Модернизация или обновление серверов группы доступности при минимальных значениях времени простоя и потери данных

При обновлении или модернизации экземпляров сервера с переходом от SQL Server 2012 на пакет обновления или более новую версию можно сократить время простоя для группы доступности лишь до единственного перехода на другой ресурс вручную путем последовательного обновления или модернизации. Обновления версий SQL Server принято называть последовательной модернизацией, а обновления текущих версий SQL Server с применением исправлений или пакетов обновления именуются последовательным обновлением.

В этом разделе мы ограничимся обсуждением только модернизаций или обновлений SQL Server. Сведения о модернизациях или обновлениях, относящихся к операционной системе, функционирующей на экземплярах SQL Server с высокой доступностью, см. в разделе Перенос групп доступности AlwaysOn из одних кластеров в другие в целях обновления ОС

Рекомендации по последовательной модернизации или обновлению для групп доступности AlwaysOn

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

• Перед запуском последовательной модернизации или обновления:

  • Получите опыт перехода на другой ресурс вручную по крайней мере на одной из применяемых реплик синхронной фиксации.

  • Защитите данные, выполнив полное резервное копирование базы данных на каждой базе данных доступности.

  • Выполните команду DBCC CHECKDB на каждой базе данных доступности.

• Всегда модернизируйте или обновляйте в первую очередь удаленные вторичные узлы реплики, затем локальные вторичные узлы реплики и, наконец, первичный узел реплики.

• Резервное копирование базы данных, которая находится в процессе обновления, не может быть выполнено. Перед обновлением вторичных реплик настройте автоматическое резервное копирование так, чтобы оно создавало резервные копии только первичной реплики. Перед обновлением первичной реплики измените этот параметр так, чтобы резервное копирование выполнялось только для вторичных реплик.

• Чтобы предотвратить непреднамеренный переход на другой ресурс групп доступности в процессе модернизации или обновления, удалите конфигурацию перехода на другой ресурс доступности со всех реплик с синхронной фиксацией до начала работы.

• Не обновляйте первичный узел реплики перед возобновлением работы группы доступности на обновленном в первую очередь узле со вторичной репликой. В противном случае клиентские приложения могут испытывать влияние более продолжительного времени простоя в ходе модернизации или обновления на первичной реплике.

• Всегда возобновляйте работу группы доступности на узле вторичной реплики с синхронной фиксацией. Если возобновление работы производится во вторичной реплике с асинхронной фиксацией, то в базах данных происходит потеря данных, а перемещение данных автоматически приостанавливается до возобновления его вручную.

• Не проводите модернизацию или обновление узла первичной реплики до модернизации или обновления всех прочих узлов вторичной реплики. Обновленная первичная реплика больше не сможет поставлять журналы на те вторичные реплики, которые еще не были обновлены с переходом на ту же версию. Если перемещение данных к вторичной реплике приостанавливается, то для этой реплики не может осуществляться автоматический переход на другой ресурс, а базы данных доступности становятся подверженными потере данных.

• Перед возобновлением работы группы доступности проверьте, чтобы состоянием синхронизации для цели перехода на другой ресурс было SYNCHRONIZED.

Процесс последовательной модернизации или обновления

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

1. Удаление конфигурации автоматического перехода на другой ресурс на всех репликах с синхронной фиксацией

2. Модернизация или обновление всех удаленных экземпляров сервера, на которых функционируют вторичные реплики с асинхронной фиксацией

3. Модернизация или обновление всех экземпляров локального сервера, на которых в настоящее время не функционирует первичная реплика

4. Возобновление вручную работы группы доступности на вторичной реплике с синхронной фиксацией

5. Модернизация или обновление экземпляра сервера, на котором прежде размещалась первичная реплика

6. Настройка участников автоматического перехода на другой ресурс желаемым образом

В случае необходимости можно выполнить дополнительный переход на другой ресурс вручную, чтобы возвратить группу доступности к ее исходной конфигурации.

Группа доступности с одной удаленной вторичной репликой

Если группа доступности развернута только для аварийного восстановления, то может потребоваться возобновить работу группы доступности для вторичной реплики с асинхронной фиксацией. Такая конфигурация показана на следующем рисунке.

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

1. Модернизация или обновление удаленного сервера

2. Изменение режима фиксации на синхронную фиксацию

3. Ожидание достижения состояния синхронизации SYNCHRONIZED

4. Возобновление работы группы доступности на удаленном узле

5. Модернизация или обновление локального сервера (первичного сайта)

6. Возобновление работы группы доступности на первичном сайте

7. Изменение режима фиксации на асинхронную фиксацию

Режим синхронной фиксации не представляет собой рекомендуемую настройку для синхронизации данных на удаленном узле, поэтому в клиентских приложениях может обнаруживаться непосредственное увеличение задержки базы данных после изменения этого параметра. Кроме того, выполнение перехода на другой ресурс приведет к тому, что все неподтвержденные сообщения журнала будут отброшены. Количество отброшенных сообщений журнала может быть весьма большим из-за высокой задержки сети между этими двумя сайтами, а это приведет к тому, что клиенты столкнутся с увеличением количества сбоев транзакций. Можно свести к минимуму отрицательное воздействие на клиентские приложения, выполнив следующее.

• Тщательный выбор перерыва на профилактическое техобслуживание в период снижения клиентского трафика

• При модернизации или обновлении SQL Server на первичном сайте изменение режима доступности снова на асинхронную фиксацию, затем возврат к синхронной фиксации, когда все будет готово для повторного возобновления работы на первичном сайте

Группа доступности с узлами экземпляра отказоустойчивого кластера

Если группа доступности содержит узлы экземпляра отказоустойчивого кластера (FCI), необходимо модернизировать или обновлять неактивные узлы перед модернизацией или обновлением активных узлов. На приведенном ниже рисунке показан обычный сценарий для групп доступности с использованием экземпляров FCI для достижения локального высокого уровня доступности и асинхронной фиксации между экземплярами FCIs для удаленного аварийного восстановления, а также последовательность обновления.

1. Модернизация или обновление REMOTE2

2. Возобновление работы FCI2 на REMOTE2

3. Модернизация или обновление REMOTE1

4. Модернизация или обновление PRIMARY2

5. Возобновление работы FCI1 на PRIMARY2

6. Модернизация или обновление PRIMARY1

Модернизация или обновление экземпляров SQL Server с несколькими группами доступности

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

Группа доступности	Узел1	Узел2	Node3
ГД1	Первичная
ГД2		Первичная
ГД3			Первичная

В конкретной ситуации бывает приемлема последовательная модернизация или обновление со сбалансированной нагрузкой в следующем порядке:

1. Возобновление работы ГД2 на Узле3 (для освобождения Узла2)

2. Модернизация или обновление Узла2

3. Возобновление работы ГД1 на Узле2 (для освобождения Узла1)

4. Модернизация или обновление Узла1

5. Возобновление работы обеих групп доступности, ГД2 и ГД3, на Узле1 (для освобождения Узла3)

6. Модернизация или обновление Узла3

7. Возобновление работы ГД3 на Узле3

Эта последовательность модернизации или обновления характеризуется средним временем простоя меньше двух переходов на другой ресурс в расчете на группу доступности. Результирующая конфигурация показана в приведенной ниже таблице.

Группа доступности	Узел1	Узел2	Node3
ГД1		Первичная
ГД2	Первичная
ГД3			Первичная

Путь модернизации или обновления может изменяться в зависимости от конкретной реализации, то же относится к времени простоя клиентских приложений.