19
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

オラクルへのクラウド移行検討 第6回 〜Exadataシステムの高可用性は身構えなくても大丈夫〜

Last updated at Posted at 2023-05-12

OCLS(Oracle Cloud Lift Service)を利用して移行検討・検証した内容を、お伝えできる範囲で提供していきます![^1]

今回のユースケースは・・・・

オンプレミスで稼働している Exadata を Oracle Cloud Infrastructure(以降 OCI)で稼働させた場合に高可用性を担保する構成を検討したケースです。

検討のポイント!!

検証を行うために東京 - 大阪リージョンのマルチリージョン構成でOracle Exadata Database Service on Dedicated Infrastructure(以降、ExaDB-D)のDR環境を構築しました。
※ExaDB-Dは、Oracle Exadata Cloud Service(ExaCS)から名前が変更されました。

image.png

今回、クラウド移行に伴う検討ポイントとしては以下を検討しました。
本記事ではDR構成について、重点的に取り扱います。

DR構成の考慮
・SI費用の削減
・OCIを初めて利用
・システム変更なく、安心・安全なシステム移行の実現

1.クラウドの検討理由とOCLS利用の背景について

クラウドへの移行期間に余裕がなく、本番移行に向けて要件や構成を急ぎ決めなければならないという背景がありました。
今回PoCを早期にスタートさせて移行実現性の検証と移行計画を具体化していく必要があり、また初めてOCIを利用するため、OCIのスキルを補うためにOCLSのPoC支援を活用いただきました。
他社クラウドは経験があるものの初めてOCIをご利用いただくというお客様はいらっしゃるのではないでしょうか。

2. 高可用性構成の「型」があります! - MAA

DR構成による可用性の担保の仕方については、どのように災害対策されるのかに依存すると考えています。
例えば、定期メンテナンスや機器障害対策の場合は東京リージョンのみで構成するケース、OCIリージョン障害対策の場合は東京 - 大阪リージョンのマルチリージョン構成とするケース、広域災害対策の場合は東京、もしくは大阪の別拠点のデータセンターを経由してOCIのリソースにアクセスするケース等、システムの重要度および求められる要件に応じてDR構成を検討する上で様々な構成が考えられます。

image.png

なお、このクラウドの構成は以下のOracle Maximum Availability Architecture(Oracle MAA)のRTO/RPOを考慮した時のリファレンス・アーキテクチャです。
Oracle MAAのレベルとしては、ケース1がSILVER、ケース2,ケース3がGOLD、ケース4がPLATINUMになります。

image.png

3. 簡単に構成できる技術! - Active Data Guard

高可用性構成のソリューションとして、OCIではActive Data Guardを提供しています。
こちらはプライマリデータベースの更新情報(REDOログ)をスタンバイデータベースに転送することで複製されたデータべースを参照可能な状態で構成することができます。
この機能を利用することにより、データベース障害やリージョン障害などのRTO/RPOを短くすることが可能で、また計画停止(メンテナンス等)における切り替えも停止時間を極小化できます。
OCIのExaDB-DのエディションはExtream Perfomaneになるため、追加費用負担がなくActive Data Guardを利用可能で、ExaDB-D及びActive Data GuardのどちらもOCIの管理コンソールから設定できるので、事前に設定項目を決めておけば、OCIの経験が無い方でも簡単に構成が可能です。

image.png
image.png

4. 設定ステップがシンプル! - OCIコンソール

OCIコンソールからActive Data Guardを構成するまでのおおまかな手順は2ステップのみで、対象のデータベースの「Data Guardの有効化」をクリックし、必要な設定項目を入力するだけで構成されます。
ハマりポイントや詳細な手順については、参考文献にも記載している「Data Guardを構成しよう」をご参照ください。

Data Guard構成時のハマりポイント:
プライマリとスタンバイの一意のデータベース名(DB_UNIQUE_NAME)はそれぞれ異なる必要ありますので注意しましょう。

ExaDB-DでData Guardを使用するための前提条件として、2つの既存のExadata VMクラスタが必要で、1つはData Guardによって複製される既存のデータベースを含み、もう1つはData Guardによって新しいスタンバイデータベースを格納します。
Data Guardを有効にする場合、スタンバイ側で新しいデータベースホームを作成して、Data Guardの有効化操作中に新しいスタンバイ・データベースを格納するか、既存のデータベースホームにスタンバイデータベースを構成することも可能です。

5.最後に

今回は、ExaDB-DのDR構成として、以下ケース2の東京 - 大阪リージョンのマルチリージョン構成としましたが、Actve Data Guardはスタンバイデータベースを参照可能な状態で構成されるので実際にはアクティブ/アクティブ構成となります。
Data Guardによる高可用性構成を組んだことが無い方でもOCIの管理コンソールからActve Data Guardを簡単に構成することができるようになっています。

image.png

また、上記にも記載しましたが、DR構成による可用性の担保の仕方については、どのように災害対策されるのかに依存するため、システム要件に合うDR構成を検討及び構成いただく際の参考になれば幸いです。
また、OCIリージョン間のインフラストラクチャ、プラットフォームおよびアプリケーションの切り替えを簡単にできるFull Stack Disaster Recoveryのソリューションが提供されているので、別の機会でご紹介できればと思います。

6.参考文献

●ExaDB-D
Exadata Database Cloud (Exadata Cloud Service) サービス技術詳細

●ディザスタ・リカバリ
Data Guardを構成しよう
BaseDB / ExaDB-D(ExaCS)におけるData Guard解説
Exadata Cloud InfrastructureでOracle Data Guardを使用するための前提条件
Oracle Exadata Database Service: 手動コマンドで Active Data Guard を構成してみてみた
Full Stack Disaster Recovery

●MAA
Oracle CloudのMAAベスト・プラクティス

19
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?