本文へジャンプします。

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

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

ニフクラ ユーザーガイド

目次

はじめに

  • 本ユーザーガイドはIaaS活用ガイドです。

  • 当サービスはサーバーやネットワークなど、提供されている機能をインターネット経由で利用するクラウドサービスです。

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

  • システム要件によっては当サービスを適用できない、または移行できない場合があります。本ユーザーガイドを最後まで確認し、適用可否を判断してください。

  • 本ユーザーガイドの記載内容は、特に断りがない限り「共有型の仮想サーバー環境」について記載しています。

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

  • 当サービスの最新情報や変更点は、最新のドキュメントを参照してください。

適用判断手順の概要

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

image

サーバー提供タイプ

プライベートリージョン

プライベートリソース

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

サーバー専有

ストレージ専有

設置場所の選択

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

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

image

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

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

SLA/移行性

不適合条件

理由

SLA

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

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


1. 業務システムを含めたSLAは、利用者側で検討してください。

移行性

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

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

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

VMwareでサポートされているOS以外を当サービスに移行できません。なお、VMwareでサポートされていても当サービスに移行できるとは限りません。
当サービスのVMインポート要件を満たさない場合も移行できません。

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

VMインポートではOVA形式など、OVF+VMDK形式以外のイメージを移行できません。
VMイメージの作成、OVFへの変更方法など以下を参照してください。
VMイメージの作成方法
ディスクイメージからovfファイルへの変換

動作環境/サポート

不適合条件

理由

選択値・条件

動作環境

物理機器の利用が必要

物理機器は当サービスで利用できません。

  • プリンタ

  • FAX

  • スキャナ

  • テープデバイス 等

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

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

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

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


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

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

ミドルウェアの動作保証が必要 [3]


3. ミドルウェアの製品指定がある商談など

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

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

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


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

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

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


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

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

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

サポート

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

  • 当サービスではOS層以上のサポートサービスは提供していません。
    これらのサポートサービスが必要な利用者は、弊社以外からサービス提供を受けてください。
    当サービス上でのサポートサービスを提供する別会社が存在しない場合、移行できません。[6]

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

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

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


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

2.ニフクラの適用判断

可用性

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

No.

要件

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

中項目

小項目

1.1

継続性

運用スケジュール

  • 以下例外を除き24時間365日無停止
    例外の影響は、No.3.3を参照

    • 計画停止

    • 定期保守

    • 即時対応

1.2

稼働率

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

1.3

耐障害性

ネットワーク

  • 当サービス内の構成は二重化構成である。ただし、切り替わり時には通信断をともなう可能性がある。 [10]


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

1.4

ストレージ

  • ストレージ機器は冗長構成である。ただし、切り替わり時に通信断、I/O遅延または断をともなう可能性がある。

1.5

災害対策(DR)

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

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

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

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

No.

要件

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

選択値・条件

中項目

小項目

2.1

リソース拡張性

vCPU

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

    • vCPU性能:仮想サーバータイプの変更で、性能の異なるvCPUを選択できる。

    • vCPU数:仮想サーバータイプの変更で、システム要件にあったvCPU数を持つタイプを選択できる。[11]

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

  • 仮想サーバータイプの変更に伴い、再起動が発生する。


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

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

2.2

メモリ

  • 仮想サーバーのメモリ量は右記のとおり。

    • メモリ容量:仮想サーバータイプの変更で、システム要件にあったメモリ容量を持つタイプを選択できる。[13]

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

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


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

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

2.3

ストレージ

  • 仮想サーバーのシステム領域は、固定。

  • 増設ディスクはタイプ、容量を設定し新規に作成できる。

    • ディスク性能:ディスクタイプを選択し、性能の異なるディスクを作成できる。

    • ディスク容量:ディスク容量を設定し、システム要件にあったディスク容量を持つ増設ディスクを作成できる。

  • 仮想サーバーへアタッチ済みの増設ディスクは、容量を拡張できる。

  • 仮想サーバー起動状態で、増設ディスクのアタッチ、デタッチができる。

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

2.4

スケールアップ

  • vCUPおよびメモリは、仮想サーバータイプの変更でスケールアップできる(No.2.1, No.2.2)。
    ストレージ容量は、増設ディスク容量の拡張/追加でスケールアップできる。(No.2.3) [15]

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

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

    • 再起動時は、その仮想サーバーで稼働中の業務アプリケーションは中断または停止される。

    • 仮想サーバーが起動状態になった後、アプリケーションの稼働状況を必ず確認する。

  • 増設ディスクの容量/アタッチ数を増やす。


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

2.5

スケールアウト

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

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

2.6

性能品質保証

  • vCPU、メモリは仮想サーバータイプに基づくスペックが割り当てられる。

    • プラットフォーム全体の利用状況に応じて、仮想サーバーの性能は変動する。

  • ストレージ、ネットワークも共用型となりベストエフォートでの提供となる。

  • 性能向上のために、スケールアップ、スケールアウト、またはアプリケーションチューニングを実施する。

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

No.

要件

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

選択値・条件

中項目

小項目

3.1

通常運用

バックアップ

カスタマイズイメージ
  • 仮想サーバーで利用するローカルディスクおよび増設ディスクをバックアップできる。
    ただし、カスタマイズイメージ取得時の制限サイズを超える領域は事前に切り離す必要がある。この切り離した領域のバックアップは別途検討する。

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

  • 一部のサーバータイプではイメージ化できないため、対応するサーバータイプに変更後、イメージ化を実施する。

  • リストア時は別サーバーとして起動される。サーバーの二重課金を避けるには、元サーバーを削除する。

  • DHCPで配布されたIPアドレスは変更になることが予想されるため、事前に付替IPを用意する等の対策を実施する。

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

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

  • リストア時は別サーバーとして起動される。
    また、DHCPで配布された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アドレスは、許可する範囲を指定できる。

    • 誤ったアクセス元IPアドレスを登録すると、コントロールパネルやAPIにアクセスできなくなる。
      その際は、当サービスのサポート窓口に連絡して、アクセス元IPアドレス制限の設定解除を依頼する。

4.2

利用制限

  • ユーザーID管理者[16]と、操作範囲を制限するための権限を提供する。

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

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


16. ユーザー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側の拒否ログのみ出力される。

    • 通信方向

    • 通信相手

    • プロトコル情報

  • 以下に対して、ルールを適用できる。

    • 対象の仮想サーバー

    • 仮想ルーター

    • 拠点間VPNゲートウェイ

上記の当サービス機能以外の対処方法として、Windowsファイアウォールや、IISなどのWebサーバー機能を用いてクライアント制限・認証の組込みもできる。

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

4.8

ネットワーク対策

セグメント分割

  • プライベートLANを作成し、サブネットの設定ができる。

  • 利用者側でネットワークの設計・構築を実施する。

4.9

マルウェア対策

  • オプションサービスとして、「Trend Micro Cloud One - Workload Security」を提供する。

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

データセンター

No.

要件

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

選択値・条件

項目

5.1

第三者認証

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

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

5.2

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

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

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

動作環境

No.

要件

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

中項目

小項目

6.1

動作仕様

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

6.2

対応OS
(VMインポート)


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

6.3

仮想サーバーのタイプ

  • 仮想サーバータイプは サーバータイプ「サーバータイプ一覧」から選択できる。

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

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

    例:一部のサーバーでは以下の操作ができない。

    • ホットスケールアップ[21]

    • サーバーを起動したままでのサーバーコピー[22]

    • カスタマイズイメージの作成[23]


21. 現在ホットスケールアップの機能は利用できません サーバータイプ・注意事項を参照

6.4

VMware Toolsのバージョン

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

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

  • 必須バージョンやその他注意事項等の詳細は クラウド技術仕様/制限値(コンピューティング:VMware Tools/open-vm-tools) を参照する。

6.5

ストレージ容量

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

6.6

ネットワーク接続形態

  • コントロールパネルへはHTTPSで接続する。

  • 仮想サーバーなどへは以下の接続が利用できる。

    • IPsec VPN接続

      • 当サービスとオンプレミス環境を拠点間VPNのIPsec VPNで接続する際は、オンプレミス環境にVPNルーターを用意する。

    • SSL-VPN接続

      • 当サービスと利用者端末をリモートアクセスVPNゲートウェイのSSL-VPNで接続する際は、利用者端末にクライアントアプリケーションをインストールする。

    • インターネット接続

  • 利用者のデータセンターと当サービスとは、専用線/閉域網を経由するプライベート接続も利用できる。

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

No.

要件

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

大項目

中項目

小項目

7.1

サービス利用

稼働状況報告

  • 利用者に対し、稼働状況の個別の報告はしない。

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

8.1

システム特性

負荷分散への対応

  • 外部/内部通信ともに負荷分散できる。

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

    • ロードバランサー(L4)は、ゾーンを跨いだ負荷分散が可能。

    • マルチロードバランサーは、内部通信の負荷分散が可能。

    • 高機能ロードバランサーが必要な際は、L7ロードバランサー(Ivanti Virtual Traffic Manager)または統合ネットワークサービス(IPCOM VE2Vシリーズ)の利用を検討。

8.2

システム連携

  • 拠点間VPNゲートウェイのIPsec VPNを用いてインターネット経由で、オンプレミス環境やリージョン間の連携ができる。
    プライベート接続サービスを用いて専用線/閉域網経由で、オンプレミス環境やリージョン間の連携ができる。

  • 連携の仕組みを実装する。

9.1

移行

移行方法

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

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

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

image

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

システムパターンの検討

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

災害対策(地理的冗長)

ゾーン規模障害対策

仮想サーバーSLA対象※1

許容可能
停止時間※2

代表的システム

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

対象

無停止~数分

重要
基幹システム [24]


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

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

不要

対象

無停止~数分

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

不要

対象

無停止~数時間

基幹システム [25]


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

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

不要

対象

数日程度

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


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

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

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

システムパターン比較表

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

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

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

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

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

構成要素

image

image

image

image

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

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

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

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

リージョン障害対策

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

なし

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

なし

ゾーン障害対策

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

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

なし

なし

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

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

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

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

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)をシングルゾーン負荷分散構成で構築します。
      フロントエンドシステムは構築したロードバランサー(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)、統合ネットワークサービス(IPCOM VE2Vシリーズ)でも構築可能です。
No.1 マルチリージョン・マルチゾーン

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

image

リージョン障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

1

リージョン間接続

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

  • 各リージョンでIP重複に留意して、ネットワーク構成を設計してください。

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

2

仮想サーバー

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

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

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

3

業務データ

当サービスでは、リージョン間で業務データをデータ同期するサービスが提供されていません。
復旧時間を短縮するには、利用者にてリージョン間でデータ同期の仕組みを構築してください。

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

4

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

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

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

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

監視とバックアップ

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

5

リージョン監視

リージョン障害を検知するには、監視対象リージョン以外の別リージョンやオンプレミス環境等から監視してください。 [36]


36. 障害対象リージョンに監視サーバーが配備されていると、通信不可となり監視できません。
  • 当サービスの基本監視サービスはクラウド基盤からのリソース監視のみです。
    OS層以上を監視するには、別途有人監視サービスを利用するか、監視サーバーを構築してください。

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

6

バックアップ

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

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

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

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

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

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

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

ゾーン間通信障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

7

ゾーン間通信

ゾーン間の通信には、プライベートブリッジを配備してください。

  • ゾーン障害時に業務データのデータベース等のスプリット・ブレインを回避するには、アプリケーション部分について、利用者にて別途設計してください。 [38]


38. スプリット・ブレインの原因と対策例:ハートビート通信するネットワークに断線などの問題が発生すると、ホストに障害が発生したと誤認し、本来立ち上がるべきではないStandby側のホストがActiveになります。そのため、ゾーン間で障害監視するとともに、他リージョンやオンプレミス環境等の別環境からも障害監視を実施してください。
ゾーン規模障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

8

仮想サーバー

ゾーン間はActive/Active構成とするため、それぞれのゾーンに同一構成で仮想サーバーを構築してください。
制限サイズ内の仮想サーバーであれば、イメージ化できるため、同一イメージを使った仮想サーバーの構築により、構築作業を短縮できます。
また、ロードバランサー(L4)における、負荷分散対象サーバーを容易に作成できます。

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

  • 設定変更等をイメージに反映させるには、イメージを再取得してください。

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

9

業務データ

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

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

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

10

ロードバランサー(L4)

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

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

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

11

データベースサーバー

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

  • 利用者側でデータベースを新規に構築し、データ同期や切り替えの仕組みを、利用者にて別途設計・構築してください。

監視とバックアップ

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

12

ゾーン監視

ゾーン障害を検知するには、対象ゾーン以外の別ゾーン、オンプレミス環境等から監視してください。[40]


40. 障害対象ゾーンに監視サーバーが配備されていると、通信不可となり監視できません。
  • 当サービスの基本監視サービスはクラウド基盤からのリソース監視のみです。
    OS層以上を監視するには、別途有人監視サービスを利用するか、監視サーバーを構築してください。

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

13

バックアップ

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

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

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

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

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

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

メンテナンス時の対策

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

No.

検討事項

検討内容

検討時の重点ポイント

14

物理サーバー

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

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

15

ネットワークノード

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

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

16

ストレージノード

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

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

17

仮想サーバー

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

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

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

クラウド基盤障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

18

物理サーバー

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

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

19

ネットワーク機器

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

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

20

ストレージ機器

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

  • 障害時間が許容範囲を超える際は、リージョン切替、ゾーン切替を検討してください。

21

仮想サーバー

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

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

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

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

image

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

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

No.

検討事項

検討内容

検討時の重点ポイント

1

リージョン障害

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

2

ゾーン間通信

ゾーン間の通信には、プライベートブリッジを配備してください。

  • ゾーン障害時に業務データのデータベース等のスプリット・ブレインを回避するには、アプリケーション部分について、利用者にて別途設計してください。 [42]


42. スプリット・ブレインの原因と対策例:ハートビート通信するネットワークに断線などの問題が発生すると、ホストに障害が発生したと誤認し、本来立ち上がるべきではないStandby側のホストがActiveになります。そのため、ゾーン間で障害監視するとともに、他リージョンやオンプレミス環境等の別環境からも障害監視を実施してください。
ゾーン規模障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

3

仮想サーバー

ゾーン間はActive/Active構成とするため、それぞれのゾーンに同一構成で仮想サーバーを構築してください。
制限サイズ内の仮想サーバーであれば、イメージ化できるため、同一イメージを使った仮想サーバーの構築により、構築作業を短縮できます。
また、ロードバランサー(L4)における、負荷分散対象サーバーを容易に作成できます。

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

  • 設定変更等をイメージに反映させるには、イメージを再取得してください。

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

4

業務データ

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

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

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

5

ロードバランサー(L4)

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

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

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

6

データベースサーバー

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

  • 利用者側でデータベースを新規に構築し、データ同期や切り替えの仕組みを、利用者にて別途設計・構築してください。

監視とバックアップ

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

7

ゾーン監視

ゾーン障害を検知するには、対象ゾーン以外の別ゾーン、オンプレミス環境等から監視してください。[44]


44. 障害対象ゾーンに監視サーバーが配備されていると、通信不可となり監視できません。
  • 当サービスの基本監視サービスはクラウド基盤からのリソース監視のみです。
    OS層以上を監視するには、別途有人監視サービスを利用するか、監視サーバーを構築してください。

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

8

バックアップ

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

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

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

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

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

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

メンテナンス時の対策

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

No.

検討事項

検討内容

検討時の重点ポイント

9

物理サーバー

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

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

10

ネットワークノード

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

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

11

ストレージノード

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

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

12

仮想サーバー

当サービス上に構築したシステムも、ネットワークノードやコントローラ切替にともなう、瞬間的な通信断、I/O遅延または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サービスの「DNSゾーン管理」「レコード管理」機能を利用して、ロードバランサー(L4)のIPアドレスを登録します。
複数リージョンでActive/Active構成のシステムを構築し、DNSサービスの「フェイルオーバー」機能を利用してください。リージョン障害発生時でも、別リージョンでの業務継続を実現します。

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

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

5

リージョン監視

リージョン障害を検知するには、監視対象リージョン以外の別リージョンやオンプレミス環境等から監視してください。[46]


46. 障害対象リージョンに監視サーバーが配備されていると、通信不可となり監視できません。
  • 当サービスの基本監視サービスはクラウド基盤からのリソース監視のみです。
    OS層以上を監視するには、別途有人監視サービスを利用するか、監視サーバーを構築してください。

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

6

バックアップ

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

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

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

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

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

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

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

ゾーン規模障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

7

ゾーン障害

ゾーン規模障害対策

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

メンテナンス時の対策

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

No.

検討事項

検討内容

検討時の重点ポイント

8

物理サーバー

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

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

9

ネットワークノード

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

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

10

ストレージノード

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

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

11

仮想サーバー

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

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

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

クラウド基盤障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

12

物理サーバー

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

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

13

ネットワーク機器

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

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

14

ストレージ機器

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

  • 障害時間が許容範囲を超える際は、リージョン切替、ゾーン切替を検討してください。

15

仮想サーバー

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

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

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

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

image

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

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

No.

検討事項

検討内容

検討時の重点ポイント

1

リージョン障害

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

2

ゾーン障害

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

メンテナンス時の対策

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

No.

検討事項

検討内容

検討時の重点ポイント

3

物理サーバー

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

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

4

ネットワークノード

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

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

5

ストレージノード

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

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

6

仮想サーバー

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

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

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

クラウド基盤障害対策

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

No.

検討事項

検討内容

検討時の重点ポイント

7

物理サーバー

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

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

8

ネットワーク機器

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

  • 障害時間が許容範囲を超える際は、リージョン切替、ゾーン切替を検討してください。

9

ストレージ機器

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

  • 障害時間が許容範囲を超える際は、リージョン切替、ゾーン切替を検討してください。

10

仮想サーバー

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

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

監視とバックアップ

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

No.

検討事項

検討内容

検討時の重点ポイント

選択値・条件

11

監視

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

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

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

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

12

バックアップ

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

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

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

カスタマイズイメージ

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

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

当サービス以外にバックアップ可能です。

バックアップ

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

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

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

カスタマイズイメージ
  • カスタマイズイメージを取得する際、制限サイズを超えるディスク領域を、一度切り離してください。
    また、サーバータイプによってはそのままイメージ化できないため、対応しているサーバータイプへ変更後、イメージ化してください。

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

バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)
  • バックアップ対象となる仮想サーバーから、グローバルに接続できる状態にしてください。

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

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

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

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

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

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

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

その他
  • システム要件によっては、オンプレミス等の当サービス以外の環境へバックアップデータを保存してください。

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

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

バックアップ

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

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

  • プライベート接続サービスを利用すれば、当サービス以外の環境と接続できます。当サービスの提供機能だけではシステム構築の要件が満たせない際に、本サービスを検討してください。

  • 接続先により、下記の機能を実現できます。

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

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

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

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

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

接続形態

提供範囲及び備考

①プライベートアクセス

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

②ダイレクトポート

利用者の専用線・閉域網からの接続を目的に、当サービス環境と直接接続できる物理ポートを提供します。
二口の利用で冗長化できます。[48]


48. 回線事業者のサービスにより冗長化の可否が異なるため、利用者にて回線事業者へ問い合わせてください。

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

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

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

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


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

サービス名

ネットワーク

提供事業者

プライベートアクセス 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

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


49. 当サービス:IaaS/PaaS/DevOps with GitLab/専有コンポーネント/プライベートリージョン/プライベートリソースを含みます。

4

本サービスで入手したサブスクリプションをニフクラ環境上で利用する場合に限り、ニフクラのサポート窓口を利用できます。
当サービス上で利用する際は、障害やトラブル時などの問い合わせは、当サービスにて24時間365日受け付けますが、対応時間は提供企業窓口に準じます。


サブスクリプション

適用場面

Premium

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

Ultimate

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

GitLabの利用環境

image



フィードバック

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

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

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