Технологии повышенной доступности в SQL Server 2005 Андрей Синкин

Технологии повышенной
доступности в SQL Server
2005
Андрей Синкин
Системный инженер
Microsoft Corporation
Основные задачи
Понять суть новых технологий
повышенного доступа в SQL Server 2005:
Database Mirroring
Database Snapshots
Понять различие между технологиями
повышенного доступа в SQL Server 2005
Два отказоустойчивых решения
Database Mirroring / Failover Clusters
Два более простых решения
Log Shipping / Replication
Доступность информации и
SQL Server 2005
Доступность данных и требования бизнеса
Доступность данных это одно из основных требований
бизнеса в IT-организациях
Есть много барьеров для доступности данных
Мы сосредоточимся на сбоях/разрушениях базы данных
Мы не будем рассматривать другие проблемы доступности
Например: параллелизм, регламентные работы,
масштабирование и т.д.
Доступность имеет множество граней
Люди
Процесс
Технология
Аппаратное обеспечение
Программное обеспечение
Технологии доступности
информации в SQL Server 2005
Автоматическая отказоустойчивость и
отсутствие возможности утраты данных
•
•
Database Mirroring
Failover Clustering
Повыш.доступность
Ручная отказоустойчивость и потенциальная
возможность потери данных
•
•
Репликация транзакций
Log Shipping
Отсутствие отказоустойчивости и
потенциальная возможность потери данных
•
•
Backup / Restore
Detach / Copy / Attach
Database Mirroring
Database Mirroring
SQL Server 2005
Резервный экземпляр
Отказоустойчивый сервер
• Компоновочный блок для сложных топологий
Отказоустойчивая БД
• Очень быстрая
• Отсутствие возможности потери данных
Аппаратное обеспечение
• Работает на стандартных компьютерах,
хранилище и сетевом окружении
• Хранилище неразделяемое
Failover Cluster
Failover Clustering
Microsoft Cluster Services
• Горячий резерв
• Построен на Microsoft Cluster Services
(MSCS)
Доступность обеспечивают множество узлов, причем прозрачно
для клиента
Автоматическое обнаружение и восстановление сбоя
Требует сертифицированного аппаратного обеспечения
Поддержка разных сценариев: Active/Active, N+1, N+I
• Отсутствие потери данных, отсутствие влияния на
пропускную способность
• Одна копия баз данных
• Отказоустойчивый экземпляр – целый
экземпляр работает как единый модуль
Log Shipping
Теплый резерв
•
•
•
•
•
Основная идея: архивирование,
копирование и восстановление
лога на другом сервере
Не требует дополнительных
вложений в скриптование
Уровень базы данных
База данных доступна в режиме
только для чтения
Для обработки следующей
порции лога пользователи
должны отключаться
Log Shipping
Репликация
Теплый резерв
Как правило используется когда
доступность требуется в сочетании с
возможностью чтения информации с
разных серверов
Возможность отказоустойчивости;
требуется собственное решение
Нет ограничения на использование
всей БД – можно определить
подмножество исходной БД или
таблицы для копирования
Копия базы данных постоянно
доступна в режиме чтения
Задержка между источником и
копией может идти на секунды
Логическая технология
Репликация
Решения для offline
Холодный резерв
Backup / Restore
Оба обеспечивают
•
•
•
•
•
•
•
•
Ручное определение и восстановление после сбоя
Потенциальная потеря части работы
Уровень базы данных
Стандартные серверы
Ограниченная возможность запуска отчетов на
резервном сервере
Дубликат базы данных
Клиент должен знать куда переподключаться
Медленное восстановление – больше времени простоя
Backup / Restore
•
•
•
Меньший размер – копируются только измененные
страницы
Log backups allow restore to point in time
Большее время восстановления
Detach / Copy / Attach
•
•
Копирование файлов БД целиком
Нет возможности накатывать последующие логи
Detach / Copy / Attach
Отказоустойчивые решения
Два решения уровня предприятия
Выбор зависит от
Стратегического развития информационных технологий
Бюджета
Различия между технологиями
Failover Cluster
Database Mirroring
Database Mirroring
(зеркалирование базы данных)
Database Mirroring
Основные достоинства
Восстановление менее 3 секунд
Полноценный резерв
Два отдельных сервера
Две отдельных копии данных
Взаимодействие между серверами через
стандартное сетевое соединение
Нет специальных требований на
аппаратное обеспечение
Самоконтроль
Высокая доступность для базы данных
Database Mirroring
Клиенты
Система Database Mirroring
База данных - часть системы Database
Mirroring
Она может управляться любым из серверов
Резервный сервер всегда имеет актуальные
данные
Переключение ролей
Ручное
Автоматическое
Клиент перенаправляется на резервный
сервер сервер после сбоя
Резервный сервер может служить сервером
отчетов с помощью технологии Database
Snapshots
Основная конфигурация
Три различных серверных роли
Principal (Основной сервер)
Принимает подключения клиентов
Позволяет обновлять базу данных
Mirror (Зеркало) (Резервный экземпляр)
Клиенты не имеют к нему доступа
Изменения данных копируются в лог на резервном
сервере после чего меняются данные в самой БД
Может меняться ролями с Principal и становиться
новым Principal
Witness (Свидетель)
Отслеживает состояние двух серверов
Позволяет автоматическое восстановление
Database Mirroring
Клиенты
Witness
Записи
лога
Principal
Mirror
Основные принципы зеркалирования
Подтверждение
Подтверждение
Фиксация
Передача на резервный
сервер
Запись в
логический
лог
DB
Непрерывное
выполнение
на резервном
сервере
Фиксация
в логе
Log
Запись в
удаленный
лог
Log
DB
Состояния Database Mirroring
База данных:
SYNCHRONIZED
Зеркало имеет все данные
SYNCHRONIZING
Зеркало находится в процессе синхронизации
SUSPENDED
Процесс передачи лога на зеркало приостановлен
DISCONNECTED
Сервер не общается с другими серверами
Незащищенные состояния =
SYNCHRONIZING или SUSPENDED или
DISCONNECTED
Database Mirroring
Основной сервер записывает информацию в
свой лог и одновременно передает эти данные
по сети
Сервер не ждет у себя фиксации изменений, а
передает записи лога сразу же
Транзакции не фиксируются пока резервный
сервер записывает данные в свой лог
В данный момент данные расположены в двух
разных местах
При восстановлении данные не теряются
Восстановление автоматическое или ручное
Database Mirroring
Менее 3 секунд на восстановление
Резервный сервер накатывает лог по месту
БД доступна в момент операции Undo
Новая возможность в SQL Server 2005
В случае сбоя:
БД была восстановлена на другом сервере
Обработаны все архивы лога, включая
последний
Восстановление произошло
База данных готова к работе
Восстановление
Crash Recovery
Empty
HOT
Database
Database:
Доступна
Недоступна
Cache
Анализ
Redo
Время
Undo / Do
Отказоустойчивость
Empty
HOT
Database
Cache
Сервер A:
Do
Empty
HOT
Сервер B:
База данных доступна
на сервере A
Database
Cache
База данных доступна
на сервере B
Redo
Undo / Do
Свидетель и Кворум
Ключевая роль Witness состоит в
обеспечении автоматического
переключения
Для безболезненной потери одного из
серверов нужно иметь полный кворум
Предотвращает “разделение мозгов”
Потеря соединения означает проблемы с
сервером-партнером или же проблему с
сетью?
Для того чтобы стать основным
сервером, сервер должен “видеть” хотя
бы один сервер из кворума
Witness
продолжение
Witness - это экземпляр SQL Server
Один свидетель может обрабатывать
множество сессий
Использует очень мало ресурсов
Отвечает на запрос проверки связи (ping)
Отвечает на вопрос “Жив ли другой сервер?”
Не единственная реакция на сбой
Партнеры могут формировать кворум
самостоятельно
Надежность / Производительность
Есть выбор между более высокой
производительностью и более высокой
надежностью
Database Mirroring имеет два уровня
надежности
FULL – фиксация при записи лога на Mirror
Допускает автоматическое восстановление
Нет потери данных
OFF – фиксация при записи лога на Principal
Уровни надежности
FULL
Подтверждение
Подтверждение
Фиксация
Передача на резервный
сервер
Фиксация
Запись в
в логе
удаленный
лог
Запись в
локальный
лог
Log
Log
Уровни надежности
OFF
Подтверждение
Фиксация
Передача на резервный
сервер
Фиксация
Запись в
в логе
удаленный
лог
Запись в
локальный
лог
Log
Log
Два сценария
Высокая доступность
Полная надежность (FULL)
Автоматическое восстановление
База данных доступна для работы даже
при потере одного из серверов
Высокая производительность
Полная надежность установлена в OFF
DBA контролирует отказоустойчивость
Небольшая потеря данных
Disaster recovery scenario
Автоматическое восстановление
Mirroring:
SUSPENDED
SYNCHRONIZING
SYNCHRONIZED
Witness
Сервер A
Сервер B
Mirror
Principal
Mirror
Principal
Безопасность
На уровне сервера
Для контроля доступа используются конечные
точки (Endpoints)
Системный администратор выбирает серверы
между которыми будут доверительные
отношения
NT логины в доменах с доверительными отношениями
Сертификаты в доменах с недоверительными отношениями
Системный администратор дает этим серверам
разрешение на участие в Database Mirroring
Это должно быть сделано на всех трех
серверах
На протяжении всего времени соединения
серверы находятся в доверительных
отношениях
Безопасность
На уровне базы данных
Как только будут установлены
разрешения на системном уровне, все
пользовательские базы данных на
партнерских серверах могут быть
зеркалированы
Владелец БД может устанавливать,
конфигурировать и администрировать
сессии зеркалирования
Для каждой сессии канал
взаимодействия может быть зашифрован
Database Snapshots
(моментальные снимки БД)
Пользовательские ошибки
Пользователи, приложения, а также DBA
могут время от времени делать ошибки
Database Snapshots решают эту
проблему, позволяя откатывать базу
данных на момент создания снимка
Данные теряются как только БД
откатывается назад на определенный
момент времени
Должны быть созданы перед
возникновением ошибки
Snapshots (моментальные снимки)
Общие понятия
Снимок БД на определенный момент времени
Создается на том же самом экземпляре сервера БД
Доступен только для чтения
Основная БД продолжает изменяться
Снимок не ограничивает основную БД
Снимок требует уникального имени
Для исправления ошибок производится откат на
заранее созданный снимок
Snapshot
Технология
Большая эффективность использования
места
Не требуется полная копия данных
Неизмененные страницы БД находятся в
совместном доступе
Требуется дополнительное место только
для измененных страниц
Используется механизм “копирование
при записи”
Снимок оказывает влияние на
производительность основной БД
Snapshot (Копирование в момент
записи)
Команда
Create Northwind_SS
Update Northwind
Read Northwind_SS
Результат:
DD
Используемое 12.5%
0%
место
Northwind
Значение
R
D
X
B
H
J
L
Y
M
Northwind_SS
Значение
D
Snapshots (снимки)
Database Mirroring
На резервном сервере можно создавать
множество снимков
Каждый снимок создается на определенный
момент времени
Каждый снимок имеет свое собственное имя
Снимки на резервном сервере могут
оказывать влияние на
производительность основного сервера
Снимки могут существовать очень долго
Ограничены только доступными ресурсами
Отчеты на резервном сервере
Использование снимков базы данных
на резервном сервере
Database Mirroring
OLTP Клиенты
Witness
Principal
Mirror
Snapshot2
@ 2PM
Snapshot
@ Noon
Клиенты
запускающие отчеты
Отчеты на резервном сервере
Ограничения
Схема снимка неизменна
Снимок статичен
Новые данные недоступны
Снимки могут влиять на производительность
Альтернатива - репликация для
выделенного решения сервера отчетов с
горизонтальным масштабированием
Перенаправление запросов
клиентов
Перенаправление прозрачно
Приложения перенаправляются на нужный
сервер
На сбой, приложение должно
инициировать перенаправление:
Текущая информация о состоянии потеряна
Приложению перенаправление не важно
В строке соединения должна быть
информация сервер/база данных
Перенаправление клиентов
Если база данных использует
зеркалирование, то загружаются
имена серверов
Клиент хранит информацию в памяти
При сбое идет подключение к
резервному серверу
MDAC использует резервный сервер
Доступность
(1 из 2)
Горячий резерв
Функциональ
Database
ность
Теплый резерв
Failover
Clustering
Transactional
Replication
Log
Shipping
Потеря данных
Нет опций
потери
данных
Нет потери
данных
Некоторые
данные могут
быть потеряны
Некоторые
данные могут
быть потеряны
Автоматическое
восстановление
Да
Да
Нет
Нет
Нет
Нет
секунды
секунды +
восстановление БД
Постоянно
доступна
Периодически
доступна
Mirroring
Прозрачность
клиента
Да,
Автоперена
правление
Время простоя
< 3 секунд
Доступ на чтение
к серверу
Постоянно
доступный
снимок
Да,
Переподсое
инение к
тому же IP
20 сек +
восстановление БД
Нет
Доступность
Функцион
альность
Уровень
детализации
данных
Горячий резерв
Database
Mirroring
БД
Устойчивость к
Да
сбою дисковой
подсистемы
НеобходиНет, нужна
мость в
дублируюспециальном
щая система
аппаратном
обеспечении
Сложность
Некоторая
Failover
Clustering
Все
системные и
пользовательские БД
Нет, диски
совместного
доступа
Специальное
аппаратное
обеспечение
от
Cluster HCL
Больше
(2 из 2)
Теплый резерв
Transact.
Replication
Log
Shipping
Таблица или
вид
БД
Да
Да
Нет, нужна
дублируюсистема
Нет, нужна
дублирующая
система
Больше
Больше
Полезные ресурсы
SQL Server 2005 Books Online
Официальная страница
http://www.microsoft.com/sql/2005
SQL Server 2005 на MSDN
http://msdn.microsoft.com/library/default.asp?url
=/library/en-us/dnanchor/html/sqlserver.asp
Российское сообщество по SQL Server
http://www.sql.ru/
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.