У них сам подход к разработке никак не поменялся после 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 или распределительном щите, рискуя оставить все серверы в стойке без электропитания.
Всё очень просто и от этого напрямую зависит конечная стоимость и управление:
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 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 сервер).
Конечно, разработка в условиях монополизма на отечественном рынке, тоже играет роль в отрицательную сторону. Когда нет конкурирующих продуктов, руководство так и будет ебланить, а страдать будут конечные потребители этого «продукта». Поэтому да. Не рискуй обновлять продукты от 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 или распределительном щите, рискуя оставить все серверы в стойке без электропитания.
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 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 сервер).