Підключення і настройка iSCSI в Windows Server. Перетворюємо старий сервер в iSCSI Target за допомогою Enterprise Storage OS (ESOS) Підключення iscsi windows 7

Internet Small Computer System Interface (iSCSI) - це протокол передачі даних, призначений для обміну даними між серверами і системами зберігання даних (Storage Area Network, SAN). iSCSI вдає із себе комбінацію протоколу SCSI і стека протоколів TCP / IP і призначений для передачі блоків даних через мережі Ethernet. Керуючі команди SCSI передаються всередині IP-пакетів, а протокол TCP забезпечує управління потоком і надійність передачі даних.

При використанні iSCSI дані між сервером і системою зберігання передаються блоками, в необробленому вигляді. Це дозволяє використовувати SAN практично так само, як якщо б вони були підключені до сервера безпосередньо, а не через мережу. Хост-система може створювати на SAN логічні розділи, форматувати їх і використовувати як звичайні локальні жорсткі диски. У цьому полягає основна відмінність SAN від мережевих сховищ (Network Area Storage, NAS), які працюють на рівні файлової системи і використовують протоколи передачі файлів, такі як SMB або CIFS.

Технологія iSCSI була розроблена як більш дешева альтернатива Fibre Channel (FC). Системи на базі iSCSI підтримують стандартні протоколи і можуть бути побудовані на базі будь-якої існуючої мережевої інфраструктури, що підтримує протокол IP. Для роботи iSCSI може використовувати самі звичайні мережеві пристрої (комутатори, маршрутизатори, мережеві адаптери і т.п), тоді як для FC потрібні спеціальні HBA-адаптери, оптичні кабелі та інше дороге устаткування.

Архітектура iSCSI є клієнт-серверної і включає в себе наступні компоненти:

iSCSI Initiator- клієнтський компонент, який відправляє запити на підключення компоненту iSCSI Target, що знаходиться на стороні сервера. Ініціатор може бути реалізований програмно, у вигляді драйвера, або апаратно, у вигляді спеціального iSCSI адаптера.

iSCSI Target- серверний компонент, слухає клієнтські запити і забезпечує установку з'єднання між клієнтом і сервером iSCSI. Крім того, таргет пов'язаний з віртуальними дисками iSCSI, і після установки з'єднання все віртуальні диски, пов'язані з цим Таргет, стають доступні через ініціатор. Як iSCSI Target може виступати як спеціалізована СГД, так і звичайний Windows серверзі встановленою роллю iSCSI Target.

Віртуальні диски iSCSI -використовуються для розбиття дискового простору на логічні розділи (Logical Unit Number, LUN). У Windows Server 2012 iSCSI LUN вдають із себе звичайні віртуальні диски формату VHD \ VHDX. До речі, в Windows Server 2012 для iSCSI підтримувався тільки формат VHD, що ставило обмеження в 2ТБ на максимальний розмір LUN. У Windows Server 2012 R2 використовується формат VHDX, що дозволяє створювати LUN-и розміром до 64ТБ.

А тепер зупинимося і уточнимо деякі моменти:

На кожному iSCSI сервері може бути один або кілька iSCSI Target;
Кожен iSCSI Target може бути підключений до одного або кількох віртуальним дискам;
Кожен iSCSI Target може обслуговувати одне або кілька підключень від iSCSI Initiator;
У свою чергу, кожен iSCSI Initiator може підключатися до одного або декількох iSCSI Target і, отже, до одного або кількох віртуальним дискам.

Крім того, в Windows Server 2012 підтримується loopback-конфігурація, в якій і Target і Initiator можуть перебувати на одному і тому ж сервері.

В операційних системах Microsoft підтримка iSCSI з'явилася досить давно. Перша версія Microsoft iSCSI Initiator встановлювалася в якості окремого компонента в Windows 2000, Windows XP SP2 і Windows Server 2003 SP1, а починаючи з Windows Server 2008 і Vista iSCSI Initiator був вбудований в операційну систему.

Що стосується iSCSI Target, то спочатку він входив в спеціальну версію серверної ОС Windows Data Storage Server 2003, що була призначена для побудови систем зберігання і поставлялася тільки одним із попередньо встановлених вигляді. Однак з 2011 року компонент Microsoft iSCSI Software Target 3.3 став доступний для завантаження і установки на Windows Server 2008R2, а в Windows Server 2012 він повністю інтегрований в систему і встановлюється в якості ролі сервера.

На цьому закінчимо теоретичну частину і приступимо до практики. Для настройки візьмемо найпростіший варіант, в якості піддослідних використовуємо два сервера зі встановленою Windows Server 2012 R2: SRV2 для ролі iSCSI Target і SRV3 для iSCSI Initiator.

Запуск служби iSCSI Initiator

Для початку перевіримо стан служби ініціатора на SRV3. Для цього відкриваємо Server Manager і в меню «Tools» вибираємо пункт «iSCSI Initiator».

Як бачите, за замовчуванням служба не запущена. Натиснувши на «Yes» в діалоговому вікні, ми стартуємо службу iSCSI Initiator і поставимо її в режим автоматичного запуску.

Потім у вікні властивостей переходимо на вкладку «Configuration» і запам'ятовуємо значення IQN, воно стане в нагоді нам при налаштуванні сервера.

IQN (iSCSI qualified name) - це унікальний ідентифікатор, який призначається для кожного iSCSI Target і Initiator. IQN формується з дати (місяць і рік) реєстрації домену, офіційного імені домена, написаного в зворотному порядку і будь-якого довільного імені, наприклад імені сервера. Виходить приблизно так: iqn: 1991-05.com.microsoft: srv3.contoso.com

Стартувати сервіс iSCSI Initiator і встановити режим його запуску можна і з консолі PowerShell, наступними командами:

Start-Service msiscsi
Set-Service msiscsi -StartupType automatic

Установка ролі iSCSI Target Server

Тепер перейдемо на SRV2 і приступимо до налаштування серверної частини. Перше, що нам треба зробити - це встановити на сервер роль iSCSI Target. Відкриваємо Server Manager, переходимо по посиланню «Add roles and features»

І вибираємо роль «iSCSI Target Server», яка знаходиться в розділі File and Storage Services \ File and iSCSI Services.

Або скористаємося командою PowerShell:

Install-WindowsFeature -Name FS-iSCSITarget-Server

підготовка диска

Тепер підготуємо фізичний диск, який буде використовуватися для зберігання віртуальних iSCSI дисків. Спеціально для цієї мети до сервера підключений новий жорсткий диск розміром 120Гб. На даний момент диск неактивний (Offline). Для його активації в Server Manager переходимо в розділ File and Storage Services -> Disks, натискаємо на диску і переводимо його в Online.

Тепер на цьому диску треба створити новий розділ (або тому), для чого в контекстному меню вибираємо пункт New Volume.

Вибираємо фізичний диск, на якому буде створюватися тому

вказуємо розмір томи

і вибираємо букву диска.

Потім вибираємо для диска файлову систему, розмір сектора і вказуємо мітку тому. Тут нагадаю, що віртуальні диски iSCSI можна створювати тільки на томах NTFS, нова файлова система ReFS (Resilient File System) не підтримується.

Дивимося сумарну інформацію, і якщо все правильно, то тиснемо «Create», запускаючи створення томи.

Ті ж дії можна виконати за допомогою PowerShell. Знаходимо потрібний диск:

Get-Disk | where ($ _. OperationalStatus -eq "Offline")

Переводимо його в online:

Set-Disk -Number 1 -IsOffline $ false

ініціалізіруем:

Initialize-Disk -Number 1

Створюємо розділ:

New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter D

І форматіруем його в NTFS:

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "iSCSI Storage"

Створення віртуальних дисків iSCSI

Наступним пунктом нашої програми йде створення віртуальних iSCSI дисків. Для цього переходимо в розділ iSCSI і натискаємо по посиланню, запускаючи черговий майстер.

Вибираємо тому, на якому буде зберігатися віртуальний диск.

Даємо диску ім'я і опис.

Вказуємо розмір віртуального диска і його тип. Вибирати можна з трьох варіантів:

Fixed size (фіксованого розміру) - створюваний дисквідразу займає весь виділений обсяг. Це найбільш продуктивний, але найменш економічний варіант;
Dynamically expanding (динамічно розширюваний) - спочатку створюється диск мінімального розміру, який потім динамічно змінюється в залежності від кількості записаних на нього даних. Найкращий варіант у плані використання дискового простору;
Differencing (різницевий) - в цьому варіанті потрібно вказати розташування батьківського диска, з яким буде пов'язаний створюваний диск. Різницевий диск може бути як фіксованим, так і динамічним, в залежності від типу батька. У цього типу дисків є свої переваги, але використовувати їх для iSCSI особисто я особливого сенсу не бачу.

Тепер потрібно вказати iSCSI Target, до якого буде підключений даний диск. Оскільки на сервері не створено жодного таргета, вибираємо «New iSCSI target».

Даємо таргету ім'я і опис.

І вказуємо сервера, які можуть отримати до нього доступ.

При виборі серверів можна скористатися двома способами. Якщо ініціатор знаходиться на Windows Server 2012 або Windows 8, то можна просто натиснути «Browse» і вибрати потрібний сервер зі списку. Для більш старих систем треба вручну ввести ідентифікатор сервера. В якості ідентифікатора можна вказати IQN ініціатора, DNS ім'я або IP-адресу сервера, або MAC-адресу мережевого адаптера.

Йдемо далі. На наступній сторінці можна налаштувати аутентифікацію по протоколу CHAP між серверами. CHAP (Challenge Handshake Authentication Protocol) - це протокол для перевірки справжності партнера по підключенню, заснований на використанні загального пароля або секрету. Для iSCSI можна задіяти як односторонню, так і двосторонню (reverse) перевірку автентичності CHAP.

Перевіряємо правильність налаштувань і запускаємо створення диска.

Спробуємо зробити все те ж за допомогою PowerShell. Створимо ще один віртуальний iSCSI диск на 20ГБ командою:

New-IscsiVirtualDisk -Path D: \ iSCSIVirtualDisks \ iSCSI2.vhdx

Зверніть увагу, що за замовчуванням створюється динамічний диск, для створення VHD фіксованого розміру треба скористатися ключем -UseFixed.

Тепер створюємо другий iSCSI Target c ім'ям iscsi-target-2 і в якості сервера доступу вкажемо IQN SRV3:

New-IscsiServerTarget -TargetName iscsi-target-2 -InitiatorIds "IQN: iqn.1991-05.com.microsoft: srv3.contoso.com"

І перевіримо результат командою:

Get-IscsiServerTarget | fl TargetName, LunMappings

підключення

Повертаємося на SRV2, відкриваємо вікно властивостей ініціатора, переходимо на вкладку Discovery і тиснемо кнопку Discover Portal.

Вводимо ім'я або IP-адресу порталу і тиснемо ОК.

За замовчуванням iSCSI використовує всі доступні IP-адреси, і якщо ви хочете, щоб трафік iSCSI йшов тільки через певний мережевий інтерфейс, то треба перейти в розширені налаштування і в поле «Connect using» і вибрати IP.

Тепер переходимо на вкладку Targets, де повинні відобразитися всі доступні для підключення iSCSI Target. Вибираємо потрібний таргет і тиснемо «Connect».

Не забудьте зазначити чекбокс «Add this connection to the list of Favorite Targets», який забезпечує автоматичне підключення до таргету при виключенні або перезавантаження машини.

Підключення відбулося, і якщо відкрити оснастку управління дисками, то там з'явиться новий диск. Далі з цим диском чинимо так само, як зі звичайним жорстким диском, підключеним локально - переводимо в Online, инициализируем, створюємо на ньому розділи і форматіруем.

Те ж саме можна виконати за допомогою PowerShell. Виводимо список доступних Таргет:

Get-IscsiTarget | fl

І підключаємося до потрібного:

Connect-IscsiTarget -NodeAddress "iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target" -IsPersistent $ true

ключ -IsPersistent $ trueзабезпечує автоматичне підключення при виключенні або перезавантаження.

Ну і для відключення можна скористатися командою Disconnect-IscsiTarge, ось так:

Disconnect-IscsiTarget -NodeAddress "iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target" -Confirm: $ false

висновок

На цьому настройка завершена. Як я говорив, це найпростіший, базовий варіант настройки сховища. У iSCSI є ще багато цікавих можливостей. Наприклад, можна використовувати службу імен iSCSI (iSNS) для простоти управління, багатоколійні введення-виведення (MPIO) для забезпечення відмовостійкості, а для безпеки налаштувати аутентифікацію по протоколу CHAP і шифрування трафіку за допомогою IPSec. Про деякі з цих фич я планую написати в наступних статтях.

І на закінчення важливі моменти, які треба врахувати при організації системи зберігання iSCSI:

Розгортати iSCSI бажано в швидкої мережі, не нижче Gigabit Ethernet;
Мережевий трафік iSCSI рекомендується відокремити від решти трафіку і винести в окрему мережу, наприклад за допомогою VLAN або фізичного поділу на підмережі;
Для забезпечення високої доступності на мережевому рівні необхідно використовувати технологію MPIO, або сеанси з декількома підключеннями (MCS). Об'єднання мережевих адаптерів (NIC Teaming) для підключення до пристроїв зберігання iSCSI не підтримує;
При використанні технології Storage Spaces можна зберігати віртуальні диски iSCSI на Storage Spaces, але не можна використовувати LUN-и iSCSI для створення Storage Spaces;
Для зберігання віртуальних дисків iSCSI можна використовувати загальні кластерні томи CSV (Cluster Shared Volume).

Продовжуючи тему корисного використання старого серверного обладнання, На цей раз поговоримо про використання сервера моделі IBM System x3200 4362в якості мережевого сховища, доступного по протоколу iSCSIв якості iSCSI Target. В ми вже розглядали такий сервер в ролі сховища резервних копій віртуальних машин з програмної Дедуплікація від Quadstor . Однак в нашому випадку ситуація ускладнилася тим, що на деяких віддалених майданчиках, де була розгорнута , Віртуальні машини, що були піддані резервного копіювання, з часом отримали додатковий дискпід зберігання контенту для точки розповсюдження SCCM . А, як відомо, вміст дисків, які використовуються під поширення контенту в SCCM може часом дуже активно змінюватися (завантажуються нові оновлення , Видаляються прострочені поновлення, завантажується якесь ПО для розгортання і т.п.). Тому, з огляду на ту обставину, що використовуване ПЗ Veeam Backup Free Editionне дозволяє виключати з резервної копіївіртуальних машини окремі віртуальні диски, що належать цій ВМ, довелося вирішувати питання про збільшення дискового простору на цих самих серверах IBM. Паралельно постало питання про корисність дедуплікаціі, яка в разі часто мінливий контенту втрачає свій ККД.

"Вишенькою на торті" в описаній ситуації стало те, що в сервері, який використовується в нашому випадку в якості iSCSI Target (з реалізації Quadstor), дуже скромна дискова кошик - всього 4 слота SAS / SATA форм-фактора 3.5 ", два з яких зайняті під хостовую ОС Linux.

Тут ми розглянемо один з можливих варіантів вирішення сукупності описаних проблем і обмежень, який полягає в заміні повноцінної інсталяції ОС Linux на завантаження з USB-накопичувача і працює в оперативній пам'яті спеціалізованийLinux-дистрибутив проекту Enterprise Storage OS (ESOS). За своєю суттю ESOS це оптимізоване під роботу в ОЗУ сучасне Linux-ядро з інтегрованим ПЗ проекту , Приклад використання якого, ми вже .

Загальний план заходів буде виглядати так:

• Прибираємо з дисковою кошика диски малої ємності, на яких встановлена ​​хостової ОС, і ставимо на це місце диски більшої ємності (всі диски в кошику стануть однакової ємності)
• На рівні апаратного RAID-контролера визначаємо кожен з чотирьох дисків, підключених до дискової кошику, як самостійний пристрій.
• Готуємо завантажувальний USB-накопичувач з ESOS
• Завантажуємо сервер з ESOS і створюємо програмний RAID-масив з усіх дисків кошика.
• Конфігуріруем в ESOS iSCSI Target і підключаємо диск на стороні сервера iSCSI Initiator
• Налаштовуємо додаткове підключення до мережі між серверами і включаємо Multipath

конфігурація серверів

У нашому прикладі буде розглянуто побудову найпростішої конфігурації з використання iSCSIз двох серверів, один з яких виконує роль цілі iSCSI Targetна базі ESOS v 1.3.5, А інший виконує роль хоста-ініціатора iSCSI Initiatorна базі Windows Server 2012 R2. Для поліпшення доступності та продуктивності між метою і хостом-ініціатором буде організовано багатоколійні підключення ( multi-path). Для відділення трафіку iSCSI від трафіку управління серверами в кожен сервер встановлений додатковий двох-портовий мережний адаптер.

1 ) Сервер під роль iSCSI Target(KOM-AD01-ESOS01)

сервер моделі IBM System x3200 4362з дисковою кошиком на 4 диска LFF HDD SAS / SATA і додатково встановленим мережним адаптером HP NC380T PCI Express Dual Port Multifunction Gigabit Server Adapter (394795-B21). На цьому сервері буде виконуватися завантажується з USB-накопичувача система ESOS. Всі 4 диска з дисковою кошика сервера будуть використані в ESOS для організації програмного RAID-масиву, який в свою чергу буде презентовано на хост-ініціатор.

2 ) Сервер під роль iSCSI Initiator (KOM-AD01-VM01)

сервер моделі HP ProLiant DL380 G5, Що виконує роль хоста віртуалізації Hyper-V на базі ОС Windows Server 2012 R2 Standard. Крім базової комплектації в сервер додатково встановлено мережевий адаптер HP NC380T PCI Express Dual Port Multifunction Gigabit Server Adapter (394795-B21). Підключається до даного сервера з сервера ESOS по протоколу iSCSI диск буде використовуватися під завдання резервного копіювання віртуальних машин Hyper-V.

Найпростіша схема підключення мережевих інтерфейсів серверів буде виглядати наступним чином:

Конфігурація RAID-контролера на сервері IBM

Безвідносно використовуваної в нашому випадку моделі сервера і RAID-контролера, можна сказати, що використання дистрибутива ESOS, що не потребує для своєї роботи виділеного диска, в будь-дискової конфігурації дозволить використовувати під корисний дисковий обсяг всі ресурси дискової кошика. У деяких ситуаціях цей аргумент може мати суттєве значення.

У нашому прикладі в дискову кошик встановлено 4 однакових диска SATA 7200 1TB.

Для того, щоб відв'язати себе від вельми скромних можливостей апаратного RAID-контролера, яким оснащений наш сервер, і в подальшому скористатися можливостями побудови програмного RAID-масиву на базі ESOS, нам буде потрібно, щоб для ESOS кожен диск виглядав, як окрема фізична пристрій. Тому під вбудованої утиліти управління RAID-контролером видаляємо всі наявні логічні RAID-диски, щоб кожен диск був представлений як окремий пристрій.

Деякі RAID-контролери, наприклад HP Smart Array, не дозволяють транслювати підключені диски, як самостійні носії пам'яті. У таких випадках потрібно створити окремий том RAID-0 для кожного окремо взятого диска. У нашому випадку все простіше, так як встановлений в нашому сервері контролер LSI Logic SAS1064ETдосить примітивний і показує все диски, як окремі пристрої, якщо ці диски не включені в апаратний RAID-масив.

Підготовка завантажувального USB-накопичувача ESOS

Завантажуємо останню актуальну версію ESOS стабільної гілки (branch 1.x.x) зі сторінки проекту ESOS - Package Downloads . На цій же сторінці можна знайти опис інших гілок ESOS (master - розробляється і 0.1.x - застаріла).

В процесі написання цієї статті використовувалася версія 1.3.5 (25.01.2018 ), Доступна по посиланню esos-1.3.5.zip . До моменту публікації мені вже вдалося попрацювати з більш новою версією 1.3.6 (12.04.2018).

Так як ESOS, це орієнтована на ОЗУ система, запускатися вона буде з підключається через звичайний USB-порт зовнішнього накопичувача. Тобто нам потрібно USB-накопичувач розміром від 4GBі більше. Якщо Ви плануєте використовувати гілку master branch, то для успішного оновлення між версіями, згідно рекомендацій документа Upgrading , На USB-накопичувачі може знадобитися до 5GB додаткового простору. У нашому випадку для ESOS успішно використовувалися накопичувачі різного ступеня "підвальних" розміром від 8GB і більше.

Облікові дані, використовувані за замовчуванням:

• Ім'я користувача: root
• пароль: esos

При вході в систему автоматично запускається спеціальна оболонка Text-based User Interface (TUI), Максимально спрощує роботу з системою. У верхній області TUI є основне функціональне меню, яке дозволяє виконувати всі основні завдання по конфігурації сервера в якості сховища для мереж SAN.

Першочерговими завданнями початкової настройки є зміна стандартного пароля користувача rootі настройка мережі, для можливості віддаленої роботи з системою.

Переходимо до пунктів меню System > Change Passwordі задаємо новий пароль для користувача root.

Потім перейдемо в System > Network Settingsі виберемо пункт настройки основних параметрів мережі General Network Settings

У формі вкажемо ім'я хоста, ім'я DNS-домену, IP адреса шлюзу та адреси DNS-серверів.

Після зміни мережевих налаштувань, ESOS буде пропонувати перезавантаження служби мережі, для вступу внесених зміни в силу. Поки ми не справили всіх мінімальних налаштувань мережі, можемо відмовитися від рестарту служби мережі.

Знову повернемося в System > Network Settings, Виберемо мережевий адаптер, який буде використовуватися для віддаленого управління ESOS і налаштуємо параметри IP. У нашому прикладі використовується статична конфігурація і інтерфейсу управління ESOS заданий IP адреса 10.1.2.201/24. Маску мережі і адресу широкомовлення, як я зрозумів, вказувати обов'язково, інакше при збереженні налаштувань можуть виникати помилки.

Після збереження зроблених змін ми знову отримаємо питання про перезавантаження мережі. Тепер на це питання відповімо ствердно.

Мережа буде перезапущено і, в разі успішного застосування заданих параметрів, у нас з'явиться можливість віддаленого підключення до ESOS по протоколу SSH.

В рамках цієї замітки, ми пропускаємо інші настройки, наявні в ESOS, такі як налаштування часу, конфігурація відсилання пошти, управління додатковими користувачами і т.д. Замість цього ми зосередимося лише на тих моментах, які мають значення в контексті нашого завдання. Проте, перш ніж підключатися до нашого сервера ESOS по протоколу SSH, мені хочеться зробити маленьке косметичний відступ щодо колірної схеми TUI.

В інтерфейсі TUI ESOS є дві колірних схеми - стандартна світла, витримана в блакитних і бірюзових тонах, що на скріншотах вище, і альтернативна - темна, витримана в кращих традиціях "підземелля зі свічкою". Ні той, ні інший варіант, на мій погляд, вдалими не є, так як при віддаленому підключенні до консолі сервера при зниженій передачі кольору (наприклад при підключенні через функцію ), В деяких місцях TUI спостерігається ефект зливається з фоном тексту. А якщо підключатися до TUI ESOS SSH-клієнтом PuTTy з Windows-системи, то стандартні колірні схеми взагалі перетворюються, на мій погляд, будь-що-то "кислотне".

Так як працювати з ESOS ми будемо в основному звичайно ж з використанням віддаленого SSH підключення, то, зокрема, для клієнта PuTTy є просте рішення - використання настроюються колірних схем на стороні SSH-клієнта на будь-який смак і колір. Приклади такого налаштування ми розглядали раніше в замітці . Далі, для роботи з ESOS через SSH ми будемо використовувати схему PuTTy - Twilight.

Створення програмного RAID-масиву в ESOS

Завершивши первинну базову настройку ESOS, переходимо до конфігурації дискової системи сервера. Виконаємо створення програмного RAID-масиву (реалізовано на базі Linux Software RAID/mdraid) З 4 наявних в нашому розпорядженні дисків. Для цього перейдемо в меню Software RAID > Add Array

У переліку доступних для включення в програмний RAID блокових пристроїв відзначимо диски, з яких будемо створювати RAID-масив.

Вибравши диски натиснемо Enter. Відкриється екран налаштування RAID-масиву. Дамо масиву ім'я в традиціях mdraid, наприклад md0. Виберемо рівень RAID (в нашому випадку це RAID5) і розмір блоку. У нашому випадку масив збирається під завдання резервного копіювання великих файлів дисків віртуальних машин, тому розмір блоку ми вибрали найбільший.

Після натискання кнопки OKбуде запущена процедура ініціалізації RAID-масиву. Переходимо в меню навігації в Software RAID > Linux MD Statusі перевіряємо статус створеного RAID-масиву.

Тут ми можемо дочекатися повного завершення побудови RAID-масиву, або можна продовжити настройку нашого сервера, так як фактично дискова ємність масиву нам уже доступна.

Конфігурація iSCSI Target

Щоб створену нами дискову ємність RAID-масиву можна було презентувати на хост віртуалізації по мережі по протоколу iSCSI, на сервері ESOS потрібно створити iSCSI Target. Для цього а меню навігації перейдемо в Targets > Add iSCSI Target. У формі створення мети вкажемо ім'я iSCSI Qualified Name (IQN).

У нашому випадку використано пропоноване за замовчуванням ім'я в форматі iqn.2018-03.esos.<имя сервера>: Єдиним, що я змінив в імені - прибрав двокрапка в кінці імені.

Після збереження інформація про цілі iSCSI Target з'явиться на головному екрані ESOS, але дана мета буде знаходиться у вимкненому стані.

Щоб активувати мета, перейдемо в меню навігації в Targets > Enable/Disable Target, Зі списку цілей виберемо щойно створену нами мета і поміняємо в її властивості Disabledна Enabled.

Переконаємося в тому, що на головному екрані TUI інформація про стан цілі змінилася.

З переліку режимів трансляції пристроїв, опис яких можна знайти в документі36_Devices_and_Mappings - SCST I / O Modes , Вибираємо цікавий для нас режим. У нашому прикладі використовується режим vdisk_blockio, Який забезпечує прямий доступ до блокових пристроїв і виключає використання проміжних механізмів кешування Linux.

Після вибору режиму відкриється вікно вибору можливих для цього режиму блокових пристроїв. Вибираємо наш RAID-масив.

Після цього відкриється форма настройки параметрів SCST для віртуального блочного пристрою vdisk_blockio. Зазначимо будь-яке коротке і зрозуміле нам ім'я пристрою. Це ім'я буде надалі відображатися на стороні хоста віртуалізації, що виконує роль iSCSI Initiator, в диспетчері пристроїв. Тому в якості імені я використовував скорочене ім'я хоста і RAID-пристрої - ESOS01-MD0. Інші параметри можна залишити в значеннях за замовчуванням.

Зберігаємо налаштування віртуального блочного пристрою і переходимо до опису хостів, яким дозволено підключатися до створеної нами мети iSCSI Target. Але перш ніж описати хости, необхідно створити групу хостів. Переходимо в меню Hosts > Add Group

Вибираємо раніше створену нами мета iSCSI Target, до якої буде відноситься створювана група хостів.

Задаємо будь-яке ім'я групи хостів, наприклад Group1, і тиснемо Enter

Отже, група хостів створена і прив'язана до мети iSCSI Target. Тепер нам потрібно описати кожен хост, який буде виступати в якості iSCSI Initiatorз призначенням цього хоста на створену групу хостів. У нашому випадку такий хост буде всього один - наш хост віртуалізації Hyper-Vна базі ОС Windows Server 2012 R2.

Перш ніж додати в ESOS хост-ініціатор, з'ясуємо його ім'я Initiator Nameна нашому хості віртуалізації. Знайти (і при бажанні змінити) це ім'я можна в Панелі управління Windows Server, викликавши аплет iSCSI Initiatorі відкривши вкладку Configuration

Як бачимо, в нашому випадку ім'я хоста-ініціатора - iqn.1991-05.com.microsoft:kom-ad01-vm01.holding.com.

Повертаємося в TUI ESOS і додаємо хост-ініціатор в меню Hosts > Add Initiator

При цьому нас запитають до якої мети SCST Target відноситься додається хост. Вибираємо єдину раніше створену і включену нами мета.

Потім вибираємо створену раніше групу хостів, до якої буде прив'язаний додається хост-ініціатор.

І нарешті вводимо IQN хоста-ініціатора, яке ми з'ясували раніше, і тиснемо Enter

Отже, на даному етапі в ESOS ми вже маємо створену мета SCST (в нашому випадку iSCSI Target), маємо віртуальне блоковий пристрій SCST (транслюється програмний RAID-масив), нами описана група хостів і до цієї групи прив'язаний хост-ініціатор (iSCSI Initiator) . Тепер нам тільки залишається прімапіть віртуальне блоковий пристрій SCST до групи хостів. Для цього переходимо в меню навігації в Devices > Map to Host Group.

Вибираємо віртуальне блоковий пристрій SCST.

Вибираємо мета SCST.

Вибираємо групу хостів, в яку був включений хост-ініціатор.

Далі відкриється форма настройки LUN-а, який буде транслюватися в мережу. Зазначимо номер LUN-а (за замовчуванням першому транслюється LUN-у присвоюється номер 0) і збережемо налаштування, натиснувши ОК.

Подивитися підсумкову конфігурацію трансляції віртуальних пристроїв SCST можемо перейшовши в меню Devices > LUN/Group Layout

Тепер визначимося з відділенням мережевого трафіку iSCSI від трафіку управління самим сервером ESOS. Зробимо так, щоб повністю розділити ці види трафіку по різних мережних інтерфейсів.

Для цього налаштуємо на стороні сервера ESOS і на стороні клієнта iSCSI Initiator окремі мережеві інтерфейси з IP-адресацією відмінною від адресації, що використовується для управління серверами. Наприклад, в нашому випадку для управління серверами використовується мережу 10.1.2.0/24, тому для відділення трафіку iSCSI ми використовуємо невелику виділену підмережа на 6 хостів - 192.168.168.0/29 (на рівні мережного обладнання додатково можна ізолювати цю мережу в окремий VLAN).

Спочатку налаштуємо виділений під iSCSI мережевий інтерфейс на стороні сервера ESOS, перейшовши в меню навігації в System > Network Settingsі вибравши відповідний мережевий адаптер.

Задамо на цьому інтерфейсі статичний IP-адресу 192.168.168.1/29, вкажемо маску підмережі, адресу широкомовлення і збільшений розмір MTU- 9000 (технологія Jumbo Frameповинна підтримуватися мережевим адаптером) для поліпшення продуктивності при передачі великих обсягів даних.

При збереженні налаштувань на питання про перезавантаження мережі відповімо ствердно (всі мережеві з'єднання з ESOS будуть тимчасово втрачені).

По завершенню процедури перезавантаження мережі ми отримаємо зведену інформацію про статус застосування нових налаштувань

Тепер переходимо до налаштування на стороні хоста-ініціатора.

Конфігурація iSCSI Initiator

На стороні нашого хоста віртуалізації на базі Windows Server, на який ми будемо приймати по протоколу iSCSI дискову ємність з сервера ESOS, налаштуємо виділений мережевий адаптер для використання в роботі з протоколом iSCSI.

Відключимо все, крім того що може знадобитися нам на цьому виділеному інтерфейсі при роботі з iSCSI. Наприклад, залишимо тільки підтримку протоколу TCP/IPv4і QoS.

вибравши протокол TCP/IPv4по кнопці Propertiesзадамо IP-адреса з мережі, яку ми визначили під трафік iSCSI, наприклад 192.168.168.3/29. Адреса шлюзу і DNS-серверів залишаємо порожніми. Відкриємо розширені настройки кнопкою Advanced.

на вкладці DNSвідключимо включену за умовчанням опцію реєстрації в DNS, а на вкладці WINSвідключимо підтримку LMHOSTі NetBIOS over TCP/IP.

Повернемося на основну вкладку властивостей мережевого інтерфейсу і викличемо діалог налаштування параметрів мережевого адаптера по кнопці Configure.

У формі на вкладці розширених налаштувань Advancedзнайдемо опцію підтримки великих пакетів Jumbo Packetі виберемо максимально можливе значення (в нашому прикладі це 9014). на вкладці Power Managementвідключимо можливість відключення системою даного мережевого адаптера в режимах енергозбереження - Allow the computer to turn off this device to save mode.

Закриємо всі вікна зі збереженням кнопкою ОК.

Тепер перевіримо доступність сервера ESOS через виділений мережевий інтерфейс. спочатку утилітою tracert, Щоб переконатися в тому, що маршрутизація трафіку йде між серверами безпосередньо.

tracert -d 192.168.168.1

Потім за допомогою утиліти ping, Включивши прапор заборони фрагментації (опція - f) І вказавши розмір переданих пакетів (опція - l)

ping 192.168.168.1 -f -l 8000

У разі якщо десь, наприклад на комутаторі, до якого підключені сервери ESOS і наш хост-ініціатор, не включена підтримка Jumbo Frame, Ми можемо отримати повідомлення " Packet needs to be fragmented but DF set. "У нашому випадку перевірка пройшла успішно, тому можна переходити до процедури підключення iSCSI диска.

Перейдемо в Панель управління Windows Server, викличемо аплет iSCSI Initiatorі відкривши вкладку Discoveryнатиснемо кнопку Discover Portal. У вікні налаштувань виявлення вкажемо IP адреса сервера ESOS з мережі для трафіку iSCSI і натиснемо кнопку Advanced.

У формі розширених налаштувань виявлення в якості локального адаптера виберемо Microsoft iSCSI Initiatorі налаштований раніше IP адреса з мережі для трафіку iSCSI - 192.168.168.3. Збережемо настройки, натискаючи OKдо тих пір, поки не повернемося до головного вікна аплету.

Після цього перейдемо на вкладку Targets, Де в розділі Discovered targetsповинен з'явиться раніше згаданий IQNнашого сервера ESOS зі статусом Inactive. Тобто система його виявила, але він поки не підключений. Для того, щоб зробити підключення до iSCSI Target скористаємося кнопкою Connect.

У вікні підключення звернемо увагу на те, щоб був включений ознака додавання підключається мети в список обраних цілей - Add this connection to the list of Favorite Targets(Для подальшого автоматичного підключення до мети в разі перезавантаження сервера). натиснемо кнопку Advanced.

У формі розширених налаштувань підключення явно вкажемо мережеві інтерфейси з мережі для трафіку iSCSI, які повинні бути задіяні для передачі iSCSI трафіку для даного сесійного підключення. Тобто в якості Initiator IPвиберемо зі списку адресу виділеного на нашому хості iSCSI-інтерфейсу 192.168.168.3, а в якості Target portal IPвиберемо зі списку адресу виділеного на сервері ESOS iSCSI-інтерфейсу - 192.168.168.1.

Закриємо зі збереженням вікна Advanced Settingsі Connect to Targetі переконався в тому, що статус підключення змінився на Connected

Заглянемо на вкладку Favorite Targetsі переконаємося в тому, що підключена мета потрапила в список обраних.

Переконаємося в тому, що в консолі управління "Диспетчер пристроїв" / Device Manager (devmgmt.msc) в розділі Disk drivesз'явився додатковий SCSI-диск з ім'ям, яке раніше ми визначали на сервері ESOS для віртуального блочного пристрою SCST.

Наступним кроком нам потрібно виконати ініціалізацію підключеного по протоколу iSCSI диска. Для цього перейдемо в консоль управління дисками Disk Management (diskmgmt.msc), Виберемо відповідний диск і переведемо його в стан Online.

Після того як диск успішно змінить свій статус, проведемо ініціалізацію диска і відформатуємо його "до смаку", наприклад в файлову систему NTFS, задавши будь-яку зрозумілу нам мітку тому. З цього моменту в графічному інтерфейсі Windows даний диск стане нам доступний для стандартних файлових операцій.

На даному етапі, якщо ми заглянемо в консоль сервера ESOS, то побачимо в нижній частині TUI інформацію про сесії підключення хоста-ініціатора.

На цьому основну настройку найпростішої конфігурацією iSCSI можна вважати закінченою.

Найпростіша перевірка продуктивності

Після підключення диска по iSCSI бажано провести хоча б якісь нехитрі виміри продуктивності, щоб розуміти те, що у нас вийшло в кінцевому підсумку і то, чого можна очікувати від такого диска.

Покладатися на цифри, які при копіюванні великих файлів з локального диска сервера на iSCSI диск показує нам провідник Windows особливо не варто, так як об'єктивної інформації ми там не побачимо. Наприклад, в моєму випадку при копіюванні кількох великих ISO-файлів (з різним вмістом) швидкість позначилася в районі 150-160 MB / s, що відрізняється в більшу сторону від реальної допустимої швидкості iSCSI-линка між двома моїми серверами в 1Gbit / s (~ 125MB / s). До того ж більш-менш схожа на правду швидкість відображається при копіюванні першого файлу, а при копіюванні наступних файлів вона дещо збільшується (можливо включається в роботу кеш файлової системи та інші інші кеши різних рівнів).

Для різного роду вимірів завжди хочеться використовувати якісь "рідні" інструменти, які не потребують установки додаткового ПЗ, але на жаль це далеко не завжди можливо. У клієнтських системах Windows для оцінки продуктивності різних підсистем, в тому числі і дискової, використовується утиліта WinSAT ( winsat disk ), Проте в складі Windows Server 2012 R2 цієї утиліти я не виявив. Тому
я скопіював з наявною по рукою клієнтської ОС Windows 10 x64 два файли - WinSAT.exe і WinSATAPI.dll з каталогу% windir% \ System32 в аналогічний каталог сервера. Тепер можна спробувати скористатися цією програмою, запустивши її з командного рядка з правами адміністратора.

winsat disk -drive T -count 3

Тут після ключового слова diskв опції -drive вказується ім'я букви диска, який ми бажаємо протестувати, а в опції -count вказується кількість циклів тестування.

Як я зрозумів, дана утиліта не дозволяє проводити тестування оперуючи великими блоками даних (більш 1MB), тобто вона більше підходить для тестування ситуацій з великою кількістю дрібних файлів. У нас же ситуація зворотна - резервне копіювання дисків віртуальних машин припускають мала кількість файлів істотного розміру.

Ще одним простим інструментом є утиліта Diskspd(DiskSpd: A Robust Storage Performance Tool ), Яка прийшла на заміну утилітіSQLIO Disk Subsystem Benchmark Tool (SQLIO) . Викачуємо утиліту, розпаковуємо на сервері і запускаємо з набором параметрів, які відповідають контексту нашої задачі.

cd / d C: \ Tools \ Diskspd-v2.0.17 \ amd64fre \ Diskspd.exe -d60 -b1M -s -w100 -t1 -c100G T: \ io1.dat T: \ io2.dat

Використовувані нами параметри означають:
-d60: Час виконання тесту 60 секунд
-b1M: Оперувати блоками по 1MB
-s: Виконувати операції з послідовним доступом
-w100: Виконувати повний тест на запис (тест на читання не виконується)
-t1: Кількість потоків роботи з метою (з файлом T: \ io.dat)
-c100G: Створювати файли розміром 100GB
В кінці перераховані імена генеруються для тесту файлів.

Трохи відхиляючись, зазначу, що на момент написання статті для завдання резервного копіювання віртуальних машин Hyper-V у нас використовується ПО Veeam Backup & Replication , Тому при виборі розміру блоку для проведення тестів я буду відштовхуватися від специфіки цього ПО. Як я зрозумів з документаData Compression and Deduplication , VBR в операціях резервного копіювання на SAN використовує блоки по 1024MB, поему саме такий розмір блоку ми і будемо використовувати при тестуванні.

Для порівняння проведемо ще раз тест з тим же набором умов, але збільшимо його тривалість до 5 хвилин

Тут добре видно, що при тривалому навантаженні показники помітно просідають. Можу припустити, що пов'язано це з тим що "пляшкове горлечко" в цьому випадку переміщається з області мережевої підсистеми в область повільних дисків, що використовуються у нас на стороні сервера ESOS.

Для любителів графічних інструментів для проведення подібних поверхневих тестів продуктивності дискової підсистеми на Windows може стати в нагоді ще одна проста безкоштовна утиліта ATTO Disk Benchmark. Завантажити її можна за посиланням: Disk Benchmark . Інтерфейс утиліти простий і зрозумілий і коментувати по ній, мабуть, нічого.

Про якісь більш складних інструментах тестування, як наприклад IOMeter , Я не кажу, так як в рамках нашого завдання немає мети займатися бенчмарками як такими. А показники простих інструментів виходять лише для того, щоб мати базу для порівняння в подальшому, коли між сервером ESOS і хостом Hyper-V у нас буде не один лінк, як на даному етапі налаштування, а два лінка і задіяний механізм Multipath.

Налаштування Multipath

Отже, ми маємо підключений по iSCSI диск і деякі базові показники тестів продуктивності, від яких можемо відштовхуватися. Тепер спробуємо поліпшити ці показники, додавши на сервер ESOS і хост-ініціатор ще по одному гігабітного мережного адаптера і об'єднавши їх роботу за допомогою механізму Multipath на стороні хоста-ініціатора.

Почнемо з настройки сервера ESOS. У головному меню навігації перейдемо в System > Network Settings, Виберемо додатковий мережевий адаптер, який буде використовуватися для ще одного підключення по протоколу iSCSI і налаштуємо параметри IP. У нашому прикладі використовується статична конфігурація і додатковому iSCSI-інтерфейсу ESOS заданий IP адреса 192.168.168.2/29, а також додатково збільшений розмір MTU.

Зберігаємо налаштування мережі в ESOS і переходимо до налаштування додаткового мережевого адаптера на стороні хоста-ініціатора, тобто нашого сервера на базі Windows Server з iSCSI Initiator.

Налаштовуємо за аналогією з першим другий iSCSI-інтерфейс, задавши йому IP 192.168.168.4/29

Відключимо раніше налаштований інтерфейс c адресою 192.168.168.3 (iSCSI диск при цьому у нас відвалиться) і переконаємося в тому, що додатково налаштовані iSCSI-інтерфейси сервера ESOS і хоста-ініціатора бачать один одного.

У апплете Панелі управління iSCSI Initiatorна вкладці Discoveryдодамо додатковий шлях виявлення, вказавши зв'язку 192.168.168.2 - 192.168.168.4

Так як раніше ми створили iSCSI підключення до мети без включеного ознаки multi-path, То тепер нам буде правильніше деактивувати це підключення і створити його заново, але вже з включеним ознакою multi-path.

Спочатку видалимо створене раніше підключення з автозавантаження на вкладці Favorite Targets

Тепер перейдемо на вкладку Targetsі виконаємо відключення (ініціалізований і підключений в системі iSCSI диск при цьому зникне з Windows)

Потім виконаємо повторне підключення мети iSCSI, але на цей раз вже з включеною опцією Enable multi-path(І не забуваємо по кнопці Advancedпровести явну зв'язку інтерфейсів 192.168.168.1 - 192.168.168.3 )

Переконавшись в тому, що мета знову перейшла в стан Connectedвідкриємо її властивості, щоб додати друге підключення по додатковому виділеного інтерфейсу

на вкладці Targetsзайдемо по кнопці Propertiesв властивості підключеної мети, і скористаємося кнопкою Add session, Щоб налаштувати друге підключення.

До речі, тут по кнопці MCSми зможемо переконається в тому, що перша встановлена ​​сесія дійсно використовує заданий нами виділений мережевий інтерфейс.

Отже, використовуючи кнопку Add sessionдодамо додаткове підключення до iSCSI Target вказавши в якості інтерфейсів додаткову пару інтерфейсів, яку ми налаштували раніше (192.168.168.2 - 192.168.168.4 )

Тепер в списку сесій повинна з'явитися запис про другий сесії.

Також створену додаткову сесію ми побачимо і на стороні сервер ESOS.

На стороні хоста-ініціатора заглянемо в оснастку "Диспетчер пристроїв" / Device Manager (devmgmt.msc) І переконаємося в тому, що в розділі Disk drivesз'явився додатковий SCSI-диск з тим же ім'ям (ESOS01-MD0).

Тобто зараз, на стороні Windows-сервера ми фактично бачимо один і той же диск, як два окремих пристрої. Щоб система змогла працювати з цим диском, як з єдиним пристроєм, використовуючи обидва мережевих линка iSCSI до сервера ESOS, нам буде потрібно включити підтримку MPIOдля iSCSI. Для цього переходимо в Панель управління Windows, відкриваємо аплет MPIOі на вкладці Discover Multi-Pathsвключаємо опцію Add support for iSCSI devices. Після цього натискаємо кнопку Addі ствердно відповідаємо на питання про перезавантаження сервера.

Після перезавантаження знову заглянемо в консоль Device Manager і переконаємося в тому, що тепер наш iSCSI диск відображається, як єдиний пристрій і має імені ... Multi-Path Disk Device. Відкриємо властивості диска і на вкладці MPIOперевіримо те, що диск доступний двома шляхами.

Більш детальну інформацію про маршрутах підключення можемо побачити в апплете панелі управління iSCSI Initiator.

Тут по кнопці MPIOми побачимо інформацію про використовувані підключених.

На цьому базову настройку Multipath можна вважати закінченою.

Тепер для того, щоб оцінити зміни в швидкості роботи з iSCSI-диском, які ми отримали в результаті організації другого линка і настройки Multipath проведемо простий тест лінійного запису великих файлів на диск за аналогією з тим, що робили раніше:

Diskspd.exe -d60 -b1M -s -w100 -t1 -c100G T: \ io1.dat T: \ io2.dat

Судячи з того, що нам показує Diskspd в даному випадку, в середньому в кожен з файлів запис пройшла зі швидкістю ~ 225MB / s, що дорівнює 1800Mb / s. Тобто в підсумку ми отримуємо швидкість наближену до сумарної пропускної спроможності двох організованих лінків iSCSI.

Той же тест, але більш тривалий за часом (5 хвилин):

Diskspd.exe -d300 -b1M -s -w100 -t1 -c100G T: \ io1.dat T: \ io2.dat

Середня величина в ~ 48.5 MB / s, отримана при роботі з кожним файлом, виглядає відчутно краще, ніж отримані раніше 16 MB / s на одному лінк iSCSI.

На підставі цих нехитрих замірів ми можемо зрозуміти, що завдяки організації Multipath-підключення ми не тільки збільшили його доступність, а й отримали поліпшені показники продуктивності. І це добре.

Гаряча заміна USB-накопичувача ESOS

З огляду на те, що збираючи бюджетне рішення, описане в рамках нашого прикладу, ми могли використовувати дешеві USB-накопичувачі, в деяких випадках може виникнути потреба в заміні цього накопичувача (наприклад при його виході з ладу). З огляду на те, що ESOS це Linux-система повністю адаптована до роботи в оперативній пам'яті, заміна USB-накопичувача є дуже простою операцією, коректна обробка якої реалізована розробником цієї системи.

Фактично виконується заміна накопичувача в кілька простих дій:

• На уже завантаженої і працюючій системі ESOS в будь-який момент часу витягаємо USB-накопичувач (накопичувач, який потрібно замінити), з якого ця система була завантажена.
• Готуємо новий USB-накопичувач з ESOS стандартним методом, описаним вище в розділі "Підготовка завантажувального USB-накопичувача ESOS", і встановлюємо цей накопичувач в працюючий сервер ESOS.
• Викликаємо процедуру синхронізації діючу пенсійну систему оперативної пам'яті конфігурації ESOS з файлової системою на USB-накопичувачі. Пункт меню System > Sync Configuration

Після цього бажано перезавантажити сервер і переконатися в тому, що з нового USB-накопичувача система запускається успішно. У процесі першого завантаження з заміненого USB-накопичувача ESOS виконає деякі службові процедури і вже буквально через кілька хвилин сервер буде готовий до роботи, довантажити раніше налаштовану нами конфігурацію.

Судячи з опису документа 13_Upgrading , Точно таким же нехитрим чином виконується оновлення сервера ESOS на більш нову версію, Що істотно полегшує обслуговування такої системи.

висновок

У висновку хочу сказати, що в нашому прикладі, завдяки системі ESOS, нам вдалося вичавити максимум з дисковою кошика застарілого в усіх відношеннях сервера і отримати на хості віртуалізації цілком стерпне по продуктивності дискову ємність під задачу резервного копіювання віртуальних машин. І мені залишається тільки подякувати розробника ESOS за виконану працю і побажати проекту подальшого успішного розвитку.

Протокол iSCSI розроблений для роботи в мережах зберігання даних і являє собою спосіб доступу до блокових пристроїв по протоколу SCSI поверх TCP / IP. Це дає можливість організації недорогих мереж зберігання даних (SAN) за допомогою звичайних Ethernet-мереж. Ця можливість широко використовується при побудові систем високої доступності і ми будемо розглядати в рамках цього циклу саме рішення на основі iSCSI-сховищ. Сьогодні ми розглянемо створення такого сховища на платформі Windows Server 2008 R2.

Спочатку пару слів про принципові відмінності iSCSI від інших мережевих систем зберігання даних. Мережі зберігання даних - SAN(Storage Area Network) передбачають передачу даних в мережі в "сирому" вигляді по протоколу SCSI, також, як якщо б вони передавалися між системою і локальним диском на низькому рівні. i SCSI пристроїва сприймаються системою практично також, як локальні диски - перед використанням на них потрібно створити розділи і відформатувати.

У той же час звичні всім мережеві сховища - NAS (Network Area Storage) забезпечують доступ на рівні файлової системи, використовуючи протоколи передачі файлів, такі як SMB або NFS.

Простіше кажучи: NAS - це звичні всім загальні мережеві папки, SAN - підключаються по мережі диски. З цього випливає друга важлива відмінність. Мережева папка може обслуговувати безліч клієнтів. Пристрій SAN може бути підключено до єдиного клієнта, так само як звичайний HDD може бути підключений тільки до одного ПК. Виняток - кластери, коли до одного SAN-пристрою мають доступ відразу кілька нод, в цьому випадку використовується додатковий рівеньабстракції - кластерна файлова система, наприклад Microsoft Cluster Shared Volumes (CSV)або VMware VMFS.

Перед тим, як приступати до практичного освоєння даної технології, слід познайомитися з прийнятою термінологією:

• Ініціатор iSCSI (iSCSI Initiator)- клієнтська частина, направляє запити мети iSCSI, може бути виконана програмно, у вигляді драйвера або апаратно, у вигляді iSCSI-адаптера;
• мета iSCSI (iSCSI Target, таргет) - серверна частина, приймає підключення від ініціатора і надає йому доступ до пов'язаних з ним блоковими пристроями - віртуальними дисками, LUN. Може бути реалізований як програмно, так і у вигляді апаратної СГД.

Одна мета iSCSI може бути пов'язана з декількома блоковими пристроями, які будуть доступні підключився до мети ініціатору. Один ініціатор може бути підключений до кількох цілей і використовувати всі пов'язані з ними пристрої. Одна мета також може приймати підключення від декількох ініціаторів, але кожне окреме пристрій може бути доступно тільки одному з ініціаторів.

Ще один момент, тепер уже пов'язаний з практичною реалізацією iSCSI-сховищ. Для SAN вкрай бажано виділити окрему мережу, ізольовану від мережі підприємства.

Це необхідно для забезпечення достатньої пропускної здатності в мережі зберігання даних і уникнути перевантаження звичайної мережі iSCSI-трафіком. Також немає сенсу організовувати iSCSI в мережах з пропускною спроможністю нижче ніж 1 Гбіт / сек.

До складу Windows Server 2008 R2 роль мети iSCSI не входить і для її розгортання необхідно завантажити Microsoft iSCSI Software Target. Розпаковуємо його і встановлюємо пакет iscsitarget_public.msiз папки x64. Установка гранично проста і ми не будемо загострювати на ній увагу.

Після установки перейдемо до консолі управління iSCSI: Пуск - Адміністрування - Програмна мета iSCSI. Перш за все створимо нову мета (таргет). Для цього клацнемо правою кнопкою на Цілі iSCSI - Створити мета iSCSI.

Відкриється майстер, в якому вкажемо ім'я мети і її опис. Давайте цілям осмислені імена і не лінуйтеся створювати опису, щоб потім не доводилося гадати для чого у вас створена та чи інша мета.

Наступним кроком нам треба вказати ідентифікатори ініціаторів iSCSI яким буде дозволено доступ до мети. Ідентифікатор IQN - це спеціальне ім'я формату iqn. .: , Яке є унікальним для кожного iSCSI-пристрої в мережі зберігання даних. де:

• year-mo- рік реєстрації доменного імені;
• reversed_domain_name-доменное ім'я, записане навпаки;
• unique_name- унікальне ім'я пристрою, наприклад таргет тут буде містити вказане вами ім'я, а ініціатор ім'я хоста.

Наприклад, в програмних рішеннях Microsoft IQN за замовчуванням має формат iqn.1991-05.com.microsoft:unique_name.

Щоб дізнатися IQN перейдемо на ініціатор iSCSI, в нашому випадку це сервер під керуванням Windows Server 2012, але алгоритм дій буде однаковий для будь-яких інших версій Windows. переходимо в Панель управління - Ініціатор iSCSI, На пропозицію поставити її автоматичний запусквідповідаємо ствердно:

Потім у вікні, переходимо на закладку конфігурація, Де знаходиться шуканий ідентифікатор:

Ви маєте можливість копіювати його і вказати під час налаштування цілі, але є інший спосіб. Для цього перейдіть на закладку кінцеві об'єкти, в полі об'єктвведіть ім'я сервера зі встановленою Програмною ціллю iSCSIі натисніть швидке підключення.

Зрозуміло, що поки ми ні до чого не підключимося, але зараз у нас інше завдання. Повертаємося назад на сервер цілі і тиснемо на сторінці зазначенням ідентифікатора ініціатора кнопку огляд.

Тепер стає зрозуміло, для чого ми робили спробу підключення. Сервер цілей iSCSI зберігає список останніх підключають до неї ініціаторів і дозволяє їх вибрати.

На цьому створення цілі завершено і ми можемо створити і прив'язати до неї один або декілька дисків. Для цього переходимо до пункту пристроїі в меню правої кнопки миші вибираємо Створити віртуальний диск.

Відкриється наступний майстер, в якому вказуємо розташування і ім'я віртуального диска, зверніть увагу, що вказувати потрібно повне ім'я файлу, разом з розширенням .vhd.

Потім вкажемо бажаний розмір в МБ

І мета iSCSI (таргет) до якої буде прив'язаний даний віртуальний диск.

На цьому настройка диска також буде завершена. В результаті цих нескладних дій ми отримали налаштовану мета iSCSI з прив'язаним до неї віртуальним диском. Тепер знову перейдемо на ініціатор. Можна скористатися швидким підключенням і автоматично приєднати диски з виявлених цілей. Але слід пам'ятати, що наша мета не тільки підключити диски, але і розділити мережу зберігання даних і локальну мережупідприємства.

Тому переходимо на закладку виявленняі натискаємо виявити портал, Потім вводимо ім'я сервера з роллю мети iSCSI.

Після чого повертаємося на закладку кінцеві об'єкти, Вибираємо виявлену мета, яка знаходиться в стані Не активно, І натискаємо властивості.

У вікні, в полі IP-адреса кінцевого порталувибираємо адреса належить вашій мережі зберігання даних:

Повертаємося назад і натискаємо підключити. Приєднані пристрої можна виявити в оснащенні управління дисками.

Подальший алгоритм роботи з ними по суті нічим не відрізняється від роботи з звичайним диском: підключаємо, розмічаємо, форматіруем.

У цьому матеріалі ми розглянули найпростіший варіант настройки сховища. У наших наступних матеріалах ми будемо повертатися до окремих налаштувань, не зачіпаючи загальної теми створення сховища.

З появою Fibre Channel і SAN, побудованих на ньому, світ storage зробив ставку на мережевий доступ до систем зберігання. Практично всі в один голос заявили, що за мережами зберігання даних - майбутнє. Протягом декількох років FC інтерфейс залишався безальтернативним стандартом для їх побудови, але вже сьогодні багато хто розуміє, що настає час змін. В SAN на основі FC є пара серйозних недоліків - це ціна і проблеми доступу до географічно (на відстані більше сотень км) віддаленим пристроїв. Останнім часом виникла ціла низка ініціатив, які знаходяться на етапі стандартизації і покликані вирішити або ж обійти зазначені проблеми. Найцікавіша з них - iSCSI.

Буквосполучення iSCSI все частіше потрапляє на сторінки газет і проспекти провідних виробників систем зберігання даних. Ви можете подивитися на ресурси, присвячені storage, і ви обов'язково його побачите. Але, переглянувши статті і новини, ви швидше за все знайдете масу абсолютно протилежних тверджень: одні підносять iSCSI як незаперечного лідера для мереж зберігання даних вже в недалекому майбутньому, інші поставили на ньому хрест ще до його народження.

Sun стала в опозицію до ІP Storage

Sun стала в опозицію до IP Storage. Sun Microsystems не випускатиме систем зберігання даних з доступом по IP. Марк Канепа, віце-президент Sun, відповідальний за виробництво всіх систем зберігання даних, заявив днями, що IP Storage був всього лише «мрією», повідомляє Byte and Switch.

Канепа сказав, що « непрактично застосовувати TCP / IP для організації SAN через більшу затримки в таких мережах. Навіть якщо у мереж зберігання на основі IP є майбутнє, то настане воно через три-п'ять років, а можливо, не наступить ніколи. Потік від систем зберігання даних не може працювати поверх стека протоколів загального призначення, у нього є особливі потреби. Технологічні проблеми застосування TCP / IP набагато більш великі, ніж багато хто думає. Саме тому ми в Sun робимо ставку на Fibre Channel", сказав він. До сих пір ніхто з виробників систем зберігання даних не займав настільки чіткої позиції проти IP Storage. Конкуренти Sun, Hewlett-Packard і IBM, більш-менш активно підтримують ці технології.

HP обіцяє підтримку iSCSI

« Остаточна версія нової технології повинна з'явитися в першому кварталі 2002 року, - повідомив керівник підрозділу систем мережевого зберігання HP Марк Томпсон. Корпорація має намір представити широкий спектр продуктів, які підтримують стандарт, іSCSI, призначений для об'єднання систем зберігання в ІP-мережах ...»

У HP визнають, що користувачі систем Fibre Channel відчувають себе досить комфортно і більше тяжіють до модернізованої технології FCIP, ніж до іSCSI. Але, в той же час, в HP вірять, що досвід роботи з рішеннями, заснованими на протоколі ІP, і особливо з Ethernet, зробить продукти іSCSI привабливими для багатьох замовників.

Computerworld, # 35/2001: «Федеративної системи зберігання»

IBM випускає продукт на базі iSCSI

IBM TotalStorage IP Storage 200i забезпечує пряме підключення накопичувачів Ethernet LAN. Ця високошвидкісна система зберігання даних підтримує новий промисловий стандарт iSCSI, що забезпечує передачу SCSI протоколу поверх IP.

Ну що ж, настільки суперечливі повідомлення не залишають нам іншого вибору окрім як розібратися самим і самостійно зважити всі «ЗА» чи «ПРОТИ».

iSCSI

« iSCSI (Internet Small Computer System Interface) - це протокол, який базується на TCP / IP і розроблений для встановлення взаємодії і управління системами зберігання даних, серверами і клієнтами».

iSCSI описує:

• Транспортний протокол для SCSI, який працює поверх TCP
• Новий механізм інкапсуляції SCSI команд в IP мережі
• Протокол для нової генерації систем зберігання даних, які будуть використовувати «рідний» TCP / IP

Відразу виникає обурення, хочеться все розкласти по окремим купках. Як казав один мій викладач: «Котлети окремо, мухи окремо». Справа в тому, що правила доставки пакетів в IP і SCSI абсолютно протилежні. В IP пакети доставляються одержувачу без дотримання суворої послідовності, він же і відновлює дані, на що витрачаються певні ресурси. У той же час, за специфікацією SCSI, як канального інтерфейсу, всі пакети повинні передаватися один за іншим без затримки, а порушення цього порядку призводить до втрати даних. Незважаючи на те, що, на думку деяких фахівців, ця проблема вносить неоднозначність в практичне використання технології iSCSI, на сьогодні вже реалізований ряд пристроїв, які підтверджують її життєздатність. Інженери, які працювали над iSCSI, змогли певним чином вирішити цю проблему. Специфікація iSCSI вимагає збільшення розмірів заголовка пакета. У заголовок включається додаткова інформація, яка значно прискорює збірку пакетів.

На думку одного з уболівальників iSCSI, Хеймора, старшого системного інженера університету штату Юта, основною перешкодою для поширення Ethernet як базової технології побудови мереж зберігання даних є відносно великий час затримки (близьке до 75 мікросекунд), яке виникає через особливості стека TCP / ІР . В High-End системах при одночасному зверненні до тисяч файлів це може стати серйозною проблемою.

Фахівці, які працюють над iSCSI, усвідомлюють значення проблеми затримки. І незважаючи на те, що розробляється маса коштів для зменшення впливу параметрів, які служать причиною затримки при обробці IP пакетів, технологія iSCSI позиціонується для побудови систем середнього рівня.

iSCSI розвивається дуже швидко. Потреба в новому стандарті відчувалася так сильно, що буквально за 14 місяців з моменту пропозиції по створенню iSCSI, з яким в лютому 2000 року виступила IETF, з'явилося досить багато пристроїв, щоб продемонструвати можливості по їх взаємодії. У липні 2000-го був опублікований Draft 0 по iSCSI, який став початком робіт по реалізації технології. У січні 2001 року в рамках SNIA (Storage Networking Industry Association) був створений IP Storage форум, який через півроку вже налічував 50 членів, а в квітні цього ж року був представлений продукт, який незабаром виграв нагороду «Enterprise Networking Product».

Що ж такого чудового в iSCSI, що він знаходить підтримку серед грандів комп'ютерної індустрії, не рахуючись з існуючими всередині стандартам протиріччями.

Деякі з найважливіших прикладних задач і функцій, які реалізуються з використанням систем зберігання даних, це:

Завдання, які ефективно реалізуються сучасними методами:

· Консолідація систем зберігання даних · Резервування даних · Кластеризація серверів · Реплікація (дублювання) Відновлення в аварійних ситуаціях

Нові можливості, які ефективно реалізуються з використанням IP Storage:

· Географічне розподіл SAN · QoS · Безпека

Разом з цим, нові системи зберігання даних, для яких iSCSI буде рідним протоколом, сформують ще масу переваг:

· Забезпечується єдина технологія для під'єднання систем зберігання, серверів і клієнтів в рамках LAN, WAN, SAN · Наявність значного досвіду індустрії в Ethernet і SCSI технологіях · Можливість значного географічного віддалення систем зберігання · Можливість використовувати засоби управління TCP / IP мережами

Причому, для передачі даних на storage з інтерфейсом iSCSI можна використовувати не тільки носії, комутатори і маршрутизатори існуючих мереж LAN / WAN, а й звичайні мережеві картки на стороні клієнта. Правда, при цьому виникають значні накладні витрати процесорної потужності на стороні клієнта, який використовує таку картку. За твердженням розробників, програмна реалізація iSCSI може досягти швидкостей середовища передачі даних Gigabit Ethernet при значній, до 100% завантаженні сучасних CPU. У зв'язку з чим, рекомендується використання спеціальних мережевих карток, які будуть підтримувати механізми розвантаження CPU від обробки стека TCP. На момент написання статті (Червень 2002 року), такі картки виробляла компанія Intel.

Intel PRO / 1000T IP Storage Adapter пропонується компанією Intel за ціною 700USD за штуку. Це пристрій містить потужний процесор Xscale, 32M пам'яті і здійснює передачу обчислень, пов'язаних з протоколами iSCSI і TCP / IP, а також розрахунок контрольних сум кадрів TCP, IP на інтегрований процесор. Його швидкодія, згідно з внутрішніми тестами компанії, може досягати 500Mbit / s при 3-5% завантаженні CPU host системи.

Давайте розглянемо iSCSI уважніше

Малюнок 1. IP мережу з використанням iSCSI пристроїв

У прикладі, зображеному на малюнку 1, кожен сервер, робоча станція і накопичувач підтримують Ethernet інтерфейс і пакет протоколів iSCSI. Для організації мережевих з'єднань використовуються IP маршрутизатори та Ethernet комутатори.

З впровадженням SAN ми отримали можливість використовувати SCSI протокол в мережевих інфраструктурах, забезпечуючи високошвидкісну передачу даних на рівні блоків між множинними елементами мережі зберігання даних.

Internet Small Computer System Interface теж забезпечує блоковий доступ до даних, але не самостійно, а поверх мереж TCP / IP.

Архітектура звичайного SCSI базується на «клієнт» / «серверної» моделі. «Клієнт», наприклад сервер, або робоча станція, ініціює запити на зчитування або запис даних з виконавця - «сервера», наприклад системи зберігання даних. Команди, які видає «клієнт» і обробляє «сервер» поміщаються в Command Descriptor Block (CDB). «Сервер» виконує команду, а закінчення її виконання позначається спеціальним сигналом. Інкапсуляція і надійна доставка CDB транзакцій між ініціаторами і виконавцями через TCP / IP мережу і є Головна задача iSCSI, причому її доводиться здійснювати в нетрадиційній для SCSI, потенційно ненадійною середовищі IP мереж.

Перед вами модель рівнів протоколу iSCSI, яка дає можливість зрозуміти порядок інкапсуляції SCSI команд для передачі їх через фізичний носій.

Малюнок 2. Модель нижніх рівнів протоколу iSCSI

iSCSI протокол здійснює контроль передачі блоків даних і забезпечує підтвердження достовірності завершення операції введення / виводу. Що, в свою чергу, забезпечується через одне або кілька TCP з'єднань.

іSCSI має чотири складові:

• Управління іменами та адресами (iSCSI Address and Naming Conventions).
• Для керування обміном (iSCSI Session Management).
• Обробка помилок (iSCSI Error Handling).
• Безпека (iSCSI Security).

Управління іменами та адресами

Так як iSCSI пристрої є учасниками IP мережі, вони мають індивідуальні Мережеві Сутності (Network Entity). Мережева Сутність може містити один або кілька iSCSI Узлов.

Малюнок 3. Модель мережевих сутностей

iSCSI вузол є ідентифікатором SCSI пристроїв (в Мережевий Сутності), доступних через мережу. Кожен iSCSI вузол має унікальне iSCSI ім'я (довжиною до 255 байт), яке формується за правилами, прийнятим для позначення вузлів в Internet. Наприклад: «fqn.com.ustar.storage.itdepartment.161». Таку назву має зручну для сприйняття людиною форму і може оброблятися сервером Доменних Імен (DNS). Таким чином, iSCSI ім'я забезпечує коректну ідентифікацію iSCSI пристрою незалежно від його фізичного місцезнаходження. У той же час, в процесі контролю і передачі даних між пристроями зручніше користуватися комбінацією IP адреси і TCP порту, які забезпечуються Мережним порталом (Network Portal). iSCSI протокол додатково до iSCSI імен забезпечує підтримку псевдонімів, які, як правило, відображаються в системах адміністрування для зручності ідентифікації та управління адміністраторами системи.

Для керування обміном

iSCSI сесія складається з фаз аутентифікації (Login Phase) і фази обміну (Full Feature Phase), яка звершается спеціальної командою.

Фаза аутентифікації iSCSI аналогічна процесу Fibre Channel Port Login (PLOGI). Вона використовується для того, щоб узгодити різноманітні параметри між двома Мережними Сутностями і підтвердити право доступу ініціатора. Якщо фаза аутентифікації iSCSI завершується успішно, виконавець підтверджує login ініціатору, інакше логін не підтверджується, а TCP з'єднання закривається.

Як тільки login підтвердиться, iSCSI сесія переходить до фази обміну. Якщо було встановлено більше одного з'єднання TCP, iSCSI вимагає, щоб кожна пара команда / відповідь проходила через одне TCP з'єднання. Така процедура гарантує, що кожна окрема команда зчитування або запису здійснюватиметься без необхідності додатково відслідковувати кожен запит з приводу його проходження по різних потоків. Однак різні транзакції можуть одночасно передаватися через різні TCP з'єднання в рамках однієї сесії.

Малюнок 4. Приклад iSCSI Write

На завершення транзакції ініціатор передає / приймає останні дані, а виконавець відправляє відповідь, що підтверджує успішну передачу даних.

У разі необхідності закрити сесію, використовується команда iSCSI logout, яка передає інформацію про причини завершення сесії. Вона також може передати інформацію про те, яке з'єднання слід закрити в разі виникнення помилки з'єднання, щоб закрити проблемні TCP зв'язку.

Обробка помилок

У зв'язку з високою ймовірністю виникнення помилок при передачі даних в деяких типах IP мереж, особливо WAN реалізаціях, в яких може функціонувати iSCSI, протокол передбачає масу заходів по обробці помилок.

Для того, щоб обробка помилок і відновлення після збоїв функціонували коректно, як ініціатор, так і виконавець повинні мати можливість буферизації команд до моменту їх підтвердження. Кожне кінцеве пристрій повинен мати можливість вибірково відновити втрачений або зіпсований PDU в рамках транзакції для відновлення передачі даних.

Ієрархія системи обробки помилок і відновлення після збоїв в iSCSI включає:

1. На найнижчому рівні - визначення помилки і відновлення даних на рівні SCSI завдання, наприклад, повторення передачі втраченого або пошкодженого PDU.
2. На наступному рівні - в TCP з'єднанні, яке передає SCSI задачу, може статися помилка, а саме, TCP з'єднання може пошкодитися. У цьому випадку здійснюється спроба відновити з'єднання.
3. І нарешті, сама iSCSI сесія може зіпсуватися. Терминация і відновлення сесії, як правило, не потрібно, якщо відновлення коректно відпрацьовується на інших рівнях, однак може статися зворотне. Така ситуація вимагає закриття всіх TCP з'єднань, завершення всіх завдань, недовиконаних SCSI команд і перезапуску сесії через повторний login.

Безпека

У зв'язку з використанням iSCSI в мережах, де можливий несанкціонований доступ до даних, специфікація передбачає можливість використання різноманітних методів для підвищення безпеки. Такі засоби шифрування, як IPSec, які використовують нижні рівні, не вимагають додаткового узгодження, так як є прозорими для верхніх рівнів, В тому числі для iSCSI. Для аутентифікації можуть використовуватися різноманітні рішення, наприклад такі, як Kerberos, або обмін Приватними Ключами, як сховища ключів може використовуватися iSNS сервер.

Інші (iFCP, FCIP)

В рамках роботи над мережевими технологіями зберігання даних в Internet Engineering Task Force (IETF) була створена робоча група IP Storage (IPS) за напрямками:

• iSCSI (Internet Small Computer Systems Interface)
• FCIP (Fibre Channel over TCP / IP)
• iFCP (Internet Fibre Channel Protocol)
• iSNS (Internet Storage Name Service)

А також, як уже зазначалося, в січні 2001 в рамках SNIA (Storage Networking Industry Association) був організований IP Storage форум. Сьогодні форум включає три підгрупи: FCIP, iFCP, iSCSI. Кожна з яких представляє протокол, який знаходиться під протекцією IETF.

FCIP- створений на базі TCP / IP тунельний протокол, функцією якого є поєднання географічно віддалених FC SAN без будь-якого впливу на FC і IP протоколи.

iFCP- створений на базі TCP / IP протокол для з'єднання FC систем зберігання даних FC мереж зберігання даних, використовуючи IP інфраструктуру спільно або замість FC комутаційних і маршрутизирующих елементів.

iSCSI- розглядається вище ...

Для кращого розуміння позиціонування цих трьох протоколів наведемо структурну схему мереж, побудованих з їх використанням.

Малюнок 5. Блок-схема IP Storage мереж

Fibre Channel over IP

Найменш революційним з трьох названих вище є протокол Fibre Channel over IP. Він не вносить ніяких змін в структуру SAN і в організацію самих систем зберігання даних. Головна ідея цього протоколу - реалізація можливості об'єднання географічно віддалених мереж зберігання даних.

Ось так виглядає стек протоколу FCIP:

Малюнок 6. Нижні рівні протоколу FCIP

FCIP допомагає ефективно вирішити задачу територіального розподілу, і об'єднання SAN на великих відстанях. Його основними перевагами є те, що цей протокол повністю прозорий для існуючих FC SAN мереж і орієнтований на використання інфраструктури сучасних MAN / WAN мереж. Таким чином, для забезпечення нової функціональності користувачам, які шукають можливості зв'язати між собою географічно віддалені FC SAN, буде потрібен всього лише FCIP шлюз і підключення до MAN / WAN мережі. Географічно розподілена SAN, побудована за допомогою FCIP, сприймається SAN пристроями як звичайна FC мережу, а для MAN / WAN мережі, до якої вона підключена, вона являє звичайний IP трафік.

Draft стандарт робочої групи IETF IPS - FCIP визначає:

• правила інкапсуляції FC кадрів для передачі через TCP / IP;
• правила використання інкапсуляції для створення віртуальної зв'язку між FC пристроями та елементами FC мережі;
• оточення TCP / IP для підтримки створення віртуальної зв'язку та забезпечення тунелювання FC трафіку через IP мережу, включаючи безпеку, цілісність даних і питання швидкості передачі даних.

Серед прикладних задач, які можна якісно вирішити з використанням FCIP протоколу: віддалене резервування, відновлення даних та загальний доступдо даних. При використанні високошвидкісних MAN / WAN комунікацій можна також з успіхом застосовувати: синхронне дублювання даних і загальний розподілений доступ до систем зберігання даних.

iFCP

Internet Fibre Channel Protocol - це протокол, який забезпечує передачу FC трафіку поверх TCP / IP транспорту між шлюзами iFCP. У цьому протоколі, транспортний рівень FC заміщається транспортом IP мережі, трафік між FC пристроями маршрутизируется і комутується засобами TCP / IP. Протокол iFCP надає можливість підключати існуючі FC системи зберігання даних до IP мережі з підтримкою мережевих сервісів, які потрібні цим пристроям.

Стек протоколу iFCP має такий вигляд:

Малюнок 7. Нижні рівні протоколу iFCP

iFCP, згідно специфікації:

• накладає кадри FC для їх транспортування на попередньо визначене TCP з'єднання;
• FC сервіси передачі повідомлень і маршрутизації перекриваються в шлюзовому пристрої iFCP, таким чином, мережеві структури і компоненти FC не зливаються в загальну FC SAN, а управляються засобами TCP / IP;
• динамічно створює IP тунелі для FC кадрів

Важливою особливістю iFCP є те, що цей протокол забезпечує FC device-to-device зв'язок (зв'язок між пристроями) через IP мережу, яка є значно більш гнучкою схемою, якщо порівнювати її зі зв'язком SAN-to-SAN. Так, наприклад, якщо iFCP має TCP зв'язок між парами портів N_Port двох FC пристроїв, такий зв'язок може мати свій власний рівень QoS, який буде відрізнятися від рівня QoS іншої пари FC пристроїв.

висновок

Підводячи підсумки, хочеться висловити свою тверду впевненість в тому, що Fibre Channel найближчим часом нікуди не зникне, ринок FC SAN буде рости і розвиватися. У той же час, IP Storage протоколи нададуть можливість ефективно використовувати мережі зберігання даних в тих прикладних задачах, для яких FC не може забезпечити ефективної реалізації. Використовуючи протоколи FCIP і iFCP, мережі зберігання даних стануть географічно розподіленими. А впровадження iSCSI в свою чергу, дасть можливість використання переваг SAN в сферах, які до сих пір залишаються нереалізованими, або реалізуються неефективно в рамках поширених сьогодні технологій.

P.S.

Бурхливий розвиток мереж зберігання даних стало основою формування концепції World Wide Strorage Area Network. WWSAN - всесвітня мережа зберігання даних і передбачає створення інфраструктури, яка забезпечить високошвидкісний доступ і зберігання даних, розподілених по всьому світу. Концепція дуже близька до існуючої сьогодні WWW, але має в своїй основі інші сервіси. Одним з оригінальних прикладів є обслуговування «менеджера», який їздить по всьому світу з презентаціями. WWWSAN передбачає прозоре переміщення «мобільних» даних слідом за персональним переміщенням їх власника по всьому світу. Таким чином, де б не перебував «менеджер», він завжди буде мати можливість одержати високошвидкісний доступ до потрібних йому даними, робота з якими не буде вимагати складної, часом дуже неефективною синхронізації через WWW.

Можна з упевненістю стверджувати, що концепція побудови всесвітньої мережі зберігання даних ідеально вписується в розвиток сучасних технологій IP Storage.

Терміни та скорочення:

• SAN - Storage Area Network, мережа зберігання даних
• CDB - command descriptor block, протокол дескриптора (опису) команди.
• PDU - Protocol Data Unit протокольна одиниця обміну, модуль даних протоколу.
• QoS - скор. від Quality of Service якість і клас послуг, що надаються передачі даних (зазвичай описує мережу в термінах затримки і смуги сигналу).
• SNIA - Storage Networking Industry Association, асоціація індустрії мережевих систем зберігання даних.
• DNS - Domain Name Server, сервер доменних імен.
• PLOGI - Fibre Channel Port Login.
• iSCSI - Internet Small Computer Systems Interface
• FCIP - Fibre Channel over TCP / IP
• iFCP - Internet Fibre Channel Protocol
• iSNS - Internet Storage Name Service
• WWSAN - World Wide Strorage Area Network, всесвітня мережа зберігання даних

література:

• «SAN після Fibre Channel», - Лукас Меріан. 12.02.2002: Computerworld, # 05/2002;
• IP Storage Tutorial, - SNIA;
• iSCSI Technical White Paper, - SNIA;
• Internet Fibre Channel Protocol (iFCP) - A Technical Overview, - SNIA;
• Storage Forum, - HP EMEA, 12-13 червня 2002 року.

Пишу в першу чергу для себе, але якщо кому то буде корисним теж добре.
Завдання, організувати тіньове копіювання на файлообмінному сервері, обсяг розділу 1Тб. Для створення тіньових копій, Необхідний ще один розділ мінімум в 1Тб, але це потрібно вишукувати кошти, купувати жорсткі диски в стійку, в загальному нешвидко, а потрібно вже вчора. Є мережеве сховище Netgear ReadyNAS з RAID-5 на борту і купою вільного місця. Нюанс лише в тому, що в для створення тіньових копій потрібен саме локальний тому, а не мережевий диск. І тут нам на допомогу приходить iSCSI, що це таке я описувати не буду, кому треба прочитають в вікіпедії, та й кому треба думаю і так знають, що це. У двох словах протокол дозволяє мережевий диск зробити локальним томом.
Отже для початку, заходимо в адмінку ReadyNAS і на вкладці iSCSI тиснемо Створити новий LUN

Варто звернути увагу на параметр наданняваріант Thick - товстий, виділить відразу весь обсяг для LUN, варіант Thin - тонкий, буде виділяти в міру заповнення. Перший варіант швидше, другий зручніше, але вирішувати вам.
Після того як ми створили LUN, на тій же вкладці тиснемо Створити нову групу. Задаємо ім'я групи і цільової ресурс.

дрібне відступ

Ідентифікатор IQN - це спеціальне ім'я формату iqn. . :, Яке є унікальним для кожного iSCSI-пристрої в мережі зберігання даних. де:

year-mo- рік реєстрації доменного імені;
reversed_domain_name-доменное ім'я, записане навпаки;
unique_name- унікальне ім'я пристрою, наприклад таргет тут буде містити вказане вами ім'я, а ініціатор ім'я хоста.

Щоб дізнатися ім'я цільового ресурсу, перемістимося на сервер до якого ходимо підключити диск. далі Панель управління - Ініціатор iSCSI. У вікні переходимо на вкладку конфігураціяі копіюємо звідти ім'я ініціатора.

Повертаємося і заповнюємо поле. Після цього заходимо в властивості групи, тиснемо на плюсик, щоб створити ініціатора, далі вводимо ім'я ініціатора, яке ми копіювали, трохи раніше, щоб скласти ім'я цільового ресурсу.

В поле пароль вводимо пароль, за яким буде авторизуватися ініціатор iSCSI. Тиснемо створити і встановлюємо галку дозволити.
Знову повертаємося до сервера-ініціатору, переходимо на вкладку виявлення, Тиснемо виявити портал, в який з'явився поле записуємо адресу нашого ReadyNAS.

У тому ж вікні (де вводимо адресу), тиснемо додатковона вкладці загальнівводимо ім'яз попереднього кроку і секрет- це пароль з попереднього кроку.

На тій же вкладці можна вибрати адаптер за допомогою якого відбувається підключення, адреса ініціатора і адреса кінцевого порталу (у мене він сірий, тому що робив скріншот на вже налагодженій системі, у вас він буде активним).
Після того як ми налаштували портал і авторизацію на вкладці кінцеві об'єктиможна буде побачити наш LUN, тиснемо підключити, Якщо він ще не підключений і переходимо на вкладку Тома і пристрої.

натискаємо там автонастройкаі наш LUN додається в якості локального томи. Все можна переходити до Управління дисками і налаштовувати його як Вам завгодно.