[Gluster-users] State of Gluster project

[Strahil Nikolov]

На 21 юни 2020 г. 10:53:10 GMT+03:00, Gionatan Danti <g.danti at assyoma.it> написа:
>Il 2020-06-21 01:26 Strahil Nikolov ha scritto:
>> The efforts are  far less than reconstructing the disk of a VM from
>> CEPH. In gluster , just run a find on the brick  searching for the
>> name of the VM disk and you will find the VM_IMAGE.xyz  (where xyz is
>> just a number)  and then concatenate the  list into a single file.
>
>Sure, but it is somewhat impractical with a 6 TB fileserver image and 
>500 users screaming for their files ;)
>And I fully expect to be the reconstruction much easier than Ceph but, 
>from what I read, Ceph is less likely to broke in the first place. But
>I 
>admit I never seriously run a Ceph cluster, so maybe it is more fragile
>
>than I expect.

With  every community project ,  you are in the position  of a Betta  Tester  - no matter Fedora,  Gluster  or CEPH. So far  ,  I had  issues with upstream  projects only diring and immediately after patching  - but this is properly mitigated  with a  reasonable patching strategy (patch  test environment and several months later  patch prod with the same repos).
Enterprise  Linux breaks (and alot) having 10-times more  users and use  cases,  so you cannot expect to start to use  Gluster  and assume that a  free  peoject won't break at all.
Our part in this project is to help the devs to create a test case for our workload ,  so  regressions will be reduced to minimum.

In the past 2  years,  we  got 2  major  issues with VMware VSAN and 1  major  issue  with  a Enterprise Storage cluster (both solutions are quite  expensive)  - so  I always recommend proper  testing  of your  software .


>> That's  true,  but  you  could  also  use  NFS Ganesha,  which  is
>> more  performant  than FUSE and also as  reliable  as  it.
>
>From this very list I read about many users with various problems when 
>using NFS Ganesha. Is that a wrong impression?

From my observations,  almost nobody  is complaining about Ganesha in the mailing list -> 50% are  having issues  with geo replication,20%  are  having issues with small file performance and the rest have issues with very old version of gluster  -> v5 or older.

>> It's  not so hard to  do it  -  just  use  either  'reset-brick' or
>> 'replace-brick' .
>
>Sure - the command itself is simple enough. The point it that each 
>reconstruction is quite more "riskier" than a simple RAID 
>reconstruction. Do you run a full Gluster SDS, skipping RAID? How do
>you 
>found this setup?

I  can't say that a  replace-brick  on a 'replica  3' volume is more  riskier  than a rebuild  of a raid,  but I have noticed that nobody is  following Red Hat's  guide  to use  either:
-  a  Raid6  of 12  Disks (2-3  TB  big)
-  a Raid10  of  12  Disks (2-3  TB big)
-  JBOD disks in 'replica  3' mode (i'm not sure about the size  RH recommends,  most probably 2-3 TB)
 So far,  I didn' have the opportunity to run on JBODs.


>Thanks.