Хочу поделится с читателями результатами многочасового мучения с производительностью VMWare. Сначала результат, потом лирика:

ОС: Windows 2003 Server
VMWare 6.5 (вероятно и другие версии) при больших объемах дисковых операций (серверные приложения) начинает жестко тормозить (падение скорости в десятки раз) после активного использования в течении нескольких часов. И это не фрагментация.

Решение:
В .vmx файле описания виртуальной машины дописываем:

MemTrimRate = «0»
sched.mem.pshare.enable = «FALSE»
mainMem.useNamedFile = «FALSE»

MemTrimRate можно настроить и через GUI, Options->Advanced->Disable memory page trimming

После этого все начинает работать в соответствии с ожиданиями (летать :-) ).

Новые SSD, выполненные по технологии MLC (multi-level-cell) объемом 100, 200 и 400 Гб появятся уже в следующем месяце. Эти накопители предназначены для enterprise-решений в области хранения данных.

Продолжаем цикл статей, посвящённых учёту ресурсов облака Селектел.

Процессорное время и память обсуждалась в прошлом году, теперь подошла очередь дисков.

С диском связаны три ресурса, каждый из которых учитывается отдельно:

1. хранение дисков
2. объём прочитанного/записанного
3. и количество дисковых операций

Перед тем, как мы обсудим все три ресурса, нужно ещё объяснить одну интересную особенность устройства виртуальных машин — раздельность учёта ресурсов.

Устройство виртуальной машины

Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?

Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в Xen Cloud Platform. На картинке упрощённая версия этой модели. Синим показано то, что принадлежит пользователю, зелёным — имена объектов, у которых осуществляется учёт.

В одном из предыдущих постов мы уже писали об ожидаемом выходе на рынок решения под ключ для электронной почты HP E5000 Messaging System for Microsoft Exchange Server 2010. Эта система была официально представлена HP на последнем CeBIT, и теперь есть возможность познакомиться с ней подробнее.



Сначала стоит сказать о двух новшествах Microsoft Exchange Server 2010, которые активно использует наша E5000. Во-первых, эта увеличение максимального размера почтовых ящиков за счет хранения их на почтовом сервере на относительно дешевых 3,5-дюймовых одно/двухтерабайтных дисках со скоростью вращения 7200 rpm. В предыдущих версиях Microsoft Exchange такой вариант хранения не применялся из-за того, что диски 7200 rpm работают слишком медленно, однако в новой версии почтового сервера Microsoft оптимизировал ввод/вывод и в результате требования по IOPS-ам снизились до уровня, которые могут обеспечить терабайтные диски.

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

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

Например, у одного из заказчиков, крупной отечественной софтверной компании, имеется довольно большой парк серверов и систем хранения. В том числе — несколько серверов HP ProLiant 6-го и 7-го поколения и система хранения HP EVA, которые были в резерве. Именно на их базе нужно было разработать решение.
Озвученными требованиями к решению VDI были:

• Floating Desktops Pool (с сохранением изменений после окончания сессии);
• Начальная конфигурация — 700 пользователей, с расширением до 1000.

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

Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании. Первый пост здесь.

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Привет, Хабрасообщество!

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

Параметр-группы RDS.

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

Доброго времени суток!


Сегодня стала известна ещё одна хорошая новость от Amazon Web Services: теперь каждый EBS-диск обеспечивает производительность в 2000 IOPS (это в два раза больше предыдущего лимита в 1000 IOPS).



Если производительности диска в 2000 IOPS Вам мало, то EBS-диски можно объединить в RAID-массив, получив тем самым необходимое количество операций ввода/вывода.

В последнее время в облачных средах и хостингах все чаще стали попадаться «виртуальные» жесткие диски. Техническая служба хостера может заверять, что «виртуальный» диск — быстрый, как десяток рейдов 10 (рейд 100 ;-) ) и держит сотни, а то и тысячи IOPS – однако MySQL заметно для клиентов тормозит. А как это доказать хостеру?

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

В статье я проиллюстрирую простую методику нахождения «точки опрокидывания» производительности виртуального жесткого диска, с использованием доступных в дистрибутивах инструментов – sysbench и iostat. Также мы измерим «точку опрокидывания» известных своей тормознутостью виртуальных дисков EBS от Амазона – как обычных EBS, так и Provisioned IOPS EBS (1000 и 2000 IOPS).

IOPS (количество операций ввода/вывода – от англ. Input/Output Operations Per Second) – один из ключевых параметров при измерении производительности систем хранения данных, жестких дисков (НЖМД), твердотельных диски (SSD) и сетевых хранилища данных (SAN).

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

Значит, для определения IOPS надо знать скорость и размер блока при операции чтения / записи. Параметр IOPS равен скорости, деленной на размер блока при выполнении операции.

Навеяно постом уважаемого amarao о том, как надо измерять производительность дисков.

Цель:

Протестировать производительность имеющихся в наличии средств хранения информации и убедиться в верности выбранной методики, а также понять разницу в производительности между разными видами накопителей, а также enterprise-level и consumer-level жёсткими дисками.

Оборудование:

1. SD-карта Sandisk Class 10 UHS 1 Extreme Pro 8 GB (до 95 Мбайт/с чтение, до 90 Мбайт/с запись)
2. SD-карта Team Class 10 32 GB (до 20 Мбайт/с)
3. SD-карта Transcend 2GB без класса скорости
4. SSD-диск OCZ-AGILITY3 60 GB
5. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
6. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
7. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
8. CD-ROM
9. RAM-диск /dev/ram в Linux

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

Методика полностью описана в посте. Есть правда несколько не совсем понятных моментов:

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

Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Так как в тестировании используется не СХД и не диски SAS, а различные накопители SATA, то параллельность нам измерять нету смысла.
Очищать диск перед каждым тестированием (dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) очень времязатратно, поэтому будем это делать перед тестированием один раз на каждый накопитель.
Тестировать весь диск полностью очень времязатратно, поэтому будем использовать тестирование в течении 30 секунд.
Итак, сформулируем методику тестирования для нашего случая:
Получить значение IOPS, выдаваемое накопителем при произвольном чтении и записи блоками по 4 Кбайт и задержке avg.latency не более 10 мс за время теста в 30 секунд. Также для полноты картины измерим скорость линейной записи.

Эта проблема наиболее актуальна для аппаратных RAID или firmware RAID (таких как Intel RST RAID 1/10/5/6) с непромышленными SSD.

Особенность SSD

SSD пишут и читают данные страницами, записать можно только на очищенные страницы, а очистить страницы можно только большими блоками. Например, у диска размер страницы 8 КБ, в блоке находится 128 страниц, таким образом, размер блока — 1024 КБ (здесь и далее, если не указано иного, КБ и МБ двоичные).

Например, если изменить 40 КБ в одном файле, то на физическом уровне это будет выглядеть так:

Предыстория

Так сложилось, что уже пять лет мой раздел ntfs с операционной системой Windows располагается на рамдиске. Решено это не аппаратным, а чисто программным способом, доступным на любом ПК с достаточным количеством оперативной памяти: рамдиск создается средствами загрузчика grub4dos, а Windows распознаёт его при помощи драйвера firadisk.

Однако до недавнего времени мне не был известен способ, как реализовать подобное для Linux. Нет, безусловно, существует огромное количество линуксовых LiveCD, загружающихся в память при помощи опций ядра toram, copy2ram и т. д., однако это не совсем то. Во-первых, это сжатые файловые системы, обычно squashfs, поэтому любое чтение с них сопровождается накладными расходами на распаковку, что вредит производительности. Во-вторых, это достаточно сложная каскадная система монтирования (так как squashfs — рид-онли система, а для функционирования ОС нужна запись), а мне хотелось по возможности простого способа, которым можно «вот так взять и превратить» любой установленный на жесткий диск Linux в загружаемый целиком в RAM.

Ниже я опишу такой способ, который был с успехом опробован. Для опытов был взят самый заслуженный дистрибутив Linux — Debian.

Обзор и тестирование флеш хранилища от IBM FlashSystem 900. Фото, базовые принципы и немного синтетических тестов внутри.

Если вы интересуетесь системами хранения данных, то сайт Storage Performance Council (SPC) вам наверняка знаком. Многие производители, в соответствии с принятыми методиками, проводят тесты своих систем и публикуют их результаты. Конечно, как в любых других синтетических тестах, можно критиковать и методику, и точность опубликованных ценовых характеристик, но на текущий момент это, пожалуй, наиболее объективный открытый источник данных о производительности СХД.

Недавно опубликованные результаты тестов системы DataCore SANsymphony-V 10 демонстрируют серьезный прорыв программно-определяемых СХД (Software Defined Storage).

Речь идет даже не об абсолютных значениях интегральной производительности — протестированная система оказалась позади первой десятки победителей с результатом порядка 450тыс IOPs, хотя и это далеко не самый плохой результат. Прорыв случился в таком важном показателе, как стоимость одной операции ввода-вывода ($/IOPs) — производитель сумел достичь величины в 0.08$/IOPs (8 центов(!) за IOPs). Это действительно великолепный результат, учитывая, что ближайший конкурент (Infortrend EonStor DS 3024B) демонстрирует результат в 3 раза худший — только 0.24$/IOPs. Для большинства же классических систем хранения, результат оказывается еще в несколько раз больше.

Кроме того, при 100% нагрузке время отклика составило 0.32мс, что тоже является замечательным показателем — для многих All Flash СХД вполне приемлемым считается результат меньше 1мс.

Низкая стоимость IOPs достигнута, разумеется, за счет того, что система имеет весьма демократичную цену — весь комплект из железа и лицензий стоит 38400$ (с учетом не очень большого дисконта). Детально стоимость решения расписна в самом отчете и любой желающий может с ней ознакомиться.

Что же, пришла пора новых технологий и уже нужно выводить из обслуживания все старые СХД, заменяя их на SDS?

Да, на первый взгляд, получить схожий результат конкурентам будет очень сложно (если вообще возможно в рамках имеющихся технологий). Дело в том, что SANsymphony-V это программное решение, которое работает внутри сервера и, как следствие, ему не требуется никакая коммутация (FC/Ethernet) со всеми связанными задержками. Кроме того, в версии 10 реализована технология многопоточного параллельного доступа (parallel I/O) к данным и здесь современные многоядерные процессоры дают заметное преимущество. (Почему многопоточный доступ становится актуальным можно прочитать здесь)

Но давайте более внимательно посмотрим на конфигурацию системы, которая участвовала в тестах. Это всего один сервер Lenovo x3650M5 с двумя процессорами Intel Xeon E5-2695v3 и 544GB оперативной памяти (из которой чуть меньше 409GB было выделено для работы SANsymphony-V). Для размещения данных использовались 16 SSD и 8 HDD общим объемом 10TB. Реальный полезный объем составил 2.9ТБ (29% от общей “сырой” емкости).

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

В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.

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

Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.

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

BX300 — это новейший потребительский 2,5-дюймовый SSD-накопитель компании Crucial, в основе которого лежит технология 3D-NAND. Новый BX300 SSD является прямым преемником BX200 и оснащен контроллером Silicon Motion и специальной прошивкой. Высокоэффективная технология BX300 доступна в объеме 120 ГБ, 240 ГБ и 480 ГБ.

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