Elasticsearch has no deeper knowledge of the disk subsystem installed.
Currently it relies on Java 6 JVM methods and these largely ignore how the
operating system deals with disk and drive resources.
Because of this, Elasticsearch is clueless about disk performance and disk
failures. It will continue as long as the OS allows access to disks. There
is no automatic detection and repair built in ES.
If you encounter disk failures, you may be confronted with
-
high I/O load during automatic RAID rebuild, which may be not intended,
because a single failure can bog down the whole cluster
-
read-only filesystems - you may notice massive write IOExceptions in the
ES log or stalled ES JVMs
-
sudden reboots, depending on BIOS / OS fatal recovery strategy
-
stalled / locked-up / unavailable machines if the damage is exceptional
severe
If you demand a resilient system with unattended recovery, put some spare
drives into your RAID 1 (or 10), and trade failsafety for performance.
RAID5 is slow with writes, it is only interesting if you don't care for
maximum performance but for maximum space instead.
If you are ready to accept disk failures with putting down a whole machine
to fix them, you can go for RAID 0 which is supported by hardware for best
I/O performance (striped reads and writes in hardware). Add more replica
level in case you want to lower the risk of multiple node failures.
Common use pattern with JBOD is SW RAID with Linux mdadm and a single drive
in LVM. I do not prefer this configuration, because if a disk fails, you
may not be able to recover the SW RAID, no matter what RAID level. It's
easy to lose super blocks while wrestling with file system repair tools.
If you do not use SW RAID, you could use ES path striping across (JBOD)
partitions, but there are some shortcomings compared to RAID. Beside
lacking failsafety, it does not guarantuee to balance the disk space and
the disk I/O load evenly.
Jörg
On Wed, Jul 31, 2013 at 9:27 AM, baytech samir.mukadam@gmail.com wrote:
Currently don't have extreme through put requirements. Planning for a few
data nodes for indices. Since elasticsearch already allows for replicas -
what is the recommended RAID with SAS disks or SATA3 JBOD disks.
Backups will be stored separately offsite.
RAID with SAS would provide higher reliability and potentially higher read
performance but lower overall capacity per node
JBOD with Sata3 would give larger capacity per node, rely on elasticsearch
replication and offsite backups.
If one disk goes bad - RAID would rebuild on replacement disk
Not sure if one of the JBOD disks go bad if elasticsearch would rebuild
all the shards/replicas on entire node or just that disk. Basically how
would elasticsearch handle recovery if one of the disk goes bad.
Thanks
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.