Posts tagged ‘netapp’

Аггрегация и балансировка на нескольких eth

А вот вы знаете, что у нас тут есть русскоязычный форум, с участием же русскоязычных специалистов, работающих в NetApp? Не знали? А он - есть :)
Это я к чему, к тому, что недавно там был обнаружен интересный топик, который будет полезен тем, кто пытается разобраться с непростой темой аггрегации etherchannel и балансировки по нескольким линкам.
https://communities.netapp.com/thread/32967

Если вы занимаетесь NetApp, и при этом еще не там - рекомендую зарегистрироваться (читать можно и так), и подписаться на rss. ??ногда там бывают полезные для жизни темы. Да и возможность спросить на русском тоже бывает порой неоценима.

Большое обновление в семействе E-series

Как вы знаете (должны знать, по крайней мере), NetApp, вот уже третий год пошел, как владеет бизнесом, ранее принадлежавшем компании LSI/Engenio, и производившим системы хранения “классической блочной архитектуры” для различных OEM-клиентов. Таким образом сегодня NetApp это не только традиционные для него стораджи семейства FAS, то есть unified, NAS+SAN, WAFL-based стораджи “со снепшотами и дедупликацией”, о которых в этом блоге в основном и пишется, но также и “традиционные для рынка” блочные стораджи для FC и iSCSI, которые продает как сам, так и поставляет по OEM-контрактам. Так, например, хорошо знакомые российскому IT системы IBM DS3524 и Dell PowerVault MD3 - это как раз они и есть, NetApp E-series.

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

На самом деле те, кто с NetApp уже давно, они знают, что он, как компания, всегда действует в русле здорового прагматизма, без всякого “идеологического паладинства”, если есть направление, в котором можно заработать деньги - действует простое правило: пойди, дай то, что пользователь хочет, и возьми у пользователя за это его деньги, без всяких “фу, это же не настоящий Fibrechannel!” :). Так, в свое время, NetApp вдруг, неожиданно для всех, перестал заниматься только лишь NAS, и быстро сделал поддержку блочных протоколов SAN в своих системах хранения (оставаясь, впрочем, сторонником своей линии, что NAS есть более интеллектуальный и прогрессивный продукт, сегодня мы все видим, что так оно, во многом, и получилось, смотрите как развивается NAS-направление в виртуализации!).

Точно также получилось и с E-series. На рынке существует ниша, в которой многочисленные интеллектуальные преимущества FAS и Data ONTAP не слишком нужны, а нужна там высокая удельная емкость хранения, высокая линейная скорость записи-чтения, возможность DAS-подключения к серверам, поддержка только блочных протоколов, и так далее. Это, например, системы хранения потокового HD-видео от камер видеонаблюдения, это системы для обработки BigData, например под Apache Hadoop, и ряд других таких же нишевых, но очень деньгоемких систем и областей использования. Ну, вот, отчего не расширить туда присутствие на рынке?

Сперва стораджи E-series продавались только в OEM, потом понемногу NetApp начал производить их и продавать от своего имени, сперва в Америке, а теперь и “в канал”, в том числе и в России.

?? вот, на днях, в семействе E-series вышло большое обновление.
Во-первых, появилась новая линейка в нижнем сегменте, той, чем был тот самый IBM DS3524, он же NetApp E2600. Теперь ему на смену появился E2700.

В линейке будет выпущено три модели, это E2712, E2724 и E2760. Последние две цифры модели, как вы уже поняли, это число дисков в конструктиве. 2712 и 2724 это уже знакомые 2U на 12 и 24 диска 2,5″, а вот 2760 это новый для модели E2 конструктив, уже встречавшийся в семействе E5, это 4U с треями “магазинного” типа, на 60 дисков 3,5″ в корпусе, для “сверхплотных” применений.

Контроллеры E2700 оснащаются в базе портами SAS 12Gb/s, и поддерживают расширение с помощью Host Interface Cards (HIC) с портами FC 16G, iSCSI 10G, а также дополнительными портами SAS 12G.

Будут поддерживаться разные типы дисков: SAS, NL-SAS, а также SSD (кроме 2712). Впрочем, про SSD дальше еще пойдет речь в связи с обновлением All-Flash системы EF5.

В остальном - это наследник E2600, все, знакомое вам по этой модели, в новой осталось.

Обновился контроллер у E5500.

E5500 - это системы еще большей производительности, чем были E2600. Теперь в нем добавились (ранее недоступные) интерфейсы FC 16Gb и iSCSI 10G (ранее были только SAS 12Gb, FC 8Gb и Infiniband). Также как у E2700 будут доступны три конструктива, на 12 и 24 диска в 2U, и на 60 дисков в 4U.
Поддерживаемые диски - SAS и SSD.

Наконец, обновился All-Flash storage, который теперь носит название EF550.

Эта система поставляется в виде 2U корпуса, с вариантами поставки на 12 дисков SSD (9,6TB raw) и на 24 диска SS (19,2TB raw), с общей возможной емкостью системы - 120 дисков.

Поддерживаются интерфейсы:
• 16Gb FC (OM2, OM3, OS1, and OS2 optical)
• 10Gb iSCSI (optical, twinax passive, and RJ-45 Cat 6)
• 6Gb SAS (copper with Mini-SAS cables)
• 40Gb IB (QSFP+ copper and OM3 optical)

Системы поставляются с 800GB SSD дисками технологии SLC, каждый диск оснащен двумя портами ввода-вывода SAS, и имеют пятилетнюю гарантию производителя.
The EF550 ships with 800GB mixed-use multi-level cell (MLC) NAND SSDs from SanDisk with dual (2) full-duplex interface ports. The EF550 actually leverages the dual-active paths from each controller to every SSD as part of its design.
Each SSD is rated at 10 drive writes per day (DWPD), warrantied up to 5 years, but with an endurance lifetime well over 5 years.

VSC 5.0 goes public beta

??так, долгожданный Virtual Storage Console, основной продукт для интеграции стораджа NetApp и виртуальной инфраструктуры vSphere, добрался до public beta.
Напомню, что VSC 5.0 будет первой версией, с интеграцией в vCenter web client. Вы знаете, что в планах VMware вскоре отказаться полностью от старого, классического “толстого” клиента, и перейти на web-client полностью, уже сейчас все новые фичи добавляются уже только через web-client.
Однако главная проблема тут - в плагинах к vCenter console, например VSC существует пока только для “толстого клиента”. Вот для того, чтобы это исправить, производится переход на новую платформу плагинов, ну и за компанию много всего перетрясено.
Новый VSC радикальным образом переделан и обновлен. Теперь нет отдельного таба для плагинов в клиенте, функции его будут интегрированы непосредственно в дерево inventory. Например для бэкапа датастора нужно будет щелкнуть правой клавишей непосредственно по нужному датастору в инвентори и выбрать нужное действие в контекстном меню.

??з основных особенностей текущей беты:

  • VSC требует vSphere 5.5 (но работающие под vSphere 5.5 ESXi 5.х и даже 4.х - поддерживаются)
  • ??меет только х64 инсталляцию
  • Не поддерживает апгрейд со старой версии VSC (например с действующей 4.2.1)

Специально, отдельной строкой отмечу, что public beta это все же еще не то, что можно ставить на продакшн, по крайней мере как единственный инструмент управления. Но посмотреть уже можно.

Почему Nutanix и NetApp, на мой взгляд, не конкуренты.

В этом году на IT-рынке EMEA появился новый, интересный, и крайне зубастый игрок - Nutanix. В двух словах, это вычислительная кластерная платформа, позволяющая строить фермы виртуальных машин без использования SAN-хранилищ, это “сервер-и-сторадж”, интегрированный специальной IT-магией в единый “кирпичик”, из множества которых можно строить кластеры VM, легко масштабируемые.
Так уж получилось, что активное продвижение Nutanix на российском рынке постоянно сталкивает его с системами NetApp, и кастомеры довольно часто задают такой вопрос “А если слон на кита залезет, то кто кого сборет?” “Победит ли Nutanix NetApp, или наоборот?”

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

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

1. Nutanix - это решение для виртуализованных сред. Область применения NetApp гораздо шире. Nutanix - передовая платформа крутить гипервизор виртуализации, это, если угодно, server-oriented система. Это сервер, с некоторыми функциями хранилища, интегрированными в него. NetApp - это, наоборот, “хранилище-ориентированная” система, это сторадж, в который интегрированы некоторые функции сервера (NAS, репликация). Эти две системы идут “навстречу”, и вот, на каком-то нейтральном для них обоих поле, они встретились и пересеклись.
На этом (и только на нем) можно говорить о конкуренции.

2. Передовые технические решения это здорово. Но иногда хочется оставаться в рамках классических архитектур. Например, когда переход на новую архитектуру несет с собой существенные риски и затраты на полную переделку уже существующей, работающей и приносящей деньги системы. Которую обслуживают люди, с определенным уровнем квалификации, в которую вложены деньги через их обучение. Которая обвязана разнообразными работающими “3rd party” продуктами, такими как инструменты мониторинга, алертинга, оптимизации, аналитики. ?? которые просто с точки зрения защиты инвестиций нельзя просто взять и выкинуть (и купить новые).

3. Линейное масштабирование, о котором часто говорит Nutanix, работает только для определенного ряда задач. Это фермы веб-сервисов, это VDI-среды, это некоторые NoSQL и BigData приложения. Это там, где сама задача позволяет выполнять обработку своих данных параллельно. Это, однако, не работает для “классических” SQL-баз и ряда традиционных архитектур. А это, читай, биллинги, ERP, legacy-системы, и все такое прочее. Перенос с переписыванием таких приложений под масштабируемую архитектуру съест всю гипотетическую экономию и поэтому экономически бессмысленнен.
Если ваша задача не масштабируется и не параллелится на кластер нодов и мощность одного нода для нее недостаточна, то никаких способов увеличить производительность этой задачи, крутя ее на Nutanix, у вас нет. В наше время это не слишком частая ситуация, тем не менее это все еще встречается.

4. Существует ряд задач, связанных с чистым хранением (а не хранением ?? обработкой) больших объемов данных. Если вам нужно хранить массив данных в несколько сотен терабайт, причем в основном только хранить, то хранить его на вычислительных нодах, тем более таких недешевых и производительных, как старшие Nutanix (NX-6000) - это оверкилл.

5. NetApp, во многих случаях, выбирают ради его многочисленных сервисов хранения данных (FlexClone, SnapLock, компрессия и дедупликация данных), их защиты, интегрированных в приложения (SnapManager, SnapProtect, SnapCreator) и репликации (SnapMirror, Metrocluster). Nutanix пока такими возможностями не обладает.

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

Ну и остановимся пока.
Таким образом, как вы видите, Nutanix конкурирует не с NetApp как таковым. Он конкурирует, возможно, с NetApp/Cisco FlexPod. Но FlexPod - это совсем не весь NetApp, это лишь отдельный прикладной продукт для определенного рынка, использующий систему хранения NetApp как свой компонент.

Можно сказать даже более, в каком-то смысле ?? Nutanix, ?? NetApp местами даже играют вместе, в одной команде. Одной из ключевых тем push message у Nutanix есть тезис об устарелости и неэффективности SAN и использования LUN, шире - тупого “блочного доступа”, прежде всего для виртуализованных сред.
Но так ведь и NetApp продвигает эту идею ни больше, ни меньше как с 1993 года! Да, NetApp умеет SAN вместе с NAS c 2004 года, в рамках концепции Unified Storage, и умеет крайне неплохо, но тем не менее, с самого начала своего сотрудничества с VMware он всюду твердит, что SAN LUN это вынужденный метод для размещения датасторов виртуальных машин, что VMFS - костыль, красивый, сияющий, хайтек, но - костыль. Что NAS-концепция и NAS-протокол лучше чем что-либо подходит именно для такого применения (параллельного доступа к данным на дисках от разных его потребителей со стороны хоста). “Делаете облачный сторадж - выкиньте LUN-ы!” - пишет в своей колонке в Computerworld Джон Мартин, директор SNIA ANZ и главный специалист по технологиям в австралийском NetApp. ?? все это как нельзя лучше поддерживает и перекликается с тем, что говорит по этому поводу Nutanix.

NetApp Hardware Universe

У NetApp есть такой подсайт, который называется Hardware Universe. На нем собраны разнообразные материалы по аппаратной части систем, например матрицы совместимости контроллеров и плат расширения, и прочие такие же полезные штуки. К сожалению, для доступа туда нужен, как я понимаю, партнерский аккаунт. На этом сайте можно найти, например, PDF с таблицами характеристик контроллеров и их максимумов. Например, какого размера данный контроллер поддерживает том для дедупликации, сколько LUN-ов можно создать максимально, какая минимальная версия Data ONTAP для этого контроллера нужна, или какое его тепловыделение в BTU, и так далее.

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

Maximums for 8.2 7-Mode

Maximums for 8.2 Cluster-mode

Maximums for 7.86 SANtricity (E-series)

Как переделать NFS VMDK в RDM LUN

??нтересный способ был подсмотрен в соседском блоге.

В некоторых (нечастых) случаях возникает необходимость преобразовать уже существующий виртуальный диск, например файл VMDK, лежащий на NFS-шаре, в RDM LUN (RDM – raw device mapping, подключение физического LUN в VM непосредственно, как SCSI LUN-а). Есть некоторое ограниченное число случаев, когда трудно или нельзя обойтись без RDM.

Сделать это можно без необходимости копирования данных через хост и создания второй копии данных. NetApp может создать LUN с указанием файла на диске, из которого будет взято его содержимое. При этом со стороны хоста это будет самый настоящий физический SCSI LUN, и его можно будет подключить как самостоятельное физическое устройство, например с помощью установленного внутри VM OS инициатора, допустим MS Software iSCSI Initiator, как новый диск. Но при этом на стороне стораджа такой “LUN” будет просто небольшой ссылкой на данные соотвествующего vmdk, уже хранящегося на дисках.

Опция –f может указать при создании LUN файл, хранящий содержимое сотвествующего LUN-а.

lun create -f /vol/vol1/test02/test02_1-flat.vmdk -t windows_2008 /vol/vol1/lun1
создаст физически небольшой файл LUN  /vol/vol1/lun1 (тип LUN – windows_2008), указывающий на существующий .vmdk файл test02_1-flat.vmdk. В дальнейшем вы можете работать с таким “LUN”-ссылкой как с настоящим LUN-ом.

Обратите внимание, что в качестве vmdk указан именно *-flat.vmdk, большого размера.

Помните также, что после такого “преобразования” нельзя удалить этот *–flat.vmdk, так как именно в нем будет находиться физическое содержимое LUN.

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

Storage QoS в Clustered Data ONTAP 8.2

Как вы уже заметили, в NetApp вот уже пару лет как перевели “семерку”, Data ONTAP 7-mode, куда входят как “классическая” линейка 7.х.х, так и Data ONTAP 8.x 7-mode, в состояние stable, и новые фичи в них практически не появляются, а все усилия разработчиков направлены на развитие и разработку Cluster mode, или как она сейчас стала часто называться в документации Clustered Data ONTAP. Уже само появление “личного имени” свидетельствует о том, что это – окончательный продукт, в представлении NetApp (затянувшийся) переходный период подошел к концу. Это, безусловно, очень рискованный период в жизни компании (любой компании), так как Clustered Data ONTAP пока еще не стал массовым и все еще не “мэйнстрим” в представлениях клиентов. Однако, NetApp не теряет терпения, и новыми фичами, такими как SMB 3.0, NFS 4.1 и pNFS, и прочими полезными штуками, старается перетянуть пользователей на новую, прогрессивную платформу с большим будущим.

Одной из новинок Clustered ONTAP стал полноценный Storage QoS. В принципе, псевдо-QoS в нетапповских стораджах был и раньше, он назывался FlexShare, но говоря о нем NetApp всегда старался уточнить, что это, ну, “не совсем настоящий QoS”, как, допустим, кооперативная многозадачность ранних Windows и MacOS Classic была лишь “псевдо”-многозадачностью. Конечно, это лучше чем ничего, многие стораджи, других вендоров, и такой-то не имеют. Но все же не следует забывать, что FlexShare это просто способ отдать побольше приоритета в тиках системы тому, данные с которого мы считаем важными, за счет того, что мы заберем их у того тома, данные с которого мы считаем не такими важными.

Однако подлинный QoS это не просто перераспределение приоритетов системы, это возможность задать некоторую гарантированную “полосу” в ресурсах. В особенности это стало важно после того, как появилась Clustered Data ONTAP, в которой multi-tenancy, то есть “сожительство” нескольких разнородных задач в рамках одной системы и одного контроллера такой системы стала не экзотикой, а нормальной повседневной работой. Для такой работы несомненно нужен полноценный QoS в рамках системы в целом, гибко назначаемый по потребителям, которые могут мигрировать по контроллерам кластерной системы, а не просто смещенные приоритеты обслуживания для какого-то тома, привязанные к данному контроллеру.

?? вот, в 8.2 появился полноценный планировщик ввода-вывода, который позволяет назначать политики с лимитами на отдельный SVM, Storage Virtual Machine, как теперь, если вы помните, решено, для упрощения понимания, называть Vserver в Clustered ONTAP.

Вы можете задать на отдельный “виртуальный нетапп”, живущий в кластерной системе, и ресурсов в нем, его лимиты по IOPS или же по MB/s ввода-вывода (но не одновременно, отметьте это ограничение). Следуя модели “политик” (policy), ограничение задается для такой созданной политики, которая затем назначается для SVM (Vserver) в целом, или же на его отдельный том, LUN, или файлы в нем. На кластер контроллеров вы можете задать до 3500 политик, то есть решение подойдет даже для довольно больших по масштабам систем.

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

QoS не разделяет операции чтения или записи, соответственно нельзя отдельно ограничить поток ввода-вывода только на чтение или только на запись.

??спользовать QoS можно, например, для ограничения производительности ввода-вывода определенных приложений, к примеру сервер резервного копирования может, при начавшемся процессе резервного копирования, очень быстро “съесть” всю доступную полосу ввода-вывода контроллера, “задавив” трафиком при этом всех своих соседей по кластеру. Можно ограничить ресурсы SVM ряда подразделений, живущих в том же кластере, например задачи R&D, чтобы случайный эксперимент на их SVM не смог повлиять на доступность продакшн-систем в том же кластере. Наконец, можно обеспечивать гарантированную полосу или величину IOPS (SLA) для особо критичных задач в облачной структуре, либо наоборот, максимально доступные им ресурсы.

Storage QoS включена в Clustered Data ONTAP 8.2, и не требует лицензии, и работает на любой системе, поддерживающей cDOT 8.2.

Оффтопик: Глава из How to Castrate a Bull

Что-то мы с вами все про технику и про технику. Отвлечемся на сегодня. Несколько лет назад, еще в 2009 году, один из сооснователей компании NetApp – Дейв Хитц, о котором я тут несколько раз уже упоминал, написал книгу под несколько шокирующим названием “HOW TO CASTRATE A BULL: Unexpected Lessons on Risk, Growth, and Success in Business” – “Как кастрировать быка: Неожиданные уроки риска, роста и успеха в бизнесе”. Книга, как вы понимаете, рассказывает историю основания и развития компании NetApp, ну и на примере разнообразных набитых в процессе шишек рассматриваются какие-то “уроки жизни” в этом бизнесе. Название взялось вот откуда: Хитц после колледжа подрабатывал на ранчо с ковбоями (в Америке они существуют и по сей день), и вспоминает, что многие из простых жизненных уроков и историй оттуда хорошо подошли и к миру IT-бизнеса.

Эта книжка (на английском) у меня есть целиком, но я бы не хотел заниматься откровенным пиратством, поэтому не буду выкладывать ее в открытый доступ (и вас бы просил этого не делать), но если кто хочет почитать – пришлите мне весточку в комменты или на romx@mail.ru, я пришлю вам текст. Книжка на английском, но, в принципе, читается неплохо.

В книге есть несколько действительно поучительных историй, одна из них – про то, как они увольняли сооснователя компании, друга в человеческих взаимоотношениях, да вдобавок и принесшего им первые инвестиционные деньги, и вообще фактического лидера компании в первые ее годы, с поста главы компании, CEO. ??стория, увы, с которй очень часто сталкиваются многие стартапы, когда выясняется, что методы работы или взгляды на будущее у бывших друзей расходятся. В какой-то момент становится ясно, что без хирургического вмешательства не обойтись, как бы болезненно для всех присутствующих оно ни было.

Вот эту главу для вас на днях я и решил перевести.

Continue reading ‘Оффтопик: Глава из How to Castrate a Bull’ »

Новые Best Practices у NetApp

Я вам тут решил регулярно докладывать о тех переводах Best Practices, что я делаю для компании Netwell и их библиотеки техдокументации в помощь клиентам, разворачивающим и использующим системы хранения NetApp (со временем, быть может, мы и для других вендоров такое сможем, пока просто на большее рук не хватает).
Однако, к сожалению, у NetApp их пишет целая команда, а перевожу их - я один. Поэтому приходится из всего потока, который ежемесячно добавляется в библиотеку самого NetApp, выбирать самое ценное и нужное. Это не значит, что остальное бесполезное. Напротив, там бывают весьма интересные тексты и руководства. Вот я и подумал, что было бы неплохо делать такой дайджест по новым документам на английском языке, котрые пока не переводились, но, возможно, читающие по-английски вполне смогут для себя полезное из них почерпнуть.

В этом месяце я бы хотел обратить ваше внимание на следующие публикации:
Using Red Hat Client with NetApp Storage over NFS
This report helps you to get the best from your Linux® NFS clients when used in an environment that includes NetApp® storage.

Best Practice Guide for Microsoft SQL Server and SnapManager 7.0 for SQL Server with Data ONTAP Operating in 7-Mode
This document describes the best practices and offers insight into design considerations when deploying Microsoft SQL Server on NetApp storage systems running Data ONTAP® operating in 7-Mode, with the goal of achieving effective and efficient storage deployment planning and end-to-end data protection and retention planning. The scope of this guide is limited to technical design guidelines based on the design principles and preferred standards that NetApp recommends for storage infrastructure when deploying aforementioned versions of Microsoft SQL Server. The end-to-end implementation is out of scope of this report.

NetApp SnapManager 2.0 for Hyper-V on Clustered Data ONTAP 8.2
This technical report provides guidelines and best practices for integrated architecture and implementations of Microsoft Hyper-V with NetApp storage solutions. The NetApp technologies discussed in this technical report are important to achieving an integrated storage solution that is cost effective, operationally efficient, flexible, and environmentally friendly.

Microsoft Exchange 2013 and SnapManager for Exchange Best Practices Guide for Clustered Data ONTAP
Microsoft Exchange 2013 and SnapManager for Exchange Best Practices Guide for 7-Mode Data ONTAP
Many organizations have come to rely on Microsoft® Exchange Server to facilitate critical business e-mail communication processes, group scheduling, and calendaring on a 24/7 basis. System failures might result in unacceptable operational and financial losses. Due to the increasing importance of Microsoft Exchange Server, data protection, disaster recovery, and high availability are of increasing concern. Companies require quick recovery with little or no data loss. With Microsoft Exchange Server databases growing rapidly, it is increasingly difficult to complete time-consuming backup operations quickly.

Best Practice Guide for Microsoft SQL Server and SnapManager 7.0 for SQL Server with Clustered Data ONTAP
Today’s business applications are more data centric than in the past, requiring fast and reliable access to intelligent information structures that are often provided by a high-performance relational database system. Many organizations use Microsoft SQL Server as a back-end datastore for mission-critical business applications. The latest release, Microsoft SQL Server 2012, delivers performance, scalability, availability, and security. This best practice guide is intended for storage administrators and database administrators to help them successfully deploy Microsoft® SQL Server® 2012, 2008, and 2005 on NetApp® storage.
(примечание romx: Этот документ, скорее всего, будет переведен до Нового года)

Virtualizing Oracle RAC on Red Hat Enterprise Virtualization 3.1 and NetApp Clustered Data ONTAP
This solution guide provides guidelines and best practices for architecting, deploying, and managing Oracle RAC on NetApp clustered Data ONTAP® storage systems. Example scenarios, validation procedures, and implementation guidelines are described in detail. Best practices for implementation and operation are provided as needed.

SnapDrive 7.0 for Windows SMB 3.0: Best Practices and Deployment Guide
NetApp® SnapDrive® for Windows® (SDW) helps you to perform storage-provisioning tasks and manage data in Microsoft® Windows environments. You can run SnapDrive software on Windows® hosts in either a physical or a virtual environment. SnapDrive software integrates with Windows Volume Manager so that storage systems can serve as virtual storage devices for application data in Windows Server® 2008 R2 and Windows Server 2012. It can also be used to provision storage for Windows virtual machines hosted on ESX® hypervisors.

SnapDrive 7.0 for Windows for Clustered Data ONTAP 8.2 - Best Practices Guide for SAN Environments
SnapDrive 7.0 for Windows for Data ONTAP 8.2 Operating in 7-Mode: Best Practices Guide
This technical report provides best practices guidelines when implementing SnapDrive for Windows in clustered Data ONTAP 8.2 in SAN environments. For best practice guidelines in SMB, refer to TR-4218: SnapDrive 7.0 for Windows SMB 3.0 Best Practices and Deployment Guide.

Reallocation в Data ONTAP. Часть 3.

??так, в прошлом посте я мельком упомянул, что кроме volume reallocation у NetApp есть еще aggregate reallocation (ключ команды запуска reallocate –A). ?? вот с ним начинается некоторое непонимание. Дело в том, что, как я показывал на примере в постах ранее, одной из необходимых операций при расширении aggregate является проведение reallocation блоков тома, для более равномерного распределения их по дискам aggregate. При этом, хотя операция проводится над aggregate, но используется НЕ aggregate reallocate, а совсем вовсе даже volume reallocation!

?? вот это принципиальный момент, вызывающий путаницу. Почему оптимизируя aggregate, мы делаем это через volume reallocate, почему не aggregate reallocate, и что же тогда делает этот aggregate reallocation?

Data ONTAP выражается тут однозначно:

NOTE: -A is for aggregate (freespace) reallocation. Do NOT use -A after growing an aggregate if you wish to optimize the layout of existing data; instead use reallocate start -f /vol/ for each volume in the aggregate.

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

На aggregate у нас расположены, как правило, не один, а множество volume.

image

Volume reallocate выполняется для отдельного тома, НО НЕ для всех томов aggregate разом. Вы, в случае рассматриваемой процедуры изменения размеров aggregate и увеличения нижележащих в нем дисков, должны последовательно провести reallocation для всех томов на aggregate.

image

Как вы видите на рисунке выше, если мы сделали reallocate для тома А, и не делали для тома В, то мы получим что-то, похожее на рисунок выше. Один том – перераспределился на добавленные диски, а второй – нет. К тому же у нас неравномерно распределилость оставшееся свободное место, как вы помните, непрерывность кусков свободного пространства для хорошей работы механизма выделения экстентов очень важно. а представьте теперь, что на aggregate не два тома, а несколько десятков или даже сотен, как это бывает? ?? при этом reallocate кому-то сделали, а кому-то – нет?

image

Дальше, как вы видите, том В начал заплняться неравномерно по дискам, как мы уже рассмотрели выше в предыдущем посте, с потенциальным образованием “дисковых хотспотов”

Что же сделает aggregate reallocation (reallocate –A), если, к примеру, на части его томов будет проведен volume reallocation, а на части нет? Он, как и написано выше, оптимизирует свободное пространство на aggregate, при этом оставив часть томов в неоптимизированном состоянии.

image

Как вы видите на рисунке выше, свободное место на aggregate действительно “оптимизировалось”, с точки зрения aggregate, да. Поэтому в случае использования reallocate после расширения aggregate новыми томами, и более равномерного “растасовывания” блоков томов по новому пространству aggregate, сперва выполните volume reallocate для КАЖДОГО тома на aggregate, а вот потом уже начинайте, если это необходимо, использовать aggregate reallocate.

Таким образом, вы видите, что volume reallocate и aggregate reallocate это ДВА РАЗНЫХ вида реаллокации блоков. В первом случае реаллоцируются блоки, принадлежащие тому, указанному в качестве аргумента команды, а во втором, при запуске ее с ключом –А, реаллоцируется своеобразный “том, состоящий из свободных блоков” на aggregate, и упорядочивается свободное пространство, сжимаются “дыры” в нем, и пространство, незанятое данными, становится “более непрерывным”, но при этом сами тома, с блоками данных, в ходе этой операции не оптимизируются, и если они были неоптимально размещены по дискам, то так неоптимальными и останутся, несмотря на завершившийся процесс aggregate reallocation.