With the Acton release of CloudStack, the choices for networking were significantly enhanced. CloudStack 3.x now has more options than ever before which must be fully understood if the platform is to be correctly leveraged to build public or private cloud.
Geoff Higginbottom, CTO of ShapeBlue the strategic cloud consultancy gives an overview of the networking models in CloudStack and highlights the key networking decisions to be made when designing a cloud around CloudStack.
CloudStack has two Networking models, Basic and Advanced, which one you use will depend on your requirements and what you are using your cloud for. As a CloudStack deployment consists of multiple Availability Zones, PODs and Clusters (see https://www.shapeblue.com/2012/03/16/cloudstack-architecture-overview/ for more info) then you can have Zones running a Basic Network architecture, and Zones running an Advanced Network architecture, all within the same Cloud, and all managed by CloudStack.
Network Traffic Types
There are four types of network traffic within CloudStack:
• Guest: When end users run VMs or Guest Instances as CloudStack refers to them, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network.
• Management: When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between Hosts, System VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server.
• Storage: Traffic between Primary and Secondary storage servers, such as VM templates and Snapshots.
• Public: Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire IPs to implement NAT and Load Balancing between their guest network and the public network.
Guest, Management and Storage are common to Basic and Advanced Networking, Public Traffic is only present in an Advanced Network configuration.
|
|
|
It is highly recommended to assign the different traffic types to different dedicated NICs on the Hypervisor, and also to use NIC Bonding where possible.
IP Addressing Schemas
Basic Networking
In a Basic Networking setup, the Guest Instances use the same IP range as the underlying CloudStack and Hypervisor architecture. When designing your IP Schema, allow sufficient IP Addresses to cater for all of your CloudStack infrastructure including the Guest Instances. Consider using an IP Range such as 192.168.0.0/20 for each Zone, as this will provide over 4,000 addresses IPs per Zone. Warning:, If you use a /16 subnet for your first Zone, there would be no more Private IP Addresses left for additional Zones!
IP addresses will need to be reserved for each POD, and a Guest IP Range assigned during the initial configuration of the Zone. Every Host, System VM and Guest Instance within the whole Cloud must have a unique IP Address.
Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network.
Advanced Networking
In an Advanced Networking setup, each Account is allocated the following:
[slist]
- Public IP, this is a live Internet Address and is assigned to their Virtual Router
- Guest IP Range, for example 10.1.1.0/24
- VLAN ID for the Isolated Guest Network
[/slist]
The default Guest IP Range is the same for all Accounts within a Zone, however it is possible for a Root Administrator to assign custom IP ranges to different Accounts.
Guests Instances within an Account communicate with each other and their Virtual Router via their own dedicated VLAN. Guest Instances can be running on any Host within the Zone, the VLANs on the Layer 2 Switches ensure they can always communicate by using VLAN Trunking.
Reserved System IP Addresses
When configuring a POD, IP addresses must be reserved for the System VMs, an allocation of 10 addresses is normally sufficient for this purpose. The reserved addresses are used by the Secondary Storage VM, and the Console Proxy VMs (on a busy system multiple Console Proxy VMs may be automatically created to deal with the workload)
Every Host and System VM throughout the entire Cloud must have a unique IP address, so when adding additional Zones, the configuration of any existing Zones must be taken into account.
Link-Local IPs
When using XenServer and KVM Link-Local addressses are allocated to the System VMs and every Virtual Router, with over 65,000 addresses available in the Link-Local Subnet it is unlikely you will ever run out of addresses. PODs containing only XenServer and KVM Clusters can be allocated a /24 CIDR for use by the Hosts and Storage.
When using VMware however IPs from the configured IP range for the POD are used by the System VMs Virtual Routers, so it is vital a suitable IP Schema is put in place when the system is configured.
For a VMware POD consider using a /21 address range, as this will allocate 2046 IPs for use by the Hosts, Storage, System VMs and Virtual Routers.
Guest Isolation
Guest Instances require isolation from other Instances running within the same Zone, this is achieved in two ways, Security Groups or VLANs.
Security Groups are available in both the Basic and Advanced Networking models, however VLAN isolation is only available with Advanced Networking.
Security Groups
When using Security Groups , each Account has a default Security Group which is automatically created. When Instances are created, they are assigned to one or more Security Groups.
Users can create additional Security Groups at any time, however existing Guest Instances cannot be assigned to newly created Security Groups, they have to be allocated to a Security Group when they are created.
Guest Instances within a Security Group are able to communicate with each other directly. Ingress and Egress rules on the Security Group control the flow of traffic, both in and out of the Group.
VLANs
VLANs are the default method for Guest Isolation when using Advanced Networking. When the first Guest Instance is created for an Account, an Isolated Network is also created, using the Guest CIDR configured for that Zone (the default 10.1.1.0/24)
If an additional Isolated Guest Network with a specific IP Range is required, a ROOT Administrator must create it and assign it to the Account, Users and Domain Administrators do not have the ability to create Isolated Guest Networks with a specific IP Range and VLAN ID .
Summary
This was an introduction to Networking in CloudStack 3.x, its aim was to give you an understanding of the two models, Basic and Advanced. There is lots more to CloudStack Networking as it is one of the key differentiators between simple Virtual Private Servers, and a true Cloud offering.
The next article in this series will look in more depth at the Advanced Networking model, and how to create and use custom Network Offerings using the CloudStack API.
About the Author
Geoff Higginbottom is CTO of ShapeBlue, the strategic cloud consultancy. Geoff spends most of his time designing private & public cloud infrastructures for telco’s, ISP’s and enterprises based on CloudStack.
Steve is ShapeBlue’s COO and is responsible for all day-to-day administrative and operational functions of the business, including the consulting, programme management, and support functions.
Involved with CloudStack since 2012, Steve has led several large customer engagements including a number of major public and private cloud deployments; co-ordinated and developed worldwide teams and helped implement and deliver an enterprise grade support product.
Prior to ShapeBlue, Steve held senior technical, project and account management roles in enterprise IT outsourcing companies where he gained domain experience in the finance, professional services and defence markets.
Away from work, Steve is a father, keen guitarist, snowboarder and singer (not necessarily in that order).
Away from work, Steve is a music lover and semi-professional musician. Although he doesn’t speak at many technology conferences, he can sometimes be heard providing the evening entertainment.
