similar to: State of the gluster project

Hi. I'm also migrating to BeeGFS and CephFS (depending on usage). What I liked most about Gluster was that files were easily recoverable from bricks even in case of disaster and that it said it supported RDMA. But I soon found that RDMA was being phased out, and I always find entries that are not healing after a couple months of (not really heavy) use, directories that can't be

Hi Diego, I have had a look at BeeGFS and is seems more similar to ceph then to gluster. It requires extra management nodes similar to ceph, right? Second of all there are no snapshots in BeeGFS, as I understand it. I know ceph has snapshots so for us this seems a better alternative. What is your experience of ceph? I am sorry to hear about your problems with gluster, from my experience we had

Hi, Red Hat Gluster Storage is EOL, Red Hat moved Gluster devs to other projects, so Gluster doesn't get much attention. From my experience, it has deteriorated since about version 9.0, and we're migrating to alternatives. /Z On Fri, 27 Oct 2023 at 10:29, Marcus Peders?n <marcus.pedersen at slu.se> wrote: > Hi all, > I just have a general thought about the gluster >

Well, After IBM acquisition, RH discontinued their support in?many projects including?GlusterFS (certification exams were removed, payed product went EOL, etc). The only way to get it back on track is with a sponsor company that haves the capability to drive it.Kadalu is relying on GlusterFS but they are not as big as Red Hat and based on one of the previous e-mails they will need sponsorship to

Maybe a bit OT... I'm no expert on either, but the concepts are quite similar. Both require "extra" nodes (metadata and monitor), but those can be virtual machines or you can host the services on OSD machines. We don't use snapshots, so I can't comment on that. My experience with Ceph is limited to having it working on Proxmox. No experience yet with CephFS. BeeGFS is

I don't think it's worth it for anyone. It's a dead project since about 9.0, if not earlier. It's time to embrace the truth and move on. /Z On Sat, 28 Oct 2023 at 11:21, Strahil Nikolov <hunter86_bg at yahoo.com> wrote: > Well, > > After IBM acquisition, RH discontinued their support in many projects > including GlusterFS (certification exams were removed,

Hi Xavi, Copy the same info file worked well and the gluster 11 arbiter is now up and running and all the nodes are communication the way they should. Just another note on something I discovered on my virt machines. All the three nodes has been upgarded to 11.0 and are working. If I run: gluster volume get all cluster.op-version I get: Option Value ------

Hi Kotresh, Yes, all nodes have the same version 4.1.1 both master and slave. All glusterd are crashing on the master side. Will send logs tonight. Thanks, Marcus ################ Marcus Peders?n Systemadministrator Interbull Centre ################ Sent from my phone ################ Den 13 juli 2018 11:28 skrev Kotresh Hiremath Ravishankar <khiremat at redhat.com>: Hi Marcus, Is the

It is very unfortunate that Gluster is not maintained. From Kadalu Technologies, we are trying to set up a small team dedicated to maintain GlusterFS for the next three years. This will be only possible if we get funding from community and companies. The details about the proposal is here?https://kadalu.tech/gluster/ About Kadalu Technologies: Kadalu Technologies was started in 2019 by a few

Hi again Xavi, I did some more testing on my virt machines with same setup: Number of Bricks: 1 x (2 + 1) = 3 If I do it the same way, I upgrade the arbiter first, I get the same behavior that the bricks do not start and the other nodes does not "see" the upgraded node. If I upgrade one of the other nodes (non arbiter) and restart glusterd on both the arbiter and the other the arbiter

On Sat, Oct 28, 2023 at 11:07:52PM +0300, Zakhar Kirpichenko wrote: > I don't think it's worth it for anyone. It's a dead project since about > 9.0, if not earlier. It's time to embrace the truth and move on. Which is shame because I choose GlusterFS for one of my storage clusters _specifically_ due to the ease of emergency data recovery (for purely replicated volumes) even

Hi Markus, It looks quite well documented, but please use?https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/sect-replacing_hosts?as 3.5?is the latest version for RHGS. If the OS disks are failing, I would have tried?moving the data disks to the new machine and transferring the gluster files in /etc and /var/lib to the new node. Any reason to reuse

I made a recusive diff on the upgraded arbiter. /var/lib/glusterd/vols/gds-common is the upgraded aribiter /home/marcus/gds-common is one of the other nodes still on gluster 10 diff -r /var/lib/glusterd/vols/gds-common/bricks/urd-gds-030:-urd-gds-gds-common /home/marcus/gds-common/bricks/urd-gds-030:-urd-gds-gds-common 5c5 < listen-port=60419 --- > listen-port=0 11c11 <

Big raid isn't great as bricks. If the array does fail, the larger brick means much longer heal times. My main question I ask when evaluating storage solutions is, "what happens when it fails?" With ceph, if the placement database is corrupted, all your data is lost (happened to my employer, once, losing 5PB of customer data). With Gluster, it's just files on disks, easily

Hi all, Over the years I have been using the same ports in my firewall for gluster 49152-49251 ( I know a bit too many ports but local network with limited access) Today I upgraded from version 9 to version 10 and it finally went well until I ran: gluster volume heal my-vol info summary I got the answer: Status: Transport endpoint is not connected I realized that glusterfsd was using 50000+

Hi all, We upgraded to gluster 11.1 and the OP version was fixed in this version, so I changed the OP version to 110000. Now we have some obscure, vague problem. Our users usually run 100+ processes with GNU parallel and now the execution time have increased close to the double. I can see that there are a couple of heals happening every now and then but this do not seem starange to me. Just to

Hi all, I have a problem with one of our gluster clusters. This is the setup: Volume Name: gds-common Type: Distributed-Replicate Volume ID: 42c9fa00-2d57-4a58-b5ae-c98c349cfcb6 Status: Started Snapshot Count: 26 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: urd-gds-031:/urd-gds/gds-common Brick2: urd-gds-032:/urd-gds/gds-common Brick3: urd-gds-030:/urd-gds/gds-common

Hi all, I am looking in to ceph and cephfs and in my head I am comparing with gluster. The way I have been running gluster over the years is either a replicated or replicated-distributed clusters. The small setup we have had has been a replicated cluster with one arbiter and two fileservers. These fileservers has been configured with RAID6 and that raid has been used as the brick. If disaster

Hi, we at forumZFD are currently experiencing problems similar to those mentioned here on the mailing list especially on the latest messages. Our gluster just doesn't heal all entries and "manual" healing is long and tedious. Entries accumulate in time and we have to do regular cleanups that take long and are risky.? Despite changing available options with different combinations

Hi all, I have setup a gluster system with geo replication (Centos 7, gluster 3.12). I have moved about 30 TB to the cluster. It seems that it goes realy show for the data to be syncronized to geo replication. It has been active for weeks and still just 9TB has ended up on the slave side. I pause the replication once a day and make a snapshot with a script. Does this slow things up? Is it possible