Назад | Перейти на главную страницу

Правильный способ распространения двоичных файлов в кластер Linux

Недавно у меня возникли разногласия с моим начальником по поводу правильного способа распределения исполняемых двоичных файлов по вычислительным узлам в кластере Linux. На всех вычислительных узлах запущен дистрибутив одной и той же версии (в частности, Ubuntu 14.04).

Текущий метод монтирует общий ресурс nfs на всех вычислительных узлах с главного узла и устанавливает все исполняемые файлы (и зависимости) в указанный каталог. Обычно существует 10-20 различных исполняемых файлов, и они обновляются раз в полгода или около того.

Я считаю, что мы должны развертывать пакеты deb на вычислительных узлах, но, поскольку я новичок в кластерах, я чувствую, что просто изливаю риторику.

Поэтому я прошу совета и отзывов о «правильном» способе развертывания и обновления двоичных файлов на вычислительных узлах.

Спасибо!

Не существует единственного «правильного» способа сделать это. Если общий ресурс NFS работает на вас, и вас не пугает SPOF, который он, вероятно, вводит, продолжайте использовать его.

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

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

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

Совершенно верно развертывать двоичные файлы вручную с помощью NFS. В зависимости от объема вашей работы создание собственных пакетов и запуск собственного репозитория debian может быть даже немного излишним. При этом использование диспетчера пакетов упростит управление зависимостями и откаты.

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