Many of you will be familiar with the term “JBOD“, and indeed will perhaps know that it stands for “Just a Bunch of Disks” and historically is a technology that you would not consider using with Exchange server. However, in the context of Exchange 2010 there have been some changes which now make the JBOD a potential cost effect storage consideration for solution designers.
Introduction
Many Exchange Administrators will be deeply familiar with the concepts of RAID, appropriate Storage, types of disk, IO sizing, IO load etc., and redundancy within the disk sub-system.
However, the principle of using JBOD’s as a storage host for the Databases and Transaction logs for Exchange will be for the most part a “taboo” concept – as in previous versions of Exchange Server prior to 2010 it was not really viable due to a number of limitations.
What is JBOD?
At the most fundamental level a JBOD is either a single or number of disks which are grouped together and presented to the Operating System as a single volume – this is called “Spanning”.
There is no resilience applied in this configuration – e.g. if you lose a single disk in the JBOD then there is a high likelihood that you will lose data, as the concept of a JBOD does not include not fault tolerance (e.g. it is not a form of RAID, although is often mistakenly believed to be so).
Below (figure 1) I have provided a diagrammatic example of what a typical JBOD might look like at a physical level and what it may look like when presented to the end Operating System.
Figure 1: Simple example of a JBOD
Advantages of JBOD
There are two main advantages of a basic JBOD architecture:
- Full space utilization
Unlike many RAID configurations JBOD does not limit you to the size of the smallest disk with the array (in fact you should not mix different disk sizes in any RAID array) – a JBOD configuration will allow for the combined space of all the drives to be used by the end Operating System.
- Cost effective
Basic SATA disks and Controllers are cheap in comparison to their SCSI, SAS and Hardware RAID cousins – therefore if you are planning storage architecture on a budget and you are sure that your backup provision is water tight then they might be a consideration.
Disadvantages of JBOD
- No hardware increase in drive performance
There is an argument that JBOD can actually affect overall performance where multiple drives are in play, as it is more difficult for the drives to be used sequentially.
- No redundancy
This is a major limitation of JBOD – if you lose the disk (in a single spindle JBOD) or one of the disks (using multiple drives) – you are heading back to your backups. If you have no backups then the data is gone!
Just on the basis of those two disadvantages, you might be asking the question – why consider a JBOD implementation in an Enterprise Exchange environment at all?
Well prior to Exchange 2010 many would agree with you wholeheartedly – however in Exchange 2010 the product team have managed (in certain configurations) to make JBOD a cost effective storage option.
Usage in Exchange 2010
Most of us will agree that the single most expensive element of an Exchange Infrastructure is typically the Storage sub-system.
Whether you use DAS, SAN, iSCSI etc. you are looking at a significant investment in technology (when you take into account of drive speeds, RAID controllers, SAN Fabrics, Enclosures, LAN changes) – it amounts to potentially multiple thousands of pounds or dollars – whereas if you could leverage the cost of simple disks (SATAe or SATA) attached to your Exchange servers there could be a huge saving.
So how is the JBOD concept now possible in Exchange 2010?
Microsoft added in two key features which make JBODs a realistic option for use in Exchange 2010 Enterprise environments.
The first of which were a number of breakthroughs in the context of Exchange database IOPS performance, these include between 50% – 70% performance increases over Exchange 2007 as well as new algorithms within the core code which are optimized for SATA disks (the code was changed so that disk writes did not come in bursts – which normal non Enterprise SATAe disk could not handle).
There are also a number of changes within the Storage Engine (such as Larger and Sequential I/O) which means that random reads and writes to the Database are significantly reduced as most data is stored sequentially (this reduces the number of Read / Write operations).
Putting all this into context – a single 7200RPM SATA drive with 1TB of Storage can potentially provide around 75 – 80 IOPS – this combined with the optimizations above puts JBODs in as an alternative storage option if your budget is limited.
Ok, but what about the missing resilience?
This is the second feature that I alluded to above – Database Availability Groups (DAG).
It is important to point out at this stage that JBODs should not be considered if you do not plan to use DAG.
Microsoft does not support Exchange 2010 deployed on JBOD storage architecture without DAG.
So how do JBODs work with DAG?
Pretty much the same as any other supported disk sub-system – although there is some specific guidance that you must follow before deploying your Exchange 2010 environment which is as follows:
- Minimum of 3 Mailbox Servers
- 3 Database Copies per Database
- Each Database is placed on a dedicated JBOD for both the Database and Transaction Log
A simple example of the above recommendation is depicted in figure 2 below as a 3 node, 3 databases, 3 DB copy setup within a single site:
Figure 2: Simple DAG to JBOD example
You should also bear in mind that you should not consider JBODs on the SAME physical hosts and then Virtualize the Exchange DAG instances on that host – this would defeat the purpose of DAG – you need to be looking at separate physical machines (or if you are virtualizing, then each host must have its own separate JBOD configuration).
Given the caveat above (the recommendation for separation) – this does beg the question of if you need to separate out onto different machines in order to use JBODS with Exchange 2010 – how much of a saving are you actually making?
If you need to purchase separate physical hardware and license it just to save money on your storage by using JBOD – how does that compare with just investing in more traditional configurations such as RAID on DAS, SAN etc.
You need to also consider that DAG is pretty much a pre-requisite for using JBOD storage architecture, this of course means that you will need the failover clustering element of Windows 2008 – which in turn means Enterprise Edition licensing for Windows – therefore more cost.
What this all really means is that when architecting your Exchange 2010 environment and are considering using JBODs – you will need to balance any choice that you make on available funds, benefits gained and how you would like your organization to look.
For example; if you are a small organization with less than 250 users and a single site I would suggest that JBOD and DAG is not for you – however if you are a medium to large sized organization (250 – 5000) users with multiple sites you may wish to leverage a “tiered” storage architecture which leverages JBOD at tier 2 or 3 – this is depicted in figure 3 as an example:
Figure 3: Tiered DAG with JBOD
With this type of deployment you are saving money at tiers 2 and 3 as you reducing your storage costs and spreading the resilience. You will notice that in the example above there is only one JBOD Exchange server, however, this would be a supported configuration as there are still 3 copies of the Database(s) which are resident on the JBODs.
Summary
This article has taken you through the principles of JBOD and how the technology can be used in conjunction with Exchange 2010. It has provided both “Pro’s and Con’s” – and given some very simple architectural overviews of possible usage.
