about NetApp

Вы наверняка уже знаете, что такое снэпшоты в NetApp, и как их используют, это, если вкратце, для вновь подключившихся мгновенная “виртуальная копия” даных диска или тома, “снимок состояния дисков” (отсюда Snapshot – “фотоснимок”). Принципиальная реализация в решении NetApp от всех прочих реализаций под тем же именем у других производителей, в том, что они не тормозят систему и занимают на диске место как differential copy, то есть только измененные с предыдущего снятия снэпшота блоки.

У NetApp есть два способа восстанавливать данные на дисках из созданных снэпшотов, это простым копированием нужного файла из псевдо-директории .snapshots на его прежнее место, и с помощью команды snap restore. Последняя использует технологию SnapRestore, это отдельно лицензируемая, но, наверное, почти у всех имеющаяся функция, которая используется во многих продуктах NetApp, например в SnapManager for Apps.

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

Однако в использовании SnapRestore есть один, как оказалось, довольно неочевидный для новичка “факап”, как выражается современная молодежь.

Дело в том, что SnapRestore восстанавливает из снэпшота файловую систему соответствующего тома целиком, на момент создания соответствующего снэпшота. “Целиком” означает вообще целиком, совсем целиком. ?? набор доступных после восстановления снэпшотов для этой файловой системы – тоже.

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

Вы выбираете, например в SnapManager, или же просто вручную, снэпшот недельной давности, и делаете ему snap restore vol1 weekly.1

Вы откатываете состояние тома на состояние неделю назад. Отлично, неделю назад проблемы не было. Но восстанавливать целую неделю работы слишком долго. Может быть три дня назад тоже еще не было ошибки? Надо восстановиться из более нового, трехдневного, или даже вчерашнего.

Опа. А у вас нету на томе снэпшота “три дня назад”. Том восстановился на состояние “неделя назад”, и никаких более новых, чем “неделя назад” снэпшотов на нем еще нет. Вы же помните, я не зря сказал, что восстанавливается том целиком, включая и состояние снэпшотов на нем.

Что делать: Ну, во-первых хорошо понимать то, как работает механизм снэпшота на NetApp. Не восстанавливать через snap restore том целиком, если есть необходимость оставить доступными более новые, чем точка восстановления, снэпшоты, или ради всего нескольких файлов. Наконец, пользоваться SnapVault, средством для “резервного копирования” снэпшотов на другой сторадж NetApp.

О любопытной функции внутри Data ONTAP прочитал недавно в блоге ntapgeek. Эта фича называется WAFL File Folding и позволяет экономить место на дисках для файлов, отдаваемых по протоколу CIFS.

Принцип работы File Folding таков. Как вы уже знаете (а кто не знает – идите и читайте), все перезаписи данных на WAFL осуществляются, согласно конструкции файловой системы, таким образом, что они не меняют собственно содержимого блока данных в файле, а записываются в отдельный свободный блок, куда переставляется “указатель”-inode. Это позволяет быстро и просто делать снэпшоты, так как в WAFL не нужно, как во всех прочих реалиациях снэпшотов, переносить содержимое перезаписывамых блоков в отдельное место. Единожды записанный блок, помещенный в снэпшот, уже никак не будет изменен, так устроена FS.

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

Я теряюсь в догадках, что это за операция такое проделвывает, но факт того, что это сделано именно для CIFS, подсказывает мне, что что-то в CIFS любит перезаписывать целиком файлы, даже, например, при незначительных изменениях в нем. Например, представм, что это какой-нибудь Winword, и в нем большой файл, в котором мы поправили запятую, и нажали “сохранить”. ?? весь этот файл, блок за блоком, перезаписался поверх теми же данными, что были (за исключением этой запятой). Не знаю, возможно кто-то подскажет, о чем тут идет речь.

Так или иначе, в результате такой перезаписи, мы будем иметь на дисках два файла, из равного набора блоков, один в снэпшоте, а один в собственно файловой системе, ведь WAFL не видит, что там такое произошло с файлом. Попросили из приложения перезаписать стотыщ блоков – вот вам стотыщ свободных блоков, пишите в них, ведь исходный файл в снэпшоте, блоки его нельзя трогать.

Вот для решения такой проблемы и предназначена малоизвестная фича, под названием WAFL File Folding.

Включают ее командой:

> options cifs.snapshot_file_folding.enable on

и эта команда делает следующее:

В Data ONTAP начинает работать процесс, который физически сравнивает в перезаписываемых файлах блоки данных с соответствующими блоками в наиболее свежем снэпшоте с этого файла. ?? если блоки оказываются идентичными, то просто указывать вместо таких “псевдоизмененных” и “псевдоперезаписанных” блоков, на блоки в крайнем по времени снэпшоте. Это что-то отдаленно напоминает дедупликацию, но там похожий процесс работает только внутри активной файловой системы, между разными в ней файлами, а тут – между пространством активной файловой системы и пространством самого свежего снэпшота.

Теоретически, как и любой процесс экономии пространства, этот процесс дополнительно нагружает процессор и занимает память задачей попарного сравнения блоков. Однако, если этот процес достигает определенного для него лимита использования RAM, он приостанавливается, и ждет ее освобождения, так что в принципе страшного ничего произойти не должно.

Утверждается, что фича эта тихо живет уже довольно давно, полагаю она была добавлена по заказу какого-нибудь Особо Любимого Клиента и его специфической задачи, и не особенно раскручивается для прочих. Данная опция существует в Data ONTAP вплоть до версии 8.1 в 7-Mode.

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

UPD: из комментариев к “зеркалу” данного поста на https://communities.netapp.com/groups/netapp-ru (если вы там еще не были - сильно рекомендую сходить и ознакомиться, это форум и сообщество по NetApp, созданное мною на официальном сайте NetApp, чтобы было удобнее вести дискуссии и обсуждения, в формате форума, и так далее. Я туда также зеркалю свои посты отсюда).

“Ну именно офисные приложения word и exel и перезаписывают файлы целиком. При открытии файла на редактирование ms офис создает новый временный файл и работаем в нем, а операция сохранения это удаляем старый, копируем новый. То есть файл всегда пишется целиком. А так как на CIFS разделах делать снепшоты очень удобно (в винде встроены механизмы отслеживания версионности файлов и нет необходимости привлекать администраторов чтоб открыть любой файл из предыдущих версий) то начинает быстро “распухать” раздел по них.

Поэтому на томах доступных для CIFS где работают с офисными приложениями и снепшоты делаются по сколько раз в день, что затрудняет возможность проведения дедупликации перед ними, данная опция маст хэв :) “

Наверняка вы уже слышали о том, как NetApp использует flash-память в форме памяти, а не эмуляции диска (SSD), я уже не раз рассказывал о том, что такое Flash Cache (ранее PAM-II), как он работает и насколько значительное дает преимущество с точки зрения производительности. С использованием обширного кэша во flash-памяти построен также нетапповский метод Virtual Storage Tiering, по многим своим параметрам превосходящий “классический” tiering, путем физического переноса данных между разными типами дисков.

Увы, все это, про “преимущества и производительность”, лишь слова, так как “потрогать руками”, не купив, Flash Cache довольно сложно, ведь ни один из российских партнеров, как я знаю, не держит систему Flash Cache для триала и демонстраций.

Однако, есть хорошая новость – на любой системе хранения NetApp вы можете оценить эффект от работы Flash Cache даже не имея ее физически, с помощью встроенного средства, под названием PCS – Predictive Cache Statistics.

Continue reading ‘Predictive Cache Statistics (PCS)’ »

Для начала несколько слов о том, что такое собственно этот VASA Provider.

VASA – это новая придумка VMware для больших сред виртуализации. Когда у вас всего один-два стораджа и всего несколько датасторов, то вам это не надо. Вы и так помните что у вас где. А вот когда систем хранения у вас будет с десяток, и несколько сотен датасторов,  несколько человек админов в три смены, вот тогда вам захочется как-то разбираться, что у вас где, и, по-возможности, быстро.

Continue reading ‘Установка NetApp VASA Provider’ »

Я уже рассказывал о том, что, начиная с ONTAP 8.х, и на 64-bit aggregate, у WAFL есть механизм компрессии хранимых на дисках данных. Механизм онлайн-компрессии сравнительно хорошо знаком пользователям, так как, например, давно поддерживается на NTFS. Однако, по моим наблюдениям, используют его не так часто, боясь его заметного влияния на производительность, и большей нагрузки на процессор сервера. Следует, тем не менее, отметить, что для современных процессоров, производительность которых сильно выросла со времен Stacker и MS DiskDrive, такая дополнительная нагрузка на процессор операций запаковки-распаковки весьма незначительна по абсолютной величине, но при этом значительно уменьшает объемы дискового трафика. Например, если компрессия, вдвое уменьшает “футпринт”, то есть хранимый объем данных, то за счет сравнительно небольшого увеличения (проценты, как правило) нагрузки на процессор, мы можем вдвое увеличить производительность чтения-записи, так как объем данных считываемых и записываемых на диск уменьшается, в нашем случае, вдвое, данные попадают на диск и считываются с него всегда уже сжатыми.

Так что влияние компрессии на производительность может быть совсем не столь однозначно отрицательным.

Но любопытно подробнее разобраться с тем, как реализована компрессия у NetApp. Дело в том, что для файловых систем, хранящих данные в фиксированных блоках-“кластерах” файловой системы, компрессия внутри этих кластеров, зачастую, бесполезна. Данные не могут занимать места менее одного блока (для WAFL – 4KB), то есть экономия места внутри блока никак не может быть использована. Сложность вызывает также работа с большим файлами. Например, в случае “обычной” компрессии файла архиватором типа ZIP, и прочими аналогичными, нам, часто, для того, чтобы извлечь, изменить или записать данные в середину большого файла, приходится распаковать и перепаковать его целиком. Это влечет за собой большую затрату времени и занятой памяти RAM. То что годится для оффлайновых архиваторов – не подходит для онлайн-компрессии.

При создании механизма компрессии инженерам NetApp пришлось решить как эти, так и многие другие проблемы.

Первый интересный с точки зрения “техники процесса” момент организации работы компрессии состоит в том, что алгоритм компрессии работает не с “файлом” целиком, а бъет его на фиксированные сегменты, под названием “Compression Groups”. Каждая Compression Group содержит 8 секторов WAFL, размером 4KB, и имеет размер 32K.

Каждый файл, размещенный на томе, со включенной компрессией, рассматривается алгоритмом компрессии как разбитый на некоторое количество независимо обрабатываемых Compression Groups (CG). Например файл, размером 60KB будет содержать две CG, одну размером 32KB, и одну неполную, размером 28KB. При этом компрессия не применяется к файлам, размерам 8KB и менее.

Каждая CG обрабатывается отдельно, а, при необходимости считывания части файла “из середины”, считывается и распаковывается не весь файл, а только необходимая Compression Group в нем.

Но это еще не все интересное.

Выглядит довольно очевидным решение как-то определять факт невозможности или низкой эффективности сжатия для данных, и данные, которые не жмутся (например JPEG, ZIP, MP3 или AVI) не жать вовсе, сэкономив на этом ресурсы процессора. Ведь в противном случае процессор будет полноценно занят сжатием-разжатием содержимого Compression Groups ради жалких долей процента результата. ??менно так поступили в NetApp. Перед операцией для Compression Group определяется эффективность сжатия, и, если результат получается ниже 25% (менее четверти содержимого группы, то есть менее 8KB, удается высвободить в результате компрессии), то сжатие для данной группы не прозводится вовсе и она записывается неизменной.

Наконец, любопытным решением является разделение операций на онлайновые (inline), то есть производящиеся непосредственно “на лету”, по ходу поступления данных, и постпроцессные (postprocess). Постпроцессный метод уже широко применяется в механизме дедупликации, и позволяет свести к минимуму влияние процесса дедупликации на работу системы и ее производительность.

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

Постпроцессная компрессия выполняется по тому же расписанию, что и дедупликация, и запускается после выполнения процесса дедупликации для данного тома. Стоит также отметить, что дедупликация и компрессия возможны на одном и том же томе, прекрасно сосуществуют, и не отменяют одна другую. Более того, компрессия после дедупликации вполне возможна. Представьте себе множество виртуальных машин, которые хорошо дедуплицируются, так как содержат одно и то же содержимое, и дедупликация позволит нам хранить не сто виртуальных машин, а одну (и некоторое количество сохраненной “дельты” между этой VM и сотней индивидуальных VM с дедуплицированным нами содержимым) . Но ведь файлы Program Files или пользовательские файлы этого единственного экземпляра, как правило, можно еще и сжать раза в полтора! ?? эта компрессия будет осуществлена над уже дедуплицированным содержимым.

Следует также отметить, что компрессия, так как она осуществляется над фиксированными Compression Groups, не мешает работе дедупликации. Два идентичных и хорошо дедуплицируемых файла, будут разбиты на одинаковое количество Compression Groups, и получившиеся 32KB группы после компрессии останутся по-прежнему идентичными и по прежнему дедуплицируемыми.

Хотя в NetApp предприняли значительные усилия, чтобы повысить эффективность и постараться обеспечить наименьшее влияние на производтельность при работе компрессии, какое-то влияние на производительность (зависящее от множества факторов, как то объемы записей, характер доступа, и так далее) все равно, безусловно, будет иметь место.

Лаборатория NetApp опубликовала следующие оценки производительности для системы FAS6080 (на сегодня это уровень хорошего такого midrange класса FAS3240, пожалуй). Для такой системы были достигнуты показатели работы постпроцессной компрессии на уровне 140MB/s для одного процесса, и 210MB/s максимальной производительности для нескольких процессов одновременно. На загрузке характера файлового сервера, с нагрузкой на процессор не более 50%, задачи inline-компрессии увеличивали нагрузку на менее чем 20% для датасетов, сжимающихся минимум на 50%.

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

Я бы хотел также упомянуть, что имеющаяся у партнеров NetApp утилита SSET (Space Savings Estimation Tool) в текущей версии позволяет провести оценку эффекивности дедупликации ?? компрессии на реальных пользовательских данных, вычисляя на них результат работы алгоритма NetApp. Эта утилита запускается на реальных данных пользователя, работая в read-only, и, никак не изменяя и не повреждая эти данные, позволяет оценить результат дедупликации и компрессии даже без использования стораджа NetApp, например до его покупки. Эту утилиту можно просить у партнеров, она имеется для Linux и Windows.

??так, в постах о том, как работает Cluster-mode я уже упоминал то, как работает доступ к данным на кластере. А сейчас давайте рассмотрим подробнее процесс создания LUN-а на кластере, для обычного блочного подключения его с хост-сервера Windows.

Несмотря на то, что System Manager 2.0 уже умеет работать с системами в Cluster-mode, мы посмотрим на то, как создаются объекты хранения данных Data ONTAP 8.1 Cluster-mode из консоли. Это нагляднее и проще заскриншотить.

Создадим Vserver. В предыдущем посте я рассказывал что это и зачем нужно в Cluster-mode. А вот как он создается.

Создадим Vserver под названием MyVserver на aggregate с именем aggr1:

Допустим, мы хотим обращаться к данным, хранимым на MyVserver по протоколу FCP, для версии 8.1 у нас уже есть возможность работать с данными в Cluster-mode по блочным протоколам. Для этого, включим для Vserver протокол FCP (и проверим его включение):

Target Name это физическое имя (nodename) соответствующего контроллера.

Далее нам нужно создать так называемый LIF – Logical Interface, о котором я уже также упоминал в посте ранее. LIF – это логический интерфейс, который динамически мапится на физический интерфейс того или иного узла кластера, на котором работает Vserver, и через который обеспечивается ввод-вывод данных. Создадим и посмотрим на то, что у нас получилось.

Network Address/Mask эквивалентен физическому WWPN у порта контроллера.

Создадим igroup – специальную группу, в которую включим нужные нам сервера, чтобы ограничить доступ и видимость LUN-ов только необходимыми серверами. Для этого нам понадобится знать имена WWPN тех портов серверов, которых мы назначим в группу, именно по WWPN и будем определять, наш сервер это или нет.

Создадим группу MyIGroup и включим туда FCP WWPN initiator-ов с соответствующих портов.

Наконец, создадим том FlexVol под названием MyVol:

Теперь создадим LUN по имени MyLUN на этом томе:

Смапим LUN соответствующей igroup

А теперь подключаем созданный LUN обычным образом на сервер Windows, с помощью стандартной оснастки Disk Management.

Готово. У нас на сервере подключен LUN по FCP, расположенный в кластере контроллеров NetApp под управлением Data ONTAP 8.1 Cluster-mode.

За основу поста взят пост из блога специалиста NetApp “Pseudo Benchmark”, из которого я позаимствовал скриншоты.

Я уже пару раз рассказывал в этом блоге о том, что такое и зачем используется такая возможность, как Multistore и vfilers. Вкратце – это изолированные jail-подобные “инстансы”, виртуальные стораджи, создаваемые и работающие поверх физического экземпляра Data ONTAP, каждый из которых работает как изолированный “нетапп”, со своим IP-space, своими настройками, и так далее. ??х можно использовать, например, для создания “партиционированных”, изолированных виртуальных стораджей, например вывесить один в DMZ, а другой – использовать во внутренней IT-инфраструктуре, обеспечив с их помощью полную изоляцию и безопасность данных одного vfiler от другого.

С использованием vfilers реализована такая интересная функциональная возможность NetApp, как Secure Multi-tenancy, то есть возможность использовать один физический сторадж для нескольких независимых клиентов, например для “облачного” хранения данных множества пользователей. Каждый клиент такого облачного стораджа получает виртуальный, независимо управляемый пользователем сторадж, логически изолированный от прочих.

В числе прочих возможностей, такой vfiler можно, не прерывая его работу, мигрировать с одного контроллера на другой, используя функциональность, под названием Data Motion for vfilers.

Однако в версии 8.х NetApp пошла дальше. Если для Data ONTAP 7.x Multistore и vfilers это хитрая опциональная фича, то для Data ONTAP 8.x новая инкарнация vfiler, под названием vserver – стандартный и абсолютно необходимый элемент структуры управления и хранения данных.

Vserver – это виртуальный сервер хранения, который размещается на одном или нескольких контроллерах кластера Data ONTAP 8.x, и который может мигрировать, подобно vfilers в Data Motion for vfilers, а для коммуникации с “внешним миром” имеет так называемые LIFs, или Logical Interfaces, независимые от физических портов контроллеров в кластере.

Таким образом, Vservers в Data ONTAP 8.x – это новое воплощение vfiler из ветки 7.x, поддерживающие Cluster-mode, обеспечивающее Single Namespace, существующие поверх одного или нескольких контроллеров кластера, имеющие для соединения с “внешним миром” “виртуальные сетевые интерфейсы” – LIF, гибко (пере)привязываемые к физическим портам контроллера. LIF поддерживают все протоколы доступа к данным в Cluster-mode. Vservers владеют томами FlexVol, могут мигрировать между контроллерами и поддерживают Role-based Access Control (RBAC).

В следующем посте этой тематики я покажу на примерах, как создается Vserver и настраивается доступ к данным в Cluster-mode.

??так, в прошлом посте этой темы я вкратце остановился на предыстории Data ONTAP 8.x Cluster-mode.

Еще в прошлом году я перестал в этом блоге называть “классическую” структуру из двух контроллеров в системах хранения NetApp “кластером”, с тем, чтобы вам было проще “переключиться”. Пару контроллеров под управлением Data ONTAP 7.x и Data ONTAP 8.x 7-mode следует правильно называть HA-pair (HA – High Availability), HA-парой, или, в крайнем случае, HA-кластером, ясно отделяя это от “кластера” в 8.x Cluster-mode. Словом “кластер” у NetApp теперь называется совсем иная структура. Дабы не путаться, буду следовать этому правилу именования и я.

В настоящий момент можно построить кластер, работающий как NAS-сервер (NFS или CIFS) из 24 узлов-контроллеров (nodes), то есть из 12 HA-пар контроллеров.

В версии Data ONTAP 8.1 появлась также поддержка блочных протоколов (iSCSI, FC, FCoE). Однако при использовании блочных протоколов (только их одних, или в комбинации с NAS) максимальный размер кластера на сегодня поддерживается в размере четырех нод, или двух HA-пар. Эта величина, как я думаю, будет расти, как только будет все отлажено и обеспечена надежность, все же 8.1 это первая версия с такой функциональностью, но пока – имейте это ввиду. Связано это, прежде всего, с тем, что файловые протоколы, такие как NFS или CIFS, по сути, полностью управляются и контролируются на стороне стораджа, и проще обеспечить все необходимые процедуры работы и синхронизацию процессов между узлами кластера.

Прежде всего, следует осознать разницу, между понятиями Global Filesystem и Global Namespace.  Data ONTAP 8.1 Cluster-mode это Global Namespace, но НЕ Global Filesystem.
Global Namespace позволяет вам видеть кластер и его пространство, как совокупность нодов его составляющих, как единую “сущность”, целостное пространство, вне зависимости от того где и как хранятся ваши данные. Однако с точки зрения хранения, каждый нод-контроллер, по-прежнему оперирует данными, хранящимися на его aggregates и томах. Один единственный файл не может располагаться более чем на одном aggregate/ноде-контроллере. Также он не может мигрировать, распределяясь частью на одном, частью на другом ноде-контроллере.

Это, как мне кажется, очень важно понимать, поэтому на этом я так заостряюсь.

Безусловно, устройства, реализующие Global Filesystem, имеют в этом месте меньше ограничений (например EMC Isilon с его OneFS это как раз Global Filesystem), однако, в нашем мире, как вы помните, ничего не дается бесплатно, и реализация Global Filesystem влечет за собой ряд весьма неприятных побочных негативных эффектов, в первую очередь для производтельности. Isilon весьма хорош, но он хорош на определенных типах рабочей нагрузки (преимущественно последовательном доступе). Насколько в вашем конкретном случае важна возможность хранить огромного размера файл(ы), превосходящие по размерам емкость дисков, подключенных к одному контроллеру, и распределенные на несколько узлов кластера, и готовы ли вы за такую возможность заплатить ухудшением характеристик рандомного доступа к ним – решать вам. На сегодня на рынке имеется как тот, так и другой вариант.

Преимущество же в производительности довольно убедительно показал NetApp в недавнем тестировании SPECsfs2008 на протоколе NFS, где 24-нодовая система FAS6240 под управлением Data ONTAP 8.1, почти в полтора раза превзошла 140-нодовую систему EMC Isilon S200.

При этом, следует отметить, что, в случае NetApp, тестировался worst case, “наихудший случай” то есть только 1/24 часть всех операций шла на контроллер-owner, 23 из каждых 24 операций шли через “неродные” контроллеры, через cluster network, и не использовались никакие существующие у NetApp средства оптимизации, такие как, например, Load Sharing Mirrors (RO-копии) на “неродных” узлах кластера, которые, безусловно, увеличат производительность в реальной жизни.

Напомню, что тест SPECsfs2008 это классический и авторитетный тест, имитрирующий усредненный типовой файловый доступ по протоколам NFS (и CIFS), сгенерированной смесью операций соответствующего протокола, и там, понятное дело, много операций с метаданными и, преимущественно, рандомный доступ.

??так – Data ONTAP 8.1 Cluster-mode это Global Storage Namespace, но НЕ Global Storage Filesystem. Несмотря на то, что вы видите кластер как единую сущность, отдельный файл, на нем хранимый не может превышать емкость аггрегейта одного контроллера. Однако вы можете получать доступ к данным этого файла через любой из контроллеров кластера. В этом заключается разница между Global Filesystem и Global Namespace.

Второй момент, на котором мне хочется подробнее остановится, это то, как именно строится кластер физически.

Несмотря на то, что, формально, “единицей измерения” размера кластера является одна нода, представляющая собой один физический контроллер, ноды эти всегда включены в HA-пары. По этой причине количество нодов в кластере NetApp Data ONTAP 8.x Cluster-mode всегда четное. Таким образом обеспечивается надежность и высокая доступность (High Availability) ноды, тем же методом, как это делалось для контроллеров в 7.x.

Поэтому вы не можете сделать 5- или 15-нодовый кластер, а 4-, 6- или 16-нодовый можете.

Третий момент, который мне бы хотелось подробнее осветить, есть то, что в настоящий момент NetApp предъявляет довольно строгие требования к оборудованию для реализации кластерных коммуникаций. Для построения Cluster network, то есть внутренней сети самого кластера, в настоящий момент поддерживаются только две модели 10-Gigabit коммутаторов, это Cisco Nexus 5010 (20 портов, кластер до 12/18 нодов) и Cisco Nexus 5020 (40 портов, кластер более 18 нодов), их продает NetApp со своими партномерами, в составе общей квотации такой системы. Причем использовать эти коммутаторы можно только под задачи внутренней кластерной сети, совмещать их с другими задачами, например для подключения в них клиентской сети – нельзя. Даже если там еще остались порты.

Однако есть и хорошая новость. Сейчас NetApp и Cisco, в качестве time-limited promotion, при заказе cluster-mode стораджа у NetApp, отдает необходимое инфраструктурное оборудование за символическую цену 1$ за Cisco Nexus для Cluster network и Cisco Catalyst 2960 для Cluster management network, плюс необходимые SFP и кабеля. При этом цена на систему Data ONTAP 8.1 Cluster-mode из двух нодов, для промоушна, уравнена с ценой аналогичной конфигурации 7-mode, а инфраструктурная часть придет по цене 5$, за пять девайсов (два Nexus 5010, два Catalyst 2960, сет кабелей), плюс сервисные платежи.

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

Купленную по промоушну систему на две ноды можно расширить до 12 нодов (6 HA-pair) докупая только SFP и кабеля.

Структура cluster-mode кластера такова (на рисунке, для примера, показана двухузловая система):

В качестве коммутаторов клиентской сети можно использовать любые коммутаторы, Ethernet или FC, в зависимости от потребностей пользователя.

В качестве коммутаторов Cluster network switch могут использоваться только Cisco Nexus 5010 (для кластеров с числом нод до 12/18) или 5020 (для большего числа нод).

В качестве Cluster Management Switch NetApp рекомендует Cisco Catalyst 2960, но, в настоящее время, не обязывает покупать именно эту модель, при необходимости использовать имеющуюся у клиента иную модель, это может быть оформлено через заведение PVR, специального запроса на проверку и аппрув конфигурации у NetApp. NB: SMARTnet для такого свитча – обязателен!

Cluster Network это выделенная только под эту задачу сеть 10Gb Ethernet. Единственное исключение – FAS2040, которая может использоваться в Cluster-mode с использованием Gigabit Ethernet, но не рекомендуется ее использование с другими контроллерами. Обратите внимание, что даже для 2040 и ее Gigabit Ethernet, другие коммутаторы, кроме Nexus 5010/5020, не поддерживаются!

Ноды кластера могут быть различными по модели. Вы можете объединить в единый кластер любые контроллеры, для которых объявлена совместимость с cluster-mode (с единственным исключением в виде FAS2040, использование которого с контроллерами другого типа не рекомендуется (хотя и возможно), по вышеописанной причине отсутствия портов 10G)

Вы также можете объединить в кластер и системы с дисками различных типов, например вы можете построить систему с дисками SAS, SATA и SSD в рамках одного единого кластера, и организовывать миграцию данных между разными колнтроллерами-нодами и дисками разных типов.

Далее кратко и бегло:

Какие контроллеры в настоящее время поддерживаются для работы в Cluster-mode?

FAS/V62×0, FAS60×0, FAS/V32×0, FAS31×0, FAS3070, FAS3040, FAS2240, и FAS2040.
Для 2040 есть ограничения, связанные с отсутствием 10G Ethernet, для 3040 и 3070 ограничено максимальное количество нодов в использующих их кластеров. Помните, что для работы Cluster-mode нужна пара портов 10G Ethernet и несколько дополнительных портов для сетевых интерфейсов cluster management и сети собственно доступа к данных с клиентов.

Какие возможности “традиционной” Data ONTAP 7-mode поддерживаются, и какие – не поддерживаются?

Поддерживаются:

• Доступ к данным по:
  • файловым протоколам (NFSv3, NFSv4, NFSv4.1/pNFS, CIFS(SMB1.0), SMB2.0 и SMB2.1), c размером кластера до 24 нодов.
  • по блочным протоколам (iSCSI, FC, FCoE), с размером кластера до 4 нодов (кроме FAS2040, FAS3040/3070 и FAS6030/6070, для них SAN в cluster-mode не поддерживается) .
• Репликация SnapMirror – только асинхронная и только Volume SnapMirror. Репликация совместима только между системами Cluster-mode.
• Снэпшоты
• Компрессия и дедупликация
• FlexClone
• NDMP

Не поддерживаются:

• Синхронный SnapMirror, Qtree SnapMirror (сами qtree как объект иерархии поддерживаются), SnapMirror между системами 7-mode и cluster-mode
• SyncMirror
• Metrocluster
• SnapVault
• SnapLock
• IPv6

Каковы основные преимущества и цели системы Cluster-mode?

• Балансировка и масштабирование для больших нагрузок
• Непрерывающее работу наращивание производительности и миграция данных
• Единая, с точки зрения управления и администрирования “сущность” – кластер нодов.
• Поддержка привычных средств и фич NetApp – RAID-DP, FlexClone, Snapshots, SnapMirror Async, дедупликация, компрессия.

Что такое Vserver?

Оставайтес с нами, об этом – в следующих постах :)

Есть/будет ли FlexPod под Cluster-mode?

Пока – нет, но, возможно, будет.

Какие диски и полки поддерживаются?

Все, любые существующие на сегодня в продаже (не поддерживается интерфейсный модуль ESH2 и еще более старые).

Можно ли включать в кластер системы V-series и сторонние стораджи через них?

Да, можно V3200/6200 c EMC DMX4, CX4 и HP EVA. Остальные, может быть, через PVR. Однако даже для перечисленных систем нужна полка с дисками NetApp для хранения root volume.

Каков максимальный размер aggregate?

• 2040/3040/3070 – 50TiB
• 2240 – 60TiB
• 3210/3140 – 75TiB
• 6030/6040/3270/3170 – 105TiB
• 6070/6080/6210/6240/6280 – 162TiB

Каков максимальный размер тома?

Как максимальный размер 64-bit aggregate в 7-mode для соответствующих контроллеров

Каково максимальное расстояние “разноса” нодов кластера?

Максимальное допустимое расстояние от ноды до коммутатора cluster network – 300 метров.
Расстояние между redundant коммутаторами cluster network – 300 метров.
Расстояние между двумя нодами в HA-паре – то же, что и для 7-mode.

FlashCache поддерживается?

Да!

Есть ли non-disruptive upgrade для систем 7-Mode?

К сожалению – нет. Только через полную разборку-сборку.

Есть ли non-disruptive expand или reduce для кластера новыми нодами?

Да.

Можно ли слить вместе два кластера?

В настоящий момент нет, только через копирование, разборку второго и добавление его нод.

Нужен ли коммутатор для Cluster network в случае использования всего двух нод в кластере?

Да, все равно нужен даже для всего двух нод.

Работают-ли на Cluster-mode системах дедупликация, компрессия, thin provisioning, снэпшоты?

Да, все это работает.

Каким образом можно управлять кластером в Cluster-mode?

• GUI: NetApp System Manager 2.0
• CLI: SSH к кластеру, ноде или Vserver
• OnCommand 5.0
• NetApp Management SDK

FilerView (web-интерфейс, встроенный в контроллер) начиная с 8.1 не поддерживается.

Должен ли я управлять каждой нодой в отдельности?

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

Как обеспечивается антивирусная защита хранимых данных для кластера?

Тадааам! Теперь у Data ONTAP есть встроенный в OS движок антивирусного контроля и защиты. В настоящий момент лицензированы продукты Sophos и McAfee

Больше о работе и управлении в кластере – в следующем посте этой серии.

Я уже упоминал, что начиная с DataONTAP 7.3.1 емкость aggregate в системах NetApp FAS рассчитывается исходя из “правильной” usable емкости дисков, “после налогов и вычетов” и без учета дисков parity.

Вот каковы right-sized емкости используемых в системах NetApp дисков, исчисленных в “двоичных” единицах (по основанию 1024):

При дальнейших расчетах также не забывайте про “основание 1024”, то есть, что
1695466 MiB = 1655,7 GiB = 1,62 TiB

При расчетах в “двоично-десятичной” арифметике для перехода от “мегабайтов” к “гигабайтам” недостаточно “сдвинуть запятую в числе на три позиции влево”, помните об этом . Разница между “терабайтом” и “тебибайтом” составляет почти 10%!

Полезное из документации. В таблице ниже приведены оценочные затраты времени на так называемый zeroing (процедуру физического стирания содержимого диска), на процедуру Rapid RAID Recovery (применяемую, когда диск, помеченный неисправным, читается и часть данных с него может быть извлечена непосредственно) и обычного, классического RAID Reconstruction (при котором данные с вышедшего из строя диска пересчитываются из parity).