Очень давно хотел попробовать развернуть SQL Server Failover Cluster ("Кластер отработки отказа SQL Server" в русской редакции оного), но то не хватало времени, то желания. А на днях скачал "Introducing Microsoft SQL Server 2012", начал разбираться с Availability Groups (боюсь даже представить как их обзовут в руссифицированной версии) и понял, что нихрена не понимаю - надо ставить и разбираться.
С помощью чудесной серии статей SQL кластер на VMware Workstation (аж из 11-ти статей!), Windows-кластер был развернут буквально за три часа. Но, увы, после того как я попробовал установить SQL Server 2012, то понял, что в дальнейшем мне надо бы заранее читать требования к ПО. Для установки SQL Server 2012 требуется Windows Server 2008 R2 Service Pack 1, а я, умница такая, ставил просто Windows Server 2008 R2.
И, пока сервис-пак для операционки качался, подумал, что неплохо бы вообще поиграться с кластером. Кто его знает когда это пригодится. Во-первых, в кластере был установлен SQL Server 2008, которого вполне себе удовлетворяла операционка без сервис-пака, и было решено попробовать следующее:
1. Установить сервис-пак на SQL Server 2008 R2 в кластере и посмотреть - есть тут какие-нибудь хитрости или нет
2. Установить сервис-пак на Windows Server 2008 R2 и, соответственно, посмотреть какие хитрости есть тут.
В этом посте я буду писать только про установку сервис-пака на SQL Server, а про установку SP на ОС будет отдельный пост.
Итак, у нас есть отказоустойчивый кластер, состоящий из двух нод: ClustNodeA и ClustNodeB; есть "рабочая станция" с установленными клиентскими утилитами для SQL Server: ClustWork. Все это добро уютненько разместилось в сети 192.168.81.0/24. Так же есть контроллер домена ClustDC (домен называется ClustDom, доменный администратор ClustDom\adm) и "эмулятор" SAN ClustSAN. В общем, все как в статьях приведенных выше.
На обоих нодах была совершена "кластерная установка" и теперь у меня есть кластер SQL2008CLUST с ip-адресом 192.168.81.99 - полностью работоспособный.
Теоретически, установка SP не представляет сложности. Нам надо установить сервис пак на пассивной ноде (ClustNodeB), проверить правильность установки, сделать переезд на обновленную ноду и обновить ClustNodeA, ставшую теперь пассивной.
Стоит отметить, что такой механизм работает начиная с SQL Server 2008. В SQL Server 2005 все было по-другому. Сервис пак должен был устанавливаться ТОЛЬКО на активной ноде, на пассивные он устанавливался автоматически, соответственно и downtime в этой редакции был намного больше, чем в последующих.
У меня SQL Server 2008 R2 и, соответственно, downtime должен быть минимальным.
Подключаюсь к пассивной ноде ClustNodeB и запускаю установку:
Пока устанавливается сервис-пак, я проверяю доступность нашего кластера. С машины ClustWork подключаюсь к sql2008clust и выполняю запросы:
SELECT SERVERPROPERTY('IsClustered')
SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS').
Результат представлен на рисунке:
Первый говорит о том, что этот экземпляр кластеризованный (IsClustered = 1), а второй о том, что физически SQL Server сейчас запущен на ноде ClusterNodeA, как и предполагалось.
Установка сервис-пака на пассивной ноде успешно завершилась и теперь нужно "перевести" SQL Server на нее и установить SP на второй ноде.
Итак, SQL Server переехал:
Обратите внимание, на предыдущем скриншоте, в окне обозревателя объектов стоит версия SQL Server: 10.50.1600 - версия без SP, а на последнем - 10.50.2500 - SQL Server 2008 R2 SP1. Так же обратите внимание - если вы решите вернуться на ClustNodeA до тех пор пока она не обновлена, вы увидите такую ошибку:
в то время как на второй, обновленной, ноде (ClustNodeB) подключение проходит нормально и можно выполнять запросы.
Установка обновления на уже пассивной ноде ClustNodeA проходит довольно быстро и успешно. Снова делаю failover, чтобы нода ClusterNodeA вновь стала активной и проверяю версию:
Версия: SQL Server 2008 R2 SP 1 (проверить можно вот здесь: SQL Server builds), активная нода: ClustNodeA.
Таким образом, установка SP на SQL Server Failover Cluster - это не просто, это очень и очень просто (и быстро, downtime равен времени failover'a с активной ноды на пассивную).
С помощью чудесной серии статей SQL кластер на VMware Workstation (аж из 11-ти статей!), Windows-кластер был развернут буквально за три часа. Но, увы, после того как я попробовал установить SQL Server 2012, то понял, что в дальнейшем мне надо бы заранее читать требования к ПО. Для установки SQL Server 2012 требуется Windows Server 2008 R2 Service Pack 1, а я, умница такая, ставил просто Windows Server 2008 R2.
И, пока сервис-пак для операционки качался, подумал, что неплохо бы вообще поиграться с кластером. Кто его знает когда это пригодится. Во-первых, в кластере был установлен SQL Server 2008, которого вполне себе удовлетворяла операционка без сервис-пака, и было решено попробовать следующее:
1. Установить сервис-пак на SQL Server 2008 R2 в кластере и посмотреть - есть тут какие-нибудь хитрости или нет
2. Установить сервис-пак на Windows Server 2008 R2 и, соответственно, посмотреть какие хитрости есть тут.
В этом посте я буду писать только про установку сервис-пака на SQL Server, а про установку SP на ОС будет отдельный пост.
Итак, у нас есть отказоустойчивый кластер, состоящий из двух нод: ClustNodeA и ClustNodeB; есть "рабочая станция" с установленными клиентскими утилитами для SQL Server: ClustWork. Все это добро уютненько разместилось в сети 192.168.81.0/24. Так же есть контроллер домена ClustDC (домен называется ClustDom, доменный администратор ClustDom\adm) и "эмулятор" SAN ClustSAN. В общем, все как в статьях приведенных выше.
На обоих нодах была совершена "кластерная установка" и теперь у меня есть кластер SQL2008CLUST с ip-адресом 192.168.81.99 - полностью работоспособный.
Стоит отметить, что такой механизм работает начиная с SQL Server 2008. В SQL Server 2005 все было по-другому. Сервис пак должен был устанавливаться ТОЛЬКО на активной ноде, на пассивные он устанавливался автоматически, соответственно и downtime в этой редакции был намного больше, чем в последующих.
У меня SQL Server 2008 R2 и, соответственно, downtime должен быть минимальным.
Подключаюсь к пассивной ноде ClustNodeB и запускаю установку:
SELECT SERVERPROPERTY('IsClustered')
SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS').
Результат представлен на рисунке:
Установка сервис-пака на пассивной ноде успешно завершилась и теперь нужно "перевести" SQL Server на нее и установить SP на второй ноде.
Итак, SQL Server переехал:
Установка обновления на уже пассивной ноде ClustNodeA проходит довольно быстро и успешно. Снова делаю failover, чтобы нода ClusterNodeA вновь стала активной и проверяю версию:
Таким образом, установка SP на SQL Server Failover Cluster - это не просто, это очень и очень просто (и быстро, downtime равен времени failover'a с активной ноды на пассивную).
