openstack/openstack-manuals
Code Issues Proposed changes

Merge "changes to section_run_openstack_api_and_schedulers"

Browse Source
This commit is contained in:
Jenkins
2014-09-09 02:26:33 +00:00
committed by Gerrit Code Review
parent 61315f9bb6 6f46158ba3
commit cdbc45f96a
1 changed files with 3 additions and 3 deletions
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>
<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>
<para>
<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>
</para>
<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
failures in the Cloud Framework infrastructure.</para>
</section>
@@ -76,6 +76,6 @@ heat-engine
</para>
</listitem>
</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>