Chapter 10 : Designing a SQL Server 2005 Solution for High Availability MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design

Chapter 10 : Designing a SQL Server 2005 Solution for High

Availability

MCITP Administrator: Microsoft SQL Server 2005 Database Server

Infrastructure Design Study Guide (70-443)

SQL Server 2005 High Availability

• Dependence on databases is growing.

• More applications used 24x7

• Maintenance periods shrinking or being eliminated.

• High availability can help

© Wiley Inc. 2006. All Rights Reserved.

SQL Server 2005 Technologies

• SQL Server 2005 has four main technologies– Failover clustering– Database mirroring– Log shipping– Replication

• Each meets different goals and solves separate problems


Availability

• Measured in different ways (application, database, network)

• Holy Grail - 5’s (99.999%) – Equates to 5 minutes of downtime a

year.– Single server can’t get here

• Need some technology to distribute load


Availability – cont’d

• Issues affecting availability– Maintenance– Upgrades

• Multiple servers can mitigate issues


Examining HA Technologies

• Trying to increase availability• Identify Single Points of Failure

– CPU– Disk drive– Power Supply– Network– OS– SQL Server– Others


Setting HA Goals

• Since each technology solves different problems, need to identify which ones you need to solve.– Hardware failures– Geological disasters– Application problems.– Automated failover


HA System Limitations

• High availability <> Scalability

• Data Loss potential

• Delays during failover


Failover Clustering

• Most common HA technology

• Improved from SQL Server 2000

• Entire instance is protected from disaster

• SQL Server Agent, Notification Services, Analysis Services, and replication failed over.

• Virtual node presented to clients


Failover Clustering Limitations

• Shared Disk Resources

• Cost

• Hardware limitations

• Complex network configuration

• Employee training (DBA and system administrator)


Designing Clustering

• Node count limited by MSCS resources– 8 nodes with Windows 2003

Datacenter and SQL Enterprise– SQL Standard limited to 2 nodes

• Active/Active v Active/Passive

• N+1 configurations


Designing Clustering – cont’d

• Geographic considerations– Protect against isolated disaster (fire,

bomb, etc.)– Hardware and networking can be very

expensive.

• Hardware decisions– Must be on the HCL– Shared disk subsystem required


Designing Clustering – cont’d

• Licensing– Only active nodes must be licensed.


Database Mirroring

• New technology introduced in SQL Server 2005.

• Not supported in RTM, need SP1• Addresses high cost and overkill of

clustering in some situations.


Database Mirroring – cont’d

• Automatic Failover

• Uses any Windows hardware, even disparate hardware between servers

• Protects against disk failure

• Very fast failover

• Operates at the database level


Database Mirroring Limitations

• Database Level means that logins must be manually setup on both servers.

• Master, msdb, model not protected

• SQL Agent jobs not failed over.

• ADO.NET 2.0 clients required for automatic failover.


Database Mirroring - Roles

• Principal – database to be protected

• Secondary – database that receives the updates from the principal

• Witness – optional server used to initiate automatic failover

• Quorum of two servers required to initiate failover.


Database Mirroring Protection Levels

• High Performance Mode– No confirmation from secondary– No automatic failover– Some data loss possible

• High Protection Mode– Secondary acknowledges updates– Manual failover required– No witness


Database Mirroring Protection Levels – cont’d

• High Availability Mode– Automatic failover supported– Updates acknowledged– Witness required


Configuring Database Mirroring

• Endpoints needed on each server to transfer updates.

• Initialize mirror database with a backup.

• ALTER DATABASE SET PARTNER to begin updates.

• Be sure you test failover and failback.


Log Shipping

• Based on normal backup and restore procedures

• Enterprise edition required in previous versions. Supported in Standard in 2005.

• Supports multiple secondary servers

• Secondary databases can be used for reporting.


Log Shipping Limitations

• No automatic failover

• Application changes may be required to failover

• Secondary server name must be different.

• Operates at the database level


Log Shipping Roles

• Primary server– Normal server for clients

• Secondary server– One or more servers receiving log

backups from the primary

• Monitor server– Stores tracking information about

backups and restores.


Failover with Log Shipping

• Must be performed by DBA– Restore remaining logs on secondary

using the NORECOVERY option– Backup tail from primary server if

possible– Restore tail on secondary– Bring secondary online with the

RECOVERY option.– Configure clients to connect to the

secondary


Replication

• Not specifically a high availability technology.

• Can be adapted for HA situations

• Use Transactional or Merge replication for HA


Transactional Replication for High Availability

• Use low latency batches to move transactions

• Similar to log shipping, but can be faster

• Secondary system is full live for queries.

• Disparate hardware can be used• Operates at the publication level, not

database level.© Wiley Inc. 2006. All Rights Reserved.

Merge Replication with High Availability

• Similar to transactional replication.

• Updates can be made to either the primary or secondary nodes

• Can scale the system when both nodes are active


Highly Available Storage

• Any HA solution requires highly available storage

• Two main choices– RAID– SAN


RAID Technology

• Redundant Array of Inexpensive Disks– RAID 0 - Striping– RAID 1 – Mirroring– RAID 5 – Striping with Parity– RAID 1 + 0 – Combine RAID 0 + 1

• RAID 0 not suitable for databases.


SAN Storage

• Large set of disks attached to multiple servers.

• May use RAID technology

• Specialized installations with proprietary hardware

• Work with vendors to design database storage


Designing an HA Solution

• Consider more than the database server

• Consider Failover times

• Application failover issues

• Cost of solutions


Nontechnical Issues

• In a disaster situation, consider other issues– Staffing– Geographic connections– Load on secondary server


Preparing for Migration

• Develop a plan to move to the HA solution– Minimize downtime– Train staff– Network Abstraction– Test


Summary

• Each HA technology has different benefits and costs

• Each solves different problems

• Match up needs with the technology

• Test the solution to be prepared for a real disaster


Documents

Chapter 10 : Designing a SQL Server 2005 Solution for High Availability MCITP Administrator: Microsoft SQL Server 2005 Database Server Infrastructure Design