Архив рубрики: обзоры

Обзоры продуктов

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 января, можете начинать скачивать и ставить.

Будни саппорта Nutanix, октябрь

Интересные данные показал наш саппорт.
Я некоторое время назад упоминал, что они в августе рассказали, что из систем, которые подключены в Pulse (нашу систему репортинга и автоматического саппорта) в августе 28% систем уже работало на AHV. Но оставался вопрос, какое число систем саппорт не видит, так как они не в Pulse.
Так вот, по последним сведениям в Pulse включены 43% проданных систем.

В настоящее время на 34% нод установлена наша самая свежая версия — NOS 4.7 (на 32% — предпоследняя, весенняя, 4.6). Суммарно на последней и предпоследней версиях сидит уже 66% нод. Отличный результат.

nos-installed

Величина зарегистрированных саппортом software defects (попросту — багов, CFDs — Customer Found Defects) снижается с марта, хорошо коррелируя с выходом релиза 4.6 GA и в октябре снизилась ниже 1%, до 0,7%. То есть на ~60 000 инсталлированных нодов каких-то проблем с софтом Nutanix встречалось всего 385 штук!
При этом число инсталлированных нодов за год практически удвоилось.

SLA по кейсам уровня P2 (229 штук за месяц), P3 (937) и P4 (218) составил 99%, по кейсам P1 (critical, 46 штук, менее 1 часа реакции) — 98%.

SSD в HPE HC380 могут быть сняты с гарантии при «интенсивном использовании»

Разбираюсь тут с нашими конкурентами в HPE, точнее — с их новой системой HC380, наталкиваюсь в документации на такое:

hpe-hc380-ssd-warranty-issues

Э-э… HPE, вы это всерьез? У вас SSD warranty is subject to maximum usage limitiaions? На втором десятке лет XXI века, у крупнейшего поставщика энтерпрайз-решений? Знает ли об этом ваша мама ваши клиенты, которым вы продаете HC380?

История двухлетнего опыта использования ceph в веб-хостере и полученный опыт.

Интересный пост на Хабре, описывающий опыт веб-хостера FirstVDS в его попытках сделать кластер на ceph, и честное описание всех значительной части проблем, которые они хапнули в процессе. Полезное и душеспасительное чтение для всех, кто рассматривает ceph как enterprise-grade решение.
Вкратце, бегло о lessons learned:

* Процесс «выучивания уроков» занял примерно два года, на сегодняшний день. Первая версия была собрана осенью 2014 года.

* Не все x86 сервера «одинаково полезны». Купленные специально под кластер сервера оказались глючными.

Чтобы опробовать новую архитектуру и избавиться от прежних недостатков, собрали тестовый стенд. И тут выяснилось интересное — специально купленные для сборки первой версии серверы оказались «палёными». Системная шина всех серверов работала медленно. В результате, все устройства, связанные с северным и южным мостами — карты IB, подключенные по PCI-E, диски, память — также работали медленно. Это объясняло большую часть проблем, с которыми мы столкнулись. В качестве пробы взяли несколько свободных нод, на которых обычно запускаем клиентские VDS. По тех. характеристикам они почти ничем не отличались. Собрали и запустили кластер на этих машинах, стали прогонять тесты. Всё летает! … купили новые серверы на базе Xeon 2630 …

* Далекая от оптимальности схема восстановления избыточности в ceph, требующая ручной регулировки.

Кластер справлялся с задачами — при выходе из строя дисков или нод целиком, он продолжал функционировать. Однако, каждая перебалансировка превращала ситуацию в критическую. При добавлении нового диска сглаживали пик нагрузки, используя веса. Вес отвечает за степень использования конкретного физического носителя. Устанавливаем новый диск, ставим вес 0 — диск не используется. После этого увеличиваем вес постепенно, и перебалансировка происходит маленькими порциями. Если же диск выходит из строя, то веса не срабатывают: ~1 Тб реплик надо «размазать» по оставшимся дискам сразу, и Ceph надолго уходит в режим записи данных, загружая диски «пустой» работой.

* Перестроение кластера ceph на ходу вызывает существенную нагрузку на серверы и влияет на нормальную работу приложений

* Для построения в чистом виде гиперконвергентной системы, когда одни и те же сервера являются и узлами хранения и хостами виртуализации, ceph оказался малопригоден.

При увеличении количества VDS кластер начинал работать нестабильно, и мы переносили клиентские машины на обычные ноды. …
После нескольких итераций стало ясно, что ситуация кардинально не меняется. Приняли решение перенести клиентов на обычные ноды и расформировать кластер.
Первая версия кластера не оправдала ожиданий. Клиенты сталкивались с дисковыми тормозами, а мы уделяли слишком много времени технической поддержке кластера.

* Несбалансированная система с купленными «для экономии» дисками SATA большой емкости стала проблемой при увеличении нагрузки.

* Сетевая распределенная запись на хранилище, без data locality, одновременно с высокой загрузкой кластера по вводу-выводу — зло.

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

Около 5-ти месяцев система замечательно работала, радуя нас и клиентов. Так было, пока количество клиентов не достигло критического значения. Вместительные диски по 4-8 Тб всё-таки вылезли нам боком. При заполнении диска уже наполовину, он превращался в бутылочное горлышко — большое количество файлов, принадлежащих разным VDS, располагались на одном физическом носителе, и ему приходилось обслуживать большое количество клиентов. При выходе его из строя перебалансировка тоже проходила тяжело — надо перераспределить большой объём информации. SSD-кэш в таких условиях плохо справлялся со своими обязанностями. Рано или поздно диск кэша переполнялся и давал сигнал — с этого момента я ничего не кэширую, а только записываю сохраненную информацию на медленный HDD-диск. HDD-диск испытывает в это время двойную нагрузку — обрабатывает прямые обращения, которые поступают минуя кэш, и записывает сохраненные в кэше данные. Хранилище хорошо работало, пока дело не доходило до изменения дисковой конфигурации. Выпадение диска или добавление нового сильно замедляло общую пропускную способность хранилища.

* Низкое качество кода ceph, может привести к серьезным проблемам с разрушением хранилища данных.

Используйте LTS-выпуски Ceph. Не рассчитывайте, что будете накатывать новую версию с каждым релизом. Обновление — потенциально опасная операция для хранилища. Переход на новую версию повлечёт изменения в конфигах, и не факт, что хранилище заработает после обновления. Отслеживайте багфиксы — они бэктрекаются из новых версий в старые.

* Баги могут уничтожить как работу кластера в целом, так и содержимое хранилища.

18 февраля 2016 мы столкнулись с критическим багом Ceph: в процессе скидывания кэша на диск происходила некорректная запись блока данных. Это приводило к отключению процессов ceph-osd всех дисков, где хранились реплики злосчастного блока. Система сразу лишалась трёх дисков, а значит и всех файлов, размещенных на них. Запускался процесс перебалансировки, но не мог завершиться до конца — ведь из системы пропадали все три копии как минимум одного блока данных (и соответствующего файла), с которого началась проблема. Консистентность хранилища была под угрозой. Мы вручную удаляли ошибочные блоки, перезапускали процессы ceph-osd, но это помогало ненадолго. Ошибочная запись повторялась, балансировка начиналась снова, и хранилище рушилось. …
Напряженный поиск в интернете дал результат — закрытая бага в последнем на тот момент релизе Ceph Hammer. Наше хранилище запущено на предыдущей версии — Firefly.
Предупредили клиентов о недоступности серверов и приступили к обновлению. Переключились на другой репозиторий, в который залит фикс баги, выполнили yum update, перезапустили процессы Ceph — не помогло. Ошибка повторяется. Локализовали источник проблемы — запись из кэша в основное хранилище — и отключили кэширование полностью. Клиентские серверы заработали, но каждая перебалансировка превращалась в ад. Диски не справлялись с обслуживанием системной балансировки и клиентского чтения-записи.
Решили проблему кардинально — отказались от SSD-кэша

* Для полноценной работы кластера ceph требуется allflash конфигурация.

поставили SSD-накопители в качестве основных. Тут помогли ноды с большим количеством дисковых корзин, предусмотрительно купленные для кластера хранения. Заменяли постепенно: сначала добавили по четыре SSD в оставшиеся пустые корзины на каждом сервере, а после балансировки данных, стали по одному заменять старые HDD-диски на SSD. Делали по схеме: удаление диска, установка диска, балансировка данных, удаление, установка, балансировка и так далее по кругу, пока в нодах не остались только SSD. Заменяли на горячую …
Использовали промышленные накопители Samsung 810 размером 1 Тб. Не стали использовать SSD большего размера, чтобы не провоцировать ситуацию «узкого горлышка», когда на одном физическом носителе располагается много данных, и, следовательно на него приходится большое количество обращений.
Таким образом, постепенно мы заменили все накопители на SSD. И наступило счастье

Мои выводы (которые могут не совпадать с выводами авторов оригинального поста): ceph в продакшне — опыт для людей с железными яйцами. Скупой платит. И хорошо если только дважды. И тем более хорошо, если только деньгами. Забудьте об отпусках с семьей и отключенном на ночь звонке телефона. Это не для вас теперь.
Зато не скучно. :)

Oracle RAC на внешних хостах с использованием Acropolis Block Services (ABS)

Интересный эксперимент провели у нас в лабе. Был запущен Oracle RAC 12.1 на двух хостах Lenovo (бывш. IBM) x3850, подключенных к 4 нодам кластера Nutanix (NOS 4.7) с использованием Lenovo HX7500 в AllFlash конфигурации (суммарное число нод в кластере было 6, как видно из скриншота ниже, но 2 в тесте не участвовали и в ABS подключены не были).
Причем так как не стояла задача достигнуть максимально возможных результатов, не делалось никакого тюнинга баз, и эксперимент проводился параллельно с другими операциями на этом экспериментальном кластере, в частности там же в этот момент было развернуто около 100 рабочих мест в XenDesktop и 4 вспомогательные базы в MS SQL.

Тем не менее, было достигнуто около 90K IOPS на OLTP-подобной нагрузке (70% Read / 30% Write) при средней latency около 1ms.
Суммарная производительность всех 6 узлов кластера, обрабатывавшего кроме нагрузки Oracle RAC еще и другие задачи лабы, составила около 200.000 IOPS

sn-2057-oracle-rac-with-abs_image5

А это показания непосредственно Enterprise Manager-а Oracle.

sn-2057-oracle-rac-with-abs_image6

Показания значений latency

sn-2057-oracle-rac-with-abs_image7

Выброс latency в районе 8:35 — это создание снэпшота AWR — Automatic Workload Repository.

При тесте в качестве генератора OLTP-подобной нагрузки использовался SLOB v2.3.

Конфигурация тестовой платформы:

Four-node HX7500 all-flash (prerelease hardware version) running Nutanix AHV:

  • 24x 800 GB SSDs per node
  • 2x Intel E5 v3 CPUs per node
  • 256 GB of RAM per node
  • 2x 10 GbE NICs per node

Two-node Lenovo x3850 X6 running Oracle Linux and Oracle 12c in RAC configuration:

  • 512 GB of RAM per node
  • 2x 40 GbE per node
  • 2x 10 GbE per node

sn-2057-oracle-rac-with-abs_image3

Nutanix AHV 4.7
Oracle Linux v7.1 x86_64
Oracle 12cR1 Grid Infrastructure v12.1.0.2
Oracle 12cR1 Database v12.1.0.2

На каждой ноде Oracle RAC был установлен Oracle Linux 7.1 x86_64 с 72 cores на 512 GB памяти, 128 GB выделено Oracle SGA (System Global Area).
Oracle ASM disk groups использовали 4 MB allocation unit (AU). Параметры ASM:

Database data — 24 тома 500GB
Online Redo Logs — 6 томов 30GB
FRA — 6 томов 100GB
OCR/Vote Disk — 6 томов 20GB

Для подключения томов к хостам Oracle использовался iSCSI 10GBE.

Citrix XenServer на Nutanix: некоторые подробности

citirx-xenserver-720x340
На прошлой неделе я упомянул о новости, появившейся на сайте Citrix, о том, что Nutanix начал поддерживать четвертый гипервизор. Плюс к VMware ESXi, MS Hyper-V, и нашему собственному Acropolis Hypervisor на базе RedHat KVM, мы начали поддерживать на наших системах еще и Citrix XenServer. Таким образом, практически все сегодняшние коммерческие гипервизора на рынке у нас поддерживаются, ни одна гипервизорная web-scale система больше такого не умеет.

У меня появились некоторые материалы, которые позволяют ответить на вопросы пользователей «как, зачем и почему».

Во-первых, как я уже писал ранее, Citrix XenServer поддерживается, в первую очередь, как гипервизор для решения Citrix XenDesktop. Первая версия, в которой появится поддержка XenServer будет Nutanix OS 5.0. Как вы уже знаете, все крупные новые фичи Nutanix сперва появляются в статусе Technical Preview (TP), и становятся Production-ready в следующем релизе Nutanix OS. Таким образом, впервые XenServer появится в ближайшем релизе, который будет 5.0, и далее станет production-ready в 5.1. Единственная версия XenServer, которая будет поддерживаться — 7.0

Направленность на XenDesktop связана с тем, что в Citrix XenServer работает поддержка для GPU-карт. Это то, что, пока, еще не работает в настоящий момент на AHV. Это будет в AHV, и ожидается уже в первой половине года 2017, но, пока этого нет, если вам нужен GPU в VDI, то следует использовать XenServer как платформу для VDI-системы XenDesktop. Мы планируем поддерживать XenServer только для этой задачи. Если вы ищете бесплатный гипервизор вообще, то лучше смотрите на наш AHV.

Интеграция XenServer в готовящемся TP пока не такая полная, как для трех остальных (например в интерфейсе управления). Пока нет средств обновления гипервизора (нашими средствами, которые есть, например, для vSphere и Hyper-V), расширения кластера, по-прежнему требуется XenCenter для развертывания VM в XenServer. К Production-ready релизу это, скорее всего, допилят.

Если вам нужны: Citrix PVS, vGPU или GPU Passthru для XenDesktop, то тогда смотрите на XenServer на Nutanix. Если ваша задача НЕ XenDesktop с GPU и/или PVS, то тогда лучше выберите AHV.

В настоящее время мы планируем использование XenServer только для платформ Nutanix, наши OEM (Lenovo и Dell) пока не планируют поддержку XenServer на Lenovo HX и Dell XC, по крайней мере для TP-стадии.

Nutanix Automation VM

Продолжаем знакомиться с блоггерами Nutanix :)
Thomas Findelkind, наш System Engineer из Германии ведет блог, где публикует свои заметки по работе с Nutanix. Недавно он опубликовал там свою разработку — специальную сервисную VM для автоматизации задач на Nutanix. Это расширяемое решение, для которого можно писать скрипты и задавать сценарии выполнения, например для резервного копирования CVM, мониторинга состояния кластера, и других админских задач.
VM поддерживает выполнение сценариев-рецептов на golang , git, govc, java, ncli (CE edition), vsphere CLI авторских преинсталлированных скриптов с https://github.com/Tfindelkind/automation. Любая задача, которую можно запрограммировать с использованием Nutanix REST API и выполнить из командной строки или из планировщика, может для этого использовать Automation VM.

Для установки вам потребуется иметь на Nutanix версию NOS равную или новее, чем v4.7 (Nutanix CE полностью поддерживается), и компьютер, умеющий выполнить инсталляционный скрипт автора на bash. Устанавливается NTNX-AVM так:

С github-репозитория автора скачивается скрипт DCI (Deploy Cloud Image)/
Скачанный tar.gz надо развернуть на машину с bash (tar -xvzf DCI-1.0-stable.tar.gz), и поправить конфиги по адресу, например: DCI/recipes/NTNX-AVM/v1/CentOS7/config (предположим, мы будем делать NTNX-AVM на основе CentOS 7).
Затем можно выполнить скрипт dci.sh. Убедитесь, что компьютер, на котором выполняется скрипт, имеет доступ в интернет, так как в ходе инсталляции он будет скачивать необходимые компоненты, формируя образ VM.

Необходимые ключи выполнения скрипта:

–recipe=NTNX-AVM             Использовать предустановленные "рецепты" NTNX-AVM
–rv=v1                       Используемая версия, в нашем случае v1
–ros=CentOS7                 Укажем, что образ у нас типа CentOS 7, а не, например, Ubuntu
–host=192.168.178.130       Это IP кластера Nutanix. Можно также использовать CVM IP
–username/–password       имя и пароль пользователя Prism
–vm-name                     Имя создаваемой VM
–container=prod              Имя контейнера установки, у автора "prod"
–vlan=VLAN0                  VLAN сети Nutanix, к которой будет подключена VM. VLAN0 это подключение без VLAN.

Пример строки запуска:
./dci.sh --recipe=NTNX-AVM --rv=v1 --ros=CentOS7 --host=192.168.178.130 --username=admin --password=nutanix/4u --vm-name=NTNX-AVM --container=prod --vlan=VLAN0

Скрипт dci.sh сделает следующее:
Загрузит образ CentOS. Загрузит бинарник deploy_cloud_vm.
Прочтет файл конфига, который мы правили и создаст файл образа CD/DVD image. Все конфигурации IP,DNS, и так далее будут записаны в образ, названный «seed.iso».
Затем скрипт DCI зальет образ CentOS и seed.iso на AHV image service.
NTNX-AVM VM будет создан из образа CentOS и образа seed.iso, подключенного как CD-ROM. Настройки применятсся после первой загрузки. Процесс использует средства cloud-init.
Таким образом NTNX-AVM будет запущен, и все настройки будут к нему применены..
Затем в образ VM в фоне будут установлены инструменты и скрипты. Не спешите выключить его сразу после успешной первой загрузки.

dci-1-0-stable

Nutanix Automation VM установлена и готова. Некоторые примеры использования ее в админской работе можно посмотреть в блоге автора, например, тут: http://tfindelkind.com/2016/09/18/unleash-power-ntnx-avm-daily_health_report-monthly_ncc_health/

Самодельная лаба на базе Intel NUC под Nutanix CE

Сообщество вот уже несколько месяцев обсуждает варианты сделать оптимальную платформу для того, чтобы покрутить Nutanix CE.
Конечно, всегда есть соблазн сколхозить что-то «из говна и палок», то есть из всякого подручного сисадминского шита. Но вряд ли это будет хорошо работать.
Одной из, на мой взгляд, оптимальных, является сборка с использованием платформы Intel NUC, barebone компьютера, позволяющего сделать достаточно мощный и пригодный для CE аппаратный сетап. Это компактный корпус, с процессором i7, возможностью установки в него памяти DDR4 и двух SSD формата M.2, в том числе с поддержкой NVMe (в настоящее время Nutanix не поддерживает NVMe, но, вероятно, мы будем ее поддерживать в следующем году).
Давайте посчитаем, во что такая лаба нам обойдется, будучи собранной «с нуля» в ценах Amazon.com.

1235iD4F4D63EF60DAD1E

Сама платформа, которая называется целиком: Intel NUC Kit NUC6i7KYK Mini PC BOXNUC6I7KYK1 — 624$
В состав платформы включен CPU i7-6770HQ (4 физических ядра, 45W, up to 3,5GHz), но не включена память и SSD.

1237i67BCD7E749028978

Добавим сюда 32GB DDR4 DRAM в виде кита из двух 16GB SODIMM: Crucial 32GB Kit (16GBx2) DDR4 2133 MT/s (PC4-17000) SODIMM 260-Pin Memory — CT2K16G4SFD8213 — 114$

В Intel NUC нет места для HDD, зато есть два слота для SSD M.2. Для CE нам обязательно нужно два дисковых устройства, причем одно должно быть SSD. Поэтому возьмем оба устройства SSD, и сделаем AllFlash!
Минимальная конфигурация по SSD у нас — 200GB, но не рассчитывайте, что минимальная конфигурация будет работать больше, чем просто «заведется». Если вы посмотрите на доступную емкость SSD ноды с одним SSD емкостью 200GB, вы увидите из этих 200GB доступными вам неутешительные 19GB от всего объема SSD. Дело в том, что значительную, на таком маленьком объеме, часть SSD займет внутренняя информация Nutanix как системы, это база метаданных в Cassandra, данные Curator, /home и кэши. На бОльшем диске эти служебные объемы будут не так заметны. Так что с SSD объемом 200GB все даже заведется. Но не более. Так что не будем экономить на SSD, раз уж мы собираем лабу «для удовольствия» при работе.
Возьмем два SSD формата M.2, например: Sandisk X400 Solid State Drive — Internal (SD8SN8U-512G-1122) — 142$ за каждый, итого — 284$.

Теперь — все. Просуммируем: 624 + 114 + 284 = 1021$.
Набросим долларов 20-25 на доставку этого хабара с Amazon в Россию через какого-нибудь мэйлфорвардера, и мы даже остались в подлимитной беспошлинной сумме в 1000 EUR.

Итого, за чуть больше 1000$ мы получаем AllFlash-платформу с четырехядерным CPU на 3,5GHz, и 32GB RAM, под Nutanix CE. Довольно неплохо для старта.

В статье http://tfindelkind.com/2016/06/17/intel-nuc-nuc6i7kyk-installation-nutanix-community-edition-ce-part1/ автор подробно рассматривает сборку и установку подобной платформы под CE.

Но что делать, если хочется собрать что-то не AllFlash, с дисками HDD и побольше, и, возможно, «для работы»? Разберем и этот вариант в следующем посте.

UPD: пост опубликован в нашем блоге на Хабре: Бюджетный «датацентр» на Nutanix CE

Почем обходится Nutanix в сравнении с инфраструктурой «самосбора VSAN»?

Интересное исследование вышло в прошлом месяце и опубликовано на Wikibon.
Делался расчет трех вариантов построения инфраструктуры и миграции на него Microsoft-based IT-системы небольшой (SME) компании:

  • На дешевых whitebox (самосбор) и VMware vSphere 6 + VSAN
  • На серверах Lenovo HX/Nutanix и VMware vSphere 6
  • На серверах Lenovo HX/Nutanix и Acropolis Hypervisor

Бралась небольшая гиперконвергентная инфраструктура из 3 хост-серверов во всех трех случаях.
Рассматривался вариант постепенной, в течение 3 лет, миграции на гиперконвергентную инфраструктуру «классической» IT-системы компании, состоящей из разнообразных инфоаструктурных серверов (File & Print, Microsoft Exchange, Microsoft SharePoint, Active Directory), затем на второй год миграция MS SQL Server компании, затем, на третий год, оставшихся (MySQL и приложений).

Результаты на одной картинке в виде Executive Summary вот:

ExecutiveSummaryLenovoNutanix[1]

Несмотря на то, что стоимость «самосборного железа» платформ в первом случае была существенно ниже (40K против ~150K за Lenovo HX), сокращение всех остальных ценовых составляющих решения, прежде всего операционных расходов, привело к суммарно более низкой цене решения для Lenovo HX, как в варианте с VMware, так и, еще более значительно, с Acropolis Hypervisor.

3YearCostBreakoutLenovoNutanix[1]

Подробнее и с расчетами, а также покомпонентный расклад — в статье: http://wikibon.com/case-study-lenovonutanix-appliance-for-microsoft-application-environment/