Archive for октября 2012

Новости конфигураций

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

В конфигураторе теперь есть диски SAS на 900GB для 2246 (2,5”, SFF). Ставятся только в полку 2246, в “голову” (2220 или 2240-2) не ставятся (или, по крайней мере, конфигурато.

В “голову” 2240-4 появились интересные комплекты под Flash Pool: 6×100GB SSD + 18×1TB SATA и 6×100GB SSD + 18×3TB SATA. Такие же варианты есть и для полочных сетов в полку 4246, плюс к ним еще есть все варианты дисков SATA – 1, 2 и 3TB.

Из недоступных, по известным причинам, в России, появились диски NSE (со встроенным шифрованием) емкостью 3TB.

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

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

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

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

Надеюсь не нужно дополнительно объяснять, почему для современных многозадачных систем, для баз 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 ‘В последний раз о фрагментации файлов и производительности’ »

Замена “головы” в сторадже: LUN serial

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

Если у вас на сторадже используются SAN LUN-ы, то при замене “головы”, а если более точно, то при замене NVRAM (при замене контроллера обычно с ним также меняется и NVRAM (NVMEM), установленная внутри) у этих LUN изменится их SerialID. В ряде случаев это может озадачить использующие их хосты (например Windows Cluster изменяет при этом их signatures, и не может после поднять в онлайн). Поэтому было бы правильно, после замены контроллера, и до возвращения LUN-ов использующим их системам, вернуть им старые SerialID.

Если у вас LUN-ов всего несколько, то это можно сделать и вручную (главное не забыть). Но если их много, то встает вопрос автоматизации.

На сайте communities.netapp.com было найдено несколько вариантов такого скрипта. На Perl, на VBS, и в виде скрипта PowerShell.

NetApp ExpressPod

Фото с VMware World 2012 Europe

Это, как можно догадаться, вариант FlexPod, ориентированный на small/mid-size enterprise. NetApp утверждает, что FlexPod “classic” продается очень успешно, и за время его существования продано 1300 устройств (не считая возможных инсталляций, в которых FlexPod взять как дизайн, и собран “по частям”, по опубликованной спецификации, а не куплен “как продукт”), из них 400 только в Европе. Новая версия позволит воспользоваться достоинствами FlexPod и “коробочного решения” тем компаниям, которым “большая” версия была еще не по бюджету.

Как можно понять из фотографии, это FAS2240-2 или 2220 и сервера Cisco USC C-series, а также “сетевое ядро” с использованием коммутатора Cisco Nexus 3048.

Также любопытно, что validated design FlexPod был расширен, и теперь включает в себя такие интересные области, как использование с Oracle RAC в виртуализованной среде, а также для Private Cloud под VMware vSphere с NetApp в Cluster-mode.

Data ONTAP Edge-T

Совсем немного времени прошло с момтента выпуска Data ONTAP Edge – “виртуального NetApp” в форме Virtual Appliance для VMware, как подоспел “апсайз”: Data ONTAP Edge-T.

Если кратко, то это расширенная и углубленная версия Edge:

Кк видите, теперь Edge может быть не только источником данных для SnapVault, но и получателем (в том числе для серверов с Open System SnapVault, под “обычными” OS), поддерживает репликацию SnapMirror. Остальные параметры остались без изменений.

Если вы уже интересовались ценами на Edge, то уже, наверняка были удивлены фактом того, что Edge продается в одном варианте - паком на 10 лицензий (UPD: с сентября можно купить поштучно). То есть нацелен он, прежде всего, на множественные филиалы, но цена, из-за за 10 штук, получилась не очень интересной тем, кому хочется купить и использовать всего один-два. Ждем более интересной и подходящей ценовой политики от Edge-T.

Берут “на попробовать” по-прежнему там: http://www.netapp.com/data-ontap-edge-eval

Замена “головы” в сторадже: 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 (отдельно, или в составе контроллера целиком), о которой поговорим в четверг.

Радикальное ускорение работы NetApp System Manager 2.x

Если вы, как и я ранее, мучаетесь от совершенно запредельно ннизкой скорости работы NetApp System Manager 2.x, основного ныне инструмента администрирования NetApp, то радикально ускорить его поможет вам способ, порекомендованный в нашем форуме (если вы еще не там – настоятельно приглашаю, ссылка в шапке блога):

По видимому причина тормозов – в крайне кривом разрешении хостнейма в IP в Java при работе через DNS, поэтому добавьте соответствие имен контроллеров и их IP в локальный файл hosts. Таким доисторическим приемом вы, на глаз, в десятки раз увеличите скорость работы, открытия панелей и их обновления.

Data ONTAP 8.1.x 7-mode Cookbook

В этом блоге я уже как-то рассказывал про прекрасный документ, под названием Data ONTAP Cookbook. Словом “Cookbook”, или, по русски, “поваренной книгой” обычно в IT называют сборники “рецептов”, как сделать то-то и то-то. Крайне полезные документы с пошаговыми инструкциями “как”: настроить экспорты NFS и поддержку для NFSv4, изменить размеры тома, провести траблшутинг проблем подключения клиента по CIFS, настроить репликацию между системами, включить и настроить компрессию, настроить BMC или RLM, подключить LUN по iSCSI, и так далее.
Раньше подобный Cookbook был выпущен для Data ONTAP 7.x, и многие им пользовались, как “настольной книгой админа”, а вот теперь у нас есть и версия для Data ONTAP 8.x 7-mode.

Если вы по каким-то этическим причинам не имеете логина на communities.netapp.com, необходимого для скачивания оттуда кукбуков по приведенным выше ссылкам, то можете взять версию на момент публикации отсюда:
https://www.box.com/s/jdvkjmtqns1i5xuhnaxc
https://www.box.com/s/qzxdsyc0g3fi4znlrf8a

Ну и, пользуясь случаем, напоминаю, что NetApp Innovation 2012 в Москве - послезавтра!

18/0.164

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.