Транснациональная миграция

размещено в: Новости компании | 0

00_new_06Если раньше для обеспечения сохранности данных многие компании стремились вынести свои данные, приложения и инфраструктуру в зарубежные ЦОД, то теперь, в соответствии с требованиями ФЗ-242, многим приходится — или предстоит — возвращать их обратно. С технической точки зрения такая процедура сопряжена с рядом сложностей из-за необходимости обеспечить непрерывность предоставления сервисов в период миграции. Дополнительные трудности возникают, если параллельно с миграцией осуществляется переход с одной вычислительной платформы на другую. Не имея опыта, компании лучше обратиться к услугам провайдера, у которого накоплен необходимый опыт по трансграничной миграции данных, например, такого, как IBS DataFort. О выгодах и преимуществах переноса инфраструктуры в виртуальную среду в ЦОД провайдера рассказывает Левон Дадаян, технический директор IBS DataFort

 

Журнал сетевых решений/LAN: Какие причины побуждают переносить данные обратно в Россию? 

Как вы, наверное, знаете, с 1 сентября 2015 года вступает в силу закон, обязывающий все компании хранить персональные данные граждан на территории Российской Федерации. Соответственно, те, кого это касается, пытаются перевести свою инфраструктуру на территорию нашей страны. Другая частая причина — организационные изменения. Например, у некоторых предприятий часть активов принадлежит иностранным акционерам, часть — российским, и когда происходит раздел бизнеса, осуществляется миграция в Россию. Есть и третья – стоимости услуг зарубежных провайдеров и ЦОД рассчитываются, к сожалению, не в российских рублях.

LAN: Какие сложности подстерегают при транснациональной миграции данных? 

Проблем несколько. Первая, самая трудная задача — обеспечить непрерывность предоставления сервиса на период миграции. Выполнить это условие без наличия соответствующего опыта очень сложно. Необходимо четко понимать, какие сервисы надо продублировать, что перенести в первую очередь, а что во вторую, как составить план перехода и насколько долгим окажется возможный простой. Все перечисленные нюансы необходимо учитывать и согласовывать, и если компания еще не сталкивалась с этой проблемой, то любая самодеятельность будет чревата отсутствием доступа к сервисам на весь срок миграции.

Вторая, не менее важная, задача — обеспечить полноту переноса (целостность) всех сервисов, которые были доступны клиенту в зарубежном ЦОД, на российскую инфраструктуру. Самый простой пример: у крупной материнской компании есть своя система Active Directory, а мигрирующая дочерняя представлена в ней как одна организационная единица (Organizational Unit, OU). Соответственно, в новой инфраструктуре надо создать новую систему каталогов и все ранее поддерживаемые сервисы переназначить соответствующим образом, чтоб они остались доступны пользователям. Эта проблема особенно актуальна при разделении предприятия, когда приходится заботиться о том, чтобы не потерять сервисы при отделении и последующей их миграции.

Третья возможная проблема возникает при гетерогенной миграции.  Зачастую оборудование  изначально установлено на одной аппаратной платформе, а клиент хочет при миграции перейти на другую платформу, например с RISC на x86. Такая гетерогенная миграция сопряжена с рядом сложностей — в частности, необходимы преобразование данных и их адаптация для новой платформы или новой системы.

Вот три наиболее серьезные проблемы, возникающие при миграции.

LAN: Какая стратегия, на ваш взгляд, является оптимальной при осуществлении миграции? Какой подход предпочтительнее — проектный или сервисный? 

Наша компания занимается профессиональными сервисами и мы считаем, что только сервисный подход к процессу миграции позволяет сделать сам процесс миграции максимально комфортным для клиента — без прерываний бизнес-процессов.

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

LAN: Наверное, для лучшего понимания необходимо рассказать, что представляет собой миграция. Как происходит этот процесс? 

В зависимости от того, какая инфраструктура у заказчика планируется к миграции, физическая или уже виртуализированная, применяются разные сценарии:

В случае с инфраструктурой представляющей собой совокупность физических серверов и сетевых устройств, миграция осуществляется в несколько этапов. Первый этап – виртуализация. С помощью специальных программных средств аппаратная среда заказчика преобразуется в виртуальную. На втором этапе виртуальная среда размещается на облачной платформе компании Датафорт. Далее происходит процесс синхронизации данных между старой и новой инфраструктурами. Затем настраиваются необходимые коммуникации с внешними сервисами. После всех проверок новая инфраструктура становится доступной клиенту.

Если у клиента инфраструктура уже виртуализирована, то один из возможных вариантов миграции это перенос его виртуальных устройств (серверов, коммутаторов и маршрутизаторов) в реальном времени без прерывания сервисов. В этом случае организуется частный канал передачи данных (в тч международный, тн International Privet Line) между старой площадкой клиента и одним из наших ЦОД, где располагается виртуальная платформа. Формируется единый виртуальный кластер, состоящий из двух географически разнесенных ЦОД. В рамках этого кластера посредством стандартных инструментов среды виртуализации происходит перенос виртуальной инфраструктуры. По завершению переноса, как и в вышеописанном случае, проверяются коммуникации с внешними сервисами клиента, и после проверок кластер разрывается, канал между ЦОД и облачной платформой компании Датафорт расформировывается и клиент начинает получать сервисы уже с инфраструктуры находящейся в облаке компании Датафорт.

LAN: Если заказчик захочет поменять платформу  RISC на x86? 

У нас есть достаточно большой опыт гетерогенной миграции, когда возникает необходимость поменять платформу. Например, если база данных размещалась на платформе RISC, то мы можем переместить ее на платформу x86, чтобы клиент мог унифицировать свои сервисы. Платформа x86 более понятна пользователям, к тому же перенос позволяет перейти к однородной среде. Большинство таких примеров у нас связано с опытом по миграции продуктов компании Oracle, платиновым партнером которой мы являемся.

LAN: А если заказчик не хочет менять платформу? 

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

LAN: Чем выгоднее перенос данных в вашу виртуальную среду, а не возвращение их в российский ЦОД или обращение к услугам хостинга? 

Собственный или арендованный ЦОД — это затраты на серверную инфраструктуру, за которой необходимо следить и постоянно поддерживать ее в актуальном состоянии. Если в процессе эксплуатации вдруг появится потребность в наращивании мощностей, без прерывания сервиса это будет сделать проблематично. Помимо этого, надо учитывать расходы на содержание штата специалистов, которые должны обеспечивать функционирование ЦОД. Мы, как сервис-провайдер, берем на себя решение обеих проблем — и масштабирование (sizing), и обслуживание. Наша платформа виртуализации позволяет клиенту самостоятельно в реальном времени наращивать ресурсы: оперативную память, процессор и жесткий диск. Такие возможности мы имеем благодаря партнерству с компанией CISCO Systems. В случае же с реализацией проектного решения в виде аппаратной инфраструктуры в ЦОД такое оперативное расширение невозможно — для этого требуется больше времени, необходимо останавливать работу сервисов и т. п. В нашем случае все делается в горячем режиме.

LAN: Базы данных ранее считались не подходящими для виртуализации приложениями из-за их высоких требований к ресурсам. Насколько с этой точки зрения оправдан перенос базы данных в виртуальную среду? 

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

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

LAN: Какие гарантии получает заказчик? Поможет ли такой перенос выполнить все требования российского законодательства? 

Гарантии обеспечиваются соглашением об уровне сервиса(SLA), которое заключается с клиентом, где прописана наша финансовая ответственность за нарушение качества предоставляемого сервиса. К тому же мы предлагаем клиентам законченный продукт (готовую платформу) соответствующую требованиям ФЗ-152, который также обеспечивается единым SLA. Большинству компаний достаточно третьего или четвертого уровня защищенности. Этим требованиям наша платформа удовлетворяет.

LAN: Сколько времени занимает проект миграции данных? От каких факторов зависит длительность переноса? 

Прежде всего, от объема данных и количества виртуальных машин (серверов). Сам перенос осуществляется достаточно быстро, если пропускная способность канала, по которому данные передаются между старой и новой площадками, достаточна.  Это величина рассчитывается в рамках проработки нами миграции и помогаем нашим клиентам организовывать данный сервис совместно с нашими партнерами-операторами: Вымпелком, Verizon, Level3.

Дольше всего длится процесс планирования: 2-3 месяца. Мы выясняем, что переносить, в каком порядке, какие сервисы клиент хочет заменить на аналоги во время миграции, контрольные точки и т. д. Сама миграция занимает в среднем от одной до трех недель. Аппаратную инфраструктуру из 20 серверов с данными объемом 10 Тбайт можно перенести за неделю.