Czy są wśród nas tacy (tsefovodov), którzy nie lubią „zawodowej skrajności”?
Jest to mało prawdopodobne – w przeciwnym razie nie kręcilibyśmy się z tym niezwykle ciekawym i zabawnym produktem.
Wielu z tych, którzy byli zaangażowani w działanie Cepha, zetknęło się z niezbyt częstym (a raczej nawet bardzo rzadkim), ale czasami na żądanie - połączeniem Cepha przez iSCSI lub FC. Po co? Cóż, na przykład prześlij obraz z Ceph na serwer Windows lub Solaris, który z jakiegoś powodu nie został jeszcze zwirtualizowany. Albo zwirtualizowany, ale z hypervisorem, który nie obsługuje Ceph - a jak wiemy jest ich mnóstwo. Na przykład? Cóż, na przykład HyperV lub ESXi, które są aktywnie wykorzystywane. A jeśli pojawi się zadanie przesłania obrazu z Cepha na maszynę gościa, staje się to bardzo ekscytującym zadaniem.
Tak podane:
- już działający klaster Ceph
- już istniejący obraz, który musi być obsługiwany przez iSCSI
- Nazwa basenu mój basen, nazwa obrazu mój obraz
Zaczynać?
Przede wszystkim, gdy mówimy o FC czy iSCSI, mamy do czynienia z takimi podmiotami jak inicjator i cel. Cel jest w rzeczywistości serwerem, inicjatorem jest klient. Naszym zadaniem jest przesłanie obrazu Ceph inicjatorowi przy minimalnym wysiłku. Oznacza to, że musimy rozszerzyć cel. Ale gdzie, na jakim komputerze?
Na szczęście w klastrze Ceph mamy co najmniej jeden komponent, którego adres IP jest stały i na którym skonfigurowany jest jeden z najważniejszych komponentów Ceph, a tym komponentem jest monitor. W związku z tym instalujemy na monitorze cel iSCSI (i jednocześnie inicjator, przynajmniej na potrzeby testów). Zrobiłem to na CentOS, ale rozwiązanie nadaje się również dla każdej innej dystrybucji - wystarczy zainstalować pakiety w sposób akceptowalny w Twojej dystrybucji.
# yum -y install iscsi-initiator-utils targetcli
Jaki jest cel zainstalowanych pakietów?
- celcli — narzędzie do zarządzania obiektem docelowym SCSI wbudowane w jądro Linuksa
- iscsi-inicjator-utils — pakiet z narzędziami służącymi do zarządzania inicjatorem iSCSI wbudowanym w jądro Linuksa
Aby przesłać obraz poprzez iSCSI do inicjatora, istnieją dwie możliwości opracowania zdarzeń - skorzystaj z backendu przestrzeni użytkownika celu lub podłącz obraz jako urządzenie blokowe widoczne dla systemu operacyjnego i wyeksportuj go poprzez iSCSI. Pójdziemy drugą drogą - backend przestrzeni użytkownika jest wciąż w stanie „eksperymentalnym” i nieco nie jest gotowy do produktywnego użycia. Poza tym wiążą się z tym pułapki, o których można dużo rozmawiać i (och, o zgrozo!) się kłócić.
Jeśli użyjemy choćby w miarę stabilnej dystrybucji z długim cyklem wsparcia, to jądro, które mamy, będzie jakąś starożytną, starożytną wersją. Na przykład w CentOS7 jest to 3.10.*, w CentOS8 jest to 4.19. A nas interesuje jądro co najmniej 5.3 (a raczej 5.4) i nowsze. Dlaczego? Ponieważ domyślnie obrazy Ceph mają włączony zestaw opcji, które nie są kompatybilne ze starszymi jądrami. Oznacza to, że podłączamy repozytorium z nowym jądrem dla naszej dystrybucji (przykładowo dla CentOS-u jest to elrepo), instalujemy nowe jądro i restartujemy system, aby działał z nowym jądrem:
- Podłącz do monitora wybranego do eksperymentu
- Łączymy repozytoria elrepo zgodnie z instrukcją -
- Zainstaluj jądro: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Zrestartuj serwer z monitorem (mamy trzy monitory, prawda?)
Podłączenie obrazu jako urządzenie blokowe
# rbd map mypool/myimage
/dev/rbd0
Pozostaje tylko skonfigurować cel. W tym przykładzie skonfiguruję cel w tzw. tryb demo - bez uwierzytelniania, widoczny i dostępny dla każdego. W środowisku produkcyjnym prawdopodobnie będziesz chciał skonfigurować uwierzytelnianie, ale jest to trochę poza zakresem dzisiejszego ćwiczenia dla zabawy.
Utwórz backend o nazwie dysk1 powiązany z plikiem /dev/rbd/mypool/myimage. Podany plik jest dowiązaniem symbolicznym automatycznie tworzonym przez demona udev do /dev/rbd0. Używamy dowiązania symbolicznego, ponieważ nazwa urządzenia rbd może się zmieniać w zależności od kolejności, w jakiej obrazy Ceph są podłączone do hosta.
Utwórz backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Utwórz cel iSCSI:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Łączymy backend jako jednostkę LUN z celem:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Skonfigurujmy cel dla trybu demonstracyjnego:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribute cache_dynamic_acls=1
Zapisz konfigurację:
# targetcli saveconfig
Sprawdzanie obecności celu:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Łączymy cel:
# iscsiadm -m node --login
Logging in to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
Login to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] successful.
Jeśli wszystko zrobiłeś poprawnie, na serwerze pojawi się nowy dysk, który wygląda jak urządzenie SCSI, ale w rzeczywistości jest obrazem z Ceph, dostępnym poprzez obiekt docelowy iSCSI. Aby uniknąć problemów z uruchamianiem, lepiej usunąć podłączony dysk i wykryty cel z lokalnego inicjatora:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Pozostaje tylko utrwalić konfigurację, aby obraz został podłączony automatycznie, a po podłączeniu cel został rozwarstwiony. Wystrzelenie celu składa się z dwóch etapów – podłączenia RBD i faktycznego wystrzelenia celu.
Najpierw skonfigurujmy automatyczne połączenie obrazów RBD z hostem. Odbywa się to poprzez dodanie następujących wierszy do pliku /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Przywrócenie konfiguracji docelowej jest trochę bardziej skomplikowane - musimy napisać jednostkę dla systemd, która przywróci konfigurację:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Description=Start iSCSI target
After=network-online.target rbdmap.service
Before=remote-fs-pre.target
Wants=network-online.target remote-fs-pre.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/targetcli restoreconfig
[Install]
WantedBy=multi-user.target
# systemctl daemon-reload
# systemctl enable scsi-target
Ostatnim testem jest ponowne uruchomienie naszego monitora (jest to teraz obiekt docelowy iSCSI). Warto zaznaczyć, że gdybyśmy nie wyczyścili komendą bazy danych inicjatora iscsiadm -n Discoverydb -o usuń ... możesz skończyć z serwerem, który się nie ładuje lub ładowanie zajmuje dużo czasu.
Co zostało?
Skonfiguruj inicjator na serwerze, do którego chcemy wysłać cel.
Jak zapewnić odporność na uszkodzenia naszego celu?
W podobny sposób możesz skonfigurować cele na innych monitorach i ustawić wielościeżkę (vmware to zrozumie i nawet będzie działać, Hyper-V nie zrozumie - wymaga blokad SCSI). Ponieważ klient Ceph z jądra nie korzysta z buforowania, jest to całkiem wykonalne. Inną opcją jest utworzenie zasobu klastra składającego się z trzech komponentów — dedykowanego docelowego adresu IP oraz usług rbdmap i scsi-target, a następnie zarządzanie tym zasobem za pomocą narzędzi do klastrowania (kto powiedział rozrusznik?)
Zamiast posłowia
Jak widać, ten artykuł to trochę żart - ale starałem się w nim „szybko i na przykładach” omówić kilka dość popularnych tematów jednocześnie - cel iSCSI, który niekoniecznie musi eksportować obrazy Ceph - ale np. eksport woluminów LVM, podstawy pracy z inicjatorem iSCSI (jak przeskanować cel, jak połączyć się z celem, rozłączyć, usunąć wpis celu z bazy danych), napisać własną jednostkę dla systemd i kilka innych
Mam nadzieję, że nawet jeśli nie powtórzysz w całości całego eksperymentu, przynajmniej coś z tego artykułu Ci się przyda.
Źródło: www.habr.com