В последнее время громадную популярность завоевали т.н. твердотельные накопители (Solid State Drives, SSD). Для простого пользователя они представляют особый интерес тем, что позволяют значительно расширить «бутылочное горлышко» производительности системы, которая упирается в быстродействие жёстких дисков. SSD потребительского класса по скорости чтения/записи превосходят жёсткие диски в несколько раз, а в некоторых задачах — даже на порядок.

Да, нынешние SSD уже готовы заменить жёсткие диски на десктопах и в ноутбуках в полной мере, но не для всех пользователей это приемлемо, и причин этому несколько. Во-первых, вызывает вопросы та самая надёжность. Тут обычно спасают бекапы, главное — вовремя их делать. Вторая причина связана с конфиденциальностью. Если на HDD использование LUKS не вызывает вопросов, то на SSD включение TRIM понижает защищённость информации. Без TRIM же есть шансы просадить производительность дисковых операций.

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

Для операционной системы Linux представлено несколько технологий кеширования данных на SSD — bcache, EnhanceIO, dm-cache и т.п. Использование их позволяет ощутить прирост быстродействия дисковых операций, при этом надёжность функционирования системы хранения данных останется на прежнем уровне.

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

Программа IOmeter — это популярное средство для тестирования производительности дисковой подсистемы и локальной сети. Тест является «100% синтетикой».

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

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

Большинство ПО кластерных систем предполагает наличие файловой системы доступной со всех узлов кластера. Эта файловая система используется для хранения ПО, данных, для организации работы некоторых кластерных подсистем и т.д. Требования на производительность такой FS могут сильно отличаться для разных задач, однако, чем она выше, тем считается, что кластер более устойчив и универсален. NFS сервер на мастер-узле является минимальным вариантом такой FS. Для больших кластеров NFS дополняется развертыванием LustreFS — высокопроизводительной специализированной распределенной файловой системы, использующей несколько серверов в качестве хранилища файлов и несколько метаинформационных серверов. Однако такая конфигурация обладает рядом свойств, которые сильно затрудняют работу с ней в случае, когда клиенты используют независимые виртуализированные кластера. В системе HPC HUB vSC для создания разделяемой FS используется широко известное решение CEPH и файловая система GFS2.

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

Знакомьтесь: Ceph

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



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

Совершенно неожиданно для меня вышла стабильная версия мультиплатформенного гнератора синтетической нагрузки IOMeter2 v1.1.0. IOMeter часто применяют для тестов дисковой подсистемы, хотя он также может генерировать нагрузку на сеть. Интерфейс совершенно не притерпел изменений. В предыдущей статье я тестировал СХД NetApp FAS подключённый по FC4 к хосту на стабильной версии IOMeter2 2008-06-22-rc2.

При нагрузочном тестировании не забывайте, что нужно оптимально настроить цепочку:
СХД -> Сеть (Ethernet / FC) -> Хост ( Windows / Linux / VMware ESXi ) -> Приложение.
Чтобы получить наилучшие результаты как в синтетически тестах, так и на реальных данных. Одного сервера может оказаться не достаточно чтобы нагрузить СХД.

Из важных нововведений:

• Поддержка Windows UAC.
• Пофикшен Windows Disk detection, позволяющий работать с новыми дисками. Диск с таблицей разделов GPT в качестве блочного устройства по-прежнему не поддерживается.
• Data randomization — появилось три варианта, сильно отличающихся генерируемым патерном случайности.
• К сожалению не все старые версии конфигов совместимы с новой версией IOMeter2, привожу патерны нагрузки для новой версии чуть ниже.

Для Outstanding I/O максимальное значение может быть 256, тогда как 128 означает высокую нагрузку схожую с высоконагруженными БД.

Привет, Geektimes! Хочу поделиться моим опытом в организации очень бюджетного видеонаблюдения на даче c 3G с возможностью просмотра онлайн и сохранению архива.

В этой статье я постараюсь вас познакомить с бесплатным продуктом FOG, который служит созданию и развертыванию образов ОС. К своему удивлению я не увидел статей на русскоязычных ресурсах, посвященных, безусловно, этому интересному продукту.
Отмечу, что я не ставлю перед собой задачу описать абсолютно все нюансы и расписать всё. Ничего не заменит ваш личный опыт. Я хочу лишь приоткрыть занавес и помочь многим системным администраторам двигаться в нужном направлении, остальное в ваших руках.

В продолжении статьи «Quadstor — виртуальный SAN для бюджетников» как и обещал, сравнительные тесты скорости VSAN Quadstor HA и VSAN Starwind HA. А так же тест надежности Quadstor HA с имитацией отключения одного из нодов HA.

Производительность

Для проверки сравнительных тестов скорости VSAN Quadstor и Starwind, были созданы 5 виртуальных машин на основе одного железного хоста с VMware ESXi 6.5. Виртуальные машины по тех. характеристикам полностью одинаковы (братья близнецы) (2хCPU, RAM-3Gb, 2x1Gb LAN,).

Ошибки и сложности, с которыми мы столкнулись, запуская собственный кластер на базе VMmanager Cloud + Ceph.

Примерно так выглядит первая инсталляция CEPH на реальном железе.

Вы установили цеф, но он тормозит и падает непонятно почему? Тогда вы пришли по адресу! Я прокачаю ваш CEPH.

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

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

Лирика

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

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

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

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

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

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