大規模分散ストレージシステムであるCephは、クラウドインフラの中核コンポーネントとして定着しました。特にOSD (Object Storage Daemon) は、Cephクラスターのデータを実際に保存・管理する重要なデーモンであり、OSDの安定性はクラスター全体の安定性に直結します。OSD障害は予測困難な瞬間に発生し、特に同時多発的な障害はサービス停止につながる深刻なリスクを内包します。
シナリオ紹介
私たちが運用するクラウドインフラ環境では、Ceph Luminousベースの分散ブロックストレージプラットフォームに、140個のOSDが7つの専用ストレージノードに分散配置されています。このクラスターは高性能SSDプールと大容量HDDプールで構成されており、ミッションクリティカルなプロダクションワークロードのストレージ要件を満たしています。私たちの最優先目標は、システムの可用性と性能SLO (Service Level Objective) を極限まで維持することです。
最近、重要なインシデントが発生しました。特定のストレージノードstorage004で4つのSSDと1つのHDDが相次いで障害を起こし、合計5つのOSDがダウンしクラスターから除外 (down/out) される状況が発生しました。さらに悪いことに、他のノードstorage001とstorage002でもそれぞれ1つ、2つのHDD OSDが障害を起こし、全140個のOSDのうち合計8個のOSDがdown/out状態となりました。これにより、SSDプールでは15.13 TiBの有効容量が失われました。幸いCRUSH mapの設計とデータ複製戦略のおかげでデータ損失はありませんでしたが、この経験はOSD障害に対する事前検知と迅速な対応の重要性を改めて認識させるきっかけとなりました。
課題
このような大規模なCephクラスター環境でOSD障害を効果的に管理することは、以下の複合的な課題を伴います。
- 規模と複雑性：140個に及ぶOSDを手動で監視することは不可能であり、リアルタイムですべてのOSDの状態と性能を追跡できる自動化されたシステムが不可欠です。
- サイレント障害 (Silent Failures)：OSDプロセスの完全な停止ではなく、性能低下 (slow OSD) や断続的な応答遅延のような微妙な障害は、既存の単純な「UP/DOWN」監視では検知が困難です。このようなサイレント障害は、サービス性能に長期的に負の影響を与える可能性があります。
- アラート疲労度 (Alert Fatigue)：過度に敏感なアラートは、SREチームのアラート疲労度を高め、実際に重要な障害信号を見逃す可能性があります。逆に、アラートが少なすぎると、潜在的な障害が実際のサービス停止につながるまで認識できない状況が発生します。
- 運用負担：障害発生時に手動で問題を診断し復旧するプロセスは、多くの時間と労力を消費し、他の重要なエンジニアリング作業に集中できなくさせます。
- データ耐久性 (Durability) と可用性 (Availability) のトレードオフ：
min_size=1のような設定は可用性を高めることに貢献しますが、同時にデータ損失のリスクを増加させるトレードオフを伴います。これを理解し、適切に管理することが重要です。
既存の監視システムは、基本的なceph healthの状態確認に依存していましたが、OSD個別レベルの性能指標や潜在的な性能低下の兆候を事前に検知するには限界がありました。
技術選択プロセス
これらの課題を解決し、Cephクラスターの安定性を最大化するために、私たちは以下の基準に基づいて新しい監視ソリューションを模索しました。
- リアルタイムかつ高度なメトリック収集：各OSDの状態、性能 (レイテンシ)、PG (Placement Group) の状態など、詳細なメトリックをリアルタイムで収集・分析できる必要があります。
- 強力なクエリおよび可視化機能：収集されたメトリックを自由にクエリし、意味のあるダッシュボードで可視化することで、クラスター全体の状態を直感的に把握できる必要があります。
- 柔軟で拡張可能なアラートシステム：特定の閾値超過またはパターン検出時にSREチームに迅速かつ正確にアラートを送信できる必要があり、様々なアラートチャネル (Slack, PagerDutyなど) と連携できる必要があります。
- 既存のObservabilityスタックとの統合容易性：すでに構築されている監視およびロギングインフラストラクチャと自然に統合できる必要があります。
これらの要件に基づいて、いくつかの候補技術を比較分析しました。
| 技術/ソリューション | 長所 | 短所 | 適合性 |
|---|---|---|---|
| Ceph Dashboard | Cephクラスターの基本状態を一目で把握。 | 高度なクエリおよびカスタムアラート設定の限界、ヒストリカルデータ分析機能の不足。 | 全体的な状態把握には良いが、詳細な監視およびアラートには不適。 |
| ELK Stack | ログ集計および検索に強み、大規模データ処理が可能。 | 時系列メトリック処理およびPromQLのような強力なクエリ言語の不在。 | 主にログ分析に特化しており、メトリックベースのリアルタイム監視には追加の労力が必要。 |
| Prometheus + Grafana | 時系列データに最適化された設計、強力なPromQL、豊富なExporterエコシステム、Alertmanagerによる柔軟なアラート。 | 大規模クラスターの長期データ保存時にリソース管理が必要。 | 精密なメトリックベース監視、リアルタイムアラート、カスタムダッシュボード構築に最適。 |
総合的な比較の結果、PrometheusとGrafanaの組み合わせは、リアルタイムメトリック収集と分析、強力なクエリ言語、そしてAlertmanagerを介した精巧なアラートシステムという点で、私たちの要件に最も合致するソリューションとして決定されました。特に、SREの観点からSLO/SLIを精密に定義し、監視できる柔軟性は、このソリューションの核となる選択基準でした。
実装プロセス
1. Ceph ExporterのデプロイとPrometheus統合
CephクラスターのメトリックをPrometheusが収集できるようにceph-exporterをデプロイすることが最初のステップです。私たちは各Ceph Manager (Mgr) ノードにceph-exporterをデプロイし、クラスターの状態とOSDごとのメトリックを収集するよう構成しました。これにより、監視対象のCephクラスターに最小限のオーバーヘッドを与えながらも、安定したメトリック収集が可能になります。
# prometheus.yml 設定例
scrape_configs:
- job_name: 'ceph'
static_configs:
- targets:
- 'ceph-mgr01:9283' # Ceph Mgr ノードにデプロイされた ceph-exporter エンドポイント
- 'ceph-mgr02:9283'
# ... 他の Mgr ノード
relabel_configs:
- source_labels: [__address__]
regex: '(.*):9283'
target_label: instance
replacement: '$1'
この設定は、ceph-exporterが公開するHTTPエンドポイントからメトリックを定期的にスクレイピング (scrape) するようPrometheusに指示します。収集されたメトリックはPrometheusの時系列データベースに保存され、クエリおよびアラートに活用されます。
2. 主要OSDメトリックに基づく監視設計
Ceph OSDの健全性とその性能を正確に把握するためには、以下の主要なPrometheusメトリックを中心に監視を設計する必要があります。
ceph_osd_up：OSDデーモンが現在実行中であるかを示す指標です。0はdown、1はupを意味します。ceph_osd_in：OSDが現在Cephクラスターに参加し、データをサービングしているかを示す指標です。0はout、1はinを意味します。OSDがup状態であってもin状態ではない場合、復旧作業中であるか、手動で除外された状況である可能性があります。ceph_osd_apply_latency_ms：OSDがクライアントの書き込み要求をジャーナルまたはデータディスクに適用するのにかかる時間 (ミリ秒) です。この指標が異常に高い場合、OSDのディスクI/O性能問題またはシステム負荷を疑うことができます。ceph_osd_commit_latency_ms：OSDが書き込み要求をすべてのレプリカにコミットし、クライアントに応答するまでにかかる時間 (ミリ秒) です。この指標はネットワーク遅延や他のOSDの性能問題と関連する可能性があります。ceph_pg_degraded：CephのPlacement Groupのうち、degraded状態にあるPGの数です。PGがdegraded状態であるということは、設定されたレプリカ数よりも少ない数のOSDにデータが保存されていることを意味し、データ損失のリスクが増加していることを示します。ceph_health_status：Cephクラスター全体の健全性状態を示します。0はOK、1はWARNING、2はERRORを意味します。
この他にも、ceph_osd_op_r_bytes、ceph_osd_op_w_bytes (OSD読み書きバイト)、ceph_osd_op_out_op_per_sec (OSDスループット) などのメトリックを通じて、さらに詳細な性能分析が可能です。
3. PromQLクエリおよびAlertmanagerルールの定義
収集されたメトリックに基づいて特定の状況を検知するPromQLクエリを作成し、それをAlertmanagerでアラートルールとして定義します。以下に主要なPromQLクエリの例とAlertmanagerルールを示します。
3.1. OSD状態検知
# 特定のOSDがdown状態であるかを検知
ceph_osd_up{job="ceph"} == 0
# OSDがup状態であるもののクラスターからout状態であるかを検知 (手動での除外または復旧中でないことを前提)
ceph_osd_in{job="ceph"} != on(instance) ceph_osd_up{job="ceph"}
3.2. OSDレイテンシ異常検知
# OSD apply latencyが100msを超えるOSDを検知 (閾値は環境に合わせて調整が必要)
ceph_osd_apply_latency_ms{job="ceph"} > 100
# OSD commit latencyが50msを超えるOSDを検知
ceph_osd_commit_latency_ms{job="ceph"} > 50
3.3. PG Degraded比率およびCeph Health状態検知
# 全PGのうちdegraded状態のPGの比率が10%を超える場合を検知
(sum(ceph_pg_degraded{job="ceph"}) / sum(ceph_pg_total{job="ceph"})) * 100 > 10
# Cephクラスターのhealth statusがERROR (2) である場合を検知
ceph_health_status{job="ceph"} == 2
# Cephクラスターのhealth statusがWARNING (1) である場合を検知
ceph_health_status{job="ceph"} == 1
3.4. Alertmanagerアラートルール
# alert.rules.yml 例
groups:
- name: ceph.rules
rules:
- alert: CephOSDDown
expr: ceph_osd_up{job="ceph"} == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Ceph OSD {{ $labels.instance }} is down"
description: "Ceph OSD {{ $labels.instance }} (ID: {{ $labels.osd_id }}) is not up for more than 1 minute. Immediate investigation required."
- alert: CephOSDHighLatency
expr: ceph_osd_apply_latency_ms{job="ceph"} > 100 or ceph_osd_commit_latency_ms{job="ceph"} > 50
for: 5m
labels:
severity: warning
annotations:
summary: "Ceph OSD {{ $labels.instance }} reports high latency"
description: "Ceph OSD {{ $labels.instance }} (ID: {{ $labels.osd_id }}) has high apply/commit latency for more than 5 minutes. Current apply: {{ $value | humanize }}ms, commit: {{ $labels.commit_latency | humanize }}ms. Investigate performance degradation."
- alert: CephOSDNearFull
expr: (ceph_osd_pool_used_ratio{job="ceph", name="ssd_pool"} * 100) > 69 # 69%は現在の状態に合わせた例、nearfull 75% 閾値を考慮
for: 5m
labels:
severity: warning
annotations:
summary: "Ceph SSD pool is near full"
description: "Ceph SSD pool usage is at {{ $value | humanize }}%. Nearfull threshold is 75%. Consider adding capacity."
- alert: CephHealthError
expr: ceph_health_status{job="ceph"} == 2
for: 1m
labels:
severity: critical
annotations:
summary: "Ceph Cluster Health is in ERROR state"
description: "The overall Ceph cluster health is in ERROR state for more than 1 minute. Immediate investigation required."
- alert: CephPGDegradedRatioHigh
expr: (sum(ceph_pg_degraded{job="ceph"}) / sum(ceph_pg_total{job="ceph"})) * 100 > 10
for: 5m
labels:
severity: critical
annotations:
summary: "High ratio of degraded Placement Groups in Ceph cluster"
description: "{{ $value | humanize }}% of Ceph PGs are in degraded state. This indicates potential data redundancy loss or slow recovery. Investigate OSDs or network issues."
これらのルールは、OSD障害だけでなく、潜在的な性能低下の兆候や容量不足のリスクを事前に検知し、SREチームが先手を打って対応できるように支援します。
4. CRUSHホストレベル障害ドメインとmin_sizeのトレードオフ
CephのCRUSH (Controlled Replication Under Scalable Hashing) mapは、データをOSDに分配し、レプリカを配置する方法を定義します。私たちは、単一ノード障害時でもデータ損失を防ぎ、サービス可用性を維持するために、CRUSH mapをhostレベルの障害ドメインとして設計しました。これにより、各レプリカが異なる物理ホストのOSDに保存されるようになり、今回のstorage004ノード全体の障害のような状況でも、データ損失なしにクラスターが復旧できた主要因となりました。
# CRUSH map 例スニペット (部分抜粋)
# rule replicated_rule {
# ruleset 0
# type replicated
# min_size 1
# max_size 10
# step take default
# step chooseleaf firstn 0 type host
# step emit
# }
# (実際の環境ではより複雑な構成が適用されます)
しかし、min_size=1の設定には注意が必要です。この設定は、PGが少なくとも1つのOSDに保存されていればI/O操作を継続できるようにすることで、可用性を最大化します。これは、例えばレプリカ数が3つ (size=3) のPGで2つのOSDが障害を起こしても、残りの1つのOSDが機能している限りサービス停止を防ぐことができます。しかし同時に、残りの1つのOSDまでも障害が発生すれば、データ損失は避けられなくなります。
私たちの場合、この設定は高速な復旧と高い可用性のための選択でしたが、同時に複数のOSDが同時障害を起こした場合にデータ損失のリスクが増加するというトレードオフがあることを明確に認識していました。これを緩和するため、OSD障害を超高速で検知し復旧するプロセスが不可欠であり、Seekurity SIEM/SOARを活用して、障害アラート発生時に自動化された対応プレイブックを連動させる方法を積極的に検討しています。これは、min_size=1の潜在的リスクを最小限に抑えつつ、高い可用性を維持するための戦略の一環です。
結果と成果
PrometheusベースのCeph監視システムを構築した後、私たちのストレージ運用は以下の定量的/定性的な成果を達成しました。
定量的な成果
- 平均OSD障害検知時間90%短縮：従来は数十分を要していたOSD障害の検知時間が、平均数分以内に短縮されました。
- PG degraded状態持続時間70%減少：障害の早期検知と迅速な対応により、PGがdegraded状態にとどまる時間が大幅に短縮されました。
- ストレージノードあたりの平均SRE障害対応時間50%削減：自動化されたアラートと明確なメトリックは、障害診断と復旧に必要なSREの手動介入時間を大幅に削減しました。
- SSDプールのnearfull閾値到達前の事前警告精度20%向上：容量利用率メトリックに基づく予測警告により、容量増設計画をより正確に立案できるようになりました。
定性的な成果
- SREチームの運用負担軽減および心理的安定性確保：予測不可能なストレージ障害に対する不安感が解消され、より戦略的な業務に集中できるようになりました。
- 障害発生時の体系的かつ迅速な対応プロセス確立：アラートルールに基づいて優先順位を付与し、標準化された手順に従って障害に対応できるシステムが整備されました。
- ストレージクラスターの可視性 (Observability) 大幅向上：Grafanaダッシュボードを通じて、Cephクラスター全体の状態と個別OSDの性能をリアルタイムで監視できるようになりました。
- CRUSH map設計の有効性検証：実際の大規模障害状況において、CRUSHホストレベル障害ドメイン設計が単一ノード障害時のデータ損失を防ぐのに効果的であることを確認しました。
| 指標 | Prometheus導入前 | Prometheus導入後 | 改善率 |
|---|---|---|---|
| OSD障害検知時間 | 平均30分 | 平均3分 | 90% |
| PG Degraded持続時間 | 平均60分 | 平均18分 | 70% |
| SRE対応時間 (ノードあたり) | 平均2時間 | 平均1時間 | 50% |
教訓と振り返り
今回のCeph OSD障害とPrometheusベースの監視システム構築経験を通じて、いくつかの重要な教訓を得ました。
min_size=1設定の両面性：高い可用性を確保するためのmin_size=1設定は、データ耐久性の側面で相当なリスクを内包していることを再確認しました。レプリカ数 (replica size) とmin_size間の繊細なバランスは、単なる技術的選択ではなく、事業継続性 (Business Continuity) と直結する政策的決定であるという点を深く理解するに至りました。- 初期監視範囲の拡張の必要性：当初は主要なOSDメトリックに集中していましたが、OSDごとのI/Oパターン、
scrubスケジューリング、そしてceph-mgrモジュールの状態および性能メトリックを含む詳細な監視が、クラスター全体の健全性と潜在的な問題を早期に把握する上で、はるかに効果的であるという点を認識しました。 - 予期せぬ副次的効果：監視システム構築の過程で、SREチームはCeph内部の動作原理、特にCRUSH mapとPGの動作方式に関する理解度を大幅に高めました。これは単に障害に対応するだけでなく、先制的な性能最適化とアーキテクチャ改善につながる肯定的な循環を形成しました。また、
nearfull警告が単純な容量問題ではなく、OSD間のデータ不均衡 (skew) またはデータ分布の偏りの初期兆候である可能性という深い洞察を得て、これを解決するための運用戦略の策定に貢献しました。
適用ガイド
類似のCephクラスター環境を運用しており、OSD障害検知および対応システムを改善しようとする組織は、以下のガイドラインを通じてシステム信頼性を定量的に確保できます。
ceph-exporterデプロイ戦略：大規模Cephクラスターでは、ceph-exporterを専用の監視ノードまたは各Managerノードに独立してデプロイすることで、Cephクラスター自体のリソース使用率を最小限に抑え、ワークロードへの影響を効率的に管理します。- Alertmanagerルーティング最適化：Alertmanagerのルーティングツリーを精巧に設計し、Critical、Warningなど深刻度に応じてアラートが適切な担当チームや個人に、SLOを違反しない最小限の遅延時間内に正確かつ迅速に届けられるようにします。不要なアラートによる「アラート疲労度」が特定の閾値を超えないよう、定期的なチューニングがシステム信頼性の核となる要素です。
- Grafanaダッシュボード可視化：主要なCephクラスターの状態 (health, PG count, OSD count) およびOSDごとの性能 (latency, I/O throughput, utilization) メトリックを一目で把握できるGrafanaダッシュボードを構築し、障害の兆候を先制的に検知し、視覚的な運用可視性を確保することが重要です。
- 段階的導入ロードマップ：
ceph-exporterをデプロイし、Prometheusに連携して主要メトリックの収集を開始します。ceph_osd_up,ceph_health_statusのような主要指標に基づくGrafanaダッシュボードを構築し、クラスターの状態を直感的に監視します。- Alertmanagerを通じてOSD down/outアラートルールを優先的に設定し、Criticalアラートがトリガーされる条件を明確にします。
- OSDレイテンシ、PG状態、プール使用率など、詳細なメトリックに基づく監視を拡張し、関連するアラートルールを細分化して潜在的な障害シグナルを早期に検知します。
- Seekurity SIEM/SOARと連携し、Ceph関連の障害アラートがトリガーされた際に自動化された対応プレイブックを即座に実行するよう構築します。例えば、OSDがSLO違反レベルで特定時間以上down状態である場合、自動復旧スクリプトを実行したり、事後分析に必要な詳細診断情報を担当者に提供するワークフローを構成します。また、FRIIM CNAPPを活用してクラウドインフラ全体のセキュリティ可視性を確保し、ストレージレイヤーで発生しうる潜在的なセキュリティ脅威を統合的に管理することで、システム全体の信頼性を高めます。
このような実践ガイドラインを通じて、Ceph OSD障害に対する先制的な検知および効率的な対応体制を構築することで、平均復旧時間 (MTTR) を短縮し、サービス停止時間を最小化して、クラウドストレージサービスの安定性を定量的に保証できます。