以前の投稿で Denali CTP3 の自動フェールオーバーは 1 ペア (2 インスタンス) が最大の構成ということを書きました。
AlwaysOn Availability Groups では設定できるインスタンス数 (レプリカ数) に上限があります。
今回はそのあたりについてまとめていきたいと思います。
おなじみの Tech Ed NA 2011 の DBI404 にこの情報はまとめられています。 
■AlwaysOn Availability Groups のインスタンス構成
概要については以下に記載がされています。
Get Started with AlwaysOn Availability Groups (SQL Server)
Specify from one to five instances of SQL Server to host availability replicas in the new availability group.
AlwaysOn Availability Groups では 5 つのクラスターノードのインスタンスを使用して可用性グループを作成することが可能です。 
ウィザードでは 5 台のインスタンスを選択した段階で [インスタンスの追加] をクリックすることができなくなります。 
以前書いた内容と重複しますが、[レプリカ モード] が [自動フェール オーバー] は 1 ペアしか設定することができません。 
ここまでで構成は以下のようになります。 
レプリカ モードには
- 自動フェールオーバー (同期モード)
- 高い安全性 (同期モード)
- 高パフォーマンス (非同期モード)
の 3 種類があります。
同期モードを使用できるインスタンス数にも上限があります。
AlwaysOn Availability Groups (SQL Server)
A given availability group can support up to three synchronous-commit availability replicas, including the current primary replica.
同期モードを設定できるのは 3 インスタンスとなっています。
そのため、以下のような構成 (5 インスタンスを同期モード) は設定することができません。 
先ほどの図に同期モードの上限を加えると以下のようになります。 
3 つのインスタンスで同期モードを構成する。
SQL Azure の構成と似ていますね。
残りの 2 つのインスタンスに関しては非同期モードで設定することになります。 
最終的な構成はこのようになります。 
5 つのインスタンスを使用して構成した環境のダッシュボードがこちらになります。 
最大で 5 つのレプリカを持つことができ、インスタンスによって異なるモードに設定できるのはミラーリングとの違いでもありますね。 
AlwaysOn Availability Groups は調べることがたくさんです。
この機能の投稿はまだまだ続きます。
蛇足ですが、ミラーリングの同期モードでミラーに更新ができずにエラーを発生させる方法の情報をお待ちしています。
可用性グループの同期モードも同じ仕様のはずなのですが、ミラーリングの知識が乏しいので同期モードで更新が成功しなかった場合のエラーのシミュレート方法が探しきれていないのですよね…。