Microsoft SQL Server 2000 High Availability

Perception is reality, whether we like it or not. Because of this, it is important to make a distinction between the types of unavailability:

• Actual unavailability Anything that makes the system and its resulting solution unavailable to the people who are using it. There are varying degrees of total unavailability (complete system failure, site down, and data gone, all of which are described in more detail in Chapter 13, along with ways to mitigate them), and this is more often than not the catastrophic or unplanned failure. That said, things such as system maintenancelike service pack installs might cause total unavailability of a system.

• Perceived unavailability When a system appears to be functioning properly from an administrative standpoint, but is unavailable to end users or customers. This can happen if only one aspect of the solution is down, for example, if the database administrators (DBAs) know SQL Server is up and running, but the front-end Web servers fielding the initial requests and serving up Active Server Page (ASP) pages are down. Another example is if someone outside has cut the network cable that goes from the data center to the outside world. Poor performance or lack of scalability can also lead to perceived unavailability, because an end user requires an answer back from your systems in a reasonable amount of time.

Each person in the availability equation sees a system or the entire solution differently. To mitigate issues caused by varied perceptions, service level agreements (SLAs) must be negotiated with all parties involved in the solution, including hosting companies, end users, contractors, administrators, and so on, to ensure that uptime and performance needs are met. Each SLA might state a different availability goal, but the overall availability is based on every component, not just one. Chapter 2, The Basics of Achieving High Availability, delves further into SLAs.