デプロイメント・アーキテクチャ・オプションの理解

初期プロビジョニング時に、Oracle Content ManagementのすべてのインスタンスがOracle Cloud Infrastructureにデプロイされます。このアーキテクチャは、単一の地域内の複数の可用性ドメインにわたる高可用性トポロジです。これらの可用性ドメイン全体で、柔軟にスケーラブルなKubernetesクラスタとともにOracle Container Engine for Kubernetes (OKE)を使用します。

可用性ドメイン - 可用性ドメインは、リージョン内に配置された1つ以上のデータ・センターです。可用性ドメインは互いに分離されており、フォルト・トレラントで、同時に障害が発生する可能性が低くなります。可用性ドメインは電源や冷却、内部の可用性ドメイン・ネットワークなどの物理的なインフラストラクチャを共有しないため、1つの可用性ドメインに影響を与える障害が他の可用性ドメインに影響を与える可能性が低くなります。リージョン内の可用性ドメインは、低レイテンシ、高帯域幅ネットワークで互いに接続されています。可用性ドメイン間のこの予測可能で暗号化された相互接続では、高可用性と障害時リカバリの両方に対して構築ブロックを提供します。
フォルト・ドメイン - フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには3つのフォルト・ドメインがあります。フォルト・ドメインを使用すると、1つの可用性ドメイン内の同じ物理ハードウェア上にインスタンスが存在しないようにインスタンスを配置できます。そのため、1つのフォルト・ドメインに影響を与えるハードウェア障害またはメンテナンス・イベントは他のフォルト・ドメインのインスタンスに影響を与えません。オプションで、起動時に新規インスタンスにフォルト・ドメインを指定することも、システムがフォルト・ドメインを選択することもできます。

デフォルトのデプロイメントでは、OKEによって可用性ドメインに複数のクラスタ(またはノード)が自動的に作成されます。すべてのサイトおよびアセットは可用性ドメインごとに同期されます。 1つの可用性ドメインが停止すると、OKEによって受信トラフィックが使用可能な可用性ドメインに自動的に転送されます。このようにして、障害が発生した可用性ドメインがリストアされている間、エンド・ユーザーはサービスの停止に気付きません。

テキストで説明されている高可用性アーキテクチャの例

インスタンスがOracle Content Managementの新しいリリースを受信するタイミングを制御するには、「アップグレード・スケジュール」オプションを使用することをお薦めします。ほとんどの場合、本番トラフィックを処理するインスタンスは、「遅延アップグレード」オプションを使用する必要があります。開発やテストを目的とするインスタンスでは、「即時アップグレード」オプションを使用する必要があります。この組合せで設定することにより、コードの堅牢性を保証する完全なリリース・サイクルが実現され、問題があった場合には、それが本番トラフィックに影響を与える前に対応する時間を得られます。「アップグレード・スケジュール」オプションは、「Oracle Content Managementインスタンスの作成」の場合に設定されます。

Oracle Content Managementネイティブ障害リカバリ

Oracle Content Managementは、ネイティブの障害リカバリ製品オプションを提供します。 Oracle Content Management障害リカバリ製品機能は基本的に、Oracle Content Managementアプリケーション層、データベース、検索索引およびオブジェクト・ストレージを含むOracle Content Managementアプリケーション・スタックのすべてのレイヤーに対する包括的な障害リカバリ・フェイルオーバー機能を含むサービスのフル・スタック・オーケストレーションを提供します。

Oracle Content Managementフル・スタック障害リカバリ、フル・スタック障害リカバリ、および障害リカバリという用語は、このドキュメント全体で同じ意味で使用されます。これらの用語はすべて同じサービスを示しています。

フル・スタックの障害リカバリにより、さまざまなデータ・センター停止による包括的なビジネス継続性が保証され、リージョン全体の停止による影響を最小限に抑えることができます。

Oracle Content Management障害リカバリは、アドオン製品サービス・オプションとしてOracle Content Managementインスタンスに対して簡単に有効化できます。 Oracle Cloudコンソール操作を使用して、Oracle Content Management対応の障害リカバリ・インスタンスをアクティブに監視できます。障害リカバリ・スイッチオーバー・テストを定期的に実行することで、ビジネス継続性の準備状況およびコンプライアンスを検証および監視することもできます。

障害リカバリ図(テキストを参照)

Oracle Content Management障害リカバリの利点

Oracle Content Management障害リカバリは、ビジネス継続性の分野で複数のメリットをもたらします。

アプリケーションの完全リカバリを提供します: Oracle Content Management障害リカバリでは、データベース、検索索引、オブジェクト・ストレージ、アプリケーション層などのコンポーネントを含むアプリケーション・スタック全体のリカバリが提供されます。このフル・スタックの障害リカバリにより、いくつかのコンポーネントではなく、アプリケーション・スタック全体のリカバリに依存するビジネス継続性を実現できます。
障害リカバリ時間を最小限に抑えます: Oracle Content Management障害リカバリを使用すると、個々のリソースに対して手動で障害リカバリを実行する必要がなくなります。
特別なスキルの必要性がなくなります: オペレータおよび管理者は、アプリケーションやストレージ・レプリケーションなどの領域で特別なスキルやドメインの専門知識を必要としません。
一元的なモニタリングと管理: Oracle Content Management障害リカバリは、すべてのOracle Content Management障害リカバリが有効なインスタンスに対して、一元的なモニタリングおよび管理機能を提供します。 Oracle Cloudコンソールを使用して、障害リカバリ・インスタンスを作成し、障害リカバリの準備状況を監視し、ステータスを確認できます。

障害リカバリの用語と概念

Oracle Content Management障害リカバリを使用する前に、次の主要な用語および概念をよく理解してください。

「障害リカバリ(DR)」-停止後にビジネス・システムの一部またはすべての部分(サービス)をリストアするプロセス。このビジネス・システムのリカバリは、同じローカライズされた地理的領域内のデータ・センター間で行われます。
「フル・スタック」-ビジネス・システム、アプリケーションまたはソフトウェア・サービスのすべての機能レイヤーを総称するために使用される用語。アプリケーションは、異なる機能レイヤーまたは層(アプリケーション・レイヤー、ミドルウェア・レイヤー、データベース・レイヤー、インフラストラクチャ・レイヤーなど)で構成できます。
「リカバリ・ポイント目標(RPO)」-RPOは、DRリストアの一部として許容できるデータ損失の最大量を定義します。 RPOは通常、時間単位で表されます。
「リカバリ時間の目標(RTO)」-RTOは、サービスがリストアされるまで、DR保護下でアプリケーションまたはサービスを使用できない最大時間を定義します。 RTOは通常、時間単位で表されます。
「プライマリ」-現在使用されているアプリケーションまたはサービスの本番バージョン。障害リカバリとは、プライマリ・ロールを持つアプリケーションのプライマリ・バージョンを指します。
「スタンバイ」-アプリケーションまたはサービスの予約バージョン。スタンバイは、アプリケーションまたはサービスがリストアされる代替リージョンを示す場合にも使用されます。障害リカバリとは、アプリケーションのスタンバイ・バージョンがスタンバイ・ロールを持つことを意味します。
「ウォーム・スタンバイ」-将来のDR移行の準備のために、アプリケーションまたはサービスの一部またはすべてのコンポーネントがスタンバイ・リージョンに事前デプロイされるDRモデル。このモデルでは、運用コストは高くなりますが、RTOは低くなります。 Oracle Content Management DRサポートは、ウォーム・スタンバイ実装を使用します。
「コールド・スタンバイ」-将来のDR遷移に備えて、アプリケーションまたはサービスのコンポーネントのほとんどまたはまったくないDRモデルをスタンバイ・リージョンに事前デプロイする必要があります。アプリケーション・コンポーネントは、DR遷移の一環としてデプロイされます。このモデルでは、運用コストは低くなりますが、RTOは高くなります。
「ロール」-アプリケーションとそのリージョンが現在プライマリ(本番)バージョンかスタンバイ(予約済)バージョンかを指定します。 DR遷移の結果として、アプリケーションのロールとそのリージョンのロールが変更されます。
「関連付け」-2つのOracle Content Managementインスタンス間に定義されたペア関係。 Oracle Content Management DR対応インスタンスは、DRサービスの実装に使用する前に、プライマリおよびスタンバイ関係に関連付け(ペア・リング)されます。
「スイッチオーバー」-Oracle Content Managementの場合、これは、プライマリDRインスタンスからスタンバイDRインスタンスへのOracle Content Managementの計画的な遷移を実行するスケジュール済DRイベントです。スイッチオーバーは、プライマリ・リージョンのアプリケーション・スタックを停止し、スタンバイ・サービスをアクティブ化してアクティブになることで、順次遷移を実行します。
「フェイルオーバー」-Oracle Content Managementの場合、これは、プライマリ・リージョンでサービス停止が発生した場合に、Oracleがスタンバイ・リージョンでOracle Content Managementウォーム・スタンバイ・インスタンスをアクティブ化してフェイルオーバー遷移を実行する必要がある未スケジュール・イベントです。

フェイルオーバー・リカバリ・プロセス

Oracleは、Oracle Content Managementサービスに対してフェイルオーバーがアクティブ化されるタイミングを制御します。 Oracle Content Managementの場合、障害リカバリのパフォーマンス・ターゲットは次のとおりです:

「リカバリ時間の目標(RTO) = 1時間」-RTOは、障害発生後にアプリケーション機能をリストアするために必要なターゲット時間です。
RTOは、障害リカバリ・プロセスをアクティブ化するOracleのディシジョンから代替サイトで本番操作を再開できるまでの最大期間に対するOracleの目標です。アップグレードの処理中に障害リカバリ・プロセスをアクティブにすることをディシジョンした場合、RTOはアップグレードの完了に必要な時間を含むように拡張されます。
「リカバリ・ポイント目標(RPO) = 1時間」-RPOは、フェイルオーバー・イベント中にアプリケーションが失われる可能性がある、失われたデータのOracleのターゲット時間枠です。
データ損失の最大期間に対するOracleの目標は、最初のトランザクションが損失してからOracleの障害宣言までを測定します。 RPOは、障害発生時に進行中のデータ・ロードには適用されません。

スイッチオーバー・テスト・プロセス

Oracleを使用すると、顧客はOracle Content Management障害リカバリが有効なインスタンスのスイッチオーバーをテストできます。スイッチオーバーをテストするには、Oracle Content Managementインスタンスに対してサービス・リクエストを記録すると、Oracleサポート・チームがテストをスケジュールするために作業します。

障害リカバリの実装

障害リカバリを実装するには、Oracle Content Managementインスタンスの作成で次のオプションを選択する必要があります:

「アドバンスト・ホスティング」-「アドバンスト・ホスティング」ライセンス・オプションを有効にする必要があります。拡張ホスティングにより、Oracle Content Managementの障害リカバリ機能をサポートするために必要な専用の自律型トランザクション処理(ATP)データベースが可能になります。拡張ホスティングは、Premium EditionまたはBYOLライセンスを使用してOracle Content Managementインスタンスを作成するときに追加できるオプション機能です。このオプションには追加の請求費用があります。追加費用については、前払いサブスクリプション契約またはUniversal Credit契約を参照してください。
「障害リカバリ」-拡張オプションで、「障害リカバリ」オプションを有効にする必要があります。障害リカバリは、Premium EditionまたはBYOLライセンスを使用してOracle Content Managementインスタンスを作成するときに追加できるオプション機能です。

ノート:

「新規インスタンスのみ」-障害リカバリは、既存のインスタンスではなく、新しいインスタンスでのみ有効にできます。

障害リカバリのデータ・センター・サポート

障害リカバリのサポートは、次のOracle Content Managementデータセンターの組み合わせで使用できます。

プライマリ・リージョン	スタンバイ・リージョン
Ashburn	Phoenix
Phoenix	Ashburn
サンホセ	Phoenix
トロント	モントリオール
モントリオール	トロント
Tokyo	大阪
大阪	Tokyo
ムンバイ	ハイデラバード
ハイデラバード	ムンバイ
フランクフルト	Amsterdam
Amsterdam	フランクフルト
Seoul	春川
春川	Seoul
ドバイ	アブダビ
アブダビ	ドバイ
Sydney	メルボルン
メルボルン	Sydney
サンパウロ	ヴィニェード
ヴィニェード	サンパウロ
サンティアゴ	サンパウロ
Zurich	ストックホルム
ストックホルム	Zurich
カーディフ	London
London	カーディフ
Singapore	ハイデラバード
ジェッダ	アブダビ
ヨハネスブルグ	Jerusalem
Jerusalem	ヨハネスブルグ
ミラノ	マルセイユ
マルセイユ	ミラノ
パリ(将来)	マドリード(将来)
ネオム(将来)	ジェッダ
ケレタロ(将来)	サンティアゴ
シカゴ(将来)	Ashburn
マドリード(将来)	パリ(将来)

高可用性の拡張

高可用性サービスは長時間の稼働時間および高度なアクセシビリティを提供するように設計されていますが、さらに様々なアーキテクチャの提供を必要とする顧客が多数います。これらの追加アーキテクチャは、Oracle Cloud InfrastructureおよびOKEによってデフォルトで提供される高可用性のメリットを享受しながら、開発プロセスをサポートするように構築することも、複数リージョンのフェイルオーバーをサポートするように構築することも、プライベートの高パフォーマンス接続を使用して拡張することもできます。ニーズに適したアーキテクチャを見つけるには、組織開発プロセスのニーズ、受入れ可能なリカバリ時間目標(RTO)、リカバリ・ポイント目標(RPO)を決定する必要があります。

Oracle Cloud Infrastructure FastConnectを使用したプライベート・インスタンス

パブリック・インターネット上では実現できないパフォーマンスやセキュリティの強化を必要とするお客様もいます。 Oracle Cloud Infrastructure FastConnectを使用すると、Oracle Content Managementインスタンスへのより高性能で堅牢かつセキュアな接続を提供できます。このタイプの接続をよく使用するのは、アクセスを確実に内部ネットワークに制限する必要があるお客様や、エンド・ユーザーに可能なかぎり最善で最も信頼性の高い接続を用意する必要があるお客様です。

このようなインスタンスを作成する場合は、Oracle Cloud Infrastructure FastConnectを設定し、追加の前提条件ステップを実行する必要があります。 FastConnectには、帯域幅の大きい専用のプライベート接続と、インターネット・ベースの接続と比較してより信頼性の高い一貫性のあるネットワーク体験が用意されています。

「FastConnectを使用したプライベート・インスタンスの作成」を参照してください。

開発プロセス

これは、組織がOracle Content Managementの新しい機能とコンテンツを作成およびデプロイするために使用するプロセスを表します。これには、高度な環境および本番用に承認する前に新機能およびコンテンツが稼働する必要がある複数の環境が含まれます。共通の設定には、開発、テスト、ステージングおよび本番用の環境が含まれます。組織のニーズは変化することがあります。

複数のインスタンスを利用して開発プロセスをサポートする顧客は、このドキュメントの説明に従って追加のインスタンスをプロビジョニングする必要がありますが、直接アクセスできるように前面にWebアプリケーション・ファイアウォール(WAF)をプロビジョニングする必要はありません。インスタンスのいずれかでコンテンツを開発した後、Oracle Content Management Toolkitのコマンドライン・インタフェース(CLI)を使用して、そのコンテンツをあるOracle Content Managementインスタンスから別のインスタンスに伝播できます。

ノート:

本番トラフィックを処理しないインスタンスを追加で作成する場合は、そのインスタンスを非プライマリとマークして、複製したアセットの支払いが生じないようにする必要があります。プライマリ・インスタンスは、インスタンス内のアセットの総数に対して課金されます。プライマリ以外のインスタンスは、レプリケートされるアセットの総数に関係なく、月当たりのアセットの単一ブロックに対して課金されます(たとえば、5,000アセット。また、Video Plusがある場合は250個のVideo Plusアセット)。詳細は、Oracle PaaSおよびIaaSユニバーサル・クレジット・サービスの説明を参照してください。

変更を伝播するには、Oracle Content Management Toolkitコマンドを使用してサイトを作成し、開発、テストおよび本番インスタンスでのライフ・サイクルを管理できます。開発環境でサイトを変更し、その変更をテスト環境と本番環境に伝播できます。このコマンド行ユーティリティのセットをスクリプト環境に組み込むと、デプロイメントを管理できます。 CLIユーティリティを使用すると、アセットやコンポーネントなどの新しいアイテムのロールアウト、および既存のコンテンツの更新を実行できます。

「テストから本番(T2P)デプロイメントの設定」を参照してください。