en-US/best-practices.xml

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "cloudstack.ent">
%BOOK_ENTITIES;
]>

<!-- Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
   http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-->

<chapter id="best-practices">
    <title>Best Practices</title>
    <para>Deploying a cloud is challenging.  There are many different technology choices to make, and &PRODUCT; is flexible enough in its configuration that there are many possible ways to combine and configure the chosen technology.  This section contains suggestions and requirements about cloud deployments.</para>
    <para>These should be treated as suggestions and not absolutes.  However, we do encourage anyone planning to build a cloud outside of these guidelines to seek guidance and advice on the project mailing lists.</para>
    <section id="process-best-practices">
    <title>Process Best Practices</title>
    <itemizedlist>
        <listitem>
        <para>A staging system that models the production environment is strongly advised.  It is critical if customizations have been applied to &PRODUCT;.</para>
        </listitem>
        <listitem>
        <para>Allow adequate time for installation, a beta, and learning the system.  Installs with basic networking can be done in hours.  Installs with advanced networking usually take several days for the first attempt, with complicated installations taking longer.  For a full production system, allow at least 4-8 weeks for a beta to work through all of the integration issues. You can get help from fellow users on the cloudstack-users mailing list.</para>
        </listitem>
    </itemizedlist>
    </section>
    <section id="setup-best-practices">
    <title>Setup Best Practices</title>
    <itemizedlist>
        <listitem>
        <para>Each host should be configured to accept connections only from well-known entities such as the &PRODUCT; Management Server or your network monitoring software.</para>
        </listitem>
        <listitem>
        <para>Use multiple clusters per pod if you need to achieve a certain switch density.</para>
        </listitem>
        <listitem>
        <para>Primary storage mountpoints or LUNs should not exceed 6 TB in size.  It is better to have multiple smaller primary storage elements per cluster than one large one.</para>
        </listitem>
        <listitem>
        <para>When exporting shares on primary storage, avoid data loss by restricting the range of IP addresses that can access the storage. See "Linux NFS on Local Disks and DAS" or "Linux NFS on iSCSI".</para>
        </listitem>
        <listitem>
        <para>NIC bonding is straightforward to implement and provides increased reliability.</para>
        </listitem>
        <listitem>
        <para>10G networks are generally recommended for storage access when larger servers that can support relatively more VMs are used.</para>
        </listitem>
        <listitem>
        <para>Host capacity should generally be modeled in terms of RAM for the guests.  Storage and CPU may be overprovisioned.  RAM may not.  RAM is usually the limiting factor in capacity designs.</para>
        </listitem>
        <listitem>
	    <para>(XenServer) Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0.  For instructions on how to do this, see <ulink url="http://support.citrix.com/article/CTX126531">http://support.citrix.com/article/CTX126531</ulink>. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0.</para>
        </listitem>
    </itemizedlist>
    </section>
    <section id="maintenance-best-practices">
    <title>Maintenance Best Practices</title>
    <itemizedlist>
        <listitem>
        <para>Monitor host disk space.  Many host failures occur because the host's root disk fills up from logs that were not rotated adequately.</para>
        </listitem>
        <listitem>
        <para>Monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use &PRODUCT; global configuration settings to set this as the default limit. Monitor the VM activity in each cluster and keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the &PRODUCT; UI to disable allocation to the cluster.</para>
        </listitem>
    </itemizedlist>
    <warning><para>The lack of up-do-date hotfixes can lead to data corruption and lost VMs.</para></warning>
    <para>Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of hypervisor patches through your hypervisor vendor’s support channel, and apply patches as soon as possible after they are released. &PRODUCT; will not track or notify you of required hypervisor patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches.</para>
    </section>
</chapter>