SE の雑記

以前投稿した内容に SQL Server 2008 Express Edition でメンテナンスプランの利用についてコメントをいただきました。

残念ながら SQL Server の Express Edition では、メンテナンスプランが使用できないんですよね。
SQL Server 2008 の各エディションがサポートする機能

また、SQL Server の Express Edition では SQL Server Agent も使用できないため、定期的なジョブを SQL Server 側で
実行することができません。

スキルチャージプログラムで貸与されている環境は Community Server をインストールしてあり、データベースには
SQL Server 2008 Express Edition を使用しています。
この環境ですが日次で 1 世代のバックアップだけは自動で取得する用に設定をしてあります。

メンテナンスプランと SQL Server Agent を使用できない状態で定期的にバックアップを取得するため、
タスクスケジューラ + SQLCMD.EXE を使ってバックアップのスケジューリングを設定しています。

[タスク スケジューラ] は管理ツールの中に入っています。?

このタスク スケジューラで以下のようなタスクを作成しています。
?

操作には以下のような設定を登録してあります。

操作	プログラムの開始
プログラム/スクリプト	"C:Program FilesMicrosoft SQL Server100ToolsBinnSQLCMD.EXE"
引数の追加 (オプション)	-S localhost<インスタンス名> -E -i "E:ToolsBackupCSDBBackup.sql"

?

CSDBBackup.sql には以下の内容を記載しています。
# SSMS で生成したスクリプトを記載しているだけですが。

BACKUP DATABASE [CommunityServer] TO? DISK = N’E:BackupCommunityServer.bak’ WITH NOFORMAT, INIT, NAME = N’CommunityServer-完全 データベース バックアップ’, SKIP, NOREWIND, NOUNLOAD,? STATS = 10 GO

?

同様の方法でインデックスのメンテナンスも可能です。
ざっくりと作ったインデックスの再構築のクエリです。
これを SQLCMD でタスクスケジューラから実行すると定期的にインデックスの断片化を解消することができます。
# アドホッククエリで書いてしまっていますが…。

SET NOCOUNT ON USE [CommunityServer] GO DECLARE @name sysname DECLARE @SQL nvarchar(500) SELECT * INTO [#tables] FROM [sys].[tables] DECLARE [table_cursor] CURSOR FOR SELECT [name] FROM [#tables] OPEN [table_cursor] FETCH NEXT FROM [table_cursor] INTO @name WHILE @@FETCH_STATUS = 0 BEGIN ??? SET @SQL = N’ALTER INDEX ALL ON [‘ + @name + ‘] REBUILD’ ??? EXECUTE sp_executesql @SQL ??? FETCH NEXT FROM [table_cursor] INTO @name END CLOSE [table_cursor] DEALLOCATE [table_cursor]

?

自分でクエリを書くのが面倒な場合は、定期的に実行したい操作を SSMS からスクリプト化しておけばよいと思います。

Express Edition を使っていてもデータベースのメンテナンスは定期的に実行しないと駄目ですが、無償版なので
この辺の機能がないのは仕方ないですね。

SCVMM のセルフサービスポータルをインターネット経由で公開できないかなといろいろと検証していました。
インターネット経由だと VPN か Direct Access 辺りを使用しないと厳しそうなのですが、調べたことを投稿しておきたいと思います。

今回の検証をするにあたり、Tech Fielders のライトニングトークの [ここまではできる SCVMM セルフサービスポータル] を
参考にさせていただきました。
Tech Fielders セミナー これまでのライトニングトーク登壇者
# ライトニングトークの内容を自分で検証してみたという投稿になっているかと。

SCVMM のセルフサービスポータルにログインした後のゲスト OS の接続には 2 種類の接続方法が用意されています。

1. VM に接続
2. リモート デスクトップ

どちらを使うかによってアクセスの経路が変わります。

■VM に接続

VM に接続は SCVMM の管理コンソールの [バーチャル マシンに接続] と同じ機能になります。
SCVMM の管理コンソールで接続した場合は、以下のように表示されます。
?

これをセルフサービスポータルで表示すると以下のように表示されます。

ゲスト OS のコンソールを直接開く機能ですね。

この機能ですが以下の接続がされているようです。
ポート 2179 で直接ホストに接続しているみたいですね。
SCVMM の管理コンソールのバーチャルマシンに接続で実行される [VirtualMachineViewer.exe] も、ポート 2179 で接続が
されているので、セルフサービスポータルの ActiveX も同様の動作になるんですね。

SCVMM がホスト OS にアクセスして表示しているのではなく、クライアントがホスト OS に接続をしているようです。
そのためクライアントが直接ホスト OS にアクセスできないといけないようです。

また、ホスト OS に接続をする関係上、ホスト OS を名前解決できないと接続ができません。
ホスト OS の名前解決ができないと以下の画面になってしまい接続ができません。

■リモートデスクトップ

リモートデスクトップですがこちらはゲスト OS のリモートデスクトップに接続をします。
そのため、ゲスト OS でリモートデスクトップを設定する必要があります。

私の環境の問題のような気もするのですが、[ネットワーク レベル認証で～] にしてリモートデスクトップを設定していると
セルフサービスポータルで接続することができませんでした。

[リモート デスクトップを実行している～] だと接続ができました。

リモートデスクトップだと以下の接続になるようですね。
直接ゲスト OS にリモートデスクトップのデフォルトポート 3389 で接続されます。
そのため、ゲスト OS でリモートデスクトップのポートを 3389 から変更すると接続できませんでした…。

こちらも直接接続していますので、ゲスト OS の名前解決ができないとエラーになります。

?

SCVMM のセルフサービスポータルからコンソールを開く場合は、ホストまたはゲスト OS に直接接続できる必要があるので、
インターネット経由での接続は簡単にはできなさそうですね。

インストールマニアックス 3 の VPS コースでは DotNetPanel という Web 管理ツールが提供されているのですが、
こちらはコンソールを操作する機能は提供されていないんですよね。

Hyper-V + SCVMM で IaaS の環境が作れれば面白いな～と思ったのですが、コンソールの利用を考えるとなかなか難しいですね。

自宅の検証環境にはインストールマニアックス 3 の勉強用で構築した Hyper-V Server 2008 R2 が 1 台あります。
# 私は VPS コースだったのですが勉強を兼ねて構築していました。

せっかくなので、この環境で Live Migration 環境を作ってみたいと思います。
1 台なので Live Migration のテストはできませんが。
# 2 月のどこかで中古の ThinkPad を購入して Live Migration の検証環境を作りたいな～とは思っているのですが。
??? UPS の電源容量が小さいので Live Migration 環境を ML115 で作ろうとすると UPS がなり始めてしまうのですよね･･･。

ちなみにこの環境はドメインに参加済みの環境です。

■クラスタのインストール

まずはクラスタ環境を構築する必要があります。
Hyper-V Server 2008 R2 では [sconfig.cmd] で表示されるメニューからクラスタの有効化ができます。

1. [11] を選択
   ?
2. [はい] をクリックします。
   
3. DISM で機能が有効化されます。
   
4. [OK] をクリックします。
   

?

■iSCSI イニシエーターサービスの自動起動化

デフォルトでは iSCSI イニシエーターのサービスは自動起動になっていませんので、自動起動に設定し初回の起動を行います。
# ローカルで MMC が使えないのでコマンドで。

1. コマンドプロンプトで以下のコマンドを実行し、サービスを自動起動にします。
   

   sc config MSiSCSI start= auto

2. 自動にしてもサーバーが再起動しないとサービスが起動されないので、再起動しない場合は以下のコマンドで起動させます。

   sc start MSiSCSI

?

■iSCSI ターゲットへの接続

iSCSI ターゲットへの接続ですが、iSCSI イニシエータのコマンドとして [iscsicli.exe] が用意されています。
Server Core 環境なのでコマンドで設定するしかないのかと思っていたのですが、GUI である、[iscsicpl.exe] が使えるんですね。

これは楽でいいです。

ターゲットを入力してクイック接続してみます。
# ターゲット側で、iSCSI ターゲットを作成し、Hyper-V Server 2008 R2 の iSCSI イニシエータの FQN を追加済みです。

接続できました。

ターゲット側でディスクを割り当てておきましたので、まずはクォーラム用のディスクが使用可能な状態です。

ひとまず、[DISKPART] コマンドで Q ドライブに割り当てておきます。
今回は、ディスク 2 に新規のディスクが割り当てられていますので以下のコマンドを実行していきます。

diskpart list disk select disk 2 create part primary format quick assign letter=Q exit

?

■クラスタの構築

[cluster.exe] を使ってクラスタを構築してもいいのですが今回は勉強を兼ねて PowerShell で。
ドメインにクラスタ用のコンピュータアカウントを作成して無効状態にし、セキュリティとして今回の作業に
使用するドメインユーザーのフルコントロールを付与している状態です。
??

後は以下のコマンドを順次実行していきます。
クラスタのコンピュータアカウントにフルコントロールを指定したユーザーをローカルの Administrators に入れるところから
コマンドを記載しています。
現在のサーバーは DHCP で IP を割り当てているので、クラスタの作成時に静的 IP を指定していません。

net localgroup “Administrators” “<ドメイン名"ユーザー名>” /add
runas /user:“<ドメイン名ユーザー名>”? cmd
powershell

Import-Module FailoverClusters
New-Cluster ?Name “HVS-CLUSTER” ?Node $ENV:COMPUTERNAME

これでクラスタの構築は完了です。
他の端末に、RSAT の [フェールオーバー クラスタリング ツール] を導入して接続してみたいと思います。

?

正常に接続できました。

クラスターの作成自体も管理ツールからリモートで実施できるので、管理端末が用意できるのであれば、Hyper-V Server 上で
PowerShell を使わなくても構築することが可能です。

■クォーラムディスクの設定

作成直後のクォーラムはノードマジョリティになっているので、Q ドライブに割り当てているディスクをクォーラムとして
追加したいと思います。

Get-ClusterQuorum Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterResource | ft -Wrap Set-ClusterQuorum -NodeAndDiskMajority "クラスター ディスク 1"

?

これでクォーラムがノードおよびディスクマジョリティになりました。

Get-ClusterQuorum Cluster??????????????????? QuorumResource??????????????????????????? QuorumType ——-??????????????????? ————–??????????????????????????? ———- HVS-CLUSTER??????????????? クラスター ディスク 1??????????? NodeAndDiskMajority

?

■CSV の有効化

初期状態では CSV は無効になっているので、これを有効化します。

Get-Cluster | %{$_.EnableSharedVolumes="Enabled/NoticeRead"}

EnabledSharedVolumes は [Enabled/NoticeRead] を指定する必要があります。
CSV を有効にするときには以下の通知が表示されます。

[Enabled] だけですと上記の通知がコンソール内に表示されるだけで有効にすることができません。
有効にするためには通知を読んだ事を指定する必要がありますので、[Enabled/NoticeRead] が必要となります。
無効にする場合は、[Disabled] を指定します。

GUI から CSV の無効化はできないみたいなので、CSV を無効にする場合には PowerShell から実行する必要があるようですね。

■CSV にディスクを追加

現在はクォーラム用のディスクしか iSCSI に作っていなかったので CSV 用のディスクを新規に作り、CSV に割り当てたいと思います。
私の環境の iSCSI ターゲットは Storage Server 2008 ですので、仮想ディスクを追加して、iSCSI イニシエータでマッピングします。

あとはこのディスクも DiskPart でフォーマットしておきます。
今回はドライブ文字は不要ですのでアサインはしません。
# クォーラムも不要なのですが、今までのクラスタ構築の癖で Q ドライブを割り当てちゃうんですよね。

diskpart list disk select disk 3 create part primary format quick exit

?

後はこのディスクを CSV に追加します。

Get-ClusterAvailableDisk | Add-ClusterDisk Get-ClusterResource | ft -Wrap Add-ClusterSharedVolume "クラスター ディスク 2"

?

これで CSV の追加は完了です。
CSV に追加されているディスクを確認してみます。

Get-ClusterSharedVolume Name?????????????????????? State????????????????????? Node —-?????????????????????? —–????????????????????? —- クラスター ディスク 2????? Online???????????????????? hvs2008r2

?

■仮想マシンの作成

残るは Live Migration する仮想マシンの作成です。
ひとまず管理用端末の GUI で仮想マシンを作りたいと思います。

クラスタの管理は RSAT の [フェールオーバー クラスタリング ツール] をインストールすればよいのですが、仮想マシンの作成は
クラスタ用の管理ツールではできません。

仮想マシンを作成する場合は [Hyper-V ツール] をインストールする必要があります。

今回は管理用端末に SCVMM 2008 R2 の端末を使用しているのですが、この場合でも RSAT の Hyper-V ツールが必要になるんですね。

GUI を使用して CSV を使用する仮想マシンを作成することができました。

?

PowerShell の場合は、[Add-ClusterVirtualMachineRole] を使用すればよいと思うのですが、私の環境では
エラーになってしまうんですよね･･･。
GUI からは作成できているのでコマンドのオプションを間違っているような気がするのですが原因までは追えていません。

?

コマンドからの仮想マシンの作成がうまくいっていないのですがひとまずこれで Live Migration に必要となる環境までは
設定ができたと思います。

GUI って楽だな～と改めて実感しました･･･。

冗長化の最後として、サーバーをシャットダウンしながら冗長化のテストをしてみたいと思います。

■管理コンソールの接続

まずは管理コンソールの接続テストから。

1. 両サーバーが停止している場合
   両サーバーをシャットダウンしている状態です。
   当然ながら接続できませんね。
   
2. 片側のサーバーが起動している場合
   片側のサーバー (2008R2-MDOP-01) だけ起動してみました。

   この状態は正常に接続ができますね。

    

   2008R2-MDOP-02 だけが起動している状態でも正常に接続ができます。

3. ファイルサーバーが停止している場合 (MED-V サーバー起動後)
   MED-V サーバー (2008R2-MDOP-01 / 02) の起動後にファイルサーバーをシャットダウンした場合のテストです。
   MED-V サーバーの起動後にファイルサーバーをシャットダウンしているので、サービスは起動している状態です。
    
   共有ディレクトリ上にあるポリシーのファイルが読み込めずにエラーとなります。

    
   開かれたワークスペースも以下のように空の状態です。
    

4. ファイルサーバーを起動
   上記の状態のときにファイルサーバーを再度起動させてみます。

   MED-V サーバーの再起動やサービスの再起動の必要なく接続ができるようになりました。

    

5. ファイルサーバーが停止している場合 (MED-V サーバー起動前)
   MED-V サーバー起動時にファイルサーバーが停止していた場合です。

   この場合は MED-V のサービスが起動しないですね。
   

6. ファイルサーバーを起動
   上記の状態ときにファイルサーバーを起動してみます。
   サービスは停止状態ですので、手動でサービスの起動を実施します。

   起動するかなと思ったら起動しませんでした…。
   定番のエラーが表示されていました。
   
   サーバーを再起動してもサービスは起動できませんでした。
   ファイルサーバーの [PublicKey.xml] を削除してサービスを起動してみます。

   2008R2-MDOP-01 では正常に起動しました。
   
   2008R2-MDOP-02 ではエラーとなり以前としてサービスが起動できません。
   2008R2-MDOP-01 の KeyPair.xml を 2008R2-MDOP-02 にコピーしたところ正常にサービスが起動できました。
   構築時に発生した現象が再発したみたいですね。

   ファイルサーバーが起動していない状態で MED-V を起動しただけなのですがこのような状態になるとは…。

接続関してはどちらかのサーバーが起動していれば問題はなさそうですね。
ただし、ファイルサーバーが起動していない状態で MED-V サーバーを起動した場合は修復作業が必要になりそうですが。

■接続後にサーバーがシャットダウンされた場合

サーバー接続後に接続されているサーバーがシャットダウンされた場合の挙動を確認してみたいと思います。

まずは片側のサーバーを NLB の負荷分散対象外とします。

これで 2008R2-MDOP-01 に接続がされるようになります。

この状態で MED-V クライアントで管理コンソールを起動させた後に、でサーバーの負荷分散対象を逆転させます。
 
管理コンソールは起動したままです。

 

この状態でイメージをアップロードしようとすると以下のエラーになります。
 

一度更新のボタンを押して、情報をリフレッシュすると正常にアップロードできるようになりました。

 

管理コンソールを使った冗長テストは以上で。
基本的な NLB のサーバー製品と考え方は変わらなさそうですね。
ファイルサーバーが起動していない場合の動作に関しては予想していませんでしたが…。

サーバー停止時の MED-V で実行されるアプリケーションの実行ですがこれに関してはオフライン実行と関連がありますので、
オフライン時 (サーバーと接続できない場合) の操作に関しては別途まとめていきたいと思います。

冗長化の最後として、サーバーをシャットダウンしながら冗長化のテストをしてみたいと思います。

■管理コンソールの接続

まずは管理コンソールの接続テストから。

1. 両サーバーが停止している場合
   両サーバーをシャットダウンしている状態です。
   当然ながら接続できませんね。
   
2. 片側のサーバーが起動している場合
   片側のサーバー (2008R2-MDOP-01) だけ起動してみました。

   この状態は正常に接続ができますね。

   ?

   2008R2-MDOP-02 だけが起動している状態でも正常に接続ができます。

3. ファイルサーバーが停止している場合 (MED-V サーバー起動後)
   MED-V サーバー (2008R2-MDOP-01 / 02) の起動後にファイルサーバーをシャットダウンした場合のテストです。
   MED-V サーバーの起動後にファイルサーバーをシャットダウンしているので、サービスは起動している状態です。
   ?
   共有ディレクトリ上にあるポリシーのファイルが読み込めずにエラーとなります。

   ?
   開かれたワークスペースも以下のように空の状態です。
   ?

4. ファイルサーバーを起動
   上記の状態のときにファイルサーバーを再度起動させてみます。

   MED-V サーバーの再起動やサービスの再起動の必要なく接続ができるようになりました。

   ?

5. ファイルサーバーが停止している場合 (MED-V サーバー起動前)
   MED-V サーバー起動時にファイルサーバーが停止していた場合です。

   この場合は MED-V のサービスが起動しないですね。
   

6. ファイルサーバーを起動
   上記の状態ときにファイルサーバーを起動してみます。
   サービスは停止状態ですので、手動でサービスの起動を実施します。

   起動するかなと思ったら起動しませんでした…。
   定番のエラーが表示されていました。
   
   サーバーを再起動してもサービスは起動できませんでした。
   ファイルサーバーの [PublicKey.xml] を削除してサービスを起動してみます。

   2008R2-MDOP-01 では正常に起動しました。
   
   2008R2-MDOP-02 ではエラーとなり以前としてサービスが起動できません。
   2008R2-MDOP-01 の KeyPair.xml を 2008R2-MDOP-02 にコピーしたところ正常にサービスが起動できました。
   構築時に発生した現象が再発したみたいですね。

   ファイルサーバーが起動していない状態で MED-V を起動しただけなのですがこのような状態になるとは…。

接続関してはどちらかのサーバーが起動していれば問題はなさそうですね。
ただし、ファイルサーバーが起動していない状態で MED-V サーバーを起動した場合は修復作業が必要になりそうですが。

■接続後にサーバーがシャットダウンされた場合

サーバー接続後に接続されているサーバーがシャットダウンされた場合の挙動を確認してみたいと思います。

まずは片側のサーバーを NLB の負荷分散対象外とします。

これで 2008R2-MDOP-01 に接続がされるようになります。

この状態で MED-V クライアントで管理コンソールを起動させた後に、でサーバーの負荷分散対象を逆転させます。
?
管理コンソールは起動したままです。

?

この状態でイメージをアップロードしようとすると以下のエラーになります。
?

一度更新のボタンを押して、情報をリフレッシュすると正常にアップロードできるようになりました。

?

管理コンソールを使った冗長テストは以上で。
基本的な NLB のサーバー製品と考え方は変わらなさそうですね。
ファイルサーバーが起動していない場合の動作に関しては予想していませんでしたが…。

サーバー停止時の MED-V で実行されるアプリケーションの実行ですがこれに関してはオフライン実行と関連がありますので、
オフライン時 (サーバーと接続できない場合) の操作に関しては別途まとめていきたいと思います。