changes to ch_intro.xml in high availability guide

remove , and since it’s listed
added “an” uptime of

Change-Id: I055baf97df6719321ecac9e33e7a43ca17a2cdfa
This commit is contained in:
Shilla Saebi 2014-09-06 15:02:29 -04:00
parent 7fb70cfcfc
commit 8afded3f3c

View File

@ -10,7 +10,7 @@
<para>High Availability systems seek to minimize two things:</para>
<itemizedlist>
<listitem>
<para><emphasis role="strong">System downtime</emphasis>occurs when a <emphasis>user-facing</emphasis> service is unavailable beyond a specified maximum amount of time, and
<para><emphasis role="strong">System downtime</emphasis>occurs when a <emphasis>user-facing</emphasis> service is unavailable beyond a specified maximum amount of time.
</para>
</listitem>
<listitem>
@ -43,7 +43,7 @@ Facility services such as power, air conditioning, and fire protection
</listitem>
</itemizedlist>
<para>Most high availability systems will fail in the event of multiple independent (non-consequential) failures. In this case, most systems will protect data over maintaining availability.</para>
<para>High-availability systems typically achieve uptime of 99.99% or more, which roughly equates to less than an hour of cumulative downtime per year. In order to achieve this, high availability systems should keep recovery times after a failure to about one to two minutes, sometimes significantly less.</para>
<para>High-availability systems typically achieve an uptime percentage of 99.99% or more, which roughly equates to less than an hour of cumulative downtime per year. In order to achieve this, high availability systems should keep recovery times after a failure to about one to two minutes, sometimes significantly less.</para>
<para>OpenStack currently meets such availability requirements for its own infrastructure services, meaning that an uptime of 99.99% is feasible for the OpenStack infrastructure proper. However, OpenStack <emphasis>does</emphasis> <emphasis>not</emphasis> guarantee 99.99% availability for individual guest instances.</para>
<para>Preventing single points of failure can depend on whether or not a service is stateless.</para>
<section xml:id="stateless-vs-stateful">