Это 2 Петабайта бэкапа
У нас 14 дата-центров по всему миру, из которых я занимаюсь обслуживанием десяти. Лет пять назад я думал, что там, за границей, всё блестит, поддержка внимательная и вежливая и ошибается только совсем по мелочам. Мои иллюзии довольно быстро развеялись.
Вот пример. Стоят у нас в стойках серверы, по сути — дисковые полки, предназначенные для «медленных» данных бэкапов. Место на них кончалось. В каждом сервере было по 24 диска и 36 слотов, мы решили добить ещё по 12 HDD. Я отправил тикеты, объяснил, что мы делаем и зачем, добавил, что нужно поставить диски в неподсвеченные слоты.
Через 10 минут мониторинг показал, что у нас выпал диск в первом сервере. «Ничего себе, коллеги жгут», — подумали мы. Наверное, задели или ещё что-то… Но тут почти сразу выпали второй и третий диски. Я начал звонить в немецкий саппорт, и мне ответил коллега из Индии.
К моменту, когда мы успели остановить его коллегу-грека, этот «терминатор» вытащил по 12 дисков из пяти серверов и готовился приступать к шестому. Система делала бешеный ребилд. Когда саппортер понял, что именно пошло не так, они начали вставлять диски обратно в сервера. И немного, совсем чуть-чуть, перепутали порядок. Что тоже сказалось на безумии ребилда. Но, к счастью, благодаря детальным объяснениям удалось предотвратить накатывание бэкапа — это прервало бы сервис на полчаса.
Так я узнал, кто конкретно и как может работать в поддержке. Тут есть и моя ошибка: рассчитывал-то я на привычную поддержку второй линии, понимающую меня в России с полуслова. И не учёл культурных и языковых различий. С тех пор мы пишем крайне детальные пошаговые инструкции в духе:
- Подойти к серверу такому-то.
- Убедиться, что это именно тот сервер, сверив номер такой-то.
- Отсчитать четвёртый диск сверху.
- Найти восьмой диск снизу.
- Если это один и тот же диск, аккуратно его вынуть.
В общем, исходим из того, что любое место, где можно сделать что-то не так или понять что-то не так, будет эксплуатироваться как уязвимость в коде. Коллеги иногда всё же подбрасывают нам новые нетрадиционные видения обычных действий, и мы дополняем типовые формы. На каждую обычную операцию у меня уже есть двухстраничные инструкции. Это очень помогает в работе.
Сент-Луис, США
Наш первый дата-центр расположен в США, в Сент-Луисе. В нем мы размещали облачный бэкап пользователей ещё в самом начале. Учитывая тогдашнюю популярность услуги и общее непонимание того, что бэкап надо не только делать, но ещё и хранить вне дома (Dropbox только год как родился, продвинутые пользователи бэкапы жгли чуть ли не на болванках), про архитектуру и масштабирование мы думали не особо много. Как оказалось, зря. Нагрузка начала расти быстрее, чем мы ожидали, и наш хостер PlusServer AG не смог довозить железо с необходимой скоростью.
Вообще, ЦОДы у нас двух типов: где мы берём в аренду площадь (дают стойки, охлаждение, питание и охрану), либо где мы берём фактически очень большую колокацию (дают секцию машзала, интернет, поддержку). В первых работают наши местные инженеры, во вторых — прямого доступа к железу нет, и работы выполняет команда поддержки дата-центра. В случае с PlusServer AG действует некий промежуточный сценарий, и, в основном, мы пользуемся услугами их инженеров. Сложностей или конфузов с ними не припоминаю. Тьфу-тьфу…
Сейчас сент-луисский ЦОД (наша секция) наполовину неактивен и находится в ожидании миграции — там очень много старого железа, которое используют разве что тестировщики.
Страсбург, Франция
Это второй по возрасту наш дата-центр, и там тоже много уже «взрослого» железа, даже, кажется, была пара i3, которые тестировщики забрали из основной инфраструктуры для «издевательств» во время краш-тестов.
Всё тот же Плюссервер, но общение с поддержкой идёт на удивление тяжело. Иногда им очень сложно что-то объяснить. Как вы уже прочли выше, если нужно что-то объяснить — уходит полчаса на все возможные варианты развития событий. Инструкция меньше чем на 30 пунктов на перезагрузку сервера, скорее всего, будет воспринята неверно.
На тестах 10G-свитча, когда мы просили сконфигурировать сеть на новом сервере, в момент исполнения тикета отвалился от мониторинга весь ЦОД целиком. Оказалось, что человек, настраивавший его, перепутал gateway и IP-сервера — и через один из серверов все остальные пробовали ломиться в сеть.
Токио, Япония
Третий наш дата-центр находится в Токио, сервис-провайдер — Еquinix, интернет-провайдер — Level 3. На самом старте они не могли вдвоём согласовать кросс-коннекты. Нам нужно было тогда получить burstable-канал, то есть линия на 10% от возможной утилизации сейчас, которую мы планировали расширять в 10 раз через два года. В точке же соприкосновения (MMR, Meet-me-Room, точки входа провайдерских каналов в ЦОД) связки не было вообще.
Level 3 сказали, что сделали всё корректно и не планируют что-то переделывать. В итоге полторы недели я сначала выяснял, что именно не так, а потом уговаривал обе компании сделать, как надо, собирая на конференц-коллы представителей разных их подразделений. Каждый сделал правильно и точно, по их убеждениям, и не хотел признавать свою ошибку. Поэтому я просил «пойти нам навстречу и сделать чуть больше». Сделали.
Самое приятное в работе с японской поддержкой — они невероятно исполнительные. Есть у этого и обратная сторона: инструкции нужны почти такие же, как в Страсбурге. Потому что они невероятно педантичны и задают очень-очень много вопросов. Как-то раз они 12 часов (!) ставили контроллеры в один сервер. Если возникает хоть одна ситуация, где есть два варианта ответа, и сотрудник поддержки знает, что на 95% первый вариант правильный, он сделает, как логично. Почти везде. Кроме Японии. В Японии он остановится, подробно опишет дилемму и будет терпеливо ждать вашего ответа. Например, они всегда останавливают процесс, если внутри сервера больше одного свободного слота, спрашивают, в какой именно ставить.
Франкфурт-на-Майне, Германия
Здесь тоже Equinix, полная поддержка с их стороны. ЦОД планировался как маленький вспомогательный в CDN, но перерос в серьёзную площадку. Именно эти парни вытащили нам по 12 дисков из серверов вечером в пятницу.
Чек-лист обращения такой:
- Разбивать инструкции на короткие пункты.
- Общаться односложными предложениями.
- Стараться не создавать возможности для решений «по месту», то есть детально прописывать все варианты.
Тогда всё работает просто отлично. Надо сказать, что других инцидентов после введения таких правил не было.
Хотя нет, была ещё одна история. Заканчивалось место, купили дисков сразу кучу коробок. Но не у местного поставщика (у него так быстро не было), а в Лондоне, и везли со склада из Нидерландов. Машина приехала в этот же день. Приходит письмо от поставщика: мол, мы диски доставили, получатель отказался, везём обратно. Оказалось, что бравые парни из безопасности не нашли непосредственно на коробках, кому эти диски предназначались. И развернули их обратно. С тех пор мы всегда просим корректно подписать коробки, если везём в ЦОДы с полным сервисом.
Кстати, Seagate очень оперативные — они по доброте душевной решили максимально быстро вернуть диски на склад отправителя, потому что явно заказчик ошибся городом, и диски срочно потребуются где-то в другой части планеты. Мы поймали поставку уже после самолёта: понадобился ещё один перелёт обратно. Приняли со второго раза успешно.
Сингапур, Сингапур
Пятый дата-центр тоже был под полным сервисом, только провайдер — Softlayer. Здесь за всё время не было ни одной истории, ни следа каких-то непониманий. Вообще ни одной проблемы, за исключением цены.
С ними очень просто: говоришь, что тебе необходимо, выставляют счёт и железно обеспечивают инфраструктуру. Цены у них одни из самых высоких, но можно и нужно торговаться — у разных посредников могут быть разные варианты для одних и тех же услуг, например. Персонала там много, судя по ответам на тикеты, но абсолютно все компетентны.
Сидней, Австралия
Шестой ЦОД мы хотели сделать уже со своим инженером. Но оказалось, что найти специалиста необходимого уровня компетенции в Австралии довольно сложно: нам был нужен, грубо говоря, фрилансер-админ на четверть ставки, который приезжал бы пару раз в месяц и делал бы текущую работу. Плюс выезжал бы на аварии. Обычно мы ищем таких кандидатов через специальные агентства, которые обеспечивают нас тремя-четырьмя десятками уже готовых на такую работу специалистов. После этого мы отбираем до 10 анкет и проводим собеседования по Skype. Остаётся один человек, работающий в штате, и ещё 1–2 на подхвате, чтобы если что — они смогли заменить его, например, при болезни.
Проблемой в ЦОД в Сиднее стали сервера с 72 дисками. Они требовали чертовски много питания — на стойку приходилось 6 таких серверов, и каждый съедал по 0,9 кВт, стойка — от 6 до 8 кВт. Мой коллега говорит, если заходишь после ливня, через 10 минут твоя одежда полностью сухая.
Лондон, Англия
В Лондоне мы совмещаемся с Acronis Disaster Recovery. Это самый скучный ЦОД, там ничего не происходило. Год как поставили железо. Так ничего и не происходит. Стук-стук.
Бостон, США
В Бостоне самый большой наш ЦОД. В планах есть его переезд.
В Бостоне мы экспериментировали с 72-дисковыми серверами в 4 юнита. Проблем просто наелись, потому что сервер просто волшебный. В бостонском офисе есть наш гуру-админ, но он вообще-то занимается другим, и каждый раз вызывать его через весь город ради замены диска — как-то не очень правильно. Да и накладно.
Пишем тикеты местной поддержке. Но она работает не от ЦОДа, а от сторонней компании, дающей стойки этого огромного дата-центра. А никого другого на площадку они не пускают: или наш гуру, или их саппорт. Сами они умеют вставлять USB-диски в машину для инициализации, менять сбойные диски и перезагружать сервера. Всё. Один раз из 72-дискового сервера надо было вытащить конкретные диски. Салазки там двойные, два диска один за другим. Сложно разобраться, где и что, поэтому иногда они всё же трогали не те диски. Пришлось ехать.
В какой-то момент после старта к нам прибежал с огромным письмом электрик. Суть сводилась к тому, что 7 серверов по 0,9 КВт в стойку — это немного перебор. Говорит, потребляет он 115% номинала, необходимо разгружать. А другие стойки были типовые — местные, где сзади два блока с розетками, куда, собственно, втыкать питание. Наши серваки длиннее обычных сантиметров на 20 — и вот ровно этими 20 сантиметрами они закрывали слоты питания. Мы разбавили стойку «короткими» серверами. Помню, пока играли в тетрис, меняли 60-килограммовые машины там, таскали вдвоем, поправляли здоровье.
Россия, Москва
Мы храним данные россиян строго в РФ. Если вы ждёте офигительных историй про нашу поддержку — не дождётесь. Хотя, конечно, парочка сюрпризов от DataPro есть в копилке. В США обычная практика техработ — за неделю приходит письмо в духе «Мы тут запланировали то-то и то-то, это нужно и полезно для всего ЦОДа и для вас, работы будут в такой-то интервал. Вас это не потревожит». В России уведомляют немного иначе, но вы и сами, наверное, знаете. Но надо сказать, прерывания сервиса ни разу не было.
До этого мы стояли в Твери. Когда перевозили железо из Твери в Москву — за 2 недели отработали переезд 15 серверов «на горячую». Хотели в одну итерацию, но решили не рисковать с даунтаймом. Возили по 2 сервера каждый день: я вставал в 6 утра, давал добро на упаковку, везли — в 11 вечера писали, что привезли, — ставили, проверял. Подняли виртуальную сеть между Москвой и Тверью на хорошем линке, сервера думали, что они в одной физической сети с той же самой адресацией, что и раньше. Так и таскали по 2 машины: восстановление, ребаланс, проверка, ещё 2 сервера.
Эшбурн, США
На эту площадку только едет бостонское железо, пока особо рассказывать нечего.
В Эшбурн мы везем всё из Бостона по схеме, отработанной на примере Твери. Тоже поднят 10G-линк, и машинки в одной сети с сохранением адресации. Идея в том, что нужно поднять железо на новом месте и дождаться ребаланса: если, например, половина дисков выпадает при перевозке, то нужно ждать довольно долго их рестора, а не везти следующую партию.
Ещё случаи
В Европе иногда бывают особенности с таможней: когда нам нужно было срочно поменять один сгоревший сервер, мы отправили машину из Бостона, а это 2 дня вместо трёх недель со склада поставщика в Европе. Но мы не учли таможенников. Не хватало номера VAT, и они не смогли из-за языкового барьера (французский) договориться с бухгалтерией в США. Отправили всё обратно. С тех пор заказываем в Европу из Европы.
В Бостоне возникла проблема, что 36-дисковый сервер заполняется за полторы недели, а это 200 терабайт. Заказ тоже от двух недель — и получается, что мы не успевали заказывать сервера на волне более чем успешного запуска одного из продуктов. Решили тогда новыми принципами упаковки и частичным распределением по другим ЦОДам, поменяли многое в архитектуре. Меня это коснулось тем, что пришлось заново настраивать процедуры закупок и работы с поставщиками, — с тех пор мы можем брать большие партии и быстрее по предварительным договорённостям, оплачивать позже.
Один раз брали на тесты сервера с неполной конфигурацией для «медленных» данных. Там был только один процессор вместо двух, а внутри — полка дисков и 10Гб-сетевая карточка. Включаем — карточка не работает. Не видят сервера эти карточки. Читаем мануал — там момент мелким шрифтом: PCI-слоты разделены по процессорам, нечётные — на первом, чётные — на втором. Все слоты работают исключительно, когда только два процессора, но питание приходит на все независимо от этого. Карточка моргает и горит, но её сервер не видит. Переставили в другой слот, хотя, вроде, это ещё производитель должен был на тестах сделать.
У DataPro в Твери как-то деревья упали на оптику: пропала публичная сеть, по телефону объяснили, что случилось. Одна линия шла теперь ровно через пару тополей, а резерв не работал. Сетевое оборудование не смогло переключиться на резервный канал.
В Германии Level 3 в 2015 настраивали свою маршрутизацию и чуть задели нашу часть оборудования парой уровней ниже. На полчаса отвалился коннект. В тот момент европейский ЦОД был главным — это привело к прекращению сервиса в части Германии. С тех пор мы поменяли архитектуру, но это лучше коллеги расскажут.
В США же был случай. Наверное, это самое весёлое за всё время, что я видел. Меняли сервер, позвали инженеров производителя, чтобы они заменили материнку и блок питания. 72 диска, масса брутто — 80 килограмм. Эти зайчики начали вытаскивать его из стойки вместе со всей требухой. Получилось у них только наполовину — он начал крениться и падать. Они попробовали его удержать и вытащить, но погнули салазки. Попробовали запихать назад, но их не пустили уже погнутые рельсы. Взяли и бросили в таком состоянии. Сказали, что приедут через неделю с заменой.
В целом, как видите, условно-опасная ситуация за 5 лет была только одна, когда стоял вопрос о накатывании бэкапа с другой площадки. Но обошлось. Всё остальное решалось локально и довольно хорошо. Мелкие шероховатости — это обычный человеческий фактор, и, наверное, было бы странно, если бы у нас было меньше историй.
