Буду рад, ребята, если вы ответите мне на несколько моих вопросов о работоспособности нашего хранилища. Установка
По сути, основной причиной, по которой мне пришлось взглянуть на наше хранилище, был перенос контролирующей ВМ с локальных дисков одного из хостов в хранилище. Поэтому перед выполнением любой миграции я настраиваю новую виртуальную машину с iometer и запускаю тесты ночью, когда в кластере не выполнялись важные задания. На этой виртуальной машине был только 1 рабочий поток динамо-машины.
Access Specification Name IOps Read IOps Write IOps MBps Read MBps Write MBps Transactions per Second Average Response Time Average Read Response Time
512B; 100% Read; 0% random 5617.191059 5617.191059 0.000000 2.742769 2.742769 0.000000 5617.191059 0.176979 0.176979
512B; 75% Read; 0% random 3190.524306 2369.761725 820.762581 1.557873 1.157110 0.400763 3190.524306 0.312244 0.321925
512B; 50% Read; 0% random 1055.807449 524.819993 530.987456 0.515531 0.256260 0.259271 1055.807449 0.946000 0.421600
512B; 25% Read; 0% random 1006.956966 239.414257 767.542709 0.491678 0.116901 0.374777 1006.956966 0.853556 0.687116
512B; 0% Read; 0% random 35.123065 0.000000 35.123065 0.017150 0.000000 0.017150 35.123065 28.349538 0.000000
4K; 75% Read; 0% random 3034.296095 2247.847150 786.448945 11.852719 8.780653 3.072066 3034.296095 0.328614 0.333793
4K; 25% Read; 0% random 2237.793260 587.671309 1650.121951 8.741380 2.295591 6.445789 2237.793260 0.445755 0.636275
16K; 75% Read; 0% random 627.852712 474.796322 153.056389 9.810199 7.418693 2.391506 627.852712 1.591288 1.840213
16K; 25% Read; 0% random 478.619741 116.666329 361.953412 7.478433 1.822911 5.655522 478.619741 2.086953 1.281547
32K; 75% Read; 0% random 848.266506 649.372846 198.893660 26.508328 20.292901 6.215427 848.266506 1.176316 1.334378
32K; 25% Read; 0% random 443.441341 117.275291 326.166050 13.857542 3.664853 10.192689 443.441341 2.253707 7.158792
Тесты чтения hdparm (с hdparm -t / dev / sda) дали 300 МБ / с.
Наша система мониторинга получает информацию от + - 40 виртуальных машин и 30 устройств, на каждом хосте есть не менее 10 сервисов, но на самом деле именно кактусы генерируют большую часть IOPS. Он массово обновляет данные RRD одновременно каждую минуту. Несмотря на это, я решил перенести виртуальную машину в хранилище. После миграции я измерил IOPS, сгенерированный в результате мониторинга - среднее значение было 800, но время отклика после любой операции чтения на каждой виртуальной машине было ужасным - 5-10 секунд, мониторинг фактически убил некоторые виртуальные машины, поскольку время ожидания ядра для некоторых операций ввода-вывода истекло. hdparm выдал 1,4 МБ / сек. Я отключил обработку cacti RRD, она работает нормально, но графиков у нас нет.
Мои вопросы:
1) Что вы думаете о производительности iometer на этой установке? Так должно быть лучше, нормально, или надо поискать некоторую неверную конфигурацию?
2) Вы рекомендуете иметь отдельный физический хост с программным обеспечением для мониторинга и не "заморачивать" хранилище такими IOPS?
3) Это более общий вопрос. После теста хранилища мы можем получить IOPS / Мбит / с для блоков разного размера. Но как я могу оценить размер блока, который в основном использует приложение? Например, система баз данных часто использует 75% операций чтения, но каков размер блока, чтобы я мог сравнить его с моими результатами? Не зная этой информации, мои тесты iometer - это просто числа.
ОБНОВЛЕНИЕ 1: Спасибо за ответы.
Итак, что мы сделали, так это то, что мы создали ramdisk для обработки rrd, и все rrds каждый час синхронизируются с диском мониторинга. Все работает довольно быстро, но мы подумаем о создании еще одной группы RAID с RAID 10 для такого типа операций ввода-вывода в секунду, которые требуют хорошей производительности записи.
Я буду честен, хотя я достаточно уверен, что такая установка поддерживается, я никогда раньше не видел кластера SAS VMWare с прямым подключением> 2 хостов. Я знаю, что он отлично работает с 2 хостами, но 3 или более не подходят для использования этого метода.
Тем не менее, ваша статистика выглядит нормально для меня, в конечном итоге у вас есть очень медленные диски в массиве R6, поэтому есть предел скорости, которая когда-либо будет - и 443 IOPS там или около того производительности, которую я ожидал.
Что касается вашего второго вопроса, если нагрузка настолько плохая, вы можете подумать о создании еще одного логического диска на P2000 с парой выделенных дисков в R1 и разместить на нем виртуальную машину или, возможно, переместить его на локальный DAS, если вы можете жить без функциональность vMotion / DRS / HA.
Третий вопрос - может быть, iotop?
Описанная установка не так быстра, как могла бы быть. Это поддерживаемая схема, так как вы можете подключить к установке максимум четыре хоста (если вы откажетесь от множественного пути SAS).
К вашим пунктам:
Производительность невысока, но подходит для того, что вы настроили. Я буду ссылаться на Сообщение об ошибке сервера канонический RAID, который в основном заявляет, что RAID 6 плох для рабочих нагрузок с произвольной записью. Виртуальные машины и системы мониторинга известны этой схемой доступа. RAID 1 + 0 - лучший вариант, если это возможно.
я делать виртуализировать мои узлы мониторинга, но создать хранилище для этого (предпочтение отдается большему кэшу записи, установить соответствующие параметры лифта ввода-вывода в виртуальной машине). Это для других инструментов на основе RRD (orca и OpenNMS), но однозначно относится к Cacti.
Что касается тестирования, я не думаю, что отслеживание средних размеров транзакций / блоков так важно, поскольку более крупная архитектурная проблема может дать больший выигрыш во всех отношениях. Однако вы можете отслеживать приложения. Также рассмотрите возможность проверки производительности хранилища виртуальных машин с помощью vCenter или esxtop / resxtop.