about NetApp

Когда вы настраивали сетевые интерфейсы на NetApp, возможно вы обратили внимание на опцию, устанавливаемую для сетевого интерфейса: trusted/untrusted. По умолчанию интерфейс считается trusted.

ifconfig <interface> [trusted|untrusted]

В чем разница?

Руководство Network Administration Guide пишет по этому поводу следующее:

“??нтерфейс с опцией untrusted отбрасывает все пакеты, включая принимаемые пакеты ICMP responce (ping), все, кроме пакетов протокола http. Через такой интерфейс возможен доступ к системе хранения только по http в режиме read-only.

Статус untrusted не может быть применен к группе интерфейсов (vif/ifgrp), а только к физическому порту.”

Нам пишут наши читатели:

Оригнал здесь, перепечатывается оттуда по согласию с автором: http://ua9uqb.livejournal.com/79872.html

Не так давно довелось мне протестировать две системы хранения данных, делюсь результатами. В тесте принимали участие системы начального уровня NetApp FAS2240 и Hitachi AMS2100.
Надо понимать, что системы эти сравнимы довольно условно, так как AMS - обычное, бедное по функционалу блочное хранилище, в отличии от сильно мозговитого, "всё-всё умеющего" NetApp-а. Конфигурации системы, методики тестирования, и прочие тюнинги, были согласованны со специалистами вендоров.

Немного подробностей по методике:
1. Тестирование проводилось программой IOMeter версии 2006.07.27 для Windows.

2. Подключение СХД Hitachi AMS2100 производится посредством FC4G, протокол FC
Cостав LUN и томов СХД
Raid10 8 x 450gb 15k 3.5’ Usable: 1.5Tb Lun: 700Gb
Raid6 8+2 450gb 15k 3.5’ Usable: 3.1Tb Lun: 700Gb

3. Подключение СХД NetApp FAS2240 производится посредством 10Ge, протокол iscsi
Состав LUN и томов СХД
RaidDP 9+2 x 600gb 10k 2.5’ Usable: 4.33Tb Lun: 700Gb

4. Тесты проводится в режиме файловой системы NTFS 4к, выравнивание партишина 64к;

5. Настройки программы IOMeter:
• Worker’s – 4
• Target – 16 (в каждом из Worker’s)
• Disk Size – 200000000 (100Gb)
• Ramp Up Time – 600 сек
• Run Time – 30 мин

6. Фиксация результатов каждого теста для IOMeter длиться 30 минут начиная с 10-й и заканчивая 40-й минутой теста;

7. Профили нагрузок(название профилей условное), используемые для тестирования IOMeter следующие: 
Нагрузка характерная для приложений ORACLE 
• размер блока 8КБ;
• соотношение количества операций чтения/запись 30/70;
• характер нагрузки – 100% случайный доступ;

Нагрузка характерная для VMware:
• размер блока 4КБ;
• соотношение количества операций чтения/запись 40/60;
• характер нагрузки – 45% линейный и 55% случайный доступ;

Нагрузка характерная для операций Backup:
• размер блока 64КБ;
• 100% последовательное чтение;

??тог:

Табличка довольно прозрачная, поэтому никаких выводов делать не буду.
NetApp FAS2240(в центре, где куча вертикальных планочек, и жёлтая наклейка сверху):

Hitachi AMS2100

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

PPS. Пост навеян коментом френдессы balorus к посту про сервер Sun T4-4 :-)

PPPS. Мой выбор был бы NetApp, если бы Хитача в те же деньги не уложила сильно больше шпинделей. А так же не ещё один сильно политический нюанс, который очень сложно перебить даже теми волшебными, и крайне необходимыми нам штуками, которые NetApp умеет делать очень хорошо, а AMS не умеет в принципе.

В воскресенье, 22 апреля, в истории NetApp случился юбилей – ровно 20 лет назад она стала компанией, официально зарегистрировавшись под названием Network Appliance Inc., в штате Калифорния, США. Хотя как концепция она возникла 2 декабря 1991 года, что было, так сказать, “зачатием”, но официальной датой “рождения” принято считать именно 22 апреля.

Некоторые интересные факты из жизни компании:

• Название 1-800-SERVERS одно время всерьез рассматривалось в качестве имени компании
• Первый продукт компании, устройство FAServer400, имел всего 30 команд и 70-страничный мануал. Он был построен на базе процессора i486/50MHz и имел максимальную raw-емкость 14GB.
• Он продавался по цене 12.000$ реселлерам, и имел листпрайс для конечных пользователей в 16.000$
• Все трое основателей компании – Дэвид Хитц, Майкл Малколм и Джеймс Лау работали в компании Auspex Systems, одной из первых начавшей продавать Enterprise NAS. Компания обанкротилась и закрылась в 2003 году, а ее патентный пул был выкуплен NetApp.
• Двое из троих основателей компании, Хитц и Лау, до сих пор работают в ней. Майкл Малколм, сыгравший большую роль в становлении компании и занимавший пост ее CEO, был вынужден покинуть компанию в ее ранние годы, в результате конфликта с советом директоров, и с тех пор занимался несколькими различными проектами в области компьютерного “железа” в компаниях в Кремниевой Долине. Подробно эта история рассказывается в книге “How to Castrate a Bull: Unexpected Lessons on Risk, Growth, and Success in Business"

??нтересный источник о первых годах компании также документы: Establishing Network Appliance и Oral History of Dave Hitz.

На прошлой неделе NetApp выпустил в свет мобильное приложение под iOS и Android, для доступа к информации Autosupport вашей системы. Приложение пока на самой ранней стадии, но идея очень правильная и нужная.

Берут здесь: http://www.netapp.com/us/support/asup-app.html

Есть, как я уже сказал, версии для iPhone, iPad и Android tablets/phones.

Вы наверняка уже знаете, что такое снэпшоты в 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.

В практике построения высокодоступных систем, прежде всего IT, существует понятие “единой точки отказа” (SPOF, Single Point Of Failure). Любая система высокой доступности данных стремится не иметь в своей архитектуре узла, линии связи или объекта, отказ которого может вывести из строя всю систему, или вызвать недоступность данных.

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

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

Что же, в таком случае, на самом деле определяет годность решения?

Мне представляется, что это удовлетворение требованиям по RPO/RTO для данной конкретной бизнес-задачи.

Термины RPO/RTO хорошо известны специалистам в области защиты данных и резервного копирования. RPO, Return Point Objective – это “точка доступности данных”, в случае их потери. RTO, Return Time Objective – это время, которое неоьходимо системе для восстановления своей работы, и возобновления обслуживания.

Например, если вы делаете резервное копирование вашей базы данных раз в сутки по вечерам, после окончания рабочего дня, в 21:00, то RPO для вашей системы будет 21:00 вечера предыдущего дня, то есть момент начала создания резервной копии.

Допустим, вы потеряли данные, восстановили их из бэкапа по состоянию на 21 час прошлого дня. Восстановление базы заняло 40 минут. Если у вас работает база данных, то вам еще надо актуализировать ее состояние из archive logs, накатив изменения, записанные с 21:00 по текущее время. Допустим, это заняло 15 минут. ??того, RTO, в вашем случае – 55 минут.

Плохо это или хорошо? Невозможно ответить с точки зрения IT. Ответ должен дать бизнес, которому вы служите. Для какой-то задачи даже 10 минут простоя это много. Какая-то вполне готова подождать пару часов, а какие-то задачи вполне могут и сутки постоять, ничего страшного не случится. Падение биржи NYSE может быть чревато паникой в масштабах глобальной экономики. Падение сети обслуживания банкоматов крупного банка, который за 10 минут периода простоя мог бы обработать десятки тысяч обращений “физиков”, это еще не паника, но все еще очень неприятно. А хостинг домашних страничек вполне может и сутки полежать с сообщением “??звините, ведутся работы”, в лучшем случае выплатив клиентам неустойку за сутки простоя.

Разумеется, бизнес будет требовать нулевого RPO/RTO, это всегда так, они всегда это требуют. :) Однако следует помнить, что все стоит денег, и каждое улучшение ситуации с временем недоступности стоит денег, причем часто растет по экспоненте, каждое следующее улучшение этих параметров обойдется бизнесу все дороже и дороже.

Поэтому, как правило, бизнес и IT обычно приходят к некоему компромиссу. Компромисс этот, как правило, сегментирован по задачам. Но в конечном счете бизнес и IT, совместно вырабатывают какие-то требования по RPO/RTO.

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

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

Может ли быть хорошей, то есть удовлетворять требованиям бизнеса по RPO/RTO, система с наличием “единой точки отказа”? Да запросто. Если период восстановления работоспособности системы укладывается в заданные рамки – да пусть сколько угодно там будет точек отказа. В особенности, если ликвидация в решении всех “единых точек отказа” экономически нецелесообразна, потому что чрезмерно дорога для решаемой бизнесом задачи.

Помните, что надежность, это комплексный параметр, зависящий от множества факторов и множества участников. Создание сверхнадежного стораджа для хранения данных не сделает сверхнадежной вашу IT-систему, если к этому сверхнадежному, кластерному, без единой точки отказа, и по FC Dual Fabric подключены ненадежные сервера, без кластеризации и с истекшим сервисным контрактом, выполняющие собственно бизнес-приложение и бизнес-функцию. Помните, что как и в случае морской эскадры, скорость которой определяется скоростью самого медленного в ней корабля, надежность IT-системы определяется надежностью самого слабого в ней звена, а отнюдь не самого надежного.

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

А не просто фетишировать на один из множества инструментов для достижения этой цели.

Я бы хотел напомнить тем, кто это уже знает, а кто не знает – рассказать, что вот уже несколько месяцев на базе сайта communuities.netapp.com организовано русскоязычное сообщество, с дискуссионным форумом, где можно задавать вопросы (и получать на них ответы), а также почерпнут оттуда разнообразную информацию, например туда я выложил все актуальные переводы Best Practices, которые я сделал за прошедший год.

Адрес: https://communities.netapp.com/groups/netapp-ru/

Для участия (а также для доступа к некоторым материалам, типа переводов) нужно зарегистрироваться (но читать можно и так). Регистрация быстрая, бесплатная, не требует быть клиетом NetApp или быть зарегистрированным владельцем системы на поддержке. Также будем рады видеть там и пользователей IBM N-series.

Только несколько тем из текущих дискуссий:

• Вопрос допуска по CIFS гостей без пароля
• Как перенести vfiler на другой интерфейс (Data ONTAP 8.1RC2) ?
• Ошибки подключения дисковых полок
• Как включить компрессию для тома? (Data ONTAP 8.0.2, 64-bit aggr)
• Некорректная работа ESXi на NetApp FAS2040
• Обновление timezone

Среди выложенных переведенных на русский Best Practices:

• RUS TR-4017 Fibre Channel SAN Best Practices
• RUS TR-3329 Using Oracle DB 10g-11g ASM and NetApp
• RUS TR-3839 NetApp and VMware NFS
• RUS TR-3705 NetApp and VMware View Solution Guide

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

Некоторое время назад по IT-новостям прокатилось сообщение что “Система хранения Oracle 7320 победила в тестах NetApp FAS3270!! адинадин”. На прошлой неделе у меня дошли руки посмотреть все же что там, как, кто, и кого победил. О результатах рассказываю.

Тема “тестирований производительности” (кавычки мои, romx) есть любимая тема любого сисадмина.

Допустим, вы читаете в новостях сообщение, что “Мотоцикл Honda CBR150 обошел на стометровке с места болид Formula1 Ferrari!”. “Ну, круто” – подумаете вы, “но кому интересно соревнование с формульным болидом на стометровке с места? Они бы еще соревновались по параметру “экономия бензина” с велосипедом!” А вот нет, оказывается, прекрасная новость и информационный повод проспамить прессрелизом IT-издания.

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

Но, для начала, несколько вводных слов.

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

Но если в том что касается бенчмарка, то есть создания повторяемой среды тестирования идентичной для всех тестирующихся систем, можно положиться на авторитет общепризнанных тестов, каковыми на сегодня являются, например SPECsfs2008 для файловых протоколов (NFS и CIFS), и SPC-1 для блочных протоколов (FC и iSCSI), то вот в подготовке тестируемой системы есть некоторая свобода, которой иногда (довольно часто, к сожалению) пользуются некоторые производители с целью создать “систему хранения”, единственная цель которой – победа в тестировании. В англоязычном сегменте такое называется lab queen, по-русски я слышал название “звездолет”.

Вариантов как построить звездолет есть масса. Например можно взять хай-энд систему и набить ее SSD, получив систему за шесть миллионов долларов на 19TB usable . Можно поставить вместе четыре стораджа, и в результатах тупо просуммировать показанные ими по отдельности результаты. Можно, наконец, тестировать систему на голых дисках без RAID или на RAID-0. ??спользовать множество дисков малого объема. Разбить пространство тестирование на большое количество мелких разделов, снижая “разбег” random access seek, и так далее. Полученные таким образом результаты окажутся неприменимыми в реальной жизни и в реальной эксплуатации того, что вы можете купить, однако очень эффектно смотрятся в пресс-релизах об очередной победе.

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

А теперь перейдем собственно к теме. Что же скрывает за собой барабанная дробь прессрелиза?

Согласно требованиям проведения тестирования SPECsfs2008, протестированная конфгурация должна быть хорошо и детально документирована и описана. Эти данные доступны на сайте SPEC.org всем желающим. Пожелаем и мы проверить, какую же в точности конфигурацию тестировали в Oracle.

Вот как описывает протестированную конфигурацию сайт SPEC.org:
http://www.spec.org/sfs2008/results/res2012q1/sfs2008-20120206-00207.html

Система Oracle Sun ZFS storage 7320

136 дисков SAS 15K на 300GB в 6 дисковых полках, обшим usable space емкостью 37,1TB и общей экспортируемой емкостью в 36,96TB были поделены на 32 файловые системы, по 16 на каждый из двух контроллеров (каждая экспортируемая FS имела размер примерно 1,1TB), доступ к которым осуществлялся с трех loadgenerator Sun Fire X4270 M2, подключенных по 10G Ethernet.

Также тестированный сторадж оснащен 8 дисками SSD по 512GB каждый, для кэширования чтения, (так называемый L2ARC), общей емкостью 4TB, пополам на каждом из двух контроллеров, и 8 дисками SSD 73GB в качестве кэша записи (ZIL), суммарно 584GB, без RAID в обоих случаях. Кроме этого, два контроллера системы хранения имели RAM емкостью 288GB (ARC, по 144GB на контроллер), что дает 4968GB суммарной емкости кэша (SSD и RAM).

Суммарная, участвующая в тестировании емкость (fileset) составила 15587,3 GB, то есть емкость кэша составила примерно треть от используемого файлсета.

Далее цитата:
The storage configuration consists of 6 shelves, 4 with 24 disk drives, 2 with 20 disk drives and 4 write flash devices. Each controller head has 4 read flash accelerators. Each controller is configured to use 68 disk drives, 4 write flash accelerator devices and 4 read flash accelerator devices. The controller is then set up with pools by dividing the disk drives, write flash accelerators and read flash accelerators into 4 pools. Each of the controller’s pools is configured with 17 disk drives, 1 write flash accelerator and 1 read flash accelerator. The pools are then set up to stripe the data (RAID0) across all 17 drives. The write flash accelerator in each pool is used for the ZFS Intent Log (ZIL) and the read flash accelerator is used as a level 2 cache (L2ARC) for the pool. All pools are configured with 4 ZFS filesystems each.

“Конфигурация системы хранения содержала 6 дисковых полок, 4 полки на 24 диска и 2 полки на 20 дисков, плюс 4 SSD-кэша на запись. Каждый контроллер использовал 4 SSD-диска в качестве кэша чтения. Каждый контроллер был сконфигурирован на работу с 68 дисками, 4 SSD кэша на запись и 4 SSD кэша на чтение. Каждый контроллер использовал пулы дисков, между которыми были разделены диски, по одному SSD-кэшу на чтение и на запись на каждый пул. Пулы были настроены таким образом, чтобы данные страйпились на все входящие в него 17 дисков (RAID-0). Write flash accelerator (SSD емкостью 73GB) в каждом пуле использовался в качестве ZFS Intent Log (ZIL), а read flash accelerator (SSD емкостью 512GB) как level 2 cache (L2ARC). На каждом из пулов было создано по 4 файловые системы.”

Как мы видим, несмотря на использование ZFS, для организации дисков в пулах был выбран простой stripe, без RAID (фактически RAID-0!). Кроме того стоит отметить, что общая тестируемая емкость дисков была поделена на сравнительно маленькие файловые системы, всего около 1,1TB каждая, числом 32 (зачем такой финт – см. выше).

Очевидно, что такая конфигурация довольно далека от реально эксплуатируемой на такого рода системах. Кто в здравом уме будет класть данные на 17-дисковую группу в RAID-0?! А как планируется использовать пространство, разбитое на 32 отдельных FS для хранения, например, больших объемов? А каковы 512GB write cache на SSD, без малейшей защиты от сбоя?

Кстати интересный вопрос: Если ZFS так хороша и производительна, и так хорош RAID-Z и RAID-Z2, то почему его не использует при выкатке систем на тестирование даже сам Oracle? Что за засада с ним, господа из Oracle? Вот NetApp показывает свой результат на реальных, эксплуатируемых конфигурациях, с RAID-DP и даже со включенным thin provisioning, а в результатах Oracle в SFS2008 – Stripe (RAID-0), а в SPC-1 – mirror (RAID-1). Почему не RAID-Z(2)? Почему бы не показать результаты с ними? Может быть они совсем не так хороши?

Для сравнения давайте посмотрим на упомянутую конфигурацию NetApp FAS3270, которую “побеждали”.

FAS3270 в конфигурации с SAS-дисками и без Flash Cache, поставки таких систем начались в ноябре 2010 года, около полутора лет назад.

360 дисков 450GB 15K, общая usable емкость дисков 125,7TB (в RAID-DP), экспортированная емкость равна 110,08TB (88% от usable) в 2 файловых системах (по одной на контроллер). Диски организованы в два aggregate из 11 RAID-групп 14d+2p в RAID-DP (RAID-6),  тестовая нагрузка генерировалась с помощью 12 Loadgenerators типа IBM 3650M2.

Exported capacity равна 110TB, файлсет, на котором проводилос тестирование - 11749.7 GB  Размер RAM, используемого как кэш на системе хранения, равен 36GB, что составляет 1/326 от fileset.

SPECsfs2008_nfs.v3=101183 Ops/Sec (Overall Response Time = 1.66 msec)

У “победившей” его полтора года спустя системы с RAID-0, с кэшами разного уровня, составляющими суммарно до трети тестируемого файлсета, включая около 4,5TB на SSD, с в шесть раз большим RAM контроллера и с тестируемым пространством побитым на 32 кусочка-FS:

SPECsfs2008_nfs.v3=134140 Ops/Sec (Overall Response Time = 1.51 msec)

На 32,5% больше IOPS и на 8,5% лучше latency.

Ребята из Oracle, что называется "при всем уважени”, но вы правда считаете, что таким результатом, при описанном выше устройстве тестируемой системы, и способе проведения тестирования, это победа и этим стоит гордиться? Нет, ну правда?

Оно дешевле стоит? Ну, согласен, дешевле. Мотоцикл порвал Феррари на стометровке. Но кто гоняет на Феррари на стометровке? Какой смысл сравнивать по цене лоу-мидрендж (“Entry-level cluster option for high availability”, цитата из техспеков на 7320), ZFS-сервер, со стораджем, в максимуме тянущем в 6,6 раз большую чем 7320 емкость, используещем RAID-6, и демонстрируемом даже близко не на пределе своих возможностей по тестируемой емкости?

Впрочем, несколько слов и о цене. В тесте SPECsfs2008 условия тестирования не требуют называния цены тестируемой системы, поэтому спекуляции о цене делаются на довольно мутном базисе “нашли гуглом какой-то прайс нетаппа, где-то в интернете, и прикинули”. Однако в случае SPC-1 требуется указывать такой параметр, как IOPS/$ и цена всей тестируемой конфигурации называется. Тут, однако, тоже есть поле для… ну-у… скажем так, для “оптимизации” :). Например на тестировании SPC-1 NetApp называет цену листпрайса (см стр. 18 отчета), а Oracle, ничуть не смущаясь приводит цену с “вшитой” 30% скидкой по всем позициям (см. стр. 14 отчета) и именно ее берет в расчете IOPS/$ в SPC-1.

Так что, повторю сказанное мной в начале поста: Читайте мелкий шрифт, не ленитесь разбираться в конфигурациях и их деталях, и оставьте пресс-релизы (и выводы только на их основании) для С*O-менеджеров. :)

О любопытной функции внутри 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)’ »