2 лицензии KVM VMmanager 5 с узлами

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

Читать дальше →

Фичи VMmanager KVM

Статьи
Вчера с 6 утра и до 23 вечера с Vova1234 — посвятили настройке 2 новых нод. И весь день как в аду каком-то был. Проблема за проблемой, переустановка с нуля, переустановка с нуля, тикеты с ispsystem, настройки ноды.

Что сегодня я спал без чувств и мне снились панели ISPsystem )
И пришла пора написать пост годичного опыта проб и ошибок.

Итак, как вы уже знаете — Debian разработчики поддерживать не будут.
А с 2016 года мы делали ноды на Debain 7. И решили раз больше поддерживаться не будет — пора делать на Cent OS 7

Одну тестовую ноду, но на CentOS 6 мы сделали — и там все отлично работало. Но там был один узел. И панель и узел стояли на одном сервере. В итоге мы подумали что косяки начинают наблюдаться когда начинаются добавляться узлы. Но потом накатили центос7 без узла и тоже не работало. Потом накатывали панель на отдельный атом, ноду добавляли узлом — такая же фигня. И никак не могли понять в чем же проблема. Уже начали грешить даже на то, что панель возможно не устанавливается на слабые Атомы. Ну с опытом мы пришли к выводу, что если делать через узлы, то саму панель нада ставить на отдельный сервер, а все будущие узлы добавлять узлами. Ниже напишу почему я так решил. Короче весь вчерашний день угрохали на эту панель. Каких только вариантов установок мы не попробовали методом тыка.

Но вчерашний день в итоге суммировал накопленный опыт. И я решил написать этот пост.

Частые проблемы при работе с VMmanager KVM

Снапшоты.
Когда создаете тариф — отключайте и запрещайте их сразу.



Потому что если у вас диск всего 480 SSD к примеру и он уже поделен на тарифы, на 15 долей по 26 SSD к примеру. То снапшоты могут засрать все свободное место, оказывается они не учитываются в этот лимит в 26 SSD по тарифу который ты создал в настройках и лепятся и лепятся из резерва. И самое интересное, когда место заканчивается — VDS-ка офается и не включается. А чтобы удалить снапшот нужно запустить эту VDS. Если зайти под рутом чисто на файлы, то там можно увидеть вообще 1 гигантский файл вместе с всем говном из снапшотов. Чисто вырезать оттуда сами снапшоты — невозможно. Весь образ VDS — может быть файл такой в 160 ГБ, где 26 SSD тариф и остальное это снапшоты. Короче в итоге приходится удалять полностью и пересоздавать VDS.

Версии ОС

Почему-то когда происходит скачивание новых версий ОС — старые часто не удаляются.
В итоге в папке
/nfsshare
накапливается какое-то говно и через месяцы работы ноды — оно тоже может сожрать все свободное место и VDS-ки начнут падать из-за нехватки места.
Логично же — образ ОС должен перезаписываться, а не копиться.

Шаблоны ОС
Шаблоны ОС не всегда автоматически копируются на «узлы». Нужно проверять задание крона, и запускать вручную. Иногда ОС могут не ставиться потому что на узлах просто папка с шаблонами пустая.

Если ставите VMmanager на CentOS 7
/etc/resolv.conf
должен быть:
nameserver 8.8.8.8
nameserver 213.186.33.99
search ovh.net
иначе centos не устанавливаются.

ОС Debian зависает шестеренка установки
В итоге как оказалось — проблема в nginx
Конфиг был взят из их статей с из сайта doc.ispsystem.ru
И там присутствовала строчка с опцией «nocunked»


В итоге эту проблему решили. И даже на старых нодах, которые на Debian 7 были сделаны — стало работать все нормально.
Ну оно как бы и работало. Но нужно было «отключать» и «включать» VDS-ку. А это значит каждому второму нужно было отвечать выключите и включите и можете пользоваться. Это был пиздец. Целый год нервировало меня это.
Но даже при таком раскладе — это не останавливало тесты и опыты и хорошее FAQ увеличивало их продажи.

Но так как Debian уже не будет поддерживаться.
Все равно — придется менять придуманную систему и маркировку нод на CentOS 7
Потому что основной сервер с панелью и узлы — должны быть сделаны на одинаковых ОС

И поэтому я решил написать эту статью.
Чтобы поделиться тем, как я придумал делать. Я раньше писал много статей про дизайн сетей там, технические домены или делать NS в 4 дата-центрах с 4 доменами купленными в 4 разных регистраторах по 4 разным юридическим законам их стран. Например я считаю что этот стандарт я и придумал в своих статьях, через 5 лет все стали так делать и если сейчас так не сделано, то это нубасы.

Или статьи про storage всякое, которое когда-то было selectel и которое меня подставило знатно.
Или я придумывал метод защиты от ддос атак шаред помоек, через специальные отдельные домены технические, где и пробить по NS было тоже не возможно. Когда еще НЕ БЫЛО OVH.
Или я первый начал разносить тысячи технических записей по кучи разных панелей. И сейчас у меня каждый дата-центр, каждая локация в отдельном месте и все места абсолютно разные, если упадет одно, другие работают.

Ну везде старался найти — идеальное что-то! :)


И с VMmanager так же.
Методом проб и ошибок я пришел вот к таким понятиям.
Для начала немного истории. Ноды VDS можно создавать по разному, очень по разному.

Метод 1
Можно ставить 1 лицензия VMmanager KVM — 1 нода. Панель и узел — 1 единственный сервер.
В итоге можно копить ноды через маркировку как шаред хостинги.
noda1.abcd.cloud
noda2.abcd.cloud
и так далее.
Их можно делить чисто по сервису/бренду, а можно так же делить по типу клиентов или предназначению, например noda1.highload.cloud noda2.highload.cloud и так далее по смысловым тех доменам.
Их можно делить по типу KVM или OVZ, например можно метить noda1.kvm.abcd.cloud
Или можно делить по типу дата-центра, например noda1.kvm.hetzner.abcd.cloud и noda1.kvm.selectel.abcd.cloud
А можно так же делить и по странам даже. Или по континентам.
Вообщем — на вкус и цвет.
Плюсы этого метода как по мне в том, что все отдельное. Сгорела/раздрочилась/хз-что-то-случилось с нодой, похуй, перенес выживших на новую. Создал новую.
Минусы как по мне — начинает накапливаться просто огромное кол-во лицензий VMmanager, замусоривается все это в самом биллинге ISP. Ну и учет вести труднее. Плюс не красиво оформлено. Смотрите какое длинное название будет noda1 KVM Hetzner ABCD cloud и так далее, это еще без страны или конкретного DC1 DC2 внутри Hetzner. Длинное техническое имя получается. Не красиво.
И второй крупный минус — каждую ноду нужно настраивать настройки с нуля. Создавать пользователей VMmanager, делать оформление бренда и тому подобное.

Метод 2
Можно создавать ноды через узлы.
Например покупается лицензия VMmanager, ставится на сервер, сервер и узел являются единичным. И потом просто добавляются узлы.

Тут тоже можно сделать по разному.
2.1 Каждому дата-центру свою ноду и маркировка сразу сокращается.
вместо noda1.kvm.hetzner.abcd.cloud будет — просто kvm.hetzner.abcd.cloud, где все последующие ноды(те которые в первом методе были цифрами) с KVM и закупающиеся в hetzner будут добавляться узлами в эту панель уже и ссылку.
2.2 Но все равно это получается не четко. В идеале ты начинаешь понимать, что создаешь ноды на конкретных процессорах и конкретных конфигах. Ведь согласитесь когда у тебя постоянно разные конфиги, то значит постоянно разные цены и рассчеты. А значит и сами шаблоны тарифов в VMmanager, все это засирается и с годами забывается. Это начинает очень сильно напрягать. Куда удобнее покупать один и тот же оптимальный конфиг, который уже рассчитан и поделен на продажи. И наполнять одинаковым узлами свою панель. В итоге решение было найдено — можно покупать каждому процессору отдельный домен. Например i7-6700k.ovh i7-7700k.ovh xeon-E5.ovh 1245.ovh i7-4790k.ovh xeon-d.ovh и тому подобное, Но этот процессор так же может быть в разных дата-центрах, странах и локациях. Поэтому его все равно нужно делить. Например покупать домен для процессора в одноименной зоне, у ДЦ OVH есть зона .ovh, если бы не было, то это была бы зона .fr, если в Hetzner, то значит i7-6700k.de и тому подобное. А потом уже метить по названию ДЦ, метить по самой локации. Например hetzner.i7-6700k.de contabo.i7-6700k.de, а внутри-дц маркировка — DC10.hetzner.i7-6700k.de например так.
В OVH же идет например по их списку дата-центров. Например gra1.i7-6700k.ovh sbg1 sbg2 rbx1 rbx2 rbx6, bhs4 bhs6 и тому подобное короче.
Итак, как мы видим — теперь уплотнять и накапливать узлы можно более грамотно.
На каждую такую панель — покупается VMmanager, а далее в нее добавляются идентичные узлы уже. И там можно хоть сотнями засрать например за будущие года. Все по полочкам начинается.
Плюсы — не нужно постоянно настраивать настройки и бренды. Ну и людям проще как-то, когда одна ссылка, а не 100 ссылок будет для каждого узла. Но все равно людям нужно будет запоминать отличие OVZ и KVM и отличие по локациям дата-центров, нода в hetzner или нода в ovh или еще где. Плюс если по процессорам, то запоминать и делить еще проще. И не нужно плодить кучу тарифов для разных конфигов железа и метить их как-то в гигантском списке шаблонов VM, нужные тарифы — в нужном узле, все просто.
Минусы — сама панель стоит на сервере и узле самом первом. Если через 3 года узел устареет или там ему пизда придет диски выгорят. То потом с нуля поднимать панель на новом месте и добавлять туда например те 50 узлов которые были. И всех пользователей с 50 узлов — это проблема! Просто огромная проблема. Восстанавливать очень много придется. Если уж панели придет пиздец, то «метод 1» описанный выше смотрится даже практичнее, где в каждой панели свои «пользователи узла-ноды». Поэтому мне нравится третий метод :)

Метод 3
Этот метод полная копия «Метода-2»
За одним важным исключением.
Панель VMamanager для определенного будущего узла, который по процессорам, по локациям странам и дата-центрам делится — эта панель ставится еще и на отдельный сервер — чисто для панели.
Например покупается что-то бюджетное, тот же Atom N2800 или i5-2400 какой-ниб. Ставится туда панель. А потом уже добавляется самый Первый узел с которого будут пилиться VDS-ки. В итоге если через 3 года какой-то узел откажет, и даже самый первый, то он просто легко заменяется и все. А сама панель Vmmanager работает отдельно, все «кол-ва пользователей для каждого узла внутри кластера по стране-локации отдельно»
Плюсы — все по полочкам. Все легко заменяемо. Повторной работы быть не должно. Если только v6 не выйдет какая-ниб которая опять заставит «создавать новые панели» :))
Минусы — пока не обнаружил, разве что лишние 500р для каждого узла. А если у нас дата-центров десяток, плюс в каждом из них еще десяток внутренних ДЦ по городам например, плюс еще десяток процессоров использоваться будет — то это неплохие такие лишние расходы получаются. Но, нужно закладывать в стоимость создания ноды. Хотя я все же считаю, VMmanager не та панель на которой можно сделать бизнес и заполнить сотнями и тысячами всю эту красоту полочек.

А, и еще добавлю.
Цена одного узла — 100 евро.
Цена 1 биллинга — 150 евро. Биллинг это просто БОГ дохода. Просто купил, настроил, продаешь, зарабатываешь.
Нода — это 15 долей на 1 узел. Всего 15 долей.
Если честно VMmanager — не дешевое удовольствие для 15 клиентов.

Как хорошое FAQ увеличивает продажи

Новости
Вот смотрите пример.
С 2012 года как я стал партнером ISPsystem еще с v4 и 500 еврами взноса.
Сколько ебучих лет прошло, прежде чем «потенциальные клиенты продукта» научились использовать этот продукт.

Ладно биллинг я сам годами изучал. Методом тыка тыкался и создавал людям хостинги.
И наконец прозрел что дело пошло в поток.

Но вот VMmamager я не мог методом тыка, т.к. админить мне не особо приятно просто по характеру.
И ведь годами никто ничего не мог настроить.
Но просто стоило написать статью пошаговую. Готовое FAQ, как вот сколько нод уже запущено. (там внутри у лицух еще узлы есть, узел = нода)


И всего-лишь из-за статьи какой-то, компания получила дохода (не забываем, что вечные там еще обновления которые не учитываются в стоимости и месячные тоже могут уже долго продляться)

Возможно это копейки для монополии.
Но неужели им самим было слабо написать такую пошаговую инструкцию?

Весь расход за 5 лет


ps
Хотя я считаю — VMmanager не та панель, на которой можно сделать бизнес «виртуальных услуг». Если ты хочешь создать тысячи виртуалок и сотни нод, то подход с узлами просто убог. Нужно что-то еще проще, еще удобнее. Чтобы можно было просто продавать по своим точкам. Пока что тащат по всем пунктам просто продажи серверов, самое прибыльное, самое легкое, самое крутое и есть будущее на десятки лет, чего я не могу сказать про виртуальные ноды, которые через 3 года точно придется переделывать.

Пользуясь продуктами ISP - будь готов отвечать одно и тоже, одно и тоже, одно и тоже

Пульс
Короче, я уже 2 года отвечаю одно и тоже про логин/email
Подробнее тут hostsuki.pro/all/samyy-bolshoy-bag-v5-ispsystem-billinga.html
Не знаю скольким людям я уже ответил «это пиздец тупость». Многим. И я думаю эти люди тоже теперь считают что продукты ISPsystem тупые до невозможности.

Далее.
Осенью прошлого года был замечен баг.
топик раз
топик два
топик три

Заметьте — прошло уже пол года.

Сколько десятков людей я должен воспитать и вбить им в голову, какие ISPsystem плохие и что у них ничего не работает. Пока этот баг починят? )) Я не знаю. Наверное больше сотни мне придется воспитать будущих нытиков которые будут ходить и рассказывать всем, что «а так и должно быть, это же косяк ISPsystem, там всегда так».

ISPmanager v5 lite за 1200р

Услуги
  • ISPmanager lite v5 вечная — 1200р
  • ISPmanager Buss v5 вечная — 6000р
  • VMmanager OVZ/KVM вечный — 4000р (как настраивать, тут, тут)
  • VMmanager 5 Cloud вечный — 60000р
  • Billmanager 5 вечный — 6000р (плюс установлю на Атом и настрою под ваш проект, Атом 4500р/год аренда)
  • Billmanager 5 Corp вечный — 35000р (с корпоративом не помогаю, лень изучать, я проиграл ему, не хочу голову засорять)
Все вечные лицензии имеют срок обновлений на 1 год, далее обновления на 50% дешевле, чем если покупать аналогичную на 1 год. Поэтому для v5 выгодно понятие «вечный» при условии что вы знаете, что не будете закрывать свои проекты года 3 и более.



bill.suki.host/billmgr

Только спустя 9 месяцев пользования VMmanager

Пульс
Ну, как наконец-то люди научились делать ноды.

Только спустя 9 месяцев дошло.
А ведь VMmanager можно установить и на дешевый Атом за 10 евро или 5 евро или i5-2400 какой-ниб за 9 евро.
Там будет сама панелька по какой-ниб локации или дата-центру.

А узлы уже добавлять — это ноды, серверы с IP

Постоянная нехватка SSD из-за «шаблонов ОС» — была.

И почему ISPsystem сразу не написали такой совет?

Так вот — делюсь открытием. Когда ставите свой VMmanager — ставьте его не на рабочую ноду, а просто на любой сервер с SATA диском.