ĂfarĂ« do tĂ« flasim:
Si të shpërndajmë shpejt një depot të përbashkët për dy serverë me zgjidhjet drbd+ocfs2.
Kë është e dobishme:
Ky tutorial do të jetë i dobishëm për administratorët e sistemeve dhe për të gjithë ata që po eksplorojnë mënyra për të realizuar një depot ose duan të provojnë një zgjidhje.
Cilat zgjidhje ne i heqëm dorë dhe pse
Shpesh hasim situata kur duhet të realizojmë një depot të përbashkët në një web-kluster të vogël me performancë të lartë në lexim-shkrim. Kemi provuar opsione të ndryshme për të realizuar depot për projektet tona, por shumë pak ishin të afta të na kënaqnin menjëherë në disa parametra. Tani do t'ju tregojmë arsyen.
- Glusterfs nuk na kënaqte me performancën në lexim dhe shkrim, kishte probleme me leximin e një numri të madh skedarësh bashkë, ndodhte një ngarkesë e lartë në CPU. Problemi me leximin e skedarëve mund të zgjidhej duke iu drejtuar atyre direkt në brick, por kjo nuk është gjithmonë e aplikueshme dhe në tërësi e gabuar.
- Ceph nuk na pëlqeu për kompleksitetin e tij të tepruar, që mund të jetë ndaluese në projekte me 2-4 serverëve, sidomos nëse projekti pastaj administrohet. Përsëri, ka kufizime të rënda në performancë, duke e detyruar ndërtimin e grupeve të veçanta të magazinës, ashtu si me glusterfs.
- Përdorimi i një serveri nfs për realizimin e depot të përbashkët ngre pyetje në lidhje me qëndrueshmërinë.
- s3 â njĂ« zgjidhje e shkĂ«lqyer dhe e njohur pĂ«r disa lloje detyrash, por kjo nuk Ă«shtĂ« njĂ« sistem skedari, qĂ« e ngushton fushĂ«n e aplikimit.
- lsyncd. Nëse tashmë filluam të flasim për "në-në e skedarëve", është e rëndësishme të kalojmë dhe në këtë zgjidhje popullore. Jo vetëm që nuk është e përshtatshme për shkëmbim në të dy drejtimet (por nëse dëshiron shumë, mund të bëhet), ashtu si nuk punon stabile në një numër të madh skedarësh. Një shtesë e këndshme do të ishte se ajo është një proces të vetëm. Arsyeja është në arkitekturën e programit: ajo përdor inotify për të mbikëqyrur objektet e punës, të cilat i ngarkon gjatë fillimit dhe gjatë rishikimit. Për të transferuar përdorim rsync.
Tutorial: si të shpërndajmë një depot të përbashkët me drbd+ocfs2
Një nga zgjidhjet më të përshtatshme për ne ishte lidhja ocfs2+drbd. Tani do t'ju tregojmë se si mund të shpërndajmë shpejt një depot të përbashkët për dy servera me bazë të zgjidhjeve. Por përpara se të fillojmë, pak fjalë për komponentët:
DRBD â njĂ« sistem depozitimi nga shpĂ«rndarja standarde Linux, i cili lejon replikimin e tĂ« dhĂ«nave midis serverĂ«ve dhe grupeve. PĂ«rdorimi kryesor i tij Ă«shtĂ« pĂ«r ndĂ«rtimin e depozitave tĂ« qĂ«ndrueshme.
OCFS2 â njĂ« sistem skedari qĂ« siguron pĂ«rdorimin e pĂ«rbashkĂ«t tĂ« tĂ« njĂ«jtĂ«s depo nga disa sisteme. Ai Ă«shtĂ« pjesĂ« e shpĂ«rndarjes Linux dhe pĂ«rbĂ«n njĂ« modul bĂ«rthamĂ« dhe instrumente tĂ« pĂ«rdoruesit pĂ«r tĂ« punuar me FS. OCFS2 mund tĂ« pĂ«rdoret jo vetĂ«m mbi DRBD, por edhe mbi iSCSI me lidhje tĂ« shumta. NĂ« shembullin tonĂ« ne pĂ«rdorim DRBD.
Të gjithë veprimet bëhen në ubuntu server 18.04 në konfigurim minimal.
Hapi 1. Konfigurojmë DRBD:
Në skedarin /etc/drbd.d/drbd0.res përshkruajmë pajisjen tonë virtuale të bllokut /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 â pĂ«rdorimi i tĂ« njĂ«jtave pajisje blloku pĂ«r ruajtjen e tĂ« dhĂ«nave tĂ« metadatat
device /dev/drbd0 â pĂ«rdorimi i /dev/drbd0 si rrugĂ« pĂ«r drbd.
disk /dev/vdb1 â pĂ«rdorimi i /dev/vdb1
syncer { rate 1000M; } â pĂ«rdorimi i kanaleve tĂ« gigabit
allow-two-primaries â njĂ« opsion i rĂ«ndĂ«sishĂ«m qĂ« lejon pranimin e ndryshimeve nĂ« dy serverĂ« primarĂ«
after-sb-0pri, after-sb-1pri, after-sb-2pri â opsione qĂ« pĂ«rcaktojnĂ« veprimet e nodit kur zbulohet njĂ« splitbrain. MĂ« shumĂ« informacion mund tĂ« gjendet nĂ« dokumentacion.
become-primary-on both â vendos tĂ« dy nodet nĂ« primar.
Në rastin tonë, ne kemi dy VM të njëjta të cilat kanë një rrjet virtual me kapacitet kalimi prej 10 gigabit.
Në shembullin tonë, emrat e rrjetit të dy nodave të klasit janë drbd1 dhe drbd2. Për funksionimin e saktë, është e nevojshme të lidhni emrat dhe adresat IP në /etc/hosts.
10.10.10.192 drbd1
10.10.10.193 drbd2Hapi 2. Konfigurojmë nodet:
Në të dy serverët ekzekutojmë:
drbdadm create-md drbd0 
modprobe drbd
drbdadm up drbd0
cat /proc/drbdMarrim këtë:

Tani mund të fillojmë sinkronizimin. Në nodën e parë duhet të ekzekutojmë:
drbdadm primary --force drbd0Shikojmë statusin:
cat /proc/drbd 
Shumë mirë, filloi sinkronizimi. Po presim përfundimin dhe shohim imazhin:

Hapi 3. Nisim sinkronizimin në nodën e dytë:
drbdadm primary --force drbd0
Marrim këtë:

Tani mund të shkruajmë në drbd nga të dy serverët.
Hapi 4. Instalimi dhe konfigurimi i ocfs2.
Do të përdorim një konfigurim mjaft të thjeshtë:
klaster:
numri_i_nodave = 2
emri = ocfs2cluster
nod:
numri = 1
klaster = ocfs2cluster
ip_port = 7777
adresa_ip = 10.10.10.192
emri = drbd1
nod:
numri = 2
klaster = ocfs2cluster
ip_port = 7777
adresa_ip = 10.10.10.193
emri = drbd2
Duhet ta regjistrojmë në /etc/ocfs2/cluster.conf në të dy nodet.
Krijojmë FSH në drbd0 në çdo nod:
mkfs.ocfs2 -L "testVol" /dev/drbd0
Këtu krijuam FSH me etiketën testVol në drbd0, duke përdorur parametërat e paracaktuar.

Në /etc/default/o2cb duhet vendosur (siç në skedarin tonë të konfigurimit)
O2CB_ENABLED=true
O2CB_BOOTCLUSTER=ocfs2cluster dhe të ekzekutohet në çdo nod:
o2cb register-cluster ocfs2clusterPas kësaj aktivizojmë dhe shtojmë në autostart të gjitha njësitë e nevojshme:
systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2Pjesa e kësaj do të ishte tashmë e aktivizuar gjatë konfigurimit.
Hapi 5. Shtojmë pikat e montimit në fstab në të dy nodet:
/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0Direktoria /media/shared duhet të jetë krijuar më parë.
Këtu përdorim opsionet noauto, që do të thotë se FSH nuk do të montohet gjatë nisjes (preferoj të montohem sisteme rrjeti përmes systemd) dhe heartbeat=local, që do të thotë përdorimin e shërbimit heartbeat në çdo nod. Ekziston gjithashtu heartbeat global, që është më i përshtatshëm për klastere të mëdha.
Më pas mund të montohet /media/shared dhe të kontrollohet sinkronizimi i përmbajtjes.
Gati! Në rezultat, ne kemi një storazh relativisht të besueshëm me mundësi për shkallëzim dhe performancë të mirë.
Burimi: habr.com
