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 и теперь доступна.

План Действий:
Вот план действий, который будет реализован с рекомендацией производителя:

• Две недели назад мы запустили замену контроллеров 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 в двух различных сетях.

Уважаемые клиенты, рады представить вашему вниманию наш новый сервис Admin-Linux.net, который специализируется на администрировании Linux серверов и сопутствующих услугах.
admin-linux.net

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

На данный момент мы предоставляем такие услуги в рамках проекта Admin-Linux.net:

1. 1. Разовые работы. В рамках разовых работ мы готовы выполнить широкий перечень услуг:
• Установка ОС
• Установка и настройка LAMP / LEMP
• Обновление серверного ПО
• Установка панелей управления
• Настройка VPN / Proxy
• Перенос сайтов
• Другие работы по установке и настройке ПО
• Очистка сайтов от вирусов
2. Абонентское обслуживание серверов
3. Продажа лицензий продуктов ISPsystems
4. Продажа SSL сертификатов
5. Регистрация доменных имён

Теперь, с сервисом Admin-Linux, всем желающим круглосуточно доступна техническая поддержка уровня Friendhosting.
С уважением, Friendhosting.net

Выбирайте сервер, а всем остальным займемся мы: произведем монтаж сервера в стойку, установим ОС, подключим Интернет, выделим IP. Количество серверов, участвующих в акции, ограничено.

Просмотреть лучшие предложения
Уже включено в услугу:

• Интернет 100 Мбит/с. с безлимитным трафиком и ip-адресом
• Установка ОС по Вашему выбору
• Удаленное управление сервером IPMI в течении 5 дней
• Бесперебойное питание

rackstore.ru/server-sale.html

Рассылка пострадавшим такого содержания была

Все VPS-ки восстановлены
Компенсация будет позже, все обязательно ее получат.
ОВХ пока что еще не сообщила что она компенсирует. Но я точно 1 месяц бесплатно сделаю в любом случае кто пострадал на моих VPS нодах. Позже.

Хронология аварии
hostsuki.pro/news/sbg-ovh-ves-prileg.html — первый топик
hosting.kitchen/ovh/avariya-s-elektrichestvom-v-sbg.html — потом я писал сюда
hosting.kitchen/ovh/dve-pervye-informacii.html — третий топик
hosting.kitchen/ovh/incident-roubaix.html — четвертый
hosting.kitchen/ovh/teper-vot-dlinnyy-otvet.html — на следующий день уже их ответ
Короче будет активация нового ДЦ SBG3 и закрытие SBG1 и SBG4 которые контейнерный эксперимент был
hostsuki.pro/news/sbg1-sbg4---budut-migrirovany-v-sbg3.html
Так что у кого серверы в SBG1 SBG4 — вероятно в будущем будет еще простой и перенос.

А теперь топик как мы с vova1234 восстанавливали наши 4 ноды что пострадали
vm.center/2017/11/public-nodes-vm-center/otchet-o-4-nodah-centos-7-vmmanager-ovh-sbg2-09-11-2017.html
Кто хочет сказать ему спасибо сюда

We’re excited to announce that Spaces is now available in Amsterdam, providing scalable Object Storage to nearby regions!

You can now create a Space in AMS3 in two clicks using the drag-and-drop UI or API, and instantly have object storage that scales automatically, works with S3-compatible tools, and requires minimal configuration or management.

Pricing for Spaces is $5 per month and includes 250 GB of storage and 1 TB of outbound data transfer per month from any data center with Spaces deployed (currently NYC3 and AMS3). Inbound data transfer for uploading is free. Additional bandwidth is available at $0.01 per GB of data transfer, and additional storage is $0.02 per GB stored.
blog.digitalocean.com/introducing-spaces-object-storage/

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 по нашим контрактам.

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

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.

Мы начинаем продажи виртуальных серверов на собственной площадке в Таллине — администрируемые серверы с конфигурацией 4 GB памяти. 40 GB диск и 500 GB включенный трафик с подключением 100 Мбит в секунду. Мы предоставляем специальную цену — 11 долларов за месяц аренды которая действует до 11.11.2017.
www.vkusno.ee/cart.php?a=confproduct&i=0

Всем, кому требуется более мощный сервер, рады напомнить: специальная акция на серверы во Франции и Германии продолжается. Сервер с конфигурацией AMD Opteron, 2x2Tb HDD, 16Gb RAM, 4 IPs, 100mbit безлимитный канал за 48 долларов.

Обратите внимание!

• У вас интересный проект? Дадим под него выделенный или виртуальным сервер бесплатно и поможем с настройкой.
• Возникают проблемы с сервером. приобретенным в другой компании? Наши системные администраторы помогут по демократичным ценам в любое время дня. Нет времени регистрироваться? Напишите напрямую в live chat и дежурный сотрудник проконсультирует по дальнейшим действиям.
• Вашей компании требуется постоянный аутсорс и не хватает свободных рук? У нас есть специалисты различной квалификации под любой вид работ. Обратитесь за консультацией в live chat сегодня.
• Хотите работать у нас или имеется партнерское предложение? Наш управляющий будет рад пообщаться с вами в рабочие часы без выходных по почте info@vkusno.ee

Команда инженеров Infobox запустила новый высокопроизводительный хостинг сайтов:

• переработала и упростила архитектуру хостинга, снизив задержки в работе сайтов
• использовала новейшие серверы с высокочастотными процессорами до 3.7 ГГц и самыми быстрыми дисками SAS SSD 12Gbit/s
• развернула полностью новую панель управления хостингом на технологиях Plesk
• внедрила процесс непрерывного мониторинга конкурирующих решений для предоставления услуги постоянно лучшего качества.

Архитектура нового хостинга
За долгие годы размещения более 300 000 клиентов мы попробовали несколько различных архитектур:

• Веб-серверы с общими базами данных (1 сервер баз данных на несколько веб-серверов)
• Кластерное решение (сетевые хранилища, веб-ноды обрабатывающие запросы и балансировщики перед ними)

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

Производительность
12GB/s SSD
На хост-серверах мы используем SSD-диски enterprise–уровня с пропускной способностью 12Gb/s, что позволяет нам обрабатывать запросы к клиентским сайтам ещё быстрее, чем на обычных SSD 6Gb/s. Особенно данное ускорение ощущается при работе с базами данных.
По нашим тестам, произвольная запись на этих дисках до 2х раз быстрее SSD 6Gb/s и в сотни раз быстрее обычных HDD дисков.

Высокочастотные процессоры 3.4 Ггц (Turbo Boost до 3.7 Ггц)
Процессор больше не будет узким горлышком для вашего сайта — высокая частота ядер существенно ускоряет выполнение скриптов и запросов к базе данных.

Работа с сессиями php redis без блокировок
Мы переписали phpredis модуль и теперь предоставляем всем клиентам возможность безопасной работы с сессиями без блокировок, redis доступен на всех тарифах без дополнительной платы.

Непрерывное сравнение производительности с конкурентами
Внутри компании написана и развернута система мониторинга быстродействия сайтов на платформах конкурентов. Мониторинг снимает показатели CPU / FS / MYSQL и среднюю скорость загрузки сайта. Мы следим за основными конкурентами и предоставляем действительно «Самый быстрый» php-хостинг.


Изоляция от других пользователей
На веб-серверах используется последняя версия CloudLinux, ограничение ресурсов клиентов осуществляется с помощью технологии LVE. Сама суть ограничений не в том, чтобы заставить клиента с большой нагрузкой перейти на VPS, а в защите клиентов от значительного увеличения потребления ресурсов соседствующих сайтов. Сейчас, на все сайты установлено ограничение в 2Гб RAM (фактическое потребление памяти) и 500% CPU (пять физических ядер сервера).

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

Резервное копирование
Все данные клиентских сайтов ежедневно резервируются на бекап-серверы. Удобные инструменты восстановления сайтов и баз из созданных копий доступны в панели управления. Также не выходя из панели управления, вы можете настроить резервное копирование на любой удалённый FTP сервер.

Возможности
В обновленном Linux–хостинге всего один тариф – 99 рублей в месяц за первый сайт и 49 рублей в месяц за каждый дополнительный. Мы уже включили максимально возможную для используемого оборудования скидку в ежемесячную плату.

Заказчик может приобрести ровно столько сайтов, сколько необходимо, не переплачивая за лишнее.
В тариф входит:

• 1 сайт / 1 БД / FTP-доступ
• 5 Гб места на диске SSD 12GB/s
• Автоустановщик 200+ CMS
• Бесплатный SSL–сертификат (Lets Encrypt конечно же)
• Резервное копирование без дополнительной оплаты.
• Круглосуточная поддержка 24х7х365

Нагрузочное тестирование
Для теста использовался реальный развернутый сайт на Joomla с контентом. Проверялась устойчивость до 200 запросов в секунду одновременно. Распределение времени отклика вы можете видеть ниже (Яндекс.Танк):


Промо-код на бесплатный месяц хостинга: e515644543e39366b1f3ef1ff

Ждем ваших отзывов на partners@infobox.ru. За полезные отзывы будем дарить дополнительный бесплатный месяц. Полезный отзыв — это рассказ нам об ошибке или проблеме, либо конструктивное предложение, как что-то сделать удобнее и лучше для вас. Нам не все равно.
Если все отлично — можете рассказать, какой проект разместили и какие ваши задачи он успешно решает.

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

Сегодня утром у нас было два отдельных инцидента, которые не имеют никакого отношения друг к другу. Первый инцидент затрагивает наш сайт в Страсбурге (SBG) и второй Roubaix (RBX). На SBG мы имеем 3 центра обработки данных и 1 в стадии строительства. На RBX мы имеем 7 центров обработки данных.

SBG:
На SBG у нас была электрическая проблема. Питание восстановлено, а службы перезапускаются. Некоторые клиенты UP, а другие пока нет.
Если ваш сервис еще не UP, время восстановления составляет от 5 минут до 3-4 часов. Наша система мониторинга позволяет нам узнать, какой клиент по-прежнему влияет, и мы работаем над их устранением.

RBX:
У нас возникла проблема в оптической сети, которая позволяет RBX подключаться к точкам соединения, которые мы имеем в Париже, Франкфурте, Амстердаме, Лондоне, Брюсселе. Источником проблемы является программная ошибка на оптическом оборудовании, которая привела к потере конфигурации и разрешению соединения с нашим сайтом RBX. Мы передали резервную копию конфигурации программного обеспечения, как только мы диагностировали источник проблемы, и DC снова доступен. Инцидент на RBX закрыт. С производителем мы ищем происхождение ошибки программного обеспечения, а также как избежать такого критического инцидента.

Мы находимся в процессе получения данных, чтобы предоставить вам информацию о времени восстановления SBG для всех служб / клиентов. Кроме того, мы дадим все технические подробности о происхождении этих двух инцидентов.

Мы искренне сожалеем. Мы только что испытали 2 одновременных и независимых события, которые повлияли на всех клиентов RBX с 8:15 до 10:37 и всех клиентов SBG с 7:15 до 11:15. Мы продолжаем работать над клиентами, которые еще не UP в SBG.

travaux.ovh.net/vms/index_sbg1.html
travaux.ovh.net/vms/index_sbg2.html
travaux.ovh.net/vms/index_sbg4.html