PowerShell DSC Configuration設計に関して
PowerShell DSCに関して、まだまだ情報は少ないのが現状。
サンプルとかに関してはちらほらネット上にあるのだが、
より実用的な、大規模な設定を投入することになると、サンプルのようにはいかなくなる。
以下、より実用的なConfigurationを作成するにあたり参考にしたサイトが以下。
■巨大なDSC Configurationの考え方
ParameterとRoleの活用に関しての記載がある
Designing Node Configurations in PowerShell DSC - Nicholas Dille
■DSCにおける、設定とConfigurationの分離
複数のConfigurationに分割しての実装方法に関して
■Nested Configuration の問題点
ネスト構造のConfigurationに関しての問題点に関して記載している。
自分は、ネスト構造を採用しているけど。
Reusing #PSDSC Node Configuration with Nested Configurations - the Horror! - Nicholas Dille
ちなみに、DSCはまとまった情報得るのが難しいのが現状かと思うが、
書籍としては下記が非常に良かった。
下手に情報をパラパラとネットで集めるよりは、この本をベースに始めるのがいいかと思う。
こっちの本も、まだ購入していないけど気になる。
VMWare ESXiのインストールおよびアップグレードのベスト プラクティス
システムを設計するうえで、利用する製品の機能・仕様を理解するのは非常に大事です。
特に、製品ベンダーの公式の資料というのが何よりも大切な指針となります。
（当然、ソースレベルで使用を確認できる唯一の組織になりますからね）
VMWareのESXi製品は、毎回バージョン毎に「インストールおよびアップグレードのベストプラクティス」が
KB Blogに公開されています。
それぞれ、ESXi 5.1, 5.5, 6.0のページが公開されています。
各ページともに下記内容で構成されています。
■システム要件
ESXiが既定しているHW要件に関しての記載があります。
特にESXiで肝になるのは、CPU、NIC、メモリサイズとかでしょうか。
CPUは、HW仮想化のサポートの有無(Intel VT)、
NICはサポートしているNICでないとドライバが対応していない等があります。
おすすめはIntel製のNICですね。迷ったらIntel、それでなくてもIntelが基本です。
メモリに関しても、最低要件が定められており、ESXi5.5ですと4GBです。
加えて、サポート対象としているSATAコントローラも記載があるのですね。
■起動要件
ここはUEFIの話とかです。
■ストレージ要件
ESXiのインストールに必要な容量としては1GBが必要です。
加えて、5.2GB以上のディスクがないとスクラッチ領域がRAM上に置かれるようです。
つまり、再起動するとデータが消えるということです。
当然、推奨はされていません。
※スクラッチ領域とは、ESXiのログ、システムスワップ含むデータを保持する領域です。
インストール後に、スクラッチ領域を別途指定可能です。
USB,SDカードにインストールする場合も、8GB未満ですとスクラッチ領域を作成しないようです。
8GBのUSBにESXiをインストールしている方は要注意です。
■ESXi ホストのアップグレードまたは移行のベストプラクティス
文字通りですが、エンタープライズ向けですとアップグレードまたは移行を考えることもあるかと思います。
その際のベストプラクティスがまとめられています。
ところで、エンタープライズでESXiのアップグレードってそんなに需要あるんですかね。
移行はともかく。
HP Lights-Out スタンド アロン リモート コンソール for Windows
サーバ機器にはリモートからコンソール接続できる機能が搭載されていることが多いです。
これは、トラブルのたびにデータセンターへダッシュして、コンソールを開いて作業することにならないためにも非常に大事です。
HP製のサーバにはiLoというリモートコンソールの機能が搭載されていますが、
多くの方がブラウザ経由でアクセスして、利用しているかと思います。
自分がよくであう状況としては、ブラウザのバージョンが低くてうまく画面を取得できない、
Javaがインストールされていない（Java版のリモートコンソールの場合）などなど、
意外とうまく動いてくれないことがありました。
トラブルの時くらいしか利用しないため普段はまったく意識しません。
が、いざトラブル時に利用できないと焦るのです。。
そこで、タイトルの件になるのですが、
ブラウザを利用しなくてもよい、スタンドアロンのソフトウエアがあるようです。
初めて知りましたが、これならメンテナンス用の端末にインストールしておけば確実ですね。
※メンテナンス用の端末のブラウザを保全しておけよという意見もまぁあるのですが。
Drivers & Software - HP Support Center.
また、HPさんはiOS,Android版のコンソールアプリもリリースしているみたいです。
HP iLO Mobile - Google Play の Android アプリ
以下、参考サイト。
あまり知られていない HP iLO リモートコンソールの 5 つの Tips - 仮想化でプリセールスしてるSEの一日
Windows Server 2012 OS標準NICチーミングに挙動に関して
サーバ構築する際には、NIC障害に備えて、複数NICを搭載してチーミングをしているかと思います。
従来、Windowsでサーバ構築をする際のNICチーミングには、NICベンダのドライバを利用してチーミングを構成していたかと思います。
ですが、Windows Server 2012以降は、OS標準機能としてNICチーミングの機能を提供しています。
OSレイヤーでチーミングが可能ですので、別ベンダーのNICでも事実上チーム構成が可能です。
※あえて、そのような構成を選択する人はいないかと思いますが。
当時、OS標準のNICチーミングでアクティブ・スタンバイ構成を利用した際に、随分とフェイルバックが遅いなと感じていました。
以下のような流れで挙動を検証をしたのですが、
NIC1:アクティブ
NIC2:スタンバイ
2.内、NIC1のイーサネットケーブルを抜栓する。
ここは瞬時にスタンバイに切り替わる。
NIC1:エラー "メディアが切断されています"
NIC2:アクティブ
3.抜栓したイーサネットケーブルを結線する。
NIC1:エラー "接続の保留中"
NIC2:アクティブ
4.一定時間経過後、NIC1がアクティブに復帰
NIC1:アクティブ
NIC2:スタンバイ
3から4への遷移に結構な時間がかかっていました。
"接続の保留中"という文言から何か待っているのかなと思っていましたが、
MSのNetworkチームBlogにその件の記載がありました。
結論から言うと、30秒待ってから、アクティブに復帰するそうです。
これは、リンクの安定性を確かめるために30秒まつようにしているようです。
尚、下記Blogによると、この30秒を変更する方法はなく、OSの仕様として決まっているようです。
Microsoft User Experience Virtualization(UE-V)概要
【概要】
Microsoft User Experience Virtualization(UE-V)に関して概要を。
このような製品があることを最近知ったので、ひとまず、簡単な調査をした程度。
今後、もう少し検証していきたい。
2012年ころに、MSがリリースした製品。
UE-Vは、Windows上でのユーザ設定を一元管理する機能を提供する。
つまり何よというと、ユーザがWindows端末にログオンして行った設定情報を
管理サーバに保存しておき、別端末にログインしてもその情報が提供されるというもの。
TecNetからの文言を拾うと、以下の設定が同期されるとある。
・ユーザアプリケーション
・Windows設定
・App-Vでシーケンス処理されたアプリケーション
・RemoteAppアプリケーション
参考：
User Experience Virtualization 1.0 の概要
となると、頭に浮かんでくるのは「移動プロファイル」である。
おおよそ機能としてはかぶっているように見える。
※ここに関しては調査中。
【アーキテクチャ概要】
自身のコンピュータに、UE-V Agentというモジュールが稼働する。
UE-V設定場所のテンプレートに従って、アプリケーションとOSを監視する。
（設定場所のテンプレートとは、UE-Vで管理対象としているアプリなどの記載がある設定ファイル)
該当のアプリケーション等が起動すると、設定が設定PKGからダウンロードされて適用される。
終了時は、更新分がアップロードされる。
設定の保存場所はActiveDirectoryのホームディレクトリ
共有フォルダへ保存できるとのこと。
また、移動プロファイルと違い、「上書き問題」は発生しないように制御されるとのこと。
（どのように制御されるかまでは、調べられてないので検証した際にでも）
ESXi仮想ディスク(シンプロビジョニングディスクの圧縮)
シンプロビジョニングのディスクの圧縮をしたくなったので、ESXiのディスク周りに関して
調べた内容を記載しておく。
まず、ESXiの仮想ディスクには下記種類がある。
自宅では容量の効率的な利用のためにシンプロを採用している。
開発環境など、性能が不要なシーンではこのような方式が多いのではないかな。
本番環境とかだと、シックが多いかなと思う。
■シンプロビジョニング
シンディスクは、構築時は最大どこまで拡張できるかを指定してディスクを作成するが、
実際に利用している分しかサイズを使わない。必要に応じで拡張されていく。
ちなみにOSとしては、構築時に指定した最大サイズ分が利用可能と見える状態になる。
例として、シンディスク300GBの仮想マシンを作成した場合。
OSをインストールした直後、15GB利用していたとすると、シンディスク（VMDKファイル)の
実際のサイズも15GB程度となる。しかしOSからは300GBのHDDを積んでいるようにみえる。
OSからI/Oが発生しコミットされるまでに、必要となる領域に0を書き込む。(スパースファイル)
このタイミングで、VMDKファイルのサイズが増加される。
一度拡張したVMDKファイルは、減少することはない。
■シックプロビジョニング(Lazy Zeroed)
シックプロビジョニングは、シンプロと違い、あらかじめ指定したサイズを確保する方法。
とはいえ、確保した後の挙動で2種類がある。
VMDKファイルのサイズは仮想ディスクのサイズと同様になる。
ファイル内で初めてI/Oが行われた際に、0が書き込まれる。
（つまり利用されるまで、初期化されない)
■シックプロビジョニング(Eager Zeroed)
もう一つのシック。この方式こそが本当のシックというべきともいわれる。
VMDKファイルのサイズが仮想ディスクのサイズと同様になるのは同じで、
初期の段階で、全ブロックを0で初期化する。
つまり、I/Oのたびに0を書き込む必要がなくなるので、
I/Oレイテンシが若干減るとも言われている。
ちなみにStorage vMotionを利用すれば、上記3種類の形式を変換可能。
■シンプロ ディスクの圧縮
シンプロで一度拡張されたVMDKファイルは自動では縮小されない。
その縮小を実施するには、以下の方法が存在する。
・sdeleteコマンドを利用して、不要な領域を0クリアする。
※ちなみにSdeleteで0クリアするということは、0書き込みをするということなので注意。
VMDKのサイズが大きくなりますよ。
・VMDKの圧縮コマンドを実行する(0クリアされた領域をパージできる)
■SDelete（Windowsならね。Linuxはddとかでできるんじゃないかな。うん）
sdelete.exe -z D:
Sysinternals: SDelete (ja-JP) - TechNet Articles - United States (English) - TechNet Wiki
■VMDK圧縮
vmkfstool -K XXXXX.vmdk
■Tips
■fsutil
指定したサイズのファイルを瞬間的に作成できるコマンド
ちなみに、ちょっと特殊な方法でファイルを作成している。（作成されたと見せかけている）
・NTFS上、領域を確保したとする。
・初期化をしない。ファイルフォーマット上利用しているよとしただけ。
※つまりVMDKのサイズが増えない。
参考文献：マスタリングVMware vSphere 5.5www.amazon.co.jp
2015/11/29 etsubo
WSUSサーバのクリーンアップ
自宅で、WSUSサーバを利用しているがいつのまにかディスク容量が枯渇していた。
当然といえば、当然。ひたすらパッチをダウンロードしているのだから。
※自宅用だからいいけど、本番でこんな運用を間違ってもしないように。
WSUSの不要なパッチを削除するには、
「管理コンソール」＞「オプション」＞「サーバクリーンアップウィザード」
で手動実行ができるわけだが、定期的に実施するのは面倒くさいので、バッチ化する。
（余談だが、自宅はHinemosを利用している)
すでに情報もあり、MicrosoftのScriptCenterで公開されていた。
今回は、このスクリプトをそのまま採用している。
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
# whether or not superseded updates should be declined.
$cleanupScope.DeclineSupersededUpdates = $true
# whether or not expired updates should be declined.
$cleanupScope.DeclineExpiredUpdates = $true
# whether or not obsolete updates should be deleted from the database.
$cleanupScope.CleanupObsoleteUpdates = $true
# whether or not obsolete revisions to updates should be deleted from the database.
$cleanupScope.CompressUpdates = $true
# whether or not obsolete computers should be deleted from the database.
# $cleanupScope.CleanupObsoleteComputers = $true
# whether or not unneeded update files should be deleted.
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope); 各プロパティの内容が何を示しているかは、下記ページを参照した。
おおむね、GUIで実施する際の設定画面の項目に準拠していた。
CleanupScope Properties (Microsoft.UpdateServices.Administration)
で、ここまで実施した後に気づいたのだが、2012R2だとWsus関連のPowerShellコマンドレットが充実していた。
reflection.assemblyで.Netを叩かなくても、PowerShellの世界で完結できていたかもしれない。
Windows Server Update Services (WSUS) Cmdlets
Invoke-WsusServerCleanup
2015/11/23 etsubo
