about NetApp

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

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

Вычислительный кластер

Как правило это продукт, в той или иной степени копирующий своего наиболее последовательного представителя – вычислительный кластер проекта Beowulf. Обычно это множество примерно однотипных вычислительных систем под управлением OS Linux, на которых установлены «узлы» вычислительного кластера, и компьютер-планировщик, распределяющий задания по такой многоузловой сети для их параллельной обработки.
Beowulf-кластер есть почти идеальный кластер, он практически линейно масштабируется до сотен и тысяч узлов, он нечувствителен к выходу из строя как одного, так и нескольких своих узлов. За исключением одного минуса: в задачах реальной жизни его применимость довольно ограниченна.
Beowulf прекрасно работает на задачах, которые алгоритмически делятся на множество однотипных операций. Но, к сожалению, такие операции встречаются главным образом в науке. Это такие операции как разложение на множители, преобразование Фурье, любые иные операции, требующие некоей минимальной порции данных и выполнения над ней какой-то относительно небольшой операции, независимо от всех прочих участников процесса.
Если мы возьмем, например, наиболее функционально применимую задачу «реальной жизни» - выборку из базы данных, а к такой задаче чаще всего и сводится большинство бизнес-задач, то мы увидим, что задача «SELECT * FROM TABLE», как ни прискорбно, не может быть распараллелена. На такой задаче Beowulf-type cluster практически не имеет преимущества перед одиночным компьютером.

Кластер приложений

Отказоустойчивый кластер (active-passive)
Традиционным представителем такого рода продуктов является хорошо известный и широко применяемый продукт Veritas Cluster Server (VCS, ныне принадлежит компании Symantec). Также известны продукты Microsoft Cluster Services (поставляется в составе Windows Server Enterprise Edition) и Legato AAM (Automated Availability Manager, ныне EMC AutoStart).
Это в чистом виде отказоустойчивый кластер. Приложение исполняется на некоей платформе, состояние платформы контролируется ПО кластера, в случае недостаточности тех или иных ресурсов (объема памяти, производительности процессора) или недоступности, прикладная задача (по возможности корректно) останавливается на существующем узле и рестартуется на другом, имеющемся в распоряжении кластерного софта. Тем самым обеспечивается доступность прикладной задачи и некий заданный уровень Quality of Service.
Конкретное приложение в каждый конкретный момент времени исполняется на какой-то одной конкретной платформе (сервере).

Параллельный кластер (active-active)

В отличие от вышеописанного кластера модели active-passive, в котором лишь один узел в любой произвольный момент времени является активным, а другой узел или узлы находятся в «горячем резерве», ожидая отказа или недоступности активного узла с тем, чтобы запустить на себе приложение и продолжить выполнение задачи, все узлы кластера модели active-active активны и исполняют прикладную задачу параллельно. Это немного напоминает ранее рассмотренный вычислительный кластер Beowulf, в котором вычислительные узлы получают свои порции данных для обработки от узла диспетчера-«планировщика». Однако, как мы уже рассмотрели выше, это требует очень непростой организации как самой задачи, позволяющей себя распараллеливать на независимые потоки, так и возможности обеспечивать совместное использование данных как на чтение, так и на запись.
??менно сложность, а следовательно и дороговизна решения этих задач ограничивала появление и применение кластеров приложений типа active-active. В остальном же он функционально подобен уже рассмотренным.
Наиболее известным представителем такого вида кластеров является продукт Oracle RAC (Real Application Cluster).

Кластер хранения

Все вышеперечисленные варианты кластера относятся к разряду кластеров приложений. Разумеется, данные, с которыми работают эти приложения (например база данных) хранятся где-то, но это находится вне «компетенции» и «области ответственности» кластера приложения. С его точки зрения данные априори всегда корректны и доступны. Большинство кластеров приложений устанавливаются так, чтобы использовать common storage, «общий диск», общий и доступный для всех узлов кластера, где и хранятся при необходимости данные исполняемого на них приложения. Либо организуется репликация для поддержания консистентной копии, в случае если систем хранения несколько, например у каждого узла кластера свой. Однако, дисковая подсистема хранения также может так или иначе выйти из строя. Отказоустойчивую организацию системы хранения будем называть «кластером хранения».

Как ни парадоксально, но даже простая структура RAID соответствует нашему определению кластера, так RAID-1 или RAID-5 являются «устройствами, сохраняющими свою функциональность при выходе из строя произвольных составляющих их компонентов (дисков)». Но попробуем рассмотреть более продвинутые и сложные варианты отказоустойчивого хранилища, ведь система хранения состоит не только из составляющих ее дисков.

Отказоустойчивый кластер (active-passive)

Таковыми ныне являются практически все имеющиеся на рынке серьезные системы хранения. Любая система хранения enterprise-класса поставляется с дублированными блоками питания и модулями контроллера управления, выход из строя любого из пары контроллеров не приводит к выходу из строя или длительной недоступности системы хранения и хранимых на ней данных. Обычно каждая дисковая группа закреплена за каким-то конкретным контроллером, ее обслуживающим (т.н «ownership»), в случае выхода его из строя, операции доступа к дисковому разделу, который обслуживался вышедшим из строя контроллером, перехватываются исправным контроллером, который начинает обслуживать как свои разделы, так и разделы погибшего товарища.
Таким образом, можно говорить, что такая конструкция будет являться «кластером active-passive», потому что несмотря на то, что оба контроллера работают, выполняя операции ввода-вывода, для каждого конкретного дискового раздела один контроллер будет owner-ом, обеспечивающим операции, а второй – резервным, а для другого раздела – наоборот.

Параллельный кластер (active-active)

Параллельный кластер в системах хранения пока представлен единичными продуктами.
Таковыми прежде всего являются кластерные конфигурации систем хранения Network Appliance (двух- и более узловые, в версии Data ONTAP GX до 24 узлов), которые вдобавок могут быть, в отличие от рассмотренных выше, и территориально распределенными: что толку от высоконадежной системы, которую зальет горячей водой лопнувшей ночью батареи?
Такие системы принято называть grid-системами. Компоненты таких систем активно развиваются в настоящее время, например, в OS Linux, и на базе таких систем со специальной Global File System строятся многоузловые вычислительные и “хранительные” кластерные системы.
Без сомнения за grid-системами большое будущее, но пока такие системы (за вышеперечисленными исключениями от того же NetApp) находятся в состоянии экспериментальных.

Одним из камней, лежащих в основании системы хранения NetApp, наряду с собственной версией UNIX-подобной OS, является внутренняя файловая система, собственная разработка компани, под названием WAFL - Write Anywhere File Layout - “Файловая система с записью повсюду” :)

Откуда такое название, и что она дает системам хранения Network Appliance?

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

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

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

К особенностям “программно-аппаратной” реализации файловой системы следует также отнести и “аппаратный журнал” - NVRAM. В отличие от журналируемых файловых систем “обычного типа”, в которых журнал вместе с данными хранится на том же самом диске (обычно в особой области данных), журнал в WAFL размещен в специальном аппаратном устройстве, которым оснащены все системы хранения NetApp - устройстве Non-Volatile RAM, модуле оперативной памяти с батарейным питанием.

Несмотря на то, что блок NVRAM внутри NetApp выглядит очень похоже на Write-back cache у большинства вендоров систем хранения и серверов (плата с модулями DRAM и батареей резервного питания), функция его полностью иная.

Ну и, наконец, важной особенностью и отличием от широкоизвестных журналируемых файловых систем является параллельная поддержка двух схем разграничения доступа, т.н. “UNIX-style” и ACL(Access Control List) или “Windows-style”. Это связано с необходимостью поддержки на одном устройстве как файлов UNIX-”мира”, так и Windows-систем.
Таким образом, работая как NAS, устройства NetApp могут обслуживать как UNIX- так и Windows-машины, обращающиеся к одним и тем же файлам. Взаимное соответствие пользователей двух “миров” настраивается через таблицы взаимных соответствий пользователей, при этом система хранения понимает, что пользователь jmith подключающийся по NFS и DOMAIN\JohnSmith (или johnsmith@domain.local) это один и тот же человек, и соответствующим образом разрешает ему доступ к данным вне зависимости от того, как он в систему хранения попадает, через NFS или CIFS.

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

Подробнее (и по-английски) об устройстве файловой системы WAFL можно подсмотреть тут:
File System Design for an NFS File Server Appliance
Dave Hitz, James Lau, & Michael Malcolm | Network Appliance | TR 3002 http://www.netapp.com/library/tr/3002.pdf

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

А так можно честно делать вид, что в рабочее время повышаешь свой профессиональный уровень чтением англоязычных материалов ;)

Sanjay Gulabani - I currently work with Network Appliance Inc on all things related to Databases. Prior to joining NetApp in Jan 2005, I worked for 8+1/2 years at Oracle Corporation in Redwood Shores, CA. I have been working with NetApp storage since 2004. I have been working with Oracle software since 1994.

Mike Eisler - I co-authored RFC3530, the NFSv4 specification and am currently an editor for the NFSv4.1 specification. I work for Network Appliance on NFS and things related to NFS. I was the primary author for RFC2203, which adds real security to NFS, and led the SEAM project at Sun that produced the first NFS implementation that used Kerberos V5 authentication.

Mark Lewis - EMC Executive Vice President and Chief Development Officer.

Anil Gupta - Storage Systems Engineer providing professional services and field support for Quantum (formerly ADIC).

Chuck Hollis - has been with EMC for 12 years, and is Vice President of Technology Alliances at EMC. He frequently speaks to customer audiences about a variety of technology topics, and can usually be counted on for an interesting point of view.

Hu Yoshida - vice president and CTO of Hitachi Data Systems, responsible for defining the technical direction for Hitachi Data Systems. He was instrumental in evangelizing Hitachi’s unique approach to storage virtualization which leverages existing storage services within the Hitachi Universal Storage Platform and extends it to externally attached, heterogeneous storage systems. Prior to joining Hitachi Data Systems in 1997, Yoshida spent 25 years with IBM’s storage division, where he held management roles in hardware performance, software development and product management.

Jonathan Schwartz - chief executive officer and president of Sun Microsystems, and a member of Sun’s board of directors. He became Sun’s CEO in 2006, succeeding the Company’s co-founder and current chairman of the board, Scott McNealy.

Dave Hitz -Vice-president, co-founder and visionary of Network Appliance.

Brian Mitchell - NetApp Pre-Sales Engineer at Arrow Enterprise Storage Solutions with 12 years of enterprise infrastructure experience.

Filer Jedi -The story of one man, and his job managing NetApp Filers.

Ну и, наконец, кошмарно выглядящий, но все еще самый популярный майллист и его веб-архив Toasters Administrators.

Надеюсь вам, как и мне, будет что почитать.

Зачастую камнем преткновения в анализе производительности системы хранения является замер текущей производительности дисковой подсистемы в IOPS. Без таких данных очень сложно, а порой и невозможно спроектировать адекватную систему хранения для имеющихся данных. Ошибка в оценке необходимого уровня производительности может напрямую исчисляться в тысячах долларов, ушедших в «молоко» при создании системы с «перелетом», и не меньших тысячах долларов потраченных на систему, не выполняющую своих задач в случае «недолета».
Грубой оценкой, но, как правило, достаточной для оценки текущей производительности для базы данных или иной системы, будут показания штатного Performance Monitor (perfmon) из Windows Server.

В запущенном perfmon к имеющимся по умолчанию счетчикам Pages/sec, Avg.Disk Queue и %Processor следует добавить из группы Physical Disk параметры Disk Reads/sec и Disk Writes/sec для нужного диска (в том случае если исследуемая активность принадлежит одному физическому диску, если же нет – те же параметры из группы Logical Disk). Таким диском может быть, например, диск, содержащий базу данных, почтовую базу или любую другую информацию, которую вы намерены перенести на внешнее хранилище. Обратите внимание, что по умолчанию выбирается общая активность всей дисковой подсистемы (_Total).
Очевидно, что сумма значений по Disk Writes/sec и Disk Reads/sec будет приблизительно искомой величиной в IOPS.

Если же мы хотим не просто посмотреть загрузку по IOPS, а провести продолжительный анализ, например для вывявления пиков загрузки и средней величины, то следует воспользоваться так называемыми «журналами счетиков» того же perfmon.
В Performance Logs and Alerts выбрать «Журналы счетчиков» и создать новый журнал с типом данных, например, csv. Добавить в этот журнал уже знакомые нам объекты Disk Reads/sec и Disk Writes/sec и установить желаемый интервал сбора данных. Следует обратить внимание, что включение счетчиков диска немного, но все же снижает общую производительность дисковой подсистемы дополнительной нагрузкой, это имеет смысл учитывать в интерпретации итоговых значений. Кроме того, слишком малый интервал считывания данных хоть и даст более детальный отчет, но, возможно, излишне нагрузит систему и даст черезмерно объемный файл журнала. Считывания раз в 3-5 секунд будет вполне достаточно. Для больших длительностей замеров имеет смысл выбрать большие интервалы, вплоть до минуты. Позаботьтесь о том, чтобы файл отчета не переполнил отведенное ему место, оставьте систему со включенным журналом регистрации и через искомое время вы получите csv-файл, наполненный значениями загрузки вашей дисковой подсистемы. Путем импорта и обработки в Excel вы сможете извлечь желаемые данные, например, средние и пиковые значения загрузки, время пиковых загрузок.

Полезными для анализа параметрами будут также значения следующих объектов:
Disk Bytes Read/sec и Disk Bytes Write/sec – показывают скорость передачи данных с диска. Должны быть близки к величине Disk Reads/sec и Disk Writes/sec помноженных на размер блока файловой системы. Показывают скорость передачи данных с диска. Полезно будет также отметить характер доступа, соотношение операций чтения к записи.
Avg.Disk Queue – показывает величину «очереди запросов» к диску. Значение длительно удерживающееся заметно выше 1,5..2*количество шпинделей дисков показывает перегруженную дисковую подсистему или дисковый контроллер, величина показывает количество запросов стоящих в очередь к диску и ожидающих его освобождения после выполнения предшествующих запросов.
%Processor – постоянная загрузка выше 60%-80% показывает слабость имеющегося процессора для выполняемой задачи, либо наличие какой-то «паразитной» загрузки сервера посторонними задачами.
Pages/sec – показывает количество считываний и записей «страниц» в памяти для того, чтобы добраться до нужной для проводящийся в данный момент операции. Резко отличающиеся величины при работе указывают на недостаток оперативной памяти, приводящей к постоянным операциям «paging»-а, переключения страниц, снижающего быстродействия. Величина должна быть близка к нулю в нормальном, непиковом состоянии.

Большое количество специфичных для себя счетчиков добавляет в perfmon установка MS SQL и MS Exchange. Среди них можно обнаружить объекты, измерение которых может помочь детализировать данные по отдельным базам данных или по определенным операциям.
Полное описание всех средств Performance Monitor в Windows Server далеко выходит за рамки этого обзора поэтому ограничимся вышеприведенным.
??нтересующихся можно отослать к следующим статьям:

«Семь наиболее полезных счетчиков эффективности» (SQL.ru)
http://www.sql.ru/articles/mssql/02111903PerformanceCounters.shtml
«Счётчики производительности SQL Server и Windows»
http://www.sql.ru/articles/mssql/03121001PERF_COUNTERs.shtml

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

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

Вопросы, на которые вы должны быть готовы ответить.
«Уроки разговора с интегратором на одном языке»

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

Вопросник (и примеры ответника):

1. Каков общий объем хранения, запланированный для данной системы?
   Пример ответа: ориентировочно 1200 GB
2. Каков планируемый прирост хранения в течении года?
   Ожидается от 80% до 100% прироста в течении ближайшего года-полутора.
3. Каков характер хранимых данных?
   Основной объем – свыше 650GB – база данных MS SQL (OLAP), около 200GB пользовательских данных типа «личные папки», файловые архивы и дисковые бэкапы, 350GB – MS Exchange.
4. Каков характер доступа к данным, есть ли явно выраженные пики загрузки?
   Основной тип характера нагрузки базы данных – OLTP, средняя установившаяся в течении рабочего дня нагрузка около 500 IOPS.
   В последние дни каждого месяца база данных активно генерирует отчеты, что вызывает примерно в 6-8 раз более высокую загрузку, чем в среднем за месяц. В 9 утра активность почтовой базы примерно вдвое выше чем в среднем по дню.
5. Как организовано хранение сейчас?
   Локально подключенные к серверам диски SCSI и SATA.

Основные типы хранения данных и где они встречаются.

Очевидно, что само по себе значение «100 гигабайт» ничего не дает с точки зрения понимания того, что именно с этими гигабайтами происходит.
Основные типы данных делятся на:

1. Архивное хранение.
   Данные с редким (но иногда большим по объему) доступом. Архивы, дистрибутивы программ, дисковые бэкапы.
2. «Личные папки и документы».
   Данные с небольшим по объему, но регулярным доступом (один клиент доступа на один файл/папку), при этом, как правило, критичные к скорости этого доступа. Сетевые папки, рабочие файлы.
3. Совместно используемые документы.
   Документы на общих дисках и сетевых папках, хранилище Sharepoint. Множество клиентов доступа к одному файлу/папке.
4. Почтовые системы и их базы.
   Базы MS Exchange (Lotus Notes/Domino, различные Internet Mail System) или иных почтовых и collaboration систем.
5. Базы данных с типом доступа «DSS» - Decision Support Systems.
   Базы данных с объемной последовательной загрузкой-выгрузкой данных. Такой характер имеют системы записи данных видеомониторинга и охраны, а также видеообработка и монтаж.
6. Базы данных с типом доступа «OLAP/OLTP» -OnLine Access/Transaction Processing.
   Базы данных ERP, CRM-систем, базы данных интернет-сайтов и магазинов.

Хо-хо, что у меня есть оказывается.

Это старинные машинки NetApp периода “каменного века”. Вот как и с чего оно все начиналось.

Что интересно, вот ту, которая называется F87 (год выпуска 2002 ?), однажды, пару лет назад, пришлось поднимать к жизни. Поразительно, но факт: на нее удалось залить свежую версию Data ONTAP G7, и она нормально заработала. Удивительное свидетельство отношения NetApp к совместимости и поддержке даже такого, относительно старого, и много лет как неподдерживаемого официально, железа. Вместе с G7 появились все “бонусы” новой OS, такие как FC, iSCSI (как и вообще SAN), репликация, FlexVol и так далее. Заводи и поехали.

Да, конечно, для системы с шестью SCSI-дисками на 36GB это, наверное, не особенно актуально, но сам факт - поражает.

Для интересующихся, что там было внутри: http://en.wikipedia.org/wiki/NetApp_Filer

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

Для начала следует определить два основных общепринятых понятия, используемых для измерения производительности.
Первый из них – Input-Output Operations Per Second – IOPS - показывает количество операций ввода-вывода в секунду, которые способно обработать устройство. Этот параметр прежде всего характеризует скорость обработки коротких запросов, и наиболее часто применим для оценки таких задач, как OLTP-база данных и близких к ней.
Операции базы данных как правило характеризуются обменом относительно небольшими блоками (как правило 4-8KB). Каждая такая операция по считыванию или записи блока является одним IOPS-ом. Таким образом, чем выше показатель производительности в IOPS, тем выше производительность базы данных.

Другим параметром, характеризующим производительность, является Скорость передачи данных, так называемый traffic throughput, измеряемый в MB/s, то есть количеством мегабайт, проходящих по интерфейсу ввода-вывода в секунду.
Этот параметр характеризует скорость обработки в случае больших блоков, классическая задача, для которой критичен именно параметр MB/s, это аудио-видео обработка, резервное копирование и DSS-базы данных.

Какой же из этих параметров более «правильный», какой более важен? Разумеется оба.
Однако следует понимать, что оба этих параметра связаны между собой «обратно пропорционально». Увеличение величины в IOPS вызывает снижение величины в MB/s и наоборот.

Чтобы понять почему так, нужно рассмотреть простой пример и аналогию.
По дороге следует переместить из А в Б большое количество человек. Возможно два варианта: мы можем перевозить их в их личных автомобилях или же усадить в автобусы. Пропускная способность дороги конечно же будет выше в случае перевозки людей автобусами, то есть «большими блоками». Однако методы общественного транспорта обычно вступают в конфликт с индивидуальными целями и маршрутами. Хорошо если в Б у нас огромный завод, на который устремлен основной поток из А. Можно погрузить все «байты» в один большой пакет-автобус на входе, и выгрузить его на остановке у завода, куда собственно и направляются все наши «байты».
Однако если наши байты не едут на завод, а разъезжаются по индивидуальным и независимым делам-«операциям», каждый имея индивидуальный маршрут, то доставка их «автобусом»-большим пакетом приведет напротив к большим потерям времени. В этом случае транспортировка индивидуальными автомобилями будет более выгодна. Однако общий пропускной объем дороги заполненной индивидуальными «пакетами»-авомобилями везущими по нескольку байт каждый, разумеется будет ниже, чем при перевозке большим пакетом-«автобусом».
Таким образом увеличение пропускной способности в MB/s за счет укрупнения пакетов приводит к снижению IOPS, и наоборот, рост операций в секунду «доставленных к цели пассажиров» нашей дороги-интерфейса, запруженной автомобилями, приводит к снижению ее пропускной способности в MB/s. Нельзя одновременно достичь высоких показателей в IOPS и в MB/s просто по физическим свойствам существующего оборудования.
Либо большие пакеты-«автобусы» и их мало («операций в секунду»), либо маленькие индивидуальные пакеты-«автомобили», каждый осуществляющий индивидуальную «операцию» по доставке данных, но заполняющие всю дорогу, и общий human traffic в результате невелик.

Отсюда видно, что широко разрекламированная величина пропускной способности интерфейса SATA-II дисков в 300MB/s далеко не всегда (а чаще и вообще никогда) не будет достижима на практике. Более того, в случае использования таких дисков для операций с базой данных OLTP роль будет играть не столько потоковая производительность интерфейса, сколько гораздо реже публикуемая максмальная величина IOPS диска, в настоящий момент равная для SATA 7200rpm примерно 50 IOPS, и в случае OLTP-нагрузки выиграет не диск с самыми высокими данными по мегабайтам в секунду, а самый быстродействующий по IOPS - параметру, напрямую связанному с рассмотренной выше «латентностью», такой как, например, диск с интерфейсом FC и скоростью вращения 15Krpm, для которого величина IOPS достигает 200. При прочих равных диски SATA всегда проиграют в случае работы с базой данных не только дискам FC, но и традиционным SCSI.
Однако в случае использования дисков на задачах считывания и записи аудио-видеоданных, или резервного копирования, характеризующихся большим и постоянным потоком данных большими блоками, диски SATA вполне могут быть не хуже значительно более дорогостоящих FC или SCSI, легко выигрывая у них за счет цены за хранимый мегабайт.

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

Несколько слов о новой технологи, объявленной компанией NetApp 15 мая, которая называется A-SIS (Advanced Single Instance Store), представляющей собой функцию внутреннего дедупликатора (de-duplication) хранимых блоков.

Аналогичный продукт сейчас продвигает на рынок молодая компания Data Domain. Это так называемый “стартап”, компания, обычно концетрирующаяся на каком-то узком сегменте, “компания одной фичи”. Data Domain - дедупликация, 3PAR - thin provisioning, и так далее. Бизнес-целью таких компаний является, как правило, продажа себя кому-то из грандов и вхождение “фичи” в продуктовый портфель более крупного вендора. Для NetApp такими компаниями были за последние несколько лет Spinnaker (с использованием его разработок получается потихоньку система нового поколения DataONTAP GX), Alacritus (система эмуляции ленточных библиотек поверх дисковых систем - VTL - Virtual Tape Library), DECRU (система потокового прозрачного шифрования траффика), последним приобретением на сегодня была компания TopIO, занимающаяся host-based репликацией в гетерогенных средах.
??з последних приобретений конкурентов нельзя не отметить покупку компанией Hitachi Data Systems компании BlueArc с очень интересным высокроизводительным NAS-решением, совершенную после малоудачных попыток разработать самостоятельный NAS на базе Open Software-решений.

Но, так или иначе, каждый из стартапов это “компания одного продукта”. Обычно стартапу просто не хватает финансовых “сил” разрабатывать и поддерживать полнофункциональную линейку продуктов на рынке. Однако приобретение стартапа более мощным игроком обычно идет на пользу всем. Команда стартапа получает зачастую неограниченные финансовые ресурсы для развития, вендор быстро получает самые современные достижения в отрасли, укрепляя свое присутствие, мы же, как потребители - хороший продукт, который мог бы и не состояться без этой встречи.
Характерным примером приобретения стартапа “корпорацией” является судьба компании VMware, которая войдя “под крыло” EMC создает сейчас наверное один из интереснейших и “change-the-world”-продуктов современного IT-рынка.

Однако традиционная слабость продуктов-стартапов вытекает из того же самого.
- Что делает 3PAR? - Они делают хороший thin provisioning! - А чем-нибудь еще их системы привлекательны? - М-м…
Аналогичная ситуация сложилась с уже упомянутым Data Domain. Да, передовая технология дедупликации данных. Сама по себе - да. Но что-то еще? Большой вопрос.
Шума конечно много, ведь, как я писал выше, одна из обычных бизнес-целей стартапа это продажа себя в качестве команды-разработчика.
Либо дальнейший (часто весьма нескорый) выход на IPO, ведь и сам NetApp когда-то давно, в 1992 году, тоже был таким молодым “стартапом”, решившим однако бороться с “акулами” самостоятельно.

В этом смысле NetApp имеет отличную позицию, ведь его системы хранения есть сами по себе продукты, насыщенные функционалом, и появление еще одной “фичи” есть лишь дополнительный плюс, но отнюдь не “единственное блюдо на столе”.
Этим она существенно отличается от систем той же Data Domain (3PAR, XIOtech, XenData, etc.).

Однако при всей сногсшибательной привлекательности A-SIS как технологии необходимо помнить и о присущих ей “подводных камнях”. Кроме ряда несовместимостей, сохраняющихся пока для систем хранения NetApp, таких как возможность использования только traditional volumes вместо FlexVol, ограничения на размер хранения, есть еще серьезная проблема, связанная с самим принципом блочной дедупликации.
Если множество блоков в различных LUNах или файлах, записанных на сторадже на протяжении последних пары лет, ссылается за содержимым на блоки, однажды записанные в некоем разделе, то потеря содержимого этого раздела приведет к потере непредсказуемого количества блоков во множестве прочих разделов, то есть к фактическому разрушению стораджа (вернее, используемого A-SIS тома) целиком.
Это может быть не столь критично для хранения дисковых бэкапов (и в первую очередь именно на этот сегмент эта опция нацелена), однако нужно очень хорошо взвесить все за и против, прежде чем принимать решение об использовании дедупликации для primary storage.
Да, конечно, в NetApp есть RAID-DP, есть внутренняя и междусистемная репликация, то есть удвоив занимаемое место за счет “зеркала”, дополнительно защитившись от потерь данных, мы получаем возможность использовать десяти-двадцатикратный эффект экономии места от дедупликации, но тем не менее тщательно подумать над этим стоит, поскольку A-SIS все же не “серебряная пуля”.
Описанной проблемой с потерей “вторичных” блоков-линков в результате повреждения “первичных” блоков-данных страдают все существующие в настоящий момент модели дедупликации.