Управление сервером — различия между версиями

Текущая версия на 09:35, 19 декабря 2014

Техническая документация / Администрирование / Общие Настройки / Системные настройки / Управление сервером

Поведение сервера после получения критической ошибки оборудования

Критической ошибкой оборудования считается получение кода возврата «ErrorDevice». Это происходит, если одна из плат, или один из серверов при обращении получил соответствующий код возврата от драйвера. Это возможно, если сбой произошел на одном из каналов, а также если сбой носит массовый характер.

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

Адрес web-сервера обновлений

Адрес сервера, на который система будет обращаться в случае необходимости обновить файлы через интернет. По умолчанию http://www.oktell.ru

Порт web-сервера обновлений

Порт web-сервера, по которому происходит обновление комплекса. По умолчанию «4058».

Идентификатор службы обновлений

Идентификатор службы, занимающейся обновлением комплекса Oktell. По умолчанию «UpdateServer».

Обновлять автоматически, время дня

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

Обновлять после запуска сервера, пауза, сек

Установка флага повлечет запуск процедуры сверки версий с web-сервером и закачки архива при наличии более новых файлов каждый раз при перезапуске сервера. Числовой параметр определяет паузу в секундах, которая пройдет с момента запуска комплекса до запуска процедуры обновления. После перезапуска сервера клиентские приложения начинают свою загрузку, а VoIP-гарнитуры и телефоны работают по UDP. Паузу необходимо использовать в случае, если после запуска сервера трафик достаточно высок и не следует усугублять ситуацию.

Перезапускать сервер автоматически после загрузки обновлений

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

Ожидать момента завершения всех коммутаций и служебных сценариев перед перезапуском

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

Сценарий IVR входа в ожидании перезапуска

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

Принудительный перезапуск сервера

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

Закрытие клиентов

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

Обновление комплекса в полуавтоматическом режиме из файла

По нажатию на кнопку будет запрошен файл-архив обновлений, из которого будет произведено копирование файлов и мгновенный перезапуск с применением новых сборок. В случае если установлен и сохранен параметр «Ожидать завершения всех коммутаций», сервер будет перезагружен в момент, когда число коммутаций будет нулевым. Запрета коммутаций самостоятельно сервер не производит. При необходимости самостоятельно на время переведите входящие вызовы в главном сценарии на файл с содержанием «Сервис временно недоступен, перезвоните через несколько минут», и осуществите запрет выхода в город через блокирование соответствующих служебных номеров.

Автоматическое обновление комплекса с сайта производителя

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

Обновление версии любым способом произведет копирование замещаемых файлов в каталог «SavedOldVersions», соответствующий текущей дате. Рекомендуется также проводить резервное копирование БД, поскольку обновление может повлечь изменения в БД и откат к предыдущей версии при существующей версии БД будет невозможен.

Размер скачиваемого архива зависит от того, насколько сильно различаются версии. В максимальном варианте архив может достигать 10МБ. В этой связи при некачественной интернет-связи не рекомендуется использовать метод обновления через интернет. Вместо этого лучше воспользоваться механизмом обновления из файла-обновления, который можно предварительно скачать с ftp-сервера http://ftp.oktell.ru или в разделе «Партнеры» на сайте http://www.telsystems.ru

Состав сервисного лог-журнала

Сервисный лог включает в себя все этапы работы сервера логики. Данным параметром регулируется его состав: какие режимы и модули производят логирование, а какие нет. Параметр представляет собой строку, каждая из позиций которой содержит «0» или «1» и отвечает за включение логирования конкретного режима.

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

Логирование счетчиков производительности

При активации в лог-журнал watcher сервера наравне с информацией о собственных процессах службы начинают фиксироваться стандартные счетчики производительности.

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

Базовыми считаются счетчики: общая загрузка процессора (0-100, %), объем доступной физической памяти (МБ), текущая очередь диска (0-10), процент использования файла подкачки.

В качестве пользовательских могут быть указаны любые другие счетчики, существующие и доступные в системе. Для их указания используются специальные ключи файлов конфигурации: <add key="PerformanceCounter{0}" value="category|counter|instance"/>, где {0} - числовой порядковый индекс счетчика производительности. В качестве значения для счетчика производительности, отслеживающего общую загрузку процессора, например, подставляется "Processor|% Processor Time|_Total". Для других счетчиков соответственно.

Логирование использования ресурсов

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

Логирование сбоев тактирования таймера

С помощью параметра можно настроить вывод в лог журнал WATCHER информации по выделению процессорного времени потокам системы. Вместе с основной деятельностью сервер постоянно проводит проверочные замеры тестовым таймером и засекает задержки в выдаче управления. В случае если операционная система отказывает в выделении службе сервера процессорного времени, это происходит и с тестовым таймером. Существует возможность выставить границу для его логирования. Среди вариантов границы задержки в 20 мс, 100 мс, 500 мс, 1 с и 5 с. По умолчанию логируются все задержки более 100 мс. Увеличение и уменьшение значения может потребоваться проводить в случае запроса из технической поддержки в ходе работ над поиском причин заметного некорректного поведения сервера.