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 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 0542tel:+442036030542 | S: +44 20 3603 0540tel:
+442036030540 | M: +447968161581tel:+447968161581
geoff.higginbot...@shapeblue.commailto: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.commailto:
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
