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

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

История двухлетнего опыта использования 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/

Демо новых фич: ABS+AFS+XenDesktopMCS+AllFlash

Интересное видео демонстрационной конфигурации на Acropolis Hypervisor, на которой показаны наши новинки нескольких последних месяцев. Тут и MCS plugin для XenDesktop, и AFS (File Server), и большие MS SQL инстансы в VM, и внешние хосты с Oracle RAC, подключенные через ABS (Block Service).

abs-afs-mcs-demo-config-acropolis

Платформой послужили AllFlash хосты Lenovo HX. Демо показывалась вживую на нашей конференции .NEXT неделю назад.

ABS: Acropolis Block Service

ABSoverview[1]

На идущей сейчас в Лас Вегасе большой конференции Nutanix .NEXT объявляют много новинок, которые будут выкачены в самом ближайщем будущем. Например, в версии 4.7 которая выйдет в релиз буквально через неделю-две, мы выпускаем новую очень важную фичу, о которой мне бы хотелось рассказать подробнее.
Итак, Acropolis Block Storage Service позволяет подключать к дисковому пространству кластера нодов Nutanix внешних потребителей не только по файловым протоколам, как это вы уже, возможно, видели в нашем Project Meduza, распределенном файловом «NAS», но теперь и как к блочному стораджу, по протоколу iSCSI.

Acropolis Block Service это расширение нашей In-Guest iSCSI service, который появился год назад. С его помощью можно было использовать блочный доступ в пользовательских VM, например для того, чтобы подключить хранилище к MS Exchange (с некоторых пор подключение по NFS в MS Exchange не поддерживается в MS), кластеры SQL, кворумные диски MS Cluster Service но, конечно, есть много других причин использовать подключение iSCSI внутри Guest OS.

Вот на базе этого механизма, только не для находящихся «внутри» кластера VM, а для внешних хостов с iSCSI Initiator-ами будет работать ABS.

Интересно, что доступ по iSCSI осуществляется непосредственно через CVM, фактически минуя гипервизор, то есть CVM в данном случае играет роль iSCSI Target для клиентского Initiator.
Для того, чтобы понять почему это так, давайте вспомним схему устройства и путей к данным в Nutanix.

.2016-06-23_13-13-52

На физический сервер-платформу устанавливается baremetal hypervisor, в случае VMware это обычный ESXi, в случае Acropolis Hypervisor это CentOS с нашей версией KVM, вернее кода, разработанного на его основе, и которую мы называем Acropolis Hypervisor. Он видит и владеет всем железом платформы, ее CPU, памятью, сетевыми интерфейсами. Всем, кроме жестких дисков. Контроллер SAS HBA, к которому подключены HDD и SSD, с помощью технологии PCIe Passthrough отдан в исключительное владение OS, находящейся в CVM, Controller VM. Он уже видит все диски как физические устройства, работает с ними напрямую, создает на них нашу NDFS (Nutanix Distributed File System, или, как мы сейчас переименовали «Acropolis Distributed Storage Fabric»). Затем, получившуюся файловую систему со всеми нашими сервисами поверх он презентует гипервизору как готовый датастор по протоколу NFS (в случае ESXi), SMB3 или iSCSI в случае Hyper-V или AHV соответственно. То есть, для CVM нет ничего невозможного отдавать наш «датастор», как какой-то фрагмент нашего хранилища, в том виде, в котором нужно, например в виде блочного хранилища внешним потребителям по протоколу iSCSI, фактически минуя при этом Hypervisor, не получая дополнительного оверхеда от двойной «виртуализации».

Вот так и получился ABS — Acropolis Block Service, естественным образом дополнивший уже вышедший и развивающийся AFS, Acropolis File Service, распределенный, многоузловой NAS-сервис Medusa.

К достоинствам ABS также следует отнести то, что на клиентской системе не нужны средства MPIO и ALUA, а при добавлении новых нод в кластер Nutanix не требуется никаких перенастроек на стороне клиента. В случае, если клиент теряет CVM, через который получал доступ к блочному диску по iSCSI, initiator на его стороне производит повторный «логин» сессии в Nutanix, и начинает работать со своими дисками через любой доступный другой CVM. Этот процесс происходит быстрее, чем таймаут SCSI, поэтому процесс работы с данными диска он не прерывает. Таким образом, количество «контроллеров» такой «системы хранения» получается равной числу нодов кластера. При этом каждый CVM может обслуживать множество iSCSI Target-ов.

ABSCVMfailure[1]

Зачем нам делать из гиперконвергентной платформы Nutanix конкурента классическим дисковым сетевым системам хранения? Ответ достаточно прост. Есть задачи, в которых не обойтись без «классического» NAS или «классического» блочного стораджа для «внешних» хостов (для «внутренних» VM у нас давно уже есть Volume Groups, если вы о них забыли). Пример такой задачи для NAS это VDI, где нужно хранить пользовательские профили и «домашние папки». Это в чистом виде задача для файлового стораджа. Раньше, строя VDI на Nutanix, нашим клиентам приходилось для хранения профилей где-то поднимать NAS на какой-то сторонней СХД. Теперь это можно сделать в рамках одного нашего решения.

Примерно та же задача произвела на свет ABS. Допустим, у пользователя есть Nutanix, и его все устраивает, и он мигрировал внутрь Nutanix свои задачи и приложения. Но у него есть legacy база данных, например Oracle, работающая на паре «тяжелых» физических серверов, может быть даже и не x86. На каком-нибудь Oracle SPARC, купленных тогда, когда сейлы Oracle очень живописно продавливали клиентам SPARC как лучшую платформу для Oracle. Может, кстати, это и так. Факт тот, что у пользователя есть физический, невиртуализованный Oracle и лицензии на него, и, как вы знаете, лицензирование Oracle в виртуальной среде штука очень хитрая. Так что пользователь может бы и хотел выкинуть уже SPARC (или там Power6/AIX/DB2/AS400), но не может. Или не хочет. Тоже имеет право.
Вот тут как раз хорошим выходом для него будет ABS. Он может не отказываться от своих физических хостов под приложения, а отказаться только от устаревшей СХД, чтобы свои данные хранить на Nutanix в ABS, со всеми плюсами этого решения.

Таким образом, ни ABS, ни AFS не означает, что Nutanix теперь отказывается от гиперконвергентности, и начинает играть как простая SDS СХД. Вовсе нет. Но в тех нишах, тех узких областях, где раньше Nutanix «не проходил», он теперь может сыграть, дополнив свою HCI-часть еще и некоторыми более традиционными сервисами для внешних потребителей.

Производительность NX-3460-G4 с NOS v4.6

Вывод diagnostics.py под Acropolis вчерашней инсталляции NX-3460-G4, 4 ноды, 2x480GB SSD, 4x2TB SATA на ноду, 256GB RAM, 2x E5-2660v3 CPU
Результаты — для всех 4 нод суммарно. Для производительности одной VM на одной ноде — делить на 4.

nutanix@NTNX-15SM60210062-A-CVM:10.9.20.160:~$ diagnostics/diagnostics.py --display_latency_stats --run_iperf run
Cleaning up node 10.9.20.156 ... done.
Cleaning up node 10.9.20.157 ... done.
Cleaning up node 10.9.20.158 ... done.
Cleaning up node 10.9.20.159 ... done.
Cleaning up the container and the storage pool ... done.
Running Iperf Test between CVMs
bandwidth between 10.9.20.160 and 10.9.20.161 is: 8.65 Gbits
bandwidth between 10.9.20.160 and 10.9.20.162 is: 8.77 Gbits
bandwidth between 10.9.20.160 and 10.9.20.163 is: 8.51 Gbits
Checking if an existing storage pool can be used ...
Using storage pool default-storage-pool-28308 for the tests.
Checking if the diagnostics container exists ... Container with desired replication factor exists.
Preparing the UVM on host 10.9.20.156 ...

Transferring diagnostics image to NDFS ... done.
Deploying the UVM on host 10.9.20.156 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.157 ...

Deploying the UVM on host 10.9.20.157 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.158 ...

Deploying the UVM on host 10.9.20.158 ... done.
Adding disks ... done.
Preparing the UVM on host 10.9.20.159 ...

Deploying the UVM on host 10.9.20.159 ... done.
Adding disks ... done.
VM on host 10.9.20.156 has booted. 3 remaining.
VM on host 10.9.20.157 has booted. 2 remaining.
VM on host 10.9.20.158 has booted. 1 remaining.
VM on host 10.9.20.159 has booted. 0 remaining.
2016-02-29_05-13-22: Running setup "Prepare disks" ...
done.
Average CPU: 10.9.20.162: 45% 10.9.20.163: 40% 10.9.20.160: 39% 10.9.20.161: 47%
Duration prepare_disks : 44 secs
*******************************************************************************

Waiting for the hot cache to flush ............. done.
2016-02-29_05-15-14: Running test "Sequential write bandwidth" ...
1291 MBps , latency(msec): min=8, max=1758, median=344
Average CPU: 10.9.20.162: 35% 10.9.20.163: 31% 10.9.20.160: 32% 10.9.20.161: 36%
Duration fio_seq_write : 41 secs
*******************************************************************************

Waiting for the hot cache to flush ............. done.
2016-02-29_05-17-00: Running test "Sequential read bandwidth" ...
3884 MBps , latency(msec): min=0, max=564, median=118
Average CPU: 10.9.20.162: 29% 10.9.20.163: 23% 10.9.20.160: 26% 10.9.20.161: 30%
Duration fio_seq_read : 15 secs
*******************************************************************************

Waiting for the hot cache to flush ........... done.
2016-02-29_05-18-11: Running test "Random read IOPS" ...
223506 IOPS , latency(msec): min=0, max=19, median=2
Average CPU: 10.9.20.162: 79% 10.9.20.163: 80% 10.9.20.160: 81% 10.9.20.161: 80%
Duration fio_rand_read : 102 secs
*******************************************************************************

Waiting for the hot cache to flush ........ done.
2016-02-29_05-20-30: Running test "Random write IOPS" ...
149141 IOPS , latency(msec): min=0, max=207, median=2
Average CPU: 10.9.20.162: 69% 10.9.20.163: 63% 10.9.20.160: 67% 10.9.20.161: 63%
Duration fio_rand_write : 102 secs
*******************************************************************************

Tests done.
Results archived in /home/nutanix/diagnostics/results/2016-02-29_05-10-56
nutanix@NTNX-15SM60210062-A-CVM:10.9.20.160:~$

До установки NOS 4.6 там была 4.5.1 и где-то ~120000 IOPS на random read.