Архив рубрики: techtalk

Как это работает?

AHV Turbo Mode — первые результаты

Интересные результаты показали наши разработчики для AHV Turbo Mode (AKA Frodo).

Напомню, AHV Turbo Mode, как внутренний project codename называвшийся Frodo, это новый способ работать с дисковым хранилищем в Nutanix AHV, оптимизация пути передачи данных и более высокая параллельность обработки очередей, которые теперь могут обрабатываться большим числом ядер CPU на хост-машине, чем было до того в vanilla QEMU. Он появился впервые в AOS 5.5, вышедшем на прошлой неделе.
Это улучшение особенно важно для AllFlash и NVMe машин, выходящих у нас в свет следующем году.
Как вы видите из графика, на обычной VM рост производительности ввода-вывода при увеличении числа параллельных операций практически останавливается в районе 30-40 Outstanding Requests, при этом с использованием AHV Turbo Mode он продолжает свой рост вплоть до 128. Это отличный потенциал для роста производительности для новых AllFlash, так как проявляется эта новая возможность прежде всего на них.

Обновление платформы: G6!

Тем временем подоспели новости, о которых я начну рассказывать с этой недели.
Как вы уже, наверное, слышали, к семье наших OEM-ов (DellEMC и Lenovo) добавляется Fujitsu. Пока это только анонс, и из трех заявленных моделей у Fujitsu доступна в первом квартале будет только одна.

Так что, когда они раскачаются, тогда я об этом и напишу подробно, а пока достаточно этого короткого анонса, потому что дальше — о нас самих.

Да, действительно, Nutanix постепенно идет в направлении software-only модели, но это будет не в следующем году точно. В следующем году нас ждет обновление линейки платформ native Nutanix, связанной с плановым обновлением процессорного ряда Intel, и, соответственно, обновлением наших ODM-партнеров, Supermicro.
Заверешен цикл тестирования, и мы официально объявляем выход поколения Generation 6, на процессорах Intel Skylake.

Вот, что будет в деталях нового и интересного.

Платформы NX-3060 первыми получат обновление до G6.
Мы будеи использовать шасси Supermicro SYS-2029BT-HNC0R-NI22 с материнской платой BigTwin X11DPT-B, на логике Intel C621 PCH (Lewisburg) и процессорами Intel Xeon Silver 4108, 4114 , 4116 и Intel Xeon Gold 5120 ,6130, 6138, 6126. Как вы должно быть знаете, Intel в очередной раз перелопатил номенклатуру процессоров Xeon, и теперь процессоры у них называются «металлами» по семейству и номерами по моделям в семействе. Bronze мы использовать, понятное дело, не будем, а Silver и Gold семейства, используемые в следующем поколении платформ, перечислены выше.
Повышается тактовая частота памяти DDR4, с 2400 до 2666 MHz. Максимальный объем памяти — 768GB на ноду G6 (все конфигурации по памяти — сбалансированные). Пока не поддерживаются 64GB DDR4 DIMM, из-за ограничений платформы по тепловыделению, поэтому максимальная емкость памяти на ноду ограничена на 768GB.

Сразу со старта заявлена поддержка NVMe (на 1.6TB). Разумеется остались SSD (960GB, 1.92TB, 3.84TB) и HDD (2TB только).

Из интересного «под капотом»: в Supermicro (и мы, следовательно, тоже), отказываются от использования SATADOM, SATA Disk-on-Module, внутреннего flash-диска на SATA-шине, с которого у нас грузится baremetal hypervisor. С ним было одно время достаточно проблем, связанных с производительностью и ресурсом. Например, проблемы вызывала Windows Server 2012R2, поставленная на него как хост Hyper-V. Оказалось, она непрерывно пишет неотключаемые логи, и это приводило к скорому выходу из строя SATADOM flash той модели, которую мы использовали примерно пару лет назад. Тогда это потребовало множества гарантийных замен на работающих системах у пользователя. Теперь эта проблема кардинально решена, платформа переходит на пару устройств 240GB SATA 2280FF M.2 в software RAID-1. Декларируется 1 DWPD, так что, как мы ожидаем, названные выше проблемы ушли в прошлое.

Расширяется номенклатура сетевых карт. К уже известным 2port 10G SFP+, 4port 10G SFP+, 2port 10GBaseT добавятся 2port 40G QSFP28 и 2port 25G SFP+, причем до двух карт на ноду! Новый конструктив корпуса дает возможность поставить ДВЕ карты на каждой ноде, и это не считая пары 10GbaseT, встроенных в платформу (на SIOM, Supermicro IO Module).
Так что 40G и 25G будут доступны теперь и на 3000-series. Это вызвано растущей производительностью ноды. Если раньше на midrange-нодах использование таких производительных интерфейсов выглядело сомнительным, так как чтобы загрузить такую полосу ввода-вывода нужна очень солидная производительность CPU и памяти, то теперь, с новыми CPU и, в особенности, с NVMe, это уже становится важным и необходимым.

Энергопотребление 4 нод под нагрузкой — в районе 1700W, рассчитанный worst case — 2080W, среднее тепловыделение 4 нод — 5800 BTU/h, блоки питания при «нашем» вольтаже поддерживают полную redundancy (блок из 4 нод продолжает работу при выходе из строя одного PSU).

Доступность всех перечисленных фич ожидается к концу декабря.

AHV Turbo mode

Наш сотрудник, Josh Odgers, ведущий свой блог тут: http://www.joshodgers.com, недавно опубликовал интересное описание того, как работает AHV Turbo, особый режим работы ввода-вывода, сокращающий путь от UVM (User VM) к CVM (Controller VM) и непосредственно к «железу» через гипервизор.
Как вы уже знаете, CVM у нас находится в User Space гипервизора, и, в отличие от схемы ввод-вывода, например, VSAN, где он осуществляется в Kernel Space. И VMware это все еще позиционирует как большое преимущество, мотивируя это тем, что, дескать, работа в kernel-space более эффективна и более производительна. С одной стороны это так, конечно. С другой, как показывает Nutanix, разница в производительности в данном случае не так значительна, а, между тем, работа в user-space имеет множество преимуществ с точки зрения защищенности и изолированности, безопасности, простоты обновлений и гипервизоро-независимости. Хорошо спроектированная архитектура для user-space практически нивелирует преимущества в производительности для kernel-space, и при этом у нас еще не закончились фичи, позволяющие нам оптимизировать и улучшать процесс ввода-вывода, в особенности если ниже, под CVM и пользовательскими VM лежит наш собственный гипервизор.
Вот, например, как работает режим AHV Turbo, появившийся в новых версиях AHV, и предназначенный, в первую очередь, для оптимизации работы с новыми устройствами хранения, такими как NVMe и 3D Xpoint. В нем Nutanix сократил и спрямил Data IO path между пользовательской VM и «железом» серверной платформы.

На рисунке ниже показывается, как ввод-вывод пользовательской VM (UVM) проходит через подсистему Frodo (служебное имя для Turbo Mode) которая работает в User Space (не в kernel) и затем идет в Stargate (подсистема ввода-вывода) в Controller VM).

Еще одним преимуществом AHV и Turbo mode является то, что администратору не требуется конфигурировать множество адаптеров PVSCSI и распределять виртуальные диски по контроллерам. При добавлении виртуального диска в VM под AHV, многопоточная и много-очередная архитектура используется автоматически, что повышает производительность ввода-вывода как на запись, так и на чтение.
Много-очередной поток ввода-вывода обслуживается с помощью множественных тредов модуля frodo (Turbo mode) и проходит через stargate.

Как показано на рисунке выше, Nutanix с Turbo mode устраняет узкие места, характерные для традиционных гипервизоров, например — причину, по которой VMFS datastore требуется использовать VAAI Atomic Test and Set (ATS) для устранения проблем с большим количеством VM на датасторе (например более 25). Напомню, в классическом VMFS существует ряд операций, которые блокируют датастор целиком, например это любые изменения в метаданных датастора, вызываемые, например, созданием или включением VM, созданием ее снэпшота, запуск Storage vMotion, и так далее. В случае таких операций, без использования VAAI ATS, будет на определенное время, при выполнении этих операций, блокирован ввод-вывод на датастор целиком, для ВСЕХ VM на нем находящихся. Это не слишком страшно, если у вас всего несколько VM на датасторе, и является существенной проблемой когда этих VM на датасторе много, не только потому, что это «тормозит» гораздо больше приложений, но и потому, что при большом количестве VM операции, связанные с блокировкой VMFS, возникают чаще. В случае AHV при использовании Turbo mode, не только каждый vdisk будет иметь свою собственную очередь команд (вместо одной на датастор или контейнер в «классике») но также добавляется и очередь per-vcpu на уровне виртуальных контроллеров.

Вот какие результаты работы AHV Turbo приводит у себя в блоге Джош:

На четырехнодовом блоке четырехлетней давности NX-3450, стоящей в лабе, с двумя SATA SSD на ноду и с отключенным memory read cache, результаты от включения AHV Turbo:
На 25% ниже загрузка CPU на задаче sequential write, при том, что значение производительности практически не изменилось (2929 MBps vs 2964 MBps)
На 27.5% выше sequential read performance (9512 MBps vs 7207 MBps)
На 62.52% увеличилась производительность random read IOPS (510 121 vs 261 265)
На 33.75% увеличилась производительность random write IOPS (336 326 vs 239 193)

И еще из интересного оттуда же. У нас есть клиент, у которого эксплуатируется под Acropolis Hypervisor 1750 нод!

Software-only Nutanix

В связи с тем, что некоторое время назад Nutanix начал шире продавать себя как Software-only вариант, например на платформы HPE ProLiant и Cisco UCS, я решил собрать краткий пост ответов на незаданные (пока) вопросы пользователей, который, я надеюсь, ответит и развеет ряд моментов непонимания для чего это все и зачем, а также насколько это подходит вам.

Практически каждый первый мой собеседник, узнав, что Nutanix это software company и мы продаем наши NX-appliances, взяв готовую x86 платформу, задает вопрос: «А можно купить Nutanix просто как софт?».
Есть короткий ответ на этот вопрос теперь: «Да, можно»
Но, как почти всегда, короткий ответ верен, но неполон. И требует более развернутого пояснения.
А начать стоит с того, что, как это часто бывает, человек, задавая этот вопрос, хочет спросить что-то совсем другое, но, по каким-то причинам, свой вопрос изменяет. На самом деле этот человек хочет спросить, также более длинно:
«Если я куплю только софт, и не буду покупать «железо», то обойдется ли мне это дешевле, смогу ли я тут сэкономить, если поставлю ваш Нутаникс на пыльный Proliant G5, который мы уже хотели совсем выкинуть, но все жалко на него потраченных в 2003-м году денег? Все же знают, что денег стоит только железо, а софт он или совсем дешевый, или бесплатный, на крайняк можно просто его скачать с торрентов, и значит должно быть круто дешевле, да?»
Вот тут, как вы понимаете, ответ на вопрос несколько удлиняется. :)

Во-первых, и прежде всего, стоит остановиться и ответить на вопрос, какую долю от целиком решения составляет в случае Nutanix стоимость его софта. К сожалению еще очень многие люди воспринимают софт как нечто «условно бесплатное», и, например, Microsoft в массовом рынке им в этом часто подыгрывает. Ну, сами судите, мы покупаем ноутбук за 1000 долларов, и на нем Windows, стоимостью 2500 рублей. Очевидно, что если нам нужен только Windows, то избавившись от ноутбука за 1000 долларов, мы круто сэкономим. Да и вообще, мы походим по базару и найдем не макбук, а что-нибудь попроще, а то может купим его с рук, за полцены, на ебэе. А то знаем мы вас, заряжаете, поди, три цены.

Ну, пойдем с конца. Утопией было бы думать, что вы сможете купить ту же платформу Supermicro дешевле, чем мы покупаем ее в Nutanix в Америке, с нашими объемами, долгосрочными контрактами, отношениями с ODM, и положенными всему этому скидками. Да, Nutanix, в целом, как весь appliance — недешев. Но стоимость железа в стоимости решения совсем не так велика, как представляется. Скорее наоборот. В определенных конфигурациях, например, в младших моделях, мы практически отдаем «железо» нашего appliance даром, подавляющую долю цены решения составляет стоимость софта и его поддержки.

То есть, отказавшись от нашего «железа» в составе appliance вы, потенциально, получаете некую (эфемерную, на мой взгляд) «бОльшую гибкость» (допустить ваших собственных ошибок при конфигурировании платформы, например), но, вместе с этим, вполне конкретную проблему с поддержкой, совместимостью всех компонентов решения, с его lifecycle, с уровнем надежности, и так далее. Стоит ли это того? На мой взгляд — нет. Тем не менее, мы, на определенных условиях, пошли навстречу пользователям, и теперь у нас появилась возможность продавать Nutanix как софт на строго определенные платформы в строго определенных конфигурациях. И это будет поддерживаться нашей техподдержкой.

  • У нас появились в партнерском прайсе строчки вида SW-PRO-PRD-3YR. Это и есть Software-only Nutanix.
  • Эта строчка одна на любую платформу.
  • Виды этих строчек – тип лицензии (PRO, ULT), а также вид и длительность поддержки.
  • Сам софт независим от платформы (то есть его можно ставить на UCS, на ProLiant, и так далее, на любую поддерживаемую платформу). Лишь бы платформа была поддерживаемой и соответствовала нашему Compatibility List.
  • Платформа должна в ТОЧНОСТИ соответствовать описанной в HFCL – Hardware AND Firmware Compatibility List. Любые отклонения вида «ой, а у нас SSD тут не такой, а почти такой, просто другого вендора, но он хорошо работает, это ничо?» не поддерживаются. Обычно это означает, что на имеющееся у вас серверное железо это, по крайней мере в поддерживаемом виде, не поставить. Вряд ли оно в точности соответствует нашему HFCL. Как правило это означает, что вы покупаете у вашего поставщика платформу, заказанную в точности в соответствии с HFCL, а потом у партнера Nutanix на него лицензию Software-only Nutanix, и с нашей помощью все это собираете и ставите.
  • Стоимость лицензии не зависит от стоимости платформы (то есть не как у Nutanix appliance сейчас, если это NX-1000, то стоимость лицензии существенно (в разы) ниже, чем, например, у NX-8000, за тот же набор фич), в результате, стоимость лицензии Software-only довольно высока сама по себе, что лишает смысла ставить ее на сравнительно слабые сервера (ну, например, за стоимость SW- можно иногда взять NX-3060, например, ВМЕСТЕ с софтом, плюс еще и железо, получается типа бесплатно). Это делает бессмысленным для пользователя покупку Software-only варианта на сравнительно слабые серверы.
  • Лицензия понодовая. Как и раньше, весь кластер должен иметь один уровень Software license, то есть PRO — то весь PRO. Если ULT — то весь ULT.
  • Лицензия не привязана к платформе, ее можно переносить на другой сервер и даже другую платформу (например год поработало на UCS, и перенесли на ProLiant).
  • Поддержка – это поддержка И обновления. После окончания поддержки перестает оказываться поддержка И предлагаться обновления. Софт продолжает работать так, как работал.
  • «Смеси» (из платформ разных вендоров) в одном кластере не поддерживаются ни с Nutanix, ни с OEM.
  • «Не поддерживаются» означает именно это.

Итак, у нас есть Software-only Nutanix License, спрашивайте у партнеров, но помните про перечисленные выше тонкости и не расчитывайте, что это «ЭсЭмБи», скорее наоборот. Это скорее интересно для крупных компаний и сервис-провайдеров/облачных провайдеров, впрочем, для их объемов мы и раньше продавали Nutanix как софт, просто не особенно это публично афишируя.

Конфигурация сети в Nutanix Acropolis Hypervisor — на русском

В конце апреля мы публиковали перевод на русский документа Nutanix Acropolis Hypervisor best practices, а сегодня я рад представить новый перевод:
Конфигурация сети в Nutanix Acropolis Hypervisor BP-2071 v.1 RUS.

По ссылке вы найдете PDF с подробным описанием того, как конфигурируется и организуется сетевая подсистема в AHV, как настроить балансировку нагрузки по портам, как организовать VLAN-ы, как настроить работу по множественным сетевым портам и виртуальным интерфейсам OpenvSwitch. Конечно, в большинстве случаев вы вполне можете оставить вашу систему в конфигурации по умолчанию, но если у вас есть специальные требования к сетевой подсистеме — этот документ для вас.
Знакомьтесь, если есть замечания по переводу, то можно оставлять в комментариях.

Пароль для admin в новом Nutanix OS 5.1

Я чуть ранее упоминал о нововведении в свежей версии Nutanix OS. Из соображений безопасности мы теперь будем требовать обязательного изменения/установки пароля админа на служебные сервисы Nutanix. Конечно, по-хорошему, доступ к CVM должен быть ограничен VLAN-ом админов, но пользователь ленив, и если есть возможность что-то усложняющее жизнь не делать — он и не сделает. Поэтому теперь рутовый-админский доступ будет закрыт паролем, который пользователь должен будет устанвить сам при запуске системы.
Мы несколько ранее сделали такое для доступа в Prism, но теперь это будет и для CVM тоже. Выглядит это так:

Прежде чем вводить пароль и тыкать кнопку, прочтите и осознайте внимательно примечание, написанное под полем пароля.

Конечно, мне тоже кажется, что со строгостью password policy у нас все же несколько перестарались, сгоряча :)
Тем не менее, теперь будет вот так.
Обратите внимание, что первые пользователи уже столкнулись с несколькими тонкими моментами.
В качестве спецсимволов новые политики не принимают, например, популярные в качестве special characters: ! @ $ /. Дефис подходит.

Пароль админа после введения на одном из нодов, синхронизируется по всему кластеру.

Как задействовать на ноде 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

Nutanix Acropolis Hypervisor best practices — на русском

Мы закончили перевод одного из наших документов серии Best Practices:
Nutanix Acropolis Hypervisor Best Practices (BP-2029) по самой свежей версии AHV, v5.0
Извольте знакомиться и пользоваться в работе.

Nutanix AHV Best Practices BP-2029 v.3 RUS

Nutanix Acropolis AHV BP v3.0 RUS

Чем отличается 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.