Теперь вот длинный ответ

travaux.ovh.net/?do=details&id=28247

Сегодня утром в 7:23 утра у нас был большой перерыв на нашем сайте в Страсбурге (SBG): перерыв в электроснабжении, который оставил три датацентра без электроэнергии в течение 3,5 часов. SBG1, SBG2 и SBG4. Вероятно, это самый худший сценарий, который мог произойти с нами.

Участок SBG питается от линии электропередачи 20 кВА, состоящей из 2 кабелей, каждая из которых обеспечивает 10MVA. 2 кабеля работают вместе и подключены к одному и тому же источнику и к тому же автоматическому выключателю в ELD (Strasbourg Electricity Networks). Сегодня утром один из двух кабелей был поврежден, и автоматический выключатель отключил питание от центра обработки данных.

Сайт SBG предназначен для работы без ограничений по времени на генераторах. Для SBG1 и SBG4 мы создали первую резервную систему из 2 генераторов по 2MVA каждый, сконфигурированных в N + 1 и 20kv. Для SBG2 мы создали 3 группы в конфигурации N + 1 1,4 МВА каждый. В случае сбоя внешнего источника питания высоковольтные ячейки автоматически перенастраиваются с помощью моторной отказоустойчивой системы. Менее чем за 30 секунд дата-центры SBG1, SBG2 и SBG4 могут восстановить мощность с 20 кВА. Чтобы сделать это переключение без отключения питания серверов, у нас есть источники бесперебойного питания (ИБП), которые могут поддерживать питание до 8 минут.

Сегодня утром моторная отказоустойчивая система работала не так, как ожидалось. Команда запуска генераторов резервного копирования не была предоставлена ​​NSM. Это NSM (двигатель с нормальной аварийной ситуацией), предоставляемый поставщиком высоковольтных ячеек 20 кВ. Мы контактируем с производителем / супером, чтобы понять происхождение этой проблемы. Тем не менее, это дефект, который должен был быть обнаружен во время периодических испытаний на неисправность внешнего источника. Последний тест SBG для восстановления резервных копий был в конце мая 2017 года. Во время этого последнего теста мы приводили SBG только из генераторов в течение 8 часов без каких-либо проблем, и каждый месяц мы тестируем генераторы резервных копий бесплатно. И, несмотря на все это, этой системы было недостаточно, чтобы избежать сегодняшнего юрта.

Примерно в 10 часов нам удалось переключить ячейки вручную и снова начать работу центра обработки данных с генераторами. Мы попросили ELD отсоединить неисправный кабель от высоковольтных ячеек и снова включить автоматический выключатель только с одним из двух кабелей и, следовательно, были ограничены 10MVA. Это действие было выполнено ELD, и мощность была восстановлена ​​примерно в 10:30. Маршрутизаторы SBG были подключены к сети с 10:58 утра.

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

В 7:50 мы создали кризисную единицу в RBX, где мы централизовали информацию и действия всех вовлеченных команд. Грузовик из RBX был загружен запасными частями для SBG. Он прибыл в пункт назначения около 17:30. Чтобы помочь нашим местным командам, мы отправили команды из центра данных LIM, расположенного в Германии, и персонала из центра обработки данных RBX, все из которых были мобилизованы на месте с 16:00. В настоящее время более 50 техников работают в SBG, чтобы вернуть все услуги в Интернете. Мы готовим работу ночью и, если необходимо, завтра утром.

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

Так почему же этот провал? Почему SBG не выдержала простой сбой питания? Почему весь интеллект, который мы развили в OVH, не смог предотвратить эту катастрофу?

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

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

Таким образом, в начале 2012 года мы запустили дата-центр SBG1 из морских контейнеров. Мы развернули 8 грузовых контейнеров, и SBG1 работает менее чем за 2 месяца. Благодаря этому сверхбыстрому развертыванию, которое заняло менее 6 месяцев, мы смогли подтвердить, что SBG действительно является стратегическим местом для OVH. К концу 2012 года мы решили построить SBG2, а в 2016 году мы начали строительство SBG3. Эти 2 датацентра не были построены из контейнеров, но были основаны на нашей технологии «Башня». Строительство SBG2 заняло 9 месяцев, и SBG3 будет запущен в производство в течение месяца. Чтобы решить проблему пространства, в начале 2013 года мы быстро построили SBG4, основываясь на разговорах о транспортировочных контейнерах.

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

Мы допустили две ошибки:
  1. Мы не сделали сайт SBG совместимым с внутренними стандартами, для которых требуется 2 отдельных электропитания 20 кВ, как и все наши места постоянного тока, которые оснащены двумя электрическими каналами. Это крупные инвестиции в размере от 2 до 3 миллионов евро за электрическую подачу, но мы считаем, что это часть нашего внутреннего стандарта.
  2. Мы построили энергосистему SBG2, поместив ее в энергосистему SBG1 вместо того, чтобы сделать их независимыми друг от друга, как и во всех наших центрах обработки данных. В OVH каждый номер центра данных указывает, что силовая сеть не зависит от других датацентров. Где угодно, кроме сайта SBG.

Технология, основанная на транспортных контейнерах, использовалась только для сборки SBG1 и SBG4. На самом деле мы поняли, что контейнерный центр обработки данных не соответствует требованиям нашей торговли. На основе темпов роста SBG минимальный размер сайта должен быть равен нескольким центрам обработки данных и, следовательно, иметь общую емкость 200 000 серверов. Вот почему сегодня для развертывания нового датацентра мы используем только два типа конструкций, которые были широко протестированы и спланированы для крупномасштабных проектов и надежности:
  1. строительство 5-6-этажных башен (RBX4, SBG2-3, BHS1-2) для 40 000 серверов.
  2. приобретение зданий (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) для 40 000 или 80 000 серверов.

Даже если этот утренний инцидент был вызван сторонним автоматом, мы не можем отрицать свою ответственность за провал. У нас есть кое-что, что нужно сделать для SBG, чтобы достичь того же уровня стандартов, что и другие OVH-сайты.

В течение дня мы приняли следующий план действий:
  • установка второго, полностью отдельного электрического питания 20MVA;
  • разделение силовой сети SBG2 от SBG1 / SBG4, а также отделение будущего SBG3 от SBG2 и SBG1 / SBG4;
  • миграция клиентов SBG1 / SBG4 в SBG3;
  • закрытие SBG1 / SBG4 и удаление транспортных контейнеров.

Это инвестиционный план в размере 4-5 миллионов евро, который мы запускаем завтра, и надеемся, что мы сможем восстановить доверие наших клиентов к SBG и OVH.

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

Мы очень сожалеем об этом инциденте, и мы благодарим доверие, которое вы оказываете нам.

29 комментариев

hitmany
Так rbx1 тоже был недоступен. Почему он не переезжает?
alice2k
про RBX читай тут
hosting.kitchen/ovh/incident-roubaix.html
hosting.kitchen/ovh/esche-summarno-pro-dc-roubaix.html

не RBX1 — а весь RBX1 — RBX6

SBG — они все свалили на неправильную архитектуру электропитания при постройке ДЦ из контейнеров — именно поэтому решили переезжать из контейнеров SBG1 SBG4 в полноценные постройки SBG2 SBG3(который щас строится как раз и завершается).
строительство 5-6-этажных башен (RBX4, SBG2-3, BHS1-2) для 40 000 серверов.
приобретение зданий (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) для 40 000 или 80 000 серверов.


А в RBX — это проблема сети была
brightside
Нихрена не работает, но они спешат отрапортовать о том, что инцидент закрыт. Инцидент закрыт тогда, когда работают все сервисы, которые were affected. По поводу переезда, это чистой воды популизм и маразм. Они там что-то делают, из-за чего в паблик клауд хосты ребутятся вместо реинсталляции и vrack работают через раз, не работают фаерволы и центос, установленный с указанием паблик кея просит пароль, а еще не работают квоты ресурсов, ну и сейчас бы в таких ситуациях на тикеты по 30 часов отвечать.

При этом они пытаются убедить общественность, что это «your issues with setup» и сейчас судя по всему вообще не торопятся, потому что максимальная компенсация в рамках инцидента по SLA не может составлять более ежемесячной стоимости того, что было affected. А если для людей, которых волнует бесперебойная работа их сервисов — то это вообще смерть OVH как public cloud провайдера. Конечно, это unmanaged cloud и все это понимают, но он должен не может быть настолько нестабилен.

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

только вот VMmanager не поднялось 4 ноды
vm.center/2017/11/public-nodes-vm-center/otchet-o-4-nodah-centos-7-vmmanager-ovh-sbg2-09-11-2017.html
с нуля пришлось восстанавливать с бекапов
brightside
В SBG3 у меня уже 4 месяца сервисы работают, поэтому хз, что там у кого строится)
alice2k
скрин сделаешь?
я тебе не верю потому что. SBG3 — не запущен еще и я точно это знаю.
brightside
Я тибе ни верююююю, ты сон вчерашниий)

alice2k
понял о чем ты

у них там в облаке — шараж мантаж
тупые сотрудники, прожирающие бабки в офисе — локации не правильно прописали

там есть и GRA3 тоже ) которого не существует.

я думал ты о дедиках говоришь

убогим облаком с "ежемесячными счетами" — не пользуемся

пользуемся только нормальным облаком, которое
www.ovh.ie/vps/vps-ssd.xml
www.ovh.ie/vps/vps-cloud.xml
www.ovh.ie/vps/vps-cloud-ram.xml
alice2k
например hosting.kitchen/ovh/public-cloud-new-region-de1-frankfurt-germany.html

там тупой сотрудник вместо LIM1 прописал DE
сука
все знают что новый ДЦ в германии называется LIM1
а он не знает, но работает в офисе на зар плате
alice2k
да, про Public Cloud — я ВЕРЮ тебе, что оно может лежать и по сей день в говно
и никто, даже сами ОВХ не знают о этом просто )
они не врут тебе, они просто не мониторят это дело. это другая инфраструктура.
а отрапортавали они — про дедики и нормальные VPS-ки.
brightside
Разницы не вижу никакой. Если пыхнет какая-то инфраструктура, связанная с серверами, будет то же самое, только сбоку. Сервера я с OVH уже 2 года назад унес. Важен подход, а у них он просто никакой. Критикал у меня давно на AWS (и там есть ряд проектов, которые просто перестали бы существовать после такого), OVH и Hetzner для всякого нон-критикала, Online.net для тестовых нод. Но даже в случае с теми сервисами, которые были на OVH, потери в раз 15-20 превышают возможную компенсацию, которую они могут произвести.

Во мне сейчас живут хипстер-энтузиаст и реальный клиент с реальными потребностями. Так вот, реальный клиент с реальными потребностями — это клиент другого хостинг-провайдера.
alice2k
Сказано как обычно красиво :)
Но я вот вижу, что ты купил дешевое облако.
Как-то не сходится облако и серьезный аптайм.
Если у тебя такие «реальные» потребности серьезные — почему не покупаешь нормальные дедики?
Дедики всегда стабильнее любых облаков. А если у тебя мощный проект, то можно и 1000 дедиков собрать бюджетных и самому сделать облако.

Я работаю с серьезными проектами.
Так у них например всегда есть запасные планы. Они не верят не одному администратору хостингов или дата-центров. Они не верят вообще не одной компании, а верят только в запасной план. И как раз таки у них есть запасные планы просто простаивающие и пожирающие бабки, потому что потери в случае чего в 20 раз превысят любые компенсации.

Если у тебя все так, как ты рассказываешь, то ты не серьезно отнесся к своим проектам и просто тупо зажал денег. Вот и получил убытки.
RWNET
Они и правда совершенно не торопятся чинить упавшие сервера, причём речь теперь точно о дедиках. Я не могу поверить в то, что сервер лежит уже 4 дня. В поддержку само собой смысла нет писать, хотя можно и новый купить, но не досмотрел и пару файлов мне очень нужно взять. Начинаю жалеть что выбрал OVH.
alice2k
Наверное у тебя ОС сдохла, как в случае с 4 нодами выше.
Переустанавливайся и с бекапа давно бы уже.

ОВХ это самообслуживание.
Если за 1 сутки не поднялось — какой смысл ждать?
RWNET
Если бы так. У меня отвалился KVM доступ, то есть сервер из их панельки даже не ребутит. Я не могу даже систему поставить или глянуть что с ней не так. Без них никак, бэкап не полный на то время был.
alice2k
Наверно сервер сгорел.
У моих клиентов, которые не одной жалобы не написали. Честно не вру.
Тоже сгорали серванты и точно так же были не доступны, не ребутались даже в режим восстановления. Кто-то купил новый. Кто-то сутки ждал и само ожило потом, но он все равно потом купил GRA локацию и переехал.

Тут да, без них никак.
Нет бекапа — только молиться на чудо.
RWNET
GRA далековат по пингу для игровых серверов, пусть и не существенно. Один сервер в SBG восстановили и даже сами мне образ ОС залили для восстановления, там без потерь. Но вот последний остался, теперь жду его.
brightside
В чем заключается самообслуживание? Прилечь на 5 дней? Или надо приехать в SBG, дать подзатыльника обжиматором местным специалистам и зачинить самому все что нужно?
alice2k
В моем понимании самообслуживание — когда ты сам все делаешь и даже тикета не создаешь.
Ну почитай ссылку что я дал.

Если ты не умеешь в самообслуживание — тогда плати тем, кто будет делать что-то за тебя. В РФ например как раз 95% хостеров живут за счет обслуживания и продают в 5 раз дороже, но зато делают все за тебя.
Иногда даже настолько привыкли помогать, что или права в панели урезаны. Или все делается по тикету. К примеру захочу я на сторону кому-ниб продать, буду пол часа еще ответы ждать. А с панелью ОВХ я за 5 минут куплю и выдам клиенту, сам, самообслуживаясь.
brightside
Самообслуживание, это не тогда, когда серверы лежат 5 дней, а все что ты можешь сделать, это сидеть и гореть, ожидая ответа на тикет, написанный 30 часов назад и наслаждаясь сообщениями о том, что инцидент закрыт и все у них понимаешь работает.

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

По дедикам OVH это вообще цирк. Они мне как-то хард меняли в рейде две недели (при том, что у них был аутпут smartctl, на котором все отлично видно), отвечая на тикет по 3 дня. Хостеров, которые продают unmanaged, просто валом. В любого тыкни, и он будет лучше чем OVH. Единственное эксклюзивное, что сегодня может предложить OVH — это vrack и неплохая география, но если на этом поприще у них появятся конкуренты, то бобик быстро сдохнет.
alice2k
Ты путаешь самообслуживание и обслуживание.

Хард меняли? Это — обслуживание.

Сидеть и ждать ответа на тикет — это обслуживание.
alice2k
Просто к слову — в ОВХ не принято «хард менять» :)
Там просто клиент покупает новый сервер, все переносит что нада, а старый не продляется.
И потом уже техник видит что сервер сбойный, меняет детали и снова выставляет на продажу.

Не хочу никого оскорбить, но мне чертовски нравится этот подход самообслуживания.
Это ЦЕХ.
Мне как клиенту, удобнее просто купить новый сервер. Нежели переписываться с чуваками из ДЦ и просить замену и еще «согласовывать время простоя». При покупке нового сервера, я сам все перенесу и простоя не будет вообще.
brightside
ЦЕХ заканчивается там, где начинается SLA. Если у тебя указано интервеншн тайм, надо идти и делать. А если не хочешь делать, напиши «посоны, мы можем по двое суток не отвечать на тикет, но вы все-равно дедики покупайте». У меня полно примеров, когда у них так же и «ЦЕХ» работает. Это вопрос исключительно обязательств, а не того, что принято и не принято.
alice2k
вопрос исключительно обязательств, а не того, что принято и не принято
я понял твою логику
но вероятно ты идеалист просто.

ты говоришь о Теории, а я говорю о Практике.
возможно у тебя тоже есть практика, но практика какой-ниб компании по контракту, где ты админ.
у меня же практика это интернет клиенты. и 100% все эти клиенты — ложили они хуй на SLA, не важно миллионами ли они платят или нет. это реальность. такова реальность. кажется абсурдно, но нет, интернет проекты ложат хуи на гарантии, им дешевле восстанавливаться, ведь они интернет проекты, они не привязаны к офисам и к чему-то еще.

да, конечно я бы на месте ОВХ — написал бы «поддержки нет».
на своих проектах я именно так и пишу :)
действительно, если так посмотреть — ОВХ хвастается тем, чего у нее нет.
твоя логика понятна. клиент вроде тебя ожидает от ОВХ чуда, ведь ОВХ пишет тоже много красивых слов на своих сайтах.

только вот реальность такова — что тот, кто действительно постоянный клиент ОВХ или любой серьезный — он не верит в то что написано на сайтах.
он верит только в опыт продавца, вроде меня. и в собственный опыт быстрого восстановления или свой штат админов.

не один клиент ОВХ, даже тот кто покупает партиями
никогда не задумывается о SLA
таким клиентам, еще раз говорю — проще, дешевле, выгоднее — быстро перейти на резервный план, а он у них есть. и реакция моментальна, там собственные админы 24/7. я вот 2 года с крупняком работаю, 6 штук таких. и сука — только начинается простой, более 20 минут допустим и они уже на резервы «ядро проекта» переводят. потом возвращаются. а возвращаются почему? потому что при их объемах экономия очень даже нехилая получается. 10 евро с сервера экономии, при партии в 1к, это 10к евро или 600 тыщ рублей экономии в месяц. ради такой экономии можно и забить на SLA я думаю.

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

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

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

ладно, закончим ) пойду спать.
я твою логику понял.
но мне, как продавцу и постоянно работающему с кучей запросов клиентов, разных уровней мелкий и крупных — она чужда. потому что от реальности она отличается. для меня это скорее фантастика. таких как ты, кто реально верит в SLA очень мало в мире.
alice2k
Хостеров, которые продают unmanaged, просто валом
поделись. я как раз ищу что-ниб новенькое.

только вот в чем проблема.
все хостеры которые я встречал — у них не было ЦЕХА
я не мог самообслуживаться
и покупать дедики за 5 минут автоматически без тикетов
везде были какие-то косяки с панелью. или косяки с заказами. или косяки с наличием выдавали сутки заказ.
как тут «самообслужишься и перенесешь данные на новый сервер», если ждать выдачу сутки.
alice2k
В чем заключается самообслуживание? Прилечь на 5 дней? Или надо приехать в SBG, дать подзатыльника обжиматором местным специалистам и зачинить самому все что нужно?
в твоем примере.
как поступают люди которые самообслуживаются
5 дней — это значит пиздец пришел серверу
люди просто покупают новый сервер, восстанавливаются с бекапа.
вот так и работает самообслуживание. они не ждут 5 дней, а уже в первый день это делают.
а кто-то сразу спустя час простоя уже делает.
молча, покупают и восстанавливаются.
сами.
не создавая не одного тикета.
вот это и есть самообслуживание. я поступаю именно так. моих клиенты в большинстве своем тоже.
alice2k
тем более IP сети ОВХ как раз легко переносятся с сервера на сервер
купил новый, накатил ОС, восстановился, перенес сетки.
живешь дальше

причин почему сервер сдох может быть много
начиная от кривых рук, заканчивая такими вот авариями.
кривые руки тоже часто ломают. и тот кто не умеет восстанавливаться сам — тот точно не будет клиентом ОВХ, ведь с исправлением кривых настроек ОС ему никто не поможет. ведь там самообслуживание.

тот кто не умеет в самообслуживание — идет покупать куда-то еще :)
где за доп плату включенную в стоимость тарифа ему все сделают.
alice2k
Начинаю жалеть что выбрал OVH
А изначально почему ты его выбрал?
Антиддос? Дешевые цены? Удобство панели?
RWNET
Выгоднее по ценам, чем у прошлого хостера, ну и панель не DCManager, а что-то интереснее и удобнее.

Оставить комментарий