Сколько должно быть разъемов на контроллере?

Наболело! Чуть ли не каждый день вижу вопросы такого плана: “В сервер можно поставить 16 (24) жестких диска, а SAS RAID контроллер у меня только 8-ми (или того хуже 4х) портовый! Что мне делать? Это наверное ошибка в конфигурации?!”. Ну что на это можно сказать? Может быть это конечно и ошибка, но скорее всего нет. Как же так? А все очень просто: SAS это протокол последовательной передачи данных и поддерживающий коммутацию. Если Вам нужно к серверу подключить 7 рабочих станций, Вы же не ставите в сервер 7 сетевых карт, а используете коммутатор на 8 портов, который позволяет всем машинам получить доступ к серверу. Точно также и в данной ситуации: либо в самом корпусе (прямо на бэкплейне), либо в виде отдельной карты присутствует аналог этого самого коммутатора. Только в данном случае он называется SAS-экспандером и позволяет подключить к RAID контроллеру гораздо больше дисков, чем есть SAS линий на самом контроллере. Наиболее распространены экспандеры на базе чипов LSI: LSISASx28, LSISASx36 или LSISAS2x36 (для 6Gbps SAS). В частности, на бэкплейнах в корпусах Supermicro используются экспандеры именно LSI. Отдельные карты с экспандерами также существуют, например в России проще всего найти их среди продукции компании Chenbro.

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

Вот вроде бы и разобрались – для подключения 24х дисков вовсе не нужно 24 порта на контроллере, достаточно и 4х (так как обычно именно 4 SAS линии используется для соединения контроллера с экспандером). А используя контроллер с 4мя внутренними портами и 4мя внешними можно не только задействовать (при использовании экспандера все диски в сервере, но и обеспечить возможность дальнейшего увеличения дисковой подсистемы за счет добавления внешней дисковой полки (JBOD).

Но сразу возникает несколько новых вопросов: “А нужно ли использовать экспандер? Может быть он так замедляет работу, что от него надо отказаться? У меня целых 24 (а то и еще больше) диска подключено только по 4м линиям SAS – наверное это будет очень медленно?”.

Попробуем найти ответы. Начнем с конца: 4 SAS линии по 3Gbps дают в сумме 12Gbps, а это целых 1.5 Гига-байта в секунду. Можно ли реально достичь такой пропускной способности? В принципе можно, но (а) нужно помнить, что наверное с этим потоком нужно еще что-то делать, а не просто читать или писать и (б) дисков для этого потребуется (даже при благоприятном стечении обстоятельств) заметно больше десятка. А если учесть, что при типичной работе сервера запросы к дисковой подсистеме идут в значительной степени случайные, то полосы пропускания в 12Gbps оказывается вполне достаточно – можете проверить сами на любом своем сервере, запустив perfmon (под Windows) и посмотрев на трансфер с дисков во время работы. А что до возникновения дополнительных задержек при использовании экспандеров, то они конечно есть, но “поймать” (измерить) их Вам не удастся – настолько они малы по сравнению с задержками при обращении к жесткому диску. Есть и еще один аргумент, чтобы не бояться экспандеров – в RAID-контроллерах, где количество портов больше 8, зачастую это объясняется именно наличием интегрированного на плате экспандера – например Adaptec 51245, 51645, 52445. Так что по сути, делая выбор в пользу многопортового контроллера, Вы просто приобретаете SAS экспандер на одной плате с контроллером.

Итак, использование SAS экспандеров не только не противопоказано, а вполне оправдано в подавляющем большинстве случаев!

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

HP Virtual Connect для чайников

HP выпустили книжку “HP Virtual Connect for Dummies” – на 76 страница кратко и понятно объясняются основные моменты построения коммутации для Blade-серверов HP. Первые 2500 зарегистрировавшихся могут скачать книжку бесплатно.

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

Бесплатный сыр (софт) без мышеловки.

Не так давно VMware объявила о доступности VMware vCenter CapacityIQ – плагина для vCenter, который дает возможность анализировать нагрузку на серверы, а также делать прогноз в стиле “что если”. Плагин является платным, но (как и для других продуктов VMware) можно скачать 60ти дневный триал. Схожие продукты были и у других компаний, например, VKernel поставляла (также платный) Modeler. Но вот на днях было объявлено, что теперь (по крайней мере до 31 декабря 2009г) данный продукт доступен совершенно бесплатно на неограниченное число хостов. Возможностей у Capacity Modeler достаточно, чтобы удовлетворить самые разные требования. Так что если нужно планировать увеличение нагрузки за счет добавления новых виртуальных машин, а бюджета на CapacityIQ уже нет, то решение от VKernel будет очень кстати. Конечно же, данная акция рассчитана прежде всего на привлечение клиентов к более “вкусным” (но уже не бесплатным) продуктам VKernel, но никто не мешает Вам ограничится только бесплатной (и от этого ничуть не менее полезной) частью.

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

Объединяй и властвуй!

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

А все дополнительные возможности (с красивыми названиями Live Migration, VMotion, DRS, HA и т.п.) служат для управления виртуальными машинами и их перемещением между серверами, но никак не для того, чтобы объединить ресурсы нескольких серверов для распределения между ними одной “тяжелой” задачи.

Хорошо, скажете Вы, а что делать, если стоит задача именно увеличить процессорную мощность системы по сравнению с имеющимся сервером? В большинстве случаев решением является приобретение сервера с большим числом процессоров. Но если задача реализована на x86 архитектуре и работала на двухпроцессорном сервере, то приобрести 4х процессорную машину можно без проблем. 8-ми процессорные системы тоже есть, но выбор гораздо меньше, а цена заметно выше. Ну а дальше? 32 процессора в одном сервере x86 уже фактически неразрешимая проблема – нужно переходить на другую архитектуру, что тоже не всегда возможно (да и требует более серьезных финансовых вложений). Для целого ряда задач решение есть – построение кластеров, где задача “распараллеливается” между серверами. Наиболее на слуху наверное Oracle Real Application Clusters (RAC) – несколько серверов объединяются для параллельной обработки запросов к СУБД, тем самым, увеличивается производительность системы. Другой, не менее часто встречающийся пример, – HPC (High-performance Computing), где вычислительная задача также разделяется на несколько подзадач, которые выполняются параллельно на нескольких вычислительных узлах. Оба эти примера объединяет одно – для работы требуется специальным образом оптимизированное приложение. В тех же случаях, когда такая оптимизация не была сделана, приложение работать либо вообще не будет (наиболее вероятный вариант), либо эффект от его запуска на кластере будет в лучшем случае нулевым. Кроме того, для успешной работы приложения необходимо приложить немало усилий к настройке самого кластера (например, в ряде случаев требуется наличие кластерной файловой системы, обеспечивающей параллельный доступ к данным с нескольких узлов).

Однако уже давно существуют способы объединить серверы через интерфейсы с низкой латентностью и высокой пропускной способностью (например Infiniband), а это, в свою очередь, открывает двери для протокола RMDA (Remote Direct Memory Access). RDMA позволяет приложению, исполняющемуся на одном сервере, получать доступ к оперативной памяти другого сервера, как если бы эта память была его собственная. Казалось бы, стоит сделать небольшой шаг и можно будет именно объединить ресурсы нескольких машин вместе, без необходимости в модернизации приложений и прочих сложностей, но до недавнего времени таких решений не было.

Но на днях мне попалась заметка со ссылкой сразу на двух производителей, которые “взяли быка за рога”: Scale MP и 3leaf Systems. Оба решения позволяют объединить несколько обычных серверов в один большой виртуальный SMP сервер, выполнение на котором приложений не требует их модификации для работы на кластере. Фактическая реализация очень похожа – для создания “объединительной” среды используется высокоскоростной интерфейс. 3leaf Systems используют свой собственный ASIC, который на текущий момент устанавливается в кастомизированные платы Supermicro для процессоров AMD, но в ближайшее время планируется решение и на процессорах Intel Xeon с поддержкой QPI. Dynamic Data Center Software позволяет выделять приложению ресурсы с гранулярностью на уровне отдельных узлов, либо на уровне процессорного ядра, а в скором времени обещают и динамическое выделение ресурсов без перезагрузки виртуальной машины. Уже сейчас можно использовать вместе до 16ти серверов (до 192 ядер) и суммарно до 1ТБ памяти.

Решение же от Scale MP может работать на самых разных системах, а для связи узлов друг с другом используется Infiniband. Серверы в рамках даже одного кластера могут отличаться друг от друга, наверное в т.ч. и из-за этого технология называется vSMP (v – versatile, универсальный).

Основной продукт – vSMP Foundation for SMP является наиболее "продвинутым” вариантам и позволяет объединить до 255 ядер и 4ТБ памяти в один SMP сервер, поддерживается деление общего процессорного пула между виртуальными машинами (одна VM должна включать минимум два узла), для небольших конфигураций можно обойтись и без Infiniband коммутатора – узлы можно соединять друг с другом напрямую. Более бюджетный вариант vSMP Foundation for Cluster отличается от “старшего” брата ограничением памяти в 512ГБ и использованием процессоров не старше 2.4ГГц. vSMP Foundation for Cloud позволяет динамически вводить машины в общий пул –загрузка производится по сети (а не с флэшки, как в остальных вариантах). Очень интересной возможностью является использование различных конфигураций в рамках одного кластера: для приложений, крайне требовательных к объему памяти, но не столь требовательных к числу процессорных ядер, можно строить систему, в которой часть узлов с быстрыми процессорами предназначена непосредственно для исполнения приложения, а другая часть – со сравнительно медленными процессорами, но большим объемом памяти, используется только для увеличения общей оперативной памяти, выделяемой приложению (процессоры этих узлов не будут использоваться для работы пользовательского ПО):

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

С учетом того, что цены на Infiniband снижаются все сильнее и построение инфраструктуры уже практически эквивалентно стоимости FC SAN, описанные решения по построению больших SMP систем имеют довольно много шансов занять вполне заметную нишу. Причем, от чисто вычислительных задач интерес постепенно будет смещаться в сторону бизнес-приложений (СУБД и т.п.).

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

Еще один RAID контроллер для IBM System x

Вчера, в день анонсов, IBM объявил о доступности довольно простенького контроллера ServeRAID M1015. Это уже третья модель у IBM для 6Gbps SAS 2.0. Из возможностей – RAID1/0/10 и поддержка до 32х дисков SAS/SATA. После установки M1000 Advanced Feature Key появляются RAID5 и 50 и encryption. Контроллер построен на базе чипа LSI SAS2008 и, как я понимаю, не имеет прямого аналога в линейке LSI MegaRAID. Ни кэш-памяти, ни возможности поставить батарейку нет, так что применение довольно ограниченное, но как достойная замена BR10i вполне подойдет.

Заодно был выпущен и M5000 Advanced Feature Key для контроллеров M5014 и M5015 – после его установки появляется RAID 6 и 60, а также возможность использовать encryption.

Обновился также документ ServerRAID Adapter Quick Reference, в котором содержится информация по возможностям и совместимости контроллеров для серверов IBM System x.

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

Еще немножко про Veeam

Я уже некоторое время назад писал про анонс Veeam Backup & Replication 4.0, теперь его можно совершенно спокойно скачать и попробовать (а те, кто уже купил и находится на поддержке – обновиться).

Кроме того, наткнулся на пару роликов про продукцию Veeam. Рекомендую посмотреть тем, кому лень читать – хотя и с прицелом в маркетинг, но довольно внятно рассказывается про возможности.

 

А тем, кто решил приобрести VMware vSphere Essentials (недорогой вариант на 3 двухпроцессорные машины), рекомендую обратить внимание на специальный бандл от Veeam – Veeam Essentials, в состав которого входят три продукта Backup & Replication, Reporter и Monitor и все это сразу на те же 6 сокетов. В результате, получается удобная в обращении инфраструктура и закрыты не только вопросы управления, но и резервного копирования.

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

Аварийное восстановление BIOS на материнских платах Supermicro X8xxx

Если BIOS который был поврежден был выпущен позже февраля 2009 года, то можно сделать такой финт:

1. скачать последнюю версию BIOS подходящую для матплаты с веб сайта и переименовать его в SUPER.ROM, положить этот файл вместе с afudos.exe на флэшку.
2. Вставить флэшку в USB порт и включить систему кнопкой включения системы 8).
3. Когда система включится, нажать Ctrl + Home.
4. Система должна начать прошиваться сама собой
5. Когда система обновится, произойдет автоматическая перезагрузка.

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

VMware ESX и новые платформы Supermicro

На всех новых платформах Supermicro под CPU 55xx стоят сетевые карты Intel 82576 в ESX 3.5 U4 или ESX 3.5 U3 нет под них драйверов и для их работы необходимо воспользоваться специальным диском с драйверами, иначе ОС просто не установить по причине отсутствия сетевой карты.

http://www.vmware.com/support/vi3/doc/drivercd/esx35-igb-350.1.3.8.6.3.html вот на этой страничке из KB WMware можно скачать эти самые диски для версии ESX 3.5 U3 и U4. Если говорить про новую установку, то её следует начинать именно с этих дисков и в ходе установки программа запросит диск собственно с ESX когда он понадобится.

С ESX 4 наблюдается схожая ситуация только там немного другой процесс установки ссылка на KB VMWare http://www.vmware.com/support/vsphere4/doc/drivercd/esx40-net-igb_400.1.3.19.12-1.0.4.html

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

Infortrend ESVA – виртуализация в дисковой системе.

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

Многие знают компанию Infortrend как производителя бюджетных дисковых систем (из разряда “один контроллер, набить любыми дисками и вперед”), а некоторые даже помнят SCSI RAID-контроллеры, которые ставились в пяти-дюймовый отсек.

Основанная в 1993 году компания изначально занималась только RAID-контроллерами, а потом пришла и к выпуску дисковым системам. Звезд с неба не хватают, но железки делают довольно стабильные и производительные (что немаловажно). Причем контроллеры их ставились не только в “свои” системы, но и поставлялись другим производителям, например, они использовались в системах DotHill SANnet, которые, в свою очередь, продавал под своим именем SUN.

Но похоже что сейчас соревноваться с множеством “нонейма” становится все сложнее и Infortrend решил выйти на новый уровень: в июне этого года общественности были представлены системы ESVA (Enterprise Storage Virtualized Architecture), призванные, как даже из названия понятно, занять место в новом (для Infortrend) сегменте рынка. Конечно и раньше двухконтроллерные системы некоторыми заказчиками ставились для важных приложений, но открытыми оставались много вопросов. Один из них - "время жизни” продукта: как долго после анонса о снятии с продаж будут доступны запчасти. Не менее важным является и вопрос замены вышедших из строя компонентов.

Какие же особенности у новых систем? Во-первых, все массивы архитектуры ESVA поставляются только с дисками, поэтому заказчику уже не нужно выбирать диски самому, потенциально рискуя “нарваться” на несовместимость. Хостовые интерфейсы либо FC (8Gbit), либо iSCSI (в настоящее время с портами 1Gbit, но совсем в недалеком будущем будут и модели с 10Gbit), “вертикальное” расширение (полками) достигается при помощи SAS интерфейса. Все компоненты дублированы (контроллеры, блоки питания, вентиляторы). Кэш контроллеров защищен батарейкой (BBU), но для систем с 3.5” дисками батарея не поддерживает кэш все время а служит для того, чтобы в случае проблем с питанием, произошел “сброс” содержимого кэша в энергонезависимую память (флэш-накопитель). На всю серию ESVA обещана пятилетняя доступность запчастей (уже после снятия конкретной модели с продаж). Вы скажете, что это конечно всё важные (очень важные) мелочи, но системы, нацеленные в “энтерпрайз” класс должны иметь и соответствующий функционал! А с функционалом у привычных Eonstor-ов всегда было негусто – вот только совсем недавно появились снапшоты (а у кого их сейчас-то нет?), да вот собственно и все возможности. И можно было бы ожидать каких-то косметических улучшений, но нет -  архитектура ESVA действительно значительно превосходит все то, чем мог нас порадовать Infortrend раньше. Помимо буквально необходимой для систем такого класса синхронной и асинхронной репликации и клонов (а про снапшоты наверное и упоминать не нужно), появилась такая технология как “thin provisioning”. Я уже очень давно думаю, но не представляю как можно коротко и внятно перевести на русский язык этот термин. Смысл технологии в том, что хосту предоставляется LUN размером, скажем 20ТБ, но фактически на дисковой системе этот LUN занимает столько места, сколько на нем сейчас есть данных (фактически у нас даже может вовсе и не быть всех этих 20ТБ на системе хранения).

Но и это не главное – основная особенность новой линейки – “горизонтальное” масштабирование (как объема, так и производительности). Если в какой-то момент нам становится недостаточно имеющегося объема, мы конечно как обычно можем добавить еще одну полку с дисками, но когда нам недостаточно производительности, то, в случае использования традиционных систем, приходится переходить уже на новую СХД, приспосабливая имеющуюся под другие нужды. При этом, миграция данных с одной системы на другую – процесс болезненный и зачастую дорогостоящий. Более того, приходится не только останавливать приложения на время миграции, но и есть ненулевой шанс потерять данные и потом восстанавливать их из резервной копии, что только увеличивает общие затраты. В случае с ESVA такой головной боли нет – достаточно добавить еще одну систему и она включится в общий “пул” – данные автоматически будут перераспределены между системами и, в зависимости от числа узлов в таком кластере, общая производительность возрастает практически линейно. В один пул можно объединить до 12ти массивов ESVA, что дает суммарно 1344 диска.

Излишне наверное говорить, что и объемы дисковых систем также объединяются (общий размер Virtual Pool может достигать 2PB) и уже нет той проблемы, когда есть две системы хранения, на одной системе осталось свободных 3ТБ, на другой - 2ТБ, а нам нужно для одного из хостов создать диск размером 4ТБ. В случае с ESVA после добавления второй системы, общий свободный доступный объем составит 5ТБ и можно создать том на 4ТБ (даже не используя thin provisioning).

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

По сути своей предлагаемое Infortrend’ом решение является системой виртуализации СХД, которая находится в самой СХД, а не вне ее, как это реализовано например в IBM SVC, Falconstor NSS или HP SVSP.  Конечно нельзя сказать, что это что-то совсем-совсем новое – довольно давно на рынке присутствуют системы EqualLogic (поставляются сейчас от имени Dell), которые тоже умеют масштабироваться горизонтально, однако они не могут быть расширены добавлением JBODов и в качестве хостового интерфейса имеют только iSCSI. Схожую реализацию можно наблюдать и в системах 3PAR, правда там уже нельзя объединить вместе несколько отдельных систем с целью повышения производительности или увеличения объема пула данных.

Несложно догадаться, что цена на массивы серии ESVA конечно же не та, что на Eonstor’ы, но тот функционал, который предоставляется, того стоит. Продажей этих систем занимаемся в том числе и мы, так что – милости просим!

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

Достоинства Microsoft Hyper-V

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

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

1. Это виртуализация от Microsoft и она работает! Как это не смешно звучит, но это очень сильный аргумент и из него вытекают многие другие  аргументы ниже.

2. Ядро системы базируется на Windows Server. В результате администраторам, которые исторически работают только с системами Microsoft, нет необходимости изучать Unix. Все же полноценное администрирование VMware без знания RedHat Linux невозможно. Самый просто пример – установка драйвера устройства отсутствующего в системе.

3. Продукт имеет встроенный функционал по обеспечению отказоустойчивости реализованный с помощью Failover Cluster. Что любопытно, имеют право на жизнь конфигурации в которых узлы кластера, кроме виртуальных машин поддерживают отказоустойчивость других сервисов. К примеру, это может быть кластер из двух серверов поддерживающий SQL, а до кучи на нем может работать 2-3 виртуальных машины. В случае если производительности хватит на всех, это на 100% рабочая конфигурация.

Опять же немаловажно, что для техников уже работавших с Microsoft Failover Cluster кластеризация виртуальных машин будет таким же привычным делом как кластеризация файловой шары.

4. Система очень неприхотлива к оборудованию на котором она работает. Есть конечно жесткое требование по обязательной поддержке технологий Intel-VT или AMD-V процессорами в системе, но за исключением этого,система работает на любой платформе. Всё же системы Windows, чрезвычайно распространены в мире и количество драйверов под них не поддается исчислению.

5. Если рассматривать вариант лицензирования отказоустойчивого кластера Hyper-V, для которого требуется минимум две лицензии на Windows Server Enterprise Edition, то эти две лицензии также позволяют запустить 4 виртуальные машины с ОС Windows Server в виртуальной среде. В ситуации когда в компании работают только Windows это вполне актуально, при определенных расчетах может получиться так что сам Hyper-V вам достается бесплатно.

6. Hyper-V комфортно управляется средствами продуктов Microsoft System Center. С их помощью он умеет отправлять сообщения о проблемах, проводить резервное копирование, мониторить производительность, детально управлять обновлениями. Что приятно есть лицензия на SystemCenter для серверов, которая лицензирует все виртуальные машины физического сервера, на все компоненты SystemCenter.

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

 

В результате я вижу что заказчики имеющие чисто Microsoft среды с настроенным и работающим SystemCenter, остаются довольны продуктом. Он удовлетворяет все их потребности, не заставляя вносить в свою “исключительно MS” инфраструктуру чужеродные элементы, которые еще надо кому-то поддерживать. Опять же зачастую использование Hyper-V совпадает в таких ситуациях с лицензированием нелегальных Windows Server, что фактически означает что стоимость Windows 2008 EE уходит не только на сам Hyper-V, но и на легализацию существующих Windows.

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

Обновление прошивки на RAID Adaptec 2й и 5й серии: проблема

На сайте Adaptec появилась информация о том, что обновление прошивки RAID контроллеров 2й и 5й серии (а это модели ASR-2405, ASR-2045, ASR-5405, ASR-5445, ASR-5805, ASR-5085, ASR-51245, ASR-51645, ASR-52445) с версии 16501 на более старшую может повлечь за собой недоступность данных (хотя все созданные ранее массивы будут иметь статус Optimal). Если у Вас на контроллерах установлена упомянутая прошивка, либо имеются массивы, которые были изначально созданы на прошивке версии 16501, настоятельно рекомендуется обратиться в техническую поддержку перед обновлением прошивки. Ну и если Вы уже обновили прошивку и доступ к данным пропал, то обращаться нужно туда же. В качестве быстрого решения возникшей проблемы можно прошить версию 16501 обратно – данные после этого станут доступны.

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

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

Intel RAID RS2BL080 6GB и 8 SAS 15k с разными FW контроллера

Компания Intel любезно предоставила нам этот контроллер на короткое время, за которое мы тестировали его в первую очередь на SSD Intel X-25 E, но также и сделали несколько тестов на обычных SAS дисках. К сожалению контроллер был у нас не очень долго и мне не удалось посмотреть все, что хотелось, но было сделано несколько полных прогонов с дисками SAS. При этом эти два прогона проходили на разных версиях прошивки контроллера сначала это была 649 версия, затем был сделан апгрейд в 673 версию и повторены часть из этих тестов.

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

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

Из восьми SAS Hitachi 15k 146GB делался RAID 10, поскольку контроллер двух портовый половинки зеркала располагались на разных портах. Настройки Array на контроллере – следующие:

Собственно все настройки по умолчанию для 10 RAID.

Тест проводился Iometer’ом, профиль в обоих случаях был одинаковый. Вся нагрузка создавалась 4-мя Worker, глубина очереди каждого составляла 32. В результате как несложно посчитать: 128.

Результаты тестов

Потоковое чтение

Версия fw 649

Версия fw 673

Потоковое чтение – самый понятный показатель работы внутренних алгоритмов кэширования контроллера. Видно, что в более новой версии прошивки на большом блоке скорость существенно просела, причем пик достигается на 8кб а дальше идет резкий спад. Судя по дальнейшим результатам – 8кб размер блока КЭШ контроллера и поэтому тут и достигается максимальный результат. Также хочется отметить, что считалка у контроллера очень мощная, судя по тому что на маленьком блоке результат вплотную подбирается к 90 000 IOPS.

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

Версия fw 649

Версия fw 673

Здесь уже КЭШ не играет большой роли и результаты близки. Нужно отметить что IOPS на маленьком блоке упал почти в 2 раза.

Потоковая запись

Версия fw 649

Версия fw 673

На записи наоборот ситуация заметно улучшилась, потоковые операции упираются в потолок около 1,4 ГБ секунду, опять же очевидно влияние КЭШ. В целом новая версия прошивки больше радует глаз, чем предыдущая.

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

Версия fw 649

Версия fw 673

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

Смешанная нагрузка – 70 запись, 30 чтение.

Версия fw 649

Версия fw 673

Как и в случайной записи, результаты приблизительно похожи.

Вывод

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

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

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