Microsoft Cluster Service or network load balancing?
Carol Bailey MCSE+I
Published: 07 Nov 2002 16:28 GMT
You cannot run both clustering technologies on the same server, but you can run them together in the same solution. With such an arrangement, Microsoft would portray them as complementary rather than conflicting, providing, of course, that hardware and licenses are plentiful.
Let's consider two examples that typify how and when you might use both advantageously: database-driven Web servers and e-mail access. We'll also look at a lesser-known scenario, using the same principles but employing some more obscure clustering techniques.
In all cases, the NLB servers are placed in the DMZ, simply accepting and rerouting traffic from the Internet to back-end servers that are running the Cluster Service. Because no data is held on the NLB servers, the security implications are lessened. And because the servers are running very few services, they are easier to harden. The data is kept secure behind another firewall. Connecting users are unaware of where that data is held and will have minimal inconvenience if the back-end servers change. Lets see how this works.
Web servers are placed within the DMZ and configured to accept traffic only on port 80 (http) and 443 (https). All other ports can be blocked. If SSL is being used, these servers all need a certificate installed and will be responsible for the encryption/decryption over the Internet. All servers will have Internet Information Services (IIS) running, configured identically, but the actual data being used (such as an online shopping store) is stored in a SQL database running on a back-end server (behind another firewall), which is running the Cluster Service.
The SQL back-end server is more secure because it's not directly available on the Internet, it won't have the overhead of SSL, and it can be independently reconfigured without requiring external changes (to the DNS or on clients). The data is monitored by the Cluster Service to ensure that it remains available on at least one of the clustered servers. You can also use IPSec so that the SQL servers accept connections only from the NLB servers. This will provide an additional safeguard on top of your firewall filtering rules and any router configuration. For Exchange 2000 offering IMAP4, POP3, and OWA for Internet-connected clients, the process is similar. The servers in the DMZ that accept the Internet connections are running NLB, with the actual data (e-mail, public folders, and calendar) held on back-end servers running the Cluster Service. Only this time, each NLB server that has Exchange 2000 installed must have an additional option checked to enable it as a front-end (FE) server--a new feature in Exchange 2000. Then, make sure you remove any data stores on these FE servers.
In this scenario, the NLB servers will need to communicate with more servers on the internal network than just the Exchange servers that hold the data stores. Exchange 2000 FE servers locate the back-end Exchange data stores by querying the Active Directory Global Catalog. And because this service is for your internal domain users rather than for anonymous public access, users must be authenticated with domain controllers. The Global Catalog and domain controllers are vital services, which, in this scenario, deliver an extra layer of security by being only indirectly accessible by the Internet. As before, encryption for added security will require a server certificate on the NLB servers, which offloads the encryption/decryption process from the back-end servers.
Our final example involves multiple VPN servers offering PPTP connections, all with NLB configured. Remember that IPSec won't work with NLB, so you can't use L2TP/IPSec. This means that you'll have to use PPTP. Once connected and authenticated, users connect to back-end clustered file servers. Users just need to know one IP address (or server name) for their remote connection, irrespective of how many VPN servers are actually available. Access to their data is always protected on clustered servers.
Putting it all together
We've taken an under-the-hood look at how both Microsoft clustering technologies work, including their differences and similarities, and how they can work together to offer highly available solutions. Delving a little deeper into specifics, my next article will draw up a list of pros and cons for each technology to help you decide which to use when you have to choose between them.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
Previous
Did you find this article useful?
215 out of 417 people found this useful
- Share this article:
