EU-Central (Strasbourg,FR)
EU-Central (Strasbourg,FR): the external source (20MVA) was broken here, it's fixed.
все новости по филиалам
Поиск
US-West (Hillsboro,OR)
US-West (Hillsboro,OR): building phase 1… work in progress…
U-West (Gravelines,FR)
U-West (Gravelines,FR): work in progress to build a new elec source 40MVA based on 225kV + 80kV
SLA Information – November 9 incident Roubaix (RBX)
On Thursday November 9, some of your services were affected by a network incident in our French site, in Roubaix (RBX). We would like to extend our sincerest apologies.
Flagged at 8:01am (French time), the incident was declared closed by our teams at 10:34am (French time). You were unable to access your services during this time.
All of your services are now working again, and we are here to answer any questions which you may have regarding your products.
We are well aware of the consequences of this service interruption, and we will, of course, be activating the planned compensation for products which are contractually bound by an SLA. As a reminder, you can find all the SLA levels pertaining to your products, in the customer control panel. You can view all compensation details via this link.
тут-адрес-панели/billing/sla/
The causes of this incident are still being analyzed, and we have already taken some measures which will further strengthen the reliability of our services, even in the most unexpected situations.
You can find additional information about the event and the resulting actions here. Rest assured that we are doing everything to learn from each new situation encountered, to further improve our service availability. We will keep you informed of the implementation of these measures.
We are very sorry for the inconvenience this incident may have caused, and would like to reiterate our sincerest apologies.
Regards, The OVH team
от редакции
по русски написано ТУТ
Flagged at 8:01am (French time), the incident was declared closed by our teams at 10:34am (French time). You were unable to access your services during this time.
All of your services are now working again, and we are here to answer any questions which you may have regarding your products.
We are well aware of the consequences of this service interruption, and we will, of course, be activating the planned compensation for products which are contractually bound by an SLA. As a reminder, you can find all the SLA levels pertaining to your products, in the customer control panel. You can view all compensation details via this link.
тут-адрес-панели/billing/sla/
The causes of this incident are still being analyzed, and we have already taken some measures which will further strengthen the reliability of our services, even in the most unexpected situations.
You can find additional information about the event and the resulting actions here. Rest assured that we are doing everything to learn from each new situation encountered, to further improve our service availability. We will keep you informed of the implementation of these measures.
We are very sorry for the inconvenience this incident may have caused, and would like to reiterate our sincerest apologies.
Regards, The OVH team
от редакции
по русски написано ТУТ
SLA OVH по инциденту RBX - 4 дня бесплатно
Подробнее написано в этом топике
hostsuki.pro/all/kak-poluchit-kompensaciyu-sla-ovh.html
Я щас буду все письма и сотню аккаунтов разгребать.
А потом уже в биллингах всех уведомлю. И на 4 дня даты изменю.
hostsuki.pro/all/kak-poluchit-kompensaciyu-sla-ovh.html
Я щас буду все письма и сотню аккаунтов разгребать.
А потом уже в биллингах всех уведомлю. И на 4 дня даты изменю.
Les cellules haute tension 20kV de SBG1
Les cellules haute tension 20kV de SBG1 avec les cellules motorisées et l'automate NSM qui n'a pas marché
Les groupes électrogènes de SBG1 (2x2MVA), SBG2 (2x1.4MVA) et SBG3 (2x1.4MVA)
Еще суммарно про DC Roubaix
travaux.ovh.net/?do=details&id=28244
Краткое описание инцидента:
8h00: все ссылки 100G на DC Roubaix не работают.
8h15: невозможно подключиться к узлу
8h40: Мы перезапускаем главный кадр электрически.
9:00 утра: узел все еще недоступен.
9:15 утра: мы отказываемся от узла управления.
9:30 утра: Мы восстанавливаем контроль над Рубе.
9h40: Мы можем видеть все кадры, но на кадре нет тревоги, и конфигурация схемы исчезла.
10h00: Мы добавляем последнюю резервную копию базы данных на узле
10h15: схемы снова начинают подниматься
10h30: Большинство схем подняты, 8 все еще
11:00: Некоторые транспондеры не могут быть обнаружены системой, а усилитель неисправен, запускается RMA усилителя.
11h30: Мы сбросили все приемоответчики, не распознанные, все схемы подняты
14h15: Замена усилителя завершена
14h30: все схемы вставлены, функциональные защиты и последние тревоги были деградированы.
Объяснение:
Согласно журналам, собранным из всех кадров узла Roubaix (20), кажется, что у нас было три отдельных события, каскадирующих на узле Roubaix:
1. Перегрузка процессора узла (главный кадр)
Каждый оптический узел имеет главный кадр, который позволяет обмениваться информацией между узлами и обмениваться со своими подчиненными кадрами. На этом главном кадре база данных сохраняется на двух картах контроллера, а также на ЖК-дисплее.
С 7:50 а. м., мы заметили, что Roubaix начинает испытывать проблемы связи с узлами, напрямую связанными с ним, и показывает перегрузку ЦП на главном кадре. На сегодняшний день мы не уверены, что вызвало перегрузку процессора. Несмотря на то, что SBG раньше, мы смотрим на все возможные причины. Команды производителя все еще следят за этой причиной. Мы запланировали звонок в субботу, 11 ноября, чтобы узнать больше о первопричине.
2. Переключение каскадов
После перегрузки процессора узел, главный кадр сделал переключение плат контроллера. После первого переключения контроллеров и перегрузки процессора мы столкнулись с известной ошибкой программного обеспечения Cisco. Эта ошибка происходит на больших узлах и приводит к переключению контроллеров, которое происходит каждые 30 секунд. Обычно это переключение стабилизируется. Эта ошибка будет полностью исправлена выпуском 10.8, который будет доступен 31 ноября.
3. Потеря базы данных
В 8 часов утра, после события переключения каскада, мы столкнулись с другой ошибкой программного обеспечения, которая де-синхронизирует синхронизацию между двумя картами контроллера основного кадра. Эта ошибка вызвала команду, отправленную на карту заказа контроллера, чтобы установить базу данных на 0. Контроллеры главных кадров отправили эту новую информацию в рамы Slaves и потеряли все ссылки 100G из Roubaix. Эта ошибка исправлена в версии 10.7 и теперь доступна.
План Действий:
Вот план действий, который будет реализован с рекомендацией производителя:
Резюме:
Стратегия потенциального разделения:
Можно полностью разделить сеть на 2 полностью независимых сети на уровне управления (всегда с возможностью повторного разбиения узлов внутри каждой сети). Благодаря «умному» красно-синему распределению оптических линий между двумя сетями каждый постоянный ток может достигать каждого POP в двух различных сетях.
Краткое описание инцидента:
8h00: все ссылки 100G на DC Roubaix не работают.
8h15: невозможно подключиться к узлу
8h40: Мы перезапускаем главный кадр электрически.
9:00 утра: узел все еще недоступен.
9:15 утра: мы отказываемся от узла управления.
9:30 утра: Мы восстанавливаем контроль над Рубе.
9h40: Мы можем видеть все кадры, но на кадре нет тревоги, и конфигурация схемы исчезла.
10h00: Мы добавляем последнюю резервную копию базы данных на узле
10h15: схемы снова начинают подниматься
10h30: Большинство схем подняты, 8 все еще
11:00: Некоторые транспондеры не могут быть обнаружены системой, а усилитель неисправен, запускается RMA усилителя.
11h30: Мы сбросили все приемоответчики, не распознанные, все схемы подняты
14h15: Замена усилителя завершена
14h30: все схемы вставлены, функциональные защиты и последние тревоги были деградированы.
Объяснение:
Согласно журналам, собранным из всех кадров узла Roubaix (20), кажется, что у нас было три отдельных события, каскадирующих на узле Roubaix:
1. Перегрузка процессора узла (главный кадр)
Каждый оптический узел имеет главный кадр, который позволяет обмениваться информацией между узлами и обмениваться со своими подчиненными кадрами. На этом главном кадре база данных сохраняется на двух картах контроллера, а также на ЖК-дисплее.
С 7:50 а. м., мы заметили, что Roubaix начинает испытывать проблемы связи с узлами, напрямую связанными с ним, и показывает перегрузку ЦП на главном кадре. На сегодняшний день мы не уверены, что вызвало перегрузку процессора. Несмотря на то, что SBG раньше, мы смотрим на все возможные причины. Команды производителя все еще следят за этой причиной. Мы запланировали звонок в субботу, 11 ноября, чтобы узнать больше о первопричине.
2. Переключение каскадов
После перегрузки процессора узел, главный кадр сделал переключение плат контроллера. После первого переключения контроллеров и перегрузки процессора мы столкнулись с известной ошибкой программного обеспечения Cisco. Эта ошибка происходит на больших узлах и приводит к переключению контроллеров, которое происходит каждые 30 секунд. Обычно это переключение стабилизируется. Эта ошибка будет полностью исправлена выпуском 10.8, который будет доступен 31 ноября.
3. Потеря базы данных
В 8 часов утра, после события переключения каскада, мы столкнулись с другой ошибкой программного обеспечения, которая де-синхронизирует синхронизацию между двумя картами контроллера основного кадра. Эта ошибка вызвала команду, отправленную на карту заказа контроллера, чтобы установить базу данных на 0. Контроллеры главных кадров отправили эту новую информацию в рамы Slaves и потеряли все ссылки 100G из Roubaix. Эта ошибка исправлена в версии 10.7 и теперь доступна.
План Действий:
Вот план действий, который будет реализован с рекомендацией производителя:
- Две недели назад мы запустили замену контроллеров Roubaix и Gravelines с помощью TNCS (вместо TNCE), в результате чего вдвое увеличилась мощность процессора и удвоила оперативную память. Мы получили первые 2 вчера для Roubaix, и мы сделаем своп как можно скорее после проверки процесса с производителем. Мы собираемся подтолкнуть замену контроллеров на узлах Страсбурга и Франкфурта.
- Мы сейчас нажимаем обновление программного обеспечения на всех узлах, чтобы перейти на 10.8
- Теперь мы используем версию 10.5.2.6, мы должны пройти промежуточную версию 10.5.2.7, чтобы иметь возможность перейти в 10.7 или 10.8 после этого.
- Мы разделим большие узлы (POP / DC) на наличие как минимум 2 контроллеров узлов на POP / DC
Резюме:
- Шаг 1: Замена TNCE на RBX / GRA (ETA: понедельник, 13 ноября, вечер для RBX, вторник, 14 ноября, вечер для GRA)
- Шаг 2: Обновление программного обеспечения в 10.8 (возможно ETA: 4 недели)
- Шаг 3: Разделение больших узлов (ETA: TBA. Необходимо определить правильную стратегию и установить точный протокол, а затем работать над дорожной картой)
Стратегия потенциального разделения:
Можно полностью разделить сеть на 2 полностью независимых сети на уровне управления (всегда с возможностью повторного разбиения узлов внутри каждой сети). Благодаря «умному» красно-синему распределению оптических линий между двумя сетями каждый постоянный ток может достигать каждого POP в двух различных сетях.
400 серверов меняли детали
travaux.ovh.net/?do=details&id=28242
There are still ~2000 ips that are still down on multiple hosts. Tech in DC working on it.
travaux.ovh.net/?do=details&id=28247
— pci / vps
64 hosts with
1000 VPS/PCI
no issue on ceph
A technician manages about 25 heavy interventions per day. With 400 issues to solve, the calculation is simple: we need between 15 to 25 technicians to complete the incident. That's why the teams take turns since yesterday noon thanks to the staff who arrived from the others DCs. OneTeam
У нас осталось чуть меньше 400 серверов. У нас есть все типы аппаратных проблем с этими серверами, и мы заменяем их к концу дня.
12-11-2017
There are still ~2000 ips that are still down on multiple hosts. Tech in DC working on it.
travaux.ovh.net/?do=details&id=28247
— pci / vps
64 hosts with
1000 VPS/PCI
no issue on ceph
A technician manages about 25 heavy interventions per day. With 400 issues to solve, the calculation is simple: we need between 15 to 25 technicians to complete the incident. That's why the teams take turns since yesterday noon thanks to the staff who arrived from the others DCs. OneTeam
У нас осталось чуть меньше 400 серверов. У нас есть все типы аппаратных проблем с этими серверами, и мы заменяем их к концу дня.
12-11-2017
- PCI/VPS: there is 10 hosts that has to be reparted. the host is very complex and we need 1H per host.
- Servers (SYS/OVH) We have 200 serveurs that the hardware issues that we are working on.
Incident Roubaix
travaux.ovh.net/?do=details&id=28244
Сегодня утром у нас был инцидент в оптической сети, которая соединяет наш сайт Roubaix (RBX) с 6 из 33 пунктов присутствия (POP) нашей сети: Paris (TH2 и GSW), Франкфурт (FRA), Амстердам (AMS ), Лондон (LDN), Брюссель (BRU).
Сайт RBX подключается через 6 оптических волокон к этим 6 СОЗ: 2x RBX <> BRU, 2x RBX <> LDN, 2x RBX <> Paris (1x RBX <> TH2 и 1x RBX <> GSW). Эти 6 оптических волокон соединены с системами оптических узлов, которые позволяют иметь 80 длин волн 100 Гбит / с на каждом оптическом волокне.
Для каждого 100G, подключенного к маршрутизаторам, мы используем 2 оптических пути, которые географически различны. В случае обрезки оптического волокна, знаменитый «удар назад», система переконфигурируется в 50 мс, и все ссылки остаются в UP. Чтобы подключить RBX к POP, мы имеем емкость 4,4 Тбит / с, 44x100G: 12x100G до Парижа, 8x100G до Лондона, 2x100G до Брюсселя, 8x100G до Амстердама, 10x100G до Франкфурта, 2x100G до DC GRA и 2x100G до DC SBG.
В 8:01 все 100G-ссылки, 44x100G, были потеряны. Учитывая систему резервирования, которую мы создали, корень проблемы не может быть физическим отключением 6 оптических волокон одновременно. Мы не смогли выполнить диагностику удаленного шасси, поскольку интерфейсы управления были исправлены. Нам пришлось вмешаться непосредственно в комнаты маршрутизации, чтобы манипулировать шасси: отсоедините кабели между корпусом и перезапустите систему и, наконец, выполните диагностику с производителем оборудования. Попытки перезагрузить систему потребовали много времени, потому что для каждого шасси требуется от 10 до 12 минут для загрузки. Это основная причина продолжительности инцидента.
Диагностика: все используемые нами карты транспондеров, ncs2k-400g-lk9, ncs2k-200g-cklc, находятся в состоянии ожидания. Одним из возможных источников такого состояния является потеря конфигурации. Таким образом, мы восстановили резервную копию и вернули конфигурацию, которая позволила системе перенастроить все карточки транспондеров. 100G в маршрутизаторах вернулись естественным образом, и связь RBX с 6 POP была восстановлена в 10:34.
Это явно ошибка программного обеспечения на оптическом оборудовании. База данных с конфигурацией сохраняется 3 раза и копируется в 2 контрольные карты. Несмотря на всю эту безопасность, база исчезла. Мы будем работать с OEM, чтобы найти источник проблемы и помочь исправить ошибку. Мы не ставим под сомнение доверие у производителя оборудования, даже если этот тип ошибок особенно важен. Время безотказной работы — это вопрос дизайна, который учитывает все случаи, в том числе когда ничего не работает. Режим параноида в Ovh должен быть продвинут еще во всех наших проектах.
Ошибки могут существовать, инциденты, которые влияют на наших клиентов, нет. В Ovh обязательно есть ошибка, поскольку, несмотря на все инвестиции в сеть, волокна, технологии, у нас просто есть 2 часа простоя всей нашей инфраструктуры в Рубе.
Одним из решений является создание двух систем оптических узлов вместо одного. 2, что означает 2 базы данных, и поэтому в случае потери конфигурации только одна система не работает. Если 50% ссылок проходит через одну из систем, сегодня мы потеряли бы 50% емкости, но не 100% ссылок. Это один из проектов, которые мы начали 1 месяц назад, было заказано шасси, и мы получим их в ближайшие дни. Мы можем начать работу по настройке и миграции за 2 недели. Учитывая сегодняшний инцидент, этот проект становится приоритетом для всех наших инфраструктур, всех DC, всех СОЗ.
В сфере предоставления облачных инфраструктур остаются только те, которые являются параноидальными. Качество обслуживания является следствием 2-х элементов. Все ожидаемые инциденты «по дизайну». И инциденты, которые мы узнали из наших ошибок. Этот инцидент приводит нас к тому, чтобы поднять планку еще выше, чтобы приблизиться к нулевому риску.
Мы искренне сожалеем о пропуске 2H33 минут на сайте RBX. В ближайшие дни, пострадавшие клиенты получат электронное письмо, чтобы инициировать обязательства SLA.
Сегодня утром у нас был инцидент в оптической сети, которая соединяет наш сайт Roubaix (RBX) с 6 из 33 пунктов присутствия (POP) нашей сети: Paris (TH2 и GSW), Франкфурт (FRA), Амстердам (AMS ), Лондон (LDN), Брюссель (BRU).
Сайт RBX подключается через 6 оптических волокон к этим 6 СОЗ: 2x RBX <> BRU, 2x RBX <> LDN, 2x RBX <> Paris (1x RBX <> TH2 и 1x RBX <> GSW). Эти 6 оптических волокон соединены с системами оптических узлов, которые позволяют иметь 80 длин волн 100 Гбит / с на каждом оптическом волокне.
Для каждого 100G, подключенного к маршрутизаторам, мы используем 2 оптических пути, которые географически различны. В случае обрезки оптического волокна, знаменитый «удар назад», система переконфигурируется в 50 мс, и все ссылки остаются в UP. Чтобы подключить RBX к POP, мы имеем емкость 4,4 Тбит / с, 44x100G: 12x100G до Парижа, 8x100G до Лондона, 2x100G до Брюсселя, 8x100G до Амстердама, 10x100G до Франкфурта, 2x100G до DC GRA и 2x100G до DC SBG.
В 8:01 все 100G-ссылки, 44x100G, были потеряны. Учитывая систему резервирования, которую мы создали, корень проблемы не может быть физическим отключением 6 оптических волокон одновременно. Мы не смогли выполнить диагностику удаленного шасси, поскольку интерфейсы управления были исправлены. Нам пришлось вмешаться непосредственно в комнаты маршрутизации, чтобы манипулировать шасси: отсоедините кабели между корпусом и перезапустите систему и, наконец, выполните диагностику с производителем оборудования. Попытки перезагрузить систему потребовали много времени, потому что для каждого шасси требуется от 10 до 12 минут для загрузки. Это основная причина продолжительности инцидента.
Диагностика: все используемые нами карты транспондеров, ncs2k-400g-lk9, ncs2k-200g-cklc, находятся в состоянии ожидания. Одним из возможных источников такого состояния является потеря конфигурации. Таким образом, мы восстановили резервную копию и вернули конфигурацию, которая позволила системе перенастроить все карточки транспондеров. 100G в маршрутизаторах вернулись естественным образом, и связь RBX с 6 POP была восстановлена в 10:34.
Это явно ошибка программного обеспечения на оптическом оборудовании. База данных с конфигурацией сохраняется 3 раза и копируется в 2 контрольные карты. Несмотря на всю эту безопасность, база исчезла. Мы будем работать с OEM, чтобы найти источник проблемы и помочь исправить ошибку. Мы не ставим под сомнение доверие у производителя оборудования, даже если этот тип ошибок особенно важен. Время безотказной работы — это вопрос дизайна, который учитывает все случаи, в том числе когда ничего не работает. Режим параноида в Ovh должен быть продвинут еще во всех наших проектах.
Ошибки могут существовать, инциденты, которые влияют на наших клиентов, нет. В Ovh обязательно есть ошибка, поскольку, несмотря на все инвестиции в сеть, волокна, технологии, у нас просто есть 2 часа простоя всей нашей инфраструктуры в Рубе.
Одним из решений является создание двух систем оптических узлов вместо одного. 2, что означает 2 базы данных, и поэтому в случае потери конфигурации только одна система не работает. Если 50% ссылок проходит через одну из систем, сегодня мы потеряли бы 50% емкости, но не 100% ссылок. Это один из проектов, которые мы начали 1 месяц назад, было заказано шасси, и мы получим их в ближайшие дни. Мы можем начать работу по настройке и миграции за 2 недели. Учитывая сегодняшний инцидент, этот проект становится приоритетом для всех наших инфраструктур, всех DC, всех СОЗ.
В сфере предоставления облачных инфраструктур остаются только те, которые являются параноидальными. Качество обслуживания является следствием 2-х элементов. Все ожидаемые инциденты «по дизайну». И инциденты, которые мы узнали из наших ошибок. Этот инцидент приводит нас к тому, чтобы поднять планку еще выше, чтобы приблизиться к нулевому риску.
Мы искренне сожалеем о пропуске 2H33 минут на сайте RBX. В ближайшие дни, пострадавшие клиенты получат электронное письмо, чтобы инициировать обязательства SLA.