要約

  • RHELガイドは同期・非同期の能動的なデータボリューム複製をホットDRに含め、有償購読を必要とする。通常の顧客通信を処理しているかだけでは分類できない。
  • 自己管理型OpenShiftは外部ストレージ装置の複製をウォームDRとして扱い、保守・試験目的の一時起動とワークロード実行も分ける。調達判断には実際の復旧経路が要る。

待機機を「使っていない」と呼ぶのは簡単だ。主系からデータが届き続けているなら、その機械は障害後の仕事を先に引き受けている。Red Hatの2026年7月21日付RHEL購読ガイドでは、システム間で能動的にデータボリュームを複製すると、同期でも非同期でもホットDRに分類される。

通常の利用者が来る前から、復旧の準備には商品としての境界がある。事業部門は早い再開を求め、運用部門は障害後の作業を減らし、購買部門は平時の支出を抑えたい。「待機」という便利な一語では、この三つの注文はまとまらない。

ウォームには後で行う作業が残る

RHELのガイドは、DR環境ではホットに有償購読が必要だとする。ホットは本番と並行して十分に稼働し、主環境の災害時に直ちに通信を受けて引き継ぐ準備ができた状態だ。

ウォームは元の環境に近いワークロードを受け入れる準備がある一方、元システムの顧客ワークロードを含まず、能動的なボリューム複製にも参加しない。再開には、元システムの外から既存ハードウェアへ顧客データを復元する。コールドは再開に必要な技術一式がまだそろっていない。

ウォームとコールドでは、災害時に主環境の購読を移してサービスを復旧できる。ただし、購読の移管、データの復元、アプリケーションの起動、業務の再開は、それぞれ終えるべき工程だ。権利を移せばデータまで席替えを済ませるわけではない。

平時の購読を抑える設計は、後の復旧に仕事を残す。その選択は事業の許容する停止時間と一緒に評価すればよい。調達側の節約額だけが見え、復元する人と時間が別の帳簿に隠れれば、会社全体の比較は崩れる。

OpenShiftでは複製の置き場所を読む

2026年1月23日付の自己管理型OpenShiftガイドも、ホットDRには有償購読を求める。その定義は、OpenShift上のソフトウェア定義ストレージがクラスター間で行う能動的な同期・非同期複製を取り上げる。

ウォームの規定では、複製データを副拠点でマウントし、稼働中のコンテナワークロードが使う場合も問題になる。一方、外部ストレージ装置によるボリューム複製は、このガイドではウォームDRのままとされる。OpenShift上のソフトウェア定義ストレージを用いたウォーム復旧には、クラスター外から既存のクラスター機材へデータを復元する工程が要る。

これで購買担当が見るべきものは、予備機の台数からデータの道筋に広がる。複製はどこで行い、どのワークロードが読み、切り替え後に何を戻すのか。保存層を変える案には、その層の費用と運用も付いてくる。

OpenShiftの外部ストレージ規定をRHELへ持ち込めば、製品の違いが消えてしまう。すべての複製を一律に有償ホットと呼んでも、OpenShiftの明記した区別を失う。同じ赤い帽子の下でも、調達条件には製品別の住所がある。

眠っていても購読は眠らない

OpenShiftでは、ウォームまたはコールドDRとして明確に設計・設定されていない休止クラスターは、引き続き購読を要する。ガイドは、需要減で一時的に休ませたクラウドのクラスターを例に挙げる。省力運転と災害復旧の準備は、用途が異なる。

実際のウォーム・コールドDRを起こしてワークロードを実行すれば購読が必要になる。通常の保守や試験のため一時的に起こす場合には、OpenShiftソフトウェア製品の構成要素に追加購読を求めない。この区別が、保守と演習の余地を残す。

演習で知るべきなのは、いざ起こした後に残る仕事だ。復元にどれだけ手間がかかり、どこで人の判断を待ち、何をもってサービス復旧とするのか。静かに置いておくだけなら予算の説明は楽になる。復旧当日の説明は難しくなる。

買い手の実際のストレージ・ワークロード経路、復旧試験時間、適用見積もりが欠けており、この三つがそろえば経済的に有利な設計は変わり得る。

準備を今買う費用と、後で復元する費用を同じ選択に戻す。人員、外部設備、他の依存先も加える。保護機能を止めて購読だけを安くする案なら、同時に変わる業務上の賭けを、停止の影響を負う人に見せる必要がある。

出典