|
Home > Archive > Data Storage > April 2006 > What is the difference between a JBOD and a SAN?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What is the difference between a JBOD and a SAN?
|
|
| JRoughgarden 2006-02-09, 5:48 pm |
| We have an application that is experiencing I/O contention,
particularly in tempdb but also in two other databases. The data is
stored on mirrored PowerVault 220's, each with 10 of 14 possible disks.
The PowerVaults are JBOD devices, not true SANs. The current config has
four separate groups of physical drives assigned to distinct logical
drives for log files, tempdb, and the two app dbs. This means, for
example, that tempdb resides on one mirrored drive. The standard advice
when faced with disk contention is to add spindles if possible. With 4
empty slots, we would presumably assign the new physical disks to the
most stressed db, e.g. tempdb.
An alternative arrangement would be to combine all the physical drives
into one logical drive, and put all the files, log and data, onto the
single logical drive. The hope for this configuration is that the
PowerVault would automagically distribute the data among the drives
such that all drives were in use, all spindles reading and writing at
maximum capacity when necessary. It is my understanding that
full-featured SANs, like NetApps and EMC models, do this. My question
is whether this configuration is best for the PowerVault, as well. Or
is this the essential difference between JBOD and a true SAN?
Has anyone tried both arrangements?
Advice is much appreciated.
| |
| Globe Treader 2006-02-20, 2:46 am |
| >>An alternative arrangement would be to combine all the physical drives[vbcol=seagreen]
NOT Recommended. Databases like to have their logs and data on
different spindles to avoid contention. By putting everything on one,
your database cannot write to logs and data files in parallel.
Make atleast two logical drives and let different drives be in each.
RAID 1/0 or atleast RAID 1 is recommended for log files and RAID 5 is
recommended for data files.
Kiran Ghag
EMC=B2 Proven CLARiiON Solutions Implementation Specialist
---------------------------------------------------------------------------=
-----
"Experience is a wonderful thing. It enables you to
recognize a mistake when you make it again."
| |
| Maxim S. Shatskih 2006-02-20, 7:46 am |
| >RAID 1/0 or atleast RAID 1 is recommended for log files and RAID 5 is
>recommended for data files.
RAID 5 is slow on write. It is a good idea only to save money on spindles. If
your bugdet is good enough to disk drive cost being not an issue - then use
RAID 10 instead.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
| |
| jeffls@sbcglobal.net 2006-02-21, 5:47 pm |
| There is no "difference" between JBOD and SAN.
JBOD is a disk configuration (single spindles per LUN vs RAID which is
mulitple spindles per LUN, where a LUN is a "device" presented to a
host).
SAN is a storage interconnect generally based on Fibre (though this is
expanding somewhat). SCSI, PATA, SATA are also storage interconnects.
You can have JBOD on storage connected via any one of these
interconnects, including a SAN. For example, on an HP MSA SAN-based
array, you can present each disk as a separate LUN to the hosts - this
is JBOD.
Or you can bind them into RAIDsets and present a single LUN.
Database - as with many I/O-based applications - performance issues
are going to be affected by the number of actual disk drives
(spindles) among which the I/O load is balanced.
NOTE: The fastest I/O is the one that doesn't (need to) happen....
thus, with many databases, if you increase the number of "buffers"
(memory used) for read access, the application may be able to "hit"
memory instead of going to the disk drive. This is, of course,
heavily dependent on the application's characteristics, including
things like locality of READs, and the READ:WRITE ratio.
In general, though, if your disks are a bottleneck, adding more disks
and/or disk controllers to the configuration, and balancing the
workload over them, is the way to resolve these issues.
Do not consider mixing the data files and logs on the same LUNs...
this basically puts disaster recovery options at high risk for
failure.
Likewise, having a RAIDset with disks in the same interconnect (e.g.,
multiple drives on the same SCSI bus) can be equally disasterous.
On 9 Feb 2006 14:45:08 -0800, "JRoughgarden"
<jroughgarden@stanfordalumni.org> wrote:
>We have an application that is experiencing I/O contention,
>particularly in tempdb but also in two other databases. The data is
>stored on mirrored PowerVault 220's, each with 10 of 14 possible disks.
>The PowerVaults are JBOD devices, not true SANs. The current config has
>four separate groups of physical drives assigned to distinct logical
>drives for log files, tempdb, and the two app dbs. This means, for
>example, that tempdb resides on one mirrored drive. The standard advice
>when faced with disk contention is to add spindles if possible. With 4
>empty slots, we would presumably assign the new physical disks to the
>most stressed db, e.g. tempdb.
>
>An alternative arrangement would be to combine all the physical drives
>into one logical drive, and put all the files, log and data, onto the
>single logical drive. The hope for this configuration is that the
>PowerVault would automagically distribute the data among the drives
>such that all drives were in use, all spindles reading and writing at
>maximum capacity when necessary. It is my understanding that
>full-featured SANs, like NetApps and EMC models, do this. My question
>is whether this configuration is best for the PowerVault, as well. Or
>is this the essential difference between JBOD and a true SAN?
>
>Has anyone tried both arrangements?
>
>Advice is much appreciated.
| |
|
| True enough. I usually like to determine the database characteristics before
deciding on a raid level for the data. =It is important to know the
read/write ratio, IOPS and transactions per second. R1 is fine for the logs
and they should indeed be kept separate. R5 is 8 out of 10 times fine for
the data. If you have a 70% read and a 30% write ratio, R5 will be OK.
You mentioned that there was disk contention. I am not surprised if you have
four databases on this disk subsystem. It is possible depending on each of
the databases characteristics but I sure would be careful where I placed
what information!
Rick
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:dtcd26$o1f$1@gavrilo.mtu.ru...
>
> RAID 5 is slow on write. It is a good idea only to save money on spindles.
> If
> your bugdet is good enough to disk drive cost being not an issue - then
> use
> RAID 10 instead.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
|
|
|
|
|