Azure Load Balancerと Azure Application Gateway のアクセスログを比較してみる

はじめに

くどうです。

Azureにはアクセスを負荷分散する方法として、Load BalancerとApplication Gatewayが用意されています。
しかし、それぞれレイヤー4とレイヤー7で挙動が異なりHTTPdへのアクセスログが異なります。
そこで、今回はアクセスログについて比較していきたいと思います。

用意した環境はCentOS上にApacheをデフォルトの状態(yum install httpd)したものです。

Load Balancer

実際にログを確認してみます。

Load Balancerからの死活監視(プローブ)は「Load Balancer Agent」と表示されます。
通常の外部からのアクセスもIPアドレスなども問題なく表示されています。

ただし、Load Balancerからの死活監視のログが邪魔ですね。
/etc/httpd/conf/httpd.conf を以下のように設定し排除します。

これで出力されなくなります。

Application Gateway

実際にログを確認してみます。

アクセス元は、すべてApplication Gatewayの内部アドレスになっていることが分かります。
これでは、アクセスログの解析には役立ちません。

これを解決する方法として、X-Forwarded-ForとX-Forwarded-Protoをログに残します。
これはAWS ELBとも同じです。

/etc/httpd/conf/httpd.conf を編集しています。

実際にログを確認してみます。

末尾の方でX-Forwarded-ForとX-Forwarded-Protoが取得できていることが確認できます。
これで問題なく解析が行えるかと思います。

まとめ

アクセスを負荷分散するLoad BalancerとApplication Gatewayですが、それぞれ出力されるアクセスログも異なるため気を付けましょう。
また、対処する方法も異なるので気を付けましょう。これらはAzureに限ったことではありません。
X-Forwarded-ForとX-Forwarded-Protoが利用されるケースが多いので覚えておくとよいと思います。

ではでは

Azure上のActive Directoryをディレクトリサービス復元モード(DSRM)で復元してみる。

はじめに

くどうです。

クラウド上でActive Directory(以下AD)を設計をする場合、復元方法についてよく議題に上がります。
特にADが論理障害起きた場合です。もう全部のADが死んで使えないときです。
実際は障害が起きないように冗長構成にして念入りに設計しましょう(w

もし障害が発生した場合どうするか、Azreu上でのADを、実際にバックアップを取得し復元するまでを説明していきます。
バックアップは普段からとっていることが前提ですが、復元には「ディレクトリサービス復元モード」で起動し作業を行います。

今回、対象にしているOSはWindows Server 2012 以降になります。
また、英語OSを利用しています。日本語でも変わりません。

バックアップ方法

バックアップにはWindows Server バックアップを使用します。
その為に、バックアップ先として別のディスクを指定する必要があります。

仮想マシンからディスクを追加します。
データディスクとしてマウントします。
adr01

次にディスクの管理を起動してフォーマットし、バックアップ先として利用できるようにします。
adr02

次にWindows Server バックアップを機能として追加します。

Windows Server バックアップを起動し、バックアップの設定を行います。
今回は、テストなので一回だけバックアップ取得するように設定します。
Backup Oneceでウィザードを起動します。
Diffrent opsionsを選択します。
adr03

Customを選択します。
adr04

Add Itemsを選択します。
adr05

System State(システムの状態)を選択します。
adr06

追加されたことを確認します。
adr07

Local Drivesを選択します。
adr08

マウントしたディスクを選択します。
adr09

確認画面がでます。Backupを開始します。
adr10

初期状態だとバックアップには30分もかからず終了します。
adr11

以上でバックアップは完了です。
実際にはスケジュールを設定し日々取得するように設定します。

復元してみる

ディレクトリサービス復元モードで起動し作業を行います。
ADを復元する場合はこのモードで作業を行います。

最初に、ADが復元されている確認するためバックアップと差分を付けます。確認用にUser1を作成しています。
adr12

msconfigを起動します。
adr13

Bootの項目でBoot Options > Safe bootにチェックを入れ、Active Directory repairを選択します。
adr14

Restartを求められます。再起動します。
adr15

再起動後、リモートデスクトップで接続しますがAD構築時に設定したパスワードになります。
また、ユーザー名はAdministratorになります。
adr16

ログイン後、四隅を見るとSafe Modeで起動したことを確認できます。
adr17

Windows Server バックアップを起動します。
Recorveryウィザードを起動します。

This serverを選択します。
adr18

復元するバックアップを選択します。
adr19

System stateを選択します。
adr20

Original locationを選択します。
Perform an authoritative restore of Active Drectory filesにチェックをいれます。
ここにチェックを入れることで権限のある復元となります。
adr21

注意書きがでます。
adr22

確認画面がでます。
adr23

始めたらやめられない止まらないって警告がでます。
adr24

復元途中の経過が表示されます。初期状態だと、だいたい20分程度で完了しました。
adr25

完了後、Restartボタンがでますがこのまま再起動すると、再度Safe Modeで起動するためブートの設定を変更します。
adr26

msconfigを起動します。
adr27

Safe Bootのチェックを外します。
adr28

再起動を求められますが、Exit without restartを選択します。
adr29

復元完了の画面で出てきたRestartボタンをクリックし再起動します。

再起動は、もともとのユーザーでログインします。
adr30

ログイン後、復元完了しましたと出ますENTERを入力しすすめます。
adr31

User1がいなくなっていることを確認します。
adr32

バックアップした時点に復元されていることが確認できました。

おわりに

ディレクトリサービス復元モードを利用することのないよう設計してください。ただし、運用設計をする場合は必ず必要となります。一度は試して見た方が良いとおもいます。
今回は、Azureで行っていますが。AWSでも同じ方法で復元が行えます。ただし、AWSではネットワークドライバによっては対応していないため確認しましょう。

ではでは

仮想マシンの構成がダイアグラムで確認できます。

ダイアグラムで表示

くどうです。

いつの間にか、仮想マシンがダイアグラムで表示できるようになっていました。
デプロイ後、モニタリングを確認するとダイアグラムの項目があります。
diag01

開くと仮想マシンの構成が確認できます。
確認したい項目を開くと、直接その機能へ飛びます。
あとは、注意事項が表示されます。
diag02

今後は、各サービスでも表示できるようになるのだろうか。
そうなればとても便利!

ではでは