Juniper機器におけるrpm、event-option機能と、以前に解説したinet filterを組み合わせてサーバ冗長構成を実現させたことがありました。
今回は、その設定例を紹介、解説します。
今回解説する構成
今回解説する構成はProxyサーバの冗長構成となります。具体的な想定ネットワーク構成は、以下の構成図をご確認ください。
昨今ではサーバ側の機能、あるいはサーバ側の環境をハイパーバイザーなどを用いた仮想環境上に構築することなどで冗長性を実現する方法もありますが、今回はそういった構成が利用できず、ネットワーク機器側の設定で実現する必要があるケースとなります。
RPM機能について
RPM機能は、指定する対象についてテスト用通信を送信して情報を収集するための機能です。今回はping疎通監視を目的とした設定例を紹介します。
set services rpm probe "プローブ名" test "テスト名" probe-type icmp-ping
set services rpm probe "プローブ名" test "テスト名" target address "サーバIPアドレス"
set services rpm probe "プローブ名" test "テスト名" probe-count 4
set services rpm probe "プローブ名" test "テスト名" probe-interval 40
set services rpm probe "プローブ名" test "テスト名" test-interval 160
set services rpm probe "プローブ名" test "テスト名" routing-instance "インスタンス名”
set services rpm probe "プローブ名" test "テスト名" thresholds total-loss 4
1行目はテスト用通信がICMP(ping)であることを指定する行です。
2行目が対象を指定する行です、今回の構成ではProxyサーバ(Active)が対象になります。
3~5行目はテスト用通信がどのような間隔や回数で行うかを指定する行です。5行目で指定する160秒間ごとにテストが開始され、4行目の指定の40秒間ごとに、3行目の指定の4回pingが送信されます。これらをまとめると常に40秒ごとにpingのテスト通信が行われる状態になります。
6行目はテスト用通信をどの仮想ルータから行うかを指定する行です。
7行目は何度通信に失敗した場合にテスト通信の失敗として検知するかを指定する行です。今回は4回で指定しているので、3~5行目で設定した1セット分が全て失敗した場合にテスト通信の失敗として検知します。
event-option機能について
続いてevent-option機能について解説します。
これは"特定の状況"が発生した際に、それをトリガーとして各種動作を行わせることが可能な機能です。この"特定の状況"として指定することになるのが、先に解説したRPM機能で設定、用意したものになります。
今回は"サーバへの疎通監視が失敗"、"サーバへの疎通監視が復旧"をトリガーとして"Backup側のサーバに通信を切り替える"、"Active側のサーバに通信を切り戻す"という構成例での設定行を紹介します。
トリガー条件の設定部分
"サーバへの疎通監視が失敗"、"サーバへの疎通監視が復旧"をトリガーとするための設定行を解説します。
サーバへの疎通監視が失敗した場合
set event-options policy "ポリシー名_act" events "イベント名"
set event-options policy "ポリシー名_act" within 60 trigger on
set event-options policy "ポリシー名_act" within 60 trigger 1
set event-options policy "ポリシー名_act" attributes-match ping_test_failed.test-name matches "テスト名"
set event-options policy "ポリシー名_act" attributes-match ping_test_failed.test-owner matches "プローブ名"
1行目は名称定義を行っている設定行になります。
4, 5行目で先程設定したRPMを指定しており、かつ設定行中に"ping_test_failed"とあるようにテスト通信の失敗時を条件として指定しています。
2, 3行目はトリガー条件が満たされた場合にevent-option機能を動作させる時間的な制限を設定しており、今回の場合は60秒間に1回までと設定しています。
今回の設定例では、"Active/Backup側サーバへ通信を切り替える"動作をConfigを書き換えることで実現させるため、ping疎通監視の失敗/復旧が短時間に繰り返し発生してしまった場合に都度動作させてしまっては機器の負荷などに問題が出る可能性があるため、それを予防する目的でこの値を採用して設定しています。
サーバへの疎通監視が復旧した場合
set event-options policy "ポリシー名_bkup" events "イベント名"
set event-options policy "ポリシー名_bkup" within 60 trigger on
set event-options policy "ポリシー名_bkup" within 60 trigger 1
set event-options policy "ポリシー名_bkup" attributes-match ping_test_completed.test-name matches "テスト名"
set event-options policy "ポリシー名_bkup" attributes-match ping_test_completed.test-owner matches プローブ名"
設定の構成はサーバへの疎通監視が失敗した場合と同様です。
4, 5行目でも同様に先程設定したRPMを指定しており、こちらは設定行中に"ping_test_completed"とあるようにテスト通信の成功時を条件として指定しています。
トリガー発生時の動作設定部分
次に、上記の条件が満たされた場合にどういった動作をさせるかの設定です。
サーバへの疎通監視が失敗した場合
set event-options policy "ポリシー名_act" then change-configuration commands "set firewall family inet filter "フィルター名" then next-ip "Backup側サーバIPアドレス""
set event-options policy "ポリシー名_act" then change-configuration commands "activate event-options policy "ポリシー名_bkup""
set event-options policy "ポリシー名_act" then change-configuration commands "deactivate event-options policy "ポリシー名_act""
set event-options policy "ポリシー名_act" then change-configuration commit-options log "ProxyServer_act Down."
1行目がConfigを書き換える設定行で、内容はinet filter設定行の内のnext-hopを指定する行をBackup側のサーバ宛てに書き換えるというものです。
やや分かり難いですが、"set firewall family inet filter ”フィルター名" then next-ip ”Backup側サーバIPアドレス”"の" "内の記述は、通常のConfig変更時に投入するConfig行と同じ記述になります。ただし、このevent-optionの設定行では" "の中の記述はcommit checkで構文確認はされません。そのため、Configを正常に書き換えることができない記述がされていてもcommitが通ってしまいます。
2~3行目もConfigを書き換える設定行で、activate/deactivateという投入Config行を使って、書かれているConfigの有効/無効を切り替えます。activateで投入するとConfig表示に該当行は表示されず、通常の設定Configどおりに各Configは機能します。deactivateで投入するとConfig表示にも該当行は表示され、該当階層以降のConfig、今回の設定例では"ポリシー名_act"として設定されているConfig全体が機能しなくなります。
つまり、2行目がサーバへの疎通監視が失敗した場合のevent-option設定を有効化する内容、3行目が自身であるサーバへの疎通監視が失敗した場合のevent-option設定を無効化する内容です。これによって検知させたいトリガー条件を切り替えて誤動作を予防しています。
4行目はこのevent-option機能にて設定変更が実施された場合に、commitログに情報を残すための設定行です。必須の設定行ではありませんが、event-optionが想定どおりに動作したかやConfigが書き換えられた時刻が確認しやすくなるため、設定しておくことを推奨します。
サーバへの疎通監視が復旧した場合
set event-options policy "ポリシー名_bkup" then change-configuration commands "set firewall family inet filter "フィルター名" then next-ip "Active側サーバIPアドレス""
set event-options policy "ポリシー名_bkup" then change-configuration commands "activate event-options policy "ポリシー名_act""
set event-options policy "ポリシー名_bkup" then change-configuration commands "deactivate event-options policy "ポリシー名_bkup""
set event-options policy "ポリシー名_bkup" then change-configuration commit-options log "ProxyServer_act Up."
deactivate event-options policy "ポリシー名_bkup"
サーバへの疎通監視が失敗した場合と同様の構成です。
異なる部分としては、当たり前ですが指定するサーバIPアドレスやevent-option設定の有効化、無効化の組み合わせがサーバへの疎通監視が失敗した場合とは逆になっていることです。
また、こちらのevent-option設定はProxyサーバ(Active)が正常な間は検知や実行される必要のないものですので、5行目としてdeactivateの設定行があり、普段は無効化された状態の設定Configとします。
inet filterの設定
inet filterの設定方法は以前のinet filterとbridge filterの設定行の記事で解説済みですが、今回の構成に対応した設定だとどういった設定行になっているのかを紹介します。
今回は全ての通信をProxyサーバ経由とさせる設定になります。以前の記事を参考にfilter処理の対象条件を設定する行を追加すれば、その対象の通信だけをProxyサーバ経由とするといった構成も実現可能です。
set firewall family inet filter "フィルター名" then next-ip "Active側サーバIPアドレス"
set firewall family inet filter "フィルター名" then next-ip routing-instance "インスタンス名"
上記configの1行目をevent-option機能にて、Ping疎通監視に失敗した場合にはBackup側サーバIP、Ping疎通監視が復旧した場合にはActive側サーバIPと書き換えることで冗長構成を実現させています。
今回の設定構成による冗長構成の実現について
設定解説のために、具体的な例としてProxyサーバの冗長構成を挙げて紹介させていただきましたが、event-option機能ではトリガー条件が満たされた場合にconfigを書き換えるという動作が可能なため、今回紹介したinet filterのnext-hop指定行だけでなく様々な設定を変更させることが可能です。
途中で説明したように" "内の記述はcommit check時に構文確認されないため、本当に正しいConfig行となっているかの検証・確認が大事ですし、また利用しすぎるとConfig内容が複雑化して引継ぎや更改時のコストに問題が出る可能性もありますが、ユーザ側からの要望への実現可否やリスクなどの説明のために、Juniper機器におけるevent-optionの機能はその存在を覚えておく必要のあるものだと思います。
廣瀬 翔也（日本ビジネスシステムズ株式会社）
クラウドソリューション事業本部 セキュリティ＆ネットワークインテグレーション2部 所属 主な業務経験範囲はネットワーク分野。 備忘録も兼ねて”ユーザ要望を実現するためのコンフィグ設計例”を掲載していく予定です。
担当記事一覧