Roving Edge Infrastructureのトラブルシューティング。

トラブルシューティング情報を使用して、Roving Edge Infrastructureの使用中に発生する可能性がある一般的な問題を特定して対処します。

一般

Oracle Supportの入手

これらのトラブルシューティングのヒントを確認して使用した後でもヘルプが必要な場合は、問題のサービス・リクエストをオープンしてください。詳細は、「サポート・チケットのオープン」を参照してください。

デバイスが再度ロックされています

Roving Edge Infrastructureのデバイスでは、再起動と電源の再投入のたびにロック解除する必要があります。REDが予期せずロックされた場合は、電源接続が安定していることを確認し、最近再起動されたかどうかを確認します。電源接続が安定しており、Roving Edge Infrastructureデバイスが再起動していないことを確認します。

シリアルコンソールの終了

Enter~ (チルダ)、. (ピリオド)の順番で、シリアルコンソールを切断します。

デバイスコンソールのURLに「unavailable」または「not trusted」のメッセージが表示される

デバイス・コンソールは、各Roving Edge Infrastructureデバイスのポート8015でTLS/HTTPSと通信します。ブラウザでURLが使用できない、または信頼できるURLではないことを示すセキュリティ警告が表示された場合は、TLS証明書がマシンにインストールされ、信頼されていることを確認してください。

デバイス・コンソールのTLS証明書がホスト・コンピュータにインストールされて信頼されていない場合は、ブラウザを使用してデバイス・コンソールからホスト・コンピュータのキーチェーン/証明書コレクションにTLS証明書を追加し、それを信頼済としてマークします。Chrome、Edge、Firefoxなどのブラウザでは、TLS証明書はURLの左側にあるブラウザ・ウィンドウにあります。証明書のダウンロード方法の詳細は、ブラウザのマニュアルを参照してください。

システムが部分的に停止している場合は、「unavailable」または「not trusted」メッセージも表示されることがあります。たとえば、システムアップグレードのリブート時や、停電後の初回起動時などです。この問題がTLS証明書またはシステムの停止に関連しているかどうかを診断するには、オペレータのブラウザのhttps://<host>:12060/v1/tenants/oreiエンドポイントまたはCURLなどのツールに対する適切なレスポンスまたは不正なレスポンスがないかどうかを確認します。そのエンドポイントにアクセスすると、セキュリティ警告が発生する場合は、Roving Edge InfrastructureデバイスのTLS証明書が正しくインストールされ、信頼されていることを確認します。エンドポイントがタイムアウトしたり、200以外のレスポンスが返された場合、システムの一部の停止が発生している可能性があります。

デバイスコンソールへのアクセス時のブラウザセキュリティー警告

デバイスコンソールは、指定されたデバイスのポート8015でTLS/HTTPSと通信します。デバイス・コンソール・ブラウザにセキュリティ警告が表示されたら、TLS証明書がRoving Edge Infrastructureデバイスにインストールされ、信頼されていることを確認します。デバイス・コンソールのTLS証明書がホスト・コンピュータにインストールされて信頼されていない場合は、ブラウザのデバイス・コンソールからホスト・コンピュータのキーチェーン/証明書コレクションにTLS証明書を追加します。これを信頼できる対象としてマークしてください。Chrome、Edge、Firefoxなどのブラウザでは、TLS証明書はURLの左側にあるブラウザ・ウィンドウにあります。証明書のダウンロード方法の詳細は、ブラウザのドキュメントを参照してください。

「サービス・ローバー」のポリシーの作成時に「サービス不明」

「サービス・ローバー」のポリシーの作成時に「サービスが不明」というエラーが表示される場合は、Oracle Cloud Infrastructureで子テナンシを作成する必要がある場合があります。この機能の詳細は、Oracle Cloud Infrastructureドキュメントの新しい子テナンシの作成を参照してください。

システムのアップグレード

システム・アップグレードのロード・アイコンが回転し続けます

システム・アップグレード・ツールは、タイムアウトが発生するまでロード状態を維持し、その後はシステムのアップグレード・ステータスを判別できないことを示します。このタイムアウトは、ほとんどの場合、REDがインターネットから切断されたときに発生します。システム・アップグレードでは、REDのアップグレードが使用可能かどうかを判断するためにOCIへの接続が必要です。

デバイスがインターネットから切断されている場合は、切断されたアップグレードプロセスを使用してデバイスを更新できます。詳細は、切断時のRoving Edge Deviceソフトウェアのアップグレードを参照してください。

システム・アップグレード・バンドルのダウンロード・プロセスに失敗しました

インターネット接続を確認し、「アップグレードのダウンロード」を押してダウンロードを試行してください。複数回試行してもダウンロードが成功しない場合は、Oracleサポートに問い合わせてください。

ネットワーキング

パブリックIPプール構成のIPアドレス範囲が送信されません

IP範囲を入力して[Enter]を押した後、空白の入力行で[Enter]を再度押して送信します。さらにIP範囲が必要な場合は、各範囲の後に[Enter]を押して別の入力行を開きます。すべてを送信するには、最後のエントリとして空白の入力明細を発行します。取り消して戻るには、Ctrl+Cを押してください。

パブリック・サービス・エンドポイント(ポート8015、18336などの169.254.169.254)にアクセスできません

インスタンスのファイアウォールが196.254.0.0/16アドレス範囲をブロックしていないことを確認します。OCIエクスポート・イメージでは、デフォルトでリンク・ローカル・アドレス範囲をブロックすることが一般的です。その場合は、ファイアウォール設定から196.254.0.0/16への接続をブロックしているルールを削除します。ファイアウォールの構成手順については、オペレーティングシステムのドキュメントを参照してください。

ストレージ

使用可能なストレージ領域が不足すると、ブロック・ボリューム操作が失敗します。

使用可能なストレージ領域が不足すると、ブロック・ストレージ操作が失敗する可能性があります。オブジェクト・ストレージ・オブジェクト、ブート・ボリューム、ブロック・ボリューム、VMなど、不要になったリソースを削除して領域を解放します。REDの使用可能なストレージを定期的にチェックして、実行の危険がないことを確認します。詳細は、Roving Edge Infrastructureデバイスのモニタリングを参照してください。

使用可能な低オブジェクト・ストレージ容量により、警告および読取り専用がトリガーされます

使用済容量が80%に達すると、モニタリング・ページで「警告」ステータスがトリガーされます。使用済容量が95%に達すると、読取り専用モードになり、「監視」ページにはオブジェクト・ストレージのステータスが「低下」または「警告」と表示されます。

Oracleでは、システムが80%の使用容量で機能しているときに、集中的な書き込み操作を実行しないようにすることをお勧めします。80%近くにいる場合、システムの容量が80%を下回るまで、データをOCIクラウドに転送します。

使用済容量の95%しきい値を超えると、読取り専用モードになり、コア機能(ComputeおよびObject Storageを含む)が制限されます。カスタムVM、ブート・ボリューム、ブロック・ボリュームなどのすべてのコンピュート操作と、すべてのObject Storage操作は一時停止されます。システムの停止により、耐久性と冗長性が保証できない場合、ストレージ・デバイスへの書込みができません。

使用可能なストレージ領域がデバイス上に残っていない場合は、オブジェクト・ストレージ内のオブジェクト、ブート・ボリュームとブロック・ボリューム、VMなど、不要になったリソースを削除することで、より多くの領域を解放できます。ストレージ領域が残っていないために削除リクエストが失敗し、システムが読み取り専用モードになっている場合は、シリアルコンソールからセーフモードをアクティブにできます。セーフモードでは、必要な削除を行うことができます。

ストレージの問題のオーバーサブスクライブの回避

過剰サブスクリプションの問題を回避するために、コンピュート、ブロック・ストレージおよびオブジェクト・ストレージのリソース消費を設定または計画する方法に関するベスト・プラクティスの推奨事項に従います。ブロック・ストレージおよびコンピュートでは、ボリュームのストレージ領域は事前に予約されません。かわりに、データがボリュームに書き込まれると、ストレージ領域が消費されます。たとえば、100 GBのブロック・ボリュームが作成された場合、このボリュームの使用可能な合計ストレージ領域から100 GBが予約されているとはかぎりません。ストレージ領域は、すべてのサービスで使用可能なままであり、100 GBボリュームにデータが一杯になる前に使い果たすことができます。

また、コンピュートおよびブロック・ストレージでは、作成済ボリュームの指定されたサイズが使用可能なストレージ領域に対して検証されません。この検証の欠如により、作成されたボリュームの合計サイズがデバイスで使用可能なストレージ領域を超えると、オーバーサブスクリプションが発生する可能性があります。ストレージ領域の使用率を計算するためにブロック・ボリューム・サイズに依存しないでください。かわりに、デバイス・コンソールの「モニタリング」ページに表示されるストレージ領域の使用状況に関する情報に従ってください。

監視ページには、オブジェクト・ストレージのステータスが「Degraded」または「Warning」と表示されます。

REDのストレージ機能が故障したり、物理的に問題が発生した場合、デバイス・コンソールの「モニタリング」ページに、オブジェクト・ストレージ・サービスの「警告」または「低下」ステータスが定期的に表示されることがあります。この状況が発生した場合、REDはストレージのリバランスを試行し、宣言された冗長性レベルをリカバリします。REDに使用可能な領域があり、ストレージに使用されている残りのREDデバイスで十分な冗長コピーをリカバリできる場合は、最終的に正常な状態になります。

Object StorageからComputeへのイメージ・インポートには時間がかかっています

「カスタム・イメージ」リストにイメージが表示されない場合、インポートは失敗しました。インポートに失敗した場合は、デバイス・ノードの「詳細」ページを確認します:

  1. ナビゲーション・メニューを開き、「ノード管理」→「ノード」を選択します。「ノード」ページが表示され、すべてのRoving Edge Infrastructureデバイスのサービスおよび機能のステータスが表形式で表示されます。

  2. ステータスをモニターするノードを選択し、その「詳細」ページを表示します。

  3. Storage」タブをクリックし、使用されたストレージのデバイスの割合を確認します。

オブジェクト・ストレージ・サービスが正常でない場合は、「モニタリング」ページに「低下」または「警告」がステータスとして表示されます。オブジェクト・ストレージが正常な場合は、「モニタリング」ページをチェックして、使用可能な領域が十分にあることを確認します。使用可能な領域が不足している場合は、イメージ、オブジェクト、VMおよびその他の項目を削除して、必要なイメージの領域を確保します。

特定のバージョンIDを持つオブジェクトで問題が発生する可能性があります。

オブジェクトのバージョンIDがダッシュ(-)で始まり、文字hまたはiを含むCLIコマンドを実行すると、CLIは対話モードになります。例:
oci os object get ... --version-id '-WhjCQ.-IYgDLuoZ9gbxpn.8Q.q-iZt' ...

このような場合は、次のいずれかの回避策を使用できます。

  • --version-idパラメータとその値の間に等号(=)を含めます。=の後ろに空白を入れないでください。例:

    oci os object get ... --version-id="-WhjCQ.-IYgDLuoZ9gbxpn.8Q.q-iZt" ...

    値の周りに二重引用符のみを使用します。

  • コマンドに--from-jsonパラメータを含めて、入力をJSON形式で指定します。詳細は、JSONの拡張オプションを参照してください。

コンピュート/インスタンス

インスタンスの作成が試行されると、「容量不足」というメッセージが表示されます

インスタンス容量は、使用可能なコア数および使用可能なメモリーによって制限されます。使用されていない既存のインスタンスの一部を終了し、再試行してください。インスタンスを停止すると、使用されるリソースに反映されます。

イメージ・インポートの失敗

大きいイメージのインポートには時間がかかり、他のディスクの多いアプリケーションや操作が進行中であれば、はるかに時間がかかります。インポートに時間がかかりすぎて終了する場合は、「インポート」メニューから「終了」を選択します。イメージのインポートは、4時間後に自動的にタイムアウトし、取り消されます。

VMは「Running」状態に起動しますが、一部のブート・メッセージで接続がループすると起動します。

Roving Edge Infrastructureでは、UEFIブートを使用した.ociおよび.qcow2イメージのみがサポートされています。イメージ関連の問題を確認するには、デバイス・コンソールを開き、コンピュートVMインスタンスの「詳細」ページに移動します。イメージ形式が.oci.qcow2または別の型かどうかを確認します。OCIクラウドからエクスポートされるイメージは通常、.ociタイプです。イメージのプロバイダを使用して、イメージおよびブート・タイプを確認します。

Linuxマシンでは、qemu-imgユーティリティを使用して、次のコマンドを使用してイメージ情報を表示します。

qemu-img info image_file

VMインスタンスから外部リソースにアクセスできません

  1. ドメイン名が外部リソースを参照している場合は、外部DNSリゾルバがインスタンス内のネームサーバーのリストに追加されていることを確認します。DNS構成手順については、オペレーティングシステムのドキュメントを参照してください。

    たとえば、一部のLinuxベース・システムでは、ネーム・サーバーIPを/etc/resolv.confファイルに追加する必要があります。

  2. RED外部接続設定が正しいことを確認します。Administering Devicesを参照してください
  3. インスタンス・ファイアウォール設定で送信接続がブロックされないようにしてください。ファイアウォールの構成手順については、オペレーティングシステムのドキュメントを参照してください。

SSHを使用してVMインスタンスに接続できません

  1. VMインスタンスが実行されていることを確認します。デバイス・コンソールを開き、コンピュートVMインスタンス・ページの「詳細」ページを確認して、インスタンスの状態が「実行中」であることを確認します。インスタンスが実行されていない場合は、「Start」と入力してインスタンスを起動します。状態がRUNNINGに変わるのを待機します。

  2. VMインスタンスにパブリックIPアドレスが割り当てられていることを確認します。デバイス・コンソールを開き、コンピュートVMインスタンスの「詳細」ページに移動します。インスタンス名をクリックし、「インスタンス・アクセス」セクションの「パブリックIPアドレス」値を確認して、インスタンスに割り当てられたパブリックIPがあることを確認します。

    インスタンスにパブリックIPが割り当てられていない場合は、次のステップを使用して追加します。

    1. コンピュートVMインスタンスの「詳細」ページを開きます。

    2. 「リソース」の下の「アタッチされたVNIC」をクリックして、アタッチされたVNICのリストを表示します。

    3. プライマリVNICを選択します。

    4. プライマリVNICの詳細ページが表示されます。

    5. 編集」をクリックします。

      または、編集するVNICの「アクション」メニュー(アクション・メニュー)を選択し、「編集」をクリックします。

      「VNICの編集」ダイアログ・ボックスが表示されます。

    6. 「Ephemeral Public IP」オプションを選択します。

    7. 更新」をクリックします。

    8. パブリックIPの割当てが失敗した場合は、シリアル・コンソールを開き、「ネットワーク構成」を選択して、REDのパブリックIPアドレス・プールが設定され、使用可能なIPがあることを確認します。

  3. RED外部接続設定が正しいことを確認します。シリアルコンソールを開き、「Configuring Devices」を選択します。REDのIPアドレス、ネットワーク接頭辞の長さおよびゲートウェイIPアドレスが正しく設定されていることを確認します。

  4. VMインスタンスがICMPリクエストを介して到達可能であることを確認します。次のコマンドを実行します:

    ping 100.100.1.10

    100.100.1.10は、ターゲット・インスタンスのパブリックIPアドレスです。コマンドが成功した場合、問題はインスタンス構成(SSHサービス、ファイアウォール・ルール)にある可能性があります。詳細は、SSHおよびファイアウォールの設定に関するオペレーティング・システムのマニュアルを参照してください。

  5. VMインスタンスが正しく起動していることを確認します。ping 100.100.1.10コマンドの実行が成功しない場合は、インスタンス・コンソール履歴をチェックして、正常な開始順序を探します。Roving Edge Infrastructureのコンソール履歴取得を参照してください。

  6. デバイスの電源ボタンまたはシリアルコンソールを使用して、ノードをリブートします。

外部マシンから VMインスタンスのポートにアクセスできない

  1. RED外部接続設定が正しいことを確認します。Administering Devicesを参照してください。

  2. インスタンス・ファイアウォール設定によって受信接続がブロックされないようにしてください。ファイアウォールの構成手順については、オペレーティングシステムのドキュメントを参照してください。

  3. パブリックIPアドレスが、プライベートIPアドレスや完全修飾ドメイン名(FQDN)ではなく、VMインスタンスにアクセスしていることを確認します。インスタンスのプライベートIPアドレスは、VCNサブネット内でのみ表示されます。インスタンスFQDNは、VCNネットワークの外部ではアクセスできないデフォルトのVCN内部DNSサービス(169.254.169.254)が使用されている場合にのみ表示されます。

別のインスタンスからVMインスタンスにアクセスできません

  1. ターゲット・インスタンスが実行されていることを確認します。デバイス・コンソールを開き、コンピュートVMインスタンスの「詳細」ページを確認して、ターゲット・インスタンスの状態が「実行中」であることを確認します。

  2. リクエスト送信インスタンスのネットワーク構成(IPアドレス、ネットワーク・マスク、ゲートウェイなど)が正しく設定されていることを確認します。構成を実行するときは、サブネット設定のガイドラインに従ってください。詳細は、ネットワーク構成に関するオペレーティング・システムのマニュアルを参照してください。

    Linuxベース・システムでは、次のコマンドを使用して設定を確認します:

    ip addr show ip route show default
  3. ターゲット・インスタンスのファイアウォール設定によって受信接続がブロックされないようにしてください。詳細は、使用しているオペレーティング・システムのファイアウォールの構成手順を参照してください。

  4. リクエスト送信インスタンスのファイアウォール設定によって送信接続がブロックされないようにしてください。ファイアウォールの構成手順については、オペレーティングシステムのドキュメントを参照してください。

  5. ターゲット・インスタンスでICMPがブロックされていない場合は、pingコマンドが成功していることを確認します。リクエスト送信インスタンス・シェルから次のコマンドを実行します。

    ping 10.0.0.2

    ここで、10.0.0.2はターゲット・インスタンスのプライベートIPです。

  6. pingコマンドの結果がNo route to hostの場合、デフォルト・ルートがサブネット・ゲートウェイに設定されていることを確認します。デフォルトのルート設定については、オペレーティングシステムのドキュメントを参照してください。たとえば、Linuxベースのオペレーティングシステムの場合、コマンドは次のようになります。

    ip route show default

    予想される出力は次のとおりです。

    default via 10.0.0.1 dev eth0

    ここで、10.0.0.1は10.0.0.0/24サブネットのゲートウェイIPアドレスです(VCNサブネット・ゲートウェイは、常にサブネット範囲内の最初のアドレスを使用します)。

完全修飾ドメイン名で別のVMインスタンスにアクセスできません

ターゲット・インスタンスが実行されていることを確認します。デバイス・コンソールを開き、コンピュートVMインスタンスの「詳細」ページを確認して、ターゲット・インスタンスの状態が「実行中」であることを確認します。ターゲット・インスタンスが「停止中」の場合は、再起動します。リクエスト送信インスタンスの169.254.169.254がネーム・サーバーとして設定されていることを確認します。DNS構成手順については、オペレーティングシステムのドキュメントを参照してください。

VMが起動しますが、SSHを使用して接続するパブリックIPアドレスがありません

VMインスタンスを作成する場合は、「パブリックIPアドレスの割当て」オプションを選択します。(シリアル・コンソールを使用して)デバイスの設定中に指定されたパブリックIPプールに、VMの数(「停止済」状態のものを含む)に十分なアドレスがあることを確認します。十分なアドレスが存在しない場合は、一部のVMを終了してアドレスを解放するか、シリアル・コンソールを使用してさらにパブリックIPを作成します。

VMの作成が「終了中」状態になります

これは、次のいずれかが原因である可能性があります。

  • パブリックIPの欠如: パブリックIPプールがシリアル・コンソールで設定されていないか、その他の不確定な理由によりIPが不足しているために、IPの欠如が発生する可能性があります。REDのパブリックIPプール範囲が設定されていることを確認します(パブリックIPのデフォルト・オプションを使用してVMを作成する場合):

    1. シリアルコンソールを開きます。

    2. 「ネットワーキングの構成」(オプション3)を選択します。

    3. 「パブリックIPプール・ステータスの表示」(オプション4)を選択します。

    パブリックIPプールが設定されていない場合は、戻って「コンピュート・インスタンスのパブリックIPプール範囲」を選択します。表示された手順に従って、パブリックIP範囲を入力します。シリアル・コンソールには、詳細に関する使用ガイドが含まれています。

  • 完全なセフ・オブジェクト/ブロック・ストレージ: VMのブート・ボリュームに領域を割り当てないと、VMが終了状態になる可能性があります。REDコンソールの「Monitoring」ページの上部を確認して、オブジェクト/ブロック・ストレージがいっぱいでないことを確認します。

  • 完全なCPU使用率: 停止されているOCPUを含む、合計で最大32個のOCPUが複数の仮想マシンに存在します。デバイス・コンソールの「Compute」ページで、既存のVMの合計OCPU数が最大32未満であることを確認します。32個のOCPUすべてが使用されている場合は、一部のインスタンスを終了してリソースを解放します。

  • 完全なGPU使用量: 停止されているGPUを含め、最大1つのGPUシェイプVMが存在します。REDは、一度にプロビジョニングできるGPU形式のVMを1つのみ持つことができます。プロビジョニング中に、さらにGPUシェイプ・インスタンスを作成しようとすると終了します。デバイス・コンソールの「コンピュート」ページで、「実行中」または「停止済」状態のGPUシェイプを持つインスタンスがないことを確認します。GPUシェイプ・インスタンスが存在する場合は、それを終了します。

  • 無効なイメージ: Roving Edge Infrastructureでは、UEFIブートを使用した.ociおよび.qcow2イメージ形式のみがサポートされています。デバイス・コンソールの「コンピュート」ページで、「インスタンス」セクションを開き、終了するVMを決定します。終了しているVMをクリックしてその詳細ページを開き、イメージ名をメモできます。イメージ名と拡張子は、.oci.qcow2、または別のタイプのいずれであるかを示します。OCIクラウドからエクスポートされるイメージは通常、.ociタイプです。イメージおよびブート・タイプを、イメージを提供したユーザーで確認します。

    Linuxマシンでは、qemu-imgユーティリティを使用して、次のコマンドを使用してイメージ情報を表示します。

    qemu-img info image_file

SSHを使用したVMパフォーマンスの低下または端末の使用速度低下

REDパフォーマンスの低下は、ディスク集中型アプリケーションやネットワーク集中型アプリケーションを実行している他のVMの使用量が多い場合に発生する可能性があります。また、大規模なオブジェクト・ストレージ・コンテンツやコンピュート・イメージのインポートなど、リソースを大量に消費するデバイス操作によって、パフォーマンスが低下する可能性があります。集中型のアプリケーションを操作している場合は、OCPU数が多いVMシェイプも多くなるため、それを使用します。現在のVMを停止または終了してから、大きい方のシェイプで同じイメージを使用して別のVMを作成します。

VMが起動して「Running」状態になりますが、SSHによってキーが拒否されるか、接続が拒否されるか、タイムアウトします。

状態が「実行中」と表示されているVMを起動したが、SSHによってキーが拒否されるか、接続が拒否されるか、タイムアウトした場合は、次を試してください:

  • SSHを使用してVMのパブリックIPアドレスに接続しようとしていることを確認します。

  • ホスト・コンピュータでSSHコマンドの一部として秘密キー(公開ではない)を使用していることを確認します。

  • VMを完全に起動するには、1分以上かかります。この時間を指定すると、SSHサービスがロードされます。接続を再試行します。

  • アップロードまたはインポートしたイメージにパブリック・ユーザーSSHキーがすでに含まれている場合、VM作成プロセスの一部としてアップロードまたはコピー/ペーストされた新しいキーが含まれないことがあります。目的のキーが追加された元のイメージのスナップショットを取得し、その変更されたイメージを使用します。

VMインスタンスが長時間スタックしています

ブート・ボリューム、GPUなどの特定のイメージおよびリソースのプロビジョニングには、10分以上かかる場合があります。VMインスタンスが長時間スタックしている場合は、次を実行します:

  1. デバイス・コンソールにアクセスし、インスタンスの「詳細」ページを開きます。

  2. 「アタッチされたブロック・ボリューム」および「アタッチされたVNIC」セクションを確認し、リソースが「アタッチ中」または「デタッチ中」の状態でスタックしていることを確認します。

  3. ブロック・ボリュームまたはVNICがアタッチ/デタッチ状態でスタックしていることが確認された場合は、「モニタリング」ページでブロック・ストレージおよびVCNサービスが正常かどうかを確認します。

    • 使用済ストレージ領域がほぼ一杯の場合、インスタンスをプロビジョニングするのに十分な容量がない可能性があります。領域を解放するために、他のインスタンスの終了、ブロック・ボリュームの削除またはその両方を検討します。

    • パブリックIPプールが使用されている場合、(デフォルトで指定されている)パブリックIPで新しいインスタンスをプロビジョニングすることはできません。既存のインスタンスを終了してIPを解放するか、シリアル・コンソールを使用してパブリックIPを追加します。

  4. その他のサービスの「Monitoring」ページが異常であることを確認します。

ここにリストされているソリューションで問題が解決しない場合は、インスタンスの終了を検討してください。

スタック・インスタンスは数時間後に自動的にクリアされます。そうしないと、手動で終了する必要がある場合があります。

データの同期

「同じタスクまたは循環タスクが存在する」というエラーでタスクの作成が失敗する

データ同期タスクは単方向であり、循環参照に敏感です。2つのタスクと、OCIとREDで使用される同じオブジェクト・ストレージ・バケットを使用して双方向同期を設定することはできません。作成中のタスクが、以前に作成したタスクの同期方向を逆にしようとしていないことを確認します。その場合は、いずれかのタスクを変更し、もう一方のタスクの方向を逆にする必要はありません。

タスクが指定されていますが、同期操作は開始されません

データ同期では、各REDの接続を、データ同期操作を実行するOCIクラウドの場所に割り当てる必要があります。OCIステータス・ページをチェックして、OCIサービスが実行されているかどうかを確認します。ネットワークまたはオブジェクト・ストレージの問題が発生した場合は、データ同期の実行またはスケジュールを試行する前に、これらの問題を解決してください。次に、ホスト・マシンからping OCIを実行して、Roving Edge InfrastructureとOCIの間の接続を確認することで、ローカル・ネットワークに接続性があるかどうかを確認します。OCIのpingが機能しない場合は、接続をブロックするファイアウォールまたはネットワーク・ルールが存在しないことを確認します。

RED-OCIまたはOCI-to-REDからバケットを同期するためのデータ同期タスク・ジョブを作成し、その推定ランタイムが12時間を超える場合、認証トークンは12時間ごとに期限切れになるため、データ同期ジョブは12時間後に失敗します。12時間を超える実行後にデータ同期ジョブが失敗した場合は、次を実行します

  1. ナビゲーション・メニューを開き、「データ同期」を選択します。

    「データ同期タスク」ページが表示されます。すべてのデータ同期タスクが表形式でリストされます。

  2. 失敗したデータ同期タスクを確認します。

  3. 起動」をクリックします。

    または、選択したデータ同期タスクの「アクション」メニュー(アクション・メニュー)を選択し、「開始」をクリックします

  4. 要求されたら、開始を確認します。