本文へジャンプします。

TOP

ニフクラSEハンドブック

クラウド トップ>SEハンドブック>ニフクラOVM適用指針
本ページは2023/10/2をもって、新ページhttps://docs.nifcloud.com/ovm/guide/OVM-Guidelines.htmへ移行しました。 今後は新ページをご参照ください。

OVM適用指針

目次

ドキュメント情報

区分

適用指針

リリース日

2023年11月09日

■ニフクラホームページ

https://pfs.nifcloud.com/

はじめに

  • 本ドキュメントではOVM適用指針について記載しています。

  • OVMサービス （以下、本サービスと言います）は、富士通クラウドテクノロジーズが構築した、Oracle DatabaseライセンスのBYOL( Bring Your Own License )が可能なIaaS環境です。

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

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

  • 利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。よって、個別の要望には対応はできません。

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

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

    • ニフクラOVM基盤環境更新が予定されています。詳細は こちらを確認してください。

アイコンの説明

  • 本ドキュメント構成図に使用されているアイコンは下記のとおりとなります。

  • リージョン及びゾーンについて特に記載がなければ、単一リージョン、単一ゾーン構成を示します。

image

image

適用判断手順の概要

適用判断手順の概要

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

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

    • OVMで対応ができない利用者要件や条件などを確認し、適用可否を判断する

  2. OVMの適用判断事項

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

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

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

    • 対応Oracle DBバージョンから選択する

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

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

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

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

  6. Appendix

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

SLA／移行性

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

不適合条件

理由

SLA

クラウドサービスが定義しているSLAとして、月間稼働率99.99%をこえるSLA提供が必要

OVMは、SLA対象外となります。

移行性

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

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

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

OracleVMでサポートされているOS以外をOVMに構築できません。

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

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

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

不適合条件

理由

動作環境

物理機器の利用が必要

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

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

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

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

対応するOS[1]を以下に示します。

  • Windows Server 2012、Windows Server 2012 R2、Windows Server 2016、Windows Server 2019

  • Oracle Linux 7.6

1. 提供時期によってバージョンに違いあり

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

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

複数NICが必要

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

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

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

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

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

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

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

サポート

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

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

  • Oracle Linux のサポートについては富士通クラウドテクノロジーズが一次受けします。 [5]

  • Windows Serverのサポートについては、富士通株式会社が提供する「サポート（富士通サポートデスク）」を利用の場合、サポート可能です。詳細は こちらを確認してください。

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

4. 記載のサポートでは要件を満たさない場合など、別会社からのサポートサービス提供を検討する必要があります。
5. ニフクラでは、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

  • ①サーバータイプのvCPUスペックは以下のとおり。

    • vCPU性能：ニフクラで提供しているType-h2相当。

    • vCPU数：サーバータイプを変更することでvCPU数を選択可能。 [6]

  • ②サーバータイプの変更には、Webフォームから申請する。

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

6. 選択するサーバータイプによって、組み合わせ可能なメモリ量は異なります。サーバーは提供されているサーバータイプからのみ選択できます。

  • vCPU数 OVM：1/2/4/6/8/16 vCPU

2.2

メモリ

  • ①サーバーのメモリ量は以下のとおり。

    • サーバー：サーバータイプを変更することでメモリ量を選択可能。 [7]

  • ②サーバータイプの変更には、Webフォームから申請する。

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

7. 選択するサーバータイプによって、組み合わせ可能なvCPU数は異なる。

  • メモリ量 OVM：8/16/24/32/48/64/96/128/256GB

2.3

ストレージ

  • ①OVMディスクの仕様は右記のとおり。

  • ②ディスクの追加と拡張には、Webフォームから申請する。

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

  • 1サーバーにつき最大2本利用可能

  • 100GB~2TBまで100GB単位で指定可能

  • 1つ目のディスクはOSインストール領域として利用

2.4

性能・拡張性

リソース拡張性

スケールアップ

  • ①サーバータイプを変更することで可能。(No.2.1, No.2.2)
    ストレージ容量は、ディスクに保存されているデータ内容を維持したまま領域拡張が可能。(No.2.3)

  • ②サーバータイプの変更及び、ディスクの追加/拡張には、Webフォームから申請する。

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

スケールアウト
運用・保守性

No.

要件

OVMの仕様
(① サービス仕様　② 利用者の対処　③ 備考(影響など))

大項目

中項目

小項目

3.1

運用・保守性

通常運用

バックアップ

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

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

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

    • OVMはベアメタルリカバリに未対応

    • OVMでは起動ディスク(CD/DVD等)をマウントする機能は未提供のためブータブルメディアを用いてのリカバリ不可 [9]

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

  • ③

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

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

8. 2020年1月時点で、富士通クラウドテクノロジーズによるOracle RAC構成下での検証は実施していません。留意してください。
9. Acronisを利用したリストア方法は大きく分けて「AcronisのWebインターフェイスを利用したリカバリ」と「ブータブルメディアを利用したリカバリ」があります。
10. ブログ内容は、検証結果の1つとなります。実際に構成を検討されるときは、それぞれの要件を鑑みて十分に検証を実施してください。

3.2

運用監視

  • ① ハードウェア監視、ハイパーバイザー稼働監視等のOVM環境基盤側の監視については、サービス提供側で実施しています。
    サーバーのOS以上の監視サービスは提供されていないため、利用者側で検討してください。

  • ②監視ツールをサーバーに導入し、利用者側で構築した監視環境からの運用監視を検討してください。

  • ③監視ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。

3.3

保守運用

計画停止

  • ①品質基準の保持やサービスメニューの拡張を目的としたメンテナンスを実施する場合があります。実施する際には、60日前に事前連絡します。ただし、機器故障時などで緊急のメンテナンスを実施する際には、作業直前若しくはメンテナンス実施後の連絡になる場合があります。

  • ②通知内容に応じて対応を検討してください。

  • ③メンテンナンス箇所により影響が分かれます。

    • サーバー機器更新メンテナンスの場合、期間中にサーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。

    • ストレージ機器更新メンテナンスの場合、期間中に仮想サーバー1台あたり約30分のサーバー停止・起動が、原則として1回発生します。なお、RAC環境などの手法により利用者側でサーバーの冗長性を確保されている状態でも、共有ディスク部分について本影響の対象となります。

    • 通常の停止作業から 10分経過後に応答がない場合、仮想化基盤からサーバーを強制停止します。

3.4

HA発生時

  • ①HAからの完全復旧を目的として、発生から2営業日後にメンテナンスを行います。実施時間は13:00～16:00若しくは20:00～23:00のいずれかで、事前に利用者が指定した方で実施します。

  • ②通知内容に応じて対応を検討してください。

  • ③メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。

3.5

パッチ適用

  • ① ハードウェアのセキュリティパッチは定期的にサービス提供側で実施しています。OS以上については、利用者にてアップデートを実施してください。

  • ②OS以上に関するメンテナンス、データバックアップの運用・管理、利用アプリケーション等のアップデートを検討してください。

  • ③パッチの適用後のアプリケーション動作検証を行い、動作しない場合の切り戻し、若しくはアプリケーションの修正などにもあらかじめ留意してください。

3.6

運用環境

開発用環境の設置

  • ①サービスとして開発用環境の提供はしていません。

  • ②開発用環境と位置付けたサーバーを作成する。
    プライベートLANを適切に用意することで、ネットワークの論理分割が可能です。

  • ③各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。

3.7

試験用環境の設置

  • ①サービスとして試験用環境の提供はしていません。

  • ②試験用環境と位置付けたサーバーを作成する。
    プライベートLANを適切に利用することで、ネットワークの分割が可能です。

  • ③各環境ごとに環境依存する設定の修正やOracleライセンスの確保なども考慮してください。

3.8

サポート体制

  • ①仕様・機能や料金、導入相談などのお問い合わせ窓口(平日9:00～17:45)

    • 利用中のトラブルについての問い合わせ(24時間365日※法定点検時等を除く)の2つの窓口を用意。いずれも電話対応可能です。 [11] [12]

  • ②ログやダンプなどの出力は利用者側のアプリケーションなどで行ってください。

  • ③特になし。

11. Oracle Linux のサポートについては富士通クラウドテクノロジーズが一次受けします。
12. Windows Serverのサポートについては、富士通株式会社が提供する「サポート（富士通サポートデスク）」を利用の場合、サポート可能です。詳細は こちらを確認してください。
セキュリティ

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ゲートウェイ、プライベート接続の詳細は各サービスページを参照してください。
    ネットワーク関連サービス： https://pfs.nifcloud.com/service/index.htm#network

4.4

蓄積データ暗号化の有無

  • ①データ暗号化サービスの提供はしていません。

  • ②暗号化が必要な場合はOS上で専用の暗号化ツールなどの導入を検討してください。

  • ③暗号化ツールを導入する際は、OVM仮想環境での動作サポート要否にも留意してください。

4.5

不正追跡・監視

  • ①ニフクラのオプションサービス「Trend Micro Cloud One – Workload Security」を検討する。 [13]

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

  • ③特になし。

13. 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」を検討する。 [14]

  • ②Trend Micro Cloud One – Workload Security利用時は、申請書提出後に発行されたActivation Codeを登録し、インストール及び各種セキュリティ設定を実施。
    Trend Micro Cloud One – Workload Securityの管理サーバーはインターネット側に配置されているため、導入したサーバーからインターネットへ接続する必要がある。OVM環境単体ではインタネット接続ができないため、ニフクラとの連係を検討してください。

  • ③Trend Micro Cloud One – Workload Securityのシステム要件については、以下リンク先の『注意事項』を参照。
    https://pfs.nifcloud.com/service/dsaas.htm

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

No.

要件

OVMの仕様
(① サービス仕様　② 利用者の対処　③ 備考(影響など))

選択値・条件

大項目

中項目

小項目

5.1

データセンター

外部監査

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

  • ②特になし。

  • ③特になし。

  • 次の認証を取得

    • ISO/IEC 27001:2013,JIS Q 27001:2014

    • JIP-ISMS517-1.0(ISO/IEC 27017:2015)

5.2

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

  • ①東日本east-1リージョンのみ

  • ②特になし。

  • ③特になし。
動作環境

No.

要件

OVMの仕様
(① サービス仕様　② 利用者の対処　③ 備考(影響など))

大項目

中項目

小項目

6.1

動作環境

動作仕様

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

6.2

サーバーのタイプ (east-1)

  • ①サーバータイプは ニフクラOVM　OVMサーバータイプ・仕様 から選択可能。 [16]

  • ②業務要件に合わせて選択。なお、定量的な性能値は公表されていません。

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

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

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で提供しているサーバータイプ以下のとおりとなります。構築するシステムに応じて選択して利用してください。

    image

  • 性能指針

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

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

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

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

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

利用するサーバーのvCPU数

エディション名

基準となるプロセッサ数

必要なProcessorライセンス数

必要なNamed User Plusライセンス数

1～4vCPU

【Oracle Database】
Enterprise Edition

利用するサーバーのvCPU数に0.5を乗じた数(小数点以下は切り上げ)

「基準となるプロセッサ数」と同数(最小数は1)

最大利用ユーザー数(最小数は「基準となるプロセッサ数」に25を乗じた数)

【Oracle Database】
Standard Edition
Standard Edition One
Standard Edition2

利用するサーバーのvCPU数に関わらず、1

「基準となるプロセッサ数」と同数

最大利用ユーザー数(最小数は10)

8vCPU以上

【Oracle Database】
Enterprise Edition

利用するサーバーのvCPU数に0.5を乗じた数(小数点以下は切り上げ)

「基準となるプロセッサ数」と同数

最大利用ユーザー数(最小数は「基準となるプロセッサ数」に25を乗じた数)

【Oracle Database】
Standard Edition
Standard Edition One
Standard Edition2

利用するサーバーのvCPU数に関わらず、2

「基準となるプロセッサ数」と同数

最大利用ユーザー数(最小数は10)
例）

  • ovm.large16でEnterpriseEdisonをBYOLする場合：基準となるプロセッサ数 ＝ 4vCPU × 0.5＝2 → 必要なProcessorライセンス数 ＝ 2

  • ovm.large16でStandardEdisonをBYOLする場合：基準となるプロセッサ数 ＝ 利用するサーバーのvCPU数(4vCPU)に関わらず、1 → 必要なProcessorライセンス数 ＝ 1

  • ovm.qlarge128でEnterpriseEdisonをBYOLする場合：基準となるプロセッサ数＝16vCPU × 0.5 ＝ 8 → 必要なProcessorライセンス数 ＝ 8

  • ovm.qlarge128でStandardEdisonをBYOLする場合：基準となるプロセッサ数 ＝利用するサーバーのvCPU数(16vCPU)に関わらず、2 → 必要なProcessorライセンス数 ＝2

  • 以下、ニフクラOVMサービス仕様書 別紙も併せて確認してください。
    https://pfs.nifcloud.com/pdf/ovm_spec_attachment.pdf

サーバー提供の形態

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

image

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

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

  • イメージ図のように、OVMサーバーの利用シーンでは、接続した「プライベートLAN」うえで、ニフクラ環境のサービスと組み合わせて利用する形態が前提となります。

  • Oracle Database及びライセンスは提供していません、利用者側で用意・導入する必要があります。

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

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

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

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

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

ニフクラとの連係方法

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

image


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

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

OVMの利用上の注意点

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

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

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

制約事項

詳細

代替となる対応手段

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

  • コントロールパネルによる、利用者側でのオンデマンドのサーバー新規作成や再起動は不可。 [17]

  • ニフクラ(パブリック)のサーバー経由でOS以上のレイヤーでログイン、サーバー運用をする必要がある。

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

Webフォームによる申請ベースで以下機能を提供。
サーバー新規作成／サーバー停止・起動／サーバー再起動／サーバー削除／サーバースペック・設定変更／ディスク追加/拡張／設定状況確認

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

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

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

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

オラクル社の方針変更により、オラクル製品利用に制約が加わる可能性がある。

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

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

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

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

image


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

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

  • OVMの提供は東日本east-1リージョンのみとなります。東日本east-2リージョンや西日本リージョンでは提供されていません。

  • OVMにはニフクラのようなゾーンという概念はありません。東日本east-1リージョン内であれば、どのニフクラのゾーンからでもOVM環境へ接続できます。

image

システムパターンの検討

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

  1. OVMはSLAの対象外となります

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

災害対策 (地理的冗長)

ゾーン規模
障害対策

サーバーSLA対象

許容可能な停止時間

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

OVMでの適用可否

要

要

対象

無停止～数分

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

不可

不要

対象

無停止～数分

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

不可

不要

要

対象

無停止～数時間

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

不可

不要

対象外

無停止～数日程度

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

可能

対象外

数時間～数日程度

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

可能

対象外

数日程度

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

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

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

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

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

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

構成要素

image

image

image

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

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

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

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

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

再起動(HA)

再起動(HA)

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

サーバー切り離し

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

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

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

数十秒～数分

1時間～＋リストア時間

15営業日程度＋リストア時間

サーバーコスト

2台分

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

1台分

OracleDBライセンスコスト

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

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

1台分

  • OVMの提供は東日本east-1リージョンのみであるため、リージョン・ゾーン障害に対する対策はとれませんので、ご留意をお願いします。

  • HAが発生した場合、サーバーは再起動される形となります。

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

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

  • 本サービスの特性上、新規サーバーの用意に15営業日かかることから、RTOが重要な場合はスタンバイサーバー利用若しくはOracle RAC・SEHA構成を推奨します。

  • 「OVMサーバー障害」に関して、ここではカーネルパニック、OS自体が起動しないなどの状況を想定しています。

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

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

No.

適用システムパターン

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

1

image

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

【作業概要】

  • 所定のWeb申請フォームよりOracle RAC・SEHA構成利用、サーバーセバレート利用を含めたサーバー新規作成の申請をしてください。

  • Web申請フォーム： https://pfs.nifcloud.com/service/ovm.htm

  • 申請後、約15営業日でサーバーが払い出されます。

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

【リージョン障害対策】

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

【ゾーン障害対策】

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

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

  • Oracle RAC・SEHA機能によりフェイルオーバーが行われ、別の物理サーバーへ切り替わります。(利用者設計)

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

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

【ストレージ障害対策】

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

【運用】

  • 障害検知のための監視サーバーはニフクラ側に用意します。

  • ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 [18]

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

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

No.

適用システムパターン

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

2

image

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

【作業概要】

  • 所定のWeb申請フォームよりスタンバイサーバー利用を含めたサーバー新規作成の申請をしてください。

  • Web申請フォーム： https://pfs.nifcloud.com/service/ovm.htm

  • 申請後、約15営業日でサーバーが払い出されます。

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

【リージョン障害対策】

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

【ゾーン障害対策】

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

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

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

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

【ストレージ障害対策】

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

【運用】

  • 障害検知のための監視サーバーはニフクラ側に用意します。

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

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

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

No.

適用システムパターン

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

3

image

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

【作業概要】

  • 所定のWeb申請フォームよりサーバー新規作成の申請をしてください。

  • Web申請フォーム： https://pfs.nifcloud.com/service/ovm.htm

  • 申請後、約15営業日でサーバーが払い出されます。

  • サーバー払い出し後のOracle DBインストール、セキュリティ対策などを含めたシステム構築は利用者自信で設計・構築することになります。

【リージョン障害対策】

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

【ゾーン障害対策】

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

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

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

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

【ストレージ障害対策】

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

【運用】

  • 障害検知のための監視サーバーはニフクラ側に用意します。

  • ニフクラ側にバックアップサーバーを構築して、取得したバックアップデータを保存します。 [20]

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

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

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

    image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策 (地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。

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

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

  • 計画メンテナンスは60日前に通知されます。メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。

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

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のオンラインバックアップには対応していません。 [21] [22] [23]

21. Oracle DBのバックアップは オプション機能：アドバンスドバックアップ により可能となります。詳細については ドキュメント を参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
22. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
23. 富士通クラウドテクノロジーズによるOracle RAC構成下での検証は実施していません。利用者側の判断にて導入を検討してください。

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

  • バックアップ

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

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

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

    【その他ソフトウェア】

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

  • リストア・リカバリ

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

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

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

    • OVMでは起動ディスク(CD/DVD等)をマウントする機能は未提供のためブータブルメディアを用いてのリカバリはできません。 [24]

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

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

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

image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。

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

  • 計画メンテナンスは60日前に通知されます。メンテナンス期間中の対応方針については、あらかじめ検討するようにしてください。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。

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

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）】となります。 [25]

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

    • ニフクラまたは、ニフクラ外へのバックアップができます。

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

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

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

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

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

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

    【システム領域】

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

    • スタンバイサーバー作成タイミングによっては、Oracleライセンスが追加発生します。

    【データベース領域】

    • 保存先はOVM環境以外を推奨します。ニフクラ側などを検討してください。

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

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

    【REDOログ】

    • データベース同様、OVM環境以外に保存するよう検討してください。

  • スタンバイサーバー利用を前提としたリストア

    • スタンバイサーバー作成タイミングにより下記2パターンのリストア方式になります。

      • ①Oracle新規インストールを含むリストア

      • ②データベース、REDOログからのリストア

  • スタンバイサーバーへの切り替えについて

    • スタンバイサーバーへの切り替え後は、本番サーバーはスタンバイサーバーに降格されます。

27. Oracle DBのバックアップは オプション機能：アドバンスドバックアップ により可能となります。詳細については ドキュメント を参照してください。OracleDBの対応バージョン、仕様等確認して検討してください。
28. RMANを利用し取得したオンラインバックアップをAcronisにてバックアップする方法も考えられます。
サーバーシングル構成

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

image

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

－

2

ゾーン障害

ゾーン規模障害対策

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

－

3

物理サーバー

メンテナンス時対策

計画メンテナンス・緊急メンテナンスの2パターンあり、メンテナンス期間中はサーバー1台あたり約30分を目安とした サーバー停止・起動が、原則として1回発生します。

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

  • 計画メンテナンスは60日前に通知されます。メンテナンス期間中の対応方針について、あらかじめ検討しておきます。

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

メンテナンス期間中に、サーバー1台あたり約30分を目安としたサーバー停止・起動が、原則として1回発生します。

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

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）】となります。 [29]

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

  • ニフクラまたは、ニフクラ外へのバックアップができます。

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

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

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

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

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

  • バックアップ

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

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

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

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

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

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

  • リストア・リカバリ

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

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

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

    • OVMでは起動ディスク(CD/DVD等)をマウントする機能は未提供のためブータブルメディアを用いてのリカバリはできません。 [33]

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

Appendix

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

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

image

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

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

image

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

    • 月次

    • 週次

    • 日次

    • メンテナンス時

  • バックアップ取得方法

    • フル

    • 差分

    • スナップショット

    • REDOログ

  • バックアップの保管

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

    • 他のデータセンター

  • バックアップの同期

    • 同期

    • 非同期

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

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

image

  • バックアップの状況によって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を利用

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

  • 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でリカバリ

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

  • Acronisを利用したリカバリ方法として大きく分けて以下2種類あります。

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

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

  • OVM環境ではコンソール機能を提供しておらず、ブータブルメディアをマウントできません。そのためOVM環境でのリカバリはすべてAcronisのWebインターフェイスを利用する必要があります。

  • 「Acronis(オプション機能：アドバンスドバックアップ)利用」についてはOracleDBの対応バージョン、仕様等確認のうえ、利用を検討してください。

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

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

OVMサーバー一部障害

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

OVMサーバー障害

カーネルパニック、OS自体が起動しない等

補足

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

システム構成と補足情報

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

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

    • OVMサーバーとルーター(SNAT)は同一セグメントでの実施

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

  • Acronisと通信する際の通信要件は以下を確認してください。本構成ではニフクラルーターのSNAT構成としていますが、通信要件を満たせば他構成でも利用可能です。
    https://faq.support.nifcloud.com/faq/show/749

  • 事前の入念なバックアップ/リカバリテストを実施することを推奨します。

image

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

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

RPO

RTO

条件

バックアップ方法

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

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

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

Oracleのデータ

OVMサーバー全体

障害発生直前

短期に復旧(数時間)

DBの停止不可

再構築不可

RMANを利用

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

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

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

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

リカバリ方針

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

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

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

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

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

    B：OVMサーバー全体(システム領域)のバックアップをAcronisで取得

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

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

    • 取得タイミング：日次

image

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

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

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データ復旧

image

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

  • カーネルパニック、OS自体が起動しない

リカバリ対応

  • A：スタンバイサーバーに切り替え申請(「スタンバイサーバーにおけるOracleライセンスの取り扱いについての注意」参照)

  • B：Acronisでバックアップしていたサーバー全体のバックアップを元スタンバイサーバーへリストア実施

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

image

スタンバイサーバーにおける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エージェント導入後になります。

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. 本番サーバーへ昇格したサーバー(スタンバイサーバー)にログインできることを確認する。

検証結果

  • Oracle Linux7.6,Widnows Server 2012,Windows Server 2016すべてでバックアップ・リカバリが正常終了を確認。

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

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

富士通クラウドテクノロジーズでの検証結果を元にした情報であり、検証結果どおり動作を保証するものではありません。

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

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

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

image

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

    • Oracle Linux7.6

    • Windows Server 2012

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

  • ③サーバー新規作成
    Webフォームからの申請となり、15営業日で用意される。※事前作成も可能

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

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

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フォルダ)に保存したバックアップデータからの復元が失敗する
      https://faq.support.nifcloud.com/faq/show/2645

image

導入のご相談はお電話でも受け付けております。

0120-22-1200

0120-22-1200

受付時間：9:00～17:45（土日祝・当社指定の休業日を除く）
※携帯電話・PHSからもご利用可能

お問い合わせ

お申し込み

資料ダウンロード

見積もりシミュレーター

お申し込み