CC BY
23
УДК 004.4
Д. В. Кадашев
Новосибирский государственный университет ул. Пирогова, 2, Новосибирск, 630090, Россия E-mail: dkadashev@gmail.com
СИСТЕМА МИГРАЦИИ ХОСТИНГОВЫХ СЛУЖБ В PARALLELS OPERATIONS AUTOMATION
Анализ требований к системе миграции хостинговых служб между различными системами управления и автоматизации хостинга. Рассматривается применимость существующих универсальных решений переноса служб хостинга с точки зрения миграции между системами управления хостингом. Описание реализации подсистемы миграции продукта Parallels Operations Automation.
Ключевые слова: хостинг, хостинговые службы, миграция, система управления, автоматизация.
Введение
Огромная популярность глобальной сети Интернет привела к появлению нового вида услуг - предоставления хостинга, т. е. выделения комплекса ресурсов и служб для размещения веб-сайта, электронной почты или других целей и обеспечения его доступности. В связи с высокой популярностью данных услуг (на сегодняшний день крупным компаниям, занимающимся предоставлением хостинговых услуг профессионально - хостинговым провайдерам, приходится обслуживать тысячи клиентов и управлять сотнями видов ресурсов) широкое распространение получили системы автоматизации хостинга, потому что управлять вручную таким количеством различных служб не представляется возможным. Эти средства автоматизации могут представлять собой как набор сценариев на интерпретируемом языке, так и крупные распределенные программные системы. И когда провайдера по каким-то причинам перестает удовлетворять текущая система автоматизации, перед ним встает проблема: как переместить всю существующую инфраструктуру на новый продукт (и часто одновременно -на новый набор серверов).
Различные системы автоматизации хостинга, как правило, не имеют ничего общего в своей низкоуровневой внутренней организации, поэтому миграция представляет собой нетривиальную задачу. Для решения этой проблемы создаются средства переноса хостинговых данных между системами автоматизации - средства миграции. Следует заметить, что большинство производителей хостинговых служб, таких как веб-серверы Microsoft IIS или Apache, предоставляют средства, которые могут использоваться для миграции с сервера на сервер, однако для переноса всего хостинга они неприменимы, так как требуется не только перенос данных самих служб, но и копирование данных самой системы автоматизации, таких как информация о клиентах, используемых ими ресурсах, различные биллинговые данные и т. д.
Для решения этой проблемы при миграции с одной системы автоматизации хостинга на другую необходимо получать дополнительную информацию об установленных на исходной хостинговой платформе клиентских службах, которая необходима целевой системе автоматизации для управления этими службами.
Можно выделить два варианта миграции хостинга.
1. Установка новой системы автоматизации на те же серверы, на которых установлена старая система.
2. Использование новой аппаратной инфраструктуры.
В первом случае серверы исходной системы включаются в целевую систему без значительных изменений. При этом с серверов должен быть осуществлен сбор информации, необходимой целевой платформе для организации управления, т. е. произведена синхронизация управляющей платформы с управляемыми серверами. Во втором - клиентские данные переносятся с серверов исходной платформы на серверы целевой. В этом случае, так же, как и в
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2010. Том 8, выпуск 1 © Д. В. Кадашев, 2010
предыдущем, целевая система должна получить необходимые данные, описывающие объекты хостинга исходной системы, которые затем реплицируются на целевую систему. Во втором варианте дополнительно необходимо перенести наполнение пользовательских служб (например, содержимое веб-сайта).
Существующие решения
Как указывалось ранее, многие производители программных продуктов, используемых в качестве хостинговых служб, предоставляют средства миграции, позволяющие переносить объекты хостинга с одного сервера (или группы серверов) на другой.
Такие средства можно разделить на две категории.
1. Инструменты, предназначенные для осуществления миграции объектов с одного сервера на другой. В качестве параметров задаются: сервер-источник, идентификаторы объектов (множество объектов также может задаваться шаблоном-фильтром и др.), которые необходимо перенести, сервер-приемник. Если требуется заменить существующие (на целевом сервере) объекты на переносимые, дополнительно указываются идентификаторы целевых объектов. В качестве примеров таких инструментов можно привести утилиту Internet Information Services Migration Tool (приложение, позволяющее переносить конфигурацию и содержимое веб-сайта с одного сервера IIS 6.0 на другой), а также средства Microsoft Exchange Server, такие как Exchange Migration Wizard (в версии 2000), Exchange Task Wizard (в версии 2003), In-terOrg Replication (позволяет переносить общие папки Exchange как в пределах одной Exchange-организации, так и между различными организациями).
2. Инструменты, предназначенные для резервного копирования объектов системы. Средства этой категории позволяют архивировать текущее состояние объекта с возможностью последующего его восстановления. Несмотря на иную направленность, с помощью этих средств также можно осуществить миграцию объекта с одной системы на другую, поскольку очень часто восстановление «сохраненного» объекта возможно на сервере, отличном от того, на котором была сделана резервная копия. К таким инструментам можно отнести средства резервного копирования / восстановления баз данных у СУБД Microsoft SQL Server, MySQL, PostgreSQL, а также утилиту ExMerge (предназначена для резервного копирования содержимого почтовых ящиков Microsoft Exchange Server различных версий).
Инструменты, относящиеся к обеим описанным категориям, позволяют осуществлять перенос объектов между хостинговыми платформами, однако в то же время они обладают большими недостатками.
• Для работы средств из первой категории необходима возможность доступа к целевому серверу (целевая хостинговая система) с сервера-источника (исходная хостинговая система) и / или наоборот, что зачастую довольно сложно обеспечить (как правило, большинство серверов хостинговых систем недоступны из внешней сети).
• Безусловный перенос всей конфигурации объекта часто бывает нежелательным, а в некоторых случая перенесенный таким образом объект может стать неуправляемым для системы автоматизации целевой платформы. Системы автоматизации могут накладывать ограничения на управляемые объекты, эти ограничения учитываются при создании объекта, однако перенесенный объект может не удовлетворять ограничениям, что может нарушить работу системы.
• При использовании средств из обеих категорий репликация осуществляется без какой -либо возможности участия системы автоматизации и, как следствие, системе автоматизации не предоставляется информация о появившихся новых объектах хостинга. Система автоматизации в этом случае должна иметь возможность извлекать информацию об объектах хостинга, что в подавляющем большинстве случаев не предусмотрено (по причине ненадобности в общем случае) в системах автоматизации.
На рынке представлены компании, такие как RAKSource, USA.NET - Transition Team For Email Hosting, занимающиеся организацией миграции, при этом взаимодействие осуществляется непосредственно с хостинговыми службами (как на исходной, так и на целевой системах) и наличие системы автоматизации не подразумевается (кроме того, услуги таких компаний являются дорогостоящими и их использование кажется неоправданным, когда, например,
речь заходит о миграции с небольшой системы с ручным управлением). Некоторые средства автоматизации хостинга позволяют осуществлять миграцию с других автоматизированных платформ, но обычно они привязаны к структуре платформы конкретного типа, не позволяя организовывать миграцию с новых платформ. Кроме того, эти средства часто не являются общедоступными.
Разновидности систем управления хостингом
Системы управления хостингом можно разделить на три группы.
1. Универсальные системы автоматизации. Здесь система автоматизации является законченным продуктом. Провайдеры покупают такую систему у компании-производите ля. Как правило, такие системы имеют контрольные панели, через которые осуществляется управление хостинговой платформой.
2. Частные системы автоматизации. Система автоматизации разрабатывается на заказ. Сложность системы автоматизации может варьироваться в очень широком диапазоне: от набора сценариев с параметрами для конфигурации той или иной клиентской службы (создание, изменение параметров, удаление) до средств администрирования с панелями управления, предоставляющими web-интерфейс.
3. Неавтоматизированные. На таких платформах какие-либо дополнительные средства автоматизации отсутствуют. Управление службами ведется посредством системных средств администрирования, поставляемых вместе с хостинговыми службами.
Системы автоматизации хостинга в свою очередь можно разделить на следующие два класса.
1. С возможностью мониторинга / изменения созданных объектов системы. Такие средства автоматизации хранят дополнительные сведения о созданных объектах и позволяют увидеть / изменить их текущую конфигурацию.
2. Позволяющие однократно создать тот или иной объект без возможности дальнейшей модификации и мониторинга. Такие средства не ведут учета созданных объектов, и их параметров и служат только для автоматизации развертывания / удаления клиентских служб.
Требования к средствам миграции
Ввиду широкого распространения всех вышеперечисленных видов систем управления хостингом инструмент миграции должен быть универсальным, т. е. поддерживать все разновидности систем управления хостингом. Кроме того, он должен быть приспособлен работать и на ЦМХ'-подобных, и на Windows платформах, так как обе платформы активно используются для хостинга.
Добавление поддержки новых систем автоматизации должно быть дешевой операцией и не требовать изменения существующего кода.
Формат данных, используемый для описания хостинга, должен естественным образом поддерживать представление иерархических структур для того, чтобы иметь возможность прозрачно описывать конфигурацию хостинга и хостинговых служб. Также этот формат данных должен иметь возможность задавать поля-идентификаторы для объектов и использовать ссылки на них.
Предлагаемое решение
В качестве решения предлагается система, состоящая из двух компонентов: менеджера миграции и набора миграционных агентов. Для каждой системы управления хостингом, миграция с которой поддерживается, должен существовать специфичный агент миграции, так как написать универсальный модуль для сбора информации о хостинговой платформе невозможно ввиду кардинальных различий между различными системами управления. Кроме сбора информации, агент может производить некоторые действия на исходной системе, такие как отключение сущностей (например, пользовательских служб) после завершения миграции. Таким образом достигается легкая расширяемость системы: для добавления поддержки но-
вой системы достаточно реализовать нового агента и зарегистрировать его в менеджере миграции. Для защиты от злоумышленников агенты подписываются при помощи PGP-подписи. В то же время существует возможность установки неподписанного агента, с тем чтобы покупатели миграционного менеджера могли реализовать и зарегистрировать свой агент.
Рис. 1. Организация системы миграции
Для описания структуры хостинга исходной системы предлагается XML-протокол, при разработке которого были рассмотрены различные службы хостинга и проведена работа по выявлению общих черт этих служб, для того чтобы, используя данный протокол, можно было естественным образом описать как можно большее количество различных служб. В данном протоколе присутствуют документы трех типов.
• Описывающие исходную платформу в целом. Такие документы содержат общую информацию о системе автоматизации - список зарегистрированных пользователей (провайдер, посредник, конечный пользователь) с общей информацией о «подписках» - наборах служб, продаваемых как одно целое. Причем список пользователей представляет собой дерево, корнем которого является пользователь-провайдер, а остальными узлами - посредники и конечные пользователи. Непосредственными потомками какого-либо узла А являются пользователи, покупающие ресурсы у пользователя А. Конечные пользователи являются листами данного дерева.
• Описывающие отдельно взятого пользователя. Эти документы содержат подробную информацию о пользователе (его платежный баланс, контактную информацию, сведения о средствах оплаты; о его подписках, например время начала и окончания действия подписки; и о доменах, принадлежащих ему).
• Описывающие подписку. Данные документы содержат информацию о конфигурации и наполнении (например, содержимое таблиц БД или файлы, составляющие веб-сайт) хостинговых служб, входящих в подписку.
Разделение информации, получаемой от агентов, на данные типы позволило сократить размер передаваемых за один раз данных, а также чаще обновлять информацию: так как размер документа, описывающего пользователя, как правило, не очень велик, то перед миграцией этого пользователя можно запросить у агента информацию о нем на случай, если что-то изменилось со времени последнего обновления данных.
Кроме предоставления этих документов, агент должен по запросу предоставлять наполнение того или иного сервиса в бинарном виде. Предполагается, что в документе, описывающем подписку, для каждого сервиса может быть один или несколько идентификаторов напол-
нения, при запросе наполнения агенту передается этот идентификатор. Формат файла наполнения для каждого типа службы свой, например, для базы данных PostgreSQL файл должен быть в формате tar, совместимом с используемым в утилите pgdump.
Миграция осуществляется в три этапа.
• Миграция пользователя. На целевой системе создается пользо ттель с тако й же (насколько это возможно с учетом различий систем) информацией о нем.
• Миграция подписки. На целевой системе для соответствующего пользователя создается новая подписка, выделяются и настраиваются ресурсы с тем, чтобы наиболее полно соответствовать ситуации на исходной системе. Например, создаются домены, базы данных, пользователи БД, пользователи электронной почты, сайты, настраивается DNS.
• Миграция наполнения подписки. На этом этапе с исходной системы последовательно копируются файлы с наполнением, из которых затем соответствующим образом восстанавливается наполнение служб.
Предварительным является этап сбора информации о платформе, в результате которой менеджер миграции получает от агента документ, описывающий платформу в целом.
Реализация
Разработанная схема была реализована в модуле Migration Manager системы автоматизации хостинга Parallels Operations Automation.
Серверная часть системы написана на языке C++ и представляет собой подключаемый модуль системы Parallels Operation Automation. Реализована балансировка нагрузки на исходную систему и на каждый сервер целевой системы (задачи выстраиваются в несколько очередей). Взаимодействие с UNIX-агентами производится посредством протокола SSH, агент представляет из себя произвольное приложение, чаще всего это сценарий интерпретируемого языка. Windows-агенты реализуются в виде сборок (assembly) .NET, взаимодействие производится как с веб-сервисом через протокол HTTP с использованием промежуточного элемента - Migration Framework - библиотеки, упрощающей сбор информации о платформе. Для валидации сообщений агента используются XSD-схемы.
Migration Manager предоставляет возможность задать XSL-трансформацию для всех трех типов документов, получаемых от агентов. Таким образом, можно не просто переносить существующий хостинг на новую платформу, но при желании вносить изменения в копируемую информацию (рис. 2).
Рис. 2. Схема работы миграционного модуля
Система была успешно использована для миграции с ряда распространенных систем управления хостингом и нескольких изготовленных на заказ.
Описание работы программной реализации
Перед началом работы в системе должен быть зарегистрирован как минимум один агент, который будет использоваться для миграции.
После регистрации агента необходимо зарегистрировать платформу-источник. При регистрации выбирается агент, указываются адрес сервера и дополнительные настройки, зависящие от ОС. Для использования Linux-агента указываются порт для подключения и имя пользователя для аутентификации. На сервере исходной системы предварительно должна быть настроена аутентификация по ключу для этого пользователя. Для Windows-агента дополнительных параметров нет, но на сервер исходной системы, используемый для установки агента, должен быть поставлен Migration Framework. При регистрации платформы происходит начальный сбор информации о платформе, после чего в Migration Manager^ появляется список пользователей, подписок и (необязательно) доменов исходной системы. С этого момента можно мигрировать пользователя со всеми или некоторыми подписками.
Для миграции пользователя(ей) необходимо выделить его и нажать кнопку Migrate. После этого Migration Manager запрашивает у агента информацию о данном пользователе, если она не была получена ранее (но не слишком давно). После получения этой информации в системе создается новый пользователь, принадлежащий соответствующему посреднику, с использованием полученных данных. Далее начинается миграция подписок пользователя (тех, что выбраны для миграции; по умолчанию выбраны все подписки).
При миграции подписки Migration Manager запрашивает информацию о подписке у агента. После получения этих данных в системе создается новая подписка, принадлежащая соответствующему пользователю. Далее происходит конфигурация хостинговых служб в соответствии с информацией, полученной от агента. Все ссылки на наполнение служб на данном этапе сохраняются в базе данных для того, чтобы быть востановленными позже. В случае успешной конфигурации служб начинается восстановление наполнения.
На этапе восстановления наполнения Migration Manager получает список ссылок на наполнение различных служб, ранее сохраненный в БД. Для каждой ссылки осуществляется два вызова агента - первый, диктующий агенту упаковать наполнение в файл, второй -для того, чтобы скачать полученный файл. Далее этот файл копируется на нужный сервер, после чего информация, сохраненная в нем, распаковывается. При возникновении ошибки на каком-либо из шагов процесс перезапускается с того этапа, на котором возникла ошибка.
При желании можно выбрать для миграции отдельную подписку. При этом сначала будет перенесен соответствующий пользователь, а затем выбранная подписка.
Материал поступил в редколлегию 24.03.2009
D. V Kadashev
HOSTING SERVICES MIGRATION MODULE IN PARALLELS OPERATIONS AUTOMATION
Analysis of requirements for hosting services migration system used to migrate services between different hosing automation platforms . Contemplation of different common hosting services migration tools applicability is given. Described implementation of Parallels Operations Automation migration module.
Keywords: hosting, hosting service, hosting automation, migration.
