You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Po Dragonwarrior <hu...@gmail.com> on 2020/05/30 05:38:30 UTC
CS networking questions
Hi all,
I am a new cloudstack user and while reading the related documentation some questions came up.
1. As explained in https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/ <https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/> the (Logical) Management Network is used for ' communication between the management server(s) and the system VMs. ‘ which is clear. But, in https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/ <https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/> it is said that 'CloudStack itself requires internal connectivity from the hypervisor host to system VMs (Virtual Routers, SSVM and CPVM) over the link local 169.254.0.0/16 subnet. This is done over a host-only bridge “cloud0”, which is created by CloudStack when the host is added to a CloudStack zone.’
So my question is, if the link local subnet is used for the communication between the hypervisor host and system vms, then the managent ip range address that is declared during the (advanced) zone creation what is it used for? Is it for the communication between the physical host and system vms?…and if so, what kind of traffic is travelling in this ip range?
2. Is it possible for test purposes to deploy cs with advanced zone with the following addressing scheme?
management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
storage ip range: 172.16.0.30 - 172.16.0.40, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
guest ip range. 172.16.0.50 - 172.16.0.60, mask: 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100)
pubic ip range 172.16.0.70 - 172.16.0.80, mask: 255.255.255.0, gw 172.16.0.254, (No VLAN)
3. What would be the best solution for the above addressing scheme?
a. Use two physical network interfaces NIC0: management + storage, NIC1: guest + public
b. Use three physical nics NIC0:management+storage, NIC1:guest, NIC2:public
c. other setup
Re: CS networking questions
Posted by Po Dragonwarrior <hu...@gmail.com>.
Hi Vivek,
thank you very much for your time and effort.
Your answer is very clear!… I will give it a try and report back!
> On 30 May 2020, at 12:40, Vivek Kumar <vi...@indiqus.com.INVALID> wrote:
>
> Hello Po Dragonwarrior-
>
> So when we deploy CloudStack below are the things you should take care -
>
> 1- Management Server (Where you install ACS)
> 2- POD (Where you install your Hypervisor)
> 3- Storage (Primary Storage and Secondary Storage)
>
> Now Let’s talk about networking - You can chose any IP schema for Management, POD and storage but it should be routed through each subject. So your Management network should be reachable to POD network and vice versa. Your Secondary storage (Where we put our templates, ISO, volumes (Uploaded)) should be reachable from Management and POD network.
>
> Your question about Link local IP-
>
> So in XenServer and KVM, It usages Link Local network for connecting the systemVMs and Routers, So when any system VM or router gets deployed on the Hypvervisor, it’s always blank and it needs to be configured as per your deployment and requirement, So ACS will send command to hypervisor and hypverior connect to system vm or router via link local IP then it configured other component inside the router i.e create interface inside the router, adding IPs, executing the scripts which is there in VR/SYSTEMVM. So there are two type of system VM - a) Secondary Storage VM, b) Console proxy VM -
>
> Secondary storage VM needs to communicate with your management server, POD and secondary storage and public Network , that’s why it is having management IP, public IP inside the System VM. So when system VM needs to connect Management, secondary storage or public network it will go via its respective IP. Other Console proxy VM will be responsible to provide you the console of VM over public IP, so it will need to have an Public IP.
>
>
> Now let’s talk about Storage, there are two kind of storage we use in CloudStack -
>
> 1- Primary Storage (which is store your root and data disk, So when you deploy your VM through CloudStack, Your disks will be residing inside the primary storage ). So if you want to use separate network for storage then you should make sure that your hosts are able to access the storage. You can also create a L2 networking from your hypvervisor to storage system, ACS doesn’t bother about this primary storage connectivity it only should be reachable through you hypervisor.
>
> 2- Secondary storage should be reachable from both Management network and POD network.
>
>> 2. Is it possible for test purposes to deploy cs with advanced zone with the following addressing scheme?
>> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
>> storage ip range: 172.16.0.30 - 172.16.0.40, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
>> guest ip range. 172.16.0.50 - 172.16.0.60, mask: 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100)
>> pubic ip range 172.16.0.70 - 172.16.0.80, mask: 255.255.255.0, gw 172.16.0.254, (No VLAN)
>
>
> You really don’t need to define your guest IP range, IN advance networking if you are choosing VLAN based ISOLATION then doesn’t matter what network you use it will always behind your VLAN, That’s why ACS won’t ask you to provide guest IP range, it will only ask you to define your guest Range,
>
>> 3. What would be the best solution for the above addressing scheme?
>> a. Use two physical network interfaces NIC0: management + storage, NIC1: guest + public
>> b. Use three physical nics NIC0:management+storage, NIC1:guest, NIC2:public
>> c. other setup
>
>
> It’s complete depend your requirement, but ideally you should not club you storage traffic with other traffic. So if you have 2 physical NIC, then probably you can use your 1st NIC for Management + Guest + Public and 2nd NIC for storage ( This is primary storage we are talking about,) and if you use 3 NIC then probably NIC 1 for Management and Guest and NIC2 for public and NIC3 for Storage, One small suggestion if you are trying to use separate NIC for storage then put it in different VLAN, i.e 192.168.0.0/24 (You are free to decide what network to choose), So let’s say 192.168.0.10 is your storage IP then put a one free IP on your hosts i.e 192.168.0.20. Make sure NIC3 are connected to the same network as your storage does.
>
>
> Vivek Kumar
> Manager - Cloud & DevOps
> IndiQus Technologies
> 24*7 O +91 11 4055 1411 | M +91 7503460090
> www.indiqus.com <http://indiqus.com/>
>
> This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential and/or privileged. If you are not the intended recipient please delete the original message and any copy of it from your computer system. You are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited unless proper authorization has been obtained for such action. If you have received this communication in error, please notify the sender immediately. Although IndiQus attempts to sweep e-mail and attachments for viruses, it does not guarantee that both are virus-free and accepts no liability for any damage sustained as a result of viruses.
>
>> On 30-May-2020, at 11:08 AM, Po Dragonwarrior <hu...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I am a new cloudstack user and while reading the related documentation some questions came up.
>>
>> 1. As explained in https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/ <https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/> the (Logical) Management Network is used for ' communication between the management server(s) and the system VMs. ‘ which is clear. But, in https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/ <https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/> it is said that 'CloudStack itself requires internal connectivity from the hypervisor host to system VMs (Virtual Routers, SSVM and CPVM) over the link local 169.254.0.0/16 subnet. This is done over a host-only bridge “cloud0”, which is created by CloudStack when the host is added to a CloudStack zone.’
>>
>> So my question is, if the link local subnet is used for the communication between the hypervisor host and system vms, then the managent ip range address that is declared during the (advanced) zone creation what is it used for? Is it for the communication between the physical host and system vms?…and if so, what kind of traffic is travelling in this ip range?
>>
>> 2. Is it possible for test purposes to deploy cs with advanced zone with the following addressing scheme?
>> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
>> storage ip range: 172.16.0.30 - 172.16.0.40, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
>> guest ip range. 172.16.0.50 - 172.16.0.60, mask: 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100)
>> pubic ip range 172.16.0.70 - 172.16.0.80, mask: 255.255.255.0, gw 172.16.0.254, (No VLAN)
>>
>> 3. What would be the best solution for the above addressing scheme?
>> a. Use two physical network interfaces NIC0: management + storage, NIC1: guest + public
>> b. Use three physical nics NIC0:management+storage, NIC1:guest, NIC2:public
>> c. other setup
>>
>>
>
Re: CS networking questions
Posted by Vivek Kumar <vi...@indiqus.com.INVALID>.
Hello Po Dragonwarrior-
So when we deploy CloudStack below are the things you should take care -
1- Management Server (Where you install ACS)
2- POD (Where you install your Hypervisor)
3- Storage (Primary Storage and Secondary Storage)
Now Let’s talk about networking - You can chose any IP schema for Management, POD and storage but it should be routed through each subject. So your Management network should be reachable to POD network and vice versa. Your Secondary storage (Where we put our templates, ISO, volumes (Uploaded)) should be reachable from Management and POD network.
Your question about Link local IP-
So in XenServer and KVM, It usages Link Local network for connecting the systemVMs and Routers, So when any system VM or router gets deployed on the Hypvervisor, it’s always blank and it needs to be configured as per your deployment and requirement, So ACS will send command to hypervisor and hypverior connect to system vm or router via link local IP then it configured other component inside the router i.e create interface inside the router, adding IPs, executing the scripts which is there in VR/SYSTEMVM. So there are two type of system VM - a) Secondary Storage VM, b) Console proxy VM -
Secondary storage VM needs to communicate with your management server, POD and secondary storage and public Network , that’s why it is having management IP, public IP inside the System VM. So when system VM needs to connect Management, secondary storage or public network it will go via its respective IP. Other Console proxy VM will be responsible to provide you the console of VM over public IP, so it will need to have an Public IP.
Now let’s talk about Storage, there are two kind of storage we use in CloudStack -
1- Primary Storage (which is store your root and data disk, So when you deploy your VM through CloudStack, Your disks will be residing inside the primary storage ). So if you want to use separate network for storage then you should make sure that your hosts are able to access the storage. You can also create a L2 networking from your hypvervisor to storage system, ACS doesn’t bother about this primary storage connectivity it only should be reachable through you hypervisor.
2- Secondary storage should be reachable from both Management network and POD network.
> 2. Is it possible for test purposes to deploy cs with advanced zone with the following addressing scheme?
> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
> storage ip range: 172.16.0.30 - 172.16.0.40, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
> guest ip range. 172.16.0.50 - 172.16.0.60, mask: 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100)
> pubic ip range 172.16.0.70 - 172.16.0.80, mask: 255.255.255.0, gw 172.16.0.254, (No VLAN)
You really don’t need to define your guest IP range, IN advance networking if you are choosing VLAN based ISOLATION then doesn’t matter what network you use it will always behind your VLAN, That’s why ACS won’t ask you to provide guest IP range, it will only ask you to define your guest Range,
> 3. What would be the best solution for the above addressing scheme?
> a. Use two physical network interfaces NIC0: management + storage, NIC1: guest + public
> b. Use three physical nics NIC0:management+storage, NIC1:guest, NIC2:public
> c. other setup
It’s complete depend your requirement, but ideally you should not club you storage traffic with other traffic. So if you have 2 physical NIC, then probably you can use your 1st NIC for Management + Guest + Public and 2nd NIC for storage ( This is primary storage we are talking about,) and if you use 3 NIC then probably NIC 1 for Management and Guest and NIC2 for public and NIC3 for Storage, One small suggestion if you are trying to use separate NIC for storage then put it in different VLAN, i.e 192.168.0.0/24 (You are free to decide what network to choose), So let’s say 192.168.0.10 is your storage IP then put a one free IP on your hosts i.e 192.168.0.20. Make sure NIC3 are connected to the same network as your storage does.
Vivek Kumar
Manager - Cloud & DevOps
IndiQus Technologies
24*7 O +91 11 4055 1411 | M +91 7503460090
www.indiqus.com <http://indiqus.com/>
This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential and/or privileged. If you are not the intended recipient please delete the original message and any copy of it from your computer system. You are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited unless proper authorization has been obtained for such action. If you have received this communication in error, please notify the sender immediately. Although IndiQus attempts to sweep e-mail and attachments for viruses, it does not guarantee that both are virus-free and accepts no liability for any damage sustained as a result of viruses.
> On 30-May-2020, at 11:08 AM, Po Dragonwarrior <hu...@gmail.com> wrote:
>
> Hi all,
>
> I am a new cloudstack user and while reading the related documentation some questions came up.
>
> 1. As explained in https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/ <https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/> the (Logical) Management Network is used for ' communication between the management server(s) and the system VMs. ‘ which is clear. But, in https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/ <https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/> it is said that 'CloudStack itself requires internal connectivity from the hypervisor host to system VMs (Virtual Routers, SSVM and CPVM) over the link local 169.254.0.0/16 subnet. This is done over a host-only bridge “cloud0”, which is created by CloudStack when the host is added to a CloudStack zone.’
>
> So my question is, if the link local subnet is used for the communication between the hypervisor host and system vms, then the managent ip range address that is declared during the (advanced) zone creation what is it used for? Is it for the communication between the physical host and system vms?…and if so, what kind of traffic is travelling in this ip range?
>
> 2. Is it possible for test purposes to deploy cs with advanced zone with the following addressing scheme?
> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
> storage ip range: 172.16.0.30 - 172.16.0.40, mask: 255.255.255.0, gw 172.16.0.254 (No VLAN)
> guest ip range. 172.16.0.50 - 172.16.0.60, mask: 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100)
> pubic ip range 172.16.0.70 - 172.16.0.80, mask: 255.255.255.0, gw 172.16.0.254, (No VLAN)
>
> 3. What would be the best solution for the above addressing scheme?
> a. Use two physical network interfaces NIC0: management + storage, NIC1: guest + public
> b. Use three physical nics NIC0:management+storage, NIC1:guest, NIC2:public
> c. other setup
>
>