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:
parent
7fb70cfcfc
commit
8afded3f3c
@ -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">
|
||||
|
Loading…
Reference in New Issue
Block a user