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

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-«контроллерам СХД».

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-часть еще и некоторыми более традиционными сервисами для внешних потребителей.