Как стать автором
Обновить

Тележка, витая пара, три свитча: как я перевозил сервер с нулевым даунтаймом

Системное администрированиеСерверное администрированиеКомпьютерное железоСетевое оборудование
Перевод
Всего голосов 67: ↑65 и ↓2+63
Просмотры41K
Комментарии 91

Комментарии 91

17 тыс., деньги конечно хорошие, но другое интересно. Никакого даунтайма и 1 сервер? Кажется автор стал жертвой какого-то пари.
В русскую рулетку играют

Я не ослышался, два часа сервер висел на упсах? Или упсы во время транспортировки подзаряжались от попадающихся на дороге розеток? PS: амортизатора не хватает в описаниях, не думаю, что сервер ехал неподрессоренным. И ещё не раскрыта тема смены этажей — на лифте подключенный по витой паре сервер переехать не может. А так вполне кулстори.

Ну, два часа для одного сервера — это не так уж и много с нормальным ИБП.

А нормальный ИБП это сколько? 10кВА или больше? Просто по мне сервер жрет от 300 Вт, тем более под нагрузкой, даже если она была меньше обычной, плюс это сервер с жесткими дисками, которые крутятся и тоже жрут, неясно, сколько их было, но похоже, отдельной полки с дисками не было, и то хорошо. Но если у них был 10кВА ИБП — да, наверно, могли и обеспечить бесперебойное питание на все два часа без плясок с силовыми проводами.

Из личного опыта — штук 5 супермикр + штук шесть единиц сетевого железа + АТС живут час на старом комплекте 2U ИБП Smart-UPS RT 5000 XL + 2U Battery Pack к нему. Один сервер без прочего барахла на новом ИБП подобном проживёт прекрасно и больше двух часов.

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

В статье говорится, что упсов было 2. Вместе с сервером тележка уже далеко за 50 кило получается...
А ведь её, судя по всему, тащили по лестницам 2 парня...

Даже представлять эту картину страшно...

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

Хмм... Ну да - в статье не говорится, что это за здания были... Вполне возможно, что и датацентр какой. А там всё на первом этаже находится + есть спец. подъёмники для загрузки крупных грузов с улицы или из грузовиков...

Но тогда непонятно, что это за хостеры такие - в 200 метрах друг от друга? (Конкуренция? Не, не слышали?)

Но тогда непонятно, что это за хостеры такие - в 200 метрах друг от друга? (Конкуренция? Не, не слышали?)

Чем 200 метров мешает конкуренции?

Из киевской практики что я лично видел: ТУМС - 3-4 провайдера в одном здании, периодически то мирились с протягиванием пиринговых шнурков друг к другу, то выключали их; когда погнали с ТУМСа - переехали через стену к биохимикам (оккупировав в итоге два корпуса полностью, куда забегали в гости белые мыши с электродами в голове), создав попутно UA-IX - и там конкуренты просто в соседних стойках могли стоять; новая точка на Гайдара, где 2-3 этажа сдавались в аренду и там тоже сидели вплотную. А сколько было в крупных коло субарендаторов которые выкупали шкафы и размещали кого хотят...

Но тогда непонятно, что это за хостеры такие — в 200 метрах друг от друга? (Конкуренция? Не, не слышали?)

Я так понял, железо стояло просто в арендованном офисе, и переезд был в другой офис.

Там речь про truks и подозреваю это про пикапы авторов.

Когда нам меняли батареи в UPS, выполнявшие это работники сервиса рассказывали, как они тащили на 16й этаж без лифта оборудование базовой станции сотовой связи. При этом больше ~150 кг весь агрегат и ограничения на наклон в процессе. Заняло два рабочих дня. Но там 4 человека работали...

А мне наоборот - довелось спускать с 14ти этажки 2 серверных шкафа телекомуникационного оборудования + 2 UPS'а с 4мя (кажется) блоками доп. батарей. Плюс 2 тонны, порезанных в металлолом, спутниковых тарелок. Благо нас было человек 15... Но все 14 этажей мы бегали туда-сюда на своих двоих (Лифт был сломан)...

На зданиях больше 5 этажей должны быть площадки для крепления лебедки.

Ну в Москве, может, и так, а в мелких городах этим не заморачиваются.
Максимум - есть проржавевший в усмерть кран в лифтовой.

Антенны изначально поднимались краном. Снимать по какой-то причине краном не получилось. Пришлось резать и выносить вручную.

Я вот не понимаю, если протянули витую пару, то что мешает и силовую переноску кинуть, тогди и ИБП нужен только на момент переключения между переносками.

p.s. Но сама идея о том что сервер нельзя выключать, при этом он не стоит на горячем дублировании, кажется мне странной.

UPS на 1000 VA + 4 шт АКБ 60 А/ч вместо штатных.

> на лифте подключенный по витой паре сервер переехать не может

Почему собственно? Берем много кабеля с запасом…
«Осторожно двери закрываются» пережимают кабель и приехали! Так же кабель может просто зацепиться, а скорость лифта скорей всего не контролируется.
а скорость лифта скорей всего не контролируется.

Ммм, скоростной свободно падающий лифт.
Последний раз, когда я видел двери лифта — сегодня утром — на них были резиновые уплотнители. У вас в офисе вместо лифта стоит «стандартная советская разрезалка пополам»?

Вы, наверное, и метро считаете таким медленным телепортом? Зашёл на станцию, вышел из другой.

Примотать к подвеснику в лифте витую пару и вуаля. )

Ну как бы какой-нибудь условный ШВВП для временного питания намного дешевле витухи cat6. Так что никто им не мешал рядом с витой парой проложить и питание — коммутаторы в промежутках же они тоже запитывали от чего-то. А ИБП уже для подстраховки.
На самом деле 2 часа не так уж и запредельно много. На одной из работ был APC 5000 c тремя внешними блоками аккумуляторов. Так эта конструкция 2 сервера держала больше 4 часов.
Правда такая конструкция не сильно мобильная. Каждый внешний блок весил что-то около 80 кг + сам бесперебойник не сильно легче.
варианты(веселые):
1. сервер был на АРМ и жрал мало.
2. пацаны приехали на тесле и подпитывались от нее.
3. УПСы были с дополнительными модулями батарей и они менялись.
Наверное давно клиенту стоило подумать о втором сервере в другом месте. По крайней мере задуматься об этом звоночке.
Что очень смущает — это проблемы с миграцией на 2012r2. Даунтайм там несколько секунд максимум, во время самого момента переключения. Автор, может, путал Live Migration и Quick Migration?

Даже если так, 30 тыс. запросов за 4.5 часа (судя по счёту) — это почти 2 запроса в секунду. Достаточно, чтоб заметить downtime и развоняться.

Смотря сколько это "несколько" секунд. Если меньше периода TCP connection timeout, могут заметить только лаг, а лаг это не даунтайм.

Такой даунтайм не вызовет таймаута для большинства соединений — пользователи этого даже не заметят (кроме каких-нибудь RDP или стримов видеопотока).

Не будет там даунтайма вовсе по идее, небольшая задержка только если. Там вроде даже tcp сессии остаются висеть при live migration (ну или vMotion у вмвари).

Это был сервер Hyper-V с 2012r2. И я, и мой друг имели дело с Hyper-V начиная с 2003 года, и множество раз предпринимали попытки Live Migrations.

ох неправда... он появился в 2008, до этого был Virtual Server если не ошибаюсь, без hardware virtualization. С live migration проблем не видел, уж на 2012 R2 она точно работает.

Опыт - говорит обратное - M$ как не странно тоже не дают гарантий на Без перебойную миграцию.....

Опыт говорит, что всё работает. А гарантию даёт только росгосстрах (с)
ХЗ — я не видел в Живую реально Больших(более 100 хостов) внедрений на Hyper-V.
пока не увижу в живую и не поговорю под Джека с Админом(Если что Джек с меня) кто это обслуживает не поверю что Это возможно заставить работать стабильно — личный опыт 25 Хостов На Hyper-V и как результат 3 месяцев геммороя, суточные простои разваливающиеся без причины кластера и разбирательств с участием вендора — Переезд на vSphere и идеальную Работу уже пару лет с минимальным участием.

Vmware тоже имеет свои приколы и ограничения. Особенно если еще VSAN там поднимать. И иногда узнаешь о таких приколах постфактум, когда пытаешь понять - почему по логике оно должно работать, а не работает(например миграция виртуалок - выключенная виртуалка мигрирует через Managment интерфейс, а включенная через vMotion) . С другой стороны, пока такие внезапные приколы не всплывают, после настройки и тюнинга кластера - все просто работает. А с настроенным HA, DRS и общим хранилищем(хранилка либо vsan) - даже внезапно вышедшие из строя сервера не заставляют напрягаться.

В свое время был выбор - либо переходить на vmware 6, либо переходить на hyper-v кластер. В общем после обучения на MS SCVMM, решили остаться на vmware.

Да есть тонкости как и везде(и в XEN и в KVM и в Nitro)

С варей проще - всё что ты можешь словить почти всегда упирается в Железо - а Всякие исключения в кривизну конфигурации.... Ну и ЛОГи в Отличии от винды ОНИ есть они понятные, простые и ПОЛНЫЕ!!!!

Если есть траблы миграция просто не происходит на конечном этапе обычно и старая машинка на старом хосте продолжает работать.

ну-ну, а повесившийся входящий хост Hyper-V не хотите? а машина Которая зависла в статусе миграция и Жрет все больше и больше памяти? или Когда внезапно оборвалась Связь на последних 3-х процентах и Машина Не работает ни там, ни там?
и это только Сюрпризы которые наблюдал Лично…
Солидарность. Если миграция на какой то платформе не отработана регулярной и актуальной практикой, то запускать её было бы, в данном случае, риском ценой в 17 т. у.е. :)

Ни разу такой дичи не встречал. У меня были скорее другие приколы когда live migration переставала работать в принципе, когда хост мог выключать машинки, но не включать и резкий полом служб hyper-v без возможности как-либо запустить. Но именно при самой миграции (при зависаниях и потерях связи) именно этого не было. Были другие косяки, но машинки продолжали работать. С другой стороны у меня репрезентативность небольшая, хостов всего 5 стэндэлон со 100+ вм. С хостами вмвари такого не случилось, но там для нормальной работы без дебильных ограничений желательно покупать максимальную лицензию сферы, что дорого. Хотя тут как не смотри получится дорого, если есть необходимость сделать хорошо.

если разбирать то там Дичи всякой - HyperV вобще кладбище Админских нервов, а уж как красиво ведутся руководители что "оно же бесплатное...."

с VMWare тоже можно хватануть если делать не по уму и не подумав....

Ну как бесплатное... Особенно весело из павершела настраивать вланы на виртуальных роутерах когда у тебя много вланов. А есть люди, которые придут в hyper-v manager не найдут как там транки настраивать и уйдут говоря "низзя", это же windows-way. Командлеты ломаются и плохо везде описаны.
Для нормальной работы (не standalone) там по хорошему нужен scvmm и везде редакции datacenter, свитчи 10 гбит (там и к винтам есть ещё требования) или полка. Вмваря тоже есть "бесплатная" (хотя бы дали фичи которые hyper-v даёт), да и всякие проксмокс есть.

для VMWare "на дне" есть vSphere essentials plus - и не дорого и вполне полно функционально.

А всё что больше это уже да.... хотя в масштабах SMB я даже не представляю задач когда Нужно что большее чем vSphere essentials plus - я про реально нужные для бизнеса задачи, а не всякие "хотелки админа на пощупать"

В essentials plus нет distributed switch. Без него настройка транков тоже становится проблематичной.

Заказчик в состоянии заплатить 17 тысяч долларов за перемещение сервера, но не хочет делать конфигурацию с несколькими серверами. Я бы от такого сбежал сразу.

да хз, 17 тысяч не лишние же )

Ну тут же посчитать надо сколько будет стоить простой в случае поломки, а она рано или поздно будет.

ну так это уже проблемы клиента, а не подрядчика

Перевозили процессинговый центр в другой ЦОД без простоя, никаких размотанных по улице кабелей, тупо растянули кластер vSphere на 2 ЦОД и перетягивали виртуалки по одной + свитчовер БД.

Мы еще виртуальные микротики подняли, через которые L2 между цодами прокинули. Чтобы после миграции спокойно уже ночью адресацию поменять

Огурец, как сетевик, нервно вздрагивает при упоминании растянутых между датацентрами l2.

Все упирается в задержку. А 3-ное инкапсулирование (eoip,gre,ipsec) вполне себе неплохо работает. Да, падает полоса пропускания примерно в 2 раза, но все работает. Хотя у нас некоторое время жил вариант еще на vpls/mpls.В принципе тот же Vmware NSX умеет делать L2 между всеми DC, правда умный вариант. Обычно от L2 между цодами вздрагивают цисководы.

Дело не в задержке полосе, а в том, что L2 домены в принципе нужно стараться делать настолько маленькими, насколько получается. Как в плане количества хостов, так и в географическом. Куда как изящнее выглядит, например, схема с виртуалкой, получающей на сетевой интерфейс по dhcp адрес из какой-то /30 подсети и анонсирующей через какой-нибудь протокол динамической маршрутизации наверх свои "главные" ip, которые повешены в виде /32 на лупбэки внутри виртуалки. Никаких растянутых на кучу железа l2 доменов, возможность тягать машину куда угодно. Или в какой-нибудь vxlan прямо на гипервизоре заворачивать если уж так нужно именно l2 подтягивать. Но не вланы поверх L2 туннелей, я умоляю.

Тут были на один влан - один туннель. Если у вас софт не работает на бродкасте (был у меня такой в прошлой конторе, он нам ядро сети положил), и вам не нужен promission mode, то разницы между L2 и L3 нету, при достаточно умном построителе туннелей. Если он будет подавать трафик только между конкретными MAC адресами между конкретными туннелями, а не спамить на всех. Мы тогда мигрировали внутренние сервисы, нам такое решение было приемлемо, а время внедрения заняло минут 10.

Я видел схему на L3 из примерно того как вы описываете (плюс между коммутаторами была L3 маршрутизация) и мы ее в итоге похоронили при замене железа. Поддерживать ее было дико неудобно.

Ну как сказать "неудобно"? Правильно организовать - и вот у вас уже любой хост может переезжать на любой гипервизор и анонсировать себя всей сети при помощи самых обычных протоколов маршрутизации. Бонусом из коробки получаем возможность anycast балансировки, полную невозможность положить сеть l2 штормом и ещё ряд приятных мелочей.

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

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

можете детальнее расписать что вы имеете в виду?

вроде на башорге была история, как похожим обрахом перемещали сервер с нулевым даунтаймом внутри помещения бегом на тележке под писк УПСов и расставленных по пути движения WiFi Ad-hoc точками доступа.

Я такое ноу-хау в году 2011 видел. Значит работал на монтаже интернет провайдера, захожу проблему у человека поправить. А он мне проходите на кухню, думаю видать ноутбук сейчас принесет. Был удивлен когда на самопальной тумбочке на колесиках вкатился ПК с монитором еще лучевым. Вот только у человека УПСа не было, он старый корпус пылесоса приспособил под самосматывающийся удлинитель, сразу под 220 и витуху.

В древние времена делал разок также. Правда без вайфая - просто 30 метровый ethernet кабель

Общая сумма составила чуть меньше 17 тысяч долларов

Есть подозрение, что просто купить новый сервер, установить его на новом месте, и спокойно мигрировать туда виртуалки возможно было бы дешевле, или как минимум не сильно дороже.

Ну вот. Ужо и на хабре появились вечора ахренительных историй

Вспоминается старое видео из 2010 года, как какие-то ребята перевозили сервер в другой дата-центр без остановки. 3 километра, в метро и под дождём.
https://youtu.be/vQ5MA685ApE

Огонь

Ох, с метро конечно любопытно, но неужели не проще было найти авто и медленно доехать? В метро ещё 3G, наверное, лагал постоянно, т.е. сервер так себе онлайн был в это время.

Вот ты сидишь, котиков в интернете рассматриваешь и даже не догадываешься, откуда они к тебе прилетели ;)

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

ps. Есть вероятность, что без выключения виртуалок они бы всё равно не смогли использовать живую миграцию (если бы пытались) без включенных "Migrate to a physical computer with a different processor version" в опциях cpu, которая по умолчанию отключена в этой версии винды.

Судя по всему они просто не освоили кластер 2012r2. С другой стороны хорошо развели заказчика на деньги.

Сервер был весь на SSD или можно ожидать что через пару дней после переезда диски начали сыпаться?

Знаю что автор меня не прочитает, но хочется спросить, чем питались промежуточные коммутаторы? Cat6 поддерживает максимальную длинну 100м, а кабеля было 300м — тогда почему коммутаторов было 3 а не 2? В общем, было очень интересно, но не получается разобраться досконально.
150м даже Cat5e удержит более-менее. так что думаю 150 там и было.

От пикапов: We plugged the switches into our trucks in the parking lot and connected them with the cat6.

По-моему, это самая невероятная часть истории. Слишком уж удачно расположились эти тачки на пути переезда. Намного проще было купить две 100м бухты самого дешёвого силового кабеля, реально самого дешёвого, и запитать один коммутатор от серверной-донора, а другой — от серверной-акцептора. Ещё не понятно почему бухт сетевого кабеля было 3, а не 4: один кабель максимальной длинны из одной серверной, другой из другой серверной, и ещё два от каждой из двух сетевых карт сервера. Расходов не намного больше, зато коммутация значительно упрощается. Чем занимался третий коммутатор мне не понятно до сих пор. Как бы там ни было, а на месте автора я бы продал сценарий этой истории в Голливуд.

Новая сказка братьев Гримм. 1) 7 виртуальных ОС, хостинг судя по рассказу, плюс файлопомойка, номинал БП 700-1000 Вт (2а проца/256 ГБ ОЗУ, 12 винтов шасси), вес плюс минус 35 КГ, потребляемая мощность 400-500 Вт, пороговое значение температур....в общем, рассказчику хорошего отдыха и кармы

2) Стоимость, 17 т. гринов ~1 млн рублей, безусловно у каждого свои расценки. Круто заработали.

3) Не верю

Круто заработали. Потому как нельзя грубить своему айтишнику. Тройная ставка - именно за смену специалиста.

1) 17К зелени за отсутствие 5-10 минутного даунтайма? Сервер "майнит" золото килограммами? Даже для среднего ентрепрайса даунтайм так дорого не стОит. Автор явно чего-то не договаривает.

2) Я не знаю как рентеру с лэнд-лордом надо было разоср поссориться, чтобы он не дал 1-2 экстра ночей на нормальный переезд серверной.

3) HDD вместо SSD. Хард: Трясёт? Автор: Да не, тебе кажется. Хард: Ой, бэдблок кажись.

Я тут мимо проходил, но
1) 17К зелени за отсутствие 5-10 минутного даунтайма? Сервер «майнит» золото килограммами? Даже для среднего ентрепрайса даунтайм так дорого не стОит. Автор явно чего-то не договаривает

Например, люди поступили неумно и в контракте понта ради вписали что-нибудь типа «круглосуточного доступа» без конкретного процента доступности, и теперь им дешевле отдать 17к, чем рисковать судами с заказчиками, за которые адвокаты сдерут еще больше. А были бы умные — развернули бы два сервака и отмигрировали как нормальные люди

2) Я не знаю как рентеру с лэнд-лордом надо было разоср поссориться, чтобы он не дал 1-2 экстра ночей на нормальный переезд серверной.

Может и дал, но см п.1

Если предполагать такой вариант, то получается они вообще ниче не понимают в отказоустойчивасти, если не смогли договориться с клиентами о плановой остановке работы на 2 мин под миграцию. А что бы они делали если бы на серваке рейдконтроллеру или материнке внезапно поплохело - там подъем занимает гораздо больше чем дауе при миграции.

Вот тоже первоначально удивило: 7 виртуалок 500/6700 уников/запросов в час с закосом на бесперебойную работу и рядом нет второй горячей железки готовой в любой момент взять все на себя, а все держится чисто на бэкапах. И при этом не жалко 17к$ на плановый переезд, если даже он и срочный, то всеравно за 2 дня можно было со статистики поднять время минимальной нагрузки и в этот момент провести миграцию с минутным дауном, в 2 часа ночи, даже выкатив предупреждение пользователям.

В 2005 «переносил» один тестовый сервер. Не важный, но аптайм >1000 дней! Жалко. Один одмин нес сервер, а второй ups… На середине пути из БП выпал провод. Жаль.

Отключив cat6 сервера


Я бы перевёл как Ethernet
мы договорились о плате, который позволит
ху из мистер плата?

И я, и мой друг имели дело с Hyper-V начиная с 2003 года
ух ты!
Спасибо, исправил.
Автор — ***дунский ящик)))
Перед тем, как сочинять такую историю, надо было хоть детали проработать, чтобы так не палиться)
Чуть ли не на баше мне попадалась похожая история, но там переезд был внутри одного здания по очень длинному коридору и сеть обеспечили развешивание нескольких вайфаев по маршруту.

Он-бы еще в другой город потребовал перевозку с нулевым даунтаймом...

Было-бы весело: два инженегра на тележке вдоль трассы толкают сервер, перетыкая удлинители... ;)

И взяли б они $170к

Надо было хоть фото на память сделать, нам показать )))
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.