Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 28/9/17 22:31, Gandalf Corvotempesta wrote: > Hi to all, > Some questions about DRBDv9 (i'm really new to DRBD and DRBDv9 seems > to be a major refactor): > > Let's assume a 3-node cluster > > a) should I use RAID or creating resources on raw-disks would be ok? The choice is yours. If you build on raw disks, then the failure of a disk will cause the failure of the node. If that meets your data protection needs, then OK. Equally, just because you use RAID, doesn't mean it improves your data protection. RAID0 will make it worse, but might improve performance. Personally, RAID10 or RAID6 would be my preferred options. A small premium for additional drives with a massive improvement in data resilience, especially when you factor in the 3 x servers, each with RAID10 for example. > b) can I use ZFS on top of DRBD ? Yes > c) what if I have to aggragate multiple resources to increase spaces ? > Can I use LVM with something like this: > > pvcreate /dev/drbd0 > pvcreate /dev/drbd1 > vgcreate vg0 /dev/drbd0 /dev/drbd1 > lvcreate ....... > > to create a single LV on top of 2 drbd resources ? I've never tried, but I don't see why not. DRBD provides a block device, it doesn't "care" what you are storing on it, whether a FS or LVM... > > d) what If node0.disk0 on resource0 will fail and node0.disk1 on > resource1 don't? > My LV spawning both resource will still work as expect but in a little > bit slow mode as drbd has to fetch missing data (due to failed disk0) > from one of the other peer ? Normally, the resource0 would be on disk0 on both servers, and resource1 on disk1 on both servers So if node0.disk0 fails then node1.disk0 will still have the data. You could move resource0 to primary on node1 which would solve any performance issue, in fact you might see performance improve, since you no longer need to write data across to node0.disk0. > > e) AFAIK drbd is a network block device, to access this "block device" > should I put an NFS/iSCSI/Whatever in front of it or are there > something integrated in drbd ? (Like NFS inside Gluster) AFAIK, no, thought it depends on your needs/wants. DRBD9 changes things a bit in that you can have multiple satellite nodes which do not have local storage, but do "use" the DRBD devices. In 8.4 which I still use in production, I used iscsi to export the DRBD devices to their clients, but I expect if/when I move to DRBD9, I would use diskless satellite nodes, and then pass the raw DRBD device to the application. This will remove the iscsi layer in my system, which I hope might improve performance slightly, but certainly will reduce complexity (one less software to go wrong). > f) a 3node cluster is still subject to splitbrain ? I expect not, there are three* possibilities given node1 node2 and node3 1) node1 by itself, node2 + node3 together 2) all nodes together 3) all nodes alone * ignoring reshuffles of the same thing, eg, you could have node1 + node3 and node2 alone, but basically it is just saying 2 nodes together, and one alone. Clearly, in scenario 1, node1 should shutdown (stonith), and leave nodes 2 + 3 operational, so no split brain. In scenario 2, everything is working well, so no SB In scenario 3, all nodes are alone, so they should all stonith and die. This is why you need to build the interconnects to ensure that the connections between the nodes is more resilient. Don't just plug a single ethernet from each to a single switch, or the switch will die killing all your storage. They should have direct connections to each other in addition to multiple connections to multiple switches. Of course, doing this properly can be difficult and expensive. Regards, Adam -- Adam Goryachev Website Managers P: +61 2 8304 0000 adam at websitemanagers.com.au F: +61 2 8304 0001 www.websitemanagers.com.au