openstack/openstack-manuals
Code Issues Proposed changes

changes to section_run_openstack_api_and_schedulers

Browse Source 
remove ) there is no (
remove space between Active/Passive
changed configure to configuring

Change-Id: I9396b03ca3e7d7c1b784dd068ecdd696624f74e1
This commit is contained in:
Shilla Saebi 2014-09-06 15:34:05 -04:00
parent 7fb70cfcfc
commit 6f46158ba3
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -11,7 +11,7 @@
<title>API services</title> <title>API services</title>
<para>All OpenStack projects have an API service for controlling all the resources in the Cloud. <para>All OpenStack projects have an API service for controlling all the resources in the Cloud.
In Active / Active mode, the most common setup is to scale-out these services on at least two nodes In active/active mode, the most common setup is to scale-out these services on at least two nodes
and use load balancing and virtual IP (with HAProxy &amp; Keepalived in this setup).</para> and use load balancing and virtual IP (with HAProxy &amp; Keepalived in this setup).</para>
<para> <para>
<emphasis role="strong">Configure API OpenStack services</emphasis> <emphasis role="strong">Configure API OpenStack services</emphasis>
@ -33,7 +33,7 @@ All OpenStack configuration files should refer to virtual IPs.
<emphasis role="strong">In case of failure</emphasis> <emphasis role="strong">In case of failure</emphasis>
</para> </para>
<para>The monitor check is quite simple since it just establishes a TCP connection to the API port. Comparing to the <para>The monitor check is quite simple since it just establishes a TCP connection to the API port. Comparing to the
Active / Passive mode using Corosync &amp; Resources Agents, we don’t check if the service is actually running). active/passive mode using Corosync &amp; Resources Agents, we don’t check if the service is actually running.
That’s why all OpenStack API should be monitored by another tool, for example Nagios, with the goal to detect That’s why all OpenStack API should be monitored by another tool, for example Nagios, with the goal to detect
failures in the Cloud Framework infrastructure.</para> failures in the Cloud Framework infrastructure.</para>
</section> </section>
@ -76,6 +76,6 @@ heat-engine
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>Please refer to the RabbitMQ section for configure these services with multiple messaging servers.</para> <para>Please refer to the RabbitMQ section for configuring these services with multiple messaging servers.</para>
</section> </section>
</section> </section>