仮想化エンジニア奮闘記

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

Citrix Receiver for Windows / Mac / ChromeBook / iOS / Androidの違い

Citrix環境へ接続する際、通常はCitrix Receiverを端末に導入します。

※StoreFrontでWebSocket接続を有効化してHTML5接続 (ブラウザ上でXenDesktop / XenAppを利用) する場合はReceiver導入不要です。

 

各Receiverで対応している機能も違うので、その違いをまとめます。

ちなみに、接続方式は次の通り呼びます。

 

ストア接続(ネイティブ):Citrix Receiverからアイコンをクリックして接続する方式

※ストアURLにてNetScaler Gatewayを指定したものをストア接続(ネイティブ / NSGW経由)と表記します

f:id:kenta53682:20170725213210p:plain

 

Receiver for Web接続:ブラウザ上でアイコンをクリックして接続する方式

※ブラウザでNetScaler Gateway経由で接続したものをReceiver for Web接続(NSGW経由)と表記します

f:id:kenta53682:20170725212826p:plain

 

以下ではお客様要件でよく使用する「ドメインパススルー」(StoreFront直接接続の場合)と「クライアント証明書認証」(NetScaler Gateway経由の接続の場合)に焦点を当てて比較をしてゆきます。

 

 

①Citrix Receiver for Windows

1)ストア接続(ネイティブ):対応 (ドメインパススルー対応)

2)Receiver for Web接続:対応 (ドメインパススルー対応)

3)ストア接続(ネイティブ / NSGW経由):対応 (クライアント証明書非対応)

4)Receiver for Web接続(NSGW経由):対応 (クライアント証明書対応)

※Receiver for Windowsドメインパススルーに対応しています。

ドメインパススルー用の設定は ↓ の記事を参照して下さい。

Citrix Receiver Configuration Checker - 仮想化エンジニア奮闘記

 

 

②Citrix Receiver for Mac

1)ストア接続(ネイティブ):対応 (ドメインパススルー非対応)

2)Receiver for Web接続:対応 (ドメインパススルー非対応)

3)ストア接続(ネイティブ / NSGW経由):対応 (クライアント証明書非対応)

4)Receiver for Web接続(NSGW経由):対応 (クライアント証明書対応)

Windowsに対し、Macではドメインパススルー対応はしていません 

 

 

③Citrix Receiver for Chrome (Chromebook専用)

1)ストア接続(ネイティブ):非対応

2)Receiver for Web接続:対応 (ドメインパススルー非対応)

3)ストア接続(ネイティブ / NSGW経由):非対応

4)Receiver for Web接続(NSGW経由):対応 (クライアント証明書対応)

ChromebookではCitrix Receiverのアプリはあるものの実態はブラウザ(Chrome)ベースで動くもののため、ストア接続は対応しておりません。

 

 

④Citrix Receiver for iOS

1)ストア接続(ネイティブ):対応 (ドメインパススルー非対応)

2)Receiver for Web接続:対応 (ドメインパススルー非対応)

※但しブラウザ上でICAファイルをクリックする動作が加わりUXはいまいち

3)ストア接続(ネイティブ / NSGW経由):対応 (クライアント証明書対応)

※クライアント証明書を配布するWebサーバーを指定する必要があります

4)Receiver for Web接続(NSGW経由):対応 (クライアント証明書対応)

 ※但しブラウザ上でICAファイルをクリックする動作が加わりUXはいまいち

 

 

⑤Citrix Receiver for Android

1)ストア接続(ネイティブ):対応 (ドメインパススルー非対応)

2)Receiver for Web接続:対応 (ドメインパススルー非対応)

3)ストア接続(ネイティブ / NSGW経由):対応 (クライアント証明書非対応)

4)Receiver for Web接続(NSGW経由):対応 (クライアント証明書対応)

 

 

Citrix Receiver for Linuxはあまり現場作業でも使用したことがないため省いています。

 

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

XenDesktopでServerOSをVDI利用する

みなさまお疲れ様です。

だいぶ間が空いてしまいましたが、今回もCitrixを記事にしてゆきます。

 

 

CitrixでVDIを提案する時、大きくは3パターンの提案があります。

①XenDesktop (Windows 10などのクライアントOSをVDIとして利用)

②XenDesktop Server VDI (Windows Server 2016などのサーバーOSをVDIとして利用)

③XenApp (SBCと呼ばれるサーバー共有型デスクトップ)

 

 

よく比較提案されるのは ① と ③ です。

①XenDesktop - Client OS の VDI

メリット:クライアントOSを使用するのでアプリケーション互換性が③よりも高い

デメリット:VDAライセンスや機器費用などコストが高い

 

 

③XenApp - SBC

メリット:①と比べてライセンスや機器費用が安く済む

デメリット:サーバーOS かつ 複数ユーザーが同時使用するのでアプリケーションの互換性がない場合がある(サーバーOS対応 / マルチユーザー対応 のアプリケーションである必要がある)

 

 

※VDAライセンスは下記のブログが非常に分かりやすいです。

VDI と Microsoft VDA ライセンス - (1) VDA の正しい理解 - 仮想化でプリセールスしてるSEの一日

 

 

お客様でもVDAライセンスを「高い」と感じられている方は結構いらっしゃいます。

そんな時の抜け道として②を提案することもあります。

 

②はWindows ServerをDatacenter Editionとして買うことで無制限に仮想マシンが立てられることから、Server OSをVDIと見立てて使おう、というものです。

実際にはVDAはいらないものの、代わりに Server CAL や RDS CAL が必要になってきます。(それでもVDAよりは安く済みます。)

 

とはいえデメリットもあります。下記にメリット / デメリットをまとめます。

 

②XenDesktop - Server OS の VDI

メリット:

1) サーバーOSを使用するが、マルチユーザー対応である必要がないのでアプリケーション互換性は③XenAppよりも高い

2) 機器費用は①XenDesktopと同じだが、ライセンスは①XenDesktopよりも安い。何よりVDAライセンスを購入しなくてよい

デメリット:

1) クライアントOSでないため、互換性がないアプリケーションはどうしてもある(特にビット数の違いなどから動かない等)

2) ③XenAppほどコストは安くならない

3) ①XenDesktopに比べて使用できる機能に制限がある

 

 

 

CitrixではサーバーOSをVDI利用する際にはVDAをコマンドラインでインストールします。下記の記事に使用できない機能も記載されています。(Personal vDiskなど。)

Server VDI (XenDesktop 7.14)

Install using the command line (XenDesktop 7.14 コマンドラインオプションの説明)

 

 

また、XenAppではVDAをインストールすると自動でデスクトップエクスペリエンスの機能を入れてくれたり、タスクバーのサーバーマネージャー等を自動で消してくれたりしますが、Server VDIでは上記の機能は入りません。UIをクライアントOSに近づけたい場合は別途デスクトップエクスペリエンスの機能を追加したり、GPO制御をするようにして下さい。

 

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

Citrix Receiver Configuration Checker

Citrix Receiver 4.5 から、Citrix Receiverに「Configuration Checker」という機能が追加されました。

最近Citrixを久々に触って「便利な機能だな」と思ったので共有します。

 

何の Configuration を Check してくれるかというと、「Single Sign-On」(以下SSO) 設定のチェックをしてくれます。

SSO は端末にログインしているユーザーの資格情報を使用してStoreFrontにパススルー認証をかける機能です。ユーザーはクライアント端末にログイン後、XenDesktopやXenAppに接続するのに再度ログインせずに済むのでよく使われる機能です。

 

ただ、上記SSOができるためにはサーバー側・端末側にいくつか設定を入れる必要があります。Configuration CheckerはSSO用の設定が正しく入っているかをチェックしてくれます!べんりー!

 

 

SSO可能な構成とするには大きく下記の設定が必要です。

◆サーバー側

①StoreFrontの ストア or Receiver for Web の認証方式で「ドメインパススルー」が設定されていること

②Delivery Controller 側で StoreFront から送信されるXML要求を信頼できるように、「Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $True」コマンドを実行していること

 

 

◆クライアント側

③Receiver が「/includeSSON」オプション付きでインストールされていること(本オプションをつけないとSSO用のモジュールがインストールされません)

④Receiver を使用するユーザーの「インターネットオプション」にて、「信頼済みサイト」にStoreFrontのアドレスが登録されていること

⑤Receiver を使用するユーザーの「インターネットオプション」にて、「信頼済みサイト」の「レベルのカスタマイズ」へ遷移する。「ログインオプション」で「現在のユーザー名とパスワードで自動的にログインする」が設定されていること

 

 

◆Configuration Checkerの使い方

Configuration Checkerは下記の要領で使用します。

1) 通地領域アイコンのReceiverを右クリックし、「高度な設定」を実行

f:id:kenta53682:20170706202118p:plain

 

2) 「Configuration Checker」を実行

f:id:kenta53682:20170706202235p:plain

 

3) 「SSONChecker」にチェックを入れ「実行」をクリック

f:id:kenta53682:20170706202330p:plain

 

4) 下記のようにOK / NG を表示してくれる

f:id:kenta53682:20170706202458p:plain

 

今回私の環境ではReceiverを「/includeSSON」オプションなしでインストールしたので、「Single Sign-On とともにインストール済み」でエラーになっています。

 

これで端末でReceiverを上げた時に「ストアにアクセスできません」というエラーが出た時に切り分けがしやすくなりましたね。

但し、上記ではサーバー側の②(Delivery ControllerでXML要求を信頼する)はチェックしてくれないので、Configuration CheckerでOKでもストアにアクセスできない場合は②設定を疑ってみて下さい。

 

Citrix公式ドキュメントはこちらです。(Receiver for Windows 4.7のもの)

構成チェッカーを使用してSingle Sign-Onの構成を検証する

 

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

 

 

VVolsを試してみた(1)-VVolsの概要と構成

みなさんお疲れ様です。

Unityも使える環境なので今回から数回VVolsの記事を記載していきます。

なお、VVolsの記事はVMware社からもいくつか出ています。下記を読むとより理解が深まると思います。

 

【参考記事1】

VMware vSphere Virtual Volumes (VVols) のご紹介 - Japan Cloud Infrastructure Blog - VMware Blogs

 

【参考記事2】

VMware vSphere Virtual Volumes に対するHP 3PAR StoreServの実装 - Japan Cloud Infrastructure Blog - VMware Blogs

 

 

【VVolsとは?】

VVolsはvSphere 6.0系から搭載された機能です。

簡単に言うと「ストレージの管理負荷を下げるためにvSphere側からAPI経由でストレージを管理しようぜ」的な機能かと思います。

 

通常、vSphereは接続されているストレージのことなど知ったこっちゃないのですが、ストレージが提供するAPIアクセスポイントに対してAPIを叩くことで、ストレージの情報をvSphere側が認識したり、vSphere側からストレージに実行命令を投げたりすることができます。(この機能はVAAIと言いますが、VVolsはVAAIをより進化させた機能かなと思っています。)

 

vSphere 6.0が出た時に「仮想マシン毎にSnapshotが取れる」なんて宣伝を聞いて「おぉすげー!」と驚いたのが懐かしいです。

 

 

【VVols機能利用の要件】

VVols機能利用のためには大きく下記3点が必要となります。

①ストレージがVVols機能をサポートしていること

②VASAプロバイダー(後述)がストレージに内臓されているか、VASAプロバイダー用の仮想マシンが稼働していること

③ライセンスがvSphere Standard以上であること

 

個人的にvSphereのライセンスはStandardでもOKなのが意外でした。

 

 

【VVols概要】

VVolsの理解のためには「VASAプロバイダー」「プロトコルエンドポイント」という2つの用語を知っておいて下さい。

 

1) VASAプロバイダー

ストレージに実装された機能をvSphere側から把握するためのアクセスポイント。

vCenterからストレージAPIを叩くときに使用する窓口。

VASAプロバイダーは仮想マシンとして提供されることもありますし、ストレージに内臓されていることもあります。(私が今まで触った中では、IBM/Lenovo Storwize系は別途仮想マシン構築が必要、3par・Unityはストレージ内臓でした。)

 

2) プロトコルエンドポイント

ストレージ側でESXiとのI/Oを行うアクセスポイント。

FC・iSCSINFSのストレージ側窓口。

 

では実際にVASAプロバイダーやプロトコルエンドポイントがどのように構成されるかを下記の表にまとめます。VASAプロバイダーが ①ストレージ内臓パターン と ②仮想マシン別立てパターン の2パターン紹介します。

 

 

①ストレージ内臓パターン

f:id:kenta53682:20170704221403p:plain

 

 

 

仮想マシン別立てパターン

f:id:kenta53682:20170704221450p:plain

 

恐らくどのエンジニアもVASAが仮想マシンで別立てされると専用の可用性設計等が増え面倒だと感じるはずです。ストレージと組み合わせてVVolsをお客様に提案する場合は、3parやUnityなどVASAプロバイダーがストレージに内臓されているベンダーのものを選ぶのが得策かと思います。

 

次回はVVolsについてUnity と vSphere Web Clientの画面を見ながら解説をしてゆこうと思います。

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

ストレージの互換性確認に利用するサイト

みなさまお疲れ様です。

久しぶりの更新となりますが、本日は短めに行きます。

 

お客様既存環境に新規ストレージを導入するとき、多くの方が既存サーバーや既存スイッチとの互換性/相互運用性を気にされると思います。

本記事ではそんな時に利用できるサイトをまとめたいと思います。

 

 

①HP - SPOCK (Single Point of Connectivity Knowledge)

※3par, MSA 等 とサーバ・HBA・SANスイッチの互換性が確認できます。

※SPOCK利用にはHPアカウント登録が必要となります。

※Webベースで調査が可能です。

※HPが買収したNimbleストレージの相互運用性情報も提供されています。

Chromeだと証明書エラーが出ますが気にせず進めて下さい。

 

②IBM - SSIC (System Storage Interoperation Center)

※DSシリーズ, Storwize 等 とサーバ・HBA・SANスイッチの互換性が確認できます。

※Webベースで調査が可能です。

 

 

③Lenovo - Lenovo Storage Interoperability Links

※Storwize V3700 V2 等 とサーバOS・HBAの互換性が確認できます。

※Storwize V5000やV7000などの一部機器はIBMのSSICにリンクされています。

Excelで情報が提供されています。

 

 

④Dell - Storage Compatibility Matrix - SC Series, PS Series, and FS Series

Dell EMCのうち、Dellが元々手掛けていたストレージ(SCシリーズ、EqualLogic PS/FSシリーズ) とHBA・SANスイッチの互換性が確認できます。

※PDFで情報が提供されています。

 

 

⑤EMC - E-Lab Interoperability Navigator

Dell EMCのうち、EMCが元々手掛けていたストレージ(VMAX, VNX, VNXe, Unity) とサーバ・HBA・SANスイッチの互換性が確認できます。

※E-Lab利用にはDell EMCアカウント登録が必要となります。

 

 

⑥NetApp - IMT (Interoperability Matrix Tool)

FASシリーズとサーバOS・HBAの互換性が確認できます。

※IMT利用にはNetAppアカウント登録が必要となります。

 

 

互換性/相互運用性を確認するサイトはほぼアカウント登録が必要なので事前にアカウントを作っておくとよいかと思います。

上記以外でもストレージベンダーはありますが、製品数も少ないと思いますので販売店に確認したりストレージベンダー自身に確認したりすればよいかと思います。

 

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

UNCパスのファイルをdel処理する時は気をつけろ!

みなさまお疲れ様です。

最近は思いついたものを色々記事にしており、仮想系の記事が少ないですがすみません。

 

今回は Windowsバッチ や Powershell 等でUNCパスのファイルをdel処理で削除する際に気をつけた方がよいことを記載します。さっそく結論です。

pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理を入れること。エラーになっていた場合は、del処理を行わないこと。

 

例えば下記のような2つの処理を行っているスクリプトを考えてみます。

①ログなどのファイルをリモートのファイルサーバーにコピーする

②ログがたまり続けないように一定期間経過したファイルサーバー上のファイルは、スクリプト実行サーバーからローテーション処理をかける

 

f:id:kenta53682:20170618125415p:plain

 

forfilesでUNCパスはサポートされていないため、「pushdしてdel処理を行う」ことを考えるかと思います。

が、上記のスクリプトだと、pushdに失敗した時の条件分岐が入っていないので、pushd失敗時はデフォルトの作業ディレクトリで削除処理が走ります。

 

タスクスケジューラでは作業フォルダを指定しない場合、「C:\windows\system32」が作業フォルダとなります。(taskschd.mscがある場所だからだと思います。)

 

もうお分かりかと思いますが、pushd失敗時 (ファイルサーバーがシャットダウンされている場合など) はスクリプト実行サーバーの「C:\windows\system32」配下のファイルが削除される処理が走ります これはやばい笑

 

このような悲しいことが起きないよう、少なくとも①だけは必ず守りましょう!

①pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理(if)を入れる

②タスクスケジューラの「開始(オプション)」にて作業ディレクトリを明示的に指定する (or スクリプトの最初で必ず作業ディレクトリにcdする)

③forfilesでdel処理を行う場合、del対象の名前や拡張子が決まっている場合、「/m [ファイル名]*.[拡張子] のようにマスクを入れる

 

ちなみに、なぜこれを記事にしているかというと直近で私が「system32配下のファイルが削除される」問題を引き起こしてしまったからです。

OSリストアが必要となる大問題なので、スクリプト作る人もレビューする人も絶対条件分岐が入っているか意識して下さい。

SANスイッチの基本的な内容を覚えよう!

みなさまお疲れさまです。

本日はSANスイッチのあれこれについて共有します。本記事はSAN初級者向けの人をターゲットにした記事となります。

 

「SAN触ったことないけどなんだか難しそう!」って思っている方、僕もそうでした!

ですが、実はSANはポイントを押さえれば難しくありません!

むしろネットワークの方が色々機能があってよっぽど難しいです 笑!

 

 

本記事は下記のトピックでSANスイッチの記載をしてゆこうと思います。

①SANってどんな機器が必要なの?どう繋ぐの?

②SAN構築にあたって考えることって?

 

 

①SANってどんな機器が必要なの?どう繋ぐの?

SAN接続には大きく「サーバー」「SANスイッチ」「ストレージ」という3つの機器が関わってきます。

 

多くの方が、SANと聞くと光ファイバーで機器間が繋がっているイメージを持たれていると思いますが、実際そのイメージは当たっていて、SANでは光ファイバーケーブルを使用して8Gbps(最近では16Gpbs)等でデータ転送を行います。

 

光ファイバーで機器間を接続するために、サーバー・ストレージに「Host Bus Adapter」というFibre Channel Protocolをしゃべれるインターフェースを搭載する必要があります。PCI-Expressを使ってマザーボードと接続される、簡単に言うとSANにおけるNICの立ち位置のインターフェースです。

 

f:id:kenta53682:20170613215950p:plain

上記HBAの赤枠部分に光ファイバーケーブル(NICでいうところのLANケーブル)が挿されるわけですね。

 

サーバー側は上記のHBAを別途購入し、ストレージ側はSAN対応のモデルを買うと標準で上記のHBAがついてきます。

 

ここで1点注意事項です。サーバーHBA・SANスイッチ・ストレージHBAでは先の画像のように光ファイバーを接続できる口を搭載した状態で出荷されません。光ファイバーでつなぐためには、下記のように光ファイバーの口を別途購入する必要がある場合がほとんどです。その光ファイバーの口となるモジュールを「SFP+トランシーバーモジュール」と呼びます。(1個4~5万するので、機器発注する際は絶対に忘れないで下さい。)

f:id:kenta53682:20170613220128p:plain

 

従って、サーバー・SANスイッチ・ストレージ間は簡単に書くと下記のように接続されます。(下記は簡単に書いた図です。物理構成は②を参照して下さい。)

f:id:kenta53682:20170613220946p:plain 

なお、光ファイバーでサーバ・ストレージ間を直接接続することがサポートされている機器もあるようです。いわゆるDirect Attached Storage(DAS)なのですが、今回はSANの記事なので扱いませんし、実務でもDASをするなら安価なSASで接続することがほとんどかなと思います。(DASするくらいのお客様はコストを抑えたい、という気持ちが強いと思いますし。)

 

 

 

②SAN構築にあたって考えることって?

SAN構築にあたり考えることは多くありません。

基本は「冗長化」「ゾーニング」という2点を考えればよいです。

 

1) SANの冗長化

SANはサーバーとデータが配置されているストレージまでの経路を提供するものなので、機器障害時にサービス提供を維持できるように冗長化について考えなくてはいけません。

 

SANの冗長化については「物理的に異なる経路のパスを複数作る」という鉄則があります。この鉄則に従って下さい。

 

SANスイッチはStandaloneのSANスイッチが2台ある状態として導入することが推奨されています。この時、お互いのSANスイッチは連携をせず、物理的に異なるパスを作ります。この時、それぞれの経路をFabric A / B のように「Fabric」という単語で表します。

サーバーやストレージのHBAは多くが2口以上あるものなので、Standalone 2台のSANスイッチそれぞれに足を伸ばすことで「物理的に異なる経路のパスを複数作り」冗長化する形となります。

 

f:id:kenta53682:20170613223845p:plain

 

サーバー側ではマルチパスドライバーがインストールされている必要があり、通常時はストレージへのアクセスに経路①、経路②を負荷分散しながら利用します。経路①に障害が発生したら経路②のみでストレージへのアクセスを継続して提供する形となります。

 

設定は2台のSANスイッチに入れる必要がありますが、「1台に間違った設定を入れてストレージにアクセスできなくなった」のようなリスクを回避することができます。

 

 

2) SANのゾーニング

NWスイッチのVLANと似た機能として、SANスイッチでは「ゾーニング」という機能を持っています。ゾーニング設定を行うことで、ストレージにアクセスできるホストを絞ることができます。セキュリティ要件や問題発生時の影響を最小限にとどめるためにゾーニング設定を行います。

 

SANのゾーニングについては「1イニシエータ 1ゾーン」という鉄則があります。この鉄則に従って下さい。

 

ここでいう「イニシエータ」とはサーバーのHBAポートのことを言います。例えば下記の図のように、サーバーHBAポート毎にゾーンを分けるのが鉄則となります。

 

f:id:kenta53682:20170613232158p:plain

 

このゾーンはHBAポート毎に割り当てられるWWPN(World Wide Port Name)という値を元に設定します。WWPNはNICでいうMACアドレスと思って下さい。

 

サーバ側のWWPN・ストレージ側のWWPNを1つのゾーンに含めることで、あるサーバーHBAからアクセスできるストレージを限定することができます。

 

通常、ストレージは2コントローラあると思いますので、それを踏まえると実環境では下記のように冗長化 + ゾーニングが設定されていることが多いです。下記の図を見て頂いても、「1イニシエータ 1ゾーン」の鉄則が守られてると分かるかと思います。

ZoneA:Server HBA① WWPN、Controller A HBA① WWPN、Controller B HBA① WWPN が含まれる

ZoneB:Server HBA② WWPN、Controller A HBA② WWPN、Controller B HBA② WWPN が含まれる

 

f:id:kenta53682:20170613234805p:plain

 

実はSANスイッチ構築にあたり独自で考えることは多くなく、基本的には鉄則に従って構築を行うことが重要です。

 

SANスイッチはIBM・HP・富士通・日立・Brocadeなど各ベンダーから製品が出ていますが、多くの製品がHWは各ベンダー固有のものを使いつつも、OSはBrocade社のFabricOSが使われています。Brocade社はSAN界隈ではよく出てくる会社名なので覚えておくとよいと思います。

 

なおBrocade社は下記SlideshareのようにSANに関する記事を多く公開しています。

参考にしてみて下さい。

 

【参考サイト】Brocade Slideshare (日本語記事も数多くあります!)

 Brocade presentations channel

 

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