Archive for ноября 2011

Hybrid Aggregate

Некоторые новости с прошедшего в Риме NetApp Insight 2011, главного мирового мероприятия NetApp, на котором, обычно, представляются все новинки года. На этот раз я обратил внимание на объявленную любопытную технологию, которая появится в Data ONTAP 8.1.1, под названием Hybrid Aggregate.
Вот что это такое.

Как вы знаете, NetApp использует flash, прежде всего, в форме “расширения кэш-памяти”, а не как “эмуляцию диска” – SSD – Solid State Disk, у такого решения множество преимуществ на практике, и широкий успех Flash Cache, устройства для систем хранения NetApp, представляющего собой плату с 256/512/1024GB flash на ней, и устанавливаемую внутрь контроллера FAS3200/6200, тому подтверждение.

Однако у NetApp есть и “классические” SSD, а теперь появилась и новая интересная разработка в области работы с “традиционными” SSD. Ведь не секрет, что не существует волшебной “серебряной пули”, разом решающей абсолютно все проблемы пользователя, что бы там по этому поводу ни утверждали в отделе маркетинга. Вот для областей, где Flash Cache работает недостаточно эффективно, и предназначены новые разработки.

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

Основные отличия Hybrid Aggregate от Flash Cache следующие:

  • Работает в том числе и на запись. В тех случаях, когда характер нагрузки системы пользователя представляет собой, преимущественно, большое количество операций записи сравнительно небольшими блоками, Flash Cache неэффективен, так как практически не ускоряет записи (в определенной степени он их ускоряет, но только за счето того, что, высвобождая ресурсы дисков за счет кэширования чтения, оставляет больше на обработку операций записи). Следует отметить, что рабочая нагрузка, представляющая собой, главным образом, объемный random write мелкими блоками, это довольно специфическая и не слишком массовая задача.
  • Hybrid Aggregate может быть несколько на одной системе, каждый из них может быть настроен индивидуально и независимо от других. Flash Cache работает на все aggregate разом, хотя и можно политиками FlexCache настроить приоритеты и политики кэширования для разных томов.

Как мне видится, преимущества от Hybrid Aggregate получат прежде всего большие и очень большие системы, с сотнями дисков, с большими aggregates и очень большим трафиком ввода-вывода, или же системы со специфической рабочей нагрузкой (большой объем преимущественно записей мелкими блоками), кроме того следует помнить, что Hybrid Aggregate не исключает использование и Flash Cache, он вполне может использоваться вместе с Hybrid Aggregate на той же системе. Таким образом, появление Hybrid Aggregate не стоит трактовать как “отказ от Flash Cache” (я специально делаю это замечание для “паникеров” ;) или признание его неэффективности, это, скорее дополнение в ранее незакрытом сегменте рабочих нагрузок и специфических решений.

Новые цены на FAS2020

Объявлены новые, последние розничные цены на преконфигуренные бандлы FAS2020.

И хотя 2020 это совсем не “звездолет”, это все же вполне себе NetApp, и для многих применений он может вполне удовлетворительно подойти.

Обратите внимание, что откладывать покупку уже времени нет, это последние FAS2020, “распродажа товарных остатков”, с ноября месяца официально “младшим” в семействе FAS2000 назначен FAS2040, который мощнее, но и дороже. Если вы хотели 2020, то вот время купить его. Это задняя цена и заднее не бывает :)

В бандлы включена фиксированная конфигурация на 1 или 2 контроллера, и 12 дисков разной емкости, а также набор лицензий на функциональность, гарантия на “железо” на 3 года, с доставкой замены в режиме Next Business Day, а также трехлетняя попдписка на обновления ПО (SSP – Software Subscription Program) и сопровождение систем (техподдержка через сайт now.netapp.com / support.netapp.com).

Bundle Цена USD
FAS2020, 12X1TB, base sw, 36M SSP NBD-Part-Shippment 7450
FAS2020, 12X2TB, base sw, 36M SSP NBD-Part-Shippment 10950
FAS2020A, 12X1TB, Windows Bundle sw, 36M SSP NBD-Part-Shippment 12950
FAS2020A, 12X600GB, Complete Bundle sw, 36M SSP NBD-Part-Shippment 13950

 

В состав лицензий входят:

  • все доступные протоколы доступа: CIFS, NFS, iSCSI, FCP
  • Base pack – основной набор функциональности, такой как:
    • Snapshots – до 255 снэпшотов на каждый том, не влияющих на производительность
    • Thin provisioning не зависящий от хост-OS
    • Дедупликация – блочная, с размером блока 4KB
    • SyncMirror – синхронная репликация как внутри, так и между системами по IP
  • Wndows bundle это Base pack плюс :
    • SnapRestore – быстрое восстановление тома целиком из снэпшота
    • SnapVault – D2D backup
    • SnapMirror – асинхронная/синхронная/полусинхронная репликация по IP
    • SnapManager – семейство продуктов для создания консистентной резервной копии в снэпшоте и восстановления из нее для MS SQL Server, MS Exchange, MS Sharepoint, Oracle DB, SAP, VMware ESX и MS Hyper-V.
    • SnapDrive – средство создания и управения снэпшотами на системе хранения с хост-OS (сервера) для Windows и UNIX/Linux.
    • NetApp DSM – Device-specific module для Windows MPIO.
  • Complete bundle это все перечисленное выше, плюс еще несколько лицензий:
    • FlexClone – возможность создавать томы-клоны данных
    • Multistore – создание независимых “виртуальных систем хранения” внутри одной физической
    • SnapLock – средство неизменяемого хранения данных (WORM – Write-once, Read-many)

Перечисленные бандлы по новым ценам доступны к заказу партнерами у дистрибуторов, цены со склада в Москве и включают в себя НДС.

Позволю себе также некоторые пояснения и уточнения тут привести.

Первые две позиции это одноконтроллерная конфигурация. Минус одноконтроллерной конфигурации – отсутствие HA-cluster failover. Но большой плюс – в том, что вы можете все 12 дисков использовать в одном aggregate и в одном RAID. В случае двухконтроллерных конфигураций (две следующие, с А) вам придется имеющееся количество дисков разбить пополам, соответственно меньше будет производительность и доступное пространство. Схема без разбивки очень выгодна с точки зрения получившегося объема хранения и производительности.

Если вы не будете гнаться за эфемерностью “кластерной отказоустойчивости” и “отсутствию единой точки отказа™” а предпочтете одноконтроллерную конфигурацию, то вы можете получить больше места и бОльшую производительность за меньшие деньги. При этом, напомню, все системы NetApp поставляются с трехгодичным гарантийным сервисом по “железу” уровня NBD onsite delivery, и это в самом деле NBD – Next Business Day delivery (не просто “время реакции”). NBD = Next Available Flight для территорий “вне Москвы”, по понятным причинам. Это значит, что в случае выхода из строя контроллера, замена для него будет доствлена на следующий рабочий день.

Помните также, что диск “на один миллиард байт”, с маркетинговым названием “1TB”, в реальной жизни меньше на 9,96% (за счет разницы между двоичной и двоично-десятичной арифметикой), а так как NetApp использует для ряда внутренних функций увеличенный сектор, то диск “1TB” будет иметь “полезный” объем 827,6Gib, а “2TB” – 1655,7GiB, именно исходя из этих величин и надо считать usable space системы хранения.

Давайте, для примера, посчитаем.

12 дисков “1TB”, физической реальной емкостью 828GiB. Один диск на HotSpare, два – на RAID-DP parity. Так как для SATA допустимый размер RAID-группы типа RAID-DP равен 16, то мы можем все оставшиеся диски поместить в одну группу, и распараллелить ввод-вывод по ним всем, минимально потеряв на дисках parity. 12 дисков – 1 Hot Spare – 2 parity = 9 дисков

827,6GiB x 9 = 7452 GiB – 10% WAFL overhead = 6703 GiB usable space для ваших данных, пока без учета дальнейшего возможного выигрыша от deduplication, thin provisioning и snapshots. При этом ввод-вывод вашей задачи будет параллельно осуществляться на все 9 дисков системы хранения.

При этом в случае двухконтроллерной конфигурации вы будете вынуждены из 12 дисков отдать два hotspare (каждому контроллеру свой) и два раза по 2 на RAID parity. В результате вы получите всего три диска под данные на каждом из контроллеров. Очевидно, что это не только уменьшит доступную емкость, но и снизит возможное быстродействие, так как ввод-вывод буде распараллеливаться на втрое меньшее число дисков (3 против 9).

827,6GiB x 3 = 2484GiB – 10% WAFL overhead = 2234,5GiB usable space на каждом из двух контроллеров, то есть:
2234,5GiB х 2 = 4469GiB на обоих, на тех же дисках, при использовании двухконтроллерной конфигурации.

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

Так что выбирайте, но острожно, но выбирайте :) И помните, что это последняя возможность купить FAS2020.

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

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

О “цене за гигабайт” и о “цене за решение”

Сегодня мне захотелось поговорить “о королях и о капусте”, поэтому я вспомнил один свой текст, что я когда-то, в начале года, уже публиковал в дискуссии в серверном форуме iXBT, на котором когда-то писал про NetApp. Мне показалось, что этот текст было бы полезно и интересно прочесть и моим читателям в этом блоге, поэтому сегодня будет мало картинок (зато много их будет в четверг), но много текста.

Текст этот писался как развенутый ответ человеку, спросившему “Почему у NetApp такие дорогие диски, и почему они даже дороже, чем у EMC VNX?” и как ответ на вообще-вопрос “Отчего ж все так дорого у вас в энтерпрайзе вообще и у NetApp в частности?”

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

Continue reading ‘О “цене за гигабайт” и о “цене за решение”’ »

DataMotion for Volumes

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

Слегка сокращенный мной перевод статьи из TechONTAP возможно позволит кому-нибудь повнимательнее присмотреться к этой новой возможности систем хранения NetApp.

Что такое DataMotion for Volumes?

DataMotion for Volumes это новая возможность, появившаяся в Data ONTAP 8.0.1 7-Mode. Она позволяет вам переносить, не прерывая работы с ними, LUN-ы на томах с одного aggregate на другой, в пределах одного контроллера системы хранения (нельзя перемещать тома между разными контроллерами, например составляющими HA-пару). DataMotion for Volumes может быть использован для миграции томов, содержащих LUN-ы с “блочным” доступом по FC, FCoE, или iSCSI. Не поддерживаются “файловые” тома, с доступом по NFS или CIFS.

tips-fig1

Рис. 1 NetApp DataMotion for Volumes позволяет вам не прерывая доступа переносить данные LUN и его том на другой aggregate, на том же контроллере NetApp.

Ключевой особенностью DataMotion for Volumes является то, что также переносятся все детали, связанные с томом:

  • Снэпшоты и их расписание
  • Настроенные отношения SnapMirror®, SnapVault®, и MetroCluster™
  • Настройки Thin provisioning
  • Состояние дедупликации (для продолжения работы дедупликации для новых данных необходимо восстановить базу фингерпринтов на новом aggregate путем запуска полного сканирования)

Вы можете перемещать данные между любыми типами дисков, подключенных к контроллеру. Например, вы можете перемещать данные с aggregate на дисках FC или SAS на aggregate, состоящий из дисков SATA, и наоборот. В текущем релизе (8.0.1) вы не можете перемещать данные между разными типами aggregate (“32-bit” и “64-bit” aggregates).

Как работает DataMotion for Volumes?

DataMotion for Volumes использует хорошо известную технологию NetApp SnapMirror для миграции данных тома. Весь процесс делится на три фазы:

  • Setup
  • Data copy
  • Cutover

В фазах setup и data copy, исходный том продолжает обслуживать операции ввода-вывода без их прерывания.

tips-fig2-lg

Рис.2 "Циклограмма" процедур DataMotion for Volumes.

Фаза Setup

В фазе setup, производятся важные предварительные проверки, чтобы убедиться, что вся процедура может быть выполнена успешно. Эти проверки проходят каждый раз, когда DataMotion for Volumes запускается, и проходят вторично, когда начинается фаза cutover.

Проверка анализирует состояние всех объектов (исходного тома, aggregate на котором располагается исходный том, и aggregate-получатель) участвующих в перемещении. Если какая-то из проверок пройдет неуспешно, вы будете уведомлены и процесс не будет запущен. Все ошибки, выявленные проверками, будут выведены в консоль и записаны в лог-файл root-тома (/etc/log/ndvm).

Если все предварительные проверки пройдены успешно, процесс DataMotion for Volumes:

  • Создает временный том на aggregate-получателе, с именем, сформированному по следующему правилу: ndm_dstvol_<timestamp>
  • Запускает начальную (baseline) передачу, устанавливая репликацию SnapMirror между источником и получателем в виде созданного выше тома. Это самая длительная фаза; длительность ее прямо пропорциональна размеру исходного тома, так как требуется передача всего его содержимого.

Фаза Data Copy

После того, как будет проведена репликация уровня baseline, начинается фаза data copy, during which successive SnapMirror updates are initiated to synchronize the destination volume with the source, which remains active. По завершении каждого успешного обновления репликации SnapMirror, DataMotion for Volumes оценивает так называемый delta lag между двумя томами. Вы получите уведомление о величине delta lag, который будет оценочным временем для следующей операции обновления. DataMotion for Volumes остается в фазе data copy так долго, пока величина delta lag остается высокой. Когда величина delta lag уменьшается, система переходит к фазе cutover.

Фаза Cutover

Процесс фазы cutover может быть выполнен вручную, или автоматически ( по умолчанию - автоматически).

Период Pre-cutover. DataMotion for Volumes переходит к фазе cutover на томе-получателе, если том-получатель может быть полностью синхронизрован в заданный интервал, называемый “окно cutover”. Фаза pre-cutover это период времени, в который проводятся предварительные проверки описанные выше, и проводятся важные проверки состояния NVLOG и уровня загрузки CPU.

Вы можете задать пороги использования CPU и диска (в процентах) для выполнения операции DataMotion for Volumes. (по умолчанию порог задан в 100 для обеих опций):

vol.move.cutover.cpu.busy.limit
vol.move.cutover.disk.busy.limit

Автоматический Cutover. Когда все проверки фазы pre-cutover проходят успешно, фаза cutover начинается автоматически. Процесс cutover должен уложиться в окно длительностью 60 секунд. Когда том-получатель полностью синхронизирован, идентификатор тома-источника переносится на том-получатель, и операции ввода-вывода продолжаются с системы-получателя.

В ходе фазы cutover выполняются следующие действия:

  • Все LUN-ы на томе-источнике переводятся в режим задержанных операций ввода-вывода (quiesced). Состояние quiesced препятствует поступлению новых операций ввода-вывода к LUN, при этом опустошается (и не пополняется новыми операциями) текущая очередь операций с данным LUNом.
  • Операции на исходный том приостанавливаются (quiesced). Как часть этой операции приостановки, последняя "дельта" (разностная часть) фиксируется в снэпшоте, который называется ndvm_final_<timestamp>.
  • Том-получатель полностью синхронизируется с томом-источником с учетом полученной "дельты" из снэпшота ndvm_final_<timestamp>. Это будет последняя порция репликации SnapMirror между двумя томами, перед тем, как операции ввода-вывода будут переданы на том-получатель.
  • Временный том на получателе переименовывается в соответствии с именем тома-источника и его file system ID (FSID), и наоборот; то есть идентификаторы тома-источника и временного тома меняются местами.
  • Перенесенный на получателя том переводится в онлайн с идентификаторами исходного тома и LUN становятся активными.
  • Исходный том удаляется (если вы не задали в параметрах его сохранить).

Неудачный автоматический Cutover. Если процесс cutover завершается неудачей, DataMotion for Volumes пытается повторить фазу data copy и пробует еще раз некоторое время спустя (делается три попытки выполнить cutover). Если ничего не удалось, то процесс cutover прекращается, и операции ввода-вывода возобновляются на том-источник. Для продолжения работы DataMotion for Volumes требуется вмешательство оператора.

Ручной Cutover. В случае выполнения cutover в ручном режиме, DataMotion for Volumes остается в фазе data copy, продолжая выполнять репликации SnapMirror. В ходе этих репликаций он записывает их результаты в лог, и ориентируясь на эти данные вы можете самостоятельно выбрать момент для проведения ручного cutover.

Возможные области применения

Существует несколько областей, где может применяться DataMotion for Volumes.

  • Балансировка нагрузки. Переместите том с нагруженного aggregate на менее загруженный.
  • Балансировка емкости. Переместите том с заполненного aggregate на тот, где больше доступного пространства.
  • Перенос данных со сторонних дисков на диски NetApp в системе V-series. Если вы используете NetApp V-Series как front-end к дисковому массиву стороннего производителя, вы можете воспользоваться DataMotion for Volumes для миграции этих данных на диски NetApp на этом контроллере V-series.
  • Изменение типа дисков. Переместите том с дисков одного типа на другие. Например с дисков FC на SAS или SATA.

Использование такого способа для непрерывающего работу переноса данных с дисков FC, выходящих из употребления, на диски SAS, может помочь для критически-высокодоступных систем обеспечить нужный SLA при такой миграции. Также это может помочь пользователям шире начать использовать системы с дисками SATA (также SATA + Flash Cache). При этом пользователи будут знать, что, в случае необходимости, они могут быстро и не прерывая работы перенести данные, которым потребуется большая производительность, чем могут обеспечить диски SATA, назад на диски SAS.

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

Обратите внимание на следующие рекомендации и наилучшие практики при использовании DataMotion for Volumes:

  • Вы можете производить только один процесс миграции DataMotion for Volumes одновременно.
  • Не делайте vol rename или изменение атрибутов тома или LUN на томе-источнике, когда выполняется DataMotion for Volumes.
  • Не запускайте какую-либо операцию, которая может вызвать конфликт процесса выполнения операций DataMotion for Volumes. Если какие-то действия начинаются до того, как процесс вошел в фазу cutover, DataMotion for Volumes прервет свои операции (abort). В состоянии cutover, DataMotion for Volumes прервет (fence) сторонние операции администрирования.
  • При использовании HA-кластера, убедитесь, что обе ноды кластера используют Data ONTAP 8.0.1 7-Mode или новее.
  • Проверьте отсутствие вышедших из строя компонентов системы и загрузку ее процессоров, перед запуском DataMotion for Volumes.
  • Для того, чтобы предотвратить ситуации с конфликтами в фазе cutover, не планируйте занимающие много времени процессы управления или защиты данных параллельно процессу DataMotion for Volumes.
  • Не изменяйте параметры конфигурации исходного тома, во время выполнения процесса DataMotion for Volumes.

SNAPMIRROR и SNAPVAULT

  • В период выполнения операций DataMotion for Volumes, не изменяйте конфигурацию SnapMirror, не редактируйте файл snapmirror.conf.
  • Пока процесс DataMotion for Volumes не достиг фазы cutover, процессы SnapMirror или SnapVault updates успешно завершаются.
  • Если процессы репликации происходят в фазе cutover, то передача данных может быть неуспешной, так как cutover прервет операцию. После того, как cutover будет завершен, репликация продолжит следующий цикл передачи обновлений.
  • В случае выполнения ручного cutover, не делайте его, пока не завершены операции передачи реплик SnapMirror и SnapVault.

SNAPDRIVE и SNAPMANAGER

В фазе cutover:

  • Не работают процессы LUN provisioning и управления снэпшотами в SnapDrive® for Windows® (SDW).
  • Не работают процессы резервного копирования и восстановления данных в продуктах SnapManager® (SME, SMSQL, SMVI, SMHV, SMO, SMSAP, and SMOSS). После окончания фазы cutover, например на следующей запланированной операции создания резервной копии, эти процедуры успешно выполнятся.

Настройки таймаутов SCSI

  • NetApp рекомендует устанавливать на OS хост-системы NetApp Host Utilities Kit, для предотвращения ошибок таймаута. Смотрите "NetApp Host Utilities Installation and Setup Guide" для вашей хост-OS http://now.netapp.com/NOW/cgi-bin/software.

FLEXVOL и FLEXCLONE

  • DataMotion for Volumes может перемещать только тома FlexVol; Тома FlexClone® не могут быть перемещены.После завершения DataMotion for Volumes, исходный том FlexVol остается в состоянии offline и отношения child-parent не изменяются.
  • Тома FlexClone должны быть отделены (split) от породившего их тома FlexVol , перед тем, как вы начнете перенос тома FlexClone.

Дедупликация и компрессия

  • Если на томе-источнике идет активный процесс дедупликации, он должен быть остановлен для успешного выполнения фазы cutover.
  • DataMotion for Volumes не переносит базу fingerprint и change logs дедуплицированного тома FlexVol. После завершения процесса DataMotion for Volumes, пользователи должны запустить команду sis start -s для того, чтобы перестроить fingerprint DB на томе-получателе.
  • Компрессированные тома не перемещаются.

Дополнительные рекомендации по использованию DataMotion for Volumes для Oracle® Database и Microsoft® Exchange можно найти в TR-3881.

Что такое Mailbox Disk?

Некоторое время назад пришлось разбираться с некоей не совсем хорошо описанной и недостаточно хорошо известной функцией внутреннего устройства систем хранения NetApp под названием Mailbox Disk. Это, если в двух словах, некая специальная структура на жестких дисках, с помощью которых две ноды, входящих в HA-пару “классических”, 7-mode кластера сообщают друг другу о своем состоянии, и состоянии кластера в целом, независимо от работы основного метода взаимодействия – кабеля кластерного интерконнекта, и дополнительно к нему.

Упоминание mailbox disks вы можете встретить в выводе команд, показывающих системный статус кластера, и, как правило, в качестве mailbox disks называются диски, на которых располагается root volume системы.

У меня сложилось также впечатление, что mailbox disk это также “рудимент” времен давних, когда кластер у NetApp в целом работал через такие “псевдо-кворумные диски”, без кластерного интерконнекта вовсе, и остался в системе с тех давних пор, но, увы, это пока лишь гипотеза.

Тем не менее, в случае неисправности mailbox disks (их в кластере, если он не использует SyncMirror – по два у каждой ноды), перестает работать cluster takeover, даже при нормальной работе cluster interconnect cable, а это уже серьезно. К сожалению никаких подробных руководств как работать с mailbox disks, что делать в случае проблем с ними, у NetApp в документации нет (отсюда моя гипотеза о “рудиментарности”, то есть “остатках хвоста”, в существовании mailbox disk вообще). Из maintenance mode его можно удалить, и тогда при перезагрузке контроллера он создастся заново. Но, в общем, это все.

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

Вот вам перевод найденного в недрах NetApp KB документа NetApp Mailbox disks FAQ.

Continue reading ‘Что такое Mailbox Disk?’ »

Как заполненность данными системы хранения влияет на ее производительность?

Сегодня в переводах новый автор, это principal technologist регионального представительства NetApp по Австрали и Новой Зеландии, и директор SNIA ANZ - Richard J Martin. Его блог это вообще и в целом довольно отличающееся явление от, увы, распространенного сейчас стиля среди блоггеров “Так как мне не хватает 140 символов моего твиттера, я вынужден написать эти 320 символов в блог, но лучше читайте мой твиттер”, его записи в блог это, порой, настоящие глубокие статьи, которые интересно читать и трудно переводить.

Надеюсь, что он еще не раз появится в моих переводах.

Ричард Мартин, NetApp Australia отвечает на вопрос “как заполненность данными системы хранения влияет на ее производительность?”

How does capacity utilisation affect performance ?

September 10, 2011 storagewithoutborders

Несколько дней назад я получил письмо с вопросом "Каковы рекомендации по максимальному уровню использования пространства системы хранения, не вызывающему падения ее производительности?". С одной стороны такие вопросы раздражают меня, так как чаще всего рождаются из регулярно вбрасываемого FUDa о NetApp, с другой стороны, даже несмотря на то, что правильно спроектированная для стабильного уровня производительности система хранения редко (если такое и вообще возможно) сводится к любой единственной метрике, понимание особенностей использования емкости хранилища и его влияния на производительность, это важный аспект при проектировании вашей системы хранения.

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

Поэтому, отвечая на вопрос, как уровень заполненности системы хранения влияет на ее производительность, мне приходится оговариваться, что "это зависит от ряда факторов", но в большинстве случаев, когда задают такой вопрос, то спрашивающего он интересует для нагрузки с высоким уровнем операций записи, например VDI, некоторые виды online transaction processing, и системы электронной почты.

Если вы рассматриваете такие варианты нагрузки, то можно смотреть наш старый добрый TR-3647 в котором как раз рассматриваются высокие нагрузки со значительными объемами записи, и где говорится:

Структура размещения данных WAFL, используемая в Data ONTAP, оптимизирует записи на диск, для улучшения производительности системы и повышения уровня использования полосы пропускания дисков. Оптимизация в WAFL использует небольшой объем свободного или зарезервированного пространства в пределах aggregate. Для высокой нагрузки, связанной с интенсивной записью, мы рекомендуем оставлять незанятым пространство, равное, в среднем, 10% от usable space, для работы этого оптимизационного процесса. Это пространство не только обеспечивает высокопроизводительную запись, но также работает как буфер при неожиданно возникающих потребностях приложения в свободном месте при объемных записях на диск.

Я видел некоторые бенчмарки, использующие синтетическую нагрузку, где точка перелома графика производительности наблюдалась между 98 и 100% usable емкости, после вычета WAFL reserve, я также видел проблемы производительности, когда люди полностью заполняли все доступное пространство на системе хранения, а затем начинали писать не нее мелкими блоками множество перезаписей данных. Это не является уникальным свойством именно WAFL, в случае любой системы хранения такое ее использование будет довольно плохой идеей, заполнить все пространство на любой структуре данных, а затем пустить на нее объемный random write.

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

Оставляя в стороне тему FUD, (подробный его разбор требует довольно глубокого понимания внутренней архитектуры ONTAP) при рассмотрении того, как влияет заполнение емкости на производительность на системах хранения NetApp FAS, надо хорошо понимать следующие моменты:

  1. Для любого конкретного типа рабочей нагрузки и типа системы хранения вы можете достичь только сравнительно ограниченного числа операций на диск, это число на диск 15K RPM составляет, обычно менее 250.
  2. Производительность системы хранения обычно определяется тем, на сколько дисков может быть распараллелена нагрузка ввода-вывода.
  3. Большинство производителей систем хранения предоставляют для рабочей нагрузки ввода-вывода диски, объединенные в RAID-10, который использует вдвое больше raw-дисков на данный объем usable. При этом NetApp использует RAID-DP, который не требует удваивать количество дисковых шпинделей на заданный объем usable данных.
  4. В большинстве бенчмарков (см. например SPC-1), NetApp использует для тестирования все доступное дисковое пространство, кроме 10% от usable space (в соответствии с написанным в TR-3647) что дает пользователю примерно 60% от емкости raw дисков, при этом достигая того же уровня IOPS/диск, которое другие производители получают при уровне usable в 30% от raw. Таким образом, равную производительность из расчет на жесткий диск мы обеспечиваем при на 10% большем уровне usable пространства, чем другие производители могут теоретически достичь при использовании RAID-10.

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

Хотя все это действительно правда, следует отметить, что тут есть и один недостаток. Хотя величина IOPS/Spindle более-менее та же, величина "плотности IOPS" (IOPS density) измеренная в IOPS/GB для результатов NetApp SPC-1 составляет примерно половину от решений конкурентов, (те же IOPS , 2x данных = вдвое меньше плотность). Хотя это на самом деле и сложнее сделать, за счет более низкого соотношения cache/data, если у вас есть приложение, которое требует очень высокой плотности IOPS/GB (например некоторые инфраструктуры VDI), тогда вы можете не использовать всю имеющуюся у вас дополнительную емкость под эту нагрузку ввода-вывода. Все это дает вам, в результате, возможность выбора из трех вариантов.

  1. Не использовать это дополнительное место, оставив его незанятым на aggregate, позволить работать на нем оптимизации записей и получить лучшую производительность.
  2. Использовать дополнительное место, например для данных некритичных к производительности, таким как хранение снэпшотов, или зеркальная реплика данных, или архивы, и так далее, и установить этой нагрузке пониженный приоритет с помощью FlexShare.
  3. Установить карту Flash Cache, которая удвоит эффективные показатели IOPS (зависит от вида нагрузки, конечно) на физический диск, что обойдется дешевле, и сэкономит ресурсы, чем удвоение количества физических дисков.

Если вы поступаете иначе, то вы можете получить ситуацию, когда наша высокая эффективность использования пространства позволяет пользователю запустить слишком большую нагрузку по вводу-выводу на недостаточном количестве физических жестких дисков, и, к сожалению, снова снова порождает пресловутый и бесконечно гуляющий FUD о "Netapp Capacity / Performance".

Он некорректен прежде всего потому, что причина тут не в каких-то тонкостях Data ONTAP или WAFL, а в том, что на систему, сайзинг которой был проведен для рабочей нагрузки X, помещают 3X данных, так как "на дисках еще есть место", и весь ввод-вывод этих 2-3-кратного объема данных наваливается на дисковые шпиндели, запланированные под совсем другой уровень нагрузки и объемов.

Для того, чтобы сделать счастливыми, и, что немаловажно, поддерживать это состояние в пользователях вашей системы хранения, вам, как администратору, нужно уметь управлять не только доступной вам емкостью, но и доступной производительностью системы хранения. Чаще всего у вас будет исчерпываться одно раньше, чем другое, и работа эффективной IT инфраструктры означает умение балансировать рабочую нагрузку между этими двумя ресурсами. В первую очередь это означает, что вы потратили определенное время измеряя и мониторя емкость и производительность вашей системы. Кроме этого вам следует настроить вашу систему так чтобы иметь возможность мигрировать и ребалансировать нагрузку между ресурсными пулами, или же иметь возможность легко добавлять дополнительную производительность для имеющейся нагрузки не прерывая нормальной работы системы, что может быть осуществлено с помощью таких технологий, как Storage DRS в vSphere 5, или Data Motion и Virtual Storage Tiering в Data ONTAP.

Когда вы наблюдаете за параметрами вашей системы хранения, вы можете своевременно принять меры, до того, как какие-либо проблемы проявятся. У NetApp есть множество великолепных инструментов по мониторингу производительности всей системы хранения. Performance Advisor дает вам визуализированные и настраиваемые алерты и пороги их срабатывания для встроенных метрик производительности, доступных в каждой системе хранения FAS, а OnCommand Insight Balance предоставляет углубленный отчет и упреждающий анализ для всей вашей виртуализованной инфраструктуры, включающей, в том числе, и стороннее, не-NetApp, оборудование.

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

Хотя я понимаю весь соблазн вернуться к старой практике, привычной для "классических" систем хранения, когда для системы хранения почти нет шансов превысить ее возможности по IOPS, прежде чем она исчерпает свои возможности по емкости, это почти всегда невероятно расточительно, и ведет, по моему опыту, к уровню использования емкости около 20% и менее, и приводит к экономически неоправданной цене/GB для таких “Tier-1″ хранилищ. Возможно еще настанут "сытные годы", когда администраторы будут снова иметь роскошь не обращать внимания на цену решения, или, быть может, вы окажетесь в такой редкой отрасли, где "цена не имеет значения", однако для остальных нынешние времена - времена начистить и привести в готовность свои навыки мониторинга, настройки и оптимизации. Сегодня спрос есть на умение делать больше с меньшими затратами, и надо учиться этому.

FAS2240 - новинка модельного ряда NetApp этого года.

Итак, об этом можно рассказать. Официально объявлено о новой модели, или вернее даже двух моделях – FAS2240-2 и FAS2240-4, о самом факте их существования я уже упоминал, теперь объявлены детали.

Как мы и предположили раньше, это модели систем хранения, представляющие собой, фактически, контроллер для дисковой полки DS2246 и DS4243 соответственно, продаваемые как отдельная модель системы хранения, и состоящие из знакомого конструктива дисковой полки с дисками, и контроллера в них. Такая конструкция позволяет легко, в дальнейшем, апгрейдить такую систему, просто вынув из нее контроллер и вставив на его место интерфейсный модуль IOM-3/6, превратив такую систему с ее дисками и данными на них, в дополнительную дисковую полку

image

Вид спереди FAS2240-2

Continue reading ‘FAS2240 - новинка модельного ряда NetApp этого года.’ »

Как передать диск в системе от одного контроллера другому

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

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

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

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

Описание

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

Процедура

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

1. Получим Disk ID

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

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

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

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

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

Внимание:

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

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

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

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

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

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

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

Эксперименты с Calibration IO в Oracle 11g

Сегодня у нас снова перевод короткой заметки Neto – технического архитектора NetApp, занимающегося вопросами работы с базами данных Oracle.

Playing with Calibration IO - Oracle 11g

Posted by neto on Aug 11, 2011 2:37:40 AM

Oracle 11g имеет интересную возможность эмулировать ввод-вывод (случайное чтение большими блоками (1MByte)). Это называется Calibration IO - http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/iodesign.htm

Давайте проделаем небольшой тест с помощью этого средства.

 

1) Проверяем, что все файлы данных используют asynchronous IO:

col name format a50
select name,asynch_io from v$datafile f,v$iostat_file i where f.file#=i.file_no and (filetype_name=’Data File’ or filetype_name=’Temp File’);
NAME                                               ASYNCH_IO
————————————————– ———
/oracle/databases/prod/data/system01.dbf           ASYNC_ON
/oracle/databases/prod/data/system01.dbf           ASYNC_ON
/oracle/databases/prod/data/sysaux01.dbf           ASYNC_ON
/oracle/databases/prod/data/undotbs01.dbf          ASYNC_ON
/oracle/databases/prod/data/users01.dbf            ASYNC_ON
/oracle/databases/prod/data/soe.dbf                ASYNC_ON

 

2) Запускаем Calibration IO


SET SERVEROUTPUT ON
DECLARE
  lat  INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
– DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
   DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);
  DBMS_OUTPUT.PUT_LINE (’max_iops = ‘ || iops);
  DBMS_OUTPUT.PUT_LINE (’latency  = ‘ || lat);
  dbms_output.put_line(’max_mbps = ‘ || mbps);
end;

 

3) Смотрим на стороне NetApp:


[root@dl585-10 ~]# ssh 10.61.106.103 sysstat 1
CPU    NFS   CIFS   HTTP      Net kB/s     Disk kB/s      Tape kB/s    Cache
                               in   out     read  write    read write     age
21%   2987      0      0    2848 102705    86688      0       0     0       2s
26%   2955      0      0    2833 101569    85000      0       0     0       2s
21%   2879      0      0    2768 98919     77168      0       0     0       3s
21%   2964      0      0    2810 101982    82673      0       0     0       3s
21%   3952      0      0    2807 111602    85412   6064       0     0       3s
21%   2894      0      0    2729 97518     79832      0       0     0       2s
22%   3033      0      0    2877 104390    92552      0       0     0       2s
20%   2825      0      0    2674 97233     81780      0       0     0       2s
21%   2808      0      0    2696 96510     81396      0       0     0       2s

4) Результаты Calibration IO:

max_iops = 5570
latency = 10
max_mbps = 110

 

110 Mегабайт в секунду, довольно неплохо для одного 1Gbit интерфейса с сервера Oracle на NetApp!

18/0.192

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.