仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

vSANやるぞー!(2)-そもそもvSANってなんだ

皆さまお疲れ様です。

 

告知していた通り、Citrixの記事と並行してvSANの記事を投稿します。

今回は初回ということで、vSANの概要や構成要件について記載します。

 

ポータルへ戻る場合はこちら

vSANやるぞー!(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

元々、vSANはvSphere 5.5から実装された機能で、2014年4月に提供が終了されたvSphere Storage Appliance(VSA)の後続製品として発表されたと記憶しています。

Software Defined Storage製品として、2017年現在ではHCIと組み合わされて使われることがほとんどかと思います。

 

ちなみに、2017年9月21日時点でのvSANの最新版は、vSAN 6.6となります。

(vCenter 6.5.0d 以降で対応)

 

 

その1.そもそもHCIってなんだ?

vSANとセットで出てくる用語に、HCIというものがあります。

Hyper Converged Infrastructure の頭文字を取った用語です。

 

~~~HCI以前の一般的なハードウェア構成~~~

現在でも企業の一般的なハードウェア構成は下記の通り、Network + Server + SAN + Storage という構成かと思います。

NW・サーバー・SANとコンポーネントが分散されることで、パフォーマンスと拡張性が高いインフラ構築が可能です。

その一方で「コンポーネントが分散されることで専用の管理者が増え、運用コストがかかる。」「サーバー追加の際に既存機器の設定変更が多くなり、迅速なサーバー追加が不可能。」などのデメリットもあります。

 

f:id:kenta53682:20170919220008p:plain

 

 

~~~HCIのハードウェア構成~~~

 HCIではSSD / HDDが内蔵されたサーバーを複数台準備し、ソフトウェアでローカルストレージを1つの共有ストレージとして認識させることで、SANの管理が不要となり、シンプルな仮想化基盤が構築できる点が特徴です。

この「ローカルディスクをまとめて共有ストレージに見せるソフトウェア」がvSANです。

今までは新規サーバーを導入する場合も、SANスイッチのゾーニング変更や、ストレージのホストマッピング追加など設定変更箇所が多かったところが、HCIではサーバーを追加し、Web Clientで数クリックをするだけで追加が完了します。かつ、管理者もサーバー管理者のみでよくなります。従って、HCiではHCI以前のインフラ基盤のデメリットが解消されます。

パフォーマンスについても、All Flashであれば25,000 IOPS~80,000IOPS(※)などEntry~ミドルレンジのストレージに近いIOを出すことが可能です。

 

f:id:kenta53682:20170921221754p:plain

 

vSAN Ready Nodes AF2~8のMaximum IOPSより

 

 

その2.そもそもvSANってなんだ?

その1.でvSANは「複数サーバーのローカルディスクをソフトウェアでまとめて1つの共有ストレージに見せる機能」と記載しました。

但し、vSANはストレージのようにVolumeという概念はなく、RAIDを構成したりプールからボリュームを切り出したりする作業は行いません。

 

vSANは簡単に言うと、下記の特徴を持っています。

①複数台のESXiのローカルディスクをまとめ、共有ストレージを作る

②ESXiのローカルディスク構成は All Flash or Hybrid(SSD+HDD) の2タイプある

③各ESXiは最低1つのSSDが必要

④③の1つのSSDはRead / Write Cache 用のCache Diskとして使用される(vSANデータストア容量には含まれない)

⑤Cache SSD以外のSSDまたはHDDはCapacity Diskとして使用される(vSANデータストア容量に含まれる)

⑥Cache Disk×1、Capacity Disk×n(最大7)でディスクグループを作る

⑦ディスクグループは1ESXi当たり最大5個設定が可能

⑧vSAN自体にはRAIDという概念はないため、vSANデータストアは「Capacity Disk×ディスク本数分」の容量となる

⑨vSANデータストアはクラスターで1つだけとなる

RAIDのような耐障害性はvmdkを複数ホストに分散配置することで実現する

⑪⑩を実現するため、各仮想マシンに「仮想マシンストレージポリシー」を適用する

⑫⑩を実現するため、ストレージポリシー内でFTT(何台のホスト障害に耐えれるようにするか)を設定する

⑬FTTで設定した台数のホストにvmdkが保存される(FTT=1、40GBの仮想マシンなら、2台のESXiのCapacity Diskに40GBのvmdkが保存される)

⑭⑬でvmdkが保存されたESXi以外のホストに、Witness用のデータが保存される

⑮vSANデータ連携用のネットワーク(VMkernel)が必要。All Flashの場合は10Gbps、Hybridの場合は1Gbpsが最低でも必要

 

箇条書きで要点をまとめましたが、vSANの概要図は下記の通りになります。

私も実際に触るまでは、vSANを「ローカルディスクをソフトウェアRAIDで組む機能」だと誤認識していました。実際はvmdkファイルの分散配置で疑似的にRAID(のようなもの)を実装し、耐障害性を実現しているイメージとなります。

 

 

f:id:kenta53682:20170921231834p:plain

 

 

その3.vSANを組むには何が必要?

前提条件は、Requirements for Enabling vSAN の記事を見るのが近道です。

下記をご参照下さい。(vSAN 6.6の記事となります。)

Requirements for Enabling vSAN

 

それでは本日は以上となります。

長々とありがとうございました。

 

XenDesktop / XenApp サイジング(6)ーLicense Server / RDS License Server

皆さまお疲れ様です。

この記事ではCitrix License Server / RDS License Server のサイジングを記事にします。

 

ポータルへ戻る場合はこちら

XenDesktop / XenApp サイジング(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

⑥Citrix License Server

VDI Handbook上では下記の指標が記載されています。

CPU:2vCPU

メモリ:2GB

170ライセンス/秒 の払い出しが可能

 

基本的に、Citrix License Server 専用のサーバーを導入することは少なく、Delivery Controller 相乗り、もしくはSQL Witness Server 相乗り のパターンがほとんどかと思います。相乗りするコンポーネントのサイジングに準拠すればよいかと思います。(License Server自体はリソースをほとんど消費しないため。)

 

 

⑦RDS License Server

XenAppの時のみ必要なコンポーネントとなります。RDS License ServerはMicrosoft製品となりますが、公式ドキュメントを探しても有用な情報は見つけられませんでした。

RDS License Serverも、基本的にCitrix License Serverやその他のコンポーネントと相乗りさせる方針だと思いますので、相乗りするコンポーネントのサイジングに準拠すればよいかと思います。

 

 

それでは、本日は以上となります。

ありがとうございました。

vSANやるぞー!(1)-まずはここから読んでね

皆さまお疲れ様です。

 

最近はCitrixの記事ばかり書いており、vSphereの記事が全然書けていなかったため、自分自身に書かせるためにも先に告知をしたいと思います。

 

2016年頃から、VMware案件でよく聞くワードといえば vSAN かと思います。

HCI導入案件はまだやったことがありませんが、最近は提案の1パターンとしてHCIが入ることが多くなっているため、Citrixと並行してvSANについて勉強し、記事にしていければと思います。(実務でやっていないので書ける情報はたかが知れているかもしれませんが。)

 

はてなブログで小佐野さん(VMの中の人?)という方がvSANを記事にしていらっしゃるので、参考にさせて頂きながら記事にできればと考えております。

 

vmwarekkhci.hatenablog.jp

 

 

~~~~~まとめページ~~~~~

①そもそもvSANってなんだ

vSANやるぞー!(2)-そもそもvSANってなんだ - 仮想化エンジニア奮闘記

 

②vSANのディスク構成(Cache / Capacity)

準備中

③vSAN障害時の挙動(Cache Disk障害時)

準備中

④vSAN障害時の挙動(Capacity Disk障害時)

準備中

⑤vSANでのBCP対応(Streached Cluster)

準備中

⑥vSANのハードウェア選定(vSAN Ready Nodes)

準備中

~~~~~~~~~~~~~~~~

 

さすがに家の環境でvSANはできないからHOLを活用しよう。。。

(Nested ESXiで過去やったことはあるのですが、IOが遅すぎてイライラ笑)

 

それでは以上となります。

これからvSANの回、よろしくお願い致します。

XenDesktop / XenApp サイジング(5)ーXenApp(VDA)

皆さまお疲れ様です。

この記事ではXenApp(VDA)のサイジングを記事にします。

 

ポータルへ戻る場合はこちら

XenDesktop / XenApp サイジング(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

⑤XenApp (VDA)

VDIの肝、Virtual Delivery Agentのサイジングです。

今回は XenApp (VDA for Server OS) のサイジングとなります。

 

 

・CPU

ネットワールド社の資料を参考にすると、vCPUをpCPUの2倍とした場合、コア数に対してパフォーマンスが30%程度落ちるそうです。(1.5倍で約20%)

上記を踏まえて、vCPUは下記で検討します。(勿論安全なのはオーバーコミットさせない pCPU:vCPU=1:1 です。)

物理コア(pCPU):仮想コア(vCPU) = 1:1~1:2

 

XenApp 6.5時代のサイジングガイドとなりますが、1物理コア当たりのユーザー数の推奨は下記となります。基本は、1物理コア当たり10ユーザーを1つの指針とします。

 

f:id:kenta53682:20170917110713p:plain

 

ちなみに、私が過去に経験したインターネット分離案件では、下記のようなサイジング・実績となりました。

【サイジング】

・pCPU:vCPU = 1:1 (オーバーコミットなし)

・1ユーザー当たりのCPU使用量:200MHz 強

・1物理コア当たりのユーザー数:12ユーザー

 

【実績】

・pCPU:vCPU = 1:1 (オーバーコミットなし)

・1ユーザー当たりのCPU使用量:200MHz

・1物理コア当たりのユーザー数:10ユーザー (想定より利用者が少なかった)

 

CPU使用量はサイジングと実績値が非常に近く、安心した記憶があります。

 

 

・メモリ

XenAppのメモリは利用するアプリケーションによって変わります。

検証環境や業務端末などで、業務アプリケーションのメモリ使用量を計測することが適切なサイジングの近道になります。

 

アプリケーションのメモリ使用量が把握できたら、次のように計算します。

メモリ容量 = OS使用量(4GB~8GB) + {( 64MB[ICA通信] + xMB[アプリ] ) × ユーザー数 }

 

従って例えばOSに40GBを搭載し、1XenApp当たり50ユーザーを見込む場合

1ユーザー当たりのメモリ量

= ( 40GB - 8GB[OS使用量] )  ÷ 50 - 64MB[ICA通信] = 590 MB 程度

 

今のアプリはメモリを消費するものが多いので(IEChromeなどもいくつかタブを開くと500MBは余裕で使われるので)、バッファも込みでサイジングをすべきです。

 

また、XenDesktopサイジングと同じく、XenAppも物理サーバー側ではオーバーコミットは推奨されていません。従って、

1XenApp当たりのメモリ量 × XenApp総数 + Hypervisor + Buffer

がHWで準備するメモリとなります。

 

 

・ディスク IOPS

XenDesktopサイジングのディスクIOPS表をそのまま再度添付します。

Disk IOはXenDesktopに比べて低く、5~10 IOPS/1ユーザーセッション当たりを指標とします。

f:id:kenta53682:20170917113016p:plain

 

従って、1,000ユーザーであれば、10 IOPS × 1,000 ユーザー = 10,000 IOPS をストレージ側で見込んでおけばよいと思います。

 

 

・ディスク サイズ

XenAppのディスクサイズは下記4つの合計値で計算します

①OS (Hotfix適用なども見込み、40~50GB 程度)

ページングファイル (メモリ容量 × 1.0~1.5程度)

③アプリケーション (インストールサイズはアプリケーションに依存)

④ユーザープロファイル (100MB × 1XenApp当たりのユーザー数)

 

特にユーザープロファイルでは、XenAppのローカルプロファイルには、移動ユーザープロファイルに含まれない「AppData\Local」や「AppData\LocalLow」が含まれます。

移動プロファイルサイズだけを見て④を計算しないように注意して下さい。

 

 

・ネットワーク

XenDesktopサイジングと同じく、 HD動画再生や大容量ファイルの印刷を頻繁に行う業務でなければ、数百Kbps/1ユーザーとなるため、1Gpbsで事足りると思われます。

 

それでは本日は以上となります。

ありがとうございました。

XenDesktop / XenApp サイジング(4)ーXenDesktop(VDA)

皆さまお疲れ様です。

この記事ではXenDesktop(VDA)のサイジングを記事にします。

 

ポータルへ戻る場合はこちら

XenDesktop / XenApp サイジング(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

④XenDesktop (VDA)

VDIの肝、Virtual Delivery Agentのサイジングです。

今回は XenDesktop (VDA for Desktop OS) のサイジングとなります。

 

 

 

・CPU

VDI Handbook 上では、VDI当たり2vCPU以上を推奨しているとのことです。

(複数スレッドが同時に実行できる。1vCPUは軽いワークロードには耐えられるが、セッションがハングする可能性が高く、かつ、軽いワークロードであればXenAppの方が適している。)

 

そして、ネットワールド社のセミナ―資料では、VDIのvCPUの計算式として、下記を指針としています。

1VMのクロック数(MHz):物理CPUのクロック数(MHz) = 物理コア(pCPU):仮想コア(vCPU)

 

例えば、Xeon E5-2680 v3 × 2ソケット搭載した物理サーバーがあり、

1VMの1vCPU当たりのクロック数を500MHzで試算した場合、下記の通りになります。

(物理コアについては、Hypervisor用2コア を引いた値を使用します。)

 

500(MHz):2500(MHz) = (12*2-2):x

x = 110

→従って、1vCPU(500MHz)なら110台 、 2vCPU(1000MHz) なら55台のような計算になります。

→CPUコアの集約率としては、5VM/pCPU となります。

 

1VM当たりのクロック数はお客様の環境にもよりますが、私個人の実績値としては 400MHz~500MHz をサイジングの基準としています。

 

VDIでは、1コア当たりの集約率も焦点になりますが、1物理コア(pCPU)当たり、5VMが集約率としては妥当な線とのことです。

 

Citrix ではありませんが、VMware View でもCPU集約率のスタートラインとして、6VM/pCPUと記載がされています (p.5) ので、5VM/pCPU前後が集約率の妥当な線なのかと思われます。

Server and Storage Sizing Guide for Windows 7 Desktops in a Virtual Desktop Infrastructure

 

 

・メモリ

 導入するアプリケーションにもよりますが、Windows 7 では 2GB、Windows 10 では 4GB が割り当てメモリの指針となるかと思います。最近のOSになるに従って、メモリの使用量は増加する傾向にあります。

 

VDI Handbook および ネットワールド社セミナー資料でメモリのオーバーコミットは推奨されていないため、HWに準備するメモリ量も

1VM当たりのメモリ量 × VM総数 + Hypervisor + Buffer

を指針とします。

 

例えば、Windows 10 で考えると下記のようになるかと思います。

4GB × 110(CPUの計算式より) + 4(Hypervisor) < 444GB 以上

→例えば、32GB RDIMM × 14枚 = 448GB 以上など

(メモリも32GBとなると定価で1枚25万程度と結構高くつきますね。)

 

 

・ディスク IOPS

VDIにおいてIOPSが最も必要な動作は、マシンの起動時となります。

1VM当たりのIOPSも、最近のOSになるに従って高くなる傾向になっています。

 

VDI Handbook上で、Windows 10であれば1ユーザー当たり 20~35IOPSであり、Read:Write = 8:2 となります。

f:id:kenta53682:20170914194234p:plain

 

従って、ストレージのIOPS(1ホスト当たり)は

35(IOPS) × 110台(CPUの計算式より) = 3,850 IOPS

例えばESXiホストが10台(1,100ユーザー分)あれば

3,850 IOPS × 10ESXi = 38,500 IOPS (Read 30,800、Write 7,700)

となり、エントリーストレージ (例:Lenovo Storwize V3700 V2 で 27,000 IOPS) だと性能不足となってきます。

 

1点注意ですが、上記の20~35IOPSはあくまで最低ラインとして考えて下さい。

IOPSの上限が大きいほど、処理速度は向上します

 

 

・ディスク サイズ

ディスクサイズはプロビジョニング方式に依存します。フルクローンを使用すれば1VM当たりのディスクサイズ × VM数 分のディスクサイズが消費されますが、今はストレージに Deduplication 機能が備わっているので、Deduplication 機能を使用すればある程度の容量削減が望めるかと思います。(Deduplication の割合はストレージに依存すると思いますのでこちらでは議題に上げません。)

 

ここではMCSを使用した場合のディスクサイズを記載します。

VDI Handbook上で、Windows 10であれば1ユーザー当たり 15~20GBが差分ディスクとして使用されます

f:id:kenta53682:20170914195637p:plain

 

従って、ストレージのディスクサイズは

マスターVM:50GB × マスター数

プロビジョニングVM:15GB × VM

例えばマスター数3台、VM数1,000台であれば

(50GB × 3VM) + (15GB × 1,000) = 15TB 程度

となります。

 

 

・ネットワーク

PVSはPXEブートでネットワーク帯域を使用しますが、通常のICA通信で使用される帯域は下記にある資料が参考になります。Office、IE、印刷、動画再生でどの程度ネットワーク帯域が使用されるかの指標を記載している資料となります。 

Performance Assessment and Bandwidth Analysis for Delivering XenDesktop to Branch Offices

 

HD動画再生や大容量ファイルの印刷を頻繁に行う業務でなければ、数百Kbps/1ユーザーとなるため、1Gpbsで事足りると思われます。

 

それでは本日は以上となります。

ありがとうございました。

XenDesktop / XenApp サイジング(3)ーDatastore SQL Server

皆さまお疲れ様です。

この記事ではDatastore SQL Serverのサイジングを記事にします。

 

ポータルへ戻る場合はこちら

XenDesktop / XenApp サイジング(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

③Datastore SQL Server

SQL Serverで肝になるのはディスクサイズかと思います。

CPU・メモリについては、VDI Handbook上で下記が推奨されております。

 

f:id:kenta53682:20170906201027p:plain

※1点気をつけて頂きたいのが、SQL Serverは既定の設定だとメモリを際限なく消費します。必ずインスタンスに対して最大サーバーメモリ設定は行うようにしましょう。

 

その他、SQL Serverでパフォーマンスに関するBest Practiceは下記が参考になります。

SQL Server 2016 環境構築時のパフォーマンスに関するベストプラクティス – Microsoft Japan Data Platform Tech Sales Team Blog

 

 

これ以降は、肝のディスクサイズについて記載をしていきます。

CitrixのDBには大きく3種類あります。

①Site Database:Studioの設定情報を格納するDB

②Monitoring Database:Directorの監視データを格納するDB

③Logging Database:Studioで管理者が行った監査ログを格納するDB

 

DBの中では②・③が容量が大きくなります。

特に②についてはPlatinum Editionだと1年間監視データを格納することが可能なため、結構な容量になります。

 

VDI Handbook上でも色々情報が書かれていますが、一番いいのがCitrix社が公開しているデータベースサイジングツールを使用することです。

 

ツールを使用して、Site DBおよびMonitoring DBのサイズを計算できます。

XenDesktop 7.x: Database Sizing Tool

※Logging DBについてはツールで算出できないため、Handbook上の情報をベースにするしかありません。Handbook上では「非MCS環境では30~40MB、MCS環境では200MBを容易に超える(仮想マシンのビルドデータをログに取るため)」と記載がされています。従って、Logging DBについては1~2GB程度を見込めば十分かと考えております。

 

 

下記は一例ですが、例えば「XenAppのインターネット分離案件で、2,000ユーザーに対してIEChromeを公開する」となったことを想定して試算をしたものです。

下記はMonitoring DBの画像ですが、1週間で約2GB、1カ月で約4.5GB、1年間で約34GBと分かります。Platinumの方は34GB(最大1年)、Enterprise/Advanced/Secure Browser の方は2GB(最大1週間)をmax値として考えればよいかなと思います。

 

f:id:kenta53682:20170906194638p:plain

 

 勿論上記はDBのサイズだけですので、DBバックアップをローカルに吐き出す場合やトランザクションログバックアップをローカルに吐き出す場合などは別途その分のディスク容量が必要となります。(特にMirroringやAlways Onを使用する場合、完全復旧モデルが必須となるため、トランザクションログバックアップは必ず取る必要があることは留意して下さい。)

 

Datastore SQL ServerについてはDBバックアップ要件でディスクサイズが大幅に変更される可能性があるため、ディスクについては明示しないようにします。

 

なお、SQL Server Mirroring や Always on フェイルオーバークラスタ・高可用性グループを使用する場合、スタンバイ側のサーバーは同じリソースで準備し、Witnessは最小リソース(SQL Express を導入し、かつ Citrix License Serverと相乗りなど)で構成すればよいと思います。

 

それでは以上となります。ありがとうございました。

XenDesktop / XenApp サイジング(2)ーStoreFront / Delivery Controller

皆さまお疲れ様です。

この記事ではStoreFront / Delivery Controllerのサイジングを記事にします。

 

ポータルへ戻る場合はこちら

XenDesktop / XenApp サイジング(1)-まずはここから読んでね - 仮想化エンジニア奮闘記

 

①StoreFront

StoreFront サイジングはVDI Handbook上では明確に記載がないため(※)、ネットワールド社のセミナー資料を参考にしています。

 

※VDI Handbook上では、4vCPU / 4GBの1台構成で、CPUを75%使用した時は1秒あたり291アクティビティが行われている、という記載がされています。但し、「アクティビティ」にはログオン以外にもアプリケーションの登録/登録解除/ログオフなどの動作も含まれるため、秒間当たりのログオン処理数は記載されていません。

 

 XenDesktop / XenApp のログイン処理を受け付けるサーバーのため、ログインストームを考慮した台数にする必要があります。

・CPU:4vCPU

・メモリ:4GB

・ディスク:40GB (IISアクセスログの保管期間などによって左右されますが、OS以外に40GB分あれば十分足ります。)

100ユーザー/分 のログオン処理が可能

上記リソースで、冗長化 2台で 1,000 同時接続ユーザー数が1つの指針

 

・StoreFrontにSSL通信(Citrix推奨)で接続することを前提としています。(HTTPの場合は暗号化処理がないため、上記より多くのログオン処理が可能かと思われますが、上記で計算してよいと思います。)

・StoreFrontノード数は6までがCitrixでもテストされていると記載がされているため、StoreFrontリソースのスケールアップも考慮に入れると下記のような拡張性になるかと思います。

f:id:kenta53682:20170902184309p:plain

 

 

②Delivery Controller

Delivery Controller サイジングはVDI Handbook上で下記の通り記載されています。

・CPU:4vCPU

・メモリ:4GB

・ディスク:40GB (左記以外にOS分のディスク)

5,000 台の VDI を管理

 

Delivery Controller 台数の計算式 (VDI Handbookより)

f:id:kenta53682:20170902171622p:plain

ほとんどの環境では、冗長化込みの2台構成で事足りる

 

Delivery Controller はCPU処理が多い傾向にあり、CPU割り当て量が大きければその分管理できるVDI数が増えます。

 

それでは以上となります。ありがとうございました。