MENU
シンクラ概論

【第3回】シンクライアントの構築・運用フェーズに検討すべきこと
〜プレゼンテーション型シンクライアント『XenApp』編〜

2014/09/24

第2回目までは、シンクライアントとは何か、その実行方式の仕組みとそれぞれの実行方式がどのような業務に向いているのか、その選定ポイントについて紹介してきた。今回は、プレゼンテーション型シンクライアント製品の中では、最も長い歴史と実績を持つ、Citrix社のXenAppの構築のポイントとその運用方法について解説する。

規模や「やりたいこと」に応じて選べる3つのエディション

XenAppには、Advanced / Enterprise / Platinumの3つのエディションが存在する。XenAppの基本的な機能は一番下位のAdvancedエディションでほとんど網羅されているが、機能面 / 運用面 / 規模感の3つの観点で選択する必要がある。(※詳細は、メーカーホームページを参照)

機能面で見ると、たとえば、高品質な3D系の機能、音声系の利用、クラウド環境の連携をするのであれば、Enterpriseエディション以上が必要だ。また、Platinumエディションを利用すると、Citrix社が提供している負荷分散装置「NetScaler」の仮想アプライアンス版の1つである「NetScaler Gateway」と連携して、SSL VPN機能やアクセスポリシーの管理などが可能になる。

運用面では、ロール分けや監査機能、イメージの集中管理など、大規模システムの運用負担を軽減するような機能はEnterprise以上、パフォーマンスのトレンドやネットワーク状況などの分析機能はPlatinumが必要となる。

規模感では、小規模~中規模がAdvanced、大規模システムはEnterprise以上が目安となる。

まずは、全体の構成を設計

XenAppでは、認証機能や管理サーバー、ライセンス管理などそれぞれの機能を持ったコンポーネントが存在する。

コンポーネントには、システムとして必須のものと、オプションのものがある。また、MicrosoftのActive Directoryや、サイト構成データベースとしてXenAppサイトの構成情報を保存するSQLServer、XenAppサーバーを複数配置した場合にユーザーのプロファイルを格納するためのファイルサーバなど、Citrix社のコンポーネント以外で必要なものもある。

Active Directory以外のコンポーネントは、すべて1台のサーバーに集約することも可能だが、パフォーマンスや可用性を考慮した場合、コンポーネントごとにサーバーを分け、それぞれに適した冗長構成を確保する必要がある。
機能概要
Delivery Controller( クライアントからXenAppサーバーへの接続要求の仲介などのセッションを管理
Citrix Studio( XenAppやXenDesktopの主に構成や運用管理を行う統合管理コンソール
Citrix StoreFront( XenAppやXenDesktopサイトへのユーザー認証や利用可能なデスクトップおよびアプリケーションを列挙するストアの管理を実施
Citrix Director Citrix Studioが構成や運用管理に使われるのに対し、パフォーマンスや監視をメインに行う管理コンソール
Citrix ライセンスサーバー( XenAppやXenDesktop、Citrix社の他製品のライセンス管理を行う
XenApp Server( ユーザーに対して、アプリケーションやデスクトップを提供

※★マークは必須コンポーネント

スクロールできます

構成イメージ

XenAppの冗長化設計

全体の構成が決まったら、次は、システムの冗長化について検討する必要がある。

XenAppの各コンポーネントは、それぞれが固有の役割を担っており、サービス停止時の影響もコンポーネントごとに異なるため、一般的には、負荷分散装置やクラスタシステムなどを利用して高可用性を高める。

しかし、最近では、仮想化基盤にHAの機能が搭載されているため、仮想化基盤上にXenAppのシステムを載せることで、容易に可用性を確保しているケースも多い。ただし、仮想化基盤のHA機能は、基本的にハードウェア障害のみしか対応していないため、サービスやネットワークがダウンしている場合には救えないケースもあるので注意が必要だ。

サービス影響の大きいコンポーネントは、仮想化基盤のHA機能に加え、負荷分散装置やクラスタシステムのようなアプリケーションレベルでの可用性を高める仕組みを導入することが望ましい。規模やサービス要件に応じて構成を検討することをおススメする。

冗長化設計① – Active Directory冗長化

XenAppに限らず、シンクライアントシステムは、基本的にMicrosoft社のディレクトリサービスシステムであるActive Directoryと連携する場合がほとんどである。XenAppの場合、Active Directory内に保管されている情報を使って、ユーザー認証やアカウント制御を行っているため、Active Directoryが停止すると、ユーザー認証が行えなくなり、新規ログインや管理ができなくなる。既存接続ユーザーは、ログオフしない限りは問題はないが、Active Directoryは他のシステムとも連携している場合が多いため、少なからず業務に影響が発生する。

Active Directoryの冗長化は、Microsoft社が標準機能として、マルチマスタレプリケーションと呼ばれる複製機能を提供している。Active Directoryのサーバーであるドメインコントローラーサーバーを容易に複数配置可能だ。最低2台以上で構成しておこう。

冗長化設計② – Delivery Controller冗長化

Delivery Controllerは、ユーザーの接続要求とXenAppサーバーの仲介役だ。Delivery Controllerがすべて停止すると、当然ユーザーの接続要求を仲介できなくなるため、新規接続は受け入れられなくなる。

すべてのDelivery Controllerサーバーが全断した場合に、VDA(Virtual Delivery Agent)の高可用性モードと呼ばれるサーバーへ直接ICA接続を可能にする機能がDelivery Controllerには標準装備されている。しかし、あくまで暫定的な救済策的だ。機能制限や使用期間(30日のみ)が限定されているため、きちんと冗長化しておく必要がある。

Delivery Controllerの冗長化は、XenAppの各コンポーネントから複数のDelivery Controllerを指定できるなど、もともと複数で構成することが前提となっているため、別の仕組みを用意する必要がない。容易に高可用性を確保することが可能だ。

冗長化設計③ – StoreFront冗長化

StoreFrontサーバーは、ユーザー認証およびユーザーが利用できるアプリケーションやデスクトップ情報をストアしている。いわば、システムの入り口的な役目だ。そのため、StoreFrontが停止すると、ユーザーは、アプリケーションやデスクトップにアクセスするための手段を失ってしまう。

StoreFrontのベースは、Microsoft社のWebサーバー機能であるIISベースのWebアプリケーションで構成されている。そのため、サーバーを複数台用意し、外部ロードバランサーやWindows Serverの標準機能であるMicrosoft NLBの機能などを利用して高可用性を確保する構成になる。StoreFrontのデータは同一のサーバーグループに配置されているStoreFrontサーバーへ定期的に同期される仕組みだ。

冗長化設計④ – サイト構成データベース冗長化

サイトのすべての情報は、サイト構成データベースに保存されるため、各Delivery Controllerは定期的にサイト構成データベースにアクセスする。サイト構成データベースが停止すると、既存の接続は、ログオフするまで機能し続けるが、新しい接続はデータベースが使用できるまで拒否されてしまう。

サイト構成データベースには、Microsoft社のSQL Serverが利用されており、冗長化方式もいくつか方法がある。システム自体を仮想基盤上に構築する、もしくは、既に仮想基盤が存在する場合には仮想基盤のHA機能を利用する方法が、最も容易に高可用性を確保できる。しかし、『XenAppの冗長化設計』の項でも紹介したとおり、仮想化基盤のHAは、ハードウェア障害のみにしか対応できないケースが多いので注意が必要だ。また、仮想基盤上に構築しない場合は、SQL ServerのSQLミラーリングやMicrosoft Fail Over ClusterによるSQL Serverのクラスタ化、SQL Server 2012以降では、AlwaysOnの機能を利用できる。

コスト的に考えた場合、SQLミラーリングが共有ディスクレスで構成できるため、導入の敷居は低い。Citrix社も推奨ソリューションとしており、XenAppのUIからSQLミラーリングに対する設定が可能だ。

冗長化設計⑤ – ライセンスサーバー冗長化

Citrix社の製品は、ライセンスサーバーによって、ライセンス状態が定期的に確認されている。そのため、適切なライセンスが無い状態で製品を利用することはできない。ライセンスサーバーは、即時のサービス停止を避けるために、ライセンス期間に猶予がある。ライセンスサーバー停止から、30日間(720時間)は同様にシステムを利用することができるのだ。しかし、それ以降は、システムが利用できなくなるため、最低限の冗長化、もしくは、障害時に即座に復旧できるバックアップを取得しておく必要がある。

ライセンスサーバーには、冗長化する機能が標準装備されていないため、クラスタシステムに組み込む構成になるが、30日間の猶予期間があるため、サービスレベルをさほど向上させる必要もないため、高価なクラスタシステムをライセンスサーバーだけのためにサーバーを新設するのは非効率だ。仮想基盤上に構築する場合は、仮想化基盤のHA機能で対応することが効率的と言える。また、物理サーバの場合は、システムバックアップを定期的に取得し、障害時に短時間で復旧できるようにしておく方法がコストバランスを考慮すると、最も効率的だ。

冗長化設計⑥ – XenAppサーバー冗長化

XenAppサーバーは、実際にユーザーがログインをして、アプリケーションを処理するサーバだ。システムの中核となるため、XenAppサーバーがすべて停止している状態では、システムは機能しない。複数台を配置することで、高可用性も確保される。

XenAppサーバーの配置台数は、ユーザ数の規模や処理するアプリケーションによって変動してくるため、Delivery Controllerの負荷分散機能を利用して、XenAppサーバの負荷やセッション数に応じて接続先を振り分けパフォーマンスを維持している。ここで注意しなければならないのは、XenAppサーバーの配置台数だ。XenAppサーバーの台数は、リソース負荷に応じて配置しているため、そのうちの1台に障害が発生した場合にリソースの低下を招く恐れがある。接続できてもパフォーマンスが非常に低下する可能性もあるのだ。

XenAppサーバーの冗長化を考える場合には、縮退稼働時にもユーザー用のリソースが100%確保できる『N+1』で構成する必要がある。

冗長化構成⑦ – ファイルサーバー冗長化

Windows OSの仕組み上、ユーザーがOSにログインする場合、ユーザーごとにプロファイルデータがOS上に管理されることでマルチユーザーアクセスに対応している。

XenAppサーバーの高可用性やパフォーマンスの確保は、複数台配置されたXenAppサーバーに対し、Delivery Controllerが負荷分散をすることで実現している。サーバーが1台の場合、ログインするサーバーは常に同一であるため、プロファイルデータもそのサーバーだけのものを管理すればよい。しかし、サーバーが複数台になると、ログインするサーバーも毎回異なる可能性があるため、プロファイルデータの一貫性を確保する仕組みが必要となる。

一般的には、プロファイルの保存パスをネットワーク越しのファイルサーバーに格納できる、Microsoft社の移動ユーザープロファイルが利用される。その場合は、ファイルサーバーが必要になる。ユーザーログイン時に、ファイルサーバー障害などにより、移動ユーザープロファイルデータにアクセスできない場合は、既定のシステムプロファイルを利用してログインするが、当然ながらユーザーのデータは存在しないし、追加のデータをファイルサーバー上に保存もできないため、影響範囲は大きい。

ファイルサーバーの冗長化には、一般的なクラスタシステムの利用や仮想基盤のHA機能でもよいが、ファイルサーバーにはネットアップ社のFASシリーズのような専用のアプライアンス製品も多くある。高可用性機能をアプライアンス内で有しており、スナップショットやレプリケーションなどの管理機能も豊富なため、仮想基盤や共有ディスクが既存で存在しない場合には、アプライアンス製品を検討するのも1つの選択肢となる。

障害(全断)時の影響度 冗長方式
Active Directory Active Directory標準機能
Delivery Controller Citrix標準機能(負荷分散)
StoreFront 外部ロードバランサ
Microsoft NLB
サイト構成データベース
(Microsoft SQL Server)
SQLミラーリング
仮想基盤HA機能
Microsoft Failover Cluster
AlwaysOn
ライセンスサーバー 仮想基盤HA
Microsoft Failover Cluster
XenAppサーバー Citrix標準機能(負荷分散)
ファイルサーバー Microsoft Failover Cluster
アプライアンス利用(※1)

※1 アプライアンスで可用性機能を持っている場合が多い

スクロールできます

ユーザーデータ設計

プレゼンテーション型シンクライアントシステムでは、ユーザーがログインするたびに接続するサーバーが異なる。そのため、プロファイルデータに一貫性を持たせる仕組みが必要になるのだ。これを「ユーザーデータ設計」と言う。

移動ユーザープロファイルとフォルダリダイレクト

XenAppでは、複数あるXenAppサーバーのどれにログインしても、プロファイルデータに一貫性を持たせるために、ファイルサーバーの冗長化部分で触れた移動ユーザープロファイルを利用する。

移動ユーザープロファイルは、ログイン時にファイルサーバー上にあるプロファイルデータをすべて読み込み、ログオフ時には、変更データを保存する仕組みだ。そのため、プロファイルデータが大きくなってしまうと、ログイン・ログオフ処理に時間がかかり、ユーザーの業務に支障をきたす恐れがある。

それを回避するために利用されるのが、フォルダリダイレクトと呼ばれる機能だ。この機能は、移動ユーザープロファイルとは異なり、プロファイルデータ内にあるデスクトップやマイドキュメントなど、フォルダのリンク先をファイルサーバー上に指定することができる。

読み込みも書き込みも、直接リンク先のファイルサーバーにネットワーク経由でおこなわれるため、移動プロファイルの読み込み時にフォルダリダイレクトで指定されているフォルダは、リンク先の入ったフォルダ情報だけを読み込む。このため、読み込むプロファイルデータを最低限に抑えることができ、ログイン・ログオフ時の処理を高速化することが可能になる。移動プロファイルもフォルダリダイレクトもActive Directoryのグループポリシーの機能で設定できる。

移動プロファイル機能を補完する「Citrix Profile Management」

一見、何の問題もないかのように見える「移動ユーザープロファイル+フォルダリダイレクト」だが、いくつかの問題点もある。この問題点を回避するために、Citrix社は、Profile Managementと呼ばれる移動プロファイル機能を補完する仕組みをXenAppに組み込んでいるのだ。課題を見ながらそれぞれ解説しよう。

◎課題1:ユーザーが複数の公開アプリケーションに同時にアクセスする場合のデータ不整合

アプリケーションごとに別々のサーバーにログインすると、プロファイルデータの一貫性が確保されず、プロファイルデータが破損する場合がある。

2つのアプリケーションを実行する際、それぞれ別のサーバーに接続した場合を考えよう。

このように、サーバーをログオフする際、プロファイルデータが更新される。別々のサーバーでアプリケーションを起動していた場合、最終的にプロファイルデータはすべて最後にログオフしたサーバーのもので上書きされてしまい、最初にログオフしたサーバーのプロファイルデータは上書きされてしまう事象が発生するのだ。

Profile Managementを利用することで、この現象は回避できる。セッション中に変更された特定の設定のみをライトバックし、ほかの未変更の設定はすべて、そのまま保持されるようにする。こうすることで、最終書き込みが優先されてしまう現象を回避できるようになるのだ。

◎課題2:ログイン・ログオフの処理時間の長期化

ログイン・ログオフ時に時間を要してしまう問題は、フォルダリダイレクト機能を使うことで一旦は回避できた。しかし、フォルダリダイレクトの対象にできるのは、ユーザに依存するファイルのみのため、ローカルコンピュータに紐づく設定は対象にできない。プロファイルデータのAppData配下のLocalフォルダなどは、リダイレクト対象から外れてしまう。

そのため、対象外フォルダに大きなデータが保存されている場合、ログイン・ログオフ時に時間を要する問題が再発してしまう。

この課題についても、Profile Managementの機能を利用することで解決できる。Profile Managementは、特定データをユーザープロファイルから除外する機能を有している。フォルダリダイレクトの対象外のデータを、この機能を使って指定することで、ログイン・ログオフ処理の長時間化を抑制することが可能になる。

バックアップ設計

システムを運用していく場合、サーバー機器の故障やデータの破損などの際に速やかにシステムを復旧させる必要がある。そのため、バックアップの取得は、システム運用という観点では、非常に重要な要素となる。ここでは、XenAppシステムにおけるコンポーネントごとに適したバックアップの頻度と取得方法について解説する。

Delivery Controllerバックアップ

『冗長化設計② – Delivery Controller冗長化』でも紹介したが、Delivery Controllerが管理する情報は、すべてサイト構成データベースに格納される。Delivery Controllerが固有で保持している情報は基本的には存在しない。そのため、システムバックアップを定期的に取得し、障害時には、故障したサーバーのみをバックアップからリストアするだけで復旧できる。

StoreFrontバックアップ

StoreFrontは、ストアに関する情報が格納されたデータベースを各サーバに保存し、同一サーバーグループにいるStoreFrontと同期を行う。そのため、万が一のために、システムバックアップだけでなく、データベース情報も取得しておくことを推奨する。StoreFrontのデータベース情報は、PowerShellのスクリプトでエクスポート・インポートできるため、バッチ化して日次でデーターベース情報を取得しておこう。有事の際には、システムバックアップリストア後に、データベース情報をインポートすれば復旧可能だ。

サイト構成データベースバックアップ

サイト構成データベースには、サイト情報がすべて格納されており動的に変更されるため、システムバックアップの他に、データベースのバックアップを考慮する必要がある。バックアップ方法は、SQL Serverのバックアップに準拠するが、構成データベースという性質上、極端にサイズが大きくならないため、日次でデータベースのエクスポートをするなどでも対応可能だ。

ライセンスサーバーバックアップ

ライセンスサーバーは、ライセンスを変更しない限り、大きな変更はほとんど発生しない。そのため、基本的にはシステムバックアップを定期的に取得しておくだけで問題ないが、念のため、元となるライセンスファイルは必ずどこかに保存しておこう。

XenAppサーバーバックアップ

移動ユーザープロファイルを利用する場合、XenAppサーバーに保存された固有データを保全する必要がないため、基本的にシステムバックアップを定期的に取得するだけで問題はない。しかし、台数が膨大になる場合は、すべてのシステムバックアップを定期的に取得するのでは非効率だ。シンクラ概論の第2回で説明した、Citrix社のリンククローンを実現するMCS(Machine Creation Service)は、XenDesktopだけでなく、XenAppサーバーでも利用できる。この機能を利用することで、マスターイメージのみの管理だけでよくなるため、大幅に管理工数を削減することができる。ただし、MCSに対応している仮想基盤が必要になるため、物理サーバの場合は実現できないので、注意が必要である。

ファイルサーバーバックアップ

ファイルサーバーは、ユーザーデータが格納されるため、バックアップの取得は絶対に欠かせない。バックアップは、ファイル数が膨大になることが想定されるため、フルバックアップ+差分バックアップなどを週次で取得するのが現実的だ。しかし、アプライアンス製品を利用している場合には、強力なスナップショット機能やレプリケーション機能を有しているため、それらを利用することで管理効率を大幅に向上することが可能である。

管理・トラブルシーティングには欠かせない「Directorによるモニタリング」

システム規模が大きくなればなるほど、管理の煩雑さも増大していく。そのため、洗練された管理ツールは非常に重要になってくる。特にシステム内で何が起こっているのかを常に把握できることは、障害時の迅速な切り分けを可能にする。

XenAppは、1つのインターフェイスから統合的な構成管理を実現するStudioに加え、監視やパフォーマンスモニタリングを可能にするDirectorと呼ばれる機能を有している。Directorでは標準でエラー情報、接続セッション数、平均ログオン期間などをダッシュボードで管理できる。機能や過去7日間の傾向情報や、ログオンにかかっている時間の平均、サーバーの負荷評価基準なども確認可能だ。また、Platinum Editionでは、EdgeSightやNetScaler HDX Insightと連携することで過去7日間以上のデータ参照やネットワーク状況(スループットやICA往復時間など)をすばやく確認できる。Director自体は、必須コンポーネントではなく、オプションインストールとなっているが、トラブルシューティングには不可欠なツールとなるため、特に理由が無い場合には導入することをおススメする

今回は、プレゼンテーション型シンクライアントの代表格である、Citrix社のXenAppでシンクライアントシステムを構築する際のポイントを解説してきた。規模や運用フェーズまで想定してシステムを設計することが必要だ。次回は、仮想PC型シンクライアント(VDI)の構築と運用方法について解説する。

まとめ

  • 模や機能面、運用フェーズを考慮して、必要なエディションを選択しよう
  • 設計フェーズで検討すべきは、以下の3つ
    • 冗長化設計 一部のシステムが故障してもサービス停止を防げるように、規模と要件に合った冗長化構成を用意しよう
    • ユーザーデータ設計 どのサーバーに接続しても、ユーザーは同じ環境を提供されなければならない。ユーザーデータの一貫性を保持する仕組みが必要
    • バックアップ設計 サービス停止時間を最小限に抑えるために、すぐに復旧できる仕組みを用意しよう