Features and Benefits

The existing CloudStack VPC implementation already offers an extensive list of features and benefits. Amongst those we can list:

  • Remote VPN Access
  • Inter-VPC Networking
  • Private Gateways
  • Multiple Isolated Networks
  • Access Control Lists
  • Load Balancing

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 a critical application's uptime, offering a better Disaster Recovery strategy by quickly switching network traffic to a backup virtual router, hence increasing business continuity. 

Use Cases

Host a simple, public-facing website

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.

Host scalable web applications

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.

Host high available critical applications

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 two 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.

Implementation

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.

rVPC Offering

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.  

Integration Tests

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:

  • test_vpc_offerings.py
    • That's an existing test, but it has been updated in order to cover the following:
      • Redundant VPC offering creation;
      • Create a Redundant VPC using the newly created offering
  • test_vpc_redundant.py
    •  That's a new test, which will check the new features of the CloudStack Virtual Private Clouds. It does the following:
      • 1st Round of Tests
        • Creates a Redundant VPC
        • Creates 2 tiers
        • Creates 4 virtual machines, 2 per tier
        • Acquires 4 public IPs
        • Create port forwarding rules to open port 22, per IP, and assign to each virtual machine
        • SSH into the virtual machines
        • Check it succeeds
      • 2nd Round of Tests
        • Stop the Master router
        • Check the the Backup router becomes Master
        • SSH into the virtual machines
        • Check it succeeds
      • 3rd Round of Tests
        • Delete all port forwarding rules
        • SSH into the virtual machines
        • Check that it doesn't succeed
      • 4th Round of Tests
        • Start the stopped router
        • Check that we don't have 2 routers as Masters
        • Add all port forwarding rules
        • SSH into the virtual machines
        • Check it succeeds

Running the tests

  • test_vpc_offerings.py

    • nosetests --with-marvin --marvin-config=[marvin_configuration_file_path] -s -a tags=advanced,required_hardware=false test_vpc_offerings.py

  • test_vpc_redundant.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.

JIRA Issues

  • Unable to render Jira issues macro, execution error.
  • Unable to render Jira issues macro, execution error.
  • Unable to render Jira issues macro, execution error.

 

  • No labels