On 20/12/13 5:50 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote:
>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. As per [1] in AWS VPC, "Each subnet must reside entirely within one Availability Zone and cannot span zones". However for CS I don't think we should have restriction. In the model I am proposing, VPC VR is gateway for outbound north-south traffic, then subnet of each tier is stretched at least into the zone running VPC VR anyway. So there is no reason to have this restriction. I will add tier/subnet stretching multiple zones as explicit requirement. [1] http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#VPCS ubnet > >Also, once you introduce distributed routing, access to other datacenter >services (S3 for instance) from within the VM will still go through the >VR? I am proposing to enable distributed routing only for inter-tier traffic for 4.4. So VPC VR still continue to be the gateway. As a future enhancement distributed routing for outbound traffic can be done. > >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-inte >>r >>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.h >>t >>m >>l >> > >
