 |
Protecting SQL Server is about maintaining user connections to the database. As such, it is not just about maintaining hardware availability. Resilience has to move up to the application level. This can only be achieved by monitoring all elements of the application stack, including the SQL Server application, the SQL Server database, the O/S, hardware, network and all associated services.
During the past 7 years we have helped many customers protect and recover their SQL Server applications, and we can help you gain the benefits of High Availability Clustering, at a fraction of the cost with increased functionality. Our solutions offer features not available with traditional clustering products - for instance 2- or 3-node disaster recovery, LAN or WAN failover, multiple server configurations, physical to virtual recovery and the option of whether or not to use shared storage - while also providing resilience and enhancing availability.
LifeKeeper actively monitors and protects all resources required by the SQL Server application, and actively checks that the application itself is running, resulting in responsive failover to another node if there are problems (e.g. faulty network cable, disk failure or server hang).
LifeKeepers active monitoring helps to ensure the highest level of availability, going beyond just checking whether the server is alive, as seen in many other products.
LifeKeeper protects the following optional SQL Server services:
The SQL Server recovery is capable of running in two basic configurations. The first, where both servers are running separate instances of SQL Server (Active/Active), or secondly where one server acts as a hot backup for the other (Active/Standby). Both servers can run other applications, which may be under control of the Lifekeeper software.
The SQL mirroring and recovery solution can be used with and without shared storage. Without shared storage, data is replicated between the active and backup server so that when failover occurs, the most recent data is used when the backup becomes live.
All data files are stored on shared or mirrored volumes, while the application binary files are installed on each host locally. LifeKeeper monitors all resources (processes, disk, IP addresses) and upon detecting a failure it initiates a failover.
This diagram shows LifeKeeper protecting SQL Server in an Active/Standby configuration, without the use of shared storage, SteelEyes data replication product is used to mirror data between the nodes over a LAN. The LAN is normally a cross over ethernet cable, allowing for a high speed, low latency, low risk of failure configuration. Data Replication can also be used over a WAN to produce a Disaster Recovery scenario.
The mirroring between nodes can be either synchronous or asynchronous depending upon the environment and requirements. Normally within a LAN environment where bandwidth is not an issue, synchronous replication will be used, which will help ensure data integrity.
Synchronous mirroring provides greater protection for data, but can result in poorer performance as writes have to take place on both servers before control returns to the calling application.
Asynchronous mirroring is near real time, in that writes occur on the local disk, and are queued to be sent to the remote server before returning control to the calling application. Asynchronous replication would be used in a WAN environment. Because WANs often have lower bandwidth or greater latency than a LAN, for performance reasons it is often necessary to sacrifice some of the fault tolerance capabilities of the replication and use an asynchronous solution rather than a synchronous solution.
The following scenario shows shared storage being used in an Active/Active configuration where there are two instances of SQL server, which may be running on either nodes. This allows for maximum hardware utilisation, and leads to greatest performance, as well as allowing for manual load sharing. Each instance of the SQL server is "virtual" in that it can move from one host to the other, without clients being aware - this is normally done through the use of floating IP addresses.
In this configuration, either shared storage or data replication technologies could be used.
This is similar to above, except there is a local and remote backup node. When there is break in service due to hardware failure, or inoperability of SQL services, a local recovery takes place. If, however, there is a site disaster, then a recovery to the remote backup node takes place.
For a seamless recovery of your SQL servers, SteelEye Life Keeper from Open Minds guarantees to provide you with a complete disaster recovery solution ensuring that you maintain business continuity. Our high availability solutions will grant continuous data protection providing data replication as well as the monitoring of all your SQL servers to ensure failover through the Java GUI.
We have been able to maximise our investment in our high availability cluster by implementing SteelEye LifeKeeper in an active/active mode. The second server in the cluster is used to run other vital service components – using this active/active configuration means that there is no need for redundant hardware to act as a standby server.
Chris Good, M-Spatial
