Лирика

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

Цель:

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

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мс.

Предыстория

Введение

Короткая история о fio и etcd

Производительность кластера etcd во многом зависит от производительности его хранилища. etcd экспортирует некоторые метрики в Prometheus, чтобы предоставить нужные сведения о производительности хранилища. Например, метрику wal_fsync_duration_seconds. В документации к etcd сказано: чтобы хранилище считалось достаточно быстрым, 99-й процентиль этой метрики должен быть меньше 10 мс. Если вы планируете запустить кластер etcd на машинах Linux и хотите оценить, достаточно ли быстрое у вас хранилище (например, SSD), можно использовать fio — популярный инструмент для тестирования операций ввода-вывода. Запустите следующую команду, где test-data — это каталог под точкой подключения хранилища:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Нужно просто посмотреть результаты и проверить, что 99-й процентиль длительности fdatasync меньше 10 мс. Если да, у вас достаточно быстрое хранилище. Вот пример результатов:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Всем привет! Как и обещали, публикуем результаты нагрузочного теста системы хранения данных российского производства – AERODISK ENGINE N2.

Всем привет. В этой статье мы публикуем мнение нашего партнера — системного интегратора — компании Ulagos. Речь в ней пойдёт о том, как видят компанию Аэродиск заказчики, о том, как в принципе воспринимается любое российское решение и о том, чем заканчивается внедрение и как работает поддержка.

Привет, читатели хабра! Темой этой статьи будет реализация средств катастрофоустойчивости в системах хранения AERODISK Engine. Изначально мы хотели написать в одной статье про оба средства: репликацию и метрокластер, но, к сожалению, статья получилась слишком большой, поэтому мы разбили статью на две части. Пойдем от простого к сложному. В этой статье мы настроим и протестируем синхронную репликацию – уроним один ЦОД, а также оборвем канал связи между ЦОД-ами и посмотрим, что из этого получится.

Привет, читатели Хабра! В прошлой статье мы рассказали о простом средстве катастрофоустойчивости в системах хранения AERODISK ENGINE – о репликации. В этой статье мы погрузимся в более сложную и интересную тему – метрокластер, то есть средство автоматизированной защиты от катастроф для двух ЦОД-ов, позволяющее работать ЦОД-ам в режиме active-active. Расскажем, покажем, сломаем и починим.

Краткое резюме всей статьи: fio и etcd

Привет, Хабр! Меня зовут Сергей Качкин. Вместе с командой я занимаюсь тестированием производительности систем хранения данных: много тестов делаем сами, видим результаты наших коллег и заказчиков, так у нас накопилось некоторое количество опыта, которым хочется поделиться. 

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