Convoy-gluster on specific storage hosts

@samouds is this forum topic the same as this github issue? https://github.com/rancher/rancher/issues/3339
Or are they separate concerns?

If they’re the same, would you mind if we continued the convo in the github issue? Its easier to track.

Yes of course, but i’m still stuck. and any help is very welcome :slight_smile:

I have my Gluster Cluster working now. So I have to test to add containers with volumes to see if it’s working. Do you have the convoy-gluster container active on all your hosts ?

Yes.

1 Like

And is appearing on your storage pool ?
I will try to test on mine later this week. And I give you my feedback.

Hi there,
I would be very interested in performance of your glusterfs.
So how fast can be a written file read again on the other hosts.

Thanks.

Do you use some benchmark solution ? So we can compare ?

Thanks @seb2411 !

Yes the volume appears in the storage pool and the problem still happens

Hi seb2411,
What I always do is the following:

$ dd if=/dev/zero of=test.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.4717 s, 730 MB/s

Sorry, it was a host on SSD that’s why it is so fast.
But in general you can see the throughput of storage very fast.

@ApolloDS ok, I will try this command.

@seb2411, just to be sure, don’t forget to delete test.dd after testing!
Otherwise you will have a big not used file lying around on your filesystem.

@samouds I was thinking about your Mysql problem. Did you try with Mysql 5.5 image. instead of the lastest ? I remember having a similar problem on my PC with a project on Docker. It was working perfectly with Mysql 5.5 but having similar troubles with the 5.6.

@ApolloDS So after runing my test :slightly_smiling:

On Vultr.com with the container on a Compute instance and the Gluster FS server on a local storage instance.

dd if=/dev/zero of=test.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 47.4925 s, 22.6 MB/s

@seb2411 it works now !

I did some little tests with wordpress/mysql to measure speed, and this is what I get :

  • Wordpress and mySQL with convoy : 10 sec to load the default homepage.
  • Wordpress with convoy, mySQL without : 10 sec too.
  • Wordpress without convoy, mySQL with convoy : 4 sec.
  • Wordpress and mySQL without convoy : 1 sec.

Why convoy is too slow … as I see it’s not advised to use it at production for now right ?

This is what the benchmark said :

`

dd if=/dev/zero of=test.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 155.418 s, 6.9 MB/s`

It’s too slow. how we can improve it ?

Definitely is not usable like that. What hosting are you using ? Mine seem a little bit better. I will investigate to see if we can have some solution to improve the performances.

I was thinking the limitation is possibly the network. All the VPS propose in general 100Mbps or 200Mbps.

If I’m not wrong :
200 Mbps = 25MB/S
so To send 1GO we need a minimum of 40s.

So we need a 4Gbps network to allow similar performances to a SSD.

Ok so checking on Vultr.com doc it seem the Private Network allow Gigabits network. So It can improve the performances a lot. I will try to setup the usage of the Gigabits private network instead the public one.

I’m using dedicated servers from soyoustart (ovh).

One question, when you create a new file for example using convoy/glusterFS it writes the file simultaneously on the three servers in one job or write it on the first one and the duplication in another one ?

Ok So testing again with the rancher-agent on the private network is not better:
root@722bdf64eceb:/testvolume# dd if=/dev/zero of=test.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 145.482 s, 7.4 MB/s
root@722bdf64eceb:/testvolume# dd if=/dev/zero of=test.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 114.637 s, 9.4 MB/s

root@722bdf64eceb:/testvolume# dd if=/dev/zero of=test2.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 115.445 s, 9.3 MB/s

root@722bdf64eceb:/testvolume# dd if=/dev/zero of=test3.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 95.5288 s, 11.2 MB/s

root@722bdf64eceb:/testvolume# dd if=/dev/zero of=test3.dd bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 115.8 s, 9.3 MB/s

I think is stille using the public network. So no improvement.