cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Higginbottom <geoff.higginbot...@shapeblue.com>
Subject Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?
Date Fri, 18 Oct 2013 20:40:26 GMT
Rob,

Answers in line prefixed GH

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.higginbottom@shapeblue.com<mailto:geoff.higginbottom@shapeblue.com> | www.shapeblue.com

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS



On 18 Oct 2013, at 18:18, "Rob C." <ioserve@gmail.com<mailto:ioserve@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.higginbottom@shapeblue.com<mailto:geoff.higginbottom@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<mailto:users@cloudstack.apache.org>>" <users@cloudstack.apache.org<mailto: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:%2B44%2020%203603%200542><tel:+442036030542<tel:%2B442036030542>>
| S: +44 20 3603 0540<tel:%2B44%2020%203603%200540><tel:+442036030540<tel:%2B442036030540>>
| M: +447968161581<tel:%2B447968161581><tel:+447968161581<tel:%2B447968161581>>

geoff.higginbottom@shapeblue.com<mailto:geoff.higginbottom@shapeblue.com><mailto:geoff.higginbottom@shapeblue.com<mailto:geoff.higginbottom@shapeblue.com>>
| www.shapeblue.com<http://www.shapeblue.com>

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS



On 17 Oct 2013, at 01:08, "Rob C." <ioserve@gmail.com<mailto:ioserve@gmail.com><mailto:ioserve@gmail.com<mailto:ioserve@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message