16. Создать на активной ноде первый виртуальный сервер SQLonCLUST и инсталлировать на него экземпляр SQL Server «по умолчанию».
Наконец-то все готово к главному — установке SQL Server. Если оснастка консоли Failover Cluster Management все еще открыта после успешной установки сервиса MS DTC, то закрываем ее и, оставаясь на все той же ноде A, запускаем Setup с образа DVD-дистрибутива SQL Server 2008R2. Предварительно, разумеется, подключив носитель с таким образом к указанной виртуальной машине. В главном окне установщика, SQL Server Installation Center, переключаемся на закладку Installation и щелкаем ссылку New SQL Server failover cluster installation.
На странице Setup Support Rules щелкаем OK, затем несколько раз Next и, наконец, Install для установки файлов поддержки будущего процесса инсталляции. В очередном окне Next и выходим на страницу Feature Selection где нам нужно выбрать состав нашего будущего экземпляра SQL сервера. Мы остановимся на одном из минимальнейших наборов: движок, репликация, полнотекстовый поиск.
Больше не отмечаем ничего, Next. На странице Instance Configuration самое важное поле, безусловно, SQL Server Network Name. Это есть имя нашего виртуального сервера, коим кластер будет представляться для клиентов. Иными словами, наши SQL-юзеры будут подключаться именно к этому «SQL серверу» (как они считают). Введем сюда, к примеру, SQLonCLUST. Все остальное оставляем по умолчанию, но лишний раз замечаем себе, что мы готовимся проинсталлировать дефолтный экземпляр сервера.
Next. На странице Disk Space Requirements снова Next и мы достигаем страницы Cluster Resource Group. На ней перечислены все ресурсные группы нашего кластера, в данном случае их три. Если бы это было возможно, то новый сервис (SQL Server) можно было бы включить в одну из существующих групп, однако ни одна из существующих групп не готова принять новый ресурс (судя по иконкам этих групп в колонке Qualified), поэтому у нас единственный выход — создать новую группу ресурсов и поместить наш будущий сервер в нее. Имя такой группы можно ввести в поле SQL Server cluster resource group name или принять вариант предложенный по умолчанию. Останавливаемся на последнем.
Next. На очередной странице Cluster Disk Selection следует выбрать те диски, с которыми сможет работать будущий сервер. Т.е. именно на них разместится информация вносимая нашими пользователями в базы данных. Один диск уже отмечен, отмечаем и второй, поскольку мы решили, что у нас базы данных и их логи (журналы транзакций) будут разнесены по разным дискам.
Next. Очередная страница, Cluster Network Configuration на которой нам следует указать тот IP-адрес по которому наш SQL Server будет доступен для наших клиентов (разумеется по публичной сети). Т.е. это есть ни что иное, как IP-адрес того виртуального сервера, которым кластер представляется нашим клиентам. Первым делом стираем галочку DHCP — мы хотим для нашего сервера статический IP. А затем в поле Address вводим, к примеру, 192.168.81.99.
Next. На странице Cluster Security Policy соглашаемся с опцией по умолчанию Use service SIDs (recommended). Для желающих разобраться почему это оптимальный выбор рекомендую отличную статью в MSDN, мы же тем временем щелкаем Next. На странице Server Configuration указываем что и сервис движка, и сервис SQL-агента будут запускаться под учеткой доменного администратора clustDom\adm, что, разумеется, совершенно не правильно с точки зрения безопасности при создании «боевого» кластера. Однако, поскольку мы для нашей тест-площадки уже приняли на вооружение девиз «чем проще — тем лучше» остановимся на этой учетке, для ввода логина-пароля которой прибегнем к помощи кнопки Use the same account for all SQL Server services.
Обратите, кстати, внимание, что тип запуска обоих сервисов — Manual, что отличается от привычного нам Automatic и что есть совершенно правильно. В условиях кластера за своевременный запуск сервиса (как и любого прочего ресурса) отвечает управляющая нода. И более того, если вам в голову придет интересная, но совершенно зряшная мысль о смене типа запуска сервисов то у вас ничего не получится: соответствующие комбобоксы на текущей странице мастера установки просто заблокированы. Так что щелкаем Next. Очередная страница Database Engine Configuration и ее закладка Account Provisioning. Тут нам требуется внести такую учетную запись (доменную, разумеется), которая будет распознаваться будущим сервером как администраторская. Иными словами сервер добавит ее в фиксированную серверную роль sysadmin. Да, вы уже догадались — и в этом качестве вновь выступит наш любимый clustDom\adm. Поскольку мы в настоящий момент залогинены именно под ним достаточно будет щелчка по кнопке Add Current User.
Вторая закладка той же страницы — Data Directories. Тут нас все устраивает за одним исключением — дефолтное положение файлов журнала транзакций (лога). Сейчас оно совпадает со всеми прочими положениями и указывает на диск T:, что есть диск для данных, согласно нашему плану. Сменим местоположение для указанного типа файлов на, допустим, L:\logFiles.
Заметьте, кстати, что мы меняем путь для журналов транзакций лишь пользовательских баз данных, аналогичные файлы системных баз останутся рядом с файлами данных тех же баз, причем путь к последним изменить невозможно, см. метку System Database Directory на последней иллюстрации. Next и еще раз та же кнопка на страницах Error and Usage Reporting и на Cluster Installation Rules. Страница Ready to Install и наш последний шанс «исправить пока не поздно». Проверьте все установки и щелкайте на Install. Дожидаемся конца установки и с удовлетворением отмечаем — пока все идет отлично!
Закрываем окно инсталлятора.
17. Применить к установленному серверу SP1 для SQL Server 2008R2.
Сразу же и не мешкая запускаем установку первого сервис-пака для только что установленного SQL Server, в моем случае это был файл SQLServer2008R2_x64_SP1.exe. Этот процесс в описании не нуждается совершенно, простой «Next-до-упора». Теперь можно удостовериться, что сервис SQL Server успешно захостился кластером. Открываем на все той же ноде A Failover Cluster Management, узел clust0adm.clustDOM.local→Services and applications→SQL Server (MSSQLSERVER). В правой панели убеждаемся что активен как сам сервис, так и все компоненты от которых он зависит.
Заодно можно удостовериться, что «рулит» сервисом именно нода A, см. поле Current Owner на последней иллюстрации.
18. Добавить к виртуальному серверу SQLonCLUST пассивную ноду.
Теперь у нас есть полностью готовый к функционированию SQL Server на базе кластера. Но у нас по прежнему нет high-availability решения, т.к. наш сервис (SQL Server) управляется всегда лишь одной нодой. То есть мы имеем точно такой же обособленный SQL-сервер который можно создать и без такой объемной работы что была нами осуществлена к данному моменту. Что бы оправдать затраченное время надо добавить к SQL-кластеру хотя бы еще одну ноду. Займемся этим прямо сейчас.
На другой (и только на ней!) машине-ноде B запускаем программу инсталляции SQL Server как мы это делали совсем недавно на ноде активной. Вновь выбираем закладку Installation в главном окне установщика SQL Server Installation Center, однако на этот раз справа щелкаем по ссылке Add node to a SQL Server failover cluster. Не ошибитесь, на этот раз мы не хотим устанавливать новый экземпляр на кластер (ссылка New SQL Server failover cluster installation) как это было на ноде A, мы хотим добавить ноду в уже существующий экземпляр SQL сервера. На странице Setup Support Rules щелкаем OK и далее несколько раз Next до страницы Cluster Node Configuration. Здесь мы просто проверяем что нода добавляется именно в тот кластер в какой мы и хотим (а поскольку таковой у нас один то ошибиться невозможно).
И вновь Next. На странице Service Accounts от нас снова ничего не зависит, единственное что мы можем (и должны) сделать это дважды впечатать пароль от учетной записи clustDom\adm.
Next несколько раз вплоть до страницы Ready to Add Node на которой проверяем еще раз выставленные опции и щелкаем Install. После окончания инсталляции нас предупредят, что к ноде A был применен патч, а к текущей ноде, B — нет.
Щелчком по Yes пообещаем немедленно применить соответствующий патч (SP1) и ко второй ноде тоже. Кроме указанного момента к остальному у инсталлятора замечаний нет.
Щелчком по Close закрываем мастер добавления ноды, да и главное окно инсталлятора SQL Server можно так же закрыть.
19. Применить SP1 для SQL Server 2008R2 к пассивной ноде и убедиться, что виртуальный сервер SQLonCLUST способен управляться любой из двух нод.
Разумеется, как мы это и пообещали, сразу же применяем SP1 к ноде B. Делаем это ровно так же, как мы действовали с нодой предыдущей — «Next-до-упора». По завершению процесса установки SP1 на вторую ноду можно проверить, что в составе SQL кластера теперь 2 ноды. Возвращаемся на компьютер-ноду A, открываем Failover Cluster Management, узел clust0adm.clustDOM.local→Services and applications, щелчок правой кнопкой мыши по под-узлу SQL Server (MSSQLSERVER). Смотрим (но не нажимаем!) пункты контекстного меню Move this service or application to another node→Move to node clustNodeB.
Значит действительно, теперь наш SQL Server может управляться как первой нодой, так и второй и мы в любой момент времени способны передавать управление им!
20. Создать в iSCSI Target добавочный виртуальный диск.
Теперь, дабы после завершения настройки всего тест-стенда у нас был простор для маневров и количество возможных экспериментов с итоговой системой многократно возрасло, установим на кластер второй, именованный, SQL-инстанс. В этом нет ничего сложного, но нужно учитывать, что каждый новый инстанс (экземпляр) должен иметь в своем полном распоряжении хотя бы один shared disk. А у нас-то свободных и не осталось, все из 4-х SAN-дисков заняты! Поэтому, для реализации нашей идеи первым делом идем на виртуальную машину clustSAN и добавляем в наше виртуальное же дисковое хранилище еще один диск. Да, именно один, а не два, поскольку на втором SQL экземпляре мы не будем разносить базы и их журналы транзакций по разным дискам, как мы это делали в случае первого и дефолтного инстанса. Параметры этого нового (пятого по счету) диска будут такими.
| Имя и путь к файлу эмулирующему диск | Размер диска в MB | Description в визарде создания виртуального диска | Назначение диска | Метка диска | Буква диска |
| c:\x.vhd | 1200 | This is disk for second SQL instance | Диск данных и логов для второго экземпляра SQL | SecondInst | X: |
По сути нам предстоит сделать уже знакомую работу состоящую из двух частей. Первая часть — создание виртуального диска — описана в шаге 6-м настоящего мануала. Часть вторая — вывод диска в он-лайн, его инициализация и подключение в виде локального к обеим нодам — в шаге 10-м. Вся необходимая информация нужная вам для завершения обеих частей приведена в последней таблице — вперед, у вас получится! Ну а завершится этот процесс переключением на машину clustNodeA, выводом нового диска в Online, его инициализацией и присваиванием ему буквы X, вкупе с назначением его единственному тому метки SecondInst. Сопутствующие операции (а именно: вывод нового диска в Online и присвоение ему той же буквы X) проводим и на clustNodeB, а потом вновь возвращаемся к ноде A и открываем на ней уже полюбившийся нам Failover Cluster Manager. Ведь диском X пока может пользоваться только сама нода A (ну и B, конечно), но не кластер. Сделаем упомянутый диск кластерным ресурсом. Раскрываем в Failover Cluster Manager узел нашего кластера (clust0adm.clustDOM.local), и в контекстном меню его под-узла Storage выбираем пункт Add a disk.
В окне Add Disk to a Cluster просто щелкаем OK — у нас единственный претендент на включение в кластер. В той же панели относящейся к под-узлу Storage убеждаемся что у нас теперь есть один свободный диск.
Заодно контролируем статус диска (должен быть Online) и его текущего владельца (должна быть нода A). Если все так и есть — Failover Cluster Manager можно закрыть.