大規模サイトの負荷分散アーキテクチャ

ロードバランシング ロードバランシングは既存のネットワーク構造上に構築され、ネットワークデバイスやサーバーの帯域幅を拡張し、スループットを向上させ、ネットワークデータ処理能力を強化し、ネットワークの柔軟性と可用性を向上させる、安価で効果的かつ透過的な方法を提供します。

大規模サイトの負荷分散に最適なツール

• グローバル負荷分散システム
• コンテンツキャッシングシステム
• サーバー負荷分散システム

DNSドメイン名解決の基本プロセス

初期負荷分散ソリューション

バンテージ

• ドメインレジストラがこの種の解決に無料で対応していることが多いため、基本的に費用はかかりません；
• ネットワーク・トポロジーの単純な拡張に加え、新しいウェブサーバーはパブリックIPを追加するだけで簡単に導入できます。

欠点

• ヘルスチェックでは、サーバーがダウンしていても、DNSサーバーはそれを知ることができず、このサーバーへのアクセスを割り当てます。すべてのDNSレコードの変更が有効になるには、それ以上ではないにしても、少なくとも3～4時間かかります；
• 不均等な分散、複数のウェブサーバ間で構成が異なれば、異なる圧力に耐えることができますが、DNS解決によって割り当てられるアクセスは均等に分散されます。ユーザーベースの不均等な分布は、不均等なDNS解決につながります。
• セッション・ホールドは、認証が必要なサイトの場合、DNS解決が認証されたユーザーのアクセスを同じサーバーに永続的に割り当てることができないため、ソフトウェア・アーキテクチャを変更することなく、これはより致命的です。特定のローカルDNSキャッシュがありますが、それは、ローカルDNSは、ユーザーの訪問中に有効期限が切れていないことを確認することは困難であり、サーバーを再照会し、新しいサーバーを指すように、その後、元のサーバーは、ユーザー情報を新しいサーバーに持って来ることができない保存するために、スイッチのアイデンティティの再認証が必要な場合があります前後に長い時間、様々なサーバー上のユーザーの情報を保存するために異なっている、それはまた、サーバーリソースの無駄です。切り替えを行ったり来たりすると、各サーバ上のユーザ情報が異なることになり、サーバリソースの無駄遣いになります。

グローバル負荷分散システム

ゆうせい

• データセンターの冗長性
• マルチサイトトラフィックの最適化
• ユーザーエクスペリエンスを確保

グローバル負荷分散システムの原理

DNSチェックツールはネット上にたくさんあるので、興味があれば検索してみてください。

コンテンツ・キャッシング・システム

• コンテンツ・キャッシング・システム
• コンテンツ・キャッシング・システムの動的高速化

動的加速度の特徴

• インテリジェントルーティング
• 伝送制御プロトコルの最適化
• HTTP

#p#

サーバー負荷分散システム

応募の背景

• アクセストラフィックの急増
• ビジネスボリュームの増加

ユーザーニーズ

• 24時間365日の無停止可用性と迅速なシステム応答時間の要望

サーバー負荷分散システムへの3種類のアクセス方法

サーバ負荷分散システムの一般的なスケジューリングアルゴリズム

• ポーリング
• 重み付けポーリング
• 最小接続
• 加重最小接続数

健康診断

健全性チェックアルゴリズムの目的：サービスのHA能力を向上させるため、何らかのプロービングメカニズムを通じてサーバクラスタ内の実サーバの健全性をチェックし、障害が発生したサーバへのクライアントリクエストの分散を回避すること。

現在一般的に使用されている健康度スクリーニングのアルゴリズム：

• Ping
• TCP
• HTTP
• FTP

システム加速

最適化機能 - SSLアクセラレーション

最適化機能 - HTTP圧縮

HTTP圧縮は、ebサーバとブラウザ間で圧縮されたテキストコンテンツを転送する方法です。 HTTP圧縮テクノロジーは、インテリジェントな圧縮機能を備えたBIG-IPシステムを通じて、アプリケーションの配信時間を短縮し、帯域幅を最適化します。http圧縮は、一般的な圧縮アルゴリズムを使用してファイルを圧縮（SS化）します。圧縮の最大のメリットは、ネットワークを介して送信されるデータ量を削減できるため、クライアント・ブラウザのアクセス速度が向上することです。

最適化機能 - 接続の再利用

最適化機能 - TCPキャッシュ

#p#

セッションホールド

セッション・ホールド-クライアント・ソースIPセッション・ホールド

送信元IPアドレスセッションホールドとは、同じ送信元IPアドレスからの接続やリクエストを同じユーザーとみなし、セッションホールドポリシーに従って、セッションホールド有効期間内に同じ送信元IPアドレスからの接続やリクエストをすべて同じサーバーに転送することです。

セッションホールド - クッキーセッションホールド

ソースアドレスベースのセッションホールドの使用は、クライアントが接続要求のソースIPアドレスが比較的固定されているような負荷分散を達成することができない場合、このような問題は、通常、アプリケーション層のセッションホールドの方法に基づいて使用することができ、クッキーは通常、HTTPヘッダに存在する、今日ではTPベースのアプリケーションが広く使用されているので、クッキーに基づいてセッションホールドは、より多くのサーバーの負荷分散に表示されます。解決策

制限事項

HTTP以外のプロトコル、またはクライアントでieが無効になっている場合は無効です。

セッションホールド - URLハッシュセッションホールド

ハッシュセッションメンテナンスの基本的なコンセプトの一つは、特定のハッシュファクターと、バックグラウンドに存在するサーバーの数に基づいて計算された、特定のハッシュファクターに従って、どのサーバーにリクエストを割り当てるかを選択することです。ハッシュセッションホールドの特徴は、バックエンドサーバの健康状態が変化しない場合、各特定のハッシュファクターが割り当てられるサーバが固定されるという事実です。その最大の利点は、ハッシュセッションホールドは、セッションホールドテーブルを使用しないことができますが、唯一の計算結果に基づいて、そのサーバーに割り当てられるサーバーを決定するために、特にいくつかのセッションホールドテーブルのクエリのオーバーヘッドは、ハッシュ計算のオーバーヘッドよりもはるかに大きいされている、ハッシュセッションホールドの使用は、システムの処理能力と応答速度を向上させることができます。

URLハッシュセッションの保持は、通常、バックグラウンドでCacheサーバーが使用されるアプリケーションシナリオのために行われ、同じURLのリクエストを同じCacheサーバーに割り当てるために、URLに対してハッシュ計算が実行され、バックグラウンドのCacheサーバーグループに対して、各Cacheサーバーに格納されるコンテンツが異なり、Cacheサーバーの利用率が向上します。

失敗事例分析

Q&A ケーススタディ - ループ・ジャンプ

故障現象：

ウェブサーバは、ユーザがアクセスしたURLを判断し、https以外のリクエストに対してはtpサイトにリダイレクトするため、ユーザは常に02ジャンプすることになります。

原因分析：

ロードバランシングSSLアクセラレーションが使用され、すべてのユーザーリクエストはhttpから来ているようにサーバー側で表示されます。

解決策

サイト全体でSSLアクセラレーションが有効になっています。

Q&A ケーススタディ - ユーザーセッションの損失

故障現象：

ユーザーがhttpサイトから同じドメインのpsサイトにデータを送信すると、ebプログラムがon lost例外をスローし、ユーザーはデータの送信に失敗します。

原因分析：

httpとpsはロードバランシングデバイス上で2つの別個のサービスとみなされ、2つの別個のCPリンクが生成され、異なる実サーバーにヒットし、結果として損失が発生します。

解決策

ロードバランシングアプライアンス上の実サーバーに基づいてセッションホールドを有効にします。

Q&A ケーススタディ-クライアントのソースIPが取得できない

故障現象：

サーバーはユーザーのエクストラネットのIPアドレスを取得せず、イントラネットの特定のセグメントからの多数のIPアドレスしか見ません。

原因分析：

負荷分散装置がユーザーソースアドレス変換モードを有効にし、TCPメッセージのユーザーソースIPを変更しました。

解決策

ロードバランシングデバイスは、x-forwarded-for値をユーザーの外部IPで書き換え、サーバーはhttpプロトコルのヘッダーのx-forwarded-for値をユーザーのソースIPとして使用します。IISログは、インストールされているプラグインの形式でユーザーのソースIPを表示します。

サーバー負荷分散装置の選択

1.価格要因

ハードウェア： F5、Citrix、Redware、A10

ソフトウェア：LVS、Nginx、Haproxy、zen loadbalance

2.パフォーマンス

レイヤ4/7スループット

レイヤー4/7での新規接続数

同時接続数

機能モジュールのパフォーマンス指標

3.現実と将来のニーズへの対応

(1)負荷分散装置が最も単純なレイヤ4処理で全てのアプリケーションを処理することが確認された場合、理論的には実際の要求性能より若干高いレイヤ4性能を持つ負荷分散装置を選定すれば十分です。

(2) 負荷分散装置が全てのアプリケーションを処理することが単純なレイヤ 7 処理であることが確 認される場合、理論上、実際の要求性能よりも若干高いレイヤ 7 性能を持つ負荷分散装置を選定すれ ばよい。

3) 負荷分散装置がレイヤ4アプリケーションとレイヤ7アプリケーションの両方を扱う場合、レイヤ7アプリケーションの性能に応じて負荷分散装置を検討することを推奨します。

(4）それが確認された場合、そのアプリケーションは、負荷分散プロセスを通じて、複雑なレイヤ4またはレイヤ7処理の必要性、クライアントのアドレスに基づいて戦略的な配布を行う必要性など、tcpの内容に基づいて処理を行う必要性、HTTPヘッダまたはTPメッセージに基づいて処理を行う必要性、それは負荷分散装置/レイヤ7 2回の実際のパフォーマンスのニーズのパフォーマンスの必要性の選択をお勧めします。

(5) ロードバランシングデバイスに複雑なトラフィック処理が混在しており、いくつかの機能モジュールも開いている場合、ロードバランシングデバイスのレイヤー4/7の性能は、実際の性能要件の3倍を選択することをお勧めします。

6) 装置をより安定させるために軽負荷で動作させる必要があることを考慮し、可能であれば上記に加えて性能を30%向上させてください。

(7）あなたはまた、上記の基礎の上に、今後数年間の開発ニーズを満たすためにしたい場合だけでなく、パフォーマンスを向上させる必要性の将来の発展を残します。

(8）異なるアーキテクチャに起因する負荷分散装置の製造業者は、複雑な環境では、いくつかの機器はまた、より良いを実行する可能性があり、この顧客は判断を比較することができますが、一般的に、上記の推奨事項は、機器のすべてのメーカーに適しています。