about NetApp

Если вы внимательно читаете директорию блоггеров NetApp на их сайте, то, скорее сего, уже знакомы с Дейвом Хитцем, “первым блоггером NetApp”, сооснователем и вице-президентом компании, много лет (пусть и не слишком часто) пишущим свою “колонку”-блог. Дейв также автор интереснейшей книги “How to Castrate a Bull: Unexpected Lessons on Risk, Growth, and Success in Business”, вышедшей несколько лет назад, в которой он рассказывает о ранних годах и развитии своей компании, и тех уроках, которые он получил за эти годы от жизни, бизнеса и других людей. Я также изредка упоминаю его и цитирую некоторые его записи в этом блоге. А сегодня я вспомнил и нашел его, на мой взгляд, очень важную заметку, с, на первый взгляд, шокирующим названием.

Покупатели - лжецы.

??сточник:
<https://communities.netapp.com/community/netapp-blogs/dave/blog/2006/09/22/buyers-are-liars>

Потребитель всегда прав, конечно, но делать так, как хотят пользователи, с этим всегда проблемы, потому что они лгут. Я впервые услышал фразу"покупатели - лжецы" от раздраженного продавца. Многие продавцы знают покупателей, которые говорят: "Когда вы сделаете X, то я определенно куплю!", но когда сделан этот X - клиент не покупает.

Наш CTO, Steve Kleiman, привел мне отличный "нетехнический" пример такой ситуации. Он искал дом, и он говорил риэлтерам и агентам, что он хочет дом без лужайки и без высаженных вокруг растений, потому что он ненавидит возню со всем этим. Агенты показывали ему один за другим дома с замощенным кирпичом или залитым цементом дворами, но ему казалось, что все они какие-то холодные и стерильные. Наконец одна женщина-агент показала ему дом, полностью нарушающий все его требования до сих пор, трава и садовые растения повсюду. ?? когда он недоуменно спросил об этом, она сказала: "Не беспокойтесь, я найду вам садовника" . Нетрудно догадаться, что именно этот дом он в результате и купил.

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

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

Как быть в ситуации, когда у нас с одной стороны "Покупатель всегда прав", а с другой в то же самое время - "Покупатели - лжецы"? Мой компромисс тут в том, что они правы в части своих проблем, но я не считаю, что их вариант решения, предложенный нам, есть лучшее возможное решение данной проблемы.

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

Мне приходится сталкиваться с подобной ситуацией очень и очень часто, когда я слушаю просьбы, а, зачастую, и требования пользователей и потенциальных клиентов NetApp.

Диапазон требований самый разный, от: "сделайте нам Infiniband до хостов" и "сделайте интерфейс FC 8Gb на системе entry-level", до: "продавайте SSD поштучно" и "выложите в интернет полный прайс, чтобы мы могли сами конфигурировать себе системы", завершая все это магической, на их взгляд, формулой: "?? вот тогда мы точно купим".

Увы. ?? вот в заметке Дейва выше хорошо показано почему "увы", и почему NetApp не делает что-то немедленно, по требованиям пользователей, несмотря на то, что "покупатель, безусловно, всегда прав".

Что-то как-то не получилось у меня опубликовать вторую часть "на следующей неделе", как я было пообещал в конце части первой. Так получилось, что я понял, что статья получается объемной, многие вещи требуют "экскурса и дискурса", а объяснить на пальцах понятно их не получается. Но когда я начал регулярно находить в поиске запросы "запускаем новую систему хранения часть 2 site:blog.aboutnetapp.ru", я понял, что тянуть дальше нельзя.

Посему, вот вам вторая, а еще, может быть, даже и третья далее часть.

Остановились мы в прошлый раз на процедуре начального запуска. Железка поставлена в стойку, ей задан IP для конфигурирования, и проведена самая первая, базовая настройка только полученной системы, к ней уже можно подключиться с помощью System Manager, через веб-интерфейс, или же простой консолью по COM-порту или телнетом по сети.

Далее нам надо сконфигурировать собственно объем хранения. ?? тут есть некоторая сложность, о которой я сейчас попробую в общих чертах рассказать.

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

Дело в том, что системы хранения NetApp в двухконтроллерной конфигурации High Available Cluster (HA-cluster, в дальнейшем) используют модель работы "share nothing", и, согласно ей, не используют диски совместно. Каждый из двух контроллеров системы хранения должен владеть своим набором дисков. То есть имеющееся количество дисков должно быть между ними поделено (поровну или нет - об этом далее). Доступ к дискам возможен только через владеющий ими контроллер, и никак иначе.

Конечно, в случае выхода из строя контроллера, как и полагается для HA-кластера, второй, выживший контроллер, перехватит на себя диски вышедшего из строя, но только в случае неработоспособности, выхода из строя контроллера. Когда контроллер работает нормально, то доступ к дискам, "приписанным" к нему, осуществляется только через работающий контроллер-владелец . Это необходимо для правильного диспетчерирования запросов чтения и записи данных с дисков.

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

Так что, в общем случае, вы можете вообразить себе двухконтроллерную систему NetApp как два отдельных (пусть и связанных) файловых сервера NAS, например, каждый со своим набором ресурсов, каждый со своим IP-адресом, по которому происходит обращение, и так далее. В случае SAN это также происходит сходным образом.

??з этого следует, что, по сути, в случае двухконтроллерного NetApp FAS2020 вы получаете не одну систему хранения на 12 дисков, а две на 6 дисков каждая (или 3 и 9 дисков, или 5 и 7 дисков, но всегда две). ?? это довольно существенный момент, который требует осознания. Более того, нельзя отдать одному контроллеру все 12 дисков (это можно в случае одноконтроллерной системы, но не двухконтроллерной, в которой второй контроллер требует наличия хотя бы одной RAID-группы минимального размера (2 диска в RAID-4) и хотя бы одного hotspare, так как на этой группе он должен записать свои собственные конфигурационные данные, иначе он не сможет загрузиться, просто не с чего.

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

Сейчас же мы перейдем к конфигурированию.

??так, мы, руководствуясь частью первой установили систему физически и провели первое включение. Теперь, если вы посмотрите на видимые системе диски, вы увидите, что каждому контроллеру доступен свой набор дисков. Скорее всего вы получите с завода систему, сконфгурированую в виде 5 дисков доступных одному контроллеру и 7 - другому (по крайней мере я видел именно такой вариант поставки FAS2020A).

Если вы читаете этот блог давно, то уже знаете, что такое у NetApp так называемый aggregate. Это структура, в которую включаются физические диски, приписанные одному контроллеру, и которая объединяет RAID-группы, к созданию которых администратор системы хранения не имеет непосредственного доступа. Поверх структуры aggregate уже располагаются непосредственно тома (volumes типа FlexVol), на томах qtrees и в них, или непосредственно на томах - LUN-ы, если вы используете NetApp как SAN-сторадж, или же network shares, если используете его как NAS. В общем яйцо в утке, утка в зайце, заяц в сундуке :)

Но в основе всего - aggregate. Несмотря на то, что в системах NetApp осталась legacy-возможность использовать "классические" RAID, это осталось "для совместимости", и нет совсем никаких причин этим пользоваться сегодня.

Будем пользоваться FlexVol и aggregates.

Два основных преимущества aggregate и его использования заключается, во-первых, что при этом операции ввода-вывода распределяются равномерно по всем входящим в него дискам, даже если вы используете маленький том на несколько десятков мегабайт, или несколько таких томов, то все они будут физически "размазаны" по всем дискам aggregate, с соответствующим положительным эффектом на их быстродействие. ??, во-вторых, он позволяет создавать тома произвольного размера, отвязавшись от размеров физических дисков и RAID-групп.

??з пункта 1 следует естественный вывод, делать как можно большие аггрегейты, из максимально доступного количества дисков.

В некоторых руководствах NetApp, ориентированных, прежде всего, на большие системы с сотнями дисков, вы можете встретить рекомендации создавать более одного aggregate, например выделять на отдельный aggregate так называемый root volume, на котором находится директория /etc внутренней файловой системы и ее настройки, а также создавать отдельные aggregate для сильно различных видов паттерна нагрузки (например отделять базу данных, с обычно random read/write access, от ее логов, с sequental write), но это рекомендации, повторюсь, для "хайэнда", для систем с сотнями дисков, когда эти рекомендации действительно дают заметный эффект. Если вы запускаете систему с количеством дисков в пределах пары десятков, безусловно наилучшим выбором будет помещать все диски в один большой aggregate, где будут находиться все тома пользователя, включая и root vol. Дробя диски по нескольким aggregates при небольшом количестве этих дисков, следуя рекомендациям для "старших" систем, вы скорее ухудшите ситуацию, уменьшив количество дисков, по которым удастся размазать ввод-вывод, чем улучшите его изолируя трафики.

Поэтому решим использовать один aggregate на контроллер (соответственно, два на кластерную пару, по одному на каждый контроллер). Поскольку вы систему уже запустили, этот aggregate у вас уже создан, на нем помещен системой root volume.

Обычно он называется aggr0, и я предлагаю, если у вас остались невключенные в него диски, добавить их в него командой aggr add (диски). Сделайте то же самое на втором контроллере.

Сейчас структура данных на вашей системе хранения выглядит так:

Обычно том vol0, в котором по умолчанию располагается root vol и директория /etc с настройками внутренней OS Data ONTAP делается с большим запасом. Если вам жалко места, то можете безопасно уменьшить размеры тома vol0, например для различных версий Data ONTAP и разных систем рекомендуется его размер от 10GB для FAS2020, 16GB для FAS2040 (для Data ONTAP 7.x), и до 250GB для старших систем под версией 8.х OS Data ONTAP.

На root vol, кроме настроек, также хранятся прошивки полок и дисков, обновляемые автоматически, а также должно быть место для аварийного сброса kernel dump в случае каких-то нештатных ситуаций.

Все же остальное место на aggregate, за вычетом примерно 10%, которые рекомендуется не занимать для облегчения жизни внутренних процессов и правильной и беспроблемной работы, например, фонового оптимизатора структур WAFL, можно использовать под хранения ваших данных в одном или нескольких томах. Хотя размер тома можно задать и сразу, во многих случаях имеет смысл настроить его на автоматическое увеличение, тогда том будет автоматически расти, по мере заполнения его данными, пока хватит места на хранящем его aggregate, а свободное место не будет заниматься на "хранение нулей", если вы можете отдать его более нуждающимся задачам. Эта настройка называется space reservation (none или file), а возможность автоматического роста тома - volume autogrowth, которую можно задать с желаемым шагом приращения.

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

А в следующей части мы рассмотрим как создавать сетевые ресурсы для NAS и LUN-ы для SAN.

По умолчанию, Data  ONTAP генерирует уведомление (trap) в SNMP, а также записывает сообщение в логах, когда заполненность тома превышает пороговую величину. По умолчанию существует два порога: “Nearly Full” и “Full”. Первый по умолчанию установлен на значение 95%, а второй – на 98% от емкости тома.

Вы можете изменить эти значения, или же вовсе выключить их. Например, иногда это бывает полезным, если у вас на томе располагается один space-reserved SAN LUN, и он занимает практически все пространство тома, но не растет, поэтому уведомление о том, что ваш том “всегда полон” не несет полезной информации, а только загромождает логи.

Для того, чтобы именить значения порогов на нужные вам, надо сделать следующее:

Войдем в режим повышенных привилегий:

netapp> priv set advanced
netapp*>

Будьте внимательны, в режиме повышенных привилегий вам становятся доступны некоторые команды, потенциально способные серьезно повредить данные! Нахождение в повышенному уровне привилегий индицирут звездочка в системном “промпте”.

Установим нужные нам значения. Например, пусть это будут 85% и 99%. Помните, что баловаться с системным реестром в Data ONTAP также опасно, как и с реестром Windows!

netapp*> registry set options.thresholds.fsFull 99
netapp*> registry set options.thresholds.fsNearlyFull 85

Можно и вовсе выключить эти уведомления, задав заведомо недостижмый уровень заполнения, больше 100%, например – 101%

netapp*> registry set options.thresholds.fsFull 101
netapp*> registry set options.thresholds.fsNearlyFull 101

Обратите внимание, что парамеры fsFull и fsNearlyFull – чувствительны к регистру.

Проверим, что все установилось так, как мы хотели:

netapp*> registry walk options.thresholds

Вернемся в стандартный уровень привилегий:

netapp*> priv set
netapp>

Готово. Теперь Data ONTAP будет генерировать SNMP traps о заполнении тома по достижении заданных нами величин (или не генерировать их вовсе, если мы их установили на 101%).

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

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

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

Arista Networks 7050Q-16 | 16-port 40 GbE switch

Arista 7050 Series Advantages

Scalability

• Supports dense virtualization, big data and storage in a flat 2-tier Leaf/Spine design
  • 128K MAC entries
  • 50,000 IGMP groups
  • 16K IPv4 Routes
  • 16K IPv4 Host Routes
  • 8K IPv6 Routes
  • 8K Multicast Groups
  • 32-way ECMP

UPD: Как заметили в комментариях - есть аналогичный от IBM, уже, в отличие от Arista, доступный в России: IBM System Networking RackSwitch G8316 http://www.redbooks.ibm.com/abstracts/tips0842.html?Open
35 тысяч без кабелей

В марте 2012 года, по всей видимости, пройдет окончательную ратификацию “в органах” новая версия протокола NFS – NFSv4.2.

Я уже рассказывал о том, как пару лет назад была выпущена v4.1, главным нововведением которой стал протокол pNFS или Parallel NFS (вопреки модным тенденциям сегодняшнего IT, даже такие значительные изменения, как pNFS, не удостоились v5.0, а считаются всего лишь минорными изменениями версии 4). Про pNFS я тоже уже писал немного, если кому интересно – отсылаю к прошлым постам, если вкратце, то это модификация файловой системы NFS, позволяющей ей работать на параллельном кластере связанных хранилищ, подобно Lustre, Hadoop или GPFS. А сегодня мы собрались для того, чтобы посмотреть на то, что появилось в v4.2. Добавления не настолько глобальные, как в 4.1, но достаточно интересные.

Server-Side Copy (SSC) – это механизм, который позволяет организовывать копирование данных между двумя серверами, не через инициировавшего копирование клиента (чтение на клиента блока с сервера A – запись этого блока на сервер Б, и так далее, пока весь файл не скопирован), а непосредственно. Это чем-то напоминает возможно знакомое кому-нибудь копирование FXP, для двух поддерживающих эту функцию серверов FTP, когда клиент, по командному каналу, указывает для двух серверов, что они должны передать друг-другу файл, после ченго может отключиться, коммуницировать и передавать файл будут два сервера без участия инициировавшего клиента.

Такая возможность значительно снижает нагрузку на канал к клиенту для объемных копирований, например для операций, подобных Storage vMotion, когда содержимое одной VM c одного стораджа, должно быть перенесено на другой сторадж. Теперь это смогут сделать два стораджа, поддерживающие NFS v4.2, самостоятельно, без участия клиента, средствами самого протокола NFS.

Guaranteed Space Reservation – несмотря на то, что thin provisioning для больших инфраструктур это благо с точки зрения эффективности расходования пространства, это большая забота администраторов, в особенности для быстро и непредсказуемо растущих сред. Хотя Thin Provisioning и дает большой выигрыш в расходовании места, за ним “нужен глаз да глаз”. К сожалению до сих пор NFS не предлагал возможности зарезервировать пространство для файлов. Размещение файлов на NFS всегда было thin. Если вы по каким-то своим причинам не хотели использовать thin-модель, то есть занятие места по фактически записанному в файл, а хотели заранее зарезервировать пространство на NFS-хранилище, то у вас не было выбора, а теперь он есть. Guaranteed Space Reservation позволяет, в рамках протокола и файловой системы NFS, создать зарезервированный объем файла, даже не осуществляя в него фактической записи.

Hole-punching. Как вы знаете, одной из наиболее значительных проблем thin provisioning, является проблема “разрастания” thin-файла или раздела (например файла диска виртуальной машины), внутри которого удаляются данные. К сожалению, не имея “арбитра” на уровне приложения, OS, или файловой системы, сторадж не может узнать, вот эти вот блоки, они стерты и больше не нужны, или просто в них давн не пишется, а на самом деле данные в них ценные и их освобождать нельзя. Отчасти эту проблему можно решить, принудительно записывая нули (что, кстати, нынешние файловые системы не делают сами, просто помечая файл у себя как “удаленный”), и считать, что то, где принудительно записаны нули – стерто, и ег можно освободить, и не держать внутри thin-тома, а отдать такое “зануленное” место желающим. Однако общего, стандартного механизма пока не было. А теперь он есть. Начиная с v4.2 при работе по NFS можно обнаруживать такие разрозненные пустые пространства от стертых данных, и освобождать его, “сжимая” файл.

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

Application Data Blocks (ADB) – это механизм для приложений определить некие блоки данных, чтобы затем можно будет заполнять “по шаблону”. Например приложение желает заполнить выделенную область данных определенной сигнатурой. “Классическим образом” вам пришлось бы передать по сети и записать на диск ровно столько блоков, сколько нужно для заполнения нужных областей. Теперь же приложение может определить блок данных как Application Data Block, и заполнить область (с точки зрения приложения) просто указав на этот блок как предопределенный ADB для этой области. Физическое заполнение при этом не происходит, но приложение, обратившись к области данных, получит именно ожидавшееся содержимое.

Aplication I/O Hints – это указание приложением стораджу, средствами протокола, на характер считывания данных с диска. Например: следующие данные будут читаться последовательно, поэтому, пожалуйста, включите на сторадже read ahed. ??ли, наприме: следующие данные мы будем читать несколько раз подряд. Поэтому включите их постоянное хранение в кэше. ??ли данные будут записаны, но читать пока мы их не планируем, поэтому не занимайте место в кэше под них. ?? так далее.

Когда все это богатство ждать? Ратификация стандарта ожидается уже в марте, так как одним из “двигателей” рабочей группы NFS являются специалисты NetApp и EMC, то в этих продуктах новые возможности будут реализованы в скором времени после ратификации стандарта. Насколько будут востребованы новые фичи на стороне клиента – ну тут решать стороне клиента, то есть, в конечном счете – вам.

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

Так, например, как-то я там обнаруживал NetApp System Analyzer for CIFS, а также архиполезный набор утилит na_stats. А на днях автор блога Geek ONTAP показал еще одну интересную утилитку – NetApp Storage Security Editor.

Если вы используете системы NetApp как CIFS-сервер, и вынуждены часто строить сложные ACL для разграничения доступа, то вам должно быть такое интересно. Этот инструмент позволяет создавать описания настроек доступа для ресурса на языке SDDL.

SDDL – Security Descriptor Definition Language – язык описания дескрипторов доступа, позволяющий создавать строки, описывающие права доступа на ресурсы. Язык этот лишь слегка проще конфигурационного файла sendmail, поэтому наличие хорошего инструмента, позволяющего на нем писать совершенно необходимо.

Записанную в файл строку на SDDL можно импортировать в NetApp с помошью консольной команды fsecurity apply.

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

К сожалению утилита находится в крайне ранней стадии развития, поддерживает пока только NTFS-security, а в нем storage-level и file/directory-level security, также не поддерживаются не-ASCII символы во вводе.

Подробнее смотрите на странице инструмента (нужен логин в NetApp Support (NOW)).

А тем временем, в выходные, выкатилась, наконец, Phase 2 обновления самого важного для пользователя сайта NetApp – NetApp Support Site (http://support.netapp.com/), бывшего “NetApp on Web”, NOW (http://now.netapp.com/).

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

Скоро сказка сказывается, да нескоро дело делается. Весь прошлый год в NetApp работали над обновлением этого “портала поддержки пользователей”, и вот, наконец, в начале марта, все новые возможности были выпущены “в продакшн”.

По работе с новым порталом выпущен специальный 111-страничнй документ, в котором многое расписано подробно и детально. Но начать использовать его можно и “методом тыка”. Попробуйте, нам теперь с этим жить.

Я уже рассказывал о том, что, начиная с 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.