Traffic Managerの動作確認
ここからは配置したサンプルプログラムを元に、Traffic Managerの動作を確認していきます。Traffic Managerの管理ポータルを確認してみましょう。図14のように、「ポーリングの状態」カラムがすべて「オンライン」になっていれば正しく動作しています。ポーリングの状態とは、Traffic Managerが監視用エンドポイントにアクセスし、サービスが正常に動作しているか判定した結果です。
ラウンドロビン
最初に作成したポリシーでは、ロードバランス方式としてラウンドロビンを選択しましたが、Traffic Manager向けのURLにアクセスしてみます。最初に東アジアが表示されます。引き続き、新規セッションから新しいIEを起動し、URLを入力してみてください。ラウンドロビンの動作どおり、順に異なるホステッドサービスが選択されることが確認できると思います。
![図15 ラウンドロビン方式の結果](http://cz-cdn.shoeisha.jp/static/images/article/6124/6124_slide09.gif)
なお、ラウンドロビン方式では、ブラウザ自身や、ProxyサーバーがDNSキャッシュを持っている場合があるため、期待通りの動作をしない場合があります。そのような場合は、何度か繰り返しアクセスしてみてください。
次にnslookupを繰り返し、どのようなDNS名が返却されるか確認してみます。ポリシーに設定したホステッドサービスのDNS名が順に返却されることが確認できるでしょう(図16)。なお、nslookupを繰り返す場合、DNSのキャッシュが効いているため、30秒程度おいてから確認してください。
パフォーマンス
ロードバランス方式をパフォーマンスに変更して動作を確認してみましょう。リボンの[構成]ボタンをクリックするとポリシーの編集ダイアログが表示されるため、ロードバランス方式から[パフォーマンス]を選択し、[更新]ボタンをクリックします。
しばらくしてから、Traffic ManagerのURLにアクセスを繰り返すと、東アジアのホステッドサービスにしか接続されなくなます。ただし、利用しているプロバイダーによっては、北中央アメリカのほうが近いと判定される場合もありますが、常に同じホステッドサービスに接続されることを確認してください。
ここで、北中央アメリカのホステッドサービスに接続されることを確認するために、北中央アメリカに配置したサービスにリモートデスクトップ接続して、その中から動作確認してみます。北中央アメリカのサービスからTraffic Managerを経由すれば一番近い自分自身に接続されることが確認できます(図18)。
フェールオーバー
最後にロードバランス方式をフェールオーバーに変更して動作を確認してみましょう。リボンの[構成]ボタンをクリックするとポリシーの編集ダイアログが表示されるため、ロードバランス方式から[フェールオーバー]を選択し、[更新]ボタンをクリックします。
フェールオーバーの動作を確認するためには、片方のサービスを停止する必要があります。今回は東アジアのホステッドサービスを停止してもよいのですが、リモートデスクトップ接続で乗り込んでエンドポイントファイルをリネームしてみます。このようにすることで、Traffic Managerからは東アジアのホステッドサービスが停止しているように見えるからです。
東アジアのホステッドサービスにリモードデスクトップ接続し、“E\siteroot\0\endpoint.htm”ファイルをリネームします。しばらくすると、東アジアのホステッドサービスがオフラインになるのが確認できます(図19)。
オフラインになったのを確認したのちに、Traffic ManagerのURLへアクセスしてみます。北中央アメリカのサービスが表示されることが確認できると思います。
まとめ
サンプルによって各ロードバランス方式の確認はできたでしょうか。これら、パフォーマンス、ラウンドロビン、フェールオーバーなど各種トラフィック制御を行ってくれるTraffic Managerですが、あくまでDNSをベースとした振り分けです。トラフィック制御をした場合に、異なるホステッドサービス間でどのようにデータを共有するか、またフェールオーバー時にどのようにデータを引き継ぐかなどは、アプリケーション側の問題となります。
情報提供サイト等ステートレスなサイトであれば問題になりませんが、永続的なデータを扱うサービスでは、これらに注意が必要です。ただし設計次第では高可用性、耐障害性を高めることができる機能であるといえるでしょう。