You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by se...@apache.org on 2014/05/17 09:34:31 UTC
[2/7] split the networking2 file into multiple includes and renamed
it to 'networking_and_traffic': This closes #11
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/9831ca6e/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>