負荷分散についてのそれらのことについて話します

インタビュー指向のブログは、Q / Aスタイルで提示されます。

---

質問1：負荷分散についてはどうですか？

回答1：

意味：

ロードバランシングとは、ネットワークデバイスとサーバーの帯域幅を拡大し、スループットを高め、ネットワークデータ処理機能を強化し、既存のネットワーク構造に加えてネットワークの柔軟性と可用性を高める、安価で効果的な透過的な方法を提供するメカニズムを指します。

次の図に示すように、4層の負荷分散と7層の負荷分散の2種類の負荷分散があります。

レイヤー4ロードバランシング（宛先アドレスとポート交換）

主にメッセージの宛先アドレスとポート、およびロードバランシングデバイスによって設定されたサーバー選択方法によって、内部サーバーの最終的な選択が決定されます。

一般的なTCPを例にとると、負荷分散デバイスは、クライアントから最初のSYN要求を受信すると、上記の方法で最適なサーバーを選択し、メッセージ内のターゲットIPアドレスを変更します（バックエンドサーバーに変更） IP）、サーバーに直接転送されます。TCP接続の確立、つまり3ウェイハンドシェイクはクライアントとサーバーによって直接確立され、負荷分散デバイスはルーターのような転送アクションとしてのみ機能します。配備状況によっては、サーバーから返されたパケットがロードバランシングデバイスに正しく返されるようにするために、パケットの転送中にパケットの元の送信元アドレスが変更される場合があります。

4層のロードバランシングを実現するソフトウェアは次のとおりです。

F5：ハードウェアロードバランサー。機能は良好ですがコストが高くなります。
lvs：ヘビーデューティ4層ロードソフトウェア。
nginx：キャッシュ機能を備えた軽量の4層ロードソフトウェア。正規表現はより柔軟です。
haproxy：レイヤー4転送をシミュレートし、より柔軟です。

7層の負荷分散（コンテンツ交換）

「コンテンツ交換」とも呼ばれる、いわゆる7層の負荷分散は、メッセージ内の本当に意味のあるアプリケーション層のコンテンツと、負荷分散デバイスによって設定されたサーバー選択方法によって最終的に選択される内部サーバーを決定します。

7層アプリケーションロードの利点は、ネットワーク全体をよりインテリジェントにすることです。たとえば、ウェブサイトにアクセスするユーザートラフィックは、画像クラスのリクエストを特定の画像サーバーに転送し、7つのレイヤーを通じてキャッシュテクノロジーを使用できます。テキストクラスのリクエストを特定のテキストサーバーに転送し、圧縮を使用できます。テクノロジー。

7層の負荷分散を実現するソフトウェアは次のとおりです。

haproxy：固有のロードバランシングスキル、7層プロキシの完全サポート、セッションメンテナンス、マーキング、パス転送;
nginx：httpおよびメールプロトコルでのみ機能し、パフォーマンスはhaproxyに似ています;
apache
：機能が低いMysql プロキシ：機能はまだですええ

---

質問2：負荷分散アルゴリズム/戦略を簡単に紹介しますか？

回答2：

1.ラウンドロビン

ネットワークからの各要求は、1からNの順番で内部サーバーに配信され、再起動されます。この種類の分散アルゴリズムは、サーバーグループ内のすべてのサーバーが同じソフトウェアおよびハードウェア構成を持ち、平均的なサービス要求が比較的分散されている場合に適しています。

2.加重ラウンドロビン

サーバーの処理能力に応じて、各サーバーには異なる重みが割り当てられ、対応する重みを持つサービス要求を受け入れることができます。たとえば、サーバーAの重みは1、Bの重みは3、Cの重みは6に設計されている場合、サーバーA、B、Cはそれぞれ10％、30％、60％のサービス要求を受け取ります。このバランシングアルゴリズムにより、高性能サーバーがより多くの使用を取得し、低パフォーマンスサーバーの過負荷を回避することができます。

3.ランダム平衡（ランダム）

ネットワーク内のリクエストをランダムに内部の複数のサーバーに割り当てます。

4.加重ランダム

この種類の等化アルゴリズムは、ウェイトラウンドロビンアルゴリズムに似ていますが、要求の共有を処理するときのランダム選択プロセスです。

5.平衡応答速度（応答時間検出時間）

負荷分散デバイスは、各内部サーバーにプローブ要求（Pingなど）を送信し、プローブ要求に対する内部サーバーの最速応答時間に基づいて、クライアントのサービス要求に応答するサーバーを決定します。このバランシングアルゴリズムは、サーバーの現在の実行状態をより適切に反映できますが、最速の応答時間は、ロードバランシングデバイスとサーバー間の最速の応答時間のみを指し、クライアントとサーバー間の最速の応答時間ではありません。

6.最小接続バランス

最小接続数バランシングアルゴリズムには、内部負荷のサーバーごとにデータレコードがあり、サーバーによって現在処理されている接続の数が記録されます。新しいサービス接続要求があると、現在の要求は最小接続数に割り当てられますサーバーは、実際の状況に合わせてバランスを調整し、負荷がよりバランスされます。このバランシングアルゴリズムは、FTPなどの長時間処理要求サービスに適しています。

7.バランスの取れた処理能力（CPU、メモリ）

このバランシングアルゴリズムは、内部サーバーと現在のネットワークの処理能力を考慮に入れるため、内部処理負荷（サーバーのCPUモデル、CPU数、メモリサイズ、現在の接続数などに応じて変換）で最も軽いサーバーにサービスリクエストを割り当てます。実行ステータス。この分散アルゴリズムは比較的正確であり、特に第7層（アプリケーション層）の負荷分散に適しています。

8. DNS応答バランス（Flash DNS）

このバランシングアルゴリズムでは、地理的に異なる場所にあるロードバランシングデバイスが同じクライアントのドメイン名解決要求を受信し、同時にこのドメイン名を対応するサーバーのIPアドレスに解決してクライアントに戻ります。クライアントは、他のIPアドレスの応答を無視しながら、最初に受信したドメイン名解決IPアドレスでサービスを要求し続けます。この種のバランシング戦略がグローバルロードバランシングのアプリケーションに適している場合、ローカルロードバランシングには意味がありません。

9.ハッシュアルゴリズム

一貫性のあるハッシュ一貫性ハッシュ、同じパラメーターを持つ要求は常に同じプロバイダーに送信されます。プロバイダーが電話を切ると、元々プロバイダーに送信された要求は仮想ノードに基づいており、大幅な変更を引き起こすことなく他のプロバイダーに均等に分散されます。

10. IPアドレスのハッシュ（クライアントとサーバー間の通信が安定していることを確認してください）

送信者IPおよび宛先IPアドレスのハッシュを管理することにより、同じ送信者からのパケット（または同じ宛先に送信されたパケット）を同じサーバーに均一に転送するアルゴリズム。クライアントが一連のサービスを処理する必要があり、サーバーと繰り返し通信する必要がある場合、アルゴリズムはストリーム（セッション）を1つの単位として使用し、同じクライアントからの通信を常に同じサーバーで処理できるようにします。

11. URLハッシュ
クライアントが要求したURL情報のハッシュを管理することにより、同じURLに送信された要求を同じサーバーに転送するアルゴリズム。

---

質問3：LVSを導入しますか？

Answer3：

LVSのIP負荷分散テクノロジーは、IPVSモジュールを介して実装されます。IPVSは、LVSクラスターシステムのコアソフトウェアです。その主な機能は、Director Serverにインストールすると同時にDirector ServerのIPアドレスを仮想化することです。ユーザーはこれを渡す必要があります。サーバーにアクセスするための仮想IPアドレス。この仮想IPは一般にLVSのVIPまたは仮想IPと呼ばれます。アクセス要求は最初にVIPを介してロードスケジューラに到達し、次にロードスケジューラは実サーバーリストからサービスノードを選択してユーザーの要求に応答します。ユーザーの要求がロードスケジューラに到達した後、スケジューラがサービスを提供する実サーバーノードに要求を送信する方法、および実サーバーノードがユーザーにデータを返す方法は、IPVSによって実装される主要なテクノロジです。

ipvs：カーネル空間での作業。主にユーザー定義の戦略を有効にするために使用されます。
ipvsadm：ユーザー空間での作業。主にユーザーがクラスターサービスツールを定義および管理するために使用されます。

ipvsは、カーネルスペースのINPUTチェーンで機能します。ユーザーがクラスターサービスを要求すると、それはPREROUTINGチェーンを通過し、ローカルルーティングテーブルを確認した後、INPUTチェーンに送信されます。netfilterINPUTチェーンに入ると、ipvsは要求メッセージを強制します。 ipvsadmによって定義されたクラスターサービス戦略のパスがFORWORDチェーンに変更され、メッセージはバックエンドでサービスを提供する実際のホストに転送されます。

---

質問4：LVSの4つのモード（NAT、DR、TUN、FULLNAT）は何ですか？

Answer4：

1. LVS NATモード

①。クライアントはリクエストをフロントエンドロードバランサーに送信します。リクエストメッセージの送信元アドレスはCIP（クライアントIP）で、これを総称してCIPと呼び、宛先アドレスはVIP（ロードバランサーのフロントエンドアドレス、総称して後でVIPと呼びます）です。
②メッセージを受信した後、ロードバランサーは、要求がルールに存在するアドレスであることを検出し、クライアント要求メッセージのターゲットアドレスをバックエンドサーバーのRIPアドレスに変更し、アルゴリズムに従ってメッセージを送信します。
③。メッセージが実サーバーに送信された後、メッセージの宛先アドレスはそれ自体であるため、要求に応答し、応答メッセージをLVSに返します。
④。次に、lvsはこのメッセージの送信元アドレスをこのマシンに変更し、クライアントに送信します。

注：NATモードでは、実サーバーのゲートウェイはLVSを指す必要があります。そうしないと、メッセージをクライアントに配信できません。

LVS NATモードの特性：
1. NATテクノロジーは、要求メッセージと応答メッセージのアドレスを書き換える必要があるため、Webサイトの訪問が比較的大きい場合、LBロードバランシングスケジューラには比較的大きなボトルネックがあり、一般に最も多くの10〜20ノードにすることができます。
2. LBでパブリックIPアドレスを構成するだけです。
3.各内部実サーバーのゲートウェイアドレスは、スケジューラLBのイントラネットアドレスである必要があります。
4. NATモードは、IPアドレスとポートの変換をサポートしています。つまり、ユーザーが要求したポートと実サーバーのポートが異なる場合があります。

LVS NATモードの利点：
クラスター内の物理サーバーは、TCP / IPをサポートする任意のオペレーティングシステムを使用でき、ロードバランサーのみが有効なIPアドレスを必要とします。

LVS NATモードの欠点：
制限されたスケーラビリティ。サーバーノード（一般的なPCサーバー）が大きくなりすぎると、すべての要求パケットと応答パケットがロードバランサーを通過するため、ロードバランサーがシステム全体のボトルネックになります。サーバーノードが多すぎると、大量のデータパケットがロードバランサーに収束され、速度が遅くなります。

2. LVS DRモード（LAN書き換えMACアドレス）

①。クライアントはフロントエンドロードバランサーにリクエストを送信し、リクエストメッセージの送信元アドレスはCIP、宛先アドレスはVIPです。
②。メッセージを受信した後、ロードバランサーは、要求がルールに存在するアドレスであることを検出し、クライアント要求メッセージの送信元MACアドレスを独自のDIP MACアドレスに変更し、ターゲットMACをRIP MACアドレスに変更します。そして、このパケットをRSに送信します。
③.RSは、リクエストメッセージ内の宛先MACがそれ自体であることを確認し、セカンダリメッセージを受信します。リクエストメッセージの処理後、レスポンスメッセージは、l0インターフェイスを介してeth0ネットワークカードに送信され、クライアントに直接送信されます。

注：lOインターフェースに設定する必要があるVIPは、ローカルネットワークのarp要求に応答できません。

LVS DRモードの機能：
1.スケジューラーLB上のデータパケットの宛先MACアドレスを変更することにより、転送が実現されます。送信元アドレスは引き続きCIPであり、宛先アドレスは引き続きVIPアドレスであることに注意してください。
2.要求されたメッセージはスケジューラを通過し、RS応答処理されたメッセージはスケジューラLBを通過する必要がないため、同時アクセス数が多い場合（NATモードと比較して）使用効率は非常に高くなります。3
. DRモードはMACアドレスによって書き換えられるためメカニズムは転送を実現するため、すべてのRSノードとスケジューラLBはローカルエリアネットワークにのみ存在でき
ます。4。RSホストはVIPアドレスをLOインターフェイス（マスク32ビット）にバインドする必要があり、ARP抑制を構成する必要があります。
5. RSノードのデフォルトゲートウェイをLBとして構成する必要はありませんが、上位ルートのゲートウェイとして直接構成されているため、RSはネットワークに直接アクセスできます。
6. DRモードのスケジューラはMACアドレスのみを書き換えるため、スケジューラLBはターゲットポートを書き換えることができないため、RSサーバーはVIPと同じポートを使用してサービスを提供する必要があります。
7. WEBなどの直接外部サービスの場合、RSのIPはパブリックIPを使用するのが最適です。データベースなどの外部サービスの場合、イントラネットIPを使用するのが最適です。

LVS DRモードの利点

TUN（トンネルモード）と同様に、ロードバランサーは要求のみを分散し、応答パケットは別のルーティングメソッドを介してクライアントに返されます。VS-TUNと比較すると、このVS-DRの実装はトンネル構造を必要としないため、ほとんどのオペレーティングシステムを物理サーバーとして使用できます。

DRモードの効率は非常に高いですが、構成はもう少し複雑なので、トラフィックがそれほど多くない企業では、代わりに
haproxy / nginxを使用できます。1日あたり1000〜2000W PVまたは10,000の同時リクエストは、haproxy / nginxと見なすことができます。

LVS DRモードの短所
すべてのRSノードとスケジューラLBは、1つのLANにのみ存在できます。

3. LVS TUNモード（IPカプセル化、ネットワーク間セグメント）

①。クライアントはフロントエンドロードバランサーにリクエストを送信し、リクエストメッセージの送信元アドレスはCIP、宛先アドレスはVIPです。
②。メッセージを受信した後、ロードバランサーは、要求がルールに存在するアドレスであることを検出し、クライアント要求メッセージのヘッダーにIPメッセージの別のレイヤーをカプセル化し、送信元アドレスを宛先アドレスであるDIPに変更します。 RIPに変更し、このパケットをRSに送信します。
③。リクエストメッセージを受信した後、RSはまずカプセル化の最初の層をアンパックし、次に、その10OインターフェイスにターゲットアドレスがVIPであるIPヘッダーの層もあるので、2番目のリクエストメッセージを処理して応答メッセージを送信します。テキストはloインターフェースを介してeth0ネットワークカードに送信され、クライアントに直接送信されます。

注：10インターフェースを設定する必要があるVIPは、パブリックネットワークに表示できません。

LVS TUNモードの機能
1. TUNNELモードは、すべての実サーバーマシンのVIPのIPアドレスにバインドする必要があります 2. TUNNELモードのVIP
------> TUNNELモードによる実サーバーパケット通信、内部ネットワークと外部ネットワークの両方通信できるため、lvs vipと実サーバーが同じネットワークセグメントに存在する必要はありません。
3. TUNNELモードの実サーバーは、パケットを直接クライアントに送信しますが、LVSには送信しません。
4.トンネルモードはトンネルモードですので、運用・保守が難しいため一般的には不要です。

LVS TUNモードの利点

ロードバランサーは、要求パケットをバックエンドノードサーバーに配信することのみを担当し、RSは応答パケットをユーザーに直接送信します。そのため、ロードバランサーの大量のデータフローが削減され、ロードバランサーはシステムのボトルネックではなくなり、大量の要求を処理できるようになります。このようにして、1つのロードバランサーで多数のRSを分散できます。パブリックネットワークで実行している場合は、さまざまな地域に分散できます。

LVS TUNモードの欠点
トンネルモードの RSノードには正当なIPが必要です。この方法では、すべてのサーバーが「IPトンネリング」（IP
カプセル化）プロトコルをサポートする必要があります。サーバーは一部のLinuxシステムに限定される場合があります。

4. LVS FULLNATモード

DRモードでもNATモードでも、問題があることは避けられません。LVSとRSは同じVLANにある必要があります。そうでない場合、LVSはRSのゲートウェイとして機能できません。これによって引き起こされる2つの問題は次のとおりです。

1.同じVLANの制限により、運用と保守が不便になり、VLAN間のRSにアクセスできません。
2. LVSの水平方向の拡張は制限されています。RSを水平方向に拡張すると、その上のシングルポイントLVSがいつかボトルネックになるでしょう。

これからフルNATが生まれ、LVSとRS間のクロスVLANの問題が解決されました。クロスVLANの問題が解決された後、LVSとRSのVLAN間に下位関係がなくなり、複数のLVSが複数のRSに対応できるようになりました。水平拡張の問題。

NATと比較したFull-NATの主な改善点は、SNAT / DNATに加えて別の変換に基づいて、変換プロセスが次のようになっていることです。

1. パケットをLVSからRSに転送するプロセスでは、ソースアドレスがクライアントIPからLVSのイントラネットIPに置き換えられます。イントラネットIPは、複数のスイッチを介してVLAN間で通信できます。ターゲットアドレスがVIPからRS IPに変更されます。
2. RSが受信したパケットを処理して処理後に戻ると、ターゲットアドレスがLVS ipに変更され、元のアドレスがRS IPに変更され、最後にパケットがLVSイントラネットIPに返されます。この手順はVLANに限定されません。
3. パケットを受信すると、LVSはNATモードで送信元アドレスを変更し、RSによって送信されたパケットの宛先アドレスをLVSイントラネットIPからクライアントのIPに変更し、元のアドレスをVIPに変更します。

Full-NATの主なアイデアは、ゲートウェイとその下のマシン間の通信を通常のネットワーク通信に変更することで、VLAN間問題を解決することです。このように、LVSとRSの導入では、VLANに対する制限がなくなり、O＆M導入の利便性が大幅に向上します。

LVS FULLNATモードの機能

1. フルNATモードでは、LBIPと実サーバーIPが同じネットワークセグメント上にある必要はありません。
2. ソースIPを更新する必要があるため、完全なnat、パフォーマンスは通常natモードよりも10％低い

---

質問5：キープアライブを導入しますか？

回答5：

キープアライブはもともとLVS用に設計され、特にlvsの各サービスノードのステータスを監視するために使用され、後でvrrpの機能が追加されたため、lvsに加えて、他のサービス（nginx、haproxy）の高可用性ソフトウェアとしても使用できます。VRRPは、仮想ルーター冗長プロトコルの略です。VRRPの出現は、静的ルーティングの単一障害点を解決することであり、ネットワークが中断なく安定して実行されることを保証できます。したがって、キープアライブには、一方でLVSクラスターノードのヘルスチェック機能があり、他方でLVSディレクターフェイルオーバーがあります。

---

質問6：Nginxリバースプロキシの負荷分散方法を紹介しますか？

回答6：

Nginxリバースプロキシでの負荷分散

LVSなどの通常の負荷分散ソフトウェアは、要求パケットの転送と配信のみを実装します。負荷分散の観点からは、ポイントサーバーでは、受信した要求は、ロードバランサーにアクセスするクライアントからの実際のユーザーです。 ;リバースプロキシは異なります。アクセスユーザーからリクエストを受信すると、リバースプロキシサーバーはリクエストプロキシの下でノードサーバーを再起動し、最終的にデータをクライアントユーザーに返します。ノードサーバーから見ると、アクセスされるノードサーバーのクライアントユーザーは、実際のWebサイトアクセスユーザーではなく、リバースプロキシサーバーです。

アップストリームモジュールとヘルスチェック

ngx_http_upstream_moduleは、ウェブサイトの負荷分散機能、つまりノードのヘルスチェックを実現できる負荷分散モジュールです。上流モジュールは、Nginxがノードサーバーグループの1つ以上のグループを定義できるようにします。これを使用すると、proxy_passプロキシを介して事前定義されたWebサイトリクエストを送信できます。アップストリームグループの名前に対応します。

アップストリームモジュールのパラメーター	パラメータの説明
重量	サーバーの重量
max_fails	Nginxがバックエンドホストへの接続に失敗した場合、この値は3つのパラメーターproxy_next_upstream、fastcgi_next_upstream、およびmemcached_next_upstreamと組み合わせて使用​​されます。Nginxは、バックエンドサーバーから返されたこれら3つのパラメーターで定義されたステータスコードを受信すると、このリクエストを正常に機能しているバックエンドサーバーに転送します。404、503、503、max_files = 1など。
fail_timeout	通常、max_failsとfail_timeoutは関連付けて使用されます。サーバーがfail_timeout時間中にmax_fails回の接続に失敗した場合、nginxはハングアップしたと見なし、fail_timeout時間中に再度要求しないため、fail_timeoutのデフォルトは10秒、max_failsのデフォルトですこれは1で、デフォルトでエラーが発生する限りサーバーがハングすることを意味します。max_failsが0に設定されている場合、このチェックをキャンセルすることを意味します。
バックアップ	現在のサーバーがスタンバイサーバーであり、他の非バックアップバックエンドサーバーがダウンしているかビジーである場合にのみ、要求を割り当てます。
ダウン	フラグサーバーは使用できません。ip_hashで使用できます

upstream lvsServer{
server 191.168.1.11 weight=5 ;
server 191.168.1.22:82;
server example.com:8080 max_fails=2 fail_timeout=10s backup;
#域名的话需要解析的哦，内网记得 hosts
}

proxy_passリクエスト転送

proxy_passディレクティブはngx_http_proxy_moduleモジュールに属しています。このモジュールはリクエストを別のサーバーに転送できます。実際のリバースプロキシ作業では、ロケーション関数を介して指定されたURIと照合し、proyx_passを介してサービスマッチングURIを受け取るリクエストを定義にスローします良い上流ノードプール。

location /download/ {
proxy_pass http://download/vedio/;
}
#这是前端代理节点的设置
#交给后端 upstream 为 download 的节点

プロキシモジュールパラメータ	解説
proxy_next_upstream	リクエストを次のアップストリームに渡すタイミング
proxy_limite_rate	応答がバックエンドサーバーから読み取られる速度を制限する
proyx_set_header	HTTPリクエストヘッダーを設定し、それをバックエンドサーバーノードに渡します。たとえば、プロキシバックエンドのサーバーノードがクライアントにアクセスできるようにすることができます。これはipです。
client_body_buffer_size	クライアント要求本文のバッファーサイズ
proxy_connect_timeout	エージェントがバックエンドノードサーバーに接続するためのタイムアウト時間
proxy_send_timeout	バックエンドノードのデータリターンのタイムアウト時間
proxy_read_timeout	Nginxがプロキシのバックエンドサーバーから情報を取得する時間を設定します。これは、接続が正常に確立された後、Nginxがバックエンドサーバーの応答時間を待つことを示します。
proxy_buffer_size	バッファサイズを設定する
proxy_buffers	バッファの数とサイズを設定する
proyx_busy_buffers_size	システムがビジーなときに使用できるproxy_buffersのサイズを設定するために使用されます。推奨されるproxy_buffers * 2
proxy_temp_file_write_size	プロキシキャッシュの一時ファイルのサイズを指定する