CloudPlatform (powered by Apache CloudStack) Version 4.
CloudPlatform (powered by Apache CloudStack) Version 4.2 Installation Guide CloudPlatform (powered by Apache CloudStack) Version 4.2 Installation Guide Revised October 27, 2013 11:15 pm Pacific Author Citrix CloudPlatform © 2013 Citrix Systems, Inc. All rights reserved. Specifications are subject to change without notice. Citrix Systems, Inc., the Citrix logo, Citrix XenServer, Citrix XenCenter, and CloudPlatform are trademarks or registered trademarks of Citrix Systems, Inc.
1. Getting More Information and Help 1.1. Additional Documentation Available ............................................................................... 1.2. Citrix Knowledge Center ............................................................................................... 1.3. Contacting Support ....................................................................................................... 1 1 1 1 2. Concepts 2.1. What Is CloudPlatform? ....................................................
CloudPlatform (powered by Apache CloudStack) Version 4.2 Installation Guide 5.5. Setting Configuration Parameters ................................................................................ 5.5.1. About Configuration Parameters ....................................................................... 5.5.2. Setting Global Configuration Parameters ........................................................... 5.5.3. Setting Local Configuration Parameters ......................................................
8.10.1. Configuring Public Network with a Dedicated NIC for XenServer (Optional) ....... 8.10.2. Configuring Multiple Guest Networks for XenServer (Optional) ........................ 8.10.3. Separate Storage Network for XenServer (Optional) ....................................... 8.10.4. NIC Bonding for XenServer (Optional) ........................................................... 106 106 107 107 9. Installing KVM for CloudPlatform 9.1. System Requirements for KVM Hypervisor Hosts ......................
CloudPlatform (powered by Apache CloudStack) Version 4.2 Installation Guide 11.3.6. Create a Bare Metal Image .......................................................................... 11.3.7. Create a Bare Metal Compute Offering ......................................................... 11.3.8. Create a Bare Metal Network Offering ........................................................... 11.3.9. Set Up the Security Group Agent (Optional) .................................................. 11.3.10.
14.7.7. VMware Topology Requirements .................................................................. 14.7.8. KVM Topology Requirements ....................................................................... 14.8. Guest Network Usage Integration for Traffic Sentinel ................................................ 14.9. Setting Zone VLAN and Running VM Maximums ...................................................... 174 174 174 175 15. Amazon Web Service Interface 15.1.
viii
Chapter 1. Getting More Information and Help 1.1. Additional Documentation Available The following guides are available: • Installation Guide — Covers initial installation of CloudPlatform. It aims to cover in full detail all the steps and requirements to obtain a functioning cloud deployment. At times, this guide mentions additional topics in the context of installation tasks, but does not give full details on every topic.
2
Chapter 2. Concepts 2.1. What Is CloudPlatform? CloudPlatform is a software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudPlatform manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudPlatform to deploy, manage, and configure cloud computing environments. Typical users are service providers and enterprises.
Chapter 2. Concepts Massively Scalable Infrastructure Management CloudPlatform can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
Management Server Overview A more full-featured installation consists of a highly-available multi-node Management Server installation and up to thousands of hosts using any of several advanced networking setups. For information about deployment options, see Chapter 13, Choosing a Deployment Architecture. 2.3.1. Management Server Overview The Management Server is the CloudPlatform software that manages cloud resources.
Chapter 2. Concepts • Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters. • Cluster: A cluster consists of one or more hosts and primary storage. • Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines. • Primary storage is associated with a cluster, and it can also be provisioned on a zone-wide basis. It stores the disk volumes for all the VMs running on hosts in that cluster.
Networking Overview • Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks and providing guest isolation. For more details, see Chapter 14, Network Setup.
8
Chapter 3. Cloud Infrastructure Concepts 3.1. About Regions To increase reliability of the cloud, you can optionally group resources into multiple geographic regions. A region is the largest available organizational unit within a CloudPlatform deployment. A region is made up of several availability zones, where each zone is equivalent to a datacenter. Each region is controlled by its own cluster of Management Servers, running in one of the zones.
Chapter 3. Cloud Infrastructure Concepts The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required). A zone consists of: • One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
About Pods For each zone, the administrator must decide the following. • How many pods to place in a zone. • How many clusters to place in each pod. • How many hosts to place in each cluster. • (Optional) If zone-wide primary storage is being used, decide how many primary storage servers to place in each zone and total capacity for these storage servers. (Supported for KVM and VMware hosts) • How many primary storage servers to place in each cluster and total capacity for these storage servers.
Chapter 3. Cloud Infrastructure Concepts 3.4. About Clusters A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, a set of OVM hosts, or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage.
About Hosts server with CloudPlatform. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters. 3.5. About Hosts A host is a single computer. Hosts provide the computing resources that run guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a host can be a Citrix XenServer server, a Linux KVM-enabled server, or an ESXi server.
Chapter 3. Cloud Infrastructure Concepts • Dell EqualLogic™ for iSCSI • Network Appliances filers for NFS and iSCSI • Scale Computing for NFS If you intend to use only local disk for your installation, you can skip adding separate primary storage. 3.7.
Basic Zone Network Traffic Types type for each network vary depending on whether you are creating a zone with basic networking or advanced networking. A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can: • Add/Remove/Update physical networks in a zone • Configure VLANs on the physical network • Configure a name so the network can be recognized by hypervisors • Configure the service providers (firewalls, load balancers, etc.
Chapter 3. Cloud Infrastructure Concepts you must also configure a network to carry public traffic. CloudPlatform takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone. 3.8.2. Basic Zone Guest IP Addresses When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts. 3.8.3.
Advanced Zone Public IP Addresses 3.8.5. Advanced Zone Public IP Addresses When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
18
Chapter 4. Upgrade Instructions 4.1. Upgrade from 3.0.x to 4.2 Perform the following to upgrade from version 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.0.6, or 3.0.7 to version 4.2. 1. If you are upgrading from 3.0.0 or 3.0.1, ensure that you query your IP address usage records and process them; for example, issue invoices for any usage that you have not yet billed users for. Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types.
Chapter 4. Upgrade Instructions Hypervisor Description OS Type: Debian GNU/Linux 7.0 (32-bit) (or the highest Debian release number available in the dropdown) Extractable: no Password Enabled: no Public: no Featured: no KVM Name: systemvm-kvm-4.2 Description: systemvm-kvm-4.2 URL: http://download.cloud.com/templates/4.2/ systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2 Zone: Choose the zone where this hypervisor is used.
Upgrade from 3.0.x to 4.2 Hypervisor Description Password Enabled: no Public: no Featured: no e. Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful f. If you use more than one type of hypervisor in your cloud, repeat these steps to download the system VM template for each hypervisor type. Warning If you do not repeat the steps for each hypervisor type, the upgrade will fail. 4. (KVM on RHEL 6.0/6.
Chapter 4. Upgrade Instructions 5. Stop all Usage Servers if running. Run this on all Usage Server hosts. # service cloud-usage stop 6. Stop the Management Servers. Run this on all Management Server hosts. # service cloud-management stop 7. On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
Upgrade from 3.0.x to 4.2 Note How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old file, and you need to merge the two files: warning: /etc/cloud.rpmsave/management/components.xml created as /etc/cloudstack/ management/components.xml.rpmnew a. Make a backup copy of your previous version file. For example: (substitute the file name components.xml, db.properties, or server.
Chapter 4. Upgrade Instructions Note After upgrade from 3.0.4 to 4.2, if the usage server fails to restart then copy db.properties from /etc/cloudstack/management to /etc/cloudstack/usage. Then start the Usage Server. 16. (VMware only) If you are upgrading from 3.0.6 or beyond and you have existing clusters, additional steps are required to update the existing vCenter password for each VMware cluster. These steps will not affect running guests in the cloud.
Upgrade from 3.0.x to 4.2 update cloud.vmware_data_center set password = <_ciphertext_from_step_i_> where id = <_id_from_step_v_>; vii. Confirm that the table is updated: select * from cloud.vmware_data_center; c. Start the CloudPlatform Management server service cloudstack-management start 17. (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
Chapter 4. Upgrade Instructions # service libvirtd restart i. Start the agent. # service cloudstack-agent start 18. Log in to the CloudPlatform UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts. Note Troubleshooting: If login fails, clear your browser cache and reload the page. Do not proceed to the next step until the hosts show in Up state.
Upgrade from 3.0.x to 4.2 The content should be like the following: Stopping and starting 1 secondary storage vm(s)... Done stopping and starting secondary storage vm(s) Stopping and starting 1 console proxy vm(s)... Done stopping and starting console proxy vm(s). Stopping and starting 4 running routing vm(s)... Done restarting router(s). c.
Chapter 4. Upgrade Instructions 23. (VMware only) After upgrade, if you want to change a Standard vSwitch zone to a VMware dvSwitch Zone, perform the following: a. Ensure that the Public and Guest traffics are not on the same network as the Management and Storage traffic. b. Set vmware.use.dvswitch to true. c.
Upgrade from 2.2.x to 4.2 Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.2, any existing IP address usage records in the old format will no longer be available. 2. If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2 2.2.14 Release Notes .
Chapter 4. Upgrade Instructions Hypervisor Description Zone: Choose the zone where this hypervisor is used. If your CloudPlatform deployment includes multiple zones running XenServer, choose All Zones to make the template available in all the XenServer zones. Hypervisor: XenServer Format: VHD OS Type: Debian GNU/Linux 7.0 (32-bit) (or the highest Debian release number available in the dropdown) Extractable: no Password Enabled: no Public: no Featured: no KVM Name: systemvm-kvm-4.
Upgrade from 2.2.x to 4.2 Hypervisor Description VMware, choose All Zones to make the template available in all the VMware zones. Hypervisor: VMware Format: OVA OS Type: Debian GNU/Linux 7.0 (32-bit) (or the highest Debian release number available in the dropdown) Extractable: no Password Enabled: no Public: no Featured: no e. Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful f.
Chapter 4. Upgrade Instructions enabled=1 gpgcheck=0 [cloudstack] name=cloudstack baseurl=file:///root/CloudPlatform-4.2.0-1-rhel6.3/6.3 enabled=1 gpgcheck=0 e. Upgrade the host operating system from RHEL 6.0 to 6.3: yum upgrade 6. Stop all Usage Servers if running. Run this on all Usage Server hosts. # service cloud-usage stop 7. Stop the Management Servers. Run this on all Management Server hosts. # service cloud-management stop 8. On the MySQL master, take a backup of the MySQL databases.
Upgrade from 2.2.x to 4.2 12. Choose "U" to upgrade the package. > U 13. If you have made changes to your existing copy of the configuration files components.xml, db.properties, or server.xml in your previous-version CloudPlatform installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.2.
Chapter 4. Upgrade Instructions • (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudPlatform database. Default: password. It is highly recommended that you replace this with a more secure value. 15. Repeat steps 9 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers. 16. Start the first Management Server. Do not start any other Management Server nodes yet.
Upgrade from 2.2.x to 4.2 g. Install a libvirt hook with the following commands: # mkdir /etc/libvirt/hooks # cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu # chmod +x /etc/libvirt/hooks/qemu h. Restart libvirtd. # service libvirtd restart i. Start the agent. # service cloudstack-agent start 19. Log in to the CloudPlatform UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline).
Chapter 4. Upgrade Instructions XenServer or KVM: SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP. Run the following commands on the XenServer or KVM host on which the system VM is present: # ssh -i /root/.ssh/id_rsa.cloud -p 3922 # cat /etc/cloudstack-release The output should be like the following: Cloudstack Release 4.
Upgrade from 2.1.x to 4.2 Note (VMware only) After upgrade, whenever you add a new VMware cluster to a zone that was created with a previous version of CloudPlatform, the fields vCenter host, vCenter Username, vCenter Password, and vCenter Datacenter are required. The Add Cluster dialog in the CloudPlatform user interface incorrectly shows them as optional, and will allow you to proceed with adding the cluster even though these important fields are blank.
Chapter 4. Upgrade Instructions Note In the latest XenServer upgrade procedure, even after putting the master host into maintenance mode, the master host continues to stay as master. Any VMs running on this master will be automatically migrated to other hosts, unless there is only one UP host in the cluster. If there is only one UP host, putting the host into maintenance mode will stop any VMs running on the host. 5. Disconnect the XenServer cluster from CloudPlatform.
Applying Hotfixes to a XenServer Cluster • If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2 or higher, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit). • If you upgraded from XenServer 5.
Chapter 4. Upgrade Instructions xe patch-upload file-name=XS602E015.xsupdate The command displays the UUID of the update file: 33af688e-d18c-493d-922b-ec51ea23cfe9 ii. Repeat the xe patch-upload command for all other XenServer updates: XS602E004.xsupdate, XS602E005.xsupdate. Take a note of the UUIDs of the update files. The UUIDs are required in the next step. b. Apply XenServer hot fixes to master host: xe patch-apply host-uuid= uuid= c.
Applying Hotfixes to a XenServer Cluster 11. You might need to change the OS type settings for VMs running on the upgraded hosts, if any of the following apply: • If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit).
42
Chapter 5. Installation 5.1. Who Should Read This These installation instructions are intended for those who are ready to set up a full production deployment. If you only need to set up a trial installation, you will probably find more detail than you need here. Instead, you might want to start with the Trial Installation Guide.
Chapter 5. Installation 5.3. Minimum System Requirements 5.3.1. Management Server, Database, and Storage System Requirements The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via local disk or NFS. The Management Server may be placed on a virtual machine. • Operating system: • Preferred: RHEL 6.2 or 6.3 64-bit (https://access.redhat.
Hypervisor Compatibility Matrix • All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags. Hosts have additional requirements depending on the hypervisor.
Chapter 5. Installation 5.3.3.2. CloudPlatform 3.x 3.0.0 3.0.1 3.0.2 3.0.3 3.0.4 3.0.5 3.0.6 3.0.7 XenServer No 5.6 No No No No No No No XenServer No 5.6 FP1 No Yes Yes Yes Yes Yes Yes XenServer No 5.6 SP2 No Yes Yes Yes Yes Yes Yes XenServer No 6.0.0 No No No No No No No XenServer Yes 6.0.2 Yes Yes Yes Yes Yes Yes Yes XenServer No 6.1 No No No No No Yes Yes XenServer No 6.2 No No No No No No Yes (3.0.7 Patch C or greater) KVM (RHEL 6.0, 6.
Management Server Installation VMware ESX 5 and vCenter 5 2.1.x 2.2.x No No 5.4. Management Server Installation 5.4.1. Management Server Installation Overview This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud: • A single Management Server node, with MySQL on the same node. • Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
Chapter 5. Installation In RHEL, SELinux is installed and enabled by default. You can verify this with: # rpm -qa | grep selinux b. Set the SELINUX variable in /etc/selinux/config to “permissive”. This ensures that the permissive setting will be maintained after a system reboot. # vi /etc/selinux/config c. Then set SELinux to permissive starting immediately, without requiring a system reboot. # setenforce 0 4. Make sure that the machine can reach the Internet. # ping www.cloudstack.org 5.
Install the Management Server on the First Host server server server server c. 0.xenserver.pool.ntp.org 1.xenserver.pool.ntp.org 2.xenserver.pool.ntp.org 3.xenserver.pool.ntp.org Restart the NTP client. # service ntpd restart d. Make sure NTP will start again upon reboot. # chkconfig ntpd on 7. Repeat all of these steps on every host where the Management Server will be installed. 8. Continue to Section 5.4.3, “Install the Management Server on the First Host”. 5.4.3.
Chapter 5. Installation 4. When the installation is finished, run the following commands to start essential services: # # # # service rpcbind start service nfs start chkconfig nfs on chkconfig rpcbind on 5. Continue to Section 5.4.4, “Install and Configure the Database”. 5.4.4. Install and Configure the Database CloudPlatform uses a MySQL database server to store its data. When you are installing the Management Server on a single node, you can install the MySQL server on the same node if desired.
Install and Configure the Database The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server. innodb_rollback_on_timeout=1 innodb_lock_wait_timeout=600 max_connections=350 log-bin=mysql-bin binlog-format = 'ROW' Note The binlog-format variable is supported in MySQL versions 5.1 and greater. It is not supported in MySQL 5.0.
Chapter 5. Installation 8. Set up the database. The following command creates the cloud user on the database. • In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password. • In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
Install and Configure the Database # yum install mysql-server # chkconfig --level 35 mysqld on 3. Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
Chapter 5. Installation d. Edit the /etc/sysconfig/iptables file and add the following lines at the beginning of the INPUT chain. -A INPUT -p tcp --dport 3306 -j ACCEPT 7. Return to the root shell on your first Management Server. 8. Set up the database. The following command creates the cloud user on the database. • In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password. • In dbhost, provide the hostname or IP address of the database node.
Changing the Default Password Encryption • VPN password • User API secret key • VNC password CloudPlatform uses the Java Simplified Encryption (JASYPT) library. The data values are encrypted and decrypted using a database secret key, which is stored in one of CloudPlatform’s internal properties files along with the database password. The other encrypted values listed above, such as SSH keys, are in the CloudPlatform internal database.
Chapter 5. Installation
In the above default ordering, SHA256Salt is used first for UserPasswordEncoders.
Prepare NFS Shares # mkdir -p /export/primary # mkdir -p /export/secondary 2. To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example: # vi /etc/exports Insert the following line. /export *(rw,async,no_root_squash) 3. Export the /export directory. # exportfs -a 4. On the management server, create a mount point for secondary storage. For example: # mkdir -p /mnt/secondary 5.
Chapter 5. Installation /export *(rw,async,no_root_squash) 3. Export the /export directory. # exportfs -a 4. Edit the /etc/sysconfig/nfs file. # vi /etc/sysconfig/nfs Uncomment the following lines: LOCKD_TCPPORT=32803 LOCKD_UDPPORT=32769 MOUNTD_PORT=892 RQUOTAD_PORT=875 STATD_PORT=662 STATD_OUTGOING_PORT=2020 5. Edit the /etc/sysconfig/iptables file.
Prepare and Start Additional Management Servers Domain = company.com 8. Reboot the Management Server host. Two NFS shares called /export/primary and /export/secondary are now set up. 9. It is recommended that you test to be sure the previous steps have been successful. a. Log in to the hypervisor host. b. Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example: # # # # # c.
Chapter 5. Installation # tar xzf CloudPlatform-VERSION-N-OSVERSION.tar.gz # cd CloudPlatform-VERSION-N-OSVERSION # ./install.sh You should see a few messages as the installer prepares, followed by a list of choices. 4. Choose M to install the Management Server software. > M 5. When the installation is finished, run the following commands to start essential services: # # # # service rpcbind start service nfs start chkconfig nfs on chkconfig rpcbind on 6. Configure the database client.
Prepare the System VM Template Source Port Destination Port Protocol Persistence Required? 80 or 443 8080 (or 20400 with AJP) HTTP (or AJP) Yes 8250 8250 TCP Yes 8096 8096 HTTP No In addition to above settings, the adminstrator is responsible for setting the 'host' global config value from the management server IP to load balancer virtual IP address.
Chapter 5. Installation 2. If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step. When the script has finished, unmount secondary storage and remove the created directory. # umount /mnt/secondary # rmdir /mnt/secondary 3. Repeat these steps for each secondary storage server. 5.4.11.
About Configuration Parameters Field Value management.network.cidr A CIDR that describes the network that the management CIDRs reside on. This variable must be set for deployments that use vSphere. It is recommended to be set for other deployments as well. Example: 192.168.3.0/24. xen.setup.multipath For XenServer nodes, this is a true/false variable that instructs CloudStack to enable iSCSI multipath on the XenServer Hosts when they are added. This defaults to false.
Chapter 5. Installation Field Value to ha_host. Specify the ha.tag value as a host tag when you add a new host to the cloud. 5.5.2. Setting Global Configuration Parameters Use the following steps to set global configuration parameters. These values will be the defaults in effect throughout your CloudPlatform deployment. 1. Log in to the UI as administrator. 2. In the left navigation bar, click Global Settings. 3. In Select View, choose one of the following: • Global Settings.
Granular Global Configuration Parameters Field Field Value account allow.public.user.templates If false, users will not be able to create public templates. account use.system.public.ips If true and if an account has one or more dedicated public IP ranges, IPs are acquired from the system pool after all the IPs dedicated to the account have been consumed. account use.system.guest.
Chapter 5. Installation Field Field Value Keep the corresponding notification threshold lower than this value to be notified beforehand. cluster cpu.overprovisioning.factor Used for CPU overprovisioning calculation; the available CPU will be the mathematical product of actualCpuCapacity and cpu.overprovisioning.factor. cluster mem.overprovisioning.factor Used for memory overprovisioning calculation. cluster vmware.reserve.
Granular Global Configuration Parameters Field Field Value zone router.template.kvm Name of the default router template on KVM. zone router.template.vmware Name of the default router template on VMware. zone enable.dynamic.scale.vm Enable or diable dynamically scaling of a VM. zone use.external.dns Bypass internal DNS, and use the external DNS1 and DNS2 zone blacklisted.routes Routes that are blacklisted cannot be used for creating static routes for a VPC Private Gateway.
68
Chapter 6. User Interface 6.1. Supported Browsers The CloudPlatform web-based UI is available in the following popular browsers: • Mozilla Firefox 22 or greater • Apple Safari, all versions packaged with Mac OS X 10.5 (Leopard) or greater • Google Chrome, all versions starting from the year 2012 • Microsoft Internet Explorer 9 or greater 6.2. Log In to the UI CloudPlatform provides a web-based UI that can be used by both administrators and end users.
Chapter 6. User Interface 6.2.2. Root Administrator's UI Overview The CloudPlatform UI helps the CloudPlatform administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears.
Changing the Root Password Warning You are logging in as the root administrator. This account manages the CloudPlatform deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password. 6.2.4.
Chapter 6. User Interface For more information on creating a new instance, see Creating VMs in the Administration Guide. 2. Download the script file cloud-set-guest-sshkey from the following link: http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-sshkey.in 3. Copy the file to /etc/init.d. 4. Give the necessary permissions on the script: chmod +x /etc/init.d/cloud-set-guest-sshkey 5. Run the script while starting up the operating system: chkconfig --add cloud-set-guest-sshkey 6.
Creating an Instance 2. Copy the key data into a file.
74
Chapter 7. Steps to Provisioning Your Cloud Infrastructure This section tells how to add regions, zones, pods, clusters, hosts, storage, and networks to your cloud. If you are unfamiliar with these entities, please begin by looking through Chapter 3, Cloud Infrastructure Concepts. 7.1. Overview of Provisioning Steps After the Management Server is installed and running, you can add the compute resources for it to manage.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure 7.2. Adding Regions (optional) Grouping your cloud resources into geographic regions is an optional step when provisioning the cloud. For an overview of regions, see Section 3.1, “About Regions”. 7.2.1. The First Region: The Default Region If you do not take action to define regions, then all the zones in your cloud will be automatically grouped into a single default region. This region is assigned the region ID of 1.
Adding Third and Subsequent Regions 3. Now add the new region to region 1 in CloudPlatform. a. Log in to CloudPlatform in the first region as root administrator (that is, log in to :8080/client). b. In the left navigation bar, click Regions. c. Click Add Region. In the dialog, fill in the following fields: • ID. A unique identifying number. Use the same number you set in the database during Management Server installation in the new region; for example, 2. • Name.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure 2. Once the Management Server is running, add your new region to all existing regions by repeatedly using the Add Region button in the UI. For example, if you were adding region 3: a. Log in to CloudPlatform in the first region as root administrator (that is, log in to :8080/client), and add a region with ID 3, the name of region 3, and the endpoint :8080/client. b.
Adding a Zone 2. In the left navigation bar, click Regions. 3. Click the name of the region you want to delete. 4. Click the Remove Region button. 5. Repeat these steps for :8080/client. 7.3. Adding a Zone Adding a zone consists of three phases: • Create a mount point for secondary storage on the Management Server. • Seed the system VM template on the secondary storage. • Add the zone. 7.3.1.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure • Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks and providing custom network offerings such as firewall, VPN, or load balancer support. For more information about the network types, see Network Setup. 7. The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you: • Section 7.3.2.
Steps to Add a New Zone • Public. A public zone is available to all users. A zone that is not public will be assigned to a particular domain. Only users in that domain will be allowed to create guest VMs in this zone. 2. Choose which traffic types will be carried by the physical network. The traffic types are management, public, guest, and storage traffic. For more information about the types, roll over the icons to display their tool tips, or see Basic Zone Network Traffic Types.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure 7. In a new zone, CloudPlatform adds the first pod for you. You can always add more pods later. For an overview of what a pod is, see Section 3.3, “About Pods”. To configure the first pod, enter the following, then click Next: • Pod Name. A name for the pod. • Reserved system gateway. The gateway for the hosts in that pod. • Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR notation. • Start/End Reserved System IP.
Steps to Add a New Zone • Citrix XenServer Installation and Configuration • VMware vSphere Installation and Configuration • KVM vSphere Installation and Configuration • Oracle VM (OVM) Installation and Configuration To configure the first host, enter the following, then click Next: • Host Name. The DNS name or IP address of the host. • Username. The username is root. • Password. This is the password for the user named above (from your XenServer or KVM install). • Host Tags.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure • Hypervisor. Choose the hypervisor for the first cluster in the zone. You can add clusters with different hypervisors later, after you finish adding the zone. • Public. A public zone is available to all users. A zone that is not public will be assigned to a particular domain. Only users in that domain will be allowed to create guest VMs in this zone. 2. Choose which traffic types will be carried by the physical network.
Steps to Add a New Zone 4. Click Next. 5. Configure the IP range for public Internet traffic. Enter the following details, then click Add. If desired, you can repeat this step to add more public Internet IP ranges. When done, click Next. • Gateway. The gateway in use for these IP addresses. • Netmask. The netmask associated with this IP range. • VLAN. The VLAN that will be used for public traffic. • Start IP/End IP.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure • Start/End Reserved System IP. The IP range in the management network that CloudPlatform uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP. For more information, see Section 3.8.6, “System Reserved IP Addresses”. 7. Specify a range of VLAN IDs to carry guest traffic for each physical network (see VLAN Allocation Example ), then click Next. 8. In a new pod, CloudPlatform adds the first cluster for you.
Steps to Add a New Zone more information, see HA-Enabled Virtual Machines as well as HA for Hosts, both in the Administration Guide. 10. In a new cluster, CloudPlatform adds the first primary storage server for you. You can always add more servers later. For an overview of what primary storage is, see Section 3.6, “About Primary Storage”. To configure the first primary storage server, enter the following, then click Next: • Name. The name of the storage device. • Protocol.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure SharedMountPoint • Path. The path on each host that is where this primary storage is mounted. For example, "/mnt/primary". • Tags (optional). The comma-separated list of tags for this storage device. It should be an equivalent set or superset of the tags on your disk offerings. The tag sets on primary storage across clusters in a Zone must be identical.
Adding a Cluster 5. Enter the following details in the dialog. • Name. The name of the pod. • Gateway. The gateway for the hosts in that pod. • Netmask. The network prefix that defines the pod's subnet. Use CIDR notation. • Start/End Reserved System IP. The IP range in the management network that CloudPlatform uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP. For more information, see System Reserved IP Addresses. 6. Click OK. 7.5.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure 3. Click the Compute tab. In the Pods node, click View All. Select the same pod you used in step 1. 4. Click View Clusters, then click Add Cluster. The Add Cluster dialog is displayed. 5. In Hypervisor, choose OVM. 6. In Cluster, enter a name for the cluster. 7. Click Add. 7.5.3. Add Cluster: vSphere Host management for vSphere is done through a combination of vCenter and the CloudPlatform UI.
Add Cluster: vSphere 2. Log in to the UI. 3. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the cluster. 4. Click the Compute tab, and click View All on Pods. Choose the pod to which you want to add the cluster. 5. Click View Clusters. 6. Click Add Cluster. 7. In Hypervisor, choose VMware. 8. Provide the following information in the dialog. The fields below make reference to values from vCenter. • Cluster Name.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure If you have enabled Nexus dvSwitch in the environment, the following parameters for dvSwitch configuration are displayed: • Nexus dvSwitch IP Address: The IP address of the Nexus VSM appliance. • Nexus dvSwitch Username: The username required to access the Nexus VSM applicance. • Nexus dvSwitch Password: The password associated with the username specified above. There might be a slight delay while the cluster is provisioned.
Adding a Host 7.6. Adding a Host 1. Before adding a host to the CloudPlatform configuration, you must first install your chosen hypervisor on the host. CloudPlatform can manage hosts running VMs under a variety of hypervisors. The CloudPlatform Installation Guide provides instructions on how to install each supported hypervisor and configure it for use with CloudPlatform.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure For all additional hosts to be added to the cluster, run the following command. This will cause the host to join the master in a XenServer pool. # xe pool-join master-address=[master IP] master-username=root master-password=[your password] Note When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
Adding a Host (vSphere) 7. Click Add Host. 8. Provide the following information. • Host Name. The DNS name or IP address of the host. • Username. Usually root. • Password. This is the password for the user named above (from your XenServer, KVM, or OVM install). • Host Tags (Optional). Any labels that you use to categorize hosts for ease of maintenance. For example, you can set to the cloud's HA tag (set in the ha.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure • Pod. (Visible only if you choose Cluster in the Scope field.) The pod for the storage device. • Cluster. (Visible only if you choose Cluster in the Scope field.) The cluster for the storage device. • Name. The name of the storage device • Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS • Server (for NFS, iSCSI, or PreSetup).
Adding an NFS Secondary Staging Store for Each Zone 3. Log in to the CloudPlatform UI as root administrator. 4. In the left navigation bar, click Infrastructure. 5. In Secondary Storage, click View All. 6. Click Add Secondary Storage. 7. Fill in the following fields: • Name. Give the storage a descriptive name. • Provider. Choose the type of storage provider (such as S3, Swift, or NFS). NFS can be used for zone-based storage, and the others for region-wide object storage.
Chapter 7. Steps to Provisioning Your Cloud Infrastructure 5. In Secondary Storage, click View All. 6. In Select View, choose Secondary Staging Store. 7. Click the Add NFS Secondary Staging Store button. 8. Fill out the dialog box fields, then click OK: • Zone. The zone where the NFS Secondary Staging Store is to be located. • NFS server. The name of the zone's Secondary Staging Store. • Path. The path to the zone's Secondary Staging Store. 7.9.
Initialize and Test If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
100
Chapter 8. Installing XenServer for CloudPlatform If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see Section 4.4.1, “Upgrading to a New XenServer Version”. 8.1. System Requirements for XenServer Hosts • The following versions of XenServer are supported: • XenServer 6.
Chapter 8. Installing XenServer for CloudPlatform 8.2. XenServer Installation Steps 1. From https://www.citrix.com/English/ss/downloads/, download the appropriate version of XenServer for your CloudPlatform version (see Section 8.1, “System Requirements for XenServer Hosts”). Install it using the Citrix XenServer Installation Guide. 2. After installation, perform the following configuration steps, which are described in the next few sections: Required Optional Section 8.
Licensing 3. Restart the NTP client. # service ntpd restart 4. Make sure NTP will start again upon reboot. # chkconfig ntpd on 8.6. Licensing Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer. 8.6.1.
Chapter 8. Installing XenServer for CloudPlatform # xe-install-supplemental-pack xenserver-cloud-supp.iso 2. If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS): # xe-switch-network-backend bridge Restart the host machine when prompted. 3. If you are using XenServer 6.1 or greater, perform the following: a. Run the following commands: echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables b.
iSCSI Multipath Setup for XenServer (Optional) lrwxrwxrwx 1 root root 9 Mar 16 13:47 /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc 5. Repeat step 4 on every host. 6. On the storage server, run this command to get a unique ID for the new SR. # uuidgen The output should look like this, although the specific ID will be different: e6849e96-86c3-4f2c-8fcc-350cc711be3d 7. Create the FiberChannel SR. In name-label, use the unique ID you just generated.
Chapter 8. Installing XenServer for CloudPlatform Make note of the values you will need when you add this storage to the CloudPlatform later (see Section 7.7, “Adding Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR. If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support. 8.10.
Separate Storage Network for XenServer (Optional) labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that CloudPlatform is aware of the networks. Follow this procedure on each new host before adding the host to CloudPlatform: 1. Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this . 2.
Chapter 8. Installing XenServer for CloudPlatform • 2 NICs on private, 2 NICs on public, storage uses management network • 1 NIC for private, public, and storage All NIC bonding is optional. XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster.
NIC Bonding for XenServer (Optional) 1. Find the physical NICs that you want to bond together. #xe pif-list host-name-label='hostname' device=eth2 # xe pif-list host-name-label='hostname' device=eth3 These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID. 2. Create a new network for the bond. For example, a new network with name "cloud-public". This label is important.
110
Chapter 9. Installing KVM for CloudPlatform If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation documentation. It provides the CloudPlatform-specific steps that are needed to prepare a KVM host to work with CloudPlatform. 9.1. System Requirements for KVM Hypervisor Hosts 9.1.1.
Chapter 9. Installing KVM for CloudPlatform patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches. Warning The lack of up-do-date hotfixes can lead to data corruption and lost VMs. 9.2. Install and configure the Agent 1. Download the operating system that includes KVM (see Section 9.
Physical Network Configuration for KVM c. Create a repo file at /etc/yum.repos.d/rhel6.repo. In the file, insert the following lines: [rhel] name=rhel6 baseurl=file:///media enabled=1 gpgcheck=0 4. Install the CloudPlatform packages. You should have a file in the form of “CloudPlatformVERSION-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using: # tar xzf CloudPlatform-VERSION-N-OSVERSION.tar.
Chapter 9. Installing KVM for CloudPlatform • private.network.device These should be set to the name of the bridge that the user created for the respective traffic type. For example: • public.network.device=publicbondbr0 9.5. Time Synchronization for KVM Hosts The host must be set to use NTP. All hosts in a pod must have the same time. 1. Log in to the KVM host as root. 2. Install NTP. # yum install ntp 3. Edit the NTP configuration file to point to your NTP server. # vi /etc/ntp.
Primary Storage Setup for KVM (Optional) • Each node in the KVM cluster mounts the storage in the same local location (e.g., /mnt/primary) • A shared clustered file system is used • The administrator manages the mounting and unmounting of the storage • If you want to use SharedMountPoint storage you should set it up on the KVM hosts now. Note the mountpoint that you have used on each host; you will use that later to configure CloudPlatform.
116
Chapter 10. Installing VMware for CloudPlatform If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud. 10.1. System Requirements for vSphere Hosts 10.1.1. Software requirements • vSphere and vCenter, both version 5.0 or 5.1. vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/ vsphere_pricing.
Chapter 10. Installing VMware for CloudPlatform 10.1.3. vCenter Server requirements: • Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine. • Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine. • Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine. • Microsoft SQL Server 2005 Express disk requirements.
Preparation Checklist for VMware 10.2. Preparation Checklist for VMware For a smoother installation, gather the following information before you start: • Information listed in Section 10.2.1, “vCenter Checklist” • Information listed in Section 10.2.2, “Networking Checklist for VMware” 10.2.1. vCenter Checklist You will need the following information about vCenter. vCenter Requirement Value Notes vCenter User This user must have admin privileges. vCenter User Password Password for the above user.
Chapter 10. Installing VMware for CloudPlatform 10.3. vSphere Installation Steps 1. If you haven't already, you'll need to download and purchase vSphere from the VMware Website (https://www.vmware.com/tryvmware/index.php?p=vmware-vsphere&lp=1) and install it by following the VMware vSphere Installation Guide. 2.
Configure vCenter Management Network 10.5.1.2. Increasing Ports By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking). In vSwitch properties dialog, select the vSwitch and click Edit. In the dialog, you can change the number of switch ports.
Chapter 10. Installing VMware for CloudPlatform 10.6. Configuring a vSphere Cluster with Nexus 1000v Virtual Switch CloudPlatform supports Cisco Nexus 1000v dvSwitch (Distributed Virtual Switch) for virtual network configuration in a VMware vSphere environment. This section helps you configure a vSphere cluster with Nexus 1000v virtual switch in a VMware vCenter environment. For information on creating a vSphere cluster, see Chapter 10, Installing VMware for CloudPlatform 10.6.1.
Nexus 1000v Virtual Switch Preconfiguration • All information given in Section 10.6.3, “Nexus 1000v Virtual Switch Preconfiguration” 10.6.3. Nexus 1000v Virtual Switch Preconfiguration 10.6.3.1. Preparation Checklist For a smoother configuration of Nexus 1000v switch, gather the following information before you start: • vCenter Credentials • Nexus 1000v VSM IP address • Nexus 1000v VSM Credentials • Ethernet port profile names 10.6.3.1.1.
Chapter 10. Installing VMware for CloudPlatform Network Requirements Value Notes establish and maintain the connection between the VSM and VMware vCenter Server. Packet Port Group VLAN ID The VLAN ID of the Packet Port Group. The packet VLAN forwards relevant data packets from the VEMs to the VSM. Note The VLANs used for control, packet, and management port groups can be the same. 2 For more information, see Cisco Nexus 1000V Getting Started Guide . 10.6.3.1.3.
Nexus 1000v Virtual Switch Preconfiguration • The Ethernet port profile created to represent the physical network or networks used by an Advanced zone configuration trunk all the VLANs including guest VLANs, the VLANs that serve the native VLAN, and the packet/control/data/management VLANs of the VSM. • The Ethernet port profile created for a Basic zone configuration does not trunk the guest VLANs because the guest VMs do not get their own VLANs provisioned on their network interfaces in a Basic zone.
Chapter 10. Installing VMware for CloudPlatform Note Before you run the vlan command, ensure that the configuration mode is enabled in Nexus 1000v virtual switch. For example: If you want the VLAN 200 to be used on the switch, run the following command: vlan 200 If you want the VLAN range 1350-1750 to be used on the switch, run the following command: vlan 1350-1750 Refer to Cisco Nexus 1000V Command Reference of specific product version. 10.6.4.
Removing Nexus Virtual Switch Parameters Description vCenter Password Enter the password for the user named above. vCenter Datacenter Enter the vCenter datacenter that the cluster is in. For example, "cloud.dc.VM". Nexus dvSwitch IP Address The IP address of the VSM component of the Nexus 1000v virtual switch. Nexus dvSwitch Username The admin name to connect to the VSM appliance. Nexus dvSwitch Password The corresponding password for the admin user specified above. 10.6.6.
Chapter 10. Installing VMware for CloudPlatform • VMware VDS does not support multiple VDS per traffic type. If a user has many VDS switches, only one can be used for Guest traffic and another one for Public traffic. • Additional switches of any type can be added for each cluster in the same zone. While adding the clusters with different switch type, traffic labels is overridden at the cluster level. • Management and Storage network does not support VDS. Therefore, use Standard Switch for these networks.
Configuring a VMware Datacenter with VMware Distributed Virtual Switch • The Public Traffic vSwitch Type field when you add a VMware VDS-enabled cluster. • The switch name in the traffic label while updating the switch type in a zone.
Chapter 10. Installing VMware for CloudPlatform Fields Name Description would be ignored and could be left empty for guest traffic. By default empty string would be assumed which translates to untagged VLAN for that specific traffic type. 3 Type of virtual switch. Specified Possible valid values are as string. vmwaredvs, vmwaresvs, nexusdvs.
Configuring a VMware Datacenter with VMware Distributed Virtual Switch you enable the vmware.use.dvswitch parameter, you cannot see any UI options specific to VDS, and CloudPlatform ignores the VDS-specific parameters that you specify. Additionally, CloudPlatform uses VDS for virtual network infrastructure if the value of vmware.use.dvswitch parameter is true and the value of vmware.use.nexus.dvswitch parameter is false. Another global parameter that defines VDS configuration is vmware.ports.per.
Chapter 10. Installing VMware for CloudPlatform Parameters Description vCenter User name Enter the username that CloudPlatform should use to connect to vCenter. This user must have all administrative privileges. vCenter Password Enter the password for the user named above. vCenter Datacenter Enter the vCenter datacenter that the cluster is in. For example, "clouddcVM". Override Public Traffic Enable this option to override the zone-wide public traffic for the cluster you are creating.
Create an iSCSI datastore Repeat these steps for all ESXi hosts in the cluster. 10.7.3. Create an iSCSI datastore You should now create a VMFS datastore. Follow these steps to do so: 1. Select Home/Inventory/Datastores. 2. Right click on the datacenter node. 3. Choose Add Datastore... command. 4. Follow the wizard to create a iSCSI datastore. This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts. 10.7.4.
134
Chapter 11. Bare Metal Installation You can set up bare metal hosts in a CloudPlatform cloud and manage them with the Management Server. Bare metal hosts do not run hypervisor software. You do not install the operating system – that is done using PXE when an instance is created from the bare metal template which you are going to create as part of this Installation procedure. Bare metal hosts use basic networking. A cloud can contain a mix of bare metal instances and virtual machine instances.
Chapter 11. Bare Metal Installation Example: Section 11.3.18, “Example CentOS 6.x Kickstart File” • Ubuntu Docs: https://help.ubuntu.com/lts/installation-guide/i386/automatic-install.html Example: Section 11.3.20, “Example Ubuntu 12.04 Kickstart File” 11.2.1. Limitations of Kickstart Baremetal Installation When this feature is used, the following are not supported: • Use in advanced zones is not supported. Use in basic zones only.
Enable PXE on the Bare Metal Host Once you are there, set the following: • IP address of IPMI NIC • Netmask • Gateway • Username and password for IPMI NIC CloudPlatform uses ipmitool to control the lifecycle of baremetal hosts. By default, ipmitool uses the interface 'lan' to issue ipmi commands. Depending on your motherboard, the interface may need to be 'lanplus'. Consult your hardware documentation to find out if this is the case. If so, modify the script / usr/lib64/cloud/agent/scripts/util/ipmi.py.
Chapter 11. Bare Metal Installation You should see a few messages as the installer prepares, followed by a list of choices. 4. Choose “B” to install the software that is needed for bare metal. > B 5. Run the bare metal setup script. # cloudstack-setup-baremetal 6. Make note of the TFTP root directory that is displayed by this script. You will need it later. 11.3.5. Set Up a File Server The kickstart bare metal image and kickstart file will be stored on an NFS file server.
Set Up a File Server • sync: exportfs notify client when file write is complete instead of async notify Warning Be careful with space characters in these NFS configuration files. They must be used exactly as shown in the syntax. 2. In /etc/hosts.deny, list the clients that are not permitted access to the NFS server by default. For example, you might want to start by denying access to everyone: portmap:ALL In the next step, you'll override this to allow specific hosts. 3. In /etc/hosts.
Chapter 11. Bare Metal Installation • rpc.lockd • rpc.rquotad 11.3.6. Create a Bare Metal Image Create an image which can be installed on bare metal hosts later, when bare metal instances are provisioned in your cloud. On the NFS file server, create a folder and put a PXE bootable kernel and initrd in it. For example: # mkdir –p /home/centos63 # cp iso_mount_path_to_centos63/images/pxeboot/{ initrd.
Create a Bare Metal Network Offering 11.3.8. Create a Bare Metal Network Offering 1. Log in as admin to the CloudPlatform UI. 2. In the left navigation bar, click Service Offerings. 3. In Select Offering, choose Network Offering. 4. Click Add Network Offering. 5. In the dialog, make the following choices: • Name: You can give the offering any desired name. For example, Baremetal.
Chapter 11. Bare Metal Installation • python-cherrypy: A Python HTTP server which is distributed by default with most Linux distributions. For example, both CentOS and Ubuntu have this package. • ipset: An iptables tool which provides ipset match. In Ubuntu, ipset is provided by default. In Cent OS, it is not provided by default; you need to download it from a third party. For example: http://www.wandin.net/dotclear/index.php?post/2012/05/26/Installing-ipset-on-CentOS-6 • libmnl: ipset dependent library.
(Optional) Set Bare Metal Configuration Parameters 11.3.10. (Optional) Set Bare Metal Configuration Parameters 1. Log in as admin to the CloudPlatform UI. Click Global Settings. Make any desired modifications to the bare metal configuration parameters. • enable.baremetal.securitygroup.agent.echo (default: false) • external.baremetal.resource.classname • external.baremetal.system.url • interval.baremetal.securitygroup.agent.echo (default: 10) • timeout.baremetal.securitygroup.agent.
Chapter 11. Bare Metal Installation 9. In a new zone, CloudPlatform adds the first pod for you. You can always add more pods later. To configure the first pod, enter the following: • Pod Name. A name for the pod. • Reserved system gateway. The gateway for the hosts in that pod. • Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR notation. • Start/End Reserved System IP.
Add the PXE Server and DHCP Server to Your Deployment 3. Click the Compute and Storage tab. In Clusters, click View All, then click the name of the bare metal cluster you added earlier. 4. Click View Hosts. 5. Click the Add Host button. The Add Host dialog will appear. 6. In the Add Host dialog, make the following choices: • Host name. The IPMI IP address of the machine. • Username. User name you set for IPMI. • Password. Password you set for IPMI. • # CPU Cores. Number of CPUs on the machine.
Chapter 11. Bare Metal Installation 7. In the list of Network service providers, click Baremetal DHCP. In the Details node, click Add Baremetal DHCP Device button. The Add Baremetal DHCP Device dialog will appear. 8. In the Add Baremetal DHCP Device dialog: • URL: http:// • Username: login username • Password: password 11.3.15.
Provision a Bare Metal Instance • Featured. Choose Yes if you would like this template to be more prominent for users to select. Only administrators may make templates featured. 11.3.16. Provision a Bare Metal Instance Deploy one bare metal instance per host using these steps. 1. Log in to the CloudPlatform UI as an administrator or user. 2. In the left navigation bar, click Instances. 3. Click Add Instance. 4. Select a zone. 5. Click Template. 6. Click Next. 7.
Chapter 11. Bare Metal Installation selinux --permissive timezone --utc Europe/London bootloader --location=mbr --driveorder=sda clearpart --initlabel --linux --drives=sda part /boot --fstype ext3 --size=500 --ondisk=sda part pv.2 --size=1 --grow --ondisk=sda volgroup vg00 --pesize=32768 pv.2 logvol swap --fstype swap --name=swap00 --vgname=vg00 --size=1024 logvol / --fstype ext3 --name=lv00 --vgname=vg00 --size=2560 #repo --name=epel --baseurl=http://download.fedoraproject.
Example Ubuntu 12.
Chapter 11. Bare Metal Installation mouse #System timezone timezone America/New_York #Root password rootpw --iscrypted password #Initial user user --disabled #Reboot after installation reboot #Use text mode install text #Install OS instead of upgrade install # Use network installation url --url=http://10.223.110.
Using Cisco UCS as Bare Metal Host CloudPlatform %pre #services services --enabled=ntpd,nscd,puppet #Package install information %packages ubuntu-standard man-db wget postfix openssh-server sysstat nfs-common nscd postfix quota ntp %post 11.4. Using Cisco UCS as Bare Metal Host CloudPlatform (Supported only for use in CloudPlatform zones with basic networking.) You can provision Cisco UCS server blades into CloudPlatform for use as bare metal hosts.
Chapter 11. Bare Metal Installation • UCS manager IP address • UCS manager username • UCS manager password 2. Log in to the CloudPlatform UI as administrator. 3. In the left navigation bar, click Infrastructure, then click Zones. 4. Click the name of a zone where Network Type is Basic. 5. Click the Compute and Storage tab. 6. Scroll down in the diagram and click UCS. 7. Click the Add UCS Manager button.
Disassociating a Profile from a UCS Blade 11.4.3. Disassociating a Profile from a UCS Blade 1. Log in to the CloudPlatform UI as administrator. 2. In the left navigation bar, click Infrastructure, then click Zones. 3. Click the name of a zone where you have registered a UCS Manager. 4. Click the Compute and Storage tab. 5. Scroll down in the diagram and click UCS. 6. Click the name of the UCS Manager. A list is displayed that shows the names of the blades that are installed under the selected manager. 7.
154
Chapter 12. Installing Oracle VM (OVM) for CloudPlatform If you want to use the Oracle VM Server (OVM) hypervisor to run guest virtual machines, install OVM on the host(s) in your cloud. 12.1. System Requirements for OVM Hosts CloudPlatform works with the following version: • OVM Server 2.2.1 The OVM hosts must follow these restrictions: • All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All Hosts within a Cluster must be homogenous.
Chapter 12. Installing Oracle VM (OVM) for CloudPlatform 4. Repeat for any additional hosts that will be part of the OVM cluster. Note After ISO installation, the installer reboots into the operating system. Due to a known issue in OVM Server, the reboot will place the VM in the Stopped state. In the CloudPlatform UI, detach the ISO from the VM (so that the VM will not boot from the ISO again), then click the Start button to restart the VM. 12.4.
Chapter 13. Choosing a Deployment Architecture The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments. 13.1. Small-Scale Deployment This diagram illustrates the network architecture of a small-scale CloudPlatform deployment.
Chapter 13. Choosing a Deployment Architecture 13.2. Large-Scale Redundant Setup This diagram illustrates the network architecture of a large-scale CloudPlatform deployment. • A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities.
Separate Storage Network • The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers. • Secondary storage servers are connected to the management network. • Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches. 13.3.
160
Chapter 14. Network Setup Achieving the correct networking setup is crucial to a successful CloudPlatform installation. This section contains information to help you make decisions and follow the right procedures to get your network set up correctly. 14.1. Basic and Advanced Networking CloudPlatform provides two styles of networking:. Basic Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
Chapter 14. Network Setup 14.2. VLAN Allocation Example VLANs are required for public and guest traffic. The following is an example of a VLAN allocation scheme: VLAN IDs Traffic type Scope less than 500 Management traffic. Reserved for administrative purposes. CloudPlatform software can access this, hypervisors, system VMs. 500-599 VLAN carrying public traffic. CloudPlatform accounts. 600-799 VLANs carrying guest traffic. CloudPlatform accounts. Account-specific VLAN is chosen from this pool.
Cisco 3750 • All VLANs (300-999) are passed to all the pod-level layer-2 switches. 14.3.2. Cisco 3750 The following steps show how a Cisco 3750 is configured for zone-level layer-3 switching. These steps assume VLAN 201 is used to route untagged private IPs for pod 1, and pod 1’s layer-2 switch is connected to GigabitEthernet1/0/1. 1. Setting VTP mode to transparent allows us to utilize VLAN IDs above 1000. Since we only use VLANs up to 999, vtp transparent mode is not strictly required.
Chapter 14. Network Setup 2. VLAN 201 is used to route untagged private IP addresses for pod 1, and pod 1 is connected to this layer-2 switch. interface range ethernet all switchport mode general switchport general allowed vlan add 300-999 tagged exit The statements configure all Ethernet ports to function as follows: • All ports are configured the same way. • All VLANs (300-999) are passed through all the ports of the layer-2 switch. 14.4.2.
External Guest Firewall Integration for Juniper SRX (Optional) To achieve the above purposes you must set up fixed configurations for the firewall. Firewall rules and policies need not change as users are provisioned into the cloud. Any brand of hardware firewall that supports NAT and site-to-site VPN can be used. 14.5.2. External Guest Firewall Integration for Juniper SRX (Optional) Note Available only for guests using advanced networking, both shared and isolated.
Chapter 14. Network Setup 8. Make sure the "ssh" and "xnm-clear-text" system services are enabled. 9. If traffic metering is desired: a. a. Create an incoming firewall filter and an outgoing firewall filter. These filters should be the same names as your public security zone name and private security zone name respectively. The filters should be set to be "interface-specific".
External Guest Firewall Integration for Cisco VNMC (Optional) • Public Interface. The name of the public interface on the SRX. For example, ge-0/0/2. A ".x" at the end of the interface indicates the VLAN that is in use. • Private Interface: The name of the private interface on the SRX. For example, ge-0/0/1. • Number of Retries: The number of times to attempt a command on the SRX before failing. The default value is 2.
Chapter 14. Network Setup • When a guest network is created with Cisco VNMC firewall provider, an additional public IP is acquired along with the Source NAT IP. The Source NAT IP is used for the rules, whereas the additional IP is used to for the ASA outside interface. Ensure that this additional public IP is not released. You can identify this IP as soon as the network is in implemented state and before acquiring any further public IPs. The additional IP is the one that is not marked as Source NAT.
External Guest Firewall Integration for Cisco VNMC (Optional) For more information, see Section 10.6, “Configuring a vSphere Cluster with Nexus 1000v Virtual Switch”. 5. Deploy and Cisco ASA 1000v appliance. 4 For more information, see Setting Up the ASA 1000V Using VNMC . Typically, you create a pool of ASA 1000v appliances and register them with CloudPlatform. Specify the following while setting up a Cisco ASA 1000v instance: • VNMC host IP. • Ensure that you add ASA appliance in VNMC mode.
Chapter 14. Network Setup 2. In the left navigation bar, click Infrastructure. 3. In Zones, click View More. 4. Choose the zone you want to work with. 5. Click the Physical Network tab. 6. In the Network Service Providers node of the diagram, click Configure. You might have to scroll down to see this. 7. Click Cisco VNMC. 8. Click View VNMC Devices. 9. Click the Add VNMC Device and provide the following: • Host: The IP address of the VNMC instance.
External Guest Firewall Integration for Cisco VNMC (Optional) 14.5.3.4. Creating a Network Offering Using Cisco ASA 1000v To have Cisco ASA 1000v support for a guest network, create a network offering as follows: 1. Log in to the CloudPlatform UI as a user or admin. 2. From the Select Offering drop-down, choose Network Offering. 3. Click Add Network Offering. 4. In the dialog, make the following choices: • Name: Any desired name for the network offering.
Chapter 14. Network Setup You are prompted with the following message: System config has been modified. Save? [Y]es/[N]o:" b. Enter N. You will get the following confirmation message: "Proceed with reload? [confirm]" c. Restart the appliance. 2.
Topology Requirements • IP Address: The IP address of the NetScaler. • Username/Password: The authentication credentials to access the device. CloudPlatform uses these credentials to access the device. • Type: The type of device that is being added. It could be NetScaler VPX, NetScaler MPX, or NetScaler SDX. For a comparison of the NetScaler types, see the CloudPlatform Administration Guide. • Public interface: Interface of device that is configured to be part of the public network.
Chapter 14. Network Setup 14.7.3. Storage Network Topology Requirements The secondary storage NFS export is mounted by the secondary storage VM. Secondary storage traffic goes over the management traffic network, even if there is a separate storage network. Primary storage traffic goes over the storage network, if available. If you choose to place secondary storage NFS servers on the storage network, you must make sure there is a route from the management traffic network to the storage network. 14.7.4.
Setting Zone VLAN and Running VM Maximums To set up the integration between CloudPlatform and Traffic Sentinel: 1. On your network infrastructure, install Traffic Sentinel and configure it to gather traffic data. For 5 installation and configuration steps, see inMon documentation at Traffic Sentinel Documentation . 2. In the Traffic Sentinel UI, configure Traffic Sentinel to accept script querying from guest users.
176
Chapter 15. Amazon Web Service Interface 15.1. Amazon Web Services EC2 Compatible Interface CloudPlatform can translate Amazon Web Services (AWS) API calls to native CloudPlatform API calls so that users can continue using existing AWS-compatible tools. This translation service runs as a separate web application in the same tomcat server as the management server of CloudPlatform, listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web service and the AWS Query API.
Chapter 15. Amazon Web Service Interface 4. (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows: a. Edit the files /etc/cloudstack/management/server.xml, /etc/cloudstack/management/servernonssl.xml, and /etc/cloudstack/management/server-ssl.xml. b. In each file, find the tag . Under this tag, locate . c.
AWS API Command-Line Tools Setup $ cloudstack-aws-api-register --apikey=User’s CloudPlatform API key -secretkey=User’s CloudPlatform Secret key --cert=/path/to/cert.pem -url=http://CloudPlatform.server:7080/awsapi Note A user with an existing AWS certificate could choose to use the same certificate with CloudPlatform, but the public key would be uploaded to the CloudPlatform management server database. 15.4.2.
Chapter 15. Amazon Web Service Interface EC2 command SOAP / REST call CloudPlatform API call ec2-deregister DeregisterImage DeleteTemplate ec2-describe-images DescribeImages listTemplates The noReboot parameter is not supported. ec2-register RegisterImage For the optional parameter architecture, use the CloudPlatform format rather than the EC2 format. The CloudPlatform format includes the template format, zone, OS type, hypervisorm and required parameters.
Supported AWS API Calls EC2 command SOAP / REST call CloudPlatform API call EC2 command SOAP / REST call CloudPlatform API call ec2-add-keypair CreateKeyPair createSSHKeyPair ec2-delete-keypair DeleteKeyPair deleteSSHKeyPair ec2-describe-keypairs DescribeKeyPairs listSSHKeyPairs ec2-import-keypair ImportKeyPair registerSSHKeyPair EC2 command SOAP / REST call CloudPlatform API call ec2-get-password GetPasswordData getVMPassword EC2 command SOAP / REST call CloudPlatform API call ec
Chapter 15. Amazon Web Service Interface EC2 command SOAP / REST call CloudPlatform API call ec2-delete-tags DeleteTags Remove tags from one or more resources. ec2-describe-tags DescribeTags Show currently defined tags.
Chapter 16. Additional Installation Options The next few sections describe CloudPlatform features above and beyond the basic deployment options. 16.1. Installing the Usage Server (Optional) You can optionally install the Usage Server once the Management Server is configured properly. The Usage Server takes data from the events in the system and enables usage-based billing for accounts. When multiple Management Servers are present, the Usage Server may be installed on any number of them.
Chapter 16. Additional Installation Options CloudPlatform uses Tomcat as its servlet container. For sites that would like CloudPlatform to terminate the SSL session, Tomcat’s SSL access may be enabled. Tomcat SSL configuration is described at http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html. 16.3. Database Replication (Optional) CloudPlatform supports database replication from one MySQL node to another. This is achieved using standard MySQL replication.
Database Replication (Optional) # mysql -u root mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 412 | | | +------------------+----------+--------------+------------------+ 8. Note the file and the position that are returned by your instance. 9. Exit from this session. 10. Complete the master setup.
Chapter 16. Additional Installation Options 16.3.1. Failover This will provide for a replicated database that can be used to implement manual failover for the Management Servers. CloudPlatform failover from one MySQL instance to another is performed by the administrator. In the event of a database failure you should: 1. Stop the Management Servers (via service cloudstack-management stop). 2. Change the replica's configuration to be a master and restart it. 3.
