ディザスタリカバリとは

災害は、いつ来るのか分かりませんが必ずやってきます。そのような災害から、ITシステムを守り迅速に復旧するため、そして、事業継続のために必要な「ディザスタリカバリ」について紹介します。

目次

ディザスタリカバリとは

  • ディザスタリカバリ概要
  • システムダウンがもたらす影響
  • ディザスタリカバリの目的

業務継続計画

  • 「業務継続計画」とは
  • ディザスタリカバリの想定ケース
  • 必要とされる全システムの復旧が必要

「ディザスタリカバリ」は「企業の常識」に

ディザスタリカバリの課題

  • 課題1 データバックアップ処理時のネットワーク帯域占拠
  • 課題2 増加し続けるデータ量
  • 課題3 リカバリ時の復旧手順

データバックアップの目的

  • 「保護」+「活用」へ
  • ウイルス対策
  • デジタルフォレンジック

ディザスタリカバリの指標

  • RPO(Recovery Point Objective)
  • RTO(Recovery Time Objective)

ディザスタリカバリ方式選定のポイント

  • 「業務プロセス」と「ビジネスインパクト」の可視化
  • 保護対象データ種類(データ整合性)
  • DR方式を決定する際の主な要素

ディザスタリカバリ方式の種類

  • 遠隔地バックアップ
  • 「同期方式」と「非同期方式」
  • レプリケーション方式
  • 「コールドスタンバイ」と「ホットスタンバイ」
  • クラウドバックアップ

コストとのトレードオフ

「経営層」と「ディザスタリカバリ」

まとめ

参考元サイト

ディザスタリカバリとは

ディザスタリカバリ概要

ディザスタリカバリ(Disaster Recovery、DR)とは、直訳すると「災害復旧」を意味します。

IT用語としての「ディザスタリカバリ」は、「事業継続マネジメントにおける概念のひとつで、災害などで大規模システム障害が発生した際に、システムを迅速に復旧/修復を行うための仕組み、被害を最小限に抑えるための予防措置、そして組織体制」となります。

災害とは、自然災害(地震/津波/風水害など)のみではなく、「火災」「テロ」「不正侵入」「大規模ハッキング」「長期間大規模停電」などの広範囲な事象まで含み、システム全体に対して壊滅的被害をもたらすものを意味します。

システムダウンがもたらす影響

システムダウンは、多くの売上機会損失など、該当企業に対して多大な損害をもたらします。

また、顧客に対してのサービスレベルの低下につながります。サービスを提供する企業は、社会的責任を問われることも考慮に入れなければなりません。

ディザスタリカバリの目的

ミッションクリティカルなサービスを提供する企業にとって、予期せぬシステムダウンタイムに対応できる事業継続体制を構築することは極めて重要な課題です。

ディザスタリカバリは「システムダウンによる利益の損失を可能な限り最小限に抑える」ことを目的とします。

信頼失墜の拡大を防ぐために、「システムダウン予防措置」「確実なデータ保護」「ダウンタイムを最小限にする迅速なサービス復旧」が可能な信頼性の高い事業継続システムが求めらます。

壊滅的システムダウン(想定内障害/想定外障害)は、「もしかしたら起こるかもしれない」ではなく、「必ず起こるもの」と認知し、対策を取る必要があります。

業務継続計画

「業務継続計画」とは

「業務継続計画」とは、システムが壊滅的被害を受けた場合に、迅速にサービスを復旧するために、「バックアップ指針」「災害時復旧手順」などを事前に定めておくものです。

「災害時の指揮本部の確保」「指揮命令系統」「連絡手段整備」などの組織体制面の対策が中心となります。

技術的なディザスタリカバリシステム設計は、「業務継続計画」に従い作成されます。

ディザスタリカバリの想定ケース

経済産業省が公表している「事業継続計画策定ガイドライン」では、ディザスタリカバリの想定ケースとして「大規模なシステム障害」「セキュリティインシデント」「情報漏えい」「データ改竄」などが上げられています。

必要とされる全システムの復旧が必要

システムの一部のみバックアップ対策が行われていたとしても、他のシステムと連動しなければ機能せず、業務が回らない場合が多々あります。

事業継続に必要なすべてのシステムがバックアップされ、迅速に復旧できる「業務継続計画」である必要があります。

「ディザスタリカバリ」は「企業の常識」に

以前は、特に中堅/中小企業において、「情報システムのバックアップ」という領域は、直接的な営業利益を生まない分野として後回しにされがちでした。

しかし、2011年3月の東日本大震災が発生したことを契機に状況が一変しました。システム停止が社会の大混乱を招くことを目の当たりにし、ディザスタリカバリの重要性を考えざるを得なくなりました。

今までディザスタリカバリを意識していなかった企業も含めて、多くの経営者/情報システム担当者は、危機感を持って、災害時事業継続性向上について取り組み始めました。

「ディザスタリカバリ(災害復旧)は企業の生命線」と捉える認識が高まり、多くの企業が、事業継続計画の作成/強化を行っています。

ディザスタリカバリの課題

ディザスタリカバリシステムを構築する場合には、多くの課題が存在します。主な課題を紹介します。

課題1 データバックアップ処理時のネットワーク帯域占拠

災害発生時のデータ損失を最小限に抑えるために、頻繁なデータバックアップは重要なポイントです。

しかし、日常の処理としてリモートバックアップを行う場合、バックアップが拠点間のネットワーク帯域を占拠してしまい、通常業務に支障を生じさせないようなネットワーク設計が必要です。

課題2 増加し続けるデータ量

IT化が進行し、さまざまなコンテンツがデジタルデータとして発生し続けています。そのため、企業のITシステムには、大規模なデータが蓄積されています。

膨大な量のデータをバックアップするためには、長時間を要します。ディザスタリカバリサイト(バックアップサイト)側のストレージ容量も増大します。

データ種類ごとに保護優先度を設定し「どれが守るべきデータなのか」について明確にしておく必要があります。

課題3 リカバリ時の復旧手順

災害が発生してシステムダウンとなった場合、サービス復旧(リカバリ)が必要です。

その手順は、シンプルに実行できるようにまとめられている必要があります。

バックアップデータが複数箇所に散在しているなど、煩雑な手順になっている場合には、できるだけシンプルな復旧手順となるように、全体設計を見直す必要があります。

データバックアップの目的

「保護」+「活用」へ

従来、データバックアップは、IT機器の障害/故障に備えるために、「データを保護する」という目的で行われていました。現在のバックアップは、「データ保護」という要素に加えて、「データ活用」という意味でも必要になってきています。

企業や業界によっては、データの長期保存が義務づけられ、「監査」のために必要なデータをすぐに提出できることが求められています。

「単にバックアップしておけばよいもの」だけではなく、「バックアップデータを活用できる仕組み」も必要になっています。

ウイルス対策

最近では、「ウイルス対策」も目的の1つになっています。

特に、ランサムウェアに感染してしまった場合、データが不正に暗号化されてしまい、復旧できなくなる場合があります。特に、レプリケーション型のバックアップである場合、不正暗号化されたデータをバックアップ上書きしてしまうという状態になりかねません。

確実に復旧できるバックアップ体制が必要とされています。

デジタルフォレンジック

「デジタルフォレンジック(サイバー攻撃を受けた場合に原因を究明するための作業)」や「e-ディスカバリー(米国の電子証拠開示制度:訴訟時デジタルデータ開示)」などにおいても、バックアップの重要性が再認識されてきています。

ディザスタリカバリの指標

ディザスタリカバリに関する主な指標として「RPO」と「RTO」があります。

RPO(Recovery Point Objective)

「RPO」とは「データ保証時間目標」です。

「災害発生時点から、過去に向かってどの時点までのデータ復旧を保証するのか」を示す指標です。

「RPO=1日」である場合、1日1回のリモートバックアップで対応可能です。

「RPO=0(データ損失ゼロ)」を目指す場合は、データ常時即時バックアップ転送(レプリケーション)などの仕組みが必要です。

RTO(Recovery Time Objective)

「RTO」とは「復旧所要時間目標」です。

「災害発生時点から、何時間後(何日後)までにシステムを復旧させるのか」を示す指標です。

「RTO=1カ月以上」とする場合、「リモートバックアップのみを行い、代替機の確保から始める」でも対応可能であるかもしれません。

「RTO=数時間以内」の場合は、バックアップリモートサイトにスタンバイ機を準備しておき、レプリケーションの仕組みが必要です。

ディザスタリカバリ方式選定のポイント

「業務プロセス」と「ビジネスインパクト」の可視化

ITシステムのディザスタリカバリ対策の検討において、ITシステム部門が主導する場合が多くなります。

ITシステム部門は、業務プロセス全体を正確に理解していないことが多く、IT視点からのアプローチに偏ってしまいがちです。システム停止時のインパクトや影響範囲を把握できずに、復旧要件/サービスレベルを定義できないことになります。

ITシステムのディザスタリカバリ対策検討時には、「すべての業務プロセスの可視化」と「各システム停止時のビジネスインパクト」の明確化が重要です。

ビジネスインパクトが最も小さくなるようなディザスタリカバリ設計が必要です。

保護対象データ種類(データ整合性)

RTO/RPOのみに注目するのではなく、保護対象データの種類/重要度の分類が大切です。

それほど正確な整合性を要しないデータ(ファイルサーバなど)は、シンプルなプライマリストレージのバックアップのみで対応可能な場合もあります。

一方、整合性の確保が必要であるデータ(データベースシステムなど)は、不整合が生じないように正確なレプリケーションが必要です。

データ整合性種類ごとに適切なDR方式を選択する必要があります。

DR方式を決定する際の主な要素

  • 保護対象システム規模(データ種類、容量)
  • 復旧要件(RTO:データ保証時間目標、RPO:復旧所要時間目標)
  • 予算

ディザスタリカバリ方式の種類

ディザスタリカバリシステムの主なバックアップ方式として、「遠隔地バックアップのみ」と「遠隔地データレプリケーション+スタンバイシステム」があります。

遠隔地バックアップ

ディザスタリカバリシステムにおいて、ローカルバックアップに加えて、遠隔地(リモート)バックアップが重要です。

ローカルシステム内において、「バックアップ」や「RAIDシステム」を行っていたとしても、災害により建物全体に被害が及んだ場合、データ損失の恐れがあります。

単純に「データを保護する」という目的のみである場合、リモートバックアップのみで対応可能です。システム構成がシンプルであるため、低コストで導入できます。

東日本大震災以降は、日本東西や海外にバックアップデータを分散することも重要視されています。データセンターを利用したリモートバックアップも増えています。

「同期方式」と「非同期方式」

データコピーの方式には「同期方式」と「非同期方式」があります。

同期方式

バックアップサイトへのコピー完了を確認してから、サーバに完了報告を行う方式です。

プライマリサイトとバックアップサイト間でデータの一致が保証されます。

非同期方式

プライマリサイトのストレージへの書き込みが終わった時点で、バックアップサイトのコピー完了を待たずにサーバに完了報告を行う方式です。

非同期方式では、災害発生のタイミングによって、プライマリサイトとバックアップサイトのストレージの内容に差異が発生する可能性があります。

レプリケーション方式

「レプリケーション方式」は、常時、リアルタイムに、プライマリシステムのデータを、バックアップシステムへデータ転送する手法です。

プライマリシステムに障害が発生した場合、データが転送されているバックアップシステム側で、システムを継続できます。

「RPO(Recovery Point Objective)」の観点としては、バックアップ方式よりも、障害直前状態での復旧を行えます。

「コールドスタンバイ」と「ホットスタンバイ」

コールドスタンバイ

待機系のスタンバイシステムを構築しておきます。

システム自体は停止させておきますが、データについては、プライマリシステムからのレプリケーションにより、常時データ同期を行います。

プライマリシステムがダウンした場合には、手動でスタンバイシステムを起動して、サービスの継続を行います。

ホットスタンバイ

スタンバイシステム側でも、システムを起動させた状態にしておき、プライマリシステムがダウンした瞬間に、自動的に、スタンバイシステムをプライマリへ昇格させ、サービスを継続する仕組みです。

システムダウンタイムを短くすることが可能ですが、仕組みが複雑になるため、コストが高くなる傾向があります。

クラウドバックアップ

クラウド利用が一般的になってくるに従い、ディザスタリカバリにクラウドを利用するケースが増えてきています。

主なメリット

  • ハードウェアなどのIT資産を自社で管理する必要がない
  • 必要量/必要スペックの機器を必要な時に利用できる
  • オンプレミスでバックアップシステムを構築するのに比べ、低コストで利用可能
  • ストレージサイズのオートスケール
  • コールドスタンバイの場合、システムを停止しておけば、利用料金が発生しない
  • レプリケーションとHAクラスタリングの利用において、インフラとして親和性が高い

コストとのトレードオフ

「RPO」と「RTO」が小さいほど、短いダウンタイムでの復旧が可能となりますが、それに従いコストが増大していきます。

「コスト面」と「各データの資産価値」を考慮し、どのレベルまでの対策が必要なのかについて、最適な方法を模索する必要があります。「自社での実施」と「外部サービス委託」についてのバランスも重要です。

要件を明確にし、ある程度許容しつつ、最小コストでディザスタリカバリシステムを構築することが求められます。

「経営層」と「ディザスタリカバリ」

事業継続計画の策定がディザスタリカバリシステム構築の前提となります。企業システムが非常事態に陥った場合の「組織としての行動」「復旧の優先順位」などのグランドデザインの中にディザスタリカバリを組み込まなければいけません。

そのために重要となってくるのが「経営層のディザスタリカバリに対する重要性の認識」です。ディザスタリカバリは、企業存続に関わる重要な経営判断となるため、現場任せではなく、経営層がディザスタリカバリプロジェクトを推進していくことが求められます。

まとめ

データは企業の重要資産として守らなければいけません。特に、日本は、地震/津波/火山噴火など自然災害の多い国です。

「災害には必ず巻き込まれる」という前提で、最適なディザスタリカバリシステムを構築し、事態に備えることが求められています。

参考元サイト

Microsoft Azureの障害・サービス停止を回避しよう

2017年3月31日にMicrosoft Azureの東日本リージョンのリソースに接続できない状態となりました。
米マイクロソフトの公式サイトによると、この障害の根本原因は、一部の拡張ユニットが冷却できない状態になったことだそうです。データ保護のために特定のストレージユニットとコンピューティングユニットが自動シャットダウンされました。

これにより、Azureストレージサービスと、ストレージを利用するAzure App Service (Web Appsなど)など多くのサービスが影響を受けました。

このような障害を教訓に、ユーザー側はクラウドサービスを使う際は障害が起こることを想定して自社システムの可用性を維持するための対策を講じておくことが重要です。

最近では、「単一のクラウドサービスにデータを預けるのはリスクがある」という理由から複数のクラウドサービスを併用する「マルチクラウド」という考え方も一般的になっています。

例えば、Azureに大規模障害が発生しても、AWS上でサービスを継続しよう、という考え方です。

DRBDは、そのようなケースにおいて、AzureとAWSの間で、データをリアルタイムに同期し、万が一AWSに大規模障害が発生した場合、AWS上でのサービス継続を可能にします。
https://www.3ware.co.jp/solution/disaster-recovery

ぜひご参考ください。

 

参考サイト:
http://ascii.jp/elem/000/001/462/1462133/

2017年3月1日のAWS障害の原因と、その対策

2017年3月1日にAWS(Amazon Web Services)の「Amazon Simple Storage Service (S3)」で大規模な障害が発生しました。S3を利用する多くのウェブサイト、アプリ、デバイスが一部あるいは完全に作動しなくなりました。

AWSの報告によると、当時作業チームのメンバーがS3の決済システムを修正するためにサブシステムを構成する数台のサーバーを停止する目的でコマンド入力しました。しかしコマンドの入力ミスにより意図したサーバーより多くのサーバーを停止してしまったようです。そのために他の重要なサブシステムにも影響が出てしまい、結果的にシステム全体を再起動しなければならない事態となってしまいました。

AWS公式サイトの説明によると、S3の急激な成長でシステムが巨大化し、思った以上に再起動に時間がかかったとのことです。

米SimilarTechのデータによると、4時間以上に及ぶ今回の大規模障害で、約15万サイトが影響を受けたとのことです。Amazonのような大手クラウドサービスであっても大障害は発生します。今後は、このようなリスクを回避するための対策が必要になってくるのではないでしょうか。

最近では、「単一のクラウドサービスにデータを預けるのはリスクがある」という理由から複数のクラウドサービスを併用する「マルチクラウド」という考え方も一般的になっています。

例えば、AWSに大規模障害が発生しても、Microsoft Azure上でサービスを継続しよう、という考え方です。

DRBDは、そのようなケースにおいて、AWSとAzureとの間で、データをリアルタイムに同期し、万が一AWSに大規模障害が発生した場合、Azure上でのサービス継続を可能にします。
https://www.3ware.co.jp/solution/disaster-recovery

ぜひご参考ください。

参考サイト:
http://itpro.nikkeibp.co.jp/atcl/news/17/030300696/?rt=nocnt
http://jp.techcrunch.com/2017/03/01/20170228amazon-aws-s3-outage-is-breaking-things-for-a-lot-of-websites-and-apps/

DRBD参考情報

DRBDに関する各種事項について参考情報として紹介します。

目次

第1回 DRBDのダウンロードとインストール
・参考サイト
  ・DRBDパッケージのダウンロード
  ・【商用サポート用】DRBDバイナリパッケージのインストール
  ・簡単にできるDRBD9環境構築
  ・【Ubuntu編】「DRBD 9環境」構築マニュアル
  ・【CentOS編】DRBDのインストールと設定手順
第2回 DRBDとPacemakerでのクラスタ構築
・「Pacemaker」とは
・「Corosync」とは
・参考サイト
  ・DRBDユーザーズガイド「DRBDとPacemakerクラスタ」
  ・【CentOS 7】DRBD+Pacemaker+Corosyncで高可用クラスタ構築
第3回 DRBDでのMySQLクラスタ構築
・参考サイト
  ・ 落ちないMySQLサーバの作り方
  ・DRBD+Corosync+Pacemakerでの「HA(高可用性)MySQLサーバ」構築方法
  ・「MySQL 5.6」でのデータ領域クラスタ化
  ・【Azure】DRBDを使用した「高可用性MySQL」クラスタ構築
第4回 DRBDでのPostgreSQLクラスタ構築
・参考サイト
  ・PostgreSQL+Pacemaker+DRBDで高可用性構成を構築してみよう
  ・DRBDでのPostgreSQLレプリケーション
  ・【Azure】DRBD/Corosync/Pacemaker を利用したAzureでの高可用性クラスタ構築手順ガイド
第5回 DRBDのスプリットブレイン
・「スプリットブレイン」とは
・参考サイト
  ・DRBDのスプリットブレイン
  ・仕組みを理解すれば怖くない「スプリットブレイン」からの復旧方法
  ・DRBD動作(パラメータ)設定
  ・DRBDのスプリットブレインの通知と自動復旧ポリシー
  ・スプリットブレインからの手動回復

第1回 DRBDのダウンロードとインストール

DRBDのダウンロード/インストール/構築について、参考にできるサイトを紹介します。

参考サイト

DRBDパッケージのダウンロード

ポイント

DRBDパッケージをダウンロードできるサイトを紹介しています。

テーマ

・ダウンロード方法
・DRBDパッケージ
  ・LINBIT社DRBDソースコード
  ・LINBIT社インストールパッケージ(サポートの購入が必要)
・導入事例・技術資料・ホワイトペーパー

ページリンク

DRBD →ダウンロード

【商用サポート用】DRBDバイナリパッケージのインストール

ポイント

商用サポート対象ユーザー向けDRBDバイナリパッケージのインストール方法が解説されています。

主要OS別に参照できます。

テーマ

・3.1. LINBIT社が提供するパッケージ
・3.2. ディストリビューションベンダが提供するパッケージ
  ・3.2.1. SUSE Linux Enterprise Server
  ・3.2.2. CentOS
  ・3.2.3. Ubuntu Linux
  ・3.2.4. Debian GNU/Linux

ページリンク

DRBDユーザーズガイド →II. DRBDのコンパイル、インストールおよび設定

簡単にできるDRBD9環境構築

ポイント

サーバ3台環境において、DRBD9で多ノード環境を構築する手順がまとめられています。

各サーバに「DRBD9」と「DRBD Manage」がインストール済みの前提です。

テーマ

・前提条件
・構成図
・DRBD9インストール手順
・DRBD9初期化
・ノード追加
・ノード確認
・プールとリソースとボリュームの関係
・リソース追加
・リソース追加確認
・ボリューム割り当て
・ボリューム割り当て確認
・デプロイ
・デプロイ確認
・ファイルシステム作成
・マウント
・書き込みテスト

ページリンク

→Qiita →簡単にできるDRBD9環境構築

【Ubuntu編】「DRBD 9環境」構築マニュアル

ポイント

Ubuntu環境において、DRBDを構築するための一連の手順が解説されています。

テーマ

・DRBD 9環境を構築する
  ・インストール準備とディスクの追加
  ・パーティション作成
・DRBD 9をインストールする
  ・hostsに追記する
  ・公開鍵の作成と鍵交換
  ・lvm領域を作成する
  ・リポジトリを追加する
  ・DRBD9とDRBD Manageをインストールする
・DRBD Manageで、DRBD 9環境を構築
  ・初期化する
  ・ノードを追加する
  ・リソースを登録する
  ・ボリュームを登録する
  ・デプロイ/アサインを行う
  ・ファイルシステムを作成する
  ・DRBD領域をマウントする
  ・DRBD 9の状況を確認する
・リソースの移動やスケールアウトも簡単

ページリンク

→@IT →Ubuntuで実践する「DRBD 9環境」構築マニュアル

【CentOS編】DRBDのインストールと設定手順

ポイント

「CentOS7.2 (64bit)」環境でのDRBD構築手順について解説されています。

「DRBD概要」「インストール/設定手順」「スプリットブレイン」など、包括的にまとめられています。

テーマ

・1 DRBDとは何か?
  ・1.1 DRBDの構成図
・2 障害が発生したらどうなるのか?
・3 DRBDのインストール&設定
  ・3.1 DRBDのインストール前の準備
  ・3.2 インストールする
  ・3.3 インストール後の各設定ファイルの設定
  ・3.4 初期設定をする
  ・3.5 リソースの有効化と無効化
  ・3.6 リソースの昇格と降格
  ・3.7 基本的な手動フェイルオーバ
・4 DRBDの障害対応
  ・4.1 障害時のチェックポイント
・5 ハンドラー用のスクリプト
・6 もう少々DRBDの説明
  ・6.1 DRBDのリソース
  ・6.2 DRBDの2つのモード
  ・6.3 レプリケーションの3つのタイプ
・7 スプリットブレインについての説明
  ・7.1 スプリットブレインの原因
  ・7.2 スプリットブレインの対処
・8 結論

ページリンク

→ 100%レンタルサーバーを使いこなすサイト →DRBDのインストールと設定手順

第2回 DRBDとPacemakerでのクラスタ構築

「DRBD」+「Pacemaker」(+「Corosync」)によるクラスタ構築方法について、参考にできるサイトを紹介します。

「Pacemaker」とは

「Pacemaker」とは、オープンソースのHA(高可用化)クラスタソフトウェアです。

以前は「Heartbeat」という名前で開発されていました。

複数のサーバを連携させ、1つのサーバに障害が発生した場合、フェイルオーバー(他のサーバを昇格)させてサービスを継続させることにより、システム全体としての可用性を向上させます。

※Pacemakerは、DRBDクラスタでのクラスタ制御機能として、よく組み合わせて利用されます。

→LINUX-HA JAPAN →Pacemakerの概要

「Corosync」とは

「Corosync」とは、オープンソースのクラスタ通信層制御ソフトウェアです。

高可用性クラスタ構成の中で、クラスタ通信フレームワークを提供し、クラスタ構成サーバ間でノード死活監視を行います。

※Corosyncも、DRBDクラスタでのクラスタ制御機能として、よく組み合わせて利用されます。

→OSS×Cloud News →オープンソースのクラスタリング/Corosyncとは

参考サイト

DRBDユーザーズガイド「DRBDとPacemakerクラスタ」

ポイント

DRBDユーザーズガイドのPacemakerに関する解説です。

技術ドキュメントとして参照できます。

テーマ

・8.1. Pacemakerの基礎
・8.2. DRBDをPacemakerクラスタで管理する
・8.3. DRBDを下位デバイスにするマスターとスレーブのあるサービスのクラスタ設定
・8.4. Pacemakerクラスタでリソースレベルのフェンシングを使用する
  ・8.4.1. dopd でのリソースレベルフェンシング
  ・8.4.2. CIB (Cluster Information Base)を使ったリソースレベルフェンシング
・8.5. PacemakerクラスタでスタックDRBDリソースを使用する
  ・8.5.1. オフサイトディザスタリカバリ機能をPacemakerクラスタに追加する
  ・8.5.2. スタックリソースを使って、Pacemakerクラスタの4ノード冗長化を実現する
・8.6. 2セットのSANベースPacemakerクラスタ間をDRBDでレプリケート
  ・8.6.1. DRBDリソース構成
  ・8.6.2. Pacemakerリソース構成
  ・8.6.3. サイトのフェイルオーバ

ページリンク

DRBDユーザーズガイド →第8章 DRBDとPacemakerクラスタ →パート IV. DRBDとアプリケーションの組み合わせ

【CentOS 7】DRBD+Pacemaker+Corosyncで高可用クラスタ構築

ポイント

DRBD+Pacemaker+Corosyncを組み合わせた高可用クラスタの構築手順についてまとめられています。

障害発生時の動作確認方法も参照できます。

テーマ

・Vagrant
・パッケージのインストール
・DRBD
・Corosync
・Pacemaker
・クライアントからマウント
・障害発生
・ノード起動時の monitor で NFS Server が開始してしまう問題
・nfsserver はクローンリソースでも良い?

ページリンク

→Qiita →CentOS 7 で DRBD/Pacemaker/Corosync で High Availability NFS

第3回 DRBDでのMySQLクラスタ構築

DRBDを使用して、オープンソースデータベース「MySQL」の高可用性クラスタを構築する方法について、参考にできるサイトを紹介します。

参考サイト

落ちないMySQLサーバの作り方

ポイント

日本MySQLユーザ会の「MySQL高可用化」に関するスライド資料です。

「共有ストレージ」と「ディスク同期」のメリット/デメリットの説明があり、DRBDの特性について分かりやすく理解できます。

テーマ

・DBサーバの構成パターンとメリット・デメリット
  ・1.共有ストレージ
  ・2.ディスク同期(DRBD)
  ・3.スレーブのマスター昇格
  ・4.Group Replication
・クライアント側で意識してほしいこと
・日本MySQLユーザ会のご紹介

ページリンク

→SlideShare →OSC 2017 Osaka MySQL 落ちないDBサーバの作り方

DRBD+Corosync+Pacemakerでの「HA(高可用性)MySQLサーバ」構築方法

ポイント

DRBD+Corosync+Pacemakerを使用した「HA(高可用性)MySQLサーバ」の構築方法についてまとめられています。

「Ubuntu 14.04」環境での構築方法です。

テーマ

0. 下準備
1. mysqlデータ領域の作成
2. DRBDのセットアップ
3. Corosync & Pacemaker のセットアップ
4. MySQLのセットアップ
5. 動作確認

ページリンク

→未経験の30歳がWebプログラマーになって思うこと →DRBD+Corosync+PacemakerでHA MySQL構築

「MySQL 5.6」でのデータ領域クラスタ化

ポイント

「MySQL 5.6」をDRBDを使用してデータ領域をクラスタ化する方法についてまとめられています。

「CentOS 6.7(2台)」+「VMware 5.5(無料版)」での環境です。

テーマ

・はじめに
  ・DRBDをもう一度
・インストール
  ・切り替えを確認
・HeartbeatとPacemaker
  ・Heartbeat
  ・Pacepaker
  ・設定(1号機)
  ・導入・設定(2号機)
  ・DRBD連動
・MySQLサーバ連動
  ・インストール

ページリンク

→fkimuraの備忘録 →MySQL5.6系をDRBDクラスタで試すメモ

【Azure】DRBDを使用した「高可用性MySQL」クラスタ構築

ポイント

Azure上に、DRBDを使用した「高可用性MySQL」クラスタを構築する方法が解説されています。

Azureのデプロイモデル「クラシックデプロイモデル」を使用する場合の解説です。

テーマ

・準備
  ・テスト環境
  ・アフィニティ グループ
  ・ネットワーク
  ・仮想マシン
  ・ストレージの接続
・クラスターをセットアップする
  ・DRBD をセットアップする
  ・DRBD リソースをマウントする
・MySQL設定
  ・MySQL 負荷分散セットを作成する
  ・負荷分散セットをテストする
  ・手動によるフェールオーバー
・Corosync をセットアップする
・Pacemaker をセットアップする
・テスト
・STONITH
・制限事項

ページリンク

→Azure →Virtual Machines →Linux →クラシック デプロイ →負荷分散セットを使用して Linux の MySQL をクラスター化する

第4回 DRBDでのPostgreSQLクラスタ構築

DRBDを使用して、オープンソースデータベース「PostgreSQL」の高可用性クラスタを構築する方法について参考にできるサイトを紹介します。

参考サイト

PostgreSQL+Pacemaker+DRBDで高可用性構成を構築してみよう

ポイント

DRBD+Pacemakerを使用して、PostgreSQLを高可用化構成にする手順についてまとめられているドキュメントです。

テーマ

・高可用性とは
・PostgreSQLのHA構成
・システム構成
・PostgreSQLのインストール
・PacemakerとHeartbeatのインストール
・DRBDのインストール
・OSの設定
・Heartbeatの設定
・DRBDの設定
・PostgreSQLの設定
・Pacemakerの設定
・動作確認

ページリンク

→SRA OSS, Inc →イベント・セミナー一覧 →2014年 →オープンソースカンファレンス2014 Tokyo/Spring →入門 PostgreSQL+Pacemaker+DRBDで高可用性構成を構築してみよう

DRBDでのPostgreSQLレプリケーション

ポイント

DRBDを使用して、PostgreSQLのレプリケーションを行う方法について解説されています。

障害事例についても参照できます。

テーマ

・各アプリケーションの概要
  ・pacemaker
  ・DRBD、PostgreSQLレプリケーション
・Master Slave リソースと従来のリソースとの違い
・Masterに昇格するノードの選定方法
  ・promotionスコア
  ・Pacemaker + DRBDのMasterスコア
  ・Pacemaker + PostgreSQLレプリケーションのMasterスコア
・障害事例
  ・レプリケーションLAN障害
  ・レプリケーションLAN+インターコネクトLAN障害

ページリンク

→SlideShare →PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション)

【Azure】DRBD/Corosync/Pacemaker を利用したAzureでの高可用性クラスタ構築手順ガイド

ポイント

Azure上において、PostgreSQLデータをDRBD領域に格納して、可用性を高める手順について解説しているドキュメントです。

テーマ

・1 はじめに
・2 本書について
・3 Microsoft Azure 構成
  ・3.1 構成図
  ・3.2 OS/ソフトウェア情報
  ・3.3 仮想マシン環境
・4 Microsoft Azure 設定
  ・4.1 ネットワーク設定
  ・4.2 仮想マシン作成
  ・4.2.1 1 台目の仮想マシンの設定
  ・4.2.2 2 台目の仮想マシンの設定
  ・4.3 仮想マシンの下準備
  ・4.4 ストレージの接続
・5 Linux-HA パッケージのインストール
・6 DRBD 設定
  ・6.1 リソースファイル作成
  ・6.2 DRBD メタデータ作成
  ・6.3 DRBD 起動
  ・6.4 DRBD 初回同期
  ・6.4.1 DRBD 初回同期
  ・6.4.2 DRBD 状態確認
・6.5 DRBD マウント領域準備
  ・6.5.1 DRBD 領域にファイルシステムを作成する
  ・6.5.2 PostgreSQL のデータを DRBD 領域に格納する
・7 負荷分散セット構成
・8 Corosync 設定
  ・8.1 corosync.conf 設定
  ・8.2 corosync 起動
・9 Pacemaker 設定
  ・9.1 Pacemaker 起動
  ・9.2 crm コマンド開始
  ・9.3 クラスタのオプション設定
  ・9.4 リソース設定
  ・9.5 設定確認
・10 動作確認
  ・10.1 フェイルオーバさせる
  ・10.2 手動でリソースをスイッチオーバさせる

ページリンク

第5回 DRBDのスプリットブレイン

DRBDの「スプリットブレイン」について紹介します。

「スプリットブレイン」とは

「スプリットブレイン」とは、クラスタ構成において、「アクティブなマスターノードが複数存在してしまう状態」のことを意味します。

ネットワーク切断などによりクラスタが分断されてしまった場合などに発生します。

スプリットブレイン状態時に、対象クラスタにデータ更新が行われるとデータ不整合が発生してしまいます。

データ不整合に対する主な復旧方法
①変更内容を調査してマージ
②どちらかの変更内容を破棄 など

参考サイト

DRBDの「スプリットブレイン」について、参考にできるサイトを紹介します。

DRBDのスプリットブレイン

ポイント

DRBDで発生するスプリットブレインについてまとめられています。

主な回避方法についても参照できます。

テーマ

・スプリットブレインとは
  ・Pacemakerのスプリットブレイン
  ・DRBDのスプリットブレイン
・スプリットブレインを防止する策
  ・フェンシング
  ・クオーラム
  ・その他の安価な代替策
・スプリットブレインを起こす前の状態を確認

ページリンク

→Qiita →CentOS6.5でDRBD8.4を使ってみる – vol.5 スプリットブレイン編1

仕組みを理解すれば怖くない「スプリットブレイン」からの復旧方法

ポイント

DRBDでのスプリットブレインについて、「スプリットブレイン概要」「初動対応方法」「復旧方法」「予防措置」などについて解説されています。

テーマ

・「スプリットブレイン」とは何か
・なぜ、スプリットブレインが発生するのか
  ・スプリットブレインが発生していないかを確認する
・スプリットブレインが発生したらまず実施すること
  ・(参考)スプリットブレインをテストとして再現する方法
・高可用性サーバとして正しい状態に戻す
  ・「他方のサーバ」のデータを破棄し、データ同期を復旧させる
・スプリットブレインを予防する方法

ページリンク

→@IT →DRBDの仕組みを学ぶ(13) →仕組みを理解すれば怖くない 「スプリットブレイン」からの復旧方法

DRBD動作(パラメータ)設定

ポイント

DRBDのパラメータ設定ファイルの各項目に関してまとめられています。

スプリットブレイン関連のパラメータについても参照できます。

テーマ

・はじめに
  ・概要
  ・環境情報
・設定ファイル
・セクション
・設定内容
  ・globalセクション
  ・handlersセクション
  ・startupセクション
  ・diskセクション
  ・netセクション
  ・syncerセクション
  ・resourceセクション
・設定サンプル

ページリンク

→Online External Strage →DRBD動作設定

DRBDのスプリットブレインの通知と自動復旧ポリシー

ポイント

DRBDユーザーズガイド内の「スプリットブレインに関する設定方法」に関して解説されている部分です。

テーマ

・5.17.1. スプリットブレインの通知
・5.17.2. スプリットブレインからの自動復旧ポリシー
  ・after-sb-0pri
  ・after-sb-1pri
  ・after-sb-2pri

ページリンク

→DRBDユーザーズガイド →5.17. スプリットブレイン時の動作の設定

スプリットブレインからの手動回復

ポイント

DRBDユーザーズガイド内の「スプリットブレインからの手動回復方法」に関して解説されている部分です。

ページリンク

→DRBDユーザーズガイド →7.3. スプリットブレインからの手動回復

クラスタ構成とは

システムの高可用性(信頼性)を実現するための仕組み「HAクラスタ構成」について紹介します。

クラスタ構成とは

「クラスタ」の本来の意味としては、「群れを成す」や「房になる」というものがあります。

IT用語における「クラスタ構成」は、複数のサーバを連携させて利用者や他のサーバから、全体で1台のサーバであるかのように動作させる技術です。

また、クラスタ構成環境を構築することを「クラスタリング(クラスタ化)」といいます。

クラスタリングの目的

大きく2つに分類できます。

(1) 拡張性(スケーラビリティ)

接続するサーバ台数を増やして、負荷分散(ロードバランサー)により、システム全体の性能向上を図る。

(2) 高可用性(アベイラビリティ)

サーバに障害が発生して1台が停止しても、システム全体としてはダウンさせずにサービスを提供し続ける。システムの信頼性を高める。

※本記事では、(2)高可用性を実現するためのクラスタリング技術を紹介します。

HAクラスタ構成とは

高可用性を目的としたクラスタ構成は、「HA(High Availability)クラスタ構成」と呼ばれます。「冗長化構成」とも呼ばれます。

最大の目的は、一部で障害が発生してもシステムを止めずに、サービスを提供し続けることにあります。

基本的に、アクティブサーバ(1台)+バックアップサーバ(1台以上)で構成され、アクティブサーバに障害が発生した場合にその障害を即座に探知して、バックアップサーバにメイン処理を移行させて、システム全体のサービスを継続します。

HAクラスタ構成におけるストレージ型

(1)共有ディスク型

アクティブサーバとバックアップサーバは、すべて1つのストレージ(ディスク)にアクセスするスタイルです。アクティブサーバからバックアップサーバに処理が移行しても、同じストレージにアクセスします。

大規模なクラスタ構成に対応できるため、データベースサーバなどに利用されます。

ただし、ストレージ側もHA化しておく必要があります。

(2)データミラー型

アクティブサーバとバックアップサーバ間で、ローカルディスクのミラーリングを行う構成です。アクティブサーバからバックアップサーバに処理が移行した場合、バックアップサーバのローカルディスクは、アクティブサーバのローカルディスクと同一になっているため、そのままサービスを継続できます。

低コストで構築できるため、小規模クラスタ構成に向いており、Web/APサーバなどに利用されています。

HAクラスタ構成 平常時の動き

平常時は、アクティブサーバ(A)(1台)がサービスを提供していて、バックアップサーバ(B)(1台以上)はスタンバイ(待機)状態です。

この時、HAクラスタリングシステムは、特に表立ったアクションは行いません。裏側で、アクティブサーバ(A)正常稼働チェック、ネットワーク正常稼働チェック、アプリケーション正常稼働チェックなど、さまざまな部分に対して監視活動を行っています。

HAクラスタ構成 障害発生時のフェイルオーバー

HAクラスタリングシステムが、アクティブサーバ(A)の障害発生を検知した場合、アクティブサーバ(A)のアプリケーションを停止、仮想IPアドレスを開放させて、アクティブサーバから降格させます。

その後、代理となるバックアップサーバ(B)に仮想IPアドレスを付与して、アプリケーションを起動、バックアップサーバ(B)をアクティブサーバに昇格させます。

※このアクティブサーバを入れ替える処理のことを、「フェイルオーバー」といいます。

仮想IPアドレスとは

仮想IPアドレスとは、他のサーバ、サービス、クライアントなどからのアクセスを受け付ける論理的なIPアドレスのことです。この仮想IPアドレスを複数のサーバ間で付け替えることで、外部からは1台のサーバであるかのように認識させ、フェイルオーバーを実現させます。

HAクラスタ構成 フェイルオーバー後の状態

フェイルオーバーの実行により、バックアップサーバから昇格したアクティブサーバ(B)がサービスを継続させます。

HAクラスタ2台構成の場合、残りのバックアップサーバが存在しない状態です。万が一、稼働中のアクティブサーバ(B)に障害が発生するとシステムダウンとなり、サービスの提供が止まってしまいます。可用性が大幅に下がってしまった状態ですので、早急にHAクラスタ構成を復旧させる必要があります。

HAクラスタ構成 復旧手順

一般的な復旧手順として、まず故障原因の解析に必要となる、対象サーバ(A)のログなどの情報収集後、サーバを停止させてクラスタ構成から切り離します。対象サーバ(A)に復旧措置を行い動作確認後、HA構成に復帰させます。

障害が発生して復旧措置を行ったサーバ(A)をバックアップサーバとして、HA構成に復帰させます。そのまま、バックアップサーバとしておくパターンもあります。バックアップサーバ(A)を手動でアクティブサーバに昇格させるパターンもあります。

※手動で、アクティブサーバとバックアップサーバを入れ替えることを、「フェイルバック」といいます。

まとめ

大規模構成ではもちろんのこと、小規模構成でもシステムの可用性と信頼性を高めるHAクラスタ構成は必要不可欠なものになってきています。HAクラスタ構成の組み方には、さまざまなパターン、さまざまなHAクラスタソリューションがあるので、システム要件に応じて適切なシステム構成を組み上げる必要があります。