TOPIC:

Hey Salvatore,

In terms of the storage layout I'm working with at the moment, DRBD is sat on top of a ZFS zVol, with just good 'ol ext4 on the resulting DRBD virtual device used for NFS. So not too sure there's much wiggle room with ext4, but I'll take a look at anything that can be optimisied on the ZFS side. I have been testing all of this within a nested virt environment, so possibly that isn't helping either.

I'm going to comb through any other HA-Lizard files I can find on my host and try and get everything working nicely with NFS, would you be interested in committing these upstream if I am succesful?

Thanks,
Maxwell

Also, I'm having a little trouble trying to create a second DRBD resource for NFS testing, any pointers as to how to set persistent rules in Xenserver/XCP-ng's firewall for another DRBD port?

Cheers

Hi Maxwell,
Excuse the late reply.

The FW rule installed by our installer will allow all traffic between hosts on the replication network, so you shouldn't need any additional rules to allow another DRBD device.

Regarding performance, our early development/testing was done inside a nested environment, and we saw very poor performance as well. That may be why you are experiencing the same.

There are a couple of posts that discuss all the config changes required to configure multiple DRBD devices. I will update shortly with links.

Lastly, regarding moving your changes upstream, yes, I would be very interested in adding NFS support. You can email ha<at>pulsesupply.com so that we can coordinate directly on that.

Thanks

Hi Maxwell,
you can follow this post for details on which files need to be updated to support multiple DRBD devices.
www.halizard.com/forum/software-support/312-multiple-srs

Hi Salvatore,

Thanks for sending this across. I have been trying to overcome the performance issues with NFS, but have so far not succeeded. I am also cautious of the write confirmations as you explained this is not present in a file based protocol like NFS compared with iSCSI. For these reasons, I have decided that in my deployment we are going to go ahead with the usual iSCSI deployment and expand storage where needed for snapshots/backups.

I will however tidy up the lab installation I was using for NFS and will gladly send the modifications across. Of course this mainly consisted of the 2 service lines you mentioned previously, I have not looked into modifying the ha-cfg tool to work with the NFS services but will look into this also.

Thank you for your time and help!

Best Regards,
Maxwell

Hi Maxwell & Salvatore

I just came by to discuss a similar thing so we might hit common ground. Otherwise, apologies in advance for hijacking your thread

Maxwell,
I can't imagine you would ever get NFS to reach iSCSI performance given the demand for block level operation but can I ask, what is the benefit of using HA-Lizard if you thin provision? ie would it not be more appropriate to deploy an iSCSI target for a pool?

Salvatore,
I would like to expand my storage facilities beyond what I have thick provisioned with my HA-Lizard farm by deploying an iSCSI target into my data centre but I don't want any single points of failure so the idea was to provision a DRBD replicated storage pair to accompany my HA-Lizard pairs.

Question: Can HA-iSCSI be easily modified to run as storage only? ie HA-Lizard without the virtualisation.
This could be an accompanying bolt-on product or a free standing iscsi target solution.

What are your thoughts?
Would this not solve the thin provisioning dilemma also?

Cheers,

Nathan