Поиск и устранение проблем с приложениями в среде Citrix MetaFrame

Application Troubleshooting in a MetaFrame Environment
George Prado, Citrix Consulting Services, 14.09.2002


Введение

Любое приложение, сертифицированное или нет для запуска в среде MetaFrame, может потенциально вызвать проблемы при установке или использовании. Существует много причин появления таких проблем, но основные связаны со следующим:

Если одно из этих условий присутствует, можно будет наблюдать определенные симпотомы, обычно невозможность запуска, неожиданный крах программы, насыщение памяти, плохая производительность сеансов ICA и приложений. Некоторые из этих симптомов могут ввести в заблуждение и требуют тщательного анализа. Суть состоит в определении источника проблемы и его устранении.

Определение источника проблемы и разработка решения или обходного пути для вышеперечисленных аспектов является непростой задачей. В этом руководстве мы хотели бы предложить процесс поиска и устранения проблем как руководство для мониторинга, анализа и решения возникающих проблем. Цель этой статьи - предложить "научный метод" решения технических проблем. Этот метод широко используется учеными в попытке создать аккуратное представление о мире. В общих словах этот метод заключается в следующем:

  1. Идентифицируйте проблему/вопрос. Ставьте вопрос так, чтобы на него можно было ответить. Пытаясь ответить на вопрос, соберите важную информацию
  2. Сформулируйте гипотезу. Предложите решение проблемы или вопроса. Определите гипотезу так, чтобы ее можно было проверить.
  3. Проверьте гипотезу. Это можно сделать двумя способами: провести эксперимент и/или провести дальнейшее расследование.
  4. Соберите и проанализируйте данные. Если гипотеза не прошла проверку, ее следует отвергнуть и либо забыть, либо изменить. Измененную гипотезу следует снова проверить. Если гипотеза прошла проверку, она считается подтвержденной и ее можно принять.
  5. Сделайте заключение. Это конечный шаг в построении, поддержке и подвергании сомнению теории. Научная теория - это унифицированное и самосогласующееся объяснение фундаментальных естественных процессов или феноменов, которая полностью состоит из подтвержденных гипотез.

При устранении проблем в среде MetaFrame применяются эти общие этапы научного метода. Необходим анализ поведения приложения и ассоциированных технических средств. На основе собранной информации можно сформулировать множество гипотез, а на этапе проверки отсеять неверные. Когда определены верные гипотезы, можно разрабатывать решения.

Модель процесса

Локализация неисправностей в среде MetaFrame требует системного подхода. Научный метод дает каркас для него. Очень важно решить проблему в кратчайшие сроки. Во многих случаях проблемы негативно влияют на клиентов, и чем дольше это продолжается, тем больше финансовое влияние это оказывает на клиента.

В этом разделе приведен детальный процесс, подчеркивающий важные задачи, которые помогут в эффективном устранении проблем с приложениями.

  1. Установка отправной точки. Установите суть проблемы. Убедитесь, что она связана с MetaFrame. Восстановите последнее рабочее состояние и текущее состояние приложения и среды MetaFrame.

  2. Понимание симптомов. Исследуйте симптомы по возможности со стороны пользователя. Исследуйте последовательность шагов, сделанных пользователем или последовательность событий, которые привели к проблеме.

  3. Воспроизведение ошибки. Воспроизведите ошибку в тестовой среде.

  4. Создание и проверка гипотез. Создайте списрок возможных причин, отсортируйте список по приоритету и проверьте. Здесь часто применимо "правило Оккама" - "самым правильным является самое простое объяснение".

  5. Выбор подходящих средств. Найдите подходящие средства для проверки гипотез.

  6. Реализация решения или обходных путей. При разработке решения или обходных путей всегда необходимо учитывать конечного пользователя и требования бизнеса. Проверьте решение на пилотной установке.

Каждый этап необходимо документировать и вносить в записи корректировки по мере поступления новых сведений.

Теперь рассмотрим каждый этап подробно.

 

1. Установка отправной точки.

Понимание контекста проблемы очень важно для избежания пустой траты ресурсов (времени, денег, технических ресурсов) при разработке решения. Четкое понимание проблемы покажет правильное направление. Очень важно восстановить последнее рабочее состояние приложения и среды MetaFrame, т.е. работало ли приложение до инсталляции некоторой версии или конфигурации MetaFrame, или некоторой версии самого приложения. Это можно установить, если в среде MetaFrame делались какие-то изменения. Кроме того, может выясниться, что проблема не связана с MetaFrame, а ее надо адресовать приложению.

Вам следует ответить на ряд вопросов:

Не идите дальше, не ответив на эти вопросы. Когда основная информация собрана, становится ясен контекст среды MetaFrame, где возникает проблема. Следующим шагом является попытка детально понять симптомы проблемы.

2. Понимание симпотомов

Определение значимых симптомов и правильная их оценка чрезвычайно важны для решения проблемы. Оцените симптомы со стороны пользователя. Определите последовательность шагов, сделанных пользователем или последовательность событий, которые привели к возникновению проблемы. Наблюдайте в прцессе за поведением приложения. Решите, нужны ли дополнительные исследования, которые могут потребовать средств мониторинга и отладки.

Приложение может давать один или несколько симптомов. Одни могут вести к корню проблемы, другие - мнимые и требуют дополнительного исследования, а третьи вообще не связаны с проблемой.

Вам следует ответить на следующие вопросы:

3. Воспроизведение ошибки

Важно попробовать повторить появление ошибки. Это гарантирует, что будущие исследования не окажут негативного влияния на промышленную среду. В некоторых случаях нельзя создать тестовую среду, способную воспроизвести проблему из-за разницы между рабочей и тестовой средой, разницы в настройках и пр.. В такой ситуации создайте изолированную тестовую среду внутри рабочей, например, выделенный сервер MetaFrame в рабочей среде.

4. Создание и проверка гипотез

Гипотеза предлагает вариант ответа на вопрос. Может быть несколько гипотез, объясняющих проблему. Разрабатывая гипотезы, располагайте их с порядке наибольшей вероятности. Вот примеры гипотез:

На основе составленного списка гипотез сформулируйте тесты, необходимые для проверки их верности, выберите подходящие средства мониторинга и отладки, и выполните необходимые тесты. В процессе проверки может выявиться источник проблемы. Тогда следующим шагом станет разработка решения. В некоторых случаях корень проблем определить сложно, и можно предпринять обходные пути.

5. Выбор подходящих средств

Поиск и выбор подходящих средств важно для быстрого устранения проблемы. Хороший инструмент даст не только информацию, необходимую для дальнейшего движения вперед, но и может служить средством для воспроизведения проблемы. Например, проблема может возникать только при превышении определенного уроавня нагрузки на сервер MetaFrame. Тогда для имитации нагрузки можно использовать Citrix Server Test Kit.

При определении подходящего средства используйте следующий набор критериев.

6. Реализация решений или обходных путей

Выбор правильного решения не всегда очевиден и должен быть предварительно тщательно проверен на основе требований клиента. Попытайтесь получить технические требования до предложения рекомендаций и разработки списка рекомендованных решений или обходных путей. Привлеките лиц, ответственных за принятие решений, в процесс выбора решения, чтобы это решение вписывалось в существующую среду. Если прямого решения не найдено, могут быть применены обходные пути. Например, проблема связана с изменением кода приложения, а исходные тексты недоступны. Кроме того, кратковременные решения или обходные пути необходимы в случае если долговременные решения невозможно немедленно реализовать. Иногда приемлимым обходным маршрутом является ничего не делать.

Решение должно быть проверено в тестовой среде, в том числе на предмет отсутствия нежелательных побочных эффектов. Избегайте внедрения решения в рабочую среду без тщательного его тестирования. Убедитесь, что у вас есь план отката в случае возникновения нежелательных эффектов от реализации решения.

Ниже приведены некоторые пожелания при выставлении рекомендаций

Наиболее общие проблемы с приложениями

В приложених, сертифицированных или нет для MetaFrame, иногда возникают проблемы вследствие способа их разработки и способа установки и настройки в среде MetaFrame. При возникновении проблем обычно возникают следующие симптомы:

Эти симптомы требуют дальнейшего исследования для выяснения источника проблемы. Сначала нужно определиться, с чего начать. Есть пять технических областей, требующих исследования: ресурсы, настройки, безопасность, сеть, seamless-окна MetaFrame.

Ресурсы

Любое чрезмерное или некорректное использование системных ресурсов может вызвать падение производительности приложений и серверов, и в некоторых случаях даже к их краху. С ресурсами ассоциированы следующие компоненты: процессор, память, диск, сетевой интерфейс, файл подкачки, файлы и пр. Наиболее часто встречаются следующие проблемы:

Для выявления причин прежде всего определите, какой именно ресурс используется чрезмерно или некорректно. Часто это бывает сложно сделать, поскольку активно используется несколько ресурсов, но часть из них - всего лишь побочные эффекты. Например, если наблюдается активное использование файла подкачки и высокое использование CPU, причина может заключаться в нехватке физической памяти в системе или приложение имеет серьезную утечку памяти. Для мониторинга ресурсов в Windows 2000 есть два средства: Task Manager (taskmgr.exe) и Performance (perfmon.msc). Эти средства легко использовать и, как правило, они являются первым, что следует использовать для выяснения причин.

Следующий шаг заключается в более пристальном исследовании приложения путем анализа логов, трассировки и/или отладки. Некоторые приложения позволяют включить журнализацию/отладку. Подсистемы, интегрированные в некоторые приложения, имеют собственные средства отладки, например, для отладки приложений ODBC можно использовать ODBCTrace.

Также полезны такие инструменты, как профилировщики производительности и индикаторы утечки памяти. Они позволяют выявить специфическую функцию в прикладной программе, вызывающую утечку памяти. Кроме того, профилировщики выдают отчет о производительности каждой функции прикладной программы. Например, Rational PurifyPlus (www.rational.com) позволяет анализировать производительность и утечки памяти в исполняемой программе.

Иногда единственным способом определить источник проблемы является пошаговый прогон программы в отладчике с исходным текстом.

Проблемы с конфигурацией

Сюда относятся пролемы, связанные с тем, каким образом инсталлированы и настроены приложения и сервер MetaFrame. Они включают:

Аспекты безопасности

Аспекты безопасности не связаны с приложениями, это нежелательные побочные эффекты от настройки безопасности. Наиболее общим подходом в этом случае является ослабление чрезмерной настройки безпасности. Наиболее часто всречающиеся проблемы:

Проблемы с сетью

Сетевые приложения, например, веб-приложения, клиент-серверные, распределенные базы данных могут испытывать проблемы с сетевыми соединениями, например, невозможность установить соединение с удаленным компонентом, или нестабильное соединение. Наиболее частые проблемы:

Проблемы с Seamless-окнами

Многие старые приложения GUI (DOS и 16-битные приложения) сталкиваются с проблемами при запуске в seamless-режиме, но нормально раболтают в обычном окне или в полноэкранном режиме. В seamless-режиме окна управляются другим способом; каждое верхнее видимое окно на сервере представляется как отдельное верхнее видимое окно на клиенте. Клиент ICA должен управлять несколькими окнами сеанса ICA, прикладывая всякие фишки типа заголовка, кнопок сжать/растянуть, кнопки выхода... Обычно проблемы с GUI в seamless-окнах возникают при использовании недокументированных режимов окон в программах.

 

Инструменты

Как уже говорилось, выбор подходящего средства является ключом к быстрому и эффективному решению проблемы. Ниже содержится таблица наиболее распространенных средств диагностики и анализа приложений.
Инструмент Назначение Источник
Computer Management –
System Information
Генерирует детальное описание конфигурации системы В составе Windows 2000 Server
DDE Spy/Spy++ Графическое представление потоков, процессов, окон, сообщений Microsoft Visual Studio
Dependency Walker
(depends.exe)
Перечисляет все DLL, используемые процессом, включая версию и размещение Microsoft Visual Studio
Dr. Watson Трассировка стека и необработанных исключений В составе Windows 2000 Server
Event Viewer Журнал событий Windows В составе Windows 2000 Server
GDI Explorer Мониторинг использования GDI каждым процессом Внутренняя утилита Microsoft.
Обратитесь за ее получением к ним.
GPO Tool Проверка доступности контроллера домена с клиента Windows 2000 Resource Kit
Gpresult Выводит информацию о том, какое влияние оказывает примененная политика на компьютер и пользователя Windows 2000 Resource Kit
Handle Выводит список файлов, открытых каждым процессом в системе http://www.sysinternals.com/
Listdlls Выводит список DLL, используемых каждым проессом, включая версию и размещение http://www.sysinternals.com/
Microsoft Visual Studio 6.0 Интегрированная среда разработки Microsoft, предназначенная для разработки программ на C/C++, Java, VB и пр. Содержит необходимые средства отладки. http://www.microsoft.com
Netstat Выводит статистику протокола tcp/ip и текущие соединения В составе Windows 2000 Server
ODBC Trace Пишет в журнал последовательность вызовов функций ODBC В составе Windows 2000 Server
Performance Monitor Мониторинг производительности В составе Windows 2000 Server
Ping Проверяет доступность связи через сеть удаленных устройств В составе Windows 2000 Server
Rational PurifyPlus Профилировщик производительности и утилита определения утечки памяти http://www.rational.com/
Regmon/Filemon Выводит информацию о попытках доступа к файлу/реестру http://www.sysinternals.com/
Secedit Используется для анализа безопасности В составе Windows 2000 Server
Task Manager Счетчик использования CPU, памяти, дисков и т.п. в реальном времени. Также выдает список всех процессов. В составе Windows 2000 Server
Telnet Виртуальный терминал, который можно использовать для проверки открытости порта tcp/ip В составе Windows 2000 Server
Tracert Утилита трассировки маршрута TCP/IP В составе Windows 2000 Server
WMI Запрос и установка информации о настольных системах, приложениях, сетях и пр. компонентах через программный интерфейс В составе Windows 2000 Server
Wngdbg Отладчик Windows Debugging Tools

Пример

В нашем примере CCS, Microsoft Consulting и Acme работали над проблемой с одним приложением. Компания Acme включала в себя разнообразные ресурсы из сетей, приложений, Windows 2000 и MetaFrame.

Суть проблемы

Acme столкнулась с ошибкой при использовании их приложения Winbroker в MetaFrame, что вызывало сообщение об ошибке "Not enough System Resources to create window." ("Недостаточно системных ресурсов для создания окна"). За ошибкой следовал крах программы. Также наблюдалась другая проблема, при которой в Winbroker постоянно создавались ресурсы GDIObject при генерации отчета.

Отправная точка.

Acme установила последнюю версию своего клиент-серверного приложения под названием WinBroker. WinBroker разработан с использованием Centura TeamDeveloper и Gupta SQLWindow, и далее подогнана с использованием языка SQLWindows. Версии TeamDeveloper и SQLWindows были не сертифицированы для работы под Windows 2000 Terminal Services или MetaFrame, а продавец не поддерживает приложения на этих платформах. В Acme есть несколько версий приложения WinBroker, лишь в последнем замечена такая проблема.

Среда MetaFrame состоит из Windows 2000 Server SP2 и MetaFrame XP Feature Release 1. Приложение опубликовано через NFuse 1.61 с Project Columbia. Кроме того, для связи с удаленным офисом через интернет используется Citrix Secure Gateway.

На рабочем столе Windows 2000 эта проблема не возникает. Она также не возникает в среде Terminal Services при использовании клиента RDP и при запуске с рабочего стола или в фиксированном окне MetaFrame. Acme не может последовательно воспроизвести ошибку.

Понимание симптомов.

После исследований стало понятным, что фактически существуют две разные проблемы. Постоянное выделение ресурсов GDIObject происходит при открытии в приложении диалогового окна. GDIObjects продолжает выделяться, когда эти окна (т.е. окна Report Progress Bar и Winbroker login) остаются открытыми, и объект не удаляется при закрытии окон. Количество объектов GDIObjects могло лекго подскочить до 9000 за короткий промежуток времени. Когда их количество достигало порогового значения, приложение генерировало ошибку “Not enough System Resources to create window”.

Во время исследований Microsoft предоставил утилиту GDI Explorer для детального анализа ресурса GDI. Это позволило выяснить, что однажды при открытии в WinBroker окна диалог стал постоянно генерировать картинки, что вызвало потоянное предоставление ресурсов GDI. Разрабочик был извещен о таком поведении. К настоящему времени причина этого неизвестна.

Воспроизведение ошибки

До визита в CCS, Acme была проинструктирована попробовать повторить ошибку. Все задачи выполнялись при использовании Task Manager для мониторинга потребления ресурсов GDI в WinBroker и ассоциированным сеансом. Использовался тестовый сервер.

WinBroker проверен в Terminal Services через сеанс RDP и ошибка не возникала. Также WinBroker был проверен в рабочем столе MetaFrame и в фиксированном окне, и ошибка тоже не возникала. В обоих случаях потребление GDI оставалось стабильным. Но как только WinBroker был опробован в “seamless”-окне, как ошибка появилась.

Создание гипотез

CCS и Acme обсудили результаты и разработали следующие шаги:

  1. Проверить - нет ли в коде утечки памяти; если оно предоставляет память для картинок. Разработчик просмотрел код и не нашел логики, постоянно генерирующей картинки. На основании имеющихся симптомов он воспользовался происком в интернет и нашел решение - передавать опцию WM_QUERYDRAGICON при создании диалоговых окон в WinBroker. Была применена предложенная заплата, которая, кажется, решила проблему.
  2. Проверить - нет ли заплат для seamless-окон. Консультанты CCS были знакомы с проблемой seamless-окон и обратились к своим внутренним ресурсам за заплатами. В одной из статей они нашли, как добавить обработку исключений в реестр.
  3. Проверить - не вызвана ли эта ошибка каким-нибудь пакетом обновлений или заплатой от Citrix или Micrososoft. Но ничего не ставилось.
  4. Проверить - правильные ли используются версии DLL. CCS вместе с Acme проверили версии DLL и убедились, что они правильных версий.
  5. Проверить - влияет ли настройка ICA (глубина цвета, разрешение, размер графического буфера). Положительных результатов получено не было.

В результате выяснилось, что фикс #1 вылечил проблему.

Выбор инструментов

Сначала использовался Task Manager для наблюдения за использованием GDI; perfmon не использовался поскольку он не может отследживать GDI. Однако, далее потребовалась более подробная информация о потреблении GDI. Microsoft предоставил более продвинутую утилиту GDI explorer.

Внедрение решения

Вначале решение было внедрено на пилотной установке и проверено настоящими пользователями. Это потребовало пару дней. Затем необходимые изменения были сделаны в оставшемся коде приложения.


Возврат