Каковы преимущества и недостатки монтирования Ваших двоичных файлов приложения от общего монтирования?
В кластере узлов приложений, каковы преимущества/недостатки размещения Ваших двоичных файлов приложения на общем монтировании и наличии каждого из узлов, монтируют что, вместо того, чтобы иметь отдельные копии двоичных файлов на каждом узле?
Есть ли что-нибудь, что делает один подход или другой особенно плохо?
Спасибо
Когда я начинал работать в финансовой индустрии, у меня были системы, которые состояли из систем шлюзов, которые потребляли / обрабатывали данные, вычислительных узлов для принятия торговых решений, серверов NFS для обслуживания приложений / централизованного ведения журналов и много сетей, чтобы связать все вместе. Мы также централизовали планирование crontab и мониторинг приложений и разместили их на монтированиях NFS.
Это было основано на NFSv3, и преимущества были, ммм ...
- Простое распространение приложений: одно монтирование. Одно место для внесения изменений.
- Простое управление данными, относящимися к этим приложениям.
Недостатки:
- Восприимчивость к ошибкам: Одно крепление. Одно место, где можно испортить изменения.
- Масштабируемость: если вы также не кластеризуете свое хранилище, центральное крепление будет иметь верхний предел количества клиентов, которые оно может эффективно обслуживать.
- Единая точка. отказа (SPOF): опять же, кластерное хранилище может смягчить это, но это следует учитывать. Что произойдет, если предположить NFS, если вам потребуется перезагрузить сервер? Будут ли узлы кластера зависать при загрузке, если сервер NFS отсутствует или недоступен?
- Разрешения: как вы будете управлять разрешениями на узлах кластера. Учетные записи местных служб? Соответствующие UID / GID? В моем случае я использовал NIS и более поздние версии LDAP. Здесь была бы полезна служба каталогов.
- Производительность: здесь вы зависите от сети и инфраструктуры коммутации. Производительность таких вещей, как загрузка приложений, ведение журнала и т. Д., На локальном диске будет выше, чем при подключении по сети.
- Настроить NFS сложно, и большинство людей не справляется с этим :)
В наши дни вы может развертывать и управлять вашим программным обеспечением с помощью системы управления конфигурацией ( Puppet , Chef , Ansible , и т. д. .). Или, что еще лучше, используйте собственный метод упаковки операционной системы (RPM, .deb) и разверните его с управлением конфигурацией:
- Это удаляет SPOF.
- Локализация приложения должна иметь преимущество в производительности.
- Упрощает сети: например что, если вы расширите доступ до нескольких местоположений?
- Может обеспечить более детальный контроль: например, распространять двоичный файл на подмножество систем, а не на весь кластер.
- Самодокументируемый.
Учитывая это, я бы, вероятно, рекомендовал отдельные копии приложений вместо использования общего монтирования.