about NetApp

Как вы знаете, я убежденный сторонник того, что системы хранения NetApp – это лучший выбор для использования в среде серверной и десктопной вируализации. А для самой этой виртуализации – использование протокола NFS, который для систем NetApp, более чем родной, в свою очередь, лучший способ подключить дисковое хранилище. Со мной согласны уже 36% пользователей систем виртуализации (согласно отчету Forrester за май прошлого года), причем процент использования NFS растет, и уже превысил процент использования iSCSI (23%) на этих задачах.

Я уже не раз писал в этом блоге про различные аспекты использования NFS (посмотрите старые статьи по тегу NFS), и даже переводил на этут тему Best Practices (про Ethernet Storage вообще и про VMware в частности), однако все это были разрозненные публикации “к случаю”. Мне захотелось собрать основные темы вопроса в одном месте, и обсудить их, наконец, “раз и навсегда”, или пока тема не изменилась значительно.

Но для начала несколько вводных слов, для тех, только что подключился к блогу.

NFS (Network File System) – это протокол “сетевой файловой системы” разработанной компанией Sun в глубокой исторически-компьютерной древности, и предназначенный для доступа к данным в файлах по сети, в том числе для совместного доступа к ним от нескольких клиентов. NFS, вследствие своей сравнительной простоты реализации, стал очень популярным в UNIX-мире, где работу по NFS поддерживают практически любые OS. Несмотря на то, что сегодня “файловой системой” обычно принято называть нечто иное, за протоколом доступа к файлам по сети, NFS, исторически закрепилось название “файловая система”.  С момента своего изобретения, NFS прошел большой путь, и на сегодня достиг версии 4.2, обретя множество важных на сегодня возможностей, таких как использование не только UDP, как первоначально в исходной версии протокола, но и TCP (в v3), улучшенные технологии разграничения доступа и безопасности (v4), поддержка распределенных кластерных и объектных хранилищ (v4.1) и различные методы offload-а (v4.2).

К сожалению, за NFS водится два своеобразных недостатка. Во-первых, он так и не появился в OS семейства Windows (если не считать крайне проблемной реализации, вышедшей в составе продуктов MS Services for UNIX) и остался “чужим и непонятным” для win-админов. ?? второе, но более важное, не все его реализации “одинаково полезны”. Многие пользователи, познакомившиеся с NFS через имеющую кучу проблем с производительностью и стабильностью, широкораспространенной реализацией в Vanilla Linux, считают, что “весь NFS такой, глючный, тормозной, для продакшна не пригодный”. А это не так.

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

А теперь о достоинствах. Во-первых следует отметить сравнительную простоту использования NFS. Его использование не требует внедрения и освоения сложной, особенно для новичка, FC-инфраструктуры, непростых процессов настроек зонинга, или разбирательства с iSCSI. ??спользовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS это обычная монтируемая на хост сетевая “шара” с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает, например, резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы “автоматически” получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, оно становится доступно непосредственно администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2TB, даже с VMFS ранее 5, а это очень полезно, например, если вам приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. ??х всех можно поместить на один большой датастор, бэкапить, и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2TB(-512bytes) каждый.

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

Однако, какие у нас имеются минусы?

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). ??спользование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые, в случае блочного SAN, реализуются на стороне хоста, в случае NFS поддерживатся стораджем. Это всяческие блокировки, разграничение доступа, и так далее. Однако, практика показывает, что оверхед отражается на производительности крайне незначительно.

Большим плюсом использования NFS на стораджах NetApp является то, что выбор NFS там не диктует вам “жесткого выбора” для вашей инфраструктуры в целом. Если вам понадобится также и блочный протокол для RDM, или для крайне критичной даже к возможному 10-15% падению производительности виртуальной машины, вы можете использовать для нее iSCSI или даже FCP, все на том же сторадже, параллельно с NFS, и всеми его плюсами, для основного датастора.

В следующем посте этой серии мы перейдемь к разбирательству основных недопониманий и мифов, которые имеются вокруг использования NFS в VMware.

Рекомендуется также почитать по теме:

• VMware: Best Practices for running VMware vSphere on Network Attached Storage
• NetApp (RU): Руководство по наилучшим способам использования систем NetApp
  с VMware vSphere
• NetApp (RU): ??спользование NFS в VMware
• NetApp (RU): Ethernet для систем хранения: наилучшие методы
• NetApp (EN): tr-3880 CLI Configuration Processes for NetApp and VMware vSphere.pdf
• NetApp (EN): tr-3697 Multiprotocol Performance Test of VMware ESX 3.5 on NetApp
• NetApp (EN): tr-3808 VMware vSphere 4.1 and ESX 3.5 Multiprotocol Performance Comparison Using FC iSCSI and NFS

Что-то как-то не получилось у меня опубликовать вторую часть "на следующей неделе", как я было пообещал в конце части первой. Так получилось, что я понял, что статья получается объемной, многие вещи требуют "экскурса и дискурса", а объяснить на пальцах понятно их не получается. Но когда я начал регулярно находить в поиске запросы "запускаем новую систему хранения часть 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.

По умолчанию, Data  ONTAP генерирует уведомление (trap) в SNMP, а также записывает сообщение в логах, когда заполненность тома превышает пороговую величину. По умолчанию существует два порога: “Nearly Full” и “Full”. Первый по умолчанию установлен на значение 95%, а второй – на 98% от емкости тома.

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

Для того, чтобы именить значения порогов на нужные вам, надо сделать следующее:

Войдем в режим повышенных привилегий:

netapp> priv set advanced
netapp*>

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

Установим нужные нам значения. Например, пусть это будут 85% и 99%. Помните, что баловаться с системным реестром в Data ONTAP также опасно, как и с реестром Windows!

netapp*> registry set options.thresholds.fsFull 99
netapp*> registry set options.thresholds.fsNearlyFull 85

Можно и вовсе выключить эти уведомления, задав заведомо недостижмый уровень заполнения, больше 100%, например – 101%

netapp*> registry set options.thresholds.fsFull 101
netapp*> registry set options.thresholds.fsNearlyFull 101

Обратите внимание, что парамеры fsFull и fsNearlyFull – чувствительны к регистру.

Проверим, что все установилось так, как мы хотели:

netapp*> registry walk options.thresholds

Вернемся в стандартный уровень привилегий:

netapp*> priv set
netapp>

Готово. Теперь Data ONTAP будет генерировать SNMP traps о заполнении тома по достижении заданных нами величин (или не генерировать их вовсе, если мы их установили на 101%).

Также как и в Data ONTAP 7-mode, в Cluster-mode с версии 8.1 есть снэпшоты. Сохранились все привычные пользователям NetApp команды snap reserve, snap sched, snap list, но добавилось несколько новых команд и возможностей.

Также добавились некоторые дополнительные опции в некоторых командах

Также есть изменения и в способе задания распсания снэпшотов. Если раньше это делалось командой snap sched, указывалост имя тома и задавались интервалы в формате cron, то новый механизм использует политики (policy), которые управляются командами add-schedule, modify-schedule и remove-schedule. Для создания же новой политики взятия снэпшотов воспользуйтесь командой snap policy create.

Я уже упоминал, что в Data ONTAP есть очень полезная команда stats, с помошью котрой можно вывести массу информации о работе системы. К сожалению, формат вывода ее “человеконечитаемый”, в большинстве случаев, поэтому для того, чтобы извлечь из ее вывода что-нибудь полезное, приходится предпринять некоторые усилия.

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

В community.netapp.com я увидел интересную строчку для использования в скрипте вывода такой информации:

watch -n 3 "ssh NetAppHost stats show disk:\*:disk_busy | awk '{FS=\":\"; print \$1 \" \" \$2 \" \" \$3 \" \" \$13}'| sed 's/%//g' | awk '\$4>40{print}'"

Можете воспользоваться, кому интересно, и расскажите как работает.

Когда вы поставили и запустили симулятор Data ONTAP 8, вы увидите, что он идет с 28 (2х14) “дисками”, размером 1GB. Этого в общем вполне достаточно для большинства целей использования, однако, если вам потребуется больше дисков, вы можете увеличить их количество (но не размер!) до 56 штук. Обратите внимание, что вы не можете увеличить размер дисков, он для симулятора не может превышать 1GB. Ну… например чтобы не было соблазна устраивать из не предназначенного для этого симулятора бесплатный “виртуальный сторадж” ;). Как говорил один большой друг СССР – “Doverjai no proverjai!” ;)

Но сперва стоит немного остановится на некоторых деталях.

В отличие от Data ONTAP 7, в версии 8 появился специальный user-mode shell (консоль админа, несмотря на внешнюю схожесть, шеллом как таковым не является). Он доступен для специального, отключенного в целях безопасности, пользователя diaguser.

Мы рассмотрим добавление дисков только для симулятора 7-Mode. Для Cluster-mode это возможно также, но чтобы не удлиннять пост я его опущу (если кому-то понадобится процедура для Cluster-mode Simulator – напишите).

??так, начнем с того, что разблокируем diaguser, от имени которого в шелле мы проделаем операции добавления:

priv set advanced
useradmin diaguser unlock
useradmin diaguser password

Теперь зайдем с systemshell этм пользователем:

systemshell
login: diag
password: <password>

Далее нам придется поправить некий глюк, допущенный при сборке утилиты управления “дисками”. Добавим символьные линки на стандартные библиотеки, а то утилита не сможет их найти:

cd /lib
sudo mount -u -o rw /
sudo ln -s libc.so.6 libc.so.7
sudo mount -u -o ro /

Установим переменную пути:

setenv PATH "${PATH}:/sim/bin"
echo $PATH

?? перейдем в директорию эмулированных устройств

cd /sim/dev
ls ,disks/

Тут вы увидите уже созданные 28 дисков. К ним мы сейчас добавим еще 28. ??мена уже существующих файлов-дисков начинаются с v1 и v2, что означает, что они “подключены” к адаптерам v1 и v2. У нас есть еще два неиспользованных адаптера (v3 и v4), к каждому из которых мы “подключим” по 14 дисков (это похоже на то, как подключаются обычные FC-полки к адаптерам отдельной FC-“петлей”, каждая полка на 14 дисков на свой адаптер).

Для этого воспользуемся утилитой makedisk.main:

makedisks.main -h
sudo makedisks.main -n 14 -t 23 -a 2
sudo makedisks.main -n 14 -t 23 -a 3
ls ,disks/

Первая команда печатает пояснение по доступным ключам. Две другие создают по 14 дисков
(-n 14) с типом диска 23 (-t 23) на адаптерах 2 и 3 (-a 2 и -a 3). Симулятор Data ONTAP 8.0.1 поддерживает конструктивно только диски размером 1GB и менее. Даже если вы видите в подсказке команды диски большего размера, воздержитесь от соблазна попробовать добавить их в симулятор. С виртуальными дисками размером больше 1GB Data ONTAP упадет в panic при перезагрузке, и вам придется устанавливать симулятор заново.

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

exit
useradmin diaguser lock
priv set admin
reboot

После перезагрузки необходимо назначить ownership новым дискам:

disk show -n
disk assign all
disk show -v

Теперь у вас в симуляторе 56 “дисков” по 1GB каждый. Они уже zeroed, и вы можете непосредственно добавить их в нужный вам aggregate.

??сходный текст был взят тут: https://communities.netapp.com/docs/DOC-9579

В ряде случаев, например когда вы планируете использовать несколько установленных симуляторов, подключенных в Operations Manager, необходимо задать каждому из этих симуляторов индивидуальный SystemID и Serial Number. В будущем в NetApp обещают генерировать при установке произвольный номер, а пока все симуляторы идут с одним. Поэтому нужно проделать небольшой трюк.

При начальной загрузке прервите ее и войдите в SIMLOADER.

Выполните там две следующие команды:

SIMLOADER> set bootarg.nvram.sysid=1111111101
SIMLOADER> set SYS_SERIAL_NUM=1111111101

SystemID это 10-значное число. Последние две цифры должны быть уникальны в пределах Cluster-mode кластера для того, чтобы обеспечить уникальность UID дисков. Таким образом первые 8 цифр определяют кластер, а последние 2 – ноду в этом кластере. Впрочем, если вы используете симулятор только как 7-mode, вам это не важно, назначьте туда любое 10-циферное число.

Дайте команду:

SIMLOADER> boot

Войдите в Boot Menu нажатием Ctrl-C и выберите там Maintenance mode boot

Переназначьте диски на новый SystemID, если вы уже назначили их ранее контроллеру на его прежний SystemID. Если вы делаете описываемую процедуру при самом первом старте, то переназначать диски еще не нужно, назначьте из обычным образом.

UPD: Приведенный метод, к сожалению, НЕ РАБОТАЕТ для Simulator версии 8.1, он работает только для 8.0.1

В предыдущей статье я показал, как поставить виртуальную машину, в виде которой сейчас идет симулятор 8.0.1 на сервер VMware ESX. А сейчас попробуем начать с ним работу.

Как я уже рассказывал в предыдущем посте, Data Ontap Simulator это виртуальная машина, в которой работает версия Data ONTAP 8 для выполнения в среде VM. Data ONTAP 8 базируется на OS FreeBSD, однако, вопреки распространенному (ошибочному) мнению, Data ONTAP 8 это НЕ FreeBSD. Это даже не программа под FreeBSD. Это самостоятельная OS, которая использует FreeBSD как загрузчик своего kernel space code, а также использует некоторые ее ресурсы, например driver model, и драйвера оборудования. Ситуация была примерно та же, что с гипервизором VMware ESX-не-i, если вы помните, там сперва грузился RedHat, под которым затем запускался как модуль собственно ESX, который уже Linux не являлся. ??менно этим объясняется то, что мы в прошлой статье создали VM типа “FreeBSD 64-bit”, действительно, сперва VM загружается с использованием loader FreeBSD, а затем использует ее драйверную модель для внешних устройств.

Симулятор, как я уже рассказывал выше, это полноценная версия Data ONTAP, за некоторым исключением: установлено ограничение по поддерживаемой емкости, не работает протокол FC (но работает iSCSI) и, в настоящий момент, реализована только одноконтроллерная конфигурация. Но для экспериментов и обучения этого будет вполне достаточно.

Давайте, для начала, отключим на симуляторе Autosupport. Симулятор это экспериментальная площадка, и лучше будет не беспокоить поддержку NetApp странными сообщениями, которые будет при наших экспериментах посылать”в центр” служба Autosupport. Войдя в консоль даем команду:

options autosupport.enable off

Штатным образом Simulator приходит с набором из 28 “как-бы дисков” размером 1GB (как я уже сказал, для экспериментов этого объема достаточно). ??значально, только 3 диска назначены (assigned) контроллеру, и на них создан root volume на RAID-DP. Остальные диски помечены как unassigned. Назначим оставшиеся диски нашему симулятору:

disk assign all

Теперь добавим ключи-лицензии. Эти ключи предназначены только для симулятора, и не будут работать на физической системе. Можно установить только то, что используется на вашей продакшн-системе, или поставить дополнительные лицензии, чтобы посмотреть “что это и как работает”, или же просто все, и экспериментировать со всеми возможными фичами.

• a_sis MTVVGAF
• cifs DZDACHD
• disk_sanitization PZKEAZL
• http NAZOMKC
• flex_clone ANLEAZL
• iscsi BSLRLTG
• multistore NQBYFJJ
• nearstore_option ELNRLTG
• nfs BQOEAZL
• smdomino RKBAFSN
• smsql HNGEAZL
• snapmanagerexchange BCJEAZL
• snapmirror DFVXFJJ
• snapmirror_sync XJQIVFK
• snaprestore DNDCBQH
• snapvalidator JQAACHD
• sv_linux_pri ZYICXLC
• sv_ontap_pri PVOIVFK
• sv_ontap_sec PDXMQMI
• sv_unix_pri RQAYBFE
• sv_windows_ofm_pri ZOFNMID
• sv_windows_pri ZOPRKAM
• syncmirror_local RIQTKCL

Лицензионный ключ – это 7 заглавных букв после имени функции. Для того, чтобы ввести лицензионный ключ дайте команду:

license add XXXXXXX

Допустим, мы решили оставить 3 уже назначенных диска в отдельном root aggregate (так рекомендуется по ряду причин), однако если ваша реальная система мала, то вам, возможно, не захочется терять эти 3 диска и их IOPS-ы, тогда возможен вариант с единым общим aggregate, не выделенным под root volume, а общим с пользовательстими данными. Тогда вам нужно будет создать из имеющихся дисков новый aggregate, перенести root volume на него, затем удалить старый том и aggregate, и освободившиеся 3 диска добавить к созданному вами “большому” aggregate. Как это сделать я уже писал в блоге ранее.

Если же мы собираемся оставить 3 диска root vol в отдельном aggregate, то просто создавайте новый aggregate на оставшихся 25 дисках. Однако тут имеет смысле сделать небольшие изменения в опциях системы. Дело в том, что размер RAID-группы по умолчанию в Data ONTAP равен 16 дискам (а максимальный для дисков FC, SAS и виртуальных дисков симулятора – 28). Если вы создаете большой единый aggregate на всех 25 дисках, то, при установленном размере RAID-группы равной 16, он создастся так:

Сперва будет взято 16 дисков, из которых 2 будут RAID-DP parity и dparity, а остальные 14 будут data в RAID-группе rg0. Затем на оставшихся будет создана вторая RAID-группа (rg1), из оставшихся 9 дисков, которые, в свою очередь, станут двумя parity и 7 data. В дальнейшем, если в aggregate добавляются новые диски они добавляются в “неполную” RAID-группу, пока она не достигнет заданного в опциях размера в 16 дисков, а следующие создадут еще одну новую “неполную” группу.

Логично было бы, особенно на небольшом числе дисков, не полагаться на такую автоматику, а самостоятельно расчитать и создать RAID-группы, по возможности равного размера. То есть, с точки зрения порядка, аккуратности (да и производительности) вариант 12+12+1 hot spare будет лучше, чем 16+8+1hs. А в нашем случае мы поступим еще лучше, мы просто увеличим заданный размер RAID-группы до максимума (28), или, хотя бы до 25. Тогда все наши диски поместятся в одну группу. Дадим в консоли команду:

aggr options aggr1 raidsize 28

Теперь добавим оставшиеся unassigned диски в созданный aggr0

aggr add aggr1 24

Мы оставим один диск под spare, это требование Data ONTAP. Для того, чтобы в логах не валились сообщения о нехватке spares, проверьте значение опции:

options raid.min_spare_count 1

Здесь 1 – количество spare для данного контроллера. Одного будет вполне достаточно, а при количестве дисков более 16 поставить 0 система не даст.

??меет смысл также уменьшить резерв под snapshots уровня aggregate. Что это я уже тоже писал в блоге, есл вкратце и в двух словах – это вам не надо, это для Metrocluster, синхронной репликации, и может помочь для ремонта сильно поврежденной WAFL. Если у вас этого всег нет, то можете этот резерв убрать и выключить расписание создания их.

snap reserve -A aggr1 0
snap sched -A aggr1 0

Отдельно отмечу, это ТОЛЬКО для специальных, внутренних снэпшотов уровня aggregate, на обычные и привычные пользовательские снэпшоты уровня volume и файлов это не влияет, они буду работать по-прежнему, и вы по-прежнему сможете их использовать.

Вот теперь все готово к созданию томов и экспериментам. Можете начать из консоли, или же подключить к симулятору System Manager, если вам в GUI привычнее. Симулятор, повторюсь, работает и ведет себя идентично реальной системе хранения (за вычетом FC, SnapLock и ограничения по объему хранения). К нему можно подключить любой софтовый продукт (System/Operations/Protection/Provision Manager, SnapManager, VSC), настроить на него репликацию, использовать его как получатель (secondary) или источник (primary) для SnapVault, и так далее.

В основу этого поста легла статья http://mtellin.com/2011/01/03/getting-started-with-the-netapp-ontap-8-0-1-simulator/.

В следующей статье я покажу, как можно добавить диски симулятору, сверх предустановленных 28, а также добавить serial console или изменить предустановленный серийный номер и SystemID, если вы планируете использовать несколько разных симуляторов в одной сети.

Я уже рассказывал в этом блоге про то, что такое Data ONTAP Simulator, и чем он полезен, не только когда у вас нет “живой” системы хранения NetApp под руками, но даже, причем в большей степени, когда она у вас есть. На таком симуляторе можно упражняться “на кошечках”, можно проверять какие-то свои идеи, ставить эксперименты, отлаживать какие-то решения (не на продакшновом же сторадже это проделывать?), наконец учиться и обучать новичков.

Однако, как вы знаете, Data ONTAP 8 отличается от DOT7 довольно прилично. Была изменена платформа, на которой выполняется код собственно NetApp. В результате теперь по другому выглядит и Симулятор. Если раньше, для версии 7, это была программа под Linux, то Симулятор под Data ONTAP v8 это самостоятельный образ виртуальной машины, который можно запустить из под, например, VMware Player, или установить ее как VM в ESX.

Вот как раз этому варианту и посвящена эта статья, которую в оригинале я подсмотрел на http://mtellin.com/2010/03/12/use-ontap-8-0-7-mode-simulator-on-esx/

Continue reading ‘Как поставить Data ONTAP Simulator v8 на VMware’ »

Как вы знаете, каждый контроллер в HA-паре системы хранения NetApp владеет собственным набором дисков. Когда-то, много лет назад, еще до систем серии 3000, использовался так называемый hardware ownership, при котором привязка к контроллеру происходила “физически”, на уровне полки и петли FCAL. Начиная с 3020 в системах NetApp применяется так называмый sowtware ownership, при котором владелец диска назначается согласно WWN этого диска, и появилась возможность более гибко назначать владельца и разделять диски между контроллерами. Например, можно даже имея одну дисковую полку произвольно назначить диски из нее разным контроллерам.

??ногда же возникает задача перераспределить диски, например передать часть дисков от одного контроллера-владельца другому.

Как это сделать показывает статья в Knowledge Base

KB ID: 1011998 Version: 3.0 Published date: 01/13/2011

Описание

Приведенная процедура смены контроллера-владельца диска применима к любой системе, поддерживающей software-based ownership (на сегодняшний день все выпускаемые системы используют software-based ownership).

Процедура

В разбираемом примере, FilerA владеет spare-диском, который мы хотим передать контроллеру FilerB.

1. Получим Disk ID

FilerA> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 6 FC:B - FCAL 10000 68000/139264000 69536/142410400

2. Перейдем в режим повышенных привилегий (advanced mode)

FilerA*> priv set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.

3. Удалим текущего владельца диска

FilerA*> disk remove_ownership 0b.22
Volumes must be taken offline. Are all impacted volumes offline(y/n)?? yes
FilerA*> Sat Jan 14 17:46:42 GMT [FilerA: raid.config.spare.disk.missing:info]: Spare Disk 0b.22 Shelf 1 Bay 6 [NETAPP X272_HJURE073F10 NA14] S/N [xxxxxx] is missing.

Внимание:

• Команду disk remove_ownership можно дать сразу на группу дисков, разделив их имена пробелами, disk remove_ownership 6c.64 6c.65 6c.66 снимет владельца со всех перечисленных дисков.
• В случае систем серии 30×0, проверьте установку опции options disk.auto_assign. Если она установлена в on, то когда вы снимете владельца с дисков, система автоматически назначит их назад. По этой причине убедитесь, что перед началом операции эта опция установлена в off. Можно ее включить назад, после передачи диска контроллеру.
• Сообщение volumes must be taken offline это предохранительная мера, вы должны подтвердить, что не удаляете диск с данными из активного тома/aggregate. В данном примере мы перемещаем spare-диск, а не диск, уже назначенный в RAID.

4. Подключаемся к контроллеру FilerB и переходим в advanced mode

FilerB*> priv set advanced
Warning: These advanced commands are potentially dangerous; use
them only when directed to do so by NetApp
personnel.

5. Назначаем нового владельца

FilerB*> disk assign 0b.22
Sat Jan 14 17:47:32 GMT [FilerB: diskown.changingOwner:info]: changing ownership for disk 0b.22 (S/N xxxxxx) from unowned (ID -1) to FilerB (ID xxxxxx)

6. Проверяем, что диск теперь spare у нового контроллера

FilerB*> vol status -s
Spare disks
RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Phys (MB/blks)
——— —— ————- —- —- —- —– ————– ————–
Spare disks for block or zoned checksum traditional volumes or aggregates
spare 0b.22 0b 1 8 FC:B - FCAL 10000 68000/139264000 69536/142410400