HAシステムのオプションは何ですか？
クライアントのWebサイト用にHALinuxマシンを作成することを検討しています。私が持っている主なオプション、または私がもっと知ることができる場所/記事は何ですか？
既存のソフトウェアが正常に機能するように、それが単一のイメージである場合も私は大好きです。
助けていただければ幸いです。
ありがとう！
多くのオプションがあります。どちらを使用できるかは、Webサイトのコーディング方法によって異なります。
密結合、単一状態
このWebサイトは、...理由により、1つのインスタンスしか実行できません。 2つを並行して実行することは、何らかの理由で非常に悪い考えです。この種のサイトになることはかなり珍しいことです。
CAP定理 ：システム全体の一貫性が最も重要であり、パーティショントレラントではありません。これにより、可用性がエンジニアリングの主要な目標になります。
密結合、セッションごとの単一状態
このWebサイトは、ユーザーが常に同じWebサイトを操作している場合にのみ正しく実行されます。それらが間違ったサーバーにヒットした場合、事態はうまくいかない可能性があります。
CAP定理：ユーザーセッションには厳密な一貫性が必要ですが、システムには必要ありません。障害時にセッションが失われたため、ある程度のパーティション耐性は依然としてサービスの低下ですが、システム全体は存続します。
疎結合、状態は重要ではありません
最もスケーラブルなオプションであるこのタイプのサイトは、状態が保持されている場合でも、データベース層でセッション状態を保持します。 Webサーバーがデータベースに状態をヒットするだけなので、間違ったサーバーにヒットしても問題ありません。
CAP定理：ユーザーセッションは一貫性が緩いことに満足しており、パーティションの許容範囲は非常に高いため、可用性が最も重要です。
シングルステートははるかにHAを作成するのが最も難しいため、サイトはほとんどコーディングされません。それ。これには、1つだけのデータベースまたはファイルセットと1つだけのWebサーバーが必要であり、HAサーバーメンバー間でレプリケーションまたはボリュームパスが行われるため、最初のサーバーが停止したときに別のサーバーがそれを取得できます。エンジニアリングは十分にトリッキーであり、通常、問題がはるかに簡単なセッションごとの単一状態アプリケーションにサイトを再コード化する方が簡単です。
しかし、選択の余地がない場合、唯一の主なオプションは heartbeat のようなクラスタリングです。サーバーのグループをまとめ、ファイルとデータベースのレプリケーションを構成し、フェイルオーバールールを設定します。簡単ではありません。
パフォーマンスと利用可能なシステムの両方を作成することは非常に難しいため、シングルシステムイメージはWebサイトでは実行できません。 SSIシステムには、単一のIPCスペースと厳密なシステムレベルの一貫性を確保するための多くのエンジニアリングがあります。これにより、Webサービスが非常に遅くなる傾向があります。これは、次のようなシステムに最適です。物理ノード間のそのレベルの統合が必要であり、Webサービスはそのようなシステムではありません。そのパーティションの許容範囲は本当に非常に悪いため、SSIは悪いHAソリューションになります。HAへの近道ではありません。クラスターでより適切に提供されます。
セッションごとの単一状態は通常、複数のWebサーバーを作成し、それらの前に haproxy などのロードバランサーを配置することで処理されます。 AWS Elastic Load Balancer（ elb ）、またはF5BigIPのようなハードウェアシステム。それらは sticky-sessions で構成され、各ユーザーセッションは単一のサーバーに供給されます。 1人が死ぬと、他の人が引き継ぎます。ダウンボックスにセッションがあるユーザーは再起動され、それが人生です。このようなセッションの中断によって問題が発生しないように、サイトをコーディングしてください。
State Does n't Matterは、セッションごとの単一状態と同じ方法で処理されますが、主な違いは、スティッキーセッションがないことです。ロードバランサーは、各リクエストをプール内の任意のサーバーにフィードするように構成され、ウェブサーバーは、リクエストごとにデータベースから状態をフィードします。 1台のサーバーが停止しても、誰も気づきません。