コーソルDatabaseエンジニアのブログ
技術ブログ
目次
渡部です。7月22日に実施した3社共催ウェビナーで渡部が担当したDbvisit Standbyセッションの骨子と、頂戴した質問への回答をまとめておきます。本セッションが、Amazon EC2でのOracle SE2活用に役立てば幸いです。
AWSを用いたシステムで高い可用性を実現するには、AZ(Availability Zone)を理解し、適切に活用する必要があります。
AZは平たく言うと、データセンターに相当する概念です。 AWSは1つのリージョン（地域、東京など）に複数のAZを用意しています。
AWS上で高可用性システムを構築するには、複数のAZを用いた構成にする必要があります。これをMulti-AZ構成（マルチAZ構成）と呼びます。 Multi-AZ構成にすると、データセンターレベルの障害に耐えられる、高可用性システムを構築できます。
逆に言うと、1つのAZだけを使用して構築したシステム、すなわち、Single AZ構成ではデータセンターレベルの障害(AZレベルの障害）に耐えられません。データセンターレベルの障害が発生すると、システムが停止することになります。
とはいえ、AWSは実績ある高品質のパブリッククラウドサービスですから、そうそうデータセンターレベルの障害は発生しません。しかし、ごくまれにデータセンターレベルの障害が発生することがあります。 これが顕在化したのが、2019年8月23日 AWS東京リージョン障害です。
2019年8月23日に発生したAWS東京リージョン障害については、以下のURLで公式にレポートされています。
日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。
このようなAZレベル（データセンターレベル）の障害を回避するベストプラクティスは、システムをマルチAZ構成で構築することです。上記レポートでも以下の様にまとめられています。
複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨します
なお、複雑なシステム故、細かいレベルではいくつかの例外があったようですが、基本的な対処原則は上記から変わるところはないと考えています。すなわち、「高可用性を求めるシステムでは、マルチAZ構成を取るべき」ということです。
お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響（…）があったことを AWS では確認しております。
AWSでOracle Databaseを使用するには、RDS for Oracleを使用する方法と、EC2にOracleを導入して使用する方法の2つがあります。
RDS for Oracleを使用する場合、マルチAZの構成は非常に簡単です。単に「マルチAZ 配置」にチェックを入れるだけです。
RDS for Oracleは、管理コストを大きく抑えることができる優れたサービスです。しかし、いくつかの制限があるため、すべてのシステムでRDS for Oracleが使用できるわけではありません。RDS for Oracleを使用できない場合は、EC2にOracleを導入する方法を取らざるを得ません。
Oracle Database Enteprirse Editionであれば、Data Guardを利用可能ですので、この機能を用いてマルチAZ構成を実現できます。本番DBをAZ#1に配置し、待機DBをAZ#2に配置して、Data Guardを構成すればOKです。
しかし、Oracle Database Standard Edition 2では、Data Guardを使用できません。Data GuardはOracle Database Enteprirse Edition限定の機能だからです。Oracle SE2の場合、Data Guardの代替として、弊社で販売・導入・サポートを行っているDbvisit Standbyを使用します。
災害対策を主な目的に、Oracle Database → Oracle Databaseという構成のData Guardに類似した物理レプリケーションを実現する製品です。
Dbvisit
Dbvisit Standbyは、2006年から14年間以上開発とバージョンアップを継続し、世界110ヵ国以上、1,300以上の導入実績を誇る信頼できる製品です。
コーソルでは、以下のような点にお困りのお客様にDbvisit Standbyをお勧めしています。
Dbvisit Standbyには、各種タスクをGUIで実行できるWeb管理コンソールが用意されています。
以下はトップ画面ですが、タスクに対応するメニューが分かりやすく配置されており、 簡単なレクチャーを受けた程度の知識で運用が可能です。 また、Dbvisit 9からは画面が日本語化されているため、より使いやすくなっています。
あまり望ましい事態ではありませんが ;-P データベースやデータセンターに障害が発生したときは、「障害回復アクション」を選択すると簡単に本番DBの切り替えを実行できます。
Dbvisit Standbyは幅広いOSバージョン、Oracle Databaseバージョンに対応しています。
特に、Oracle Database 10g R2をはじめとする古いOracle Databaseバージョンに対応している点は、非常に助かる点です。実務的には、古いOracle Databaseバージョンをどうしても使わざるをいけない状況が発生しますから。
Dbvisit Standbyを用いてEC2上でOracle DatabaseのマルチAZ構成を実現するのは簡単です。 基本的にオンプレミス環境と同等の手順で構築できます。
GUI操作で、待機データベースの作成が可能な点に注意してください。手動でデータベース複製を実行する必要がないため、非常に簡単に待機データベースを作成できます。
データベースやデータセンターに障害が発生したときは、Web管理コンソールから 「障害回復アクション」を選択して、待機データベースを本番データベースに昇格できます（フェイルオーバー）。
すでに書いた通り、Dbvisit Standbyは、2006年から14年間以上開発とバージョンアップを継続し、世界110ヵ国以上、1,300以上の導入実績を誇る信頼できる製品です。
当然ながら、Amazon EC2でも多くの導入実績があります。紹介できる事例を以下に記載します。
なお、公開はできませんが、日本でもAmazon EC2上の多くの導入実績があります。
待機系DBを災害対策以外の用途に活用することができると、費用対効果を高めることができます。 Dbvisit Standbyはversion 9から待機系DBを災害対策以外の用途に活用するための、以下の機能を拡充しました。
なお、上記以外のDbvisit Standby version 9新機能については、以下の記事をご覧ください。
【祝】Dbvisit 9 日本リリース！＋さっそく新機能を紹介
Dbvisit Standby Snapshot Option – Dbvisit 9新機能
本セッションでは、本番系および待機系の両方をクラウドにLift upする構成についてご説明しましたが、様々な理由で本番系をクラウドに移行するのが難しい場合があるかと思います。 その場合でも、待機系をクラウドを配置するいわゆる「クラウドDR」をご検討ください。
導入時点のコスト削減という、クラウドの利点を享受できます。
将来的なクラウド完全以降の第一ステップとしての、クラウド利用と位置づけることもできます。
最近、バージョンを変えずにOracle Databaseを移行するパターンが増えて来たようです。 Dbvisitは同一バージョン間での物理レプリケーション技術を基礎にしていますので、Oracleバージョンを変えない環境移行を支援するツールとして活用できます。
誤解を招かぬよう補足しておくと、Oracleバージョンを変えない環境移行には、必ずしもツールは必要ありません。しかし、Dbvisitを活用すると、作業コスト（移行作業そのものの作業工数、事前検証の工数など）を大幅に削減できます。信頼できるスキルを持つOracleエンジニアを探して仕事をお願いするコストを削減できます（「現場」的には、実はコレが一番インパクトが大きいかも・・・）。
セミナー中およびアンケートで頂戴した質問への回答を以下にまとめます。参考になれば幸いです。
はい、その通りです。DbvisitのスタンバイDBは通常運用時はMOUNTモードで起動しています。そして、プライマリDBからアーカイブログファイルが転送されたら、内部的にRECOVER STANDBY DATABASEコマンドを実行し、アーカイブログファイルをスタンバイDBに適用します。
はい、いくつかの方法で使用できます。
1つ目の方法は、スタンバイDBを読み取り専用でOPENする方法です。OPEN中はアーカイブログファイルの適用が停止しますが、MOUNTモードで再起動すると、アーカイブログファイルの適用を再開できます。
2つ目の方法は、有償のSnapshotオプションを使用して、スタンバイDBの複製データベースを作成する方法です。
Dbvisit Standby Snapshot Option – Dbvisit 9新機能
Dbvisit Standbyでデータを同期する仕組みは、プライマリDBからスタンバイDBにアーカイブログファイルを転送し、スタンバイDBでアーカイブログファイルを適用する（ロールフォワード）ものです。
このため、当然ですが、プライマリDBはアーカイブログモードで運用する必要があります。
なお、データ同期に先立ち、スタンバイDBを作成する必要がありますが、これはDbvisitの管理コンソールからGUI操作で簡単に実行可能です。このとき、内部的にはRMANでプライマリDBのバックアップが取得され、バックアップファイルがスタンバイホストに転送＋リストアされています。
両社はともにデータベースレプリケーション製品ですが、基礎とするレプリケーション技術の種類が異なります。
Dbvisit Standbyは物理レプリケーション技術を基礎とするデータベースレプリケーション製品です。物理的に同一の構成の複製データベースを作成する技術です。主に、災害対策用途などで使用されます。 オラクル製品で言うと、Dbvisit Standbyは、Oracle Data Guardに相当するものです。
Oracle GoldenGateは論理レプリケーション技術を基礎とするデータベースレプリケーション製品です。 データベースの一部のデータだけをレプリケーションすることが可能で、主に複数データベース間のデータ連携、または、データベースのバージョンアップを伴う移行作業で使用されます。
Oracle Databaseのレプリケーションについては、以下の記事も参考にしてください。
Oracle Databaseレプリケーションとサポート状況／対応製品
はい、対応しています。
Oracle Database Standard Edition いわゆるHAクラスターに相当するソリューションは、Oracle SEHAまたはSIOS様 LifeKeeper、NEC様CLUSTERPROなどの3rdパーティ製クラスタウェアを用いたActive-Standby HA構成になります。
弊社では、HAクラスタ構成は、同一拠点内のノード障害に備えるソリューションと位置付けています。すなわち、あるデータセンター内の1つのデータベースサーバーが破損しても、サービスを継続できるようにするソリューションです。
一方、Dbvisit StandbyはOracle Data Guardに相当するソリュ―ションで、拠点レベルの障害に備えるものと位置付けています。すなわち、あるデータセンターが破損しても、別のデータセンターでサービスを継続できるようにするソリューションです。このソリューションを用いた構成は一般にDR構成(Disaster Recovery構成)と呼ばれます。
ですので、頂戴した質問への回答としては、「Dbvisit Standby はHAクラスターに相当するソリューションではなく、HAクラスタ構成では対処が難しい、拠点レベルの障害に対応できるソリューションである。」となります。
HA構成とDR構成については、以下の記事も参考にしてください。
データベース高可用性 – HA構成とDR構成
Dbvisit StandbyはOracle Data Guardに相当し、拠点レベルの障害に備えるソリュ―ションです。このソリューションを用いた構成は一般にDR構成(Disaster Recovery構成)と呼ばれます。
一方、Oracle SEHAはいわゆるHAクラスタ構成に相当し、同一拠点内のノード障害に備えるソリューションです。このソリューションを用いた構成は一般にHA構成(High Availability構成)と呼ばれます。
1つ前の質問への回答もあわせてご覧ください。
Oracle Database Enterprise Editionは優れた製品ですが、Oracle Database Standard Editionよりもライセンス費用が大幅に高いです。
Oracle Database Standard EditionでDbvisit Standbyを使用することで、災害対策を実現しつつ、ライセンス費用の大幅な削減を実現できます。
Oracle Database Enterprise EditionとOracle Database Standard Editionのライセンス費用の比較については、弊社過去発表資料もあわせてご覧ください。
db tech showcase Tokyo 2019 Oracle SE2 強化セッション 発表骨子と資料の公開 #dbts2019
以下をご覧ください。
なお、Dbvisit Standbyは、2006年から14年間以上開発とバージョンアップを継続し、世界110ヵ国以上、1,300以上の導入実績を誇る信頼できる製品です。安心して導入をご検討ください。
コーソルはDbvisit Standbyの一次代理店で、Dbvisit Standbyの製品販売を行います。
コーソルからDbvisit Standbyを購入いただけると、ORACLE MASTER Platinum 累計取得者数4年連続No.1(2016年度,2017年度,2018年度,2019年度)という指標に裏付けされた高いOracle Databaseの技術力により、安心して製品を導入いただけます。また、導入後も製品サポートをご提供いたします。
累計V4 / 単年V6！ ORACLE MASTER Platinum 2部門でOracle Certification Award 2019を1位受賞しました！
3年連続！ ORACLE MASTER Platinum 2部門でOracle Certification Award 2018を1位受賞しました！
ORACLE MASTER Platinum部門を含む3部門でOracle Certification Award 2017を1位受賞しました！
ORACLE MASTER Platinum部門を含む3部門でOracle Certification Award 2016を1位受賞しました！
ORACLE MASTER Platinumとは、2日間にわたる実技試験により認定されるOracle Database最高難度の資格です。 であること。全世界的に有効で、海外では、"Oracle Certified Master"と呼ばれます。
ORACLE MASTER Platinumとは何か / コーソルはPlatinum取得者数No.1!
Dbvisit Standbyと併せて使用される、Oracle Databaseについても製品販売、製品サポート、製品の導入を行います。また、リモート回線経由でスポット的なDBA実務を行うリモートDBAサービス、コンサルティングやベンダコントロールを含めたOracle Databaseプロフェッショナルサービスを時間制で提供する時間制DBAサービスも提供しています。
リモートDBAサービス
渡部 亮太
・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数
2024年
2023年
2022年
2021年
2020年
2019年
2018年
2017年
2016年
2015年
2014年
2013年
2012年
2000年