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






(亀)