Заранее неправильные ответы — 2 или неправильные ответы, которые многие хотят услышать на техническом интервью: Сети
Для лиги лени: до сих пор часть людей считает, что Etherchannel \ LAG — лучшее, что придумали в части сетей.
Введение, для тех кто не знаком с теорией
Рассмотрим простую сеть на 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)
Тут мог быть текст про то, как болезненно все вышесказанное в 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
