Архив метки: nutanix

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

Результаты первого полугода «публичности» в Nutanix

Итак, закончился второй квартал, для нас, как для публичной компании, это время (и обязанность) опубликовать отчеты о проделанной работе. Делать Nutanix это будет теперь регулярно. Вот так выглядит текущее состояние компании сегодня:

17q2 nutanix results

О пользе точной настройки перед проведением 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 в новостях: ГК Ангара

Я всегда стараюсь отлавливать публикации о внедрениях Nutanix, появляющиеся в российской компьютерной прессе. Увы, на десяток внедрений нам удается едва ли одну компанию уговорить опубликовать новость об этом. И вот — один из примеров публичной новости. В компании Ангара работает кластер из 4 нод модели NX-6155.

http://www.cnews.ru/news/line/2017-02-07_angara_priobrela_giperkonvergentnoe_webscale

www.angaratech.ru

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

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

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

Новости саппорта Nutanix, январь.

Я уже рассказывал в октябре о том, как обстоят дела с продуктом и его саппортом, основываясь на нашей внутренней информации на этот счет.
Интересно, как обстоят дела «в динамике», в особенности после выхода новой мажорной версии — 5.0.

Число установленных нод и блоков, числящихся на саппорте, продолжает расти, появились первые системы на v5.0

Насколько надежен релиз 5.0 станет понятно в ближайшие месяцы, но с апреля прошлого года уровень Customer-founded defects (CFD) по всем релизам на системах, стоящих на поддержке линейно снижается с заданного нами порогового уровня 2%, и в декабре упал до 0,6% от инсталлированных систем (всего 410 багов было обнаружено на системах пользователей в процессе эксплуатации, и это очень хороший результат, и лучший за всю историю компании на сегодня).

CFD — это любые дефекты и претензии пользователей, заводимые ими через кейсовую систему, от действительно багов кода, до, например, недочетов в GUI. Все такие defects учитываются как CFD. Нет особого смысла смотреть на абсолютное значение на этом графике, смысл имеет только динамика развития значения CFD.

Как настроить и использовать 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.

Карты 40GBE — на NX-8150-G5

Новость не то чтобы немедленно «в печать», но все же, возможно, кому-то будет интересно. Иногда спрашивают «есть ли жизнь за 10GBE у Nutanix»?
Вот теперь официально — есть, сейчас уже стали доступны карты 40GBE для нашей топовой модели NX-8150-G5, где они более всего нужны, а следующим этапом, возможно — и для других моделей, когда они там понадобятся.

«Они снова сделали это» — 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).