iSCSI е протокол, който предоставя отдалечен директен достъп до физичиески или логически диск по такъв начин, че този отдалечен диск се припознава от операционната система, която го достъпва отдалечено, като локален.

Трябва да се направят следните важни уточения, относно използването на iSCSI:

• iSCSI е TCP-базиран протокол

  Това директно го обвързва с механизмите, част от TCP протокола, които контролират скоростта на обмен на данни в TCP сесия. Очевидно е, че ако ще се монтира отдалечено диск, то скоростта на достъп до него е от значение и тя трябва да бъде не само висока, но и девиацията ѝ, трябва да бъде контролирана и държана в поносими граници. Също така, оепрационната система на инициатора (този, който предоставя отдалечения достъп до диска), трябва да бъде настроена така, че да управлява възможно най-ефективно прочита от диска или записа (това включва и настройка на буферирането, използването на памет, MTU и др).

• в iSCSI няма стандартен протокол за криптиране на трафика от и до инициатора

  Най-добрият начин за пренос на iSCSI трафик в Интернет е транспортен IPsec. При него целият процес на криптиране/декриптиране и изчисляването на контролните суми на пакетите, става в ядрото. Използването на IPsec обаче изисква между двата участника в комуникацията да няма NAT (Network Address Translation), тъй като налагането на NAT е несъвместимо с принципа на работа на транспортния IPsec механизъм. Използването на NAT-T в IPsec не е ефективно в IPsec, защото създава UDP тунел, през който се пренася IP трафика. От друга страна, iSCSI може да използва SSL, чрез реверсивно проксиране. По този начин обект на криптиране и удостоверяване са само пакетите в TCP сесията, установена между клиента и инициатора. Тази схема на криптиране на трафика позволява и по-лесно да се идентифицира дадена сесия и да бъде приоритизирана като скорост и закъснение на пакетите.

• iSCSI оперира с физически и логически дялове или дискове и не е обвързан с файловите системи (съдържанието) върху тях

  Реално, само операционната система, която монтира отдалечено дяла (диска) се интересува от неговото съдържание. Инициаторът (този, който реално предоставя дяловете за отдалчен достъп) не взаимодейства със съдържанието. Той е само блокове мениджър. Това означава, че даден дял (диск) може да бъде криптиран така, че ключа за криптиране/декриптиране да е известен само на този, който ще го монтира отдалечено.

Защо проектът УНИТе се нуждае от протокола iSCSI:

• В много случаи, даден потребител на изчислителни ресурси няма да иска (а понякога няма да има и възможност), да копира и съхранява данните си върху файловите системи на HPC. Причината за това може да бъде различна - или масивите с данни са големи, или данните не бива да бъдат копирани поради конфиденциалността им. С помощта на iSCSI той може да игради свой инициатор и да монтира локално, в HPC инфраструктурата на УНИТе, отдалечения дял, който пък да се достъпва от софтуера за анализ и изчисления.

• В някои случаи данните, които ще бъдат генерирани в HPC са твърде много и файловете, които ги съдържат са големи и няма как да бъдат копирани. В този случай, тези данни могат да се поставят в отделен дисков масив и чрез iSCSI той да се предостави за отдалечен достъп на този, който е заинтересован от анализа на данните.

Важна бележка: iSCSI предоставя дял, който най-вероятно не може да бъде споделен (ако дялът е част от SAN, такава възможност съществува при определено условия). Т.е. няма как този диск да се монтира на повече от една система и всяка система да може да извършва записи върху него.

За примерите по-долу се предполага, че инициатора и клиента са изградени върху CentOS 7 или Scientific Linux 7. Лесно може да транслирате примерите към други дистрибуции.

Използвайте актуализирана и поддържана версия на CentOS 7 и Scientific Linux 7!

$ sudo yum install scsi-target-utils iscsi-initiator-utils

За да стартирате сървърския процес, чрез който да давате достъп на клиентите до деклрарираните iSCSI ресурси, трябва да изпълните:

$ sudo systemctl start tgtd

За да може tgtd да се стартира по време на зареждането на Linux системата, изпълнете:

$ sudo systemctl enable tgtd

ВНИМАНИЕ! Сървърския процес на tgtd слуша на порт 3260/tcp. Актуализирайте правилата за пакетна филтрация, за да допуснете трафик от и до този порт.

За да стартирате процеса на iscsid, чрез който да може да зареждате и използвате споделените iSCSI устройства, трябва да изпълните:

$ sudo systemctl start iscsid

За да може iscsid да се стартира по време на зареждането на Linux системата, изпълнете:

$ sudo systemctl enable iscsid

Преди да започнете с дефинирането на ресурса, убедете се, че услугата tgtd е активирана и работи:

$ sudo systemctl status tgtd

Създайте дефиниция за име на ресурса и неговия клас:

$ sudo tgtadm --lld iscsi --mode target --op new --tid 3 --targetname iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001

При задаване на името на ресурса (това е частта от командния ред, която стои след --targetname) имайте предвид следното:

• iqn

  Това е стандартен идентификатор в случая на iSCSI. Не задавайте друга стойност.

• 2019-07

  Това е дата, която е формално тази, на която домейн името, което стои след датата (името е наобратно), е започнало да бъде използвано за разполагане в него на iSCSI инициатори.

• bg.uni-sofia.unite.iscsi

  Това е формалното име на домейн, използвано за разполагане в него на iSCSI инициатори. Може и да е име на хост.

• unite.storage.001

  Това е формалното име на дяла (диска). Йерархията с точките, като тази, която е демонстрирана, не е задължителна, но води до по-лесното визуално намиране на ресурс в дълги списъци и конфигурационни файлове.

Локално, от гледна точка на инициатора, най-важния идентификатор в горния команден ред е числото, което седи след --tid. Това число е уникалния номер на iSCSI ресурса в системата на инициатора. За да се асоциира дял или диск към този ресурс, трябва да изпълните команден ред, който е подобен на следния:

$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 3 --lun 1 -b /dev/sda

Ако сега изпълните:

$ sudo tgt-admin -s

в резултата ще видите блок подобен на следния:

Target 3: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00030000
            SCSI SN: beaf30
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00030001
            SCSI SN: beaf31
            Size: 4000787 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sda
            Backing store flags: 
    Account information:
    ACL information:

в който се съдържа информация за създадения ресурс.

В случай, че искате вместо диск да споделите логически дял от LVM2, то командния ред по създаването на ресурса ще бъде следния (забележете указания път до устройството в термини на LVM2):

$ sudo tgtadm --lld iscsi --op new --mode logicalunit --tid 3 --lun 1 --backing-store /dev/unite/storage_001

Създайте потребител с име и парола, който ще може да достъпва този ресурс отдалечено (не е добра идея iSCSI ресурсите да могат да бъдат свободно монтирани отдалечено от всеки iSCSI клиент, без никакви рестрикции):

$sudo tgtadm --lld iscsi --op new --mode account --user unite.storage.001 --password very_complex_and_long_password

и асоциирайте потребителя с ресурса, като след --tid по-долу, зададете номера на iSCSI ресурса (който сте задали при дефинирането му):

$sudo tgtadm --lld iscsi --op bind --mode account --tid 3 --user unite.storage.001

Ако отново изпълните:

$ sudo tgt-admin -s

ще видите потребителя асоцииран към ресурса (вижте под "Account information"):

Target 3: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00020000
            SCSI SN: beaf20
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00020001
            SCSI SN: beaf21
            Size: 4000787 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: rdwr
            Backing store path: /dev/sda
            Backing store flags: 
    Account information:
        unite.storage.001
    ACL information:
        ALL

Допълнително, може да ограничите достъпа до ресурса и на база IP адрес на инициатора (поддържат се и IPv6 адреси):

$sudo  tgtadm --lld iscsi --mode target --op bind --tid 3 --initiator-address=192.168.0.106

и премахнете подразбиращото се правило (резрешава достъпа от инициратори с произволен IP адрес), на база на което ще може да бъде монтиран отдалечено ресурса:

$ sudo tgtadm --lld iscsi --mode target --op unbind --tid 3 --initiator-address=ALL

В този пример достъп до ресурса може да има само инициатор с IP адрес 192.168.0.106.

Ако и сега изпълните:

$ sudo tgt-admin -s

то ще видите IP адреса най-долу, под "ACL information".

ВНИМАНИЕ! Това, че инициаторът има зададения IP адрес за достъп не означава, все още не означава, че ще може да монтира отдалечено ресурса, ако не знае зададената към този ресурс парола за достъп.

Възмножно е да филтрирате достъпа и по iSCSI име на инициатора (клиента). В рамките на iSCSI протокола, клиентът има дефинирано при себе си специфично име, което представя пред iSCSI сървъра, когато иска да достъпи ресурс. Ако клиентът използва Linux, това име обикновено се деклрарира във файла /etc/iscsi/initiatorname.iscsi. Пример за такова име е например iqn.2019-07.bg.uni-sofia.unite.client001:31e6bbe299f. В случай, че желаете да направите така, че даден ресурс да бъде достъпен на база на това име (ако има зададена парола обаче, клиентът ще трябва да въведе и нея след това), може да използвате следния примерен команден ред:

$ sudo tgtadm --lld iscsi --mode target --op unbind --tid 3 --initiator-name=iqn.2019-07.bg.uni-sofia.unite.client001:31e6bbe299f

Изпълнете следния команден ред, за да запазите изградената то тук част от конфигурацията, която ще изгради деклрарирания ресурс, ако tgtd бъде рестартиран:

$ sudo tgt-admin --dump > /etc/tgt/conf.d/unite.storage.001.conf

Отворете файла /etc/tgt/conf.d/unite.storage.001.conf, премахнете от него всичко друго, освен тази част (XML елемента target):

<target iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001>
        backing-store /dev/sda
        incominguser unite.storage.001 PLEASE_CORRECT_THE_PASSWORD
        initiator-address 192.168.0.106
</target>

и въведете истинската парола за потребителя (т.е. заменете PLEASE_CORRECT_THE_PASSWORD с истинската парола)

<target iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001>
        backing-store /dev/sda
        incominguser unite.storage.001 very_complex_and_long_password
        initiator-address 192.168.0.106
</target>

Запазете промените във файла. Не е нужно да рестартирате tgtd, защото всички конфигурации, които извършвате с tgt-admin влизат в сила веднага.

Преди да опишете и монтирате ресурса, убедете се, че услугата iscsid е активирана и работи:

$ sudo systemctl status iscsid

Първата стъпка, преди да започнете с монтирането, е да проверите какви ресурси предлага дадения сървър:

$sudo iscsiadm -m discovery -t sendtargets -p iscsi.unite.uni-sofia.bg

В този команден ред трябва след -p да зададете името на сървъра или неговия IP адрес. Ако имате достъп до сървъра и се осъществява iSCSI протоколна комуникация, ще видите резултат, в който ще има списък с достъпните ресурси, като например:

192.168.123.12:3260,1 iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001
192.168.123.12:3260,1 iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.002
192.168.123.12:3260,1 iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.003
192.168.123.12:3260,1 iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.004

ВНИМАНИЕ! Ако в този списък не виждате ресурс, който би следвало да виждате, то най-вероятно вашия IP адрес (адреса на инициатора) не е добавен в списъка с допустими IP адреси

В обясненията относно дефинирането на ресурс върху сървъра, е описано как се дефинира достъп до ресурс, на база IP адрес на инициатора.

Ако ресурса е защитен с потребителско име и парола, ще трябва да ги декларирате. За целта, влезте в директория /var/lib/iscsi/nodes и там ще видите поддиректория, чието име е името на хост на iSISI сървъра, списък с предоставяните ресурси от който, сте извели по горния пример. В рези директория, за всеки ресурс, ще имате поддиректория, а в нея файл с име default. Отворете този файл с текстов редактор:

$ sudo vi /var/lib/iscsi/nodes/iscsi.unite.uni-sofia.bg\,3260/iqn.2019-07.bg.uni-sofia.unite.iscsi\:unite.storage.001\,68.181.32.97\,3260\,1\,default/default

и намерете следния ред:

node.session.auth.authmethod = None

По подразбиране, при създаването на записите за ресурсите, се приема, че ресурсът не е защитен с парола. За това именно ще трябва да я добавите, като първо модифицирате вече коментирания ред:

node.session.auth.authmethod = CHAP

и добавите след него по един ред за името и паролата, спазвайки следния синтаксис:

node.session.auth.username = unite.storage.001
node.session.auth.password = very_complex_and_long_password

След това, може да пристъпите към монтирането на ресурса:

$ sudo iscsiadm -m node -T iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001 -p iscsi.unite.uni-sofia.bg -l

При успешно монтиране, ще видите съобщение подобно на следното:

Logging in to [iface: default, target: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001, portal: 192.168.123.12,3260] (multiple)
Login to [iface: default, target: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001, portal: 192.168.123.12,3260] successful.

Как да разберете като какво диското устройство се намира в системата монтирания отдалечен iSCSI ресурс? Прегледайте съдържанието на директорията /dev/disk/by-path:

$ ls -al /dev/disk/by-path

Там ще видите symlink обект, подобен на следния:

lrwxrwxrwx. 1 root root  9 Jul 23 17:11 ip-192.168.123.12:3260-iscsi-iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001-lun-1 -> ../../sdc

Тексът, оцветен в синьо, е наименованието на ресурса спрямо конвенцията, използвана от iSCSI.

Отделно, ако имате дялове в този диск, те ще изглеждат така:

lrwxrwxrwx. 1 root root  9 Jul 23 17:11 ip-192.168.123.12:3260-iscsi-iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001-lun-1-part1 -> ../../sdc1

При локално монтиране на дисков дял от подобно устройство се препоръчва да използвате името на symlink обекта от /dev/disk/by-path или UUID на файловата система, намираща се в дяла.

Не се опитвайте да използвате името устройството за дял в /dev. Ако следвате описанието в примера по-горе, не използвайте /dev/sdc или /dev/sdc1. Причината е, че при разместване на дисковите устройства или монтиране на други отдалечени iSCSI ресурси, тези имена на устройства може да се окажат различни след рестартирането на системата.

Преди да демонтирате отдалечен ресурс от инициатора, задължително проверете дали този ресурс не е монтиран в момента като локален диск, който в момента се използва. Ако в момента дисковото устройство, съответстващо на iSCSI ресурса не се използва, може да го демонтирате по начин подобен на този, използван за монтирането му, като в края вместо -l използвате --logout:

$ sudo iscsiadm -m node -T iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001 -p iscsi.unite.uni-sofia.bg --logout

При успешно демонтиране ще бъдат изведени съобщения, подобни на:

Logging out of session [sid: 38, target: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001, portal: 192.168.123.12,3260]
Logout of [sid: 38, target: iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001, portal: 192.168.123.12,3260] successful.

Много важно е да разберете, че не е нужно да описвате допълнително, в каквато и да е конфигурация, отдалеченото монтиране на iSCSI ресурса. В момента, в който го монтирате ръчно, както е показано по-горе в примерите:

$ sudo iscsiadm -m node -T iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001 -p iscsi.unite.uni-sofia.bg -l

се създава конфигурацията в /var/lib/iscsi/nodes/iscsi.unite.uni-sofia.bg\,3260/iqn.2019-07.bg.uni-sofia.unite.iscsi\:unite.storage.001\,192.168.123.12\,3260\,1\,default/default. Ако междувремено не демонтирате този ресурс (демонтирането е също описано по-горе) и iscsid е стартиран, то ресурсът ще бъде наличен и при зареждне на системата. Бъдете сигурни, че услугата iscsid е указана да бъде зареждана заедно със зареждането на системата:

$ sudo systemctl enable iscsid

Преди да започнете с описанието на монтирания ресурс в /etc/fstab, трябва ръчно да проверите дали ресурса е монтируем, следвайки инструкциите по-горе. Освен това, при зареждане на системата, тя трябва да има достъп до iSCSI сървъра, в противен случай може да се получи нежелано забавяне или провал на зареждането на системата.

ВНИМАНИЕ! Въздържайте се от поставяне на системни дялове като /boot и / върху iSCSI ресурси, освен ако нямате добра подготовка и опит в създаване и поддържане на бездискови системи.

За да монтирате отдалечен iSCSI ресурс използвайте UUID идентификатора на файловата система в дяла:

UUID=1cbe3761-466a-49ee-9fc3-2d4d9686e606 /storage xfs _netdev 0 0

или пътя до устройството в /dev/disk/by-path:

/dev/disk/by-path/ip-192.168.123.12:3260-iscsi-iqn.2019-07.bg.uni-sofia.unite.iscsi:unite.storage.001-lun-1-part1 /storage xfs _netdev 0 0