機器監視のためのZabbixを、DB含めてL3冗長化した話-1-janog54-koyama-20240704

マスター タイトルの 機器監視のためのZabbixを、 書式設定 DB含めてL3冗長化した話 〇小山 拓海 今井 宏謙

本日の目次 • 結論 • 監視ツールZabbixとは • L3冗長化に至った背景 • 要件定義 • POC（導入前テスト） • 構築 • 今後のお話（移行設計） • 議論ポイント・質疑応答 2

自己紹介(小山) • 小山 拓海 • 株式会社Jストリーム • ネットワークインフラ部 ネットワークインフラ課 2018年、株式会社Jストリームに入社 • 業務内容 • 基盤ネットワーク・サーバインフラの設計・構築 • JANOG現地初参加、初登壇です。 • 業界のつながりを広げたく参加致しました。 • 名刺いっぱい持ってきました。ぜひ交換してください。 • 懇親会も参加します。 3

J-Streamについて www.stream.co.jp 動画配信 サービス 株式会社Ｊストリーム(AS24253) Ｊストリームは1997年の設立以来、動画配信を主軸として事業展開を続けております。 自社で保有･運営する独自のコンテンツ配信ネットワーク（CDN）を活用した動画配信に加え、 これまで積み上げてきたノウハウを活かした動画の企画・制作・運用から、Webサイト制作、 システム開発、動画広告による収益化支援まで、総合的なサービスとソリューションを提供し、 企業のマーケティングやコンテンツビジネスなどを支援しております。 設立 運用 サポート 1997年5月 証券コード 4308（東京証券取引所 グロース市場） コンテンツ配信 ネットワーク （CDN） 制作( Web/ 映像 )・ 開発 本社：105-0014 東京都港区芝二丁目5-6 芝256スクエアビル6階 西日本オフィス：530-0003 大阪府大阪市北区堂島2-4-27 JRE堂島タワー5階 資本金 21億8,237万円 （2023年12月末現在） © J-Stream Inc. All Rights Reserved. 4

• https://www.stream.co.jp/contact/contact-32226/

結論 • 今年の6月にリリースされたZabbix7.0で監視環境を構築 • データセンター冗長(L3で冗長)構成を実現 • ネットワーク • Webサーバ • データベース 5

Zabbixとは • オープンソースのインフラ監視ツール • 機器の死活監視やリソース監視を行い、異常があればアラートの発砲を行う 死活監視・リソース監視 異常を検知したら メール等で検知 配信サーバ等 6

L3冗長化に至った背景（旧監視サーバ構成） 7

L3冗長化に至った背景（課題） • データセンター冗長ができていない • 上位NW機器のメンテナンスや障害時に全断 • 結果、Zabbixへのアクセスができず、アラートの受信に気付けないことも…。 • クラスタの切り替えに時間がかかる • ミドルウェアの停止・起動に約5分以上かかることも… • Timeoutで切り替わらない場合もあった 8

L3冗長化に至った背景(プロジェクト発足) • 2023年4月よりプロジェクト発足。 • 弊社のZabbixサーバがハードウェア・OSともにEOLのため、リプレース計画を開始 • 弊社はDCを跨いで動画配信・CDNを展開しており、サービスでは複数のDC冗長を行っ ている。 • 既存のZabbixサーバは同一拠点内での冗長である。 ⇒リプレースにあわせて拠点を跨いだ冗長を構築 9

要件定義 耐障害性を備えたいよね • 1台のサーバの故障 耐障害性を備えたいよね • 1台のサーバの故障 • 1拠点のネットワーク • サービス回線の断 Zabbixは継続的に閲覧したい L3冗長化しよう！ 10

POC（導入前テスト） • 要件定義と同時並行で、どのような構成が取れるかPOCを行った • コストや導入のしやすさの観点から検討した 11

パターン1 StandAlone x 2 • 各拠点でzabbixサーバをStandAloneで立てる構成 • 特徴 • 構築が簡単 • 障害時のフェイルオーバが考慮不要 • 以下の理由で採用を見送り • 管理コストが倍かかる • 監視データやアラートが重複 Internet ロードバランサ 拠点A 拠点B Web Server DB Server 12

パターン2 Active-Active構成 • Zabbix社公式のコンフィグ同期ツールを使用する Internet • 特徴 • Zabbix社公式のサポートを受けられる • 以下の理由で採用を見送り • 弊社はDCを複数拠点抱えていたため、 コストがかかりがち （拠点数分の費用での見積もりが多く、 導入の見送り） ロードバランサ 拠点B 拠点A Web Server Zabbix公式 バックアップ同期 ツール DB Server 13

パターン3 Active-Standby構成（Pacemaker） • Pacemaker等のクラスタツールを使用 • 特徴 Internet • 過去と同じ構成が取れる • 以下の理由で採用を見送り • そもそもVIPが付けれないので、 DBの向き先を片方にしか寄せられなかった • 障害時には手動で切り替えが発生 ロードバランサ 拠点B 拠点A Web Server • 自動でフェールオーバーしてくれない VIP DB Server 14

パターン3 Active-Standby構成（Pacemaker） • Pacemaker等のクラスタツールを使用 • 特徴 Internet • 過去と同じ構成が取れる • 以下の理由で採用を見送り • そもそもVIPが付けれないので、 DBの向き先を片方にしか寄せられなかった • 障害時には手動で切り替えが発生 ロードバランサ 拠点A 拠点B Web Server • 自動でフェールオーバーしてくれない DB Server 15

パターン4 クラウド • クラウドに移行する案も検討した • 特徴 Internet • 冗長性はクラウド上で担保、冗長性を考える必要がない • 以下の理由で採用を見送り • クラウドもコストがかかる ▪ やはり実機を触りたい ▪ オンプレは触ってる感ある Web Server DB Server 16

パターン5 Active-Standby (Zabbix-HA) • パターン3を拡張 • VIPの問題があるのであれば、VIPをなくせばよい。 • 実現方法を考えてみた。 拠点A Internet ロードバランサ 拠点B Web Server DB Server 17

ここからは今井にバトンタッチします 18

構築を終えて（小山） • 基本設計が一番印象的だった • 一からシステムをきれいにすることができた • 自分がわかるシステムができた • 障害になったら自己責任、でも自分で作ったからわかる • 引継ぎ資料もちゃんとある • 悩んだこと • 時間との闘い • プロジェクトを期限までに終わらせる焦り、ハードウェア、OSのEOLも見えている • 構築への不安 • 仕様の変更(MySQL⇒PostgreSQLへの変更) • 珍しい構成 19

監視の移行頑張ってます • MySQL→PostgreSQLに設計を変更 • DBリストアでデータ移行ができなくなりました • 監視対象は900弱 • 責任分界点の策定 • IaaS（NW機器、OS）までを自部門、PaaS以上は、他部門の担当。 • 監視項目のブラックボックス化を回避 • Zabbix7.0によるもろもろの変更 • Zabbixエージェント7.0へアップデート • Zabbixプロキシも7.0で新規構築（OSのEOLのため） • コンフィグファイルの設定変更 20

議論ポイント • 監視ツールは何使ってますか • 監視の冗長化、監視のサービスレベルどんな感じですか • オンプレ環境で監視システムを稼働させていますか？（コンテナ？クラウド？） • 監視ホストの登録の方法 • 監視項目として何を取得していますか • 監視アラートがなった時の通知方法 • 資産管理情報ツールと監視ツールの紐づけ • その他監視についてなんでもお話したいです。 • 皆さんの苦労話とかお聞きしたいです。 21