NetApp для самых маленьких. Часть 2

В предыдущей части «NetApp для самых маленьких. Часть 1: первоначальное конфигурирование» мы закончили подготовку нашей системы, а теперь можем перейти к следующему этапу и познакомиться с ещё некоторыми техническими решениями в системах на ONTAP.

Create SVM
Мы всё ближе подбираемся к тому, чтобы выделить ресурсы для наших серверов и начать уже работать, но теперь нам нужно настроить Storage Virtual Machines (SVM). Когда-то раньше SVM назывались VServer, поэтому даже команда для работы с ними из CLI осталась прежней — vserver. Это ещё одна виртуальная сущность, которая есть в системах ONTAP, и по сути это виртуальная СХД в рамках которой мы уже и выделяем луны/шары, создаём инициаторов и проводим другие настройки, которые распространяются только в рамках этого SVM. Таких SVM на массиве может быть до 1024 для файлового доступа или до 250 для блочного доступа. Их можно по отдельности отдавать заказчикам или департаментам, в том числе и с возможностью самостоятельного их администрирования (только в рамках SVM).

На самом деле, даже в свежеустановленной системе уже есть SVM, но они служебные. По одному SVM на каждую ноду и кластерный SVM. Их не нужно дополнительно конфигурировать (это было сделано автоматически, во время инициализации и первоначальной настройки системы).

Как видно из примера (я решил вставлять вывод консоли в виде картинки, иначе форматирование текста разъезжается и вывод становится совершенно нечитабельным) у меня есть 3 SVM: один (admin) кластерный, один (node) для ноды (т.к. у меня ONTAP Select, у меня только одна нода) и svm0, который используется для данных. SVM ноды и кластера используются только для служебных нужд. Вы можете вносить изменения в них, но, например, создать в них вольюм у вас не получится. SVM не имеет привязки к ноде или агрегатам. Даже если у вас всего один агрегат, вы можете создать множество SVM и располагать данные на нём одном, при этом в рамках каждого SVM будет предоставляться доступ только к его данным. Вообще это отлично подходит для мультитенантности, т.к. вы можете не просто разделить данные между этими SVM, но и предоставить административный доступ к каждому SVM в отдельности, в том числе, выдавая права и на агрегаты, которые будут доступны администраторам конкретных SVM. Правда административный доступ к SVM возможен только по SSH или при помощи API (например Veeam умеет работать и с отдельными SVM). Ещё одним best practice по использованию SVM, помимо мультитенантности, является создание отдельных SVM для разных протоколов доступа. Конечно, никто вам не мешает в рамках одного SVM дать доступ к данных по всем поддерживаемым протоколам, но это будет не очень удобно с точки зрения администрирования, когда все возможные настройки у вас будут в одной куче. Хотя есть положительные аргументы в пользу использования единого SVM для повышения storage efficiency (но об этом чуть позже).

И так, создадим SVM
ontap2::> vserver create -vserver FirstSVM

В данном случае это минимальный набор параметров, имя нашего SVM. Что же мы ещё полезного можем указать, при его создании?
-ipspace — привязать SVM к IPspace, которые мы создавали в первой части
-rootvolume — указать имя рутового раздела SVM. каждый SVM так же имеет свой рутовый раздел, как это было с нодами, и он также предназначен для хранения служебной информации об SVM. Запомните одно — в рутовом вольюме нельзя размещать данные.
-aggregate — агрегат, на котором будет размещён рутовый вольюм
-snapshot-policy — задаёт политику снепшотов для данного SVM (о снепшотах я планирую поговорить в следующей части)

Как вы могли заметить — в списке нет параметров, указывающих на те протоколы, которые будет обслуживать данный SVM. Так исторически сложилось, что этот параметр нельзя указать при создании SVM (через консоль, через WUI это доступно) и для этого, требуется сделать vserver modify.
ontap2::> vserver modify -vserver FirstSVM -allowed-protocols iscsi

Раз уж мы узнали, что не все параметры можно указать при создании, что же ещё интересного нам доступно при изменении SVM?
-aggr-list — список доступных агрегатов для администраторов этого SVM. Как я уже говорил выше — мы не привязываем SVM к каким то агрегатам, а только даём доступ администаторм SVM создавать на них вольюмы. По умолчанию администратор SVM не может создавать тома в рамках этого SVM.
-max-volumes — максимальное количество томов в рамках SVM. Опять-таки этот параметр нам пригодится в случае “внешнего” администрирования SVM отдельным администраторм
-admin-state — этим параметром мы можем остановить наш SVM, т.е. он не будет работать, не будет доступен для администрирования и не будет предоставит доступ к данным, но при этом он продолжит своё существование. Не заплатил нам заказчик или мы поссорились с отделом Х? Останавливаем их SVM, они теряют доступ к своим данным и администрированию SVM. Ждём, когда нам принесут денежки/примирительную шоколадку и запускаем SVM обратно. При этом все настройки и данные у нас сохраняются.
-allowed-protocols — собственно то, что мы уже сделали, указывает SVM список протоколов, которые на нём доступны

Каждый SVM имеет собственный namespace, поэтому в разных SVM у вас могут быть директории и вольюмы с одинаковыми названиями. В них может пересекаться адресация, да и вообще на самом деле — всё. SVMы в системе ведут себя, как действительно независимые СХД.

Далее мы будем рассматривать как блочный, так и файловый доступ, поэтому я создам сразу 3 (ONTAP Select не поддерживает FC) SVM для каждого из протоколов, и вот что у меня получилось.

Полезные материалы по данной секции:
NetApp Storage Virtual Machines SVM Tutorial Video
Storage Virtual Machines (SVM) Configuration

Create LIF
LIF — это логический сетевой интерфейс, который работает поверх физического порта СХД и привязан SVM, в котором вы его создаёте. Также как и в случае с SVM — у нас уже есть несколько LIF’ов, которые были созданы системой автоматически при первоначальном конфигурировании и привязаны к административным SVM нод и кластера. Наши IP адреса кластера и нод — это такие же LIF’ы, как и те, что мы будем создавать сами. В документации NetApp есть вот такая прекрасная картинка, которая это объясняет просто и наглядно.

В комментариях мне верно подметили, что я упустил один важный момент – настройка работы портов. Массивы NetApp имеют универсальные UTA 2 порты, которые могут работать как по FC протоколу, так и по iSCSI. Для FC используется FC mode, для iSCSI — CNA mode. Самый важный момент – смена режимы работы порта требует перезагрузки контроллеров. А сменить режим работы порта очень просто, это отлично описано в Changing the UTA2 port from CNA mode to FC mode.
Так же один из самых популярных вопросов – прямое подключение систем на ONTAP к хостам по FC. Такая конфигурация не поддерживается, только с использование коммутаторов.

Как видно из картинки, несколько LIF’ов могут работать через один физический или логический порт. Это могут быть как LIF’ы одного SVM, так и разных. У каждого LIF’а есть собственный “домашний” порт, на котором он работает в нормальном режиме. Но LIF’ы могут переезжать на другой порт на соседней ноде (или на той же), в случае, если домашний порт стал недоступен. Но здесь следует сделать уточнение, что мигрируют только LIF’ы административные и предоставляющие доступ к данных по файловым протоколам (CIFS, NFS), LIF’ы предоставляющие блочный доступ — не мигрируют. По этой причине для обеспечения отказоустойчивости нам необходимо создавать как минимум 2 LIF’а на портах разных нод. При этом для SVM с протоколом доступа iSCSI IP адрес на LIF’е сохраняется. Тогда, в случае отказа одного из контроллеров, механизм мультипасинга на хосте должен отработать эту ситуацию и самостоятельно переключить поток данных на те порты, которые остались доступны, а в случае с файловыми протоколами, может быть недоступность адреса шары до 45 секунд, после чего по тому же адресу вы сможете снова получить доступ к данным уже через второй контроллер.

Соответственно, для каждого SVM мы должны создать несколько LIF’ов. Один для управления SVM (если вы планируете передать его управления кому то ещё) и LIF’ы, через которые мы будем передавать данные.

Ещё одно уточнение. Если в вашей конфигурации сети используются VLAN’ы и согласно первой части вы их уже настроили, то в этом случае, необходимо в качестве порта указывать именно порт, на котором уже настроен VLAN, т.е. вместо e0a, использовать, например e0a-211. Аналогично и с Interface group.

ontap2::> network interface create -vserver FirstSVM -lif FirstSVM_mgmt -role data -service-policy default-management -data-protocol none -address 192.168.1.144 -netmask 255.255.255.0 -home-node ontap2-01 -home-port e0a -status-admin up

Разберёмся подробнее
-vserver — указывает для какого именно SVM мы создаём LIF
-lif — название
-role — роль
-service-policy — указывает политику данного интерфейса, в случае создания fil’а для данных, мы будем использовать default-data-blocks или default-data-files в зависимости от протокола доступа к данным
-data-protocol — указываем none, т.к. этот интерфейс будет служить только для административного доступа и не будет использоваться для передачи данных
-address — задаём ip
-netmas — задаём маску сети
-home-node — у каждого LIF’а должна быть “домашняя” нода, как это было у нас с аггрегатами. Это опять-таки не значит, что в случае падения ноды, мы потеряем наш интерфейс, нет, он смигрирует на вторую ноду.
-home-port — аналогично и для физического порта
-status-admin — состояние порта up или down

Аналогичным образом мы создаём FIL’ы для данных, но в отличие от административного интерфейса — их создают несколько (но опять-таки — у меня ONTAP Select, по-этому я меня все LIF’ы будут располагаться на порту только одного контроллера). Вы можете совместить файловые протоколы (CIFS, NFS) в рамках одного LIF’а, но так не получится сделать с файловыми и блочными протоколами, да и вообще — best practice является выделение отдельных LIF’ов под каждый протокол и я не вижу особых поводов здесь для экономии.

ontap2::> network interface create -vserver SVMcifs -lif SVMcifs_data -role data -data-protocol cifs -address 192.168.1.150 -netmask 255.255.255.0 -home-node ontap2-01 -home-port e0a -status-admin up
ontap2::> network interface create -vserver SVMiscsi -lif SVMiscsi_data -role data -data-protocol iscsi -address 192.168.1.151 -netmask 255.255.255.0 -home-node ontap2-01 -home-port e0a -status-admin up
ontap2::> network interface create -vserver SVMnfs -lif SVMnfs_data -role data -data-protocol nfs -address 192.168.1.152 -netmask 255.255.255.0 -home-node ontap2-01 -home-port e0a -status-admin up

Ну а теперь посмотрим, что у нас получилось

У нас есть наш служебный SVM ontap2 у которого 2 интерфейса управления (кластера и ноды), у нас есть FirstSVM, для которого мы создали так же интерфейс управления, и у нас есть 3 SVM и у каждого из них интерфейс для передачи данных.
Конечно, в нормальной сети, вы будете использовать для этого разные порты, vlan’ы и адресацию, но в рамках домашнего тестового стенда мне этого достаточно.

Отдельно добавлю про FC. Точно таким же образом создаются LIF’ы для FC, поверх физических портов. При этом у каждого LIF’а будет собственный WWPN. Со стороны коммутатора, на порту подключения NetApp вы будете видеть NPIV и сможете организовать зонинг с конкретным SVM.

Именно WWPN LIF’ов необходимо добавлять в зонинг на коммутаторах. И для каждого SVM вы должны будете создать отдельные зоны. Физические порты массива добавлять в зонинг не нужно.

Мы закончили конфигурирование SVM и LIF’ов для него, и теперь, наконец-то, мы можем перейти к тому чтобы выделить дисковые ресурсы.

Полезные материалы по данной секции:
NetApp ONTAP Logical Interfaces Tutorial
Roles for LIFs

Create Volume
Ещё несколько лет назад, у компании NetApp были «обычные» Volumes, которые были связаны с агрегатами 1 к 1. На вашем агрегате мог находится только один Volume и вы не имели возможности гибко его расширять или уменьшать. Для его расширения требовалась установка дополнительных дисков. Но компания NetApp пошла дальше и представила технологию Flexible Volumes (или кратко FlexVol или просто — том), которые не имеют жёсткой связи с агрегатом, могут быть размером до 100ТиБ и поддерживают расширение и уменьшение на лету, без простоя. Их может быть до 5000 на систему и они поддерживают технологию thin provisioning. Так же вольюмы можно перемещать между разными агрегатами или SVM и клонировать. Технологии SnapMirror и SnapVault так же работают на уровне вольюма. Для систем FAS дедупликация, компрессия и компакшн (наверное, я напишу отдельную статью о технологиях эффективного хранения в системах NetApp, но это будет позже) также работают на уровне вольюма. А также — снепшоты.
Вольюм, это логический контейнер, который содержит ваши данные. Если мы говорим про файловые протоколы, то клиенты получают доступ к шарам, располагающимся на вольюмах. А если мы говорим про блочный доступ, то вольюм помещаются ещё и LUN’ы (о них мы погодим уже в следующей части), к которым уже и мапятся непосредственно хосты. Думаю в этот момент становится понятно, на сколько сильно все слои системы виртуализованы. Это одна из причин, почему на мой взгляд, для тех, кто впервые столкнулся с системами ONTAP, они очень сложны. И хоть документация описывает практически всё из мною сказанного, найти нужную последовательность с первого раза слишком сложно.

После того, как мы немного разобрались в нашей будущей схеме хранения, нам необходимо создать том
ontap2::> volume create -vserver SVMiscsi -volume vol1 -aggregate ontap2_01_VM_DISK_1 -size 1Gb -space-guarantee none

-vserver — в каком SVM создаём вольюм
-volume — задаём ему имя
-aggregate — на каком аггрегате он будет располагаться
-size — размер
-space-guarantee — отключение гарантии резервирования места делает этот вольюм Thin Provisioned

Как и в случае с созданием SVM, мы не все параметры можем указать при создании вольюма, по этому сразу приступаем к его изменению. Первым делом, мне бы хотелось включить дедупликацию на этом вольюме.
ontap2::> volume efficiency on -vserver SVMiscsi -volume vol1

Аналогичным образом мы можем включить и фоновую компрессию
ontap2::> volume efficiency modify -vserver SVMiscsi -volume vol1 -compression true -inline-compression true

-compression true — включается фоновую компрессию
-inline-compression true — включает инлайн компрессию
Сейчас не буду останавливаться на том, как включение этого функционала будут влиять на производительность в целом. Тут оставлю себе вторую закладочку о том, что я обещал написать отдельную статью по технологиям эффективного хранения данных на ONTAP и там будет логичнее это описать более подробно.

Что касается инлайн дедупликации — для AFF с версии ONTAP 9.2 она включена по-умолчанию. Официально NetApp говорит, что инлайн дедупликация поддерживается только на AFF и на Flash Pool (Flash Pool — это добавление SSD raid-группы в дисковый агрегат. SSD накопители используются для хранения блоков случайного чтения и случайной записи, что позволяет ускорить эти операции в рамках дискового агрегата).

И так, я создам для каждого из нашего SVM свой собственный вольюм

Полезные материалы по данной секции:
Volumes, qtrees, files, and LUNs
Creating and managing volumes

Да, массивы NetApp ONTAP требуют довольно большой предварительной подготовки, нежели конкурентные решения, но это добавляет им гибкости в дальнейшем использовании. Именно поэтому я и решил написать этот небольшой цикл статей. В целом — всё это прекрасно описано в документации, но новичку сложно ориентироваться во всех необходимых для корректной работы системы сущностях.

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

И снова я хочу выразить благодарность Алексею Сарычеву, за помощь в подготовке этой статьи.

Оглавление:
NetApp для самых маленьких. Часть 1
NetApp для самых маленьких. Часть 2
NetApp для самых маленьких. Часть 3