Сховішча LINSTOR і яго інтэграцыя з OpenNebula

Сховішча LINSTOR і яго інтэграцыя з OpenNebula

Не так даўно хлопцы з LINBIT прадставілі сваё новае SDS-рашэнне – Linstor. Гэтае цалкам вольнае сховішча ў аснове якога выкарыстоўваюцца правераныя тэхналогіі: DRBD, LVM, ZFS. Linstor спалучае ў сабе прастату і добра прапрацаваную архітэктуру, што дазваляе дамагчыся стабільнасці і дастаткова вялікіх вынікаў.

Сёння я хацеў бы расказаць пра яго крыху падрабязней і паказаць наколькі проста яго можна інтэграваць з OpenNebula выкарыстоўваючы linstor_un — новы драйвер, які я распрацаваў спецыяльна для гэтай мэты.

Linstor у спалучэнні з OpenNebula дазваляе пабудаваць хуткае і надзейнае воблака, якое можна без праблем разгарнуць на ўласнай інфраструктуры.

Архітэктура Linstor

Linstor не з'яўляецца ні файлавай сістэмай ні блокавым сховішчам само па сабе, Linstor – гэта аркестратар, які падае пласт абстракцыі які дазваляе аўтаматызаваць стварэнне тамоў у LVM ці ZFS і рэплікаваць іх з дапамогай DRBD9.

Ламаем стэрэатыпы

Але пастойце, DRBD? - Навошта яго аўтаматызаваць і як наогул гэта можа працаваць?

Успомнім мінулае, калі ва ўсю быў папулярны DRBD8. Стандартнае яго выкарыстанне мела на ўвазе стварэнне адной вялікай блокавай прылады і наразанне яго на шмат маленькіх кавалачкаў, пры дапамозе таго ж LVM. Гэтакі mdadm RAID-1 але з рэплікацыяй па сетцы.

Такі падыход не пазбаўлены недахопаў, і таму з прыходам DRBD9 прынцыпы пабудовы сховішча памяняліся, зараз пад кожную віртуалку ствараецца асобная DRBD-прылада.

Падыход з незалежнымі блокавымі прыладамі дазваляе лепш утылізаваць прастору ў кластары, а таксама дадае шэраг дадатковых магчымасцяў. Да прыкладу для кожнай такой прылады можна вызначаць колькасць рэплік, іх размяшчэнне і індывідуальныя налады. Іх лёгка ствараць/выдаляць, рабіць снапшоты, змяняць памер, уключаць шыфраванне і шматлікае іншае. Варта заўважыць, што DRBD9 гэтак жа падтрымлівае кворум, які дазваляе пазбегнуць split-brain сітуацый.

Рэсурсы і бэкэнды

Ствараючы новую блокавую прыладу, Linstor размяшчае патрэбную колькасць рэплік на розных нодах у кластары. Кожную такую ​​рэпліку мы будзем зваць DRBD-рэсурсам.

Рэсурсы бываюць двух тыпаў:

  • Data-рэсурс - Уяўляюць сабой DRBD-прылада размешчанае на нодзе ў LVM або ZFS пуле.
    На дадзены момант ёсць падтрымка некалькіх бэкэндаў і іх колькасць увесь час расце. Ёсць падтрымка LVM, ThinLVM і ZFS. Апошнія два дазваляюць ствараць і выкарыстоўваць снапшоты.
  • Diskless-рэсурс - уяўляе сабой DRBD-прылада размешчанае на нодзе без бэкенда, але якое дазваляе звяртацца з ім як са звычайнай блокавай прыладай, усе аперацыі чытання/запісы будуць перанакіраваны на data-рэсурсы. Бліжэйшы аналаг diskless-рэсурсам – гэта iSCSI LUN.

Кожны DRBD-рэсурс можа мець да 8 рэплік, і толькі адзін з іх па змаўчанні можа быць актыўным. Першасны, усе астатнія будуць з'яўляцца Другасны і іх выкарыстанне будзе немагчыма да таго часу, пакуль ёсць хаця б адзін Primary, гэта значыць яны проста будуць рэплікаваць дадзеныя паміж ссобай.

Мантуючы DRBD-прылада ў сістэму, яно аўтаматычна становіцца Першасны, Такім чынам нават Diskless-рэсурс, у тэрміналогіі DRBD, можа быць Primary.

Дык навошта патрэбен Linstor?

Давяраючы ўсе рэсурсаёмістыя задачы ядру, Linstor у сутнасці ўяўляе сабою звычайнае Java-прыкладанне якое дазваляе без працы аўтаматызаваць стварэнне DRBD-рэсурсаў.
Пры гэтым кожны створаны ім рэсурс будзе ўяўляць сабой незалежны DRBD-кластар, які працуе самастойна, нягледзячы на ​​стан control-plane і астатніх DRBD-рэсурсаў.

Linstor складаецца ўсяго з двух кампанентаў:

  • Linstor-controller - Асноўны кантролер, які дае API для стварэння і кіравання рэсурсамі. Ён таксама ж мае зносіны з сатэлітамі, правяраючы вольнае месца на іх, і адпраўляе заданні для стварэння і выдаленні новых рэсурсаў. Запускаецца ў адзінкавым экзэмпляры і выкарыстоўвае базу дадзеных, якая можа быць як унутранай (H2), так і вонкавай (PostgreSQL, MySQL, MariaDB)
  • Linstor-satellite - Усталёўваецца на ўсе storage-ноды і падае кантролеру інфармацыю аб вольнай прасторы, а гэтак жа выконвае задачы, атрыманыя ад кантролера, для стварэння і выдаленні новых тамоў і DRBD-прылад па-над імі.

Linstor аперуе наступнымі ключавымі паняццямі:

  • вузел - фізічны сервер, на якім будуць стварацца і выкарыстоўвацца DRBD-рэсурсы.
  • Басейн захоўвання - LVM або ZFS пул, створаны на нодзе ў якім будуць размяшчацца DRBD-рэсурсы. Гэтак жа магчымы diskless-пул - гэта пул у якім будуць размяшчацца толькі diskless-рэсурсы.
  • Resource Definition - Вызначэнне рэсурсу, па сутнасці гэта прататып які апісвае імя і ўсе яго ўласцівасці.
  • Volume Definition - Вызначэнне тома. Кожны рэсурс можа складацца з некалькіх тамоў, кожны том мусіць мець памер.
  • Рэсурс - Створаны асобнік блокавага ўладкавання, кожны рэсурс павінен быць размешчаны на вызначанай нодзе і ў якім-небудзь storage pool.

Ўстаноўка Linstor

У якасці сістэмы рэкамендую выкарыстоўваць Ubuntu, т.я. для яе існуе гатовы PPA:

add-apt-repository ppa:linbit/linbit-drbd9-stack
apt-get update

Або Debian, дзе Linstor можна ўсталяваць з афіцыйнага рэпазітара для Proxmox:

wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
PVERS=5 && echo "deb http://packages.linbit.com/proxmox/ proxmox-$PVERS drbd-9.0" > 
    /etc/apt/sources.list.d/linbit.list
apt-get update

Кантролер

Тут усё проста:

apt-get install linstor-controller linstor-client
systemctl enable linstor-controller
systemctl start linstor-controller

Storage-ноды

У сапраўдны момант у ядры Linux пастаўляецца in-tree модуль ядра DRBD8, на жаль ён нам не падыходзіць і нам трэба ўсталяваць DRBD9:

apt-get install drbd-dkms

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

modprobe drbd
cat /proc/drbd

Калі ўбачыце версія: 9 - значыць усё ў парадку, калі версія: 8 - значыць нешта пайшло не так і вам неабходна распачаць дадатковыя дзеянні для высвятлення прычын.

Цяпер усталюем linstor-satellite и drbd-utils:

apt-get install linstor-satellite drbd-utils
systemctl enable linstor-satellite
systemctl start linstor-satellite

Стварэнне кластара

Storage pools і ноды

У якасці бэкенда мы возьмем ThinLVM, т.я. ён найболей просты і падтрымлівае снапшоты.
Усталюйце м2, калі яшчэ гэтага не зрабілі і давайце створым ThinLVM pool на ўсіх нашых storage-нодах:

sudo vgcreate drbdpool /dev/sdb
sudo lvcreate -L 800G -T drbdpool/thinpool

Усе далейшыя дзеянні могуць выконвацца непасрэдна на кантролеры:

Дадамо нашы ноды:

linstor node create node1 127.0.0.11
linstor node create node2 127.0.0.12
linstor node create node3 127.0.0.13

Створым storage pools:

linstor storage-pool create lvmthin node1 data drbdpool/thinpool
linstor storage-pool create lvmthin node2 data drbdpool/thinpool
linstor storage-pool create lvmthin node3 data drbdpool/thinpool

Цяпер праверым створаныя пулы:

linstor storage-pool list

Калі ўсё выканана правільна, то мы павінны ўбачыць нешта накшталт:

+------------------------------------------------- -------------------------------------------------- ----+ | StoragePool | Node | Driver | PoolName | FreeCapacity | TotalCapacity | SupportsSnapshots | |------------------------------------------------- -------------------------------------------------- ----| | data | node1 | LVM_THIN | drbdpool/thinpool | 64 GiB | 64 GiB | true | | data | node2 | LVM_THIN | drbdpool/thinpool | 64 GiB | 64 GiB | true | | data | node3 | LVM_THIN | drbdpool/thinpool | 64 GiB | 64 GiB | true | +------------------------------------------------- -------------------------------------------------- ----+

DRBD-рэсурсы

Цяпер давайце паспрабуем стварыць наш новы DRBD-рэсурс:

linstor resource-definition create myres
linstor volume-definition create myres 1G
linstor resource create myres --auto-place 2

Праверым створаныя рэсурсы:

linstor resource list 

+------------------------------------------------- -------------------------------------------------- ---+ | Node | Resource | StoragePool | VolumeNr | MinorNr | DeviceName | Allocated | InUse | State | |------------------------------------------------- -------------------------------------------------- ---| | node1 | myres | data | 0 | 1084 | /dev/drbd1084 | 52 KiB | Unused | UpToDate | | node2 | myres | data | 0 | 1084 | /dev/drbd1084 | 52 KiB | Unused | UpToDate | +------------------------------------------------- -------------------------------------------------- ---+

Выдатна! - мы бачым, што рэсурс стварыўся на першых двух нодах, мы таксама можам паспрабаваць стварыць diskless-рэсурс на трэцяй:

linstor resource create --diskless node3 myres

На нодах вы заўсёды знойдзеце гэтую прыладу як /dev/drbd1084 або /dev/drbd/by-res/myres/0

Вось так працуе Linstor, вы можаце атрымаць больш інфармацыі з афіцыйнай дакументацыі.

Цяпер я раскажу пра тое як інтэграваць яго з OpenNebula

Настройка OpenNebula

Я не буду моцна паглыбляцца ў працэс наладкі OpenNebula, т.я. усе крокі дэталёва апісаны ў афіцыйнай дакументацыі, да якой і рэкамендую вам звярнуцца, раскажу толькі пра інтэграцыю OpenNebula з Linstor.

linstor_un

Для вырашэння гэтай задачы я напісаў уласны драйвер. linstor_un, на дадзены момант ён даступны ў выглядзе плагіна і павінен усталёўвацца асобна.

Уся ўстаноўка ажыццяўляецца на frontend OpenNebula-нодах і не патрабуе дадатковых дзеянняў на compute-нодах.

Перш за ўсё нам трэба пераканацца што мы маем jq и linstor-client:

apt-get install jq linstor-client

Каманда linstor node list павінна выводзіць спіс нод. Усе compute-ноды OpenNebula павінны быць дададзены ў кластар Linstor.

Спампуем і ўсталюем убудову:

curl -L https://github.com/OpenNebula/addon-linstor_un/archive/master.tar.gz | tar -xzvf - -C /tmp

mv /tmp/addon-linstor_un-master/vmm/kvm/* /var/lib/one/remotes/vmm/kvm/

mkdir -p /var/lib/one/remotes/etc/datastore/linstor_un
mv /tmp/addon-linstor_un-master/datastore/linstor_un/linstor_un.conf /var/lib/one/remotes/etc/datastore/linstor_un/linstor_un.conf

mv /tmp/addon-linstor_un-master/datastore/linstor_un /var/lib/one/remotes/datastore/linstor_un
mv /tmp/addon-linstor_un-master/tm/linstor_un /var/lib/one/remotes/tm/linstor_un

rm -rf /tmp/addon-linstor_un-master

Цяпер нам трэба дадаць яго ў канфіг OpenNebula, для гэтага выконваем нескладаныя крокі апісаныя тут.

Пасля чаго перазапусцім OpenNebula:

systemctl restart opennebula

І дадамо нашы datastores, сістэмнае:

cat > system-ds.conf <<EOT
NAME="linstor-system"
TYPE="SYSTEM_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
CLONE_MODE="snapshot"
CHECKPOINT_AUTO_PLACE="1"
BRIDGE_LIST="node1 node2 node3"
TM_MAD="linstor_un"
EOT

onedatastore create system-ds.conf

І сховішча выяў:

cat > images-ds.conf <<EOT
NAME="linstor-images"
TYPE="IMAGE_DS"
STORAGE_POOL="data"
AUTO_PLACE="2"
BRIDGE_LIST="node1 node2 node3"
DISK_TYPE="BLOCK"
DS_MAD="linstor_un"
TM_MAD="linstor_un"
EOT

onedatastore create images-ds.conf

  • Параметр AUTO_PLACE адлюстроўвае колькасць data-рэплік, якая будзе створана для кожнай новай выявы ў OpenNebula.
  • Параметр CLONE_MODE паказвае на тое, як менавіта будуць кланавацца выявы пры стварэнні новых віртуальных машын, snapshot - будзе ствараць снапшот выявы і з снапшота разгортваць віртуальную машыну, copy - будзе рабіць поўную копію выявы пад кожную віртуальную машыну.
  • В BRIDGE_LIST рэкамендуецца пазначыць усе ноды, якія будуць выкарыстоўвацца для выканання аперацый па кланаванні вобразаў.

Поўны спіс падтрымліваемых параметраў прыведзены ў README праекта.

На гэтым налада завершана, зараз можна загрузіць які-небудзь appliance з афіцыйнага OpenNebula Marketplace і стварыць віртуальныя машыны з яго.

Спасылка на праект:
https://github.com/OpenNebula/addon-linstor_un

Крыніца: habr.com

Дадаць каментар