cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Kahn <jk...@idea11.com.au>
Subject Re: Storage Networks XenServer
Date Fri, 22 Jun 2012 12:35:55 GMT
Hi Geoff,

That quote will be talking about the local interfaces / routes on your
XenServer hosts. I believe what it means is that it uses the XenServer's
routing table to determine which interface to send the primary storage
traffic out from.

Primary storage traffic is definitely going through the storage network in
our install.

JK.



-----Original Message-----
From: Geoff Higginbottom <geoff.higginbottom@shapeblue.com>
Reply-To: "cloudstack-users@incubator.apache.org"
<cloudstack-users@incubator.apache.org>
Date: Friday, 22 June 2012 10:28 PM
To: "cloudstack-users@incubator.apache.org"
<cloudstack-users@incubator.apache.org>
Subject: RE: Storage Networks XenServer

>Hi James,
>
>Thanks for your feedback, what is confusing here is that the admin guide
>states that the
>
>Quote
>For the separate storage network to work correctly, it must be the only
>interface that can ping the primary storage device's IP address
>Unquote
>
>I would assume that by adding a route between the storage and management
>networks this will no longer be the case
>
>Regards
>
>Geoff
>
>-----Original Message-----
>From: James Kahn [mailto:jkahn@idea11.com.au]
>Sent: 22 June 2012 13:25
>To: cloudstack-users@incubator.apache.org
>Subject: Re: Storage Networks XenServer
>
>Hi Geoff,
>
>We experienced the same and settled for adding a route between the
>storage and management networks on L3 switches.
>
>I agree that ideally secondary storage should be able to be isolated to
>the management network only to ensure primary storage performance.
>
>JK.
>
>
>
>-----Original Message-----
>From: Geoff Higginbottom <geoff.higginbottom@shapeblue.com>
>Reply-To: "cloudstack-users@incubator.apache.org"
><cloudstack-users@incubator.apache.org>
>Date: Friday, 22 June 2012 9:00 PM
>To: "cloudstack-users@incubator.apache.org"
><cloudstack-users@incubator.apache.org>
>Subject: Storage Networks XenServer
>
>>Hi
>>
>>I have been trying to get a system up and running using XenServer 6.0.2
>>with multiple physical networks, with one nic dedicated to Storage.
>>
>>There seems to be a lot of contradictory info regarding the use of the
>>storage network, and whether it is for Primary or Secondary storage.
>>
>>The latest admin guide for 3.0.3 states the following
>>
>>
>>Storage Network Topology Requirements
>>The secondary storage NFS export is mounted by the secondary storage VM.
>>Secondary storage traffic goes over the management traffic network,
>>even if there is a separate storage network. Primary storage traffic
>>goes over the storage network, if available. If you choose to place
>>secondary storage NFS servers on the storage network, you must make
>>sure there is a route from the management traffic network to the storage
>>network.
>>
>>And
>>
>>
>>Separate Storage Network for XenServer (Optional)
>>
>>You can optionally set up a separate storage network. This should be
>>done first on the host, before implementing the bonding steps below.
>>This can be done using one or two available NICs. With two NICs bonding
>>may be done as above. It is the administrator's responsibility to set
>>up a separate storage network.
>>
>>
>>
>>Give the storage network a different name-label than what will be given
>>for other networks.
>>
>>For the separate storage network to work correctly, it must be the only
>>interface that can ping the primary storage device's IP address. For
>>example, if eth0 is the management network NIC, ping -I eth0 <primary
>>storage device IP> must fail. In all deployments, secondary storage
>>devices must be pingable from the management network NIC or bond. If a
>>secondary storage device has been placed on the storage network, it
>>must also be pingable via the storage network NIC or bond on the hosts
>>as well.
>>
>>
>>I think it is pretty clear that a "Storage Network" in CloudStack is
>>for Primary Storage, but can optionally be used for Secondary Storage.
>>
>>So I have a test system with single XenServer 6.0.2 Host, with 4
>>physical NICs, and each NIC is assigned a role with the appropriate
>>traffic label eg NIC 0: Management NIC 1: Guest NIC 2: Public NIC 3:
>>Storage
>>
>>The CS Management Server, Host and Secondary Storage are all on the
>>192.168.1.0/24 address range with no VLAN tagging The Primary Storage
>>is on the 172.16.0.0/24 address range with no VLAN tagging
>>
>>Deploying a new Zone works OK, and the System VMs (SSVM and CP) come on
>>line, however uploading templates or ISOs fails.
>>
>>When I log onto the SSVM and try and ping the Secondary Storage IP
>>(192.168.1.100) it fails as there is a ROUTE forcing the traffic over
>>the Storage Network NIC which is a completely different physical network
>>rung
>>on IP Range 172.16.0.0.   If I manually delete the ROUTE then the SSVM
>>can ping the Secondary Storage and the Templates and ISOs upload
>>correctly.
>>
>>Can someone clarify how we should be using the Storage Network ideally
>>with some detailed examples including IPs
>>
>>Thanks
>>
>>Geoff
>>
>>ShapeBlue provides a range of strategic and technical consulting and
>>implementation services to help IT Service Providers and Enterprises to
>>build a true IaaS compute cloud. ShapeBlue's expertise, combined with
>>CloudStack technology, allows IT Service Providers and Enterprises to
>>deliver true, utility based, IaaS to the customer or end-user.
>>
>>________________________________
>>
>>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. 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 provides a range of strategic and technical consulting and
>implementation services to help IT Service Providers and Enterprises to
>build a true IaaS compute cloud. ShapeBlue┬╣s expertise, combined with
>CloudStack technology, allows IT Service Providers and Enterprises to
>deliver true, utility based, IaaS to the customer or end-user.
>
>________________________________
>
>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. 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.



Mime
View raw message