Return-Path: X-Original-To: apmail-cloudstack-commits-archive@www.apache.org Delivered-To: apmail-cloudstack-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3D9C51141B for ; Wed, 10 Sep 2014 06:42:21 +0000 (UTC) Received: (qmail 5523 invoked by uid 500); 10 Sep 2014 06:42:16 -0000 Delivered-To: apmail-cloudstack-commits-archive@cloudstack.apache.org Received: (qmail 5358 invoked by uid 500); 10 Sep 2014 06:42:16 -0000 Mailing-List: contact commits-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list commits@cloudstack.apache.org Received: (qmail 4772 invoked by uid 99); 10 Sep 2014 06:42:16 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Sep 2014 06:42:16 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id C91F7965E; Wed, 10 Sep 2014 06:42:15 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: rajani@apache.org To: commits@cloudstack.apache.org Date: Wed, 10 Sep 2014 06:42:22 -0000 Message-Id: In-Reply-To: <52fdcf6da1f44f26812d5392d47912a3@git.apache.org> References: <52fdcf6da1f44f26812d5392d47912a3@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [08/43] git commit: split the networking2 file into multiple includes and renamed it to 'networking_and_traffic': This closes #11 split the networking2 file into multiple includes and renamed it to 'networking_and_traffic': This closes #11 Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/repo Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/commit/72a3a7c1 Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/tree/72a3a7c1 Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/diff/72a3a7c1 Branch: refs/heads/master Commit: 72a3a7c109c7ef198dc1fe99d91a4dd2ff6791a7 Parents: 5a4a44d Author: Will Stevens Authored: Fri May 16 17:35:52 2014 -0400 Committer: Sebastien Goasguen Committed: Sat May 17 09:35:01 2014 +0200 ---------------------------------------------------------------------- source/index.rst | 2 +- source/networking/acquiring_an_ip_address.rst | 42 + source/networking/advanced_zone_config.rst | 152 + source/networking/basic_zone_config.rst | 24 + source/networking/dns_and_dhcp.rst | 22 + source/networking/elastic_ips.rst | 104 + .../external_firewalls_and_load_balancers.rst | 661 ++ .../networking/global_server_load_balancing.rst | 453 ++ source/networking/guest_ip_ranges.rst | 29 + source/networking/guest_traffic.rst | 50 + source/networking/inter_vlan_routing.rst | 96 + .../ip_forwarding_and_firewalling.rst | 280 + source/networking/ip_load_balancing.rst | 31 + .../ip_reservation_in_guest_networks.rst | 125 + .../isolation_in_advanced_zone_with_vlan.rst | 202 + source/networking/multiple_guest_networks.rst | 207 + source/networking/multiple_ip_ranges.rst | 43 + .../networking/multiple_ips_on_single_nic.rst | 98 + .../multiple_subnets_in_shared_network.rst | 99 + source/networking/networking_in_pod.rst | 45 + source/networking/networking_in_zone.rst | 34 + source/networking/palo_alto_config.rst | 475 ++ source/networking/persistent_networks.rst | 94 + source/networking/portable_ips.rst | 131 + .../public_ips_and_vlans_for_accounts.rst | 154 + source/networking/releasing_an_ip_address.rst | 38 + source/networking/remote_access_vpn.rst | 696 ++ source/networking/security_groups.rst | 214 + source/networking/static_nat.rst | 56 + .../networking/virtual_private_cloud_config.rst | 1438 ++++ source/networking2.rst | 7033 ------------------ source/networking_and_traffic.rst | 82 + source/palo_alto_config.rst | 282 - source/systemvm.rst | 8 +- 34 files changed, 6180 insertions(+), 7320 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/index.rst ---------------------------------------------------------------------- diff --git a/source/index.rst b/source/index.rst index ddfa3bb..cc25dd4 100644 --- a/source/index.rst +++ b/source/index.rst @@ -114,7 +114,7 @@ Managing Networks and Traffic .. toctree:: :maxdepth: 2 - networking2 + networking_and_traffic Managing the Cloud ------------------ http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/acquiring_an_ip_address.rst ---------------------------------------------------------------------- diff --git a/source/networking/acquiring_an_ip_address.rst b/source/networking/acquiring_an_ip_address.rst new file mode 100644 index 0000000..b6556db --- /dev/null +++ b/source/networking/acquiring_an_ip_address.rst @@ -0,0 +1,42 @@ +.. 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. + + +Acquiring a New IP Address +-------------------------- + +#. 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. + + If you want Portable IP click Yes in the confirmation dialog. If you + want a normal Public IP click No. + + For more information on Portable IP, see `"Portable + IPs" <#portable-ips>`_. + + 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. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/advanced_zone_config.rst ---------------------------------------------------------------------- diff --git a/source/networking/advanced_zone_config.rst b/source/networking/advanced_zone_config.rst new file mode 100644 index 0000000..63027b3 --- /dev/null +++ b/source/networking/advanced_zone_config.rst @@ -0,0 +1,152 @@ +.. 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. + + + +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. + + +.. |addguestnetwork.png| image:: /_static/images/add-guest-network.png + :alt: Add Guest network setup in a single zone. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/basic_zone_config.rst ---------------------------------------------------------------------- diff --git a/source/networking/basic_zone_config.rst b/source/networking/basic_zone_config.rst new file mode 100644 index 0000000..a1ba26c --- /dev/null +++ b/source/networking/basic_zone_config.rst @@ -0,0 +1,24 @@ +.. 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. + + + +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. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/dns_and_dhcp.rst ---------------------------------------------------------------------- diff --git a/source/networking/dns_and_dhcp.rst b/source/networking/dns_and_dhcp.rst new file mode 100644 index 0000000..c84cffa --- /dev/null +++ b/source/networking/dns_and_dhcp.rst @@ -0,0 +1,22 @@ +.. 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. + + +DNS and DHCP +------------ + +The Virtual Router provides DNS and DHCP services to the guests. It +proxies DNS requests to the DNS server configured on the Availability +Zone. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/elastic_ips.rst ---------------------------------------------------------------------- diff --git a/source/networking/elastic_ips.rst b/source/networking/elastic_ips.rst new file mode 100644 index 0000000..fe83a3b --- /dev/null +++ b/source/networking/elastic_ips.rst @@ -0,0 +1,104 @@ +.. 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. + + +About Elastic IPs +----------------- + +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" `_. + +.. 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. + + +.. |eip-ns-basiczone.png| image:: /_static/images/eip-ns-basiczone.png + :alt: Elastic IP in a NetScaler-enabled Basic Zone. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/external_firewalls_and_load_balancers.rst ---------------------------------------------------------------------- diff --git a/source/networking/external_firewalls_and_load_balancers.rst b/source/networking/external_firewalls_and_load_balancers.rst new file mode 100644 index 0000000..1652b77 --- /dev/null +++ b/source/networking/external_firewalls_and_load_balancers.rst @@ -0,0 +1,661 @@ +.. 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. + + +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 +summarizes how these variants are treated in CloudStack. + +**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 RHELServer" + <#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. + + +.. |autoscaleateconfig.png| image:: /_static/images/autoscale-config.png + :alt: Configuring AutoScale. +.. |EnableDisable.png| image:: /_static/images/enable-disable-autoscale.png + :alt: button to enable or disable AutoScale. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/global_server_load_balancing.rst ---------------------------------------------------------------------- diff --git a/source/networking/global_server_load_balancing.rst b/source/networking/global_server_load_balancing.rst new file mode 100644 index 0000000..3d88f4d --- /dev/null +++ b/source/networking/global_server_load_balancing.rst @@ -0,0 +1,453 @@ +.. 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. + + +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 and VM6 in Zone-2. Tenant-A +acquires a public IP, IP-1 in Zone-1, and configures a load balancer +rule to load balance the traffic between VM1 and VM2 instances. +CloudStack orchestrates setting up a virtual server on the LB service +provider in Zone-1. Virtual server 1 that is set up on the LB service +provider in Zone-1 represents a publicly accessible virtual server that +client reaches at IP-1. The client traffic to virtual server 1 at IP-1 +will be load balanced across VM1 and VM2 instances. + +Tenant-A acquires another public IP, IP-2 in Zone-2 and sets up a load +balancer rule to load balance the traffic between VM5 and VM6 instances. +Similarly in Zone-2, CloudStack orchestrates setting up a virtual server +on the LB service provider. Virtual server 2 that is setup on the LB +service provider in Zone-2 represents a publicly accessible virtual +server that client reaches at IP-2. The client traffic that reaches +virtual server 2 at IP-2 is load balanced across VM5 and VM6 instances. +At this point Tenant-A has the service enabled in both the zones, but +has no means to set up a disaster recovery plan if one of the zone +fails. Additionally, there is no way for Tenant-A to load balance the +traffic intelligently to one of the zones based on load, proximity and +so on. The cloud administrator of xyztelco provisions a GSLB service +provider to both the zones. A GSLB provider is typically an ADC that has +the ability to act as an ADNS (Authoritative Domain Name Server) and has +the mechanism to monitor health of virtual servers both at local and +remote sites. The cloud admin enables GSLB as a service to the tenants +that use zones 1 and 2. + +|gslb.png| + +Tenant-A wishes to leverage the GSLB service provided by the xyztelco +cloud. Tenant-A configures a GSLB rule to load balance traffic across +virtual server 1 at Zone-1 and virtual server 2 at Zone-2. The domain +name is provided as A.xyztelco.com. CloudStack orchestrates setting up +GSLB virtual server 1 on the GSLB service provider at Zone-1. CloudStack +binds virtual server 1 of Zone-1 and virtual server 2 of Zone-2 to GLSB +virtual server 1. GSLB virtual server 1 is configured to start +monitoring the health of virtual server 1 and 2 in Zone-1. CloudStack +will also orchestrate setting up GSLB virtual server 2 on GSLB service +provider at Zone-2. CloudStack will bind virtual server 1 of Zone-1 and +virtual server 2 of Zone-2 to GLSB virtual server 2. GSLB virtual server +2 is configured to start monitoring the health of virtual server 1 and +2. CloudStack will bind the domain A.xyztelco.com to both the GSLB +virtual server 1 and 2. At this point, Tenant-A service will be globally +reachable at A.xyztelco.com. The private DNS server for the domain +xyztelcom.com is configured by the admin out-of-band to resolve the +domain A.xyztelco.com to the GSLB providers at both the zones, which are +configured as ADNS for the domain A.xyztelco.com. A client when sends a +DNS request to resolve A.xyztelcom.com, will eventually get DNS +delegation to the address of GSLB providers at zone 1 and 2. A client +DNS request will be received by the GSLB provider. The GSLB provider, +depending on the domain for which it needs to resolve, will pick up the +GSLB virtual server associated with the domain. Depending on the health +of the virtual servers being load balanced, DNS request for the domain +will be resolved to the public IP associated with the selected virtual +server. + + +Configuring GSLB +~~~~~~~~~~~~~~~~ + +To configure a GSLB deployment, you must first configure a standard load +balancing setup for each zone. This enables you to balance load across +the different servers in each zone in the region. Then on the NetScaler +side, configure both NetScaler appliances that you plan to add to each +zone as authoritative DNS (ADNS) servers. Next, create a GSLB site for +each zone, configure GSLB virtual servers for each site, create GLSB +services, and bind the GSLB services to the GSLB virtual servers. +Finally, bind the domain to the GSLB virtual servers. The GSLB +configurations on the two appliances at the two different zones are +identical, although each sites load-balancing configuration is specific +to that site. + +Perform the following as a cloud administrator. As per the example given +above, the administrator of xyztelco is the one who sets up GSLB: + +#. In the cloud.dns.name global parameter, specify the DNS name of your + tenant's cloud that make use of the GSLB service. + +#. On the NetScaler side, configure GSLB as given in `Configuring Global + Server Load Balancing + (GSLB) `_: + + #. Configuring a standard load balancing setup. + + #. Configure Authoritative DNS, as explained in `Configuring an + Authoritative DNS + Service `_. + + #. Configure a GSLB site with site name formed from the domain name + details. + + Configure a GSLB site with the site name formed from the domain + name. + + As per the example given above, the site names are A.xyztelco.com + and B.xyztelco.com. + + For more information, see `Configuring a Basic GSLB + Site `_. + + #. Configure a GSLB virtual server. + + For more information, see `Configuring a GSLB Virtual + Server `_. + + #. Configure a GSLB service for each virtual server. + + For more information, see `Configuring a GSLB + Service `_. + + #. Bind the GSLB services to the GSLB virtual server. + + For more information, see `Binding GSLB Services to a GSLB Virtual + Server `_. + + #. Bind domain name to GSLB virtual server. Domain name is obtained + from the domain details. + + For more information, see `Binding a Domain to a GSLB Virtual + Server `_. + +#. In each zone that are participating in GSLB, add GSLB-enabled + NetScaler device. + + For more information, see :ref:`enabling-gslb-in-ns`. + +As a domain administrator/ user perform the following: + +#. Add a GSLB rule on both the sites. + + See ":ref:`adding-gslb-rule`". + +#. Assign load balancer rules. + + See ":ref:`assigning-lb-rule-gslb`". + + +Prerequisites and Guidelines +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- The GSLB functionality is supported both Basic and Advanced zones. + +- GSLB is added as a new network service. + +- GSLB service provider can be added to a physical network in a zone. + +- The admin is allowed to enable or disable GSLB functionality at + region level. + +- The admin is allowed to configure a zone as GSLB capable or enabled. + + A zone shall be considered as GSLB capable only if a GSLB service + provider is provisioned in the zone. + +- When users have VMs deployed in multiple availability zones which are + GSLB enabled, they can use the GSLB functionality to load balance + traffic across the VMs in multiple zones. + +- The users can use GSLB to load balance across the VMs across zones in + a region only if the admin has enabled GSLB in that region. + +- The users can load balance traffic across the availability zones in + the same region or different regions. + +- The admin can configure DNS name for the entire cloud. + +- The users can specify an unique name across the cloud for a globally + load balanced service. The provided name is used as the domain name + under the DNS name associated with the cloud. + + The user-provided name along with the admin-provided DNS name is used + to produce a globally resolvable FQDN for the globally load balanced + service of the user. For example, if the admin has configured + xyztelco.com as the DNS name for the cloud, and user specifies 'foo' + for the GSLB virtual service, then the FQDN name of the GSLB virtual + service is foo.xyztelco.com. + +- While setting up GSLB, users can select a load balancing method, such + as round robin, for using across the zones that are part of GSLB. + +- The user shall be able to set weight to zone-level virtual server. + Weight shall be considered by the load balancing method for + distributing the traffic. + +- The GSLB functionality shall support session persistence, where + series of client requests for particular domain name is sent to a + virtual server on the same zone. + + Statistics is collected from each GSLB virtual server. + + +.. _enabling-gslb-in-ns: + +Enabling GSLB in NetScaler +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In each zone, add GSLB-enabled NetScaler device for load balancing. + +#. Log in as administrator to the CloudStack UI. + +#. In the left navigation bar, click Infrastructure. + +#. In Zones, click View More. + +#. Choose the zone you want to work with. + +#. Click the Physical Network tab, then click the name of the physical + network. + +#. In the Network Service Providers node of the diagram, click + Configure. + + You might have to scroll down to see this. + +#. Click NetScaler. + +#. Click Add NetScaler device and provide the following: + + For NetScaler: + + - **IP Address**: The IP address of the SDX. + + - **Username/Password**: The authentication credentials to access + the device. CloudStack uses these credentials to access the + device. + + - **Type**: The type of device that is being added. It could be F5 + Big Ip Load Balancer, NetScaler VPX, NetScaler MPX, or NetScaler + SDX. For a comparison of the NetScaler types, see the CloudStack + Administration Guide. + + - **Public interface**: Interface of device that is configured to be + part of the public network. + + - **Private interface**: Interface of device that is configured to + be part of the private network. + + - **GSLB service**: Select this option. + + - **GSLB service Public IP**: The public IP address of the NAT + translator for a GSLB service that is on a private network. + + - **GSLB service Private IP**: The private IP of the GSLB service. + + - **Number of Retries**. Number of times to attempt a command on the + device before considering the operation failed. Default is 2. + + - **Capacity**: The number of networks the device can handle. + + - **Dedicated**: When marked as dedicated, this device will be + dedicated to a single account. When Dedicated is checked, the + value in the Capacity field has no significance implicitly, its + value is 1. + +#. Click OK. + + +.. _adding-gslb-rule: + +Adding a GSLB Rule +^^^^^^^^^^^^^^^^^^ + +#. Log in to the CloudStack UI as a domain administrator or user. + +#. In the left navigation pane, click Region. + +#. Select the region for which you want to create a GSLB rule. + +#. In the Details tab, click View GSLB. + +#. Click Add GSLB. + + The Add GSLB page is displayed as follows: + + |gslb-add.png| + +#. Specify the following: + + - **Name**: Name for the GSLB rule. + + - **Description**: (Optional) A short description of the GSLB rule + that can be displayed to users. + + - **GSLB Domain Name**: A preferred domain name for the service. + + - **Algorithm**: (Optional) The algorithm to use to load balance the + traffic across the zones. The options are Round Robin, Least + Connection, and Proximity. + + - **Service Type**: The transport protocol to use for GSLB. The + options are TCP and UDP. + + - **Domain**: (Optional) The domain for which you want to create the + GSLB rule. + + - **Account**: (Optional) The account on which you want to apply the + GSLB rule. + +#. Click OK to confirm. + + +.. _assigning-lb-rule-gslb: + +Assigning Load Balancing Rules to GSLB +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +#. Log in to the CloudStack UI as a domain administrator or user. + +#. In the left navigation pane, click Region. + +#. Select the region for which you want to create a GSLB rule. + +#. In the Details tab, click View GSLB. + +#. Select the desired GSLB. + +#. Click view assigned load balancing. + +#. Click assign more load balancing. + +#. Select the load balancing rule you have created for the zone. + +#. Click OK to confirm. + + +Known Limitation +~~~~~~~~~~~~~~~~ + +Currently, CloudStack does not support orchestration of services across +the zones. The notion of services and service providers in region are to +be introduced. + + +.. |gslb.png| image:: /_static/images/gslb.png + :alt: GSLB architecture +.. |gslb-add.png| image:: /_static/images/add-gslb.png + :alt: adding a gslb rule. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/guest_ip_ranges.rst ---------------------------------------------------------------------- diff --git a/source/networking/guest_ip_ranges.rst b/source/networking/guest_ip_ranges.rst new file mode 100644 index 0000000..d0edf78 --- /dev/null +++ b/source/networking/guest_ip_ranges.rst @@ -0,0 +1,29 @@ +.. 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. + + +Guest IP Ranges +--------------- + +The IP ranges for guest network traffic are set on a per-account basis +by the user. This allows the users to configure their network in a +fashion that will enable VPN linking between their guest network and +their clients. + +In shared networks in Basic zone and Security Group-enabled Advanced +networks, you will have the flexibility to add multiple guest IP ranges +from different subnets. You can add or remove one IP range at a time. +For more information, see `"About Multiple IP +Ranges" <#about-multiple-ip-ranges>`_. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/guest_traffic.rst ---------------------------------------------------------------------- diff --git a/source/networking/guest_traffic.rst b/source/networking/guest_traffic.rst new file mode 100644 index 0000000..51374d1 --- /dev/null +++ b/source/networking/guest_traffic.rst @@ -0,0 +1,50 @@ +.. 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. + + +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 + + +.. |guest-traffic-setup.png| image:: /_static/images/guest-traffic-setup.png + :alt: Depicts a guest traffic setup http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/inter_vlan_routing.rst ---------------------------------------------------------------------- diff --git a/source/networking/inter_vlan_routing.rst b/source/networking/inter_vlan_routing.rst new file mode 100644 index 0000000..fd651a8 --- /dev/null +++ b/source/networking/inter_vlan_routing.rst @@ -0,0 +1,96 @@ +.. 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. + + +About Inter-VLAN Routing (nTier Apps) +------------------------------------- + +Inter-VLAN Routing (nTier Apps) is the capability to route network +traffic between VLANs. This feature enables you to build Virtual Private +Clouds (VPC), an isolated segment of your cloud, that can hold +multi-tier applications. These tiers are deployed on different VLANs +that can communicate with each other. You provision VLANs to the tiers +your create, and VMs can be deployed on different tiers. The VLANs are +connected to a virtual router, which facilitates communication between +the VMs. In effect, you can segment VMs by means of VLANs into different +networks that can host multi-tier applications, such as Web, +Application, or Database. Such segmentation by means of VLANs logically +separate application VMs for higher security and lower broadcasts, while +remaining physically connected to the same device. + +This feature is supported on XenServer, KVM, and VMware hypervisors. + +The major advantages are: + +- The administrator can deploy a set of VLANs and allow users to deploy + VMs on these VLANs. A guest VLAN is randomly alloted to an account + from a pre-specified set of guest VLANs. All the VMs of a certain + tier of an account reside on the guest VLAN allotted to that account. + + .. note:: + A VLAN allocated for an account cannot be shared between multiple accounts. + +- The administrator can allow users create their own VPC and deploy the + application. In this scenario, the VMs that belong to the account are + deployed on the VLANs allotted to that account. + +- Both administrators and users can create multiple VPCs. The guest + network NIC is plugged to the VPC virtual router when the first VM is + deployed in a tier. + +- The administrator can create the following gateways to send to or + receive traffic from the VMs: + + - **VPN Gateway**: For more information, see `"Creating a VPN gateway for the + VPC" <#creating-a-vpn-gateway-for-the-vpc>`_. + + - **Public Gateway**: The public gateway for a VPC is added to the + virtual router when the virtual router is created for VPC. The + public gateway is not exposed to the end users. You are not + allowed to list it, nor allowed to create any static routes. + + - **Private Gateway**: For more information, see ":ref:`adding-priv-gw-vpc`". + +- Both administrators and users can create various possible + destinations-gateway combinations. However, only one gateway of each + type can be used in a deployment. + + For example: + + - **VLANs and Public Gateway**: For example, an application is + deployed in the cloud, and the Web application VMs communicate + with the Internet. + + - **VLANs, VPN Gateway, and Public Gateway**: For example, an + application is deployed in the cloud; the Web application VMs + communicate with the Internet; and the database VMs communicate + with the on-premise devices. + +- The administrator can define Network Access Control List (ACL) on the + virtual router to filter the traffic among the VLANs or between the + Internet and a VLAN. You can define ACL based on CIDR, port range, + protocol, type code (if ICMP protocol is selected) and Ingress/Egress + type. + +The following figure shows the possible deployment scenarios of a +Inter-VLAN setup: + +|mutltier.png| + +To set up a multi-tier Inter-VLAN deployment, see ":ref:`configuring-vpc`". + + +.. |mutltier.png| image:: /_static/images/multi-tier-app.png + :alt: a multi-tier setup. http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/72a3a7c1/source/networking/ip_forwarding_and_firewalling.rst ---------------------------------------------------------------------- diff --git a/source/networking/ip_forwarding_and_firewalling.rst b/source/networking/ip_forwarding_and_firewalling.rst new file mode 100644 index 0000000..0999eb7 --- /dev/null +++ b/source/networking/ip_forwarding_and_firewalling.rst @@ -0,0 +1,280 @@ +.. 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. + + +IP Forwarding and Firewalling +----------------------------- + +By default, all incoming traffic to the public IP address is rejected. +All outgoing traffic from the guests is also blocked by default. + +To allow outgoing traffic, follow the procedure in :ref:`egress-fw-rules`. + +To allow incoming traffic, users may set up firewall rules and/or port +forwarding rules. For example, you can use a firewall rule to open a +range of ports on the public IP address, such as 33 through 44. Then use +port forwarding rules to direct traffic from individual ports within +that range to specific ports on user VMs. For example, one port +forwarding rule could route incoming traffic on the public IP's port 33 +to port 100 on one user VM's private IP. + + +Firewall Rules +~~~~~~~~~~~~~~ + +By default, all incoming traffic to the public IP address is rejected by +the firewall. To allow external traffic, you can open firewall ports by +specifying firewall rules. You can optionally specify one or more CIDRs +to filter the source IPs. This is useful when you want to allow only +incoming requests from certain IP addresses. + +You cannot use firewall rules to open ports for an elastic IP address. +When elastic IP is used, outside access is instead controlled through +the use of security groups. See `"Adding a Security +Group" <#adding-a-security-group>`_. + +In an advanced zone, you can also create egress firewall rules by using +the virtual router. For more information, see ":ref:`egress-fw-rules`". + +Firewall rules can be created using the Firewall tab in the Management +Server UI. This tab is not displayed by default when CloudStack is +installed. To display the Firewall tab, the CloudStack administrator +must set the global configuration parameter firewall.rule.ui.enabled to +"true." + +To create a firewall 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 work with. + +#. Click View IP Addresses. + +#. Click the IP address you want to work with. + +#. Click the Configuration tab and fill in the following values. + + - **Source CIDR**: (Optional) To accept only traffic from IP + addresses within a particular address block, enter a CIDR or a + comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave + empty to allow all CIDRs. + + - **Protocol**: The communication protocol in use on the opened + port(s). + + - **Start Port and End Port**: The port(s) you want to open on the + firewall. If you are opening a single port, use the same number in + both fields + + - **ICMP Type and ICMP Code**: Used only if Protocol is set to ICMP. + Provide the type and code required by the ICMP protocol to fill + out the ICMP header. Refer to ICMP documentation for more details + if you are not sure what to enter + +#. Click Add. + + +.. _egress-fw-rules: + +Egress Firewall Rules in an Advanced Zone +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The egress traffic originates from a private network to a public +network, such as the Internet. By default, the egress traffic is blocked +in default network offerings, so no outgoing traffic is allowed from a +guest network to the Internet. However, you can control the egress +traffic in an Advanced zone by creating egress firewall rules. When an +egress firewall rule is applied, the traffic specific to the rule is +allowed and the remaining traffic is blocked. When all the firewall +rules are removed the default policy, Block, is applied. + + +Prerequisites and Guidelines +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Consider the following scenarios to apply egress firewall rules: + +- Egress firewall rules are supported on Juniper SRX and virtual + router. + +- The egress firewall rules are not supported on shared networks. + +- Allow the egress traffic from specified source CIDR. The Source CIDR + is part of guest network CIDR. + +- Allow the egress traffic with protocol TCP,UDP,ICMP, or ALL. + +- Allow the egress traffic with protocol and destination port range. + The port range is specified for TCP, UDP or for ICMP type and code. + +- The default policy is Allow for the new network offerings, whereas on + upgrade existing network offerings with firewall service providers + will have the default egress policy Deny. + + +Configuring an Egress Firewall Rule +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +#. Log in to the CloudStack UI as an administrator or end user. + +#. In the left navigation, choose Network. + +#. In Select view, choose Guest networks, then click the Guest network + you want. + +#. 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 guest network: + + |egress-firewall-rule.png| + + - **CIDR**: (Add by CIDR only) To send traffic only to the 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. + + - **Protocol**: The networking protocol that VMs uses to send + outgoing traffic. The TCP and UDP protocols are typically used for + data exchange and end-user communications. The ICMP protocol 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 are sent. + +#. Click Add. + + +Configuring the Default Egress Policy +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default egress policy for Isolated guest network is configured by +using Network offering. Use the create network offering option to +determine whether the default policy should be block or allow all the +traffic to the public network from a guest network. Use this network +offering to create the network. If no policy is specified, by default +all the traffic is allowed from the guest network that you create by +using this network offering. + +You have two options: Allow and Deny. + +Allow +''''' + +If you select Allow for a network offering, by default egress traffic is +allowed. However, when an egress rule is configured for a guest network, +rules are applied to block the specified traffic and rest are allowed. +If no egress rules are configured for the network, egress traffic is +accepted. + +Deny +'''' + +If you select Deny for a network offering, by default egress traffic for +the guest network is blocked. However, when an egress rules is +configured for a guest network, rules are applied to allow the specified +traffic. While implementing a guest network, CloudStack adds the +firewall egress rule specific to the default egress policy for the guest +network. + +This feature is supported only on virtual router and Juniper SRX. + +#. Create a network offering with your desirable default egress policy: + + #. Log in with admin privileges to the CloudStack UI. + + #. In the left navigation bar, click Service Offerings. + + #. In Select Offering, choose Network Offering. + + #. Click Add Network Offering. + + #. In the dialog, make necessary choices, including firewall + provider. + + #. In the Default egress policy field, specify the behaviour. + + #. Click OK. + +#. Create an isolated network by using this network offering. + + Based on your selection, the network will have the egress public + traffic blocked or allowed. + + +Port Forwarding +~~~~~~~~~~~~~~~ + +A port forward service is a set of port forwarding rules that define a +policy. A port forward service is then applied to one or more guest VMs. +The guest VM then has its inbound network access managed according to +the policy defined by the port forwarding service. You can optionally +specify one or more CIDRs to filter the source IPs. This is useful when +you want to allow only incoming requests from certain IP addresses to be +forwarded. + +A guest VM can be in any number of port forward services. Port forward +services can be defined but have no members. If a guest VM is part of +more than one network, port forwarding rules will function only if they +are defined on the default network + +You cannot use port forwarding to open ports for an elastic IP address. +When elastic IP is used, outside access is instead controlled through +the use of security groups. See Security Groups. + +To set up port forwarding: + +#. Log in to the CloudStack UI as an administrator or end user. + +#. If you have not already done so, add a public IP address range to a + zone in CloudStack. See Adding a Zone and Pod in the Installation + Guide. + +#. Add one or more VM instances to CloudStack. + +#. In the left navigation bar, click Network. + +#. Click the name of the guest network where the VMs are running. + +#. Choose an existing IP address or acquire a new IP address. See + `"Acquiring a New IP Address" <#acquiring-a-new-ip-address>`_. + Click the name of the IP address in the list. + +#. Click the Configuration tab. + +#. In the Port Forwarding node of the diagram, click View All. + +#. Fill in the following: + + - **Public Port**: The port to which public traffic will be + addressed on the IP address you acquired in the previous step. + + - **Private Port**: The port on which the instance is listening for + forwarded public traffic. + + - **Protocol**: The communication protocol in use between the two + ports + +#. Click Add. + + +.. |egress-firewall-rule.png| image:: /_static/images/egress-firewall-rule.png + :alt: adding an egress firewall rule.