- Why Edgenexus?
- Try
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
ロードバランサ/ADC ALB-Xテストドライブチュートリアル
(ADC アプリケーションデリバリコントローラ)
試乗はこちらから
目次
ALB-Xロードバランサーを楽しんでいただき、現実的な構成で遊んでいただきたいと思います。
-
このテストドライブの一環として、いくつかのサービス例を事前に設定し、すぐにご利用いただけるようにしています。
-
私たちはこのセットアップをAzure上でホストしていますが、Azureアカウントを持っている必要はありませんし、無料ですのでご安心ください。
-
アプライアンスを再設定して、ご自身のサーバーでお試しください。
ここでは、ユーザーインターフェイスをナビゲートし、テストドライブを最大限に活用するのに役立ついくつかの言葉を紹介します。
ALB-Xテストドライブにサインアップすると、ウェブブラウザからALB-X GUIにアクセスするための独自のURLが表示されます。 可能であれば、Google Chromeブラウザの使用をお勧めします。
- GUIは非標準ポート:27376を使用してアクセスされるため、標準のHTTPSポート:443が負荷分散サービスとして割り当てられることに注意してください。
- SSLセキュリティの警告が表示されても心配しないでください。これは、管理接続がデフォルトでローカル証明書を使用して保護されているためです。
プロンプトが表示されたら、このテストドライブセッション用に固有のユーザー名とパスワードを入力してください（電子メールで送信されています）。
Azureテストドライブのセットアップ
- Azureは、インターネットのパブリックIPアドレス空間から内部のプライベートIPアドレスへのアクセスを提供するために、1:1のNATポートマッピングを使用します。
-
ロードバランサーアプライアンスに自動的に設定される IP アドレスは、Azure のプライベート IP アドレスを使用します。
-
もちろん、Azureを設定して、追加サービスのためにさらに多くのポートを開いたりNATにしたりすることもできる。
-
このデモでは、ポート80、443、27376（GUI用）のみが開放されている。
ALB-Xテストドライブ事前入力サービス
これはカスタムテストドライブであるため、IP-Servicesにはすぐに試せるサービスをあらかじめ入れてあります。 テストドライブの目的で、2つの一般公開されているウェブサーバーで実際のサーバーコンテンツを利用できるようにしました：
- ALB-X は DNS を使用して名前をパブリック IP アドレスに解決することができる。 これらの各サイトには、どのサイトがコンテンツを提供したかを示すテキストや画像が表示され、負荷分散プロセスが実際に行われていることを確認できる。
4つのデモサービスをご用意しています：
|
名称
|
ポート
|
アクセシビリティ
|
|---|---|---|
|
HTTP最小接続の負荷分散
|
80
|
http://yoururl
|
|
HTTPSオフロード
|
443
|
https://yoururl
|
|
クッキーベースの永続性
|
601
|
http://yoururl/601/
|
|
ボディテストの書き直し
|
602
|
http://yoururl/?602
|
ポート80のサービス - HTTPの最小接続のロードバランシング
最初のサービスは、基本的なポート80のウェブサーバーのロードバランサーで、「最小接続」のロードバランサーポリシーを使い、2つの「実際のサーバー」に接続します。
- ブラウザで、ALB-X の管理アクセスと同じ Public IP アドレスに HTTP 接続を開くと、以下のようなものが返されます。
ポート443のサービス - SSLオフロード
つ目のサービスは443番ポートだ。 この場合、ロードバランサーはSSLの「オフロード」と呼ばれる暗号化を行っている。
- テストドライブデモではデフォルトのSSL証明書を使用しているため、このチャンネルに接続するとブラウザに同じセキュリティ警告が表示されます。
ご自身のSSL証明書をアップロードし、サービスに適用してください。 セキュリティの例外をクリックすると、ブラウザに同じ内容が表示されます。
HTTPからHTTPSへのリダイレクト
flightPATHを 使う最初のものは、HTTPからHTTPSへのリダイレクトだ。
これは、ウェブトラフィックが安全な接続を使用して提供されることを保証するためによく使用される機能です。
- flightPATHルールを事前に設定し、ポート80のHTTPチャネルに適用して、クエリー文字列が次のようなリクエストを探すようにした：/のクエリー文字列を持つリクエストを探すようにした。
/?secure
もしflightPATHがこの'条件'を見つけたら、トラフィックに対応し、ブラウザに302リダイレクトを返し、HTTPS://your.original.request.locationへの別のGETリクエストを実行するよう指示する。
flightPATHルールがどのように設定されているか、今一度見てみるといいだろう。
左のライブラリー タブをクリックし、flightPATHを選択します。
Force HTTPS - when query string is secure（HTTPSを強制実行 - クエリー文字列がセキュアな場合）」 エントリーをクリックすると
- "条件 "はクエリ文字列がsecureを含んでいる
または
- "Action "はRedirect 302 https://$host$$path$$querystring$ ($はルールアクションで使える便利な変数)
クッキーの永続性とパスに基づくサーバーの使用
このため、サーバー1とサーバー2の両方から画像が返されます。 これは、デフォルトのロードバランシングポリシーが「最小接続数」であるためで、これにより、サービスに設定されたすべてのサーバーへの接続数を均等に保とうとします。
- 覚えておいてください：画像、ビデオ、JSなど、ウェブページ内のすべてのオブジェクトは、それぞれウェブサーバーに個別のGETリクエストを行います。 この動作はアプリケーションと相性が悪いかもしれない。アプリケーションは「永続性」や「粘着性」を要求するかもしれない。
HTTPサービスの場合、これは、ブラウザがそのサービスに対する以降のすべてのリクエストに、通常は「セッション」の期間だけ提示する特別なセッションクッキーを適用することで実現できます。
- これを示すために、ALBセッション・クッキー・ベースのロードバランシングのために「internal」601サービスを設定しました。 601サービスはAzureネットワークの外からは直接アクセスできないため、flightPATHルールを使ってこのサービスにトラフィックを誘導している。
flightPATHルールは、リクエストされたパスを調べ、それが/601/であれば、ポート601で実行されているサービスにトラフィックを送る。 以下は、このflightPATHルールの詳細である。
このflightPATHルールは、トラフィックをパスに基づいてどのように別のサービスに送ることができるかを示すもので、トラフィック操作やコンテンツステアリングのための強力なツールである。
ポート601のVIPのコンフィギュレーションを見ることができる：
- では、パブリックIP「http://myurl/601/」に/601/のパスを追加してみてください。次のような結果が得られるはずです：
http://myurl/601/
ブラウザの開発者ツールをチェックすると、jnAccel=というクッキーが設定されていることがわかります。
パスの書き換えとRegExの評価
実際のサーバーは/601/ パスの下にコンテンツを持っていないので、リクエストからそれを削除する必要があった。
- これは、ポート:601で実行されているサービスに「Remove Path 601」という別のflightPATHルールを適用することで実現した。
ここでも、このルールを発動させる条件として、パス中の601を探す。
- この場合、既存のシステム変数（この場合、私たちが見たオリジナルのパス値）を操作することによって新しい変数を作成できるようにするために、正規表現を使用する評価関数を利用します。
そこで、先頭の/601/パス接頭辞の後のデータだけを抽出してNewPathを作成する。
アクション」は、$NewPath1$と $querystring$があればそれを使ってパスを書き換える。
HTML本文の置換
ポート:602を 使った他のサービスの例では、HTTPヘッダーだけでなく、HTMLコンテンツも操作できることを示している。
- 80番ポートに到着したトラフィックを602番サービスに誘導するパスを使う代わりに、クエリー文字列/? - "http://myurl/?602"
http://myurl/?602
ブラウザにテストドライブALB-XのパブリックIPアドレスを入力し、/?602を 追加すると、次のような結果が返されます。
オレンジ色のテキストが追加されている。
- "このテキストはflightPATHによって追加されました"
これは2つのflightPATHルールによって達成される。
port:80に適用される以下のルールは、602というクエリー文字列値を探し、ポート602で実行されているサービスにマッチするすべてのリクエストを送る。
ポート:602で実行されるサービスに適用されるflightPATHルールは、終了するボディタグを探す「Body Replace Last」機能を実行する。
</body>
に置き換える。
<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>
この場合、条件や評価は必要ないので、この関数はサービスを通過するすべてのトラフィックに適用される。
これらの機能を組み合わせることで、HTTPトラフィックを巧みに操作できることがお分かりいただけたと思うが、これらはflightPATHでできることの氷山の一角に過ぎない。
ぜひご自身の目でお確かめください。お客様の具体的なご要望をお聞かせいただければ幸いです。
リアルサーバーのヘルスチェック
次に取り上げるのは、実際のサーバーの健全性チェックだ。 クライアントのトラフィックが稼動しているサーバーにのみ送信されるようにするためには、バックエンドサーバーの健全性を確実に検出できるよう、適切なタイプの健全性チェックがサービスに適用されることが不可欠である。
新しいサービスを作成する際には、デフォルトのパラメーターセットを定義する必要がある。 サーバー監視には、TCP接続の健全性チェックを使用する。 サーバー監視オプションは、構成するサービスの基本タブにあります。
これは合理的な出発点ですが、より信頼性の高いヘルスチェックを設定し、サービスに適用することを強くお勧めします。
- ヘルスチェックは、「ライブラリ / リアルサーバーモニタ」の下にあります。
テストドライブでは、HTTPレスポンスのヘルスチェックの例を示すために、3つ目のリアルサーバーモニタを追加しました。
HTTP 200 OK 監視方法
200OKは、チェック用に設定されたページ・ロケーションへのHTTP GETリクエストを使用し、200OKステータス・レスポンスが返されることを確認します。
特定のコンテンツを探すのではなく、ウェブサーバーがそのポートで稼働していて、要求されたページを提供できるかどうかをチェックするだけだ。
- TCPコネクションは、レイヤ7でアプリケーションの実行をチェックするため、TCPコネクションよりも優れたモニターであるが、返されるコンテンツの特定のレスポンスをチェックするわけではない。
ポート:601で実行されているサービスに、このモニターを適用した。
HTTPレスポンス監視方法
テストドライブに設定された NLS モニターは、HTTP レスポンスチェックを使用します。
このために、特定のページの場所（ホストヘッダが必要な場合は完全なURL）を定義し、サーバー/アプリケーションから返されるデータに含まれるべきコンテンツ（テキスト文字列）を定義します。
これは、ページが存在し、特定のコンテンツが利用可能である必要があるため、はるかに優れたテストである。
- アプリケーションがバックエンドのデータベースをフロントにしている場合、健康状態をチェックしたページで取得したコンテンツのステータスを、ウェブフロントエンドサーバー上の静的コンテンツではなく、データベースからのライブレスポンスに依存するようにするのがよいでしょう。
このモニターをport:602で動いているサービスに適用していることがわかる。
このヘルスチェックの[必須コンテンツ]フィールドのテキストを変更すると、サーバーが赤くなり、ヘルスチェックに失敗したことが示されます。 必要な内容を正しい値に戻すと、サーバーは緑色のOKに戻る。
モニタリング間隔
詳細タブでは、そのサービスのヘルスチェック操作の頻度やタイムアウトなどを操作することができます。
テストドライブでは、モニター間隔を3秒、タイムアウトを2秒に設定した。
モニタリング・アウト・カウントは3に設定されているので、サーバーに到達不能とマークする前に、3つの連続した応答を得ることに失敗しなければならない。
- Monitor In Countが2の場合、サーバーをサービス再開にマークする前に、2回連続して応答が成功しなければならない。 これらの値は、ほとんどの場合に使用できる賢明な値である。
HTTPSとSSL証明書
ますます多くのウェブサイトがHTTPSを使用するようになり、2017年の初めには、その割合はHTTPSを支持する方向に振れていた。
ほとんどのエンタープライズアプリケーションは暗号化による保護を必要とするので、ALB-Xで証明書を使用する必要があることはかなり安全な賭けであり、HTTPSでロードバランサーをデプロイすることは、暗号化されていないアプリケーションへのアクセスを保護するための迅速かつ簡単な方法です。
- ALB-X にはデフォルトで「default」と呼ばれるプライベート証明書がインストールされており、管理 GUI への HTTPS 接続を許可するために使用される。 この証明書を仮想サービスまたはクライアント側の Test Drive:443 HTTPS 設定サービスに適用します。
このサービスはSSLオフロードに設定されているため、リアルサーバー側はSSLなしに設定されています。
証明書のアップロード/インポート
ライブラリセクションの SSL 証明書メニューを使用して、独自の署名付き証明書を ALB-X にアップロードできます。
テキスト入力フィールドで強調表示されているように、ALB-X にインポートする証明書は PKCS#12 形式である必要がある。
- このタイプの証明書には秘密鍵が含まれ、インポート時に必要となるパスワードで保護される。
インポート時に証明書に付ける名前（スペースを含んではならない）は、IPサービスBasicタブの証明書選択ドロップダウンに表示されるものになる。
リアルサーバー再暗号化
実サーバーがSSL/TLSの再暗号化を必要とする場合、最も賢明なオプションは、実サーバーSSL証明書のドロップダウンから「Any」を選択することです。
- つまり、ALB-Xは、実サーバが提示した証明書を有効なものとして受け入れる。
SNI（サーバー名表示）
パブリックIPアドレスの不足と、AzureではVIPを1つしか設定できないことから、1つの仮想サービスを通じて複数のセキュアなドメイン/ホストURLをサポートできることは有用であり、ALB-XではSNIをサポートしているため、これが可能です。
- SNI を使用するには、バーチャルサービス SSL 証明書のドロップダウンボックスから必要な証明書をすべて選択するだけです。 クリックするごとに、SNI リストの一部としての証明書の選択/非選択が切り替わる。
リアルサーバー側では、サービスが再暗号化され、共通のサーバー上でホストされる場合、正しいサービス識別とネゴシエーションのためにSNIが必要となるため、リアルサーバーSSL証明書のドロップダウンでSNIをオプションとして選択する必要がある。
認証
ALB-Xは、MS AD（Microsoft Active Directory）/LDAPサーバーと連携した事前認証に対応しています。
- 一般にアクセス可能なMS AD / LDAPサーバー（LDAPを使用）にアクセスできる場合は、この機能を自由に探索することができます。 ALB-Xのオンライン・ユーザーガイドでは、この機能の設定方法を説明しています。
この機能は、製造中止となったマイクロソフトのTMG製品の代替品として人気がある。
アプライアンスの使用状況と接続の監視
メニューのビューセクションでは、接続状況やサーバーの状態をリアルタイム（ステータス）または時系列（履歴）で確認することができます。
- W3Cやシステムのログもここにあります。 また、ダッシュボードに表示する独自のカスタムウィジェットを作成することもできます。 このセクションのさまざまなオプションをぜひご覧ください。
システム
ここには、時刻と日付の設定、電子メール・アラートの有効化、製品のライセンス、ログの記録方法と送信先の選択、アプライアンスの再起動と再起動の設定、SNMPの設定、他の管理ユーザーの追加など、システム機能に適用される設定オプションがあります。
上級
詳細メニューでは、設定のバックアップと復元、jetPACKテンプレートの設定のアップロードができます。
- 一般的なHTTPプロトコルの動作を変更したり、ソフトウェアのアップグレードを実行したり、クラウドライブラリから他のソフトウェアパッケージをダウンロードしたりすることができる。
最後にトラブルシューティングセクションがあり、バンドルされているサポートファイルパッケージのダウンロード、ネットワークPINGの実行、様々なシステムトレースやネットワークパケットキャプチャの実行が簡単にできるようになっています。
ありがとう。
- ALB-Xの試乗をお楽しみください。
pre-sales@edgenexus.ioへのご質問をお待ちしております。
Copyright © 2021 Edgenexus Limited.