Половина не случившегося пожара: как мы переезжали в новый ЦОД

Два переезда равноценны одному пожару.
(Народная мудрость)

Вместо предисловия

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

— Доктор! По сути, мы с вами занимаемся одним и тем же: я вынимаю «сердца» автомобилей, вытаскиваю из них клапаны, ставлю новые. А могу и весь двигатель заменить. Так или иначе, после моей работы автомобиль продолжает жить с новым «сердцем». Но вы гребете деньги лопатой, а я за свою работу получаю копейки. Почему так?!

На что доктор резонно заметил:

— А вы, уважаемый, попробуйте сделать капитальный ремонт работающего двигателя!

Растем мы быстро, и нам постоянно необходимы новые мощности для размещения нашего оборудования. При этом рост наших объемов ни в коем случае не должен обернуться снижением качества оказываемых нами услуг. Это стратегическая задача.

Лето — время отпусков, наиболее «спокойный» период для большинства вебмастеров: внеочередная плановая «перезагрузка» сервера воспринимается более спокойно.

Мы дождались лета — и переехали в свой новый ЦОД!

Задача

Казалось бы, о чем тут можно рассказать? Ведь на первый взгляд, в переезде нет ничего хитрого: обладая известной аккуратностью, можно без труда перевезти что угодно и куда угодно — особенно, когда дело касается перевозки коробок с железом, каковыми по своей природе является серверное и сетевое оборудование. На деле же задача перевоза хостинга ^[1] на новую техническую площадку, да еще и в Санкт-Петербурге (это важный момент!), имеет пикантные особенности — в частности, крайне желательно, чтобы в процессе переезда хостинг ^[1] продолжал работать. Таким образом, основной проблемой, которую предстояло решить в процессе переезда, являлась минимизация простоя в оказании услуг. Отталкиваясь от этой цели, выбирались средства.

Планирование переезда осуществлялось исходя из следующих данных:

• Место действия — Санкт-Петербург. Старый и новый ЦОДы находятся на разных берегах реки Невы на расстоянии 12 километров друг от друга. Для справки: летом в ночное время мосты в черте города разводятся.
• Требуется перевезти из старого ЦОДа в новый серверы и прочее оборудование, с помощью которого оказываются услуги виртуального хостинга ^[1] (shared, premium) для нескольких десятков тысяч сайтов, услуги аренды VDS ^[1], выделенные серверы клиентов услуги dedicated.
• Завершение эксплуатации старой технической площадки и начало работы во всю мощь на новом месте было запланировано осуществить в течение трех недель.

Решения

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

Простое, дешевое, топорное

Самое простое решение выглядело бы так:

• Демонтировать все железо.
• Погрузить его в грузовик, привезти на новую техническую площадку.
• Смонтировать его там, запустить и посмотреть, что из этого получится.
• Пока серверы едут с места на место, внести изменение в анонсирование сетей и продолжить работу всех сайтов на новом месте с использованием старых IP-адресов.

Плюсы:

• Получилось бы очень дешево.
• Решение, относительно простое в реализации.
• Получилось бы очень быстро в плане продолжительности процесса всего переезда.
• Не случилось бы необходимости вносить правки в зоны размещаемых на хостинге ^[1] доменов.

Минусы:

• Огромный риск повреждения оборудования (в том числе, всего сразу, а равно без возможности восстановления) в процессе перевозки.
• Существенное время простоя: для демонтажа и монтажа всего оборудования потребовалось бы несколько часов, что абсолютно неприемлемо.

Количественное преобладание плюсов такого сценария переезда не смогло перевесить существенность его минусов, и вариант в работу не приняли.

Трудоемкое, дорогое, изящное

Изящным решением выглядело бы разворачивание на новом месте абсолютно новой технической площадки — новое оборудование в количестве имеющегося в старом ЦОДе, новые сети IP-адресов. После готовности новой площадки можно было бы:

• Вручную перенести каждый сайт со старого сервера на соответствующий новый (скопировать файлы, БД, почту).
• Заранее уменьшив TTL для зон доменов, изменить значения соответствующих записей.
• На время обновления DNS организовать проксирование, чтобы для посетителей, у которых по тем или иным причинам закешировалась информация DNS, сайты открывались и со старых адресов.

Плюсы:

• Малое время простоя в работе сайтов. Для многих переезд произошел бы вовсе незамеченным.

Минусы:

• Чтобы перенести несколько десятков тысяч сайтов, требуется неопределенно большое количество времени работы квалифицированных специалистов. Учитывая необходимость выполнять текущую работу, переезд затянулся бы на месяцы.
• Не все домены размещающихся у нас сайтов делегированы на наши NS-серверы. Для тех, кто самостоятельно поддерживает зоны своих доменов, никакой изящности в данном решении не обнаружилось бы, строго наоборот.
• Время обновления информации DNS невозможно спрогнозировать или как-то на него повлиять — этот процесс не зависит от хостинг-провайдера ^[1] (подробнее см. статью Все о регистрации и переносе доменов ^[2]).
• На нашем хостинге ^[1] размещаются отнюдь не только сайты в привычном понимании этого слова: ряд клиентов использует наши вычислительные мощности для размещения специализированного программного обеспечения, и описанный подход для переноса таких сервисов оказался бы просто не применим.
• Потребовались бы внушительные вложения в приобретение избыточного количества нового оборудования, время для его настройки, затраты на его обслуживание.

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

Жизненное

Проанализировав факторы, обуславливающие продолжительность перерыва в предоставлении услуг, мы разработали решение, которым в глубине души гордимся.

Технические факторы

• Наша компания имеет статус локальной интернет-регистратуры (LIR ^[3]) и эксплуатирует собственное адресное пространство. В этом вопросе мы не зависим от интернет-провайдеров, что существенно помогло нам при переезде. Во избежание необходимости внесения изменений в записи зон доменов размещающихся у нас сайтов мы приняли решение продолжать работать на действующем адресном пространстве. С целью обеспечения возможности его одновременного использования на обеих технических площадках ЦОДы были соединены виртуальной сетью (VLAN ^[4]). В практическом смысле это дало нам возможность выключить сервер на старой технической площадке и включить его на новой без изменения IP-адресов и без необходимости внесения изменений в маршрутизацию.
• Перед перемещением сервера с собственными сервисами компании (биллинг, основной NS-сервер, пр.) была дополнительно проверена работа резервного NS-сервера, который расположен физически вне основной технической площадки.

Организационные факторы

• Перевозка жестких дисков осуществлялась отдельно от самих серверов, в новом ЦОДе они устанавливались в новые серверы: это дало экономию времени на демонтаже и монтаже оборудования и СКС; кроме того, организовать незаметную для внешнего наблюдателя перевозку жестких дисков в ночное время гораздо проще, чем перевозку множества серверов в сборе.
• С целью минимизации вероятности быть остановленными сотрудниками ГИБДД, перевозка дисков осуществлялась в обыкновенном легковом автомобиле, осуществлявшем движение без малейших нарушений ПДД (скоростного режима, пр.).
• Перевозку серверов shared и premium осуществляли в выходные дни по ночам — аккурат после сведения мостов. Время перевозки серверов dedicated предварительно согласовывали с клиентами.

По завершении физического переноса оборудования в новый ЦОД нам оставалось только «погасить» сеть в старом ЦОДе и внести изменения в маршрутизацию наших сетей, что и было успешно сделано. Со стороны перерыва в работе площадки можно было и не заметить. У тех же, кто по техническим причинам все-таки его заметил, видимость площадки «пропала» не более чем на 10 минут.

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

Оргвыводы

Сделать «капитальный ремонт работающего двигателя» у нас, разумеется, не получилось — по объективным причинам изменить физическое положение оборудования без приостановки его работы невозможно. Но мы рады, что сумели не допустить возникновение «половины пожара» — физический переезд оборудования со стороны пользователя виртуального хостинга ^[1] и большинства клиентов услуг аренды VDS ^[1] или dedicated выглядел совсем неотличимо от рядовой штатной перезагрузки сервера, совершаемой, например, для обновления аппаратного или системного программного обеспечения: вместо запланированных двух часов простоя, о которых мы предупреждали клиентов в рассылках, среднее время недоступности сайтов составило 1 час 20 минут.

Автор: Vverxdnom