В версии VMware Data Services Manager 9.1 поддержка Microsoft SQL Server переведена в статус общей доступности на платформе VCF — продукт полностью поддерживается и готов к промышленным нагрузкам.
В демонстрации, подготовленной Эриком Греем (Eric Gray) из подразделения технического маркетинга VCF, показан полный цикл восстановления базы данных на произвольный момент времени. В стенде уже развёрнут промышленный кластер Always On availability group из трёх узлов, на котором работают базы данных. Задача — восстановить одну из этих баз на конкретный момент времени для отладки, не изменяя и не затрагивая работающий кластер.
Исходное состояние стенда
Работа ведётся в интерфейсе управления DSM под учётной записью администратора DSM. Среда заранее подготовлена: настроена интеграция с Active Directory, сконфигурированы S3-совместимые хранилища для резервных копий баз данных и системных бэкапов, а также уже запущено несколько баз данных.
Основное внимание в демонстрации уделяется SQL Server. В окружении уже работает один экземпляр SQL Server, и его можно рассмотреть подробнее.
Одна из особенностей, отличающих SQL Server от СУБД с открытым исходным кодом в DSM, — намеренно проведённое разделение между базовым экземпляром (instance) и пользовательской базой данных. На скриншоте видно, что базовый экземпляр состоит из трёх узлов и представляет собой кластер Always On availability group. Он интегрирован с Active Directory, работает под управлением SQL Server 2022 с накопительным обновлением и находится в использовании.
На этом экземпляре размещены две пользовательские базы данных, названные в честь деревьев — spruce и pine. В рамках операции демонстрируется восстановление базы pine на момент времени с размещением копии на новом базовом экземпляре, предназначенном для отладки.
Создание нового экземпляра SQL Server
Первым шагом создаётся новый экземпляр SQL Server — так не придётся вмешиваться в существующий трёхузловой HA-кластер. Экземпляру задаётся имя (в демонстрации используются названия штатов), после чего выбирается редакция. Для решаемой задачи достаточно редакции Developer, однако DSM предлагает и другие варианты — на случай, если требуются возможности уровня Enterprise.
Далее можно указать имя и пароль административной учётной записи либо оставить эти поля пустыми: тогда DSM сгенерирует учётные данные автоматически. Второй вариант удобнее — при необходимости их всегда можно посмотреть позже.
Интеграция с Active Directory
Здесь проявляется одно из ключевых преимуществ связки DSM и Microsoft SQL Server — работа с Active Directory. В качестве подготовительного шага интеграция с AD в DSM уже настроена: указаны имя домена и учётные данные. Поэтому при создании нового экземпляра достаточно выбрать опцию присоединения к домену.
Для этого указывается заранее созданная на стороне AD учётная запись с необходимыми правами и включается запись DNS-имён. Задаётся IP-адрес сервера AD, выполняющего роль DNS-сервера, и вводится полное доменное имя (FQDN). DSM самостоятельно создаст прямую и обратную записи для этого FQDN, благодаря чему к экземпляру можно будет обращаться по имени, а не по IP-адресу.
Чтобы продолжить, необходимо принять лицензионное соглашение Microsoft и перейти к выбору топологии развёртывания.
Топология развёртывания и инфраструктурные политики
Рассмотренный ранее экземпляр использовал трёхузловую конфигурацию Always On availability group — кластер для обеспечения высокой доступности и отработки отказов. Для текущего проекта, связанного только с восстановлением ради отладки, высокая доступность не нужна, поэтому создаётся одиночный виртуальный экземпляр SQL Server.
В DSM существует понятие инфраструктурных политик — это ресурсы, на которых выполняются сами базы данных. Доступны два варианта: пространство имён vSphere либо политика, создаваемая в клиенте vSphere, — так называемая DSM managed policy. Она представляет собой набор ресурсов: кластер, пул IP-адресов, набор классов виртуальных машин. Эти ресурсы создаёт администратор vSphere, и они становятся местом размещения базы данных.
Пространство имён vSphere в данном стенде было создано в VCF Automation для другого проекта, поэтому оно не используется — выбор делается в пользу политики DSM. Соответствующая политика хранения подставляется автоматически, остаётся выбрать класс виртуальной машины. Произвольные значения CPU и памяти задать нельзя: выбор ограничен классами, подготовленными администраторами. В данном случае четырёх vCPU и 8 ГБ оперативной памяти более чем достаточно.
Если бы речь шла о промышленной базе данных, с которой будут работать администраторы SQL Server, им наверняка потребовался бы включённый агент SQL Server для планирования регламентных заданий, а также специфические настройки конфигурации SQL Server. Всё это задаётся на данном шаге. Для отладочного проекта достаточно значений по умолчанию.
После итогового просмотра всех параметров запускается создание экземпляра. Процесс занимает несколько минут: в фоновом режиме на инфраструктуре vSphere разворачивается новая виртуальная машина, внутри неё устанавливается Microsoft SQL Server, после чего экземпляр вводится в работу.
Настройка политики сервиса данных
Следующий шаг — получить доступ к новому экземпляру баз данных в DSM. Доступ полностью управляется через концепцию политик сервисов данных (data service policies). В рассматриваемом окружении политика для SQL Server уже существует, поэтому вместо создания новой достаточно отредактировать имеющуюся. Эта политика определяет, кто, что и где может запускать.
Сейчас она настроена на применение ко всем пространствам имён — в тестовой среде это самый простой вариант. Кроме того, политика управляет тем, к каким серверам баз данных имеет доступ пользователь.
До этого момента в списке присутствовал только экземпляр nevada — тот самый трёхузловой HA-кластер. Поскольку в среде появился новый экземпляр arizona, его необходимо отметить, чтобы получить возможность разворачивать на этой инфраструктуре новые пользовательские базы данных.
Новый одноузловой SQL Server будет использоваться временно и, скорее всего, впоследствии удалён, поэтому резервное копирование для него делать необязательно. Политика меняется с режима «требовать резервные копии», который необходим при использовании варианта с HA-кластером, на режим «разрешать резервные копии». В результате базы данных на HA-кластере продолжают резервироваться, а для одиночного экземпляра резервное копирование можно не задействовать.
Типы аутентификации остаются без изменений — разрешены оба: Windows Active Directory и связка «имя пользователя и пароль SQL Server». Второй вариант считается менее безопасным, но зачастую более удобным, поэтому пока допускаются оба. После краткой проверки настроек политика сохраняется и готова к использованию.
Восстановление базы данных на момент времени
Далее выполняется возврат к разделу SQL Server и переход на вкладку баз данных, где видны две работающие пользовательские базы. Из существующей базы данных запускается восстановление на определённый момент времени.
Это востребованная возможность. Например, произошло повреждение данных или кто-то внёс изменения, и требуется вернуться назад, чтобы понять, как база выглядела в определённый момент, — ради отладки. В мастере выбирается вариант Custom Time вместо восстановления на последнюю доступную точку, после чего указываются нужные дата и время.
Копия разворачивается не поверх существующего экземпляра, где работает «живая» база, а на новом экземпляре arizona, созданном ранее. База при этом переименовывается — так её проще запомнить.
Имя пользователя не меняется: используется аутентификация Windows и учётная запись Active Directory с именем DBA. Резервные копии для этой базы отключаются, чтобы не засорять корзину S3, — база всё равно будет удалена через день-два. После итогового просмотра параметров запускается восстановление. В результате в среде появляется третья база данных SQL Server, размещённая на другом сервере SQL Server и готовая к работе.
Подключение через SQL Server Management Studio
Дальнейшая работа переносится на рабочий стол Windows, где выполнен вход под той самой доменной учётной записью DBA. Заранее открыта SQL Server Management Studio, в которой уже указано полное доменное имя только что созданного экземпляра базы данных. Соответствующая запись в DNS присутствует — её автоматически создал DSM.
Остаётся ввести имя новой базы данных, работающей на этом экземпляре. Шифрование и доверие сертификату сервера также настроены. После нажатия кнопки подключения база открывается так же, как любая другая знакомая база SQL Server.
Видно, что это копия на определённый момент времени: в ней уже присутствует таблица cities — набор данных о городах со всего мира, и данные в ней есть. Начиная с этого момента разработчик или администратор баз данных может выполнять запросы и выяснять состояние тех элементов, которые предположительно вызывают проблемы и требуют расследования путём восстановления на момент времени.
Итог
Показанный сценарий представляет собой восстановление базы данных SQL Server на момент времени с размещением на полностью изолированном экземпляре. Промышленный кластер при этом не был затронут.
DSM самостоятельно подготовил целевой экземпляр, присоединил его к Active Directory, автоматически зарегистрировал DNS-запись и восстановил базу данных на точно указанную метку времени. Администратор базы данных подключился с использованием аутентификации Windows — без необходимости управлять паролями. Ручных операций с инфраструктурой и заявок в поддержку не потребовалось.
Именно так выглядит управление жизненным циклом SQL Server на платформе VCF в DSM 9.1: автоматизированно, управляемо и с готовностью к промышленной эксплуатации.
RSS
