SAN Performance
Есть вопрос, касающийся производительности SAN, в частности EMC VNX SAN. У меня есть значительное количество процессов, распределенных по числу блейд-серверов, работающих одновременно. Количество процессов обычно составляет около 200. Каждый процесс загружает 2 небольших файла из хранилища, один 3 КБ, один 30 КБ. Есть миллионы (20) файлов для обработки. Процессы работают на Windows Server в VMWare. Первоначально это было сделано для установки 1 ТБ LUN в сети SAN, объединенной в один 15 ТБ диск в VMWare, а затем в качестве сетевого ресурса из одного экземпляра Windows для всех процессов. Процессы работают одновременно, а производительность ужасна. По сути, 200 одновременных запросов обслуживаются SAN через общий ресурс Windows одновременно, и SAN обрабатывает их не слишком хорошо. Я ищу рекомендации по улучшению производительности. Заранее спасибо...
1 ответ
Со всеми вопросами производительности, есть степень "это зависит".
Когда вы говорите о доступе к SAN, существует цепочка потенциальных узких мест, которые нужно распутать. Во-первых, нам нужно понять, в чем проблема:
- У нас есть проблемы с пропускной способностью - например, длительная передача или задержка?
- Похоже, мы смотрим на случайный ввод-вывод - это одна из самых сложных рабочих нагрузок для обслуживания, потому что прогностическое кэширование не работает.
Итак, начнем с самого начала:
Какой тип хранилища вы используете?
Вы попали в ловушку, покупая большой SATA, настраивая его RAID-6? Я видел множество мест, где это делается, потому что это выглядит как дешевые терабайты, но не влияет на производительность. Диск SATA начинает замедляться со скоростью около 75 операций ввода-вывода в секунду. Если у вас большие диски - например, 3 ТБ - это 25 IOP на терабайт. Как правило, 200 на диск для FC/SAS и 1500 для SSD.
ты многоуровневый? Многоуровневое хранение - это умный трюк для создания "сэндвича" с разными скоростями диска. Обычно это работает, потому что обычно только небольшая часть файловой системы является "горячей", поэтому вы можете поместить горячую часть на быстрый диск, а холодную часть - на медленный диск, и средняя производительность выглядит лучше. Это не работает для случайного ввода-вывода или холодного доступа. Он также не работает для полной передачи диска - только 10% (или любая другая пропорция) могут быть "быстрыми", а все остальное должно идти медленным путем.
Каково ваше утверждение уровня массива? Смысл SAN заключается в том, что вы агрегируете свою производительность так, чтобы у каждого пользователя был более высокий пик и более низкое среднее значение, поскольку это отражает большинство рабочих нагрузок. (Когда вы работаете с документом, вам нужно получить прирост производительности, чтобы получить его, но только его, пока вы не сохраните его снова).
Как вы получаете доступ к вашему массиву? Обычно доступ к SAN осуществляется через сеть Fibre Channel. Существует целый ряд технических различий с "настоящими" сетями, но они не имеют значения для вас - но конкуренция и пропускная способность по-прежнему имеют значение. В частности, с ESX, я нахожу тенденцию недооценивать потребности ввода-вывода хранилища. (Несколько виртуальных машин, использующих одну пару адаптеров HBA, означают, что вы столкнулись с конфликтом на сервере ESX).
с какой нагрузкой мы имеем дело? Одним из других основных преимуществ массивов хранения является механизм кэширования. Как правило, они имеют очень большие кэши и некоторые умные алгоритмы, позволяющие использовать преимущества таких шаблонов рабочей нагрузки, как временная локальность и последовательный или полупоследовательный ввод-вывод. Загрузка массива легче обрабатывать для массива, потому что, несмотря на ужасные потери записи в RAID-6, операции записи находятся под мягким временным ограничением (они могут быть поставлены в очередь в кеше), но операции чтения находятся под жестким временным ограничением (чтение не может завершить, пока блок не будет извлечен). Это означает, что для истинного случайного чтения вы вообще не можете кешировать, что означает худшую производительность.
Проблема определенно в вашем массиве? Похоже, у вас есть одна виртуальная машина с 15 ТБ, и эта виртуальная машина обрабатывает ввод-вывод. Это узкое место прямо здесь. Сколько IOP генерирует виртуальная машина для сервера ESX, и как там происходит конфликт? На что похожа сеть? Сколько других виртуальных машин используют тот же сервер ESX и могут быть источниками конкуренции? Это проход через LUN или хранилище данных VMFS с VMDK?
Итак, есть куча потенциальных проблем, и поэтому трудно откатить их до одного источника. Все, что я могу вам дать, это несколько общих рекомендаций для получения хорошей производительности ввода-вывода.
- быстрые диски (они дорогие, но если вам нужен IO, вам нужно потратить на него деньги).
- Кратчайший путь к хранилищу (не помещайте ВМ в середину, если вы можете избежать этого. Для общих ресурсов CIFS наилучшим подходом может быть голова NAS).
- Попытайтесь сделать свою рабочую нагрузку кэшируемой - я знаю, легче сказать, чем сделать. Но с миллионами файлов, если у вас есть предсказуемый шаблон выборки, ваш массив начнет предварительную выборку, и он получит ОЧЕНЬ быстрее. Вы можете обнаружить, что если вы начнете архивировать файлы в большие "чанки", вы получите производительность (потому что массив / клиент извлечет весь чанк и будет доступен для следующего клиента).
По сути, "множество небольших случайных операций ввода-вывода", особенно на медленных дисках, на самом деле является наихудшим случаем для хранилища, потому что ни один из умных приемов для оптимизации не работает.