From ddca80591206a4976d2abc5e53cf6abf3697cbf9 Mon Sep 17 00:00:00 2001 From: Gavin Lee Date: Fri, 9 Nov 2012 13:55:27 +0800 Subject: [PATCH] Docbook xml for additional installation options --- docs/en-US/Installation_Guide.xml | 1 + .../en-US/additional-installation-options.xml | 31 ++++ docs/en-US/cloudstack.xml | 1 + docs/en-US/database-replication.xml | 136 ++++++++++++++++++ docs/en-US/install-usage-server.xml | 61 ++++++++ docs/en-US/ssl.xml | 29 ++++ 6 files changed, 259 insertions(+) create mode 100644 docs/en-US/additional-installation-options.xml create mode 100644 docs/en-US/database-replication.xml create mode 100644 docs/en-US/install-usage-server.xml create mode 100644 docs/en-US/ssl.xml diff --git a/docs/en-US/Installation_Guide.xml b/docs/en-US/Installation_Guide.xml index 90f8748046d..2f60acac984 100644 --- a/docs/en-US/Installation_Guide.xml +++ b/docs/en-US/Installation_Guide.xml @@ -52,6 +52,7 @@ + diff --git a/docs/en-US/additional-installation-options.xml b/docs/en-US/additional-installation-options.xml new file mode 100644 index 00000000000..622ef03d07e --- /dev/null +++ b/docs/en-US/additional-installation-options.xml @@ -0,0 +1,31 @@ + + +%BOOK_ENTITIES; +]> + + + + + Additional Installation Options + The next few sections describe &PRODUCT; features above and beyond the basic deployment options. + + + + diff --git a/docs/en-US/cloudstack.xml b/docs/en-US/cloudstack.xml index c745bc95fe7..0b762a2da1f 100644 --- a/docs/en-US/cloudstack.xml +++ b/docs/en-US/cloudstack.xml @@ -51,6 +51,7 @@ + diff --git a/docs/en-US/database-replication.xml b/docs/en-US/database-replication.xml new file mode 100644 index 00000000000..718c34959da --- /dev/null +++ b/docs/en-US/database-replication.xml @@ -0,0 +1,136 @@ + + +%BOOK_ENTITIES; +]> + + + +
+ Database Replication (Optional) + &PRODUCT; supports database replication from one MySQL node to another. This is achieved using standard MySQL replication. You may want to do this as insurance against MySQL server or storage loss. MySQL replication is implemented using a master/slave model. The master is the node that the Management Servers are configured to use. The slave is a standby node that receives all write operations from the master and applies them to a local, redundant copy of the database. The following steps are a guide to implementing MySQL replication. + Creating a replica is not a backup solution. You should develop a backup procedure for the MySQL data that is distinct from replication. + + Ensure that this is a fresh install with no data in the master. + + Edit my.cnf on the master and add the following in the [mysqld] section below datadir. + +log_bin=mysql-bin +server_id=1 + + The server_id must be unique with respect to other servers. The recommended way to achieve this is to give the master an ID of 1 and each slave a sequential number greater than 1, so that the servers are numbered 1, 2, 3, etc. + + + Restart the MySQL service: + +# service mysqld restart + + + + Create a replication account on the master and give it privileges. We will use the "cloud-repl" user with the password "password". This assumes that master and slave run on the 172.16.1.0/24 network. + +# mysql -u root +mysql> create user 'cloud-repl'@'172.16.1.%' identified by 'password'; +mysql> grant replication slave on *.* TO 'cloud-repl'@'172.16.1.%'; +mysql> flush privileges; +mysql> flush tables with read lock; + + + Leave the current MySQL session running. + In a new shell start a second MySQL session. + + Retrieve the current position of the database. + +# mysql -u root +mysql> show master status; ++------------------+----------+--------------+------------------+ +| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ++------------------+----------+--------------+------------------+ +| mysql-bin.000001 | 412 | | | ++------------------+----------+--------------+------------------+ + + + Note the file and the position that are returned by your instance. + Exit from this session. + + Complete the master setup. Returning to your first session on the master, release the locks and exit MySQL. + +mysql> unlock tables; + + + + Install and configure the slave. On the slave server, run the following commands. + +# yum install mysql-server +# chkconfig mysqld on + + + + Edit my.cnf and add the following lines in the [mysqld] section below datadir. + +server_id=2 +innodb_rollback_on_timeout=1 +innodb_lock_wait_timeout=600 + + + + Restart MySQL. + +# service mysqld restart + + + + Instruct the slave to connect to and replicate from the master. Replace the IP address, password, log file, and position with the values you have used in the previous steps. + +mysql> change master to + -> master_host='172.16.1.217', + -> master_user='cloud-repl', + -> master_password='password', + -> master_log_file='mysql-bin.000001', + -> master_log_pos=412; + + + + Then start replication on the slave. + +mysql> start slave; + + + + Optionally, open port 3306 on the slave as was done on the master earlier. + This is not required for replication to work. But if you choose not to do this, you will need to do it when failover to the replica occurs. + + +
+ Failover + This will provide for a replicated database that can be used to implement manual failover for the Management Servers. &PRODUCT; failover from one MySQL instance to another is performed by the administrator. In the event of a database failure you should: + + Stop the Management Servers (via service cloud-management stop). + Change the replica's configuration to be a master and restart it. + Ensure that the replica's port 3306 is open to the Management Servers. + Make a change so that the Management Server uses the new database. The simplest process here is to put the IP address of the new database server into each Management Server's /etc/cloud/management/db.properties. + + Restart the Management Servers: + +# service cloud-management start + + + +
+
diff --git a/docs/en-US/install-usage-server.xml b/docs/en-US/install-usage-server.xml new file mode 100644 index 00000000000..9dde5523f5e --- /dev/null +++ b/docs/en-US/install-usage-server.xml @@ -0,0 +1,61 @@ + + +%BOOK_ENTITIES; +]> + + + +
+ Installing the Usage Server (Optional) + You can optionally install the Usage Server once the Management Server is configured properly. The Usage Server takes data from the events in the system and enables usage-based billing for accounts. + When multiple Management Servers are present, the Usage Server may be installed on any number of them. The Usage Servers will coordinate usage processing. A site that is concerned about availability should install Usage Servers on at least two Management Servers. +
+ Requirements for Installing the Usage Server + + The Management Server must be running when the Usage Server is installed. + The Usage Server must be installed on the same server as a Management Server. + +
+
+ Steps to Install the Usage Server + + + Run ./install.sh. + +# ./install.sh + + You should see a few messages as the installer prepares, followed by a list of choices. + + + Choose "S" to install the Usage Server. + + > S + + + + Once installed, start the Usage Server with the following command. + +# service cloud-usage start + + + + The Administration Guide discusses further configuration of the Usage Server. +
+
diff --git a/docs/en-US/ssl.xml b/docs/en-US/ssl.xml new file mode 100644 index 00000000000..9aeb2f91aa8 --- /dev/null +++ b/docs/en-US/ssl.xml @@ -0,0 +1,29 @@ + + +%BOOK_ENTITIES; +]> + + + +
+ SSL (Optional) + &PRODUCT; provides HTTP access in its default installation. There are a number of technologies and sites which choose to implement SSL. As a result, we have left &PRODUCT; to expose HTTP under the assumption that a site will implement its typical practice. + &PRODUCT; uses Tomcat as its servlet container. For sites that would like &PRODUCT; to terminate the SSL session, Tomcat’s SSL access may be enabled. Tomcat SSL configuration is described at http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html. +