« 2011年4月 | トップページ | 2011年7月 »

2011年5月

XNA Game Studio 4.0のインストール

もう3年ほど前に作りかけたゲームを完成させようと思い立った。当時はVisual Studio 2008 + XNA Game Studio 3.0 だったが、今はVisual Studio 2010の時代。2010で続きを作ろうと思いきや、C#のプロジェクトが変換エラーになり、開発ができない。う~ん、ただのC#プロジェクトなのに。。。いや、そういや、思い出してきた。XNA専用のプロジェクトだった気がする。Visual Studio 2010用XNA Game Studioをインストールしないといけないんだな、と気づく。

さっそくマイクロソフト社のサイトで調べてみると、4.0がリリースされており、それがVisual Studio 2010に対応しているとのこと。さらにWindows Phone 7にも対応済み。XNA 3.x時代はWindows Mobileに対応してなかったからなぁ。すばらしいじゃないか。

…ところが、ところがである。ダウンロードページでいくら検索しても「XNA Game Studio 4.0」が無いではないか!日本語パックはあるのに…。いったい、何の仕打ちかと。何か悪いことをした罰なのか。

だがしかし。そうではなかった。実はXNA Game Studio 4.0は単体でリリースされているのではなく、Windows Phone Developer Toolsに含まれる形でリリースされているのでした。今やWindows Phoneがメインということか。(Windows XPの人用にXNA Game Studio 4.0単体インストーラはあるものの、ダウンロードサイトでは検索されない。)

さっそくWindows Phone Developer Toolsをダウンロードし、インストーラを実行。しかし、これがエラーとなる。"vm_web.exe"を実行すると、「compatibility modeでは実行できないッスわ」的な英語のメッセージが出る。exeファイルのプロパティを見ると、なぜかWindows Vistaモードの互換性モード固定になっていた。なんでダウンロードしたファイルが勝手に互換性モードになってんの。やはり何かの罰なのか。exeファイルのプロパティの[互換性]タブの[すべてのユーザーの設定を変更]ボタンをクリックし、[互換モードでこのプログラムを実行する]のチェックをはずして、解決!

| | コメント (0) | トラックバック (0)

クラスタ(MSFC)の試し方メモ

クラスタの各ノードに SQL Server でもインストールしてフェールオーバーを試せばいいんだけど、インストールがめんどくさい。てっとり早く何か試したいよう。そんな時はこの手順で「あぁ、フェールオーバーしてるなぁ」を味わうと。

==その1.クラスタリソースの移動で、クライアントからの接続先が自動的に変わるのを体験

  1. [フェールオーバークラスタ―マネージャー](WindowsServer2003時代の[クラスタアドミニストレータ]相当)を起動し、ツリーのクラスタ名の下にある[サービスとアプリケーション](WindowsServer2003時代に「グループ」と呼んでいたもの相当)を右クリックし、空のアプリケーションを作成。
  2. その中に、IPアドレスリソース(たとえば192.168.7.201とする)を追加。まず、ノード1に所有させておく。(どちらでもいいが)
  3. ノード1でも2でもないPCで、かつ、ノードと同じサブネット内のPC(ここではドメインコントローラを使う)でコマンドプロンプトを開き、
    ping 192.168.7.201
    を実行。応答があることを確認。
    arp -a 192.168.7.201
    を実行。相手のMACアドレスを確認。これが、現在IPアドレスを所有しているサーバーのMACアドレスだ!
  4. ping -t 192.168.7.201
    を実行し、pingを打ち続ける。
  5. どちらかのノードで[フェールオーバークラスタ―マネージャー]を開き、IPアドレスをノード2へ移動する。所有者が変わって、オンラインになったことを確認する。
  6. ドメインコントローラの画面に戻ると、pingが2回ほどタイムアウトし、その後復活するのを確認する。
    フェールオーバーした!
  7. arp -a 192.168.7.201
    を実行し相手のMACアドレスを確認。これが、現在IPアドレスを所有しているサーバーのMACアドレスになっている。先ほどとは異なるMACアドレスになっている。つまり、同じIPアドレスに対して通信しているのに、自動的に別のノードとつながっている!
  8. フェールバックして、再度確認するもよし。

==その2.クォーラムディスクの所有者がディスクにアクセスできなくなると、自動的に別ノードが所有者になるのを体験

  1. [フェールオーバークラスタ―マネージャー]の[記憶域]で、クォーラムディスクの所有者を確認。
  2. その所有者のネットワーク接続を[無効]にする。(コンパネの[ネットワーク]から)
  3. [フェールオーバークラスタ―マネージャー]の[記憶域]で、クォーラムディスクの所有者が変わったのを確認。ちなみに、[エクスプローラー]で見ても、所有者にしか、共有ディスクがドライブとして見えない。
  4. 元所有者のネットワーク接続を[有効]に戻す。

以上。

| | コメント (0) | トラックバック (0)

PC1台にクラスタ(MSFC)環境をインストールする手順

おおざっぱな手順は↓こんな感じ。

  1. ドメインコントローラー、iSCSI Targetのインストール
  2. iSCSI Targetの管理コンソールで、接続を許可するイニシエータ(クラスタノード)のIPアドレスを全部指定する。
  3. 各ノードのOSのインストール(Enterprise Edition 以上)   
  4. ノードで、iSCSIイニシエータの設定ツールで、iSCSI TargetのIPアドレスを入力して検索し、[接続]をクリックする。
    →ここでダイアログに[YES]することで、OS起動時に自動的にサービスが起動してTarget(共有ディスク)に接続するように設定できる。 
  5. iSCSI接続を行うと、[サーバーマネージャ]-[記憶域]-[ディスクの管理]コンソールに、共有ディスクがディスクとして表示される。   
    そのディスクを[オンライン]にし、[初期化]を行う。そしてディスク内をパーティションに分けてドライブ文字を割り当てる。 
  6. 他方のノードでもiSCSIイニシエータを設定して共有ディスクに接続する。   
    そのディスクに、さっきのノードと同じドライブ文字を割り当てる。 
    ※この時点で、両方のノードから、共有ディスクに同時に接続できる。
  7. 両方のノードで、機能の追加を行い、[フォールオーバークラスタリング]の機能をインストールする。   
    ※WS2008からは、サービス起動アカウントがSYSTEMになり、作成不要になった。 
  8. 片方のノードで、[フェールオーバークラスターマネージャー]コンソールを開き、クラスタを新規作成する。   
    ※両方のノードが共有ディスクに接続していないと、クラスタにディスクを追加できない。(クラスタで使用できるディスクが無いと言われる。)   
    その場合は、両方のノードで共有ディスクに接続した後、[記憶域]で[ディスクの追加]を行う。 
    ※共有ディスクの状態は次の通りになった。   
    ・iSCSIで接続し、サーバーマネージャーの[記憶域]でオンラインにしてフォーマットした段階:エクスプローラーでドライブとして参照可能。 
    ・フェールオーバークラスタ―マネージャーの[記憶域]でディスクを追加した段階:所有者ではエクスプローラーでドライブとして参照可能、非所有者のエクスプローラーでは表示されない。 
    ・フェールオーバークラスタ―マネージャーの[クラスターの共有ボリューム]にディスクを追加した段階:所有者でもエクスプローラーでドライブとしては表示されない。 
    ツリーで[<クラスタ名>]を右クリックして、[その他のアクション]-[クォーラムの構成(だったか?)]を選択し、   
    [ノードおよびディスクマジョリティ]に変更。(なぜか既定ではノードマジョリティになっていた。) 
    これで、共有ディスクをクォーラムディスクとして設定。 

※マジョリティの決定は、クラスタ内のPC群の通信が分断された場合に、スプリットブレーンが発生するため、自分が起動すべきか停止すべきかを判断するために、 
  ・自分と通信可能なノード数が、クラスタの過半数を超えていたら、起動する(でなければ停止する) … ノードマジョリティ。
  ・監視ディスク(または共有フォルダ)にアクセスできたら、起動する(でなければ停止する) … ディスクマジョリティ。
の方式があり、ノード数が偶数の場合は、ちょうど過半数になりうるので、ディスク監視も行う必要がある。 
2ノードクラスタでは、通信障害時は1ノードだけになるので、常にディスク監視のみによって、起動するか停止するかを判断する。 
※quorum=(議決に必要な)定足数。majority=多数派。arbitration=調停。   

これで、クラスタ環境がHyper-V上に構築できた。実際に試してみる方法はコチラ

| | コメント (0) | トラックバック (0)

PC1台でクラスタ(MSFC)を試すメモ

PC1台でクラスタ(MSFC)を試す方法メモ。あくまで機能を試すための方法なので、性能面から考えて実運用では使えないだろう。

(2012/1/21追記:1年ほど前までは下記の記事通りだったが、現在はWindows Server 2008 R2だけでできるようになった。詳しくはコチラ

"Windows Storage Server 2008 R2"(Windows Server 2008 R2ではない)というNAS用OSがある。これに"iSCSI Software Target 3.3"をオプションで付けると、iSCSI共有ディスクにできる。つまり共有ディスクというハードウェアを購入しなくても、普通のPCをクラスタ用共有ディスクとして使用できるのだ。

Windows Storage Server (略してWSS)とは。
NAS(Network Attached Storage)用OS。たとえばLogitecは WSS 2008 R2 ベース(WorkgroupEdition)のNAS製品をリリースしている。Windows Storage Server 2008までは単体のOSとして提供されていたようだが、Windows Storage Server 2008 R2 は、Windows Server 2008 R2の更新モジュールとして提供されており、Windows Server 2008 R2 をインストールしてから、その更新モジュールをインストールすることで作成できる。

iSCSI Software Targetとは。   
Windows Storage Server 2008 R2 のオプション。iSCSIではサーバーをTarget、クライアントをイニシエーターと呼んでいる。イニシエーターは、最近のOSなら標準で入っている。実際にインストールしてみたところ、   
・Windows Storage Server 2008 R2 インストール後、OSのバージョン表記が変わった。それ以外は何が変わったのかわからない
・iSCSI Software Targetは、管理コンソールで簡単に設定できた(Targetの定義、仮想ディスクの定義 、接続を許可するイニシエーターの定義(IQNでなくIPアドレスで指定するのが一番楽) )

したがって、次の構成で、クラスタ(MSFC)の試験環境が構築可能。   

  1. Windows Storage Server 2008 R2 with iSCSI Software Target 3.3 (兼ドメインコントローラー)
  2. Windows Server 2008 R2 Enterprise Edition (ノード1)
  3. Windows Server 2008 R2 Enterprise Edition (ノード2)

これら3台のハードウェアが無い場合は、1台だけ(HDD120GB以上、メモリ3GB以上あればイケる)を用意して、Windows Server 2008 R2 (仮想OSのライセンスの関係からEnterpriseEditionが望ましい)に Hyper-V 2.0 の役割をインストールし、上記1~3をHyper-V上の仮想OSとしてインストールすればOK。(ただし、Hyper-Vのライブマイグレーションを試すには、物理的にハードウェアを分けないといけないので、その場合はPCが3台以上必要。)

ちなみにWindows7用のWindows Virtual PCは、64ビットOSをゲストとしてインストールできないため、(Windows Server 2008 R2を使った)利用不可。

PC1台でクラスタ(MSFC)環境をインストールする手順はコチラ

| | コメント (1) | トラックバック (0)

Hyper-VでP2V

PCのHDDにインストールされている既存のOS環境を、そのままHyper-V上の仮想環境に変換する方法がある。P2V(Physical to Virtual)だ。

http://www.microsoft.com/japan/powerpro/TF/column/do_01_1.mspx
P2V(Phisycal to Virtual)

Disk2Vhd というフリーのツールで、物理OSのディスク内容を、そのままvhdファイルに変換できる。 これを使ってvhdファイルを生成して、それをHyper-Vの仮想マシンに割り当てるのだが、 そのままだと仮想OSとして起動できない。

そこで、Disk2Vhdの画面にある"Prepare for use in VirtualPC"にチェックを入れてvhdを生成することで、 HALを一時的にHyper-V対応のものに挿し替えた状態のvhdファイルを生成してくれる。 これで仮想OSとしてvhdから起動できる。

HALについては、次のサイト参照。
http://www.atmarkit.co.jp/fwin2k/win2ktips/010halchk/halchk.html

実際にWindows2003R2の実環境をこれで仮想化したところ、Hyper-V上で起動できた。

しかしHyper-Vの統合サービスをインストールするときに「HALのアップグレードが必要です。」と出て、アップグレード後再起動しても、また同じメッセージが出て、これの繰り返しになってしまい、統合サービスがインストールできなかった。このままだとネットワークアダプタも見えない状態なので使えない。

そこで

C:\boot.ini

を確認したところ

"/HAL="

付きの行が追加されていたので、 それを削除して起動したところ、統合サービスのインストールが続行された。

| | コメント (0) | トラックバック (0)

Hyper-Vのネットワーク

仮想マシンから物理ネットワークに接続できるように、仮想ネットワークの設定を「外部」(既定)にしてあると、そのネットワークを使って、管理OSと外部との通信でNetBTが使えないことがあった。

ただ、「外部」以外にしてから再度「外部」にしたらNetBTが有効になった。
Hyper-Vの問題か?

Hyper-Vが、ネットワーク接続の設定を上書きし、NetBTを「無効」にしていた様子。
管理OSには、NIC2つ以上搭載すべき(MSもそれを推奨している)。もっとも、仮想OSをホストするマシンは大きなスペックを必要とするのでそれぐらい問題にならないのかもしれないが。

Hyper-Vでは、管理OS側に、物理ネットワークアダプタの他に、仮想のネットワーク接続アダプタが作られ、これが、仮想のスイッチとして動作し、各仮想OS上の仮想ネットワークアダプタと通信する。
この仮想スイッチはVLANにも対応しており、VLAN IDを各仮想ネットワークアダプタに設定すると、仮想スイッチがVLANタグをつけてくれる。
(それで、外部の物理スイッチとの間で、VLANのルーティングを行えるのだと思われる。)
それで、管理OS側の物理ネットワーク接続が、仮想スイッチの1ポートみたいに扱われているので、物理ネットワーク接続の設定が(外部設定の場合に)勝手に上書きされるのだろう。

| | コメント (0) | トラックバック (0)

« 2011年4月 | トップページ | 2011年7月 »