Анонс подкаста. Выпуск 56. \\\\\Подкаст закончился. Запись традиционно будет 25 числа

Тема 56-го выпуска была рождена на стыке эволюции и ваших запросов.



Два месяца назад, после выпуска про ЦОДы изнутри, от вас пришло множество запросов объяснить, как же выстроить эффективную работу в ЦОДе простым смертным инженерам. И чтобы научить вас обходить все подводные камни, мы нашли трёх специалистов с многолетним опытом работы с самыми разнообразными дата центрами. Каждый из них не то что собаку, а наверное, целую лошадь съел на этом поприще. А втроём они способны лишить атакующей силы всё татаро-монгольское иго.

И вот наши герои:

— Степанов Константин, руководитель регионального развития MSK-IX

— Дубовиков Александр, исполнительный директор хостинга diphost.ru

— Петров Дмитрий, генеральный директор Комфортел

Собираемся 21 числа, 13 часов дня время всё так же московское. Будем слушать увлекательные истории и задавать ваши каверзные вопросы.

LinkMeUp. Выпуск № 55. Квантовые коммуникации

В этот раз Александру пришлось поднапрячься и за сутки собрать приятную на слух дорогу.

Алексей Фёдоров — старший научный сотрудник Российского Квантового Центра и первый физик-теоретик в подкасте linkmeup — рассказывает о квантовой криптографии и коммуникациях.
О том, как, можно сказать, впервые, силы света оказались на шаг впереди сил тьмы.

Скачать файл подкаста






Добавить RSS в подкаст-плеер.

Подкаст доступен в iTunes.

Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.


Сети для самых матёрых. Часть тринадцатая. MPLS Traffic Engineering

Все выпуски СДСМ...


Современные компьютерные сети, предложив дешёвый трафик, высокий профит, суперстабильность и божественную конвергентность, лишились таких притягательных качеств старых технологий, как возможность определять путь трафика и обеспечить качество канала от начала до конца.

Однако сеть linkmeup выросла до размеров федерального оператора. Возможность управления трафиком и быстрого восстановления сервисов стали очень важным требованием в MPLS-сети.
Пора внедрять Traffic Engineering.







Зачем вообще может понадобиться инжиниринг трафика?

Читать дальше →

Анонс подкаста. Выпуск 55 \\\\\24.09.2017

Дилетантские рассуждения о квантовых коммуникациях и запутанности до добра не доводят.
В 55-й выпуск к нам идёт физик-теоретик, научный сотрудник Российского Квантового Центра — Алексей Фёдоров, чтобы вывести linkmeup на новый энергетический уровень.

Онлайн Трансляция






Когда: 24.09.2017 в 15:00 (МСК)
Кто: Алексей Фёдоров, научный сотрудник РКЦ.
Про что: Квантовые коммуникации и шифрование


Фотография с сайта www.interviewrussia.ru/

А туда ли мы идём?

Просто представьте, во что мы себя уже втянули. Какова сложность архитектурной композиции из костылей, которую мы сооружаем?

Сначала мы ушли от технологий с коммутацией каналов к коммутации по ячейкам, чтобы более оптимально использовать полосу пропускания.
Потом оказалось, что строить заранее канал для ячеек тоже неудобно — негибко, ненадёжно.
Мы создали Ethernet, который в самом своём начале задумывался как протокол только для локальных сетей. Никому и в голову не могло прийти, что он может стать канальной технологией уровня города. Мы создали монстра, лишившего нас сна своими широковещательными штормами. При этом связка Ethernet+IP от рождения не предназначена для транспортировки старых протоколов, не может изолировать трафик разных клиентов друг от друга, даже элементарно управлять путём, которым пойдёт трафик мы не можем.
О, мой Лейбниц! А чего стоит рекурсивный поиск наиболее точного маршрута в таблице маршрутизации, отъедавший на заре IP драгоценные секунды процессорного времени? Пришлось выдумать MPLS, чтобы маршрутизаторы смотрели только на метку, что должно было происходить гораздо быстрее. В итоге мы опять вернулись к построению заранее определённых каналов, лишившись однако такой важной вещи, как гарантированное качество сервиса — то ли дойдёт пакет до получателя, то ли нет. Для этого были изобретены монструозные механизмы классификации трафика, токен-бакетов, аппаратных очередей QoS, управления перегрузками. А с появлением TCAM и FIB, быстрых процессоров и дешёвой памяти, чистый MPLS стал шпилем на уродливой башне из подпорок.


К слову, TCAM — самый дорогой и горячий компонент современного оборудования.

И что мы имеем в итоге? Канал без гарантированного качества, который строится как случай на душу положит, а под собой несёт все проблемы Ethernet.
И тут появляется MPLS Traffic Engineering. Который делает что? Правильно: IntServ QoS и возможность строить маршруты так, как этого хочет оператор, а не IGP. При этом вручную задаются узлы по пути, где можно строить туннель, где нельзя, требования по ширине, задержкам, вариациям.

И тут нужно задать себе и окружающим вопрос: а туда ли мы идём?


Классические технологии, такие, как E1 или SDH были прекрасны: у абонента всегда была гарантированная полоса, гарантированное качество канала, который если уж он занял, то никто не отнимет. Прекрасны во всём, кроме:
  • Полоса занята, даже если абоненты томно молчат в трубку, пытаясь придумать тему для разговора.
  • Количество абонентов, которые могут использовать линию строго ограничено, соответственно никакой переподписки и высочайшая цена.
  • Если вдруг кот погрыз радиоволну, то всё ваше телевидение испорчено. Не все технологии прошлого умели в резервирование. А те, что умели (тот же SDH восстанавливался за 50мс) стоили неприлично.

Вызов первых двух проблем приняло следующее поколение технологий — ATM. Была введена концепция ячеек. Стало лучше, стало легче — у клиентов по прежнему было гарантированное качество, но при этом их (клиентов) можно было подключить больше.
А вот с резервированием беда — АТМ по-прежнему был очень инертным и негибким, кроме экзотических реализаций IP over ATM.

А кроме того, появилась и новая идея — LAN — локальные компьютерные сети — все прежние технологии приходили в мир со стороны телефонных компаний и телефонных же стандартизирующих организаций. А там всё просто — инпут=оутпут, битрейт всегда плюс-минус одинаковый — чего хочет абонент, понятно.
LAN же ставил, можно сказать, противоположные задачи. АТМ потерпел сокрушительное поражение в схватке с Ethernet+IP.

Подход с коммутацией пакетов оказался очень гибким.
IP — обеспечил связность любых двух компьютеров в мире. А учитывая, что каждый маршрутизатор самостоятельно принимает решение, как поступить с каждым пакетом, резервирование стало очень простым и переключение в случае поломки происходило практически без перерыва сервиса.
Ethernet прекрасно справлялся с задачами локальной сети с минимальной настройкой — дошло до смешного — воткнул кабель в свитч — и всё работает. АТМ вместе с ISDN грустно утирают слезу.
Купить же себе бухту витухи, пару коммутаторов и собрать простую локалку мог позволить себе любой студент.

Да, пришлось пожертвовать гарантированным качеством сервиса. Однако Ethernet+IP, реализующий плавающий битрейт и открывающий широкие возможности для переподписки, оказался очень дешёвым по сравнению не только с ATM/E1, но и с SDH/SONET, поэтому вытеснил все другие технологии из локальных сетей, а сейчас вовсю и из магистральных вытесняет (прощай, SDH!).
А вопрос качества сервиса был адресован новаторскому механизму — PHB — DiffServ QoS, когда каждый маршрутизатор должен самостоятельно управлять трафиком. Концепция приоритезаци пакетов блестяще проявила себя, позволяя важному трафику выдать максимум ресурсов. В результате, по сравнению с моделью качества сервиса в старых технологиях Ethernet+IP оказался более или менее на уровне.

Но новые стандарты не заменяли старые — они использовались на новых сетях, а АТМы и SDH жили на старых. И долгое время они едва пересекались. У нас были отдельно сети для телефонии, отдельно для ШПД, отдельно для телевидения.

Единственная серьёзная проблема IP была в Control Plane'е — очень уж ресурсоёмкой процедурой был поиск нужной строчки в таблице маршрутизации. И этот вопрос был адресован молодой технологии MPLS, разработчики которой решили взять лучшее от ATM, избавиться к чертям от его канальной функции и внедрить её в связку Ethernet+IP, аккурат между ними. Да, странная вставка L2,5 между L2 и L3 выглядит неорганично, но кому какое дело до этой модели OSI (спросите об этом Иннокентия в чате linkmeup)?
Первоначально MPLS был призван упростить процедуру коммутации пакетов. То есть connectionless IP сначала находит все маршруты в сети, а поверх них натягиваются MPLS-туннели, которые с одной стороны являются каналами между двумя точками, но с другой автоматические и опираются на IP. В итоге MPLS-пакет приходил на MPLS-маршрутизатор, тот проверял его метку, менял её и отправлял дальше. В его таблицах было чёткое соответствие — пакет с такой меткой нужно отправить в такой-то интерфейс, а с меткой сделать то-то и то-то. Никаких многократных переглядывалок с таблицей маршрутизации.
Но в этом плане MPLS прискорбно опоздал — микроэлектроника тоже не топталась на месте и подставила ему подножку — появились TCAM, которые за фиксированное время возвращали нужный маршрут, появилась концепция FIB — когда все необходимые параметры для действий с IP-пакетами были в близком доступе — в том самом TCAM, выросли процессорные мощности, а гигабайты оперативки можно было купить вместе с луком на рынке.
И вот тут хотелось сесть и заплакать — всё зря. Мы создали 11-й стандарт вместо того, чтобы свести 10 предыдущих к одному.
И вдруг какая-то светлая голова обнаружила, что MPLS-инкапусляция скрывает для транзитных маршрутизаторов внутренности пакета. То есть происходит туннелирование, как, например, в GRE. А почему бы нам внутрь MPLS-пакета закинуть не IP, а какой-нибудь E1?
Ну в самом деле, технологиям PDHoverEthernet или PDHoverIP сто лет в обед — просто это было неудобно. А тут уже есть есть автоматически созданные туннели — нужно только направить в них E1.
Как словом, так и делом, AToM через сеть MPLS может передать любые существующие протоколы канального уровня. Это MPLS L2VPN.
Можно подключить пару клиентов по Ethernet и, изолировав их друг от друга MPLS-метками, обеспечить им виртуальную локальную сеть — это MPLS VPLS, MPLS VPWS, EVPN и другие.
А ещё можно всё тот же IP прятать, но разными MPLS-метками обозначать разных клиентов и предоставлять им IP-связность. Это MPLS L3VPN.

И это немного больше, чем просто дополнительные сервисы — это огромный скачок в направлении конвергентных сетей. Теперь MPLS-сеть провайдера может использоваться для предоставления услуг ШПД, телефонии, телевещания, L3VPN и L2VPN одновременно.
Это уже серьёзный удар по классическим телефонным компаниям, которым пришлось скинуть путы старых стандартов и свои сети тоже переводить на Ethernet+MPLS+IP. Не удалось им почивать на лаврах фиксированной телефонии вечно.

Следующее поколение конвергентных сетей — FMC — Fixed-Mobile Convergence. Одна и та же сеть теперь может использоваться для всего перечисленного выше плюс являться транспортной сетью для мобильной сети.
В самом деле — базовые станции LTE подключаются только по Ethernet, 3G — частично по Ethernet, частично по ATM, 2G могут быть Ethernet или E1. И для всего этого есть MPLS.
И концепция DiffServ вместе с приоритезацией пакетов в целом неплохо справляется с таким потоком данных. Например, служебные протоколы MPLS-сети имеют приоритет 6-7, данные 2G и IP-телефонии могут идти с приоритетом 5, 3G — 4, LTE — 3, real-time video — 3, сёрфинг — 2, FTP, почта — 1 а торренты — 0.
Вместо инсталляции из палок, скреплённых жвачкой, перед нами прекрасная пирамида, которая медленно эволюционировала долгие годы.

И вот он — Traffic Engineering — самое неоднозначное применение MPLS.

Сети для самых матёрых. Микровыпуск №8. EVPN Multihoming

В рамках серии СДСМ публикуем вторую статью Марата Бабаяна о EVPN.
==================================================================



В статье, посвященной EVPN я затронул тему multihoming-га. Многих эта тема заинтересовала и поэтому в продолжении предыдущей статьи сегодня мы рассмотрим что же такое EVPN multihoming и как он работает.

EVPN multihoming работает в двух режимах: Single-Active и Active-Active. Мы сегодня в основном остановимся на более сложном и интересном варианте: Active-Active, так как Single-Active по сути очень упрощенная версия Active-Active.

Данная статья рассчитана на тех, кто уже имеет общие знания о EVPN: основные принципы работы, отличия от VPLS и т д. В противном случае понять содержание статьи будет сложно.
Читать дальше →

В поисках утерянного гигабита или немного про окна в TCP

Поводом для написания этой статьи послужила лень, которая, как известно, двигатель прогресса и свидетель появления на свет невероятно облегчающих жизнь вещей.


В моём случае это была лень объяснять в тысячный раз клиенту, почему он арендовал канал точка-точка и в договоре чёрным по белому написано Ethernet 1Гбит/с, а он как ни измеряет, но чуть-чуть да меньше получается.


Где остальное? Почему недобор? Куда девался интернет из провода? А может его и вовсе страшно обманули?


Ну что ж, давайте искать, а заодно напишем заметку, которую будет не стыдно показать тысяче первому клиенту, у которого будет недосдача скорости.


Важно!

Если вы сетевой инженер, то не читайте эту статью. Она оскорбит все ваши чувства т.к. написана максимально простым и доступным языком с множеством упущений.




Читать дальше →

LinkMeUp. Выпуск № 54. ЦОДы

Последний раз мы дали маху со временем подкаста. Оказалось, что в 9 утра тяжело было даже гостям, которые знали и готовились.
Что уж говорить о слушателях, которых было в среднем 15 человек, против обычных 50.
Линкмиап пришлось в эфире пообещать так больше не делать.

Итак, как разогрев перед CC2017, послушайте linkmeup#54 про ЦОДы с генеральными директором ДЦ «Бонч-Айти» Борисом Мейером и главным инженером «Миран» Виталием Николаевым.

План был следующий:
— Атрибут любой философии — терминология. Определяем ЦОД.
— Где лучшие ЦОДы? У нас в клубе. Почему территориально они сосредоточены преимущественно в европейской части.
— ЦОД и клиенты. SLA. ТУ на размещение.
— ЦОД, операторы и датаиксы. Почему в одних много, в других мало, а у третьих интерконнект на весь континент.
— ЦОД и люди. Как попасть, кто приходит, куда развиваться и где потолок развития. Главный инженер царь и бог.
— ЦОД как место внедрения новейших технологий.

Скачать файл подкаста




Добавить RSS в подкаст-плеер.

Подкаст доступен в iTunes.

Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.


Анонс подкаста. Выпуск 54. ЦОДы \\\Подкаст закончился. Запись 25.08

Подзадержались мы в этом месяце с анонсом свежего выпуска, но всё же лето. Не судите строго.
На часах без пятнадцати осень, поэтому ловим последние летние деньки и собираемся в эту субботу, в 9 утра и обсуждать мы будем датацентры.
Да-да, мы прекрасно понимаем, что всем уже надоели рассказы про охлаждение, электричество, резервирование каналов и тысячи стоек, поэтому мы будем говорить про датацентры как объекты глобальной инженерной инфраструктуры: путь инженера как винтика в бездушной машине, где датацентрам жить хорошо, цод и клиенты, цод и операторы связи, цод как место внедрения передовых технологий и т.д.
Тем много, успеем всё или нет пока не ясно, а помогать нам будут директора самого настоящего ЦОДа, главный инженер не менее настоящего ЦОДа и директор оператора связи.
А вообще хотим сделать выпуск, опирающийся на ваши вопросы, так что обязательно приходите. Все высказывания в стиле – а почему вот про это не говорили, не принимаются.



Когда: 19.08.2017 в 09:00 (МСК)
Кто:
  • Дмитрий Петров
  • Виталий Николаев
  • Борис Мейер
Про что: ЦОДы

Поccieлки №6. Владислав Данилюк (56830)

С лёгкой руки Александра названный «256-й TTL» бар принимает своего 6-го эксперта — Владислав Данилюк.

Скачать файл подкаста




Добавить RSS в подкаст-плеер.

Подкаст доступен в iTunes.

Скачать все выпуски подкаста вы можете с помощью BT Sync (код: BYENRHD5UNKD5ZDIYFSB63WG2PEY2GIUN) или с яндекс-диска.