4.2.3 【Azure】LANの管理
クライアントから実行サーバへの通信を実現するために，HAモニタは次の制御をします。
- OSでのエイリアスIPの追加・削除（DNS名制御の場合を除く）
-
マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「LANの管理」を参照してください。ただし，Azure環境下では次の点が異なります。
-
OSのarpingコマンドは実行不要※
-
エイリアスIPを割り当てるとき，ブロードキャストアドレスは指定不可
- 注※
-
Azureでの通信経路の制御によって，通信経路が定まるためです。
-
- Azureでの通信経路の制御
-
クライアントから実行サーバへ通信できるようにするために，HAモニタが業務通信経路の切り替えを制御します。次の表のとおり，クライアントからの通信方法によって，業務通信の切り替え方法を決定してください。
表4‒21 Azure環境下の業務通信の切り替え方法 クライアントからの通信方法
業務通信の切り替え方法
プライベートIPアドレスで通信する方法
Azure ロードバランサー制御による業務通信の切り替え
パブリックIPアドレスで通信する方法
DNS名で通信する方法
DNS名制御による業務通信の切り替え
次に，それぞれの通信経路の制御方式について説明します。
(1) Azure ロードバランサー制御による業務通信の切り替え
Azure ロードバランサー制御による業務通信の切り替えについて説明します。
Azure ロードバランサーには，関連づけた複数の仮想マシンにトラフィックを分散させる機能があります。Azure ロードバランサーは，特定のプロトコルおよびポートを使用して，一定時間ごとに仮想マシンの正常性確認を実行します。正常性確認に応答があった仮想マシンにトラフィックを転送し，応答がなかった仮想マシンにはトラフィックを転送しません。
HAモニタでは，実行系仮想マシンだけが正常性確認に応答するように制御することで，クライアントが実行サーバと通信できるようにします。
Azure ロードバランサー制御によって，業務通信を切り替える流れを次の図に示します。
|
|
![[図データ]](GRAPHICS/F0000024.GIF)
上記の図の系切り替え前は，仮想マシン2だけがAzure ロードバランサーからの正常性確認に応答します。そのため，仮想マシン2だけにトラフィックが転送されます。系切り替え後は，仮想マシン3だけがAzure ロードバランサーからの正常性確認に応答します。そのため，仮想マシン3だけにトラフィックが転送されます。
Azure ロードバランサー制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。
-
実行系仮想マシンで正常性確認を待ち受けるポートを閉塞する。
-
実行系仮想マシンのLinuxのループバックインターフェイスから，エイリアスIPアドレス（Azure ロードバランサーのIPアドレス）を削除する。
-
待機系仮想マシンのLinuxのループバックインターフェイスに，エイリアスIPアドレス（Azure ロードバランサーのIPアドレス）を付与する。
-
待機系仮想マシンで正常性確認を待ち受けるポートを開放する。
Azure ロードバランサー制御による業務通信の切り替えをするためには，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.13.5 【Azure】LANの状態設定ファイルの設定」を参照してください。
(2) DNS名制御による業務通信の切り替え
DNS名制御による業務通信の切り替えについて説明します。
Azure DNSに登録しているレコードを変更することによって，業務通信を切り替えます。このレコードには，DNS名と実行系仮想マシンのIPアドレスの対応が記載されています。
レコードの変更方法は，次のどちらかを選択してください。
-
レコードを更新する方法
-
レコードを削除したあとレコードを更新する方法
それぞれの方法の詳細について，次の表に示します。
|
方法 |
系切り替え元による処理 |
系切り替え先による処理 |
実行サーバ停止時のレコードの状態 |
実行サーバ停止時のクライアントからの通信 |
|---|---|---|---|---|
|
レコードを更新する方法 |
なし |
レコードの更新 |
残る |
サーバが停止しているときもレコードが残っているため，クライアントからのDNS名を使用した通信がインスタンスまで到達します。 |
|
レコードを削除したあとレコードを更新する方法 |
レコードの削除 |
レコードの更新（追加） |
残らない |
サーバが停止しているときは，クライアントからDNS名を使用した通信はインスタンスまで到達しません。 |
「レコードを更新する方法」より「レコードを削除したあとレコードを更新する方法」の方が，処理に時間が掛かります。そのため，「レコードを更新する方法」を推奨します。「実行サーバ停止時のクライアントからの通信」がシステム要件に合わない場合は，「レコードを削除したあとレコードを更新する方法」を選択してください。
それぞれの方法の処理の流れについて説明します。
- レコードを更新する方法
-
レコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。
図4‒14 レコードを更新する方法の動作例 ![[図データ]](GRAPHICS/F0000025.GIF)
図の例では，Azure DNSのDNSゾーンに，DNS名と仮想マシン2のIPアドレスとを対応させるレコードを登録します。これによって，クライアントから，DNS名を使用した通信ができます。系切り替え時は，このレコードを，DNS名と仮想マシン3のIPアドレスとを対応させるレコードに更新することによって，業務通信を切り替えます。
変更前のレコードの例を次に示します。
表4‒23 変更前のレコード（レコードを更新する方法） Name
Type
Value
TTL
備考
DNS名
（例：hitachi.co.jp）
DNSレコードタイプ
（例：A※）
実行系仮想マシン2のIPアドレス
（例：100.100.100.100）
キャッシュ生存期間
（例：60秒）
-
- （凡例）
-
-：特にありません。
- 注※
-
この例では，IPv4アドレスを記録するAレコードタイプを使用しています。
図中の仮想マシン2から，仮想マシン3に系切り替えをするときの動作を次に示します。番号は，図中の番号と対応しています。
-
新規のレコード追加を要求する。
新規（更新しようとしている内容）のレコード追加をAzure CLIで要求します。
-
新規のレコード追加を確認する。
新規（更新しようとしている内容）のレコード追加が完了したことをAzure CLIで確認します。
変更後のレコードの例を次に示します。
表4‒24 変更後のレコード（レコードを更新する方法） Name
Type
Value
TTL
備考
DNS名
（例：hitachi.co.jp）
DNSレコードタイプ
（例：A）
実行系仮想マシン3のIPアドレス
（例：200.200.200.200）
キャッシュ生存期間
（例：60秒）
更新
- レコードを削除したあとレコードを更新する方法
-
レコードを削除したあとレコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。
図4‒15 レコードを削除したあとレコードを更新する方法の動作例 ![[図データ]](GRAPHICS/F0000026.GIF)
変更前のレコードの例を次に示します。
表4‒25 変更前のレコード（レコードを削除したあとレコードを更新する方法） Name
Type
Value
TTL
備考
DNS名
（例：hitachi.co.jp）
DNSレコードタイプ
（例：A※）
実行系仮想マシン2のIPアドレス
（例：100.100.100.100）
キャッシュ生存期間
（例：60秒）
-
- （凡例）
-
-：特にありません。
- 注※
-
この例では，IPv4アドレスを記録するAレコードタイプを使用しています。
図中の仮想マシン2から，仮想マシン3に系切り替えをするときの動作を次に示します。番号は，図中の番号と対応しています。
-
レコードの削除をAzure CLIで要求する。
-
レコードの削除が完了したことをAzure CLIで確認する。
削除後のレコードの例を次に示します。
表4‒26 削除後のレコード（レコードを削除したあとレコードを更新する方法） Name
Type
Value
TTL
備考
（空白）
（空白）
（空白）
（空白）
削除
-
レコードの追加をAzure CLIで要求する。
-
レコードの追加が完了したことをAzure CLIで確認する。
変更後のレコードの例を次に示します。
表4‒27 変更後のレコード（レコードを削除したあとレコードを更新する方法） Name
Type
Value
TTL
備考
DNS名
（例：hitachi.co.jp）
DNSレコードタイプ
（例：A）
実行系仮想マシン3のIPアドレス
（例：200.200.200.200）
キャッシュ生存期間
（例：60秒）
更新
- 重要
-
-
これらの処理をするために，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.13.5 【Azure】LANの状態設定ファイルの設定」を参照してください。
-