По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Cisco Unity Connection (CUC) это решение, которое создано для обеспечения обмена голосовыми сообщениям в корпоративной сети и удовлетворения целого множества других бизнес – требований. Пользователи CUC могу прослушивать оставленные для них голосовые сообщения с помощью телефона, технологий по распознаванию речи и множества других клиентских приложений. Гибкий интерфейс администратора, позволяет легко настраивать приложения для конвертации текста в речь с целью удовлетворения бизнеса.
CUC – масштабируется до 20 000 пользователей в рамках одного сервера. Если необходима поддержка большего количества пользователей, решение позволяет одновременно разворачивать до 10 серверов а так же поддерживает кластеризацию.
Начиная с версии 8.5, поддерживается Unified Messaging, который обеспечивает синхронизацию голосовой почты с Exchange сервером.
С версии 7.x, CUC поддерживает кластерные пары модели «active-active», в рамках которой обеспечивается высокий показатель отказоустойчивости и масштабируемости по сравнению с единичным сервером. Важно отметить, что Cisco Unity поддерживает протокол VPIM (Voice Profile for Internet Mail), который описан в RFC 2423 и RFC 3801 и обеспечивает использование различных платформ для голосовой почты таких производителей как Cisco, Nortel или Avaya, в рамках одной сети.
Для организаций, которым не нужна крупная и сильно производительная система, существует возможность инсталляции CUC как части Cisco Unified Communications Manager Business Edition, который совмещает в себе функционал CUCM и CUC в рамках единого сервера, с возможностью поддержки до 500 телефонных аппаратов и пользователей голосовой почты и 24 порта Unity Connection. Разработанный специально для среднего бизнеса, Business Edition не обладает такими высокими показателями масштабируемости и отказоустойчивости, однако является привлекательным решением с точки зрения цены и удобства администрирования.
Администраторы, которые поработил с интерфейсом Cisco Unified Communications Manager смогут оценить достоинства интерфейса CUC. Так же как и CUCM, Unity использует операционную систему на базе Linux с базой данных IBM Informix. Схожесть интерфейса, обеспечит быструю адаптацию администратора к интерфейсу Unity Connection.
Более того, многие конфигурационные параметры настраиваются идентично на CUCM и CUC, например, такие как настройка интеграции с AD по протоколу Lightweight Directory Access Protocol (LDAP).
Итог
В итоге, хочется подчеркнуть следующие особенности Cisco Unity Connection:
Обеспечение обмена голосовой почтой для 20 000 пользователей в рамках одного сервера.
CUC использует VPIM для увеличение числа пользователей (свыше 20 000)
Cisco Unity Connection использует ОС Linux и базу данных IBM Informix для хранения конфигурации и сообщений.
Всем привет! Недавно мы рассказывали об операционной системе Cisco IOS, которая работает на устройствах Cisco. Сегодня мы расскажем про особенности её интерфейса командной строки (CLI).
Операционная система Cisco IOS использует иерархическую систему режимов, по которым нужно переходить во время работы.
Основными режимами являются:
Пользовательский режим User executive (User EXEC) mode
Привилегированный режим Privileged executive (Privileged EXEC) mode
Глобальный режим конфигурации Global configuration mode
Другие режимы конфигурации, такие как режим конфигурации интерфейса
Каждый режим имеет свои отличия и используется для выполнения определенных задач, с определенным набором команд, доступных только для этого режима. Например, глобальный режим конфигурации позволяет настраивать параметры на устройстве, которые влияют на устройство в целом, например изменение имени устройства. Если нужно изменить параметры определенного порта, то необходимо войти в режим конфигурации интерфейса для этого порта. Все команды, введенные в режиме настройки интерфейса, применяются только к этому порту. Иерархическую структуру можно настроить для обеспечения безопасности - для каждого режима можно настроить различную аутентификацию.
Двумя основными режимами работы являются режим User EXEC и режим Privileged EXEC. В качестве безопасности IOS разделяет сессии EXEC на два уровня доступа, и привилегированный режим Privileged EXEC позволяет выполнять больше команд, влияющих на устройство.
Режим User EXEC
Режим пользователя User EXEC имеет ограниченные возможности, но может быть полезен для некоторых основных операций. Режим User EXEC находится на самом базовом уровне иерархической структуры и является первым режимом, возникающим при входе в CLI устройства. Он допускает только ограниченное количество основных команд мониторинга и не позволяет выполнять какие-либо команды, которые могут изменить конфигурацию устройства. По умолчанию для доступа к режиму User EXEC с консоли не требуется аутентификация. User EXEC идентифицируется подсказкой CLI, которая заканчивается символом ”>”. Выглядит это так:
Switch>
Режим Privileged EXEC
Выполнение конфигурационных команд требует использование привилегированного режима Privileged EXEC или более конкретного режима в иерархии. Это означает, что нужно сначала войти в User EXEC, а оттуда в Privileged EXEC.
Этот режим можно определить по символу “#”. Например:
Switch#
Глобальный режим конфигурации и все другие, специфические режимы могут быть достигнуты только из привилегированного режима EXEC. Чтобы войти в него нужно ввести команду enable. Для возврата в пользовательский режим используется команда disable.
Глобальный режим конфигурации
Основной режим конфигурации называется Global Configuration. В глобальном режиме конфигурации выполняются команды, которые влияют на работу устройства в целом. Доступ к глобальному режиму осуществляется перед доступом к определенным режимам конфигурации.
Для перехода устройства из привилегированного режима Privileged EXEC в режим Global Configuration используется команда:
Switch# configure terminal
После ее выполнения устройство перейдет в режим конфигурации:
Switch(config)#
Особые режимы конфигурации
Из режима глобальной конфигурации можно войти в различные режимы подконфигурации. Каждый из этих режимов позволяет конфигурировать определенную часть или функцию устройства. Например, режим интерфейса (настройка одного из сетевых интерфейсов - Fa0/0, S0/0/0)) или режим линии (настройка одной из физических или виртуальных линий - консоль, AUX, VTY).
Switch(config)# Interface FastEthernet 0/0
Switch(config-if)#
Чтобы выйти из определенного режима конфигурации и вернуться в режим глобальной конфигурации Global Configuration, нужно ввести exit в командной строке. Чтобы полностью выйти из режима конфигурации и вернуться в режим Privileged EXEC, нужно ввести end или использовать последовательность клавиш Ctrl-Z.
Сегодня в статье рассказываем про плагин kubectl, который использует tmux, чтобы быстрее устранить неполадки Kubernetes.
Kubernetes - это процветающая платформа для взаимодействия контейнеров с открытым исходным кодом, которая обеспечивает масштабируемость, высокую доступность, надежность и отказоустойчивость приложений. Одной из его многочисленных функций является поддержка запуска пользовательских сценариев или двоичных файлов через основной двоичный файл клиента, kubectl. Kubectl очень мощный, и позволяет пользователям делать с ним все, что они могли бы сделать непосредственно в кластере Kubernetes.
Устранение неполадок с псевдонимами Kubernetes
Каждый, кто использует Kubernetes для управления контейнерами, знает о его особенностях - а также о сложности, причиной которого является его дизайн. Например, существует острая необходимость упростить поиск и устранение неисправностей в Kubernetes с помощью чего-то более быстрого и практически не требующего ручного вмешательства (за исключением критических ситуаций).
Существует много сценариев, которые следует учитывать при устранении неполадок. В одном сценарии вы знаете, что нужно запускать, но синтаксис команды - даже если она может выполняться как одна команда - чрезмерно сложен, или для работы может потребоваться один-два входа.
Например, если часто требуется перейти в запущенный контейнер в пространстве имен System, вы можете неоднократно писать:
kubectl --namespace=kube-system exec -i -t <your-pod-name>
Для упрощения поиска и устранения неисправностей можно использовать псевдонимы этих команд в командной строке. Например, можно добавить следующие файлы dotfiles (.bashrc или .zshrc):
alias ksysex='kubectl --namespace=kube-system exec -i -t'
Это один из многих примеров из хранилища общих псевдонимов Kubernetes, который показывает один из способов упрощения функций в kubectl. Для чего-то простого, подобного этому сценарию, достаточно псевдонима.
Переключение на подключаемый модуль kubectl
Более сложный сценарий устранения неполадок включает в себя выполнение множества команд, одной за другой, для исследования среды и выведения заключения. Одних псевдонимов недостаточно для этого варианта использования; необходима воспроизведение логического узла и корреляция между многими частями развертывания Kubernetes. На самом деле вам нужна автоматизация для получения нужного результата за меньшее время.
Рассмотрим пространства имен от 10 до 20 или даже от 50 до 100, содержащие различные микросервисы в вашем кластере. Что поможет вам начать устранение неполадок в этом сценарии?
Вам потребуется что-то, что может быстро определить, какой модуль в каком пространстве имен вызывает ошибки.
Вам понадобится что-то, что сможет просматривать журналы всех модулей в пространстве имен.
Также может потребоваться просмотр журналов определенных модулей в определенном пространстве имен, в котором были обнаружены ошибки.
Любое решение, охватывающее эти вопросы, было бы очень полезно при изучении производственных проблем, а также в ходе циклов разработки и тестирования.
Чтобы создать нечто более мощное, чем простой псевдоним, можно использовать плагины kubectl. Плагины подобны автономным сценариям, написанным на любом языке сценариев, но предназначены для расширения функциональных возможностей главной команды при работе в качестве администратора Kubernetes.
Чтобы создать плагин, необходимо использовать правильный синтаксис kubectl- < имя-плагина > для того, чтобы скопировать сценарий в один из экспортированных путей в $PATH и предоставить ему исполняемые разрешения chmod+x.
После создания плагина и перемещения его в свой путь, вы можете немедленно запустить его. Например, у меня на пути есть kubectl-krwl и kubectl-kmux:
$ kubectl plugin list
The following compatible plugins are available:
/usr/local/bin/kubectl-krawl
/usr/local/bin/kubectl-kmux
$ kubectl kmux
Теперь давайте изучим, как выглядит обеспечение работы Kubernetes с tmux.
Использование силы tmux
Tmux - очень мощный инструмент, на который полагаются многие команды для устранения проблем, связанных с упрощением работы - от разделения окон на панели для выполнения параллельной отладки на нескольких машинах до мониторинга журналов. Одним из основных его преимуществ является то, что его можно использовать в командной строке или в сценариях автоматизации.
Я создал плагин kubectl, который использует tmux, чтобы сделать поиск и устранение неисправностей гораздо проще. Я буду использовать аннотации, чтобы пройти через логику за плагином (и оставить его для вас, чтобы пройти через полный код плагина):
#NAMESPACE is namespace to monitor.
#POD is pod name
#Containers is container names
# initialize a counter n to count the number of loop counts, later be used by tmux to split panes.
n=0;
# start a loop on a list of pod and containers
while IFS=' ' read -r POD CONTAINERS
do
# tmux create the new window for each pod
tmux neww $COMMAND -n $POD 2>/dev/null
# start a loop for all containers inside a running pod
for CONTAINER in ${CONTAINERS//,/ }
do
if [ x$POD = x -o x$CONTAINER = x ]; then
# if any of the values is null, exit.
warn "Looks like there is a problem getting pods data."
break
fi
# set the command to execute
COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE”
# check tmux session
if tmux has-session -t <session name> 2>/dev/null;
then
<set session exists>
else
<create session>
fi
# split planes in the current window for each containers
tmux selectp -t $n ;
splitw $COMMAND ;
select-layout tiled ;
# end loop for containers
done
# rename the window to identify by pod name
tmux renamew $POD 2>/dev/null
# increment the counter
((n+=1))
# end loop for pods
done< <(<fetch list of pod and containers from kubernetes cluster>)
# finally select the window and attach session
tmux selectw -t <session name>:1 ;
attach-session -t <session name>;
После запуска скрипта плагина он будет выдавать выходные данные, аналогичные изображению ниже. Каждый модуль имеет собственное окно, и каждый контейнер (если их несколько) разделяется панелями в окне модуля в потоковые журналы по мере их поступления. Преимущество tmux можно увидеть ниже; При правильной конфигурации можно даже увидеть, какое окно активно (см. белые вкладки).
Заключение
Псевдонимы всегда полезны для простого устранения неполадок в средах Kubernetes. Когда среда становится более сложной, плагин kubectl является мощным вариантом для использования более продвинутых сценариев. Ограничения в выборе языка программирования, который можно использовать для записи плагинов kubectl, нет. Единственное требование состоит в том, чтобы соглашение об именовании в пути являлось исполняемым и не имело того же имени, что и существующая команда kubectl.
Прочитать полный код или попробовать плагины можно тут