Azure Stack HCI OS 21H2 を Nested かつ WAC(Windows Admin Center)で構築する

みなさま 2021/11/2 -11/3 の Microsoft Ignite は見ましたか？😋

明確に Azure Arc や Azure Stack HCI のお話がありましたね。
私としては、いまの Microsoft の方針は世の中のITインフラが動く場所やデータの発生源からのデータの流れを考えると、すごくマッチしているように思え、すごく納得感があります。

2021年は、ハイブリッドクラウドの観点から Azure Arc や Azure Stack HCI の啓蒙活動をしているので、Azure Stack HCI OS 21H2 もGA されたことですし、限りあるリソースの中で、Azure Stack HCI OS 21H2 を使った構築の流れを記載します。

タイトルのとおり、限りあるリソースの中でNested 環境で作成します。
"Nested" というのは、ハイパーバイザーの上でさらにハイパーバイザーを稼働させることを意味します。つまり、今回は ESXi の上で仮想マシンとして Hyper-V を稼働させるということになります。

環境情報

【物理的なマシン】
ハードウェア：R640 x 1台
CPU：Intel Xeon Silver 4114 2.2GHz
OS：ESXi 6.7 （Build: 15160138）

【仮想マシン】
Azure Stack HCI OS 21H2  × 3 台
Windows Server 2022 × 1 台（Windows Admin Center 稼働用）
Windows Server 2019 × 1 台（Active Directory / DNS）

【既に構築済のモノ】

・Active Directory / DNS は既にあるものを使っています

・Windows Admin Center は ADDS との共存は不可なので、別で立てています 
　Version：1.3.2105.24004

【事前に見ておいたほうがいいモノ】
私のチームで共同で以下のサイトを作っているので、事前に読むと進めやすいです。

Azure Stack HCI攻略Wiki | Dell eカタログサイト

事前準備１

Azure Stack HCI を構築するには事前準備がすごく重要になってきます。
特にNested だとしなければいけないこともあるので、事前準備だけでかなり長い記事になりそうです。

Azure Stack HCI OS をダウンロードします。

事前準備２（仮想ハードウェア）

Azure Stack HCI OS 21H2  × 3 台 を作っていきます。
ESXi の Host Client から以下のようにディスクを構成しています。
30GBのディスクに Azure Stack HCI OS をインストールし、その他は実際に使う領域（キャパシティ）として追加しています。
キャパシティに関しては、最低で4本のSSD が必要ですが、わたしは仮想マシンを少し作りたい想定なので、多めの5本にしています。

すべてシンプロビジョニングです。

Azure Stack HCI OS は 現時点で All Flash が必須になっています。
しかし、、、見てわかる通り、このままではただの全てハードディスク構成ですので、Azure Stack HCI OS から見て、「自分には SSDが搭載されている！」と錯覚させる必要があります。その方法は私のこの記事をみてほしい。

大まかに説明すると、仮想マシンの構成ファイル（.vmx）にこれを追記します。
scsi0:1.virtualSSD = 1

Nested ESXiにSSDがあるように思わせる設定 - VMware / Microsoft 製品はこう使う。

今回は５つのハードディスクをSSDに思わせたいので、私はこんなカタチで追記しています。その後、パワーオンすることでSSDとしてAzure Stack HCI OS から認識されます。

scsi0:1.virtualSSD = 1
scsi0:2.virtualSSD = 1
scsi0:3.virtualSSD = 1
scsi0:4.virtualSSD = 1
scsi0:5.virtualSSD = 1

CPUの設定では [ハードウェアアシストによる仮想化をゲストOSに公開] にチェックをいれます。
これにチェックを入れないと、Azure Stack HCI OS にHyper-Vの役割がインストールされるときにエラーになってしまいます。

ネットワークに関しては、3本のNIC をつけています。
［VM Network］ が管理用のネットワークで、[Katayama_Storage1] が、ストレージ同期などに使うネットワークです。

 

Azure Stack HCI OS 21H2 のインストール

OSのインストールに関しては、普通のWindows Server をインストールするときと何も差がありません。3台に同じようにインストールを実施します。
注意が必要なのは、Azure Stack HCI OS は Server Core OS（GUIナシ）のOSであるため、最初の設定などは自動起動する SConfig の画面 ↓ から設定します。

この画面で最低限実施することは、以下になります。

・IP Address の設定（管理IP, Storage IP）
・ホスト名の設定

やっておいたらいいことは以下です。
あとからWindows Admin Center経由でドメイン参加させることも可能ですが、私は直接コンソールからやっています。

・ドメインへの参加

Azure Stack HCI OS 21H2 のIP Address の設定で私が少しハマった（困った）のは、
SConfig(上記の画面）から IP Address を設定しようとしたときに設定が反映されない自称に遭遇しました。何度設定しようとしても Error となりました。
そのため、SConfig の画面で 「15」を入力してPowerShell を起動後に netsh コマンドで設定を実施しました。netshコマンドだったらなぜか設定ができました。
同じ事象に遭遇した際は、原始的ですが netsh コマンドをご利用ください。

書式
netsh interface ip set address "＜インタフェース名＞" static ＜IPアドレス＞ ＜ネットマスク＞ ＜ゲートウェイ＞
コマンド例
C:\>netsh interface ip set address "Ethernet0" static 172.16.1.101 255.255.255.0 172.16.1.1 

また、この環境特有の話ではないですが、"Ethernet0" "Ethernet1" "Ethernet2" がどのネットワークに所属しているNICなのかわからなくなってしまいがちなので、そのあたりもご注意ください。

Windows Admin Center (WAC) のみで Azure Stack HCI を構築していく

これまでコマンドで構築していくのが主流の Azure Stack HCI でしたが、Windows Admin Center のみで構築をしていきます。GUI のみで構築！

Windows Admin Center にログインし、［追加］ボタンをクリックすると、
右側に "サーバークラスター " が表示されるので、[新規作成] ボタンをクリックします。

[Azure Stack HCI] を選択し、[すべてのサーバーを１つのサイトに] をクリックします。
ストレッチクラスタなどを組むときは、もう１つの選択肢になると思います。

事前にどのような前提条件があるのかを表示してくれています。
すごく良心的です。ここで何かチェックが入るわけではありません。
[次へ] をクリックして進みます。

ここからが、構成していくフェーズに入ります。
クラスターを構成するノードを検索して、[追加]ボタンでリストアップしていきます。
今回は3ノードクラスタなので、3台を追加しています。
Nested 環境なので、ハードウェアモデルのところが VMware,Inc になっています。

以下のスクリーンショット上部の少し見えていない部分では、サーバー（ASH OS）に接続しにいくときに使用するユーザーを指定しています。
※ドメイン名¥Administrator を指定

事前準備の段階でドメイン参加をしたので、ここでは既にドメインに参加済みであることが表示されています。そのまま [次へ] をクリックします。

[機能をインストールします] をクリックします。
ここでインストールされるのは、Hyper-V の役割など必須のものがインストールされます。事前準備の段階で、仮想CPUの設定で、[ハードウェアアシストによる仮想化をゲストOSに公開] にチェックをいれておかないとココでエラーになってしまいます。
クリック後は、２〜３分で終わるはずなので、[次へ] をクリックします。

更新プログラムのインストールも流れ作業で適用可能です。

ここで、Dell の認定済みノード（AX Node）などであれば、Firmwareとか適用できるはず。その際、Windows Admin Center のプラグインに OMI MS WAC(Dell EMC OpenManage Integration with Microsoft Windows Admin Center) もインストール済みじゃないといけないはず。
今回はNested のため、試せるわけもなく、[次へ] をクリックする。

再起動を実施します。Nested のため、再起動に関しては激早いです。

再起動が終わったら、[次のステージ：ネットワーク] ボタンがクリックできるようになります。

続いて、ネットワークの設定セクションに入っていきます。
各ノードに搭載しているNIC が表示されます。USB NIC など構成に不要なものは除外する必要があります。もし、残ったまま進めようとすると構成時にエラーになります。

すべて3つのNIC を搭載させています。
実際の動作検証済みノードだともっとNICポート数が多いので混乱しないように注意が必要そうです。

管理ネットワークで使う NIC を選びます。
今回の環境では NIC Teaming しないので、左側の [管理用に１つの物理ネットワークアダプター] を選択します。

事前に "Ethernet0" にのみきちんと管理ネットワークのIP Address を設定していたため、 "管理者におすすめ" と親切に記載してくれています。

[適用してテスト] ボタンをクリックすると疎通確認が行われ、[次へ]ボタンがクリックできるようになります。ここで管理ネットワークでどのNICを使うのかが決まります。

仮想スイッチを作成します。選択肢としては、３つあります。
　・仮想スイッチ１つに複数の単独NICが接続される構成（左）
　・ユーザーが使用する用の仮想スイッチ１つのみが作成される（中央）
　・ユーザー用、ストレージ用、２つの仮想スイッチが作成される（右）
Dell の Azure Stack HCI の構成ガイドは "中央" の構成を推奨としているようですが、
Nested なので、左の構成を選択します。

仮想スイッチ名などもデフォルト名 "ConvergedSwitch" というのが入力されています。
デフォルト値から変更することなく [次へ] ボタンをクリックします。

RDMA（Remote Direct Memory Access）の設定を有効化すことができる。
ここで重要なのは、Azure Stack HCI OS 側に NIC の Driver がインストールされていないと、RDMA を有効化する事ができないと思われる。
Nested なので、RDMA は使えないので、このまま [次へ] をクリックする。 

クラスター内のストレージ同期のネットワークにつかうIP Address の指定です。
私はあらかじめ、Azure Stack HCI OS のコンソールからIP Address を設定していたので、既に192.168.1.x が表示されています。この設定値は模範的ではなく、きちんとVLANごとに分けるのが正攻法ですので、ご注意ください。

WACから ASH OS ノードに接続するときのアカウントを聞かれます。

さらに、CredSSP を有効にするかどうかを聞かれます。
有効にしないと先に進めないので [はい] をクリックします。

無事接続テストが完了します。
[次のステージ：クラスタリング] に進みます。

ボタンなどをクリックすることなく、自動的にクラスタが構成可能かチェックが実行されます。

だいたい3分くらいで検証が行われました。

警告が出ていますね。

想定していた警告だったのでスルーします。

クラスタ作成を行います。
ここでは Windows Failover Cluster の名前と  クラスターIP を入力します。
その他の設定はデフォルトにしています。

クラスター構成が開始されます。

数分でクラスターが構成されました。（10分もかからなかったとおもいます）

ついに 記憶域 の設定に入ってきましたね！
まずはじめに、余計なデータが入っている場合は削除することができるようです。
今回は空っぽのディスクなので、使いませんでした。

各ホストに SSD が5本接続されているのがわかります。

一応全部のSSD が見えている状態です。

接続されているSSD がきちんと使えるかをチェックします。
一発合格しました。一応、どんなチェックをしているのか、スクロールしたスクリーンショットもつけています。

つ、ついに S2D(Storage Space Direct) の有効化です。
[有効にする] ボタンをクリックすると、構成が開始します。

約2分くらいで Storage Space Direct は有効化されました！（はやい）
ここまでで構成自体は完了ですが、まだ他に少しやらないといけないことがあります。

残りの作業

・SDN（Software Defined Network）の設定　→オプションなので今回はスキップ

・Azure Stack HCI OS を Microsoft Azure に登録　※これしないと仮想マシン作成できない

「Azure 接続」の部分から [このクラスターを登録] をクリックして進める必要があります。

今回は、構築の流れを知るために、私自信の備忘録にもなるかとおもって、流れを記載しました。

◆一覧

◆Azure Stack HCI OS 21H2 ノードの概要

総評

これまでコマンド（PowerShell）で構築するのがやっとだったAzure Stack HCI ですが、
Windows Admin Center のみで構築できるのはユーザーにとって導入の敷居がグッと下がっ多様に思います。
また、Windows Admin Center は Azure Backup なども簡単に使えますし、Azure Hybrid の 中核である Azure Arc の操作なども助けてくれるため、これぞ真のハイブリッドクラウドの出発時点ですね。

Azure Arc とは なにか？

ワタクシが ハイブリッドクラウド研究会でお話しているYoutube があるので、是非みてくださいね😋

www.youtube.com

 番外編）Windows Admin Center の更新を試してみる

Windows Admin Center の新しいバージョンがたまたまリリースされたので、ついでに付録として記載します。

現在:1.3.2105.24004

次    :1.3.2111.01001

[更新プログラムのインストール] をクリックするとすぐに始まりました。

無事、3分くらいでインストールされました！

どんどん使い勝手がよくなってきている。

Azure Hybrid たのしくなってきましたね。

かたやん

vSphere 7 - 新しいDRS ってどこが新しいの？

さて、GWで毎日なにか達成感がほしくて記事書いてみたりいろいろもがいているかたやまです。今回はvSphere 7 でDRSに機能追加されたとのことなので見てみました。

DRS とは言わずもがな Distributed Resource Scheduler のことですが、DRS自体は2006年 のときに実装されたもので、なかなかの歴史があります。

なかなかの歴史がある機能でありながら、これまで大きな機能の追加というか変化などはあまり行われずここまできています。

vSphere 7 ではメニューが増えたり、考え方が変わったりしたので、メモです。

実はざっくりですが、vSphere7 がリリースされた4/3（日本時間）でDELLEMC の石塚さん、わたし（片山）、VMwareの南さんで書いた記事の中にこんなことを書いています。

https://japancatalog.dell.com/c/isg_blog_vsphere7_01/

Dell）DRS は最近日本のユーザ様でも普通に使ってもらえるようになった印象ですが、何が変わったのでしょうか？

VMware）これまでの DRS はクラスタ全体の負荷を管理し、ホスト間の負荷のバランスをとるように動作していました。それに対して新しい DRS ではアプリケーション中心の思想で再設計が行われ、アプリケーションが動作するワークロードそのものを最適化するような配置が行われるようになりました。旧バージョンの DRS との最大の違いは、ホスト間の負荷のバランスをとらなくなったことです。新しい DRS ではホスト上の VM に対してスコアを計算し、このスコアに基づいて VM を移動させます。またこのスコアは1分ごとに計算されており、よりきめ細かな最適化が行われるようになりました。

つまり、VMごとにDRSスコアというものを出して、スコアが（改善する）と思われるESXiホストにVMを移動させる、ということが言いたいようです。 VMwareの公式Blogでもそのように書かれていますね。

https://blogs.vmware.com/vsphere/2020/03/vsphere-7-improved-drs.html

 

DRSスコアの見方については、、猛烈にわかりにくい…！のですが、文面からのわたしの解釈は、

ベースの考え方として、スコアは高ければ高いほど、リソースの競合がなく、良い状態ということ。つまり100％ が一番いい状態。ただし、80%とか100％のDRSスコアのVMが50％とかスコアが低いVMよりもパフォーマンスがいいかどうかは別。理由は、DRSスコアは５つの指標から算出されるため、一概にスコアが悪いからといってパフォーマンスが悪いとは限らない（状況による）。
例えば、CPU Ready timeが高くなってしまっているときでも、CPUの影響をあまり受けないアプリケーションがVM上で動作している場合などは、見かけ上パフォーマンス影響を受けていないように見えることもあるとおもいます。そもそもパフォーマンスが悪いと言葉は、すごく広域な意味合いであるため、あまり掘り下げても "状況による" というのが正直なところなのかもしれない。

Obtaining a VM DRS score of 80-100% indicates that there is mild to no resource contention. It does not necessarily mean that a virtual machine in the 80-100% bucket is doing way better than a virtual machine in the lower buckets. That is because there are many metrics that influence the VM DRS score. Not only performance metrics are used, but capacity metrics are also incorporated in the algorithm.

DRSのスコアはVMwareさんの資料や記事からはこんな感じで書かれています。

・CPU %ready time

・メモリスワップ

・CPU キャッシュ動作

・現在のESXiホストが持つ予備リソース容量

・マイグレーションのコスト

 

実際のDRSスコアをVMごとに見る画面ではこれらの列が用意されていました。

・DRSスコア

・アクティブなCPU

・使用済みCPU

・CPU Readiness

・付与されたメモリ

・スワップ済みメモリ

・バルーンメモリ

 

 

DRSを動かそう

やはりわたくしエンジニアですので、動いているものをみたいわけで。

新DRSのテストになっていないかもしれないですが、DRSスコアとかの変化を見るためだけに実機を触りました。新しい画面に何か表示されてほしいですから。 

DRSの設定は　完全自動化　にして、その他はデフォルト値のままです。 

 

まずテンプレートとなるWindows Server 2019 （vCPU2, Mem8GB）を作成し、以下のPowerCLI で仮想マシンを２５０個クローンする。そのとき、データストアはvsanDatastoreを使い、あとからのテスト用に１つのESXiホストに仮想マシンが寄るようにした。

 

$esxName = "172.31.7.125"
$template = "WS2019-2"
$datastore = "vsanDatastore"
foreach($n in 1..250) {
New-VM -Name test-vm$n -VMHost (Get-VMHost -Name $esxName) -Template $template -Datastore $datastore -RunAsync
}

作成後の状態がこちら。

DRSは仮想マシンが起動したときから発動するようになるので、この250個の仮想マシンを一気にパワーオンします。172.31.7.125というESXi上で仮想マシンが250個リソースを使い始めたので、vCPUならびにメモリがいっきに使用状態になるので、即座にDRSが開始されはじめます。

DRSが順次動き始めているときに [監視] - [vSphere DRS] - [CPU使用率] を見ました。

やはり、172.31.7.125 に寄せて仮想マシンのクローンをしていたので、案の定の見え方です。

 一応画面説明をみると、あくまでここでは仮想マシンのCPU使用率を表示しているらしく、CPU Ready timeというわけではないらしいです。

[監視] - [vSphere DRS] - [メモリ使用率] を見ました。同じく想定通り172.31.7.125 のメモリをめっちゃ使っています。これがどうなっていくか楽しみです。

その間にもDRSでどんどん仮想マシンが別ホストへ移行されていきます。

DRSスコアはどうなっているかというと０％のものもあれば、８０％くらいのものもあり、バラバラという印象。

６分ほど経過して確認すると、CPU使用率がすこしマシになってきました。平準化されてきましたね。

 同じくメモリもましになってきました。

９分くらい経つとほぼほぼふらっとになりつありますね。

仮想マシンのパワーオンからトータル約１０分でリバランス完了しました。

[監視] - [vSphere DRS] - [推奨]

DRSの設定を "完全自動化" から"手動" に変更したら使えます。

DRSで動かしたほうがいい仮想マシンを表示してくれ、しかも原因が何かを表示してくれています。すごく親切ですね。さっそく [今すぐ DRS を実行]をクリックします。

 "推奨の更新" というタスクが動きました。ボタンの意味合いからだとすぐにvMotion が実行されるのかとおもいきや、10分経っても実行されず。

まだ見れていないメニュー

まだみれていないものは以下３つです。

[監視] - [vSphere DRS] - [障害]　　→謎

[監視] - [vSphere DRS] - [ネットワーク使用率]　→みてもおもしろくなさそう

 少し長くなってしまいました。

こうやって文字にすることで自分の頭にも入るのでいいですね。

おわり

vSphere 7 - File Service for vSAN 7 をESXiでNFSマウントしてみる（２）

前回の投稿で、File Service を有効化の流れをご紹介しました。

vSphere7 - File Server for vSAN7 を有効化するよ - VMware製品はこう使う。

VMware公式ドキュメントはこちらあたりです。（VMware Docs）

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-82565B82-C911-42F7-85B1-E9EF973EE90C.html

ファイル共有を作っていく🙆

今回は、vSANのFile Serviceで ファイル共有を作成していき、その後、スタンドアロンのESXiにマウントさせようとおもいます。

左のインベントリ一覧から vSANクラスタをクリックして、［設定]タブ - [vSAN] - [ファイル サービスの共有] をクリックして追加ボタンを押して共有を作成していきます。

一般的なNFS共有を作るときの設定項目が並んでいますね。

・[プロトコル]：NFS3 , NFS4.1 が使えます。設定画面で選ぶ必要はありません。ただ経験則的にNFS4.1使われてるのを見たことがないですが…

・[名前] ：共有名です。

・ストレージポリシー：vSAN特有のワードが出てきました。この共有に保存されるデータをどのような冗長性を担保するかというポリシーですね。作る共有によってストレージポリシーを変更できるのはFile Serviceの良さと思いました。

・ストレージ容量の割り当て：クォータ（閾値）の設定です。

こんな感じで設定しました。

ファイル共有へのアクセス権の設定です。

私は  [任意のIPアドレスからのアクセスを許可] で設定しましたが、各項目の解説です。

---------------------------

[アクセスなし]：アクセス件の設定をしない場合に選択

[任意のIPアドレスからのアクセスを許可]：一見、指定したIP アドレスからだけのアクセスを許可するような文言ですが、指定することはできません。

[ネット アクセスのカスタマイズ]：アクセスするネットワークを範囲指定する設定です。

---------------------------

最後に確認画面が表示され、 [終了]ボタンをクリックすると共有が作成されます。

共有ができあがった画面がこちら。

[URLのコピー] のリンクをクリックすると、NFSv3、NFSv4.1 を選ぶことができるので、クリックするとリンクをコピーできます。わざわざ入力する手間もかからないのですごくいい！！

スタンドアロンのESXiからFile Serviceをマウントする
※vSphere 7.0リリースされた現時点ではESXiでマウントはNot Supportだそうですが。

vSANクラスタに所属しない単独のESXiを右クリック して、[ストレージ] - [新しいデータストア...] をクリックします。

新しいデータストア [NFS] を選択して [NEXT] ボタンをクリック。

NFSの情報を入力します。

[FINISH]をクリック！

無事マウント完了。

ファイル共有の容量の監視は データストアをクリックし、[監視] - [vSAN] - [容量] から確認します。ファイル共有の容量は、[ユーザーオブジェクト]にふくまれるのですが、

スクリーンショットを撮り忘れました。。

使い始めるまでは以上になります。

個人的には、このNFSに仮想マシン置いたらどれくらいのIOPS出るのだろうという好奇心が湧いてきました。

次回はせっかく有効化したFile Serviceですが、無効化してみようとおもいます。

vSphere 7 - File Service for vSAN 7 を有効化してみようではないか。

File Service for vSAN7 を有効化するよ

手元の環境を使ってvSphere 7 のFile Service を有効化したのでスクリーンショットをペタペタ貼っていこうの会です。（まだ普通に有効化しただけですが）

私が使っている環境はvSphere7 正式GA後のものを使っているのでスクリーンショットもGA版です。

環境（Build 15843803)

File Service for vSAN 7 ってなに？

ようはファイル共有機能です。といってもきちんとした機能なので、ご紹介。

File Service はvSphere 7 の注目機能の１つで、vSAN 7に完全に統合されているのが特徴です。vSANデータストア上にNFSが位置するような構造になっていて、NFS v3, NFS v4.1 を介してアクセスすることになります。

vSAN自体を構築するのが簡単になっていることはご存知のとおりですが、このFile Service も有効化（構築）するのは簡単で、非常にシンプルな構造になっています。

注目すべきはこのFile Serviceはファイル共有がVM、PC、そしてコンテナで利用することを想定されているという点です。アピールするかのように「Pod1」「Pod2」が画面のど真ん中に表示されていますね　笑

ここ1年以上、VMware社はアプリケーションとインフラの融合をメッセージしてきていますが、技術的にはこういったところがネタになってくる部分ですね。

ただし、File Serviceを利用するにあたり、各ESXiノードごとにファイルサービスエージェントをデプロイすることになりますので、有効化ボタンを "ポチッとな" だけでは利用することはできませんので、ご注意ください。

ファイルサービスエージェントがNFS を提供することになるわけですが、間にDistributed File System というのがいるので、全てのファイルサービスエージェント間で構成を共有しています。（ファイル共有名など）

Windows Server のDFS（Distributed File System） をご存知の方は似たようなものだと思ってもらえればいいかなと。

事前準備

・各ESXiホストに配置されるファイルサービスエージェント（仮想マシン）で使うIP Addressを用意する（ESXi×4台なら４つ用意）

・準備するIP Address を全て逆引きできるできるようにしておく

・パラメータ：名前空間の名称、DNSサーバーIP Address、DNSサフィックス名

・用意が整っていればだいたい30分くらいの作業

有効化していく

では、File Serviceの有効化メニューを見てみましょう。

左のインベントリからvSANクラスタをクリックしたあと、[設定]タブ - [vSAN] - [サービス] の中にある [ファイルサービス] から ”有効化” ボタンをクリックするところから始まります。

概要が表示されます。この図は本当にわかりやすいですね。

Pod のアピールがすごいですが、両サイドを見るとVMもPCも接続されているので、汎用性が高いことが見て取れます。

vCenterからインターネット接続できるようにしているにも関わらず、直接ファイルサービスエージェントのOVFやVMDKをダウンロードできなかったです。

そのため、手動でダウンロードしました。

ダウンロードはこちらから（探すのめんどくさかった）
-VMware Virtual SAN File Services Appliance 7.0 (release date 2020-04-02)
https://my.vmware.com/jp/group/vmware/details?downloadGroup=VSAN-FILESERVICE-700&productId=973#product_downloads

File Name:
-VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.ovf
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.mf
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962_OVF10.cert
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-system.vmdk
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-log.vmdk
VMware-vSAN-File-Services-Appliance-7.0.0.1000-15817962-cloud-components.vmdk

名前空間、DNSサーバー、DNSサフィックスを入力して次へ！

ファイルサービスでどのネットワークを使うのか、を選びます。

vDSにつながっている使っている vmkernelポートはちゃんと表示してくれているという親切な表示です。

ファイルサービスエージェントが使用するIP Address のプールを指定します。

1行目のIP Address を入力したあとに"自動入力"ボタンを押すと、連番が自動入力されます。また、 "ルックアップDNS"ボタンを押すと名前解決して自動でFQDNが入ります。

事前にDNSレコードを作成しておかないと、この画面を突破できません。

設定項目がざっと一覧で表示されます。"終了"ボタンをポチっと押します。

ファイルサービスエージェントがデプロイされ自動的に「vSAN File Service Node」という名前になります。この仮想マシンの実態はPhoton OS で、VMware曰くこの上でファイルサービスとしてコンテナが動いているそうです。

ESXi1台に対して、1台のファイルサービスエージェントなので、あえてDRSは無効化してFile Serviceを有効化しましたが、特に問題なく構成ができた結果となります。

 DRSがオンだったら、稼働するホストを指定するアフィニティルールが作られたのか・・・？（未確認）

File Serviceの有効化がおわると、以下のようにパラメータが表示されるようになります。

使い方とかについては後日紹介できればとおもっています。

オワリ

ESXi 7.0 をインストールしてみる（Nested）

SIerさまに手順書作成のときにご好評のESXiインストール時のスクリーンショット です。ただひたすらにインストール画面を張っていくだけの記事です。

（シュール）

結論からいうとぜんぜん変わってないです、

インストール後の画面で、メディアを取り出すかどうかを問われるところが

変わったくらいかなとおもいます。

昔からの画面ですね。いままでESXiを運用してきた人にはすごく安心材料ですね。

vCenter7を新規デプロイしたが、デプロイ時の画面は変わらず

インフラ市場大注目のvSphere7 が コロナなんてなんのその！

SIerのみなさまに、ドキュメント作るときの材料としてご好評のひたすらスクリーンショットを張るシリーズです。今回はvCenter 7をただただ新規デプロイするだけという気楽な記事です。

一言でいうと新規デプロイではぜんぜんvCenter 6.7のときから画面の内容は変わっていません。

日本時間だと2020/4/3にリリース（GA）されたわけですが、その日と同時にわたしは所属会社で以下の記事を投稿しています。

https://japancatalog.dell.com/c/isg_blog_vsphere7/

とはいえ、まったくvSphere7(vCenterもESXiも）触っておりませんゆえ、、、触っていかな記事も書けないわけなので、、触っていきます。

ではさっそく　Let's Start!

デフォルトはSSH無効になっている。

なぜか有効にすることを促してくる。デフォルトをしるためにスクリーンショットを撮ったが、もちろん有効にしました。

やはりぜんぜん変わらなかったですね(

中身はめちゃ変わってるはずなのに、作るときは前のまま　というのは

ユーザー視点でいいですな。

オワリ