AlwaysOn 可用性グループで複数の NIC を使用して、複製のトラフィックについては特定のネットワークを利用したい場合の方法をまとめてみたいと思います。
基本的な設定方法についてはデータベースミラーリングも同等です。
WSFC のクラスターリソースとドメインコントローラーの冗長化の必要性についてのメモ
WSFC (Windows Server Failover Clustering) を使用するためには、Active Directory が必要となるため、ドメインコントローラーの準備が必要となります。
検証環境などではドメインコントローラーを冗長構成にしていなくても、検証は可能ですが実運用環境では冗長化されたドメインコントローラーの利用が強く推奨されます。
詳細については DC 停止時の WSFC への影響について が参考になります。
また フェールオーバー クラスター ステップ バイ ステップ ガイド: Active Directory のアカウントの構成 も確認をしておくとよいかと。
Azure の仮想マシンで SQL Server のログファイルを配置するデータディスクを記憶域プールを使用する際の注意点
Azure の仮想マシンでディスクのスループットを向上させる方法として、複数のデータディスクを使用して記憶域プールでディスクを構成する方法があるかと思います。
記憶域プールでは、あとからプールにディスクを足し、ディスクの容量を拡張することができますが、SQL Server のログファイルの用途で使用するディスクについて、性能を向上させるためにあとからディスクを足すのは効果的ではない可能性がありますので、その点についてまとめてみたいと思います。
複数 NIC を持った仮想マシンの作成
複数の NIC を備えた VM の作成
Azure VM での複数の NIC のサポート、Azure へのネットワーク仮想アプライアンスの導入
Microsoft Azure の仮想ネットワーク上に複数NICの仮想マシンを配置してみる
ですでに情報が公開されていますが、まだ触っていなかったのでちょっと試してみました。
割と普通なブログ さんで紹介されている方法は NIC を 2 つ持つ仮想マシン (Large で可能)、MSDN で紹介されている方法は NIC を 3 つ持つ仮想マシン (Extra Large で可能) の作成方法となっているようです。
Read the rest of this entry »
2014年のまとめ
WordPress.com 統計チームは、2014年のあなたのブログの年間まとめレポートを用意しました。
概要はこちらです。
ルーブル美術館には毎年850万人が訪れます。2014にこのブログは約1,700,000回表示されました。ルーブル美術館と同じだけの来場者が訪れるには約73日かかることになります。
ALB と ILB の両方を設定する
Azure Load Balancer (ALB) と Internal Load Balancer (ILB) で同一のパブリックポートは使用できませんが、一つの環境に両方とも作成することができます。
この作成方法についてメモを。
ILB については一つしか作成できないようですので、注意しておいたほうがよさそうですね。
BadRequest: LoadBalancer already exists: AlwaysOnILB. Only one internal load balancer allowed per deployment.
ALB と ILB の両方を可用性グループのリスナーに使いたかったのですが、うまくいったりいかなかったりと挙動が安定しないので、これは別の機会に調査してみたいと思います。
# DNS の解決方法についても考慮が必要になってくるので。
AlwaysOn 可用性グループを Azure 上で構築した場合のリスナーの構成
数回、AlwaysOn 可用性グループを Azure 上で構築した場合の情報を書きてきましたが今回のリスナーの構成でひと段落かなと。
基本的な情報については チュートリアル:AlwaysOn 可用性グループのリスナー構成 に掲載されています。
AlwaysOn 可用性グループを Azure 上で構築する場合の最小構成
AlwaysOn 可用性グループを検証環境用と等で最小構成で構築したい場合のメモを。
この構成は AlwaysOn 可用性グループのフェールオーバーは使用できますが、ドメインコントローラーが SPOF になっていますのでご注意ください。
AlwaysOn 可用性グループをテンプレート展開した場合とチュートリアルを参考に構築した場合の相違点
AlwaysOn 可用性グループを構築する場合、
- Preview ポータルからテンプレートで展開
- チュートリアルを参考に手動で展開
の 2 種類の構築方法が考えられます。
チュートリアルについては Azure の仮想マシン内の SQL Server の高可用性と災害復旧 の一連のドキュメントから確認することができ、初めて構築する場合には以下の GUI ベースのチュートリアルを確認するとよいかと思います。
- チュートリアル:Azure AlwaysOn 可用性グループ (GUI)
# 可用性グループのリスナーを除いた環境を構築することができます。 - チュートリアル:AlwaysOn 可用性グループのリスナー構成
# 可用性グループのリスナー並びに、Azure の負荷分散エンドポイント (Azure (Public) Load Balancer / Internal Load Balanser) を作成することができます。
テンプレート展開された環境とチュートリアルを参考にした環境ではいくつか相違点があるので少しまとめてみたいと思います。
AlwaysOn の検証環境を Azure 上で作成する場合、価格レベルには標準を使用する
Azure の価格レベルですが
- 標準 (Standard))
- 基本 (Basic)
の 2 種類があり、検証用途で使用する場合には基本を使用すると費用を抑えることができます。
Azure の料金体系について
AlwaysOn 可用性グループの環境を Azure 上に構築しようとして、テンプレート展開や自分で作成などをやっていて気付いたのですが、基本では 負荷分散されたエンドポイントをサポートしていないのですね。
Basic (基本) レベルの仮想マシン
既に Azure ロード バランサーまたは自動スケーリング機能を構成している場合は、その構成を削除しない限り、Basic (基本) レベルの仮想マシン サイズにはダウングレードできない点にもご留意ください。ロード バランサーまたは自動スケーリングの構成を削除すると、上記と同じ手順で Standard (標準) サイズを Basic (基本) サイズに切り替えられるようになります。
これを理解していなくて、テンプレート展開で AlwaysOn 基本の価格レベルに設定したインスタンスを使用して、構築しようとしていたところ、SQL Server を展開しようとしたタイミングでエラーとなってしまっていました。
# テンプレート展開された AlwaysOn は Azure ロードバランサーによりリスナーに接続するためのエンドポイントが作成されるため
なぜ、テンプレート展開できないのかわからず、3 時間ぐらいはまってしまいました…。