VM.center

Вообщем с утра обнаружили что нода почему-то не работает.
Сервер был куплен в октябре 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 часа.

2.rbx.noda.ovh/vemgr
Еще одна тестовая нода из 2016 года.
Это был конфиг
Xeon W3520 / 32 ddr3 / 2x 300 SSD
list.skladchik.ovh (искать файл за 2016 год)
Май 2018 — закрывается

Сначала VMmanager KVM никто не мог настроить — года 2-3 так.
Даже платные админы не умели.
Потом наконец-то наша вонь по интернету добилась своего. Некоторые люди настроили за 5000р
И процесс пошел в массы. Пошли продажи. Нам стали писать другие админы и стали просить помочь настроить эту панель. И даже хостеры и даже с SE люди писали с репутацией. Никто не умел настраивать короче. Благодаря нашей статье десяток хостингов точно научился делать VPS и теперь продает.

Так вот, сначала мы конечно же пробовали на OpenVZ, т.к. KVM не настраивалось.
Потом OpenVZ ноды отобрали у нас runabove (кстати весь проект на 200к начинался с OVZ runabove как раз; история была такова, я увидел супер дешевые runabove и подумал, а давайте все таки куплю в очередной раз говно панель VMnanager и попробуем запилить складчину, так и понеслось)
И еще вот остался апендикс — W3520

• Во первых оказалось, что процессор слабоват.
• Во вторых оказалось, на OpenVZ нельзя установить Windows
• Ну и в третьих — он не вписывается в красивую архитектуру.

Поэтому еще для истории

• Тоже была на Debian
• Тоже не одного падения не было.

Все клиенты — перенесены на i7-6700k теперь.
Так и не сгорела сама по себе.

В будущем конечно же OpenVZ делать вообще не планируем. Да и ISPsystem ее вроде поддерживать не собираются даже.

В самом начале, когда мы еще делали ноды на Debian 7
Были собраны 4 сервера тестовых.
Первый с 120 диском
Второй на 16 озу проверка, как оно
Третий на 240 диск, какие потом стали делаться с SSD
Четвертый стандарт с sata дисками, какие потом стали популярны для винды

На этом портале нету заметок про эту ноду.

Так вот, конфиг с 16 озу — оказался апендиксом.
Точно так же как конфиг с 120 ssd — не пригоден из-за нехватки места вечного, даже шаблоны ОС постоянно засирают там все.

И сегодня нода2 — закрывается.
Для истории.
list.skladchik.ovh (искать файл за 2016 год)





На Дебиане — не одного падения не было!
Не то, что на ЦентОС

Что делать с Дебиан нодами — мы пока не решили.
Но очевидно, что либо пока не сгорят. Либо до последнего клиента, перенос на новые и закрытие.


Скорее всего вообще, любые наши ноды — будут работать пока не сгорят.
Переходить на VMmanager 6 когда он там родится в 2019 возможно — не планируем.
К 2020 — надеюсь на рынке появятся более достойные альтернативы, панели, конфиги серверов более мощные. И уже на новых конфигах с нуля будем делать по умному архитектуру. Я не любитель портить готовую архитектуру. А у VMmanager v5 как мы знаем — лучшее это вариант с узлами и Атомами оказался. И мне нравится эта архитектура, поганить ее я не хочу. Пусть живет пока не сгорит. А новую — будем уже пробовать и тестировать на новом, с новыми подходами.

[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.?

CentOS и VMmanager — постоянно зависают от любого косяка. Даже просто от обновления Vmmanager падает и не запускается.
Debian же всегда поднимается, но разработчик ISPsystem не умеет поддерживать Debian для VMmanager. Такие вот дела.

А на рынке альтернативы нет.
Хотя будущее за панелью, которая будет поддерживаться уже непосредственно разработчиком панели. Либо дата-центром и его штатом админов и программистов.
Когда панель, облачная, станет именно не просто софтом каким-то, а целым сервисом/биллингом по подписке. Куда все будут добавлять свои мощности и резать VPS.

Тот кто сделает это быстрее всех — заберет себе весь рынок бюджетных VPS.

Итак, как мы знаем — была авария с электричеством в SBG дата-центрах OVH.
И конечно же все серверы с Debian — поднялись без проблем.
А вот CentOS — сдохла.


Написали в этот в поддержку ISPsystem — на что получили ответ.


Было решено — восстанавливать как обычно, самим. Можно было еще вчера начать, но думали может просто косяк и серверы еще не подняли. Но потом когда ОВХ сбросило их в режимы восстановления, стало понятно, что ОС пришел пиздец.
21:18 — старт копирования.



Интересно то, что 4 ноды сдохли.
А вот 5-ая почему-то нет :) Возможно потому-что она была самая свежая и версия centos была чуть другая например, ведь шаблоны ОС тоже постоянно меняются? А может быть потому что она была полу-пустая. Трудно сказать короче — почему.

Но факт есть факт. CentOS с VMmanager KVM — само умерло и не запустилось. Просто из-за того, что сервер отключился аварийно. А все серверы Debian 7, 8, 9 на 100% — поднялись и не заметили даже косяков. Серверы с VMmanager правда были в меньшинстве, остальные были просто Дебианы с ISPmanager или играми какими-ниб, но даже меньшинство серверов vmmanager поднялось без единого косяка.

Трудно сказать короче что лучше, что хуже.
В нашем деле — нужно уметь готовить продукты из различных говен и выпускать в продакшен. Не привыкать :) Сколько себя знаю — всегда только из говна и делал. И делал удачно, что специалистам которые считают что они работают с идеальными технологиями — всегда припекало и они горели, что кто-то из говна лепит более удачно, чем они.

Итак понеслось.

Публичная статистика под что у нас покупают VPS-ки

И как именно работают ноды. (мы и сами не знаем как, хорошие ли это показатели или нет)

Итак, хоть ноды мы пилим с лета 2016 года.
А летом 2017 был создан vm.center проект и отдельный биллинг.
Ну кому нужно будет — почитает историю, очень много топиков где все рассказано. Щас не буду тут ссылки кидать и засорять.

Итак.
Как вы уже знаете — мы и сами не знаем что мы создали.
И никакого мониторинга у нас нету. Мы вообще без профессионализма подходим к этому делу.
Как я уже сказал — не было бы панели VMmanager — мы бы даже разрезать серверы не смогли :)
Дада, припекает уже наверно кому-то, какому-ниб специалисту, который гордится своими умениями и кластеризацией или умением работать с докерами, или там что он в офисах получает копейку и покупает серверы только за счет бюджета работодателя, а свои собственные жмотит потратить. Припекает наверно от того, что наши доли могут сами работать на автопилотах, и что клиенты даже не жалуются на качество, хотя качества мы не какого и не гарантировали. У нас только чернь банится, только тогда Око Саурона начинает смотреть на VPS-ки Фродо и безжалостно банить. Я чувствую как у хостеров, считающих себя специалистами уже горит. Как горит от того, что «школьники из интернета» могут обслуживать проекты крупного размаха, а они специалисты не могут в одиночку даже.

Ну да ладно :) Ради того чтобы припекало — мы и создаем свои честные проекты.
Мы не боимся поделиться опытом. Любые знания полученные тестами и опытом — тут же выкладываются в паблик. Мы не собираемся этими знаниями зарабатывать в деньги и не храним их как зеницу ока.

Короче.
Мы создали проекты даже — и понятия не имеем — какая нагрузка для «доли» — должна быть.
Оптимальная ли нагрузка или это вредитель который пакостит соседям.

По идее панель VMmanager должна сама определять и выдавать информацию, как она считает, на основе тысяч и десятков тысяч показателей что она собрала с нод всех всех хостеров, которые ее используют.
И методом машинного обучения говорить уже — нода заполнена, не рекомендуется больше садить.
Вот будущее панелей и облаков :) Сказал alice2k ;)

Ну так вот, примеры для истории. [list.skladchik.ovh]
Возможно кто-ниб в комментариях даже скажет — нормальные ли это показатели или не нормальные.

noda1 gra1.1245.ovh