メトロ仮想データセンター(MVDC)とは?Oracle Data Guardによるアクティブ・アクティブ構成と切替テストの完全ガイド
IT技術の進化に伴い、情報システムは通信、金融、医療、Eコマース、物流、行政など、さまざまな業界において不可欠な存在となっています。情報システムが停止すれば、経済的損失や重要データの喪失、市場におけるブランドイメージの低下など、深刻な影響が及ぶ可能性があります。そのため、情報システム構築においては「サービス継続性」が極めて重要な要素となります。現在、サービス継続性を高める一般的な手法として、本番データのコピーを保存する災害復旧(DR:Disaster Recovery)センターの構築が広く採用されています。
はじめに
従来型のDRソリューションでは、1つの本番データセンター(DC)に対して1つのDRセンターを配置するのが一般的でした。DRセンターは、本番DCで障害が発生し、短時間での修復が不可能なサービス停止が起きた場合にのみアクセスを提供する待機系として機能します。このような従来型アーキテクチャには、以下のような課題があります。
本番センターで停電、火災、洪水、地震などの災害が発生した場合、手動操作によってDRセンターへサービスを切り替える必要があり、専門的な復旧作業とデバッグも求められます。これらの災害は長期にわたるサービス中断とサービス継続性の欠如を招く恐れがあります。
DRセンターは通常サービスを提供せず、ほとんどの時間アイドル状態であるため、リソース利用率が低下します。
こうした課題を受け、Oracle®はエンドツーエンドのアクティブ・アクティブDCソリューションを発表しました。このソリューションでは、2つのDCが同時に稼働し、サービス負荷を分担することで、全体のサービス能力とリソース利用率を向上させます。また、機器障害や片側DC障害が発生した場合でも、サービスを意識することなく自動フェイルオーバーを実現します。さらに、リカバリポイント目標(RPO)ゼロおよびリカバリ時間目標(RTO)ゼロという特長を備えています。なお、RTOはアプリケーションシステムやデプロイ方式に依存します。
現在のストレージ業界には、主に以下の2つの可用性モードが存在します。
- アクティブ・パッシブ(AP)/ アクティブ・スタンバイ
- アクティブ・アクティブ(AA)/ メトロ仮想データセンター(MVDC)
データベース層の重要コンポーネント
データベース(DB)は、データ損失ゼロのオプションを備えたアクティブ・スタンバイ構成でセットアップする必要があります。以下の項目が重要なコンポーネントとなります。
- Oracle Data Guard Broker:Data Guard構成の自動化と一元管理を行い、複雑なロール変更を単一のコマンドで実行できるようにします。
- Flashback Database(フラッシュバック・データベース):DBの巻き戻し(リバート)機能を提供し、フラッシュバックログ情報を高速リカバリ領域に格納します。
- Fast-Start Failover(FSFO):データ損失ゼロでのフェイルオーバーを可能にします。スタンバイDBがプライマリDBと同期している場合にのみトリガーされます。
- Observer(オブザーバー):Data Guardコマンドラインインターフェース
dgmgrlに組み込まれた独立したプロセスで、障害発生の可能性がないか、プライマリDBとスタンバイDBの状態を常時監視します。
Data Guard構成
次の図はData Guardの構成を示しています。
画像出典:https://neeraj-dba.blogspot.com/2011/10/dataguard-broker-and-its-benefits_05.html
プライマリDB側では、Log Writer(LGWR)プロセスがREDOデータを1つ以上のLog Network Server(LNSn)プロセスに送信し、LNSnが複数のリモート宛先へ並列にネットワークI/Oを開始します。すべてのLGWR SYNC宛先でトランザクションのリカバリに必要なREDOデータが受信されるまで、プライマリデータベース上でトランザクションはコミットされません。
スタンバイDB側では、Remote File Server(RFS)がネットワーク経由でLGWRプロセスからREDOデータを受信し、スタンバイREDOログファイルに書き込みます。
最大可用性アーキテクチャ
最大可用性を実現するアーキテクチャを設計する際には、ダウンタイムの発生原因を把握するとともに、計画外ダウンタイムと計画ダウンタイムを分類して考える必要があります。
計画外ダウンタイムには、以下の予期しない中断が含まれます。
サーバー可用性:DBサーバーをホストする1台以上のマシンがハードウェアまたはソフトウェアの障害により予期せず停止しても、DBサービスへのアクセスを中断させないことが求められます。Oracle Real Application Clusters(RAC)は、この種の障害に対して最も効果的な保護を提供します。
データ可用性:ビジネスクリティカルなデータの喪失、破損などのデータ障害を軽減するため、常にデータへアクセスできる体制を計画に盛り込む必要があります。
計画ダウンタイムには、以下のようなスケジュールされたアクセス中断が含まれます。
- システム変更
- データ変更
- アプリケーション変更
MVDCにおけるスイッチオーバーテストのシナリオ
スイッチオーバーとは、Data Guard構成内のプライマリDBとスタンバイDBが役割を入れ替える、制御された計画的なロール反転操作です。スイッチオーバー後も、各データベースは新しい役割でData Guard構成に参加し続けます。
スイッチオーバーのプロセス
スイッチオーバーは以下の順序で実行されます。
- 元のプライマリDBがスタンバイロールへ切り替わります。
- 元のスタンバイDBがプライマリロールへ移行します。
スイッチオーバー実行時、Data Guard Brokerは以下の処理を自動的に行います。
- プライマリDBとターゲットのスタンバイDBがオンラインであり、エラーがないことを検証します。
- プライマリDBとスタンバイDBの両方について、RAC構成内のインスタンスを1つ残してすべてシャットダウンします。
- プライマリDBとスタンバイDBのロールを切り替えます。Brokerはまず元のプライマリDBをスタンバイロールで稼働するよう変換し、次にターゲットのスタンバイDBをプライマリロールへ移行します。あわせてBroker構成ファイルを更新してロール変更を記録し、再起動後も各DBが正しいロールで稼働するようにします。
- 新しいスタンバイDB(元のプライマリ)を再起動し、Redo Applyプロセスを開始して新しいプライマリDBからのREDOデータを適用します。RAC DBの場合、Brokerはスイッチオーバー前にシャットダウンしたインスタンスを再起動します。
- 新しいプライマリDBを再起動してオープンし、REDO転送サービスを開始してスタンバイDBへREDOデータを送信します。RAC DBの場合、Brokerはスイッチオーバー前にシャットダウンしたインスタンスを再起動します。
スイッチオーバー前の状態:
画像出典:https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615
スイッチオーバー後の状態:
画像出典:https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615
スイッチオーバーの実施手順
スイッチオーバーを実施するには、以下の手順に従います。
アプリケーションが完全に停止していること、およびユーザーがデータベースに接続していないことを確認します。
スイッチオーバー開始の少なくとも30分前に、両DCで稼働中のアーカイブUTLスクリプトを無効化します。テスト完了後にDBが優先ロケーションで稼働していることを確認したら、アーカイブユーティリティスクリプトのコメントを解除します。
現在のプライマリDBで以下のSQLクエリを実行します。
SELECT * FROM DBA_JOBS_RUNNING; (sys所有のジョブが実行されていないこと) SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED FROM DBA_SCHEDULER_JOBS WHERE ENABLED='TRUE' AND OWNER <> 'SYS'; (Data Guard Brokerはsys所有のジョブを強制終了しないため)job_queue_processesとaq_tm_processesを0に設定します。スイッチオーバーテスト完了後に元の値へ戻す必要があるため、必ず元の値を記録しておいてください。プライマリDB上で稼働している
emagentを停止します。現在のプライマリDBで以下のSQLクエリを実行します。
SELECT sid, username, status, program, inst_id FROM gv$session WHERE username is not null and status='ACTIVE' order by inst_id; (アクティブな接続数を検証・確認する。アクティブ接続が多いと スイッチオーバーに要する時間が長くなる可能性がある)sysとして接続しているすべてのsqlplusセッションからログアウトします。現在のプライマリDBで以下のSQLクエリを実行します。
set linesize to 132 col value format a35 SELECT inst_id,name,value from gv$parameter WHERE name in ('job_queue_processes','aq_tm_processes'); (job_queue_processesとaq_tm_processesの値がゼロになっていることを確認)以下のコマンドを実行してData Guard構成を検証します。
DGMGRL> show configuration verbose ** STATUS が success と表示されること。success 以外の場合は先に進めない。Cluster Ready Services(CRS)のステータスを確認し、すべてのリソースがオンライン登録されていることを確認します。このプロセスでは、DBのマウントとシャットダウンがCRSに引き渡されるためです。
プライマリDB上で数個のログをスイッチオーバーし、それらがスタンバイDBに適用されたことを確認します。
本番前に一度スイッチオーバーを実行し、DRCログとアラートログに障害がないか監視します。以下のコマンドにより、旧プライマリがスタンバイへ変換され、その後旧スタンバイがプライマリへ変換されます。
DGMGRL> switchover to 'DDMPROD_STANDBY';スイッチオーバー完了後、ログ転送サービスとログ適用サービスが正常に稼働していることを確認します。
MVDCにおけるフェイルオーバーテストのシナリオ
フェイルオーバーとは、プライマリDB(RACプライマリDBの場合は全インスタンス)に障害が発生し、スタンバイDBがプライマリロールを引き継ぐことです。フェイルオーバーは以下のようなケースで実行されます。
- プライマリDBに壊滅的な障害が発生し、短期間でのプライマリDBの復旧が不可能な場合。
- オブザーバーとスタンバイDBの双方がプライマリDBとのネットワーク接続を失い、かつスタンバイDBが同期済み状態であることが確認された場合。
フェイルオーバーのシナリオ
以下のDB状態がファストスタート・フェイルオーバーのトリガーとなります。
- プライマリサイトの障害
- 以下を含むプライマリDBの状態:
- インスタンス障害
- 最後の生存インスタンスの障害(RACの場合)
- 最後の利用可能なインスタンスのshutdown abort
- I/Oエラーによるデータファイルのオフライン化(オフラインデータファイルによるフェイルオーバー実行時はしきい値が無視されます)
ネットワーク関連の条件については、プライマリとオブザーバー間、およびプライマリとターゲットのスタンバイDB間のリンクが双方ともダウンした場合にのみ、フェイルオーバーの原因となり得ます。オブザーバーが構成が同期状態にあることを確認できるよう、オブザーバーとスタンバイDB間の接続は必須です。
画像出典:https://docs.oracle.com/cd/E11882_01/server.112/e41134/role_management.htm#SBYDB00615
まとめ
MVDC(メトロ仮想データセンター)は、効率的なリソース利用、ロードバランシング、高可用性、そして2つのDC間の自動切替を実現します。両DCは同時に稼働(アクティブ・アクティブ)してサービス負荷を分担し、全体のサービス能力を向上させます。また、災害復旧のためのフェイルオーバーやアップグレード・メンテナンス時の切替において、必要な人手による介入を大幅に削減できます。
ご意見やご質問がある場合は、フィードバックタブをご利用ください。
専門家による管理・運用・構成で環境を最適化
Rackspaceのアプリケーションサービス(RAS)の専門家は、幅広いアプリケーションポートフォリオにわたって、以下のようなプロフェッショナルサービスおよびマネージドサービスを提供しています。
-
>eCommerceおよびデジタルエクスペリエンスプラットフォーム
- 企業資源計画(ERP)
- ビジネスインテリジェンス(BI)
- Salesforce顧客関係管理(CRM)
- データベース
- メールホスティングと生産性向上ツール
私たちが提供する価値:
- 偏りのない専門知識:モダナイゼーションの道のりを簡素化し、即座に価値をもたらす機能に焦点を当ててご案内します。
- Fanatical Experience™:「プロセス・ファースト、テクノロジー・セカンド®」のアプローチと専任のテクニカルサポートを組み合わせ、包括的なソリューションを提供します。
- 比類のないポートフォリオ:豊富なクラウド経験を活かし、適切なクラウド上に最適なテクノロジーを選定・デプロイできるよう支援します。
- アジャイルなデリバリー:お客様の状況に合わせて伴走し、私たちの成功をお客様の成功と共に実現します。
今すぐチャットでご相談ください。
-
iCloudデータ復旧サービスとは?iPhone・iPad・Macでの設定方法をわかりやすく解説
iCloudのデータにアクセスできなくなってしまうのは、誰にとっても悪夢のような事態です。しかしiOS 15以降、Appleは「iCloudデータ復旧サービス(iCloud Data Recovery Service)」という新機能を搭載し、最悪の事態が起きた際にも一部のデータを取り戻せるようになりました。iPhoneやMacでも簡単に設定できるため、今のうちに準備しておけば、いざというときにきっと自分を救うことになります。 iCloudデータ復旧サービスとは何か iCloudデータ復旧サービスは、iCloudのセキュリティ機能の一つで、写真、メモ、書類、デバイスのバックアップなど、暗
-
データセンターにフラッシュストレージが必要な理由|性能・耐久性・コストを徹底解説
技術と時代の変化とともに、データを保存するためのさまざまな手段が登場してきました。初期にはフロッピーディスクが使われ、その後はCDやDVDでメディアを書き込むのが一般的になりました。しかし現在、これらのデバイスは急速に姿を消しつつあります。最新ノートパソコンをはじめとする主流デバイスの多くには、もはや内蔵のCD/DVDドライブすら搭載されていません。 市場の話題や世間の声によれば、近い将来、世界のすべてのデータはクラウドに保存されることになるといわれています。しかしこれは完全に正しいとは言えません。企業はクラウドが提供する以上のコントロールをデータに対して求めており、重要なデータ要素を自社の手