[RH7] Tworzenie targetu iSCSI - targetcli

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)