Red Hat 7.x / CentOS 7.x
Zarządzanie targetami iSCSI w wersji 7 odbywa się poprzez narzędzie
targetcli. Narzędzie jest rozbudowane i możemy przy jego pomocy zarządzać kilkoma rodzajami storage'u onlineowego (o innych rodzajach może w przyszłości).
Realizację zadania rozpoczniemy oczywiście od instalacji i uruchomienia pakietu targetcli. Ważne, aby pamiętać o
systemctl enable - bez tego konfiguracja targetów nie będzie ładowana po restarcie systemu:
[root@server ~]# yum install targetcli
[root@server ~]# systemctl enable target
Created symlink from /etc/systemd/system/multi-user.target.wants/target.service to /usr/lib/systemd/system/target.service.
[root@server ~]# systemctl start target
Narzędzie udostępnia nam swoistą powłokę, w ramach której operujemy na naszych udziałach dyskowych. Wywołanie go daje taki oto efekt:
[root@server ~]# targetcli
targetcli shell version 2.1.fb41
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
/>
Na pierwszy rzut oka powłaka wydaje się być dziwna, ale z jej poziomu możemy wywołać helpa - i tu niespodzianka, help jest ciekawie zorganizowany - zależnie od poziomu drzewa help wyświetla opcje specyficzne dla tej właśnie lokalizacji.
Powłoka przedstawia nam w formie hierarchicznej konfigurację storage'ów możliwych do skonfigurowania. Część z nich jest dostępna jedynie, w przypadku kiedy wspierający rozwiązanie hardware jest obecny w naszym systemie. Inne znich są dostępne zawsze.
Poruszanie się po drzewie odbywa się analogicznie do poruszania w systemie -
ls i
cd.
[root@server ~]# targetcli
targetcli shell version 2.1.fb41
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
/> ls
o- / ..................................................................... [...]
o- backstores .......................................................... [...]
| o- block .............................................. [Storage Objects: 0]
| o- fileio ............................................. [Storage Objects: 0]
| o- pscsi .............................................. [Storage Objects: 0]
| o- ramdisk ............................................ [Storage Objects: 0]
o- iscsi ........................................................ [Targets: 0]
o- loopback ..................................................... [Targets: 0]
/> cd iscsi
/iscsi> ls
o- iscsi .......................................................... [Targets: 0]
/iscsi>
Backstores
Udostępnianie powierzchni dyskowej dobrze jest rozpocząć od zdefiniowania tego, co i w jakiej ilości chcemy udostępniać. Obiekty takie - zwane
backstores możemy zdefiniować w oparciu o cztery komponenty:
-
block - to udostępnienie zwykłego urządzenia blokowego, które możemy znaleźć w katalogu
/sys/block (np. /dev/sdb)
-
fileio - to przestrzeń, którą zaalokujemy w pliku na naszym filesystemie (file I-O)
-
pscsi - to urządznie typu pass-through SCSI, czyli np. dysk SAS-owy
-
ramdisk - emulujące protokół SCSI na obszarze zarezerwowanym w pamięci RAM.
Tworzenie na podstawie każdego z typów rozpoczyna się identycznie - od przejścia do odpowiedniego "katalogu" w drzewie konsoli, czyli np. jeśli chcemy udostępnić powierzchnię 1GB, która fizycznie będzie się znajdować w pliku na naszym lokalnym dysku, skorzystamy z backstore'a typu fileio:
/> cd backstores/fileio
/backstores/fileio>
Wszystkie opcje dostępne w tej lokalizacji możemy podejrzeć poprzez polecenie
help, a detale komendy poprzez
help POLECENIE.
Jak łatwo wydedukować na podstawie takiego helpa, tworzenie backstore'a zrealizujemy poleceniem
create, który jako parametrów potrzebuje
nazwy i
lokalizacji pliku, w którym zostanie zaalokowany.
Niestety help zawiera pewną nieścisłość - zaznaczono tam parametr size jako opcjonalny, co może zostać źle zrozumiane. Jego opcjonalność polega bowiem na fakcie, że jest opcjonalny jedynie dla komendy create, przy czym jeśli create tworzyć ma backstore typu fileio, jest on wymagany, a jeśli tyczy się typu block należy go pominąć.
Opcjonalnymi parametrami komendy są:
-
write_back - przyjmujący parametr
true (domyślnie) jeśli chcemy korzystać z cache lokalnego filesystemu, lub false, jeśli chcemy operować w trybie write_thru. Tryb z włączonym write_back zwiększa co prawda wydajność, ale i możliwość utraty danych, które nie są zapisywane bezpośrednio na dysku.
-
sparse - to opcja używana jedynie w przypadku tworzenia nowych plików dla typu fileio - jeśli ustawiona jest na
true (domyślnie) fizyczna zajętość dysku będzie rosła wraz z ilością danych w pliku - wartość false zajmie zadeklarowaną powierzchnię na naszym filesystemie od razu. Efekt użycia może zaskoczyć - zmieścimy 20G plik sparse na dysku o pojemności 1G... oczywiście do czasu wykorzystania 1G w udostępnionym później iSCSI.
Stwórzmy zatem nasz backstore:
/backstores/fileio> create my_file_backstore /opt/my_file_backstore 1G write_back=false
Created fileio my_file_backstore with size 1073741824
/backstores/fileio> ls
o- fileio ........................................................... [Storage Objects: 1]
o- my_file_backstore .......... [/opt/my_file_backstore (1.0GiB) write-thru deactivated]
/backstores/fileio> cd ../..
/> ls
o- / ............................................................................... [...]
o- backstores .................................................................... [...]
| o- block ........................................................ [Storage Objects: 0]
| o- fileio ....................................................... [Storage Objects: 1]
| | o- my_file_backstore ...... [/opt/my_file_backstore (1.0GiB) write-thru deactivated]
| o- pscsi ........................................................ [Storage Objects: 0]
| o- ramdisk ...................................................... [Storage Objects: 0]
o- iscsi .................................................................. [Targets: 1]
| o- iqn.2003-01.org.linux-iscsi.server.x8664:sn.ca677b0f8d08 ................ [TPGs: 1]
| o- tpg1 ..................................................... [no-gen-acls, no-auth]
| o- acls ................................................................ [ACLs: 0]
| o- luns ................................................................ [LUNs: 0]
| o- portals .......................................................... [Portals: 1]
| o- 0.0.0.0:3260 ........................................................... [OK]
o- loopback ............................................................... [Targets: 0]
/>
Target
Target iSCSI możemy chyba z grubsza opisać jako nazwany obiekt, który dla zdefiniowanych odbiorców zewnętrznych (ip, acl) będzie udostępniał zasoby wewnętrzne serwera (backstore).
Tworzenie targetu iSCSI możemy zrealizować w 2 wariantach - z domyślną lub zdefiniowaną nazwą.
Pierwsza opcja polega po prostu na wydaniu wewnątrz "katalogu" iscsi polecenia:
/iscsi> create
Created target iqn.2003-01.org.linux-iscsi.server.x8664:sn.ca677b0f8d08.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
/iscsi> ls
o- iscsi .......................................................... [Targets: 1]
o- iqn.2003-01.org.linux-iscsi.server.x8664:sn.ca677b0f8d08 ........ [TPGs: 1]
o- tpg1 ............................................. [no-gen-acls, no-auth]
o- acls ........................................................ [ACLs: 0]
o- luns ........................................................ [LUNs: 0]
o- portals .................................................. [Portals: 1]
o- 0.0.0.0:3260 ................................................... [OK]
/iscsi>
Stworzenie targetu ze zdefiniowaną nazwą wygląda identycznie, z tym, że po poleceniu create podajemy ową nazwę, np:
create iqn.2016-03.server:moj.storage.
Definiowana przez nas nazwa musi być kwalifikowana jako IQN, NAA lub EUI.
TPG oraz iSCSI Portal
TPG, czyli Target Portal Groups pozwalają iSCSI korzystać w wielu konfiguracji w ramach jednego targetu. Jedna grupa TPG jest tworzona domyślnie przy kreowaniu targetu, i w większości przypadków będzie wystarczająca.
W ramach grupy TPG definiowane są tzw. portale, które definiują adres ip oraz port poprzez które target może zostać użyty. Domyślnie w ramach każdego TPG tworzony jest portal domyślny, udostępniający target poprzez wszystkie skonfigurowane adresy IP z użyciem portu 3260.
W przypadku, kiedy chcemy ograniczyć dostępność naszego targetu do jednego adresu skonfigurowanego na maszynie możemy utworzyć taki portal poprzez polecenie
create 192.168.1.1 6290 wydane w lokalizacji
iscsi/<idn_target>/tpg1/portals/.
LUN-y
Kiedy już wiemy gdzie będziemy udostępniać, przyszła kolej na skonfigurowanie co będziemy udostępniać, poprzez dowiązanie wcześniej ustawianych backstore'ów do naszego targetu.
Analogicznie do poprzednich kroków, konfiguracji dokonywać będziemy w "katalogu" z nazwą odpowiadającą zagadnieniu, a więc
luns w lokalizacji odpowiadającej naszemu targetowi, czyli
iscsi/<idn_target>/tpg1/.
Dowiązanienie backstore'a do targetu polega na wskazaniu go jako parametru polecenia create:
/iscsi/iqn.20...d08/tpg1/luns> create /backstores/fileio/my_file_backstore
Created LUN 0.
Szybkie sprawdzenie, czy lun się dowiązał:
/iscsi/iqn.20...d08/tpg1/luns> ls /
o- / ........................................................................................................ [...]
o- backstores ............................................................................................. [...]
| o- block ................................................................................. [Storage Objects: 0]
| o- fileio ................................................................................ [Storage Objects: 1]
| | o- my_file_backstore ................................. [/opt/my_file_backstore (1.0GiB) write-thru activated]
| o- pscsi ................................................................................. [Storage Objects: 0]
| o- ramdisk ............................................................................... [Storage Objects: 0]
o- iscsi ........................................................................................... [Targets: 1]
| o- iqn.2003-01.org.linux-iscsi.server.x8664:sn.ca677b0f8d08 ......................................... [TPGs: 1]
| o- tpg1 .............................................................................. [no-gen-acls, no-auth]
| o- acls ......................................................................................... [ACLs: 0]
| o- luns ......................................................................................... [LUNs: 1]
| | o- lun0 ............................................. [fileio/my_file_backstore (/opt/my_file_backstore)]
| o- portals ................................................................................... [Portals: 1]
| o- 0.0.0.0:3260 .................................................................................... [OK]
o- loopback ........................................................................................ [Targets: 0]
ACLe
Mamy co udostępnić, mamy adres pod którym będzie się to działo, powinniśmy teraz zadbać o to komu będziemy udostępniać.
Każdy klient, łączący się do naszego zasobu iSCSI posiadać powinien unikalną nazwę inicjatora. Nazwa ta może być znalezniona w pliku
/etc/iscsi/initiatorname.iscsi na maszynie klienta, a jej znajomość umożliwi nam konfigurację Access Control List dla danego zasobu.
[root@iscsi-client ~]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:ccfb1428b2a
Znając tą nazwę, możemy utworzyć odpowiedni wpis na naszej liście kontroli dostępu.
/iscsi/iqn.20...d08/tpg1/luns> cd ../acls
/iscsi/iqn.20...d08/tpg1/acls> create iqn.1994-05.com.redhat:ccfb1428b2a
Created Node ACL for iqn.1994-05.com.redhat:ccfb1428b2a
Created mapped LUN 0.
/iscsi/iqn.20...d08/tpg1/acls> ls
o- acls ................................................................................................. [ACLs: 1]
o- iqn.1994-05.com.redhat:ccfb1428b2a .......................................................... [Mapped LUNs: 1]
o- mapped_lun0 ........................................................... [lun0 fileio/my_file_backstore (rw)]
Usuwanie definicji
Nie było sensu pisać tego przy każdej pozycji, ponieważ usuwanie elementów konfiguracji w konsoli
targetcli zawsze wygląda tak samo.
1. Nawigujemy do lokalizacji odpowiadającej kategorii elementu, który chcemy usunąć
2. Wydajemy polecenie
delete nazwa_elementu_do_usuniecia (p.s. działa tabulator)
