The Best of Russ and Rod

August 11, 2005

Exchange Q&A with David Elfassy

Filed under: Server Clustering 2003, Storage, Exchange — Administrator @ 11:50 pm

David Elfassy IM’d me yesterday and asked me to play a game of word association. I hate word associations. It seems that word associations always lead to people thinking I am insane, and I get locked in padded rooms.

Anyways, he said it would really help him with some Exchange materials that he is working on, so I agreed.

David: SAN optimization. (First word that comes to your mind)

Russ: Banana (I was hungry and was reaching for a banana)

David: You *&(%$__*(&*(@#** - (wow, that was rude)

Russ: Cheerios (what else do you say to that?)

Note: at this point, I could already hear the ambulance and the guys in white suits coming to take me away.

David: SAN optimization.

Russ: diskpar, multipathing (see the link for Rod Fournier’s diskpar blog, and see on the Exchange team blog on the same subject here)

David: SAN availability

Russ: Multipathing, SAN replication, geo clustering

David: Transaction log performance on SAN’s

Russ: disable write back cache for the LUN if possible, provide a separate LUN, RAID 1 within the SAN

Note: David asked me to explain why I did not say anything about RAID 10 or 0+1. I told him that I can’t see throwing that much at a transaction log unless you really have huge amounts of transactions that require scaling up the size of the log space to hold a large size.

David: iSCSI for Exchange

Russ: Interesting solution, not near the I/O achievable via a SAN with multipathing, though. Must use a dedicated gig/e network to achieve best performance.

David: WIndows Storage Server with NAS for small orgs

Russ: Good solution depending on size of org. Again, not near the I/O of an inexpensive SAN device and should again have a dedicated gig/e network for the connection.

Comments Off

Microsoft Clustering and Firewalls

Filed under: Network — Administrator @ 12:45 am

When we installed our first Exchange 2003 Cluster at work our firewall group was very mad, they called screaming about how we had set it up. They did not like the fact that ingress (inbound) traffic was to the Virtual IP (VIP) and egress (outbound) traffic was via which ever node was controlling the Exchange Virtual Server (EVS) at the time. “This will simply not do”, they said. “We want you to use the same IP for inbound and outbound traffic”. “You are making our firewall rules very difficult to maintain and manage!”

Hmm, I see the point our firewall group was trying to make. Why was the traffic pattern this way?

Simple answer – that is how Microsoft wrote the clustering code. No, that would not do, they are pretty smart and would want a better answer.

Longer answer – You can’t send traffic on a network that does not really exist. Think about what the VIP is, it’s not real. A VIP by definition is not real. Because of this fact, nothing can leave it. The only direction traffic moves via the VIP is inbound. The VIP is bound to a physical network interface (on the controlling node), thus allowing it to interact with the real world. All outbound or return traffic has to come from a real network interface. So, traffic is allowed to come into the VIP, which is bound to a real network interface. That real network interface is then the one that replies or send out information. This makes rules in the firewall very interesting (because the inbound is static – always the VIP, but outbound is from which ever node is controlling at that moment and can change over time), hence why they were so mad!

Conclusion:
The Virtual is for inbound traffic only. Outbound traffic is via the controlling node at that time. After I explained this, my firewall team was still not happy, but at least they fully understood J Did I mention that this is how other clustered services like SQL Server 2000 handle traffic too?

Comments Off