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

Nutanix Acropolis Block Service: планы на ближайший релиз

Уже не раз в этом блоге я упоминал про ABS, Acropolis Block Service, нашу фичу, с помошью которой вы можете создать на хранилище Nutanix блочный LUN, и отдать его по iSCSI 10G внешним хостам, используя часть пространства Nutanix как своеобазную «SDS СХД». Сервис этот развивается, и вот какие новые фичи были объявлены на ближайший релиз.

abs

В настоящее время в списке поддерживаемых OS на внешних хостах: RHEL 6 и 7, CentOS 6 и 7, Oracle Linux 6 и 7, Microsoft Windows Server 2008 R2, 2012 и 2012 R2.
В ближайшем релизе сюда добавятся VMware ESXi 5.5 и 6.
Последние в настоящий момент не поддерживаются, но, как видите, будут. Это означает, что вы сможете использовать Nutanix как внешнее хранилище для уже существующих у вас хостов виртуализации, например, на время переходного периода, миграции, и так далее. Не думаю, что использовать Nutanix только как SDS будет хорошей идеей, в результате вы лишаетесь множества плюсов, присущих Nutanix как решению. Но как вспомогательный способ решить какие-то конкретные задачи инфраструктуры это вполне работает.

В 5.0 ожидается Online LUN resizing.

Также мы ожидаем механизм Dynamic load balancing, который поможет распределять и динамически ребалансировать нагрузку по нодам в зависимости от их загрузки.

В 5.0 также появится CHAP authentication и IP/IQN based whitelisting, что позволит обеспечить необходимый некоторым инфраструктурам уровень защиты.

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.

Nutanix ABS: как у нас работает failover/failback?

Интересное видео, показывающее, как отрабатывает Failover и Failback на нашем ABS — Acropolis Block Storage — сервисе, который отдает внешним серверам хранилище Nutanix как блочные LUNы. Это (по крайней мере изначально) было придумано для возможности подключить к кластеру Nutanix какой-то внешний сервер, например Oracle, который нельзя, или лицензионно дорого перетаскивать под гипервизор.
Но как при этом работает failover? Что произойдет если, например, одна из нод кластера упадет?

Вот на этот вопрос отвечает видео. На нем 4-нодовый кластер Nutanix отдает LUN-ы с тестовой базой внешнему серверу Oracle DB. На Nutanix также запущен в отдельной VM swingbench, эмулирующий нагрузку к этой базе данных и показывающий графики параметров работы теста.

На первом видео мы видим, как все четыре CVM обслуживают внешний сервер, самобалансируя ввод-вывод с него между собой. Обратите внимание, что мы НЕ ИСПОЛЬЗУЕМ MPIO или ALUA, для нашей архитектуры доступа к данным они не нужны на хост-сервере! iSCSI Initiator на физическом хост-сервере обращается на общий «кластерный IP» таргета, который передается какому-то из CVM, и им обслуживается. В версии 4.7 используется равномерная «рассортировка» по CVM, начиная с версии 5.0 для выбора целевого CVM используется сравнительный уровень его загрузки. Добавляемые в кластер ноды автоматически начинают обслуживать операции ввода-вывода, без дополнительного вмешательства и перенастройки админом.

Затем мы физически отключаем одну ноду, используя команду poweroff на IPMI из консоли. (страничка по адресу CVM с портом 2009 это одна из наших служебный вебстраниц интерфейса, в данном случае — iSCSI Target Adapter-а).
Мы видим, что iSCSI target переехал на одну из нод, которая подхватила операции упавшей, с минимальной задержкой операций, в пределах таймаута. Нагрузка на CVM, подхвативший операции вышедшего из строя выросла. Операции swingbench не прерывались.

Затем, мы включаем ноду назад, и, вскоре, видим, как она включилась, и iSCSI Target самостоятельно вернулся на включенную ноду, так что нагрузка снова автоматически сбалансировалась по всем четырем CVM-«контроллерам СХД».