nTier Apps 2.0 Requirements

1       Background

nTier Apps was a new feature added in the previous release of CloudStack. nTier Apps feature allows users to create a multi-tier App connected to a single instance of Virtual Router that supports inter-VLAN routing. Users were also able to connect their multi-tier applications to a private Gateway or a Site-to-Site VPN tunnel and route certain traffic to those gateways. Following is the diagram that highlights the first version of the nTier Apps feature currently available in CloudStack.

However, there were some sub-features that were left out of the initial implementation. This requirements document captures additional enhancements that need to be provided for this feature in order for users to deploy this feature more widely and meet different use cases.

2        Requirements

Following are the requirements for nTier Apps 2.0 feature.

Note: Please note that this feature is currently only supported for VLAN based Isolation and not for SDN.

Note: I have split 2.20 and 2.21 into two separate tasks. Even though both are P1, we should give more importance to 2.21.

2.1 Combine VR and VPC VR Code-base and feature set

Currently the code base as well as the feature set supported for non-VPC Virtual Router and VPC Virtual Router are different. For example, Remote-Access VPN is supported only by non-VPC VR and Site-2-Site VPN is only suppoted by VPC VR. With this release, both the VR code base should be consolidated and the feature set supported should be the same. This way, going forward, when a new feature is developed, it is automatically supported in VPC and non-VPC environments. Also, features like Firewall and Network ACLs should be supported in all scenarios.

2.2 Load Balancing on all Tiers

Currently, Load Balancing is only supported using VPC VR and is only supported on on of the Tiers of an nTier Application. With this release, CloudStack should support load balancing on all tiers of an nTier application.

Use Case: Users would like to deploy a multi-tier application with the VR load balancing each of the tiers. As a result, users would be able to provide flexibility and elasticity at each tier of their application

2.3 Deployment on VM on a VPC Tier + 1 or more Shared Networks

When deploying a virtual machine, the API allows a user to deploy VM on one of the tiers as well as a shared network. The UI doesn't allow this functionality. This feature needs to be enabled in UI.

Use Case: Users might want to deploy all of their VM of a multi-tier app and receive a monitoring service via a Shared Network provided by the provider.

2.4 Support for physical devices to do FW & LB

All of the network services are currently only supported by VR in a VPC environment. Users might want Firewall, LB or other service provided by an external network provider. All of the external devices currently supported in a non-VPC environment should be supported in VPC. With requirement 2.1, this should be supported.

Use Case: Similar to the non-VPC use case, users might want to start with VR providing all of the network services. As the load increases on the application, users might want to switch to a hardware-based provider for a specific network service like Firewall or Load Balancer.

2.5 KVM Hypervisor support

Allow support for KVM Hypervisor support. This is a P2 requirement.

2.6 Blacklist of Routes

Administrators would want to block a list of routes so that they are not assigned to any of the private Gateways. Admins should be provided with an option to provide with a list of routes that are blacklisted and should be be allowed to be enabled on any of the private gateways.

2.7 Support for 8 VPN connections using the same Public IP of VR

Currently, only 1 VPN GW is supported. This requirement is to track support for up to 8 VPN gateways. This would require UI changes but we need to use the same Public IP for all 8 VPN Connections.

2.8 Static routes to VPN Gateway

This is a P2 requirement. Allow admins to add static routes on a VPN Gateway.

2.9 Remote access VPN to VPC

Isolated Networks allows Remote-access VPN capability for remote users to VPN into the Isolated Network. Similar functionality needs to be provided via the VPC VR.

2.10 Users from different Accounts should be able to deploy to a VPC

This is a P2 requirement to allow users to share a VPC between different accounts.

2.11 Don't ask the user to provide super CIDR as part of VPC creation

(Ability to give isolated network any IP network, not just unique from super-net)

Users want flexibility in defining the IP Network for each of their tiers. Users can specify a sub-network out of the VPC super-net for any specific tier and they are limited to specifying only a network out of the super-net defined while creating a VPC.

2.12 Use same public IP for static NAT, PF and LB in VPC

Users would want to have one public IP for their application and get all network services like Static NAT, Port Forwarding and/or Load balancing on that public IP. This is important both from a provider perspective (who might want to conserve public IP Addresses) as well as from the consumer perspective (who might get charged based on Public IP Addresses consumed).

2.13 Meter IPSEC data separate from other data

Open question: Is this already supported?

2.14 Allow ACL on all layer 4 protocols

Currently, there are only 3 options that a user can specify for the protocol field in the Network ACL APIs/UI. These fields are ICMP, UDP and TCP.  This requirement is to make the protocol field more flexible.

2.15 Support guest networks outside of RFC 1918 addresses

2.16 Support ACL deny rules

Only ACL allow rules are supported as part of Network ACLs. Default is to block all incoming and all outgoing traffic between tiers and between tiers and various gateways (including Public). Users might want to allow most of the traffic and deny only a selected few traffic types.

2.17 Redundant Virtual Router for VPC

This is a P2 requirement. This might get addressed as part of requirement 2.1.

2.18 Assign a VLAN ID to a network

Allow admins to specify a VLAN ID while defining a Tier of a VPC.

2.19 Add more than one Private GW to a VPC

Similar to requirement 2.7

2.20 NAT on private GW

Allow NAT service on private gateway. Currently, only a private gateway can be defined and then static routes can be defined for that private gateway.

Customer might want to deploy multiple VPCs (with the same super CIDR) and/or guest Tier CIDR. So, there could be a possibility that multiple guest VM (from different VPCs) having the same IP need to reach a enterprise DC via the Private GW. In these cases, NAT service is needed on the private GW.

Only SourceNAT service is a requirement for this release.

2.21 ACL on private GW

Allow ACL services on private gateway. Currently, only a private gateway can be defined and then static routes can be defined for that private gateway.

3       UI / UX Requirements

All of the above features should be supported via UI.

4   Upgrade Scenarios

Following upgrade scenarios should be supported:

• No upgrade scenarios need to be handled, as this is a new functionality.

5   Non-Requirements

• None

6   Bugs

• nTier Apps 2.0 JIRA Ticket

7   Open Items:

• None