You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by se...@apache.org on 2014/01/27 22:12:09 UTC
[4/9] break file into chapters
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/b1401796/source/installation.rst
----------------------------------------------------------------------
diff --git a/source/installation.rst b/source/installation.rst
index b5c504a..10dacaf 100644
--- a/source/installation.rst
+++ b/source/installation.rst
@@ -14,20005 +14,1412 @@
specific language governing permissions and limitations
under the License.
-Legal Notice
+Installation
============
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership. The
-ASF licenses this file to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance with the
-License. You may obtain a copy of the License at
-
-http://www.apache.org/licenses/LICENSE-2.0
+Who Should Read This
+--------------------
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
+For those who have already gone through a design phase and planned a
+more sophisticated deployment, or those who are ready to start scaling
+up a trial installation. With the following procedures, you can start
+using the more powerful features of CloudStack, such as advanced VLAN
+networking, high availability, additional network elements such as load
+balancers and firewalls, and support for multiple hypervisors including
+Citrix XenServer, KVM, and VMware vSphere.
-Concepts
-========
+Overview of Installation Steps
+------------------------------
-1.1. What Is CloudStack?
-------------------------
+For anything more than a simple trial installation, you will need
+guidance for a variety of configuration choices. It is strongly
+recommended that you read the following:
-CloudStack is an open source software platform that pools computing
-resources to build public, private, and hybrid Infrastructure as a
-Service (IaaS) clouds. CloudStack manages the network, storage, and
-compute nodes that make up a cloud infrastructure. Use CloudStack to
-deploy, manage, and configure cloud computing environments.
+-
-Typical users are service providers and enterprises. With CloudStack,
-you can:
+ Choosing a Deployment Architecture
-
- Set up an on-demand, elastic cloud computing service. Service
- providers can sell self service virtual machine instances, storage
- volumes, and networking configurations over the Internet.
+ Choosing a Hypervisor: Supported Features
-
- Set up an on-premise private cloud for use by employees. Rather than
- managing virtual machines in the same way as physical machines, with
- CloudStack an enterprise can offer self-service virtual machines to
- users without involving IT departments.
+ Network Setup
-|1000-foot-view.png: Overview of CloudStack|
+-
-1.2. What Can CloudStack Do?
-----------------------------
+ Storage Setup
-**Multiple Hypervisor Support**
-
-CloudStack works with a variety of hypervisors, and a single cloud
-deployment can contain multiple hypervisor implementations. The current
-release of CloudStack supports pre-packaged enterprise solutions like
-Citrix XenServer and VMware vSphere, as well as KVM or Xen running on
-Ubuntu or CentOS.
-
-**Massively Scalable Infrastructure Management**
-
-CloudStack 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
-a cloud-wide outage. Periodic maintenance of the management server can
-be performed without affecting the functioning of virtual machines
-running in the cloud.
-
-**Automatic Configuration Management**
-
-CloudStack automatically configures each guest virtual machine’s
-networking and storage settings.
-
-CloudStack internally manages a pool of virtual appliances to support
-the cloud itself. These appliances offer services such as firewalling,
-routing, DHCP, VPN access, console proxy, storage access, and storage
-replication. The extensive use of virtual appliances simplifies the
-installation, configuration, and ongoing management of a cloud
-deployment.
-
-**Graphical User Interface**
-
-CloudStack offers an administrator's Web interface, used for
-provisioning and managing the cloud, as well as an end-user's Web
-interface, used for running VMs and managing VM templates. The UI can be
-customized to reflect the desired service provider or enterprise look
-and feel.
-
-**API and Extensibility**
-
-CloudStack provides an API that gives programmatic access to all the
-management features available in the UI. The API is maintained and
-documented. This API enables the creation of command line tools and new
-user interfaces to suit particular needs. See the Developer’s Guide and
-API Reference, both available at `Apache CloudStack
-Guides <http://cloudstack.apache.org/docs/en-US/index.html>`__ and
-`Apache CloudStack API
-Reference <http://cloudstack.apache.org/docs/api/index.html>`__
-respectively.
-
-The CloudStack pluggable allocation architecture allows the creation of
-new types of allocators for the selection of storage and Hosts. See the
-Allocator Implementation Guide
-(`http://docs.cloudstack.org/CloudStack\_Documentation/Allocator\_Implementation\_Guide <http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide>`__).
-
-**High Availability**
-
-CloudStack has a number of features to increase the availability of the
-system. The Management Server itself may be deployed in a multi-node
-installation where the servers are load balanced. MySQL may be
-configured to use replication to provide for a manual failover in the
-event of database loss. For the hosts, CloudStack supports NIC bonding
-and the use of separate networks for storage as well as iSCSI Multipath.
-
-1.3. Deployment Architecture Overview
--------------------------------------
-
-A CloudStack installation consists of two parts: the Management Server
-and the cloud infrastructure that it manages. When you set up and manage
-a CloudStack cloud, you provision resources such as hosts, storage
-devices, and IP addresses into the Management Server, and the Management
-Server manages those resources.
-
-The minimum production installation consists of one machine running the
-CloudStack Management Server and another machine to act as the cloud
-infrastructure (in this case, a very simple infrastructure consisting of
-one host running hypervisor software). In its smallest deployment, a
-single machine can act as both the Management Server and the hypervisor
-host (using the KVM hypervisor).
-
-|basic-deployment.png: Basic two-machine deployment|
-
-A more full-featured installation consists of a highly-available
-multi-node Management Server installation and up to tens of thousands of
-hosts using any of several advanced networking setups. For information
-about deployment options, see the "Choosing a Deployment Architecture"
-section of the CloudStack Installation Guide.
-
-1.3.1. Management Server Overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-
-The Management Server is the CloudStack software that manages cloud
-resources. By interacting with the Management Server through its UI or
-API, you can configure and manage your cloud infrastructure.
+ Best Practices
-The Management Server runs on a dedicated server or VM. It controls
-allocation of virtual machines to hosts and assigns storage and IP
-addresses to the virtual machine instances. The Management Server runs
-in a Tomcat container and requires a MySQL database for persistence.
+#.
-The machine must meet the system requirements described in System
-Requirements.
+ Make sure you have the required hardware ready. See `Section 4.3,
+ “Minimum System Requirements” <#minimum-system-requirements>`__
-The Management Server:
+#.
--
+ Install the Management Server (choose single-node or multi-node). See
+ `Section 4.5, “Management Server
+ Installation” <#management-server-install-flow>`__
- Provides the web user interface for the administrator and a reference
- user interface for end users.
+#.
--
+ Log in to the UI. See `Chapter 5, *User Interface* <#ui>`__
- Provides the APIs for CloudStack.
+#.
--
+ Add a zone. Includes the first pod, cluster, and host. See
+ `Section 6.3, “Adding a Zone” <#zone-add>`__
- Manages the assignment of guest VMs to particular hosts.
+#.
--
+ Add more pods (optional). See `Section 6.4, “Adding a
+ Pod” <#pod-add>`__
- Manages the assignment of public and private IP addresses to
- particular accounts.
+#.
--
+ Add more clusters (optional). See `Section 6.5, “Adding a
+ Cluster” <#cluster-add>`__
- Manages the allocation of storage to guests as virtual disks.
+#.
--
+ Add more hosts (optional). See `Section 6.6, “Adding a
+ Host” <#host-add>`__
- Manages snapshots, templates, and ISO images, possibly replicating
- them across data centers.
+#.
--
+ Add more primary storage (optional). See `Section 6.7, “Add Primary
+ Storage” <#primary-storage-add>`__
- Provides a single point of configuration for the cloud.
+#.
-1.3.2. Cloud Infrastructure Overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ Add more secondary storage (optional). See `Section 6.8, “Add
+ Secondary Storage” <#secondary-storage-add>`__
-The Management Server manages one or more zones (typically, datacenters)
-containing host computers where guest virtual machines will run. The
-cloud infrastructure is organized as follows:
+#.
--
+ Try using the cloud. See `Section 6.9, “Initialize and
+ Test” <#initialize-and-test>`__
- Zone: Typically, a zone is equivalent to a single datacenter. A zone
- consists of one or more pods and secondary storage.
+Minimum System Requirements
+---------------------------
--
+Management Server, Database, and Storage System Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Pod: A pod is usually one rack of hardware that includes a layer-2
- switch and one or more clusters.
+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 localdisk or NFS. The
+Management Server may be placed on a virtual machine.
-
- Cluster: A cluster consists of one or more hosts and primary storage.
+ Operating system:
--
+ -
- Host: A single compute node within a cluster. The hosts are where the
- actual cloud services run in the form of guest virtual machines.
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
-
- Primary storage is associated with a cluster, and it stores the disk
- volumes for all the VMs running on hosts in that cluster.
+ 64-bit x86 CPU (more cores results in better performance)
-
- Secondary storage is associated with a zone, and it stores templates,
- ISO images, and disk volume snapshots.
-
-|infrastructure_overview.png: Nested organization of a zone|
-
-**More Information**
-
-For more information, see documentation on cloud infrastructure
-concepts.
+ 4 GB of memory
-1.3.3. Networking Overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+-
-CloudStack offers two types of networking scenario:
+ 250 GB of local disk (more results in better capability; 500 GB
+ recommended)
-
- Basic. For AWS-style networking. Provides a single network where
- guest isolation can be provided through layer-3 means such as
- security groups (IP address source filtering).
+ At least 1 NIC
-
- Advanced. For more sophisticated network topologies. This network
- model provides the most flexibility in defining guest networks.
-
-CloudStack Terminology
-======================
-
-2.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 CloudStack deployment. A region is made up
-of several availability zones, where each zone is roughly equivalent to
-a datacenter. Each region is controlled by its own cluster of Management
-Servers, running in one of the zones. The zones in a region are
-typically located in close geographical proximity. Regions are a useful
-technique for providing fault tolerance and disaster recovery.
-
-By grouping zones into regions, the cloud can achieve higher
-availability and scalability. User accounts can span regions, so that
-users can deploy VMs in multiple, widely-dispersed regions. Even if one
-of the regions becomes unavailable, the services are still available to
-the end-user through VMs deployed in another region. And by grouping
-communities of zones under their own nearby Management Servers, the
-latency of communications within the cloud is reduced compared to
-managing widely-dispersed zones from a single central Management Server.
-
-Usage records can also be consolidated and tracked at the region level,
-creating reports or invoices for each geographic region.
-
-|region-overview.png: Nested structure of a region.|
-
-Regions are visible to the end user. When a user starts a guest VM on a
-particular CloudStack Management Server, the user is implicitly
-selecting that region for their guest. Users might also be required to
-copy their private templates to additional regions to enable creation of
-guest VMs using their templates in those regions.
-
-2.2. About Zones
-----------------
-
-A zone is the second largest organizational unit within a CloudStack
-deployment. A zone typically corresponds to a single datacenter,
-although it is permissible to have multiple zones in a datacenter. 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:
+ Statically allocated IP address
-
- One or more pods. Each pod contains one or more clusters of hosts and
- one or more primary storage servers.
+ Fully qualified domain name as returned by the hostname command
--
+Host/Hypervisor System Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- A zone may contain one or more primary storage servers, which are
- shared by all the pods in the zone.
+The host is where the cloud services run in the form of guest virtual
+machines. Each host is one machine that meets the following
+requirements:
-
- Secondary storage, which is shared by all the pods in the zone.
-
-|zone-overview.png: Nested structure of a simple zone.|
+ Must support HVM (Intel-VT or AMD-V enabled).
-Zones are visible to the end user. When a user starts a guest VM, the
-user must select a zone for their guest. Users might also be required to
-copy their private templates to additional zones to enable creation of
-guest VMs using their templates in those zones.
+-
-Zones can be public or private. Public zones are visible to all users.
-This means that any user may create a guest in that zone. Private zones
-are reserved for a specific domain. Only users in that domain or its
-subdomains may create guests in that zone.
+ 64-bit x86 CPU (more cores results in better performance)
-Hosts in the same zone are directly accessible to each other without
-having to go through a firewall. Hosts in different zones can access
-each other through statically configured VPN tunnels.
+-
-For each zone, the administrator must decide the following.
+ Hardware virtualization support required
-
- How many pods to place in each zone.
+ 4 GB of memory
-
- How many clusters to place in each pod.
+ 36 GB of local disk
-
- How many hosts to place in each cluster.
+ At least 1 NIC
+
+.. note::If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack.
-
- (Optional) How many primary storage servers to place in each zone and
- total capacity for these storage servers.
+ Latest hotfixes applied to hypervisor software
-
- How many primary storage servers to place in each cluster and total
- capacity for these storage servers.
+ When you deploy CloudStack, the hypervisor host must not have any VMs
+ already running
-
- How much secondary storage to deploy in a zone.
-
-When you add a new zone using the CloudStack UI, you will be prompted to
-configure the zone’s physical network and add the first pod, cluster,
-host, primary storage, and secondary storage.
+ All hosts within a cluster must be homogeneous. The CPUs must be of
+ the same type, count, and feature flags.
-In order to support zone-wide functions for VMware, CloudStack is aware
-of VMware Datacenters and can map each Datacenter to a CloudStack zone.
-To enable features like storage live migration and zone-wide primary
-storage for VMware hosts, CloudStack has to make sure that a zone
-contains only a single VMware Datacenter. Therefore, when you are
-creating a new CloudStack zone, you can select a VMware Datacenter for
-the zone. If you are provisioning multiple VMware Datacenters, each one
-will be set up as a single zone in CloudStack.
+Hosts have additional requirements depending on the hypervisor. See the
+requirements listed at the top of the Installation section for your
+chosen hypervisor:
-.. note:: If you are upgrading from a previous CloudStack version, and your existing deployment contains a zone with clusters from multiple VMware Datacenters, that zone will not be forcibly migrated to the new model. It will continue to function as before. However, any new zone-wide operations, such as zone-wide primary storage and live storage migration, will not be available in that zone.
+.. warning::Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
-2.3. About Pods
----------------
+Configure package repository
+----------------------------
-A pod often represents a single rack. Hosts in the same pod are in the
-same subnet. A pod is the third-largest organizational unit within a
-CloudStack deployment. Pods are contained within zones. Each zone can
-contain one or more pods. A pod consists of one or more clusters of
-hosts and one or more primary storage servers. Pods are not visible to
-the end user.
+CloudStack is only distributed from source from the official mirrors.
+However, members of the CloudStack community may build convenience
+binaries so that users can install Apache CloudStack without needing to
+build from source.
-|pod-overview.png: Nested structure of a simple pod|
+If you didn't follow the steps to build your own packages from source in
+the sections for `Section 3.6, “Building RPMs from
+Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
+packages” <#sect-source-builddebs>`__ you may find pre-built DEB and RPM
+packages for your convenience linked from the
+`downloads <http://cloudstack.apache.org/downloads.html>`__ page.
-2.4. About Clusters
--------------------
+.. note::These repositories contain both the Management Server and KVM Hypervisor packages.
-A cluster provides a way to group hosts. To be precise, a cluster is a
-XenServer server pool, a set of KVM servers, , 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. Virtual machine instances (VMs) can be
-live-migrated from one host to another within the same cluster, without
-interrupting service to the user.
+DEB package repository
+~~~~~~~~~~~~~~~~~~~~~~
-A cluster is the fourth-largest organizational unit within a CloudStack
-deployment. Clusters are contained within pods, and pods are contained
-within zones. Size of the cluster is limited by the underlying
-hypervisor, although the CloudStack recommends less in most cases; see
-Best Practices.
+You can add a DEB package repository to your apt sources with the
+following commands. Please note that only packages for Ubuntu 12.04 LTS
+(precise) are being built at this time.
-A cluster consists of one or more hosts and one or more primary storage
-servers.
+Use your preferred editor and open (or create)
+``/etc/apt/sources.list.d/cloudstack.list``. Add the community provided
+repository to the file:
-|cluster-overview.png: Structure of a simple cluster|
+.. code:: bash
-CloudStack allows multiple clusters in a cloud deployment.
+ deb http://cloudstack.apt-get.eu/ubuntu precise 4.2
-Even when local storage is used exclusively, clusters are still required
-organizationally, even if there is just one host per cluster.
+We now have to add the public key to the trusted keys.
-When VMware is used, every VMware cluster is managed by a vCenter
-server. An Administrator must register the vCenter server with
-CloudStack. There may be multiple vCenter servers per zone. Each vCenter
-server may manage multiple VMware clusters.
+.. code:: bash
-2.5. About Hosts
-----------------
+ $ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
-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, an ESXi server, or a
-Windows Hyper-V server.
+Now update your local apt cache.
-The host is the smallest organizational unit within a CloudStack
-deployment. Hosts are contained within clusters, clusters are contained
-within pods, pods are contained within zones, and zones can be contained
-within regions.
+.. code:: bash
-Hosts in a CloudStack deployment:
+ $ apt-get update
--
+Your DEB package repository should now be configured and ready for use.
- Provide the CPU, memory, storage, and networking resources needed to
- host the virtual machines
+RPM package repository
+~~~~~~~~~~~~~~~~~~~~~~
--
+There is a RPM package repository for CloudStack so you can easily
+install on RHEL based platforms.
- Interconnect using a high bandwidth TCP/IP network and connect to the
- Internet
+If you're using an RPM-based system, you'll want to add the Yum
+repository so that you can install CloudStack with Yum.
--
+Yum repository information is found under ``/etc/yum.repos.d``. You'll
+see several ``.repo`` files in this directory, each one denoting a
+specific repository.
- May reside in multiple data centers across different geographic
- locations
+To add the CloudStack repository, create
+``/etc/yum.repos.d/cloudstack.repo`` and insert the following
+information.
--
+.. code:: bash
- May have different capacities (different CPU speeds, different
- amounts of RAM, etc.), although the hosts within a cluster must all
- be homogeneous
+ [cloudstack]
+ name=cloudstack
+ baseurl=http://cloudstack.apt-get.eu/rhel/4.2/
+ enabled=1
+ gpgcheck=0
-Additional hosts can be added at any time to provide more capacity for
-guest VMs.
+Now you should be able to install CloudStack using Yum.
-CloudStack automatically detects the amount of CPU and memory resources
-provided by the hosts.
+Management Server Installation
+------------------------------
-Hosts are not visible to the end user. An end user cannot determine
-which host their guest has been assigned to.
+Management Server Installation Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For a host to function in CloudStack, you must do the following:
+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:
-
- Install hypervisor software on the host
+ A single Management Server node, with MySQL on the same node.
-
- Assign an IP address to the host
-
--
+ Multiple Management Server nodes, with MySQL on a node separate from
+ the Management Servers.
- Ensure the host is connected to the CloudStack Management Server.
+In either case, each machine must meet the system requirements described
+in System Requirements.
-2.6. About Primary Storage
---------------------------
+.. warning::For the sake of security, be sure the public Internet can not access
+port 8096 or port 8250 on the Management Server.
-Primary storage is associated with a cluster or (in KVM and VMware) a
-zone, and it stores the disk volumes for all the VMs running on hosts.
+The procedure for installing the Management Server is:
-You can add multiple primary storage servers to a cluster or zone. At
-least one is required. It is typically located close to the hosts for
-increased performance. CloudStack manages the allocation of guest
-virtual disks to particular primary storage devices.
+#.
-It is useful to set up zone-wide primary storage when you want to avoid
-extra data copy operations. With cluster-based primary storage, data in
-the primary storage is directly available only to VMs within that
-cluster. If a VM in a different cluster needs some of the data, it must
-be copied from one cluster to another, using the zone's secondary
-storage as an intermediate step. This operation can be unnecessarily
-time-consuming.
+ Prepare the Operating System
-For Hyper-V, SMB/CIFS storage is supported. Note that Zone-wide Primary
-Storage is not supported in Hyper-V.
+#.
-CloudStack is designed to work with all standards-compliant iSCSI and
-NFS servers that are supported by the underlying hypervisor, including,
-for example:
+ (XenServer only) Download and install vhd-util.
--
+#.
- Dell EqualLogic™ for iSCSI
+ Install the First Management Server
--
+#.
- Network Appliances filers for NFS and iSCSI
+ Install and Configure the MySQL database
--
+#.
- Scale Computing for NFS
+ Prepare NFS Shares
-If you intend to use only local disk for your installation, you can skip
-adding separate primary storage.
+#.
-2.7. About Secondary Storage
-----------------------------
+ Prepare and Start Additional Management Servers (optional)
-Secondary storage stores the following:
+#.
--
+ Prepare the System VM Template
- Templates — OS images that can be used to boot VMs and can include
- additional configuration information, such as installed applications
+Prepare the Operating System
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
+The OS must be prepared to host the Management Server using the
+following steps. These steps must be performed on each Management Server
+node.
- ISO images — disc images containing data or bootable media for
- operating systems
+#.
--
+ Log in to your OS as root.
- Disk volume snapshots — saved copies of VM data which can be used for
- data recovery or to create new templates
+#.
-The items in secondary storage are available to all hosts in the scope
-of the secondary storage, which may be defined as per zone or per
-region.
+ Check for a fully qualified hostname.
-To make items in secondary storage available to all hosts throughout the
-cloud, you can add object storage in addition to the zone-based NFS
-Secondary Staging Store. It is not necessary to copy templates and
-snapshots from one zone to another, as would be required when using zone
-NFS alone. Everything is available everywhere.
+ .. code:: bash
-For Hyper-V hosts, SMB/CIFS storage is supported.
+ hostname --fqdn
-CloudStack provides plugins that enable both OpenStack Object Storage
-(Swift, `swift.openstack.org <http://swift.openstack.org>`__) and Amazon
-Simple Storage Service (S3) object storage. When using one of these
-storage plugins, you configure Swift or S3 storage for the entire
-CloudStack, then set up the NFS Secondary Staging Store for each zone.
-The NFS storage in each zone acts as a staging area through which all
-templates and other secondary storage data pass before being forwarded
-to Swift or S3. The backing object storage acts as a cloud-wide
-resource, making templates and other data available to any zone in the
-cloud.
+ This should return a fully qualified hostname such as
+ "management1.lab.example.org". If it does not, edit /etc/hosts so
+ that it does.
-.. warning:: Heterogeneous Secondary Storage is not supported in Regions. For example, you cannot set up multiple zones, one using NFS secondary and the other using S3 or Swift secondary.
+#.
-2.8. About Physical Networks
-----------------------------
+ Make sure that the machine can reach the Internet.
-Part of adding a zone is setting up the physical network. One or (in an
-advanced zone) more physical networks can be associated with each zone.
-The network corresponds to a NIC on the hypervisor host. Each physical
-network can carry one or more types of network traffic. The choices of
-traffic type for each network vary depending on whether you are creating
-a zone with basic networking or advanced networking.
+ .. code:: bash
-A physical network is the actual network hardware and wiring in a zone.
-A zone can have multiple physical networks. An administrator can:
+ ping www.cloudstack.org
--
+#.
- Add/Remove/Update physical networks in a zone
+ Turn on NTP for time synchronization.
--
+.. note::NTP is required to synchronize the clocks of the servers in your
+ cloud.
- Configure VLANs on the physical network
+ #.
--
+ Install NTP.
- Configure a name so the network can be recognized by hypervisors
+ .. code:: bash
--
+ yum install ntp
- Configure the service providers (firewalls, load balancers, etc.)
- available on a physical network
+ .. code:: bash
--
+ apt-get install openntpd
- Configure the IP addresses trunked to a physical network
+#.
--
+ Repeat all of these steps on every host where the Management Server
+ will be installed.
- Specify what type of traffic is carried on the physical network, as
- well as other properties like network speed
+Install the Management Server on the First Host
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-2.8.1. Basic Zone Network Traffic Types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The first step in installation, whether you are installing the
+Management Server on one host or many, is to install the software on a
+single node.
-When basic networking is used, there can be only one physical network in
-the zone. That physical network carries the following traffic types:
+.. note::If you are planning to install the Management Server on multiple nodes
+for high availability, do not proceed to the additional nodes yet. That
+step will come later.
--
+The CloudStack Management server can be installed using either RPM or
+DEB packages. These packages will depend on everything you need to run
+the Management server.
- Guest. When end users run VMs, they generate guest traffic. The guest
- VMs communicate with each other over a network that can be referred
- to as the guest network. Each pod in a basic zone is a broadcast
- domain, and therefore each pod has a different IP range for the guest
- network. The administrator must configure the IP range for each pod.
+Install on CentOS/RHEL
+^^^^^^^^^^^^^^^^^^^^^^
--
+We start by installing the required packages:
- Management. When CloudStack's internal resources communicate with
- each other, they generate management traffic. This includes
- communication between hosts, system VMs (VMs used by CloudStack to
- perform various tasks in the cloud), and any other component that
- communicates directly with the CloudStack Management Server. You must
- configure the IP range for the system VMs to use.
+.. code:: bash
-.. note:: We strongly recommend the use of separate NICs for management traffic
- and guest traffic.
+ yum install cloudstack-management
--
+Install on Ubuntu
+^^^^^^^^^^^^^^^^^
- Public. Public traffic is generated when VMs in the cloud access the
- Internet. Publicly accessible IPs must be allocated for this purpose.
- End users can use the CloudStack UI to acquire these IPs to implement
- NAT between their guest network and the public network, as described
- in Acquiring a New IP Address.
+.. code:: bash
--
+ apt-get install cloudstack-management
- Storage. While labeled "storage" this is specifically about secondary
- storage, and doesn't affect traffic for primary storage. This
- includes traffic such as VM templates and snapshots, which is sent
- between the secondary storage VM and secondary storage servers.
- CloudStack uses a separate Network Interface Controller (NIC) named
- storage NIC for storage network traffic. Use of a storage NIC that
- always operates on a high bandwidth network allows fast template and
- snapshot copying. You must configure the IP range to use for the
- storage network.
-
-In a basic network, configuring the physical network is fairly
-straightforward. In most cases, you only need to configure one guest
-network to carry traffic that is generated by guest VMs. If you use a
-NetScaler load balancer and enable its elastic IP and elastic load
-balancing (EIP and ELB) features, you must also configure a network to
-carry public traffic. CloudStack takes care of presenting the necessary
-network configuration steps to you in the UI when you add a new zone.
-
-2.8.2. Basic Zone Guest IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When basic networking is used, CloudStack 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.
-
-2.8.3. Advanced Zone Network Traffic Types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When advanced networking is used, there can be multiple physical
-networks in the zone. Each physical network can carry one or more
-traffic types, and you need to let CloudStack know which type of network
-traffic you want each network to carry. The traffic types in an advanced
-zone are:
+Downloading vhd-util
+^^^^^^^^^^^^^^^^^^^^
--
+This procedure is required only for installations where XenServer is
+installed on the hypervisor hosts.
- Guest. When end users run VMs, they generate guest traffic. The guest
- VMs communicate with each other over a network that can be referred
- to as the guest network. This network can be isolated or shared. In
- an isolated guest network, the administrator needs to reserve VLAN
- ranges to provide isolation for each CloudStack account’s network
- (potentially a large number of VLANs). In a shared guest network, all
- guest VMs share a single network.
+Before setting up the Management Server, download vhd-util from
+`vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__.
--
+If the Management Server is RHEL or CentOS, copy vhd-util to
+/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
- Management. When CloudStack’s internal resources communicate with
- each other, they generate management traffic. This includes
- communication between hosts, system VMs (VMs used by CloudStack to
- perform various tasks in the cloud), and any other component that
- communicates directly with the CloudStack Management Server. You must
- configure the IP range for the system VMs to use.
+If the Management Server is Ubuntu, copy vhd-util to
+/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
--
+Install the database server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Public. Public traffic is generated when VMs in the cloud access the
- Internet. Publicly accessible IPs must be allocated for this purpose.
- End users can use the CloudStack UI to acquire these IPs to implement
- NAT between their guest network and the public network, as described
- in “Acquiring a New IP Address” in the Administration Guide.
+The CloudStack management server 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 locally. For an installation that
+has multiple management server nodes, we assume the MySQL database also
+runs on a separate node.
--
+CloudStack has been tested with MySQL 5.1 and 5.5. These versions are
+included in RHEL/CentOS and Ubuntu.
- Storage. While labeled "storage" this is specifically about secondary
- storage, and doesn't affect traffic for primary storage. This
- includes traffic such as VM templates and snapshots, which is sent
- between the secondary storage VM and secondary storage servers.
- CloudStack uses a separate Network Interface Controller (NIC) named
- storage NIC for storage network traffic. Use of a storage NIC that
- always operates on a high bandwidth network allows fast template and
- snapshot copying. You must configure the IP range to use for the
- storage network.
-
-These traffic types can each be on a separate physical network, or they
-can be combined with certain restrictions. When you use the Add Zone
-wizard in the UI to create a new zone, you are guided into making only
-valid choices.
-
-2.8.4. Advanced Zone Guest IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Install the Database on the Management Server Node
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-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. Additionally, the administrator can reserve a part
-of the IP address space for non-CloudStack VMs and servers.
+This section describes how to install MySQL on the same machine with the
+Management Server. This technique is intended for a simple deployment
+that has a single Management Server node. If you have a multi-node
+Management Server deployment, you will typically use a separate node for
+MySQL. See `Section 4.5.4.2, “Install the Database on a Separate
+Node” <#management-server-install-db-external>`__.
-2.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.
+ Install MySQL from the package repository of your distribution:
-2.8.6. System Reserved IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ .. code:: bash
-In each zone, you need to configure a range of reserved IP addresses for
-the management network. This network carries communication between the
-CloudStack Management Server and various system VMs, such as Secondary
-Storage VMs, Console Proxy VMs, and DHCP.
+ yum install mysql-server
-The reserved IP addresses must be unique across the cloud. You cannot,
-for example, have a host in one zone which has the same private IP
-address as a host in another zone.
+ .. code:: bash
-The hosts in a pod are assigned private IP addresses. These are
-typically RFC1918 addresses. The Console Proxy and Secondary Storage
-system VMs are also allocated private IP addresses in the CIDR of the
-pod that they are created in.
+ apt-get install mysql-server
-Make sure computing servers and Management Servers use IP addresses
-outside of the System Reserved IP range. For example, suppose the System
-Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7.
-CloudStack can use .2 to .7 for System VMs. This leaves the rest of the
-pod CIDR, from .8 to .254, for the Management Server and hypervisor
-hosts.
+#.
-**In all zones:**
+ Open the MySQL configuration file. The configuration file is
+ ``/etc/my.cnf`` or ``/etc/mysql/my.cnf``, depending on your OS.
-Provide private IPs for the system in each pod and provision them in
-CloudStack.
+#.
-For KVM and XenServer, the recommended number of private IPs per pod is
-one per host. If you expect a pod to grow, add enough private IPs now to
-accommodate the growth.
-
-**In a zone that uses advanced networking:**
-
-For zones with advanced networking, we recommend provisioning enough
-private IPs for your total number of customers, plus enough for the
-required CloudStack System VMs. Typically, about 10 additional IPs are
-required for the System VMs. For more information about System VMs, see
-the section on working with SystemVMs in the Administrator's Guide.
-
-When advanced networking is being used, the number of private IP
-addresses available in each pod varies depending on which hypervisor is
-running on the nodes in that pod. Citrix XenServer and KVM use
-link-local addresses, which in theory provide more than 65,000 private
-IP addresses within the address block. As the pod grows over time, this
-should be more than enough for any reasonable number of hosts as well as
-IP addresses for guest virtual routers. VMWare ESXi, by contrast uses
-any administrator-specified subnetting scheme, and the typical
-administrator provides only 255 IPs per pod. Since these are shared by
-physical machines, the guest virtual router, and other entities, it is
-possible to run out of private IPs when scaling up a pod whose nodes are
-running ESXi.
-
-To ensure adequate headroom to scale private IP space in an ESXi pod
-that uses advanced networking, use one or both of the following
-techniques:
+ 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 one Management
+ Server.
- Specify a larger CIDR block for the subnet. A subnet mask with a /20
- suffix will provide more than 4,000 IP addresses.
+.. note::On Ubuntu, you can also create a file
+ `/etc/mysql/conf.d/cloudstack.cnf` and add these directives there.
+ Don't forget to add [mysqld] on the first line of the file.
--
+ .. code:: bash
- Create multiple pods, each with its own subnet. For example, if you
- create 10 pods and each pod has 255 IPs, this will provide 2,550 IP
- addresses.
+ innodb_rollback_on_timeout=1
+ innodb_lock_wait_timeout=600
+ max_connections=350
+ log-bin=mysql-bin
+ binlog-format = 'ROW'
-Building from Source
-====================
+#.
-The official CloudStack release is always in source code form. You will
-likely be able to find "convenience binaries," the source is the
-canonical release. In this section, we'll cover acquiring the source
-release and building that so that you can deploy it using Maven or
-create Debian packages or RPMs.
+ Start or restart MySQL to put the new configuration into effect.
-Note that building and deploying directly from source is typically not
-the most efficient way to deploy an IaaS. However, we will cover that
-method as well as building RPMs or Debian packages for deploying
-CloudStack.
+ On RHEL/CentOS, MySQL doesn't automatically start after installation.
+ Start it manually.
-The instructions here are likely version-specific. That is, the method
-for building from source for the 4.0.x series is different from the
-4.1.x series.
+ .. code:: bash
-If you are working with a unreleased version of CloudStack, see the
-INSTALL.md file in the top-level directory of the release.
+ service mysqld start
-3.1. Getting the release
-------------------------
+ On Ubuntu, restart MySQL.
-You can download the latest CloudStack release from the `Apache
-CloudStack project download
-page <http://incubator.apache.org/cloudstack/downloads.html>`__.
+ .. code:: bash
-Prior releases are available via archive.apache.org as well. See the
-downloads page for more information on archived releases.
+ service mysql restart
-You'll notice several links under the 'Latest release' section. A link
-to a file ending in ``tar.bz2``, as well as a PGP/GPG signature, MD5,
-and SHA512 file.
+#.
--
+ (CentOS and RHEL only; not required on Ubuntu)
- The ``tar.bz2`` file contains the Bzip2-compressed tarball with the
- source code.
+ Warning
+
+ On RHEL and CentOS, MySQL does not set a root password by default. It
+ is very strongly recommended that you set a root password as a
+ security precaution.
--
+ Run the following command to secure your installation. You can answer
+ "Y" to all questions.
- The ``.asc`` file is a detached cryptographic signature that can be
- used to help verify the authenticity of the release.
+ .. code:: bash
--
+ mysql_secure_installation
- The ``.md5`` file is an MD5 hash of the release to aid in verify the
- validity of the release download.
+#.
--
+ CloudStack can be blocked by security mechanisms, such as SELinux.
+ Disable SELinux to ensure + that the Agent has all the required
+ permissions.
- The ``.sha`` file is a SHA512 hash of the release to aid in verify
- the validity of the release download.
+ Configure SELinux (RHEL and CentOS):
-3.2. Verifying the downloaded release
--------------------------------------
+ #.
-There are a number of mechanisms to check the authenticity and validity
-of a downloaded release.
+ Check whether SELinux is installed on your machine. If not, you
+ can skip this section.
-3.2.1. Getting the KEYS
-~~~~~~~~~~~~~~~~~~~~~~~
+ In RHEL or CentOS, SELinux is installed and enabled by default.
+ You can verify this with:
-To enable you to verify the GPG signature, you will need to download the
-`KEYS <http://www.apache.org/dist/incubator/cloudstack/KEYS>`__ file.
+ .. code:: bash
-You next need to import those keys, which you can do by running:
+ $ rpm -qa | grep selinux
-.. code:: bash
+ #.
- # gpg --import KEYS
+ Set the SELINUX variable in ``/etc/selinux/config`` to
+ "permissive". This ensures that the permissive setting will be
+ maintained after a system reboot.
-3.2.2. GPG
-~~~~~~~~~~
+ In RHEL or CentOS:
-The CloudStack project provides a detached GPG signature of the release.
-To check the signature, run the following command:
+ .. code:: bash
-.. code:: bash
+ vi /etc/selinux/config
- $ gpg --verify apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc
+ Change the following line
-If the signature is valid you will see a line of output that contains
-'Good signature'.
+ .. code:: bash
-3.2.3. MD5
-~~~~~~~~~~
+ SELINUX=enforcing
-In addition to the cryptographic signature, CloudStack has an MD5
-checksum that you can use to verify the download matches the release.
-You can verify this hash by executing the following command:
+ to this:
-.. code:: bash
+ .. code:: bash
- $ gpg --print-md MD5 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5
+ SELINUX=permissive
-If this successfully completes you should see no output. If there is any
-output from them, then there is a difference between the hash you
-generated locally and the hash that has been pulled from the server.
+ #.
-3.2.4. SHA512
-~~~~~~~~~~~~~
+ Set SELinux to permissive starting immediately, without requiring
+ a system reboot.
-In addition to the MD5 hash, the CloudStack project provides a SHA512
-cryptographic hash to aid in assurance of the validity of the downloaded
-release. You can verify this hash by executing the following command:
+ .. code:: bash
-.. code:: bash
+ $ setenforce permissive
- $ gpg --print-md SHA512 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha
+#.
-If this command successfully completes you should see no output. If
-there is any output from them, then there is a difference between the
-hash you generated locally and the hash that has been pulled from the
-server.
+ Set up the database. The following command creates the "cloud" user
+ on the database.
-3.3. Prerequisites for building Apache CloudStack
--------------------------------------------------
+ -
-There are a number of prerequisites needed to build CloudStack. This
-document assumes compilation on a Linux system that uses RPMs or DEBs
-for package management.
+ In dbpassword, specify the password to be assigned to the "cloud"
+ user. You can choose to provide no password although that is not
+ recommended.
-You will need, at a minimum, the following to compile CloudStack:
+ -
-#.
+ 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.
- Maven (version 3)
+ -
-#.
+ (Optional) For encryption\_type, use file or web to indicate the
+ technique used to pass in the database encryption password.
+ Default: file. See `Section 4.5.5, “About Password and Key
+ Encryption” <#about-password-encryption>`__.
- Java (OpenJDK 1.6 or Java 7/OpenJDK 1.7)
+ -
-#.
+ (Optional) For management\_server\_key, substitute the default key
+ that is used to encrypt confidential parameters in the CloudStack
+ properties file. Default: password. It is highly recommended that
+ you replace this with a more secure value. See `Section 4.5.5,
+ “About Password and Key
+ Encryption” <#about-password-encryption>`__.
- Apache Web Services Common Utilities (ws-commons-util)
+ -
-#.
+ (Optional) For database\_key, substitute the default key that is
+ used to encrypt confidential parameters in the CloudStack
+ database. Default: password. It is highly recommended that you
+ replace this with a more secure value. See `Section 4.5.5, “About
+ Password and Key Encryption” <#about-password-encryption>`__.
- MySQL
+ -
-#.
+ (Optional) For management\_server\_ip, you may explicitly specify
+ cluster management server node IP. If not specified, the local IP
+ address will be used.
+
+ .. code:: bash
- MySQLdb (provides Python database API)
+ cloudstack-setup-databases cloud:<dbpassword>@localhost \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key> \
+ -i <management_server_ip>
-#.
+ When this script is finished, you should see a message like
+ “Successfully initialized the database.”
- Tomcat 6 (not 6.0.35)
+ Note
-#.
- genisoimage
+ If the script is unable to connect to the MySQL database, check the
+ "localhost" loopback address in ``/etc/hosts``. It should be pointing
+ to the IPv4 loopback address "127.0.0.1" and not the IPv6 loopback
+ address ::1. Alternatively, reconfigure MySQL to bind to the IPv6
+ loopback interface.
#.
- rpmbuild or dpkg-dev
-
-3.4. Extracting source
-----------------------
+ If you are running the KVM hypervisor on the same machine with the
+ Management Server, edit /etc/sudoers and add the following line:
-Extracting the CloudStack release is relatively simple and can be done
-with a single command as follows:
+ .. code:: bash
-.. code:: bash
+ Defaults:cloud !requiretty
- $ tar -jxvf apache-cloudstack-4.1.0.src.tar.bz2
+#.
-You can now move into the directory:
+ Now that the database is set up, you can finish configuring the OS
+ for the Management Server. This command will set up iptables,
+ sudoers, and start the Management Server.
-.. code:: bash
+ .. code:: bash
- $ cd ./apache-cloudstack-4.1.0-src
+ # cloudstack-setup-management
-3.5. Building DEB packages
---------------------------
+ You should see the message “CloudStack Management Server setup is
+ done.”
-In addition to the bootstrap dependencies, you'll also need to install
-several other dependencies. Note that we recommend using Maven 3, which
-is not currently available in 12.04.1 LTS. So, you'll also need to add a
-PPA repository that includes Maven 3. After running the command
-``add-apt-repository``, you will be prompted to continue and a GPG key
-will be added.
+Install the Database on a Separate Node
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. code:: bash
+This section describes how to install MySQL on a standalone machine,
+separate from the Management Server. This technique is intended for a
+deployment that includes several Management Server nodes. If you have a
+single-node Management Server deployment, you will typically use the
+same node for MySQL. See `Section 4.5.4.1, “Install the Database on the
+Management Server Node” <#management-server-install-db-local>`__.
- $ sudo apt-get update
- $ sudo apt-get install python-software-properties
- $ sudo add-apt-repository ppa:natecarlson/maven3
- $ sudo apt-get update
- $ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
+.. note:: The management server doesn't require a specific distribution for the
+MySQL node. You can use a distribution or Operating System of your
+choice. Using the same distribution as the management server is
+recommended, but not required. See `Section 4.3.1, “Management Server,
+Database, and Storage System Requirements” <#management-server-system-requirements>`__.
-While we have defined, and you have presumably already installed the
-bootstrap prerequisites, there are a number of build time prerequisites
-that need to be resolved. CloudStack uses maven for dependency
-resolution. You can resolve the buildtime depdencies for CloudStack by
-running:
+#.
-.. code:: bash
+ Install MySQL from the package repository from your distribution:
- $ mvn3 -P deps
+ .. code:: bash
-Now that we have resolved the dependencies we can move on to building
-CloudStack and packaging them into DEBs by issuing the following
-command.
+ yum install mysql-server
-.. code:: bash
+ .. code:: bash
- $ dpkg-buildpackage -uc -us
+ apt-get install mysql-server
-This command will build the following debian packages. You should have
-all of the following:
+#.
-.. code:: bash
+ 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.
- cloudstack-common-4.2.0.amd64.deb
- cloudstack-management-4.2.0.amd64.deb
- cloudstack-agent-4.2.0.amd64.deb
- cloudstack-usage-4.2.0.amd64.deb
- cloudstack-awsapi-4.2.0.amd64.deb
- cloudstack-cli-4.2.0.amd64.deb
- cloudstack-docs-4.2.0.amd64.deb
-
-3.5.1. Setting up an APT repo
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After you've created the packages, you'll want to copy them to a system
-where you can serve the packages over HTTP. You'll create a directory
-for the packages and then use ``dpkg-scanpackages`` to create
-``Packages.gz``, which holds information about the archive structure.
-Finally, you'll add the repository to your system(s) so you can install
-the packages using APT.
-
-The first step is to make sure that you have the **dpkg-dev** package
-installed. This should have been installed when you pulled in the
-**debhelper** application previously, but if you're generating
-``Packages.gz`` on a different system, be sure that it's installed there
-as well.
+.. note:: On Ubuntu, you can also create /etc/mysql/conf.d/cloudstack.cnf file
+ and add these directives there. Don't forget to add [mysqld] on the
+ first line of the file.
.. code:: bash
- $ sudo apt-get install dpkg-dev
+ innodb_rollback_on_timeout=1
+ innodb_lock_wait_timeout=600
+ max_connections=700
+ log-bin=mysql-bin
+ binlog-format = 'ROW'
+ bind-address = 0.0.0.0
-The next step is to copy the DEBs to the directory where they can be
-served over HTTP. We'll use ``/var/www/cloudstack/repo`` in the
-examples, but change the directory to whatever works for you.
+#.
-.. code:: bash
+ Start or restart MySQL to put the new configuration into effect.
- sudo mkdir -p /var/www/cloudstack/repo/binary
- sudo cp *.deb /var/www/cloudstack/repo/binary
- sudo cd /var/www/cloudstack/repo/binary
- sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz
+ On RHEL/CentOS, MySQL doesn't automatically start after installation.
+ Start it manually.
-.. note:: You can safely ignore the warning about a missing override file.
+ .. code:: bash
-Now you should have all of the DEB packages and ``Packages.gz`` in the
-``binary`` directory and available over HTTP. (You may want to use
-``wget`` or ``curl`` to test this before moving on to the next step.)
+ service mysqld start
-3.5.2. Configuring your machines to use the APT repository
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ On Ubuntu, restart MySQL.
-Now that we have created the repository, you need to configure your
-machine to make use of the APT repository. You can do this by adding a
-repository file under ``/etc/apt/sources.list.d``. Use your preferred
-editor to create ``/etc/apt/sources.list.d/cloudstack.list`` with this
-line:
+ .. code:: bash
-.. code:: bash
+ service mysql restart
- deb http://server.url/cloudstack/repo binary ./
+#.
-Now that you have the repository info in place, you'll want to run
-another update so that APT knows where to find the CloudStack packages.
+ (CentOS and RHEL only; not required on Ubuntu)
-.. code:: bash
+.. warning:: On RHEL and CentOS, MySQL does not set a root password by default. It
+ is very strongly recommended that you set a root password as a
+ security precaution. Run the following command to secure your installation. You can answer
+ "Y" to all questions except "Disallow root login remotely?". Remote
+ root login is required to set up the databases.
- $ sudo apt-get update
+ .. code:: bash
-You can now move on to the instructions under Install on Ubuntu.
+ mysql_secure_installation
-3.6. Building RPMs from Source
-------------------------------
+#.
-As mentioned previously in `Section 3.3, “Prerequisites for building
-Apache CloudStack” <#sect-source-prereq>`__, you will need to install
-several prerequisites before you can build packages for CloudStack. Here
-we'll assume you're working with a 64-bit build of CentOS or Red Hat
-Enterprise Linux.
+ If a firewall is present on the system, open TCP port 3306 so
+ external MySQL connections can be established.
-::
+ On Ubuntu, UFW is the default firewall. Open the port with this
+ command:
- # yum groupinstall "Development Tools"
+ .. code:: bash
-::
+ ufw allow mysql
- # yum install java-1.6.0-openjdk-devel.x86_64 genisoimage mysql mysql-server ws-commons-util MySQL-python tomcat6 createrepo
+ On RHEL/CentOS:
-Next, you'll need to install build-time dependencies for CloudStack with
-Maven. We're using Maven 3, so you'll want to `grab a Maven 3
-tarball <http://maven.apache.org/download.cgi>`__ and uncompress it in
-your home directory (or whatever location you prefer):
+ #.
-::
+ Edit the /etc/sysconfig/iptables file and add the following line
+ at the beginning of the INPUT chain.
- $ tar zxvf apache-maven-3.0.4-bin.tar.gz
+ .. code:: bash
-::
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
- $ export PATH=/usr/local/apache-maven-3.0.4//bin:$PATH
+ #.
-Maven also needs to know where Java is, and expects the JAVA\_HOME
-environment variable to be set:
+ Now reload the iptables rules.
-::
+ .. code:: bash
- $ export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
-
-Verify that Maven is installed correctly:
-
-::
-
- $ mvn --version
-
-You probably want to ensure that your environment variables will survive
-a logout/reboot. Be sure to update ``~/.bashrc`` with the PATH and
-JAVA\_HOME variables.
-
-Building RPMs for CloudStack is fairly simple. Assuming you already have
-the source downloaded and have uncompressed the tarball into a local
-directory, you're going to be able to generate packages in just a few
-minutes.
-
-.. note:: Packaging has Changed. If you've created packages for CloudStack previously, you should be
-aware that the process has changed considerably since the project has moved to using Apache Maven. Please be sure to follow the steps in this section closely.
-
-3.6.1. Generating RPMS
-~~~~~~~~~~~~~~~~~~~~~~
-
-Now that we have the prerequisites and source, you will cd to the `packaging/centos63/` directory.
-
-::
-
- $ cd packaging/centos63
-
-Generating RPMs is done using the ``package.sh`` script:
-
-::
-
- $./package.sh
-
-That will run for a bit and then place the finished packages in
-``dist/rpmbuild/RPMS/x86_64/``.
-
-You should see the following RPMs in that directory:
-
-::
-
- cloudstack-agent-4.2.0.el6.x86_64.rpm
- cloudstack-awsapi-4.2.0.el6.x86_64.rpm
- cloudstack-cli-4.2.0.el6.x86_64.rpm
- cloudstack-common-4.2.0.el6.x86_64.rpm
- cloudstack-docs-4.2.0.el6.x86_64.rpm
- cloudstack-management-4.2.0.el6.x86_64.rpm
- cloudstack-usage-4.2.0.el6.x86_64.rpm
-
-3.6.1.1. Creating a yum repo
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-While RPMs is a useful packaging format - it's most easily consumed from
-Yum repositories over a network. The next step is to create a Yum Repo
-with the finished packages:
-
-::
-
- $ mkdir -p ~/tmp/repo
-
-::
-
- $ cp dist/rpmbuild/RPMS/x86_64/*rpm ~/tmp/repo/
-
-::
-
- $ createrepo ~/tmp/repo
-
-The files and directories within ``~/tmp/repo`` can now be uploaded to a
-web server and serve as a yum repository.
-
-3.6.1.2. Configuring your systems to use your new yum repository
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Now that your yum repository is populated with RPMs and metadata we need
-to configure the machines that need to install CloudStack. Create a file
-named ``/etc/yum.repos.d/cloudstack.repo`` with this information:
-
-::
-
- [apache-cloudstack]
- name=Apache CloudStack
- baseurl=http://webserver.tld/path/to/repo
- enabled=1
- gpgcheck=0
-
-Completing this step will allow you to easily install CloudStack on a
-number of machines across the network.
-
-3.7. Building Non-OSS
----------------------
-
-If you need support for the VMware, NetApp, F5, NetScaler, SRX, or any
-other non-Open Source Software (nonoss) plugins, you'll need to download
-a few components on your own and follow a slightly different procedure
-to build from source.
-
-Why Non-OSS?
-------------
-
-Some of the plugins supported by CloudStack cannot be distributed with
-CloudStack for licensing reasons. In some cases, some of the required
-libraries/JARs are under a proprietary license. In other cases, the
-required libraries may be under a license that's not compatible with
-`Apache's licensing guidelines for third-party
-products <http://www.apache.org/legal/resolved.html#category-x>`__.
-
-#.
-
- To build the Non-OSS plugins, you'll need to have the requisite JARs
- installed under the ``deps`` directory.
-
- Because these modules require dependencies that can't be distributed
- with CloudStack you'll need to download them yourself. Links to the
- most recent dependencies are listed on the `*How to build on master
- branch* <https://cwiki.apache.org/CLOUDSTACK/how-to-build-on-master-branch.html>`__
- page on the wiki.
-
-#.
-
- You may also need to download
- `vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__,
- which was removed due to licensing issues. You'll copy vhd-util to
- the ``scripts/vm/hypervisor/xenserver/`` directory.
-
-#.
-
- Once you have all the dependencies copied over, you'll be able to
- build CloudStack with the ``nonoss`` option:
-
-::
-
- $ mvn clean
- $ mvn install -Dnonoss
-
-#.
-
- Once you've built CloudStack with the ``nonoss`` profile, you can
- package it using the `Section 3.6, “Building RPMs from
- Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
- packages” <#sect-source-builddebs>`__ instructions.
-
-Installation
-============
-
-4.1. Who Should Read This
--------------------------
-
-For those who have already gone through a design phase and planned a
-more sophisticated deployment, or those who are ready to start scaling
-up a trial installation. With the following procedures, you can start
-using the more powerful features of CloudStack, such as advanced VLAN
-networking, high availability, additional network elements such as load
-balancers and firewalls, and support for multiple hypervisors including
-Citrix XenServer, KVM, and VMware vSphere.
-
-4.2. Overview of Installation Steps
------------------------------------
-
-For anything more than a simple trial installation, you will need
-guidance for a variety of configuration choices. It is strongly
-recommended that you read the following:
-
--
-
- Choosing a Deployment Architecture
-
--
-
- Choosing a Hypervisor: Supported Features
-
--
-
- Network Setup
-
--
-
- Storage Setup
-
--
-
- Best Practices
-
-#.
-
- Make sure you have the required hardware ready. See `Section 4.3,
- “Minimum System Requirements” <#minimum-system-requirements>`__
-
-#.
-
- Install the Management Server (choose single-node or multi-node). See
- `Section 4.5, “Management Server
- Installation” <#management-server-install-flow>`__
-
-#.
-
- Log in to the UI. See `Chapter 5, *User Interface* <#ui>`__
-
-#.
-
- Add a zone. Includes the first pod, cluster, and host. See
- `Section 6.3, “Adding a Zone” <#zone-add>`__
-
-#.
-
- Add more pods (optional). See `Section 6.4, “Adding a
- Pod” <#pod-add>`__
-
-#.
-
- Add more clusters (optional). See `Section 6.5, “Adding a
- Cluster” <#cluster-add>`__
-
-#.
-
- Add more hosts (optional). See `Section 6.6, “Adding a
- Host” <#host-add>`__
-
-#.
-
- Add more primary storage (optional). See `Section 6.7, “Add Primary
- Storage” <#primary-storage-add>`__
-
-#.
-
- Add more secondary storage (optional). See `Section 6.8, “Add
- Secondary Storage” <#secondary-storage-add>`__
-
-#.
-
- Try using the cloud. See `Section 6.9, “Initialize and
- Test” <#initialize-and-test>`__
-
-4.3. Minimum System Requirements
---------------------------------
-
-4.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 localdisk or NFS. The
-Management Server may be placed on a virtual machine.
-
--
-
- Operating system:
-
- -
-
- Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
-
--
-
- 64-bit x86 CPU (more cores results in better performance)
-
--
-
- 4 GB of memory
-
--
-
- 250 GB of local disk (more results in better capability; 500 GB
- recommended)
-
--
-
- At least 1 NIC
-
--
-
- Statically allocated IP address
-
--
-
- Fully qualified domain name as returned by the hostname command
-
-4.3.2. Host/Hypervisor System Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The host is where the cloud services run in the form of guest virtual
-machines. Each host is one machine that meets the following
-requirements:
-
--
-
- Must support HVM (Intel-VT or AMD-V enabled).
-
--
-
- 64-bit x86 CPU (more cores results in better performance)
-
--
-
- Hardware virtualization support required
-
--
-
- 4 GB of memory
-
--
-
- 36 GB of local disk
-
--
-
- At least 1 NIC
-
-.. note::If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack.
-
--
-
- Latest hotfixes applied to hypervisor software
-
--
-
- When you deploy CloudStack, the hypervisor host must not have any VMs
- already running
-
--
-
- All hosts within a cluster must be homogeneous. The CPUs must be of
- the same type, count, and feature flags.
-
-Hosts have additional requirements depending on the hypervisor. See the
-requirements listed at the top of the Installation section for your
-chosen hypervisor:
-
-.. warning::Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
-
-4.4. Configure package repository
----------------------------------
-
-CloudStack is only distributed from source from the official mirrors.
-However, members of the CloudStack community may build convenience
-binaries so that users can install Apache CloudStack without needing to
-build from source.
-
-If you didn't follow the steps to build your own packages from source in
-the sections for `Section 3.6, “Building RPMs from
-Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
-packages” <#sect-source-builddebs>`__ you may find pre-built DEB and RPM
-packages for your convenience linked from the
-`downloads <http://cloudstack.apache.org/downloads.html>`__ page.
-
-.. note::These repositories contain both the Management Server and KVM Hypervisor packages.
-
-4.4.1. DEB package repository
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can add a DEB package repository to your apt sources with the
-following commands. Please note that only packages for Ubuntu 12.04 LTS
-(precise) are being built at this time.
-
-Use your preferred editor and open (or create)
-``/etc/apt/sources.list.d/cloudstack.list``. Add the community provided
-repository to the file:
-
-.. code:: bash
-
- deb http://cloudstack.apt-get.eu/ubuntu precise 4.2
-
-We now have to add the public key to the trusted keys.
-
-.. code:: bash
-
- $ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
-
-Now update your local apt cache.
-
-.. code:: bash
-
- $ apt-get update
-
-Your DEB package repository should now be configured and ready for use.
-
-4.4.2. RPM package repository
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There is a RPM package repository for CloudStack so you can easily
-install on RHEL based platforms.
-
-If you're using an RPM-based system, you'll want to add the Yum
-repository so that you can install CloudStack with Yum.
-
-Yum repository information is found under ``/etc/yum.repos.d``. You'll
-see several ``.repo`` files in this directory, each one denoting a
-specific repository.
-
-To add the CloudStack repository, create
-``/etc/yum.repos.d/cloudstack.repo`` and insert the following
-information.
-
-.. code:: bash
-
- [cloudstack]
- name=cloudstack
- baseurl=http://cloudstack.apt-get.eu/rhel/4.2/
- enabled=1
- gpgcheck=0
-
-Now you should be able to install CloudStack using Yum.
-
-4.5. Management Server Installation
------------------------------------
-
-4.5.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.
-
-In either case, each machine must meet the system requirements described
-in System Requirements.
-
-.. warning::For the sake of security, be sure the public Internet can not access
-port 8096 or port 8250 on the Management Server.
-
-The procedure for installing the Management Server is:
-
-#.
-
- Prepare the Operating System
-
-#.
-
- (XenServer only) Download and install vhd-util.
-
-#.
-
- Install the First Management Server
-
-#.
-
- Install and Configure the MySQL database
-
-#.
-
- Prepare NFS Shares
-
-#.
-
- Prepare and Start Additional Management Servers (optional)
-
-#.
-
- Prepare the System VM Template
-
-4.5.2. Prepare the Operating System
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OS must be prepared to host the Management Server using the
-following steps. These steps must be performed on each Management Server
-node.
-
-#.
-
- Log in to your OS as root.
-
-#.
-
- Check for a fully qualified hostname.
-
- .. code:: bash
-
- hostname --fqdn
-
- This should return a fully qualified hostname such as
- "management1.lab.example.org". If it does not, edit /etc/hosts so
- that it does.
-
-#.
-
- Make sure that the machine can reach the Internet.
-
- .. code:: bash
-
- ping www.cloudstack.org
-
-#.
-
- Turn on NTP for time synchronization.
-
-.. note::NTP is required to synchronize the clocks of the servers in your
- cloud.
-
- #.
-
- Install NTP.
-
- .. code:: bash
-
- yum install ntp
-
- .. code:: bash
-
- apt-get install openntpd
-
-#.
-
- Repeat all of these steps on every host where the Management Server
- will be installed.
-
-4.5.3. Install the Management Server on the First Host
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The first step in installation, whether you are installing the
-Management Server on one host or many, is to install the software on a
-single node.
-
-.. note::If you are planning to install the Management Server on multiple nodes
-for high availability, do not proceed to the additional nodes yet. That
-step will come later.
-
-The CloudStack Management server can be installed using either RPM or
-DEB packages. These packages will depend on everything you need to run
-the Management server.
-
-4.5.3.1. Install on CentOS/RHEL
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-We start by installing the required packages:
-
-.. code:: bash
-
- yum install cloudstack-management
-
-4.5.3.2. Install on Ubuntu
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code:: bash
-
- apt-get install cloudstack-management
-
-4.5.3.3. Downloading vhd-util
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This procedure is required only for installations where XenServer is
-installed on the hypervisor hosts.
-
-Before setting up the Management Server, download vhd-util from
-`vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__.
-
-If the Management Server is RHEL or CentOS, copy vhd-util to
-/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
-
-If the Management Server is Ubuntu, copy vhd-util to
-/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
-
-4.5.4. Install the database server
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The CloudStack management server 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 locally. For an installation that
-has multiple management server nodes, we assume the MySQL database also
-runs on a separate node.
-
-CloudStack has been tested with MySQL 5.1 and 5.5. These versions are
-included in RHEL/CentOS and Ubuntu.
-
-4.5.4.1. Install the Database on the Management Server Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes how to install MySQL on the same machine with the
-Management Server. This technique is intended for a simple deployment
-that has a single Management Server node. If you have a multi-node
-Management Server deployment, you will typically use a separate node for
-MySQL. See `Section 4.5.4.2, “Install the Database on a Separate
-Node” <#management-server-install-db-external>`__.
-
-#.
-
- Install MySQL from the package repository of your distribution:
-
- .. code:: bash
-
- yum install mysql-server
-
- .. code:: bash
-
- apt-get install mysql-server
-
-#.
-
- Open the MySQL configuration file. The configuration file is
- ``/etc/my.cnf`` or ``/etc/mysql/my.cnf``, depending on your OS.
-
-#.
-
- 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 one Management
- Server.
-
-.. note::On Ubuntu, you can also create a file
- `/etc/mysql/conf.d/cloudstack.cnf` and add these directives there.
- Don't forget to add [mysqld] on the first line of the file.
-
- .. code:: bash
-
- innodb_rollback_on_timeout=1
- innodb_lock_wait_timeout=600
- max_connections=350
- log-bin=mysql-bin
- binlog-format = 'ROW'
-
-#.
-
- Start or restart MySQL to put the new configuration into effect.
-
- On RHEL/CentOS, MySQL doesn't automatically start after installation.
- Start it manually.
-
- .. code:: bash
-
- service mysqld start
-
- On Ubuntu, restart MySQL.
-
- .. code:: bash
-
- service mysql restart
-
-#.
-
- (CentOS and RHEL only; not required on Ubuntu)
-
- Warning
-
- On RHEL and CentOS, MySQL does not set a root password by default. It
- is very strongly recommended that you set a root password as a
- security precaution.
-
- Run the following command to secure your installation. You can answer
- "Y" to all questions.
-
- .. code:: bash
-
- mysql_secure_installation
-
-#.
-
- CloudStack can be blocked by security mechanisms, such as SELinux.
- Disable SELinux to ensure + that the Agent has all the required
- permissions.
-
- Configure SELinux (RHEL and CentOS):
-
- #.
-
- Check whether SELinux is installed on your machine. If not, you
- can skip this section.
-
- In RHEL or CentOS, SELinux is installed and enabled by default.
- You can verify this with:
-
- .. code:: bash
-
- $ rpm -qa | grep selinux
-
- #.
-
- Set the SELINUX variable in ``/etc/selinux/config`` to
- "permissive". This ensures that the permissive setting will be
- maintained after a system reboot.
-
- In RHEL or CentOS:
-
- .. code:: bash
-
- vi /etc/selinux/config
-
- Change the following line
-
- .. code:: bash
-
- SELINUX=enforcing
-
- to this:
-
- .. code:: bash
-
- SELINUX=permissive
-
- #.
-
- Set SELinux to permissive starting immediately, without requiring
- a system reboot.
-
- .. code:: bash
-
- $ setenforce permissive
-
-#.
-
- 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 although that is not
- recommended.
-
- -
-
- 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.
-
- -
-
- (Optional) For encryption\_type, use file or web to indicate the
- technique used to pass in the database encryption password.
- Default: file. See `Section 4.5.5, “About Password and Key
- Encryption” <#about-password-encryption>`__.
-
- -
-
- (Optional) For management\_server\_key, substitute the default key
- that is used to encrypt confidential parameters in the CloudStack
- properties file. Default: password. It is highly recommended that
- you replace this with a more secure value. See `Section 4.5.5,
- “About Password and Key
- Encryption” <#about-password-encryption>`__.
-
- -
-
- (Optional) For database\_key, substitute the default key that is
- used to encrypt confidential parameters in the CloudStack
- database. Default: password. It is highly recommended that you
- replace this with a more secure value. See `Section 4.5.5, “About
- Password and Key Encryption” <#about-password-encryption>`__.
-
- -
-
- (Optional) For management\_server\_ip, you may explicitly specify
- cluster management server node IP. If not specified, the local IP
- address will be used.
-
- .. code:: bash
-
- cloudstack-setup-databases cloud:<dbpassword>@localhost \
- --deploy-as=root:<password> \
- -e <encryption_type> \
- -m <management_server_key> \
- -k <database_key> \
- -i <management_server_ip>
-
- When this script is finished, you should see a message like
- “Successfully initialized the database.”
-
- Note
-
-
- If the script is unable to connect to the MySQL database, check the
- "localhost" loopback address in ``/etc/hosts``. It should be pointing
- to the IPv4 loopback address "127.0.0.1" and not the IPv6 loopback
- address ::1. Alternatively, reconfigure MySQL to bind to the IPv6
- loopback interface.
-
-#.
-
- If you are running the KVM hypervisor on the same machine with the
- Management Server, edit /etc/sudoers and add the following line:
-
- .. code:: bash
-
- Defaults:cloud !requiretty
-
-#.
-
- Now that the database is set up, you can finish configuring the OS
- for the Management Server. This command will set up iptables,
- sudoers, and start the Management Server.
-
- .. code:: bash
-
- # cloudstack-setup-management
-
- You should see the message “CloudStack Management Server setup is
- done.”
-
-4.5.4.2. Install the Database on a Separate Node
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes how to install MySQL on a standalone machine,
-separate from the Management Server. This technique is intended for a
-deployment that includes several Management Server nodes. If you have a
-single-node Management Server deployment, you will typically use the
-same node for MySQL. See `Section 4.5.4.1, “Install the Database on the
-Management Server Node” <#management-server-install-db-local>`__.
-
-Note
-
-
-The management server doesn't require a specific distribution for the
-MySQL node. You can use a distribution or Operating System of your
-choice. Using the same distribution as the management server is
-recommended, but not required. See `Section 4.3.1, “Management Server,
-Database, and Storage System
-Requirements” <#management-server-system-requirements>`__.
-
-#.
-
- Install MySQL from the package repository from your distribution:
-
- .. code:: bash
-
- yum install mysql-server
-
- .. code:: bash
-
- apt-get install mysql-server
-
-#.
-
- 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.
-
- Note
-
-
- On Ubuntu, you can also create /etc/mysql/conf.d/cloudstack.cnf file
- and add these directives there. Don't forget to add [mysqld] on the
- first line of the file.
-
- .. code:: bash
-
- innodb_rollback_on_timeout=1
- innodb_lock_wait_timeout=600
- max_connections=700
- log-bin=mysql-bin
- binlog-format = 'ROW'
- bind-address = 0.0.0.0
-
-#.
-
- Start or restart MySQL to put the new configuration into effect.
-
- On RHEL/CentOS, MySQL doesn't automatically start after installation.
- Start it manually.
-
- .. code:: bash
-
- service mysqld start
-
- On Ubuntu, restart MySQL.
-
- .. code:: bash
-
- service mysql restart
-
-#.
-
- (CentOS and RHEL only; not required on Ubuntu)
-
- Warning
-
-
- On RHEL and CentOS, MySQL does not set a root password by default. It
- is very strongly recommended that you set a root password as a
- security precaution.
-
- Run the following command to secure your installation. You can answer
- "Y" to all questions except "Disallow root login remotely?". Remote
- root login is required to set up the databases.
-
- .. code:: bash
-
- mysql_secure_installation
-
-#.
-
- If a firewall is present on the system, open TCP port 3306 so
- external MySQL connections can be established.
-
- On Ubuntu, UFW is the default firewall. Open the port with this
- command:
-
- .. code:: bash
-
- ufw allow mysql
-
- On RHEL/CentOS:
-
- #.
-
- Edit the /etc/sysconfig/iptables file and add the following line
- at the beginning of the INPUT chain.
-
- .. code:: bash
-
- -A INPUT -p tcp --dport 3306 -j ACCEPT
-
- #.
-
- Now reload the iptables rules.
-
- .. code:: bash
-
- service iptables restart
-
-#.
-
- Return to the root shell on your first Management Server.
-
-#.
-
- 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.
-
- -
-
- (Optional) For encryption\_type, use file or web to indicate the
- technique used to pass in the database encryption password.
- Default: file. See `Section 4.5.5, “About Password and Key
- Encryption” <#about-password-encryption>`__.
-
- -
-
- (Optional) For management\_server\_key, substitute the default key
- that is used to encrypt confidential parameters in the CloudStack
- properties file. Default: password. It is highly recommended that
- you replace this with a more secure value. See About Password and
- Key Encryption.
-
- -
-
- (Optional) For database\_key, substitute the default key that is
- used to encrypt confidential parameters in the CloudStack
- database. Default: password. It is highly recommended that you
- replace this with a more secure value. See `Section 4.5.5, “About
- Password and Key Encryption” <#about-password-encryption>`__.
-
- -
-
- (Optional) For management\_server\_ip, you may explicitly specify
- cluster management server node IP. If not specified, the local IP
- address will be used.
-
- .. code:: bash
-
- cloudstack-setup-databases cloud:<dbpassword>@<ip address mysql server> \
- --deploy-as=root:<password> \
- -e <encryption_type> \
- -m <management_server_key> \
- -k <database_key> \
- -i <management_server_ip>
-
- When this script is finished, you should see a message like
- “Successfully initialized the database.”
-
-4.5.5. About Password and Key Encryption
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-CloudStack stores several sensitive passwords and secret keys that are
-used to provide security. These values are always automatically
-encrypted:
-
--
-
- Database secret key
-
--
-
- Database password
-
--
-
- SSH keys
-
--
-
- Compute node root password
-
--
-
- VPN password
-
--
-
- User API secret key
-
--
-
- VNC password
-
-CloudStack 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 CloudStack’s internal properties files along
-with the database password. The other encrypted values listed above,
-such as SSH keys, are in the CloudStack internal database.
-
-Of course, the database secret key itself can
<TRUNCATED>