<p dir="ltr">Il 03 ott 2016 09:33, "Kevin Lemonnier" <<a href="mailto:lemonnierk@ulrar.net">lemonnierk@ulrar.net</a>> ha scritto:<br>
><br>
> Not sure about that for the web hosting workload, but that would be very<br>
> interesting for our VM hosting service. I read the topic about that,<br>
> if there are docs about how to set that up I might test it next time<br>
> I have to setup a VM cluster.<br>
></p>
<p dir="ltr">how do you plan to use block storage for vm hosting?<br>
With vm hosting you could create an additional qcow2 disk and access that natively with qemu, isn't it?</p>
<p dir="ltr">It should way faster than using iscsi to access the block device on top of gluster</p>
<p dir="ltr">I think that top priorities for gluster would be:</p>
<p dir="ltr">- 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) </p>
<p dir="ltr">- 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</p>
<p dir="ltr">In full replica 3 cluster, adding a brick means adding at least 3 severs with 1 brick each</p>
<p dir="ltr">DRBD9 does something similiar by adding one server at once and rebalance the cluster<br>
<a href="http://www.drbd.org/en/doc/users-guide-90/s-rebalance">http://www.drbd.org/en/doc/users-guide-90/s-rebalance</a></p>
<p dir="ltr">- 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!</p>