Load Balancing vs. Failover Clustering

A pending post from long time!!! At distance both look quite similar and are point of confusion for many. Rationale though is making Load Balancing address scalability while Failover Clustering address high availability. Load Balancing is all about improvising performance (scale) while Failover Clustering is improvising uptimes mitigating system failures. Another difference is, you would find Load Balancing happening at web/application servers (stateless hopefully) and failover clustering at database servers (state full). Industry seems to be using word “Cluster” (set of connected nodes) for both – but with different intents of Load & Failover.

Both are also separate things in terms of configuration & setup. For instance, Windows 2003 (currently that’s what we have in our production) has separate options for Load Balancing & Clustering. Windows recommendation is not to mix both, i.e. you shouldn’t cluster machines for failover which are already configured for load balancing.

Setting up load balancing is simple – you need couple of machines connected to a common network and an additional IP where clients would connect to. This Virtual IP where the requests are made by clients, is in turn is used for Load Balancing nodes that part of this cluster (load balancing cluster).

Setting up failover clustering on the other hand is little complex. You need 2 networks a public and private (hear beat), a shared drive (called Quorum), and an additional Public IP (in addition to minimum – 2 public and 2 private IPs that 2 systems will have). Remember, creating a failover cluster at Windows level is a primary requirement to build a failover SQL Server cluster. Reason to create a Windows level cluster is install required cluster services and create cluster groups (logical collection of nodes). You can select a cluster group (obviously at least 2 nodes should be part of this group) and configure SQL Server Cluster or anything else on top it. SQL Server Cluster would require an additional IP, another shared disk for installation & database files (this disk is a shared resource for chosen cluster group), domain account (that has administrative privileges on all nodes) & group on that domain which that account has complete access. Shared Quorum and Shared Disk are normally part of SAN storage. I have also come across quite a few implementations using Starwind or similar tools to create these shared iSCSI targets in form of virtual disks (.img). It might be helpful to know that Windows 2003 doesn’t have the iSCSI initiator built-in and you can download the same from here.

Hope above helps to some extent .

RAID 0 vs. RAID 1 vs. RAID 4 vs. RAID 5 vs. RAID 10

My company had ordered some hardware recently. As usual, the buying process brought in lot of insights which I thought of sharing with you guys. I will cover them all in parts, starting with basics. First let’s see a fundamental concept called RAID which becomes critical when you start planning your storage.

RAID (Redundant Array of Independent Disks) – This technology is mainly used for hard disks to provide protection against hard drive failures and also to improvise performance (of course you can select either of failure protection / performance). RAID also gives an implicit way to scale your disks (after all it’s an Array). RAID builds on 2 primary concepts – Striping (storing data across multiple disks sectors of multiple drives so that disk head can read more data in a single move) and Mirroring(replication of drives). RAID requires minimum of 2 disks & can have maximum of 32 disks. It’s also important to note here that RAID controllers typically abstract out the striping & mirroring details giving end user a feel of only a single disk available at disposal. Below are some of the popular RAID configurations out there:

RAID 0 – Striping
Pros: Better performance – data replicated across drives, no storage overhead as drives are utilized 100%
Cons: Possibility of losing entire data on failure of a single disk
Minimum Disks Required – 2

RAID 1 – Mirroring
Pros – Guard against disk failure as data is replicated across disk drives
Cons – Replication creates storage overhead as the same data is copied across drives
Minimum Disks Required – 2

RAID 4 – A Mirroring variation. It actually uses the concept of ‘Parity’ (based on XOR operation – Sum of all bits across drives – if sum is even parity set to 0 else parity set to 1) to retrive data in case of a disk failure, which reduces storage overhead – an issue with RAID 1.
Pros – Reduced storage overhead (actually we need only a single disk here to store parity). E.g. if you have 3 disks, parity can be stored on 3rd. So your overhead is only 33% in terms of storage.
Cons – Still suffers from a performance prespective
Minimum Disks Required – 3 (anyways 2 doesn’t make sense and the more no. of disks you have lesser would be your storage overhead)

RAID 5 – Striped Data & Striped Parity – most widely used. Taking RAID 4 to next level by striping the parity (parity gets stored across disks instead of getting stored on single disk) and also striping data (that anyways doesn’t matter as far as parity is concerned)
Pros – Good Performance, Good failure protection
Cons – Not as good when your requirement is only performance or only failure protection (parity doesn’t come for free).
Minimum Disks Required – 3

RAID 10 (1 + 0) – Combination of Stripe & Mirror with no parity. You stripe the data across drives & mirror the entire set of drives.
Pros: Best in terms of performance & guards against potential failures.
Cons: Costly in terms of storage overhead
Minimum Disks Required – 4 (and for > 4 you must have even number of disks)

There are few other RAID levels which I would leave for the reader to digg into, as they are comparatively not that widely used. I will continue exploring hardware aspects further in next thread.