Is there any reason to restrict a subnet to a single zone? AFAIK, AWS VPC lets you stretch a subnet across AZ. This way you can replicate *within* the DB tier to another zone.
Also, once you introduce distributed routing, access to other datacenter services (S3 for instance) from within the VM will still go through the VR? On 12/19/13 4:24 AM, "Murali Reddy" <murali.re...@citrix.com> wrote: >I would like to propose two networking models enhancements for ACS 4.4 >release that will enable building highly available applications. Currently >VPC in CloudStack is a zone level entity. So tiers with in the VPC are >confined to the zone to which VPC belongs. For an application deployed in >current model of VPC failure of the zone is a single point of failure. It >is desirable to make VPC a region level entity, where tiers in the VPC can >be created in different zones of the region. When tiers can be created in >different zones, application hosted in VPC can be architected to be highly >available masking zone failures by having redundant tiers in different >zones. While it may be seen as natural extension, there are fundamental >limitations with VLAN/traditional L2 based networking due to which >realizing it would be non-trivial or require special solutions [1]. >Overlay networks [2] in the context of SDN & network virtualization >provides a way to build networks that are abstracted from >physical/underlay network. An overlay network is typically built with >tunnels across edge(vSwitch's in hypervisor) and core is plain L3 network. >With requirement that L3 connectivity across zones and tunnels can be >established across the zones, an overlay network that spans multiple zones >is easily realized. > >Given the range of SDN controllers that are integrated with CS, goal of >this proposal is to leverage advances in SDN & network virtualization >introduce below generic notions into CS. > >- an advanced zone isolated network that can span multiple zones >- a region level VPC where tiers belong to different zones. > >I have opened bugs [3],[4] to track these two enhancements. As part of the >effort I would like to extend the current OVS plug-in (that builds overlay >network with GRE tunnels) to realise these two use-cases. I have opened >bug [5] to track this enhancement. > >As long as we establish tunnels across the zones, we can have overlay >networks that are functional, but would be inefficient in handling >east-west traffic [6] and BUM traffic. While the problems exist in the >overlay networks that are confined to a zone as well, they are compounded >when the network spans multiple zones resulting in high cross-zone >east-west traffic. I would be sending out a complementary proposal to >introduce distributed routing and ACL's for east-west traffic and ARP >localisation that will allow only legitimate cross zone east-west traffic. > >I will send out a functional specification with detailed requirements, >assumptions, limitation etc once I make progress with these enhancements. >Please share any feedback and comments. > >[1] >http://www.networkworld.com/news/tech/2010/090310-layer2-data-center-inter >c >onnect.html >[2] >http://etherealmind.com/introduction-to-how-overlay-networking-and-tunnel- >f >abrics-work/ >[3] https://issues.apache.org/jira/browse/CLOUDSTACK-5567 >[4] https://issues.apache.org/jira/browse/CLOUDSTACK-5568 >[5] https://issues.apache.org/jira/browse/CLOUDSTACK-5569 >[6] >http://blog.ipspace.net/2011/02/traffic-trombone-what-it-is-and-how-you.ht >m >l >
