Что такое NSX Edge

В данной статье речь пойдет о определенном типе транспортных нод в NSX – Edge. До этого мы не обсуждали их конкретно, лишь говорили, что они нужны для «соединения» виртуальной сети с физической и для выделения ресурсов на всяческие сервисные задачи и маршрутизацию. Настало время рассмотреть их подробнее, прежде чем перейти к самому логическому роутингу в NSX. Здесь мы рассмотрим только сам объект Edge, не вдаваясь в подробности о тех службах, которые его используют.

Да, прошло достаточно много времени со дня публикации последней статьи про NSX-T. За это время изменилось некоторое количество вещей, в том числе и название продукта, ранее это было NSX-T, а сейчас это просто NSX. Так же NSX начиная с версии 4.0 более не поддерживает KVM в качестве транспортных нод и не поддерживает еще парочку вещей, но сейчас не об этом. Это так, к слову. Что бы было понятно почему в предыдущих статьях был NSX-T, а сейчас просто NSX.

Очень часто сталкиваюсь с инженерами и сотрудниками различных IT подразделений и компаний, которым в принципе трудно понять, что такое SDN, не говоря уже про NSX, что он делает и для чего он нужен, а самое главное, как он устроен. И это несмотря на то что эти компании покупают или рассматривают к покупке данный продукт. Поэтому я решил остановиться на Edge Nod-ах подробнее и раскрыть их как просто объект в физическом мире без нагромождения логических служб, которые и без того достаточно комплексны в своем устройстве.

Итак, как мы помним у нас есть Транспортные Ноды – ESXi хосты, которые тащат на себе виртуальные машины и строят меж собой Overlay туннели, что бы эти VM могли общаться между собой по сети в пределах L2 сегмента. Но виртуальным машинам нужно взаимодействовать не только друг с другом, но и с внешним физическим миром. И это взаимодействие возможно только через Edge Nod-ы.

Edge Nod-ы служат пограничными инстансами на пути North-South траффика. Производят маршрутизацию выходящего и входящего в NSX сетевого траффика. Все сетевые пакеты, предназначенные внешним получателям, проходят через «эджи» (с вашего позволения буду именовать их так).

И когда VM нужно «поговорить» с внешним миром, ее траффик попадает в Geneve туннель, построенный между ESXi хостом и Edge. Затем Edge обрабатывает его и выпускает в физический мир. Точно так же и с входящим из физики траффиком, он летит на Edge, а за тем, через туннель на гипервизор, где располагается VM. Из этого следует что у Edge Node так же, как и ESXi есть TEP интерфейс, в большинстве случаев не один, через который строятся туннели с каждой другой Транспортной Нодой в NSX. Так же у Edge есть и интерфейсы, смотрящие в физическую сеть, предоставляющие возможность сетевой связности между виртуальной сетью и физической. Как все это происходит в деталях с маршрутизацией и прочим, мы пока опустим.

Так как весь North-South траффик ходит через «эдж», на «эдже» базируется большая часть всех сетевых служб NSX-а.

Edge служит пулом вычислительных ресурсов для этих служб, но некоторые из них присутствуют фактически только на ESXi хостах, например, Distributed Firewall.

Теперь, когда нам стало понятно для чего нужен Edge, перейдем к его физическим особенностям. Edge Node является Транспортной Нодой и поэтому присутствует в физическом мире и бывает двух типов:

Виртуальная машина
Физический сервер

VM Edge Node

Виртуальная машина разворачивается только на ESXi хостах и может быть нескольких размеров:

Размер	Память	vCPU	Размер vmdk	Для чего
NSX Edge Small	4 GB	2	200 GB	Только для лабы или пилота.
NSX Edge Medium	8 GB	4	200 GB	Только для не затратных вычислений, типа роутинга, L4 firewall, L4 балансировщика и подразумевает не более 2 Gb/s пропускной способности.
NSX Edge Large	32 GB	8	200 GB	Рассчитан на пропускную способность до 10 Gb/s и может немного больше сервисов.
NSX Edge Extra Large	64 GB	16	200 GB	Подразумевает использование всех сервисов NSX и рассчитан на пропускную способность более 10 Gb/s но максимум 20 Gb/s.

Развернуть Edge VM можно из консоли vCenter или из интерфейса NSX, это как правило стандартные и простые способы. Так же можно заморочиться и организовать установку «эджа» с помощью PXE загрузки и ISO образа, это более сложный и комплексный способ, но он позволят развертывать множество «эджей» одновременно и с заранее заданными настройками, что в больших инфраструктурах может быть оправдано.

Что нужно знать так это то, что Edge Node после развертывания должен (или должна) быть зарегистрирован в Management Plane NSX-а, чтобы имелась возможность его добавить в транспортную зону и произвести дальнейшую конфигурацию. И только вариант деплоя из интерфейса NSX делает это автоматически. Все остальные варианты подразумевают, что вы это сделаете потом сами. Из этого следует что вариант через NSX UI самый предпочтительный в типовых средах.

Так же есть и требования при развертывании Edge в качестве VM:

Разворачивается только из OVA, OVF, ISO форматов или можно грузить VM с PXE.
Естественно только на VMware ESXi.
VMware Tools на Edge Node не могут быть обновлены или переустановлены.
Все Edge Nod-ы будучи в кластере должны использовать одни и те же NTP сервера.

Так же Edge VM может пользоваться DPDK функционалом гипервизора, для этого ESXi хост должен поддерживать инструкции AES-NI на процессоре и иметь поддержку так называемых Huge Page (больших страниц памяти) размером 1GB.

Что такое DPDK? Это аббревиатура Intel® Data Plane Development Kit (Intel® DPDK). Набор библиотек, в гостевой ОС виртуальной машины, как правило Linux-based. Этот набор библиотек позволяет приложениям (написанным с использованием этих библиотек) внутри ОС обращаться к устройствам ввода-вывода (сетевой карте) напрямую, минуя аппаратный уровень. Что намного увеличивает производительность и полосу пропускания, так как минуется уровень абстракции, представляемый гипервизором. Но это не тоже самое что SR-IOV или DirectPath I/O, так как VM видит у себя виртуальный адаптер, а не проброшенную напрямую с физического сервера PCI функцию или устройство. При этом сохраняется весь функционал виртуального сетевого адаптера, vMotion, снепшоты и так далее, все что связано с Stun-Unstun операцией.

Но стоит сказать, что представление SR-IOV или DirectPath I/O в VM DPDK так же поддерживает, ключевым тут является что представление происходит приложению, а не ядру гостевой системы.

DPDK позволяет Edge Node, а точнее сетевым службам, запущенным на «эдже» достигать меньших задержек и большей пропускной способности при обработке большого объема траффика. На физическом (Bare Metal) «эдже» DPDK так же доступен.

Вернемся к «эджам». Edge VM по умолчанию разворачивается с несколькими vNIC на борту. А точнее их пять (один, как и ранее для менеджмента и остальные на сетевой ввод-вывод).

Аплинки Edge ноды носят характерные их назначению названия – eth0 (для менеджмента), fp-ethX (fast path Ethernet для непосредственно траффика).

Как и можно догадаться виртуальные адаптеры Edge подключаются в виртуальный коммутатор гипервизора и должны иметь выход в физическую сеть с помощью физических Uplink-ов гипервизора. Причем неважно какой тип виртуального свича присутствует на ESXi, это может быть, как DVS так Standard vSwitch.

На fp-eth интерфейсы «эджа» как правило подаются транком необходимые VLAN-ы. То есть данные интерфейсы добавлены в порт-группу ESXi хоста, где необходимый список VLAN-ов подан транком. Список этих VLAN-ов включает в себя VLAN для overlay (потому как на Edge нодах так же, как и на ESXi хостах создаются TEP интерфейсы) и VLAN-ы предназначенные для связи с физическими маршрутизаторами для установления BGP/OSPF связности между Uplink-интерфейсами виртуальных маршрутизаторов NSX (которые как мы помним живут на «эджах») и физических маршрутизаторов. Вообще вариантов подачи VLAN-ов на сетевые интерфейсы Edge великое множество и все зависит от дизайна вашего решения. А раз в Edge заходят все необходимые VLAN-ы, ему нужно как с ними работать и распределять по ним Overlay траффик, исходящий с TEP и траффик, направленный к физическим маршрутизаторам. Как раз-таки для этого внутри Edge ноды присутствует свой виртуальный коммутатор, так же, как и на ESXi хосте. Это N-VDS, о котором я писал в предыдущих статьях цикла.

В зависимости от конфигурации, которую задали при развертывании Edge Node, N-VDS-ов может быть несколько.

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

Bare Metal Edge Node

Теперь поговорим про «металлические эджи» или Bare Metal Edge. Фактически это обычные железные сервера, на борт которых устанавливается ОС «эджа». Надобность в них возникает в основном из соображений производительности. Как мы помним «эдж» развернутый как VM может выдать не более 20 Gb/s, а «металлический» упрется в суммарную производительность его физических сетевых адаптеров. Которые в современных реалиях могут быть 10/25/40/100G. С точки зрения требования к характеристикам выглядит оно так.

Form Factor	Memory	CPU Cores	Disk
Bare metal (minimum requirements)	32 GB	8	200 GB
Bare metal (recommended requirements)	256 GB	24	200 GB

Как видим для физического «эджа» нам не нужен монстр в ресурсной перспективе, но тем не менее стоит разворачивать Edge на стареньком пенсионном сервачке, купленном под 1с пять лет назад. Для не очень требовательной к пропускной способность инфраструктуре вполне хватит развертывания на виртуальной машине, тем более учитывая, что Edge никогда не разворачивается один (минимум два) в целях балансировки нагрузки и высокой доступности. А если смотреть в сторону Bare Metal Edge, то стоит обратить внимание на сервера укомплектованные сетевыми картами с поддержкой DPDK, так как это позволит осуществлять передачу трафика на скоростях максимально близких к пропускной способности адаптеров. Если VM Edge мы разворачиваем с помощью OVA, OVF образа через vCenter или напрямую из интерфейса NSX, то с Bare Metal Edge не все так просто, и мы прибегаем к методу «по старинке», да-да с помощью флешки (ну или диска) и ISO образа, который мы скачиваем с My VMware. Мы проходим обычную процедуру установки Edge на железный сервер, с воткнутой флешкой, через консоль этого самого сервера.

Так же, как и с VM Edge, для инсталляции «железного эджа» можно использовать PXE загрузку по сети со всеми ее плюсами и минусами.

Развертывание VM Edge Node

Мы не будем рассматривать все варианты развертывания всех форм факторов «эджа», вместо этого остановимся на самом популярном как форм факторе, так и варианте развертывания. Развернем Edge в виде виртуальной машины из интерфейса NSX. Логинимся в NSX UI и идем в System>Fabric>Nodes>Edge Transport Nodes. На этой панели отображаются все наши Edge Nod-ы в системе и тут же мы создаем новые.

Жмем ADD EDGE NODE и нам предоставляется «мастер», который собирает настройки и требуемую конфигурацию для развертывания. Мы рассмотрим вариант с одним n-vds свичем, двумя аплинк интерфейсами в нем и двумя TEP интерфейсами.

Мы выбираем размер, даем FQDN и VMname для будущей Edge Node. Так же можно указать параметры резервирования ресурсов в vSphere для этой машины в раскрывающемся меню снизу. Идем дальше.

Задаем пароли для локальных пользователей Edge VM. Это пользователи root, admin и audit. В добавок есть возможность включить SSH для каждого и них. Для обычных операций, связанных с траблшутингом и управление вполне хватит и admin-а. Пользователь root нужен для каких-то углубленных задач, связанных с деятельностью в ОС «эджа» и в повседневных задачах не нужен. Далее.

Тут указываем на каких ресурсах мы будем размещать наш Edge. Выбираем vCenter (который Вы заблаговременно добавили в NSX), кластер с включенным DRS или если такого нет, то кластер без него и хост в этом кластере, а также датастор, в моем варианте это vSAN.

В пункте 4 мы определяем сетевые параметры для нашей VM. Это относится к сети управления и не как не к транспортной сети NSX-а. Определяем, как назначается Management IP для «эджа» — DHCP или статический. Во втором случае указываем адрес в виде CIDR и шлюз. А также указываем DNS, NTP и что самое важное порт группу в vSphere, куда будет подключен Management интерфейс Edge. Это может быть какой-то VLAN для сети управления, куда возможно добавлены интерфейсы ESXi хостов с ролью Management. Именно на этот интерфейс вы будите подключаться по SSH. Далее.

А вот тут самый ответственный пункт и наиболее важный для понимания. Мы конфигурируем сколько будет N-VDS свичей на ноде, какие аплинки будут в них добавлены и сколько TEP интерфейсов будет на Edge. То есть все что касается внутренней сетевой архитектуры «эджа». Начнем по порядку.

Мы помним, что у Edge Node есть N-VDS и это виртуальный свитч, N-VDS-ов может быть несколько и у каждого из них должен быть минимум один аплинк.

По умолчанию нам предлагается создать Edge с одним N-VDS-ом. Но мы при желании можем добавить дополнительные (вопросы из ряда – «а зачем?», «а сколько надо?» или, «а как правильно?», пока опустим, мы вернемся к ним позже в других статьях). Там, где на скриншоте выделено зеленым, фигурирует кнопка +ADD SWITCH, она как раз и добавляет в конфигурацию еще свичи, но только после того, как вы до конца заполните конфигурацию первого, и она будет корректной. И там же где эта кнопка, снизу конфиг каждого свича можно свернуть или развернуть для удобства. Перейдем к конфигурации первого свича.

Edge Swith Name – собственно имя свича.

Transport Zone. В каких транспортных зонах будет этот свитч участвовать. Edge Node может быть добавлена в только одну транспортную зону типа overlay. Но в множество зон типа VLAN. Как помним VLAN транспортные зоны нужны для размещения в них сегментов на базе VLAN-ов. И именно они «подаются» в Edge для соединения overlay сетей, NSX-а с физическими по L3, например, с помощью BGP.

Uplink Profile. Так как у нас есть N-VDS, ему нужны аплинки (являющиеся fp-eth интерфесами или по-простому vNIC-ами Edge VM) и зачастую этих аплинков несколько. Uplink Profile определяет сколько аплинков будет у N-VDS который мы конфигурируем в данное время, будут ли они собраны в LAG, как на них будет балансироваться траффик и будет ли вообще. А так же в нем присутствуют другие настройки. Рассмотрим подробнее Uplink Profile. Начнем с того что вы его выбираете из списка доступных. А раз есть этот список, значит можно предварительно его пополнить новыми политиками или изменить уже имеющиеся. Он расположен в System>Fabric>Profiles>Uplink Profiles.

В этом списке присутствуют профили как для хостов, так и для «эджей», они различаются названиями. Притом между этими профилями с технической точки зрения нет никакой разницы, они содержат просто различные конфигурации для одних и тех же параметров. Например, для хоста ESXi мы имеем профиль, в котором говориться, что у хоста четыре интерфейса будут собраны в LAG, а для Edge Node профиль говорит использовать просто балансировку нагрузки между ее аплинками.

Так же есть несколько типовых Default профилей, которые присутствуют с момента развертывания NSX Manager-а. В принципе в большинстве средних инфраструктур этих профилей вполне достаточно. У меня в интерфейсе есть два закрашенных профиля, один для «эджей» (который сверху) и второй для хостов. Выбрав определенный профиль, посмотрим его содержание.

Помимо имени и описания тут присутствует Transport VLAN – это VLAN по которому будет ходить Overlay трафик у транспортной ноды, в данном случае — у нашего «эджа». Следует заметить, что в более ранних версиях NSX требовалось Transport VLAN-ы у хостов и у «эджей» делать разными в случае если Edge VM располагался на хосте, добавленном в NSX, то есть так же имеющего Uplink Profile и данную настройку. Начиная с версии 3.2 этого требования нет, то есть и хост и «эдж» могут иметь один и то же Transport VLAN, даже если «эдж» расположен на этом хосте.

Далее идет MTU, который должен быть не менее 1700. Рекомендуется конечно использовать Jumbo Frame если это возможно. Данное значение определяет какое MTU будет использовано на аплинках Транспортной Ноды конфигурируемого N-VDS свича.

LAGs. Данный раздел определяет настройки бондинга на Edge. Это актуально для Bare Metal или для ESXi и тут мы не будем на этом останавливаться, так как разворачиваем Edge в форм-факторе VM.

Teamings. Тут нас ждет список из Teaming политик, используемых в Uplink Profile. Teaming Policy тут очень похожи на аналогичные настройки в порт группах vSwitch или VDS на ESXi хостах. Функции они выполняют те же самые. Рассмотрим их подробнее. Каждая политика может иметь один из нескольких режимов:

Failover Order. При создании нового Uplink Profile, ставиться по умолчанию, но естественно может быть изменена. Нет никакой балансировки, используется один Active аплинк, остальные Standby (так же, как и на ESXi в аналогичной политике). Если конфигурируемая политика для Edge Node, то вам не стоит выбирать Standby аплинки, так как в случае Edge VM это не имеет смысла, потому что аплинки виртуальные и не могут «упасть», может упасть физическая сетевая карта на ESXi, но с этим должен уже разбираться хост, путем конфигурирования соответствующей политики на порт группе, куда подключен аплинк Edge VM.
Load Balance Source. Позволяет балансировать трафик между Active аплинками. Рекомендована для Edge.
Load Balance Source MAC Address так же производит балансировку между Active аплинками, но на основе MAC хэша. Не сильно рекомендована для Edge.

В списке Temings нашего Uplink Profile как видно из скриншота присутствует [Default Teaming], это как понятно из названия основная политика балансировки, которая применяется для всего исходящего трафика и вдобавок определяет количество TEP интерфейсов на Транспортной Ноде, это зависит от количества активных аплинков в политике и в случае с Edge VM не может быть больше двух (У Bare Metal Edge может быть и больше). Когда вы создаете новый Uplink Profile, [Default Teaming] там уже присутствует и ему можно поменять алгоритм, как на скрине снизу (выделено зеленым).

Но вернемся к нашему Uplink Profile, который мы рассматриваем, тут помимо [Default Teaming] также присутствуют и другие политики с именами (Named Teaming Policy), которые имеют другие алгоритмы. Их можно добавлять и удалять в Teamings. Они могут быть назначены на определенные VLAN based сегменты и только на них (картинка снизу). Overlay сегменты такой настройки не имеют, так как их трафик ходит наружу через TEP интерфейсы а не через аплинки.

Для чего это нужно? Допустим у нас на Edge есть два аплинка. Оба аплинка по [Default Teaming] политике балансируют между собой overlay трафик с двух TEP интерфейсов. Так же у нас подано на Edge два VLAN сегмента (к примеру, VLAN 10 и 20) для связи с двумя BGP пирами. И мы хотим, чтобы трафик VLAN 10 ходил через uplink-1 (который подключен к одной порт группе на ESXi хосте), а трафик VLAN 20 через uplink-2 (подключенный соответственно к другой порт группе). Отлично, мы для каждого VLAN сегмента конфигурируем свою Named Teaming Policy и прописываем в ней режим Failover Order и один active аплинк (для VLAN 10 – uplink-1, для VLAN 20 – uplink-2), standby оставляем пустым.

И в настройках этих сегментов выбираем соответствующую Uplink Teaming Policy. Вот для этого нам и нужны Named Teaming Policy, как на предыдущей картинке. Стоить помнить, что в настройках сегмента NSX, мы сможем выбрать Named Teaming Policy только в случае если в Транспортной Зоне, к которой этот сегмент относится добавлены Транспортные Ноды, у которых в Uplink Profile присутствует нужная Named Teaming Policy.

Итак, разобрались со списком Teamings в Uplink Profile и собственно с ним самим. Вернемся к пятому пункту развертывания Edge Node.

На очереди у нас IP Assigment (TEP). Этот параметр определяет, как будут назначаться IP адреса TEP интерфейса Edge ноды. Нам доступны две опции – Use IP pool (в этом случае адреса будут автоматически присвоены интерфейсам из сконфигурированного заранее пула) либо Static (адреса прописываются вручную). В параметре IP Рool мы как раз указываем с какого пула брать адреса.

Teaming Policy Uplink Mapping. Тут мы производим сопоставление наших аплинков из Teaming Policy (там мы их обозначали как uplink-X и тут у нас фигурируют эти же обозначения) с порт группами на vSwitch или VDS выбранного ранее ESXi хоста. То есть говорим – подключи uplink «такой-то» в «такую-то» порт группу.

На этом все. Мы внесли всю необходимую конфигурацию и можно жать на Finish и ждать пока развертывание закончится и Edge будет добавлен к Management Plane нашего NSX.

В данном примере мы разобрали конфигурацию Edge VM как на схеме ниже.

То есть один N-VDS свитч с двумя TEP интерфейсами и двумя аплинками. Учитывая, что «эдж» будет через свои аплинки гонять как overlay трафик, так и приходящий\исходящий трафик физической сети, можно понять, что будут задействованы несколько VLAN-ов и соответственно не трудно предположить, что подключаемая к Edge порт группа на хосте ESXi будет передавать тэгированые кадры и должна быть в режиме Trunk. Это стандартная рекомендованная конфигурация для небольших сред. Конечно, мы можем пойти другим путем и сконфигурировать на нашем Edge несколько N-VDS свичей, каждый из которых будет выделен под определенный тип трафика. Например, так.

И тогда мы можем каждый аплинк Edge подключить к порт группе в режиме Access, потому что нет смысла прокидывать тэгированые кадры внутрь Edge. Но это не совсем рекомендуемая конфигурация. Мы не будем углубляться в специфику дизайна Edge нод в контексте данной статьи опять же, потому что она имеет другое назначение и ставит целью разобраться с внутренним устройством NSX Edge Node.

Edge Cluster

После того как Edge развернут, он должен быть добавлен в кластер. Теперь поподробнее о Edge Cluster. Это несколько Edge нод (до десяти) собранных в группу для отказоустойчивости и балансировки входящего и выходящего из NSX трафика. Под отказоустойчивостью подразумевается, что если один из «эджей» упадет, то оставшиеся «подхватят» его роль и сетевые службы переживут failower. Подробнее об этом в следующей серии. Под балансировкой нагрузки подразумевается использование ECMP (Ecual Cost Multi Path) между несколькими Edge нодами. Опять же, подробнее б этом в другой раз. Так же без Edge кластера мы не сможем создавать логические роутеры и дружить физическую сеть с виртуальной. Если вкратце, то Edge кластер must have.

Так вот, вернемся к добавлению Edge Node в кластер. Мы идем в System>Nodes>Edge Clusters. В данной вкладке у нас содержаться наши Edge кластера. Естественно, при развертывании инфраструктуры с нуля список будет пуст и нам необходимо создать первый Edge кластер.

В меню создания или изменения Edge Cluster мы просто перетаскиваем свободные Edge ноды в наш кластер. На что можно обратить внимание, так это на Edge Cluster Profile, да снова профили, как их много тут… Да в NSX почти все построено на профилях. Профиль в скрине является дефолтным, но может быть заменен на заранее созданный альтернативный профиль. Профиля Edge кластеров можно найти в System>Profiles>Edge Cluster Profiles. В чистом новом развертывании он тут будет один — nsx-default-edge-high-availability-profile. И на практике его хватает. Edge Cluster Profiles описывает настройки для BFD между нодами в кластере. BFD используется Edge нодами в пределах кластера, что бы определять доступность друг друга.

Данные настройки и таймеры относятся к протоколу BFD, который будет работать между Edge нодами в кластере. По умолчанию BFD сессии работают между участника кластера по Management сети и по Transport сети.

После того как Edge Node добавлен в кластер и кластер содержит хотя бы одну ноду, можно продолжать и переходить к дальнейшей настройке NSX. Рекомендуется, конечно, иметь в кластере минимум две ноды, иначе какой в нем смысл. Ноды в кластере рекомендуется держать с консистентной конфигурацией n-vds и аплинков, а также в одном форм-факторе. Но ничего не мешает вам пренебрегусь данным правилом и нашпиговать кластер разносортными «эджами».

После того как вы развернули Edge и добавили его в Edge Cluster, его настройки можно изменить. Изменить можно параметры, заданные при деплое, на пятом пункте. Для этого достаточно выбрать нужный «эдж» и нажать EDIT во вкладке с Edge нодами, по пути System>Fabric>Nodes>Edge Nodes.

В этой же вкладке, при выборе определенного «эджа» доступно меню ACTION, предоставляющее несколько дополнительных операций с Edge. Из этого списка наиболее востребованными считаю пункты Change Node Settings, где можно изменить настройки SSH и сети управления, а также Enter NSX Maintenance Mode, который переводит Edge в режим обслуживания, снимая с него нагрузку, например, для того что бы вывести его из эксплуатации в дальнейшем.

P.S

На этом статья подходит к концу. Мы рассмотрели что такое NSX Edge, для чего он нужен и из чего состоит. В рамках этой статьи я не стал вдаваться в подробности о опирающихся на Edge сетевых сервисах и маршрутизации, это темы для следующих статей цикла. А на сим я откланяюсь.