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

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

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.

О пользе точной настройки перед проведением performance tests на Nutanix

Немного интересного о том, насколько важно для получения хорошего результата правильно и грамотно конфигурировать систему (а не просто поставить ее потыкав Enter и «Далее»), руководствуясь нашими Best Practices.

Нак коллега из Германии поделился своим опытом:

«Доброе утро. Хочу с вами поделиться результатами тестирования, которые хорошо иллюстрируют важность использования наших best practices.

Я запускал бенчмарк на MSSQL с использованием HammerDB. Использовался AOS 5 на AHV на 3x NX-3175-G4. CPU на 2.6 Ghz (2x 10 core) и каждая нода имела 692 GB RAM. Диски: 2x 1.5 TB SSD и 2x 2TB HDDs.

Все VM были созданы из шаблона Windows 2012 R2 x64 со всеми сежими патчами, VM имела 1 сокет и 8 виртуальных ядер, а также 64GB vRAM.

Я создал VM с SQL Server установленным по умолчанию (просто приняты все значения установки по умолчанию, просто жал «next» всегда), и база была поставлена на виртуальный диск, размером 1TB в контейнере по умолчанию.

Я также создал одну VM с SQL установленным и настроенным в соответствии с нашими best practices. Контейнер имел включенную inline compression, для базы созданы несколько виртуальных дисков, настроены параметры SQL Server, установлены trace flags, large pages, database memory allocation, и так далее.

Затем я установил HammerDB и выполнил транзакционный тест (TPC-C) с 40 пользователями и 254 warehouses, что, в общем, довольно невысокое число последних.

Так выглядел запуск теста на неоптимизированном сервере SQL. Мы получили примерно 90K transactions per minute, и уперлись в CPU.

А это тест на оптимизированной VM с SQL. Мы получили тут более миллиона транзакций в минуту, и все еще не уперлись в CPU.

В обоих случаях, OS и базовая конфигурация VM были идентичны, различалась только конфигурация контейнера, были добавлены дополнительные диски в VM, и были сделаны настройки базы данных. Подсистема хранения не была слишком нагружена, она выдавала всего около 4800 IOs или 290 MB/s.

Мне показалось, что вам будет интересно посмотреть на результаты. Возможно это также будет полезно показать пользователям, если заходит разговор о производительности базы данных на Nutanix.»

Итак, просто за счет более правильной настройки VM для работы в Nutanix, получен двенадцатикратный прирост ее производительности.

Интеграция Nutanix AHV в vRealize Automation 7.x

Интересное видео, показывающее интеграцию гипервизора Nutanix AHV в среду управления vRealize Automation 7.
Это возможно, и сравнительно несложно, используя наш RESTful API, подробнее — в видео:

Кроме этого следует упомянуть, что у нас есть и свой собственный «портал самообслуживания» (SSP, Self-Service Portal), встроенный в Acropolis.