Переход на Clustered Data ONTAP. Часть 1

Несколькими месяцами ранее я уже проводил опрос, на тему перспектив перехода пользователей на Clustered Data ONTAP на их стораджах. Опрос это обозначил несколько основных групп пользователей по отношению к Clustered Data ONTAP.

Если с примерно третью, теми, кто ответил, что они уже перешли, или переходят до конца этого года (ну или в обозримое время, главное, что решение уже принято), все понятно, я могу их только поздравить с их решением, то вот с оставшимися двумя третями все сложнее. Конечно, я трезво понимаю, что среди оставшхся некоторое (значительное) количество составляют владельцы младших и старых систем, для которых переход на Clustered Data ONTAP закрыт по техническим причинам (например – старости, слабости и непригодности контроллеров предшествующих поколений стораджей). Но наверняка среди них также есть и люди, которые, возможно, могли бы перейти на Clustered Data ONTAP, но либо не понимают как и когда это проделать, либо недостаточно осведомлены о том, от каких плюшек они, в результате, отказываются. Мне бы хотелось, в серии постов, котрые я запланировал и написал для ближайших нескольких недель, детально разобрать эти новые и полезные возможности Clustered Data ONTAP.

??так, вкратце, для тех, кто совсем все проспал, или же только подключился к чтению этого блога, например собираясь купить сторадж NetApp, или разбираясь с уже купленным:

Системы хранения NetApp это устройства, в значительной мере предвосхитившие идею Software-defined Storage, так как практически все их функцональные возможности реализованы внутри и посредством их собственной OS, носящей название Data ONTAP. Эта OS развивается с 1992 года, и, на сегодня, несмотря на некоторую внешнюю похожесть, не является ни одной из знакомых вам опенсорсных платформ (хотя когда-то, в самом начале и началась с допиливания BSD 4.2 UNIX, а сегодня частично использует в некоторых “небоевых” областях отдельные модули из FreeBSD). Я хочу на этом отдельно остановится, так как, по-прежнему, некоторые люди, плохо разбирающиеся в деталях работы Data ONTAP, считают и утверждают (голословно), что, де, “это все Linux (или FreeBSD)”. Нет, это не так. Кратко на этом остановившись, пойдем дальше.

OS Data ONTAP позволила построить систему хранения, в которой добавление новой функциональности сводится, по сути, к дописыванию нового кода в этой OS, что позволяет быстро и широко модернизировать их системы хранения. Такой подход существено отличается от подхода “аппаратной реализации”, при котором любое расширение или изменение функционала крайне болезненно и занимает у разработчика много сил и средств (поскольку функциональность оказывается “захардкожена” в “микросхемах”), и, часто, практически невозможно в уже проданных и установленных системах. Когда-то “аппаратность”, следует уточнить, обеспечивала лучшие показатели производительности и надежности, но сегодня, с современными процессорами, архитектурами и хорошо отлаженным программным кодом такой Software-defined Storage уже мало отличается по этим параметрам от “аппаратных” решений, но существенно в лучшую сторону отличается в гибкости и способности расширять функциональность просто обновлением OS.

Поэтому нет ничего удивительного в том, что несколько лет назад NetApp, с выходом Data ONTAP версии 8, начала, почти с нуля, развивать новую “ветку” своей OS Data ONTAP, которая позвляет строить системы хранения в виде многоузловых кластерных систем. Однако, так как многие пользователи были на тот момент не готовы к переходу на новую, полностью обновленную архитектуру и OS, то NetApp, здраво рассудив, продолжила поддержку и развитие своей “классической” OS, которая получила название 7-mode, так как продолжала внури 8.x линейку ветки 7.х. При этом, кроме Data ONTAP 7-mode, существовала Data ONTAP, “новая”, получившая название c-mode, или Cluster-mode, сейчас же она стала называться короче и понятнее: Clustered Data ONTAP.

Такая двойственость “переходного периода” существовала на сегодня уже довольно долгое время, однако у всего есть конец, и вот, наконец, было принято решение, что Data ONTAP 7-mode больше не будет развиваться. Сперва, вот уже вроде пару лет как, в нее перестали добавляться новые фичи, ограничиваясь поддержкой и отладкой уже существовавших, то есть переведя ее в frozen/stable, а вот теперь, наконец, было решено сделать следующий шаг, и что следующий мажорный релиз, выходящий в RC уже этой осенью, будет уже только Clustered Data ONTAP, так что в v8.3 кода 7-mode уже не будет.

Что это означает для всех нас? Ну, тут есть два варианта. Если у вас уже работающая в Data ONTAP 7-mode система из старых серий, то есть ранее FAS2240 и FAS3200, и вас в том, как она работает все устраивает, то тогда нет повода беспокоиться, просто продолжаете жить и работать, как жили и работали до этого. Силой вас никто никуда переезжать не заставит. В период пяти лет с момента продажи такие сторажи продолжают полностью и официально поддерживаться компанией. При этом, фактически, стораджи NetApp часто живут очень долгую жизнь, я лично встречался с по прежнему работавшим старым устройством, жившим на аж на какой-то 6.5.х, то есть свыше десятилетней давности выпуска. Ну, коптило, тарахтело, обслуживала свох пару десятков пользователей NFS в университете. Но работало.

Но если у вас сторадж относительно новый, купленный в пределах последних года-двух, в особенности если это системы midrange, то есть FAS3200, то, наверняка, вам будет интересно посмотреть на то, что же есть сегодня в Clustered Data ONTAP, и чего у вас нет в Data ONTAP 7-mode.

Прежде всего, в Clustered Data ONTAP теперь присутствует концепция, под названием NDO – Non-Disruptive Operations. Практически все операции, которые вы можете выполнить на сторадже, например обслуживания его, обновления OS, замены контроллеров, миграции данных, переноса томов и даже виртуальных файлеров, SVM, с контроллера на контроллер, и так далее, могут выполняться без прерывания идущей работы с данными. В небольшой список исключений входят, например, операции с сетевыми шарами SMB, где, по свойствам самого протокола, при миграции SVM разрывается сессия, которую приложение должно заново инициировать, например заново ранее открытый открыть файл. При этом любые операции NFS или блочных протоколов, iSCSI, FCP, FCoE, происходят без прерывания работы с данными, даже если при этом том с этими данными переезжает с контроллера на контроллер.

Наличие в сторадже NDO обеспечивает сразу существенный рост “готовности”, или же, иначе, availability. Хотя ряд операций можно было выполнять онлайн и в случае классической 7-mode, например с помощью Cluster Failover, и они тоже могли быть выполнены с минимальным влиянием на доступность, все же были операции, требовавшие даунтайма. Теперь их не будет. Даже отключить дисковую полку на работающем сторадже теперь можно “на ходу”.

Только в Clustered Data ONTAP появились новые фичи, добавленные за последние несколько лет, например это SMB 3.0, pNFS (NFS 4.1) и некоторые другие возможности.

В Clustered Data ONTAP теперь есть нормальный multipathing и ALUA для iSCSI. А также QoS, BranchCache, Access-based Enumeration для SMB, SSL-secured LDAP, IPv6.

При этом сохранилась большая часть фич, за которые мы знаем и любим “классический” Data ONTAP, такие как снэпшоты, дедупликация, thin provisioning, клоны, IP-based репликация, RAID-DP, FlashCache и FlashPool. Правда пока еше некоторые фичи остаются в списке work in process, из наиболее заметных это Metrocluster и синхронная репликация, а также всякие нишевые штучки, типа SnapLock (если вы этм не пользуетесь, то вам это не надо). Metrocluster ожидается уже осенью, в уже упомянутой Data ONTAP 8.3.

В кластере, в отличие от HA-пары контроллеров в 7-mode, у вас имеется глобальное пространство имен для NAS, а не два отдельных файлера, каждый с отдельным IP-адресом и своим набором ресурсов, например сетевыми шарами. Даже несмотря на то, что файловая система при этом все равно остается “controller-bound”, и, допустим, один файл не может лежать одновременно, кусками, на нескольких контроллерах (почему это так, и что мешает сделать по-другому я уже как-то писал), такая штука сильно упрощает работу с большими NAS-системами.

Вы можете строить многоузловые кластеры из разных контроллеров, с разными дисками на них, и, тем самым, создавать сложные инфраструктуры хранения. Без прерывания работы кластера и обслуживания ресурсов мигрирвать данные по кластеру с контроллера на контроллер, с одного типа дисков на другой, при этом с сохранением к ним доступа даже во время миграции. Кластер может обслуживать как NAS, так и SAN, в том числе и одновременно, unified, как привычно это для 7-mode пользователей.

Долгое время одной из основных проблем была высокая цена инфраструктуры, так, до известных пор, поддерживалась только switched конфигурация кластера, при которой ноды кластера были соединены вместе кластерным интерконектом через довольно дорогой сам по себе 10G Ethernet коммутатор Cisco Nexus 5000, причем коммутатор был нужен в любом случае, даже если у вас в кластере было всего две ноды. С тех пор многое изменилось, во-первых у NetApp появился недорогой 10G switch специально для cluster interconnect, во-вторых стала поддерживаться конфигурация, называемая dual-node switchless cluster, которая позволяет перевести в cluster-mode без использования коммутатора, прямым включением “порта в порт” 10G кабеля cluster network обычную пару контроллеров, как раньше она работала в привычном, классическом 7-mode. Такая конфигурация может быть хорошим стартом для тех, кто хотел бы перейти на Clustered Data ONTAP прямо сейчас, “по-быстрому”, без дополнительных инфраструктурных расходов на тот же коммутатор. Причем, что интересно, этот вариант ничуть не лишает вас возможности в будущем перейти на switched cluster, и добавлять к кластеру новые ноды.

“Ну хорошо”, скажете вы мне на это, “но как же нам перейти на Clustered Data ONTAP?”. Ну вот тут-то и скрывается основая закавыка, которая заставила NetApp уже несколько лет тянуть две верси своей OS. Дело в том, что прямого и легкого “однокнопочного” пути миграции из 7-mode в Clustered Data ONTAP на сегодня все еще нет. Да, есть те или иные тулзы, например так называемый 7MMT7-mode Migration Tool, но и он решает только часть задач. Даже не считая того, что он мигрирует только файловые, NAS-данные,  не мигрирует LUN-ы, которые приходится переносить вручную, это в любом случае предполагает, что у вас ест еще NetApp, сконфигурированный в кластер, и на который собствено и происходит перенос. Нет data-in-place миграции. То есть вам надо все ваши данные куда-то смигрировать или забэкапить, потом имеющийся сторадж убить, разобрать, переконфигурировать, создать заново уже в Cluster-mode, и вернуть на него все ваши данные уже в его новой ипостаси.

Почему это так? Дело в том, что несмотря на то, что, как я уже написал выше, у NetApp в Clustered Data ONTAP сохранилось большинство фич “классической” DOT, внутри она сильно и радикально другая. ??зменения были слишком революционны, чтобы иметь возможность делать data-in-place. У NetApp это происходит не слишком часто, впрочем, последний раз такой радикальный переход был, пожалуй, с выходом 7.0 и появлением так называемых FlexVol и aggregate, вместо того, что сейчас носит название Traditional Volumes, и с которыми вы, готов спорить, никогда не встречались в реальной жизни (при этом оно, к слову, до сих пор существует в системе).

Если вы не клиент NetApp и покупаете первый свой сторадж, то у вас все просто на самом деле. Вы можете заказать сразу систему в Cluster-mode, получить ее, и начинать работать, уже не думая ни о каких миграциях.

Сложнее обстоит дело, если у вас уже есть работающая развернутая система с данными. Причем, как часто бывает, для миграции нет ни времени ни средств. Для таких пользователей у NetApp в России есть интересное предложение, и о нем мы поговорим в одном из следующих постов.

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

Во-первых, NetApp подготовил специальный сайт, ориентированный на администраторов, знакомых с системами 7-mode, и собирающихся переходить на c-mode. Это прекрасная стартовая страница, на которой собрано множество линков на документацию по всем аспектам миграции.

image

Во-вторых, стоит начать с установки на виртуальную машину так называемого NetApp Simulator в Cluster-mode. NetApp Simulator – это код Data ONTAP, выполняющийся в виртуальной машине как Virtual Appliance. Он несколько ограничен, чтобы не было нездорового соблазна использовать его для продакшна, но при этом внешне, со стороны интерфейса управления и логики работы, полностью выглядит как система хранения. К симулятору можно подключать System Manager и любой прочий софт, он имеет полноценную админскую консоль, выполняет все действия также, как реальный сторадж, на нем, например, сейчас проводят авторизованные учебные курсы в учебных центрах. Поэтому развернуть Simulator и посмотреть, как выглядит “внутри” Clustered Data ONTAP, будет очень полезно. Тем более, что именно консоль администратора изменилась радикально.

Дело в том, что “классическая” консоль 7-mode, она, все же, привычная, родная, но довольно примитивная, по факту. Мы, админы NetApp, с ней сроднились, но, откровенно говоря, консоль без автодополнения, без иерарихической структуры команд, это какой-то примитив.

Однако хорошие новости. Новая консоль админа в Clustered Data ONTAP полностью переписана. Автодополнение по табу, wildcards, глобальные команды, иерарихическая структура команд – все это теперь есть.

Плохие новости: многие команды поменялось. Да, в чем-то стало более логично, и, вскоре, вы эту логику поймете, и будете удивляться тому, как вы могли работать в “старой” консоли. Однако для облегченя перехода NetApp подготовил “розеттский камень”, документ, в котором каждой старой команде в консоли 7-mode соответствует команда в Clustered Data ONTAP.

 image

Этот документ поможет разобраться с новой консолью для опытных 7-mode админов.

В третьих, рекомендую внимательно изучить сайт NetApp University на предмет курсов, среди которых есть даже бесплатные web-курсы, которые можно посмотреть в браузере. Например есть бесплатный часовой курс, под названием: Introduction to Cluster-Mode for 7-Mode Administrators, есть пятичасовой, но уже платный Data ONTAP Cluster-Mode Fundamentals. По ссылкам выше, в обоих случаях – описания курсов.

image

Посмотрев курсы, начинайте крутить консоль и System Manager на симуляторе, пробуйте конфигурировать, привыкайте к новому виду системы хранения. В следующих постах я постараюсь рассказать, что NetApp придумал для облегчений миграции на Clustered Data ONTAP для пользователей, и о том, какие подводные камни в плане конфигураций вы можете встретить на этом пути.

Комментарии (10)

  1. bbk:

    Как вариант тем, кто хочет перейти с 7-Mode: можно попросить “взять в тест” систему хранения у одного из дистрибьюторов и осуществить при её помощи переезд на C-Mode. Говорите вашему дисти прямо: мы хотим переехать на C-Mode. Если система будет свободна и на неё не будет “ажиотажа”, то вам конечно же её дадут, тем более нужна она будет не на месяц, а от силы на неделю. А если вы ещё дадите открытый “референс”, то могут и помочь в переезде ;)

    Желательно это проделывать летом, или сразу после нового года, когда у дистрибьюторов “не сезон”, системы хранения лежат и пылятся, не задействованные, на полочках.

  2. bbk:

    Об этом варианте я собирался отдельно рассказать в следующем посте серии :)

  3. Андрей:

    Хочу внести небольшое дополнение: для меня Cluster ONTAP будет закрыта пока она будет требовать отдельного root-агрегата на каждую ноду. На системах с одной-двумя дисковыми полками такие траты просто не разумны.
    Надеемся, что в 8.3 сделают возможность размещения root-данных на агрегатах с данными.

    Роман, что скажете?

  4. Nostromo:

    А синхронная репликация вообще ожидается?

  5. Андрей:

    Про новую схему выделения места под root aggregate я тоже расскажу в одном из следующих постов. Расскажу на пальцах и неофициально, потому что до выхода 8.3 осенью в деталях это рассказывать сложно. Но такая работа ведется.
    Пока же мы идем в теме миграции от общего к частному. Безусловно, для владельцев маленьких малодисковых систем схема с обязательны выделением минимум 3 дисков на контроллер под root aggregate - кажется расточитетьной, но не забывайте, что для владельцев систем с, допустим, пятью полками дискв на контроллер, это будет не настолько критично.

    Nostromo:

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

  6. Odna Ptichka:

    уточню:
    в 8.3.0 будет упрощение ситуации с root-агрегатоми для младших моделей, где это наиболее чувствительно. На остальных системах это будет чуть познее. Но пока до осени говорить рано.

    Так же в 8.3.0 будет доступен метрокластер, обеспечивающий RPO=0. Это ответ на требование синхронной репликации. Но тоже надо ждать деталей не ранее середины осени, как минимум.

    Но это все экстремальные случаи. ?? не стоит на этом зацикливаться.

  7. Артём:

    Роман, где же продолжение?
    Нам, кажется, предстоит миграция на cDOT.
    ?? у нас FC. Для миграции LUN предвидится какое-нибудь решение?

  8. Артём:

    “Сеня, жарьте рыбу. Рыба - будет!” (с) Одесса

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

  9. [...] в прошлый раз мы начали трогать тему перехода с Data ONTAP 7-mode, на Clustered Data [...]

  10. Andrey:

    Можно подробнее об организации c-mode на 2240-2. У нас 10Gb интерфейсы подключены к FI Cisco UCS.
    Вроде можно сделать интерконнект внутри 2240-2.

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