テクニカルトレーナーの佐分利です。時が経つのは早いもので、 XenDesktop 7 がリリースされてから3年以上が経ちました。 つまり、FMA ( FlexCast Management Architecture ) アーキテクチャーも3年以上存在していることになります。 以前のバージョンのXenApp / XenDesktop に比べ、 より信頼性や堅牢性に優れ、 多くの新機能が追加されている FMA アーキテクチャーがどのような仕組みで成り立っているかはご存知でしょうか。 FMA は複数の独立したサービスが複数のコントローラーサーバーによって提供されるサービス指向のアーキテクチャーです。 それぞれのサービスは別々の役割を持ち、 新機能の追加が必要な場合シトリックスは新しいサービスという形でこのアーキテクチャーに追加することができるようになっています。 現に、 XenDesktop 5.x の頃はこのサービスが 5 つのみでしたが、 XenApp / XenDesktop 7.6 以降では 11 ものサービスにより構成されています。 この FMA という仕組みにより、 一つのサービス障害がほかのサービスへの影響を与えることがなくなり、 トラブルシューティングも行いやすくなっています。
受講者から時折 「 XenApp / XenDesktop のトラブルシューティングって難しいですよね 」 というコメントをいただくことがあります。 一般的にトラブルシューティング自体簡単なタスクではないですが、 特に複雑に見えてしまいやすいシトリックス製品のトラブルシューティングとなると尚の事尻込みしてしまう方がいらっしゃってもおかしくないと思います。 ただ、 上にあげた FMA の仕組みを正しく捉え、 適切な方法論とツールの活用によって XenApp / XenDesktop のトラブルシューティングは圧倒的に楽になること請け合いです。 それぞれ少し紐解いてみましょうか。
まずは FMA の仕組みを改めて。 11のサービスは以下のような関係になっています。
真ん中にある CCS ( Central Configuration Service ), CLS ( Configuration Logging Service ), DAS ( Delegated Administration Service ) がコアサービスと呼ばれ、中心的な役割を果たします。デスクトップやアプリケーションに関連するサービスが左側の ADIS ( AD Identity Service ) , MCS ( Machine Creation Service ), Host Service, Broker Service です。 そして、 サポート関連のサービスが右側にある Analytics Service, StoreFront Service, EnvTest Service, Monitor Service です。 それぞれの役割は以下の通りです。
こういった機能がサービスとして独立し、 かつ連携しながら FMA は成り立っています。 障害や不具合が発生した場合、 その現象からどのサービスで問題が発生していそうなのか、 ある程度はアタリがつけられるようになります。 それでは、 次にトラブルシューティングの方法論についても触れておきます。 XenApp / XenDesktop にかかわらず、 同じようなアプローチが効果的ですが、 シトリックスが推奨している方法論として以下の 6 ステップをご紹介します。
- 問題の特定
まずは問題を特定するところから始まります。 実際に問題が起きていても誰も把握していなければ起こっていないのと同じです。 特定されるパターンとしてはユーザーからの問い合わせや監視ツールによる検知、 あるいは管理者による発見が挙げられます。 - 問題の理解
そして次に問題に関する情報をできるだけ集めます。 どれだけの影響範囲があるのか。 問題の重要度はどれほどか。 いつから起こっているか。 再現性はあるか。 など。 時には Citrix Discussions や Google 検索なども活用しながら既知の問題に当たらないかなども調べます。 - サービスの復旧
根本解決はできなくとも、 ワークアラウンドがあれば一時的に復旧を試みます。 ここでの目的はエンドユーザーが業務をできるようにし、 その間に問題のトラブルシュートを行うことです。 例えば特定のサーバー OS マシンで問題が起こっている場合、 そのマシンのメンテナンスモードを有効にし、 ユーザーがほかのサーバーへ接続されるようにするなどです。 - 問題の切り分け
いよいよトラブルシューティングの真髄です。 適当にHotfixやパッチを適用して運に任せるのではなく、 根本原因を探ります。 - 問題の修正
根本原因が明らかになれば、 あとは問題を修正する段階に進みます。 ここで重要なことは、 いきなり本番環境に適用するのではなく、 テスト環境で検証をするということです。 修正箇所が複数ある場合はいっぺんに行うのを避け、 ひとつずつ検証します。 可能な限り、 ユーザーのアクセスが少ない時間帯に実施します。 - 対策
最後に、 将来同じような事象があった場合により迅速に対応できるよう措置を講じます。 例えば監視のツールを新たに導入したり、 メンテナンス期間を定期的に設けるようにしたり、 SPOF が無くなるように構成を変更したりすることが含まれます。
最後にいくつかトラブルシューティングに役立つツールのご紹介です。
・Citrix Director
言わずと知れた監視ツールですが、 監視のみならず簡単なトラブルシューティングやヘルプデスクツールとしても活用できます。 すべてのユーザーセッションに関する現在のリアルタイムなデータや過去の統計的データを直感的な GUI で確認することが可能です。 負荷状況やログオン時間、 接続やマシンの障害などは特にトラブルシューティングに役立つ情報になります。 また、 Director はバージョンを追うごとに新機能が追加され、 どんどん便利になっています。すべての Edition で無償で提供されているので活用しない手はないでしょう。
・Citrix Scout
7.1 からデフォルトでインストールされるようになったのでお馴染みの方も多いと思います。 Scout はイベントログや CDF トレース、そしてマシンの設定情報をまとめて収集することが可能です。 設定情報としては適用されている Hotfix や構成データ、 レジストリの値などを取得できます。さらに、収集した後はローカルに保存するだけなくシトリックスサポートが分析するために cis.citrix.comにアップロードすることも可能になっています。
・Supportability Pack
Supportability Pack は CTX203082 からダウンロードすることができ、 様々なトラブルシューティングに活用できるツールがまとまっています。
・Citrix Insight Services (CIS)
以前は TaaS と呼ばれていたシトリックスのクラウドサービスの一つです。 ログや設定情報をアップロードすると、 構成上の問題や推奨事項を提示してくれる無償のサービスです。
・CDF トレース
一番詳細なログを取得したい場合は CDF トレースを取得します。 サービスやエンドユーザーに影響を与えることなくローカルまたはリモートからリアルタイムにログを取得できるツールです。 従来型のテキストファイルにログが記録される仕組みに比べてハードルが高く見えがちですが、FMA アーキテクチャーのように複数のサービスがそれぞれ独立して機能している場合はログのプロバイダーを選択できる CDF のようなツールの方がむしろ使い勝手が良いです。 一度使い方を覚えてしまえば意外と簡単に取得できます。
さて、このブログでは FMA アーキテクチャーが採用されている XenApp / XenDesktop 7.x のトラブルシューティングを行うにあたって必要な仕組みと方法論とツールについてご紹介しました。 FMA に関する正しい知識と方法論、そしてツールの使用方法さえ抑えられればトラブルシューティングはそう難しくありません。 このブログではあくまでその入り口を示したに過ぎませんが、 より網羅的に、 そして詳細について知りたい方は CXD-302 XenApp and XenDesktop 上級コース: トラブルシューティング コースをご受講ください。 XenApp / XenDesktop 7.x のトラブルシューティングについて苦手意識が無くなるだけでなく、 よりプロアクティブに問題が起こる前から対策をすることにより安定稼働の実現にもつながるはずです。 分かりやすい講義と実践的なハンズオン演習がたくさん用意されているオススメのトレーニングコースです。 このブログでは触れていない PowerShell の活用方法や、StoreFront, Delivery Controller, VDA 非登録問題、HDX 接続問題なども併せて、 効果的なトラブルシューティングに必要な様々なトピックを扱います。
日本初開催！
CXD-302 XenApp and XenDesktop 上級コース: トラブルシューティング
日程: 9月28-29日 ( 水、木曜日 )
場所: 東京本社 （ 虎ノ門 / 霞ヶ関 )
お問い合わせはこちらまで。
