5. Инсталлировать и настроить iSCSI Target (storage provider).
Теперь в фокус нашего внимания попадает ВМ с именем clustSAN (на всякий случай напомню, что согласно нашим договоренностям гостевые компьютеры имеют те же имена, что и виртуальные машины их хостящие). Именно на ней нам прямо сейчас предстоит организовать iSCSI Target. Что это такое и зачем? История начинается с того факта, что у готового кластера должен быть один важный (а может и просто важнейший) компонент — разделяемый дисковый массив (shared disk array). Именно на нем (а не на локальных дисках C: каждой ноды) будет храниться самое ценное — информация нашего предприятия или организации. Т.е. все базы данных (а равно и их журналы транзакций) будут собраны на этом массиве. В каждый момент времени доступ к этим базам будет у одной, и строго у одной (не больше, но и не меньше!) ноды, причем именно эта нода будет называться активной. Однако физически массив постоянно подключен ко всем нодам кластера вне зависимости от их текущих ролей.
Что может выступить в роли такого массива? Концептуально, Windows как таковая поддерживает, три технологии хранения данных:
- DAS (Direct Attached Storage)
- NAS (Network Attached Storage)
- SAN (Storage Area Networks)
Возможность применения любой из них конкретно с кластером будет упираться в поддержку (либо, соответственно, не-поддержку) протокола обмена данными, реализованной конкретным «железом», позиционирующим себя как решение той или иной технологии хранения данных. Иными словами, определяющим фактором становится не технология, а протокол, посредством которого shared disk соединен с остальной системой. Вот вам «кластеро-совместимые» протоколы:
- Serial Attached SCSI (SAS)
- iSCSI
- Fibre Channel
Не сказать что б «глаза разбегались», как видите. В реальных кластерах shared disk это, скорей всего, или массив RAID 5 / RAID 10 подключенный по протоколам iSCSI / Fibre Channel, или SAN использующая те же протоколы. И мы собираемся эмулировать именно последний вариант — SAN, причем подключенному по первому протоколу — iSCSI.
Строго говоря, SAN как готовое решение состоит минимум из трех компонентов:
- Host Bus Adaptor (HBA) — плата вставляемая в любой компьютер/сервер желающий получить доступ к информации хранящейся в SAN;
- ресурсы хранения данных — непосредственно дисковые массивы и/или ленточные накопители, с соответствующим интерфейсом подключения. Тут все очевидно, это тот самый компонент что, собственно, и хранит информацию;
- устройства, реализующие инфраструктуру SAN — в качестве такового будет выступать SAN коммутатор (SAN switch), представляющий собой центральное коммутирующее устройство для узлов сети SAN. По сути это ядро всего вашего SAN-решения, т.к. соединяет первое со вторым. Допустим, если вы замахнетесь на кластер состоящий из 16-ти нод (максимальное число поддерживаемое OS Windows Server 2008 R2), а ваша SAN будет содержать 50 различных ресурсов хранения данных (объединенных в дисковый массив, разумеется), не исключена ситуация, когда, скажем 10 нод попытаются забрать информацию с 25-ти различных дисков. Коммутатор обеспечит реализацию именно этого сценария — «все говорят со всеми».
А с другой стороны, с учетом что у нас будет именно SAN over iSCSI, наш shared disk обязан состоять из двух основополагающих компонентов этого протокола:
- iSCSI target — iSCSI сервер. Это, можно сказать, как SQL Server, только последний ждет открытия сессии (и готов ее обслужить) по протоколу (чаще всего) TCP, а первый делает тоже самое для iSCSI session, по, соответственно, iSCSI же протоколу. Иными словами это есть не что иное как storage provider;
- iSCSI initiator — да, вы уже правильно догадались, «это как SQL клиент, но только для iSCSI». Совершенно верно, инициатор, собственно, инициирует открытие iSCSI session, обращаясь с этой целью к iSCSI target, а последний, если открытие прошло успешно, начинает ее обслуживать.
Максимально упрощая ситуацию и сводя последний список с предпоследним:
- iSCSI target=SAN коммутатор+SAN ресурсы хранения данных
- iSCSI initiator=Host Bus Adaptor
Для нас самой приятной новостью является та, что все без исключения «участники спектакля» могут быть софт-эмулированы. Причем такую эмуляцию иногда делают даже в реальных решениях. Понятно, что «железные» HBA/ресурсы хранения имеют громадное преимущество (и даже преимущества) перед софт-вариантом, но тут уж как обычно, «деньги vs. надежность/производительность». У нас никаких колебаний нет, для нашего тест-стенда программная реализация это лучшее что можно придумать.
Итак, мы находимся на clustSAN, который будет нами сейчас же и незамедлительно преобразован в iSCSI target. Эмулятором последнего выступит пакет Microsoft iSCSI Software Target 3.3, любезно распространяемый фирмой Microsoft совершенно безвозмездно. Дистрибутив пакета мы предусмотрительно заготовили где-то на нашем внешнем носителе типа USB-диска (если это не так и ничего не подготовлено — срочно прочтите раздел Software из второй части мануала!) и сейчас самое время подключить его к указанной ВМ.
Запускаем инсталлятор. В моем случае это был rar-архив «завернутый» в exe-файл. Указываем ему в качестве цели распаковки любую папку, к примеру c:\iSCSITar, жмем Extract либо Install. Однако это будет только распаковка архива, пока еще никакого iSCSI target-а у нас нет. Идем в целевую папку, где обнаруживается две под-папки: x86 и x64. Нам, понятно, во вторую.
Запускаем из нее iscsitarget_public.msi — этот как раз наш будущий «iSCSI-сервер». Все экраны установщика просто прощелкиваем «по дефолту». Скорее всего в конце нам будет предупреждение о невозможности создать правило-исключение для файрвола. Игнорируем, т.к. никаких исключений в виду отсутствия у нас файрвола как такового нам не требуется В конце щелкаем Finish и завершаем процесс установки.
Если хотим фолдер c:\iSCSITar можно сносить — больше он нам не понадобится.
Теперь, образно говоря, у нас есть платформа для эмуляции SAN коммутатора, но нет ни его самого, ни единого диска в массиве. Да и массива-то тоже нет. Исправим ситуацию. Если инсталляция прошла успешно в меню Administrative Tools у нас обязан появиться новый пункт — Microsoft iSCSI Software Target, его и вызываем.
Наша ближайшая цель — создать iSCSI-сервер, первый и единственный. Хотя — заметьте, платформа позволяет их создать сколько угодно, оцените «простор для творчества»! Стало быть, из контекстного меню узла iSCSI Targets вызываем пункт Create iSCSI Target.
На первой странице открывшегося визарда вводим имя будущего сервера и его описание. Допустим назовем наш сервер FourDisksSAN, а описание будет Four Disks SAN for cluster tests.
На странице следующей нам надо указать идентификатор первого инициатора будущего сервера, то есть, иными словами, его потребителя. Такой идентификатор указывается в формате iSCSI Qualified Name (IQN) и может иметь вид примерно вот какой:
где
- iqn — буквальный литерал, означающий что данный идентификатор определяет именно iSCSI устройство;
- 2009-01 — год-месяц обретения прав на доменное имя, см. следующую строку;
- ru.site — доменное имя в «реверсивной» записи принадлежащее той организации, что придумала разбираемый нами в настоящий момент идентификатор;
- :storageArr.myDisk1.mySys1.abc — опциональная часть, но если используется, то с обязательным двоеточием! Совершенно произвольная строка текста.
«Генеральная» идея стоящая за такой схемой наименования — каждое iSCSI устройство должно быть максимально уникальным (отсюда и эта опциональная часть после двоеточия). Как можно предположить (и при этом не ошибиться) подобным образом именуются не только iSCSI инициаторы, но и их сервера. Однако в данный момент нас просят задать имя первого. Но мы просто не можем этого сделать! У нас нет ни единого инициатора как такового, откуда ж мы узнаем их (или хотя бы его) идентификаторы? Ставим покамест вполне формальный 0, имея в виду, что мы позже вернемся и исправим этот фиктивный идентификатор на валидный, и едем дальше.
Завершаем создание нашего единственного iSCSI Target.
Проверяем факт успешного создания сервера его присутствием в списке таковых.
К этому серверу пока не способен подключиться ни один клиент (мы пропустили указание имени клиентов имеющих право доступа — помните?), ну да лиха беда начало. Наша очередная цель — создать дисковый массив из четырех дисков управлять которыми будет этот самый сервер по имени FourDisksSAN.
6. Добавить в iSCSI Target управляемые им виртуальные диски.
Для достижения этой цели вызываем контекстное меню самого сервера FourDisksSAN (а не его родительского узла iSCSI Targets) и выбираем пункт Create Virtual Disk for iSCSI Target
Это приведет к запуску очередного мастера, на этот раз мастера создания виртуальных дисков.
Здесь следует понять вот какую вещь: поскольку, очевидно, нам совсем не интересно закупать «железную» реализацию массива для своего стенда, мы идем таким путем — считаем что сам массив (или, более четко, модульный массив для SAN, или, на профессиональном сленге — «полка») у нас уже есть. Но пока он пуст, т.е. содержит 0 дисков. Теперь мы «начиняем» его жесткими дисками по нашему выбору. Однако и жестких дисков у нас тоже нет, 
их роль выполнят «физические файлы виртуальной машины». Т.е. сейчас мы на диске C: компьютера clustSAN создадим четыре файла, каждый из которых, «на самом деле», будет «жестким диском» и войдет в состав массива. Не запутайтесь в этой «виртуализации внутри виртуализированного»!
Что бы добавление указанных дисков носило упорядоченный и управляемый характер сразу определимся — какие характеристики запросит для каждого только что запущенный мастер. А он потребует от нас:
- имя «виртуально-физического» файла и полный путь к нему;
- размер целевого диска (и как следствие — предыдущего файла, разумеется)
- описание диска в свободной форме
Составим табличку нужных нам значений.
| Имя и путь к файлу эмулирующему диск | Размер диска в MB | Описание диска |
| c:\q.vhd | 2000 | This is quorum disk |
| c:\m.vhd | 2000 | This is MSDTC disk |
| c:\t.vhd | 4000 | This is DB data disk |
| c:\l.vhd | 500 | This is DB logs disk |
Не забывайте, что первая колонка это путь для локального диска виртуального компьютера clustSAN, не диска компьютера-хоста! Возвращаемся к ненадолго покинутому нами мастеру. На второй странице нам предложат как раз ввести путь к файлу, которому предначертано сыграть роль диска в дисковом массиве. Идем по только что составленной таблице сверху вниз.
Следующая страница — размер виртуального диска.
Завершающая страница — описание диска.
Да и, собственно, финиш.
Теперь в главном окне инструмента iSCSITarget, в списке дисков нашего iSCSI сервера мы видим результаты только что проделанной работы.
Повторяем тот же мастер еще трижды, каждый раз переходя со строчки на строчку нашей таблицы. По итогу получаем картину следующего вида.
Мы только что создали SAN коммутатор, подключили его к дисковому массиву и «вставили» в последний четыре диска! Поздравляем себя с отличной работой и двигаемся дальше.