Несколько месяцев назад Cloudflare объявила о переходе на FL2, нашу переработанную на Rust версию основного уровня обработки запросов Cloudflare. Этот переход ускоряет нашу способность помогать создавать лучший Интернет для всех. Благодаря миграции в программном стеке, Cloudflare обновила конструкцию серверного оборудования, улучшив его возможности и повысив эффективность для удовлетворения меняющихся потребностей нашей сети и программного обеспечения. Серверы 13-го поколения оснащены 192-ядерным процессором AMD EPYC Turin 9965, 768 ГБ оперативной памяти DDR5-6400, 24 ТБ хранилища PCIe 5.0 NVMe и двумя сетевыми картами с портами 100 Гбит/с.

13-е поколение предлагает:

• До 2 раз более высокая пропускная способность по сравнению с Gen 12 при сохранении уровня задержки в пределах SLA.
• Повышение производительности на ватт до 50%, что снижает затраты на расширение центров обработки данных.
• Увеличение пропускной способности на стойку до 60% при сохранении постоянного энергопотребления стойки.
• Вдвое больший объем памяти, в 1,5 раза больший объем хранилища, в 4 раза большая пропускная способность сети.
• В дополнение к шифрованию памяти, добавлена ​​поддержка аппаратного шифрования PCIe.
• Улучшена поддержка мощных, требующих интенсивного теплоотвода ускорителей PCIe, устанавливаемых без доработок.

В этой статье в блоге подробно рассматривается инженерное обоснование выбора каждого из основных компонентов: что мы оценивали, что выбрали и почему.





Процессор


На этапе проектирования мы протестировали несколько процессоров AMD EPYC™ 5-го поколения, получивших кодовое название Turin, в аппаратной лаборатории Cloudflare: AMD Turin 9755, AMD Turin 9845 и AMD Turin 9965. В таблице ниже приведены различия в характеристиках кандидатов для серверов 13-го поколения по сравнению с AMD Genoa-X 9684X, используемым в наших серверах 12-го поколения. Следует отметить, что все три кандидата предлагают увеличение количества ядер, но с меньшим объемом кэша L3 на ядро. Однако, благодаря переходу на FL2, новые рабочие нагрузки менее зависимы от кэша L3 и хорошо масштабируются с увеличением количества ядер, обеспечивая увеличение пропускной способности до 100%.

Три представленных процессора предназначены для разных сценариев использования: AMD Turin 9755 предлагает превосходную производительность на ядро, AMD Turin 9965 жертвует производительностью на ядро ​​ради энергоэффективности, а AMD Turin 9845 жертвует количеством ядер ради меньшего энергопотребления сокета. Мы протестировали три процессора в производственной среде.



Почему именно AMD Turin 9965?
Во-первых, FL2 положила конец проблеме нехватки кэша L3.

Кэш L3 — это большой кэш последнего уровня, разделяемый всеми ядрами ЦП на одном вычислительном кристалле для хранения часто используемых данных. Он заполняет пробел между медленной основной памятью, находящейся вне ЦП, и быстрым, но меньшим по размеру кэшем L1 и L2 на ЦП, уменьшая задержку доступа ЦП к данным.

Некоторые могут заметить, что у 9965 всего 2 МБ кэша L3 на ядро, что на 83,3% меньше, чем 12 МБ на ядро ​​у Genoa-X 9684X 12-го поколения. Зачем отказываться от того самого преимущества в кэше, которое дало Gen 12 его превосходство? Ответ кроется в том, как эволюционировали наши рабочие нагрузки.

Cloudflare перешла с FL1 на FL2, полностью переписав свой слой обработки запросов на Rust. Благодаря новому программному стеку конвейер обработки запросов Cloudflare стал значительно менее зависимым от большого кэша L3. Нагрузки FL2 масштабируются почти линейно с количеством ядер, а 192 ядра 9965 обеспечивают двукратное увеличение количества аппаратных потоков по сравнению с Gen 12.

Во-вторых, производительность на единицу общей стоимости владения (TCO). В ходе производственной оценки 192 ядра 9965 показали наибольшее суммарное количество запросов в секунду среди трех кандидатов, а его производительность на ватт благоприятно масштабировалась при TDP 500 Вт, обеспечивая превосходную общую стоимость владения на уровне стойки.



Во-третьих, простота в эксплуатации. Наши оперативные группы отдают предпочтение меньшему количеству серверов с высокой плотностью размещения. Управление парком машин с 192 ядрами означает меньшее количество узлов, которые необходимо выделять, обновлять и контролировать на единицу предоставленных вычислительных ресурсов. Это напрямую снижает операционные издержки в нашей глобальной сети.

Наконец, они обладают обратной совместимостью. Архитектура процессоров AMD поддерживает память DDR5-6400, PCIe Gen 5.0 и CXL 2.0 Type 3 во всех моделях. AMD Turin 9965 имеет наибольшее количество высокопроизводительных ядер на сокет в отрасли, что максимизирует вычислительную плотность на сокет, поддерживая конкурентоспособность и актуальность платформы на долгие годы. Переход с AMD Genoa-X 9684X на AMD Turin 9965 обеспечивает более длительную поддержку безопасности от AMD, продлевая срок службы серверов Gen 13 до того, как они устареют и потребуют обновления.

Память

Поскольку процессор AMD Turin имеет вдвое больше ядер, чем предыдущее поколение, ему требуется больше памяти, как по объему, так и по пропускной способности, для обеспечения увеличения производительности.

Максимальная пропускная способность при использовании 12 каналов.
Выбранный процессор AMD EPYC 9965 поддерживает двенадцать каналов памяти, и для 13-го поколения мы устанавливаем модули во все из них. Мы выбрали 64 ГБ памяти DDR5-6400 ECC RDIMM в конфигурации «один модуль на канал» (1DPC).

Эта конфигурация обеспечивает пиковую пропускную способность памяти 614 ГБ/с на сокет, что на 33,3% больше по сравнению с нашей серверной платформой 12-го поколения. Используя все 12 каналов, мы гарантируем, что процессор никогда не будет испытывать «нехватку» данных, даже при самых ресурсоемких параллельных нагрузках.

Использование сбалансированной конфигурации всех двенадцати каналов памяти — одинаковая емкость на канал, без смешанных конфигураций — является распространенной передовой практикой. Это важно с точки зрения эксплуатации: процессоры AMD Turin используют чередование памяти по всем каналам памяти с одинаковым типом DIMM, одинаковой емкостью памяти и одинаковой конфигурацией ранга. Чередование увеличивает пропускную способность памяти за счет распределения непрерывного доступа к памяти по всем каналам памяти в наборе чередующихся каналов, вместо того чтобы направлять весь доступ к памяти на один или небольшое подмножество каналов памяти.

Оптимальный объем памяти — 4 ГБ на ядро.
Наши серверы 12-го поколения имеют конфигурацию с 4 ГБ оперативной памяти на ядро. Мы пересмотрели это решение при проектировании серверов 13-го поколения.
Cloudflare ежемесячно запускает множество новых продуктов и услуг, и каждый новый продукт или услуга требует всё большего объёма памяти. Со временем это приводит к накоплению объёма памяти, что может стать проблемой нехватки памяти, если объём памяти не будет рассчитан должным образом.
Первоначально предполагалось соотношение памяти к ядру от 4 до 6 ГБ на ядро. При наличии 192 ядер на AMD Turin 9965 это соответствует диапазону от 768 ГБ до 1152 ГБ. Следует отметить, что при больших объемах шаг изменения емкости модуля DIMM обычно составляет 16 ГБ. При 12 каналах в конфигурации 1DPC доступны варианты 12x 48 ГБ (576 ГБ), 12x 64 ГБ (768 ГБ) или 12x 96 ГБ (1152 ГБ).

• 12 x 48 ГБ = 576 ГБ, или 1,5 ГБ на поток. Объем памяти в этой конфигурации слишком мал; это приведет к нехватке памяти для ресурсоемких задач и нарушению нижнего предела.
• 12 x 96 ГБ = 1152 ГБ, или 3,0 ГБ/поток. Это означает увеличение емкости на ядро ​​на 50%, а также приведет к увеличению энергопотребления и существенному росту стоимости, особенно в нынешних рыночных условиях, когда цены на память в 10 раз выше, чем год назад.
• 12 x 64 ГБ = 768 ГБ, или 2,0 ГБ/поток (4 ГБ/ядро). Эта конфигурация соответствует нашему соотношению памяти к ядрам в Gen 12 и представляет собой двукратное увеличение объема памяти на сервер. Сохранение объема памяти на уровне 4 ГБ на ядро ​​обеспечивает достаточную емкость для рабочих нагрузок, масштабируемых с увеличением количества ядер, таких как наша основная рабочая нагрузка, FL, и обеспечивает достаточный запас памяти для будущего роста без избыточного выделения ресурсов.

FL2 использует память более эффективно, чем FL1: наши внутренние измерения показывают, что FL2 использует менее половины ресурсов процессора, чем FL1, и значительно меньше половины памяти. Высвобожденные ресурсы, полученные в результате миграции программного стека, обеспечивают достаточный запас для поддержки роста Cloudflare в течение следующих нескольких лет.

Решение: 12 модулей по 64 ГБ, что в сумме составляет 768 ГБ. Это сохраняет проверенное соотношение 4 ГБ/ядро, обеспечивает двукратное увеличение общей емкости по сравнению с 12-м поколением и остается в оптимальном ценовом диапазоне модулей DIMM.

Повышение эффективности за счет двойного ранга
В Gen 12 мы продемонстрировали, что двухранговые модули DIMM обеспечивают заметно более высокую пропускную способность памяти, чем одноранговые модули, с преимуществами до 17,8% при соотношении чтения и записи 1:1. Двухранговые модули DIMM быстрее, потому что они позволяют контроллеру памяти обращаться к одному рангу, пока другой обновляется. Этот же принцип применим и здесь.

Наши требования также предусматривают пропускную способность памяти примерно в 1 ГБ/с на каждый аппаратный поток. При пиковой пропускной способности в 614 ГБ/с на 384 потоках мы обеспечиваем 1,6 ГБ/с на поток, что значительно превышает минимальный показатель. Анализ производственных условий показал, что рабочие нагрузки Cloudflare не ограничены пропускной способностью памяти, поэтому мы сохраняем этот запас как резерв для будущего роста нагрузки.

Выбрав модули памяти DDR5 RDIMM 2Rx4 с максимальной поддерживаемой частотой 6400 МТ/с, мы обеспечиваем минимальную задержку и наилучшую производительность в конфигурации памяти нашей платформы Gen 13.

Хранилище


В 12-м поколении наша архитектура хранения данных претерпела трансформацию, когда мы перешли от M.2 к EDSFF E1.S. В 13-м поколении мы увеличиваем емкость хранения и пропускную способность, чтобы соответствовать новейшим технологиям. Мы также добавили фронтальный отсек для накопителей, что обеспечивает гибкость и позволяет устанавливать до 10 накопителей U.2, чтобы идти в ногу с ростом продаж продуктов хранения Cloudflare.

Переход на PCIe 5.0
В Gen 13 используются накопители NVMe PCIe Gen 5.0. Хотя Gen 4.0 хорошо себя зарекомендовал, переход на Gen 5.0 гарантирует, что наша подсистема хранения данных сможет передавать данные с меньшей задержкой и справляться с возросшими требованиями к пропускной способности хранилища, предъявляемыми новым процессором.

от 16 ТБ до 24 ТБ
Помимо увеличения скорости, мы физически расширяем массив с двух до трех NVMe-накопителей. Наша серверная платформа 12-го поколения была разработана с четырьмя слотами для накопителей E1.S, но только два из них были заняты 8-терабайтными дисками. Серверная платформа 13-го поколения использует ту же конструкцию с четырьмя доступными слотами для накопителей E1.S, но три из них заняты 8-терабайтными дисками. Зачем добавлять третий диск? Это увеличивает емкость хранилища на сервер с 16 ТБ до 24 ТБ, обеспечивая расширение нашей общей емкости хранилища для поддержания и улучшения производительности кэша CDN. Это также поддерживает прогнозируемый рост для Durable Objects, Containers и сервисов Quicksilver.

Передний отсек для дисков для установки дополнительных накопителей.
Для Gen 13 шасси спроектировано с передним отсеком для накопителей, который может поддерживать до десяти накопителей U.2 PCIe Gen 5.0 NVMe. Передний отсек для накопителей позволяет Cloudflare использовать одно и то же шасси на вычислительных и хранилищных платформах, а также обеспечивает гибкость при необходимости преобразования вычислительной версии в версию для хранения данных.

Выносливость и надежность
Мы проектируем наши серверы с расчетом на 5-летний срок службы и требуем от накопителей ресурс в 1 операцию записи в день (DWPD) на протяжении всего срока службы сервера.

Как Samsung PM9D3a, так и Micron 7600 Pro соответствуют спецификации 1 DWPD с аппаратным резервированием (OP) приблизительно на 7%. Если в будущем потребуется более высокая ресурсоемкость, у нас есть возможность зарезервировать дополнительную пользовательскую мощность для увеличения эффективного OP.

Соответствие стандартам NVMe 2.0 и OCP NVMe 2.0
Как Samsung PM9D3a, так и Micron 7600 используют спецификацию NVMe 2.0 (вместо NVMe 1.4) и спецификацию OCP NVMe Cloud SSD Specification 2.0. Ключевые улучшения включают в себя зонированные пространства имен (ZNS) для более эффективного управления усилением записи, команду Simple Copy Command для перемещения данных внутри устройства без пересечения шины PCIe, а также улучшенную блокировку команд и функций для более жесткого контроля безопасности. Спецификация OCP 2.0 также добавляет расширенные возможности телеметрии и отладки, специально разработанные для работы в центрах обработки данных, что соответствует нашему акценту на управляемость всего парка устройств.

Тепловой КПД
Накопители по-прежнему будут выполнены в форм-факторе E1.S толщиной 15 мм. Большая площадь поверхности корпуса необходима для охлаждения новых контроллеров Gen 5.0, которые могут потреблять до 25 Вт при длительной интенсивной работе. Корпус высотой 2U обеспечивает достаточный воздушный поток над накопителями E1.S, а также отсеками для накопителей U.2, — преимущество, подтвержденное нами в Gen 12, когда мы приняли решение перейти от форм-фактора 1U к 2U.

Сеть


Более восьми лет два порта 25 Гбит/с Ethernet составляли основу нашего парка оборудования. С 2018 года они хорошо нам служили, но по мере совершенствования процессоров для обработки большего количества запросов и масштабируемости нашей продукции мы официально достигли предела своих возможностей. Для 13-го поколения мы вчетверо увеличиваем пропускную способность каждого порта.

Почему именно 100 Гбит/с Ethernet и почему именно сейчас?
Пропускная способность сетевых интерфейсных карт (NIC) должна соответствовать росту вычислительной производительности. При наличии 192 современных ядер наши каналы 25 Гбит/с Ethernet станут ощутимым узким местом. Данные, полученные в ходе недельной эксплуатации наших центров обработки данных по всему миру, показали, что на наших серверах 12-го поколения пропускная способность P95 на порт стабильно превышает 50% от доступной пропускной способности. Поскольку пропускная способность на каждом сервере 13-го поколения удваивается, мы рискуем перегрузить пропускную способность сетевых интерфейсных карт.



Решение перейти на 100 GbE вместо 50 GbE было продиктовано экономическими соображениями отрасли: объемы производства трансиверов 50 GbE остаются низкими, что делает их невыгодным вариантом для цепочки поставок. Два порта 100 GbE также обеспечивают суммарную пропускную способность 200 Гбит/с на сервер, что гарантирует готовность к росту трафика в ближайшие несколько лет.

Выбор оборудования и совместимость
Мы сохраняем нашу стратегию работы с двумя поставщиками, чтобы обеспечить устойчивость цепочки поставок — урок, который мы с трудом усвоили во время пандемии, когда закупка сетевых карт Gen 11 у одного поставщика привела к тому, что мы оказались в затруднительном положении.

Обе сетевые карты соответствуют форм-фактору OCP 3.0 SFF/TSFF со встроенной защелкой, что обеспечивает унифицированность шасси с Gen 12 и гарантирует, что полевым специалистам не потребуются новые инструменты или обучение для замены.

Распределение PCIe
Слот OCP 3.0 NIC на материнской плате имеет выделенные линии PCIe 4.0 x16, обеспечивающие двунаправленную пропускную способность 256 Гбит/с, чего более чем достаточно для двух интерфейсов 100 Гбит/с (суммарная скорость 200 Гбит/с) с запасом.

Управление


Мы сохраняем архитектурный сдвиг, введенный в Gen 12, заключающийся в разделении компонентов управления и безопасности от материнской платы на модуль Project Argus Data Center Secure Control Module 2.0.


Непрерывность работы с DC-SCM 2.0
Мы продолжаем развивать стандарт Data Center Secure Control Module 2.0 (DC-SCM 2.0). Разделяя функции управления и безопасности от материнской платы, мы гарантируем, что «мозг» системы безопасности сервера останется модульным и защищенным.

В модуле DC-SCM размещены наши наиболее важные компоненты:

• Базовая система ввода-вывода (BIOS)
• Контроллер управления материнской платой (BMC)
• Аппаратный корень доверия (HRoT) и TPM (Infineon SLB 9672)
• Два флэш-чипа BMC/BIOS для резервирования

Почему мы продолжаем работу над DC-SCM 2.0
Решение сохранить эту архитектуру для 13-го поколения обусловлено доказанным повышением уровня безопасности, которое мы наблюдали в предыдущем поколении. Перенеся эти функции в отдельный модуль, мы сохраняем:

• Быстрое восстановление: Двойное резервирование образов позволяет практически мгновенно восстановить прошивку BIOS/UEFI и BMC в случае обнаружения случайного повреждения или вредоносного обновления.
• Физическая прочность: В шасси 13-го поколения механизм обнаружения вторжений также смещен дальше от плоского края шасси, что затрудняет физический перехват.
• Шифрование PCIe: В дополнение к технологии TSME (Transparent Secure Memory Encryption) для шифрования данных между процессором и памятью, которая была включена еще в наших платформах 10-го поколения, процессор AMD Turin 9965 для 13-го поколения расширяет шифрование на трафик PCIe, что гарантирует защиту данных при передаче по каждой шине в системе.
• Операционная согласованность: Использование стека управления Gen 12 означает, что наши процедуры аудита безопасности, развертывания, предоставления ресурсов и операционных стандартов остаются полностью совместимыми.

Power


По мере модернизации вычислительных и сетевых возможностей серверов, их энергопотребление, естественно, также увеличилось. Серверы 13-го поколения оснащены более мощными блоками питания для обеспечения необходимой мощности.

Переход к мощности 1300 Вт
В то время как наши узлы 12-го поколения комфортно работали с резервным источником питания 800 Вт 80 PLUS Titanium CRPS (Common Redundant Power Supply), спецификация 13-го поколения требует более мощного источника питания. Мы выбрали резервный источник питания 80 PLUS Titanium CRPS мощностью 1300 Вт.

Потребляемая мощность процессоров Gen 13 в типичном режиме работы выросла до 850 Вт, что на 250 Вт больше, чем 600 Вт у Gen 12. Основными факторами являются процессор с TDP 500 Вт (вместо 400 Вт), удвоение объема памяти и дополнительный NVMe-накопитель.

Почему 1300 Вт вместо 1000 Вт? В существующей экосистеме блоков питания отсутствуют жизнеспособные высокоэффективные варианты мощностью 1000 Вт. Для обеспечения надежности цепочки поставок мы перешли к следующему отраслевому стандарту — 1300 Вт.

Регламент ЕС Lot 9 требует, чтобы серверы, развертываемые в Европейском Союзе, имели блоки питания с КПД при нагрузке 10%, 20%, 50% и 100%, равным или превышающим пороговое значение, указанное в регламенте. Это пороговое значение соответствует требованиям программы сертификации блоков питания 80 PLUS, предусматривающим использование блоков питания титанового класса. Для Gen 13 мы выбрали блоки питания титанового класса, чтобы обеспечить полное соответствие требованиям EU Lot 9 и гарантировать возможность развертывания серверов в наших европейских центрах обработки данных и за их пределами.

Тепловая конструкция: 2U снова приносит свои плоды.
Принятый нами в 12-м поколении форм-фактор 2U1N продолжает приносить свои плоды. В 13-м поколении используются 5 80-мм вентиляторов (против 4 в 12-м поколении) для компенсации возросшей тепловой нагрузки от процессора мощностью 500 Вт. Больший объем вентиляторов в сочетании с характеристиками воздушного потока в 2U-корпусе означает, что вентиляторы работают значительно ниже максимального рабочего цикла при типичных температурах окружающей среды, поддерживая энергопотребление вентиляторов в диапазоне < 50 Вт на вентилятор.

Поддержка ускорителя без дополнительных настроек


Сохранение модульности нашего парка серверов является ключевым требованием к их проектированию. Это требование позволило Cloudflare быстро модернизировать и развернуть графические процессоры по всему миру более чем в 100 городах в 2024 году. В 13-м поколении мы продолжаем поддерживать высокопроизводительные дополнительные карты PCIe.

В 13-м поколении обновлена ​​компоновка корпуса в форм-факторе 2U, адаптированная для поддержки более высоких требований к питанию и теплоотводу. Если в 12-м поколении использовалась только одна двухслотовая видеокарта, то архитектура 13-го поколения теперь поддерживает две двухслотовые карты PCIe.

Стартовая площадка для масштабирования Cloudflare и выведения его на новый уровень.
Каждое поколение серверов Cloudflare — это попытка сбалансировать противоречащие друг другу ограничения: производительность против энергопотребления, емкость против стоимости, гибкость против простоты. Серверы 13-го поколения имеют вдвое больше ядер, вдвое больший объем памяти, вчетверо большую пропускную способность сети, в 1,5 раза больший объем хранилища и обеспечивают перспективность для развертывания в ускоренном режиме — и все это при одновременном снижении общей стоимости владения и сохранении надежного набора функций управления и уровня безопасности, которые требуются нашему глобальному парку серверов.

Серверы 13-го поколения полностью сертифицированы и будут развернуты для обработки миллионов запросов в глобальной сети Cloudflare в более чем 330 городах. Как всегда, стремление Cloudflare к максимально эффективному предоставлению услуг в Интернете на этом не заканчивается. По мере начала развертывания 13-го поколения мы планируем архитектуру для 14-го поколения.

Если вас вдохновляет возможность внести свой вклад в создание лучшего интернета, присоединяйтесь к нам. Мы набираем сотрудников www.cloudflare.com/careers/jobs/

Бизнес ожидает от СХД простых характеристик — чтобы данные были доступны всегда, а сбои и обслуживание не останавливали работу виртуальных машин и сервисов. Именно поэтому программно-определяемые хранилища становятся распространенным инструментом. На примере SpaceVM разбираем, как за считанные минуты собрать отказоустойчивое кластерное SDS, которое решает сразу несколько ключевых задач: снижает стоимость владения и обеспечивает стабильную работу в реальных условиях эксплуатации.

Вопрос о том, зачем вообще нужны программно-определяемые хранилища не лишен смысла. Объемы данных, которые приходится хранить бизнесам, постоянно растут, емкость хранилищ приходится постоянно наращивать, а многим компаниям приходится, к тому же, еще и обеспечивать соответствие требованиям регуляторов. Но стоимость аппаратных СХД и объем инвестиций в них перевешивают – и компании задумываются о переходе на SDS.

Они не только дешевле в принципе – экономия становится еще заметнее, если приходится иметь дело с неструктурированными данными. Есть и другие преимущества: можно абстрагироваться от аппаратной платформы и успешно побороть пресловутый vendor-lock. (это особенно важно в России), компании куда проще обеспечить независимость от вендорских санкций.

Программно-определяемые хранилища перестают быть экспериментальным решением в тот момент, когда инфраструктура выходит за рамки одного сервера или одной задачи. Рост числа виртуальных машин, регулярное расширение дисковой емкости и требования к высокой доступности данных быстро делают классическую СХД узким местом. В этот момент выбор SDS становится не вопросом технологий, а способом сохранить управляемость и предсказуемость инфраструктуры.

Наиболее заметно преимущества SDS проявляются в прикладных сценариях, с которыми сталкивается большинство компаний. Виртуализация «1С», CRM и биллинговых систем требует отказоустойчивости без кратного роста стоимости. VDI и удаленные рабочие места чувствительны к задержкам и неравномерной нагрузке. Файловые хранилища с неструктурированными данными плохо масштабируются в рамках монолитных массивов. Во всех этих случаях традиционные СХД начинают ограничивать развитие сервисов, а не поддерживать его.

Сложность заключается в том, что в разных виртуальных средах создание и управление SDS осуществляется тоже по-разному. О том, как решается эта задача на платформе SpaceVM, расскажем далее. При этом сфокусируемся на создании кластерного хранилища, которые становятся все более популярны благодаря своим надежности, простой масштабируемости и управлению.

Готовим сеть
Кластерное программно-определяемое хранилище в SpaceVM строится по многоуровневой архитектуре, в которой вычисления, сеть и хранение логически разделены, но управляются из единого контура.

На нижнем уровне располагаются физические серверы с локальными дисками, объединенными в RAID-массивы. Выше находится слой SDS на базе GlusterFS, который отвечает за агрегацию дискового пространства, репликацию данных и отказоустойчивость. Гипервизор SpaceVM использует этот слой как общее хранилище для образов дисков qcow2 виртуальных машин, абстрагируясь от конкретного оборудования.

На уровне каждого узла SpaceVM использует ZFS для управления локальными дисками и формирования разделов (бриков). Поверх ZFS-пулов строится кластерный слой SDS на базе GlusterFS, который отвечает за репликацию данных и их распределение между серверами. Такое разделение позволяет независимо управлять локальной надежностью хранения и кластерной отказоустойчивостью.

С точки зрения потоков данных виртуальная машина работает с единым логическим томом, тогда как внутри кластера операции записи и чтения распределяются между узлами с учетом выбранного типа тома и уровня репликации. Такое разделение позволяет масштабировать хранилище и вычислительные ресурсы независимо, устранять единичные точки отказа и обслуживать отдельные узлы без остановки сервисов. Именно поэтому корректная настройка сети и понимание архитектуры кластера становятся ключевыми факторами стабильной работы SDS.


Начинаем, конечно, с того, что вводим в панели администратора название сети (назовем ее для простоты Gluster), даем ее описание и, если требуется, указываем адрес подсети. Затем выбираем необходимый сервер и интерфейс, через который будет работать кластерный транспорт, — в нашем случае это будет 10 Гбит. В демонстрации используется сеть 10 Гбит; в реальных инсталляциях допустимы иные параметры, если они соответствуют требованиям по пропускной способности и задержкам.

Использование интерфейсов 10 Гбит для кластерного транспорта обусловлено не «запасом на будущее», а реальными нагрузками SDS. При активной записи и репликации данных сеть 1 Гбит быстро становится узким местом, что приводит к росту латентности и деградации производительности виртуальных машин. В кластере из нескольких узлов такие ограничения усиливаются, поэтому 10 Гбит рассматривается как базовый уровень для стабильной работы программно-определяемого хранилища.


Здесь же есть возможность агрегированный интерфейс. Нам потребуется еще создать внутренний интерфейс на каждом из серверов – у нас их будет три, для каждого будет актуальна та же самая процедура.


Затем проверяем настройки сети, при необходимости вводим тег VLAN и меняем MTU. Настройки MTU и VLAN оказывают заметное влияние на работу кластера. Использование увеличенного MTU позволяет сократить накладные расходы при передаче больших объемов данных, однако требует единообразной настройки на всех узлах и сетевом оборудовании.

Некорректные или неоднородные параметры сети могут приводить к трудно диагностируемым ошибкам, которые внешне проявляются как проблемы хранилища.

Далее, можно добавить резервированные пулы адресов. И после этого запускаем процесс создания сети.


После того, как она создана, нужно создать кластерный транспорт.


Для этого нужно зайти в кластерные хранилища, ввести в них название кластерного транспорта, задаем для него описание и выбираем созданную нами внешнюю сеть. Это нужно для того, чтобы трафик проходил именно через нее.

Подготовка хранилищ на узлах


Следующий шаг – подготовка хранилищ на узлах созданной сети. Для этого нам надо сформировать массивы RAID на каждом из серверов. Выбираем тип RAID: доступны stripe, mirror, RAIDZ1 и RAIDZ2 — это реализации отказоустойчивых схем хранения на уровне ZFS, функционально сопоставимые с RAID5 и RAID6, но реализованные с учетом архитектуры файловой системы. Тип RAID на узлах следует выбирать с учетом профиля нагрузки и логики работы SDS.

Зеркальные конфигурации обеспечивают минимальные задержки и предсказуемую производительность, тогда как схемы с контролем четности позволяют эффективнее использовать емкость. Важно учитывать, что локальный RAID не заменяет кластерную репликацию, а дополняет ее, снижая вероятность потери данных и ускоряя восстановление при отказах.

Можно собрать RAID из подключенных LUN, расположенных на внешнем хранилище iSCSI или FC. Для каждого массива вводится название и, опционально, описание. Эта процедура повторяется на каждом из серверов.


У каждого из серверов нам доступен просмотр статуса, монтаж и демонтаж дисков, выключение устройства для обслуживания. Можно также получить расширенные сведения ZFS тома, добавить устройства для горячей замены и расширить пулы в случае добавления дисков.

Создание SDS-тома
Следующий этап – создание программно-определяемого тома. Для этого в интерфейсе управления есть отдельный раздел. В нем выбираем функцию создания, определяем тип тома, реплицированный или дисперсный. Первый потребуется для обеспечения отказоустойчивости и надежности, второй позволяет объединять RAID различного размера, а кроме того, может обеспечивать более высокую производительность в ряде сценариев, в зависимости от профиля нагрузки и конфигурации кластера.


В нашем случае выберем реплицированный том, затем транспорт, через который будет работать том и пулы хранилищ из числа созданных на предыдущем этапе. В рамках демонстрационного кластера мы используем реплицированный том как наиболее универсальный вариант.

Кроме того, нужно выбрать размер записи, указать значение репликации тома (оно равно количеству томов).

Опционально можно указать использование арбитра — логического компонента, который не хранит пользовательские данные, а используется для обеспечения кворума и предотвращения split-brain-сценариев при отказе одного из узлов кластера.

SpaceVM позволяет создать пул данных автоматически – статус выполнения задания можно отследить в нижней части интерфейса.

Проверка пула данных


После того, как SDS-тома созданы, можно для каждого из них посмотреть, к каким серверам он смонтирован, проверить их доступность и активность. После создания тома стоит проверить через пул данных его корректность и объем.



Проверить надо и кластерный транспорт. На соответствующей вкладке можно видеть, что он подключен ко всем серверам, получить расширенные сведения о состоянии транспорта.

Проверка работоспособности
Затем, конечно, нужно проверить созданный SDS в работе.


Для этого нужно в соответствующем разделе выбрать виртуальную машину и перенести ее на созданный том. В ручном режиме выбираем пул ресурсов для миграции, режим с переносом локальных дисков, сеть, к которой будет подключена виртуальная машина и запускаем процесс миграции.

Миграция при этом происходит бесшовно, она продолжает работать во время переноса.

Отказоустойчивость
В такой конфигурации отказоустойчивость обеспечивается на двух уровнях: за счет локальных RAID-массивов на каждом сервере и за счет кластерной репликации данных между узлами. Это позволяет переживать отказ отдельных дисков или одного сервера без потери данных и остановки сервисов при соблюдении требований к кворуму кластера.

Как видим, процесс создания SDS-хранилища в среде SpaceVM укладывается в типовой рабочий сценарий администратора. Все основные операции выполняются через интерфейс управления и не требуют ручной настройки на уровне CLI. В демонстрационной конфигурации развертывание занимает минимальное время, тогда как в продакшене сроки и параметры могут варьироваться в зависимости от архитектуры, оборудования и требований к отказоустойчивости.

spacevm.ru/space-vm/
spacevm.ru/spacevm-essentials-plus-kit/
spacevm.ru/space-cloud/

Облачные среды, отказоустойчивые кластеры и платформы виртуализации требуют от хранилищ не только надежности, но и поддержки одновременного доступа. В этих условиях традиционные файловые системы (EXT4, NTFS, XFS и др.) оказываются недостаточными — они не рассчитаны на работу с общими блочными устройствами между несколькими узлами. Одним из решений может стать кластерная файловая система, и одной из самых зрелых в этом классе является GFS2 (Global File System 2).

Современные ИТ-инфраструктуры часто строятся вокруг виртуализации и облаков, где несколько серверов одновременно обращаются к одним и тем же данным. В таких системах ключевым становится не просто объем или скорость хранилища, а способ доступа к данным — общий или локальный, файловый или блочный. От того, как именно организовано взаимодействие с хранилищем, зависит архитектура всего решения: от производительности виртуальных машин до отказоустойчивости кластера.

Локальные хранилища привычны для одиночных серверов: диск или массив принадлежит конкретному узлу, который управляет им напрямую. Общие (shared) хранилища, напротив, предоставляют единое пространство данных для нескольких серверов. Именно они лежат в основе высокодоступных кластеров и виртуализационных платформ, где важно, чтобы виртуальные машины могли мигрировать между узлами без потери доступа к своим дискам.

Но общий доступ — это не только вопрос архитектуры, но и способа взаимодействия с данными. Файловые протоколы (NFS, SMB и др.) дают возможность работать с файлами на уровне операционной системы, но вносят дополнительные задержки и ограничения. Блочные протоколы (iSCSI, Fibre Channel) предоставляют более низкоуровневый доступ — сервер видит удаленное устройство как локальный диск. Однако при этом возникает другая проблема: как синхронизировать работу нескольких узлов с одним и тем же блочным устройством, не разрушив файловую систему?

Ответ на этот вызов дают кластерные файловые системы, специально разработанные для совместного блочного доступа. Одна из самых зрелых и функциональных среди них — GFS2 (Global File System 2). В нашем опыте ее интеграция в собственный продукт — платформу виртуализации SpaceVM — позволила приблизиться к созданию устойчивой, масштабируемой и по-настоящему отказоустойчивой среды.

SpaceVM — собственная разработка компании, платформа виртуализации на базе гипервизора KVM. Своего рода аналог vSphere от VMware, адаптированный под отечественные реалии и высокую степень автоматизации, это программный комплекс для управления вычислительными кластерами, автоматизации развертывания виртуальных машин и балансировки ресурсов между узлами. В его основе — идея унифицированного управления инфраструктурой: от гипервизора до сетевых и дисковых подсистем, с акцентом на прозрачность процессов и возможность интеграции с существующими ИТ-ландшафтами.

С использованием GFS2 достигается эффект, сопоставимый по удобству и стабильности с использованием VMFS в продуктах VMware — с открытым исходным кодом и возможностью глубокой адаптации под нужды отечественных заказчиков.

В архитектуре платформы стояла задача обеспечить общий доступ к блочному хранилищу между узлами кластера — без потери целостности данных и с возможностью одновременной работы виртуальных машин. При этом многие заказчики ожидали получить функциональность, сопоставимую с VMFS, используемой в продуктах VMware. Эти два требования сошлись в одной точке: для реализации такой модели доступа мы выбрали GFS2 — кластерную файловую систему, по принципам работы близкую к VMFS, но основанную на открытом коде и допускающую глубокую адаптацию под особенности отечественной инфраструктуры.

GFS2: преимущества архитектуры и механизма блокировок
GFS2 — это POSIX-совместимая кластерная файловая система, разработанная для работы с общими блочными устройствами, подключенными по Fibre Channel или iSCSI. Ее ключевая особенность — координация доступа к метаданным и содержимому файлов при помощи распределенного менеджера блокировок DLM (Distributed Lock Manager).

Это позволяет гарантировать целостность данных даже при одновременном доступе с нескольких узлов. В отличие от NFS или SMB, где блокировки файлов координируются через сеть, GFS2 использует механизм локальных блокировок. Это принципиальное отличие: при сетевых файловых системах каждая операция блокировки требует удаленного вызова — будь то RPC-запрос или SMB-пакет — и ожидания ответа от сервера. Такие сетевые транзакции неизбежно добавляют задержку, особенно при высокой нагрузке или нестабильных сетевых условиях.



В GFS2 же блокировки реализованы на уровне узлов кластера с использованием локальных ресурсов ОС и специализированных сервисов. Это значит, что большинство операций синхронизации выполняется без сетевых вызовов, напрямую внутри ядра или через быстрые механизмы обмена между узлами. Благодаря этому GFS2 обеспечивает более предсказуемое время отклика и лучшую масштабируемость при росте количества клиентов, чем файловые протоколы NFS или SMB.

По сравнению с прямым пробросом блочных устройств в виртуальные машины, GFS2 предлагает более безопасный и управляемый способ совместного доступа к данным, не жертвуя скоростью и устойчивостью файловой системы.

GFS2 демонстрирует сбалансированный и технологически обоснованный подход к организации доступа к общим данным, выгодно отличаясь как от сетевых решений вроде NFS или SMB, так и от схем прямого подключения блочных устройств без кластеризации.

В сетевых файловых системах вся работа с данными происходит через удаленный сервер — каждая операция чтения, записи или блокировки требует сетевого запроса и подтверждения. Это упрощает администрирование, но создает точку отказа и ограничивает масштабирование: при росте нагрузки сервер становится узким местом, а задержки на уровне сети напрямую влияют на производительность.

В противоположность этому, при прямом пробросе блочного устройства (или подход называемый SharedLVM) в несколько узлов вся логика управления данными перекладывается на хосты. Такой подход обеспечивает высокую скорость, но лишен механизмов согласования и защиты целостности: две машины могут записать разные данные в один и тот же блок, разрушив файловую систему.

GFS2 решает обе проблемы одновременно. Она обеспечивает одновременный блочный доступ к устройству, но при этом использует встроенные кластерные механизмы — журналирование, распределенный менеджер блокировок (DLM) и систему метаданных, общую для всех узлов. За счет этого данные остаются согласованными, а операции синхронизации происходят быстрее, чем в сетевых файловых системах, поскольку выполняются на уровне ядра и не требуют посредничества сервера. Таким образом, GFS2 сочетает надежность и консистентность сетевых решений с низкими задержками и эффективностью блочного доступа.

Второе важное преимущество — масштабируемость. Архитектура GFS2 допускает одновременный доступ к файловой системе с большого числа узлов, не требуя специальных клиентских или серверных реализаций. Это делает ее пригодной для использования как в компактных конфигурациях с 2–3 серверами, так и в полноценных кластерах с десятками узлов.

При этом поддержка iSCSI и Fibre Channel дает гибкость в выборе СХД и не требует полной перестройки инфраструктуры.

Третье — отказоустойчивость. В отличие от решений, где потеря одного узла может повлечь за собой повреждение данных или зависание всей файловой системы, GFS2 умеет корректно обрабатывать сбои.

Механизмы fencing и quorum позволяют изолировать некорректно работающий узел, предотвращая split-brain и обеспечивая консистентность хранилища. Это особенно важно в условиях непрерывной работы платформ виртуализации, где потеря доступности даже части пула данных может повлечь каскадный отказ сервисов.

Наконец, GFS2 упрощает администрирование за счет единого пространства имен и поддержки различных форматов данных. Это позволяет централизованно управлять пулами хранения и использовать привычные средства резервного копирования, миграции и диагностики. Для конечного пользователя это выражается в предсказуемом поведении системы и возможности разворачивать кластерные решения без глубокого погружения в особенности конкретных СХД или драйверов.

На фоне альтернатив — GlusterFS, CEPH, Lustre — GFS2 занимает уникальное положение: это именно кластерная файловая система, работающая поверх одного общего устройства хранения, а не распределенная система с репликацией. Что делает ее особенно актуальной для сценариев, где важна экономия места, контроль над изоляцией данных и высокая предсказуемость поведения I/O.

Для чего мы используем GFS2 в SpaceVM
Одной из ключевых архитектурных задач в SpaceVM стало обеспечение полноценного доступа к общему хранилищу с возможностью запуска и миграции виртуальных машин на любых узлах кластера. Без использования внешней кластерной файловой системы это невозможно реализовать корректно.



В виртуализированной инфраструктуре, где диски ВМ хранятся на сетевых LUN, только кластерная файловая система обеспечивает безопасный параллельный доступ с нескольких узлов, защиту от повреждения данных и поддержание высокой доступности. Именно в этом контексте в архитектуру SpaceVM была интегрирована GFS2 как штатный компонент хранилищ виртуальных машин.

Благодаря GFS2, платформа получает следующие возможности, критически важные для промышленного использования:

• Хранение образов ВМ в виде файлов (формата qcow2) на общем устройстве, доступном всем серверам одновременно;
• Реализация высокой доступности (HA) за счет возможности мгновенного запуска виртуальной машины на любом из узлов без предварительной миграции её диска;
• Поддержка динамического перераспределения ресурсов (DRS), включая live migration, без необходимости вручную управлять блочными устройствами;
• Использование моментальных снимков, клонов и тонких дисков, с одновременной защитой от потерь данных при overcommit-сценариях — благодаря механизмам блокировок GFS2;
• Выполнение требований безопасности, предъявляемых заказчиками: например, возможность использовать атрибуты безопасности на уровне файлового слоя, чего невозможно достичь при прямом пробросе блочных устройств в ВМ.

GFS2 в SpaceVM — не просто еще один способ монтировать хранилище, а полноценный архитектурный уровень, обеспечивающий устойчивость, управляемость и безопасность всей платформы.

Однако простая интеграция GFS2 в SpaceVM оказалась невозможной. Нужно было добиться не только корректной работы файловой системы, но и органичной интеграции в архитектуру SpaceVM, где свои требования к кластерному транспорту, управлению ограждением узлов и мониторингу.

Архитектура и технические сложности
Файловая система GFS2 не существует в изоляции — она требует работы в составе кластера и взаимодействует с рядом системных компонентов, формирующих так называемый кластерный транспорт. В этой архитектуре важны не только сама файловая система, но и сопутствующий ИТ-ландшафт, обеспечивающий согласованность операций, отказоустойчивость и синхронизацию между узлами.

В первую очередь, GFS2 включает в себя менеджер DLM, который отвечает за координацию доступа к метаданным и содержимому файлов. Чтобы избежать ситуаций типа split-brain и гарантировать консистентность, применяется механизм ограждения (fencing), реализуемый через SBD (Storage-Based Death), чаще всего с использованием аппаратного watchdog-интерфейса IPMI.

Файловая система GFS2 не работает автономно — она является частью кластерной инфраструктуры и требует взаимодействия с рядом системных сервисов, которые обеспечивают согласованность доступа и защиту данных. В отличие от обычных файловых систем, где единственный узел управляет диском, в кластере одновременно несколько машин читают и записывают данные на одно и то же блочное устройство. Это создает типичные распределенные проблемы — от гонок за блокировки до рассинхронизации метаданных при сбоях узлов.

Чтобы избежать подобных ситуаций, GFS2 использует DLM. Он координирует доступ к метаданным и содержимому файлов, гарантируя, что ни один узел не изменит данные, пока другой с ними работает. Механизм блокировок распределенный, но выполняется внутри кластера, без участия центрального сервера, что снижает задержки и устраняет единую точку отказа.

Однако даже с DLM остаются риски, связанные с частичными сбоями — например, когда узел теряет связь с сетью, но продолжает считать себя активным. Чтобы предотвратить разрушение данных в таких сценариях, применяется механизм fencing — изоляции или «отключения» проблемного узла. В GFS2 это реализуется через SBD (Storage-Based Death), который хранит управляющие метки на общем хранилище и при необходимости инициирует аппаратный перезапуск узла через интерфейс IPMI или watchdog. Таким образом, система сохраняет консистентность даже в условиях сетевых сбоев и частичных отказов, что критически важно для кластерной файловой системы.

Кластерный транспорт GFS2 опирается на стек Corosync — это системный уровень, обеспечивающий коммуникацию между узлами и согласование их состояний. Важной частью надежной работы всей системы является синхронизация времени на всех узлах, обеспечиваемая через NTP: даже небольшие расхождения могут привести к рассогласованию в блокировках или ложным срабатываниям watchdog-механизма.


Кроме того, для подключения LUN в инфраструктуре используются утилиты multipath-tools (в случае Fibre Channel) и open-iscsi (для iSCSI). Они обеспечивают корректное определение, маршрутизацию и управление путями к блочным устройствам, поверх которых и разворачивается файловая система GFS2.

GFS2 — целостная кластерная подсистема, в которой управление доступом, синхронизацией, диагностикой и восстановлением после сбоев вынесено на уровень кластера.

К системе/кластеру предъявляется ряд требований: строгое время синхронизации между узлами, устойчивость к потере сетевого трафика и возможность автоматического fencing'а при ошибках. Любые отклонения ведут к перезагрузкам узлов или развалу кластера.

Трудности при развертывании GFS2: от теории к полевым реалиям
Хотя GFS2 — зрелая и мощная технология, ее внедрение в реальной инфраструктуре связано с рядом инженерных сложностей. Эти проблемы не всегда очевидны на этапе проектирования, но проявляются в момент масштабирования, нагрузки или интеграции в существующую платформу. Наш опыт развертывания GFS2 в составе SpaceVM показал: надежная работа кластерной файловой системы требует учета множества низкоуровневых факторов.

• Один из критических аспектов — синхронизация времени между узлами. GFS2 использует DLM и SBD, которые чувствительны даже к незначительным расхождениям во времени. Практика показала: если разница между узлами превышает 60 секунд, возможны некорректные решения по кворуму или ошибочные fencing-сценарии. Поэтому требуется жесткая настройка NTP-инфраструктуры с контролем точности синхронизации вплоть до миллисекунд.
• Следующая проблема — сетевые коллизии. При использовании iSCSI поверх общей инфраструктуры наблюдались случаи, когда трафик от виртуальных машин перекрывал каналы кластерного транспорта. Это приводило к задержкам, потере пакетов и, как следствие, рассинхронизации между узлами, развалу кворума и перезагрузкам. Особенно остро это проявлялось при объединении сетевых интерфейсов по LACP: реализация агрегации каналов у разных производителей оборудования иногда конфликтовала с работой iSCSI, вызывая нестабильные и трудноотлавливаемые ошибки. Мы отказались от LACP в пользу Active-Backup-режима, обеспечив тем самым предсказуемую работу с минимальной зависимостью от поведения сетевого оборудования.
• Отдельного внимания требует механизм ограждения через аппаратный watchdog. В нашем случае это IPMI-интерфейс, который должен реагировать на команды от SBD каждые 5 секунд. Однако в ряде инсталляций IPMI не успевал обработать запросы вовремя — из-за параллельных обращений от других сервисов или под нагрузкой. Это приводило к ложным fencing-сценариям: узел перезагружался без реальной причины. Решение — настройка возможности изменения таймаута watchdog’а и тщательное тестирование поведения IPMI на каждом типе оборудования.

Также важно отметить трудности, возникающие при блокировке монтирования LUN. В случае некорректного завершения работы или проблем с доступом к СХД, файловая система могла зависать в состоянии ожидания, блокируя операции на уровне ядра. Требовались либо перезагрузка узла, либо использование низкоуровневых утилит для разблокировки ресурса.

Подобные случаи невозможно игнорировать в продуктивной системе, и мы встроили в SpaceVM механизмы предиктивной диагностики, позволяющие заранее идентифицировать потенциальные блокировки по косвенным признакам.

Интеграция GFS2 в платформу виртуализации
Интеграция GFS2 в платформу виртуализации SpaceVM потребовала глубокого осмысления архитектуры кластерного транспорта и адаптации логики GFS2 под централизованную модель управления. В отличие от классического использования GFS2 в кластерах с ручной настройкой, здесь требовалось встроить файловую систему в оркестратор, который сам управляет вычислительными узлами, хранилищами и службами мониторинга через API и веб-интерфейс.

Одна из ключевых проблем заключалась в несовместимости базовой логики GFS2 с концепцией SpaceVM. GFS2 ставит во главу угла сохранность данных: при любых ошибках, нарушениях кворума или сбоях с доступом к хранилищу система инициирует ограждение узла, то есть его принудительную перезагрузку. Напротив, SpaceVM ориентирован на непрерывную доступность ВМ и динамическую работу с узлами — даже при частичных деградациях инфраструктуры.

В результате потребовалось реализовать механизм точной настройки поведения GFS2 через интерфейс платформы, чтобы у администратора была возможность балансировать между отказоустойчивостью хранения и живучестью вычислительного пула.

Также было необходимо централизовать управление кластерным транспортом. В классическом варианте администратор вручную настраивает corosync, DLM, SBD, конфигурирует кольца, задает пороги кворума и поведение watchdog. В SpaceVM же вся эта конфигурация задается через API и визуальный мастер (wizard) создания GFS2-пула. Он позволяет в одном окне:

• выбрать диски,
• указать тип монтирования,
• настроить кластерный транспорт и fencing,
• развернуть файловую систему.

Эта автоматизация особенно важна, поскольку GFS2 имеет высокий порог входа в плане требований к администратору. Ручная настройка — сложна и не масштабируется. Внедрение через интерфейс SpaceVM снимает барьер для широкого использования технологии.


Мы внедрили централизованную валидацию настроек, автоматическое создание кластерного транспорта, подключение или отключение ограждений узлов, а также поддержку резервных сетей на базе протокола SCTP — они выбираются из UI и позволяют без прерывания работы переключаться между каналами связи.

На уровне гипервизора также произошла серьезная интеграция. Контроллер SpaceVM передает вычислительным узлам команды через GRPC, синхронизируя настройки кластера, хранилищ и дисков. Все компоненты — от планировщика задач и очередей до сервисов синхронизации — взаимодействуют через собственную распределенную архитектуру. В этом окружении GFS2 стала частью общей системы: она управляется не вручную, а автоматически, через механизмы модулей Puppet, SSH-контроллеров и специализированных микросервисов.

Особое внимание мы уделили типам монтирования и поведению ограждений. В GFS2 предусмотрены два основных сценария fencing’а:

• При потере кворума кластерного транспорта (split-brain).
• При ошибках записи или потере связи с блочным хранилищем.

Мы реализовали возможность включать или отключать каждый из этих типов независимо, а также контролировать режим монтирования LUN (например, errors=panic или debug). В результате администратор получает не «чёрный ящик», а управляемую систему, где последствия сбоев можно смоделировать и задать заранее.

Также были предприняты меры по валидации некорректных состояний:

• перед созданием нового транспорта проверяются конфигурации всех оставшихся узлов;
• при попытке монтирования система автоматически выявляет заблокированные LUN и предотвращает зависание задачи;
• по умолчанию отключена устаревшая опция создания дисков с полным выделением пространства (full), вместо неё используется falloc — это снижает нагрузку на GFS2 и исключает ошибки при записи.

Таким образом, мы не просто подключили GFS2 как файловую систему — мы встроили её в архитектуру платформы виртуализации, превратив в управляемый, безопасный и масштабируемый компонент. Получилась не просто интеграция, а полноценная унификация двух миров: надёжного хранения и гибкой оркестрации вычислений.

Оптимизация производительности
Однако даже после корректной настройки GFS2 может демонстрировать нестабильную производительность. В процессе внедрения мы протестировали и включили ряд оптимизаций:

• BFQ-алгоритм планирования ввода-вывода, сглаживающий пики нагрузки между ВМ;
• Обязательное использование virtio и hyper-v оптимизаций для улучшения взаимодействия между хостом и гостевыми ОС;
• Отказ от метода выделения диска full в пользу falloc — это устраняет ошибки записи и уменьшает нагрузку на подсистему хранения.

Итоги: GFS2 — зрелое решение с инженерной спецификой
GFS2 — мощный инструмент, который требует глубокого понимания. Его сила — в контроле над данными, гибкости и отказоустойчивости. Чтобы получить все преимущества его использования нужно глубокое понимание принципов его работы, особенно если разворачивать его «сбоку», не связывая с платформой.

Сложность GFS2 — это не недостаток, а плата за мощь. Осознавая это, разработчики SpaceVM провели кропотливую работу по ее комплексной интеграции в свою платформу.

В результате, то, что в изоляции воспринималось как слабость (чувствительность к среде, сложность настройки), было устранено. Пользователь получает всю силу GFS2 — контроль, гибкость, отказоустойчивость — через доступный интерфейс, автоматизацию и диагностику SpaceVM.

Мы добились того, чего ждали от VMFS в отечественном исполнении: общего хранилища, совместимого с кластерами, виртуальными машинами и требованиями безопасности. А главное — доказали, что даже сложные opensource-компоненты могут органично встраиваться в коммерческие платформы, если подойти к этому как инженеры.

spacevm.ru/space-vm/
spacevm.ru/spacevm-essentials-plus-kit/
spacevm.ru/space-cloud/

Зарубежные панели управления хостингом cPanel и Plesk прекратят поддержку пользователей в России с 31 марта

Американская компания WebPros International LLC, выступавшая глобальным дистрибьютором лицензий на популярнейшие панели управления хостингом cPanel и Plesk, уведомила российских партнеров о полном прекращении обслуживания клиентов из России с 31 марта 2026 года. В этих условиях крупнейший российский хостинг-провайдер Рег.ру запустил программу бесплатного переноса сайтов для всех пользователей.

Совокупная доля использования cPanel и Plesk в РФ, по оценке ispmanager (по отпечаткам сервисов на IP-адресах), сократилась до 5%. Однако даже оставшиеся 5% представляют собой значительный массив данных: по данным Рег.ру, речь идет как минимум о 50 тысячах сайтов только в доменной зонах .ru и.рф, которые всё еще работают под управлением зарубежных платформ и теперь вынуждены срочно искать альтернативы.

Пользователи могут потерять не только доступ к панелям управления и API, но и рискуют столкнуться с остановкой работы ресурсов из-за сбоев в настроенных системах автоматизации. В Рег.ру сообщили о полной технической готовности к миграции не только своих клиентов, пользующихся cPanel и Plesk, но предложили всем владельцам любых сайтов бесплатную помощь.

«Мы запустили программу бесплатного переноса как на наш хостинг, так и на облачные и VPS-серверы. Пользователи смогут мигрировать свои проекты на альтернативные платформы, к примеру на ispmanager. Наша задача — помочь клиентам сохранить работоспособность их бизнеса и пройти переход с минимальными потерями без ущерба для доступности сайтов», — пояснил Валентин Бостанов, руководитель департамента хостинга Рег.ру.
www.reg.ru/hosting/transfer#cloud

В Рег.ру подчеркивают, что бесплатный перенос позволит минимизировать эти риски и сохранить работоспособность сайтов без перерывов в обслуживании. С подробной инструкцией по миграции можно ознакомиться на сайте.

ВАЖНО. Временно отключены начальные тарифы START в локации РФ и ЕС.
Испытываем большой наплыв заказов. Ресурсы быстро заканчиваются.

ihor.online/vds

Компания GTHost рада сообщить, что наш дата-центр в Милане теперь подключен к нейтральной точке доступа Milan Neutral Access Point (MINAP), расположенной на территории кампуса Via Caldera в Милане, Италия.

Интеграция пиринга улучшает маршруты, снижает задержку и повышает общую производительность сети для трафика, исходящего из Милана или проходящего через него. Подключаясь к MINAP, GTHost расширяет локальную экосистему межсетевого взаимодействия и поддерживает более эффективный обмен трафиком со многими итальянскими и международными сетями, которые используют этот узел обмена.

Благодаря этому новому соединению GTHost продолжает расширять свое присутствие в Европе, предоставляя клиентам, которые зависят от низкой задержки и надежного подключения, более эффективную и отказоустойчивую сетевую инфраструктуру. Каждое улучшение производительности способствует более быстрой и отзывчивой работе — ведь в современных сетях миллисекунды имеют значение.

hosting-vds.com

8 Мар 2026
Плановые работы по техническому обслуживанию
Запланированы технические работы по обслуживанию и улучшению работы оборудования для Стандартные VDS KVM на NVMe в России
Мы планируем провести улучшение оборудования и обновить процессоры на Intel Xeon Gold 6240R
Для выполнения данной задачи, потребуется отключение серверов примерно на 20-30 минут каждый.
Все остальные сервера в Европе и Hi-CPU категории в Москве, продолжат свою работу без перерывов в обслуживании.

7 Фев 2026
Обновление стоимости тарифов
Мы обновляем стоимость наших услуг, но для наших постоянных пользователей подготовили «иммунитет» к изменениям на первое время. Вы можете продолжать пользоваться услугами по старой цене!

14 Дек 2025
C 1 января 2026 года мы будем включать 5% НДС в стоимость всех наших услуг.
Обращаем ваше внимание, что с 1 января 2026 года мы будем добавлять 5% НДС к стоимости всех наших услуг.

24 Ноя 2025
DNS хостинг — приглашаем к тестированию.
Мы запустили свой DNS хостинг и приглашаем к тестированию всех желающих. Доступен бесплатный заказ DNS хостинга для владельцев активных услуг VDS. Ожидаем ваши предложения и пожаления касательно DNS хостинга в тикетах на сайте.
DNS хостинг доступен к оформлению по ссылке my.hosting-vds.com/order/dns

26 Окт 2025
Локация в Нидерландах, Амстердам!
Открыли новую локацию в Нидерландах для услуг VDS серверов. Для всех стандартных тарифов в Европе my.hosting-vds.com/order/vds-kvm-ssd-de мы добавили выбор локации при заказе с указанием типа процессора который там используется.

9 Окт 2025
Локация в Болгарии, София!
Открыли новую локацию в Болгарии для услуг VDS серверов. Для всех стандартных тарифов в Европе my.hosting-vds.com/order/vds-kvm-ssd-de мы добавили выбор локации при заказе с указанием типа процессора который там используется.

19 Сен 2025
Локация в Польше, Варшава!
Открыли новую локацию в Польше для услуг VDS серверов. Для всех стандартных тарифов в Европе my.hosting-vds.com/order/vds-kvm-ssd-de мы добавили выбор локации при заказе с указанием типа процессора который там используется.

10 Сен 2025
Локация в Швеции, Стокгольм!
Открыли новую локацию в Швеции для услуг VDS серверов. Для всех стандартных тарифов в Европе my.hosting-vds.com/order/vds-kvm-ssd-de мы добавили выбор локации при заказе с указанием типа процессора который там используется.

21 Авг 2025
Увеличено количество трафика на некоторых тарифных планах.
Увеличили количество трафика на некоторых тарифных планах во всех категориях и локациях

2 Июл 2025
Плановые технические работы в Москве. Информация из дата-центра.
В целях улучшения качества наших услуг с 22:00 07.07.2025 по 02:00 08.07.2025 в стойке DX-1911 будут проводиться плановые работы по прогрессивной цепи электропитания

11 Мар 2025
Локация в Германии, Франкурт!
Открыли новую локацию в Германии для услуг VDS серверов.

12 Фев 2025
Важные изменения в резервном копировании серверов. Новая услуга резервного копирования.
Мы добавили новую услугу – резервное копирование серверов. Теперь вы можете защитить свои данные от потерь и неожиданных сбоев.

+ добавлена поддержка PHP 8.4.
+ интеграция с платежной системой ВТБ (эквайринг), vtb-ekv.ru.
+ интеграция с платежной системой SeverPay.io.
+ интеграция с платежной системой Spayon.io.
+ интеграция с платежной системой WATA.pro.
* админу: доменные зоны: возможность переопределить/указать ID регистратора, ID прайса, ID периода, которые необходимо использовать при регистрации/продлении доменов (только для Ardis).
* админу: обратная связь: устаревший блок ICQ-контактов заменен на Telegram.
* админу: настройки клиента: возможность отключить сохранение PDF-инвойсов персонально для клиента.
* админу: настройки клиента: api: добавлена настройка «Включить доступ к API (ссылка на оплату)».
* админу: шаблоны: для шаблонов о регистрации, продлении и напоминании об окончании оплаченного периода доменов добавлены макросы {startdate} и {todate}.
* админу: регистраторы: возможность для большинства EPP-регистраторов (hostmaster.ua, sunic.ua, coordinator.ua, nic.lviv.ua, v.ua, dns.pl, nic.dp.ua, nic.kz, drs.ua) автоматически подтверждать запросы на трансфер доменов к другим регистраторам + возможность настроить поведение при получении POLL-уведомления о завершении трансфера к другому регистратору (удалять домен или уведомлять админа; по умолчанию — домен будет удаляться) + добавлено уведомление в систему уведомлений при получении запроса на трансфер домена к другому регистратору.
* клиенту: автопродление: если в настройках тарифного плана или доменной зоны запрещено продление ранее указанного кол-ва дней до окончания, то не позволяем клиенту установить день автоматического продления больше указанного.
* клиенту: заказы: возможность управления устройствами (только для IPTVPortal).
* клиенту: мультиязычность: допереведены азербайджанский и польский языковые файлы.
* клиенту: обратная связь: устаревшее поле ICQ в форме заменено на Telegram.
* клиенту: оформление заказа (v2): добавлена поддержка проверки заказана ли доп. услуга из группы доп. услуг с активной настройкой «Заказ обязателен».
* api (тарифы): добавлены команды getBills (получение списка счетов) + createBillBalance (создание счета на пополнение внутреннего баланса) + getBillPaymentLink (получение ссылки на оплату счета через указанную платежную систему без авторизации в кабинете).
* 1ofd: добавлена поддержка НДС 5%, НДС 7%, НДС 5/105 и НДС 7/107.
* 4vps: добавлена возможность указать Panel ID в настройках сервера/локации + добавлен cron-скрипт, позволяющий автоматически управлять активностью тарифных планов (в зависимости от доступности их на стороне 4VPS) + обновляем активность тарифных планов при повторных импортах в админке.
* iptvportal: добавлена поддержка управления устройствами (просмотр, включение, выключение, удаление, изменение комментария).
* iptvportal: добавлена возможность использования логина от биллинга в качестве логина в iptvportal.
* monobank: в связи с изменениями на стороне сервиса, запрашиваем у клиента перед оплатой последние 4 номера карты для автоматического проведения платежа.
* onpay: удалена устаревшая форма выбора доступных к оплате валют.
* paykassa: обновлен список доступных криптовалют.
* stripe: возможность автоматического расчета налога на стороне Stripe на основании страны клиента + возможность расчета налога с использованием фиксированного Tax Rate.
* stripe: обновлена библиотека для корректной работы с PHP 8.x.
— безопасность: исправлена ошибка, когда авторизованный пользователь мог иметь доступ к своим тикетам даже если его аккаунт был заблокирован (только при условии, что разрешен доступ к тикетам для гостей).
— безопасность: исправлена ошибка в callback-обработчиках у всех платежных модулей, когда не выполнялась проверка суммы платежа для объединенных счетов.
— ядро: ряд исправлений в сборке для php 8.x.
— 1ofd: исправлена ошибка, возникающая когда в totalSum в копейках есть только десятые и нет сотых.
— 4vps: исправления в модуле интеграции, в связи с изменениями на стороне сервера.
— hetzner.cloud: исправлена ошибка, возникающая при попытке выделения дополнительных IP и дополнительных дисков.
— paykassa: исправлена ошибка, когда не работало получение курса для криптовалюты.
— virtualizor: обновлен класс интеграции.
— приват24 для бизнеса: исправление в модуле интеграции в связи с изменениями на стороне сервиса.
— рассылки: исправлена ошибка, когда при рассылке планировщиком задач в случае какой-либо ошибки smtp, возникающей у отдельного сообщения, она дублировалась в логах у всех последующих писем, отправляемых этим же скриптом.
— sms: исправлена ошибка, когда при преобразовании сообщения в транслит удалялся символ дефиса.
-d- pay54: удален модуль интеграции как утративший актуальность.

rootpanel.net/buy.php
rootpanel.net/price.php
rootpanel.net

В продолжение нашего предыдущего сообщения об обязательных изменениях в политике соответствия требованиям NIXI для доменов .IN, доменов третьего уровня .IN и .BHARAT, а именно:

• Требования к участникам: Регистрация, перенос данных и редактирование контактной информации возможны только для зарегистрированных лиц из Индии.
• Ограничения на использование электронной почты: Запрет на использование одноразовых или временных почтовых сервисов для контактов зарегистрированных пользователей.
• Ограничения VPN: Запрет на использование VPN или маскированных IP-адресов во время регистрации.

Примечание: Вы уже должны были учесть эти конкретные изменения и внедрить необходимые проверки на витрине вашего магазина.

Мы публикуем технические подробности интеграции обязательных процедур eKYC и проверки
электронной почты зарегистрированных пользователей (вступающих в силу с 31 марта 2026 года).

Если вы используете наши API для работы своего интернет-магазина, вам потребуется внедрить следующие обновления, чтобы обеспечить постоянное соответствие требованиям для ваших клиентов:

1. Улучшения API: Получение сведений о домене
API-интерфейсы для получения сведений о домене (api/domains/details.json и api/domains/details-by-name.json ) были улучшены и теперь возвращают новый объект VerificationInfo. Это позволит вам определить, соответствует ли домен требованиям, ожидает ли проверки или приостановлен, а также включает статусы для проверки электронной почты и проверки eKYC.

2. Новый API: повторная отправка письма с подтверждением.
Мы добавили новую конечную точку API (POST /api/domains/nixi/verification/resend.json ), которая позволяет вручную повторно отправлять электронные письма с подтверждением домена для доменов, у которых ожидается подтверждение электронной почты и/или eKYC.

3. График внедрения и тестирования
Чтобы помочь вам подготовиться, обратите внимание на следующий график внедрения API:

• API демонстрационного сервера: доступны для тестирования с 25 марта 2026 года.
• API для производственной среды: запуск 31 марта 2026 года.

Полную документацию по API вы найдете в прикрепленном к этому письму файле.

Прилагаемый документ содержит исчерпывающую информацию, в том числе:

• Подробные структуры ответов и определения статусов для новых API.
• Учетные данные и URL-адреса для доступа к демонстрационному серверу.

Мы настоятельно рекомендуем ознакомиться со всей прилагаемой документацией, чтобы подготовиться к предстоящим изменениям.
Если у вас возникнут какие-либо вопросы по внедрению, пожалуйста, создайте заявку через службу поддержки.
Благодарим вас за сотрудничество в обеспечении соблюдения рекомендаций NIXI.

С уважением,
команда ResellerClub.

Новые вычислительные ресурсы готовятся для всех стран (для тарифов линейки Стандарт на базе Intel Xeond Gold 6238R).
—
More compute power is being prepared for all of the regions (Standard plans running at Intel Xeon Gold 6238R).



hip.hosting/ru