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

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

一般

Oracle Supportの取得

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

端末が再度ロックされています

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

Serial Consoleの終了

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証明書とシステム停止のどちらに関連しているかを診断するには、オペレータのブラウザまたはCURLなどのツールで、https://<host>:12060/v1/tenants/oreiエンドポイントに対する適切なレスポンスまたは不正なレスポンスを確認します。そのエンドポイントにアクセスするとセキュリティ警告が発生する場合は、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ドキュメントの新しい子テナンシの作成を参照してください。

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

「System Upgrade Loading」アイコンは回転し続けます

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

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

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

インターネット接続を確認し、「アップグレードのダウンロード」を押してダウンロードを試行してください。複数回試行してもダウンロードが成功しない場合は、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への接続をブロックしているルールをファイアウォール設定から削除します。ファイアウォールの構成手順については、オペレーティングシステムのドキュメントを参照してください。

ストレージ

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

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

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

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

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

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

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

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

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

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

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

RED内のストレージ機能が故障しているか、物理的な問題がある場合、デバイス・コンソールのモニタリング・ページに、Object Storageサービスの「警告」または「低下」ステータスが定期的に表示されることがあります。この状況が発生した場合、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外部接続設定が正しいことを確認します。Setting Up 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. 「エフェメラル・パブリックIP」オプションを選択します。

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

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

  3. RED外部接続設定が正しいことを確認します。シリアル・コンソールを開き、「デバイスの構成」を選択します。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外部接続設定が正しいことを確認します。Setting Up 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範囲を入力します。詳細は、シリアル・コンソールの使用ガイドを参照してください。

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

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

  • GPU全体の使用: 最大1つのGPUシェイプVM (停止されたGPUを含む)が存在します。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(ディスク集中型アプリケーションやネットワーク集中型アプリケーションを実行しているVMなど)が大量に使用されている場合に、パフォーマンスが低下する可能性があります。大規模なオブジェクト・ストレージ・コンテンツやコンピュート・イメージのインポートなど、リソース負荷の高いデバイス操作でもパフォーマンスが低下する可能性があります。集中型のアプリケーションで作業している場合は、より多くのRAMが含まれるため、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で使用される同じオブジェクト・ストレージ・バケットを使用して双方向同期を設定することはできません。作成しているタスクが、以前に作成したタスクの同期方向を逆にしようとしていないことを確認してください。その場合は、いずれかのタスクを変更して、他のタスクの方向を反転しないようにする必要があります。

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

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

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

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

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

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

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

    Alternately, select the Actions menu (アクション・メニュー) for the data sync task that you checked and click Start

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