Такой большой топик о xeon, вместо того чтобы просто написать, что Intel отсасывает у AMD, как в desktop, так и в enterprise (серверном) сегменте вот уже на протяжении не менее 5 последних лет.
Что касается VMmanager 6 и того факта, что оно не потянет множество кластеров, узлов и виртуалок. Так это тоже ожидаемо. У них с ISPmanager Business тоже самое было, когда больше 10 нод невозможно было нормально строить, потому что их панель тормозит и попросту не тестировалась при разработке под такие объёмы и под масштабирование. Понятно, что они сменили стек используемых технологий при разработке и компании поделили. Но это не сильно как-то повлияло в положительную сторону для конечного пользователя. Поэтому от этой конторы уже заранее чего-то ожидать не стоило и как ты и сказал, да, вероятно самый адекватный подход — это строить по гео-зонам, т.е на каждую страну отдельно панель с виртуалками. Ну или вовсе на каждую ноду — отдельно панель. Да, неудобно, особенно для клиента, зато надёжнее.
Но тогда если уж строить с подходом 1 нода — 1 панель, тогда уж лучше перейти на какой-нибудь solusvm2, где хотя бы цикл разработки более адекватен и каждое обновление панели не ломают что-либо. Потом что там видимо хоть как-то тестируют перед выкатыванием обновления в стабильную версию.
Да, вначале 2023 года. Лучшие умы ispsystem своими обновлениями вечно что-то ломали ещё со времён ispmanager. Просто максимально наитупейший подход к разработке у них. Видимо им максимально накласть на стабильность работы при каждой очередной новой версии.
когда они убили v3 авторизацию для Bill-5
Тоже через это пришлось проходить, когда они убили v3 совместимость со СВОИМИ же продуктами при интеграции с IPmanager, вместо которого использовался DCImanager модуль для распределения IP адресов, а этот модуль в свою очередь использовал v3 авторизацию видимо. ISPmanager тот же, например, до сих пор работает с этим модулем через v3 при интеграции с DCImanager.
Благо их саппорт там как-то смог откатить docker контейнер с этим модулем тогда в течении дня, а не спустя месяцы. Иначе это была бы дорога в 1 конец для дальнейшего использования их поделия.
Сейчас Версия платформы
2025.04.3 Regular (22 апр 2025)
Пока эти гении ничего не поломали на текущий момент и оно даже как-то работает, но насчёт billmanager интеграции хз, не используется, не знаю для него не сломали ли что-нибудь снова в текущей версии.
Не, до hosting.show у меня через vpn трафик шёл. Это именно до hostsuki.abcdusercontent.com трафик шёл напрямую, без vpn. Сейчас, кстати, картинки заработали и прогружаются. И это не из мск. Это из южного поволжья — ростелеком.
С этим видимо как-то связно, последние дней 5 у РQ подсети банил РКН активно. Вообще конечно очень странно они свои блокировки на ТСПУ тестят, как-будто как-то по регионам отдельно вначале проверяют, а потом уже на всю остальную часть страны выкатывают.
У тебя у самого, отображение картинок посыпалось, видимо из-за банов РКН подсетей OVH/Hetzner/etc.
Без proxy/vpn не показываются изображения из поста с твоего hostsuki.abcdusercontent.com, пинг до домена есть, но изображения в браузере не прогружаются.
Условия аренды стойки или места под установку своей стойки (стоек) и условия установки своего сервера на colocation в готовую скоммутированную стойку с интернетом от ЦОДа — это совершенно разные виды услуг для ЦОДа, поэтому и подходит к условиям обслуживания совершенно разный в том числе и список дополнительных услуг может быть разным.
Когда ты арендуешь место под свои стойки или арендуешь стойки (хоть целые ряды или целые маш.залы), ЦОДу безразлично что ты ввозишь, какое оборудование, какие конфиги и что и как именно ты там устанавливаешь в стойки это только твоё дело. Ты просто оформишь ввоз оборудования или вывоз на территорию ЦОДа и подпишешь акты ввоза или вывоза между цодом и твоей организацией либо ИП (смотря что там у тебя заключает отношения с ЦОДом). А дальше, внутри ЦОДа, ты уже сам силами своей организации пойдешь устанавливать сервер в стойку, коммутировать его, настраивать и т.д. Обычно ЦОД этим бесплатно заниматься не будет в рамках аренды стойки или места под стойку или аренды ряда (рядов) или маш.зала.
Когда ты устанавливаешь сервер на colocation в ЦОД, от тебя нужен будет только сервер с рельсами и возможно проводом электропитания. Ты привозишь его в ЦОД, оформляешь акты приема-передачи и они сами проверят какой БП стоит и если нужно замерят его потребление и сами установят его в свою стойку, подключив к сетевой и электрической сети. Это считай как услуга «под ключ».
Каждый сам для себя выбирает что ему подходит. Когда у тебя 1-2 сервера и больше 10 шт не планируется в ближайшие 5 лет, коло вполне может и хватать многим. Когда ты планируешь за годы установить более 20 серверов, имеет смысл сразу арендовать стойку (стойки) или место под свою стойку (стойки).
Ну а когда в ближайшие 5-10 лет ты планируешь ставить более 100 или 1000 серверов, наверное имеет смысл сразу строить свой ЦОД, если конечно найдешь финансы на его постройку и обслуживание :)
Это статистика говна, ничего не имеющая общего с реального. Простой и банальный пример: у одного и того же хостера может быть больше одной AS. Например одна AS для РФ, другая для EU, третья для США или вообще под каждую страну или под каждый ЦОД своя AS. Про DNS — вообще молчу.
Если интересно как именно statonline «считает» эту статистику, можешь посмотреть тут — habr.com/ru/articles/301894/ это один из сотрудников beget (бывших или нет хз) нормально описал и объяснил — как эта стата собирается.
В режиме работы EFI ты сможешь сделать загрузочным накопитель NVME, установить ОС на него и ОС будет загружаться с него. Потому что мат.плата имеет встроенную поддержку драйверов NVME в данном режиме. BIOS (он же Legacy Boot) не имеет такой поддержки драйверов для NVME и если установишь ОС на NVME, загрузка ОС уже не будет происходить.
Когда давно размещались в селектел для виртуалок ставили у них серверы, если у тебя на ноде будет 25+ виртуалок, ты столкнёшься с проблемами сети из-за ограничения на их коммутаторах по количеству MAC-адресов на порту. Это некая защита у них, от деградации сети от клиента. По тикету поднимут лимит если попросишь.
Да скорее всего в 99% случаях никому не нужны /24 подсети у них, поэтому и условно в рабочий день только смогут откопать свободную подсеть и назначить тебе её на vlan.
РКН — Рос Ком Надзор. Не сложно же запомнить сокращение этого органа. РНК — это скорее что-то про биологию.
Пока что страдают только жители OVH/Hetzner/Cloudflare от их действий, в плане сайтов.
Если не ошибаюсь долг не у самого ihor был ну и классически отжали бизнес и всё.
Просто сами себе выстрелили в ногу на этапе роста, арендуя помещения под оборудование в каком-то сомнительном здании.
У них сам подход к разработке никак не поменялся после 5-й версии. Там тоже каждое обновление (СТАБИЛЬНОЕ) и каждый раз какие-то баги всплывали. И только теперь, когда 5-я версия EOL и более не обновляется, работает стабильно, как часы. И такое ощущение, что дело даже не в рядовых сотрудниках — программистах. Видимо кто-то у руководящего состава так уже много лет рулит всем этим механизмом. И дело тут даже не в дойке гос-ва. Наоборот, крупные гос.компании выебут со всякими неустойками за такие косяки, вплоть до судов довести дела если это повлияет не реальные промышленные процессы с серьёзными последствиями.
Конечно, разработка в условиях монополизма на отечественном рынке, тоже играет роль в отрицательную сторону. Когда нет конкурирующих продуктов, руководство так и будет ебланить, а страдать будут конечные потребители этого «продукта». Поэтому да. Не рискуй обновлять продукты от ISPsystem / ISPmanager даже если это стабильная ветка. Потому что, даже если это обновление вышло уже давно, не факт, что эти гении не сломали что-то предыдущее, что уже и так хорошо работало. Не уведомив при этом никак.
Похожая проблема с лагами и низкой производительностью сети была ещё во времена VMmanager 5. В основном причина была в traffic shaper, он же — tc.
Эту утилиту VMmanager 5 использует для настройки шейпера трафика на каждую виртуалку. И уже при кол-ве виртуалок 150+ на ноде, общая пропускная скорость порта на сервере падала при замерах скорости. Но если удалить все виртуалки и замерить скорость сети любыми утилитами, хоть через iperf3 или тем же speedtes-cli, скорость была равной скорости порта. При создании 150+ виртуалок с включенным шейпером трафика у каждой и общей нагрузки на порт от них в районе ~100Мбит/С на ноде с 1Гбит/с портом, замеряя скорость как на ноде, так и с любой виртуалки, получалось порядка 300-400Мбит/с и не больше.
Решения было только 2 (желательно было делать оба пункта):
1 — отключение шейпера в любом виде для виртуалок
2 — отключение tso gso и tx offload для бриджа и физ.сетевого интерфейса:
ethtool -K vmbr0 gso off; ethtool -K vmbr0 tso off; ethtool -K vmbr0 tx off
ethtool -K eno1 gso off; ethtool -K eno1 tso off; ethtool -K eno1 tx off
Вполне вероятно в VMmanager 6 они наступили на те же грабли, используя nftables, когда при большим количестве правил для nftables, проблема начинаются в сетевом стеке ниже уровнем, особенно при большом количестве packet per second на ноде.
ИМХО основная проблема контор на ISPsystem и ISPmanager в том, что они за 10+ лет разработки серьёзных продуктов, до сих пор не научились тестировать свои продукты под высокими нагрузками и с большим количеством различных сущностей в своих панелях, именно панелях, а не продуктах. Потому что продуктом скорее можно назвать законченный и стабильно работающее решение, в котором практически нет багов. Складывается ощущение, что за многие годы никто из крупных их клиентов, никогда к ним не обращался с такими проблемами. Либо если обращались такие крупняки, то видимо решения не было найдено или как обычно «задачу зарегистрировали, решим через пару лет или в следующей новой мажорной версии нашей панели, когда придумаем, как найти причину поднять цену в 2-3 раза».
2 простейших и известных кейса:
— для ispsystem это vmmanager и сетевые лаги при большом кол-ве виртуалок на ноде
— для ispmanager это резервное копирование, которое может делаться сутками при наличии большого количества сущностей у пользователей (и дело даже не в объёме файлов при архивации)
Обычно тебе цод продаёт colocation 1 юнит с какой-то фикс.мощностью, к примеру 350W или 500W на одну розетку от одной фазы. Когда у тебя будут принимать сервер на установку в стойку ЦОДа на колокейшн, в первую очередь проверят мощность БП по наклейкам на сервере и если она сильно выше того, что ты оплачиваешь по прайсу за 1 юнит, предупредят о последствиях в будущем (либо это уже будет написано в договоре — соглашении на обслуживание).
Если у тебя в сервере стоят 2 БП по 1+ KW каждый и сервер под нагрузкой в проде будет превышать мощность, которую тебе продали в 1 юнит, попросят оплатить всё что свыше или выключат электропитание к серверу. Ну и ЦОД, заранее зная, что у сервера БП с большой мощностью, вероятнее всего сразу поставит твой сервер у себя в такую стойку, где будет реально занято буквально несколько юнитов, а остальные юниты закрыты заглушкой. Потому что у стойки есть определенный запас по мощности.
Поэтому да, если поставишь, условно, 10 серверов в стойку на каком-нибудь 2 х Xeon Gold или на 2 x AMD EPYC, как раз и получится что у тебя 10 серверов в стойке под нагрузкой будут те же 7-10 кВт потреблять в среднем и больше ты серверов уже если и поставишь, то только под страх срабатывания защиты от нагрузки в PDU или распределительном щите, рискуя оставить все серверы в стойке без электропитания.
Но тогда если уж строить с подходом 1 нода — 1 панель, тогда уж лучше перейти на какой-нибудь solusvm2, где хотя бы цикл разработки более адекватен и каждое обновление панели не ломают что-либо. Потом что там видимо хоть как-то тестируют перед выкатыванием обновления в стабильную версию.
Тоже через это пришлось проходить, когда они убили v3 совместимость со СВОИМИ же продуктами при интеграции с IPmanager, вместо которого использовался DCImanager модуль для распределения IP адресов, а этот модуль в свою очередь использовал v3 авторизацию видимо. ISPmanager тот же, например, до сих пор работает с этим модулем через v3 при интеграции с DCImanager.
Благо их саппорт там как-то смог откатить docker контейнер с этим модулем тогда в течении дня, а не спустя месяцы. Иначе это была бы дорога в 1 конец для дальнейшего использования их поделия.
Сейчас Версия платформы
2025.04.3 Regular (22 апр 2025)
Пока эти гении ничего не поломали на текущий момент и оно даже как-то работает, но насчёт billmanager интеграции хз, не используется, не знаю для него не сломали ли что-нибудь снова в текущей версии.
С этим видимо как-то связно, последние дней 5 у РQ подсети банил РКН активно. Вообще конечно очень странно они свои блокировки на ТСПУ тестят, как-будто как-то по регионам отдельно вначале проверяют, а потом уже на всю остальную часть страны выкатывают.
Без proxy/vpn не показываются изображения из поста с твоего hostsuki.abcdusercontent.com, пинг до домена есть, но изображения в браузере не прогружаются.
Когда ты арендуешь место под свои стойки или арендуешь стойки (хоть целые ряды или целые маш.залы), ЦОДу безразлично что ты ввозишь, какое оборудование, какие конфиги и что и как именно ты там устанавливаешь в стойки это только твоё дело. Ты просто оформишь ввоз оборудования или вывоз на территорию ЦОДа и подпишешь акты ввоза или вывоза между цодом и твоей организацией либо ИП (смотря что там у тебя заключает отношения с ЦОДом). А дальше, внутри ЦОДа, ты уже сам силами своей организации пойдешь устанавливать сервер в стойку, коммутировать его, настраивать и т.д. Обычно ЦОД этим бесплатно заниматься не будет в рамках аренды стойки или места под стойку или аренды ряда (рядов) или маш.зала.
Когда ты устанавливаешь сервер на colocation в ЦОД, от тебя нужен будет только сервер с рельсами и возможно проводом электропитания. Ты привозишь его в ЦОД, оформляешь акты приема-передачи и они сами проверят какой БП стоит и если нужно замерят его потребление и сами установят его в свою стойку, подключив к сетевой и электрической сети. Это считай как услуга «под ключ».
Каждый сам для себя выбирает что ему подходит. Когда у тебя 1-2 сервера и больше 10 шт не планируется в ближайшие 5 лет, коло вполне может и хватать многим. Когда ты планируешь за годы установить более 20 серверов, имеет смысл сразу арендовать стойку (стойки) или место под свою стойку (стойки).
Ну а когда в ближайшие 5-10 лет ты планируешь ставить более 100 или 1000 серверов, наверное имеет смысл сразу строить свой ЦОД, если конечно найдешь финансы на его постройку и обслуживание :)
Если интересно как именно statonline «считает» эту статистику, можешь посмотреть тут — habr.com/ru/articles/301894/ это один из сотрудников beget (бывших или нет хз) нормально описал и объяснил — как эта стата собирается.
ntc.party/t/%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BD%D0%BE%D1%81%D1%82%D1%8C-hetzner/12845
Пока что страдают только жители OVH/Hetzner/Cloudflare от их действий, в плане сайтов.
Просто сами себе выстрелили в ногу на этапе роста, арендуя помещения под оборудование в каком-то сомнительном здании.
Конечно, разработка в условиях монополизма на отечественном рынке, тоже играет роль в отрицательную сторону. Когда нет конкурирующих продуктов, руководство так и будет ебланить, а страдать будут конечные потребители этого «продукта». Поэтому да. Не рискуй обновлять продукты от ISPsystem / ISPmanager даже если это стабильная ветка. Потому что, даже если это обновление вышло уже давно, не факт, что эти гении не сломали что-то предыдущее, что уже и так хорошо работало. Не уведомив при этом никак.
Эту утилиту VMmanager 5 использует для настройки шейпера трафика на каждую виртуалку. И уже при кол-ве виртуалок 150+ на ноде, общая пропускная скорость порта на сервере падала при замерах скорости. Но если удалить все виртуалки и замерить скорость сети любыми утилитами, хоть через iperf3 или тем же speedtes-cli, скорость была равной скорости порта. При создании 150+ виртуалок с включенным шейпером трафика у каждой и общей нагрузки на порт от них в районе ~100Мбит/С на ноде с 1Гбит/с портом, замеряя скорость как на ноде, так и с любой виртуалки, получалось порядка 300-400Мбит/с и не больше.
Решения было только 2 (желательно было делать оба пункта):
1 — отключение шейпера в любом виде для виртуалок
2 — отключение tso gso и tx offload для бриджа и физ.сетевого интерфейса:
ethtool -K vmbr0 gso off; ethtool -K vmbr0 tso off; ethtool -K vmbr0 tx off
ethtool -K eno1 gso off; ethtool -K eno1 tso off; ethtool -K eno1 tx off
Вполне вероятно в VMmanager 6 они наступили на те же грабли, используя nftables, когда при большим количестве правил для nftables, проблема начинаются в сетевом стеке ниже уровнем, особенно при большом количестве packet per second на ноде.
ИМХО основная проблема контор на ISPsystem и ISPmanager в том, что они за 10+ лет разработки серьёзных продуктов, до сих пор не научились тестировать свои продукты под высокими нагрузками и с большим количеством различных сущностей в своих панелях, именно панелях, а не продуктах. Потому что продуктом скорее можно назвать законченный и стабильно работающее решение, в котором практически нет багов. Складывается ощущение, что за многие годы никто из крупных их клиентов, никогда к ним не обращался с такими проблемами. Либо если обращались такие крупняки, то видимо решения не было найдено или как обычно «задачу зарегистрировали, решим через пару лет или в следующей новой мажорной версии нашей панели, когда придумаем, как найти причину поднять цену в 2-3 раза».
2 простейших и известных кейса:
— для ispsystem это vmmanager и сетевые лаги при большом кол-ве виртуалок на ноде
— для ispmanager это резервное копирование, которое может делаться сутками при наличии большого количества сущностей у пользователей (и дело даже не в объёме файлов при архивации)
Если у тебя в сервере стоят 2 БП по 1+ KW каждый и сервер под нагрузкой в проде будет превышать мощность, которую тебе продали в 1 юнит, попросят оплатить всё что свыше или выключат электропитание к серверу. Ну и ЦОД, заранее зная, что у сервера БП с большой мощностью, вероятнее всего сразу поставит твой сервер у себя в такую стойку, где будет реально занято буквально несколько юнитов, а остальные юниты закрыты заглушкой. Потому что у стойки есть определенный запас по мощности.
Поэтому да, если поставишь, условно, 10 серверов в стойку на каком-нибудь 2 х Xeon Gold или на 2 x AMD EPYC, как раз и получится что у тебя 10 серверов в стойке под нагрузкой будут те же 7-10 кВт потреблять в среднем и больше ты серверов уже если и поставишь, то только под страх срабатывания защиты от нагрузки в PDU или распределительном щите, рискуя оставить все серверы в стойке без электропитания.