本文へジャンプします。

TOP

ニフクラSEハンドブック

IaaS適用指針

目次

ドキュメント情報

区分

適用指針

リリース日

2022年7月1日

留意事項

2022 年 3 月時点の機能をもとに作成しております。
機能は順次エンハンスされますので、検討時にはニフクラホームページにて最新情報を確認ください。

■ニフクラホームページ

https://pfs.nifcloud.com/

はじめに

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

  • ニフクラはサーバーやネットワークなど、提供されている機能をインターネット経由で利用するクラウドサービスです。利用者に共通して提供されている機能やサービスを組み合わせることでシステムを構築します。よって、個別の要望には対応はできません。

  • システム要件によってはニフクラ適用(移行)不可となる場合があるため、本ドキュメントを最後まで確認の上、適用可否を判断してください。

  • 本ドキュメントの記載内容は特に記載のない箇所については「共有型の仮想サーバー環境」についての記載になります。

  • 本ドキュメントでは、「プライベートアクセス」「ダイレクトポート」の総称として「プライベート接続サービス」という表記をしていますが、この「プライベート接続サービス」という表現は、ニフクラ上での正式な呼称ではありませんので、ご注意ください。

  • 本ドキュメントの注意事項

    • 本ドキュメントは、2022年3月時点の機能をもとに作成しています。ニフクラは継続的にエンハンスが行われるクラウドサービスです。

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

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

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

  • 構成図内の名称は略称で記載されている場合があります。(下記()内が略称の例)

image image

適用判断手順の概要

適用判断手順の概要(導入説明)
  • ニフクラのサーバー提供タイプは、大きく分けて3種類あります(下図を参照)。本ドキュメントでは、特に断りがない限りニフクラパブリックのIaaS環境についての適用判断手順を掲載しています。ニフクラのプライベートリソース、プライベートリージョンを検討する場合は以下を参照してください。

image

プライベートリージョン

プライベートリソース

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

サーバー専有

ストレージ専有

設置場所の選択

適用判断手順の概要(ニフクラ適用可否判断)

ニフクラの適用可否を判断するために以下を確認してください。

  • 1.ニフクラを適用できないケース
    ニフクラを適用できない主な条件を記載

  • 2.ニフクラの適用判断
    利用者要件に対するサービス仕様を記載

  • 3. システムパターンの検討
    システムの必要とする可用性・業務継続性からパターンを判断

  • 4.プライベート接続サービスの検討
    提供機能のみではシステム構築が不可能な場合にプライベート接続サービスを利用した他システム連携を判断

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

  • 6.FUJITSU Software Enterprise Postgres利用パターン
    FUJITSU Software Enterprise Postgresの利用方法や注意事項について記載

  • 7.SAP製品利用パターン
    SAP製品が利用可能なゾーンや注意事項について記載

  • 8.GitLab製品利用パターン
    GitLab製品の利用方法や注意事項について記載

1.ニフクラを適用できないケース

ニフクラを適用できない主な条件を示します。以下の不適合条件に合致する要求がある場合、他のクラウドやオンプレミスの検討が必要です。
この条件はサービス単体利用での不適合条件であり、プライベート接続サービス利用時には必ずしも当てはまりません。また本条件に記載しているものでも、 専有コンポーネントを利用することにより、機器を専有して利用できるため要件によっては適用できる場合があります。

SLA/移行性

不適合条件

理由

SLA

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

ニフクラでは、仮想サーバー、ネットワークサービス等にSLAを設定しています。
それぞれのサービスで設定している稼働率は異なります。ニフクラで設定しているSLAでは、最大でも、月間稼働率が99.99%となります。これを超えるSLAは設定していません。 [1] [2]


1. ニフクラで提供しているSLAの詳細については「 https://pfs.nifcloud.com/sla/ 」を参照してください。
2. 業務システムを含めたSLAについては、利用者側で検討が必要です。

移行性

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

仮想サーバーのグローバルIPアドレスはサービスで割り振ります。払い出されるグローバルIPアドレスを利用者が指定することはできません。

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

VMwareでサポートされているOS以外をニフクラに移行することはできません。(VMwareでサポートされていてもニフクラに移行できるとは限りません)
ニフクラのVMインポート要件を満たさないものも移行できません。また、移行前の仮想サーバーの各種設定が動作のための必須条件となっている場合、移行できません。

OVF+VMDK形式以外のイメージ移行が必要

VMインポートではOVF+VMDK形式以外のイメージを移行することはできません。

動作環境/サポート

不適合条件

理由

選択値・条件

動作環境

物理機器の利用が必要

プリンタ・FAX・スキャナ・テープデバイスなどの物理機器をニフクラで利用することはできません。

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

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

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

VMインポートが可能なOS以外も利用できる可能性はありますが、保証されません。[3]


3. 時期によりインポート可能OSのバージョンが異なる可能性があります。

VMインポート可能OS:Windows Server/Cent OS/Rocky Linux/AlmaLinux/Red Hat Enterprise Linux/Ubuntu

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

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

仮想化に対応しない製品を利用

上限を超えたディスク領域やNICが必要なサーバーを用意することはできません。[4]


4. NICに関してはVMインポート後に追加NICを利用することにより対応できる可能性があります。

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

ニフクラの性能はベストエフォートでの提供のみです。[5]


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

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

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

サポート

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

ニフクラではOS層以上についてのサポートサービスを提供していません。これらのサポートサービスが必須の場合、利用者は別会社からサービス提供を受ける必要がありますが、ニフクラ上でのサポートサービスを提供する別会社が存在しない場合、移行ができません。[6]
Windows Serverのサポートについては、富士通株式会社が提供する「サポート(富士通サポートデスク)」を利用の場合、サポート可能です。詳細は こちらを確認してください。
Red Hat Enterprise Linux(サブスクリプション付き)の場合は、例外的にOSに関するサポートを一次受けします。[7]


6. ニフクラでは問い合わせ窓口をご用意していますが、回答時間や事象の解決についての保証はしておりません。
7. VMインポートにて持ち込んだサーバーはニフクラのサブスクリプション利用不可

24時間365日受付可能

2.ニフクラの適用判断

可用性

利用者の要件に対応するニフクラサービス仕様(①)を確認し、利用者側で必要となる対処(②)、影響等(③)を検討した上で、ニフクラ適用可否を判断します。

No.

要件

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

大項目

中項目

小項目

1.1

可用性

継続性

運用スケジュール

  • ①24時間365日無停止。(計画停止/定期保守/即時対応を除く)

  • ②特になし。

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

1.2

稼働率

  • ①月間稼働率:仮想サーバー、ネットワークサービス等にSLAを設定しています。それぞれのサービスで設定している稼働率は異なりますので、詳細については「 https://pfs.nifcloud.com/sla/ 」を参照ください。

  • ②特になし。

  • ③稼働率が下回った場合、利用者が請求し、内容が認められることで、当該ユーザーの有償オプションサービス料金を除く当月分の利用料金の10%に相当する金額を、翌々月以降ニフクラご利用料金から減額します。

1.3

耐障害性

ネットワーク

  • ①ニフクラ内の構成は二重化構成。

  • ②特になし。

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

1.4

ストレージ

  • ①システム領域/増設ディスク/スナップショットデータは、RAID6相当にてデータ保持。機器については冗長構成となっている。
    仮想サーバーイメージ(カスタマイズイメージ)は保存先のリージョン/ゾーンを選択できる。

  • ②特になし。

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

1.5

災害対策(DR)

  • ①サービスとして提供なし。

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

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

性能・拡張性:リソース拡張性

No.

要件

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

選択値・条件

大項目

中項目

小項目

2.1

性能・拡張性

リソース拡張性

vCPU

  • ①仮想サーバータイプのvCPUスペックは右記のとおり。

    • vCPU性能:仮想サーバータイプを変更することでvCPUを選択可能。

    • vCPU数:仮想サーバータイプを変更することでリージョン・ゾーン別に選択可能。[8]

  • ②提供されている仮想サーバータイプから選択。

  • ③仮想サーバータイプの変更にともない再起動が発生。


8. 選択する仮想サーバータイプによって、組み合わせ可能なメモリ量は異なる。仮想サーバーは提供されている仮想サーバータイプから選択。
  • vCPU性能:ハイスペックモデルvCPU、ベーシックモデルvCPU、ハイコストパフォーマンスモデルvCPUを選択可能。

  • vCPU数
    east-13, east-14, east-31, west-21, us-east-11:1/2/4/6/8/12/16/28/32vCPU
    east-11, east-12, east-41, west-11, west-13:1/2/4/6/8/12/16/28vCPU
    east-21, west-12:1/2/4/6/8vCPU

2.2

メモリ

  • ①仮想サーバーのメモリ量は右記のとおり。
    仮想サーバー:仮想サーバータイプを変更することでリージョン・ゾーン別に選択可能。[9]

  • ②仮想サーバーは提供されている仮想サーバータイプから選択。

  • ③仮想サーバータイプの変更にともない再起動が発生。


9. 選択する仮想サーバータイプによって、組み合わせ可能なvCPU数は異なる。
  • メモリ量
    east-13, east-14, east-31, west-21, us-east-11:0.5/1/2/4/8/16/24/32/48/64/96/128/256/384/512GB
    east-11, east-12, east-41, west-11, west-13:0.5/1/2/4/8/16/24/32/48/64/96/128/256GB
    east-21, west-12:0.5/1/2/4/8/16/24/32/48/64/96GB

2.3

ストレージ

  • ①仮想サーバーのシステム領域は、右記のとおり。(デフォルトで用意されている領域)
    増設ディスクは右記のとおり。(オプションで追加する領域)

  • ②増設ディスクは仮想サーバーへアタッチ済みの増設ディスク容量拡張、またはタイプ、容量を設定し新規に作成。
    仮想サーバー起動状態でアタッチ、デタッチが可能。

  • ③仮想サーバーへアタッチできる増設ディスク数、容量の上限あり。[10]


10. 拡張時は切り戻しが必要な場合に備えて、ディスク拡張操作の前にデータのバックアップを推奨。ディスク拡張後、ゲストOS側でディスク拡張操作が必要。
  • システム領域(デフォルト)Linux系:30GB、Windows系:80GB

  • 標準フラッシュドライブ、高速フラッシュドライブ、標準ディスク、高速ディスク、フラッシュドライブより選択

  • 1サーバ最大14本(計14TB)まで増設可能

  • 1増設ディスク100GB~1TB(100GB単位指定)

  • east-11,east-12,east-13,east-14,east-31,west-13,west-21,us-east-11の標準フラッシュドライブ、高速フラッシュドライブとeast-11,east-12,east-13,east-14,east-31,east-41,west-11,west-13の標準ディスク、高速ディスクのみ100GB~2,000GB(計28TB)

  • 縮小は不可

  • 容量拡張は100GB/回ごと

  • 増設ディスク拡張における作成済みディスクの使用対象OSを下表に示す。

2.4

スケールアップ

  • ①仮想サーバータイプを変更することで可能(No.2.1, No.2.2)。
    ストレージ容量に関しては、増設ディスクの容量を拡張、または追加することでスケールアップ可能。(No.2.3) [11]

  • ②仮想サーバーは提供されている仮想サーバータイプから選択。
    増設ディスクの容量、またはアタッチ数を増やす。
    仮想サーバータイプの変更にともない自動で再起動される。
    再起動される場合、その仮想サーバーで稼働中の業務アプリケーションは中断または停止されるため、仮想サーバーの状態が起動状態になってから、アプリケーション稼働状況の確認(必要なら対処)が必要。

  • ③なし。


11. 新しいディスクは別領域となり、マウントの再定義やデータの移行作業、もしくはOS上での拡張設定等は利用者側での実施が必要。
  • 無停止でのスケールアップ可能(条件あり)[12]

  • 増設ディスクアタッチ数最大14本


12. 現在、ホットスケールアップ機能利用不可

2.5

スケールアウト

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

  • ②スケールアウトに必要なオートスケーリング条件の設定。

  • ③特になし。

2.6

性能品質保証

  • ①vCPU、メモリは仮想サーバータイプに基づくスペックが割り当てられる。(プラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動。)ストレージ、ネットワークも共用型となりベストエフォート。

  • ②スケールアップ、スケールアウト、アプリケーションチューニングを実施。

  • ③特になし。

増設ディスク拡張における作成済みディスクの使用可能OS ※1

CentOS 7.0 プレーンインストール(64bit)

CentOS 7.1 プレーンインストール(64bit)

CentOS 7.4 プレーンインストール(64bit)

CentOS 7.5 プレーンインストール(64bit)

CentOS 7.6 プレーンインストール(64bit)

CentOS 7.7 プレーンインストール(64bit)

CentOS 7.8 プレーンインストール(64bit)

CentOS 7.9 プレーンインストール(64bit)

CentOS 8.1 プレーンインストール(64bit)

CentOS 8.2 プレーンインストール(64bit)

CentOS 8.3 プレーンインストール(64bit)

Rocky Linux 8.4(64bit)

Rocky Linux 8.5(64bit)

AlmaLinux 8.4(64bit)

AlmaLinux 8.5(64bit)

Red Hat Enterprise Linux 7.0(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.1(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.4(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.5(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.6(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.7(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.8(64bit)サブスクリプション付き

Red Hat Enterprise Linux 7.9(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.1(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.2(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.3(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.4(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.5(64bit)サブスクリプション付き

Ubuntu 18.04(64bit)

Ubuntu 20.04(64bit)

Microsoft Windows Server 2012 R2 Standard Edition(64bit)

Microsoft Windows Server 2016 Standard Edition(64bit)

Microsoft Windows Server 2019 Standard Edition(64bit)

Microsoft Windows Server 2022 Datacenter Edition(64bit)

※1 VMインポート、ディスク受取サービス、Liveマイグレーションを利用して、利用者にて持ち込んだサーバー及びOSは対象外。

運用・保守性:運用、サポート体制

No.

要件

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

選択値・条件

大項目

中項目

小項目

3.1

運用・保守性

通常運用

バックアップ

【カスタマイズイメージ】
  • ①バックアップ/リストア関連の機能は以下のとおり。 仮想サーバーで利用するブロックストレージ(システム領域、増設ディスク)はカスタマイズイメージによるバックアップが可能。ただし、カスタマイズイメージ取得の制限サイズを超える領域は事前に切り離しておく必要があり、この切り離した領域のバックアップは別途検討が必要。
    カスタマイズイメージ取得時は、仮想サーバーの停止を推奨。(仮想サーバー稼働中でもオンラインでのカスタマイズイメージの取得は可能だが、サーバー負荷状況等により中断する可能性あり。)また、サーバータイプによってはイメージ化できないため、その場合は対応するサーバータイプを変更後にイメージ化する必要あり。
    リストア時は別サーバーとして起動される。サーバーの二重課金を避けるためには、元サーバーを削除しておく必要がある。
    また、DHCPで配布されたIPアドレスを利用している場合、その値が変更になることが予想される。事前に付替IPを用意しておく等の対策が必要。

  • ②IPアドレスが変更になる。

【バックアップサービス】
  • ①バックアップ/リストア関連の機能は右記のとおり。
    バックアップ対象サーバーの更新差分量によっては、バックアップ処理が失敗する場合があるため注意が必要。
    利用中のリージョンの混雑状況により、希望の時間帯でバックアップ設定ができない場合がるため注意が必要。

  • ②リストア時は別サーバーとして起動される。また、DHCPで配布されたIPアドレスを利用している場合、その値が変更になることが予想される。事前に付替IPを用意しておく等の対策が必要。

  • ③IPアドレスが変更になる。また、OSの仕様によりネットワークインターフェースのeth番号が入れ替わることがある。

【カスタマイズイメージ】
  • 標準システム領域+300GBまでカスタマイズイメージ取得可能

  • e-miniタイプのイメージ取得は仮想サーバー停止が必要

  • イメージ化非対応のサーバータイプあり

  • バックアップ対象:システム領域及び増設ディスク領域(標準システム領域+300GBまで)

  • バックアップ先:各リージョン/ゾーンを選択可能

  • バックアップ契機:手動もしくはAPI

  • バックアップ保存数:20件まで保存可能 (世代管理機能はなし)

【バックアップサービス】
  • 定期バックアップルール設定必須

  • 保持世代数は1~10世代数

  • リストア先はバックアップ対象と同じリージョン/ゾーンに限定

  • バックアップ失敗の可能性あり

  • 対象:ローカルディスク(OS領域含む)+増設ディスクの合計が1.1TBまでのサーバー

  • バックアップ対象サーバーの更新差分量50GB以内(目安)

    • バックアップ対象サーバーの操作制限

    • ワンデイスナップショット機能:利用不可

    • サーバー削除:利用不可

    • 増設ディスク:操作負荷

    • ネットワーク構成、サーバータイプ:構成変更は可能。バックアップデータには未反映

3.2

運用監視

  • ①ハードウエア監視、ハイパーバイザー稼働監視等のクラウド基盤側の監視については、サービス提供側で実施。
    仮想サーバー、ロードバランサー(L4)、マルチロードバランサー、ストレージのリソースを自動的にモニタリングし、リソースごとに定義された監視項目についてモニタリングされたデータを取得。モニタリングデータはパフォーマンスチャートとして表示される。

  • ②監視項目においてしきい値を超えた場合のメール通知設定。
    サービスで提供されていない監視項目については、利用者側で監視ツールを仮想サーバーにインストールが必要。
    モニタリングデータを保存する場合は、利用者がAPIで取得し保存が必要。

  • ③ニフクラで提供される監視項目の最新情報は下記URLにて確認のこと。
    https://pfs.nifcloud.com/service/watch.htm
    利用者側で監視ツールをインストールする際は、仮想環境での動作をサポートしているか確認が必要。

  • パフォーマンスチャート表示期間は最大6ヶ月

  • 期間で“最新”を選択した場合:10分間隔で表示

  • 期間で“カスタム”を選択した場合
    1~7日間以内指定:30分間隔で表示
    8日間以上指定:1日間隔で表示

3.3

保守運用

計画停止

  • ①非活性メンテナンスの情報は、コントロールパネル内のお知らせ欄に掲載。緊急メンテナンス時は、掲載や告知がメンテナンスを実施する直前となることがある。コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知される。
    定期メンテナンス中はコントロールパネルとAPIが利用できない。利用者のサーバーは通常通り利用可能。障害時には、コントロールパネル内のお知らせ欄に情報が掲載される。こちらも、コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知される。
    コントロールパネルにログインできない、またはサービスアクティビティが利用できない事象が発生している場合は、 ニフクラInformationにて障害の情報を確認可能。

  • ②通知内容に応じて対応を検討する。

  • ③特になし

  • メンテナンス実施掲載時期:約14日前(目安)

  • 定期メンテナンス:毎月第3木曜日 午前8時~10時実施

  • 定期メンテナンスは事前告知なし

3.4

パッチ適用

  • ①ハードウエアのセキュリティパッチは定期的にサービス提供側で実施。
    仮想サーバーについては、利用者にてアップデートを実施。

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

  • ③パッチの適用後のアプリケーションの動作検証は利用者側で実施。動作しない場合は切り戻し、もしくはアプリケーションの修正が必要。

3.5

運用環境

開発用環境の設置

  • ①サービスとして開発用環境の提供はなし。

  • ②開発用環境と位置づけた環境(プロジェクト)に仮想サーバーを作成。オプションでネットワークを論理分割することも可能。

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

3.6

試験用環境の設置

  • ①サービスとして試験用環境の提供はなし。

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

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

3.7

サポート体制

  • ①仕様・機能や料金、導入相談などのお問い合わせ窓口と利用中のトラブルについてのお問い合わせ窓口を用意。

  • ②ログやダンプなどの出力は利用者側のアプリケーションで実施。

  • ③特になし。

  • 仕様・機能や料金、導入相談窓口(平日9:00~17:45)

  • トラブルについての問い合わせ(24時間365日※法定点検時等を除く)

  • ベーシックサポート(無償)、エンタープライズサポート(有償)を選択可能

  • 電話対応可能

セキュリティ

No.

要件

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

選択値・条件

大項目

中項目

小項目

4.1

セキュリティ

アクセス・利用制限

認証機能

  • ①サービス:コントロールパネルはユーザーID/パスワード、APIはAccessKey/SecretAccessKeyで認証。コントロールパネルとAPIへアクセスを許可するアクセス元IPアドレスを指定することも可能。

  • ②サービス:コントロールパネルログイン時はユーザーID/パスワード、API使用時はAccessKey/SecretAccessKeyを利用。必要に応じてアクセス元IPアドレスを登録。

  • ③アクセス元IPアドレスが間違った状態で登録されている場合、コントロールパネルやAPIにアクセスできなくなるので注意。その場合は、ニフクラのサポート窓口に連絡して設定解除する必要あり。

4.2

利用制限

  • ①ニフクラID管理者と、操作範囲を制限するための権限を提供。

  • ②業務要件に基づいた権限を設定した子アカウントを作成し、利用者に割り当てる。[13]

  • ③サーバー削除等の事故を避けるため適切な権限設定が必要。


13. ニフクラID管理者はサービス契約時に作成される親アカウント(1つのみ)を指す。
  • 管理者権限、運用者権限、閲覧権限を提供

  • 子アカウントは100アカウント作成可能

  • 一部マルチアカウント未対応サービスあり

  • 運用者権限・閲覧権限のユーザーにポリシー追加可能

4.3

データの秘匿

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

  • ①オンプレミス環境とニフクラ間の接続には以下を提供。

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

    • 専用線/閉域網経由:プライベート接続サービス(プライベートアクセスサービス+ダイレクトポート)

  • ②IPsec VPN機能は拠点間VPNゲートウェイを作成し、オンプレミス環境にVPNルーターを設置する必要がある。
    SSL-VPN機能はリモートアクセスVPNゲートウェイを作成し、利用者端末にクライアントアプリケーションのインストールが必要。
    プライベート接続サービスはスイッチ接続手続きが必要。

  • ③IPsec VPN機能では、動作確認済みVPNルーターの利用を推奨。選択するVPNルーターにより、機能差あり。

4.4

蓄積データ暗号化の有無

  • ①システム領域/増設ディスク/スナップショットデータ/仮想サーバーイメージ/オブジェクトストレージのデータは物理ストレージ書き込み時に暗号化しない。

  • ②暗号化が必要な場合は利用者側でOS上で対処する必要あり。

  • ③east-13,east-14,east-31,west-11,west-13,west-21のローカルディスクでは筐体暗号化対応しています。ただし、Oracle製品の利用をされる場合は、対象ゾーンでは筐体暗号化対応していません。
    east-13の下記増設ディスクでは筐体暗号化対応しています。

    • 標準フラッシュドライブ[A/B]

    • 高速フラッシュドライブ[A/B]

4.5

不正追跡・監視

  • ①ニフクラのオプションサービスとして「Trend Micro Cloud One - Workload Security」を提供。

  • ②業務システムのログ管理については、決定、実装、取得の全てが利用者の責任範囲。
    「Trend Micro Cloud One - Workload Security」で要件が満たせない場合、IPCOMなどの物理機器をプライベート接続サービスで利用する構成などの検討が必要。

  • ③特になし。

4.6

不正アクセス検知・監視

  • ①ニフクラのオプションサービスとして「IDS」を提供。

  • ②報告書内容に応じて対応を検討する。

  • ③特になし。

4.7

ネットワーク対策

ネットワーク制御

  • ①仮想サーバー単位に設定するファイアウォールグループを提供。
    設定するルールは通信方向、通信相手、プロトコル情報で構成。なお、ログはIN/OUT側の拒否ログのみ出力。

  • ②対象の仮想サーバー、仮想ルーターに対して、ルールを設定。
    上記のニフクラ機能以外の対処方法として、Windows FirewallやIISなどのWebサーバー機能を用いてクライアント制限・認証の組み込みも可能。

  • ③共通ネットワークに接続されるサーバーには、IPアドレスの重複を防止するファイアウォールルールが自動的に適用。

4.8

ネットワーク対策

セグメント分割

  • ①プライベートLANを作成し、サブネットを設定することが可能。

  • ②利用者側でネットワークの設計・構築 。 (セグメント分割含む)

  • ③特になし。

  • 1IDあたり最大5本/ゾーン(上限解除申請で7本まで可能)

4.9

マルウエア対策

  • ①ニフクラのオプションサービスとして、「Trend Micro Cloud One - Workload Security」を提供

  • ②Trend Micro Cloud One - Workload Security利用時は、申請書提出後に発行されたActivation Codeを登録し、インストール及び各種セキュリティ設定を実施。Trend Micro Cloud One - Workload Securityの管理サーバーはインターネット側に配置されているため、導入した仮想サーバーはインターネットへ接続する必要がある。

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

データセンター

No.

要件

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

選択値・条件

大項目

中項目

小項目

5.1

データセンター

外部監査

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

  • ②特になし。

  • ③特になし。

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

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

5.2

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

  • ①東日本リージョン、西日本リージョン、北米リージョン [14]

  • ②1つのIDで全リージョンのクラウドリソースを管理可能。

  • ③なし。


14. ゾーン数はリージョンにより異なる。
  • 東日本リージョン1~4、西日本リージョン1、北米リージョン

  • 最小1ゾーン~最大4ゾーン

動作環境:対応OS(スタンダードイメージ)

No.

要件

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

大項目

中項目

小項目

6.1

動作環境

動作仕様

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

  • ①スタンダードイメージとして用意されているOSを下表に示す。 [15]

  • ②提供されるOSイメージより選択。

  • ③OSイメージによって制限があるため注意が必要。
    例:OSイメージによっては、一部のサーバータイプで利用できません。
    (最新の情報は、 https://pfs.nifcloud.com/service/spec.htm を参照)


15. 適宜バージョンアップされるため、最新情報の確認が必要。

①提供OS

CentOS 7.9 プレーンインストール(64bit)

Rocky Linux 8.4(64bit)

Rocky Linux 8.5(64bit)

AlmaLinux 8.4(64bit)

AlmaLinux 8.5(64bit)

Red Hat Enterprise Linux 7.9(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.4(64bit)サブスクリプション付き

Red Hat Enterprise Linux 8.5(64bit)サブスクリプション付き

Ubuntu 18.04(64bit)

Ubuntu 20.04(64bit)

Microsoft Windows Server 2016 Standard Edition(64bit)

Microsoft Windows Server 2016 Standard Edition(64bit)+ SQL Server 2016 Standard Edition SP2

Microsoft Windows Server 2016 Standard Edition(64bit)+ SQL Server 2017 Standard Edition

Microsoft Windows Server 2016 Standard Edition(64bit)+ Windows Server リモートデスクトップ接続(RDS)

Microsoft Windows Server 2016 Standard Edition(64bit)+ Windows Server リモートデスクトップ接続(RDS)+ Office 2016 Standard

Microsoft Windows Server 2019 Standard Edition(64bit)

Microsoft Windows Server 2019 Standard Edition(64bit)+ SQL Server 2017 Standard Edition

Microsoft Windows Server 2019 Standard Edition(64bit)+ SQL Server 2019 Standard Edition

Microsoft Windows Server 2019 Standard Edition(64bit)+ Windows Server リモートデスクトップ接続 (RDS)

Microsoft Windows Server 2019 Standard Edition(64bit)+ Windows Server リモートデスクトップ接続 (RDS) + Office 2019 Standard

Microsoft Windows Server 2022 Datacenter Edition(64bit)

Microsoft Windows Server 2022 Datacenter Edition(64bit)+ Windows Server リモートデスクトップ接続(RDS)

Microsoft Windows Server 2022 Datacenter Edition(64bit)+ SQL Server 2019 Standard Edition

動作環境:対応OS(VM インポート)

No.

要件

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

大項目

中項目

小項目

6.2

動作環境

動作仕様

対応OS
(VMインポート)

  • ①VMインポート検証済みのOSを下表に示す。 [16]

  • ②希望のOSイメージ(OVFファイル及びVMDKファイル)を利用者側で用意。

  • ③Red Hat EnterpriseはRed Hat Cloud Accessを利用してライセンスの持ち込みを行う。
    https://pfs.nifcloud.com/service/rhel_ca.htm 」を参考に、手続きを行うこと。EOLを迎えたバージョン等、利用者のライセンスがCloud Accessで持ち込み可能か不明な場合は、Red Hat社に確認すること。
    Windows Server 2008/2008 R2はTrend Micro Cloud One - Workload Security提供の仮想パッチを適用することで、Microsoftによる延長サポート終了後4年間(2024年6月20日まで)脆弱性保護が可能。


16. これら以外のOSでも利用者責任でインポートを試すことは可能。動作可否についてはニフクラでは確認しない。
①インポート可能OS(CentOS / Rocky Linux / AlmaLinux / Red Hat Enterprise Linux)

CentOS 5.3(32bit/64bit)

CentOS 5.6(64bit)

Red Hat Enterprise Linux 5.8(64bit)

CentOS 5.11(64bit)

Red Hat Enterprise Linux 5.11(64bit)

CentOS 6.0(64bit)

Red Hat Enterprise Linux 6.1(64bit)

CentOS 6.2(64bit)

CentOS 6.3(64bit)

Red Hat Enterprise Linux 6.3(64bit)

CentOS 6.4(32bit/64bit)

Red Hat Enterprise Linux 6.4(32bit/64bit)

CentOS 6.6(64bit)

Red Hat Enterprise Linux 6.6(64bit)

CentOS 6.7(64bit)

Red Hat Enterprise Linux 6.7(64bit)

CentOS 6.9(64bit)

Red Hat Enterprise Linux 6.9(64bit)

CentOS 6.10(64bit)

Red Hat Enterprise Linux 6.10(64bit)

CentOS 7.0(64bit)

Red Hat Enterprise Linux 7.0(64bit)

CentOS 7.1(64bit)

Red Hat Enterprise Linux 7.1(64bit)

CentOS 7.4(64bit)

Red Hat Enterprise Linux 7.4(64bit)

CentOS 7.5(64bit)

Red Hat Enterprise Linux 7.5(64bit)

CentOS 7.6(64bit)

Red Hat Enterprise Linux 7.6(64bit)

CentOS 7.7(64bit)

Red Hat Enterprise Linux 7.7(64bit)

CentOS 7.8(64bit)

Red Hat Enterprise Linux 7.8(64bit)

CentOS 7.9(64bit)

Red Hat Enterprise Linux 7.9(64bit)

CentOS 8.0(64bit)

Red Hat Enterprise Linux 8.0(64bit)

CentOS 8.1(64bit)

Red Hat Enterprise Linux 8.1(64bit)

CentOS 8.2(64bit)

Red Hat Enterprise Linux 8.2(64bit)

CentOS 8.3(64bit)

Red Hat Enterprise Linux 8.3(64bit)

Rocky Linux 8.4(64bit)

AlmaLinux 8.4(64bit)

Red Hat Enterprise Linux 8.4(64bit)

Rocky Linux 8.5(64bit)

AlmaLinux 8.5(64bit)

Red Hat Enterprise Linux 8.5(64bit)

②インポート可能OS(Windows) ※1,※2

Microsoft Windows Server 2008 R2 Standard Edition(64bit)

Microsoft Windows Server 2008 R2 Enterprise Edition(64bit)

Microsoft Windows Server 2012 Standard Edition(64bit)

Microsoft Windows Server 2012 R2 Standard Edition(64bit)

Microsoft Windows Server 2016 Standard Edition(64bit)

Microsoft Windows Server 2019 Standard Edition(64bit)

Microsoft Windows Server 2022 Datacenter Edition(64bit)

※1 2021/12/8以降、インポート可能OSからMicrosoft Windows Server 2003は削除。
※2 二フクラ提供側で動作確認がとれたものを記載。記載の無いOSについても、インポートできる可能性あり。

③インポート可能OS(Ubuntu)

Ubuntu 10.04(64bit)

Ubuntu 14.04(64bit)

Ubuntu 16.04(64bit)

Ubuntu 18.04(64bit)

Ubuntu 20.04(64bit)

動作環境:仮想サーバーのタイプ Type-h2

No.

要件

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

大項目

中項目

小項目

6.3

動作環境

動作仕様

仮想サーバーのタイプ
(east-11,east-12,east-13,east-14,east-21,east-31,east-41,west-11,west-12,west-13,west-21,us-east-11)

  • ①仮想サーバータイプは下表から選択可能。
    ただしプラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動。

  • ②業務要件に合わせて選択。定量的な性能値は公表されていないため、サイジングには利用者側の検証が必要。

  • ③仮想サーバータイプによって起動中に実施できる機能に制限があるため注意が必要。
    例:一部のサーバーでは、ホットスケールアップや、サーバーを起動したままでのサーバーコピー、カスタマイズイメージの作成といった操作ができません。[17]
    (最新の情報は、「 https://pfs.nifcloud.com/service/spec.htm 」を参照)
    Type-h2(ハイスペックモデル)は、高いパフォーマンスが求められるシステムでの利用を想定したサーバープランです。[18]


17. 現在ホットスケールアップの機能は利用できません。
18. 一部サーバータイプの作成台数上限についてqlarge256, slarge256, olarge256, olarge384, olarge512は、ゾーンごとに作成できる台数に上限有。上限に達した場合は、コントロールパネル/APIで「エラーが発生しました。サポートまでお問い合わせください。」というメッセージが表示される。その場合は他のゾーンでの作成するか、サポート窓口まで問い合わせしてください。希望に添えず作成できない場合は、他のゾーンで作成頂くよう案内する可能性があるため注意が必要。

①仮想サーバータイプ(Type-h2)

サーバータイプ

vCPU

メモリ(GB)

h2-mini

1

0.5

h2-small

1

1

h2-small2

1

2

h2-small4

1

4

h2-small8

1

8

h2-small16

1

16

h2-medium

2

2

h2-medium4

2

4

h2-medium8

2

8

h2-medium16

2

16

h2-medium24

2

24

h2-large

4

4

h2-large8

4

8

h2-large16

4

16

h2-large24

4

24

h2-large32

4

32

h2-xlarge8

6

8

h2-xlarge16

6

16

h2-xlarge24

6

24

h2-xlarge32

6

32

h2-xlarge48

6

48

h2-wlarge16

8

16

h2-wlarge24

8

24

h2-wlarge32

8

32

h2-wlarge48

8

48

h2-wlarge64

8

64

h2-wlarge96

8

96

h2-tlarge32 ※1

12

32

h2-tlarge48 ※1

12

48

h2-tlarge64 ※1

12

64

h2-tlarge96 ※1

12

96

h2-tlarge128 ※1

12

128

h2-qlarge64 ※1

16

64

h2-qlarge96 ※1

16

96

h2-qlarge128 ※1

16

128

h2-qlarge256 ※1

16

256

h2-slarge128 ※1

28

128

h2-slarge256 ※1

28

256

h2-olarge256 ※2

32

256

h2-olarge384 ※2

32

384

h2-olarge512 ※2

32

512

※1 east-11, east-12, east-13, east-14,east-41,west-11,west-13, west-21,us-east-11のみ作成可能
※2 east-13, east-14, west-21,us-east-11のみ作成可能

動作環境:仮想サーバーのタイプ Type-e

No.3

要件

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

大項目

中項目

小項目

6.4

動作環境

動作仕様

仮想サーバーのタイプ(east-11,east-12,east-13,east-14,east-21,east-31,east-41,west-11,west-12,west-13,west-21,us-east-11)

  • ①仮想サーバータイプは下表から選択可能。
    ただしプラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動。

  • ②業務要件に合わせて選択。定量的な性能値は公表されていないため、サイジングには利用者側の検証が必要。

  • ③仮想サーバータイプによって起動中に実施できる機能に制限があるため注意が必要。
    例:一部のサーバーでは、ホットスケールアップや、サーバーを起動したままでのサーバーコピー、カスタマイズイメージの作成といった操作ができません。[19]
    (最新の情報は、「 https://pfs.nifcloud.com/service/spec.htm 」を参照)
    Type-e(ベーシックモデル)は、一般的な業務システムなど多くのシステムでご利用頂ける、コストパフォーマンスと汎用性の高いサーバープランです


19. 現在ホットスケールアップの機能は利用できません。
①仮想サーバータイプ(Type-e)

サーバータイプ

vCPU

メモリ(GB)

e-mini

1

0.5

e-small

1

1

e-small2

1

2

e-small4

1

4

e-small8

1

8

e-small16

1

16

e-medium

2

2

e-medium4

2

4

e-medium8

2

8

e-medium16

2

16

e-medium24

2

24

e-large

4

4

e-large8

4

8

e-large16

4

16

e-large24

4

24

e-large32

4

32

e-xlarge8

6

8

e-xlarge16

6

16

e-xlarge24

6

24

e-xlarge32

6

32

e-xlarge48

6

48

e-wlarge16

8

16

e-wlarge24

8

24

e-wlarge32

8

32

e-wlarge48

8

48

e-wlarge64

8

64

e-wlarge96

8

96

動作環境:仮想サーバーのタイプ Type-c

No.

要件

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

大項目

中項目

小項目

6.5

動作環境

動作仕様

仮想サーバーのタイプ (east-11,east-12,east-13,east-14,east-21,east-41,west-11,west-12,west-13,west-21,us-east-11)

  • ①仮想サーバータイプは下表から選択可能。
    ただしプラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動。

  • ②業務要件に合わせて選択。定量的な性能値は公表されていないため、サイジングには利用者側の検証が必要。

  • ③仮想サーバータイプによって起動中に実施できる機能に制限があるため注意が必要。
    例:一部のサーバーでは、ホットスケールアップや、サーバーを起動したままでのサーバーコピー、カスタマイズイメージの作成といった操作ができません。[20]
    (最新の情報は、「 https://pfs.nifcloud.com/service/spec.htm 」を参照)
    Type-c(ハイコストパフォーマンスモデル)は、高いコストパフォーマンスを発揮するサーバープランです。


20. 現在ホットスケールアップの機能は利用できません。

①仮想サーバータイプ(Type-c)

サーバータイプ

vCPU

メモリ(GB)

c-small

1

1

c-small2

1

2

c-small4

1

4

c-medium

2

2

c-medium4

2

4

c-medium8

2

8

c-large

4

4

c-large8

4

8

動作環境:その他

No.

要件

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

選択値・条件

大項目

中項目

小項目

6.7

動作環境

VMware Toolsのバージョン

  • ①必須バージョンは右記のとおり。

  • ②必須バージョンより古いバージョンを利用している場合は、VMware Toolsの更新が推奨される。

  • ③必須バージョンより古いバージョンを利用し続けてもサーバーの稼働そのものへの影響はないが、クラウド基盤のバージョンアップにともない、コントロールパネルの表示や特定の機能が正常に動作しなくなる場合がある。
    VMware-Toolsの起動状態、バージョンについてはコントロールパネルのサーバー詳細画面から確認が可能。[21] [22] [23]


21. VMware-Toolsのバージョン表記は、バージョンが「10.1.15」未満の場合は「10.1.15以前のバージョン」と表示される。
22. SHA-2コード署名をサポートしていないWindows Server 2008 R2では、VMware Tools 11.2.0以降のアップグレードに失敗します。
23. Windows Server 2008 R2は、2019年3月にリリースされた更新プログラムによってSHA-2コード署名がサポートされるようになるため、VMware Toolsのアップグレードを行うために更新プログラムの適用が必要となる場合があります。

必須バージョン:VMware Tools 10.2.0以上

6.8

ストレージ容量

  • ①ストレージ容量はNo.2.3参照。

  • ②特になし。

  • ③特になし。

6.9

ネットワーク接続形態

  • ①コントロールパネルへはhttps接続、仮想サーバーなどへのアクセスはIPsec VPN接続、SSL-VPN接続、インターネット接続が可能。利用者のデータセンターとニフクラのプライベート接続も可能。

  • ②ニフクラとオンプレミス環境をIPsec VPN機能で接続する場合、オンプレミス環境にVPNルーターが必要。ニフクラ側は拠点間VPNゲートウェイの追加設定が必要。
    ニフクラと利用者端末をSSL-VPN機能で接続する場合、利用者端末にクライアントアプリケーションのインストールが必要。ニフクラ側はリモートアクセスVPNゲートウェイの設定が必要。

  • ③特になし。

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

No.

要件

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

選択値・条件

大項目

中項目

小項目

7.1

サービス利用

稼働状況報告

  • ①稼働状況の利用者への報告はなし。

  • ②基本監視等を利用して利用者側で確認。

  • ③特になし。

8.1

システム特性

負荷分散への対応

  • ①外部/内部通信ともに負荷分散可能。セッションの維持機能/ヘルスチェック機能/Sorryページ表示機能。

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

  • ③ロードバランサー(L4)は、ゾーンを跨いだ負荷分散が可能。マルチロードバランサーは、内部通信の負荷分散が可能。高機能ロードバランサーが必要な場合は、L7ロードバランサー(Ivanti Virtual Traffic Manager)または統合ネットワークサービス(IPCOM VE2シリーズ)の利用を検討。

1ロードバランサー(L4)で3ポート設定可能

8.2

システム連携

  • ①IPsec VPN通信を用いてインターネット経由により、オンプレミス環境やリージョン間の連携が可能。
    プライベート接続サービスを用いて専用線/閉域網経由により、オンプレミス環境やリージョン間の連携が可能。

  • ②連携の仕組みを実装。

  • ③特になし。

9.1

移行

移行方法

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

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

  • ③VMインポートの利用を検討する場合、「 https://pfs.nifcloud.com/service/vmimport.htm 」にて前提条件等の確認が必要。

OVF+VMDKファイル形式以外は移行不可

3.システムパターンの検討

ニフクラのリージョンとゾーンについて(参考)
  • ニフクラは契約することで複数のリージョンを利用することが可能です。リージョンの定義は国や地域など、地理的に離れた場所を指します。

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

image

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

システムパターンの検討

災害対策やゾーン障害対策などの観点から適用するシステムパターンを選択してください。

災害対策(地理的冗長)

ゾーン規模障害対策

仮想サーバーSLA対象※1

許容可能
停止時間※2

代表的システム

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

対象

無停止~数分

重要
基幹システム [24]


24. グローバル展開が必要/地域的な災害発生時でも業務継続が必要なシステムを指します。

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

不要

対象

無停止~数分

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

不要

対象

無停止~数時間

基幹システム [25]


25. ゾーン障害時に業務継続が必要なシステムを指します。

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

不要

対象

数日程度

非基幹/情報参照系システム [26]


26. ゾーン障害時に業務継続が不要なシステムを指します。

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

※1
ニフクラでは、仮想サーバー、ネットワークサービス等にSLAを設定しています。 それぞれのサービスで設定している稼働率は異なりますので、詳細は、以降を参照ください。
https://pfs.nifcloud.com/sla/
※2
障害発生の状況やシステム構成などにより、停止時間は異なるため目安としてください。記載の停止時間を実現するには、提供機能以外の部分で利用者側でも設計・構築が必要です。

システムパターン比較表

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

マルチリージョン・マルチゾーン ※1

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

マルチリージョン・シングルゾーン ※1

シングルリージョン・シングルゾーン

構成要素

image

image

image

image

各リージョンでActive/Standby、各ゾーンでActive/Activeとする構成を前提としたシステム構成例

シングルリージョン構成のリージョン内において、各ゾーンでActive/Activeとする構成を前提としたシステム構成例

リージョン内をシングルゾーン構成とし、各リージョンでActive/Standbyとする構成を前提としたシステム構成例

シングルリージョン、シングルゾーン構成としたロケーションサービスによる冗長性を持たない運用を前提としたシステム構成例

リージョン障害対策

DNSサービスによる自動/手動切替

なし

DNSサービスによる自動/手動切替

なし

ゾーン障害対策

ロードバランサー(L4)、プライベートブリッジを利用したデータベース冗長化(利用者による構築)

ロードバランサー(L4)、プライベートブリッジを利用したデータベース冗長化(利用者による構築)

なし

なし

別リージョン、別ゾーンへのデータ保存

物理サーバー故障に対しては、全パターンでHA機能が標準装備されています。ただし、HAが発生した場合、仮想サーバーは再起動される形となります。

※1:国をまたがるマルチリージョン構成の場合、リージョン所在地の国や共同体の法令を遵守する必要があります。

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

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

No.

適用システムパターン

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

1

image

  • 各リージョンでActive/Standby、各ゾーンでActive/Activeとする構成を前提としたシステム構成例となります。 本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

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

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

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

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

    • 各リージョンに対し、データベース仮想サーバーをマルチゾーン構成で構築します。プライベートブリッジ機能を使ってプライベートLANをゾーン間接続し、マルチゾーンの冗長化を組みます。利用者自身で設計・構築する必要があります。 [27]

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

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

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

    【ゾーン障害対策】
    • ゾーン障害が発生した際、以下のシステムが自動で切り替わります。
      フロントエンドシステム:ロードバランサー(L4)により切替
      データベースシステム:データベース冗長化構成により切替(構築した構成による)

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

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

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

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


27. 業務データはリージョン間接続経由でセカンダリリージョン側へ転送します。
28. プライマリ側のロードバランサー(L4)へのヘルスチェックがエラーとなり、一定の切替条件を満たせば、自動的にセカンダリ側のロードバランサー(L4)のIPアドレスをDNSが返却するようになります。
29. セカンダリリージョンへバックアップデータ保存用仮想サーバーを構築します。
シングルリージョン・マルチゾーン

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

No.

適用システムパターン

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

2

image

  • シングルリージョン構成のリージョン内において、各ゾーンでActive/Activeとする構成を前提としたシステム構成例となります。
    本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

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

    • ロードバランサー(L4)をマルチゾーン負荷分散構成で構築します。フロントエンドシステムは構築したロードバランサー(L4)配下に登録します

    • マルチゾーンに配置されたデータベース仮想サーバーを冗長構成で構築します。プライベートブリッジ機能を使ってプライベートLANをゾーン間接続し、それぞれのゾーンにデータベースを用意してマルチゾーンの冗長化を組みます。利用者自身で設計・構築する必要があります

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

    【ゾーン障害対策】
    • ゾーン障害が発生した際、以下のシステムが自動で切り替わります。
      フロントエンドシステム:ロードバランサー(L4)により切替
      データベースシステム:データベース冗長化構成により切替(構築した構成による)

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

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

    【運用】
    • 障害検知のための監視サーバーは各ゾーンに用意します。

    • 片方のゾーン内にバックアップサーバーを構築して、取得したバックアップデータを別ゾーンに保存します。[30]


30. 別ゾーン内にバックアップデータ保存用仮想サーバーを構築します。
マルチリージョン・シングルゾーン

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

No.

適用システムパターン

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

3

image

  • リージョン内をシングルゾーン構成とし、各リージョンでActive/Standbyとする構成を前提としたシステム構成例となります。
    本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

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

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

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

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

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

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

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

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

    【ゾーン障害対策】
    • シングルゾーン構成のため、ゾーン障害時もリージョン障害対策と同様に切り替えます。

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

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

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

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


31. シングルゾーンの場合、マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)でも構築可能です。
32. 業務データはリージョン間接続経由でセカンダリリージョン側へ転送します。
33. プライマリ側のロードバランサー(L4)へのヘルスチェックがエラーとなり、一定の切替条件を満たせば、自動的にセカンダリ側のロードバランサー(L4)のIPアドレスをDNSが返却するようになります。
34. セカンダリリージョンへバックアップデータ保存用仮想サーバーを構築します。
シングルリージョン・シングルゾーン

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

No.

適用システムパターン

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

4

image

  • シングルリージョン、シングルゾーン構成としたロケーションサービスによる冗長性を持たない運用を前提としたシステム構成例となります。
    本構成例を実現するために利用者側が実施すべき作業を以下に記載します。

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

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

    • データベース仮想サーバーをシングルゾーン構成(DB冗長化構成)で構築します。

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

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

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

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

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

    • バックアップデータは同一ゾーン内に保存します。


35. シングルゾーンの場合、マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)、統合ネットワークサービス(IPCOMVE2シリーズ)でも構築可能です。
No.1 マルチリージョン・マルチゾーン

本構成は各リージョンをActive/Standby、各ゾーンをActive/Activeで構成するシステム構成例の概要図です。図に記載された吹き出し番号は次ページからの番号に対応しています。

image

リージョン障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン間接続

災害対策 (地理的冗長)

リージョン間通信を行う場合、プライベートブリッジやインターネット回線を利用できます。
インターネット回線を利用する場合、オプションの拠点間VPNゲートウェイを使って、インターネットVPN通信を行うことも可能です。

  • 各リージョンでIP重複が起こらない様、ネットワーク構成を設計してください。

  • 拠点間VPNゲートウェイでL2接続をする場合、ループが発生しないようネットワーク設計してください。

2

仮想サーバー

災害対策 (地理的冗長)

リージョン間でカスタマイズイメージを共有することが可能なため、各リージョンで同じイメージからサーバーを構築することが可能です。

  • 各リージョンでサーバーを構築するため、それぞれのリージョンでメンテナンス作業など、運用・保守作業が必要となります。

  • リージョンごとのサーバー配置(切替時の縮退運用等)について利用者にて別途設計してください。

3

業務データ

災害対策 (地理的冗長)

ニフクラでは、リージョン間で業務データをデータ同期するサービスが提供されていないため、復旧時間を短縮するために、利用者にてリージョン間でデータ同期の仕組みを構築する必要があります。

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

4

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

災害対策 (地理的冗長)

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

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

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

リージョン障害:監視とバックアップ

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

5

リージョン監視

災害対策 (地理的冗長)

リージョン障害を検知する場合、監視対象リージョン以外(別リージョン、オンプレミス環境等)から監視を行う必要があります。 [36]


36. 障害対象リージョンに監視サーバーが配備されている場合、通信不可となり監視不可となるため。
  • ニフクラの基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上の監視を行うためには、別途有人監視サービス (オプション)をご利用頂くか、監視サーバーを構築してください。

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

6

バックアップ

災害対策 (地理的冗長)

リージョンを跨いだバックアップとしてカスタマイズイメージの取得が可能です。 ただし、カスタマイズイメージ取得の制限サイズを超える分については、サードパーティー製のバックアップソフトウエアを利用したファイルレベルでのバックアップの検討が必要です。 バックアップソフトウエアを利用し、セカンダリリージョン側の仮想サーバーへアタッチしたブロックストレージへリージョン間接続間経由でデータ転送を行います。
また、バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用することで、ニフクラ外の環境にバックアップを行うことも可能です。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。
    また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。
    その作業手順や運用ルールについては、利用者にて設計してください。

  • ファイルレベルのバックアップを実施する場合は、バックアップサーバーを別途用意してください。

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

  • バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用するには、バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

  • リージョン跨ぎでのニフクラのバックアップ、スナップショット取得不可

  • 標準システム領域+300GBまでカスタマイズイメージ取得可能

ゾーン間通信障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

7

ゾーン間通信

ゾーン規模障害対策

ゾーン間通信を行う場合プライベートブリッジを配備する必要があります。

  • ゾーン障害時に業務データのスプリット・ブレイン
    (データベースデータ等)が起こらない様、アプリケーション部分について、利用者にて別途設計が必要です。 [37]


37. スプリット・ブレインの原因と対策例:ハートビート通信を行うネットワークに断線などの問題が発生した場合、ホストに障害が起こったと勘違いし、本来立ち上がってほしくないStandby側のホストがActiveになってしまいます。そのため、ゾーン間で障害監視を行うとともに、別環境(他リージョン、オンプレミス環境等)からの障害監視が必要となります。
ゾーン規模障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

8

仮想サーバー

ゾーン規模障害対策

ゾーン間はActive/Active構成とするため、それぞれのゾーンに同一構成の仮想サーバーを構築する必要があります。
制限サイズ内の仮想サーバーであれば、イメージ化することができるため、同一イメージを使った仮想サーバー構築を行うことで、構築作業を短縮することができます。
また、ロードバランサー(L4)における、負荷分散対象サーバーを容易に作成することも可能となります。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。その作業手順や運用ルールについては、利用者にて設計してください。

  • 設定変更等をイメージに反映させたい場合は、イメージの再取得が必要となります。

  • 標準システム領域+300GBまでイメージ化可能

  • e-miniタイプのイメージ取得は仮想サーバー停止が必要

9

業務データ

ゾーン規模障害対策

WebサーバーやAPサーバー、利用者側で構築したデータベースサーバーにおける業務データの復旧時間を短縮するためには、ゾーン間でデータ同期の仕組みを利用者にて構築する必要があります。

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

ゾーン間での業務データ同期サービス未提供

10

ロードバランサー(L4)

ゾーン規模障害対策

ロードバランサー(L4)配下には、複数ゾーン内の仮想サーバーを接続することができるため、ゾーンを跨いだ負荷分散構成を構築することが可能です。
上記構成とすることで、片方のゾーンに障害が発生しても、もう片方のゾーンで業務継続が可能です。

  • 障害となったゾーン内の仮想サーバーから死活監視の応答がない場合、自動的にロードバランサー(L4)から切り離されます。明示的に切り離しを行いたい場合には、コントロールパネルからの手動操作か、APIによる操作を行ってください。

3ポート/1ロードバランサー(L4)
(IPアドレスは1つのみ)

11

データベースサーバー

ゾーン規模障害対策

ゾーン間でプライベートLANを接続できるプライベートブリッジ機能を使い、データベース仮想サーバーをマルチゾーンで冗長化します。

  • 利用者側でデータベースを新規に構築し、データ同期や切替の仕組みを利用者にて別途設計・構築する必要があります。

ゾーン規模障害:監視とバックアップ

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

12

ゾーン監視

ゾーン規模障害対策

ゾーン障害を検知する場合、対象ゾーン以外(別ゾーン、オンプレミス環境等) から監視を行う必要があります。[38]


38. 障害対象ゾーンに監視サーバーが配備されている場合、通信不可となり監視不可となるため。
  • ニフクラの基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上の監視を行うためには、別途有人監視サービス(オプション)をご利用頂くか、監視サーバーを構築してください。

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

13

バックアップ

ゾーン規模障害対策

ゾーンを跨いだバックアップとしてカスタマイズイメージの取得が可能です。ただし、カスタマイズイメージ取得の制限サイズを超える分については、サードパーティー製のバックアップソフトウエアを利用したファイルレベルでのバックアップの検討が必要です。バックアップソフトウエアを利用し、セカンダリリージョン側の仮想サーバーへアタッチしたブロックストレージへリージョン間接続間経由でデータ転送を行います。
また、バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用することで、ニフクラ外の環境にバックアップを行うことも可能です。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。その作業手順や運用ルールについては、利用者にて設計してください。

  • ファイルレベルのバックアップを実施する場合は、バックアップサーバーを別途用意してください。

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

  • バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用するには、バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

標準システム領域+300GBまでカスタマイズイメージ取得可能

メンテナンス時の対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

14

物理サーバー

メンテナンス時対策

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

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

15

ネットワークノード

メンテナンス時対策

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

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

16

ストレージノード

メンテナンス時対策

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

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

17

仮想サーバー

メンテナンス時対策

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

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

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

クラウド基盤障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

18

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけたい場合には、マルチゾーン構成を検討する必要があります。

  • HAでの自動復旧時3~5分程度(目安)のサーバー停止

19

ネットワーク機器

クラウド基盤障害対策

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

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

20

ストレージ機器

クラウド基盤障害対策

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

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

21

仮想サーバー

クラウド基盤障害対策

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

  • 障害検知については監視サービスや監視用のソフトウエアを導入する必要があります。また、復旧方式については利用者にて別途設計が必要です。

No.2 シングルリージョン・マルチゾーン

本構成はシングルリージョン構成のリージョン内において、各ゾーンでActive/Activeとする構成を前提としたシステム構成例の概念図です。図に記載された吹き出し番号は次ページからの番号に対応しています。

image

リージョン障害/ゾーン間通信障害

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策 (地理的冗長)

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

2

ゾーン間通信

ゾーン規模障害対策

ゾーン間通信を行う場合、プライベートブリッジを配備する必要があります。

  • ゾーン障害時に業務データのスプリット・ブレイン(データベースデータ等)が起こらない様、アプリケーション部分について、利用者にて別途設計が必要です。[39]


39. スプリット・ブレインの原因と対策例:ハートビート通信を行うネットワークに断線などの問題が発生した場合、ホストに障害が起こったと勘違いし、本来立ち上がってほしくないStandby側のホストがActiveになってしまいます。そのため、ゾーン間で障害監視を行うとともに、別環境(他リージョン、オンプレミス環境等)からの障害監視が必要となります。
ゾーン規模障害対策

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

No.

検討事項

対策観点

検討内容

検討時のポイント

選択値・条件

3

仮想サーバー

ゾーン規模障害対策

ゾーン間はActive/Active構成とするため、それぞれのゾーンに同一構成の仮想サーバーを構築する必要があります。
制限サイズまでイメージ化することができるため、同一イメージを使った仮想サーバー構築を行うことで、構築作業を短縮することができます。
また、ロードバランサー(L4)における、負荷分散対象サーバーを容易に作成することも可能となります。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。その作業手順や運用ルールについては、利用者にて設計してください。

  • 設定変更等をイメージに反映させたい場合は、イメージの再取得が必要となります。

  • 標準システム領域+300GBまでイメージ化可能

  • e-miniタイプのイメージ取得は仮想サーバー停止が必要

4

業務データ

ゾーン規模障害対策

WebサーバーやAPサーバー、利用者側で構築したデータベースサーバーにおける業務データの復旧時間を短縮するためには、ゾーン間でデータ同期の仕組みを利用者にて構築する必要があります。

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

ゾーン間での業務データ同期サービス未提供

5

ロードバランサー(L4)

ゾーン規模障害対策

ロードバランサー(L4)配下には、複数ゾーン内の仮想サーバーを接続することができるため、ゾーンを跨いだ負荷分散構成を構築することが可能です。
上記構成とすることで、片方のゾーンに障害が発生しても、もう片方のゾーンで業務継続が可能です。

  • 障害となったゾーン内の仮想サーバーから死活監視の応答がない場合、自動的にロードバランサー(L4)から切り離されます。明示的に切り離しを行いたい場合には、コントロールパネルからの手動操作か、APIによる操作を行ってください。

3ポート/1ロードバランサー(L4)
(IPアドレスは1つのみ)

6

データベースサーバー

ゾーン規模障害対策

ゾーン間でプライベートLANを接続できるプライベートブリッジ機能を使い、データベース仮想サーバーをマルチゾーンで冗長化します。

  • 利用者側でデータベースを新規に構築し、データ同期や切り替えの仕組みを利用者にて別途設計・構築する必要があります。

ゾーン規模障害・監視とバックアップ

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

7

ゾーン監視

ゾーン規模障害対策

ゾーン障害を検知する場合、対象ゾーン以外(別ゾーン、オンプレミス環境等) から監視を行う必要があります。[40]


40. 障害対象ゾーンに監視サーバーが配備されている場合、通信不可となり監視不可となるため。
  • ニフクラの基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上の監視を行うためには、別途有人監視サービス(オプション)をご利用頂くか、監視サーバーを構築してください。

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

8

バックアップ

ゾーン規模障害対策

ゾーンを跨いだバックアップとしてカスタマイズイメージの取得が可能です。ただし、カスタマイズイメージ取得の制限サイズを超える分については、サードパーティー製のバックアップソフトウエアを利用したファイルレベルでのバックアップの検討が必要です。バックアップソフトウエアを利用し、セカンダリリージョン側の仮想サーバーへアタッチしたブロックストレージへリージョン間接続間経由でデータ転送を行います。
また、バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用することで、ニフクラ外の環境にバックアップを行うことも可能です。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。その作業手順や運用ルールについては、利用者にて設計してください。

  • ファイルレベルのバックアップを実施する場合は、バックアップサーバーを別途用意してください。

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

  • バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用するには、バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

標準システム領域+300GBまでカスタマイズイメージ取得可能

メンテナンス時の対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

9

物理サーバー

メンテナンス時対策

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

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

10

ネットワークノード

メンテナンス時対策

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

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

11

ストレージノード

メンテナンス時対策

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

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

12

仮想サーバー

メンテナンス時対策

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

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

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

クラウド基盤障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

13

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけたい場合には、マルチゾーン構成を検討する必要があります。

  • HAでの自動復旧時3~5分程度(目安)のサーバー停止

14

ネットワーク機器

クラウド基盤障害対策

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

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

15

ストレージ機器

クラウド基盤障害対策

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

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

16

仮想サーバー

クラウド基盤障害対策

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

  • 障害検知については監視サービスや監視用のソフトウエアを導入する必要があります。
    また、復旧方式については利用者にて別途設計が必要です。

No.3 マルチリージョン・シングルゾーン

本構成はリージョン内をシングルゾーン構成とし、各リージョンでActive/Standbyとする構成を前提としたシステム構成例の概念図です。図に記載された吹き出し番号は次ページからの番号に対応しています。

image

災害対策/地理的冗長

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

1

リージョン間接続

災害対策(地理的冗長)

リージョン間通信を行う場合、プライベートブリッジやインターネット回線を利用できます。
インターネット回線を利用する場合、オプションの拠点間VPNゲートウェイを使って、インターネットVPN通信を行うことも可能です。

  • 各リージョンでIP重複が起こらない様、ネットワーク構成を設計してください。

  • 拠点間VPNゲートウェイでL2接続をする場合、ループが発生しないようネットワーク設計してください。

2

仮想サーバー

災害対策(地理的冗長)

リージョン間でカスタマイズイメージを共有することが可能なため、各リージョンで同じイメージからサーバーを構築することが可能です。

  • 各リージョンでサーバーを構築するため、それぞれのリージョンでメンテナンス作業など、運用・保守作業が必要となります。

  • リージョンごとのサーバー配置(切替時の縮退運用等)について、利用者にて別途設計してください。

3

業務データ

災害対策(地理的冗長)

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

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

リージョン間での業務データ同期サービス未提供

4

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

災害対策(地理的冗長)

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

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

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

災害対策/ゾーン障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

5

リージョン監視

災害対策 (地理的冗長)

リージョン障害を検知する場合、監視対象リージョン以外(別リージョン、オンプレミス環境等)から監視を行う必要があります。[41]


41. 障害対象リージョンに監視サーバーが配備されている場合、通信不可となり監視不可となるため。
  • ニフクラの基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上の監視を行うためには、別途有人監視サービス(オプション)をご利用頂くか、監視サーバーを構築してください。

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

6

バックアップ

災害対策 (地理的冗長)

リージョンを跨いだバックアップとしてカスタマイズイメージの取得が可能です。ただし、カスタマイズイメージ取得の制限サイズを超える分については、サードパーティー製のバックアップソフトウエアを利用したファイルレベルでのバックアップの検討が必要です。バックアップソフトウエアを利用し、セカンダリリージョン側の仮想サーバーへアタッチしたブロックストレージへリージョン間接続間経由でデータ転送を行います。また、バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用することで、ニフクラ外の環境にバックアップを行うことも可能です。

  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域は一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。
    その作業手順や運用ルールについては、利用者にて設計してください。

  • ファイルレベルのバックアップを実施する場合は、バックアップサーバーを別途用意してください。

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

  • バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を利用するには、バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

  • リージョン跨ぎでのニフクラのバックアップ、スナップショット取得不可

  • 標準システム領域+300GBまでカスタマイズイメージ取得可能

7

ゾーン障害

ゾーン規模障害対策

シングルゾーン構成のため、リージョン切替にて対応する必要があります。

メンテナンス時の対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

8

物理サーバー

メンテナンス時対策

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

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

9

ネットワークノード

メンテナンス時対策

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

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

10

ストレージノード

メンテナンス時対策

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

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

11

仮想サーバー

メンテナンス時対策

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

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

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

クラウド基盤障害対策

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

12

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけたい場合には、マルチゾーン構成を検討する必要があります。

  • HAでの自動復旧時3~5分程度(目安)のサーバー停止

13

ネットワーク機器

クラウド基盤障害対策

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

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

14

ストレージ機器

クラウド基盤障害対策

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

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

15

仮想サーバー

クラウド基盤障害対策

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

  • 障害検知については監視サービスや監視用のソフトウエアを導入する必要があります。
    また、復旧方式については利用者にて別途設計が必要です。

No.4 シングルリージョン・シングルゾーン

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

image

リージョン障害/ゾーン障害

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

1

リージョン障害

災害対策
(地理的冗長)

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

2

ゾーン障害

ゾーン規模障害対策

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

3

物理サーバー

メンテナンス時対策

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

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

4

ネットワークノード

メンテナンス時対策

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

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

5

ストレージノード

メンテナンス時対策

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

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

6

仮想サーバー

メンテナンス時対策

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

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

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

物理環境と仮想サーバー

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

7

物理サーバー

クラウド基盤障害対策

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

  • できるだけ無停止に近づけたい場合には、マルチゾーン構成を検討する必要があります。

  • HAでの自動復旧時3~5分程度(目安)のサーバー停止

8

ネットワーク機器

クラウド基盤障害対策

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

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

9

ストレージ機器

クラウド基盤障害対策

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

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

10

仮想サーバー

クラウド基盤障害対策

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

  • 障害検知については監視サービスや監視用のソフトウエアを導入する必要があります。
    また、復旧方式については利用者にて別途設計が必要です。

監視

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

11

監視

クラウド基盤障害対策

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

  • ニフクラの基本監視サービスはクラウド基盤からのリソース監視のみであるため、OS層以上の監視を行うためには、別途有人監視サービス(オプション)をご利用頂くか、監視サーバーを構築してください。

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

  • システム要件によっては、ニフクラ以外の環境(オンプレミス環境等)へ監視サーバーを構築してください。

バックアップ

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

No.

検討事項

対策観点

検討内容

検討時の重点ポイント

選択値・条件

12

バックアップ

クラウド基盤障害対策

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

【ワンデイスナップショット】

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

【カスタマイズイメージ】

別ゾーン、別リージョンに保存することが可能です。

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

ニフクラ外にバックアップすることができます。

【バックアップ】

バックアップデータは同一ゾーンに保管されますが、サーバーのデータを保管しているストレージとは異なるストレージで保管するため、データの保全向上が見込まれます。

【ワンデイスナップショット】
  • 作成から一定時間経過後、または更新差分が一定サイズを超えた場合、スナップショットは自動削除されます。

  • アプリケーション部分の復旧は、別途設計してください。

【カスタマイズイメージ】
  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域を、一度切り離す必要があります。また、サーバータイプによってはそのままイメージ化できず、対応しているサーバータイプに変更してからイメージ化する必要があります。

  • e-miniタイプをご利用の場合、イメージの取得には仮想サーバーの停止が必要です。その他、カスタマイズイメージの取得に時間もかかるため、採取タイミング等、別途運用設計をしてください。

  • イメージからのリストアは別仮想サーバーとして認識されるため、イメージからシステム復旧する場合は、業務アプリケーションが復旧可能かを別途確認してください。

【バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)】
  • バックアップ対象となる仮想サーバーから、グローバルに接続できる必要があります。

【バックアップ】
  • 定期バックアップルールの設定は必須となります。

  • リストアはバックアップからの新規サーバー作成となります。

  • リストア先のリージョン/ゾーンはバックアップ対象と同じリージョン/ゾーンに限定されます。

  • バックアップは失敗する可能性があります。

  • サーバーのローカルディスク(OS領域含む)及び、接続している増設ディスクの合計サイズに制限があります。

  • バックアップ対象サーバーの更新差分量によっては、バックアップ処理が失敗する場合があります。

  • 更新差分量によっては、バックアップ処理が失敗する場合があります。

  • バックアップ対象に設定したサーバーに対する操作は下記の制限があります。

    • ワンデイスナップショット機能:利用不可

    • サーバー削除:利用不可

    • 増設ディスク:操作不可

    • 以下の構成変更は可能だが、バックアップデータには反映されません  

      • ネットワーク構成、サーバータイプ

    • 利用リージョンの混雑状況により、希望の時間帯でバックアップ設定ができない場合があります

【その他】
  • システム要件によっては、ニフクラ以外環境(オンプレミス環境等)へバックアップデータ保存してください。

【ワンデイスナップショット】

作成後24時間経過または更新差分20GB超過時、自動削除

【バックアップ】
  • 保持世代数1~10世代

  • 1.1TB(ローカルディスク、増設ディスク合計)まで可能

  • バックアップ対象サーバーの更新差分量50GB以内(目安)

4.プライベート接続サービスの検討

本ドキュメントでは、「プライベートアクセス」「ダイレクトポート」の総称として「プライベート接続サービス」と表記しています。「プライベート接続サービス」という表現は、ニフクラ上での正式な呼称ではありませんので、注意してください。

プライベート接続サービスの検討
  • プライベート接続サービスを利用することで、ニフクラ以外の環境と接続することが可能です。ニフクラで提供されている機能だけではシステム構築の要件が満たせない場合に検討してください。

  • 接続先によって下記のような機能が実現可能です。

    • オンプレミス環境と構内接続・専用線・閉域網で接続

    • 他社のクラウドサービスと専用線・閉域網で接続

      • 他社クラウドサービスの機能を利用

プライベート接続サービス接続形態

各プライベート接続サービスの接続形態は下記のとおりとなります。

接続形態

提供範囲及び備考

プライベート接続機能

①プライベートアクセス

下表の各ネットワークとあらかじめ接続された環境を利用できる。

②ダイレクトポート

お客様の専用線・閉域網から接続することを目的に、ニフクラ環境と直接接続できる物理ポートを提供。
二口利用することで冗長化可能。[42]


42. ニフクラのデータセンターに入館できるのは回線事業者のみ。

①プライベートアクセス:ネットワーク提供事業者・サービス名

サービス名

ネットワーク

提供事業者

プライベートアクセス for ARTERIA

VECTANT クローズドIPネットワーク

アルテリア・ネットワークス

プライベートアクセス for クラウドゲートウェイ クロスコネクト

フレッツ・VPNワイド
フレッツ・VPNプライオ

NTT東日本

プライベートアクセス for SINET

学術情報ネットワーク(SINET5)

国立情報学研究所(NII)

プライベートアクセス for Equinix Cloud Exchange™ [43]


43. プライベートアクセス for Equinix Cloud Exchange™ はeast-2のみ利用可能です。

Equinix Cloud Exchange™

エクイニクス・ジャパン

プライベートアクセス for Digital enhanced EXchange(DEX)[44]


44. プライベートアクセス for Digital enhanced EXchange(DEX)はeast-1,east-4,jp-west-2のみ利用可能です。

DEXの閉域ネットワーク

富士通

プライベートアクセス プライベートアクセス for OPTAGE

VPNサービス・ネットワークエクスチェンジ

オプテージ

プライベート接続サービス概要図
  • 接続サービスを組み合わせて利用することも可能です。

  • リージョンによって利用可能なプライベート接続サービスは異なります。

image

5.Oracle製品利用パターン

Oracle製品の利用について

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

利用パターン

利用方法

ニフクラ環境(パターン1)
(ニフクラOVM利用)

ニフクラOVMでは、Oracle DatabaseライセンスのBYOL(Bring Your Own License)が可能な環境を利用します。Oracle Databaseライセンスを持ち込むことができる仮想サーバーを所定の方法で作成し、そのサーバーに Oracle Databaseをインストールして利用できます。ニフクラOVMは、パブリック等のニフクラ環境とは異なる仮想化基盤(Oracle VM)を用いて、構築・運用されています。
ニフクラOVMに関しての詳細は以下を参照してください。

アウトソーシング環境(パターン2)
(プライベートアクセス/ダイレクトポート利用)

アウトソーシング環境に設置したサーバーにOracle製品を導入して利用します。
(サーバーの調達、設置、構築、ニフクラとの接続作業などは全て利用者側での実施となります。)

ニフクラ環境(パターン1)

image

Oracle製品のライセンスやインストール作業は利用者にて手配

アウトソーシング環境(パターン2)

image

Oracle製品のライセンスやインストール作業は利用者にて手配
アウトソーシング環境の手配、ネットワーク設備・サーバーの設置、構築は利用者にて実施

6.FUJITSU Software Enterprise Postgres利用パターン

FUJITSU Software Enterprise Postgresの利用について

FUJITSU Software Enterprise Postgres(FEP)利用時の注意事項を記載しています。

No.

FUJITSU Software Enterprise Postgres利用時の注意事項 (抜粋)

1

本サービスでは、「FUJITSU Software Enterprise Postgres」で利用できるEnterprise Postgres Community Editionを提供していません。

2

DB二重化構成でのライセンスタイプの選び方について、初期構成時の主系(プライマリ)サーバーに「ACTIVE」を、従系(スタンバイ)サーバーに「STANDBY」をお選びください。 障害等でACTIVE / STANDBYが切り替わった場合については、連絡やライセンスの切り替えは不要です。

3

クラウド環境では共用ディスクを使用したクラスタシステムは対応していませんが、データベース多重化運用は利用可能です。

4

データベース(FUJITSU Software Enterprise Postgres)は、 ニフクラのサーバー(月額のみ) [45] とセットで提供となります。ライセンスのみを提供することはできません。サーバーやOSの費用は別途請求されます。詳細は 料金一覧を確認してください。


45. 月額のサーバーが作成可能です。従量のサーバーを選択した場合は、確認画面でエラーが表示されます。

5

データベース(FUJITSU Software Enterprise Postgres)のサポートを利用するためには、SupportDeskサービス管理者IDが必要になります。SupportDeskサービス管理者IDの新規申し込み後、データベース(FUJITSU Software Enterprise Postgres)のサポートの利用開始まで5営業日程度かかります。

6

DBサーバーとは別のサーバーにクライアントを導入して運用する場合、または、DB二重化構成でサーバーアシスタント(裁定サーバー)を構築する場合は、クライアント、サーバーアシスタントのISOをダウンロードして利用してください。クライアント及びサーバーアシスタントをインストールするサーバーに、データベース(FUJITSU Software Enterprise Postgres)のライセンスは不要です。

FUJITSU Software Enterprise Postgresの利用環境

該当サーバーのスペック(vCPU)に応じて、FEPライセンス数を計算して課金(顧客側でライセンス数の申告不要)

image

7.SAP製品利用パターン

SAP製品の利用について
  • SAP製品利用時の注意事項を記載しています。

    • ニフクラのSAP向けサービスを利用する際にはSAPコンサルタントやSAPコンピテンスセンターと連携してください

    • SAPS値についてはSAPコンピテンスセンターで計測済みですので、そちらに確認してください。

No.

SAP製品利用時の注意事項 (抜粋)

1

SAP製品を利用する場合は、新規にニフクラIDを取得する必要があります。ニフクラID取得前にまず問い合わせしてください。

2

SAP製品が利用可能なゾーンは、east-13、west-11となります。また、SAP Solution Managerからの情報取得が必要なため、ESXiとVMに下表のとおり設定を実施しています。

3

SAP製品利用をお申し込みされたIDでVMインポート、サーバーコピーなどを実施する場合、SAP Solution Managerからの情報取得のための設定が削除される場合がございますので、別途お問い合わせが必要になります。

4

ストレージとネットワークは論理分割された共有環境を使用します。

ESXi/VM設定項目

設定項目

設定値

ESXi設定

Misc.GuestLibAllowHostInfo

1

VM設定

tools.guestlib.enableHostInfo

true

SAP製品の利用環境

image

SAP製品のライセンスやインストール作業は利用者にて手配
コントロールパネル上は別のゾーンとして見える
ESXiとVMの一部設定が通常ゾーンとは異なる

8. GitLab製品利用パターン

GitLab製品の利用について

GitLab Enterprise Edition(GitLab EE)のサブスクリプション利用時の注意事項を記載しています。

No.

利用時の注意事項

1

ニフクラ環境専用のGitLab Enterprise Edition(GitLab EE)のサブスクリプションを提供します。提供サブスクリプションは下表のとおりです。
申請フォームからの申し込みによりGitLab EE サブスクリプションを購入可能です。
提供するサブスクリプションは、10ユーザー単位の年間サブスクリプションです。
本サービスの契約を更新することで、利用中のGitLab EE サブスクリプションの更新が可能です。

2

ニフクラからGitLab EE サブスクリプションを申し込む場合は、事前にニフクラIDを取得する必要があります。

3

サブスクリプションの利用先はニフクラ環境 [46] に限定されます。
ニフクラ環境上での利用を証明するため、お客様は当社の指示に従い、ニフクラでの利用の証跡を提示する義務があります。
ニフクラ環境以外で利用した場合、あらかじめ利用者に通知することなく、当社は本契約を中止することができます。また、上記原因で当社、及び他社に損害などを発生した場合、利用者に損害賠償を請求することができます。
GitLabサブスクリプションのみを利用する場合、またはニフクラ環境以外で利用予定の方は、ソリューションサービス GitLab EE ライセンス を申し込んでください。


46. ニフクラ環境:IaaS/PaaS/DevOps with GitLab/Hatoba/専有コンポーネント/プライベートリージョン/プライベートリソースを含みます。

4

本サービスで入手したサブスクリプションをニフクラ環境上で利用する場合に限り、ニフクラのサポート窓口を利用できます。
ニフクラ上で利用する場合、障害やトラブル時などの問い合わせはニフクラにて24時間365日可能ですが、対応時間は提供企業窓口に準じることとなるため、あらかじめ了承ください。

サブスクリプション

適用場面

Premium

複数プロジェクトの管理が必要な組織向け

Ultimate

複数プロジェクト管理に加え、セキュリティやコンプライアンス管理も重視する組織向け

GitLabの利用環境

image
※ GitLab EEのライセンスやインストール作業は利用者にて手配

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

0120-22-1200

0120-22-1200

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