Ah OK. Just want to make sure that traffic accounting for access to in-DC services is separate even though it may go through the same interface as the public traffic.
On 12/20/13 2:09 AM, "Murali Reddy" <murali.re...@citrix.com> wrote: >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#VPC >S >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-int >>>e >>>r >>>c >>>onnect.html >>>[2] >>>http://etherealmind.com/introduction-to-how-overlay-networking-and-tunne >>>l >>>- >>>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 >>> >> >> > >
