その 2 でノードの追加手順を書こうと思っていたのですが、クラスタのインストールで補足して書いておきたい
内容がありましたので 1.5 として補足編を。
[インストール時に使用できるディスク]
クラスタの共有ディスクはインストーラーを実行しているノードがリソースを保有している必要があります。
ノードがディスクを保有していない場合、セットアップのルールチェックで以下のエラーとなります。 
事前に SQL Server をインストールしているグループを作って、ディスクリソースをグループに割り当てている場合は、
ノードの移動で、インストーラーを起動しているノードにグループを移動します。
ただし、グループにディスクを割り当てていない時にディスクが割り当てられている [使用可能記憶域] に
ディスクが存在している場合は GUI からはディスクを特定のノードに移動させることができません。
今は [2008R2-NODE-02] にディスクが割り当てられていますが、インストーラーは [2008R2-NODE-01] で実行しています。
ディスクを移動させるためにはコマンドで移動させます。
# コマンドプロンプトは管理者として実行する必要があります。
|
>cluster group "使用可能記憶域" /MOVETO:%COMPUTERNAME% リソース グループ ‘使用可能記憶域’ を移動しています… グループ???????????? ノード????????? 状態 |
使用可能記憶域の実体はクラスタグループなので、グループの移動をすることで未割当の共有ディスクを
所有しているノードが変更できます。
[SQL Server 仮想ホストのコンピュータアカウント]
事前にコンピュータアカウントを作成していない場合、SQL Server の仮想ホストは [Computers] に作成されます。 
? 
このとき、コンピュータアカウントは WSFC の仮想コンピュータが作成を行っています。
今回、クラスタは [2008R2-WSFC-01] としていますので、[SQL-WSFC-01] の作成者は [2008R2-WSFC-01] になります。
作成者は、属性エディタや ADSI Edit で [mS-DS-CreatorSID] を表示すると確認できます。
[mS-DS-CreatorSID] に表示されている SID が作成者の SID ですので [objectSid] が表示内容になっているものが
作成に使われたアカウントになります。
2008 のクラスタを構築する際にコンピュータアカウントを事前に作成しておく場合は、コンピュータアカウントに
クラスタを構築する際に使用しているドメインユーザーのフルコントロールを付与しますが、SQL Server の
クラスタの場合には、WSFC の仮想コンピュータ名のフルコントロールを付与しておきます。
事前にコンピュータアカウントを作成していない場合に、自動で作成されるコンピュータアカウントにはフルコントロールは
付与されていないのですが、事前に作成する場合はフルコントロールがないと、コンピュータ名のリソースがオンラインにできませんでした。
自動作成の時と同じ権限を付与して試したのですが、コンピュータアカウントのパスワードリセットができずにエラーとなっていました。
コンピュータアカウントのパスワード関連の権限も付与してはいたのですが。
以下の画像が事前にコンピュータアカウントを作成した場合に、WSFC の仮想コンピュータアカウントにフルコントロールを
付与した設定になります。
コンピュータアカウントに権限を付与しているのでユーザー名は [2008R2-WSFC-01$] となっています。
# コンピュータアカウントを指定する場合は最後に [$] が入ります。
[サービス SID とドメイングループ]
インストールするときにサービス SID を使うかドメイングループを使うかの選択がありますが、どこに使われているかというと
フォルダのアクセス権やディレクトリのアクセス権で使用されています。
左がサービス SID を使用する設定でインストールしたインスタンスのデータディレクトリのアクセス権、
右がドメイングループを使用する設定でインストールしたインスタンスのデータディレクトリのアクセス権になります。
# ドメイン名は塗りつぶしています。
[MSSQL$INSTANCE1] となっていますが実際には、[NT ServiceMSSQL$INSTANCE1] となります。
Windows サービス アカウントの設定
Vista ごとはサービスも SID が持て、特定のサービスがアクセスできる領域を制限することができます。
今まではサービスの起動アカウントに対して権限が付与されていましたが、サービス自体にセキュリティを
付与することができるようになっています。
サービス SID はイベントビューアの evt ファイルのセキュリティなどにも使われており、以下はアプリケーションログの
ファイルのセキュリティですが、[eventlog] という [Windows Event Log] サービスのサービス SID にアクセス権が
設定されています。
サービスをさらに低い権限で動かすためにサービス SID は使われているようです。
ドメイングループを使用する場合、ドメイングループの中に SQL Server のサービス起動アカウントを事前に
メンバとして追加しておくとよいかと思います。
インストールをしているユーザーにメンバの変更権限がない場合、インストール中にエラーとなるためです。
プロダクション環境にインストールする際、Active Directory の管理者権限を持つユーザーでインストールが
できないのであれば、検証時にも低い権限のユーザーでインストールを試した方がよいかと。
次の投稿でノードの追加をまとめてみたいと思います。
