Делаем апгрейд серверов в SQL Server AlwaysOn. Вкратце план таков:
1. Вводим новые сервера в кластер - выполнено
2. Синхронизируем БД в группу высокой доступности на новых нодах - выполнено
3. Делаем файловер на новые сервера - выполнено
4. Исключаем старые сервера из AlwaysOn и кластера.

И сейчас заказчик хочет сделать ход конем пункт:
5. Меняем на живую в прод ИП адреса нод на те которые были на старых серверах
6. Меняем имя нод кластера на имена старых серверов

Есть подобные кейсы кто здесь делал?


Может тупо у меня не хватает квалификации в подобных переименованиях, да опыта такого у меня не было ))). Поделитесь если у кого было подобное

OBGДед-Папыхтет,
Можно поиграть в "шашки": добавить временно еще одну ноду, на первой ноде убрать группу доступности, вывести из кластера, переименовать и поменять IP, потом включить в кластер и добавить группу доступности, потом сделать то же самой для второй ноды. Временную ноду удалить.
Бд в 4 тема, синхронизация олвизон была больше суток. Хотят быстро это сделать не за неделю

Slava_Nikя бы не делал переименовани, хотя вроде это можно.
я бы сделал сейчас так: вывел ноду из группы с базами, переименовал как надо, IP , добавил назад, при этом на второй ноде не делал бекап логов во время переименования, либо потом эти логи накатил на выведенную ноду, после введения назад в группу синхронизация будет минимальная. В итоге примерно время часа 2-3 на все про все.
Да можно думаю, если отключить на какое то время штатный бэкап лога... можно и без полной синхронизации БД сделать. Вывести из кластера ноду, переименовать и переназначить айпи... скл не трогать, далее снова ввести в кластер и в олвизон добавить ноду без бэкапа а опция join only. По идее должна сработать...

a_voroninSlava_Nika_voronin,

когда вы выводите из кластера чать "организма", вы можете что угодно с выведенным узлом делать, потом его заново вводите тогда у вас снова единый орагнизи.
так же и с Listener, если в одной подсети, то просто меняете его IP с выводом из Alwayson и затем назад его вводите.

А вы попробуйте ввести его назад и посмотрите, что на практике будет.
Попробовал - задачу поставили.

Короче... все таки озадачили переименованием серверов (узлов кластера). Причем работы велись на 4х кластерах было старых 8 узлов, и новые 8 узлов добавили. Старые удалили, после 8 узлов переименовывали. План вкратце такой был по переименованию:
1. в каждом из 4х кластерах по 2 новые ноды. Отключаем бэкапы журнала транзакций что бы синхронизацию можно было делать без бэкап рестора в олвизон.
2. выводим пассивные реплики (по одной ноде из каждого кластера) из кластера.
3. выведенные ноды переименовываем, меняем айпи на старые имена.
4. вводим в кластер, вводим в олвизон но без бэкап/рестор, а join only и ждем синхронизацию БД.
5. делаем файловер - меняем активные реплики на введенные ноды
6. выводим снова пассивные ноды из кластера
7. переименовываем их
8. вводим в кластер
9. ждем синхронизацию.
10. включаем бэкапы журналов транзакций.

Итак что сделано... пункты 1-8 полностью прекрасно отработали - БД синхронизированы, все тип-топ. Так можно делать ))))
пункт 9 на 2х кластерах отработал норм - кластера в рабочем состоянии, но на других 2х кластерах приветЖопа началась. В кластерной БД c:\windows\Cluster\clustdb на одном сервере почему при evict в кластере на активной ноде удалилось имя, на пассивной не удалилось - осталось. На другом кластере не получалось вывести его в онлайн, ожидания HADR на скл не дают перегрузить скл, БД в состоянии not syncronized. Прыгал вчера до 20 вечера. Проблемный второй кластер заработал после перезагрузки сервера (вообще не понятно по какой причине он не мог запуститься). Первый проблемный кластер пришлось удалить кластерную службу из выведенной ноды и заново переставить, после кластер запустился - нода добавилась.

Щас продолжается эпопея со 2м проблемным кластером, началось с того что синхронизация на пассивную реплику не проходит тупо копится очередь... Час назад перестали коннекты к нему приходить. Привет в общем )))).
Последний этот кластер, пришлось выводить ноду из кластера заново вводить и синхронизировать через бэкап/рестор - так заработало.... Причем... в логах винды и скл сервер ошибок не было...

Мистика - 2 кластера этим планом норм поднялись с 2мя проблема была