本文へジャンプします。

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

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

ニフクラ ユーザーガイド

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

はじめに

  • 本ドキュメントは、OVM活用ガイドです。

  • ニフクラOVMサービス（以下、本サービスと呼びます）は、富士通が構築した、Oracle DatabaseライセンスのBYOL( Bring Your Own License )が可能なIaaS環境です。

  • 本サービスの利用者は、Oracle Databaseライセンスを持ち込むことが可能な仮想サーバー（以降、サーバーと呼び、物理サーバーとは区別して説明します）を所定の方法で作成し、そのサーバーにOracle Databaseをインストールして利用できます。

  • 本サービス環境は、パブリック等のニフクラ環境とは異なる仮想化基盤 (OracleVM/Oracle Linux Virtualization) を用いて、構築・運用されています。

  • 利用者に共通して提供されている機能やサービスを組み合わせて、システムを構築します。

  • システム要件によってはOVM環境への移行が不可となる場合があります。サービス仕様書及び、本ドキュメントを最後まで確認し、適用可否を判断してください。

  • ニフクラサービスの変更は、最新のドキュメントを参照してください。

適用判断手順の概要

適用判断手順の概要

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

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

    • OVMで対応ができないシステム要件や条件などを確認し、適用可否を判断します。

  2. OVMの適用判断事項

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

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

    • 提供サーバーOS及びサーバータイプの選択指針から、利用するサーバーを選択します。

    • 対応Oracle DBバージョンから選択します。

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

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

    • 可用性・業務継続性からシステムパターンを選択します。

    • サービス利用上の注意点から運用方式を検討します。

  6. Appendix

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

SLA／移行性

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

不適合条件

理由

SLA

クラウドサービスが定義するSLAを超えるSLA提供が必要

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

移行性

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

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

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

OVMサーバーは、対応OSのみ導入できます。
対応OSは、クラウド技術仕様/制限値(OVM)を確認してください。

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

OVMでは、VMインポート機能は提供していません。
動作環境／サポート

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

不適合条件

理由

動作環境

物理機器の利用が必要

OVMでは、物理機器は利用できません。

  • 例

    • プリンタ

    • FAX

    • スキャナ

    • テープデバイス

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

提供されているvCPUのみ利用可能です。
GPU搭載モデルのサーバータイプは、提供していません。

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

対応OSは、クラウド技術仕様/制限値(OVM)を確認してください。

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

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

複数NICが必要

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

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

厳密なレスポンスタイムが必要

OVMの性能は、ベストエフォートで提供されます。 [2]

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

インフラ基盤に厳格な動作要件が必要

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

サポート

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

OVMにおけるOS層以上のサポートは、以下のとおりです。
記載のサポートで要件を満たせない場合は、別会社とのサポート契約を検討してください。

  • Oracle Linuxのサポートは、富士通が一次受けします。 [3]

  • Windows Serverのサポートは、「Windows Server向けサポートデスク）」でサポートできます。
    詳細は、機能・サービス_サポート（Windows Server向けサポートデスク）を確認してください。

  • Oracle Database製品に対するオラクル社のサポートは、利用者が用意してください。

3. ニフクラでは、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の仕様

大項目

中項目

小項目

2.1

性能・拡張性

リソース拡張性

vCPU

2.2

メモリ

2.3

ストレージ

2.4

性能・拡張性

リソース拡張性

スケールアップ

  • vCPUスペック及びメモリ量は、サーバータイプの変更により拡張可能です。(No.2.1, No.2.2)
    ストレージ容量は、ディスクに保存されているデータ内容を維持したまま、領域拡張が可能です。(No.2.3)

  • サーバータイプの変更及び、ディスクの追加/拡張は、Webフォームから申請してください。

  • 申請時はあらかじめアプリケーション、RDBMSなどを停止してください。

スケールアウト

  • オートスケール機能は提供していません。

2.5

性能品質保証

  • 性能保証型のサービスではありません。

  • スケールアップ、アプリケーションチューニングなどを検討してください。
運用・保守性

No.

要件

OVMの仕様

大項目

中項目

小項目

3.1

運用・保守性

通常運用

バックアップ

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

  • OVM環境で利用できるバックアップ/リストア関連の機能及び制約は、以下のとおりです。

    • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）が、利用可能です。

    • OVMは、ベアメタルリカバリに非対応です。

    • OVMでは、CD/DVD等の起動ディスクをマウントできないため、ブータブルメディアを用いたリカバリはできません。 [5]

  • OVM環境以外にバックアップ環境の設計、構築を検討してください。

    • ベアメタルリカバリは利用できないため、システムフルリストア要件がある場合は、スタンバイサーバーオプションの利用を検討してください。

    • シングル構成のOVMサーバーにOracleを導入した状態で、Acronisを利用したバックアップ/リストア検証のブログ「 Acronis Cyber Protect Cloudを利用したバックアップ/リストアをOVMで実施する方法 」を、CLOUD NAVIに公開しています。参考にしてください。 [6]

4. 2020年1月時点で、富士通によるOracle RAC構成下での検証は実施していません。留意してください。
5. Acronisを利用したリストア方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。
6. ブログ内容は、検証結果の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」を検討します。 [7]

  • 業務システムのログ管理は、管理対象ログの決定、実装、取得のすべてが、利用者の責任範囲です。
    Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されています。導入するサーバーは、インターネットへの接続が必要です。
    OVM環境単体ではインターネット接続ができません。他のニフクラ機能との連係が必要です。

7. 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」を検討します。 [8]

  • 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）全般）_注意事項を参照してください。

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

No.

要件

OVMの仕様

選択値・条件

大項目

中項目

小項目

5.1

データセンター

外部監査

  • 外部機関から公的な認証を取得しています。

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

5.2

データセンターロケーション
動作環境

No.

要件

OVMの仕様

大項目

中項目

小項目

6.1

動作環境

動作仕様

対応OS

  • OVMで選択可能なOSは、クラウド技術仕様/制限値(OVM)を確認してください。 [9]

  • サーバー新規作成時のWebフォームで、OSタイプを選択して、申請します。

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

6.2

サーバータイプ

  • OVMのサーバータイプは、クラウド技術仕様/制限値(OVM)を確認してください。 [10]

  • サーバー新規作成時のWebフォームで、業務要件に合ったサーバータイプを選択して申請します。定量的な性能値は公表していません。

  • Oracle Databaseのエディションによっては、1DBあたりのスレッド数が制限されている場合があります。
    Oracle Databaseの仕様は、オラクル社に確認のうえ、適切なサーバータイプを選択してください。

10. 適宜バージョンアップされるため、最新情報を確認してください。
サービス利用／システム特性／移行

No.

要件

OVMの仕様

大項目

中項目

小項目

7.1

サービス利用

稼働状況報告

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

8.1

システム特性

負荷分散への対応

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

8.2

システム連係

  • ニフクラ上で構築したシステムとプライベートLANで連係可能です。利用者側で連係の仕組みを実装してください。

    • 連係例

      • ニフクラからIPsec VPN通信を用いたインターネット経由の通信により、オンプレミス環境やリージョン間を連係します。

      • プライベート接続サービスを用いた専用線/閉域網経由の通信により、オンプレミス環境やリージョン間を連係します。

9.1

移行

移行方法

  • オンプレミス仮想環境上のゲストOSをOVMへ移行する際、VMインポートは利用できません。

  • OVM上で新規にサーバーを構築し、オンプレミスとデータ連係が可能なネットワークを構築したうえで、データ転送の方式を検討します。

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

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

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

提供サーバータイプ

  • OVMで提供しているサーバータイプは、クラウド技術仕様/制限値(OVM)を確認のうえ、構築するシステムに応じて選択してください。

  • 性能指針

    • CPU性能：　ニフクラで提供しているType-h2相当の性能となります。

    • ストレージ性能：　ニフクラで提供している高速ディスク相当の性能となります。

  • Oracle DB以外のOracle製品の利用について

    • Oracle DB以外のOracle製品をOVMで利用したい場合は、利用者自身でOVMでの利用可否をオラクル社へ確認してください。

BYOL時に必要となるOracleDBライセンス数
サーバー提供の形態

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

image

  • OVM提供範囲のみでは、外部のネットワークと接続できません。

  • 必ず、ニフクラ環境の「プライベートLAN」を利用して、アクセス経路を確立してください。

  • イメージ図のように、OVMサーバーを利用するには、接続した「プライベートLAN」上で、ニフクラ環境のサービスと組み合わせて利用してください。

  • Oracle Database及びライセンスは提供していません。利用者側で用意・導入してください。

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

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

  • OVMで作成されたサーバーは、ニフクラ環境と同じく、複数のユーザーが利用する共用環境上に作成されます。

  • OVMサーバーは ニフクラ環境からプライベートLAN 経由でのみ接続が可能な環境 であり、ネットワーク環境はユーザー別に分離されています。

  • 外部のネットワークとの接続には、プライベートLAN経由でアクセス経路を確立してください。

ニフクラとの連係方法

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

image


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

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

OVMの利用上の注意点

  • OVMはニフクラとは異なる仮想化基盤であり、コントロールパネルなども提供されていないため、様々な注意点と制約事項があります。

  • 以下の注意点と制約事項は、運用方式を検討するうえでの前提条件として、留意してください。

OVMサービスにおける注意点と制約

制約事項

詳細

代替となる対応手段

コントロールパネル非連係

  • コントロールパネルの操作による、オンデマンドでのサーバーの新規作成や再起動はできません。 [11]

  • ニフクラ(パブリック)のサーバーを経由して、OS以上のレイヤーにログインし、サーバーを運用してください。

11. OS内での再起動(Linux：rebootコマンド、Windows：スタートメニューから再起動など)は利用者側で行っても構いません。

Webフォームによる申請で、新規作成など各機能を提供します。
各機能の詳細は、ニフクラOVM（Oracle Database利用環境） サービス仕様書を参照してください。

停止を伴うメンテナンスの発生

オラクル社の規約上、ライブマイグレーションが禁止されているため、HA後の復旧作業時や、仮想・物理基盤メンテナンス時には、利用者サーバーの停止を伴うメンテナンスが発生します。

Oracle RAC・SEHA環境を構築することで、仮想化基盤メンテナンスの際にも、データベース停止時間の最小化が可能です。

オラクル社のポリシー変更による影響

オラクル社のポリシー変更により、オラクル製品利用に制約が加わる可能性があります。

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

  • データセンターが存在する独立した地域のことを「リージョン」と定義しています。

  • ニフクラを契約すると、複数の国や地域など、地理的に離れた場所にあるリージョンが利用できます。

  • リージョンの中に複数のゾーンが存在し、それぞれ独立したシステムとして運用されています。サーバーが収容されているラックや電源、ストレージなどは、ゾーンごとに分離されています。

image


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

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

  • OVMの提供は一部リージョンのみです。詳細は、クラウド技術仕様/制限値(共通:ゾーン別機能対応表)を確認してください。

  • OVMには、ニフクラで提供されているゾーンの概念はありません。同一リージョン内であれば、どのニフクラのゾーンからでもOVM環境へ接続できます。

システムパターンの検討

OVMで適用可能なシステムパターンは、下記のとおりです。

  • OVMはSLAの対象外です。

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

災害対策 (地理的冗長)

ゾーン規模 障害対策

サーバーSLA対象

許容可能な停止時間

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

OVMでの適用可否

要

要

対象

無停止～数分

マルチリージョン：マルチゾーン構成

不可

不要

対象

無停止～数分

マルチリージョン：シングルゾーン構成

不可

不要

要

対象

無停止～数時間

シングルリージョン：マルチゾーン構成

不可

不要

対象外

無停止～数日程度

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

可能

対象外

数時間～数日程度

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

可能

対象外

数日程度

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

可能
システムパターン比較表

以下に、OVMで適用可能なシステムパターンの比較表を記載します。

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

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

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

構成要素

image

image

image

シングルリージョン構成のリージョン内で、Oracle RAC・SEHAによるサーバー冗長化を前提とした構成

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

シングルリージョンで、サーバーもシングル構成とし、ロケーション及びサーバーを冗長化しない運用を前提とした構成

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

片系でサービス継続

  • ダウンしたサーバーはHAによる再起動後、RACに復旧

HAによる再起動

HAによる再起動

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

サーバー切り離し

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

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

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

数十秒～数分

1時間～＋リストア時間

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

12. 元のサーバーと同じIPアドレスで申請してください。

サーバーコスト

2台分

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

1台分

OracleDBライセンスコスト

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

スタンバイサーバー内のDB有無による
* スタンバイサーバー内にDB有：1台分 * スタンバイサーバー内にDB無：2台分

1台分

  • OVMは、リージョン・ゾーン障害に対する対策はとれません。

  • HAが発動すると、別の物理サーバーで再起動されます。

  • HA発動後、元の物理サーバーへ戻すには、サーバーの停止を伴うメンテナンス作業が発生します。

  • Oracle RAC・SEHA構成では、サーバーセパレート機能の利用が必須です。これにより、稼働するVMは、新規作成時とHAからの復旧時に、異なる物理サーバーに配置されます。

  • 本サービスでの新規サーバー用意に必要なリードタイムは、ニフクラOVM（Oracle Database利用環境） サービス仕様書を参照してください。RTOが重要な場合は、スタンバイサーバー利用構成、もしくはOracle RAC・SEHA構成を推奨します。

  • 本ドキュメントにおいて「OVMサーバー障害」とは、カーネルパニック、OS自体が起動しないなどの状況を想定しています。

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

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

No.

適用システムパターン

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

1

image

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

【作業概要】

  • ニフクラOVM 利用申請フォームから、Oracle RAC・SEHA構成利用、サーバーセパレート利用を含めたサーバーの新規作成を申請してください。

  • 本サービスでの新規サーバー用意に必要なリードタイムは、ニフクラOVM（Oracle Database利用環境） サービス仕様書を参照してください。

  • サーバー払い出し後のOracle DBインストール、RAC構築、セキュリティ対策などを含めたシステム構築は、利用者自身で設計・構築してください。

【リージョン障害対策】

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

【ゾーン障害対策】

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

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

  • Oracle RAC・SEHA機能によりフェイルオーバーが発生し、別の物理サーバーへ切り替わります。

  • OVM環境基盤障害にて物理サーバーに障害が発生すると、HAが発動し、別の物理サーバーへ自動で切り替わります。

  • HA発動後、元の物理サーバーへ戻すには、サーバー停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

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

【運用】

  • 障害検知するには、ニフクラ側に監視サーバーを構築します。

  • バックアップデータを保存するには、ニフクラ側にバックアップサーバーを構築します。 [13]

13. ニフクラ側にバックアップデータ保存用サーバーを構築します。
シングルリージョン：スタンバイサーバー利用構成

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

No.

適用システムパターン

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

2

image

OVM環境で、スタンバイサーバーを用意し、障害発生時などのサーバー復旧時間の短縮を目的とした構成例となります。本構成例を実現するために、利用者側が実施すべき作業を以下に記載します。

【作業概要】

  • ニフクラOVM 利用申請フォームから、スタンバイサーバー利用を含めたサーバーの新規作成を申請してください。

  • 本サービスでの新規サーバー用意に必要なリードタイムは、ニフクラOVM（Oracle Database利用環境） サービス仕様書を参照してください。

  • サーバー払い出し後のOracle DBインストール、バックアップ／リストア方法、セキュリティ対策などを含めたシステム構築は、利用者自身で設計・構築してください。

【リージョン障害対策】

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

【ゾーン障害対策】

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

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

  • OVM環境基盤障害にて物理サーバーに障害が発生すると、HAが発動し別物理サーバーへ自動で切り替わります。

  • HA発動後、元の物理サーバーへ戻すには、サーバー停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

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

【運用】

  • 障害検知するには、ニフクラ側に監視サーバーを構築します。

  • バックアップデータを保存するには、スタンバイサーバーへの切り替えを想定し、データ及びREDOログなどの保存先として、ニフクラ側にバックアップサーバーを構築します。 [14]

14. ニフクラ側にバックアップデータ保存用サーバーを構築します。
シングルリージョン：サーバーシングル構成

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

No.

適用システムパターン

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

3

image

OVM環境で、ロケーション及びサーバーを冗長化しない運用を前提とした構成例になります。本構成例を実現するために、利用者側が実施すべき作業を以下に記載します。

【作業概要】
【リージョン障害対策】

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

【ゾーン障害対策】

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

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

  • OVM環境基盤障害にて物理サーバーに障害が発生すると、HAが発動し、別の物理サーバーへ自動で切り替わります。

  • HA発動後、元の物理サーバーへ戻すには、サーバー停止を伴うメンテナンス作業が発生します。

【ストレージ障害対策】

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

【運用】

  • 障害検知するには、ニフクラ側に監視サーバーを構築します。

  • バックアップデータを保存するには、ニフクラ側にバックアップサーバーを構築します。 [15]

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

  • OVM環境でOracle RAC・SEHA構成により、サーバー冗長化を確保したシステム構成例の概念図です。

  • 図に記載された吹き出しは、RAC構成を構築する場合に設定が必要です。サーバー新規作成申し込み時に、オプションメニューとして同時に申し込んでください。

    image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策 (地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

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

  • データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

  • Oracle RAC・SEHA構成の場合、フェイルオーバーにより、データベース処理は継続されます。

  • メンテナンス期間中の対応方針は、事前に検討してください。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

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

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

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インターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。
スタンバイサーバー利用構成

  • スタンバイサーバーは、利用者の依頼により、任意のタイミングで依頼元サーバーのコールドクローンとして作成されます。

  • スタンバイサーバーへの切り替えは任意のタイミングで可能ですが、データの復元方法などは別途検討が必要です。

image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

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

  • データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

  • メンテナンス期間中の対応方針は、事前に検討してください。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

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

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

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を利用したバックアップ/リストアの検証ブログ「 Acronis Cyber Protect Cloudを利用したバックアップ/リストアをOVMで実施する方法 」を、CLOUD NAVIに公開しています。参考にしてください。 [21]

20. バックアップ/リカバリ運用に関する詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。
21. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

  • ニフクラで提供しているバックアップ関連サービスの中で、ワンデイスナップショット・カスタマイズイメージ・バックアップは、OVM環境では利用できません。

  • スタンバイサーバー利用を前提としたバックアップ

    【システム領域】

    • スタンバイサーバー作成タイミングを、システムバックアップとします。

    • Oracle導入済みの本番サーバーからクローンされた場合、追加で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環境で、ロケーション及びサーバーを冗長化しない運用を前提としたシステム構成例の概念図です。

image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

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

  • データベースの整合性維持の観点から、メンテナンス期間の前後において、利用者作業としてデータベースの停止・起動を実施してください。

  • メンテナンス期間中の対応方針は、事前に検討してください。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

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

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

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を利用したバックアップ/リストア検証のブログ「 Acronis Cyber Protect Cloudを利用したバックアップ/リストアをOVMで実施する方法 」を、CLOUD NAVIに公開しています。参考にしてください。 [25]

24. バックアップ/リカバリ運用に関して詳細は「Appendix OVMバックアップ/リカバリ運用について」を参照してください。
25. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

  • ニフクラで提供しているバックアップ関連サービスの中で、ワンデイスナップショット・カスタマイズイメージ・バックアップは、OVM環境では利用できません。

  • バックアップ

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

    • バックアップ対象のサーバーから、インターネットへの接続が必須です。

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

    • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）では、Oracleのオンラインバックアップには対応していません。 [26] [27]

    バックアップ【その他ソフトウェア】

    • 利用者が用意したバックアップソフトウェア利用時においても、バックアップ保存先はOVM環境以外を推奨します。

  • リストア・リカバリ

    • データリストア時は、ニフクラ側に保存したデータをリストアします。

    • システムフルリカバリを検討する場合、新規構築したサーバーに対しデータリストアをして、再構築する方式などが考えられます。

      • 新規構築するサーバーは、元のサーバーと同じIPアドレスで申請してください。

    • もしくは、あらかじめ低スペックサーバーを待機系サーバーとして用意しておき、そのサーバーに対してデータリストアし縮退稼働させ、縮退稼働中に再構築する方法なども考えられます。この待機系サーバーで縮退稼働させる場合、IPアドレス、ホスト名などは本番系サーバーとは異なる点に留意してください。

    • OVMでは、CD/DVD等の起動ディスクをマウントできないため、ブータブルメディアを用いたリカバリはできません。 [28]

26. Oracle DBのバックアップは オプション機能：アドバンスドバックアップ により可能です。詳細は、ドキュメントを参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
27. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
28. Acronisを利用したリカバリ方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。

Appendix

OVMバックアップ/リカバリ運用について
RPOとRTOの検討

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

image

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

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

image

  • バックアップ取得ポイント

    • 月次

    • 週次

    • 日次

    • メンテナンス時

  • バックアップ取得方法

    • フル

    • 差分

    • スナップショット

    • REDOログ

  • バックアップの保管

    • ローカルのデータセンター

    • 他のデータセンター

  • バックアップの同期

    • 同期

    • 非同期

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

データ復旧にかかる時間を決めます。

image

  • バックアップの状況によってRTOは変動します。

  • データ同期が不要なシステムのRTOは短いです。

    • 参照系のシステム

  • データ同期が必須のシステムのRTOは長いです。

    • バックアップのみでのデータ復旧の可否

    • REDOログの適用の可否

    • 災害発生時のロストデータの復旧方法および手入力の有無

  • データ復旧後の整合性の確認が重要です。

    • 自動的な整合性確認の可否

    • 手作業による整合性確認の有無

  • 業務再開における判断基準や判断主体を明確にします。

    • IT管理者側での再開判断

    • システム利用者側での再開判断

OVMバックアップについて

RPO、RTOの観点で、ニフクラOVMで利用可能なバックアップ方法について記載します。

パターン

RPO

RTO

条件

バックアップ方法

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

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

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

Oracleのデータ

OVMサーバー全体

1

障害発生直前

無停止

DBの停止不可

再構築不可

  • RMANを利用

  • dumpを利用

  • 他バックアップ製品の持ち込みなど

Oracle RAC・SEHAの利用

Oracle RAC・SEHA構成

2

数時間の短期で復旧

DBの停止不可

再構築不可

  • RMANを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

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

3

1日程度の長い停止も許容

DBの停止可/不可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

  • 他バックアップ製品の持ち込みなど

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

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

4

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

数時間の短期で復旧

DBの停止可

再構築不可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

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

5

1日程度の長い停止も許容

DBの停止可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

  • 他バックアップ製品の持ち込みなど

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

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

6

15営業日以上

DBの停止可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

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

サーバーシングル構成
補足事項/留意事項

  • 「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」を利用する際は、以下を確認してください。

  • RMANの利用は利用者の責任範囲です。

  • バックアップ製品を別途持ち込んで導入する場合、提供元にサポート可否等を確認してください。

  • 記載内容は、OVMサーバー単体、データ消失レベルの障害を想定しています。ゾーン/リージョン自体の障害は考慮していません。必要に応じて、遠隔地へのデータバックアップ等を検討してください。

以下の注意事項に関して確認してください。
OVMリカバリについて

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

パターン

RPO

RTO

条件

バックアップ方法

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

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

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

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

Oracleのデータ

OVMサーバー全体

データ破損

OVMサーバー 一部障害

OVMサーバー 障害

1

障害発生直前

無停止

DBの停止不可

再構築不可

  • RMANを利用

  • dumpを利用

  • 他バックアップ製品の持ち込みなど

Oracle RAC・SEHAの利用

Oracleデータのバックアップ方法に対応したデータリカバリ

片系運用(+復旧作業)

片系運用(+復旧作業)

Oracle RAC・SEHA構成

2

数時間の短期で復旧

DBの停止不可

再構築不可

  • RMANを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

Oracleデータのバックアップ方法に対応したデータリカバリ

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

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）でリカバリ

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

3

1日程度の長い停止も許容

DBの停止可/不可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

  • 他バックアップ製品の持ち込みなど

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

Oracleデータのバックアップ方法に対応したデータリカバリ

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

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

4

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

数時間の短期で復旧

DBの停止可

再構築不可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

Oracleデータのバックアップ方法に対応したデータリカバリ

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

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）でリカバリ

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

5

1日程度の長い停止も許容

DBの停止可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

  • 他バックアップ製品の持ち込みなど

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

Oracleデータのバックアップ方法に対応したデータリカバリ

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

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

6

15営業日以上

DBの停止可

再構築可

  • RMANを利用

  • dumpを利用

  • バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

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

Oracleデータのバックアップ方法に対応したデータリカバリ

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

新規OVM申請 [29] +バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）でリカバリ

29. 元のサーバーと同じIPアドレスで申請してください。

サーバーシングル構成
補足事項/留意事項

  • 「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」を利用したリカバリ方法には、主に以下の2種類があります。

    • AcronisのWebインターフェイスを利用したリカバリ

    • ブータブルメディアを利用したリカバリ

  • OVM環境でのリカバリはすべて、AcronisのWebインターフェイスを利用してください。

    • OVM環境ではコンソール機能を提供しておらず、ブータブルメディアをマウントできません。

  • 「バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）」を利用する際は、OracleDBの対応バージョン、仕様等を確認してください。詳細は、クラウド技術仕様/制限値（ニフクラ バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud））を確認してください。

  • 「OVMサーバー 一部障害」、「OVMサーバー障害」からの復旧作業では、必要に応じて、Oracleデータもリカバリしてください。

想定障害についての例
データ破損

一部Oracleデータが紛失した。

OVMサーバー一部障害

OSへのパッチ適用後、動作が不安定になった。ただしOSにはログイン可能で、Acronisのエージェントも起動している。

OVMサーバー障害

カーネルパニックの発生やOSが起動しない。

システム構成と補足情報

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

  • 富士通では、Acronisを利用したOVMサーバーのシステムバックアップについて、下記システム構成で検証しています。

    • OVMサーバーとSNAT用のルーターは同一セグメントに配置

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

  • Acronisの通信要件は、クラウド技術仕様/制限値（ニフクラ バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud））_通信要件を確認してください。
    本構成ではニフクラルーターでSNATを構成していますが、通信要件を満たせば他の構成でも動作可能です。

  • 事前に、入念なバックアップおよびリカバリのテストを推奨します。

image

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

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

RPO

RTO

条件

バックアップ方法

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

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

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

Oracleのデータ

OVMサーバー全体

障害発生直前

数時間の短期で復旧

DBの停止不可

再構築不可

RMANを利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

スタンバイサーバー利用構成
バックアップ方針

  • OVMサーバーのシステム領域は、パッチ適用などの変更を伴うメンテナンス前後で取得する。

  • Oracleデータは日次で取得する。

リカバリ方針

  • Oracleデータは障害発生直前までのリカバリを実現するため、REDOログの適用まで考慮する。

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

  • ニフクラOVMでのバックアップ実施例
    例として記載したバックアップ/リカバリ方針に対して、ニフクラOVMで実施するバックアップ例を記載します。

    A：スタンバイサーバーを作成

    • 取得タイミング：事前(最初に作成)

    B：システム領域のバックアップをAcronisで取得

    • 取得タイミング：メンテナンス前後

    C：RMANを利用してOracleデータバックアップ

    • 取得タイミング：日次

image

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

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

RPO

RTO

バックアップ方法

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

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

Oracleのデータ

OVMサーバー全体

データ破損

OVMサーバー
一部障害

OVMサーバー
障害

障害発生直前

数時間の短期で復旧

RMANを利用

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）を利用

データリカバリ

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

スタンバイサーバー+バックアップ/セキュリティサービス（Acronis Cyber Protect Cloud）でリカバリ

スタンバイサーバー利用構成
想定障害
①データ破損

一部Oracleデータが紛失した。

②OVMサーバー一部障害

OSへのパッチ適用後、動作が不安定になった。ただしOSにはログイン可能で、Acronisのエージェントも起動している。

③OVMサーバー障害

カーネルパニックの発生やOSが起動しない。

想定障害とバックアップデータの要不要表

想定障害

各バックアップ手法で取得したデータのリカバリ必要可否

RMAN

Acronis

スタンバイサーバー

①

データ破損

必要

不要

不要

②

システム一部不具合

必要

必要

不要

③

OVMサーバー自体の障害

必要

必要

必要
想定障害シーン①のリカバリ
発生障害

  • 一部Oracleデータが紛失した。

リカバリ対応

  • RMANを利用して障害直前までリカバリ実施

想定障害シーン②のリカバリ
発生障害

  • OSへのパッチ適用後、動作が不安定になった。

  • OSにはログイン可能で、Acronisのエージェントも起動している。

リカバリ対応

  • A：Acronisでバックアップしたサーバー全体のバックアップを、本番サーバーへリストア実施

  • B：必要に応じてRMANでのOracleデータ復旧

image

想定障害シーン③のリカバリ
発生障害

  • カーネルパニックの発生やOSが起動しない。

リカバリ対応

image

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

  • Oracleライセンスに関して

    • Oracleのライセンスは基本的に、Oracleをインストールしたサーバーの台数分必要です。そのため、スタンバイサーバーを利用する際は、ライセンスに注意してください。

  • 以下の2パターンで復旧の手順が異なります。
    ※上記「バックアップ/リカバリ方針のサンプル」を例に記載しています。その他のパターンの場合は手順が一部異なります。

    • Oracleライセンスを二式(スタンバイサーバー分)、用意できる場合の復旧(こちらを推奨)

      1. スタンバイサーバーへの切り替えを申請する。

      2. Acronisでバックアップしていたデータを、スタンバイサーバーへリストアする。

      3. 必要に応じてRMANでOracleのデータを復旧する。

    • Oracleライセンスを一式に抑えたい場合の復旧

      1. スタンバイサーバーへの切り替えを申請する。

        • 申し込み受領後、1時間以内に着手します。

      2. スタンバイサーバーが主系サーバーへ昇格したら、スタンバイサーバーに降格した元主系サーバーの削除を申請する。

        • 5営業日以内を目安に実施してください。

      3. Oracleを導入する前に、主系サーバーを元に新規のスタンバイサーバーの作成を申請する。

        • 5営業日以内を目安に実施してください。

      4. Acronisで取得しておいたサーバー全体のバックアップを、元スタンバイサーバーへリストアする。

      5. 必要に応じてRMANでOracleのデータを復旧する。

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

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

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

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

  • スタンバイサーバー作成のタイミングはAcronisエージェント導入後になります。

image

  • ①Acronisへバックアップ
    検証したOSは以下のとおりです。

    • Oracle Linux7.6

    • Windows Server 2012

    • Windows Server 2016

  • ②本番サーバーの疑似障害サーバーを停止

  • ③スタンバイサーバーへ切り替え
    Webフォームからの申請を受け付け後、1時間以内を目安に着手し切り替えが実施されます。

  • ④ ①で取得したバックアップをスタンバイサーバーへリストア

検証方法と結果
検証方法

  1. 各OS内にAcronisエージェントをインストールし、Acronis管理画面にてデバイスが登録されたことを確認します。

  2. 各サーバーのOSの状態を記録します

    • Windows:ネットワークアダプタ名、ネットワークアダプタ内の設定、ipconfig /allの結果

    • Linux:ネットワークアダプタ名、ネットワークアダプタのifcfgの設定、ipaの結果

  3. 各OSをAcronis上にバックアップ

  4. スタンバイサーバーの新規作成を申請します。

    • Webフォームから申請してください。

    • スタンバイサーバー作成時にはサーバーが停止されるため、あらかじめ停止させておきます。

  5. 本番サーバーを停止します。

    • ハード故障を想定した疑似障害として、サーバーを停止します。

  6. スタンバイサーバーへの切り替えを申請します。

    • Webフォームから申請してください。

  7. Acronis管理画面にて本番サーバーへ昇格したサーバー(スタンバイサーバー)のデバイスが有効になることを確認します。

  8. Acronis側から本番サーバーに昇格したサーバー(スタンバイサーバー)へリストアを実施します。

  9. 本番サーバーへ昇格したサーバー(スタンバイサーバー)にログインできることを確認します。

検証結果

  • 検証したすべてのOSでバックアップ・リカバリの正常終了を確認

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

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

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

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

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

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

image

  • ①Acronisへバックアップ
    検証を実施したOSは以下のとおりです。

    • Oracle Linux7.6

    • Windows Server 2012

  • ②本番サーバーの疑似障害サーバーを停止

  • ③サーバー新規作成
    Webフォームから申請してください。
    ※新規サーバーは元のサーバーと同じIPアドレスで申請します。
    ※本サービスでの新規サーバー用意に必要なリードタイムは、ニフクラOVM（Oracle Database利用環境） サービス仕様書を参照してください。

  • ④ ①で取得したバックアップを新規サーバーへリストア

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

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

Windows Server 2012
原因

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

対処

  • サーバー再起動後にネットワークアダプタが初期化されたことを確認後、IPアドレスを指定する(※)ことで、復元したサーバーに接続できます。

  • ネットワークアダプタ名とIPアドレス設定を指定するバッチを作成しておき、タスクスケジューラなどでOS起動時に実行するよう設定しておきます。
    「事前バッチスクリプトサンプル(Windows Server 2012)」も参考にしてください。

Oracle Linux 7.6
原因

  • ifcfg-eth0内のMACアドレスを表す「HWADDR」に新規サーバーの値が設定されていた。

対処

  • 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構成例

image


フィードバック

サービス利用中のトラブルは、ニフクラサポート窓口にお願いします。

お役に立ちましたか？
  • ※本ページ記載の金額は、すべて税抜表示です。
  • ※本ページ記載の他社製品名および会社名などは、各社の商標または登録商標です。
  • ※本ページの内容は、2025年9月16日時点の情報です。

推奨画面サイズ　1024×768 以上

ページの先頭へ