仮想化エンジニア奮闘記

Citrix や VMware をはじめ、仮想化に関する最新技術や設計情報の検証結果を共有します。自分が面白いと思ったものを記事にするので一貫性はあまりありません。なお本ブログは個人のものであり、所属する会社とは関係ありません。内容については自己責任の上、ご参照をお願い致します。

vSphere 6.7 / vSAN 6.7 / vROps 6.7 がリリースされました

皆さまお疲れ様です。

 

2018年4月17日、vSphere 6.7がリリースされました

 

今まではvSphere 5.0 → 5.1 → 5.5 → 6.0 → 6.5 と来ていたので、「次はvSphere 7かなー」と思っていたのですが、6.7でした 笑

 

さて、今回のリリースでは下記の製品が6.7系として発表されているようです。

今までバージョンが違って覚えるのに苦労していましたが、足並みがそろいましたね。

vSphere ESXi 6.7 / vCenter Server 6.7

vSAN 6.7

vRealize Operations Manager 6.7 (4/12 Relase vSphereより少し早いです)

 

Release NoteやvSphere Blogから気になる情報をピックアップしてみましょう。

vSphere 6.7 Release Notes

VMware vSAN 6.7 Release Notes

vRealize Operations Manager 6.7 Release Notes

Introducing VMware vSphere 6.7 - VMware vSphere Blog

 

 

◆気になる情報をピックアップしてみた

①vSphere 6.7 がvCenter Server for Windows の最後のリリースになるようです。以降はVCSAのみが提供される形となるかと思います。

 

 

②vSphere Client(HTML5)の機能が強化され、従来のvSphere Web Clientに(機能的に)近づいているようです。VMwareは将来のリリースでvSphere Web Clientを非推奨にする予定です。

 

vSphere 6.7ではvCenterのアドレスにアクセスすると、下記のようにHTML5版が上に表示されます。(vSphere 6.5ではvSphere Web Clientの方が上でした。)

呼び名が「vSphere Client」なので、5.x時代のC#のとごっちゃになりそうですね 笑

f:id:kenta53682:20180419090925p:plain

 

ホーム画面に移ると、Web Clientとほぼ同等の操作が出来そうな印象を受けました。

vSANやUpdate Managerなども操作ができ、通常運用で必要な操作は一通りできそうです。

f:id:kenta53682:20180419091311p:plain

 

ホストおよびクラスタ画面です。ホスト設定もほぼvSphere Web Clientと変わらない感じを受けました。

f:id:kenta53682:20180419165846p:plain

 

HTML5でサポートされていない機能は以下にまとまっています。

Functionality Updates for the vSphere Client

Contents LibraryやVCHAなどが操作できないようですね。

 

 

③VCSA 6.7はパフォーマンスが向上しているとのことです。どのようにパフォーマンス向上しているかというと、、、

 ・1秒あたりのvCenter操作で2倍の高速パフォーマンス
 ・メモリ使用量を3倍削減
 ・DRS関連の操作が3倍高速(パワーオン仮想マシンなど)

 

1点目についてはvSphere Web Client / vSphere Clientを触っていますが、「2倍も早いかー?」という感じです。重すぎてイライラすることはないですが、あまり期待しすぎない方がいいかもしれません 笑

 

 

④vSAN iSCSI TargetでのWSFCサポート

以前の私の記事で記載しましたが、vSAN 6.6.1まではvSAN iSCSI Targetでサポートされているクラスタソリューションは、Oracle RAC(物理)のみでした。

 

kenta-virtualization.hatenablog.com

 

vSAN 6.7ではvSAN iSCSI Targetとして、WSFCもサポートされるようになりました。

しかも、、、

WSFC can run on either physical servers or VMs.

の通り、仮想マシンに対してもサポートがされるようになりました!

 

これは試してみようと思います!

 

 

⑤vSphere ClientにvROpsのダッシュボード統合

vSphere ClientからvROpsのダッシュボード画面が確認できるようになったようです。

というわけで見てみましょう。

 

vSphere ClientでvROpsの画面を見るために、以下のことをやっています。

1) vROpsのデプロイ

2) vROpsのクラスタ作成とクラスタの起動

3) vROpsにおいて、vCenter ServerアダプタとvSANアダプタを設定

vCenterはvROpsの名前解決ができる必要があります。名前解決ができないと、vSphere Client上にデータが表示されません

 

3) が終わった後、vSphere Clientにログインすると下記の画面が表示されます。

おー。環境の概要が分かりますね!詳細はvROpsに飛ばないと分かりませんが、パッと問題が起きているかどうかはvSphere Clientで把握ができます。

詳細を見たい場合は「Quick Links」からvROpsに飛ぶような形になっています。

f:id:kenta53682:20180419164810p:plain

 

「Quick Links」からは赤枠の通り、vCenter以外にvSANの概要も見れます。一番下にはvROpsに飛ぶリンクもあります。

f:id:kenta53682:20180419165110p:plain

 

vSAN Overviewでは問題があるかどうかや、IOPs、スループット、圧縮や重複排除について見れるようです。

f:id:kenta53682:20180419165202p:plain

 

vSAN Cluster Viewでは、vsandatastoreの残り容量やLatencyなども確認可能です。

f:id:kenta53682:20180419165348p:plain

 

※下記の画像のようにvSphere ClientのvRealize Operationsの画面からvROpsをデプロイすることも可能なようです。ただ私の環境ではデプロイ先のクラスターやホスト選択画面でクラスター・ホストがなぜか表示されず先に進めませんでした。

証明書とか名前解決周りが原因かなと思うのですが、画面を見るのを優先したかったのでvROpsは今まで通りデプロイする方法を取りました。

 

vSphere Clientのホーム画面の左ペインから「vRealize Operations」に遷移し、「INSTALL」を実行

f:id:kenta53682:20180419102800p:plain

 

オンラインかオフラインかを選択。オフラインはvROpsのovaファイルを指定

f:id:kenta53682:20180419102940p:plain

 

vCenterの情報を指定して、接続テストを実行

f:id:kenta53682:20180419103820p:plain

 

デプロイ先のクラスタやESXiを選択する画面ですが、ここで先に進めず。。。

時間ができたら調査しようと思います。

f:id:kenta53682:20180419115257p:plain

 

  

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

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

Lenovo Converged HXシリーズ深分かりトレーニングを受けてみた

皆さまお疲れ様です。

最近日中は暑くて夜寒いなど、季節の変わり目で体調崩しやすい天気になっていますよね。

私も恥ずかしながら風邪を引いてしまい高熱が出たので、皆さまも体調には十分ご配慮下さい。

 

さて、本日はネットワールド主催の「Lenovo Converged HXシリーズ深分かりトレーニング」を受講したので、その感想などを記載していこうと思います。

 

 

◆そもそも Lenovo Converged HXシリーズとは?

Converged HXシリーズはLenovoのサーバーラインの1つ、いわゆるHCIのラインとなり、「Nutanixのアプライアンス」製品となります。

 

www3.lenovo.com

 

ただ「Converged HX」シリーズは世代が少し古く(第2世代)、2018年4月現在は「Think Agile HX」シリーズというのが新しい世代(第3世代)となっています。

 

www3.lenovo.com

 

「Nutanixアプライアンス」という位置づけですが、ハイパーバイザーとしては「Acropolis Hypervisor」(AHV)、「VMware vSphere」、「Hyper-V」が選択可能です。

 

私自身「Nutanixアプライアンス」という意味がいまいち分かりませんでしたが、なんということはなく、vSANのようなSoftware Defined Storage(SDS)機能をNutanixが提供している、ということです。

vSANはハイパーバイザーのカーネルに組み込まれているのに対し、Nutanixは各ハイパーバイザーホスト上にController VMという仮想マシンを立て、Controller VM仮想マシンのI/Oを受け、SSDやハードディスクに書き込みを行います。

下記がNutanixのイメージとなります。

 

f:id:kenta53682:20180418093503p:plain

 

 

ちなみに、SDSをvSANで提供するThink Agileシリーズもあります。

それがThink Agile VXシリーズです。気になる方はチェックしてみて下さい。

www3.lenovo.com

 

 

◆セミナーでやったこと

セミナーは下記内容を行いました。

Lenovo HXシリーズ 製品概要 (座学)

→そもそもNutanixとは何か?HXシリーズとは何か?などを座学で勉強しました。

 

Lenovo HXシリーズ Nutanixハンズオン

→座学を元に、Nutanix Prismという管理コンソールのハンズオンを行いました。コンテナ作成、VM作成、スナップショット取得、リモートレプリケーションなどを体験しました。


Lenovo XClarity ハンズオン

→Think Agile HXシリーズから、IMM2ではなくXClarity Controllerがサーバー管理モジュールとなります。ここではXClarityの座学 + XClarity Administratorのハンズオンを行いました。


Lenovo Network Switchハンズオン

→HXシリーズでは10Gbpsスイッチが必要となりますが、Lenovo製の10Gbpsスイッチのハンズオンを行いました。

 

 

◆セミナーの感想

HXシリーズは「Nutanixアプライアンス」ということもあり、サーバー構成のイメージがつきづらかったですが、本セミナー受講後はNutanixアプライアンスのイメージが持てるようになりました。

HCIに触れたことがない方で、特に既存物理サーバーでIBMLenovoを多く導入されている方は本セミナーを受講するとよい勉強となるかと思います。

 

話しは変わりますが、HXシリーズを採用してハイパーバイザーにvSphereを使うと、管理コンソールや製品の問い合わせ先が増えることにより、運用負荷が上がるのではないかと感じました。

せっかくNutanix使うならハイパーバイザーはAHVを使った方が管理コンソールがPrism 1つだけで済むので楽なのかな、と思った次第です。

(裏を返すと、ハイパーバイザーでvSphere使いたいならVXシリーズを採用した方がよいのではと感じました。)

 

さて、以下はセミナー受講前に私が疑問に思っていた技術的な内容を講師に質問したものとなります。参考にして頂ければと思います。

 


【質問】Controller VMのサイジングについて、ディスクパフォーマンスが出ない時、CVMのCPU・メモリリソースを上げればディスクI/Oが上がるのか?
【回答】ディスクI/Oを上げるのは基本的にNUTANIXのノード追加で対応。CVMはメモリサイズの変更が可能で、vCPUやディスクは固定。メモリについては最小の16GBから始め、管理ノード数が増えれば増やす方針となる。

 

【質問】Controller VMのディスクの実態はどこに保管されているのか?NUTANIXコンテナレイヤーで動作しており、vSphere等からは見えないのか?またはすべてメモリで稼働しているのか?
【回答】Controller VMはAHVやESXiが導入されるM.2 SSDのブート領域に保管される。

 

【質問】ハイパーバイザーをインストールする領域はどこになるか?またその冗長性の担保はどうなっている?
【回答】HXxx20シリーズはHXシリーズの第3世代となり、M.2 SSD(128GB)にハイパーバイザーをインストールする。M.2 SSDはミラー構成に対応しており、M.2 SSDを2つ搭載して冗長構成とする。

 

【質問】vSANだとvSphere Web ClientからFTT=1以上の仮想マシンのデータ複製状況が分かるが、NUTANIXだと分かるのか?
【回答】複製完了までの時間程度は分かるかもしれないがvSANのように仮想マシンがどのディスクに書き込まれているかまでは分からない。分からない、というよりどのディスクに書き込まれるかまで意識しなくてよい思想で作られていると思われる。

 

【質問】vSANのFTT(いくつのホスト障害まで許容するか)といった概念はNUTANIXではあるのか?
【回答】NUTANIXではRF(Replication Factor)という単語になる。RF2 or RF3が選択できる。かつ、RF2 or RF3は「コンテナレベルで設定」する。従って、vSANの仮想マシンレイヤーの設定よりも低いレイヤー(=データストアレイヤー)での設定となる。また、Erasure Codingや重複排除等も可能。

 

【質問】vSphere(やHyper-V)の場合、PrismとvSphere Web Client(SCVMM)との住み分けはどのように行うか?仮想マシンコンソールの確認、リソース(CPU・メモリ・ネットワーク)の変更、クローン作成、スナップショット取得は可能だった。
【回答】仮想マシン操作、仮想ネットワーク操作はvSphere Web Clientから行い、コンテナ、DRへのレプリケーション、ノード追加はPrismから行う。基本的に、AHVでない場合はSDS周りの設定をPrismで行う形となる。

 

【質問】vSphereの場合、VMを作るのはPrismから?vSphere Clientから?
【回答】1つ前の質問で回答した通り、仮想マシンはvSphere Web Clientから作成した方がよい。

 

【質問】仮想スイッチの構成はどういった構成が一般的?
【回答】お客様のシステム構成によるため回答できない。

 

【質問】10Gbps NICをCVM通信専用にする構成は一般的なのか?
【回答】ノード数が増えれば10Gbps NICをCVMの通信専用にする構成はあるが、ノードが少ない場合はトランクした10Gbps NIC内にCVMやその他サービス通信を通す方が一般的。

 

【質問】NUTANIXではvSANと異なり、SSDもデータストア容量の一部となっていると聞いたが正しいか?(vSANはSSDはRead/Write Chache領域のみとして使用され、データストア領域としては使用されない。)
【回答】正しい。SSD・HDDへの階層化された書き込みを行う。データ書き込みはまずSSDに行われる。OSやアプリケーションレイヤーから見たとき、SSDに書込みが行われたらWrite I/Oは完了となり、SSD→HDDへのデータ書き込みはCVMが行う。

 


【セミナーメモ】
◆◆◆Lenovo HXシリーズ 製品概要◆◆◆
①NUTANIXコンテナはNFSデータストアとしてESXiにマウントされる。
②VLANはタグVLANで行う。
③XCC(IPMIポート)はCVMと疎通できるように構成する必要がある。
④CVMに障害が起きた場合、他のホストのCVMを経由してデータの書き込みを行うようになる。
クラウドコネクトはクラウドにバックアップを取るだけ。バックアップデータからクラウド上にVMを復旧することはできない。
Lenovo初期デプロイメントサービスを利用した場合の構築は下記の通りとなる。
 1) HWおよびNUTANIX(クラスタ作成)はLenovo対応
 2) ハイパーバイザー導入もLenovo対応
 3) vCenterは「Base」だとついておらず、「Advanced」だと初期構築のみ行われる

 


◆◆◆Lenovo HXシリーズ Nutanixハンズオン◆◆◆
①AHVで新規にOSを作成する場合、Nutanix Virt IO Mediaが必要。これがないとSCSIドライバーがないためディスクが見えない。
→NUTANIX Support PotalよりDLする。
②PRISMでのVMクローンはスナップショットからクローンをかけることも可能。
③Metro AvailabilityはvSphereのみ対応。
④システム全停止順序 CVM以外のVMを落とす→Nutanixクラスタを終了する(任意のCVMにログインし、停止)→各CVMを停止→ハイパーバイザー停止 (※起動は逆)

 


【参考サイト】
①NUTANIXバイブル http://nutanixbible.jp/

Lenovo HX Series Best Recipe https://support.lenovo.com/jp/ja/solutions/ht503607
HXシリーズではサポートされているファームウェアのバージョンが決まっており、その時に参照するサイト。最新版にすると動かなくなる可能性もある。

③NUTANIXデモ環境 https://demo.nutanix.com

 

 

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

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

vSANやるぞー!(13)-vSANをiSCSIターゲットに①

皆さまお疲れ様です。
今回はvSANデータストアをiSCSIターゲットとして公開する機能について紹介したいと思います。

 

NUTANIXでも同じ機能が実装されていますよね。

HCIはCPUやメモリ容量に比べてディスク容量が大きくなる傾向にあると感じてはいるので、ディスクを使い倒すために実装されたのですかね。エンドユーザー様の事例を聞いてみたいところではあります。

 

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

次:vSANをiSCSIターゲットに② (準備中)

 

 

vSANデータストアはvSAN Clusterに所属する仮想マシン用のvsanDatastore提供が主目的ではありますが、vsanDatastoreの一部を別LUNとして切り出してiSCSI Targetとして公開する機能も有しています。

 

ただこのiSCSIですが、vSAN6.6.1の時点では物理サーバーに対してのみしか公開をサポートしていません

また、使用用途はStorage Hubの「iSCSI Target Usage Guide」に記載された用途に限定されます。

主にクラスタリングの用途が記載されていますが、iSCSI Target Usage Guideをざっくりまとめると、、、

 

・物理サーバーでのOracle RAC構成は対応

・WSFCやSQL Server Always On Failover Cluster Instanceは非対応

・ESXiでの使用は非対応

・ハードウェアHBAは非対応

 

などの条件があるようです。シェアードナッシングな高可用性ソリューションは対応しているものの、共有ストレージが必要なソリューションはOracle RACくらいしか対応していないようです。

 

また、物理サーバーでもサポートされているOSは下記の通りとなります。

Windows 10、Windows 2016、2012 R2、2012、2008 R2、2008
RHEL 7、RHEL 6、RHEL 5
SUSE® Linux Enterprise Server 12、SLES 11 SP4/SP3/SP1

 

下記は少し古い記事ですが、日本語で分かりやすかったです。

vSAN 6.5 iSCSI デバイスを使用するためのベスト プラクティス

 

ESXiで使えるようになれば、仮想のOracle RACやWSFCのデータをiSCSI上に置く、などができて利用の幅が広がるのかな、と感じました。

 

というわけで、今回は一旦ここまで。

次回、iSCSIターゲットとして公開する手順を書こうと思います。

 

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

 

vSANやるぞー!(12)-Erasure Coding

皆さまお疲れ様です。
これまでのvSANの記事では障害時の挙動やメンテナンスモードの挙動を見てきましたが、本日からはvSANの少し踏み込んだ機能についてブログ記事にしてゆこうと思います。

 

まず、1発目がErasure Coding(イレージャーコーディング)となります。

 

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

次:vSANをiSCSIターゲットに①

 

Erasure CodingはvSAN 6.2から使用できるようになった機能で、vSANにおけるRAID5・RAID6を実現する(実データのフラグメント+パリティをESXiホスト跨ぎで保存する)機能です。

 

vSAN 6.1まではvmdkの冗長化方式はRAID1に相当するvmdkの多重化しか選択肢がありませんでした。従って、仮想マシンデータを冗長化するためには最低でもvmdkの2倍(3重化なら3倍)のディスク容量が必要でした。

【RAID1】 FTT=1

f:id:kenta53682:20180329190328p:plain

 

 

vSAN 6.2以降ではRAID5・6相当の冗長化方式が利用できるようになり、冗長性を担保しつつもデータ容量をRAID1方式よりも抑えることが可能となりました。

 

【RAID5】 FTT=1 ※RAID1(160GB)に比べて33%データ消費量を削減

f:id:kenta53682:20180329191403p:plain

 

 

【RAID6】 FTT=2 ※RAID1(240GB)に比べて50%データ消費量を削減

f:id:kenta53682:20180329192051p:plain

 

 

但しディスク容量が削減できる一方で、例えばWrite I/O時に追加でRead/Write I/Oが発生するなどRAID5 or RAID6はI/Oが増大します

容量とパフォーマンスはトレードオフの関係と考えて頂ければと思います。

 

※I/O増大については下記の記事が大変参考になりました。

【参考】Virtual SAN – RAID-5/6 | over a Radler

 

 

 ◆Erasure Coding利用時の考慮事項

仮想マシンの冗長性を担保しつつも、RAID1よりディスク容量を削減できるErasure Codingですが、使用に当たって考慮事項があります。下記に考慮事項をまとめます。

 

① vSAN All Flash Typeであること

② vSAN Advanced / Enterprise Editionが必要

③ オンディスクフォーマットバージョン3.0以上(=vSAN 6.2以上)が必要

④ vSANクラスタがストレッチクラスタでないこと

⑤ RAID5はESXi4台以上、RAID6はESXi6台が必要

⑥ RAID5ではFTT=1、RAID6ではFTT=2となり、Erasure CodingではFTT=3に設定することは不可

 

【参考】RAID 5 または RAID 6 の設計に関する考慮事項

 

先に記載した通りErasure CodingではI/Oが増大しますが、増大するI/OをものともしないAll Flash Typeが要件となっています。

 

 

◆Erasure Codingの設定

Erasure Coding用の仮想マシンストレージポリシー設定方法を記載します。

自宅の環境はAll Flashではないため(Nested ESXiなのでAll Flashにもできますが面倒くさいので割愛で笑)、ここではWeb上に落ちている画像を参考に設定方法を書いていきます。

f:id:kenta53682:20180329193350p:plain

 

上の画像のように設定は非常に簡単で、「Failure tolerance method」から「RAID-5/6」を選択し、FTTの値によってRAID5 or RAID6を設定する形です。そして、作成した仮想マシンストレージポリシーを仮想マシンに適用する、と。

・FTT = 1の場合:RAID5 になる

・FTT = 2の場合:RAID6 になる

 

 

さて、本日はErasure Condingについて説明をさせて頂きました。

All Flashが必須であることから、導入されるお客様は中~大規模なお客様が多いのかな?とも思いました。今度vSAN導入実績が多いSIerの人や、VMの中の人と会話する機会があれば導入実績を聞いてみたいですね。

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

vSANやるぞー!(11)-メンテナンスモード移行

皆さまお疲れ様です。

すっかり放置していたvSANの残りの記事を書いていきたいと思います。

 

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

次:Erasure Cording

 

vSANクラスタ配下のESXiをメンテナンスモードに移行する場合、下記のように3つの方法から1つを選択することになります。

f:id:kenta53682:20180311153752p:plain

 

まずはそれぞれの方式について説明をしてゆきます。

1) 「すべてのデータを他のホストに退避する」

メンテナンスモードにするESXiが持つデータを他のESXiにコピーするモードです。

下記の図のようなイメージとなります。

f:id:kenta53682:20180327215657p:plain

 

勿論この方式では全データを移動するため、

①メンテナンスモード移行までに時間がかる

②ESXiが3台構成では使えない (vmdkのコピー先ホストがないため)

、、、などの制約があります。②の制約があるためESXi3台構成ではこの方式は利用せず、2) or 3) を利用することになります。

 

 

2) 「他のホストからデータにアクセスできることを確認する」

FTT=1以上の仮想マシンで、メンテナンスモードにしないESXiに格納されたvmdkへのデータ経路が確保されていればデータ移行をしないモードとなります。

但し、FTT=0の仮想マシンがメンテナンスモードにするESXi内にあった場合は、vmdkが別ESXiにコピーされます

ESXiを一時的にメンテナンスする場合などに活用できるモードです。

下記の図のようなイメージとなります。

【FTT=0の場合】

f:id:kenta53682:20180327215927p:plain

【FTT=1の場合】

f:id:kenta53682:20180327220001p:plain

 

 

3) 「データを退避しない」

メンテナンスモードにする時、データコピーを行わないモードです。

FTT=0の仮想マシンが格納されたESXiをこのモードでメンテナンスモードにすると、仮想マシンにアクセスができなくなります。

個人的に、停電対応等でESXiを全台シャットダウンするときはこのモードでメンテナンスモードにすればよいかなと考えています。

f:id:kenta53682:20180327220105p:plain

 

 

それではここからメンテナンスモード移行の挙動を見てみましょう。

 

①Step 1 ESXi3台構成の時のメンテナンスモード移行

 1) 初期状態。vmdkはESXi#1とESXi#2にいます。

f:id:kenta53682:20180311162042p:plain

 

[すべてのデータを他のホストに退避する]

2) ESXi#1をメンテナンスモードにします。方式は「すべてのデータを他のホストに退避する」です。

f:id:kenta53682:20180311162146p:plain

 

3) ESXiが3台のため、下記のエラーが出てメンテナンスモード移行に失敗しました。

f:id:kenta53682:20180311162434p:plain

 

[他のホストからデータにアクセスできることを確認する]

4) 続いては「他のホストからデータにアクセスできることを確認する」にて行います。

f:id:kenta53682:20180311162620p:plain

 

5) メンテナンスモードへの切り替えが完了しました。

f:id:kenta53682:20180311162716p:plain

 

6) 仮想オブジェクトを見ると、「再構築なしで低下した可用性-遅延タイマー」という表示に変わっています。コンポーネントの状態も「なし」というステータスに変わりました。

f:id:kenta53682:20180311163327p:plain

 

7) CentOSは問題なく動作しています。

f:id:kenta53682:20180311162949p:plain

 

[データを退避しない]

8) それでは最後「データを退避しない」にてメンテナンスモードにします。

f:id:kenta53682:20180311163057p:plain

 

9) メンテナンスモードへの切り替えが完了しました。

f:id:kenta53682:20180311163220p:plain

 

10) 「仮想オブジェクト」の表示は「他のホストからデータにアクセスできることを確認する」と同じです。

f:id:kenta53682:20180311163353p:plain

 

11) CentOSは問題なく動作しています。

f:id:kenta53682:20180311163621p:plain

 

 

②Step 2 ESXi4台構成の時のメンテナンスモード移行

4台構成では3台構成時に確認できなかった「すべてのデータを他のホストに退避する」方式を確認します。

 

[すべてのデータを他のホストに退避する]

1) 初期状態。vmdkはESXi#1とESXi#2にいます。

f:id:kenta53682:20180311164032p:plain

 

2) ESXi#1をメンテナンスモードに移行します。方式は勿論、「すべてのデータを他のホストに退避する」です。

f:id:kenta53682:20180311162146p:plain

 

3) 下記のようにESXi 4台構成ではコンポーネントの再同期が行われます。

f:id:kenta53682:20180311164254p:plain

 

4) 「仮想オブジェクト」欄を見てみると、ESXi#4がWitnessとなり、ESXi#1→ESXi#3への再構成が行われていることが分かります。

f:id:kenta53682:20180311164434p:plain

 

5) 勿論、メンテナンスモード移行中もCentOSは稼働し続けています。

f:id:kenta53682:20180311164603p:plain

 

6) コンポーネントの再同期が完了し、ESXi#1がメンテナンスモードに移行しました。

f:id:kenta53682:20180311165102p:plain

 

 

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

NetScaler 12.56 ICA Proxyを構築してみた(2)

皆さまお疲れ様です。

今回はNetScalerのデプロイと初期設定を行います。

 

NetScalerは物理アプライアンス版と仮想アプライアンス版がありますが、今回使用するのはESXi用仮想アプライアンス版(Version 12.56.20)で、ESXiは6.5の画面となります。HAペアを構成することを前提とします。

 

◆NetScaler VPX OVFテンプレートのデプロイ

1) まずはCitrixのサイトよりNetScalerのOVFファイルをダウンロードします。

f:id:kenta53682:20180218213117p:plain

 

2) VCまたはESXi上にOVFテンプレートのデプロイを行います。(画面ではESXi上にデプロイをしていきます。)

f:id:kenta53682:20180218213234p:plain

 

3) 仮想マシン名を入力し、OVFファイルを指定して「次へ」を実行します。

f:id:kenta53682:20180218213355p:plain

 

4) デプロイ先のデータストアを選択し、「次へ」を実行します。

f:id:kenta53682:20180218213630p:plain

 

5) ネットワークラベル、プロビジョニングタイプ、デプロイ後の自動パワーオン設定を行い、「次へ」を実行します。

f:id:kenta53682:20180218213825p:plain

 

6) 「完了」を実行し、仮想マシンをデプロイします。

f:id:kenta53682:20180218214052p:plain

 

※NetScaler 12.56では既定で1本のNICが割り当てられています。マルチホーム構成とする場合はパワーオン前にNICを追加して下さい。(今回の検証ではNICは既定のまま1本とし、DMZ用のラベルを割り当てます。)

 

※ESXiホスト側にNested ESXiを可能とする「vhv.enable=True」設定を入れていると、起動時に下記の確認画面が表示されます。嫌な場合は、NetScalerのvmxファイルに「vhv.enable=False」を追記して下さい。

f:id:kenta53682:20180218214406p:plain

 

【参考】ESXiで仮想マシン起動時に「仮想 Intel VT-x/EPT を使わずに続行しますか? 」って聞かれた場合の対応 | あいしんくいっと

 

 

◆NSIP(NetScaler IP)の設定

デプロイが完了したら、NSIPの設定を行います。

1) NetScalerにvSphereコンソール接続します。下記画面のように、IPを設定する画面が出てくるため、NSIPを設定します。

f:id:kenta53682:20180218215330p:plain

 

2) NSIPのサブネットマスクを設定します。

f:id:kenta53682:20180218215412p:plain

 

3) NetScalerのデフォルトゲートウェイを設定します。

f:id:kenta53682:20180218215509p:plain

 

4) IP・サブネットマスクデフォルトゲートウェイを修正する場合は1~3を、OKであれば4を入力し、Enterを実行します。

f:id:kenta53682:20180218215642p:plain

 

5) 1~2分時間を置いてEnterを実行し、「login」画面が表示されたらブラウザを開き、NSIPに接続します。

f:id:kenta53682:20180218220433p:plain

 

◆NetScaler初期設定

1) ブラウザから「https://NSIP」へ接続します。(証明書の警告が出るので続行して下さい。)

 

2) NetScalerのログイン画面が表示されるため、ログインします。初期ユーザー名・パスワードは「User Name:nsroot」、「Password:nsroot」です。

f:id:kenta53682:20180218220639p:plain

 

3) ログインするとCEIP参加の確認画面が表示されます。ここではSkipを行います。

f:id:kenta53682:20180218220914p:plain

 

4) 初期設定画面です。まずはSNIP(Subnet IP)を設定します。HAペアで同じIPを設定して下さい。

f:id:kenta53682:20180218221120p:plain

f:id:kenta53682:20180218221300p:plain

 

5) 続いて、ホスト名・DNSサーバー・タイムゾーンの設定を行います。

f:id:kenta53682:20180218221357p:plain

f:id:kenta53682:20180218221517p:plain

 

6) 設定後、再起動を求められるので再起動を行います。

f:id:kenta53682:20180218221557p:plain

 

7) 再起動完了後、再度ログインを行い、ライセンスファイルをNetScalerにアップロードします。

NetScalerのライセンスはNetScalerのMACアドレスに紐づきます。下記3枚目の画像の青枠で囲ってある部分のIDでライセンス発行を行うよう注意して下さい。

f:id:kenta53682:20180218221906p:plain

f:id:kenta53682:20180218221946p:plain

f:id:kenta53682:20180218222056p:plain

ライセンスアップロード後、再起動が求められるため再起動します。

 

8) ライセンスをアップロードし、再起動が完了したら再度NetScalerにログインします。

ライセンスが正常に登録されると、「System→Licenses」でライセンスタイプや使用できる機能が一覧表示されます。

f:id:kenta53682:20180218222620p:plain

 

HAペアを構成する場合、以上の手順をスタンバイ機の方でも行って下さい。

これで初期設定は完了です。

 

 

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

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

NetScaler 12.56 ICA Proxyを構築してみた(1)

皆さまお疲れ様です。三連休いかがお過ごしでしょうか?

 

ブログ更新があまりできていませんでしたが、最近NetScaler 12.56を触る機会がありましたので、ICA Proxyを構築する流れをブログにしようと思います。NetScalerを題材にしたブログって日本ではあまり見かけないので、この記事が皆さまのお役に立てれば幸いです。

 

NetScalerってサーバーエンジニアが触る機会がない機器だとは思いますが、やれることが多いので覚えると楽しいですよ。ぜひ機会があれば触ってみて下さい。

 

構築にあたり、いくつかNetScalerで覚えておく単語があるので、この記事では単語のお勉強から始めましょう。

 

次:NetScaler 12.56 ICA Proxyを構築してみた(2)

 

①NetScaler Gateway

NetScaler GatewayはNetScalerの機能の1つの名称です。

クライアント端末がインターネットから社内のXenDesktop/XenAppなどに接続する際、NetScalerがゲートウェイとなってバックエンドサーバー・VDIとの接続を仲介するためこのような機能名となっているのだと思います。

 

NetScaler Gatewayでは大きく2種類の接続パターンがあります。

1つはNetScaler Gateway用のプラグインを使う方式、もう1つはNetScaler Gateway用のプラグインが不要な方式です。それぞれの接続方式について簡単にまとめてみます。

 

f:id:kenta53682:20180211235135p:plain

 

※詳しくは以下の記事も参照して下さい。

kenta-virtualization.hatenablog.com

 

 

②ICA Proxy

NetScaler Gatewayの有する機能の1つです。その名の通り、NetScalerがICA画面転送通信のリバースプロキシとして動作する機能です。

今回のブログのメインディッシュとなる機能です。

 

 

③Load Balancing

Load BalancingはNetScalerの機能の1つです。NetScaler Gatewayと同列にあると思って下さい。

名前の通りバックエンドサーバーへの負荷分散 を行う機能です。今回のブログではStoreFrontを負荷分散するときに使用します。

 

 

④Virtual Server

サーバーエンジニアにはあまり馴染みがないかもしれませんが、NetScaler GatewayやLoad Balancing用のVirtual IP(VIP)を提供する仮想的なサーバーと思って下さい。

NetScaler GatewayやLoad Balancingでは複数のVirtual Serverを作ることが可能です。

 

Virtual ServerにはVIPが1つ紐づき、クライアント端末は接続目的に応じて適切なVirtual Serverにアクセスします。(例えば、VDIに接続する場合はICA Proxy用NetScaler Gateway Virutal Serverなど)

 

 

⑤NSIP・SNIP・VIP

NetScalerでは大きく3つのIP種別があります。

1つめはNetScaler IP(NSIP)、2つめはSubnet IP(SNIP)、3つめはVirtual IP(VIP)の3つです。それぞれどのようなIPかを下の表にまとめてみました。

 

f:id:kenta53682:20180211233113p:plain

 

NetScalerはDMZに導入されることが多くFirwall申請がついて回ると思います上記の表を参考に、どのIPをソースとするかきちんと把握しておきましょう

 

 

⑥Secure Ticket Authority(STA)

社内でXenDesktop/XenAppを利用する場合、クライアント端末がStoreFrontにアクセスしてICAファイルをダウンロードし、ICA通信を開始します。このICAファイルにはVDAのアドレスやICAポートが記載されており、記載されたアドレスのVDAに対して画面転送通信を開始する流れとなっています。

 

ただインターネットから接続するICA Proxyの場合、ICAファイルにVDAのアドレスが記載された状態は非常に危ないですよね?通信を盗聴された場合、VDAのアドレスが丸裸になってしまいます。

 

ICA ProxyではSTAという機能を利用し、ICAファイルのVDAのアドレスをランダムな文字列にすることでVDAのアドレス流出を回避する仕となっています。

 

STAのフローは以下の図の通りです。

①・②ユーザーの新規接続時(①)、NetScalerはSTAサーバー(=Delivery Controller)に対してSTAチケット発行要求を行います。(②)

③STAサーバーはNetScalerに対してSTAチケットを発行します。STAチケットにはランダムな文字列が記載されています。

④クライアント端末はNetScalerからICAファイルをDLします。ICAファイル内にはSTAチケットの番号が記載されています。VDAのアドレスは記載されていません

⑤クライアント端末はICAファイルを元に接続を開始します。

⑥NetScalerはSTAチケットの番号を元に、どのVDAへ接続すればよいかSTAサーバーに照会します。

⑦STAサーバーは照会結果をNetScalerに返却します。

⑧NetScalerは照会結果を元にVDAへ接続を開始します。

 

 

f:id:kenta53682:20180211220550p:plain

 

STAとは上記のようなICAファイル内のVDAアドレスの暗号化を行う仕組みを提供する機能と覚えておいて下さい。

 

 

⑦Session Policy / Session Profile

NetScaler Gatewayを構成するときの設定の1つです

 

例えばICA ProxyではSession ProfileでStoreFrontのアドレスを設定します。ここで、接続元のクライアントソフトウェアがネイティブReceiverであればストアサイト、ブラウザであればReceiver for Webと分けたい要件がでてきたとしましょう。そんな時はSession Profileでまずストアサイト用のProfileとReceiver for Webサイト用のProfileを分けます。

 

そしてSession Policyにより、どんな時にSession Profileを適用するか設定します。例えばSession PolicyでUser-Agentを元にCITRIXRECEIVERが含まれていたらストアサイトへ、含まれていなかったらReceiver for Webへ、という設定を行います。

 

Session Policyに設定されたポリシーに合致した場合、対応するSession Profileを適用する流れとなります。これは後の記事で設定を載せますのでそこでイメージを持って頂ければと思います。

 

 

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

次の記事も近日中に投稿しますのでお待ち下さい。