このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

第3章アプライアンス管理の概要

アプライアンス・インフラストラクチャは、クラウド・リソースが作成および管理されるワークスペースから安全に分離されるシステム領域から制御されます。この管理領域は「サービス・エンクレーブ」と呼ばれ、権限のある管理者のみが使用できます。この章では、管理者がサービス・エンクレーブにアクセスする方法と、アプライアンスを構成して最適な動作状態を維持するために使用できる機能と機能について説明します。

3.1 管理者アクセス

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

管理機能へのアクセスは、個別のインタフェースを介して提供されます: サービスWeb UI、サービスCLIおよびサービスAPI。これらはすべて非常に制限されています。管理機能には、ハードウェア管理、テナンシ管理、システムおよびコンポーネントのアップグレード、システムのバックアップとリストア、モニタリングなどがあります。インフラストラクチャ管理者には、次に示す1つ以上のロールがあります:

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

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

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

3.2 高可用性

Oracle Engineered Systemsは、シングル・ポイント障害を取り除くために構築されており、ハードウェアまたはソフトウェアの障害発生時だけでなく、アップグレードおよびメンテナンス操作時にも、システムおよびホストされるワークロードが動作し続けることができます。 Oracle Private Cloud Applianceには、すべてのレベルでアーキテクチャに組み込まれた冗長性があります: ハードウェア、コントローラ・ソフトウェア、マスター・データベース、サービスなど。バックアップ、自動化されたサービス・リクエスト、オプションのディザスタ・リカバリなどの機能により、システムの保守性とサービスの継続性がさらに向上します。

3.2.1 ハードウェアの冗長性

最小の基本ラック構成には、1つの要素の障害がシステム全体の可用性に影響しないように、冗長ネットワーク、ストレージおよびサーバー・コンポーネントが含まれています。

システム全体のデータ接続は、リーフ・スイッチとスパイン・スイッチの冗長ペアに基づいて構築されます。リンクアグリゲーションはすべてのインタフェース上で構成されます: スイッチ・ポート、ホストNIC、およびアップリンク。リーフ・スイッチは、クロス配線を使用して、各コンポーネントの冗長ネットワーク・インタフェースにラック・コンポーネントを相互接続します。各リーフ・スイッチには、各スパイン・スイッチへの接続もあります。スパイン・スイッチも相互接続されます。スパイン・スイッチは、ネットワークのバック・ボーンを形成し、ラック外部からのトラフィックを有効にします。データセンター・ネットワークへのアップリンクは、2つの冗長ToR (ラックのトップ)スイッチにクロス・コネクトされる2つのケーブル・ペアで構成されます。

コントローラ・ソフトウェアおよびシステムレベルのサービスを実行する管理クラスタは、3つの完全アクティブ管理ノードで構成されます。インバウンド・リクエストは管理ノード・クラスタの仮想IPを通過し、ロード・バランサによって3つのノードに分散されます。ノードの1つが応答を停止し、クラスタからフェンスした場合、ロード・バランサは、障害の発生したノードが再び正常なヘルスになるまで、残りの2つのノードにトラフィックを送信し続けます。

システムおよび環境内のクラウド・リソースのストレージは、内部ZFS Storage Applianceによって提供されます。その2つのコントローラはアクティブ/アクティブ・クラスタを形成し、同時に高可用性と優れたスループットを実現します。 ZFSプールは、最適なデータ保護のためにミラー化された構成のディスク上に構築されます。これは、標準の大容量ディスク・トレイと、オプションのSSDベースの高性能トレイに適用されます。

3.2.2 システム可用性

アプライアンス・コントローラ・ソフトウェアおよびサービス・レイヤーは、3ノード管理クラスタにデプロイされ、クラスタ設計に固有の高可用性を利用します。 Kubernetesコンテナ・オーケストレーション環境では、独自のコントローラ・ノードと、それがホストするサービス・ポッドの両方にクラスタリングが使用されます。マイクロサービスの複数のレプリカはいつでも実行されています。ノードとポッドは管理ノードに分散され、Kubernetesにより、失敗したポッドが新しいインスタンスで置き換えられ、すべてのサービスがアクティブ/アクティブ設定で実行されるようにします。

すべてのサービスおよびコンポーネントは、共通の中央データベースにデータを格納します。 3つの管理ノード間でインスタンスがデプロイされたMySQLクラスタ・データベースです。可用性、ロード・バランシング、データ同期およびクラスタリングはすべて、MySQLクラスタの内部コンポーネントによって制御されます。

システム・レベルのインフラストラクチャ・ネットワーキングの重要な部分は、VCNおよびインスタンス・レベルのすべての仮想ネットワーキングと同様に、ソフトウェアによって定義されます。仮想スイッチ、ルーター、およびゲートウェイの構成は、スイッチによって格納および管理されませんが、ネットワークアーキテクチャの複数のコンポーネントに分散されます。ネットワーク・コントローラは、高可用性コンテナ化されたサービスとしてデプロイされます。

アップグレード・フレームワークは、ハードウェアの冗長性およびクラスタ化された設計を利用して、すべてのコンポーネントのローリング・アップグレードを提供します。基本的に、1つのコンポーネント・インスタンスのアップグレード中、残りのインスタンスによって停止時間がなくなります。アップグレードは、すべてのコンポーネント・インスタンスがアップグレードされて通常の操作に戻ると完了します。

3.2.3 コンピュート・インスタンスの可用性

コンピュート・ノードの障害によりコンピュート・インスタンスが停止すると、システムはホスト・コンピュート・ノードが通常の操作に戻ったときに、コンピュート・インスタンスを自動的にリカバリしようとします。自動リカバリが失敗した場合、インスタンスを手動で再起動する必要があります。インスタンスは、最初のホスト・コンピュート・ノードでインスタンスが終了されるという条件下で、別のコンピュート・ノードの別のフォルト・ドメインで再起動できます。

計画メンテナンスの場合、管理者が最初にコンピュート・ノードをメンテナンス・モードにします。その結果、実行中のコンピュート・インスタンスは別のコンピュート・ノードにライブ移行されます。同じフォルト・ドメインで使用可能なターゲット・コンピュート・ノードがない場合は、インスタンスを別のフォルト・ドメインに移行できます。ライブ移行が失敗した場合、管理者はインスタンスを手動で停止し、別のコンピュート・ノードで再起動する必要があります。メンテナンス・モードは、コンピュート・ノードで実行中のインスタンスがなくなった場合にのみアクティブ化されます。このコンピュート・ノード上のすべてのコンピュート・インスタンス操作は無効になります。メンテナンス・モードのコンピュート・ノードはプロビジョニングまたはプロビジョニング解除できません。

3.2.4 サービスの継続性

Oracle Private Cloud Applianceには、高可用性をサポートし、さらに強化する複数の機能があります。システムのすべてのレベルでのヘルス・モニタリングが重要なファクタです。診断およびパフォーマンス・データはすべてのコンポーネントから収集され、一元的に格納および処理され、標準ダッシュボードでのビジュアライゼーションの形式で管理者が使用できるようになります。また、メトリックが定義済のしきい値を超えるとアラートが生成されます。

Monitoringを使用すると、管理者はシステムの健全性を一定期間追跡し、必要に応じて予防措置を講じ、問題が発生したときにその問題に対応できます。さらに、My Oracle Supportに登録されているシステムは、障害モニタリングおよびターゲットのプロアクティブ・サポートのために収集された診断データを使用して、フォン・ホーム機能を提供します。登録されたシステムは、アプライアンスによって報告された特定の問題について、Oracleで自動サービス・リクエストを送信することもできます。

データ損失を軽減し、障害発生時にシステムおよびサービスの構成のリカバリをサポートするために、一貫性のある完全バックアップを定期的に実行します。クリティカル変更の直前にリストア・ポイントを作成するなど、バックアップを手動で実行することもできます。バックアップはZFS Storage Appliance上の専用NFS共有に格納され、必要に応じてサービス・エンクレーブ全体をリストアできます。

オプションで、アプライアンスにデプロイされているワークロードをディザスタ・リカバリの実装を通じて、ダウンタイムやデータ損失から保護できます。これを実現するには、2つのOracle Private Cloud Applianceシステムを異なるサイトで設定し、互いに複製するように構成する必要があります。ディザスタ・リカバリ制御下のリソースは、各システムのZFS Storage Appliancesに個別に格納され、2つのシステム間でレプリケートされます。あるサイトでインシデントが発生した場合、環境は実際にはダウンタイムなしでレプリカ・システムで起動されます。 Oracleでは、すべてのクリティカルな本番システムにディザスタ・リカバリを実装することをお薦めします。

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

システムの全体的なヘルス・ステータスは、ハードウェアおよびプラットフォーム・レイヤーからのリアルタイム・データを使用して継続的に監視されます。システム・ヘルス・チェックおよびモニタリング・データは、問題検出の基盤です。異常な状態が見つかると、管理者はこの情報を使用してトラブルシューティングを開始します。必要に応じて、Oracleにサービス・リクエストを登録して、問題の解決を支援します。システムの組込みOracle Auto Service Requestクライアントが構成されている場合は、問題の性質および重大度に応じて、サービス・リクエストを自動的に生成できます。

3.3.1 監視

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

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

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

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

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

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

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

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

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

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

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

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

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

Oracle 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クラスタのステータス、アクティブな問題および管理パスの接続情報を報告します。また、構成可能なデータセットのリストのアナリティクス情報も報告します。

3.3.3 集中ロギング

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

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

システムでOracle Auto Service Requestクライアントが構成されている場合は、自動的にサービス・リクエストを生成できます。ただし、サポート・バンドルは手動でアップロードする必要があります。

3.4 アップグレード

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

アップグレードのソース・コンテンツ - パッケージ、アーカイブ、デプロイメント・チャートなど - ISOイメージを介して提供されます。イメージのロケーションは、アップグレード・コマンドの必須パラメータです。管理者は、サービスWeb UIまたはサービスCLIを使用してアップグレードを実行でき、使用可能な2つのオプションのいずれかを選択する必要があります: 個々のコンポーネントのアップグレードまたはフル管理ノードのクラスタのアップグレード。

Pre-Checks

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

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

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

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

ILOMファームウェア

アプライアンス内の特定のサーバーの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イメージを介して提供され、内部レジストリにアップロードされます。この時点までのいずれの操作も、操作環境には影響しません。

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

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

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

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

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

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

3.5 パッチ適用

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

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

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

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

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

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

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

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

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

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

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

ノート

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

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

3.7 障害時リカバリ

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

2つのOracle Private Cloud Applianceシステムは、どちらも単独で完全操作環境ですが、同時に互いに複製するように構成されています。 2つのピアZFS Storage Appliances間の専用ネットワーク接続 - 各ラックに1つ - 確実なデータ・レプリケーションを、スケジュールではなく連続モードで行います。いずれかの環境でインシデントが検出された場合、Oracle Site Guardのロールは、操作計画と呼ばれるフェイルオーバー・ワークフローを実行することです。

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

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

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

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

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

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

3.8 保守性

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

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

コンポーネント・ステータスが正常から正常に変わったら、サービス・ワークフローを開始する通知を送信するようにアラート・メカニズムを構成できます。 Oracleからのサポートが必要な場合、最初のステップは管理者がサービス・リクエストを開き、問題の説明を提供することです。ただし、Oracle Auto Service Requestクライアント・サービスがアクティブ化され、その特定の構成に応じて、サービス・リクエストを自分の名前で自動的に開くことができます。いずれの場合も、管理者はサポート・バンドルを生成して、サービス・リクエストに含めるようにアップロードします。 Oracle Auto Service Requestの詳細については、「ステータスおよびヘルス・モニタリング」を参照してください。

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

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

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

第3章 アプライアンス管理の概要