openstack/openstack-manuals
Code Issues Proposed changes

Merge "Corrects typos and provide clarification"

Browse Source
This commit is contained in:
Jenkins 2014-08-19 03:28:13 +00:00 committed by Gerrit Code Review
commit e8ea4fdf01
15 changed files with 30 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/high-availability-guide/api/section_api_pacemaker.xml
View File

@ -6,7 +6,7 @@
<title>Configure Pacemaker group</title>
<para>Finally, we need to create a service <literal>group</literal> to ensure that virtual IP is linked to the API services resources:</para>
<para>Finally, we need to create a service <literal>group</literal> to ensure that the virtual IP is linked to the API services resources:</para>
<screen>group g_services_api p_api-ip p_keystone p_glance-api p_cinder-api \
p_neutron-server p_glance-registry p_ceilometer-agent-central</screen>
</section>

8
doc/high-availability-guide/api/section_glance_api.xml
View File

@ -26,7 +26,7 @@ Configure OpenStack services to use this IP address.
</listitem>
</itemizedlist>
<note>
<para>Here is the <link xlink:href="http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_glance.html">documentation</link> for installing OpenStack Image API service.</para>
<para>Here is the <link xlink:href="http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_glance.html">documentation</link> for installing the OpenStack Image API service.</para>
</note>
<section xml:id="_add_openstack_image_api_resource_to_pacemaker">
@ -45,12 +45,12 @@ configure</literal>, and add the following cluster resources:</para>
<para>This configuration creates</para>
<itemizedlist>
<listitem>
<para><literal>p_glance-api</literal>, a resource for manage OpenStack Image API service
<para><literal>p_glance-api</literal>, a resource for managing OpenStack Image API service
</para>
</listitem>
</itemizedlist>
<para><literal>crm configure</literal> supports batch input, so you may copy and paste the
above into your live pacemaker configuration, and then make changes as
above into your live Pacemaker configuration, and then make changes as
required. For example, you may enter <literal>edit p_ip_glance-api</literal> from the
<literal>crm configure</literal> menu and edit the resource to match your preferred
virtual IP address.</para>
@ -84,7 +84,7 @@ rabbit_host = 192.168.42.102</programlisting>
the highly available, virtual cluster IP address — rather than an
OpenStack Image API server’s physical IP address as you normally would.</para>
<para>For OpenStack Compute, for example, if your OpenStack Image API service IP address is
192.168.42.104 as in the configuration explained here, you would use
192.168.42.103 as in the configuration explained here, you would use
the following line in your <filename>nova.conf</filename> file:</para>
<programlisting language="ini">glance_api_servers = 192.168.42.103</programlisting>
<para>You must also create the OpenStack Image API endpoint with this IP.</para>

10
doc/high-availability-guide/api/section_neutron_server.xml
View File

@ -7,21 +7,21 @@
<title>Highly available OpenStack Networking server</title>
<para>OpenStack Networking is the network connectivity service in OpenStack.
Making the OpenStack Networking Server service highly available in active / passive mode involves</para>
Making the OpenStack Networking Server service highly available in active / passive mode involves the following tasks:</para>
<itemizedlist>
<listitem>
<para>
Configure OpenStack Networking to listen on the VIP address,
Configure OpenStack Networking to listen on the virtual IP address,
</para>
</listitem>
<listitem>
<para>
managing OpenStack Networking API Server daemon with the Pacemaker cluster manager,
Manage the OpenStack Networking API Server daemon with the Pacemaker cluster manager,
</para>
</listitem>
<listitem>
<para>
Configure OpenStack services to use this IP address.
Configure OpenStack services to use the virtual IP address.
</para>
</listitem>
</itemizedlist>
@ -40,7 +40,7 @@ Configure OpenStack services to use this IP address.
OpenStack Networking Server resource. Connect to the Pacemaker cluster with <literal>crm
configure</literal>, and add the following cluster resources:</para>
<programlisting>primitive p_neutron-server ocf:openstack:neutron-server \
params os_password="secrete" os_username="admin" os_tenant_name="admin" \
params os_password="secret" os_username="admin" os_tenant_name="admin" \
keystone_get_token_url="http://192.168.42.103:5000/v2.0/tokens" \
op monitor interval="30s" timeout="30s"</programlisting>
<para>This configuration creates <literal>p_neutron-server</literal>, a resource for manage OpenStack Networking Server service</para>

2
doc/high-availability-guide/ch_intro.xml
View File

@ -59,7 +59,7 @@ Facility services such as power, air conditioning, and fire protection
<title>Active/Passive</title>
<para>In an active/passive configuration, systems are set up to bring additional resources online to replace those that have failed. For example, OpenStack would write to the main database while maintaining a disaster recovery database that can be brought online in the event that the main database fails.</para>
<para>Typically, an active/passive installation for a stateless service would maintain a redundant instance that can be brought online when required. Requests are load balanced using a virtual IP address and a load balancer such as HAProxy.</para>
<para>Typically, an active/passive installation for a stateless service would maintain a redundant instance that can be brought online when required. Requests may be handled using a virtual IP address to facilitate return to service with minimal reconfiguration required.</para>
<para>A typical active/passive installation for a stateful service maintains a replacement resource that can be brought online when required. A separate application (such as Pacemaker or Corosync) monitors these services, bringing the backup online as necessary.</para>
</section>
<section xml:id="aa-intro">

2
doc/high-availability-guide/ch_network.xml
View File

@ -7,7 +7,7 @@
<title>Network controller cluster stack</title>
<para>The network controller sits on the management and data network, and needs to be connected to the Internet if a VM needs access to it.</para>
<para>The network controller sits on the management and data network, and needs to be connected to the Internet if an instance will need access to the Internet.</para>
<note>
<para>Both nodes should have the same hostname since the Networking scheduler will be
aware of one node, for example a virtual router attached to a single L3 node.</para>

10
doc/high-availability-guide/controller/section_mysql.xml
View File

@ -27,7 +27,7 @@ Configure MySQL to use a data directory residing on that DRBD
</listitem>
<listitem>
<para>
selecting and assigning a virtual IP address (VIP) that can freely
Select and assign a virtual IP address (VIP) that can freely
float between cluster nodes,
</para>
</listitem>
@ -38,14 +38,14 @@ Configure MySQL to listen on that IP address,
</listitem>
<listitem>
<para>
managing all resources, including the MySQL daemon itself, with
Manage all resources, including the MySQL daemon itself, with
the Pacemaker cluster manager.
</para>
</listitem>
</itemizedlist>
<note>
<para><link xlink:href="http://galeracluster.com/">MySQL/Galera</link> is an
alternative method of Configure MySQL for high availability. It is
alternative method of configuring MySQL for high availability. It is
likely to become the preferred method of achieving MySQL high
availability once it has sufficiently matured. At the time of writing,
however, the Pacemaker/DRBD based approach remains the recommended one
@ -125,7 +125,7 @@ creating your filesystem.
<para>Once the DRBD resource is running and in the primary role (and
potentially still in the process of running the initial device
synchronization), you may proceed with creating the filesystem for
MySQL data. XFS is the generally recommended filesystem:</para>
MySQL data. XFS is the generally recommended filesystem due to its journaling, efficient allocation, and performance:</para>
<screen><prompt>#</prompt> <userinput>mkfs -t xfs /dev/drbd0</userinput></screen>
<para>You may also use the alternate device path for the DRBD device, which
may be easier to remember as it includes the self-explanatory resource
@ -187,7 +187,7 @@ primitive p_fs_mysql ocf:heartbeat:Filesystem \
op stop timeout="180s" \
op monitor interval="60s" timeout="60s"
primitive p_mysql ocf:heartbeat:mysql \
params additional_parameters="--bind-address=50.56.179.138"
params additional_parameters="--bind-address=192.168.42.101"
config="/etc/mysql/my.cnf" \
pid="/var/run/mysqld/mysqld.pid" \
socket="/var/run/mysqld/mysqld.sock" \

2
doc/high-availability-guide/ha_aa_controllers/section_memcached.xml
View File

@ -7,7 +7,7 @@
<title>Memcached</title>
<para>Most of OpenStack services use an application to offer persistence and store ephemeral data (like tokens).
Memcached is one of them and can scale-out easily without specific trick.</para>
Memcached is one of them and can scale-out easily without any specific tricks required.</para>
<para>To install and configure it, read the <link xlink:href="http://code.google.com/p/memcached/wiki/NewStart">official documentation</link>.</para>
<para>Memory caching is managed by oslo-incubator so the way to use multiple memcached servers is the same for all projects.</para>
<para>Example with two hosts:</para>

4
doc/high-availability-guide/ha_aa_controllers/section_run_openstack_api_and_schedulers.xml
View File

@ -20,12 +20,12 @@ and use load balancing and virtual IP (with HAProxy &amp; Keepalived in this set
<itemizedlist>
<listitem>
<para>
You use Virtual IP when configuring OpenStack Identity endpoints.
You use virtual IPs when configuring OpenStack Identity endpoints.
</para>
</listitem>
<listitem>
<para>
All OpenStack configuration files should refer to Virtual IP.
All OpenStack configuration files should refer to virtual IPs.
</para>
</listitem>
</itemizedlist>

2
doc/high-availability-guide/ha_aa_db/section_ha_aa_db_mysql_galera.xml
View File

@ -100,7 +100,7 @@ that cluster:</para>
<listitem>
<para>
Start on <literal>10.0.0.10</literal> by executing the command:
Start on the first node having IP address <literal>10.0.0.10</literal> by executing the command:
</para>
</listitem>
</orderedlist>

2
doc/high-availability-guide/ha_aa_rabbitmq/section_configure_openstack_services_to_user_rabbitmq.xml
View File

@ -18,7 +18,7 @@
<programlisting>rabbit_max_retries=0</programlisting>
<para>Use durable queues in RabbitMQ:</para>
<programlisting>rabbit_durable_queues=false</programlisting>
<para>Use H/A queues in RabbitMQ (x-ha-policy: all):</para>
<para>Use HA queues in RabbitMQ (x-ha-policy: all):</para>
<programlisting>rabbit_ha_queues=true</programlisting>
<para>If you change the configuration from an old setup which did not use HA queues, you should interrupt the service:</para>
<screen><prompt>#</prompt> <userinput>rabbitmqctl stop_app</userinput>

2
doc/high-availability-guide/network/section_highly_available_neutron_metadata_agent.xml
View File

@ -32,7 +32,7 @@ service
</listitem>
</itemizedlist>
<para><literal>crm configure</literal> supports batch input, so you may copy and paste the
above into your live pacemaker configuration, and then make changes as
above into your live Pacemaker configuration, and then make changes as
required.</para>
<para>Once completed, commit your configuration changes by entering <literal>commit</literal>
from the <literal>crm configure</literal> menu. Pacemaker will then start the neutron metadata

4
doc/high-availability-guide/pacemaker/section_install_packages.xml
View File

@ -6,12 +6,12 @@
<title>Install packages</title>
<para>On any host that is meant to be part of a Pacemaker cluster, you must
first establish cluster communications through the Corosync messaging
layer. This involves Install the following packages (and their
layer. This involves installing the following packages (and their
dependencies, which your package manager will normally install
automatically):</para>
<itemizedlist>
<listitem>
<para><literal>pacemaker</literal> Note that the crm shell should be downloaded separately.
<para><literal>pacemaker</literal> (Note that the crm shell should be downloaded separately.)
</para>
</listitem>
<listitem>

7
doc/high-availability-guide/pacemaker/section_set_basic_cluster_properties.xml
View File

@ -25,10 +25,9 @@ Setting <literal>no-quorum-policy="ignore"</literal> is required in 2-node Pacem
clusters for the following reason: if quorum enforcement is enabled,
and one of the two nodes fails, then the remaining node can not
establish a <emphasis>majority</emphasis> of quorum votes necessary to run services, and
thus it is unable to take over any resources. The appropriate
workaround is to ignore loss of quorum in the cluster. This is safe
and necessary <emphasis>only</emphasis> in 2-node clusters. Do not set this property in
Pacemaker clusters with more than two nodes.
thus it is unable to take over any resources. In this case, the appropriate
workaround is to ignore loss of quorum in the cluster. This should only <emphasis>only</emphasis> be done in 2-node clusters: do not set this property in
Pacemaker clusters with more than two nodes. Note that a two-node cluster with this setting exposes a risk of split-brain because either half of the cluster, or both, are able to become active in the event that both nodes remain online but lose communication with one another. The preferred configuration is 3 or more nodes per cluster.
</para>
</callout>
<callout arearefs="CO2-2">

2
doc/high-availability-guide/pacemaker/section_start_pacemaker.xml
View File

@ -4,7 +4,7 @@
version="5.0"
xml:id="_start_pacemaker">
<title>Start Pacemaker</title>
<para>Once the Corosync services have been started, and you have established
<para>Once the Corosync services have been started and you have established
that the cluster is communicating properly, it is safe to start
<literal>pacemakerd</literal>, the Pacemaker master control process:</para>
<itemizedlist>

2
doc/high-availability-guide/pacemaker/section_starting_corosync.xml
View File

@ -7,7 +7,7 @@
<title>Starting Corosync</title>
<para>Corosync is started as a regular system service. Depending on your
distribution, it may ship with a LSB (System V style) init script, an
distribution, it may ship with an LSB init script, an
upstart job, or a systemd unit file. Either way, the service is
usually named <literal>corosync</literal>:</para>
<itemizedlist>