冗長サーバーの構成はまったく同じですか、それともわずかに異なりますか？
高可用性を確保するために2つのサーバーでサービスを提供する場合、「異常な構成」エラーを防ぐためにわずかな違いを導入するのではなく、まったく同じ方法で構成する方がよいでしょうか。
Linux（Ubuntu LTS）、Nginx、Apache、Python WSGI、ロードバランサーの背後にある3つのサーバーで複製された）のスタックでDjangoベースのWebサイトをホストしています。現在、これらはAmazonクラウドでホストされています。 、しかし将来的には独自のデータセンターに移動する可能性があります。最近、3つのサーバーすべてで問題が発生しましたが、カーネルをアップグレードすることによってのみ解決されたため、 この特定のバージョンのカーネル）間の非互換性であると考えられます。および物理ハードウェア その時点でAmazonが使用を開始した可能性があります。
これは私に考えさせました：すべてのマシンを完全に同じ構成に保つ方が良いでしょうか（管理が簡単ですか？）、または代わりに少し違いを持たせて、2つのコンポーネント間の非互換性がすべてではなく1台のマシンでのみ現れるようにする必要がありますそれらのうち、あなたのウェブサイトを空中に保ちますか？
それらを同じに保ちます。特定の構成でのみ現れる非互換性が発生する可能性は最小限であり、その後は、行うすべての違いを覚えておく必要があります。
簡単にするために、それらはすべて同じ構成である必要がありますが、負荷分散が不可能であり、フェイルオーバーが唯一のオプションになる場合があります（ほとんどの場合、使用中のソフトウェアによって決定されます）-そのような場合は、わずかに異なる構成が必要になることがあります。
OTOH、インターネット向けサービスの場合、可用性とセキュリティは優先順位のリストの上位にある必要があります。優れたセキュリティとは、パッチを定期的に適用することを意味します。可用性が高いと、すべてのボックスに同時にパッチを適用することはできません。実際、同様の設定で採用した方法は、パッチが利用可能になり、適用されたらすぐに1台のライブマシンにパッチを適用することでした。テストマシンで簡単に評価しましたが、パッチが悪影響を及ぼさないことがわかるまで、他のノードへのロールアウトを数日間遅らせました。
Sirexは正しいですが（完璧な世界では）、本番前のクラスターにパッチを実装し、本番システムからのトラフィック/データを使用してテストします。実際には、これはこのような小規模では費用効果が高いとは言えません。
はい、間違いなく。これは、発生する問題のトラブルシューティングに役立ちます。
Puppetを見て、構成ファイルの変更を管理します。設定ファイルをsvnに保存してから、変更をプッシュします。変更をチェックし、Puppetがそれらをプッシュする集中管理サーバーがありました。これにより変更の履歴が得られるため、間違えた場合は非常にシームレスにロールバックでき、複数の管理者がいる場合は構成の変更を追跡できます。