Всё очень просто и от этого напрямую зависит конечная стоимость и управление:
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 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.
Не удивительно.
Нам OVH в 2016 вообще удалил 2 подсети /26, на которых работало порядка ~100 виртуалок клиентов, без возможности реабилитации.
Им было абсолютно поебать на email/тикеты по вопросу решения этой ситуации и мирного урегулирования.
Было каких-то 2-3 абузы на IP, в разные месяцы года, на разные IP, виртуалки которых нами блокировались сразу же вместе с аккаунтом такой виртуалки.
На 3-ю абузу, взяли просто заблочили и удалили подсети из аккаунта. Поэтому размещать там что-то серьёзное, ещё и с каким-то серьёзным количеством конечных клиентов, затея не самая разумная.
Чем крупнее компания — тем боле бюрократии. Чем больше бюрократии, тем больше даунов и бесполезных сотрудников, ничего не умеющих и не имеющих каких-либо доступов, чтобы сделать что-то внутри этой самой компании.
Не случайность, скорее плановый осмотр стоек с арендованными серверами, в том числепо индикаторам лампочек на самих платформах. (наличию красных мигающих)
— аренда маш.зала или отдельного ряда в маш.зале
— аренда стойко-места (мест), куда тебе ЦОД подвёл уже заранее электричество, охлаждение, а ты уже покупаешь и ставишь свои стойки, а платишь либо фикс за 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.
Нам OVH в 2016 вообще удалил 2 подсети /26, на которых работало порядка ~100 виртуалок клиентов, без возможности реабилитации.
Им было абсолютно поебать на email/тикеты по вопросу решения этой ситуации и мирного урегулирования.
Было каких-то 2-3 абузы на IP, в разные месяцы года, на разные IP, виртуалки которых нами блокировались сразу же вместе с аккаунтом такой виртуалки.
На 3-ю абузу, взяли просто заблочили и удалили подсети из аккаунта. Поэтому размещать там что-то серьёзное, ещё и с каким-то серьёзным количеством конечных клиентов, затея не самая разумная.