about NetApp

Те, кто закончили на прошлой неделе пятницу раньше обычного ;) и с той поры не заглядывали в rss-ридер, могли не увидеть пятничный пост с фотографиями московской презентации. Рекомендую полюбопытствовать.

Ну и завершая тему распиаривания наших конкурентов ;) несколько видеороликов, посвященных Project Blackbox.

YouTube video, 3:43, Project Blackbox Tour, October 17, 2006.
Dave Douglas, Vice President Advanced Technology of Sun Microsystems.

YouTube Video, 5:53, Tour of Project Blackbox, October 18, 2006.
Dave Douglas, Vice President Advanced Technology of Sun Microsystems.
Чуть более подробно о том, почему и зачем это все.

Ну и, наконец, уже приводившийся в блоге ранее ролик испытания Blackbox на виброплатформе, имитирующей калифорнийское землетрясение 1994 года магнитудой 6.7 балла по Рихтеру.
YouTube video, 4:04, Project Blackbox UCSD Test, June 08, 2007.

SUN Project Blackbox в Москве, 26.07.2007 (flickr photos)

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

Вид снаружи, генератор, охлаждение и сам он.	Наполнение в текущей конфигурации и ТТХ
Вводы для подключения охлаждающей магистрали и порты ввода-вывода.	Подключение охлаждения и электричества
Выдвигаем одну из 8 стоек	Гибкий подвод коммуникаций к стойкам, позволяющий ее выкатить без отключения.
Кабельное хозяйство под потолком и форсунки системы пожаротушения	Трубы охлаждения радиаторов между стойками
Порты ввода-вывода. 2хRJ-45 в military исполнении, ниже выводы LC fiber optics, правее - резервные отверстия под заглушками.	Блоки системы контроля и диагностики
Система амортизации вибрации стоек с помошью спирали из стального троса	Порт электропитания (3 фазы)

-

Некоторые дополнительные фотографии, найденные во Flickr.

	В Хельсинки, предыдущем перед Москвой пункте roadshow.

Большое спасибо коллеге Александру Красюкову из Jet Infosystems за предоставленные фотографии.

Еще почитать:

Новость на “русскоязычном” сайте SUN Microsystems.

Презентация проекта (на русском языке, pdf)

Сегодня днем в Москве, во дворе здания Академии Наук состоялся смотр московской IT-общественностью нового продукта компании SUN, известного пока под названием Blackbox (да, именно “пока”, потому что, во-первых, продукт этот пока еще не выпущен официально, а во-вторых, реальный “blackbox” - белого цвета;).
Фотографии, которыми со мной поделился мой коллега, предусмотрительно, в отличие от меня, захвативший на смотрины фотокамеру, будут завтра, отдельным постом, а пока краткий обзор.

Project Blackbox это инфраструктурное решение компании SUN Microsystems, представляющее собой “датацентр в коробке” - 9-тонный контейнер стандартного формата (20-футов), внутри которого с удобством расположились восемь 19″ стоек для серверного и сетевого оборудования, полностью законченное решение для организации датацентра, автономный “IT-модуль”.

Герметичный, полностью замкнутый контейнер, с внутренней уникальной “бескондиционерной” системой воздушно-водяного охлаждения, требует снаружи лишь:

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

“Blackbox” полностью автономен, может работать при температурах от -18С до +54С (в перспективе нижняя граница температуры будет опущена до -35С), то есть в принципе не требует для своего размещения специального здания, и может размещаться в дешевом неотапливаемом помещении складского типа.
Формат стандартного грузового контейнера позволяет легко и дешево транспортировать полностью укомплектованный, собранный и работающий Blackbox к нужному месту, при необходимости это может быть и мобильный датацентр, например, для какой-нибудь нефтегазовой индустрии.
Но не только.

Уже многие компании, особенно в таких насыщенных городах как Москва, сталкиваются не только с высокой стоимостью аренды площадей, но и, каким бы парадоксальным это не могло показаться, с проблемами с электропитанием в условиях городского центра. Лично знаю компанию, хостинговая площадка которой в принципе не имеет возможности расширяться по причине нехватки электропитания в том районе города, где она имела несчастье разместиться.
При планируемой стоимости Blackbox в районе 300 тысяч долларов (без “набивки”) такой “датацентр в коробке” был бы хорошим решением для многих крупных компаний, причем за счет экономии на аренде площадей, на электроэнергии, на кондиционировании, обслуживании, и прочих, далеко не всегда учитывающихся в изначальном расчете “совокупной стоимости владения” датацентра, ожидается достаточно простая окупаемость такого решения.

Причем, несмотря на всю “брэндовость” продукта, оно не означает выбор серверных решений от SUN для наполнения этого “ящика”. Внутри расположены стандартные 19″ стойки глубиной 78,1 см, пригодные для размещения любого принятого в компании оборудования.
То есть Blackbox это не серверный, а инфраструктурный продукт SUN.

Немного цифр:

• Вмещает в себя до 250 1U серверов.
• Обеспечивает питание и охлаждение оборудования с энергопотреблением до 200 кВт.
• За счет радиаторов водяного охлаждения циркулирующего воздуха обеспечивается отвод до 25 кВт тепла, выделяемого размещенным оборудованием.
• Обеспечивает работоспособность оборудования при внешних температурах от -18С до +54С (при использовании испытываемого в настоящий момент специального охлаждающего состава на основе этиленгликоля - до -35С)
• За счет специальной демпферной системы выдерживает вибрации и удары, в том числе на испытаниях на сейсмическую устойчивость до 6,7 баллов магнитуды (около 1.7 - 2G).
• Оснащен встроенной системой управления, диагностики, контроля доступа и пожаротушения.
• Занимаемая площадь - 9.1м х 4.6м

Ну и в завершение повод для гордости. Первый запущенный в production Blackbox установлен в московском МТС-е, со всей суетой, связанной с переносом в него действующей серверной инфраструктуры датацентра МТС, компания уложилась от поставки до запуска примерно в месяц.
Еще один проданный early adopted blackbox установлен в Стэнфордском ускорительном научном центре (SLAC - Stanford Linear Accelerator Center), один ездит по Америке с аналогичным roadshow, один по Европе (именно он, прибывший из Хельсинки, сейчас в Москве), и еще один принадлежит SUN, установлен в кампусе компании в Калифорнии, и используется для тестирования внутри компании и подготовки уже к публичному выпуску продукта.

PS. Установка BlackBox в SLAC (66Mb QT video)

Еще почитать:

Новость на “русскоязычном” сайте SUN Microsystems.

Презентация проекта (на русском языке, pdf)

“Симъ полукресломъ мастер Гамбсъ…”
Начинаю публиковать ряд результатов измерений производительности различных систем хранения NetApp, которые я проводил в нашей лаборатории.
Тесты неидеальны и, к сожалению, неполны во многом. Впрочем, я давно уже убедился в том, что идеальных и бесспорных тестов не бывает. Лучший тест - это реальная работа. Тут я с позицией NetApp не играть в “пузомерки”, а измерять производительность реальными задачами предприятия на демо-оборудовании, полностью согласен. Но все ж мне было любопытно, и я сделал некоторые замеры.

NB: Это неофициальные, не спонсированные Network Appliance, частные результаты измеренные лично мной, на доступном мне оборудовании и тестовом софте. Эти результаты возможно использовать только как информацию к размышлению, ни я сам, ни, конечно же, компания Network Appliance, не дает фактом публикации этих результатов никаких рекомендаций или обещаний по достижению каких-либо результатов производительности и так далее, blah-blah-blah.

Читать запись полностью »

Мрачно разглядываю результаты разбора логов вебсервера блога.

В среднем после новой публикации на блог приходят от 80 до 90 человек в день. Публикация фотографии “100KIOPS” принесла мне 180 уникальных посетителей в день. А следующая за ней статья про iSCSI - 32 в первый день и 16 во второй, то есть вдвое-вчетверо меньше среднего. Ну то есть я понимаю, запощено в пятницу вечером, мысли у публики уже не о работе, а к понедельнику новость в аггрегаторах успела уже уйти в подвал и все такое, но все же…

То ли в самом деле написано нудно, то ли действительно интерес в России к iSCSI практически нулевой.

“Много думал” (с) ;)

Технология iSCSI (ныне входит в употребление термин IP-SAN) - метод для организации SAN-сети через обычную сетевую инфраструктуру Ethernet.
Она прошла ратификацию в IETF в конце 2003 года (RFC3720) и на сегодняшний день является широкораспространенной и стандартной.

iSCSI является функциональным эквивалентом известного протокола FiberChannel, также как FC, технология iSCSI позволяет организовывать сеть хранения данных, подключать к серверам или рабочим станциям диски и иные устройства хранения (например, ленточные устройства для бэкапа) с тем, чтобы использовать их так, как будто они подключены непосредственно к этим компьютерам.

Технически это осуществляется путем инкапсулирования (”заворачивания”) команд и блоков данных обычного SCSI в IP-пакеты. Это достаточно обычная и традиционная для IP технология, используемая не только в iSCSI. “Обернутые” в IP пакеты SCSI (”SCSI-over-IP”) могут пересылаться по обычной почте сети Ethernet или даже ??нтернету.
Попадая к получателю, они извлекаются из “обертки” IP и в дальнейшем, с точки зрения конечного пользователя, это те же самые SCSI-пакеты, словно они прошли не через Ethernet, а через обыкновенный SCSI-кабель.

Строго говоря то, что мы привыкли называть FiberChannel (FC), есть на самом деле “SCSI-over-FC”, то есть точно таким же образом пакеты FC переносят блоки и команды SCSI, и разница с iSCSI тут на “транспортном уровне”.
А существует, например, “Video-over-FC”, ограниченно применяется в высокопроизводительных системах видеообработки, например в “боевых” авиационных симуляторах.

Преимуществом-же iSCSI является то, что он работает всюду, где пройдет обычный IP, что на практике означает “вообще всюду”. Хоть по модему, хоть через всю планету. На практике же обычно используется уже достаточно широкораспространенный Gigabit Ethernet, обеспечивающий “скорость провода” около 1GBit в секунду (около 100 мегабайт в секунду), не считая возможности объединить провода в “транки”, пропорционально увеличивающие эту скорость.

Широкая доступность Ethernet-инфраструктуры означает в том числе и ее дешевизну в практической реализации. В наше время, когда стоимость порта Gigabit Ethernet снижается на 30% ежемесячно, и дешевые GigE switch доступны уже даже для домашнего использования, это является довольно значимым и существенным аспектом.

Преимущества:

Это дешево, зачастую бесплатно. ?? это работает, причем уже сейчас.
Программный модуль для использования iSCSI имеется для большинства существующих сегодня на рынке OS (MS Windows, Solaris, Linux, AIX и.т.д). Где-то он бесплатно скачивается и устанавливается, где-то включен в поставку. Но, так или иначе, он у вас уже есть.
Его можно просто взять и начать использовать.

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

Недостатки:

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

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

Конечно, существуют и “аппаратные” реализации в виде iSCSI HBA (пример: QLogic QLA4050), снимающие эти проблемы, однако они уже отнюдь не бесплатные, и, хоть и стоят дешевле большинства FC HBA, все же существенно увеличивают бюджет проекта.

Однако, повторюсь, в реальной жизни, в практических задачах применимость и безусловная нужность iSCSI HBA вовсе не настолько бесспорна.
Если идти не от абстрактной “производительности системы хранения”, а от производительности информационной системы в целом, то беспокоить скорость передачи данных между дисковой системой и сервером вас должна, пожалуй, в последнюю очередь. Обычно прикладной задаче, например ERP или CRM-системе, всегда есть где потормозить и не упираясь в канал передачи данных между дисками и процессором.

Скорость iSCSI не использующего “транки” (объеднение вместе нескольких портов для увеличения пропускной способности) в настоящий момент равна 1Gb/s. Несмотря на то, что уже появились сетевые устройства стандарта 10G Ethernet со скоростью до 10Gb/s, цена на них пока еще совершенно заоблачна, что не позволяет говорить о них как о среде для iSCSI.
Скорость FC для наиболее распространенных FC-устройств равна 2 и 4Gb/s, что формально вдвое-вчетверо выше. Однако в условиях “реальной жизни” наличие на устройстве порта 4Gb/s не делает скорость работы устройства вчетверо выше, чем с портом 1Gb/s.

Что необходимо для использования iSCSI:

Для построения простейшей SAN необходимо наличие дискового массива с поддержкой интерфейса iSCSI (например любой NetApp FAS), отдельного сегмента сети передачи данных (несмотря на то, что траффик iSCSI может идти и по обычной “офисной” LAN, более грамотно выделить его в отдельную сеть), свободных Ethernet портов в серверах или специального iSCSI адаптера, а так же программный компонент “Initiator” под ОС серверов.

Где применять iSCSI:

• Для замены DAS - Direct Attached Storages - собственных дисков серверов.
• Для построения SAN “с нуля”, особенно в условиях ограниченного бюджета.
• Для создания протяженной, распределенной SAN, в том числе “катастрофоустойчивых” ее вариантов.

Где не применять iSCSI:

• Для приложений, заведомо сильно загружающих канал передачи данных от дисков.
• Для high-end приложений, таких как крупные enterprise базы данных, с предельными требованиями по латентности и быстродействию.

Предлагаю рассмотреть пару кейсов.

Вариант 1 (Small and Medium Business)

Небольшая компания стремится внедрить SAN с единым дисковым массивом для группы своих серверов баз данных. ??спользуемые платформы: Oracle for Linux и MS SQL на Windows Server. Суммарное количество серверов - 6, прогнозируется рост в течении года до 10 серверов суммарно. Загрузка серверов по процессорам невелика. Сильно загруженная база данных (CPU time >85%) в настоящее время только одна.
При рассмотрении проекта было предложено два варианта: FC и iSCSI.

Суммарная цена решения с FC складывается из:

Суммарная цена решения с iSCSI:

Как мы видим, с использованием iSCSI поставленная задача полностью решена с бюджетной экономией более чем 3,7 раза.
Причем остается обсуждаемым вопрос необходимости в данной конфигурации дорогого (~60% бюджета) многопортового свитча Cisco, вполне возможно применить гораздо менее дорогое оборудование для организации работы 6 портов.

Вариант 2 (Enterprise)

Крупная компания стремится оптимизировать расходы на развитие крупной SAN системы из трех десятков серверов приложений, почты и баз данных. В настоящее время все сервера подключены в FC-SAN, и используют несколько FC-массивов разных производителей. Ряд серверов относятся к business-critical, остальные же - относительно малозагруженные сервера департаментов, почтовая система и сервера группы разработки и тестирования.
Недавно компания пережила ряд проблем, связанных с выходами из строя в рабочее время FC-фабрики и некоторых дисковых массивов. Была поставлена задача повысить доступность данных путем подключения всех серверов по дублированным fault-tolerance путям и замены дискового массива на более современный, с объединением нескольких групп хранения в единое пространство.

Однако при рассмотрении проекта стало ясно, что оснащать значительную часть серверов вторым FC-адаптером финансово затратно, и при этом избыточно с точки зрения производительности. При этом часть departmental-серверов в low-profile корпусах для монтирования в стойку не имеют достаточно места для установки второго адаптера, и требуют закупки двухпортового FC HBA.

Была выделена группа 10 business-critical серверов, и 20 серверов среднего уровня готовности. Часть FC-адаптеров из группы серверов среднего уровня готовности были перенесены в business critical сервера, и все они были подключены по двум портам iSCSI (сервера среднего уровня готовности) и FC (business-critical сервера).

Первоначальный проект FC-SAN with fault tolerance:

Вариант с использованием iSCSI:

Как видно из сметы, поставленная задача обеспечить fault tolerance выполнена во втором случае с более чем трехкратной экономией средств, причем функциональность IT системы не пострадала.

Что почитать еще:

Немного outdated (2004 год), но все еще показательный по результатам и интересный репорт независимой аналитической компании ESG lab:
“iSCSI SAN: a validation study”

Общий обзор состояния индустрии на 2006 год в области IP-SAN:
“ESG Analysis – The State of iSCSI-based IP SAN 2006″

Fibre Channel and iSCSI Performance Comparison for DSS Workloads Using SQL Server 2005
Yogesh Manocha, and Ian Breitner
Network Appliance, Inc., May 2006, TR-3476

Performance Study of iSCSI in an OLTP-Based. Oracle 9i RAC Database Environment with. NetApp iSCSI Filers.
By: Giovanni Brignolo, Sankar Bose – Network Appliance, Inc.
Theodore Haining, Srinivas Maturi, Xiaoping Li – Oracle Corporation
Robin Bhagat, Samdeep Nayak, Robert Ortega – Adaptec Corporation
November 11, 2004

Technology Validation of Microsoft Exchange on iSCSI Storage
Network Appliance, Inc. and Cisco Systems, Inc.
February 2006, TR-3421

Example Proof of Concept for Microsoft Exchange Running with FC or iSCSI on a Network Appliance MetroCluster
Richard Jooss | Network Appliance | May 2005 | TR 3412

Techtarget.com All-in-One Buying Guide: Scaling Storage Networks

IP SAN FAQ

Синхронная
Синхронная репликация - это зеркалирование данных на две системы хранения или два дисковых раздела внутри одной системы.
Популярный RAID-1 («зеркало») для дисковых контроллеров есть по сути просто синхронная репликация на два диска, выполняемая контроллером диска. При этом каждый блок данных записывается более или менее одновременно, параллельно, на оба устройства. Аналогичным образом это осуществляется на два «диска» в разных дисковых системах хранения.
Это «идеальная репликация», обе копии данных полностью идентичны, потому что пока данные не будут гарантированно записаны на оба устройства, оно не может приступить к записи следующего блока.
Однако теоретическая идеальность в реальной жизни оказывается ограничением.

Как мы видим, общая скорость системы ограничена самым узким каналом передачи данных. Если мы соединены с системой хранения FC-каналом в 4GB/s, а система хранения синхронно реплицируется на удаленную систему по каналу в 10MB/s, то скорость обмена по FC-каналу 4GB/s будет 10MB/s и ни байтом больше.

Асинхронная
Асинхронной называют репликацию, которая осуществляется не в тот же момент, когда осуществляется запись оригинального блока данных, а в «удобное время». Это позволяет преодолеть вышеописанный недостаток синхронной репликации, поскольку процесс записи данных и процесс их переноса на «реплику» разделены и не связаны больше.

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

«Полусинхронная»
Вариантом, сочетающим в себе возможности синхронной и асинхронной репликации, является так называемая «semi-synchronous» репликация, или «полусинхронная».
В этом случае репликация проводится синхронной до тех пор, пока это позволяет быстродействие системы или канала связи. А затем, вместо замедления и остановки операций записи, временно переключается в асинхронный режим, продолжая обрабатывать поступающие данные без задержек, отправляя данные репликации в асинхронном режиме до тех пор, пока не возникнет возможность восстановить синхронный режим.

Проблемы консистентности
Для любой репликации отличной от синхронной серьезной проблемой является также “проблема консистентности”. Рассмотрим ее на простом примере.
Узел хранения А асинхронно реплицирует данные на узел хранения Б.
На устройстве хранения работает база данных, которая обрабатывает запросы, например финансовой системы.

В процессе проводки операции продажи база данных при продаже декрементирует счетчик количества товара и добавляет в базу сумму продажи (то есть я утрирую и огрубляю, но примерный принцип таков). Но это две различных операции над базой (разными базами) данных.
Если у нас работает асинхронная репликация, то может случиться так, что разрыв репликации в результате отказа может произойти в момент, когда первая операция уже прошла, а вторая еще не началась.
В результате мы имеем нарушение консистентности базы, которое довольно непросто выловить, ведь транзакции-то как таковые завершились успешно, но нарушилась бизнес-связность группы транзакций.
Поэтому с точки зрения целостности базы будет лучше, если мы “откатим” всю операцию продажи, сохранив консистентность, а не только отдельную транзакцию.
Эту проблему в репликации каждый вендор решает по-своему, обычно путем реализации так называемых consistency groups, для которых операции репликации производятся связно.

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

1. Network Appliance был первым в мире производителем дисковых систем хранения с дисками FiberChannel (модели F520/540, 1996 год).
2. Технология Snapshots в области хранения данных изобретена в Network Appliance и это зарегистрированная торговая марка NetApp.
3. Технология RAID-6 (RAID-DP) в системах хранения NetApp появилась еще в 2004 году. (?? стала доступна для всех систем хранения компании, поддерживавших обновление OS Data ONTAP, в том числе и для ранее выпущенных)
4. NetApp первым в отрасли выпустил в 2001 году enterprise storage на дисках технологии ATA (тогда еще PATA) (модель Nearstore).
5. Процедура апгрейда системы хранения NetApp (например на более мощную) занимает, с полным сохранением хранимых данных, в среднем около 3 минут.

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

Однако ситуацию можно изменить в корне, использовав специальный режим записи на RAID-группу, подготовленными в памяти системы хранения “страйпами”, длиной во всю дисковую группу. То есть сначала все операции записи совершаются в сегмент кэш-памяти, а затем, раз в 10 секунд (или чаще в случае большой нагрузки по записи), этот страйп целиком переносится на все диски RAID-группы одной операцией записи, в один прием, обновляя во время этого процесса и пресловутый “диск блока избыточности”.
А учитывая то, что диски вместе с OS, “железом”, кэшем, NVRAM и файловой системой представляют собой единый взаимосвязанный “программно-аппаратный комплекс”, отстроенный производителем, это позволяет создать единую систему, осуществлять все операции с ней согласованно и единообразно.
Не следует также забывать и о том, что на дисках при этом присутствует специальная файловая система WAFL, о которой я писал раньше, позволяющая за счет своей своеобразной схемы записи данных осуществлять запись особым и наиболее оптимальным в данном случае образом.

Некоторые фундаментальные основы организации систем хранения NetApp можно найти в одном из первых документов NetApp Techlibrary:
A Storage Networking Appliance
Dave Hitz and Akshay Bhargava, Network Appliance, Inc.
February 2006, TR-3001

Почему же RAID-4, почему не хорошо известный и широкораспространенный RAID-5?
В первую очередь выбор RAID-4 был обусловлен простотой обслуживания и расширения системы хранения. В отличие от RAID-5, наш RAID type 4 позволяет “на лету” расширять RAID-группу добавлением дополнительных дисков, при этом не перестраивая весь RAID, операция, которая на многие часы (а для больших групп - дни!) “убивает” производительность RAID-5.

На заре систем хранения счет дисков в системах хранения шел на единицы. ?? возможность, при необходимости, расшириться не на “пару терабайт”, а на 1-2 диска был (впрочем, и остается) весьма существенным преимуществом.
В результате RAID с теоретически наихудшими возможными показателями по записи, на практике в системах NetApp зачастую обгоняет на операциях записи большинство “одноклассников”. Это ли не прекрасная иллюстрация инженерного потенциала системы?

RAID-DP
RAID with Diagonal Parity или иногда встречается вариант ‘Double Parity’ - реализованный в 2003 году (впервые появился в версии Data ONTAP 6.5) собственный NetApp-овский аналог RAID-6. Несмотря на то, что RAID-DP в деталях отличается от “канонического” RAID-6, тем не менее относительно недавно маркетингом компании было принято решение чаще пользоваться обозначением RAID-6 для обозначения RAID-DP в своей продукции. Это облегчает принципиальное понимание и, кроме прочего, облегчает соответствие систем NetApp тендерным требованиям.

Функционально же, как средство, обеспечивающее защиту данных при выходе из строя двух дисков в RAID-группе, RAID-DP эквивалентен RAID-6.
В чем же разница?
Практически все вендоры, использующие RAID-6, признают, что использование RAID-6 вместо RAID-5 приводит к падению производительности от 10 до 20%.
??ная ситуация с RAID-DP. Компания NetApp официально подтверждает, что по сравнению с традиционным RAID-4 производительность тома на группе RAID-DP отличается не более чем на единицы процентов.

То есть за повышенную надежность своих данных пользователь системы хранения NetApp не платит производительностью вовсе. Такой результат также является следствием использования все той же тесной интеграции между OS, кэшем, дисками, RAID-структурой и файловой системой - то, что не могут предложить другие производители систем хранения.
Это позволило Network Appliance рекомендовать использовать RAID-DP как схему по умолчанию для всех своих систем хранения.

Для лучшего понимания того, как работает RAID-DP могу порекомендовать документ из NetApp Technical Library:
RAID-DP™: NETWORK APPLIANCE™ IMPLEMENTATION OF RAID DOUBLE PARITY FOR DATA PROTECTION A HIGH-SPEED IMPLEMENTATION OF RAID 6
Chris Lueth, Network Appliance, Inc. TR-3298 [12/2006]

а также:
Row-Diagonal Parity for Double Disk Failure Correction
Peter Corbett, Bob English, Atul Goel, Tomislav Grcanac, Steven Kleiman, James Leong, and Sunitha Sankar, Network Appliance, Inc. [USENIX]