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

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

Пароль для 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.

Как настроить и использовать Nutanix SSP

Если вы хотите разобраться как настроить, использовать, и что вообще такое SSP — Nutanix Self-service Portal, то рекомендую вам просмотреть серию из шести статей, написанных в блоге нашего инженера, Магнуса Андерссона: http://vcdx56.com/category/ssp/.
Очень подробно, пошагово, с массой скриншотов рассмотрено как настраивать и использовать SSP. Все настолько детально и подробно, что не требует даже перевода.
SSP — это наш встроенный в Acropolis продукт, позволяющий построить портал самообслуживания для «частного облака» компании на базе AHV и Nutanix. Вы можете создавать лимиты на ресурсы для групп пользователей (которые интегрируются с корпоративным AD/LDAP), создавать заранее подготовленные для развертывания пользователями образы VM, делегировать управление, в общем все то, для чего ранее вам нужно было переходить на VMware и ее vCloud Director, теперь вы это сможете сделать в рамках Acropolis Hypervisor на Nutanix.

«Они снова сделали это» — disk performance в AOS 5.0

Помните, я рассказывал про историю, как мы в 4.6 значительно улучшили производительность работы на том же самом железе, просто обновлением софта.
Так вот, «мы снова сделали это». На скриншотах ниже результаты обновления версии AOS 4.7.3 на AOS 5.0 на тестовой системе. Просто запустили diagnostics.py, обновили систему на 5.0, и снова его запустили.

Вот результат с последней сабверсией линейки 4.7 — 4.7.3 на 4-нодовой демосистеме NX-3000, стоявшей в этот момент на тестировании у пользователя.

А это результат того же diagnostics.py сразу после обновления на 5.0.

Вот так работает software defined. То же железо, та же задача, а производительность Random Read IOPS стала выше на ~25%, Random Write IOPS — на ~30%, просто обновлением ПО, которое вы получаете бесплатно, пока система находится на поддержке.

Nutanix CE — уже 5.0!

Всякий раз, когда я рассказывал где-нибудь про CE, пользователи пеняли мне на медленное обновление CE относительно «коммерческого Nutanix», что, мол, новая версия «большого» уже вышла, а CE обновляется до него месяца через два только.
Так вот, выложенная версия CE на известном вам портале, сейчас УЖЕ 5.0.

Обновляется без проблем из Prism, надо взять пак «upgrade», а не «baremetal install», и обновить прямо на живом CE.

Также обратите внимание, что в ноябре обновился и Hypervisor, то есть сам AHV. Его обновление качается там же, встает только на новый AOS. То есть сперва обновляете AOS CE до последней (codebase 5.0), как на картинке выше, а потом, вторым действием обновляйте Hypervisor. Он тоже обновляется из Prism с помощью offline bundle (tar.gz + json).

Nutanix AOS 5.0 — что нового в мажорном релизе? Ч.1.

Итак, после небольшого перерыва в блоге, вызванного новогодними праздниками, возвращаемся к регулярности. А главное событие у нас — выход «мажорного» релиза Nutanix Acropolis OS — 5.0. Релиз этот был собран еще в конце прошлого года, его «мучили» в QA, и выпустили в релиз в последние дни декабря, так что все же можно сказать, что в прошедшем, 2016 году мы выдали «на гора» три больших релиза: 4.6 весной, 4.7 осенью, и 5.0 в декабре. Все они были большие, но, конечно, замена «первой цифры» в номере версии всегда привлекает много внимания, поэтому остановимся на этом релизе особенно.
Релиз этот во внутренней документации носил внутреннее имя Asterix, следующий, Asterix.1, с некоторыми новыми фичами, подоспеет видимо весной.

Self-Service Portal

Начнем обзор с темы, которая была предметом просьб наших пользователей весь прошедший год. Это — Self-service portal, SSP. Портал — отдельный веб-интерфейс, который позволяет с использованием гипервизора AHV создать своеобразный «Acropolis Cloud Director», то есть отдельный веб-интерфейс для конечного пользователя, на котором он может, без доступа к «большому» Prism, и всем админским функциям его, создавать, модифицировать и разносторонне управлять своими VM в большой инфраструктуре. Представьте, что вы — админ большой виртуальной инфраструктуры с сотнями пользователей, и тысячами их VM. Раньше вам, как админу, приходилось в Prism вручную рулить всем этим стадом, потому что не было возможности дать конечному пользователю простой «трехкнопочный» интерфейс для создания VM из шаблонов и управления ими. Теперь он есть. Пользователь, аутентифицированный в AD, получает доступ через SSP к своему набору VM и пулу ресурсов, и может управлять им самостоятельно, как через своеобразный Cloud Director.

Лично для меня загадка, отчего, при наличии нашего RESTful API, пользователи, в первую очередь сервис-провайдеры, которым нужен этот инструмент, не писали его сами. Объективно, паре программистов со знанием какого-нибудь Python или Go, написать такое — неделя работы максимум, с перекурами, да вдобавок еще и с заточкой под конкретные нужды этого провайдера, тем более, что примеры есть. Однако ж просили постоянно. Просили — получите.
SSP получился довольно богатый возможностями, и еще будет развиваться.
Подробно о его настройке и возможностях смотрите в серии постов вот в этом блоге, например: http://vcdx56.com/category/ssp/

RESTful API 2.0

Раз уж мы затронули тему RESTful API, то стоит сразу сказать, что в этом релизе вышла новая, доработанная и причесанная его версия. Напомню, что почти всем что есть в Nutanix можно управлять не только из GUI PRISM, и не только из командной строки nCLI, но и через наш API.
Если вы разработчик, или хотите разрабатывать какие-то свои сервисы на базе Nutanix, то первая ваша «точка входа» — портал developer.nutanix.com. Там вы найдете документацию, примеры кода на GitHub, и так далее.

Affinity и Anti-Affinity

Эта фича тоже часто спрашивалась пользователями. Вкратце, это правила, с помощью которых можно было определить то, как будут мигрировать во хостам определенные VM. Например, если нам надо, чтобы определенные VM всегда располагались вместе, даже при переезде по хостам, например, если это связанные сервисы, или же определенные VM всегда работали на определенных хостах, на которых есть для них нужные им аппаратные средства, то это VM affinity. Если, напротив, определенные VM никогда не должны оказываться на одном хосте, например по требованиям безопасности или отказоустойчивости, то это — Anti-Affinity. Это было в vSphere. Теперь возможность задать такие правила есть и в AHV.

Acropolis Dynamic Resource Scheduling

Отчасти связанная с предыдущим пунктом тема — Dynamic Resource Scheduling. Тут мы тоже нагнали vSphere, теперь такая фича есть и у нас, пользуйтесь. Теперь, например, при создании VM и размещении ее на хост, или миграции между хостами, будет учитываться степень загрузки этого хоста по памяти, CPU и дискам.

Network Visualization

Появися новый удобный инструмент для визуализации ваших сетевых соединений в кластере. Когда число VM за много сотен, когда хостов и VLAN-ов — десятки, бывает непросто разобраться что с чем и где соединено. Теперь это станет проще.

Несмотря на то, что HCI сегодня в «датацентре 4.0» оставляет «вне себя», отдельно, только Top-of-the-Rack коммутаторы, Nutanix может автоматически собрать информацию о их конфигурациях через LLDP и SNMP, проанализировать и визуализировать топологию сети, и показать ее пользователю в своем интерфейсе. Это существенно сократит для него время на траблшутинг и разбирательство в «сетевой лапше» соединений крупного виртуального датацентра.

Acropolis File Services goes GA

Наш продукт, встроенный в AOS, Acropolis File Services, позволяющий запустить на Nutanix файловый сервис SMB 2.1 дорос до статуса GA, General Available, пригодный в продакшн для всех. Первоначально он разрабатывался как средство, позволяющее на инфраструктуре Nutanix хранить файлы пользователей в больших VDI, но сейчас может использоваться на множестве разных применений, требующих высокопроизводительного распределенного NAS c single namespace. Так, например, всего три ноды кластера Nutanix могут держать на себе до 60 миллионов файлов/директорий.

AFS, напомню, реализован в виде специальной VM, аналогичной CVM, что довольно практично, если пользователю не нужен этот, довольно тяжелый, сервис, он его не устанавливает и не разворачивает, и не тратит на него память и CPU. Нужен — устанавливает VM и использует. Лицензия на AFS включена в лицензионный блок Ultimate, либо может быть приобретена отдельно, на любой сет лицензий, например на Pro.

В AFS теперь поддерживается нативная Async репликация, имеющаяся у Nutanix. Поддерживаются квоты на место для пользователей, а также Access-based Enumeration.

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

Acropolis Block Services

Это, как вы помните, блочная, iSCSI «SDS» на Nutanix. Она также как AFS распределенная, многопутевая, «многоконтроллерная». В новой версии к поддерживаемым ранее OS добавился VMware ESXi (раньше не работал с ABS), это позволяет использовать Nutanix со сторонними хостами, например если клиент по каким-то причинам не хочет отказываться от уже существующих у него хостов ESXi. Это также поможет при миграции и вообще постепенном внедрении Nutanix в большой системе.

Поддерживается CHAP аутентификация, dynamic load balancing, online LUN resize, IP based initiator whitelisting, Flash mode для volume groups.

И много-много других, менее значительных, но все же важных улучшений и новинок.

Nutanix официально объявил о том, что AHV теперь сертифицирован на работу Oracle VM и Oracle Linux с ABS, и поддерживает работу стека SAP Netweaver на AHV.

В Metro Availability появился собственный witness, это VM на «третьей» стороне, контролирующий двух участников синхронной репликации датасторов ESXi, и принимающий решение в случае разрыва репликации, чтобы избежать split brain. Это VM, разворачивающаяся из OVF на каком-то третьем сайте, это может быть, например, сервер в стороннем датацентре, имеющий связь по IP с двумя защищаемыми датацентрами.

Улучшена настройка и работа того, что называлось Flash Pinning. Это возможность закрепить виртуальные диски VM на уровне SSD, и сделать AllFlash для отдельных VM.

Теперь это называется VM Flash Mode.

Появился еще один self-service portal, на это раз для самостоятельного восстановления пользователем своих данных в VM из снэпшота. Раньше это было возможно только админу из PRISM GUI, отчасти это было возможно через Nutanix Guest Tool, а теперь для этого появился отдельный веб-интерфейс.

В статусе Tech Preview поддерживается Citrix Xen Server 7, под VDI инфраструктуры с GPU. Раньше для этого требовался платный vSphere, сейчас GPU у нас работает и под бесплатным Xen Server.

Расширяется поддержка серверов Cisco UCS, теперь к Cisco UCS С220/240 M4 (рэковым) добавились Cisco UCS B200-M4 (блейд). Там есть некоторая засада, связанная с тем, что в blade-сервера можно поставить только 2 диска. Это означает, во-первых, что требуется storage-node на базе UCS C240-M4SX, и, во-вторых, так как диски в blade будут SSD, это делает систему all-flash (как вы помните, мы не умеем пока смешивать all-flash и hybrid в одном кластере).
В общем получается что-то такое:

Появилась разнообразная What-if и prediction аналитика.

Она помогает ответить на вопросы и промоделировать разнообразные ситуации:

  1. Сколько VM определенного типа потянет этот кластер?
  2. Через месяц мне нужно будет развернуть еще один SQL сервер, хватит ли мне ресурсов на кластере?
  3. Если у меня вырастет нагрузка, то сколько я еще продержусь с имеющейся системой?
  4. Если у меня вот такая вот нагрузка, то если я перенесу ее на отдельный кластер, то какой он должен быть?

Теперь у вас есть куда эти вопросы задать и откуда получить ответ.

Ну и, наконец, чтобы уж чем-то закончить заметным, потому что множество еще более мелких фишечек осталось неосмотренными:
Появилась конфигурация Single Node Backup. То есть, например, вы маленькая компания, эксплуатирующая недорогую NX-1365-G5, и хотите с нее делать репликацию в бэкап. Раньше вам нужно было на резервном сайте только для бэкапов держать еще три ноды, так как это был минимум. Теперь вы можете поставить туда для бэкапов одну ноду. Ведь не секрет, что Nutanix может, без отказоустойчивости, но может работать с одной нодой, как это делает CE. Ну, вот, скорее всего без отказоустойчивости для хранения бэкапа можно обойтись в таких недорогих системах, и теперт у нас поддерживается в продуктиве, на «большом» Nutanix, но только для получателя бэкап-репликации, single node системы.

Ну, на этом, чтобы не раздувать бесконечно этот пост, поставим брейкпойнт, и продолжение с некоторыми любопытными фичами, достойными упоминания, напишу в начале следующей недели.

Обновление для действующих систем поступило на сервера обновления 3 января, можете начинать скачивать и ставить.