さらに続きの投稿で。

データファイルを追加した際にファイルの再構成ではファイルの平準化はされませんでした。
この時の各ファイルの読み取り / 書き込みの状態を確認してみたいと思います。

データベースのファイルのアクセス状況を確認したい場合には、[sys.dm_io_virtual_file_stats] または、[fn_virtualfilestats]を使用します。
ここから情報を取得することでファイルのアクセス状況を取得することができます。
今回は、以下のクエリを実行して情報を取得してみました。

SELECT     DB_NAME(database_id) AS [database_name],     FILE_NAME(file_id) AS [file_name],     num_of_bytes_read,     num_of_bytes_written FROM     sys.dm_io_virtual_file_stats(DB_ID(N’TEST’), NULL)

それでは、インデックスの再構成を実行し、その後情報を再取得してみたいと思います。

再構成実行後、実行前の情報の差を出すことで、どのファイルに対してアクセスがされたかを確認することができます。

database_name	file_name	num_of_bytes_read	num_of_bytes_written
TEST	TEST	0	19,578,880
TEST	TEST_log	0	55,043,072
TEST	TEST2	0	0

num_of_bytes_written が [TEST] [TEST_log] にだけ発生しているのが確認できます。
インデックスの再構成は再構築とことなり、新規にデータを再構築するのではなく、既存のエクステント内でデータを再構成しますので、このような動きとなります。

それではこの状態から再構築をしてファイルのアクセスを確認したいと思います。

database_name	file_name	num_of_bytes_read	num_of_bytes_written
TEST	TEST	0	13,508,608
TEST	TEST_log	0	25,758,720
TEST	TEST2	0	8,151,040

 

再構築をした場合は、[TEST2] にも書き込みがされていることが確認できます。

データ平準化の動作は、ファイルのアクセス状況を取得することで確認することもできますので、簡単にではありますがまとめてみました。

先ほど投稿した内容の続きになります。

データファイルを追加してデータを平準化すると各ファイルの使用状況は以下のようになります。

何かの理由で、追加したデータファイルを削除する必要が発生し、削除をしようとすると以下のメッセージが表示され削除をすることができません。

DataFile ‘TEST2’ の削除に失敗しました。  (Microsoft.SqlServer.Smo) Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo) ファイル ‘TEST2’ は空ではないので、削除できません。 (Microsoft SQL Server、エラー: 5042)

メッセージに表示されているように、すでにデータが格納されているファイルは空ではありませんので削除をすることができません。

データを空にするためには、[EMPTYFILE] を指定してファイルを圧縮する必要があります。
SQL で実行する場合は以下のクエリを実行します。

USE [TEST] GO DBCC SHRINKFILE (N’TEST’ , EMPTYFILE) GO

SSMS で圧縮をする場合は、ファイル単位の圧縮で [データを同じファイル グループの他のファイルに移行してファイルを空にする] を選択してファイルの圧縮を行います。

いずれかの操作をすることで対象のファイルから別のファイルにデータを移行することが可能です。

実行前の各ファイルの使用状況は以下のようになっています。

実行後は以下のようになります。

EMPTYFILE を指定してデータベースの圧縮をすると以下のような結果が表示されます。

UsedPages は 0 となっていますが、SHOW FILESTATS の結果では 1 エクステントが使われています。
# 管理用のページが残っているからだからだと思いますが。

この状態でデータを追加してみます。

EMPTYFILE により圧縮をしたファイルにはデータが格納されていません。

以下は BOL に記載されている内容です。

指定したファイルから、同じファイル グループ内の他のファイルにすべてのデータを移動します。データベース エンジンではデータを空のファイルに配置できなくなったので、ファイルを削除するには、ALTER DATABASE ステートメントを使用します。

圧縮により空にしたファイルにはデータの配置ができなくなりますので、データを追加しても使用されなくなります。
# ページヘッダ と sys.database_files を確認してみたのですが違いがいまいちわかりませんでした…。

空にしたファイルは削除することが可能となります。

SSMS から見るとファイルが削除されているのですが、[sys.database_files] を確認すると実はファイルが削除されていません。

削除しただけでは、[OFFLINE] の状態でエントリとしては残った状態となっています。

SSMS のファイルの表示は [state] が [0] (ONLINE) または [2] (RECOVERING) のファイルが表示されるようになっています。
# 実際には sys.database_files ではなく、sys.master_files から取得しています。

そのため、SSMS では表示はされないがエントリとしては残った状態となります。

エントリが残った状態で同じ名前 (TEST2) でファイルを追加してみます。

データベース ‘TEST’ のAlterに失敗しました。  (Microsoft.SqlServer.Smo) Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo) 次回の BACKUP LOG 操作が終了するまで、ファイル ‘F:DataTEST2.ndf’ を再利用できません。 次回の BACKUP LOG 操作が終了するまで、ファイル ‘TEST2’ を再利用できません。 (Microsoft SQL Server、エラー: 1833)

メッセージに表示されている通りなのですが、トランザクションログのバックアップをしないとエントリが削除されないためエラーが発生しています。
エントリが存在している状態では、[is_name_reserved] が [1] となっています。

BOL には以下のように記載されています。

1 = 削除されたファイル名を再使用できます。新しいファイル名に対して名前 (name または physical_name) を再使用するには、ログのバックアップを実行する必要があります。

0 = ファイル名は再使用できません。

[is_name_reserved] が [1] の状態について明記がされていますね。

それではトランザクションログのバックアップを取って再度確認をしてみたいと思います。

トランザクションログのバックアップを取得することでファイルのエントリが削除されていることが確認できます。

ファイルの削除をする際にはトランザクションログのバックアップをして [sys.database_files] または、[sys.master_files] からエントリが削除されるところまでを確認しておいた方が良いかもしれないですね。

Twitter でご質問をいただきましたので軽くまとめて見たいと思います。

SQL Server のファイルグループは一つ以上のデータファイルで構成がされます。

ファイルグループはデータファイルの集合を管理する論理単位のため、SQL Server 上にデータとして情報が存在するだけですが、データファイルは実際のファイルになりますので、ディスク上にファイルが存在することになります。

データベースのデータはファイルグループと関連付けますので、データも絵に含めると以下のような形になります。

 

テーブルの件数が増加し、ディスクのサイズが枯渇 / ディスク負荷低減のため、ファイルグループに新規にデータファイル (ndf) を追加することがあります。

テーブルはファイルグループに関連づいていますので、そのファイルグループにデータファイルが追加されれば、使用できる領域が増えることになり、ディスクサイズの枯渇に関しては対応ができます。

ディスク負荷低減についてはどのようになるかを考えてみます。
ディスク追加後の各ファイルのデータの充填状況は以下のようになっています。
# 赤が使用領域となります。

追加したデータファイルにはデータは格納されていませんので、読み取りは今まで存在したデータファイルに、書き込みは新規に追加したデータファイルに集中することになります。
# 読み取りはデータが格納されているファイル / 書き込みは空きページの多いファイルに対して行われますので。

通常、同一のファイルグループにデータファイルを追加する場合は別のディスクにしますので、データの充填率は以下のようになっているとディスク I/O が分散されることになります。

データファイル追加後は上記の図のようにデータファイル内のデータは各ファイルに平準化して格納されていません。
平準化をするためにはデータ領域を再構築してデータを均等に配置する必要があります。

それでは、各状態を SQL Server で実際に確認をしてみたいと思います。

■初期状態

今回は [TEST] というデータベースを作成しています。

このデータベースですが単一のデータファイルで構成されています。
テスト用のテーブルを作成して、データを入れてありますので現在のファイルの使用状況を確認してみたいと思います。
ファイルの使用状況を確認するためには [DBCC SHOWFILESTATS] を使用します。
この DBCC コマンドを実行することで、現在のデータベースのファイル使用状況を取得することができます。

ファイルの使用状況はエクステントで表示されます。
[TEST.mdf] は [1,600] エクステント (1,600 × 64 KB = 102,400 KB = 100 MB) 割り当てられ、そのうち [339] エクステント (339 × 64 KB = 21,696 KB = 21 MB)  が使用されていることが確認できます。

■ファイル追加後のデータ充填状況

それではファイルグループにデータファイルを追加して、データの充填状況を確認してみたいと思います。
# ドライブ構成の関係で既存のファイルと同じドライブに格納してしまっています…。

今回は [TEST2.ndf] というファイルを追加しています。

それではデータファイル追加後の使用状況を取得してデータの充填状況を確認してみたいと思います。

新規に吹ファイルが追加 (Fileid = 3) され、UsedExtents が [1] (管理用ページを作成する必要があるため) となっています。
データファイルを追加後はこのような状態となります。

 

■データを平準化する

データを平準化するためにはどうすればいいかというと、データ領域の再構築を行います。
# ヒープの場合は別の機会に考えて見たいと思います…。
再構築はインデックスの再構築をすれば実施できますので、インデックスの [REBUILD] を行います。

インデックスの再構築では、エクステントも含めてデータを再配置し直しますので、データが各ファイルに均等に再配置されます。

インデックスの再構成 (REORGANIZE) では、エクステントの再割り当てはせずに既に存在しているエクステント内でページの並び替えを行いますのでデータは平準化されません。

それでは、実際に確認をしてみたいと思います。

まずはインデックスを再構成してみます。
# GUID をキーにしてテスト用のデータを生成しているので断片化が著しいです…。

再構成後のデータ充填率を取得すると各ファイルにデータが分散していないことが確認できます。

それでは、再構成 (REORGANIZE) ではなく 再構築 (REBUILD) を行ってみます。

完全に平準化 (199 ページずつ) とはいきませんでしたが今まで UsedExtents が 1 となっていた TEST2.ndf のエクステントが利用されていることが確認できます。

データファイルの追加後にデータ領域を再構築することで、既に格納されているデータについて使用するファイルを平準化することができます。

 

■ファイルサイズの差によるデータファイルの使用状況

データファイルのサイズを変更して、

• TEST.mdf : 100 MB
• TEST2.ndf : 1 MB

にしてみました。
# 自動拡張は有効です。

この状態でデータを挿入するとどうなるか試してみます。

TEST2.ndf は 1 MB のサイズに変更しましたので 16 × 64 KB = 1,024 MB と割り当てていたサイズはすべて使用されていますが、自動拡張はせずに残りのデータは TEST.mdf に格納がされています。
データ格納時は空きページを考慮してデータを格納していきますので空きがある TEST.mdf が使用されたことになります。

これは極端な例ですので、

• TEST.mdf : 100 MB
• TEST2.ndf : 20 MB

として、

両方のファイルで分散させたデータが格納できる状態にしてデータを挿入してみます。

この場合は両ファイルに十分な空き領域がありますので、両方のファイルが均等と言っていいレベルで使用されています。

 

使用されるファイルは空き領域 (ページ) が考慮されて使われますので、均等にデータを書き込んだ結果片一方の空きページに余裕が無くなってしまうと思ったようにディスク利用が分散されない可能性があります。

使用領域を増やすのではなく、ディスクのアクセス効率を向上するためにファイルを追加した場合は追加後に各ファイルでデータを平準化するかを考慮し、作業 / 確認をした方がよいかもしれないですね。

Tech・Ed Europe 2010 のセッション資料が Tech・Ed Online で公開されています。
Tech・Ed Online

Denali リリース後に開催された (といっても本当に直ぐ後ですが) Tech・Ed となり、Denali に関連するセッションがいくつかあったようです。

気づいた範囲になりますが Denali が含まれるセッションをまとめてみました。
# 一文は入っているだけのセッションもありますが。

BIN204:Offering PowerPivot as a Service – Best Practices from Microsoft IT
BIN206:A-to-Z of Master Data Services in Microsoft SQL Server 2008 R2
BIN308:Finally: Data Lineage in Business Intelligence Projects with SQL Server Metadata Toolkit 2008
BIN310:Analysis with Microsoft PowerPivot
DAT222:Microsoft SQL Server Code Name "Denali" Overview
DAT303:SQL Server “Denali” High Availability:The next generation high availability solution
DAT342:SQL Server Performance Series – Part 3 – Query and Index Tuning
# DAT340～342 は Perfomance Series になっており Denali ではありませんがおすすめのセッションです。

DAT222 / DAT303 は Denali とセッション名についているようにフォーカスして情報が公開されています。
# DAT222 は PPTX の提供がないので動画を途中までしか見て入れませんが。

Tech・Ed Europe 2010 のセッション資料のダウンロード先やセッション一覧は以下の URL にテキストベースにはなりますが、簡単にまとめたファイルを作ってみましたので、興味のある方はご利用いただければと思います。
Tech Ed 2010 Europe

最近は 64 ビット (x64) の OS を使う機会の方が多いと思いますが、あらためて 32 ビット (x86) の SQL Server のメモリチューニングについてまとめていきたいと思います。

今回は

• Windows Server 2008 Datacenter Edition x86 SP2
• SQL Server 2008 R2 Enterprise Evaluation x86
• SQL Server Code Name ‘Denali’ Enterprise Evaluation x86
• 4 CPU
• 6GB Memory

の環境を使用しています。

■仮想アドレス空間の確認

32 ビット の SQL Server の場合、ユーザーモードの仮想アドレス空間 (VAS : Virtual Address Space) の最大サイズは通常 [2GB] となります。

SQL Server のユーザーモードの VAS ですが、SQL を実行して確認をするためには二種類の方法があります。

1. DBCC MEMORYSTATUS を実行
2. sys.dm_os_memory_nodes を参照

この 2 種類の方法で VAS の状態を確認することが可能です。

DBCC MEMORY STATUS については技術情報が提供されています。
DBCC MEMORYSTATUS コマンドを使用して SQL Server 2005 のメモリ使用量を監視する方法

sys.dm_os_memory_nodes に関しては BOL に情報が記載されています。
sys.dm_os_memory_nodes (Transact-SQL)

これらを使用することで SQL Server の VAS の情報を確認することができます。

DBCC MEMORYSTATUS  を実行するとこのような情報が取得できます。

Memory Manager                           KB —————————————- ———– VM Reserved                              1114756 VM Committed                             1048580 AWE Allocated                            0 Large Pages Allocated                    0 Emergency Memory                         1024 Emergency Memory In Use                  16 Target Committed                         1048576 Current Committed                        1048576 Pages Allocated                          1019480 Pages Reserved                           0 Pages Free                               2672 Pages In Use                             105968 Page Alloc Potential                     890176 NUMA Growth Phase                        2 Last OOM Factor                          0 Last OS Error                            0

sys.dm_os_memory_nodes ではこのような情報が取得できます。

memory_node_id virtual_address_space_reserved_kb virtual_address_space_committed_kb ————– ——————————— ———————————- 0              1114692                           1048568                            32             0                                 12                                 locked_page_allocations_kb pages_kb             shared_memory_reserved_kb ————————– ——————– ————————- 0                          1019480              0                         0                          1019480              0                         shared_memory_committed_kb cpu_affinity_mask    online_scheduler_mask ————————– ——————– ——————— 0                          15                   15                    0                          15                   15                    processor_group foreign_committed_kb ————— ——————– 0               0 0               0

どちらのコマンドを実行しても VAS の情報を確認可能です。
DBCC MEMORYSTATUS で取得できる情報は、[sys.dm_os_memory_nodes] [sys.dm_os_memory_clerks] [sys.dm_os_memory_objects] [sys.dm_os_memory_cache_counters] [sys.dm_os_memory_pools] から取得することも可能です。

これらの情報を取得することで、[reserved] と [committed] の2 種類を確認することができます。
[reserved] (予約) は仮想メモリの領域を予約しているが実際には物理メモリを割り当てていない状態、 [committed] (確定) は物理メモリを割り当てている状態になります。

■max server memory の設定

SQL Server では [max server memory] を設定することでメモリの上限を設定することができますが、この設定をすることで、[reserved] とするサイズの上限を制限することが可能です。

今回は 32 ビット版の SQL Server を使用しているのですが、1.6GB 程度 VAS が確保できています。
# 大量のデータを検索して SQL Server のメモリを使用させた状態です。

この情報は以下のクエリを実行して取得しています。

SELECT     [virtual_address_space_reserved_kb] / 1024 AS [VAS Reserved (MB)],     [virtual_address_space_committed_kb] / 1024 AS [VAS Committed (MB)] FROM     [sys].[dm_os_memory_nodes] WHERE     [memory_node_id] = 0

初期設定の状態なので max server memory は [2147483647] が設定されているので、使用できる上限まで SQL Server はメモリを確保します。

それでは、max server memory を [1024] に設定して VAS の状態を確認してみたいと思います。

max server memory を設定することで、[Committed] のサイズが変更されていることが確認できます。
今回は設定変更後はサービスを再起動していないため、[Reserved] に関しては 1024 MB 以上の値となっています。
このことから max server memory は [Reserved] ではなく [Committed] 状態のメモリのサイズを制御していることが確認できます。

サービスの再起動をして、Reserved を解放し再度メモリの割り当てを確認してみます。

起動直後の VAS の状態は以下のようになっています。
SQL Server は通常の設定では max server memory を設定しても、起動直後は最小限のメモリのみ [Reserved] [Committed] で確保を行います。

サービスを再起動すると最小限の [Reserved] [Committed] から開始されますので、[Reserved] の確保も抑えられた状態となります。
# [Committed] が [1024 MB] で上限となるので、[Reserved] の確保も抑えらえた状態となります。

 

■/3GB スイッチによる VAS 上限の変更

今回の環境ではメモリを 6GB 割り当てているのですが、32 ビット OS の制限でユーザーモードの VAS の上限は 2GB となっています。
以下は SQL Server のメモリ割り当て (Memory ManagerTotal Server Memory (KB)) とサーバーの空きメモリ (MemoryAvailable MBytes) の関係をグラフ化したものになります。

サーバーの空きメモリはあるのですが、SQL Server で使用しているメモリについては VAS の上限に達してから頭打ちになっているのが確認できます。

この状態が 32 ビット版の SQL Server の通常設定時の限界となります。
空きメモリがあるにも関わらず、32 ビット OS の制限でメモリを最大限使用できない状態となっています。

32 ビット OS では [/3GB] オプションを設定することで、ユーザーモードのVAS の上限値を 2GB → 3GB に変更することが可能となります。
# [/3GB スイッチ] [4GB チューニング] と呼ばれる設定になります。

Windows Server 2003 向けなりますが以下の技術情報が公開されています。
/userva スイッチと /3GB スイッチを使用してユーザー モード領域を 2 ～ 3 GB の間でチューニングする方法
4 GB RAM チューニング機能と物理アドレス拡張のスイッチの説明

Windows Server 2008 以降は boot.ini ではなく、BCD が使用されていますので bcdedit を使用して設定を行う必要があります。

[/3GB] スイッチは、[increaseuserva 3072] で設定することが可能です。

bcdedit /set {current} increaseuserva 3072

上記コマンドをコマンドプロンプトで実行することでユーザーモードの VAS を3GB まで使用することが可能となります。
# 代わりにカーネルモードが 1GB に制限されますが。

設定を削除する場合は以下のコマンドを実行します。

bcdedit /deletevalue {current} increaseuserva

 

設定をしたら一度サーバーを再起動して、SQL Server のメモリの使用状況を確認してみます。

 

設定をすることで設定前と比較して 1GB 程メモリの割り当てが増えていることが確認できます。

この設定をすることで 2GB 以上のメモリを使用することが可能となりますが、サーバーの空きメモリはまだ残っておりメモリを最大限活用できていない状態となっています。

これ以上のメモリを使用するためには AWE (Address Windowing Extensions) を有効にする必要があります。
AWE については次の投稿でまとめたいと思います。

AWE と PAE のテストをしようと思って、大量のデータを作成して SSMS (SQL Server Management Studio) で SELECT 文を実行してキャッシュに載せる検証をしていました。

SELECT 文を実行してみたところ以下のようなエラーが。

C ドライブの空き容量を確認したところ、[0 バイト] との表示が…。

C ドライブに tempdb を格納しているのですが、今回はソートをしていないのでサイズも増えていないのですよね。

ディレクトリのサイズを確認していたら、SSMS を実行しているユーザーの TEMP ディレクトリのサイズが肥大化していました。

Temp ディレクトリに一つ大きなファイルが作成されていました。

Process Explorer で確認をすると SSMS がつかんでいるファイルのようでした。

このファイルですが、大量のデータを返すクエリを実行していたクエリウィンドウを閉じたところ削除がされました。
今まであまり意識していなかったのですが、SSMS で [グリッド形式] で結果を表示するようにすると一時ファイルが作成されるようですね。
10 件程度の結果を返す軽いクエリでもファイルが作成されていました。

[テキスト形式] で結果を返すようにするとファイルは作成されませんでした。

 

急に C ドライブの容量が減ってびっくりしたのですが、SSMS が一時ファイルを作っていることが分かったので勉強になりました。

KeyNote だけですが、MSC 2010 に参加してきましたのでレポートを。

Cloud Power
未来へと続く新しいチカラ
CCC (シーシーシー)
# マークの呼称

グローバルに通用するグローバル基盤の整備という流れがある。
# グローバル経営の基盤

ブレークしたいニーズとクラウドが重なって一材料となるのではないか。
パートナーがグローバルな基盤を持つことでグローバル展開ができるようになるのではないか。

プライベートクラウド
パートナークラウド
パブリッククラウド

 

■ リクルート様講話

個人の方にとって重要な情報/機会を提供するのが役割。

戦略からみたIT

[以前]
情報が集まれば価値になる

[現在]
デバイス/ネットワークの進歩により個人にとって重要な情報を提供するのが重要になってきている。
タイミング / スピード
個人にベストマッチする情報の提供
コストとしてどのようなサービスを提供できるか

グローバルに展開するに際し、IT 基盤をどのように構築するかが重要になってくる

クラウドについて

情報の絶対量の増加/時代のニーズに合わせた情報を提供するシステムをいかに短期間で作成するか
→クラウドの柔軟性がポイントになってくる

コミュニケーションを円滑に行う必要がある。(M&A により海外にも拠点がr増えていくことも考慮)
企業運営の中にクラウドサービスをどこまで取り込んでいけるか
(スピード感を増すためにも重要となってくる)

Microsoft のオンラインサービスを利用している

増大している情報量をさばきながら社内のコミュニケーションを円滑にする必要がある。

省内の環境変化による応用の面でもクラウドは頼もしく思っている。

グローバル戦略における IT /クラウド

IT の進化による流れを自社のチャンスにどのようにつなげていくか
新しい技術を企業経営につなげていくうえでも Microsoft は頼もしいパートナー

 

■ Office 365 のデモ

Office 365 / Windows Phone 7 / Lync

Office 365 Beta の SharePoint に Office ドキュメントをドラッグ & ドロップでファイルをアップロード
# Excel 2010 の Web に保存 / SharePoint に保存でも実施可能

Office 365 Beta の Outlook のデモ
Outlook 2010 で開いていたメールをブラウザからも確認できる。

HTC の WP7 を使用したデモ
WP 7 から Office 365 にアクセスして Excel を開いてみる。

クラウド上での共同作業による生産性向上
Office 365 のチームサイトを使用して、Office Web App の Excel を 2 名で開き共同編集
共同編集中は Office Web App で他ユーザーの編集状況が分かる

富士通製 Slate PC / ONKYO 製 Slate PC
USB ポートを備えた Windows 7 モデル
Slate 端末から Office 365 にアクセスをするデモ

Lync
Lync (クラウドサービス版) を使用してマイクロまいこさんと Excel の共同作業
Excel は PC のローカルに保存されているものを使用して Lync を使用して共同編集を実施。
# 画面を共有して情報の共有を実施

Online Servicesの利用状況
全世界 : 4,000 万人以上
日本国内 : 30 万人以上

 

■ 伊藤病院のメッセージビデオの上映
Exchange Online Service の Standard を利用している
60% のコスト削減を実施できるとのことであった

スマートフォンユーザーから評判も良かった (スマートフォンユーザーがビックるしていた)

 

Dynamics CRM Online

Online のサービスの方がオンプレミスより先にリリースされる
2011 年 1 月に日本で差ーービス提供開始
40 か国 / 41 言語一斉インターナショナルリリース

Dynamics CRM Online を使用したデモ
画面のカスタマイズもブラウザ上で実施することが可能
データのインポート機能も備えている
→ Sales Force からエクスポートしたデータをインポートできる
オンプレミスの Outlook 2010 と Dynamics CRM の連携デモ
→ メール / 予定表から Dynamics CRM とシームレスに SSO で連携

Dynamics CRM Online から Excel にエクスポートすることができる。

スピード経営を支える迅速な展開が可能となる

58 社のパートナーが対応を表ｆ明

 

■ 帝国データバンク様 講話
Dynamics CRM Online の利用を表明
Dynamics CRM Online  TBD 企業情報サービスを組み合わせたクラウド型統合顧客管理サービス

Dynamics CRM Online に情報を乳rykすると TBD 企業情報サービスで照会され最新の企業情報を抽出する。
# 最新の企業情報に基づく照会を実施できる

利便性の高い新サービスの実現
2011 年 2 月のサービス開始を予定

■ 三和コムテック様 メッセージビデオ上映
Sales Force から Dynamics CRM Online に乗り換えをされた
BPOS も利用されている

Outlook との連携がポイント
ストレージが他社と比べると大きい
2/3 程度のコストに落ちた

Sales Force 用の標準で用意されているマップを使用して移行が実施できた

■ シームレスな連携
System Center / Windows Server / Windows azure をシームレスに統合することが可能になる

OpsMgr 2007 R2 を使用して Azure Based Customer Portal Diagram を表示
Azure のインスタンスを追加してダイアグラムを更新して、インスタンスが増えていることを確認

Windows Intune
クラウドからオンプレミス資産を管理
社内の PC 7 台を実際に管理
Windows XP / 2008 R2 / Windows 7 を管理している画面を表示
# Windows 7 Ultimate をインストールした Slate PC も管理している

Windows Azure Marketplace DataMarket
クラウドからビジネスデータを取得
犯罪履歴のデータを使用したデモ
# DATA.GOV
Excel から Marketplace のデータを取得
データ → Import data from DataMarket で Excel から直接データを取り込み

 

■ パソナ様 / パソナグループ様 講話
アーバンファーム
エコを含めた農業への関心

パソナの案件 / 取り組みに Azure を利用している
実際に使ってみようから始まっている
# Azure / Sales Force を使ってみた

導入に当たって感じたこと
Sales Force を使ってクラウドのスピード感を感じた
もう一
つ使ってみるという事で Azure を使った
PaaS もスピード感がある
他のグループ会社への展開にたいしての苦労は少なそうというところでメリットを感じている

 

■ NTT データ様 講話
社内システムの Azure への移行プロジェクト
オンプレミスからクラウド化への流れ

プライベートクラウド
パブリッククラウド
コミュニティクラウド
ハイブリッドクラウド

Azure ～ NTT データのクラウドと連携を行いハイブリッドクラウドの実現

Windows Azure + Windows Azure platform AppFabric + SQL Azure + intra-mart
# intra-mart は Java ベース
インフラのコストが 90% 抑えられる

[課題]
IP/ポート番号が指定できない
既定の AP インストールフォルダは書き込みできない
詳細な ACL が設定できない
標準で OS / DB で暗号化の機能を有していない
スイッチやファイアウォールを設定できないため AP でアクセス制御が必要

アプリケーションを PaaS に移すサービスを立ち上げている
# 今回のプロジェクトもその一環

 

■ 弥生株式会社様 講話
弥生オンラインのご紹介

Why Saas? Why Azure?
20 周年周期でのテクノロジーサイクル (中央→分散→中央）
パッケージ開発との親和性 (C#/.NET Framework)

従来の弥生製品とは異なる統合業務ソフトウェア (ミニ ERP)
仕訳ではなく取引を入力する
日常の業務と弥生オンラインを一体化

2010 年 11 月 クローズドβ開始
2011 年 7 月 オープンβ 開始
2011 年 9 月 一般オープン

 

■ 富士通株式会社様 講話
Azure アプライアンスは、館林に機器導入が完了し、現在試験中

FJ-Azure と 富士通プライベート クラウドサービスとのハイブリッドインテグレーションを進めていく

Azure 技術者 5,000 名教をグローバルに育成

Interstage / Systemwalker / WebSERVE の Azure 対応

FJ-Azure インテグレーションパートナーの育成

 

 

■ Cloud Power
IDC フロンティア様によるクラウドサービス (NOAH)
SQL Server 2008 + WIndows Server

NTT コミュニケーションズ様のハイブリッドクラウド

■ Hyper-V Cloud
Deployment Guide
Fast Track
Service Providers
Hyper-V Cloud Accelerate
(プライベートクラウド導入支援プログラム)

 

■日立製作所様 講話
高信頼クラウドサービスの実現

幅広い業種 / 業務にクラウドソリューションの導入実績を持つ
# NASA の観測データを一括してオンデマンドに管理できるソリューションも提供を行っている

Cloud を支える製品軍
BladeSynmphony
Virtual Storage Platform
CommuniMax AX
JP1

Hyper-V Cloud Fast Track
検証済みの安全、安心なソリューション
クラウド運用の効率化
プライベートクラウドの構築

 

■ NEC 様 講話
NEC グループ 12 万人を支える基幹システムをクラウド化
# Microsoft との技術協業により実現

2010 年 10 月にプライベートクラウドとしてグローバル標準経営システムを全面稼働
# Windows Server 2008 / SQL Server 2008

業務プロセス / IT システムのコストを 20% 削減

クラウド指向データセンター (CODC) を 5 極で順次立ち上げ
(欧州 / APAC /  北米 / 日本 / 中国)

クラウドサービス事業を支える共通プラットフォーム
Windows 基盤システムとして Hyper-V Cloud を採用予定
Express 5800
iStorage

 

■ Microsoft のコミットメント
社内体制強化
パートナーシップ推進
オファリング拡充

最近、自宅の検証環境に 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 サービスを実行した際の一時クラスが生成できずエラーになってしまったみたいですね。

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

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

Denali の HADR の構築はできましたので、今回はフェールオーバーについてまとめてみたいと思います。

■HADR 用のクラスターグループについて

HADR は WSFC が必須の構成となります。
HADR を構築するとクラスターグループとして Availability Group として設定したグループ名が作成されます。

このクラスターグループにはリソースが一つ含まれています。

このリソースですが、[SQL Server Availability Group] というリソースで作成されています。

リソースの所有者が [Primary] として設定されているサーバーになるようですね。

このグループですが、WSFC の管理コンソールからはグループを移動させることはできないようになっているようです。

 

■SSMS で Primary サーバーを切り替え

WSFC のグループは WSFC の管理コンソールからは切り替えることができません。
Primary サーバーを切り替える (フェールオーバーさせる) 場合は、SSMS から操作をする必要があります。

Primary サーバーの切り替えですが、現在 [Primary] サーバーとなっているサーバーの接続からは変更することができません。

• DENALI-01 : Primary
• DENALI-02 : Secondary

となっている場合、DELALI-01 の接続では、サーバーの切り替えをするためのメニューは表示されません。

DENALI-02 に接続し、Secondary で右クリックをするとメニューが少し変わります。

SSMS で Secondary のサーバーに接続をして、Secondary のサーバーを右クリックすると [Force Failover] が表示されます。
[Force Failover] を使用することで Primary と Secondary を切り替えることができます。

CTP1 の Release Notes には以下の記載があります。

The SQL Server Code-Named “Denali” CTP1 release of "HADR" is a preview and does not support the following features:

• Synchronous data movement (synchronous-commit availability mode).

• Manual failover and automatic failover.

  The only supported form is forced failover, which allows data loss and suspends the secondary databases.

• Log compression.

• Automatic page repair.

• The ALTER AVAILABILITY GROUP Transact-SQL statement does not support changing the configuration of the availability group such as changing read-only access to an availability replica, adding or removing an availability database, and adding or removing a secondary availability replica. For information about what this Transact-SQL statement supports, see ALTER AVAILABILITY GROUP (Transact-SQL) in Books Online.

 

現状は マニュアル / 自動フェールオーバーは実装されていないようです。
そのため、Primary / Secondary を切り替えるためには強制フェールオーバーをする必要があります。
# Primary のサービスを停止しても Secondary には切り替わりません。

それでは、[Force Failover] を実行して Primary と Secondary を切り替えてみたいと思います。
DEHALI-02 に接続し、[HADR Group] → [Availability Replicas] を展開して、[DENALI-02] を右クリックし、[Force Failover] をクリックします。
# Secondary の接続でないと [Force Failover] が表示されません。

[OK] をクリックして、フェールオーバーを実施します。

H
ADR の強制フェールオーバーは以上で完了です。

強制フェールオーバー前は以下の状態となっていました。

[DENALI-01]

[DENALI-02]

 

強制フェールオーバーを実施すると以下の状態となります。

強制フェールオーバー前は [Primary] であった、[DENALI-01] が [Secondary] になっているのが確認できます。
強制フェールオーバーを実施した影響だと思うのですが、[Synchronization State] が [Synchronized] から [Not Synchronizing] に変わっています。

データベースの状態も [Online] から [Suspended] に変わっています。

[DENALI-01]

[DENALI-02]

強制フェールオーバーを実施した場合は、自動で [Online] にはならないため手動で HADR による同期を再開する必要があります。

 

同期を再開するためには、[Secondary] に接続をして [Resume Data Movement] を実行する必要があります。

[OK] をクリックして、HADR によるデータ同期を再開します。

Resume をすることでデータ同期が再開されます。

 

自動フェールオーバーや自動ページ修復が実装されるとミラーリングと変わらない利用が出来そうなので期待大ですね。

次の CTP で検証できるようになっているとうれしいですね～。

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 種類の方法があります。

1. 一度ローカルディスク上に OS をインストールしてそこからデバイスマネージャーで iSCSI 用のファームにアップデート
2. 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] というファイルを選択し、ファームをアップデートします。

1. [フラッシュの更新] をクリックします。
   
2. [はい] をクリックします。
   
3. [いいえ] をクリックします。
   # PXE ブートのファームに関してはダウンロードできますので。
   
4. [はい] をクリックします。
   
5. [iscsi.flb] を選択して、[開く] をクリックします。
   
6. [はい] をクリックします。
   
   
7. [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 種類のオプションのどちらかを使用することが可能です。

1. 全アダプターを対象にして更新可能なものを更新
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 の設定をしてみたいと思います。
デバイスマネージャーからネットワークアダプターのプロパティを開いて設定を行います。

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

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

 

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

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

1. 起動時に 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…

2. 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

3. [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   ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

4. 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] ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

5. 認証設定がある場合は、トップのメニューで [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] ================================================================================== Copyright (c) 2003-2010 Intel Corporation. All rights reserved.

6. 設定が終わったら、トップメニューの [Save changes and Exit] を押して設定を保存します。
7. [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 でも購入できますので入手も難しくありませんので結構おすすめかもしれないですね。