Windows Server 2003 Archives

August 23, 2012

When Is It Time To Stop Using a Deprecated Feature?

Twitter conversations can sometimes lead to interesting things. Jonathan Kehayias (Blog | Twitter) and I were going back and forth about something, and in some cases, how we differ on how we teach (some of that was based on teaching or not teaching a deprecated feature). It was a very healthy discussion if you ask me. I really respect Jon and he’s one of the smartest folks on the planet when it comes to SQL Server in nearly every respect. I don’t say that lightly. Paul, Kim, and the rest of the crew over at SQLskills are very lucky to have him on their team.

Be it Windows, SQL, SharePoint, whatever – all of these products at some point release a new version and as part of the lifecycle of that product, some features are deprecated. A good example is that database mirroring has been deprecated as of SQL Server 2012. It’s still in the product, but its development is over and it will disappear from the product in a few versions. Another easy example for me to mention (and what sparked the debate between Jon and I) was the use of the aforementioned cluster.exe in Windows, which was deprecated in Windows Server 2008 R2 and is technically gone in Windows Server 2012 (disclaimer: you can add it back by enabling a certain feature, but it hasn’t seen any improvement or development since Windows Server 2008; more on cluster.exe in a bit). In the immortal words of Hall and Oates, “She’s Gone” (following the Daryl Hall theme from my last post; I was challenged to use “Rich Girl”, but this was more of a natural fit – sorry Rick!).

http://www.youtube.com/watch?v=bnVXIUyshng

That begs the question: when do you stop actively using/teaching/recommending/etc. a certain feature you either know has been deprecated or will be going away (but may not be public knowledge although you have good NDA information which you really can’t share)? The answer, not surprisingly, is “it depends”.

Let’s take the case of my good friend cluster.exe who I’ve lived with for the better part of 10+ years. At this point, I’m not seeing any new deployments of SQL Server 2008 (RTM branch or R2) on the original Windows Server 2008 (no R2); it’s all basically Windows Server 2008 R2 with SP1. W2K8 R2 introduced the first round of PowerShell cmdlets for Windows Server failover clustering (WSFC). When I wrote my SQL Server 2008 book, W2K8 R2 was just being wrapped up so I documented both. As time has marched on since 2008/9, not only have I personally used cluster.exe less, when I teach my classes or do presentations, I don’t even bother showing it anymore. Why? In 2012, to me it makes no sense to show something that is deprecated and outdated, and is gone in Windows Server 2012. If you’re using Windows Server 2008 R2, you really should be using PowerShell to administer your clusters (one man’s opinion, of course; feel free to disagree). However, there are still exceptions to that rule. For one specific thing in Windows Server 2008 R2, there is no PowerShell equivalent (it’s basically related to availability groups in SQL Server 2012). This is fixed in Windows Server 2012. Similarly, some things that have a PowerShell cmdlet (Test-Cluster), have no cluster.exe equivalent. The pros outweigh the cons for me of not showing or teaching cluster.exe these days. Would I if someone asked? Sure. I’m not so stuck on not showing it; I just think it’s better to learn the stuff you can use now AND in the future when you want to go to Windows Server 2012.

The story is not so cut and dry with a feature like database mirroring. Unlike Windows which really makes it clear cut you need to move on – and quickly, SQL Server keeps a feature around and intact for at least two versions before it goes away (another really good example was DB-Lib). That could possibly translate into almost 6 – 10 years of shelf life, giving you a false sense of security. Sometimes there’s a clear cut feature that replaces it. In the case of database mirroring, a lot of people use it now. That’s one factor, so it makes the announcement that much harder. But the real crux of the problem as I see it is a case of the haves and have-nots. If you are using Standard Edition of SQL Server, Microsoft is recommending log shipping as your replacement. For Enterprise (now Datacenter) Edition, it’s availability groups. AGs are a great evolution of what was started with DBM, but with the new dependence on WSFC for deploying AGs, it may be a non-starter for some. But people who want to upgrade to SQL Server 2012 or whatever vNext (or vNextNext) may be, they need to start planning a roadmap otherwise it makes it that eventual upgrade harder because your back will be up against the proverbial wall. There’s no easy answer here, but it’s a conversation I’m having with a lot of my customers.

When it comes to having NDA information on something to be announced in the future, I can never spill the beans. Sorry. If I do, that puts me at risk with whoever I have the NDA in place with (and that comes with all kinds of legal problems for me if I do). I love my customers, but it’s not worth putting me out of business by letting something slip. That said, I can still steer customers in the right direction without them even getting a hint that there may be an underlying and different reason I am doing so.

I’ll leave you with this one final thought: as much as deprecated features are important to consider in your planning efforts, don’t let it become an obsession, either. DBM is a great example – it’s not going away tomorrow. If you’re using it now, that’s OK. A deprecation announcement didn’t mean to stop using it this very minute; just don’t get complacent about making a decision, either. A few years goes by in the blink of an eye when it comes to IT (just look at the people still running SQL Server 2000 for whatever valid reason and are stuck supporting it). Don’t be that guy or gal keeping the lights on for the few instances requiring DBM for the next 15 years. Be smart, make the right choices, and stay on a supportability path.

June 10, 2011

SQL Server Denali, Upgrading, Supported Platforms, and You

Dan Jones just blogged about the proposed upgrade paths and supported platforms for Denali. I’m glad they are publishing this information long before a new CTP is released. In that blog post, Dan encourages you to reach out to them via Connect (linked in his blog post) and I would say the same: if you have any issues or concerns, or agree with what I’m going to post here, let ’em know! Speak now or forever hold your peace.

Here’s my take on what Microsoft is proposing. You may disagree and I would love to hear your comments.

Windows Server 2003 Is Dead
If you haven’t gotten the hint, Microsoft has released two OSes (Windows Server 2008 and Windows Server 2008 R2) since Windows Server 2003/R2. Yet, I still know many customers (talk to them often) that still only support Windows Server 2003. I’ll just say this: if you haven’t started looking at, evaluating, certifying, deploying, etc. Windows Server 2008 (and at this point, it should be Windows Server 2008 R2) in your IT organization, start now. That should be a huge priority.

Supporting Windows Server 2008 with Service Pack 2 Is A Mistake
I’m focusing mainly on the server side. I know Windows Server 2008 (no R2) is Vista server. I’m in full agreement that Vista the desktop OS should be supported. Supporting Windows Server 2008 with Service Pack 2 is a huge problem for me. Why? Let me state my case.

Windows Server 2008 mainstream support ends in 2013.
Check the Microsoft lifecycle site for your country if you don’t believe me – it’s slated to end mainstream support in July, of 2013. We do not know any RTM dates, but it’s fair to assume most of you at the earliest won’t even think about Denali until sometime in 2012, if not later. Do you want to deploy on an OS that is already out of mainstream support and you can’t get hotfixes for? Yeah, I didn’t think so. This also plays into the whitepaper I wrote about supportability and staying ahead of the curve.
From an AlwaysOn standpoint, Windows Server 2008 R2 SP1 brings much more to the table.
Windows failover clustering, which both the SQL Server failover clustering feature as well as the new availability groups feature rely upon, has been further enhanced in Windows Server 2008 R2. The biggest improvement is PowerShell integration.
Windows vNext is around the corner.
Again, we don’t know release dates but Microsoft recently unveiled the first looks at Windows 8 the client OS, which means its server counterpart is also in the works. If Denali ships with Windows Server 2008 SP2 support, that means their support needs to worry about Denali on three different OS platforms with their own quirks. That’s not a scenario I would want if I was Microsoft.
[EDIT – Added] Server Core and failover clustering.
I’m not giving away any trade secrets, but you may have heard that Denali will be supported on the Server Core variation of Windows (i.e. no GUI). Server Core is part of both Windows Server 2008 and Windows Server 2008 R2. However, if you want to do something like failover clustering, cluster validation (the Windows process) only has a PowerShell cmdlet (not a cluster.exe implementation), and that would require Windows Server 2008 R2.
32-bit is dead. Long live 64-bit.
Windows Server 2008 (no R2) does have a 32-bit flavor. That means Denali would have to ship a 32-bit server (which may be the main reason behind the decision to support that OS). However, let’s face it: 32-bit is a dying breed in most environments. Truth be told, I haven’t implemented anything but an x64-based SQL Server (even under virtual machines) in my test environments as well as at all of my customers for at least 3 or 4 years going back to Windows Server 2003. I would argue most of you who need 32-bit need legacy support in some way, and that is done via some old platform. Your new apps are probably moving on, even if you are using Windows Server 2003 64-bit and not Windows Server 2008/R2.Windows has killed 32-bit. I believe Exchange has. Why not SQL? I don’t understand the wishy-washy reluctance to not embrace 64-bit fully and kick 32-bit to the curb. It’s time to move on. 32-bit has been a great platform, but let’s retire it with dignity.This does not mean that Microsoft shouldn’t support 32-bit on the desktop … I’m purely talking about deploying it in a production capacity.There’s another big reason I would recommend this: make the testing matrix smaller. Removing 32-bit as a server platform allows MS to have better testing coverage for everything else. The more platforms, the more testing, the bigger the matricies. Having done QA in the past, I know this is huge.

What About SQL Server 2000 Upgrades?
It’s clear by the list you won’t be able to go directly from SQL Server 2000 to Denali. Hopefully by now most of you know that SQL Server 2000 is not supported on any version or variation of Windows Server 2008. While Windows Server 2003 supports SQL Server 2000, 2005, and 2008, it’s gone. Kaput. Forget about it. In that context, it makes sense that upgrading in-place would not be possible to Denali. This is much like the SQL Server 7.0 upgrade scenario where in some cases with later versions of SQL Server you need to do a “double hop” (i.e. get it to 2000, and then upgrade to a later version). In this case, you’d have to do an intermediate step to 2005 or 2008. If you’re going to have to go from 2000 to Denali, start thinking about that and come up with a short term plan so you can minimize your downtime in the Denali upgrade.

I know that the decision here will not make some of you happy, but it does make sense at this point to cut the 2000 lifeline directly. I know customers out there are still using it. You have options, but you need to just figure out what you want and need to do.

What Version of SQL Server 2005, 2008, or 2008 R2 Are You On?
So the published list of minimum upgradeable SQL Server versions (meaning you can be at that version or greater) is 2005 SP4, 2008 SP2, or 2008 R2 SP1. If you’re not at any of those, as with what I said about 2000, start planning to get there now. It’ll save you a lot of grief and aggrivation in the long term.

May 10, 2011

Patching Clustered SQL Server Instances with SQL Server 2008 and SQL Server 2008 R2

One of the things you will eventually have to do to an instance of SQL Server is apply one or more of the following: a community update (CU), service pack (SP), or hotfix. I recently wrote a whitepaper entitled “Applying Updates to a Clustered Instance of SQL Server 2008 or SQL Server 2008 R2” which can be downloaded from this link. It has all the background information you need, and includes how to do things like check for reboots, script thge installs, etc. The scripts for the whitepaper can be downloaded here.

That whitepaper describes the process on how to approach patching clustered instances of SQL Server and patching, but in its examples, covers two more difficult examples because things can be complex and those are not described anywhere else (hence me wanting to write the paper). Read the whitepaper for the background information, but I thought in this blog post I would present the most simple case: one instance on a two-node cluster. All changes will be denoted in red italics.

In this example, to start, the instance is currently owned by Node A and is at SQL Server 2008 SP1 and you are looking to update the instance to SQL Server 2008 Sp2. Both nodes can potentially own the instance at this point.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	Yes	Yes	SP1	No	Yes	SP1

Table 1. Initial cluster state

To start the process, you will first have to remove the node which does not own the instance as a possible owner of the network name resource for the instance. This process and why you need to do it is described in the whitepaper.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	Yes	Yes	SP1	No	No	SP1

Table 2. Cluster state after removing Node B as a possible owner

Install SP2 on the node which is not currently a possible owner of the instance. Once that it is done, it will look like Table 3.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	Yes	Yes	SP1	No	No	SP2

Table 3. Cluster state after patching the instance on Node B

Add Node B back as a possible owner of the network name resource. The cluster will now look like Table 4.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	Yes	Yes	SP1	No	Yes	SP2

Table 4. Cluster state after adding Node B back as a possible owner

You now need to fail the instance over to Node B to start the upgrade of the instance itself as shown in Table 5. This will be the first time you would have to schedule an outage. You should do this in a controlled fashion as to minimize the impact to end users and applications.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	No	Yes	SP1	Yes	Yes	SP2

Table 5. Failing the instance over to Node B

The instance itself and the databases that were online will now be upgraded. The time it takes to do this will be fairly short. Technically you could allow connections after the failover, but you may want to wait until you are able to complete the patching of Node A and test full failover. That is up to you.

As with Node B, remove Node A as a possible owner of the instance’s network name as shown in Table 6.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	No	No	SP1	Yes	Yes	SP2

Table 6. Removing Node A as a possible owner of the instance

Install SP2 on Node A as shown in Table 7.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	No	No	SP2	Yes	Yes	SP2

Table 7. Installing SP2 on Node A

Once Node A has been patched, add it back as a possible owner as shown in Table 8.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	No	Yes	SP2	Yes	Yes	SP2

Table 8. Adding Node A back as a possible owner of the instance

Finally, you should fail the instance back to Node A as shown in Table 8 not because you want it to “live” there (your instance should be able to run anywhere in the cluster assuming you did capacity planning correctly), but because you want to ensure that there will be no problems after the installations are done and that the instance can run on all nodes. If you have allowed connections into the instance already, you will have to schedule an outage or do it during an already scheduled outage.

	Node A			Node B
	Owner	Possible Owner	Version	Owner	Possible Owner	Version
Instance	Yes	Yes	SP2	No	Yes	SP2

Table 9. Final state

February 7, 2011

Scripting the Addition and Removal of Cluster Nodes as Possible Owners of a Resource

Currently I’m writing a whitepaper on how to best approach installing updates on a multiple instance failover cluster. I’m using Windows Server 2008 R2 as the underlying operating system. As part of my testing, I’m automating a bunch of things via a combination of PowerShell scripts and scripts to run the SP install without having to do anything in the GUI. The scripts will be available as part of the whitepaper.

As some of you may know, part of the process for installing a SP or CU on a clustered instance of SQL Server is removing some nodes as possible owners. This is done on the Network Name resource. You have three ways of accomplishing this task: GUI (Failover Cluster Manager), cluster.exe (deprecated in Windows Server 2008 R2, but it’s still there for now), and in PowerShell. Because cluster.exe is going away, I’m using all PowerShell. Doing things in the GUI is more time consuming, and as I said, I want to automate as much as possible.

I wrote about this in my book Pro SQL Server 2008 Failover Clustering in Chapter 8. However, I did show some wrong screen shots for PowerShell – I showed removing possible owners of the SQL Server resource with PowerShell. That is wrong. I showed it correctly with cluster.exe. So that’s one errata for the book. I was also using the beta of Windows Server 2008 R2. Now that it’s released, I can update you here with the new stuff.

My cluster has three nodes: DENNIS, TOMMY, and JY. I’m currently in the midst of updating the EQUINOX instance from SQL Server 2008 SP1 to SQL Server 2008 SP2. I can remove TOMMY and JY from the network name resource’s possible owners with no problem using PowerShell. Set-ClusterOwnerNode has an -owners option, and my understanding is that it was always implicit. It is … but only sometimes. Let me show you.

Below is adding the nodes working as expected using cluster.exe (which I do not want to use; this syntax currently works on Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2).

Adding the nodes back using cluster.exe

Let’s see what happens in PowerShell.

First, here is the removal of the other nodes as a possible owner so I can do the patching on those nodes. Note that I do not use the -owners clause. I apologize if the formatting of the following pictures looks a little weird on your screen.

Removing nodes to patch

Things are working as expected. So far, so good. Now, let’s try to add the nodes removed back as possible owners.

First, set the nodes to all three not using the -owners clause.

Adding the nodes back not using -owners with error

Clearly, that didn’t work. Now let’s try it with the -owners clause.

Adding the nodes back successfully with -owners

Yay! All is right with the world again.

Now, what happens if you use quotes around each node?

Putting quotes around each node

As expected, this works just like it would if the nodes were not encased in quotes.

This whole -owners inconsistency is not a hindrance, and clearly you can get everything to work just fine.

However if you just use the list all encased in quotes, you will encounter this:

Error when specifying all nodes encased in quotes

What happened? Well, it not only didn’t add or remove the two nodes I wanted, but it removed ALL of the nodes as possible owners because -owners parses everything encases in quotes and expects it to be a node name. There is no node named DENNIS,TOMMY,JY so it removes all nodes as possible owners. It seems to treat it like a NULL or something like that.

This is behavior I hope is changed in a future version of Windows so that it will leave the current configuration alone or only allow removal/addition of nodes which currently do not own the resource. That way the resource, and possibly the resource group if there are dependencies (such as SQL Server being dependent on the Network Name), won’t accidentally go offline.

So what are the lessons to be learned?

Be careful if using PowerShell to add or remove nodes and using quotes around the nodes. Doing that wrong may have unintended consequences.
Adding and removing nodes using PowerShell is nearly opposite of what you would think. Since it is a single command, you specify all nodes you want to own that resource. With cluster.exe you had separate switches for adding and removing, so it was a bit more intuitive.

May 19, 2009

SQL Server Failover Clustering Now Supported Under Virtualization for Production Use! (And A Final TechEd Update)

Clustering Virtual Machines in Production
Yesterday (5/19/09), the KB article which details the support policy for SQL Server failover clusters was officially updated to include support for clustering guests/Virtual Machines … including in production. So anyone who talked to me at TechEd last week, I was right until yesterday 🙂

Now a couple of points which the KB does not say currently (and I hope it will):
1. Don’t put both of your guests under the same hypervisor. It makes no sense, and creates a single point of failure for both of your cluster nodes. Nothing will stop you from doing this since both of your guests have no idea they are virtual machines.
2. Don’t mix physical and virtual/guest nodes. Choose a single strategy. There is nothing that will prevent you from mixing node types, but it really makes no sense to me.

Remember that each of the virtual/guest nodes running under the hypervisor of your choice must also meet the requirements for Windows failover clustering as if they were nodes on physical hardware. That means they must have redundant everything, which goes back to my point #1.

Other helpful links which apply:
KB943984 The Microsoft Support Policy for Windows Server 2008 Failover Clusters
KB309395 The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog (pre-Windows Server 2008)
KB327518 The Microsoft SQL Server support policy for Microsoft Clustering

This is all good timing as I am finishing up my book. It does make things a bit difficult as some chapters are done, but this will make it in one way or another.

TechEd Wrapup
It was a good week. Thanks to everyone who came to the booth and to my session. I do look and incorporate feedback from the sessions I do, so anyone who posted evaluations, it’s helpful.

The Tech Talk I did (Clustering Microsoft SQL Server 2008 with Windows Server 2008) is also posted, so have a look. It has some demos and is about 20 minutes long give or take.

Popular Posts

Categories