アプライアンス管理の概要

管理者アクセス

アプライアンス管理者は、Oracle Private Cloud Applianceの物理コンポーネントにアクセスできる高度な特権ユーザーです。アプライアンス管理者アカウントとテナンシ管理者アカウントの間に機能的な関係はありません。これらは完全に個別のエンティティです。アプライアンス管理者はテナンシを作成および削除する権限を持っている場合がありますが、そのアカウントはテナンシへのアクセス権限またはそのリソースの使用権限を付与しません。アプライアンス管理者は、ユーザー・データやインスタンスにはまったくアクセスできません。

管理機能へのアクセスは、個別のインタフェースを介して提供されます: 「サービスWeb UI」、「サービスCLI」およびService APIは、すべて高度に制限されています。管理者がアクセスできるリソースおよび機能は、「ポリシー」を使用してアクセス制御用に構成された「認可グループ」によって制御されます。詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「管理者アカウント管理」を参照してください。

アプライアンス管理者アカウントはローカルに作成できますが、Private Cloud Applianceでは既存のアイデンティティ・プロバイダとのフェデレートもサポートされるため、ユーザーは既存のIDとパスワードを使用してログインできます。アイデンティティ・プロバイダのユーザー・グループをアプライアンス管理者グループにマッピングして、各認可されたアカウントに管理者ロールが正しく割り当てられるようにする必要があります。

アプライアンス管理者アカウントでは、1つのフェデレーテッド・アイデンティティ・プロバイダがサポートされます。アイデンティティ・プロバイダとのフェデレーション信頼を確立するプロセスは、テナンシ・レベルでのアイデンティティ・フェデレーションの場合と同じです。これについては、「Identity and Access Management概要」の章を参照してください。「アイデンティティ・プロバイダによるフェデレート」の項を参照してください。

認可グループとそのポリシー

管理者として実行できる特定の機能は、ユーザーが属する「承認グループ」によって異なります。認可グループには、アクセス権を持つリソースおよび機能を定義するアクセス制御ポリシーがアタッチされています。アクセス・ポリシー(ポリシー・ステートメント)を記述する場合、リソースとファンクションを個別に定義するか、「認可ファミリ」を使用できます。

Oracle Private Cloud Applianceには3つのデフォルトの認可グループがあります:

SuperAdmin

ユーザーは、「サービス・エンクレーブ」に無制限にアクセスできます。他の管理者アカウントの設定や認可グループおよびファミリの管理など、使用可能なすべての操作を実行する権限があります。
初期

ユーザーは、「サービス・エンクレーブ」へのアクセスが制限されています。初期管理者アカウントを作成し、アプライアンスに関する情報を表示する権限はありますが、ほかのリソースへの読み取りアクセス権はありません。
Day0

ユーザーには、アプライアンスの初期設定に関連する操作への特定のアクセス権があります - プロセスは、日ゼロ構成とも呼ばれます。

追加の管理アクセスを構成する場合は、デフォルトの承認グループを使用するか、新しい承認グループを作成できます。各認可グループには、このグループに属するユーザーがリソースにアクセスできるようにするポリシー・ステートメントが少なくとも1つ必要です。ポリシー・ステートメントのない認可グループは有効ですが、そのユーザーはどのリソースにもアクセスできません。

以前のリリースからアプライアンスをアップグレードする場合、レガシー認可グループのユーザーが存在する可能性があります。これらのレガシー・グループは、アップグレード後も存在します。継続性を確保するために、アップグレード・プロセスでは、レガシー・グループのユーザーが同じレベルのアクセスを保持できるように、必要な認可ファミリおよびポリシーが作成されます。

次の表に、レガシー承認グループと、それぞれに関連付けられているアクセス権限を示します。

レガシー認可グループ	説明
管理者	「管理者」ロールは、実質的にサポートされているすべてのオブジェクト・タイプをリスト、作成、変更および削除する権限を付与します。このロールから除外された権限は: 管理者アカウントと承認グループの管理、および障害リカバリ操作。
モニター	「モニター」ロールを持つ管理者は、読取り専用コマンドを実行する権限があります。たとえば、`get` APIコールを使用すると、特定のタイプのオブジェクトをリストおよびフィルタできます。ディザスタ・リカバリ・アイテムなど、特定の機能に関連する一部のオブジェクトは、追加の権限を必要とするため除外されます。
DR管理者	DrAdminロールは、ディザスタ・リカバリに関連するすべての操作を追加して、Adminロールと同じ権限を付与します。
日ゼロ構成	Day0Configロールは、アプライアンスの初期設定に関連する操作への特定のアクセスのみを提供 - プロセスは、日ゼロ構成とも呼ばれます。システムの状態によって、このロールを持つ管理者が実行できる操作が決まります。たとえば、プライマリ管理者アカウントを作成する準備ができている場合は、その特定のコマンドのみを使用できます。その後、システム初期化データを登録する準備ができたら、それらのパラメータを設定するコマンドのみを使用できます。
内部	このロールは、内部システムで使用するために予約されています。

認可グループには、アクセス制御ポリシーが関連付けられている必要があります。認可グループの個別のポリシーを作成することも、「認可ファミリ」を使用することもできます。認可ファミリを使用すると、認可グループ間で再利用できるポリシーを作成できます。デフォルトの認可グループでは、認可ファミリを使用して作成される事前定義済ポリシーが使用されます。

ポリシー・ステートメントは、「サービスWeb UI」または「サービスCLI」から作成できます。各ポリシー・ステートメントには次のものが含まれている必要があります:

名前 - 1から255文字
アクション - 検査、読取り、使用または管理
リソース / 認可ファミリ - 1つ以上のリソースまたは1つの認可ファミリ
( 「サービスCLI」のみ)認可グループ - グループのID

次の表に、リソースに対して実行できるアクションに関する情報を示します。

アクション	アクセスのタイプ
`inspect`	リソースの一部である機密情報またはユーザー指定メタデータにアクセスせずに、リソースをリストする機能。
`read`	`inspect`に加えて、ユーザー指定のメタデータと実際のリソース自体を取得する機能が含まれます。
`use`	`read`に加えて、既存のリソースを操作する機能が含まれます。アクションはリソース・タイプによって異なります。
`manage`	リソースのすべての権限が含まれます。

認可グループおよびポリシーの作成方法について学習するには、「Oracle Private Cloud Appliance管理者ガイド」の「管理者アカウント管理」セクションの「管理者権限の管理」のトピックを参照してください。

認可ファミリ

認可グループには、ポリシー・ステートメントと呼ばれる少なくとも1つのアクセス制御ポリシーが関連付けられている必要があります。各ポリシー・ステートメントは、1つ以上のリソースに対するアクションのタイプを提供します。文内の個々のリソースをリストするか、「認可ファミリ」を使用できます。

認可ファミリを使用すると、アプライアンスの管理において論理的に意味のあるリソースと機能をグループ化できます。ポリシー・ステートメントで使用できる認可ファミリには、次の2つのタイプがあります:

「リソース・ファミリ」は、サーバー、ストレージ、ネットワーク・インフラストラクチャなどのアプライアンス・リソースを定義するために使用されます。
「機能ファミリ」は、コンパートメント、ユーザー、コンピュート管理などのアプライアンス機能を定義するために使用されます。

デフォルトの認可グループは、事前定義されたリソースおよびファンクション・ファミリをポリシー・ステートメントで使用します。次の表に、これらの事前定義済認可ファミリと、デフォルトの認可グループ・ポリシーでの使用方法を示します。

承認ファミリ名	承認ファミリ・タイプ	ポリシーで使用。	グループ内のユーザーは...
Day0	機能ファミリ	SuperAdmin認可グループ	Day0システム、静的ルーティング、動的ルーティング、およびネットワーク・パラメータを設定 ILOMから管理ノード、コンピュート・ノード、およびZFSの健全性を取得アプライアンスのロック解除とロック
初期	機能ファミリ	初期認可グループ	初期管理アカウントの作成
SuperAdmin	機能ファミリ	SuperAdmin認可グループ	すべてのアプライアンス機能の管理
Day0	リソース・ファミリ	SuperAdmin認可グループ	システム情報およびネットワーク構成の読み取り
初期	リソース・ファミリ	初期認可グループ	システム情報の読み取り
SuperAdmin	リソース・ファミリ	SuperAdmin認可グループ	アプライアンスのすべてのリソースの管理

認可ファミリの作成方法について学習するには、「Oracle Private Cloud Appliance管理者ガイド」の「管理者アカウント管理」セクションの「管理者権限の管理」のトピックを参照してください。

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

システムの全体的なヘルス・ステータスは、ハードウェアおよびプラットフォーム・レイヤーからのリアルタイム・データを使用して継続的に監視されます。システム・ヘルス・チェックおよびモニタリング・データは、問題検出の基盤です。異常な状態が見つかると、管理者はこの情報を使用してトラブルシューティングを開始します。必要に応じて、問題の解決を支援するためにサービス・リクエストをOracleに登録します。 Private Cloud ApplianceがOracle Auto Service Request (ASR)に登録されている場合、特定のハードウェア障害によって、サービス・リクエストおよび診断データがOracleサポートに自動的に送信されます。

モニタリング

管理者は、組み込みの健全性検査とは別に、いつでもモニタリング・データを参照して、システム全体のステータスや、特定のコンポーネントやサービスの状況を確認できます。これは、Prometheusに格納されているシステム全体のメトリック・データを問い合せることによって、Grafanaインタフェースを介して実行されます。

Grafanaは、モニタリングに対する視覚的なアプローチを提供: 複数のビジュアライゼーション・パネルで構成されるダッシュボードを作成できます。各パネルは、選択した形式で表示される単一のメトリック問合せまたはメトリック問合せの組合せに対応します。オプションには、グラフ、表、チャート、図、ゲージなどが含まれます。メトリック・パネルごとに、しきい値を定義できます。問合せ結果が特定のしきい値を上回ったり下がったりすると、表示色が変わり、どの要素が正常であるか、調査が必要であるか、または機能不全であるかがすばやくわかります。

Oracleには事前定義済のダッシュボードのセットが用意されており、管理者はシステムの起動および実行直後にシステムのモニタリングを開始できます。デフォルトのモニタリング・ダッシュボードは、次のカテゴリにグループ化されます:

モニタリング・ダッシュボード・セット	説明
サービス・アドバイザ	Kubernetesコンテナ・オーケストレーション環境、ホストするコンテナ化されたサービス、およびシステム・ヘルス・チェック・サービスをモニタリングするためのアプライアンス固有のダッシュボード・コレクション。
サービス・レベルのモニタリング	すべてのマイクロサービスの統計データを提供する、ダッシュボードの読取り専用コレクション。
Kubernetesモニタリング	Oracleクラウド・ネイティブ・モニタリングおよびビジュアライゼーションの専門家が提供するダッシュボードの追加コレクション。これらは、Kubernetesクラスタとそのサービスに関する膨大な詳細情報を提供します。

デフォルトのダッシュボードには、システムの物理コンポーネントのメトリック・データが含まれます - サーバー、スイッチ、ストレージ・プロバイダ、およびそのオペレーティング・システムとファームウェア - 論理コンポーネント - コントローラ・ソフトウェア、プラットフォーム、Kubernetesクラスタとマイクロサービス、コンピュート・インスタンスとその仮想化リソース。これにより、管理者またはサポート・エンジニアは、両方のコンポーネント・カテゴリのヘルス・ステータスを個別に検証し、それら間の相関関係を検索できます。たとえば、使用可能なメモリーがないため、特定のマイクロサービスのパフォーマンスが低下する場合があります。モニタリング・データは、これがシステム構成の問題、物理リソースの不足、またはハードウェア障害の兆候であるかどうかを示します。モニタリング・システムには、ハードウェアの障害を検出して報告できるアラート・サービスがあります。管理者はオプションで、モニタリング・システムで定義されたルールに基づいてアラートを受信するように通知チャネルを構成できます。

サービスおよびサポート操作の一部として、Oracleによって、デフォルトのダッシュボードに表示される特定のメトリック・データのレポートが求められる場合があります。このため、デフォルトのダッシュボード構成は常に保持する必要があります。ただし、モニタリング機能の一部が誤って変更または壊れている場合は、デフォルトをリストアできます。同様に、Oracleでは、新しいダッシュボードを作成したり、モニタリングを改善するために既存のダッシュボードを変更したり、正式なアップグレード手順を必要とせずに操作環境にプッシュできます。

ここで説明するオープン・ソースのモニタリング・ツールおよびロギング・ツールにはすべて、お客様が既存のヘルス・モニタリング・システムおよびアラート・システムと統合できるパブリックAPIがあります。ただし、Oracleでは、このようなカスタム構成はサポートされていません。

フォルト・ドメインの可観測性

アプライアンス・インフラストラクチャ、コンピュート・インスタンスおよび関連するリソースを正常なヘルスで稼働させることに関しては、「フォルト・ドメイン」は非常に重要な概念です。障害またはメンテナンスによるダウンタイム・イベントを分離することを目的とした一連のインフラストラクチャ・コンポーネントをグループ化し、他のフォルト・ドメインのリソースに影響を与えないようにします。

Oracle Cloud Infrastructureに沿って、Private Cloud Applianceには常に3つの障害ドメインがあります。その各フォルト・ドメインは、1つ以上の物理コンピュート・ノードに対応しています。 Grafanaを使用してシステム全体のデータをモニタリングすること以外に、管理者はサービス・エンクレーブから直接フォルト・ドメインの主要な容量メトリックにアクセスすることもできます:

フォルト・ドメイン当たりのコンピュート・ノード数
フォルト・ドメイン当たりの合計および使用可能なRAMの量
フォルト・ドメイン当たりの合計および使用可能なvCPUs数
未割当てのシステムCPUおよびRAM容量

フォルト・ドメイン・メトリックは、コンピュート・ノードでホストされているコンピュート・インスタンスで消費できる実際の物理リソースを反映しています。合計には、ハイパーバイザの操作用に予約されたリソースは含まれません: 40GB RAMおよび4 CPUコア(8 vCPUs)。

3つのフォルト・ドメインに加えて、「サービスCLI」には「未割当て」カテゴリが表示されます。これは、プロビジョニングされていないためにまだフォルト・ドメインの一部ではないインストール済コンピュート・ノードを参照します。割り当てられていないコンピュート・ノードの場合、メモリー容量は計算できませんが、CPUメトリックが表示されます。

システム・ヘルス・チェック

ヘルス・チェックは最も基本的な検出形式です。これらは、通常のUNIX cronジョブに非常に似ているKubernetes CronJobサービスとして定期的に実行されます。ステータス・エントリは、ヘルス・チェック結果ごとに作成され、常に2つの可能性のうちの1つになります: 健康なまたは健康ではない。すべてのステータス情報は、Prometheusでさらに処理するために格納されます。異常な結果では、トラブルシューティング・プロセスの進行に役立つ詳細とともにLokiにログ・エントリも生成されます。

ヘルス・チェックは、特定のシステム・コンポーネントのステータスを検証し、ステータスの変更を検出するためのものです。各ヘルス・チェック・プロセスは、同じ基本原則に従います: 現在の条件を記録し、予想結果と比較します。一致した場合、ヘルス・チェックは合格します。異なる場合、ヘルス・チェックは失敗します。ステータスが正常から「健康ではない」に変更された場合、トラブルシューティングが必要であることを示します。

トラブルシューティングのために、自由に使用できる主要なデータ・ソースが2つあります: ログおよびメトリック。両方のカテゴリのデータがシステム全体から収集され、中央のロケーションに格納されます: ログはLokiに集計され、メトリックはPrometheusに集計されます。どちらのツールにも、データのフィルタ処理およびビジュアル化を可能にする問合せインタフェースがあります: 両方ともGrafanaと統合されています。ブラウザベースのインタフェースには、「サービスWeb UI」からアクセスできます。

ヘルス・チェックの失敗の原因を調査するために、失敗のタイプに基づいてログおよびメトリック・データをフィルタ処理するのに役立ちます。 Lokiは、ラベル付けシステムを使用してデータを分類し、選択したログ・ラベルに一致するログ・メッセージを表示します。リストからラベルを選択して、関心のあるサービスまたはアプリケーションのログを表示します。このリストでは、ヘルス・チェックだけでなく、内部および外部アプライアンス・サービスも選択できます。

また、各ヘルス・チェックの最新ステータスは、デフォルトでGrafanaで提供されるサービス・アドバイザ・ダッシュボード・セットの一部であるプラットフォーム・ヘルス・チェック・ダッシュボードに表示されます。

Private Cloud Applianceは、次に示すヘルス・チェックを実行します。

ヘルス・チェック・サービス	説明
cert-checker	証明書が期限切れでないことを各管理ノードで検証します。
flannel-checker	Flannelコンテナ・ネットワーク・サービスが各Kubernetesノードで完全に動作していることを確認します。
kubernetes-checker	Kubernetesノードおよびポッドのヘルス・ステータス、およびコンテナ化されたサービスとその接続エンドポイントを検証します。
mysql-cluster-checker	MySQLクラスタ・データベースのヘルス・ステータスを確認します。
l0-cluster-services-checker	低レベルのクラスタリング・サービスおよびハードウェアおよびプラットフォーム・レイヤー内の主要な内部コンポーネント(プラットフォームAPI、DHCPなど)が完全に動作していることを確認します。
network-checker	システム・ネットワーク構成が正しいことを確認します。
registry-checker	コンテナ・レジストリが各管理ノードで完全に動作していることを確認します。
vault-checker	各管理ノードでシークレット・サービスが完全に動作していることを確認します。
etcd-checker	etcdサービスが各管理ノードで完全に動作していることを確認します。
zfssa-analytics-exporter	ZFS Storage Applianceクラスタのステータス、アクティブな問題、および管理パスの接続情報を報告します。また、構成可能なデータセットのリストのアナリティクス情報も報告します。

集中ロギング

このプラットフォームは、システム全体で統合ロギングを提供します。 Fluentdデータ・コレクタは、システム全体のコンポーネントからログを取得し、それらをアプライアンスのテレメトリ・データとともに中央のロケーションに格納します。その結果、必要なトラブルシューティングおよびデバッグ情報はすべて1つのデータ・ストアで保持されるため、問題を調査する必要がある場合、様々なソースから収集する必要はありません。システムの全体的なヘルスは、Grafanaダッシュボードという1つのビューで取得されます。つまり、管理者が個々のコンポーネントを確認する必要はありません。

Oracleの支援を必要とする問題が見つかった場合は常に、管理者がサービス・リクエストをログに記録します。サポート・バンドルは通常、そのプロセスの一部としてリクエストされます。一元的なロギングのおかげで、サポート・バンドルは生成が簡単で、システム操作が重大な危険にさらされていても可能なままです。サポート・バンドルの生成は、単一の圧縮アーカイブ・ファイルを生成するスクリプト化された操作です。管理者は、統合ログおよびその他の診断データを含むアーカイブ・ファイルを手動でアップロードする必要があります。

Private Cloud ApplianceがASRに登録されている場合、特定のハードウェア障害によって、サービス・リクエストおよび診断データがOracleサポートに自動的に送信されます。

アップグレード

Private Cloud Applianceのコンポーネントのアップグレードは、アプライアンス管理者の責任です。システムには、アップグレード前のアプライアンスの状態を検証し、各個々のタスクを開始し、完了するまで進行状況を追跡するワークフローとしてアップグレード手順を実行するためのフレームワークが用意されています。すべてのシステム・レベルで冗長性が組み込まれているため、アプライアンス・コンポーネントは、運用環境にサービスを停止することなくアップグレードできます。

アップグレードのソース・コンテンツ - パッケージ、アーカイブ、デプロイメント・チャートなど - ISOイメージを介して提供されます。アップグレード環境の準備中に、ISOイメージが共有ストレージにダウンロードされ、アップグレーダ自体がISOに含まれる最新バージョンにアップグレードされます。この段階で、アプライアンスはアップグレードを適用する準備ができています。

管理者は、「サービスWeb UI」または「サービスCLI」を使用してアップグレードを実行でき、2つの使用可能なオプションのいずれかを選択する必要があります: 個々のコンポーネントのアップグレードまたはフル管理ノードのクラスタのアップグレード。

事前チェック

すべてのアップグレード操作の前に検証プロセスが表示され、システム・コンポーネントがアップグレードする適切な状態になっていることが確認されます。これらの事前チェックでは、アップグレード・メカニズムはプラットフォーム・レベルのヘルス・チェックに依存します。モニタリングのためにヘルス・チェックが継続的に実行されますが、アップグレード操作の前に特に実行する必要があります。管理者は、事前チェックを手動で実行する必要はありません。アップグレード・コマンドを入力すると、アップグレード・コードによって実行されます。単一コンポーネント・アップグレードが選択されている場合でも、すべてのチェックでアップグレードの開始を許可する必要があります。

アップグレード手順によっては、管理者が最初にプロビジョニング・ロックとメンテナンス・ロックを設定する必要があります。ロックがアクティブである間、プロビジョニング操作やその他の競合するアクティビティは発生しません。つまり、アップグレード・プロセスは潜在的な中断から保護されます。アップグレードが完了したら、メンテナンス・ロックおよびプロビジョニング・ロックを解放して、システムがフル操作モードに戻る必要があります。

単一コンポーネントのアップグレード

Private Cloud Applianceアップグレードはモジュール化するように設計されているため、システム全体ではなく個々のコンポーネントを一度にアップグレードできます。単一コンポーネントのアップグレードでは、次のコンポーネント・オプションを使用できます:

ILOMファームウェア

このオプションを使用して、アプライアンス内の特定のサーバーのOracle Integrated Lights Out Manager (ILOM)ファームウェアをアップグレードします。ファームウェアが正常にアップグレードされると、ILOMが自動的にリブートされます。ただし、すべての変更を有効にするには、管理者が手動でサーバーを再起動する必要があります。
スイッチ・ファームウェア

スイッチの動作ソフトウェアをアップグレードするには、このオプションを使用します。アップグレードするスイッチ・カテゴリを指定する必要があります: リーフ・スイッチ、スパイン・スイッチ、または管理スイッチ。
ZFS Storage Applianceファームウェア

このオプションを使用して、ZFS Storage Applianceのオペレーティング・ソフトウェアをアップグレードします。アクティブ/アクティブのクラスタ構成で動作する両方のコントローラは、同じプロセスの一部としてアップグレードされます。
ホスト・オペレーティング・システム

このオプションを使用して、管理ノードのOracle Linuxオペレーティング・システムをアップグレードします。選択した管理ノードでyumアップグレードをトリガーし、ISOイメージを介して移入されたyumリポジトリを使用するように構成されます。
クラスタMySQLデータベース

すべての管理ノードでMySQLデータベースをアップグレードするには、このオプションを使用します。データベースのインストールはrpmベースであるため、ISOイメージを介して移入されるyumリポジトリに依存します。データベースのアップグレードのタイミングは重要であるため、データベースのパッケージは意図的にホスト・オペレーティング・システムのアップグレードから除外されます。データベース・アップグレード・ワークフローは、バックアップ操作およびクラスタ状態を管理し、関連するサービスを停止および再起動します。これにより、すべてのステップが各管理ノードで正しい順序で実行されます。
Kubernetesクラスタ

このオプションを使用して、サービスがデプロイされるコンテナ・オーケストレーション環境であるKubernetesクラスタをアップグレードします。 Kubernetesクラスタは、すべての管理ノードおよびコンピュート・ノードで実行されます。アップグレードには、次の3つの主要な操作が含まれます:
- Kubernetesパッケージおよびすべての依存関係のアップグレード: kubeadm、kubelet、kubectlなど。
- Kubernetesコンテナ・イメージのアップグレード: kube-apiserver、kube-controller-manager、kube-proxyなど。
- 非推奨のKubernetes APIおよびサービスYAMLマニフェスト・ファイルを更新しています。
シークレット・サービス

すべての管理ノードでシークレット・サービスをアップグレードするプロセスは、2つの部分で構成されます。これには、2つの主要なシークレット・サービス・コンポーネントのローリング・アップグレードが含まれます: etcdキー・バリュー・ストアとボールト・シークレット・マネージャ。両方とも、ポッドマン・レジストリで入手できる新しいイメージ・ファイルを使用して、特別な順序ではなく互いに独立してアップグレードされます。
プラットフォーム・サービス

このオプションを使用して、管理ノードのKubernetesクラスタ内で実行されているコンテナ化されたサービスをアップグレードします。サービス・アップグレードのメカニズムは、パッケージ・マネージャと同等のKubernetesであるHelmに基づいています。アップグレードが必要なサービスの場合、新しいコンテナ・イメージおよびHelmデプロイメント・チャートはISOイメージを介して提供され、内部レジストリにアップロードされます。この時点までのいずれの操作も、操作環境には影響しません。

プラットフォーム・レベルでは、サービスを実行するポッドを再起動することでアップグレードがトリガーされます。新しいデプロイメント・チャートが検出され、再起動時にポッドが新しいコンテナ・イメージを取得します。問題が見つかった場合は、サービスを前の作業バージョンのイメージにロールバックできます。

ノート:

特定の状況では、オプションのJSON文字列をコマンドに追加することで、特定のプラットフォーム・サービスを個別にアップグレードできます。このオプションは、Oracleで明示的な手順が提供されないかぎり使用しないでください。
コンピュート・ノード

このオプションを使用して、コンピュート・ノードでOracle Linuxオペレーティング・システムのyumアップグレードを実行します。アップグレードには、仮想マシン操作およびハイパーバイザ機能を最適化するためのアプライアンス固有のコードを含むovm-agentパッケージが含まれます。コンピュート・ノードを1つずつアップグレードする必要があります。同時にアップグレード操作を行うことはできません。

完全管理ノード・クラスタのアップグレード

個々のコンポーネントのアップグレードは、主に自己完結型です。完全な管理ノード・クラスタ・アップグレードは、これらのコンポーネント・アップグレードをグローバル・ワークフローに統合して、事前定義された順序でコンポーネント・アップグレードを実行します。単一のコマンドで、クラスタ内の3つの管理ノードはすべて、コンポーネントごとに順次アップグレードされます。これは、グローバル・ワークフローが次のコンポーネント・アップグレードに移動する前に、3つの管理ノードのそれぞれで特定のコンポーネントのアップグレードが実行されることを意味します。

コンポーネントがアップグレードされる順序は、依存関係のために事前定義されており、変更することはできません。完全な管理ノード・クラスタのアップグレード中に、次のコンポーネントがアップグレードされます:

管理ノードのホスト・オペレーティング・システム
クラスタ化されたMySQLデータベース
シークレット・サービス
Kubernetesクラスタ
プラットフォーム・サービス

パッチ適用

パッチ適用とは、通常の製品リリースとは関係なく、セキュリティ強化および機能更新をPrivate Cloud Applianceに適用する機能です。パッチは、Unbreakable Linux Network (ULN)上の一連の専用チャネルを介してRPMパッケージとして提供されます。これらのチャネルにアクセスするには、カスタマ・サポートID (CSI)およびULNサブスクリプションが必要です。

アプライアンスは、Oracle ULNサーバーに直接接続することはできません。サポートされているプロセスは、データセンター内のシステムでULNミラーを設定することです。次に、パッチ・チャネルはULNミラー上で同期され、管理ノードがRPMにアクセスできます。コンピュート・ノードにはRPMのサブセットへのアクセス権が必要です。RPMは内部共有ストレージ上の指定されたロケーションにコピーされ、最新の状態に保たれます。

パッチは、アップグレードと同様のメカニズムを使用してインストールされます。主な違いは、パッチ適用コマンドにULNミラーへのパスが含まれていることです。「サービスCLI」は、サポートされているコンポーネント・タイプごとに個別のパッチ・コマンドを提供します。「サービスWeb UI」では、管理者は特定のコンポーネント・タイプのアップグレード・リクエストを作成し、アップグレードではなく「パッチ」オプションを選択してパッチを適用します。

ULNパッチは、従来の製品リリースの一部である任意のコンポーネント・タイプに対して配信できます: 管理およびコンピュート・ノード、プラットフォームの更新、マイクロサービスの更新、ファームウェアの更新、コンピュート・イメージの更新などに対するオペレーティング・システムの更新。

詳細およびステップの詳細は、「Oracle Private Cloud Applianceパッチ適用ガイド」を参照してください

バックアップおよびリストア

統合されたPrivate Cloud Applianceバックアップ・サービスは、データ損失および破損からシステム構成を保護することを目的としています。顧客環境のバックアップは作成されませんが、かわりにシステムおよびサービスの操作に必要なデータの格納に向けて準備されているため、重要なサービスまたはコンポーネントは、最後の既知の正常なヘルスにリストアできます。マイクロサービス・ベースのデプロイメント・モデルに従って、バックアップ・サービスはシステム全体で様々なバックアップ操作を編成し、データの一貫性と整合性を保証しますが、個々のコンポーネントのバックアップ要件を定義しません。そのロジックは、コンポーネント・バックアップ・プラグインの一部です。

バックアップ・プラグインは、特定のシステム・コンポーネントまたはサービスに対してバックアップする必要があるファイル、およびデータの収集方法を決定するキー要素です。たとえば、単純なファイル・コピーは、他のデータにスナップショットが必要なときに特定のファイルに対して動作する場合や、バックアップを作成できるようにサービスを停止する必要がある場合があります。プラグインは、バックアップの頻度と保存時間も決定します。各プラグインは、アクティブなプラグインを認識し、必要なバックアップ操作をKubernetes CronJobsと同じ方法でスケジュールできるように、バックアップ・サービスに登録されます。プラグインはバックアップ・プロファイルに集約されます。バックアップ・プロファイルは、バックアップ・ジョブの起動時にバックアップ・サービスが実行するタスク・リストです。

その後、プラグインを通じて収集されたバックアップ・データは、バックアップ・サービスによって内部ZFS Storage Appliance上の専用のNFS共有に格納され、ZFS暗号化を使用して保存中のデータがセキュアになります。必要に応じて、バックアップ・ファイルを外部ストレージのロケーションにレプリケートすることもできます。

バックアップからサービスまたはコンポーネントをリストアする場合、サービスはプラグインによって提供されるロジックにもう一度依存します。コンポーネントのリストア・プロセスには、2つの主なフェーズがあります: 検証およびデータ管理。検証フェーズでは、バックアップがコンポーネントの現在の条件に対する完全性と妥当性について評価されます。次に、データ管理フェーズ中に、コンポーネントの停止または一時停止、データの置換、通常の操作の再起動または再開に必要なアクションが実行されます。バックアップと同様に、データをリストアする操作は問題のコンポーネントに固有です。

デフォルトのバックアップおよびリストア実装では、MySQLクラスタ・データベース、ZFS Storage Appliance構成、ストレージ・アプライアンス上のZFSプロジェクトのスナップショット、および登録されているすべてのコンポーネント・バックアップ・プラグインをカバーするグローバル・バックアップ・プロファイルを実行します。デフォルト・プロファイルは、毎日UTCの午前0時に実行され、14日間の保存ポリシーがあります。バックアップは/nfs/shared_storage/backups/backup_*に格納されます。すべてのリストア操作は、コンポーネントごとに手動で実行する必要があります。

ノート:

Private Cloud Applianceのリリース3.0.1では、バックアップおよびリストア・サービスは「サービスWeb UI」または「サービスCLI」では使用できません。これは、管理者がバックアップ・スケジュールを構成できないことも意味します。

現在、バックアップ・プラグインに基づいた自動リストア操作は実行できません。バックアップからの手動リストアが必要な場合は、Oracleにお問い合せください。

障害時リカバリ

ディザスタ・リカバリの目的は、インストール・サイトのレベルで高可用性を提供し、Private Cloud Applianceでホストされているクリティカルなワークロードを停止およびデータ損失から保護することです。実装には、異なるサイトに2つのPrivate Cloud Applianceシステムをインストールし、Oracle Site Guardを使用してOracle Enterprise Managerインストールを実行する3番目のシステムが必要です。

2つのPrivate Cloud Applianceシステムはどちらも完全に動作する環境ですが、同時に相互のレプリカとして構成されます。 2つのピアZFS Storage Appliance間の専用ネットワーク接続 - 各ラックに1つ - 5分間隔で信頼性の高いデータ・レプリケーションを実現します。いずれかの環境でインシデントが検出された場合、Oracle Site Guardのロールは、操作計画と呼ばれるフェイルオーバー・ワークフローを実行することです。

障害リカバリの設定は、アプライアンス管理者またはOracleエンジニアの責任です。関連するすべてのシステムを相互接続し、両方のPrivate Cloud ApplianceシステムでOracle Site Guard操作計画およびレプリケーション設定を構成します。管理者は、2つのアプライアンスの「サービスCLI」を使用して「DR構成」を作成および管理することによって、障害リカバリ制御下にあるワークロードおよびリソースを決定します。

DR構成はコア要素です。管理者は、重要なコンピュート・インスタンスをサイトレベルのインシデントから保護できるように、DR構成に追加します。ストレージおよびネットワーク接続情報は、DR構成に含まれる各インスタンスに対して収集および格納されます。 DR構成を作成すると、ピアZFS Storage Applianceへのレプリケーション用に専用のZFSプロジェクトが設定され、関連するコンピュート・インスタンス・リソースがデフォルトのストレージ・ロケーションからこの新しいZFSプロジェクトに移動されます。 DR構成はいつでもリフレッシュして、含まれているインスタンスに対して発生した可能性のある変更を取得できます。

次に、サイト・マッピングの詳細がDR構成に追加されます。関連するすべてのコンパートメントおよびサブネットは、レプリカ・システム上の対応するコンパートメントにマップする必要があります。 DR構成は、コンパートメント階層とネットワーク構成が両方のPrivate Cloud Applianceシステムに存在しないかぎり機能しません。

インシデントが発生すると、フェイルオーバー操作が起動され、レプリカ・システムの障害時リカバリ制御下にインスタンスが起動されます。このフェイルオーバーは粒度ではなく、次のステップを含むサイト全体のプロセスです:

サイト・レベルのインシデントにより、実行中のインスタンスが突然失敗します。正常に停止することはできません。
プライマリおよびレプリカZFS Storage Applianceのロールを元に戻します。
プライマリ・システムの影響を受けるコンピュート・インスタンスをレプリカ・システムで起動することでリカバリします。
プライマリ・システムのクリーン・アップ: 停止したインスタンスの削除、凍結されたDR構成など。
ZFSプロジェクトおよびインスタンス・メタデータに基づいて、リバースDR構成を設定します。

フェイルオーバーは、中断を伴うインシデントがインストール・サイトの1つで検出される結果です。ただし、Oracle Site Guardではスイッチオーバーもサポートされており、これは事実上同じプロセスですが、管理者によって手動でトリガーされます。制御されたスイッチオーバー・シナリオでは、データの損失や破損を回避するために、プライマリ・システムで実行中のインスタンスを安全に停止することがプロセスの最初のステップです。スイッチオーバーは通常、計画メンテナンスまたはテストに使用されます。フェイルオーバーまたはスイッチオーバーの後、両方のサイトが完全に動作している場合は、2つのPrivate Cloud Applianceシステムを元の構成に戻すためにフェイルバックが実行されます。

保守性

保守性とは、運用システムで発生する問題を検出、診断および修正する機能です。主な要件は、システム・データの集まりです: 一般的なハードウェア遠隔測定の詳細、すべてのシステム・コンポーネントのログファイル、およびシステムや構成の健全性検査の結果。モニタリング、システム・ヘルスおよびロギングの詳細は、「ステータスおよびヘルス・モニタリング」を参照してください。

Private Cloud Applianceは、エンジニアド・システムとして、構造化された方法で収集されたデータを処理するように設計されています。リアルタイムのステータス情報を提供するために、システムはPrometheusを使用して、すべてのコンポーネントおよびサービスからメトリック・データを一元的に収集および格納します。 Prometheusの一元的に集計されたデータは、Grafanaダッシュボードのメトリック・パネルを介してビジュアル化されます。これにより、管理者はシステム全体のステータスを一目で確認できます。ログは、Fluentdを使用してアプライアンス全体で取得され、診断目的でLokiに収集されます。

コンポーネント・ステータスが正常から正常に変わったら、サービス・ワークフローを開始する通知を送信するようにアラート・メカニズムを構成できます。 Oracleのサポートが必要な場合、最初のステップは、管理者がサービス・リクエストを開き、問題の説明を入力することです。

Private Cloud ApplianceがASRに登録されている場合、特定のハードウェア障害によって、サービス・リクエストおよび診断データがOracleサポートに自動的に送信されます。診断データの収集は、サポート・バンドルとも呼ばれます。「サービス・エンクレーブ」管理者は、サービス・リクエストおよびサポートする診断データをASRとは別に作成および送信することもできます。 ASRおよびサポート・バンドルの詳細は、「Oracle Private Cloud Appliance管理者ガイド」の「ステータスおよびヘルス・モニタリング」を参照してください。

報告された問題を解決するには、Oracleでアプライアンス・インフラストラクチャへのアクセスが必要になる場合があります。このため、システムの初期化中に専用サービス・アカウントが構成されます。セキュリティ上の理由から、このroot以外のアカウントにはパスワードがありません。エンジニアがシステムにかわって作業できるように、サービス・キーを生成して指定する必要があります。サービス・アカウントに関連するアクティビティが監査証跡から離れ、他のユーザー・アクティビティから明確に分離されます。

Oracleエンジニアド・システムのほとんどのサービス・シナリオは、割り当てられたフィールド・エンジニアが実行する詳細なアクション・プランによって説明されています。問題が解決された場合、またはコンポーネントが修復または交換された場合、エンジニアは、サービス・リクエストがクローズされる前に、システムが再度健全であることを検証します。

問題の検出、診断および解決へのこの構造化されたアプローチにより、最低限の運用上の影響、遅延およびコスト、および最大限の効率性で高品質のサービスが配信されます。