Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Multistore | about NetApp

Multistore

Как и обещал чуть раньше – рассказываю про этого зверя.
Multistore – опция систем хранения NetApp, позволяющая делить физическую систему хранения на “логические партиции”.

image

Multistore - “в обед сто лет”. Она существует многие годы (с первых версий 7.0, а то может и даже раньше), но, к сожалению, до недавних пор сравнительно редко применялась. На нее требовалась отдельная и не самая дешевая лицензия, поэтому многие NetApp-админы часто даже не слышали о Multistore, и не применяли ее.

Однако многое изменилось в прошлом году. Во-первых Multistore была извлечена из забвения, в котором находилась много лет, и приспособлена к многим новым инициативам NetApp, куда она удивительно органично подошла, например к Secure Multi-Tenancy. Во-вторых, появились новые и многообещающие продукты, использующие Multistore, например NetApp DataMotion for vFilers, позволяющая такие “виртуальные партиции” – виртуальные “файлеры”, созданные внутри физической системы хранения, переносить между системами хранения, даже между физически различными, и установленными в разных местах, без прерывания к ним доступа, наподобие vMotion для виртуальных машин в VMware.
?, наконец, логичным шагом стало включение Multistore в комплект ONTAP Essentials, идущий по умолчанию, и доступный целиком, без покупки дополнительных лицензий, для новых систем FAS3200/6200, что тем более делает нужным и полезным знакомство с этой интересной опцией.

Но давайте по порядку.

Multistore – это средство создавать внутри физического контроллера системы хранения множество “виртуальных”, автономных “логических” систем хранения, с автономным управлением, и своим набором данных для каждой.
Разумеется вы уже подумали про гипервизоры в стиле VMware, но – нет, все проще, используется механизм, подобный chroot или jail во FreeBSD. Это позволяет гораздо меньше “нагружать” железо, и вполне безопасно изолирует такие виртуальные файлеры друг от друга. Так, например, для самой младшей FAS2020 количество таких виртуальных файлеров ограничено 26, а для всех остальных контроллеров NetApp под версиями Data ONTAP 7.x можно создать до 65 таких ?vfilers’ (на каждом контроллере, на HA-пару – 130), что, конечно, гораздо экономичнее, с точки зрения расхода памяти и ресурсов, так как как “сущность” Data ONTAP не множится в памяти, продолжая существовать в единственном экземпляре. Каждый vFiler занимает в системной памяти всего около 400Kb.

В отношении же безопасности изоляции данных, следует упомянуть, что, в течении нескольких лет, независимая компания информационной безопасности Matasano Security проводила security audit OS NetApp Data ONTAP, и отметила в итоговом документе:

At the conclusion of our testing, we found that the Data ONTAP operating system exceeded our expectations for security. We know of no vulnerability in Data ONTAP that would allow an attacker to use a FAS Storage System, even if they have a login to a portion of it, to compromise another subnet.

NetApp MultiStore: An Independent Security Analysis
Prepared By: Thomas Ptacek and Eric Monti, Matasano Security

Классической, изначальной областью применения Multistore, до недавних пор, была организация использования NAS-файлера в многодоменной Windows-сети, а также возможность создавать виртуальные файлеры для подразделений в компании, требующих отдельных политик администрирования и безопасности. В этом случае, вместо заведения таким подразделениям отдельных физических систем, вы могли выделить им виртуальный файлер, на котором они могли быть своим собственным виртуальным рутом, создавать на нем любые, угодные им ресурсы, с любыми нужными им политиками, все в таком своеобразном изолированном jail-е внутри физического файлера.

Такой виртуальный файлер выглядит изнутри себя как отдельный “netapp”, включая свой собственный vol0 и /etc, а попасть администратору в его контекст можно с помощью команды:

mainfiler> vfiler context vfiler1
vfiler1@mainfiler> Wed Apr 8 22:18:24 EDT [vfiler1@cmds.vfiler.console.switch:notice]: Console context was switched to a vFiler(tm) unit vfiler1.

vfiler1@mainfiler>

Далее вы можете оперировать в среде такого vfiler как в реальной системе. В настоящее время  в среде vfiler команды управления в значительной мере совпадают с тем, что доступно в “физическом” файлере.

Каковы же ограничения?

Пожалуй самым заметным следует указать отсутствие в среде такого vfiler поддержки FCP. Работают все остальные протоколы, то есть CIFS, NFS, NDMP, FTP, и так далее, но из “блочных” протоколов доступен iSCSI. То есть vfiler может работать в SAN, но в настоящее время только как iSCSI-target. Отсутствие поддержки FCP в контексте vfiler связано, прежде всего, с отсутствием поддержки NPIV в Data ONTAP, однако  она также может быть со временем добавлена. Но в настоящий момент вы не можете “виртуализовать” физический FC HBA, разделив его между виртуальными файлерами, поэтому FCP доступен только на уровне хост-системы, или vfiler0, как ее в данном случае принято называть.

Мне не удалось найти однозначных сведений по поводу текущего состояния с FCoE на Unified Target, возможно уточнят этот вопрос присутствующие и читающие меня люди из NetApp?

Что касается ethernet, то каждый vfiler оперирует своим набором IP-адресов, VLAN, VIF и таблиц маршрутизации, что позволяет оперировать с ним как с самостоятельной сущностью, с точки зрения администрирования. Например можно держать один vfiler в DMZ, а другой – во внутренней сети, оба будут находиться внутри одного физического контроллера, но данные первого будут надежно изолированы от данных второго. На физический контроллер доступно до 101 набора IPspaces, то есть логических таблиц маршрутизации.

Кроме уже упомянутой, традиционной области применения, такой как многодоменная Windows-сеть, и подразделения с индивидуальными политиками администрирования, областью применения Multistore, в особенности с новыми продуктами Secure Multi-Tenancy и DataMotion, может быть задачи Disaster Recovery или миграции данных.

Например команда vfiler migrate перенесет весь instance виртуального файлера, включая его данные и конфигурацию, IP-адреса, NETBIOS Name, hostname, на новый контроллер (требуется активированная лицензия SnapMirror).

Вы также можете регулировать загрузку физического файлера его vfiler-ами с помощью средств FlexShare и назначения приоритетов доступа к томам FlexVol. Помните, что оттого, что вы на одном физическом контроллере создали десяток виртуальных, производительность физического не увеличилась, IOPSы, выдаваемые физическим контроллером распределятся между vfiler-ами, а с помощью FlexShare вы сможете правильно сбалансировать приоритеты.

Так что тем, кто получает новые системы с набором лицензий ONTAP Essentials, куда, повторюсь, входит Multistore, рекомендую пошевелить тему поподробнее, возможно вы найдете что-то интересное для конкретно вашего случая использования.

2 комментария

  1. bbk:

    Никто так и не выяснил на счёт FCoE для vfiler’ов?

    По поводу безопасности,- если каждый управляет своими VLAN, то это получается дыра в безопасности в случае совместного использования несколькими vfiler’ами физических Ethernet интерфейсов. С другой же стороны, если файлерам отдаются физические интерфейсы в монопольное использование, где напастись 64+1 интерфейсов?

    ? ещё вопрос на счёт того, можно ли передать виртуальному файлеру в управление физические диски? Подозреваю,что только разделы vfiler0.

  2. bbk:

    На свой вопрос о безопасности и VLAN’ах для vFiler’ов ответ нашел здесь:
    https://communities.netapp.com/message/81017#81017

Оставить комментарий

20/0.081

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.