SQL Server を Winodws Azure Virtual Machine で動作させるときの留意事項などのメモを。
Contents
■Azure VM の SLA
Azure VM の SLA ですが、サービス レベル アグリーメント に以下のように記述があります。
インターネットに接続するすべての仮想マシンに、同じ可用性セットにデプロイした 2 つ以上のインスタンスがある場合、99.95% 以上外部に接続されることを保証します。
同一の可用性セットを設定した仮想マシンを使用することで SLA の対象となります。
SQL Server の場合は、同一の可用性セットに設定した場合は各仮想マシンでデータの同期をとる必要が出てきます。
データ損失をなくして、データの同期をする場合には同期モードのミラーリングか AlwaysOn 可用性グループを同期モードで設定する必要が出てきます。
■インスタンスのサイズ
SQL Server のインスタンスで利用可能なメモリのサイズは VM のインスタンスサイズに依存します。
VM で使用できるメモリのサイズは以下に記載されています。
Virtual Machine and Cloud Service Sizes for Windows Azure
また、インスタンスサイズによってネットワーク帯域の上限が異なるため、データ転送量が多い場合にはインスタンスのサイズを変更する必要が出てきます。
VM ではディスクを追加することができますが、各ディスクの最大の IO/Sec についてもディスク単位で決まってきますので、この辺も注意が必要になってきそうです。
■ネットワークの構成
レイテンシーを極力なくすために SQL Server へのアクセスは Virtual Network で同一のクラウドサービス内に完結するようにすることが望ましいです。
# ~.cloudapp.net による名前解決でなく、ホスト名で名前解決を可能にし、ネットワークのトラフィックを内部で完結させる。
同一の可用性グループ (Availability Group) にすることで物理的に近い位置に配置されるようになるのでレイテンシーを抑えることができるようになります。
Web ロール / Worker ロールでも Virtual Networkは使用できますので、VM 以外のロールで SQL Server にアクセスする場合にはこれらのロールも同一の可用性グループ (仮想ネットワーク) に設定してレイテンシーを抑えることも検討する必要があるかと。
# Web ロール / Worker ロールで cscfg を設定することで仮想ネットワークに参加させることができます。
■ディスクの構成
データファイルとログファイルの一貫性を保つために [書き込み] のキャッシュは使用せずキャッシュ設定は [読み取り] を使用する必要があります。
いろいろな資料を見たところ 数 GB 程度であれば OS のディスクにデータベースのファイルを配置することも検討の余地があるようですがそれを超える場合には、データベースを配置するための専用ディスクを用意する必要が出てきます。
# OS のディスクにデータベースを配置する場合は、PowerShell で OS のディスクのキャッシュを読み取りにして仮想マシンを作成するか、ポータルから作成した後にキャッシュの設定を変更する必要があります。
追加できるディスクですが私が検証した限りでは、キャッシュを有効にできるディスクの追加は最大で 4 本までとなるようでした。
5 本以上ディスクを追加しようとすると以下のようなエラーが表示されました。
読み取りのディスクは、
- OS ディスク × 1
- 追加のディスク × 4
が最大の構成となるようですね。
以下は PASS のセッションで説明されていたディスクの構成となります。
- VM に接続できるディスクの 1 本あたりのサイズは 1TB が上限となるため、XL または A7 のインスタンスで最大 16TB まで増設可能
- ディスクを格納するための新しいストレージアカウントを用意する
- トランザクションログを配置するディスクを個別に用意する
- 複数のデータファイルを複数の VHD に分割して配置する
# この際に異なるストレージアカウントを使用することも検討する - ソフトウェアレベルでのストライピングは推奨しない
- トランザクションログには書き込みキャッシュは使用しない
- D ドライブは非永続化領域のため、データまたはログファイルは配置しない
- C ドライブにデータベースのファイルを配置するのは避ける
ストレージアカウントには Windows Azure’s Flat Network Storage and 2012 Scalability Targets に記載されているような性能指標があるため、複数のデータファイルを配置する場合にはストレージアカウントを分けることも考慮する必要があります。
ストレージの地域レプリケーション (ジオレプリケーション) は、一貫性を担保するためにデータファイルとログファイルが同じディスクに配置されている場合のみ使用することができます。
Geo-replication not supported for data and log files on separate disks
■tempdb の配置
tempdb はサービスの再起動が発生するタイミングで初期化されるため、非永続化領域である D ドライブに配置することができます。
ただし、D ドライブのディスクは初期化されることが想定されるため、初期化時にデータベースを配置するためのフォルダを作成することも考慮する必要があります。
また、ドライブの直下への作成は権限が付与されていないとできないことがあるため、ローカルシステムアカウントを使用していない場合には SQL Server のサービスアカウントでドライブ直下に tempdb が作成できるかはテストをする必要があります。
このあたりの情報については Change TEMPDB to Temporary Drive on Azure SQL IaaS に詳しく記載されています。
■リストアに関しての設定
SQL Server 2012 SP1 CU2 からバックアップを Azure Storage へ取得することが可能となっていますので、この方法を使用してバックアップを取得することも検討します。
この際、バックアップ圧縮を利用してネットワークトラフィックを抑えることも有効です。
リストアについてですが、高速化するために瞬時初期化の機能を有効にすることもポイントになってくるかと。
Azure Storage にバックアップを取得する場合はブロックサイズを [BLOCKSIZE = 65536] を指定して変更、トレースフラグ 3051 を指定して、Azure Storage にバックアップを取得 (TO URL を指定) した際のログを追加で出力することも検討するとよさそうですね。
バックアップとリストアに関しては バックアップと復元に関するベスト プラクティス (Windows Azure BLOB ストレージ サービス) にまとめられています。
■可用性構成
同一のディスクにデータファイルとログファイルを格納した場合は一貫性が保てるのでジオレプリケーションを使用することができます。
ジオレプリケーションはファイルを他地域に保存することでの冗長化 (サイト障害) になるかと思いますので、即時に切り替えをしたい場合は、SQL Server の可用性ソリューションを使用して冗長構成をとる必要がでてきます。
ダウンタイムを抑えた冗長構成としては
- AlwaysOn 可用性グループ
- ミラーリング
を使用することが考えられます。
AlwaysOn 可用性グループを使用する場合には、AD が必須、自動フェールオーバーを使用する場合にはウィットネスが別に必要となりますので構成については検討する必要が出てきます。
# ミラーリングに関しては AD を使用しなくても構築することができますが、ウィットネスを使用しない場合には自動フェールオーバーは実施することができません。
仮想マシンの SLA (Windows Azure Cloud Services, Virtual Machines, and Virtual Network SLA) では以下のように定義されています。
「最大接続時間 (分)」とは、同じ可用性セットに展開された 2 つ以上のインスタンスを持つ、すべてのインターネット向け仮想マシンの請求月の合計累積時間 (分) です。最大接続時間 (分) は、同じ可用性セット内の 2 つ以上の仮想マシンのすべてが、お客様によって開始された操作の結果として起動した時点から、仮想マシンを停止または削除する操作をお客様が開始した時点まで計測されます。 "
同一の可用性性セットに展開された 2 つ以上のインスタンスを持つ仮想マシンが対象となるため、この点には留意するひつようがあります。
AlwaysOn 可用性グループに関してはリスナーの IP をエンドポイントとして設定することが投稿時点ではサポートされていないため、プライマリサーバーに直接接続の方式をとる必要がでてきます。
# 負荷分散エンドポイントを使用せずに Virtual Network 内部のアクセスであれば使えそうな気もしますが。
セカンダリレプリカが 1 台の場合は、可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server) に記載されているようにデータベースミラーリングの接続文字列を使用することで代替できるはずですのでこの辺を利用することを検討してもよいかもしれないですね。
# この辺りは別途検証したいと思います。
SQL Server on Windows Azure VM は技術情報もかなり出ており、Microsoft もかなり力を入れていきそうな感じが個人的にしているので、きちんと検証していきたいと思います。
■参考
- SQL Server in Windows Azure Virtual Machines
- Performance Considerations for SQL Server in Windows Azure Virtual Machines
- Change TEMPDB to Temporary Drive on Azure SQL IaaS
- High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines
- Windows Azure Cloud Services, Virtual Machines, and Virtual Network SLA
- NetworkConfiguration Schema
- Windows Azure Name Resolution
- SQL Server in Windows Azure Infrastructure Services ? Updated Documentation and Best Practices for GA, Upcoming Blogs
- Microsoft server software support for Windows Azure Virtual Machines
- ハードウェア仮想化環境で実行している Microsoft SQL Server 製品のサポート ポリシー
- SQL Server のローカル言語版
- バックアップと復元に関するベスト プラクティス (Windows Azure BLOB ストレージ サービス)
- Windows Azure 仮想マシンの正式リリースまだか!!SQL Server 編
- SQL Server in Windows Azure 仮想マシン 関連ドキュメントアップデートのお知らせ
- Windows Azure インフラストラクチャ サービス内で実行される SQL Server ? 一般提供開始に合わせたドキュメントおよびベスト プラクティスの更新と、今後のブログ記事について
- Performance Guidance for SQL Server in Windows Azure Virtual Machines
いつも貴重な情報ありがとうございます。
ExtraSmallの帯域が他にくらべすごく小さいことに驚いております。
Virtual Machine and Cloud Service Sizes for Windows Azure
http://msdn.microsoft.com/ja-jp/library/windowsazure/dn197896.aspx
リンク先を参照したところ「Allocated Babdwidth(Mbps)」の項目が現在は表示されていません。
なにかAzure側で問題があったのかなあと勘ぐっている次第です。
みうらひろし
27 6月 13 at 12:26