対応するOS[1]を以下に示します。
-
Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019
-
Oracle Linux 7.6
適用指針
2023年11月09日
本ドキュメントではOVM適用指針について記載しています。
OVMサービス (以下、本サービスと言います)は、富士通クラウドテクノロジーズが構築した、Oracle DatabaseライセンスのBYOL( Bring Your Own License )が可能なIaaS環境です。
本サービスの利用者は、Oracle Databaseライセンスを持ち込むことができるサーバー(以降、サーバーと言い、物理サーバーとは区別して説明します)を所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。
本サービス環境は、パブリック等のニフクラ環境とは異なる仮想化基盤 (OracleVM/Oracle Linux Virtualization) を用いて、構築・運用されています。
利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。よって、個別の要望には対応はできません。
システム要件によってはOVM適用(移行)不可となる場合があるため、サービス仕様書及び、本ドキュメントを最後まで確認のうえ、適用可否を判断してください。
ニフクラサービスの変更は最新のドキュメントを参照してください。
ニフクラOVM基盤環境更新が予定されています。詳細は こちらを確認してください。
本ドキュメント構成図に使用されているアイコンは下記のとおりとなります。
リージョン及びゾーンについて特に記載がなければ、単一リージョン、単一ゾーン構成を示します。
OVMの適用可否を判断するために、以下手順を確認してください。
OVMで対応できない要件
OVMで対応ができない利用者要件や条件などを確認し、適用可否を判断する
OVMの適用判断事項
利用者要件に対応するOVMサービス仕様を確認し、必要となる対処、影響等を検討したうえで、適用可否を判断する
提供サーバーOS及びサーバータイプの検討
提供サーバーOS及びサーバータイプの選択指針から、利用するサーバーを選択する
対応Oracle DBバージョンから選択する
ニフクラとの連係方法の検討
システムパターンと運用方式の検討
可用性・業務継続性からシステムパターンを選択する
サービス利用上の注意点から運用方式を検討する
Appendix
OVMを適用できない主な条件を示します。以下の不適合条件に合致する要件がある場合、他のクラウドやオンプレミスを検討してください。
不適合条件 |
理由 |
|
---|---|---|
SLA |
クラウドサービスが定義しているSLAとして、月間稼働率99.99%をこえるSLA提供が必要 |
OVMは、SLA対象外となります。 |
移行性 |
特定のグローバルIPアドレスが必要 |
OVMのサーバーは、グローバルIPアドレスは付与されません。 |
OracleVMサポート外のOS移行が必要 |
OracleVMでサポートされているOS以外をOVMに構築できません。 |
|
OVF+VMDKなどのイメージ移行が必要 |
OVMでは、VMインポート機能は提供していません。 |
OVMを適用できない主な条件を示します。以下の不適合条件に合致する要求がある場合、他のクラウドやオンプレミスの検討してください。
不適合条件 |
理由 |
|
---|---|---|
動作環境 |
物理機器の利用が必要 |
プリンタ・FAX・スキャナ・テープデバイスなどの物理機器をOVMで利用できません。 |
システム要件として高性能なCPUスペックが必要 |
提供されているvCPU以外を利用できません。 また、GPU搭載モデルのサーバータイプも未提供となります。 |
|
提供されていないOSが必要 |
||
ミドルウェアの動作保証が必要 (ミドルウェアの製品指定がある商談など) |
ミドルウェアのサポート可否や動作実績、ライセンスの考え方などについては、それぞれのミドルウェア販売元への確認が必要です。また、ミドルウェアを導入する場合は、事前検証や導入作業を、プロジェクト責任で実施してください。(OVM側で環境変更などの個別対応はできません。) |
|
複数NICが必要 |
||
厳密なレスポンスタイムが要求されるシステム |
||
インフラ基盤に対する厳格な動作要件をもつシステム |
インフラ基盤に特別な設定が必要となるシステムは、OVM上では稼働できない可能性があります。 |
|
サポート |
OS等のインフラ基盤より上位層について、OVMに対応していないサポート契約が必要 |
OVMではOS層以上のサポートについては下記のとおりです。[4] |
利用者の要件に対応するOVMサービス仕様(①)を確認し、利用者側で必要となる対処(②)、影響等(③)を検討したうえで、OVM適用可否を判断します。
No. |
要件 |
OVMの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
1.1 |
可用性 |
継続性 |
運用スケジュール |
|
1.2 |
稼働率 |
|
||
1.3 |
耐障害性 |
ネットワーク |
|
|
1.4 |
ストレージ |
|
||
1.5 |
災害対策(DR) |
|
No. |
要件 |
OVMの仕様 |
選択値・条件 |
||
---|---|---|---|---|---|
大項目 |
中項目 |
小項目 |
|||
2.1 |
性能・拡張性 |
リソース拡張性 |
vCPU |
|
|
2.2 |
メモリ |
|
|||
2.3 |
ストレージ |
|
|
||
2.4 |
性能・拡張性 |
リソース拡張性 |
スケールアップ |
|
スケールアウト |
No. |
要件 |
OVMの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
3.1 |
運用・保守性 |
通常運用 |
バックアップ |
ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】となります。 [8]
|
3.2 |
運用監視 |
|
||
3.3 |
保守運用 |
計画停止 |
|
|
3.4 |
HA発生時 |
|
||
3.5 |
パッチ適用 |
|
||
3.6 |
運用環境 |
開発用環境の設置 |
|
|
3.7 |
試験用環境の設置 |
|
||
3.8 |
サポート体制 |
|
No. |
要件 |
OVMの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
4.1 |
セキュリティ |
アクセス・利用制限 |
認証機能 |
|
4.2 |
利用制限 |
|
||
4.3 |
データの秘匿 |
伝送データの暗号化の有無 |
|
|
4.4 |
蓄積データ暗号化の有無 |
|
||
4.5 |
不正追跡・監視 |
13. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通クラウドテクノロジーズによるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください
|
||
4.6 |
不正アクセス検知・監視 |
|
||
4.7 |
ネットワーク対策 |
ネットワーク制御 |
|
|
4.8 |
セグメント分割 |
|
||
4.9 |
マルウェア対策 |
14. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通クラウドテクノロジーズによるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください
|
No. |
要件 |
OVMの仕様 |
選択値・条件 |
||
---|---|---|---|---|---|
大項目 |
中項目 |
小項目 |
|||
5.1 |
データセンター |
外部監査 |
|
|
|
5.2 |
データセンターロケーション |
|
No. |
要件 |
OVMの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
6.1 |
動作環境 |
動作仕様 |
対応OS |
15. 適宜バージョンアップされるため、最新情報を確認してください。
|
6.2 |
サーバーのタイプ (east-1) |
16. 適宜バージョンアップされるため、最新情報を確認してください。
|
No. |
要件 |
OVMの仕様 |
||
---|---|---|---|---|
大項目 |
中項目 |
小項目 |
||
7.1 |
サービス利用 |
稼働状況報告 |
|
|
8.1 |
システム特性 |
負荷分散への対応 |
|
|
8.2 |
システム連係 |
|
||
9.1 |
移行 |
移行方法 |
|
OVMで提供しているサーバーOSと対応するOracleDBの組み合わせは、 ニフクラOVM(Oracle Database利用環境) サービス仕様書 別紙 の「対応 Oracle Database バージョン」を確認してください。
※適宜バージョンアップされるため、最新情報を確認してください。
OVMで提供しているサーバータイプ以下のとおりとなります。構築するシステムに応じて選択して利用してください。
性能指針
CPU性能: ニフクラで提供しているType-h2相当の性能となります。
ストレージ性能: ニフクラで提供している高速ディスク相当の性能となります。
Oracle DB以外のOracle製品の利用について
Oracle DB以外のOracle製品を利用したい場合、OVMでの利用可否を利用者自身でオラクル社へ確認してください。
利用するサーバーのvCPU数 |
エディション名 |
基準となるプロセッサ数 |
必要なProcessorライセンス数 |
必要なNamed User Plusライセンス数 |
---|---|---|---|---|
1~4vCPU |
【Oracle Database】 |
利用するサーバーのvCPU数に0.5を乗じた数(小数点以下は切り上げ) |
「基準となるプロセッサ数」と同数(最小数は1) |
最大利用ユーザー数(最小数は「基準となるプロセッサ数」に25を乗じた数) |
【Oracle Database】 |
利用するサーバーのvCPU数に関わらず、1 |
「基準となるプロセッサ数」と同数 |
最大利用ユーザー数(最小数は10) |
|
8vCPU以上 |
【Oracle Database】 |
利用するサーバーのvCPU数に0.5を乗じた数(小数点以下は切り上げ) |
「基準となるプロセッサ数」と同数 |
最大利用ユーザー数(最小数は「基準となるプロセッサ数」に25を乗じた数) |
【Oracle Database】 |
利用するサーバーのvCPU数に関わらず、2 |
「基準となるプロセッサ数」と同数 |
最大利用ユーザー数(最小数は10) |
ovm.large16でEnterpriseEdisonをBYOLする場合:基準となるプロセッサ数 = 4vCPU × 0.5=2 → 必要なProcessorライセンス数 = 2
ovm.large16でStandardEdisonをBYOLする場合:基準となるプロセッサ数 = 利用するサーバーのvCPU数(4vCPU)に関わらず、1 → 必要なProcessorライセンス数 = 1
ovm.qlarge128でEnterpriseEdisonをBYOLする場合:基準となるプロセッサ数=16vCPU × 0.5 = 8 → 必要なProcessorライセンス数 = 8
ovm.qlarge128でStandardEdisonをBYOLする場合:基準となるプロセッサ数 =利用するサーバーのvCPU数(16vCPU)に関わらず、2 → 必要なProcessorライセンス数 =2
以下、ニフクラOVMサービス仕様書 別紙も併せて確認してください。
https://pfs.nifcloud.com/pdf/ovm_spec_attachment.pdf
OVMにおけるサーバーの提供形態は下記のようなイメージになります。
OVM提供範囲のみでは、外部のネットワークと接続できません。
必ず、ニフクラ環境の「プライベートLAN」をご利用のうえ、アクセス経路を確立してください。
イメージ図のように、OVMサーバーの利用シーンでは、接続した「プライベートLAN」うえで、ニフクラ環境のサービスと組み合わせて利用する形態が前提となります。
Oracle Database及びライセンスは提供していません、利用者側で用意・導入する必要があります。
OVMで作成されたサーバーは、ニフクラ環境と同じく複数のユーザーが利用する共用環境上に作成されます。
OVMサーバーは ニフクラ環境からプライベートLAN 経由でのみ接続が可能な環境 であり、ネットワーク環境はユーザー別に分離されています。
外部のネットワークとの接続には、プライベートLAN経由でアクセス経路を確立してください。
ニフクラと連係するために必要なサービスについて紹介します。
※申し込みからサーバー払出し後のログインまでの手順を紹介している、「OVM スタートアップガイド」も併せて参照ください。
OVMはニフクラとは異なる仮想化基盤(Oracle VM)となっており、コントロールパネルなども提供されていないため、様々な注意点・制約事項があります。
以下、注意点・制約事項は運用方式を検討するうえでの前提条件として留意ください。
制約事項 |
詳細 |
代替となる対応手段 |
---|---|---|
コントロールパネル非連係 |
Webフォームによる申請ベースで以下機能を提供。 |
|
停止を伴うメンテナンスの発生 |
ライブマイグレーションがオラクル社の規約上禁止されているため、HA後の復旧作業時や、仮想・物理基盤メンテナンス時に、利用者サーバーの停止が伴うメンテナンスが発生する。 |
Oracle RAC・SEHA環境を構築することで、仮想基盤メンテの際にもデータベース停止時間の最小化が可能。 |
オラクル社のポリシー変更による影響 |
オラクル社の方針変更により、オラクル製品利用に制約が加わる可能性がある。 |
特になし。 |
データセンターが存在する独立した地域のことを「リージョン」と定義しています。
ニフクラは、契約することで複数の国や地域など、地理的に離れた場所にあるリージョンを利用可能です。
リージョンの中に複数のゾーンが存在し、別のシステムとして運用されています。サーバーが収容されているラックや電源、ストレージなどは、ゾーン別に分離されています。
※リージョンによってゾーンの数は異なります。
OVMの提供は東日本east-1リージョンのみとなります。東日本east-2リージョンや西日本リージョンでは提供されていません。
OVMにはニフクラのようなゾーンという概念はありません。東日本east-1リージョン内であれば、どのニフクラのゾーンからでもOVM環境へ接続できます。
OVMで適用できるシステムパターンは下記のとおりです。
OVMはSLAの対象外となります
障害発生の状況やシステム構成などにより、停止時間は異なるため目安としてください。記載の停止時間を実現するには、提供機能以外の部分で利用者側でも設計・構築が必要です。
災害対策 (地理的冗長) |
ゾーン規模 |
サーバーSLA対象 |
許容可能な停止時間 |
推奨適用システムパターン |
OVMでの適用可否 |
---|---|---|---|---|---|
要 |
要 |
対象 |
無停止~数分 |
マルチリージョン マルチゾーン |
不可 |
不要 |
対象 |
無停止~数分 |
マルチリージョン シングルゾーン |
不可 |
|
不要 |
要 |
対象 |
無停止~数時間 |
シングルリージョン マルチゾーン |
不可 |
不要 |
対象外 |
無停止~数日程度 |
シングルリージョン Oracle RAC・SEHA構成 |
可能 |
|
対象外 |
数時間~数日程度 |
シングルリージョン シングル構成 スタンバイサーバー利用 |
可能 |
||
対象外 |
数日程度 |
シングルリージョン シングル構成 |
可能 |
以下にOVMでとれるシステムパターンの比較表を記載します。
シングルリージョン・Oracle RAC・SEHA構成 |
シングルリージョン・スタンバイサーバー利用構成 |
シングルリージョン・シングル構成 |
|
---|---|---|---|
構成要素 |
|
|
|
シングルリージョン構成のリージョン内において、Oracle RAC・SEHAでサーバーの冗長性を確保する構成を前提としたシステム構成 |
シングルリージョン・シングル構成のサーバーの他にスタンバイサーバーを用意し、障害発生時などにサーバー復旧時間を短縮することを目的とした構成 |
シングルリージョン、サーバーもシングル構成としたロケーション及びサーバー自体も冗長性を持たない運用を前提としたシステム構成 |
|
物理サーバー障害時の挙動 |
片系でサービス継続 (ダウンしたサーバーはHAによる再起動後、RACに復旧) |
再起動(HA) |
再起動(HA) |
単一サーバー障害時 |
サーバー切り離し |
スタンバイサーバーへ切り替え+リストア |
サーバー再作成+リストア |
単一サーバー障害時 |
数十秒~数分 |
1時間~+リストア時間 |
15営業日程度+リストア時間 |
サーバーコスト |
2台分 |
1台分+スタンバイサーバー分のコスト |
1台分 |
OracleDBライセンスコスト |
2台分(+RAC/SEHAに必要となるオプションライセンス等) |
1~2台分(スタンバイサーバー内のDB有無による) |
1台分 |
OVMの提供は東日本east-1リージョンのみであるため、リージョン・ゾーン障害に対する対策はとれませんので、ご留意をお願いします。
HAが発生した場合、サーバーは再起動される形となります。
HAが発動した場合、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。
Oracle RAC・SEHA構成にする場合、サーバーセパレート機能の利用が必須となります。この結果、稼働するVMは新規作成並びにHAからの復旧時に、別々の物理サーバーに配置されます。
本サービスの特性上、新規サーバーの用意に15営業日かかることから、RTOが重要な場合はスタンバイサーバー利用若しくはOracle RAC・SEHA構成を推奨します。
「OVMサーバー障害」に関して、ここではカーネルパニック、OS自体が起動しないなどの状況を想定しています。
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
No. |
適用システムパターン |
利用者が実施すべき作業内容 |
---|---|---|
1 |
|
OVM環境でOracle RAC・SEHA構成によりサーバーの冗長化を確保したシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。
18. ニフクラ側にバックアップデータ保存用サーバーを構築します。
|
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
No. |
適用システムパターン |
利用者が実施すべき作業内容 |
---|---|---|
2 |
|
OVM環境でスタンバイサーバーを利用しサーバーの可用性を向上させたシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。
19. ニフクラ側にバックアップデータ保存用サーバーを構築します。
|
以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。
No. |
適用システムパターン |
利用者が実施すべき作業内容 |
---|---|---|
3 |
|
OVM環境で冗長性を持たない運用を前提としたシステム構成例になります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。
20. ニフクラ側にバックアップデータ保存用サーバーを構築します。
|
OVM環境でOracle RAC・SEHA構成によりサーバーの冗長化を確保したシステム構成例の概念図です。
図に記載された吹き出しはRAC構成を組む場合に必要な設定であり、サーバー新規作成申し込み時に、オプションメニューとして同時に申し込んでください。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
リージョン障害 |
災害対策 (地理的冗長) |
シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。 |
- |
2 |
ゾーン障害 |
ゾーン規模障害対策 |
シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。 |
- |
3 |
物理サーバー |
メンテナンス時対策 |
計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。 |
|
4 |
ネットワークノード |
メンテナンス時対策 |
ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。 |
|
5 |
ストレージノード |
メンテナンス時対策 |
メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。 |
|
6 |
サーバー |
メンテナンス時対策 |
ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。 |
|
7 |
物理サーバー |
OVM環境障害対策 |
サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。 |
|
8 |
ネットワーク機器 |
OVM環境障害対策 |
ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。 |
|
9 |
ストレージ機器 |
OVM環境障害対策 |
ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。 |
|
10 |
サーバー |
OVM環境障害対策 |
サーバーのOS層以上については、サービス側での対策はありません。 |
|
11 |
監視 |
OVM環境障害対策 |
監視環境を別途構築する場合は、ニフクラ側で構築することになります。 |
|
12 |
バックアップ |
OVM環境障害対策 |
ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】となります。
21. Oracle DBのバックアップは オプション機能:アドバンスドバックアップ により可能となります。詳細については ドキュメント を参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
22. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
23. 富士通クラウドテクノロジーズによるOracle RAC構成下での検証は実施していません。利用者側の判断にて導入を検討してください。
|
24. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。
|
スタンバイサーバーは任意のタイミングで利用者の依頼元サーバーからコールドクローンすることにより作成されます。
スタンバイサーバーへの切り替えも任意のタイミングで可能ですが、データの復元方法などは別途検討が必要となります。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
リージョン障害 |
災害対策(地理的冗長) |
シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。 |
- |
2 |
ゾーン障害 |
ゾーン規模障害対策 |
シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。 |
- |
3 |
物理サーバー |
メンテナンス時対策 |
計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。 |
|
4 |
ネットワークノード |
メンテナンス時対策 |
ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。 |
|
5 |
ストレージノード |
メンテナンス時対策 |
メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。 |
|
6 |
サーバー |
メンテナンス時対策 |
ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。 |
|
7 |
物理サーバー |
OVM環境障害対策 |
サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。 |
|
8 |
ネットワーク機器 |
OVM環境障害対策 |
ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。 |
|
9 |
ストレージ機器 |
OVM環境障害対策 |
ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。 |
|
10 |
サーバー |
OVM環境障害対策 |
サーバーのOS層以上については、サービス側での対策はありません。 |
|
11 |
監視 |
OVM環境障害対策 |
監視環境を別途構築する場合は、ニフクラ側で構築することになります。 |
|
12 |
バックアップ |
OVM環境障害対策 |
|
27. Oracle DBのバックアップは オプション機能:アドバンスドバックアップ により可能となります。詳細については ドキュメント を参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
28. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
|
OVM環境で冗長性を持たない運用を前提としたシステム構成例の概念図です。
No. |
検討事項 |
対策観点 |
検討内容 |
検討時の重点ポイント |
---|---|---|---|---|
1 |
リージョン障害 |
災害対策(地理的冗長) |
シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。 |
- |
2 |
ゾーン障害 |
ゾーン規模障害対策 |
シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。 |
- |
3 |
物理サーバー |
メンテナンス時対策 |
計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。 |
|
4 |
ネットワークノード |
メンテナンス時対策 |
ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。 |
|
5 |
ストレージノード |
メンテナンス時対策 |
メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。 |
|
6 |
サーバー |
メンテナンス時対策 |
ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。 |
|
7 |
物理サーバー |
OVM環境障害対策 |
サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。 |
|
8 |
ネットワーク機器 |
OVM環境障害対策 |
ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。 |
|
9 |
ストレージ機器 |
OVM環境障害対策 |
ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。 |
|
10 |
サーバー |
OVM環境障害対策 |
サーバーのOS層以上については、サービス側での対策はありません。 |
|
11 |
監視 |
OVM環境障害対策 |
監視環境を別途構築する場合は、ニフクラ側で構築することになります。 |
|
12 |
バックアップ |
OVM環境障害対策 |
ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】となります。 [29]
|
31. Oracle DBのバックアップは オプション機能:アドバンスドバックアップ により可能となります。詳細については ドキュメント を参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
32. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
33. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。
|
先ずは、業務要件より適切なRPOとRTOを検討します。
復旧させるデータのバックアップポイントとバックアップ方法を決める。
バックアップ取得ポイント
月次
週次
日次
メンテナンス時
バックアップ取得方法
フル
差分
スナップショット
REDOログ
バックアップの保管
ローカルのデータセンター
他のデータセンター
バックアップの同期
同期
非同期
復旧させるデータをどのくらいの時間で復旧させるか決める。
バックアップの状況によってRTOは変動
データ同期が不要なシステムのRTOは短い
参照系のシステム
データ同期が必須のシステムのRTOは長い
バックアップだけでデータを戻せるか
REDOログの適用の可否
災害発生時のロストデータの復旧方法(手入力?)
データ復旧後の整合性の確認が重要
自動的に整合性確認できるか
手作業が必要か
業務再開可能と判断する判断基準は何か
IT管理者側のGo判断?
システム利用者側のGo判断?
RPO,RTOに対して、ニフクラOVMで可能と考えられるバックアップ方法に関して記載します。
パターン |
RPO |
RTO |
条件 |
バックアップ方法 |
適合システムパターン (システムパターンの検討参照) |
||
---|---|---|---|---|---|---|---|
バックアップ時OracleDBの停止可否 |
リカバリ時OVMサーバーの再構築可否 |
Oracleのデータ |
OVMサーバー全体 |
||||
1 |
障害発生直前 |
無停止 |
DBの停止不可 |
再構築不可 |
RMAN,dump,他バックアップ製品の持ち込みなど |
Oracle RAC・SEHAの利用 |
Oracle RAC・SEHA構成 |
2 |
短期に復旧 (数時間) |
DBの停止不可 |
再構築不可 |
RMANを利用 |
スタンバイサーバー+ニフクラAcronisを利用 |
スタンバイサーバー利用構成 |
|
3 |
長い停止も許容 (1日程度) |
DBの停止可/不可 |
再構築可 |
RMAN,dump, 他バックアップ製品の持ち込みなど |
スタンバイサーバーを利用 |
スタンバイサーバー利用構成 |
|
4 |
日次バックアップ取得時点 |
短期に復旧 (数時間) |
DBの停止可 |
再構築不可 |
RMAN,dump,ニフクラAcronisなど |
スタンバイサーバー+ニフクラAcronisを利用 |
スタンバイサーバー利用構成 |
5 |
長い停止も許容 (1日程度) |
DBの停止可 |
再構築可 |
RMAN,dump,ニフクラAcronis,他バックアップ製品の持ち込みなど |
スタンバイサーバーを利用 |
スタンバイサーバー利用構成 |
|
6 |
15営業日以上 |
DBの停止可 |
再構築可 |
RMAN,dump,ニフクラAcronisなど |
ニフクラAcronisを利用 |
シングル構成 |
OVMサーバーのバックアップ方法としてAcronisを利用する場合、他のバックアップ製品との併用はできません。
RMANの利用は利用者の責任範囲となります。
バックアップ製品を別途持ち込みし導入する場合、提供元にサポート可否等を確認してください。
想定している障害はOVMサーバー単体、データ消失レベルとなります。ゾーン/リージョン自体の障害は考慮できていません。必要に応じて遠隔地へのデータバックアップ等は検討してください。
「Acronis(オプション機能:アドバンスドバックアップ)利用」についてはOracleDBの対応バージョン、仕様等確認のうえ、利用を検討してください。
後述「スタンバイサーバーにおけるOracleライセンスの取り扱いについての注意」の章
各バックアップパターンで想定障害に応じたリカバリ方法案について記載します。
パターン |
RPO |
RTO |
条件 |
バックアップ方法 |
(想定障害に応じた)リカバリ方法 |
適合システムパターン (システムパターンの検討参照) |
||||
---|---|---|---|---|---|---|---|---|---|---|
バックアップ時OracleDBの停止可否 |
リカバリ時OVMサーバーの再構築可否 |
Oracleのデータ |
OVMサーバー全体 |
データ破損 |
OVMサーバー 一部障害 |
OVMサーバー 障害 |
||||
1 |
障害発生直前 |
無停止 |
DBの停止不可 |
再構築不可 |
RMAN,dump,他バックアップ製品の持ち込みなど |
Oracle RAC・SEHAの利用 |
データリカバリ(RMAN,dumpなどを利用) |
片系運用(+復旧作業) |
片系運用(+復旧作業) |
Oracle RAC・SEHA構成 |
2 |
短期に復旧(数時間) |
DBの停止不可 |
再構築不可 |
RMANを利用, |
スタンバイサーバー+ニフクラAcronisを利用 |
データリカバリ(RMAN、ニフクラAcronis(オプション機能:アドバンスドバックアップ)を利用) |
ニフクラAcronisでリカバリ |
スタンバイサーバー+ニフクラAcronisでリカバリ |
スタンバイサーバー利用構成 |
|
3 |
長い停止も許容(1日程度) |
DBの停止可/不可 |
再構築可 |
RMAN,dump, 他バックアップ製品の持ち込みなど, |
スタンバイサーバーを利用 |
データリカバリ(RMAN、ニフクラAcronis(オプション機能:アドバンスドバックアップ)、dumpなどを利用) |
スタンバイサーバーを利用してリカバリ |
スタンバイサーバー利用構成 |
||
4 |
日次バックアップ取得時点 |
短期に復旧(数時間) |
DBの停止可 |
再構築不可 |
RMAN,dump,ニフクラAcronisなど |
スタンバイサーバー+ニフクラAcronisを利用 |
データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用) |
ニフクラAcronisでリカバリ |
スタンバイサーバー+ニフクラAcronisでリカバリ |
スタンバイサーバー利用構成 |
5 |
長い停止も許容(1日程度) |
DBの停止可 |
再構築可 |
RMAN,dump,ニフクラAcronis,他バックアップ製品の持ち込みなど |
スタンバイサーバーを利用 |
データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用) |
スタンバイサーバーを利用してリカバリ |
スタンバイサーバー利用構成 |
||
6 |
15営業日以上 |
DBの停止可 |
再構築可 |
RMAN,dump,ニフクラAcronisなど |
ニフクラAcronisを利用 |
データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用) |
ニフクラAcronisでリカバリ |
新規OVM申請+ニフクラAcronisでリカバリ |
シングル構成 |
Acronisを利用したリカバリ方法として大きく分けて以下2種類あります。
AcronisのWebインターフェイスを利用したリカバリ
ブータブルメディアを利用したリカバリ
OVM環境ではコンソール機能を提供しておらず、ブータブルメディアをマウントできません。そのためOVM環境でのリカバリはすべてAcronisのWebインターフェイスを利用する必要があります。
「Acronis(オプション機能:アドバンスドバックアップ)利用」についてはOracleDBの対応バージョン、仕様等確認のうえ、利用を検討してください。
一部Oracleデータが紛失した。
OSにパッチ適用したところ動作が不安定等、ただしOSにはログイン可能で、Acronisのエージェントも起動している
カーネルパニック、OS自体が起動しない等
OVMサーバー 一部障害/OVMサーバー障害の際の復旧について、Oracleのデータリカバリ作業も必要に応じて追加で実施してください。
基本となるシステム構成イメージと各パターン共通の補足情報について説明します。
Acronisを利用したOVMサーバーのシステムバックアップに関して、FJCTでは下記システム構成で検証しています。
OVMサーバーとルーター(SNAT)は同一セグメントでの実施
ニフクラで提供しているバックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスド バックアップ機能はオプションで提供しています。
Acronisと通信する際の通信要件は以下を確認してください。本構成ではニフクラルーターのSNAT構成としていますが、通信要件を満たせば他構成でも利用可能です。
https://faq.support.nifcloud.com/faq/show/749
事前の入念なバックアップ/リカバリテストを実施することを推奨します。
サンプルとして、下記パターンに関して、バックアップ/リカバリ方針を例として記載します。
RPO |
RTO |
条件 |
バックアップ方法 |
適合システムパターン (システムパターンの検討参照) |
||
---|---|---|---|---|---|---|
バックアップ時OracleDBの停止可否 |
リカバリ時OVMサーバーの再構築可否 |
Oracleのデータ |
OVMサーバー全体 |
|||
障害発生直前 |
短期に復旧(数時間) |
DBの停止不可 |
再構築不可 |
RMANを利用 |
スタンバイサーバー+ニフクラAcronisを利用 |
スタンバイサーバー利用構成 |
OVMサーバー全体(システム領域)は変更があるメンテナンス前後に取得する(パッチ適用等)
Oracleデータは日次で取得する
Oracleデータは障害発生直前までリカバリできることそのためREDOログの適用まで考慮する
以降に本サンプルにおけるバックアップ/リカバリの具体的実施例を説明します。他パターンは本パターンを参考にしてください。
ニフクラOVMでのバックアップ実施例
例として記載したバックアップ/リカバリ方針に対して、ニフクラOVMで実施するバックアップ例を記載します。
取得タイミング:事前(最初に作成)
取得タイミング:メンテナンス前後
取得タイミング:日次
想定障害に応じたリカバリ方法の詳細を以降に記載していきます。
RPO |
RTO |
バックアップ方法 |
(想定障害に応じた)リカバリ方法 |
適合システムパターン |
|||
---|---|---|---|---|---|---|---|
Oracleのデータ |
OVMサーバー全体 |
データ破損 |
OVMサーバー |
OVMサーバー |
|||
障害発生直前 |
短期に復旧(数時間) |
RMANを利用 |
スタンバイサーバー+ニフクラAcronisを利用 |
データリカバリ |
ニフクラAcronisでリカバリ |
スタンバイサーバー+ニフクラAcronisでリカバリ |
スタンバイサーバー利用構成 |
一部Oracleデータが紛失した。
OSにパッチ適用したところ動作が不安定等、ただしOSにはログイン可能で、Acronisのエージェントも起動している
カーネルパニック、OS自体が起動しない等
想定障害 |
各バックアップ手法で取得したデータのリカバリ必要可否 |
|||
---|---|---|---|---|
RMAN |
Acronis |
スタンバイサーバー |
||
① |
データ破損 |
必要 |
不要 |
不要 |
② |
システム一部不具合 |
必要 |
必要 |
不要 |
③ |
OVMサーバー自体の障害 |
必要 |
必要 |
必要 |
一部Oracleデータが紛失した。
RMANを利用して障害直前までリカバリ実施
OSにパッチ適用したところ動作が不安定等
OSにはログイン可能で、Acronisのエージェントも起動している
A:Acronisでバックアップしていたサーバー全体のバックアップを、本番サーバーへリストア実施
B:必要に応じてRMANでOracleデータ復旧
カーネルパニック、OS自体が起動しない
A:スタンバイサーバーに切り替え申請(「スタンバイサーバーにおけるOracleライセンスの取り扱いについての注意」参照)
B:Acronisでバックアップしていたサーバー全体のバックアップを元スタンバイサーバーへリストア実施
C:必要に応じてRMANでのOracleデータ復旧
Oracleライセンスに関して
Oracleのライセンスは基本的に、Oracleインストールした台数分だけ必要になります。そのためスタンバイサーバーを利用する場合ライセンスに注意してください。
以下の2パターンで復旧の手順が異なります。
※上記「バックアップ/リカバリ方針のサンプル」を例に記載しています。その他のパターンの場合は手順が一部異なります。
Oracleライセンスを二式(スタンバイサーバー分)、用意できる場合の復旧(こちらを推奨)
スタンバイサーバーに切り替え申請
Acronisでバックアップしていたデータを、スタンバイサーバーへリストア実施
必要に応じてRMANでのOracleデータ復旧
Oracleライセンスを一式に抑えたい場合の復旧
スタンバイサーバーに切り替え申請
⇒申し込み受領後1時間以内の着手
Oracleが入っている元サーバー(入れ替わりでスタンバイサーバーになる)を削除
⇒5営業日以内を目安に対応
再度(Oracleの入っていない)新規のスタンバイサーバーを作成
⇒5営業日以内を目安に対応
Acronisでバックアップしていたサーバー全体のバックアップを、元スタンバイサーバーへリストア実施
必要に応じてRMANでのOracleデータ復旧
※富士通クラウドテクノロジーズでの検証結果を元にした情報であり、検証結果どおり動作を保証するものではありません。
Oracle未導入のサーバーでの検証となります。
スタンバイサーバー作成のタイミングはAcronisエージェント導入後になります。
①Acronisへのバックアップ検証を実施したOSは以下のとなります
Oracle Linux7.6
Windows Server 2012
Windows Server 2016
②本番サーバーの疑似障害サーバーを停止
③スタンバイサーバーへ切り替えWebフォームからの申請となり、受け付け後、1時間以内を目安に着手し切り替えられる
④ ①で取得したバックアップをスタンバイサーバーへリストア
各OS内にAcronisエージェントをインストールし、Acronis管理画面にてデバイスが登録されたことを確認する。
各サーバーのOSの状態を記録する
Windows:ネットワークアダプタ名、ネットワークアダプタ内の設定、ipconfig /allの結果
Linux:ネットワークアダプタ名、ネットワークアダプタのifcfgの設定、ipaの結果
各OSをAcronis上にバックアップ
スタンバイサーバーの作成 ※Webフォームからの申請
スタンバイサーバー作成時はサーバーが停止されるため、あらかじめ停止させておく。
本番サーバーを停止 ※ハード故障を想定
スタンバイサーバーへの切り替え ※Webフォームからの申請
Acronis管理画面にて本番サーバーへ昇格したサーバー(スタンバイサーバー)のデバイスが有効になることを確認する。
Acronis側から本番サーバーに昇格したサーバー(スタンバイサーバー)へリストアを実施する。
本番サーバーへ昇格したサーバー(スタンバイサーバー)にログインできることを確認する。
Oracle Linux7.6,Widnows Server 2012,Windows Server 2016すべてでバックアップ・リカバリが正常終了を確認。
新規サーバーに対して同一IPアドレスで復元したい場合の情報となります。
富士通クラウドテクノロジーズでの検証結果を元にした情報であり、検証結果どおり動作を保証するものではありません。
Oracle未導入のサーバーでの検証となります。
リストア対象サーバーは新規作成となり、Acronisエージェントも別途導入します。
①Acronisへバックアップ
検証を実施したOSは以下のとなります
Oracle Linux7.6
Windows Server 2012
②本番サーバーの疑似障害サーバーを停止
③サーバー新規作成
Webフォームからの申請となり、15営業日で用意される。※事前作成も可能
④ ①で取得したバックアップを新規サーバーへリストア
Acronisによるリストア後、復元したサーバーへ接続できない事象が発生した。
リストア後のサーバー再起動時にネットワークアダプタが初期化された影響でIPアドレスが反映されていないため。
サーバー再起動後にネットワークアダプタが初期化されたことを確認後、IPアドレスを指定する(※)ことで接続可能になります。
ネットワークアダプタ名とIPアドレス設定を指定するバッチを作成しておき、タスクスケジューラなどでOS起動時実行を設定しておく。以下のバッチスクリプトサンプルも参考にしてください。
ifcfg-eth0内の「HWADDR」(MACアドレス)が新規サーバーのものが指定されるため。
ifcfg-eth0内の「HWADDR」をバックアップ元サーバーのMACアドレスを指定する(※)ことで接続可能になります。
事前にバックアップ元サーバーで以下の作業を実施しておく。
ifcfg-eth0内の「HWADDR」を記載しない
70-persistent-ipoib.rulesに/dev/nullのシンボリックリンクをはる
※IPアドレスなどのネットワーク設定値はサーバー新規作成時に付与された設定値を指定してください。異なる設定値を指定した場合、サーバーへ接続できなくなる場合があります。
対象サーバーの任意の場所に配置します。
実行にはAdministrator権限が必要です。
バッチスクリプトサンプル
ネットワークアダプタ名、IPアドレス箇所は対象サーバーに併せて読み替えてください。
DNSアドレスはご利用しているものを指定してください。サンプルではGoogle Public DNSを指定しています。
@echo off
netsh interface ipv4 set add name="Ethernet1" source=static addr="192.168.1.1” mask=“255.255.255.0” gateway=“192.168.1.254" gwmetric=1
netsh interface ipv4 set dns name="Ethernet1" source=static addr="8.8.8.8" register=non validate=no
netsh interface ipv4 add dns name="Ethernet1" addr="8.8.4.4" index=2 validate=no
pause
exit
下図の構成ではサーバー全体のリストア時、スタティックルート情報が参照できず、バックアップサーバーまで疎通できないため、有事の際リストアできない構成となります。留意してください。
バックアップ構成
Acronisへの通信はルーターSNATを利用(緑線)
バックアップ先はハウジング環境のバックアップサーバー(紫線)(スタティックルートでネクストホップをハウジング環境のルーター)
リストア時
サーバーに設定していたスタティックルート情報が参照できないため、バックアップサーバーまで疎通できない
参考FAQ
Acronisでルーターを経由してローカルストレージ(ネットワークフォルダ、NFSフォルダ)に保存したバックアップデータからの復元が失敗する
https://faq.support.nifcloud.com/faq/show/2645