telecom № 58. SDN. Cisco ACI
25 декабря 2017, 11:43
0
14438
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
14438
5
Ещё выпуски
У большинства вендоров что-то интеллектуальное начинается с канального уровня. А вот Ариста предлагает L1-коммутацию — этакая умная патч-панель. В гостях: Андрей Нуштаев. Системный ...
25 сентября 2019
Chaos Constructions не помеха опубликовать 66-й выпуск подкаста linkmeup. Ребята из Кода Безопасности: Павел Коростелев (Руководитель отдела продвижения продуктов) и Сергей Кормушин (Менеджер ...
25 августа 2018
Для кого-то это фантастика, а для кого-то самая что ни на есть реальность - 400Гб/с с порта. На 50гигабитных SerDes'ах. Андрей Нуштаев из ...
11 октября 2021
Итак, этот выпуск случился, несмотря на все незвгоды! В 111-м выпуске говорим про телевидение в широком смысле этого слова со smotreshka.tv и Яндексом. ...
25 мая 2022
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… Но такой траблшут должен выполняться только с полным пониманием того, что делается и с пониманием того за что отвечает каждый внутренний процесс. Т.е. это не пререгатива кастомера…