Фичи VMmanager KVM
Вчера с 6 утра и до 23 вечера с Vova1234 — посвятили настройке 2 новых нод. И весь день как в аду каком-то был. Проблема за проблемой, переустановка с нуля, переустановка с нуля, тикеты с ispsystem, настройки ноды.
Что сегодня я спал без чувств и мне снились панели ISPsystem )
И пришла пора написать пост годичного опыта проб и ошибок.
Итак, как вы уже знаете — Debian разработчики поддерживать не будут.
А с 2016 года мы делали ноды на Debain 7. И решили раз больше поддерживаться не будет — пора делать на Cent OS 7
Одну тестовую ноду, но на CentOS 6 мы сделали — и там все отлично работало. Но там был один узел. И панель и узел стояли на одном сервере. В итоге мы подумали что косяки начинают наблюдаться когда начинаются добавляться узлы. Но потом накатили центос7 без узла и тоже не работало. Потом накатывали панель на отдельный атом, ноду добавляли узлом — такая же фигня. И никак не могли понять в чем же проблема. Уже начали грешить даже на то, что панель возможно не устанавливается на слабые Атомы. Ну с опытом мы пришли к выводу, что если делать через узлы, то саму панель нада ставить на отдельный сервер, а все будущие узлы добавлять узлами. Ниже напишу почему я так решил. Короче весь вчерашний день угрохали на эту панель. Каких только вариантов установок мы не попробовали методом тыка.
Но вчерашний день в итоге суммировал накопленный опыт. И я решил написать этот пост.
Снапшоты.
Когда создаете тариф — отключайте и запрещайте их сразу.
Потому что если у вас диск всего 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 клиентов.
Что сегодня я спал без чувств и мне снились панели 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 клиентов.
