本文へジャンプします。

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

2024年4月1日をもって、「ニフクラ」は、「FJcloud-V」に統合し、名称を変更しました。
「ニフクラ」「NIFCLOUD」「nifcloud」は、「FJcloud-V」に読み替えていただきますようお願いいたします。

ニフクラ ユーザーガイド

目次

はじめに

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

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

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

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

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

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

適用判断手順の概要

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

image

プライベートリージョン

プライベートリソース

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

サーバー専有

ストレージ専有

設置場所の選択

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

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

image

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

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

SLA/移行性

不適合条件

理由

SLA

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

ニフクラでは、仮想サーバー、ネットワークサービス等にSLAを設定しています。
それぞれのサービスで設定している稼働率は異なります。ニフクラで提供しているSLAの詳細は 「 品質保証制度(SLA)について 」 を参照してください。 [1]


1. 業務システムを含めたSLAについては、利用者側で検討が必要です。

移行性

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

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

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

VMwareでサポートされているOS以外をニフクラに移行できません。(VMwareでサポートされていてもニフクラに移行できるとは限りません)
ニフクラのVMインポート要件を満たさないものも移行できません。

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

VMインポートではOVA形式など、OVF+VMDK形式以外のイメージを移行できません。

動作環境/サポート

不適合条件

理由

選択値・条件

動作環境

物理機器の利用が必要

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

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

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

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

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


2. 時期によりインポート可能OSのバージョンが異なる可能性有

VMインポート検証済みOSを参照

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

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

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

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


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

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

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


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

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

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

サポート

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

  • ニフクラではOS層以上についてのサポートサービスを提供していません。これらのサポートサービスを必要とする場合、利用者は弊社以外からサービス提供を受ける必要があります。ニフクラ上でのサポートサービスを提供する別会社が存在しない場合、移行できません[5]

  • Windows Serverのサポートについては、富士通株式会社が提供する「サポート(富士通サポートデスク)」を利用の場合、サポート可能です。詳細は クラウド技術仕様/制限値(サポート(富士通サポートデスク)全般)を確認してください

  • Red Hat Enterprise Linux(サブスクリプション付き)の場合は、例外的にOSに関するサポートを一次受けします。[6]


5. ニフクラでは問い合わせ窓口をご用意していますが、回答時間や事象の解決は保証しておりません。
6. VMインポートにて持ち込んだサーバーはニフクラのサブスクリプション利用不可
7. 本サービス利用には、AUS専用のRed Hat Enterprise Linuxイメージで構築する必要があります。ニフクラ標準のRed Hat Enterprise Linuxイメージや外部からインポートしたRed Hat Enterprise Linuxイメージでは利用できません。また、AUSイメージで構築したサーバーをニフクラ標準サポートのRed Hat Enterprise Linuxに切り替えることはできません。
8. 問い合わせ窓口は、富士通のサポートデスクとなります。

2.ニフクラの適用判断

可用性

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

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

中項目

小項目

1.1

継続性

運用スケジュール

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

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

1.2

稼働率

  • 月間稼働率:仮想サーバー、ネットワークサービス等にSLAを設定しています。それぞれのサービスで設定している稼働率は異なりますので、詳細は「 品質保証制度(SLA)について 」を参照ください。

1.3

耐障害性

ネットワーク

  • ニフクラ内の構成は二重化構成、切り替わり時に通信断をともなう可能性あり。 [9]


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

1.4

ストレージ

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

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

1.5

災害対策(DR)

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

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

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

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

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

選択値・条件

中項目

小項目

2.1

リソース拡張性

vCPU

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

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

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

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

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


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

11. 一部ゾーンでは対応していないサーバータイプがあります。 ニフクラ ゾーン別機能対応表・サーバーを確認してください。

2.2

メモリ

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

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

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


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

13. 一部ゾーンでは対応していないサーバータイプがあります。 ニフクラ ゾーン別機能対応表・サーバーを確認してください。

2.3

ストレージ

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

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

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

2.4

スケールアップ

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

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


14. 新しいディスクは別領域となり、マウントの再定義やデータの移行作業、もしくはOS上での拡張設定等は利用者側での実施が必要

2.5

スケールアウト

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

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

2.6

性能品質保証

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

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

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

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

選択値・条件

中項目

小項目

3.1

通常運用

バックアップ

【カスタマイズイメージ】
  • バックアップ/リストア関連の機能は以下のとおり。

    • 仮想サーバーで利用するブロックストレージ(システム領域、増設ディスク)はカスタマイズイメージによるバックアップが可能。ただし、カスタマイズイメージ取得の制限サイズを超える領域は事前に切り離しておく必要があり、この切り離した領域のバックアップは別途検討が必要。

    • カスタマイズイメージ取得時は、仮想サーバーの停止を推奨。(仮想サーバー稼働中でもオンラインでのカスタマイズイメージの取得は可能だが、サーバー負荷状況等により中断する可能性あり。)

    • サーバータイプによってはイメージ化できないため対応するサーバータイプに変更後、イメージ化する必要あり。

    • リストア時は別サーバーとして起動される。サーバーの二重課金を避けるためには、元サーバーを削除しておく必要がある。

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

  • IPアドレスが変更になるので対処が必要。

【バックアップサービス】
  • バックアップ/リストア関連の機能は右記のとおり。

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

    • 利用中リージョンの混雑状況により、希望の時間帯でバックアップ設定をできない場合があるため注意。

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

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

【カスタマイズイメージ】
【バックアップサービス】

3.2

運用監視

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

    • 仮想サーバー、ロードバランサー(L4)、マルチロードバランサー、ストレージのリソースを自動的にモニタリングし、リソースごとに定義された監視項目についてモニタリングされたデータを取得。モニタリングデータはパフォーマンスチャートとして表示される。

  • 監視項目においてしきい値を超えた場合のメール通知設定。

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

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

3.3

保守運用

計画停止

  • 非活性メンテナンスの情報は、コントロールパネル内のお知らせ欄に掲載。緊急メンテナンス時は、掲載や告知がメンテナンスを実施する直前となることがある。コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知される。

  • 定期メンテナンス中はコントロールパネルとAPIが利用できない。利用者のサーバーは通常通り利用可能。障害時には、コントロールパネル内のお知らせ欄に情報が掲載される。こちらも、コントロールパネル内の「障害・お知らせ通知」でメールアドレスを登録すれば、メールでも通知される。

  • コントロールパネルにログインできない、またはサービスアクティビティを利用できない事象が発生している場合は、 ニフクラ 最新イベント/ニュース一覧にて障害の情報を確認可能。通知内容に応じて対応を検討する。

3.4

パッチ適用

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

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

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

3.5

運用環境

開発用環境の設置

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

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

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

3.6

試験用環境の設置

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

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

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

3.7

サポート体制

セキュリティ

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

選択値・条件

中項目

小項目

4.1

アクセス・利用制限

認証機能

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

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

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

4.2

利用制限

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

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

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


15. ニフクラID管理者はサービス契約時に作成される親アカウント(1つのみ)を指す。

4.3

データの秘匿

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

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

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

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

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

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

4.4

蓄積データ暗号化の有無

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

  • 暗号化が必要な場合はOS上で対処する必要あり(利用者にて実施)。

  • 一部ゾーンのローカルディスク及び増設ディスクでは筐体暗号化対応しています。 詳細は ニフクラ ゾーン別機能対応表 を確認してください。

4.5

不正追跡/監視

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

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

4.6

不正アクセス検知・監視

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

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

4.7

ネットワーク対策

ネットワーク制御

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

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

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

4.8

ネットワーク対策

セグメント分割

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

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

4.9

マルウェア対策

データセンター

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

選択値・条件

項目

5.1

第三者認証

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

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

5.2

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

  • 東日本リージョン、西日本リージョン、北米リージョン から選択可能

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

動作環境

No.

要件

ニフクラの仕様、利用者の対処、備考(影響など)

中項目

小項目

6.1

動作仕様

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

  • スタンダードイメージとして用意されているOSは ニフクラ サーバータイプ・仕様「OS(選択可能)」項目 の最新情報を確認してください。

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

  • OSイメージによって制限があるため注意。
    例:OSイメージによっては、一部のサーバータイプで利用できません。[16]

6.2

対応OS
(VMインポート)


17. これら以外のOSでも利用者責任でインポートを試すことは可能。動作保証等はできない。
18. Windowsのインポート可能OSは、ニフクラ提供側で動作確認がとれたバージョンを記載。記載のないOSについてもインポートできる可能性あり。

6.3

仮想サーバーのタイプ

  • 仮想サーバータイプは ニフクラ サーバータイプ・特徴「サーバータイプ一覧」 から選択可能。用途に合わせて複数のモデルを提供。
    ただしプラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動。
    作成可能ゾーンは ニフクラ ゾーン別機能対応表・サーバーを参照。

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

  • 仮想サーバータイプによって起動中に実施できる機能の制限がある。

    • 一部のサーバーではホットスケールアップや、サーバーを起動したままでのサーバーコピー[20]、カスタマイズイメージの作成[21]といった操作ができません。[22]

6.4

VMware Toolsのバージョン

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

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

  • 必須バージョンやその他注意事項等の詳細は こちら を参照。

6.5

ストレージ容量

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

6.6

ネットワーク接続形態

  • コントロールパネルへは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 VE2Vシリーズ)の利用を検討。

8.2

システム連携

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

  • 連携の仕組みを実装。

9.1

移行

移行方法

  • オンプレミス仮想環境上のゲストOSの移行については、VMインポートの利用が可能。移行可能なOSは、VMインポート・仕様 にて確認が必要。

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

  • VMインポートの利用を検討する場合、VMインポート・仕様にて前提条件等の確認が必要。

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

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

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

image

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

システムパターンの検討

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

災害対策(地理的冗長)

ゾーン規模障害対策

仮想サーバーSLA対象※1

許容可能
停止時間※2

代表的システム

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

対象

無停止~数分

重要
基幹システム [23]


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

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

不要

対象

無停止~数分

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

不要

対象

無停止~数時間

基幹システム [24]


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

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

不要

対象

数日程度

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


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

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

※1
ニフクラでは、仮想サーバー、ネットワークサービス等にSLAを設定しています。 それぞれのサービスで設定している稼働率は異なりますので、詳細は、品質保証制度(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をゾーン間接続し、マルチゾーンの冗長化を組みます。
      利用者自身で設計・構築する必要があります。 [26]

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

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

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

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

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

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

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

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


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

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

No.

適用システムパターン

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

2

image

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

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

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

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

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

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

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

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

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

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


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

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

No.

適用システムパターン

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

3

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

No.

適用システムパターン

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

4

image

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

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

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

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

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

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

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

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

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

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


34. シングルゾーンの場合、マルチロードバランサー、L7ロードバランサー(Ivanti Virtual Traffic Manager)、統合ネットワークサービス(IPCOM VE2Vシリーズ)でも構築可能です。
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

リージョン監視

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


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

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

6

バックアップ

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

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

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

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

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

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

  • カスタマイズイメージ取得可能 [36]


36. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。
ゾーン間通信障害対策

ゾーン規模で障害が発生した場合を想定したゾーン間通信障害対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

7

ゾーン間通信

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

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


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

ゾーン規模で障害が発生した場合を想定したゾーン規模障害対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

8

仮想サーバー

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

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

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

  • カスタマイズイメージ取得可能 [38]


38. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。

9

業務データ

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

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

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

10

ロードバランサー(L4)

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

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

ロードバランサー(L4)の詳細は、 クラウド技術仕様/制限値(ロードバランサー(L4))を確認してください。

11

データベースサーバー

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

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

監視とバックアップ

ゾーン規模で障害が発生した場合を想定した監視とバックアップの主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

12

ゾーン監視

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


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

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

13

バックアップ

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

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

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

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

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

カスタマイズイメージ取得可能 [40]


40. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。
メンテナンス時の対策

メンテナンス時を想定した対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

14

物理サーバー

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

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

15

ネットワークノード

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

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

16

ストレージノード

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

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

17

仮想サーバー

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

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

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

クラウド基盤障害対策

クラウド基盤で障害が発生した場合を想定した主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

18

物理サーバー

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

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

19

ネットワーク機器

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

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

20

ストレージ機器

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

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

21

仮想サーバー

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

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

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

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

image

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

リージョン規模/ゾーン規模で障害が発生した場合を想定した障害対策(災害対策)の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

1

リージョン障害

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

2

ゾーン間通信

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

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


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

ゾーン規模で障害が発生した場合を想定したゾーン規模障害対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時のポイント

選択値・条件

3

仮想サーバー

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

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

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

  • カスタマイズイメージ取得可能 [42]


42. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。

4

業務データ

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

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

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

5

ロードバランサー(L4)

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

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

ロードバランサー(L4)の詳細は、 クラウド技術仕様/制限値(ロードバランサー(L4))を確認してください。

6

データベースサーバー

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

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

監視とバックアップ

ゾーン規模で障害が発生した場合を想定した監視とバックアップの主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

7

ゾーン監視

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


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

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

8

バックアップ

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

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

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

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

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

カスタマイズイメージ取得可能 [44]


44. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。
メンテナンス時の対策

メンテナンス時を想定した対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

9

物理サーバー

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

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

10

ネットワークノード

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

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

11

ストレージノード

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

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

12

仮想サーバー

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

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

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

クラウド基盤障害対策

クラウド基盤で障害が発生した場合を想定した主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

13

物理サーバー

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

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

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サービスの「フェイルオーバー」機能を利用することで、リージョン障害が起こっても別リージョンで業務継続可能となります。

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

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

5

リージョン監視

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


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

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

6

バックアップ

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

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

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

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

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

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

  • カスタマイズイメージ取得可能 [46]


46. カスタマイズイメージの仕様については クラウド技術仕様/制限値(コンピューティング:カスタマイズイメージ/イメージ配布)を確認してください。
ゾーン規模障害対策

ゾーン規模で障害が発生した場合を想定したゾーン規模障害対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

7

ゾーン障害

ゾーン規模障害対策

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

メンテナンス時の対策

メンテナンス時を想定した対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

8

物理サーバー

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

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

9

ネットワークノード

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

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

10

ストレージノード

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

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

11

仮想サーバー

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

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

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

クラウド基盤障害対策

クラウド基盤で障害が発生した場合を想定した主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

12

物理サーバー

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

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

13

ネットワーク機器

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

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

14

ストレージ機器

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

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

15

仮想サーバー

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

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

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

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

image

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

リージョン規模/ゾーン規模で障害が発生した場合を想定した障害対策(災害対策)の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

1

リージョン障害

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

2

ゾーン障害

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

メンテナンス時の対策

メンテナンス時を想定した対策の主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

3

物理サーバー

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

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

4

ネットワークノード

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

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

5

ストレージノード

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

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

6

仮想サーバー

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

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

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

クラウド基盤障害対策

クラウド基盤で障害が発生した場合を想定した主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

7

物理サーバー

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

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

8

ネットワーク機器

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

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

9

ストレージ機器

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

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

10

仮想サーバー

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

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

監視とバックアップ

クラウド基盤で障害が発生した場合を想定した監視とバックアップの主要検討事項を以下に記載します。

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

11

監視

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

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

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

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

12

バックアップ

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

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

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

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

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

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

ニフクラ外にバックアップできます。

【バックアップ】

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

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

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

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

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

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

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

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

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

  • バックアップは失敗する可能性があります。失敗した場合メールで通知されます。

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

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

  • 更新差分量によっては、バックアップ処理失敗の可能性があります。

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

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

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

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

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

ワンデイスナップショットの仕様詳細は、 クラウド技術仕様/制限値(コンピューティング:ワンデイスナップショット))を確認してください。

【バックアップ】

バックアップサービスの仕様詳細は クラウド技術仕様/制限値(コンピューティング:バックアップ)を確認してください。

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

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

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

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

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

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

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

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

接続形態

提供範囲及び備考

①プライベートアクセス

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

②ダイレクトポート

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

③物理ポート(コロケーションプラン)

当社の指定するデータセンターにおいて、コロケーションスペース(当社手配)に通信キャリアの回線(利用者手配)と 通信キャリアのネットワーク機器(利用者手配)を設置し、当社のネットワーク機器に通信キャリアのネットワーク機器を接続するプラン。
デュアル接続を利用することで冗長化可能。

④物理ポート(構内接続プラン)

当社の指定するデータセンターにおいて、当社のネットワーク機器に構内配線(利用者手配)を接続するプラン。
デュアル接続を利用することで冗長化可能。

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

サービス名

ネットワーク

提供事業者

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

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

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

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

フレッツ・VPN ワイド
フレッツ・VPN プライオ
Managed SD-WAN

NTT東日本

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

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

国立情報学研究所(NII)

プライベートアクセス for Equinix Fabric™

Equinix Fabric™

エクイニクス・ジャパン

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

DEXの閉域ネットワーク

富士通

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

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

オプテージ

※提供しているリージョンを限定しているサービスがあります。詳細は ニフクラ ゾーン別機能対応表 を確認してください。

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

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

image

5.Oracle製品利用パターン

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

利用パターン

利用方法

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

ニフクラOVMでは、Oracle DatabaseライセンスのBYOL(Bring Your Own License)が可能な環境を提供します。ニフクラOVMは、パブリック等のニフクラ環境とは異なる仮想化基盤(OracleVM/Oracle Linux Virtualization)を用いて、構築・運用されています。ニフクラOVMに関しての詳細は以下を参照してください。
クラウド技術仕様/制限値(OVM:構成の内容)

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

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

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

image

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

image

6.SAP製品利用パターン

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

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

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

No.

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

1

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

2

SAP製品が利用可能なゾーンの詳細は ニフクラ ゾーン別機能対応表:ライセンス利用・管理 を確認してください。また、SAP Solution Managerからの情報取得が必要なため、ESXiとVMに下表のとおり設定を実施しています。

3

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

  • ESXi/VM設定項目

設定項目

設定値

ESXi設定

Misc.GuestLibAllowHostInfo

1

VM設定

tools.guestlib.enableHostInfo

true

SAP製品の利用環境

image

7. GitLab製品利用パターン

GitLab製品の利用について

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

No.

利用時の注意事項

1

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

2

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

3

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


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

4

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

サブスクリプション

適用場面

Premium

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

Ultimate

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

GitLabの利用環境

image

  • ※本ページ記載の金額は、すべて税抜表示です。
  • ※本ページ記載の他社製品名および会社名などは、各社の商標または登録商標です。
  • ※本ページの内容は、2024年5月08日時点の情報です。

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