1. 管理者ガイドforリリース3.0.2
  2. ステータスおよびヘルス・モニタリング
機械翻訳について

5 ステータスおよびヘルス・モニタリング

システム・ヘルス・チェックおよびモニタリング・データは、問題検出の基盤です。 必要なトラブルシューティングおよびデバッグ情報はすべて単一のデータ・ストアで保持されるため、問題を調査する必要がある場合、個々のコンポーネントから収集する必要はありません。 システムの全体的な健全性は1箇所で取得されます: Grafana.

Oracleでは、Grafanaにデフォルトのダッシュボードとアラート、およびLokiに格納されているログを参照するメカニズムが構築されています。 お客様は、この設定を展開してカスタマイズすることもできますが、これはOracle Private Cloud Applianceドキュメントの範囲外です。

この機能の実装の詳細および技術的なバックグラウンド情報は、「Oracle Private Cloud Appliance概要ガイド」を参照してください。 「アプライアンス管理の概要」の章の「Status and Health Monitoring」の項を参照してください。

Grafanaの使用

Grafanaを使用すると、Oracle Private Cloud Applianceは、システムのすべてのレベルおよびすべてのコンポーネントで収集されたログおよびメトリックに対して、視覚的に指向した単一のインタフェースを管理者に提供します。 この項では、Grafanaにアクセスし、ログおよびモニタリング・ダッシュボードをナビゲートするための基本的なガイドラインを示します。

Grafanaホーム・ページにアクセスするには

  1. 「サービスWeb UI」を開き、ログインします。

  2. ダッシュボードの右側にあるMonitoringタイルをクリックします。

    Grafanaホーム・ページが新しいブラウザ・タブで開きます。 プロンプトが表示されたら、ユーザー名およびパスワードを入力します。

ログおよびメトリックがPrometheusに格納されると、アプライアンスの時間とタイムゾーン設定に基づいてタイムスタンプが付与されます。 ただし、Grafanaでは、ユーザー・プリファレンスに基づいて時間が表示され、異なるタイム・ゾーンにいるためオフセットが発生する可能性があります。 Grafanaビジュアライゼーションのタイム・ラインをアプライアンスのタイム・ゾーンと同期することをお薦めします。

Grafanaタイム・ライン表示を変更するには

  1. Grafanaホーム・ページを開きます。

  2. 左側のメニュー・バーで、(下部近くにある)ユーザー・アカウント・アイコンをクリックして、アカウント・プリファレンスを表示します。

  3. プリファレンス・セクションで、タイムゾーン設定をアプライアンスと同じタイムゾーンに変更します。

  4. 下の保存ボタンをクリックして変更を適用します。

Private Cloud Applianceの事前定義済ダッシュボードには、Grafanaホーム・ページから直接アクセスできませんが、最も使用されているダッシュボードを後でホーム・ページに表示できます。 ダッシュボードは、メイン・メニューのダッシュボード・セクションからアクセスするフォルダで構成されています。

Grafanaダッシュボードを参照するには

  1. 左側のメニュー・バーで、Dashboards(ダッシュボード)をポイントし、Manage(管理)を選択します。

    フォルダまたはダッシュボード・セットのリストが表示されます。

  2. フォルダをクリックすると、そのフォルダに含まれるダッシュボードのリストが表示されます。 ダッシュボードをクリックしてそのコンテンツを表示します。

  3. フォルダとダッシュボードのリストに戻るには、ステップ1で行ったようにメニュー・バーを使用します。

「My Sauron (読取り専用)」ダッシュボード・セットを除き、すべての事前定義済ダッシュボードおよびパネルは設計によって編集可能です。 これらは、モニターする特定のメトリックを使用して変更することも、独自のメトリックを作成することもできます。 アラートにも同様です。

アラートは別の領域で管理されます。 Oracleには、便宜上、一連のアラートが事前定義されています。

アラート・ルールおよび通知にアクセスするには

  1. 左側のメニュー・バーで、Alerting(ベル・アイコン)をクリックします。

    現在のステータスを含む、定義されているすべてのアラート・ルールのリストが表示されます。

  2. アラート・ルールをクリックして詳細パネルを表示し、そのステータスが時間の経過とともにどのように変化し、アラートしきい値に対する相対的なかを確認します。

  3. アラート・ルールのリストに戻るには、ステップ1で行ったようにメニュー・バーを使用します。

  4. アラート通知を構成するには、アラート・ページの「通知チャネル」タブに移動します。

ノート:

独自の外部通知チャネルを使用してカスタム・アラートを構成する場合は、最初にSauron APIエンドポイントを使用してGrafanaのプロキシを構成する必要があります。 これを行うには、管理仮想IPを所有する管理ノードにログインし、次のコマンドを実行します: 

$ sudo curl -u <admin_user_name> \
-XPUT 'https://api.<mypca>.example.com/v1/grafana/proxy/config?http-proxy=<proxy_fqdn>:<proxy_port>&https-proxy=<proxy_fqdn>:<proxy_port>'
Enter host password for user '<admin_user_name>':
Grafana proxy config successfully updated!

最後に、Grafanaは、Lokiを介して集計されるアプライアンス・ログへのアクセスも提供します。 詳細は、「システム・ログへのアクセス」を参照してください。

ハードウェアおよびプラットフォーム・コンポーネントの健全性およびステータスの確認

ハードウェア層とプラットフォーム層は、システムアーキテクチャの基礎を形成します。 このレベルの異常な条件は、インフラストラクチャ・サービス内の操作に悪影響を及ぼすことが予想されます。 多くの事前定義済Grafanaダッシュボードを使用すると、これらの重要な低レベル・コンポーネントのステータスを確認し、関連するメトリックのリアルタイムおよび履歴の詳細にドリルダウンできます。

この項で説明するダッシュボードは、基本的なシステム・ヘルス・チェックのスタート・ポイントと、問題が見つかった場合のトラブルシューティングに役立ちます。 かわりに、様々なダッシュボード、メトリックおよびビジュアライゼーションを使用することをお薦めします。 システム全体にわたって収集される必要なデータはPrometheusに格納され、無数の方法でGrafanaを使用して照会および表示できます。

Grafanaフォルダ ダッシュボード 説明

サービスのモニタリング

サーバー統計

この包括的なダッシュボードには、サーバー・ノードのテレメトリ・データが表示されます。 これには、CPUおよびメモリー使用率、ディスク・アクティビティ、ネットワーク・トラフィックなどのグラフが含まれます。

このダッシュボードの一部のパネルでは、1つのグラフに多数の「シリーズ」が表示されるため、1つのグラフをクリックして表示するか、グラフ上にカーソルを置いて時間軸の特定のポイントの詳細データを表示できます。

PCA 3.0サービス・アドバイザ

プラットフォームのヘルス・チェック

このダッシュボードは、Grafanaがロギングおよびモニタリング用に提供する一元化されたアプローチにアプライアンスのヘルス・チェック・メカニズムを統合します。

デフォルトでは、Platform Health Checkダッシュボードに、すべてのヘルス・チェック・サービスの失敗が表示されます。 プラットフォーム・サービスのリストからヘルス・チェッカを選択してパネルの表示を変更でき、正常、異常またはすべての結果を表示するように選択できます。

通常、ヘルス・チェックの失敗が表示された場合は、トラブルシューティングを開始します。 そのために、各ヘルス・チェック結果には、関連するLokiログへの直接リンクとして機能するタイムスタンプが含まれています。 ヘルス・チェックの結果に関連するログを表示するには、タイム・スタンプをクリックするだけです。

My Sauron (読取り専用)

ノード・エクスポータがいっぱいです

このダッシュボードには、1つのコンピュートまたは管理ノードに対して多数の詳細なメトリック・パネルが表示されます。 リストからホストを選択してデータを表示します。

このダッシュボードは、サーバー統計ダッシュボードのファイングレイン拡張とみなすことができます。 さまざまなパネルでは、サーバー・ノードのハードウェア・ステータスとオペレーティング・システムのサービスとプロセスの詳細なカバレージが提供されます。 通常、各物理ノードのコマンド行で収集する情報は、1つのダッシュボードにまとめられ、ライブ・データとその推移が表示されます。

My Sauron (読取り専用)フォルダのすべてのダッシュボードには、システム・レベルの障害を解決する必要がある場合に重要なデータが表示されます。 したがって、これらのダッシュボードは変更または削除できません。

モニタリング・データの表示および解釈

インフラストラクチャ・サービス・レイヤーは、プラットフォーム上に構築され、すべてのクラウド・ユーザーおよび管理者機能を有効にし、Grafanaダッシュボードの広範なコレクションを介して監視できます。 これらのマイクロサービスは、Kubernetesコンテナの3つの管理ノードにわたってデプロイされるため、そのモニタリングは主にKubernetesノードおよびポッド・メトリックに基づきます。 Kubernetesクラスタもコンピュート・ノードに拡張され、Kubernetesワーカー・ノードは、システム操作およびモニタリングのための重要な追加データを収集します。

この項で説明するダッシュボードは、マイクロサービス・ヘルス・モニタリングの開始点となります。 かわりに、様々なダッシュボード、メトリックおよびビジュアライゼーションを使用することをお薦めします。 システム全体にわたって収集される必要なデータはPrometheusに格納され、無数の方法でGrafanaを使用して照会および表示できます。

Grafanaフォルダ ダッシュボード 説明

サービスのモニタリング

ClusterLabs HAクラスタの詳細

このダッシュボードでは、特注のPrometheusエクスポータを使用して、Pacemakerに基づいてHAクラスタのデータを表示します。 各HTTPリクエストでは、クラスタ・コンポーネント・ツールによって提供される既存の分散データを解析することで、クラスタ・ステータスをローカルで検査します。

モニタリング・データには、Pacemakerクラスタ・サマリー、ノードとリソース統計、Corosyncリング・エラーおよび定足数投票が含まれます。

サービスのモニタリング

MySQLクラスタ・エクスポータ

このダッシュボードには、MySQLデータベース・クラスタのパフォーマンス詳細が表示されます。 データには、稼働時間、接続統計、表ロック数などのデータベース・サービス・メトリック、およびMySQLオブジェクト、接続、ネットワーク・トラフィック、メモリーおよびCPU使用率に関するより一般的な情報が含まれます。

サービスのモニタリング

サービス・レベル

このダッシュボードには、基本的なアプライアンス・サービスによって受信されたRabbitMQリクエストに関する詳細情報が表示されます。 リクエスト数、リクエスト・レイテンシ、およびエラーの原因となったリクエストを監視できます。

サービスのモニタリング

VM統計

この包括的なダッシュボードには、環境内のコンピュート・インスタンス全体のリソース消費情報が表示されます。 これには、CPUおよびメモリー使用率、ディスク・アクティビティ、ネットワーク・トラフィックなどのグラフが含まれます。

このダッシュボードのパネルには、1つのグラフに多数の「シリーズ」が表示されるため、1つのグラフをクリックして表示するか、グラフ上にカーソルを置いて時間軸の特定のポイントの詳細データを表示できます。

PCA 3.0サービス・アドバイザ

Kubeエンドポイント

このダッシュボードは、特にKubernetesエンドポイントに焦点を当て、エンドポイント・アラートを提供します。 これらのアラートは、選択した通知チャネルに送信できます。

PCA 3.0サービス・アドバイザ

Kube Ingress

このダッシュボードでは、Kubernetesサービスおよびそのポッドへのイングレス・トラフィックに関するデータが提供されます。 2つのアラートが組み込まれており、選択した通知チャネルに送信できます。

PCA 3.0サービス・アドバイザ

Kubeノード

このダッシュボードには、Kubernetesクラスタおよびホスト・マイクロサービス・ポッドに属するすべてのサーバー・ノードのメトリック・データ(管理およびコンピュート・ノード)が表示されます。 ポッド数、CPUおよびメモリー使用量などを監視できます。 メトリック・パネルには、すべてのノードに関する情報が表示されます。 グラフ・ベースのパネルでは、クリックすると1つのノードだけの情報を表示できます。

PCA 3.0サービス・アドバイザ

Kube Pod

このダッシュボードには、マイクロサービス・ポッドのレベルでメトリック・データが表示され、ポッドの合計数およびそれらをノード間でどのように分散しているかを表示できます。 ネームスペースごとおよびサービスごとにステータスをモニターし、アラートがトリガーされたかどうかを確認できます。

PCA 3.0サービス・アドバイザ

Kubeサービス

このダッシュボードには、メトリック・データがKubernetesサービス・レベルで表示されます。 データは特定のサービスに対してフィルタ処理できますが、デフォルトではすべてが表示されます。 2つのアラートが組み込まれており、選択した通知チャネルに送信できます。

Kubernetesモニタリング

Kubernetesコンテナのモニタリング

Kubernetesモニタリング・ノード

(all)

これらのフォルダには、Kubernetesクラスタのほぼすべての側面をカバーする、広範なモニタリング・データを含むダッシュボードの多種多様なコレクションが含まれています。

データは、クラスタ、ノード、ポッドおよびコンテナ・レベルでKubernetesをカバーします。 メトリックは、デプロイメント、イングレス、CPU、ディスク、メモリーおよびネットワークの使用状況などについてのインサイトを提供します。

システム容量のモニタリング

コンピュート・インスタンスをホストするシステム容量と、使用するストレージを決定する主要なメトリックを追跡することが重要です。 コンピュート・ノードの負荷およびストレージ使用量の詳細データはGrafanaダッシュボードにありますが、管理者はCPUおよびメモリーの現在の消費量とストレージ領域に直接アクセスできます。

フォルト・ドメイン別CPUおよびメモリー使用量の表示

getFaultDomainInfoコマンドは、フォルト・ドメイン全体のメモリーおよびCPU使用率の概要を示します。

「サービスWeb UI」の使用

  1. PCA Configナビゲーション・メニューで、Fault Domainsをクリックします。

    この表には、フォルト・ドメイン別のCPUおよびメモリー使用量データが表示されます。

  2. コンポーネントに関する詳細情報を表示するには、表でそのホスト名をクリックします。

「サービスCLI」の使用

  1. フォルト・ドメインのCPUおよびメモリー使用量のリストを表示するには、getFaultDomainInfoコマンドを使用します。

    UNASSIGNED行は、現在フォルト・ドメインに割り当てられていないコンピュート・ノードを参照します。 コンピュート・ノードはフォルト・ドメインに属していないため、メモリーおよびCPU使用率「フォルト・ドメイン内」はゼロです。 「サービスWeb UI」の「コンピュート・ノード情報」ページを表示すると、コンピュート・ノード当たりのメモリーおよびCPU使用率にアクセスできます。 

    PCA-ADMIN> getFaultDomainInfo
Command: getFaultDomainInfo
Status: Success
Time: 2022-06-17 14:43:13,292 UTC
Data:
  id           totalCNs   totalMemory   freeMemory   totalvCPUs   freevCPUs  
notes  
  --           --------   -----------   ----------   ----------   ---------  
-----  
  UNASSIGNED   11         0.0           0.0          0            0          
        
  FD1          1          984.0         968.0        120          118        
        
  FD2          1          984.0         984.0        120          120        
        
  FD3          1          984.0         984.0        120          120
ZFS Storage Applianceのディスク領域使用量の表示

「サービス・エンクレーブ」は、ZFSプール・マネージャと呼ばれるストレージ・モニタリング・ツールを実行し、60秒ごとにZFS Storage Applianceをポーリングします。 「サービスCLI」を使用すると、各ZFSプールで使用可能なディスク領域の使用状況に関する現在の情報を表示できます。 超過した場合に障害をトリガーする使用しきい値を設定することもできます。

標準ストレージ構成では、プールは1つしかありません。 システムに高パフォーマンスのディスク・トレイが含まれている場合は、両方のプールの使用状況情報を個別に表示できます。

次のように「サービスCLI」を使用して、ストレージ容量を確認します:

  1. ZFSプールのステータスを表示します。

    PCA-ADMIN> list ZfsPool
Command: list ZfsPool
Status: Success
Time: 2022-10-10 08:44:11,938 UTC
Data:
  id                                     name
  --                                     ----
  e898b147-7cf0-4bd0-8b54-e32ec83d04cb   PCA_POOL
  c2f67943-df81-47a5-9713-06768318b623   PCA_POOL_HIGH

PCA-ADMIN> show ZfsPool id=e898b147-7cf0-4bd0-8b54-e32ec83d04cb
Command: show ZfsPool id=e898b147-7cf0-4bd0-8b54-e32ec83d04cb
Status: Success
Time: 2022-10-10 08:44:22,051 UTC
Data:
  Id = e898b147-7cf0-4bd0-8b54-e32ec83d04cb
  Type = ZfsPool
  Pool Status = Online
  Free Pool = 44879343128576
  Total Pool = 70506183131136
  Pool Usage Percent = 0.3634693989163486
  Name = PCA_POOL
  Work State = Normal

  2. ZFSプール・マネージャの障害しきい値を構成します。 デフォルトでは、80%フル(値= 0.8)に設定されます。 

    PCA-ADMIN> show ZfsPoolManager
Command: show ZfsPoolManager
Status: Success
Time: 2022-10-10 08:58:11,231 UTC
Data:
  Id = a6ca861b-f83a-4032-91c5-bc506394d0de
  Type = ZfsPoolManager
  LastRunTime = 2022-10-09 12:17:52,964 UTC
  Poll Interval (sec) = 60
  The minimum Zfs pool usage percentage to trigger a major fault = 0.8
  Manager's run state = Running

PCA-ADMIN> edit ZfsPoolManager usageMajorFaultPercent=0.75
Command: edit ZfsPoolManager usageMajorFaultPercent=0.75
Status: Success
Time: 2022-10-10 08:58:27,657 UTC
JobId: 67cfe180-f2a2-4d59-a676-01b3d73cffae

システム・ログへのアクセス

ログはシステム全体から収集され、Lokiに集計されます。 すべてのログ・データは、Grafanaの中央インタフェースを使用して問合せ、フィルタ処理および表示できます

Lokiログを表示するには

  1. Grafanaホーム・ページを開きます。

  2. 左側のメニュー・バーで、エクスプローラ(コン・パス・アイコン)をクリックします。

    デフォルトでは、参照ページのデータ・ソースは"Prometheus"に設定されます。

  3. 左側のページの上部にあるデータ・ソース・リストから「Loki」を選択します。

  4. ログ・ラベル・リストを使用して、ログを問い合せてフィルタします。

ログはラベルに分類され、特定のタイプまたはカテゴリのログ・エントリを表示するために問合せできます。 Private Cloud Appliance内で使用される主要なログ・ラベル・カテゴリは次のとおりです:

  • job

    このカテゴリのログ・ラベルは、次の3つのカテゴリに分類されます:

    • プラットフォーム: アプライアンス・アーキテクチャの基礎レイヤーで実行されているサービスおよびコンポーネントからのログ。

      このカテゴリのログ・ラベルには次が含まれます: "him"/"has"/"hms" (ハードウェア管理)、"api-server"、"vault"/"etcd" (シークレット・サービス)、"corosync"/"pacemaker"/"pcsd" (管理クラスタ)、"messages" (RabbitMQ) "pca-platform-l0"、"pca-platform-l1api"など。

    • インフラストラクチャ・サービス: プラットフォーム上にデプロイされたユーザー・レベルのクラウド・サービスおよび管理サービスからのログ。 これらのサービスは、名前で簡単に識別できます。

      このカテゴリのログ・ラベルには次が含まれます: "brs" (バックアップ/リストア)、"ceui" (コンピュートWeb UI)、"seui" (サービスWeb UI)、"compute"、"dr-admin" (ディザスタ・リカバリ)、"filesystem"、"iam" (アイデンティティおよびアクセス管理)、"pca-upgrader"など。

    • 標準出力: コンテナ化されたインフラストラクチャ・サービスがstdoutストリームに送信したことをログに記録します。 この出力は、ユーザーがUI操作またはCLIコマンドを実行すると表示されます。

      ログ・ラベルjob="k8s-stdout-logs"を使用して、標準出力ログをフィルタ処理します。 ログ・データはマイクロサービスのKubernetesコンテナから取得され、ポッド名またはコンテナ名(あるいはその両方)を指定してさらにフィルタできます。

  • k8s_app

    このカテゴリのログ・ラベルを使用すると、標準出力ログを絞り込むことができます(job="k8s-stdout-logs")。 そのログ・データはマイクロサービスのKubernetesコンテナから取得され、関心のある特定のサービスの名前に対応するラベルを選択してさらにフィルタできます。

jobまたはk8s_appログ・ラベルのいずれかを選択して、ログをナビゲートします。 目的のサービスまたはアプリケーションに対応するラベルを選択し、ログのリストが時系列で逆に表示されます。 ログ・エントリの上に表示されている時間行の一部にズーム・インすることで、検索を絞り込むことができます。 カラー・コーディングは、注意が必要なアイテムを識別するのに役立ちます。たとえば、: 警告は黄色でマークされ、エラーは赤でマークされます。

監査ログ

監査ログは、個別のカテゴリとして参照できます。 ログ・ラベル・リストから、次の監査ラベルを選択できます:

  • job="vault-audit"

    このログ・ラベルを使用して、ボールト・クラスタの監査ログをフィルタします。 シークレット・サービスのキー・コンポーネントであるボールトは、すべてのリクエストおよびレスポンスの詳細なログを保持します。 認証されたすべてのボールトとの相互作用(エラーを含む)を表示できます。 これらのログには機密情報が含まれているため、秘密情報が監査ログでプレーン・テキストで表示されないように、リクエストおよびレスポンス内の多くの文字列がハッシュされます。

  • job="kubernetes-audit"

    このログ・ラベルを使用して、Kubernetesクラスタの監査ログをフィルタします。 Kubernetes監査ポリシーは、リクエスト・メタデータをログに記録するように構成されます: ユーザー、タイム・スタンプ、リソース、動詞などのリクエスト・リクエスト本文およびレスポンス本文は監査ログには含まれません。

  • job="audit"

    このログ・ラベルを使用して、Oracle Linuxカーネル監査デーモンのログをフィルタします。 カーネル監査デーモン(auditd)は、Linux監査システムのユーザー空間コンポーネントです。 システム・ログイン、アカウント変更、sudo操作などの特定のイベントを取得します。

  • log="audit"

    このログ・ラベルを使用して、ZFS Storage Applianceの監査ログをフィルタします。

リストのログ・ラベルを使用する以外に、カスタム問合せを作成することもできます。 たとえば、管理サービスおよびAPIサービスの監査ログをフィルタするには、ログ・ラベル・リストの横にあるフィールドに次の問合せを入力します: 

{job=~"(admin|api-server)"} | json tag="tag" | tag=~"(api-audit.log|audit.log)"

実行するには、右上隅の問合せの実行ボタンをクリックするか、Shift + Enterを押します。

Oracle Auto Service Requestの使用

Oracle Private Cloud Applianceは、Oracle Auto Service Request (ASR)に適格です。 ASRは、My Oracle Supportと統合されています。 特定のハードウェア障害が発生すると、ASRは自動的にサービス・リクエストを開き、診断情報を送信します。 アプライアンス管理者は、サービス・リクエストが開いているという通知を受信します。

ASRの使用はオプションです: アプライアンスのサービスを登録して有効にする必要があります。

Oracle Auto Service Requestの理解

ASRは、特定のPrivate Cloud Applianceハードウェア障害が発生した場合にサービス・リクエストを自動的に開きます。 この機能を有効にするには、ハードウェア障害テレメトリをhttps://transport.oracle.comのOracleに直接、プロキシ・ホスト、または別のエンドポイントに送信するようにPrivate Cloud Applianceを構成する必要があります。 たとえば、データセンターにASR Managerソフトウェアがインストールされている場合、複数のシステムの集約ポイントとして別のエンドポイントを使用できます。

ハードウェアの問題が検出されると、ASRはサービス・リクエストをOracleサポート・サービスに送信します。 多くの場合、Oracleサポート・サービスは、管理者が問題が存在することを認識する前に、問題の解決作業を開始できます。

ASRは、ディスク、ファン、電源供給などの最も一般的なハードウェア・コンポーネントで障害を検出し、障害が発生するとサービス・リクエストを自動的に開きます。 ASRは、可能性のあるすべてのハードウェア障害を検出せず、顧客データセンター内のほかのモニタリング・メカニズム(SMTPアラートなど)を置き換えるものではありません。 ASRは、交換ハードウェアの発送を促進および簡素化する補完メカニズムです。 ASRは、高優先度システムのダウンタイム・イベントに使用することはできません。 優先順位の高いイベントについては、Oracleサポート・サービスに直接お問い合せください。

サービス・リクエストの作成を通知するために、My Oracle Support電子メール・アカウントとPrivate Cloud Applianceの技術担当者の両方に電子メール・メッセージが送信されます。 ASRへの接続が失われた場合など、場合によってはサービス・リクエストが自動的に発行されないことがあります。 管理者は、サービス・リクエストが自動的に提出されたという通知を受け取らない場合は、各自のシステムの障害を監視し、Oracleサポート・サービスを呼び出す必要があります。

ASRの詳細は、次のリソースを参照してください。

Oracle Auto Service Request前提条件

ASRサービスに登録する前に、次の前提条件が満たされていることを確認してください。

  1. 有効なMy Oracle Supportアカウントがあることを確認してください。

    必要に応じて、https://support.oracle.comでアカウントを作成します。

  2. My Oracle Supportに次のものが正しく設定されていることを確認します:

    • Private Cloud Applianceを担当する顧客サイトの技術担当者

    • Private Cloud Applianceが配置されている顧客サイトの有効な出荷先住所で、部品が設置する必要があるサイトに搬送されるようにします

  3. HTTPSを使用してインターネットへの接続を確認します。

    たとえば、curlを試して、https://support.oracle.comにアクセスできるかどうかをテストします。

Oracle Auto Service RequestへのPrivate Cloud Applianceの登録

Private Cloud ApplianceをASRクライアントとして登録するには、次のいずれかの方法でハードウェア障害テレメトリをOracleに送信するようにアプライアンスを構成する必要があります:

異なるエンドポイントを使用する例として、複数のシステムのポイントとしてデータセンターにASR Managerソフトウェアがインストールされているとします。

ASRにPrivate Cloud Applianceを登録すると、ASRサービスが自動的に有効になります。

「サービスWeb UI」の使用

  1. ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。

  2. 「登録」ボタンをクリックします。

  3. ユーザー名とパスワードを入力し、選択したフォン・ホーム構成のフィールドに入力します。

    • ユーザー名: 必須。 My Oracle Supportから取得できるOracleシングル・サインオン(SSO)資格証明を入力します。

    • パスワード: 必須 SSOアカウントのパスワードを入力します。

    • プロキシ・ユーザー名: プロキシ・ホストを使用するには、そのホストにアクセスするためのユーザー名を入力します。

    • プロキシ・パスワード: プロキシ・ホストを使用するには、そのホストにアクセスするためのパスワードを入力します。

    • プロキシ・ホスト: プロキシ・ホストを使用するには、そのホストの名前を入力します。

    • プロキシ・ポート: プロキシ・ホストを使用するには、ホストへのアクセスに使用するポートを入力します。

    • エンドポイント: ASRデータ統合にポイントまたはその他のエンドポイントを使用する場合は、この形式でそのエンドポイントを入力 : http://host[:port]/asr

「サービスCLI」の使用

ASRをhttps://transport.oracle.comに直接構成

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientRegisterカスタム・コマンドを使用して、アプライアンスを登録します。 

    PCA-ADMIN> asrClientRegister username=asr-pca3_ca@example.com \ 
password=********  confirmPassword=******** \
endpoint=https://transport.us.oracle.com/ \
Command: asrClientRegister username=asr-pca3_ca@example.com \ 
password=*****  confirmPassword=***** \ 
endpoint=https://transport.us.oracle.com/
Status: Success
Time: 2021-07-12 18:47:14,630 UTC

  3. 構成を確認します。

    PCA-ADMIN> show asrPhonehome
Command: show asrPhonehome
Status: Success
Time: 2021-09-30 13:08:42,210 UTC
Data:
  Is Registered = true
  Overall Enable Disable = true
  Username = asr.user@example.com  Endpoint = https\://transport.us.oracle.com/
PCA-ADMIN>

プロキシ・ホストへのASRの構成

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientRegisterカスタム・コマンドを使用して、アプライアンスを登録します。 

    PCA-ADMIN> asrClientRegister username=asr-pca3_ca@oracle.com \ 
password=******** confirmPassword=******** \ 
proxyHost=zeb proxyPort=80 \ 
proxyUsername=support \ 
proxyPassword=**** proxyConfirmPassword=**** \

別のエンドポイントへのASRの構成

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientRegisterカスタム・コマンドを使用して、アプライアンスを登録します。 

    PCA-ADMIN> asrClientRegister username=oracle_email@example.com \ 
password=********  confirmPassword=******** \
endpoint=https://transport.us.oracle.com/ \
Command: asrClientRegister username=oracle_email@example.com \ 
password=*****  confirmPassword=***** \ 
endpoint=https://transport.us.oracle.com/
Status: Success
Time: 2021-07-12 18:47:14,630 UTC

Oracle Auto Service Request構成のテスト

構成後、ASR構成をテストして、エンド・ツー・エンドの通信が正しく機能していることを確認します。

「サービスWeb UI」の使用

  1. ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。

  2. ControlsメニューでTest Registrationを選択します。

  3. Test Registrationをクリックします。 ダイアログによって、テストが成功したかどうかが確認されます。

  4. テストが成功しない場合は、ASR構成情報を確認してテストを繰り返します。

「サービスCLI」の使用

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientsendTestMsgカスタム・コマンドを使用して、ASR構成をテストします。 

    PCA-ADMIN> asrClientsendTestMsg
Command: asrClientsendTestMsg
Status: Success
Time: 2021-12-08 18:43:30,093 UTC
PCA-ADMIN>

Oracle Auto Service RequestのPrivate Cloud Applianceの登録解除

ASRのPrivate Cloud Applianceを登録解除すると、ASRサービスは自動的に無効になります。別のステップを実行する必要はありません。

「サービスWeb UI」の使用

  1. ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。

  2. Unregisterボタンをクリックします。 プロンプトが表示されたら、操作を確認します。

「サービスCLI」の使用

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientUnregisterカスタム・コマンドを使用して、アプライアンスを登録します。 

    PCA-ADMIN> asrClientUnregister
Command: asrClientUnregister
Status: Success
Time: 2021-06-23 15:25:18,127 UTC
PCA-ADMIN>

Oracle Auto Service Requestの無効化

アプライアンスでASRを無効にして、障害メッセージの送信やサービス・リクエストの作成を一時的に防止できます。 たとえば、システムのメンテナンス中、コンポーネントは停止しているが、障害が発生していないか、障害が発生していない可能性があります。 ASRサービスを再起動するには、「Oracle Auto Service Requestの有効化」を参照してください。

「サービスWeb UI」の使用

  1. ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。

  2. 「無効化」ボタンをクリックします。 プロンプトが表示されたら、操作を確認します。

「サービスCLI」の使用

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientDisableカスタム・コマンドを使用して、ASRサービスを停止します。 

    PCA-ADMIN> asrClientDisable
Command: asrClientDisable
Status: Success
Time: 2021-06-23 15:26:17,753 UTC
PCA-ADMIN>

Oracle Auto Service Requestの有効化

このセクションでは、ASRサービスが無効になっている場合にASRサービスを再起動する方法について説明します。

「サービスWeb UI」の使用

  1. ナビゲーション・メニューを開き、ASR Phone Homeをクリックします。

  2. 「有効化」ボタンをクリックします。 プロンプトが表示されたら、操作を確認します。

「サービスCLI」の使用

  1. SSHを使用して、管理ノードVIPにadminとしてログインします。 

    # ssh -l admin 100.96.2.32 -p 30006

  2. asrClientEnableカスタム・コマンドを使用して、ASRサービスを起動します。 

    PCA-ADMIN> asrClientEnable
Command: asrClientEnable
Status: Success
Time: 2021-06-23 15:26:47,632 UTC
PCA-ADMIN>

サポート・バンドルの使用

サポート・バンドルは、問題の評価および修正に使用される、Private Cloud Applianceから収集された診断データのファイルです。

サポート・バンドルは、Oracleサポートに自動的にアップロードすることも、手動でアップロードすることもできます。 サポート・バンドルは安全にアップロードされ、最小限必要なデータが含まれます: システム・アイデンティティ (IPアドレスではない)、問題の症状、およびログやステータスなどの診断情報。

サポート・バンドルは作成でき、アップロードできません。 自分で使用するためにバンドルを作成することもできます。 サポート・バンドルの作成は、関連データを収集する便利な方法です。

サポート・バンドルは、次の方法で作成およびアップロードされます:

Oracle Auto Service Request (ASR)

特定のハードウェア障害が発生した場合、ASRは自動的にサービス・リクエストとサポート・バンドルを作成します。 サービス・リクエストおよびサポート・バンドルはOracleサポートに自動的に送信され、Private Cloud Appliance管理者に通知されます。 「Oracle Auto Service Requestの使用」を参照してください。

asrInitiateBundle

asrInitiateBundleコマンドは、サポート・バンドルを作成し、既存のサービス・リクエストにサポート・バンドルをアタッチし、OracleサポートにアップロードするPCA-ADMINコマンドです。 「asrInitiateBundleコマンドの使用」を参照してください。

support-bundles

support-bundlesコマンドは、指定したタイプのサポート・バンドルを作成する管理ノード・コマンドです。 Oracleサポートでは、このコマンドを実行してサービス・リクエストに関連するより多くのデータを収集するように求められる場合や、ユーザー自身で使用するためにこのデータを収集する必要がある場合があります。 「support-bundlesコマンドの使用」を参照してください。

Oracleサポートへの手動アップロード

サポート・バンドルまたはその他のデータをOracleサポートにアップロードするには、いくつかのメソッドを使用できます。 「サポート・バンドルのOracle Supportへのアップロード」を参照してください。

asrInitiateBundleコマンドの使用

asrInitiateBundleコマンドには3つのパラメータがあり、すべて必須です: 

PCA-ADMIN> asrInitiateBundle mode=triage sr=SR_number bundleType=auto

triageサポート・バンドルが収集され、サービス・リクエストSR_numberに自動的にアタッチされます。 triageサポート・バンドルの詳細は、「トリアージ・モード」を参照してください。

ASRサービスが有効になっている場合、bundleType=autoはPhone Homeサービスを使用してバンドルをOracle Supportにアップロードします。 Phone Homeサービスの詳細については、「Oracle Auto Service RequestのPrivate Cloud Applianceの登録」を参照してください。

support-bundlesコマンドの使用

support-bundlesコマンドは、ヘルス・チェック・ステータス、コマンド出力、ログなどの診断データの様々なタイプのバンドル(モード)を収集します。 このトピックでは、使用可能なモードについて説明します。 このコマンドを使用する推奨方法は次のとおりです:

  1. triageモードを指定してデータ収集を開始し、Private Cloud Applianceの予備ステータスを理解します。

  2. triageモードの結果にNOT_HEALTHYが表示された場合は、次のいずれかを実行します:

    • time_sliceモードを使用して、タイム・スロット別にデータを収集します。 これらの結果は、ポッド名、ジョブおよびk8s_appラベルを指定することでさらに絞り込むことができます。

    • 特定のヘルス・チェッカからデータを問い合せるには、smartモードを使用します。

support-bundlesコマンドにはモード(-m)オプションが必要です。 一部のモードには、追加のオプションがあります。

次の表に、support-bundlesコマンドのすべてのモードに共通するオプションを示します。

オプション 説明 必須

-m mode

バンドルのタイプ。

はい

-sr SR_number

--sr_number SR_number

サービス・リクエスト番号。

いいえ

ほとんどのモードでは、support-bundlesコマンドは単一のアーカイブ・ファイルを生成します。 出力アーカイブ・ファイルの名前は[SR_number_]pca-support-bundle.current-time.tgzです。 SR_numberは、-srオプションを指定した場合に使用されます。 サービス・リクエストのサポート・バンドルを作成する場合は、SR_numberを指定する必要があります。

nativeモードの場合、support-bundlesコマンドはアーカイブ・ファイルのディレクトリを生成します。

アーカイブ・ファイルは、管理ノードの/nfs/shared_storage/support_bundles/に格納されます。

管理ノードへのログイン

support-bundlesコマンドを使用するには、Pacemakerリソースを実行している管理ノードにrootとしてログインします。 Pacemakerリソースを実行している管理ノードから、必要に応じてほかの管理ノードからデータを収集します。

Pacemakerリソースを実行している管理ノードがわからない場合は、管理ノードにログインし、Pacemakerクラスタのステータスを確認します。 次のコマンドは、Pacemakerクラスタ・リソースがpcamn01で実行されていることを示しています。 

[root@pcamn01 ~]# pcs status
Cluster name: mncluster
Stack: corosync
Current DC: pcamn01
...
Full list of resources:

scsi_fencing (stonith:fence_scsi): Stopped (disabled)
Resource Group: mgmt-rg
vip-mgmt-int (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-host (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ilom (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-lb (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ext (ocf::heartbeat:IPaddr2): Started pcamn01
l1api (systemd:l1api): Started pcamn01
haproxy (ocf::heartbeat:haproxy): Started pcamn01
pca-node-state (systemd:pca_node_state): Started pcamn01
dhcp (ocf::heartbeat:dhcpd): Started pcamn01
hw-monitor (systemd:hw_monitor): Started pcamn01

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

トリアージ・モード

triageモードでは、Prometheus platform_health_checkはHEALTHYステータスとNOT_HEALTHYステータスの両方で問い合せられます。 NOT_HEALTHYが見つかった場合は、time_sliceモードを使用して詳細を取得します。 

[root@pcamn01 ~]# support-bundles -m triage

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプおよびコマンドライン。

compute_node_info.json

コンピュート・ノードで実行されているポッド。

management_node_info.json

管理ノードで実行されているポッド。

rack_info.json

ラックの取り付け時間とビルド・バージョン。

loki_search_results.log.n

jsonのチャンク・ファイル。

タイム・スライス・モード

タイム・スライス・モードでは、データは開始タイムスタンプと終了タイムスタンプを指定することによって収集されます。

-jオプションまたは--allオプションを指定しない場合、データはすべての健全性チェッカ・ジョブから収集されます。

次のいずれかを指定して、データ収集を絞り込むことができます:

  • Lokiジョブ・ラベル

  • Loki k8s_appラベル

  • ポッド名

[root@pcamn01 ~]# support-bundles -m time_slice -j flannel-checker -s 2021-05-29T22:40:00.000Z \
-e 2021-06-29T22:40:00.000Z -l INFO

次のその他の例を参照してください。

support-bundlesコマンドのタイム・スライス・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

  • 指定できるのは、--job_name、--allおよび--k8s_appのいずれか1つのみです。

  • --job_name、--allまたは--k8s_appのいずれも指定されていない場合、ポッド・フィルタリングはデフォルト(.+checker)で実行されます。

  • --allオプションは大量のデータを収集できます。 タイム・スライスを48時間に制限できます。

オプション 説明 必須

-j job_name

--job_name job_name

Lokiジョブ名。 デフォルト値: .+checker

次のラベル・リスト問合せを参照してください。

いいえ
--all audit、kubernetes-audit、vault-auditおよびk8s_appラベルpcacorednsなど、ロギングが多すぎることが認識されているジョブを除くすべてのジョブ名を問い合せます。 いいえ
--k8s_app 「ラベル」

k8s-stdout-logsジョブ内で問い合せるk8s_appラベル値。

次のラベル・リスト問合せを参照してください。

 いいえ

-l level

--levelname level

メッセージ・レベル

いいえ

-s timestamp

--start_date timestamp

開始日(書式yyyy-mmm-ddTHH:mm:ss)

最小引数はyyyy-mmm-ddです

はい

-e timestamp

--end_date timestamp

yyyy-mmm-ddTHH:mm:ss形式の終了日

最小引数はyyyy-mmm-ddです

はい
--pod_name pod_name ポッドに基づいて出力をフィルタするためのポッド名(kubeやnetwork-checkerなど)。 開始文字のみが必要です。 いいえ

ラベル・リスト問合せ

ラベル・リスト問合せを使用して、使用可能なジョブ名とk8s_appラベル値をリストします。 

[root@pcamn01 ~]# support-bundles -m label_list
2021-10-14T23:19:18.265 - support_bundles - INFO - Starting Support Bundles
2021-10-14T23:19:18.317 - support_bundles - INFO - Locating filter-logs Pod
2021-10-14T23:19:18.344 - support_bundles - INFO - Executing command - ['python3', 
'/usr/lib/python3.6/site-packages/filter_logs/label_list.py']
2021-10-14T23:19:18.666 - support_bundles - INFO -
Label:  job
Values: ['admin', 'api-server', 'asr-client', 'asrclient-checker', 'audit', 'cert-checker', 'ceui', 
'compute', 'corosync', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 'flannel-checker', 
'his', 'hms', 'iam', 'k8s-stdout-logs', 'kubelet', 'kubernetes-audit', 'kubernetes-checker', 
'l0-cluster-services-checker', 'messages', 'mysql-cluster-checker', 'network-checker', 'ovm-agent', 
'ovn-controller', 'ovs-vswitchd', 'ovsdb-server', 'pca-healthchecker', 'pca-nwctl', 'pca-platform-l0', 
'pca-platform-l1api', 'pca-upgrader', 'pcsd', 'registry-checker', 'sauron-checker', 'secure', 
'storagectl', 'uws', 'vault', 'vault-audit', 'vault-checker', 'zfssa-checker', 'zfssa-log-exporter']
 
Label:  k8s_app
Values: ['admin', 'api', 'asr-client', 'asrclient-checker', 'brs', 'cert-checker', 'compute', 
'default-http-backend', 'dr-admin', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 
'flannel-checker', 'fluentd', 'ha-cluster-exporter', 'has', 'his', 'hms', 'iam', 'ilom', 
'kube-apiserver', 'kube-controller-manager', 'kube-proxy', 'kubernetes-checker', '
l0-cluster-services-checker', 'loki', 'loki-bnr', 'mysql-cluster-checker', 'mysqld-exporter', 
'network-checker', 'pcacoredns', 'pcadnsmgr', 'pcanetwork', 'pcaswitchmgr', 'prometheus', 'rabbitmq', 
'registry-checker', 'sauron-api', 'sauron-checker', 'sauron-grafana', 'sauron-ingress-controller', 
'sauron-mandos', 'sauron-operator', 'sauron-prometheus', 'sauron-prometheus-gw', 
'sauron-sauron-exporter', 'sauron.oracledx.com', 'storagectl', 'switch-metric', 'uws', 'vault-checker', 
'vmconsole', 'zfssa-analytics-exporter', 'zfssa-csi-nodeplugin', 'zfssa-csi-provisioner', 'zfssa-log-exporter']

例:

ジョブ・ラベルなし、k8s_appラベルなし、すべてのヘルス・チェッカからログを収集します。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

1ジョブの停滞。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -j ceui -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

1つのk8s_appネットワーク・チェッカ。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx --k8s_app network-checker -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

すべてのジョブと日付。

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s `date -d "2 days ago" -u +"%Y-%m-%dT%H:%M:%S.000Z"` -e `date -d +u +"%Y-%m-%dT%H:%M:%S.000Z"`

全ジョブ

[root@pcamn01 ~]# support-bundles -m time_slice -sr 3-xxxxxxxxxxx --all -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプおよびコマンドライン。

loki_search_results.log.n

jsonのチャンク・ファイル。

スマート・モード

スマート・モードでは、最近のNOT_HEALTHYステータスについてヘルス・チェッカが問い合せられます。 デフォルトでは、2日間のログが収集されます。 2日を超えるログが必要な場合は、--forceオプションを指定します。 ヘルス・チェッカを指定するには、-hcオプションを使用します。 

[root@pcamn01 ~]# support-bundles -m smart

次のその他の例を参照してください。

support-bundlesコマンドのスマート・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

開始日または終了日のみが指定されている場合、時間は計算され、指定された終了日の2日前または指定された開始日の2日後に問い合せられます。 開始日のみが指定され、2日の時間範囲内では、デフォルトの最近の異常時間が使用されます。

オプション 説明 必須

-hc health_checker_name

--health_checker health_checker_name

Lokiヘルス・チェッカ名。

次の健全性チェッカ・ログファイルの表を参照してください。

いいえ
--errors_only レベル名のフィルタリングは、エラー、クリティカルおよび重大でのみ実行されます。 いいえ
--force

開始日が2日の時間範囲制限を上書きするように強制します。

 いいえ

-s timestamp

--start_date timestamp

開始日(書式yyyy-mmm-ddTHH:mm:ss)

最小引数はyyyy-mmm-ddです

デフォルト値: 終了日マイナス2日

いいえ

-e timestamp

--end_date timestamp

yyyy-mmm-ddTHH:mm:ss形式の終了日

最小引数はyyyy-mmm-ddです

デフォルト値: 最新の異常時間

いいえ

次の表に、各ヘルス・チェッカに対するログ・ファイルを示します。

ヘルス・チェッカ サポート・ログ・ファイル

L0_hw_health-checker

  • pca.log, pca.health.log, pca.l1api.log, pacemaker.log

  • pca-platform-l1api

  • pca-healthchecker

  • pacemaker

  • pca-platform-l0

cert-checker

ログなし - 証明書と有効期限(チェッカから)のみ

etcd-checker

  • etcd-container.log

flannel-checker

k8s-stdout-logs: ポッド(flannel)、ノードおよびコンテナによるフィルタ

kubernetes-checker

k8s-stdout-logs: ポッド(kube-apiserver)、ノードおよびコンテナによるフィルタ

l0-cluster-services-checker

  • pacemaker.log, corosync.log

  • corosync

  • pcsd

mysql-cluster-checker

  • mysqld

network-checker

  • HMS

registry-checker

メッセージ(レジストリ自体はログを生成しません)

vault-checker

  • hc-vault-audit.log

  • hc-vault-audit.log

zfssa-checker

  • zfssa-checker

  • zfssa-log-exporter (ログ= alert | audit | pcalog)

例:

-hcはありません。 すべてのヘルス・チェッカから異常なデータを問い合せます。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx

-hcを使用して、1つのヘルス・チェッカを指定します。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx -hc network-checker

--forceのタイムスタンプ。 

[root@pcamn01 ~]# support-bundles -m smart -sr 3-xxxxxxxxxxx -s "2022-01-11/00:00:00" -e "2022-01-15/23:59:59" --force

出力アーカイブ・ファイルには、次のファイルがあります。

ファイル 説明

header.json

このバンドルを生成するためのタイムスタンプおよびコマンドライン。

loki_search_results.log.n

jsonのチャンク・ファイル。

ネイティブ・モード

他のサポート・バンドル・モードとは異なり、ネイティブ・バンドル・コマンドはただちに戻り、バンドル・コレクションはバックグラウンドで実行されます。 ネイティブ・バンドルでは、収集に時間がかかる場合があります。 収集の進捗情報は、バンドル・ディレクトリのnative_collection.logにあります。

また、他のサポート・バンドル・モードとは異なり、ネイティブ・バンドルの出力は単一のアーカイブ・ファイルではありません。 かわりに、バンドル・ディレクトリは管理ノードの/nfs/shared_storage/support_bundles/領域に作成されます。 このディレクトリには、native_collection.logファイルおよび多数のtar.gzファイルが含まれています。 

[root@pcamn01 ~]# support-bundles -m native -t bundle_type [-c component_name] [-sr SR_number]

support-bundlesコマンドのネイティブ・モードには、このトピックの最初にリストされているモードおよびサービス・リクエスト番号オプションに加えて、次のオプションがあります。

オプション 説明 必須

-t bundle_type

--type bundle_type

バンドル・タイプ: sosreportまたはzfs-bundle

はい

-c component_name

--component component_name

コンポーネント名

このオプションは、sosreport型にのみ適用されます。

いいえ

ZFSバンドル

typeがzfs-bundleの場合、ZFSサポート・バンドル・コレクションは両方のZFSノードで開始され、新しいZFSサポート・バンドルがバンドル・ディレクトリにダウンロードされます。 

[root@pcamn01 ~]# support-bundles -m native -t zfs-bundle
2021-11-16T22:49:30.982 - support_bundles - INFO - Starting Support Bundles
2021-11-16T22:49:31.037 - support_bundles - INFO - Locating filter-logs Pod
2021-11-16T22:49:31.064 - support_bundles - INFO - Executing command - ['python3', '/usr/lib/python3.6/site-packages/filter_logs/native.py', '-t', 'zfs-bundle']
2021-11-16T22:49:31.287 - support_bundles - INFO - LAUNCHING COMMAND: ['python3', '/usr/lib/python3.6/site-packages/filter_logs/native_app.py', '-t', 'zfs-bundle', '--target_directory', '/support_bundles/zfs-bundle_20211116T224931267']
ZFS native bundle collection running to /nfs/shared_storage/support_bundles/zfs-bundle_20211116T224931267
Monitor /nfs/shared_storage/support_bundles/zfs-bundle_20211116T224931267/native_collection.log for progress.
 
2021-11-16T22:49:31.287 - support_bundles - INFO - Finished running Support Bundles

SOSレポート・バンドル

typeがsosreportの場合、component_nameは管理ノードまたはコンピュート・ノードです。 component_nameを指定しない場合、レポートはすべての管理ノードおよびコンピュート・ノードから収集されます。 

[root@pcamn01 ~]# support-bundles -m native -t sosreport -c pcacn003 -sr SR_number

Oracleサポートへのサポート・バンドルのアップロード

「support-bundlesコマンドの使用」の説明に従ってsupport-bundlesコマンドを使用してサポート・バンドルを作成した後、このトピックで説明するメソッドを使用して、サポート・バンドルをOracleサポートにアップロードできます。

これらのメソッドを使用するには、次の要件を満たす必要があります:

  • ファイルのアップロードに使用される各サポートID (SI)の適切なカスタマ・ユーザー管理者(CUA)によって付与された、SRの作成および更新権限を持つMy Oracle SupportユーザーIDが必要です。

  • 既存のサービス・リクエストにファイルをアップロードする場合は、サービス・リクエストに関連付けられたサポートIDがプロファイルに含まれている必要があります。

  • 2 GBより大きいファイルをアップロードするには、送信マシンがFTPSおよびHTTPSを使用するには、transport.oracle.comのMy Oracle Supportサーバーに接続するためのネットワーク・アクセス権を持っている必要があります。

    Oracle FTPSサービスはパッシブ実装です。 暗黙的な構成では、初期接続はクライアントから990の制御ポート上のサービスに接続され、その後、接続は上位ポートに切り替えられてデータを交換します。 Oracleは、データ・ポート32000から42000の範囲を定義し、ネットワーク構成によっては、ポート990とポート32000から42000の両方でアウトバウンド接続を有効にする必要がある場合があります。 TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256のみが有効な暗号化メソッドです。

    Oracle HTTPS診断アップロード・サービスは、443の標準HTTPSポートを使用し、追加のポートを開く必要はありません。

    コマンドライン・プロトコルを使用する場合は、コマンドにパスワードを含めないでください。 要求された場合にのみパスワードを入力します。

  • Oracleでは、すべてのファイル転送にTLS 1.2 +を使用する必要があります。

  • 暗号化ファイルまたはパスワードで保護されたファイル(スタンドアロンまたはアーカイブ内)はアップロードしないでください。 サービス・リクエストの更新では、これは破損ファイルとして記録されるか、許可されていないファイル・タイプが見つかったためアップロードを拒否します。 FTPSおよびHTTPSを使用すると、ファイルは暗号化されます。追加の保護は必要ありません。

  • ファイル・タイプ拡張子がexe, bat, aspまたはcomのファイルは、スタンドアロンまたはアーカイブ内でアップロードしないでください。 サービス・リクエストの更新により、許可されていないファイル・タイプが見つかったことが通知されます。

ファイル2 GB以下のアップロード

My Oracle SupportポータルでSRファイル・アップロード・ユーティリティを使用します。

  1. My Oracle Supportのユーザー名とパスワードでMy Oracle Supportにログインします。

  2. 次の内の1つを実行します。

    • 新規サービス・リクエストを作成し、次のステップでアップロード・ボタンを選択します。

    • 既存のサービス・リクエストを選択して開きます。

  3. ページ上部の添付の追加ボタンをクリックします。

  4. 「ファイルの選択」ボタンをクリックします。

  5. ナビゲートして、アップロードするファイルを選択します。

  6. ファイルの添付ボタンをクリックします。

また、次のセクションで説明するメソッドを使用して、大きなファイルを作成することもできます。

GBが2つを超えるファイルのアップロード

200GBを超えるファイルはアップロードできません。 「ファイルの分割」を参照してください。

FTPS

構文:

サービス・リクエスト番号の後に/文字を含めてください。 

$ curl -T path_and_filename -u MOS_user_ID ftps://transport.oracle.com/issue/SR_number/

例:

$ curl -T /u02/files/bigfile.tar -u MOSuserID@example.com ftps://transport.oracle.com/issue/3-1234567890/

HTTPS

構文:

サービス・リクエスト番号の後に/文字を含めてください。 

$ curl -T path_and_filename -u MOS_user_ID https://transport.oracle.com/upload/issue/SR_number/

例:

$ curl -T D:\data\bigfile.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/

送信中のファイルの名前変更 

$ curl -T D:\data\bigfile.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/NotSoBig.tar

プロキシの使用 

$ curl -k -T D:\data\bigfile.tar -x proxy.example.com:80 -u MOSuserID@example.com https://transport.oracle.com/upload/issue/3-1234567890/

ファイルの分割

大きなファイルを複数のパートに分割し、パートをアップロードできます。 Oracleすべてのパートのアップロードが完了すると、トランスポートによってセグメントが連結されます。

HTTPSプロトコルのみを使用できます。 使用できるのはUNIXスプリット・ユーティリティのみです。 Microsoft Windows分割ユーティリティは、互換性のない書式を生成します。

アップロード時間を短縮するには、分割する前に元のファイルを圧縮します。

  1. ファイルを分割します。

    次のコマンドは、ファイルfile1.tarをfile1.tar.partaaおよびfile1.tar.partabという名前の2つのGB部分に分割します。

    重要:

    次に示すように、.part拡張子を正確に指定します。 

    $ split –b 2048m file1.tar file1.tar.part

  2. 結果のfile1.tar.partaaおよびfile1.tar.partabファイルをアップロードします。

    重要:

    これらの出力パート・ファイルの名前を変更しないでください。

    $ curl -T file1.tar.partaa -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/
$ curl -T file1.tar.partab -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/

  3. コマンドを送信してパーツをまとめます。

    ス・ピット・ファイルはサービス・リクエストに添付されません。 最終連結ファイルのみがサービス・リクエストに添付されます。 

    $ curl -X PUT -H X-multipart-total-size:original_size -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/file1.tar?multiPartComplete=true

    前述のコマンドで、original_sizeは、ファイル・リストに示されている元の分割されていないファイルのサイズです。

  4. 新しく添付されたファイルのサイズを確認します。

    ノート:

    この検証コマンドは、ステップ3の連結コマンドの直後に実行する必要があります。 それ以外の場合は、ファイルの処理が開始され、このコマンドで使用できなくなります。 

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/file1.tar
    X-existing-file-size: original_size

中断されたHTTPSアップロードの再開

異常終了したファイル・アップロードを再開できます。 再開はHTTPSを使用してのみ実行できます。 再開はFTPSでは機能しません。 アップロードがイベントによって中断された場合、中断されたファイルのファイル・サイズの取得から開始

  1. すでにアップロードされているファイルの量を確認します。

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar
HTTP/1.1 204 No Content
Date: Tue, 15 Nov 2022 22:53:54 GMT
Content-Type: text/plain
X-existing-file-size: already_uploaded_size
X-Powered-By: Servlet/3.0 JSP/2.2

  2. ファイルのアップロードを再開します。

    ステップ1の「X-existing-file-size」で返されるファイル・サイズに注意してください。 このファイル・サイズは、-Cスイッチの後および-H “X-resume-offset:”スイッチで使用します。 

    $ curl -Calready_uploaded_size -H "X-resume-offset: already_uploaded_size" -T myinfo.tar -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar

  3. 最終ファイル・サイズを確認します。

    $ curl -I -u MOSuserID@example.com https://transport.oracle.com/upload/issue/SR_number/myinfo.tar
-H X-existing-file-size: original_size

    前述のコマンドで、original_sizeは、ファイルのリストに示されている元のファイルのサイズです。