Теперь вот длинный ответ
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 с технологией, основанной на транспортных контейнерах, мы не смогли подготовить сайт для крупномасштабного проекта.
Мы допустили две ошибки:
Технология, основанная на транспортных контейнерах, использовалась только для сборки SBG1 и SBG4. На самом деле мы поняли, что контейнерный центр обработки данных не соответствует требованиям нашей торговли. На основе темпов роста SBG минимальный размер сайта должен быть равен нескольким центрам обработки данных и, следовательно, иметь общую емкость 200 000 серверов. Вот почему сегодня для развертывания нового датацентра мы используем только два типа конструкций, которые были широко протестированы и спланированы для крупномасштабных проектов и надежности:
Даже если этот утренний инцидент был вызван сторонним автоматом, мы не можем отрицать свою ответственность за провал. У нас есть кое-что, что нужно сделать для SBG, чтобы достичь того же уровня стандартов, что и другие OVH-сайты.
В течение дня мы приняли следующий план действий:
Это инвестиционный план в размере 4-5 миллионов евро, который мы запускаем завтра, и надеемся, что мы сможем восстановить доверие наших клиентов к SBG и OVH.
Наши команды по-прежнему трудно на работе, чтобы восстановить услуги последний из затронутых клиентов. Как только инцидент будет полностью разрешен, мы применим SLA по нашим контрактам.
Мы очень сожалеем об этом инциденте, и мы благодарим доверие, которое вы оказываете нам.
Сегодня утром в 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 с технологией, основанной на транспортных контейнерах, мы не смогли подготовить сайт для крупномасштабного проекта.
Мы допустили две ошибки:
- Мы не сделали сайт SBG совместимым с внутренними стандартами, для которых требуется 2 отдельных электропитания 20 кВ, как и все наши места постоянного тока, которые оснащены двумя электрическими каналами. Это крупные инвестиции в размере от 2 до 3 миллионов евро за электрическую подачу, но мы считаем, что это часть нашего внутреннего стандарта.
- Мы построили энергосистему SBG2, поместив ее в энергосистему SBG1 вместо того, чтобы сделать их независимыми друг от друга, как и во всех наших центрах обработки данных. В OVH каждый номер центра данных указывает, что силовая сеть не зависит от других датацентров. Где угодно, кроме сайта SBG.
Технология, основанная на транспортных контейнерах, использовалась только для сборки SBG1 и SBG4. На самом деле мы поняли, что контейнерный центр обработки данных не соответствует требованиям нашей торговли. На основе темпов роста SBG минимальный размер сайта должен быть равен нескольким центрам обработки данных и, следовательно, иметь общую емкость 200 000 серверов. Вот почему сегодня для развертывания нового датацентра мы используем только два типа конструкций, которые были широко протестированы и спланированы для крупномасштабных проектов и надежности:
- строительство 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 серверов.
Даже если этот утренний инцидент был вызван сторонним автоматом, мы не можем отрицать свою ответственность за провал. У нас есть кое-что, что нужно сделать для SBG, чтобы достичь того же уровня стандартов, что и другие OVH-сайты.
В течение дня мы приняли следующий план действий:
- установка второго, полностью отдельного электрического питания 20MVA;
- разделение силовой сети SBG2 от SBG1 / SBG4, а также отделение будущего SBG3 от SBG2 и SBG1 / SBG4;
- миграция клиентов SBG1 / SBG4 в SBG3;
- закрытие SBG1 / SBG4 и удаление транспортных контейнеров.
Это инвестиционный план в размере 4-5 миллионов евро, который мы запускаем завтра, и надеемся, что мы сможем восстановить доверие наших клиентов к SBG и OVH.
Наши команды по-прежнему трудно на работе, чтобы восстановить услуги последний из затронутых клиентов. Как только инцидент будет полностью разрешен, мы применим SLA по нашим контрактам.
Мы очень сожалеем об этом инциденте, и мы благодарим доверие, которое вы оказываете нам.
35 комментариев
hosting.kitchen/ovh/incident-roubaix.html
hosting.kitchen/ovh/esche-summarno-pro-dc-roubaix.html
не RBX1 — а весь RBX1 — RBX6
SBG — они все свалили на неправильную архитектуру электропитания при постройке ДЦ из контейнеров — именно поэтому решили переезжать из контейнеров SBG1 SBG4 в полноценные постройки SBG2 SBG3(который щас строится как раз и завершается).
А в RBX — это проблема сети была
При этом они пытаются убедить общественность, что это «your issues with setup» и сейчас судя по всему вообще не торопятся, потому что максимальная компенсация в рамках инцидента по SLA не может составлять более ежемесячной стоимости того, что было affected. А если для людей, которых волнует бесперебойная работа их сервисов — то это вообще смерть OVH как public cloud провайдера. Конечно, это unmanaged cloud и все это понимают, но он должен не может быть настолько нестабилен.
Окончательно ситуацию усугубляет их подход и нескончаемое вранье, которое прозрачностью никак не назовешь
честно.
все что было куплено у меня — а у меня не мало ресурсов закуплено. и облако их тоже закуплено было.
все поднялось.
не один мой клиент не написал негативного отзыва.
только вот VMmanager не поднялось 4 ноды
vm.center/2017/11/public-nodes-vm-center/otchet-o-4-nodah-centos-7-vmmanager-ovh-sbg2-09-11-2017.html
с нуля пришлось восстанавливать с бекапов
я тебе не верю потому что. SBG3 — не запущен еще и я точно это знаю.
у них там в облаке — шараж мантаж
тупые сотрудники, прожирающие бабки в офисе — локации не правильно прописали
там есть и GRA3 тоже ) которого не существует.
я думал ты о дедиках говоришь
убогим облаком с "ежемесячными счетами" — не пользуемся
пользуемся только нормальным облаком, которое
www.ovh.ie/vps/vps-ssd.xml
www.ovh.ie/vps/vps-cloud.xml
www.ovh.ie/vps/vps-cloud-ram.xml
там тупой сотрудник вместо LIM1 прописал DE
сука
все знают что новый ДЦ в германии называется LIM1
а он не знает, но работает в офисе на зар плате
и никто, даже сами ОВХ не знают о этом просто )
они не врут тебе, они просто не мониторят это дело. это другая инфраструктура.
а отрапортавали они — про дедики и нормальные VPS-ки.
Во мне сейчас живут хипстер-энтузиаст и реальный клиент с реальными потребностями. Так вот, реальный клиент с реальными потребностями — это клиент другого хостинг-провайдера.
Но я вот вижу, что ты купил дешевое облако.
Как-то не сходится облако и серьезный аптайм.
Если у тебя такие «реальные» потребности серьезные — почему не покупаешь нормальные дедики?
Дедики всегда стабильнее любых облаков. А если у тебя мощный проект, то можно и 1000 дедиков собрать бюджетных и самому сделать облако.
Я работаю с серьезными проектами.
Так у них например всегда есть запасные планы. Они не верят не одному администратору хостингов или дата-центров. Они не верят вообще не одной компании, а верят только в запасной план. И как раз таки у них есть запасные планы просто простаивающие и пожирающие бабки, потому что потери в случае чего в 20 раз превысят любые компенсации.
Если у тебя все так, как ты рассказываешь, то ты не серьезно отнесся к своим проектам и просто тупо зажал денег. Вот и получил убытки.
Переустанавливайся и с бекапа давно бы уже.
ОВХ это самообслуживание.
Если за 1 сутки не поднялось — какой смысл ждать?
У моих клиентов, которые не одной жалобы не написали. Честно не вру.
Тоже сгорали серванты и точно так же были не доступны, не ребутались даже в режим восстановления. Кто-то купил новый. Кто-то сутки ждал и само ожило потом, но он все равно потом купил GRA локацию и переехал.
Тут да, без них никак.
Нет бекапа — только молиться на чудо.
Ну почитай ссылку что я дал.
Если ты не умеешь в самообслуживание — тогда плати тем, кто будет делать что-то за тебя. В РФ например как раз 95% хостеров живут за счет обслуживания и продают в 5 раз дороже, но зато делают все за тебя.
Иногда даже настолько привыкли помогать, что или права в панели урезаны. Или все делается по тикету. К примеру захочу я на сторону кому-ниб продать, буду пол часа еще ответы ждать. А с панелью ОВХ я за 5 минут куплю и выдам клиенту, сам, самообслуживаясь.
Самообслуживание, это когда хостер предоставил тебе все необходимые средства и инструменты, чтобы ты мог это самообслуживание осуществлять и самостоятельно поддерживать свою инфраструктуру, когда он своевременно устраняет неполадки в своей зоне ответственности.
По дедикам OVH это вообще цирк. Они мне как-то хард меняли в рейде две недели (при том, что у них был аутпут smartctl, на котором все отлично видно), отвечая на тикет по 3 дня. Хостеров, которые продают unmanaged, просто валом. В любого тыкни, и он будет лучше чем OVH. Единственное эксклюзивное, что сегодня может предложить OVH — это vrack и неплохая география, но если на этом поприще у них появятся конкуренты, то бобик быстро сдохнет.
Хард меняли? Это — обслуживание.
Сидеть и ждать ответа на тикет — это обслуживание.
Там просто клиент покупает новый сервер, все переносит что нада, а старый не продляется.
И потом уже техник видит что сервер сбойный, меняет детали и снова выставляет на продажу.
Не хочу никого оскорбить, но мне чертовски нравится этот подход самообслуживания.
Это ЦЕХ.
Мне как клиенту, удобнее просто купить новый сервер. Нежели переписываться с чуваками из ДЦ и просить замену и еще «согласовывать время простоя». При покупке нового сервера, я сам все перенесу и простоя не будет вообще.
но вероятно ты идеалист просто.
ты говоришь о Теории, а я говорю о Практике.
возможно у тебя тоже есть практика, но практика какой-ниб компании по контракту, где ты админ.
у меня же практика это интернет клиенты. и 100% все эти клиенты — ложили они хуй на SLA, не важно миллионами ли они платят или нет. это реальность. такова реальность. кажется абсурдно, но нет, интернет проекты ложат хуи на гарантии, им дешевле восстанавливаться, ведь они интернет проекты, они не привязаны к офисам и к чему-то еще.
да, конечно я бы на месте ОВХ — написал бы «поддержки нет».
на своих проектах я именно так и пишу :)
действительно, если так посмотреть — ОВХ хвастается тем, чего у нее нет.
твоя логика понятна. клиент вроде тебя ожидает от ОВХ чуда, ведь ОВХ пишет тоже много красивых слов на своих сайтах.
только вот реальность такова — что тот, кто действительно постоянный клиент ОВХ или любой серьезный — он не верит в то что написано на сайтах.
он верит только в опыт продавца, вроде меня. и в собственный опыт быстрого восстановления или свой штат админов.
не один клиент ОВХ, даже тот кто покупает партиями
никогда не задумывается о SLA
таким клиентам, еще раз говорю — проще, дешевле, выгоднее — быстро перейти на резервный план, а он у них есть. и реакция моментальна, там собственные админы 24/7. я вот 2 года с крупняком работаю, 6 штук таких. и сука — только начинается простой, более 20 минут допустим и они уже на резервы «ядро проекта» переводят. потом возвращаются. а возвращаются почему? потому что при их объемах экономия очень даже нехилая получается. 10 евро с сервера экономии, при партии в 1к, это 10к евро или 600 тыщ рублей экономии в месяц. ради такой экономии можно и забить на SLA я думаю.
хотя я думаю они и к другим компаниям относятся так же.
не встречал еще людей, которые реально верили был в гарантии. гарантии может просить только тот, кто по безналу работает или по контракту, чтобы через суд потом возмещаться. это просто тролли судебные. но не серьезные проекты. серьезные проекты не занимаются подобной чушью, как поиск SLA или выпрашивание SLA — они просто делают перенос и запасной план. переписка с ДЦ — обходится им дороже. или там тратить кучу времени на SLA — это тоже самое.
можешь мне не верить, но не один реально крупный проект — никогда не просит гарантий. его больше беспокоит сам продавец вроде меня, можно ли мне верить или нет, и мой характер и отношение к тем или иным вещам в жизни, нежели дата-центр и его гарантии.
например смотри, такие клиенты не верят «наемным админам» хостеров с поддержкой. и чертовски боятся этой бесплатной поддержки по SLA, думают что они там будут тырить их данные. ну причин много. поэтому они обращаются ко мне, а не к компании какой-то, где безымянный штат админов имеет доступы. им проще верить в одного человека, но который публичная личность и уже годами показал свое отношение к тем или иным вещам.
ладно, закончим ) пойду спать.
я твою логику понял.
но мне, как продавцу и постоянно работающему с кучей запросов клиентов, разных уровней мелкий и крупных — она чужда. потому что от реальности она отличается. для меня это скорее фантастика. таких как ты, кто реально верит в SLA очень мало в мире.
только вот в чем проблема.
все хостеры которые я встречал — у них не было ЦЕХА
я не мог самообслуживаться
и покупать дедики за 5 минут автоматически без тикетов
везде были какие-то косяки с панелью. или косяки с заказами. или косяки с наличием выдавали сутки заказ.
как тут «самообслужишься и перенесешь данные на новый сервер», если ждать выдачу сутки.
Антиддос? Дешевые цены? Удобство панели?
SBG2 сгорел, дотла. F.
Вставка изображения
Оставить комментарий