?? 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.