SQL SERVER 2012 ALWAYSON: НОВЫЕ ВОЗМОЖНОСТИ ПО СОЗДАНИЮ КАТАСТРОФО УСТОЙЧИВЫХ РЕШЕНИЙ Дмитрий Артемов Старший консультант

Терминология 1. AlwaysOn – «покрывающий» термин для описания отказоустойчивых решений на базе SQL Server 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 Интегрированное, Гибкое, Экономически эффективное решение для создания отказоустойчивых решений для критически важных приложений AlwaysOn обеспечивает защиту на уровне БД и на уровне экземпляра SQL Server AlwaysOn Availability Groups для защиты БД AlwaysOn Failover Cluster Instances для защиты на уровне экземпляра Перевод группы БД как единого набора Несколько резервных серверов Активные резервные серверы Встроенное управление Multisite Clustering Гибкая политика перехода Расширенная диагностика Подходит для сценариев консолидации

Сценарии использования (1) Синхронная репликация Асинхронная репликация AG Direct Attached Storage Локальные, региональные и гео распределенные реплики Пример Primary в Казани Failover Partner в Москве Синхронная копия в Красноярске Асинхронная копия в Иркутске (отчетность) Асинхронная копия в Петропавловсе- Камчатском (Гео кластер)

Сценарии использования (2) Shared Storage Локальные, региональные и гео распределенные реплики Смешанная конфигурация с использованием Direct Attached Storage Пример Primary Failover Cluster в Екатеринбурге Синхронный Secondary Failover Cluster в Москве AG Асинхронный резервный сервер в Хабаровске AG Синхронная репликация Асинхронная репликация

v v AlwaysOn Availability Groups защита на уровне БД

AlwaysOn Availability Groups AlwaysOn Availability Groups – новый функционал, который расширяет и комбинирует возможности database mirroring и log shipping Гибкость Переход группы БД Множественные резервные серверы До 4 резервных серверов 2 с синхронной репликацией Синхронное и асинхронное перемещение данных Встроенная компрессия и шифрование Автоматический и ручной переход Гибкая политика перехода Автоматическое восстановление страниц Интеграция Единое виртуальное имя Мастер конфигурации Dashboard Интеграция с System Center Развитые средства диагностики Синхронизация File- stream Поддержка репликации Эффективность Активные резервные серверы Readable Backup Автоматизация средствами power-shell

HR DB Переход при сбое Availability Groups Listener позволяет приложению переходить на любой резервный сервер Приложение восстанавливает соединение, пользуясь виртуальным именем ServerAServerBServerC PrimarySecondary HR DB HR DB Приложение пытается восстановить соединение после перехода server HR_Listener;-catalog HRDB После завершения перехода и подъема listener восстанавливается соединение к новому primary HR_VNN AG_HR Primary

Availability Group - архитектура Windows Server Failover Cluster Database Active Log Synchronization Database Active Log Synchronization SQL Server выполняет синхронизацию По данным в журнале транзакций Посредством TCP Endpoint Синхронно\Асинхронно Со сжатием в канале С шифрованием DB AG AG-VNN AG-IP Availability Group использует Windows Server Failover Cluster (WSFC) для Проверки «здоровья» узлов кластера, Координации перехода, Проверки «здоровья» Primary реплики, Организации распределенного хранилища данных с настройками и состояниями, Распределенного управления уведомлениями

Что такое Availability Group «Контейнер» 1 или более БД Listener (виртуальное сетевое имя) 1 или более IP адресов (DHCP или статика, aka virtual IP) Реплика Primary/Secondaries Automatic Failover Partner Sync/Async Secondaries Readonly Routing list DB AG AG-VNN AG-IP

AlwaysOn Active Secondary Эффективность IT и эффективность затрат – критически важно для бизнеса Больше нет простаивающих серверов AlwaysOn Active Secondary позволяет эффективно загрузить серверы, что повышает общую эффективность вложений в IT Active Secondary можно использовать для: Балансировки read-only нагрузки Выполнения операций резервного копирования

Active Secondary – как сделать Secondary доступной SQLservr.exe InstanceA DB2DB1 Отчеты Переход SQLservr.exe InstanceB DB2DB1 Отчеты Readable secondary позволяет перенаправить часть запросов на резервный сервер «Свежесть» данных зависит от задержек синхронизации, резервный сервер обновляется в режиме близком к реальному времени Primary Secondary

Что же такое «близко к реальному времени»? Точное время отставания определить невозможно Это связано с работой процесса фиксации записей в БД Вначале переданные записи фиксируются в журнале Затем они из журнала поднимаются в БД (Redo) Рабочий процесс, выполняющий операции Redo работает асинхронно и исполняется в фоновом режиме При передаче записей журнала от интенсивных операций (массивный импорт, перестройка индексов), задержки могут быть выше (обычно это секунды) Использование синхронной реплики сокращает расхождения, вызванные сетевыми задержками

Active Secondary: Backup на резервном сервере Backup может быть снят на любой из реплик Backup на primary по- прежнему работает Log backup, выполненные на любой реплике формируют единую цепочку копий Database Recovery Advisor облегчает восстановление R/W workload Primary Backups Secondary Backups Secondary Backups

Резервное копирование/Восстановление Дифференциальная копия не поддерживаются на secondary Полная копия поддерживается на secondary только в виде Copy-only Т.к. не реализована очистка Differential bitmap для полного копирования И Дифференциальная копия будет расти, пока не станет размером с БД Рекомендуется использовать центральное хранилище для размещения копий Резервная копия на «отставшей» асинхронной реплике также будет отставать В среде AlwaysOn все копии журнала транзакций, независимо от места сбора, формируют единую цепочку (log chain) Т.е. копирование журнала на replica A, затем на replica B и на replica C, для полного восстановления нужны все три копии

Recovery Advisor Recovery Advisor собирает информацию о доступных файлах резервной копии и из них формирует временнОй период, визуально представленный на диалоговом окне. Администратор выбирает нужную точку времени для восстановления Когда выбор сделан, инструмент формирует команду RESTORE

Read-Only Client Connectivity Обработка соединений для «читающих» клиентов определяется настройками реплики и свойством соединения (Availability Replica Option+ ApplicationIntent) ApplicationIntent – свойство соединения Replica option определяет доступность реплики в режиме secondary: SECONDARY_ROLE ( ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ) Read-Only Routing обеспечивает перенаправление клиентских соединений при изменении роли. Доступно только при подключении через Listener. Обеспечивает прозрачное перенаправление клиентских соединений между репликами

v v AlwaysOn Failover Cluster Instances Защита на уровне экземпляра

Основные расширения Ускорение перехода экземпляра За счет предсказуемости подъема БД на резервном узле (ALTER DATABASE … SET TARGET_RECOVERY_TIME = target_recovery_time { SECONDS | MINUTES }) Встроенная поддержка кластеров в разных подсетях Обеспечивает не только отказо, но и катастрофо устойчивость Гибкая политика перехода Устраняет ложные переходы Позволяет конфигурировать уровни Configurable failure condition levels Более качественная диагностика - sp_server_diagnostics Starting SQL Server 2012, system databases (Master, Model, MSDB, and TempDB), and Database Engine user databases can be installed with Server Message Block (SMB) file server as a storage option. This applies to both SQL Server stand-alone and SQL Server failover cluster installations (FCI) Позволяет выполнить консолидацию более 26 экземпляров (The current results are that TPCC running over an SMB link as described above performs at 97% of the speed of direct-attach) Поддержка TEMPDB на локальном диске

Гибкая политика перехода 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 0 – No Automatic Failover or restart Пользователь назначает новые свойства HealthCheckTimeout и FailureConditionLevel SQL Server Failover Cluster Instance Диагностика для группы компонентов System Resource Query Processing IO Subsystem Events WSFC Service FCI Res DLL Exec sp_server_diagnosticsДиагностика IsAlive/LooksAlive WSFC запрашивает ресурсную DLL жив ли кластер SQL Результат IsAlive/ LooksAlive Зависит от данных диагностики и установленного уровня FailureConditionLevel

Сокращение запланированных простоев Поддержка Windows Server Core Снижение простоев при установке обновлений на 50-60% Поддержка последовательного (rolling) обновления и установки исправлений на SQL Server для Availability Groups и Failover Cluster Instance Ускорение времени перехода (Fast failover) для Availability Groups и Failover Cluster Instances Поддержка новых операций online Поддержка LOB индексов (varchar(max), nvarchar(max), varbinary(max) или XML теперь можно строить, перестраивать или удалять в режиме online) Добавление поля со значением умолчания

ACTIVE SECONDARY: РАСПРЕДЕЛЕНИЕ ОТЧЕТНОЙ НАГРУЗКИ

Отчетная нагрузка сейчас Зеркалирование Репликация Вся нагрузка падает на Primary (в том числе и отчеты) Негативное влияние на потребление ресурсов/блокировки Отчеты на зеркале с использованием snapshot Задержка данных Усложнение администрирования Нет перехода на резервный узел При создании snapshot – падение производительности Чаще всего используется для организации отчетов За: Большое число подписчиков, фильтрация данных Добавление индексов для отчетов Против: Сложность управления и оптимизации

Readable secondary позволяет перенести нагрузку от отчетов на secondary Невысокая задержка После перехода (failover) «читающие» приложения могут быть автоматически перенаправлены на новый Secondary (требуется явный запрос на соединение) Не годится как замена сценариям репликации DB2DB1 SQLservr.exe InstanceA DB2DB1 Primary Secondary Синхронизация журналов InstanceB Отчеты Primary Secondary Отчеты Active Secondary – Readable Secondary CRASH

Дисковая подсистема: влияние на отчеты (1) Воздействие на RTO Отчеты отбирают ресурсы от REDO процесса Увеличение recovery time (RTO) Что делать Использовать Use resource-governor для контроля ресурсов под отчеты При использовании комбинации SYNC/ASYNC secondary, лучше направить отчеты на Async Secondary. Log Cache DB1 Log Apply Redo Thread Redo Pages DB1 Log DB1 Data Отчеты Интенсивная нагрузка (IO., Memory, CPU) Интенсивная нагрузка (IO., Memory, CPU) 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 v Демо

Ресурсы по AlwaysOn SQL Server 2012 AlwaysOn Resource Center Можно скачать сам SQL Документация MSDN форумы Microsoft Connect ( AlwaysOn Blog ( wayson)

© 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. СПАСИБО! Вопросы?