Оверлайн что это значит
Оверлей
Смотреть что такое «Оверлей» в других словарях:
оверлей — сущ., кол во синонимов: 2 • операция (457) • слой (111) Словарь синонимов ASIS. В.Н. Тришин. 2013 … Словарь синонимов
оверлей — 4.14 оверлей: Одна из основных операций геоинформационных технологий, реализующая наложение в единой системе координат двух или более картографических слоев, представленных в цифровой форме, в результате которой образуется графическая композиция… … Словарь-справочник терминов нормативно-технической документации
оверлей — оверл ей, я … Русский орфографический словарь
Оверлей топологический — Оверлей топологический: наложение двух или более полигональных объектов, в результате которого образуется новый слой, состоящий из фрагментов исходных полигональных объектов и наследующий их координатные, атрибутивные данные и топологические… … Официальная терминология
голографический оверлей — Защитная пленка, содержащая голографический рисунок переливающейся всеми цветами радуги. Используется для обеспечения высокой степени защиты от подделок пластиковых карт. [http://www.lexikon.ru/rekl/a eng.html] Тематики реклама … Справочник технического переводчика
графический оверлей — Графическая композиция, получаемая наложением двух или более слоев. [ГОСТ Р 52438 2005] Тематики географические информационные системы … Справочник технического переводчика
(топологический) оверлей — 57 (топологический) оверлей: Наложение двух или более полигональных объектов, в результате которого образуется новый слой, состоящий из фрагментов исходных полигональных объектов и наследующий их координатные, атрибутивные данные и топологические … Словарь-справочник терминов нормативно-технической документации
графический оверлей — 60 графический оверлей: Графическая композиция, получаемая наложением двух или более слоев. Источник: ГОСТ Р 52438 2005: Географические информационные системы. Термины и определения оригинал документа … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 52438-2005: Географические информационные системы. Термины и определения — Терминология ГОСТ Р 52438 2005: Географические информационные системы. Термины и определения оригинал документа: 57 (топологический) оверлей: Наложение двух или более полигональных объектов, в результате которого образуется новый слой, состоящий… … Словарь-справочник терминов нормативно-технической документации
Что такое Figma Overlays и как его использовать при создании интерфейса
Современные интерфейсы — это не просто статические экраны. Рассказываем, какие эффекты можно создать с помощью Figma Overlays.
Что такое оверлей
Overlay (дословно «перекрытие») — один из вариантов действий, которые можно назначить любому элементу.
Существует 3 варианта анимации для элементов на сайте:
Оверлей подходит для прототипирования бургер-меню, всплывающих модальных окон, системных сообщений, а также для всплывающих подсказок и экранной клавиатуры.
Автор статей по дизайну. В веб-дизайн пришел в 2013 году, осознанно начал заниматься с 2015 года. Параллельно освоил верстку. Время от времени публикует переводы на Хабре.
Как использовать параметр Overlay
Разберем на примере одного проекта, как использовать параметр Overlay и какие преимущества он дает.
Чтобы активировать оверлей, нужно перейти в режим прототипа.
Выберите элемент, по нажатию на который должен срабатывать оверлей. В нашем примере клик по элементу будет вызывать бургер-меню.
Чтобы создать связку бургер-меню с оверлеем, перетащите круглый маркер, который появился при выделении бургер-меню, на фрейм оверлея (я назвал его OverlaysMenu).
Выберите тип триггера — событие, которое будет запускать действие. Я выбрал On Tap — то есть при нажатии.
Плюсы и минусы использования оверлеев
Появившись всего несколько лет назад, модальные окна или оверлеи (overlays) стали элегантным решением проблемы интерактивного дизайна: как сообщить пользователю важную информацию, при этом не заставляя его покидать текущую страницу. Диалоговые окна и всплывающие поп-апы не всегда справлялись с данной задачей, и заменившие их лайтбоксы были признаны главной дизайн-технологией 2008 года.
Оверлей — это бокс с контентом, расположенный поверх основной страницы. Его размер заметно меньше по величине нижележещего окна, которое при появлении оверлея часто затенено, дабы обратить внимание на содержание сообщения. Собственно, сам термин «лайтбокс» (от англ. lightbox — световой короб) был выбран по аналогии с визуальным эффектом одноименных рекламных щитов с внутренней подсветкой.
Рекламный лайтбокс компании Chanel. Источник
Все хорошо в меру
С момента своего появления новая технология полюбилась веб-дизайнерам по всему миру, но, как и любым хорошим изобретением, ей начали злоупотреблять. Информация, помещаемая в изначально небольшой лайтбокс, разрослась до такой степени, что возник вопрос о необходимости использования внутренних ссылок и вертикальной прокрутки в рамках всплывающего окна:
Лайтбокс с описанием ошибки 452 в разделе «Помощь» на сайте apple.com
Элементы навигации, обычно применяемые на веб-странице, все чаще переносились в оверлей, и в результате пользователи начали иметь дело с полноценным окном внутри окна с той только разницей, что его размер был значительно меньше рабочей площади экрана. Не говоря уже о том, что лайтбокс не позволяет делиться полезными сведениями с другими людьми, так как не имеет собственной ссылки.
Кстати, Apple в итоге отказалась от такого способа представления информации: теперь весь нужный контент можно найти на самостоятельных страницах, а для приглашений к участию в опросах был создан feature box — врезка на цветном фоне, погруженная в основной текст.
Текущая версия раздела помощи Apple не содержит оверлеев
В целом удобный инструмент, оверлей все чаще стал использоваться не по назначению. Нередко это происходит из лучших побуждений: маркетологи стремятся предоставить максимально быстрый доступ к важной информации. Однако, иногда лайтбоксы «плодятся» в угоду дизайнерам, которые ради дополнительного контента или опций не хотят создавать отдельную страницу или менять навигацию.
Правила использования оверлеев
Стандартные требования к модальным окнам известны всем:
Тем не менее, даже соблюдение всех технических требований помогает далеко не всегда — в некоторых ситуациях модальные окна не только раздражают пользователей, но и в прямом смысле мешают им получить информацию или выполнить желаемое действие. Во избежание подобных проблем, всегда проводите систематический анализ целесообразности использования и адекватной работы оверлеев.
Прежде, чем решить, нужен ли лайтбокс вашему лендингу или приложению, ответьте для себя на следующие вопросы:
Рассмотрим подробнее каждый из этих пунктов.
Кто ваша целевая аудитория?
Представьте ситуацию, в которой спроектированный для большого экрана оверлей появляется на экране мобильного телефона. В лучшем случае, пользователь просто будет сбит с толку, а в худшем — и вовсе потеряет доступ к контенту.
Дезориентация
Лендинг viafoura.com являет собой пример дезориентирующего воздействия оверлея на мобильных посетителей. При нажатии на кнопку «Получить бесплатную пробную версию» на экран выводится только часть регистрационной формы, и чтобы понять, что произошло, приходится зуммировать страницу.
Слева показано то, что видят пользователи в первый момент, справа — после уменьшения масштаба экрана.
Блокировка доступа к контенту
Другой распространенной и намного более серьезной проблемой является некорректная реализация или баг, который делает невозможными функции скролла и зуммирования для манипуляций с оверлеем. Вероятно, каждый оказывался в ситуации, когда вдруг возникший лайтбокс блокировал весь контент страницы, при этом элементы его управления находились за пределами экрана — у вас просто не остается выбора, кроме как закрыть заблокированный сайт.
Если мобильные пользователи составляют значительную часть вашей целевой аудитории, хорошенько подумайте, прежде чем размещать важную информацию при помощи лайтбокса. В случае, если по-другому не получается, будьте готовы провести первичное и последующие тестирования (QA), чтобы убедиться: ваш дизайн исправно работает при разных разрешениях экрана и при любой ориентации.
Помимо этого, обратите внимание на самих пользователей. Люди с плохим зрением даже на больших мониторах часто используют функцию масштабирования, чтобы приблизить контент. Так как после зуммирования видна только небольшая часть экрана, оверлеи могуг иметь такой же дезориентирующий эффект, как на мобильных устройствах.
Что именно требуется от пользователей?
Для создания хорошего оверлея, в первую очередь, нужно четко обозначить цель: какое действие предлагается совершить пользователям в ответ? Должны ли они ознакомиться с коротким сообщением или прочитать объемный текст? Принять важное решение или просто подтвердить, что информация воспринята? А может, вы хотите, чтобы они поместили в лайтбокс какие-то данные — если да, то какие именно и как много?
Опыт показывает, что быстрый и простой пользовательский опыт очень редко является следствием быстрой и простой работы дизайнера. Напротив, для создания удобного взаимодействия требуется время и ясное понимание условий и итогового результата.
Наиболее частой причиной обращения к оверлеям является желание сообщить посетителям некоторую информацию, предложить заполнить форму или принять решение.
Прочитать текст или просмотреть изображения
Часто единственная цель модального окна — передать пользователям короткое статус-сообщение, и простой оверлей с кнопкой подтверждения или закрытия уведомления подходит для этого как нельзя кстати. Однако текст сверх одного-двух предложений уже создает излишние сложности.
Если слишком длинный контент в маленьком лайтбоксе вынуждает вас использовать прокрутку, позаботьтесь о том, чтобы отключить скроллбар браузера на момент просмотра оверлея: в противном случае, прокручиваться будет не информация, а основная страница. При этом помните, что подобная дезактивация скроллинга может иметь непредвиденные последствия для мобильных пользователей, например, заблокировать доступ к элементам управления лайтбоксом.
Кроме того, если ваш оверлей содержит интересные или полезные сведения, это может вызвать желание добавить его в закладки или поделиться с другими людьми. Создание кнопок — это дополнительная работа, поэтому стоит задуматься: нет ли смысла разместить представленный контент на отдельной странице? Оверлей в таком случае лишь усложняет взаимодействие, используя меньшую площадь экрана.
Заполнить форму
Лайтбокс с полями дает возможность доступа с любого экрана, без необходимости загружать новую страницу. Особенно привлекательно такой вариант смотрится для формы входа или регистрации. Но здесь кроется опасность: малейший баг способен заблокировать доступ к важным функциям, поэтому не забывайте тестировать ваш оверлей на разных браузерах и платформах, или откажитесь от него в пользу испытанного и надежного метода входа с обычной страницы.
Значок «Закрыть» должен быть хорошо заметен. Некоторые дизайнеры полагают, что люди и так догадаются, что для закрытия лайтбокса нужно всего лишь кликнуть по экрану за его пределами. Однако, многие не знают об этом, а другие посетители, особенно использующие тачскрин, и вовсе могут закрыть его случайно.
В представленном ниже примере, оверлей интернет-магазина bluefly.com не уходит с экрана даже при нажатии на серую область страницы, и единственный способ избавиться от него — это кликнуть на черную кнопку «Начать покупки».
Совет: чтобы предотвратить негативный опыт случайного закрытия, продумайте возможность сохранения введенной в поля информации и простой реактивации модального окна.
Принять решение
Оверлеи часто используются для подтверждения действия или мотивации к принятию решения. Проблема заключается в том, что люди настолько привыкли к надоедливым диалоговым окнам и поп-апам рекламного характера, что при появлении сообщения они закрывают его, не задумываясь. В итоге важная и полезная информация остается незамеченной, особенно, когда кнопки содержат стандартные «ОК» и «Отмена»:
Оверлей US Airways спрашивает о согласии на списание средств с кредитной карты
Для предотвращения автоматического закрытия лайтбокса создайте выразительную надпись на кнопке подтверждения, которая будет объяснять пользователям, что именно произойдет, если они ее нажмут:
При удалении контактов в LinkedIn появляется сообщение, содержащее кнопку «Да, удалить их»
Также стоит предусмотреть вариант, в котором пользователь решит не выполнять ни одно из целевых действий. Несмотря на наличие опции «Закрыть» вверху модального окна, многие часто предпочитают задействовать кнопку «Назад» в браузере. Однако в связи с тем, что браузеры не распознают оверлей как самостоятельную страницу, кнопка «Назад» ведет их не к исходной, а предыдущей странице.
Поэтому если вы заметили, что в момент появления лайтбокса на вашем сайте происходит слишком много возвратов назад, рассмотрите возможность сделать данный элемент навигации еще одним способом его закрыть.
Когда появляется оверлей, и не прерывает ли он другой процесс?
Одной из самых больших проблем оверлеев является то, что они отвлекают пользователей от текущего конверсионного процесса.
Верной стратегией в данном случае может стать их появление в момент, когда вероятность совершения какого-либо действия минимальна. Например, многие приложения используют модальные окна во вводных инструкциях или подсказках по навигации: в самом начале они смотрятся куда адекватнее, чем в середине задачи.
Подобный формат очень удобен на мобильных устройствах, когда комментарии располагаются прямо поверх основного экрана.
Вводный оверлей приложения The Zappos для iPhone
Модальное окно, активированное пользователем
Оверлеи являются отличным средством прогрессивного открытия (progressive disclosure) — техники интерактивного дизайна, предоставляющей информацию по мере возникновения необходимости или в зависимости от задачи, которую пользователь решает в текущий момент. Главное преимущество модальных окон — возможность выполнения действия без закрытия основного окна — здесь приходится как нельзя кстати.
Так, приложение Facebook для iPhone с помощью оверлея предлагает несколько вариантов поделиться информацией. Внешне это выглядит как обычное выпадающее меню, однако такой способ сосредотачивает внимание пользователя на конкретной задаче, отодвигая остальную страницу на задний план. Главное здесь — оставить видимым изображение того элемента, который был активирован:
Различные варианты кнопки «Поделиться»
Модальное окно, активированное не пользователем
Ситуация, когда страница неожиданно темнеет, а ее контент перекрывается каким-то внезапным сообщением, однозначно расценивается пользователями как неприятная, если не возмутительная. Хорошо, если смысл оверлея оправдывает его неожиданное вторжение, но чаще всего информация имеет интерес только для самой компании (например, предложение о подписке на новости).
Многие веб-маркетологи исходят из принципа «цель оправдывает средства» и верят, что выгода от увеличения подписной базы перевешивает негативные последствия надоедливого сообщения. Если вы придерживаетесь данной стратегии, проверьте, становятся ли подписавшиеся таким образом люди действительно квалифицированными лидами.
Иногда, несмотря на вполне невинное содержание оверлея, время его появления настолько неудачно, что этим он ничем не отличается от раздражающих поп-апов. Наиболее характерный пример — окно чата, возникающее в самый неподходящий момент, скажем, при заполнении полей формы для открытия счета в банке:
Окно помощи Live Chat Support появляется на каждой странице сайта Bank of the West
В этом случае, оверлей не только не помогает, но и значительно усложняет конверсию посетителей, отвлекая их от важного действия.
Проверенным методом здесь является настройка модальных окон только на активацию пользователем или на передачу действительно срочных сообщений. Но если вы все-таки хотите использовать рекламный лайтбокс, по крайней мере, выбирайте подходящее время и страницы, на которых его раздражающий эффект будет минимален, например, перед закрытием вкладки:
Digitalmarketer.com перед закрытием страницы предлагает своим посетителям «Бесплатный подарок»
Где именно он располагается?
Распространенная проблема оверлеев — их слишком низкое расположение на странице. Особенно это актуально для мобильных девайсов, но также иногда случается и на полноразмерных экранах. Разрабатывая дизайн, помните, что у многих пользователей в браузере установлены панели закладок и инструментов, и их полезная площадь окна несколько уже, чем обычно.
Лайтбокс должен находиться как можно выше на странице — в противном случае контент может оказаться недоступным для просмотра:
Оверлей сайта verizon.com практически невидим для пользователей
Чем выше расположен ваш лайтбокс, тем меньше вероятность, что он обрежется снизу даже на самых маленьких экранах, а у пользователей будет возможность прокрутить и увидеть все его содержание.
Лайтбокс почтовой службы USPS отцентрован и смещен в сторону верхней части страницы
Еще одним требованием, особенно для больших лайтбоксов, является правильное взаимное расположение контента и элементов управления в самом оверлее. Иногда лайтбоксы ведут себя неожиданно в необычных условиях, заставляя пользователей тратить большое количество времени на поиск нужной кнопки.
Так, лайтбокс American Furniture Warehouse между фотографией стола сверху и элементом управления снизу содержит огромное количество белого пространства, вынуждая скролить в самый низ модального окна, чтобы его закрыть:
Почему вы используете оверлей, а не обычную страницу?
Последнее, но самое важное замечание: не используйте оверлей, если у вас нет ясной, веской причины, почему вы не хотите представить этот контент на обычной странице.
Среди таких причин можно выделить следующие:
В первом случае оверлей должен появляться только когда отменить совершенное действие по-настоящему сложно. Но даже тогда предусмотрите опцию «Не показывать это сообщение», чтобы не надоедать пользователям.
Последнее же условие нередко становится делом интерпретации. «Важно» для покупателей совсем не всегда совпадает с тем, что под этим подразумевают маркетологи. Проще всего обозначить важность, когда интересы компании и клиентов взаимосвязаны.
Например, в декабре сайт фонда защиты окружающей среды предлагал всем посетителям совершить благотворительный акт при условии, что каждый пожертвованный до определенной даты доллар будет дополнен спонсором. В конце года для многих людей такое сообщение оказалось привлекательным с учетом скидок на налоги благотворителям.
Оверлей содержит «выгодную» для пользователей информацию
Однако уже в апреле другой оверлей больше не учитывал временной фактор и, по сути, представлял интерес только для самой организации.
Менее интересный призыв к действию: «3 больших победы уже близко, с вашей помощью»
Вместо заключения
При определенный условиях оверлеи могут быть эффективным инструментом интерактивного дизайна, однако нередко их использование необоснованно, а то и вовсе неуместно. Мобильные устройства и маленькие экраны компьютеров часто отображают лайтбокс некорректно, создавая проблемы и нервируя посетителей. Люди вынуждены тратить больше сил на выполнение простейших задач — в таком случае, лучше совсем отказаться от данной техники.
Сомневаясь, размещать ли контент в оверлее или на отдельной странице, задайте себе пять вопросов из этого поста. Если вы все еще думаете, что оверлей — идеальное решение для вашего дизайна, действуйте осторожно. Протестируйте ваш лендинг или приложение на разных браузерах и девайсах, чтобы убедиться: он не испортит всю вашу работу.
Автоматизация Для Самых Маленьких. Часть первая (которая после нулевой). Виртуализация сети
В предыдущем выпуске я описал фреймворк сетевой автоматизации. По отзывам у некоторых людей даже этот первый подход к проблеме уже разложил некоторые вопросы по полочкам. И это очень меня радует, потому что наша цель в цикле — не обмазать питоновскими скриптами анзибль, а выстроить систему.
Этот же фреймворк задаёт порядок, в котором мы будем разбираться с вопросом.
И виртуализация сети, которой посвящён этот выпуск, не особо укладывается в тематику АДСМ, где мы разбираем автоматику.
Но давайте взглянем на неё под другим углом.
Уже давно одной сетью пользуются многие сервисы. В случае оператора связи это 2G, 3G, LTE, ШПД и B2B, например. В случае ДЦ: связность для разных клиентов, Интернет, блочное хранилище, объектное хранилище.
И все сервисы требуют изоляции друг от друга. Так появились оверлейные сети.
И все сервисы не хотят ждать, когда человек настроит их вручную. Так появились оркестраторы и SDN.
Первый подход к систематической автоматизации сети, точнее её части, давно предпринят и много где внедрён в жизнь: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Вот с ним сегодня и поразбираемся.
Содержание
Причины
И раз уж мы об этом заговорили, то стоит упомянуть предпосылки к виртуализации сети. На самом деле этот процесс начался не вчера.
Наверно, вы не раз слышали, что сеть всегда была самой инертной частью любой системы. И это правда во всех смыслах. Сеть — это базис, на который опирается всё, и производить изменения на ней довольно сложно — сервисы не терпят, когда сеть лежит. Зачастую вывод из эксплуатации одного узла может сложить большую часть приложений и повлиять на много клиентов. Отчасти поэтому сетевая команда может сопротивляться любым изменениям — потому что сейчас оно как-то работает (мы, возможно, даже не знаем как), а тут надо что-то новое настроить, и неизвестно как оно повлияет на сеть.
Чтобы не ждать, когда сетевики прокинут VLAN и любые сервисы не прописывать на каждом узле сети, люди придумали использовать оверлеи — наложенные сети — коих великое многообразие: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE итд.
Их привлекательность заключается в двух простых вещах:
Вся серия будет описывать датацентр, состоящий из рядов однотипных стоек, в которых установлено одинаковое серверное оборудование.
На этом оборудовании запускаются виртуальные машины/контейнеры/серверлесс, реализующие сервисы.
Терминология
В цикле сервером я буду называть программу, которая реализует серверную сторону клиент-серверной коммуникации.
Физические машины в стойках называть серверами не будем.
Физическая машина — x86-компьютер, установленный в стойке. Наиболее часто употребим термин хост. Так и будем называть её «машина» или хост.
Гипервизор — приложение, запущенное на физической машине, эмулирующее физические ресурсы, на которых запускаются Виртуальные Машины. Иногда в литературе и сети слово «гипервизор» используют как синоним «хост».
Виртуальная машина — операционная система, запущенная на физической машине поверх гипервизора. Для нас в рамках данного цикла не так уж важно, на самом ли деле это виртуальная машина или просто контейнер. Будем называть это «ВМ«
Тенант — широкое понятие, которое я в этой статье определю как отдельный сервис или отдельный клиент.
Мульти-тенантность или мультиарендность — использование одного и того же приложения разными клиентами/сервисами. При этом изоляция клиентов друг от друга достигается благодаря архитектуре приложения, а не отдельно-запущенным экземплярам.
ToR — Top of the Rack switch — коммутатор, установленный в стойке, к которому подключены все физические машины.
Кроме топологии ToR, разные провайдеры практикуют End of Row (EoR) или Middle of Row (хотя последнее — пренебрежительная редкость и аббревиатуры MoR я не встречал).
Underlay network или подлежащая сеть или андэрлей — физическая сетевая инфраструктура: коммутаторы, маршрутизаторы, кабели.
Overlay network или наложенная сеть или оверлей — виртуальная сеть туннелей, работающая поверх физической.
L3-фабрика или IP-фабрика — потрясающее изобретение человечества, позволяющее к собеседованиям не повторять STP и не учить TRILL. Концепция, в которой вся сеть вплоть до уровня доступа исключительно L3, без VLAN и соответственно огромных растянутых широковещательных доменов. Откуда тут слово «фабрика» разберёмся в следующей части.
SDN — Software Defined Network. Едва ли нуждается в представлении. Подход к управлению сетью, когда изменения на сети выполняются не человеком, а программой. Обычно означает вынесение Control Plane за пределы конечных сетевых устройств на контроллер.
NFV — Network Function Virtualization — виртуализация сетевых устройств, предполагающая, что часть функций сети можно запускать в виде виртуальных машин или контейнеров для ускорения внедрения новых сервисов, организации Service Chaining и более простой горизонтальной масштабируемости.
VNF — Virtual Network Function. Конкретное виртуальное устройство: маршрутизатор, коммутатор, файрвол, NAT, IPS/IDS итд.
Я сейчас намеренно упрощаю описание до конкретной реализации, чтобы сильно не запутывать читателя. Для более вдумчивого чтения отсылаю его к секции Ссылки. Кроме того, Рома Горге, критикующий данную статью за неточности, обещает написать отдельный выпуск о технологиях виртуализации серверов и сетей, более глубокую и внимательную к деталям.
Большинство сетей сегодня можно явно разбить на две части:
Underlay — физическая сеть со стабильной конфигурацией.
Overlay — абстракция над Underlay для изоляции тенантов.
Это верно, как для случая ДЦ (который мы разберём в этой статьей), так и для ISP (который мы разбирать не будем, потому что уже было в СДСМ). С энтерпрайзными сетями, конечно, ситуация несколько иная.
Картинка с фокусом на сеть:
Underlay
Underlay — это физическая сеть: аппаратные коммутаторы и кабели. Устройства в андерлее знают, как добраться до физических машин.
Опирается он на стандартные протоколы и технологии. Не в последнюю очередь потому, что аппаратные устройства по сей день работают на проприетарном ПО, не допускающем ни программирование чипа, ни реализацию своих протоколов, соответственно, нужна совместимость с другими вендорами и стандартизация.
А вот кто-нибудь вроде Гугла может себе позволить разработку собственных коммутаторов и отказ от общепринятых протоколов. Но LAN_DC не Гугл.
Underlay сравнительно редко меняется, потому что его задача — базовая IP-связность между физическими машинами. Underlay ничего не знает о запущенных поверх него сервисах, клиентах, тенантах — ему нужно только доставить пакет от одной машины до другой.
Underlay может быть например таким:
Вручную, скриптами, проприетарными утилитами.
Более подробно андерлею будет посвящена следующая статья цикла.
Overlay
Overlay — виртуальная сеть туннелей, натянутая поверх Underlay, она позволяет ВМ одного клиента общаться друг с другом, при этом обеспечивая изоляцию от других клиентов.
Данные клиента инкапсулируются в какие-либо туннелирующие заголовки для передачи через общую сеть.
Так ВМ одного клиента (одного сервиса) могут общаться друг с другом через Overlay, даже не подозревая какой на самом деле путь проходит пакет.
Overlay может быть например таким, как уже я упоминал выше:
Да, это SDN в чистом виде.
Существует два принципиально различающихся подхода к организации Overlay-сети:
Overlay с ToR’a
Overlay может начинаться на коммутаторе доступа (ToR), стоящем в стойке, как это происходит, например, в случае VXLAN-фабрики.
Это проверенный временем на сетях ISP механизм и все вендоры сетевого оборудования его поддерживают.
Однако в этом случае ToR-коммутатор должен уметь разделять различные сервисы, соответственно, а сетевой администратор должен в известной степени сотрудничать с администраторами виртуальных машин и вносить изменения (пусть и автоматически) в конфигурацию устройств.
Тут я отошлю читателя к статье о VxLAN на хабре нашего старого друга @bormoglotx.
В этой презентации с ENOG подробно описаны подходы к строительству сети ДЦ с EVPN VXLAN-фабрикой.
А для более полного погружения в реалии, можно почитать цискину книгу A Modern, Open, and Scalable Fabric: VXLAN EVPN.
Замечу, что VXLAN — это только метод инкапсуляции и терминация туннелей может происходить не на ToR’е, а на хосте, как это происходит в случае OpenStack’а, например.
Однако, VXLAN-фабрика, где overlay начинается на ToR’е является одним из устоявшихся дизайнов оверлейной сети.
Overlay с хоста
Другой подход — начинать и терминировать туннели на конечных хостах.
В этом случае сеть (Underlay) остаётся максимально простой и статичной.
А хост сам делает все необходимые инкапсуляции.
Для этого потребуется, безусловно, запускать специальное приложение на хостах, но оно того стоит.
Во-первых, запустить клиент на linux-машине проще или, скажем так, — вообще возможно — в то время как на коммутаторе, скорее всего, придётся пока обращаться к проприетарным SDN-решениям, что убивает идею мультивендорности.
Во-вторых, ToR-коммутатор в этом случае можно оставить максимально простым, как с точки зрения Control Plane’а, так и Data Plane’а. Действительно — с SDN-контроллером ему тогда общаться не нужно, и хранить сети/ARP’ы всех подключенных клиентов — тоже — достаточно знать IP-адрес физической машины, что кратно облегчает таблицы коммутации/маршрутизации.
В серии АДСМ я выбираю подход оверлея с хоста — далее мы говорим только о нём и возвращаться к VXLAN-фабрике мы уже не будем.
Проще всего рассмотреть на примерах. И в качестве подопытного мы возьмём OpenSource’ную SDN платформу OpenContrail, ныне известную как Tungsten Fabric.
В конце статьи я приведу некоторые размышления на тему аналогии с OpenFlow и OpenvSwitch.
На примере Tungsten Fabric
На каждой физической машине есть vRouter — виртуальный маршрутизатор, который знает о подключенных к нему сетях и каким клиентам они принадлежат — по сути — PE-маршрутизатор. Для каждого клиента он поддерживает изолированную таблицу маршрутизации (читай VRF). И собственно vRouter делает Overlay’ное туннелирование.
Чуть подробнее про vRouter — в конце статьи.
Каждая ВМ, расположенная на гипервизоре, соединяется с vRouter’ом этой машины через TAP-интерфейс.
TAP — Terminal Access Point — виртуальный интерфейс в ядре linux, которые позволяет осуществлять сетевое взаимодействие.
Если за vRouter’ом находится несколько сетей, то для каждой из них создаётся виртуальный интерфейс, на который назначается IP-адрес — он будет адресом шлюза по умолчанию.
Все сети одного клиента помещаются в один VRF (одну таблицу), разных — в разные.
Сделаю тут оговорку, что не всё так просто, и отправлю любознательного читателя в конец статьи.
Чтобы vRouter’ы могли общаться друг с другом, а соответственно и ВМ, находящиеся за ними, они обмениваются маршрутной информацией через SDN-контроллер.
Чтобы выбраться во внешний мир, существует точка выхода из матрицы — шлюз виртуальной сети VNGW — Virtual Network GateWay (термин мой).
Теперь рассмотрим примеры коммуникаций — и будет ясность.
Коммуникация внутри одной физической машины
VM0 хочет отправить пакет на VM2. Предположим пока, что это ВМ одного клиента.
Data Plane
Пакет в этом случае не попадает в физическую сеть — он смаршрутизировался внутри vRouter’а.
Control Plane
Гипервизор при запуске виртуальной машины сообщает ей:
И снова, реальная процедура взаимодействия упрощена в угоду понимания концепции.
Таким образом все ВМ одного клиента на данной машине vRouter видит как непосредственно подключенные сети и может сам между ними маршрутизировать.
А вот VM0 и VM1 принадлежат разным клиентам, соответственно, находятся в разных таблицах vRouter’а.
Смогут ли они друг с другом общаться напрямую, зависит от настроек vRouter и дизайна сети.
Например, если ВМ обоих клиентов используют публичные адреса, или NAT происходит на самом vRouter’е, то можно сделать и прямую маршрутизацию на vRouter.
В противной же ситуации возможно пересечение адресных пространств — нужно ходить через NAT-сервер, чтобы получить публичный адрес — это похоже на выход во внешние сети, о которых ниже.
Коммуникация между ВМ, расположенными на разных физических машинах
Data Plane
Control Plane
При запуске машины происходит всё то же, что было описано выше.
И плюс ещё следующее:
На самом деле MPLS-метка выделяется vRouter’ом безусловно всегда — ведь неизвестно заранее, что машина будет взаимодействовать только с другими машинам за тем же vRouter’ом и это скорее всего даже не так.
Overlay может меняться хоть каждую минуту. Примерно так это и происходит в публичных облаках, когда клиенты регулярно запускают и выключают свои виртуальные машины.
Центральный контроллер берёт на себя все сложности с поддержанием конфигурации и контролем таблиц коммутации/маршрутизации на vRouter.
Если говорить грубо, то контроллер запиривается со всеми vRouter’ами по BGP (или похожему на него протоколу) и просто передаёт маршрутную информацию. BGP, например, уже имеет Address-Family для передачи метода инкапсуляции MPLS-in-GRE или MPLS-in-UDP.
При этом не меняется никоим образом конфигурация Underlay-сети, которую кстати, автоматизировать на порядок сложнее, а сломать неловким движением проще.
Выход во внешний мир
Где-то симуляция должна закончиться, и из виртуального мира нужно выйти в реальный. И нужен таксофон шлюз.
Практикуют два подхода:
Преимущество второго подхода в дешёвой горизонтальной масштабируемости — не хватает мощности — запустили ещё одну виртуалку со шлюзом. На любой физической машине, без необходимости искать свободные стойки, юниты, вывода питания, покупать саму железку, везти её, устанавливать, коммутировать, настраивать, а потом ещё и менять в ней сбойные компоненты.
Минусы же у виртуального шлюза в том, что единица физического маршрутизатора всё же на порядки мощнее многоядерной виртуалки, а его софт, подогнанный под его же аппаратную основу, работает значительно стабильнее (нет). Сложно отрицать и тот факт, что программно-аппаратный комплекс просто работает, требуя только настройки, в то время как запуск и обслуживание виртуального шлюза — занятие для сильных инженеров.
Одной своей ногой шлюз смотрит в виртуальную сеть Overlay, как обычная Виртуальная Машина, и может взаимодействовать со всеми другими ВМ. При этом она может терминировать на себе сети всех клиентов и, соответственно, осуществлять и маршрутизацию между ними.
Другой ногой шлюз смотрит уже в магистральную сеть и знает о том, как выбраться в Интернет.
Data Plane
То есть процесс выглядит так:
Трафик в обратную сторону проходит те же шаги в противоположном порядке.
Control Plane
VNGW1 устанавливает BGP-соседство с SDN-контроллером, от которого он получает всю маршрутную информацию о клиентах: за каким IP-адресом (vRouter’ом) находится какой клиент, и какой MPLS-меткой он идентифицируется.
Аналогично он сам SDN-контроллеру сообщает дефолтный маршрут с меткой этого клиента, указывая себя в качестве nexthop’а. А дальше этот дефолт приезжает на vRouter’ы.
На VNGW обычно происходит агрегация маршрутов или NAT-трансляция.
И в другую сторону в сессию с бордерами или Route Reflector’ами он отдаёт именно этот агрегированный маршрут. А от них получает маршрут по умолчанию или Full-View, или что-то ещё.
В плане инкапсуляции и обмена трафиком VNGW ничем не отличается от vRouter.
Если немного расширить область, то к VNGW и vRouter’ам можно добавить другие сетевые устройства, такие как файрволы, фермы очистки или обогащения трафика, IPS и так далее.
И с помощью последовательного создания VRF и правильного анонса маршрутов, можно заставлять трафик петлять так, как вам хочется, что и называется Service Chaining’ом.
То есть и тут SDN-контроллер выступает в роли Route-Reflector’а между VNGW, vRouter’ами и другими сетевыми устройствами.
Но фактически контроллер спускает ещё информацию об ACL и PBR (Policy Based Routing), заставляя отдельные потоки трафика ходить не так, как им велит маршрут.
Зачем ты всё время делаешь ремарку GRE/UDP?
Ну, вообще, это, можно сказать, специфично для Tungsten Fabric — можно вообще не брать во-внимание.
Но если брать, то сам TF, ещё будучи OpenContrail’ом поддерживал обе инкапсуляции: MPLS in GRE и MPLS in UDP.
UDP хорош тем, что в Source Port в его заголовке очень легко закодировать хэш-функцию от изначальных IP+Proto+Port, что позволит делать балансировку.
В случае GRE, увы, есть только внешние заголовки IP и GRE, которые одинаковы для всего инкапсулированного трафика и речь о балансировке не идёт — мало кто может заглянуть так глубоко внутрь пакета.
До некоторого времени маршрутизаторы, если и умели в динамические туннели, то только в MPLSoGRE, и только совсем недавно, научились в MPLSoUDP. Поэтому приходится делать всегда ремарку о возможности двух разных инкапсуляций.
Справедливости ради, стоит отметить, что TF вполне поддерживает и L2-связность с помощью VXLAN.
Ты обещал провести параллели с OpenFlow.
Они и правда напрашиваются. vSwitch в том же OpenStack’е делает весьма похожие вещи, используя VXLAN, у которого, кстати, тоже UDP-заголовок.
В Data Plane они работают примерно одинаково, существенно различается Control Plane. Tungsten Fabric использует XMPP для доставки информации о маршрутах на vRouter, в то время, как в OpenStack’е работает Openflow.
А можно чуть больше про vRouter?
Он делится на две части: vRouter Agent и vRouter Forwarder.
Первый запускается в User Space хостовой ОС и общается с SDN-контроллером, обмениваясь информацией о маршрутах, VRF и ACL.
Второй реализует Data Plane — обычно в Kernel Space, но может запускаться и на SmartNIC’ах — сетевых картах с CPU и отдельным программируемым чипом коммутации, что позволяет снять нагрузку с CPU хостовой машины, а сеть сделать быстрее и более предсказуемой.
Ещё возможен сценарий, когда vRouter — это DPDK-приложение в User Space.
vRouter Agent спускает настройки на vRouter Forwarder.
Что за Virtual Network?
Я обмолвился в начале статьи о VRF, что мол каждый тенант привязывается к своему VRF. И если для поверхностного понимания работы оверлейной сети этого было достаточно, то уже на следующей итерации надо делать уточнения.
Обычно в механизмах виртуализации сущность Virtual Network (можно считать это именем собственным) вводится отдельно от клиентов/тенантов/виртуальных машин — вполне себе самостоятельная вещь. А этот Virtual Network через интерфейсы уже можно подключить в один тенант, в другой, в два, да хоть куда. Так, например, реализуется Service Chaining, когда трафик нужно пропустить через определённые ноды в нужной последовательности, просто в правильной последовательности создавая и привзявая Virtual Network’и.
Поэтому как такового прямого соответствия между Virtual Network и тенантом нет.
Заключение
Это весьма поверхностное описание работы виртуальной сети с оверлеем с хоста и SDN-контроллером. Но какую бы платформу виртуализации вы сегодня ни взяли, работать она будет похожим образом, будь то VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric или Juniper Contrail. Они будут отличаться видами инкапсуляций и заголовков, протоколами доставки информации на конечные сетевые устройства, но принцип программно настраиваемой оверлейной сети, работающей поверх сравнительно простой и статичной андерлейной сети останется прежним.
Можно сказать, что области создания приватного облака на сегодняшний день SDN на основе оверлейной сети победил. Впрочем это не значит, что Openflow нет места в современном мире — он используется в OpenStacke и в той же VMWare NSX, его, насколько мне известно, использует Google для настройки андерлейной сети.
Чуть ниже я привёл ссылки на более подробные материалы, если хочется изучить вопрос глубже.
А что там наш Underlay?
А в общем-то ничего. Он всю дорогу не менялся. Всё, что ему нужно делать в случае оверлея с хоста — это обновлять маршруты и ARP’ы по мере появления и исчезновения vRouter/VNGW и таскать пакеты между ними.
Давайте сформулируем список требований к Underlay-сети.
Очевидно, я сильно ограничиваю нас всех, используя в качестве примера сеть ДЦ, построенную на фабрике Клоза с чистой IP-маршрутизацией и оверлеем с хоста.
Однако я уверен, что любую сеть, имеющую дизайн, можно описать в формальных терминах и автоматизировать. Просто я здесь преследую целью разобраться в подходах к автоматизации, а не запутать всех вообще, решая задачу в общем виде.
В рамках АДСМ мы с Романом Горге планируем опубликовать отдельный выпуск про виртуализацию вычислительных мощностей и её взаимодействие с виртуализацией сети. Оставайтесь на связи.