Il 03 ott 2016 09:33, "Kevin Lemonnier" <lemonnierk@xxxxxxxxx> ha scritto:
>
> Not sure about that for the web hosting workload, but that would be very
> interesting for our VM hosting service. I read the topic about that,
> if there are docs about how to set that up I might test it next time
> I have to setup a VM cluster.
>
how do you plan to use block storage for vm hosting?
With vm hosting you could create an additional qcow2 disk and access that natively with qemu, isn't it?
It should way faster than using iscsi to access the block device on top of gluster
I think that top priorities for gluster would be:
- small files performance so that gluster could replace NFS on almost every workload (i know, writing 3 times like in gluster would be always slower than writing once like in nfs, but the replica is not the only issue that gluster has on small files. Ever a "ls -la" is slow)
- some way to add bricks in a number less than the replica count. I don't know how but ceph does it even without EC thus there's a way to accomplish
In full replica 3 cluster, adding a brick means adding at least 3 severs with 1 brick each
DRBD9 does something similiar by adding one server at once and rebalance the cluster
http://www.drbd.org/en/doc/users-guide-90/s-rebalance
- native snmp monitoring (with smuxpeer or similiar, traps and so on). Having a good monitoring system is mandatory in every production environment . This could be really a plus for gluster. Triggering traps on events is cool!
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
