DigiLoog

続きを読む »

トリガーアクション切り替えの為に作成したスクリプトは、記事の一番下にダウンロードリンクを張ったので、
スクリプトが目当ての人は内容を飛ばして記事の一番したを見るべし。

………

筆者のZabbix環境は、ZabbixServerが2台・ZabbixProxyが4台の計6台で動作している。
NW機器や通信経路が単一障害点にならない様にProxy毎の監視対象をグループを作りつつ、
監視対象が停止した際は設定に従いメールアラートを発砲させるオーソドックスな構成となる。

ZabbixServer間の設定自動同期は行わず、主系・副系に手動設定する事で各々が独立している。
APIを叩いて設定同期したりDBをダンプすれば完全冗長化出来るかもしれないが、
先にも書いた通り通信経路を主系・副系で分離したりしているので完全同期すると設定が複雑になる。
その為、メンテナンス負荷を犠牲にしつつも監視対象ホストは手動登録する様にしている。

冗長化方針は置いといて、Zabbix環境の設計思想はエンタープライズ環境や他の誤自宅も似ている筈。
ちなみに、ZabbixProxyを構えずにZabbixServer単体で動かしている人も多いと思うが、
グラフを大量に配置したスクリーンを表示するとWebサーバ等がメモリを大量に使い出す上、
サーバ負荷が結構かかるのでサーバは分離する事をオススメする。

………

今回の重要ポイントとなるトリガーアクションの切り替えスクリプトは次の通り。
前提として、ZabbixServerは2台がActive-Activeで動作しており、左の主系からのみアラート発砲させている。
右の副系サーバはアラート発砲を無効化しつつも、監視アイテムは有効化されていて監視を実行している。
この時、主系サーバがダウンすると副系サーバのみとなるので、アラート発砲が届かない状態になる。

この主系が落ちた時に副系からアラートが上がらない設計問題を解決する為、
副系から主系にZabbixプロセスの内部監視を行い、
プロセスが落ちている時は副系のトリガーアクションを有効化するスクリプト(api_zabbix_failover.pl)を作成した。

主系のZabbixプロセス停止を検知すると、副系のトリガーアクションステータスを切り替えるトリガーが発動し、
ステータスを切り替えるアクションスクリプトを実行する様にしている。
結果、スクリプトが副系のZabbix APIを叩いてアクショントリガーを有効にしてアラート発砲出来る様になる。

スクリプトを実行するメディアタイプは上の通り。
引数を与える事で有効化・無効化を切り替えつつ、対象範囲を全体・トリガー毎に変更して制御する。
引数はダブルクォーテーションで囲った状態で渡される為、スペースを含む時もそのまま書けば設定出来る。

………

主系が復旧した際は、副系のトリガーアクションを無効化する必要がある為、
発動時に使ったトリガーアクションに、復旧時の実行内容を追加して切り替えスクリプトを再実行する。

スクリプトで切り替える時のコツは、主系トリガーを常時ONにして副系のON・OFFで制御をする事。
このように片方のみ動かす事で、アラートの上がらないダウンタイムを最小限に出来るのと、
切り替え動作の設計が行いやすくなる。

………

サービス提供するサーバやNW機器を二重化するのは当たり前だが、監視サーバの二重化は忘れがちだと思う。
HinemosとかならHA機能があるので冗長化しやすいが、Zabbixは機能が無いので自力で組む必要がある。
とは言っても、Zabbix APIを叩けば管理画面の操作が大体出来るのでアイディア次第で作る事が出来る。
ググればAPIの叩き方は情報が出てくるので、やった事が無い人はコレを機に挑戦してみて欲しい。

---

トリガーアクション切り替えスクリプトのサンプル

トリガーとメディアタイプの設定方法はQiita辺りに図解もされているのでこの場は割愛。
今回作成したトリガーアクション切り替えスクリプトは次の処理に特化して作りました。
何が起きても利用者の自己責任を前提に、興味ある人はそのまま使ったり改造してみてください。

MD5:A6C05EF05A7719CC772A28BF95F9410E

実行方法はスクリプトに直接書いてあるヘルプを読めばわかる筈ですが、
基本的な実行方法とオプションの組み合わせは次の通りとなります。
例えば『Sample Action』という名前のトリガーアクションが存在する場合は次の通りとなります。

実行オプション	実行結果の説明
$ api_zabbix_failover.pl enable all	全てのトリガーアクションステータスを有効化
$ api_zabbix_failover.pl enable　”Sample Action”	Sample Actionのトリガーを有効化
$ api_zabbix_failover.pl disable all	全てのトリガーアクションステータスを無効化
$ api_zabbix_failover.pl disable “Sample Action”	Sample Actionのトリガーを無効化

スクリプトはPerlとShellコマンドの組み合わせで書いていますが、
モジュールは出来る限り使わない様にしているので大体のLinux環境で動作する様に設計しています。
スクリプト13～16行目の変数に、Zabbix APIのユーザ情報や接続先ZabbixServerのFQDNを設定し、
上記の様なコマンドを打ち込めばAPIを叩いて動きます。

« 続きを隠す

続きを読む »

元ネタは、IIJエンジニアブログで公開していた次の記事。
バリュードメイン利用時のDSレコード申請方法は、筆者の技術wikiに纏めてみた。

• IIJ Engineers Blog > やってみようDNSSEC
• nowsky system-lab memo > Knot

今回はお試しでDNSSECを触ってみたかったのと、粗探しの検証も兼ねているので、
構成はIIJのサンプルを流用して変に躓かないようにした。
ゾーン管理にはBIND、ゾーン署名にKnot、DNSクエリ処理にNSDを使う多段構成になっている。

最初はKnotを使わずに、スクリプトとansibleを組み合わせてゾーン署名の自作を考えていたのだが、
レコードを書き換えた時のロック処理や、署名の自動更新が複雑で実装が凄く面倒臭かったので諦めた。

………

今回一番躓いたのはDNSSECの仕組み把握する事。関連技術が多い上、文献も多く中々大変だった。
とは言っても、正しく把握しないと運用出来ないのでJPRS資料を片っ端から読んでなんとかした。
資料にも書かれていない細かい仕様があったりするが、
運用する上で必要な情報はゲット出来たので結果オーライだと思う。

ソフトウェア面ではKnotを使うのが初めてだったが、
1週間程度弄っていたらチューニングのコツは大体わかった。
DNSSECの実装範囲はソフトウェア毎に違うので、結果として弄るのが最善・最短となった。

という事で、DNSSECオプションを有効にしてDNS名前解決したのがこちら。
実際はもっと長いレコードが返ってくるのだが、画像が横にデカくなってしまうので割愛。
サンプルでは個別にAAAAレコードも指定しているが、ちゃんとRRSIGレコードが付与されている。

………

本来はメイン利用の権威DNSにもDNSSECを導入したいのだが、、
サーバをマルチマスターかつansibleでゾーン管理をしているのでサーバの改修が必要となった。
また、DNSSEC運用を間違えたら名前解決が全滅するので、いきなり適用するのは見送った。

検証ドメインを購入して何でも出来る様に、メイン利用のドメインと別に用意した訳なので、
暫くはこのまま検証ドメインで運用を続け、軌道に乗ったらメイン利用のドメインに反映しようと思う。
形は置いといてDNSSECの導入は出来たので、当初の目的は達成出来たとしてヨシとしよう。

« 続きを隠す

続きを読む »

NSDのビルド方法などはコチラ

“ns-lab BB”のインターネット向け権威DNSは、gdnsdを使ってグローバルロードバランサも兼任している。
また、DNSクエリログを解析する事でFW自動遮断をしているので、クエリログ取得も必須要件となる。
この課題を解決する為に、フロントエンドにdnsdistを使ってクエリログを取得しつつ、
グローバルロードバランサ用のサブドメインクエリのみgdnsdに曲げる設計となっている。

NSDはソースを改造しないとDNSクエリログを取得出来ないのだが、
同様にクエリログを取れない、gdnsd・dnsdist構成を作ってあったので問題を解決出来そうだった。

という事で、今回の権威DNS構成変更によって最終的に上の構成になった。

“ns-lab BB”のインターネット向け権威DNSは、
IPv4/IPv6でデュアルスタックにしつつ合計4台で負荷分散をしているのだが、
内部では2台1セットで運用しており、セット毎に稼働OSとkernelチューニングを変えている。

今回は2台1セットを維持しつつ、1セット内でBINDメインとNSDメインを用意した。
さらにバックエンドにNSDとBINDをバックアップとして構えておき、dnsdistで転送先を切り替えられる様にした。
この構成にする事で、BINDやNSDが脆弱性で落ちたとしても1～3秒程度で互いのバックアップに切り替わり、
権威DNS停止から来る名前解決待ちや正常系への再問い合わせ遅延が発生しにくくなった。
また、フォールバックする様にしておく事により、サーバメンテナンス時に正常系のバックエンドに切り替え、
サービス停止無しでメンテナンスを行える様になった。

………

独自ドメインを持っている大半の人は、レジストラや代理店が用意している権威DNSを使うと思う。
というのも、権威DNSが落ちるとサービスに繋がらなくなる上、メンテナンスと脆弱性対応が面倒なので、
自鯖を趣味としている人でも、権威DNSを自前運用してインターネット公開している人は少ない筈。
企業レベルでドメインを運用するなら、IaaS付属の権威DNSや権威DNS専用サービスを別途契約してしまい、
自前運用している所は相当減ってきている様に感じる。
さらに、権威DNSサーバの脱自前運用も叫ばれ「餅は餅屋」ならぬ「ドメインは権威DNS屋」も浸透してきた。

だとしても、ローカルなど閉じた環境では自前運用が必須となる上、相応の経験が必要となるのが事実。
先の通り、DNSが止まるとサービスが全滅する事もあり、可用性確保に躍起している運用担当も多いと思う。
だからこそ、何でも出来る自鯖で今回の様なトリッキー構成を試してみるのは今後も必要になるだろう。

« 続きを隠す