rus tr-3965 netapp thin provisioning - руководство по использованию для...

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

NETAPP TECHNICAL REPORT

NetApp Thin Provisioning: руководство по использованию для Data ONTAP 8.1 7-ModeCarlos Alvarez, NetApp

Сентябрь 2011 | TR-3965 | Rev. 1

Коротко о главном:

В этом руководстве по технологии thin provisioning, описывается в деталях то, как ее использовать и настраивать, приведена информация о наилучших методах, способах и практиках использования, а также приведены способы поиска и устранения проблем. Хотя в заголовке и указывается Data ONTAP 8.1, общие концепции, описанные в документе, применимы и к Data ONTAP 7.3.x и 8.0.x. Основное отличие заключается в работе функции DataMotion. Для подробностей смотрите включенные в документ справочные материалы.

Руководство может быть полезным как для действующих пользователей систем NetApp, так и для тех, кто только разворачивает такую систему, и кому необходима помощь в понимании деталей при развертывании решения, использующего thin provisioning.

1

Оглавление1 Введение и обзор технологии Thin Provisioning..................................................................................6

1.1 Определение Thin Provisioning......................................................................................................6

1.2 Архитектура Thin Provisioning.........................................................................................................7

Ключевые компоненты Thin Provisioning.........................................................................................7

1.3 Тома Thin Provisioning.....................................................................................................................9

1.4 LUN Thin Provisioning.....................................................................................................................11

Возврат неиспользуемого места (Space Reclamation)...................................................................13

1.5 Общие характеристики Thin Provisioning.................................................................................16

2 Конфигурирование и операции..........................................................................................................16

2.1 Требования....................................................................................................................................16

2.2 Ключевые параметры Data ONTAP..............................................................................................17

Aggregate Snapshot Reserve.............................................................................................................17

Volume Space Guarantee..................................................................................................................18

Volume Snap Reserve........................................................................................................................20

LUN Overwrite Reserve (опция FRACTIONAL_RESERVE)...................................................................20

Volume Autosize................................................................................................................................21

Volume Snapshot Autodelete............................................................................................................22

LUN Reservation................................................................................................................................23

Общий вид ситуации.......................................................................................................................23

Справочная таблица параметров...................................................................................................24

2.3 Установка и лицензирование Thin Provisioning...........................................................................25

2.4 Команды для работы с Thin Provisioning.....................................................................................25

2.5 Thin Provisioning: быстрый старт..................................................................................................27

2.6 Политики Thin Provisioning в Provisioning Manager.....................................................................27

Распределение пространства тома с помощью Provisioning Manager.........................................28

Распределение пространства LUN с помощью Provisioning Manager.........................................28

2.7 Мониторинг Thin Provisioning с помощью Operations Manager.................................................29

Пороги срабатывания......................................................................................................................29

Оценка тенденций...........................................................................................................................32

Мониторинг эффективности...........................................................................................................32

2.8 Уведомления.................................................................................................................................33

Уведомление по E-Mail....................................................................................................................34

Уведомление по SNMP....................................................................................................................34

3

Уведомление с использованием скрипта......................................................................................35

2.9 Сохранение доступности хранилища..........................................................................................35

Процедуры снижения рисков исчерпания пространства.............................................................36

Сохранение доступности объема хранения на томе.....................................................................38

3 Рекомендации по использованию и наилучшие практики...............................................................40

3.1 Thick Provisioning, как режим по умолчанию..............................................................................40

3.2 Общие практики и рекомендации использования Thin Provisioning........................................41

3.3 Рекомендуемые конфигурации Thin Provisioning.......................................................................42

Как следует оценивать размеры тома?..........................................................................................44

3.4 Thin Provisioning на практике.......................................................................................................44

Рекомендации по приложениям....................................................................................................44

Миграция томов thin provisioning с использованием NetApp DataMotion..................................44

Тестирование: Thin и Thick Provisioning..........................................................................................46

Влияние на производительность....................................................................................................47

4 Thin Provisioning и VMware vSphere....................................................................................................47

Справочные материалы..................................................................................................................47

5 Thin Provisioning и Microsoft SharePoint..............................................................................................47

5.1 Спецификации...............................................................................................................................47

5.2 Рекомендации и наилучшие практики........................................................................................48

Конфигурирование Data ONTAP для работы с MS SharePoint.......................................................48

Развертывание SharePoint...............................................................................................................48

Мониторинг MS SharePoint.............................................................................................................49

Рост хранилища в MS Sharepoint....................................................................................................49

Особые случаи, требующие внимания, при использовании Thin Provisioning............................50


6 Thin Provisioning и Microsoft SQL Server..............................................................................................51

6.1 Спецификации...............................................................................................................................51


Конфигурирование Data ONTAP для работы с MS SQL Server.......................................................51

Установка MS SQL Server.................................................................................................................52

Мониторинг MS SQL Server.............................................................................................................53

Растущий объем хранения в MS SQL Server...................................................................................53

Рост хранилища в MS SQL Server.....................................................................................................53

Space Reclamation и MS SQL Server.................................................................................................54


4


7 Thin Provisioning и MS Exchange..........................................................................................................54

7.1 Спецификации...............................................................................................................................54

Миграция на Exchange Server 2010.................................................................................................55

Database Availability Group (DAG)....................................................................................................55


Конфигурирование Data ONTAP для работы с Exchange...............................................................56

Установка MS Exchange 2010...........................................................................................................57

Мониторинг Exchange......................................................................................................................57

Растущий объем хранения в Exchange...........................................................................................57

Space Reclamation и Exchange.........................................................................................................58



8 Thin Provisioning и Oracle DB................................................................................................................58

8.1 Спецификации...............................................................................................................................58


Конфигурирование Data ONTAP для работы с Oracle....................................................................59

Использование с ORACLE.................................................................................................................59

Мониторинг Oracle..........................................................................................................................61



9 Thin Provisioning и другие возможности NetApp...............................................................................62

9.1 Thin Provisioning и средства администрирования и мониторинга............................................62

9.2 Thin Provisioning и дедупликация................................................................................................63

9.3 Thin Provisioning и тома FlexClone................................................................................................63

9.4 Thin Provisioning и системы V-Series............................................................................................64

9.5 Thin Provisioning и репликация SnapMirror.................................................................................64

Рекомендации и наилучшие практики...........................................................................................64

9.6 Thin Provisioning и SnapVault........................................................................................................65

9.7 Thin Provisioning и Multistore (vFiler)............................................................................................65

Рекомендации и наилучшие практики...........................................................................................65

9.8 Thin Provisioning и Datamotion for LUNs......................................................................................65

10 Поиск и устранение неполадок.........................................................................................................66

10.1 Нет заметной экономии пространства......................................................................................66

10.2 Нет уведомлений........................................................................................................................66

5

10.3 Замедление производительности.............................................................................................66

11 Дополнительная и справочная литература.......................................................................................66

12 Где искать дополнительную помощь................................................................................................68

13 Версии документа...............................................................................................................................68

6

1 Введение и обзор технологии Thin ProvisioningХотя сегодня thin provisioning и является широко распространенным в отрасли систем хранения данных термином, его реализация широко варьируется в зависимости от конкретного производителя, продукта или даже приложения. В этой главе рассмотрены детали реализации данной технологии в системах хранения NetApp, и преимущества этой реализации. Они включают такие ключевые особенности, как простота включения thin provisioning, и то, как архитектура thin provisioning в реализации NetApp обеспечивает необходимые уровни производительности. Thin provisioning это наиболее эффективный путь использования пространства хранения, так как пространство хранения не выделяется заранее, в момент создания соответствующей структуры хранения, дискового тома, share или LUN. Иными словами, когда том или LUN только созданы и не содержат никаких данных, место на системе хранения ими не занимается.

Пространство остается незанятым до тех пор, пока фактические данные не будут физически записаны на диски LUN или тома, и только в этот момент место на диске этими данными начнет быть занято. Для получения всех преимуществ от этой технологии, необходимы развитые средства управления системой хранения. Для более подробного рассмотрения темы, включая бизнес-применения, смотрите документ TR -3563: NetApp Thin Provisioning Increases Storage Utilization with on - Demand Allocation .

Альтернативой thin provisioning является так называемый thick provisioning, это традиционный подход к распределению дискового пространства, при котором пространство на дисках занимается уже в момент создания соответствующей структуры, например тома или LUN. В этом случае, пространство, выделенное на определенный том или LUN, эксклюзивно закреплено за ним, даже если фактически данными в нем и не используется, и не может быть использовано, пока свободно, другими данными, в других томах или LUN.

Хотя в заголовке и указывается версия Data ONTAP 8.1, общие концепции, описанные в документе, применимы и к Data ONTAP 7.3.x, и 8.0.x. Основное отличие заключается в работе функции DataMotion. Для подробностей смотрите включенные в документ справочные материалы.

1.1 Определение Thin Provisioning NetApp thin provisioning имеет две основных возможности.

1. Возможность распределять больше логического дискового пространства хостам, чем его физически в момент распределения имеется у системы хранения (т.н overprovisioning).

2. Возможность распределять пространство по потребности, по мере поступления данных на запись на систему хранения, а не заранее (т.н. on-demand).

Рассмотрим пример, когда 15 хостов, на каждом из которых оценена потребность 500GB пространства на протяжении 3 лет длительности проекта, что в совокупности составляет 7500GB. Администратор системы хранения выделяет, с использованием thin provisioning, пространство на системе хранения, на которой физически есть всего 5000GB. При этом каждый из подключенных хостов, тем не менее, видит доступной ему всю запрошенную емкость, а на самом деле на системе хранения, в момент первоначального подключения этих 15 хостов, место не занято. По контрасту с вариантом thin provisioning, при использовании thick-provisioned системы хранения, когда при создании раздела для хоста он целиком и заранее занимает пространство на системе хранения, такая система не может обеспечить выполнение задачи для всех хостов на имеющемся

7

http://media.netapp.com/documents/tr-3563.pdf


в ней количестве дисков. Для системы thick provisioning необходимо сначала расширить пространство хранения на все 7500GB, и лишь потом начинать его распределять хостам. Вместо этого, в случае использования thin provisioning, 5000GB пространства остаются доступны всем проектам, пока какой-то из проектов не запишет объем данных на систему хранения. В этот момент данный раздел займет необходимое пространство из общего объема, и этот участок пространства перестанет быть доступным свободным пространством для всех проектов. Для того, чтобы избежать ситуации исчерпания свободного места, администраторам надо внимательно наблюдать за состоянием системы хранения, свободным местом на ней, и вовремя добавлять диски для расширения ее емкости.

Thin provisioning, как принцип, широко используется во многих областях. Давайте рассмотрим для примера водопровод. Компания, обеспечивающая подачу воды в водопровод, как правило, не имеет емкостей, достаточных для обеспечения давления в сети, когда все потребители откроют свои краны одновременно. Компания планирует, что только определенный процент потребителей одновременно использует воду. Этот пример иллюстрирует базовые концепции thin provisioning.

1.2 Архитектура Thin Provisioning Технология NetApp FlexVol® обеспечивает возможность создания эффективного, гибкого «контейнера данных», который отделяет свое содержимое от непосредственно физических дисков хранилища. Технология FlexVol разделяет «контейнеры данных» и физические диски, на которых они расположены: в результате это позволяет значительно увеличить гибкость и степень использования системы хранения. Используя Data ONTAP® FlexVol, вы можете сжимать и расширять контейнер данных, руководствуясь вашими сиюминутными потребностями. Добавление дисков может осуществляться «на ходу», без прерывания работы системы хранения и использующих ее приложений.

Ключевые компоненты Thin Provisioning1. Тома FlexVol: Тома FlexVol это стандартный компонент систем хранения NetApp. Они могут

быть сконфигурированы для автоматического занятия ими доступного пространства хранения по мере записи данных в них, и обычно несут на себе структуры shares, или «совместно используемых папок» для доступа по протоколам файлового уровня (NAS), или же LUN-ы для протоколов блочного уровня (SAN).

2. LUN: LUN-ы это стандартный компонент в иерархии объектов хранения систем NetApp. Они обеспечивают поддержку протоколов блочного уровня (SAN). Для Data ONTAP, LUN-ы это просто объекты внутри тома, что обеспечивает дополнительную гибкость и эффективность.

3. Aggregate: 32-bit и 64-bit aggregates это базовый компонент системы хранения NetApp, и он используется как пул хранения, в котором содержатся тома и LUN-ы, использующие thin provisioning. Несколько aggregates могут быть использованы на одной системе одновременно, и каждый из них может быть расширен дополнительным пространством, если пулу в нем потребуется дополнительное место.

4. Инструменты администрирования: Инструменты администрирования NetApp, такие как Provisioning Manager и Operations Manager, могут быть использованы для легкого создания и применения политик распределения пространства, создания отчетов о используемом месте на системе хранения, мониторинга тенденций расходования пространства и планирования ближайшего будущего, а также настройки срабатывания автоматических действий и уведомлений, по достижении заданных порогов.

8

Рисунок 1 показывает, как эти компоненты комбинируются для создания решения, основанного на едином aggregate. На практике, достаточно обычным для одной системы является использование нескольких aggregates и различных комбинаций томов и LUN на них.

Рис. 1) Архитектура хранения NetApp Data ONTAP.

Архитектура NetApp Data ONTAP использует aggregates для виртуализации физического хранилища в так называемые «пулы хранения» (storage pools) для дальнейшего логического распределения между использующими их ресурсами. Тома и LUN-ы видят «логическое», виртуализованное пространство, вместо «физического», которым управляет только aggregate. Эта архитектура обеспечивает гибкость создания множества томов и LUN-ов, которые могут в сумме объемов превышать доступное физическое пространство aggregate. Все тома и LUN-ы на aggregate используют доступное пространство внутри aggregate как совместно используемый ресурсный пул. Это позволяет им эффективно распределять пространство, доступное на aggregate только по мере того, как данные записываются в них, то есть вместо того, чтобы резервировать это место сразу, на этапе создания тома или LUN-а.

Резервирование часто приводит к тому, что место остается неиспользованным на протяжении длительного времени, а как результат – снижается коэффициент использования системы хранения. В случае, когда некоторым томам или LUN-ам необходимо продолжить резервирование места в момент создания, вы, разумеется, можете им это разрешить, и выделять пространство для них традиционным образом, тогда как другие могут делать это с использованием thin provisioning, нарезая себе место из оставшегося пространства на aggregate. Это можно делать на одном и том же aggregate. Или более определенно: aggregate это совместно используемый пул ресурсов для томов и LUN-ов, использующих thin provisioning, и он же также может, одновременно и совместно с первыми, нести на себе тома и LUN-ы традиционного типа, thick (preallocated). Объем aggregate может быть расширен простым добавлением в него физических дисков. Мониторинг использования пространства работает на уровне aggregate и помогает предсказать момент, когда необходимо добавление пространства.

Рисунок 1, выше, показывает, что физическое пространство aggregate сделано из дисков (SATA, FC, SAS, или SSD), объединенных в RAID. Тома и LUN-ы созданные в aggregate, находятся на уровне абстракции между логическими томами и LUN-ами и физическими дисками. Разделение логических «контейнеров хранения» и физических дисков обеспечивает гибкость роста при

9

необходимости увеличить aggregate, делать это независимо от процессов увеличения и сжатия томов или LUN-ов . Все это реализовано прозрачно для клиентов. При доступе с клиентских хостов к томам или LUN-ам, приложения и пользователи видят «логический размер» этих томов или LUN, вместо их физического размера.

В двух следующих главах мы приведем больше подробностей о том, как использовать эту концепцию для систем NAS (тома) и SAN (LUN).

1.3 Тома Thin ProvisioningФайловая система Write Anywhere File Layout (WAFL®) обеспечивает уровень виртуализации хранилища в Data ONTAP, позволяя использовать thin provisioning для томов. Для создания тома с использованием thin provisioning, установите опцию volume space guarantee в значение -none.‖ Вы также можете изменить существующее значение опции volume space guarantee в значение -none‖ для уже существующего тома, причем без какого-либо воздействия на его производительность. Когда том создается, то он не занимает заранее запрошенное на aggregate место под том (операция, известная как preallocation). Вместо этого блоки распределяются с aggregate в том по мере того, как данные в этот том записываются. Это позволяет распределить больше пространства, чем его физически имеется на aggregate.

Таблица 1, ниже, показывает минимальные параметры, которые нужно использовать для использования thin provisioning для тома. Установка параметра volume guarantee в значение -none‖ приводит к тому, что место на родительском aggregate для данного тома не резервируется.

Таблица 1) Основные параметры для тома в режиме thin provisioning.

Параметр ЗначениеОпции тома

guarantee none

Рисунок 2 показывает устройство тома в режиме thin provisioning в схематичной форме. Единственное пространство, которое в данном случае занимается, это пространство, занятое уже записанными на том данными. Нераспределенное пространство доступно для этого тома, или для любых других томов, создаваемых на этом aggregate.

10

Рис. 2) Том в режиме thin provisioning.

Если в aggregate добавляются еще тома, то на нем занимается только фактически использованное ими место. Это позволяет распределить пространства больше, чем его физически есть на aggregate, такое поведение называется overcommitting. Overcommitment на aggregate означает, что суммарная емкость томов, с точки зрения использующих их хостов, превышает общую емкость aggregate.

Рис. 3) Несколько томов с thin provisioning, и overcommit.

11

Рисунок 3 показывает несколько томов на одном aggregate, когда общий объем созданных томов превышает общий доступный объем их aggregate.

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

1.4 LUN Thin ProvisioningУниверсальная архитектура хранения NetApp (Unified Architecture) обеспечивает возможность хранить на одной системе хранения как тома с файлами, так и LUN-ы с блочным доступом. Когда LUN создан, это просто объект на томе FlexVol. Этот подход дает много преимуществ, включая возможность использовать thin provisioning для LUN-ов, точно также, как он используется для файлов на томе. Файловая система Write Anywhere File Layout (WAFL) обеспечивает уровень виртуализации для Data ONTAP, что позволяет использовать thin provisioning для LUN. Для создания LUN с использованием thin provisioning, создайте том с установками volume guarantee со значением -none, и затем создайте LUN с установкой LUN reservation в значении off . Вы также можете изменить величину volume guarantee и LUN reservation для уже существующих томов или LUN-ов, без остановки доступа к ним и ущерба для производительности. Когда LUN создан, он не занимает какие-то конкретные блоки на aggregate, то есть не делает preallocation. Вместо этого, блоки занимаются на aggregate тогда, когда данные пишутся в LUN. Это позволяет распределить потребителям больше пространства хранения, чем физически имеется на момент распределения на aggregate.

Таблица 2, приведенная ниже, показывает минимальный набор параметров, которые следует задать при использовании thin provisioning для LUN на томе, также использующем thin provisioning. Установка volume guarantee в значение -none‖ приводит к тому, что на родительском aggregate место под конкретный том резервироваться не будет. Установка для LUN параметра space reservation в -disabled‖ ведет к тому, что пространство на томе под созданный на нем LUN также не будет зарезервировано.

Таблица 2) Основные параметры thin provisioning для LUN.

Параметр ЗначениеОпции тома

guarantee NoneОпции LUN

space reservation Disabled

Рисунок 4 представляет схему LUN thin provisioning в упрощенном виде. Единственное пространство, которое занято на хранилище – это то, куда записаны данные в LUN . Нераспределенное место доступно как этому LUN, так и любому другому LUN (или тому), созданному на этом aggregate.

12

Figure 4) LUN thin provisioning.

Далее, давайте посмотрим что случится, если мы добавим томов и LUN-ов на aggregate, создав некоторый overcommitment.

Рис. 5) Несколько LUN с использованием thin provisioning, overcommitted.

Рисунок 5 показывает несколько томов и LUN-ов, созданных в режиме thin provisioning на одном aggregate, когда общий объем распределенного между хостами пространства больше, чем доступно на aggregate. Так как пространство хранения не резервируется за томом или LUN-ом, все неиспользуемое пространство доступно для всех LUN-ов (или томов) на этом aggregate. По мере того, как данные пишутся на LUN, общее физическое пространство на aggregate постепенно

13

распределяется между LUN-ами и томами, и уровень использования aggregate постепенно повышается. По мере того, как aggregate приближается к границе полного заполнения, предварительно запланированный процесс, например покупки и добавления новых дисков для расширения aggregate, должен быть инициирован с тем, чтобы обеспечить достаточно свободного места росту объемов хранимых данных. Политики и параметры, предназначенные для этого, рассмотрены в этом документе далее.

(Возврат неиспользуемогоместа Space Reclamation)Тема места, использованного внутри LUN, часто не всегда до конца понятна пользователям. Это непонимание вызвано тем, что, как правило, внутри LUN располагается какая-либо файловая система, в которую он отформатирован, в результате возникает путаница в том, сколько места на LUN занято с точки зрения файловой системы, и сколько – с точки зрения самого LUN и системы хранения. Эта путаница не является исключительно проблемой систем хранения NetApp. Допустим, что одна файловая система занимает целиком LUN, все его пространство отформатировано под эту файловую систему. При этом LUN будет наполнен данными как минимум настолько, насколько ей наполнена файловая система. С точки зрения системы хранения, несущей LUN, процентное заполнение данными LUN-а будет всегда возрастать, и никогда не уменьшается, если только не будет проведена операция space reclamation, то есть «возврата неиспользуемого места», о которой ниже.

Рисунок 6, ниже, показывает процесс заполнения данными отдельного LUN, и то, почему необходима процедура space reclamation. Она показывает теоретический случай, когда LUN и файловая система на нем используются для записи и последующего удаления файлов с файловой системы. Шаги 1 и 2 показывают, как описано, что файловая система и LUN, оба сообщают равный уровень заполнения, когда файлы записаны на файловую систему. Но на Шаге 3 возникает разница между тем, что видит хост, работающий с файловой системой, и тем, что видит система хранения на уровне LUN. На этом шаге, файлы 1 и 2 удалены, что подразумевает, что блоки, ими занимавшиеся, снова доступны для записи в файловой системе. Единственный файл, оставшийся видимым файловой системе – это файл 3, поэтому файловая система сообщает о 25% заполненности. Однако сама система хранения по-прежнему считает, что она заполнена на 75% емкости LUNа. Причина этому в том, что система хранения не имеет способа узнать о том, что данные, записанные ранее в файл 1 и 2 больше не нужны, и считаются в файловой системе удаленными. Пространство на схеме закрашено, потому что, с точки зрения системы хранения, эти блоки по-прежнему хранят какие-то данные. Когда файл удаляется с файловой системы, она не изменяет блоки, занимаемые файлом, и не сообщает нижележащей системе хранения, на которой располагается LUN с ней, что какие-то блоки были удалены или стерты. Она просто изменяет указатель на файл таким образом, что он позволяет используемым блокам быть записанными повторно, новыми данными другого файла. Факт того, что блоки, содержащие файл, остаются неуничтоженными и нестертыми, позволяет, как вы знаете, осуществить операцию undelete‖с помощью множества разных системных утилит. На Шаге 4, файл 4 показан записанным на последние 25% LUN. Этот шаг отображает тот факт, что файловая система не обязательно старается записывать данные с начала LUN. После Шага 4, каждый блок в LUN был записан, и он становится заполненным с точки зрения системы хранения. Как мы уже упомянули ранее, величина заполненности LUN не снижается, пока вы не запустите операцию space reclamation, и на Шагах 5, 6, 7 это показано, Вне зависимости от того, что записывает на LUN его хост, он по-прежнему остается заполненным на 100% с точки зрения системы хранения.

14

Рис. 6) LUN заполняется новыми файлами.

LUN space reclamation это процесс, который позволяет системе хранения освободить блоки, которые больше не используются для хранения данных в файловой системе хоста. Эти блоки могут быть использованы системой хранения для других целей, например, они могут поступить в

15

пул свободных блоков на уровне aggregate. SnapDrive® for Windows® версии 5.0 и новее позволяет осуществлять процедуру space reclamation для файловой системы Windows NTFS.

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

Первые три шага на рисунке 7, ниже, показывают ту же ситуацию, что и на рисунке выше, без space reclamation. Шаг 4 на рисунке 7 показывает результат после того, как сработала процедура space reclamation. Процесс space reclamation выполняется с помощью SnapDrive for Windows и работает на файловой системе соответствующего хоста. Процесс обнаруживает и освобождает группы блоков, принадлежащих стертым файлам на ней, а затем посылает специальные команды системе хранения, которые указывают ей то, какие блоки теперь могут считаться незанятыми. Эти блоки временно блокируются на доступ со стороны OS хоста, пока идет операции reclamation.

Рис. 7) LUN заполнен новыми файлами и использована процедура Space Reclamation.

16

В дополнение к тому, что процедуры space reclamation предусмотрены в продуктах NetApp, таких как SnapDrive for Windows, NetApp также поддерживает средства Symantec Thin Reclamation API. Для подробностей, смотрите документ WP-7111: Maximize Storage Efficiency with NetApp Thin Provisioning and Symantec Thin Reclamation.

1.5 Общие характеристики Thin ProvisioningThin provisioning может быть включен для отдельного тома или для отдельного LUN.

Thin provisioning может быть включен при создании тома или LUN. Он также может быть включен и в любое время после их создания. Для включения NetApp thin provisioning не требуется миграции данных.

Thin provisioning может быть также выключен в любое время, подразумеваем, что на aggregate имеется достаточно пространства для включения резервирования пространства для тома или LUN.

Thin provisioning может быть также включен для любого количества и любой комбинации томов или LUN-ов на системе хранения независимо, по выбору администратора.

Thin provisioning для LUN-ов и томов может использоваться прозрачно для хостов и приложений, но необходимо принять во внимание, что в случае роста объемов необходимо своевременно обеспечить достаточный объем свободного места на уровне aggregate. Если приложение в явном виде поддерживает thin provisioning, то для задач конфигурирования и распределения пространства с использованием томов и LUN-ов в режиме thin provisioning следует руководствоваться рекомендациями и наилучшими практиками для данного приложения, как на уровне приложения, так и на уровне системы хранения.

Когда вы планируете использование thin provisioning, рассмотрите также и другие продукты и возможности системы хранения, которые могут уменьшить или увеличить объемы занятого дискового пространства, доступного на aggregate. В качестве примера можно привести дедупликацию и компрессию данных, которые экономят пространство на aggregate и увеличивают доступное томам и LUN-ам место, в то время как aggregate snapshot reserve и volume snapshot reserve отнимают пространство у томов и LUN-ов на aggregate.

Подробнее вопрос об использовании thin provisioning с другими опциями и функциональными возможностями рассматривается в следующих главах документа.

2 Конфигурирование и операцииВ этой главе обсуждаются требования конфигурирования и ряд аспектов по администрированию дисковых ресурсов, созданных в режиме thin provisioning.

Хотя в этой главе, прежде всего, рассматриваются базовые понятия, подразумевается, что ваша система хранения NetApp уже установлена и работает, и читающий знаком с базовыми процедурами администрирования системы хранения NetApp.

2.1 Требования Thin provisioning хорошо интегрирован в систему хранения NetApp, это означает, что вы встретитесь с малым числом ограничений его использования. Таблица 3 показывает простой список технических требований.

17

http://media.netapp.com/documents/wp-7111.pdf


Таблица 3) Обзор технических требований к thin provisioning.

ТребованияОборудование Все системы. V-series и IBM N-series также поддерживаются.Минимальная версия Data ONTAP

Data ONTAP 7.0, однако ряд возможностей, описываемых в документе, доступен с Data ONTAP 7.2.4

Требуемые лицензии Не нужныПоддерживаемые типы томов Только Flexible volume.

Traditional volume не поддерживаются.Поддерживаются LUN ДаПоддерживаются протоколы Все

Дополнительно к чисто техническим требованиям, thin provisioning выдвигает также весьма важные требования к инфраструктуре. Таблица 4 показывает основные требования к организации инфраструктуры, которые являются абсолютно необходимыми для успешной реализации системы thin provisioning.

Таблица 4) Обзор требований к инфраструктуре thin provisioning.

ТребованияМониторинг Для оценки темпов роста хранилища, уровней его

использования и доступности, необходимо развернуть инфраструктуру мониторинга, например с использованием NetApp Operations Manager.

Расширение емкости Необходимы четкие и хорошо отработанные процедуры циклов расширения емкости системы хранения с тем, чтобы, по мере заполнения системы хранения данными, дополнительная емкость хранения своевременно добавлялась.

Система уведомлений Для своевременной сигнализации о наступлении или приближении ситуации исчерпания места, необходима развитая система уведомлений администратора, с использованием e-mail, пейджинга и SMS.

2.2 Ключевыепараметры Data ONTAPВ данной главе рассматриваются параметры Data ONTAP, влияющие на thin provisioning.

Aggregate Snapshot ReserveПараметр aggregate snapshot reserve задает резервирование на уровне aggregate для снэпшотов целиком всего aggregate, моментального read-only-образа этого aggregate. Это резервирование обычно применяется, когда на системе хранения используется SyncMirror® (например, в MetroCluster), и, в ряде случаев, когда требуется сохранить состояние всего aggregate целиком. Этот параметр действует на уровне aggregate, и устанавливается в процентах от емкости aggregate. Data ONTAP исключает заданную процентную долю от емкости aggregate из доступной пользователям емкости хранения. По умолчанию величина aggregate snapshot reserve для Data ONTAP, версии выше 8.0.1 равна 5%, но задание его не обязательно, и может быть установлено в 0%, если SyncMirror на этом aggregate не используется. Мы упоминаем об этом параметре в данной главе потому, что этот параметр влияет на доступное в aggregate общее пространство хранения, и поэтому его влияние следует хорошо понимать и верно оценивать. Если он задан, то

18

зарезервированое пространство доступно только для снэпшотов уровня aggregate, и не доступно для томов, LUN-ов, или для хранения файлов.

Aggregate snapshot reserve и его подробное рассмотрение находится за пределами темы данного документа. Для подробностей о нем, смотрите Data ONTAP System Administration Guide.‖

Volume Space GuaranteeVolume space guarantees определяет то, когда и как должно быть зарезервировано пространство на дисках aggregate под дисковый том. Два основных значения volume space guarantee , которые следует использовать для thin и thick provisioning это none и volume. Установка параметра volume space guarantee в значение none приведет к использованию для тома режима thin provisioning. Установка параметра volume space guarantee в значение volume приводит к использованию томом режима thick provisioning.

Установка резервирования в значение volume‖указывает aggregate, что запрошенное при создании тома пространство, равное его объему, должно всегда оставаться доступным на несущем его aggregate. Это значение по умолчанию для томов типа FlexVol. С параметром space guarantee установленном в значение -volume,‖объем вычитается, или резервируется, из доступного на соответствующем aggregate пространстве, непосредственно в момент создания тома. Пространство резервируется на aggregate вне зависимости от того, используется ли оно для хранения данных или нет.

Примеры ниже показывают процесс создания тома, размером 20GB с установкой параметра space guarantee в значении -volume.‖ Команда df запускается до и после момента создания тома, чтобы показать занятость пространства на aggregate. Мы видим, что 20GB пространства забирается с aggregate немедленно в момент создания тома, даже если никакие данные на этот том еще не записаны.

netapp1> df -A -g aggr0Aggregate total used avail capacityaggr0 85GB 0GB 85GB 0%aggr0/.snapshot 4GB 0GB 4GB 0%netapp1>netapp1> vol create flex0 aggr0 20gCreation of volume 'flex0' with size 20g on hosting aggregate 'aggr0' has completed.netapp1>netapp1> df -g /vol/flex0File system total used avail capacity Mounted on/vol/flex0/ 16GB 0GB 16GB 0% /vol/flex0//vol/flex0/.snapshot 4GB 0GB 4GB 0% /vol/flex0/.snapshotnetapp1>netapp1> df -A -g aggr0Aggregate total used avail capacityaggr0 85GB 20GB 65GB 23%aggr0/.snapshot 4GB 0GB 4GB 0%

Так как пространство резервируется в полном объеме в момент создания тома, операции записи на том уже не займут пространство, сверх уже зарезервированного на aggregate.

19

Установка резервирования в значение none‖указывает aggregate, что резервировать пространство за томом на его aggregate, в момент его создания, не нужно. Пространство не забирается с aggregate, пока в него не начнется фактическая запись хранимых на томе данных. В примере ниже показано создание тома, размером 20GB с заданием установки guarantee в -none.‖ Команда df, используемая в процессе, позволяет увидеть то, как и когда занимается место на aggregate. Пример также включает в себя создание LUN, который, по умолчанию, использует включенную LUN space reservation. Отметьте, что задание LUN space reservation не ведет к выделению пространства на aggregate. Операции записи в LUN, созданный с резервированием на томе, использующем, в свою очередь, guarantee=none, приведет к отказу в операции, если на содержащем том aggregate не будет достаточно свободного места. Включение LUN space reservation позволяет LUN эксклюзивно занять место на томе, но при установке значения volume space guarantee на -none‖ не гарантирует, что на aggregate будет достаточно места для размещения тома. Тема LUN reservation будет рассмотрена отдельно в этой главе.

netapp1> df -A -g aggr0Aggregate total used avail capacityaggr0 85GB 0GB 85GB 0%aggr0/.snapshot 4GB 0GB 4GB 0%netapp1>netapp1> vol create noneflex -s none aggr0 20gCreation of volume 'noneflex' with size 20g on hosting aggregate'aggr0' has completed.netapp1>netapp1> df -g /vol/noneflexFile system total used avail capacity Mounted on/vol/noneflex/ 16GB 0GB 16GB 0% /vol/noneflex//vol/noneflex/.snapshot 4GB 0GB 4GB 0% /vol/noneflex/.snapshotnetapp1>netapp1> df -A -g aggr0Aggregate total used avail capacityaggr0 85GB 0GB 85GB 0%aggr0/.snapshot 4GB 0GB 4GB 0%netapp1>netapp1> lun create -s 10g -t windows /vol/noneflex/fooMon Nov 24 15:17:28 EST [array1: lun.vdisk.spaceReservationNotHonored:notice]:Space reservations in noneflex are not being honored, either because the volume space guarantee is set to 'none' or the guarantee is currently disabled due to lack of space in the aggregate.lun create: created a LUN of size: 10.0g (10742215680)netapp1>netapp1> df -g /vol/noneflexFile system total used avail capacity Mounted on/vol/noneflex/ 16GB 10GB 6GB 0% /vol/noneflex//vol/noneflex/.snapshot 4GB 0GB 4GB 0% /vol/noneflex/.snapshotnetapp1>netapp1> df -A -g aggr0Aggregate total used avail capacityaggr0 85GB 0GB 85GB 0%aggr0/.snapshot 4GB 0GB 4GB 0%

20

Выставление значения guarantee в -file‖это еще одна возможная опция, но NetApp не рекомендует пользоваться ей. Пользуйтесь ей, только если вам ее порекомендовала служба NetApp Technical Support или иные технические специалисты NetApp.

Volume Snap ReserveПараметр volume snap reserve это пространство, которое резервируется на томе под блоки данных в снэпшотах тома, моментального read-only образа тома. Эта переменная действует на уровне тома и указывается в процентах к объему тома. Data ONTAP исключает заданную процентную долю от емкости тома из доступной пользователям емкости хранения на этом томе. По умолчанию объем volume snapshot reserve для Data ONTAP версии выше 8.0.1 равен 20%, но задание его не обязательно, и может быть установлено в 0%. Если резервирование используется, то зарезервированное пространство доступно только для снэпшотов, и не может быть использовано для размещения LUN-ов или файлов. Когда снэпшотам требуется место для хранения данных, они используют пространство в зарезервированной области. По умолчанию, когда зарезервированная область заполнена, и только тогда, снэпшоты начнут занимать место на пространстве данных в томе.

LUN Overwrite Reserve (опция FRACTIONAL_RESERVE)The LUN overwrite reserve это пространство, зарезервированное на томе для его LUN-ов, которое используется для не-снэпшотов (у них есть свой резерв) после того, как все другое пространство на томе будет использовано. Пространство LUN overwrite reserve используется на томах типа FlexVol, которые работают в среде SAN. Использование LUN overwrite reserve не является необходимым для среды NAS, и поэтому NetApp не рекомендует выделять его в NAS, так как это ведет только к непроизводительному расходу дискового пространства. В среде SAN это резервирование используется в качестве страховки на тот случай, когда на томе не останется места после того, как данные LUN-а, расположенного на томе, будут перезаписаны, частично или целиком, в период между одним и другим снэпшотом этого тома. В особенности это может быть востребовано, когда большой объем данных записывается на LUN после того, как с него был сделан снэпшот, поэтому объем снэпшота на томе может значительно вырасти и занять значительное пространство (вплоть до полного объема LUN-а).

Опция LUN overwrite reserve это опция уровня тома и устанавливается в процентах. Процент вычисляется, основываясь на текущем числе занятых блоков всех LUN-ов данного тома на момент создания снэпшота тома. Data ONTAP изымает заданный процент пространства с тома в момент создания снэпшота. После появления функциональности автоудаления снэпшотов (snapshot autodelete) в Data ONTAP 7.1, NetApp, как общую рекомендацию, советует устанавливать параметр LUN overwrite reserve в 0 и использовать возможности autodelete.

Опция autodelete позволяет автоматически удалять снэпшоты согласно заданному порогу, мы рассмотрим использование ее в отдельной главе далее.

Если на томе используется LUN overwrite reserve, то его пространство зарезервировано как последний резерв места для записи данных, поступающих на LUN в том случае, если все другое пространство на томе уже недоступно. Этот резерв не позволяет использовать себя для размещения снэпшотов. Снэпшоты занимают место на томе сначала в пределах volume snap reserve, пока оно не наполнится целиком, а затем, продолжая занимать место на свободном пространстве тома. Создание снэпшота завершится неудачей, если для его размещения нет места, исключая пространство LUN overwrite reserve. Настройка размера LUN overwrite reserve разрешена

21

для тома FlexVol, на котором параметр volume space guarantee установлен в значение -volume,‖ и, начиная с Data ONTAP 7.3.3, на котором volume space guarantee установлен в -none.‖ Когда volume space guarantee установлен в значение -none‖ или -file,‖ величина LUN overwrite reserve установлена в 100%. Величину зарезервированного в LUN overwrite space пространства можно увидеть с помощью ключа -r‖ команды df. Величина LUN overwrite reserve по умолчанию составляет 100%, это наиболее консервативная величина для этого резерва, и наихудшая с точки зрения эффективности расходования пространства. Когда это возможно, она может быть уменьшена, чтобы соответствовать оценочной величине объемов перезаписи данных на LUN от одного снэпшота, до другого, и обеспечить при этом достаточный объем в случае, если том будет заполнен новыми данными или снэпшотами.

Рис. 8) Примеры LUN overwrite reserve.

Рисунок 8 показывает, как различные величины LUN overwrite reserve влияют на доступное пространство на томе thick-provisioned (с установкой guarantee = volume). В левой половине рисунка 8 показывается том, размером 100GB, содержащий два 20GB LUN-а. На центральной части рисунка показана ситуация, когда LUN-ы заполнены, и установлен LUN overwrite reserve размером по умолчанию. Созданием снэпшота Data ONTAP включит резервирование, размером 40GB (2 x 20GB) пространства на томе, чтобы гарантировать достаточно места на дисках на случай, если все блоки данных на LUN-ах будут перезаписаны. Величина резерва в 100% от емкости LUN оставит достаточно места для данных даже в том случае, если оба LUN-а будут перезаписаны новыми данными полностью. Правее на рисунке вы видите вариант, когда величина резервирования установлена в 60%. В этом случае, после того, как будет создан снэпшот на томе, Data ONTAP зарезервирует заданный объем в 60% от объема LUN-ов, это будет объем, равный 24GB (60% * [2 x 20GB]). Этого пространства достаточно, чтобы перезаписать 60% емкости обоих LUN-ов в сумме новыми данными. В отдельных случаях мы можем оценить величину объема перезаписи от одного снэпшота до другого, и выбрать более экономичную величину LUN overwrite reserve.

22

Volume AutosizeЭто параметр тома (он стал доступен, начиная с версии Data ONTAP 7.1) определяет то, что том может самостоятельно увеличиваться в размерах, по мере заполнения его данными, чтобы избежать его переполнения. Эта опция доступна только на томах типа flexible volumes. Определите величину инкремента емкости опцией -i. Значение инкремента по умолчанию равно 5% от емкости тома на момент его создания. Определить максимальную величину объема тома при увеличении можно указанием опции -m. Величина по умолчанию составляет 120% от объема в момент создания. Параметр тома autosize по умолчанию выключен.

Volume Snapshot AutodeleteЭтот параметр тома (стал доступен, начиная с версии Data ONTAP 7.1) позволяет Data ONTAP автоматически удалять снэпшоты в соответствии с заданным порогом срабатывания. Этот порог называется -trigger‖ и может быть установлен таким образом, чтобы снэпшоты автоматически удалялись с тома по достижению следующих условий триггера:

volume — Том близок к заполнению, И объем volume snap reserve исчерпан. Этот объем сообщается в первой строке для каждого тома в выводе команды df. Следует отметить, что том может быть полон, даже если в snap_reserve есть место, в этом случае autodelete не будет запущен.

snap_reserve — Емкость volume snap reserve на данном томе исчерпана. space_reserve — Зарезервированное на томе пространство близко к исчерпанию, и место в

пределах volume snap reserve скоро закончится. Под зарезервированным пространством понимается то, что было определено в LUN-ах с включенным space reservations и опцией LUN overwrite reserve (fractional_reserve). Эта опция не рекомендуется NetApp к использованию в NAS системах.

NetApp настоятельно рекомендует использовать триггер, установленный в значение volume.

Порядок, в котором будут удаляться снэпшоты задается следующими тремя опциями:

delete_order — Эта опция определяет, должен ли быть удален сперва самый старый, или самый новый снэпшот из имеющихся.

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

commitment — Эта опция определяет, как должны обрабатываться снэпшоты, сделанные для работы SnapMirror® и команды dump. Если значение задано -try,‖ то будут удаляться снэпшоты, которые не заблокированы на удаление. Если опция установлена в -disrupt,‖ то снэпшоты будут удаляться даже в том случае, если они заблокированы (например, используются в данный момент). Эти снэпшоты в любом случае будут последними удаляемыми снэпшотами тома. Во многих конфигурациях, удаление снэпшота SnapMirror крайне нежелательно, так как потребует выполнения после этого длительной процедуры full baseline copy transfer для того, чтобы иметь возможность продолжить операции репликации данных. Если, допустим, источник и получатель репликации находятся на разных сайтах, пересоздание baseline copy может занимать много времени и быть дорогостоящей операцией, так как займет ресурсы канала передачи данных между сайтами. Рекомендуется использовать опцию в значении -try.‖

23

Алгоритм, который определяет порядок удалений снэпшотов, сперва находит снэпшоты, не удовлетворяющие условиям -defer_delete. Затем он определяет среди них, руководствуясь правилом в -delete_order то, удалить ли самый старый, или, наоборот, самый новый снэпшот из списка. Если при этом не находится ни одного кандидата на удаление, то критерий -defer_delete‖ игнорируется. Если и в этом случае ни одного снэпшота удалить не удается, то удаляются снэпшоты SnapMirror и dump. Способ удаления этих снэпшотов определяется согласно значению опции –commitment.

Удаление снэпшотов прекращается, когда освобождается свободное место на томе в объеме, заданном значением опции -target_free_space, по умолчанию это 80%.

Если включены одновременно и autosize, и autodelete, и при этом триггер autodelete установлен на -volume, то будет использовано значение опции тома -try_first для определения того, будет ли сначала том увеличен, или же сначала должны удаляться снэпшоты.

LUN ReservationПараметр LUN reservation определяет то, когда пространство, заданное как размер LUN, будет распределено эксклюзивно данному LUN, с несущего его тома. Если LUN reservation включен, то пространство вычтется из доступного пространства на томе в момент создания LUN. Например, рассмотрим aggregate размером 100GB, который содержит один том с включенным space-guarantee, размером 80GB. Это означает, что на этом aggregate есть 20GB свободного места, и 80GB занято томом в момент его создания (thick provisioning). Теперь представим, что на томе создан 20GB LUN, с включенными параметром LUN reservation. На томе 80GB, 20GB пространства будет вычтено из доступного пространства в момент создания LUN, что снизит объем, доступный для размещения других файлов или LUN-ов на этом томе до 60GB, даже если LUN пуст. Пространство на aggregate останется прежним, и том c LUN-ом на нем по-прежнему будет занимать на aggregate 80GB места.

Если же LUN создан с отключенным параметром LUN reservation, то пока LUN пуст, например, сразу после его создания, то свободное пространство на томе, где лежит этот LUN, не уменьшится, и будет уменьшаться только по мере того, как на LUN будут записываться пользовательские данные. Если взять пример выше, то в рассматриваемом случае, после создания 20GB LUN с выключенной LUN space reservation, свободное пространство на томе по-прежнему будет составлять 80GB, и эта величина изменится только когда данные поступят на LUN.

Общийвид ситуацииРисунок 9 показывает то, как распределяется и выделяется пространство для тома и LUN при thin provisioning, включая то, как ранее описанные параметры влияют на доступность пространства.

24

Рис. 9) Как распределяется пространство при thin provisioning для тома и LUN.

Справочная таблица параметровВ таблице 5 вы найдете краткий справочник по параметрам, рассмотренным в этом разделе, плюс еще один параметр, volume grow area.‖Параметр volume grow area‖не связан с какими-то конкретными настройками как таковыми, но он определяет то, как используется размер aggregate. Значение ―yes‖задает то, что место на aggregate должно использоваться, позволяя рост объема тома. Эта таблица – простой способ показать все ключевые настройки для различных областей применения, и не раз будет использоваться в этом качестве далее в документе.

25

Таблица 5) Основные параметры создания тома и LUN.

Параметр ЗначениеAggregate

volume grow area yes | no

Volume optionsguarantee Volume | file | none

fractional_reserve W%

autosize on |off

autosize options -m Xg -i Yg

try_first volume_grow | snap_delete

Volume Snapshot optionsreserve Z%

autodelete on | off

autodelete options volume | snap_reserve | space_reserve

LUN Optionsspace reservation enabled | disabled

2.3 Установка и лицензирование Thin Provisioning Thin provisioning это функция, не требующая лицензирования и включенная в каждую систему NetApp FAS по умолчанию. Использование thin provisioning зависит от используемой системной конфигурации.

NetApp thin provisioning поддерживается на всех моделях систем хранения NetApp FAS и V-Series, а также на соответствующих им системах хранения IBM N-series.

2.4 Командыдля работы с Thin ProvisioningВ этой главе мы рассмотрим различные команды и параметры, которые могут быть использованы с thin provisioning. Мы приведем общий обзор команд создания томов и LUN-ов, которые в дальнейшем будут подробно рассмотрены, ниже в этом документе.

Таблица 6) Команды создания томов и LUN-ов, и их параметры.

Команда ДействиеСоздание нового тома:vol create flexvol_nameaggr_name –s[volume|file|none] size[k|m|g|t]

Создает том типа FlexVol с заданным типом space guarantee (volume, file, или none) и желаемым размером гарантированного пространства (KB, MB, GB, или TB).Для использования на томе thin provisioning установите значение guarantee в -none.‖Для использования на томе thin provisioning, но одновременно позволяя отдельным LUN-ам на нем резервировать место на уровне aggregate (то есть для thick provisioning на уровне LUN) установите значение guarantee в -file.‖Для использования на томе thick provisioning установите значение guarantee в -volume.‖

26

Изменение уже существующего тома:vol options flexvol_nameaggr_name guarantee[volume|file|none]

Изменяет установки space guarantee на уже существующем томе FlexVol.Для использования на томе thin provisioning установите значение guarantee в -none.‖Для использования на томе thin provisioning, но одновременно позволяя отдельным LUN-ам на нем резервировать место на уровне aggregate (то есть для thick provisioning на уровне LUN), установите значение guarantee в -file.‖Для использования на томе thick provisioning установите значение guarantee в -volume.‖

Задание LUN overwrite reserve (fractional_reserve):vol options flexvol_namefractional_reserve percent

Резервирует пространство внутри тома с LUN-ами, для использования под не-снэпшотные данные, после того, как все другое доступное пространство тома будет занято данными.Это пространство используется как страховочное для того, чтобы гарантированно иметь достаточное место на томе для данных LUN-ов в случае, если после взятия снэпшота, большой объем блоков в LUN будет перезаписан новыми данными, что повлечет за собой значительное увеличение объема, занимаемого на диске уже сделанным снэпшотом. (величина по умолчанию - 100%)

Автоматическое расширение тома:vol autosize flexvol_name [-m<size>[k|m|g|t]] [-i<size>[k|m|g|t]] [ on | off |reset ]

Определяет, будет ли автоматически расширяться том при нехватке места, и насколько (по умолчанию – выключено).

Try_first:vol options volname try_first[snap_delete|volume_grow]

Определяет, что будет выполняться первым в случае нехватки пространства: расширение тома (volume_grow) или удаление снэпшотов (snap_delete)

Задание volume snapshot reserve:snap reserve –V flexvol_namepercent

Резервирует место на томе под хранение снэпшотов, вычитая и скрывая заданный процент емкости из общего объема тома (по умолчанию - 20%)

Задание volume snapshot autodelete:snap autodelete flexvol_name[on|off|show|reset|help]

Определяет, когда и при каких условиях будут автоматически удаляться снэпшоты (по умолчанию - выключено)

Создание нового LUN:lun create -s size –t ostype[–o noreserve] lun_path

Создает LUN с заданным типом space guarantee, reserve or noreserve (по умолчанию - reserve).Для LUN thin provisioning используйте -o noreserve.‖Для LUN thick provisioning НЕ указывайте ‖-o noreserve‖ и используйте значение по умолчанию.Внимание: Выбор thick provisioning для LUN обеспечивает достаточно места для LUN на его томе, но не гарантирует наличие места на aggregate для содержащего его тома. См. Создание нового тома для подробностей.

Изменение уже существующего LUN:lun set reservation lun_path[enable|disable]

Изменяет значение параметра reservation для уже существующего LUN (по умолчанию - enable).Для использования thin provisioning укажите -disable.‖Для thick provisioning, укажите -enable.‖Внимание: Указание значения reservation как -enable‖ обеспечивает достаточно места для LUN на его томе, но не гарантирует наличие места на aggregate для содержащего его тома.

27

2.5 Thin Provisioning: быстрый стартЭта глава описывает необходимые шаги для включения и конфигурирования thin provisioning на томе FlexVol и для LUN. Для полного синтаксиса перечисленных команд и всех доступных в них опциях, смотрите man pages или документ Commands: Manual Page Reference, доступный на http :// support . netapp . com .

Table 7) Краткая шпаргалка по thin provisioning.

Описание КомандаНастройки уровня aggregateСоздание aggregate aggr create <aggr_name>

Расширение aggregate, когда на нем требуется больше места

aggr add <aggr_name>

Настройки уровня томаВключение thin provisioning при создании тома (без space guarantee)

vol create <vol_name> –s none <aggr_name> <size>g

Включение thin provisioning на уже существующем томе (удаление space guarantee)

vol options <vol_name> guarantee none

Установка LUN overwrite reserve vol options <vol_name> fractional_reserve 0

Включение volume autosizing vol autosize <vol_name> –m <max_size>g –I <increment_size>g on

Выбор между расширением тома или удалением снэпшотов

try_first [volume_grow|snap_delete]

Задание snapshot reserve snap reserve –V <vol_name> <percent>

Включение автоудаления снэпшотов

snap autodelete <vol_name> on

Задание того, когда начнется автоудаление снэпшотов

snap autodelete <vol_name> trigger volume

Конфигурирование поведения автоудаления снэпшотов

snap autodelete <vol_name> delete_order oldest_first

Настройки уровня LUNВключение thin provisioning при создании нового LUN (без space reservation)

lun create –s <size>g –t <ostype> -o noreserve/vol/<vol_name>/<lun_name>

Включение thin provisioning на существующем LUN (удаление space reservation)

lun set reservation /vol/<vol_name>/<lun_name> disable

2.6 Политики Thin Provisioning в Provisioning ManagerProvisioning Manager обеспечивает простой способ создания политик распределения пространства хранения с помощью графического интерфейса и мыши. Использование политик для сред NAS и SAN проще, чем выполнение скриптов, и помогает минимизировать риски неправильной конфигурации.

Внимание: Версии Provisioning Manager ранее 4.0 не могут использовать autosize и autodelete

28

Внимание: Процедуры conformance tests в Provisioning Manager принудительно установят настройки в те, что определены в соответствующей политике. Если Provisioning Manager использован для установки thin provisioning, а затем некоторые параметры были изменены вручную, или в постпроцессном скрипте, то Provisioning Manager откатит эти изменения в настройках на те, что указаны в соответствующих оригинальных политиках Provisioning Manager.

Для подробностей по данной теме смотрите TR-3710: Operations Manager, Provisioning Manager, and Protection Manager Best Practices Guide.

Распределение пространства тома с помощью Provisioning ManagerРисунок 10, приведенный ниже, показывает скриншот раздела volume provisioning в Provisioning Manager. Каждая опция соответствует предварительно заданной политике тома, как это показано на рисунке. Это позволяет легко и консистентно задать настройки для политик NAS, включая guarantee space для данных и снэпшотов, автоматическое увеличение тома (volume growing), и автоматическое удаление снэпшотов. Снимите отметку, установленную по умолчанию с первой опции, чтобы включить для тома thin provisioning. Отметка в опции Reserve space for Snapshot copies может использоваться с thin provisioning.

Рис. 10) Создание тома с помощью Provisioning Manager.

Распределение пространства LUN с помощью Provisioning ManagerРисунок 11, приведенный ниже, показывает скриншот раздела LUN provisioning в Provisioning Manager. Каждая опция, представленная на рисунке, соответствует заданной политике создания LUN. Это позволяет легко и консистентно задать настройки для политик SAN, включая guarantee space для данных и снэпшотов, автоматическое увеличение тома (volume growing), и автоматическое удаление снэпшотов. Отметка последней опции задает создание LUN в режиме

29



thin provisioning, что означает, что место на томе не занимается до тех пор, пока в LUN не начнутся физические записи данных.

Рис. 11) Создание LUN с помощью Provisioning Manager/LUN provisioning.

2.7 Мониторинг Thin Provisioning с помощью Operations ManagerNetApp Operations Manager обеспечивает мониторинг и администрирование совместно-используемого пространства хранения для thin provisioned-системы. Ключевыми компонентами для thin provisioning являются возможность задавать пороги срабатывания и уведомления, создавать отчеты по утилизации и трендам, мониторить производительность и конфигурировать хранилище. Возможности мониторинга для этих компонентов критически важно для достижения необходимых уровней эффективности и доступности. Operations Manager – это клиент-серверное приложение, которое предоставляет все перечисленные возможности через единую консоль. Оно также предоставляет прикладной интерфейс (application programming interface, API) для интеграции со сторонними продуктами управления.

Operations Manager мониторит инфраструктуру хранения NetApp и может рассылать уведомления о тех или иных событиях в ней. События могут запускать те или иные действия. Когда событие запускает триггер уведомления, оно может быть отослано на e-mail, pager, с помощью SNMP, или настраиваемого скрипта.

Мониторинг LUN-ов может быть несколько более сложным. Простой подход к мониторингу LUN-ов, это поместить их в qtree, и назначить этим qtree величину soft quota. Отчет по qtree будет содержать ключевую информацию по утилизации для каждого LUN. Для взаимодействия со средствами мониторинга, которые могут принимать SNMP traps, сделайте значение quota как threshold quota.

30

Пороги срабатыванияOperations Manager мониторит соответствующие параметры, которые отражают существование определенных ситуаций, таких как заполненность томов или aggregates, и их приближение к полному заполнению, или же опасное повышение уровня утилизации имеющегося пространства в случае, если вы используете overcommit (распределение хостам большего объема, чем его физически имеется у системы хранения).

Operations Manager обеспечивает возможность установить порог срабатывания, по которому будет настроено срабатывание триггера события, когда определенное условие начнет выполняться. Например, вы можете уведомлять команду администраторов о том, что такое-то событие требует их немедленного внимания. Пороги могут быть настроены как глобально, на уровне системы хранения в целом, так и индивидуально, на уровне отдельного aggregate.

В Operations Manager, установить и проверить установленные пороги срабатывания можно на странице Default Thresholds, которую можно найти по пути Setup→Options→Default Thresholds. Рисунок 12 показывает пример страницы конфигурации.

Рис. 12) Экран Operations Manager по конфигурированию порогов операционных метрик.

Мониторинг состояния aggregate – это задача очень важная. Aggregates используются для размещения на них пулов хранения, физических контейнеров как с заранее выделенной емкостью, так и растущих по объему объектов хранения. Если aggregate, на котором используется thin provisioning, не мониторится, это может иметь прямые последствия для других приложений, использующих ресурсы того же aggregate.

Пороги могут быть выставлены на различные уровни, в соответствии с критичностью события. Имеются порог срабатывания типа warning и порог типа error, сигнализирующий, если достигнуто критически опасное состояние. При определении значения порога крайне важно принимать во

31

внимание гибкость и взаимозависимости планов необходимых действий. Эти планы действий в дальнейшем в этом документе называются «процедурами снижения рисков переполнения».

Процедуры снижения рисков переполнения описывают действия, которые следует предпринять при тех или иных событиях.

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

Ниже приведены пороги событий, которые Operations Manager определяет для aggregates. Они соответствуют абсолютным лимитам. Для информирования операционного персонала и администраторов системы можно использовать средства уведомления в Operations Manager (alarms), которые срабатывают и отсылаются, когда достигнуты заданные пороги.

Aggregate full threshold: Этот порог устанавливается на значение, с которого aggregate считается заполненным. Это критическое состояние (critical).

Aggregate nearly full threshold: Этот порог устанавливается на значение, с которого aggregate считается почти заполненным. Это тревожное состояние (warning).

Aggregate overcommitted threshold: Этот порог установлен на значение такой степени избыточного заполнения (overcommit) для aggregate, которое считается предельным. Это критическое состояние. Этот параметр указывает на величину емкости, назначенной приложениям. Значение по умолчанию установлено в 200%, и отражает ситуацию, когда aggregate может нести на себе тома и LUN суммарным объемом на 100% превышающим его физическую емкость.

Aggregate nearly overcommitted threshold: Этот порог установлен на значение такой степени избыточного заполнения (overcommit) для aggregate, которое считается близким к предельному. Это тревожное состояние. Этот параметр указывает на величину емкости, назначенной приложениям. Значение по умолчанию установлено в 150%, и отражает ситуацию, когда aggregate может нести на себе тома и LUN суммарным объемом на 50% превышающим его физическую емкость.

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

Пороги, аналогичные имеющимся для aggregate, у Operations Manager есть и для томов.

Volume full threshold: Этот порог устанавливается на значение, с которого том считается заполненным. Это критическое (critical) состояние.

Volume nearly full threshold: Этот порог устанавливается на значение, с которого том считается почти заполненным. Это тревожное (warning) состояние.

Volume growth event minimum change threshold: Этот порог установлен для тома на событии, когда том расширяется функцией autosize с минимальным объемом изменений. Это состояние типа «принять к сведению» (informative). Этот параметр можно использовать для отслеживания ситуации, когда том регулярно растет, что может означать, что пространство на томе быстро потребляется снэпшотами или пользовательскими данными.

32

Оценка тенденцийOperations Manager 4.0 и новее поддерживает возможности оценки «трендов» или тенденций для характеристик объектов хранения, таких как aggregates и тома. Это важная возможность, так как она позволяет вам оценивать временные рамки для событий, например, когда объект хранения ориентировочно заполнится, и когда возникнет необходимость в принятии мер. Тренд вычисляется как линейная интерполяция по периоду в 90 дней. Для структуры aggregates, Operations Manager вычисляет тренды его суточного роста. В Operations Manager картину тренда для aggregate, включая показатели Daily Growth Rates и Days To Full, можно посмотреть, перейдя в панель Aggregate Growth по пути Reports→All. Там выберите Aggregates в группе Physical Objects , а затем выделите Aggregate Growth среди доступных отчетов раздела Available Reports, затем нажмите кнопку Show.

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

Рисунок 13 показывает вид страницы Aggregate Growth, на которой суммарная информация отсортирована и может быть быстро охвачена взглядом. Щелкая на различных объектах на данной странице, вы сможете получить дополнительные сведения, например различные отчеты по трендам.

Рис. 13) Тренды (тенденции) роста объемов aggregate и предсказание «дней до заполнения» в окне Operations Manager.

Мониторинг эффективности NetApp Operations Manager предоставляет инструмент мониторинга эффективности хранения, с помощью которого можно визуализировать эффективность распределения пространства, а также

33

результативность работы средств экономии на системах хранения NetApp. Этот дашборд включает в себя полезные инструменты, такие как средства углубленного анализа утилизации, емкости, неиспользованных объемов резерва, эффективности хранения и величин емкости, которые удалось вернуть как свободное место.

Эта информация, в совокупности, показывает эффективность технологий NetApp по экономии пространства хранения. Рисунок 14 показывает вид этого дашборда в NetApp Operations Manager. Подробнее на эту тему смотрите в документе NetApp Operations Manager Efficiency Dashboard Installation and User Guide.

Рис. 14) Operations Manager storage efficiency dashboard.

2.8 Уведомления Группа администраторов системы хранения должны получать уведомления о ситуациях, ведущих к исчерпанию пространства, необходимых мерах по снижению возможных рисков переполнения хранилища и обеспечению непрерывной доступности данных и ресурсов для пользователей и приложений. Как мы уже рассмотрели раньше, Operations Manager позволяет установить пороги срабатывания (thresholds) для того, чтобы активировать уведомления о событиях. Эти уведомления отправляются персоналу, например системным администраторам, администраторам системы хранения, менеджменту и ответственным за планирование емкости хранения. Эти уведомления являются хорошим инструментом для снижения административных затрат на обслуживание системы хранения.

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

34

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

Operations Manager может посылать уведомления различными способами. Эти способы могут быть использованы по отдельности, или скомбинированы; например уведомление может быть отослано только по e-mail, или одновременно по e-mail и через SNMP, при определенных условиях.

Уведомление по E-Mail Operations Manager поддерживает уведомления по e-mail, настраиваемые в меню Alarms. Уведомление может быть послано на несколько адресов e-mail. Если ситуация не разрешена, то может быть настроена посылка повторяющихся уведомлений. Для настройки отсылки уведомлений пройдите на страницу Alarm по пути Setup→Alarms в настройках Operations Manager. Доступ к дополнительным настройкам уведомлений находится в Advanced Version. Рисунок 15 показывает скриншот для настройки уведомления, включая адрес e-mail. Событие, установленное в Event Name на странице Alarms, имеет порог срабатывания, о котором мы поговорим далее в разделе о порогах срабатывания (thresholds).

NetApp рекомендует для рассылки уведомлений использовать почтовые группы (distribution lists) или алиасы, вместо адресации уведомлений на каких-то индивидуальных получателей. Это устраняет необходимость настраивать адреса конкретных получателей в Operations Manager всякий раз, когда в компании меняются работники группы администраторов или их роли в группе.

Уведомление по SNMP Operations Manager поддерживает использование SNMP alerts/traps для генерации уведомлений. SNMP traps могут быть направлены на специальный хост, который выполнит соответствующее действие вне Operations Manager. SNMP широко используется во множестве управляющих фреймворков и систем. Используя SNMP, Operations Manager может быть интегрирован в существующую систему управления более высокого уровня. Рисунок 15 показывает скриншот для конфигурации уведомлений, включающей в себя SNMP trap host. Этот SNMP trap host конфигурируется с использованием имени хоста или IP-адреса и порта, на котором слушает SNMP-агент. Событие, определенное как Event Name на странице Alarms, соответствующее заданному порогу срабатывания, настраивается так, как мы это обсудили в главе, обсуждавшей пороги срабатывания.

35

Рис. 15) Конфигурирование уведомления о заполнении aggregate.

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

Уведомление с использованием скрипта Operations Manager поддерживает также определенные пользователем «адаптеры», которые можно использовать для уведомлений в сценарии глубоко модифицированной системы. Заданный пользователем «adapter» может быть выполнен, доставляя информацию в инфраструктуру, или же систему по вашему выбору. Скрипты могут использоваться как сами по себе, так и как связующее звено между Operations Manager и такой глубоко модифицированной информационной системой. Например, установка уведомления Operations Manager для срабатывания скрипта по событию Aggregate Almost Full, с использованием командной строки:

dfm alarm create –s script_to_execute –h aggregate-almost-full

2.9 Сохранение доступности хранилищаЭта глава посвящена действиям, которые могут быть использованы как интегральная часть процесса thin provisioning для сохранения доступности хранилища и данных на нем. Эти действия, которые в данном документе мы будем называть «процессы снижения рисков», создают совместно используемый пул хранения в виде aggregates и/или томов. Критически важно начать соответствующие процессы до того, как система столкнется с исчерпанием места. Доступность хранилища и тренды загрузки емкости должны отслеживаться с помощью инструментов, которые были рассмотрены ранее в этом документе. Затем, когда это необходимо, должны быть инициированы процессы снижения риска исчерпания пространства на томах и aggregate, при необходимости они должны повторяться в дальнейшем вновь и вновь. Правильные процедуры

36

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

Переполнение хранилища это ситуация, когда пул блоков хранения более не соответствует требованиям минимально доступного свободного объема на нем, как он был определен администратором системы хранения. Переполнение хранилища может случиться в ходе его использования, как на уровне aggregate, так и на уровне тома.

Когда тома данных сконфигурированы на использование thin provisioning, они используют нераспределенное пространство на aggregate как совместно используемый пул блоков хранения, и пользуются блоками оттуда для размещения растущего на них объема данных. По мере того, как доступное на томе пространство уменьшается, или приближается к определенному лимиту, например к заданному порогом Aggregate Nearly Full Threshold,‖необходимо предпринимать меры на уровне aggregate.

Когда LUN-ы, размещенные на thick-томе, сконфигурированы на использование thin provisioning, они используют нераспределенное пространство на томе как совместно используемый пул блоков хранения, и пользуются блоками оттуда для размещения растущего на них объема данных. По мере того, как доступное на томе пространство уменьшается, или приближается к определенному лимиту, например к заданному порогом Volume Nearly Full Threshold,‖необходимо предпринимать меры на уровне тома.

Следующие две подглавы описывают способы снизить риски, отдельно для aggregates и томов.

Процедуры снижения рисков исчерпанияпространстваAggregate – это наиболее грубо-определяемый объект хранения для контроллера системы хранения NetApp. Когда используется thin provisioning, то он применяется к более мелким и тонко-определяемым объектам хранения, например томам типа FlexVol и LUN-ам. Хотя тома и LUN-ы могут изменять свой размер по необходимости, их размер ограничен размером содержащего их aggregate, и его физическим размером. План использования thin provisioning должен включать в себя различные процедуры по снижению рисков переполнения, приведенных ниже. Это необходимо для того, чтобы быть уверенным в том, что в случае неожиданного роста потребления у ваших томов и aggregates останется достаточно места для бесперебойного обслуживания. Кроме этого, подобные действия могут быть использованы в случае аварийных ситуаций, таких как незапланированные перебои, вызванные пиковыми объемами операций записи, которые могут заполнить диски быстрее, чем запланировано. Такие ситуации могут оказывать влияние также на работу и других томов и LUN-ов данного aggregate, поэтому в таких случаях требуются немедленные корректирующие действия.

1. Расширьте aggregate: Новые физические диски могут быть добавлены в состав aggregate «на ходу», без прерывания его работы. Вы можете повторять эту операцию предотвращения переполнения хранилища до тех пор, пока не будет достигнут максимально допустимый размер aggregate. Эта величина зависит от версии Data ONTAP, типа aggregate, и типа контроллера системы хранения. Тип, называемый 64-bit aggregates, поддерживается в Data ONTAP 8, и имеет весьма высокие лимиты на размер. Дополнительные физические диски могут быть использованы

37

немедленно; однако помните о времени, необходимом на закупку и доставку дисков для системы, это время надо учитывать при планировании объемов и их расширении. Ребалансировка данных между существующими и новыми дисками ведет к равномерности загрузки и использования старых и новых дисков.

2. Уменьшите размер aggregate snapshot copy reserve: Этот резерв используется для систем MetroCluster™ и использующих SyncMirror®. Для всех других конфигураций вы можете уменьшить его величину до нуля.

3. Сократите размеры thick-томов: Если у вас на aggregate присутствуют thick-тома (guarantee = volume) с большими объемами выделенного, но неиспользованного в них данными пространства, рассмотрите вариант уменьшить их размер, что сделает неиспользованный в этих томах объем свободного пространства, доступным для других томов и LUN-ов на этом aggregate. При распределении пространства на томе помните о необходимости следить за трендами использования пространства, и характере работы приложений

4. Используйте дедупликацию для томов: Включение дедупликации данных на томе даст возможность сэкономить пространство хранения. Если том использует thin provisioning, то дедупликация вернет пространство на уровень aggregate. Если том использует thick provisioning, то экономия от дедупликации появится на самом этом томе, и будет доступна для LUN-ов и файлов этого тома. Дедуплицированный том может быть также уменьшен в размерах, возвращая экономию, полученную на томе, на уровень aggregate.

5. Перенесите MultiStore vFiler не останавливая его работы: Миграция намеченного для переноса кандидата в виде контейнера vFiler позволяет переносить данные в онлайне между разными aggregate. MultiStore® позволяет на одном контроллере организовывать безопасную «кооперативную» (multi-tenancy) среду, в которой различные отдельные «виртуальные» системы хранения безопасно сосуществуют на одном физическом контроллере. MultiStore включает в себя возможность прозрачно переносить контейнеры таких «виртуальных систем хранения» между контроллерами различных HA-пар, без прерывания работы и обслуживания ими данных. Эти возможности можно использовать для организации процедур снижения рисков переполнения. VMware также имеет средство мигрирования – Storage VMotion™, которое позволяет прозрачную миграцию контейнеров хранения без остановки их работы, однако подробный разбор этого средства выходит за рамки этого документа. Соответствующий объем свободного места должен быть доступен на aggregate-получателе миграции. Подробнее о DataMotion™ for vFiler®, смотрите в TR-3814: NetApp DataMotion for vFiler.

6. Выполните миграцию LUN с одного aggregate на другой: Начиная с Data ONTAP 8.1 7-Mode, функция NetApp DataMotion for LUNs предлагает возможность прозрачной миграции LUN-ов (поддерживаемые протоколы FCP, FCoE, или iSCSI) между aggregates без остановки их работы и обслуживания ими данных. Эта операция также может быть использована в составе процедур снижения рисков переполнения. Для подробностей о NetApp DataMotion for Volumes, смотрите TR-3873: NetApp DataMotion for Volumes, и TR-3881: DataMotion for Volumes for Enterprise Applications.

7. Мигрируйте тома с одного aggregate на другой, на том же или другом контроллере, с минимальным простоем: Миграция намеченного тома-кандидата на другой aggregate с минимальным временем простоя может быть выполнена с помощью средств репликации.

38





Для выполнения этого потребуется лицензия на функцию SnapMirror. SnapMirror реплицирует данные в то время, как доступ к исходной их копии сохраняется. Для переключения на реплицированный том, клиенту необходимо отключиться от тома-источника, и подключиться к его реплике. После завершения репликации, реплика тома может рассматриваться как новый источник. Эта операция требует определенного времени простоя в отношении доступности пользовательских данных. Обычно современные каналы передачи данных позволяют синхронизировать репликацию источника и реплики в течение минут (это зависит от объемов реплицируемых данных, и первая репликация, так называемый baseline transfer, может выполняться значительно более продолжительное время). Достаточное количество свободного места должно быть доступно на aggregate-получателе. Этот вариант ограничен в применении, так как требует возможности проведения приостановки работы с данными на время переключения приложения на их реплику.

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

Таблица 8 сводит воедино все перечисленные выше способы. Отметьте, что Provisioning Manager выполняет процедуры с 3 по 6 для вторичного хранилища в онлайне.

Таблица 8) Снижение рисков переполнения и недоступности хранилища на уровне aggregates.

# Предпринимаемое действие Частота выполнения

Влияние на SLA

Время подготовки

Когда результат

1 Увеличить емкость aggregate покупкой дополнительных дисков

Любое Нет Покупка дисков

Сразу

2 Уменьшить размер aggregate snapshot reserve, если он создан и не используется

Однократно Нет Нет Сразу

3 Уменьшите thick-тома, если место на них не используется.

Однократно Низкое Нет Сразу

4 Запустите дедупликацию. Любое Низкое/производительность

Время на дедупликацию

Сразу

5 Мигрируйте тома на другой aggregate, на том же или другом контроллере (в онлайне)

Любое Низкое Нет Минуты:DataMotion for VFilers

6 Мигрируйте LUN-ы на другой aggregate (в онлайне)

Любое Низкое Нет Минуты:DataMotion for LUNs

7 Мигрируйте тома на другой aggregate (в оффлайне)

Любое Средне-высокое

Окно обслуживания

Минуты:переключение томов

8 Для предотвращения потери или искажения данных остановите работу приложений и мигрируйте их.

Любое Низко-высокое

Согласовать с пользователем

Минуты:миграция

Сохранение доступности объема хранения на томеСуществует возможность сконфигурировать LUN-ы на использование thin provisioning, в то время как содержащий их том будет использовать thick provisioning. В этом случае, LUN thin provisioning позволит LUN-ам использовать нераспределенное место на thick-томе как совместно

39

используемый пул хранения. Хотя эти LUN-ы могут расти по мере необходимости, так как они расположены на томе, который имеет физическое ограничение на размер, пределы роста этих LUN-ов ограничены. Разработанный thin provisioning plan должен включать в себя одну или более «процедуру снижения рисков исчерпания пространства», как мы называем их в данном документе, и которые перечислены ниже. Эти процедуры обеспечивают тому достаточные объемы хранения, чтобы работа его по обслуживанию доступа к хранимым данным не прерывалась. Кроме этого, подобные действия могут быть использованы в случае аварийных ситуаций, таких как незапланированные перебои, вызванные пиковыми объемами операций записи, которые могут заполнить диски быстрее, чем запланировано. Такие ситуации могут оказывать влияние также на работу и других LUN-ов данного тома, поэтому в таких случаях требуются немедленные корректирующие действия.

Внимание: Некоторые из предлагаемых процедур зависят от имеющегося объема на aggregate, или непосредственно влияют на него.

Таблица 9) Действия по предотвращению переполнения и обеспечению доступности данных.

# Предпринимаемое действие Частота выполнения

Влияние на SLA

Время подготовки

Когда результат

1 Уменьшите объем snapshot reserve на томе, если он установлен и не используется


2 Увеличьте, если это возможно, размер тома и свободное место на aggregate


3 Удалите ненужные снэпшоты, в том числе и те, которые могли быть пропущены операцией snapshot autodelete

Иногда Низкое Нет Сразу

4 Включите на томе дедупликацию Однократно Низкое/ небольшое

Время на дедупликацию

Сразу

5 Если том содержит более чем один LUN, мигрируйте эти данные на другие тома или aggregate.

Регулярно Высокое Окно обслуживания


6 Остановите приложение и мигрируйте его данные

Регулярно Высокое Согласовать с пользователем


40

3 Рекомендации по использованию и наилучшие практикиВ этом разделе документа мы перечислим наилучшие практики применения thin provisioning. Цели данного раздела – дать руководство для начинающего использовать thin provisioning в некоторых, наиболее распространенных сценариях. Смотрите отдельные главы в этом документе, посвященные использованию thin provisioning для конкретных приложений, например VMware®, Oracle®, SharePoint®, и других.

3.1 Thick Provisioning, как режимпо умолчаниюПеред тем, как мы перейдем к рассмотрению наилучших практик thin provisioning, взвесим за и против использования традиционной модели распределения пространства, используемой в системах хранения NetApp при выборе по умолчанию.

Если при распределении пространства хранения использованы значения по умолчанию, то в конечном результате хранилище будет использовать тома и LUN-ы в режиме thick provisioning с дополнительным зарезервированным местом для снэпшотов и LUN overwrites. Таблица 10, ниже, показывает результаты распределения пространства на системе хранения, при использовании всех величин в значении по умолчанию.

Таблица 10) Значения по умолчанию.


volume grow area N/A

Volume optionsGuarantee volume

fractional_reserve 100%

Autosize off

autosize options N/A

try_first N/A

Volume Snapshot optionsreserve 20%

autodelete off

autodelete options N/A

LUN Optionsspace reservation enabled

Цель выбора именно таких значений в том, чтобы обеспечить доступность пространства для хранения поступающих данных в любом, самом наихудшем случае использования, и неизменно доступное пространство для хранения снэпшотов данных. Большой объем дополнительного пространства зарезервирован (LUN overwrite reserve) на случай большого роста хранимых данных (или их изменений), что может вызвать использование всего доступного пространства в LUN, томе и snapshot reserve. Конкретнее, 100% занимаемого размера хранимых данных, зарезервировано на всякий случай. Такой традиционный метод thick provisioning подходит для различных применений и решений (например, смотрите главы, посвященные SQL Server® и Exchange в этом документе).

41

Недостатками использования значений по умолчанию является то, что резервирование из доступного пространства значительных объемов только на случай резких пиковых ситуаций потребления, ведет к высокой относительной стоимости хранения. Например, LUN overwrite reserve, не может быть использован никаким иным способом, кроме как в «аварийном» случае для хранения данных, когда исчерпается основной объем тома, и обычно он так и остается неиспользованным. В результате такой подход гарантирует безопасное хранение с минимумом планирования и оценки, но ему недостает гибкости.

А так как IT сегодня требует все больших результатов на меньшем пространстве хранения, то вопрос начинает ставиться уже не «если мы будем использовать thin provisioning», а «когда и где именно мы будем его использовать».

3.2 Общие практики и рекомендации использования Thin ProvisioningПеред тем, как перейти к рассмотрению рекомендуемых конфигураций thin provisioning, советуем обратить внимание на ряд рекомендаций, основанных на успешных реализациях систем пользователями и нашим внутренним опытом. Эти рекомендации будут использованы, чтобы помочь сформулировать рекомендованные практики для thin provisioning.

Используйте средства Provisioning Manager – Storage Services при установке и задании параметров политик thin provisioning, чтобы обеспечить правильные настройки и следование рекомендациям.

Если не указано иное, всегда, когда это возможно, используйте раздельные aggregates для thin provisioning и thick provisioning, это упростит управление thin provisioning.

Aggregate может быть расширен по объему добавлением в него физических дисков до тех пор, пока не будет достигнут максимально допустимый его на данной системе размер, а далее необходимо предпринять меры для увеличения доступного пространства на aggregate (например использовать дедупликацию томов, миграцию томов /LUN на другие aggregate).

Используйте thick provisioning для root volume системы хранения. Если на момент создания тома хранения с thin provisioning нет информации о планируемом

росте объема и его темпах, используйте тот же подход и оценку емкости, что и для thick provisioning, остерегайтесь чрезмерного оптимизма и высоких уровней overcommitments (запланированного перерасхода). Величина перерасхода емкости может быть скорректирована позже, когда станет доступна информация и темпах роста объемов.

Когда вы планируете объем тома-получателя репликации для резервной копии (например, SnapVault®) или DR (с использованием volume SnapMirror), используйте thin provisioning и установите размер этого тома, равный максимально возможному объему тома соответствующей платформы, или же размеру несущего его aggregate. Это позволит правильно обработать ситуацию с увеличением размера тома на системе-источнике в результате работы там volume autosizing.

Thin provisioning обычно используется с FlexClone® для достижения максимальной эффективности использования пространства при создании клонов.

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

42

NetApp DataMotion и MultiStore обеспечивают возможности реакции на ситуации с исчерпанием места на дисках, без прерывания доступа к данным, что позволяет свободнее использовать thin provisioning и ее возможности для бизнес-критичных приложений.

В общем случае VMware VMotion и NetApp DataMotion при работе не вызывают прекращения доступности данных. Если вы используете критичное для бизнеса приложение, которое использует thin provisioning , но при этом не использует какое-либо решение нулевого даунтайма, внимательнее отнеситесь к задачам мониторинга, установки порогов срабатывания уведомлений, возможно на более низкие, чем обычно, значения.

Решения, использующие thin provisioning, должны иметь предсказуемую величину роста объемов хранимых данных.

Использование функции volume autosize это общепринятая практика для некоторых приложений, как это будет рассмотрено ниже. Хотя этот механизм удобен для эффективного использования пространства такими приложениями, его использование может создать затруднения для учета места и планирования его расхода для других приложений на том же томе или aggregate.

Функция snapshot autodelete может быть использована для автоматического освобождения места на томе, когда свободное место на нем исчерпывается, но в ряде случаев, особенно когда приложение и его данные должны следовать требованиям SLA (service-level agreement), ее использование нежелательно. Возможной альтернативой является использование скриптов, работающих с учетом логики SLA, для удаления только определенных снэпшотов.

3.3 Рекомендуемыеконфигурации Thin ProvisioningСуществует множество возможных конфигураций thin provisioning. Основываясь на рекомендациях наилучших и общепринятых практик, описанных в предыдущей главе, весь список можно сократить до нескольких ключевых конфигураций.

Внимание: Если для конфигурирования thin provisioning был использован Provisioning Manager, внимательно изучите главу Политики thin provisioning в Provisioning Manager в этом документе.

Таблица 11 показывает параметры для каждой из следующих рекомендованных конфигураций thin provisioning:

Том в режиме thin provisioning без резервирования Том в режиме thin provisioning и LUN thin provisioning без резервирования Том в режиме thick provisioning и LUN thick provisioning c volume autosize first Том в режиме thick provisioning и LUN thick provisioning c autodelete first

Таблица 11) Сравнение методов выделения пространства и их требований.

Параметр Vol ThinNo LUNsNo Reserve

Vol ThinLUN ThinNo Reserve

Vol ThickLUN ThinAutosize first

Vol ThickLUN ThinAudodelete first

Aggregatevolume grow area N/A N/A да даVolumeguarantee нет нет volume volumefractional_reserve 0% 0% 0% 0%autosize Off Off On Onautosize options N/A N/A trigger=volume trigger=

43

snap_reserve |space_reserve

try_first N/A N/A volume_grow snap_reserveVolume Snapshotreserve 0% 0% 0% 5%autodelete off off (optional)* on*

autodelete options N/A N/A delete_order = oldest_first

delete_order = oldest_first

LUN optionsspace reservation N/A disabled disabled disabled

Таблица 12 показывает обзор некоторых ключевых характеристик для каждой из четырех рекомендованных конфигураций thin provisioning, где:

X – это объем основных данных = сумма всех пользовательских данных (файлов и директорий) на томе

Δ – это величина пространства, необходимая ля хранения снэпшотов N – это объем традиционно выделенного пространства, равное числу блоков, которые

распределены при создании тома/LUN, но, возможно, еще не использованы

Таблица 12) Характеристики рекомендованных конфигураций thin provisioning.

Характеристика Vol ThinNo LUNsNo Reserve

Vol ThinLUN ThinNo Reserve

Vol ThickLUN ThinAutosize first

Vol ThickLUN ThinAudodelete first

Использование пространства

X - N X - N X X + Δ

Эффективное расходование пространства

да да Частично, LUN-ы и снэпшоты

Частично, LUN-ы и снэпшоты

Мониторинг На уровне aggregate

На уровне тома и aggregate



Необходимость уведомлений и процесса миграции

да да Опционально в большинстве случаев

Опционально в большинстве случаев

Дедупликация возвращает место:

На уровень aggregate

На уровень aggregate

На уровень тома На уровень тома

Риски исчерпания места для хранения данных

Да, при отсутствии мониторинга

Да, при отсутствии мониторинга

Нет, пока есть место для роста тома

Нет, пока есть возможность удалять снэпшоты

* Не используйте autodelete если на томе есть снэпшоты, выполненные SnapManager. Если в ходе работы autodelete будут удалены снэпшоты, создаваемые SnapManager, то это приведет к сбою в его работе.

44

Типичные области использования

Совместно используемые хранилища, домашние папки, DR-сайты, FlexClone, тестовые системы

Совместно используемые хранилища, некоторые тома баз данных, базы Sharepoint, пулы виртуальных серверов и тестовые системы

Большие базы данных

Большие базы данных, где можно удалять старые снэпшоты

?Как следует оценивать размерытома Так как физически размещение данных в томе thin provisioning происходит по мере их фактической записи, теоретически размер тома может быть задан очень большим, что позволит разместить в нем все необходимые данные приложений и их снэпшоты. Так как нераспределенное пространство на томе не резервируется из объема aggregate, все другие приложения, использующие этот же aggregate на системе хранения, могут использовать этот нераспределенный (пока он неиспользованный) объем пространства на дисках. Однако NetApp рекомендует планировать размер тома согласно ожидаемому объему содержащихся на нем объектов, и, если это необходимо, позволить ему автоматически увеличиваться с использованием опции autosize.

Внимание: Помните, если вы используете дедупликацию, необходимо принять во внимание размер тома, для которого в таком случае допустимый размер «сверху» ограничен лимитами на том у функции дедупликации. Проверьте его величину в документации на контроллер используемой модели и применяемую версию Data ONTAP.

3.4 Thin Provisioning на практике

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

Для систем хранения, подключенных по SAN, NetApp рекомендует использовать файловые системы, поддерживающие технологии space reclamation, например команды SCSI UNMAP и SCSI WRITESAME. Эти команды позволяют сообщить системе хранения, что указанный блок больше не используется для хранения данных.

Миграция томов thin provisioning с использованием NetApp DataMotion Использование томов с thin provisioning совместно с решением NetApp DataMotion позволяет построить решение, в котором тома и LUN-ы могут быть легко смигрированы на другой aggregate или контроллер, если это потребуется в ходе эксплуатации системы хранения. Это поможет автоматизировать процессы снижения рисков переполнения и увеличивает степень использования хранилища. При использовании механизма онлайн-миграции NetApp, процессы

45

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

Внимание: DataMotion for LUNs доступен начиная с версии Data ONTAP 8.1 7-mode.

NetApp MultiStore обеспечивает возможности онлайн-миграции с помощью своей структуры-абстракции – vFiler. NetApp рекомендует использовать MultiStore vFiler для организации не прерывающей работу миграции данных.

Кандидаты на миграцию могут быть выбраны по различным критериям. Это могут быть самые старые тома; если ожидается, что они реже всего используются, то они могут быть смигрированы на менее производительные хранилища с более низкой ценой хранения. Или же тома могут быть мигрированы потому, что они переросли запланированный для них размер, или потому, что они имеют наименьший приоритет, согласно SLA. Вне зависимости от определяющего фактора, это позволит автоматически реализовать сценарий реакции. Рисунки 16 и 17 показывают различные фазы примера сценария, использующего кандидата на миграцию, в который входит процесс уплотнения хранилища и миграция тома с одного aggregate на другой. Невключенные в число кандидатов на миграцию показывают, что их данные остаются на месте. Так как не включенные в число кандидатов на миграцию тома не перемещаются, оно могут быть или не быть включенными в структуру MultiStore vFiler. Также решение включить их в vFiler существенно упрощает операции и обслуживание оборудования хранилища, но обязательное использование vFiler для томов, которые не планируется мигрировать, не требуется. Кандидаты на мигрирование, однако, рассматриваются как перемещаемые, и должны быть включены в состав структуры vFiler. Соотношение между объемами мигрируемых и немигрируемых томов зависит от темпов роста объемов, а также времени жизни данных в немигрируемых томах.

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

Реагировать на различные сценарии роста данных. Быстро мигрировать наименьшие по размеру тома, если недостаточно времени или канал

между контроллерами недостаточно широк. Обеспечить продолжительную работу в наиболее комфортном для aggregate уровне

загрузки; это можно сделать, поделив емкость хранилища на небольшие мигрируемые тома, тем самым вы сможете обеспечить работу aggregate с заданным уровнем заполненности.

46

Рис. 16) Пример заполнения aggregate и необходимых действий по снижению его загрузки.

Рис. 17) Пример процесса миграции тома/LUN на другой aggregate.

: Тестирование Thin и Thick Provisioning Thin provisioning может быть использован как при создании нового хранилища, так и для уже используемого хранилища данных, без влияния на его работу и доступность и производительность. Внутреннее тестирование в NetApp и собственный опыт пользователей показывают сходную производительность при сравнении thin provisioning и традиционной схемы (thick provisioning).

47

Для примера возьмем типовое сравнение между thin provisioning и thick provisioning. Тестируемая среда в рассматриваемом случае использовала Microsoft® Exchange, и следовала рекомендациям и наилучшим практикам, описанным ниже в главе, посвященной MS Exchange.

Спецификации тестировавшейся системы:

Симуляция рабочей нагрузки Exchange производилась с помощью Jetstress 2010 Число майлбоксов (пользователей): 1000 Размер майлбокса: 200MB IOPS/Mailbox: 1 (высокая нагрузка) Время тестирования: 2 часа

Результаты подтверждают, что использование thin provisioning не привело к сколь-нибудь заметному снижению производительности по сравнению с thick provisioning для рабочей нагрузки Exchange. Среднее снижение показателей IOPS в случае использования thin provisioning составило всего около 3%.

Влияние на производительностьThin provisioning не оказывает существенного воздействия на производительность приложений.

4 Thin Provisioning и VMware vSphereТестирование использования thin provisioning в среде VMware в настоящее время не закончено. Результаты будут опубликованы в следующих редакциях данного документа. В настоящий момент руководствуйтесь, пожалуйста, документами, перечисленными в главе Справочные материалы ниже.

СправочныематериалыДля дополнительных сведений смотрите эти документы:

NetApp and VMware vSphere Storage Best Practiceshttp://media.netapp.com/documents/tr-3749.pdf

NetApp and VMware Virtual Infrastructure 3 Storage Best Practiceshttp://media.netapp.com/documents/tr-3428.pdf

5 Thin Provisioning и Microsoft SharePointВ этом разделе мы рассмотрим особенности использования thin provisioning и MS SharePoint. Цель документа показать, как следует оценивать и учитывать использование thin provisioning в решении. Раздел и его рекомендации выработаны в результате анализа пользовательских практик и внутреннего тестирования.

5.1 Спецификации Рекомендации этой главы были разработаны для следующих перечисленных версий приложений и версий OS.

Microsoft SharePoint Server 2010o Remote BLOB storage

Microsoft SQL Server 2008 R2

48



Microsoft Server 2008 R2 x64 NetApp System Manager 1.1 NetApp SnapDrive for Windows 6.3 NetApp SnapManager for SharePoint 6.0 NetApp Data ONTAP 7.3.3

Если вы используете версии приложений и OS иные, чем указанные, вам может потребоваться внести изменения в приведенные рекомендации и дополнительные настройки.

5.2 Рекомендацииинаилучшие практикиЭта глава посвящена наилучшим практикам и рекомендациям по использованию NetApp thin provisioning с MS SharePoint. Если вы впервые сталкиваетесь в работе с thin provisioning, NetApp настоятельно рекомендует связаться с техническими специалистами NetApp или его авторизованных партнеров. Таблица 13 показывает рекомендованные NetApp параметры для thin provisioning.

Конфигурирование Data ONTAP для работы сMS SharePointТаблица 13) Рекомендованные параметры Data ONTAP для томов и LUN.


volume grow area yes

Volume optionsGuarantee none

fractional_reserve 0%*

Autosize on

autosize options -m Xg* -I Yg*

try_first volume_grow

Volume Snapshot optionsReserve Z%

Autodelete off


LUN Optionsspace reservation disabled

Внимание: Хотя Microsoft SQL Server является частью SharePoint, рекомендации для базы данных SQL Server не включены в эту главу. Эти рекомендации вынесены в отдельную главу в этом же документе, посвященную конфигурированию MS SQL Server .

Развертывание SharePointThin provisioning рекомендуется использовать для SharePoint RBS Archived Data Store (RBS CIFS share).

Thin provisioning не рекомендуется для использования с RBS Archived Index Store. Так как Index Store не требует большого объема хранения, не представляет большой проблемы развернуть его на thick-хранилище.

* Величины данных параметров зависят от проектируемой системы и определяются на этапе сайзинга

49

NetApp рекомендует использовать LUN для Archived Index/Extender LUN и сетевую папку SMB (CIFS) для Archived Data device. Для подробностей смотрите документ TR-3877: SharePoint Server 2010 and SnapManager 6.0 for SharePoint Best Practices Guide

NetApp рекомендует использовать сетевую папку CIFS для хранения BLOB, но если для хранения BLOB решено использовать LUN в режиме thin provisioning, то необходимо, чтобы для форматирования LUN в NTFS использовался Quick Format.

По умолчанию, System Manager 1.1 создает LUN-ы с использованием thick provisioning. При использовании System Manager для создания LUN, значение space-reserved для LUN необходимо изменить на –none (то есть thin provisioning) отдельным шагом.

По умолчанию, System Manager 1.1 создает все тома NAS с параметром autodelete, установленным в OFF и параметром autosize, установленным в OFF. Эти значения требуют изменения отдельным шагом установки.

По умолчанию, System Manager 1.1 создает все тома SAN с параметром autodelete, установленным в ON, и параметром autosize, установленным в ON. Эти значения требуют изменения отдельным шагом установки.

МониторингMS SharePointПо умолчанию уведомления по SNMP не сконфигурированы. Уведомления SNMP (events и messages) должны быть сконфигурированы как отдельный шаг в Operations Manager и других системах.

При использовании thin provisioning необходим правильно настроенный мониторинг, и эффективный план дальнейших действий. Установите уведомления и пороги срабатывания таким образом, чтобы у ответственных лиц было достаточно времени и информации отреагировать на заполнение хранилища.

Убедитесь, что SnapManager for SharePoint отсылает уведомления на все события мониторинга заданий. Например, если какое-то задание, относящееся к Archiver или Extender завершилось неудачей по причине нехватки места на сетевой папке CIFS, то SNMP должен послать по этому поводу уведомление администратору.

Внимание: Уведомления в SnapManager for SharePoint 2010 отличаются от таковых в SnapManager for SharePoint 6. Убедитесь, что пользуетесь для настройки и установки соответствующими документами и рекомендациями.

Будьте осторожны при мониторинге места, использованного LUN-ами для SQL Log. Если лог транзакций не обрезается (truncated) регулярно, то логи могут вырасти весьма большими, и потребуется значительное увеличение объема хранения для этих LUN-овs.

Рост хранилищавMS SharepointЕсли Archived Datastore исчерпает отведенное ему место, то закачка файлов на SharePoint будет завершаться неудачей. При этом генерируется следующее сообщение:

"The URL 'Shared Documents/test.doc' is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web."

50



Уже существующие файлы на ферме серверов SharePoint при этом остаются доступны для чтения.

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

NetApp также рекомендует настроить несколько сетевых папок CIFS для хранения BLOB storage device чтобы, если одна сетевая папка CIFS заполнится, то SnapManager for SharePoint смог бы перенести работу на следующую доступную сетевую папку без прерывания процесса загрузки документов.

CIFS Share: Если размер тома, содержащего на себе CIFS share увеличивается с помощью CLI или GUI, дополнительное пространство будет распознано автоматически.

Воспользуйтесь NetApp SnapDrive for Windows (SDW) для того, чтобы сделать растущее пространство доступным для LUN.

NTFS LUN: Если размер LUN увеличивается с помощью CLI или GUI, дополнительное пространство не будет распознано автоматически. Используйте для увеличения LUN SnapDrive for Windows (SDW). Использование SDW для увеличения LUN позволяет дополнительному месту сразу стать видимым и используемым для сервера.

Внимание: Microsoft рекомендует размонтировать LUN перед увеличением его объема. Для деталей смотрите статью KB http :// support . microsoft . com / kb /959613 .

Для работы volume autosizing, содержащий том aggregate должен иметь достаточно места (по меньшей мере в 1,2 раза больше размера тома).

, , Особые случаи требующие внимания прииспользовании Thin ProvisioningКогда потребление пространства хранения непредсказуемо, или может резко меняться, лучше всего снизить уровень перерасхода (overcommitment) с тем, чтобы хранилище оставалось доступным даже в моменты пиков потребления. Рассмотрите также вариант назначить уровень расхода пространства на хранилище равным 100%, что означает «без перерасхода», и используйте графики трендов для определения того, какие величины перерасхода вы можете безболезненно использовать, если он все же необходим.

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

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


SharePoint Server 2010 and SnapManager 6.0 for SharePoint Best Practices Guide:http://media.netapp.com/documents/tr-3887.pdf

51


http://support.microsoft.com/kb/959613

6 Thin Provisioning и Microsoft SQL ServerВ этом разделе мы рассмотрим особенности использования thin provisioning и MS Exchange Server. Цель документа показать, как следует оценивать и учитывать использование thin provisioning в решении. Раздел и его рекомендации выработаны в результате анализа пользовательских практик и внутреннего тестирования.

6.1 СпецификацииРекомендации этого главы были разработаны для следующих перечисленных версий приложений и версий OS.

Microsoft SQL Server 2008 R2 Single Instance Database OLTP Microsoft Server 2008 R2 x64 NetApp System Manager 1.1 NetApp SnapDrive for Windows 6.3 NetApp SnapManager for SQL 6.0 NetApp Data ONTAP 7.3.3


6.2 Рекомендацииинаилучшие практикиЭта глава посвящена наилучшим практикам и рекомендациям по использованию NetApp thin provisioning с MS SQL Server. Если вы впервые сталкиваетесь в работе с thin provisioning, NetApp настоятельно рекомендует связаться с техническими специалистами NetApp или его авторизованных партнеров. Таблица 14 показывает рекомендованные NetApp параметры для thin provisioning.

Конфигурирование Data ONTAP для работы сMS SQL ServerТаблица 14) Рекомендованные параметры Data ONTAP для томов и LUN.


volume grow area Yes

Volume optionsguarantee None


autosize On



Volume Snapshot optionsreserve Z%

autodelete Off


LUN Optionsspace reservation Disabled

* Величины данных параметров зависят от проектируемой системы и определяются на этапе сайзинга52

УстановкаMS SQL ServerThin provisioning рекомендуется для использования под файлы базы данных SQL Server.

Thick provisioning рекомендуется для всех других файлов и типов их:

System databases, такие как master, model, msdb, и tempdb User database logs

Используйте отдельные тома для каждой базы данных SQL, как это рекомендовано для процедур резервного копирования и восстановления SnapManager. Для подробностей смотрите документ TR-3768: SnapManager 5.0 for SQL Server: Best Practices Guide.

Если для хранения данных решено использовать LUN в режиме thin provisioning, то необходимо, чтобы для форматирования LUN в NTFS использовался Quick Format.

По умолчанию инструмент сайзинга в SnapManager for SQL подразумевает, что используется thick provisioning. Вы не должны использовать эти настройки по умолчанию, хотя это и обычная практика. Для подробностей смотрите Appendix C в документе SnapManager 2.1 for Microsoft SQL Server.

Для MS SQL Server, NetApp рекомендует использовать встроенную функциональность snapshot autodelete в SnapManager for SQL, а не функцию autodelete в Data ONTAP.




Когда вы используете MS SQL Server с thin provisioning, функция Instant file initialization должна быть включена с использованием полномочий «perform volume maintenance task» локальной политики безопасности. Подробнее смотрите в статье Microsoft MS175935 по адресу http :// msdn . microsoft . com / en - us / library / ms 175935. aspx .

Как autodelete, так и autosize работают на уровне тома, а не отдельного LUN-а. Это означает, что LUN-ы не будут автоматически расти, это следует проделать вручную, соответствующей командой. Помните о следующих моментах:

Autosize может закончиться неудачно, если нет достаточно места на aggregate, за его состоянием следует наблюдать с помощью Operations Manager.

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

53

http://msdn.microsoft.com/en-us/library/ms175935.aspx

http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsmsql_21/html/software/admin/cfgappl9.htm



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

МониторингMS SQL ServerПо умолчанию уведомления по SNMP не сконфигурированы. Уведомления SNMP (events и messages) должны быть сконфигурированы как отдельный шаг в Operations Manager и других системах.


Растущий объем хранения вMS SQL ServerВоспользуйтесь NetApp SnapDrive for Windows (SDW) для того, чтобы сделать растущее пространство доступным для LUN.

CIFS Share: Если размер тома, содержащего на себе CIFS share увеличивается с помощью CLI или GUI, дополнительное пространство будет распознано автоматически.



Для работы volume autosizing, содержащий том aggregate должен иметь достаточно места (по меньшей мере, в 1,2 раза больше размера тома).

Рост хранилищавMS SQL ServerВоспользуйтесь NetApp SnapDrive for Windows (SDW) для того, чтобы сделать растущее пространство доступным для LUN.


Внимание: Microsoft рекомендует размонтировать LUN перед увеличением его объема. Подробнее смотрите статью MS KB http :// support . microsoft . com / kb /959613 .

Для работы volume autosizing, содержащий том aggregate должен иметь достаточно места (по меньшей мере, в 1,2 раза больше размера тома).

54



Space Reclamation и MS SQL ServerНеобходимо время от времени выполнять процесс space reclamation, чтобы возвращать системе неиспользованное пространство в LUN. Пространство может быть возвращено системе на уровне базы данных, использовав SQL Server Management studio -> Shrink database/files, и затем на уровне системы хранения, с помощью команды SnapDrive -> Start Space Reclaimer.

, , Особые случаи требующие внимания прииспользовании Thin ProvisioningКогда потребление пространства хранения непредсказуемо, или может резко меняться, лучше всего снизить запланированный уровень перерасхода (overcommitment) с тем, чтобы хранилище оставалось доступным даже в моменты пиков потребления. Рассмотрите также вариант назначить уровень расхода пространства на хранилище равным 100%, что означает «без перерасхода», и используйте графики трендов для определения того, какие величины перерасхода вы можете безболезненно использовать, если он все же необходим.




SnapManager 5.0 for SQL Server: Best Practices Guide:http://media.netapp.com/documents/tr-3768.pdf

Best Practice Guide for Microsoft SQL Server on NetApp Storage:http://media.netapp.com/documents/tr-3821.pdf

7 Thin Provisioning и MS ExchangeВ этом разделе мы рассмотрим особенности использования thin provisioning и MS Exchange Server. Цель документа показать, как следует оценивать и учитывать использование thin provisioning в решении. Раздел и его рекомендации выработаны в результате анализа пользовательских практик и внутреннего тестирования.

7.1 СпецификацииРекомендации этого главы были разработаны для следующих перечисленных версий приложений и версий OS.

Exchange Server 2010 Microsoft Server 2008 R2 x64 NetApp System Manager 1.1 NetApp SnapDrive for Windows 6.3 NetApp SnapManager for Exchange 6.0

55



NetApp Data ONTAP 7.3.3


Миграцияна Exchange Server 2010В ходе миграции на MS Exchange 2010 возможно получить значительную миграцию места. Размер майлбокса по умолчанию в Exchange 2010 составляет 10GB, что значительно больше 2GB на более ранних версиях. Майлбоксы большого размера при своем создании для большой организации вызывают быстрый рост заполнения дискового хранилища.

Для значительного сокращения объемов занимаемого создаваемыми майлбоксами места на дисках удобно использовать thin provisioning, когда место на дисках будет заниматься только тогда, когда в майлбоксы будут записываться поступающие email. Это устраняет ситуацию с заполнением хранилища при создании множества пустых майлбоксов, и повышает общую эффективность решения хранилища. Рисунок 18 демонстрирует принципы thin provisioning и thick provisioning для решения Exchange 2010.

Рис. 18) Сравнение thin и thick provisioning для Exchange 2010 со 100 майлбоксами

Database Availability Group (DAG)Для замены data resiliency options в старых версиях Exchange, Microsoft разработала новое решение, под названием Database Availability Group (DAG) feature. DAG cсостоит из 2 или более серверов майлбоксов; однако таких серверов не может быть больше 16 в одной DAG. Каждый сервер майлбоксов держит на себе одну или более активную или пассивную копию базы данных. Каждая из этих баз имеет статус активной или пассивной, так что один сервер может нести на себе копии нескольких баз, но только некоторые из этих баз будут находиться в активном статусе.

56

Рисунок 19 показывает пример решения с несколькими DAG. Вы видите на рисунке три сервера и три копии базы данных, по одной на каждый сервер. Активная копия базы данных для каждого из серверов выделена синим.

Пассивные копии каждой из баз непрерывно обновляются путем «накатывания» на них логов (log shipping). Использование thin provisioning для хранения баз Exchange помогает снизить объемы использования хранилища с нескольких сайтов репликации, убрав предварительное занятие дисковых блоков на этапе создания дискового ресурса.

Рис. 19) Использование thin provisioning для Exchange 2010 DAG.

7.2 Рекомендацииинаилучшие практикиЭта глава посвящена наилучшим практикам и рекомендациям по использованию NetApp thin provisioning с Exchange. Если вы впервые сталкиваетесь в работе с thin provisioning, NetApp настоятельно рекомендует связаться с техническими специалистами NetApp или его авторизованных партнеров. Таблица 15 показывает рекомендованные NetApp параметры для thin provisioning.

Конфигурирование Data ONTAP для работы с ExchangeТаблица 15) Рекомендованные параметры Data ONTAP для томов и LUN.


volume grow area Yes

Volume optionsguarantee None


autosize On


* Величины данных параметров зависят от проектируемой системы и определяются на этапе 57



autodelete Off


LUN Optionsspace reservation Disabled

УстановкаMS Exchange 2010Использование thin provisioning рекомендуется как для логов Exchange, так и для томов базы данных Exchange.

Дедупликация NetApp обычно дает экономию пространства для Exchange 2010 в районе 10 - 30% объема.

Дедупликация может быть эффективным способом вернуть в доступность пространство, занятое данными базы Exchange, в том числе и с использованием thin provisioning. Подробнее смотрите документ Storage Efficiency and Best Practices for Microsoft Exchange Server 2010.

По умолчанию инструмент сайзинга в SnapManager for Exchange подразумевает, что используется thick provisioning. Вы не должны использовать эти настройки по умолчанию, хотя это и обычная практика.

Для MS Exchange NetApp рекомендует использовать встроенную функциональность snapshot autodelete в SnapManager for Exchange, а не функцию autodelete в Data ONTAP.

Мониторинг ExchangeПо умолчанию уведомления по SNMP не сконфигурированы. Уведомления SNMP (events и messages) должны быть сконфигурированы как отдельный шаг в Operations Manager и других системах.


Растущий объем хранения в ExchangeВоспользуйтесь NetApp SnapDrive for Windows (SDW) для того, чтобы сделать растущее пространство доступным для LUN.



сайзинга58


Space Reclamation и ExchangeНеобходимо время от времени выполнять процесс space reclamation, чтобы возвращать системе неиспользованное пространство в LUN. Пространство может быть возвращено системе на уровне системы хранения с помощью команды SnapDrive -> Start Space Reclaimer.

, , Особые случаи требующие внимания прииспользовании Thin ProvisioningКогда потребление пространства хранения непредсказуемо, или может резко меняться, лучше всего снизить уровень запланированного перерасхода (overcommitment) с тем, чтобы хранилище оставалось доступным даже в моменты пиков потребления. Рассмотрите также вариант назначить уровень расхода пространства на хранилище равным 100%, что означает «без перерасхода», и используйте графики трендов для определения того, какие величины перерасхода вы можете безболезненно использовать, если он все же необходим.




Thin Provisioning in a NetApp SAN or IP SAN Enterprise Environment:http://media.netapp.com/documents/tr-3483.pdf

Storage Efficiency and Best Practices for Microsoft Exchange Server 2010:http://media.netapp.com/documents/tr-3824.pdf

Maximize Storage Efficiency with NetApp Thin Provisioning and Symantec Thin Reclamation:http://media.netapp.com/documents/wp-7111.pdf

SnapDrive 6.2 for Windows Best Practices:http://media.netapp.com/documents/tr-3828.pdf

8 Thin Provisioning и Oracle DBВ этом разделе мы рассмотрим особенности использования thin provisioning и Oracle. Цель документа показать, как следует оценивать и учитывать использование thin provisioning в решении. Раздел и его рекомендации выработаны в результате анализа пользовательских практик и внутреннего тестирования.

8.1 СпецификацииПриведенные рекомендации были разработаны для следующих версий приложений и OS.

Oracle Single Instance Database

59





OLTP 11g NetApp System Manager 1.1 NetApp SnapDrive for Windows 6.3 NetApp SnapManager for Oracle 6.0 NetApp Data ONTAP 7.3.3

Если вы используете иные версии или конфигурации, то рекомендации могут потребовать корректировки.

8.2 Рекомендацииинаилучшие практикиЭта глава посвящена наилучшим практикам и рекомендациям по использованию NetApp thin provisioning с Oracle. Если вы впервые сталкиваетесь в работе с thin provisioning, NetApp настоятельно рекомендует связаться с техническими специалистами NetApp или его авторизованных партнеров. Таблица 16 показывает рекомендованные NetApp параметры для thin provisioning.

Конфигурирование Data ONTAP для работы с OracleТаблица 16) Рекомендованные параметры Data ONTAP для томов и LUN.


volume grow area yes

Volume optionsguarantee none


autosize on




autodelete off


LUN Optionsspace reservation disabled

Использование с ORACLEThin provisioning рекомендован для использования на разделе под файлы данных Oracle (типы файлов .dbf).

Thick provisioning рекомендован для разделов под все другие типы файлов (не файлов данных).

Файлы Log: Oracle записывает все транзакции в форме redo, и сбрасывает их время от времени на диски в виде журналов redo logs. Эти журналы крайне важны для базы данных, и должны быть доступны без малейшей задержки.

Oracle Automatic Storage Management (ASM) обеспечивает отличное взаимодействие с технологией thin provisioning на уровне хранения. Он создает заголовок (ASM header) на каждом

* Величины данных параметров зависят от проектируемой системы и определяются на этапе сайзинга

60

из используемых в группе ASM LUN-ов. Однако предварительная инициализация LUN-а не выполняется до фактической записи данных в них.

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

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

Oracle требует, чтобы вы явно установили опцию autoextend в значение ON, при создании табличных пространств (tablespaces), размещенных на thin-томах.

В случае использования overprovisioning, обратите внимание на следующее:

Когда пространство на томе thin provisioning занято, то другие тома, воспользовавшиеся возможностью overprovisioning на том же aggregate будут видеть только оставшееся нераспределенным место, доступное на aggregate. Это важно при использовании NFS, так как приложения будут видеть гораздо меньше места, чем им выделено, так как пространство было занято другими томами.




По умолчанию, System Manager 1.1 использует величину Snapshot reserve, равную 20% для всех томов NAS. Значение Snapshot reserve может быть изменено при желании, при условии следованию наилучшим практикам и рекомендациям. Для дополнительных сведений смотрите документ: TR -3633: NetApp Best Practice Guidelines for Oracle Database 11 g .‖

Как autodelete, так и autosize работают на уровне тома, а не отдельного LUN-а. Это означает, что LUN-ы не будут автоматически расти, это следует проделать вручную, соответствующей командой. Помните о следующих моментах:

Autosize может закончиться неудачно, если нет достаточно места на aggregate, его состояние следует правильно наблюдать с помощью Operations Manager.

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

61


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

Мониторинг OracleПо умолчанию уведомления по SNMP не сконфигурированы. Уведомления SNMP (events и messages) должны быть сконфигурированы как отдельный шаг в Operations Manager и других системах.


, , Особые случаи требующие внимания прииспользовании Thin ProvisioningКогда потребление пространства хранения непредсказуемо, или может резко меняться, лучше всего снизить уровень запланированного перерасхода (overcommitment) с тем, чтобы хранилище оставалось доступным даже в моменты пиков потребления. Рассмотрите также вариант назначить уровень расхода пространства на хранилище равным 100%, что означает «без перерасхода», и используйте графики трендов для определения того, какие величины перерасхода вы можете безболезненно использовать, если он все же необходим.



СправочныематериалыДля подробностей по теме смотрите документы:

TR -3633: NetApp Best Practice Guidelines for Oracle Database 11 g Свяжитесь с вашим контактом в NetApp или партнере компании для получения этого документа, если он недоступен.

SnapManager 3.0 for Oracle Best Practices

62


9 Thin Provisioning и другие возможности NetAppЭтот раздел рассматривает некоторые особенности использования thin provisioning совместно с другими возможностями систем хранения NetApp.

9.1 Thin Provisioning и средства администрирования и мониторинга Если вы планируете использовать на системе хранения thin provisioning, абсолютно необходимо, чтобы состояние свободного места на ней постоянно наблюдалось. Это необходимо для того, чтобы дополнительное место на хранилище своевременно добавлялось для удовлетворения растущих потребностей приложения.

Таблица 17 показывает, какие инструменты могут быть использованы для распределения пространства хранения. Некоторые из перечисленных инструментов не являются инструментами «полного цикла», но мы включили их в список, так как они могут использоваться для некоторых операций.

Таблица 17) Функциональность распределения пространства в инструментах NetApp.O

NTAP CLI

FilerView

System

Manager

SnapDrive

for W

indows

SnapDrive

for U

NIX

Provisioning M

anager

Конфигурирование Data ONTAP

Создание aggregate

Создание тома

Конфигурирование тома

Создание Qtree

Создание LUN

Конфигурирование LUN

Маппинг LUN

Таблица 18 показывает, как каждый из инструментов воздействует на текущие значения, если используется для распределения пространства. Важно отметить, что отметка (x) показывает, что соответствующие настройки, при использовании данного инструмента, будут сброшены в значение по умолчанию. Хорошим правилом будет проверить итоговые значения опций после окончания операции по распределению пространства хранения с использованием данных инструментов.

63

Таблица 18) Ключевые параметры и инструменты NetApp для их изменения.

(X) – означает, что текущее значение будет изменено в соответствующем инструменте на значение по умолчанию.

ON

TAP CLI

FilerView

System

Manager

SnapDrive

for Window

s

SnapDrive

for UN

IX

Provisioning M

anager

System autodelete thresholds X XVolume guarantee X X X (X)

Volume fractional_reserve X X (X)Volume autosize X X (X)

Volume autosize options X (X)Volume try_first X (X) (X)

Snapshot reserve X X (X) (X)Snapshot autodelete X (X) X

Snapshot autodelete options X (X)LUN space reservation X X X X X X

9.2 Thin Provisioning и дедупликация Дедупликация работает независимо и прозрачно с thin provisioning как для LUN-ов, так и для томов/файлов.

Эффект экономии пространства при дедупликации дает больше места для LUN, тома или aggregate, в зависимости от того, как она сконфигурирована.

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

Для подробностей смотрите документ TR-3505: NetApp Deduplication Deployment and Implementation Guide.

9.3 Thin Provisioning и тома FlexCloneФайлы, созданные с помощью FlexClone получаются файлами/LUN-ами без резервирования вне зависимости от того, какой тип резервирования был у оригинальных экземпляров. Для включения space reservation для клонов, если это необходимо, используйте отдельное указание опции резервирования для файла уже после создания клона.

FlexClone LUN-ы наследуют настройки space guarantee своего источника. Если на томе, где происходит процесс создания клона, не хватает места для создания клона с такими же как у исходного LUN настройками reservation, то процесс клонирования завершается с ошибкой.

Отметьте, что исходный LUN и его клон будут совместно использовать одни и те же блоки диска даже в случае, если включена space guarantee.

При создании клона Data ONTAP создает метаданные для нового экземпляра данных. При этом данные изменений клонированной копии, или новые данные, записываемые в нее, по мере поступления этих данных размещаются на дополнительном пространстве блоков. По этой причине, уровень перерасхода (overcommitment) на aggregate, который содержит клонированные

65

данные, растет при создании клона. Однако это не влияет на уже занятое пространство на aggregate. Но когда данные на клоне изменяются, или когда новые данные записываются в клон, уровень использования aggregate растет.

9.4 Thin Provisioning и системы V-SeriesThin provisioning поддерживается системами хранения V-Series.

9.5 Thin Provisioning и репликация SnapMirror

Рекомендацииинаилучшие практикиПриведенные рекомендации должны использоваться при использовании thin provisioning в конфигурации систем для построения disaster recovery (DR) решений, когда сайт-получатель репликации данных должен корректно обрабатывать ситуацию с автоматическим изменением размера томов на сайте-источнике данных.

Если тома данных зеркалируются с помощью SnapMirror и исходный том растет в размерах, то отношения в паре репликации SnapMirror (так называемый relationship) будут разорваны, если том-получатель окажется меньше в объеме, чем том-источник данных. Для предотвращения такой ситуации система-получатель DR должна иметь объем тома как минимум не меньше, чем размер тома-источника, в том числе с учетом его возможного роста при autosize или в результате ручного изменения размера:

Рассмотрите возможность установить для тома-источника репликации значение space guarantee в -volume‖и включенный autosize.

На системе-получателе, на DR-сайте, создайте том-получатель на aggregate , который имеет такой же размер, как aggregate на сайте-источнике.

Установите величину guarantee на DR-сайте на -none,‖и задайте размер для всех томов-получателей репликации меньше, чем общий размер aggregate (то есть, например, если ваш aggregate имеет размер 10TB, создайте размер всех томов-получателей на нем с объемом 9.9TB). Общий суммарный объем томов может быть больше, чем объем содержащего их aggregate.

НЕ ВЫКЛЮЧАЙТЕ (off) параметр FS_SIZE_FIXED на системе-получателе.

Теперь тома-получатели DR-сайта используют thin provisioning, с максимальным объемом равным объему aggregate, на котором они расположены, или, более точно, очень близко к этому объему, но меньше его. Это позволяет использовать автоматическое увеличение исходного тома с помощью autosize, в том время, как его объем будет ограничен и не превысит максимального объема тома-получателя репликации.

Помните, что, начиная с версии Data ONTAP 7.3, когда происходит событие DR и переключение сайтов, и связь пары репликации SnapMirror разрывается, том-получатель репликации сохраняет свои установки и характеристики, и не наследует характеристики тома-источника (то есть после файловера он будет иметь space guarantee = none). Таким образом, если система-получатель (DR) после файловера будет использоваться как основная продолжительное время, желательно будет изменить настройки тома на значения с исходной системы (то есть, изменить значение space guarantee на этой новой рабочей системе хранения с -none‖на -volume, в рассмотренном примере). В версии Data ONTAP 7.2, разрыв репликации SnapMirror приводит к

66

тому, что том-получатель автоматически наследует значение volume guarantee с исходного тома, что должно соответствующим образом учитываться при планировании емкости.

Позднее, когда оригинальная основная система хранения вернется в работу, настройки томов обеих систем должны быть внимательно просмотрены и проанализирована их корректность для работы в качестве основной и DR-системы. Например, в рассмотренном варианте, определим, что том-источник репликации на основной системе должен иметь значение space guarantee

установленное в –volume, а система-получатель на DR-сайте – иметь space guarantee

установленное в -none, как это было сконфигурировано изначально. Эти значения должны быть внимательно проанализированы и установлены вне зависимости от того, будет ли вернувшаяся в строй система использоваться как рабочая, или резервная система после DR-события возьмет на себя роль основной.

Если не планируется осуществлять resync между DR primary (исходным сайтом) и DR destination (удаленным сайтом-получателем данных) и желательно использование volume autosizing, то установите FS_SIZE_FIXED в значение off.

Для деталей смотрите документ TR-3446: SnapMirror Async Overview and Best Practices Guide. Если вы используете synchronous или semi-synchronous режим работы SnapMirror, смотрите документ TR-3326: SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerations.

9.6 Thin Provisioning и SnapVaultНа момент написания данного руководства, рекомендацией для SnapVault secondary является установка space guarantees для тома в значение -volume.‖

9.7 Thin Provisioning и Multistore (vFiler)MultiStore очень удобно применять в процедурах снижения рисков переполнения хранилища при использовании на системе хранения thin provisioning.

Начиная с версии Data ONTAP 7.3.3, DataMotion for vFiler доступен на всех FAS и V-Series, и обеспечивает возможности онлайн-миграции.

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

Рекомендацииинаилучшие практикиИспользование MultiStore vFiler не является необходимым для томов, которые не планируется мигрировать, но для томов, которые планируется мигрировать с сохранением к ним доступа (в онлайне), следует использовать помещение их в структуру vFiler.

9.8 Thin Provisioning и Datamotion for LUNsНачиная с версии Data ONTAP 8.1 7-Mode доступна функциональность DataMotion for LUNs, и она может быть использована для устранения рисков переполнения хранилища и сохранения доступности данных.

67

10 Поиск и устранение неполадокЭтот раздел содержит некоторые начальные сведения о том, как обнаружить и устранить источники проблем для некоторых ситуаций.

10.1 Нет заметной экономиипространстваНаилучший инструмент для просмотра величины экономии пространства на системе хранения при использовании thin provisioning, это My AutoSupport™ и Operations Manager Storage Efficiency Dashboard.

10.2 Нет уведомленийПроверьте, что уведомления верно сконфигурированы в Operations Manager. Помните, что вы можете установить срабатывание уведомлений одновременно на уровне по умолчанию, и для каждого aggregate отдельно. Также убедитесь, что вы ввели в Operations Manager правильный e-mail, номер пейджера, и имя хоста для SNMP trap. Если используется e-mail alias, убедитесь, что он не был изменен. Если вы используете SNMP trap , попробуйте использовать для его хоста адрес IP, если имя в адрес разрешается неправильно.

10.3 Замедление производительностиНет сколь-нибудь заметного снижения производительности при использовании NetApp thin provisioning. Если вы наблюдаете замедление операций, попробуйте изолировать проблему. Если вам требуется техническая помощь, свяжитесь с NetApp Technical Support. Контактная информация приведена в конце данного документа.

11 Дополнительная и справочная литератураOperations Manager Administration Guidehttp://now.netapp.com/NOW/knowledge/docs/DFM_win/rel40/html/software/opsmgr/frameset.html

Operations Manager Efficiency Dashboard Installation and User Guidehttp://now.netapp.com/NOW/download/tools/omsed_plugin/InstallUserGuide.pdf

Performance Study of VMware vStorage Thin Provisioninghttp://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf

RA-0007: Storage Efficiency Every Day: How to Achieve and Manage Best-in-Class Storage Usehttp://media.netapp.com/documents/RA-0007.pdf

SnapManager 2.1 for Microsoft SQL Serverhttp://now.netapp.com/NOW/knowledge/docs/SnapManager/relsmsql_21/html/software/admin/cfgappl9.htm

TR-3263: WORM Storage on Magnetic Disks Using SnapLock Compliance and SnapLock Enterprise http://media.netapp.com/documents/tr-3263.pdf

TR-3326: SnapMirror Sync and SnapMirror Semi-Sync Overview and Design Considerationshttp://media.netapp.com/documents/tr-3326.pdf

68





http://media.netapp.com/documents/RA-0007.pdf

http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf

http://now.netapp.com/NOW/download/tools/omsed_plugin/InstallUserGuide.pdf

http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel40/html/software/opsmgr/frameset.html

TR-3428: NetApp and VMware Virtual Infrastructure 3 Storage Best Practiceshttp://media.netapp.com/documents/tr-3428.pdf

TR-3440: Operations Manager, Protection Manager, and Provisioning Manager Sizing Guidehttp://media.netapp.com/documents/tr-3440.pdf

TR-3446: SnapMirror Async Best Practices Guidehttp://media.netapp.com/documents/tr-3446.pdf

TR-3450: Active-Active Controller Configuration Overview and Best Practice Guidelines http://media.netapp.com/documents/tr-3450.pdf

TR-3466: Open Systems SnapVault Best Practice Guidehttp://media.netapp.com/documents/tr-3466.pdf

TR-3483: Thin Provisioning in a NetApp SAN or IP SAN Enterprise Environment http://media.netapp.com/documents/tr-3483.pdf

TR-3487: SnapVault Best Practice Guide http://media.netapp.com/documents/tr-3487.pdf

TR-3548: MetroCluster Design and Implementationhttp://media.netapp.com/documents/tr-3548.pdf

TR-3563: NetApp Thin Provisioning Increases Storage Utilization with on-Demand Allocationhttp://media.netapp.com/documents/tr-3563.pdf

TR-3584: Microsoft Exchange 2007 Disaster Recovery Model Using NetApp Solutionshttp://media.netapp.com/documents/tr-3584.pdf

TR-3608: Data ONTAP SNMP Trap Managementhttp://media.netapp.com/documents/tr-3608.pdf

TR-3651: Microsoft Exchange 2007 SP1 Continuous Replication Best Practices Guidehttp://media.netapp.com/documents/tr-3651.pdf

TR-3694: NetApp and Citrix XenServer 4.1: Building a Virtual Infrastructure from Server to Storagehttp://media.netapp.com/documents/tr-3694.pdf

TR-3702: NetApp Storage Best Practices for Microsoft Virtualizationhttp://media.netapp.com/documents/tr-3702.pdf

TR-3705: NetApp and VMware VDI Best Practiceshttp://media.netapp.com/documents/tr-3705.pdf

TR-3712: Oracle VM and NetApp Storage Best Practices Guidehttp://media.netapp.com/documents/tr-3712.pdf

TR-3729: Simplified SAN Provisioning and Improved Space Utilization Using NetApp Provisioning Managerhttp://www.netapp.com/us/library/technical-reports/tr-3729.html

69

http://www.netapp.com/us/library/technical-reports/tr-3729.html

















TR-3742: Using FlexClone to Clone Files and LUNs http://media.netapp.com/documents/tr-3742.pdf

TR-3747: Best Practices for File System Alignment in Virtual Environmentshttp://media.netapp.com/documents/tr-3747.pdf

TR-3749: NetApp and VMware vSphere Storage Best Practiceshttp://media.netapp.com/documents/tr-3749.pdf

TR-3770: 2,000-Seat VMware View on NetApp Deployment Guide Using NFS: Cisco Nexus Infrastructurehttp://media.netapp.com/documents/tr-3770.pdf

TR-3814: DataMotion Best Practiceshttp://media.netapp.com/documents/tr-3814.pdf

TR-3824: Storage Efficiency and Best Practices for Microsoft Exchange Server 2010http://media.netapp.com/documents/tr-3824.pdf

TR-3827: Storage Efficiency—If You Are Doing This, Then Your Storage Could Be Underutilizedhttp://www.netapp.com/us/library/technical-reports/tr-3827.html

TR-3828: SnapDrive 6.2 for Windows Best Practiceshttp://media.netapp.com/documents/tr-3828.pdf

TR-3873: NetApp DataMotion for Volumeshttp://www.netapp.com/us/library/technical-reports/tr-3873.html

TR-3881: DataMotion for Volumes for Enterprise Applicationshttp://media.netapp.com/documents/tr-3881.pdf

TR-3886: Understanding and Using vStorage APIs for Array Integration with NetApp Storagehttp://media.netapp.com/documents/tr-3886.pdf

WP-7053: The 50% Virtualization Guarantee* Program Technical Guidehttp://media.netapp.com/documents/wp-7053.pdf

WP-7111: Maximize Storage Efficiency with NetApp Thin Provisioning and Symantec Thin Reclamationhttp://media.netapp.com/documents/wp-7111.pdf

12 Где искать дополнительнуюпомощьДля дополнительных источников информации и помощи, свяжитесь с:

Ваш аккаунт-менеджер в компании-партнере NetApp Системный инженер представительства NetApp Global Services NetApp Support (бывший NOW, NetApp on the Web) 888.4.NETAPP (для США и Канады) 00.800.44.NETAPP (EMEA/Eвропа)

70

https://now.netapp.com/eservice/SupportHome.jsp

http://www.netapp.com/us/support/ngs-contacts.html














13 Версии документаВерсия 1 Сентябрь 2011 Исходная версия документа

71