Введение
ProxLB (PLB) — это продвинутый инструмент, предназначенный для повышения эффективности и производительности кластеров Proxmox за счет оптимизации распределения виртуальных машин (ВМ) или контейнеров (КТ) по узлам кластера, используя Proxmox API. ProxLB тщательно собирает и анализирует комплексную совокупность метрик ресурсов как от узлов кластера, так и от работающих ВМ. Эти метрики включают в себя загрузку ЦП, потребление памяти и использование диска, в частности, с акцентом на локальные дисковые ресурсы. В принципе, это что-то вроде DRS для VMware. PLB собирает данные об использовании ресурсов от каждого узла в кластере Proxmox, включая использование ЦП, (локального) диска и памяти. Кроме того, он собирает статистику использования ресурсов от всех работающих ВМ/КТ, обеспечивая детальное понимание распределения рабочей нагрузки в кластере.
Интеллектуальная балансировка — ключевая особенность ProxLB, позволяющая перераспределять ВМ на основе их использования памяти, диска или ЦП, обеспечивая отсутствие перегруженных узлов при одновременном поддержании неиспользованных ресурсов. Возможности балансировки PLB значительно повышают производительность и надежность кластера. Обеспечивая равномерное распределение ресурсов, PLB помогает предотвратить ситуацию, когда отдельный узел становится узким местом производительности, улучшая надежность и стабильность кластера. Эффективная балансировка приводит к лучшему использованию доступных ресурсов, потенциально снижая необходимость в дополнительных аппаратных инвестициях и снижая операционные затраты.
Автоматизированная балансировка снижает потребность в ручных действиях, позволяя операторам сосредоточиться на других критических задачах, тем самым повышая операционную эффективность.
Как это работает?
ProxLB — это система балансировки нагрузки, предназначенная для оптимизации распределения виртуальных машин (ВМ) и контейнеров (КТ) по кластеру. Он работает путем первоначального сбора метрик использования ресурсов со всех узлов кластера через Proxmox API. Это включает в себя подробные метрики ресурсов для каждой ВМ и КТ на каждом узле. ProxLB затем оценивает разницу между максимальным и минимальным использованием ресурсов узлов, называемую "Балансирностью". Если эта разница превышает заранее определенный порог (который настраивается), система инициирует процесс балансировки.
Прежде чем начать какие-либо миграции, ProxLB проверяет, необходимы ли и полезны ли действия по балансировке. В зависимости от выбранного режима балансировки — например, ЦП, память или диск — он создает матрицу балансировки. Эта матрица сортирует ВМ на основе их максимального использованного или назначенного ресурса, определяя ВМ с самым высоким использованием. ProxLB затем помещает эту ВМ на узел с наибольшим количеством свободных ресурсов выбранного типа балансировки. Этот процесс выполняется рекурсивно до достижения Балансирности, определенной оператором. Балансировка может быть определена для используемых или максимальных назначенных ресурсов ВМ/КТ.
Возможности
* Бесплатный и открытый исходный код (GPLv3)
* Балансировка кластера по:
* Памяти
* Диску (только локальное хранилище)
* ЦП
* Выполнение периодически или однократно.
* Типы:
* Балансировка только ВМ
* Балансировка только КТ
* Балансировка всех (ВМ и КТ)
* Фильтры:
* Исключение узлов
* Исключение виртуальных машин
* Группировка (аффинитет/анти-аффинитет)
* Включение групп (ВМ, которые будут балансироваться к узлам вместе)
* Исключение групп (ВМ, которые должны работать на разных узлах)
* Игнорирование групп (ВМ, которые должны оставаться нетронутыми)
* Поддержка Dry-run
* Человекочитаемое представление в CLI
* JSON-вывод для дальнейшей обработки
* Миграция рабочих нагрузок ВМ подальше (например, для подготовки к обслуживанию)
* Полностью основан на Proxmox API
Использование
* Однократно (one-shot)
* Периодически (daemon)
* Интеграция с Proxmox Web GUI (опционально)
Ожидаемые функции
* Автоматическое исправление узлов кластера (грязное исправление: [ >))
* DPM
* Собственный API-интерфейс для интеграций CI/CD
* Предоставление результатов dry-run тестов
* Предоставление лучшего нового узла для новых КТ/ВМ
Где взять?
Как указано на GitHub, вы можете просто использовать код оттуда, но есть и другие варианты:
* Распространительный пакет(ы): .deb, .rpm, .pkg (FreeBSD)
* Репозиторий Debian
* Контейнерный образ Docker
* Podman
Это должно соответствовать большинству нужд и также показывает, что, используя только API, это может просто работать на большинстве систем, которые могут получить доступ к Proxmox API.
Примечания
Лично, мне очень нравится включение автоматического исправления узлов. Это означает, что узлы периодически проверяют наличие новых доступных пакетов и проверяют, нужны ли им перезагрузки. Если перезагрузка не требуется, их можно просто установить. Если перезагрузка необходима, рабочие нагрузки КТ/ВМ необходимо перенести на другие узлы кластера.
Убедитесь, что все рабочие нагрузки перенесены (что может занять некоторое время, особенно на локальном хранилище), а затем выполните обновление. Поскольку я лично предпочитаю использовать только API, а не все включено там, мне нужно исправить API (что и является действительно грязным способом и, следовательно, потребует дополнительного пакета proxlb-additions, который включает это. Таким образом, это все еще проект, и также сказано, что это одна из ожидаемых функций и ищут лучшее решение, но только путем вызова API. Текущее решение для получения этого в API выглядит следующим образом).
Еще одна важная и часто запрашиваемая функция — DPM из VMware, где узлы могут определять, необходимы ли они в кластере или могут быть выключены для экономии электроэнергии. В этом случае нам нужно проверить, достаточно ли ресурсов для размещения рабочей нагрузки в кластере (будет несколько дополнительных параметров для разрешения перераспределения или для обеспечения наличия достаточного количества свободных ресурсов для обеспечения возможности сбоя одного или нескольких узлов) и миграции вещей. Можно использовать хук для повточного включения узлов по запросам WoL.
Еще одна большая вещь — собственный API, который уже немного интегрирован в собственную адаптацию, но подход "не изобретать велосипед" не был таким хорошим, и мне стоит придерживаться стабильных фреймворков. Этот API-интерфейс позволяет собирать метрики, результаты dry-run тестов, но также и другие вещи, такие как получение лучшего нового узла для размещения рабочих нагрузок КТ или ВМ.
Буду рад услышать ваши мнения об этом проекте — сообщите мне, чего вам не хватает или подходит ли это для ваших нужд. Возможно, вы уже нашли Reddit-треда об этом, где мне посоветовали также упомянуть это здесь, потому что это выглядит полезным для большинства.
Ресурсы
* Источник: [ >)
* Блог-пост: [ >)
ProxLB (PLB) — это продвинутый инструмент, предназначенный для повышения эффективности и производительности кластеров Proxmox за счет оптимизации распределения виртуальных машин (ВМ) или контейнеров (КТ) по узлам кластера, используя Proxmox API. ProxLB тщательно собирает и анализирует комплексную совокупность метрик ресурсов как от узлов кластера, так и от работающих ВМ. Эти метрики включают в себя загрузку ЦП, потребление памяти и использование диска, в частности, с акцентом на локальные дисковые ресурсы. В принципе, это что-то вроде DRS для VMware. PLB собирает данные об использовании ресурсов от каждого узла в кластере Proxmox, включая использование ЦП, (локального) диска и памяти. Кроме того, он собирает статистику использования ресурсов от всех работающих ВМ/КТ, обеспечивая детальное понимание распределения рабочей нагрузки в кластере.
Интеллектуальная балансировка — ключевая особенность ProxLB, позволяющая перераспределять ВМ на основе их использования памяти, диска или ЦП, обеспечивая отсутствие перегруженных узлов при одновременном поддержании неиспользованных ресурсов. Возможности балансировки PLB значительно повышают производительность и надежность кластера. Обеспечивая равномерное распределение ресурсов, PLB помогает предотвратить ситуацию, когда отдельный узел становится узким местом производительности, улучшая надежность и стабильность кластера. Эффективная балансировка приводит к лучшему использованию доступных ресурсов, потенциально снижая необходимость в дополнительных аппаратных инвестициях и снижая операционные затраты.
Автоматизированная балансировка снижает потребность в ручных действиях, позволяя операторам сосредоточиться на других критических задачах, тем самым повышая операционную эффективность.
Как это работает?
ProxLB — это система балансировки нагрузки, предназначенная для оптимизации распределения виртуальных машин (ВМ) и контейнеров (КТ) по кластеру. Он работает путем первоначального сбора метрик использования ресурсов со всех узлов кластера через Proxmox API. Это включает в себя подробные метрики ресурсов для каждой ВМ и КТ на каждом узле. ProxLB затем оценивает разницу между максимальным и минимальным использованием ресурсов узлов, называемую "Балансирностью". Если эта разница превышает заранее определенный порог (который настраивается), система инициирует процесс балансировки.
Прежде чем начать какие-либо миграции, ProxLB проверяет, необходимы ли и полезны ли действия по балансировке. В зависимости от выбранного режима балансировки — например, ЦП, память или диск — он создает матрицу балансировки. Эта матрица сортирует ВМ на основе их максимального использованного или назначенного ресурса, определяя ВМ с самым высоким использованием. ProxLB затем помещает эту ВМ на узел с наибольшим количеством свободных ресурсов выбранного типа балансировки. Этот процесс выполняется рекурсивно до достижения Балансирности, определенной оператором. Балансировка может быть определена для используемых или максимальных назначенных ресурсов ВМ/КТ.
Возможности
* Бесплатный и открытый исходный код (GPLv3)
* Балансировка кластера по:
* Памяти
* Диску (только локальное хранилище)
* ЦП
* Выполнение периодически или однократно.
* Типы:
* Балансировка только ВМ
* Балансировка только КТ
* Балансировка всех (ВМ и КТ)
* Фильтры:
* Исключение узлов
* Исключение виртуальных машин
* Группировка (аффинитет/анти-аффинитет)
* Включение групп (ВМ, которые будут балансироваться к узлам вместе)
* Исключение групп (ВМ, которые должны работать на разных узлах)
* Игнорирование групп (ВМ, которые должны оставаться нетронутыми)
* Поддержка Dry-run
* Человекочитаемое представление в CLI
* JSON-вывод для дальнейшей обработки
* Миграция рабочих нагрузок ВМ подальше (например, для подготовки к обслуживанию)
* Полностью основан на Proxmox API
Использование
* Однократно (one-shot)
* Периодически (daemon)
* Интеграция с Proxmox Web GUI (опционально)
Ожидаемые функции
* Автоматическое исправление узлов кластера (грязное исправление: [ >))
* DPM
* Собственный API-интерфейс для интеграций CI/CD
* Предоставление результатов dry-run тестов
* Предоставление лучшего нового узла для новых КТ/ВМ
Где взять?
Как указано на GitHub, вы можете просто использовать код оттуда, но есть и другие варианты:
* Распространительный пакет(ы): .deb, .rpm, .pkg (FreeBSD)
* Репозиторий Debian
* Контейнерный образ Docker
* Podman
Это должно соответствовать большинству нужд и также показывает, что, используя только API, это может просто работать на большинстве систем, которые могут получить доступ к Proxmox API.
Примечания
Лично, мне очень нравится включение автоматического исправления узлов. Это означает, что узлы периодически проверяют наличие новых доступных пакетов и проверяют, нужны ли им перезагрузки. Если перезагрузка не требуется, их можно просто установить. Если перезагрузка необходима, рабочие нагрузки КТ/ВМ необходимо перенести на другие узлы кластера.
Убедитесь, что все рабочие нагрузки перенесены (что может занять некоторое время, особенно на локальном хранилище), а затем выполните обновление. Поскольку я лично предпочитаю использовать только API, а не все включено там, мне нужно исправить API (что и является действительно грязным способом и, следовательно, потребует дополнительного пакета proxlb-additions, который включает это. Таким образом, это все еще проект, и также сказано, что это одна из ожидаемых функций и ищут лучшее решение, но только путем вызова API. Текущее решение для получения этого в API выглядит следующим образом).
Еще одна важная и часто запрашиваемая функция — DPM из VMware, где узлы могут определять, необходимы ли они в кластере или могут быть выключены для экономии электроэнергии. В этом случае нам нужно проверить, достаточно ли ресурсов для размещения рабочей нагрузки в кластере (будет несколько дополнительных параметров для разрешения перераспределения или для обеспечения наличия достаточного количества свободных ресурсов для обеспечения возможности сбоя одного или нескольких узлов) и миграции вещей. Можно использовать хук для повточного включения узлов по запросам WoL.
Еще одна большая вещь — собственный API, который уже немного интегрирован в собственную адаптацию, но подход "не изобретать велосипед" не был таким хорошим, и мне стоит придерживаться стабильных фреймворков. Этот API-интерфейс позволяет собирать метрики, результаты dry-run тестов, но также и другие вещи, такие как получение лучшего нового узла для размещения рабочих нагрузок КТ или ВМ.
Буду рад услышать ваши мнения об этом проекте — сообщите мне, чего вам не хватает или подходит ли это для ваших нужд. Возможно, вы уже нашли Reddit-треда об этом, где мне посоветовали также упомянуть это здесь, потому что это выглядит полезным для большинства.
Ресурсы
* Источник: [ >)
* Блог-пост: [ >)
