пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В качестве меры избыточности можно развернуть вместе несколько устройств ASA от Cisco в отказоустойчивой конфигурации, именуемой как реализация высокой доступности (High Availability). Для реализации данной схемы требуются абсолютно идентичные ASA, то есть чтобы устройства имели идентичное программное обеспечение, лицензирование, память и интерфейсы. Существует три возможных варианта реализации схемы High Availability для защиты от простоев.
Реализация отказоустойчивости Active/Standby: в этой модели только один из брандмауэров отвечает за обработку трафика, в то время как другой становиться "горячим" резервным устройством. Резервное устройство начинает обработку трафика в случае сбоя активного устройства.
Реализация отказоустойчивости Active/Active: в этой модели оба брандмауэра активно обрабатывают трафик как кластер. При выходе из строя одного из устройств, сеть будет продолжать нормально функционировать, так как они имеют одинаковые (дублирующие) настройки.
Данная реализация чуть сложнее и требует использования нескольких контекстных режимов. В режиме множественного контекста можно разделить одно устройство ASA на несколько виртуальных, известных как контексты безопасности. Каждый контекст безопасности действует как независимое устройство со своими собственными политиками, интерфейсами и администраторами. Поэтому несколько контекстов представляются как отдельные автономные устройства.
Для реализации отказоустойчивости Active/Active используются два физических брандмауэра. На каждом из этих брандмауэров настраивается несколько виртуальных брандмауэров или контекстов безопасности. В примере выше в ASA 1 настраиваются контекст безопасности 1 и контекст безопасности 2. Аналогично настраивается и ASA 2:
Следующий шаг состоит в том, чтобы взять виртуальные контексты безопасности и разделить их на отказоустойчивые группы. Отказоустойчивая группа- это просто логическая группа одного или нескольких контекстов безопасности.
Аса-1 определена в качестве основного устройства, активной для отказоустойчивой группы 1. Аналогично, ASA 2 определена как вторичное устройство, активное для отказоустойчивой группы 2. Контексты безопасности разделяются и назначаются следующим образом:
ASA 1:
Контекст безопасности 1 Назначена отказоустойчивая группа 1
Контекст безопасности 2 Назначена отказоустойчивая группа 2
ASA 2:
Контекст безопасности 1 Назначена отказоустойчивая группа 2
Контекст безопасности 2 Назначена отказоустойчивая группа 1
Нагрузка распределяется таким образом, что обе ASA активны. Таким образом достигается избыточность.
Реализация отказоустойчивого кластера: это объединение нескольких ASA в кластеры, действующих как единое логическое устройство. Интеграция и управление по-прежнему работают так, как если бы это было единое устройство, но кластеризация обеспечивает более высокую пропускную способность и избыточность. Это работает в модели slave/master аналогично тому, как работает массив RAID- дисков. Если одно устройство ASA, входящее в кластер, выходит из строя, другое берет на себя операции до тех пор, пока не будет заменен отказавший брандмауэр.
Интерфейсы соединяются с двумя различными коммутаторами, причем виртуальный канал порта соединяет коммутаторы вместе. Это должно быть сделано как на внутренней, так и на внешней зонах безопасности.
Давайте рассмотрим настройку функции Intercom в Cisco CME. Если вам интересна настройка этой функции в CUCM, то про это можно прочитать тут.
Интерком является распространенной функцией в телефонных сетях, и позволяет абонентам устанавливать одностороннюю связь посредством громкой связи, например между директором и секретарем. Технически интерком работает при помощи быстрого набора и функции автоответа. На телефоне директора, с которого будет транслироваться сообщение нажать на клавишу интеркома, телефон секретаря автоматически принимает звонок с выключенным микрофоном. Чтобы установить двустороннюю связь нужно нажать на принимающем телефоне кнопку Mute
Чтобы настроить интерком необходимо создать два новых ephone-dn номера, по одному для каждой стороны соединения. Этим интерком линиям нужно присвоить номер, как и любой другой ephone-dn. Для предотвращения случайного доступа других абонентов к линии интеркома и вызова случайного номера с замьюченым микрофоном, нужно создать номер интеркома таким, чтобы его нельзя было набрать с других IP-телефонов.
Процесс с примером
Рассмотрим на примере как это сделать:
CME(config)# ephone-dn 500
CME(config-ephone-dn)# number A100
CME(config-ephone-dn)# intercom A101 label “Manager”
CME(config-ephone-dn)# exit
CME(config)# ephone-dn 501
CME(config-ephone-dn)# number A101
CME(config-ephone-dn)# intercom A100 label “Manager”
CME(config-ephone-dn)# exit
CME(config)# ephone 1
CME(config-ephone)# button 2:500
CME(config-ephone)#restart
CME(config-ephone)#exit
CME(config)# ephone 2
CME(config-ephone)# button 2:501
CME(config-ephone)#restart
CME(config-ephone)#exit
Здесь обратим внимание на то, что ephone-dn 500 присваивается номер А100. Этот номер нельзя набрать с клавиатуры IP-телефона Cisco, но его можно присвоить на кнопку быстрого набора. Команда intercom [номер][аргумент] действует как кнопка быстрого набора на ephone-dn. В нашем примере на ephone-dn 500 команда intercom A101 набирает номер А101, который присвоен ephone-dn 501. Поскольку на ephone-dn 501 также была введена команда intercom, он автоматически отвечает на вызов с выключенным микрофоном. Аргумент label позволяет дать имя для линии интеркома, которая будет отображаться на телефоне. Помимо этого можно использовать еще три аргумента, при помощи которых можно настроить функционал:
Barge-in – автоматически ставит текущий звонок на удержание и отвечает на intercom вызов;
No-auto-answer – заставляет телефон звонить, вместо автоматического ответа;
No-mute – делает intercom вызов с включенным микрофоном.
Также настройку можно выполнить, используя Cisco Configuration Professional (CCP) . Для этого нужно перейти в меню Unified Communications → Telephony Features → Intercom и нажать кнопку Create.
Здесь для двух телефонов нужно выбрать пользователя, на какую кнопку будет назначен интерком и указать дополнительные настройки. После чего нужно нажать OK и Deliver. В окне предпросмотра будет видно, что чтобы исключить возможность случайного набора будет использован алфавитно-цифровой номер.
Отслеживание версий программного обеспечения – довольно сложная задача, и Git помогает с ней справиться. С помощью теговой системы Git вы можете создавать версионированные номера версий, которые бы указывали на определенные коммиты, и использовать их в автоматизации CI/CD для публикации версий.
Тегированные версии в Git
Теги Git очень напоминают ветки Git. Это отметки, которые указывают на определенные коммиты, и их можно использовать для извлечения репозитория в определенный момент времени. Однако их нельзя обновить или изменить (в отличие от ветвей), и они всегда указывают на конкретную версию.
Как правило, теги используются для присвоения определенным выпускам номеров версий, и в большинстве случаев для этого используется формат семантического версионирования (Major.Minor.Patch). Такой подход довольно полезен с точки зрения отслеживания версий, особенно если при развертывании возникают проблемы и необходимо вернуться к последнему одобренному тегу.
Кроме того, теги используются для передачи сигнала конвейерам CI/CD о том, что необходимо опубликовать версию. Некоторые репозиторию могут быть настроены на публикацию «последнего» выпуска для каждого отдельного коммита, особенно после тестирования ветвей разработки. Также теги часто используют для того, чтобы CI-конвейеры выпуска запускались и развертывались только по специальному запросу.
Когда вы отправляете изменения в удаленный репозиторий, например, GitHub, ваши теги будут отображаться во вкладке «Releases» (Версии). Таким образом, другие люди могут клонировать и загружать репозитории по этому тегу.
Выгрузить определенные теги можно с помощью команды
git checkout
что аналогично извлечению ветки.
git checkout v1.0.0
Создание тегов
Для того, чтобы создать простой тег, много сил вам не потребуется. Вам нужно просто извлечь коммит или ветку, которой вы хотите присвоить тег, и запустить команду
git tag
с названием тега.
git checkout master
git tag v1.0.0
В любом случае есть общепринятая практика, которая подразумевает использование комментированных тегов, то есть тегов, которые позволяют задавать описание и могут хранить дополнительную информацию о том, кто их создал и когда (по аналогии с коммитами).
git tag -a v1.0.0 -m "New Release Version - Summary"
Кроме того, вы можете присваивать теги коммитам, которые были созданы ранее, при этом не извлекая их:
git tag -a v1.2 commit_id
Теги нельзя отправлять в удаленные репозитории, такие как GitHub, с помощью стандартной команды Git
push
. Эту команду необходимо запускать с флагом
--tags
или отправлять имя тега вручную.
git push origin --tags
Удаление и редактирование тегов
Теги можно удалять, но важно помнить, что, если вы удалите теги с удаленных серверов, то можете подпортить работу других людей, которые работают с вашим репозиторием. Однако, так как вы на самом деле не редактируете историю Git, то это больше похоже на удаление старой ветки, которая не затрагивает ни один из текущих коммитов.
Вы можете удалить тег по имени с помощью флага
-d
:
git tag -d v1.0.0
Вы даже можете удалить их из удаленного репозитория с помощью следующей команды:
git push origin --delete v1.0.0
А для того, чтобы отредактировать тег, вам понадобиться флаг
-f
, который заставит Git переписать существующий тег:
git tag -f v1.0.0
Создание версий на GitHub
GitHub также поддерживает теги, но расширяет их возможности за счет собственной системы версий (Releases). Версии можно создать из тегов, любого конкретного коммита или с помощью указателя HEAD на любую текущую ветку.
Основная цель публикации версий – предоставить людям для загрузки заранее собранные двоичные файлы. Такая функция довольно полезна на GitHub, но теги ее предоставить не могут. В случае тегов пользователям все равно придется клонировать определенный тег и производить сборку из исходного кода.
Еще одна цель – документирование примечаний к версиям. Система версий GitHub также поддерживает Markdown. Таким образом, пользователи могут легко просматривать версии и наблюдать за их большими изменениями с течением времени.
Создать версию довольно легко. Нажмите «Releases» на боковой панели вашего репозитория и создайте новую версию:
На этом экране вы можете ввести примечания к версии с помощью Markdown и перетащить двоичные файлы, необходимые для этой версии. GitHub автоматически предоставит вам ссылку на исходный код по этому тегу.
Кроме того, вы можете создавать версии автоматически с помощью GitHub Actions. Это избавит вас от постоянной загрузки двоичных файлов. Таким образом, вы сможете автоматизировать ваш репозиторий.