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

Question

Текущая настройка

• у нас есть наш кластер обнаружения из 10 узлов.
• Каждый узел этого кластера имеет 24 ядра и оперативную память 264 ГБ. Оставляя немного памяти и ЦП для фоновых процессов, мы планируем использовать 240 ГБ памяти.
• Теперь, когда дело доходит до настройки контейнера, так как каждому контейнеру может потребоваться 1 ядро, так что максимум у нас может быть 24 контейнера, каждый с 10 ГБ памяти.
• Обычно в кластерах есть контейнеры с 1-2 ГБ памяти, но мы ограничены доступными ядрами, которые есть у нас, или, может быть, я что-то упускаю

Постановка задачи

• , поскольку наш кластер широко используется исследователями и аналитиками данных, для этого недостаточно всего лишь 24 контейнеров. Это приводит к сильной конкуренции за ресурсы.

• Есть ли способ увеличить количество контейнеров?

Варианты, которые мы рассматриваем

• Если мы попросим команду выполнить много тез-запросов (не отдельно), а в файле, то при максимуме мы будем хранить один контейнер.

Запросы

1. Есть ли другой способ управления нашим кластером обнаружения.
2. Есть ли возможность уменьшить размер контейнера.
3. Можно ли совместно использовать vcore (поскольку это логическая концепция) для нескольких контейнеров?

Answer 1

Vcores - это просто логическая единица, никак не связанная с ядром ЦП, если вы не используете YARN с CGroups и не активированы yarn.nodemanager.resource.percentage-physical-cpu-limit. Большинство задач редко связаны с процессором, но чаще связаны с сетевым вводом / выводом. Поэтому, если вы посмотрите на общее использование ЦП и использование памяти в вашем кластере, вы сможете изменить размеры своих контейнеров в зависимости от потерянной (резервной) емкости.

Вы можете измерить уровень загрузки с помощью множества инструментов, но sar, ganglia и grafana являются очевидными, но вы также можете обратиться к инструментам производительности Linux Брендана Грегга для получения дополнительных идей.