Если вы предоставляете услугу на двух серверах для обеспечения высокой доступности, лучше ли сконфигурировать их точно так же, чем вместо этого вы должны вводить небольшие различия, чтобы предотвратить ошибки «странной конфигурации»?
Мы размещаем веб-сайт на основе Django в стеке Linux (Ubuntu LTS), Nginx, Apache и Python WSGI, дублированных на трех серверах за балансировщиком нагрузки. В настоящее время они размещены в облаке Amazon, но в будущем мы можем переехать в наш собственный центр обработки данных. Недавно у нас была проблема на всех трех серверах, которая была решена только обновлением ядра, что заставляет нас думать, что это несовместимость между эта конкретная версия ядра и физического оборудования которую Amazon могла начать использовать в тот момент.
Это заставило меня задуматься: было бы лучше оставить все машины в одной и той же конфигурации (более легкое управление?), Или вместо этого мы должны оставить вещи небольшими различиями, чтобы несовместимость между двумя компонентами проявлялась только на одной машине, а не на всех из них, держа ваш сайт в воздухе?
Оставьте их такими же. Вероятность того, что у вас будет некоторая несовместимость, которая проявляется только в определенной конфигурации, минимальна, и после этого вам придется помнить о различиях для всего, что вы делаете.
Определенно да. Это поможет с устранением возникающих проблем.
Посмотрите на Puppet, чтобы управлять изменениями файла конфигурации. Мы будем хранить файлы конфигурации в svn, а затем отправлять наши изменения. У нас был централизованный сервер управления, который проверял наши изменения, а Puppet отправлял их. Это дает историю изменений, поэтому, когда вы делаете ошибку, вы можете легко откатить ее, а когда у вас несколько администраторов, изменения конфигурации можно отслеживать.
Ссылка: http://puppetlabs.com/
Для простоты все они должны иметь одну и ту же конфигурацию, однако бывают случаи (в основном продиктованные используемым программным обеспечением), когда просто невозможно сбалансировать нагрузку, и переключение при отказе становится единственным вариантом - и в таких случаях могут потребоваться немного разные конфигурации. .
OTOH, для службы с выходом в Интернет, доступность и безопасность должны быть в списке приоритетов. Хорошая безопасность означает регулярное применение исправлений, хорошая доступность означает, что вы не можете исправлять все блоки одновременно - действительно, практика, которую я использовал для аналогичной настройки, заключалась в применении исправлений к одной действующей машине, как только они были доступны и были применены и кратко оценили на тестовой машине, но отложили развертывание на другие узлы на пару дней, пока я не узнаю, что исправления не имеют никакого отрицательного эффекта.
Хотя Sirex прав - в идеальном мире - вы бы внедрили исправления в опытный кластер и протестировали бы с использованием трафика / данных из производственной системы - на практике это далеко не рентабельно в таком небольшом масштабе.