http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking2.rst ---------------------------------------------------------------------- diff --git a/source/networking2.rst b/source/networking2.rst deleted file mode 100644 index b3743fc..0000000 --- a/source/networking2.rst +++ /dev/null @@ -1,7033 +0,0 @@ -.. Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file - distributed with this work for additional information# - regarding copyright ownership. The ASF licenses this file - to you under the Apache License, Version 2.0 (the - "License"); you may not use this file except in compliance - with the License. You may obtain a copy of the License at - http://www.apache.org/licenses/LICENSE-2.0 - Unless required by applicable law or agreed to in writing, - software distributed under the License is distributed on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the - specific language governing permissions and limitations - under the License. - - -Managing Networks and Traffic -============================= - -In a CloudStack, guest VMs can communicate with each other using shared -infrastructure with the security and user perception that the guests -have a private LAN. The CloudStack virtual router is the main component -providing networking features for guest traffic. - -Guest Traffic -------------- - -A network can carry guest traffic only between VMs within one zone. -Virtual machines in different zones cannot communicate with each other -using their IP addresses; they must communicate with each other by -routing through a public IP address. - -See a typical guest traffic setup given below: - -|guest-traffic-setup.png| - -Typically, the Management Server automatically creates a virtual router -for each network. A virtual router is a special virtual machine that -runs on the hosts. Each virtual router in an isolated network has three -network interfaces. If multiple public VLAN is used, the router will -have multiple public interfaces. Its eth0 interface serves as the -gateway for the guest traffic and has the IP address of 10.1.1.1. Its -eth1 interface is used by the system to configure the virtual router. -Its eth2 interface is assigned a public IP address for public traffic. -If multiple public VLAN is used, the router will have multiple public -interfaces. - -The virtual router provides DHCP and will automatically assign an IP -address for each guest VM within the IP range assigned for the network. -The user can manually reconfigure guest VMs to assume different IP -addresses. - -Source NAT is automatically configured in the virtual router to forward -outbound traffic for all guest VMs - -Networking in a Pod -------------------- - -The figure below illustrates network setup within a single pod. The -hosts are connected to a pod-level switch. At a minimum, the hosts -should have one physical uplink to each switch. Bonded NICs are -supported as well. The pod-level switch is a pair of redundant gigabit -switches with 10 G uplinks. - -|networksinglepod.png| - -Servers are connected as follows: - -- - - Storage devices are connected to only the network that carries - management traffic. - -- - - Hosts are connected to networks for both management traffic and - public traffic. - -- - - Hosts are also connected to one or more networks carrying guest - traffic. - -We recommend the use of multiple physical Ethernet cards to implement -each network interface as well as redundant switch fabric in order to -maximize throughput and improve reliability. - -Networking in a Zone --------------------- - -The following figure illustrates the network setup within a single zone. - -|networksetupzone.png| - -A firewall for management traffic operates in the NAT mode. The network -typically is assigned IP addresses in the 192.168.0.0/16 Class B private -address space. Each pod is assigned IP addresses in the 192.168.\*.0/24 -Class C private address space. - -Each zone has its own set of public IP addresses. Public IP addresses -from different zones do not overlap. - -Basic Zone Physical Network Configuration ------------------------------------------ - -In a basic network, configuring the physical network is fairly -straightforward. You only need to configure one guest network to carry -traffic that is generated by guest VMs. When you first add a zone to -CloudStack, you set up the guest network through the Add Zone screens. - -Advanced Zone Physical Network Configuration --------------------------------------------- - -Within a zone that uses advanced networking, you need to tell the -Management Server how the physical network is set up to carry different -kinds of traffic in isolation. - -Configure Guest Traffic in an Advanced Zone -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -These steps assume you have already logged in to the CloudStack UI. To -configure the base guest network: - -#. - - In the left navigation, choose Infrastructure. On Zones, click View - More, then click the zone to which you want to add a network. - -#. - - Click the Network tab. - -#. - - Click Add guest network. - - The Add guest network window is displayed: - - |addguestnetwork.png| - -#. - - Provide the following information: - - - - - **Name**. The name of the network. This will be user-visible - - - - - **Display Text**: The description of the network. This will be - user-visible - - - - - **Zone**: The zone in which you are configuring the guest network. - - - - - **Network offering**: If the administrator has configured multiple - network offerings, select the one you want to use for this network - - - - - **Guest Gateway**: The gateway that the guests should use - - - - - **Guest Netmask**: The netmask in use on the subnet the guests - will use - -#. - - Click OK. - -Configure Public Traffic in an Advanced Zone -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In a zone that uses advanced networking, you need to configure at least -one range of IP addresses for Internet traffic. - -Configuring a Shared Guest Network -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as administrator. - -#. - - In the left navigation, choose Infrastructure. - -#. - - On Zones, click View More. - -#. - - Click the zone to which you want to add a guest network. - -#. - - Click the Physical Network tab. - -#. - - Click the physical network you want to work with. - -#. - - On the Guest node of the diagram, click Configure. - -#. - - Click the Network tab. - -#. - - Click Add guest network. - - The Add guest network window is displayed. - -#. - - Specify the following: - - - - - **Name**: The name of the network. This will be visible to the - user. - - - - - **Description**: The short description of the network that can be - displayed to users. - - - - - **VLAN ID**: The unique ID of the VLAN. - - - - - **Isolated VLAN ID**: The unique ID of the Secondary Isolated - VLAN. - - - - - **Scope**: The available scopes are Domain, Account, Project, and - All. - - - - - **Domain**: Selecting Domain limits the scope of this guest - network to the domain you specify. The network will not be - available for other domains. If you select Subdomain Access, - the guest network is available to all the sub domains within - the selected domain. - - - - - **Account**: The account for which the guest network is being - created for. You must specify the domain the account belongs - to. - - - - - **Project**: The project for which the guest network is being - created for. You must specify the domain the project belongs - to. - - - - - **All**: The guest network is available for all the domains, - account, projects within the selected zone. - - - - - **Network Offering**: If the administrator has configured multiple - network offerings, select the one you want to use for this - network. - - - - - **Gateway**: The gateway that the guests should use. - - - - - **Netmask**: The netmask in use on the subnet the guests will use. - - - - - **IP Range**: A range of IP addresses that are accessible from the - Internet and are assigned to the guest VMs. - - If one NIC is used, these IPs should be in the same CIDR in the - case of IPv6. - - - - - **IPv6 CIDR**: The network prefix that defines the guest network - subnet. This is the CIDR that describes the IPv6 addresses in use - in the guest networks in this zone. To allot IP addresses from - within a particular address block, enter a CIDR. - - - - - **Network Domain**: A custom DNS suffix at the level of a network. - If you want to assign a special domain name to the guest VM - network, specify a DNS suffix. - -#. - - Click OK to confirm. - -Using Multiple Guest Networks ------------------------------ - -In zones that use advanced networking, additional networks for guest -traffic may be added at any time after the initial installation. You can -also customize the domain name associated with the network by specifying -a DNS suffix for each network. - -A VM's networks are defined at VM creation time. A VM cannot add or -remove networks after it has been created, although the user can go into -the guest and remove the IP address from the NIC on a particular -network. - -Each VM has just one default network. The virtual router's DHCP reply -will set the guest's default gateway as that for the default network. -Multiple non-default networks may be added to a guest in addition to the -single, required default network. The administrator can control which -networks are available as the default network. - -Additional networks can either be available to all accounts or be -assigned to a specific account. Networks that are available to all -accounts are zone-wide. Any user with access to the zone can create a VM -with access to that network. These zone-wide networks provide little or -no isolation between guests.Networks that are assigned to a specific -account provide strong isolation. - -Adding an Additional Guest Network -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network. - -#. - - Click Add guest network. Provide the following information: - - - - - **Name**: The name of the network. This will be user-visible. - - - - - **Display Text**: The description of the network. This will be - user-visible. - - - - - **Zone**. The name of the zone this network applies to. Each zone - is a broadcast domain, and therefore each zone has a different IP - range for the guest network. The administrator must configure the - IP range for each zone. - - - - - **Network offering**: If the administrator has configured multiple - network offerings, select the one you want to use for this - network. - - - - - **Guest Gateway**: The gateway that the guests should use. - - - - - **Guest Netmask**: The netmask in use on the subnet the guests - will use. - -#. - - Click Create. - -Reconfiguring Networks in VMs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -CloudStack provides you the ability to move VMs between networks and -reconfigure a VM's network. You can remove a VM from a network and add -to a new network. You can also change the default network of a virtual -machine. With this functionality, hybrid or traditional server loads can -be accommodated with ease. - -This feature is supported on XenServer, VMware, and KVM hypervisors. - -Prerequisites -^^^^^^^^^^^^^ - -Ensure that vm-tools are running on guest VMs for adding or removing -networks to work on VMware hypervisor. - -Adding a Network -^^^^^^^^^^^^^^^^ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, click Instances. - -#. - - Choose the VM that you want to work with. - -#. - - Click the NICs tab. - -#. - - Click Add network to VM. - - The Add network to VM dialog is displayed. - -#. - - In the drop-down list, select the network that you would like to add - this VM to. - - A new NIC is added for this network. You can view the following - details in the NICs page: - - - - - ID - - - - - Network Name - - - - - Type - - - - - IP Address - - - - - Gateway - - - - - Netmask - - - - - Is default - - - - - CIDR (for IPv6) - -Removing a Network -^^^^^^^^^^^^^^^^^^ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, click Instances. - -#. - - Choose the VM that you want to work with. - -#. - - Click the NICs tab. - -#. - - Locate the NIC you want to remove. - -#. - - Click Remove NIC button. |remove-nic.png| - -#. - - Click Yes to confirm. - -Selecting the Default Network -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, click Instances. - -#. - - Choose the VM that you want to work with. - -#. - - Click the NICs tab. - -#. - - Locate the NIC you want to work with. - -#. - - Click the Set default NIC button. |set-default-nic.png|. - -#. - - Click Yes to confirm. - -Changing the Network Offering on a Guest Network -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -A user or administrator can change the network offering that is -associated with an existing guest network. - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - If you are changing from a network offering that uses the CloudStack - virtual router to one that uses external devices as network service - providers, you must first stop all the VMs on the network. - -#. - - In the left navigation, choose Network. - -#. - - Click the name of the network you want to modify. - -#. - - In the Details tab, click Edit. |edit-icon.png| - -#. - - In Network Offering, choose the new network offering, then click - Apply. - - A prompt is displayed asking whether you want to keep the existing - CIDR. This is to let you know that if you change the network - offering, the CIDR will be affected. - - If you upgrade between virtual router as a provider and an external - network device as provider, acknowledge the change of CIDR to - continue, so choose Yes. - -#. - - Wait for the update to complete. Don't try to restart VMs until the - network change is complete. - -#. - - If you stopped any VMs, restart them. - -IP Reservation in Isolated Guest Networks ------------------------------------------ - -In isolated guest networks, a part of the guest IP address space can be -reserved for non-CloudStack VMs or physical servers. To do so, you -configure a range of Reserved IP addresses by specifying the CIDR when a -guest network is in Implemented state. If your customers wish to have -non-CloudStack controlled VMs or physical servers on the same network, -they can share a part of the IP address space that is primarily provided -to the guest network. - -In an Advanced zone, an IP address range or a CIDR is assigned to a -network when the network is defined. The CloudStack virtual router acts -as the DHCP server and uses CIDR for assigning IP addresses to the guest -VMs. If you decide to reserve CIDR for non-CloudStack purposes, you can -specify a part of the IP address range or the CIDR that should only be -allocated by the DHCP service of the virtual router to the guest VMs -created in CloudStack. The remaining IPs in that network are called -Reserved IP Range. When IP reservation is configured, the administrator -can add additional VMs or physical servers that are not part of -CloudStack to the same network and assign them the Reserved IP -addresses. CloudStack guest VMs cannot acquire IPs from the Reserved IP -Range. - -IP Reservation Considerations -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Consider the following before you reserve an IP range for non-CloudStack -machines: - -- - - IP Reservation is supported only in Isolated networks. - -- - - IP Reservation can be applied only when the network is in Implemented - state. - -- - - No IP Reservation is done by default. - -- - - Guest VM CIDR you specify must be a subset of the network CIDR. - -- - - Specify a valid Guest VM CIDR. IP Reservation is applied only if no - active IPs exist outside the Guest VM CIDR. - - You cannot apply IP Reservation if any VM is alloted with an IP - address that is outside the Guest VM CIDR. - -- - - To reset an existing IP Reservation, apply IP reservation by - specifying the value of network CIDR in the CIDR field. - - For example, the following table describes three scenarios of guest - network creation: - - ===== ============= =============== =========================================== ======================================================== - Case CIDR Network CIDR Reserved IP Range for Non-CloudStack VMs Description - ===== ============= =============== =========================================== ======================================================== - 1 10.1.1.0/24 None None No IP Reservation. - 2 10.1.1.0/26 10.1.1.0/24 10.1.1.64 to 10.1.1.254 IP Reservation configured by the UpdateNetwork API with - guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR - field in the UI. - 3 10.1.1.0/24 None None Removing IP Reservation by the UpdateNetwork API with - guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR - field in the UI. - ===== ============= =============== =========================================== ======================================================== - -Limitations -~~~~~~~~~~~ - -- - - The IP Reservation is not supported if active IPs that are found - outside the Guest VM CIDR. - -- - - Upgrading network offering which causes a change in CIDR (such as - upgrading an offering with no external devices to one with external - devices) IP Reservation becomes void if any. Reconfigure IP - Reservation in the new re-implemeted network. - -Best Practices -~~~~~~~~~~~~~~ - -Apply IP Reservation to the guest network as soon as the network state -changes to Implemented. If you apply reservation soon after the first -guest VM is deployed, lesser conflicts occurs while applying -reservation. - -Reserving an IP Range -~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network. - -#. - - Click the name of the network you want to modify. - -#. - - In the Details tab, click Edit. |edit-icon.png| - - The CIDR field changes to editable one. - -#. - - In CIDR, specify the Guest VM CIDR. - -#. - - Click Apply. - - Wait for the update to complete. The Network CIDR and the Reserved IP - Range are displayed on the Details page. - -Reserving Public IP Addresses and VLANs for Accounts ----------------------------------------------------- - -CloudStack provides you the ability to reserve a set of public IP -addresses and VLANs exclusively for an account. During zone creation, -you can continue defining a set of VLANs and multiple public IP ranges. -This feature extends the functionality to enable you to dedicate a fixed -set of VLANs and guest IP addresses for a tenant. - -Note that if an account has consumed all the VLANs and IPs dedicated to -it, the account can acquire two more resources from the system. -CloudStack provides the root admin with two configuration parameter to -modify this default behavior: use.system.public.ips and -use.system.guest.vlans. These global parameters enable the root admin to -disallow an account from acquiring public IPs and guest VLANs from the -system, if the account has dedicated resources and these dedicated -resources have all been consumed. Both these configurations are -configurable at the account level. - -This feature provides you the following capabilities: - -- - - Reserve a VLAN range and public IP address range from an Advanced - zone and assign it to an account - -- - - Disassociate a VLAN and public IP address range from an account - -- - - View the number of public IP addresses allocated to an account - -- - - Check whether the required range is available and is conforms to - account limits. - - The maximum IPs per account limit cannot be superseded. - -Dedicating IP Address Ranges to an Account -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as administrator. - -#. - - In the left navigation bar, click Infrastructure. - -#. - - In Zones, click View All. - -#. - - Choose the zone you want to work with. - -#. - - Click the Physical Network tab. - -#. - - In the Public node of the diagram, click Configure. - -#. - - Click the IP Ranges tab. - - You can either assign an existing IP range to an account, or create a - new IP range and assign to an account. - -#. - - To assign an existing IP range to an account, perform the following: - - #. - - Locate the IP range you want to work with. - - #. - - Click Add Account |addAccount-icon.png| button. - - The Add Account dialog is displayed. - - #. - - Specify the following: - - - - - **Account**: The account to which you want to assign the IP - address range. - - - - - **Domain**: The domain associated with the account. - - To create a new IP range and assign an account, perform the - following: - - #. - - Specify the following: - - - - - **Gateway** - - - - - **Netmask** - - - - - **VLAN** - - - - - **Start IP** - - - - - **End IP** - - - - - **Account**: Perform the following: - - #. - - Click Account. - - The Add Account page is displayed. - - #. - - Specify the following: - - - - - ****Account****: The account to which you want to - assign an IP address range. - - - - - ****Domain****: The domain associated with the - account. - - #. - - Click OK. - - #. - - Click Add. - -Dedicating VLAN Ranges to an Account -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - After the CloudStack Management Server is installed, log in to the - CloudStack UI as administrator. - -#. - - In the left navigation bar, click Infrastructure. - -#. - - In Zones, click View All. - -#. - - Choose the zone you want to work with. - -#. - - Click the Physical Network tab. - -#. - - In the Guest node of the diagram, click Configure. - -#. - - Select the Dedicated VLAN Ranges tab. - -#. - - Click Dedicate VLAN Range. - - The Dedicate VLAN Range dialog is displayed. - -#. - - Specify the following: - - - - - ****VLAN Range****: The VLAN range that you want to assign to an - account. - - - - - ****Account****: The account to which you want to assign the - selected VLAN range. - - - - - ****Domain****: The domain associated with the account. - -Configuring Multiple IP Addresses on a Single NIC -------------------------------------------------- - -CloudStack provides you the ability to associate multiple private IP -addresses per guest VM NIC. In addition to the primary IP, you can -assign additional IPs to the guest VM NIC. This feature is supported on -all the network configurations: Basic, Advanced, and VPC. Security -Groups, Static NAT and Port forwarding services are supported on these -additional IPs. - -As always, you can specify an IP from the guest subnet; if not -specified, an IP is automatically picked up from the guest VM subnet. -You can view the IPs associated with for each guest VM NICs on the UI. -You can apply NAT on these additional guest IPs by using network -configuration option in the CloudStack UI. You must specify the NIC to -which the IP should be associated. - -This feature is supported on XenServer, KVM, and VMware hypervisors. -Note that Basic zone security groups are not supported on VMware. - -Use Cases -~~~~~~~~~ - -Some of the use cases are described below: - -- - - Network devices, such as firewalls and load balancers, generally work - best when they have access to multiple IP addresses on the network - interface. - -- - - Moving private IP addresses between interfaces or instances. - Applications that are bound to specific IP addresses can be moved - between instances. - -- - - Hosting multiple SSL Websites on a single instance. You can install - multiple SSL certificates on a single instance, each associated with - a distinct IP address. - -Guidelines -~~~~~~~~~~ - -To prevent IP conflict, configure different subnets when multiple -networks are connected to the same VM. - -Assigning Additional IPs to a VM -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI. - -#. - - In the left navigation bar, click Instances. - -#. - - Click the name of the instance you want to work with. - -#. - - In the Details tab, click NICs. - -#. - - Click View Secondary IPs. - -#. - - Click Acquire New Secondary IP, and click Yes in the confirmation - dialog. - - You need to configure the IP on the guest VM NIC manually. CloudStack - will not automatically configure the acquired IP address on the VM. - Ensure that the IP address configuration persist on VM reboot. - - Within a few moments, the new IP address should appear with the state - Allocated. You can now use the IP address in Port Forwarding or - StaticNAT rules. - -Port Forwarding and StaticNAT Services Changes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because multiple IPs can be associated per NIC, you are allowed to -select a desired IP for the Port Forwarding and StaticNAT services. The -default is the primary IP. To enable this functionality, an extra -optional parameter 'vmguestip' is added to the Port forwarding and -StaticNAT APIs (enableStaticNat, createIpForwardingRule) to indicate on -what IP address NAT need to be configured. If vmguestip is passed, NAT -is configured on the specified private IP of the VM. if not passed, NAT -is configured on the primary IP of the VM. - -About Multiple IP Ranges ------------------------- - -.. note:: The feature can only be implemented on IPv4 addresses. - -CloudStack provides you with the flexibility to add guest IP ranges from -different subnets in Basic zones and security groups-enabled Advanced -zones. For security groups-enabled Advanced zones, it implies multiple -subnets can be added to the same VLAN. With the addition of this -feature, you will be able to add IP address ranges from the same subnet -or from a different one when IP address are exhausted. This would in -turn allows you to employ higher number of subnets and thus reduce the -address management overhead. To support this feature, the capability of -``createVlanIpRange`` API is extended to add IP ranges also from a -different subnet. - -Ensure that you manually configure the gateway of the new subnet before -adding the IP range. Note that CloudStack supports only one gateway for -a subnet; overlapping subnets are not currently supported. - -Use the ``deleteVlanRange`` API to delete IP ranges. This operation -fails if an IP from the remove range is in use. If the remove range -contains the IP address on which the DHCP server is running, CloudStack -acquires a new IP from the same subnet. If no IP is available in the -subnet, the remove operation fails. - -This feature is supported on KVM, xenServer, and VMware hypervisors. - -About Elastic IP ----------------- - -Elastic IP (EIP) addresses are the IP addresses that are associated with -an account, and act as static IP addresses. The account owner has the -complete control over the Elastic IP addresses that belong to the -account. As an account owner, you can allocate an Elastic IP to a VM of -your choice from the EIP pool of your account. Later if required you can -reassign the IP address to a different VM. This feature is extremely -helpful during VM failure. Instead of replacing the VM which is down, -the IP address can be reassigned to a new VM in your account. - -Similar to the public IP address, Elastic IP addresses are mapped to -their associated private IP addresses by using StaticNAT. The EIP -service is equipped with StaticNAT (1:1) service in an EIP-enabled basic -zone. The default network offering, -DefaultSharedNetscalerEIPandELBNetworkOffering, provides your network -with EIP and ELB network services if a NetScaler device is deployed in -your zone. Consider the following illustration for more details. - -|eip-ns-basiczone.png| - -In the illustration, a NetScaler appliance is the default entry or exit -point for the CloudStack instances, and firewall is the default entry or -exit point for the rest of the data center. Netscaler provides LB -services and staticNAT service to the guest networks. The guest traffic -in the pods and the Management Server are on different subnets / VLANs. -The policy-based routing in the data center core switch sends the public -traffic through the NetScaler, whereas the rest of the data center goes -through the firewall. - -The EIP work flow is as follows: - -- - - When a user VM is deployed, a public IP is automatically acquired - from the pool of public IPs configured in the zone. This IP is owned - by the VM's account. - -- - - Each VM will have its own private IP. When the user VM starts, Static - NAT is provisioned on the NetScaler device by using the Inbound - Network Address Translation (INAT) and Reverse NAT (RNAT) rules - between the public IP and the private IP. - - .. note:: - Inbound NAT (INAT) is a type of NAT supported by NetScaler, in which - the destination IP address is replaced in the packets from the public - network, such as the Internet, with the private IP address of a VM in - the private network. Reverse NAT (RNAT) is a type of NAT supported by - NetScaler, in which the source IP address is replaced in the packets - generated by a VM in the private network with the public IP address. - -- - - This default public IP will be released in two cases: - - - - - When the VM is stopped. When the VM starts, it again receives a - new public IP, not necessarily the same one allocated initially, - from the pool of Public IPs. - - - - - The user acquires a public IP (Elastic IP). This public IP is - associated with the account, but will not be mapped to any private - IP. However, the user can enable Static NAT to associate this IP - to the private IP of a VM in the account. The Static NAT rule for - the public IP can be disabled at any time. When Static NAT is - disabled, a new public IP is allocated from the pool, which is not - necessarily be the same one allocated initially. - -For the deployments where public IPs are limited resources, you have the -flexibility to choose not to allocate a public IP by default. You can -use the Associate Public IP option to turn on or off the automatic -public IP assignment in the EIP-enabled Basic zones. If you turn off the -automatic public IP assignment while creating a network offering, only a -private IP is assigned to a VM when the VM is deployed with that network -offering. Later, the user can acquire an IP for the VM and enable static -NAT. - -For more information on the Associate Public IP option, see -`"Creating a New Network Offering" <networking.html#creating-a-new-network-offering>`_. - -.. note:: - The Associate Public IP feature is designed only for use with user VMs. - The System VMs continue to get both public IP and private by default, - irrespective of the network offering configuration. - -New deployments which use the default shared network offering with EIP -and ELB services to create a shared network in the Basic zone will -continue allocating public IPs to each user VM. - -Portable IPs ------------- - -About Portable IP -~~~~~~~~~~~~~~~~~ - -Portable IPs in CloudStack are region-level pool of IPs, which are -elastic in nature, that can be transferred across geographically -separated zones. As an administrator, you can provision a pool of -portable public IPs at region level and are available for user -consumption. The users can acquire portable IPs if admin has provisioned -portable IPs at the region level they are part of. These IPs can be use -for any service within an advanced zone. You can also use portable IPs -for EIP services in basic zones. - -The salient features of Portable IP are as follows: - -- - - IP is statically allocated - -- - - IP need not be associated with a network - -- - - IP association is transferable across networks - -- - - IP is transferable across both Basic and Advanced zones - -- - - IP is transferable across VPC, non-VPC isolated and shared networks - -- - - Portable IP transfer is available only for static NAT. - -Guidelines -^^^^^^^^^^ - -Before transferring to another network, ensure that no network rules -(Firewall, Static NAT, Port Forwarding, and so on) exist on that -portable IP. - -Configuring Portable IPs -~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, click Regions. - -#. - - Choose the Regions that you want to work with. - -#. - - Click View Portable IP. - -#. - - Click Portable IP Range. - - The Add Portable IP Range window is displayed. - -#. - - Specify the following: - - - - - **Start IP/ End IP**: A range of IP addresses that are accessible - from the Internet and will be allocated to guest VMs. Enter the - first and last IP addresses that define a range that CloudStack - can assign to guest VMs. - - - - - **Gateway**: The gateway in use for the Portable IP addresses you - are configuring. - - - - - **Netmask**: The netmask associated with the Portable IP range. - - - - - **VLAN**: The VLAN that will be used for public traffic. - -#. - - Click OK. - -Acquiring a Portable IP -~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network. - -#. - - Click the name of the network where you want to work with. - -#. - - Click View IP Addresses. - -#. - - Click Acquire New IP. - - The Acquire New IP window is displayed. - -#. - - Specify whether you want cross-zone IP or not. - -#. - - Click Yes in the confirmation dialog. - - Within a few moments, the new IP address should appear with the state - Allocated. You can now use the IP address in port forwarding or - static NAT rules. - -Transferring Portable IP -~~~~~~~~~~~~~~~~~~~~~~~~ - -An IP can be transferred from one network to another only if Static NAT -is enabled. However, when a portable IP is associated with a network, -you can use it for any service in the network. - -To transfer a portable IP across the networks, execute the following -API: - -.. code:: bash - - http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=a242c476-ef37-441e-9c7b-b303e2a9cb4f&networkid=6e7cd8d1-d1ba-4c35-bdaf-333354cbd49810 - -Replace the UUID with appropriate UUID. For example, if you want to -transfer a portable IP to network X and VM Y in a network, execute the -following: - -.. code:: bash - - http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=Y&networkid=X - -Multiple Subnets in Shared Network ----------------------------------- - -CloudStack provides you with the flexibility to add guest IP ranges from -different subnets in Basic zones and security groups-enabled Advanced -zones. For security groups-enabled Advanced zones, it implies multiple -subnets can be added to the same VLAN. With the addition of this -feature, you will be able to add IP address ranges from the same subnet -or from a different one when IP address are exhausted. This would in -turn allows you to employ higher number of subnets and thus reduce the -address management overhead. You can delete the IP ranges you have -added. - -Prerequisites and Guidelines -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- - - This feature can only be implemented: - - - - - on IPv4 addresses - - - - - if virtual router is the DHCP provider - - - - - on KVM, xenServer, and VMware hypervisors - -- - - Manually configure the gateway of the new subnet before adding the IP - range. - -- - - CloudStack supports only one gateway for a subnet; overlapping - subnets are not currently supported - -Adding Multiple Subnets to a Shared Network -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Infrastructure. - -#. - - On Zones, click View More, then click the zone to which you want to - work with.. - -#. - - Click Physical Network. - -#. - - In the Guest node of the diagram, click Configure. - -#. - - Click Networks. - -#. - - Select the networks you want to work with. - -#. - - Click View IP Ranges. - -#. - - Click Add IP Range. - - The Add IP Range dialog is displayed, as follows: - - |add-ip-range.png| - -#. - - Specify the following: - - All the fields are mandatory. - - - - - **Gateway**: The gateway for the tier you create. Ensure that the - gateway is within the Super CIDR range that you specified while - creating the VPC, and is not overlapped with the CIDR of any - existing tier within the VPC. - - - - - **Netmask**: The netmask for the tier you create. - - For example, if the VPC CIDR is 10.0.0.0/16 and the network tier - CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the - netmask of the tier is 255.255.255.0. - - - - - **Start IP/ End IP**: A range of IP addresses that are accessible - from the Internet and will be allocated to guest VMs. Enter the - first and last IP addresses that define a range that CloudStack - can assign to guest VMs . - -#. - - Click OK. - -Isolation in Advanced Zone Using Private VLAN ---------------------------------------------- - -Isolation of guest traffic in shared networks can be achieved by using -Private VLANs (PVLAN). PVLANs provide Layer 2 isolation between ports -within the same VLAN. In a PVLAN-enabled shared network, a user VM -cannot reach other user VM though they can reach the DHCP server and -gateway, this would in turn allow users to control traffic within a -network and help them deploy multiple applications without communication -between application as well as prevent communication with other users' -VMs. - -- - - Isolate VMs in a shared networks by using Private VLANs. - -- - - Supported on KVM, XenServer, and VMware hypervisors - -- - - PVLAN-enabled shared network can be a part of multiple networks of a - guest VM. - -About Private VLAN -~~~~~~~~~~~~~~~~~~ - -In an Ethernet switch, a VLAN is a broadcast domain where hosts can -establish direct communication with each another at Layer 2. Private -VLAN is designed as an extension of VLAN standard to add further -segmentation of the logical broadcast domain. A regular VLAN is a single -broadcast domain, whereas a private VLAN partitions a larger VLAN -broadcast domain into smaller sub-domains. A sub-domain is represented -by a pair of VLANs: a Primary VLAN and a Secondary VLAN. The original -VLAN that is being divided into smaller groups is called Primary, which -implies that all VLAN pairs in a private VLAN share the same Primary -VLAN. All the secondary VLANs exist only inside the Primary. Each -Secondary VLAN has a specific VLAN ID associated to it, which -differentiates one sub-domain from another. - -Three types of ports exist in a private VLAN domain, which essentially -determine the behaviour of the participating hosts. Each ports will have -its own unique set of rules, which regulate a connected host's ability -to communicate with other connected host within the same private VLAN -domain. Configure each host that is part of a PVLAN pair can be by using -one of these three port designation: - -- - - **Promiscuous**: A promiscuous port can communicate with all the - interfaces, including the community and isolated host ports that - belong to the secondary VLANs. In Promiscuous mode, hosts are - connected to promiscuous ports and are able to communicate directly - with resources on both primary and secondary VLAN. Routers, DHCP - servers, and other trusted devices are typically attached to - promiscuous ports. - -- - - **Isolated VLANs**: The ports within an isolated VLAN cannot - communicate with each other at the layer-2 level. The hosts that are - connected to Isolated ports can directly communicate only with the - Promiscuous resources. If your customer device needs to have access - only to a gateway router, attach it to an isolated port. - -- - - **Community VLANs**: The ports within a community VLAN can - communicate with each other and with the promiscuous ports, but they - cannot communicate with the ports in other communities at the layer-2 - level. In a Community mode, direct communication is permitted only - with the hosts in the same community and those that are connected to - the Primary PVLAN in promiscuous mode. If your customer has two - devices that need to be isolated from other customers' devices, but - to be able to communicate among themselves, deploy them in community - ports. - -For further reading: - -- - - `Understanding Private - VLANs <http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swpvlan.html#wp1038379>`_ - -- - - `Cisco Systems' Private VLANs: Scalable Security in a Multi-Client - Environment <http://tools.ietf.org/html/rfc5517>`_ - -- - - `Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept - Overview (1010691) <http://kb.vmware.com>`_ - -Prerequisites -~~~~~~~~~~~~~ - -- - - Use a PVLAN supported switch. - - See `Private VLAN Catalyst Switch Support - Matrix <http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a0080094830.shtml>`_ for - more information. - -- - - All the layer 2 switches, which are PVLAN-aware, are connected to - each other, and one of them is connected to a router. All the ports - connected to the host would be configured in trunk mode. Open - Management VLAN, Primary VLAN (public) and Secondary Isolated VLAN - ports. Configure the switch port connected to the router in PVLAN - promiscuous trunk mode, which would translate an isolated VLAN to - primary VLAN for the PVLAN-unaware router. - - Note that only Cisco Catalyst 4500 has the PVLAN promiscuous trunk - mode to connect both normal VLAN and PVLAN to a PVLAN-unaware switch. - For the other Catalyst PVLAN support switch, connect the switch to - upper switch by using cables, one each for a PVLAN pair. - -- - - Configure private VLAN on your physical switches out-of-band. - -- - - Before you use PVLAN on XenServer and KVM, enable Open vSwitch (OVS). - - .. note:: - OVS on XenServer and KVM does not support PVLAN natively. Therefore, - CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by - modifying the flow table. - -Creating a PVLAN-Enabled Guest Network -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as administrator. - -#. - - In the left navigation, choose Infrastructure. - -#. - - On Zones, click View More. - -#. - - Click the zone to which you want to add a guest network. - -#. - - Click the Physical Network tab. - -#. - - Click the physical network you want to work with. - -#. - - On the Guest node of the diagram, click Configure. - -#. - - Click the Network tab. - -#. - - Click Add guest network. - - The Add guest network window is displayed. - -#. - - Specify the following: - - - - - **Name**: The name of the network. This will be visible to the - user. - - - - - **Description**: The short description of the network that can be - displayed to users. - - - - - **VLAN ID**: The unique ID of the VLAN. - - - - - **Secondary Isolated VLAN ID**: The unique ID of the Secondary - Isolated VLAN. - - For the description on Secondary Isolated VLAN, see - `About Private VLAN" <#about-private-vlan>`_. - - - - - **Scope**: The available scopes are Domain, Account, Project, and - All. - - - - - **Domain**: Selecting Domain limits the scope of this guest - network to the domain you specify. The network will not be - available for other domains. If you select Subdomain Access, - the guest network is available to all the sub domains within - the selected domain. - - - - - **Account**: The account for which the guest network is being - created for. You must specify the domain the account belongs - to. - - - - - **Project**: The project for which the guest network is being - created for. You must specify the domain the project belongs - to. - - - - - **All**: The guest network is available for all the domains, - account, projects within the selected zone. - - - - - **Network Offering**: If the administrator has configured multiple - network offerings, select the one you want to use for this - network. - - - - - **Gateway**: The gateway that the guests should use. - - - - - **Netmask**: The netmask in use on the subnet the guests will use. - - - - - **IP Range**: A range of IP addresses that are accessible from the - Internet and are assigned to the guest VMs. - - - - - **Network Domain**: A custom DNS suffix at the level of a network. - If you want to assign a special domain name to the guest VM - network, specify a DNS suffix. - -#. - - Click OK to confirm. - -Security Groups ---------------- - -About Security Groups -~~~~~~~~~~~~~~~~~~~~~ - -Security groups provide a way to isolate traffic to VMs. A security -group is a group of VMs that filter their incoming and outgoing traffic -according to a set of rules, called ingress and egress rules. These -rules filter network traffic according to the IP address that is -attempting to communicate with the VM. Security groups are particularly -useful in zones that use basic networking, because there is a single -guest network for all guest VMs. In advanced zones, security groups are -supported only on the KVM hypervisor. - -.. note:: - In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs. - -Each CloudStack account comes with a default security group that denies -all inbound traffic and allows all outbound traffic. The default -security group can be modified so that all new VMs inherit some other -desired set of rules. - -Any CloudStack user can set up any number of additional security groups. -When a new VM is launched, it is assigned to the default security group -unless another user-defined security group is specified. A VM can be a -member of any number of security groups. Once a VM is assigned to a -security group, it remains in that group for its entire lifetime; you -can not move a running VM from one security group to another. - -You can modify a security group by deleting or adding any number of -ingress and egress rules. When you do, the new rules apply to all VMs in -the group, whether running or stopped. - -If no ingress rules are specified, then no traffic will be allowed in, -except for responses to any traffic that has been allowed out through an -egress rule. - -Adding a Security Group -~~~~~~~~~~~~~~~~~~~~~~~ - -A user or administrator can define a new security group. - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network - -#. - - In Select view, choose Security Groups. - -#. - - Click Add Security Group. - -#. - - Provide a name and description. - -#. - - Click OK. - - The new security group appears in the Security Groups Details tab. - -#. - - To make the security group useful, continue to Adding Ingress and - Egress Rules to a Security Group. - -Security Groups in Advanced Zones (KVM Only) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -CloudStack provides the ability to use security groups to provide -isolation between guests on a single shared, zone-wide network in an -advanced zone where KVM is the hypervisor. Using security groups in -advanced zones rather than multiple VLANs allows a greater range of -options for setting up guest isolation in a cloud. - -Limitations -^^^^^^^^^^^ - -The following are not supported for this feature: - -- - - Two IP ranges with the same VLAN and different gateway or netmask in - security group-enabled shared network. - -- - - Two IP ranges with the same VLAN and different gateway or netmask in - account-specific shared networks. - -- - - Multiple VLAN ranges in security group-enabled shared network. - -- - - Multiple VLAN ranges in account-specific shared networks. - -Security groups must be enabled in the zone in order for this feature to -be used. - -Enabling Security Groups -~~~~~~~~~~~~~~~~~~~~~~~~ - -In order for security groups to function in a zone, the security groups -feature must first be enabled for the zone. The administrator can do -this when creating a new zone, by selecting a network offering that -includes security groups. The procedure is described in Basic Zone -Configuration in the Advanced Installation Guide. The administrator can -not enable security groups for an existing zone, only when creating a -new zone. - -Adding Ingress and Egress Rules to a Security Group -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network - -#. - - In Select view, choose Security Groups, then click the security group - you want . - -#. - - To add an ingress rule, click the Ingress Rules tab and fill out the - following fields to specify what network traffic is allowed into VM - instances in this security group. If no ingress rules are specified, - then no traffic will be allowed in, except for responses to any - traffic that has been allowed out through an egress rule. - - - - - **Add by CIDR/Account**. Indicate whether the source of the - traffic will be defined by IP address (CIDR) or an existing - security group in a CloudStack account (Account). Choose Account - if you want to allow incoming traffic from all VMs in another - security group - - - - - **Protocol**. The networking protocol that sources will use to - send traffic to the security group. TCP and UDP are typically used - for data exchange and end-user communications. ICMP is typically - used to send error messages or network monitoring data. - - - - - **Start Port, End Port**. (TCP, UDP only) A range of listening - ports that are the destination for the incoming traffic. If you - are opening a single port, use the same number in both fields. - - - - - **ICMP Type, ICMP Code**. (ICMP only) The type of message and - error code that will be accepted. - - - - - **CIDR**. (Add by CIDR only) To accept only traffic from IP - addresses within a particular address block, enter a CIDR or a - comma-separated list of CIDRs. The CIDR is the base IP address of - the incoming traffic. For example, 192.168.0.0/22. To allow all - CIDRs, set to 0.0.0.0/0. - - - - - **Account, Security Group**. (Add by Account only) To accept only - traffic from another security group, enter the CloudStack account - and name of a security group that has already been defined in that - account. To allow traffic between VMs within the security group - you are editing now, enter the same name you used in step 7. - - The following example allows inbound HTTP access from anywhere: - - |httpaccess.png| - -#. - - To add an egress rule, click the Egress Rules tab and fill out the - following fields to specify what type of traffic is allowed to be - sent out of VM instances in this security group. If no egress rules - are specified, then all traffic will be allowed out. Once egress - rules are specified, the following types of traffic are allowed out: - traffic specified in egress rules; queries to DNS and DHCP servers; - and responses to any traffic that has been allowed in through an - ingress rule - - - - - **Add by CIDR/Account**. Indicate whether the destination of the - traffic will be defined by IP address (CIDR) or an existing - security group in a CloudStack account (Account). Choose Account - if you want to allow outgoing traffic to all VMs in another - security group. - - - - - **Protocol**. The networking protocol that VMs will use to send - outgoing traffic. TCP and UDP are typically used for data exchange - and end-user communications. ICMP is typically used to send error - messages or network monitoring data. - - - - - **Start Port, End Port**. (TCP, UDP only) A range of listening - ports that are the destination for the outgoing traffic. If you - are opening a single port, use the same number in both fields. - - - - - **ICMP Type, ICMP Code**. (ICMP only) The type of message and - error code that will be sent - - - - - **CIDR**. (Add by CIDR only) To send traffic only to IP addresses - within a particular address block, enter a CIDR or a - comma-separated list of CIDRs. The CIDR is the base IP address of - the destination. For example, 192.168.0.0/22. To allow all CIDRs, - set to 0.0.0.0/0. - - - - - **Account, Security Group**. (Add by Account only) To allow - traffic to be sent to another security group, enter the CloudStack - account and name of a security group that has already been defined - in that account. To allow traffic between VMs within the security - group you are editing now, enter its name. - -#. - - Click Add. - -External Firewalls and Load Balancers -------------------------------------- - -CloudStack is capable of replacing its Virtual Router with an external -Juniper SRX device and an optional external NetScaler or F5 load -balancer for gateway and load balancing services. In this case, the VMs -use the SRX as their gateway. - -About Using a NetScaler Load Balancer -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Citrix NetScaler is supported as an external network element for load -balancing in zones that use isolated networking in advanced zones. Set -up an external load balancer when you want to provide load balancing -through means other than CloudStack's provided virtual router. - -.. note:: - In a Basic zone, load balancing service is supported only if Elastic IP or Elastic LB services are enabled. - -When NetScaler load balancer is used to provide EIP or ELB services in a -Basic zone, ensure that all guest VM traffic must enter and exit through -the NetScaler device. When inbound traffic goes through the NetScaler -device, traffic is routed by using the NAT protocol depending on the -EIP/ELB configured on the public IP to the private IP. The traffic that -is originated from the guest VMs usually goes through the layer 3 -router. To ensure that outbound traffic goes through NetScaler device -providing EIP/ELB, layer 3 router must have a policy-based routing. A -policy-based route must be set up so that all traffic originated from -the guest VM's are directed to NetScaler device. This is required to -ensure that the outbound traffic from the guest VM's is routed to a -public IP by using NAT.For more information on Elastic IP, see -`"About Elastic IP" <#about-elastic-ip>`_. - -The NetScaler can be set up in direct (outside the firewall) mode. It -must be added before any load balancing rules are deployed on guest VMs -in the zone. - -The functional behavior of the NetScaler with CloudStack is the same as -described in the CloudStack documentation for using an F5 external load -balancer. The only exception is that the F5 supports routing domains, -and NetScaler does not. NetScaler can not yet be used as a firewall. - -To install and enable an external load balancer for CloudStack -management, see External Guest Load Balancer Integration in the -Installation Guide. - -The Citrix NetScaler comes in three varieties. The following table -summarizes how these variants are treated in CloudStack. - -NetScaler ADC Type - -Description of Capabilities - -CloudStack Supported Features - -MPX - -Physical appliance. Capable of deep packet inspection. Can act as -application firewall and load balancer - -In advanced zones, load balancer functionality fully supported without -limitation. In basic zones, static NAT, elastic IP (EIP), and elastic -load balancing (ELB) are also provided. - -VPX - -Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V -hypervisors. Same functionality as MPX - -Supported on ESXi and XenServer. Same functional support as for MPX. -CloudStack will treat VPX and MPX as the same device type. - -SDX - -Physical appliance. Can create multiple fully isolated VPX instances on -a single appliance to support multi-tenant usage - -CloudStack will dynamically provision, configure, and manage the life -cycle of VPX instances on the SDX. Provisioned instances are added into -CloudStack automatically - no manual configuration by the administrator -is required. Once a VPX instance is added into CloudStack, it is treated -the same as a VPX on an ESXi host. - -Configuring SNMP Community String on a RHEL Server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The SNMP Community string is similar to a user id or password that -provides access to a network device, such as router. This string is sent -along with all SNMP requests. If the community string is correct, the -device responds with the requested information. If the community string -is incorrect, the device discards the request and does not respond. - -The NetScaler device uses SNMP to communicate with the VMs. You must -install SNMP and configure SNMP Community string for a secure -communication between the NetScaler device and the RHEL machine. - -#. - - Ensure that you installed SNMP on RedHat. If not, run the following - command: - - .. code:: bash - - yum install net-snmp-utils - -#. - - Edit the /etc/snmp/snmpd.conf file to allow the SNMP polling from the - NetScaler device. - - #. - - Map the community name into a security name (local and mynetwork, - depending on where the request is coming from): - - .. note:: - Use a strong password instead of public when you edit the - following table. - - .. code:: bash - - # sec.name source community - com2sec local localhost public - com2sec mynetwork 0.0.0.0 public - - .. note:: Setting to 0.0.0.0 allows all IPs to poll the NetScaler server. - - #. - - Map the security names into group names: - - .. code:: bash - - # group.name sec.model sec.name - group MyRWGroup v1 local - group MyRWGroup v2c local - group MyROGroup v1 mynetwork - group MyROGroup v2c mynetwork - - #. - - Create a view to allow the groups to have the permission to: - - .. code:: bash - - incl/excl subtree mask view all included .1 - - #. - - Grant access with different write permissions to the two groups to - the view you created. - - .. code:: bash - - # context sec.model sec.level prefix read write notif - access MyROGroup "" any noauth exact all none none - access MyRWGroup "" any noauth exact all all all - -#. - - Unblock SNMP in iptables. - - .. code:: bash - - iptables -A INPUT -p udp --dport 161 -j ACCEPT - -#. - - Start the SNMP service: - - .. code:: bash - - service snmpd start - -#. - - Ensure that the SNMP service is started automatically during the - system startup: - - .. code:: bash - - chkconfig snmpd on - -Initial Setup of External Firewalls and Load Balancers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -When the first VM is created for a new account, CloudStack programs the -external firewall and load balancer to work with the VM. The following -objects are created on the firewall: - -- - - A new logical interface to connect to the account's private VLAN. The - interface IP is always the first IP of the account's private subnet - (e.g. 10.1.1.1). - -- - - A source NAT rule that forwards all outgoing traffic from the - account's private VLAN to the public Internet, using the account's - public IP address as the source address - -- - - A firewall filter counter that measures the number of bytes of - outgoing traffic for the account - -The following objects are created on the load balancer: - -- - - A new VLAN that matches the account's provisioned Zone VLAN - -- - - A self IP for the VLAN. This is always the second IP of the account's - private subnet (e.g. 10.1.1.2). - -Ongoing Configuration of External Firewalls and Load Balancers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Additional user actions (e.g. setting a port forward) will cause further -programming of the firewall and load balancer. A user may request -additional public IP addresses and forward traffic received at these IPs -to specific VMs. This is accomplished by enabling static NAT for a -public IP address, assigning the IP to a VM, and specifying a set of -protocols and port ranges to open. When a static NAT rule is created, -CloudStack programs the zone's external firewall with the following -objects: - -- - - A static NAT rule that maps the public IP address to the private IP - address of a VM. - -- - - A security policy that allows traffic within the set of protocols and - port ranges that are specified. - -- - - A firewall filter counter that measures the number of bytes of - incoming traffic to the public IP. - -The number of incoming and outgoing bytes through source NAT, static -NAT, and load balancing rules is measured and saved on each external -element. This data is collected on a regular basis and stored in the -CloudStack database. - -Load Balancer Rules -~~~~~~~~~~~~~~~~~~~ - -A CloudStack user or administrator may create load balancing rules that -balance traffic received at a public IP to one or more VMs. A user -creates a rule, specifies an algorithm, and assigns the rule to a set of -VMs. - -.. note:: - If you create load balancing rules while using a network service - offering that includes an external load balancer device such as - NetScaler, and later change the network service offering to one that - uses the CloudStack virtual router, you must create a firewall rule on - the virtual router for each of your existing load balancing rules so - that they continue to function. - -.. _adding-lb-rule: - -Adding a Load Balancer Rule -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -#. - - Log in to the CloudStack UI as an administrator or end user. - -#. - - In the left navigation, choose Network. - -#. - - Click the name of the network where you want to load balance the - traffic. - -#. - - Click View IP Addresses. - -#. - - Click the IP address for which you want to create the rule, then - click the Configuration tab. - -#. - - In the Load Balancing node of the diagram, click View All. - - In a Basic zone, you can also create a load balancing rule without - acquiring or selecting an IP address. CloudStack internally assign an - IP when you create the load balancing rule, which is listed in the IP - Addresses page when the rule is created. - - To do that, select the name of the network, then click Add Load - Balancer tab. Continue with #7. - -#. - - Fill in the following: - - - - - **Name**: A name for the load balancer rule. - - - - - **Public Port**: The port receiving incoming traffic to be - balanced. - - - - - **Private Port**: The port that the VMs will use to receive the - traffic. - - - - - **Algorithm**: Choose the load balancing algorithm you want - CloudStack to use. CloudStack supports a variety of well-known - algorithms. If you are not familiar with these choices, you will - find plenty of information about them on the Internet. - - - - - **Stickiness**: (Optional) Click Configure and choose the - algorithm for the stickiness policy. See Sticky Session Policies - for Load Balancer Rules. - - - - - **AutoScale**: Click Configure and complete the AutoScale - configuration as explained in :ref:`conf-autoscale`. - - - - - **Health Check**: (Optional; NetScaler load balancers only) Click - Configure and fill in the characteristics of the health check - policy. See :ref:`health-check`. - - - - - **Ping path (Optional)**: Sequence of destinations to which to - send health check queries. Default: / (all). - - - - - **Response time (Optional)**: How long to wait for a response - from the health check (2 - 60 seconds). Default: 5 seconds. - - - - - **Interval time (Optional)**: Amount of time between health - checks (1 second - 5 minutes). Default value is set in the - global configuration parameter lbrule\_health - check\_time\_interval. - - - - - **Healthy threshold (Optional)**: Number of consecutive health - check successes that are required before declaring an instance - healthy. Default: 2. - - - - - **Unhealthy threshold (Optional)**: Number of consecutive - health check failures that are required before declaring an - instance unhealthy. Default: 10. - -#. - - Click Add VMs, then select two or more VMs that will divide the load - of incoming traffic, and click Apply. - - The new load balancer rule appears in the list. You can repeat these - steps to add more load balancer rules for this IP address. - -Sticky Session Policies for Load Balancer Rules -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sticky sessions are used in Web-based applications to ensure continued -availability of information across the multiple requests in a user's -session. For example, if a shopper is filling a cart, you need to -remember what has been purchased so far. The concept of "stickiness" is -also referred to as persistence or maintaining state. - -Any load balancer rule defined in CloudStack can have a stickiness -policy. The policy consists of a name, stickiness method, and -parameters. The parameters are name-value pairs or flags, which are -defined by the load balancer vendor. The stickiness method could be load -balancer-generated cookie, application-generated cookie, or -source-based. In the source-based method, the source IP address is used -to identify the user and locate the user's stored data. In the other -methods, cookies are used. The cookie generated by the load balancer or -application is included in request and response URLs to create -persistence. The cookie name can be specified by the administrator or -automatically generated. A variety of options are provided to control -the exact behavior of cookies, such as how they are generated and -whether they are cached. - -For the most up to date list of available stickiness methods, see the -CloudStack UI or call listNetworks and check the -SupportedStickinessMethods capability. - -.. _health-check: - -Health Checks for Load Balancer Rules -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -(NetScaler load balancer only; requires NetScaler version 10.0) - -Health checks are used in load-balanced applications to ensure that -requests are forwarded only to running, available services. When -creating a load balancer rule, you can specify a health check policy. -This is in addition to specifying the stickiness policy, algorithm, and -other load balancer rule options. You can configure one health check -policy per load balancer rule. - -Any load balancer rule defined on a NetScaler load balancer in -CloudStack can have a health check policy. The policy consists of a ping -path, thresholds to define "healthy" and "unhealthy" states, health -check frequency, and timeout wait interval. - -When a health check policy is in effect, the load balancer will stop -forwarding requests to any resources that are found to be unhealthy. If -the resource later becomes available again, the periodic health check -will discover it, and the resource will once again be added to the pool -of resources that can receive requests from the load balancer. At any -given time, the most recent result of the health check is displayed in -the UI. For any VM that is attached to a load balancer rule with a -health check configured, the state will be shown as UP or DOWN in the UI -depending on the result of the most recent health check. - -You can delete or modify existing health check policies. - -To configure how often the health check is performed by default, use the -global configuration setting healthcheck.update.interval (default value -is 600 seconds). You can override this value for an individual health -check policy. - -For details on how to set a health check policy using the UI, see -:ref:`adding-lb-rule`. - -.. _conf-autoscale: - -Configuring AutoScale -~~~~~~~~~~~~~~~~~~~~~ - -AutoScaling allows you to scale your back-end services or application -VMs up or down seamlessly and automatically according to the conditions -you define. With AutoScaling enabled, you can ensure that the number of -VMs you are using seamlessly scale up when demand increases, and -automatically decreases when demand subsides. Thus it helps you save -compute costs by terminating underused VMs automatically and launching -new VMs when you need them, without the need for manual intervention. - -NetScaler AutoScaling is designed to seamlessly launch or terminate VMs -based on user-defined conditions. Conditions for triggering a scaleup or -scaledown action can vary from a simple use case like monitoring the CPU -usage of a server to a complex use case of monitoring a combination of -server's responsiveness and its CPU usage. For example, you can -configure AutoScaling to launch an additional VM whenever CPU usage -exceeds 80 percent for 15 minutes, or to remove a VM whenever CPU usage -is less than 20 percent for 30 minutes. - -CloudStack uses the NetScaler load balancer to monitor all aspects of a -system's health and work in unison with CloudStack to initiate scale-up -or scale-down actions. - -.. note:: AutoScale is supported on NetScaler Release 10 Build 74.4006.e and beyond. - -Prerequisites -^^^^^^^^^^^^^ - -Before you configure an AutoScale rule, consider the following: - -- - - Ensure that the necessary template is prepared before configuring - AutoScale. When a VM is deployed by using a template and when it - comes up, the application should be up and running. - - .. note:: - If the application is not running, the NetScaler device considers the - VM as ineffective and continues provisioning the VMs unconditionally - until the resource limit is exhausted. - -- - - Deploy the templates you prepared. Ensure that the applications come - up on the first boot and is ready to take the traffic. Observe the - time requires to deploy the template. Consider this time when you - specify the quiet time while configuring AutoScale. - -- - - The AutoScale feature supports the SNMP counters that can be used to - define conditions for taking scale up or scale down actions. To - monitor the SNMP-based counter, ensure that the SNMP agent is - installed in the template used for creating the AutoScale VMs, and - the SNMP operations work with the configured SNMP community and port - by using standard SNMP managers. For example, see `"Configuring SNMP Community String on a RHEL - Server" <#configuring-snmp-community-string-on-a-rhel-server>`_ to configure SNMP on a RHEL - machine. - -- - - Ensure that the endpointe.url parameter present in the Global - Settings is set to the Management Server API URL. For example, - ``http://10.102.102.22:8080/client/api``. In a multi-node Management - Server deployment, use the virtual IP address configured in the load - balancer for the management server's cluster. Additionally, ensure - that the NetScaler device has access to this IP address to provide - AutoScale support. - - If you update the endpointe.url, disable the AutoScale functionality - of the load balancer rules in the system, then enable them back to - reflect the changes. For more information see :ref:`update-autoscale`. - -- - - If the API Key and Secret Key are regenerated for an AutoScale user, - ensure that the AutoScale functionality of the load balancers that - the user participates in are disabled and then enabled to reflect the - configuration changes in the NetScaler. - -- - - In an advanced Zone, ensure that at least one VM should be present - before configuring a load balancer rule with AutoScale. Having one VM - in the network ensures that the network is in implemented state for - configuring AutoScale. - -Configuration -^^^^^^^^^^^^^ - -Specify the following: - -|autoscaleateconfig.png| - -- - - **Template**: A template consists of a base OS image and application. - A template is used to provision the new instance of an application on - a scaleup action. When a VM is deployed from a template, the VM can - start taking the traffic from the load balancer without any admin - intervention. For example, if the VM is deployed for a Web service, - it should have the Web server running, the database connected, and so - on. - -- - - **Compute offering**: A predefined set of virtual hardware - attributes, including CPU speed, number of CPUs, and RAM size, that - the user can select when creating a new virtual machine instance. - Choose one of the compute offerings to be used while provisioning a - VM instance as part of scaleup action. - -- - - **Min Instance**: The minimum number of active VM instances that is - assigned to a load balancing rule. The active VM instances are the - application instances that are up and serving the traffic, and are - being load balanced. This parameter ensures that a load balancing - rule has at least the configured number of active VM instances are - available to serve the traffic. - - .. note:: - If an application, such as SAP, running on a VM instance is down for - some reason, the VM is then not counted as part of Min Instance - parameter, and the AutoScale feature initiates a scaleup action if - the number of active VM instances is below the configured value. - Similarly, when an application instance comes up from its earlier - down state, this application instance is counted as part of the - active instance count and the AutoScale process initiates a scaledown - action when the active instance count breaches the Max instance - value. - -- - - **Max Instance**: Maximum number of active VM instances that **should - be assigned to**\ a load balancing rule. This parameter defines the - upper limit of active VM instances that can be assigned to a load - balancing rule. - - Specifying a large value for the maximum instance parameter might - result in provisioning large number of VM instances, which in turn - leads to a single load balancing rule exhausting the VM instances - limit specified at the account or domain level. - - .. note:: - If an application, such as SAP, running on a VM instance is down for - some reason, the VM is not counted as part of Max Instance parameter. - So there may be scenarios where the number of VMs provisioned for a - scaleup action might be more than the configured Max Instance value. - Once the application instances in the VMs are up from an earlier down - state, the AutoScale feature starts aligning to the configured Max - Instance value. - -Specify the following scale-up and scale-down policies: - -- - - **Duration**: The duration, in seconds, for which the conditions you - specify must be true to trigger a scaleup action. The conditions - defined should hold true for the entire duration you specify for an - AutoScale action to be invoked. - -- - - **Counter**: The performance counters expose the state of the - monitored instances. By default, CloudStack offers four performance - counters: Three SNMP counters and one NetScaler counter. The SNMP - counters are Linux User CPU, Linux System CPU, and Linux CPU Idle. - The NetScaler counter is ResponseTime. The root administrator can add - additional counters into CloudStack by using the CloudStack API. - -- - - **Operator**: The following five relational operators are supported - in AutoScale feature: Greater than, Less than, Less than or equal to, - Greater than or equal to, and Equal to. - -- - - **Threshold**: Threshold value to be used for the counter. Once the - counter defined above breaches the threshold value, the AutoScale - feature initiates a scaleup or scaledown action. - -- - - **Add**: Click Add to add the condition. - -Additionally, if you want to configure the advanced settings, click Show -advanced settings, and specify the following: - -- - - **Polling interval**: Frequency in which the conditions, combination - of counter, operator and threshold, are to be evaluated before taking - a scale up or down action. The default polling interval is 30 - seconds. - -- - - **Quiet Time**: This is the cool down period after an AutoScale - action is initiated. The time includes the time taken to complete - provisioning a VM instance from its template and the time taken by an - application to be ready to serve traffic. This quiet time allows the - fleet to come up to a stable state before any action can take place. - The default is 300 seconds. - -- - - **Destroy VM Grace Period**: The duration in seconds, after a - scaledown action is initiated, to wait before the VM is destroyed as - part of scaledown action. This is to ensure graceful close of any - pending sessions or transactions being served by the VM marked for - destroy. The default is 120 seconds. - -- - - **Security Groups**: Security groups provide a way to isolate traffic - to the VM instances. A security group is a group of VMs that filter - their incoming and outgoing traffic according to a set of rules, - called ingress and egress rules. These rules filter network traffic - according to the IP address that is attempting to communicate with - the VM. - -- - - **Disk Offerings**: A predefined set of disk size for primary data - storage. - -- - - **SNMP Community**: The SNMP community string to be used by the - NetScaler device to query the configured counter value from the - provisioned VM instances. Default is public. - -- - - **SNMP Port**: The port number on which the SNMP agent that run on - the provisioned VMs is listening. Default port is 161. - -- - - **User**: This is the user that the NetScaler device use to invoke - scaleup and scaledown API calls to the cloud. If no option is - specified, the user who configures AutoScaling is applied. Specify - another user name to override. - -- - - **Apply**: Click Apply to create the AutoScale configuration. - -Disabling and Enabling an AutoScale Configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you want to perform any maintenance operation on the AutoScale VM -instances, disable the AutoScale configuration. When the AutoScale -configuration is disabled, no scaleup or scaledown action is performed. -You can use this downtime for the maintenance activities. To disable the -AutoScale configuration, click the Disable AutoScale |EnableDisable.png| button. - -The button toggles between enable and disable, depending on whether -AutoScale is currently enabled or not. After the maintenance operations -are done, you can enable the AutoScale configuration back. To enable, -open the AutoScale configuration page again, then click the Enable -AutoScale |EnableDisable.png| button. - -.. _update-autoscale: - -Updating an AutoScale Configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can update the various parameters and add or delete the conditions -in a scaleup or scaledown rule. Before you update an AutoScale -configuration, ensure that you disable the AutoScale load balancer rule -by clicking the Disable AutoScale button. - -After you modify the required AutoScale parameters, click Apply. To -apply the new AutoScale policies, open the AutoScale configuration page -again, then click the Enable AutoScale button. - -Runtime Considerations -^^^^^^^^^^^^^^^^^^^^^^ - -- - - An administrator should not assign a VM to a load balancing rule - which is configured for AutoScale. - -- - - Before a VM provisioning is completed if NetScaler is shutdown or - restarted, the provisioned VM cannot be a part of the load balancing - rule though the intent was to assign it to a load balancing rule. To - workaround, rename the AutoScale provisioned VMs based on the rule - name or ID so at any point of time the VMs can be reconciled to its - load balancing rule. - -- - - Making API calls outside the context of AutoScale, such as destroyVM, - on an autoscaled VM leaves the load balancing configuration in an - inconsistent state. Though VM is destroyed from the load balancer - rule, NetScaler continues to show the VM as a service assigned to a - rule. - -Global Server Load Balancing Support ------------------------------------- - -CloudStack supports Global Server Load Balancing (GSLB) functionalities -to provide business continuity, and enable seamless resource movement -within a CloudStack environment. CloudStack achieve this by extending -its functionality of integrating with NetScaler Application Delivery -Controller (ADC), which also provides various GSLB capabilities, such as -disaster recovery and load balancing. The DNS redirection technique is -used to achieve GSLB in CloudStack. - -In order to support this functionality, region level services and -service provider are introduced. A new service 'GSLB' is introduced as a -region level service. The GSLB service provider is introduced that will -provider the GSLB service. Currently, NetScaler is the supported GSLB -provider in CloudStack. GSLB functionality works in an Active-Active -data center environment. - -About Global Server Load Balancing -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Global Server Load Balancing (GSLB) is an extension of load balancing -functionality, which is highly efficient in avoiding downtime. Based on -the nature of deployment, GSLB represents a set of technologies that is -used for various purposes, such as load sharing, disaster recovery, -performance, and legal obligations. With GSLB, workloads can be -distributed across multiple data centers situated at geographically -separated locations. GSLB can also provide an alternate location for -accessing a resource in the event of a failure, or to provide a means of -shifting traffic easily to simplify maintenance, or both. - -Components of GSLB -^^^^^^^^^^^^^^^^^^ - -A typical GSLB environment is comprised of the following components: - -- - - **GSLB Site**: In CloudStack terminology, GSLB sites are represented - by zones that are mapped to data centers, each of which has various - network appliances. Each GSLB site is managed by a NetScaler - appliance that is local to that site. Each of these appliances treats - its own site as the local site and all other sites, managed by other - appliances, as remote sites. It is the central entity in a GSLB - deployment, and is represented by a name and an IP address. - -- - - **GSLB Services**: A GSLB service is typically represented by a load - balancing or content switching virtual server. In a GSLB environment, - you can have a local as well as remote GSLB services. A local GSLB - service represents a local load balancing or content switching - virtual server. A remote GSLB service is the one configured at one of - the other sites in the GSLB setup. At each site in the GSLB setup, - you can create one local GSLB service and any number of remote GSLB - services. - -- - - **GSLB Virtual Servers**: A GSLB virtual server refers to one or more - GSLB services and balances traffic between traffic across the VMs in - multiple zones by using the CloudStack functionality. It evaluates - the configured GSLB methods or algorithms to select a GSLB service to - which to send the client requests. One or more virtual servers from - different zones are bound to the GSLB virtual server. GSLB virtual - server does not have a public IP associated with it, instead it will - have a FQDN DNS name. - -- - - **Load Balancing or Content Switching Virtual Servers**: According to - Citrix NetScaler terminology, a load balancing or content switching - virtual server represents one or many servers on the local network. - Clients send their requests to the load balancing or content - switching virtual server's virtual IP (VIP) address, and the virtual - server balances the load across the local servers. After a GSLB - virtual server selects a GSLB service representing either a local or - a remote load balancing or content switching virtual server, the - client sends the request to that virtual server's VIP address. - -- - - **DNS VIPs**: DNS virtual IP represents a load balancing DNS virtual - server on the GSLB service provider. The DNS requests for domains for - which the GSLB service provider is authoritative can be sent to a DNS - VIP. - -- - - **Authoritative DNS**: ADNS (Authoritative Domain Name Server) is a - service that provides actual answer to DNS queries, such as web site - IP address. In a GSLB environment, an ADNS service responds only to - DNS requests for domains for which the GSLB service provider is - authoritative. When an ADNS service is configured, the service - provider owns that IP address and advertises it. When you create an - ADNS service, the NetScaler responds to DNS queries on the configured - ADNS service IP and port. - -How Does GSLB Works in CloudStack? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Global server load balancing is used to manage the traffic flow to a web -site hosted on two separate zones that ideally are in different -geographic locations. The following is an illustration of how GLSB -functionality is provided in CloudStack: An organization, xyztelco, has -set up a public cloud that spans two zones, Zone-1 and Zone-2, across -geographically separated data centers that are managed by CloudStack. -Tenant-A of the cloud launches a highly available solution by using -xyztelco cloud. For that purpose, they launch two instances each in both -the zones: VM1 and VM2 in Zone-1 and VM5
<TRUNCATED>