[Gluster-users] RAID on GLUSTER node

Pranith Kumar Karampuri pkarampu at redhat.com
Tue Jan 12 08:46:35 UTC 2016



On 01/12/2016 01:26 PM, Pawan Devaiah wrote:
> Thanks for your response Pranith and Mathieu,
>
> Pranith: To answer your question, I am planning to use this storage 
> for two main workloads.
>
> 1. As a shared storage for VMs.
EC as it is today is not good for this.
> 2. As a NFS Storage for files.
If the above is for storing archive data. EC is nice here.

Pranith
>
> We are a online backup company so we store few hundred Terra bytes of 
> data.
>
>
> Mathieu: I appreciate your concern, however as a system admins 
> sometimes we get paranoid and try to control everything under the Sun.
> I know I can only control what I can.
>
> Having said that, No, I have pair of servers to start with so at the 
> moment I am just evaluating and preparing for proof of concept, after 
> which I am going to propose to my management, if they are happy then 
> we will proceed further.
>
> Regards,
> Dev
>
> On Tue, Jan 12, 2016 at 7:30 PM, Mathieu Chateau 
> <mathieu.chateau at lotp.fr <mailto:mathieu.chateau at lotp.fr>> wrote:
>
>     Hello,
>
>     For any system, 36 disks raise disk failure probability. Do you
>     plan GlusterFS with only one server?
>
>     You should think about failure at each level and be prepared for it:
>
>       * Motherboard failure (full server down)
>       * Disks failure
>       * Network cable failure
>       * File system corruption (time needed for fsck)
>       * File/folder removed by mistake (backup)
>
>     Using or not raid depend on your answer on these questions and
>     performance needed.
>     It also depend how "good" is raid controller in your server, like
>     if it has battery and 1GB of cache.
>
>     When many disks are bought at same time (1 order, serial number
>     close to each other), they may fail in near time to each other (if
>     something bad happened in manufactory).
>     I already saw like 3 disks failing in few days.
>
>     just my 2 cents,
>
>
>
>     Cordialement,
>     Mathieu CHATEAU
>     http://www.lotp.fr
>
>     2016-01-12 4:36 GMT+01:00 Pranith Kumar Karampuri
>     <pkarampu at redhat.com <mailto:pkarampu at redhat.com>>:
>
>
>
>         On 01/12/2016 04:34 AM, Pawan Devaiah wrote:
>>         Hi All,
>>
>>         We have a fairly powerful server sitting at office with 128
>>         Gig RAM and 36 X 4 TB drives. I am planning to utilize this
>>         server as a backend storage with GlusterFS on it.
>>         I have been doing lot of reading on Glusterfs, but I do not
>>         see any definite recommendation on having RAID on GLUSTER nodes.
>>         Is it recommended to have RAID on GLUSTER nodes specially for
>>         the bricks?
>>         If Yes, is it not contrary to the latest Erasure code
>>         implemented in Gluster or is it still not ready for
>>         production environment?
>>         I am happy to implement RAID but my two main concern are
>>         1. I want to make most of the disk space available.
>>         2. I am also concerned about the rebuild time after disk
>>         failure on the RAID.
>         What is the workload you have?
>
>         We found in our testing that random read/write workload with
>         Erasure coded volumes is not as good as we get with
>         replication. There are enhancements in progress at the moment
>         to address these things which we are yet to merge and re-test.
>
>         Pranith
>>
>>         Thanks
>>         Dev
>>
>>
>>
>>
>>         _______________________________________________
>>         Gluster-users mailing list
>>         Gluster-users at gluster.org  <mailto:Gluster-users at gluster.org>
>>         http://www.gluster.org/mailman/listinfo/gluster-users
>
>
>         _______________________________________________
>         Gluster-users mailing list
>         Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>         http://www.gluster.org/mailman/listinfo/gluster-users
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160112/e84b920c/attachment.html>


More information about the Gluster-users mailing list