Статьи про VMmanager
  • Дата создания
    10 июля 2017
  • Топиков
    31
  • Ограничение на постинг
    0.000
  • Категория:
    Панели

История VM на базе [VMmanager 5 KVM 2017-2020 годы by кошелек alice2k]

Много истории вы уже можете видеть на портале vm.center
vm.center/blog/vmmanager/
vm.center/blog/qa-vmmanager/
Но так же есть серия топиков, честных.
И хочу чтобы они были всем доступны тоже. Поэтому скопирую, чтобы потом не искать. Вряд-ли уже напишу новые топики про VM-5, поэтому одним постом обобщаю опыт для потомков.


Но зато мы неплохо прокачали скидку ISPsystem.
И десятки хостеров были настроены нами :)
Абсолютно бесплатно!
Мы ввели в стандарт подобные «честные доли». И именно после нас все остальные начали делать VM на десктоп процессорах, т.к. мы доказали, что они работают не хуже чем энтерпрайз.
Нашу идею кто только не скопировал.

И даже VMmanager 6 — стала делать панель для модели «на базе аренда дедик ОВХ где сетка на каждом узле своя». То что мы мучались в VM-5 — было решено в VM-6.

Но это уже, совершенно другая история, про которую я напишу еще через пару лет. В историю.

bomj.cloud - 300р за узел в бесконечное облако кластеров


Кто хочет присоединиться к one-panel?
  • 1 узел/нода 300р/мес
go@bomj.cloud пишите

Была статья про VMmanager 5, теперь вот тоже самое но на VMmanager 6, еще проще, еще дешевле.

В 2020 идеальные конфиги — Райзен 7 ОВХ, Райзен 9 у 1dedic.ru и Epyc у Хетзнера.

Обновление логотипа

Как было

Как стало


Раньше когда меняешь цвет панели — favicon тоже менялся.

Тем самым в браузере когда у тебя 10 дата-центров и локаций открыто с узлами — можно было легко переключиться на нужный и сэкономить время.

Но теперь все они стали идентичные.
И теперь тратится лишние 10 секунд чтобы нащелкать и найти нужную вкладку.


Обновления выпускал человек который сам не пользовался панелью!

Обновление VMmanager KVM от [5.136.0] до 5.142.0

Короче, было замечено, что часть нод — не обновилось само.
И застряло на VMmanager KVM 5.136.0

Те, которые Дебиан — гладко обновились до 5.142.0

А вот те, которые как обычно Хваленная Расхваленная CentOS 7
21:01 - Vova1234: Could not create lock at /var/run/yum.pid: [Errno 28] No space left on device
21:02 - Vova1234: места нет
21:02 - Vova1234: tmpfs           1.9G  1.9G     0 100% /run

  1. Место какое-то кончилось.
  2. Начали копать о чем речь.
Я сначала подумал это на нодах — думаю, ебать нужно ноды с клиентами ребутать теперь. А это опасно. Да и вообще не айс ребутать рабочих клиентов.
Другие же хостеры как-то обходятся без ребута.
Начал уточнять у админа.

В итоге оказалось, что речь идет именно о серверах, где стоит сама VMmanager KVM — а у нас как вы знаете, т.к. я предусмотрительный человек — под панель выделены Атомы дешевые специально. (про Атомы тут и вот пример наглядно как это меня спасло)
Ребутнуть атом — не проблема.

  • Итого — после ребута временные файлы вычищались и все потом обновлялось само.
  • И узлы которые прикреплены в Атоме уже, сами ноды — так же потом начинали обновляться до последней версии 5.142.0.

Мне стало интересно, почему только 2 ГБ ?
Начали проверять разные серверы. Там где под панель был сервер с 16 озу i5-2400 допустим — там раздел tmpfs был 8 ГБ почему-то, а вот на Атоме — именно 2 ГБ.

Подумали сначала что это SWAP.
Но нет, swap если верить «информация о системе» из VMmanager у нас либо 4096, либо другие значения, но никак не 2 ГБ.

Например был сервер, где swap писало 32 ГБ
Но разметка там была
Filesystem      Size  Used Avail Use% Mounted on
rootfs          1.8T  728G  999G  43% /
/dev/root       1.8T  728G  999G  43% /
devtmpfs         32G     0   32G   0% /dev
tmpfs           6.3G  444K  6.3G   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            19G     0   19G   0% /dev/shm
root@gra:~#
Так что это явно не swap никакой. И как вообще создается этот раздел — не понятно. Почему где-то 2, где-то 4, где-то 6, а где-то 8?

Так что этот вопрос мы так и не поняли, почему вдруг оно забилось, и почему именно на Атоме с 4 озу — такой размер. А на других серверах другой размер. Он как-то сам автоматически наверно делается, в зависимости от сервера? ОС наверно смотрит на мощу сервера и выделяет оптимальное что-то.

Если кто-то знает — в комменты.

22:35 — alice2k: 1,5 часа обновляли
22:35 — Vova1234: еще
22:35 — Vova1234: нет
22:35 — Vova1234: 2 осталось
22:35 — alice2k: ну эти уже мелочи
22:35 — alice2k: угу
22:35 — Vova1234: атомы долго обновляются

update
решение
mount -o remount,size=10G /run

Просто в честные отчеты

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

Зависают.


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


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

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

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

[Новость для хостеров] 50% на VMmanager

У нас в рамках ABCD Team | HostSuki имеются технические домены.

1245.ovh
1650.ovh
i7k.ovh
i9k.ovh
i7-4790k.ovh
i7-6700k.ovh i7-6700k.ru
i7-7700k.ovh i7-7700k.ru
i7-8700k.ovh i7-8700k.ru
i9-9900k.ovh i9-9900k.ru
xeon-e5.ovh
e5-26xx.ovh
w35.ovh
w21.ovh
i5x.ovh
i7x.ovh
i9x.ovh
i9k.ovh
xeon-d.ovh
xeon-w.ovh
xeon-b.ovh
xeon-s.ovh
xeon-g.ovh
xeon-p.ovh
xeon-e.ovh
noda.ovh
ispm.ovh
storage.ovh
hdd-vps.ovh
nvme.ovh
gpu.ovh
epyc.ovh
ryzen.ovh
windows-vm.ovh
hdd-vps.ovh

Вы можете добавлять свои серверы в эту удобную и красивую сортировку. Если процессоры другие — купим еще доменов ;)
И использовать уже наши панели, наш бренд, наши советы и даже бесплатную/платную помощь админа.
И получать 50% скидку на оплату узла VMmanager :) Да, это правда. Уже к существующей скидке.


[обновление VMmanager KVM 5.124.0] [или все тоже 122 ?]

Очередной топик про неудавшиеся обновления 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 за обновление, отлично наши бабки расходуются.


[Архив] публикаций о VMmanager из других блогов

Не вижу смысла копировать.
Тем более скоро будет v6 уже.
Да и Дебиан не поддерживается.

Короче старые топики устареют через 2 года.
Но История важна.

2017

2016

2015

2014

2013

[обновление VMmanager KVM 5.122.0]

Решил так же документировать все баги и косяки 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 часа щас восстанавливать ноду.