[DRBD-user] Dual primary and LVM

[Igor Cicimov]

Hey Gionatan,

On Thu, Jul 27, 2017 at 7:04 PM, Gionatan Danti <g.danti at assyoma.it> wrote:

> Il 27-07-2017 10:23 Igor Cicimov ha scritto:
>
>>
>> When in cluster mode LVM will not use local cache that's part of the
>> configuration you need to do during setup.
>>
>>
> Hi Igor, I am not referring to LVM's metadata cache. I speak about the
> kernel I/O buffers (ie: the one you can see from "free -m" under the buffer
> column) which, in some case, work similarly to a "real" pagecache.
>
> ​Well don't see how is this directly related to dual-primary setup since
even with single primary what ever is not yet committed to disk is not
replicated to the secondary as well. So in case you loose the primary what
ever was in its buffers at the time is gone as well.
​

​But the rule-of-thumb lets say would be to have as less cache layers as
possible without impact on the performance and retain the data consistency
in the same time. With VMs you have additional cache layer in the guest as
well as the one in the host. There are many documents discussing cache
modes like these
https://www.suse.com/documentation/sles11/book_kvm/data/sect1_1_chapter_book_kvm.html,
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liaat/liaatbpkvmguestcache.htm,
https://pve.proxmox.com/wiki/Performance_Tweaks for example.

So which write cache mode you will use really depends on the specific
hardware you use, the system amount of RAM, the OS sysctl settings (ie how
often you flush to dis, params like vm.dirty_ratio,
vm.dirty_background_ratio etc.), the disk types/speed, the HW RAID
controller (for example with battery backed cache or not) ie DRBD has some
tuning parameters like:

    disk-flushes no;
    md-flushes no;
    disk-barrier no;

which makes it possible to use the write-back caching on the *BBU-backed*
RAID controller instead of flushing directly to disk. So many factors are
in play but the main idea is to reduce the number of caches (or their
caching time) between the data and the disk as much as possible without
loosing data or performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170727/25f128fc/attachment.htm>