Платформа vSphere всегда предоставляла несколько способов использовать несколько сетевых карт (NIC) совместно, но какой из них лучший для vSAN? Давайте рассмотрим ключевые моменты, важные для конфигураций vSAN в сетевой топологии. Этот материал не является исчерпывающим анализом всех возможных вариантов объединения сетевых интерфейсов, а представляет собой справочную информацию для понимания наилучших вариантов использования техники teaming в среде VMware Cloud Foundation (VCF).
Описанные здесь концепции основаны на предыдущих публикациях:
- «vSAN Networking – Сетевые топологии»
- «vSAN Networking – Переподписка сети (Oversubscription)»
- «vSAN Networking – Оптимальное размещение хостов в стойках»
Назначение объединения (Teaming)
Объединение сетевых портов NIC — это конфигурация vSphere, при которой используется более одного сетевого порта для выполнения одной или нескольких задач, таких как трафик ВМ или трафик VMkernel (например, vMotion или vSAN). Teaming позволяет достичь одной или обеих следующих целей:
-
Резервирование: обеспечение отказоустойчивости в случае сбоя сетевого порта на хосте или коммутатора, подключенного к этому порту.
-
Производительность: распределение одного и того же трафика по нескольким соединениям может обеспечить агрегацию полосы пропускания и повысить производительность при нормальной работе.
В этой статье мы сосредоточимся на объединении ради повышения производительности.
Распространённые варианты объединения
Выбор варианта teaming для vSAN зависит от среды и предпочтений, но есть важные компромиссы, особенно актуальные для vSAN. Начиная с vSAN 8 U3, платформа поддерживает один порт VMkernel на хост, помеченный для трафика vSAN. Вот три наиболее распространённые подхода при использовании одного порта VMkernel:
1. Один порт VMkernel для vSAN с конфигурацией Active/Standby
- Используются два и более аплинков (uplinks), один из которых активен, а остальные — в режиме ожидания.
- Это наиболее распространённая и рекомендуемая конфигурация для всех кластеров vSAN.
- Простая, надёжная, идеально подходит для трафика VMkernel (например, vSAN), так как обеспечивает предсказуемый маршрут, что особенно важно в топологиях spine-leaf (Clos).
- Такой подход обеспечивает надежную и стабильную передачу трафика, но не предоставляет агрегации полосы пропускания — трафик проходит только по одному активному интерфейсу.
- Обычно Standby-интерфейс используется для другого типа трафика, например, vMotion, для эффективной загрузки каналов.
2. Один порт VMkernel для vSAN с двумя активными аплинками (uplinks) и балансировкой Load Based Teaming (LBT)
- Используются два и более аплинков в режиме «Route based on physical NIC load».
- Это можно рассматривать как агрегацию на уровне гипервизора.
- Изначально предназначен для VM-портов, а не для трафика VMkernel.
- Преимущества для трафика хранилища невелики, могут вызывать проблемы из-за отсутствия предсказуемости маршрута.
- Несмотря на то, что это конфигурация по умолчанию в VCF, она не рекомендуется для портов VMkernel, помеченных как vSAN.
- В VCF можно вручную изменить эту конфигурацию на Active/Standby без проблем.
3. Один порт VMkernel для vSAN с использованием Link Aggregation (LACP)
- Использует два и более аплинков с расширенным хешированием для балансировки сетевых сессий.
- Может немного повысить пропускную способность, но требует дополнительной настройки на коммутаторах и хосте.
- Эффективность зависит от топологии и может увеличить нагрузку на spine-коммутаторы.
- Используется реже и ограниченно поддерживается в среде VCF.
Версия VCF по умолчанию может использовать Active/Active с LBT для трафика vSAN. Это универсальный режим, поддерживающий различные типы трафика, но неоптимален для VMkernel, особенно для vSAN.
Рекомендуемая конфигурация:
Active/Standby с маршрутизацией на основе виртуального порта (Route based on originating virtual port ID). Это поддерживается в VCF и может быть выбрано при использовании настраиваемого развертывания коммутатора VDS. Подробнее см. в «VMware Cloud Foundation Design Guide».
Можно ли использовать несколько портов VMkernel на хосте для трафика vSAN?
Теоретически да, но только в редком случае, когда пара коммутаторов полностью изолирована (подобно Fibre Channel fabric). Это не рекомендуемый и редко используемый вариант, даже в vSAN 8 U3.
Влияние объединения на spine-leaf-сети
Выбор конфигурации teaming на хостах vSAN может показаться несущественным, но на деле сильно влияет на производительность сети и vSAN. В топологии spine-leaf (Clos), как правило, нет прямой связи между leaf-коммутаторами. При использовании Active/Active LBT половина трафика может пойти через spine, вместо того чтобы оставаться на уровне leaf, что увеличивает задержки и снижает стабильность.
Аналогичная проблема у LACP — он предполагает наличие прямой связи между ToR-коммутаторами. Если её нет, трафик может либо пойти через spine, либо LACP-связь может полностью нарушиться.
На практике в некоторых конфигурациях spine-leaf коммутаторы уровня ToR (Top-of-Rack) соединены между собой через межкоммутаторное соединение, такое как MLAG (Multi-Chassis Link Aggregation) или VLTi (Virtual Link Trunking interconnect). Однако не стоит считать это обязательным или даже желательным в архитектуре spine-leaf, так как такие соединения часто требуют механизмов блокировки, например Spanning Tree (STP).
Стоимость и производительность: нативная скорость соединения против агрегации каналов
Агрегация каналов (link aggregation) может быть полезной для повышения производительности при правильной реализации и в подходящих условиях. Но её преимущества часто переоцениваются или неправильно применяются, что в итоге может приводить к большим затратам. Ниже — четыре аспекта, которые часто упускаются при сравнении link aggregation с использованием более быстрых нативных сетевых соединений.
1. Высокое потребление портов
Агрегация нескольких соединений требует большего количества портов и каналов, что снижает общую портовую ёмкость коммутатора и ограничивает количество возможных хостов в стойке. Это увеличивает расходы на оборудование.
2. Ограниченный прирост производительности
Агрегация каналов, основанная на алгоритмическом балансировании нагрузки (например, LACP), не дает линейного увеличения пропускной способности.
То есть 1+1 не равно 2. Такие механизмы лучше работают при большом количестве параллельных потоков данных, но малоэффективны для отдельных (дискретных) рабочих нагрузок.
3. Ошибочные представления об экономичности
Существует мнение, что старые 10GbE-коммутаторы более экономичны. На деле — это миф.
Более объективный показатель — это пропускная способность коммутатора, измеряемая в Гбит/с или Тбит/с. Хотя сам по себе 10Gb-коммутатор может стоить дешевле, более быстрые модели обеспечивают в 2–10 раз больше пропускной способности, что делает стоимость за 1 Гбит/с ниже. Кроме того, установка более быстрых сетевых адаптеров (NIC) на серверы обычно увеличивает стоимость менее чем на 1%, при этом может дать 2,5–10-кратный прирост производительности.
4. Нереализованные ресурсы
Современные серверы обладают огромными возможностями по процессору, памяти и хранилищу, но не могут раскрыть свой потенциал из-за сетевых ограничений.
Балансировка между вычислительными ресурсами и сетевой пропускной способностью позволяет:
- сократить общее количество серверов;
- снизить капитальные затраты;
- уменьшить занимаемое пространство;
- снизить нагрузку на систему охлаждения;
- уменьшить потребление портов в сети.
Именно по этим причинам VMware рекомендует выбирать более высокие нативные скорости соединения (25Gb или 100Gb), а не полагаться на агрегацию каналов — особенно в случае с 10GbE. Напомним, что когда 10GbE появился 23 года назад, серверные процессоры имели всего одно ядро, а объём оперативной памяти составлял в 20–40 раз меньше, чем сегодня. С учётом того, что 25GbE доступен уже почти десятилетие, актуальность 10GbE для дата-центров практически исчерпана.
Дополнительную информацию о сетевой архитектуре для vSAN можно найти в vSAN Network Design Guide. Для среды VMware Cloud Foundation (VCF) см. документ “Network Design for vSAN for VMware Cloud Foundation”.
Количество uplink-портов на хост
Объединение для повышения производительности и отказоустойчивости обычно предполагает использование нескольких физических сетевых карт (NIC), каждая из которых может иметь 2–4 порта. Сколько всего портов следует иметь на хостах vSAN? Это зависит от следующих факторов:
- Степень рабочих нагрузок: среда с относительно пассивными виртуальными машинами предъявляет гораздо меньшие требования, чем среда с тяжёлыми и ресурсоёмкими приложениями.
- Нативная пропускная способность uplink-соединений: более высокая скорость снижает вероятность конкуренции между сервисами (vMotion, порты ВМ и т.д.), работающими через одни и те же аплинки.
- Используемые сервисы хранения данных: выделение пары портов для хранения (например, vSAN) почти всегда даёт наилучшие результаты — это давно устоявшаяся практика, независимо от хранилища.
- Требования безопасности и изоляции: в некоторых средах может потребоваться, чтобы аплинки, используемые для хранения или других задач, были изолированы от остального трафика.
- Количество портов на ToR-коммутаторах: количество аплинков может быть ограничено самими коммутаторами ToR. Пример: пара ToR-коммутаторов с 2?32 портами даст 64 порта на стойку. Если в стойке размещено максимум 16 хостов по 2U, каждый хост может получить максимум 4 uplink-порта. А если коммутаторы имеют по 48 портов, то на 16 хостов можно выделить по 6 uplink-портов на каждый хост. Меньшее количество хостов в стойке также позволяет увеличить количество портов на один хост.
Рекомендация:
Даже если вы не используете все аплинки на хосте, рекомендуется собирать vSAN ReadyNode с двумя NIC, каждая из которых имеет по 4 uplink-порта. Это позволит без проблем выделить отдельную команду (team) портов только под vSAN, что настоятельно рекомендуется. Такой подход обеспечит гораздо большую гибкость как сейчас, так и в будущем, по сравнению с конфигурацией 2 NIC по 2 порта.
Итог
Выбор оптимального варианта объединения (teaming) и скорости сетевых соединений для ваших хостов vSAN — это важный шаг к тому, чтобы обеспечить максимальную производительность ваших рабочих нагрузок.