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]

Alibaba Group Holding сообщила о строительстве новых дата-центров

Новости
По планам Alibaba, к концу марта 2018 года в индийском Мумбаи и индонезийской Джакарте должны заработать по одному ЦОДу компании. В результате общее количество центров обработки данных Alibaba достигнет 17. В настоящее время такие объекты располагаются в Китае, Гонконге, Сингапуре, Японии, Австралии, США, странах Ближнего Востока и Европы.

Строительство дата-центра Alibaba в Индии будет проходить совместно с местной компанией Global Cloud Xchange — «дочкой» телекоммуникационного оператора Reliance Communications. Китайский интернет-гигант также начал сотрудничество с крупнейшим в Индии оператором связи — Tata Communications. Партнёрство предполагает предоставление облачных услуг через платформу Alibaba Cloud.

Плюс так же.
Alibaba’s decision to join forces with Equinix in 2015 provided powerful new fuel for its global expansion strategy. The company initially selected Equinix to host a number of its cloud compute nodes and joined the Equinix Cloud Exchange in Singapore.
blog.equinix.com/blog/2017/06/13/alibaba-scales-up-global-cloud-and-digital-services/?hootPostID=3d91c02773b9cce327a76ace47041c9e

Собственно весной 2017 я случайно заметил их сервис облако, методом тыка шарился и открыл.
hostsuki.pro/news/alibaba-cloud.html
Ждем к 2020 что-то интересное и от Китайцев. Не только OVH правит миром.
И конечно же — все эти «локации по миру» — нужно продавать.