メモリ、ディスク使用量、およびその他の属性に関する負荷分散の方法
NGINXなどのロードバランサーを見つけましたが、CPU使用率とネットワークトラフィックを考慮することによってのみ機能するようです。各ノードで利用可能なディスクの量や利用可能なメモリの量など、他の変数に関してどのように負荷分散を行いますか？
リクエストを送信するノードを決定するときにこれらの変数を利用するために、独自のリクエスト処理サービスを作成する必要がありますか？
これは私のユースケースです。消去コード用の分散ファイルシステムを構築しており、ロードバランサーが、トラフィックを処理できるノードにファイルの書き込みを送信し、CPU負荷が、IO操作と予想される操作に十分なメモリがあることを理解しているように、ロードバランサーを使用してもトラフィックとCPUの部分しか処理できませんが、ロードバランサーの要件をさらに強化するにはどうすればよいですか。
私の最初の質問を手伝ってくれてありがとう。
Rob-dは、ロードバランサーが正常に動作し、リクエストに対応できるようにするには、バックエンドサーバーでヘルスチェックを実行する必要があると述べています。これは絶対に本当であり、私はそれがあなたがあなたが望むことをすることを可能にするものだと思います（他のメトリックをチェックし、LBにそれらに基づいてルーティングの選択をさせます）。
HTTPの負荷を分散していると仮定すると、ほとんどのロードバランサーは特定のページに対してHTTP GETまたはHEADを実行して、実行可能なバックエンドとしてのステータスを確認します。このページは、静止画像、CSSファイル、またはHTMLページの場合もあります。
ただし、PHP/ASP/Java/Pythonページの場合もあります。アプリケーションのスタック（SQL、NoSQL、ヘルパーサービスなど）で何らかの健全性チェックを実行できるページである必要があると主張する人もいます。
複雑な負荷分散アルゴリズムを実装し、サーバーがリクエストを処理できるかどうかに応じてHTTP/1.1 200 OKまたはHTTP/1.1 503 Service Unavailableを返すだけのスクリプトを作成できなかった理由はありません。
セカンダリagent-checkを実行できるロードバランサーが少なくとも1つあることを知っています。これにより、単純にUP/DOWNよりも詳細を返すことができ、サーバーのエージェントに基づいて構成された間隔でサーバーの重みを動的に変更できます。決定します。これはまさにあなたが探しているものだと思います。
あなたが質問している質問は、負荷分散に関して非常に重要な質問です。負荷分散を行う主な理由は2つあります。1つ目は、クライアント要求を2つ以上のサーバーに分割することです。2つ目は、サービスを高可用性にすることです。これら2つの結果を考慮してロードバランサーを構成したら、whatifの領域に入りますか？ -ラウンドロビンのようなロードバランシングアルゴリズムを使用して、2つのWebサーバーをロードバランスし、Apacheがホスト1でクラッシュするとします。ロードバランサーはクライアントリクエストをクラッシュしたサーバーに送信するため、「ヘルスチェック」でクライアントを監視する必要があります。 '-これの主な理由は、ヘルスチェックが失敗したときに回避アクションを実行することです-Apacheの例でロードバランサーが実行する必要があるヘルスチェックを想像できます-Apacheは起動していますか？あなたはゲートウェイにpingできますか？ディスクはいっぱいですか？ DBサーバーに到達できますか？などなど.
キャッシング、スティッキーセッション、SSLオフロード、クライアントIP、地理的位置、またはブラウザーに基づくネットワークルーティングなど、ロードバランシングには他にも多くの利点があります。httpの書き換えとリダイレクトを使用し、ヘッダーを変更し、基本的に他に言及すること（サーバー温度など）。
あなたが言及するメトリックに関して、これらはヘルスチェックではなく「パフォーマンスチェック」または「しきい値の状態」です-ロードバランサーはもちろんサーバーをポーリングして好きなメトリックを求め、定義したパラメーターに基づいてリクエストをルーティングしますが、ロードバランサーは主にネットワークデバイスであり、ramとcpuをポーリングせず、他の何かを行い（外部）、指定されたしきい値を超えたことをロードバランサーに通知します（例RAM> 90％使用される）ロードバランサーは、セマフォを発生させ、「新しい要求をserver1にルーティングしないでください」、そして（外部サービス）は、RAM <90％-まですべてのサーバーがレポートする場合はどうなるかRAM> 90％-クラウドロードバランシングでは、これらのメトリックを使用してロードバランサーの背後にあるサーバープールを動的にスケールアップおよびスケールダウンするのに、どれほど速く複雑になるかを確認できます。
概要についてはこちらをご覧ください https://support.f5.com/kb/en-us/products/em/manuals/product/em-health-monitoring-3-0-0/11.html
-私はあなたの質問に賛成票を投じました。質問に反対票を投じる場合、人々はコメントする必要があります。
通常、ロードバランサーのロードバランシングコンポーネントは、アクティブなネットワーク接続の数とバックエンドサーバーに送信したリクエストのどちらか一方のみを認識しており、バックエンドシステムで発生する実際の負荷を認識していません。
選択した負荷分散アルゴリズムにより、ロードバランサーが受信する次の新しい接続/要求を処理するバックエンドサーバーが決まります。
最も単純なのはラウンドロビンで、後続の新しい接続/要求は、次に利用可能なバックエンドサーバーに送られます。
ラウンドロビンに加えて、ほとんどのロードバランサーは、特定の事前定義されたバックエンドサーバーに送信するリクエストまたは接続に比例して送信できる特定の加重ロードバランシングアルゴリズムもサポートします。 （つまり重み1のバックエンドサーバーAと重み2のBを使用すると、サーバーAはすべての要求の1/3を処理し、サーバーBは新しい要求の2/3を処理します）
監視コンポーネントを追加することにより、特定のロードバランサーはその重みを動的に調整できます。つまり、1つのバックエンドサーバーが他のバックエンドサーバーに比べて速度が低下し始めると、動的に取得する新しい接続または要求が少なくなります。
バックエンドサーバーの利用可能なディスク領域に基づいてロードバランサーを調整することは、明らかに非標準のパフォーマンスメトリックスだと思います。 :)
"予想される操作の要件"に基づくロードバランシングに関して、設計しているプロトコルを深く理解する必要があり、ロードバランサーでそのようなロジックを本当に複製しますか？