クラウドユーザーガイド（OVM活用ガイド）

【重要なお知らせ】サービス統合に基づくサービス名称の読み替えのお願い（2024年4月1日）

2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。
当サイトのアドレス（ドメイン名）に含まれる「nifcloud.com」は現時点では変更はございませんが、
各ページに記載の「ニフクラ」「NIFCLOUD」「nifcloud」は、「FJcloud-V」に読み替えていただきますようお願いいたします。

ニフクラユーザーガイド

クラウドトップ>OVM>ユーザーガイド>OVM活用ガイド

はじめに
適用判断手順の概要
- 適用判断手順の概要
1.OVMで対応できない要件
- SLA／移行性
- 動作環境／サポート
2.OVMの適用判断事項
3.提供サーバーOS及びサーバータイプの検討
4.ニフクラとの連係方法の検討
- ニフクラとの連係方法の検討
- ニフクラとの連係方法
5.システムパターンと運用方式の検討
Appendix

はじめに

本ドキュメントは、OVM活用ガイドです。
ニフクラOVMサービス（以下、本サービスと言います）は、富士通が構築した、Oracle DatabaseライセンスのBYOL( Bring Your Own License )が可能なIaaS環境です。
本サービスの利用者は、Oracle Databaseライセンスを持ち込むことができる仮想サーバー（以降、サーバーと言い、物理サーバーとは区別して説明します）を所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。
本サービス環境は、パブリック等のニフクラ環境とは異なる仮想化基盤 (OracleVM/Oracle Linux Virtualization) を用いて、構築・運用されています。
利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。
システム要件によってはOVM適用(移行)不可となる場合があるため、サービス仕様書及び、本ドキュメントを最後まで確認のうえ、適用可否を判断してください。
ニフクラサービスの変更は最新のドキュメントを参照してください。

適用判断手順の概要

OVMの適用可否を判断するために、以下手順を確認してください。

OVMで対応できない要件
- OVMで対応ができないシステム要件や条件などを確認し、適用可否を判断する
OVMの適用判断事項
- システム要件に対応するOVMサービス仕様を確認し、必要となる対処、影響等を検討したうえで、適用可否を判断する
提供サーバーOS及びサーバータイプの検討
- 提供サーバーOS及びサーバータイプの選択指針から、利用するサーバーを選択する
- 対応Oracle DBバージョンから選択する
ニフクラとの連係方法の検討
システムパターンと運用方式の検討
- 可用性・業務継続性からシステムパターンを選択する
- サービス利用上の注意点から運用方式を検討する
Appendix

1.OVMで対応できない要件

SLA／移行性

OVMを適用できない主な条件を示します。以下の不適合条件に合致する要件がある場合、他のクラウドやオンプレミスを検討してください。

不適合条件	理由
SLA	クラウドサービスが定義しているSLAをこえるSLA提供が必要	OVMは、SLA対象外となります。詳細は品質保証制度（SLA）についてを確認してください。
移行性	特定のグローバルIPアドレスが必要	OVMのサーバーは、グローバルIPアドレスは付与されません。
サポート外のOS移行が必要	対応OS以外は導入できません。対応OSはこちらより確認してください。
OVF+VMDKなどのイメージ移行が必要	OVMでは、VMインポート機能は提供していません。

不適合条件

理由

SLA

クラウドサービスが定義しているSLAをこえるSLA提供が必要

OVMは、SLA対象外となります。詳細は品質保証制度（SLA）についてを確認してください。

移行性

特定のグローバルIPアドレスが必要

OVMのサーバーは、グローバルIPアドレスは付与されません。

サポート外のOS移行が必要

対応OS以外は導入できません。
対応OSはこちらより確認してください。

OVF+VMDKなどのイメージ移行が必要

OVMでは、VMインポート機能は提供していません。

動作環境／サポート

OVMを適用できない主な条件を示します。以下の不適合条件に合致する要求がある場合、他のクラウドやオンプレミスの検討してください。

不適合条件	理由
動作環境	物理機器の利用が必要	プリンタ・FAX・スキャナ・テープデバイスなどの物理機器をOVMで利用できません。
システム要件として高性能なCPUスペックが必要	提供されているvCPU以外を利用できません。 GPU搭載モデルのサーバータイプも提供していません。
提供されていないOSが必要	対応OSはこちらより確認してください。
ミドルウェアの動作保証が必要 (ミドルウェアの製品指定がある商談など)	ミドルウェアのサポート可否や動作実績、ライセンスの考え方などについては、それぞれのミドルウェア販売元への確認が必要です。また、ミドルウェアを導入する場合は、事前検証や導入作業を、プロジェクト責任で実施してください。(OVM側で環境変更などの個別対応はできません。)
複数NICが必要	OVMでは複数NICは提供していません。 ^[1] 1. 「Oracle RAC・SEHA向けディスク・ネットワーク設定」オプション利用時を除く。
厳密なレスポンスタイムが要求されるシステム	OVMの性能はベストエフォートでの提供となります。 ^[2] 2. IOPS保証などの性能保証はありません。
インフラ基盤に対する厳格な動作要件をもつシステム	インフラ基盤に特別な設定が必要となるシステムは、OVM上では稼働できない可能性があります。
サポート	OS等のインフラ基盤より上位層について、OVMに対応していないサポート契約が必要	OVMではOS層以上のサポートについては下記のとおりです。^[3] Oracle Linux のサポートについては富士通が一次受けします。 ^[4] Windows Serverのサポートについては、「サポート（富士通サポートデスク）」を利用の場合、サポート可能です。詳細はこちらを確認してください。 Oracle Database 製品についてのオラクル社のサポートは、利用者にて用意してください。 3. 記載のサポートでは要件を満たさない場合など、別会社からのサポートサービス提供を検討する必要があります。 4. ニフクラでは、24時間365日受け付け可能な窓口をご用意していますが、回答時間や事象の解決についての保証はしておりません。

不適合条件

理由

動作環境

物理機器の利用が必要

プリンタ・FAX・スキャナ・テープデバイスなどの物理機器をOVMで利用できません。

システム要件として高性能なCPUスペックが必要

提供されているvCPU以外を利用できません。
GPU搭載モデルのサーバータイプも提供していません。

提供されていないOSが必要

対応OSはこちらより確認してください。

ミドルウェアの動作保証が必要 (ミドルウェアの製品指定がある商談など)

ミドルウェアのサポート可否や動作実績、ライセンスの考え方などについては、それぞれのミドルウェア販売元への確認が必要です。また、ミドルウェアを導入する場合は、事前検証や導入作業を、プロジェクト責任で実施してください。(OVM側で環境変更などの個別対応はできません。)

複数NICが必要

OVMでは複数NICは提供していません。 ^[1]

1. 「Oracle RAC・SEHA向けディスク・ネットワーク設定」オプション利用時を除く。

厳密なレスポンスタイムが要求されるシステム

OVMの性能はベストエフォートでの提供となります。 ^[2]

2. IOPS保証などの性能保証はありません。

インフラ基盤に対する厳格な動作要件をもつシステム

インフラ基盤に特別な設定が必要となるシステムは、OVM上では稼働できない可能性があります。

サポート

OS等のインフラ基盤より上位層について、OVMに対応していないサポート契約が必要

OVMではOS層以上のサポートについては下記のとおりです。^[3]

Oracle Linux のサポートについては富士通が一次受けします。 ^[4]
Windows Serverのサポートについては、「サポート（富士通サポートデスク）」を利用の場合、サポート可能です。詳細はこちらを確認してください。
Oracle Database 製品についてのオラクル社のサポートは、利用者にて用意してください。

3. 記載のサポートでは要件を満たさない場合など、別会社からのサポートサービス提供を検討する必要があります。

4. ニフクラでは、24時間365日受け付け可能な窓口をご用意していますが、回答時間や事象の解決についての保証はしておりません。

2.OVMの適用判断事項

可用性

利用者の要件に対応するOVMサービス仕様を確認し、利用者側で必要となる対処、影響等を検討したうえで、OVM適用可否を判断します。

No.	要件	OVMの仕様
大項目	中項目	小項目
1.1	可用性	継続性	運用スケジュール	24時間365日無停止。(計画停止/定期保守/即時対応を除く) 計画停止/定期保守/即時対応の影響については、No.3.3を参照。
1.2	稼働率	月間稼働率：SLA対象外のサービスであり、月間稼働率は定めていません。
1.3	耐障害性	ネットワーク	OVM環境基盤の構成は二重化構成。切り替わり時に通信断を伴う可能性あり。
1.4	ストレージ	OVM環境基盤構成は二重化構成。切り替わり時に通信断、I/O遅延または断を伴う可能性あり。
1.5	災害対策(DR)	サービスとして提供はしていませんが、災害規模を想定し、その復旧計画(手順、コスト、テスト)を検討してください。オンプレミス環境などを活用し、地理的に離れた複数拠点での冗長化システムを用意しておき、データをニフクラ経由で同期するといった構成を検討など、利用者側にてレプリケーションの仕組みを構築する必要あり。

No.

要件

OVMの仕様

大項目

中項目

小項目

1.1

可用性

継続性

運用スケジュール

24時間365日無停止。(計画停止/定期保守/即時対応を除く)
計画停止/定期保守/即時対応の影響については、No.3.3を参照。

1.2

稼働率

月間稼働率：SLA対象外のサービスであり、月間稼働率は定めていません。

1.3

耐障害性

ネットワーク

OVM環境基盤の構成は二重化構成。
切り替わり時に通信断を伴う可能性あり。

1.4

ストレージ

OVM環境基盤構成は二重化構成。
切り替わり時に通信断、I/O遅延または断を伴う可能性あり。

1.5

災害対策(DR)

サービスとして提供はしていませんが、災害規模を想定し、その復旧計画(手順、コスト、テスト)を検討してください。
オンプレミス環境などを活用し、地理的に離れた複数拠点での冗長化システムを用意しておき、データをニフクラ経由で同期するといった構成を検討など、利用者側にてレプリケーションの仕組みを構築する必要あり。

性能・拡張性：リソース拡張性、性能保証

No.	要件	OVMの仕様
大項目	中項目	小項目
2.1	性能・拡張性	リソース拡張性	vCPU	サーバータイプのvCPUスペックはこちらを確認してください。
2.2	メモリ	サーバーのメモリ量はこちらを確認してください。
2.3	ストレージ	OVMディスクの仕様はこちらを確認してください。
2.4	性能・拡張性	リソース拡張性	スケールアップ	サーバータイプを変更することで可能。(No.2.1, No.2.2) ストレージ容量は、ディスクに保存されているデータ内容を維持したまま領域拡張が可能。(No.2.3) サーバータイプの変更及び、ディスクの追加/拡張は、Webフォームから申請してください。申請時はあらかじめアプリケーション、RDBMSなどを停止してください。
スケールアウト	オートスケール機能は提供されていないため、不可能。
2.5	性能品質保証	性能保証型のサービスではありません。スケールアップ、アプリケーションチューニングなどを検討してください。

No.

要件

OVMの仕様

大項目

中項目

小項目

2.1

性能・拡張性

リソース拡張性

vCPU

サーバータイプのvCPUスペックはこちらを確認してください。

2.2

メモリ

サーバーのメモリ量はこちらを確認してください。

2.3

ストレージ

OVMディスクの仕様はこちらを確認してください。

2.4

性能・拡張性

リソース拡張性

スケールアップ

サーバータイプを変更することで可能。(No.2.1, No.2.2)
ストレージ容量は、ディスクに保存されているデータ内容を維持したまま領域拡張が可能。(No.2.3)
サーバータイプの変更及び、ディスクの追加/拡張は、Webフォームから申請してください。
申請時はあらかじめアプリケーション、RDBMSなどを停止してください。

スケールアウト

オートスケール機能は提供されていないため、不可能。

2.5

性能品質保証

性能保証型のサービスではありません。
スケールアップ、アプリケーションチューニングなどを検討してください。

運用・保守性

No.	要件	OVMの仕様
大項目	中項目	小項目
3.1	運用・保守性	通常運用	バックアップ	ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。ニフクラで提供しているバックアップサービスの中で【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】が利用可能です。 ^[5] OVM環境で利用できるバックアップ/リストア関連の機能及び制約は以下のとおり。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）が利用可能 OVMはベアメタルリカバリに非対応 OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリ不可 ^[6] OVM環境以外にバックアップ環境の設計、構築を検討してください。ベアメタルリカバリが不可のため、システムフルリストア要件がある場合は、スタンバイサーバーオプションの利用を検討してください。 OVMサーバー(シングル構成)にOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[7] 5. 2020年1月時点で、富士通によるOracle RAC構成下での検証は実施していません。留意してください。 6. Acronisを利用したリストア方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。 7. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。
3.2	運用監視	ハードウェア監視、ハイパーバイザー稼働監視等のOVM環境基盤側の監視については、サービス提供側で実施しています。サーバーのOS以上の監視サービスは提供されていないため、利用者側で検討してください。監視ツールをサーバーに導入し、利用者側で構築した監視環境からの運用監視を検討してください。監視ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。
3.3	保守運用	計画停止	品質基準の保持やサービスメニューの拡張を目的としたメンテナンスを実施する場合があります。通知内容に応じて対応を検討してください。メンテナンスの内容、影響の詳細については、サービス仕様書を確認してください。
3.4	HA発生時	HAからの完全復旧を目的として、発生から一定時間経過後にメンテナンスを行います。通知内容に応じて対応を検討してください。メンテナンスの内容、影響の詳細については、サービス仕様書を確認してください。
3.5	パッチ適用	ハードウェアのセキュリティパッチは定期的にサービス提供側で実施しています。OS以上については、利用者にてアップデートを実施してください。 OS以上に関するメンテナンス、データバックアップの運用・管理、利用アプリケーション等のアップデートを検討してください。パッチの適用後のアプリケーション動作検証を行い、動作しない場合の切り戻し、若しくはアプリケーションの修正などにもあらかじめ留意してください。
3.6	運用環境	開発用環境の設置	サービスとして開発用環境の提供はしていません。開発用環境と位置付けたサーバーを作成し、プライベートLANを適切に用意することで、ネットワークの論理分割が可能です。各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。
3.7	試験用環境の設置	サービスとして試験用環境の提供はしていません。試験用環境と位置付けたサーバーを作成し、プライベートLANを適切に利用することで、ネットワークの分割が可能です。各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。
3.8	サポート体制	仕様・機能や料金、導入相談などのお問い合わせ窓口を用意しています。詳細は、サービス仕様書を確認してください。

No.

要件

OVMの仕様

大項目

中項目

小項目

3.1

運用・保守性

通常運用

バックアップ

ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。
ニフクラで提供しているバックアップサービスの中で【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】が利用可能です。 ^[5]

OVM環境で利用できるバックアップ/リストア関連の機能及び制約は以下のとおり。
- バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）が利用可能
- OVMはベアメタルリカバリに非対応
- OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリ不可 ^[6]
OVM環境以外にバックアップ環境の設計、構築を検討してください。
- ベアメタルリカバリが不可のため、システムフルリストア要件がある場合は、スタンバイサーバーオプションの利用を検討してください。
- OVMサーバー(シングル構成)にOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[7]

5. 2020年1月時点で、富士通によるOracle RAC構成下での検証は実施していません。留意してください。

6. Acronisを利用したリストア方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

7. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

3.2

運用監視

ハードウェア監視、ハイパーバイザー稼働監視等のOVM環境基盤側の監視については、サービス提供側で実施しています。
サーバーのOS以上の監視サービスは提供されていないため、利用者側で検討してください。
監視ツールをサーバーに導入し、利用者側で構築した監視環境からの運用監視を検討してください。
監視ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。

3.3

保守運用

計画停止

品質基準の保持やサービスメニューの拡張を目的としたメンテナンスを実施する場合があります。通知内容に応じて対応を検討してください。
メンテナンスの内容、影響の詳細については、サービス仕様書を確認してください。

3.4

HA発生時

HAからの完全復旧を目的として、発生から一定時間経過後にメンテナンスを行います。通知内容に応じて対応を検討してください。
メンテナンスの内容、影響の詳細については、サービス仕様書を確認してください。

3.5

パッチ適用

ハードウェアのセキュリティパッチは定期的にサービス提供側で実施しています。OS以上については、利用者にてアップデートを実施してください。
OS以上に関するメンテナンス、データバックアップの運用・管理、利用アプリケーション等のアップデートを検討してください。
パッチの適用後のアプリケーション動作検証を行い、動作しない場合の切り戻し、若しくはアプリケーションの修正などにもあらかじめ留意してください。

3.6

運用環境

開発用環境の設置

サービスとして開発用環境の提供はしていません。
開発用環境と位置付けたサーバーを作成し、プライベートLANを適切に用意することで、ネットワークの論理分割が可能です。
各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。

3.7

試験用環境の設置

サービスとして試験用環境の提供はしていません。
試験用環境と位置付けたサーバーを作成し、プライベートLANを適切に利用することで、ネットワークの分割が可能です。
各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。

3.8

サポート体制

仕様・機能や料金、導入相談などのお問い合わせ窓口を用意しています。詳細は、サービス仕様書を確認してください。

セキュリティ

No.	要件	OVMの仕様
大項目	中項目	小項目
4.1	セキュリティ	アクセス・利用制限	認証機能	サービスとして提供していません。サーバー上のOS上で認証機能を実装してください。意図しないユーザーのサーバーログイン等の事故を避けるため適切な権限設定を検討してください。
4.2	利用制限	サービスとして提供していません。サーバー上のOS上で認証機能を実装し、業務要件に基づいた利用者制限設計を検討してください。意図しないユーザーのサーバーログイン等の事故を避けるため適切な権限設定を検討してください。
4.3	データの秘匿	伝送データの暗号化の有無	オンプレミス環境とOVM間を接続するには、以下のいずれかの方法により実現できます。インターネット経由：IPsec VPN機能、SSL-VPN機能専用線/閉域網経由：プライベート接続サービス(プライベートアクセスサービス＋ダイレクトポート) IPsec VPN機能は拠点間VPNゲートウェイを作成し、オンプレミス環境にVPNルーターを用意してください。 SSL-VPN機能はリモートアクセスVPNゲートウェイを作成し、端末に専用のクライアントアプリケーションを導入してください。プライベート接続サービスはスイッチ接続手続きが必要となります。 IPsec VPN機能では、動作確認済みVPNルーターの利用を推奨。選択するVPNルーターにより、機能差があります。拠点間VPNゲートウェイ、リモートアクセスVPNゲートウェイ、プライベート接続の詳細は各サービスページ/技術仕様/制限値を参照してください。ネットワーク関連サービスクラウド技術仕様/制限値（ネットワーク）
4.4	蓄積データ暗号化の有無	データ暗号化サービスの提供はしていません。暗号化が必要な場合はOS上で専用の暗号化ツールなどの導入を検討してください。暗号化ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。
4.5	不正追跡・監視	ニフクラのオプションサービス「Trend Micro Cloud One – Workload Security」を検討する。 ^[8] 業務システムのログ管理については、決定、実装、取得のすべてが利用者の責任範囲。 Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーはインターネットへ接続する必要がある。 OVM環境単体ではインターネット接続ができないため、ニフクラとの連係が必要となる。 8. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通によるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください
4.6	不正アクセス検知・監視	ニフクラのオプションサービス「Trend Micro Cloud One – Workload Security」を検討する。 Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーからインターネットへ接続する必要がある。 OVM環境単体ではインターネット接続ができないため、ニフクラとの連係を検討してください。
4.7	ネットワーク対策	ネットワーク制御	ニフクラで提供しているサーバー単位に設定可能なファイアウォールグループサービスはOVMでは提供していません。利用者側でiptables等の設計、構築が必要。
4.8	セグメント分割	ニフクラであらかじめ作成したプライベートLANのセグメント上に作成されるため、OVM内自体でのセグメント分割は不可。また、追加NIC非対応のため、1つのサーバーに対して複数セグメントの接続は不可。利用者側でネットワークの設計・構築 (セグメント分割含む) が必要。
4.9	マルウェア対策	ニフクラのオプションサービスとして、「Trend Micro Cloud One – Workload Security」を検討する。 ^[9] Trend Micro Cloud One – Workload Security利用時は、申請書提出後に発行されたActivation Codeを登録し、インストール及び各種セキュリティ設定を実施。 Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーからインターネットへ接続する必要がある。 OVM環境単体ではインターネット接続ができないため、ニフクラとの連係を検討してください。 Trend Micro Cloud One – Workload Securityのシステム要件については、クラウド技術仕様/制限値（サーバー向けクラウド型セキュリティ（Trend Micro Cloud One – Workload Security）_注意事項を参照。 9. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通によるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください

No.

要件

OVMの仕様

大項目

中項目

小項目

4.1

セキュリティ

アクセス・利用制限

認証機能

サービスとして提供していません。サーバー上のOS上で認証機能を実装してください。
意図しないユーザーのサーバーログイン等の事故を避けるため適切な権限設定を検討してください。

4.2

利用制限

サービスとして提供していません。サーバー上のOS上で認証機能を実装し、業務要件に基づいた利用者制限設計を検討してください。
意図しないユーザーのサーバーログイン等の事故を避けるため適切な権限設定を検討してください。

4.3

データの秘匿

伝送データの暗号化の有無

オンプレミス環境とOVM間を接続するには、以下のいずれかの方法により実現できます。
- インターネット経由：IPsec VPN機能、SSL-VPN機能
- 専用線/閉域網経由：プライベート接続サービス(プライベートアクセスサービス＋ダイレクトポート)
IPsec VPN機能は拠点間VPNゲートウェイを作成し、オンプレミス環境にVPNルーターを用意してください。
SSL-VPN機能はリモートアクセスVPNゲートウェイを作成し、端末に専用のクライアントアプリケーションを導入してください。
プライベート接続サービスはスイッチ接続手続きが必要となります。
IPsec VPN機能では、動作確認済みVPNルーターの利用を推奨。
選択するVPNルーターにより、機能差があります。拠点間VPNゲートウェイ、リモートアクセスVPNゲートウェイ、プライベート接続の詳細は各サービスページ/技術仕様/制限値を参照してください。
ネットワーク関連サービス
 クラウド技術仕様/制限値（ネットワーク）

4.4

蓄積データ暗号化の有無

データ暗号化サービスの提供はしていません。暗号化が必要な場合はOS上で専用の暗号化ツールなどの導入を検討してください。
暗号化ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。

4.5

不正追跡・監視

ニフクラのオプションサービス「Trend Micro Cloud One – Workload Security」を検討する。 ^[8]
業務システムのログ管理については、決定、実装、取得のすべてが利用者の責任範囲。
Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーはインターネットへ接続する必要がある。
OVM環境単体ではインターネット接続ができないため、ニフクラとの連係が必要となる。

8. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通によるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください

4.6

不正アクセス検知・監視

ニフクラのオプションサービス「Trend Micro Cloud One – Workload Security」を検討する。
Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーからインターネットへ接続する必要がある。
OVM環境単体ではインターネット接続ができないため、ニフクラとの連係を検討してください。

4.7

ネットワーク対策

ネットワーク制御

ニフクラで提供しているサーバー単位に設定可能なファイアウォールグループサービスはOVMでは提供していません。
利用者側でiptables等の設計、構築が必要。

4.8

セグメント分割

ニフクラであらかじめ作成したプライベートLANのセグメント上に作成されるため、OVM内自体でのセグメント分割は不可。また、追加NIC非対応のため、1つのサーバーに対して複数セグメントの接続は不可。
利用者側でネットワークの設計・構築 (セグメント分割含む) が必要。

4.9

マルウェア対策

ニフクラのオプションサービスとして、「Trend Micro Cloud One – Workload Security」を検討する。 ^[9]
Trend Micro Cloud One – Workload Security利用時は、申請書提出後に発行されたActivation Codeを登録し、インストール及び各種セキュリティ設定を実施。
Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーからインターネットへ接続する必要がある。
OVM環境単体ではインターネット接続ができないため、ニフクラとの連係を検討してください。
Trend Micro Cloud One – Workload Securityのシステム要件については、クラウド技術仕様/制限値（サーバー向けクラウド型セキュリティ（Trend Micro Cloud One – Workload Security）_注意事項を参照。

9. Trend Micro Cloud One – Workload Securityについて、2020年1月時点で、富士通によるOVM環境での検証は実施していません。利用者側の判断にて導入を検討してください

データセンター

No.	要件	OVMの仕様	選択値・条件
大項目	中項目	小項目
5.1	データセンター	外部監査	外部機関より公的認証を取得。	取得している認証については、第三者認証を確認してください。
5.2	データセンターロケーション	使用できるリージョンが限定されています。詳細はこちらを確認してください。

No.

要件

OVMの仕様

選択値・条件

大項目

中項目

小項目

5.1

データセンター

外部監査

外部機関より公的認証を取得。

取得している認証については、第三者認証を確認してください。

5.2

データセンターロケーション

使用できるリージョンが限定されています。詳細はこちらを確認してください。

動作環境

No.	要件	OVMの仕様
大項目	中項目	小項目
6.1	動作環境	動作仕様	対応OS	OVMで提供しているOSはニフクラOVM　OVMサーバータイプ・仕様で確認可能。 ^[10] サーバー新規作成時のWebフォームから選択して申請。 10. 適宜バージョンアップされるため、最新情報を確認してください。
6.2	サーバーのタイプ	サーバータイプはニフクラOVM　OVMサーバータイプ・仕様から選択可能。 ^[11] 業務要件に合わせて選択。なお、定量的な性能値は公表されていません。 Oracle Database のエディションによっては、1DB あたりのスレッド数が制限されている場合があります。仕様についてはオラクル社にご確認のうえ、適切なサーバータイプを選択してください。 11. 適宜バージョンアップされるため、最新情報を確認してください。

No.

要件

OVMの仕様

大項目

中項目

小項目

6.1

動作環境

動作仕様

対応OS

OVMで提供しているOSはニフクラOVM　OVMサーバータイプ・仕様で確認可能。 ^[10]
サーバー新規作成時のWebフォームから選択して申請。

10. 適宜バージョンアップされるため、最新情報を確認してください。

6.2

サーバーのタイプ

サーバータイプはニフクラOVM　OVMサーバータイプ・仕様から選択可能。 ^[11]
業務要件に合わせて選択。なお、定量的な性能値は公表されていません。
Oracle Database のエディションによっては、1DB あたりのスレッド数が制限されている場合があります。仕様についてはオラクル社にご確認のうえ、適切なサーバータイプを選択してください。

11. 適宜バージョンアップされるため、最新情報を確認してください。

サービス利用／システム特性／移行

No.	要件	OVMの仕様
大項目	中項目	小項目
7.1	サービス利用	稼働状況報告	サービスとして提供はしていません。利用者側で構築した監視環境等を利用し、利用者側で確認してください。
8.1	システム特性	負荷分散への対応	OVMでの負荷分散機能は提供していません。業務要件に基づいて、Oracle RAC・SEHA構成を選択して利用者側で負荷分散機能を構築してください。
8.2	システム連係	ニフクラ上で構築したシステムへはプライベートLANで連係可能です。利用者側で連係の仕組みを実装してください。連係例ニフクラからIPsec VPN通信を用いてインターネット経由により、オンプレミス環境やリージョン間を連係。プライベート接続サービスを用いて専用線/閉域網経由により、オンプレミス環境やリージョン間を連係。
9.1	移行	移行方法	オンプレミス仮想環境上のゲストOSの移行については、VMインポートの利用は不可。 OVM上で新規にサーバーを構築、オンプレミスとのデータ連係可能なネットワーク構成を構築し、データを転送する方式を検討する。

No.

要件

OVMの仕様

大項目

中項目

小項目

7.1

サービス利用

稼働状況報告

サービスとして提供はしていません。利用者側で構築した監視環境等を利用し、利用者側で確認してください。

8.1

システム特性

負荷分散への対応

OVMでの負荷分散機能は提供していません。業務要件に基づいて、Oracle RAC・SEHA構成を選択して利用者側で負荷分散機能を構築してください。

8.2

システム連係

ニフクラ上で構築したシステムへはプライベートLANで連係可能です。利用者側で連係の仕組みを実装してください。
- 連係例
  - ニフクラからIPsec VPN通信を用いてインターネット経由により、オンプレミス環境やリージョン間を連係。
  - プライベート接続サービスを用いて専用線/閉域網経由により、オンプレミス環境やリージョン間を連係。

9.1

移行

移行方法

オンプレミス仮想環境上のゲストOSの移行については、VMインポートの利用は不可。
OVM上で新規にサーバーを構築、オンプレミスとのデータ連係可能なネットワーク構成を構築し、データを転送する方式を検討する。

3.提供サーバーOS及びサーバータイプの検討

提供サーバーOS及び対応Oracle DBの選択指針

OVMで提供しているサーバーOSと対応するOracleDBの組み合わせは、ニフクラOVM（Oracle Database利用環境）サービス仕様書別紙の「対応 Oracle Database バージョン」を確認してください。
※適宜バージョンアップされるため、最新情報を確認してください。

提供サーバータイプ

OVMで提供しているサーバータイプはこちらを確認のうえ、構築するシステムに応じて選択して利用してください。
性能指針
- CPU性能：　ニフクラで提供しているType-h2相当の性能となります。
- ストレージ性能：　ニフクラで提供している高速ディスク相当の性能となります。
Oracle DB以外のOracle製品の利用について
- Oracle DB以外のOracle製品を利用したい場合、OVMでの利用可否を利用者自身でオラクル社へ確認してください。

BYOL時に必要となるOracleDBライセンス数について

ニフクラOVMサービス仕様書別紙の「Oracle Database ライセンス数」を確認してください。

サーバー提供の形態

OVMにおけるサーバーの提供形態は下記のようなイメージになります。

OVM提供範囲のみでは、外部のネットワークと接続できません。
必ず、ニフクラ環境の「プライベートLAN」をご利用のうえ、アクセス経路を確立してください。
イメージ図のように、OVMサーバーの利用シーンでは、接続した「プライベートLAN」上で、ニフクラ環境のサービスと組み合わせて利用する形態が前提となります。
Oracle Database及びライセンスは提供していません、利用者側で用意・導入する必要があります。

4.ニフクラとの連係方法の検討

ニフクラとの連係方法の検討

OVMで作成されたサーバーは、ニフクラ環境と同じく複数のユーザーが利用する共用環境上に作成されます。
OVMサーバーは ニフクラ環境からプライベートLAN 経由でのみ接続が可能な環境 であり、ネットワーク環境はユーザー別に分離されています。
外部のネットワークとの接続には、プライベートLAN経由でアクセス経路を確立してください。

ニフクラとの連係方法

ニフクラと連係するために必要なサービスについて紹介します。

※申し込みからサーバー払出し後のログインまでの手順を紹介している、「OVM スタートアップガイド」も併せて参照ください。

5.システムパターンと運用方式の検討

OVMの利用上の注意点

OVMはニフクラとは異なる仮想化基盤となっており、コントロールパネルなども提供されていないため、様々な注意点・制約事項があります。
以下、注意点・制約事項は運用方式を検討するうえでの前提条件として留意ください。

OVMサービスにおける注意点と制約
制約事項	詳細	代替となる対応手段
コントロールパネル非連係	コントロールパネルによる、利用者側でのオンデマンドのサーバー新規作成や再起動は不可。 ^[12] ニフクラ(パブリック)のサーバー経由でOS以上のレイヤーでログイン、サーバー運用をする必要がある。 12. OS内での再起動(Linux：rebootコマンド、Windows：スタートメニューから再起動など)は利用者側で行っても構いません。	Webフォームによる申請ベースで新規作成など各機能を提供。各機能についての詳細は仕様書を参照。
停止を伴うメンテナンスの発生	ライブマイグレーションがオラクル社の規約上禁止されているため、HA後の復旧作業時や、仮想・物理基盤メンテナンス時に、利用者サーバーの停止が伴うメンテナンスが発生する。	Oracle RAC・SEHA環境を構築することで、仮想化基盤メンテナンスの際にもデータベース停止時間の最小化が可能。
オラクル社のポリシー変更による影響	オラクル社の方針変更により、オラクル製品利用に制約が加わる可能性がある。	特になし。

【参考】ニフクラのリージョンとゾーンについて

データセンターが存在する独立した地域のことを「リージョン」と定義しています。
ニフクラは、契約することで複数の国や地域など、地理的に離れた場所にあるリージョンを利用可能です。
リージョンの中に複数のゾーンが存在し、別のシステムとして運用されています。サーバーが収容されているラックや電源、ストレージなどは、ゾーン別に分離されています。

※リージョンによってゾーンの数は異なります。

OVMのリージョンとゾーンについて

OVMの提供は一部リージョンのみとなります。詳細はこちらを確認してください。
OVMにはニフクラのようなゾーンという概念はありません。同一リージョン内であれば、どのニフクラのゾーンからでもOVM環境へ接続できます。

システムパターンの検討

OVMで適用できるシステムパターンは下記のとおりです。

OVMはSLAの対象外となります
障害発生の状況やシステム構成などにより、停止時間は異なるため目安としてください。記載の停止時間を実現するには、提供機能以外の部分で利用者側でも設計・構築が必要です。

災害対策 (地理的冗長)	ゾーン規模障害対策	サーバーSLA対象	許容可能な停止時間	推奨適用システムパターン	OVMでの適用可否
要	要	対象	無停止～数分	マルチリージョンマルチゾーン	不可
不要	対象	無停止～数分	マルチリージョンシングルゾーン	不可
不要	要	対象	無停止～数時間	シングルリージョンマルチゾーン	不可
不要	対象外	無停止～数日程度	シングルリージョン Oracle RAC・SEHA構成	可能
対象外	数時間～数日程度	シングルリージョンシングル構成スタンバイサーバー利用	可能
対象外	数日程度	シングルリージョンシングル構成	可能

災害対策 (地理的冗長)

ゾーン規模
障害対策

サーバーSLA対象

許容可能な停止時間

推奨適用システムパターン

OVMでの適用可否

要

対象

無停止～数分

マルチリージョンマルチゾーン

不可

不要

対象

無停止～数分

マルチリージョンシングルゾーン

不可

不要

要

対象

無停止～数時間

シングルリージョンマルチゾーン

不可

不要

対象外

無停止～数日程度

シングルリージョン Oracle RAC・SEHA構成

可能

対象外

数時間～数日程度

シングルリージョンシングル構成スタンバイサーバー利用

可能

対象外

数日程度

シングルリージョンシングル構成

可能

システムパターン比較表

以下にOVMでとれるシステムパターンの比較表を記載します。

	シングルリージョン・Oracle RAC・SEHA構成	シングルリージョン・スタンバイサーバー利用構成	シングルリージョン・シングル構成
構成要素
シングルリージョン構成のリージョン内において、Oracle RAC・SEHAでサーバーの冗長性を確保する構成を前提としたシステム構成	シングルリージョン・シングル構成のサーバーの他にスタンバイサーバーを用意し、障害発生時などにサーバー復旧時間を短縮することを目的とした構成	シングルリージョン、サーバーもシングル構成としたロケーション及びサーバー自体も冗長性を持たない運用を前提としたシステム構成
物理サーバー障害時の挙動	片系でサービス継続 (ダウンしたサーバーはHAによる再起動後、RACに復旧)	再起動(HA)	再起動(HA)
単一サーバー障害時システム復旧に必要な対応	サーバー切り離し	スタンバイサーバーへ切り替え＋リストア	サーバー再作成＋リストア
単一サーバー障害時復旧目安時間	数十秒～数分	1時間～＋リストア時間	新規作成申請～新規作成完了時間＋リストア時間
サーバーコスト	2台分	1台分＋スタンバイサーバー分のコスト	1台分
OracleDBライセンスコスト	2台分(＋RAC/SEHAに必要となるオプションライセンス等)	1～2台分(スタンバイサーバー内のDB有無による)	1台分

シングルリージョン・Oracle RAC・SEHA構成

シングルリージョン・スタンバイサーバー利用構成

シングルリージョン・シングル構成

構成要素

シングルリージョン構成のリージョン内において、Oracle RAC・SEHAでサーバーの冗長性を確保する構成を前提としたシステム構成

シングルリージョン・シングル構成のサーバーの他にスタンバイサーバーを用意し、障害発生時などにサーバー復旧時間を短縮することを目的とした構成

シングルリージョン、サーバーもシングル構成としたロケーション及びサーバー自体も冗長性を持たない運用を前提としたシステム構成

物理サーバー障害時の挙動

片系でサービス継続 (ダウンしたサーバーはHAによる再起動後、RACに復旧)

再起動(HA)

単一サーバー障害時
システム復旧に必要な対応

サーバー切り離し

スタンバイサーバーへ切り替え＋リストア

サーバー再作成＋リストア

単一サーバー障害時
復旧目安時間

数十秒～数分

1時間～＋リストア時間

新規作成申請～新規作成完了時間＋リストア時間

サーバーコスト

2台分

1台分＋スタンバイサーバー分のコスト

1台分

OracleDBライセンスコスト

2台分(＋RAC/SEHAに必要となるオプションライセンス等)

1～2台分(スタンバイサーバー内のDB有無による)

1台分

OVMは、リージョン・ゾーン障害に対する対策はとれませんので、ご留意をお願いします。
HAが発動した場合、別の物理サーバーにて再起動されます。
HA発動後、元の物理サーバーへ戻すためにサーバーの停止を伴うメンテナンス作業が発生します。
Oracle RAC・SEHA構成にする場合、サーバーセパレート機能の利用が必須となります。この結果、稼働するVMは新規作成並びにHAからの復旧時に、別々の物理サーバーに配置されます。
本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。RTOが重要な場合はスタンバイサーバー利用若しくはOracle RAC・SEHA構成を推奨します。
「OVMサーバー障害」に関して、ここではカーネルパニック、OS自体が起動しないなどの状況を想定しています。

シングルリージョン：Oracle RAC・SEHA構成

以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。

No.	適用システムパターン	利用者が実施すべき作業内容
1		OVM環境でOracle RAC・SEHA構成によりサーバーの冗長化を確保したシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。【作業概要】所定のWeb申請フォームよりOracle RAC・SEHA構成利用、サーバーセバレート利用を含めたサーバー新規作成の申請をしてください。本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。サーバー払い出し後のOracle DBインストール、RAC構築、セキュリティ対策などを含めたシステム構築は利用者自身で設計・構築することになります。【リージョン障害対策】シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。【ゾーン障害対策】シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。【物理サーバー故障対策】 Oracle RAC・SEHA機能によりフェイルオーバーが行われ、別の物理サーバーへ切り替わります。(利用者設計) OVM環境基盤障害にて物理サーバーに障害が発生した際、別の物理サーバーへ自動で切り替わります。(HA) HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。【ストレージ障害対策】障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。【運用】障害検知のための監視サーバーはニフクラ側に用意します。ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[13] 13. ニフクラ側にバックアップデータ保存用サーバーを構築します。

No.

適用システムパターン

利用者が実施すべき作業内容

OVM環境でOracle RAC・SEHA構成によりサーバーの冗長化を確保したシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

【作業概要】

所定のWeb申請フォームよりOracle RAC・SEHA構成利用、サーバーセバレート利用を含めたサーバー新規作成の申請をしてください。
本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。
サーバー払い出し後のOracle DBインストール、RAC構築、セキュリティ対策などを含めたシステム構築は利用者自身で設計・構築することになります。

【リージョン障害対策】

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

【ゾーン障害対策】

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

【物理サーバー故障対策】

Oracle RAC・SEHA機能によりフェイルオーバーが行われ、別の物理サーバーへ切り替わります。(利用者設計)
OVM環境基盤障害にて物理サーバーに障害が発生した際、別の物理サーバーへ自動で切り替わります。(HA)
HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。

【運用】

障害検知のための監視サーバーはニフクラ側に用意します。
ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[13]

13. ニフクラ側にバックアップデータ保存用サーバーを構築します。

シングルリージョン：スタンバイサーバー利用構成

以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。

No.	適用システムパターン	利用者が実施すべき作業内容
2		OVM環境でスタンバイサーバーを利用しサーバーの可用性を向上させたシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。【作業概要】所定のWeb申請フォームよりスタンバイサーバー利用を含めたサーバー新規作成の申請をしてください。本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。サーバー払い出し後のOracle DBインストール、バックアップ／リストア方法、セキュリティ対策などを含めたシステム構築は利用者自身で設計・構築することになります。【リージョン障害対策】シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。【ゾーン障害対策】シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。【物理サーバー故障対策】 OVM環境基盤障害にて物理サーバーに障害が発生した際、別物理サーバーへ自動で切り替わります。(HA) HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。【ストレージ障害対策】障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。【運用】障害検知のための監視サーバーはニフクラ側に用意します。スタンバイサーバーへの切り替えを想定し、データ及びREDOログなどの保存先として、ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[14] 14. ニフクラ側にバックアップデータ保存用サーバーを構築します。

No.

適用システムパターン

利用者が実施すべき作業内容

OVM環境でスタンバイサーバーを利用しサーバーの可用性を向上させたシステム構成例となります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

【作業概要】

所定のWeb申請フォームよりスタンバイサーバー利用を含めたサーバー新規作成の申請をしてください。
本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。
サーバー払い出し後のOracle DBインストール、バックアップ／リストア方法、セキュリティ対策などを含めたシステム構築は利用者自身で設計・構築することになります。

【リージョン障害対策】

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

【ゾーン障害対策】

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

【物理サーバー故障対策】

OVM環境基盤障害にて物理サーバーに障害が発生した際、別物理サーバーへ自動で切り替わります。(HA)
HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。

【運用】

障害検知のための監視サーバーはニフクラ側に用意します。
スタンバイサーバーへの切り替えを想定し、データ及びREDOログなどの保存先として、ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[14]

14. ニフクラ側にバックアップデータ保存用サーバーを構築します。

シングルリージョン：サーバーシングル構成

以下にシステム構成例を実現するために利用者が実施すべき作業を記載します。

No.	適用システムパターン	利用者が実施すべき作業内容
3		OVM環境で冗長性を持たない運用を前提としたシステム構成例になります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。【作業概要】所定のWeb申請フォームよりサーバー新規作成の申請をしてください。本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。サーバー払い出し後のOracle DBインストール、セキュリティ対策などを含めたシステム構築は利用者自信で設計・構築することになります。【リージョン障害対策】シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。【ゾーン障害対策】シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。【物理サーバー故障対策】 OVM環境基盤障害にて物理サーバーに障害が発生した際、別物理サーバーへ自動で切り替わります。(HA) HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。【ストレージ障害対策】障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。【運用】障害検知のための監視サーバーはニフクラ側に用意します。ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[15] 15. ニフクラ側にバックアップデータ保存用サーバーを構築します。

No.

適用システムパターン

利用者が実施すべき作業内容

OVM環境で冗長性を持たない運用を前提としたシステム構成例になります。本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

【作業概要】

所定のWeb申請フォームよりサーバー新規作成の申請をしてください。
本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。
サーバー払い出し後のOracle DBインストール、セキュリティ対策などを含めたシステム構築は利用者自信で設計・構築することになります。

【リージョン障害対策】

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

【ゾーン障害対策】

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

【物理サーバー故障対策】

OVM環境基盤障害にて物理サーバーに障害が発生した際、別物理サーバーへ自動で切り替わります。(HA)
HA発動後には、元の物理サーバーへ戻すために、サーバーの停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

障害(故障)が発生した際、冗長化された経路またはコントローラ切り替わりにより自動的にI/Oが再開されます。

【運用】

障害検知のための監視サーバーはニフクラ側に用意します。
ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 ^[15]

15. ニフクラ側にバックアップデータ保存用サーバーを構築します。

Oracle RAC・SEHA構成

OVM環境でOracle RAC・SEHA構成によりサーバーの冗長化を確保したシステム構成例の概念図です。
図に記載された吹き出しはRAC構成を組む場合に必要な設定であり、サーバー新規作成申し込み時に、オプションメニューとして同時に申し込んでください。

本パターンを構築するための主要検討事項

No.	検討事項	対策観点	検討内容	検討時の重点ポイント
1	リージョン障害	災害対策 (地理的冗長)	シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。	－
2	ゾーン障害	ゾーン規模障害対策	シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。	－
3	物理サーバー	メンテナンス時対策	計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。	データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。 Oracle RAC・SEHA構成の場合フェイルオーバーにより、データベースの処理は継続されます。メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。
4	ネットワークノード	メンテナンス時対策	ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。	ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
5	ストレージノード	メンテナンス時対策	メンテナンス期間中は対象サーバーの停止・起動が発生します。	物理サーバーと同様の考え方となります。
6	サーバー	メンテナンス時対策	ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。	物理サーバーと同様の考え方となります。
7	物理サーバー	OVM環境障害対策	サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。	HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。
8	ネットワーク機器	OVM環境障害対策	ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
9	ストレージ機器	OVM環境障害対策	ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
10	サーバー	OVM環境障害対策	サーバーのOS層以上については、サービス側での対策はありません。	障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。 HA後のメンテナンス後にOracle RAC・SEHA構成を正常に戻すためのリカバリ操作などの復旧方式については、利用者にて別途設計してください。
11	監視	OVM環境障害対策	監視環境を別途構築する場合は、ニフクラ側で構築することになります。	OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。障害発生時の通知方法を含む運用については、利用者にて別途設計してください。システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。
12	バックアップ	OVM環境障害対策	ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】ニフクラまたは、ニフクラ外へのバックアップができます。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[16] ^[17] ^[18] 16. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。 17. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。 18. 富士通によるOracle RAC構成下での検証は実施していません。利用者側の判断にて導入を検討してください。	ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。バックアップ【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】バックアップ対象となるサーバーから、インターネットへの接続が必須です。バックアップはニフクラ側にバックアップサーバーを構築して保存するか、ニフクラを経由してAcronisのクラウドストレージに保存する方法があります。【その他ソフトウェア】利用者が用意したバックアップソフトウェア利用時においても、バックアップ保存先はOVM環境以外を推奨します。リストア・リカバリデータリストア時は、ニフクラ側に保存したデータをリストアします。システムフルリカバリを検討する場合は、新規構築したOracle RAC・SEHA構成に対しデータリストアをし再構築する方式などが考えられます。若しくは、あらかじめ低スペックサーバーを待機系として用意しておき、そのサーバーに対してデータリストアし縮退稼働させ、縮退運転中に再構築する方法なども考えられます。この待機系サーバーで縮退稼働させる場合、IPアドレス、ホスト名などは本番系サーバーとは異なることは留意してください。 OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリはできません。 ^[19] 19. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

リージョン障害

災害対策 (地理的冗長)

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

－

ゾーン障害

ゾーン規模障害対策

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

－

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。

データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
Oracle RAC・SEHA構成の場合フェイルオーバーにより、データベースの処理は継続されます。
メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。

ネットワークノード

メンテナンス時対策

ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。

ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

ストレージノード

メンテナンス時対策

メンテナンス期間中は対象サーバーの停止・起動が発生します。

物理サーバーと同様の考え方となります。

サーバー

メンテナンス時対策

ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。

物理サーバーと同様の考え方となります。

物理サーバー

OVM環境障害対策

サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。

HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。

ネットワーク機器

OVM環境障害対策

ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

ストレージ機器

OVM環境障害対策

ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

サーバー

OVM環境障害対策

サーバーのOS層以上については、サービス側での対策はありません。

障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。
HA後のメンテナンス後にOracle RAC・SEHA構成を正常に戻すためのリカバリ操作などの復旧方式については、利用者にて別途設計してください。

監視

OVM環境障害対策

監視環境を別途構築する場合は、ニフクラ側で構築することになります。

OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。
障害発生時の通知方法を含む運用については、利用者にて別途設計してください。
システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。

バックアップ

OVM環境障害対策

ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。

【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】

ニフクラまたは、ニフクラ外へのバックアップができます。
バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。
ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。
バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[16] ^[17] ^[18]

16. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。

17. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。

18. 富士通によるOracle RAC構成下での検証は実施していません。利用者側の判断にて導入を検討してください。

ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。
バックアップ
【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】
バックアップ対象となるサーバーから、インターネットへの接続が必須です。

バックアップはニフクラ側にバックアップサーバーを構築して保存するか、ニフクラを経由してAcronisのクラウドストレージに保存する方法があります。
【その他ソフトウェア】
利用者が用意したバックアップソフトウェア利用時においても、バックアップ保存先はOVM環境以外を推奨します。
リストア・リカバリ
- データリストア時は、ニフクラ側に保存したデータをリストアします。
- システムフルリカバリを検討する場合は、新規構築したOracle RAC・SEHA構成に対しデータリストアをし再構築する方式などが考えられます。
- 若しくは、あらかじめ低スペックサーバーを待機系として用意しておき、そのサーバーに対してデータリストアし縮退稼働させ、縮退運転中に再構築する方法なども考えられます。この待機系サーバーで縮退稼働させる場合、IPアドレス、ホスト名などは本番系サーバーとは異なることは留意してください。
- OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリはできません。 ^[19]

19. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

スタンバイサーバー利用構成

スタンバイサーバーは任意のタイミングで利用者の依頼元サーバーからコールドクローンすることにより作成されます。
スタンバイサーバーへの切り替えも任意のタイミングで可能ですが、データの復元方法などは別途検討が必要となります。

本パターンを構築するための主要検討事項

No.	検討事項	対策観点	検討内容	検討時の重点ポイント
1	リージョン障害	災害対策(地理的冗長)	シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。	－
2	ゾーン障害	ゾーン規模障害対策	シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。	－
3	物理サーバー	メンテナンス時対策	計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。	データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。
4	ネットワークノード	メンテナンス時対策	ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。	ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
5	ストレージノード	メンテナンス時対策	メンテナンス期間中は対象サーバーの停止・起動が発生します。	物理サーバーと同様の考え方となります。
6	サーバー	メンテナンス時対策	ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。	物理サーバーと同様の考え方となります。
7	物理サーバー	OVM環境障害対策	サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。	HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。
8	ネットワーク機器	OVM環境障害対策	ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
9	ストレージ機器	OVM環境障害対策	ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
10	サーバー	OVM環境障害対策	サーバーのOS層以上については、サービス側での対策はありません。	障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。
11	監視	OVM環境障害対策	監視環境を別途構築する場合は、ニフクラ側で構築することになります。	OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。障害発生時の通知方法を含む運用については、利用者にて別途設計してください。システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。
12	バックアップ	OVM環境障害対策	スタンバイサーバーの特徴は以下のとおりです。以降スタンバイサーバーではない、本番稼働サーバーを「本番サーバー」と呼びます。本番サーバーのクローンで作成される。スタンバイサーバーに切り替えた際のIPアドレスは本番サーバーと同じものが付与される。本番サーバーと並行起動はできない。 Oracle導入済みの本番サーバーがクローンされた場合、Oracleライセンスが追加で必要となる。スタンバイサーバーは最新化も可能。これらの特徴を踏まえ、設計時は以下を検討してください。スタンバイサーバーの作成タイミング(Oracle導入前後いずれか) スタンバイサーバー最新化の実施有無スタンバイサーバー利用を前提としたバックアップ設計スタンバイサーバーへのリストア設計ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。 ^[20] 【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】ニフクラまたは、ニフクラ外へのバックアップができます。ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。 OVMサーバーにOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[21] 20. バックアップ/リカバリ運用に関して詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。 21. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。	ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。スタンバイサーバー利用を前提としたバックアップ【システム領域】スタンバイサーバー作成タイミングをシステムバックアップとする。スタンバイサーバー作成タイミングによっては、Oracleライセンスが追加発生します。【データベース領域】保存先はOVM環境以外を推奨します。ニフクラ側などを検討してください。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）などのバックアップソフトの利用を検討してください。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[22] ^[23] 【REDOログ】データベース同様、OVM環境以外に保存するよう検討してください。スタンバイサーバー利用を前提としたリストアスタンバイサーバー作成タイミングにより下記2パターンのリストア方式になります。 ①Oracle新規インストールを含むリストア ②データベース、REDOログからのリストアスタンバイサーバーへの切り替えについてスタンバイサーバーへの切り替え後は、本番サーバーはスタンバイサーバーに降格されます。 22. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。 23. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

リージョン障害

災害対策(地理的冗長)

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

－

ゾーン障害

ゾーン規模障害対策

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

－

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。

データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。

ネットワークノード

メンテナンス時対策

ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。

ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

ストレージノード

メンテナンス時対策

メンテナンス期間中は対象サーバーの停止・起動が発生します。

物理サーバーと同様の考え方となります。

サーバー

メンテナンス時対策

物理サーバーと同様の考え方となります。

物理サーバー

OVM環境障害対策

HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。

ネットワーク機器

OVM環境障害対策

ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

ストレージ機器

OVM環境障害対策

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

サーバー

OVM環境障害対策

サーバーのOS層以上については、サービス側での対策はありません。

障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。

監視

OVM環境障害対策

監視環境を別途構築する場合は、ニフクラ側で構築することになります。

OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。
障害発生時の通知方法を含む運用については、利用者にて別途設計してください。
システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。

バックアップ

OVM環境障害対策

スタンバイサーバーの特徴は以下のとおりです。以降スタンバイサーバーではない、本番稼働サーバーを「本番サーバー」と呼びます。
- 本番サーバーのクローンで作成される。
- スタンバイサーバーに切り替えた際のIPアドレスは本番サーバーと同じものが付与される。
- 本番サーバーと並行起動はできない。
- Oracle導入済みの本番サーバーがクローンされた場合、Oracleライセンスが追加で必要となる。
- スタンバイサーバーは最新化も可能。
これらの特徴を踏まえ、設計時は以下を検討してください。
- スタンバイサーバーの作成タイミング(Oracle導入前後いずれか)
- スタンバイサーバー最新化の実施有無
- スタンバイサーバー利用を前提としたバックアップ設計
スタンバイサーバーへのリストア設計
ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。 ^[20]
【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】
ニフクラまたは、ニフクラ外へのバックアップができます。

ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。

OVMサーバーにOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[21]

20. バックアップ/リカバリ運用に関して詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。

21. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。
スタンバイサーバー利用を前提としたバックアップ
【システム領域】
スタンバイサーバー作成タイミングをシステムバックアップとする。

スタンバイサーバー作成タイミングによっては、Oracleライセンスが追加発生します。
【データベース領域】
保存先はOVM環境以外を推奨します。ニフクラ側などを検討してください。

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）などのバックアップソフトの利用を検討してください。

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[22] ^[23]
【REDOログ】
データベース同様、OVM環境以外に保存するよう検討してください。
スタンバイサーバー利用を前提としたリストア
- スタンバイサーバー作成タイミングにより下記2パターンのリストア方式になります。
  - ①Oracle新規インストールを含むリストア
  - ②データベース、REDOログからのリストア
スタンバイサーバーへの切り替えについて
- スタンバイサーバーへの切り替え後は、本番サーバーはスタンバイサーバーに降格されます。

22. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。

23. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。

サーバーシングル構成

OVM環境で冗長性を持たない運用を前提としたシステム構成例の概念図です。

本パターンを構築するための主要検討事項

No.	検討事項	対策観点	検討内容	検討時の重点ポイント
1	リージョン障害	災害対策(地理的冗長)	シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。	－
2	ゾーン障害	ゾーン規模障害対策	シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。	－
3	物理サーバー	メンテナンス時対策	計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。	データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。メンテナンス期間中の対応方針について、あらかじめ検討しておきます。
4	ネットワークノード	メンテナンス時対策	ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。	ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
5	ストレージノード	メンテナンス時対策	メンテナンス期間中は対象サーバーの停止・起動が発生します。	物理サーバーと同様の考え方となります。
6	サーバー	メンテナンス時対策	ネットワークノードやストレージコントローラ切り替えによって、OVM環境上に構築したシステムも瞬間的な通信断やI/O遅延または断が発生する場合があります。	物理サーバーと同様の考え方となります。
7	物理サーバー	OVM環境障害対策	サーバーには標準でHA機能が装備されているため、サーバーの稼働中にデータセンター内の物理サーバーが故障などにより停止した場合、そのホスト上で稼働していたサーバーを、自動的に別のホストに移動して稼働させることができます。このため、物理障害についてはHAでの自動復旧が見込めますが、この際、サーバーは強制シャットダウンで停止し、別物理サーバー上で再起動します。	HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。
8	ネットワーク機器	OVM環境障害対策	ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
9	ストレージ機器	OVM環境障害対策	ネットワーク機器切り替えの際に、ネットワーク通信断が発生する場合があります。ネットワーク機器やストレージ機器に異常が発生した場合、正常な基盤に原則自動的に経路またはコントローラが切り替わり、復旧します。	障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。
10	サーバー	OVM環境障害対策	サーバーのOS層以上については、サービス側での対策はありません。	障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。
11	監視	OVM環境障害対策	監視環境を別途構築する場合は、ニフクラ側で構築することになります。	OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。障害発生時の通知方法を含む運用については、利用者にて別途設計してください。システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。
12	バックアップ	OVM環境障害対策	ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。 ^[24] 【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】ニフクラまたは、ニフクラ外へのバックアップができます。ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。 OVMサーバーにOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[25] 24. バックアップ/リカバリ運用に関して詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。 25. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。	ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。バックアップ【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】バックアップ対象となるサーバーから、インターネットへの接続が必須です。バックアップはニフクラ側にバックアップサーバーを構築して保存するか、ニフクラを経由してAcronisのクラウドストレージに保存する方法があります。バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[26] ^[27] バックアップ【その他ソフトウェア】利用者が用意したバックアップソフトウェア利用時においても、バックアップ保存先はOVM環境以外を指定してください。リストア・リカバリデータリストア時は、ニフクラ側に保存したデータをリストアします。システムフルリカバリを検討する場合は、新規構築したサーバーに対しデータリストアをし再構築する方式などが考えられます。若しくは、あらかじめ低スペックサーバーを待機系として用意しておき、そのサーバーに対してデータリストアし縮退稼働させ、縮退運転中に再構築する方法なども考えられます。この待機系サーバーで縮退稼働させる場合、IPアドレス、ホスト名などは本番系サーバーとは異なることは留意してください。 OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリはできません。 ^[28] 26. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。 27. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。 28. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

リージョン障害

災害対策(地理的冗長)

シングルリージョン構成のため、利用中のリージョンが復旧するまでシステムが利用不可となります。

－

ゾーン障害

ゾーン規模障害対策

シングルゾーン構成のため、利用中のゾーンが復旧するまでシステムが利用不可となります。

－

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中は対象サーバーの停止・起動が発生します。

データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。
メンテナンス期間中の対応方針について、あらかじめ検討しておきます。

ネットワークノード

メンテナンス時対策

ネットワークノードの切り替えが発生し、経路切り替えに伴う瞬間的な通信断が発生する場合があります。

ネットワークの通信断が発生した場合、データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

ストレージノード

メンテナンス時対策

メンテナンス期間中は対象サーバーの停止・起動が発生します。

物理サーバーと同様の考え方となります。

サーバー

メンテナンス時対策

物理サーバーと同様の考え方となります。

物理サーバー

OVM環境障害対策

HA発生後には、移動したサーバーを元の構成に戻すためのメンテナンスが発生します。メンテナンスの際、もう一度サーバーの停止・起動操作が行われます。

ネットワーク機器

OVM環境障害対策

ネットワーク機器に異常が発生した場合、正常な基盤に原則自動的に経路が切り替わり、復旧します。

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

ストレージ機器

OVM環境障害対策

障害時間が許容範囲をこえる場合、オンプレミスのOracle環境とのハイブリッドクラウド構成も検討してください。

サーバー

OVM環境障害対策

サーバーのOS層以上については、サービス側での対策はありません。

障害検知については監視サービスや監視用のソフトウェアを導入することを推奨しています。

監視

OVM環境障害対策

監視環境を別途構築する場合は、ニフクラ側で構築することになります。

OVM環境を監視できるサービスは提供されていません。別途監視サーバーを構築してください。
障害発生時の通知方法を含む運用については、利用者にて別途設計してください。
システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)に監視サーバーを構築してください。

バックアップ

OVM環境障害対策

ニフクラで提供しているバックアップサービスでOVM環境にて利用可能と考えられるサービスは【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】となります。 ^[24]

【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】

ニフクラまたは、ニフクラ外へのバックアップができます。
ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。
バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用するには、インターネット接続できる経路が必要です。OVM環境からインターネット接続をするには、ニフクラ環境のオプション機能を利用してください。
OVMサーバーにOracleを導入した状態で、Acronisを利用してバックアップ/リストアを検証したブログを公開しています。参考にしてください。^[25]

24. バックアップ/リカバリ運用に関して詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。

25. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

ニフクラで提供している、ワンデイスナップショット・カスタマイズイメージ・バックアップと言ったバックアップ関連サービスはOVM環境では利用できません。
バックアップ
【バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）】
バックアップ対象となるサーバーから、インターネットへの接続が必須です。

バックアップはニフクラ側にバックアップサーバーを構築して保存するか、ニフクラを経由してAcronisのクラウドストレージに保存する方法があります。

バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）ではOracleのオンラインバックアップには対応していません。 ^[26] ^[27]
バックアップ【その他ソフトウェア】
利用者が用意したバックアップソフトウェア利用時においても、バックアップ保存先はOVM環境以外を指定してください。
リストア・リカバリ
- データリストア時は、ニフクラ側に保存したデータをリストアします。
- システムフルリカバリを検討する場合は、新規構築したサーバーに対しデータリストアをし再構築する方式などが考えられます。
- 若しくは、あらかじめ低スペックサーバーを待機系として用意しておき、そのサーバーに対してデータリストアし縮退稼働させ、縮退運転中に再構築する方法なども考えられます。この待機系サーバーで縮退稼働させる場合、IPアドレス、ホスト名などは本番系サーバーとは異なることは留意してください。
- OVMでは起動ディスク(CD/DVD等)をマウントする機能は非対応のためブータブルメディアを用いてのリカバリはできません。 ^[28]

26. Oracle DBのバックアップはオプション機能：アドバンスドバックアップにより可能となります。詳細についてはドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。

27. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。

28. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

Appendix

OVMバックアップ/リカバリ運用について

RPOとRTOの検討

先ずは、業務要件より適切なRPOとRTOを検討します。

どの時点のデータに復旧するか(RPO)

復旧させるデータのバックアップポイントとバックアップ方法を決める。

バックアップ取得ポイント
- 月次
- 週次
- 日次
- メンテナンス時
バックアップ取得方法
- フル
- 差分
- スナップショット
- REDOログ
バックアップの保管
- ローカルのデータセンター
- 他のデータセンター
バックアップの同期
- 同期
- 非同期

どの位の時間で復旧させるか(RTO)

復旧させるデータをどのくらいの時間で復旧させるか決める。

バックアップの状況によってRTOは変動
データ同期が不要なシステムのRTOは短い
- 参照系のシステム
データ同期が必須のシステムのRTOは長い
- バックアップだけでデータを戻せるか
- REDOログの適用の可否
- 災害発生時のロストデータの復旧方法(手入力？)
データ復旧後の整合性の確認が重要
- 自動的に整合性確認できるか
- 手作業が必要か
業務再開可能と判断する判断基準は何か
- IT管理者側のGo判断？
- システム利用者側のGo判断？

OVMバックアップについて

RPO,RTOに対して、ニフクラOVMで可能と考えられるバックアップ方法に関して記載します。

パターン	RPO	RTO	条件	バックアップ方法	適合システムパターン (システムパターンの検討参照)
バックアップ時OracleDBの停止可否	リカバリ時OVMサーバーの再構築可否	Oracleのデータ	OVMサーバー全体
1	障害発生直前	無停止	DBの停止不可	再構築不可	RMAN,dump,他バックアップ製品の持ち込みなど	Oracle RAC・SEHAの利用	Oracle RAC・SEHA構成
2	短期に復旧 (数時間)	DBの停止不可	再構築不可	RMANを利用ニフクラAcronis(オプション機能：アドバンスドバックアップ)利用	スタンバイサーバー+ニフクラAcronisを利用	スタンバイサーバー利用構成
3	長い停止も許容 (1日程度)	DBの停止可/不可	再構築可	RMAN,dump, 他バックアップ製品の持ち込みなどニフクラAcronis(オプション機能：アドバンスドバックアップ)利用	スタンバイサーバーを利用	スタンバイサーバー利用構成
4	日次バックアップ取得時点	短期に復旧 (数時間)	DBの停止可	再構築不可	RMAN,dump,ニフクラAcronisなど	スタンバイサーバー+ニフクラAcronisを利用	スタンバイサーバー利用構成
5	長い停止も許容 (1日程度)	DBの停止可	再構築可	RMAN,dump,ニフクラAcronis,他バックアップ製品の持ち込みなど	スタンバイサーバーを利用	スタンバイサーバー利用構成
6	15営業日以上	DBの停止可	再構築可	RMAN,dump,ニフクラAcronisなど	ニフクラAcronisを利用	シングル構成

パターン

RPO

RTO

条件

バックアップ方法

適合システムパターン (システムパターンの検討参照)

バックアップ時OracleDBの停止可否

リカバリ時OVMサーバーの再構築可否

Oracleのデータ

OVMサーバー全体

障害発生直前

無停止

DBの停止不可

再構築不可

RMAN,dump,他バックアップ製品の持ち込みなど

Oracle RAC・SEHAの利用

Oracle RAC・SEHA構成

短期に復旧 (数時間)

DBの停止不可

再構築不可

RMANを利用
ニフクラAcronis(オプション機能：アドバンスドバックアップ)利用

スタンバイサーバー+ニフクラAcronisを利用

スタンバイサーバー利用構成

長い停止も許容 (1日程度)

DBの停止可/不可

再構築可

RMAN,dump, 他バックアップ製品の持ち込みなど
ニフクラAcronis(オプション機能：アドバンスドバックアップ)利用

スタンバイサーバーを利用

スタンバイサーバー利用構成

日次バックアップ取得時点

短期に復旧 (数時間)

DBの停止可

再構築不可

RMAN,dump,ニフクラAcronisなど

スタンバイサーバー+ニフクラAcronisを利用

スタンバイサーバー利用構成

長い停止も許容 (1日程度)

DBの停止可

再構築可

RMAN,dump,ニフクラAcronis,他バックアップ製品の持ち込みなど

スタンバイサーバーを利用

スタンバイサーバー利用構成

15営業日以上

DBの停止可

再構築可

RMAN,dump,ニフクラAcronisなど

ニフクラAcronisを利用

シングル構成

補足事項/留意事項

OVMサーバーのバックアップ方法としてAcronisを利用する場合、他のバックアップ製品との併用はできません。
RMANの利用は利用者の責任範囲となります。
バックアップ製品を別途持ち込みし導入する場合、提供元にサポート可否等を確認してください。
想定している障害はOVMサーバー単体、データ消失レベルとなります。ゾーン/リージョン自体の障害は考慮できていません。必要に応じて遠隔地へのデータバックアップ等は検討してください。
「Acronis(オプション機能：アドバンスドバックアップ)利用」についてはOracleDBの対応バージョン、仕様等確認のうえ、利用を検討してください。

以下の注意事項に関して確認してください。

後述「スタンバイサーバーにおけるOracleライセンスの取り扱いについての注意」の章

OVMリカバリについて

各バックアップパターンで想定障害に応じたリカバリ方法案について記載します。

パターン	RPO	RTO	条件	バックアップ方法	(想定障害に応じた)リカバリ方法	適合システムパターン (システムパターンの検討参照)
バックアップ時OracleDBの停止可否	リカバリ時OVMサーバーの再構築可否	Oracleのデータ	OVMサーバー全体	データ破損	OVMサーバー一部障害	OVMサーバー障害
1	障害発生直前	無停止	DBの停止不可	再構築不可	RMAN,dump,他バックアップ製品の持ち込みなど	Oracle RAC・SEHAの利用	データリカバリ(RMAN,dumpなどを利用)	片系運用(+復旧作業)	片系運用(+復旧作業)	Oracle RAC・SEHA構成
2	短期に復旧(数時間)	DBの停止不可	再構築不可	RMANを利用, ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用	スタンバイサーバー+ニフクラAcronisを利用	データリカバリ(RMAN、ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用)	ニフクラAcronisでリカバリ	スタンバイサーバー+ニフクラAcronisでリカバリ	スタンバイサーバー利用構成
3	長い停止も許容(1日程度)	DBの停止可/不可	再構築可	RMAN,dump, 他バックアップ製品の持ち込みなど, ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用	スタンバイサーバーを利用	データリカバリ(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でリカバリ	シングル構成

パターン

RPO

RTO

条件

バックアップ方法

(想定障害に応じた)リカバリ方法

適合システムパターン (システムパターンの検討参照)

バックアップ時OracleDBの停止可否

リカバリ時OVMサーバーの再構築可否

Oracleのデータ

OVMサーバー全体

データ破損

OVMサーバー一部障害

OVMサーバー障害

障害発生直前

無停止

DBの停止不可

再構築不可

RMAN,dump,他バックアップ製品の持ち込みなど

Oracle RAC・SEHAの利用

データリカバリ(RMAN,dumpなどを利用)

片系運用(+復旧作業)

Oracle RAC・SEHA構成

短期に復旧(数時間)

DBの停止不可

再構築不可

RMANを利用,
ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用

スタンバイサーバー+ニフクラAcronisを利用

データリカバリ(RMAN、ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用)

ニフクラAcronisでリカバリ

スタンバイサーバー+ニフクラAcronisでリカバリ

スタンバイサーバー利用構成

長い停止も許容(1日程度)

DBの停止可/不可

再構築可

RMAN,dump, 他バックアップ製品の持ち込みなど,
ニフクラAcronis(オプション機能：アドバンスドバックアップ)を利用

スタンバイサーバーを利用

データリカバリ(RMAN、ニフクラAcronis(オプション機能：アドバンスドバックアップ)、dumpなどを利用)

スタンバイサーバーを利用してリカバリ

スタンバイサーバー利用構成

日次バックアップ取得時点

短期に復旧(数時間)

DBの停止可

再構築不可

RMAN,dump,ニフクラAcronisなど

スタンバイサーバー+ニフクラAcronisを利用

データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用)

ニフクラAcronisでリカバリ

スタンバイサーバー+ニフクラAcronisでリカバリ

スタンバイサーバー利用構成

長い停止も許容(1日程度)

DBの停止可

再構築可

RMAN,dump,ニフクラAcronis,他バックアップ製品の持ち込みなど

スタンバイサーバーを利用

データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用)

スタンバイサーバーを利用してリカバリ

スタンバイサーバー利用構成

15営業日以上

DBの停止可

再構築可

RMAN,dump,ニフクラAcronisなど

ニフクラAcronisを利用

データリカバリ(RMAN、ニフクラAcronis、dumpなどを利用)

ニフクラAcronisでリカバリ

新規OVM申請+ニフクラAcronisでリカバリ

シングル構成

補足事項/留意事項

Acronisを利用したリカバリ方法として大きく分けて以下2種類あります。
- AcronisのWebインターフェイスを利用したリカバリ
- ブータブルメディアを利用したリカバリ
OVM環境ではコンソール機能を提供しておらず、ブータブルメディアをマウントできません。そのためOVM環境でのリカバリはすべてAcronisのWebインターフェイスを利用する必要があります。
「Acronis(オプション機能：アドバンスドバックアップ)利用」についてはOracleDBの対応バージョン、仕様等確認のうえ、利用を検討してください。

想定障害についての例

データ破損: 一部Oracleデータが紛失した。
OVMサーバー一部障害: OSにパッチ適用したところ動作が不安定等、ただしOSにはログイン可能で、Acronisのエージェントも起動している
OVMサーバー障害: カーネルパニック、OS自体が起動しない等

補足

OVMサーバー一部障害/OVMサーバー障害の際の復旧について、Oracleのデータリカバリ作業も必要に応じて追加で実施してください。

システム構成と補足情報

基本となるシステム構成イメージと各パターン共通の補足情報について説明します。

Acronisを利用したOVMサーバーのシステムバックアップに関して、富士通では下記システム構成で検証しています。
- OVMサーバーとルーター(SNAT)は同一セグメントでの実施
ニフクラで提供しているバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）はAcronis Cyber Backup Standardの仕様を元に提供しています。アドバンスドバックアップ機能はオプションで提供しています。
Acronisと通信する際の通信要件は以下を確認してください。本構成ではニフクラルーターのSNAT構成としていますが、通信要件を満たせば他構成でも利用可能です。
クラウド技術仕様/制限値（ニフクラバックアップ/セキュリティサービス（Acronis Cyber Protect Cloud））_通信要件
事前の入念なバックアップ/リカバリテストを実施することを推奨します。

バックアップ/リカバリ方針のサンプル

サンプルとして、下記パターンに関して、バックアップ/リカバリ方針を例として記載します。

RPO	RTO	条件	バックアップ方法	適合システムパターン (システムパターンの検討参照)
バックアップ時OracleDBの停止可否	リカバリ時OVMサーバーの再構築可否	Oracleのデータ	OVMサーバー全体
障害発生直前	短期に復旧(数時間)	DBの停止不可	再構築不可	RMANを利用	スタンバイサーバー+ニフクラAcronisを利用	スタンバイサーバー利用構成

RPO

RTO

条件

バックアップ方法

適合システムパターン (システムパターンの検討参照)

バックアップ時OracleDBの停止可否

リカバリ時OVMサーバーの再構築可否

Oracleのデータ

OVMサーバー全体

障害発生直前

短期に復旧(数時間)

DBの停止不可

再構築不可

RMANを利用

スタンバイサーバー+ニフクラAcronisを利用

スタンバイサーバー利用構成

バックアップ方針

OVMサーバー全体(システム領域)は変更があるメンテナンス前後に取得する(パッチ適用等)
Oracleデータは日次で取得する

リカバリ方針

Oracleデータは障害発生直前までリカバリできることそのためREDOログの適用まで考慮する

以降に本サンプルにおけるバックアップ/リカバリの具体的実施例を説明します。他パターンは本パターンを参考にしてください。

ニフクラOVMでのバックアップ実施例
例として記載したバックアップ/リカバリ方針に対して、ニフクラOVMで実施するバックアップ例を記載します。
A：スタンバイサーバーを作成
取得タイミング：事前(最初に作成)
B：OVMサーバー全体(システム領域)のバックアップをAcronisで取得
取得タイミング：メンテナンス前後
C：RMANを利用してOracleデータバックアップ
取得タイミング：日次

想定障害に応じたリカバリ方法

想定障害に応じたリカバリ方法の詳細を以降に記載していきます。

RPO	RTO	バックアップ方法	(想定障害に応じた)リカバリ方法	適合システムパターン (システムパターンの検討参照)
Oracleのデータ	OVMサーバー全体	データ破損	OVMサーバー一部障害	OVMサーバー障害
障害発生直前	短期に復旧(数時間)	RMANを利用	スタンバイサーバー+ニフクラAcronisを利用	データリカバリ	ニフクラAcronisでリカバリ	スタンバイサーバー+ニフクラAcronisでリカバリ	スタンバイサーバー利用構成

RPO

RTO

バックアップ方法

(想定障害に応じた)リカバリ方法

適合システムパターン
(システムパターンの検討参照)

Oracleのデータ

OVMサーバー全体

データ破損

OVMサーバー
一部障害

OVMサーバー
障害

障害発生直前

短期に復旧(数時間)

RMANを利用

スタンバイサーバー+ニフクラAcronisを利用

データリカバリ

ニフクラAcronisでリカバリ

スタンバイサーバー+ニフクラAcronisでリカバリ

スタンバイサーバー利用構成

想定障害

①データ破損: 一部Oracleデータが紛失した。
②OVMサーバー一部障害: OSにパッチ適用したところ動作が不安定等、ただしOSにはログイン可能で、Acronisのエージェントも起動している
③OVMサーバー障害: カーネルパニック、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のライセンスは基本的に、Oracleインストールした台数分だけ必要になります。そのためスタンバイサーバーを利用する場合ライセンスに注意してください。
以下の2パターンで復旧の手順が異なります。
※上記「バックアップ/リカバリ方針のサンプル」を例に記載しています。その他のパターンの場合は手順が一部異なります。
- Oracleライセンスを二式(スタンバイサーバー分)、用意できる場合の復旧(こちらを推奨)
  1. スタンバイサーバーに切り替え申請
  2. Acronisでバックアップしていたデータを、スタンバイサーバーへリストア実施
  3. 必要に応じてRMANでのOracleデータ復旧
- Oracleライセンスを一式に抑えたい場合の復旧
  1. スタンバイサーバーに切り替え申請
    ⇒申し込み受領後1時間以内の着手
  2. Oracleが入っている元サーバー(入れ替わりでスタンバイサーバーになる)を削除
    ⇒5営業日以内を目安に対応
  3. 再度(Oracleの入っていない)新規のスタンバイサーバーを作成
    ⇒5営業日以内を目安に対応
  4. Acronisでバックアップしていたサーバー全体のバックアップを、元スタンバイサーバーへリストア実施
  5. 必要に応じてRMANでのOracleデータ復旧

【参考情報①】スタンバイサーバー利用時のAcronisバックアップ・リカバリについて

※富士通での検証結果を元にした情報であり、検証結果どおり動作を保証するものではありません。

スタンバイサーバー利用時の構成と検証概要

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すべてでバックアップ・リカバリが正常終了を確認。

【参考情報②】シングル構成下でのAcronisバックアップ・リカバリ時の考慮点

新規サーバーに対して同一IPアドレスで復元したい場合の情報となります。

富士通での検証結果を元にした情報であり、検証結果どおり動作を保証するものではありません。

シングル構成での検証概要

Oracle未導入のサーバーでの検証となります。

リストア対象サーバーは新規作成となり、Acronisエージェントも別途導入します。

①Acronisへバックアップ
検証を実施したOSは以下のとなります
- Oracle Linux7.6
- Windows Server 2012
②本番サーバーの疑似障害サーバーを停止
③サーバー新規作成
Webフォームからの申請となり、事前作成も可能。 ※本サービスでの新規サーバー用意に必要なリードタイムはサービス仕様書を参照してください。
④ ①で取得したバックアップを新規サーバーへリストア

リカバリ時の問題と対処方法

Acronisによるリストア後、復元したサーバーへ接続できない事象が発生した。

Windows Server 2012

原因

リストア後のサーバー再起動時にネットワークアダプタが初期化された影響でIPアドレスが反映されていないため。

対処

サーバー再起動後にネットワークアダプタが初期化されたことを確認後、IPアドレスを指定する(※)ことで接続可能になります。
ネットワークアダプタ名とIPアドレス設定を指定するバッチを作成しておき、タスクスケジューラなどでOS起動時実行を設定しておく。以下のバッチスクリプトサンプルも参考にしてください。

Oracle Linux 7.6

原因

ifcfg-eth0内の「HWADDR」(MACアドレス)が新規サーバーのものが指定されるため。

対処

ifcfg-eth0内の「HWADDR」をバックアップ元サーバーのMACアドレスを指定する(※)ことで接続可能になります。
事前にバックアップ元サーバーで以下の作業を実施しておく。
- ifcfg-eth0内の「HWADDR」を記載しない
- 70-persistent-ipoib.rulesに/dev/nullのシンボリックリンクをはる
  ※IPアドレスなどのネットワーク設定値はサーバー新規作成時に付与された設定値を指定してください。異なる設定値を指定した場合、サーバーへ接続できなくなる場合があります。

事前バッチスクリプトサンプル(Windows Server 2012)

対象サーバーの任意の場所に配置します。
実行には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バックアップ・リカバリ時のNG構成例

Acronisバックアップ・リカバリ時のNG構成例

下図の構成ではサーバー全体のリストア時、スタティックルート情報が参照できず、バックアップサーバーまで疎通できないため、有事の際リストアできない構成となります。留意してください。
- バックアップ構成
  - Acronisへの通信はルーターSNATを利用(緑線)
  - バックアップ先はハウジング環境のバックアップサーバー(紫線)(スタティックルートでネクストホップをハウジング環境のルーター)
- リストア時
  - サーバーに設定していたスタティックルート情報が参照できないため、バックアップサーバーまで疎通できない
参考FAQ
- Acronisでルーターを経由してローカルストレージ(ネットワークフォルダ、NFSフォルダ)に保存したバックアップデータからの復元が失敗する