Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?

[Rob C.]

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."  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 
>> Date: Thu, Oct 17, 2013 at 2:56 AM
>> Subject: Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?
>> To: &

Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?

[Geoff Higginbottom]

Rob,

Answers in line prefixed GH

Regards

Geoff Higginbottom
CTO / Cloud Architect


D: +44 20 3603 0542 | S: +44 20 3603 0540 
| M: +447968161581

geoff.higginbot...@shapeblue.com<mailto: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." 
mailto: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 
mailto: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: "mailto: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 /

Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?

[Rob C.]

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.

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?

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?


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?

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.

Thanks again,
Rob



From: Geoff Higginbottom 
> Date: Thu, Oct 17, 2013 at 2:56 AM
> Subject: Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?
> To: "" 
>
>
> 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 | S: +44 20 3603 0540 +442036030540> | M: +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>> 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-ty

Re: Secondary Storage IP Subnet: Is it Optional or Mandatory?

[Geoff Higginbottom]

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 | S: +44 20 3603 0540 
| M: +447968161581

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." 
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 reg

RE: Secondary Storage IP Subnet: Is it Optional or Mandatory?

[Sanjeev Neelarapu]

Hi Rob,

Even in 4.2 defining storage traffic is not mandatory while creating physical 
network. If you opt to have storage network then you have to specify IP range.

Thanks,
Sanjeev

-Original Message-
From: Rob C. [mailto:iose...@gmail.com] 
Sent: Thursday, October 17, 2013 4:58 AM
To: users@cloudstack.apache.org
Subject: Secondary Storage IP Subnet: Is it Optional or Mandatory?

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