SQL Server Anywhere
SQL Server on Linux がリリースされた際に「SQL Server Anywhere」が一つのキーワードとなっていました。
この時の Anywhere は、「SQL Server を Windows 以外で動作させることができる」ことになり、どこでも SQL Server を活用できるというのが一つのアナウンスとなっていました。
動作環境については、現在でも強化が行われています。
先日、一般提供 (GA) が開始された、Azure SQL Edgeも SQL Server を様々な場所で動作させることができるサービスの一つです。
Azure SQL Edge の動作要件についてはAzure SQL Edge でサポートされる機能に記載されています。
現状、Azure SQL Edge はコンテナーとして展開が行われるため、推奨としては Ubuntu 18.04 LTS となっており、Ubuntu 20.04 LTS でもサポートが行われます。
これだけであれば、SQL Server on Linux と変わりませんが、Azure SQL Edge の最大の特徴として含まれるものは、「サポートする CPU」です。
SQL Server は、2016 以降は x64 の CPU 上でのみ動作をサポートしていました、Azure SQL Edge も 64 ビットアーキテクチャ上で動作するものとなりますが、x64 だけでなく、「ARM64」についてもサポートしています。
これにより、一般的な Linux ベースの環境のほかに、軽量なエッジデバイス上でも動作させることができるようになりました。
私の場合は、Raspberry Pi 4 Model B を使用しているのですが、Cortex-A72 のデバイス上で、SQL Server が起動できています。
このように動作するデバイスを選ばなくなっているところに、SQL Server Anywhere の強化が行われています。
SQL Server は「動作するデバイス」以外にも多様性を持たせるようになってきており、その仕組みが今回紹介する「Azure Arc」です。
Azure Arc は、Azure の管理性/サービスを「様々なインフラストラクチャ上で実現」することができるサービスとなります。
Azure Arc で管理できる対象が記載されています。
Azure Arc で SQL Server に関連するものは、現状、次の 2 種類がプレビューの機能として提供されています。
これらの機能を使用することで「Azure 以外で動作している SQL Server を Azure 上で管理」「Azure 以外の環境に SQL Managed Instance を展開」することができるようになります。
SQL Server on Linux や Azure SQL Edge は「デバイス / OS を選ばなくなる」という観点での SQL Server Anywhere だったのではないかと思います。
Azure Arc は「実行するインフラストラクチャを選ばなくなる」という観点での SQL Server Anywhere となるのではないでしょうか。
Azure Arc を使用すると SQL Server ベースの環境に対してどのようなことができるようになるのかを見ていきたいと思います。
Azure Arc enabled SQL Server
Azure Arc enabled SQL Server の全体構成はAzure Arc 対応 SQL Server (プレビュー)で次のように示されています。
Azure Arc は様々な場所で実行している「インストールタイプの SQL Server」を Azure に接続することで、Azure の管理性を様々なインフラストラクチャ上で実行している SQL Server に拡張をすることができます。
Azure Arc enabled SQL Server は、次の環境で動作している SQL Server 2012 以降をサポートしています。(Linux は SQL Server 2017 以降)
- Windows Server 2012 R2 以降
- Ubuntu 16.04 および 18.04 (x64)
- Red Hat Enterprise Linux (RHEL) 7 (x64)
- SUSE Linux Enterprise Server (SLES) 15 (x64)
これらの環境で動作している SQL Server のベース環境に対して、Azure Arc に接続するためのスクリプトを実行することができれば、SQL Server を Azure Arc に接続することができます。
実際にオンプレミスの SQL Server を Azure Arc に接続した環境がこちらになります。
Azure Arc enabled SQL Server を使用することで、「様々なインフラストラクチャ上で実行している SQL Server」を Azure Arc 経由で管理することができます。
このインフラストラクチャはオンプレミス / Azure 以外のクラウドで動作している SQL Server が含まれています。
Azure Arc 自体は Azure のリソースですが、登録する SQL Server については Azure 以外の環境で動作していても、接続用のスクリプトが実行でき、Azure への接続経路が整っていれば、Azure Arc に登録を行うことができます。
Azure Arc には、Azure Arc enabled Server という、様々なインフラストラクチャ上で動作しているサーバーを Azure Arc に接続するという機能が既に一般提供されています。
Azure Arc enabled SQL Server は enabled Server を拡張するような形の機能となっているため、enabled SQL Server を登録すると enabled Server にも登録が行われます。
enabled SQL Server では、登録した SQL Server に対して、セキュリティのチェック / 環境の診断 / 自動化タスクの機能を活用できるようになります。
これらの機能は Azure で実行している仮想マシンの SQL Server に対して、提供されているものがいくつかありますが、このような機能を様々なインフラストラクチャで実行している SQL Server でも活用ができるようになります。
つまり、「Azure の管理性を Azure 以外の環境にも使用する」ことができます。
様々なインフラストラクチャ上で実行されている SQL Server に対して、Azure に接続を行い、Azure の管理性を提供する ことができるのが Azure Arc enabled SQL Server となります。
Azure Arc enabled SQL Managed Instance
Azure Arc enabled SQL Server は、様々なインフラストラクチャ上で実行している SQL Server に対して、Azure の管理性を提供することができる機能でした。
Azure Arc enabled SQL Managed Instance は様々なインフラストラクチャ上に対して、SQL Managed Instance を展開できる機能です。
正確にいうと「様々なインフラストラクチャ上で実行されている Kubernetes (k8s) の環境に対して、SQL Managed Instanceを展開できる」機能です。
Azure Arc enabled SQL Managed Instance は Azure Arc enabled Data Services というサービスの一機能となっており、
- Azure Arc enabled PostgreSQL Hyperscale
- Azure Arc enabled SQL Managed Instance
の 2 種類が提供されおり、k8s 上に Azure の PaaS のデータサービスを展開することができる機能となります。
k8s については、Azure 利用可能な AKS (Azure Kubernetes Services) や、そのほかのクラウドで実行されている k8s でも問題ありません。
私の場合は、オンプレミスの環境に k8s を構築している環境を使用しているのですが、k8s が動作していれば、どれを実行しているインフラストラクチャを問わずに、Data Services を展開することが可能です。
Azure Arc Data Controller
Azure Arc enabled SQL Managed Instance を k8s 上に展開するには、Azure Arc Data Controller を最初に k8s 上に展開する必要があります。
現状、サポートされている k8s には次のようなものがあります。
- Azure Kubernetes Service (AKS)
- Azure Stack の Azure Kubernetes Service エンジン (AKS エンジン)
- Azure Stack HCI の Azure Kubernetes Service
- Azure RedHat OpenShift (ARO)
- OpenShift Container Platform (OCP)
- AWS Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Kubeadm を使用して通常デプロイされるオープンソースのアップストリーム Kubernetes
Azure 以外のクラウドサービスが記載されているのが特徴的ですね。
Azure Arc enabled Data Services を展開するためには、最初に、k8s 上に Data Controller の展開を行います。
Data Controller の展開方法
Data Controller の展開方法については、いくつかのパターンが提供されています。
kubectl で展開するパターン についても公開されており、Data Controller を展開する際に使用する YAML については、https://github.com/microsoft/azure_arc/tree/master/arc_data_services/deploy/yaml で公開されています。
どのようなリソースが作成されるかについては、YAML を展開しながら眺めると良いのではないでしょうか。
最初に、Custom Resource Definition (CRD) の展開を行います。
これにより、次の CRD が追加されます。
CRD の追加が完了したら、Arc 用の Namespace を追加し、bootstrapper service を展開します。
bootstrapper service は、 data controller を展開するためのコントローラーとなります。
bootstrapper service の展開が終わったら、data controller を展開します。
bootstrapper service は、「kind: datacontroller」のリソースが展開されると、Azure Arc enabled Data Services に必要な Pod の展開を開始します。
以降は、bootstrapper service によって展開が行われた data controller 内の Pod が Controller として動作するようになり、展開する DBaaS の Custom Resource に応じた、DB が展開されます。
今回は、SQL Server ベースの環境しか触れていませんが、CDR としては PostgreSQL 用の定義も追加が行われます。
SQL Managed Instance については、1 バージョンのみですが、PostgreSQL については、11/12 を選択することができます。
詳細については、Azure Arc 対応 PostgreSQL Hyperscale とは から確認することが可能です。
Azure Arc enabled Data Services で展開される PostgreSQL については Hyperscale (Citus) が使用されるため、スケーラビリティについては、現時点では、SQL Managed Instance より、PostgreSQL Hyperscale のほうが高いかと。(SQL Database Hyperscale が展開できるようになるとうれしいんですけどね)
Azure との接続
Data Controller の展開が完了すると、k8s と Azure Arc を接続することが可能となります。
Data Controller が Azure と接続するための方法は 3 種類が提供されます。
- 直接接続
- 間接接続
- 非接続
現在、プレビューで利用可能なのは、間接接続のみとなっています。
間接接続も Azure と接続が行われた環境なのですが、Azure との接続については、常時接続されている状態ではなく、利用者が定期的に接続の状態を Azure にアップロードする必要があります。
そのため、
- Azure Portal に対して、リソースの使用状況を反映するためには、エクスポートしたデータをインポート
- Azure Portal からリソースの展開をすることはできず、リソースの展開は k8s に対して直接実施
というような、いくつかの機能制限があります。
各モードの操作性の違いについては接続モードと要件に記載されていますが、「直接接続」がサポートされるようになると、Azure Portal を起点として、Azure の一リソースとして Azure Arc を使用して Data Services を操作することができるようになるようです。
接続モードは課金にも影響しますので、課金データを Azure にアップロードして Azure portal に表示する の情報も接続に関する情報となります。
Azure Arc enabled SQL Managed Instance
Azure Arc enabled SQL Managed Instance は、Azure Arc Data Controller がインストールされている k8s に対して、Managed Instance を展開することができます。。
次の画面は、Azure Data Studio で、Data Controller に接続し、新しいインスタンスを作成する画面です。
現状、Azure Portal からの展開はできませんが、Azure Data Studio を使用することで、GUI で展開することも可能です。
Data Controller が展開されている環境には、次の 3 つの方法で SQL Managed Instance を展開することができます。
SQL Managed Instance の場合、CRD は「kind: sqlmanagedinstance」のリソースとなります。
このカスタムリソースを展開すると、Data Controller の展開時に展開されたコントローラー (control-xxxx) が、リソースの要求を処理するようです。
bootstrapper の説明には次のようにあります。
Create the bootstrapper service
The bootstrapper service handles incoming requests for creating, editing, and deleting custom resources such as a data controller, SQL managed instance, or PostgreSQL Hyperscale server group.Run the following command to create a bootstrapper service, a service account for the bootstrapper service, and a role and role binding for the bootstrapper service account.
bootstrapper が Operator の Controller としての動作を行い、要求を Data Controller に連携することで、実際のインスタンスのデプロイが行われているのかもしれませんね。
実際に展開した環境がこちらになります。
現在、Data Controller は「間接接続」のみをプレビューとして提供していますので、展開した環境が即時ポータルに反映されるのではなく、使用状況をエクスポート/インポートすることでポータルに取り込みが行われているのですが、Azure の 1 リソースとして、Azure Arc の Managed Instance が認識されていますね。
今回使用している k8s はオンプレミス上に構成しているものとなります。
このように、k8s が動作していれば、Azure 以外のインフラストラクチャに対しても、SQL Managed Instance を展開することができます。
展開した Managed Instance は Pod として展開が行われています。
SQL Server 2019 の Big Data Cluster も似たような構成になっているのですが、Pod 内は次の 3 種類のコンテナーで構成されています。
- arc-sqlmi
- fluentbit
- collectd
Azure Arc enabled Data Services には、メトリックを確認するための Kibana と Grafana が展開されており、展開した SQL Managed Instance の Pod のメトリックが自動的に収集されます。
展開した環境に対して、バージョン情報を取得したものがこちらになります。
Managed Instance が展開されていることが確認できますね。
最新の Azure Data Studio では、Azure Arc enabled Data Services にも対応しており、どのような環境が展開されているかなどを Azure Data Studio 上から確認することもできます。
SQL Server では、2017 以降は、コンテナーに対応していますので、今までのバージョンの SQL Server でも k8s 上に展開することはできました。
しかし、この展開については、インストールタイプの SQL Server を展開するものですので、SQL Server のバージョンは固定であり、管理についても利用者側で考慮する必要がありました。
しかし、Azure Arc enabled Data Services で展開されたデータベースは、Azure の PaaS の Data Services と同様の管理となります。
つまり、環境の更新については、PaaS のサービスとして自動的に頻繁に行われるようになります。
(この辺はポリシーで更新タイミングを制御できるようになるようですが)
つまり、様々なインフラストラクチャ上で実行している SQL Managed Instance については、Azure の SQL Database のように常に最新のバージョンが保たれるようになり、サポート切れを考慮する必要がなくなるということになります。
現在、利用可能な機能についてはAzure Arc 対応 SQL Managed Instance の機能に記載されており、いくつかの機能制限があります。
最終的には、現在 PaaS として提供されているAzure SQL Managed Instance (MI) と同様の管理性が持てるのではないかと思いますが、現在の利用可能な機能の中では PaaS の MI と比較して、基盤側で自動化されている個所が少ないようですので、どの程度 PaaS に近づくのかは今後も情報をキャッチアップする必要があります。
様々なインフラストラクチャ上で実行されている k8s に対して、Azure に接続を行い、SQL Managed Instance を展開し、PaaS の運用性を提供 することがができるのが Azure Arc enabled SQL Managed Instance となります。
Azure Arc を使用することで様々なインフラストラクチャに対して Azure の SQL Server の管理性を提供することができるようになります。
Managed Instance の自動バージョンアップなどはかなり興味深いものがありますので、今後も情報をキャッチアップしたいですね。