Архив метки: block storage

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