telecom № 58. SDN. Cisco ACI
25 декабря 2017, 11:43
0
14510
5
Продолжаем тему Software Defined Networking. По словам нашего гостя SDN — это наше настоящее. Сетевым инженерам надо меняться, хотя, безусловно есть шанс дотянуть до пенсии с тем, что есть.
Про решение Application Centric Infrastructure, решающие как задачи настройки underlay сети, так и создания overlay в автоматическом режиме, рассказывает Алексей Гусев — сетевой инженер компании, название которой слишком известно, чтобы его называть.
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Группа в linkedin
Скачать все выпуски подкаста вы можете с яндекс-диска.
Добавить RSS в подкаст-плеер.
Пообщаться в общих чатах в тг:
t.me/linkmeup_chat t.me/linkmeup_sysadm_chat
Поддержите нас:
0
14510
5
Ещё выпуски
Вот уж тема так тема! Сегодня мы поговорим о том, как устроен мир доменных имён изнутри — от базовых понятий вроде gTLD и ...
25 апреля 2026
Такие выпуски заставляют нас/вас/всех расти над собой. Когда ты думаешь, что ничего интересного не осталось, появляются люди готовые растоптать твою дерзкую самоуверенность. На ...
25 июля 2020
Два часа отборных ответов на отборные вопросы. Мы заканчиваем цикл подкастов про фаерволы. Нам кажется, получилось достаточно хорошо, чтобы уже никогда не возвращаться ...
25 февраля 2021
Она хотела сделать что-то важное в своей жизни, хотела оставить свой след, но в ней видели только красивую куклу. Она была одной из ...
26 декабря 2025
5 коментариев
timeline 39:30
К вопросу о raund trip delay это 5 ms между конечными серверами!
При этом если взять на задержку внутри инфраструктуры каждого POD по 0,5 ms то требовать в SLA от провайдера нужно уже максимум 4 ms задержки.
access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/installation_guide/index#idm139781234547664
Спасибо за подкаст и полезную тему!
К слову о репликации, вопрос был мой.
— позволю тут частично не согласиться с аналогией и проблематикой. Можно игнорировать наличие БД и репликации между нодами ровно до момента, пока она не начнёт сбоить. А по опыту общения с CUCM 7.x-11.x и продуктами Cisco в целом это неизбежно случается. И тогда начинаются приключения.
Первый привет от Cisco TAC, когда есть подозрение на плавающие проблемы в CUCM-кластере:
utils dbreplication status
utils dbreplication runtimestate
И в том же CUCM топология репликации влияет на возможность управления кластером и частично на его функционирование: при выключенном Publisher’е невозможно вносить изменения в конфигурацию, хоть и некоторые user-facing функции продолжат работать.
Поэтому там, где есть кластер, лучше иметь понимание, с какими симптомами и последствиями он может (рано или поздно будет) разваливаться.
Все ИМХО, конечно.
Ensure the latency of the multi-site cluster is no more than 5ms.
Как небольшое дополнение. При наличии желания синхронизацию между переложить на OOB. Но с точки зрения дизайна такой подход рекомендуется только для recovery процедур.
Привет!
По поводу репликации БД. По сути, все процессы шарятся между всеми APIC в кластере. Данные, которые обрабатывают внутренние процессы, делятся на 32 части. И эти части раскидываются между серверами в +- равном распределении.
Начиная с версии 2.2 появилась возможность добавлять Standby ноды в кластер.
Есть такое понятие как Replica Vector. По сути это распределение процессов между нодами. Проверяя ее «статус» можно отслеживать не фейлятся ли какие-либо процессы. За это отвечает команда #acidiag rvread… Но такой траблшут должен выполняться только с полным пониманием того, что делается и с пониманием того за что отвечает каждый внутренний процесс. Т.е. это не пререгатива кастомера…