Перенос дата-центра — сложная задача, где важно обеспечить бесперебойность работы и заранее подготовить оборудование для переезда. Евгений Боровиков, VP of technology, эксперт в сфере управления инфраструктурным проектированием, рассказал о своем самом сложном проекте по переносу дата-центра и поделился экспертизой, которая пригодится техническим тимлидам.
Евгений, расскажите о проекте переноса дата-центра, которым вы руководили. Какие ключевые этапы вы выделили в процессе миграции инфраструктуры?
У меня было несколько таких проектов, но перенос дата-центра из Нью-Йорка в Санкт-Петербург стал одним из самых сложных в моей карьере. Компания, в которой я работал, занималась услугами по предоставлению в аренду телефонных агентов — например, для техподдержки или отделов маркетинга. У нас было несколько собственных колл-центров, и в обязанности инженерной команды входила разработка и поддержание кластеров IP-АТС для входящих и исходящих кампаний наших клиентов.
В тот момент я занимал должность вице-президента по технологиям (VP of technology), отвечая за все процессы переноса дата-центра: юридические аспекты, поиск помещения в Санкт-Петербурге, организация подвоза и монтажа оборудования, заключение договоров с операторами связи. Под моим управлением в общей сложности было до 30 человек.
Переехать мы решили по двум причинам — практически вся техническая команда оказалась из России, а затраты на поддержку дата-центра в США были гораздо выше, чем там. Наша инфраструктура в Нью-Йорке была довольно специфичной и построена во многом на базе mini PC. Ее удаленная эксплуатация с другого континента на объемах в сотни серверов представляла достаточно серьезные трудности для технических специалистов. В связи с этим я решил перенести все ядро инфраструктуры в РФ, параллельно сократив издержки на ее обслуживание.
Если говорить о ключевых этапах, то первоначально следовало найти дата-центр назначения, запрашивая коммерческие предложения у компаний на рынке и разговаривая с проектными менеджерами. Было необходимо, чтобы для нас смогли смонтировать оборудование нестандартного форм-фактора с промышленными импульсными блоками питания и другими не совсем обычными для дата-центров решениями.
Параллельно мы подготавливали оборудование для монтажа: импульсные блоки питания, телескопические стойки с прорезями под кабели питания и сеть, тумблерную панель для удобства эксплуатации.
Для нас, как и для дата-центров, на первом месте стояла беспрерывность предоставления услуг нашим клиентам. Поэтому перед началом работ для итеративного переноса данных клиентов мы закупили буферный объем серверов, который позволил нам начать работы по переезду.
Отдельным этапом можно выделить организацию доставки большого объема оборудования из США в РФ. Было множество нюансов юридического плана, и сложности координации самого процесса. Как следствие, все затянулось на 6 месяцев и было разбито на
Какие основные вызовы и риски возникли при переносе дата-центра на другой континент, и как ваша команда справлялась с ними?
Если коротко, то это несколько вещей, которые я уже частично упоминал: архитектурное решения для монтажа серверного оборудования на базе mini pc, организация доставки в РФ и каналы связи.
Я бы остановился на каналах связи чуть более подробно. Так как по целому ряду причин мы проксировали голосовой трафик через наши кластеры IP-АТС, а наши контрагенты зачастую находились в США с колл-центрами на Филиппинах, удлинение маршрута сказывалось на его качестве. Увеличение количества промежуточных узлов добавляло не просто задержку передачи трафика реального времени, но и нестабильность джиттера, что крайне важно для качества голосовой связи.
Это стандартная проблема, когда вы используете публичные каналы связи через интернет и не тратитесь на аренду выделенных каналов передачи данных с определенным в контракте SLA. Решением было туннелирование голоса через одного из облачных провайдеров, обладающего собственной или арендованной оптикой.
И, конечно, вызовом стала поддержка двух инфраструктур одновременно. Одно дело — работать только в США или в России, и совсем другое — поддерживать геораспределенную инфраструктуру с репликацией данных.
Как перенос дата-центра повлиял на общую производительность и доступность услуг компании?
Надежность систем и качество предоставляемых услуг определенно повысились. С точки зрения электропитания, мы получили резервирование на уровне двух заведенных в каждую стойку фаз, а также кластера импульсных блоков питания. Ранее каждый сервер имел свой выделенный БП малой мощности, что на сотнях серверов приводило к сложностям при выходе из строя. И это были не единичные случаи.
Благодаря наличию в дата-центре множества операторов связи, мы могли достаточно оперативно переключаться между ними и изменять исходящие маршруты в случае необходимости. В арендованной локации в Нью-Йорке такой возможности у нас не было.
Также у нас появилась возможность оперативно масштабироваться на выработанном техническом решении, достаточно легко добавляя в стандартные 19 дюймовые стойки наше оборудование.
Какие системы были использованы для обеспечения бесперебойной работы услуг при переносе производственных серверов?
На самом деле все было достаточно стандартно. Где это возможно, мы реплицировали данные или дублировали наши основные сервисы. Где-то балансировали нагрузку между двумя локациями.
Какие используются стратегии для обеспечения безопасности данных и устойчивости инфраструктуры в таких проектах?
Сам проект не накладывает дополнительных требований к безопасности данных. У вас либо уже внедрены определенные подходы к этому, либо нет. В первую очередь, это зонирование — на уровне сетевой инфраструктуры, политики безопасности для доступа к информационным системам, в том числе к базам данных клиентов, шифрование данных.
Что касается надежности самой системы, то я рекомендую резервировать самые критичные элементы — например, сетевое и серверное оборудование. У нас всегда было несколько резервируемых друг друга маршрутизаторов, буферных кластеров клиентов, на которые мы могли перейти при выходе из строя основных. Таким образом, мы обеспечивали минимальное время простоя.
Какие выводы и уроки вы извлекли из опыта миграции инфраструктуры, которые могли бы быть полезны для других подобных проектов?
Это был интересный проект с точки зрения технической реализации. Ранее никто из нас не встречал аналогичных решений, и с инженерной точки зрения это был определенного рода вызов для нас.
Задачи требовали широкого технического кругозора от инженеров. Плюс наш общий энтузиазм и интерес позволили в достаточно короткие сроки все реализовать.
Также могу сказать, что для каждого проекта желательно максимально декомпозировать цель на первоначальном этапе. Если вы в самом начале сделаете это хорошо, распределите и распараллелите процессы, то уменьшите количество проблем при реализации.
