クラスタ負荷等化技術の概要
3970 ワード
クラスタ負荷等化技術(Load Balancing)は現在のインターネットバックエンドサービスの重要な技術であり、インターネットシステムが現在のような巨大な規模に進化した基礎である.
客観的に言えば、負荷等化はかなり敷居の低い分野であり、既存の技術は主にハードウェアスキームとソフトウェアスキームを含む.簡単に言えば、ハードウェアスキームは性能が良いが、高価である.ソフトウェア・スキーマはパフォーマンスが悪いが、コストは相対的に制御可能である.
ハードウェア案はF 5、Ctrix、A 10、RedwareなどのLBメーカーの製品を代表し、毎年市場収益額は100億ドルに達している.
オープンソースのソフトウェア実装案も少なくなく、HAProxy、Nginx、LVSなどが知られている.
実際の大規模で高性能なシナリオでは、信頼性の高い負荷分散サービスを単一のスキームで実現することは困難であることが多い.
多くのLBメーカーは現在、「負荷等化装置」という用語を使用せず、アプリケーション配布(ADC、ADN)装置(さらには直接4-7層スイッチと呼ぶ)と改称しているが、これらの装置の中で最も基礎的で重要な技術は依然として大量の流量を処理する負荷等化技術である.
実際、クライアントが負荷等化を感知または参加できるかどうかの過程から区別すると、まず負荷等化技術を大きく2つに分けることができる:クライアントが感知できる負荷等化とクライアントの透明な負荷等化.もちろん、2つの技術はさらに結合して使用することができます.
クライアントが負荷分散を感知
名前の通り、クライアントは負荷等化プロセスに積極的に参加し、負荷等化の存在を感知することができる.
典型的な例は、サービスアドレスを動的に知る必要があるクライアントアプリケーションである.この意味では,多くのP 2 Pアプリケーションがこの範疇に属する.
基本的な手順は、クライアントが制御(Control)サーバに要求を開始し、サービス(Service)サーバアドレス(ドメイン名またはIPアドレス)のリストを取得することである.リストの取得に成功すると、ローカルは何らかの均衡ポリシーに従ってこれらのビジネスサーバに要求を発行します.
このような利点は、サーバ側の負荷分散の要件を低減し、サービス側が負荷分散を必要とせず、単純なリソースプールであればよいことが明らかです.
技術的な難点は、主にクライアントとサービス・エンド間の情報同期にある.例えば、業務サーバープールの調整後、情報はどのようにタイムリーにクライアントに更新されますか?一部のロード・バランシング・ポリシーでは、リアルタイム・サーバのステータス情報などを取得する必要があります.
具体的な実装では、クライアントとサービス側の協力が必要になることが多い.特定のビジネスシーンに対して、Yahooがいくつかのインターネットビジネスでこのモードを使用しているなど、いくつかの調整と最適化を行うことができます.
デスクトップ時代のクライアントは制御性が悪く、状況が複雑で、このモデルの実現は難しい.
現在、モバイルインターネットが発展した後、クライアントAPPの制御性が大幅に向上し、このようなモデルの応用見通しが期待されている.
クライアントの透過的な負荷分散
クライアントの透明な負荷分散には、実際には多くのレベルの技術が含まれています.ここでは、統合されています.異なる実装は異なる場所(キャリアやサービス業者など)に置かれる可能性があるが、原理は一致しており、核心は「Overlay」の思想を借りている(コンピュータ業界のすべての問題は、基本的に新しい層を導入することで実現できる).
次に、クライアントが要求を発行した後の完了プロセスから、どのステップで負荷等化を実現できるかを示します.
DNS層
まず,クライアントはある業務サーバのドメイン名に要求を開始し,まずこのドメイン名を具体的なIPアドレスとして解析する.
ドメイン名解析というできることはたくさんありますが、大体は運営者がローカルに応答するか、運営者がサービス業者のドメイン名サーバーに投げます.
前者(一般的に)であれば、事業者はローカルcacheで照会し、ヒットがなければ上位ドメイン名サービスやサービス業者に投げつける.
ドメイン名解析の過程はLBの効果を直接決定する.ここで問題があります.ドメイン名は運営者が維持して回答しているので、変化すると、サービス業者はどのように迅速に調整しますか.伝統的なドメイン名の更新方法は数分から数時間の遅延に達することができます.
1つの考え方は運営者と話して、すべての関連要求はサービス業者が自分で処理したり、どのように協力して迅速に更新したりすることができますか?一つは、リクエストをキャリアを迂回し、トンネルを自分に与える(またOverlay)、テンセントのHttpDNSはこの考え方であり、ドメイン名解析は伝統的なDNSプロトコルではなく、HTTPリクエストを通じて実現される.
まとめると、DNSベースのLB方式は比較的簡単で直接的で、実現しやすいが、問題も少なくなく、主にマルチレベルDNS構造が制御できず、分布が不均一になりやすく、タイムリーなリフレッシュが難しいなどがある.
IP層
IPを取得すると、クライアントは対応するIPアドレスを要求し、その後、ソースアドレスがそのIPである応答パケットを受信するのを待つことができる.もちろん、LBでこのアドレスを置き換えて、バックエンドのリアルサービスプールに送ることができます.これも現在大量の3/4層負荷イコライザの基本原理である.
実際には,前面にDNS等化を1層,後に3/4層の負荷等化を行い,大規模なシーンをサポートできるようになった.
典型的には、LVSはこのようなソフトウェアスキームであるが、具体的には、LVSは、NAT(Network Address Translation)、DR(Direct Routing)、TUN(IP Tunneling)の3つのモードをサポートする.NATはLBをNATゲートウェイにすることです.DRとTUNはトラフィックをバックエンドサーバに転送し,後のサーバに自分で処理させ,三角ルートを形成する方法を考えている.
まず、負荷イコライザにはVIP(ユーザが見たサービスアドレス)とDIP(バックエンドサービスの生存を検出するためのもの)があり、バックエンドの実際のサーバにはRIPがあります.
NATモードでは,要求と応答トラフィックが負荷イコライザを通過し,性能が劣る.
ネットワークアドレス変換により、スケジューラは要求メッセージのターゲットアドレスを書き換え、予め設定されたスケジューリングアルゴリズムに基づいて、要求をバックエンドの実際のサーバに割り当てる.実際のサーバの応答メッセージがスケジューラを通過すると、メッセージのソースアドレスが書き換えられ、顧客に返され、負荷スケジューリングプロセス全体が完了します.
DRモードでは、要求メッセージの宛先MACアドレスがある実サーバのMACであることを書き換え(ARP要求は自動的に応答できないに違いない)、要求を実サーバに送信する.実際のサーバは、応答を直接お客様に返します.このモデルはモデルを拡張しているが、LBは実際のサーバと2層接続できることが要求されている.このモードは性能がいいので、たくさん使います.
TUNはDRがネットワークにまたがることができない問題を解決し、MACを転送するのではなく、完全なパッケージをパッケージしてIP転送を行い、DR処理よりも複雑である.
また、Sessionの一貫性を保証するには、IPヘッダとTCPヘッダに基づいて内部Sessionテーブルを検索して、以前の決定を見つけ、ストリームが同じマシンにスケジューリングされることを保証する必要があります.この意味では,接続向けのすべての負荷イコライザは4層に属するべきである.
実際には、10～数十台のバックエンドサーバをサポートするのが適切です.
アプリケーション層
ユーザがリソースにアクセスするには、URIを介して、1つのIPアドレス上で複数のURIをサポートする必要があり、3層の等化と同時に、
このような応用層の均衡は、もちろん最も柔軟で、多段に分けることができるが、応用層の情報を見るため、計算の複雑性が大きく、イコライザに対する要求も比較的高く、高性能を作ることができることは少ない.
転載は以下のことを明記してください.http://blog.csdn.net/yeasy/article/details/50413558
客観的に言えば、負荷等化はかなり敷居の低い分野であり、既存の技術は主にハードウェアスキームとソフトウェアスキームを含む.簡単に言えば、ハードウェアスキームは性能が良いが、高価である.ソフトウェア・スキーマはパフォーマンスが悪いが、コストは相対的に制御可能である.
ハードウェア案はF 5、Ctrix、A 10、RedwareなどのLBメーカーの製品を代表し、毎年市場収益額は100億ドルに達している.
オープンソースのソフトウェア実装案も少なくなく、HAProxy、Nginx、LVSなどが知られている.
実際の大規模で高性能なシナリオでは、信頼性の高い負荷分散サービスを単一のスキームで実現することは困難であることが多い.
多くのLBメーカーは現在、「負荷等化装置」という用語を使用せず、アプリケーション配布(ADC、ADN)装置(さらには直接4-7層スイッチと呼ぶ)と改称しているが、これらの装置の中で最も基礎的で重要な技術は依然として大量の流量を処理する負荷等化技術である.
実際、クライアントが負荷等化を感知または参加できるかどうかの過程から区別すると、まず負荷等化技術を大きく2つに分けることができる:クライアントが感知できる負荷等化とクライアントの透明な負荷等化.もちろん、2つの技術はさらに結合して使用することができます.
クライアントが負荷分散を感知
名前の通り、クライアントは負荷等化プロセスに積極的に参加し、負荷等化の存在を感知することができる.
典型的な例は、サービスアドレスを動的に知る必要があるクライアントアプリケーションである.この意味では,多くのP 2 Pアプリケーションがこの範疇に属する.
基本的な手順は、クライアントが制御(Control)サーバに要求を開始し、サービス(Service)サーバアドレス(ドメイン名またはIPアドレス)のリストを取得することである.リストの取得に成功すると、ローカルは何らかの均衡ポリシーに従ってこれらのビジネスサーバに要求を発行します.
このような利点は、サーバ側の負荷分散の要件を低減し、サービス側が負荷分散を必要とせず、単純なリソースプールであればよいことが明らかです.
技術的な難点は、主にクライアントとサービス・エンド間の情報同期にある.例えば、業務サーバープールの調整後、情報はどのようにタイムリーにクライアントに更新されますか?一部のロード・バランシング・ポリシーでは、リアルタイム・サーバのステータス情報などを取得する必要があります.
具体的な実装では、クライアントとサービス側の協力が必要になることが多い.特定のビジネスシーンに対して、Yahooがいくつかのインターネットビジネスでこのモードを使用しているなど、いくつかの調整と最適化を行うことができます.
デスクトップ時代のクライアントは制御性が悪く、状況が複雑で、このモデルの実現は難しい.
現在、モバイルインターネットが発展した後、クライアントAPPの制御性が大幅に向上し、このようなモデルの応用見通しが期待されている.
クライアントの透過的な負荷分散
クライアントの透明な負荷分散には、実際には多くのレベルの技術が含まれています.ここでは、統合されています.異なる実装は異なる場所(キャリアやサービス業者など)に置かれる可能性があるが、原理は一致しており、核心は「Overlay」の思想を借りている(コンピュータ業界のすべての問題は、基本的に新しい層を導入することで実現できる).
次に、クライアントが要求を発行した後の完了プロセスから、どのステップで負荷等化を実現できるかを示します.
DNS層
まず,クライアントはある業務サーバのドメイン名に要求を開始し,まずこのドメイン名を具体的なIPアドレスとして解析する.
ドメイン名解析というできることはたくさんありますが、大体は運営者がローカルに応答するか、運営者がサービス業者のドメイン名サーバーに投げます.
前者(一般的に)であれば、事業者はローカルcacheで照会し、ヒットがなければ上位ドメイン名サービスやサービス業者に投げつける.
ドメイン名解析の過程はLBの効果を直接決定する.ここで問題があります.ドメイン名は運営者が維持して回答しているので、変化すると、サービス業者はどのように迅速に調整しますか.伝統的なドメイン名の更新方法は数分から数時間の遅延に達することができます.
1つの考え方は運営者と話して、すべての関連要求はサービス業者が自分で処理したり、どのように協力して迅速に更新したりすることができますか?一つは、リクエストをキャリアを迂回し、トンネルを自分に与える(またOverlay)、テンセントのHttpDNSはこの考え方であり、ドメイン名解析は伝統的なDNSプロトコルではなく、HTTPリクエストを通じて実現される.
まとめると、DNSベースのLB方式は比較的簡単で直接的で、実現しやすいが、問題も少なくなく、主にマルチレベルDNS構造が制御できず、分布が不均一になりやすく、タイムリーなリフレッシュが難しいなどがある.
IP層
IPを取得すると、クライアントは対応するIPアドレスを要求し、その後、ソースアドレスがそのIPである応答パケットを受信するのを待つことができる.もちろん、LBでこのアドレスを置き換えて、バックエンドのリアルサービスプールに送ることができます.これも現在大量の3/4層負荷イコライザの基本原理である.
実際には,前面にDNS等化を1層,後に3/4層の負荷等化を行い,大規模なシーンをサポートできるようになった.
典型的には、LVSはこのようなソフトウェアスキームであるが、具体的には、LVSは、NAT(Network Address Translation)、DR(Direct Routing)、TUN(IP Tunneling)の3つのモードをサポートする.NATはLBをNATゲートウェイにすることです.DRとTUNはトラフィックをバックエンドサーバに転送し,後のサーバに自分で処理させ,三角ルートを形成する方法を考えている.
まず、負荷イコライザにはVIP(ユーザが見たサービスアドレス)とDIP(バックエンドサービスの生存を検出するためのもの)があり、バックエンドの実際のサーバにはRIPがあります.
NATモードでは,要求と応答トラフィックが負荷イコライザを通過し,性能が劣る.
ネットワークアドレス変換により、スケジューラは要求メッセージのターゲットアドレスを書き換え、予め設定されたスケジューリングアルゴリズムに基づいて、要求をバックエンドの実際のサーバに割り当てる.実際のサーバの応答メッセージがスケジューラを通過すると、メッセージのソースアドレスが書き換えられ、顧客に返され、負荷スケジューリングプロセス全体が完了します.
DRモードでは、要求メッセージの宛先MACアドレスがある実サーバのMACであることを書き換え(ARP要求は自動的に応答できないに違いない)、要求を実サーバに送信する.実際のサーバは、応答を直接お客様に返します.このモデルはモデルを拡張しているが、LBは実際のサーバと2層接続できることが要求されている.このモードは性能がいいので、たくさん使います.
TUNはDRがネットワークにまたがることができない問題を解決し、MACを転送するのではなく、完全なパッケージをパッケージしてIP転送を行い、DR処理よりも複雑である.
また、Sessionの一貫性を保証するには、IPヘッダとTCPヘッダに基づいて内部Sessionテーブルを検索して、以前の決定を見つけ、ストリームが同じマシンにスケジューリングされることを保証する必要があります.この意味では,接続向けのすべての負荷イコライザは4層に属するべきである.
実際には、10～数十台のバックエンドサーバをサポートするのが適切です.
アプリケーション層
ユーザがリソースにアクセスするには、URIを介して、1つのIPアドレス上で複数のURIをサポートする必要があり、3層の等化と同時に、
Front_IP:80/app1にアクセスするトラフィックがBack_IP1:80/app1に割り当てられるなど、これらのURIに基づいて具体的な配布ポリシーを制定することができる.Front_IP:80/app2までの流量はBack_IP1:80/app2などに分配される.このような応用層の均衡は、もちろん最も柔軟で、多段に分けることができるが、応用層の情報を見るため、計算の複雑性が大きく、イコライザに対する要求も比較的高く、高性能を作ることができることは少ない.
転載は以下のことを明記してください.http://blog.csdn.net/yeasy/article/details/50413558