В статье «Лицензирование SQL Server в стеке» (опубликована в этом же номере журнала)
я рассказал об огромных экономических преимуществах организации стека экземпляров SQL Server. Это секретный прием, с помощью которого можно потенциально сэкономить миллионы в компаниях, использующих SQL Server. В данной статье речь пойдет о том, что мешает пользователям организовать стек экземпляров. Любопытно, приведет ли активно обсуждаемая сегодня тема контейнеризации (в частности, компании Docker (docker.com/)) к окончательному решению даже в ориентированном на Windows мире SQL Server.
Причина № 1. Трудности перемещения.
Переместить экземпляр с одного узла на другой — сложная задача, требующая немало времени (около 8 часов). В приведенной таблице описаны типовые шаги при миграции экземпляра с 200-гигабайтными базами данных на новый сервер.
.jpg) |
Даже если вам удастся сократить время вдвое, из-за малой мобильности практически невозможно упорядочить экземпляры в стеке в производственной среде. Представьте, что вы объединили в стек пять критически важных экземпляров, а затем в условиях новой рабочей нагрузки выяснилось, что два экземпляра негативно влияют друг на друга. В краткосрочной перспективе административной группе потребуется отключить один или оба экземпляра, чтобы попытаться устранить проблему. Производительность работы клиента неизбежно снижается. В идеальном случае административная группа может быстро переместить два проблемных экземпляра на другой сервер, чтобы уменьшить потери производительности, но для этого требуется быстро остановить и перезапустить экземпляры на другом сервере, одновременно сохраняя cтроки подключения приложения экземпляра. Это нелегкая задача, но если строка подключения может храниться внутри виртуального контейнера, уже хорошо.
Причина № 2. Сложно добиться высокого уровня доступности.
Проектирование и внедрение решения с высоким уровнем доступности (HA), обеспечивающим стабильную производительность одного критически важного экземпляра SQL Server — трудная задача. Добавление к решению упорядоченных в стеке экземпляров связано со слишком большим операционным риском. Отказ единственного экземпляра повлияет лишь на одну систему. Невозможность обеспечить высокий уровень доступности для группы организованных в стеке экземпляров может иметь катастрофические последствия для операционной целостности бизнеса. Лучше изолировать экземпляры в собственных двухузловых кластерах, чтобы уменьшить стоимость простоев. Если вы хотите организовать стек экземпляров как часть решения высокой доступности, то нужен способ назначить политики, «разводящие» экземпляры по целевым серверам, обеспечивающим выполнение соглашения об условиях обслуживания. Может ли контейнер содержать такие политики? Вероятно.
Причина № 3. Хлопотно управлять исправлениями.
Управление исправлениями в нескольких изолированных экземплярах на отдельных узлах вроде бы требует значительных усилий администратора, хотя на самом деле это очень простая задача. Уровнем обновления каждого экземпляра можно управлять в соответствии со специфическими требованиями базовой системы независимо от любого другого экземпляра. В среде с упорядоченными в стеке экземплярами следует обратить особое внимание на то, чтобы избежать непредвиденных последствий исправления одного экземпляра для любого другого экземпляра в стеке. В среде с единственным экземпляром нестабильное исправление изолировано на одном сервере. В среде со стеком экземпляров нестабильное исправление одного экземпляра может нанести ущерб рабочим характеристикам нескольких систем. Чтобы упростить управление исправлениями в среде со стеком экземпляров, необходим способ быстро перемещать экземпляры на неисправленные серверы, если на исправленном сервере возникают неполадки. И вновь, подход на основе облегченного контейнера поможет обеспечить такой уровень мобильности.
Несмотря на технические и операционные трудности, организация стека экземпляров SQL Server — это цель, к которой стоит стремиться, чтобы получить немалую экономическую выгоду от организации стека экземпляров. При всем ажиотаже вокруг решений компании Docker, я считаю, что контейнерная виртуализация для больших приложений — возможное решение.