Архив метки: 10G

Как задействовать на ноде Nutanix под трафик VM более одного порта 10G?

Стандартная конфигурация сети ноды Nutanix — это два порта 10G в конфигурации active-passive, при котором один работает и передает данные как межкластерного соединения, так и обеспечивает внешнюю сеть для VM, а второй стоит на случай отказа первого или его коммутатора. И поэтому у многих сисадминов чешутся руки и второй также задействовать для передачи данных, сделав на них какой-нибудь «LACP».
Это возможно. Но прежде чем мы пустимся дальше — несколько слов напутствия. Вариант с active-passive выбран нами как вариант по умолчанию не зря. Наш опыт конфигуирования систем Nutanix показывает, что для подавляющего большинства систем один хост не исчерпывает своим трафиком возможности одного порта 10G, поэтому расширение полосы пропускания в неиспользуемой части ее не увеличит быстродействие вашей системы. К тому же любой сетевик скажет вам, что active-passive это наименее проблемная конфигурация с точки зрения глюков, и самая простая в настройке. А раз так — то зачем нам приключения?
Но если так оказалось, что вы в самом деле уперлись на вашей системе Nutanix в трафик порта (такое может случиться с высоконагруженными системами производительного семейства NX-8000, например), то одним из вариантов будет задействовать два (или даже больше) порта для одновременной передачи данных по ним.
И вот как это возможно.

Первый, приходящий в голову способ будет у вас, я думаю, задействовать LACP. Это возможно, и прежде всего для этого надо переключить значение bond_mode на OpenvSwitch в Acropolis для OVS-бонда с active-passive на balance-tcp.
Однако это, хотя и позволит нам задействовать LACP, не решит проблему с одной высоконагруженной VM. Дело в том, что такая VM, обладая всего одним source IP, не сможет в случае балансировки LACP задействовать более одного порта, так как балансировка в этом режиме идет по парам source-target IP. Начав передавать трафик по одному интерфейсу, она и будет продолжать по нему передавать, даже в случае, если объем трафика превысит его полосу пропускания. Другая VM, с другим source IP пакета, конечно, сможет использовать для своего трафика второй eth, но только таким образом.

Чтобы избежать такой ситуации, мы попробуем другой режим балансировки, в OVS он называется balance-slb.
Вот как его включить.

Допустим, у нас конфигурация сетевого бонда на ноде вот такого типа:

Здесь, как вы видите, оба порта 10G объединены в сетевой бонд с именем bond0 и включены в бридж по имени br0.

Команда:
hostssh ovs-appctl bond/show bond0
покажет нам конфигурацию OVS на всех хостах кластера. Выглядит это примерно так:

Как вы видите, значение bond-mode у нас всюду active-backup.

Дадим команду:
hostssh ovs-vsctl set port bond0 bond_mode=balance-slb

и она переключит нам режимы бондов с именем bond0 для ВСЕХ хостов на balance-slb

[Если вам необходимо сделать это только для одного конкретного хоста, то тогда из консоли CVM этого хоста дайте команду:

ssh root@192.168.5.1 ovs-vsctl set port bond0 bond_mode=balance-slb]

В результате вы получите такое:

Теперь действующий режим бонда стал balance-slb.

Обратите внимание на обведенное зеленой рамкой. Это указывает время перебалансировки портов. Значение по умолчанию для перебалансировки — 10 секунд, но Nutanix рекомендует устанавливать значение перебалансировки на 60 секунд, чтобы минимизировать «скачки» VM и ее трафика с порта на порт.

Команда:
hostssh ovs-vsctl set port bond0 other_config:bond-rebalance-interval=60000
установит это значение.

Данный метод работает для AHV 20160925.43 и AOS 5.0.2

Больше про балансировку и особенности работы сети в AHV — в статье: https://next.nutanix.com/t5/Nutanix-Connect-Blog/Network-Load-Balancing-with-Acropolis-Hypervisor/ba-p/6463

Чем отличается SAN СХД от Nutanix?

После публикации о том, что в самой старшей модели, NX-8150, официально появилась поддержка 40GbE, стали часто задавать вопрос: «А почему нельзя заказать 40GbE и для остальных нод?» И для ответа надо немного более подробно рассказать о том, как именно работает устройство распределенного кластера Nutanix с точки зрения хранения данных, и почему нам не настолько важны «толстые» интерфейсы, особенно на не супермощных нодах-серверах.

Представим себе условную инфраструктуру, состоящую из 6 серверов, и SAN СХД. Допустим, для простоты иллюстрации, что на каждом из шести серверов работает прикладная задача, генерирующая около 2000 IOPS дискового трафика. Все эти серверы включены в SAN, и туда же включена и СХД.

Как мы видим на рисунке выше, это будет означать, что для обеспечения этих 2000 IOPS на каждом сервере, наша СХД будет должна обслужить и выдать 12 тысяч IOPS дискового трафика (без учета RAID penalty!). И чем больше будет становиться подключенных серверов, тем выше будет на нее нагрузка. Для такой СХД разумеется потребуется достаточно «толстый» интерфейс, иначе однажды серверы не смогут «протолкнуть» с СХД необходимый им трафик. В конечном счете производительность серверов будет определяться производительностью интерфейса к СХД и производительностью самой СХД, нагрузка на которую будет расти линейно увеличанию серверов или с ростом дискового трафика задач.

Другая ситуация в случае распределенного кластера хранения на Nutanix.
Представим такую же точно ситуацию, 6 серверов-нод, на каждом по 2000 IOPS. В отличие от «классической» SAN-инфраструктуры, у Nutanix нет единой консолидированной СХД, пространство хранения локально для каждой задачи, плюс каждая нода кластера хранит какую-то часть избыточных блоков. Избыточные блоки пересылаются на другие ноды с помощью канала 10GbE. Но этот канал не используется для доступа к дисковым данным у этого нода-сервера!

Каждый локальный диск отдает свои 2000 IOPS, что для современных SSD, совсем немного, и, при необходимости, может отдать и больше. Причем при увеличении инфраструктуры и добавлении еще серверов-нод, перегрузки какого-то отдельного компонента трафиком не возникает.
Вот здесь и кроется основная особенность распределенного хранилища Nutanix, вот почему нам не нужны на любой ноде сверхтолстые интерфейсы. Мы просто не гоняем по ним (весь) трафик. Да, бывают ситуации, когда толстый интерфейс нужен. Но это означает, не только то, что нода сама по себе высокопроизводительная, но и что задача на ней способна такой канал загрузить (прежде всего извне).

Давайте рассмотрим два крайних случая использования распределенного хранилища на шести нодах, по 2000 IOPS каждая: 100% чтение и 100% запись.
При 100% чтении все блоки данных будут читаться с локального хранилища, и межнодового трафика не будет практически совсем. Каждая нода дает 2000 IOPS и все.
Теперь наихудший с точки зрения межнодового трафика случай, 100% запись. При этом, как вы помните, каждый блок пишется локально, плюс, для избыточности, каждый этот блок записывается рандомно в одной или двух копиях, на одну или две ноды.

При этом вариант каждая нода пишет 2000 IOPS своего трафика, плюс 1/5 или 2/5 (в зависимости от RF=2 или RF=3) от этого трафика операций записи «чужих» блоков с пяти оставшихся нодов. В нашем случае это 2000+400 или +800 IOPS. То есть даже в наихудшем случае 100% рандомной записи, дисковый трафик на каждой ноде кластера не превысит 2400 или 2800 IOPS. Причем, отметьте, при увеличении числа нодов, эта «прибавка» будет падать, так как она будет размазана на все большее число нодов равномерно.
В реальной жизни, где объем трафика записи обычно ниже объема трафика чтения, значение прибавки в «1/5» в данном случае будет даже меньше.

Как совершенно справедливо заметил в комментариях один из читателей, написанный выше расчет относится к варианту, когда из 6 нод только одна делает 100% write, а остальные — read. В случае же, когда ВСЕ ноды делают 100% write (для простоты расчета возьмем, что все ноды делают равное число операций ввода-вывода), то наихудший случай даст нам на ноде 2x local IOPS. 2000 своих, плюс пять оставшихся нод пришлют нам на запись по одной пятой своих копий блоков, итого 4000 IOPS для RF=2 и 6000 для RF=3.

Вот почему ноды Nutanix, хотя и могут использовать новые «толстые» интерфейсы, чаще всего не нуждаются в них.

Практический пример?
Воспользуемся нашей демо-системой на demo.nutanix.com
Вот как выглядит ее загрузка на дашборде:

Как видите, 70 тысяч дисковых IOPS-ов на 4 нодах и 22 VM
Посмотрим, что делается при этом на сетевых портах нод и коммутаторе. Воспользуемся нашей новой фичей, Network Visualization:
Вот выше пример на одной ноде (на остальных трех ситуация аналогичная, трафикогенерирующие VM разбросаны по ним равномерно). Три-шесть мегаБАЙТА в секунду даже в пике!

А вот — статистика с порта коммутатора, соединяющего ноды вместе в кластер. Тоже семечки для 10GbE коммутатора, меньше миллиона пакетов в пике на порт.

Вот такие вот причины, почему Nutanix не требуется использовать суперинтерфейсы для получения его огромной производительности.

UPD: Поправки, на которые обратил мое внимание в комментариях к посту коллега Nickolay.