Я часто слышал легенды о Stack.net - xelent.cloud

Новости
За свои 6 лет в хостинге — я часто слышал легенды о неком Stack.net, но там никогда ничего нельзя было заказать. Так же как в еще одной легенде интернета — ДЦ Крок, там тоже ничего не заказать.

И вот наконец-то свершилось — они создали дочерний проект.



xelent.cloud/Account/Register

organisation: ORG-OI27-RIPE
org-name: OOO IT-Grad
org-type: LIR
address: Kirochnaya St. 9, 6 fl.
address: 191014
address: Saint-Petersburg
address: RUSSIAN FEDERATION
phone: +78123138815
fax-no: +78123138816
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: MNT-IT-GRAD
mnt-by: RIPE-NCC-HM-MNT
abuse-c: ITG6-RIPE
created: 2012-07-06T09:29:17Z
last-modified: 2015-04-07T07:43:44Z
source: RIPE # Filtered

Отличная статья попалась про суперэкономщиков

Новости
20 тысяч VPN клиентов на серверах за $5
habrahabr.ru/post/331178/

Чувак создал сервис на виртуалках.
На виртуалках! Которые я считаю в принципе не годятся для чего-либо стоящего, ведь это виртуалки «дешевле 1000р» для мусора всякого, тестов и опытов. Только дедики рулят же :)

И еще неплохо он так высказался про черты устаревшего хостинга.
Про VMmanager и фразу VDS.


Эта статья — просто шедевр того, как сейчас РФ избаловала клиентов сервисом и обслуживанием. Люди хотят за 5 баксов чтобы были сервисы которые им позволяли на бомж тарифе содержать крутые проекты.
И автор статьи не видит даже других хостингов, кроме хостингов которые как linode или digitalocean, где собрался целый штат специалистов, раз они смогли построить облако, смогли построить собственный биллинг и тому подобное.

Короче — по мнению такого клиента — все хостинги РФ устарели и проиграли, потому что пилят на Billmanager + Vmmanager.
А ведь почему пилят? Да потому что другие панели ничем не лучше.

И может быть — оно действительно так.
Возможно запиливать проекты на будущее десятилетие, через VMmanager это уже путь в безысходность. Но тогда остается только продавать дедики и не париться с виртуализацией в принципе, окрестить ее устаревшей технологией с кучей возьни. Ведь продавать дедики легче легкого — возможно именно это и есть будущее и я уже давно там?

Hetzner обновил сайт

Новости

www.hetzner.com/dedicated



В принципе пошел в массовом стиле.
Почему-то сейчас так модно, через фильтры дедиков делать по «меткам».

Но у них не так много серверов и тарифов, чтобы это выглядело полезной фичей ) Одно дело когда ты толкаешь 1000 тарифов со всех ДЦ, другое дело 2-3 линейки как в hetzner.
Для аукциона их пригодилось бы неплохо.

А так — мне кажется это шаг к тому чтобы попытаться что-то изменить. Ведь OVH давит.

Толкаю Идею

Пульс
Постоянно, уже много лет идут демагогии, что в Интернете нету специалистов.
Что тем людям которые запиливают все в интернете — очень трудно запиливать, потому что все держится на честном слове, даже компании создаются удаленные кто-то оформляет и добавляет в интернет банки и так далее.

И тоже самое касается администаторов или программистов.
Поэтому лучшее решение — в принципе создавать такую систему/структуру/синдикат, которая не зависит от этих ячеек.

Очень частое явление.
Создает программист API панель, через пол года api обновляется, а программист уже ливнул. На его место приходит другой желающий, но разбираться в чужом говне он не хочет, делает с нуля. И так же потом через год API обновляется и он снова ливает. А клиенты вынуждены из одной панели переходить в другую, в третью, в десятую.
Поэтому — лучше вообще вручную толкать, самое оптимальное и не пудрить мозги людям.

Тоже самое касается и VDS-нод.
В очередной раз нашлись недо-специалисты, которые считают что умнее всех — но на самом деле кроме слов от них ничего не узнать. Просто говорят, что они могут. Но сделать сервис, настроить ноду или написать статью — им сыкотно или вломы. Что же это за специалист? Это просто показушник демагог значит.

И вот в процессе демагогии родилась идея.
Толкаю эту идею в мир хостеров.

Создайте сервис по резалке VDS.
Вот сейчас VMmanager например режет VDS-ки.
А вы можете создать опенсорс какой-то или просто собственную разработку. Отдельным проектом. Отдельным сервисом.
Суть такая.
  • Каждый хостер просто покупает где-то сервер с IP и добавляет его в этот сервис. Получает свою сгенерированную ссылку с letsencrypt сертификатом или даже может добавить свой домен/поддомен для этого сервера, т.е. уже добавленной ноды. И пилит через Ваш сервис vds-ки.
  • Если месячная стоимость такого сервиса, по подписке, будет как цена VMmanager — мне кажется полно хостеров воспользуются такими услугами специалистов виртуализации, которые тусуются по интернету.
  • Согласитесь поддерживать такой сервис гораздо проще, ведь он один. Чем поддерживать и обслуживать 500 нод различных настроек.

FastVPS придумали локацию по быстрому для РФ

Новости
fastvps.ru/dedicated#/ru



Соблюдайте ФЗ N152 «О персональных данных» и размещайте Ваши проекты на выделенных физических серверах от FASTVPS :)

Я сначала обрадовался, заголовок уже начинался «ФастВПС — коло?»
Но потом начал искать ДЦ, нигде нету.
Но тут же в глаза бросились тарифы, ведь мы их уже видели.
И новость в итоге вышла не такая интересная.

Хотя этот топик отличный пример "сервиса и обслуживания". Клиент которому не нужен сервис и обслуживание, сразу увидит знакомые тарифы, а клиент которому нужно обслуживание даже и не поймет что это продается. Абсолютно разные категории клиентов. И надеюсь мои проекты никогда не будут такие, чтобы бояться даже дать ссылку на оригинал. Я всегда считал, что если клиент покупает у тебя, а не на оригинале — этим можно гордиться, и любой недовольный всегда может тут же пойти купить на оригинал, никогда не скрывал где закупаюсь, наоборот ко мне идут чтобы я закупил там и сям, все знают оригиналы.

Фичи 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 клиентов.

Хочу увидеть собственными глазами (с)

Пульс
Короче, недавно я осознал.
Что в 2014 году когда начался успех OVH — все железо было новое. Вся линейка SYS, все диски — все было новое.

И вот я записываю статистику по серверам и дискам уже 3 года. И перед моими глазами встает картина — как когда-ниб этому парку железа придет конец.

В 2017 году уже редко попадаются новые диски, только видимо «те которые пересобрали и заменили». В основном на новые покупки, ведь плату за установку отменили в 2016 году, когда была плата диски меняли, платы не стало — идут 2 2,5 3 летней давности.

И разумеется хоть они все и без ошибок. Например в hetzner могут поменять диск на диск с ошибками, который точно через 4 месяца тоже сдохнет. Но в OVH всегда без ошибок, там некие Хитачи в основном ставятся, которые я редко видел кстати, везде почему-то Сеагейты ставили.

Ну так вот, за 3 года — к примеру из партии в 1000 серверов только 5 штук могли быть какие-то бракованные. Абсолютно ничего не сгорало. И я даже начал считать, что в период моих покупок VDS, когда я еще был клиентом, который постоянно обучался и открывал что-то новое для себя, в тот период 2010-2013 года, когда мне хостеры постоянно лечили, то у них raid развалился, то еще что-то сгорело — я начал считать, что мне просто врали, как клиенту, а на самом деле это админы роняли ноды.

И вот, например пройдет еще пару лет. И диски же должны когда-то сгореть! В любом случае. Например просто почему-то мне кажется это срок в 5 лет. Даже покупая собственное новое железо(этот опыт у нас начался только с 2016 года) — мне кажется через 5 лет ему должен прийти пиздец, поэтому у меня такой девиз в правилах — «работает, пора не сгорит».

И вот я хочу увидеть своими собственными глазами — как парк новых серверов 2014 года начнет устаревать и массово гореть. ЖДУ ЭТОГО С НЕТЕРПЕНЬЕМ прямо :) Для моей истории и статистике. Случится ли такое? Или не случится?



И еще забыл написать.
Так же с 2016 года пошла статистика «VDS-нод» — будут ли диски сгорать быстрее, если это VDS-нода, а не просто клиент-сервер-одни-руки.

Полный список доменов в зоне ru/su/tatar/рф/дети

Новости
habrahabr.ru/post/331144/



Дампы зон, сжатые xz, можно скачать через Bittorrent и I2P Bittorrent, torrent-файлом или по следующей Magnet-ссылке:
magnet:?xt=urn:btih:3457106ce62b2707639978d802e20567e278aa39&dn=Russian%20domain%20zones&tr=udp%3a%2f%2ftracker.leechers-paradise.org%3a6969&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969%2fannounce&tr=udp%3a%2f%2fp4p.arenabg.com%3a1337%2fannounce&tr=udp%3a%2f%2ftracker.zer0day.to%3a1337%2fannounce


Не обязательно их распаковывать, можно работать с ними в сжатом виде. Используйте xzcat вместо cat, xzdiff вместо diff, xzgrep вместо grep, xzless вместо less.

наконец-то официальные маркировки ДЦ OVH

Пульс
Я уже как пол года занимаюсь публикациями. И мечу все посты по своим меткам, чтобы через 10 лет потом находить за 5 минут, а не за 30 минут времени поиска :)

И вот наконец-то опубликовали карту названий.

2 дата-центра я не угадал — и пришлось переделывать метки в публикациях и ссылки.

А вот про Австралию и Сидней угадал — что ДЦ запиливаются на базе чужих компаний. Equinix и Telstra

Вообще — нормальные люди сначала придумывают названия, потом публикуют свои фоточки. А не наоборот :)) Но в OVH все так работает.

Итого, картина выглядит следующим образом теперь.

Было
  • PAR datacentre
  • SBG datacentre, EU Central [FR, Strasbourg]
  • RBX datacentre, EU West [FR, Lille]
  • GRA datacentre, EU West [FR, Lille]
  • BHS datacentre, CA East [QC, Montreal]
Добавилось
  • ERI datacentre, EU West [UK, London]
  • HIL datacentre, Hillsboro, US West [OR, Portland]
  • VIL datacentre, Vint Hill, Virginia, US East [VA, Washington]
  • WAW datacentre, OZA, EU Central [PL, Warsaw]
  • SYD datacentre, SY2(Equinix), AP Australia [NSW, Sydney]
  • SGP datacentre, SGCS2(Telstra), AP South-East [SG, Singapore]
  • LIM datacentre, Limburg, EU Central [DE, Frankfurt]

Будут в будущем
  • EU West [Nl, Amsterdam]
  • EU South [ES, Madrid]
  • EU South [IT, Milan]
  • US Central [TX, Dallas]
  • AP Australia [VIC, Melbourne]