Azure Arc 対応 SQL Managed Instance のストレージ規範
ストレージは、Azure Arc 対応 SQL Managed Instance (Arc 対応 SQL Managed Instance) デプロイの重要なコンポーネントです。 このドキュメントで説明するストレージ関連の概念が Kubernetes クラスターの機能にどのように影響するかを理解することは、ストレージ設計の選択と管理における重要な側面です。
Kubernetes は、基になるストレージと直接やり取りするのではなく、ストレージ クラスを介してさまざまなストレージ テクノロジへの抽象化レイヤーを提供します。 クラウド プロバイダー、ハードウェア ベンダー、およびその他の Kubernetes で管理されるプラットフォームでは、特定の環境と実装シナリオに合わせてさまざまな StorageClass オプションが提供されます。
Arc 対応 SQL Managed Instance では、ストレージ クラスの使用は制限も強制もされないため、適切なストレージの設計と構成を選択することが重要です。 Arc 対応 SQL Managed Instance のストレージ設計は、ベア メタルまたは仮想マシンで実行するときに SQL Server のバッキング ストレージ デバイスを選択するのと同じくらい重要です。 これらの選択は、最終的には、RPO、RTO、容量、パフォーマンスに関する要件を表します。
Arc 対応 SQL Managed Instance のデプロイでは、ストレージの機能と構成を効果的に計画することが、正常な動作のために不可欠です。 考慮すべきストレージ関連の要素と、Arc 対応 SQL Managed Instance を構成するための推奨事項について説明します。
アーキテクチャ
次のアーキテクチャ図は、Azure Arc 対応データ サービス コンポーネントの論理設計を示しています。 これらのコンポーネントには、必要な Azure Arc データ コントローラーと、参照用にプロビジョニングされたデータベースを含む 1 つ以上の Arc 対応 SQL Managed Instance が含まれます。 Azure Arc データ コントローラーと Arc 対応 SQL Managed Instance ではいずれも、Kubernetes ディストリビューションおよびストレージ インフラストラクチャ プロバイダーに依存するバッキング ストレージ デバイスのオプションが提供されます。
設計上の考慮事項
ストレージの設計と構成に関する考慮事項を次に示します。
記憶域クラス
データ ストレージのパフォーマンス、回復性、容量にとって、お使いの Azure Arc 対応データ サービス コンポーネントに適した Kubernetes StorageClass と構成を選択することが重要です。
StorageClass、PersistentVolume (PV)、PersistentVolumeClaim (PVC) は、Azure Arc 対応データ サービス コンポーネントのプロビジョニング時に、システムにより Kubernetes クラスターに作成される Kubernetes リソース オブジェクトです。
StorageClass のオプションは、クラウド プロバイダー、ハードウェア ベンダーが提供する内容、および Kubernetes 管理者が構成した内容によって異なります。 PersistentVolumeClaim は、StorageClass と要求されたサイズに応じて PersistentVolume を作成するように要求します。 次の図は、これらの Kubernetes リソースとストレージ クラスの潜在的なオプションの関係を示しています。
PV および PVC Kubernetes リソースは、Azure Arc データ コントローラーと Arc 対応 SQL Managed Instance をプロビジョニングするときにそれぞれ構成されます。
以下の 2 つ異なるストレージの種類から選択できます。
- ローカル: ポッドが実行されている Kubernetes ノードにアタッチされているローカル ストレージ デバイスにマウントされているボリューム。 通常、この種類のストレージでは、リモート/共有ストレージと比較して、1 秒あたりの入出力操作 (IOPS) とスループットが高くなり、待機時間が短くなります。
- リモート/共有ストレージ: 通常は冗長性が組み込まれているネットワーク接続ストレージ デバイス。 一般的なストレージ オプションは、NAS と SAN デバイスです。
StorageClass を選択する場合は、次の標準を考慮してください。 これらの条件は、構築するすべてのデータベース サーバーにも当てはまります。
- パフォーマンス: ストレージ デバイスの入出力 (I/O) スループットと IOPS は、データベースのニーズを満たしている必要があります。
- 読み取り/書き込みの比率: ワークロードを理解することは、適切なコストでニーズに最適なバッキング ハードウェアを選択するのに役立ちます。 書き込みの負荷の高いワークロードでは RAID 0 構成を活用できる一方で、アクセス頻度の低いデータは SAN デバイス ストレージを使用するのが最適な場合があります。
- データベースの分離と共同配置: Arc 対応 SQL Managed Instance インスタンス上のすべてのデータベースは PV を共有するため、Arc 対応 SQL Managed Instance の別のインスタンスにデータベースを移動することで、ストレージ リソースの競合を回避できます。
- 容量: 定義されるストレージ サイズは、PVC のサイズを変更する必要がないように、データ コントローラーとデータベース インスタンスの将来の容量を満たす必要があります。 選択した StorageClass に含まれる可能性があるストレージの制限事項を考慮してください。
- アクセス モード: ストレージ クラス プロバイダーにはさまざまなアクセス モードがあり、ストレージのマウント方法やポッドによる読み取りまたは書き込み方法に関するさまざまな機能がサポートされています。 SQL Backup ボリュームには RWX (ReadWriteMany) が必要です。
- 冗長性: ハードウェア ディスク障害が発生した場合のシームレスなフェールオーバーをサポートするための物理ストレージ層でのデータのレプリケーション (RAID)。これは、可用性グループ (AG) によって実現されるデータベース レベルの冗長性とは別です。
Azure Arc データ コントローラーと Arc 対応 SQL Managed Instance Arc データ サービスの両方で、データベース データ用のさまざまなストレージ クラスを構成するための詳細なオプションが提供されます。 これらのデータ サービスではログも提供されるため、ニーズに合わせてストレージ クラスを柔軟に選択できます。
データ コントローラー
Arc 対応 SQL Managed Instance のインスタンスを作成するための前提条件として、Kubernetes クラスターには 1 つの Azure Arc データ コントローラーが必要です。 クラスターで複数のデータ コントローラーを実行することはサポートされていません。
Azure Arc データ コントローラーでは、Kubernetes クラスターで、コントローラー SQL、コントローラー API、ログ DB、メトリック DB の 4 つの異なるステートフル ポッドが実行されます。 各ポッドには、データ ボリュームとログ ボリューム用に 2 つの永続ボリュームが必要です。 データ コントローラー コンポーネント自体はデータの持続性をネイティブに提供しないため、すべてのデータ コントローラー コンポーネントではデータの持続性を確保するためにリモート StorageClass が必要です。
必ず、Azure Arc データ コントローラーに必要なコンピューティングとメモリのリソースを検討してください。 次の図は、データ コントローラー ストレージ、PV、PVC の各 Kubernetes リソースを表しています。
データ コントローラーの既定のボリューム サイズ設定は、推奨される最小値です。 使用するストレージは、データベースの数、データベースの使用方法、生成されるログの数によって異なります。 Azure Arc データ コントローラー StorageClass は、低待機時間に対して敏感ではありません。 それでも、クラスター内に Arc 対応 SQL Managed Instance デプロイが多数ある場合は、パフォーマンスの高いストレージの利点が Grafana と Kibana のインターフェイスで見られる場合があります。 Grafana と Kibana は、データ コントローラーと共にデプロイされる監視視覚化ツールで、Arc 対応 SQL Managed Instance のメトリックとログを表示するためのダッシュボードと共にプロビジョニングされます。
データ コントローラーのプロビジョニング
Azure Arc データ コントローラーをプロビジョニングするときは、ログとデータの両方の StorageClass とストレージ容量を構成します。 ログとデータの両方にストレージを構成すると、データ コントローラー ポッド用に作成する 8 個の PV すべてに適用されます。 プロビジョニング中に、容量、ログ リテンション期間、Kubernetes サービスの種類などのセキュリティに関連する項目などの既定のパラメーターをオーバーライドするカスタム デプロイ テンプレートを指定できます。 プロビジョニングが完了すると、PV と PVC Kubernetes オブジェクトが作成されます。
データ コントローラーの StorageClass は、プロビジョニング後に変更できないことを理解しておくことが重要です。 StorageClass を指定しない場合、データ コントローラーは Kubernetes の既定の StorageClass を使用します。これは、Kubernetes インスタンスまたはプロバイダーによって異なる場合があります。
Azure Arc データ コントローラーをアンインストールすると、それに関連付けられているすべての永続ボリュームが削除されます。 データ コントローラーをアンインストールする前に、組織で保存する必要がある Azure Arc 対応データ サービスのコントロール プレーン レベルのログをアーカイブしてください。
Azure Arc 対応 SQL Managed Instance
Arc 対応 SQL Managed Instance では、ビジネス要件に応じて、General Purpose と Business Critical の 2 つの異なるレベルが提供されます。 どちらのレベルでも、最小と最大の Arc 対応 SQL Managed Instance の制限 (構成可能) を確認し、デプロイされる Kubernetes クラスターに適切なコンピューティングとメモリの容量があることを確認することが重要です。
特定のデータベース インスタンスに複数のデータベースがあるシナリオでは、すべてのデータベースで Arc 対応 SQL Managed Instance に指定された同じ StorageClass、PVC、PV が使用されます。 1 つの Kubernetes クラスターに Arc 対応 SQL Managed Instance の複数のインスタンスを含めることが可能です。 この構成により、独立した永続ボリュームが可能になり、Arc 対応 SQL Managed Instance の異なるインスタンスにデータベースをデプロイすることで、異なるデータベースからの IO 競合を分離できます。
次の表では、Arc 対応 SQL Managed Instance の各ポッドで使用されるさまざまな永続ボリュームとその目的について説明します。
| 永続ボリューム | 説明 | ストレージ クラスの要件 |
|---|---|---|
| Data | SQL Database データ ファイル (.mdf ファイル) | レベルによって異なる |
| DataLogs | SQL Database ログ ファイル (.ldf ファイル) | レベルによって異なる |
| ログ | SQL エージェント、エラー ログ、トレース ファイル、正常性ログ | レベルによって異なる |
| バックアップ | 完全、差分、トランザクション ログを含む SQL Server バックアップ ファイル | リモート、ReadWriteMany アクセス モード |
汎用のサービス階層
Arc 対応 SQL Managed Instance の General Purpose レベルでは、ポッドに障害が発生しても、新しく作成されたポッドでデータを引き続き使用できるように、データベース インスタンスにリモート ストレージを使用する必要があります。 フェールオーバーは、Kubernetes ポッドとノード オーケストレーションによって管理されます。 この構成は、SQL 可用性グループと複数の Arc 対応 SQL Managed Instance レプリカを使用する Business Critical に比べて複雑ではありません。 General Purpose レベルの単一ポッド構成は、他のレプリカのストレージ容量を複製する必要がないため、ストレージの量を最小限に抑えることができることを意味します。
Business Critical サービス レベル
Business Critical レベルでは、データとログのボリュームをローカルまたはリモートのストレージ クラスに格納できる複数ポッドのモデルが使用されます。 通常、ローカル ストレージ クラスは、ストレージ デバイスがノードに直接接続されているため、待機時間とスループットの面でパフォーマンスが向上します。 通常、リモート ストレージには冗長性が組み込まれていますが、多くの場合、ローカル ストレージと比較して待機時間とスループットが低くなります。 より多くの Business Critical データベース レプリカを使用するには、Data、Logs、および DataLogs 用の追加の永続ボリュームが必要になることに注意してください。 必要な合計ストレージ容量ははるかに多くなります。
次の図は、2 つのレプリカを持つ Arc 対応 SQL Managed Instance の Business Critical ストレージ構成を示しています。
Business Critical では、2 つまたは 3 つのセカンダリ レプリカを構成できます。 フェールオーバーは SQL Always On 可用性グループによって管理されます。これにより、General Purpose レベルよりもアップグレードと障害のダウンタイムが短くなります。
同期コミット モードのデータ レプリケーションを使用して複数のレプリカを構成すると、障害が発生したポッド、ノード、ストレージ ハードウェアなどの障害に対する保護が強化されます。 レプリカにデータのコピーが複数存在するため、障害から保護されます。 セカンダリ リスナー エンドポイントを使用するときにクライアントが接続できる、読み取りスケールアウト インスタンスとしてセカンダリ レプリカを構成することを検討してください。
Azure Arc SQL Managed Instance のプロビジョニングとアンインストール
Arc 対応 SQL Managed Instance をプロビジョニングする場合、必要な Arc 対応SQL Managed Instance の永続ボリュームごとに異なるストレージ クラスを柔軟に割り当てることができます。 Data と DataLogs にはパフォーマンスの高いストレージ オプションが必要な場合がありますが、Logs と Backup ボリュームでは、コスト効率の高い StorageClass オプションを使用してコストを節約できます。 ローカル ストレージを使用するシナリオでは、ディスク I/O での競合を回避するために、ボリュームを異なるノードと物理ストレージ デバイスに配置できることを確認します。 Data と DataLogs を同じ物理ドライブに配置すると、そのストレージ ドライブで競合が発生し、パフォーマンスが低下する可能性があります。 代わりに、データベースのデータとログの両方の I/O を並列化するために、Data と DataLogs を別々のストレージ ドライブに配置することを検討してください。
Arc 対応 SQL Managed Instance を削除しても、関連付けられている PV と PVC は削除されません。 この動作は、誤って削除された場合に、データベース ファイルにアクセスできるようにするためです。
設計の推奨事項
ストレージの設計と構成に関する推奨事項を次に示します。
運用ワークロードのストレージ クラス
特定のパブリック クラウドの場合に、運用ワークロードに推奨されるストレージ クラスを次の表に示します。
| プロバイダー | 検証済みの推奨されるストレージ |
|---|---|
| Azure Kubernetes Service (AKS) | Azure Managed Disks (Premium レベル) |
| Amazon Elastic Kubernetes Service (EKS) | EBS CSI ストレージ ドライバー |
| Google (GKE) | GCE 永続ディスク |
オンプレミスまたはマルチクラウドのシナリオで運用 StorageClass を選択する場合は、目的のストレージ容量、IOPS、冗長性、スループットのニーズを満たすことができることを確認します。 以降のセクションで、これらのシナリオでの推奨事項について詳しく説明します。
データ コントローラーの設計
データの持続性を確保するために、リモートの共有 StorageClass を選択します。 ポッドまたはノードが削除された場合は、ポッドのバックアップを戻し、永続ボリュームに再度接続できます。 下線の StorageClass は、冗長性と高可用性を提供する必要があります。
Arc 対応データ サービスのデータ コントローラーを作成するときは、カスタム デプロイ テンプレートを使用することをお勧めします。 カスタム テンプレートを使用すると、ストレージ クラス、データとログのストレージ サイズ、セキュリティ、Kubernetes サービスの種類を細かく調整できます。 環境や企業のニーズに合わせてこれらをカスタマイズできます。 Azure Arc データ コントローラーには、合計 8 つの永続ボリュームが必要です。 既定の最小構成では、データに 15Gi、ログに 10Gi を PV で使用できます。 最小の推奨事項を満たすだけでなく、クラスターで多数の Arc 対応 SQL Managed Instance 実装を実行することによる増加をサポートする容量を構成します。 この構成により、後で PVC のサイズを変更する必要がなくなります。
クラスターに多数のデータベースと Arc 対応 SQL Managed Instance のデプロイがある場合は、低遅延の StorageClass を選択することをお勧めします。 待機時間が短いほど、Grafana と Kibana のインターフェイスのユーザー エクスペリエンスが向上します。
Azure Arc 対応 SQL Managed Instance の移行
Arc 対応 SQL Managed Instance の移行とデプロイに関連するすべての新規および既存のデータベースについて計画し、考慮することをお勧めします。 計画により、後でインスタンス間でデータベースを移動する必要がなくなります。
Kubernetes クラスターの編成に応じて、環境 (非運用、運用) を分離する必要性、リージョン、その他のビジネス要因に基づいて、Arc 対応 SQL Managed Instance のデプロイを異なる Kubernetes クラスターにプロビジョニングします。 追加の推奨事項について、リソース編成の設計領域を確認してください。 クラスターで複数のデータベース インスタンスを構成する場合は、I/O 競合を回避するために、負荷の高いデータベースをそれぞれのインスタンスに分離してください。
ノード ラベルを使用して、データベース インスタンスが個別のノードに配置され、I/O トラフィック全体が複数のノードに分散されるようにします。ラベルを構成するには、Kubernetes のノード ラベルと Kubernetes のノードのアフィニティと非アフィニティ ラベルに関する記事を参照してください。 仮想化された環境で運用する場合は、I/O が物理ホスト レベルで適切に分散されていることを確認します。
Arc 対応 SQL Managed Instance の容量を計画して、Data、Logs、DataLogs、Backups に適したストレージ サイズを含めます。 Arc 対応 SQL Managed Instance のインスタンスに存在するすべてのデータベースについて、現在のニーズと予測される増加の両方に対応する容量を計画すれば、将来 PVC のサイズを変更する必要がなくなります。 並列 I/O アクティビティを実行できるように、Data と DataLogs には別の物理ドライブを選択します。 並列 I/O アクティビティでは、共有ドライブの使用時に発生する可能性のある競合を回避することで、パフォーマンスが向上します。
Arc 対応 SQL Managed Instance の Business Critical または General Purpose レベルのデプロイを決定づけるいくつかの要因がありますが、ローカル ストレージを使用する Business Critical は待機時間が最も短く、可用性が最も高くなります。 ポイントインタイム リストア、高可用性、ディザスター リカバリーに関する推奨事項について、Arc 対応 SQL Managed Instance のビジネス継続性の設計領域を確認してください。 さらに、各レベル間でのコストへの影響について、Arc 対応 SQL Managed Instance のコスト ガバナンスの設計領域を確認してください。
次のサブセクションでは、各レベルについてより具体的な推奨事項を示します。
General Purpose サービス レベルの推奨事項
最適なパフォーマンスを得るために、Data および DataLogs の永続ボリュームには低待機時間のリモート StorageClass を選択することをお勧めします。 Backup と Logs の永続ボリュームにインターネットで提供される StorageClass を使用するようにオンプレミス クラスターを構成するなど、ネットワーク パーティションが導入される StorageClass を使用することは避けてください。
Business Critical サービス レベルの推奨事項
可用性モードの違いを確認することをお勧めします。選択するモードごとに異なる構成が必要になります。
可能な限り短い待機時間の要件があるシナリオでは、お使いの Kubernetes インフラストラクチャのオプションである場合は、ローカル ストレージを選択します。 ローカル ストレージ ボリュームは、ディスク I/O での競合を回避し、パフォーマンスを最大化するために、異なる基本ストレージ デバイスに配置する必要があります。 ストレージ デバイスには、オペレーティング システム パーティションのホスティングなど、複数の機能を持たせないでください。
読み取り集中型のワークロードと高可用性については、複数のレプリカを構成し、セカンダリ レプリカを読み取りスケールアウト インスタンスとして使用するようにアプリケーションまたはクライアントを構成します。 セカンダリ レプリカは、既定では読み取りできませんが、設定を構成できます。
監視
Arc 対応データ サービスによって作成されるすべての PVC (Azure Arc データ コントローラーとクラスター内の Arc 対応 SQL Managed Instance のすべてのインスタンスを含む) を監視することをお勧めします。 PVC が容量に近づいたときに通知するアラートを設定します。 通知を使用すると、容量に達する前に PVC のサイズを変更できます。 直接接続されたクラスターの場合、PVC の監視とアラートの生成は、Azure Monitor と Container Insights によって行われます。 間接接続クラスターを使用する場合は、Grafana と Kibana で監視とアラート生成を実行します。 Grafana のインストールには、Arc 対応 SQL Managed Instance のメトリックと Kubernetes リソースのダッシュボードが含まれています。
Arc 対応 SQL Managed Instance の監視に関するその他の推奨事項については、Arc 対応 SQL Managed Instance のガバナンス規範に関する記事を確認してください。
次のステップ
ハイブリッドとマルチクラウドでのクラウドの取り組みの詳細については、次の記事を参照してください。
- Azure Arc 対応データ サービスのストレージ構成について確認する。
- Azure Arc 対応データ サービスの検証済み Kubernetes ディストリビューションを確認する。
- Azure Arc 対応データ サービスのサイズ設定ガイダンスを確認する。
- Arc 対応 SQL Managed Instance での Grafana と Kibana を使用した監視について確認する。
- Azure Arc Jumpstart を使用して、Arc 対応 SQL Managed Instance の自動化シナリオを体験する。
- Azure Arc の詳細については、Microsoft Learn の Azure Arc ラーニング パスを確認します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示