月別アーカイブ: 12月 2016

標準

投稿者:

投稿日

2016年12月29日

カテゴリー:

Hyper-V, WS2016

コメント

コメントする

S2D (Storage Space Direct) の構成

前回の投稿で記載したとおり、RAIDコントローラー経由でホストOSに接続したハードディスクを S2Dで利用することができません。
サーバーマネージャーからホストOSに接続している物理ディスクを確認した場合、BusType が ”RAID” になっているとクラスターの検証でエラーになります。

１．サーバーマネージャーからローカルディスクの確認

1

2. クラスターの検証

2.png

3. クラスター検証のエラー

3.png

本番環境ではハードウェア構成に不備があることはないと思いますので、検証をしたいけれどハードウェアを準備できないということであれば、下記のコマンドを実行することで S2D を構成できる可能性があるということです。

コマンド： (Get-Cluster).S2DBusTypes=0x100

【参考】 Perc H310 reporting wrong Bustype to Windows Server
http://en.community.dell.com/support-forums/servers/f/906/t/19987807
You can configure the Failover Cluster to ignore the bus type: (Get-Cluster).S2DBusTypes=0x100

今回私が試した環境は下記のとおりです。

サーバー

PowerEdge R630 × 2台

CPU

Intel E5-2660 v3

メモリ

192 GB

ディスク

600GB × 2：RAID1 (ホストOS用)

600GB × 4：非RAIDディスク (S2D用)

RAIDコントローラー

PERC H730P Mini

S2D用のディスクですが、それぞれの4本のディスクをRAID0としても、非RAIDディスクとしても、サーバーマネージャーから見えるディスクのBusTypeはRAIDのまま変わりませんでした。

4.png

デルのサーバーでS2Dを構成する場合は、R730XD で PERC HBA330 の利用が推奨のようです。
Testing Storage Spaces Direct using Dell PowerEdge R730xd

そのため、S2Dを利用する際は適切なハードウェア構成にするように気を付けましょう。

今回は検証用途でS2Dの構成を構成するため、ディスクのBusTypeに対してコマンドを発行してからS2Dを構成する手順を実施しました。

1. S2D の検証項目なしでクラスターの検証を実施し、クラスターを作成

6.png

2. クラスター作成後、下記コマンドを実行
コマンド： (Get-Cluster).S2DBusTypes=0x100

5

3.S2Dに追加するディスクを確認 (ここでもBusType はRAIDのままでした。。)

コマンド： Get-Disk | select Number, FriendlyName, OperationalStatus, Size, PartitionStyle, BusType | sort Number | ft -AutoSize

7

4. 作成したクラスターで、下記コマンドを実行してS2Dの有効化
コマンド： Enable-ClusterS2D

8.png

S2D有効化コマンドの結果がこちらです。クラスターに参加している2ノードのHDDがStorage Space に追加されたことが分かります。今回の構成はSSDなしなので、キャッシュ領域がありません。。

9.png

5．フェールオーバークラスターマネージャーから作成されたストレージプールを確認

10.png

「クラスタープール１」 という記憶域プールが作成され、そのプールに所属している物理ディスクを確認することができました。これで、S2Dの構成が完了しました、無事にできてよかったです。

この作成されたクラスタープールから仮想ディスクを作成し、仮想マシンを配置すればHCI環境 (Hyper Converged Infrastructure) で利用することができます！次回にストレージプールから、仮想ディスクを作成して、CSVへ変換する手順を記載したいと思います。

今のところこの環境でS2Dの動作に関する不具合は起きていないです。もしS2Dで利用する予定のディスクの BusType が RAID として認識されてしまった場合は、こちらの手順でS2Dを構成できるか試してみてください！

標準

投稿者:

投稿日

2016年12月25日

カテゴリー:

WS2016

コメント

コメントする

Storage Space Direct (S2D) とは

Windows Server 2016 に、Storage Space Direct という機能が追加されました。今回は、Storage Space Directの構成についてです。

Storage Space Direct は、フェールオーバークラスターに参加するノードのローカルディスクを1つの共有ボリュームとして構成することを可能にする機能です。 Storage Space Direct を利用することで、共有ストレージを利用することなくフェールオーバークラスターを構成することができるため、Hyper- Converged Hyper-V や Converged Hyper-Vの環境を比較的安価に作成することができます。

【Converged Hyper-V】

converged-minimal

【Hyper Converged Hyper-V】

hyper-converged-minimal

下記がStorage Space Directのハードウェア要件です。

Storage Spaces Direct hardware requirements

  • サーバー
    • 2 から 16ノードまで
  • メモリ
    • 1TBのキャッシュドライブに対して 5GBのメモリ
    • OSやアプリケーション用のメモリは別途必要
  • ドライブ
    • ローカル接続の、SATA, SAS, NVMe
    • それぞれのドライブは1台の物理サーバーのみに接続する
    • ドライブは512n, 512e, ネイティブ4K に対応
    • OSのブート領域とは別ドライブで構成する必要がある
    • MPIO はサポートされない
  • ドライブの最低本数
    • キャッシュ領域用のドライブは1台の物理ホストに2ドライブ以上必要
    • 1台の物理ホストに、キャッシュ領域以外で4ドライブ以上必要
    • 1つのStorage Pool の容量は、1TB以上必要
Drive types present Minimum number required
All NVMe (same model) 4 NVMe
All SSD (same model) 4 SSD
NVMe + SSD 2 NVMe + 4 SSD
NVMe + HDD 2 NVMe + 4 HDD
SSD + HDD 2 SSD + 4 HDD
NVMe + SSD + HDD 2 NVMe + 4 Others
  • HBA
    • パススルー SAS HBA が必要
    • SAS や SATA ディスク用の SCSI エンクロージャー
    • すべてのダイレクト接続ストレージは、ユニークIDが必要
    • RAID HBAコントローラーはサポートされない
    • iSCSI や FC を利用したSANもサポートされない

ということです。

Storage Space Direct を構成するには、いままでにSANで構成したHyper-V用のハードウェア構成ではだめで、Windows Server 2016 のOSにRAID コントローラー経由ではなく、直接見せることができるHBAにする必要があるということですので、気を付けましょう！

Storage Space Direct を検証しようと思ったときに、こちらに該当するハードウェアがないので困りました。。。

そのため、次回にRAIDコントローラー経由でしかOSにディスクを見せることができないハードウェアでもStorage Space Direct の構成方法を記載します。

サポートされない構成となるため、検証用途でご参照ください。

標準

投稿者:

投稿日

2016年12月7日

カテゴリー:

VMM

コメント

コメントする

VMMテンプレート用 応答ファイルの作成

SCVMMを利用して仮想マシンをテンプレート展開する際に、一定のパラメーターを設定した状態で仮想マシンを展開できると非常に便利です。

その一定のパラメーターは、応答ファイルを作成することで実現が可能です。

応答ファイルをVMMテンプレートに設定すると、設定した項目の設定値が反映されます！

VMMテンプレート.png

応答ファイルは、Sysprepする際のパラメーター設定方法としてよく利用されているみたいですが、VMMのテンプレート展開でも利用可能です。

応答ファイルの作成は、WAIKの中に入っているWindows システム イメージ マネージャーを利用することで作成が可能です。

WSIM.png

設定したいパラメーターは、Windows OS がブートするまでの各シーケンスの中で設定することができ、設定する内容によって設定するタイミングが違います。

今回試したのは、下記内容です。

  • Windows ライセンスキーのアクティベーション
  • リモートデスクトップの許可
  • Windows Firewall で リモートデスクトップサービスの許可
  • 日本語化
  • レジストリを追加するためのコマンドの実行

Windows システム イメージ マネージャー で構成した応答ファイルの内容は下記のとおりです。

  1. WindowsPE
    • amd64_Microsoft-Windows-Setup_netral
      • UserData
        • ProductKey
  2. OfflineServicing
  3. Generalize
  4. Specialize
    • amd64_Microsoft-Windows-TerminalServices-LocalSessionManager_neutral
    • amd64_Networking-MPSSVC-Svc_neutral
      • FirewallGroups
        • FirewallGroup[Key=”1″]
  5. auditSystem
  6. auditUser
  7. oobeSystem
    • amd64_Microsoft-Windows-International-Core_neutral
    • amd64_Microsoft-Windows-Shell-Setup_neutral
      • FirstLogonCommands
        • SynchronousCommand[Order=”1″]

4-2.FirstCommand.PNG

設定値は下記のようにすることで、テンプレートから展開した仮想マシンはリモートデスクトップやライセンス認証などの設定が完了した状態にすることができました。

プロダクトキーの入力 (仮想マシンの場合はAVMAキーを利用すると便利です)

https://technet.microsoft.com/ja-jp/library/dn303421(v=ws.11).aspx

コンポーネント

値
  • amd64_Microsoft-Windows-Setup_netral
    • UserData
      • ProductKey

プロダクトキーを入力

リモートデスクトップの有効化 と Windows Firewall でリモートデスクトップの許可

コンポーネント

値

Microsoft-Windows-TerminalServices-LocalSessionManager

fDenyTSConnections=false

Networking-MPSSVC-Svc\FirewallGroups\FirewallGroup

Active=true

Group=@FirewallAPI.dll,-28752

Profile=all

Key=1

日本語化

コンポーネント

値

Microsoft-Windows-International-Core_neutral

InputLocale=ja-JP

SystemLocale=ja-JP

UILanguage=ja-JP

UILanguageFallback=ja-JP

UserLocale=ja-JP

Microsoft-Windows-Shell-Setup__neutral

TimeZone=Tokyo Standard Time

起動後に実行したいコマンド (レジストリなどの設定が可能)

コンポーネント

値

Microsoft-Windows-International-Core_neutral

  • FirstLogonCommands

実行したいコマンド

他にも実施できることはいろいろあるみたいですので、ぜひ試してみてください。

ちなみに、下記に記載のあるリモートデスクトップ有効化のパラメーターの中の、“Group” を “Remote Desktop”としてもリモートデスクトップ接続できませんでした。。。そのため、この内容で失敗する場合は上記に記載した”@FirewallAPI.dll,-28752” で接続可能になるかご確認ください。

応答ファイルを使ったリモート デスクトップの有効化

https://msdn.microsoft.com/ja-jp/library/hh825710.aspx

標準

投稿者:

投稿日

2016年12月5日

カテゴリー:

Active Directory

コメント

コメントする

Windows 資格情報を利用したRDP接続について

Windows 資格情報を構成すると、接続先サーバーへユーザー名やパスワードを都度入力することなく、RDPなどで接続できるようになります。

しかし、既定では資格情報を利用したRDP接続は無効化された状態です。そのため、ローカルセキュリティポリシーやグループポリシーを利用して、資格情報を利用した接続を許可する必要があります。

【Windows 資格情報の登録】

1. 資格情報を登録していない場合は、コントロール パネル\ユーザー アカウント\資格情報マネージャーを展開します。

2. 「Windows 資格情報」 をクリックし、「Windows 資格情報の追加」をクリックします。

13. RDPで接続したいサーバー名、RDP接続するユーザー名とパスワードを入力しOkをクリックすれば、Windows 資格情報の登録は完了です。

1-2.png

この状態で、RDP接続しようとしてもパスワードの入力が求めまれます。

そのため、資格情報を登録したら、グループポリシーにて資格情報の使用を許可する設定をします。今回はADのグループポリシーを使用した設定方法の手順です。

【グループポリシーの設定】

1. グループポリシーを作成し、編集画面を開きます。

2. コンピューターの構成 – ポリシー – 管理用テンプレート – システム – 資格情報の委任 の順に展開。設定する項目は、「 NTLMのみのサーバー認証で保存された資格情報の委任を許可する」 です。

2.png

 

 

 

 

3. 設定を有効にし、「表示」をクリックします。

WS000001.PNG

4. Windows 資格情報を使用して接続したいサーバーのIPアドレスやホスト名を指定します。ホスト名を指定する前に、「TERMSRV/」をつける必要があります。すべてのサーバーへの接続を許可したい場合は、＊を使用します。

ex) TERMSRV/<ホスト名 or IPアドレス>  もしくは  TERMSRV/*

ws000002

これで、Active Directory 側の設定は完了です。

接続元にて、グループポリシーを手動で再適用するか、再起動をしてリモートデスクトップ接続してみてください。ユーザー名とIPアドレスを入力することなく、接続することができるようになります！

こちらの設定は、ドメイン参加したPCからワークグループへのリモートデスクトップ接続時などで有効かと思います。

ちなみに、ドメイン参加しているPCからドメイン参加したサーバーへのリモートデスクトップ接続をしたいばあい、Windows資格情報の接続先名の指定方法としてホスト名を使用すれば、グループポリシーを設定することなく、接続可能となります！

13

以上です！