Публичные отчеты и различная статистка по нашим нодам, что мы насоздавали от балды.
  • Дата создания
    7 ноября 2017
  • Топиков
    13
  • Ограничение на постинг
    1.000
  • Категория:
    VM.Center

Отчет про "среднее кол-во" виртуалок на нодах

Если вы сомневаетесь в честности своего хостера.
Попросите его сделать вот такие вот скрины.

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







И так далее, как и заявлено в правилах.

И даже при условии что там виндоусы больше половины. Все равно никто не жалуется.

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

noda3 6700k

Днем 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.


Статистка по ОС №2

Первая статистика была в самом начале
Решил вести паблик примеры [Осень 2017]

Теперь статистика на март 2019
Нагрузку мы так и не поняли как нужно считать, поэтому просто положили хуй короче. Как говорится работает и ладно :) Оптимизацией не занимаемся.
Как и написано в правилах услуги.


А теперь факты, просто факты.
















SMART отчет №2


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

Точно так же смотрим только ноды, где 1 SSD без raid1
Потому что там сгорание равносильно смерти узла.

SBG i7-6700k
noda1 — 272379466896 — 126.84 TB — 0 ошибок
noda2 — 295425295251 — 137.57 TB — 0 ошибок
noda3 — 766966834999 — 357.15 TB — 0 ошибок
noda4 — 185514307689 — 86.39 TB — 0 ошибок
noda5 — 181434747397 — 84.49 TB — 0 ошибок
noda6 — 558204424554 — 259.93 TB — 0 ошибок
noda01 2016 — 378695466309 — 176.34 TB — 0 ошибок
noda02 2016 — 165944088769 — 77.27 TB — 0 ошибок

GRA i7-6700k
noda1 — 172324367138 — 80.24 TB — 0 ошибок
noda2 — 53503605961 — 24.91 TB — 0 ошибок
noda3 — 50002184870 — 23.28 TB (меняли ноду) — 0 ошибок
noda4 — 233938 — 0 ТБ (либо ошибка, либо так и осталось с прошлого замера) — 0 ошибок
noda5 — 106640635623 — 49.66 TB (меняли ноду) — 0 ошибок
noda6 — 86617391991 — 40.33 TB — 0 ошибок
noda7 — 38769693909 — 18.05 TB — 0 ошибок
noda8 — 13825987528 — 6.44 TB — 0 ошибок
noda01 2016 — 266791112841 — 124.23 TB — 0 ошибок
noda02 2016 — 250296977064 — 116.55 TB — 0 ошибок

Так же было решено сохранить для будущего понимания.
Полноценные смарты.
И в конце 2019 года сохранить еще раз.
И сравнить какие показатели увеличились, какие наоборот уменьшились.
Чтобы понять что происходит со временем.

Судя по всему, возможно мы так и не увидим собственными глазами как сгорят эти ноды :)
Быстрее процессоры потеряют актуальность.
Читать дальше

bhs.i7k => bhs6.i7-4790k.ovh

Как вы уже знаете из старых топиков, ISP закрывает Debian ноды.
Поэтому процесс переезда.

Еще одна нода переезжала из Debian 7 на CentOS 7
Она была создана еще в 2016 году в самом начале, и вот в январе 2019 переехала.

И даже оказалось, что там диск один сгорел.

Raid1 был, 2 диска, один издох, а все работало на втором и никто не заметил даже.


Переезд занял вот столько. Около 2 часов.
Никто даже не заметил, так как 3 января :)



Старый сервер работал

Operation Motherboard replacement finished (noda2 sbg2.i7-6700k)

[TICKET#8492399526] OVH Monitoring
06:08 (7 ч. назад)
Mūsų technikai (dirbantys 24 val./24, 7 d./7) buvo informuoti ir
prisijungs prie Jūsų serverio.
Šiuo metu gali būti atliekamos kitos intervencijos, vidutiniškai jos trunka
30 minučių.
Sutrikimo priežastį žinosime tik pradėję intervenciją.
Bendrą sutrikusių serverių kiekį ir vykdomas intervencijas galite
matyti šiuo adresu:
darbai.ovh.lt/vms/
Jūsų serveris yra spintoje 75A33.
Kai technikas ims tikrinti Jūsų serverį, gausite pranešimą apie tai.
Šiuo metu galite perkrauti serverį tvarkytuve.
Logs:

PING ns3054529.ip-164-132-205.eu (164.132.205.111) 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
— 164.132.205.111 ping statistics —
10 packets transmitted, 0 packets received, +6 errors, 100% packet loss
---------------------

[TICKET#4862680610] Operation Motherboard replacement finished
07:47 (5 ч. назад)
Operacija baigta 2019-01-02 01:47:11 CET (UTC +01:00).
Toliau pateikiamos intervencijos detalės:
Motherboard replacement
Date 2019-01-02 00:30:55 CET (UTC +01:00), jonas B made Motherboard replacement: Diagnosis:
HS motherboard
Actions:
Replacing the motherboard.
Updating the MAC address for DHCP.
Server restart on the OVH kernel «BZimage» because when boot on disk it stuck on «GRUB interface».
Result:
DHCP OK. Boot on the OVH kernel. Server on login screen. Ping OK, services started.
OVH как всегда все сделало само
Сгорела мать, поменяли мать, перезапустили сервер.
Ты с утра проснулся, увидел что что-то падало и что все уже работает :)

SSD Total Bytes Written

Решил собрать статистику по записанному на наши ноды.
Не на все ноды, а только на SSD 480
Потому что только на них 1 диск без raid.
Итак поехали



SBG i7-6700k
noda1 — 237188120396 — 110.45 TB — 0 ошибок
noda2 — 225563838822 — 105.04 TB — 0 ошибок
noda3 — 705543486450 — 328.54 TB — 0 ошибок
noda4 — 123513899388 — 57.52 TB — 0 ошибок
noda5 — 161425790769 — 75.17 TB — 0 ошибок
noda6 — 542676301010 — 252.70 TB — 0 ошибок

GRA i7-6700k
noda1 — 95814997413 — 44.62 TB — 0 ошибок (но есть CRC Error Count 2, хоть это не считается плохим)
noda2 — 20698304512 — 9.64 TB — 0 ошибок (свежая была новый диск и недавний перенос с Дебина)
noda3 — 100699200328 — 46.89 TB — 0 ошибок
noda4 — 14811 — 0 ТБ ?? — 0 ошибок (новый диск, месяца нет, перенос с Дебиана был на новый сервер)
noda5 — 239684042104 — 111.61 TB — 0 ошибок

остальные не проверял, там везде raid или sata диски, а у sata нету такого показателя.
потом в новый год проверю все.

  • Итак, вопрос, когда же 480 SSD выйдут из строя ?
  • На каком показателе ?
  • SAMSUNG MZ7WD480HAGM-00003

waw.1245.ovh

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

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 ее вроде поддерживать не собираются даже.

noda2 RBX

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

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

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

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





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

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


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