Header RSS-подписка на обновления сайта eMail-подписка на обновления сайта

SQL кластер на VMware Workstation. Часть 5/11.













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. Нам, понятно, во вторую.

Install_pack

Запускаем из нее iscsitarget_public.msi — этот как раз наш будущий «iSCSI-сервер». Все экраны установщика просто прощелкиваем «по дефолту». Скорее всего в конце нам будет предупреждение о невозможности создать правило-исключение для файрвола. Игнорируем, т.к. никаких исключений в виду отсутствия у нас файрвола как такового нам не требуется В конце щелкаем Finish и завершаем процесс установки.

iSCSI_target_ready

Если хотим фолдер c:\iSCSITar можно сносить — больше он нам не понадобится.

Теперь, образно говоря, у нас есть платформа для эмуляции SAN коммутатора, но нет ни его самого, ни единого диска в массиве. Да и массива-то тоже нет. Исправим ситуацию. Если инсталляция прошла успешно в меню Administrative Tools у нас обязан появиться новый пункт — Microsoft iSCSI Software Target, его и вызываем.

New_item_in_Administrative_Tools

Наша ближайшая цель — создать iSCSI-сервер, первый и единственный. Хотя — заметьте, платформа позволяет их создать сколько угодно, оцените «простор для творчества»! Стало быть, из контекстного меню узла iSCSI Targets вызываем пункт Create iSCSI Target.

Start_Create_iSCSI_Target

На первой странице открывшегося визарда вводим имя будущего сервера и его описание. Допустим назовем наш сервер FourDisksSAN, а описание будет Four Disks SAN for cluster tests.

iSCSI_Target_name_and_description

На странице следующей нам надо указать идентификатор первого инициатора будущего сервера, то есть, иными словами, его потребителя. Такой идентификатор указывается в формате iSCSI Qualified Name (IQN) и может иметь вид примерно вот какой:

iqn.2009-01.ru.site:storageArr.myDisk1.mySys1.abc

где

  • iqn — буквальный литерал, означающий что данный идентификатор определяет именно iSCSI устройство;
  • 2009-01 — год-месяц обретения прав на доменное имя, см. следующую строку;
  • ru.site — доменное имя в «реверсивной» записи принадлежащее той организации, что придумала разбираемый нами в настоящий момент идентификатор;
  • :storageArr.myDisk1.mySys1.abc — опциональная часть, но если используется, то с обязательным двоеточием! Совершенно произвольная строка текста.

«Генеральная» идея стоящая за такой схемой наименования — каждое iSCSI устройство должно быть максимально уникальным (отсюда и эта опциональная часть после двоеточия). Как можно предположить (и при этом не ошибиться) подобным образом именуются не только iSCSI инициаторы, но и их сервера. Однако в данный момент нас просят задать имя первого. Но мы просто не можем этого сделать! У нас нет ни единого инициатора как такового, откуда ж мы узнаем их (или хотя бы его) идентификаторы? Ставим покамест вполне формальный 0, имея в виду, что мы позже вернемся и исправим этот фиктивный идентификатор на валидный, и едем дальше.

iSCSI_Initiators_Identifiers

Завершаем создание нашего единственного iSCSI Target.

Finish_Create_iSCSI_Target

Проверяем факт успешного создания сервера его присутствием в списке таковых.

New_iSCSI_target_in_list

К этому серверу пока не способен подключиться ни один клиент (мы пропустили указание имени клиентов имеющих право доступа — помните?), ну да лиха беда начало. Наша очередная цель — создать дисковый массив из четырех дисков управлять которыми будет этот самый сервер по имени FourDisksSAN.

6. Добавить в iSCSI Target управляемые им виртуальные диски.

Для достижения этой цели вызываем контекстное меню самого сервера FourDisksSAN (а не его родительского узла iSCSI Targets) и выбираем пункт Create Virtual Disk for iSCSI Target

Create_Virtual_Disk_for_iSCSI_Target

Это приведет к запуску очередного мастера, на этот раз мастера создания виртуальных дисков.

Create_Virtual_Disk_Wizard_start

Здесь следует понять вот какую вещь: поскольку, очевидно, нам совсем не интересно закупать «железную» реализацию массива для своего стенда, мы идем таким путем — считаем что сам массив (или, более четко, модульный массив для 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, не диска компьютера-хоста! Возвращаемся к ненадолго покинутому нами мастеру. На второй странице нам предложат как раз ввести путь к файлу, которому предначертано сыграть роль диска в дисковом массиве. Идем по только что составленной таблице сверху вниз.

Path_to_file_with_virtual_disk

Следующая страница — размер виртуального диска.

Size_of_virtual_disk

Завершающая страница — описание диска.

Virtual_disk_description

Да и, собственно, финиш.

Create_Virtual_Disk_Wizard_finish

Теперь в главном окне инструмента iSCSITarget, в списке дисков нашего iSCSI сервера мы видим результаты только что проделанной работы.

First_virtual_disk_ready

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

Four_virtual_disks_ready

Мы только что создали SAN коммутатор, подключили его к дисковому массиву и «вставили» в последний четыре диска! Поздравляем себя с отличной работой и двигаемся дальше.