はじめに
-
本ドキュメントの目的
-
要件定義/システム設計・構築をする際のナレッジの中でも、利用者がつまずきやすいポイントやありがちな失敗に絞って記載します。
※利用者がニフクラ上でシステム設計/構築する際のポイントです。サービスを提供する基盤や提供事業者が作業する内容は含みません。
-
ニフクラ全般編
-
ニフクラの各種サービスに限らない、ニフクラ全般の内容を記載します。
リージョン/ゾーンごとの機能差について
- つまずきやすいポイント/ありがちな失敗例
-
-
構築作業を開始したが、後になって、利用を想定していたサービスが使えないリージョン/ゾーンで作業していたことに気づいた。既に一部リソースは作成済みであったため、課金が発生してしまった。
-
- 仕様/対策
-
-
各リージョン/ゾーンは、新規構築やリプレースタイミングの影響で、利用時期によって機能差が生じます。詳細は、ゾーン別機能対応表を確認してください。
-
プライベートブリッジを利用したネットワーク延伸により、リージョン/ゾーン間の機能差を吸収可能です。
-
ニフクラサービス編
-
ニフクラの各種提供サービスについて、つまずきやすいポイントやありがちな失敗を記載します。
ファイアウォール設定について
- つまずきやすいポイント/ありがちな失敗例
-
-
以下の状態でサーバーを作成してしまい、サーバーが不正アクセスを受けた。
-
グローバルIPアドレスを付与
-
ファイアウォールを付与せず作成
-
ファイアウォールは作成したが、初期構築時にanyのIPアドレス:ポートからアクセスを許可したルールを付与
-
-
- 仕様/対策
-
-
ニフクラは、サーバー作成時にグローバルIPアドレスを付与すると、作成後直ちにインターネットに接続されます。
サーバー作成時には、必ずファイアウォールを設定してください。また、適宜要件に応じたルールを設定してください。-
ニフクラファイアウォールのルールは クラウド技術仕様/制限値(コンピューティング:ファイアウォール:ルール) を参照してください。
-
-
インターネットに接続する必要のないサーバーは、グローバル側のインターフェースを利用しないでください。
-
- つまずきやすいポイント/ありがちな失敗例
-
-
ファイアウォールの設定を間違えて、実施したい通信が通らない。
-
- 仕様/対策
-
-
ネットワーク不通などのトラブルは、ニフクラファイアウォール設定が影響している可能性があります。
コントロールパネル上より、ファイアウォールグループのログを参照して、ニフクラファイアウォールによって遮断された通信を確認してください。
-
ニフクラバックアップについて
- つまずきやすいポイント/ありがちな失敗例
-
-
設計した時間帯でニフクラバックアップを設定したところ、該当時間帯で設定できず、トラブルになった。
-
日次の更新差分が大きいサーバーに、ニフクラバックアップを設定したところ、日次のバックアップに失敗し続け、バックアップが取得できない状態になった。
-
- 仕様/対策
-
-
ニフクラのバックアップ機能の制限
-
ニフクラのバックアップ機能は、時間枠ごとに設定数の上限が決められており、希望の時間帯でバックアップ定義を設定できない場合があります。
-
本仕様は、不特定多数の利用者による負荷集中をさけ、基盤を安定稼働させるためにもうけられています。
-
-
バックアップ対象サーバーの更新差分量に目安があります。更新差分量によっては、バックアップ処理が失敗する場合があります。詳細は クラウド技術仕様/制限値(コンピューティング:バックアップ) を参照してください。
-
対策
-
バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)の活用
-
クラウドユーザーガイド(コンピューティング:バックアップ関連サービス比較) を参考に、他のバックアップ方式を検討する。
-
-
-
拠点間VPNゲートウェイを利用した接続性について
- つまずきやすいポイント/ありがちな失敗例
-
-
拠点間VPNゲートウェイを利用して、利用者拠点とIPsecでVPN接続したが、VPNの接続が安定しない。
-
- 仕様/対策
-
-
VPN接続及び、VPN接続後のrekeyを一方に固定化すると、相互接続性が向上する可能性があります。
-
拠点間VPNゲートウェイの VPNコネクションに設定 する「IKE lifetime」の設定や、拠点側機器のLifetimeを調整してください。
-
利用者作業範囲(OS等)編
-
ニフクラ利用時の利用者作業範囲について、つまずきやすいポイントやありがちな失敗を記載します。
-
利用者作業範囲、クラウドサービス事業者の責任範囲は ニフクラでのセキュリティの考え方 を参照してください。
-
ディスク障害について
- つまずきやすいポイント/ありがちな失敗例
-
-
ニフクラでディスク障害が発生した後、復旧報が届いたが構築したサーバーのディスクが復旧していない。
-
- 仕様/対策
-
-
サーバーのローカルディスク、増設ディスク障害時、利用者でその後の対処が必要な場合があります。
-
障害・お知らせ通知で復旧報が届いた後、サーバーの状態を確認してください。
-
サーバーの状態確認で、リードオンリーとなっているか、なっていた場合の対処は、クラウドユーザーガイド(コンピューティング:ディスクがリードオンリーになった場合の対応手順)を確認して対応してください。
-
リードオンリーになっている可能性が高い利用者には、復旧報とは別に通知することがあります。
-
-
SSHキーファイルについて
- つまずきやすいポイント/ありがちな失敗例
-
-
サーバー作成時に指定したSSHキーファイルを紛失してしまい、サーバーにログインできなくなった。
-
- 仕様/対策
-
-
Linux系OSで仮想サーバーを作成した際に指定したSSHキーファイルは 再ダウンロードできません、大切に保存し 紛失や誤って削除しない よう注意してください。また、仮想サーバー内に生成されたキーペアファイル(“authorized_keys”)も 削除しないでください。
-
ダウンロードしたSSHキーファイルや、仮想サーバー内のキーペアファイルを削除すると、以後、仮想サーバーに対してSSHキーを使った ログインができなくなります。
-
-
復旧方法
-
コントロールパネルのコンソール画面からログインし、対処してください。
※Linux系OSでは、rootユーザーのパスワードは設定されていない状態で提供されます。以下2つの対処方法があります。-
コンソール画面接続時にシングルユーザーモードでログインする
シングルユーザーモードでのログイン手順は クラウドユーザーガイド(コンピューティング:シングルユーザーモードでのログイン手順)を参照してください。 -
事前にrootユーザーのパスワードを設定する(rootユーザーでコンソール接続可能)。
-
-
-
- その他SSH公開鍵認証の注意点
-
-
SSH接続時に入力するパスフレーズとOS上のユーザー/パスワードは異なります。
SSH公開鍵の設定先ユーザーは「root」、SSHパスフレーズはSSH鍵の作成時に設定したものです。 -
SSHの秘密鍵はファイルの削除で喪失します。利用中の鍵ファイルは削除しないでください。
-
SSH接続ユーザーの「.ssh」ディレクトリ 「.ssh/authorized_keys」ファイルはオーナーだけに読み書き可能な権限にしてください。(700、711、755)
-
秘密鍵のパーミッションは600に設定し、その他の設定に変更しないでください。
-
SSH設定ファイルの編集は、編集ミスによって新規のSSH通信が不通になる事を想定した対処を取ってから実施してください。
-
DHCP IPアドレスについて
- つまずきやすいポイント/ありがちな失敗例
-
-
仮想サーバーにDHCPから割り当てられたIPアドレスを手動で設定し、接続できなくなった。
-
- 仕様/対策
-
-
仮想サーバーの グローバルIPアドレス や 共通プライベート に接続されたプライベート側のIPアドレスを、デフォルトのDHCP設定から 変更しないでください。
-
Linux系OS:インターフェース設定ファイルにて静的IPアドレスを設定し再起動しても、設定したIPアドレスで 接続できません。
-
Windows:ネットワークのプロパティ設定にて静的IPアドレスに変更し適用しても、設定したIPアドレスで 接続できません。
-
また、いずれも禁止事項に該当します。
-
-
-
復旧方法
-
コントロールパネルのコンソール画面からログインし、復旧してください。
※Linux系OSでは、rootユーザーのパスワードは設定されていない状態で提供されます。以下2つの対処方法があります。-
コンソール画面接続時にシングルユーザーモードでログインする
-
事前にrootユーザーのパスワードを設定する(rootユーザーでコンソール接続可能)。
-
-
TIPS
- 稼働不可状態となる操作
-
-
Linux系 OS上で /dev/port を対象に読み取りを行うとサーバーが稼働不可状態となり、当社で検知・復旧するまでお客様で操作はできません。詳細は、以下を確認してください。
-
Red Hat系Linux 7以降、Ubuntu 16.04以降のOSでは、起動時スクリプトでSSHの起動及び再起動をするとサーバーが起動しなくなり、サーバー作成の際、起動時スクリプトで実施するとサーバーが自動的に削除されます。
systemctl restart sshd等のコマンドは指定しないでください。
-
- アプリケーションが応答不能になる事象
-
-
Red Hat系Linux 6.6、7.0、7.1の特定カーネルバージョンにおいて、カーネルバグによりfutexを使用するアプリケーションが応答不能になる可能性があります。
OSのカーネルアップデートで事象を解消できます。詳細は、以下を確認してください。
-
ソリューション製品編
-
ニフクラではパートナーが提供するソリューション製品を提供しています。ソリューション製品について、つまずきやすいポイントやありがちな失敗を記載します。
-
ソリューション製品の動作環境やサポート範囲は、ソリューションサービス提供企業に準ずる場合があります。事前に利用予定のソリューションサービスについて、確認してください。
-
Acronisエージェントのバージョンについて
- つまずきやすいポイント/ありがちな失敗例
-
-
バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)を導入時のバージョンで使い続けており、バックアップの失敗や、リストアの失敗などが発生した。
問い合わせしたところ、エージェントのアップデートを求められ想定以上の工数が必要となった。
-
- 仕様/対策
-
-
バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud)の利用時、Acronisエージェントは最新版へのアップデートを推奨します。
詳細はクラウド技術仕様/制限値(ニフクラ バックアップ/セキュリティサービス(Acronis Cyber Protect Cloud))を確認してください。
-
ニフクラトラブルシューティング
-
仮想サーバーをはじめ、よくあるお問い合わせやトラブルシューティングなど、ニフクラ設計や構築の際に役立つ情報をまとめて公開しています。
-
-
ニフクラFAQ(よくある質問)内 『トラブルシューティング』
-
-
-
トラブル時、問合せする際に、早期解決するための問合せ方法を公開しています。
-
ネットワーク通信異常が発生した場合の具体的な現象の一覧、現象に対応した原因、対処方法を公開しています。