As you establish your availability objectives for all of your different groups of Users and Applications, you more than likely will have varying requirements. This emphasizes the need to have multiple levels of availability, and additionally you need the flexibility to change those levels as your business changes. The concept of multiple levels of availability for different applications and their support infrastructures has been established by industry expert IDC and is portrayed in the pyramid below with the addition of recovery objectives to help determine where your specific needs fall.
The bottom two tiers of the pyramid describe an application that does not need availability planning beyond hot-swappable hardware components. While you may need to recover it at some point after a major failure, the business can continue operating with one of these servers missing. There is no hard RTO requirement.
Next, in the level labeled Recovery, are those applications for which recovery time (RTO) within a day is often acceptable. If one should fail, you want it to recover automatically if possible. But some downtime is acceptable, and even significant downtime won’t have a detrimental effect on the business.
The next level, labeled High Availability is the home of the majority of applications that run the business, such as email, CRM, financial systems, and databases. These are systems with high downtime costs, and therefore short RTO requirements. Data loss is expensive – rolling back an hour can be costly. You need to minimize interruptions and be confident that recovery will be consistent. This level requires redundant systems and components.
The highest (and smallest) slice of the pyramid belongs to those applications with the most stringent RTO requirements, where even brief moments of downtime are extremely detrimental to the client or business. These may include process control, security systems, and trading and banking applications. Some businesses may not have any applications in this category.