仮想化エンジニア奮闘記

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

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を適用する流れとなります。これは後の記事で設定を載せますのでそこでイメージを持って頂ければと思います。

 

 

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

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

vSANやるぞー!(10)-vSAN障害時の挙動(ホスト障害時)②

皆さま、明けましておめでとうございます。

 

12月は1カ月間まるまる更新ができておらず申し訳ありませんでした。

仕事が忙しく、更新をしている暇がありませんでしたが、失踪したわけではないのでまた今月から記事を投稿してゆきます。12月はちょうどXenApp 7.15を触っていたので、vSANの記事が終わったらXenApp 7.15の記事を書こうと思います。

今年もよろしくお願い致します。

 

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

次:vSAN環境でのメンテナンスモード移行①(ESXi3台) 準備中

 

 

②Step 2 ESXi4台構成の時にFTT=1の仮想マシンのvmdkが保存されたホスト障害

ESXi 4台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #3をパワーオフします。(あえてvSANの動きだけを見るため、ESXi #1をパワーオフしてHAはさせません。)

f:id:kenta53682:20180211201237p:plain

 

結論:仮想マシンは稼働し続ける。ホスト障害に伴いDisk Groupが無効となり、ESXiが4台あるため、VSAN.ClomRepairDelayの分数が過ぎたらコンポーネントの再同期が行われる。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #3(10.17.101.73) に保管されています。

f:id:kenta53682:20180107094428p:plain

 

2) ここで、ESXi #3をパワーオフします。(9時50分です)

f:id:kenta53682:20180107095044p:plain

 

3) ESXi #3が(not responding)状態となりました。(9時51分) 仮想オブジェクトを見ると、「再構築なしで低下した可用性 - 遅延タイマー」と表示されており、コンポーネントの再同期が行われるまでの遅延タイマーが動いていることが分かる表記です。

f:id:kenta53682:20180107095222p:plain

 

4) CentOS7.3は稼働し続けています。

f:id:kenta53682:20180107095456p:plain

 

5) ESXi 4台なので、5分後にコンポーネントの再同期が行われました。(9時56分)

f:id:kenta53682:20180107095634p:plain

 

6) CentOS7.3のvmdkファイルがESXi #4に再同期されています。

f:id:kenta53682:20180107095804p:plain

 

7) vmdkの再同期が完了しました。

f:id:kenta53682:20180107100525p:plain

 

8) 復旧のため、ESXi #3をパワーオンします。

 

9) 既にESXi #4へのコンポーネントの再同期が完了しているため、コンポーネントの再同期は行われません。仮想オブジェクトは健全状態のままです。

f:id:kenta53682:20180107102235p:plain

 

それでは、次回はメンテナンスモード移行時の挙動を確認します。

 

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

vSANやるぞー!(9)-vSAN障害時の挙動(ホスト障害時)①

皆さまお疲れ様です。

今回からホスト障害時の挙動を確認してゆきます。

 

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

次:ホスト障害時の挙動②(ESXi4台、FTT=1)

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiをパワーオフして疑似障害を発生させます。

 

 

ESXiホスト障害では、障害発生後すぐにコンポーネントの再同期は行われず、

既定では障害発生後60分後に再同期が行われる仕様となっています。

60分の設定は下記KBに従って変更することが可能です。

https://kb.vmware.com/s/article/2075456

 

※システムの詳細設定⇒VSAN.ClomRepairDelay より変更可能です。(本環境では5分)

f:id:kenta53682:20171125110549p:plain

 

 

①Step 1 FTT=1の仮想マシンのvmdkが保存されたホスト障害

※FTT=0は実際の環境で構成しないと思うので、割愛します。

 

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #3をパワーオフします。(あえてvSANの動きだけを見るため、ESXi #1をパワーオフしてHAはさせません。)

f:id:kenta53682:20171125135943p:plain

 

結論:仮想マシンは稼働し続ける。ホスト障害に伴いDisk Groupが無効となり、ESXiが4台ないため、コンポーネントの再同期は行われない。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(10.17.101.71) と ESXi #3(10.17.101.73) に保管されています。

f:id:kenta53682:20171125141203p:plain

 

2) ここで、ESXi #3をパワーオフします。

 

3) ESXi #3が(not responding)状態となり、ディスクグループが見えなくなりました。

f:id:kenta53682:20171125141345p:plain

 

4) 仮想オブジェクトを見ると、「再構築なしで低下した可用性」と表示されています。

f:id:kenta53682:20171125141939p:plain

 

5) CentOS7.3は稼働し続けています。

f:id:kenta53682:20171125142101p:plain

 

6) ESXi 3台なので、コンポーネントの再同期は5分経っても行われません。

f:id:kenta53682:20171125142305p:plain

 

7) 復旧のため、ESXi #3をパワーオンします。

 

8) 仮想オブジェクトは特に問題なく「健全」状態となりました。ESXi #3復旧前後でvmdkに差分がなかったためか、コンポーネントの再同期の画面は6)と同じ状態でした。

f:id:kenta53682:20171125143119p:plain

 

 

それでは、次回はESXi 4台でホスト障害時の挙動を確認します。

 

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

vSANやるぞー!(8)-vSAN障害時の挙動(Capacity Disk障害時)②

皆さまお疲れ様です。

今回はESXi 4台でCapacity Disk障害時の挙動を確認してゆきます。ESXi 4台になっても、基本的にESXi 3台と同じ挙動を取ります。

 

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

次:ESXiホスト障害時の挙動①(ESXi3台、FTT=1)

 

 

②Step 2 ESXi 4台構成の時にFTT=1の仮想マシンが属するCapacity Disk障害

ESXi 4台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #1のCapacity Diskを仮想マシンから削除します。

f:id:kenta53682:20171125105536p:plain

 

結論:ESXi 3台の時と同じく、別Capacity Diskに対してコンポーネントの再同期が行われる。

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #1(C0:T2:L0) と ESXi #3(C0:T2:L0) に保管されています。

f:id:kenta53682:20171119132224p:plain

 

2) ここで、ESXi #1の仮想マシン設定を編集し、C0:T2:L0 の Capacity Disk を削除します。

f:id:kenta53682:20171119132606p:plain

 

3) ディスク削除直後はvSANのステータスが「再構築なしで低下した可用」でしたが、その後コンポーネントの再同期が行われ始め、「低下した可用性」に変化しました。

f:id:kenta53682:20171119132935p:plain

f:id:kenta53682:20171119133239p:plain

 

4) 再同期中です。ESXi #4に再同期が行われています。

f:id:kenta53682:20171119133339p:plain

 

「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。ESXi 3台の時もそうでしたが、Witnessもコンポーネント配置場所が変わっています。

f:id:kenta53682:20171119133716p:plain

 

5) CentOS7.3は勿論起動しています。

f:id:kenta53682:20171119133916p:plain

 

6) 再同期完了後、健全状態に戻りました。

f:id:kenta53682:20171119134208p:plain

 

以上の通り、Capacity Disk障害時はESXi 3台 / ESXi 4台で挙動に差は出ませんでした。

次回はESXiホスト障害を取り上げていきます。

 

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

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

vSANやるぞー!(7)-vSAN障害時の挙動(Capacity Disk障害時)①

皆さまお疲れ様です。

今回からCapacity Disk障害時の挙動を確認してゆきます。

 

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

次:Capacity Disk障害時の挙動②(ESXi4台、FTT=1)

 

今回もNested ESXi環境を利用し、親のESXi上でNested ESXiの仮想ディスクを削除して疑似障害を発生させます。

 

 

①Step 1 FTT=1の仮想マシンが属するCapacity Disk障害

※FTT=0は実際の環境で構成しないと思うので、割愛します。

 

ESXi 3台(すべて仮想マシン)、ESXi #1上にあるFTT=1の仮想マシンが稼働している状態で、ESXi #2のCapacity Diskを仮想マシンから削除します。

f:id:kenta53682:20171121205534p:plain

 

結論:仮想マシンは稼働し続ける。Cache Diskと異なり、Disk Group自体がエラーになるわけではないので、別Capacity Diskに対してコンポーネントの再同期が行われる。

 

 

1) 障害発生前の状態。CentOS7.3はESXi #1(10.17.101.71)上にいます。FTT=1のため、vmdkは ESXi #2(C0:T4:L0) と ESXi #3(C0:T2:L0) に保管されています。

f:id:kenta53682:20171119105102p:plain

 

2) ここで、ESXi #2の仮想マシン設定を編集し、C0:T4:L0 の Capacity Disk を削除します。

f:id:kenta53682:20171119105458p:plain

 

3) vSANのステータスが「再構築なしで低下した可用」というステータスになりました。(コンポーネントの再同期開始前)

f:id:kenta53682:20171119110531p:plain

 

4) Cache Diskと異なり、Disk Group自体は見えています。

f:id:kenta53682:20171119110842p:plain

 

5) 仮想マシンはもちろん稼働しています。

f:id:kenta53682:20171119110608p:plain

 

6) そうこうしている間に、コンポーネントの再同期が行われています。予想では同一ESXi(ESXi #2)の別Capacity Diskに対して優先的に再同期がかけられると思っていましたが、そういうわけではないようです。別ESXi(ESXi#1)のCapacity Diskに対して再同期がかけられています。

f:id:kenta53682:20171119111035p:plain

 

「障害前の状況」と「障害発生し、コンポーネントの再同期が行われた後の状況」を比べてみます。赤字が変わった部分です。

f:id:kenta53682:20171119111851p:plain

 

7) コンポーネントの再同期画面を確認し、ETAが7分であることと、ESXi #1に再同期がかけられていることを確認しました。

f:id:kenta53682:20171119111954p:plain

 

8) 再同期が完了した後の画面です。かつ仮想マシンストレージポリシーのコンプライアンスチェックも行っています。vSANオブジェクトはすべて健全となり、コンプライアンスステータスも準拠となりました。

f:id:kenta53682:20171119112347p:plain

 

Capacity Disk障害時は、Disk Groupが無効になるわけではないので、ESXi 3台の環境でもコンポーネントの再同期が行われます。ですので、復旧についてもゆっくり対応することが可能です。

 

勿論、本環境では仮想マシンは既にストレージポリシーのコンプライアンスに準拠しているため、Capacity Diskが復旧してもコンポーネントの再同期等は行われません。

 

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

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

祝!10,000 PV突破しました!

皆さまお疲れ様です。

今回は技術とは全く関係ないこのブログ自身の話を記載します。

 

 

タイトルにもある通り、

 

 

 

本日「仮想化エンジニア奮闘記」の累計PV数が10,000を超えました!ありがとうございます!

 

 

 

そして、今月の月間PV数も3,000を超えそうです。

 

f:id:kenta53682:20171116203949p:plain

 

 

↓の記事を参考にすると、脱ビギナーになりそうです!

PV数でわかるブロガー番付|あなたのブログはどのレベル? | ブログ収益 | ブログ部

 

 

、、、まぁ先月末~今月にかけてvForumがあったので、その影響でVMwareとかのワードに引っ掛かりやすかったのかなと思っていますが。

 

 

このブログを始めたのが2017年4月20日となりますが、早いもので半年以上続けられています。vExpert受賞を目指してスタートしたものの、今ではVMwareはもちろん、Citrixも、その他の製品も、私が気になったことを記事にさせて頂いており、楽しくブログ更新ができています。

 

最初は3日坊主になると思っていたのですが、継続できているのはPV数が増える(=皆さまにブログを見て頂いているという実感が持てる)からです。

 

技術ブログの性質上、答えが見つかればすぐ閉じられてしまい、リピート率が低いと思っていたのですが、Google Analyticsではリピーターが30%あったりと意外と何度か見て下さっている方もいらっしゃるようです。リピートありがとうございます。

 

引き続き、流行に乗り遅れず色々な情報を発信できればと思っています。

皆さま、引き続きよろしくお願い致します。

 

本日は以上となります。

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