Венгрия - новая локация в is*hosting!



Страна, известная национальной кухней и интересными изобретениями, пополнила список локаций is*hosting. Узнайте Венгрию с новыми VPS DELL R640 на NVMe дисках!

Дата-центр ATW Dataland 1 находится в Будапеште и отвечает современным требованиям надежности. В дата-центре кондиционирование воздуха зарезервировано по схеме N+1, доступность электрической сети находится на уровне 99,99%, система электроснабжения имеет резервный генератор, а сетевые устройства работают на базе оборудования Cisco.

Наш партнер ATW имеет опыт уже более 15 лет и понимает важность обеспечения дата-центра необходимыми системами безопасности, включая автоматическую пожарную сигнализацию и обнаружение дыма, систему поддержки оптимальной температуры (22°C ± 2°C) и круглосуточный мониторинг.
is*hosting — надежный провайдер для развития бизнеса. Попробуйте VPS в Венгрии уже сейчас!
Мы объявляем бонусы в честь открытия новой локации!

Получите 3 дополнительных месяца в подарок после оплаты, воспользовавшись кодом HUNOW, или 6 бонусных месяцев при оплате за год!
Код будет действовать до 3 июля.
cp.inferno.name/cart.php?gid=82

Отвечаю на вопросы после аварии



Мы шутили про эти телефоны, а они пригодились на прошлых выходных. Точнее, пригодилось резервирование телефонии. Не конкретно эти, но похожие)

Вот тут пост про нашу аварию на прошлых выходных. Там всё было по горячим следам, потом я обещал подробнее ответить на вопросы. Отвечаю. Самое главное, пожалуй, что бы я хотел донести, — в комментариях к первому посту было очень много советов, что можно сделать, чтобы избежать такой же аварии. Но большинство из этого мы делать не будем. Потому что это ошибка выжившего: защищаться надо от вероятных рисков, а не от крайне маловероятных, где совпадает сразу пять факторов. Точнее, можно и от них, но есть критерий экономической обоснованности.

Но давайте обо всём по порядку.

Сколько клиентов пострадало?
На три часа и более в одном ЦОДе отключилось 7–10 % из 14 наших, то есть менее 0,5 % от общего числа клиентов хостинга (точнее, хостов). Тем не менее мы очень подробно рассказываем про эту аварию, потому что она вызвала очень много вопросов.

Почему вы занимаетесь ЦОДом, а не встаёте в готовый?
«Прекрасная история, спасибо! Совет автору: ищите компанию, которая занимается ЦОДами давно и профессионально, ну а вам — переориентироваться на продажу сервисов/мощностей в этих ЦОДах...»
Сейчас по миру у нас 14 ЦОДов, где можно разместиться. Один из них, первый в Москве, с которого всё начиналось, — наш. Именно в нём произошла эта авария, и именно поэтому я так подробно всё рассказываю. Естественно, было бы логично уже давно сосредоточиться только на VDS-хостинге, как мы делаем везде по миру, но это наш базовый ЦОД, он для нас дорог. В смысле пока всё же экономически обоснованнее держать его. Плюс у нас на площадке есть аттестация ФСТЭК, что позволяет строить защищённые сегменты. Ну и охрана у него впечатляющая, про это — ниже.

Вообще тут вопрос намного более сложный. RuCloud Королёв — это наш первый ЦОД. Мы его создали сразу после истории с «Караваном», когда «Караван» ушёл в небо. Напомню, что они при срочной необходимости переехать не смогли забрать с собой энергетику и много других вещей, и это стоило им бизнеса. Полностью. Теперь — про экономику ЦОДа: если вы строите свой, то с масштабом снижается доля постоянных издержек. То есть с экономической точки зрения надо строить ЦОД как можно большего размера. А вот с точки зрения ведения ИТ-бизнеса в России — как можно меньшего, потому что, если есть выбор между одним ЦОДом и двумя-тремя, второе намного надёжнее. Но каждый инстанс получается дороже. В итоге мы построили свой ЦОД, подняли в нём аттестованный ФСТЭК сегмент (это своё помещение, защита от прослушивания, защита от лазерного считывания вибраций, сертифицированное оборудование, сертифицированное ПО, аудиты) — такого на общих площадках в принципе не сделать, а некоторым клиентам это важно. В смысле по рекламным проспектам может создаться впечатление, что можно, но нет. Равно как и с PCI DSS в Европе чаще всего — так же. Опять же свои админы, свои правила. Но тут — как с 3F: лучше всё же арендовать.

Соответственно, дальше мы раскладывали яйца по разным корзинам. Сейчас их 14. К концу недели будет 15. Можно выбрать любую.

То есть надо читать блог, чтобы понимать некоторые незадокументированные особенности ЦОДов?
Да. Мы же не можем прямо на сайте явно написать про ЦОД в Амстердаме, что там в стране легальны порнография и варез, и поэтому там можно выкладывать свежий фильм Михалкова без юридических проблем. Точно так же мы не можем рассказать про все особенности других ЦОДов. По большому счёту они сводятся к тому, что «по беспределу не заберут сервер», к особенностям охраны, питания, законодательства страны и так далее. Корпоративных клиентов мы консультируем на переговорах, если надо.

Сразу скажу, что даже Tier-IV никак не защищает от аварии. У нас был пример, когда 10 часов не было Интернета в Швейцарии. Они каждые 15 минут писали, что сейчас всё будет, кстати. Молодцы! Хороший статус-апдейт.

Вкратце вот: в ZUR1 (Цюрих) — 2N по питанию и N+1 охлаждения, внутренний стандарт SLA — 99,999 % (это выше, чем в Tier IV по UI). Во Франкфурте (это наш второй Tier IV UI) — N+1, два городских ввода от разных станций. EQUINIX LD8 гарантирует SLA TIER III (99,98 % — те самые 105 минут простоя в год). Питание и охлаждение — N+1, но они очень сильно заморочились на резервирование Интернета, аплинки с нескольких магистралей. Linxdatacenter — питание N+1. Екатеринбург — N+1. AMS9 — N+1. Останкино — четыре независимых ввода, прямое подключение к ТЭЦ-21, N+N.

А вот что мы реальном можем сделать — это написать SLA в каком-то виде на каждом из ЦОДов при выборе места для создания VDS. Это мы сейчас обдумываем, потому что SLA надо считать и фактический, и какой-то ещё прогнозный.

Уложились ли вы в свой SLA?
«Было бы очень интересно послушать про SLA и про то, как оно сейчас реализуется в текущей действительности...»
У нас по этому ЦОДу SLA — с 99,98-процентной доступностью, это 1 час 45 минут возможного простоя в год. Сразу скажу: это только в рекламе, а в документах это никак не регламентировано. Но мы всё равно выплачиваем компенсации.

Напомню, что в этом ЦОДе были клиенты с простоем больше трёх часов (77 % пострадавших), около 10 % — с простоем около 12 часов, и около 1 % — с простоем больше. Естественно, мы сразу же обещали компенсации всем тем, кто попал под этот инцидент. Надо понимать, что речь идёт про оговорённые договором компенсации, то есть если там была трейдерская машина, которая должна была что-то выкупить в нужный момент и клиент от этого потерял или недополучил какую-то сумму, — простите, но по договору мы компенсируем время простоя сервера, а не недополученную прибыль в результате работы ПО. Для критичных случаев как раз используется георезервирование, и именно поэтому нас выбирают: среди российских VDS-провайдеров у нас наиболее широкая география.

Сейчас, возможно, мы ещё выдохнем и будем менять договоры в сторону более явного прописывания SLA. Если бы мы делали это заранее, то ЦОД в Королёве имел бы 99,96 % или 99,9 %, а не 99,98 %. Для примера: фактический аптайм 100 % с 1991 года есть в Останкино.

Собственно, поэтому Королёв и дешевле других ЦОДов по колокации. Мы продаём колокацию во всех точках нашего присутствия, но об этом мало кто знает. У нас много места везде, кроме М9.

Почему ИБП хватает только на одно переключение дизеля?
«Тут много всяких «полезных» решений насоветовали в комментариях, разумеется. Вроде стресс-проверок отключением электроэнергии каждую ночь и покупки ИБП с акумом на сутки работы. Лол».
Похоже, про ИБП всё же надо объяснить. На текущий момент общемировая практика — держать их из расчёта одного набора свинцовых батарей на юнит, что обеспечивает несколько минут работы. За эти несколько минут нужно сделать переключение питания, то есть завести дизель. Заряда хватает обычно и на второе переключение с дизеля на городской ввод. Батареи заряжаются около 9–12 часов минимум. В случае если отключений питания несколько, то с каждым новым разрядом вырастают шансы, что они отключатся вместе с частью стоек. Почему так? Потому что бесконечно копить батареи обычно не имеет смысла. Уже начиная с полуторного запаса начинаются сложности с их размещением (они травят водород, то есть нуждаются в своей вентиляции, им нужен свой климат-контроль, они очень тяжёлые, то есть давят на перекрытия). В ЦОДах высокой ответственности вместо свинцовых батарей используются ДДИБП — огромные волчки, вращающиеся в гелии или вакууме, которые крутят вал генератора. У нас такого в этом ЦОДе, естественно, не было. Если бы было — размещение было бы куда дороже, и логичнее было бы дублировать ЦОД целиком. Что, собственно, у нас сделано 14 раз.

Почему охрана не пускала админов в девять утра в субботу?
Потому что одна из главных фичей Королёва — это та самая охрана режимного объекта, которая не стесняется посылать на три буквы всех, кого нет в списках. То есть они как-то умудрились даже [данные удалены] лицом в пол [данные удалены] приехавших нас аттестовать [данные удалены]. Потому что они размахивали какими-то корочками и хамили.

В Останкино у нас, например, охрана — отдельным батальоном Росгвардии. Поверьте, туда не приедет никакой ретивый сотрудник МВД с документами на следственные действия по виртуальному серверу вынимать физический. А это известный российский риск: если рядом с вами стоят странные персонажи (а на любом крупном VDS-хостинге всегда есть доля таких клиентов, и я про это писал), то может приехать сотрудник и попытаться выдернуть сервер. А железо — оно не такое, что вот на этом сервере добрые, а на этом — злые. Оно общее. Мы по опыту коллег знаем, что самый быстрый возврат сервера по звонку начальника: «Ты что там такое творишь? Верни железку обратно!» — занимает пять часов даунтайма. Спасибо, такого не надо ни нам, ни нашим клиентам.

Поэтому охрана действовала ровно в рамках своих полномочий. Мы находимся на территории стратегического производства. С началом кое-каких событий тут очень поднялся уровень паранойи. Героев, желающих проскочить, потому что внутри что-то срочное, хоть отбавляй. Охрана — в нашем случае внешний периметр Росгвардии — пускает тех, кто есть в списке, и не пускает остальных. Аварийной команды в списке не было, им нужно было получить соответствующий приказ. В лица они нас знают прекрасно, но нет — правила есть правила! Как я уже говорил, они очень юзерфрендли, почти как UNIX. То, что нам надо обсудить, как пускать своих людей во время аварий, — это отдельный вопрос, его сейчас прорабатываем. Возможно, будем страховаться и выписывать дополнительные разовые пропуска каждую смену. Собственно, вы сейчас будете смеяться, но мы так и делали, просто не на всех, а на одного человека дополнительно на всякий случай, и как раз он смог приехать уже к концу инцидента.

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

Обычная практика ЦОДов нашего размера — резерв из N+1 дизелей. У нас был 2N, нужен 2N+1.

Как вы видите выше, даже Tier-IV ЦОДы не считают критичным подниматься до 2N+1.

Почему дизель чинили админы?
Потому что не было выбора: дизелист был снаружи. Естественно, админы не должны были этого делать, естественно, большое спасибо, что получилось. Админы — однозначно герои этой истории!

Почему на территории нет моториста постоянно?
Потому что при дублировании вторым вводом из города, дизелем, 2N дизелем и ИБП шанс, что понадобится моторист, исчезающе мал. Для предотвращения маловероятных рисков проще дублировать ЦОД, что, повторюсь, у нас и сделано 14 раз. Вообще каждый раз, когда встаёт вопрос повышения на 0,5 % шанса в случае аварии или при открытии новой площадки начиная с какого-то экономического порога лучше выбирать геораспределённость. Это же ответ про то, готовы ли мы запуститься после пожара топлива: нет, не готовы, мы потушимся штатно, но не перезапустим дизели в разумный срок. А вот что реально стоит пересмотреть — это режим работы вентиляции, нужны отдельные решения под неё.

Теперь — самое интересное. На каждые плановые работы или начало каждой аварии мы тут же зовём профессионалов с дизелем, который арендуем. То есть когда планируются работы на подстанции, у нас резерв 3N по дизелям (наши плюс привезённый мобильный) и мотористы в дежурстве. В данном случае ещё один дизель на 0,5 МВт и команда обслуживания прибыли и смогли попасть на территорию уже после включения луча из города.

Почему админы вручную включали оборудование?
«И «Админы бегали между стойками» — даже после отключения питания машины должны сами подниматься».
Как раз машины не должны сами подниматься. История знает слишком много ситуаций, когда несколько циклов включения-выключения по питанию разваливают рейды и ломается железо. У нас настроено так, что после нештатного отключения питания часть оборудования надо включать вручную осознанно. В обычное время, когда не надо зажимать руками патрубок дизеля, это очень хорошая практика. И нет, мы не собираемся менять её несмотря на произошедшую ситуацию. Это как с ремнём в машине: есть незначительный процент аварий, когда пристёгнутый ремень хуже, чем непристёгнутый. Но статистически верно пристёгиваться, если задача — выжить.

Были ли потери данных?
Нет, рейды не сыпались. Если не считать нештатных перезагрузок и потерь того, что было в оперативной памяти, всё остальное более-менее нормально (насколько мы знаем).

Почему вы не сделали всё, чтобы предотвратить аварию?
На самом деле мы сделали всё, что казалось вероятным и при этом укладывалось в экономическое обоснование. По каждому риску вы делаете следующее: оцениваете его вероятность, а также ущерб от него и решаете, сколько вы готовы потратить на предотвращение. И, соответственно, оцениваете, насколько его можно предотвратить за этот бюджет. Исходя из этой модели очень хорошо закрываются наиболее вероятные риски и куда хуже — маловероятные. К нашествию пришельцев, высаживающихся в ЦОД, мы не готовы. Эта ситуация с цепочкой из пяти совпадений подряд — на самом деле тот же класс риска.

Как я уже говорил, мы исходили из двух неверных допущений в оценке рисков: что резервировать дизели надо по 2N, а не 2N+1 (уже исправили), и что DDoS-защита (за которой был мониторинг серверов) не нуждается в кластере коммутаторов, если есть один надёжный онлайн и один точно такой же в шкафу через 20 метров от стойки. Ну и главный косяк — мониторинг должен быть геораспределён, это мы знали, но не успели сделать.

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

Например, мы очень долго занимались сетевыми драйверами и писали свои, а затем сертифицировали их в Microsoft (ну с последней версией уже не выйдет, а вот предыдущие сертифицированы и лежат в каталоге ПО гипервизора).

После общения с другими хостинг-провайдерами могу сказать, что ситуация с сетью у нас очень хорошая. Именно в Королёве у нас огромная плотность вычислительных машин — это из-за 30-рублёвых промотарифов. И у нас там порядок в сети. При последней большой DNS-атаке, затронувшей всю страну (привет, домены Битрикса!), пострадали, кажется, вообще все наши знакомые. У нас же только два человека хоть как-то пострадали среди всех клиентов. Два человека, Карл! Мне кажется, что это лучший показатель порядка в сети.

Мы предотвратили очень много инцидентов, направленных не в наш карман, а в сторону клиента, благодаря правильным ACL, драйверам и т. п. У этого есть оборотная сторона: в субботу не могли быстро включить коммутатор на замене вместо выгоревшего. Теперь продумаем и это, скорее всего, построим кластер.

В целом по этой аварии вопрос такой: «Действовал бы я точно так же, если бы мог вернуться в прошлое?» Ответ: «Скорее всего, да». Без проклятия знания все действия ДО были рациональными.

Почему вы пишете про такие вещи?
«Вот за такие триллеры вам можно простить горы проходного шлака, который обычно публикуется в этом блоге. Побольше бы таких историй! ;)»
Мы открыто рассказываем про все ситуации, которые влияют на хостинг. Да, мы прекрасно понимаем, что в России так не принято. Да, мы прекрасно понимаем, что из-за этого открывается много приподзакрытых глаз, не знающих, как всё изнутри. Да, мы понимаем, что другие хостинги, утаивающие детали про то, что у них происходило и происходит, до какого-то момента надёжнее смотрятся со стороны. Тем не менее моё осознанное решение как владельца компании — долговременная репутация. Если уж мы лажаем, то рассказываем об ошибке. Мы тут не на пару дней и вроде до этого момента более-менее успешно избегали серьёзных косяков.

«Захватывающая статья! Очень импонирует то, что вы открыто говорите о своих косяках. Думаю, что даже у недовольных отключением пользователей её прочтение повысит доверие к вам».

Если быть честными, то скорее наоборот. Это вот вторая публикация про менее чем 0,5 % клиентов хостинга, но при этом выглядящая так, как будто всё произошло по всему гриду. Но я очень надеюсь на то, что наши клиенты — всё же рациональные люди.

Как себя чувствуют админы?
С моей точки зрения, они герои той ночи! Но, тем не менее, они довольно сильно подавлены, потому что успели прочитать комментарии и чаты. Каждый раз возникает ощущение, что ты что-то недоработал, и при любой аварии ответственный человек начинает корить себя. Наши админы как раз очень ответственные, и ЦОД — их детище во многом. Естественно, они расстроены. Более того, мы с командой очень долго обсуждали, нужно ли публиковать материал про эту аварию второй раз: это ведь ещё один удар по ним фактически. Представьте себя сейчас на их месте: ощущение будет не из приятных. Полагаю, что девопсы и админы, которые знают, что у них в инфраструктуре что-то ещё неидеально (а это постоянное чувство, и оно сохраняется годами), это поймут.

ruvds.com

Самый длинный простой за нашу историю

Коротко: 17 июня около часа ночи мы потеряли два ввода питания от города из-за аварии на подстанции, затем — один из дизелей, что вызвало «мигание» питания в подземном дата-центре. Итог инцидента — простой около 12 часов примерно 7–10 % машин одного из 14 наших ЦОДов.

Это просто дикая цепочка событий.


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

Итак, мы потеряли оба городских ввода — всё как в худших домах Парижа. Как мы уже потом узнаем, вроде бы авария была на трансформаторе 110 кВт: при перераспределении мощностей с первого произошло замыкание второго. За полтора года это уже третий раз, когда пропадают оба луча, и вот тут я рассказывал, как мы почти сутки стояли на дизеле. Для клиентов это прошло незаметно (кроме той стойки, где при мигании света сгорел ИБП: там был простой на перезагрузку).

Штатно сработали ИБП, автоматически завелись дизель-генераторы, ЦОД продолжил работу. У нас общая энергосеть с соседним ЦОДом всё в том же подземном бомбоубежище. Общее потребление — 0,5 МВт, дизелей — на 1,05 МВт.

Через два часа, около 3:30 ночи, лопнул патрубок дизеля 0,5 МВт, отчего он внезапно перестал работать. Админы убежища переключили мощности на дизели 2 х 100 КВт и 2 х 200 КВт. В момент переключения нагрузка снова легла на ИБП, а за два часа они не успели восстановиться, и часть оборудования выключилась.

Это запустило целую цепочку последствий, потому что при этом выключении погорела одна из плат коммутатора, обеспечивавшего доступ в нашу сеть управления ЦОДом, то есть все удалённые доступы.

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

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

Что было с городскими вводами
Они пропали. Авария коснулась всего микрорайона. Мы относимся к важным потребителям электроэнергии, поэтому восстановление наших мощностей — первый приоритет для города. У нас не было городского ввода примерно с часа ночи до обеда, около 10 дали первый луч, через пару часов — второй.

Как можно видеть по заявкам в районе, жилые дома восстанавливали позже, то есть устраняли аварию максимально быстро для нас.



Почему только два админа
Ночь с субботы на воскресенье, особо охраняемая территория. В течение двух часов с начала инцидента всё идёт относительно предсказуемо, и помощь не нужна. Админы работают штатно. Примерно в 3:30 становится понятно, что нужно высылать подкрепление, но в этот момент уже:

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

Самое печальное — коммутатор защищённого сегмента, который включился, но работал неправильно. Это сегмент, в котором стоит DDoS-защита, то есть через него подключено около 7 % IP-адресов ЦОДа. Коммутатор зарезервирован по принципу HOT SWAP, то есть точно такой же лежит в коробке в шкафу в админской. Мы не думали строить кластер из двух коммутаторов, потому что не похоже, что DDoS-защита относится к критичным сегментам: при выходе её из строя примерно на 5–20 минут (время физической замены коммутатора) возможны DDoS.

То есть центральный коммутатор у нас нормально в кластере, а один из листов, относительно небольшая и относительно нетребовательная к непрерывности подсеть, на хотсвапе. Это была ошибка, и здесь мы здорово облажались.

Во-первых, оказывается, что тяжело менять коммутатор, когда ты держишь руками патрубок дизеля. Кроме физической замены, там нужно импортировать правила и ACL.

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

В этот момент около 3:30 мы остались без сервисдеска, мониторинга, корпоративного мессенджера и одной из реплик сайта. Мессенджер тут же деградировал до «Телеграма», веб-сервер сайта автоматически поднялся в другом ЦОДе, а вот от мониторинга и сервисдеска такой подставы мы не ждали.

На мониторинг, в частности, было завязано определение оставшегося свободного места в ЦОДах, а оставшееся свободное место в ЦОДе определяет возможность создавать в нём новую виртуальную машину.

Это означало, что автоматика не видит свободного места, потому что источник данных для панели управления находился именно в глючившем защищённом сегменте. А потому система не даёт возможности создать новые ВМ в каждом из ЦОДов сети.

Выглядело это как крестик на создание ВМ на каждом из ЦОДов нашей сети, что начало вызывать панику в чате клиентов хостинга:

Это уже семь утра, когда существенная часть клиентов проснулась. До семи утра было ещё два отключения питания и перехода на уже истощённые ИБП. Перегрелся и начал нестабильно работать один из малых дизелей, а большой ещё не успели перебинтовать. И вообще, админы не очень хорошо ремонтируют дизели: это немного не их профиль работы.

Соответственно, клиенты пытались перенести свои ВМ в другие ЦОДы по миру, но из-за сбоя мониторинга не могли этого сделать: система не давала создать новые ВМ.

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


Админы были отрезаны от мира
Я неслучайно сказал, что это ночь с субботы на воскресенье на особо охраняемой территории. Дело в том, что после начала всем известных событий территория стала просто параноидально охраняемой.

Среди всего прочего в рамках общей параноизации нам отозвали все постоянные пропуска и заменили их на систему одноразовых пропусков персонала посменно. То есть около 3:40 ночи, когда уже стало понятно, что в ЦОДе не помешают лишние руки, никого отправить туда мы не могли, потому что люди встали бы на проходной.

Бюро пропусков по ночам не работает, по воскресеньям — тоже.

Это значит, что мы не можем отправить ещё админов и не можем отправить дизель. Дизель на 0,5 МВт у нас под рукой был после прошлого инцидента, и мы подтащили его к территории около девяти утра, но попасть внутрь не могли.

Охрана понимала всю серьёзность ситуации (насколько могла) и очень хотела помочь, но ровно в рамках своих полномочий: им нужно было разбудить своего начальника, чтобы он разрешил нештатную ситуацию. Попасть на территорию получилось только около 13:00.

До этого момента в ЦОДе было две пары рук.

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

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

Восстановление
Когда приехал резервный дизель, всё встало на свои места.

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


Последние сервера поднялись около 16 часов: это когда мы подключили в бой тот самый защищённый сегмент, стоявший за частично погоревшим коммутатором.

Клиенты, естественно, были не очень довольны:


Интересно, что больше всего тикетов с паникой было у пользователей наиболее экономичных тарифов. То есть те, у кого был действительно критичный проект, развернули его на нескольких геоплощадках. Бывалые админы достаточно спокойно наблюдали за паникой людей в чате:



Общий итог такой:
  • 23% клиентов ДЦ вообще ничего не заметили, остальные могли ощутить даунтайм до 120 минут.
  • 7-8 % виртуальных машин было недоступно более трёх часов. Мы не можем сказать точнее: верхняя оценка — 10 %, но мы знаем, что часть машин в рассыпавшемся сегменте отвечала, по косвенным данным, что это было всё же 7 %. Максимальный даунтайм на отдельных серверах из 7-8% составлял 16 часов.
  • Всё 13 остальных ЦОДов работали штатно, но отсутствие мониторинга не давало создавать на них новые ВМ.
  • Всё решилась после прибытия подмоги, то есть с 13:00 до 15:00. К 16:30-17:00 доступность была 100% восстановлена.
  • В нашем ЦОДе не работало, по верхней оценке, 10 % оборудования. У соседей же была настоящая паника: у них пострадало до 75 % оборудования (судя по их письму клиентам).

Сколько/чего выключилось:
  • Количество НОД перезагрузившихся из-за перепада/отсутствия питания в ночь аварии — 68 %: 24 % в 3:30, 26 % в 4:50 и 18 % в 6:00.
  • Количество НОД дц Rucloud, которых не затронула авария — 23 %.
  • Количество НОД дц Rucloud, которые стали доступны после решения проблемы с коммутатором (самое большое время простоя) — 8 %.
  • Количество НОД дц Rucloud, которые были перезагружены 18-19 июня в результате выявленных последствий аварии — 1 %.

Разбор ошибок
Из того, на что мы могли повлиять:
  • Нужен не двойной запас по дизелям, а больший: ночь показала, что двух недостаточно, нужно 2N + 1 минимум. Поскольку в кризисы мы объединяем энергосеть с соседями, договорились, что введем в эксплуатацию (дизель уже куплен, ожидаем к нему кожух) вместе ещё один 0,5 МВт ДГУ и разместим на территории.
  • Коммутатор защищённого сегмента должен был быть задублирован в кластере. Как только мы разместили за DDoS-защитой мониторинг, сеть стала критичной, но мы этот момент упустили и оставили узкое место с ручной заменой железяки. Оказалось, что у неё есть не только бинарные состояния «однозначно работает» и «однозначно не работает», но и промежуточные.
  • Тот факт, что мониторинг и тикет-система не были зарезервированы в другом ЦОДе, — это пощёчина нашему достоинству. Мы чёртовы параноики из финансов, и именно мы остались без мониторинга. Дублирование было в разработке и намечалось на конец июля. Немного не успели. Исторически эти системы размещались в первом нашем ЦОДе, теперь нужно распределять их по гриду, чтобы даже масштабный сбой никак не влиял на возможность заказывать виртуалки и обращаться в поддержку в других ЦОДах.

Я пережил несколько очень неприятных моментов этой ночью и понял, что нам нужен публичный мониторинг.

С моей точки зрения ситуация выглядела так: ужасно усталый я пришёл домой вечером, бросил телефон с 3 % заряда на столик и вырубился. Около шести часов я проснулся, решил, что быстро не засну, включил телефон почитать Хабр и сорвал джекпот в виде лавины уведомлений. Технический директор хостинга ночью тоже спал. Но он никогда не отключает телефоны, и звонки админов у него всегда дают громкий сигнал. Он разруливал ситуацию с часа ночи. Хорошо, что телефония в ЦОДе у нас как раз была зарезервирована правильно.

Фактически утром я не мог точно понять, что произошло (как и все мы: для полноты картины нужно было бы дозвониться до админов и поговорить с ними больше 20 минут).

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

Мы рассылали вот такое письмо:
Всем привет!

В районе 3:00 по МСК произошла авария на подстанции, в результате чего в дата-центре Rucloud (г. Королёв) были нарушены оба ввода электроснабжения. Проблема повлекла за собой перезапуск коммутационного ядра и длительный период восстановления. На момент аварии оборудование дата-центра работало на аварийных дизель-генераторах, но сейчас проблема устранена, и доступность всех нод уже восстановлена. Специалисты работают над восстановлением доступа к единичным оставшимся оффлайн виртуальным машинам, и в ближайшее время доступ должен полностью восстановиться.

По предварительным данным, аварийные работы затронули не более 10 % серверного оборудования в дц Rucloud. Остальные 13 дата-центров работают в штатном режиме, и проблем там не наблюдалось.

Если ваша виртуальная машина была среди тех, что затронула сегодняшняя авария, обязательно свяжитесь с нами по почте support@ruvds.com. Каждый случай простоя будем решать индивидуально и начислять компенсации за простой.

Подробный отчёт по аварии ждите в нашем блоге на Хабре в ближайшие дни.
Приносим свои извинения за доставленные неудобства!

В телеграм-канале был сущий кошмар. Дело в том, что в России уже было два случая, когда хостинг внезапно отключался целиком, а потом больше никогда не включался. И среди наших клиентов были админы, повидавшие некоторое дерьмо и знающие особенности ИТ-бизнеса в этой стране. Поэтому они, естественно, волновались. Мне очень нужно было объяснить, что происходит, но я никак не мог сам собрать информацию рано утром.

Никто не верил, что в одном из 14 ЦОДов был сбой, который затронул до 10 % железа. Отдельно меня обижали фразы вроде: «Чего вы хотите за такие деньги?» Аварии бывают и там, где на порядок дороже. У нас нет умышленной ставки на некачественные услуги. Неважно, сколько заплатить: зарезервироваться на 100 % не получится. Самое обидное в этой истории, что раздолбаями на этот раз оказались не мы. Точнее, мы тоже, но, трезво оценивая ситуацию, мы всё же в меньшей степени.

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

Более-менее связную картину произошедшего мы получили только около восьми утра.

В целом это, наверное, — самый тяжёлый наш кризис, потому что мы его переживали при 100-процентно заполненном машзале. Когда гермозона стоит полупустой, есть резерв по мощности: формируется тот самый 2N + 1, а не просто 2N. У нас такой роскоши не было. В целом мы сейчас переберём архитектуру сети, но куда важнее, что мы в Москве принципиально делаем ставку на развитие Останкино (вот пост про него) — ЦОДа повышенной ответственности. И в убежище, и в М9 гермозоны уже заполнены полностью, и новых стоек просто нет. В случае М9, где мы делим площадку с другими компаниями, нет места даже в стойках соседей.

Итог: нам нужен сервис публичного мониторинга доступности нод. Обычный хостинг такого делать не будет, потому что инциденты принято скрывать. Особенно если они затронули не очень большую часть клиентов. Просто телеграм-канала, Хабра и поддержки не хватает. Нужна система, которая сама обновляется и показывает объективные данные всё время, даже если это не очень удобно для нас в моменте.

В процессе слова поддержки от вас были очень приятны. Благодарности в конце тоже очень грели. Спасибо! Это было очень тяжело, но то, что вы с пониманием отнеслись, — это очень приятно.

ruvds.com

E3-1245v2 / 32 GB DDR3 / 2x960 GB SSD - 2700р./месяц, 0р. установка





Срочно с распродажи освобождаются около 40 выделенных серверов
E3-1245v2 [4c-8t] (3.8GHz) / 32 GB DDR3 / 2x960 GB SSD / 100Mbps — 2700р./месяц, 0р. установка
Если берете разом все, цена будет еще ниже.

  • Диски новые
  • Дата-центр OVH, Франция GRA RBX
  • Безлимитный трафик
  • Anti-DDoS
  • Панель управления сервером

Для заказа создайте тикет panel.abcd.host либо пишите в чат на сайте abcd.host.

Спасибо что остаетесь с нами,
ABCD.HOST

5 июня 2023



5 июня 2023
  • Панель переведена на бразильский португальский язык, огромная благодарность Жоао Родригесу.

8 марта 2023
  • Панель локализована на итальянский язык, огромная благодарность Риккардо Олларгиу.
  • Мы благодарим Фила Гонсалеса за его помощь в улучшении испанской версии FASTPANEL.

14 декабря 2022
  • Добавлена ​​поддержка PHP 8.2.
  • Панель локализована в Турции, огромное спасибо Yasin Yilmaz.

fastpanel.direct

Обновление SmartDedic - теперь дедики с бекапом!

Уважаемые клиенты!

Мы рады представить вам новое обновление опции SmartDedic для выделенных серверов!
Теперь вы можете сделать полноценные бекапы своих выделенных серверов со всеми данными!
Опция уже доступна в панели управления SmartDedic :)
И самое главное, это полностью бесплатно!

Спасибо, что вы с нами!

Рассказываем о произошедших и ближайших изменениях







Избавились от большого количества legacy кода, который сильно замедлял разработку нового функционала;
  • Интегрировали синхронизацию всех доступных ресурсов для заказа в каждой из локации (по каждому тарифу просчитывается каждые 30 минут). Синхронизация происходит уже сейчас, в следующем релизе личного кабинета появится и отображение (скриншот 1);
  • Меняется основной домен с hip-hosting.com на hip.hosting. Старый домен будет выполнять редирект на новый;
  • Всё больше и больше текста доступно для отображения на 2 языках. Стремимся к показателю в 100%;
  • Изменили отображение услуг в дашборде на более компактное, а также добавили меню быстрых действий для каждого сервера (скриншот 2);
  • В разделе финансов теперь отображаются последние платежи (скриншот 3);
  • Оборудование уже достигло датацентра в США. Скоро установка в стойку и разворачивание инфраструктуры; Германия также довольно близка к запуску.

В свете изменений и улучшений совсем не исключено, что у нас появится и посуточная аренда серверов во всех локациях.
my.hip-hosting.com/hiplets/new

Proxmox Virtual Environment 8.0 with Debian 12 "Bookworm" released



ВЕНА, Австрия — 22 июня 2023 г. — Разработчик корпоративного программного обеспечения Proxmox Server Solutions GmbH (далее «Proxmox») сегодня выпустила стабильную версию 8.0 своей платформы управления виртуализацией серверов Proxmox Virtual Environment. Этот основной выпуск основан на последней версии Debian 12 («Книжный червь») и поставляется с тщательно протестированным и подробным путем обновления для пользователей Proxmox VE 7.4 или более ранних версий, чтобы обеспечить плавное обновление. Proxmox VE 8.0 использует более новое ядро Linux 6.2 в качестве стабильного по умолчанию и включает обновления последних версий ведущих технологий с открытым исходным кодом для виртуальных сред, таких как QEMU 8.0.2, LXC 5.0.2, ZFS 2.1.12 и Ceph Quincy 17.2. 6.

Платформа виртуализации от Proxmox поставляется со всеми необходимыми инструментами управления и простым в использовании пользовательским веб-интерфейсом. Это позволяет удобно управлять отдельными хостами или всем дата-центром с помощью готовых инструментов — либо через веб-браузер, либо через командную строку.

Дополнительные особенности Proxmox Virtual Environment 8.0
  • Новый репозиторий Ceph Enterprise: Proxmox Virtual Environment полностью интегрирует Ceph Quincy, позволяя запускать и управлять хранилищем Ceph непосредственно с любого из узлов кластера, а также легко настраивать гиперконвергентную инфраструктуру и управлять ею. Исходный код Ceph упаковывается командой разработчиков Proxmox и — после обширных тестов — доставляется в стабильный репозиторий Enterprise. Это унифицирует доставку Ceph с другими компонентами Proxmox VE. С версией 8.0 все клиенты Proxmox с активной подпиской теперь могут получить доступ к стабильному репозиторию Ceph Enterprise, рекомендованному для производственных сред.
  • Задания синхронизации области аутентификации: Синхронизация пользователей и групп для областей на основе LDAP (LDAP и Microsoft Active Directory) теперь может быть настроена на автоматический запуск через регулярные промежутки времени. Это упрощает управление и устраняет источник ошибок и упущений конфигурации по сравнению с синхронизацией области вручную.
  • Сетевые ресурсы, определенные для программно определяемой сети (SDN), теперь также доступны как объекты в подсистеме управления доступом (ACL) Proxmox VE. Конкретным пользователям и группам можно предоставлять подробные разрешения для сетевых мостов узлов и виртуальных сетей.
  • Сопоставления ресурсов: Сопоставления между ресурсами, такими как устройства PCI(e) или USB, и узлами в кластере Proxmox VE теперь можно создавать и управлять ими в API и веб-интерфейсе. Гости ВМ могут получить такой назначенный абстрактный ресурс, который можно сопоставить с конкретными ресурсами на каждом узле. Это позволяет осуществлять автономную миграцию для виртуальных машин со сквозными устройствами. Сопоставления также представлены в системе ACL Proxmox VE, позволяя пользователю получить доступ к одному или нескольким определенным устройствам, не требуя root-доступа. В случае обнаружения конфликтующей записи, например. из-за изменения или перекрытия адресов пользователи информируются о запуске ВМ.
  • Надежная блокировка для двухфакторной аутентификации/TOTP: для дальнейшего повышения безопасности учетные записи пользователей со слишком большим количеством попыток входа в систему, не прошедших двухфакторную аутентификацию, блокируются. Это защищает от атак, когда пользовательский пароль получается, а второй фактор пытается подобрать методом грубой силы. Если TFA дает сбой слишком много раз подряд, учетная запись пользователя блокируется на один час. Если TOTP терпит неудачу слишком много раз подряд, TOTP отключается для учетной записи пользователя. Учетная запись пользователя может быть снова разблокирована с помощью ключа восстановления или вручную администратором.
  • Текстовый пользовательский интерфейс (TUI) для установщика ISO: добавлен текстовый пользовательский интерфейс, который теперь можно использовать для сбора всей необходимой информации. Это устраняет проблемы при запуске графического установщика на основе GTK, которые иногда возникают как на очень новом, так и на довольно старом оборудовании.
    Модель x86-64-v2-AES — это новый тип ЦП по умолчанию для ВМ, созданных через веб-интерфейс. Он предоставляет важные дополнительные функции по сравнению с qemu64/kvm64 и повышает производительность многих вычислительных операций.
Proxmox Virtual Environment — это бесплатное программное обеспечение с открытым исходным кодом, опубликованное под Стандартной общественной лицензией GNU Affero, v3. ISO содержит полный набор функций и может быть установлен на «голое железо». Proxmox VE 8.0 доступен для загрузки по адресу www.proxmox.com/downloads.

Инструкции по плавному обновлению с Proxmox VE 7.x до 8.x задокументированы по адресу pve.proxmox.com/wiki/Upgrade_from_7_to_8.
Также можно установить Proxmox VE 8.x поверх Debian.

Для корпоративных пользователей Proxmox Server Solutions GmbH предлагает модель поддержки на основе подписки, которая обеспечивает доступ к тщательно протестированному корпоративному репозиторию с регулярными обновлениями через веб-интерфейс, а также техническую поддержку на основе подписки. Цены начинаются от 105 евро в год за процессор.

Объявление Leaseweb Deutschland GmbH о нашем новом официальном адресе офиса

Уважаемый клиент,

Сообщаем вам, что официальный адрес Leaseweb Deutschland GmbH изменился на Hanauer Landstra ß e 121, 60314 Frankfurt am Main, Germany

Вы можете увидеть это изменение адреса на нашем веб-сайте и во всех официальных документах Leaseweb Deutschland GmbH.

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

С наилучшими пожеланиями,
Лизевеб Дойчланд ГмбХ