Open Stack

Tricircle project has decided to shrink its scope to networking automation across Neutron, and focus on addressing the networking requirements in following use cases:

1. Cloud Capacity Expansion

When one OpenStack cloud is provisioned with more and more resources, the capacity of one OpenStack instance may not be enough. A new openstack instance has to be added to the cloud. But tenants still want to add VMs to existing network.


2. Application high availability running over cloud

In telecom and other industries(for example, MySQL Galera cluster), normally applications tend to be designed as Active-Active, Active-Passive or N-to-1 node configurations. Because those applications need to be available as much as possible. Once those applications are planned to be migrated to cloud infrastructure, active instance(s) need(s) to be deployed in one OpenStack instance first. After that, passive or active instances(s) will be deployed in another (other) OpenStack instance(s) in order for achieving 99.999% availability, if it’s required. The reason why this deployment style is required is that in general cloud system only achieve 99.99% availability.

To achieve required high availability, design of network architecture (especially Layer 2 and Layer 3) across Neutron needs to be considered for application state replication or heartbeat.


3. Isolation of East-West traffic

In financial industry, more than one OpenStack instances will be deployed, some OpenStack instance will be put in DMZ zone, and the other ones in trust zone, so that application or part of the application could be put in different level security zone. Although the tenant’s resources are provisioned in different OpenStack instances, east-west traffic among the tenant’s resources should be isolated.

Bandwidth sensitive, heavy load App like CAD modeling asked for the cloud close to the end user in distributed edge site for better user experience, multiple OpenStack instances will be deployed into edge sites, but the east-west communication with isolation between the tenant’s resources are also required.


4. Dual ISPs Load Balancing for internet link

Deploy application in separate OpenStack instance with dual ISPs for internet link redundancy, load balancing, east-west traffic isolation for data/state replication is needed.


5. Cross Neutron L2 network for NFV area

IN NFV(Network Function Virtualization) area, network functions like router, NAT, LB etc will be virtualized, The cross Neutron L2 networking capability like IP address space management, IP allocation and L2 network segment global management provided by the Tricircle can help VNFs(virtualized network function) across site inter-connection. For example, vRouter1 in site1, but vRouter2 in site2, these two VNFs could be in one L2 network across site.


The common requirements for above use cases are:

1. Tenant's resources will be located in different OpenStack instances, networking across Neutron required.

2. IP/Mac address management across Neutron to avoid conflict.

3. East-west L2/L3 traffic for the tenant should be isolated. No matter using VPN or not.

4. If L2 network will be stretched into multiple Neutron, global network segment management is required.

5. Security group should work for VMs in different OpenStack instances.

... etc.


Although Tricircle splitting and cleaning is WIP, some draft materials were prepared for open comments and to be improved with your contribution:

1. Tricircle focuses on networking automation across Neutron: https://docs.google.com/presentation/d/1Zkoi4vMOGN713Vv_YO0GP6YLyjLpQ7fRbHlirpq6ZK4/

2. Tricircle design blueprint update: https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/

3. Tricircle wiki update: https://wiki.openstack.org/wiki/Tricircle

(Caution: the git repo. of Tricircle will be purified, nova_apigw and cinder_apigw will be removed from the repo. soon https://github.com/openstack/tricircle/ , the description will also be updated)

There are also some requirements to Neutron to support cross Neutron networking automation, for example, to support VxLAN network across Neutron (6.5.3 Shared VxLAN, point2point, https://docs.google.com/document/d/1zcxwl8xMEpxVCqLTce2-dUOtB-ObmzJTbV1uSQ6qTsY/), IP/mac list needs to be added for different VTEP in the patch https://review.openstack.org/#/c/282180/  for better data plane performance.

If you are interested in the L2/L3 networking automation across Neutron, it will be good to have a BoF to meet and discuss f2f in Barcelona.

Best Regards
Chaoyi Huang (joehuang)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160919/8eac0eb7/attachment.html>