Hello,

I want to migrate a two node Windows Server 2003 x64 R2 Cluster with
multiple clustered SQL Server 2008 instances and a few TB of databases
to Windows Server 2008 R2 x64 with minimum downtime and keep the
instance names.

What recommendations and best practices documents are where?


Kind regards,

Peter

Good news and bad news.

Bad news: There is no cluster migration path between Windows 2003 and
2008R2.

Good news: You can keep the instance names but not the virtual server
names.

I would do something like the following:

Beg, borrow, or steal some temporary cluster hardware.

Build a new clustered SQL server using small LUNS to "anchor" the installs.

Do your login synch, etc.

Shut down the old cluster and snap the LUNS

Present the LUNs to the new server, make them clustered disks, put them in
the right service or application group and attach the databases.

Use DNS records to redirect the old virtual server names to the new systems.

Test thoroughly

Finally, flatten the old boxes and add them to the cluster. You can then
remove and return the temporary machines.

I never said it would be easy.


--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"Peter Gibbons" <Peter (AT) initech (DOT) local> wrote

Can't I change the Network name in the the new resource group to the
original network name after I have taken the old resource group down and
before I attach the databases on the new system?

I think I should make a snapshot before I move the LUNs in addition to
the normal backups.

Before all this I should lower the DNS TTLs or also migrate the IPs.
That would also lessen the possibilities of firewall issues. Bad enough
that SQL Server Clusters on W2k3 are firewall and Windows 6.x
incompatible because of the SQL browser service.

I hope account delegation to and from remote servers still works after
this. But the SPNs are bound to the SQL services accounts so at least I
have to take care that the instances protocol configuration is kept.
Especially the TCP listen ports.

I'll also have to do research on fage file sizing recommendation. This
was already kind of <sarcasm>fun</sarcasm> for the current system.


Best regards,

Peter

Geoff N. Hiten wrote:

SQL Clustering does not tolerate renaming instances or virtual server names.
It has been tried before.

Migrating IPs has its own issues.

You can make clusters firewall compatible by locking the IP addresses.

The whole cluster migration issue is a pain. I usually begin with a DNS
alias for each instance just to keep it simple later.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP




"Peter Gibbons" <Peter (AT) initech (DOT) local> wrote

Hi Geoff,

thanks for the info. So I don't have to take this as a possibility any
longer.

the Vista/firewall incompatibility I talked about is caused by the fact
that SQL server browser service answers from the cluster _node_ IP
address instead of the cluster _groups'_ IP addresses and therefore this
problem cannot be solved by locking IP addresses.

Microsoft was just to lazy to make the sql server browser communication
cluster aware and firewall compatible on W2k3. I am of that optinion
because the same thing (strict source UDP communication) works with
clustered Microsoft DNS Server.


Regards,

Peter


Geoff N. Hiten wrote:

I am familiar with the IP address strangeness. Actually, it answers using
the Physical NIC address. Try adding the Physical NIC addresses to the
firewall exceptions.

--
Geoff N. Hiten
Principal SQL Infrastructure Consultant
Microsoft SQL Server MVP



"Peter Gibbons" <Peter (AT) initech (DOT) local> wrote

Hello Geoff,

it is not strange because it is known what happens and it is a bug in
the sql server browser service that causes it:

1.) You create a firewall rule that allows the client to query the
browser service.
2.) The client sends a request to the cluster _ressource_ IP address
UDP:1434. It is not aware of the cluster _node_ IP address.
3.) The firewall passes the request along and if it is a stateful
firewall (like most firewalls are. Especially Vistas and Microsoft
Internet Security and Acceleration Server) it implicitly creates an
internal rule for the answers.
4.) SQL Server browser receives the request
5.) SQL Server browser processes the request
6.) SQL Server browser sends the answer. But instead of setting the
source IP address of the answer to the IP address the request was sent
to (the cluster _resource_ IP address) it uses the _node_ IP address
7.) The firewall drops the answer packet because no allow rule exists for it

Your proposal to "try" to add firewall exceptions leads to security
risks. Because you would have to allow all UDP Traffic originating from
port 1434 to be passed to the clients. Because UDP is stateless
attackers could easily spoof the address of "trusted" servers. You may
remember the "slammer" worm?

And again: the same thing (strict source UDP communication) works with
clustered Microsoft DNS Server. Microsoft is just to lazy to make the
sql server browser communication cluster aware and firewall compatible
on W2k3.

Plus the migration from Windows 5.x to 6.x clusters should be easier and
better documented. Especially when it comes to SQL clusters.


Best Regards,

Peter

Geoff N. Hiten wrote: