По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Управление компьютерными сетями - дело непростое. В последние годы всеобщая компьютеризация вызвала огромный скачок в расширении компьютерных сетей. Это добавило работы системному администратору. Ведь если ранее были распространены небольшие сети, то добавление и настройка новых устройств, либо обновление ПО на уже находящихся требовали ручной настройки операционной системы, а то и установки на каждом из них. Это требовало времени и нервов администратора. Сейчас же, когда сети насчитывают сотни, а то и тысячи машин, ручная настройка требует либо участия многих специалистов (а это порождает проблему плохой совместимости согласно человеческому фактору, каждый админ мыслит по-своему), либо очень долгого времени, если этим будет заниматься один специалист.
Такая проблема, с учетом технического прогресса, породила решение об автоматизации. На сегодняшний день существует специализированное программное обеспечение, которое позволяет присоединиться к удаленным машинам, и в автоматическом режиме произвести настройки операционной системы для корректной работы сети. Однако, как быть, если на нужных компьютерах в рамках одной сети установлены разные операционные системы? Ведь сейчас компьютеры под Linux, FreeBSD и Windows, объединенные в одну сеть - далеко не редкость. Поэтому одним из требований к управляющей программе стала кроссплатформенность. В этом случае одним из самых эффективных решений является такая программа, как Puppet.
Puppet это один из самых нужных инструментов сетевого администратора. Это приложение создано специально для управления конфигурацией операционных систем внутри одной сети. Оно имеет клиент-серверную архитектуру, то есть администратор, находящийся за сервером, может отправлять данные конфигурации на периферийные машины, на которых установлена клиентская часть. На этих рабочих станциях система в автоматическом режиме сконфигурирует себя в соответствии с присланными с сервера настройками.
Важным моментом является кроссплатформенность. Простота настройки и управления самыми распространенными операционными системами делает Puppet одним из самых актуальных решений по управлению компьютерными сетями на сегодняшний день.
Как же работает Puppet? Разберем подробнее. Для начала, на сервер нужно установить серверную часть программы. Поскольку приложение написано на Ruby, на серверной рабочей станции обязательно должна быть установлена нужная программная среда.
Серверная часть программы создана для хранения манифестов так в программной терминологии Puppet называются файлы с настройками конфигурации. В процессе работы сервер принимает обращения с клиентских машин и автоматически отсылает им обновленные файлы конфигурирования ОС для работы в сети.
На клиентских компьютерах также должно быть установлено программное обеспечение Puppet, уже в виде клиентской части. Как правило, данные установочные пакеты включаются в саму операционную систему, что позволяет быстро развертывать компьютерную сеть, однако, в случае их отсутствия, придется скачивать необходимую сборку с сайта разработчика.
Дополнительное удобство данного решения в том, что один администратор с помощью сервера может осуществить настройку и управление сотен и тысяч машин, объединенных в сеть. Если возникнут какие-то проблемы, то отклик с мест позволит админу быстро поправить код и устранить их. Хотя в данном случае возрастают требования к внимательности админа - одна неверно написанная строка кода конфигурации может привести к неполадкам по всей сети. Хотя, если разобраться, в данном случае можно запустить работающий манифест предыдущей сборки и восстановить все достаточно оперативно.
В сегодняшней статье рассмотрим модуль, который позволяет просматривать детальную информацию о сервере IP-АТС Asterisk и о процессах, которые на нем запущены прямо из web-интерфейса FreePBX - Asterisk Info. Все примеры в данной статье будут приводиться с использованием FreePBX 13. Ту же самую информацию можно получить, используя командную строку Asterisk – CLI (Command Line Interface). Сразу отметим, что данная информация будет понятна и полезна только продвинутым пользователям Asterisk и системным администраторам, например, при траблшутинге проблем.
Модуль Asterisk Info
Перейдём в модуль и рассмотрим его функционал. Модуль доступен по следующему пути с главной страницы Reports -> Asterisk Info
Как только мы переходим в модуль, перед нами открывается страница Summary. Здесь находится следующая информация:
Uptime – Показывает как долго сервер работает без отключения и рестарта
Reload - Показывает, когда последний раз была выполнена перезагрузка сервера. Перезагрузка происходит после нажатия на кнопку Apply Config, которая появляется после внесения изменений в конфигурацию через вэб-интерфейс
Active SIP Channels -Показывает, как много на сервере активных SIP каналов. Не надо путать с активными звонками.
Active IAX2 Channels – Показывает количество активных IAX2 каналов
SIP Registry - Показывает количество SIP транков, которые зарегистрированы на сервере
IAX2 Registry - Показывает количество IAX2 транков, которые зарегистрированы на сервере
SIP Peers - Показывает количество зарегистрированных SIP пиров. Пир – это внутренний номер (Extension) или транк (Trunk)
IAX2 Peers - Показывает количество зарегистрированных IAX2 пиров.
Справа можно выбрать другой тип отчета.
Registries
Данный отчет показывает каждое соединение, на которое зарегистрирован сервер Asterisk. Обычно здесь находится информация о транках. Этот отчёт показывает, на что зарегистрирован сервер, но не что зарегистрировано на нем, эту информацию следует искать во вкладке Peers.
Channels
Здесь выводится информация о каждом активном канале на сервере. Канал – это одно двустороннее соединение между двумя устройствами.
Peers
Здесь выводится информация о каждом устройстве, транке, внутреннем номере, которое зарегистрировано на сервере Asterisk.
SIP Info
Данный отчёт суммирует предыдущие два Registry и Peers, но выводит информацию только по SIP.
IAX Info
Данный отчёт суммирует Registry и Peers, но выводит информацию только по IAX2.
Conferences Report
Данный отчёт показывает информацию о любых активных конференциях на сервере.
Subscription Report
Показывает список всех подсказок (hints), которые созданы на сервере. Подсказка это то, на что подписана BLF кнопка на телефоне.
Voicemail Users Report
Показывает информацию о голосовой почте пользователей. Например, как много новых сообщений поступило.
Queues
Показывает информацию по очередям. Например, сколько сейчас звонков находится в очереди.
Full Report
Показывает информацию из всех предыдущих вкладок в одном окне.
В этой статье рассмотрим как решить следующие неисправности:
При подключении к vCenter Server с помощью веб-клиента vSphere и при переходе к Домашней странице -> Сеть и безопасность возникают следующие симптомы:
Нет доступных менеджеров NSX.
В разделе "Сеть и инвентаризация безопасности" отображается сообщение о том, что менеджеры NSX имеют значение 0.
При выборе NSX Home появляется сообщение об ошибке:
No NSX Managers available. Verify current user has role assigned on NSX Manager
Сбой отмены регистрации и повторной регистрации службы поиска в NSX Manager.
Вы видите ошибку:
NSX Management Service operation failed. Initialization of Admin Registration Service Provider failed. Root Cause: NSX Manager and Lookup service clocks are not in sync. They need to be synchronized. Please check NTP configuration
Эта проблема возникает, когда vCenter Server и разрешение неправильно настроены для учетной записи, в которой выполнен вход.
Решение
Чтобы устранить эту проблему, правильно настройте разрешение для учетной записи.
Чтобы правильно настроить разрешение для учетной записи:
Войдите в диспетчер NSX с помощью веб-интерфейса пользователя.
Щелкните Manage vCenter Registration (Управление регистрацией vCenter).
Перейдите в раздел COMPONENTS > NSX Management (Компоненты -> Служба управления NSX).
Убедитесь, что сервер vCenter настроен правильно.
Также убедитесь, что разрешение настроено правильно для учетной записи, в которой выполнен вход.
Примечания:
Убедитесь, что та же проблема возникает с учетной записью administration@vsphere.local. Если диспетчер NSX виден с этой учетной записи, убедитесь, что учетная запись, которая имеет проблему, правильно настроена с разрешениями.
Проверьте, синхронизированы ли часы службы NSX Manager и Lookup.
Даже после того, как vCenter Server and Lookup Service покажет подключение в пользовательском интерфейсе NSX, выход из системы и возврат к ней с помощью учетной записи administrator@vsphere.local "Нет доступных менеджеров NSX", это может потребовать завершения существующих сеансов VC. Это можно сделать в веб-клиенте vSphere, перейдя на узел & кластеры. Выберите vCenter -> Manage -> Sessions (Управление) > Select All Sessions (кроме "This Session" (Этот сеанс)) -> Click Terminate Sessions (Завершить сеансы). Выйдите из системы и войдите обратно из сеанса. Убедитесь, что диспетчер NSX теперь виден.