пятница, 31 июля 2009 г.

Windows и teaming Broadcom

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

image

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

Наблюдения описанные здесь относятся к ОС windows 2003/2008. В общем случае все работает отлично. В определенных ситуациях бывает необходимо фиксированным образом задать все параметры сетевой карты, и отключить все что можно отключить (RSS, Offloading etc). Ниже картинка на которой, как раз таки, все отключено. При настройке имеет смысл повторять все как на скриншоте, за исключением строк “Locally administered address” и если у вас скорость не гигабит, задать её фиксировано.

[image[3].png]

В каких ситуациях могут начаться сложности? Если кроме тиминга на конкретных сетевых интерфейсах будут использоваться еще какие-то компоненты влияющие на трафик. К ним можно отнести: MS NLB, Failover Cluster, Hyper-v virtual свитч.

Практика показывает, что тиминг и Virtual Switch – живут нормально если отключить все ненужное (см скриншот выше).

С прочими комбинациями, необходимо проводить дополнительные проверки.

Документы описывающие тиминг от broadcom:
Виденье IBM для SystemX
BNT – Broadcom + BNT swithes
FAQ на сайте Broadcom, не только про teaming
Dell и teaming Broadcom
Офф сайт с драйверами и утилитой управления тимингом(BACS)

Читать дальше ...

четверг, 30 июля 2009 г.

Отказоустойчивость сетевых подключений в Windows 2008 server и Hyper-V

Для обеспечения отказоустойчивости сети, наиболее понятный путь – объединение нескольких интерфейсов в одну группу, в Linux  эта процедура называется бондинг, в Windows эта функция не заложена в ОС и требует дополнительных компонент для своей работы, компоненты эти предоставляются производителями сетевых карт. Соответственно сколько производителей сетевых карт, столько технологий объединения. Для меня представляет определенный интерес сетевые адаптеры broadcom, поскольку именно их встраивают в свои сервера все основные вендоры: IBM, HP, Dell, Fuji. Встраивают в основном карты NetXtreme I или II. Понятно что при необходимости можно добавить карты Intel, но зачастую это не позволяет сделать конструктив, к примеру в Blade системах, либо в другой ситуации оказываешься перед фактом – есть то железо которое есть. Как известно добавляют сетевые карты в сервера сверх встроенных – нечасто.

Итак о какой задаче пойдет речь – необходимо реализовать полную отказоустойчивость сервера на уровне локальной сети - 1GB Ethernet. При том, что сервер работает в кластере и используется для работы Microsoft hyper-v.

Зачем нужна отказоустойчивость сети

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

По большому счету платформа виртуализации представляет собой 3 больших блока – вычислительная часть, сетевая (I/O) и система хранения данных для виртуальных машин. Отказоустойчивость для вычислительной части на 100% процентов для х86 систем невозможна, к ней можно приблизиться путем создания Failover Cluster в Microsoft. С точки зрения отказоустойчивости системы хранения можно отметить что, отказоустойчивость самой системы рационально реализовать с помощью надежного конструктива собственно СХД и дублирования её компонент, к Microsoft и операционной системе это отношения не имеет. Отказоустойчивость путей подключения сервера к СХД реализуется с помощью встроенного в Windows 2008 MPIO либо с помощью ПО производителя СХД, тут тоже все работает без каких либо сложностей. Остается отказоустойчивость сети. Как я писал выше единственно возможный путь здесь – объединение карточек в одну группу и настройка отказоустойчивости канала в этой группе. В системах виртуализации Vmware и Citrix это встроенный функционал реализованный внутри самой системы, в Microsoft Hyper-V необходимо использовать сторонний софт. Как я писал выше я пытаюсь реализовать эту схему на сетевых картах Broadcom.

Реализация Broadcom

В ПО предлагаемом Broadcom есть 3 варианта организации Teaming:
1. Проприетарный вариант имени Broadcom. (называется - “SLB”)
2. LACP 802.11 ad
3. Generic Trunking

Несколько слов о том чем они отличаются:
1. Работает на уровне драйвера, поддержки от коммутатора не требует. теоретически в настройках есть два режима – балансировка и отказоустойчивость.
2. Требует поддержки от свитча соответствующей технологии.
3. Похоже на второй вариант, отличается жесткой организацией транка. (Более подробно в документации)

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

image
Настройки сетевой карты. В общем случае должно быть все также, только Locally Administered Address будет пустой. Это скриншот с уже собранного тиминга.

Первичная проверка и способ тестирования работы

Итак, чтобы с чего то можно было начать, был сделан самый просто вариант тиминга SLB из двух сетевых карт одна из которых была в режиме standby. То есть был собран самый просто режим отказоустойчивости. Эта процедура была проведена на двух серверах на которых стояла ОС w2008 server SP2 ent x64, на этих серверах был настроен hyper-v и оба они были в составе одного Failover Cluster. В кластере было 3 виртуальные машины, одна с домен контроллером для кластера и две с установленной 2008 Windows в качестве демо нагрузки. В обоих узлах кластера было по две сетевые карты broadcom BCM5708S NetExtreme II, версия драйвера 4.8.5.0, версия прошивки 4.6.0 на момент проверок это были наиболее актуальные версии взятые с сайта производителя.

Проверка осуществлялась следующим образом – на каждой из двух демо машин создавался скрипт с одной строкой “shutdown –s –t 40” этот скрипт ставился на выполнение после загрузки ОС на каждой виртуальной машине. Естественно обе машины были в кластере.

Что получалось таким образом? Виртуальная машина включалась, грузилась, а через 40 секунд выключалась. Кластерный сервис воспринимал это как аварию и включал эту виртуальную машину на другом сервере. Там происходило все с самого начала и машина опять выключалась.

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

Да, надо сказать о настройке самого кластера – в нем два узла-сервера, находящихся в одной подсети. В  качестве внешнего стораджа используется FC система, на ней хранятся виртуальные машины и кворум кластера. В кластере используется одна сеть вида 192.168.199.0/24 в этой подсети и находятся оба узла. Использование этой сети для кластера – разрешено. Режим работы кластера – “Node and Disk Majority”.

Результат первой проверки

После порядка 40 переключений ВМ, или около часа времени постоянных переключений виртуальных машин один из узлов вылетел в BSOD. В результате образовался minidump который был разобран и получен следующий результат:

C:\Users\admin\Desktop\kdfe>kdfe.cmd "teaming BASP Mini072909-01.dmp"
Analyzing "C:\Users\admin\Desktop\kdfe\teaming BASP Mini072909-01.dmp", please wait... Done.

Crash date:         Wed Jul 29 17:54:58.282 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

Эта стоп ошибка – описана в KB842465 если коротко – ошибка вычислений CPU. По большому счету показывает что произошла критическая ошибка в вычислениях.

Затем было произведено переконфигурение тиминга в режим LACP, сделаны нужные настройки на свитче куда включались интерфейсы и повторен тест, система упала в BSOD еще быстрее в результате был получен следующий minidump:

C:\Users\admin\Desktop\kdfe>kdfe.cmd LACP_Mini073009-05.dmp
Analyzing "C:\Users\admin\Desktop\kdfe\LACP_Mini073009-05.dmp", please wait... Done.

Crash date:         Thu Jul 30 14:01:32.501 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

ошибка полностью повторяет первую.

Здесь я чуть позже размещу ссылки на описание этой утилиты и её возможностей, а в следующем посте опишу свои злоключения с ней.

Читать дальше ...

среда, 29 июля 2009 г.

Supermicro 6026TT-IBXF

clip_image002

Новая платформа Supermicro 6026TT-IBXF.

clip_image004

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

image

Все модули вставлены вид сзади. У каждого модуля свои отдельные сеть, VGA, USB.

clip_image002[7]

Кнопки включения питания расположены для каждого сервера в отдельности.

image

Целиком вынутый модуль.

image

Все модули-сервера вынуты. В системе остались только вентиляторы и корзина с дисками.

clip_image005

Каждый модуль можно оснастить двумя высокопроизводительными процессорами Nehalem-EP. Ограничение для процессоров – термопакет, он не должен превышать 100W, но почти все процессоры удовлетворяют этому требованию.

clip_image010

На каждый модуль приходиться по 3 SATA диска. Этого достаточно для организации отказоустойчивого массива под систему. Жесткие диски связаны с конкретными модулями-серверами по слотам.

clip_image007

С памятью никаких необычных решений. Все штатно согласно функционалу чипсета, Intel 5500 (Tylersburg), 3 канала на процессор. На каждое лезвие максимально можно установить либо 48 Гб DDR3 ECC Registered DIMM, либо 24Гб Unbuffered. Частота 1333/1066/800 MHz.

clip_image008

В каждый модуль интегрирован IPMI, что упрощает управление сервером, позволяя полностью контролировать его через LAN. Так же на плате уже распаян Mellanox ConnectX DDR Infiniband 20Gbps Controller, наружу выведен разъем QSFP. Infiniband дает возможность организации быстрого интерконекта с низкой латентностью между серверами.

Все остальные решения совершенно стандартные для серверов на платформе Nehalem. За исключением использования в платформах с процессорами Nehalem-EP, моста ICH10R, в данном случае он используется для возможности собрать RAID массив.

clip_image012

Для тех кому не хватает дискового пространства или нужно что-то более производительное и надежное, каждый сервер оснащен PCI-E x16. Это позволяет  при необходимости установить дополнительные карточки для подключения массива по iSCSI или более дорогую FC, либо любую другую совместимую. Или все, что ваша душа пожелает, но карта должна иметь LP форм фактор.

clip_image014

Система вентиляции. Сразу за вентиляторами располагаются 2 сервера, друг над другом.

clip_image016

Сильно порадовало что все куллера больше не прикручены насмерть саморезами к железу. Все аккуратно сделано на резиновых фиксаторах, и с резиновыми прокладками. Это существенно уменьшает уровень шума и вибрацию.

clip_image018

Что касается питания в базовой комплектации модуль только 1 мощностью 1200W. Для избыточности нужно купить дополнительный.

clip_image020

Модуль для подключения двух БП. расположен в центре корпуса, между серверами-модулями.

clip_image022

Платформа в сборе с открытой крышкой. Под видимыми модулями-серверами располагается второй слой.

http://supermicro.com/products/system/2U/6026/SYS-6026TT-IBXF.cfm

Характеристики:

Four systems (nodes) in a 2U form factor. Each node supports the following:

1. Dual Intel® 5500 series Xeon® Quad/
    Dual-Core, with QPI up to 6.4 GT/s

2. Up to 48GB DDR3 1333/ 1066/ 800MHz
    ECC Registered DIMM

3. 1 (x16) PCI-E ( Low Profile)

4. Integrated IPMI 2.0 with KVM and
    Dedicated LAN

5. Mellanox ConnectX DDR Infiniband
    20Gbps Controller w/ QSFP connector

6. Intel® 82576 Dual-Port Gigabit
    Ethernet Controller

7. 3x Hot-swap SATA Drive Bays

8. 1200W Gold-level High-efficiency
   Power Supply

CPU
- Dual 1366-pin LGA Sockets
- Supports up to two Intel® 64-bit Xeon® processor(s) of the same type below:
      Quad-Core Intel®
      Xeon®Processor 5500 sequence (Nehalem-EP processor)

QPI
- up to 6.4 GT/s

System Memory (per Node)

Memory Capacity
- Twelve 240-pin DIMM sockets
- Supports up to 48 GB 1333 / 1066 / 800MHz DDR3 ECC Registered memory
- Memory Mirroring supported

Memory Type
- 1333 / 1066 / 800MHz Registered ECC DDR3 SDRAM 72-bit, 240-pin gold-plated DIMMs

DIMM Sizes
- 1GB, 2GB, 4GB

Memory Voltage
- 1.5 V

Height
3.5" (89mm)
Width
17.2" (437mm)
Depth
28.5" (724mm)
Gross Weight
85 lbs (38.6kg)

On-Board Devices (per Node)

Infiniband
- Mellanox ConnectX DDR Infiniband 20Gbps Controller

Chipset
- Intel® 5520 (Tylersburg) chipset
- ICH10R + IOH-36D

SATA
- Intel ICH10R SATA 3.0Gbps Controller
- RAID 0, 1, 5, 10 support

IPMI
- Support for Intelligent Platform Management Interface v.2.0
- IPMI 2.0 with virtual media over LAN and KVM-over-LAN support
- Winbond® WPCM450 BMC

Network Controllers
- Intel® 82576 Dual-Port Gigabit Ethernet Controller
- Supports 10BASE-T, 100BASE-TX, and 1000BASE-T, RJ45 output
- Intel® I/OAT 3 support for fast, scaleable, and reliable networking
- VMDq support for better performance of virtualization
- 1x Realtek RTL8201N PHY (dedicated IPMI)

Graphics
- Matrox G200eW 8 MB DDR2

Super I/O
- Winbond W83527HG chip

Clock Generator
- 932S421 chip

Input / Output
Serial ATA
- Six Serial ATA ports
- 3 SATA hard drives supported

LAN
- 2x RJ45 LAN ports
- 1x RJ45 Dedicated IPMI LAN port

USB
- 2 rear + 1 header (2 Ports)
- 4 total USB ports, 2.0 Compliant / 1.1 Compliant

VGA
- 1x VGA Port

Serial Port
- 1 Fast UART 16550 serial port

Infiniband
- 1 External QSFP Infiniband Connector

Отдельное спасибо Куликову Диме за помощь в подготовке.

Читать дальше ...

Лицензирование VMware vSphere

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

 Базовая страница про лицензии для VMware vSpehere. Upgrade/downgrade vi 3 etc.

VMware vSphere 4 Licensing guide – pdf.

PDF с полной таблицей всех функций и описанием в каких редакциях что есть. Зато очень подробно описан функционал того что есть в vSphere. Фактически – детальное сравнение редакций standart/advanced/enterprise/enterprise+. Ссылка.

Статья из KB VMware описывающая исключительно апгрейд с VI3 на vSphere. Ссылка.

Статья из KB VMware описывающая исключительно даунгрейд с vSphere на VI3. Ссылка.

Про Intel HT и лицензии на ядра – официального ответа не нашел. Есть тема на форуме VMware из неё можно сделать вывод, что HT за отдельное ядро не считается. Видимо точный ответ надо искать индивидуально в суппорте. Ссылка.

Читать дальше ...

воскресенье, 26 июля 2009 г.

DS3000 GUI vs CLI

Не секрет что системы IBM DS3000, DS4000, DS5000 производятся компанией LSI по заказу IBM, при этом прошивки систем очень похожи друг на друга. Они имеют схожую нумерацию версий, одинаковый синтаксис командной строки, управляются одним и тем же продуктом - IBM DS Storage Manager.

Системы DS4000 и DS5000 практически идентичны, с точки зрения функционала доступного из GUI DS Storage Manager. Они отличаются только эскизами самих систем (все-таки, внешне они разные) и количественными характеристиками. Другое дело отличия в GUI DS3000 и старших систем, так получается, что часть функционала имеющегося в системах DS3000 недоступна из GUI, при этом его можно задействовать через командную строку. С моей точки зрения там есть действительно нужные команды, которые могут серьезно облегчить жизнь инженеру обслуживающему данные системы. К примеру, команда расширения LUN, альтернатива ей из GUI нету.

Я думаю, что все функции не включены в GUI системы DS3000 по маркетинговым соображениям. Видимо с точки зрения IBM, если вам требуется что-то большее чем просто дисковая емкость, следует покупать системы старшего уровня

Я не буду перечислять все команды, которые доступны в системе, их можно найти в хелпе к DS Storage Manager, я же отмечу только то, что однозначно полезно знать и чем я сам неоднократно пользовался.

Самый простой способ инициировать выполнение скрипта системой – открыть DS staroge manager, щелкунть по требуемой системе правой клавишей и выбрать из контекстного меню “Execute Script”. В открывшемся окне пишем код и жмем по необходимости Verify или Execute.

Теперь непосредственно сами команды:

1. Добавление дисков к уже существующему массиву можно выполнить из GUI но добавлять можно только по одному диску (по два для RAID10), через консоль же можно добавлять по два диска и для RAID 5/6. Учитывая то, что каждый шаг расширения может достигать нескольких часов, консоль в случае расширения RAID 5/6 уменьшит количество итераций в 2 раза.

Синтаксис:
set array [tst] addDrives=(0,9 0,10);
здесь “tst” имя array, диски адресуются по принципу «номер полки запятая номер диска», между дисками ставится пробел.

2. Если у Вас на Array находится несколько LUN и Вы удаляете не последний на его месте образуется «пусто место». Это пустое место будет доступно для того чтобы сделать на его месте один или несколько LUN, но если вы хотите использовать это место для создания большого луна, тоесть использовать его вместе с другим пустым местом – ничего не получится. Поскольку можно создать LUN только на пустом месте идущем «одним куском». Помогает вынести все свободное место в конец массива команда дефрагментации. В GUI её нет.

Синтаксис:
start array [tst] defragment;
здесь “tst” имя array

3. После создания LUN зачастую оказывается, что места было мало и необходимо предоставить больший объем. В GUI DS3000 не умеют расширять LUN, то есть предполагается, что мы создаем новый LUN, копируем на него данные и потом меняем старый на новый LUN. Понятно что такая процедура очень сложна и требует на одной системе места и под старый LUN и под новый, либо стороннего дискового пространства. Ну и в момент переноса данные будут недоступны по понятным причинам. В консоли же есть штатная команда для расширения, процесс займет какое-то время (в зависимости от размера LUN), но работа с данными не будет прервана и после окончания ОС просто обнаружит пустое место на диске (так будет в ОС Windows 2003/2008).

Синтаксис:
set logicalDrive ["tstlun"] addCapacity= 1 GB;
Здесь “testlun” имя LUN, вместо GB могут быть MB. Не забудьте пробел после цифры.

4. Можно изменить размер сегмента LUN. Целесообразность – тема отдельная, но в GUI этой функции нету.

Синтаксис:
set logicalDrive ["tstlun"] segmentSize = 256;
Здесь “testlun” имя LUN, цифра размер сегмента в kb.

5. В системе можно изменить настройки кэширования для отдельного LUN. Чтобы понять что отвечает за что – нужно читать Redbook.

Синтаксис:
set logicalDrive ["tstlun"] cacheFlushModifier=cacheFlushModifierValue cacheWithoutBatteryEnabled=(TRUE | FALSE) mirrorCacheEnabled=(TRUE | FALSE) readCacheEnabled=(TRUE | FALSE) writeCacheEnabled=(TRUE | FALSE) cacheReadPrefetch=(TRUE | FALSE);
Здесь “testlun” имя LUN, варианты представлены в скобках.

6. Можно изменить размер блока КЭШа. С моей точки зрения надо ставить 16 kb.

Синтаксис:
set storageSubsystem cacheBlockSize=16;

7. Можно изменить настройки работы КЭШа.

Синтаксис:
set storageSubsystem cacheFlushStart=80 cacheFlushStop=80;
Для понимание что это – Redbook. Best Practice – 80 оба значения.

8. Можно снять с системы результаты производительности. С моей точки зрения результаты могут быть чрезвычайно полезны.

Синтаксис:
set session performanceMonitorInterval=10 performanceMonitorIterations=10;
save storageSubsystem performanceStats file="C:\perf.txt";
Здесь в первой строке мы задаем время снятия изменений (одной итерации) и количество этих итераций. Во второй строке мы стартуем процесс снятия результатов и указываем, куда сохранять результаты.

9. Можно посмотреть статус текущей операции и процент её выполнение. В GUI система показывает, что она просто “Operation in prgoress” через CLI можно еще и получить точную информацию о проценте выполнения.

Синтаксис:
show logicalDrive[tstlun] actionProgress;
Здесь “testlun” имя LUN. Также можно использовать для создания скриптов где требуется дождаться что система свободна.

Информация по теме:
http://www.redbooks.ibm.com/abstracts/sg247065.html - RedBook IBM System Storage DS3000: Introduction and Implementation Guide

ftp://ftp.software.ibm.com/systems/support/bladecenter/gc52127502.pdf - IBM System Storage DS3000, DS4000, and DS5000 Command Line Interface and Script Commands Programming Guide

Читать дальше ...

четверг, 23 июля 2009 г.

IBM DS3400 размер блока массива R10 и размер блока кэша системы

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

Что такое вообще размер сегмента, segment size в терминологии IBM? В DS3000/4000 это размер данных, который должен быть записан на диск или прочитан с диска, перед тем, как система продолжит запись/чтение на следующий диск.

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

В чистой теории максимальная производительность достигается тогда, когда размер страйпа диска максимально приближен к размеру IO которым система создающая нагрузку взаимодействует с самой системой. С другой стороны все рекомендации производителей дисковых систем сводятся к тому, что нужно выбирать размер страйпа для массива по умолчанию, что фактически означает прямую зависимость оптимизации кода прошивки контроллера под конкретный размер страйпа массива. В 3400 системе по умолчанию это 128кб, для медиа контента (большие файлы) предлагается блок 256кб. Вообще размер этого самого страйпа может меняться шагами 16-32-64-128-256-512 кб.

В руководстве IBM дает только 2 принципиальных рекомендации по размеру сегмента:
1. Для маленького IO размер сегмента массива должен быть равен или больше, чем размер IO.
2. Размер IO не обязательно должен совпадать с размером сегмента для достижения максимальной производительности.

Около полугода назад я ставил тест при повышении размера страйпа с 32 до 512 кб и замерами производительности и был изрядно удивлен тем, что на любом типе нагрузки максимальная скорость достигалась на размере сегмента 128 или 256 кб, даже на самых маленьких размерах IO. Сейчас я проделывал туже операцию на DS3400 сконцентрировавшись на 2-х размерах сегмента: 128кб (по умолчанию) и 256кб (предлагается системой для медиа нагрузки). Также я менял размер блока кэша системы с 4кб (по умолчанию) на 16кб, это максимальное значение для данной системы.

Управление размером кэша производится на уровне всей системы целиком и в DS3400 делается из консольной строки.

Тесты проводились на 2-х контроллерной системе DS3400 подключенной через FC свитч к 1 портовому FC HBA на сервере который создавал рабочую нагрузку. В каждом контроллере системы стоит по 512МБ кэша. Ниже представлены диаграммы на которых видно влияние тех или иных настроек на производительность системы.

Последовательное чтение

image image

image image

image image

image image

Из результатов видно, что изменяемые характеристики не имею сильного влияния на производительность, ясно видно что система быстро доходит до порога 400 мб/сек, ограничения сервера с одним HBA адаптером и перестает расти. На меньших скоростях видно, что в точке, где размер IO совпадает с размером блока кэша достигает повышение производительности относительно соседних результатов.

Последовательная запись

image image

image image

image image

image image

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

Случайное чтение

image image

image image

image image

image image

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

Случайная запись

image image

image image

image image

image image

Видно, что на маленьком блоке IO значения практически не влияют на IOPS, а на большом чуть быстрее оказывается 16кб блок кэша, 256кб размер сегмента.

Смешанная нагрузка (33% чтение), 100% случайная

image image

image image

image image

image image

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

Какие можно сделать выводы?

1. я думаю что в любом случае стоит ставить размер блока кэша системы в 16кб. Поскольку система DS3000 не обладает таким уж быстрым контроллером и не предполагает того, что на неё будут падать десятки тысячи мелких IO в секунду от какой нибудь высоконагруженной БД, кэш будет использоваться нерационально не так уж и часто. Синтетические тесты показывают, что и на маленьком размере блока система не проседает. Изменение размера блока  кэша на DS3000 делается командой “set storageSubsystem cacheBlockSize= XX KB;”, где ХХ – размер нового блока. Процедура выполняется мгновенно и применяется ко всей системе.

2. Скорее всего рационально использовать размер сегмента не в 128Кб, по умолчанию, а в 256кб. Я думаю что при реальной нагрузке это как минимум не снизит производительность работы, но вероятно и повысит её в определенных ситуациях. Скорее всего размер сегмента в 128кб по умолчанию сложился исторически с ранних версий прошивок системы.
Изменение размера сегмента для уже созданного луна возможно из командной строки, командой “set logicalDrive  ["logicalDriveName"] segmentSize= XX KB ;”, нужно учитывать, что процедура выполняется тем медленее, чем больше размер LUN’а к которой она применяется и чем больше система нагружена, процесс запросто может идти несколько часов. При этом процедура не отменяема и относится к монопольным, и если к примеру в момент перестройки понадобиться переконфигурить еще что ни будь, это не удастся сделать до окончания изменения размера сегмента. Процедура не прерывает доступ к информации в момент своей работы.

Книжка по теме:
http://www.redbooks.ibm.com/abstracts/sg246363.html?Open - DS4000 Best Practices and Performance Tuning Guide

Читать дальше ...