Archive for the ‘techtalk’ Category.

О кэшировании в SSD для E-Series

Как вы знаете, я мало и редко пишу тут про отдельное семейство продуктов NetApp - так называемые системы хранения E-series (они же знакомы многим из вас как IBM DS3500/3700, и ряд других), это продукты бывшего LSI Engenio, пару лет назад перешедшего “под крыло” NetApp. ?? хотя под этим самым крылом развитие их не остановилось, напротив, даже закоренелые скептики вынуждены были признать, что ресурсы NetApp сильно помогли Engenio в разработке новых фич и продвижении продукта, для меня эти системы довольно сторонний продукт, и пишу я о нем тут редко.

E5400

Причин этому две. Во-первых ни их самих, ни задач под них у меня нет нигде рядом, во-вторых сами по себе они мне не особенно интересны.

Последнее стоит чуть более развернуто объяснить.
Дело в том, что, если системы линейки FAS, это стораджи “широкого профиля” применения, создаваемые для использования под различные задачи, с широким набором разнообразной функциональности, как встроенной, так и дополнительной, то системы E-Series это крайне “узкопрофильный” сторадж. Это система хранения, строго говоря, под одну задачу: “скорость, скорость и ничего кроме скорости”. Причем “ничего кроме” это почти не фигура речи. Как следствие (а вы знаете мою позицию по данному вопросу), это системы хранения довольно ограниченны по своей области применения.
Это “болиды Формулы 1″, быстрые в условиях гоночного трека, но не очень полезные в городе или, например, на стройке.

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

Поэтому, по моему мнению (и по мнению NetApp), E-series это нишевое решение, для специализированных применений, таких как хранилища для Big Data под Hadoop, высокопроизводительные grid-системы, стораджи под Lustre для HPC, промышленных масштабов Video Surveillance, реалтайм аналитика, особо критичные к времени выполнения запросов OLTP-базы, и прочие подобные области применения.

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

Вот и кэширование в SSD (Performance Read Cache), поверхностно похожее на аналогичную функцию у NetApp FAS, довольно значительно отличается от NetApp Flash Pool (Hybrid Aggregate).

Во-первых, значительным отличием является использование переменного размера блока. Так как E-series это не-WAFL-based системы, они не привязаны к блоку “файловой системы” (в случае WAFL это 4 килобайта), и могут варьировать размер оперируемого блока от 2K до 8K. В ряде случаев это может дать эффект при специфических нагрузках ввода-вывода, прежде всего при процессе “прогрева кэша”, то есть первоначальном заполнении его данными. ??сследование NetApp утверждает, что правильная настройка размеров блока для Performance Read Cache на E-series может дать до 500% увеличения скорости первоначального наполнения кэша. А как вы понимаете, чем быстрее наполнится этот, довольно объемистый кэш на SSD, тем скорее он даст отдачу по ускорению работы с данными.

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

Наконец, значительным отличием от Flash Pool является то, что карта блоков кэша у E-series хранится в оперативной памяти контроллера, а не на диске, как у FAS. Это, конечно, позволяет ускорить выборку (по утверждению NetApp возможно до 700% ускорения), но значительно нагружает память контроллера и занимает в нем много места. Это оправданно для purpose-build стораджа, в котором производительности отдано все, но расточительно для стораджа, в котором память контроллера используется под множество различных задач и функций.

Минимальный доступный объем SSD cache для E-series это один SSD, а максимальный на сегодня - 5TB на сторадж. Причем предлагаются SSD объемом 800GB за “диск”.

Data ONTAP Simulator 8.1.1 в VirtualBox

О том что такое симулятор Data ONTAP я не буду повторяться в пятый, кажется, раз, отсылая к более ранним постам на эту тему. Сегодня – о возможности поставить Simulator под гипервизором, отличным от рекомендуемой NetApp VMware. Ну, допустим, у вас Linux, Solaris, или еще что-то, и поставить VMware Player вы не можете. ??ли просто больше любите VirtualBox. Если для симуляторов версии 7 все было просто, там, фактически, это была задача под обычным Linux, то теперь, для симуляторов v8, это стало чуть сложнее, так как он идет уже готовой VM с FreeBSD внутри.

Описание того, как настроить VM в VirtualBox для запуска в нем Simulator 8.1.1 было недавно опубликовано в Community NetApp.

  1. Установите VirtualBox обычным образом.
     
  2. Скачайте и распакуйте Симулятор 8.1.1
     
  3. Создайте новую VM с типом OS – “BSD”, версией “FreeBSD (64bit)”. Выделите памяти 1600MB, не выбирайте создание виртуальных дисков, они у нас уже есть и мы подключим их позже в готовую VM.
     
  4. Откройте настройки VM (Settings), и на странице System, на табе Processor установите количество CPU – 2.
     
  5. В настройках Storage удалите CDROM с IDE-контроллера. Затем добавьте 4 виртуальных жестких диска, для каждого диска выберите уже существующий vmdk симулятора, по порядку: “DataONTAP.vmdk”, “DataONTAP-var.vmdk”, “DataONTAP-nvram.vmdk” и “DataONTAP-sim.vmdk”. Добавьте контроллер floppy drive с одним пустым floppy. Получившиеся настройки должны выглядеть так:
     

     

  6. На странице Audio уберите отметку в чекбоксе Enable Audio.
     
  7. На странице Network добавьте четыре сетевых адаптера (любого нужного вам режима: “host only”, “bridged”, “internal”, “NAT”). В каждом из четырех добавленных NIC откройте секцию Advanced, и выберите в ней тип адаптера “Intel Pro/1000MT Server (82545EM)”. В симуляторе есть драйвер только для этой карты. Выглядит в итоге все так:
     

     

  8. В стандартной установке виртуальная машина использует подключенные пайпы Windows для двух последовательных портов: стандартной консоли и дебага. Выможете перенаправить их в обычные последовательные порты, но это не обязательно.
     
  9. На странице USB снимите отметку в чекбоксе “Enable USB Controller”
     
  10. На странице Shared Folder не устанавливайте shared folder.
     
  11. Запишите все изменения в VM.
     
  12. Убедитесь, что имеете 1600MB физической свободной памяти для запуска VM, иначе запуск прервется в произвольном месте.
     
  13. Запустим VM.
     
  14. Во время 10-секундной паузы нажмите любую клавишу КРОМЕ Enter, чтобы прервать нормальную загрузку.
     
  15. ??змените настройки, запретив запуск установленных в виртуальной машине VMware Tools командой: “setenv bootarg.vm.run_vmtools false”

     
  16. Тут же можно изменить и серийный номер симулятора, если вы собираете многосимуляторную конфигурацию, чтобы избежать конфликта при их одновременной работе.
     
  17. Введите команду “boot” для нормальной загрузки
     
  18. Когда появится сообщение “Press Ctrl-C for menu”, нажмите Ctrl-C и дождитесь появления boot menu. Первая загрузка может занять порой довольно значительное время.
     
  19. В появившемся boot menu выберите пункт 4, и подтвердите очистку всех дисков и конфигурации.
     
  20. Затем симулятор перезагрузится, эту загрузку уже не нужно прерывать. После окончания загрузки вы увидите стандартную подсказку мастера начальной установки параметров системы, следуйте этой установке и введите все необходимые параметры. Откажитесь от предложения “продолжить в графическом режиме” где-то в середине мастера (в 8.1.1 FilerView уже нет), и дойдите до конца. Если вы сбились, то просто введите setup в качестве команды в консоли, после завершения мастера, и вы сможете повторить настройку с уже введенными данными и изменить какие-то из них.
     

В последний раз о фрагментации файлов и производительности

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

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

Выше в постах, на которые я сослался, я уже ответил на этот вопрос и прояснил свою позицию. Вкратце: при рандомном доступе производительность от фрагментации данных не зависит. Так как система хранения обращается к данным рандомно, в произвольном, случайном порядке, то нет никакой особенной разницы в том, будут ли блоки данных лежать упорядоченно, или беспорядочно – их всегда будут читать “беспорядочно”. А рандомность обращения, помноженная на рандомность размещения не дает “рандомность в квадрате”, она остается обычной рандомностью, “в первой степени”.

Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз OLTP, для виртуализованных серверных сред почти 100% доступа к данным является рандомным? Последовательный, “секвентальный” доступ встречается в очень узком сегменте, это бэкапы (а у NetApp, к слову, задача бэкапа, как вы помните, решается другим способом, а не последовательным копированием и передачей данных), это базы с характером доступа DSS, и это, отчасти, логи баз данных. Вот, в общем, и все использование секвентального доступа. Остальное все – более или менее чистый рандом.

Поэтому я взял паттерн доступа VM-сервер (40%-write/60%-read, 45%-sequental/55%-random, 4KB block). Секвентальность в последнем случае берется вследствие работы локального кэша хоста. Паттерны эти определил не я, они довольно широко распространены. Вот его и будем кушать мерять.

Тестировал я с помощью IOmeter, который, несмотря на некоторые его недостатки, знаю и люблю. В качестве load-generator использовались виртуальные машины, работающие с достаточно мощного хоста (IBM 3850 X5), который был подключен к стораджу по NFS. Для OS в VM диск выглядел “физическим” LUN без файловой системы, который делался MBR-разделом и форматировался в NTFS со стандартным размером блока (4KB). Раздел делался размером 40GB, на нем создавался тестовый файл IOmeter (iobw.tst), размером 16GB (для гарантированного “пробоя кэша”). На каждой VM делался 4-процессорный vCPU, и, соответственно, запускались 4 Worker, на каждом из которых пускался тестовый паттерн на созданный диск, в 16 потоков ввода-вывода (Outstanding IOs) на каждый Worker, то есть 64 одновременных потока ввода-вывода на диски (контроллер NetApp). Загрузка хост-сервера тестом не превышала при этом 15% (мощная зверюга этот 3850), загрузка стораджа колебалась, но также не превышала 80%. То есть заведомо мы в “потолки” нигде не упирались.

Для минимизации эффектов “прогрева WAFL” (о котором еще будет пост, это также была одна из тем “исследовательской недели”) я делал длинный ramp-up (10 минут), а затем начинался собственно измеряемый тест, длиной 30 минут. Я брал для оценки значение в steady state, ближе к концу теста, и для оценки параллельно проверяемого эффекта “падения производительности” при прогреве – ближе к его началу.

Однако, перед исследователем, в моем лице, встала проблема: как обеспечить “фрагментацию” файла тестирования? Если создать последовательный, упорядоченный файл просто: запускай IOmeter на пустом диске – вот он и создаст свой iobw.tst, то с фрагментацией “на заказ” сложнее.

Для того, чтобы сделать фрагментированный файл я нашел любопытную утилитку, под названием MyDefragmenter, которая, как ясно из названия – дефрагментатор. Но у нее в комплекте есть также программка MyFragmenter :). Она делает вполне ожидаемую из названия вещь :)

Я взял созданный IOmeter тестовый файл и качественно замесил его с помощью этой утилитки. Я фрагментировал с ее помощью этот файл на 250 тысяч кусочков по 64KB каждый (ну, чтоб не было претензий, что гранаты у нас не той системы;), а потом повторно провел тестирование описанными выше паттернами.

Также я проанализировал ситуацию с фрагментацией не только файла на NTFS, но и в WAFL, а затем измерил эффект от работы reallocate в WAFL.

Хочу отдельно отметить, что в данном случае измеренные “попугаи”  не могут рассматриваться по абсолютной величине, я не проводил никакого (необходимого) тюнинга системы, и настройки ее “по уму” и по best practices (это я  сделаю позже, ту у меня есть некоторые бюрократические процедуры для этого). Целью теста было сравнить два достигнутых параметра производительности: “А” и”Б”, то есть их соотношение, а не достижение абсолютного рекорда, поэтому реплики с мест “чота как-то иопсев маловата!” мы отметем как неорганизованные ;).

Вот какие результаты я получил:

Continue reading ‘В последний раз о фрагментации файлов и производительности’ »

Замена “головы” в сторадже: disk ownership change

Вы уже наверняка знаете, что, в принципе, замена контроллера на установленной системе хранения NetApp процедура довольно несложная. Так как все контроллеры, всех семейств, используют одну и ту же OS Data ONTAP, отличаясь только  внутренним аппаратным устройством, а индивидуальные настройки контроллера системы (файловая система /etc, если кто понимает UNIX-style) находится отдельно от контроллера, на дисках дисковых полок, то вообще говоря замена контроллера на новый, даже другой системы, сводится к простому перетыканию кабелей, после чего новый контроллер с OS внутри подмонтирует свои индивидуальные настройки и поднимется с сохранением настроек и данных на дисках. Но следует не забыть про software ownership. Дело в том, что в этой схеме, ныне общепринятой, диски “приписаны” к определенному контроллеру по его SystemID (а не по подключенным портам, как было когда-то, во времена FAS3020 и старше). Соответственно, чтобы старые диски увиделись новым контроллером нужно на них записи их владельца поменять на нового. делается это из Maintenance mode:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2012.10.08 09:26:06 =~=~=~=~=~=~=~=~=~=~=~=
login as: root
root@192.168.99.161’s password:
=== OEMCLP v1.0.0 BMC v1.3 ===
bmc shell -> system power cycle
This will cause a dirty shutdown of your appliance. Continue? [y/N] y
bmc shell ->
bmc shell -> system console
Press ^G to enter BMC command shell

AMI BIOS8 Modular BIOS
Copyright (C) 1985-2009,  American Megatrends, Inc. All Rights Reserved
Portions Copyright (C) 2009 NetApp, Inc. All Rights Reserved
BIOS Version 6.1
+++++++++++++++++++++++++++++++++++

Boot Loader version 2.1
Copyright (C) 2000-2003 Broadcom Corporation.
Portions Copyright (C) 2002-2008 NetApp

4096MB RAM installed
CPU Type: Intel(R) Xeon(R) CPU                  @ 1.66GHz

Starting AUTOBOOT press Ctrl-C to abort…
Loading X86/freebsd/image2/kernel:..0×200000/7916668 0×98cc7c/708860 0xa3a000/573440 Entry at 0×00248390
Loading X86/freebsd/image2/platform.ko:0xac6000/380544 0xb23000/28000 0xb29d60/109976
Starting program at 0×00248390
NetApp Data ONTAP 8.1.1 7-ModeCopyright (C) 1992-2012 NetApp.
All rights reserved.
md1.uzip: 26368 x 16384 blocksmd2.uzip: 3584 x 16384 blocks

*******************************
*                             *
* Press Ctrl-C for Boot Menu. *
*                             *
*******************************
^C

Boot Menu will be available.

Please choose one of the following:

(1) Normal Boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Clean configuration and initialize all disks.
(5) Maintenance mode boot.
(6) Update flash from backup config.
(7) Install new software first.
(8) Reboot node.
Selection (1-8)? 5

You have selected the maintenance boot option:
the system has booted in maintenance mode allowing the
following operations to be performed:

?                 disk             
key_manager       fcadmin          
fcstat            sasadmin         
sasstat           acpadmin         
halt              help             
ifconfig          raid_config      
storage           sesdiag          
sysconfig         vmservices       
version           vol              
aggr              sldiag           
dumpblock         environment      
systemshell       vol_db           
led_on            led_off          
sata              acorn            
stsb              scsi             
nv8               disk_list        
fctest            disktest         
diskcopy          vsa              
xortest           disk_mung        

Type "help <command>" for more details.

In a High Availablity configuration, you MUST ensure that the
partner node is (and remains) down, or that takeover is manually
disabled on the partner node, because High Availability
software is not started or fully enabled in Maintenance mode.

FAILURE TO DO SO CAN RESULT IN YOUR FILESYSTEMS BEING DESTROYED

NOTE: It is okay to use ’show/status’ sub-commands such as
‘disk show or aggr status’ in Maintenance mode while the partner is up
Continue with boot?Please answer yes or no.
Continue with boot? yes

*> disk ?
usage: disk <options>

Options are: 
        assign {<disk_name> | all | [-T <storage type> | -shelf <shelf name>] [-n <count>] | auto} [-p <pool>] [-o <ownername>] [-s <sysid>] [-c block|zoned] [-f] - assign a disk to a filer or all unowned disks by specifying "all"  or <count> number of unowned disks
        ddr_label {repair | print | delete | dumpraw | modify [-c] -o <offset> -v <value> | start_scan | pause_scan | resume_scan | error_scan} [-d all | <disk_list>]
        encrypt { lock | rekey | destroy | sanitize | show } - perform tasks specific to self-encrypting disks
        power_cycle [ -f ] { [-d <disk_list>] | [ -c <channel_name> [ -s <shelf_number> ] ] } - power-cycle one or more disks
        reassign {-o <old_name> | -s <old_sysid>} [-n <new_name>] [-d <new_sysid>] - reassign disks from old filer
        remove_ownership [<disk_name> | all | -s <sysid>] [-f] - revert/remove disk ownership
        sanown_stats {start| stop| show }- collect sanown event stats
        show [-o <ownername> | -s <sysid> | -n | -v | -a]  - lists disks and owners
        unfail [-s] <disk_name>     - unfail a disk  (-s  not valid in maintenance mode)
        upgrade_ownership           - upgrade disks to new ownership scheme

*>

*> disk reassign -s xxxxxxxxxxx -d yyyyyyyyyyy

Partner node must not be in Takeover mode during disk reassignment
from maintenance mode.
Serious problems could result!!
Are you sure partner is NOT in takeover mode (y/n)? n

*> halt

Oct 08 01:34:22 [localhost:kern.cli.cmd:debug]: Command line input: the command is ‘halt’. The full command line is ‘halt’.

Uptime: 6m54sSystem halting…

Выше я прервал переназначение disk ownership, сама же эта процедура делается довольно быстро, и если нигде не ошибиться, и все иметь подготовленным и смонтированным, то можно уложить процедуру замены контроллера системы хранения в 15-20 минут.

Впрочем, если вы используете NetApp как SAN-устройство, и храните на нем LUN-ы, есть еще одна тонкость, связанная со сменой serial id этих LUN при замене NVRAM (отдельно, или в составе контроллера целиком), о которой поговорим в четверг.

SMB 3.0

Для начала терминологическое вступление. Вокруг файлового протокола Microsoft довольно много путаницы, начнем с ее распутывания.

  • SMB“Server Message Block” – первоначальная версия протокола, разработанная еще во времена MS LAN manager 1.0(почти уже никто не застал те времена, и не помнит что это, совсем каменный век IT, середина 80-х). Некоторый отголосок этой аббревиатуры остался в названии опенсорсного продукта SAMBA, реализации файлового протокола SMB путем его реверс-инжиниринга.
  • CIFS – (он же SMB-“просто” или SMB 1.0) – “Common Internet File System” – название CIFS появилось, когда Microsoft в 1996 году начала процесс стандартизации уже существовавшего протокола, в качестве RFC в IETF. Процесс стандартизации этот застопорился где-то на начальном этапе, и MS решила не продолжать его, остановившись на проведении в RFC первой версии драфта (сегодня его статус уже expired). Тем не менее название CIFS в индустрии закрепилось, и постепенно почти вытеснило SMB.
  • SMB 2.0 – протокол, появившийся в Windows Server 2008, Vista, и поддерживающийся в более поздних OS. Microsoft осознала в какой-то момент, что файловый протокол, разработанный в середине 80-х, пусть и весьма совершенный на тот момент, и имеющий возможности постепенного расширения и добавления возможностей на уровне протокола, страшно отстал от современности (ситуация как примерно с Internet Explorer), страдает рядом существенных проблем, которые стали более заметны с годами. ?? вот в компании дошли руки до начала глубокой модернизации протокола SMB. Обратите внимание, что SMB 2.0 уже некорректно называть “CIFS”. CIFS это только SMB 1.0, поэтому постепенно название CIFS будет уходить. Я, в свою очередь, в этом блоге также буду постепенно избавляться от термина “CIFS”. Если мы говорим о новых версиях файлового протокола Microsoft, то мы будем называть его SMB (v2.0, v2.1, v2.2 AKA v3.0). В SMB 2.0 (и последующих его модификациях: 2.1, 2.2) были улучшены многие насущно важные аспекты, мешавшие SMB 1.0. Протокол был значительно упрощен, и, вместе с тем, улучшен. Появилась возможность кэширования и объединения нескольких команд в одну “цепочку”. Улучшилась работа по “длинным” сетям с большими уровнями задержек, что позволили использовать SMB 2.0 даже в географически распределенных локальных сетях, соединенных через WAN и VPN. Улучшилась реакция на кратковременные дисконнекты сети и масштабируемость.
    Но работы в группе разработки SMB не стояли на месте, и к выходу Server 2012 была готова новая, еще более глубоко переработанная версия:
  • SMB 3.0 – это самая новая на сегодня версия файлового протокола Microsoft, с которым компания готова побороться с некоторым вынужденным засилием NFS в файловых системах хранения (NAS). В ее разработке MS буквально скакнула через несколько ступенек, и подготовила крайне интересный и современный продукт, с множеством новинок и хорошим заделом на будущее. Продолжая развитие SMB 2.0, в Microsoft еще более значительно улучшили производительность работы протокола, реализовали такие интересные вещи, как SMBDirect, с использованием RDMA Transport Protocol (Remote DMA, технология, используемая в высокоскоростых сетях, таких как 10G Ethernet и Infiniband) и поддержку многоканального режима, возможность использовать Remote VSS, BranchCache v2, Transparent Failover, шифрования. Немалую роль в популяризации и распространении SMB 3.0 должен сыграть и MS Hyper-V, впервые поддерживающий в его лице файловые протоколы для подключения стораджа.

Официально о поддержке, кроме самой Microsoft, уже заявили EMC и NetApp, два крупнейших игрока рынка NAS, а также поддержка SMB 3.0 появится и в открытом проекте SAMBA. Есть надежда, что к этим игрокам, после выхода Server 2012 подтянутся и остальные, уж больно много полезного появилось в новом SMB.

Так, например, SMB 3.0 явственно нацелился не только на традиционный для SMB 1.0/CIFS/SMB 2.0 сегмент канала связи от сервера до конечной клиентской машины, но и на межсерверный коннект (как бы ни звучало это дико и невообразимо для Old Skool: “Между серверами по бэкбону гонять данные? MS SQL? Exchange? По CIFS SMB? Да вы шутите!”). Для этого в нем появились средства SMBDirect и multichannel, позволяющие полноценно использовать производительные возможности вплоть до все еще невообразимого многими 40G Ethernet. Например можно объединить на уровне протокола (а не EtherChannel) в мультилинковый “транк” четыре 10G-линка. А использование RDMA (наиболее известным пользователем технологий RDMA является протокол Infiniband, славящийся своей низкой латентностью) и iWARP (я рассказывал о них в давней заметке в этом блоге) позволит даже выйти по уровню латентности и полосе пропускания для файлового протокола на уровень FC, при этом сохранив все преимущества файлового, а не тупого блочного протокола.

SMB 2.0 поддерживается в системах NetApp уже довольно давно, и требует просто включения соответствующей опции в конфигурации (> options cifs.smb2.enable on и > options cifs.smb2.client.enable on), так что если вы используете в своей сети клиентов не ниже Windows Vista/7, и сервера не ниже Server 2008, то есть смысл включить на сторадже эти опции и перейти целиком на версию протокола SMB 2.0, вы можете получить довольно заметный прирост в производительности.

Поддержка SMB 3.0 в NetApp появится в версии Data ONTAP 8.2, планируемой к выпуску в RC осенью этого года.

Политики кэширования записи на Flash Pool

В одном из предыдущих постов я начал описывать то, как, с помошью политик кэширования Flash Pool можно настроить индивидуально параметры кэширования для томов. Однако кроме кэширования чтения у Flash Pool появидлись средства и кэшировать запись. ??х немного, но они есть.

В настоящий момент имеется два варианта настройки кэширования записи (и один – и чтения и записи разом, который зачислен в “чтения”, и о котором я упомянул в предшествующем посте на эту тему):

  • write-cache = none – тут нечего особенно рассказывать, это отключение кэширования записи, когда она включена в режиме кэширования во Flash Pool по умолчанию. Параметр этот может быть задан на каждый конкретный том, и использовать его стоит в тех случаях, когда кэширование записи не приносит пользы, например когда рабочая нагрузка не делает многочисленных и частых random-перезаписей данных тома (а напротив, записи идут секвентальные, большими блоками). С использованием такой опции данные пойдут непосредственно на HDD, собственно как они и записывались ранее, в обычных aggregates, без использования Flash Pool. В случае такого характера нагрузки данных тома, вы освободите место на кэше для тех, кому оно действительно необходимо.
  • write-cache = random-write – эта опция, напротив, включает кэширование записей на aggregate для данного тома через flash. При этом данные сперва попадают в пространство SSD и кэшируются на нем. Такая политика должна хорошо работать для задач, когда данные, рандомно записываемые на том, часто перезаписываются, или перечитываются сразу после записи. Это значение политики записи по умолчанию.

Как я уже упоминал в предшествующей заметке, для управления настройкой кэширования томов на Flash Pool теперь используется новая команда priority, имеющая следующий синтаксис:

priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

Что такое IOPS?

Сегодня очередной перевод одного из моих любимых авторов, инженера NetApp Dimitris Krekoukias, пишущего в блоге recoverymonkey.org. Текст крайне важный и заставляющий задуматься. Казалось бы, все мы знаем, что такое “IOPS”, но знаем ли мы это на самом деле, и не упускаем ли мы, говоря про IOPS-ы, нечто важное из виду? Насколько полнятие IOPS является однозначно идентифицируемым и можно ли показатели “в IOPS” трактовать однозначно, и сравнивать различные результаты, различных вендоров между собой?

IOPS: Возможно наиболее известный показатель производительности системы хранения.

IOPS означает Input/Output (operations) Per Second, "операций ввода-вывода в секунду". Смысл величины выглядит довольно очевидно. Он измеряет объем работы за определенный промежуток времени (и это не то же самое, что мегабайты в секунду, MB/s).

Кто из вас не видел вендоров, которые превозносят достоинства своих систем хранения, демонстрируя огромные величины IOPS ими достигнутые? Кто из вас не принимал решения покупки системы хранения, основываясь на обещаниях вендорами этих величин? Однако: как часто вендоры, приводя свои результаты, в действительности четко определяли то, что они понимали под аббревиатурой "IOPS", публикуя эти результаты?

Для нетерпеливых, скажу это с самого начала: Величина IOPS сама по себе бессмысленна, и именно так и должна рассматриваться. Без дополнительных метрик, таких как latency, процентное соотношение операций чтения и записи и размера блоков ввода-вывода, величина IOPS совершенно бесполезна.

А теперь подробнее…

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

Политики кэширования чтения на Flash Pool

В предыдущем посте я показал, как создать и начать использовать гибридный aggregate (flash pool) с использованием дисков SATA для хранения, и SSD для кэширования обращения.
Но aggregate может содержать на себе множество томов, и, часто, разные тома потребуют разных режимов использования. Flash Pool конечно имеет возможности индивидуальной настройки параметров кэширования для тома. Делается это так:
С помощью команды priority можно указать следующие варианты политик кэширования чтения:

  • read-cache = none - эта политика отключает кэширование чтения для данного тома вовсе. Например мы хотим сэкономить место в кэше для более ценных данных, или чтение с этого тома редкое и длинными последовательными кусками, затем не перечитываемых повторно, и их кэширование просто непроизводительно замусорит кэш.
  • read-cache = meta - эта политика кэширует операции чтения метаданных. Такая политика полезна для томов, на которых значительную часть операций составляют операции чтения метаданных. Например это операции с большим количеством сканирований директорий со значительным количеством (сотни и тысячи) файлов, поиска и выбора среди них.
    Операции чтения метаданных довольно затратны, так как представляют из себя рандомное чтение мелкими блоками, и кэширование таких операций очень эффективно (и при этом может не занимать больших объемов в кэше).
  • read-cache = random-read - эта политика, что очевидно из названия, кэширует операции чтения, идущие в произвольном порядке. Причем кэшируются ?? метаданные, ?? собственно данные одновременно. Эта политика как бы включает в себя предыдущую, но расширяет кэш и на собственно считываемые данные. Это политика по умолчанию. Если вы не переопределите ее, то действовать будет именно она. Обратите внимание, что ‘random’ означает, что sequental-операции будут исключены из операций кэширования (оно и правильно).
  • read-cache = random-read-write - несколько парадоксальным образом эта политика считается политикой кэширования чтения. С ее использованием к кэшированию операций чтения добавляется новый для NetApp процесс кэширования операций записи. Впрочем, о политиках по кэшированию операций записи мы поговорим в одном из следующих постов.

Командная строка настройки политик кэширования для тома выглядит так:
priority hybrid-cache set <volume name> read-cache=<value> write-сache=<value>

Создание Flash Pool

С выходом Data ONTAP 8.1.1 (сейчас он, для самых нетерпеливых, находится в состоянии Release Candidate) появляется долгожданная фича под названием Flash Pool (он же, ранее, Hybrid Aggregate)

??так, давайте посмотрим, как можно создать Flash Pool, то есть aggregate с дополнительными дисками SSD для кэширования данных.
Создадим для начала простой aggregate:

fas01> aggr create flashpool -B 64 -t raid_dp -T SATA -r 16 16

??мя aggregate: flashpool, формат: 64-bit, тип RAID: RAID-DP, тип дисков: SATA, размер RAID: 16

После успешного создания aggregate по имени ‘flashpool’ разрешим на нем собственно flashpool:

fas01> aggr options flashpool hybrid_enabled on

Несмотря на то, что коммерческое название фичи было изменено в релизе с ‘hybrid aggregate’ на ‘flash pool’, опция по прежнему называется ‘hybrid’. Аналогично с дедупликацией, которая когда-то называлась A-SIS (Advanced Single Instance Storage), и до сих пор так называется соответствующая опция в параметрах.

Теперь можно добавить к aggregate диски SSD в количестве 6 штук:

fas01> aggr add flashpool -T SSD 6

??з 6 штук два будет забрано под RAID parity (RAID-DP), а оставшиеся 4 - будут использованы как кэш. Обратите внимание, что сам aggregate не увеличится в емкости хранения! Добавленные SSD недоступны для непосредственного использования и записи на них данных, они будут использованы как кэш.

А теперь просто создадим на получившемся aggregate том (myvol) для хранения данных, емкостью 500GB:

fas01> vol create myvol flashpool 500g

Теперь получившийся том myvol, размером 500GB, можно использовать под данные, причем записываемые и считываемые данные будут автоматически использовать кэш на SSD.
В следующем посте мы посмотрим, какие средства есть для тонкой настройки режимов кэширования томов на Flash Pool.

Про настройку NetApp – новый блог

К пользующимся у меня тут, судя по вебсатистике, бешеным спросом статьям о начальном запуске и настройке новых систем NetApp (часть 1 и часть 2), в закладки админу добавились в интернете новые тексты:

Настройка NetApp FAS – Часть 1 

(Описание контроллера FAS2040, возврат к заводским настройкам, базовая настройка файлера, настройка BMC, обновление Data ONTAP, NTP сервера).

Настройка NetApp FAS – Часть 2

  

(Multimode VIF и его виды, балансировка нагрузки, интерфейсы-партнер в кластере, псевдонимы aka IP Aliasing, flowcontrol и MTU, настройка Static и Dynamic VIF с  коммутатором Cisco Catalyst).

Настройка NetApp FAS – Часть 3

  

(disk ownership, raid group, aggregate, volume, qtree, lun).

Настройка NetApp FAS – Часть 4

  

(iSCSI, настройка iSCSI, безопасность iSCSI, iSNS)

Все это – в блоге http://twistedminds.ru.

Если вы интересуетесь темой, то сходите, посмотрите, может быть полезно. Автор раскрывает тему в несколько ином ключе, и пишет, например, гораздо больше о сетевых настройках и VIF, о которых я в своих постах “самого начала” не говорил (отчасти намеренно).

Ожидается продолжение. да и вообще заглядывайте туда, интересный ресурс.

UPD: Пока пост отстаивался в “отстойнике”, как это обчно и бывает с написанными мной текстами, автор удвоил количество своих постов на данную тему. Шоназывается “респект”.