2016-04-15

WakeMeOnLan

 遠隔地からネットワーク経由でマシンを起動するWakeOnLAN(WOL) ツールは無償のものが多数出回っていますが、今回はインストール不要で感覚的に操作できる WakeMeOnLan をご紹介します。

WakeMeOnLan ダウンロードサイト ダウンロードリンクはこちら

 ツールは英語表記ですが、日本語ファイル(ダウンロード)を WakeMeOnLan と同じフォルダに入れれば日本語化されるのがいいですね。

 クライアントコンピュータの適当なところにダウンロードして解凍し、WakeMeOnLan.exe を実行するだけの手軽さです(゚∀゚)
 WakeMeOnLan を起動した状態は以下のようになります。


 上図の赤で囲まれたスキャンボタンをクリックすると、同一ネットワーク上のコンピュータがスキャンされます。電源状態が不明なものも、電源が落ちているものもスキャンされます。

 稼働状態はアイコンで示されます。

 赤● --- 電源が落ちている
 黄● --- 電源状態は不明
 緑● --- 稼働中



 リストより、起動したいコンピュータをマウスで右クリックすると、サブメニューが表示されますので、その中から「選択したコンピュータを起動(W)」を選択すると、コンピュータが起動されます。

 但し、コンピュータのネットワークカードが WakeOnLAN(WOL) 対応している必要があり、かつWOLが使用できる状態に設定されている必要があります。


(亀)

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