Geoff, thanks again! Rob
On Fri, Oct 18, 2013 at 4:40 PM, Geoff Higginbottom < geoff.higginbot...@shapeblue.com> wrote: > Rob, > > Answers in line prefixed GH > > > Regards > > > > Geoff Higginbottom > > *CTO / Cloud Architect* > > > > > > D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540 <+442036030540> | > M: +447968161581 > > > > geoff.higginbot...@shapeblue.com | www.shapeblue.com > > > > ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS > > > > > On 18 Oct 2013, at 18:18, "Rob C." <iose...@gmail.com> wrote: > > > Hi, > > Thanks Sanjeev and Geoff for your replies. I have a few follow-up > questions. > > A. The document I referenced states "if a physical storage interface was > not > specified when creating the zone this interface will not exist" in > reference to eth3 (the SSVM storage network interface). Is that no > longer the case? I don't see the logic of having a second virtual NIC on > the same subnet. > > GH - there are always 4 vNICs, link local, management, storage and public. > > > > > B. I know that having multiple NICs on the same system connected to the > same subnet can sometimes cause network issues. If this is to be the > resulting configuration on the SSVM, is there anything I should watch out > for? What has been done to head off any issues that could result from this > configuration? > > GH - if the storage network is not configured CloudStack creates static > routes mapping the IPs of the sec storage devices to the 'storage' vNIC. > Default gateway is the public interface. > > > > C. Aside from performance/redundancy concerns, can you offer any general > comments regarding the wisdom of opting not to have a secondary storage IP > subnet? Beyond being technically possible and permitted, is this a common > and accepted approach? > > GH - I've been involved in lots of deployments and I'd say about half > have used the storage network and half have not. If you have hosts with > lots of 1GB NICs you can dedicate some to Sec Storage to help with the > transferring of Snapshot data. If you only have 2x10GB NICs then the > common approach is to simply put all traffic over a LACP bond. > > > For my better understanding, and because I am weighing the options, I'd > still appreciate answers to my questions about the Secondary Storage > network, re-posted below: > > 4. I haven't found any documentation that helps with planning the size of > the Secondary Storage network -- besides the NFS server and the SSVM, what > other devices must have an IP address on this network? > > GH - The IPs you allocate to the storage network for the POD are used by > the SSVMs running in that POD. Every Host also needs to have a connection > to all Secondary Storage devices within the Zone, as do the Management > Servers. > > > 5. How are IP addresses for devices on the Secondary Storage network > assigned? In the case of the SSVM it must be dynamic, but if I were to > manually put a CloudStack host onto this network (for convenience), what > assures that the same IP address won't also get handed out to an SSVM? > > GH - The IPs are for SSVM only. The IPs you allocate to Hosts must be > outside of the range you allocate to the POD. FYI Hosts HAVE to have a > connection to Sec storage, either directly or via their default gateway. > > > 6. Is it permitted to place the Secondary Storage traffic onto its own > dedicated vSwitch on ESXi? According to the Installation Guide under > section 8.3.5.1.1 Separating Traffic: "*CloudStack allows you to use > vCenter to configure three separate networks per ESXi host. *...* The > allowed networks for configuration are public, guest, and private (for > management and usually storage traffic).*" This would suggest that storage > traffic must share the same vSwitch as management traffic. > > GH - when allocating the different traffic types to different NICs you > map the traffic to the vSwitch so you have to configure a dedicated vSwitch > for each network. > > As a side note, if you have a zone with multiple hypervisors, say VMWare > and XenServer, the networks need to be common across the Zone, so all your > hosts should have the same number of NICs. For VMware you map the traffic > to the vSwitch, and for XenServer you map it to the name of the network or > bond, and for KVM the bridge etc. > > > Thanks again, > Rob > > > > From: Geoff Higginbottom <geoff.higginbot...@shapeblue.com> >> Date: Thu, Oct 17, 2013 at 2:56 AM >> Subject: Re: Secondary Storage IP Subnet: Is it Optional or Mandatory? >> To: "<users@cloudstack.apache.org>" <users@cloudstack.apache.org> >> >> >> Hi Rob, >> >> The 'storage' network is indeed optional so your plan to not use it is >> perfectly valid. >> >> Simply put the NFS server on the management network or ensure there is a >> route to it via the management network. >> >> The SSVM will still get a virtual interface dedicated to storage, but it >> will be assigned an additional IP address from the management ip range. >> >> There is no need to configure any ip range for storage, and if using the >> add zone wizard it will not prompt you for one. >> >> Regards >> >> Geoff Higginbottom >> CTO / Cloud Architect >> >> >> D: +44 20 3603 0542<tel:+442036030542> | S: +44 20 3603 0540<tel: >> +442036030540> | M: +447968161581<tel:+447968161581> >> >> geoff.higginbot...@shapeblue.com<mailto:geoff.higginbot...@shapeblue.com> >> | www.shapeblue.com >> >> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS >> >> >> >> On 17 Oct 2013, at 01:08, "Rob C." <iose...@gmail.com<mailto: >> iose...@gmail.com>> wrote: >> >> Hi, >> >> According to some (possibly old) documentation I read, I have the >> impression that it is *optional* to define a secondary storage IP >> subnet. >> >> >> Note, my questions are all in the context of: >> - CloudStack 4.2 >> - ESXi hosts / vSphere 5.1 >> - Primary Storage is VMFS via fiber channel >> - Advanced Networking >> >> Here is the document to which I am referring, along with the relevant >> quotes: >> CloudStack System VMs: >> >> https://cwiki.apache.org/confluence/download/attachments/30149076/Cloudstack+System+VMs.pdf >> *"Network Terminology -> Storage: As it relates to CloudStack, this is >> an >> >> optional network dedicated to secondary storage. If not specified, the >> management network will be assumed for this role."* >> >> *"SSVM -> eth3 (storage): Note if a physical storage interface was not >> specified when creating the zone this interface will not exist. Storage >> traffic will assume the management interface"* >> >> >> My Questions: >> 1. Is the above-referenced document accurate for CloudStack 4.2? >> >> 2. Do I interpret correctly that I don't need to define an IP subnet for >> Secondary Storage? >> >> 3. I have noticed that the CloudStack 4.2 Installation Guide, section >> 2.8.3 >> "Advanced Zone Network Traffic Types", for the type "Storage" says: *"You >> must configure the IP range to use for the storage network."* >> >> >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/index.html#advanced-zone-network-traffic-types >> How am I to interpret the quoted statement? Is it saying that I must >> configure a range regardless, or only if I *opt* to have a Secondary >> >> Storage network? If there is no Secondary Storage IP subnet, would I >> enter >> a range selected from the Management IP subnet? >> >> I am aware of the redundancy and performance benefits to using separate >> interfaces, this is not my concern here. My idea is to have a simplified >> CloudStack architecture by using a single IP subnet for CloudStack >> Management, and putting the NFS server on the same subnet (NFS to be used >> for Secondary Storage only). >> >> If your response is that a defined Secondary Storage IP subnet is a >> mandatory requirement, then I have a few other questions regarding this >> network: >> 4. I haven't found any documentation that helps with planning the size of >> the Secondary Storage network -- besides the NFS server and the SSVM, what >> other devices must have an IP address on this network? >> >> 5. How are IP addresses for devices on the Secondary Storage network >> assigned? In the case of the SSVM it must be dynamic, but if I were to >> manually put a CloudStack host onto this network (for convenience), what >> assures that the same IP address won't also get handed out to an SSVM? >> >> 6. Is it permitted to place the Secondary Storage traffic onto its own >> dedicated vSwitch on ESXi? According to the Installation Guide under >> section 8.3.5.1.1 Separating Traffic: "*CloudStack allows you to use >> vCenter to configure three separate networks per ESXi host. *...* The >> >> allowed networks for configuration are public, guest, and private (for >> management and usually storage traffic).*" This would suggest that >> storage >> >> traffic must share the same vSwitch as management traffic. >> >> If I am missing something fundamental, and/or asking the wrong questions, >> please correct me! Same goes if you have some general insight into the >> pros and cons of having a Secondary Storage IP subnet. >> >> Many thanks! >> Rob >> This email and any attachments to it may be confidential and are >> intended solely for the use of the individual to whom it is addressed. Any >> views or opinions expressed are solely those of the author and do not >> necessarily represent those of Shape Blue Ltd or related companies. If you >> are not the intended recipient of this email, you must neither take any >> action based upon its contents, nor copy or show it to anyone. Please >> contact the sender if you believe you have received this email in error. >> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue >> Services India LLP is a company incorporated in India and is operated under >> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a >> company incorporated in Brasil and is operated under license from Shape >> Blue Ltd. ShapeBlue is a registered trademark. >> >> > This email and any attachments to it may be confidential and are > intended solely for the use of the individual to whom it is addressed. Any > views or opinions expressed are solely those of the author and do not > necessarily represent those of Shape Blue Ltd or related companies. If you > are not the intended recipient of this email, you must neither take any > action based upon its contents, nor copy or show it to anyone. Please > contact the sender if you believe you have received this email in error. > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue > Services India LLP is a company incorporated in India and is operated under > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a > company incorporated in Brasil and is operated under license from Shape > Blue Ltd. ShapeBlue is a registered trademark. >
