Сандра Делани написала хорошо продуманную запись в блоге под названием Должен ли SQL Server DBA разбираться в Windows Server Failover Clustering? У неё около 20 лет опыта работы администратором баз данных, и она работает консультантом в Straight Path (компании, которую я уважаю). Вы, вероятно, можете догадаться, исходя из её опыта, что да, она считает, что вы должны знать, как настроить, сконфигурировать и устранять неполадки в кластерах Windows. Это хорошая статья, и вам стоит её прочитать.
Но... я не согласен.
Во-первых, у меня есть проблема с любой заметкой в блоге (даже с моей собственной), которая говорит: «Если вы называете себя X, вы определённо должны знать Y». Термин «администратор баз данных» охватывает огромное разнообразие должностей, которые занимают люди с самым разным уровнем опыта. Если человек находится на первом году работы администратором баз данных, может быть, даже на пятом, я не обязательно ожидаю, что он будет знать Windows Clustering.
Например, я однажды (недолго) работал в глобальной компании, где администраторам баз данных даже не давали разрешений взглянуть на кластер. Если служба SQL Server не запускалась, администраторам баз данных приходилось передавать проблему команде Windows, которая занималась кластеризацией. Логика компании заключалась в том, что кластеризация — это фундаментальная часть Windows, и она не имеет никакого отношения к SQL Server — и, более того, используется другими приложениями, поддерживающими кластеризацию. Устранение неполадок кластеризации — это адская головная боль, которая включает журналы Windows, DNS, IP-адреса и т.д., то есть всё то, в чём администраторы баз данных не сильны, — но команда Windows сильна (или, по крайней мере, должна быть).
Что подводит меня к другой статье в блоге...
Крисси Лемэр, создатель мощного и популярного набора инструментов DBAtools на PowerShell, написала основательную статью под названием Вы задумывались о том, чтобы не использовать высокую доступность SQL Server?. Вам тоже стоит прочитать эту статью.
Многие из вас — администраторы баз данных на полную ставку, и вы уже делаете глубокий вдох в предвкушении криков в ответ на экран, но подождите секунду.
Во-первых, вашим серверам SQL Server по-прежнему необходимо аварийное восстановление. Это другое. Когда мы говорим об аварийном восстановлении, мы обычно имеем в виду такие вещи, как встроенное резервное копирование SQL Server, доставка журналов, репликация хранилища и т.д. Это методы, которые вы можете использовать для восстановления сервера SQL Server в другом месте, например, после атаки вымогателей или стихийного бедствия. Никто не предлагает от этого отказываться.
Здесь мы говорим конкретно о функциях высокой доступности (HA): отказоустойчивые кластерные экземпляры (FCI), группы доступности Always On и зеркалирование баз данных. Крисси пишет об операционных сложностях этих функций.
Функции высокой доступности требуют 2 вида труда от 4 типов людей. В записи Крисси отмечается, что должны быть задействованы команды, управляющие базами данных, хранилищем, Active Directory/DNS и сетями. Я бы добавил, что от всех этих людей требуется 2 вида труда: как плановый, так и внеплановый/хаотичный. Когда происходит сбой производственной базы данных, начинается много взаимных обвинений, и руководство требует, чтобы все бросили свою работу и подключились к конференц-звонкам. Все начинают тыкать в различные переключатели и настройки, действуя вслепую и теряя время, пока всё не вернётся в норму — до следующей аварии на следующем сервере.
В небольших компаниях нет 4 типов людей. У них есть лишь небольшая основная группа ИТ-специалистов, которые делают всё. Они эксперты в том, как настроен весь стек в этой компании, но они не эксперты во всех базовых технологиях. Когда что-то идёт не так, работа обычно выполняется последовательно и зависит от одного человека, которому не повезло быть на смене. Этот человек с ещё большей вероятностью начнёт тыкать в различные переключатели и настройки, внося незапланированные, хаотичные изменения, которые со временем делают среду ещё менее стабильной.
Виртуализация обеспечивает довольно хорошую высокую доступность для многих типов сбоев во многих компаниях. При правильной настройке она защищает вас от отказов аппаратного обеспечения отдельных хостов и проблем с отдельными сетевыми кабелями. Нет, она не защитит вас от плохого патча Windows или SQL Server, но в небольших компаниях они всё равно не делают много обновлений. (Не возмущайтесь — я видел ваши данные SQL ConstantCare®, я знаю, что вы отстали на несколько накопительных обновлений, и я знаю, что вы отключили рекомендацию об установке обновлений.)
Высокой доступностью на уровне виртуализации проще управлять. Это всего лишь одна технология, которая работает для защиты всех ваших виртуальных машин. Это меньше знаний, которые перегруженный персонал должен освоить, и, кроме того, им всё равно придётся это изучать для защиты остальных серверов. Раз уж они используют её для всего остального, они вполне могут положиться на неё и для защиты SQL Server.
Поэтому, когда клиенты спрашивают меня о простых способах повысить время безотказной работы, и они уже запускают SQL Server на виртуальной машине, мы делаем шаг назад и смотрим на их настройку высокой доступности виртуализации. Если это работает хорошо, я объясняю часть про новую дополнительную плановую и внеплановую работу для всех различных ролей, а затем спрашиваю об их графиках дежурств и их планах по найму дополнительного персонала для выполнения этой новой дополнительной работы.
Если они не нанимали дополнительный персонал и не планируют этого, то я бы предпочёл, чтобы персонал сосредоточился на улучшении своей способности быстро восстанавливать резервные копии SQL Server, подготавливать и настраивать новые серверы и просто автоматизировать свою среду в целом. Это пригодится чаще и поможет как при аварийном восстановлении, восстановлении после вымогателей, восстановлении после ошибочных запросов на удаление, так и просто при реагировании на повседневные проблемы.
Краткие итоги
- Если вы не знаете, как устранять неполадки с DNS, общими файловыми ресурсами, проверкой кластеров Windows или PowerShell, то статья в блоге Крисси права, и вам, вероятно, стоит попробовать виртуализацию для высокой доступности.
- Если потребности вашей компании в высокой доступности и аварийном восстановлении требуют групп доступности и/или отказоустойчивых кластерных экземпляров, то статья в блоге Сандры права, и вам, вероятно, предстоит долгий путь обучения.
Комментариев нет:
Отправить комментарий