Как мы строили свой мини ЦОД. Часть 3 — Переезд
В продолжение Части 1 — Colocation
В продолжение Части 2 — Гермозона
Здравствуйте! Судя по отзывам, письмам и комментариям к прошлым двум частям нашей статьи — Вам понравилось, а это главное. Напоминаю, постройкой собственного мини-ЦОДа мы обязаны именно «жителям» Хабра, именно Вы помогли нам с реализацией наших идей — своими статьями. Поэтому данный цикл статей благодарность пользователям и комментаторам, из идей которых мы и «черпали» вдохновение.
Сразу хочу сказать. Мы не претендуем на сертификацию по классу TIER (мы попросту не можем), мы не говорим что сделали нечто новое или идеальное, мы повествуем лишь о том, что у нас получилось, за короткий срок в менее чем 14 дней с нашими потребностями и возможностями. Отнеситесь к данной статье как к «наглядной пище для мозгов», это не идеал, это лишь опыт одного проекта, который возможно поможет Вам избежать ошибок в своем бизнесе. У нас их было допущено не мало.
Итак, начнем. У нас оставалось буквально пару дней до физического переезда всего оборудования, в нашем мини дата-центре было готово практически все, кроме основного — интернет-каналов. Мы спешно договорились о подключении двух независимых провайдеров, но как мы и писали раньше — они ставили нереальные для нас сроки, вплоть до 6 месяцев. Так вышло что мы выбрали место дислокации рядом с группой провайдеров и усложняло протяжку лишь согласование с владельцами колодцев/опор.
Поговорив с техническим директором первого провайдера, мы все-же убедили его сделать «быстро» и подать линк в кратчайшие сроки. Бригада выехала и буквально на следующий день подписания договора протянула нам оптику (тянуть им было, к слову, метров 100). Весь процесс фотографировать я не мог, ездил между дата-центами, решал сопутствующие вопросы.
Второй же провайдер имел центральный офис в Киеве и это связывало нас по рукам и ногам. Извините за подробности, но они без центрального офиса даже «чихнуть» не могут, не то что протянуть кабель. Нам был озвучен окончательный срок в 11 месяцев и мы окончательно оцепенели. Поговорив с провайдером, менеджер подсказал выход из ситуации. А именно — подрядчики. Они могут протянуть быстро и качественно без дополнительных бумаг (т.к. у них разрешения уже есть). Связались с ними.
В отличии от первого провайдера (канализация), они предложили протянуть по «воздушке». В целом — нам все равно, это резервный канал и мы на него особо не рассчитывали, но все-же его отсутствие не давало нам возможности старта, т.к. все должно быть «по уму». Заплатили, договорились — пошла работа. Сначала предлагали тянуть через дома, потом через столбы, потом через то и другое, в итоге из-за создания ОСМД вынужденны были делать только через столбы (на крыши не попасть и не согласовать), по кронам деревьев, прыгая с ветки на ветку. Действительно, эту протяжку нужно было видеть, ребята рисковали жизнью буквально каждую секунду, прокидывая кабель через дерево, залезая на него без страховок и прыгая при этом на соседнее. Нужно отдать должное, ребята — профессионалы.
И вот казалось бы все, оптика проложена, по первому провайдеру есть линк, по второму они еще утверждают и ждут людей на «базовую станцию» чтобы включиться там, заявили что это вопрос 1–2 дней. Мы в целом довольны и думаем о переезде.
День переезда
Наверное самое сложно для нас — это было продумать как с минимальным даунтаймом переехать. Так вышло что переезжали мы в пятницу. Одна из самых сложных вещей это поднять BGP тунель. Постараюсь пояснить что это такое на пальцах. BGP — Border Gateway Protocol, протокол по которому один провайдер со своей AS (автономной сети) обменивается информацией с другим провайдером и с его AS (автономной сетью). Грубо говоря это стык, который позволяет передавать трафик от одного провайдера другому и так по цепочке.
Сложность в данной ситуации возникла в том, что у нас на тот момент была одна AS на которую были привязаны наши IP. Чтобы сменить данные с одного провайдера на другого — нужно для начала перенастроить основной маршрутизатор (нашу Cisco), а потом еще и внести изменения в RIPE и у провайдера. Таким образом сделать это до переезда — нельзя, сляжет все. А делать во время — есть риски большого даунтайма. Исходя из того, что мы переезжали планово — мы предупредили всех пользователей заранее рассылкой, в твиттере и на форумах. Поэтому мы решили менять настройки уже после переезда. Но об этом немного позднее.
Итак, мы начали отключать оборудование. Вытаскиваем железки.
Протираем от пыли.
Учитывая что заезжали мы туда с тремя серверами и добавляли их понемногу (нося на руках на 5–6 этаж) — мы не знали на сколько не просто будет это все отключать и носить, т.к. серверов на момент переезда уже было 14 штук, плюс IP-KVM IBM. Но благо мы прихватили с собой ребят в помощь и еще одну машинку (т.к. в мой легковой автомобиль все бы не влезло).
Несколько раз побегав между этажами, мы поняли что на руках мы это все не спустим, и попросили включить грузовой лифт (чтобы его включить нужно искать владельца здания, брать ключи, договариваться и т.п.), в общем это был как раз тот случай когда это было нужно. Спасибо за это ребятам.
Хлама накопилось не мало, 14 серверов, 1 клиентский, PDU розетки, диски и прочее барахлишко для укладки СКС. Грузимся и в путь.
Ехать не так далеко, около 5–8 КМ, поэтому едем не спеша, аккуратно. В нашем новом мини-цоде нас уже ждут коллеги для разгрузки и подключения. Приехали, разгрузили железо на стол.
Начали заниматься установкой сетевого оборудования, его подключением, протяжкой и укладкой кабелей. Для этого дела так-же прикупили хомутики. С ними очень удобно.
Монтируем APC PDU (благо одну именно управляемую мы уже прикупили).
Начинаем наполнять шкаф.
Вставили железки, циску, пока тестово кинули кабель только к циске.
Приступили к настройке циски. Это были еще те извращения.Монитор на полу, системник на стуле, все в «подвешенном» состоянии. Да, бывает и такое:)
Пока настраивали циску, начали перепись оборудования, портов Cisco и портов APC PDU. Это очень важный момент, нам это потом помогло не раз.
Уже вечерело, часа 4, может половина пятого… казалось бы основная работа сделана…, но если бы мы знали как ошибались… Приступили к поднятию BGP туннеля (заранее получили настройки) —, а фиг… Линк есть, а работать он не хочет. Проблема выявилась быстро и получилась из-за нашей неопытности. Нам подключили гигабитный линк через оптоволокно. Наша Cisco поддерживает 2×10GB. Мы смело вставили оптику в неё (собственно это мой косяк, не посоветовался с админами нашими, они еще долго меня ругали) — и ничего. Оказалось что если порт гигабитный, а модуль у нас 10 гигабитный он работать не будет. Начали срочно вызванивать провайдера, с просьбами о помощи, как и что делать…, но тут оказалось что все ушли домой (пятница, перед 3-мя выходными и праздником)… и мы стали в ступор.
Был вариант подключить все через медиаконвертер (как мы и сделали в перспективе), входит оптика — выходит витая пара, но его у нас не было, а магазины были все закрыты, и работать начнут лишь через 3 дня. Пришлось через знакомых вызванивать тех. директора компании, срывать его сотрудника из дому, чтобы он в офисе взял модуль 10G для их узла и подключил. И только тогда, наша циска начала воспринимать линк адекватно и все заработало (стык).
Мы закончили все работы и стали ждать… когда обновятся записи, маршруты и все заработает. Уже было 8 вечера, все уставшие, одному парню даже скорую вызывали, один из наших поцарапал руку, а другой из ребят которых мы позвали на помощь в качестве физ. силы — плюхнулся от вида крови носом об порог и рассек себе подбородок.
Примерно в 3–4 часа ночи у нас потихоньку начал подниматься трафик. Все заработало, мы бегали и устраняли неполадки «на ходу». Но IPv6 так и не заработал. Ни утром, ни через день… При общении с провайдером, выяснилось что менеджер заключил договор (в том числе на IPv6) не зная что провайдер физически не имеет IPv6 сетей, и тем более возможности их маршрутизировать. Это был коллапс. Но благодаря опять-же связи с тех. директором провайдера, он нашел способ как «прокинуть» трафик мимо них через соседнего провайдера с IPv6 и у нас все заработало, правда было уже немного поздно, часть клиентов нас покинула.
По завершению всех работ наш дата-центр выглядил примерно вот так:
На этом и закончился наш переезд. Как видите, было много мелочей о которых мы не подумали сразу, совершили много ошибок за которые в последствии и заплатили. Мы искренне надеемся что данная статья поможет избежать наших ошибок — другим людям которые попытают счастье в подобном деле.
Ну и как всегда, есть один приятный бонус. Мы планируем написать отдельную статью по финансовой части нашего проекта (возможно без конкретных цифр, но в сравнительном анализе будет понятно). Из неё Вы поймете что рентабельно, что нет, на чем можно сэкономить и многое другое.
Мы также будем продолжать публиковать статьи на Хабре о работе нашего мини дата-центра, о сложностях которые возникают и о наших нововведениях. В одной из ближайших статей Вы увидите как мы подбирали «самосборное» оборудование для специфических целей и что в итоге выбрали. Спасибо за внимание!
Комментарии (3)
vel
17 октября 2016 в 18:01
0↑
↓
Почему у серверов используется только один блок питания из двух?17 октября 2016 в 18:02
0↑
↓
На данном этапе мы не предоставляем SLA и в случае выхода из строя одного — переключаем во второй в ручном режиме. В планах на пару месяцев задействовать и резервные тоже, но пока только в планах.
Zagrebelion
17 октября 2016 в 19:53
0↑
↓
Переезд — это круто, можно с нуля сделать что-то по-другому, что на старом месте слишком сложно переделывать.Несколько комментариев:
1. Переезжать в пятницу перед тремя выходными — идея для храбрых сердцем.
2. С ноутбуком гораздо удобнее настраивать коммутаторы/маршрутизаторы.
3. Подпишите, пожалуйста, патчкорды, будет легче определять, где какой конец. А учитывая, как неаккуратно обжата витая пара на нечётных и на 46–47–48 портах коммутатора (остальные порты плохо видно), то вероятность замены патчкорда велика.
