Перенос баз данных в облако

Одна из самых заметных тенденций в сегодняшней индустрии информационных технологий (ИТ) — перемещение баз данных в облако. Нам часто задают вопросы по проблемам миграции реляционных баз данных в Windows Azure, поэтому мы решили попытаться поговорить с группами, создающими различные продукты, и специалистами в этой области, чтобы получить конкретные ответы на ваши вопросы. Существует широкий спектр предложений, которые следует тщательно изучить до миграции, и принять во внимание целый ряд факторов, включая стоимость, совместимость, гибкость, масштабируемость, сопровождение, соответствие законодательству и т. д.

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

Многие клиенты путаются в вариантах, предлагаемых в облаке, особенно когда дело доходит до хостинга реляционных данных. В этой статье мы хотим прояснить варианты, касающиеся SQL Server и хранилища данных на платформе Windows Azure.

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

Некоторые варианты представлены на рис. 1. Вы можете использовать SQL Server минимум четырьмя способами, как указывают пронумерованные блоки. Заметьте: обозначены решения как на основе облака, так и с использованием локальных ресурсов предприятия. Верхняя половина рис. 1 относится к общедоступному облаку. Если вы глубже проанализируете общедоступное облако, то поймете, что оно покоится на двух основных столпах: Infrastructure as a Service (IaaS) и Platform as a Service (PaaS). Нижняя половина схемы иллюстрирует варианты с использованием SQL Server на предприятии. Вы можете либо осуществлять хостинг собственного частного облака или последовать традиционному методу и выполнять SQL Server на физическом оборудовании безо всяких технологий виртуализации.

Увеличить
Рис. 1. Варианты хостинга SQL Server

IaaS	IaaS
PaaS	PaaS
Web App	Веб-приложение
Web Role	Веб-роль
IIS	IIS
Windows Azure SQL Database Virtual Machine	Виртуальная машина с базой данных SQL в Windows Azure
Public Cloud	Общедоступное облако
Windows Azure SQL Database	Windows Azure SQL Database
SQL Server for Private Cloud	SQL Server для частного облака
VPN Tunnel	VPN-тоннель
Private Cloud	Частное облако
Non-Virtualized On-Premises SQL Server	Не виртуализованный SQL Server на предприятии
On-Premises Web Servers On IIS Web Farm	Веб-серверы предприятия на веб-ферме IIS
ON-PREMISES	На предприятии

Windows Azure Portal

Мы задействуем три компонента Windows Azure для развертывания нашей локальной базы данных в облаке, продемонстрировав модели как IaaS, так и PaaS: виртуальные машины (Virtual Machines, VM) (в IaaS), Windows Azure SQL Database (в PaaS) и Windows Azure Storage. К ним можно обращаться через портал управления, показанный на рис. 2. Первые два достаточно очевидны, но вариант со Storage может преподнести сюрприз. Windows Azure Storage необходим для хранения файла BACPAC, который содержит схему базы данных и сами данные в этой базе. Этот файл можно создать с помощью SQL Server Management Studio (SSMS); он является логическим эквивалентом резервной копии базы данных (database backup). SSMS сама разместит этот файл BACPAC в Windows Azure Storage, которое представляет собой идеальное место, поскольку отсюда его можно импортировать напрямую из облачных версий SQL Server, как видно из вариантов 3 и 4 на рис. 1.

Рис. 2. Windows Azure Management Portal

Четыре сценария

Вернувшись к рис. 1, вы заметите, что SQL Server связан с четырьмя основными сценариями использования. Эти сценарии пронумерованы в порядке увеличения эффективности, что в конечном счете приводит к сокращению затрат. Но параллельно ваш уровень контроля над аппаратным обеспечением и конфигурацией уменьшается, что влияет на уровень совместимости при развертывании баз данных предприятия в облаке.

Традиционный, «голое железо» Сценарий №1 заключается в выполнении SQL Server с применением традиционных подходов, что подразумевает отсутствие его виртуализации и высокую степень настройки ИТ-персоналом и администраторами баз данных. Естественно, поскольку это дает ИТ-персоналу полный контроль над тем, как все конфигурируется и как работает, от них требуется гораздо больше усилий в подготовке, сопровождении и масштабировании баз данных. Подготовка кластера к высокой доступности (high availability, HA), а также выполнение резервного копирования и восстановления — это лишь две из многих обязанностей, возлагаемых на администраторов баз данных.

На предприятии, частное облако Сценарий №2 подразумевает развертывание SQL Server в частном облаке, где применяется виртуализация для оптимального использования аппаратных ресурсов. Эта технология позволяет создавать пул баз данных SQL Server с помощью Windows Server 2012 Hyper-V для эффективного использования вычислительных ресурсов, сети и хранилища. Вы можете поддерживать эластичную инфраструктуру для своих баз данных, благодаря чему можно эффективнее реализовать вертикальное и горизонтальное масштабирование. С точки зрения управления, этот вариант обеспечивает встроенные возможности самообслуживания (self-service), что позволяет подготавливать базы данных, применяя Microsoft System Center 2012. Однако вы по-прежнему отвечаете за приобретение оборудования и поддержание системы в актуальном состоянии с помощью обновлений ПО.

Виртуальные машины (VM) Windows Azure SQL Server for VM (IaaS) позволяет вам разместить свой кластер в информационном центре Microsoft. Ключевое преимущество этого варианта с хостингом в общедоступном облаке — высокий уровень совместимости с существующими на предприятии базами данных SQL Server. Так как этот вариант поддерживает полнофункциональную версию SQL Server, вы можете использовать HA, транспарентное шифрование данных, аудит, бизнес-анализ (business intelligence, BI) (например, сервисы анализа и отчетности), распределенные транзакции, Active Directory (Active Directory Federation Services, или AD FS 2.0) и др. Более того, вы можете создать свою VM или задействовать шаблон из галереи образов Windows Azure (о ней — позже). Наконец, этот вариант позволяет легко создавать собственные виртуальные частные сети (VPN), формируя мост между облачными ресурсами и корпоративной сетью и обеспечивая бесшовную среду, где границы между информационными центрами Microsoft и вашими внутренними серверами размыты.

SQL Server for VM также поддерживает новую функцию Always-On, которая позволяет создавать до пяти копий базы данных, поддерживаемых каждым участвующим в процессе экземпляром. Каждый экземпляр SQL Server может размещать базу данных в своем локальном хранилище или в каком-то другом месте. Это обеспечивает хостинг в облаке корпоративного уровня в качестве альтернативы зеркальному отображению базы данных (database mirroring).

Другое преимущество виртуальных машин Windows Azure в том, что они позволяют задействовать возможности Windows Azure Storage, а это означает, что ОС и дисковые устройства автоматически сохраняются в Windows Azure по умолчанию, предоставляя три автоматически создаваемые копии ваших данных в информационном центре и обеспечивая использование при необходимости территориальной репликации (geo-replication). Вкратце, использование Windows Azure SQL Server for VM делает возможным перенос ваших приложений баз данных с предприятия в Windows Azure и минимизацию (если не полное исключение) необходимости в модификации приложения и базы данных.

Windows Azure SQL Database Чтобы прояснить любую путаницу в терминологии, следует понять, что Windows Azure SQL Database раньше называли SQL Azure. Таким образом, Windows Azure SQL Database — это и подмножество, и надмножество традиционной SQL Server; кроме того, она размещается в облаке как сервис.

Поскольку Windows Azure SQL Database на самом деле является сервисом, это дает некоторые реальные преимущества. Во-первых, он может обеспечить фантастическую экономию — некоторые компании сократили расходы на свои базы данных более чем на 90%, используя Windows Azure SQL Database. Во-вторых, он предоставляет средства самоуправления, позволяя организациям подготавливать сервисы данных для приложений в рамках их предприятий и обходиться без бремени поддержки центральным ИТ-отделом. В-третьих, сервис реплицирует три копии ваших данных и в случае аварии оборудования обеспечивает автоматическое восстановление.

Но ограничения все же есть. Максимальный размер базы данных — 150 Гб, хотя его можно увеличить за счет сегментирования (sharding) (горизонтального разбиения данных на разделы). Этот подход также приводит к более продолжительным задержкам из-за выполнения в общей инфраструктуре информационного центра Microsoft. Другой недостаток в том, что вы должны ожидать нерегулярные отказы и программировать с учетом этого фактора. Наконец, Windows Azure SQL Database представляет подмножество SQL Server, а значит, некоторые средства вроде XML, системных хранимых процедур, распределенных транзакций, синонимов, CLR-процедур, полнотекстового поиска и возможности связывания серверов не поддерживаются. Ввиду этих ограничений переход на Windows Azure SQL Database может оказаться в ряде сценариев неудачным выбором. Как видите, этот вариант не обеспечивает совместимость с экземплярами SQL Server на предприятии в отличие от предыдущего варианта — виртуальных машин Windows Azure SQL Server Database.

Некоторые соображения

При переносе базы данных из решения на предприятии в общедоступное облако, следует учесть несколько соображений. Один из важных факторов — производительность, охватывающий использование процессорных ресурсов, дискового ввода-вывода, ограничения памяти, а также сетевые задержки и пропускная способность. Кроме того, вы должны подумать о том, сколько дискового пространства вам потребуется и какое количество VM будет оптимально. Принимайте во внимание и топологию сети, если приложениям баз данных нужны соединения с ресурсами на предприятии, что потенциально потребует от вас создания VPN, а это другое предложение на платформе Windows Azure. Соответствие законодательству и безопасность тоже крайне важны, особенно когда дело касается клиентских данных: где именно хранятся и обрабатываются эти данные, как они передаются. Существуют серьезные юридические требования в отношении безопасности, например, всевозможной медицинской и страховой информации.

Перенос базы данных SQL Server в виртуальную машину Windows Azure

Хотя Microsoft выпустила CTP-версию мастера развертывания, мы выбрали подход, требующий больше ручной работы, — он даст вам лучшее представление о том, что происходит в процессе развертывания. Мы создадим файл BACPAC из базы данных на предприятии, а затем импортируем его в нашу виртуальную машину с Windows Azure SQL Server.

До создания файла BACPAC мы рекомендуем два предварительных этапа. Сначала отключите всех пользователей от базы данных и выполните традиционное резервное копирование. Это сохранит целостность журнала транзакций и гарантирует корректное развертывание базы данных во всей ее полноте. Мы абсолютно не рекомендуем создавать файл BACPAC из активной производственной базы данных. Файлы BACPAC должны создаваться только из резервных образов. Затем создайте VM с Windows Azure SQL Server. Вы можете создать свою VM и загрузить ее в облако, если хотите, но проще использовать галерею образов Windows Azure, которую вы найдете на Windows Azure Management Portal. Там вы просто выберете подходящее из списка доступных образов VM.

Чтобы начать процесс, войдите в Windows Azure Management Portal. В строке команд щелкните New | Virtual Machine | From Gallery. На рис. 3 перечислен ряд разновидностей SQL Server и Windows Server, их которых вы можете выбирать.

Рис. 3. Галерея образов для виртуальных машин Windows Azure

Выбрав образ из галереи, вы можете выбрать нужное из списка аппаратных вариантов. На рис. 4 показано, что на верхнем уровне вы можете выбрать восемь ядер и 56 Гб оперативной памяти.

Рис. 4. Доступные конфигурации виртуальных машин

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

1. Чтобы создать файл BACPAC, запустите SSMS и подключитесь к экземпляру на предприятии (локальному экземпляру).
2. Затем в Object Explorer раскройте узел для экземпляра, из которого вы хотите экспортировать базу данных, и создайте BACPAC.
3. Щелкните правой кнопкой мыши название базы данных, щелкните Tasks, а затем выберите Export Data-tier Application. Появится мастер, и вам предложат указать хранилище для файла BACPAC.

Замечательная вещь здесь заключается в том, что мастер позволит вам сохранить файл BACPAC в Windows Azure Storage в информационном центре Microsoft, что может кардинально упростить процесс импорта из Windows Azure SQL Server VM. Если у вас нет учетной записи хранилища, вам понадобится перейти в Windows Azure Management Portal и создать ее. Обязательно запишите где-нибудь имя учетной записи хранилища и связанный с ней ключ управления, так как они потребуются мастеру. Предполагая, что вы не столкнулись ни с какими ошибками, считайте, что создание файла BACPAC закончено. Заметьте, что этот процесс может занять от нескольких минут до нескольких часов в зависимости от размера вашей базы данных. Более того, как уже упоминалось, вы должны понимать, что это сделает недоступным сервис существующим подключенным пользователям, поэтому перед созданием файла BACPAC нужно выполнить традиционное резервное копирование.

Файл BACPAC — это просто большой двоичный объект в Windows Azure Storage. Как только он успешно создан, вы можете запустить Visual Studio и просмотреть этот файл с помощью Server Explorer (или аналогичной утилиты, позволяющей просматривать Windows Azure Storage). URL для вашего файла BACPAC будет выглядеть примерно так: https://[имя вашей учетной записи хранилища].blob.core.windows.net/[имя вашего контейнера]/[имя вашей базы данных].bacpac.

Удаленное взаимодействие с вашей SQL Server Database VM Теперь вы должны удаленно взаимодействовать с созданной вами ранее SQL Server Database VM. Заметьте, что в этом случае для входа нужно вводить не удостоверения вашей подписки на Windows Azure, а удостоверения, указанные при создании VM. В нашем случае имя — «msdn-vm\the-admin» плюс пароль, введенный нами.

Импорт файла BACPAC из Windows Azure Storage Как только вы вошли в VM, можно импортировать файл BACPAC в облачную VM.

1. Запустите SSMS и подключитесь к локальному экземпляру SQL Server.
2. В Object Explorer щелкните правой кнопкой мыши Databases, а затем выберите Import Data-tier Application для запуска мастера. Этот мастер аналогичен тому, который вы использовали при создании файла BACPAC из базы данных на предприятии. И вновь введите удостоверения для учетной записи хранилища, например имя этой учетной записи и ключ управления. Мастер покажет контейнер и имя файла BACPAC.
3. Щелкните Next, чтобы выполнить процесс импорта базы данных. Рис. 5 иллюстрирует успешный импорт базы данных в облачную VM в информационном центре Microsoft.

Рис. 5. Успешный импорт MarketIndexData

Перенос базы данных SQL Server в Windows Azure SQL Database

Как отмечалось ранее, Microsoft предлагает PaaS-решение для баз данных, известное как Windows Azure SQL Database. Чтобы импортировать файл BACPAC (только что созданную вами упакованную локальную базу данных), войдите в Windows Azure Management Portal. Выберите SQL Databases, а затем Import из Command Window. Вам будет предложено ввести URL файла BACPAC, хранящегося в Windows Azure Storage как большой двоичный объект (рис. 6). Это тот самый URL, который вы уже использовали для файла BACPAC. И это одно из крупных преимуществ файлов BACPAC: их можно использовать для импорта как из Windows Azure SQL Database, так и из Windows Azure SQL Server Database VM.

Рис. 6. Импорт файла BACPAC

По окончании импорта вы сможете открыть базу данных в SSMS, как и в случае Windows Azure SQL Server Database VM. По сути, SSMS работает со всеми четырьмя вариантами, представленными ранее. Вам нужно лишь получить имя сервера из Windows Azure Management Portal для базы данных и разрешить конкретные клиентские IP-адреса на портале. Более подробные сведения вы найдете на странице Tools and Utilities Support (Windows Azure SQL Database) по ссылке bit.ly/Vh8jGg.

Заключение

Платформа Windows Azure быстро развивается, особенно в области технологий VM и баз данных SQL Server. Клиенты активно переносят свои базы данных в облако, стремясь к сокращению расходов, а также к использованию других ресурсов, таких как хранилище, кеширование, идентификация, VPN, обмен сообщениями и т. д. Хотя Windows Azure SQL Database может предложить колоссальную экономию расходов, этот вариант не обеспечивает уровень совместимости, требуемый многими корпоративными клиентами. В будущих выпусках SSMS (2014) ожидается, что мастера развертывания полностью автоматизируют ручной процесс, продемонстрированный в этой статье. Когда такие мастера появятся, вы уже будете твердо знать, как они работают и что делают.