# To Raid or not to Raid **URL:** \ **Category:** Elasticsearch\ **Created:** [December 12, 2014, 12:32pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234 "2014-12-12T12:32:53Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![elvarb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elvarb/32/44840_2.png) [@elvarb](https://discuss.elastic.co/u/elvarb)\ **Post date:** [December 12, 2014, 12:32pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/1 "2014-12-12T12:32:53Z")
When running Elasticsearch on physical hardware you have it create replicas to make sure no node is a single point of failure. From everyone's experiance should I use Hardware Raid as well, or is it not needed? -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![nik9000](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nik9000/32/44947_2.png) [@nik9000](https://discuss.elastic.co/u/nik9000)\ **Post date:** [December 12, 2014, 1:30pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/2 "2014-12-12T13:30:06Z")
Striping raid is viable for 2 or 3 disks because of the redundancy. Software raid works fine for me. Hardware raid enables battery backed write behind but I don't know how important that is with ssds. Either way, we go 2xSSDs per server with os in mirrored raid and data striped. Depending on your data you may want spinning disks instead, then battery backed writes are probably a bigger win. On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > When running Elasticsearch on physical hardware you have it create > replicas to make sure no node is a single point of failure. From everyone's > experiance should I use Hardware Raid as well, or is it not needed? > > -- > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft\_BAT4wa6dZ%2Bfrupg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft_BAT4wa6dZ%2Bfrupg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![elvarb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elvarb/32/44840_2.png) [@elvarb](https://discuss.elastic.co/u/elvarb)\ **Post date:** [December 12, 2014, 3:13pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/3 "2014-12-12T15:13:02Z")
This would be for log storage, plan is to go with HDD's for the long term storage and SSD's for short term storage. Total storage will be maybe 8tb total, using replica's would bring that to 16tb and if using raid1 or raid10 would bring total raw storage up to 32tb On Friday, December 12, 2014 1:30:32 PM UTC, Nikolas Everett wrote: > Striping raid is viable for 2 or 3 disks because of the redundancy. > Software raid works fine for me. Hardware raid enables battery backed write > behind but I don't know how important that is with ssds. Either way, we go > 2xSSDs per server with os in mirrored raid and data striped. > > Depending on your data you may want spinning disks instead, then battery > backed writes are probably a bigger win. > On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" \<[elv...@gmail.com](mailto:elv...@gmail.com) > \\> wrote: > > > When running Elasticsearch on physical hardware you have it create > > replicas to make sure no node is a single point of failure. From everyone's > > experiance should I use Hardware Raid as well, or is it not needed? > > > > -- > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [December 12, 2014, 3:43pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/4 "2014-12-12T15:43:09Z")
If you can architect around the loss of a node and subsequent recovery, then I reckon it's worth testing the notion of not running RAID. On 12 December 2014 at 14:30, Nikolas Everett [nik9000@gmail.com](mailto:nik9000@gmail.com) wrote: > Striping raid is viable for 2 or 3 disks because of the redundancy. > Software raid works fine for me. Hardware raid enables battery backed write > behind but I don't know how important that is with ssds. Either way, we go > 2xSSDs per server with os in mirrored raid and data striped. > > Depending on your data you may want spinning disks instead, then battery > backed writes are probably a bigger win. > On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > > > When running Elasticsearch on physical hardware you have it create > > replicas to make sure no node is a single point of failure. From everyone's > > experiance should I use Hardware Raid as well, or is it not needed? > > > > -- > > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft\_BAT4wa6dZ%2Bfrupg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft_BAT4wa6dZ%2Bfrupg%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft\_BAT4wa6dZ%2Bfrupg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAPmjWd2k6KMPF%3Dw%3DzzAEg1bxCNp1Aa-7ft_BAT4wa6dZ%2Bfrupg%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X8pf%3DxopyPw9tGs\_GXDUZ25y7o\_b%2BU5KujXU%2BJJbN012w%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X8pf%3DxopyPw9tGs_GXDUZ25y7o_b%2BU5KujXU%2BJJbN012w%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [December 12, 2014, 4:00pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/5 "2014-12-12T16:00:38Z")
It's a risk thing, you need to be comfy with the risk of losing one disk and all that it entails. If you can mitigate that through a process and you are happy with the remaining risk, then 🙂 On 12 December 2014 at 16:13, Elvar Böðvarsson [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > This would be for log storage, plan is to go with HDD's for the long term > storage and SSD's for short term storage. Total storage will be maybe 8tb > total, using replica's would bring that to 16tb and if using raid1 or > raid10 would bring total raw storage up to 32tb > > On Friday, December 12, 2014 1:30:32 PM UTC, Nikolas Everett wrote: > > > Striping raid is viable for 2 or 3 disks because of the redundancy. > > Software raid works fine for me. Hardware raid enables battery backed write > > behind but I don't know how important that is with ssds. Either way, we go > > 2xSSDs per server with os in mirrored raid and data striped. > > > > Depending on your data you may want spinning disks instead, then battery > > backed writes are probably a bigger win. > > On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" [elv...@gmail.com](mailto:elv...@gmail.com) wrote: > > > > > When running Elasticsearch on physical hardware you have it create > > > replicas to make sure no node is a single point of failure. From everyone's > > > experiance should I use Hardware Raid as well, or is it not needed? > > > > > > -- > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea% > > > [40googlegroups.com](http://40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9\_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jackpark](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jackpark](https://discuss.elastic.co/u/jackpark)\ **Post date:** [December 12, 2014, 4:17pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/6 "2014-12-12T16:17:52Z")
I cannot put my finger on it, but I think I recall that someone in this group once said that ES is IO intensive, that RAID would slow things down, arguing in favor of redundant servers over RAID. Does that still make sense? On Fri, Dec 12, 2014 at 8:00 AM, Mark Walkom [markwalkom@gmail.com](mailto:markwalkom@gmail.com) wrote: > It's a risk thing, you need to be comfy with the risk of losing one disk > and all that it entails. > If you can mitigate that through a process and you are happy with the > remaining risk, then 🙂 > > On 12 December 2014 at 16:13, Elvar Böðvarsson [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > > > This would be for log storage, plan is to go with HDD's for the long term > > storage and SSD's for short term storage. Total storage will be maybe 8tb > > total, using replica's would bring that to 16tb and if using raid1 or > > raid10 would bring total raw storage up to 32tb > > > > On Friday, December 12, 2014 1:30:32 PM UTC, Nikolas Everett wrote: > > > > > Striping raid is viable for 2 or 3 disks because of the redundancy. > > > Software raid works fine for me. Hardware raid enables battery backed write > > > behind but I don't know how important that is with ssds. Either way, we go > > > 2xSSDs per server with os in mirrored raid and data striped. > > > > > > Depending on your data you may want spinning disks instead, then battery > > > backed writes are probably a bigger win. > > > On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" [elv...@gmail.com](mailto:elv...@gmail.com) wrote: > > > > > > > When running Elasticsearch on physical hardware you have it create > > > > replicas to make sure no node is a single point of failure. From everyone's > > > > experiance should I use Hardware Raid as well, or is it not needed? > > > > > > > > -- > > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea% > > > > [40googlegroups.com](http://40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > -- > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9\_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9\_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAH6s0fwLhZNmSQVJmOKY4WtL-d003J0\_%3DYamGh7i7uhT%3Df\_W6A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAH6s0fwLhZNmSQVJmOKY4WtL-d003J0_%3DYamGh7i7uhT%3Df_W6A%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![elvarb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elvarb/32/44840_2.png) [@elvarb](https://discuss.elastic.co/u/elvarb)\ **Post date:** [December 12, 2014, 6:28pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/7 "2014-12-12T18:28:51Z")
Just went through these slides > **[Scaling Elasticsearch; Washington DC Meetup](https://speakerdeck.com/bhaskarvk/scaling-elasticsearch-washington-dc-meetup)** > > Slides from my talk at Washington DC Elasticsearch meetup on Dec 11th 2014, about scaling Elasticsearch for production scale data. > > Event Details :- > http://www.meetup.com/Elasticsearch-Washington-DC/events/218806074/ > > Video of the Talk... First of all, thats one HUGE cluster Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, maybe then to be safe go with 2x replicas, goes well with having 3x nodes On Friday, December 12, 2014 4:18:01 PM UTC, Jack Park wrote: > I cannot put my finger on it, but I think I recall that someone in this > group once said that ES is IO intensive, that RAID would slow things down, > arguing in favor of redundant servers over RAID. Does that still make sense? > > On Fri, Dec 12, 2014 at 8:00 AM, Mark Walkom \<[markw...@gmail.com](mailto:markw...@gmail.com) > \\> wrote: > > > It's a risk thing, you need to be comfy with the risk of losing one disk > > and all that it entails. > > If you can mitigate that through a process and you are happy with the > > remaining risk, then 🙂 > > > > On 12 December 2014 at 16:13, Elvar Böðvarsson \<[elv...@gmail.com](mailto:elv...@gmail.com) > > \\> wrote: > > > > > This would be for log storage, plan is to go with HDD's for the long > > > term storage and SSD's for short term storage. Total storage will be maybe > > > 8tb total, using replica's would bring that to 16tb and if using raid1 or > > > raid10 would bring total raw storage up to 32tb > > > > > > On Friday, December 12, 2014 1:30:32 PM UTC, Nikolas Everett wrote: > > > > > > > Striping raid is viable for 2 or 3 disks because of the redundancy. > > > > Software raid works fine for me. Hardware raid enables battery backed write > > > > behind but I don't know how important that is with ssds. Either way, we go > > > > 2xSSDs per server with os in mirrored raid and data striped. > > > > > > > > Depending on your data you may want spinning disks instead, then > > > > battery backed writes are probably a bigger win. > > > > On Dec 12, 2014 7:32 AM, "Elvar Böðvarsson" [elv...@gmail.com](mailto:elv...@gmail.com) wrote: > > > > > > > > > When running Elasticsearch on physical hardware you have it create > > > > > replicas to make sure no node is a single point of failure. From everyone's > > > > > experiance should I use Hardware Raid as well, or is it not needed? > > > > > > > > > > -- > > > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea% > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4827efb1-b5cf-4407-97ef-f6c4c3029cea%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > -- > > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/13b36ab6-7fb6-4f6f-b11d-79069aed74ad%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9\_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9\_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X9_ULd9j7jFVJaMYvLz3NNwYsqCAwHsfUxkxCwg1oV3-A%40mail.gmail.com?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/02040a16-9718-4fc8-be28-4ff781de5c40%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/02040a16-9718-4fc8-be28-4ff781de5c40%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 13, 2014, 3:48pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/8 "2014-12-13T15:48:48Z")
The statement is related to performance and I can't agree with it. You can easily build a RAID 0 system which has massive I/O throughput performance and is superior to JBOD, because RAID striping does not slow things down, it is as always as much as fast than a single drive and in most RAID levels it is much faster. In the past, RAID was invented for mirroring cheap and error-prone spindle disk arrays, while mirrors increase costs but decrease fault probability. With Elasticsearch, the decision is if you still want to handle disk faults by drive redundancy (RAID) and all other hardware faults like power outages by server downtime. This is just a matter of organization and of cost. I would suggest from my experience: take control over your complete hardware setup, equip your systems with expensive SAS2 (or even better) controllers with RAID 0 to reduce cost and maximize performance, and handle all kind of hardware faults by server downtime, because ES replica level \> 0 allows that. There is also a simplification of SAN/NAS in the statement but that is a different discussion. Never use SAN/NAS for ES local gateway. Jörg On Fri, Dec 12, 2014 at 7:28 PM, Elvar Böðvarsson [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, > maybe then to be safe go with 2x replicas, goes well with having 3x nodes -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoE9g%2BJFNQdZYH1%3D3pz-b%2Bx0j9cc3M5dLV9rB4gL\_SWvWA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoE9g%2BJFNQdZYH1%3D3pz-b%2Bx0j9cc3M5dLV9rB4gL_SWvWA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![elvarb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elvarb/32/44840_2.png) [@elvarb](https://discuss.elastic.co/u/elvarb)\ **Post date:** [December 15, 2014, 10:45am UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/9 "2014-12-15T10:45:21Z")
If you have a node that has 4x disks as JBOD and you configure Elasticsearch to use all of them, so it will write to as like its Raid0. How does Elasticsearch handle a failure of one disk? Will the whole node go down or will Elasticsearch continue to function just with lower total available storage? (and then recreate the shards that went down) On Saturday, December 13, 2014 3:48:55 PM UTC, Jörg Prante wrote: > The statement is related to performance and I can't agree with it. You can > easily build a RAID 0 system which has massive I/O throughput performance > and is superior to JBOD, because RAID striping does not slow things down, > it is as always as much as fast than a single drive and in most RAID levels > it is much faster. > > In the past, RAID was invented for mirroring cheap and error-prone spindle > disk arrays, while mirrors increase costs but decrease fault probability. > > With Elasticsearch, the decision is if you still want to handle disk > faults by drive redundancy (RAID) and all other hardware faults like power > outages by server downtime. This is just a matter of organization and of > cost. I would suggest from my experience: take control over your complete > hardware setup, equip your systems with expensive SAS2 (or even better) > controllers with RAID 0 to reduce cost and maximize performance, and handle > all kind of hardware faults by server downtime, because ES replica level \> > 0 allows that. > > There is also a simplification of SAN/NAS in the statement but that is a > different discussion. Never use SAN/NAS for ES local gateway. > > Jörg > > On Fri, Dec 12, 2014 at 7:28 PM, Elvar Böðvarsson \<[elv...@gmail.com](mailto:elv...@gmail.com) > \\> wrote: > > > Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, > > maybe then to be safe go with 2x replicas, goes well with having 3x nodes -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [December 15, 2014, 12:04pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/10 "2014-12-15T12:04:44Z")
Unfortunately you lose all data on the node as ES will stripe segments across the disks/mount points. On 15 December 2014 at 11:45, Elvar Böðvarsson [elvarb@gmail.com](mailto:elvarb@gmail.com) wrote: > If you have a node that has 4x disks as JBOD and you configure > Elasticsearch to use all of them, so it will write to as like its Raid0. > > How does Elasticsearch handle a failure of one disk? > Will the whole node go down or will Elasticsearch continue to function > just with lower total available storage? (and then recreate the shards that > went down) > > On Saturday, December 13, 2014 3:48:55 PM UTC, Jörg Prante wrote: > > > The statement is related to performance and I can't agree with it. You > > can easily build a RAID 0 system which has massive I/O throughput > > performance and is superior to JBOD, because RAID striping does not slow > > things down, it is as always as much as fast than a single drive and in > > most RAID levels it is much faster. > > > > In the past, RAID was invented for mirroring cheap and error-prone > > spindle disk arrays, while mirrors increase costs but decrease fault > > probability. > > > > With Elasticsearch, the decision is if you still want to handle disk > > faults by drive redundancy (RAID) and all other hardware faults like power > > outages by server downtime. This is just a matter of organization and of > > cost. I would suggest from my experience: take control over your complete > > hardware setup, equip your systems with expensive SAS2 (or even better) > > controllers with RAID 0 to reduce cost and maximize performance, and handle > > all kind of hardware faults by server downtime, because ES replica level \> > > 0 allows that. > > > > There is also a simplification of SAN/NAS in the statement but that is a > > different discussion. Never use SAN/NAS for ES local gateway. > > > > Jörg > > > > On Fri, Dec 12, 2014 at 7:28 PM, Elvar Böðvarsson [elv...@gmail.com](mailto:elv...@gmail.com) > > wrote: > > > > > Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, > > > maybe then to be safe go with 2x replicas, goes well with having 3x nodes > > > > > > -- > > > 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](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEYi1X\_fAiiMnXq5dfGJBuTFxFGt182hVVv\_qYKYiqC6%2BQfhUQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X_fAiiMnXq5dfGJBuTFxFGt182hVVv_qYKYiqC6%2BQfhUQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![elvarb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/elvarb/32/44840_2.png) [@elvarb](https://discuss.elastic.co/u/elvarb)\ **Post date:** [December 15, 2014, 1:54pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/11 "2014-12-15T13:54:16Z")
That is quite scary Lets say I have 3x nodes each with 4x disks, a total of 12x disks. Two disk fails would mean a data loss if its set to 1 replicas, with 2 replicas it would mean no data loss but with the cluster availability of n+1 nodes it would take down the whole cluster if one disk failsin two hosts. Maybe It would be smart to split the elasticsearch processes or run two VM's per host. [https://codeascraft.com/2014/12/04/juggling-multiple-elasticsearch-instances-on-a-single-host/](https://codeascraft.com/2014/12/04/juggling-multiple-elasticsearch-instances-on-a-single-host/) If I did it like this then each process would have access to 2x disks meaning if one disk fails only two disks will be unavailable to the cluster instead of four. On Monday, December 15, 2014 12:05:18 PM UTC, Mark Walkom wrote: > Unfortunately you lose all data on the node as ES will stripe segments > across the disks/mount points. > > On 15 December 2014 at 11:45, Elvar Böðvarsson \<[elv...@gmail.com](mailto:elv...@gmail.com) > \\> wrote: > > > If you have a node that has 4x disks as JBOD and you configure > > Elasticsearch to use all of them, so it will write to as like its Raid0. > > > > How does Elasticsearch handle a failure of one disk? > > Will the whole node go down or will Elasticsearch continue to function > > just with lower total available storage? (and then recreate the shards that > > went down) > > > > On Saturday, December 13, 2014 3:48:55 PM UTC, Jörg Prante wrote: > > > > > The statement is related to performance and I can't agree with it. You > > > can easily build a RAID 0 system which has massive I/O throughput > > > performance and is superior to JBOD, because RAID striping does not slow > > > things down, it is as always as much as fast than a single drive and in > > > most RAID levels it is much faster. > > > > > > In the past, RAID was invented for mirroring cheap and error-prone > > > spindle disk arrays, while mirrors increase costs but decrease fault > > > probability. > > > > > > With Elasticsearch, the decision is if you still want to handle disk > > > faults by drive redundancy (RAID) and all other hardware faults like power > > > outages by server downtime. This is just a matter of organization and of > > > cost. I would suggest from my experience: take control over your complete > > > hardware setup, equip your systems with expensive SAS2 (or even better) > > > controllers with RAID 0 to reduce cost and maximize performance, and handle > > > all kind of hardware faults by server downtime, because ES replica level \> > > > 0 allows that. > > > > > > There is also a simplification of SAN/NAS in the statement but that is a > > > different discussion. Never use SAN/NAS for ES local gateway. > > > > > > Jörg > > > > > > On Fri, Dec 12, 2014 at 7:28 PM, Elvar Böðvarsson [elv...@gmail.com](mailto:elv...@gmail.com) > > > wrote: > > > > > > > Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, > > > > maybe then to be safe go with 2x replicas, goes well with having 3x nodes > > > > > > > > -- > > > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/fad86579-2072-438d-94da-80219e200b67%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7e2260da-7082-4957-8302-57bf2a912b7b%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7e2260da-7082-4957-8302-57bf2a912b7b%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Bhaskar\_Karambelkar](https://avatars.discourse-cdn.com/v4/letter/b/3ab097/32.png) [@Bhaskar\_Karambelkar](https://discuss.elastic.co/u/Bhaskar_Karambelkar)\ **Post date:** [January 10, 2015, 5:23pm UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/12 "2015-01-10T17:23:07Z")
Hi Jörg, I'm the author of those slides, and that statement, even when taken out of context starts with "Prefer", I don't think I need to explain what prefer means, but just in case ... Using JBOD will be your safest bet as opposed to using something like RAID / SAN/ NAS unless you really know what you're doing. I never said DON'T EVER use RAID or even SAN|NAS, just "prefer" JBOD. I do agree with your assessment of RAID 0 below, but do remember that, that one statement was taken out of context, for full context I suggest you go through the whole slide deck and better yet the whole talk whose video was posted on elasticsearch site. I even made a point about some of my recommendations not being applicable to cloud deployments etc. As to your point about simplification of NAS|SAN, that's the whole point of presenting to a wide audience, one simplifies things such that they can be applied to majority of the cases, and not concentrate on esoteric deployments :). As to local gateway, that's the only one ES recommends now, the shared FS, HDFS, S3 gateways were long deprecated. FWIW I fully agree with your statement on taking control over complete hardware setup, heck there's a full slide in there dedicated to this point, titled 'Know your platform'. At the end of the day, there's no single silver bullet, everyone will have to evaluate what works best for their situation, what worked for us may not work well for others. It would be indeed very naive to take my slides as laws, they are more or less pointers worth exploring. Some may work for you some won't. They worked fairly well for us. I might sound a bit defensive here, but hey we did build that cluster and we're nearing a Trillion documents in it, so I guess we must be doing something right :). Bhaskar On Saturday, December 13, 2014 at 10:48:55 AM UTC-5, Jörg Prante wrote: > The statement is related to performance and I can't agree with it. You can > easily build a RAID 0 system which has massive I/O throughput performance > and is superior to JBOD, because RAID striping does not slow things down, > it is as always as much as fast than a single drive and in most RAID levels > it is much faster. > > In the past, RAID was invented for mirroring cheap and error-prone spindle > disk arrays, while mirrors increase costs but decrease fault probability. > > With Elasticsearch, the decision is if you still want to handle disk > faults by drive redundancy (RAID) and all other hardware faults like power > outages by server downtime. This is just a matter of organization and of > cost. I would suggest from my experience: take control over your complete > hardware setup, equip your systems with expensive SAS2 (or even better) > controllers with RAID 0 to reduce cost and maximize performance, and handle > all kind of hardware faults by server downtime, because ES replica level \> > 0 allows that. > > There is also a simplification of SAN/NAS in the statement but that is a > different discussion. Never use SAN/NAS for ES local gateway. > > Jörg > > On Fri, Dec 12, 2014 at 7:28 PM, Elvar Böðvarsson \<[elv...@gmail.com](mailto:elv...@gmail.com) > \\> wrote: > > > Second, "Prefer JBODs for data disks over RAID, SAN/NAS", would be ok, > > maybe then to be safe go with 2x replicas, goes well with having 3x nodes -- 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](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/d0fa5e9c-2658-4fef-a9ad-ea83873a8f28%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/d0fa5e9c-2658-4fef-a9ad-ea83873a8f28%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:39am UTC](https://discuss.elastic.co/t/to-raid-or-not-to-raid/21234/13 "2017-07-06T00:39:44Z")