ИТ-технологии для профессионалов

вторник, 23 июня 2009 г.

Недостатки Hyper-V

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

итак по порядку

1. отсутствие нормально реализованного teaming для сетевых карт, существующий вариант от broadcom требует донастройки и “из коробки” не работает. Если же у нас узлы hyper-v еще и в кластере – то конфигурация становится невалидной, т.к. использовать на кластерных интерфейсах teaming низя по докам от MS. Т.е. нужно либо больше 2-х интерфейсов либо отказаться от teaming.

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

3. Огромное количество патчей. Часть из патчей не полностью валидировано поддержкой. Я прихожу к выводу что человек который поддерживает большую ферму hyper-v вынужден очень хорошо уметь контролировать апдейты. Поскольку не все апдейты идут через WSUS это приходится делать вручную. Немаловажно что приходится периодически для апдейтов машинки перегружать.

4. Отсутствие живых миграций. Это конечно не самый важный минус, но учитывая необходимость перегружать сервера после апдейтов периодически это нехороший момент. Да, после релиза 2008R2 лично я его не буду использовать минимум пол года.

5. Отсутствие возможности детализировать приоритеты по сети, дискам. То что есть, сделано на зачаточном уровне и в реальности сложно используемо.

6. Отсутствие поддержки FC устройств внутрь ВМ.

7. Невозможность сделать Failover Cluster между ВМ без iSCSI. Таким образом получается что приходится делать устойчивый iSCSI таргет, т.е. это либо дисковая с 2-мя контроллерами либо еще один кластер, таким образом чисто между ВМ его не сделать.

8. Сложность мониторинга состояния системы и отсылки простых оповещений. Понятно что это достигается средствами SyscOM, но ИМХО сложность продукта сравнима со сложностью самого hyper-v. В итоге получается, что для мониторинга только hyper-v приходится осваивать универсальный инструмент связанный с SQL и т.д.

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

10. Меньшее количество протестированного оборудования под платформу. Получается что широта поддержки оборудования бьет обратно тем что за такой широтой сложно присматривать.

11. Невозможность добавить в существующую виртуальную сеть более одного физического адаптера с каждого хоста. См выше про teaming.

буду стараться дополнять при возможности, сейчас больше ничего в голову не лезет

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

четверг, 18 июня 2009 г.

Тестирование Intel® X25-E Extreme SATA Solid-State Drive

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

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

Компания Intel представила два новых SSD накопителя. Это сверхбыстрые твердотельные накопители Intel X25-M и X25-E. Первый рассчитан на системы среднего уровня, а второй, достоинства и недостатки которого я рассматриваю, рассчитан на корпоративный (High-End) сегмент.

Что же диск из себя представляет?

Диски выполнены в форм-факторе 2,5 дюйма, имеют привычный и интерфейс SATA с пропускной способностью 3.0 Gb/s, практически не греются и устойчивы к вибрациям. Полная спецификация диска доступна на сайте производителя (http://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf).

Явным достоинством дисков X25-E является использование флеш памяти SLC (single-level cell), что обеспечивает высокую производительность, так как имеется прямой доступ к каждому биту данных (в отличие от памяти MLC (multi-level cell), где в каждой ячейке хранится несколько бит данных).

clip_image002

SSD диск Intel X25-E 32 GB

clip_image004

Можно оценить масштаб

Также для повышения производительности используется десятиканальный контроллер памяти работающий с чипами параллельно, то есть вся флеш-память внутри диска объединена в RAID 0. Основное преимущество в использовании SSD дисков – крайне малое время для обращения к случайным секторам, что очень важно в системах хранения (к примеру, для поиска по базе данных). Мы постараемся проследить это в нашем тесте. Главное, что заставляет смотреть в сторону SSD дисков как на перспективное решение хранения – интерфейс SATA и самим фактом работы их с уже существующей инфраструктурой. Нет сомнений, что намного проще постепенно добавлять SSD к системам хранения, начиная от понятной возможности включения их в SATA контроллеры. А в перспективе, возможно, появятся отдельные контроллеры, оптимизированные именно под SSD или отдельные BIOS для существующих контроллеров, которые будут работать с SSD оптимально, а другие BIOS будут для HDD.

clip_image006

Если разобрать – видим на одной стороне 10 чипов памяти SLC, 1 контроллер диска от Intel, 1 чип памяти RAM в роли кэша. На другой стороне 10 чипов памяти.

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

Часто к недостаткам твердотельных дисков относят достаточно высокую цену за 1Mb хранимой информации. Это не совсем верно, более правильно пересчитывать цену за iops. Как правило, нам не требуется огромного объема для хранения базы данных.

Еще одно заблуждение – это невысокая надежность, вызванная ограниченным количеством циклов перезаписи ячеек памяти. Время наработки на отказ (MTBF) у X25-E составляет 2 миллиона часов, к примеру, MTBF жестких дисков Hitachi HUS153014VL300 составляет 1,2 миллиона часов, а у контроллера Adaptec на котором мы проводили тесты всего 873,402 часов.

К этому можно добавить “умный” контроллер, который оптимизирует использование ресурса записи ячеек, т.е. износ памяти происходит равномерно. Для повышения отказоустойчивости, на дисках зарезервировано 6% от объема на случай отказа части ячеек или исчерпания ими ресурса записи. А также вы можете при помощи SMART отслеживать количество уже записанной информации и прогнозировать время жизни каждого диска.

Соответственно если отдельная ячейка перестает работать, вместо неё начинает использоваться резервная. Учитывая природу SSD, это не сказывается на общей производительности, в отличие от аналогичной процедуры remap’а у HDD. Скорость работы SSD не зависит от фрагментации ячеек, как таковое понятие физической последовательности ячеек просто отсутствует в SSD.

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

Методика тестирования

Тестовая конфигурация:

Материнская плата

Supermicro X7SBE (f/w 1.2a)

Процессор

Intel Core 2 Quad Q9400 2666 MHz

Оперативная память

2x Kingston 2GB 800 DDR2

RAID контроллер

Adaptec RAID 5805 (f/w 16501) Cache Memory 512MB of DDR2

Дисковая система

Seagate 7200.10, 250Gb –системный
- 8x Intel® X25-E 32 Gb
- 8x Hitachi HUS153014VL300147Gb 15K rpm

Операционная система

MS Windows Server 2008 Enterprise 6.0.6001 (HotFix KB960735)

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

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

Официально Intel валидировала свои SSD под южный мост ICH9R и ICH10R, а Adaptec добавил их в лист совместимости, хотя поддержку конфигураций Adaptec начнет оказывать только с лета.

Эмпирическим путем были выяснены оптимальные настройки контроллера для работы с SSD:

Drivers Write Cache

Enable All (рекомендовано инженерами Intel)

Array Background Consistency Check

Disabled

SATA Native Command Queuing

Enabled (рекомендовано инженерами Intel)

Power Management

Off (как показали другие исследователи, данная опция имеет серьезное влияние на производительность SSD)

Почти таким же путем и параметры массива:

Write cache

Enabled (write-back) when protected by battery (общая рекомендация для RAID)

Read cache

Enabled

Stripe Size RAID 0

1024 kb

Stripe Size RAID 5

256 kb (рекомендовано инженерами Intel)

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

Тест 1-го SSD диска

В начале тестирования, когда я измерял производительность одного диска, он был подключен к южному мосту ICH9R. Результаты получались в 1,5-2 раза ниже официально заявленных и при повторении тестов результаты очень сильно отличались друг от друга. Как выяснилось, проблема оказалась в некорректной поддержке NCQ в ACHI драйвере Microsoft (http://support.microsoft.com/kb/960735/en-us). После установки патча, диск сразу показал производительность близкую к заявленной.

clip_image008

Результаты получились близкие к заявленным, что позволило перейти к дальнейшим тестам дисков в RAID. Именно эти тесты представляют из себя наибольший интерес.

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

2xSSDRaid 0, блок 1024kb

В этой конфигурации на пробу были включены 2 SSD диска с целью понять, как оно вообще будет работать в RAID. Естественно ожидаемый прирост производительности относительно 1-го диска 2 раза.

Я прогонял по 10 минут IOmeter в 256 потоков с разными по размеру блоками запроса. Блок меньше 128kb можно соотнести с нагрузкой БД или веб-сервера, блок большего объема к работе с файлами.

Соответственно в графиках ниже, по горизонтали размер блока, по вертикали –IOPS или мегабайты в секунды.

Линейное чтение

clip_image010clip_image012

Линейная запись

clip_image014clip_image016

Сначала были выполнены тесты с последовательными чтением и записью. Поскольку, например операции чтения показали скорость больше 1,5 ГБ/сек, у меня нет к ним большого доверия. Это связано с тем, что большую часть запросов обрабатывал кэш контроллеров. В общем и целом линейные результаты получились - «ни о чем».

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

clip_image018clip_image020

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

clip_image022clip_image024

А вот с операциями случайного доступа, все намного интереснее. Они не зависят от кэша и по ним можно оценить саму скорость диска, поскольку влияние модуля кэширования контроллера в них сводится к минимуму.

Интересен провал производительности в случае записи блоков больше чем 64кб, но об этом мы поговорим чуть ниже, при сравнении SAS и SSD.

Сами цифры для 2-х дисков получились отличные. Для полностью случайной записи по 4 000 IOPS на диск это очень круто.

Чтение 33%, запись 67%

clip_image026clip_image028

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

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

В начале лета должна появиться прошивка для контроллера Adaptec которая сможет использовать все преимущества дисков как следствие ожидается улучшение результатов.

8xSSDRaid 0, блок 1024kb

VS
8
xSSDRaid 5, блок 256kb

VS
8xSAS15k – Raid 5,
блок 256kb

Итак сравним напрямую производительность 8 SAS и 8 SSD на одном и том же контроллере Adaptec 5805. Всего в дисковом контроллере было 2 порта по 4 канала, соответственно все порты заняты дисками. Этим обусловлено количество сравниваемых дисков – 8. Еще на выбор в 8 дисков повлияло то что всего у меня было 8 штук SSD для тестов.

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

В наших тестах размер блока чтения/записи 4Кб оказался наиболее приемлемым с точки зрения количества операций в секунду. В пользу того, что такой размер является оптимальным, говорят и официальные данные Intel, где производительность в IOPS также рассчитывается на блоках 4 Кб. Но в реальных задачах часто блоки иные, и мы постарались показать изменение производительности при смене блока. Таким образом, в этих тестах мы выбрали стандартные размеры блоков и проверяли производительность дисковых систем под нагрузкой 256 одновременных потоках IOmeter’а.

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

SSD

clip_image030clip_image032

SAS

clip_image034clip_image036

Различия в производительности Raid 0 и Raid 5 у SSD вызваны тем что, во втором случае контроллер RAID выполняет работу по расчетам четности блоков данных, что снижает общую производительность.

Радует что результат линейный и крайне предсказуемый. Также замечательно то, что в пике чтение SSD достигает 1ГБ/сек или 30 000 IOPS. Результаты SAS в 10 раз меньше.

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

SSD

clip_image038clip_image040

SAS

clip_image042clip_image044

Наиболее показательно то, что SSD на маленьком блоке (512b – 8k) дает результаты почти в 20 раз выше, чем SAS. В общем-то, увидели, что и ожидали. Именно в такого типа нагрузке SSD проявляет себя с самой сильной стороны.

Падение производительности SSD на блоке больше 64кб мы уже видели до этого в RAID 0 из двух SSD дисков. Причины этого падения производительности у SSD не ясны, но можно предположить, что алгоритмы записи SSD диска заточены на блок меньший 64к. Либо алгоритмы работы Adaptec’а каким-то образом влияют на производительность контроллера SSD при блоках больших 64K. Поскольку внутренняя схема работы и алгоритмы контроллера не известны нельзя точно сказать, в чем же дело.

Но даже, несмотря на это падение, худший результат SSD всё равно выше, лучшего результата SAS.

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

70% запись, 30% чтение

SSD

clip_image046clip_image048

SAS

clip_image050clip_image052

Графики разделены на чтение и запись, что позволяет детально видеть динамику движения и влияние чтения на запись.

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

Этим объясняется падение производительности SSD на размере блока 64к. Здесь мы видим туже картину, что и в случайной записи. В случайном чтении поведение графика было другое, в тесте со смешанной нагрузкой оно становится как и у записи из-за общей очереди. Опять же про это уже говорили выше.

По результатам наглядно видно превосходство SSD дисков над HDD. На маленьком блоке оно просто огромно! SSD быстрее больше чем в 20 раз.

Время ответа массива при нагрузке 70% запись, 30% чтение

SSD

clip_image054

На графиках: ART – среднее время ответа.

SAS

clip_image056

На графиках: ART – среднее время ответа.

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

Этот параметр критичен, например, для баз данных. БД генерирует огромное количество запросов и естественно долгое ожидание на запрос, тормозит всю очередь.

По графикам видно, что на блоках свойственных БД, SSD в сотни раз превосходит обычные диски. Ситуация начинает портиться при размере блока больше 256кб, но этот тип нагрузки свойственен больше потоковому копированию на котором эта характеристика уже менее актуальна. Есть предположение, что схожая динамика SSD и SAS может быть объяснена дисковым контроллером, но это скорее предположение.

Выводы

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

Итак, если ваша задача требует интенсивного обмена данными с дисковой системой, то твердотельные диски Intel X-25E станут достойной альтернативой многодисковым массивам из традиционных дисков. К примеру, SSD получается отличным решением для баз данных или веб серверов.

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

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

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