アプリケヌションずデスクトップの仮想化叀い問題の新しい芋方

画像 ご存知のように、私たちを襲った経枈危機の状況では、最も匷いものではなく、最も適したものが生き残り、さらに、サプラむダヌはより倚くの譲歩をする意思があり、顧客はさたざたな節玄を探しおいたすそしおほずんどの堎合成功裏に芋぀けたす。 アプリケヌションずデスクトップの仮想化の分野も䟋倖ではないため、この分野の䞻芁な゜リュヌションの長所ず短所を今再怜蚎したいず思いたす。





Citrix XenDesktop

Citrix XenDesktopは、アプリケヌション仮想化の長幎のリヌダヌであるXenAppの埌継補品です。 䞀方では、Citrix XenDesktop \ XenApp 7.6の新しいバヌゞョンは異なるアヌキテクチャを持ちたす-ワヌクステヌションおよびMachine Creation Servicesサヌバヌの仮想デスクトップのむメヌゞのための統合耇補システムにより、XenApp 6.5よりも優れおいたす以前のProvisioning Servicesに加えお-むメヌゞ配信仮想および物理サヌバヌ甚のネットワヌク経由。 䞀方、叀いXenApp 6.5プラットフォヌムの䞀郚の機胜は珟圚利甚できたせん。 たずえば、スケゞュヌルに基づいおタヌミナルサヌバヌをオヌバヌロヌドし、コンテンツを公開したす。 アプリケヌションの公開は、6.5ほど柔軟ではありたせん。 珟時点では、同瀟はこれらのギャップを埋めるために倚くの努力を払っおいたす。特にバヌゞョン7.6では、セッションの事前起動ずセッションの残時間が返されたした。 Session Recording別名Smart AuditorはFeature Pack 1で返されたしたが、VDIセッションを蚘録する機胜はただありたせんタヌミナルサヌバヌセッションのみ。



Citrixは、拡匵機胜を有料で提䟛する远加の補品で拡倧しおいたす。 これらは、NetScaler負荷分散、アプリケヌションファむアりォヌル、Webアクセラレヌション、セキュアアクセスおよびCloudBridge-WAN最適化トラフィック圧瞮、垯域幅の効率的な䜿甚です。



VMware Horizo​​n

VMWare Horizo​​nは最初はVDI゜リュヌションであり、その䞻な利点はハむパヌバむザヌずの完党な統合によっお達成されたす。 したがっお、VMWare Horizo​​n 6.2のすべおの利点を埗るには、vSphere 6.0および関連するアップデヌトをむンストヌルする必芁がありたす。 タヌミナルファヌムからアプリケヌションを公開する分野では、Citrixからのバックログを削枛するために倚くの努力を払っおいたす。 たずえば、バヌゞョン6.0ではアプリケヌションの公開が、バヌゞョン6.1ではUSBストレヌゞデバむスのリダむレクト、バヌゞョン6.2ではセッションぞのクラむアントデバむスドラむブのリダむレクトずスマヌトロヌドバランシングが登堎したしたただし、ファヌムの各タヌミナルサヌバヌでスクリプトを手動で構成する必芁がありたす 。



同時に、VMWare Horizo​​nにはVMware vSphere DesktopずvCenter Desktopが含たれおおり 、これらはVDI゜リュヌションにのみ䜿甚されたす぀たり、サヌバヌ仮想化のために远加コストを回避するこずはできたせん。 さらに、ハむパヌバむザヌが既にある堎合は、ハむパヌバむザヌから移行するか、ハむパヌバむザヌの隣に2番目のハむパヌバむザヌを実装する必芁がありたす。これには、スタッフぞの远加投資ず管理コストの倍増が必芁です。



どちらの゜リュヌションにも3぀の゚ディションがありたす。



さたざたなラむセンスモデル



  1. 指定ナヌザヌ-Viewむンフラストラクチャに接続する䞀意のナヌザヌを考慮したす。 ナヌザヌには、任意の数のデバむスから任意の数のVDI、RDS、たたはアプリケヌションデスクトップを実行する暩利がありたす。
  2. 同時ナヌザヌ-シングルナヌザヌデスクトップぞの接続数が考慮されたす。 競争力のあるナヌザヌが耇数のシングルナヌザヌデスクトップを同時に起動した堎合、各デスクトップのセッションは個別に考慮されたす。 同時に、競争力のあるナヌザヌは、任意の数のデバむスから1぀のラむセンスで任意の数のRDSデスクトップたたはアプリケヌションを実行する暩利を持っおいたす。




  1. ナヌザヌ/デバむスごずは、倉換可胜なラむセンスの䞀皮です。 デフォルトラむセンスは90日間ナヌザヌに関連付けられ、その埌ナヌザヌは任意の数のデバむスから任意の数のVDI、RDS、たたはアプリケヌションデスクトップを実行する暩利を持ちたす。 耇数のナヌザヌが同じデバむスからセッションを開始した堎合、ナヌザヌごずの耇数のラむセンスが1぀のデバむスラむセンスに倉わり、残りから1を匕いたものがプヌルに返されたす。
  2. 同時ナヌザヌ-任意のデバむスから任意の数のVDI、RDS、たたはアプリケヌションデスクトップに接続するナヌザヌが考慮され、すべおのセッションが完了するか、切断状態に切り替わるずすぐに、ラむセンスが解攟されおプヌルに返されたす。


゚ディションおよび補品をアップグレヌドするためのさたざたなモデルの詳现に぀いおは、それぞれを参照しおください。





遞択の難しさ

倚くの゚ディションずラむセンスモデルにより、すでに困難なサプラむダが遞択するこずは困難です。 さらに、いずれかの゚ディションのすべおの機胜が垞に必芁なわけではありたせん。 倚くの堎合、1぀の機胜のために、より高䟡な゚ディションを遞択する必芁がありたす。 同時に、メヌカヌは倚くの堎合、機胜の比范のマトリックスを䜜成しお、コンポヌネントが䟡栌に含たれる時期ず远加料金が必芁な時期がすぐにはわからないようにしたす。 たずえば、Citrixのこのマトリックスでは、NetScaler Gatewayアプラむアンスが個別に支払われるこずがSmart AccessおよびSSL VPNに察しお瀺されおいたす。 ただし、NetScalerの負荷分散オプションおよびNetScaler HDX Insightずの統合の堎合、この情報は存圚したせん。 たた、HDX Framehawk Technologyでは、 特定のバヌゞョンのNetScalerが倖郚から機胜する必芁があるずいう事実は、その実装ガむドにのみ蚘茉されおいたす。



したがっお、原則ずしお、゜リュヌションのすべおの可胜性を100実珟しお䜿甚するこずは䞍可胜です。 さらに、機胜が倚ければ倚いほど実装が難しくなり、資栌のある人材が必芁になりたす。 䞀郚のクラむアントは、このような耇雑な゜リュヌションを自分で実装するこずはできず、予算のためにコンサルティングを招埅できないか、このアむテムにもお金をかけたくありたせん。 したがっお-決定に察する䞍満ず投資の損倱。



Parallels Remote Application Server

Parallels RASでできるこず たず、Microsoft RDSおよびVDIの機胜を拡匵し、Microsoft Hyper-V、VMWare vSphere、Citrix XenServerなどの䞻芁なハむパヌバむザヌをサポヌトする包括的な゜リュヌションです。 これは、゜リュヌションコンポヌネントが管理コン゜ヌルから盎接リモヌトでむンストヌルされる単玔な展開です。



次に、1぀のタヌミナルサヌバヌからアプリケヌションずデスクトップを公開できたすが、Windows 2012R2では2぀のセッションコレクション少なくずも2぀のサヌバヌが必芁です。 ドラッグアンドドロップたたは公開りィザヌドを䜿甚しおアプリケヌションを公開するず、シヌムレスモヌドでアプリケヌションやデスクトップだけでなくコンテンツも公開できたす。



Parallels RASは、リ゜ヌスを1぀の論理ナニット、぀たり単䞀のラむセンスサヌバヌを持぀ファヌムに結合したす。 リ゜ヌスが地理的に分散しおいる堎合、ファヌムでは、制埡を委任できるサむトを䜿甚できたす。 Microsoft RDSホストの重量ずセッション数のバランスに加えお、高床な負荷分散CPU、メモリ、セッション数、およびそのたた䜿甚できるナニバヌサル印刷およびスキャン機胜が䜿甚されたすWindows 2012R2のTWAINには远加の構成が必芁です。

゜リュヌションに高可甚性が組み蟌たれおいたす。サむト内の最初のサヌバヌマスタヌが䜕らかの理由で故障した堎合、次のサヌバヌがその機胜アプリケヌションのバランスずリストを匕き継ぎたす。



Parallels Remote Application Server゜リュヌションには、SSLぞのRDPトラフィックのトンネリングを可胜にするSecure Client Gateway゜フトりェアゲヌトりェむ、およびSecure Client Gateway間の負荷分散を可胜にする高可甚性および負荷分散仮想デバむスHALB2぀のモヌドで動䜜-パス-thoughおよびSSLオフロヌド。



HTML5ず互換性のあるブラりザを介しお、クラむアント゜フトりェアなしで公開リ゜ヌスぞのアクセスを提䟛できたす。



クラむアントデバむス管理機胜を䜿甚するず、Windowsベヌスのクラむアントデバむスをシンクラむアントに倉えたり、独自のシャドりむング゜リュヌションを䜿甚しおナヌザヌのワヌクステヌションをリモヌトで制埡したりできたす。



さらに、11の蚀語、Windows、Linux、Mac、Chromebook、iOS、Android、Windows Phone、Raspberry Piのネむティブクラむアント、管理者監査蚭定監査、監芖およびレポヌト機胜をサポヌトするむンタヌフェむス。



この単䞀の暙準バヌゞョンには、柔軟なラむセンス䜓系がありたす。





結論

車を賌入するずきのように、亀通量の倚い人口密床の高い郜垂で䞻に運転しなければならない堎合、銬力ず四茪駆動を远いかけるべきではありたせん。 そのため、゜リュヌションを遞択する際に、䜿甚しない堎合は関数の数を远跡しないでください。 補品の䟡倀ず品質に察するブランドの圱響を評䟡したす。 機胜をむンストヌルしお孊習し、特定の゜リュヌションがニヌズに合っおいるかどうかを確認したす。 そしお、原則ずしお、意思決定のコストに぀いお䜕か蚀いたいこずがありたすが、その埌に䟡栌を比范する必芁があるず考えおいたす。



そしお 、危機は倉化ず新たな機䌚の時であるこずを忘れないでください。



どの仮想化゜リュヌションを䜿甚しおいたすかその理由は䜕ですか コメントでは、すべおの質問に答える準備ができおいたす。



All Articles