With Windows 2008 you now have the option to set up a cluster using different IP address subnets for each site.. If you needed to replicate data from a west coast data center to an east
Trang 1of setting up the same IP address subnet in two different data centers is extremely
complex With Windows 2008 you now have the option to set up a cluster using
different IP address subnets for each site This makes the process much easier to
set up
Configuring & Implementing…
Combining Solutions
In the real world setting up a geographically dispersed cluster is
extremely difficult even with the advancements that have been made
the clustering software in Windows Server 2008 You may in fact find it
easier to combine two of these solutions instead.
If you needed to replicate data from a west coast data center to an
east coast data center, but still maintain a high-availability solution at
your primary West Coast data center, one configuration you may choose
is a cluster on the WeSt CoaSt, then use database mirroring to replicate
your data from the WeSt CoaSt to the eaSt CoaSt this would allow
you to satisfy the requirements of having a local high-availability solution
on the west coast (your Windows cluster); and still giving you the option
of replicating your data to the east coast using database mirroring.
In this case you would probably want to use database mirroring in
the high performance mode so that your front end application is not
slowed down by the WaN link latency between the two sites When
deciding on how to replicate data between sites over a WaN, keep in
mind that no matter the solution you use data takes approximately
three microseconds for every kilometer of fiber cable a 100 kilometer
distance will have a round trip time of approximately 600 microseconds
(0.6 milliseconds).
Going from a data center in New York to a data center in Los
angeles and back will take approximately 26 milliseconds this is in
addition to any latency that is added by firewalls, encryption devices,
and the time it takes the storage to actually write the data to the hard
drive to us 26 extra milliseconds is not much, but to the SQL server this
amount of time is a very long wait, which will be shown within the local
SQL server as blocking while you wait for the data to be transmitted
and the acknowledgment to be returned.
Trang 2When you set up a geographically dispersed cluster you do not use a quorum drive This is because you can’t replicate the quorum drive from site to site and have the cluster work correctly Instead you use what is called a Majority Node Set When you use a Majority Node Set whenever a node fails or the cluster is told to fail over a service, all the nodes take a vote as to which node should start the service The node that wins then starts the service A majority node set requires an odd number of servers so that there cannot be a tie—for example if you have three nodes
at your primary site and two nodes at your backup site as shown in Figure 6.17
Figure 6.17 A Majority Node Set
In the event that your primary site fails and the two servers on the right cannot connect to the three servers on the left they will take a vote between themselves and decide if the remote servers are offline Once they decide that the three servers
at the primary site are offline they will take control of the clustered resources and begin starting the clustered resources such as the SQL Server Service and the SQL Server Agent Service
Once the primary site comes back online, the storage arrays at each site will begin replicating back the changes that have been made Once this process is completed the cluster will be ready to move the services back to the original site
Trang 3If you have automatic failback enabled then the cluster will take a vote as to which
servers should control everything The site with three nodes will win the vote and
the services will be automatically moved back If you do not have automatic failback enabled then you will need to manually trigger the failback when it is most convenient
to do so
Troubleshooting a clustered installation of SQL Server can be a bit trickier
than troubleshooting a stand-alone SQL Server installation This is because of the
clustered component In the event that SQL Server is not starting, check the
ERRORLOG file for information This will tell you if the SQL Server service is
starting or not If the SQL Service is not starting check the application log and
system log for errors about the cluster If the ERRORLOG file shows that the
SQL Server is starting and stopping then your issue is probably not going to be
related to the cluster
If you recently have changed the resource dependencies of the cluster and the
SQL Server will no longer start, make sure that the SQL Server is dependent on
all the correct hard drives and on the network name If the SQL Service is not
dependent on the hard drives the SQL Server will not start
Changing the IP Address of a clustered SQL Server is not as easy as simply
changing the IP Address of the SQL Server IP address resource in the cluster
administrator You will also need to search the registry and change any references
from the old IP address to the new IP address, or the SQL Server will start, but not
listen correctly
If you have multiple instances of SQL Server installed in a clustered environment make sure that the instances are configured to listen on their own IP address only
or that each instance uses a different TCP port number If you do not, the SQL
Service will attempt to listen on all the IP addresses on the node of the cluster on
which it is being hosted If all SQL Services have the same port number, only the
first SQL Server to start will actually be able to listen on that port since only a
single Windows Service can use any one port number If you use the default of
dynamic port numbers for the named instances this will not be a problem because
the SQL Server will pick a port number at random of the ports that are not in use
If you are using the SQL Server Maintenance plans to back up the database, and you are backing up the database to a disk that is a clustered resource, but is in a
different Resource Group than the SQL Server, be sure to create a network share
via the cluster administrator and back up the database over the network to that
net-work share If you do not, and the Resource Group that holds the hard drive you
are backing up to is hosted by a different node of the cluster than your SQL Server
Resource Group, the backups will fail as the hard drive cannot be accessed locally
Trang 4In the example cluster shown earlier, you would want to host the hard drive in the SQL01 Resource Group where the SQL Server is hosted in the SQL01V01
Resource Group You would then want to create a network share \\SQL01\
SQLBackups that points to a folder on that new hard drive You would then set up the backups to point to the network share instead of a local drive
Replication
Replication is another technique that can be used for high availability By replicating the data from one system to another you can easily redirect your clients to the secondary system in the event that your primary system fails Since you are going
to want the changes that are made to the backup system replicated back to the primary system after it is brought back online, you will want to use merge replication
so that the subscriber can replicate its changes back to the publisher Refer to Chapter 9 for information on setting up SQL Server Replication
When using Merge replication, failover and failback are relatively easy Simply redirect your clients to connect to the subscriber Once the publisher is back online and in sync you can configure your clients to connect back to the publisher
If you are using transaction replication then you will need to set up your subscriber as a publisher, and publish the data back to your original publisher After the two servers are in sync, stop all client connections and remove the replication Point all your clients to the publisher and configure that server to publish its data back to the subscriber
Replication typically does not make a good high-availability solution because new objects are not replicated to the subscriber automatically It is also difficult
to make schema changes since replication limits what can be done to the table schemas It also requires that you manually deploy procedures, views, functions, and such to the subscribers whenever they are updated
The upside to using SQL Server Replication for your high-availability solution
is that is you are using merge replication and your database is designed without having the requirement of unique columns that are not part of your primary key You can use your high-availability solution to spread the load of your database between multiple SQL Servers
If your database has a table that requires uniqueness as shown in the following example then it is not a good candidate for running both machines actively because you could create a record in one server, then create a second record with the same value for the unique column on the other server before the data is able to replicate Even with a unique index or constraint on this column, uniqueness cannot be guaranteed since the unique index or constraint can be enforced only after the data
Trang 5has been replicated to the other server If you have a unique index on the
UserName column then your replication will fail because it cannot successfully
add the row to the other server
CREATE TABLE Authentication
(UserId INT PRIMARY KEY IDENTITY(1,1),
UserName NVARCHAR(50) /*This column must be unique*/,
Password NVARCHAR(100),
Active BIT)
Troubleshooting replication when used for a high-availability solution will be the
same as when using normal SQL Server replication This is discussed in Chapter 9
When using SQL Server Replication for your high-availability solution like log
shipping and database mirroring you will need to license each machine to which
the database is being replicated
Recovery Model
Depending on Which high-availability model you select will determine which
recovery models are available to you for your database Database mirroring, clustering, and replication will support any of the available database recovery models When
using log shipping you should use the full recovery model This is because you have
to keep the transaction log available and every transaction needs to be logged so
that it can be backed up and shipped to the backup server
All recovery models log most or all transactions to the transaction log The
bulk logged recovery model is different from the simple and full recovery models
in that all transactions are fully logged with the exception of bulk insert tasks
These bulk insert tasks are only minimally logged With the simply recovery model
the transactions are purged from the transaction log file every few minutes at most
Expandability
In addition to having the redundant hardware some systems will allow you to add
CPUs and RAM to the system on the fly These are Enterprise class features, but as
more time goes on these features will make their way into more and more systems
Hot Add CPU
The ability to add CPUs into the server is a hardware and operating system function
as well as a function of the SQL Server This gives you the ability to physically add
physical CPUs to the server without powering down the system This typically is