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






(亀)