SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Windows Server 2008 以降のクラスターではクライアントアクセスポイント (CAP) で作成されるネットワーク名は Kerberos 認証が有効になっているため Active Directory 上に仮想コンピューターオブジェクト (VCO) としてコンピューターアカウントが作成されます。
# Windows Server 2003 はデフォルトの設定では Kerberos 認証が無効な状態だったので、ネットワーク名のリソースを作成してもコンピューターアカウントは作成されていませんでした。
SQL Server 2008 以降をクラスターインスタンスとしてインストールした場合もコンピューターアカウントが作成されたりするのですが。
# Windows Server 2003 のクラスター上に SQL Server のクラスターインスタンスをインストールした場合も作成されます。
クライアントアクセスポイントを作成する際にちょっとした注意点があるのでまとめてみたいと思います。
前回、クラスター環境の SQL Server をシングルユーザーモードで起動 という投稿を書きました。
この投稿ではクラスターのサービス (Cluster Service) が起動した状態が前提となっていました。
今回はクラスターのサービスが起動しない状態になった場合に、クラスター環境の SQL Server を起動するための手順をまとめてみたいと思います。
# かなり無理やり起動させていますので、実施する場合は自己責任でお願いいたします。
本作業は 2 ノードクラスターで構成された環境で、1 ノードのみ起動した状態で実施しています。
SQL Server の障害時はシステムデータベースのリストア時に SQL Server をシングルユーザーモードで起動することがあります。
シングル ユーザー モードでの SQL Server の起動
SQL Server サービスのスタートアップ オプションの使用
クラスター環境でない SQL Server の場合では、コマンドプロンプトから [sqlservr.exe ?m] で SQL Server を起動させるか、SQL Server 構成マネージャーでスタートアップパラメーターに [-m] を指定します。
# SQL Server Agent や Reporting Services のサービスを停止していないと、これらのサービスがシングルユーザーモードの接続をとってしまうので注意が必要だったりしますが。 
今回の投稿ではこのシングルユーザーモードをクラスター環境で実行するための手順についてまとめてみたいと思います。
前回は、クラスター環境の SQL Server 2008 R2の LooksAlive / IsAlive 投稿しました。
SQL Server 2008 R2 までは、[SELECT @@servername] を実行することで IsAlive の検査が行われていました。
Denali では IsAlive の検査方法が変わっているので今回はその点についてまとめてみたいと思います。
このあたりの情報については Tech Ed North America 2011 の Denali のセッションで解説がされています。
Microsoft SQL Server Code-Named “Denali” AlwaysOn Series,Part 1: Introducing the Next Generation High Availability Solution
Read the rest of this entry »
Denali でちょっと変更があるので、今のうちに SQL Server 2008 R2 までの LooksAlive / IsAlive について簡単にまとめておきたいと思います。
# 基本的には 2008 R2 以前のバージョンは動作は同じです。
Windows のクラスター (MSCS / WSFC) と Windows のネットワーク負荷分散 (NLB) は共存ができないため、クラスター環境で IIS を冗長化した構成で使う場合には、[汎用スクリプト] を登録してクラスター化された IIS を作成していました。
Windows Server 2003 までは、[C:WINDOWSSystem32inetsrv] の [ClusWeb.vbs] [ClusFtp.vbs] を使用していました。
Windows Server 2008 以降では、これらのスクリプトは使用できず以下の技術情報に記載されているサンプルスクリプトを使用します。
# 2008 では 2003 で使用していたスクリプトが含まれてしまっているのですが、使用せずに以下の技術情報 (KB970759) のスクリプトを使用します。 2008 R2 では含まれなくなっています。
IIS 7. 0 の WWW (World Wide Web 発行サービスは、Microsoft Windows Server 2008 フェールオーバー クラスターで構成します。
前回はローリング アップグレードということで、パッシブ ノードからパッチを適用していました。
アクティブ ノードからパッチを適用したらどうなるのだろうと思って試してみました。
TechNet フォーラムを見ていたところ SQL Server 2008 R2 のローリングア ップグレードを使用したパッチ適用についての投稿がありました。
そういえば、SQL Server 2008 以降のクラスタ環境ではローリング アップグレードのシナリオが追加されていたなということを思い出し、良い機会だったので試してみました。
# Tech･Ed 2009 のセッションでの話があったということをブログに書いていたのですが試していませんでした…。
技術情報としては以下の情報が参考になります。
# フォーラムに記載されていた技術情報になります。2008 R2 でも同じ手順になります。
SQL Server 2008 フェールオーバー クラスタにローリング更新プログラムおよび Service Pack を適用する方法
今回は使用しないのですが以下のような技術情報もあります。
FIX: Error message when you perform a rolling upgrade in a SQL Server 2008 cluster : "18401, Login failed for user SQLTESTAgentService. Reason: Server is in script upgrade mode. Only administrator can connect at this time.[SQLState 42000]"
SQL Server フェールオーバー クラスター インスタンスをアップグレードする方法 (セットアップ)
リストアですがまずは、サーバーのベース部分のリストアについてまとめてみました。
この手順に関してはクラスタ特有の内容はないですね。
■サーバーの全損の再現
全損状況の再現として、iSCSI の共有ディスクとして使用していた LUN は一度削除して再作成しています。
各ノードの内蔵ディスクに関しては、DISKPART で Clean を実行して一度クリアした状態にしてあります。
?
■サーバーのベース部分のリストア
サーバーのベース部分 (内蔵ディスク) のリストアに関しては通常のベアメタル回復と同じです。
今回の環境には、DHCP サーバーがあるため [NETSH コマンド] を使用した、IP アドレスの設定に関しては省略しています。
今まで、ベアメタル回復の手順はまとめたことがなかったのでこの機会にまとめてみました。
?
?
?
上記の手順は、共有ディスクの所有者だったサーバーをリストアした場合のものになります。
共有ディスクの所有者でなかった場合、一部画面が表示されないことがありますが基本的な手順は同じになります。
次の投稿で、共有ディスクのリストアについてまとめていきたいと思います。
続いては全損時に備えたバックアップの取得です。
全損時に備えたバックアップとしてはクラスターの構成情報のバックアップだけでなく、共有ディスクのバックアップも
取得する必要があります。
共有ディスクのバックアップについていろいろと検証してみたところ、バックアップの設定に少し癖がありそうでした。
■共有ディスクのバックアップ取得の注意点
Windows バックアップで共有ディスクを選択することは可能ですが、バックアップのスケジューリング時に共有ディスクを
選択できるのは、設定時にディスクを所有しているノードだけになります。
上記の図のような状態になっている場合、共有ディスクのバックアップのスケジューリングを設定できるのは、[NODE-1] だけになります。
[NODE-2] に関しては、ディスクの所有者でないため、バックアップの取得対象として設定できません。
そのため、バックアップを設定したノードから共有ディスクがフェールオーバー等で移動すると以下の図のようなバックアップ取得となります。
このとき、Windows Server バックアップの GUI でスケジューリングをしていた場合 [NODE-1] で、スケジュールが実行されると
共有ディスクのバックアップは、[見つからないボリューム] として対象のボリュームのバックアップだけスキップされます。
# Windows Server バックアップの GUI でスケジューリング設定した [wbadmin] は [-template] というオプションで実行されます。
? このオプションで実行されているバックアップの場合、存在しないボリュームのバックアップはスキップされます。
? 
?
この存在しないボリュームがスキップされるという動作ですが、wbadmin を [-template] のオプションで設定しているバックアップでないと、
存在しないボリュームのバックアップが実行されると一部のボリュームだけスキップされるという動作はされず、バックアップ全体がエラーとなってしまいます。
?
?
■ディスクを所有しているノードを意識しないでバックアップを取得する方法
昨日まででここまでは検証ができていたのですが、ディスクを所有しているノードを意識しないでバックアップをスケジューリングする方法が
思い浮かばずに悶々としていましたのですが、ものすごい単純な方法で解決ができることについ先ほど気づきました。
以下の手順で、バックアップのスケジュールを設定すればよかったんですね。
この方法でバックアップのスケジューリングをすると、共有ディスクを所有しているノードを意識せずにバックアップが取得できるようになります。
[NODE-1] が共有ディスクを所有している場合の動作
[NODE-2] が共有ディスクを所有している場合の動作
?
気づいてみたら単純な方法ですね。
各ノードが共有ディスクを所有している状態でバックアップを設定すればよかったんですよね。
この方法でクラスターが全損した場合もリストアできる状態のバックアップを取得することができます。
次の投稿ではサーバー、共有ディスクが全損した状態からのバックアップのリストアまとめてみたいと思います。