�ݺ�ߣ

Editor's Notes

• #2: Что такое виртуализация? Никто не знает Ролик про маму (самый популярный ответ э-э-э-э и меджик ) - Не будем спорить о том кто лучше или хуже - Покажем разные реализации идеи заложенной в фундамент виртуализации сети - Сегодня рассмотрим проприетарное решение vmware (nicira пионеры 2012 ) и подойдём к детальному рассмотрению открытых решений - Очень похоже, что за этим будущее т.к. все игроки ведут свои разработки на уровне как минимум совместимости своего железа
• #3: ПУСТАЯ ЧАША – чем меньше мешает опыт и образование, тем тебе же лучше Ложки нет – КИСС!
• #4: Стрейт форвард
• #6: Максимальная утилизация ресурсов. Покупая карьерный самосвал мы не будем возить на нём два листика бумаги, для этого можно нанять школьника-курьера Простое управление (эпл вей). Проще управление – меньше специалистов. Можно не комментировать =)
• #7: Теряется куча денег на железе и кластеризации. + Избыточность на защиту. Скачущая нагрузка. Black Friday. Автотесты В случае с сетью это оптимизация затрат на оборудование т.к. в цене железа есть цена внутренней программы упить одно дорогое или два дешёвых?
• #8: Самое затратное это электричество. Самая большая статья расходов при строительстве и эксплуатации. Светодиоды и двухстрочные экраны. Это надо охладить. И оно кушает электричество. И нужны тысячи сотрудников А железо где-то в конце Больше утилизация ресурсов – меньше площадь цода, меньше всё остальное, больше прибыль при тойже площади
• #9: Набросим на вентилятор Появился новый игрок - Huawei. Citrix оказался в нишевых игроках. Он там и должен быть, как и Oracle, и все остальные. Кстати, про Oracle. Они как раз и двинулись в нишу. Red Hat. Заметил их агрессивность на рынке. Видимо поэтому он и устремляется в "провидцы" на графе. Почему затормозил Microsoft? Опять же маркетинг. К выходу Hyper-V 2012, благодаря агрессивности маркетинга MSFT было выдано заранее много всего, так что выход 2012 R2 ничего не поменял.
• #10: Разростание сетей, спасение во vlan. Это всё да, но не до конца. Смена вектора работы сетей с вертикальной на горизонтальную. Объёмы трафика. Было: толстый канал – большой сервер – множество запросов внутри себя (дерево – доступ – аггрегация - ядро) Стало: тонкий канал – большой фронтэнд – запросы во внутренней сети (клиент-серверная модель сети) Мораль: внутренняя сеть стала важнее внешней Почему старая модель не подходит к новым реалиям: сеть не гибкая (топологии, адресация, кос и т.п.) Сеть слишком статичная. Долг пересчитывать Современные инструменты управления ориентированы на одно устройство. В трафике слишком много относительно мусорной информации (от 20%) Это инкапсуляции, заголовки протоколов и прочая Слишком сложно этим управлять и подстраиваться под ситуацию Где – цоды и облака Миграция виртуальных машин (запуск, вытеснение…) Итог: сеть будет заниматсья только внутренними делами Вопрос к удивлённой публике – представьте, что всю вашу инфраструктуру выдернули из розеток, хаотично перемешали и включили обратно. Сколько времени займёт переснатройка? Правильный ответ – несколько миллисекунд.
• #11: - Важный момент: это просто одна из идей, коих может быть тыща мильёнов! Вас никто не ограничивает. Надо уходить от набора сущностей к единой системе. Простота управления функции управления трафиком и функции его передачи должны существовать отдельно друг от друга, на разных логических уровнях и/или разных ��устройствах. - И где-то над всем этим парят приложения способные общаться в менеджмент плейн через апи. Но это не обязательно. Идеальный случай – описание всей сети помещается в одном устройстве. На этом его функционал закончен. Передачей занимается рой глупых л2 свичей. Всё работает через коммутационную таблицу (Flow table). Протокол OpenFlow. Пришёл пакет, сверились, сбегали на контроллер, переслали, Есть приоритизация, контроллер забирает статистику. Итого – связь идёт не на уровне пакетов, а на уровне потоков Минимум действий над пакетами, направленный в основном на accept/reject и накопление статистики Опасносте: Но простое железо может подорвать основной бизнес крупнейших игроков рынка, но они вынуждены т.к. не хотят терять клиентов идущих за модными технологиями Хотя у них нет альтернативы =) 
• #12: Сие конструкция не умозрительная, а вполне себе реальная из ЦОД крок, open vswitch, open flow, все дела Зачем? Более миллиона сетей поверх обычного физического оборудования. Облака, белогривые лошадки 
• #13: - Не надо рубить с плеча. Нужна эволюция, а не революция - ��Централизация и децентрализация – процесс колебательный. Мы покупаем��BRAS��и ставим его в середине. Понимаем, что у нас ничего не масштабируется, растащим его по краям.�� Насколько сильно должен быть централизован контроллер? Реагировать на все события в сети (проблема очень больших географически разнесённых сетей) Такая конструкция очень опасна в плане масштабирования. Придется снова брать большой контроллер, делить его на несколько, распределять, чтобы он справлялся с нагрузкой. Единый стандарт а не rfc поверх rfc Нужен выбор степени централизации управления и вообще выдуманная гибкость не должна ограничивать действительную гибкость
• #14: - Виртуальный SDN Самый хардкор: не трогая существующую физическую сеть, всё уходит на виртуализованный уровень vSwitch = Virtual Ethernet Bridge (VEB) Переберём важные основы сетевого взаимодействия в ESXi, которые очень здорово перекликаются с описанными выше идеями SDN: - Виртуальные свичи (vSwitch в терминологии VMware) это L2 устройство без IP маршрутизации - Все порты принципиально разделены на аплинки и внутренние. Pазница хорошо иллюстрированна обработкой мультикаста: Когда ВМ отправляет запрос на добавление в мультикаст группу, всвич напрямую пересылает пакет на физический свич, который обрабатывает запрос, в всвич дабвляет мультикаст мак вм в свою таблицу переадресации.Таким образом, мультикаст трафик идёт только запросившим его машинам. - Всвичи, как устройства, не взаимодействуют между собой. Никак и никогда. Это значит, что если этому свичу не назначен внешний nic, трафик никогда не покинет гипервизор. (Возражение о VDS не принимается т.к. это другой уровень) - Принципиально невозможно создание петель т.к. vSwitch не участвует в spanning tree (stp bpdu пакеты банально отбрасываются). - Всегда проверяется адрес источника пакета во входящем трафике (обработака мультикаста и широковещательных пакетов) Это решает проблему петли через физический свич. Очень удобно, не правда ли? - На можно организовать поргруппы, которые объединяют набор внутренних линков в логическую группу удобную для управления. Это напоминает идею ��vlan, но не надо их путать т.к. они не производят изоляции - vSwitch не изучает мас адреса проходящего трафика. Они просто их знает из конфигов подключённых машин или от гипервизора - Трафик с одного физического аплинка никогда не будет передан на другой аплинк средствами всвича. Это ещё один уровень защиты сети в целом, и от образования петель в частности. - Так же не учавствует в IGMP Snooping (не тот уровень OSI) и передаёт мультикаст трафик только на vNic готовые его получать - Не использует пользовательские данные в сетевых кадрах. Хранит копию данных нужных для пересылки и фильтрации, а обрабатывает их простым сравнением. - Никаких native vlan тэгов - Нет динамической агрегации каналов
• #15: В ГУЕ этих настроек даже нет т.е. они считаются избыточными External switch tagging – Пакеты режутся физическим свичом и к нам приходят без заголовков - Увеличение количества машин никак не влияет на количество используемых физических портов. 
• #16: - Virtual switch tagging. Заголовки обрабатываются виртуальным свичом, отдавая машине чистый пакет Вводится понятие портгруппы ��traffic shaping and bandwidth limitations, NIC failover Весь трафик идёт по одному транку
• #17: На обоих свичах есть одна машина – не нужен внешний роутер Портгруппы не изолируют трафик. Если нужна изоляция – надо добавить vlan - Virtual guest tagging. Тэгированные пакеты пересылаются внутрь машин без изменений. Для этого порт группе достаточно назначить vlan id 4095
• #19: Но надо ли больше?
• #20: - По сути это обыкновенная виртуальная машина, заточенная под обработку сетевого взаимодействия. Состоит из, так называемого, апплаенса, разворачиваемого на гипервизоре и внешнего модуля управления, к которому может быть подключено множество апплаенсов. По сути является 100% воплощением идей SDN. 
• #21: - Идея состоит в слепом перенаправлении трафика из гипервизора (вне зависимости от таргета) с обработкой на внешнем сетевом устройстве и отправкой обратного пакета с MAC’ом таргетной виртуальной машины. 
• #22: - Идея заключена в обратную сторону: с помощью SRIOV внутрь виртуальной машины пробрасывается нормальная сетевая карта, которой соответствует реальный физический порт.