Беспроводные сети : Cisco Policy Suite for BNG

Журналы и информация, требуемая в случае сбоя системы QPS

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает шаги, которые должны быть выполнены для получения информации, когда происходят сбой системы Комплекта политики Quantum (QPS) или катастрофический отказ. Если аппаратные средства, программное обеспечение и требования виртуальной машины встречены, маловероятно, что QPS завершится катастрофическим отказом.

Внесенный Aravindhan Balasubramian, Тони Пиной, и Винодкумаром Тивари, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

  • Выпуск 5.5 QPS и позже.

Примечание: Определенные, некоторый журналы не появятся в версиях QPS, более старых, чем Выпуск 5.5 QPS.

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

Получение информации

Если сбой системы QPS происходит, соберите эту информацию:

Диагностика и журналы отладки

  1. Войдите к Политике и Заряжающей Функции Правил (PCRF) в виртуальную машину клиента (например, pcrfclient01) и соберите диагностическую информацию (например,  /opt/broadhop/installer/diag/diagnostics.sh).
  2. Войдите к клиентской виртуальной машине PCRF и соберите отладочную информацию. Отладочная информация включает консолидированный журнал QNS, svn repo, и элементы конфигурации QNS. Удостоверьтесь, что объединенные журналы покрывают время сбоя системы и что уровень отладки установлен в logback.xml файле. 
  3. Соберите эти выходные данные от QPS (например, Выполнение/opt/broadhop/installer/diag/zip_debug_info.sh и выходные данные сохранены в/var/tmp/debug_info <дата> .zip).
  4. Войдите к экземпляру виртуальной машины QPS, где произошел сбой системы. (например, pcrfclient0x, lb0x, qns0x, portal0x). Соберите журналы QNS и удостоверьтесь, что журнал QNS включает время сбоя системы. (например, кошка/etc/broadhop/license/QUANTUM201311210402429360.lic).

Лицензионные сведения QPS

  1. Войдите к клиентской виртуальной машине PCRF и соберите лицензионные сведения QPS. QPS обычно лицензируется для определенной функции и существует максимальное число параллельных сеансов, которые это поддерживает. QPS также имеет дату окончания действия для этой функции.
  2. Перейдите к этому каталогу:/etc/broadhop/license и перехват выходные данные лицензии (.lic) файл. (например, кошка/etc/broadhop/license/QUANTUM201311210402429360.lic).

Статистика системы

  1. Перехватите статистику системы (Пример: ЦПУ, память, использование диска).
  2. Войдите к клиентской виртуальной машине PCRF и соберите выходные данные. Пример :/opt/broadhop/control/top_qps.sh
  3. Войдите к виртуальной машине, которая соответствует (например,  pcrfclient0x, lb0x, qns0x), и перехватите эту статистику системы:

    кошка/proc/meminfo> Выделенные данные памяти
    свободный-s 60> статистика Памяти в течение каждой минуты
    vmstat 1> состояние ЦП в течение каждой минуты
    ps-aux | возглавляет-10> Лучшие 10 сведений о процессе, который использует большую часть загрузки ЦПУ
    swapon-s> подкачивают меню Usage Summary для каждого устройства
    . du-a | вид-n-r | возглавляют-n 10> Лучшие 10 файлов / каталоги, занимающие больше места

  4. Вход в систему к sessionmgr виртуальной машине и собирает выходные данные mongostat и mongotop, который поможет, чтобы устранить неполадки, отнесена ли проблема к базе данных или нет.

Конфигурация потока в разработчике политики

Войдите разработчику политики и перейдите к Справочным данным> Система 1> Сменные Конфигурации> Поточная обработка Конфигурации. 

Количество потоков могло бы колебаться от 40 до 50 для TPS, но является меньше чем 1,000. Максимальное число потоков, которые можно настроить, равняется 50. При увеличении числа потоков это влияет на производительность системы. 

Журнал фатальной ошибки

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

Журнал фатальной ошибки включает эту информацию:

  • Операционное исключение или сигнал, который вызвал фатальную ошибку
  • Версия и сведения о конфигурации
  • Подробные данные о потоке, который вызвал фатальную ошибку и трассировку стека потока
  • Список выполнения потоков и их состояния
  • Сводная информация о "куче"
  • Список собственных библиотек загрузился
  • Аргументы командной строки
  • Переменные среды
  • Подробные данные об операционной системе (OS) и процессоре (CPU)

Название файла журнала по умолчанию придерживается этого формата: <pid> .log hs_err_pid и генерируется в рабочем каталоге, где запустились соответствующие процессы Java. Пример: рабочий каталог пользователя, когда пользователь запустил процесс QNS.

Если вы не знаете рабочий каталог, ищете систему файл с название hs_err_pid*.log и исследуете файл какое-то время, который совпадает, когда произошла ошибка.

Выполните эти шаги для определения местоположения для фатальной ошибки:

  1. Войдите к pcrfclient01 виртуальной машине
  2. Откройте jvm.conf (например, vms/etc/broadhop/pcrf/jvm.conf).
  3. Добавьте опцию: -XX:ErrorFile = <каталог> / <имя файла> %p.log к списку и удостоверяются, что путь указанного каталога существует и что у пользователя QNS есть полные полномочия по тому каталогу . Пример : X : ErrorFile =/home/qns/fatal_error%p.log
  4. Если файлы conf в pcrfclient01:/etc/broadhop не находятся в синхронизации с файлами conf в/etc/broadhop на VM, выполняющих сервис QNS, команда syncconfig.sh может вызвать много проблем. syncconfig.sh возьмет файлы pcrfclient01:/etc/broadhop conf и по записи файлы conf в/etc/broadhop на VM, выполняющих QNS. 

    warningПредупреждение: Команда synconfig.sh возьмет файлы pcrfclient01:/etc/broadhop conf и перезапишет все файлы conf в/etc/broadhop на виртуальных машинах , выполняющих сервис QNS (ifor пример, iomgr01, iomgr02, qns01, qns02, и т.д.)

  5. Перезапустите приложение QNS и введите команду restartall.sh

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.