ラベル Hyper-V の投稿を表示しています。 すべての投稿を表示
ラベル Hyper-V の投稿を表示しています。 すべての投稿を表示

2017-09-07

太古の FileMaker システムを延命させる! ― 後日談


 今年の4月に FileMaker Pro 5.5 を運用する Windows Server 2008 (32bit版、Remote Desktop Serviceを運用)をP2Vにより仮想マシン化するプロジェクトに関する記事を書きました。
 あれから4カ月、先月末、ようやく納品が終わりました。いろいろあってとっても苦労しました、トホホ… 以下、古いFileMakerシステムを仮想マシン化して Hypervisor 上で運用したい、という方の参考に多少ともなれば幸いです。

1. FileMaker Pro 5.5/6を仮想マシン上で運用する

今回、特に問題となったのは、仮想マシン上のFileMaker Pro 5.5/6(FMP)からFMSにアクセスしたときの操作が極端に遅くなること。今回、新マシン(下図のVM)と旧マシン(下図Win Server 2008)上の FMP から FileMaker Server 5.5(FMS)上の郵便番号.fp5(レコード12万件)に対しソートを実行し、この実行時間を遅速判断の1つの基準としました。




 12万件ソートの時間計測は、異なる5つのHypervisor機(Dell PowerEdge 2台、HP Proliant 1台、Lenovo X 2台)上に仮想マシンを作成し、様々なチューニングを試しながら繰り返し行いましたが、最速で20秒、最遅では2分強と、サーバ個体やNICの設定により結果が大きく異なったのには閉口しました。

 では、仮想マシン上の Remote Desktop Service に FMP を乗せ、FMSにアクセスするシナリオで、旧マシンに比べ仮想マシンが遅い場合の対処方法を小社の今回の経験からご紹介します。

※一つずつ試してください。
  1. 物理NICが Broadcom NetXtreme Gigabit Ethernet の場合、NICの詳細設定で Virtutal Machine Queues を Disable にするとともに、Hyper-V Manager の仮想マシンの「ネットワークアダプター」で「仮想マシンキューを有効にする」のチェックを解除。
  2. NICの詳細設定で、「TCP/UDP Checksum Offload (IPv4)」と、「TCP/UDP Checksum Offload (IPv6)」を Disable にする。
  3. Hyper-V Manager で、(普通のネットワークアダプターではなく)レガシネットワークアダプターを構成する。
  4. ネットでHyper-Vのチューニング情報を漁って試す(例:Performance Tuning for Hyper-V Servers)。
  5. そもそもロジックボード設計が Hyper-V に適していない→マシンを変える
 小社の今回の経験では、上記3が有力と思います。5の状況にならないようにするには、導入前にベンダーのSEに聞いてみるか、導入実績のあるサーバを導入するか、試用機を借りて事前テストする、位でしょうか。


2. FileMaker Server 5.5 を仮想マシン上で運用する

これについては、レガシネットワークアダプターよりも、普通のネットワークアダプタの方が有利(速い)というテスト結果です。

 同じ仮想マシンであるにもかかわらず、サーバとして利用するのと、クライアントで利用するのとで、採用すべき仮想NICの構成が異なるというのは不思議です。


■ FileMaker 5/6等レガシーシステム関連記事

太古の FileMaker システムを延命させる! ― 後日談FileMaker(17/09/07投稿)
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる!(17/04/25投稿)
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う(16/05/25投稿)
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
 

今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。

土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。


(土屋)

2017-04-25

太古の FileMaker システムを延命させる!

 小社では 「売上猫くん 4.0」という自社製パッケージ製品(一部改変)をもう20年程、社内の見積・売上・請求管理システムとして使用しています。 「売上猫くん」は初期には FileMaker 3/4 により開発されたものです。 この太古のシステムは現在、  仮想マシン(Windows Server 2008)上のFileMaker Server 5.5 で公開され、Windows 10 を含む最新のWindows 機上のFileMaker Pro 5.5/6 から毎日アクセスされて使用されています。
 小社同様、FileMaker 5.x/6.0 でシステムを運用している企業・組織は一定数あり、当方の客先にも何社かはそのようなところがあります。
 このような FileMaker のレガシーシステムを運用する場合、まずネックとなるのがハードウェアの老巧化や故障によるリプレイスです。 本稿では「FileMaker レガシーシステムの仮想化による延命方法」を小社の客先である某社を例にご紹介します。

1. 某社の状況

1998年: 某社より生産・購買・販売・在庫管理システムの開発業務を受注。FileMaker 4 により開発を開始。数ヶ月後に首尾よくリリースに漕ぎ着ける。某社本社の Macintosh 上に FileMaker Server 5.5 を配置し、NTTの専用線  Digital Access による WAN を介して複数拠点で運用を開始。

2001年: FileMaker 5.5 へアップグレード。fmj から  fp5 へのファイル構造の変換が伴うアップグレードにも関わらず、難なく終了。 この際、サーバを Windows Server 2000 に変更。

2008年*1: Windows Terminal Service (後のRemote Desktop Service)を導入し、FileMaker Pro 5.5 をインストール。拠点のユーザはこのサーバ上の FileMaker クライアントを実行することにより、アプリの実行速度を改善。この際、FileMaker Serverを運用するサーバ機も Windows Server 2008 に変更(参考記事)。さらに、ネットワークの高速化とコスト低減を目的に Digital Access から インターネットVPN へ変更。  インターネットVPNへの変更に伴うセキュリティ上のリスクへの備えとして、SonicWALL による IPS 、Gateway Antiviurs 等も併せて導入。

導入以来、数多の仕様変更を繰り返しながら、現在もFileMaker 5.5 の環境で運用中。

*1
2008年当時、小社内で Windows Server 2008 と FileMaker Server 5.5 の組み合わせによる運用実績はあったのですが、このようなレガシーシステムの運用はベンダーによる動作保証の対象外となることを事前に客先に十分説明しなければなりません。 レガシーシステムの延命は客先のリスクに関する理解と許容が重要だと思います。

2. さらなる延命へ

2008年に導入した RDSサーバですが、経年劣化によるリプレイスを検討するように、客先に数年前からお願いしていたところ、先ごろ、ようやくリプレイス案を出すように求められました。 ただ、運用実績のある Windows Server 2008 は既に発売中止になっていました。そこで以下のような図と共に提案書を客先に提出しました。

仮想環境はWindows Server 2012/2016 Standard 付属のHyper-V(ゲストOSが2ライセンス付属)

A案は単純リプレイス型ですが、新サーバを導入し、そこに現行のOS(Windows Server 2008)をインストールし、RDTアカウントやFileMakerが動作する環境を新たに構築し直す、というものです。 問題となるのは、前述のように Windows Server 2008 に公式対応するサーバ機が2017年現在ほとんど存在しないので、それを覚悟の上での実装となります(参考:Microsoft社のサポート期限一覧)。

B案は現行サーバを P2V (Physical to Virutal)し、これを Hyper-V 2.0 で運用するというものです。これが上手くいくと 旧サーバのハードディスク情報をそのまま仮想マシン化でき、OSやアカウント情報の再構築・再設定が不要になるので、大変便利です。 半面、まったく異なるハードウェア環境へ移動することになるので、各種ドライバでエラーが発生したり、悪くすると初回起動時にブルースクリーンが表示されたりします。 安定運用期に入るまで気をぬけません。

C案は 新規にWindowsサーバを導入、ゲストOS も新たに作成し、その上にRDTアカウント等の再度設定しなおすものです。ゲストOS上での作業はほとんどA案と同様になります。P2Vに比べハードウェアの差異によるエラーやブルースクリーンやらの可能性はほぼなくなりますが、すべて一からの作業となります。

 提案書と概算見積をご提示した後に打ち合わせをしました。結果、サーバ故障時やリプレイス時に仮想マシンであれば迅速に復旧可能であることも勘案し、Windows Server 2016 を使用したB案で進行することになりました。ただ前述のように P2Vが失敗するリスクがあることをご説明し、B案不首尾の場合は、A案、C案、さらには Windows Server 2016 の 2012 へのダウングレード(D案*2) もバックアップとしてご提示しました。

*2
D案の提案理由は  SATO のあるラベルプリンタが Windows Server 2012 へは公式対応している一方、Windows 2016 に非対応であることによります。重要な周辺機器との互換性もレガシーシステムの延命を行うときには“要注意”となります。

3. テスト環境での実装

新しいサーバ機の納品までしばらく時間があるため、客先の旧サーバを予め P2V してVHD(X)にし、当方の Windows Server 2016 の Hyper-V に入れ、事前にテストを行いました。仮想マシンを起動するとエラーイベントが複数発生していたので、一つ一つ潰していきました。 次に FileMaker Pro 5.5 (以下、FM5.5)を起動してテストを実施。 下図のようにクライアントPCから仮想サーバにRD接続。 FM5.5 を使用し FileMaker Server 5.5 (以下、FMS)上の12万件のデータが入った郵便番号ファイルを開き、ソートを実行・・・ 「ん? 」、なんかかなり遅い感じ。

確認のため、仮想サーバではなく、別の物理マシンのRDS から郵便番号ファイルにアクセス(クライアントPC→物理マシンRDS+FMP→FMS)すると、なんと3倍!速い。 クライアントPC→Win Server 2016 RDS+FMP→FMSで実行してもやはり3倍速い。

 ならば、仮想サーバ上に郵便番号.fp5 を配置して、ネットワークを介さずローカルで実行するとどうか? 一瞬 = 数秒~10秒程度!で終了してしまいます。 ということで、仮想サーバの通信速度(上図の「FMP⇔FMS接続」)に問題があることが判りました。 実はここからがすごく大変で、 「Hyper-V ゲストOS 遅い」や「Hyper-V Guest OS slow」などをキーワードに、数日間、ググって試す、ググって試すを繰り返しました。 ググってまず最初に出てくるのが、NICの仮想マシンキュー(VMQ、Virtual Machine Queue)を オフ にせよ、というもの。これは内外のいろいろなところで書かれており、小社の別のHyper-V環境下のゲストOSでは劇的な効果があったのですが、今回の仮想マシンについては全く効果無しでした。 NICの「IPV4チェックサムオフロード」をオフにしろ、という記事も多く見かけましたがこれもダメ。
NICの設定は、ホスト側からだけではなく、仮想マシンからもいじってみましたがうまくいかず。
万策尽きたか、と思ったところで、突然光明が差しました。 それは、「レガシーネットワークアダプタ」の使用(下図)。



 仮想マシンのネットワークアダプタを作成する際、「ハードウェアの追加」を選択。この時、通常は「ネットワークアダプタ」が推奨されますが、ここで「レガシ ネットワーク アダプター」を図のように選んで“追加”します。 これを行うことにより、

ping -l 60000 hostname

の応答時間も劇的に改善し、12万件の郵便番号ソートも劇的に速くなりました。

 今回のゲストOSは Windows Server 2008 で、このOSは Hyper-V の「統合サービス」に対応しているので、上図では「ネットワーク アダプター」を選択するのがセオリーだと思うのですが、、、
ネットで調べてもレガシはオバーヘッドが多いので、「ネットワークアダプター」を使いなさいという記事しか見当たらりませんでしたが、レガシーのままテストを続行することにしました。

尚、上記の記事に関する後日談はこちらをご覧ください。


土屋企画では、FileMaker レガシーシステムの延命、拡張、仮想マシンへの移行に関するご相談を請け賜わっております。ご希望の方はこちらからお問い合わせください。



(土屋)


追記
「売上猫くん3.0」は1997年に FileMaker Pro 3 により開発されたものですが、 いまだにご愛用頂いているお客様がいらっしゃいます。 ただ、ハードウェアの老巧化の問題があるのでできる限り新バージョンへのアップグレードをお勧めしてます。 それはそれとして、 FileMaker Pro 3/4 のシステムを Windows NT 4.0 の仮想マシンで運用するというのは、実際やったことはありませんが、チャレンジしてみたい気もします。



■ FileMaker 5/6等レガシーシステム関連記事
下記記事のレガシー延命スキームの実施と結果について。

Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。
 
今なお輝くFileMaker 5.5/6(16/05/23投稿)
レガシーFileMaker の意外な利点。




参考リンク:
今なお輝くFileMaker 5.5/6
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Performance Tuning for Hyper-V Servers
Hyper-V network adapter differences
Windows Server 2012 Hyper-V の SR-IOV 構築手順 (1)

2016-05-13

仮想マシン復旧メモ ― 次にやらかしたときのために

またやらかしてしまった...orz
最近退役したQNAPのiSCSI上にある仮想マシンに故あってアクセスしようとしたところアクセスできず、ping は返れどもブラウザからアクセスできない状態。 そこで、QNAP本体の正面にあるボタン(SELECT ― ENTER)を何気に数回押したところ、RAIDを再構成してしまった模様 ヽ(`Д´)ノ 
何たる不覚...

 ということで、バックアップから他のHypervisor上に回復することに。この機会(=やらかした機会)に回復時のオプションを確認してみることにした。 以下、そのメモです。

Windows Server バックアップを進めると、以下の画面が表示される。



ここで、上図のように[Hyper-V]を選択して“次へ”をクリックすると、下図となる。



すべての仮想マシンを回復するには[Hyper-V]を選択すればいいのだが、特定の仮想マシンのみを復旧しようとすると、ご覧のごとくトホホな状態。回復が完了すると、回復先のフォルダの名称も同じくトホホな名称となるが、このトホホフォルダ内のVHD名(が適切に指定されていれば)からマシン名が特定できる。

ただ、そんなことをやっている暇はないので、「回復種類の選択」画面(冒頭の図)に戻り、[ボリューム]を選択し、“次へ”を押すと下図となる。



ご覧のように、オリジナルのボリュームに1対1で対応するように回復先のボリュームを用意しなければならない。 今回は、一つのボリュームに仮想マシンのC/E/Fドライブをまとめてしまうつもりなので、このオプションは見送る。

注:このオプションは、回復先のボリュームを初期化してしまうので、要注意。


で、結局、冒頭の画面に戻り、[ファイルおよびフォルダー]を選択し、“次へ”を押すと以下の画面。




仮想マシンを選んで、“回復”。 
元の仮想マシンはC/E/Fに分かれているのだが、このウィザードでは1回に1つのボリュームしか復旧できない(1つのボリューム内であれば、複数のファイル/フォルダ選択可)。


以下、回復操作を3回繰り返し、目的の仮想マシンのC/E/Fを回復、他のHypervisor上で仮想マシンを再構築し、無事起動することができた。

また、無駄な仕事をしてまった (ノД`)ハァ


(土屋)

参考サイト:
Windows Server 2012 R2 Hyper-V バックアップ/リストア設計・導入・運用ガイド

富士通の技術ドキュメントは何気に凄い。いつもお世話になってますm(,_,)m 

2016-01-20

御三家による Hyper-V 講習リスト

まとめてみました。

 到達目標NEC富士通CTC
1Hyper-V のインストールMU032/MU05C/MU89A OT024/P720/P674
2仮想ハードディスクの構成MU032/MU05C/MU89AUCV32LP720/P674
3仮想ネットワークの構成MU032/MU05C/MU89AUCV32LP720/P674/EL080
4仮想サーバ環境の構築と運用MU032UCV32LOT024/P720/P674
5仮想マシンの作成MU032/MU05C/MU53B/MU89AUSK81L/UCV32LP720/P674/EL080
6仮想マシンの設定MU032/MU05C/MU53B/MU89AUSK81L/UCV32LP720/P674
7エクスポートとインポートMU032/MU05C/MU53B/MU89AUCV32L/USK81LP720/P674
8Hyper-V の管理MU032/MU05C/MU53B/MU89AUCV32LOT024/P720/P674
9Hyper-Vの設定MU032/MU05C/MU53B/MU89AUCV32LP720/P674
10高可用システムの構成MU032 P720/P674
11フェールオーバークラスタMU032/MU05C/MU53B/MU89AUCV32L/USK81LP720/P674/EL080
12クイックマイグレーションMU032/MU05C  
13ライブマイグレーションの有効化MU032/MU05CUSK81L 
14Hyper-Vレプリカ USK81LP720/P674
15ライブマイグレーション委任設定MU032/MU05C/MU53B P720
16SCVMMのインストールと構成MU53B/MU89A P720/P673
17SCVMMによるネットワークと記憶域の管理MU89A P720/P673
18SCVMMによる仮想マシンの作成と管理MU53B/MU89A P720/P673
19SCVMMのインストールライブラリの構成と管理MU53B/MU89A P720/P673
20SCVMMクラウドの管理MU89A P720/P673
21SCVMM および App Controller によるサービスの管理MU89A P720/P673

(亀)

2015-12-11

iSCSI を利用したFileMaker Server の冗長構成を考える

 先日の記事で、FileMaker Server 14 オリジナルのスタンバイサーバ機能のテスト環境構築方法についてご紹介しましたが、このスタンバイサーバ機能には、以下のような問題点があります。

  1. プライマリからスタンバイサーバへの切り替えはコマンドライン入力が必要で面倒で、誤操作が発生する可能性がある
  2. 前回保存以降(0~99分間)のデータが失われる

 そこで今回は、上記のスタンバイサーバ機能の代わりに、プライマリ/スタンバイサーバでiSCSIディスクを共有するように設定し、障害時にはサーバ切替を行う冗長構成を考えてみました。

尚、本稿でもプライマリサーバの代替機という意味でスタンバイサーバという言葉を使用しています。 前稿のFileMaker Server 14 オリジナルのスタンバイサーバ機能と混乱しないようにご注意ください。


注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 実運用前に社内で入念な動作検証を行い、お客様の責任で導入をお願いします。


 前回構築した仮想マシン二台を流用した iSCSI ドライブ共有モデルがこちらになります。
iSCSI ドライブの共有によるデータベース公開モデル
平常時はスタンバイサーバはiSCSIドライブには接続せず、プライマリサーバがダウンした時にのみ接続する
iSCSI ターゲットに配置されたデータベースファイルを FileMaker Server で公開することによって、緊急時にはスタンバイサーバから同じデータベースファイルにアクセスできるようにします。
 ※スタンバイサーバ側は、初回導入時にプライマリサーバと同様に iSCSI ドライブ内のデータベースを公開できるように設定します。設定後に iSCSI ドライブを切断するため、上図では接続状態を黄色の矢印で示してあります。

プライマリサーバの設定:

 iSCSIターゲット上でデータベース専用ドライブを作成し、プライマリサーバ上にマウントします(下図のEドライブ)。

 このとき、FileMaker Server 14 アプリケーションはCドライブにインストールし、データベースファイルはすべて iSCSI ドライブ(Eドライブ)に配置します。

 たとえば、下図のように iSCSI ドライブを E: ドライブとしてマウント。その中に FmData フォルダを作成して、この中に FileMaker データベースファイル群を配置します。



次に FileMaker Server Admin Console を使用し、上記で作成したデータフォルダが公開されるようにそのフォルダのパスを指定します。

 下図では、filewin:/E:/FmData/ が公開されるように設定しています。
 また、データベースファイル破損時に備えて、バックアップはローカルディスク上に取っておきます。




スタンバイサーバーの設定:

 プライマリサーバで iSCSI を切断し、FileMaker Server を停止させます。
 プライマリサーバの設定内容と同様にスタンバイサーバの設定を行います。

 ※ プライマリサーバの FileMaker Server の動作競合や、iSCSI ディスクへの書き込みエラーを防止するために、スタンバイサーバの設定が終わったら FileMaker Server を停止させて iSCSI 接続を切断しておきます。
 iSCSI の切断後は、スタンバイサーバをシャットダウンします。

正常時の操作


 普段はプライマリサーバのみ稼働させておきます。

プライマリサーバ稼働時の iSCSI 接続状態


緊急時の操作


 プライマリサーバのメンテナンスが必要になったり、プライマリサーバに障害が発生したりした場合は、FileMaker Server を停止させて iSCSI ドライブへの接続を切断します。

 そして、スタンバイサーバから iSCSI ドライブへ接続後に、FileMaker Server を起動します。

スタンバイサーバ稼働時の iSCSI 接続状態

ポイント:
 ― FileMaker Server 14 のサーバ切替コマンド操作が不要な分、サーバのダウンタイムは短縮できますが、プライマリサーバの iSCSI 切断、スタンバイサーバの iSCSI 接続と FileMaker Server 起動までの操作は手動作業になります。

 ― スタンバイサーバはプライマリで運用していたファイルを直接引き続くため復旧時にデータロスは発生しませんが、iSCSIターゲット(ディバイス)の堅牢性が要求されます。RAID6やRAID10などの採用を検討してください。

 ― FileMaker Server 14 以前の FileMaker Server にも応用できます。


とっても重要:

 フルバックアップ及びプログレッシブバックアップにより作成されるバックアップファイルは iSCSI ディスク上ではなく、ローカルディスク及び外部メディアに取ることをおすすめします。

 これにより、iSCSI ターゲット自体が故障した場合に、ローカルディスクにあるバックアップから復旧作業を行えます。
 また、ローカルディスクも同時に損傷しまった場合にも、外部メディアから復旧する手段が残ることになります。






(亀)



2015-12-09

Hyper-V VMを使用しFileMakerスタンバイサーバーのテスト環境を構築する


 FileMaker Server 14 でスタンバイサーバーが導入されたことにより、システムメンテナンス時や障害時にもすみやかに FileMaker データベース作業を再開できるようになりました。


 スタンバイサーバー - 概要


 プログレッシブバックアップを利用した現用系(プライマリ)と予備系(スタンバイ)のサーバ切替が可能になった分、突然のデータロスの可能性を低減できることは大きいと思います。

 しかしながら、切替制御が自動でないため、人為作業がどうしても発生してしまう点や、緊急時に FileMaker Server 管理者が対応不能の場合に作業が一時中断してしまう点などの問題は残りますので、緊急時の作業規則をあらかじめ社内で決めておくことが大切です。

 今回は、Windows OS で FileMaker Server 14 のスタンバイサーバー機能の動作検証を行いたい方のために、スタンバイサーバーのテスト環境を Hyper-V の仮想マシンを使って手っ取り早く構築する方法をご紹介します。

Hyper-V 上の仮想マシン(VM)のイメージ ― 1台のホストOS上で複数のVMを運用する

準備するもの

1. Hyper-V サービスがインストールされたコンピュータ 1 台
 今回は Windows Server 12 を使用しています。

2. FileMaker Server 14 が動作する Windows Server ライセンス 2 つ
 今回は Windows Server 2008 R2 を使用しています。

3. FileMaker Server 14 ライセンス 1 つ
 スタンバイサーバーを構成する場合、必要な FileMaker Server 14 のライセンスは1つのみです。

Hyper-V 環境の構築方法


1. 一台めの仮想マシンを作成してから仮想ハードディスクを接続します。
 その後、Windows Server OS と FileMaker Server 14 をインストールし、必要なデータベースファイルを Data/Databases ディレクトリの中に入れておきます。

新規仮想マシンと Windows Server OS および FileMaker Server 14 のインストール

ポイント:
 ― Windows Server の IP アドレスを正しく設定し、Windows 認証を済ませておきます。
 ― FileMaker Server 14 をインストールしたら、すぐにプログレッシブバックアップ設定をしておきます。



 このとき、プログレッシブバックアップ先のパス名の指定を忘れないようにしてください。
 上図では便宜的に filewin:/C/FMSProgBkup/ を指定してあります。

2. 一台めの仮想マシンをシャットダウンします。
そして、仮想マシンから仮想ハードディスクを削除(切断)します。

仮想マシンから仮想ハードディスクを切り離す

3. 仮想ハードディスク1 (VHD1) を複製して仮想ハードディスク2(VHD2=スタンバイサーバー用VHD)を作成します。
 Windows Server OS と FileMaker Server 14 がインストールされた状態の仮想ハードディスクを複製するため、インストール作業の二度手間を大幅に省くことができます

仮想ハードディスクを複製する

4. 一台めの仮想マシンに仮想ハードディスク1(VHD1)を再接続し、無事に起動してきたら、二台めの仮想マシンを新規作成し、仮想ハードディスク2(VHD2)を接続し、同様に起動します。

仮想マシンを新規作成して、二台の仮想マシンを稼働させる
ポイント:
 ― Active Directory に参加しているサーバを複製した場合は、二台めのサーバはドメインに参加できなくなります。
 このため、一旦ローカルログインし、IP アドレスの変更、コンピュータ名の変更、ワークグループへの切り替えを行ったあとで仮想マシンを再起動し、再度 ActiveDirectory に参加するようにする必要があります。

参考記事:ドメインにログインできなくなって泣かされる

 ― Windows OS は新たに仮想ハードディスクを接続すると、Windows 認証作業が必要になります。
  ボリュームライセンス利用者の場合は、「自動ライセンス認証が始まるまで XX 日です。今すぐ行う場合はここをクリックしてください」をクリックし、指示どおりに操作します。



 シングルライセンス利用者の場合は、「プロダクトキーの変更」をクリックして、二台めの Windows ライセンスを入力します。

 ― FileMaker Server 14 のプログレッシブバックアップの設定はプライマリサーバと共通になるので作業は不要です。FileMaker Server に付ける名前だけ変更すれば OK です。

FileMaker Server 14 スタンバイサーバーの設定方法


1. プライマリサーバの公開済データベースを全部閉じます。



 コマンドプロンプトから以下のコマンドを入力します。

fmsadmin standby connect スタンバイサーバーの名前または IP アドレス

 接続およびログインに成功すると、8桁のセットアップコードが表示され、待ち状態となります。
 このセットアップコードをメモしておきます。


2. スタンバイサーバー側でコマンドプロンプトを開き、以下のようにセットアップコードを入力します。

fmsadmin standby accept XXXXXXXX

ログイン成功後、スタンバイサーバー切替のメッセージが出るので y を選択後、ログインします。

3. プライマリサーバに戻り、待ち状態のコマンドプロンプトで Enter キーを押すとスタンバイサーバーへの接続が完了します。

ポイント:
 ― スタンバイサーバーでセットアップコードを入力して受理されたものの、セットアップコードが不正だった場合は Enter キーを押すとエラー終了になります。この場合は、手順 1. のコマンド入力からやり直してください。


4. プライマリサーバのコマンドプロンプトで、以下のコマンドを入力します。

fmsadmin standby update

 ログイン成功後、プライマリサーバのデータベースがスタンバイサーバーの公開データベース環境にコピーされます。


5. プライマリサーバのデータベースを再度公開します。


 すると、プライマリサーバとスタンバイサーバーのデータベース同期が行われるようになります。
 このとき、スタンバイサーバーの FileMaker Server Admin Console を開こうとすると、以下のように待機状態であることが確認できます。



 スタンバイサーバーのさらに詳しい設定方法および、スタンバイサーバーの動作確認方法(メンテナンス時、障害発生時のサーバ切替)は、FileMaker 社の公式動画がおすすめですので、ご覧になってみてください。



おまけ: FileMaker Server 14 プライマリサーバとスタンバイサーバの同期関係を解除する方法


 これまで、FileMaker Server 14 でプライマリサーバとスタンバイサーバーで同期が取れるように設定しましたが、逆に同期を解除したいという要望も出てくることでしょう。

 そのようなときは、プライマリサーバ側でコマンドプロンプトより以下のように切断コマンドを入力します。


fmsadmin standby disconnect

 本当にスタンバイサーバーを切断してよいかと聞いてきますので、y を選択し、ログインすると、スタンバイサーバーとの接続が切断されます。

 これにより、今までスタンバイサーバーだった FileMaker Server 14 はスタンドアロンサーバとして動作するようになります。

以上

(亀)

FileMaker バックアップ関連記事:

データベースのバックアップ方法
FileMaker Server のプログレッシブバックアップ機能の考え方と使い方


Hyper-V 関連記事:

Hyper-V の仮想マシンの移行方法(エクスポート&インポート)
Hyper-V の仮想マシンのエクスポート時の注意点
物理マシンを Hyper-V 仮想マシンに移行する(P2V)
Hyper-V のゲスト OS を起動しようとすると、「一般のアクセスが拒否されました」というメッセージが表示される
計画停電対策(1) --- ノートPCサーバとHyper-Vで乗り切る


2012-03-21

Hyper-V のゲスト OS の BIOS 不良で泣かされる

Hyper-V てはゲスト OS を複数運用できるため、今となっては弊社の業務に欠かせない存在ですが、当方のブログでもたびたび記事を書いているとおり、過去にも色々とトラブルに泣かされていることも確かです。

 さて、今回も月曜日の朝からゲスト OS が起動して来ないというトラブルに見舞われました。
 Hyper-V マネージャ画面を見ると、「仮想マシンの構成記憶域に接続できません」というエラーメッセージが表示されています。しかも状況は「重大」のようです。



 試しに起動してみると、以下のようなエラーメッセージが返されました。



 
 ゲスト OS の設定を確認してみると、BIOS の読み込みに失敗したとあります。
 BIOS 設定に何らかの障害が発生し、起動不能になった模様です。



 ネットを調べ回ったところ、仮想マシンを削除(仮想ディスクはそのまま残すこと)し、再度追加することで解決するとあったので試したところ、復活しました。

 ただし、システムの状態によっては Windows ライセンス認証がもう一度必要になったり、IP アドレス設定が丸々飛んだりしたりするので、その辺の微調整は必要になるかもしれません。

 ただ、今回のように突然ゲスト OS が起動しなくなる可能性がありますので、同じように BIOS による起動トラブルが発生した場合は、今回の方法をダメ元で試してみるのも一つの方法かもしれません(ただし、自己責任ということでお願いします)

2011-06-01

Hyper-V のゲスト OS からサウンドを出す方法(裏技的な使い方)

 Hyper-V のゲスト OS は、サーバ機能に特化した機能以外はほとんど使えないようになっているようです。
 USB ポートやサウンドカード等のサポートがこれに該当するため、Hyper-V のゲスト OS にはサウンドボードのエミュレータは組み込まれていません。

 32-bit のサポートを謳っていない Skype や AIM などの通信アプリケーションでは、64-bit であるホストでは正常に動作しないため、32-bit のゲスト OS 環境にそれらをインストールして使用する必要があります。

 しかし、上記の説明どおりゲスト OS からはサウンドを出すことができないため、リモートデスクトップを使うことによってこれを解決できます。

 リモートデスクトップ接続ウィンドウから“オプション”ボタンをクリックし、「ローカルリソース」タブの「リモートオーディオ」というセクションから“設定(S)...”というボタンをクリックすると、以下のようなダイアログが表示されます。



 上図のように設定して“OK”を選択してからゲスト OS にリモートデスクトップ接続を行い、接続先のゲスト OS で正しくサウンドデバイスを設定すると、サウンドが有効になります。

 今まで Hyper-V ゲスト OS からサウンドデバイスが有効にならないため諦めていた方は、駄目元で試してみると良いでしょう。


参考:Sound Card Emulation in Hyper-V?(英文)
http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/a060720c-833e-4855-921b-6d5c79dc98d9/