SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Azure Stack TP3 の SQL Hosting Server / SQL Databases の構成を把握する

leave a comment

Azure Stack TP3 の環境を、SQL Server resource provider adapter がインストールされている状態で、お借りすることができたので、TP3 時点の Azure Stack では、どのような構成で、SQL Server を使用することができるのかをまとめてみたいと思います。
SQL Server 向けのリソースプロバイダー (以降、SQL RP) については、次の情報から確認することができます。
Use SQL databases on Azure Stack
本投稿は、Azure Stack も SQLRP もどちらも Preview の内容ですので、今後変更があるかもしれないということはご了承ください。
また、管理用のポータルで構成を把握するための検証をしているため、エンドユーザーに利用する場合の方法については本投稿では基本的に触れていません。
大事なことを書いておくと、この? SQL RP で提供される SQL Server のデータベースは、

The resource provider does not support all the database management capabilities of Azure SQL Database. For example, elastic database pools and the ability to scale database performance aren’t supported.

となっていることです。
Azure では「SQL Database」として、PaaS 型の DB が提供されており、Azure Stack では、この SQL RP により提供される DB が Azure Stack 版の SQL Server の PaaS 型 DB に相当すると思うのですが、この二つの機能は大きく異なっています。
SQL Database は、SQL Server のデータベースエンジンと同等のものを使用していますが、Azure に適応された形でカスタマイズがされている「SQL Server のデータベースエンジンを使用している Azure に適応したものとして開発が行われたデータベース」です。
たいして、Azure Stack の SRP 提供されるデータベースは「製品版 (Box 版) の SQL Server を使用して SQL Server 内のデータベースを切り出した形て提供をする」ものとなっています。
そのため、SQL RP で使用する SQL Server の管理や、構成などについてもすべて、Azure Stack の提供側で考慮する必要があり、ドキュメントにも書かれているように、Elastic Pool や、データベース単位のパフォーマンスの制御機能といったものは標準の仕組みとして、現時点のプレビューの段階では提供されていません。
SQL Server のリソースガバナーと組み合わせた形で今後提供されるかもしれませんが、現時点の実装では、次のようなことは、リソース提供側で考慮する必要があります。

  • サーバーの管理 (バックアップを含めた運用)
  • 冗長構成 (AlwaysOn 可用性グループ等を利用した、SQL Hosting Service のサーバーの構築)
  • データベース毎のリソース制御 (CPU / メモリ / ディスク I/O)
    (データベースのサイズの制御は、Azure Stack 側で実施できます)
  • tempdb の利用状況 (複数のデータベースは同一の tempdb を使用します)

SQL RP による提供される SQL Database の構成の全体がいようとしては、次の図のような感じでしょうか。
image

■リソースプロバイダーの導入


リソースプロバイダーの導入については、実施した状態でお借りしていますため、私の方では実施できていないのですが流れについては、冒頭で紹介したドキュメントに記載がされています。
プロバイダーを導入するための PowerShell のスクリプトが提供されており、それを Azure Stack のホスト (物理環境) で実施することで、Azure Stack にリソースプロバイダーの導入が行われるようです。
導入が終わると、リソースプロバイダーとして「SQLAdapter」が登録され、これが、Azure Stack の SQL Database をホスティングするためのプロバイダーとなるようです。
image
このプロバイダーをインストールする際には、仮想マシンの作成も同時に行われています。
スクリプトでは「VmName」を指定している仮想マシンですが、この仮想マシンに SQL Server がインストールされ、SQL RP の管理情報が登録されるようになっています。
SQL Server 2014 の評価版 (Enterprise Evaluation) がインストールされているようですね。
(スクリプトの実行時変数で、SQL Server のインストールメディアは変えられそうですが、デフォルトでは評価版の ISO を DL して使用しているようです)
現状の Preview 版でしたら、これで問題はないですが、本番環境として使用する場合にはリソースプロバイダーの管理情報を格納するために使用する SQL Server についても考慮する必要があるかと。
実際に SQL Server に接続すると、DB を確認できるのですが、「AzureStack-SqlServer」というデータベースで SQL RP の情報を管理しているようで、この DB に「SQL Hosting Servers」や「SQL Databases」、「SKU」の情報などが登録されているようです。
image
このサーバーを後述する「SQL Hosting Servers」のサーバーとして登録することもできるのですが、管理用サーバーですので、このサーバーとは別の SQL Server で Database のサービスを提供していくことになるのが一般的な構成でしょうね。
 

■SQL Server のデータベースを提供するための 2 つの構成要素


リソースプロバイダーを導入することで 2 つの機能を提供することができるようになります。
以下は、「Data + Storage」の内容となりますが、SQL Server に関連するものとしては、次の 2 つがあります。

  • SQL Hosting Server
  • SQL Databases

image
SRP で提供されるデータべースは「SQL Databases」となりますが、これは単体では利用することはできません。
データベースを作成する先となる、SQL Server の仮想マシンを「SQL Hosting Server」として登録をしておき、このサーバー上にデータベースを作成することになります。
それでは、これらについてみていきたいと思います。

■SKU を登録する


最初の作業としてはサービスを提供する際に選択をさせる SKU (Stock Keeping Unit) を登録する必要があります。
SKU については、SRP の「すべての設定」から登録することが可能です。
image
SKU には以下の情報を登録します。

  • Name : SKU の名称
  • Family : SKU に含まれている SQL Server の情報
  • Tier : サービス階層 (スタンドアロンか HA かといった情報)
  • Edition : SQL Server のエディション

image
ちなみにこれらの情報は管理用のラベル扱いですので、実際に使用される SQL Server とは異なる情報を設定しても動作します。(スタンドアロンの SQL Server に HA という Tier を設定することもできます)
次に登録する SQL Hosting Server は「1 つの SKU に必ず関連づける必要がある」ということがポイントでしょうか。
SQL Hosting Server に登録する SQL Server の情報を SKU として設定するということがわかっていればいいのかなと。
 

■SQL Hositing Server とは


SKU の登録が終わったら、SQL Hosting Server に SQL Server の登録を行います。
SQL Hosting Server は、データベースを切り出す SQL Server がインストール済みの仮想マシンを指定する必要がありますので、事前に SQL Server インストール済みの仮想マシンを準備しておく必要があります。
そのため、冗長構成をとった環境として、SQL Database を提供する必要があるのであれば、AlwaysOn 可用性グループの構成で構築した SQL Server を事前に構築しておく必要があります。
(現時点の SQL RP では、自動的に冗長構成を持ったデータベースを提供するような仕組みはありません)
今回は、「パブリック IP とパブリック IP の DNS 名を持つ SQL Server 2017 CTP 2.1 インストール済みの仮想マシン」を事前に準備しています。
SQL Server Hosting Server の登録の流れは、以下に書かれているのですが、Hosting Server に設定するための SQL Server の準備の方法については記載がないのですよね…。
Provide capacity by connecting to a hosting SQL server

  • SQL Server インストール済みの仮想マシンを準備
  • TCP 1433 によるアクセスを許可しておく

あたりが設定できていればひとまず登録はできそうです。
SQL RP からのアクセスは確実に行っていると思うのですが、ほかにどのサーバーからのアクセスが最低限必要なのかといった細かなセキュリティ設定までは確認ができてません。
また、名前付きインスタンスが使えるのかも現時点では未確認です。
ネットワークについては、今回はパブリック IP 経由でのアクセスが可能な環境としているのですが、内部 IP のみでのアクセスも可能なのか (特定の VNET 向けの SQL Hosting Server の提供) も現時点では確認できていません。
「どのネットワーク向けに提供する SQL Hosting Server なのか」ということをどのようにして制御するかは実運用での考慮点になりそうですね。
Hosting Server の登録は SQL RP のブレードの Hostinge Server のタイルや、新規追加の SQL Hosting Servers のどちらでも実施することが可能です。
追加を行う際の設定画面は以下となります。
image
IP アドレス / ポート番号の指定ができるので名前付きインスタンスを固定ポートでサービスしておけば、名前付きインスタンスでの提供できそうではありますが、今は未確認です。
冗長構成をとりたい場合には、AlwaysOn 可用性グループのリスナーをここで指定すれば、冗長構成がとられたデータベースの提供を行えると思うのですが、Azure Stack のロードバランサーから可用性セットを指定する方法がわからず、今のところは作業がとん挫しています…。
Hosting Server の登録時には、「Size of Hosting Server in GB」を設定でき、そのサーバーでは何 GB まで、データベースの合計領域を作成することを許可するかを指定できます。
この設定は「Azure Stack 経由でデータベースを作成する際の制限」として動作するため、設定が SQL Server 内の何らかの設定と同期しているかというとそういうことはないようです。
Azure Stack 経由では、SQL RP 側で管理されている Hosting Server の DB 上限以上、DB で領域を使用しようとすると、エラーとなりますが、極端なことをするとすれば、「SQL Server に直接ログインして指定したサイズ以上、データベースの領域として作成することが可能」となっています。
Hosting Server を作成する際に、SKU を指定します。
SKU については「1 つの SKU に複数の Hosting Server を登録することが可能」となっています。
1 つの SKU に複数のサーバーを登録した場合、各サーバーの容量の使用状況を考慮して、データベースを配置するサーバーの分散が行われていそうな感じでした。
SKU はサービスの提供のレベルとともに、SQL Server のサーバープールとしても使用することができそうな感じですかね。
正常に登録が行われると指定した SQL Server に「SqlResourceProviderLogin」という sysadmin のロールを持つログインが登録されます。
以降、SQL RP からの操作要求はこのログイン経由で実施されるのでしょうね。
これでデータベースを作成するサーバーができましたので、次に SQL Database を作成します。
 

■SQL Databases とは


こちらは Hosting Server 上に作成されたデータベースとなり、エンドユーザーはこのリソースの作成を行う形になるのかなと。
SQL Hosting Server は SQL Databases をホストするサーバーですので、この作成自体はエンドユーザーに許可をするのではなく、リソース提供側でしか作成できないようにする必要がある気もしますね。
作成のブレードの内容は次の図のような内容となります。
image
データベースを作成する際には Hosting Server を指定するのではなく SKU を指定することで、データベースの作成場所 (作成されるサーバー) が決められることになります。
ここで「Max Size in MB」を指定するのですが、このサイズについてはもどのサーバーに配置されるかの判断基準になるかと。選択している SKU に指定したサイズを賄える領域が管理情報上不足していると判断されると作成時にエラーとなるようです。
これでデータベースの作成が行われるのですが、作成時には以下のようなクエリが実行されています。

USE [master];
SELECT 1 FROM master.sys.sql_logins WHERE name = 'nawagami'
go
USE [master];
SELECT 1 FROM sys.databases WHERE name = 'NawagamiDB01'
go
USE [master];
--*CREATE LOGIN-------------------------------------
go
USE [master];
IF NOT EXISTS(SELECT name FROM sys.database_principals WHERE name = 'nawagami')
CREATE USER [nawagami] FOR LOGIN [nawagami];
go
CREATE DATABASE [NawagamiDB01]
COLLATE SQL_Latin1_General_CP1_CI_AS; ALTER DATABASE [NawagamiDB01]
MODIFY FILE (NAME = N'NawagamiDB01', MAXSIZE = 100MB)
go
USE [NawagamiDB01];
IF EXISTS(SELECT name FROM sys.database_principals WHERE name = N'nawagami')
DROP USER [nawagami];
EXEC dbo.sp_changedbowner @loginame = N'nawagami', @map = false
go
USE [master];
IF EXISTS(SELECT name FROM sys.syslogins WHERE name = N'nawagami')
DROP USER [nawagami];
go

 
実行されている内容としては、次にような内容となります。

  • ポータルで指定した名称のデータベースを作成
  • データベースの照合順序は、ポータルで指定されたものを設定
  • データファイルの最大サイズは、ポータルで指定されたものを設定
  • ポータルで指定した名称のログインを作成
  • 作成したデータベースの [database owner] として、作成したログインを設定
  • master からログインのユーザーを削除

ユーザーがアクセスできるログインと作成したデータベースに対しての管理者権限の付与を実施している感じですね。
これを繰り返すことで、サーバー上にデータベースが作成されていくというのが、SQL RP の仕組みです。
データベース作成時には、データベースの作成パスは指定されていないため、デフォルトのデータベースのパスに作成されます。
データベースに関しては、専用のディスクを追加して、データ / ログファイルのデフォルトの保存先を適切に変更する必要がありそうですね。
image
Azure Stack では ARM テンプレートを使用したデプロイも可能となっています。
Deploy templates in Azure Stack using PowerShell
Check your templates for Azure Stack with Template Validator
とりあえず、一つのリソースグループに 120 個程度のデータベースを作ることもできました。
image
今回は 1 つの SKU に 2 つの Hosting Server を設定していて、同一サイズのデータベースを繰り返し作成していたのですが、それぞれのサーバーに分散されて配置されていました。
image
 
 
 

■SQL RP 利用時の考慮点


ここまで、基本的な環境を見てきましたが、SQL RP により作成されるリソースは「通常の SQL Server からデータベースを切り出したもの」となるため、実際の利用時には様々な考慮点が必要になってきます。
基本的な考えとしては「同一のインスタンスを複数のデータベースが共有している環境である」ことを意識することから始まるのかと。
SQL Database のような論理サーバーの考えがありませんので、サーバーレベルの設定は全データベースに影響を及ぼすことになります。
これは、サーバーレベルの照合順序の観点でも同じことが言えます。
現状、SQL RP のデータベースについては「包含データベース」を使用するような設定となっていませんので、一部の動作についてはサーバーレベルの照合順序に引きずられることになりますので、これを緩和させる必要があるかも検討事項の一つかと。
定期的なバックアップの取得についても考慮点になりうるかと思います。
現状、定期的なバックアップは SQL RP では取得されておらず、ユーザーが BACKUP DATABASE を実行することができてしまいます。
バックアップをユーザーから取得できてしまうと、今後運用のバックアップを実装した場合に細心のバックアップの制御や、ユーザーかサーバーのローカルディスクにバックアップを取得してしまうことによるディスクへの影響を考慮する必要が出てきます。
サーバーのリソース使用の観点も考慮点ですね。
各データベースで使用できるリソース (CPU / メモリ / ディスク IO) を制御していませんので、特定のデータベースで大量のリソースを使用すると、他のデータベースへの性能の影響が発生してきます。
これは、temodb / バッファ , クエリキャッシュにも言えることで、この辺のインスタンスレベルの共有リソースと各データベースの高負荷時の影響も考慮点です。
データベースのサイズについても実は考慮が必要です。
現状、データファイルは MAX 設定が行われるのですが、ログファイルについては行われていません。そのためログファイルの領域の影響でディスクが枯渇する可能性もあります。
また、データファイルについても MAX サイズは設定されるのですが、実はこれ、作成されていたデータベース接続用のログインでデータベースの設定として変更できてしまい、これによりポータルの管理情報との整合性が崩れる可能性があるのですよね…。
複数のユーザーが同一のインスタンス上にデータベースを作成してしまってもよいかの観点も必要となり、利用するユーザーに応じて、個別に SKU を作成して、複数のユーザーのデータベースが同一のインスタンス内に作成されないような考慮が必要となるかについても検討する必要があるかもしれませんね。
 
ざっと触ってみた感じ「SQL Server からデータベースを簡単に切り出して作成できるのは面白いが、実際にサービスとして提供するような場合には、考慮点がいろいろとある」というのが、現状の SQL RP についての感想でしょうか。
ある程度 SQL Server に知見のあるエンジニアと協力して SQL RP によるデータベースリソースの提供を考えていく必要があるのではないでしょうか。

Share

Written by Masayuki.Ozawa

7月 8th, 2017 at 1:02 pm

Posted in Azure Stack

Tagged with

Leave a Reply