Czy wśród nas (cefowców) są tacy, którzy nie lubią „profesjonalnych ekstremów”?
Raczej nie — w przeciwnym razie nie zajmowalibyśmy się tym niezwykle interesującym i zabawnym produktem.
Wielu z tych, którzy zajmowali się eksploatacją Ceph, napotkało jeden rzadki (a wręcz bardzo rzadki), ale czasami potrzebny przypadek — podłączenie Ceph przez iSCSI lub FC. Po co? Na przykład, aby podać obraz z Ceph na z jakiegoś powodu niezwirtualizowany serwer Windows lub Solaris. Lub na zwirtualizowany, ale za pośrednictwem hiperwizora, który nie obsługuje Ceph — a takich, jak wiemy, jest pod dostatkiem. Na przykład? Cóż, na przykład HyperV lub ESXi, które są powszechnie używane. A jeśli pojawia się potrzeba podania obrazu z Ceph do maszyny wirtualnej, to staje się to dość interesującym zadaniem.
Zatem mamy:
- już działający klaster Ceph
- już istniejący obraz, który należy podać przez iSCSI
- Nazwa puli mypool, nazwa obrazu myimage
Zaczynamy?
Przede wszystkim, gdy mówimy o FC lub iSCSI, pojawiają się takie byty jak inicjator (initiator) i cel (target). Target to tak naprawdę serwer, inicjator — klient. Naszym zadaniem jest z minimalnym nakładem pracy podać obraz Ceph do inicjatora. A więc musimy rozwinąć target. Ale gdzie, na którym 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 na monitorze instalujemy iSCSI target (i inicjator na próbę, przynajmniej do testów). Robiłem to na CentOS, ale dla jakiejkolwiek innej dystrybucji rozwiązanie również pasuje — wystarczy po prostu instalować pakiety w sposób, który jest akceptowalny w Twojej dystrybucji.
# yum -y install iscsi-initiator-utils targetcli
Jakie jest przeznaczenie instalowanych pakietów?
- targetcli — narzędzie do zarządzania wbudowanym w jądro Linux SCSI-targetem
- iscsi-initiator-utils — pakiet z narzędziami używanymi do zarządzania również wbudowanym w jądro Linux iSCSI initiatorem
Aby przesłać obraz przez iSCSI do inicjatora, mamy dwie możliwości — użyć backendu targetu w użytkowej przestrzeni lub podłączyć obraz jako urządzenie blokowe widoczne dla systemu operacyjnego i eksportować go przez iSCSI. Wybierzemy drugą opcję — backend w użytkowej przestrzeni jest wciąż w stanie "eksperymentalnym" i nie jest jeszcze gotowy do produkcyjnego użytku. Ponadto wiążą się z nim pewne pułapki, o których można by długo dyskutować i (o zgrozo!) spierać się.
Jeśli korzystamy z stabilnej dystrybucji z długim cyklem wsparcia, to jądro ma bardzo starą wersję. Na przykład w CentOS7 jest to 3.10.*, a w CentOS8 4.19. Nas interesuje jądro co najmniej 5.3 (a właściwie 5.4) lub nowsze. Dlaczego? Ponieważ domyślnie obrazy w Ceph mają włączony zestaw opcji, które nie są kompatybilne ze starymi jądrami. To oznacza, że musimy podłączyć repozytorium z nowym jądrem dla naszej dystrybucji (na przykład dla CentOS to elrepo), zainstalować nowe jądro i zrestartować system, aby skorzystać z nowego jądra:
- Podłączamy się do wybranego monitora do eksperymentów
- Podłączamy repozytoria elrepo zgodnie z instrukcją —
- Instalujemy jądro: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Restartujemy serwer z monitorem (mamy przecież trzy monitory, prawda?)
Podłączamy obraz jako urządzenie blokowe
# rbd mapa mypool/myimage
/dev/rbd0
Pozostaje tylko skonfigurować target. W tym przykładzie skonfiguruję target w tzw. trybie demo — bez uwierzytelniania, widoczny i dostępny dla wszystkich. W środowisku produkcyjnym, prawdopodobnie, będziesz chciał skonfigurować uwierzytelnianie — ale to trochę poza zakresem dzisiejszych ćwiczeń.
Tworzymy backend o nazwie disk1 przypisany do pliku /dev/rbd/mypool/myimage. Wskazany plik to automatycznie utworzony przez demona udev dowiązanie symboliczne do /dev/rbd0. Używamy właśnie dowiązania symbolicznego, ponieważ nazwa urządzenia rbd może się zmienić w zależności od kolejności podłączania obrazów Ceph do hosta.
Tworzymy backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Tworzymy target iSCSI:
# targetcli /iscsi utwórz iqn.2020-01.demo.ceph:mypool
Podłączamy backend jako LUN do targetu:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Dostosowujemy target do trybu demo:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atrybut demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atrybut generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> atrybut cache_dynamic_acls=1
Zapisujemy konfigurację:
# targetcli saveconfig
Sprawdzamy dostępność targetu:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Podłączamy target:
# iscsiadm -m node --login
Logowanie do [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (wiele)
Logowanie do [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] zakończone sukcesem.
Jeśli wszystko zostało wykonane poprawnie, na serwerze pojawi się nowy dysk, który wygląda jak urządzenie SCSI, lecz w rzeczywistości jest obrazem z Ceph, do którego dostęp uzyskuje się przez iSCSI target. Aby uniknąć problemów przy uruchamianiu, lepiej usunąć podłączony dysk i wykryty target z lokalnego inicjatora:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Pozostało tylko zdefiniować konfigurację, aby obraz był automatycznie podłączany i po podłączeniu uruchamiał target. Uruchomienie targetu składa się z dwóch kroków — podłączenia RBD i faktycznego uruchomienia targetu.
Najpierw skonfigurujemy automatyczne podłączenie obrazów RBD do hosta. Robi się to, dodając wiersze do pliku /etc/ceph/rbdmap:
# kot /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Z przywróceniem konfiguracji targetu jest nieco trudniej — musimy napisać jednostkę dla systemd, która będzie przywracać konfigurację:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Opis=Uruchomienie celu iSCSI
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
Ostatni test — jeszcze raz uruchamiamy nasz monitor (który teraz jest iSCSI-targetem). Należy zauważyć, że gdybyśmy nie wyczyścili bazy inicjatora poleceniem iscsiadm -n discoverydb -o delete … moglibyśmy otrzymać serwer, który nie uruchamia się lub długo się uruchamia.
Co pozostało?
Skonfigurować inicjator na tym serwerze, na który chcemy podać target.
Jak zapewnić odporność na awarie naszego targetu?
Można podobnie skonfigurować targety na innych monitorach i zorganizować multipath (vmware to zrozumie i nawet będzie działać, Hyper-V nie zrozumie — tam wymagane są blokady SCSI). Ponieważ klient Ceph z jądra nie używa pamięci podręcznej, jest to w pełni działające. Inną opcją jest stworzenie klastra zasobów z trzech komponentów — dedykowanego adresy IP targetu oraz usług rbdmap i scsi-target, i zarządzanie tym zasobem za pomocą narzędzi klastrowania (kto powiedział pacemaker?)
Zamiast posłowia
Jak widać, ten artykuł to trochę żart — ale starałem się „szybko i na przykładach” omówić jednocześnie kilka dość popularnych tematów — iSCSI target, który niekoniecznie musi eksportować obrazy Ceph — ale na przykład eksportować wolumeny LVM, podstawy działania z inicjatorem iSCSI (jak przeskanować target, jak podłączyć się do targetu, odłączyć się, usunąć wpis o targetcie z bazy), pisanie własnej jednostki dla systemd i inne.
Mam nadzieję, że nawet jeśli nie powtórzysz całego tego eksperymentu w pełni, to przynajmniej coś z tego artykułu okaże się dla Ciebie użyteczne.
Źródło: habr.com
