Маркетинг...

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

Заказчик, которому мельком покажут такую картинку, будет “аргументировано” убежден в неоспоримых преимуществах продуктов производителя A (название я так уж и быть замазал ;) ). Если же внимательно присмотреться к масштабу изображений, то разница (4% если считать “на сколько меньше” и 5%, если” на сколько больше”) становится уже не такой убедительной. А учитывая минимальный объем информации о том, как и в каких условиях, это тестирование производилось, такой разницей можно вообще пренебречь.

И еще, совет от одного бывалого эксперта: “Хотите спрятать реальное состояние дел – активно используйте гистограммы ;) “ .

Уровни драйверов и HBA

Любая HBA имеет физические ограничения на максимальные возможные значения Bandwidth и Throughput.

FC интерфейс HBA	Макс. Bandwidth на порт half duplex	Макс. Throughput на порт
2FGC	180MB/s	~40.000IOPS
4GFC	360MB/s	~150.000IOPS
8GFC	720MB/a	~210.000-500.000IOPS (данные из различных источников)

Для обеспечения высокого уровня Bandwidth необходимо использовать 8GFC HBAs. Не стоит забывать, что при этом они должны быть подключены к соответствующим 8Gbps портам FC коммутаторов.
Некоторые производители предлагают свои проприетарные методы повышения Bandwidth. Например, HBA Brocade, позволяют агрегировать два порта одной карты в единый канал передачи данных (trunk), тем самым практически удваивая суммарную полосу пропускания.

Если максимальные показатели Bandwidth у HBAs различных моделей отличаются друг от друга незначительно, то значения Throughput могут различаться очень заметно. Это связано с архитектурными особенностями адаптеров различных производителей. В одних моделях за буферизацию и обработку пакетов отвечают несколько отдельных модулей программно управляемых микрокодом (firmware). В HBA другого производителя большая часть функций “зашита в железо” специализированных ASIC, что позволяет при обработке данных минимизировать внутренние накладные расходы, тем самым уменьшая задержки передачи и повышая максимальное количество IOPS.

Но даже в рамках модельного ряда одного производителя, следующие поколения HBAs имеют более мощную аппаратную начинку и эффективные внутренние методы передачи данных. Поэтому в уже существующей инфраструктуре SAN на базе 4Gbps FC коммутаторов, модернизация HBA 4GFC на 8GFC все равно позволит увеличить максимальную Throughput. За подробностями отсылаю вас к рекомендациям на сайтах производителей.

Внутренние соединения HBA

Факты из истории виртуальной памяти

С момента появления идеи до признания преимуществ использования виртуальной памяти и ее массового использования прошло достаточно много времени. Вот некоторые исторические факты.

В конце 1947г. в лабораториях Bell Labs команда под руководством Вильяма Шокли представила первый работающий образец биполярного транзистора. Достаточно скоро появились вычислительные комплексы, использующие эту революционную технологию. Историки их называют компьютерами второго поколения. Такие системы в качестве оперативной памяти обычно использовали жутко дорогие устройства на ферритовых сердечниках. Именно тогда была выдвинута мысль о возможности расширения физической области оперативного хранения данных за счет использования более дешевых, но медленных магнитных барабанов.

К сожалению, эта смелая идея не нашла поддержки в тогдашней достаточно консервативной среде. Поэтому первая работающая система с использованием идей виртуализации памяти начала серьезно разрабатываться только в период 1959-1962 гг. в рамках проекта команды из University of Manchester, который назывался Atlas Computer.

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

В мире персональных компьютеров виртуальная память была представлена достаточно недавно, с появлением protected mode процессора Intel x86.

Кстати, в Большом Советском Энциклопедическом Словаре есть следующая статья: “виртуальная память (кажущаяся память ЭВМ) - система запоминающих устройств, организованных таким образом, что программист может рассматривать их как одну большую оперативную память, что существенно упрощает процедуру составления программ для мультипрограммных ЭВМ”. Но, несмотря на авторитетность издания, я все-таки соглашусь с замечанием журналиста Леонида Черняка в одной из статей: “такая память никому не кажется и не мерещится, а функционирует в полном согласии с законами физики” :) .

Виртуальная Память

Уровни приложений описываются здесь

Для логической изоляции процессов друг от друга, расширения адресного пространства и более рационального управления RAM, в большинстве современных операционных систем используется специальная схема адресации, которая называется виртуальной памятью (virtual memory). Совершенно прозрачно для приложений в ее логически непрерывное адресное пространство кроме оперативной памяти можно включать другие физически раздельные области, находящиеся на внешних запоминающих устройствах. Например, специальные разделы или даже файлы на уже используемых файловых системах. Такие области называются разделами или файлами подкачки (swap или paging, в зависимости от операционной системы).

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

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

Better then nothing

17 ноября посетил EMC форум. Достаточно интересным показалось выступление Брайана Галахера (Brian Gallagher), который в EMC является самым большим боссом по Hi-end линейке Symmetrix (вот здесь видюшка с его рассуждениями по поводу FAST). Особенно последокладные ответы на вопросы по поводу развития технологий репликации и дисков SSD. Ну да рассказ не об этом.
Через пару дней, воодушевленный возможностью послушать и пообщаться с человеком, "который знает куда катится мир", посетил внутренние посиделки в центре разработки EMC в Питере, где Брайан общался с народом. В конце беседы коснулись одной очень мощной, но глюкавой внутренней тулзы для анализа статистики Symm. Я пожаловался, что без этого инструмента мне в работе не обойтись, но его применение регулярно вызывает массу негативных эмоций. На это Брайан ответил "You are right, but that's better then nothing"...

Последнее время, когда меня что-то начинает раздражать, сама собой всплывает фраза "but that's better then nothing"...  и правда становится легче...  :)

дописано
Выдали мне все-таки новый более мощный ноутбук...  оказывается экстенсивный путь развития - тоже вариант...  учетверение памяти позволило глюкам работать на порядок быстрее и, как следствие, качество тулзов сразу увеличилось до уровня "так как должно"...  :)

Менеджеры Томов - часть 2 Plaids

Часть 1 об использоании Volume Managers

Если визуально представить себе VM страйпинг LUNs, которые уже сами по себе уже страйпированы (RAID 5, RAID 6, RAID 10), получится клетчатый “узор”, напоминающий шотландку-тартан. Благодаря этому такие конфигурации в литературе часто называются пледами (plaid).

Обычно используется 3 типа plaids:

• High Bandwidth plaid имеет смысл использовать при размерах I/O запросов приложений >= размера RAID stripe на дисковом массиве (размер stripe element * количество дисков данных в RAID). Это необходимо для увеличения производительности записи за счет full-stripe writes (будем обсуждать далее в разделе xxx). В однопоточных приложениях Volume Manager создает отдельные потоки данных на каждую LUN, равномерно распределяя нагрузку сразу по нескольким дискам.

Для повышения полосы пропускания рекомендуется
o    распределять нагрузку между портами различных контроллеров (SP)
o    для каждого активного пути к портам контроллера использовать на сервере выделенную HBA
o    по возможности распределять нагрузку между различными дисковыми массивами
o    настраивать только одну LUN на RAID Group.

• High Throughput plaid имеет жесткое ограничение на VM stripe element = RAID stripe. Основная идея такая же, как и в предыдущем случае – по максиму распределить нагрузку по различным шпинделям. Этот тип plaid можно организовывать как на RAID 5/6, так и на RAID10.

Для повышения пропускной способности рекомендуется
o    распределять нагрузку между портами различных контроллеров (SP)
o    для каждого активного пути к портам контроллера использовать на сервере выделенную HBA
o    настраивать только одну LUN на RAID Group

• Cross-striping plaid используется при random I/O с размерами запросов от приложения <8KB. Для эффективной балансировки random нагрузки применяется “размазывание” сразу нескольких LUNs по максимально возможному количеству дисков. При распределении LUNs по RAID Groups необходимо быть уверенным в том, что эти тома не будут испытывать пиковую нагрузку в одни и те же моменты времени.