По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Графический интерфейс Cisco Unified Communications Manager (CUCM) имеет раздел Disaster Recovery System (DRS), который предназначен для проведения резервного копирования (backup) и восстановления системы (restore). Но бывают ситуации, когда GUI недоступен, например, из-за проблем с сетью. В этом случае, провести процедуры бэкапирования и восстановления можно через консоль CLI и сейчас мы расскажем как это сделать. Процедура бэкапа Перед началом процедуры, у вас должен быть настрое SFTP сервер, куда вы будете заливать бэкап с CUCM. Для начала нужно добавить сервер, куда мы будем загружать бэкап. Для этого вводим команду: utils disaster_recovery device add network [number of backups] Где: backup device name - Имя устройства, куда будем заливать бэкап; path - Путь, куда будем заливать бэкап на данном устройстве; ip-address of remote server - IP адрес удалённого устройства; username - Имя пользователя; number of backups - Количество резервных копий После ввода данной команды, вас попросят ввести пароль пользователя, из под которым вы хотите осуществить бэкап (в нашем случае - ccmadmin) admin: utils disaster_recovery device add network merionbckp ./ 10.20.30.123 ccmadmin Please enter password to connect to network server 10.20.30.123:**** drfCliMsg: Backup Device has been saved successfully. Проверим, что устройство для бэкапа успешно добавилось, для этого введём команду: utils disaster_recovery device list В выводе мы должны увидеть устройство, добавленное ранее: admin:utils disaster_recovery device list Device Name Device Type Device Path -------------------------------------------------------------- merionbckp NETWORK ./ Волшебно! Теперь мы можем осуществить бэкап. Для этого пишем в консоли: utils disaster_recovery backup network Где: backup device name - Имя устройства, куда будем заливать бэкап; featurelist - Список функционала, который нужно забэкапить; Для того, чтобы посмотреть какой функционал доступен для бэкапирования наберите команду: utils disaster_recovery show_registration , где servername - имя сервера, на котором осуществляется бэкап. admin:utils disaster_recovery backup network UCM,CDR_CAR,PLM merionbckp drfCliMsg: Backup initiated successfully. Please run 'utils disaster_recovery status backup' command to see the status Всё, бэкап запущен! Чтобы проверить статус, нам предлагают ввести: utils disaster_recovery status backup admin:utils disaster_recovery status backup Status: SUCCESS :Backup Completed... Tar Filename: 2019-02-16-04-21-37.tar Storage Location: NETWORK Operation: backup Percentage Complete: 100 PLM CCM01 ELM-AGENT SUCCESS Sat Feb 16 04:17:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-agent.log PLM CCM01 ELM-SERVER SUCCESS Sat Feb 16 04:17:26 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-server.log CDR_CAR CCM01 CAR SUCCESS Sat Feb 16 04:17:27 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_cdr_car_car.log UCM CCM01 BAT SUCCESS Sat Feb 16 04:19:23 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_bat.log UCM CCM01 CCMPREFS SUCCESS Sat Feb 16 04:19:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmprefs.log UCM CCM01 PLATFORM SUCCESS Sat Feb 16 04:19:30 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_platform.log UCM CCM01 TCT SUCCESS Sat Feb 16 04:19:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tct.log UCM CCM01 SYSLOGAGT SUCCESS Sat Feb 16 04:19:35 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_syslogagt.log UCM CCM01 CDPAGT SUCCESS Sat Feb 16 04:19:36 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_CCM01_ucm_cdpagt.log UCM CCM01 CLM SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_clm.log UCM CCM01 CCMDB SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmdb.log UCM CCM01 TFTP SUCCESS Sat Feb 16 04:21:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tftp.log UCM CCM01 ANN SUCCESS Sat Feb 16 04:21:33 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ann.log UCM CCM01 MOH SUCCESS Sat Feb 16 04:21:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ccm01_ucm_moh.log Всё, бэкап готов! Процедура восстановления Чтобы восстановить конфигурацию CUCM из бэкапа, нужно сначала посмотреть – что доступно для восстановления на удалённом сервере? Проверить это можно командой: admin:utils disaster_recovery show_backupfiles merionbckp 2019-02-16-04-21-37 2018-12-25-21-52-19 Выбираем нужный нам бэкап и вводим следующую команду: admin:utils disaster_recovery restore network 10.20.30.123 2019-02-16-04-21-37 merionbckp drfCliMsg: WARNING! There are nodes in current production cluster but NOT present in the backup. These nodes will be removed if you restore the Publisher. If you want to keep these nodes, you will need to manually re-add them after the restore. Do you want DRS to perform a SHA-1 File Integrity Check of your backup archives y/n ?(n) : y Please enter the comma seperated features you wish to restore. Valid features for server CCM01 are PLM,CDR_CAR,UCM:PLM,CDR_CAR,UCM Do you want to restore database from the subscriber y/n ?(n) : n drfCliMsg: Restore initiated successfully. Please run 'utils disaster_recovery status restore' command to see the status ALERT: Please restart the server(s) before performing the next restore for changes to take effect. In case of a cluster, restart the entire cluster. Теперь проверяем статус восстановления: admin:utils disaster_recovery status restore Status: SUCCESS :Restore Completed... Tar Filename: 2019-02-16-04-21-37.tar Storage Location: NETWORK Operation: restore Percentage Complete: 100 CDR_CAR CCM01 CAR SUCCESS Sun Feb 17 11:20:15 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_cdr_car_car.log PLM CCM01 ELM-AGENT SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-agent.log PLM CCM01 ELM-SERVER SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-server.log UCM CCM01 BAT SUCCESS Sun Feb 17 11:25:06 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_bat.log UCM CCM01 CCMPREFS SUCCESS Sun Feb 17 11:37:06 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_ccmprefs.log UCM CCM01 PLATFORM SUCCESS Sun Feb 17 11:37:13 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_platform.log UCM CCM01 TCT SUCCESS Sun Feb 17 12:11:10 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_tct.log UCM CCM01 SYSLOGAGT SUCCESS Sun Feb 17 12:14:19 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_syslogagt.log UCM CCM01 CDPAGT SUCCESS Sun Feb 17 12:14:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_cdpagt.log UCM CCM01 CLM SUCCESS Sun Feb 17 12:17:03 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_clm.log UCM CCM01 CCMDB SUCCESS Sun Feb 17 12:17:05 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ccmdb.log UCM CCM01 TFTP SUCCESS Sun Feb 17 12:25:12 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_tftp.log UCM CCM01 ANN SUCCESS Sun Feb 17 12:26:38 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ann.log UCM CCM01 MOH SUCCESS Sun Feb 17 12:26:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_moh.log
img
Старый и безусловно привычный администраторам интерфейс FreePBX 12 – ой версии в прошлом – в декабре 2015 выпущена тринадцатая версия графической оболочки для Asterisk. Как идти в ногу со временем и произвести обновление с 12 на 13 версию FreePBX расскажем в статье. Обновление через WEB - интерфейс Для полного удобства в двенадцатой версии FreePBX был создан встроенный пошаговый мастер обновления. Перейдите во вкладку Admin -> 12 to 13 Upgrade Tool Перед вами откроется приветственное меню мастера обновления. Тут же, развернув выделенную на скриншоте ниже красным вкладку, вы сможете ознакомиться с новинками FreePBX 13. Для продолжения установки, нажмите Check the requirements!. Система проверит текущие версии установленных на вашей IP – АТС Asterisk модулей, и, в случае не совместимости укажет какие из них необходимо будет обновить. Имейте ввиду, для корректного обновления необходимо чтобы следующие условия были выполнены: Asterisk 11 версии или выше PHP версии 5.3.3 или выше FreePBX версии 12 Нажмите на кнопку Proceed to the upgrade process. Мастер обновления занимает 3 простых шага: На первом шаге необходимо указать информацию о пользователе FreePBX, выбрав наиболее подходящую опцию в выпадающем поле Distribution На втором шаге, мастер попросит указать ваши контактные данные, такие как: Ваше имя Название компании Номер телефона Адрес электронной почты Третьим шагом будет начато обновление дистрибутива FreePBX 12 до 13 версии. По окончанию работы мастера обновления ваша система будет готова к работе в рамках 13 версии. Обновление через консоль Если по каким-либо причинам вы не можете обновить FreePBX через пошаговый, встроенный в графический интерфейс мастер обновления, вы можете сделать это через командную строку Asterisk, то есть через CLI. Для этого, выполните указанные ниже команды: amportal a ma upgradeall amportal a m update admin set value = '13.0.0alpha1' where variable = 'version'; exit amportal a ma upgrade framework fwconsole --fix_zend fwconsole ma upgrade core fwconsole ma disable backup fwconsole ma download backup fwconsole ma install backup Рассмотрим команды поподробнее. Сразу обозначим, что fwconsole и amportal это командная прослойка между пользователем через командную строку Linux и FreePBX. Итак: ma - это короткая запись команды moduleadmin. Команда отвечает за администрирование модулей FreePBX ma upgradeall - обновление в FreePBX 12 всех имеющихся модулей m - это короткая запись команды mysql. Команда отвечает за управление базой данных через MySQL update admin set value = '13.0.0alpha1' where variable = 'version'; - обновляем версию в базе данных на 13 a ma upgrade framework - обновление фреймворка FreePBX --fix_zend - с помощью программного обеспечения Zend Guard, на момент активации ваш сервер генерирует хэш – сумму, которая хранится на сервере лицензирования. Данный хэш связывается с идентификатором инсталляции, и называется Zend ID. Данная команда урегулирует все возможные конфликты с Zend. ma upgrade core - обновление модуля Core. Обратите внимание, команда уже выполняется с помощью fwconsole ma disable backup - выключаем модуль Backup ma download backup - загружаем модуль Backup ma install backup - устанавливаем модуль Backup Если у вас имеются коммерческие (купленные) модули, то укажите так же команду fwconsole ma upgrade sysadmin Для завершения установки, укажите следующие команды: fwconsole ma upgradeall fwconsole chown fwconsole reload ma upgradeall - обновление всех модулей до актуальных версий fwconsole chown - команда устанавливает необходимые права на все файлы FreePBX fwconsole reload - перезагружаем FreePBX
img
Helm — это инструмент развертывания Kubernetes для автоматизации создания, упаковки, настройки и развертывания приложений и служб в кластерах Kubernetes. Kubernetes — это мощная система управления контейнеризацией для развертывания приложений. Для этого существует несколько независимых ресурсов, и для каждого требуется отдельный YAML-файл манифеста. В этой статье расскажем, что такое Helm и Helm Charts, а также как автоматизировать развертывание приложений в Kubernetes. Что такое Helm? Если бы Kubernetes был операционной системой, то Helm был бы менеджером пакетов. Ubuntu использует apt, CentOS использует yum, а Kubernetes использует helm. Helm развертывает пакетные приложения в Kubernetes и структурирует их в чарты (Helm Charts). Чарты содержат все предустановленные ресурсы приложения вместе со всеми версиями, которые помещены в один легко управляемый пакет. Helm упрощает установку, обновление, вызов зависимостей и настройку развертываний в Kubernetes с помощью простых CLI-команд. Пакеты программного обеспечения находятся в репозиториях или создаются. Почему нам нужен Helm? Объектами Kubernetes сложно управлять. Благодаря полезным инструментам освоение Kubernetes становится плавным и удобным. Helm автоматизирует обслуживание YAML-файлов для объектов Kubernetes, упаковывая информацию в чарты и анонсируя их в кластере Kubernetes. Helm отслеживает историю версий для каждой установки и изменения чарта. Откат к предыдущей версии или обновление до более новой выполняется понятными командами. Доступные команды: Completion — создает сценарий автозаполнения для указанной оболочки. Create — создает новый чарт с заданным именем. Dependency — управление зависимостями чарта. Env — информация о клиентской среде Helm. Get — загрузка расширенной информации об именованном релизе. Help — помощь по любой команде. History — получить историю релизов. Install — установить чарт. Lint — проверить чарт на возможные проблемы. List — список релизов. Package — упаковать каталог чарта в архив чарта. Plugin — установить, внести в список или удалить плагины Helm. Pull — загрузить чарт из репозитория или (опционально) распаковать его в локальный каталог. Repo — установка, внесение в список, удаление, обновление и индексация репозиториев чартов. Rollback — откат релиза к предыдущей версии. Search — поиск в чарте по ключевым словам. Show — показать информацию о чарте. Status — отображение статуса названного релиза. Template — локальное отображение шаблонов. Test — запустить тесты релиза. Uninstall — деинсталлировать релиз. Upgrade — обновить релиз. Verify — проверить, что чарт по указанному пути подписан и действителен. Version — распечатать информацию о версии клиента. Что вы можете сделать с помощью Helm? Helm позволяет разработчикам программного обеспечения развертывать и тестировать среду самым простым способом. Требуется меньше времени, чтобы перейти от разработки к тестированию и продакшену. Помимо повышения производительности, Helm предоставляет разработчикам удобный способ упаковки и отправки приложений конечным пользователям для установки. Как работает Helm? Helm и Kubernetes работают как клиент-серверное приложение. Клиент Helm отправляет ресурсы в кластер Kubernetes. Серверная часть зависит от версии: Helm 2 использует Tiller, тогда как Helm 3 избавился от Tiller и полностью полагается на Kubernetes API. Что такое Helm Charts? Чарты Helm (Helm Charts) — это пакеты Helm, состоящие из файлов и шаблонов YAML, которые преобразуются в файлы манифеста Kubernetes. Чарты могут повторно использоваться кем угодно и в любой среде, что уменьшает сложность и количество дубликатов. Папки имеют следующую структуру: Как работают чарты Helm? Три основные концепции чартов Helm: Чарт — предварительно настроенный шаблон ресурсов Kubernetes. Релиз — чарт, развернутый с помощью Helm в кластере Kubernetes. Репозиторий — общедоступные чарты. Рабочий процесс заключается в поиске чартов через репозитории и создании релизов путем установки чартов в кластеры Kubernetes. Структура чарта Helm Файлы и каталоги чарта Helm имеют определенную функцию: Название Тип Функция charts/ Каталог Каталог для управляемых вручную зависимостей чарта. templates/ Каталог Написанные на языке Go файлы шаблонов, объединенные с конфигурационными значениями из файла values.yaml и предназначенные для генерации манифестов Kubernetes. Chart.yaml Файл Метаданные о чартах, такие как: версия, имя, ключевые слова для поиска и так далее. LICENSE (опционально) Файл Лицензия на чарт в текстовом формате. README.md (опционально) Файл Удобочитаемая информация для пользователей чарта. requirements.yaml (опционально) Файл Список зависимостей чарта. values.yaml Файл Настройки чарта по умолчанию. Создавайте чарты Helm вручную или собирайте общедоступные чарты из репозиториев. Репозитории чартов Helm Репозитории содержат чарты, которые могут быть установлены или предоставлены для доступа другим пользователям. Helm обеспечивает поиск напрямую из клиента. Существует два основных типа поиска: helm search hub — поиск через Artifact Hub из множества репозиториев. helm search repo — поиск через репозитории, добавленные в локальном клиенте Helm с помощью helm repo add. Без каких-либо фильтров в результатах поиска отображаются все доступные чарты. Чтобы уточнить запрос, добавьте условие поиска. Например: helm search hub wordpress Когда найдете подходящий чарт, установите его с помощью helm install. Релизы чартов При установке чарта создается новый пакет. Команда helm install принимает два аргумента: helm install <release name> <chart name> Запуск helm install выводит полезную информацию и указывает, следует ли вам предпринять какие-либо действия для установки. Чарты кастомизируемы и легко настраиваются перед установкой. Релизы Helm легко поддерживать и откатывать в случае любых нежелательных изменений.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59