次の方法で共有

Azure Red Hat OpenShift の運用ベースライン ガイダンス

  • [アーティクル]

Azure Red Hat OpenShift により、可用性の高いフル マネージド OpenShift クラスターがオンデマンドで提供されます。 管理と監視を念頭に置いてソリューションを適切に設計することで、オペレーショナル エクセレンスと顧客の成功を目標に作業を行うことができます。

設計上の考慮事項

次の要因について検討します。

  • Azure Red Hat OpenShift の責任マトリックスを確認して、Microsoft、Red Hat、および顧客間でクラスターの責任がどのように共有されるかを把握してください。
  • Azure 仮想マシンの制限とサポートされるリージョンに留意してください。 リソースのデプロイに使用できる容量があることを確認します。
  • ワークロードをクラスター内で論理的に分離する方法、別々のクラスターに物理的に分離する方法に注意します。
  • Kubernetes がワークロードの正常性を理解するために役立つ方法に注意します。
  • さまざまな仮想マシンのサイズと、そのいずれかを使用した場合の影響に留意してください。
  • Azure Red Hat OpenShift を監視およびログに記録して、リソースの正常性に関する分析情報を取得し、潜在的な問題を予測する方法に留意してください。 クラスターと上で実行されているアプリケーションの両方で、多くのイベントが生成される可能性があります。 アラートを使用して、ログの履歴目的のエントリと、早急に対処する必要があるエントリとの区別に役立ててください。
  • システムの重要な更新プログラムとアップグレードに留意してください。 重要なパッチ更新プログラムは、Azure Red Hat OpenShift のサイト信頼性エンジニア (SRE) によって自動的にクラスターに適用されます。 パッチ更新プログラムの事前インストールを希望する顧客は、自由に行うことができます。
  • クラスターと個々のワークロードのリソースの制限に留意してください。
  • Horizontal Pod Autoscaler とクラスターの自動スケーリングの違いに留意してください。
  • サポート ライフサイクルを確認し、バージョン サポート ポリシーを把握してください。 Azure Red Hat OpenShift でサポートされているのは、Red Hat OpenShift Container Platform の現在および前の一般公開されているマイナー リリースのみです。 サポート要求では、クラスターがサポートされているバージョン内にある必要があります。
  • クラスターのサポートを維持するために、クラスター構成の要件を確認してください。
  • ネットワーク ポリシーを使用してクラスター内のトラフィックをセキュリティで保護するための名前空間間のネットワークを確認してください。

設計の推奨事項

  • Azure Red Hat OpenShift には豊富なオペレーター エコシステムがあり、運用アクティビティを良好な効率と精度で実行および自動化するために使用する必要があります。
  • アプリケーションの正常性を監視するために、ポッドに正常性プローブを追加します。 ポッドに livenessProbe と readinessProbe が含まれていることを確認します。 スタートアップ プローブを使用して、アプリケーションが起動した時点を特定します。
  • 密度向上による利点が得られるように、複数のコンテナー インスタンスを格納するのに十分大きいが、障害が発生しているノードのワークロードをクラスターで処理できなくなるほど大きくはない仮想マシン サイズを使用します。
  • 受付プラグインを使用してクラスター関数を調整します。これは、セキュリティ ポリシー、リソースの制限、または構成要件を適用するために一般的に使用されます。
  • ポッドの要求と制限を使用して、クラスター内のコンピューティング リソースを管理します。 ポッドの要求と制限によって、Kubernetes スケジューラに、ポッドに割り当てるコンピューティング リソースを通知します。 制限範囲を使用して、プロジェクト内のリソース消費量を制限します。
  • Vertical Pod Autoscaler を使用して、CPU とメモリの要求値を最適化し、クラスター リソースの効率を最大化します。
  • OpenShift Web コンソールには、ノード レベルのすべてのメトリックが含まれています。 組み込みの Prometheus または Container Insights 統合を使用して監視プロセスを確立します。
    • Prometheus は、プレインストールされ、Azure Red Hat OpenShift 4.x クラスター用に構成されています。
    • Container Insights は、クラスターを Azure Arc 対応 Kubernetes にオンボードすることで有効にできます。
    • OpenShift Logging は、ログ アグリゲーター、ストレージ、視覚化コンポーネントをデプロイします。
  • OpenShift Container Platform によって提供されるパイプラインや GitOps などの DevOps プラクティスと CI/CD ソリューションを使用して、アプリケーションの配信プロセスを自動化します。
  • クラスターがリソースを使い切ったときにマシンをスケーリングし、より多くのデプロイをサポートするために ClusterAutoScaler と MachineAutoScaler を定義します。
  • マシン の正常性チェックをデプロイして、マシン プール内の破損したマシンを自動的に修復します。
  • Horizontal Pod Autoscaler を使用して、需要に合わせてポッドをスケーリングします。
  • アラート システム (Container Insights のメトリック アラート または組み込みのアラート UI) を使用して、直接アクションが必要なときに通知を提供します。

ビジネス継続性とディザスター リカバリー (BCDR)

組織は、その特定の要件を満たすように、適切な Azure Red Hat OpenShift プラットフォームレベルの機能を設計する必要があります。 これらのアプリケーション サービスには、目標復旧時間 (RTO) と回復ポイントの目標 (RPO) に関連する要件があります。 ディザスター リカバリーには、対処する複数の考慮事項があります。 最初の手順で、インフラストラクチャとアプリケーションのサービス レベル アグリーメント (SLA) を定義します。 Azure Red Hat OpenShift の SLA について確認してください。 月間稼働率の計算の詳細については、SLA の詳細セクションを参照してください。

BCDR の設計に関する考慮事項:

次の要因について検討します。

  • Azure Red Hat OpenShift クラスターでは、複数のマシン セットを使用して、アプリケーションに対して最小レベルの可用性を提供する必要があります。
  • ポッドの要求と制限を設定します。 これらの制限を設定すると、Kubernetes から次のことができます。
    • ポッドに CPU およびメモリ リソースを効率的に割り当てます。
    • ノードのコンテナー密度を高くします。
    • ハードウェアを効果的に使用できるようになるため、コストを削減しながら信頼性が向上します。
  • 可用性を高める目的で、使用可能なすべてのゾーンにノードを分散します。
    • 可用性ゾーンをサポートしているリージョンを選択します。
    • ゾーンを完全に活用するには、すべてのサービス依存関係でもゾーンがサポートされている必要があります。 依存サービスでゾーンがサポートされていない場合、ゾーンの障害によってそのサービスが失敗する可能性があります。 ワークロードを複数のゾーンに分散するときに使用されるディスクの種類を確認してください。
    • Availability Zones が達成できる以上の高可用性を実現するには、複数のクラスターを異なるペアのリージョンで実行します。 Azure リソースで geo 冗長がサポートされている場合は、冗長サービスのセカンダリ リージョンが維持される場所を指定します。
  • アプリケーションとデータのバックアップを一貫して作成します。
    • ステートフルでないサービスは、効率的にレプリケートできます。
    • クラスター内に "状態" を格納する必要がある場合は、ペアになっているリージョンで頻繁にデータをバックアップしてください。
  • クラスターをアップグレードおよび保守します。
  • フェールオーバーが発生した場合のネットワーク接続について:
    • リージョン間でトラフィックを分散する必要がある場合は、Azure Front Door の使用を検討してください。
  • 計画的および計画外のフェールオーバーについて:
    • 各 Azure サービスを設定するときに、ディザスター リカバリーをサポートする機能を選択します。 たとえば、Azure Container Registry が選択されている場合は、geo レプリケーションに対して有効にします。 リージョンがダウンした場合でも、レプリケートされたリージョンから引き続きイメージをプルできます。
  • サービスレベル目標を達成するためにエンジニアリング DevOps 機能を保守します。

BCDR のための設計上の推奨事項

設計のベスト プラクティスを次に示します。

  • Azure Red Hat OpenShift クラスターは、3 つのコントロール プレーン ノードと、3 つ以上のワーカー ノードでプロビジョニングされます。 ノードがゾーン全体に分散されるように、Availability Zones をサポートするリージョンにクラスターが作成されるようにします。
  • 高可用性のため、これらのノードを異なる Availability Zones にデプロイします。 Availability Zones ごとに異なるマシン セットが必要であるため、少なくとも 3 つのマシン セットを作成します。
  • コントロール プレーン ノードで追加のワークロードを実行しないでください。 これらはコントロール プレーン ノードでスケジュールできますが、クラスター全体に影響を与える可能性のある余分なリソースの使用と安定性の問題が発生します。
  • インフラストラクチャ コンポーネントを保持するインフラストラクチャ マシン セットを作成します。 これらのマシンに特定の Kubernetes ラベルを適用し、それらのマシンでのみ実行されるようにインフラストラクチャ コンポーネントを更新します。
  • 可能な限り、サービスの状態をコンテナー内から削除します。 代わりに、マルチリージョン レプリケーションをサポートする Azure のサービスとしてのプラットフォーム (PaaS) を使用します。
  • デプロイで、ポッド リソースの要件を指定する必要があります。 そうすることで、スケジューラでポッドを適切にスケジューリングできます。 ポッドがスケジュールされていない場合、信頼性が大幅に低下します。
  • ハードウェア障害などの中断に対処するために、デプロイに複数のレプリカを設定します。 更新やアップグレードなどの計画されたイベントに備えて、中断バジェットを使用して、予想されるアプリケーション負荷を処理するために必要な数のポッド レプリカを確保できます。
  • ポッド トポロジ制約を使用して、クラスター全体のノードでポッドを自動的にスケジュールします。
  • アプリケーションはそのデータにストレージを使用する可能性があり、必要に応じて次の方法でリージョンにまたがる可用性を確保する必要があります。
  • 次のようにアプリケーションのバックアップを作成し、復元を計画します。
  • ポッド リソース制限を見積もります。 ベースラインをテストして確定します。 要求と制限に等しい値を使用して開始します。 次に、それらの値を徐々に調整しながら、クラスターを不安定にするおそれがあるしきい値を確定します。 ポッドの制限は、配置マニフェストに指定できます。 Vertical Pod Autoscaler により、CPU とメモリの要求値が最適化され、クラスター リソースの効率を最大化できます。
    • 組み込みの機能は、サービス アーキテクチャの障害や中断に対処できます。 これらの構成は、設計とデプロイ自動化の両方を簡略化するのに役立ちます。 SLA、RTO、および RPO の標準を定義すると、組織は Kubernetes と Azure に組み込まれているサービスを使用して、ビジネス目標を達成できます。
  • アプリケーションの新しいリリースをデプロイするには、ブルーグリーンまたはカナリアの戦略を検討してください。
  • ポッドの優先度やポッド中断の予算を設定して、クラスターがメンテナンス操作のために停止できるポッド レプリカの数を制限することで、可用性を確保します。
  • サービス名前空間でリソース クォータを適用します。 名前空間のリソース クォータによって、デプロイにポッドの要求と制限が適切に設定されます。
    • クラスター レベルでリソース クォータを設定すると、適切な要求と制限のないパートナー サービスをデプロイするときに問題が発生するおそれがあります。
  • コンテナー イメージを Azure Container Registry に格納し、そのレジストリを各リージョンに geo レプリケートします。
  • Azure ExpressRoute 接続には、複数のリージョンとピアリングの場所を使用します。 Azure リージョンまたはピアリング プロバイダーの場所に影響する停止が発生した場合に、ハイブリッド ネットワーク アーキテクチャが冗長になっていると、中断のないクロスプレミス接続を確保できます。
  • グローバル仮想ネットワーク ピアリングを使用してリージョンを相互接続します。 クラスターが相互に通信する必要がある場合、両方の仮想ネットワークを相互に接続するには、仮想ネットワーク ピアリングを使用して実現できます。 このテクノロジにより、異なる地理的リージョンにまたがっていても、仮想ネットワークが相互に接続されて、Microsoft のバックボーン ネットワーク全体に高帯域幅がもたらされます。
  • スプリット TCP ベースのエニーキャスト プロトコルである Azure Front Door を使用して、エンド ユーザーを最も近いフロント ドア POP (存在点) に迅速に接続します。 Azure Front Door には、さらに次のような機能があります。
    • TLS 終了
    • カスタム ドメイン
    • Web アプリケーション ファイアウォール
    • URL 書き換え
    • セッション アフィニティ

次の手順

Azure ランディング ゾーンでのプラットフォームの自動化と DevOps に関する設計上の考慮事項と推奨事項について説明します。