VM.center

Трудно сказать связано ли это с обновлениями или нет.
Но 30/11/2017
И вот 01/12/2017
Некоторые ноды на CentOS зависают.
Не важно CentOS-6 ли это или CentOS-7

Зависают.


Не перезагружаются. Создается авто-тикет сотруднику ДЦ, что перезагрузка не удалась.


И потом вручную техник похоже что-то чинит и ребутает уже.

Так что вот, еще одно честное — падение.
От 15 до 40 минут простоя.
Причины — не известны.

В логах смотрели.
Сначала показалось что каких-то пакетов не хватало, поэтому зависло.
Потом админ сказал что больше похоже на панику ядра.

Очередной топик про неудавшиеся обновления VMmanager KVM

Итак.
Почему-то сервер с панелью VMmanager обновился до 5.124
А вот «узлы» не обновились. Примечательно то, что узел был более старый чем 122 версия. Так что возможно это все тот же косяк 122 обновления.
Написал админу, чтобы он вручную запустил.

И получили

[root@ns3061009 ~]# yum update
Loaded plugins: fastestmirror
Existing lock /var/run/yum.pid: another copy is running as pid 306.
Another app is currently holding the yum lock; waiting for it to exit...
  The other application is: yum
    Memory : 131 M RSS (1.5 GB VSZ)
    Started: Wed Sep 27 20:40:10 2017 - 02:01 ago
    State  : Sleeping, pid: 306

После этого сервер не вышел из ребута.
Только 15 минут «он пытался ребутнутся»


Далее, снова начали копировать файлы виртуалок.
В этот раз оказалось больше. Полностью заполненный сервер.


Спустя 30 минут после кривого обновления VMmanager
Только приступили к копированию, потому что не все так просто.
Потому что в этот раз решили использовать локальный бекап дата-центра, где скорость выше. Чтобы не копировать файлы по интернету. А у дата-центров такие бекапы слишком тупы и доступ туда только с IP сервера. Поэтому админу потребовалось 15 минут чтобы поднять VPN там для начала и пошло копирование.

Как и предположил alice2k — скорость качалова — в 10 раз возросла сразу.



Заметьте — если бы я не продумал систему с «отдельным атомом для панели». В топике ссылка с комментарием «итоговый пост 2017»

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


Далее короче скопировали все дампы
Переустановили ОС на узле.
Снова добавили узел в атом с панелью VMmanager
Вручную восстановили пользователям их заказы.

Часа 2 дрочили с восстановлением.
В западло еще сервер тормозить стал, потому что там слишком много винды было. А винда как вы знаете устанавливается оч долго.
Короче админ уже уснул к тому времени.
А по факту в итоге целую ночь будет качаться эта винда. Так как особенность винды еще в том, что нужно с нуля установиться ей. А только потом восстановление с бекапа. С линуксом можно например запустить создание VPS и остановить тут же, потом заменить файлы на диске и включить VPS. А с виндой — остановка не работает и нужно дождаться по 40 минут пока это дерьмо установится.

Все таки винда на ноде — дело не благородное. И даже честные доли наверно перестают быть честными при таком загрузе.

Итого простой составил

• 1-45 ночи
• 12-00 — думаю завтра утром, потом подправлю

Не одного косяка или падения за год как мы создаем VPS. Только если не обновление ISPsystem. Может и правда лучше не покупать обновлений и просто работает пусть до самого конца, пока не сгорит? А потом когда сгорит просто уже восстановиться на новом сервере, свежем.
Возможно стоит рассмотреть вариант без узлов и просто тупо оставлять ноды жить на автопилотах и пусть работают без обновлений.

Спасибо тебе ISPsystem за обновление, отлично наши бабки расходуются.

Решил так же документировать все баги и косяки ISPsystem.
За 1 год работы мы конечно намучались с ними нехило. При том, что это самые невыгодные панели, если делать всего на 16 долей. Но это единственное что есть на рынке. Плюс понадобилось очень много лет, пока наконец-то интернет-админы научились работать с VMmanager.

И сколько вот я наблюдаю за рынком. Постоянно куча жалоб, как рабочая, с трудом созданная система — портится после обновлений, платных чуваки обновлений. Платишь за то, чтобы тебе разрушили систему.

Итак. На текущий момент мы имеем нод(list.skladchik.ovh) и куча вечных лицензий с узлами, продленными до 2022-2023 года (фишка короче в том, что сначала покупаешь лицуху, потом продляешь обновления на 5-10-20 лет, а потом уже докупаешь узлы, и сколько бы узлов не стало, лицуха уже продлена, а если продлять лицуху потом, то она считает продление от кол-ва узлов)
Как видите их графика — ноды есть на Дебиан 7 старые. И на CentOS 7 уже новые. Так как оказалось, что Дебиан 8 они типо не поддерживают и там всегда все в говно работает.
Но и на CentOS7 не лучше. Но конечно получше чем на Дебиане.

Пришло обновление.


Везде перестали устанавливаться ОС

Притом какие-то ноды обновились нормально, какие-то нет, большинство после ребута(дада, пришлось ребутать ноду, а значит падение на 5 минут как минимум) ожили и обновление VMmanager завершилось удачно. А вот одна нода, почему-то не запустилась.

Можно видеть как потом 2 часа ушло на копирование бекапа. А считай что это — уже день насмарку. И мы платим деньги за эти обновления парни.



В итоге всего 5 долей пострадало. Но все равно — не приятно.
Что бы было, если бы вместо моей безопасной системы, из первой ссылки FAQ которая, и минимальными рисками по 16 долей, была бы например нода на 256 долей или целое облако. И оно потом так внезапно сдохло само? Был бы топик тогда, как VMmanager убивает хостинги.

4 часа ушло только на копирование.
И еще 3 часа щас восстанавливать ноду.