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/05/28 08:45:12 UTC
[8/8] git commit: cleaned up formatting in all the files and removed
the deprecated 'managing_networks.rst' file: This closes #13
cleaned up formatting in all the files and removed the deprecated 'managing_networks.rst' file: This closes #13
Signed-off-by: Sebastien Goasguen <ru...@gmail.com>
Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/commit/f58c8b9f
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/tree/f58c8b9f
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/diff/f58c8b9f
Branch: refs/heads/master
Commit: f58c8b9f69229e14ea22163261b6a49a5368bab1
Parents: 629ff54
Author: Will Stevens <ws...@cloudops.com>
Authored: Tue May 27 16:41:54 2014 -0400
Committer: Sebastien Goasguen <ru...@gmail.com>
Committed: Wed May 28 08:44:40 2014 +0200
----------------------------------------------------------------------
source/building_from_source.rst | 209 +-
source/choosing_deployment_architecture.rst | 132 +-
source/conf.py | 9 +
source/configuration.rst | 1471 ++---
source/hypervisor/hyperv.rst | 117 +-
source/hypervisor/kvm.rst | 615 +-
source/hypervisor/lxc.rst | 470 +-
source/hypervisor/vsphere.rst | 541 +-
source/hypervisor/xenserver.rst | 485 +-
source/index.rst | 83 +-
source/installation.rst | 880 ++-
source/managing_networks.rst | 6914 ----------------------
source/network_setup.rst | 839 +--
source/optional_installation.rst | 514 +-
source/qig.rst | 660 ++-
source/storage_setup.rst | 162 +-
16 files changed, 2862 insertions(+), 11239 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/f58c8b9f/source/building_from_source.rst
----------------------------------------------------------------------
diff --git a/source/building_from_source.rst b/source/building_from_source.rst
index 7ce77d7..a4cb300 100644
--- a/source/building_from_source.rst
+++ b/source/building_from_source.rst
@@ -13,6 +13,7 @@
specific language governing permissions and limitations
under the License.
+
Building from Source
====================
@@ -34,11 +35,13 @@ for building from source for the 4.0.x series is different from the
If you are working with a unreleased version of CloudStack, see the
INSTALL.md file in the top-level directory of the release.
+
Getting the release
-------------------
You can download the latest CloudStack release from the `Apache
-CloudStack project download page <http://cloudstack.apache.org/downloads.html>`_.
+CloudStack project download page
+<http://cloudstack.apache.org/downloads.html>`_.
Prior releases are available via archive.apache.org as well. See the
downloads page for more information on archived releases.
@@ -47,32 +50,26 @@ 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.
--
-
- The ``tar.bz2`` file contains the Bzip2-compressed tarball with the
+- The ``tar.bz2`` file contains the Bzip2-compressed tarball with the
source code.
--
-
- The ``.asc`` file is a detached cryptographic signature that can be
+- The ``.asc`` file is a detached cryptographic signature that can be
used to help verify the authenticity of the release.
--
-
- The ``.md5`` file is an MD5 hash of the release to aid in verify the
+- The ``.md5`` file is an MD5 hash of the release to aid in verify the
validity of the release download.
--
-
- The ``.sha`` file is a SHA512 hash of the release to aid in verify
+- The ``.sha`` file is a SHA512 hash of the release to aid in verify
the validity of the release download.
+
Verifying the downloaded release
--------------------------------
There are a number of mechanisms to check the authenticity and validity
of a downloaded release.
+
Getting the KEYS
~~~~~~~~~~~~~~~~
@@ -83,7 +80,8 @@ You next need to import those keys, which you can do by running:
.. sourcecode:: bash
- # gpg --import KEYS
+ # gpg --import KEYS
+
GPG
~~~
@@ -93,11 +91,12 @@ To check the signature, run the following command:
.. sourcecode:: bash
- $ gpg --verify apache-cloudstack-4.3.0-src.tar.bz2.asc
+ $ gpg --verify apache-cloudstack-4.3.0-src.tar.bz2.asc
If the signature is valid you will see a line of output that contains
'Good signature'.
+
MD5
~~~
@@ -107,12 +106,13 @@ You can verify this hash by executing the following command:
.. sourcecode:: bash
- $ gpg --print-md MD5 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-src.tar.bz2.md5
+ $ gpg --print-md MD5 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-src.tar.bz2.md5
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.
+
SHA512
~~~~~~
@@ -122,13 +122,14 @@ release. You can verify this hash by executing the following command:
.. sourcecode:: bash
- $ gpg --print-md SHA512 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-src.tar.bz2.sha
+ $ gpg --print-md SHA512 apache-cloudstack-4.3.0-src.tar.bz2 | diff - apache-cloudstack-4.3.0-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.
+
Prerequisites for building Apache CloudStack
--------------------------------------------
@@ -138,37 +139,22 @@ for package management.
You will need, at a minimum, the following to compile CloudStack:
-#.
-
- Maven (version 3)
-
-#.
-
- Java (OpenJDK 1.6 or Java 7/OpenJDK 1.7)
-
-#.
-
- Apache Web Services Common Utilities (ws-commons-util)
+#. Maven (version 3)
-#.
+#. Java (OpenJDK 1.6 or Java 7/OpenJDK 1.7)
- MySQL
+#. Apache Web Services Common Utilities (ws-commons-util)
-#.
+#. MySQL
- MySQLdb (provides Python database API)
+#. MySQLdb (provides Python database API)
-#.
+#. Tomcat 6 (not 6.0.35)
- Tomcat 6 (not 6.0.35)
+#. genisoimage
-#.
+#. rpmbuild or dpkg-dev
- genisoimage
-
-#.
-
- rpmbuild or dpkg-dev
Extracting source
-----------------
@@ -178,13 +164,14 @@ with a single command as follows:
.. sourcecode:: bash
- $ tar -jxvf apache-cloudstack-4.3.0-src.tar.bz2
+ $ tar -jxvf apache-cloudstack-4.3.0-src.tar.bz2
You can now move into the directory:
.. sourcecode:: bash
- $ cd ./apache-cloudstack-4.3.0-src
+ $ cd ./apache-cloudstack-4.3.0-src
+
Building DEB packages
---------------------
@@ -198,11 +185,11 @@ will be added.
.. sourcecode:: bash
- $ 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
+ $ 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
While we have defined, and you have presumably already installed the
bootstrap prerequisites, there are a number of build time prerequisites
@@ -212,7 +199,7 @@ running:
.. sourcecode:: bash
- $ mvn3 -P deps
+ $ mvn3 -P deps
Now that we have resolved the dependencies we can move on to building
CloudStack and packaging them into DEBs by issuing the following
@@ -220,20 +207,21 @@ command.
.. sourcecode:: bash
- $ dpkg-buildpackage -uc -us
+ $ dpkg-buildpackage -uc -us
This command will build the following debian packages. You should have
all of the following:
.. sourcecode:: bash
- cloudstack-common-4.3.0.amd64.deb
- cloudstack-management-4.3.0.amd64.deb
- cloudstack-agent-4.3.0.amd64.deb
- cloudstack-usage-4.3.0.amd64.deb
- cloudstack-awsapi-4.3.0.amd64.deb
- cloudstack-cli-4.3.0.amd64.deb
- cloudstack-docs-4.3.0.amd64.deb
+ cloudstack-common-4.3.0.amd64.deb
+ cloudstack-management-4.3.0.amd64.deb
+ cloudstack-agent-4.3.0.amd64.deb
+ cloudstack-usage-4.3.0.amd64.deb
+ cloudstack-awsapi-4.3.0.amd64.deb
+ cloudstack-cli-4.3.0.amd64.deb
+ cloudstack-docs-4.3.0.amd64.deb
+
Setting up an APT repo
~~~~~~~~~~~~~~~~~~~~~~
@@ -253,7 +241,7 @@ as well.
.. sourcecode:: bash
- $ sudo apt-get install dpkg-dev
+ $ sudo apt-get install dpkg-dev
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
@@ -261,19 +249,19 @@ examples, but change the directory to whatever works for you.
.. sourcecode:: bash
- 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
+ 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
.. note::
-
You can safely ignore the warning about a missing override file.
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.)
+
Configuring your machines to use the APT repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -285,33 +273,34 @@ line:
.. sourcecode:: bash
- deb http://server.url/cloudstack/repo binary ./
+ 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.
.. sourcecode:: bash
- $ sudo apt-get update
+ $ sudo apt-get update
You can now move on to the instructions under Install on Ubuntu.
+
Building RPMs from Source
-------------------------
-As mentioned previously in `“Prerequisites for building
-Apache CloudStack” <#prerequisites-for-building-apache-cloudstack>`_, 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.
+As mentioned previously in `“Prerequisites for building Apache CloudStack”
+<#prerequisites-for-building-apache-cloudstack>`_, 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.
.. sourcecode:: bash
- # yum groupinstall "Development Tools"
+ # yum groupinstall "Development Tools"
.. sourcecode:: bash
- # yum install java-1.6.0-openjdk-devel.x86_64 genisoimage mysql mysql-server ws-commons-util MySQL-python tomcat6 createrepo
+ # yum install java-1.6.0-openjdk-devel.x86_64 genisoimage mysql mysql-server ws-commons-util MySQL-python tomcat6 createrepo
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
@@ -320,24 +309,24 @@ your home directory (or whatever location you prefer):
.. sourcecode:: bash
- $ tar zxvf apache-maven-3.0.4-bin.tar.gz
+ $ tar zxvf apache-maven-3.0.4-bin.tar.gz
.. sourcecode:: bash
- $ export PATH=/usr/local/apache-maven-3.0.4/bin:$PATH
+ $ 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:
.. sourcecode:: bash
- $ export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
+ $ export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
Verify that Maven is installed correctly:
.. sourcecode:: bash
- $ mvn --version
+ $ 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
@@ -349,23 +338,27 @@ 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.
- 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.
Generating RPMS
~~~~~~~~~~~~~~~
-Now that we have the prerequisites and source, you will cd to the `packaging/centos63/` directory.
+Now that we have the prerequisites and source, you will cd to the
+`packaging/centos63/` directory.
.. sourcecode:: bash
- $ cd packaging/centos63
+ $ cd packaging/centos63
Generating RPMs is done using the ``package.sh`` script:
.. sourcecode:: bash
- $./package.sh
+ $ ./package.sh
That will run for a bit and then place the finished packages in
``dist/rpmbuild/RPMS/x86_64/``.
@@ -374,13 +367,14 @@ You should see the following RPMs in that directory:
.. sourcecode:: bash
- cloudstack-agent-4.3.0.el6.x86_64.rpm
- cloudstack-awsapi-4.3.0.el6.x86_64.rpm
- cloudstack-cli-4.3.0.el6.x86_64.rpm
- cloudstack-common-4.3.0.el6.x86_64.rpm
- cloudstack-docs-4.3.0.el6.x86_64.rpm
- cloudstack-management-4.3.0.el6.x86_64.rpm
- cloudstack-usage-4.3.0.el6.x86_64.rpm
+ cloudstack-agent-4.3.0.el6.x86_64.rpm
+ cloudstack-awsapi-4.3.0.el6.x86_64.rpm
+ cloudstack-cli-4.3.0.el6.x86_64.rpm
+ cloudstack-common-4.3.0.el6.x86_64.rpm
+ cloudstack-docs-4.3.0.el6.x86_64.rpm
+ cloudstack-management-4.3.0.el6.x86_64.rpm
+ cloudstack-usage-4.3.0.el6.x86_64.rpm
+
Creating a yum repo
^^^^^^^^^^^^^^^^^^^
@@ -391,19 +385,20 @@ with the finished packages:
.. sourcecode:: bash
- $ mkdir -p ~/tmp/repo
+ $ mkdir -p ~/tmp/repo
.. sourcecode:: bash
- $ cp dist/rpmbuild/RPMS/x86_64/*rpm ~/tmp/repo/
+ $ cp dist/rpmbuild/RPMS/x86_64/*rpm ~/tmp/repo/
.. sourcecode:: bash
- $ createrepo ~/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.
+
Configuring your systems to use your new yum repository
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -422,6 +417,7 @@ named ``/etc/yum.repos.d/cloudstack.repo`` with this information:
Completing this step will allow you to easily install CloudStack on a
number of machines across the network.
+
Building Non-OSS
----------------
@@ -431,38 +427,35 @@ a few components on your own and follow a slightly different procedure
to build from source.
.. warning::
-
- 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
+ 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 CloudStack* <https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack>`_
+ most recent dependencies are listed on the `*How to build CloudStack*
+ <https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack>`_
page on the wiki.
-#.
-
- You may also need to download
+#. 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
+#. Once you have all the dependencies copied over, you'll be able to
build CloudStack with the ``noredist`` option:
.. sourcecode:: bash
- $ mvn clean
- $ mvn install -Dnoredist
-
-#.
+ $ mvn clean
+ $ mvn install -Dnoredist
- Once you've built CloudStack with the ``noredist`` profile, you can
+#. Once you've built CloudStack with the ``noredist`` profile, you can
package it using the `“Building RPMs from Source” <#building-rpms-from-source>`_
- or `“Building DEB packages” <#building-deb-packages>`_ instructions.
\ No newline at end of file
+ or `“Building DEB packages” <#building-deb-packages>`_ instructions.
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/f58c8b9f/source/choosing_deployment_architecture.rst
----------------------------------------------------------------------
diff --git a/source/choosing_deployment_architecture.rst b/source/choosing_deployment_architecture.rst
index 11c4c03..8e92a12 100644
--- a/source/choosing_deployment_architecture.rst
+++ b/source/choosing_deployment_architecture.rst
@@ -13,6 +13,7 @@
specific language governing permissions and limitations
under the License.
+
Choosing a Deployment Architecture
==================================
@@ -22,6 +23,7 @@ deployment architecture, including a small-scale deployment useful for
test and trial deployments and a fully-redundant large-scale setup for
production deployments.
+
Small-Scale Deployment
----------------------
@@ -30,25 +32,18 @@ Small-Scale Deployment
This diagram illustrates the network architecture of a small-scale
CloudStack deployment.
--
-
- A firewall provides a connection to the Internet. The firewall is
+- A firewall provides a connection to the Internet. The firewall is
configured in NAT mode. The firewall forwards HTTP requests and API
calls from the Internet to the Management Server. The Management
Server resides on the management network.
--
-
- A layer-2 switch connects all physical servers and storage.
-
--
+- A layer-2 switch connects all physical servers and storage.
- A single NFS server functions as both the primary and secondary
+- A single NFS server functions as both the primary and secondary
storage.
--
+- The Management Server is connected to the management network.
- The Management Server is connected to the management network.
Large-Scale Redundant Setup
---------------------------
@@ -58,49 +53,36 @@ Large-Scale Redundant Setup
This diagram illustrates the network architecture of a large-scale
CloudStack deployment.
--
-
- A layer-3 switching layer is at the core of the data center. A router
+- A layer-3 switching layer is at the core of the data center. A router
redundancy protocol like VRRP should be deployed. Typically high-end
core switches also include firewall modules. Separate firewall
appliances may also be used if the layer-3 switch does not have
integrated firewall capabilities. The firewalls are configured in NAT
mode. The firewalls provide the following functions:
- -
-
- Forwards HTTP requests and API calls from the Internet to the
+ - Forwards HTTP requests and API calls from the Internet to the
Management Server. The Management Server resides on the management
network.
- -
-
- When the cloud spans multiple zones, the firewalls should enable
+ - When the cloud spans multiple zones, the firewalls should enable
site-to-site VPN such that servers in different zones can directly
reach each other.
--
-
- A layer-2 access switch layer is established for each pod. Multiple
+- A layer-2 access switch layer is established for each pod. Multiple
switches can be stacked to increase port count. In either case,
redundant pairs of layer-2 switches should be deployed.
--
-
- The Management Server cluster (including front-end load balancers,
+- The Management Server cluster (including front-end load balancers,
Management Server nodes, and the MySQL database) is connected to the
management network through a pair of load balancers.
--
+- Secondary storage servers are connected to the management network.
- Secondary storage servers are connected to the management network.
-
--
-
- Each pod contains storage and computing servers. Each storage and
+- Each pod contains storage and computing servers. Each storage and
computing server should have redundant NICs connected to separate
layer-2 access switches.
+
Separate Storage Network
------------------------
@@ -110,6 +92,7 @@ network is optional for deployments. Storage protocols such as iSCSI are
sensitive to network delays. A separate storage network ensures guest
network traffic contention does not impact storage performance.
+
Multi-Node Management Server
----------------------------
@@ -123,19 +106,14 @@ remote site to add DR capabilities.
The administrator must decide the following.
--
-
- Whether or not load balancers will be used.
+- Whether or not load balancers will be used.
--
+- How many Management Servers will be deployed.
- How many Management Servers will be deployed.
-
--
-
- Whether MySQL replication will be deployed to enable disaster
+- Whether MySQL replication will be deployed to enable disaster
recovery.
+
Multi-Site Deployment
---------------------
@@ -157,15 +135,11 @@ two connected to storage network switches.
There are two ways to configure the storage network:
--
-
- Bonded NIC and redundant switches can be deployed for NFS. In NFS
+- Bonded NIC and redundant switches can be deployed for NFS. In NFS
deployments, redundant switches and bonded NICs still result in one
network (one CIDR block+ default gateway address).
--
-
- iSCSI can take advantage of two separate storage networks (two CIDR
+- iSCSI can take advantage of two separate storage networks (two CIDR
blocks each with its own default gateway). Multipath iSCSI client can
failover and load balance between separate storage networks.
@@ -221,18 +195,15 @@ 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.
+
Process Best Practices
~~~~~~~~~~~~~~~~~~~~~~
--
-
- A staging system that models the production environment is strongly
+- A staging system that models the production environment is strongly
advised. It is critical if customizations have been applied to
CloudStack.
--
-
- Allow adequate time for installation, a beta, and learning the
+- 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
@@ -240,69 +211,52 @@ Process Best Practices
through all of the integration issues. You can get help from fellow
users on the cloudstack-users mailing list.
+
Setup Best Practices
~~~~~~~~~~~~~~~~~~~~
--
-
- Each host should be configured to accept connections only from
+- Each host should be configured to accept connections only from
well-known entities such as the CloudStack Management Server or your
network monitoring software.
--
-
- Use multiple clusters per pod if you need to achieve a certain switch
+- Use multiple clusters per pod if you need to achieve a certain switch
density.
--
-
- Primary storage mountpoints or LUNs should not exceed 6 TB in size.
+- 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.
--
-
- When exporting shares on primary storage, avoid data loss by
+- 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".
--
-
- NIC bonding is straightforward to implement and provides increased
+- NIC bonding is straightforward to implement and provides increased
reliability.
--
-
- 10G networks are generally recommended for storage access when larger
+- 10G networks are generally recommended for storage access when larger
servers that can support relatively more VMs are used.
--
-
- Host capacity should generally be modeled in terms of RAM for the
+- 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.
--
-
- (XenServer) Configure the XenServer dom0 settings to allocate more
+- (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
- `http://support.citrix.com/article/CTX126531 <http://support.citrix.com/article/CTX126531>`_.
+ `http://support.citrix.com/article/CTX126531
+ <http://support.citrix.com/article/CTX126531>`_.
The article refers to XenServer 5.6, but the same information applies
to XenServer 6.0.
+
Maintenance Best Practices
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
-
- Monitor host disk space. Many host failures occur because the host's
+- Monitor host disk space. Many host failures occur because the host's
root disk fills up from logs that were not rotated adequately.
--
-
- Monitor the total number of VM instances in each cluster, and disable
+- 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
@@ -319,10 +273,15 @@ Maintenance Best Practices
CloudStack UI to disable allocation to the cluster.
.. warning::
-
The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
-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. CloudStack 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.
+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.
+CloudStack 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.
.. |Small-Scale Deployment| image:: ./_static/images/small-scale-deployment.png
@@ -331,4 +290,3 @@ Be sure all the hotfixes provided by the hypervisor vendor are applied. Track th
.. |Example Of A Multi-Site Deployment| image:: ./_static/images/multi-site-deployment.png
.. |Separate Storage Network| image:: ./_static/images/separate-storage-network.png
.. |NIC Bonding And Multipath I/O| image:: ./_static/images/nic-bonding-and-multipath-io.png
-
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/f58c8b9f/source/conf.py
----------------------------------------------------------------------
diff --git a/source/conf.py b/source/conf.py
index 05f1cad..add1c67 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -17,6 +17,8 @@
import sys
import os
+on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
+
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
@@ -105,6 +107,13 @@ pygments_style = 'sphinx'
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'default'
+if not on_rtd:
+ try:
+ import sphinx_rtd_theme
+ html_theme = 'sphinx_rtd_theme'
+ html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+ except ImportError:
+ pass
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the