蒼の王座

Windows Azure SQL Database Servicesの2012年7月アップデートの内容がBlogに投稿されていたので紹介します。

SQL Data Syncを使用してFederationの参照テーブルをレプリケーションできるようになりました

SQL Azure Federationでは、メンバーデータベースに参照テーブルを含めることができます。
一度、SPLITで分割したメンバーデータベースに含まれる参照テーブルは互いに独立したテーブルなので、
片方を更新しても、もう片方には変更は反映されません。

その為、これまでは手動でメンバーデータベースの数だけ参照テーブルを更新する必要がありました。
例えば、メンバーデータベースが30個あった場合、30回参照テーブルを更新しないと、
全ての参照テーブルに変更を反映させることができません。

2012年7月のアップデートにより、SQL Data Syncで、メンバーデータベースの参照テーブルを同期対象に設定できるようになりました。

上の図のように、メンバーデータベースを同期グループに登録することができます。
同期したいメンバーデータベースの参照テーブルとSQL Data Syncのハブデータベースとを同期するように設定します。

同期設定をすると、次の図のようにメンバーデータベースをすべて同期するように設定できます。

とは言え、制限事項もあります。

• レプリケーション間隔は短くても5分なので、最大5分の同期遅延があります。
• スクリプトによる同期レプリケーションの設定をすることができません。
  つまり、同期設定をしたい場合は、GUIで手で設定する必要があります。20個同期するなら20回。。。
• 最大でも30個までしか、同期グループに設定できません。

参照テーブルで一意のIDを生成するのにIdentityプロパティを使用できるようになりました

2012年7月のアップデートで、フェデレーションメンバーの参照テーブル上でIdentityプロパティを使用できるように、制約を解除しました。
これにより、スキーマの変更を最小限に、既存のデータベースからフェデレーションへの移行ができるようになります。

参照元

Newsflash: Reference Data Management Simplified in Federations with the July 2012 Update to SQL Database! Reference Data Replication with Data Sync Service, Unique ID Generation for Reference Data and more…

Windows Azure SQL Databaseは、インターネット上で提供されるデータベースサービスです。
セキュリティを確保するため、SQL Databaseに接続することができるIPアドレスを制限する機能として、Firewallが提供されています。

SQL Databaseがリリースされた当初から今まで提供されていたのは、SQL DetabaseサーバーレベルのFirewallでした。SQL Databaseサーバーに接続することができるIPを指定すると、SQL Databaseに含まれるすべてのデータベースに接続することができました。

これまではできなかったデータベース個別のFirewall設定ができるようになり、SQL Databaseに含まれる特定のデータベースだけにしか接続できないIPを設定することができるようになりました。

概要

Azure SQL Databaseに接続をする場合の挙動が、今後次のようになります。

1. サーバーレベルのFirewallルールで許可されたIP範囲の中に、リクエスト元のIPアドレスが含まれていれば、SQL Databaseへの接続が許可されます。
2. サーバーレベルのFirewallルールにリクエスト元のIPアドレスが含まれていない場合は、データベースレベルのFirewallルールをチェックします。リクエスト元のIPアドレスが、データベースレベルのFirewallルールで許可されたIP範囲に含まれていれば、データベースレベルのルールと適合したデータベースだけ接続が許可されます。
3. サーバーレベルもしくはデータベースレベルのFirewallルールで許可されたIP範囲の中に、リクエスト元のIPアドレスが含まれていない場合、接続は失敗します。

データベースレベルのFirewallルール制御

今のところGUIでの制御画面が提供されていないので、設定したいデータベースに対してT-SQLクエリを発行することで設定します。

ルールの確認

select * from sys.database_firewall_rules

ルールの作成

exec sp_set_database_firewall_rule N’Example DB Setting 1′,’0.0.0.4′,’0.0.0.4′

ルールの更新

exec sp_set_database_firewall_rule N’Example DB Setting 1′,’0.0.0.4′,’0.0.0.5′

ルールの削除

exec sp_delete_database_firewall_rule N’Example DB Setting 1′

次の図は、未設定、作成、更新、削除をした、それぞれのタイミングで確認クエリを発行したときの内容です。

FederationメンバーDBへの影響について

データベースレベルのFirewallルールを設定したルートデータベースに、Federationを作成した場合、
フェデレーションメンバーデータベースには、データベースレベルのFirewallルールはコピーされません。

フェデレーションメンバーデータベースで、データベースレベルのFirewallルールを定義する必要がある場合は、個別にデータベースレベルのルールを作成する必要があります。

フェデレーションメンバーデータベースにデータベースレベルのFirewallルールを定義してある状態で、メンバーデータベースをSPLITすると、新しいメンバーデータベースにもFirewallルールが複製されます。

参考・元情報

• Control access at the database level using the improved Windows Azure SQL Database firewall rules
• Windows Azure SQL Database Firewall
• How to: Configure the Database-Level Firewall Settings (Windows Azure SQL Database)

Windwos Virtual Machineが、反応無くなったり、ディスクが読み取り専用になった時、
ポータルもしくはスクリプトで仮想マシンを再起動します。
大抵の場合、これで問題が解決し、仮想マシンは健全な状態に戻ります。

仮想マシンを再起動しても、仮想マシンが「Stopping」のまま止まり続けていることがあります。
この場合は、仮想マシンを削除し（ポータルで、「Delete」ボタンをクリックします）、
使用していたのと同じVHDディスクを使用して再度デプロイします。

さらに同じDNS名を使用したい場合は、前のDNS名を解放するために
仮想マシンで使用していたDNS名をポータルでクラウドサービスから削除する必要があります。

情報源

VM becomes unresponsive or disk becomes read-only

Virtual Machine名とホスト名とDNSの関係

 

Virtual Machineを作成する際に、Virtual Machine Nameを指定します。
ここで指定したVirtual Machine NameがLinux上のホスト名に登録されます。Linux上で、「> hostname」とコマンドを打って返ってくる文字列となります。

AzureのインターナルのDNSにも登録され同じDNS名に登録された仮想マシン間であれば、直接通信できます。DNSが名前解決してくれるので、Virtual Machine名で通信できます。

仮想マシン作成直後は、

Virtual Machine Name＝ホスト名＝DNS登録名

となっています。しかし、手動でホスト名を変更しても自動では、Virtual Machine Nameに反映されないため、ズレが発生してしまいます。
今のところ、仮想マシンを作成した後にVirtual Machine名を変更する術が提供されていないようなので、
後から変更はできないようです。
そのため、後からLinux上のホスト名を変更しても、他の仮想マシンから変更後のホスト名では接続することができません。

/etc/resolv.conf ネームサーバーの設定

次のような感じで設定されています。

; generated by /sbin/dhclient-script
search 2d2eae9005.test.27672059.asiaeast.internal.cloudapp.net
nameserver 10.146.190.200

Linuxのイメージを作成する方法

1．初期化処理を実行する

Linuxのイメージを作成するには、WindowsのSysprep的な処理を実行する必要があります。
Linuxでは、Windows Azure Linux Agentが、その機能を提供しています。

次のコマンドを実行すると、必要な初期化をしてくれます。

sudo waagent –deprovision

コマンドを実行すると、次のような警告と処理継続の確認が表示されます。

• waagentサービスは停止します
• 全てのSSHホストキーのペアーは削除されます
• /etc/resolv.conf ネームサーバーの設定を削除します
• DHCPリースのキャッシュを削除します
• rootのパスワードを無効化します。rootでログインできなくなります。

この処理をすることで、ホスト名が初期化されます。この処理を飛ばすとホスト名が初期化されないため、イメージから仮想マシンを作成する際にVirtual Machine名を指定したものにならず、同じホスト名のままになり、2つ以上作成できないという悲劇が待っています。

確認方法として、$ cat /etc/sysconfig/network を確認すると、hostname が localhost.localdomain に変更されていることが重要と思われます。補足として、/etc/sysconfig/network-scripts/ifcfg-eth0 や /etc/resolv.conf も書き換えられます。

2．仮想マシンを停止し、Captureを実行する

仮想マシンのコンソールから抜けて、仮想マシンをシャットダウンします。

Captureボタンをクリックします。

ダイアログが表示されるので、「I have run the de-provision command on the virtual machine」にチェックを入れ、イメージ名を指定します。
「I have run the de-provision command on the virtual machine」のチェックは必須になっており、チェックを入れずにクリックしてもバリデーションチェックに引っかかります。
ちなみに、手順1をすっ飛ばして、ここのダイアログでチェックを入れてイメージを作成してもイメージは作成されます。しかし、初期化処理が不十分なため、イメージから2つ目以降の仮想マシンを作成しようとしても2つ目以降は正常に作成が完了しません。

イメージから仮想マシーンを作成したときのユーザとパスワード

キャプチャーをしようとしている仮想マシンには、仮想マシンを作成する際に指定したユーザーが存在しています。このユーザーは、キャプチャーしてイメージを作成した際に削除されません。

そのためキャプチャーしたイメージから新たに仮想マシンを作成する際に、管理者アカウントに別のユーザーを指定すると、ユーザーが追加で削除され、新旧の管理者アカウントが残ります。

上の図で、gloopsとnoraというユーザーがいることがわかります。
gloopsはイメージを作成したときに使用した仮想マシンの管理者アカウントです。
noraは、キャプチャーしたイメージから新たに仮想マシンを作成するときに指定した管理者アカウントです。

仮想マシン名とDNS名

次の図のように、仮想マシンは、DNS名に紐づきます。
同じDNS名に登録されている仮想マシン間はVirtual Machine名で直接通信でき、エンドポイントの設定に関わらずすべてのポートと通信することができます。。別のDNSにある仮想マシン間では、直接通信できません。
test01から、test03に通信するにはDNS名（example.cloudapp.net）でグローバルから接続する必要があり、その際には、エンドポイントで指定したポートでのみ通信できます。

参考

How to Capture an Image of a Virtual Machine Running Linux

高い可用性をもったWebアプリケーションやサービスを構築する必要がありますか？
柔軟に簡単にスケールアウトさせたいですか？
スキーマーフリーのリッチなオブジェクトに対して複雑なクエリが必要ですか？
もし、これらの質問にYesっという回答であれば、MongoDB on Windows Azure をお勧めします。

MongoDB Installer for Windows Azure のリリースによってセットアップ、デプロイがとても快適になります。

MongoDB

MongoDBは、とても有名なNoSQLデータベースです。
Node.jsまたはJavaScriptの経験があるのであれば、学習するのはとても簡単です。
データベース管理用のJavaScriptベースのShellは、データ更新やクエリはJSON形式で、
サーバー上で、JavaScriptベースのmap/reduce操作をすることができます。

MangoDBを学習するには、「Quickstart guides on MongoDB.org」、「MongoDB.org tutorial」を参照するのがお勧めです。

MongoDB Installer for Windows Azure

MongoDB Installer for Windows Azure は、Windows Azure Virtual Machine上にMongoDBのレプリカのデプロイとプロビジョニングを自動的に実施するWindows PowerShellスクリプトのコマンドラインツールです。
DNSプレフィックスとノードをなどいくつかの指定をすると、インストーラーはVirtual Machineをプロビジョニングし、MongoDBをデプロイし設定をします。

「How to deploy a PHP application using MongoDB on Windows Azure」で、使用方法を学んでください。PHP開発者でMongoDBを使用する人は、「MongoDB tutorial on php.net」を参照してください。

Microsoft Open Technologiesチームは、Windows Azure上でのMongoDB開発経験の改善をし続けます。

参考

元ネタは、MongoDB Installer for Windows Azureです。