本文へジャンプします。

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

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

ニフクラ ユーザーガイド

はじめに

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

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

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

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

留意事項

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

適用判断手順の概要

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

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

    • 提供されるサービスについて把握する

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

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

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

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

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

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

  4. Oracle製品の利用検討

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

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

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

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

  6. Appendix

    • 利用開始までの流れ

    • 契約更新時に関して

    • その他Tips

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

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

image

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

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

プライベートリソース

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

サーバー専有

専有

専有

専有

共有

ストレージ専有

専有

専有

専有/共有

共有

ネットワーク

専有

専有

共有

共有

DC

お客様

ニフクラDC
(east-1、jp-west-2)

ニフクラDC

ニフクラDC

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

プライベートリージョンではリソース規模に応じて4つのモデル「Small v.1 / Medium v.1 / Largev.1 / 段階従量課金モデル」が用意されています。要望のシステム規模に合うリソース規模を選択してください

Small v.1

Medium v.1

Large v.1

段階従量課金モデル

推奨エンドユーザー

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

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

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


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

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

導入タイミング

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

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

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

留意事項

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

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

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

備考/顧客例

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

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

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

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

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

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

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

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

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

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

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

提供内容

Small v.1 / Medium v.1 / Large v.1 / 段階従量課金モデルともに、提供内容(メニュー)は基本プランに加えて、希望の追加オプションを利用可能です。詳細は サービス仕様書 を参照の上、要件を満たすためのオプションがあるか、確認し検討してください。

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

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

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

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

image

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

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

レイヤー

範囲

責任

DC利用型

お客様先設置型

アプリケーション

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

利用者

利用者

ミドルウェア

OSイメージ

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

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

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

富士通

富士通

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

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

仮想化基盤(VMware vSphereなど)

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

  • 各種オペレーション

  • ライセンス手配・購入

  • ライセンス適用

  • ライセンス管理

  • パッチ適用

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

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

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

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

基盤リソース管理

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

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

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

利用者

利用者

ファシリティ

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

富士通

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

利用者

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

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

プライベートリージョン利用、Small v.1 / Medium v.1 / Large v.1 / 段階従量課金モデルのメニュー決定までに検討を必要とする事項があります

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

スケールアップ

  • 仮想サーバータイプを変更することで可能(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

移行

移行方法

  • オンプレミス仮想環境上のゲストOSの移行については、VMインポート、Liveマイグレーションの利用が可能。移行可能なOSは、最新の機能説明書と制限事項・注意事項を参照。

  • サービス利用の判断も含め、移行方法について個別検討が必要。

  • VMインポートの利用を検討する場合、 VMインポート・仕様 にて前提条件などの確認が必要。
    Liveマイグレーションの利用を検討する場合 Liveマイグレーション・仕様 を確認のうえ、検討が必要

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年間)にわたって利用可能です。詳細は こちらを確認してください。

    • 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 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.

検討事項

対策観点

検討内容

検討時の重点ポイント

8

物理サーバー

メンテナンス時対策

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

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

9

ネットワークノード

メンテナンス時対策

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

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

10

ストレージノード

メンテナンス時対策

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

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

11

仮想サーバー

メンテナンス時対策

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

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

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

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

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

12

物理サーバー

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超える場合、リージョン切り替えをする必要があります。

13

ネットワーク機器

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超える場合、リージョン切り替えをする必要があります。

14

ストレージ機器

クラウド基盤障害対策

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

  • 障害時間が許容範囲を超える場合、リージョン切り替えをする必要があります。

15

仮想サーバー

クラウド基盤障害対策

バックアップを提供しています。定期的な自動バックアップや任意のタイミングで仮想サーバーのバックアップを取得する機能です。エージェントレスで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
ラック数の目安

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

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

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

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



アンケート
アンケートにご協力を
  • ※本ページ記載の金額は、すべて税抜表示です。
  • ※本ページ記載の他社製品名および会社名などは、各社の商標または登録商標です。
  • ※本ページの内容は、2024年11月29日時点の情報です。

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