21. Создать на активной ноде второй виртуальный сервер SQL2NET и инсталлировать на него экземпляр SQL Server с именем SQL2INST.
Оставаясь все на той же машине-ноде A, из оснастки консоли Failover Cluster Manager которой мы только что проверили факт успешного добавления 5-го общего диска в кластер, запускаем уже знакомый нам установщик SQL Server. Поскольку установка второго инстанса на 90% совпадает с установкой инстанса первого, процесс будет показан и описан максимально лаконично, выделяются лишь значимые различия в двух инсталляциях. Итак — приступаем.
Installation→New SQL Server failover cluster installation, несколько щелчков по OK/Install/Next до страницы Feature Selection где вновь отмечается наш «джентльменский набор»: движок, репликация, полнотекстовый поиск. Next. На странице Instance Configuration мы указываем свое собственное (т.е. уникальное) имя для идентификации нового экземпляра в сети (для этого служит поле SQL Server Network Name). По сути, новый инстанс будет представлен как новый виртуальный сервер для будущих SQL-юзеров нашей системы. Однако с точки зрения именно самого SQL Server это должен быть только именованный инстанс, поскольку он считает что дефолтный инстанс уже существует. Иными словами, мы на этой странице не можем указать SQLonCLUST в поле SQL Server Network Name. Против этого «возражает» виндовый кластер, считающий что ресурс (сервис это такой же ресурс как и диск, к примеру) с таким именем уже существует. Но и если мы введем в это поле уникальное значение выбрать Default instance у нас тоже не получится — «взбрыкнет» уже SQL Server которому не «понравятся» два инстанса с одним именем (MSSQLSERVER). Поэтому, как ни покажется это странным, уникальными должны быть и сетевое имя нового инстанса, и его собственное имя. Остановимся, допустим, на вариантах SQL2NET и SQL2INST соответственно.
Next несколько раз до страницы Cluster Network Configuration, где так же как и в прошлой инсталляции очищаем галочку DHCP, но IP-адрес вводим, понятно, свой. Вариант 192.168.81.100 выглядит подходящим.
Next до страницы Server Configuration. Вводим наш дежурный clustDom\adm с паролем, Next. На странице Database Engine Configuration добавляем того же пользователя в число будущих SQL-администраторов. Закладка Data Directories нам в этот раз не пригодится — у нас всего один диск. Хотя, для контроля, загляните на нее и удостоверьтесь, что все данные пойдут в различные папки одного и того же диска X. Если все в порядке — Next. «Пробегаем» до страницы Ready to Install, где все еще раз тщательно проверяем. Убедившись, что в настройках будущего инстанса «косяков» нет щелкаем Install. Через некоторое время фиксируем полный успех нашего предприятия.
Закрываем окно инсталлятора.
Теперь, если следовать логике установки предыдущего инстанса самое время запустить установку сервис-пака для нового именованного экземпляра. Однако делать это мы не будем. Это потому, что со вторым инстансом мы хотим «разыграть» такой сценарий: SQL Server 2008R2 установлен на 2 ноды, сдан в эксплуатацию, и успешно работает день-месяц-год или просто какое-то время. И вот после этого «какого-то» времени выходит сервис-пак (а равно hot-fix, а равно cumulative update). И нам нужно применить все это хозяйство к «живому» SQL-кластеру. Когда кластер создан, но пока не отдан «в работу» все просто — применяем апдейты как если бы каждая нода была независимым SQL сервером. Именно так мы поступили с дефолтным инстансом. А вот если на кластерном SQL-сервере уже вовсю пользователи трудятся — что тогда? Вот мы и посмотрим на этот процесс буквально через пару минут.
22. Добавить к виртуальному серверу SQL2NET пассивную ноду.
Но прежде, понятно, нам нужно закончить формирование кластера для второго SQL-экземпляра, и мы отправляемся на ВМ clustNodeB. Запускаем на ней SQL Server инсталлятор со все того же DVD-образа. Как легко догадаться, процесс крайне похож на добавление второй ноды к предыдущему инстансу, дефолтному. А поэтому вновь лишь «избранные места» данного процесса. Installation в главном окне SQL Server Installation Center, ссылка Add node to a SQL Server failover cluster. OK/Install/Next до страницы Cluster Node Configuration. Контролируем, что нода добавляется именно к именованному инстансу.
Next, дважды вводим пароль, Next до страницы Ready to Add Node. Проверяем что нигде не ошиблись и Install. Отмечаем наш пусть скромный, зато очередной успех.
Закрываем инсталлятор.
23. Проинсталлировать SP1 для SQL Server 2008R2 на уже кластеризованный виртуальный сервер SQL2NET.
Так вот, сценарий: организовали кластер, «запустили» пользователей, и тут — БАЦ! — вторая смена обновление для SQL Server в виде сервис-пака/хот-фикса/кумулятивного апдейта. Как грамотно все поставить и ничего при этом не порушить? Сразу скажу, что процесс к которому мы переходим кардинально отличается от такового даже еще на 2005-м сервере. Так что если ваш опыт ограничивается этой и более ранней версиями сервера — не пропускайте этот раздел! Начиная с сервера 2008-го (без R2, но R2, понятно, тоже попадает в эту группу) схема применения всего вышеперечисленного к работающему SQL-кластеру такая:
- применить сервис-пак/хот-фикс/кумулятивный апдейт на пассивной ноде;
- произвести «failover вручную», т.е. форсировать передачу управления всеми ресурсами кластера пассивной ноде и забрать такой контроль у ноды активной;
- теперь, когда бывшая активная нода стала пассивной (юзеры продолжают работать как ни в чем ни бывало с новой активной нодой) применяем тоже самое на ней;
- опционально, если хотим полного возвращения системы к исходному состоянию, вторично форсируем передачу управления к оригинальной активной ноде.
Вот давайте этот план попробуем реализовать. Мы сейчас находимся все еще на ВМ clustNodeB после успешного ее добавления в кластер. Очень удачно, поскольку как раз эта нода — пассивная (убедитесь в этом через ее Failover Cluster Manager). Запускаем установщик сервис-пака на ней и, собственно, ставим SP1 на нашу пассивную ноду традиционным методом «Next-до-упора». Убедившись что все установлено, и ошибок-предупреждений нет, открываем на этой же машине (clustNodeB) Failover Cluster Manager. В узле нашего кластера clust0adm.clustDOM.local выбираем под-узел SQL2INST.
Дважды проверьте, что вы выбрали именно второй, именованный инстанс! В контекстном меню именно этого под-узла выбираем Move this service or application to another node→Move to node clustNodeB.
Подтверждаем передачу «полномочий».
Этот процесс достаточно быстрый, но все же не моментальный. Ждем пару десятков секунд пока все ресурсы SQL2INST будут выведены в Online, а он сам передан под управление ноде B.
Вот теперь идем на бывшую активную (а ныне пассивную) ноду A и применяем тот же SP1 на ней. Все хорошо? Тогда точно так же как и на предыдущей ноде передаем управление на ноду исходную, A.
Если все закончилось удачно — поздравляем себя! У нас есть два рабочих экземпляра SQL Server 2008R2 SP1 на двух нодах в конфигурации Active/Passive.
24. Инсталлировать на ВМ-клиенте клиентскую часть SQL Server.
Последнее усилие — поставить на машину clustWork (которая уже просто застоялась без дела) клиента SQL Server (а проще говоря — студию) и приступать к экспериментам с кластером. Запускаем на указанной машине в который уж раз все тот же инсталлятор SQL Server. Поскольку на ней не была включена роль Application Server (она ей, собственно, и не нужна), нас спросят (или скорей потребуют) о необходимости предварительной инсталляции .NET Framework, соглашаемся. В открывшемся SQL Server Installation Center как всегда выбираем Installation, однако на этот раз в списке ссылок справа выбираем New installation or add features to an existing installation, поскольку нам не нужны ни кластеры, ни даже сам SQL Server. Нам единственно нужен его клиент. OK/Install/Next до страницы Feature Selection где отмечаем всего два пункта — Client Tools Connectivity и Management Tools - Complete (что в свою очередь отметит ее «базовый» пункт Management Tools - Basic).
И это все, Next/Install до конца визарда и закрываем его по завершению успешной инсталляции. Хоть это и не столь принципиально как в предыдущих инсталляциях, все же поставьте SQL Server сервис-пак 1 и на эту машину, дабы обновить те немногочисленные SQL-компоненты что были нами только что установлены.
25. Подключиться из ВМ-клиента к обоим виртуальным серверам и убедиться в работоспособности кластера.
Для начала проверим тот факт, что клиентская машина (clustWork) «видит» все что ей положено «видеть» в кластере. Запустим на ней такой тестовый файлик 2.cmd:
ECHO --- Start test cluster---
ping -n 1 192.168.81.99
ping -n 1 SQLonCLUST
ping -n 1 192.168.81.100
ping -n 1 SQL2NET
PAUSE
Все пинги должны быть успешны. Это будет означать видимость для клиента обоих виртуальных серверов, причем как по их IP, так и по их именам.
Ну что же — вот и «час истины» наступает. Сейчас мы выясним, были ли все наши действия, усилия, переживания и хлопоты корректными и привели ли они к желаемому результату. Запускаем из меню Start студию. В окне подключения указываем первый (дефолтный) инстанс. Поскольку он дефолтен, достаточно указать имя сервера (как о нем «думает» клиент!) — SQLonCLUST.
Имя инстанса указывать не надо. Щелкаем по кнопке Connect и...
Отлично, просто отлично! Отключаемся от этого сервера и вновь вызываем окно подключения дабы попробовать работоспособность второго, именованного, инстанса. Вот тут как раз придется указывать и имя сервера, и, через косую черту, имя инстанса. А вместе это будет SQL2NET\SQL2INST.
Вновь Connect и вновь успех!
Мы получили полнофункциональный стенд для любых действий и операций в кластерном окружении, великолепно!!
Что дальше? Да что угодно! Все зависит лишь от вашей фантазии и конечной цели. Инструмент ее достижения у вас в руках — действуйте. Для примера будет интересно убедиться, правдивы ли те «мифы и предания», что утверждают будто бы при «падении» одной из нод кластера клиенты к ней подключенные вообще ничего не замечают, а продолжают работу как ни в чем не бывало. Попробуем? Зайдем, для начала, на любую из нод (допустим A) и через ее Failover Cluster Manager проконтролируем кто управляет в данный момент обеими SQL-серверами. Это должна быть все та же clustNodeA. Кстати, хотя этот мануал ни разу не о кластерах как таковых и не об управлении ими, но раз уж мы находимся здесь, в Failover Cluster Manager, обратите внимание какие интересные возможности он вам предлагает. Допустим, вы видите: у нас есть такой ресурс как SQLonCLUST. Хорошо, а от каких прочих ресурсов он зависит? Должны ли для его успешной работы (даже проще — успешного запуска) находится в состоянии Online какие-то диски (и если да — какие)? Сети (networks)? Прочие софт-ресурсы, такие как приложения или сервисы? Если такой вопрос у вас возник выбирайте в левой колонке этот самый ресурс (SQLonCLUST), а в колонке правой щелкайте ссылку Show Dependency Report, либо выберите одноименный пункт из контекстного меню. Будет сгенерирована Web-страница и показана вам в Internet Explorer. Наглядно? Впрочем о возможностях Failover Cluster Manager можно отдельную статью писать, вернемся к задаче которую мы перед собой поставили.
Так вот, заметим что активной нодой в настоящий момент является A и вернемся на клиентский компьютер (clustWork). Там откроем в редакторе студии две новых вкладки. Первая пусть будет подключена к SQLonCLUST, а вторая — к SQL2NET\SQL2INST. В первой наберем:
1 2 3 4 5 6 7 8 9 10 11 | CREATE DATABASE DB1 GO USE DB1 GO CREATE TABLE T1(Col1 int, Col11 varchar(15)) GO INSERT INTO T1 VALUES (1, 'DB1') INSERT INTO T1 VALUES (2, 'DB1') USE DB1 GO SELECT *, SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS ActiveNode FROM T1 |
А во второй:
1 2 3 4 5 6 7 8 9 10 11 | CREATE DATABASE DB2 GO USE DB2 GO CREATE TABLE T2(Col2 int, Col22 varchar(15)) GO INSERT INTO T2 VALUES (21, 'DB2') INSERT INTO T2 VALUES (22, 'DB2') USE DB2 GO SELECT *, SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS ActiveNode FROM T2 |
И выполним оба отрывка. Результаты первой вкладки:
1 DB1 CLUSTNODEA
2 DB1 CLUSTNODEA
Второй:
21 DB2 CLUSTNODEA
22 DB2 CLUSTNODEA
Т.е. все работает и команды исполняет физический компьютер с указанным именем. Теперь в обоих вкладках сотрите все строки кода кроме трех последних. Иными словами оставьте лишь строку переключения в контекст соответствующей базы и строку извлечения данных. Если хотите, вновь запустите укороченные версии обоих скриптов и убедитесь, что, разумеется, ровным счетом ничего не изменилось, те же самые резалт-сеты. Теперь идем на компьютер-активную ноду (clustNodeA) и, не дрогнувшей рукой, делаем ему Shut down, эмулируя тем самым его полный отказ. Чуть подождем, что бы на выключаемом компьютере определенно завершились все сервисы. Вернемся на компьютер-клиент (clustWork) и повторно выполним оба оставшихся скрипта. Что мы видим?
A transport-level error has occurred when sending the request to the server. (provider:
TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
Да, вот так. Это потому, что при наступлении события failover (а мы выключением активной ноды именно его и инициировали) клиент теряет текущее соединение с сервером. То есть вообще. И никакого «повторно-автоматического» реконнекта не случается. Однако, не закрывая вкладок редактора, попробуем сделать им ручной реконнект (кнопка Connect в тулбаре студии или Connection→Connect... в контекстном меню самой вкладки). Соединяем их с теми же экземплярами к которым они были подключены до «падения» активной ноды, и имена целевых серверов указываем те же самые. Подключились! Уже неплохо. Вновь исполняем наши укороченные скрипты. Резалт-сеты практически идентичны только что приведенным, только активная нода сменилась с CLUSTNODEA на CLUSTNODEB. Выводы из этого 3-х минутного теста:
- клиент, если ему это интересно, всегда может узнать какому именно физическому серверу направляются его запросы;
- случившийся failover — это полное и безусловное отключение всех подключенных в настоящий момент клиентов. Точка. Кстати, если в этот момент случились открытые и незавершенные транзакции — они будут безусловно откачены (rolled back);
- единственный выход для пользователя после failover — сделать самое обычное подключение когда резервная нода примет на себя управление кластером;
- промежуток времени между «падением» бывшей активной ноды и тем моментом когда новая активная нода готова принять пользовательские подключения является «разумно-коротким». Далеко не мгновенным, но через 10 сек. можно предпринять попытку подключения, хотя нормальным, даже хорошим, считается промежуток в 15-20 сек. Через минуту подключение можно практически гарантировать даже на очень загруженной системе, хотя имели место практические примеры, когда полностью исправный кластер переключался с ноды на ноду более 2-х минут;
- при переходе управления от ноде к ноде адрес целевого сервера с точки зрения клиента не меняется. В этом смысле failover на кластере прозрачен для клиента;
- никакого true transparent client redirection, предлагаемого, к примеру, технологией зеркализации баз данных, нет и в помине.
Заметьте — автор вовсе не говорит, что используя на стороне сервера failover cluster как технологию высокой доступности у вас нет ни единого шанса создать для конечного пользователя иллюзию прозрачного переключения того клиента с которым он работает (а работать он будет, надо думать, отнюдь не со студией) к резервной ноде кластера. Однако тема «SQL кластер и его клиенты», это, как говорится, совсем иная история.
Успехов и приятных открытий в мире SQL-кластеров! Увидимся, пока.