about NetApp

Тема якобы катастрофического уменьшения usable space по сравнению с raw space на системах хранения NetApp занимает, по популярности, у наших конкурентов, пожалуй, третье место, сразу за страшилкой про "ужасную фрагментацию", и пугалкой про "эмуляцию LUN-ов поверх файлов на файловой системе". Про первых две я уже писал, и не по разу, пришла пора разобраться и с этой.
Основой для поста послужил перевод статьи в блоге Recoverymonkey.

Ранее я уже рассматривал "первую часть" ситуации, то, как образуется usable disk space, то есть та емкость, которая остается для использования на дисках, после того, как мы вычтем из них parity, hot spare и ряд прочих "накладных расходов". Однако это еще не все, определенный объем на дисках также занимают различные структуры данных. Я называю получившееся пространство, после того, как из usable disk space вычтутся прочие накладные расходы - usable system space.

Во многих виденных мной у конкурентов "документах" такого рода постоянно рассказывается о том, что, якобы, usable system space на системах хранения NetApp составляет менее 50% от купленного raw, а у одного "последовательного борца" с NetApp даже доходила до анекдотичных 34%.
Это смешно для тех, кто знает, как оно обстоит на практике, но все еще производит впечатление на новичков, тех, кто еще не разобрался с тем, как дела обстоят на самом деле.
Ну хорошо, где же истина, которая, как всегда "где-то рядом"?

Цель данного поста - рассмотреть ситуацию с тем, как и из чего образуется usable space на системах NetApp по состоянию дел и технологий на весну 2010 года.
Так как системы NetApp используют свободное пространство на дисках разными способами, а не просто для "хранения LUN-ов" , это постоянно порождает множество непониманий в том, что означают те или иные понятия и параметры, относящиеся к распределению свободного пространства на дисках системы хранения. При этом ряд рекомендаций NetApp изменялись с течением времени, по мере выхода новых версий их OS и взросления используемых технологий. Наша цель - рассмотреть текущее положение дел и обновить понимание вопроса у тех, кто по тем или иным причинам "отстал".

Коротко, "для тех, кому лень читать все"
(то, что называется "Executive summary" ;)

В зависимости от количества и типа дисков и общего дизайна хранилища, исключая самые маленькие системы с очень небольшим количеством дисков, реальная величина usable space целиком системы NetApp может легко превышать 75% от usable space самих дисков. Я видел, например, величину в 78%. Такое значение, конечно же, обеспечивалось при использовании защиты от двойного сбой (RAID-6/DP) и включала spares. Эта величина показывает "честный" объем хранимых данных для NAS или SAN и не включает в себя дедупликацию, компрессию или клоны типа FlexClone; вместе со всеми перечисленными технологиями, эффективность может легко превысить и 1000%. Во многих случаях клиенты NetApp выбирают их системы хранения как раз именно потому, что системы NetApp настолько эффективны с точки зрения usable space. А теперь перейдем к подробностям…

Сколько места будет "достаточно каждому"?

Традиционны дисковые массивы используют пространство довольно простым способом. Вы создаете RAID-группы, затем на них LUN-ы, а эти LUN-ы изображают из себя хост-серверам "локальные" SCSI-диски, вот и все. Понять что происходит с пространством хранения довольно просто. Суммарный размер всех LUN-ов, плюс оставшееся свободное место и есть полное usable-пространство такой системы хранения. Вы покупаете дисковый массив, который, за вычетом RAID и spares, дает вам 10TB, и это все.

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

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

Каково эффективное пространство хранения на NetApp?

Если вы примете во внимание, что каждый снэпшот выглядит для вас, как пользователя, как полная копия всех ваших данных на определенный момент времени, without factoring in any deduplication at all, эффективная "логическая" емкость системы хранения будет во много, много раз больше ее "физической" емкости. Большая юридическая компания, с которой я работал, поместила около 2.5PB своих данных во всего 8TB объема delta space снэпшотов – довольно высокая эффективность, как ни смотри. Мы сейчас не говорим о резервных копиях, сделанных на дедуплицированные диски, резервных копиях, которые, чтобы ими пользоваться, надо восстановить назад на диски, – мы говорим о многих тысячах непосредственных полных "копий" LUN-ов, шар CIFS и NFS, которые вы можете смонтировать и использовать немедленно и непосредственно, без какого-либо процесса "восстановления", занимающего время и место на системе хранения.
А когда вы добавите дедупликацию или thin-клонирование, то эффективность хранения может вырасти и еще больше.

Дело не в том, какого размера ваш диск, а в том, как вы его используете

Если вы рассматриваете систему хранения NetApp как обычный, привычный, "старый добрый" дисковый массив, без использования всех его преимуществ, то соотношение raw/usable space будет примерно равной привычным показателям. Когда вы начинаете использовать снэпшоты, конечно же они начинают "отъедать" пространство, это так. Но посмотрите, что вы получаете взамен. К примеру, можно держать полные бэкапы Exchange на протяжении месяца, платя за это всего лишь незначительным увеличением занимаемого ими объема. Что это дает мне и моему бизнесу? Например:

• Я могу сэкономить, отказавшись от лицензий софт резервного копирования
• Я могу сэкономить, сократив занимаемое системой хранения место и ее энергопотребление
• Я могу обойтись без закупки дополнительных дисков для хранения резервных копий
• Я могу отказаться от покупки дополнительных средств Continuous Data Protection данных
• Восстановление моих данных происходит за секунды
• Решение обеспечения катастрофоустойчивости становится гораздо проще

??ли же я могу создать 150 клонов моей SQL-базы для экспериментов отдела разработки, которыми они могут свободно пользоваться и "ломать" одновременно, и которые займут совершенно незначительную долю места, по сравнению с традиционными "копиями", место, которое на других системах занялось бы в размере 150x от размера самой базы…
??ли создать тысячи клонов VM-рабочих мест в среде VDI…

Сколько денег я сэкономил?

Во сколько обходится простота и скорость администрирования, в терминах операционных затрат вашего бизнеса?

??ли, другими словами:

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

Что именно вы покупаете

Просто для того, чтобы уяснить моменты, в изложенном далее: если вы попросите у меня систему с 10TB usable, я сконфигурирую вам систему c usable system space посчитанного с честным Base2 объемом хранения, защищенным от двойной дисковой ошибки (то есть НЕ RAID5), емкостью равной 10TB, после всех оверхедов, spares, и так далее. Я называю емкостью системы именно usable system space.

Right-sized, реальный объем против raw-объема

Вот некоторые моменты, которые стоит иметь ввиду, при расчете "настоящего" usable-объема:

• Реальный usable размер диска, допустим, FC 450GB не будет равен в точности 450GB, независимо от производителя.
• Реальная usable емкость зависит от того, использовался ли в подсчете "двоичный" (Base2) или "десятичный" (Base10) базис арифметики, а также множество других факторов.
• Все вендоры систем хранения используют жесткие диски, поставляемые разными их производителями, поэтому при создании RAID-группы вам надо рассчитывать, что емкость составляющих ее дисков должна соответствовать самому "маленькому" (исчисляя в количестве секторов) диску среди поставляемых данным вендором системы хранения, иначе вы не сможете установить какой-то из попавших к вам в будущем дисков (например, пришедшем на замену вышедшему из строя, но не Hitachi, например, а Seagate) в существующий RAID, если он окажется меньше по количеству секторов, чем вы определили как емкость диска в существующем RAID. Выбор такого значения "наименьшего общего" числа секторов для ряда дисков разных производителей "одинаковой емкости" называется right-sizing.
• В примере выше, диск "450GB" будет иметь right-sized Base10 пространство равное 438,3GB, и даже "меньше" в двоичной арифметике Base2 (402,2GB). Помните, что "двоичная" Base2-арифметика считает в 1K не 1000, а 1024 байта, а на больших емкостях это может давать подчас значительную “погрешность” (до 9% между TB (Base10) и TiB (Base2)). Хотя для Base2 и Base10 в международном стандарте и определены различные приставки (килобайт, мегабайт и гигабайт для Base10 и "кибибайт", "мебибайт" и "гибибайт" для двоичных Base2), на практике ими все еще мало кто пользуется, что вызывает неизбежную путаницу.
• Остерегайтесь анализа, сравнений или спецификаций, которые показывают данные по емкости, основываясь на Base10 одного вендора, и Base2 другого, или raw disk space одного против right-sized у другого! Всегда спрашивайте, какой базис (Base10 или Base2) используется в том расчете, что вы видите, и каковы значения, отражающие right-sized емкость дисков! Рассчитывайте процент usable базируясь на правильных и главное - одинаково вычисленных емкостях дисков, а не на "маркетинговых" числах вида "450GB".

Некоторые аксиомы процесса резервирования пространства

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

Как обычно, во всем этом нет никакого волшебства. Если вы собираетесь хранить многочисленные снэпшоты, то системе нужно место, чтобы хранить изменения, сделанные в данных между взятыми снэпшотами, независимо от того, кто производитель системы хранения!

Описание принципов организации данных на системах NetApp

??з чего, рассматривая иерархически, состоят структуры хранения NetApp:

• Диски (физичские)
• RAID-группы – создаются из нескольких дисков. Типа RAID по умолчанию у NetApp это RAID-DP. Система хранения создает его автоматически, так что вам не нужно беспокоиться о деталях, таких как балансировка на бэкенде, например, и так далее. RAID-группы у NetApp обычно довольно большие , 16 дисков, иногда и больше. RAID-DP обеспечивает лучшую защиту, чем RAID10 (математика показывает, что в 163 раза лучше, чем у RAID10 и в 4000 раз лучше, чем у RAID5).
• Диски Parity – эти диски содержат избыточную информацию, которая необходима для восстановления данных в случае отказа дисков. RAID-DP использует 2 диска parity на группу RAID.
• Диски Spares – диски, которые автоматически заменяют вышедшие (или планирующие выйти) из строя.
• Aggregates – логическая структура, состоящая из нескольких нижележащих RAID-групп и базовый элемент структуры, на которой размещаются доступные пользователю данные. После создания aggregate (русского термина пока не устоялось, а "агрегат" слишком уж попахивает машиностроением) вы можете расширять его, добавляя в него диски "на ходу", даже по одному. Кроме этого, располагающиеся на aggregate структуры более высокого уровня, такие как тома и LUN-ы оказываются "размазанными" по всем его дискам, что положительно сказывается на быстродействии.
• Тома (Volumes) – "контейнеры данных", размещающиеся поверх Aggregate. Тома могут использоваться в NAS или нести на себе LUN-ы SAN. Тома могут принадлежать только одному Aggregate, и обычно на одном Aggregate располагается множество томов. Обычно тома могут автоматически расширяться, когда они заполняются реальными пользовательскими данными.
• LUN-ы – помещаются внутри томов. Они могут быть один на том, или несколько. Чаще всего используют схему с одним LUN на том.
• Snapshots – логические, эффективно использующие пространство структуры, содержащие мгновенные копии состояния данных на томе, или любых структур, размещающихся на томе. Есть три "формы существования" снэпшота как технологии (Snapshot, SnapVault и FlexClone) но все они базируются на сходных принципах работы. Если коротко: Snapshot – для краткосрочного read-only хранения, Snapvault – для долгосрочного, Flexclone – это Snapshot, в который можно писать.

Описание основных типов резервирований пространства на системах NetApp

1. Snapshot Reserve – это специальная возможность, облегчающая учет пространства на томе в случае использования снэпшотов, которая определяется админом в процентах от общего объема тома. Например, если вы создаете том размером 10TB и устанавливаете для него 10% Snap Reserve, то клиентская система, подключенная к этому тому увидит его размер, доступный для своих операций, равным 9TB. Величина этого резервирования может произвольно задаваться, и даже меняться "на ходу". Действительный объем пространства, занятый снэпшотами зависит от темпов записи изменений на том, произошедший между взятием одного и следующего снэпшота. Реальную ситуацию с величиной занятого в снэпшотах пространства на множестве систем (7597 штук, если быть точным) можно посмотреть здесь . Вкратце: по данным Autosupport на 7597 эксплуатируемых систем, с 127584 томами и более чем 144PB использованной емкости, было занято в почти полутора миллионах снэпшотов около 2,4PB, то есть менее 3%.
2. Aggregate Snap Reserve – этот сравнительно малоизвестный тип резервирования пространства может помочь в случае серьезного повреждения на уровне целиком всей системы, например при катастрофическом повреждении aggregate, и прочего "большого бадабума". Этот параметр включен по умолчанию, и резервирует примерно 5% пространства на aggregate. Это резервирование не обязательно к использованию, если вы только не используете SyncMirror (обычно используется в составе решения Metrocluster). В зависимости от того, что именно вы делаете на вашей системе, это значение можно уменьшить, например до 1%, или, при желании, отключить вовсе (меняя значения по умолчанию всегда ясно понимайте, что именно вы делаете!).
3. Fractional Reserve – это то, что уже много лет вызывает непонимание у многих. Я уже писал о том, что такое и как используется Fractional Reserve раньше. Вкратце: это "страховочная сеть", в том случае, когда вы изменили абсолютно все хранящиеся в LUN на томе данные, при этом, если у вас есть Fractional Reserve, вы по прежнему сможете создать с этого тома снэпшот. Допустим, что мы взяли снэпшот, а затем начали изменять по очереди каждый блок данных в этом томе. Величина snap delta будет пухнуть, пока не составит 100% размера LUN – это случится вне зависимости от того, какую систему хранения со снпшотами вы используете: NetApp, EMC, XIV, Compellent, 3Par, HDS, HP и т.д. Данные же должны где-то размещаться! Отличное и исчерпывающее описание того, что такое Fractional Reserve сделано в этом документе, рекомендую прочесть и разобраться. Еще один полезный документ на эту тему. Короче говоря: с параметром snapshot autodelete, и/или volume autogrow, (и при наличии места для этого роста на aggregate) вы можете установить его значение в 0. Если вы используете продукты SnapManager, они позаботятся об удалении снэпшотов самостоятельно.
4. System reserve – это единственный параметр, не являющийся опциональным. Он установлен в 10% по умолчанию. На самом деле даже его можно изменить, но, ради вас самих, как это сделать я вам не скажу. Для резервирования этого объема есть весомые причины, и уменьшение его может потенциально вызвать серьезные проблемы в системе с высокими показателями по записи. Величина в 10% была выбрана экспериментальным путем и обеспечивает достаточную производительность. Все процессы сайзинга у NetApp учитывают это значение. Кстати, рекомендую вам поинтересоваться у инженеров других вендоров, считают ли они безопасным и правильным использовать их системы хранения заполненными на 100% данными, без никакого резерва, не вызовет ли это ущерба для производительности… Кстати говоря, вы получаете обратно эти 10% (а, зачастую и много больше), когда используете другие методы повышения эффективности хранения NetApp (например сравните типичную длину группы RAID-DP в сравнении с рекомендуемыми значениями у других производителей) так что эта "потеря" не будет столь важной.

??того: За исключением 10% системного резерва, все остальное пространство это, так или иначе, usable space.

Значения по умолчанию, принятые NetApp, и некоторые рекомендации

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

Вот почему, если вы посмотрите в какой-нибудь документ по сравнению систем хранения от наших конкурентов, вы почти наверняка найдете там утверждение, что, якобы, NetApp требует, чтобы место, где размещается LUN имело еще свободного, ничем не занятого пространства в объеме самого LUN, для создания fractional reserve. Эта рекомендация действительно существовала много лет назад, так как была необходима на тот момент для обеспечения безопасности данных, а других средств это сделать на тот момент еще не было. Документация с тех пор была обновлена много лет назад, в соответствии с текущей версией Data ONTAP и ее новыми возможностями, сейчас в ней указано рекомендованное значение fractional reservation в 0, что, правда, почему-то не было замечено нашими, обычно столь внимательными конкурентам, по прежнему твердящим о давно outdated требованиях.

??так, краткий лист рекомендованных значений для LUN:

1. Snap reserve – 0
2. Fractional reserve – 0
3. Snap autodelete on (в случае, если вы не используете продукты SnapManager, который сам управляет процессом удаления старых снэпшотов)
4. Volume autogrow on
5. Оставляйте небольшое незанятое пространство на ваших томах, не заполняйте том на 100% одним LUN-ом (пространство, занятое LUN может быть thick, но пространство тома может быть thin-provisioned). Это пространство используется временными процессами при дедупликации, и рядом других внутренних процессов, к тому же заполнение тома целиком данными может ухудшать его производительность (кстати, это так и для большинства других систем хранения).
6. Рассмотрите возможность использовать thin provisioning, даже если вы не планируете использовать oversubscribe для диска. Это решение даст вам значительную гибкость и "эластичность" системе хранения в долговременной перспективе.

??так, посмотрите на значения по умолчанию, спросите ваших инженеров о их мнении, и, если они не возражают, измените значения по умолчанию на предложенные выше, или на рекомендованные вашими инженерами, лучше соответствующие вашей задаче. Обратите внимание, что на старых системах, даже после обновления Data ONTAP, старые значения не будут изменены (апгрейд системы не изменяет установленных ранее значений в конфигах).

Если вы хотите использовать thin provisioning, то, в зависимости от используемой на системе хранения версии Data ONTAP, вы можете увидеть, что включение thin provisioning на томе может автоматически изменить значение fractional reserve на 100% – но, на самом деле место на дисках при этом не занимается. Это не ставилось принудительно в версиях 7.2.x, поведение было изменено в версии 7.3.1 с установкой на 100%, затем поправлено в 7.3.3, так как всех смутило.

??того

Вопрос объема usаble (используемого) пространства зависит, прежде всего, от того, как именно это пространство будет использоваться. Вы можете использовать систему хранения NetApp как "обычную систему хранения" (помните, "обычный стиральный порошок"?), не используя ее многочисленные дополнительные возможности, и тогда соотношение raw/usable часто будет сравнимым с "обычным". Однако системы хранения NetApp имеют множество дополнительных, зачастую уникальных возможностей по организации и защите данных, их использование неизбежно потребует определенных "жертв" в отношении места на дисках. При этом взамен вы получите новые возможности, лучшую защищенность данных, и новые возможности в бизнесе, выражающиеся, зачастую, во вполне денежном выражении. Все то, что более "традиционные" системы хранения вам просто не смогут предоставить.

Лукавство многих наших конкурентов состоит в том, что они сравнивают системы хранения, не обладающие всеми этими дополнительными возможностями, с системами NetApp, этими возможностями обладающими. Грубо говоря, это сравнения молотка и микроскопа на задаче забивания гвоздя (молоток безусловно выиграет, и по цене решения и по удобству использования;)

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

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