High availability (HA) is a characteristic of a system that aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period.
There is now more dependence on these systems as a result of modernization. For example, to carry out their regular daily tasks, hospitals and data centers need their systems to be highly available. Availability refers to the ability of the user to access a service or system, whether to submit new work, update or modify existing work, or retrieve the results of previous work. If a user cannot access the system, it is considered unavailable from the user's perspective. The term downtime is generally used to refer to describe periods when a system is unavailable.
Resilience High availability is a property of network resilience, the ability to "provide and maintain an acceptable level of service in the face of faults and challenges to normal operation." Threats and challenges for services can range from simple misconfiguration to large-scale natural disasters to targeted attacks. As such, network resilience touches a very wide range of topics. In order to increase the resilience of a given communication network, the probable challenges and risks have to be identified and appropriate resilience metrics have to be defined for the service to be protected.
The importance of network resilience is continuously increasing, as communication networks are becoming a fundamental component in the operation of critical infrastructures. Consequently, recent efforts focus on interpreting and improving network and computing resilience with applications to critical infrastructures. As an example, one can consider as a resilience objective the provisioning of services over the network, instead of the services of the network itself. This may require coordinated response from both the network and from the services running on top of the network.
These services include: supporting distributed processing supporting network storage maintaining communication services such as video conferencing instant messaging online collaboration access to applications and data as needed
Resilience and survivability are interchangeably used according to the specific context of a given study.Castet J., Saleh J. Survivability and Resiliency of Spacecraft and Space-Based Networks: a Framework for Characterization and Analysis", American Institute of Aeronautics and Astronautics, AIAA Technical Report 2008-7707. Conference on Network Protocols (ICNP 2006), Santa Barbara, California, USA, November 2006
Principles
There are three principles of systems design in reliability engineering that can help achieve high availability.
Elimination of single points of failure. This means adding or building redundancy into the system so that failure of a component does not mean failure of the entire system. Reliable crossover. In redundant systems, the crossover point itself tends to become a single point of failure. Reliable systems must provide for reliable crossover. Detection of failures as they occur. If the two principles above are observed, then a user may never see a failure – but the maintenance activity must.
Scheduled and unscheduled downtime
A distinction can be made between scheduled and unscheduled downtime. Typically, scheduled downtime is a result of maintenance that is disruptive to system operation and usually cannot be avoided with a currently installed system design. Scheduled downtime events might include patches to system software that require a reboot or system configuration changes that only take effect upon a reboot. In general, scheduled downtime is usually the result of some logical, management-initiated event. Unscheduled downtime events typically arise from some physical event, such as a hardware or software failure or environmental anomaly. Examples of unscheduled downtime events include power outages, failed CPU or RAM components (or possibly other failed hardware components), an over-temperature-related shutdown, logically or physically severed network connections, security breaches, or various application, middleware, and operating system failures.
If users can be warned away from scheduled downtimes, then the distinction is useful. But if the requirement is for true high availability, then downtime is downtime whether or not it is scheduled.
Many computing sites exclude scheduled downtime from availability calculations, assuming that it has little or no impact upon the computing user community. By doing this, they can claim to have phenomenally high availability, which might give the illusion of continuous availability. Systems that exhibit truly continuous availability are comparatively rare and higher priced, and most have carefully implemented specialty designs that eliminate any single point of failure and allow online hardware, network, operating system, middleware, and application upgrades, patches, and replacements. For certain systems, scheduled downtime does not matter, for example, system downtime at an office building after everybody has gone home for the night.
Percentage calculation Availability is usually expressed as a percentage of uptime in a given year. The following table shows the downtime that will be allowed for a particular percentage of availability, presuming that the system is required to operate continuously. Service level agreements often refer to monthly downtime or availability in order to calculate service credits to match monthly billing cycles. The following table shows the translation from a given availability percentage to the corresponding amount of time a system would be unavailable. Availability is often quoted in terms of "nines", with 90% availability being called "one nine", 99% "two nines", 99.9% "three nines" and so on. As the number of nines gets larger, the availability targets get exponentially more stringent.
Reliability levels of more than nine nines are rare, and typically only achieved by distributed networks of redundant systems, and even then largely only in theory since it is effectively impossible to measure such low levels of downtime in any reasonable period; even a single second of system-wide downtime in 30 years (say, through an unanticipated common-mode software error) would be sufficient to dethrone an 11-nines system to nine nines of availability.
NinesAvailability %Downtime per yearDowntime per monthDowntime per weekDowntime per day1 90%37 days73 hours17 hours2.4 hours299%3.7 days7.3 hours1.7 hours14 minutes399.9%9 hours44 minutes10 minutes1.4 minutes499.99% 53 minutes4.4 minutes1 minute8.6 s599.999%5.3 minutes26 s6 s860 ms699.9999%32 s2.6 s600 ms86 ms799.99999% 3.2 s260 ms60 ms8.6 ms899.999999% 320 ms26 ms6 ms860 μs999.9999999% 32 ms2.6 ms600 μs86 μs1099.99999999% 3.2 ms260 μs60 μs8.6 μs
The terms uptime and availability are often used interchangeably but do not always refer to the same thing. For example, a system can be "up" with its services not "available" in the case of a network outage. Or a system undergoing software maintenance can be "available" to be worked on by a system administrator, but its services do not appear "up" to the end user or customer. The subject of the terms is thus important here: whether the focus of a discussion is the server hardware, server OS, functional service, software service/process, or similar, it is only if there is a single, consistent subject of the discussion that the words uptime and availability can be used synonymously.
Five-by-five mnemonic A simple mnemonic rule states that 5 nines allows approximately 5 minutes of downtime per year. Variants can be derived by multiplying or dividing by 10: 4 nines is 50 minutes and 3 nines is 500 minutes. In the opposite direction, 6 nines is 0.5 minutes (30 sec) and 7 nines is 3 seconds.
"Powers of 10" trick Another memory trick to calculate the allowed downtime duration for an "-nines" availability percentage is to use the formula seconds per day.
For example, 90% ("one nine") yields the exponent , and therefore the allowed downtime is seconds per day.
Also, 99.999% ("five nines") gives the exponent , and therefore the allowed downtime is seconds per day.
"Nines"
Percentages of a particular order of magnitude are sometimes referred to by the number of nines or "class of nines" in the digits. For example, electricity that is delivered without interruptions (blackouts, brownouts or surges) 99.999% of the time would have 5 nines reliability, or class five.Lecture Notes M. Nesterenko, Kent State University In particular, the term is used in connection with mainframesIntroduction to the new mainframe: Large scale commercial computing Chapter 5 Availability IBM (2006)IBM zEnterprise EC12 Business Value Video at youtube.com or enterprise computing, often as part of a service-level agreement.
Similarly, percentages ending in a 5 have conventional names, traditionally the number of nines, then "five", so 99.95% is "three nines five", abbreviated 3N5. This is casually referred to as "three and a half nines", but this is incorrect: a 5 is only a factor of 2, while a 9 is a factor of 10, so a 5 is 0.3 nines (per below formula: ): 99.95% availability is 3.3 nines, not 3.5 nines. More simply, going from 99.9% availability to 99.95% availability is a factor of 2 (0.1% to 0.05% unavailability), but going from 99.95% to 99.99% availability is a factor of 5 (0.05% to 0.01% unavailability), over twice as much.
A formulation of the class of 9s based on a system's unavailability would be
(cf. Floor and ceiling functions).
A similar measurement is sometimes used to describe the purity of substances.
In general, the number of nines is not often used by a network engineer when modeling and measuring availability because it is hard to apply in a formula. More often, the unavailability expressed as a probability (like 0.00001), or a downtime per year is quoted. Availability specified as a number of nines is often seen in marketing documents. The use of the "nines" has been called into question, since it does not appropriately reflect that the impact of unavailability varies with its time of occurrence.Evan L. Marcus, The myth of the nines For large amounts of 9s, the "unavailability" index (measure of downtime rather than uptime) is easier to handle. For example, this is why an "unavailability" rather than availability metric is used in hard disk or data link bit error rates.
Sometimes the humorous term "nine fives" (55.5555555%) is used to contrast with "five nines" (99.999%), though this is not an actual goal, but rather a sarcastic reference to something totally failing to meet any reasonable target.
Measurement and interpretation
Availability measurement is subject to some degree of interpretation. A system that has been up for 365 days in a non-leap year might have been eclipsed by a network failure that lasted for 9 hours during a peak usage period; the user community will see the system as unavailable, whereas the system administrator will claim 100% uptime. However, given the true definition of availability, the system will be approximately 99.9% available, or three nines (8751 hours of available time out of 8760 hours per non-leap year). Also, systems experiencing performance problems are often deemed partially or entirely unavailable by users, even when the systems are continuing to function. Similarly, unavailability of select application functions might go unnoticed by administrators yet be devastating to users – a true availability measure is holistic.