Похожая проблема с лагами и низкой производительностью сети была ещё во времена 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 или распределительном щите, рискуя оставить все серверы в стойке без электропитания.
Всё очень просто и от этого напрямую зависит конечная стоимость и управление:
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 5/7/10кВт или по счётчику (сколько электричества потребил столько и оплатил в месяц), а все остальные затраты (железо, интернет, монтаж и настройка железа в стойку) на тебе, как на клиенте, потому что у тебя собственная стойка со своим железом
— аренда стойки 42 или 48, в которую цод тебе уже поставит свои PDU на каждую фазу, за отдельную плату может быть даже коммутатор какой-то предложат
— юниты в стойке (считай colocation)
В зависимости от того, что подходит клиенту, такую схему взаимодействия с цодом и выбирает клиент.
А юниты — это речь как раз про последний пункт, когда тебе цод под ключ продаёт 1, 2, 3, 4 юнита в стойке, куда ты приехал и воткнул свои серверы. Выдаст даже какую-нибудь /29 или /28 подсеть на эти серверы с 5-15 IP адресами. Ну или за отдельную плату может быть даст тебе какую-нибудь /24 в аренду, если у цода они есть в наличии.
Даже не просто в проектировании, а в самом подходе к построению ЦОДов.
Многие годы, пока на стойку было не более 5-10кВа в среднем по больнице, всех устраивал подход воздушного охлаждения и отведения тепла. Сейчас же, поскольку современное железо, а так же железо с видеокартами под ИИ, становятся всё более и более мощными (горячими), старый подход по охлаждению и отведению тепла перестаёт быть эффективным. Ты говоришь — «модный ДЦ должен иметь до 20-30квт запаса на стойку». Я тебе и отвечаю — ты забываешь про тепло, которое нужно как-то отвести, а так же как-то охладить такие «горячие» стойки. Подвести более толстый кабель с бОльшим запасом по силе тока к стойке — не самая сложная задача. Сложнее всего — организовать отвод тепла и охлаждение 10+ кВт стоек в маш.зале в одном ряду с другими стойками.
Потому что в горячем коридоре, даже у 7кВт стойки, температура в близи 40 серверов будет в среднем на уровне 45 градусов, при постоянно поступающих 23-25 градусах холода (зависит от честности ЦОДа) из холодного коридора. Это уже не мало, и, например, на стойках с 10-12кВт, задняя часть серверов постоянно будет перегрета и это вполне может чаще приводить к выходу из строя серверов, особенно актуально для платформ, у которых стоят PCIe видеокарты или те же NVME накопители через PCIe переходники, ещё и учитывая тот факт что видеокарты и накопители и так греются сильно под нагрузкой и их температуры могут быть тоже на уровне 65-80 градусов в среднем.
Именно поэтому сейчас всё чаще идут разговоры про жидкостное охлаждение стоек, но тоже с разным подходом, когда у тебя условно сразу вся стойка с «плавающими» серверами в ней, в неком диэлектрике или же стойка с водоблоком, который встроен непосредственно в стойку. Серверные платформы с СЖО появляются постепенно на рынке за последние годы. В ЦОДах такие стойки тоже уже появляются, даже в РФ. Например в московском датапро у какой-то клиентской стойки лично видел такой тип охлаждения, когда у стойки система жидкостного охлаждения вмонтирована прям вертикально рядом с ПДУ, имея специальные фитинги подключения СЖО, в которые подключаются трубками серверные платформы. У самих серверных платформ в задней части выходят обычно по 2-4 трубки для включения в эту систему СЖО. Если найду сейчас похожие фотки в гугло-картинках, прикреплю их, чтобы понятнее было о чём речь.
В итоге пройдёт какое-то количество лет, чтобы сменилось ещё пару поколений железа и ЦОДы начнут постепенно строить из гибридных (воздух+сжо), под уже современные серверы с жидкостным охлаждением и тут то твои запросы по 20-30кВт на стойку как раз начнут покрываться.
Про тепло и охлаждение забываешь. Дать больше энергии в стойку не сложная задача для цода, проложив тебе трассу от распределительного щита в стойку кабелем с более толстым сечением проводника.
У тебя размышления уровня — ноль понимания как устроена работа дата-центра.
Если в твоём городе какие-нибудь полноценные ДЦ есть, возьми да запишись на экскурсию в ДЦ. Тебе расскажут и покажут как устроено и организованно электропитание и его резервирование, может быть даже схему электросети покажут. Да и вопросы свои позадавать сможешь экскурсоводу.
У XEON серверных платформ ставятся ECC планки таким образом, чтобы использовать все доступные каналы c 2х или 4х процессоров.
Desktop платформа с каким-нибудь i7/i9/Ryzen, обычно не более 2х каналов и 1 процессор, поэтому минимально 2 планки в оба канала.
s2.alexws.ru s5.alexws.ru ALEXPG.ru ALEXWY.ru, s6.alexdf.ru, alexdf.ru, в 2023 в апреле с этих доменов спамил из подсетей selectel. Позже светилась подсеть уже aeza, дальше уже надоело отслеживать и просто все домены в blacklist.
Зачем скрывать то, что и так ясно? Полноценные серверные платформы всегда поставляются с DDR ECC памятью, desktop солянки вида 7950x / 12900k и подобные, без ECC. Более того, полноценные серверные платформы есть такие, которые и вовсе обычную non-ECC и non-Reg память не поддерживают. Сервер попросту не загрузиться с другим видом планок. Другое дело, что гении на маркетолохах, как обычно, лишь бы хоть чем-то привлечь внимание и сделать из этого «преимущество». Все эти «NVME», «ECC», «от 5Ghz» и прочие бесполезные приписки, не более чем маркетинг. Тот, кто хоть немного понимает в железе и знает как проверять инфу о железе в ОС, всегда будет иметь понимание что за конфиг ему предлагают. На крайний случай проверит это средствами ОС.
Тогда уж и про OVH следует знать, что они тоже любят просто так блокировать людей. Достаточно несколько раз закинуть abuse на IP адрес из их какой-нибудь их /28 например. И всё, не важно была решена проблема с прежними abuse или нет. У тебя просто удалят подсеть и никакие тикеты тебе ничего не дадут, придётся потом переносить все VM из такой подсети на какие-то другие подсети или лучше даже в другой ЦОД сразу все ноды и VM с таких нод.
ОЗУ или ПЗУ?
Сотни миллионов мелких файлов суммарным объёмом 10+ ТБ, без предварительной их архивации в единый большой файл, вот это действительно долго, независимо от скорости сети между серверами, даже с NVME. Копировать 10-20-100+ ТБ большие файлы — образы по сети не сложно, если сеть хотя бы 1Гбит/с.
А так, да, всё что делается «руками», зачастую занимает МНОГО времени.
Поэтому программисты-хипстеры любят всякие эти новомодные удобные: облака, контейнеры, панельки (и ещё кучу ГОТОВЫХ инструментов), чтобы одну кнопочку нажал и наблюдаешь как «оно» устанавливается, настраивается, раскатывается, дублируется, резервируется и т.д., чтобы сидеть попивать свой любимый смузи/латте эти несколько минут, наблюдая за процессором и затем уже только приступить к своим задачам по написанию говнокода кода.
Основная причина этого шага — сраные спамеры, которые регистрируют кучу VM с разных учётных записей. Второстепенная причина — дополнительный доход в будущем (после беты).
Казалось бы, ну спамят и хрен бы с ними, но тут начинает всплывать другая проблема — чёрные списки, которыми пользуются до сих пор много почтовых сервисов.
И одно дело, когда DNSBL черные списки банят только IP адреса или подсети. Другое дело, когда банят целиком по AS.
Вот тут то к тебе, как к хостеру или дата-центру и приходят легитимные клиенты и задают вопросы, какого их письма с рабочих корп.адресов с их VM/Cloud/Dedicated серверов не доходят до конечных адресов, где используются те самые DNSBL фильтры.
Именно поэтому selectel, как вырастающий гигант на рынке VM/Cloud/Dedicated и прочих продуктов, принял единственное верное решение, забанить всем 25 порт и дать SMTP сервер тем, кому он ДЕЙСТВИТЕЛЬНО нужен для отправки email рассылок и писем.
Лол, они там тебе ещё и угрожают ещё всякими УК статьями?
Все домены этих спамеров, компании разные регают, но по факту одно и тоже:
kipmonitor.com
brandpolgroup.com
katkovpartners.ru
Это легко понять по номерам их внутренней спам-системе, через которую спамят.
Начали спамом этим заниматься с 2019 года. В чёрный список почтового сервера эти домены и любые другие их новые домены добавляй и всё.
Свой спам на бумажном носителе Почтой России или курьером могут прислать, если им так удобнее.
Они, кстати, в курсе за этот говнобаг, он у них и в dcimanager тоже т.к структура dci6/vmgr6 практически схожа.
Решается достаточно просто, достаточно прописать подсеть от docker серую тоже в разрешенную, т.к все действия приходят из бэкенда у них как раз из этой докерной сетки. Обычно это что-то вроде 172.0.0.0/8
Не за что.
Видимо что-то снова не осилили они в плане распределения IPv6, потому что если вспомнить те же 5-е версии их продуктов (DCI5 и VMmgr5), там IPv6 вообще только поштучно могло быть выдано. И если нужно было выдать, скажем, сразу штук 100 хотя бы IPv6 адресов — это был сущий кошмар.
В solusvm2 можно без проблем создать IP-блок (пул), скажем, какой-нибудь XXXX:XXX:X::/56 и в длине префикса задать хоть /64 (если нужно /64 подсеть каждой vm выдавать), либо можно даже /128 без проблем указать.
Но best practice всё же считается /64 для конечных хостов клиентских машин (не важно vm это или bare metal сервер).
Не осилили сортировку по IP, так как стандартные методы сортировки по цифре не совсем корректно упорядочивают IP адреса.
Хотя при этом недавно осилили эту сортировку в DCI6, так что глядишь и в VM6 добавят. Там по сути CTRL_C CTRL_V.
Эту утилиту 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 или распределительном щите, рискуя оставить все серверы в стойке без электропитания.
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 5/7/10кВт или по счётчику (сколько электричества потребил столько и оплатил в месяц), а все остальные затраты (железо, интернет, монтаж и настройка железа в стойку) на тебе, как на клиенте, потому что у тебя собственная стойка со своим железом
— аренда стойки 42 или 48, в которую цод тебе уже поставит свои PDU на каждую фазу, за отдельную плату может быть даже коммутатор какой-то предложат
— юниты в стойке (считай colocation)
В зависимости от того, что подходит клиенту, такую схему взаимодействия с цодом и выбирает клиент.
А юниты — это речь как раз про последний пункт, когда тебе цод под ключ продаёт 1, 2, 3, 4 юнита в стойке, куда ты приехал и воткнул свои серверы. Выдаст даже какую-нибудь /29 или /28 подсеть на эти серверы с 5-15 IP адресами. Ну или за отдельную плату может быть даст тебе какую-нибудь /24 в аренду, если у цода они есть в наличии.
Многие годы, пока на стойку было не более 5-10кВа в среднем по больнице, всех устраивал подход воздушного охлаждения и отведения тепла. Сейчас же, поскольку современное железо, а так же железо с видеокартами под ИИ, становятся всё более и более мощными (горячими), старый подход по охлаждению и отведению тепла перестаёт быть эффективным. Ты говоришь — «модный ДЦ должен иметь до 20-30квт запаса на стойку». Я тебе и отвечаю — ты забываешь про тепло, которое нужно как-то отвести, а так же как-то охладить такие «горячие» стойки. Подвести более толстый кабель с бОльшим запасом по силе тока к стойке — не самая сложная задача. Сложнее всего — организовать отвод тепла и охлаждение 10+ кВт стоек в маш.зале в одном ряду с другими стойками.
Потому что в горячем коридоре, даже у 7кВт стойки, температура в близи 40 серверов будет в среднем на уровне 45 градусов, при постоянно поступающих 23-25 градусах холода (зависит от честности ЦОДа) из холодного коридора. Это уже не мало, и, например, на стойках с 10-12кВт, задняя часть серверов постоянно будет перегрета и это вполне может чаще приводить к выходу из строя серверов, особенно актуально для платформ, у которых стоят PCIe видеокарты или те же NVME накопители через PCIe переходники, ещё и учитывая тот факт что видеокарты и накопители и так греются сильно под нагрузкой и их температуры могут быть тоже на уровне 65-80 градусов в среднем.
Именно поэтому сейчас всё чаще идут разговоры про жидкостное охлаждение стоек, но тоже с разным подходом, когда у тебя условно сразу вся стойка с «плавающими» серверами в ней, в неком диэлектрике или же стойка с водоблоком, который встроен непосредственно в стойку. Серверные платформы с СЖО появляются постепенно на рынке за последние годы. В ЦОДах такие стойки тоже уже появляются, даже в РФ. Например в московском датапро у какой-то клиентской стойки лично видел такой тип охлаждения, когда у стойки система жидкостного охлаждения вмонтирована прям вертикально рядом с ПДУ, имея специальные фитинги подключения СЖО, в которые подключаются трубками серверные платформы. У самих серверных платформ в задней части выходят обычно по 2-4 трубки для включения в эту систему СЖО. Если найду сейчас похожие фотки в гугло-картинках, прикреплю их, чтобы понятнее было о чём речь.
В итоге пройдёт какое-то количество лет, чтобы сменилось ещё пару поколений железа и ЦОДы начнут постепенно строить из гибридных (воздух+сжо), под уже современные серверы с жидкостным охлаждением и тут то твои запросы по 20-30кВт на стойку как раз начнут покрываться.
Если в твоём городе какие-нибудь полноценные ДЦ есть, возьми да запишись на экскурсию в ДЦ. Тебе расскажут и покажут как устроено и организованно электропитание и его резервирование, может быть даже схему электросети покажут. Да и вопросы свои позадавать сможешь экскурсоводу.
Desktop платформа с каким-нибудь i7/i9/Ryzen, обычно не более 2х каналов и 1 процессор, поэтому минимально 2 планки в оба канала.
s2.alexws.ru s5.alexws.ru ALEXPG.ru ALEXWY.ru, s6.alexdf.ru, alexdf.ru, в 2023 в апреле с этих доменов спамил из подсетей selectel. Позже светилась подсеть уже aeza, дальше уже надоело отслеживать и просто все домены в blacklist.
Судя по поддомену это всё тот же спамер.
Сотни миллионов мелких файлов суммарным объёмом 10+ ТБ, без предварительной их архивации в единый большой файл, вот это действительно долго, независимо от скорости сети между серверами, даже с NVME. Копировать 10-20-100+ ТБ большие файлы — образы по сети не сложно, если сеть хотя бы 1Гбит/с.
А так, да, всё что делается «руками», зачастую занимает МНОГО времени.
Поэтому программисты-хипстеры любят всякие эти новомодные удобные: облака, контейнеры, панельки (и ещё кучу ГОТОВЫХ инструментов), чтобы одну кнопочку нажал и наблюдаешь как «оно» устанавливается, настраивается, раскатывается, дублируется, резервируется и т.д., чтобы сидеть попивать свой любимый смузи/латте эти несколько минут, наблюдая за процессором и затем уже только приступить к своим задачам по написанию
говнокодакода.Казалось бы, ну спамят и хрен бы с ними, но тут начинает всплывать другая проблема — чёрные списки, которыми пользуются до сих пор много почтовых сервисов.
И одно дело, когда DNSBL черные списки банят только IP адреса или подсети. Другое дело, когда банят целиком по AS.
Вот тут то к тебе, как к хостеру или дата-центру и приходят легитимные клиенты и задают вопросы, какого их письма с рабочих корп.адресов с их VM/Cloud/Dedicated серверов не доходят до конечных адресов, где используются те самые DNSBL фильтры.
Именно поэтому selectel, как вырастающий гигант на рынке VM/Cloud/Dedicated и прочих продуктов, принял единственное верное решение, забанить всем 25 порт и дать SMTP сервер тем, кому он ДЕЙСТВИТЕЛЬНО нужен для отправки email рассылок и писем.
Все домены этих спамеров, компании разные регают, но по факту одно и тоже:
kipmonitor.com
brandpolgroup.com
katkovpartners.ru
Это легко понять по номерам их внутренней спам-системе, через которую спамят.
Начали спамом этим заниматься с 2019 года. В чёрный список почтового сервера эти домены и любые другие их новые домены добавляй и всё.
Свой спам на бумажном носителе Почтой России или курьером могут прислать, если им так удобнее.
Решается достаточно просто, достаточно прописать подсеть от docker серую тоже в разрешенную, т.к все действия приходят из бэкенда у них как раз из этой докерной сетки. Обычно это что-то вроде 172.0.0.0/8
Не за что.
В solusvm2 можно без проблем создать IP-блок (пул), скажем, какой-нибудь XXXX:XXX:X::/56 и в длине префикса задать хоть /64 (если нужно /64 подсеть каждой vm выдавать), либо можно даже /128 без проблем указать.
Но best practice всё же считается /64 для конечных хостов клиентских машин (не важно vm это или bare metal сервер).
Хотя при этом недавно осилили эту сортировку в DCI6, так что глядишь и в VM6 добавят. Там по сути CTRL_C CTRL_V.