Когда кто-то спрашивает об архитектуре SQL Server, рефлекторным ответом обычно становится «Высокая доступность» (High Availability, HA), будто это требование, а не выбор. Но после 20 лет управления средами SQL Server я обнаружила, что высокая доступность часто создаёт больше проблем, чем решает, особенно в организациях определённого типа.
Проблема текучести кадров
В большинстве мест, где я работала, наблюдается ротация персонала — люди уходят в течение 1–4 лет по разным причинам. Это означает, что инфраструктура, которую мы строим, должна быть максимально простой, потому что все мы можем покинуть компанию в эти же сроки.
Высокая доступность SQL Server не является простой. Она постоянно отключается в высокозащищённых средах, требует постоянного присмотра и специальных навыков. Кроме того, я не видела вакансий, посвящённых исключительно «администратору SQL Server», уже много лет, поэтому, когда я уйду, меня, скорее всего, заменит универсальный специалист. Из-за этого я не настраиваю ничего, что требует присмотра или углублённых знаний. Старый добрый изолированный (Standalone) SQL Server не требует ни того, ни другого.
Когда ваше целевое время восстановления (RTO) измеряется днями
В большинстве мест, где я работала, целевое время восстановления (RTO) невероятно велико. Я однажды радостно рассмеялась, узнав, что на моём рабочем месте было 48 часов на возвращение в онлайн. За это время я могла бы построить 48 серверов SQL Server! Зачем использовать что-то, что зависит от стабильности сети и хранилища, если среды, в которых я работаю, этой стабильности не обеспечивают?
В высокозащищённых средах «Высокая» в «Высокой доступности» часто не существует. Возможно, виной тому шифрование, комплексы антивирусной защиты или нестабильные/развёртываемые сети, но группы доступности (Availability Groups) и отказоустойчивые кластеры часто вносят больше простоев, чем предотвращают.
Скрытая сложность: это не только SQL
Высокая доступность SQL Server — это не только проблема SQL Server. Кластеры и группы доступности требуют координации между администраторами хранилищ, сетевыми инженерами, специалистами по виртуализации и администраторами баз данных SQL Server.
Во время тестирования непрерывности операций (COOP) мы попытались поднять наш кластер на вторичном сайте хранения. Запуск потребовал работы с аппаратными дисками VMware (RDMs) и конфигурациями хранилища, для которых были нужны несколько команд. Спустя 33 часа мы наконец-то заставили его работать. После этого администратор хранилищ умолял меня перейти на изолированные серверы — лучшее оправдание, которое я когда-либо получала.
Когда ваше решение для высокой доступности становится тем, что проваливает тестирование аварийного восстановления, что-то не так. И когда ваша команда по хранилищам просит вас упростить, вы понимаете, что сложность вышла из-под контроля. Когда всё ломается в 2 часа ночи в выходные, вам нужно, чтобы все эти специалисты были доступны одновременно. Удачи!
Примеры из реальной жизни
Я помню одну работу, где я заменила все наши кластеры на изолированные серверы SQL Server. Я перенесла работу по аварийному восстановлению на VMware Site Recovery Manager, потому что именно это использовалось в остальной части нашей инфраструктуры. Это означало, что другие тоже смогут восстановить SQL Server в чрезвычайной ситуации, а не только я.
После моего ухода я поговорила со старым коллегой о том, как идут дела. Он сказал: «Практически всё летит к чертям, кроме твоих серверов SQL Server». Я даже не преувеличиваю — это одно из моих самых гордых достижений. Изолированный SQL Server — лучший.
Недавно я уволилась с работы, где мне досталась среда, работающая на группах доступности. Человек, который её настраивал, был компетентен, и система оставалась стабильной, пока мы оба за ней ухаживали. Но после моего ухода серьёзный сбой сети отправил эти группы доступности прямиком на свалку. После нескольких дней простоя меня попросили вернуться и помочь. Мы разработали план по замене их на изолированные серверы, и с тех пор они остаются стабильными, даже когда сетевые инженеры вносят агрессивные изменения.
Когда этот подход имеет смысл
Итак, для тех из вас, кто видел необходимость в этом в своей собственной среде, я могу сказать вам и вашему начальнику, что я, Крисси Лемэр, Microsoft Data Platform MVP, администратор баз данных с более чем 20-летним стажем, автор книг и создатель dbatools, не использую высокую доступность SQL Server по умолчанию. Я тщательно оцениваю, действительно ли она необходима. Вот что я учитываю:
- Моё требование к RTO всегда больше 2 секунд и всегда больше, чем время, необходимое мне, чтобы просто построить совершенно новый сервер SQL Server.
- Я обычно поддерживаю небольшое число пользователей: в среднем от 250 до 1000 человек.
- Если мне достаётся среда SQL Server с высокой доступностью, я не вычищаю её немедленно. Как администратор баз данных, я консервативна в своём подходе и подожду, пока она не начнёт сбоить или пока не потребуется миграция по другой причине.
- В моей среде нет стабильности сети или специализированного персонала для долгосрочного обслуживания решений высокой доступности.
И снова, люди, которым достаются мои среды, испытывают облегчение, и это изменение всегда встречалось положительно. Кроме того, в качестве дополнительного аргумента при представлении этой идеи руководству у меня всегда готов скрипт dbatools для развёртывания всего из резервной копии. Покажите им, что вы можете восстановить весь сервер за считанные минуты, и внезапно эти 48 часов RTO кажутся излишеством.
Как упростить с помощью dbatools
Ознакомьтесь с dbatools.io/dr и, в частности, с командой Export-DbaInstance, которая экспортирует имена входа, почту базы данных, учётные данные, задания агента, связанные серверы и многое другое — в общем, всё, что нужно для восстановления сервера. Вместе с Install-DbaInstance она может сделать восстановление лёгким делом. Попрактикуйтесь в автоматической установке, посмотрите, сколько времени это занимает, а затем включите это в своё обоснование.
Как отмечается в записи блога, высокая доступность (HA) и аварийное восстановление (DR) — это две разные вещи, но с RTO в 48 часов различие становится менее критичным. Независимо от того, упадёт ли SQL Server из-за сбоя кластера или полной катастрофы, у меня одно и то же окно восстановления. Хорошая автоматизация аварийного восстановления может справиться с обоими сценариями без накладных расходов на поддержание инфраструктуры высокой доступности.
Пора ли пересмотреть устоявшуюся практику?
Я знаю, что это противоречит общепринятой мудрости. Высокая доступность стала рекомендацией по умолчанию, когда создание нового сервера было многосуточной работой. Но благодаря современной автоматизации и инструментам вроде dbatools восстановление полной среды может занимать минуты вместо дней.
Вопрос не в том: «Можем ли мы позволить себе простой?» Вопрос в том: «Уменьшает ли высокая доступность время простоя в нашей среде?» Во многих случаях — особенно в высокозащищённых или нестабильных сетях — ответ «нет». Высокая доступность вносит сложность, требует специализированных знаний и часто создаёт больше простоев, чем предотвращает.
Я не говорю, что высокая доступность никогда не нужна. Если вы управляете жизненно важными системами или поддерживаете тысячи одновременных пользователей со строгими соглашениями об уровне обслуживания (SLA), она вам, вероятно, необходима. Но если ваше RTO измеряется часами или днями, и в вашей среде не хватает стабильности или персонала для правильного обслуживания высокой доступности, хороший план аварийного восстановления с автоматизацией может послужить вам лучше.
Возможно, пора задаться вопросом, действительно ли ваша конкретная среда нуждается в высокой доступности, вместо того чтобы считать её универсальной лучшей практикой.
С любовью к изолированному SQL Server,
Крисси
Комментариев нет:
Отправить комментарий