Требования к производительности

• Дисковый массив должен обеспечивать производительность N IOPS, а агрегированная пропускная способность массива должна составлять M МБ/с. Как уже отмечалось, получить такие цифры не просто. Если существует прототип системы или выбор дискового массива осуществляется для модернизации существующей СХД, то можно провести "натурные" замеры производительности и аппроксимировать их для ожидаемого роста нагрузки на СХД. Если система создается с "нуля", то можно попытаться получить эти цифры в качестве требований производителя прикладного ПО (что практически не реально) или обраться к производителям массивов, чтобы те провели определение требуемых параметров массива (sizing). Обычно производители имеют методики "грубой" оценки требуемой производительности. Но входными данными для этих методик, как правило, служат ожидаемое число транзакций и их "вес" (light, medium, heavy), которые тоже не всегда можно определить.
• Специфические функции управления кэш-памятью массива. Например, к таким функциям относятся:
• возможность закрепления участка кэш-памяти за конкретным LUN (может пригодиться для размещения в кэш часто используемых служебных таблиц базы данных);
• отключение использования кэш на запись и/или чтение для конкретного LUN (может потребоваться для DSS-задач);
• обеспечение уровня сервиса в виде заданного уровня производительности (IOPS) или пропускной способности (МБ/с) для указанного сервера.

Требования по отказоустойчивости и надежности хранения данных

• Поддержка нужных уровней RAID. Как правило, это уровни 1, 0+1,1+0 и 5.
• Наличие дисков "горячей замены" (hot-spare). Механизмы использования hot-spare дисков могут быть разные. Например, возможен вариант, когда в случае отказа диска данные из дисков затронутой RAID-группы копируются на hot-spare диск. Но также возможен вариант, когда нет специально выделенного hot-spare диска — все диски содержат данные, но при этом на всех дисках выделена резервная область, куда копируются данные с поврежденной RAID-группы. Определение требуемого метода опять же за проектировщиком.
• Защита участков кэш-памяти, обслуживающих операции записи. За исключением тех случаев, когда отключен кэш на запись, сервер получает подтверждение завершения операции записи сразу после попадания данных в кэш-память еще до записи их на диск. Для обеспечения целостности данных обычно применяются следующие методы:
• Зеркалирование участков кэш-памяти, обслуживающих операции записи.
• Поддержка батареями кэш-памяти в течении N часов или сохранение ее содержимого на диски в случае отключения внешнего питания. Какой из указанных вариантов определить в требованиях — задача проектировщика.
• Дублирование всех компонентов и отсутствие единой точки отказа (SPOF). Степень важности этого требования зависит от режима работы системы и требований к доступности сервисов. Однако, не надо забывать, что сам массив является SPOF, если он не задублирован другим массивом.

Возможность создания PIT-копий данных для использования их в системе резервного копирования. В ряде систем, где обрабатываются большие объемы данных (терабайты), а сервисы должны быть доступны 24х7 при больших нагрузках, необходимо применять Serverless резервное копирование. Для этого используется механизм создания PIT-копий средствами дискового массива.

Требования по обслуживаемости

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

Требования по масштабируемости

• Наращивание дискового пространства до N ТБ без замены ранее установленных дисков. Такая формулировка позволяет "убить двух зайцев" — обеспечить требуемую функциональность СХД при росте объемов обрабатываемых данных и сохранить сделанные инвестиции. Здесь может быть добавлено требование: "без потери производительности". Архитектура массива (об этом речь пойдет ниже) может стать "узким местом" и привести к тому, что при очередном добавлении дисков производительность массива существенно снизится, что повлияет на уровень качества сервиса.
• Расширение размера LUN путем добавления новых дисков без разрушения хранимых данных. Это требование важно не только для систем, работающих в режиме 24х7, но также когда имеется дефицит квалифицированного персонала, способного осуществить расширение дискового пространства при отсутствии у массива данной функции. Желательно, чтобы операционная система, данные которой хранятся на расширяемом LUN, могла автоматически расширить свою файловую систему.
• Увеличение числа подключаемых серверов до N.
• Увеличение объема кэш-памяти до N ГБ без замены ранее установленных модулей.