インターネット経由で負荷分散された Linux サーバーですか?

Question 1

This is a large topic that gets complicated fast. The CAP theorem is a good starting point, as it identifies the higher level choices that must be made.

When you are dealing with a write heavy Web application, it makes it more difficult to distribute load across the Internet while maintaining data integrity. Read centric applications (search!) are easier to distribute, as you do not have to concern yourself with the logistics of writing the data.

ipvsLinux を本質的にレイヤー 4 スイッチにすることができます。レイヤー 2 (ARP/イーサネット - リンク層) で使用して最も成功したので、これが私の第一選択ですが、次のようなものを使用することもできます。LVS-タンブロードキャスト層で接続されていない、地理的に離れたサーバー用です。ipvsadm は ipvs のユーザーランドツールであり、ldirectord は ipvs リソースを管理するデーモンであることに注意してください。

ハートビートは事実上ペースメーカー他のサーバーを監視するには、複数のリンクが必要です。サーバー間にシリアルまたは冗長物理接続がない場合のリスクは大幅に大きくなります。ハートビートが 2 つのサイト間で監視する複数の物理的に異なるインターネット接続であっても、ダウンする可能性があります。自動フェイルオーバーではスプリットブレインによってデータが破損するリスクがあるため、ここでデータのリスクが発生します。このリスクを軽減する理想的な方法はありません。

フェイルオーバープロセスにさらにロジックを挿入することもできます。例:

path1 がダウンし、path2 もダウンし、このプロセスは実行されておらず、これを行うことができない場合は、フェイルオーバーします。

これによりリスクは軽減されますが、それでも必ずしも短距離でサーバーを物理的に接続できるほどには至りません。

静的コンテンツでは、コンテンツ配信ネットワーク。

シンプルな負荷分散とフェイルオーバーは、ラウンドロビン DNS、これはより誤りやすいです。

ボーダーゲートウェイプロトコルネットワーク層で高可用性を実現できるネットワークプロトコルです。

最終的には、十分な資金 (時間/リソース) があれば、適切な SLA を開発して高い可用性を実現できます。最終的な制約は予算です。要件を定義し、予算内で何を達成できるかを検討してください。妥協が必要になります。

少なくとも書き込み負荷の高いアプリケーションの場合、同じ物理的な施設内で高可用性と自動フェイルオーバーを有効にする方が合理的であることがよくあります。災害復旧計画と SLA の一部として、物理的に別のサイトへの手動フェイルオーバープロセスを用意することで、データの整合性を維持しながら質の高いサービスレベルを維持できます。

Answer