The existing CloudStack VPC implementation already offers an extensive list of features and benefits. Amongst those we can list:
From the features listed above we can take as an example the multiple isolated networks. For instance, each network, or tier, will have an independent Access Control List in order to control the in/out traffic That's just a simple example as we won't explain all the existing features in this document. Here we will talk about the new Redundant Virtual Routers in the VPCs
Concerning the Redundant Routers for VPCs, the main goal behind its implementation was to increase critical applications' uptime, by offering a better Disaster Recovery strategy by quickly switching network traffic to a backup virtual router, hence increasing business continuity.
You can host a basic web application, such as a blog or simple website in a VPC, and gain the additional layers of privacy and security Host muilti-tier web applications offered by CloudStack. You can increase security by creating ACL rules which allow the the virtual routers to respond to inbound HTTP and SSL requests, for example, while simultaneously prohibiting the routers from initiating outbound connections towards other ports.
You can use a CloudStack VPC to host multi-tier web applications and enforce access between your web-servers, application servers, and databases. You can launch web-servers in a publicly accessible tier and application servers and databases in non-publically accessible tiers. The application servers and databases can’t be directly accessed from the Internet, but they can still access the Internet. You can control access between the servers and tiers using inbound and outbound rules provided by network access control lists.
You can create a CloudStack VPC where instances in one tier, such as web-servers, communicate with the Internet while instances in another tier, such as application servers, communicate with databases on your corporate network. A VPN connection between your VPC and your corporate network helps secure all communication between the application servers in the cloud and databases in your datacenter.
Thanks to the redundant nature of a CloudStack VPC, your applications are by default high available. The VPC will contain tow virtual routers, where the configuration of tiers, ACLs, public IPs, Load Balancers and Port Forwarding are persisted. In case one of the routers crash or loses networking connection, the traffic will be automatically forwarded to the backup router, which in that case will have its status changed to master.
The current rVPC - (i.e. redundant Virtual Private Cloud) implementation relies on the usage of industry standards like the VRRP - Virtual Router Redundancy Protocol RFC-3769 - and the Netfilter's Connection Tracking System, which is implemented under the conntrack-tools package for GNU/Linux systems.
For instance, a new service offering has been added in order to make the system identify which type of VPC is being created. When the redundant VPC offering is used, the VPC will be deployed with two routers instead of only one. It will also make possible to identify the rVPC configuration and make sure the routers get all the setup done without interference of the system administrators.
The new offering will be available on CloudStack 4.6 and onwards. When creating a CloudStack VPC, the user will be prompted with the following screen:
Apache CloudStack will also make available the possibility to convert existing single router VPCs into redundant ones. This will make users and system administrator to easily increase the robustness of their application via 1-click. This can be accomplished by restarting the single VPC. See the image depicted below for more details:
However, turning a single VPC into a redundant one means downtime. During the restart process, there won't be any router taking care of the in/outbound network traffic.
In order to cover the new functionality, making sure the implementation actually works, a couple of new Integration Tests were added under the test/integration/component directory:
nosetests --with-marvin --marvin-config=[marvin_configuration_file_path] -s -a tags=advanced,required_hardware=false test_vpc_offerings.py
nosetests --with-marvin --marvin-config=[marvin_configuration_file_path] -s -a tags=advanced,required_hardware=true test_vpc_redundant.py
When running the "test_vpc_offerings.py", the required_hardware flag should be set to false. The test will only create the offering and a Redundant VPC, no further tests will be done (e.g. create VMs, etc).
However, concerning the "test_vpc_redundant/py", it does need the required_hardware flag to be set to true.