AlwaysOn Availability Groups

SQL SERVER 2012 ALWAYSON:
НОВЫЕ ВОЗМОЖНОСТИ ПО СОЗДАНИЮ КАТАСТРОФО
УСТОЙЧИВЫХ РЕШЕНИЙ
Дмитрий Артемов
Старший консультант
[email protected]
Терминология
1. AlwaysOn – «покрывающий» термин для описания отказоустойчивых
решений на базе SQL Server 2012
2. AlwaysOn описывает два решения
AlwaysOn Availability Group (AG) для защиты на уровне БД
Физическая репликация записей журнала транзакций (сходное с
зеркалированием) для синхронизации Primary-Secondary серверов
AlwaysOn Failover Cluster Instance (FCI) для защиты на уровне экземпляра
(расширенные возможности SQL Server Failover Cluster Instance)
Классическая схема с разделяемым хранилищем, без синхронизации журналов
(возможно использование SRDF в соответствующих сценариях)
3. В обоих решения используется Windows Server Failover Cluster
И AlwaysOn AG и AlwaysOn FCI требуют нахождения всех узлов в одном Windows
Server Failover Cluster (WSFC), отличие в том, что AlwaysOn FCI также требует
разделяемого хранилища
AlwaysOn AG похож на зеркалирование, когда все узлы работаю с собственными
дисками и синхронизация выполняется посредством передачи записей журнала
транзакций
4. AlwaysOn FCI может использоваться совместно с AlwaysOn AG
Представляем SQL Server AlwaysOn
Перевод группы БД как
единого набора
Несколько резервных
серверов
Активные резервные
серверы
Встроенное управление
Multisite Clustering
Гибкая политика перехода
Расширенная диагностика
Подходит для сценариев
консолидации
Сценарии использования (1)
 Direct Attached Storage
 Локальные, региональные и гео распределенные реплики
AG
AG
AG
AG
Асинхронная
репликация
AG
Пример
 Primary в Казани
 Failover Partner в Москве
 Синхронная копия в
Красноярске
Синхронная
репликация
 Асинхронная копия в
Иркутске (отчетность)
 Асинхронная копия в
ПетропавловсеКамчатском (Гео кластер)
Сценарии использования (2)
AG
AG
AG
Синхронная
репликация
 Shared Storage
 Локальные,
региональные и гео
распределенные
реплики
 Смешанная
конфигурация с
использованием Direct
Attached Storage
Асинхронная
репликация
Пример
 Primary Failover Cluster в Екатеринбурге
 Синхронный Secondary Failover Cluster в
Москве
 Асинхронный резервный сервер в
Хабаровске
защита на уровне БД
v
AlwaysOn Availability Groups
AlwaysOn Availability Groups – новый функционал, который расширяет и
комбинирует возможности database mirroring и log shipping
Переход группы БД
Множественные
резервные серверы
До 4 резервных
серверов
2 с синхронной
репликацией
Синхронное и
асинхронное
перемещение данных
Встроенная компрессия
и шифрование
Автоматический и
ручной переход
Гибкая политика
перехода
Автоматическое
восстановление страниц
Единое виртуальное
имя
Мастер
конфигурации
Dashboard
Интеграция с System
Center
Развитые средства
диагностики
Синхронизация Filestream
Поддержка
репликации
Активные
резервные
серверы
Readable
Backup
Автоматизация
средствами
power-shell
Переход при сбое
HR
DB
HR
DB
HR
DB
Secondary
Primary
Secondary
AG_HR
HR_VNN
Primary
Приложение пытается восстановить соединение после перехода
server HR_Listener;-catalog HRDB
После завершения перехода и
подъема listener
восстанавливается соединение к
новому primary
Availability Group - архитектура
AG
Windows Server Failover Cluster
AG-VNN
AG-IP
Database
Active Log Synchronization
DB
DB
DB
DB
Проверки «здоровья» узлов кластера,
Координации перехода,
Проверки «здоровья» Primary реплики,
Организации распределенного хранилища
данных с настройками и состояниями,
Распределенного управления
уведомлениями
Database
Active Log Synchronization
DB
DB
По данным в журнале транзакций
Посредством TCP Endpoint
Синхронно\Асинхронно
Со сжатием в канале
С шифрованием
Что такое Availability Group
«Контейнер»
1 или более БД
Listener (виртуальное сетевое имя)
1 или более IP адресов (DHCP или
статика, aka virtual IP)
DB
DB
DB
Реплика
Primary/Secondaries
Automatic Failover Partner
Sync/Async Secondaries
Readonly Routing list
AG
AG-VNN
AG-IP
AlwaysOn Active Secondary
Балансировки read-only нагрузки
Выполнения операций резервного копирования
Active Secondary – как сделать
Secondary доступной
DB1
DB2
DB1
DB2
Readable secondary позволяет перенаправить часть запросов на
резервный сервер
«Свежесть» данных зависит от задержек синхронизации, резервный
сервер обновляется в режиме близком к реальному времени
Что же такое «близко к реальному времени»?
Точное время отставания определить
невозможно
Это связано с работой процесса фиксации
записей в БД
Вначале переданные записи фиксируются в журнале
Затем они из журнала поднимаются в БД (Redo)
Рабочий процесс, выполняющий операции Redo
работает асинхронно и исполняется в фоновом режиме
При передаче записей журнала от интенсивных
операций (массивный импорт, перестройка индексов),
задержки могут быть выше (обычно это секунды)
Использование синхронной реплики сокращает
расхождения, вызванные сетевыми задержками
Active Secondary: Backup на резервном
сервере
 Backup может быть снят на
любой из реплик
R/W workload
Secondary
 Backup на primary попрежнему работает
Backups
 Log backup, выполненные
на любой реплике
формируют единую
цепочку копий
 Database Recovery
Advisor облегчает
восстановление
Backups
Backups
Primary
Secondary
Резервное копирование/Восстановление
Дифференциальная копия не поддерживаются на secondary
Полная копия поддерживается на secondary только в виде Copy-only
Т.к. не реализована очистка Differential bitmap для полного копирования
И Дифференциальная копия будет расти, пока не станет размером с БД
Рекомендуется использовать центральное хранилище для размещения
копий
Резервная копия на «отставшей» асинхронной реплике также будет
отставать
В среде AlwaysOn все копии журнала транзакций, независимо от места
сбора, формируют единую цепочку (log chain)
Т.е. копирование журнала на replica A, затем на replica B и на replica C, для
полного восстановления нужны все три копии
Recovery Advisor
Recovery Advisor собирает
информацию о доступных
файлах резервной копии и
из них формирует
временнОй период,
визуально
представленный на
диалоговом окне.
Администратор выбирает
нужную точку времени для
восстановления
Когда выбор сделан,
инструмент формирует
команду RESTORE
Read-Only Client Connectivity
AlwaysOn Failover Cluster Instances
Защита на уровне экземпляра
v
Основные расширения



sp_server_diagnostics
Позволяет выполнить консолидацию более 26 экземпляров The current results
are that TPCC running over an SMB link as described above performs at 97% of the
speed of direct-attach”)
Гибкая политика перехода
Пользователь назначает новые свойства
HealthCheckTimeout и FailureConditionLevel
FailureConditionLevel (0 до 5)
5 – Failover or restart on any qualified failure
4 – Failover or restart on moderate SQL Server errors
3 – Failover or restart on critical SQL Server errors
2 – Failover or restart on SQL Server unresponsive
1 – Failover or restart on SQL Server down
Диагностика
Exec sp_server_diagnostics
0 – No Automatic Failover or restart
WSFC Service
Результат IsAlive/ LooksAlive
Зависит от данных диагностики
и установленного уровня
FailureConditionLevel
IsAlive/LooksAlive
WSFC запрашивает ресурсную
DLL жив ли кластер SQL
Сокращение запланированных простоев


ACTIVE SECONDARY:
РАСПРЕДЕЛЕНИЕ ОТЧЕТНОЙ
НАГРУЗКИ
Отчетная нагрузка сейчас
Зеркалирование
Вся нагрузка падает на Primary (в том числе и
отчеты)
Негативное влияние на потребление
ресурсов/блокировки
Отчеты на зеркале с использованием snapshot
Задержка данных
Усложнение администрирования
Нет перехода на резервный узел
При создании snapshot – падение
производительности
Репликация
Чаще всего используется для
организации отчетов
За:
Большое число подписчиков,
фильтрация данных
Добавление индексов для отчетов
Против:
Сложность управления и оптимизации
Active Secondary – Readable
Secondary
SQLservr.exe
InstanceA
CRASH
DB1
DB2
Отчеты
Secondary
Primary
SQLservr.exe
Secondary
Primary
InstanceB
Синхронизация
журналов
DB1
DB2
Отчеты
Readable secondary позволяет перенести нагрузку от отчетов на secondary
Невысокая задержка
После перехода (failover) «читающие» приложения могут быть автоматически
перенаправлены на новый Secondary (требуется явный запрос на
соединение)
Не годится как замена сценариям репликации
Дисковая подсистема: влияние на
отчеты (1)
Воздействие на RTO
Отчеты отбирают
ресурсы от REDO
процесса
Увеличение recovery
time (RTO)
Secondary
Log Apply
Log
Cache
DB1 Log
Интенсивная
нагрузка
(IO., Memory, CPU)
DB1
Redo
Thread
Redo
Pages
DB1
Data
Отчеты
Что делать
Использовать Use
resource-governor для
контроля ресурсов под
отчеты
При использовании
комбинации
SYNC/ASYNC secondary,
лучше направить отчеты
на Async Secondary.
Дисковая подсистема: влияние на отчеты (2)
Конкурентный доступ и блокировки
Отчеты могут заблокировать REDO
Отчеты и REDO могут попасть в deadlock
Решение
Все уровни блокировки, используемые приложением,
автоматически преобразуются в Snapshot Isolation
Полностью прозрачно для приложения
Все подсказки оптимизатору игнорируются (часто отчеты
используют с опцией NOLOCK)
SQL Server никогда не выберет REDO как жертву deadlock
В результате
Снижение уровня блокирований между отчетами и REDO
Проблемы с DML (INSERT/DELETE/UPDATE) отсутствуют т.к.
это просто не позволено
Дополнительная нагрузка на TempDb за счет использования
версионирования
Производительность отчетов на
Secondary
Оптимизированные планы запросов
Цель: Сходные планы на Readable Secondary
Оптимизация запросов и статистика
SQL Server использует cost based optimizer, работа которого сильно зависит от
статистики
Если статистика отсутствует, SQL Server автоматически создает ее и хранит
Автоматическое создание/обновление статистики требует физических
изменений
Пример: Table T1 (C1, C2, C3)
Запрос на Primary с условием (C3 > 10).
SQL Server, если нужно, автоматически создаст статистику, на поле C3
На Secondary это невозможно т.к. физические изменения в БД запрещены
Аналогичная проблема при попытке обновить статистику
Решение
Статистика создается, но хранится в (многострадальной) TempDB
Системные представления (напр. sys.stats) показывают временную статистику
Не используется FULLSCAN (очень долго)
Проблемы
Рестарт сервера = потеря статистики
Для «скошенных» данных sampling может не дать качественной статистики
Создайте статистику WITH FULLSCAN на Primary и она перейдет на Secondary
Демо
v
Ресурсы по AlwaysOn
http://msdn.microsoft.com/en-us/sqlserver/gg490638(en-us,MSDN.10)
СПАСИБО!
Вопросы?
© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.