2016-04-14

Apcupsd を使用して LAN 上の複数のサーバを自動シャットダウンする

 1台のAPC社製 UPS を複数サーバで使用する場合、停電時にこれらのサーバ群を自動的かつ安全にシャットダウンしてくれる  Apcupsd というUPS 監視デーモンがフリーウェアとして配布されています。大分前に小社でこのソフトを評価したときには、当時の新しい Smart UPS に対応していなかったのですが、現在はほとんどのAPC製UPS に対応しています。本稿では備忘録を兼ねその使用方法を解説します。

※ 仮想マシンの自動シャットダウンについては、本稿末尾の「仮想マシンの自動シャットダウンについて」をご参照ください。

Apcupsd による APC Smart UPS 監視モデル


 下図のようにサーバ Aサーバ Bサーバ C という 3 台の Windows サーバ機が UPS に接続されているとします。
Apc Smart UPS 1500 へのケーブル接続例

 上図のように、複数のサーバが UPS から電力供給され(黒い矢印)、サーバ A がUSB ケーブルでUPSに接されています(青い矢印)。各サーバは同一のネットワーク上にあります(緑色の線)。
 このような状況で Apcupsd を使用すると、サーバAにUPSを監視させておき、停電などの電力遮断時に他のサーバを安全にシャットダウンさせることがことができます。以下がその構成イメージです。

Apcupsd による UPS 監視構成例

ここでは、サーバAがマスタ(Master)機になります。サーバAはUSB 信号を受け取りのために、USB ドライバのインストールも必要になります。サーバ B、およびサーバ C にも Apcupsd をインストールし、サーバ A からシャットダウン命令を受け取るためのスレーブ(Slave)設定を行います。


停電発生時のサーバシャットダウンシナリオ
  1. 停電発生時は、サーバA が USB 経由で停電状態を受信します(青い矢印)。
  2. サーバ B およびサーバ C が LAN 経由で サーバ A から停電状態を受信します(緑色の線)。
  3. 所定の時間内にサーバ Bおよびサーバ C の自動シャットダウンを実行後、サーバ A の自動シャットダウンを行います。これですべてのサーバがシャットダウンします。

 このシナリオを成功させるためには、事前に以下のことを考慮します。

考慮しておくべきこと
  1. すべてのサーバがシャットダウンするまでの所要時間はどれくらいになるか

    シャットダウン時間がかかりすぎる場合は、サーバが完全にシャットダウンする前に電力を使い切る恐れがあります。この場合はサーバが強制(異常)終了してしまいますので、バッテリー残量があるうちにすべてのサーバが完全にシャットダウンされるように計画します。

    ※ UPS の電源コードを抜き、バッテリー消費モードにしてから、シャットダウンの所要時間をそれぞれのサーバで計測し、すべてのサーバをシャットダウンさせてもバッテリーが残っていることを確認します。
    ※ UPS に接続された物理サーバで仮想マシンを運用している場合は、本稿末尾の「仮想マシンの自動シャットダウンについて」をご参照ください。
  2. シャットダウンの順番を計画する

    サーバプログラムの依存関係を調べ、バッテリー容量に余裕がある場合は、被依存のサーバは依存するサーバより後にシャットダウンするように計画します。

    ※ 今回の例では、スレーブとなるサーバ B およびサーバ C をシャットダウンさせた後で、サーバ A をシャットダウンするように計画します。


マスタとなるサーバ機に Apcupsd と USB ドライバをインストールする


 UPS 監視マスタとなるサーバ A に Apcupsd をインストールします。
 Apcupsd は以下のサイトよりダウンロードできます。ここでは WINDOWS BINARY (3.14.13) をダウンロードします。

 apcupsd サイト


 Apcupsd インストールの際は、すべての項目にチェックをつけておきます。


 
 途中、以下のような警告が表示されることがあります。これは、USB ドライバーの自動インストールができなかった場合に表示されるメッセージです。
 この後、手動インストール手順をご紹介しますので、ここでは“OK”ボタンをクリックして次へ進みます。



 さらにインストールが進むと、以下のようなメッセージが表示されます。設定ファイルを今編集するかどうかを尋ねているものです。


チェックをつけたままにして“Next”をクリックすると、以下のような設定ファイルが表示されます。



 APC Smart UPS に USB 接続しているのであれば特に編集する必要はありませんが、上記の conf をスクロールダウンし、 「UPSCABLE」に「usb」が指定されていれることを念のため確認します。

※このボックスのチェックを外すと、設定ファイルが開かないままインストールが進みますが、設定ファイル(apcupsd.conf)はこの後でも変更することができます。


 Apcupsd の起動オプションを選択します。ここでは両方の項目にチェックをつけた状態で“Next”をクリックします。



 インストールが成功すると、以下のメッセージが表示されます。このサービスはサーバ起動時に自動的に開始されます。


 
 システムトレイに監視アイコンを常駐させるか尋ねるダイアログが表示されますので、チェックをつけたまま“Next”ボタンをクリックします。



 Apcupsd のインストールができました。


USBドライバのインストール


 Apcupsd インストール直後のシステムトレイアイコンはこのような状態になっています。


 これは、UPS との接続が確立できていない COMMLOST 状態を示します。
 先ほどのインストールで USB ドライバのインストールに失敗したのが原因です。この場合は、手動でインストールします。

 コントロールパネルからデバイスマネージャーを開きます。
 バッテリーのセクションに、「American Power Conversion USB UPS」 という表記をみつけ、その項目を右クリックして「ドライバー ソフトウェアの更新(P)...を選択します」。



 ドライバの検索方法が表示されますので、「コンピュータを参照してドライバー ソフトウェアを検索します(R)」をクリックします。


 USB ドライバの場所を指定します。
 Apcupsd のインストール先直下の driver フォルダを指定します。



 “次へ”をクリックすると、USB ドライバがインストールされます。


 コントロールパネルより、サービスを開きます。
 Apcupsd UPS Minotor サービスを再起動します。



 アイコンが以下のように変化したら成功です。これは接続中の CONNECT 状態を示しています。

 アイコンを右クリックすると、サブメニューが開きますので、その中から「Status」を選択します。


 
 マスタサーバの UPS 監視ステータスが表示されますので、[Status] が 「ONLINE」 になっていること、[CABLE] が 「USB Cable」 になっていること、[UPSMODE]が 「Stand Alone」 になっていることなどを確認してください。



スレーブとなるサーバ機に Apcupsd をインストールする


 サーバ B、およびサーバ C にも Apcupsd をインストールします。
 インストール方法はマスタサーバと同様ですが、USB 接続はしないため、[USB ドライバ]のチェックは解除してください。



 Apcupsd インストール直後のシステムトレイアイコンはこのような状態になっています。


 これは、サーバ A との接続が確立できていない 「COMMLOST」 状態を示します。
 ここで、Apcupsd の設定ファイル apcupsd\etc\apcupsd.conf を開きます





  以下の項目を修正します。


UPSCABLE ether


UPSTYPE net
DEVICE 192.168.0.100:3551    ← サーバ A の IP アドレス、ポート番号に 3351 を指定


 ここまで設定したら、設定ファイルを保存して閉じます。


 コントロールパネルより、サービスを開きます。
 「Apcupsd UPS Minotor」 サービスを再起動します。



 アイコンが以下のように変化したら成功です。これは接続中の 「CONNECT」 状態を示しています。

 アイコンを右クリックすると、サブメニューが開きますので、その中から「Status」を選択します。


 
 スレーブサーバの UPS 監視ステータスが表示されますので、[Status] が 「ONLINE SLAVE」 になっていること、[CABLE] が 「Ethernet Link」 になっていることなどを確認してください。
 これは、マスタサーバの UPS 監視状態をスレーブサーバで取得していることを意味します。



スレーブサーバのシャットダウン待ち時間を指定する


 インストール作業が終わったら、スレーブサーバ(サーバ B および サーバ C )のシャットダウン待ち時間を指定します。

 これは、マスタ(サーバ A) 側で、停電状態が検知されてから、スレーブ側でシャットダウンを開始するまでの待ち時間となります。

 設定ファイル(apcupsd\etc\apcupsd.conf )を開き、TIMEOUT セクションの数値を変更します。
 デフォルトは 0 (シャットダウンしない)になっています。



 待ち時間は秒単位で指定します。
上図では 2 分を示す 120 が指定されています。5 分なら 300 のように指定しますが、あまり長すぎるとそれだけ停電時のバッテリーを消耗し、シャットダウン処理が完了する前にバッテリを使い切り異常終了してしまう可能性があるので、本稼働前に計画・テストするようにします。

 設定が終わったら、ファイルを保存します。
 その後、「Apcupsd UPS Minotor」 サービスを再起動すると、設定が有効になります。

マスタサーバのシャットダウン待ち時間を指定する


 これは、マスタ(サーバ A) 側の待ち時間設定もスレーブの場合と同様です。ただし、スレーブがシャットダウンを開始するのを確認した後でマスタサーバのシャットダウンが始まるようにしますので、スレーブの待ち時間よりも長めに設定しておきます。

 この待ち時間設定は、先述の「考慮しておくべきこと」セクションの内容を考慮したうえで行うようにします。


 設定が終わったら、ファイルを保存します。
 その後、「Apcupsd UPS Minotor 」サービスを再起動すると、設定が有効になります。


停電発生時のサーバシャットダウンのシミュレーションを行う


 ここでは、停電が発生したときのシミュレーションを行います。
 手順は以下のとおりです。

  1. それぞれのサーバの UPS 接続状態が ONLINE 状態になっていることを確認してから、UPS の電源コードを抜きます。UPS がバッテリーモードに切り替わり、アラート音が鳴り始めます。

  2. スレーブサーバ(サーバ B およびサーバ C)の待ち時間終了と同時に、スレーブサーバのシャットダウンが開始することを確認します。

  3. マスタサーバ(サーバ A)の待ち時間終了と同時に、マスタサーバのシャットダウンが開始することを確認します。

  4.  すべてのサーバが完全にシャットダウンするまで待ちます。バッテリーが十分余っていれば成功です。

  テストが終わったら UPS の電源コードを忘れずにコンセントに挿しましょうね><
 


尚、停電復旧後はサーバ機を起動する必要がありますが、無人のサーバセンターや夜間などスタッフが不在の場合に備え、WakeOnLAN (WOL)も検討しておくとよいでしょう(参考記事)。



仮想マシンの自動シャットダウンについて


 UPSに接続されたサーバがHyper-V等で仮想マシンをホストしている場合、そのホスト機がシャットダウンする際の仮想マシンの扱いに気をつける必要があります。

 仮想マシンの停止アクションは仮想マシンの設定画面で指定できます。



 自動停止アクションには 3 つのオプションが用意されています。
  1. 仮想マシンの状態を保存する(S) --- 稼働中の仮想マシンの状態を一時保存(起動ボタンを押すと稼働状態が復元される)

  2. 仮想マシンを停止する(T) --- 強制終了させる

  3. ゲストオペレーティングシステムをシャットダウンする(D) --- 仮想マシンをシャットダウンする

 通常はUPS の蓄電量に応じて、「仮想マシンの状態を保存する(S)」または「ゲストオペレーティングシステムをシャットダウンする(D)」を選択します。UPSの蓄電量が少なく、できるだけ早くシャットダウンする場合は前者を選択します。蓄電量が多く余裕をもってシャットダウンできるのであれば後者を選択したほうがいいかもしれませんが、 シャットダウン中に電池切れにならないように計画してください。

 すべての仮想マシンの自動停止アクションの設定が終わったら、ホストサーバのシャットダウン時を実行し、完全にシャットダウンして電源が切れるまでの時間を測定し、これを参考に Apcupsd のシャットダウン待ち時間(TIMEOUT)を算出してください。

仮想マシンの自動起動について


 ホストサーバ起動時に仮想マシンを自動起動するかどうかを決めます。仮想マシンの開始アクションは仮想マシンの設定画面で指定できます。



 自動開始アクションには 3 つのオプションが用意されています。
  1. 何もしない(N) --- アクションなし。仮想マシンが落ちていれば落ちたまま。
  2. 仮サービスが停止したときに実行されていた場合は自動的に起動する(U) --- 前回サーバがシャットダウンしたときに仮想マシンが稼働していた場合は稼働状態が復元される
  3. 常にこの仮想マシンを自動的に起動する(W--- 仮想マシンが停止していた場合にも自動的に起動する
CPU の性能とメモリ割り当てを考慮して、自動開始アクションを設定するとよいでしょう。




参考情報


Apcupsd User Manual --- Apcupsd のユーザマニュアル(英語)

Network UPS Tools --- いろんなネットワーク UPS ツールの情報サイト(英語)


(亀)


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-15

マルチ認証ライセンスキーを使って Windows OS エディションをアップグレードする方法

 Windows OS のエディションをアップグレードしようとするとき、DISM コマンドを使うこともあると思いますが、マルチ認証ライセンスのプロダクトキー(MAK キー)で同操作を行うと失敗します。

 ここでは、アップグレードの失敗例をご紹介したあとで、その理由と、対処方法についてご紹介します。

 なお、本記事では Windows Server 2008 R2 を使っていますが、Windows Vista、 Windows 7、Windows 8/8.1、Windows Server 2008、Windows Server 2012/R2、Windows 10 のエディションアップグレード作業時にも参考にしていただけるとのではないかと思います。

注意点:

 本記事でご紹介する操作は、動作を保証するものではありません。
 事前にアップグレード要件の検討を行い、必要に応じてバックアップをお取りいただき、お客様の責任で操作をお願いいたします。


絵で見る失敗例:マルチ認証ライセンスのプロダクトキーを使うと、Windows OS エディションのアップグレードができない


 コマンド プロンプトから 以下のコマンドを入力し、現在のエディションを確認します。
 
DISM /online /Get-CurrentEdition


 上図では、ServerStandard という文字列が返りますので、Standard であることがわかります。
 (実際に使用しているのは Windows Server 2008 R2 Standard エディションです。)

 次に、アップグレード可能なエディションの種類を確認します。

 以下のコマンドを入力ます。
 
DISM /online /Get-TargetEditions



 ServerDataCenter および ServerEnterprise にアップグレード可能なことがわかります。
 ここで、Enterprise にアップグレードする場合は、以下のようにコマンドを入力します。

 
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX



 しかしながら、ご覧のようにエラー 1605 とともに、「指定したプロダクト キーは、このターゲット エディションに対して有効なキーではありません。このターゲット エディション固有のプロダクト キーを指定して、このコマンドをもう一度実行してください。」というメッセージが表示されて失敗します。


原因:マルチ認証ライセンスのプロダクトキー(MAK キー)は、DISM コマンドには使えない


 MAK キーそのものは複数のエディションに対して共通のプロダクトキーとなっていますが、DISM コマンドは各エディションに固有のキーを要求するため、共通キーの MAK キーが使えません。

 これを回避するには、キー管理サービス(KMS)用のクライアントセットアップキーを使えば、一旦アップグレード操作は成功するようになります。

 KMS クライアントセットアップキーはこちらのページから入手できます。

 付録 A:KMS クライアント セットアップ キー

 一覧より、アップグレード対象のエディションのキーをコピーしておきます。
 お手持ちのマルチ認証ライセンスのプロダクトキーも後で必要になりますので保存しておきます。

KMS クライアントセットアップキーを使った Windows エディションのアップグレード


 コマンドラインより、DISM のアップグレードコマンドを入力し、/ProduktKey スイッチに KMS クライアントセットアップキーを入力します。

 
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX




 指定したエディションと、KMS クライアントセットアップキー が一致すると、プロダクトキーのインストールが行われます。

 その後、10分~程度待ち状態になります。
 既存のパッケージが削除された後に新しいパッケージが適用されます。
 下図は、Windows Server 2008 R2 Standard Edition が削除された後で、Enterprise Edition が適用された様子です。



 すべての操作が終わると、「今すぐコンピューターを再起動しますか(Y/N)?」というプロンプトが出ますので、Y を選択すると、即座にサーバが再起動されます。

 ※作業中のドキュメント等が開いている場合は、事前に保存しておくことを忘れないようにしましょう。

 起動後は、おなじみのアップグレード画面が表示されますので、完了するまで待ちます。



 アップグレードが完了したら、ログインして、コンピュータのプロパティでエディションを確認しましょう。
 下図では、Windows Server 2008 R2 Enterprise エディションにアップグレードされていますね。

 

 エディションが変わるため、Windows ライセンスの認証は解除された状態となりますので、別途認証作業が必要となります。

 「プロダクトキー の変更」リンクをクリックします。



 プロダクトキー入力ダイアログが表示されますので、お手持ちのマルチ認証ライセンスのプロダクトキー(MAK キー)を入力します。



 ライセンスが認証されたら、一連の操作は成功です。



 MAK キーを使うと、どうやってもエディションのアップグレードに失敗してしまう場合は参考にしていただければ幸いです。


参考リンク:
Features missing or incorrect memory reported after using dism /set-edition to upgrade computer (英語)
(dism /set-edition コマンドでコンピュータをアップグレードしようとすると、機能不足やメモリ割当が不正などのエラーが報告される)

KMS Client Setup Keys (英語)





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で乗り切る


2015-06-25

新WebDirectのパフォーマンスについてあれこれ

 FileMaker 13 の WebDirect (以下、WebDirect 13) と比べ、FileMaker 14 の WebDirect (以下、WebDirect 14) のパフォーマンスはどれだけ向上したのか?実用に耐えるレベルになったのか?
 WebDirect 14 の導入を検討するにあたり、これはとっても気になるところです。

 FileMaker 社の公式サイトでは、WebDirect の起動スピードは以前より 25% 向上していると謳ってはいます。また、独自にパフォーマンスの比較検証を行って公開している方(会社)もおいでで、そうした情報はとっても貴重です。

 ということで、パフォーマンスについて情報を公開している方の情報を例によって渉猟してみました。 (あと、人様の情報を紹介させて頂くだけでは申し訳ないので、弊社でも WebDirect のパフォーマンスの検証をしてみました。)


米国 FileMaker 社(パートナー)が公開している YouTube ビデオ


 かの有名な  Richard Carlton Consulting Inc. の FileMaker Training Videos Channel という動画です。

 WebDirect関連のビデオでは 「第一部:FileMaker WebDirect 14 のご紹介」、「第二部:WebDirect の最適化方」の 2 本が公開されていますが、その中からパフォーマンスに関する情報を拾って要約しました。

「第一部:FileMaker WebDirect 14 のご紹介」 Introduction to FileMaker WebDirect 14


 WebDirect がモバイル対応になったことを中心に、パフォーマンス面も向上していることについて触れています。

パフォーマンスに関する重要ポイント(リンクはタイムスタンプ):
  1. 11:30 今回のリリースで WebDirect の全面書き換えが行われたことにより、実行速度が格段に向上している。
  2. 13:40 WebDirect 14 によるレコード移動時の表示速度デモ
  3. 15:13 WebDirect 13 vs WebDirect 14 レコード移動速度比較
  4. 16:54 WebDirect 14 のタブキー操作によるレイアウトフィールド移動は、WebDirect 13 に比べると 2倍は速くなっている
  5. 20:02 デスクトップ版 WebDirect 14 は、 WebDiredt 13 に比べると 2-3 倍動作が速い。Android モバイルに至っては 10-20 倍速くなっている!(WD13はAndroidには正規対応していないのですが、Richardさんは独自の方法でチェックされたようです。但し、この部分は動画にはありません。)。
  6. 27:28 WebDirect は ChromeBook の動作保障をしていないが、自己検証ではサクサク動いた。

(動画は英語)
 

 特に 15:13 あたりの WebDirect 13 vs WebDirect 14 レコード移動速度比較実験は必見!
 ウィンドウを左右に並べて比較しているので、速度が向上していることは一目瞭然にわかります。

「第二部:WebDirect の最適化」 Optimaizing Solutions for FileMaker WebDirect 14 


 2013年の Richard Carlton Consulting Inc. の FileMaker 13 WebDirect Overview and Optimization Presentation と基本的な流れは同じですが、 WebDirect 14 に関する情報にも触れられています。

パフォーマンスに関する重要ポイント(リンクはタイムスタンプ):
  1. 17:55 *.fp7 ファイルを  FileMaker Pro 14 フォーマット(*.fmp12) に変換した直後のレイアウトサイズは 850kb。
    これを予め登録した共有スタイルで最適化させると 425kb までサイズダウン。
    サイズが約半分ということは、転送速度が約2倍になっているといえる。
  2. 18:49 FileMaker Pro 14 に付属のストーンテーマのスタイルを極力いじらずに同様のレイアウトを作成した場合は、225kb までスリム化できた。
  3. 19:55 WebDirect 13 で共有スタイルで最適化したレイアウトサイズは 480kb だったが、 WebDirect 14 で同様の作業を行うと 425kb で、 約15% スリム化されていることがわかった。

(動画は英語)

  今回は WebDirect のパフォーマンス比較がわかるところのみを中心にご紹介していますが、ビデオの中では以下のようなことにも触れています。

WebDirect 13 の最適化ビデオと重なる情報は省いてあります。より詳しい情報をご覧になりたい方は、FileMaker 13 WebDirect Overview and Optimization (英語)をご覧いただくか、弊社記事 WebDirect 開発の勘どころ をご覧ください。

画像について 


 jpeg, png などの画像利用は最小限にする。
 FileMaker Pro 14 には軽量の SVG ビルトイン画像(glyph)が用意されているので、これを使ってボタンアイコンを装飾することを検討。
 ※SVG = スケーラブル・ベクター・グラフィックス

タブ・スライドコントロールについて


 タブ、スライドコントロールの使用もできるだけ避ける。
 必要のない情報をロードさせないのが基本。
 タブコントロールを配置するれば、裏でタブ上のすべての情報がロードされることに注意。

ポップオーバーについて


 FMP13 で導入されたポップオーバーも要注意。
 ブラウザに別ウィンドウを表示させる代わりに使えるが、多用は避けること。
 裏であらかじめすべてのポップオーバーデータをロードすることには変わりはない。

スクリプトトリガについて


 WebDirect 側にはスクリプトエンジンが搭載されていない。
 このため、イベントが発生するたびに FileMaker Server にアクセスして処理を決定する。
 当然、スクリプトをトリガさせるイベントがたびたび発生すれば、その分のトラフィックが増加する。
 このトラフィックコストはできるだけ少なくした方がよい。

FileMaker WebDirect 14 のパフォーマンス最適化については、「FileMaker 14 WebDirect ガイド」の 14 ページ「ステップ 3: パフォーマンスの最適化」(PDF)にヒントが掲載されています。こちらも併せて読むと、参考になると思います。




土屋企画による WebDirect パフォーマンス検証

 

 小社でも『FMEasy在庫 IWP/WD R1.5』 という製品を使い、社外と社内の2つのサーバでテストをしていました。

■実行環境
社外:米国某ホスティングサービス(VM/共用タイプ)、16 GB RAM/Xeon E5 4 cores
社内:自社サーバ(VM/占有タイプ)、4GB RAM/core i7(4プロセッサ割り当て)
FileMaker Server: Ver14.0.2(サーバ1/サーバ2共に)
使用ブラウザ:主としてIE10、IE11
注:VM=仮想マシン

■テスト内容
 予め、連続ビュー、連続更新、出庫伝連続伝票作成、という3つのループスクリプト(後述)作っておき、5~10個のブラウザウインドウからこれらのスクリプトを実行しています。
 で、こんな感じになります。


 上図は、1台のPC上で10個のIE10ブラウザウインドウを開き、ループスクリプトを実行していますが、Remote Desktop (RDT)で複数のセッションを開き、それぞれのセッションで1~複数のブラウザウインドウを開いてループスクリプトを実行というテストも行っています。
 後述の「■テスト」の項では、<社内/1PC/複数ブラウザ>、<社外/複数RDT/1ブラウザ>などと表記しますが、前者は社内サーバに1台のPCから複数のブラウザウインドウを起動しアクセス・テスト、後者は社外サーバに複数のRemote Desk Top から1つのブラウザウインドウを起動してアクセス・テスト、を表しています。

■ループスクリプトの内容
1. 連続ビュー
上図の出庫画面で先頭レコードから1件づつ後方へ移動していく。移動直後に0.2~1秒ポーズし、50~100件目に到達したらメッセージを出して終了する。

2.連続更新
上記の連続ビューと基本は同じだが、移動直後に備考フィールドに実行時の日時を追記する。

3.連続伝票作成(クライアントサイド)
出庫伝票形式のデータを連続して100件作る。といっても、1出庫レコードには25の出庫明細レコードが付属しているので、このスクリプトを1回実行すると、出庫レコード100件+出庫明細レコード2500(25明細×100)件、計2600のレコードが作成される。

4.連続伝票作成(サーバサイド)
仕様は上記4同じだが、サーバサイドスクリプトで実行。

■テスト
1.連続ビュー <社外/1PC/複数ブラウザ>
10個のIE10ブラウザウインドウで連続ビューを実行し、すべてのブラウザでエラーなく成功。


以下の動画は、撮影の都合上、6つのブラウザで実行しています。


2.連続更新
2-1  連続更新 <社外/1PC/複数ブラウザ>
10個のIE10ブラウザウインドウで連続更新を実行し、全てで成功。但し、上記1よりは時間がかかる。

2-2 連続更新による影響  <社外/複数RDT/1ブラウザ>
6つのRDTで1つのブラウザを起動し、それぞれで連続更新スクリプトを実行させた後、ローカルでブラウザを起動し、テスト実行者が手動によりレコード移動や入力を行いました。 これは、他のユーザが入力作業をしていると、どのような影響を受けるかシミュレートしたものです。結果は以下の通りです。
  • 6つのRDTの連続更新は時間はかかるもの成功します。
  • ローカルのブラウザでは入力は成功するものの 、レコード移動ボタン(>アイコン)を数回クリックすると、サークルアイコンが現れ操作ができなくなる現象が頻発します。数分待つと画面が表示されますが、これでは実用に耐えないレベルです。 


2-3 連続更新による影響  <社内/複数RDT/1ブラウザ >
上述の2-2 と同様テスト内容を 社内サーバで実行したときの模様です。

  • 今回は、ローカルで新規レコード入力操作中にサークルアイコンが現れ、その後 15 分経過しても状況が変わらなかったため、テストを中断しました。
  • このサークルアイコンが現われ操作不能になる現象は今回のループテスト実行中に何回も発生しました。 サーバ性能を上げるとこの現象は緩和されるのかもしれませんが、性能を上げたとしても FileMaker Pro 並みの安定運用を行うのは厳しいのではないかと思われます。 

2-4 連続更新を24セッションで実行 <社内/複数RDT/複数ブラウザ >
4つの RDTクライアントでそれぞれ5つのIE10ブラウザウインドウを開き、さらにローカルで4つのIEブラウザウインドウを開いて(計24セッション=4×5+4)て連続更新スクリプトを実行。成功したのは24セッション中9、残りの15セッションはサークルアイコンが出現し制御不能に。

3.連続伝票作成(クライアントサイド)  <社外/1PC/1ブラウザ>
1つのIE10ブラウザウインドウで成功。所要時間は43秒。但し、再度実行すると、ブラウザが反応しなくなる(下図)。



4. .連続伝票作成(サーバサイド) <社外/1PC/1or 5ブラウザ>
1つのIE10ブラウザウインドウで数秒で成功。但し、実行直後から全くブラウザが反応(上図と同様)しなくなることがある
バグを修正したところ、上記打消し線部の問題は解消。 5つのブラウザウインドウ上で本スクリプトを同時実行したところ正常終了。さらに、続けて5つのブラウザで同スクリプトを実行したところ、こちらも問題なく終了。
※バッチ処理は実行速度と安定性から、利用可能であればサーバサイドスクリプトを利用するのが良い


※ 今回のテストを通じて思ったこと ― WebDirect導入時の注意点

  1. 複数のブラウザでループスクリプトを実行しても(動作は遅くても)比較的に安定して動作する。
  2. ユーザが < や > (レコード間移動)ボタンを手動で実行すると、サークルアイコンが延々と表示され、場合によっては操作不能になことがある。 < や > を連続押しすると、この現象は高い頻度で発生する。
  3. レコードの連続作成スクリプトをクライアントサイドで実行すると、そのスクリプトは正常に終了したにも関わらず、次の操作が不能になる(サークルアイコンが出っ放し状態)になることがある。
  4. サーバサイドスクリプトが実行できる状況であれば、使う
上述のように上記のテストは海外のサーバを使用して行っていることにご注意ください。上記2の現象に関し、WinMTR の結果をホスティング会社に送付し問い合せたところ、「some severe packet loss and latency from you location in Japan to our location」とのことでした。 ただ、サークルアイコン出っ放し状態の時でも、FileMaker Pro によりサーバにアクセスして < あるい > をクリックすると、速度は遅いものの正常に動作すること、社内サーバを使用してもサーバへの負荷を高めるとサークルアイコン出っぱなし現象が発生することからみて、WebDirect にはまだ問題があると思います。
 尚、小社のLAN内のWebDirect環境では、ブラウザの > または <  ボタンを連続押ししても、上記の問題は発生していません。  

 以上のことから、WebDirect の導入に際しては、サーバ性能(メモリ/CPU)に加え、ネットワーク環境にも十分注意を払う必要があります。実際の運用環境にできるだけ近い環境を用意し、事前に十分なテストを行うことも必要でしょう。 またテストを行う際も精度の高いプロトタイプを用意し、十分な実行速度が確保できるかもチェックしたいところです。ブラウザ上の < と > (ナビボタン)を非表示にしたり、短い間隔で連続実行できないようにするなどの工夫も必要かもしれません。 導入担当者または開発者は、サークルアイコンの地雷を踏まぬよう、十分注意しましょう。

注:
「社内サーバのスペックが低すぎるのがサークルアイコンの原因だろ?」とお思いの各位、御尤もです。メモリたっぷりなサーバを調達してテストしてみたいです。 ただ、サーバ性能が低いにしても、サークルアイコン出っぱなしはオカシイと思います。



WebDirect のパフォーマンスに関するその他の情報


 バージョン間での WebDirect パフォーマンス比較を実際に行っている開発者は残念ながらまだ少ないようです(公式サイトの 25% 速度アップについて言及していらっしゃる方は多いでのですが)。

 そんな中、米国の FileMaker Forum ではいくつかのスレッドで WebDirect のパフォーマンスに関する情報がみつかりました。
 リンク先は英語ですが、スレッドの紹介程度に要約を載せておきます。

1. FileMaker Server 14 & WebDirect Performance


 NickLightbody という方が WebDirect 1ユーザあたりの消費メモリを計測して表にされています。
 こちらのスレッドでは、3 WebDirect ユーザ の場合は 100MB の RAM を消費し、 30 ユーザでは 1 GB の RAM を消費することを挙げたうえで、独自の計測結果も公開されているのでとても参考になります。 すばらしい! \(^o^)/

2. FMS 14 WebDirect Performance?


 WebDirect 14にアクセスしたところ、ロード中のアイコンが出っぱなしになり、10~20 秒後にログイン画面に戻ってしまうという現象が発生。

 ちなみに、当方でも同じ現象に遭遇したことがあります。
 ホスティング会社にこの件について問い合わせたところ、FileMaker Server 13 から発生している既知の現象で、この現象が発生した場合は、FileMaker Server を再起動しないとどうにもならないとのことでした。
 また、この現象はいまのところ FileMaker Server 14 でも発生しているので、今後のアップデートが望まれるところです。 早く出さんかいヽ(`Д´)ノ


(亀)