本文へジャンプします。

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

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

ニフクラ ユーザーガイド

はじめに

  • 本ドキュメントではプライベートリージョン活用ガイドについて記載しています。

  • プライベートリージョン(以下、本サービスと記載します)は、利用者に共通で提供されている機能やサービスを組み合わせてシステムを構築します。そのため、個別の要望には対応はできません。

  • システム要件によるプライベートリージョンの適用可否は、サービス仕様書 及び、本ドキュメントを最後まで確認のうえ、判断してください。

  • サービスの最新の情報は、クラウド ドキュメントなどの該当ドキュメントを参照してください。

留意事項

本ドキュメントは 仕様書第1.24.0版 をもとに作成しております。
機能は順次エンハンスされます。検討時には弊社ホームページにて最新情報を確認してください。

適用判断手順の概要

プライベートリージョンの適用可否を判断するために、以下手順を確認してください。

  1. プライベートリージョン概要

    • 提供されるサービスを把握する。

    • 全体構成を把握し、システム全体の構成を検討する。

    • 責任分担を把握したうえで、適用可否を判断する。

  2. プライベートリージョンの適用判断事項

    • 利用者要件に対応するプライベートリージョンのサービス仕様を確認し、必要となる対処、影響などを検討したうえで、適用可否を判断する。

  3. プライベートリージョンで対応できない要件

    • プライベートリージョンで対応ができない利用者要件や条件などを確認し、適用可否を判断する。

  4. Oracle製品の利用検討

    • BYOL/アウトソーシング環境を利用したOracle製品の利用方法について検討する。

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

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

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

  6. Appendix

    • 利用開始までの流れ

    • 契約更新時に関して

    • その他Tips

適用判断手順の概要(設置タイプ)

設置タイプは、大きく分けて下図の4種類あります。
本ドキュメントでは、特に断りがない限りプライベートリージョン(お客様先設置型、DC利用型)の適用判断手順を掲載しています。

2025年11月4日にお客様先設置型および、DC利用型(west-2リージョン)は新規受付を終了します。
以降の新規契約はDC利用型(east-1リージョン)を検討してください。

image

プライベートリージョン(お客様先設置型)

プライベートリージョン(DC利用型)

プライベートリソース

パブリッククラウド(IaaS)

サーバー専有

専有

専有

専有

共有

ストレージ専有

専有

専有

専有/共有

共有

ネットワーク

専有

専有

共有

共有

DC

お客様

弊社DC
(east-1、jp-west-2)

弊社DC

弊社DC

適用判断手順の概要(規模種類)

プライベートリージョンではリソース規模に応じて、下記表にある複数のモデルが用意されています。要望のシステム規模に合うリソース規模を選択してください。

XSmall v.1

Small v.1

Medium v.1

Large v.1

段階従量課金モデル

推奨エンドユーザー

プロジェクト単位での利用

自社利用・プロジェクト単位での利用

自社もしくはグループ会社内利用

自社利用もしくはエンドユーザーへの再販 [1]


1. 再販には別途OEM契約が必要

最終的な利用規模が読めない案件・プロジェクト

導入タイミング

  • 既存環境の保守切れなどによる環境移行タイミング

  • 自社クラウドサービスをOEMに置き換えるタイミング

  • 2025年の崖回避に必要な中間段階の構築や、クラウドへのリフト&シフトを始めるタイミング

留意事項

  • 基本プラン、初期追加パック、vCPU/メモリ追加オプションでは作成可能vCPU上限が定められている。

    • 本上限は作成するサーバータイプにより、vCPU利用数の算出方法が異なる。
      詳細は サービス仕様書 を参照

  • 作成するサーバータイプにより、vCPU利用数の算出方法が異なる。
    詳細は サービス仕様書 を参照

備考/顧客例

  • 専有型のクラウド環境を利用したい。

  • Small v.1では遊休リソースやラック等の余剰投資が発生してしまう。

  • 専有リソースを特定年数のみ利用したい。

  • 大きなリスクなく、低価格、小規模で利用したい。

  • 専有型のクラウド環境を利用したい。

  • Medium v.1 / Large v.1では遊休リソースやラックなどの余剰投資が発生してしまう。

  • 「利用期間固定」により、特定年数のみ利用したい。

  • 保有するVMのすべてを短期間では移行できないので、段階的に1,000VM程度まで環境を増強したい。

  • 提供済みのLarge v.1(1,728vCPU)では、移行が完了するまでの期間に、遊休リソースや、ラックなどの余剰投資が発生してしまう。

ホスティングサービス提供事業者
  • 既存サービスの移行先、もしくは新しくクラウドサービスの提供を検討されている。

  • 運用・管理・機能エンハンス・課金請求処理などのサービス運営費用を削減したい。

大手ITリソース保有企業
  • 既設オンプレミス環境とのハイブリッド構成により、シームレスな連携が可能なオンデマンド基盤を要望する。

  • 想定システム規模内で最終的な利用規模が予測できず、利用状況に合わせたコストで専有環境を利用したい。

  • 想定システム規模内で、段階的な移行で環境を拡大したい。

1.プライベートリージョン概要

提供内容

プライベートリージョンの提供するメニューは、いずれも基本プランに加えて、希望の追加オプションを利用できます。詳細は サービス仕様書 を参照の上、要件を満たすオプションがあるか、確認し検討してください。

プライベートリージョンの全体構成
  • プライベートリージョンは、完全に外部接続を遮断して利用できます。

    • サービスで提供する環境とIaaS管理系システムのリソースは物理的に分離しています。

    • サービスネットワークとメンテナンスネットワークには接続性はありません。

  • 全体構成を把握し、システムとしての構成要件を満たせるか確認してください。

image

お客様先設置型/DC利用型の提供範囲(利用者との責任分担)

お客様先設置型/DC利用型の提供範囲と利用者との責任分担を記載します。利用者責任箇所が運用可能か、富士通責任範囲をベンダに任せてよいか確認してください。

レイヤー

範囲

責任

DC利用型

お客様先設置型

アプリケーション

仮想サーバー上で稼働するアプリケーション及びミドルウェア全般

利用者

利用者

ミドルウェア

OSイメージ

  • 脆弱性対応/パッチ適用

  • 作成した仮想サーバー台数管理(お申し込みモデルの範囲内)

仮想サーバーOSの払い出し

富士通

富士通

クラウド機能(コントロールパネル/API)

新機能の提供、既存機能の拡張

仮想化基盤(VMware vSphereなど)

仮想化基盤の構築・運用管理

  • 各種オペレーション

  • ライセンス手配・購入

  • ライセンス適用

  • ライセンス管理

  • パッチ適用

  • サービス提供に関して必要な情報の共有

  • ご契約いただいたリソースを提供できる環境の維持管理

ハードウェア(サーバー・ストレージ・ネットワーク機器)

ハードウェアの調達(新規/増強)・構築・運用管理、基盤システムキャパシティ管理

基盤リソース管理

  • vCPU上限管理(お申し込みモデルの範囲内)

  • メモリ上限管理(お申し込みモデルの範囲内)

  • オプションディスク上限管理(お申し込みモデルの範囲内)

利用者

利用者

ファシリティ

ハードウェア設置用ラック提供、電源設備、空調管理

富士通

インターネット回線及び上位ネットワーク

利用者

2.プライベートリージョンの適用判断事項

利用と決定までの検討フロー

プライベートリージョンの利用と、利用するメニューの決定までに、必要な検討事項があります。

image

可用性

利用者の要件に対応するプライベートリージョンサービス仕様を確認し、利用者側で必要となる対処、影響などを検討したうえで、プライベートリージョンの適用可否を判断します。

No.

要件

プライベートリージョンの仕様

大項目

中項目

小項目

1.1

可用性

継続性

運用スケジュール

  • 24時間365日無停止です。ただし、計画停止/定期保守/即時対応は除きます。

  • 計画停止/定期保守/即時対応の影響は、No.3.3を参照してください。

1.2

稼働率

それぞれのサービスで設定している稼働率は異なります。
SLAの詳細は 品質保証制度(SLA)について を参照してください。

1.3

耐障害性

ネットワーク

  • プライベートリージョン内の構成は二重化構成です。 [2]

  • 切り替わり時に通信断をともなう可能性があります。


2. 詳細は 可用性向上への取り組みを確認してください。

1.4

ストレージ

  • ストレージ機器は冗長構成となっており、仮想サーバーイメージ(カスタマイズイメージ)は保存先のリージョン/ゾーンを選択できます。 [3]

  • 切り替わり時に通信断、I/O遅延または断をともなう可能性があります。


3. 詳細は 可用性向上への取り組みを確認してください。

1.5

災害対策(DR)

  • 本サービスでは提供していません。

  • 災害規模を想定し、その復旧計画を検討してください。
    マルチリージョンやオンプレミス環境などを活用し、地理的に離れた複数拠点での冗長化システムを用意してください。

  • マルチリージョンで同一環境を構築し、データをリージョン間接続経由で同期する構成を検討など、利用者側にてレプリケーションの仕組みを構築してください。

性能・拡張性

No.

要件

プライベートリージョンの仕様

大項目

中項目

小項目

2.1

性能・拡張性

リソース拡張性

vCPU

パブリック環境で提供中の クラウド技術仕様/制限値(コンピューティング:クラウド サーバー(共有)タイプ)から、選択できます。一部制限があるため 仕様書を参照してください。

2.2

メモリ

パブリック環境で提供中の クラウド技術仕様/制限値(コンピューティング:クラウド サーバー(共有)タイプ)から、選択できます。一部制限があるため 仕様書を参照してください。

2.3

ストレージ

2.4

スケールアップ

  • CPU/メモリは、仮想サーバータイプの変更で、スケールアップできます。No.2.1, No.2.2を参照してください。

  • ストレージ容量は、増設ディスクの容量を拡張、または追加でスケールアップできます。No.2.3を参照してください。

    • 新しいディスクは別領域となり、マウントの再定義やデータの移行作業、もしくはOS上での拡張設定などは利用者側で実施してください。

  • 仮想サーバーは提供されている仮想サーバータイプから選択します。増設ディスクの容量、またはアタッチ数を増やします。

    • 仮想サーバータイプの変更にともない自動で再起動されます。

    • 再起動されると、その仮想サーバーで稼働中の業務アプリケーションは中断または停止されます。
      仮想サーバーが起動状態になってから、アプリケーション稼働状況の確認や起動後に必要な対処を実施してください。

2.5

スケールアウト

  • オートスケールの設定で定義されている仮想サーバーの台数など、条件設定に従ってリソースを追加できます。

  • スケールアウトに必要なオートスケーリング条件を設定してください。

2.6

性能品質保証

  • vCPU、メモリは仮想サーバータイプに基づくスペックが割り当てられますが、仮想サーバー、ストレージ、ネットワークの性能はベストエフォートでの提供です。

運用・保守性

No.

要件

ニフクラの仕様

大項目

中項目

小項目

3.1

運用・保守性

通常運用

バックアップ

【バックアップ】
【カスタマイズイメージ】
【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】

3.2

運用監視

  • ハードウェア監視、ハイパーバイザー稼働監視等のクラウド基盤側の監視は、サービス提供側で実施します。

  • サービスで提供されていない監視項目は、利用者側で監視ツールを仮想サーバーにインストールしてください。

    • 利用者側で監視ツールをインストールする際は、仮想環境での動作をサポートしているか確認してください。

3.3

保守運用

計画停止

3.4

パッチ適用

  • ハードウェアのセキュリティパッチは定期的にサービス提供側で実施します。

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

    • OS層以上のパッチ適用後、利用者側でアプリケーションの動作を検証してください。

3.5

運用環境

開発用環境の設置

  • 本サービスでは、開発用環境は提供していません。

  • 開発用環境と位置付けた環境に仮想サーバーを作成します。オプションでネットワークを論理分割できます。

  • 開発用環境で作成した仮想サーバーのイメージを作成すれば、本番用環境や試験用環境へ配備できます。
    その際は、各環境に、環境依存する設定の修正を利用者にて実施してください。

3.6

試験用環境の設置

  • 本サービスでは、試験用環境は提供していません。

  • 試験用環境と位置付けた環境に開発用環境にて作成したイメージを元に仮想サーバーを作成します。オプションでネットワークを論理分割できます。

  • 試験用環境以外で作成した仮想サーバーイメージを使用する際は、環境依存する設定の修正を利用者にて実施してください。

3.7

サポート体制

  • 以下の窓口を用意しています。

    • 仕様・機能や料金、導入相談などのお問い合わせ窓口

    • 利用中のトラブルの問い合わせ窓口

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

セキュリティ

No.

要件

ニフクラの仕様

大項目

中項目

小項目

4.1

セキュリティ

アクセス・利用制限

認証機能

  • コントロールパネルはユーザーID/パスワード、APIはAccessKey/SecretAccessKeyで認証します。

    • コントロールパネルとAPIへアクセスを許可するアクセス元IPアドレスを指定できます。

4.2

利用制限

4.3

データの秘匿

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

  • オンプレミス環境と当サービス間の接続には、以下を提供します。

    • ハウジング接続サービス

    • インターネット経由:IPsec VPN機能、SSL-VPN機能

4.4

蓄積データ暗号化の有無

  • 以下のデータは物理ストレージ書き込み時に暗号化しません。

    • システム領域

    • 増設ディスク

    • スナップショットデータ

    • 仮想サーバーイメージ

    • オブジェクトストレージサービス

  • 暗号化が必要な際は、利用者側がOS上で対処してください。

4.5

不正追跡・監視

  • ソリューションサービスとして「Trend Micro Cloud One - Workload Security」を提供します。

  • 業務システムのログ管理は、決定、実装、取得のすべてが利用者の責任範囲です。
    「Trend Micro Cloud One - Workload Security」で要件が満たせなければ、別途ミドルウェアを導入し利用する、ハウジング環境に設置し利用する構成などを検討してください。

4.6

不正アクセス検知・監視

  • ソリューションサービスとして「Trend Micro Cloud One - Workload Security」を提供します。

4.7

ネットワーク対策

ネットワーク制御

4.8

ネットワーク対策

セグメント分割

4.9

マルウェア対策

4.10

ディスク破壊サービス

  • 故障、もしくは利用終了するディスクの破壊作業を実施します。破壊作業の実施後、破壊されたディスクの写真を撮影し、その写真を貼付した報告書を作成します。
    詳細は、プライベートリージョン v.1 サービス仕様書 別紙も併せて参照してください。

データセンター

No.

要件

ニフクラの仕様

選択値・条件

大項目

中項目

小項目

5.1

データセンター

外部監査

  • DC利用型

    • 外部機関より公的認証を取得しています。

  • お客様先設置型

    • 利用者準備のデータセンターに依存します。

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

5.2

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

  • DC利用型

    • east-1もしくはjp-west-2と同じデータセンターです。

  • お客様先設置型

    • 利用者準備のデータセンター [4]


4. データセンター要件があります。詳細は サービス仕様書 を参照してください。
動作環境

No.

要件

ニフクラの仕様

大項目

中項目

小項目

6.1

動作環境

動作仕様

対応OS (スタンダードイメージ)

  • スタンダードイメージとして用意されているOSは、サーバータイプ・仕様「選択可能なOS」項目 から確認できます。

  • 提供されるOSイメージより選択できるが、OSイメージによっては制限があります。

    • OSイメージによっては、一部のサーバータイプを利用できません。

    • Windowsライセンス持ち込み時、当サービス提供のWindows Serverが選択可能なOSから除外される。

6.2

対応OS (VMインポート)


5. 未検証のOSでも利用者責任でインポートを試行できます。動作可否は弊社では確認しません。

6.3

仮想サーバーのタイプ

6.4

VMware Toolsのバージョン

6.5

ストレージ容量

  • ストレージ容量はNo.2.3参照してください。

6.6

ネットワーク接続形態

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

No.

要件

ニフクラの仕様

大項目

中項目

小項目

7.1

サービス利用

稼働状況報告

  • 毎日1回、メールでvCPUの使用量などのリソース状況を報告します。

  • リソース状況報告を元に、申し込みモデルの範囲内でのvCPU上限管理/メモリ上限管理/オプションディスク上限管理を実施してください。

8.1

システム特性

負荷分散への対応

  • 外部/内部通信ともに、ロードバランサーサービスを利用して負荷分散できます。セッションの維持機能/ヘルスチェック機能/Sorryページ表示機能を利用できます。

  • 業務要件に基づいて利用サービスを選択し、外部/内部通信の負荷分散を設定してください。

  • ロードバランサー(L4)は、ゾーンを跨いだ負荷分散ができます。
    マルチロードバランサーは、内部通信の負荷分散ができます。
    高機能ロードバランサーが必要であれば、L7ロードバランサー(Ivanti Virtual Traffic Manager)または統合ネットワークサービス(IPCOM VE2Vシリーズ)の利用を検討してください。

8.2

システム連携

  • IPsec VPN通信を用いてインターネット経由により、オンプレミス環境やリージョン間の連携ができます。
    ハウジング接続サービスを利用すれば、ハウジング環境との連携ができます。

  • 連携の仕組みを実装してください。

9.1

移行

移行方法

3.プライベートリージョンで対応できない要件

操作権限/サービス提供方法

プライベートリージョンを適用できない主な条件を示します。以下の不適合条件に合致する要求があれば、以下を検討してください。

  • ハウジング環境への設置

  • 専有コンポーネントの利用

  • 他のクラウドやオンプレミスの利用

不適合条件

理由

操作権限

仮想化基盤の操作権限が必要

  • 利用ソフトウェアで必要など

プライベートリージョンでは、仮想化基盤の運用管理はサービスで実施します。利用者に操作権限を譲渡できません。

サービス提供方法

インターネットへのアクセスはすべて許容できない
他者との共有は許容できない

プライベートリージョンのコントロールパネル/APIの管理システムは、パブリック環境と共有されます。またコントロールパネル、APIのエンドポイントへのアクセスはインターネット経由となります。

動作環境/サポート

プライベートリージョンを適用できない主な条件を示します。以下の不適合条件に合致する要求があれば、以下を検討してください。

  • ハウジング環境への設置

  • 専有コンポーネントの利用

  • 他のクラウドやオンプレミスの利用

不適合条件

理由

動作環境

物理機器の利用が必要

物理機器はプライベートリージョンで利用できません。

  • プリンタ

  • FAX

  • スキャナ

  • テープデバイス

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

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

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

プライベートリージョンで提供する各サービスの性能は、特に言及がない限りベストエフォートでの提供となります。

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

インフラ基盤に特別な設定が必要なシステムは、プライベートリージョンでは稼働できない可能性があります。

サポート

OSなどのインフラ基盤より上位層は、それぞれサポート契約が必要

  • プライベートリージョンでのOS層以上のサポートは、下記のとおりです。

    • OS内部の動作における健全性は利用者責任となり、いかなる理由があってもOS内部へは干渉しません。

    • Red Hat Enterprise Linux(サブスクリプション付き)の利用時に限り、例外的にOSに関するサポートを一次受けします。
      また、富士通株式会社が提供するサブスクリプション付きのRed Hat Enterprise Linuxサポートサービスとして、ソリューションサービス「Red Hat Enterprise Linux AUS[6]」を提供しています。
      特定のマイナーリリースを長期(最大6年間)にわたって利用できます。
      詳細は クラウド技術仕様/制限値(Red Hat Enterprise Linux AUS全般)を確認してください。

    • Windows Serverのサポートは、エフサステクノロジーズ株式会社が提供する「Windows Server向けサポートデスク」を利用の際は、サポートできます。
      詳細は クラウド技術仕様/制限値(Windows Server 向けサポートデスク全般)を確認してください。

    • 24時間365日受け付け可能な窓口を用意していますが、回答時間や事象の解決の保証はしていません。


6. 問い合わせ窓口は、富士通のサポートデスクとなります。

4.Oracle製品の利用検討

下記の利用パターンから利用方法を検討してください。

利用パターン

利用方法

ハウジング環境(パターン1)
ハウジング接続を利用

ハウジング環境に設置したサーバーへOracle製品を導入して利用します。
サーバーの調達、設置、構築、プライベートリージョン環境との接続作業などは全て、利用者側での実施となります。

ハウジング環境(パターン1)

image

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

【参考】パブリック環境のリージョンとゾーンについて
  • パブリック環境は複数のリージョンを利用できます。リージョンの定義は国や地域など、地理的に離れた場所を指します。

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

image


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

プライベートリージョンのリージョンについて
  • プライベートリージョンのDC利用型では、東日本、西日本の特定リージョンで利用できます。利用できるリージョンの詳細は、仕様書を確認してください。
    お客様先設置型では、ファシリティ要件を満たせば設置できます。

  • 1つのプライベートリージョンで複数ゾーンの提供はありません。複数のプライベートリージョンを契約し、複数リージョンの利用はできます。

image

システムパターンの検討

プライベートリージョンで想定できるシステムパターンは下記のとおりです。
※本パターン以外も実装できる可能性があります。要件に応じて検討してください。

システムパターン

構成コンポーネント

構成例

利用シーン

シングルリージョン

プライベートリージョン

  • east-1 DC利用型プライベートリージョン

  • プライベートリージョンを利用する

マルチリージョン

【ピックアップパターン】 [7]

  • プライベートリージョン

  • パブリッククラウド


7. 以降マルチリージョンに関してはピックアップパターンを元に記載します。
  • east-1 DC利用型プライベートリージョン

  • jp-west-2 パブリッククラウド

  • システム要件としてDR構成を実装する必要がある

  • プライベートリージョン

  • プライベートリージョン

  • east-1 DC利用型プライベートリージョン

  • jp-west-2 DC利用型プライベートリージョン

  • プライベートリージョン

  • オンプレミス環境

  • east-1 DC利用型プライベートリージョン

  • 西日本オンプレミス環境

ハイブリッド

  • プライベートリージョン

  • ハウジング環境

  • east-1 DC利用型プライベートリージョン

  • east-1 ハウジング環境

  • ハウジング環境に搭載すべき機器がある

    • VMインポートで当サービスに搭載できないサーバー、機器

    • Oracleをインストールしたサーバー

    • セキュリティ上、自社資産として持ち、クローズドにする必要がある機器

No.1 シングルリージョン

シングルリージョン構成とし、ロケーションサービスによる冗長性を持たない運用としたシステム構成例の概念図です。
※図に記載された吹き出し番号は、下に出てくる表の番号に対応しています。

image

システムパターン

構成コンポーネント

構成例

利用シーン

シングルリージョン

プライベートリージョン

east-1 DC利用型プライベートリージョン

  • プライベートリージョンを利用する

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

No.

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

1

シングルリージョン構成とした、ロケーションサービスによる冗長性を持たないシステム構成例となります。 [8]

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

【作業概要】
  • 仮想サーバーを構築します。仮想サーバーにはHA機能が標準装備されています。

  • ロードバランサー(L4)を用いて、負荷分散構成で構築します。
    フロントエンドシステムは構築したロードバランサー(L4)配下に登録します。 [9]

  • データベース仮想サーバーをDB冗長化構成で構築します。

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

【物理サーバー故障対策】
  • クラウド基盤障害にて物理サーバーに障害が発生した際、HA機能で別物理サーバーへ自動で切り替わります。

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

【運用】
  • 障害検知のために監視サーバーを構築しても、監視サーバーを含む障害が発生した際は、監視不可となります。

  • バックアップデータはプライベートリージョン内に保存します。


8. 1つのシステムにフォーカスした構成例です。プライベートリージョン環境のため利用上限の範囲内で複数システムの搭載も可能です。
9. マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)、統合ネットワークサービス(IPCOM VE2Vシリーズ)でも構築可能です。
検討事項(リージョン障害時/メンテナンス時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

2

物理サーバー

メンテナンス時対策

物理サーバー上の仮想サーバーをマイグレーションにより、別物理サーバーへ移動します。
仮想サーバーの再起動は発生しません。

  • 通常のマイグレーション時は、ネットワーク通信断は発生しません。

3

ネットワークノード

メンテナンス時対策

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

  • メンテナンスの影響を最小限に抑えるため、マルチリージョン構成を検討してください。マルチリージョン構成によって、計画メンテナンス時でも片側の仮想リソースでシステムを継続できる可能性が高まります。

4

ストレージノード

メンテナンス時対策

ネットワークノードやコントローラ切り替えにともなう、瞬間的なI/O遅延または断が発生する可能性があります。

  • ネットワークノードと同様の考え方となります。

5

仮想サーバー

メンテナンス時対策

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

  • ネットワークノードと同様の考え方となります。

  • 業務アプリケーションの可用性は別途設計してください。

検討事項(クラウド基盤障害時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

6

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけるには、マルチリージョン構成を検討してください。

7

ネットワーク機器

クラウド基盤障害対策

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

  • 障害発生時の運用に関して検討してください。

8

ストレージ機器

クラウド基盤障害対策

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

  • 障害発生時の運用に関して検討してください。

9

仮想サーバー

クラウド基盤障害対策

仮想サーバーのOS層以上は、サービス側での対策はありません。

  • 障害検知は監視サービスや監視用のソフトウェアを導入してください。
    また、復旧方式は利用者にて別途設計してください。

10

監視

クラウド基盤障害対策

本環境内に構築した監視サーバーを利用すると、ネットワーク障害時に監視不可となる可能性があります。

  • 基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上を監視するには、別途監視サーバーを構築してください。

  • 障害発生時の通知方法を含む運用は、利用者にて別途設計してください。

  • システム要件によっては、オンプレミス環境など、本環境以外の環境へ監視サーバーを構築してください。

11

バックアップ

クラウド基盤障害対策

シングルリージョン構成では、データを別環境へ保存していないため、リージョン単位に障害が発生した際は、バックアップデータからの復旧が前提となります。
ただし、バックアップデータも同一リージョン内に保存しているため、リージョン障害にてバックアップデータが破損する可能性もあります。

【バックアップ】
  • 定期的な自動バックアップや任意のタイミングでバックアップを取得できます。

【ワンデイスナップショット】
  • ブロックストレージに格納されるため、本番システムとバックアップデータが同一物理環境へ保存されます。

【カスタマイズイメージ】
  • 同一プライベートリージョン内に保存できます。

【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】
  • 同一プライベートリージョン内、またはAcronisクラウドへ保存できます。Acronisクラウドへの保存には、バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

【バックアップ】
【ワンデイスナップショット】
【カスタマイズイメージ】
【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】
【その他】
  • システム要件によっては、本環境以外のオンプレミス環境などへバックアップデータを保存してください。

No.2 マルチリージョン

本構成は各リージョンでActive/Activeとする構成を前提としたシステム構成例の概念図です。本例ではeast-1 DC利用型プライベートリージョン、jp-west-2パブリッククラウドを利用した構成を記載しています。
※図に記載された吹き出し番号は、下に出てくる表の番号に対応しています。

image

システムパターン

構成コンポーネント

構成例

利用シーン

マルチリージョン

プライベートリージョン
パブリッククラウド

east-1 DC利用型プライベートリージョン
jp-west-2 パブリッククラウド

  • システム要件としてDR構成を実装する必要がある

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

No.

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

2

各リージョンでActive/Standbyとしたシステム構成例になります。 [10]

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

【作業概要】
  • 仮想サーバーを各リージョンに構築します。仮想サーバーにはHA機能が標準装備されています。

  • 各リージョンに対し、ロードバランサー(L4)を用いて負荷分散構成で構築します。フロントエンドシステムは構築したロードバランサー配下に登録します。 [11]

  • プライマリリージョン側のロードバランサー(L4)のIPアドレスを、DNSサービスの「レコード設定」機能にてAレコードへ登録し、フェイルオーバーのプライマリとして登録します。

  • セカンダリリージョン側のロードバランサー(L4)のIPアドレスを、DNSサービスの「レコード設定」機能にてAレコードへ登録し、フェイルオーバーのセカンダリとして登録します。

  • 各リージョンに対し、データベース仮想サーバーをシングルゾーン構成で構築します。 [12]

  • DNSはプライベートリージョンとして専有のサービス提供はないため、パブリッククラウドのDNSの利用を想定しています。

  • 各リージョン間のデータ同期などのサービス提供はないため、利用者で別途実装してください。

【リージョン障害対策】
  • フェイルオーバーが機能すれば、DNS上でのリージョン切り替えは自動で実行されます。 [13]

  • 自動で切り替わらない際や、運用上問題がある際には、手動でDNS設定を変更しリージョンを切り替えます。

  • 切り替え後、セカンダリリージョンへ転送完了している業務データを元に復旧します。

【物理サーバー故障対策】
  • クラウド基盤障害にて物理サーバーに障害が発生した際、HA機能で別物理サーバーへ自動で切り替わります。

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

【運用】
  • 障害検知のための監視サーバーは各リージョンにそれぞれ用意します。

  • プライマリリージョンにバックアップサーバーを構築して、取得したバックアップデータをセカンダリリージョンに保存します。 [14]


10. 1つのシステムにフォーカスした構成例です。プライベートリージョン環境のため利用上限の範囲内で複数システムの搭載も可能です。
11. マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)でも構築可能です。
12. 業務データはリージョン間接続経由でセカンダリリージョン側へ転送します。
13. プライマリ側のロードバランサー(L4)へのヘルスチェックがエラーとなり、一定の切り替え条件を満たせば、自動的にセカンダリ側のロードバランサー(L4)のIPアドレスをDNSが返却するようになります。
14. セカンダリリージョンへバックアップデータ保存用仮想サーバーを構築します。
検討事項(リージョン障害時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン間接続

災害対策(地理的冗長)

リージョン間通信をする際、ハウジング接続経由で専用線/閉域網での接続やインターネット回線を利用できます。
インターネット回線利用時には、オプションの拠点間VPNゲートウェイを使用したインターネットVPN通信もできます。

  • 拠点間VPNゲートウェイでL2TPv3/IPsecを利用する際は、各リージョンでIP重複が起こらないようネットワーク構成を設計してください。また、ループが発生しないようネットワーク設計してください。

2

仮想サーバー

災害対策(地理的冗長)

リージョン間で冗長化した構成が可能となるため、リージョン間でサーバーを構築します。

  • 各リージョンでサーバーを構築するため、それぞれのリージョンでメンテナンス作業など、運用・保守作業を実施してください。

  • リージョンごとのサーバー配置や、切り替え時の縮退運用など、利用者にて別途設計してください。

3

業務データ

災害対策(地理的冗長)

復旧時間を短縮するために、利用者にてリージョン間でデータ同期の仕組みを構築します。

  • 転送方法、転送タイミングなどのデータ転送方式やリージョン障害時の切り替え、リージョン復旧時のリカバリは、利用者にて別途設計してください。

4

DNSサービス+ロードバランサー(L4)

災害対策(地理的冗長)

DNSサービスの「ゾーン管理」「レコード設定」機能を利用して、ロードバランサー(L4)のIPアドレスを登録します。
複数リージョンにて、Active/Active構成でシステムを構築します。DNSサービスの「フェイルオーバー」機能を利用して、リージョン障害発生時でも別リージョンで業務を継続できます。

  • 「フェイルオーバー」機能を利用するとリージョン間の切り替えが自動で実行されます。自動切り替えに対応するための手法や構成は、利用者にて設計してください。

  • リージョン切り替え後にシステム立ち上げが必要な際は、業務アプリケーションの復旧方法を含む方式を、利用者にて別途設計してください。

5

リージョン監視

災害対策(地理的冗長)

リージョン障害を検知する際、監視対象リージョン以外の別リージョン、オンプレミス環境などから監視します。 [15]


15. 障害対象リージョンに監視サーバーが配備されていると、監視不可となるため。
  • 基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上を監視するには、別途監視サーバーを構築してください。

  • 障害発生時の通知方法を含む運用は、利用者にて別途設計してください。

6

バックアップ

災害対策(地理的冗長)

リージョンを跨いだバックアップの仕組みを構築します。
ソリューションサービスである「バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)」を利用するか、サードパーティー製のバックアップソフトウェアを利用する方法があります。
バックアップソフトウェアを利用し、リージョン間接続間経由で、セカンダリリージョン側の仮想サーバーへアタッチしたブロックストレージへデータ転送します。「バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)」を利用の際は、Acronisクラウドへバックアップを取得できます。

  • バックアップ要件を考慮して検討してください。

  • プライマリリージョン以外にバックアップデータを保存する際、セカンダリリージョンなどにデータ保存用仮想サーバーを用意してください。

  • バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用するには、バックアップ対象となる仮想サーバーから、いずれかの経路でグローバルに接続してください。

検討事項(メンテナンス時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

7

物理サーバー

メンテナンス時対策

物理サーバー上の仮想サーバーをマイグレーションにより、別物理サーバーへ移動します。
仮想サーバーの再起動は発生しません。

  • 通常のマイグレーション時は、ネットワーク通信断は発生しません。

8

ネットワークノード

メンテナンス時対策

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

  • 必要に応じて、片方のリージョンで縮退運用などを実施してください。

9

ストレージノード

メンテナンス時対策

ネットワークノードやコントローラ切り替えにともなう、瞬間的なI/O遅延または断が発生する可能性があります。

  • ネットワークノードと同様の考え方となります。

10

仮想サーバー

メンテナンス時対策

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

  • ネットワークノードと同様の考え方となります。

  • 業務アプリケーションの可用性は別途設計してください。

検討事項(クラウド基盤障害時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

11

物理サーバー

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超過する際は、リージョン切り替えを実施してください。

12

ネットワーク機器

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超過する際は、リージョン切り替えを実施してください。

13

ストレージ機器

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超過する際は、リージョン切り替えを実施してください。

14

仮想サーバー

クラウド基盤障害対策

バックアップを提供しています。定期的な自動バックアップや任意のタイミングで仮想サーバーのバックアップを取得する機能です。
エージェントレスでOS領域だけではなく、増設したディスクのデータも丸ごとバックアップします。
トラブル発生時には、取得したバックアップデータから、別サーバーとして新規作成し、バックアップ時の状態で復元させることができます。
仕様は、 クラウド技術仕様/制限値(コンピューティング:バックアップ)を参照してください。

  • 障害検知は監視サービスや監視用のソフトウェアを導入してください。
    また、復旧方式は利用者で別途設計してください。

No.3 ハイブリッド

本構成はプライベートリージョンとオンプレミス環境でハイブリッド構成としたシステム構成例の概念図です。本例ではeast-1 DC利用型プライベートリージョンとハウジング接続を経由してハウジング環境と接続した構成を記載しています。
※図に記載された吹き出し番号は、下に出てくる表の番号に対応しています。

image

システムパターン

構成コンポーネント

構成例

利用シーン

ハイブリッド

プライベートリージョン
ハウジング環境

east-1 DC利用型プライベートリージョン
east-1 ハウジング環境

  • ハウジング環境に搭載すべき機器がある

    • VMインポートで当サービスに搭載できないサーバー、機器

    • Oracleをインストールしたサーバー

    • セキュリティ上自社資産として持ち、クローズドにする必要がある機器

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

No.

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

3

ハイブリッド構成としたシステム構成例になります。 [16]
本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

【作業概要】
  • 仮想サーバーを構築します。仮想サーバーにはHA機能が標準装備されています。

  • ロードバランサー(L4)を用いて、負荷分散構成で構築します。フロントエンドシステムは構築したロードバランサー(L4)配下に登録します。 [17]

  • ハウジング接続サービスを利用してハウジング接続環境と接続します。

  • DBサーバーはOracle製品があるためハウジング環境に設置し、DBサーバーとはハウジング接続経由で接続します。

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

【物理サーバー故障対策】
  • クラウド基盤障害にて物理サーバーに障害が発生した際、HA機能で別物理サーバーへ自動で切り替わります。

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

【運用】
  • 障害検知のために監視サーバーを構築しても、監視サーバーを含む障害が発生した際は、監視不可となります。

  • バックアップデータはプライベートリージョン内に保存します。


16. 1つのシステムにフォーカスした構成例です。プライベートリージョン環境のため利用上限の範囲内で複数システムの搭載も可能です。
17. マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)、統合ネットワークサービス(IPCOM VE2Vシリーズ)でも構築できます。
検討事項(リージョン障害時/メンテナンス時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策(地理的冗長)

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

2

物理サーバー

メンテナンス時対策

物理サーバー上の仮想サーバーをマイグレーションにより、別物理サーバーへ移動します。
仮想サーバーの再起動は発生しません。

  • 通常のマイグレーション時は、ネットワーク通信断は発生しません。

3

ネットワークノード

メンテナンス時対策

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

  • メンテナンスの影響を最小限に抑えるため、マルチリージョン構成を検討してください。マルチリージョン構成によって、計画メンテナンス時でも片側の仮想リソースでシステムを継続できる可能性が高まります。

4

ストレージノード

メンテナンス時対策

ネットワークノードやコントローラ切り替えにともなう、瞬間的なI/O遅延または断が発生する可能性があります。

  • ネットワークノードと同様の考え方となります。

5

仮想サーバー

メンテナンス時対策

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

  • ネットワークノードと同様の考え方となります。

  • 業務アプリケーションの可用性は別途設計してください。

検討事項(クラウド基盤障害時)

本パターンを構築するための主要検討事項を以下に記載します。

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

6

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけるには、マルチリージョン構成を検討してください。

7

ネットワーク機器

クラウド基盤障害対策

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

  • 障害発生時の運用に関して検討してください。

8

ストレージ機器

クラウド基盤障害対策

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

  • 障害発生時の運用に関して検討しておいてください。

9

仮想サーバー

クラウド基盤障害対策

仮想サーバーのOS層以上は、サービス側での対策はありません。

  • 障害検知は監視サービスや監視用のソフトウェアを導入してください。
    また、復旧方式は利用者で別途設計してください。

10

監視

クラウド基盤障害対策

本環境内に構築した監視サーバーを利用すると、ネットワーク障害時に監視不可となる可能性があります。監視要件によってはハウジング環境へ監視サーバーを設置してください。

  • 基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上を監視するには、別途監視サーバーを構築してください。基本監視ではハウジング環境の監視はできません。

  • 障害発生時の通知方法を含む運用は、利用者で別途設計してください。

11

バックアップ

クラウド基盤障害対策

シングルリージョン構成では、データを別環境へ保存していないため、リージョン単位に障害が発生した際は、バックアップデータからの復旧が前提となります。
ただし、バックアップデータは同一リージョン内に保存しているため、リージョン障害にてバックアップデータが破損する可能性もあります。

【バックアップ】
  • 定期的な自動バックアップや任意のタイミングでバックアップを取得できます。

【ワンデイスナップショット】
  • ブロックストレージに格納されるため、本番システムとバックアップデータが同一物理環境へ保存されます。ハウジング環境のバックアップはできません。

【カスタマイズイメージ】
  • 同一プライベートリージョン内に保存できます。ハウジング環境のバックアップはできません。

【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】
  • 本環境外にバックアップできます。ハウジング環境のバックアップも可能なため、システム全体をバックアップできます。バックアップの保存先サーバーをプライベートリージョン、ハウジング環境どちらにも持たせた相互バックアップもできます。

【バックアップ】
【ワンデイスナップショット】
【カスタマイズイメージ】
【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】

Appendix

契約更新時に関して
契約更新時のマイグレーション対応
  • 基本プラン契約期間、ならびに各種追加オプション契約期間は、所定の方法で契約を更新し、サービスの利用期間を延長できます。

  • 更新時には、契約期間が最初のプランと異なる、更新対象により更新の申し込み期限が異なるなど、留意事項があります。またマイグレーションにも各種留意事項があります。詳細は、 サービス仕様書の「9.3 利用期間 契約の更新・変更」を参照してください。

その他Tips
ラック数の目安

お客様先設置型の利用では、選択する各プラン/オプションに応じたラック数の目安を仕様書に記載しています。詳細は サービス仕様書 を確認してください。

  • 新規、追加に関わらず、申し込み内容の組み合わせによる利用者ごとのケース別に、正確なラック数の案内はできません。すべての基本パック及び追加オプションを適当な空きラックがない状態とみなしたうえで、考えられるラック数の目安を案内します。

  • そのため、受注後に物理的な詳細設計をする段階でラック数を減らせる可能性があります。ラック数は、受注後の詳細決定後に最終決定となります。

  • 用意するラックの要件は、仕様書の「ラック要件(お客様先設置型のみ)」を確認してください。



フィードバック

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

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

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