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

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





11. Завершить настройки публичной и приватной сетей, тестировать сетевую конфигурацию.

Мы довольно интенсивно работали с настройками сетевых адаптеров наших машин. А их у нас (адаптеров, а не машин) целых семь штук! По мере становления нашего тест-стенда мы меняли их IP-адреса, предпочитаемые DNS-серверы и т.д. Немудрено было что-то забыть, где-то недосмотреть, перепутать или что-то вроде. Поэтому сейчас, в этом коротком 11-м шаге, мы последними штрихами завершим картину сетевой настройки всех наших машин, а заодно устроим финальный сетевой аудит, дабы быть уверенными в отсутствии каких либо проблем в этом компоненте нашего решения. И да — мы так же должны убедиться в полной независимости и отсутствии взаимного влияния двух наших подсетей: 81-й (публичной) и 136-й (приватной).

Итак, прежде всего мы идем на наш контроллер домена, он же, «по совместительству», наш доменный DNS сервер — clustDC. Открываем там окно настроек IP-адреса сетевого адаптера (на этой машине он единственный) и, прежде всего, стираем значение Default gateway. Вообще, т.е. делаем это поле пустым: нам не нужна точка доступа из одной сети в другую. Наша цель — разделить их «тотально». Кроме того, наш сервер clustDC с установленным (и сконфигурированным!) на нем DNS сервисом теперь сам себе режиссер DNS. А поэтому поле Preferred DNS server заполняем как 127.0.0.1, что означает, буквально, «я — есть DNS». Пользуясь случаем заодно убеждаемся,что IP адрес нашего домен-контроллера по прежнему 192.168.81.110. Все вместе приводит нас к такой картине.

TCPIP_Properties_for_clustDC

Щелчком по OK фиксируем изменения конфигурации.

Далее, на всех машинах кроме clustDC поля Default gateway и Preferred DNS server аналогичных окон настроек TCP/IPv4 должны оба иметь одно и тоже значение — 192.168.81.110. Для машин-нодов (clustNodeA/B) это замечание относится к первому сетевому подключению (тому, что обслуживает 81-ю сеть). Для двух других машин такое подключение вообще единственное. Переходя с машины на машину проверяем этот пункт. Заодно контролируем значение поля IP address, оно должно быть таким:

  • clustNodeA — 192.168.81.111
  • clustNodeB — 192.168.81.112
  • clustSAN — 192.168.81.113
  • clustWork — 192.168.81.114

Наконец, только на двух машинах-нодах: проверяем что в настройках протокола TCP/IP второго подключения (относящегося к 136-й сети) статический IP адрес указан как 192.168.136.111/192.168.136.112 для clustNodeA/B соответственно. Subnet mask стандартная, Default gateway и Preferred DNS server пусты. Находясь во все том же окне назначения IP адреса щелкаем кнопку Advanced... В окне Advanced TCP/IP Settings нам нужна вкладка DNS и галочка Register this connections addresses in DNS. По умолчанию она установлена, а мы ее — стираем.

Advanced_TCP_IP_Settings_register_this_connections_addresses_in_DNS

И фиксируем все изменения. Повторю, что данная процедура относится только к двум указанным машинам и только к подключениям 136-й сети.

Ну и проводим «инвентаризацию» всех имеющихся подключений обоих сетей. На каждой из пяти виртуальных машин создаем несложный cmd-файлик такого примерно содержания:

@ECHO OFF
ECHO --- Start test PUBLIC network---
ping -n 1 192.168.81.110
ping -n 1 192.168.81.111
ping -n 1 192.168.81.112
ping -n 1 192.168.81.113
ping -n 1 192.168.81.114
ECHO --- Start test PRIVATE network---
ping -n 1 192.168.136.111
ping -n 1 192.168.136.112
PAUSE

Называем его, допустим, 1.cmd и запускаем на каждой машине прямо из Windows проводника. Первые 5 команд должны успешно «отпинговаться» на всех машинах без исключения, последние две — только на машинах-нодах (ведь только они имеют подключение к приватной сети!). При этом сообщение о неудачном пинге приватной сети с домен-контроллера будет иметь вид:

Pinging 192.168.136.111 with 32 bytes of data:
Reply from 192.168.81.110: Destination host unreachable.

(и тоже самое для адреса 136.112), а с двух других не подключенных к этой сети машин вид:

Pinging 192.168.136.111 with 32 bytes of data:
Request timed out.

(и тоже самое для адреса 136.112). В данном мануале нет места для разбора причин этого несовпадения, но сообщения должны быть именно такими. Если наш несложный сетевой аудит приносит ожидаемые и только что описанные результаты — двигаемся дальше.

12. Установить на обе будущие ноды компонент (feature) Failover Clustering.

Пришло время для довольно ответственного шага — на каждой из двух будущих нод нашего кластера этот самый кластер «поднять». Пока что это будет кластер операционной системы, но без него определенно невозможно достижение нашей финальной цели — SQL-кластера. Так что сначала нам нужно организовать именно кластер «базовый», поддерживаемый самой Windows Server.

Несмотря на всю ответственность шаг сам по себе очень прост и потребует от нас буквально пары щелчков мышью. Для начала, находясь на первой из двух нод (пусть, для определенности, это будет clustNodeA) мы запускаем консоль Server Manager (Administrative tools→Server Manager). Слева, в дереве, выбираем Features, а справа щелкаем ссылку Add Features.

Server_Manager_Features_Add_Features

На странице мастера с возможностью выбора дополнительных компонентов сервера отмечаем нужную нам — Failover Clustering.

Server_Manager_Features_Failover_Clustering

И щелкаем Next/Install. Через пару десятков секунд мастер успешно завершает инсталляцию всех файлов необходимых для работы будущего кластера, о чем радостно нам рапортует.

Features_Failover_Clustering_installation_results

Щелчком по Close принимаем данный рапорт к сведению и закрываем мастера. Собственно — все. Ну то есть как, для данной будущей ноды — определенно все. Однако текущий шаг требуется повторить буквально «буква-в-букву» на всех будущих нодах. В нашем случае таковая всего одна — clustNodeB. И вот когда мы увидим рапорт подобный приведенному на последней иллюстрации и на ней тоже, вот тогда шаг текущий, 12-й, будет завершен абсолютно, целиком и полностью.

13. Проверить текущую конфигурацию обеих будущих нод на готовность к работе в составе кластера.

Мы подошли, возможно, к ключевому шагу во всем построении тест-стенда SQL-кластеризации на базе платформы VMware Workstation. По некоторым причинам, которые автор иначе как «мистические» назвать не может, шаг получил говорящий порядковый номер — 13. Это очень неспроста, ибо изрядное число бравых ковбоев, бодро приступивших к реализации кластера в реальном, а равно и виртуальном, окружении «скопытились» именно на этом шаге. По сути этот шаг итожит всю проделанную до настоящей точки мануала работу (а сделано, скажем без ложной скромности, немало) и проверяет эту работу на наличие «косяков». Формально говоря, мы собираемся сейчас произвести проверку годности нашего оборудования для целей организации на этом самом оборудовании кластера. То есть нам предстоит провести наше оборудование готовое (с нашей точки зрения) для включения в кластер через ряд тестов. Но, во-первых, тестов много. Не один-два, а несколько десятков! Во-вторых, тестируются различное компоненты системы. Тестируется связка всех указанных тестировщику серверов-нод как единое целое. Тестируется отдельно сетевой компонент системы. Проходят отдельную проверку Shared disks (в нашем случае — наши SAN-диски). И так далее. В-третьих, тесты весьма «суровы». Все должно быть приведено в полное соответствие стандартам и предписаниям даваемых компанией Microsoft для компонентов кластерных решений. Малейшее отклонение — получите от проверяющего «красный крестик» и, как следствие, запрет на «подъем» кластера на текущем оборудовании. Ну или как минимум на текущем оборудовании в его текущей конфигурации. Разумеется, в финальном отчете визарда-тестировщика вы сможете посмотреть причины появления того или иного «креста» для любого конкретного теста. Однако не сказать что бы описания этих причин страдали многословностью. Совсем нет, в лучшем случае код ошибки и пара сопроводительных предложений. Информацию же о том как указанную причину исправить в большинстве случаев вам придется искать самостоятельно. И, по опыту автора, даже «великий-ужасный-все-знающий» Гугл отнюдь не переполнен информацией подобного рода. В общем, самый лучший совет который я могу вам дать — проходить весь тот набор тестов к которым мы приступаем сразу и без всяких «крестиков». А путь к этому — тщательное предварительное планирование финального решения. И тщательный отбор оборудования для него. А так же тестирование прототипа будущего решения на стенде вроде того, чьим созданием мы с вами заняты прямо сейчас.

Итак, на текущий момент на обеих (проверьте, что именно на обеих!) будущих нодах у нас установлен программный компонент по имени Failover Clustering. Проверку можно производить с любой ноды, в ней участвуют все сервера что будут указаны на одной из страниц мастера-тестировщика. Ну, допустим, произведем такую проверку с ВМ clustNodeA. После предыдущего шага у нас на обоих нодах в меню Administrative Tools обязан появиться новый пункт — Failover Cluster Manager, его и вызываем.

Menu_Administrative_Tools_Failover_Cluster_Manager

Открывается одноименная оснастка консоли. На текущий момент нам нужна ссылка Validate a Configuration приводящая к запуску одноименного мастера.

Failover_Cluster_Manager_link_Validate_a_configuration

Щелкаем Next на странице приветствия нового мастера. На странице следующей нам предстоит выбрать те сервера, что войдут в состав будущего кластера. Щелкаем Browse...

Failover_Cluster_Manager_Validate_a_Configuration_Wizard

У нас кластер составят два сервера, clustNodeA и clustNodeB, их и надлежит указать. В поле ввода имен компьютеров впечатываем clustNodeA;clustNodeB (точку с запятой не забудьте!) и щелкаем OK.

Failover_Cluster_Manager_Select_Computers

После возврата на страницу выбора серверов и короткого ожидания убеждаемся что оба сервера внесены в список Selected servers.

Failover_Cluster_Manager_Selected_Servers

Next, на следующую страницу. Это будет страница Testing Options, предоставляющая нам выбор: «прогнать» все тесты или лишь выбранные нами. Настойчиво рекомендован первый (он же дефолтный) вариант, его и утверждаем щелчком по Next. На очередной странице Confirmation подтверждения набора тестов снова Next (хотя можете и задержаться тут на секунду дабы оценить число тестов и их масштаб, а так же их скрупулёзность) и — процесс тестирования запущен, ждем когда все тесты успешно (как мы очень, и даже очень-очень, надеемся) пройдут. Процесс умеренно-длительный, минут 5-10 в зависимости от ресурсов хост-компьютера. Если наши «очень-очень» ожидания оправдываются, то по завершению тестирования можно будет увидеть такую примерно картину.

Failover_Cluster_Validation_Report

Мелкие предупреждения в виде желтых восклицательных знаков (но никак не ошибки в виде красных крестов!) вполне допустимы, все-таки у нас куча эмулируемого оборудования, а ведь согласно правилам и официальной документации все, без исключения, hardware участвующее в построении кластера должно быть сертифицировано для, собственно, такого участия. Иными словами мы должны его наблюдать в том самом списке, ссылку на который автор приводил в самой первой части данного мануала (так называемый каталог Windows Server, он же Windows Server Catalog, WSC). Эмулируемому «железу» тяжело соблюсти все нюансы реализации подобного оборудования. В реальных условиях, понятно, желательно добиваться 100% прохождения этого теста без «сучка-задоринки», хотя даже с официальной точки зрения «желтый знак» не является препятствием для продолжения установки кластера и получившееся в результате решение будет саппортиться сотрудниками Microsoft Customer Support Services. Однако «red X» ставит именно X как на упомянутом саппорте, так и на возможности продолжить, допустим, построение нашего тест-стенда.

Я делал все верно, а у меня при проверке оборудования все равно выдаются ошибки!

Дело, будем откровенны, плохо. Не безнадежно, но совсем, совсем «не айс». Причем нельзя исключить что вы действительно делали все верно и это тонкая «фича» вашего, допустим, оборудования хост-компьютера. Или не менее тонкая «фича» драйвера такого оборудования. Или еще что-то в этом духе. Прежде всего щелкайте в окне Summary мастера проверки оборудования кнопку View Report... (ее можно наблюдать на последней иллюстрации). Будет сгенерирована довольно-таки объемная HTML страница которая и откроется в проводнике (на этот раз как раз Internet проводнике). Просмотрите ее фокусируя свое внимание на любых кусочках информации связанных с ошибками. Ясно ли вам какие тесты окончились неудачей? Понятно ли вам сообщение об ошибке? Содержит ли такое сообщение характерный номер ошибки, могущий выступить в роли ключа поиска дальнейшей информации в Гугле? Если ошибками заканчивается целая группа тестов (особенно следующих друг за другом) постарайтесь установить тест с «корневой» ошибкой. Обычно достаточно исправить ее, что бы «исправились» и остальные тесты. Если анализ выявил такой «ведущий» проблемный тест — сосредоточьте свои усилия на решении проблем связанных именно с ним. В целом ничего утешительного автор сообщить вам не может: причин приводящих к провалу всего теста проверки оборудования — куча, чего никак не скажешь об объеме информации повествующей о способах устранения этих причин. Однако (опять же, по опыту автора), есть одна ошибка возникающая при описываемом процессе тестирования чаще других и вот ее-то мы разберем, вкупе с методиками избавления от оной.

Идентифицировать нашу «популярную» ошибку несложно. Если случилась именно она, то в отчете доступном для изучения после клика на кнопке View Report... мы будем видеть, что проблемными оказались тесты из группы сетевых (Network) проверок. Скорей всего проблемным будет тест Validate IP Configuration, или Validate Cluster Network Configuration, или даже оба сразу. Пояснение для ошибки будет идентичным, неважно какой именно тест завершился провалом:

There was an error initializing the network tests.
There was an error creating the server side agent (CPrepSrv).
Creating an instance of the COM component with CLSID {E1568352-586D-43E4-933F-8E6DC4DE317A} from the IClassFactory failed due to the following error: 80070005.

Если это именно ваш случай — частично вас поздравляю, все не так плохо как могло бы быть. С достаточно большой долей вероятности проблему мы решим, поскольку в 95% случаев указанная ошибка вызвана одной из трех причин. В следующем списке они отсортированы от наиболее вероятной к менее вероятной.

Причина 1. Вы не вняли предупреждению автора данному им в самом начала мануала и не сменили SID-ы (Security Identifier) на виртуальных машинах-нодах. Методика исправления очень простая (но нудная) — вновь создайте из исходной («мастер») виртуальной машины два клона, назовите их clustNodeA и clustNodeB, на этот раз уж точно обработайте их Sysprep-ом и, собственно, повторите все шаги данного мануала затрагивающие эти две машины до шага 13-го включительно. Рутина, да — а кто виноват?

Причина 2. Если предыдущая причина точно не ваш вариант, то на втором месте у нас причина связанная с ошибкой аутентификации COM-объекта, о котором прямо сообщает текст ошибки приведенный чуть выше. Что бы «пофиксить» ее сделайте следующее.

  • логинимся на clustDC (нет, никакой опечатки нет, именно на домен-контроллер. И помните о наших правилах «корректного логина»!);
  • из окна Run запускаем утилиту dcomcnfg;
  • в оснастке консоли Component Services распахиваем последовательно узлы Component ServicesComputers и вызываем окно свойств элемента My Computer
    Component_Services_My_Computer_Properties
  • идем на закладку Default Properties и из выпадающего списка Default Impersonation Level выбираем пункт Impersonate
    My_Computer_Properties_Default_Impersonation_Level
  • щелкаем OK и соглашаемся с предупреждением;
  • перегружаем (обязательно!) наш домен-контроллер и повторяем процедуру тестирования как она описана в текущем шаге

Причина 3. Если не помогло ни первое, ни второе — попробуйте способ «полу-шаманский». Сам автор не видит большого физического смысла в последующем наборе шагов, однако не исключен смысл... мета-физический? В любом случае, по неоднократным заявлениям на форумах и блогах этот способ так же помогал администраторам пройти процедуру тестирования оборудования, а поскольку к этой точке изложения терять нам уже абсолютно нечего, то...

  • выведите из состава домена обе ноды — clustNodeA и clustNodeB. Иными словами верните их в рабочую группу по умолчанию;
  • сделайте reboot как двум указанным машинам, так и домен-контроллеру (clustDC);
  • затем верните обе машины в домен как мы делали это в 9-м шаге данного мануала;
  • повторите текущий 13-й шаг с самого начала.

В любом случае, какие бы ошибки нам не показывал заключительный отчет и какие бы причины к ним не вели «генеральное» правило очень простое:

Мы не можем продолжать построение тест-стенда пока на заключительной странице Summary мастера Validate a Configuration Wizard мы не обнаружим фразу Tested has completed successfully, точка.