Установка и настройка DRBD для сетевой репликации файловой системы на Debian 8

Компьютерное

Поговорим о сетевой репликации файловой системы. Сначала, я хотел разбить статья на несколько разных, но потом решил что так будет удобнее читать.

Сетевая репликация файловой системы сегодня используется в различных задачах:

  • Репликация файловой системы по соображениям безопасности: если откажет один узел, другой узел будет доступен.
  • Репликация файловой системы в другой офис компании, так что каждый сотрудник будет иметь доступ к своим данным локально, а не через общедоступную сеть. Но если он вдруг окажется в другом офисе — он так же будет иметь свои данные — локально, сразу и моментально.

Как вы наверное уже подумали — такого рода системы используются в кластерных системах.

Мы разберемся как сделать реализацию сетевой репликации на DRBD. Главная её задача (как и других похожих систем) Высокая доступность и Отказоустойчивость для файловой системы.

Разберем настройку на Debian 8, но по идее, должно работать и на Ubuntu.

Подготовка

Перед началом, разберемся с тем что у нас есть:

  • Минимум 2 сервера на Debian.
  • Debian установлен в минимальной конфигурации (не обязательно если вы хотите экспериментировать на продакшен-серверах и знаете что делаете). Рекомендую к прочтению инструкцию: https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
  • Минимум 2 Linux диска на каждом сервере: /dev/sda для установки Linux, /dev/sdb для установки DRBD.

ВНИМАНИЕ!!!: В процессе установки все данные хранимые на диске /dev/sdb будут уничтожены, так что не используйте диск с данными на нем.

Установка DRBD

В нашем примере мы будем использовать два узла, которые будут такими:

  • 192.168.152.100 mysql1.local.vm
  • 192.168.152.110 mysql2.local.vm

На всех узлах должен быть файл /etc/hosts с таким содержанием:

127.0.0.1 localhost
192.168.152.100 mysql1.local.vm mysql1
192.168.152.110 mysql2.local.vm mysql2
#The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Теперь устанавливаем DRBD:

apt-get update
apt-get -y upgrade
apt-get install drbd-utils

Настраиваем Primary/Secondary — Отказоустойчивый

Основной конфигурационный файл это /etc/drbd.conf который выглядит приблизительно вот так:

include "drbd.d/global_common.conf";
include "drbd.d/*.res";

По умолчанию, /etc/drbd.d/global_common.conf глобальные и общие секции конфигурации DRBD configuration, в то время как.res содержат один ресурс в каждой секции.

В нашем примере мы делаем минимальную установку для репликации на два узла. На каждом узле вносим изменения:

Для начала отредактируем  строки заданные по умолчанию в /etc/drbd.d/global_common.conf

global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification
}
...
net {
protocol C;
# protocol timeout max-epoch-size max-buffers unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow-two-primaries cram-hmac-alg shared-secret after-sb-0pri
# after-sb-1pri after-sb-2pri always-asbp rr-conflict
# ping-timeout data-integrity-alg tcp-cork on-congestion
# congestion-fill congestion-extents csums-alg verify-alg
# use-rle
}
...

Теперь создадим файл /etc/drbd.d/r0.res для наших ресурсов. Создаем один и тот же файл на всех узлах и вносим туда информацию о ресурсах:
resource r0 {
on mysql1.local.vm {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.152.100:7789;
meta-disk internal;
}
on mysql2.local.vm {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.152.110:7789;
meta-disk internal;
}
}

Что мы сделали и получили:

  • С помощью параметра usage-count мы будем получать статистику использования DRBD.
  • Ресурсы настроены на использование полной синхронизации репликации с Protocol Cunless если явно не указано другое.
  • Наш кластер состоит из двух узлов: mysql1 и mysql2.
  • У нас есть ресурс названный r0 который использует/dev/sdb как низкоуровневое устройство, и настроен на внутренние метаданные.
  • Ресурс использует порт TCP 7789 для своего сетевого подключения, и закреплен за адресами 192.168.152.100 и 192.168.152.110 соответственно.

На всех узлах инициализируем метаданные:
drbdadm create-md r0
Вы увидите что-то вроде:

—== Thank you for participating in the global usage survey ==—
The server’s response is:

you are the 2963th user to install this version
initializing activity log
NOT initializing bitmap
Writing meta data…
New drbd meta data block successfully created.
success

Далее запустим ресурс и инициализируем выполнение первой репликации, только на первом узле:
drbdadm up r0
drbdadm primary --force r0

Для проверки — что у нас все хорошо — посмотрите файл /proc/drbd на обоих узлах. Вы должны увидеть что-то вроде:

Mysql1

root@mysql1:# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r——
ns:54624 nr:0 dw:0 dr:55536 al:0 bm:3 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5188060
[>………………..] sync’ed: 1.1% (5064/5116)Mfinish: 0:17:21 speed: 4,964 (4,964) K/sec

Mysql2 

root@mysql2:# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r——
ns:0 nr:17496 dw:17496 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5225188
[>………………..] sync’ed: 0.4% (5100/5116)Mfinish: 0:29:41 speed: 2,916 (2,916) want: 5,160 K/sec

Во время сборки вы можете увидеть уведомление UpToDate/Inconsistent. Все нормально. Вы же делаете первую синхронизацию.

После синхронизации должно измениться UpToDate/UpToDate в логах:

root@mysql1:/home/sysop# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r——
ns:5242684 nr:0 dw:0 dr:5243596 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Теперь у нас есть блочное устройство, по имени /dev/drbd1 которое мы можем отформатировать в любую предпочитаемую нами файловую систему. Например мы хотим отформатировать его в ext4 и смонтировать в /var/www:

root@mysql1:/home/sysop# mkfs.ext4 /dev/drbd1
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 1310671 4k blocks and 327680 inode
Filesystem UUID: ab3e18c9-e8cb-42c8-977a-ab79bdb18aea
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Теперь монтируем нашу файловую систему:

mkdir /var/www
mount /dev/drbd1 /var/www

Как результат — директория /var/www directory смонтирована на drbd системе.

В нашем сценарии настройки Primary/Secondary, мы внедрили систему аварийного восстановления.

В этом случае, если вы попробуете смонтировать файловую систему на втором узле — вы получите ошибку:

root@mysql2:~# mount /dev/drbd1 /var/www/
mount: /dev/drbd1 is write-protected, mounting read-only
mount: mount /dev/drbd1 on /var/www failed: Wrong type of media

Это нормально и ожидаемо из-за нашей конфигурации

Теперь симулируем падение узла mysql1, например отключим узел командой отключения питания.

На mysql2 мы увидим что случилось:

Oct 5 13:52:14 mysql2 kernel: [13458.629215] drbd r0: PingAck did not arrive in time.
Oct 5 13:52:14 mysql2 kernel: [13458.629587] drbd r0: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Oct 5 13:52:14 mysql2 kernel: [13458.629919] drbd r0: asender terminated
Oct 5 13:52:14 mysql2 kernel: [13458.629921] drbd r0: Terminating drbd_a_r0
Oct 5 13:52:14 mysql2 kernel: [13458.630028] drbd r0: Connection closed
Oct 5 13:52:14 mysql2 kernel: [13458.630035] drbd r0: conn( NetworkFailure -> Unconnected )
Oct 5 13:52:14 mysql2 kernel: [13458.630035] drbd r0: receiver terminated
Oct 5 13:52:14 mysql2 kernel: [13458.630036] drbd r0: Restarting receiver thread
Oct 5 13:52:14 mysql2 kernel: [13458.630037] drbd r0: receiver (re)started
Oct 5 13:52:14 mysql2 kernel: [13458.630041] drbd r0: conn( Unconnected -> WFConnection )

Узел mysql2 обнаружил что mysql1 мертв и если мы проверим /proc/drbd:

root@mysql2:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/DUnknown C r——
ns:0 nr:5457236 dw:5457236 dr:0 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Мы увидим что изменился статус с Secondary/primary на Secondary/unknown. Теперь сделаем трюк, и представим mysql2 как главного. На mysql2 выполняем:

drbdadm primary r0

Теперь снова проверим /proc/drbd и увидим магию…

root@mysql2:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r——
ns:0 nr:5457236 dw:5457236 dr:912 al:0 bm:320 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Как видите, наш узел теперь главный и мы можем монтировать всё как обычно.

root@mysql2:~# mount /dev/drbd1 /var/www/
root@mysql2:~# df -h
Filesystem          Size            Used          Avail         Use%           Mounted on
/dev/sda1           9,3G           1,4G           7,5G           16%               /
udev                     10M            0                 10M           0%               /dev
tmpfs                   97M           4,6M          92M            5%               /run
tmpfs                 241M            0                241M          0%               /dev/shm
tmpfs                  5,0M          4,0K            5,0M          1%               /run/lock
tmpfs                  241M           0                241M          0%              /sys/fs/cgroup
/dev/drbd1         4,8G          10M             4,6G           1%              /var/www

Теперь предположим что мы решили использовать mysql1 снова, если мы начнем сразу мы получим splitbrain. На самом деле. Посмотрите на логи и ошибки:

Oct 5 14:26:04 mysql1 kernel: [ 7.760588] drbd r0: conn( StandAlone -> Unconnected )
Oct 5 14:26:04 mysql1 kernel: [ 7.760599] drbd r0: Starting receiver thread (from drbd_w_r0 [458])
Oct 5 14:26:04 mysql1 drbdadm[435]: adjust net: r0
Oct 5 14:26:04 mysql1 drbdadm[435]: ]
Oct 5 14:26:04 mysql1 kernel: [ 7.769318] drbd r0: receiver (re)started
Oct 5 14:26:04 mysql1 kernel: [ 7.769327] drbd r0: conn( Unconnected -> WFConnection )
Oct 5 14:26:04 mysql1 /etc/init.d/mysql[485]: MySQL PID not found, pid_file detected/guessed: /var/run/mysqld/mysqld.pid
Oct 5 14:26:04 mysql1 acpid: starting up with netlink and the input layer
Oct 5 14:26:04 mysql1 acpid: 1 rule loaded
Oct 5 14:26:04 mysql1 acpid: waiting for events: event logging is off
Oct 5 14:26:05 mysql1 kernel: [ 8.270578] drbd r0: Handshake successful: Agreed network protocol version 101
Oct 5 14:26:05 mysql1 kernel: [ 8.270581] drbd r0: Agreed to support TRIM on protocol level
Oct 5 14:26:05 mysql1 kernel: [ 8.270770] drbd r0: conn( WFConnection -> WFReportParams )
Oct 5 14:26:05 mysql1 kernel: [ 8.270771] drbd r0: Starting asender thread (from drbd_r_r0 [461])
Oct 5 14:26:05 mysql1 kernel: [ 8.272594] block drbd1: drbd_sync_handshake:
Oct 5 14:26:05 mysql1 kernel: [ 8.272597] block drbd1: self 242B364F4A5B9C68:525CC995A3CFBA2B:44A1DE193A6C6701:0000000000000004 bits:64463 flags:0
Oct 5 14:26:05 mysql1 kernel: [ 8.272598] block drbd1: peer 6903F6042F95F5FF:525CC995A3CFBA2A:44A1DE193A6C6700:0000000000000004 bits:4 flags:0
Oct 5 14:26:05 mysql1 kernel: [ 8.272599] block drbd1: uuid_compare()=100 by rule 90
Oct 5 14:26:05 mysql1 kernel: [ 8.272601] block drbd1: helper command: /sbin/drbdadm initial-split-brain minor-1
Oct 5 14:26:05 mysql1 kernel: [ 8.272692] drbd r0: meta connection shut down by peer.
Oct 5 14:26:05 mysql1 kernel: [ 8.272720] drbd r0: conn( WFReportParams -> NetworkFailure )
Oct 5 14:26:05 mysql1 kernel: [ 8.272722] drbd r0: asender terminated
Oct 5 14:26:05 mysql1 kernel: [ 8.272722] drbd r0: Terminating drbd_a_r0
Oct 5 14:26:05 mysql1 kernel: [ 8.279158] block drbd1: helper command: /sbin/drbdadm initial-split-brain minor-1 exit code 0 (0x0)
Oct 5 14:26:05 mysql1 kernel: [ 8.279173] block drbd1: Split-Brain detected but unresolved, dropping connection!
Oct 5 14:26:05 mysql1 kernel: [ 8.279197] block drbd1: helper command: /sbin/drbdadm split-brain minor-1
Oct 5 14:26:05 mysql1 kernel: [ 8.286125] block drbd1: helper command: /sbin/drbdadm split-brain minor-1 exit code 0 (0x0)
Oct 5 14:26:05 mysql1 kernel: [ 8.286144] drbd r0: conn( NetworkFailure -> Disconnecting )
Oct 5 14:26:05 mysql1 kernel: [ 8.286146] drbd r0: error receiving ReportState, e: -5 l: 0!
Oct 5 14:26:05 mysql1 kernel: [ 8.287009] drbd r0: Connection closed
Oct 5 14:26:05 mysql1 kernel: [ 8.287017] drbd r0: conn( Disconnecting -> StandAlone )
Oct 5 14:26:05 mysql1 kernel: [ 8.287018] drbd r0: receiver terminated
Oct 5 14:26:05 mysql1 kernel: [ 8.287019] drbd r0: Terminating drbd_r_r0

Это потому что у нас теперь два главных узла что невозможно в конфигурации Primary/Secondar. Предполагая что на mysql2 уже более свежие данные, мы понизим mysql1 до Secondary.

На mysql1 выполняем:

root@mysql1:~# drbdadm secondary r0
root@mysql1:~# drbdadm connect --discard-my-data r0

На mysql2 который выживает со splitbrain  выполняем:

root@mysql2:~# drbdadm connect r0

Теперь можете проверить что все пересобралось и работает правильно, но теперь mysql1 — secondary, а mysql2 — primary.

root@mysql1:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r——
ns:0 nr:28224 dw:28224 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:229628
[=>………………] sync’ed: 11.2% (229628/257852)K
finish: 0:01:04 speed: 3,528 (3,528) want: 6,600 K/sec

Настройка DRBD как кластер Primary/Primary  — Высокой Доступности

Теперь мы хотим сконфигурировать наш Кластер Сетевой Файловой системы в конфигурации высокой доступности (High Availability. Для этого надо сделать несколько изменений в настройках.

Откройте файл /etc/drbd.d/r0.res и добавьте в настройки то что выделено красным:

 resource r0 {
on mysql1.local.vm {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.152.100:7789;
meta-disk internal;
}
on mysql2.local.vm {
device /dev/drbd1;
disk /dev/sdb;
address 192.168.152.110:7789;
meta-disk internal;
}
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
startup {
become-primary-on both;
}
}

Что мы сделали — мы автоматизировали управление ситуациями splitbrain, Потому что у нас HA окружение, и перенос на другой ресурс доложен быть автоматизирован.

split-brain = это действие которое ловится когда случается splitbrain, в этом случае мы отправляем письмо на root@localhost.

after-sb-0pri = Split brain только что обнаружен, но в это время ни на одном хосте у ресурса нет роли Primary.

discard-zero-changes = Если есть какие-либо хосты, на которых не произошло никаких изменений вообще, просто применить все изменения, сделанные с другой стороны и продолжать.
after-sb-1pri = Split brain только что обнаружен и в это время на одном из хостов у ресурса Primary роль.

discard-secondary = тот хост у которого Secondary роль, делает хост жертвой split brain.

after-sb-2pri = Split brainтолько что обнаружен, и в это время у ресурса Primary роль на обоих хостах.

Теперь выполните на обоих серверах команды,  каждая команда на каждом сервере одновременно:

drbdadm disconnect r0
drbdadm connect r0
drbdadm primary r0

Теперь перезапустите сервис на обоих серверах:

/etc/init.d/drbd restart

Поглядим теперь логи drbd на обоих узлах

root@mysql1:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r——
ns:0 nr:12 dw:4 dr:904 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

root@mysql2:~# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 1A9F77B1CA5FF92235C2213
1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r——
ns:12 nr:0 dw:0 dr:924 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Как можете видеть, на обоих конфигурация Primary/Primary, и мы можем монтировать раздел на обоих узлах если потребуется.

root@mysql1:~# mount /dev/drbd1 /var/www/
root@mysql1:~# df -h
Filesystem          Size            Used          Avail         Use%           Mounted on
/dev/sda1           9,3G           1,4G           7,5G          16%               /
udev                    10M            0                 10M          0%                 /dev
tmpfs                  97M            4,6M          92M          5%                 /run
tmpfs                  241M          0                 241M        0%                 /dev/shm
tmpfs                  5,0M           4,0K          5,0M         1%                  /run/lock
tmpfs                  241M          0                 241M        0%                 /sys/fs/cgroup
/dev/drbd1        4,8G           10M           4,6G          1%                  /var/www

Сейчас проверим как это работает. Создадим файл на mysql1

root@mysql1:~# touch /var/www/mysql1.txt
root@mysql1:~#

Попробуем смонтировать drbd1 на mysql2 и поглядим, есть ли у нас там mysql1.txt.

root@mysql2:~# mount /dev/drbd1 /var/www/
root@mysql2:~# ls -al /var/www/
total 24
drwxr-xr-x 3 root root 4096 oct 5 15:30 .
drwxr-xr-x 12 root root 4096 oct 5 12:26 ..
drwx—— 2 root root 16384 oct 5 12:23 lost+found
-rw-r—r— 1 root root 0 oct 5 15:20 mysql1.txt

Как видите — файл есть!

DRBD с файловой системой OCFS2

В предыдущем решении у нас была небольшая проблема: если у вас смонтированы обе файловые системы, вы не увидите изменения, пока не перемонтируете раздел, а это может быть проблемой большой. Так что вместо ext4, мы используем файловую систему ocfs2.

Сначала убедитесь что /dev/drbd1 отмонтированна, для верности — что на обоих серверах:

umount /var/www

Теперь установим утилиты ocfs2 на обоих узлах для создания нашей распределенной файловой системы:

apt-get install ocfs2-tools

После этого создаем файловую систему ocfs2 командой:

root@mysql1:/var/www# mkfs -t ocfs2 -N 2 -L ocfs2_drbd1 /dev/drbd1

Вывод должен выглядеть как-то так:

root@mysql1:/var/www# mkfs -t ocfs2 -N 2 -L ocfs2_drbd1 /dev/drbd1
mkfs.ocfs2 1.6.4
Cluster stack: classic o2cb
/dev/drbd1 is mounted; will not make a ocfs2 volume here!
root@mysql1:/var/www# cd
root@mysql1:~# umount /var/www/
root@mysql1:~# mkfs -t ocfs2 -N 2 -L ocfs2_drbd1 /dev/drbd1
mkfs.ocfs2 1.6.4
Cluster stack: classic o2cb
Label: ocfs2_drbd1
Features: sparse backup-super unwritten inline-data strict-journal-super xattr
Block size: 4096 (12 bits)
Cluster size: 4096 (12 bits)
Volume size: 5368508416 (1310671 clusters) (1310671 blocks)
Cluster groups: 41 (tail covers 20431 clusters, rest cover 32256 clusters)
Extent allocator size: 4194304 (1 groups)
Journal size: 67108864
Node slots: 2
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 2 block(s)
Formatting Journals: done
Growing extent allocator: done
Formatting slot map: done
Formatting quota files: done
Writing lost+found: done
mkfs.ocfs2 successful

Теперь мы можем использовать нативные возможности ocfs2 для управления распределенной файловой системой.

Отредактируем /etc/ocfs2/cluster.conf на обоих узлах, добавив:

node:
ip_port = 7777
ip_address = 192.168.152.100
number = 0
name = mysql1.local.vm
cluster = ocfs2
node:
ip_port = 7777
ip_address = 192.168.152.110
number = 1
name = mysql2.local.vm
cluster = ocfs2
cluster:
node_count = 2
name = ocfs2

Затем потребуется перезапустить сервис ocfs2:

/etc/init.d/o2cb restart

И проверим статус, должен быть похож на это:

root@mysql1:~# /etc/init.d/o2cb status
* o2cb.service — LSB: Load O2CB cluster services at system boot.
Loaded: loaded (/etc/init.d/o2cb)
Active: active (exited) since Wed 2016-10-05 16:10:20 CEST; 23s ago
Process: 2767 ExecStop=/etc/init.d/o2cb stop (code=exited, status=0/SUCCESS)
Process: 2793 ExecStart=/etc/init.d/o2cb start (code=exited, status=0/SUCCESS)
Oct 05 16:10:20 mysql1.local.vm systemd[1]: Starting LSB: Load O2CB cluster services at system boot….
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Loading filesystem «configfs»: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Loading stack plugin «o2cb»: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Loading filesystem «ocfs2_dlmfs»: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Creating directory ‘/dlm’: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Mounting ocfs2_dlmfs filesystem at /dlm: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Setting cluster stack «o2cb»: OK
Oct 05 16:10:20 mysql1.local.vm o2cb[2793]: Starting O2CB cluster ocfs2: OK
Oct 05 16:10:20 mysql1.local.vm systemd[1]: Started LSB: Load O2CB cluster services at system boot..

Снова переходим к магии и монтируем нашу файловую систему на обоих серверах:

root@mysql1:~# mount -t ocfs2 /dev/drbd1 /var/www/

root@mysql2:~# mount -t ocfs2 /dev/drbd1 /var/www/

Создаем по файлу на каждом сервере:

root@mysql1:~# touch /var/www/mysql1.txt

root@mysql2:~# touch /var/www/mysql2.txt

Проверяем:

root@mysql1:~# ls -la /var/www/
total 4
drwxr-xr-x 3 root root 3896 oct 5 16:20 .
drwxr-xr-x 12 root root 4096 oct 5 12:25 ..
drwxr-xr-x 2 root root 3896 oct 5 15:55 lost+found
-rw-r--r-- 1 root root 0 oct 5 16:20 mysql1.txt
-rw-r--r-- 1 root root 0 oct 5 16:20 mysql2.txt

root@mysql2:~# ls -la /var/www/
total 4
drwxr-xr-x 3 root root 3896 oct 516:20 .
drwxr-xr-x 12 root root 4096 oct 512:26 ..
drwxr-xr-x 2 root root 3896 oct 515:55 lost+found
-rw-r--r-- 1 root root 0 oct 5 16:20 mysql1.txt
-rw-r--r-- 1 root root 0 oct 516:20 mysql2.txt

Производительность

Вы можете сделать несколько тестов для проверки производительности вашей конфигурации. На виртуальной машине на моем ПК я получил данные приведеные ниже. На реальных серверах вы получите лучшие результаты.

Сначала установите ioping, для теста производительности случайного чтения.

apt-get install ioping

Запускаем:

root@mysql1:cd /var/www
root@mysql1:/var/www# ioping -R .
--- . (ocfs2 /dev/drbd1) ioping statistics ---
49.3 k requests completed in 3.00 s, 17.1 k iops, 66.7 MiB/s
min/avg/max/mdev = 43 ms / 58 ms / 8.41 ms / 64 ms

66,7 MiB/s на случайном чтении — это очень и очень хороший результат!!

И последовательное чтение:

root@mysql1:/var/www# dd if=/dev/zero of=test bs=64k count=32k conv=fdatasync
32768+0 records recived
32768+0 records send
2147483648 byte (2,1 GB) coping, 34,1095 s, 63,0 MB/s

Пара советов

  • Для файловой системы с высоким трафиком используйте выделенную сетевую карту.
  • Для отказоустойчивости сети используйте  связку из 2 сетевых интерфейсов.
  • DRBD имеет множество опций для настройки производительности на узлах.

Источник статьи: https://www.howtoforge.com/tutorial/install-and-configure-drbd-for-network-filesystem-replication-debian-8/

На этом всё. Удачи!

Оцените статью
( 2 оценки, среднее 5 из 5 )
Блог админа