VM.center

История еще не завершилась и думаю еще пара недель уйдет на все это.
Следить за новостями можно тут
hosting.kitchen/ovh/datacenter-sbg.html



Итого, VM-ы которые сгорели. Или может быть потом что-то и восстановится посмотрим.

На данный момент считаем их погибшими.

Ryzen 7 SBG2 [VM-5]


i7-6700k SBG2 [VM-5]


i7-6700k SBG2 [VM-6]

Днем 23/06/2019 сдохла нода3 из GRA2 узлов.
Оказалось сотрудник ОВХ хотел что-то обновить в CPU дырках intel

Stable kernel, hz1000 — 64bit (includes up-to-date intel microcodes)

Но убил ОС
И сбросил ее типо ОС должна быть исправлена заказчиком.


Пришлось восстанавливать



Пришлось переустанавливать ОС с нуля и накатывать из бекапа.
Копирование данных. 21-23 00-40, т.е почти 3 часа выкачивали



Пол часа переустановка ОС, настройка узла.
И восстановление. 02-33, 03-39, копирование оказалось быстрее.



Итого на все про все ушло. 8 часов :) Закладывали 10.

Вообщем с утра обнаружили что нода почему-то не работает.
Сервер был куплен в октябре 2016 года — работал без единного косяка.
И самое интересное там было Debian 7


Поэтому мы подумали — обновы пришли — херят Debian как и обещали.

Админ проснулся, посмотрел.
Говорит обновы ISPsystem зависли.
Обновили там вручную, все равно не поднимается.
Написал в ISP поддержку, те обновили конфиг и панель вроде заработала.
Но перестали работать IP

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


Пришлось потратить несколько часов на доказывания саппорту, что письма не летят у нас в спам.
И что реально не приходит письмо с данными от режима восстановления.
И он в принципе не запускается. Все равно доступ идет до сервера. Хотя в панели пишет режим спасения.
Короче баганулся там сервер. А может изначально такой был, просто мы не проверяли после покупки работает ли вообще там Режим Спасения.


Еле как короче за 2 часа времени доказали, что мы не лохи и не далбоебы, что мы не тупые и ничего в спаме у нас нету.
И тогда саппорт запросил «диагностику»


Я уже к тому времени подумал — а не восстановить ли всех в другом месте.
Но из-за того что там были SATA диски и каждая доля по 100 200 400 гектар — долго все качать.
Решил подождать.

В итоге разбирали проблему.
Что-то там про обновы сначала разговор пошел, что оно делает /dev/root вместо /dev/sda1
Типо из-за этого все испортилось. Типо подумали что Дебианы убивают и списывают их в утиль.

Но короче по факту — не понятно.
Поддержка ISP тоже не особо помогла.
Ждать ее времени уже не было, день уже кончался. Весь день пришлось заниматься этой нодой, вместо других планов.

Не дожила нода :) Она уже давно архивная была. И я думал будет жить пока не сгорит. Но нет, пришлось таки ее на CentOS 7 переделывать.
И заодно сделали ей Атом отдельный.
Эта нода была одна из первых, из 2016 года, тогда как раз Польский ДЦ только запускался в Октябре как раз, были куплены 2 сервера на пробу одни из первых, и решили пустить их под VPS как раз.
Атомы для панели мы придумали только в 2017 году уже методом тестов и опытов. Поэтому там не было технического атома. Возможно именно из-за этого все и похерилось поэтому вместе с обновами.

Надеюсь ОВХ в будущем будет продавать 1245 процессоры в Польше. Иначе растратно держать технический атом, ради 2х архивных серверов, которые уже давно не продаются даже такие.

Начали качать БЕКАПЫ
И ТУТ НАЧАЛОСЬ :)
Короче сервер начал сам перезагружаться.
Даже бекапы оттуда выкачать не удавалось.
Как оказалось, все таки в этот раз обновы ISP кажется не были виноваты. Просто они не завершились нормально из-за процессора который сгорел.
Пошел снова процесс тупых тикетов с поддержкой ОВХ.
В итоге смогли доказать саппорту, что с CPU что-то не так.
Его заменили. На все это ушло еще часа 4.



Проблема была обнаружена в 10 утра :)
Но только в 23:30 мы приступили к нормальному почину.
Потом всю ночь что-то качалось.
И в 12-40 следующего дня — все запустилось уже.


Потери составили — 1 заказ CentOS — там был дополнительный IP, поэтому сеть что-то кривит.
Ждем клиента пока он скажет свой пароль, чтобы можно было сеть поднять самим. Все остальное запустилось само.
// обновили, короче дело оказалось в MAC адресе, Vova1234 починил; Мак мы делали на тест, когда диагностировали почему сетка не работала на сервере.

И еще нас ждет так же «переделка узла №2» из Debian 7 на CentOS 7.
Сейчас тот узел работает как-то сам, без управления вообще.
Нужно его тоже бекапнуть и в новую панель на Атоме затолкать узлом №2.
// Готово, сделали за 2 часа.

[TICKET#0118326990] OVH Monitoring (20:54)

Our monitoring system has just detected a fault on your server ns3365126.ip-37-187-75.eu.
The fault was noticed on 2018-02-04 14:50:09
Our team of technicians on site (operational 24/7), has been informed
of the fault and will intervene on your machine.
Please be aware that other interventions may currently be in progress and
an intervention lasts on average 30 minutes per machine.
We are therefore not able to give you more details on the starting time
of the intervention.
You can see a general display of the machines currently in fault and
in intervention across our network at the following address: status.ovh.ie/vms/
Your server is in rack G111A17
You will receive an email as soon as a technician takes charge of your
server. Meanwhile, you have can reboot it via your manager.
Logs:
—
PING ns3365126.ip-37-187-75.eu (37.187.75.20) from 213.186.33.13: 56(84) bytes of data.
From 213.186.33.13: Destination Host Unreachable
From 213.186.33.13: Destination Host Unreachable
From 213.186.33.13: Destination Host Unreachable
— 37.187.75.20 ping statistics —
10 packets transmitted, 0 packets received, +6 errors, 100% packet loss
---------------------

Пошли смотреть в чем дело.
Оказалось



Время простоя — 45 минут



[TICKET#4258299994] Operation Network connector finished (21:41)

The intervention on ns3365126.ip-37-187-75.eu has been completed.
This operation was closed at 2018-02-04 15:41:04 CET (UTC +01:00)
Here are the details of this operation:

• Network connector

Date 2018-02-04 15:00:06 CET (UTC +01:00), kevin H made Network connector:
Operation details:

• Your server was inaccessible from the network due to a network issue.
• Here's the task linked to this incident: travaux.ovh.net/?do=details&id=29730

Action and result:

• No intervention was made on the server.
• The server is booted on disk and is on the login screen. Ping OK and services are up.?