Archives

January 2005 | February 2005 | March 2005 | May 2005 | June 2005 | July 2005 | August 2005 | September 2005 | October 2005 | January 2006 | February 2006

 

 

May 25 - Exchange Cluster Support KBs – Russ Kaufmann

 

I am not sure what I would do without Evan Dodd being around. If his blog isn't in your list, you need to add it. Anyways, I decided that Evan saves me at least a few hours a month by him finding and reporting on issues before I run into them in my life (which seems to be more of a sit-com than a drama lately). Thanks Evan.

 

Anyway, the reason for this entry is that Evan reported some changes to a very important KB for Exchange server clustering. KB 810986 was recently re-written with a narrower focus on Microsofts support for 3rd party clustering software (to sum it up, you may need to remove 3rd party cluster software during troubleshooting efforts).

 

The concern, as Evan pointed out, is that the old KB used to contain some other very important information regarding Exchange server clustering support. Evan was nice enough to also point out that this older, and still very important information, was spun off into its own KB (I bet it gets good ratings and will not be cancelled this season). The new KB 898634 clearly spells out that installing Exchange server cluster nodes on domain controllers is not supported. This has been the case for a good while having been included as a couple of sentences in the old KB. Now, however, this issue is much clearer and will get much more visibility.

 

I know most of the Exchange and Cluster crowd already reads Evan's blog. In the future, I will try not to rehash Evan's posts.

 

 

May 11 – Exchange 2000 Cluster to 2003 Upgrade – Russ Kaufmann

Rod and I were talking the other day about how much we hate the idea of upgrading servers, especially clusters.

Upgrading any server bothers me on several levels. First, I can never be certain that all of the old operating system and all of the old application are gone (they linger in small corners just waiting to screw with my day). Second, I worry about the supportability of the environment and worry about it doing its job. Upgrading clustered applications bothers me even more because it just doesn't lend itself to providing High Availability (HA) for vital services. It goes deeper, but I just don't get a warm and fuzzy feeling knowing that there is code on my server that not only isn't needed, but it also doesn't belong there.

So what? Yeah, I heard to you say that! Well, the whole point is that rolling upgrades of existing clusters do not allow for "clean" installations. I really want clean installations for my important applications, especially when talking about a vital application like my messaging platform.  KB842427 outlines a clean upgrade scenario that is fully supported by Microsoft (Thanks, Evan, I never read that one!) for the move from an Exchange 2000 server cluster to an Exchange Server 2003 server cluster.

I previously did some testing of my own, and my steps are pretty close to the ones in this KB. Since this is fully supported, I have chopped out a bunch of stuff from the previous blog entry and updated it accordingly. According to the KB, this process is not supported for an Active/Active cluster, but I am pretty sure it would work if you added the steps for the additional EVS. Of course, I have to add the disclaimer that Active/Active is not recommended and if you are doing an upgrade it is a good time to convert to Active/Passive.

While I like the process in the KB, I have to say that I will probably avoid it for my production environment. Instead, I will use this alternate solution:

Scenario: NodeA is the Active node, and NodeB is the passive node.

  1. Borrow a server with enough disk space to hold all of your cluster's mailboxes.
  2. Back up the Exchange cluster just in case you need it (if you don't back it up, you will need to do a restore - it is the way of the jungle).
  3. Install the new server with Windows Server 2003 and Exchange Server2003 (both Standard Editions) into the existing Exchange Organization. Name it whatever you want.
  4. Apply latest service packs and patches.
  5. Move all mailboxes to the new server.
  6. Migrate public folders to the new server. This is the tough part. To make this work, you will need to wait several days until the outlook profiles are properly updated to point to the temp server.
  7. Uninstall Exchange 2000 from NodeB.
  8. Stop the cluster service on NodeB. Evict NodeB from the cluster.
  9. Use KB 833396 to manually remove Exchange 2003 and to clean up active directory from NodeA.
  10. Wipe and reinstall both NodeA and NodeB (use new names, i.e. NodeC and NodeD to avoid any name issues in case you missed something and need to do more work in AD to clean it up) with Windows Server 2003 Enterprise Edition and apply the latest service pack and patches.
  11. Create a new cluster with NodeC and NodeD.
  12. Install Exchange Server 2003 on NodeC and NodeD and create the EVS in the existing Exchange org (do not use the old EVS network name here).
  13. Install AV, content scanning, and other Exchange applications on the cluster.
  14. Move all mailboxes from the Temp Exchange server to the new cluster.
  15. Migrate the public folder structure to the new cluster.
  16. Uninstall the Temp Exchange server. Again, you will probably want to wait several days so that the outlook profiles are properly updated.

This entry was updated on 5/13/05 per info from Evan Dodd.

 

 

May 5 – Fail-Over Clustering in Longhorn – Rodney R. Fournier

This came across my desk the other day. Looks to be pretty good stuff. Moreinformation can be had at http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032271683&Culture=en-US

What you can expect:

Improved Cluster Setup, Setup is streamlined and simplified, Create an entire cluster in one seamless step, Thorough cluster testing to ensure your cluster will function properly,
All the power of a full cluster test suite in your hands to guarantee the actual cluster you are setting up will provide rock solid stability
Fully scriptable for automated deployments

A Cluster Migration Tool Will assist migration of a cluster configuration from one cluster to another rolling upgrade of Windows 2003 to Longhorn cluster. It will be a “Roll Forward” model. Migration from win2k3 to Longhorn cluster will is not that simple under the hood as from win2k to win2k3.

All New Cluster Administrator Tool! Designed to be task based and easy to use. Less dials-n-knobs to worry about.

Expanded tool functionality for better manageability. Cluster Administrator graphical tool. Command line (cluster.exe) Fully scriptable with WMI. Enhanced WMI functionality over Windows 2003. Migration from legacy cluster debug logging (cluster.log) to Event Tracing for Windows (ETW)

The name "Virtual Server" is going to be replaced by "Virtual Instance" because Microsoft has an actual product "Virtual Server 2005" to avoid confusion.

Virtual Instance Share Scoping:
Just see the shares available through that Virtual Server, Removes user confusion when browsing Clusters, Ability to modify resource dependencies while resources are online, Facilitates scaling up disks while applications are online, Cluster VSS Writer for Backup & Restore

Network Name resource stays up if either IP Address resource A or B are up. Today both resource A and B have to be online for the Network Name to be available to users. Allows redundant resources and scoping impact to dependent services and applications.

Support for GUID Partition Table (GPT) disks, Allows support for larger then 2 TB partitions, GPT provides improved redundancy and recoverability.
Support for all platforms:  x86, x64, and Itanium
Support for Hardware Snapshot restores of Clustered Disks
Improved disk Maintenance Mode will allow giving temporary exclusive access to online clustered disks to other applications

Quorum enhancements: New best-of-both-worlds quorum model. Hybrid of Majority Node Set (MNS) logic and Shared Disk Quorum model. This model will replace both of the existing models. Scales from Small to large node clusters. Clusters with or without shared disks. Geographically dispersed clusters. Can achieve current “Classic” quorum or MNS quorum functionality. Shared quorum disk is optional. NO single point of failure. Can survive loss of the Quorum disk.

No More Single-Subnet Limitation!!!!
Allow cluster nodes to communicate across network routers. No more having to connect nodes with VLANs!  Configurable Heartbeat Timeouts. Increase to Extend Geographically Dispersed Clusters over greater distances. Decrease to detect failures faster and take recovery actions for quicker failover. Using new Quorum with 3 sites, “wiser decisions” about automatic failover is provided.

Integrated with new LH TCP/IP Stack. Full IPv6 Support. Client Access via IPv6. Tunnel IPv6 address resources for IPv4 compatibility. Inner-node communication with IPv6
No more legacy dependencies on NetBIOS, Ready for NetBIOS-less environments!!
Simplifying the transport of SMB traffic
Removes WINS and NetBIOS name resolution broadcasts, Standardizing name resolution on DNS !!

Pure Kerberos based authentication, No more legacy NTLM!!
Secure mutual authentication
Enhanced encryption, Better performance. Moved from datagram (UDP) protocols to secure TCP session oriented protocols. Auditing of Cluster Access: “ Who failed over this group…?”
Logged to Security Event Log, Can be bubbled up through security tools or remote event management such as MOM.

 

May 1 – Common Exchange Server 2003 Cluster Questions – Russ Kaufmann

Whenever I teach Exchange Server 2003 classes, I get to the module that discusses clustering and I want to scream. There just isn't enough material to discuss Exchange clustering properly. Anyways, I started talking more and more about clustering as there seems to be a great deal of interest in clustering Exchange in many organizations. So, here are some of the more common questions I get when discussing Exchange Server Clustering.

Q1. If I have two nodes in the cluster, do the mailboxes exist on both nodes?

A1. Microsoft Server Clustering uses a shared nothing architecture. In this architecture, resources are created for a virtual server (they include any needed Physical Disk resources, Network Name, IP Address, and services). In the case of Exchange, the cluster virtual server is built and all the resources run on the active node. If the virtual server fails over or is moved to the passive node, the second node in the cluster then takes control of all of those resources. So, short answer: The mailboxes exist in the storage group associated with the physical disk resource and this disk resource is passed back and forth between the nodes. Only one copy of each mailbox exists.

Q2. If I build a two node cluster, do the computers have to be exactly the same?

A2. No, they don't need to be exactly the same, but they need to be very close in order to be supported. See KB 814607 and read the section on Server Cluster Qualification for more information.

Q3. I read the book and I also heard you say that you will often need additional single machine Exchange servers when using Exchange Server Clusters. Why do I need to have Exchange servers that are not part of a cluster?

A3. Several different services are not properly supported in a cluster and others just simply do not work. These services include:

To top it off, because of the SRS and ADC issues, an Exchange Server 2003 cluster can't be the first Exchange Server 2003 server in an Exchange 5.5 site. Thanks to David Elfassy for helping me with this list. http://spaces.msn.com/members/elfassy/Blog/cns!1pvwhiXzZoTl_cUJCU1PSHfw!185.entry

Q4. MSDTC is required as part of the cluster install and there are conflicting articles on the Microsoft site about whether it needs its own cluster group with its own IP resource, network name resource, and physical disk resource. What is the right answer?

A4. MSDTC does not require its own physical disk resource and it can be included in the default cluster group. You can get more info on my blog under the Micrososft Clustering category.

Q5. What is wrong with using Active/Active for Exchange clustering vs. Active/Passive?

A5. Auggghhh. Read my blog here for the answer: http://spaces.msn.com/members/russkaufmann/Blog/cns!1pwuGkyvTDx37q1_Y3JQ_E6g!137.entry

Q6. How do I add the IMAP4 and POP3 services to my Exchange cluster after it is installed?

A6. It is covered here: http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3AdminGuide/47c09fa5-09cc-4fe6-a748-d45f0d3b5ded.mspx but to boil it down to the basics, the steps (shown for IMAP4 only) are:

  1. In the Cluster Group for the Exchange Virtual Server (EVS), right click it and select New, Resource, then enter the name (i.e. EVS1 IMAP4)
  2. Select Microsoft Exchange IMAP4 Server Instance from the Resource Type list.
  3. Add all nodes as possible owners
  4. Add the System Attendent as a dependency

Q7. Why do I need MSDTC to be installed in order to build an Exchange cluster?

A7. Because. It is really only needed during the installation of the cluster because the Exchange install application needs the cdowfevt.dll that is part of the Com+ installation. MSDTC is used for workflow applications in Exchange, but other than that, it isn't used at all after the install. Oops, I take it back, it is used for upgrading as well.

Q8. How many physical disk resources should I plan for an Exchange cluster?

A8. At a minimum, you should have 4 physical disk resources per EVS, 5 if you the MTA is heavily used as it should have its own physical disk resource.

Keep in mind that each of these disks should be a LUN on a SAN. If you are carving them up yourself, I highly recommend using RAID 1 sets for the transaction logs, SMTP, and MTA (if you use it heavily) and RAID 5 for the mailbox stores. Do not create physical disk resources that are partitions on the same physical drives. When it comes to disk sizing, I highly recommend reading Nicole Allen's blog entry at http://blogs.technet.com/exchange/archive/2004/10/11/240868.aspx. She does a fantastic job of explaining how to size disks for Exchange.

Q9. Why do you recommend MSCS for the mailbox servers but not for the OWA servers?

A9. The OWA (also known as the Front End or FE) servers do not have a requirement for shared disk storage. You can achieve server redundancy and horizontal scaling using NLB or hardware load balancers with multiple FE servers since there is no requirement for a database or information stores on an FE.

Q10. Windows Server 2003, Enterprise Edition, support eight nodes in a cluster. Can I have eight virtual Exchange servers?

A10. While you can have up to eight nodes in a cluster, you can't have that many Exchange Virtual Servers in a single cluster. Once you go to three or more nodes, Exchange forces you to have at least one passive node. So, for eight nodes, it is possible to have only up to seven active nodes and one passive node. There are a couple of concerns that you need to be aware of when creating larger than two node Exchange clusters.

Q11. How many IP address do I need for an Exchange cluster?

A11. You need IP address for:

Remember a couple of important things regarding your heart beat networks:

Note: I will return and update this entry as I think of the more common questions that I get in my Exchange classes.