今回はAWSそんなに関係ない（いや全く）記事です。
VMware App Volumesは、大きく分けて2つの目的があります。
- 仮想マシンのテンプレートに含めることのできないアプリケーションをPackageの中に含めて、提供すること。
- Writable Volumeを提供すること。この機能を使うことで、マシン内のユーザープロファイルデータをキャプチャすることが可能になるし、Packageの中に含めることができないアプリを含めて配信操作が行える。これにより、ディスク領域を逼迫しがちな個人用のPersistent Desktopを提供する必要がなくなってくるし、テンプレートをなるべくシンプルな形にすることができる。
App Volumeエージェントはnon-persistentな仮想マシンの中にインストールされる。このAgentがApp Volumes Managerに通信して、App Volumes ManagerからvCentertと連携することにより、前述のPackagesやWritable Volumeを仮想マシンにアタッチする。
App Volumes Managerの設定はすべてSQLデータベースに格納される。また、PackageやWritable Volumeの割り当てを決める際は、ADのオブジェクトが参照されて、それに沿って仮想マシンに割り当てが決められる。
アーキテクチャ上の推奨は以下のようなものである。
- 常に２台以上のApp Volumes Managerを利用すること
- クライアントから認識されるManagerのURLが常に一意になるように、LBを前段に配置するのが常套手段
- SQLサーバは共有となる
- カーネルモードで動作するようなアプリケーションは、PackagesやWritable Volumeには含めない
- Storage Group機能を使用して、一つのストレージに読み書きが集中しないようにすること。（vSANならなくてもよいと書いてあるけれど、それってFTT1以上の場合のみじゃないかな。FTT０だったら結局一つの領域に読み書き集中するだろうし）特にPackageはリードが激しくなりやすい。そらそうか。
- Packageのレプリケーションを使用する場合は、vSANだろうとStorage Group機能を使用するのはあり（ですよね）
- Packagesは、100％Readに曲振りしたストレージ上に配置すること
- Writable VolumeはRead/Writeが50:50なストレージ上に配置すること
- 一人のユーザーやデバイスにアサインするPackagesは最小にすること(KB 67354)
- App Volumes 4はMachine Managersの設定に最適化されているから必要ない限りいじるな（なんだこれ）
PackagesやWritable Volumesのリクエストは、App Volumes Agent→App Volumes Manager→vCenter Serverの順にたどって処理される。vCenterにマウント処理の負荷が集中しないように「Mount ESXi」オプションが存在し、バージョン2.x系の頃はこれが結構使える環境がおおかった。が、4.xになってからは、vCenterも新しい機構（なんぞこれ）を持つようになったため、そんなにこのオプションが役に立つこともなくなった（らしい。）
もしHorizonのPodがマルチサイトに展開されている大規模な環境であれば、App Volumes ManagerもPodのあるサイトには展開していないといけない。
Horizon Published Apps on Demand
RDSHに、必要に応じてPackagesをアタッチする機能。この機能により、RDSHのイメージをよりシンプルに構成し、必要なアプリはPackagesでアタッチすることが可能。
Horizon 2212とApp Volumes 2212を使用している必要がある。
Apps on Demandの作成手順は以下の通り
- 自動化されたRDSHのインスタントクローンファームを作成する
- App Volumes ManagerをHorizon Connection Serverに登録する
- App Volumes ManagerをRDSHファームに紐づける
- アプリケーションプールを作ってユーザーを紐づける
Apps on Demandの動作は以下の順序
- ユーザーが公開されたアプリケーションをHorizon Entitlementsから起動する
- HCSがApp Volumes Managerに接続し、必要なRDSHにPackageをアタッチするように命令する
- App Volumes ManagerはHCSから来た命令をそのままvCenterにパスする
- vCenterがRDSH仮想マシンに対してPackageをアタッチする
- Horizon ClientがRDSHのHorizon Agentにセッションを張り、アプリケーションの利用が開始される
RDSHのイメージにインストールしてしまった方がなんだか利用までの時間が短くて済みそうな気がしてしまうけれど、きっとこれでも問題ないんだろうな。。
Horizonと統合する際の考慮事項
- App VolumesのPackageにはHorizon Agentを含めてはいけない（含めるやつがいるのか。。。？）
- 既存のHorizon VMをPackageを作成するためのVMとして使用してはならない（これはやるやついそう）
- Horizon AgentやHorizon Agentなどのインストール順番はKB 2118048を参照してね
App Volumes ManagerをHorizon Connection Serverに登録する
複数台のApp Volumes Managerを登録することが、プロダクション環境におけるベストプラクティス。その際は、App Volumes Managersの前段にLBを配置することが水晶とされている。なので、Horizon Connection ServerにApp Volumes Managerを登録する際は、LBのFQDNを登録することになる。
拡張性と冗長性
App Volumes Managersのサーバは仮想マシンで組むことが推奨されている。理由はHAやSRM、vSphere Replicationなどの機能で保護することが可能だからだ。やってはいけないことは、繰り返しになるけれど、シングル構成でApp Volumes Managerを構成することである。
App Volumes Manager
App Volumes Mangerを冗長構成でデプロイするときは、SQLデータベースを外だしして構成する。App Volumes Managerはデータベースを持たずに構成するため、畢竟、ステートレスになる（？）らしい。
サイジングの限界的には2台のApp Volumes Mangerで8000ユーザーの同時利用をサポートしているらしい。ログインストームに対応したいときはもっと増やしてもいいらしい。詳細はKB 67354を参照とのこと。
vCenter Serverが複数台ある時の考慮事項
大規模環境になれば、マルチポッドの構成の元、App Volumes Managerを展開することになる。その際に、マルチサイトにあるvCenter Server（？）が異なるログイン情報を持っていても、特に問題はないが、各サイト間のESXiホスト名やデータストア名は一意である必要がある。
ただし、vCenter Serverがマルチ構成になった後は、シングル構成のvCetner Serverに戻すことは非推奨となる。
Packageはストレージに紐づく。各サイトのvCenterのストレージ内のPackageがApp Volumes Managerに見えてくる。この状況下だと、本来別サイトにあって、アクセスが不可能なPackageをApp Volumes Managerの誤操作などで仮想マシンにアタッチしてしまいうる。その時は、ストレージどうしでPackageをレプリケートするStoage Groups機能を使用して、できるだけ各サイトのストレージ内のPackageに差異がないようにするとよいようだ。（別サイトにあるPackageだからむりやでっていうValidationくらいは働かせてくれてもよくない？）
ADが複数あった時の考慮事項
複数ADがある環境でも、App Volumes Managerを利用することが可能である（ちなみに、複数存在するAD同士で、信頼関係があろうがなかろうが問題ない）。各ドメインに対して、読み取り権限さえあればよい。設定はConfigurations > Settings > Active Directoryから行う。
vSphereの考慮事項
特にストレージについて考慮する必要がある。vSphere Security Configuration Guidesを参照してね、とのこと。ん？Securityの方なの。。。？
負荷分散の考慮事項
LBを構成して、複数台存在するApp Volumes Managerの前段に配置すること（何回目？ｗ）。これができないなら、App Volumes Agentが複数のApp Volumes Managerと接続するように構成することもできる。要は、ユーザーのログインストームをいかにして裁くことができるかが至上命題らしい。
ちなみにこの本（App Volumes Architecture）作成時点では、一台当たり2000ユーザーの同時利用を想定して記載していたらしい。ユーザー何名が利用することができるかは、詳しくはKB 67354を見てね、とのこと。
ちなみにNSX Avi LBを使用するときは、Configure Avi Vantage for VMware HorizonのLoad Balancing App Volumes Managerセクションを読んでね、とのこと。
必要なのはLB側の設定なので、App Volumes Manager側では追加設定はないらしい。
で、面白いのは、サードパーティのLBもサポートしてるよ！その時は以下の表に記載の内容を意識してね！と書いてあるまではいいものの、その表が、少なくともPDF番だとすっからかんなのだ。とりあえずヘルスモニターとプールと、Application ProfileとVirtual Serviceという項目があるけれど、中身が書いてない。Web版になら書いてあるのかな。。？
データベースのデザインについて
前述のとおり、App Volumesの設定はすべてMS SQL DBに格納される。App Volumes ManagerのインストーラにはExpress版が含まれているので、検証用ならそれだけでも十分だけれども、本番環境では使わない方がいいよとあった気がする。
Failover ClusterやAlways Onの機能と一緒に使うことができるらしい。
VMware App Volumes Database Best Practicesを見ると、ちゃんとした情報を得ることができるとか。え、じゃぁこのドキュメントと一緒にしておいてほしい
