VM.center

Опять самая первая нода.
Про нее уже было
Вот реально — если нода куплен проблемной — это будет всегда на протяжении всей жизни заказа hetzner

Короче зависла нода.
Все как обычно — перезагрузка не помогает.
Пишем на ручную перезагрузку сотрудником.
Но в этот раз даже сотрудник не справился с задачей. И сервер все равно не ожил.
Хотя ответ пришел что он перезагрузил.


Пришлось создавать еще один тикет.
И через пол часа вдруг ожил.


Целый час даунтайма.

Самопроизвольно завис


Сервер просто 2 дня работал и сразу начал сбоить


Сделали отказ.
Написали текст

Короче как только мы ее купили. Нам продали 64 озу вместо 128 озу.
В 2020 году еще мы переписывались с ДЦ и они там потом починили.

Но в 2021 снова произошло это дело.
Поэтому простой ноды — вот публичный отчет. Около часа валялась.





После починки

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



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

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

Ryzen 7 SBG2 [VM-5]


i7-6700k SBG2 [VM-5]


i7-6700k SBG2 [VM-6]

Хоть они и заявляют о стабильности, но на 2021 год — пока что это не так.


За 2020 было проделано много работы, что-то стало лучше, что-то стало хуже.
Например хуже стало то, что при создании кластера нельзя теперь указать настройки для него, например выставить лимит на канал, в итоге все ВМ создаются без ограничений и потом приходится вручную уже всем настраивать после создания ВМ. А раньше эта функция бралась из создания кластера, просто когда его создашь там указывалось.
А лучше стало наверно то, что больше функционала, все таки Март 2020, Апрель 2020 и Ноябрь 2020 — это небо и земля.

Короче по каким-то причинам часть узлов стала писаться якобы проблемы на узле.
Но узлы работали и ВМ на них работали.
Хотя в панели показывался статус что ВМ отключена и не работает.

Ради теста я перезагрузил 1 узел, он перестал писаться с ошибками. Но зато ВМ-ки на нем перестали работать.

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

И до сих пор пока что проблема не исправлена.
Пишут что утечка ОЗУ, хотя сама панель их показывает что 2 ГБ в запасе.


Вероятно эта проблема случилась после обновления
Версия 6.15.0 VMmanager KVM 6


На VMmanager 5 — были похожие проблемы ранее.

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

Так вот, короче я перезагрузил 1 узел — и он сдох.
И вот всем кто пострадал на этом узле — 1 месяц бесплатно :)

Вот этим чувакам.

И в публичные отчеты честности для истории.
Дата подачи заявки о проблеме панели.

2021-02-05 15:39:27

Но восстановлен узел был только.

2021-02-06 19:48:21

Почти 24 часа короче.
Такие вот дела. Извиняюсь хоть это и не косяк хостера.

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

• Как я хотел сделать красиво, но не получилось — октябрь 2020
• Но вот я делал просто от балды, абсолютно убыточные услуги 2016-2019 годы
• Захотелось потратить денег — январь 2020
• Есть ли будущее у VM ? — ноябрь 2019
• Увеличить продажи VM — апрель 2019
• Публичный отчет №2 — март 2019
• Куда развивать виртуальные услуги? № 3 — январь 2019
• Куда развивать виртуальные услуги? № 2 — сент 2018
• Куда развивать виртуальные услуги ? — май 2018
• Небольшой отчет о виртуальном — март 2018
• В НГ писался отчет (в низу вывод о VPS за 2017, статья 2016 оказалась правдой)
• VDS — list.skladchik.ovh — август 2017
• Решил создать свои ТРЕШ вдс-ки — май 2017
• Свободные доли VMmanager — май 2017
• Vmmnager — вчера убили весь день — июнь 2017
• Как услуги деграданты убивают людей — январь 2017

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

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

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

• Первый был летом 2018 -SSD Total Bytes Written
• Второй был весной 2019 — SMART отчет №2
• Третий был август 2020 — SMART отчет №3

А теперь я решил глянуть HDD ноды, которые в raid, и которые мы давно не делаем уже, т.к. тариф не особо интересный был. Чисто остатки прошлого висят.

noda1 — 43790 часов — 0 ошибок
noda2 — 51440 часов — 0 ошибок
noda3 — 56165 часов — 0 ошибок (6 лет)
noda4 — 48623 часов — 0 ошибок
noda5 — 30930 часов — 0 ошибок
noda6 — 16306 часов — 0 ошибок
noda7 — 42814 часов — 0 ошибок
noda8 — 51034 часов — 0 ошибок
noda9 — 48798 часов — 0 ошибок

Как так? Даже HDD диски — не сгорают у нас!

Первый был летом 2018
SSD Total Bytes Written

Второй был весной 2019
SMART отчет №2

Третий отчет. Лето 2020.
У нас так и не сгорел не один диск.
За эти годы я успел уже закрыть кучу нод из-за старых процессоров.
За эти годы я уже придумал новые тарифные модели.
За эти годы я уже успел разочароваться в дешевой аудитории.
Но — у нас так и не сгорел не один диск. Я так и не увидел собственными глазами как они сгорят ;(

SBG i7-6700k
noda1 — закрыли ее уже, сделали перенос на VM-6
noda2 — 295425295251 357302316667 — 137.57 TB 166.38 TB — 0 ошибок
noda3 — закрыли ее уже, сделали перенос на VM-6
noda4 — закрыли ее уже, сделали перенос на VM-6
noda5 — закрыли ее уже, сделали перенос на VM-6
noda6 — закрыли ее уже, сделали перенос на VM-6
noda7 — появилась новая нода, 231009455557 — 107.57 TB — 0 ошибок
noda8 — появилась новая нода, 133745752064 — 62.28 TB — 0 ошибок
noda01 2016 — закрыли ее уже цены 2016 отличаются от цен соврменности, сделали перенос на Райзен
noda02 2016 — закрыли ее уже цены 2016 отличаются от цен соврменности, сделали перенос на Райзен

GRA i7-6700k
noda1 — закрыли ее уже, сделали перенос на VM-6
noda2 — 53503605961 212621713408 — 24.91 TB 99.01 TB — 0 ошибок
noda3 — закрыли ее уже, сделали перенос на VM-6
noda4 — 233938 1701297 — 0 ТБ (либо ошибка, либо так и осталось с прошлого замера) — 0 ошибок
noda5 — 106640635623 292179512829 — 49.66 TB 136.06 TB — 0 ошибок
noda6 — 86617391991 243250025384 — 40.33 TB 113.27 TB — 0 ошибок
noda7 — 38769693909 356324041216 — 18.05 TB TB 165.93 TB — 0 ошибок
noda8 — 13825987528 119205617664 — 6.44 TB 55.51 TB — 0 ошибок
noda9 — появилась новая нода, 1318151026488 — 613.81 TB — 0 ошибок
noda10 — появилась новая нода, 132548597248 — 61.72 TB — 0 ошибок
noda01 2016 — закрыли ее уже цены 2016 отличаются от цен соврменности, сделали перенос на Райзен
noda02 2016 — закрыли ее уже цены 2016 отличаются от цен соврменности, сделали перенос на Райзен

Все остальные 1245 всякие — в raid1, хотя тоже не мешало бы замерить как-ниб.
Еще Райзены новые делаем в raid0 — но там NVME диски, там смарты не показываются даже. Но пока тоже не разу ничего не сгорело.

Так же было решено сохранить для будущего понимания.
Полноценные смарты.

Закрыли 3 старых сервера из 2016 года по 32 озу.
Переместили их на 1 сервер 2020 года на 128 озу.

Управились часов за 15 наверно. Начали утром. Потом я уже спать ушел. И Вова продолжал до 5 утра или до 0-00 по украине.




Проблем особо не было.
Вручную, создали аналогичные ВДС с аналогичными ОС и IP на новой ноде.
Потом удалили файлы самих ВМ.
Потом скопировали с старых серверов.
И включили виртуалки.
И разослали людям новые пароли доступа.

Методом тыка — произвели очередной перенос, ибо автоматика VMmanager импорт — хз параша делает помойку, импорт мы не осилили за 3 года пока что :) Вручную надежнее и проще.
Мы — эталон ручного продления и ВМ тоже :))