about NetApp

Далее переходим к созданию aggregate (вернее создание RAID и aggregate это чаще всего один этап).

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

В ряде особых случаев, некоторые рекомендации Best Practices говорят о необходимости создавать отдельные aggregates для сильно различных типов нагрузки, с тем чтобы одна из нагрузок совершенно не влияла на тома с другим типом нагрузки.
Однако в подавляющем количестве случаев, и в случаях, когда диски ваших систем не исчисляются сотнями, рекомендация заводить все физические диски в один aggregate, а уже потом разбивать емкость на отдельные volumes, дает наилучшие результаты.

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

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

Рассматривая аггрегейты, давайте остановимся на нетапповской специфике. Знакомые с системами хранения от EMC и Hitachi уже знают некоторую особенность дисковой организации на таких системах. На нескольких дисках такого стораджа размещается некая “служебная область”. Там, например, хранится содержимое внутренней OS системы, туда, например, делается “слив” содержимого кэша в случае выключения, и так далее, подробности обычно не объявляются, и область эта закрыта.
Например у EMC Clariion CX4 с каждого из 5 дисков, отведенных системой под эти нужды (так называемый Vault), отнимается по 62GB (в CX3 - 33GB), то есть “минус 310 MB” на систему в целом.
Такая схема, кроме всего прочего, заставляет при создании RAID, выделять эти 5 дисков (4 в случае Hitachi модели AMS) в отдельный RAID, так как в противном случае они уменьшат размер всех остальных дисков в этом RAID на те же 62GB, ведь объем всех дисков в RAID должен быть абсолютно равный.

Нечто подобное есть и у NetApp. Он хранит настройки системы (для знакомых с UNIX-ами скажу: раздел /etc UNIX-подобной файловой системы ядра) на самих дисках системы хранения. Остальная OS Data ONTAP находится и грузится с Compact Flash-карты, так как она совсем небольшая, несколько десятков мегабайт на все.

По умолчанию этот /etc хранится на своем собственном aggregate (aggr0), состоящем из двух (в случае RAID-4) или трех (RAID-DP) дисков: диск данных, один или два диска parity. На этом aggregate создается том vol0, на котором и лежит около 200 мегабайт содержимого этого самого /etc: настройки, конфигурационные файлы, прошивки firmware для дисков, и так далее.
Такая схема позволяет, в частности, легко переносить данные между системами хранения, а также, в случае необходимости, заменять и апгрейдить контроллер, так как вся конфигурация конкретной системы, по сути, от ее контроллера отделена. В случае замены “головы”, новый контроллер загружает “конфигурациенезависимое” ядро, монтирует к нему /etc, прочитывает оттуда конфигурацию текущей системы - и готово.

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

Для системы с небольшим количеством дисков и невысокой предполагаемой загрузкой бывает жалко отдавать отдельный aggregate и целых два-три диска только под служебную директорию размером в несколько мегабайт, особенно если используются большие диски, например при дисках SATA 1TB вы теряете на первом aggregate 1 или 2 TB на диски parity, и еще один диск под служебный vol0, пусть на нем и можно хранить данные. Все равно это минус 2-3 диска целиком, из общего количества.

В этом случае можно порекомендовать создать единый aggregate, в который войдут все диски системы, и уже на нем выделить vol0 под системный раздел.
В этом случае общая производительность вашего aggregate увеличится на величину 2..3 * IOPS одного диска, ведь, как я писал выше, общая нагрузка ввода-вывода в aggregate расделяется поровну по всем входящим в него дискам.

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

Продолжение как всегда следует в следующий понедельник.