SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for 2月 21st, 2010

Hyper-V 上で実行している Exchange 2010 のバックアップについて

leave a comment

少し動作を確認しておかないといけないなと思い検証をしてみました。

■Windows Server バックアップを使用したゲスト OS のバックアップ取得

Windows Server 2008 / R2 の Windows Server バックアップは VSS に対応しており、ゲスト OS の VSS と連携して、
バックアップを取得することが可能となっています。

VSS の追加方法は以下の KB に記載されています。
Windows Server バックアップを使用して Windows Server 2008 ベースのコンピューターの親パーティションから Hyper-V 仮想マシンをバックアップする方法

本投稿作成時点は、日本語の KB では 2008 無印が対象 OS となっていますが、英語の情報では R2 も対象になっています。
# Fix it も R2 で実行可能です。
How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup

以下が上記の KB の作業を実施していない状態で、[vssadmin list writers] を実行した結果になります。
image

一見 Hyper-V 用の VSS が組み込まれているように見えますが、この状態では回復時にアプリケーションから [Hyper-V] を
選択することができません。
# この状態でもゲスト OS の VSS と連携はできているみたいなんですけどね。
image

KB の Fix it を適用すると回復時にアプリケーションが選択可能です。
image image

?

それでは、ここからが本題になります。

Exchange 2007 SP2 以降では、Windows Server 2008 用の Exchange 用 VSS ライターが追加されています。
このライターは Exchange 2010 でもデフォルトで追加されており、Windows Server バックアップを使用して、
Exchange のメールボックスデータベースをバックアップし、ログの切り捨てができるようになっています。
# 以前投稿した、Exchange 2007 / 2010 のバックアップについて の内容になります。

このライターが導入されたことにより、Hyper-V のホスト OS から Windows Server 2008 で稼働させている Exchange の
バックアップを取得すれば Exchange のメールボックスデータベースのバックアップも連携がされ、ログが切り捨てられるように
なるのではということに気付きました。

直近だと、Exchange 2007 で試しておいた方がよいのですが、ログがある程度たまっている Exchange の環境が 2010 しか
手元になかったため、まずは Exchange 2010 で検証をしてみました。

■バックアップ前のログの状況

最近、バックアップを取得していなかったためかなりログが溜まってしまっていました…。
image

この状態でホスト OS からバックアップを取得してみます。

■ホスト OS からバックアップを取得

今回のゲスト OS は F ドライブに配置しています。
image

そこで、Windows Server バックアップでは F ドライブのバックアップの取得を行います。
image

VSS の設定に関しては、[VSS 完全バックアップ] で設定しています。
image

このバックアップを G ドライブに取得します。
image

■ ゲスト OS で確認

バックアップを進めていると、ゲスト OS のイベントビューアに以下の情報が出力されます。
image image

ホスト OS のバックアップでゲスト OS の Exchange VSS Writer が同期して実行されていますね。
ログのディレクトリを確認してみるとログの切り捨てが行われています。
image

ゲスト OS でバックアップを取得した場合と同じ動作になっていますね。

?

バックアップも正常に完了しました。
image?

時間がある時に Exchange 2007 も同様の動きになるがきちんと確認しておきたいと思います。

Written by Masayuki.Ozawa

2月 21st, 2010 at 3:12 pm

Posted in Exchange

SQL Server の名前付きインスタンスのポート解決について

3 comments

久しぶりに SQL Server の勉強を。今日はインスタンスのポート番号の解決について。

今回は以下の環境を使って検証しています。
ポート番号をいろいろと変更してテストを行っていたので、
?image

?

■SQL Server が使用するポートのデフォルト設定

SQL Server のインスタンスには既定のインスタンスと名前付きインスタンスの 2 種類があります。

初期設定では、既定のインスタンスの場合は、デフォルトで [TCP 1433] が使用され、名前付きインスタンスの場合は、
[動的ポート] となり使用されるポートは固定されません。

既定のインスタンスに接続する場合は [サーバー名] のみ
image

名前付きインスタンスに接続する場合は、[サーバー名インスタンス名] の形式で指定します。
image?

?

■ポートの変更

ポートの設定は、[SQL Server 構成 マネージャ] で設定することができ、デフォルトでは以下の設定となっています。

image

既定のインスタンス

名前付きインスタンス

image image

SQL Server のポート番号は任意に変更することができ、既定のインスタンスを動的ポート、名前付きインスタンスで [1433] を
設定するということもできます。

名前付きインスタンスを [TCP 1433] で動かすと、名前付きインスタンスにサーバー名だけで接続ができるようになったりもします。
下の画像のオブジェクトエクスプローラーでは [SQL-TEST] というサーバー名で接続をしているのですが、[@@servername] を
実行した結果は、[SQL-TESTINSTANCE1] となっています。
image

このようにポート 1433 で実行している SQL Server インスタンスに関しては、サーバー名で接続が可能になります。

■サーバー名だけで接続した際の挙動

Network Monitor を使ってサーバー名だけで接続した場合に使用されるポートを調べてみたいと思います。
SSMS で接続するより、SQLCMD で接続をした場合の方がポートの使用状況がわかりやすかったので、
今回は SQLCMD を使用しながら、挙動を確認していきたいと思います。

接続に使用するコマンドは以下になります。

SQLCMD ?E ?S “SQL-TEST”

この時の接続状況が以下になります。

クライアント [172.23.0.2] からサーバー [172.23.0.1] の [TCP 1433] に対して接続が行われていますね。

?image

サーバー名だけで接続をする場合は、直接 1433 に対して接続をしているのが確認できます。

?

■[サーバー名インスタンス名]で接続した場合の挙動

続いては、[サーバー名インスタンス名] で確認をしてみます。

名前付きインスタンスに接続する場合のコマンドは以下になります。

SQLCMD ?E ?S “SQL-TESTINSTANCE1”

?

この時の Network Monitor の内容が以下になります。

image

現在、[INSTANCE1] の動的ポートでは [TCP 49151] が使用されています。

image

[SQLCMD.EXE] で、172.23.0.2 から、172.23.0.1 のポート [TCP 49151] に接続している個所が、SQL Server に
接続をしている内容になります。

先ほどの既定のインスタンスへの接続と異なる個所としては、[UDP 1434] の通信が発生しているところですね。

この時のフレームサマリーが以下になります。
image

172.23.0.2 から 172.23.0.1 に [UDP 1434] で接続をし、そのあとに 172.23.0.1 の [TCP 49151] に接続をしています。

この時の [UDP 1434] の通信に使用されるサービスが、[SQL Server Browser] サービスになります。
# サーバー名だけの接続では使われないようです。

?

■SQL Server Browser サービスについて

先ほどの内容で [SQL Server Browser] サービスで [UDP 1434] が使用されていると書きました。

[SQL Server Browser] サービスは、SQL Server を起動しているサーバーで実行することのできるサービスになります。
今回の検証では、[SQL-TEST] でサービスが起動しています。
image

タスクマネージャーで確認するとプロセス ID [2896] で起動しているのが確認できますね。
# 32ビットプロセスなんですよね。
image

[netstat] コマンドを使用して、プロセス ID [2896] のポート使用状況を確認してみたいと思います。
使用するコマンドはこちらです。

netstat ?ano | find “2896”

?

実行するとこのような結果が取得できます。
[UDP 1434] がプロセス ID [2896] で実行されていることが確認できますね。
image

このサービスが何をやっているかを確認する場合は、[SQL Server Browser] サービスをサービスではなく、
コンソールモードで起動するとわかりやすいです。

コンソールモードで起動するためには、[SQL Server Browser] サービスを停止して、コマンドプロンプトで
以下のコマンドを実行します。
コンソールモードで起動すると [UDP 1434] に対してのアクセスのログがコンソールに表示されるようになります。

"C:Program Files (x86)Microsoft SQL Server90Sharedsqlbrowser.exe" -c

この状態で再度名前付きインスタンスでの接続をするとコンソールに以下の用に表示されます。
image?

172.23.0.2 から [UDP 1434] に対してアクセスがあったことを確認することができますね。

[SQL Server Browser] サービスは SQL Server のインスタンス名を指定した接続要求時に、インスタンスに対応するポートを
返答する機能になります。
# サーバー名だけで接続した場合は使用されません。そのため、既定のインスタンスのポートを変更した際には、
  SQL Server Browser が使用されないので、接続時にポート番号を指定する必要があります。
特定のインスタンスの接続をする際にポート番号を指定しなかった場合はこの機能を使用して、ポート解決をする必要があります。

下の画像が、[INSTANCE1] 接続時にクライアントから SQL Server の [UDP 1434] に対してアクセスされた際の
ネットワークフレームの情報 (Frame Number 9 の情報) になります。
パースがうまくできなかったので、[Hex Details] をみる必要があるのですが、[instance1] という情報が読み取れますね。
クライアントからサーバーに [instance1] のポート解決に対してのリクエストがされています。
image

次ネットワークフレームの情報 (Frame Number 10 の情報) が SQL Server からクライアントに対してのレスポンスになります。
こちらもパースができなかったので [Hex Details] で確認する必要があるのですが、SQL Server の情報がクライアントに渡されています。
この中にポート番号 (49195) が入っているのが確認できますね。
image

[SQL Server Browser] サーバーは、インスタンス名が指定されており、ポート番号が指定されていない場合に使用されます。
そのため、インスタンス名を指定していても、ポート番号を指定している場合は使用されません。
# [UDP 1434] にたいしてアクセスがされません。

ポート番号を指定する場合は以下のコマンドになります。

SQLCMD ?E ?S “SQL-TESTINSTANCE1,49195”

?

この場合の Network Monitor の取得内容が以下になるのですが、指定したポートに直接接続がされており、[UDP 1434] の
通信は発生していません。
image

普段何気なく使用している、[サーバー名インスタンス名] の接続ですがきちんと調べると勉強になります。

Written by Masayuki.Ozawa

2月 21st, 2010 at 7:48 am

Posted in SQL Server