CloudStack Installation Documentation - Read the Docs ?· CloudStack Installation Documentation, Release…

Download CloudStack Installation Documentation - Read the Docs ?· CloudStack Installation Documentation, Release…

Post on 04-Jun-2018

217 views

Category:

Documents

3 download

Embed Size (px)

TRANSCRIPT

  • CloudStack Installation DocumentationRelease 4.12.0.0

    Apache Software Foundation

    Apr 19, 2018

  • Contents

    1 Choosing a Deployment Architecture 31.1 Choosing a Deployment Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

    2 Quick Installation Guide 132.1 Quick Installation Guide for CentOS 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

    3 Source Installation 233.1 Building from Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

    4 General Installation 314.1 Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Management Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

    5 Configuration 475.1 Configuring your CloudStack Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

    6 Hypervisor Setup 736.1 Host Hyper-V Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Host KVM Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 Host LXC Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.4 Host VMware vSphere Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.5 Host Citrix XenServer Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

    7 Network Setup 1357.1 Network Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

    8 Storage Setup 1518.1 Storage Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518.2 Small-Scale Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1518.3 Large-Scale Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.4 Storage Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.5 Network Configuration For Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

    9 Optional Installation 1599.1 Additional Installation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599.2 About Password and Key Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

    i

  • ii

  • CloudStack Installation Documentation, Release 4.12.0.0

    This is the Apache CloudStack installation guide, for the Documentation home, the administrator guide or the Release-Notes please see:

    Documentation home

    Administration Guide

    Release Notes

    Note: In this guide we first go through some design and architectural choices to build your cloud. Then we dive intoa single node quick start guide to give you a feel for the installation process. The source installation steps are given inthe follow-on section for people who want to build their own packages. Otherwise you can use the general installationwhich makes use of community maintained package repositories. The rest of the guide goes through the configurationof the data-center and the setup of the network, storage and hypervisors.

    Contents 1

    http://cloudstack.apache.org/http://docs.cloudstack.apache.orghttp://docs.cloudstack.apache.org/projects/cloudstack-administrationhttp://docs.cloudstack.apache.org/projects/cloudstack-release-notes

  • CloudStack Installation Documentation, Release 4.12.0.0

    2 Contents

  • CHAPTER 1

    Choosing a Deployment Architecture

    1.1 Choosing a Deployment Architecture

    The architecture used in a deployment will vary depending on the size and purpose of the deployment. This sectioncontains examples of deployment architecture, including a small-scale deployment useful for test and trial deploymentsand a fully-redundant large-scale setup for production deployments.

    3

  • CloudStack Installation Documentation, Release 4.12.0.0

    1.1.1 Small-Scale Deployment

    This diagram illustrates the network architecture of a small-scale CloudStack deployment.

    A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwardsHTTP requests and API calls from the Internet to the Management Server. The Management Server resides onthe management network.

    A layer-2 switch connects all physical servers and storage.

    A single NFS server functions as both the primary and secondary storage.

    The Management Server is connected to the management network.

    4 Chapter 1. Choosing a Deployment Architecture

  • CloudStack Installation Documentation, Release 4.12.0.0

    1.1.2 Large-Scale Redundant Setup

    This diagram illustrates the network architecture of a large-scale CloudStack deployment.

    A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should bedeployed. Typically high-end core switches also include firewall modules. Separate firewall appliances mayalso be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured inNAT mode. The firewalls provide the following functions:

    Forwards HTTP requests and API calls from the Internet to the Management Server. The ManagementServer resides on the management network.

    When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers indifferent zones can directly reach each other.

    1.1. Choosing a Deployment Architecture 5

  • CloudStack Installation Documentation, Release 4.12.0.0

    A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase portcount. In either case, redundant pairs of layer-2 switches should be deployed.

    The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQLdatabase) 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 redundantNICs connected to separate layer-2 access switches.

    1.1.3 Separate Storage Network

    In the large-scale redundant setup described in the previous section, storage traffic can overload the managementnetwork. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitiveto network delays. A separate storage network ensures guest network traffic contention does not impact storageperformance.

    1.1.4 Multi-Node Management Server

    The CloudStack Management Server is deployed on one or more front-end servers connected to a single MySQLdatabase. Optionally a pair of hardware load balancers distributes requests from the web. A backup managementserver set may be deployed using MySQL replication at a remote site to add DR capabilities.

    The administrator must decide the following.

    Whether or not load balancers will be used.

    How many Management Servers will be deployed.

    Whether MySQL replication will be deployed to enable disaster recovery.

    1.1.5 Multi-Site Deployment

    The CloudStack platform scales well into multiple sites through the use of zones. The following diagram shows anexample of a multi-site deployment.

    6 Chapter 1. Choosing a Deployment Architecture

  • CloudStack Installation Documentation, Release 4.12.0.0

    Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in realtime to the secondary Management Server installation in Data Center 2.

    1.1. Choosing a Deployment Architecture 7

  • CloudStack Installation Documentation, Release 4.12.0.0

    This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-levelnetwork switches and two connected to storage network switches.

    There are two ways to configure the storage network:

    Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches andbonded NICs still result in one network (one CIDR block+ default gateway address).

    8 Chapter 1. Choosing a Deployment Architecture

  • CloudStack Installation Documentation, Release 4.12.0.0

    iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gate-way). Multipath iSCSI client can failover and load balance between separate storage networks.

    This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configurationinvolves only one network. MPIO involves two separate networks.

    1.1.6 Choosing a Hypervisor

    CloudStack supports many popular hypervisors. Your cloud can consist entirely of hosts running a single hypervisor,or you can use multiple hypervisors. Each cluster of hosts must run the same hypervisor.

    You might already have an installed base of nodes running a particular hypervisor, in which case, your choice ofhypervisor has already been made. If you are starting from scratch, you need to decide what hypervisor software bestsuits your needs. A discussion of the relative advantages of each hypervisor is outside the scope of our documentation.However, it will help you to know which features of each hypervisor are supported by CloudStack. The followingtable provides this information.

    1.1. Choosing a Deployment Architecture 9

  • CloudStack Installation Documentation, Release 4.12.0.0

    Feature XenServervSphere KVM -RHEL

    LXC Hy-perV

    BareMetal

    Network Throttling Yes Yes No No ? N/ASecurity groups in zones that use basic networking Yes No Yes Yes ? NoiSCSI Yes Yes Yes Yes Yes N/AFibreChannel Yes Yes Yes Yes Yes N/ALocal Disk Yes Yes Yes Yes Yes YesHA Yes Yes

    (Na-tive)

    Yes ? Yes N/A

    Snapshots of local disk Yes Yes Yes ? ? N/ALocal disk as data disk Yes No Yes Yes Yes N/AWork load balancing No DRS No No ? N/AManual live migration of VMs from host to host Yes Yes Yes ? Yes N/AConserve management traffic IP address by using link localnetwork to communicate with virtual router

    Yes No Yes Yes ? N/A

    Hypervisor Support for Primary Storage

    The following table shows storage options and parameters for different hypervisors.

    Primary Storage Type XenServer vSphere KVM - RHEL LXC Hy-perV

    Format for Disks, Templates,and Snapshots

    VHD VMDK QCOW2 VHD

    iSCSI support CLVM VMFS Yes via SharedMountpoint

    Yes via SharedMountpoint

    No

    Fiber Channel support Yes, Via ex-isting SR

    VMFS Yes via SharedMountpoint

    Yes via SharedMountpoint

    No

    NFS support Yes Yes Yes Yes NoLocal storage support Yes Yes Yes Yes YesStorage over-provisioning NFS NFS and

    iSCSINFS No

    SMB/CIFS No No No No Yes

    XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does notsupport over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As aresult the CloudStack can still support storage over-provisioning by running on thin-provisioned storage volumes.

    KVM supports Shared Mountpoint storage. A shared mountpoint is a file system path local to each server in a givencluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpointis assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount orunmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage isavailable

    With NFS storage, CloudStack manages the overprovisioning. In this case the global configuration parameter stor-age.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.

    Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option isenabled, a local disk storage pool is automatically created on each host. To use local storage for the System VirtualMachines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.

    10 Chapter 1. Choosing a Deployment Architecture

  • CloudStack Installation Documentation, Release 4.12.0.0

    CloudStack supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS serversin primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the firstapproaches capacity.

    1.1.7 Best Practices

    Deploying a cloud is challenging. There are many different technology choices to make, and CloudStack is flexibleenough in its configuration that there are many possible ways to combine and configure the chosen technology. Thissection contains suggestions and requirements about cloud deployments.

    These should be treated as suggestions and not absolutes. However, we do encourage anyone planning to build a cloudoutside of these guidelines to seek guidance and advice on the project mailing lists.

    Process Best Practices

    A staging system that models the production environment is strongly advised. It is critical if customizationshave been applied to CloudStack.

    Allow adequate time for installation, a beta, and learning the system. Installs with basic networking can be donein hours. Installs with advanced networking usually take several days for the first attempt, with complicatedinstallations taking longer. For a full production system, allow at least 4-8 weeks for a beta to work through allof the integration issues. You can get help from fellow users on the cloudstack-users mailing list.

    Setup Best Practices

    Each host should be configured to accept connections only from well-known entities such as the CloudStackManagement Server or your network monitoring software.

    Use multiple clusters per pod if you need to achieve a certain switch density.

    Primary storage mountpoints or LUNs should not exceed 6 TB in size. It is better to have multiple smallerprimary storage elements per cluster than one large one.

    When exporting shares on primary storage, avoid data loss by restricting the range of IP addresses that canaccess the storage. See Linux NFS on Local Disks and DAS or Linux NFS on iSCSI.

    NIC bonding is straightforward to implement and provides increased reliability.

    10G networks are generally recommended for storage access when larger servers that can support relativelymore VMs are used.

    Host capacity should generally be modeled in terms of RAM for the guests. Storage and CPU may be overpro-visioned. RAM may not. RAM is usually the limiting factor in capacity designs.

    (XenServer) Configure the XenServer dom0 settings to allocate more memory to dom0. This can enableXenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServerdom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers toXenServer 5.6, but the same information applies to XenServer 6.0.

    Maintenance Best Practices

    Monitor host disk space. Many host failures occur because the hosts root disk fills up from logs that were notrotated adequately.

    1.1. Choosing a Deployment Architecture 11

    http://support.citrix.com/article/CTX126531

  • CloudStack Installation Docu...

Recommended

View more >