Что-то как-то не получилось у меня опубликовать вторую часть "на следующей неделе", как я было пообещал в конце части первой. Так получилось, что я понял, что статья получается объемной, многие вещи требуют "экскурса и дискурса", а объяснить на пальцах понятно их не получается. Но когда я начал регулярно находить в поиске запросы "запускаем новую систему хранения часть 2 site:blog.aboutnetapp.ru", я понял, что тянуть дальше нельзя.
Посему, вот вам вторая, а еще, может быть, даже и третья далее часть.
Остановились мы в прошлый раз на процедуре начального запуска. Железка поставлена в стойку, ей задан IP для конфигурирования, и проведена самая первая, базовая настройка только полученной системы, к ней уже можно подключиться с помощью System Manager, через веб-интерфейс, или же простой консолью по COM-порту или телнетом по сети.
Далее нам надо сконфигурировать собственно объем хранения. ?? тут есть некоторая сложность, о которой я сейчас попробую в общих чертах рассказать.
Я уже писал в этом блоге об одной особенности двухконтроллерных систем хранения NetApp, особенности, с которой часто сталкиваются начинающие, особенно если ранее он не имели дела с такими системами, и с такой организацией дисков.
Дело в том, что системы хранения NetApp в двухконтроллерной конфигурации High Available Cluster (HA-cluster, в дальнейшем) используют модель работы "share nothing", и, согласно ей, не используют диски совместно. Каждый из двух контроллеров системы хранения должен владеть своим набором дисков. То есть имеющееся количество дисков должно быть между ними поделено (поровну или нет - об этом далее). Доступ к дискам возможен только через владеющий ими контроллер, и никак иначе.
Конечно, в случае выхода из строя контроллера, как и полагается для HA-кластера, второй, выживший контроллер, перехватит на себя диски вышедшего из строя, но только в случае неработоспособности, выхода из строя контроллера. Когда контроллер работает нормально, то доступ к дискам, "приписанным" к нему, осуществляется только через работающий контроллер-владелец . Это необходимо для правильного диспетчерирования запросов чтения и записи данных с дисков.
Да, обратившись к "не тому" контроллеру вы, конечно, можете получить данные с дисков, приписанных другому контроллеру, но для этого "ваш" контроллер должен обратиться к "тому" контроллеру, чтобы он прочел и передал "этому" запрошенные данные по внутренней шине, а потом "этот" отдаст их вам. Это неоптимальный путь доступа, о котором сторадж вам сообщит в логах, и который иногда встречается при неправильной настройке, и о том, что с этим делать и как исправить я уже писал в блоге ранее.
Так что, в общем случае, вы можете вообразить себе двухконтроллерную систему NetApp как два отдельных (пусть и связанных) файловых сервера NAS, например, каждый со своим набором ресурсов, каждый со своим IP-адресом, по которому происходит обращение, и так далее. В случае SAN это также происходит сходным образом.
??з этого следует, что, по сути, в случае двухконтроллерного NetApp FAS2020 вы получаете не одну систему хранения на 12 дисков, а две на 6 дисков каждая (или 3 и 9 дисков, или 5 и 7 дисков, но всегда две). ?? это довольно существенный момент, который требует осознания. Более того, нельзя отдать одному контроллеру все 12 дисков (это можно в случае одноконтроллерной системы, но не двухконтроллерной, в которой второй контроллер требует наличия хотя бы одной RAID-группы минимального размера (2 диска в RAID-4) и хотя бы одного hotspare, так как на этой группе он должен записать свои собственные конфигурационные данные, иначе он не сможет загрузиться, просто не с чего.
Тему с разбиением дисков по контроллерам, и выбором между равным и неравным разбиением дисков я уже затрагивал в этом блоге, поэтому интересующихся отошлю к более ранним статьям.
Сейчас же мы перейдем к конфигурированию.
??так, мы, руководствуясь частью первой установили систему физически и провели первое включение. Теперь, если вы посмотрите на видимые системе диски, вы увидите, что каждому контроллеру доступен свой набор дисков. Скорее всего вы получите с завода систему, сконфгурированую в виде 5 дисков доступных одному контроллеру и 7 - другому (по крайней мере я видел именно такой вариант поставки FAS2020A).
Если вы читаете этот блог давно, то уже знаете, что такое у NetApp так называемый aggregate. Это структура, в которую включаются физические диски, приписанные одному контроллеру, и которая объединяет RAID-группы, к созданию которых администратор системы хранения не имеет непосредственного доступа. Поверх структуры aggregate уже располагаются непосредственно тома (volumes типа FlexVol), на томах qtrees и в них, или непосредственно на томах - LUN-ы, если вы используете NetApp как SAN-сторадж, или же network shares, если используете его как NAS. В общем яйцо в утке, утка в зайце, заяц в сундуке :)
Но в основе всего - aggregate. Несмотря на то, что в системах NetApp осталась legacy-возможность использовать "классические" RAID, это осталось "для совместимости", и нет совсем никаких причин этим пользоваться сегодня.
Будем пользоваться FlexVol и aggregates.
Два основных преимущества aggregate и его использования заключается, во-первых, что при этом операции ввода-вывода распределяются равномерно по всем входящим в него дискам, даже если вы используете маленький том на несколько десятков мегабайт, или несколько таких томов, то все они будут физически "размазаны" по всем дискам aggregate, с соответствующим положительным эффектом на их быстродействие. ??, во-вторых, он позволяет создавать тома произвольного размера, отвязавшись от размеров физических дисков и RAID-групп.
??з пункта 1 следует естественный вывод, делать как можно большие аггрегейты, из максимально доступного количества дисков.
В некоторых руководствах NetApp, ориентированных, прежде всего, на большие системы с сотнями дисков, вы можете встретить рекомендации создавать более одного aggregate, например выделять на отдельный aggregate так называемый root volume, на котором находится директория /etc внутренней файловой системы и ее настройки, а также создавать отдельные aggregate для сильно различных видов паттерна нагрузки (например отделять базу данных, с обычно random read/write access, от ее логов, с sequental write), но это рекомендации, повторюсь, для "хайэнда", для систем с сотнями дисков, когда эти рекомендации действительно дают заметный эффект. Если вы запускаете систему с количеством дисков в пределах пары десятков, безусловно наилучшим выбором будет помещать все диски в один большой aggregate, где будут находиться все тома пользователя, включая и root vol. Дробя диски по нескольким aggregates при небольшом количестве этих дисков, следуя рекомендациям для "старших" систем, вы скорее ухудшите ситуацию, уменьшив количество дисков, по которым удастся размазать ввод-вывод, чем улучшите его изолируя трафики.
Поэтому решим использовать один aggregate на контроллер (соответственно, два на кластерную пару, по одному на каждый контроллер). Поскольку вы систему уже запустили, этот aggregate у вас уже создан, на нем помещен системой root volume.
Обычно он называется aggr0, и я предлагаю, если у вас остались невключенные в него диски, добавить их в него командой aggr add (диски). Сделайте то же самое на втором контроллере.
Сейчас структура данных на вашей системе хранения выглядит так:
Обычно том vol0, в котором по умолчанию располагается root vol и директория /etc с настройками внутренней OS Data ONTAP делается с большим запасом. Если вам жалко места, то можете безопасно уменьшить размеры тома vol0, например для различных версий Data ONTAP и разных систем рекомендуется его размер от 10GB для FAS2020, 16GB для FAS2040 (для Data ONTAP 7.x), и до 250GB для старших систем под версией 8.х OS Data ONTAP.
На root vol, кроме настроек, также хранятся прошивки полок и дисков, обновляемые автоматически, а также должно быть место для аварийного сброса kernel dump в случае каких-то нештатных ситуаций.
Все же остальное место на aggregate, за вычетом примерно 10%, которые рекомендуется не занимать для облегчения жизни внутренних процессов и правильной и беспроблемной работы, например, фонового оптимизатора структур WAFL, можно использовать под хранения ваших данных в одном или нескольких томах. Хотя размер тома можно задать и сразу, во многих случаях имеет смысл настроить его на автоматическое увеличение, тогда том будет автоматически расти, по мере заполнения его данными, пока хватит места на хранящем его aggregate, а свободное место не будет заниматься на "хранение нулей", если вы можете отдать его более нуждающимся задачам. Эта настройка называется space reservation (none или file), а возможность автоматического роста тома - volume autogrowth, которую можно задать с желаемым шагом приращения.
Нельзя сказать, что я открыл вам все серветы и тайны конфигурирования NetApp, но, с имеющимся базисом и дружа с документацией, вы уже сможете самостоятельно запустить систему хранения.
А в следующей части мы рассмотрим как создавать сетевые ресурсы для NAS и LUN-ы для SAN.