Apache CloudStack 4.1 – New Features


CloudStack 4.1 is soon to be released, bringing with it a raft of new features and improvements; here I look at some of those new features that the latest release brings.

Add / Remove Network on VM

Pre CloudStack 4.1, NICs could only be added to a VM during VM Creation. This new feature means they can now be added or removed from an existing VM, and in my opinion is one of the headline new features of the 4.1 release.

You cannot remove the NIC for the Default Network so you first add a new NIC, make it default, then remove the old NIC.  The Networks the new NIC will connect to must be in the same zone as the existing VM/NIC.

The following new API calls are used:

addNicToVirtualMachine

Add a new NIC to the specified VM on the specified Network

 Parameter Description Required
 virtualmachineid  Virtual Machine ID  True
 networkid  Network ID  True
 ipaddress  IP Address  False

Event Type: NIC.CREATE
Will throw an exception if the selected network is not in the same zone as the VM.

updateDefaultNicForVirtualMachine

Update the specified NIC to be the default NIC for the specified VM. Default NIC settings will not take effect until the VM is rebooted, but the admin could change the default route in the meantime.

Parameter Description Required
virtualmachineid Virtual Machine ID True
nicid NIC ID True

Event Type: NIC.UPDATE
Will throw an exception and fail when trying to set the current default NIC.
Will throw an exception and fail if NIC is not a NIC for the specified VM.

removeDefaultNicForVirtualMachine

Remove specified NIC from the specified VM.

Parameter Description Required
virtualmachineid Virtual Machine ID True
nicid NIC ID True

Event Type: NIC.DELETE
Will throw an exception and fail when trying to remove the default NIC.
Will throw an exception and fail if NIC is not a NIC for the specified VM.

The ability to now add and remove NICs/Networks on existing VMs opens up many possibilities for changing the configuration of a Guest VM and brings even more flexibility to a CloudStack Cloud.

API Discover Service

CloudStack has over 300 API commands and with every release additional commands are added.  API commands can be enabled or disabled by the Cloud Admins, and Plugins can add even more commands, so with an ever growing list, end users need a way to list the API commands available to them.

The API discovery service allows users or apps to generate a list of the available API commands and the details. Only the API commands they are entitled to access will be listed.

The API Discovery function runs as a service which will be enabled by default, but can be disabled by admins if required.

The key benefits of this new feature are users will be able to quickly find available API commands, instead of having to refer to the ever growing API Documentation and admins can easily confirm that disabled API Commands are not available to end users.

Events Framework

Event management is an important part of managing any IT system, and CloudStack is no exception.  The new Events Framework is an in-process event bus in the Management Server which handles event notifications.  Scope is within the CloudStack Management Server so only CloudStack components and extension plug-ins can be subscribers to the events.

The end goal is to have a simple events mechanism in the CloudStack code base, which will enable more powerful notification mechanisms to be built as CloudStack extensions.

Persistent Networks without running a VM

In a CloudStack 4.0 Advanced Network Zone, each Guest Network gets allocated a VLAN ID but only after the first VM has been created.  If all of the VMs connected to the Guest Network are stopped, the associated Virtual Router will be automatically stopped by the system, and the VLAN ID will be released.  When the VMs are restarted a new VLAN ID will be issued to the Guest Network.

If an end user wishes to run physical machines outside of CloudStack, but connected to the same VLAN to enable L2 communication, currently they need to also create a VM and leave it running, which is a waste of resources.

The new Persistent Network feature enables end users to create a new Guest Network which will remain active, even when there are no VMs running.

The key use case for this new feature is to enable end users to have a CloudStack Network which is connected to external physical equipment, without the need to keep a CloudStack VM running.

Advanced Search UI

The new enhanced search options when searching for Instances, Storage, Network, Templates, ISOs, Projects and Events significantly improve the manageability of a CloudStack system, especially the larger scale deployments.

The available search criteria depend upon the area being searched, but the main fields available are:

  • Name
  • Zone
  • Domain
  • Account
  • Tag Key
  • Tag Value
  • Level

Search Menu for Instances, Storage & Snapshots

Search Menu for Network, Templates, ISOs & Projects

 Search Menu for Events

 

Resize Volumes

The size of the Root volume for a VM created from a Template is determined by the Template Author so a one size fits all approach has been required until now.  Whilst a VM created by a user from an ISO gives the user the ability to specify the partition size, they have been unable to change it once the VM has been deployed.  Data Volumes have also had a fixed size, decided when the volume is created.

The ability to resize both Root and Data Volumes of existing VMs will give the end user greater flexibility when managing their VMs, and will enable service providers to create small efficient Templates.

Users will be able to switch between different disk offerings, including the custom disk size option, enabling them to expand the size of both Root and Data Volumes. 

From an end user perspective, they can now create small VMs based on what their current data needs are, keeping costs to a minimum, rather than having to size VMs on day one, and simply expand the volumes as and when required.

The new functionality is currently only supported on KVM, but support for XenServer and VMware is expected to follow in the next release.

L3 Router Functionality for Nicira NVP Plugin

The Nicira NVP Plugin which was originally introduced in CloudStack 4.0 and enables the creation of Stateless Transport Tunnelling (STT) Guest Networks, removing the reliance on VLANs and enabling much greater scale as a result.

The CloudStack 4.0 implementation could provide all of the L2 functionality which was previously handled by the Virtual Router.

The CloudStack 4.1 Nicira NVP implementation now adds L3 routing functionality into the mix.

New features:

  • L3 Routing (Gateway)
  • Source NAT
  • Static NAT
  • Port Forwarding

The 4096 theoretical VLAN limit is a massive constraint on large public clouds, and implementing physical networks which can actually handle 4096 VLANs without crashing due to memory and CPU load on the switches is very expensive.

By using Software Defined Networks (SDN) the cloud provider can not only utilise cheaper commodity network hardware, but also build at much greater scale as the 4096 VLAN limit is removed.

With the growing popularity or Virtual Private Clouds which consume multiple VLANs per account, cloud provider management, monitoring and backup networks, which can also consume multiple VLANs per account, you can very quickly run out of even 4096 VLANs.

The addition of Layer 3 functionality to the Nicira NVP Plugin builds on an already great feature, and gives the cloud provider the ability to build at larger scale, across multiple Data Centres, and at lower cost.

One of the many ‘Enhancements’ that CloudStack 4.1 has introduced is support for Open vSwitch on KVM, so now SDN can be deployed on KVM and XenServer Clusters.

Autoscaling

Autoscaling using a Citrix NetScaler provides the ability to automatically create and destroy instances as the load demands.  This is a major new feature providing some great functionality allowing the end user to utilise a truly flexible, scalable cloud solution.

We will be publishing a blog dedicated to Autoscaling giving greater detail within the next couple of weeks.

API Request Throttling

By throttling the maximum number of API requests per second for any individual account the cloud admins can ensure their system does not get swamped by requests, and every user gets a fair amount of API resources. 

In addition, protecting against a Distributed Denial of Service Attack (DDOS) should always be high on the list of any public cloud provider and the new API request Throttling adds another weapon to your arsenal.

S3 Backed Secondary Storage

In a CloudStack Cloud with multiple Availability Zones, end users can create VMs in each Zone and also create Snapshots (backups) of those VMs.  The problem is the Snapshots reside on the Secondary Storage within the Zone that the VM is running in.

Now if one of the Availability Zones goes offline, the end user has no access to the latest Snapshot to enable them to restore data to an alternate Zone.

The new S3 Backed Secondary Storage solves this problem by enabling automatic replication of Secondary Storage data from each Zone into an S3-compatible object store.

Any data which is written to Secondary Storage is automatically replicated to the S3 object store, but it is not automatically replicated back to every Secondary Storage as this would be very inefficient.  Instead, when an end user tries to access the data from another zone, an on-demand replication of the data from the S3 object store, to the Secondary Storage in the alternate Zone takes place.

When an item such as an ISO or Template is deleted from Secondary Storage, it is also deleted from the S3 object store and every Secondary Storage it has been replicated to.

As an end user, you can now build cloud solutions across multiple Availability Zones, and be safe in the knowledge that if you have a unique VM or set of data in particular Zone, you will be able to recreate it in another Zone in the event of a disaster.

AWS Style Regions

Regions are designed to allow multiple Zones to be grouped together into geographic areas, with each Zone having a low latency link to the other Zones in its Region.

Each Region is managed by a dedicated set of CloudStack management servers, ensuring a level of independence and resilience.

An end user can access every Zone in every Region from a single logon allowing them to build and run highly resilient and efficient cloud solutions.

As each Region has its own CloudStack management servers, the potential scale of a CloudStack Cloud increases massively, as does its resilience as each Region can operate independently, meaning a failure of one Zone or Region will not affect the other Zones or Regions.

By using the new S3 Backed Secondary Storage, end users will have access to all of their ISOs, Templates and Snapshots from any Zone within a particular Region, meaning there are no barriers to building true Cloud Applications spread around the globe for maximum resilience.

Self Service Security

In CloudStack 4.0 and earlier, end users have had to rely on Root Admins to reset user passwords and SSH keys, and to generate the API and Secret Keys to enable API access..

In 4.1 end users can now do all of these themselves, so they no longer have to rely on the Root Admins, and can ensure that any security breaches such as compromised passwords can be resolved without delay.

SRX & F5 Inline

In CloudStack 4.0 a Juniper SRX Firewall and F5 load balancer can be deployed in side by side mode, where the F5 load balances inbound traffic, and the SRX handles outbound traffic.

The new inline mode available in CloudStack 4.1 enables you to put the F5 load balancer behind the SRX firewall, so benefitting from the extra levels of protection, whilst still load balancing.

Virtual Router Egress Rules

The introduction of Egress Rules on the Virtual Router allows the end user to control the outbound traffic from their Guest Network.

By default, all new Guest Networks will have no Egress Rules configured, effectively blocking all outbound traffic.  The user will need to configure the required Egress Rules to allow traffic originating from the Guest Network to reach the Internet.

Traffic which is in response to an Ingress Rule does not require an Egress Rule as the return traffic is automatically allowed out, and in the same way, Ingress Rules are not required in response to Egress Rules.

Egress Rules are made up of the Source CIDR, Protocol (TCP, UDP, ICMP or All) and Port Ranges

An example of some Egress Rules

 Example of an Allow All Egress Rule

 

About the Author

Geoff Higginbottom is an Apache CloudStack Committer and 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.

 

leave a reply