[Источник] Высокая доступность в SQL Server (1) ---- обзор высокой доступности

Начиная с SQL Server 2005 года, Microsoft внедрила различные технологии высокой доступности для сокращения простоев и повышения защиты бизнес-данных, а с постоянным выпуском SQL Server 2008, SQL Server 2008 R2 и SQL Server 2012 в SQL Server существует множество технологий высокой доступности для различных сценариев.

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

    Многим компаниям нужно, чтобы все или часть их данных были максимально доступны, например, сайты онлайн-покупок, онлайн-базы данных товаров должны быть онлайн круглосуточно, иначе в условиях высокой конкуренции на рынке простой означает потерю клиентов и доходов. Например, в колл-центре, который использует SQL Server, если база данных выходит из строя, все звонящие могут только сидеть и отвечать клиенту «Извините, сбой системы», что тоже недопустимо.

    Конечно, в идеальном мире все критически важные данные всегда будут в сети, но в реальном мире существуют различные причины недоступности базы данных, поскольку невозможно предсказать время и форму катастрофы, необходимо заранее принимать меры для предотвращения различных чрезвычайных ситуаций, поэтому SQL Server предоставляет различные технологии высокой доступности, к которым в основном относятся: кластеризация, репликация, зеркалирование, доставка журналов, группы доступности AlwaysOn и другие, такие как резервное копирование и восстановление групп файлов, Технологии высокодоступности с одним экземпляром, такие как онлайн-индексы восстановления. Использование технологий высокой доступности — это не выбор знакомой технологии для прямого применения, а всесторонний рассмотрение бизнеса и технологий. Потому что не существует единой технологии, способной выполнять все функции. Как внедрять эти технологии в зависимости от вашего конкретного бизнеса и бюджета — это так называемая стратегия высокой доступности.

При разработке стратегии высокой доступности сначала следует учитывать следующие факторы:

• RTO (Цель по времени восстановления) — то есть цель по времени восстановления, означает, сколько разрешённого простоя, обычно выражаемое несколькими девятками, например, доступность 99,999% означает не более 5 минут простоя в год, 99,99% — не более 52,5 минут простоя в год, а 99,9% — не более 8,75 часов простоя в год. Стоит отметить, что метод расчёта RTO учитывает, работает ли система 24*365 или только с 6 утра до 9 вечера и так далее. Также нужно обратить внимание, считается ли окно обслуживания простоем, и достичь более высокой доступности, если в период обслуживания разрешены обслуживание и исправления базы данных.
• RPO (Цель точки восстановления) — также известная как цель точки восстановления, означает, сколько допустимых потерь данных. Обычно, если сделать хорошую резервную копию, можно легко избежать потери данных. Но когда происходит катастрофа, в зависимости от степени повреждения базы данных, время, необходимое для восстановления данных из резервной копии, приводит к недоступности базы данных, что повлияет на внедрение RTO. Ранний и более известный пример — банковская система в Европе и США, учитывая только RPO, в системе есть только полные резервные копии и логовые резервные копии, полные резервные копии каждые 3 месяца, архивирование каждые 15 минут, когда происходит катастрофа, только полные резервные копии и логовые резервные копии могут восстановить данные, так что, хотя потери данных нет, восстановление данных заняло два полных дня, банковская система была недоступна в течение двух дней, поэтому большое количество клиентов было потеряно. Другой противоположный пример — отечественный онлайн-видеосайт, использующий SQL Server в качестве реляционной базы данных, фронтенд — No-SQL и регулярно импортирует No-SQL данные в реляционную базу данных в качестве резервной копии.
  

    Бюджет — RTO и RPO вместе называются SLA (Service Level Agreements), и при разработке стратегии высокой доступности необходимо оценивать, насколько вы выполняете SLA, исходя из вашего бизнеса, в зависимости от бюджета, а также оценивать стоимость различных SLA в случае сбоя. В целом, сложно достичь высоких SLA с ограниченным бюджетом, и даже если высокие SLA достигаются через сложные архитектуры, сложные архитектуры также означают высокие эксплуатационные и технические затраты, поэтому необходимо выбирать правильную технологию в рамках бюджета для соответствия SLA.

Таким образом, в общем случае основную структуру высокой доступности можно определить несколькими вопросами для принятия порядков:

• Какой период простоя готовы принять акционеры?
• Какое простое время приемлемо для менеджеров?
• Какой бюджет предусмотрен для сценария высокой доступности?
• Какова потеря в час из-за простоя?
  

• Холодное резервное копирование: резервный сервер настроен на прием данных основного сервера, а при сбое — ручное восстановление данных в основную базу данных или перенастройки строки подключения или разрешений программы для запуска резервной базы данных.
• Горячая резервная копия: основные данные сервера будут непрерывно передавать логи на сервер резервного копирования (с нерегулярными интервалами — 15 минут, 30 минут, 1 минута и т.д.), таким образом, основной сервер резервного сервера обычно обновляется асинхронно, поэтому данные основного и резервного сервера не могут быть гарантированы. Кроме того, эта схема обычно не реализует автоматический мониторинг неисправностей и резервирование.
• Горячее резервное копирование: данные основного сервера автоматически синхронизируются на сервере резервного копирования, и в большинстве случаев включаются автоматический мониторинг неисправностей и резервное копирование, а также гарантируется согласованность данных основного сервера и резервного сервера.
  

    От холодных к тёплым и горячим резервным вариантам стоимость взлетает до небес.

    Функции высокой доступности, поддерживаемые SQL Server, тесно связаны с версией, а версия Enterprise поддерживает все функции высокой доступности, включая:

• Резервный кластер
• Изображение базы данных l
• l Передача транзакционного журнала
• Снимки базы данных I
• Улучшения высокой доступности
• I Горячая загрузка памяти
• l Онлайн-операции индексирования
• l Частично онлайн-база данных (восстанавливаются только группа мастер-файлов или группа мастер-файлов и дополнительные файлы NDF)
  

    Для конкретных версий с высокой доступностью см.:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxСтоит отметить, что бесплатная версия Express может служить сервером свидетелей для зеркалирования баз данных, что позволяет экономить средства.

Резервный кластер

    Резервные кластеры обеспечивают высокую доступность всего экземпляра SQL Server, что означает, что экземпляр SQL Server на узле кластера переключается на другие узлы кластера из-за аппаратных ошибок, ошибок операционной системы и т.д. Высокая доступность достигается благодаря тому, что несколько серверов (узлов) совместно используют один или несколько дисков, а резервные кластеры появляются в сети так же, как и один компьютер, но с высокими характеристиками доступности. Важно отметить, что поскольку резервные кластеры основаны на общих дисках, существует одна точка отказа диска, поэтому необходимо внедрять дополнительные защиты, такие как репликация SAN, на уровне диска. Наиболее распространённым кластером резервного переключения является двухузловый кластер, включая мастер и ведомого.

Передача транзакционного журнала

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

    Доставка транзакционного журнала может использоваться для создания холодных и тёплых резервных копий.

Зеркалирование базы данных

    Зеркалирование баз данных — это программное решение, которое также обеспечивает защиту на уровне базы данных, обеспечивая почти мгновенное отказное переключение для повышения доступности базы данных. Зеркало базы данных может использоваться для поддержания одной резервной базы данных (или «зеркальной базы данных») для соответствующей производственной базы данных (называемой «основной базой данных»).
Поскольку зеркальная база данных всегда находится в состоянии восстановления, но база данных не восстановлена, зеркальная база данных нельзя получить прямой доступ. Однако для загрузок только для чтения, таких как отчёты, зеркальная база данных можно использовать косвенно, создав снимок зеркальной базы данных. Снимки базы данных предоставляют клиентам доступ только для чтения к данным в базе данных при создании снимка. Каждая конфигурация зеркалирования базы данных включает «главный сервер», содержащий основную базу данных, а также зеркальный сервер, содержащий зеркальную базу данных. Сервер зеркала постоянно обновляет базу данных с основной базой данных.
    Зеркалирование базы данных работает синхронно в режиме высокой безопасности или асинхронно в режиме высокой производительности. В высокопроизводительном режиме транзакции не нужно ждать, пока зеркальный сервер запишет логи на диск, прежде чем их можно будет отправить, что максимизирует производительность. В режиме высокой безопасности фиксированные транзакции совершаются обоими партнёрами, но время задержки транзакции продлевается. Самая простая конфигурация зеркалирования базы данных включает только главный сервер и сервер зеркала. В такой конфигурации, если главный сервер теряется, зеркальный сервер может использоваться как резервный сервер, но это может привести к потере данных. Режим высокой безопасности поддерживает режим ожидания, режим высокой безопасности с автоматическим резервированием. Эта конфигурация включает сторонний сервер, называемый «сервером свидетеля», который позволяет использовать зеркальный сервер в качестве сервера горячего резервного копирования. Отказ от основной базы данных к зеркальной обычно занимает несколько секунд.

    Зеркалирование базы данных может использоваться как для горячих, так и для горячих резервных копий.

копировать

    Репликация — это не строго функция, предназначенная для высокой доступности, но её можно применять к высокой доступности. Репликация обеспечивает защиту на уровне объектов базы данных. Репликация использует модель публикации-подписка, при которой данные публикуются основным сервером, известным как издатель, одному или нескольким вторичным или подписчикам. Репликация обеспечивает доступность и масштабируемость в реальном времени между этими серверами. Он поддерживает фильтрацию для предоставления абонентам подмножества данных, а также обновления разделов. Абонент находится онлайн и доступен для отчётов или других функций без восстановления по запросу. SQL Server предлагает четыре типа репликации: репликацию по снимку, транзакционную репликацию, одноранговую репликацию и репликацию слияния.

AlwaysOnГруппа удобства

    AlwaysOn Availability Groups — это новая функция, введённая в SQL Server 2012. Также обеспечивается защита на уровне базы данных. Это также расширяет ограничение, позволяющее зеркалированию базы данных быть только 1:1, так что одна основная реплика может соответствовать до 4 вторичным репликам (в SQL Server 2014 это ограничение увеличено до 8), из которых две вторичные реплики могут синхронизироваться как горячие резервные копии и первичные реплики в реальном времени, а две другие асинхронные вторичные реплики могут использоваться как горячие резервные копии. Кроме того, вторичные реплики могут быть настроены только для чтения и использоваться для выполнения нагрузки резервных копий.

    Из-за этого зеркалирование базы данных в SQL Server 2012 отмечено как «устаревшее».

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

Требования к сбору

    Первым шагом при выборе стратегии высокой доступности является сбор бизнес-требований для создания SLA. RTO и RPO — самые важные компоненты, и на их основе необходимо устанавливать реалистичные ожидания по требованиям по доступности и разрабатывать реалистичную стратегию высокой доступности, основанную на этих ожиданиях.

Пределы оценки

    Ограничения оценки ограничиваются не только ограничениями различных высокодоступных технологий SQL Server, но и тех, которые не являются техническими. Если у вас бюджет всего в десятки тысяч юаней, но вы хотите сделать решение с высокой доступностью, основанное на дата-центрах вне площадки и репликации SAN, это, безусловно, глупая мечта. Ещё одно нетехническое ограничение — уровень оперативного персонала, и часто сложные архитектуры означают более квалифицированный персонал. Другие нетехнические ограничения включают наличие дискового пространства в дата-центре, соответствие потребностям источника питания и кондиционирования воздуха, а также время, необходимое для реализации стратегии доступности.

    Технические ограничения включают различные функции и ограничения высокой доступности, функции, поддерживаемые разными версиями SQL Server, количество процессоров и размер памяти. Настоятельно рекомендуется сначала ознакомиться с ограничениями различных версий и функций SQL Server на сайте Microsoft MSDN, прежде чем внедрять политику высокой доступности.

Избранная технология

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

Тестируйте, проверяйте и документируйте

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

В этой статье объясняются основные концепции высокой доступности, концепция SLA, различные типы функций высокой доступности, поддерживаемые SQL Server, и шаги, необходимые для разработки стратегии высокой доступности. Стоит отметить, что хотя в статье речь идёт только о высокой доступности на уровне базы данных, высокая доступность — это не только вопрос DBA, но и взаимодействие различных ролей, таких как персонал по эксплуатации и обслуживанию систем, сетевые администраторы, разработчики и менеджеры для лучшего соответствия SLA.