По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы покажем, как собирать трейсы с Cisco Unified Communications Manager (CUCM) . Это используется для траблшутинга системы, а так же эта информация будет необходима TAC инженерам Cisco при заведении заявки.
Для того чтобы снять трейсы нам понадобится программа Real-Time Monitoring Tool. О том как ее установить можно прочитать в нашей статье.
Сначала идем в меню Cisco Unified Serviceability, и переходим во вкладку Trace → Configuration. Здесь выбираем наш сервер, в строке Server, в строке Service Group выбираем CM Services, а в строке Service указываем Cisco CallManager. Дефолтные настройки показаны на скриншоте.
Убедитесь, что галочка стоит в пункте Trace On, а в выпадающем меню Debug Trace Level выбран пункт Detailed.
Тоже самое нужно повторить на других серверах кластера, если они имеются.
Далее запускаем RTMT и подключаемся к нашему серверу. Тут переходим во вкладку System → Tools → Trace & Log Central. Нажимаем Collect Files и в открывшемся окне ставим галочки в строке Cisco CallManager выбрав необходимые сервера.
Нажимаем Next и в следующем окне ставим галочки в пунктах Event Viewer → Application Log и Event Viewer → System Log.
Далее необходимо выбрать временной промежуток снятия наших данных в поле Collection Time. В этом же окне, в поле Download File Options указываем папку, в которою все будет скачиваться.
Теперь можно нажать Finish и после сбора информации нужные нам файлы окажутся в указанной ранее папке.
В этой статье поговорим о локализации проблем функционирования ESXi/ESX.
Неисправности. Что может быть не так?
ПО, работающее в гостевой виртуальной машине - медленно реагирует на команды управления;
ПО, работающее в гостевой виртуальной машине, периодически прерывают работу;
Гостевая виртуальная машина работает медленно или не отвечает на запросы.
Проблемы с производительностью могут случаться из-за ограничений центрального процессора (CPU), переполнения памяти или, например, задержкой сети. Если виртуалки работают плохо, скорее всего имеют место траблы с памятью. Устраним?
Решение (воркэраунд)
Ограничения центрального процессора (проблемы CPU)
Чтобы определить, связана ли низкая производительность виртуалки с ограничением центрального процессора, надо:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки
Проверьте командой load average загрузку. Если среднее значение нагрузки равно 1.00 , то физические ЦП (центральные процессоры) гипервизора ESXi/ESX полностью используются, а среднее значение нагрузки, равное 0.5, значит, что используются наполовину. Логика, думаю, вам понятна. Значение нагрузки, равное 2.00, означает, что система в целом переполнена (бегите в серверную с огнетушителем 👀)
Проверьте поле %READY на процент времени на момент, когда виртуальная машина была готова, но не смогла запуститься на физическом ЦП. При нормальных условиях эксплуатации это значение должно находиться в пределах 5%. Если это значение высокое, и виртуальная машина имеет плохую производительность, тогда проверьте ограничение центрального процессора:
Убедитесь, что на виртуальной машине не установлен предел ЦП.
Убедитесь, что на виртуальной машине не установлен пул ресурсов (Resource Pool).
Если среднее значение нагрузки слишком высокое и время ожидания не вызвано ограничением центрального процессора, тогда отрегулируйте нагрузку ЦП на хост. Чтобы настроить нагрузку на хост, выполните следующие шаги:
Увеличьте значение физического ограничения ЦП на хост
Или уменьшите виртуальное ограничение ЦП, выделенное хосту. Чтобы уменьшить это ограничение, сделайте:
Уменьшите общее количество ЦП, выделенных всем виртуальным машинам, работающих на узле ESX
Или уменьшите количество виртуальных машин, работающих на хосте (но это весьма грубый способ, как мы считаем)
Если Вы используете ESX 3.5, проверьте доступ к IRQ.
Переполнение памяти
Чтобы определить, связана ли низкая производительность с избыточностью памяти:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки.
Проверьте параметр MEM в первой строке вывода. Это значение отражает отношение запрошенной памяти к доступной, минус 1. Например:
Если виртуальным машинам требуется 4 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то справедливо соотношение 1:1. После вычитания 1 (из 1/1) поле MEM overcommit avg считывает 0. Вывод - избытка нет и не требуется дополнительной оперативной памяти.
Если виртуальным машинам требуется 6 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то есть соотношение 1,5:1. После вычитания 1 (из 1,5/1), поле overcommit avg МЭМ считывает 0,5. Объем оперативной памяти превышен на 50%, что означает, что требуется на 50% больше доступной оперативной памяти.
Если память перегружается, отрегулируйте нагрузку на хост. Чтобы настроить нагрузку на память, выполните следующие действия:
Увеличьте количество физической оперативной памяти на хосте
Или уменьшите объем оперативной памяти, выделенной виртуальным машинам. Для уменьшения объема выделенной оперативной памяти:
Уменьшите общий объем оперативной памяти, выделяемой всем виртуальным машинам на узле
Или уменьшите общее число виртуальных машин на узле.
Определите, являются ли виртуальные машины "раздувающимися" или/и заменяемыми. Для обнаружения раздувания или замены:
Запустите esxtop
Введите m для просмотра памяти
Введите f для управления колонками вывода (полями)
Выберите букву J в поле Memory Swap Statistics "Статистика раздувания памяти" (MCTL)
Посмотрите на значение MCTLSZ. MCTLSZ (MB)отображает объем физической памяти гостя, возвращаемой драйвером баллона (Memory Ballooning).
Введите f для управления колонками вывода (полями)
Выберите букву для статистики свопов памяти (SWAP STATS)
Посмотрите на значение SWCUR. SWCUR (MB) отображает текущее использование обмена.
Чтобы устранить эту проблему, убедитесь, что раздувание и/или замена не вызваны неправильно установленным пределом памяти
Период ожидания запоминающего устройства
Чтобы определить, связана ли низкая производительность с задержкой хранения данных:
Определите, связана ли проблема с локальным хранилищем. Если связана, то перенесите виртуальные машины в другое место хранения.
Уменьшите количество виртуальных машин на одно логическое устройство.
Найдите записи журнала в Windows guests, которые выглядят следующим образом: The device, DeviceScsiPort0, did not respond within the timeout period.
Используя esxtop, найдите высокое время задержки DAVG.
Определите максимальную пропускную способность ввода-вывода, которую можно получить с помощью команды iometer.
Сравните результаты iometer для виртуальной машины с результатами для физической машины, подключенной к тому же хранилищу.
Проверьте наличие конфликтного обращения к ресурсу SCSI.
Если вы используете ресурсы хранения iSCSI и группу данных jumbo, убедитесь, что все настроено правильно.
Если вы используете ресурсы хранения iSCSI и передачу по нескольким трактам с использованием программного инициатора iSCSI, убедитесь, что все настроено правильно.
При выявлении проблемы, связанной с хранением:
Убедитесь, что аппаратный массив устройства и платы HBA сертифицированы для ESX/ESXi.
Убедитесь, что BIOS физического сервера обновлена.
Убедитесь, что встроенное ПО вашего HBA-адаптера обновлено.
Убедитесь, что ESX может распознать правильный режим и политику пути для типа массива хранения SATP и выбора пути PSP.
Задержка сети
На производительность сети может сильно влиять производительность ЦП. Исключите проблему производительности ЦП перед исследованием сетевой задержки.
Чтобы определить, вызвана ли низкая производительность задержкой сети, выполните следующие действия:
Проверьте максимальную пропускную способность виртуальной машины с помощью инструмента Iperf.
При использовании Iperf измените размер окон TCP на 64 K. Производительность также зависит от этого значения. Чтобы изменить размер окон TCP:
На стороне сервера введите следующую команду: iperf –s
На стороне клиента введите следующую команду: iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M
Запустите Iperf с компьютера вне хоста ESXi/ESX. Сравните результаты с ожидаемыми, в зависимости от физической среды.
Выполните команду Iperf с другого компьютера вне хоста ESXi/ESX в той же VLAN на том же физическом коммутаторе. Если производительность хорошая, и проблему можно воспроизвести только на машине в другом географическом месте, то проблема связана с вашей сетевой средой.
Выполните команду Iperf между двумя виртуальными машинами на одном сервере ESX/portgroup/vswitch. Если результат хороший, можно исключить проблему с ЦП, памятью или хранилищем.
Если вы определяете параметры, которые ограничивают производительность системы в сети:
Если вы используете ресурсы хранения iSCSI и кадры jumbo, убедитесь, что все настроено правильно.
Если вы используете Network I/O Control,то убедитесь, что общие ресурсы и ограничения правильно настроены для вашего трафика.
Проверьте правильность настройки формирования траффика.
Прочитайте материал про реактивное и упреждающее распределение достижимости в сетях.
Есть много случаев, когда более эффективно или в соответствии с конкретными ограничениями политики для плоскости управления изучать информацию о достижимости и топологии с другой плоскости управления, а не с помощью механизмов, описанных до этого момента в этой серии статей. Вот некоторые примеры:
Две организации должны соединить свои сети, но ни одна из них не хочет позволить другой контролировать политику и работу своих плоскостей управления;
Крупная организация состоит из множества бизнес-единиц, каждая из которых имеет возможность управлять собственной внутренней сетью в зависимости от местных условий и требований приложений.
Организация должна каким-то образом позволить двум плоскостям управления взаимодействовать при переходе от одной к другой.
Причины, по которым одна плоскость управления может получать информацию о доступности от другой, почти безграничны. Учитывая это требование, многие сетевые устройства позволяют операторам перераспределять информацию между плоскостями управления. При перераспределении достижимости возникают две проблемы, связанные с плоскостью управления: как обрабатывать метрики и как предотвращать петли маршрутизации.
Примечание. Перераспределение можно рассматривать как экспорт маршрутов из одного протокола в другой. На самом деле импорт/экспорт и перераспределение часто используются для обозначения одного и того же, либо разными поставщиками, либо даже в разных ситуациях одним и тем же поставщиком.
Перераспределение и метрики
Взаимосвязь между свойствами связи, политиками и метриками определяются каждым протоколом плоскости управления независимо от других протоколов. Фактически, более описательная или более полезная метрическая система - это то, что иногда привлекает операторов к определенному протоколу плоскости управления. На рисунке 12 показаны два участка сети, в которых работают две разные управляющие плоскости, каждая из которых использует свой метод расчета метрик связей.
Протоколы X и Y в этой сети были настроены с использованием двух разных систем для назначения показателей. При развертывании протокола X администратор разделил 1000 на скорость соединения в гигабитах. При развертывании протокола Y администратор создал "таблицу показателей" на основе наилучшего предположения о каналах с самой высокой и самой низкой скоростью, которые они могут иметь в течение следующих 10-15 лет, и назначил метрики для различных скоростей каналов в этой таблице. Результат, как показывает рисунок, несовместимые показатели:
10G каналы в протоколе X имеют метрику 100, в то время как в протоколе Y они имеют метрику 20.
100G-каналы как в протоколе X, так и в протоколе Y имеют метрику 10.
Предполагая, что более низкая метрика предпочтительна, если метрики добавлены, канал [B, C, F] будет считаться более желательным путем, чем канал [B, D, G]. Однако, если учитывать пропускную способность, оба канала будут считаться одинаково желательными.
Если между этими двумя протоколами настроено перераспределение, как следует обрабатывать эти метрики? Есть три общих решения этой проблемы.
Администратор может назначить метрику в каждой точке перераспределения, которая передается как часть внутренней метрики протокола. Например, администратор может назначить метрику 5 для пункта назначения E на маршрутизаторе C при перераспределении из протокола X в Y. Этот пункт назначения, E, вводится в протокол Y с метрикой 5 маршрутизатором C. На маршрутизаторе F метрика для E будет от 25 для C. В G стоимость достижения E будет 35 по пути [F, C]. Желательность использования любой конкретной точки выхода для любого конкретного пункта назначения выбирается оператором при назначении этих ручных метрик.
Метрика "другого" протокола может быть принята как часть внутренней метрики протокола. Это не работает в случае, когда один протокол имеет более широкий диапазон доступных метрик, чем другой. Например, если протокол Y имеет максимальную метрику 63, метрики 10G из протокола X будут "выше максимума"; ситуация, которая вряд ли будет оптимальной. При отсутствии такого ограничения маршрутизатор C внедрит маршрут к E со стоимостью 100 в протокол Y. Стоимость достижения E на маршрутизаторе F составит 110; стоимость в G будет от 130 до [F, C].
Примечание. Здесь вы можете увидеть компромисс между состоянием плоскости управления и оптимальным использованием сети, это еще один пример компромисса сложности при проектировании реальных протоколов. Перенос внешней метрики в отдельное поле добавляет состояние плоскости управления, но позволяет более оптимально управлять трафиком через сеть. Назначение или использование внешней метрики снижает состояние плоскости управления, но за счет возможности оптимизации потока трафика.
Внешняя метрика может быть перенесена в отдельное поле, поэтому каждое сетевое устройство может отдельно определять лучший путь к каждому внешнему адресату. Это третье решение является наиболее широко используемым, поскольку оно обеспечивает наилучшую возможность управления трафиком между двумя сетями. В этом решении C вводит достижимость для E с внешней стоимостью 100. В F есть две метрики в объявлении, описывающие достижимость для E; внутренняя метрика для достижения точки перераспределения (или выхода) - 20, а метрика для достижения точки E во внешней сети - 100. В G внутренняя метрика для достижения точки выхода - 30, а внешняя метрика - 100.
Как реализация будет использовать оба этих показателя? Следует ли протоколу выбирать ближайшую точку выхода или, скорее, самую низкую внутреннюю метрику? Это позволит оптимизировать использование локальной сети и потенциально деоптимизировать использование сетевых ресурсов во внешней сети. Должен ли протокол выбирать точку выхода, ближайшую к внешнему назначению, или, скорее, самую низкую внешнюю метрику? Это позволит оптимизировать сетевые ресурсы во внешней сети, потенциально за счет деоптимизации использования сетевых ресурсов в локальной сети. Или протоколу следует попытаться каким-то образом объединить эти две метрики, чтобы максимально оптимизировать использование ресурсов в обеих сетях?
Некоторые протоколы предпочитают всегда оптимизировать локальные или внешние ресурсы, в то время как другие предоставляют операторам возможность конфигурации. Например, протокол может позволять переносить внешние метрики в виде метрик разных типов, при этом один тип считается большим, чем любая внутренняя метрика (следовательно, сначала предпочтение отдается самой низкой внутренней метрике и использование внешней метрики в качестве средства разрешения конфликтов), а другой тип - это когда внутренние и внешние метрики считаются эквивалентными (следовательно, добавляются внутренние и внешние метрики для принятия решения о пути).
Перераспределение и петли маршрутизации
В приведенном выше обсуждении вы могли заметить, что места назначения, перераспределенные с одного протокола на другой, всегда выглядят так, как будто они подключены к перераспределяющему маршрутизатору. По сути, перераспределение действует как форма резюмирования (что означает, что удаляется информация о топологии, а не информация о достижимости), как описано ранее в этой серии статей. Хотя этот момент не является критическим для показателей перераспределения, важно учитывать способность плоскости управления выбирать оптимальный путь. В некоторых конкретных случаях деоптимизация может привести к тому, что плоскость управления не сможет выбрать пути без петель. Рисунок 13 демонстрирует это.
Чтобы построить петлю маршрутизации в этой сети:
Маршрут к хосту A перераспределяется от протокола X к Y с вручную настроенной метрикой 1.
Маршрутизатор E предпочитает маршрут через C с общей метрикой (внутренней и внешней) 2.
Маршрутизатор D предпочитает маршрут через E с общей метрикой 3.
Маршрутизатор D перераспределяет маршрут к хосту A в протокол X с существующей метрикой 3.
Маршрутизатор B имеет два маршрута к A: один со стоимостью 10 (напрямую) и один с метрикой от 4 до D.
Маршрутизатор B выбирает путь через D, создавая петлю маршрутизации.
И так далее (цикл будет продолжаться, пока каждый протокол не достигнет своей максимальной метрики).
Этот пример немного растянут для создания цикла маршрутизации в тривиальной сети, но все циклы маршрутизации, вызванные перераспределением, схожи по своей структуре. В этом примере важно, что была потеряна не только топологическая информация (маршрут к A был суммирован, что, с точки зрения E, было непосредственно связано с C), но и метрическая информация (исходный маршрут со стоимостью 11 перераспределяется в протокол Y со стоимостью 1 в C). Существует ряд общих механизмов, используемых для предотвращения формирования этой петли маршрутизации.
Протокол маршрутизации всегда может предпочесть внутренние маршруты внешним. В этом случае, если B всегда предпочитает внутренний маршрут A внешнему пути через D, петля маршрутизации не образуется. Многие протоколы маршрутизации будут использовать предпочтение упорядочивания при установке маршрутов в локальную таблицу маршрутизации (или базу информации о маршрутизации, RIB), чтобы всегда отдавать предпочтение внутренним маршрутам над внешними. Причина этого предпочтения состоит в том, чтобы предотвратить образование петель маршрутизации этого типа.
Фильтры можно настроить так, чтобы отдельные пункты назначения не перераспределялись дважды. В этой сети маршрутизатор D может быть настроен для предотвращения перераспределения любого внешнего маршрута, полученного в протоколе Y, в протокол X. В ситуации, когда есть только два протокола (или сети) с перераспределенной между ними информацией плоскости управления, это может быть простым решением. В случаях, когда фильтры необходимо настраивать для каждого пункта назначения, управление фильтрами может стать трудоемким. Ошибки в настройке этих фильтров могут либо привести к тому, что некоторые пункты назначения станут недоступными (маршрутизация черных дыр), либо приведет к образованию петли, потенциально вызывающей сбой в плоскости управления.
Маршруты могут быть помечены при перераспределении, а затем отфильтрованы на основе этих тегов в других точках перераспределения. Например, когда маршрут к A перераспределяется в протокол Y в C, маршрут может быть административно помечен некоторым номером, например, 100, чтобы маршрут можно было легко идентифицировать. На маршрутизаторе D можно настроить фильтр для блокировки любого маршрута, помеченного тегом 100, предотвращая образование петли маршрутизации. Многие протоколы позволяют маршруту нести административный тег (иногда называемый сообществом или другим подобным именем), а затем фильтровать маршруты на основе этого тега.