次の方法で共有

Azure Arc 対応 SQL Managed Instance のアップグレードに関する規範

  • [アーティクル]

Azure Arc 対応データ サービスでは、Arc 対応 SQL Managed Instance でのみ利用可能な、常に最新に保たれたバージョンの SQL を取得することができます。 Arc 対応 SQL Managed Instance は、常に最新の状態であるという性質上、管理サービスベースのアップグレードが可能であり、オンプレミスのインストールやマルチクラウド環境とは違って、Azure インフラストラクチャのイノベーションをすぐに利用することができます。

この記事では、Azure Arc 対応データ サービスのアップグレード プロセスを構成および管理するための主要な設計上の考慮事項と推奨事項について説明します。

アーキテクチャ

直接接続モード

次の図は、直接接続モードでのデータ サービスのアップグレード フローを示しています。

直接接続モードでのデータ サービスのアップグレード フローを示すスクリーンショット。

間接接続モード

次の図は、間接接続モードでのデータ サービスのアップグレード フローを示しています。

間接接続モードでのデータ サービスのアップグレード フローを示すスクリーンショット。

汎用のサービス階層

次の図は、General Purpose サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード プロセスを示しています。

General Purpose サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード前のプロセスを示すスクリーンショット。

General Purpose サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード プロセスを示すスクリーンショット。

Business Critical サービス レベル

次の図は、Business Critical サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード プロセスを示しています。

Business Critical サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード前のプロセスを示すスクリーンショット。

Business Critical サービス レベルでの Arc 対応 SQL Managed Instance のアップグレード プロセスを示すスクリーンショット。

Business Critical サービス レベルのアップグレードにおける残りのセカンダリ レプリカのアップグレード ロールアウトを示すスクリーンショット。

Business Critical サービス レベルのアップグレードにおける SQL レベルのフェールオーバーと最後のポッドのインスタンス化を示すスクリーンショット。

設計上の考慮事項

Azure Arc データ コントローラーのアップグレード

  • アップグレードは、Azure CLI、Azure portal、Kubernetes など、さまざまなツールを使用して実行できます。 使用する接続モード (直接接続モードまたは間接接続モード) と、最も使い慣れたツールに応じて、どのツールを利用するかを検討してください。
  • Azure Arc データ コントローラーを確認して、Arc 対応 SQL Managed Instance と共に Azure Arc 対応 PostgreSQL などのプレビュー データ サービスがデプロイされているかどうかを確認します。 プレビューと一般提供のサービスが同じデータ コントローラーにデプロイされている場合、一括アップグレードを実行することはできません。
  • アップグレードを実行する前に、データ コントローラーで使用されているすべての Arc 対応 SQL Managed Instance のバージョンを確認し、データ コントローラーと同じバージョンであることを確かめます。
  • サポートされているアップグレード パスを考慮して、アップグレード前にデータ コントローラーの次の正しいバージョンを決定してください。

Note

Azure Arc データ コントローラーをアップグレードしても、Arc 対応 SQL Managed Instance のダウンタイムは発生しません。

直接接続モード

間接接続モード

  • 間接接続モードでの Azure Arc データ コントローラーのアップグレードを、Azure CLI、または Kubernetes ツールのいずれを使用して実装するかを決定します。
  • Kubernetes ツールと Azure CLI を使用してアップグレードの前提条件を確認します。
  • クラスターがインターネットに接続されている場合は Microsoft アーティファクト レジストリを使用して、あるいはクラスターがエアギャップされている場合はプライベート レジストリを使用して Azure Arc 対応データ サービス イメージをプルするかどうかを決定します。
  • Kubernetes ツールを使用して Azure Arc データ コントローラーをアップグレードするために使用するサービス アカウントに必要な Kubernetes アクセス許可について検討します。
  • リポジトリ情報を確認して、それが有効であり、新しいイメージが既にプルされていることを確認します。

Azure Arc 対応 SQL Managed Instance のアップグレード

一般的な考慮事項

  • Arc 対応 SQL Managed Instance をアップグレードする前に、Azure Arc データ コントローラーのアップグレードを実行する必要があります。 arcdata クラスター拡張機能と SQL Managed Instance 拡張機能のバージョンは関連しており、同じである必要があります。
  • 要件に応じて、Arc 対応 SQL Managed Instance の自動アップグレードまたは手動アップグレードを使用するかを決定します。
  • 自動アップグレードの場合、データ コントローラーに対して定義できるメンテナンス期間は 1 つだけです。 必要なデータ コントローラーの数を特定できるよう、ワークロードに応じて必要なメンテナンス期間の数を考慮してください。

汎用のサービス階層

  • General Purpose サービス レベルのアップグレードでは、Kubernetes ポッドが終了して新しいバージョンで再プロビジョニングされます。 アップグレードで新しいポッドが作成される際に短時間のダウンタイムが発生することによる、アプリケーションとクライアント側の影響を理解することが重要です。
  • アプリケーションのアーキテクチャを見直して、アップグレード時に生じた短時間の影響に対応するために必要な回復性と再試行ロジックを備えているかどうかを把握します。

Business Critical サービス レベル

  • 複数のレプリカの Business Critical サービス レベルのアップグレードでは、セカンダリ レプリカが最初にアップグレードされます。 アップグレードされたセカンダリ レプリカの 1 つが新しいプライマリ レプリカに昇格し、古いプライマリがセカンダリになり、アップグレードされます。 古いプライマリから新しいプライマリへの移行中に、フェールオーバーが発生すると、短時間のダウンタイムが発生します。 アップグレードでフェールオーバーが発生した場合のアプリケーションとクライアント側の影響を理解することが重要です。
  • アプリケーションのアーキテクチャを見直して、アップグレード時に生じた短時間の影響に対応するために必要な回復性と再試行ロジックを備えているかどうかを把握します。

設計の推奨事項

Azure Arc データ コントローラーのアップグレード

  • Azure CLI を使用してアップグレードする場合は、バージョン ログで arcdata Azure CLI 拡張機能のバージョンがアップグレードするイメージ バージョンに対応していることを確認します。

  • マルチクラスター環境では、まずテスト/開発環境でアップグレードを実行して、潜在的な問題や破壊的変更を検証します。

  • アップグレードの前にドライ ランを実行して、バージョン スキーマ、プライベート リポジトリ認証トークン (使用されている場合)、およびレジストリが存在することを検証してから実際のアップグレードを試行してください。

  • 新しい Azure Arc データ コントローラーのアップグレードを監視するプロセスを作成します。

  • Arc 対応 SQL Managed Instance は一般提供されていますが、PostgreSQL はまだプレビュー段階のため、同じデータ コントローラーに PostgreSQL と Arc 対応 SQL Managed Instance を混在させないようにしてください。 PostgreSQL をテストする際は、独自のデータ コントローラーを備えた別のクラスターを検討してください。

  • 運用環境でのプレビュー機能の使用は避け、Dev/Test インスタンスでの評価目的でのみプレビュー機能を使用してください。

  • デプロイされたデータ コントローラーの現在のバージョンのインベントリを作成します。 Azure Resource Graph を使用して、現在デプロイされているデータ コントローラーのクエリを実行できます。

      resources
  | where type == 'microsoft.azurearcdata/datacontrollers'
  | extend version = tostring(properties.k8sRaw.status.runningVersion)
  | project name,location,resourceGroup,version

  • トラブルシューティング ガイドを参照して、アップグレードの問題を解決するために必要なログを取得する方法を確認してください。

直接接続モード

間接接続モード

Azure Arc 対応 SQL Managed Instance のアップグレード

一般的な推奨事項

  • Arc 対応 SQL Managed Instance を常に最新のバージョンに更新しておくことで、最新のパッチ、バグ修正、機能を受け取ることができます。 現在、Arc データ サービスでは、アップグレード時のリリースのスキップはサポートされていません。 したがって、アップグレードするリリースが複数ある場合は、一連のリリースにアップグレードして最新バージョンに移行する必要があります。 最新リリースからあまり離れないようにすることをお勧めします。

  • アップグレード中に問題が発生した場合に回復できるように、必ず "ポイントインタイム リストア" バックアップ ポリシーを構成してください。 事業継続とディザスター リカバリーの重要な設計領域を確認し、インスタンスに対して kubectl describe sqlmi コマンドを使用して現在の保持設定を検証します。

  • マルチクラスター環境や、異なる環境を表す Arc 対応 SQL Managed Instance の複数デプロイのシナリオでは、まず開発環境などの Dev/Test 環境でアップグレードを実行して、潜在的な問題や破壊的変更を検証します。

  • アップグレードの前にドライ ランを実行して、バージョン スキーマ、プライベート リポジトリ認証トークン (使用されている場合)、およびレジストリが存在することを検証してから実際のアップグレードを試行してください。

  • Azure CLI を使用して、Arc 対応 SQL Managed Instance の大規模なアップグレードを実行できます。

  • 即時アップグレードを許容できるワークロードには自動アップグレードを使用し、ピーク時以外の時間にアップグレードを実行するようスケジュールする必要があるワークロードに対しては自動アップグレードをオプトアウトします。

  • 自動アップグレードを使用する場合は、ピーク時以外の時間にアップグレードを実行できるように、適切なメンテナンス期間を定義するようにしてください。

  • 手動アップグレードの場合は、アップグレードがサポートされているバージョンに収まるように、一定の実行頻度を確立するようにしてください。

    Note

    新しいコンテナー イメージ バージョンの Microsoft アーティファクト レジストリをポーリングすることもできます。

  • Azure CLI または Kubernetes ツールを使用してアップグレードの状態を監視するプロセスを作成します。

  • アップグレードを実行する前に、コンポーネントごとの対応するバージョンを確認し、正しいバージョンのコンポーネントが配置されていることを検証します。

汎用のサービス階層

Business Critical サービス レベル

  • 2 つではなく 3 つのレプリカを含む Business Critical インスタンスをデプロイして、アップグレードやフェールオーバー アクティビティ時のダウンタイムを減らし、高可用性を実現します。
  • 重要でない時間帯にアップグレードを実行して、ユーザーと組織データへの影響を最小限に抑えます。

次の手順

ハイブリッド クラウドとマルチクラウドの導入過程の詳細については、次の記事を参照してください。