Кластарнае сховішча для невялікіх web-кластэраў на базе drbd+ocfs2

Пра што мы раскажам:
Як хутка разгарнуць агульнае сховішча для двух сервераў на базе рашэнняў drbd+ocfs2.

Для каго гэта будзе карысна:
Тутарыял стане карысны сістэмным адміністратарам і ўсім, хто выбірае спосаб рэалізацыі сховішчы ці жадаюць паспрабаваць рашэнне.

Ад якіх рашэнняў мы адмовіліся і чаму

Часта мы сутыкаемся з сітуацыяй, калі нам трэба рэалізаваць на невялікім web-кластары агульнае сховішча з добрай прадукцыйнасцю на чытанне - запіс. Мы спрабавалі розныя варыянты рэалізацыі агульнага сховішча для нашых праектаў, але мала што было здольна задаволіць нас адразу па некалькіх паказчыках. Цяпер раскажам, чаму.

• Glusterfs не задаволіў нас прадукцыйнасцю на чытанне і запіс, узнікалі праблемы з адначасовым чытаннем вялікай колькасці файлаў, была высокая нагрузка на CPU. Праблему з чытаннем файлаў можна было вырашыць, звяртаючыся за імі напрамую ў brick-і, але гэта не заўсёды дастасавальна і ў цэлым няправільна.

• Ceph не спадабаўся залішняй складанасцю, якая можа быць шкодная на праектах з 2/4 серверамі, асабліва, калі праект пасля абслугоўваюць. Ізноў жа, маюцца сур'ёзныя абмежаванні па прадукцыйнасці, якія змушаюць будаваць асобныя storage кластары, як і з glusterfs.

• Выкарыстанне аднаго nfs сервера для рэалізацыі агульнага сховішча выклікае пытанні ў плане адмоваўстойлівасці.

• s3 - выдатнае папулярнае рашэнне для некаторага круга задач, але гэта і не файлавая сістэма, што звужае вобласць ужывання.

• lsyncd. Калі мы ўжо пачалі казаць аб "не-файлавых сістэмах", то варта прайсціся і па гэтым папулярным рашэнні. Мала таго, што яно не падыходзіць для двухбаковага абмену (але калі вельмі жадаецца, то можна), дык яшчэ і не стабільна працуе на вялікай колькасці файлаў. Прыемным дадаткам да ўсяго будзе тое, што яно з'яўляецца аднаструменным. Прычына ў архітэктуры праграмы: яна выкарыстоўвае inotify для маніторынгу аб'ектаў працы, якія наважвае пры запуску і пры перасканаванні. У якасці сродку перадачы выкарыстоўваецца rsync.

Тутарыял: як разгарнуць агульнае сховішча на базе drbd+ocfs2

Адным з найболей зручных рашэнняў для нас стала звязак ocfs2+drbd. Цяпер мы раскажам, як мага хутка разгарнуць агульнае сховішча для двух сервераў на базе дадзеных рашэнняў. Але спачатку крыху пра кампаненты:

ДРБД - сістэма захоўвання з стандартнай пастаўкі Linux, якая дазваляе рэплікаваць дадзеныя паміж серверамі блокамі. Асноўнае прымяненне заключаецца ў пабудове адмоваўстойлівых сховішчаў.

OCFS2 - файлавая сістэма, якая забяспечвае падзялянае выкарыстанне аднаго і таго ж сховішчы некалькімі сістэмамі. Уваходзіць у пастаўку Linux і ўяўляе з сябе модуль ядра і userspace інструментар для працы з ФС. OCFS2 можна выкарыстоўваць не толькі па-над DRBD, але і па-над iSCSI з множным падлучэннем. У нашым прыкладзе мы выкарыстоўваем DRBD.

Усе дзеянні вырабляюцца на ubuntu server 18.04/XNUMX у мінімальнай канфігурацыі.

Крок 1. Наладжваем DRBD:

У файле /etc/drbd.d/drbd0.res апісваем нашу віртуальную блокавую прыладу /dev/drbd0:

resource drbd0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }
    on drbd1 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.192:7789;
}
    on drbd2 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.193:7789;
}
}

meta-disk internal - выкарыстоўваць тыя ж блокавыя прылады для захоўвання метададзеных
device /dev/drbd0 - выкарыстоўваць /dev/drbd0 як шлях да drbd таму.
disk /dev/vdb1 - выкарыстоўваць /dev/vdb1
syncer { rate 1000M; } - выкарыстоўваць гігабіт прапускной здольнасці канала
allow-two-primaries - важная опцыя, якая дазваляе прыняцце змен на двух primary серверах
after-sb-0pri, after-sb-1pri, after-sb-2pri - Опцыі, якія адказваюць за дзеянні вузла пры выяўленні splitbrain. Падрабязней можна паглядзець у дакументацыі.
become-primary-on both - усталёўвае абедзве ноды ў primary.

У нашым выпадку мы маем дзве абсалютна аднолькавыя ВМ, з выдзеленай віртуальнай сеткай прапускной здольнасцю ў 10 гігабіт.

У нашым прыкладзе сеткавыя імёны двух нод кластара - гэта drbd1 і drbd2. Для правільнай працы неабходна супаставіць у /etc/hosts імёны і ip адрасы вузлоў.

10.10.10.192 drbd1
10.10.10.193 drbd2

Крок 2. Наладжваем ноды:

На абодвух серверах выконваем:

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Атрымліваем наступнае:

Можна запускаць сінхранізацыю. На першай надзе трэба выканаць:

drbdadm primary --force drbd0

Глядзім статус:

cat /proc/drbd

Выдатна, пачалася сінхранізацыя. Чакаем заканчэння і бачым карціну:

Крок 3. Запускаем сінхранізацыю на другой нодзе:

drbdadm primary --force drbd0

Атрымліваем наступнае:

Цяпер мы можам пісаць у drbd з двух сервераў.

Крок 4. Устаноўка і настройка ocfs2.

Будзем выкарыстоўваць дастаткова трывіяльную канфігурацыю:

cluster:
     node_count = 2
     name = ocfs2cluster

node:
     number = 1
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.192
     name = drbd1

node:
     number = 2
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.193
     name = drbd2

Яе трэба запісаць у /etc/ocfs2/cluster.conf на абедзвюх нодах.

Ствараем ФС на drbd0 на любой надзе:

mkfs.ocfs2 -L "testVol" /dev/drbd0

Тут мы стварылі ФС з пазнакай testVol на drbd0, выкарыстоўваючы параметры па змаўчанні.

У /etc/default/o2cb неабходна выставіць (як у нашым файле канфігурацыі)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

і выканаць на кожнай надзе:

o2cb register-cluster ocfs2cluster

Пасля чаго ўключаем і дадаем у аўтазапуск усе патрэбныя нам unit-ы:

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Частка гэтага ўжо будзе запушчана падчас налад.

Крок 5. Дадаем кропкі мантавання ў fstab на абедзвюх нодах:

/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0

Дырэкторыя /media/shared пры гэтым павінна быць створана загадзя.

Тут мы выкарыстоўваем опцыі noauto, якая азначае, што ФС не будзе змантаваная пры старце (аддаю перавагу мантаваць сеткавыя фс праз systemd) і heartbeat=local, што азначае азначае выкарыстанне сэрвісу heartbeat на кожнай нодзе. Існуе яшчэ global heartbeat, які больш падыходзіць для вялікіх кластараў.

Далей можна змантаваць /media/shared і праверыць сінхранізацыю змесціва.

Гатова! У выніку мы атрымліваем больш-менш адмоваўстойлівае сховішча з магчымасцю маштабавання і прыстойнай прадукцыйнасцю.

Крыніца: habr.com