Resource Representations in GENI: A path forward
description
Transcript of Resource Representations in GENI: A path forward
![Page 1: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/1.jpg)
Resource Representations in GENI:A path forward
Ilia Baldine, Yufeng Xin
[email protected], [email protected]
Renaissance Computing Institute, UNC-CH
![Page 2: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/2.jpg)
Slicing of a network
![Page 3: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/3.jpg)
Link slivering
![Page 4: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/4.jpg)
4
Agreements – resource representation cycle
Possibly fuzzy request
More specific request to substrate provider(s)
Detailed manifest fromsubstrate provider
Collective possibly filtered manifest
Ads from substrate providers
![Page 5: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/5.jpg)
5
PG Rspec V1
GENI Resource representation mechanisms
• ‘Traditional’ Network resources– Ethernet links, tunnels, vlans
• Edge compute/storage resources• Measurement resources
– Including collected measurement data objects
• Wireless resources– WiFi, WiMax, motes etc
• Lack of agreement on what resources represent will be a significant impediment to interoperability
• Agreement on a format is important, but can be dealt with on the engineering level
PL RSpec PG Rspec V2 ORCA NDL-OWL OMF
![Page 6: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/6.jpg)
6
Network resources
• Key distinctions– Number of layers– Describing adaptations
between layers– Syntax– Tools
PL
PG
NDL-OWL
![Page 7: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/7.jpg)
7
Aside: why adaptations are critical?• Network adaptations are part of the description of stitching
capability• Needed for properly computing paths between aggregates
connected by network providers at different layers– E.g. if a host has an interface that has an Ethernet to VLAN
adaptation, this interface is capable of stitching to vlans– Consistent way to describe connectivity across layers (tunnels,
DWDM, optical)
• Also– Important for matching requests to substrate capabilities
• E.g. creating a VM is a process of ‘adaptation’ of real hardware to virtualization layer
![Page 8: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/8.jpg)
8
Network resources: a practical solution
• Stay primarily within Ethernet layer• Accept one format to be used between control
frameworks• Perform bi-directional format conversion
– Only partial may be possible
• Hosted services that perform conversion on demand– E.g. NS2/RSpec v1 and v2 request converter to NDL-OWL– http://geni-test.renci.org:11080/ndl_conversion/request.jsp
• Works well for several types of links, nodes, interfaces, ip addresses and simple link attributes
![Page 9: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/9.jpg)
9
Agreeing on wire format
• RSpec v2 with extensions is a viable possibility• Conversion from RSpec v2 is relatively
straightforward pending agreement on edge resources
• Conversion to RSpec v2 is likely to be partial but probably sufficient for the time being– Nothing below Layer2 is visible to experimenter
![Page 10: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/10.jpg)
10
Next challenge: Edge compute resources
• Ads:– Aggregates can produce (adapt to) different types of nodes– E.g. PL VServer, PG bare hardware node types, ORCA’s
Xen/KVM virtual machines (and hardware nodes)– Constraints are possible on disk, memory size, number and type
of CPU cores– Properties may include location, ownership etc.– Note: internal topology may or may not be part of the site ad. E.g.
clouds have no inherent topology that needs to be advertized
• Requests:– Based on constraints on type of node, disk, memory size, core
type and count, location
![Page 11: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/11.jpg)
11
Advertising edge resources
• A server can be an individual node or a cloud of servers• A site may choose to advertise individual servers/nodes
or server clouds– Clouds have no inherent topology, just constraints on the type
of topology they can produce and adaptations for nodes
• Servers/nodes or server clouds are adaptable to different types of nodes distinguished by– Virtualization (Xen, KVM, VServer, None etc)– Possibly memory, disk sizes, core types and counts, OS
![Page 12: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/12.jpg)
12
Requesting edge resources
• A request for a node specifies multiple constraints on that node– Type of virtualization preferred– Memory, disk size– CPU Type– Core count– OS
• Allows policy to pick best sites based on request and resource availability.
![Page 13: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/13.jpg)
13
Semantic Shortcut examples
• Semantic shortcuts– PL node
• Virtualiztion: Vserver
– Simple PG node• Virtualization: None• CPU type: x86 or ?? or ??
– EC2M1Small• Virtualization: KVM or XEN• CPU count: 1• Memory size: 128M
– EC2M1Large• Virtualization: KVM or XEN• CPU count: 2• Memory size: 512M
– PlanetLabCluster• Produces PL Nodes
– ProtoGeniCluster• Produces PG nodes
![Page 14: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/14.jpg)
14
Other considerations
• Emerging standards:– OVF – portable appliance images across
heterogeneous environments– CF should be able to generate OVF based on
combination of request data and substrate information
• Higher-level programming environments:– Google App Engine, AppScale– Distributed map/reduce– …
![Page 15: Resource Representations in GENI: A path forward](https://reader035.fdocuments.net/reader035/viewer/2022062500/56815769550346895dc50c65/html5/thumbnails/15.jpg)
15
Next steps
• Align edge compute resource descriptions• Enable conversion as a GENI-wide service• Test full interoperation PG<->ORCA by GEC11• Get the conversation started on aligning
abstraction models for for – Wireless resources
• Max Ott, Hongwei Zhang, ?
– Storage (physical and cloud)• Mike Zink, ?