Intel SSD x25-e и Intel RAID RS2BL080

Продолжая тему SSD и их работы в RAID, надо отметить что пока что (на мой взгляд) не было контроллера который давал адекватную производительность во всех ситуациях с SSD. Также большой головной болью было то, что при отключении КЭШа SSD дисков производительность системы значительно падала, тогда как его требуется выключать для создания отказоустойчивых конфигураций.

Вот и получается – хочется чтобы все работало быстро, включай КЭШ диска. Но если вдруг выключиться электричество или будет еще какой сбой, все данные находящиеся в этом КЭШе потеряются. С другой стороны выключая КЭШ мы получали просадку по производительности (подробнее можно посмотреть в предыдущем материале про SSD и контроллеры LSI).

Теперь непосредственно, что привело к написанию этого материала. Intel любезно предоставил нам в тест контроллер Intel RAID RS2BL080, который интересен тем, что он рассчитан на 6ГБ SAS (обратная совместимость с SAS 3GB и SATA присутствует), в результате чего имеет полностью переработанную архитектуру. Для начала мы решили посмотреть контроллер в работе с SSD, чтобы посмотреть на что он способен при максимально быстром back-end (дисках), результаты тестов и будут представлены ниже.

Контроллер Intel RAID RS2BL080

Intel RAID RS2BL080 он же LSI MegaRAID 9260-8i

Строго говоря контроллер произведен компанией LSI, Intel же OEMит их. В контроллере 8 портов 6Gb/s SATA/SAS, 512МБ памяти и процессор LSISAS2108 (6Gb/s RAID-on-Chip - 800MHz PowerPC). Выглядит вполне обычно.

Судя по маркетингу LSI максимальная пропускная способность чтения около 2,9ГБ/сек, а записи 1,8ГБ/сек.

Описание на сайте Intel.
Спецификация на сайте Intel.
Спецификация на сайте LSI.

Тесты с SSD

Было решено в первую очередь проверить две разные конфигурации:

1. 8 штук SSD Intel x25-e в RAID 5, КЭШ контроллера включен, КЭШ дисков выключен. Общий смысл данного теста был посмотреть, как себя покажет конфигурация собранная из расчета компромиссного соотношения цена/объем. Также немаловажно и то, что КЭШ дисков был отключен, в реальную работу не стоит ставить диски с включенным КЭШ, слишком велики риски потери информации.

2. 8 штук SSD Intel x25-e в RAID 10, КЭШ контроллера включен, КЭШ дисков выключен. Также было решено проверить R10 для оценки разницы в производительности относительно R5.

Ниже представлены скриншоты настроек.
Тест делался по обычной схеме с Iometer’ом.

Настройки для теста в R5

Настройки для теста в R10

Результаты

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

Raid5

Raid10

Чрезвычайно впечатляющее начало 160 000 IOPS на чтение, эти цифры соизмеримы с характеристиками производительности дисковых систем среднего уровня. С той лишь разницей, что на дисковой системе с обычными дисками, таких цифр можно достичь только из чистого КЭШа, а здесь эти цифры получены на LUN в 200GB. Фактически этот результат показывает производительность контроллера, для сравнения LSI 84016E давал в пике около 40 000 IOPS, Adaptec 5805 около 50 000 IOPS, здесь же мы получили 160 000 IOPS на маленьком блоке. Очень круто. Руки чешутся протестировать на нем обычный SAS, чтобы понять даст ли такой контроллер роста производительности с обычными дисками.

Кстати кроме IOPS не менее интересно что контроллер достиг уже 1200 МБ/сек. У предыдущего LSI этот потолок был около 800МБ/сек.

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

Raid5

 

Raid10

Результат очень достойный, для полностью случайной нагрузки также отличный результат. Тот же потолок в 1200 МБ/сек, достигается здесь несколько позже чем при последовательном чтении, что в общем естественно. Для сравнения IOPS у LSI 84016E было примерно столько же, у Adaptec 5805 в Raid5 чуть больше (правда с включенным КЭШ дисков .) ).

Отличные результаты, на уровне лучших что я видел для такого количества SSD при такой нагрузке.

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

Raid5

 

Raid10

 

Исключительные результаты, видно что контроллер работает по максимуму и вычислительной мощности ему хватает с лихвой. При всем при этом, что интересно в RAID 5 контроллер пробил планку в 1200МБ/сек и уперся уже в 1400МБ/сек. В RAID 10 такого не наблюдается, видимо по причине меньшего количества конечных дисков на которые ведется запись. Тест опять же наглядно показывает что подопытный контроллер чрезвычайно мощный.

Что интересно, так называемого, RAID 5 penalty не наблюдается. По идее мы должны были бы видеть некоторую просадку по производительности в RAID 5 , относительно RAID 10.

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

Raid5

 

Raid10

Левая часть графиков где отражены IOPS соответствует высоким ожиданиям, динамика графиков с точностью повторяет такую в предыдущих тестах, результаты получаются лучше чем и у LSI 84016E и у Adaptec 5805. Adaptec 5805 проигрывает где то около 20% в RAID5 и около 30% в RAID10, LSI 84016E проигрывает около 20% в RAID10 результатов эквивалентных тестов в RAID5 у меня нету.

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

Также надо отметить, что есть подозрение что такое поведение массива обязано больше не контроллеру а дискам и их собственным алгоритмам записи и выстраивания очереди. Любопытно посмотреть аналогичные результаты при включеном КЭШ дисков (собственно именно эти тесты сейчас у нас и идут).

33% чтение, 100% случайные операции.

Raid5

 

Raid10

 

Комментировать особенно нечего, случайная запись задает тон результатам. Они в точности повторяют динамику случайной записи.

Типовые профили

Raid5

Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	ART (ms)	ART-read (ms)	ART-write (ms)
File Server	7 938,72	6 349,31	1 589,41	85,82	68,62	17,20	4,03	4,78	1,04
Web Server	15 791,47	15 791,47	0,00	242,30	242,30	0,00	2,03	2,03	0,00

Raid10

Access Specification Name	IOps	Read IOps	Write IOps	MBps	Read MBps	Write MBps	ART (ms)	ART-read (ms)	ART-write (ms)
File Server	17 184,08	13 750,53	3 433,55	185,72	148,68	37,04	1,86	2,02	1,21
Web Server	20 511,35	20 511,35	0,00	313,48	313,48	0,00	1,56	1,56	0,00

В качестве сравнительной шкалы приведены результаты двух типовых тестов, отметить хочется то, что при очень высоких результатах время ответа (ART) сохраняется на рекордно низком уровне 1-4 ms. В этих же результатах видно что RAID 10 благодаря более высоким результатам на записи показывает лучшие результаты.

Выводы

Что хочется сказать в итоге, контроллер судя по этим результатам получился исключительно мощный, руки чешутся сделать тесты на 15k SAS дисках (я думаю сделаем на следующей неделе), вероятно контроллер и на них даст лучшую производительность чем его текущие конкуренты (тот же Adaptec 5805).

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

Доступность и стоимость контроллера пока не ясна, как я уже писал выше, нам он достался в единственном экземпляре и реальных цен в РФ я не видел. Судя по всему он должен быть в одной ценовой группе с Adaptec 5805 и аналогичными 8 портовыми LSI.

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

Для владельцев CLARiiON, использующих iSCSI и vSphere

Если Вы используете iSCSI на EMC CLARiiON для подключения к vSphere и испытываете проблемы с производительностью, то проблема в том, что кларионы идентифицирует iSCSI сессию только по IQN, что вызывает многочисленные log-in/log-off и заметно снижает скорость. Более подробное описание проблемы и, что более важно, ее временное решение (до исправления FLARE) находится тут.

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

Обновления NetApp

 

Новости, правда, уже пару дней как отшумели, но раньше что-то не доходили руки :)

Объявлено о выходе 8й версии ONTAP, ключевая особенность – наконец состоялось (худо-бедно) слияние “классической” версии и ONTAP GX. Слияние обещали уже лет 5, но вот теперь оно свершилось. Почему “худо-бедно”? Несмотря на то, что ONTAP теперь один, все равно приходится выбирать, как он будет работать – в “7 mode” или “claster mode”. Классический вариант 8ки практически эквивалентен версии 7.3.1, но из-за слияния {временно} лишен IPv6 и SnapLock. С другой стороны, появились 64бит агрегаты, что конечно будет на руку всем, кому было мало 16ТБ. Но и здесь не обошлось без ложки дегтя – для младших систем размер агрегата увеличился всего до 40ТБ, а максимальные 100ТБ можно получить только на старших 6070 и 6080 (из-за ограничений, вызванных объемом памяти). Смешение 32х битных (уже имеющихся) и 64х битных (новых) агрегатов может повлечь неприятные моменты – в частности, если Вы купили новую систему под Volume SnapMirror и сделали в ней 64х битные агрегаты, то снап-миррор работать не будет. Превратить один агрегат в другой без миграции данных на свободное место нельзя.

Вторая важная новость - NetApp начинает предлагать SAS полки для своих систем (всех, кроме самой младшей 2020). Полка сейчас только одна – DS4243, занимает 4U в стойке и может вмещать до 24х дисков SAS или SATA(если быть точнее, то заказать можно либо 12, либо 24 диска). Диски внутри полки могут быть только одного типа, поэтому поставить 12 SAS и 12 SATA дисков не получится.

Полка, как я понимаю, традиционно изготавливается на заводах Xyratex и очень сильно напоминает OneStor SP1424s, однако интерфейсные модули стоят другие и обеспечивают дополнительный канал управления через ethernet порт. Благодаря этому каналу можно управлять экспандером (перезагружать и т.п.), но нужно будет выделить один из портов ethernet на каждом контроллере под это дело (пока на новых системах не будет отдельного порта). Стекировать можно до 10 полок, получая до 240 дисков в стеке (нужно помнить, что количество дисков на систему не поменялось, поэтому для младших систем ограничения будут другие).

Также был анонсирован кэширующий модуль PAM II объемом 256ГБ и 512ГБ. Теперь для старших систем можно получить до 4ТБ кэша (чтения). Про него имеет писать с графиками и результатами тестов, соответственно, все это можно уже прочитать у самих нетаповцев.

Аппаратные обновления поддерживаются в ONTAP 7.3.3, которая ожидается в декабре 2009 (если я правильно помню). Также в этой версии будет возможность прозрачной миграции данных между системами с включенным MultiStore (для NFS и iSCSI) – NetApp Data Motion, приложения, при этом, не потребуется останавливать. Можно сказать, что это некий аналог Vmware Storage vMotion.

Все вышесказанное относится конечно и к IBM N series (анонсы должны быть чуть позднее).

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

Supermicro Super Server 6016GT-TF-TC2

Новая платформа от Supermicro с двумя видеокартами Nvidia “Tesla” не имеющими ни одного видеовыхода на двоих и используемыми только для расчетов.

Компания Super Micro представила новую 1U платформу SuperServer 6016GT-TF. В этой платформе возможна установка двух отдельных видеокарт в независимые слота PCIx16. В нашем случае это платформа SuperServer 6016GT-TF-TC2, в ней уже установлено 2 видеокарты Nvidia Tesla C1060, служащие для вычислений. Так же есть модель в которой установлены Nvidia Tesla M1060.

В основе платформы материнская плата X8DTG-DF. Материнская плата рассчитана на использование новых процессоров Intel Nehalem-EP (QPI до 6.4 GT/s) и памяти DDR3 (до 96GB 1333/ 1066/ 800MHz ECC Registered DIMM и до 24GB Unbuffered DIMM).

Функционал материнской платы стал уже почти стандартным. Чипсет Intel 5520 (Tylersburg), ICH10R + IOH-36D. ICH10R позволяет создать из SATA дисков RAID 0, 1, 5. Вообще-то он умеет делать и R10, но из трех дисков его не сделать.

Корзина рассчитана на 3 диска, блок питания так же выведен спереди, для оптимизации используемого пространства внутри платформы

Блок питания один, хотя и вынимается

Мощность блока питания – 1000W.

Есть один свободный порт PCI-E x4 выполненный в форм-факторе x16. В него можно установить Low Profile карточки расширения.

В платформе установлена двойная сетевая карта Intel® 82576 Dual-Port Gigabit Ethernet Controller, также в платформе интегрированный IPMI с поддержкой virtual media over LAN и KVM-over-LAN, а так же Dedicated LAN.

Перейдем к самому интересному. На фотографии одна из двух Nvidia Tesla находящихся в платформе и карточка Riser для её установки в шасси.

Как видно на фотографии видео карта не имеют видео выходов. Она предназначены только для расчетов.

Снизу карта закрыта массивным радиатором на который отводят тепло чипы памяти расположенные с внутренней стороны платы. В сумме на плате 4ГБ GDDR3.

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

Спецификация видео карты:

Form Factor	10.5" x 4.376", Dual Slot
# of Tesla GPUs	1
# of Streaming Processor Cores	240
Frequency of processor cores	1.3 GHz
Single Precision floating point performance (peak)	933
Double Precision floating point performance (peak)	78
Floating Point Precision	IEEE 754 single & double
Total Dedicated Memory	4 GB GDDR3
Memory Speed	800MHz
Memory Interface	512-bit
Memory Bandwidth	102 GB/sec
Max Power Consumption	187.8 W
System Interface	PCIe x16
Auxiliary Power Connectors	6-pin & 8-pin
Thermal Solution	Active fan sink

Очень хорошо выполнено охлаждение всей системы. Четыре вентилятора охлаждают процессоры и память.

По два вентилятора охлаждают каждую видеокарту. Нагнетаемый ими воздух попадает прямо в систему охлаждения видеокарты.

Полная спецификация видеокарты:
http://www.nvidia.com/docs/IO/43395/BD-04111-001_v05.pdf

Полная спецификация платформы:
http://www.supermicro.com/products/system/1U/6016/SYS-6016GT-TF.cfm?GPU=TC2

Позже, надеюсь, мы опубликуем расчетный тест выполненный на GPU и сможем посмотреть эффективность GPU против CPU на данной платформе.

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

IBM DS5020 приходит на смену “старичку” DS4700

Дисковая система IBM DS4700 уже несколько лет является боевой лошадкой для тех, кому нужна довольно производительная и расширяемая СХД среднего класса не с заоблачной ценой. Но вот и пора на покой – на смену приходит новый игрок – IBM DS5020. Анонс, традиционно, датирован вторником (сегодняшним числом).

Что же нас ждет? Неожиданных новостей не будет – практически все уже видели у “старшего брата” – DS5100/5300. В базе система DS5020 оснащена 4мя портами FC 8Gbit (по два на каждый контроллер). При желании, можно дополнительно установить либо еще 4 порта FC 8Gbit, либо 4 порта iSCSI 1Gbit. Это избавляет нас от необходимости использовать отдельные (и требующие соответствующей настройки) iSCSI-гейты для подключения серверов, которым нет особой нужды в FC. Диски поддерживаются SATA (750GB и 1TB) , FC (146/300/450GB 15k) и FDE (с поддержкой шифрования – 146/300/450GB 15k). Поддержка SSD осталась в старшей серии, что наверное логично (в первую очередь из-за цены SSD – уж если есть бюджет на них, то и на DS5300 можно найти). В плане кэша также есть выбор – 2 или 4GB на систему. Т.е. хотя и разграничения по моделям и нет, но “болезненный” выбор необходимых опций при начальном заказе остался - дополнительные порты и расширение кэша доступны только при изначальном заказе, но не как апгрейд. Одно из новшеств DS5100/5300, перекочевавшее в DS5020, состоит в том, что защита кэш памяти не ограничивается установкой батарей, а при отключении питания происходит “сброс” содержимого кэша на флэш-память, что обеспечивает защиту кэша даже при долговременном отключении системы (или при неполной зарядке батарей). В контроллерной полке, как и в DS4700 можно установить до 16-ти дисков, а вся система расширяется до 112 дисков. Полки расширения используются новые EXP520, но и “старые” EXP810 также можно подключить (правда требуется соответствующая лицензия). Бэкэнд остался 4х гигабитным. Но исчезла лицензия, позволяющая смешивать в одной системе FC и SATA диски – теперь это можно делать совершенно спокойно (диски, как и прежде, можно “смешивать” по собственному желанию, без каких либо ограничений). Кроме того, добавление первой EXP520 не требует никаких лицензий. Лицензируется подключение дисков с 33 по 64го, при подключении более 64х дисков потребуется еще одна лицензия. Минимальное число Storage Partitions, как и прежде, 2 и расширяется до 128ми степенями двойки (4, 8, 16, 32, 64, 128). Вот собственно и все новости – внешне система практически не отличается от DS4700 (спереди только надписью, а сзади – небольшим внешним отличием контроллеров).

Основные характеристики по сравнению с DS4700 мало изменились: поддерживаются RAID1,3,5,10,6; в одной RAID-группе RAID10 можно использовать до 112 дисков, в остальных типах RAID – до 30ти дисков; поддерживаются такие возможности как создание мгновенных снимков (FlashCopy), клонов (VolumeCopy) и репликация на удаленный массив (Enhanced Remote Mirroring). Производительность системы заметно увеличена (результаты пока официально не опубликованы, но обещают до 50% прироста). Фактически, получили новую “рабочую лошадь” взамен старой.

А что же все-таки не получили, хотя было бы очень полезно? Есть и такое:

• установка дополнительных портов по мере необходимости (EMC вон уже давно это умеет);
• расширение кэша как апгрейд;
• поддержка SSD – не больно и хотелось, а, положа руку на сердце, и не нужно (с технической точки зрения), но “толпа жаждет”;
• расширение возможностей VolumeCopy и FlashCopy;
• FCoE – хотя и тоже пока не актуально, но тоже было бы громким шагом.

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

CNA - в массы … но пока еще не скоро.

Qlogic объявили о начале отгрузок второго поколения CNA адаптеров – серию 8100. Ключевые отличия – поддержка PCI-express x8 версии 2.0 и теперь вся реализация “упрятана” в единственный чип. Как следствие, карты получились очень экономичными по питанию – тепловыделение всего 7W . Заявлена производительность в 250.000 IOPs на порт (платы как одно-, так и двухпортовые). iSCSI поддерживается через программный инициатор, что несколько ограничивает применение на высоких скоростях (впрочем, для этого данные платы и не предназначены).

Подключение – через SFP+, а варианты поставки есть как без SFP+ модулей (для twin-ax кабелей), так и с модулями под SR и LR оптику. На текущий момент можно уже строить решение целиком под FCoE – коммутаторы Cisco Nexus 5000 (или Brocade 8000), дисковые системы от NetApp (или их аналоги - IBM N Series) уже сейчас можно заказать с FCoE интерфейсами (кроме того, имеющиеся FC системы можно подключить к коммутаторам в специально отведенные порты). Таким образом (если задаться целью), уже сейчас можно получить инфраструктуру завтрашнего дня. Однако, по различным оценкам (как аналитиков, так и самих заказчиков) реальных внедрений стоит ожидать в 2011-2012 годах.

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

Память DDR3 и процессоры Intel Xeon 5500 (nehalem)

Основные вопросы, на которые нужно ответить при выборе конфигурации памяти DDR3:

1. Нужно получить максимальный объём или максимальную производительность памяти?

2. Какие процессоры будут использоваться?

3. Какое соотношение цена/производительность для нас оптимальна?

Отличия в использовании DDR2 и DDR3

DDR2 и процессоры Intel Xeon 5400 - До 4 каналов - До 4 DIMM на канал - Память Fully-buffered DDR2 533/667/800 - Максимальный объем 128Гб	DDR3 и процессоры Intel Xeon 5500 - До 6 каналов - До 3 DIMM на канал - Память DDR3 800/1066/1333 - Максимальный объем 144Гб

Варианты конфигурирования

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

Максимальная производительность

Для обеспечения максимальной производительности необходимо использовать память DDR3 с частотой 1333MHz и процессоры серии X5550, т.к. только они способны обеспечить необходимую пропускную способность шины QPI (10,6 GB/s). Такая конфигурация накладывает ограничение на максимальный объем памяти в 48GB, т.к. возможно установить только 1 модуль памяти на 1 канал процессора.

Максимальная производительность

Максимальный объем

В этом случае необходима память с частотой 800MHz и любые процессоры серии X5500. Пропускная способность шины QPI при этом будет 6,4GB/s. При этом можно будет установить до 18 модулей памяти, то есть по 3 модуля на канал, и получить объем в 144GB.

Максимальный объем

 

Сбалансированный

Оптимальный вариант, межу производительностью и объемом. Необходимо использовать память DDR3 с частотой 1066 MHz, процессоры серии E5520 или старше. В такой конфигурации возможна установка по 2 модуля памяти на канал (всего 12 модулей) и получить общий объем памяти 96GB.

Сбалансированный вариант

Типы памяти

Но это не все. Кроме ранжирования по скорости MHz, есть 3 вида памяти DDR3: Registered DIMMs (RDIMM), Unbuffered ECC DIMMs (UDIMM ECC) и Unbuffered DIMMs (UDIMM). Сразу отмечу что Unbuffered DIMMs (UDIMM) не рекомендуется использовать в серверах. Так же модули памяти бывают разных рангов.

Сравнение UDIMM и RDIMM:

	UDIMM	RDIMM
Регистр/Буфер	Нет	Есть
Частоты	800, 1066, 1333 МГц	800, 1066, 1333 МГц
Количество рангов	1 или 2	1, 2 или 4
Максимальное кол-во модулей на канал	2	3
Объем модулей	1 и 2 Гб	1,2,4 и 8 Гб
ECC	Поддерживает	Поддерживает
SDDC	X8	X4 и X8
Четность адреса	Нет	Поддерживает
Энергопотребление	~5W	~5.75W

RDIMMs:: Хотя они на несколько процентов медленнее чем UDIMM, они позволяют получить больший общий объем памяти. Поддерживают до 3 DIMMs/канал.

UDIMM ECC: поддерживает все RAS функции RDIMM кроме x4 Single Device Data Correction (SDDC).

Для систем начального уровня с объемом ОЗУ 12Гб или меньше, целесообразно использовать UDIMM ECC, т.к. у них меньше стоимость. Регистровую память имеет смысл использовать в материнских платах, где по 3 слота на канал (на будущее расширение без выбрасывания старой памяти) или модули по 4ГБ.

Относительная стоимость модулей

Ранги (Single, Dual, Quad)

Не будем детально разбирать вопрос рангов. Остановимся на наиболее важных моментах. Итак, на рисунках наглядно показано основные отличия разноранговой памяти. Технологически, при производстве, дешевле размещать большее чипов на одном модуле, то есть изготавливать память типа quad rank.

Физическое устройство разноранговой памяти

Латентность QR модулей меньше, т.к. в них одновременно может быть открыто несколько страниц. Так же есть ограничение в 8 рангов на канал, т.е в один канал можно поставить только 2 QR модуля (у разных производителей, кол-во поддерживаемых рангов может отличаться в зависимости от модели материнской платы). На данный момент Quad Rank бывают только модули RDIMM.

Еще отмечу момент, что при установки памяти с разным количеством рангов, первыми устанавливаются QR модули, потом DR и SR.

Выбор модулей оптимального объема.

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

При использовании RDIMM-ов, возможны следующие конфигурации (при использовании 2х 4х ядерных процессоров Nehalem-EP)

 

В таблице представлены основные конфигурации памяти. Сначала в первой строке выбираем желаемый объем памяти на 1 ядро.
Во второй строчке указа общий объем памяти, который мы получим.
Далее ниже рассмотрены варианты с разным объемом каждого модуля. Красным выделены оптимальные конфигурации.

При использовании UDIMM-ов ECC (при использовании 2х 4х ядерных процессоров Nehalem-EP)

 

DDR3 UDIMMs ограничены 2 DIMMs на канал, или в общей сложности 12 DIMMs.
Принцип выбора тот же что и при RDIMM.

Баланс памяти по каналам в конфигурации

В таблицах есть не сбалансированные конфигурации. Не сбалансированной конфигурация считается, если не используются все 3 канала памяти на процессор или число модулей не кратно 3 модулям на процессор. Конфигурация, когда используется два канала из трех, можно считать сбалансированной, т.к. interleave работает, но только на 2 канала.

Так же возможна конфигурация, когда вся память находиться у одного процессора. Она возможна при использовании Non-Uniform Memory Access (NUMA).

 
Примеры несбалансированных конфигураций

Сбалансированная конфигурация: задействовано больше каналов, выше пропускная способность памяти.

· Пропускная способность одинакова при использовании 1 модуля памяти на канал и при использовании 2х модулей на канал (как на DDR3 1066)

Несбалансированная конфигурация: уменьшенная пропускная способность (до 17%)

· Не работает Interleave во всех 3х каналах

· Приводит к снижению пропускной способности на 2-1-1 против 1-1-1 конфигурации

Пропускная способность памяти. Сравнение сбалансированной и не сбалансированной конфигурации (DDR3 1066).

Разница в скорости на разных конфигурациях

Очень хорошо видна разница в пропускной способности памяти в разных режимах:

Memory Frequency (MHz)	DIMM Population (CPU 0 / CPU 1)	STREAM Triad Result 4.8GT/s QPI	STREAM Triad Result 5.86GT/s QPI	STREAM Triad Result 6.4GT/s QPI
Balanced Configs
1333	1-1-1 / 1-1-1	---	---	36,588
1066	1-1-1 / 1-1-1	---	31,218	33,723
1066	2-2-2 / 2-2-2	---	30,912	33,203
800	1-1-1 / 1-1-1	24,265	26,750	27,748
800	2-2-2 / 2-2-2	23,866	25,844	26,565
800	3-3-3 / 3-3-3	24,052	26,750	27,208
Unbalanced Configs
1066	2-2-0 / 2-2-0	---	25,343	---
1066	2-1-1 / 2-1-1	---	25,679	---
1066	2-2-2 / 2-2-2	---	30,912	---
800	2-2-0 / 2-2-0	---	19,510	---
800	2-1-1 / 2-1-1	---	19,961	---
800	2-2-2 / 2-2-2	---	25,884	---

 

RAS Features

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

Memory mirroring (Зеркалирование памяти):

• 2 канала памяти, в качестве зеркала (одна информация записывается на обоих каналах одновременно)
• Модули памяти должны быть одинаковые
• Полезный объем памяти равен 50%
• Повышение надежности (память избыточна)

Технология Lockstep

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

Lockstep mode

• 2 канала, работающих в lockstep (кэш линия разделяется между обоими каналами), 3 канал не используется.
• Модули памяти должны быть одинаковые
• Увеличение надежности, но низкая производительность

Примеры работы RAS features

Технология Intel® x4 Single Device Data Correction (x4 SDDC) обеспечивает обнаружение и исправление ошибок размером 1, 2, 3 или 4 бит данных в одном устройстве и обнаружение ошибок размером до 8 бит данных на двух устройствах.

Материал был сделан, большой частью, Куликовым Дмитрием, за что ему выражается отдельная благодарность!

Для написания статьи использованы материалы Intel:
Xeon 5500 Memory White Paper Intel® Xeon® processor 5500 Series Datasheet: (public)

http://www.intel.com/Assets/PDF/datasheet/321321.pdf (Volume 1)
http://www.intel.com/Assets/PDF/datasheet/321322.pdf (Volume 2)

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

IBM DS4700-70 проверка скорости работы КЭШа системы

Понятно что в любой дисковой системе, скорость работы КЭШа системы намного выше чем скорость работы дисков в этой системе. Обычно характеристик производительности дисковой системы в IOPS указываемые изготовителем в маркетинговых документов соответствуют скорости работы системы при максимально выгодной для неё нагрузке, чаще всего это последовательное чтение при удобном размере блока, близкого к размеру блока КЭШ памяти.

В информации по IBM DS 4700-70 заявленная производительность 112 000 IOPS, это я и попробую проверить в тестах. Также я буду смотреть на общее поведение системы при работе только на КЭШе.

Для такой задачи сперва было необходимо найти способ заставить систему работать только из КЭШ памяти. Как это было сделано я опишу ниже. Сначала несколько слов про схему кэш памяти в контроллере: в системе на каждый контроллер приходится по 1ГБ КЭШ памяти. По умолчанию используется полное зеркалирование КЭШ памяти контроллеров между собой, это необходимо для того чтобы в случае отказа одного контроллера система смогла переключить нагрузку на второй при этом не потеряв данные из КЭШа потерянного контроллера. У КЭШа есть две глобальные характеристики задающиеся на уровне всей системы: размер блока КЭШа и политика сброса содержимого КЭШа на диск.

Размер блока КЭШ памяти

Может выставляться значениями 4, 8, 16 кб. По умолчанию стоит по-моему 8кб. Я делал тест около полугода назад, проверяя отличия в производительности при разных значениях, у меня получилось что наилучшая скорость получается на блоке 16кб, независимо от типа нагрузки на систему. Посему в этот раз я тоже выставлю блок 16кб. Вполне вероятно, что в перспективе стоит попробовать уменьшить размер блока КЭШ и повторить тоже самое на 8кб.

Политика сброса КЭШа на диск

Когда размер данных в КЭШе превышает определенный порог он автоматически начинает скидываться на диск, пока не освободиться достаточно места в КЭШе. Эти два порога задаются в настройках системы. Если применить эти настройки к тестовой системе то это выглядит так: в ней 1ГБ КЭШ в каждом контроллере, 512МБ доступно для данных после вычета половины для зеркала.

Политика сброса КЭШ в тестовом случае выглядит так: начать сброс на диск – 95%; окончить сброс КЭШа на диск – 90%. Получается, что при заполнении 486МБ (95% от 512МБ) система начнет переписывать содержимое КЭШ на диск пока не останется заполненным 460МБ (90% от 512МБ) после этого система остановит переписывание и будет ждать того когда КЭШ опять заполнится до 486МБ.

В тестовой системе политика сброса КЭШ выбрана как описано выше, чтобы при маленьком LUN (для тестов делался LUN размером 200МБ) он мог быть полностью размещен в КЭШ и верхний порог для сброса КЭШ на диск был бы не достижим.

И еще надо уточнить один момент, в системе на политику сброса описанную выше накладывается еще политика сброса содержимого КЭШа по расписанию, с заданной частотой. Поскольку в тестовом случае это только мешает (мне было нужно свести влияние дисков к нулю) я отключил сброс КЭШа на диск по расписанию. Это делается через CLI следующей командой:

set logicalDrive ["lun2"] cacheFlushModifier= infinite ;

Такую процедуру я выполнил на обоих тестовых LUN.

Условия теста

На системе был создан массив из одного диска FC 15k 146GB, один диск выбрался специально, чтобы увидеть резкое понижение производительности если вдруг система начнет работать не через КЭШ а через диск. По большому счету тест планируется диского независимый поэтому количество значения не имеет. На массиве делалось два LUN по 200МБ, на них включался весь КЭШ, отключалось скидывание КЭШа на диск (см выше) и они назначались на разные контроллеры дисковой системы. Затем брался IOmeter и ставилась нагрузка, резульаты которой и записывались.

 
Настройки LUN.

 

 
Подключение дисковой системы к серверу.

 

Результаты

Чтение

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

Случайное

В обоих случаях на маленьком блоке цифры колеблются в районе 100 000 IOPS, случайность чтения оказывает минимальное влияние. Спад IOPS в районе 4кб блока вызван тем что сервер с нагрузкой подключен через один порт HBA, скорость у него 4ГБ. В данном случае меня это не напрягает, поскольку все цифры выше 4кб, превышают 400МБ/сек а это очень много. Поскольку график не падает, видно что система ведет себя отлично.

Надо отметить, что здесь показаны средние цифры за 5 минут работы, после проведения тестов внутренний монитор дисковой системы показал что максимальная скорость в IOPS составляла около 116 000 IOPS, то есть обещанная производителем скорость в 112 000 достигнута.

Запись

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

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

При последовательной записи картина похожая на ожидаемую, с той лишь оговоркой, что скорость снижается на большом блоке. Я стал думать почему так и пришел к выводу, что это связанно с количеством дисков в массиве. Все же скорость около 100МБ/сек очень напоминает скорость одного диска.

Специально для того чтобы можно было понять влияние дисков на запись в кэш, был проведен второй тест, в котором в массив был добавлен еще один диск (то есть массив стал состоять из двух дисков) и проведена такая же нагрузка. На нижнем графике видно, что динамика полностью прежняя, тогда как скорость на большом блоке поднялась примерно в два раза. Поскольку в системе изменилось только количество дисков, из этого прямо следует, что алгоритмы кэширования последовательной записи связаны с физическими дисками в системе и даже имея тестовый лун объемом меньше чем доступный КЭШ и отключив сброс на диск, система все равно будет писать IO в диски, при последовательной записи.

Очень интересно что порог перехода записи в диск разный в массивах из одного и из двух дисков. Видимо система имеет заложенный алгоритм который определяет когда начинать писать КЭШ в диск исходя из критериев: какие диски включены в массив и какого объема, какой размер блока, какова последовательность нагрузки.

Логика прослеживается абсолютно четкая – если мы пишем последовательно и блоком большого объема, то диск не будет здесь узким местом, он себя должен показать лучше, чем КЭШ. Это дает максимальные результаты в нормальных средах на реальной нагрузке, все же LUN объемом 200МБ на который последовательно пишут 45ГБ за 5 минут в реальности не будет существовать.

 

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

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

 
Случайная запись на 16 дисков

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

Поведение случайной записи получается существенно ниже чем последовательной, таким образом можно сказать что система кэширования при случайной записи наибольшим образом зависит от дисков, независимо от реального объема данных. Это сказывается даже на том, что при последовательной записи система больше ориентируется на КЭШ и в результате не достигает возможного потолка (в нашем случае 400 мб/сек), а при случайной записи система независимо от реального объема данных активно пишет их на диск и даже при полностью случайном характере нагрузки достигает потолка в 400мб/сек.

Выводы

1. Ну и собственно идеи о том, что было бы круто разместить все данные в КЭШ памяти и писать/читать из неё меня покинули, абсолютно очевидно что для последовательной записи объем КЭШа не будет играть большой роли и для достижения максимальных результатов не будет требоваться. Для случайной записи он играет еще меньшую роль.

Нужно добавить, что в ходе тестов было сделано несколько прицельных прогонов в которых я отключал зеркалирование КЭШ чтобы сориентироваться насколько это будет сильно влиять на производительность. Так вот влияние было порядка 2-3%, таким образом ответ на вопрос “снижает ли зеркалирование производительность?” – отрицательный. По результатам же этого теста можно сказать, что при нагрузках преимущественно записи длительное время, размер КЭШ не будет выполнять ключевую роль для общей производительности. Также нужно не забывать, что отключая зераклирование КЭШа мы теряем отказоустойчивость системы.

2. Система показала свою полную адекватность с точки зрения максимальной производительности работы из КЭШа, цифры заявлены в маркетинге – получены, остальные результаты выглядят реалистично.

 

Ну и в результате интересно посмотреть в подобном тесте влияние настроек блока КЭШа системы, в максимально нагружающей его конфигурации – 2 LUN по 200МБ на 16 дисках.

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