Для лиги лени: до сих пор часть людей считает, что Etherchannel \ LAG – лучшее, что придумали в части сетей.
Часть 0. Найм и HR 2024 — чего нового
Заранее неправильные ответы - 1 или проходим первого босса найма – HR
Заранее неправильные ответы - 2 или неправильные ответы, которые многие хотят услышать на техническом интервью: Сети.
(план) Заранее неправильные ответы - 3 или неправильные ответы, которые многие хотят услышать на техническом интервью: SDLC / Devops.
Введение, для тех кто не знаком с теорией
Рассмотрим простую сеть на ip v4 – Клиент (сервер, рабочая станция) = коммутатор1 = коммутатор2 = шлюз. Клиент изначально не знает MAC адрес шлюза, и рассылает сообщение "Всем всем всем, кто тут c ip шлюза". Коммутатор 1 тоже изначально не знает, кто у него где, и пересылает это сообщение во все порты, кроме исходного. Коммутатор 2 выполняет аналогичную операцию, шлюз отвечает, дальше уже не так интересно.
Но что будет, если мы выдернем провод между коммутаторами? Очевидно, коммутатор 1 не сможет связаться с коммутатором 2, НЕ РАБОТАЕТ.
Давайте поставим два провода! Порт 1 коммутатора 1 > в коммутатор 2 порт 1 , 2>2. Что будет? Коммутатор 1 отправит пакет в коммутатор 2 через провод 1.1 >1.2, коммутатор 2 отправит пакет в свой порт 2.2 – коммутатор 1, не ожидая такой подлости, примет пакет в 2.2 и сделает как предписано – отправит широковещательный пакет вне своей MAC таблицы во все порты, кроме того откуда он пришел .И поехали, кошки пакеты размножаются умножением, все лежит, бухгалтерия не может открыть 1с. Сетевой шторм и кольцо, обычное дело, 1-2 занятие на первом курсе по сетям.
Как быть? Сначала, давно, появился протокол STP (и его развитие, вместе с настройками про storm-control и прочие bpdu guard) – когда второй (третий, и далее) порт в таких ситуациях просто блокируется, все счастливы. Но в работе все равно один провод, хочется два. Появляется Etherchannel \ LAG – когда 2 (3,4 и до 8) портов обьединяются в один виртуальный, внутри магия балансировки, 2 общих протокола IEEE 802.3ad – статический и LACP, и десяток вендорских. Все описано, как-то понятно. Пока мы не начинаем рассуждать про плюсы и минусы Stack и Mlag – статья 1 , статья 2 и дальше начинаются IP-фабрики.
Итог: в общем случае сетей - Etherchannel \ LAG это хорошо, это надежно. Даже если выстрелит в ногу, вторая нога останется.
Как быть с клиентами ?
Ведь у клиентов тоже в начальной ситуации 1 провод, вырвали его, или отказал порт – и все, связи нет, можно же два использовать? Можно, когда-то давно, в времена Windows server 2003, так и работало. Ставим драйвер +софт от вендора, два физических порта собираются в виртуальный, и даже работает какая-никакая балансировка для нескольких потоков данных. Хорошо, надежно.
Все меняется с приходом виртуализации и не только
Уже в Windows 2012R2, может и раньше, в 2012 (интересно, а когда в Linux ? не искал) есть три варианта подключения и балансировки - Static Teaming, Switch Independent (SET), LACP
Как легко увидеть, появляется режим Switch Independent (SET) – когда вся настройка выполняется на стороне сервера, и балансировка идет там же. LAG на стороне коммутатор не всегда нужен, можно reddit почитать или Dell
Плюсы и минусы известны – LAG как бы сам делает вид, что следит за тем, что оба порта работают (что работает в реальных ситуациях ой как не всегда), SET требует следить за состоянием портов. Мониторинг нужен и там и там, в любом случае надо отслеживать и битые пакеты, да и за уровнями сигнал-шум и трафик-ошибки нужно следить. И то, иногда Cisco может устроить шоу с Nexus и необходимостью звать на помощь TAC, и в иных местах между Cisco Nexus – кто угодно – можно вот такой ложкой поесть понятно чего.
С добавлением виртуализации появляется виртуальный коммутатор – для MS это описано в Hyper-V Cluster NIC Teaming
У VMware Broadcom – в документации по standard и distributed virtual switch.
В чем разница между обычным (физическим) коммутатором и виртуальным?
В первую очередь как раз том, что описано выше – в обычном случае на виртуальном коммутаторе MS и Broadcom нельзя устроить кольцо. Коммутатор не пересылает широковещательные пакеты между физическими сетевыми картами. Про это прямо написано в документации Broadcom - Typically VMware vSwitches (Standard and Distributed) don't form loops by default as there is no way to join two virtual switches together at layer 2 of the OSI layer. Understanding the BPDU Filter feature in vSphere (2047822)
и поэтому STP надо отключать - STP may cause temporary loss of network connectivity when a failover or failback event occurs (1003804)
Для MS то же самое описано в Network Recommendations for a Hyper-V Cluster in Windows Server 2012 , Windows Server 2016: NIC Teaming Functionality , Step-by-Step – Deploy Switch Embedded Teaming (SET)
Для Linux тоже есть вариации, описанные у RH - Chapter 3. Configuring network bonding
Но как же тогда обеспечить отказоустойчивость и балансировку, ведь все что сказано выше – применительно к LAG – такое хорошее, описанное? Давайте делать LAG!
Пропустим тот момент, что LACP протокол работает только при покупке vDS, а при Virtual Standard Switch (vSS) – только статика (1001938) . Но зачем LACP делать вообще? Стандартный NIC Teaming и так позволяет делать и балансировку, и Active-passive, и Active-standby. Teaming and Failover Policy. Про плюсы и минусы обеих решений есть минимум две полноценные статьи – раз, два.
Приведу выдержку из перевода первой:
Load Balance Teaming (LBT): позволяет выполнять перебалансировку трафика по нагрузке по физическим портам. LACP – не позволяет.
LACP: сложнее настроить (больше операций) и на хосте, и на коммутаторах.
LACP: сложнее мониторить на стороне ESXi
В игру вступают RDMA, SDS и менеджмент
RDMA - Remote direct memory access)
SDS - software-defined storage
RDMA на Windows дает выигрыш по скорости в 20-30% (To RDMA, or not to RDMA – that is the question) , для SDS vSAN дает и выигрыш по скорости, и снижение нагрузки на процессор
но:
RDMA НЕ работает с LAG и, кроме того:
The Basics of Remote Direct Memory Access (RDMA) in vSphere: PVRDMA does not support NIC teaming. The HCA must be the only uplink on the vSphere (Distributed) Switch
vSAN with RDMA does not support LACP or IP-hash-based NIC teaming. vSAN with RDMA does support NIC failover.
Agents: If Link Aggregation Control Protocol (LACP) is used on an ESXi host that is a member of a vSAN cluster, don’t restart ESXi management agents with the services.sh command.
То есть, или LAG и отсутствие балансировки и сложности в администрировании, или RDMA, балансировка (в том числе в vSAN в режиме Air gap) и чуть чуть меньше проблем.
Для MS Windows надо читать Manage SMB Multichannel и SMB Direct с использование SET – то есть без LAG: You can team RDMA-capable network adapters using Switch Embedded Teaming (SET) starting with Windows Server 2016.
Ограничения
У RDMA есть свои лимиты, и в первую очередь это дистанция. Причем, не в том понимании, что RDMA (RoCE) не может быть передан на сотню километров – может, инфа сотка
Но из-за потери скорости (без оптимизации) и при возможных потерях пакетах на таких дистанциях – может, но не всегда нужен.
И для растянутого кластера vSAN – RDMA не работает –
vSAN over RDMA is not supported stretched or two-node vSAN clusters.
vSAN cluster sizes are limited to 32 hosts
vSAN cluster must not be running the vSAN iSCSI services
vSAN cluster must not be running in a stretched cluster configuration
vSAN cluster must be using RDMA over Layer 2. RDMA over Layer 3 is not supported.
vSAN cluster running vSAN over RDMA is not supported with disaggregated vSAN topologies, such as vSAN Max.
vSAN cluster must not be using a teaming policy based on IP Hash or any active/active connection where sessions are balanced across two or more uplinks.
Stretched Clusters Network Design v7
What Are vSAN Stretched Clusters v8
vSAN Frequently Asked Questions (FAQ)
Примечание: по пункту vSAN cluster must not be running the vSAN iSCSI services не понятно написано - в vSAN Frequently Asked Questions (FAQ) эта строчка есть, в Characteristics of vSAN iSCSI Network 8 - не вижу.
Тут мог быть текст про то, как болезненно все вышесказанное в Linux и поддержку вендора, и отдельно про то, что упоротозаместители могут и нарушать первую заповедь – да не сотвори петлю внутри виртуального свича, но и так уже 5 страниц. Если же еще попробовать нырять в сети с VXlan и организацию сетей в контейнерах - будет еще 20 страниц
Итого
Несмотря на все вышесказанное, зачастую единственно правильный ответ на вопрос «как нам сделать отказоустойчивый кластер чего угодно» - соберем LAG! Все, что выше – новомодная ересь, 640k 10G должно хватить всем, на 25/100 у нас ни денег ни специалистов.
Домашнее задание
Pros and Cons of Air Gap Network Configurations with vSAN
NFS Multi-Connections in vSphere 8.0 Update 1
