Archive for the ‘Windows Server’ Category

サービス用のプログラムが C ドライブ以外にあることは問題ないのですが、この状態では Windows Server バックアップで [システム状態] [ベアメタル回復] のバックアップを取得する際に、SQL Server 用のサービスに必要なプログラムが格納されているドライブも取得対象となります。
# このあたりは、System Writer の VSS Writer が制御しているみたいですね。レジストリ (ImagePath の値) を直接修正して、サービスで使用するプログラムの場所を変更すればインスタンスルートディレクトリを取らなくすることもできますが。危険すぎてこの方法は使わないですよね…。

最初は [ベアメタル回復] のバックアップ取得を試してみます。

ベアメタル回復を選択すると、自動的にベアメタル回復に必要なドライブが選択されるのですが、C ドライブだけでなく E ドライブも自動的に選択がされます。
E ドライブを外そうとしても以下のメッセージが表示され、ドライブ / ドライブ以下のフォルダを外すことができません。

[システム状態] を選択すると、システム状態の回復に必要なものが取得されます。
# ドライブの選択状況は変わらず、内部でシステム状態の回復に必要なものが自動で取得されます。

システム状態を選択した際に取得されるバックアップを確認してみます。
3 つの VHD ファイルが作成されています。

これですが、[システムで予約済み] (通常にインストールをした際の先頭 100MB) [C ドライブ] [E ドライブ] のバックアップとなっています。

Windows Server 2008 R2 の場合はファイル単位でバックアップが取得できるようになているので、各ドライブのバックアップはシステム状態として必要最低限のファイルがバックアップされています。
# C ドライブであればユーザープロファイルのディレクトリは除外されています。

E ドライブのバックアップを確認してみるとサービスで使用している 2 つのファイルのみが取得されています。

Windows Server 2008 R2 であれば、ファイル単位で取れるのでシステム状態を取得した時にインスタンスルートディレクトリを C ドライブ以外にしても最小限のファイルがバックアップされることになります。

Windows Server 2008 ではどうなるでしょう。

Win
dows Server 2008 では[システム回復を有効にする] がベアメタル回復相当のバックアップとなります。
このオプションを有効にすると、インスタンスルートディレクトリに指定したドライブも自動的に選択されます。

この動きは、Windows Server 2008 R2 と同じですね。

それでは、システム状態のバックアップを取得するとどうなるでしょう。
Windows Server 2008 の場合は、[wbadmin start systemstate

backup] というコマンドラインを使用して、システム状態だけを取得することが可能です。
# [Start Backup] で取得する場合は、[-allCritical] というオプションを指定します。

システム状態を取得する場合に必要となるファイルが含まれているドライブを自動で判断する動きは Windows Server 2008 R2 と変わりません。

Windows Server 2008 の場合は、デフォルトでは先頭の 100MB の領域は作成されないので、2 つの VHD ファイルが取得されます。

E ドライブ用に取得された VHD の中身を見てみます。

Windows Server 2008 R2 と異なり、サービス以外のファイルも取得されています。

Windows Server 2008 の場合は、ボリューム単位でのバックアップしか取得ができないため、SQL Server のサービスで使用しているファイル以外のものも取得がされます。

そのため、インスタンスルートディレクトリのドライブに SQL Server のデータベースを格納していると、Windows Server 2008 ではシステム状態のバックアップでデータベースのファイルも取得がされてしまい、バックアップのファイルサイズが肥大化する可能性があります。

インスタンスルートディレクトリを変更することはあまりないかもしれませんが、変更する場合はバックアップの取得で影響がないようにデータベースのファイルを配置するような考慮が必要そうですね。

Written by Masayuki.Ozawa

12月 19th, 2010 at 10:11 pm

Posted in SQL Server,Windows Server

Tagged with SQL Server, Windows Server 2008, Windows Server 2008R2, Windows Server バックアップ

ETG2-SHV16N のアグリゲーションを試してみる

leave a comment

私の検証環境は、ETG2-SHV16N という L2 スイッチングハブを使っています。
このスイッチングハブですが、サポート対象外ではありますが Aggregation機能がついています。

リンクアグリゲーションができますのでスイッチ間を接続する際に複数のポートを束ねて一つの論理ポートとして扱うことが可能になります。

私はネットワーク関係はものすごい疎いので、いろいろと試行錯誤しながらこの辺の事を調べてみました。
# いろいろなところに間違いがあってきっと突っ込みどころ満載な気がしますがご容赦を…。

今回、スイッチ間をリンクアグリゲーションで接続しようとして、以下の環境を作ってみました。
この環境で、ファイルサーバーから GT110b にファイルをコピーする際にアグリゲーションあり / なしでどのように速度が変わるのかな～というのを検証してみようとしました。

で、この環境にしたところ、CG-SW08GTXB に接続している、GT110b に接続ができなくなりました…。
というより、ETG2-SHV16N に接続しているサーバーにメイン PC から接続ができなくなりました…。
GT110b からインターネットや対向のスイッチに接続しているサーバー / インターネットに接続することもできず。
ネットワークがダウンした状態になりました。

CG-SW08GTXB ですが、リンクアグリゲーション (ポートトランキング) には対応していない普通のギガビットのスイッチングハブになります。
そういうものなのかな～と Twitter でつぶやいたところ、 IEEE 803.ad 規格に対応していないと通信できない、エラーになってポートが落ちるのでと教えていただくことができました。

なるほどと思って、ちょっと IEEE 803.ad を調べていました。

IEEE 803.ad で、LACP (Link Aggregation Control Protocol) というプロトコルが標準化されており、LACP リンクアグリゲーション (動的リンクアグリゲーション) ではこのプロトコルが使用されているようです。
他にも、スタティックリンクアグリゲーション (SLA) というものもあるようですね。

スイッチ間をアグリゲーションを設定したポートで接続する場合はに対向のスイッチでもアグリゲーションに対応していないと通信を行うことができないようですね。

家にはネットワーク機器がこれ以上ないので、とりあえず構成を以下のようにしてみました。

GT110b の NIC はチーミングをしているのですが、「静的リンクアグリゲーション」として設定をしています。

[IEE 802.3ad 動的リンクアグリゲーション] も設定ができるのですが、この設定では内部 / 外部ともに通信ができなくなりました。

今回は静的リンクアグリゲーションでチーミングした NIC をアグリゲーションしたポートに接続して速度のどの程度の影響が出るのかを試してみたいと思います。
10GB 程度のファイルをファイルサーバーからコピーしてネットワークの使用状況を確認してみました。
単一 NIC の場合は以下のようなネットワークの使用状況になります。

チーミング + アグリゲーションをした環境で取得したデータが以下になります。
# NIC2 は全く使われていないわけではないのですが、低い値を推移しています。
ETG2-SHV16N ではアグリゲーションで xor / smac / dmac の 3 種類の設定があります。
xor だとコピーの最後で送信バイトが瞬間的に上がるのですが、 smac / dmac では平均的な値を示していました。
# smac / dmac ともに似たようなトレンドを示していました。

チーミングのみ設定した場合はこちら。
NIC が交互に使われていました。

ポート側でアグリゲーションをしても効率よく両方の NIC が使われるような設定というのがうまく設定できませんでした…。

ネットワークはよくわかっていないことがたくさんあるのでもっと勉強しないと駄目ですね。

Written by Masayuki.Ozawa

12月 12th, 2010 at 11:01 pm

Posted in Windows Server

Tagged with Aggregation, Teaming

WSUS の管理コンソールに突然つながらなくなりました…

leave a comment

最近、自宅の検証環境に Windows Update Services (WSUS) を導入しました。

新しい検証サーバーをデプロイして、Windows Update の参照先として構築した WSUS を設定したのですが更新プログラムの適用をすることができませんでした。

どうしてだろうと思って、WSUS の管理コンソールを開いてみたところこのようの画面になっていました…。

エラーの内容を見てみたところこのような内容が。

WSUS 管理コンソールは、リモート API 経由で WSUS サーバーに接続できませんでした。

Update Services サービス、 IIS および SQL がサーバー上で実行されていることを確認してください。問題が解決しない場合は、IIS、SQL、および Update Services サービスを再起動してみてください。

System.Net.WebException — HTTP ステータス 401: Unauthorized で要求が失敗しました。

Source
System.Web.Services

Stack Trace:
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   場所 Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, Int32 publicationState, Int32 propertiesToGet)
   場所 Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
   場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet)
   場所 Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)
   場所 Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()
   場所 Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()
   場所 Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

IIS / SQL Server / Update Service も正常に起動はしているのですよね…。

管理コンソールで再接続をしようとしてもこのようなエラーが。

‘2008R2-WSUS-01’ に接続できません。
サーバーが別のポートを使用しているか、別の SSL (Secure Sockets Layer) 設定を使用している可能性があります。

WSUS の Web サービスを開こうとしてもエラーとなっていました。

‘/ApiRemoting30’ アプリケーションでサーバーエラーが発生しました。
——————————————————————————–

要求形式が認識されません。
説明: 現在の Web 要求を実行中に、ハンドルされていない例外が発生しました。エラーに関する詳細および例外の発生場所については、スタックトレースを参照してください。

例外の詳細: System.InvalidOperationException: 要求形式が認識されません。

ソースエラー:

現在の Web 要求の実行中にハンドルされていない例外が生成されました。障害の原因および発生場所に関する情報については、下の例外スタックトレースを使って確認できます。

スタックトレース:

[InvalidOperationException: 要求形式が認識されません。]
   System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type type, HttpContext context, HttpRequest request, HttpResponse response) +401178
   System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler(HttpContext context, String verb, String url, String filePath) +281
   System.Web.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +425
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +263

——————————————————————————–
バージョン情報: Microsoft .NET Framework バージョン:2.0.50727.4952; ASP.NET バージョン:2.0.50727.4955

WSUS のログは [C:Program FilesUpdate ServicesLogFilesSoftwareDistribution.log] に出力がされているのですが、このログには以下のように出力がされていました。

2010-11-20 13:27:35.395 UTC Error WsusService.8 HmtWebServices.CheckDssAuthWebService DssAuth WebService SoapException:System.Web.Services.Protocols.SoapException: System.W
eb.Services.Protocols.SoapException: サーバーは要求を処理できませんでした。 —> System.InvalidOperationException: 一時クラスを生成できません (result=1)。
error CS2001: ソースファイル ‘C:WindowsTEMPy4sk819r.0.cs’ が見つかりませんでした。
error CS2008: 入力が指定されていません。

   場所 System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
   場所 System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
   場所 System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
   場所 System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Evidence evidence)
   場所 System.Web.Services.Protocols.SoapServerType..ctor(Type type, WebServiceProtocols protocolsSupported)
   場所 System.Web.Services.Protocols.SoapServerProtocol.Initialize()
   場所 System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response)
   場所 System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean& abortProcessing)
   — 内部例外スタックトレースの終わり —
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   場所 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   場所 Microsoft.UpdateServices.Internal.DssAuthWebService.DssAuthWebService.Ping(Int32 pingLevel)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckDssAuthWebService(EventLoggingType type, HealthEventLogger logger)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HmtWebServices.CheckDssAuthWebService(EventLoggingType type, HealthEventLogger logger)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringTasks.ExecuteSubtask(HealthMonitoringSubtask subtask, EventLoggingType type, HealthEventLogger logger)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringTasks.Execute(EventLoggingType type)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringThreadManager.Execute(Boolean waitIfNecessary, EventLoggingType loggingType)
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.HealthMonitoringThreadManager.PeriodicTask()
   場所 Microsoft.UpdateServices.Internal.HealthMonitoring.PeriodicTaskExecuter.ThreadStart()
   場所 System.Threading.ExecutionContext.runTryCode(Object userData)
   場所 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   場所 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   場所 System.Threading.ThreadHelper.ThreadStart()

情報を探してみたところ、以下のようなものがありました。
ASP.NET 2.0 をユーザーアカウントで実行されるように構成するとエラーメッセージ "一時クラスを生成できません" が表示される
Issues with the WSUS 3.0 Administration Console
WSUS に関連した Web サービスが、Windows Server 2003 ベースのコンピューターを Windows Server 2008 にアップグレードするときの動作を停止します。
WSUS Install Fails; There is a problem with this Windows Installer package.
そこが知りたい Windows Server Update Services（第3回）

今回の現象ですが、最後の [そこが知りたい Windows Server Update Services（第3回）] に記載されている現象が原因のようでした。

[C:Windowstemp] から [Network Service] の権限が外れてしまっていたため Web サービスを実行した際の一時クラスが生成できずエラーになってしまったみたいですね。

[フォルダーの一覧/データの読み取り] の権限を付与したところエラーを回避することができました。

どうして突然外れてしまったのかはわからないのですが今後、同様の現象が発生した際の対応策のメモとして残しておきたいと思います。

Written by Masayuki.Ozawa

11月 20th, 2010 at 11:06 pm

Posted in Windows Server

Tagged with WSUS

GT110b で iSCSI Boot を設定

one comment

NEC Express5800/GT110b で iSCSI Boot を実行する方法についてまとめてみたいと思います。

GT110b のオンボード NIC には、Intel の [82574L] というチップセットの NIC が使用されています。
このチップセットですが iSCSI Boot に対応しているのですが、GT110b のオンボード NIC ではiSCSI Boot 用のファームに書き換えることができないため、iSCSI Boot をすることができません。

メーカーのホームページにも iSCSI Boot 不可という記載がされています。
Express5800/GT110b

実際にオンボード NIC のファームを更新しようとすると、以下のように表示がされて更新することができませんでした。

そこで、今回は Intel の [EXPI9301CT] という NIC を購入してこの NIC で iSCSI Boot を設定してみました。
この NIC もオンボードと同じ [82574L] のチップセットを使用しているのですが iSCSI Boot 用のファームのアップデートを行うことが可能です。
また、オンボードの NIC と同じ Intel のチップセットなのでチーミングを組むことも可能です。
# iSCSI Boot 用のファームにした場合はチーミングを組むことができませんが。
お値段も 3,000 円台と手ごろな価格で入手が可能です。

この NIC を使用して iSCSI Boot を設定していきたいと思います。

ファームのアップデートですが 2 種類の方法があります。

一度ローカルディスク上に OS をインストールしてそこからデバイスマネージャーで iSCSI 用のファームにアップデート
USB メモリに起動可能な DOS のイメージを格納して、そこから iSCSI Boot 用のユーティリティを実行

どちらの場合も、以下の URL からダウンロードできるファームを適用します。
iSCSI boot BIOS firmware utility

ファームを書き換えるとチーミング / PXE ブートができなくなるのですが、元のファームに戻したい場合はこちらのファームを適用します。
Intel Boot Agent BIOS image utility ? IBABUILD

GT110b の iSCSI Boot の検証をしていて気づいたのですが、オンボードの Software RAID を使用すると iSCSI Boot がうまくできなかったので、この点は注意が必要になるかもしれません。
# Software RAID を有効にすると iSCSI Boot のファームが起動してこなかったのですよね。

■ OS インストール後にファームをアップデート

今回は OS として Windows Server 2008 R2 をインストールしています。
82574L のチップセットの NIC ですが、OS のインストールメディアに含まれるドライバで認識ができるのですが、標準ドライバでは細かな設定をすることができません。

Intel のサイトから最新のデバイスドライバをダウンロードしてインストールします。
Network Adapter Driver for Windows Server 2008 R2*
# [PROWinx64.exe] を使用します。

インストールに関してはデフォルトでインストールをすれば問題ありません。

デバイスドライバを最新にするとタブが増えます。

[起動オプション] タブに [フラッシュの更新] ボタンがありますのでこれをクリックして、ダウンロードした iSCSI Boot 用ファームウェアの [iscsi.flb] というファイルを選択し、ファームをアップデートします。

[フラッシュの更新] をクリックします。
[はい] をクリックします。
[いいえ] をクリックします。
# PXE ブートのファームに関してはダウンロードできますので。
[はい] をクリックします。
[iscsi.flb] を選択して、[開く] をクリックします。
[はい] をクリックします。
[OK] をクリックします。

これでファームの変更は完了です。
ファームが iSCSI Boot バージョンに変更されています。

[アクティブイメージ] を [iSCSI Boot] に変更すると iSCSI Boot 用の設定をすることが可能になります。

■DOS 起動可能な USB で起動してファームをアップデート

OS をインストールしないでも DOS 起動可能な USB メモリで起動をしてファームを更新することも可能です。
DOS 起動可能な USB メモリを作成する方法ですが、[Windows 98 System Files] と [HP USB Disk Storage Format Tool] を使うと作成することが可能です。

作成した USB メモリで起動をすると DOS が起動しますので、コマンドを実行してファームの更新を行います。
USB メモリの中には、iSCSI boot BIOS firmware utility でダウンロードしたファイルを解凍したものを入れておきます。

今回は USB メモリの直下に [iSCSI] というディレクトリを作成してその中に格納をしています。

DOS 起動でファームを iSCSI Boot 用のものにアップデートするときには、[ISCSIUTL.EXE] を使用します。

この EXE を起動すると現在のファームのバージョンを確認することができます。

CD C:ISCSIISCSIUTLDOS
ISCSIUTL

Intel(R) iSCSI Remote Boot Utility
Copyright (C) 2003-2010 Intel Corporation

Type iSCSIUTL ?? for help

Port Network Address Series WOL Flash Firmware       Version
==== =============== ======= === ==================== ========
1   xxxxxxxxxxxxxxxx Gigabit YES PXE Enabled          1.3.53
2   xxxxxxxxxxxxxxxx Gigabit YES FLASH Not Present

[1] が今回追加した NIC で [2] がオンボードの NIC になります。
オンボードの NIC は [Flash Firmware] が [FLASH Not Present] となっており、ファームウェアの更新を行うことができません。
これが回避できればオンボード NIC で iSCSI Boot ができるのですけどね…。

ISCSIUTL には[-FLASHENABLE] というオプションがあるのでそれを試してみたのですが駄目でした…。

本題に戻って iSCSI 用のファームにアップデートしたいと思います。

ISCSIUTL でファームを更新する場合、2 種類のオプションのどちらかを使用することが可能です。

全アダプターを対象にして更新可能なものを更新
特定のアダプターを対象として更新

ただし、[2] の [-NIC] [-UPDATE] オプションを使用して更新する方法だと、うまく更新を行うことができませんでした。
そのため、今回は [1] の全アダプターを対象にして更新しています。

CD C:ISCSIISCSIUTLDOS
ISCSIUTL ?ALL ?UP

Intel(R) iSCSI Remote Boot Utility
Copyright (C) 2003-2010 Intel Corporation

Press ‘q’ in a prompt to exit the command operation
Programing flash on port 1 with flash firmware image
Create restore image before proceeding? (Y)es or (N)o:N
Continue update without restore image? (Y)es or (N)o:Y
Updating iSCSI Remove PXE functionality
Would you like to Continue? (Y)es or (N)o:Y
Flash update successful

Unsupported feature on port 2
ERROR: Flash update was unsuccessful

Port Network Address Series WOL Flash Firmware       Version
==== =============== ======= === ==================== ========
1   xxxxxxxxxxxxxxxx Gigabit YES iSCSI Enabled        2.5.12
2   xxxxxxxxxxxxxxxx Gigabit YES FLASH Not Present

現状のファームのバックアップを取得しないでファームをアップデートする場合はこのような形で実行を行います。
全アダプターを対象として実行していますので、オンボード NIC も更新しようとするのですがファームのアップデートには対応をしていないためエラーとなっています。

以上でファームのアップデートは完了です。

続いて iSCSI Boot 用の設定をしていきたいと思います。
iSCSI Boot 用の設定ですが、OS のデバイスマネージャーかファームのユーティリティを起動して設定をすることができます。

■OS から iSCSI Boot を設定

デバイスマネージャーから iSCSI Boot の設定をしてみたいと思います。
デバイスマネージャーからネットワークアダプターのプロパティを開いて設定を行います。

[起動オプション] タブをクリックします。
[アクティブイメージ] を iSCSI Boot に設定します。
アクティブイメージを変更することで iSCSI Boot 用の設定をすることが可能となります。
[起動の優先度] を選択して、[プロパティ] をクリックします。
[プライマリーの設定] をクリックして、[OK] をクリックします。
[OK] をクリックします。
[イニシエータ] を選択して、[プロパティ] をクリックします。
iSCSI イニシエーターの設定情報を入力して、[OK] をクリックします。
DHCP がある場合は iSCSI Boot をする NIC の IP アドレスを自動で取得することができますが、今回は固定 IP を割り当てています。
[ターゲット] を選択して、[プロパティ] をクリックします。
iSCSI Boot で使用する LUN を用意している iSCSI ターゲットの情報を入力して、[OK] をクリックします。
私は iSCSI に QNAP の TS-439 を使用していますので、ターゲットの IQN はQNAP 用の設定になっています。
iSCSI ターゲットの [起動 LUN] に関しては、最初の LUN が [0] になるようですね。
今回は対象のターゲットにはブート用の LUN 一つのみを設定しています。
認証設定をしている場合は、[認証] を選択し [プロパティ] をクリックします。

続いてファームのユーティリティから iSCSI Boot の設定を実施してみたいと思います。

■ファームのユーティリティから iSCSI Boot を設定

オンボードの Soft RAID を有効にしている場合は無効に設定します。

起動時に iSCSI Remote Boot 用のファームが起動してきますので [Ctrl] + [D] をクリックしてファームのユーティリティを起動します。
# Soft RAID を有効にしているとこの画面が表示されないのですよね…。

Intel (R) iSCSI Remote Boot version 2.5.12
Copyright (c) 2003-2010 Intel Corporation. All rights reserved.
Press ESX key to skip iSCSI boot initialization.
Press <Ctrl-D> to run setup…

iSCSI Remote Boot が起動しますので、設定を行うポートを選択して [P] を押して PRIMARY に設定をします。
設定をしたら [Enter] を押し、確定します。

Intel(R) iSCSI Remote Boot v2.5.12
==================================================================================

iSCSI Port Selection

MAX:xxxxxxxx Dev:i0D3 Loc:13:0:0 BOOT:PRIMARY

==================================================================================
Select iSCSI Boot priority: P=PRIMARY S=SECONDARY D=DISALED B=BLINK LED

[iSCSI Port Selection] を選択し、[Enter] を押します。

Intel(R) iSCSI Remote Boot v2.5.12
==================================================================================

iSCSI Port Configuration

iSCSI Port Selection

iSCSI CHAP Configuration

Discard change and Exit

Save change and Exit

iSCSI イニシエーターとターゲットの設定をして、[OK] を押します。

Intel(R) iSCSI Remote Boot v2.5.12
==================================================================================

iSCSI Boot Configuration

[ ] Use dynamic IP Configuration (DHCP)

Initiator Name:     iqn.2010-11.gt110b-03.local
Initiator IP:       192.168.0.1
Subnet Mask:        255.0.0.0
Gateway:            192.168.0.254
VLAN ID:

[ ] Use DHCP for iSCSI Target information
Target Name:    iqn.2004-04.com.qnap:ts-439.iscsi.iscsiboot.xxxxxx
Target IP:      192.168.0.10
Target Port:    3260
Boot LUN:       0

[OK] [Cancel]

認証設定がある場合は、トップのメニューで [iSCSI CHAP Configuration] を選択して設定を行います。

Intel(R) iSCSI Remote Boot v2.5.12
==================================================================================

iSCSI CHAP Configuration
Specify the same authentication information
as configured on the target.

[ ] Use CHAP

User Name:
Targert Secret:

[ ] Use MutualCHAP

Initiator Secret:

Minimum CHAP secret length is 12 and maximum 16.

[OK] [Cancel]

設定が終わったら、トップメニューの [Save changes and Exit] を押して設定を保存します。
[ESC] を押してユーティリティを終了させます。

設定が終了して、ユーティリティを終了させると起動画面に戻るのですが設定が正しく行われていれば以下のように表示がされ iSCSI ターゲットの LUN に接続ができていることを確認できます。

Initializing adapter configuration ? MAC address (xxxxxxxxxxxxxxxxx).
Using STATIC configuration for primary port, please wait.
iSCSI Target Name       : iqn.2004-04.com.qnap:ts-439.iscsi.iscsiboot.xxxxxx
iSCSI Target IP Address : 192.168.0.10
LUN ID: 0                   Port: 3260
iSCSI Initiator IP      : 192.168.0.1
iSCSI Gateway IP        : 192.168.0.254
iSCSI Initiator Name    : iqn.2010-11.gt110b-03.local

Attempting to connect to target disk using MAC address (xxxxxxxxxxxx)
LUN: 0 DEVICE: QNAP iSCSI Storage 40.0 GB

ここまでで設定は完了です。

内蔵のディスクに OS をインストールしている場合は、BIOS のブート順で [PCI SCSI: Intel (R) iSCSI Remote Boot] を [IDE HDD] より上になるように設定をしておきます。
# Soft RAID を有効にしていると Remote Boot がブート対象として表示されないのですよね。

iSCSI Boot でインストールした環境がこちらになります。
40GB の領域が iSCSI の領域になります。

Soft RAID と併用する方法が分かっていないのですが、iSCSI Boot の検証したいときには利用ができそうです。
Soft RAID 構築後にジャンパピンを変更しても設定はそのまま残っていますので、iSCSI Boot に切り替えたいときも既存環境を壊さないで確認ができます。

iSCSI Boot から PXE Boot 用のファームに変更したいときは、Intel Boot Agent BIOS image utility ? IBABUILD からダウンロードしたファームを適用すれば戻すことができます。

作業内容は同じで、OS から変更する場合はデバイスマネージャーで NIC のプロパティを開いて、[フラッシュの更新] から

[BA1353L2.FLB] を選択して適用を行います。

iSCSI Boot で起動している状態で、iSCSI Boot に使用している NIC に対して変更できました。

DOS 起動可能な USB メモリから変更する場合は、以下のコマンドを実行します。
# USB メモリに [Boot] というディレクトリを作成してその中にダウンロードしたファイルを展開しています。

CD C:BOOT
IBAUTIL.EXE ?ALL ?UP

設定も簡単に戻せるので気軽に検証ができそうですね。
EXPI9301CT は amazon でも購入できますので入手も難しくありませんので結構おすすめかもしれないですね。

Written by Masayuki.Ozawa

11月 20th, 2010 at 3:01 pm

Posted in Windows Server

Tagged with iSCSI Boot

SSMS を RemoteApp で使ってみる

leave a comment

SQL Server の管理をするために使用する SQL Server Management Studio (SSMS) ですが、サーバーにはインストールをしているケースが多いと思いますが、保守用のクライアントには入っていないことがあるかもしれないです。

そんな時に便利なのが RemoteApp。

正確に言うと以下の更新プログラムをインストールすることで使用できるようになる、アプリケーションのコンソールリダイレクト機能を使用します。
# Windows 7 / 2008 / 2008 R2 は更新プログラムをインストールしないでも使用できます。

RemoteApp? を有効にするための WindowsR XP SP3 用の更新プログラム
RemoteApp? を有効にするための WindowsR Vista SP1 以降用の更新プログラム

残念ながら Windows Server 2003 用はないのですよね…。
これが使用できるのは、Windows XP SP3 / Windows Vista SP1 以降 / Windows 7 / Windows Server 2008 / Windows Server 2008 R2 上で実行されているプログラムをクライアントで使用したいときに限定がされます。

XP / Vista の初期で使用されている、RDP 6.x 系でも使用できます。
最新の RDP 7.0 を使用したい場合は以下の更新プログラムをインストールします。
Windows XP 用の更新プログラム (KB969084)
Windows Vista 用の更新プログラム (KB969084)

有効にするための方法はいろいろとあるのですが一番単純なのは、起動したいアプリケーションがインストールされているサーバー (今回は SQL Server をインストールしているサーバー) で以下のレジストリを 1 にすることだと思います。
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTsAppAllowList]
[fDisabledAllowList] (REG_DWORD)

デフォルトは [0] になっていますのでこれを [1] に変更します。
# 再起動は不要です。

これでサーバーで起動できるアプリケーションをリモートデスクトップ経由でリダイレクトできるようになります。
サーバーのアプリケーションを利用したい端末で以下の内容を記載した [.rdp] という拡張子のファイルを作成します。
IP アドレスを記載している部分は接続したいサーバーの IP アドレスに変更してください。
# 最後の行は改行されてしまっていますが一行で記載します。

full address:s:192.168.0.1
server port:i:3389
remoteapplicationmode:i:1
remoteapplicationname:s:SQL Server Management Studio
remoteapplicationprogram:s:C:Program Files (x86)Microsoft SQL Server100ToolsBinnVSShellCommon7IDESsms.exe

リモートデスクトップを使用していますので、サーバー側でリモートデスクトップを有効にする必要もあります。
# 3389 はリモートデスクトップのポートですので。

上の画像では、NLA (ネットワークレベル認証) で設定をしていますが、NLA でない設定でも問題はありません。

後は作成した RDP ファイルを実行して、リモートデスクトップ接続をすれば RemoteApp で SSMS を起動することが可能です。

SSMS が起動してきているのですが、[(リモート)] となっているのが確認できます。
これはリモートデスクトップ経由でアプリケーションが実行されていることになります。

タスクマネージャーから確認をしても同様に (リモート) となっています。

リモートデスクトップで接続ができる環境にインストールされているプログラムを透過的に利用したい場合は結構便利だと思います。

私は、XP の環境で Hyper-V マネージャーを使用したい場合にもこの方法を使用して使っていたりします。
# UAC が働くので、一度ダイアログが表示されてしまいますが。

Written by Masayuki.Ozawa

11月 8th, 2010 at 12:02 am

Posted in Windows Server

Windows Server 2008 R2 SP1 RC の Hyper-V マネージャーの変更点

leave a comment

Winodws Server 2008 R2 SP1 RC のインストールが終わったので Hyper- マネージャーを少し触っています。

Windows Server 2008 R2 SP1 RC の評価ガイドは以下からダウンロードできるのですが現状は Beta の内容がベースになっているようで、RC での変更点は記載されていないようでした。
Windows Server 2008 R2 SP1 RC Reviewer’s Guide
Download Windows Server 2008 R2 Technical Whitepaper

■ RTM / Beta / RC の Hyper-V マネージャーの表示内容の比較

Hyper-V マネージャーは RTM / Beta / RC で設定できる内容や表示内容に変更があります。
それぞれを比較していきたいと思います。

SP1 Beta / RC で起動した仮想マシンですが、構成ファイルに SP1 特有の定義が入るためエクスポートしても RTM にインポートできなくなりますのでご注意ください。
# エクスポート前やエクスポート後の構成ファイルを手で書き換えればインポートできるかもしれませんが…。

■仮想マシンの一覧画面
SP 1 では Dynamic Memory の機能が追加されています。
SP1 以降では、仮想マシンの一覧画面が Dynamic Memory に対応した表示になっています。

[RTM]

[SP1 Beta]

[SP1 RC]

Beta では、[現在のメモリ] [使用可能なメモリ] という表示だったものが、SP1 Beta では、[Assgined Memory] [Memory Demand] [Memory Status] という表示になっています。

Beta では、[現在のメモリ] に、仮想マシンに割り当てらている物理メモリ、[使用可能なメモリ] に [(現在のメモリ – 仮想マシンのコミットチャージ) / 現在のメモリ] の値が表示されています。

Dynamic Memory で仮想マシンにメモリが割り当てられる場合は、使用可能めなメモリがマイナスを示すことはありませんが、メモリが割り当てられなくなり、コミットチャージが割り当てられている物理メモリを超えた場合、この値はマイナスになります。

上の画像は使用可能なメモリがマイナスとなっているときの仮想マシンの状態になります。
# Dynamic Memory はスタートアップ RAM が 1024 MB、最大 RAM が 1536 MB で設定しています。
[コミット (MB)] が 2046 MB になっていますが、[現在のメモリ] は 1536 MB になっています。
そのため、[(1536 ? 2046) / 1536 = ?0.33203125 = ?33%] となります。

仮想マシンに割り当てられているメモリが足りていないということですね。

SP1 RC だと、[Assgined Memory] [Memory Demand] [Memory Status] の 3 項目に表示が変更がされています。

[Assgined Memory] は Beta の [現在のメモリ] に相当します。仮想マシンに割り当てられているメモリが表示されます。
[Memory Demand] は、仮想マシンのコミットチャージの値が表示されます。
[Memory Status] は、[OK] [Low] [Warning] のいずれかが表示されます。

Beta の [使用可能なメモリ] に相当するのは、[Memory Demand] と [Memory Status] に分けられたようです。
仮想マシンのコミットチャージが [Memory Demand] に表示され、[Assigned Memory] と [Memory Demand] の比較が [Memory Status] に表示されます。

[Assigned Memory] と [Memory Demand] の値に差がある (メモリに余裕がある) 場合は、[OK] が表示されます。

[Assigned Memory] と [Memory Demand] の値に差がな少ない (メモリに余裕が少ない) 場合は、[Low] が表示されます。
具体的にどれくらいの値になると [Low] になるかが記載されているドキュメントは見つからなかったのですが、割合が 86% ぐらいになると Low にはなるようでした。

[Memory Demand] が [Assgined Memory] を超えた (メモリに余裕がない) 場合は、[Warning] となります。

■Hyper-V の設定

NUMA アーキテクチャが使われている環境では、NUMA ノード内のメモリに当てはまる範囲で、仮想マシンのメモリを設定するのがベストプラクティスとなっています。
# NUMA ノード内に当てはまらないメモリを割り当てた場合、パフォーマンスが低下することがあります。
Hyper-V のパフォーマンスおよび容量の要件

SP1 では、[Hyper-V の設定] の設定が追加されています。

[RTM]

[SP1 Beta]

[SP1 RC]

SP1 では、[NUMA ノードにまたがるメモリ割り当て] という設定が追加されています。
デフォルトでは、[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] が有効に設定されています。
この設定ですが変更をすると再起動が必要となりますので、稼働中は変更することができないので注意が必要です。

この設定ですがレジストリに格納がされています。

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationNumaSpanning]
この DWORD に値が設定されます。
[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] を有効にしている場合は、[1] が、無効にしている場合は、[2] が設定されます。
RTM からアップグレードした場合は DWORD が存在していないようです。存在しない場合は有効という判断なのかもしれないですね。

■Dynamic Memory の設定

Dynamic Memory のバッファの設定方法が SP1 Beta と RC では変更されています。

[RTM]

[SP1 Beta]

[SP1 RC]

SP1 Beta ではメモリバッファーはスライドバーだったのですが、SP1 RC ではテキストボックスに変更がされています。

RetemoFX 関連の設定に関しては変わっていないようですね。

RTW した際にはまた変更されているかもしれませんが、ひとまず気づいたことをまとめてみました。