第2回目までは、シンクライアントとは何か、その実行方式の仕組みとそれぞれの実行方式がどのような業務に向いているのか、その選定ポイントについて紹介してきた。今回は、プレゼンテーション型シンクライアント製品の中では、最も長い歴史と実績を持つ、Citrix社のXenAppの構築のポイントとその運用方法について解説する。
機能概要 | |
---|---|
Delivery Controller(★) | クライアントからXenAppサーバーへの接続要求の仲介などのセッションを管理 |
Citrix Studio(★) | XenAppやXenDesktopの主に構成や運用管理を行う統合管理コンソール |
Citrix StoreFront(★) | XenAppやXenDesktopサイトへのユーザー認証や利用可能なデスクトップおよびアプリケーションを列挙するストアの管理を実施 |
Citrix Director | Citrix Studioが構成や運用管理に使われるのに対し、パフォーマンスや監視をメインに行う管理コンソール |
Citrix ライセンスサーバー(★) | XenAppやXenDesktop、Citrix社の他製品のライセンス管理を行う |
XenApp Server(★) | ユーザーに対して、アプリケーションやデスクトップを提供 |
※★マークは必須コンポーネント
XenAppに限らず、シンクライアントシステムは、基本的にMicrosoft社のディレクトリサービスシステムであるActive Directoryと連携する場合がほとんどである。XenAppの場合、Active Directory内に保管されている情報を使って、ユーザー認証やアカウント制御を行っているため、Active Directoryが停止すると、ユーザー認証が行えなくなり、新規ログインや管理ができなくなる。既存接続ユーザーは、ログオフしない限りは問題はないが、Active Directoryは他のシステムとも連携している場合が多いため、少なからず業務に影響が発生する。
Active Directoryの冗長化は、Microsoft社が標準機能として、マルチマスタレプリケーションと呼ばれる複製機能を提供している。Active Directoryのサーバーであるドメインコントローラーサーバーを容易に複数配置可能だ。最低2台以上で構成しておこう。
Delivery Controllerは、ユーザーの接続要求とXenAppサーバーの仲介役だ。Delivery Controllerがすべて停止すると、当然ユーザーの接続要求を仲介できなくなるため、新規接続は受け入れられなくなる。
すべてのDelivery Controllerサーバーが全断した場合に、VDA(Virtual Delivery Agent)の高可用性モードと呼ばれるサーバーへ直接ICA接続を可能にする機能がDelivery Controllerには標準装備されている。しかし、あくまで暫定的な救済策的だ。機能制限や使用期間(30日のみ)が限定されているため、きちんと冗長化しておく必要がある。
Delivery Controllerの冗長化は、XenAppの各コンポーネントから複数のDelivery Controllerを指定できるなど、もともと複数で構成することが前提となっているため、別の仕組みを用意する必要がない。容易に高可用性を確保することが可能だ。
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サーバーの配置台数は、ユーザ数の規模や処理するアプリケーションによって変動してくるため、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サーバーのどれにログインしても、プロファイルデータに一貫性を持たせるために、ファイルサーバーの冗長化部分で触れた移動ユーザープロファイルを利用する。
移動ユーザープロファイルは、ログイン時にファイルサーバー上にあるプロファイルデータをすべて読み込み、ログオフ時には、変更データを保存する仕組みだ。そのため、プロファイルデータが大きくなってしまうと、ログイン・ログオフ処理に時間がかかり、ユーザーの業務に支障をきたす恐れがある。
システムを運用していく場合、サーバー機器の故障やデータの破損などの際に速やかにシステムを復旧させる必要がある。そのため、バックアップの取得は、システム運用という観点では、非常に重要な要素となる。ここでは、XenAppシステムにおけるコンポーネントごとに適したバックアップの頻度と取得方法について解説する。
『冗長化設計② – Delivery Controller冗長化』でも紹介したが、Delivery Controllerが管理する情報は、すべてサイト構成データベースに格納される。Delivery Controllerが固有で保持している情報は基本的には存在しない。そのため、システムバックアップを定期的に取得し、障害時には、故障したサーバーのみをバックアップからリストアするだけで復旧できる。
StoreFrontは、ストアに関する情報が格納されたデータベースを各サーバに保存し、同一サーバーグループにいるStoreFrontと同期を行う。そのため、万が一のために、システムバックアップだけでなく、データベース情報も取得しておくことを推奨する。StoreFrontのデータベース情報は、PowerShellのスクリプトでエクスポート・インポートできるため、バッチ化して日次でデーターベース情報を取得しておこう。有事の際には、システムバックアップリストア後に、データベース情報をインポートすれば復旧可能だ。
サイト構成データベースには、サイト情報がすべて格納されており動的に変更されるため、システムバックアップの他に、データベースのバックアップを考慮する必要がある。バックアップ方法は、SQL Serverのバックアップに準拠するが、構成データベースという性質上、極端にサイズが大きくならないため、日次でデータベースのエクスポートをするなどでも対応可能だ。
ライセンスサーバーは、ライセンスを変更しない限り、大きな変更はほとんど発生しない。そのため、基本的にはシステムバックアップを定期的に取得しておくだけで問題ないが、念のため、元となるライセンスファイルは必ずどこかに保存しておこう。
移動ユーザープロファイルを利用する場合、XenAppサーバーに保存された固有データを保全する必要がないため、基本的にシステムバックアップを定期的に取得するだけで問題はない。しかし、台数が膨大になる場合は、すべてのシステムバックアップを定期的に取得するのでは非効率だ。シンクラ概論の第2回で説明した、Citrix社のリンククローンを実現するMCS(Machine Creation Service)は、XenDesktopだけでなく、XenAppサーバーでも利用できる。この機能を利用することで、マスターイメージのみの管理だけでよくなるため、大幅に管理工数を削減することができる。ただし、MCSに対応している仮想基盤が必要になるため、物理サーバの場合は実現できないので、注意が必要である。
ファイルサーバーは、ユーザーデータが格納されるため、バックアップの取得は絶対に欠かせない。バックアップは、ファイル数が膨大になることが想定されるため、フルバックアップ+差分バックアップなどを週次で取得するのが現実的だ。しかし、アプライアンス製品を利用している場合には、強力なスナップショット機能やレプリケーション機能を有しているため、それらを利用することで管理効率を大幅に向上することが可能である。