はじめに - DNS トラフィック管理
Oracle Cloud (OCI) のDNSに付随する機能に、トラフィック管理機能があります。トラフィック管理機能にはいくつかのステアリングポリシーの種類があり、様々なシーンで利用できそうです。
ステアリングポリシーの種類
今回はステアリングポリシーの１つ、フェイルオーバーを試してみます。
フェイルオーバー
フェイルオーバー・ポリシーでは、プライマリおよびセカンダリの順序優先(回答)を定義でき、OCIのヘルスチェックが、ポリシーのヘルス状態をチェックします。プライマリの回答が異常であると判断されると、トラフィックは自動的にセカンダリに渡されます。
通常(大阪のサーバーがヘルスチェックで正常時)はトラフィックは大阪のプライマリサーバーに送信されますが、ヘルスチェックによりプライマリサーバーが異常と判断された場合は、セカンダリのロンドンサーバーにトラッフィックが転送されるといったケースが想定されます。(下図)
フェイルオーバーの検証
それでは上図のケースを例にして、フェイルオーバーの検証をしていきます。
準備
異なるリージョン（大阪リージョン、ロンドンリージョン）にそれぞれコンピュートインスタンスを立てて、Webアプリを稼働させます。
- osaka01 - 大阪リージョンのインスタンス
- london01 - ロンドンリージョンのインスタンス
Webアプリはリクエストがあると、インスタンス名をブラウザに表示します。これにより、プライマリ／セカンダリのどちらにトラフィックが送信されたかを確認できます。
検証シナリオ
シンプルに次の２つの検証をおこないます。
-
プライマリ（osaka01サーバー）がヘルスチェックで異常と判断された時に、トラフィックはセカンダリ（london01サーバー）にフェイルオーバーされるか？
-
プライマリ（osaka01サーバー）が正常に復帰した時に、どのような動作になるか？
フェイル―オーバー設定
左上のナビゲーションメニューから[ネットワーキング]-[トラフィック管理ステアリング・ポリシー]を選択し、[トラフィック管理ステアリング・ポリシーの作成]をクリックします。
ポリシータイプ
トラフィック管理ステアリング・ポリシーの設定画面が表示されます。ポリシータイプから選択していきます。
[ポリシータイプ] フェイルオーバーを選択します。
[ポリシー名] 任意のポリシー名を入力します。
[ポリシーTTL] ステアリング・ポリシーからのレスポンスの存続時間。ここではデフォルトの60秒としてます。
回答プール
続いて、回答プールを設定します。
回答プール１：
[回答プール名] osaka とします。
回答：
[名前] osaka-web とします。
[タイプ] DNSレコードタイプを選択。ここではAレコードとしてます。
[RDATA] レコードタイプに応じたデータを入力。osaka01インスタンスのIPアドレスを入力します。
同様に、
回答プール２：
[回答プール名] london とします。
回答：
[名前] london-web とします。
[タイプ] DNSレコードタイプを選択。ここではAレコードとしてます。
[RDATA] レコードタイプに応じたデータを入力。london01インスタンスのIPアドレスを入力します。
プール優先度
先に定義したプールに対して、プール優先度でプライマリ、セカンダリを決めていきます。
osaka プールを優先度１（プライマリ）、london プールを優先度2（セカンダリ） で設定しました。
ヘルスチェック
ヘルスチェックを設定します。
新規追加 を選択し、
[ヘルスチェック名] DemoHealthCheck とします。
[間隔] デフォルトの30秒のまま。
[プロトコル] デフォルトのHTTPのまま。
アタッチ済みドメイン
[サブドメイン] app とします。
[コンパートメント] ご自身のコンパートメントを入力します。
[ゾーン] DNSゾーンを選択します。ゾーンはあらかじめ登録しておく必要があります。
この設定により、app.cocotaro.com へのリクエストは、プール優先度に応じて処理されます。
最後に、ポリシーの作成 をクリックします。
ポリシーが作成されると、
回答プールの優先度、各サーバーのヘルス・ステータスなどが表示されます。osaka, london サーバーは共に正常動作しています。
動作確認
1. osakaのサーバーが異常時に、トラフィックはlondonのサーバーへフェイルオーバーされるか？
1) 初期状態
ポリシー作成の直後は、osaka, london サーバー共に正常動作でした。
アタッチ済みドメインで定義した app.cocotaro.com でリクエストしてみます。プライマリのosaka サーバーで処理されてます。
2) osakaサーバーのWebアプリを停止
osaka サーバーのWebアプリを停止します。
しばらくしてヘルス・ステータスを確認します。osaka サーバーのヘルス・ステータスが異常に更新されています。
3) londonサーバーへのフェイルオーバ確認
app.cocotato.com でリクエストしてみます。london サーバーへフェイルオーバーされることが確認できました。
2. osakaのサーバーが正常に戻った時、トラフィックはosakaのサーバーへ戻るか？
1) osakaサーバーのWebアプリを再起動
osaka サーバーのWebアプリを再起動します。
2) ヘルス・ステータス
しばらくしてヘルス・ステータスを確認します。osaka サーバーのヘルス・ステータスが正常に戻りました。
3) osakaサーバーへのフェイルオーバー確認
osaka サーバーが復活して、通常の優先度の処理に戻りました。
まとめ
今回は、OCIの大阪リージョンとロンドンリージョン間でのフェイルオーバーを試してみました。国内の場合だと、東京リージョンと大阪リージョン間でもフェイルオーバーできるので、通常利用システム異常時のスタンバイ対策や、システムのサービスレベルの向上に役立てることが期待できそうです。
参考URL
Getting Started with Traffic Management
[Oracle Cloud] Traffic Management Steering Policies を使って、地球規模のフェールオーバーをやってみた