SAN Performance

Question

Имейте вопрос относительно производительности SAN, в частности, EMC VNX SAN. У меня есть значительное количество процессов, распределенных по числу блейд-серверов, работающих одновременно. Количество процессов обычно составляет около 200. Каждый процесс загружает 2 небольших файла из хранилища, один 3 КБ один 30 КБ. Есть миллионы (20) файлов для обработки. Эти процессы выполняются на Windows Server на VMWare. Первоначально он был настроен на 1 TB LUN в SAN, который был включен в один 15-тибайтный диск в VMWare, а затем делился как общий сетевой ресурс из одного экземпляра Windows ко всем процессам. Процессы, выполняемые одновременно и производительность, являются ужасающими. По существу, одновременно 200 одновременных запросов обслуживаются SAN через общий ресурс Windows, и SAN слишком плохо справляется с этим. Я ищу рекомендации для повышения производительности. Заранее спасибо ...

Answer 1

Со всеми вопросами производительности есть степень «это зависит».

Когда вы говорите о доступе к сети SAN, существует цепочка потенциальных узких мест, которые нужно разгадать. Во-первых, нам нужно понять, в чем проблема:

• Есть ли у нас проблемы с пропускной способностью - например, устойчивый перенос или латентность?
• Похоже, мы смотрим на случайное чтение IO - это одна из самых тяжелых рабочих нагрузок для обслуживания, поскольку интеллектуальное кэширование не работает.

Итак начнем с самого начала:

• Какой основной памяти вы используете?

  Вы попали в ловушку покупки большого SATA, настроив его на RAID-6? Я видел, как много мест делают это, потому что это выглядит как дешевые терабайты, не делая действительно суммы на производительности. Привод SATA начинает замедляться со скоростью около 75 операций ввода-вывода в секунду. Если у вас есть большие диски - например, 3 ТБ - это 25 IOP на терабайт. В качестве приблизительного эмпирического правила, 200 на привод для FC/SAS и 1500 для SSD.

• Вы многоуровневые? Хранение - это умный трюк создания «сэндвича» из разных скоростей диска. Обычно это работает, потому что обычно, только небольшая часть файловой системы «горячая», поэтому вы можете разместить горячую часть на быстром диске, а холодная часть на медленном диске, а средняя производительность выглядит лучше. Это не работает для случайного ввода IO или холодного чтения. Он также не работает для полного переноса диска, так как только 10% его (или любая доля) могут быть «быстрыми», а все остальное должно идти медленным путем.

• Что вы имеете в виду на уровне массива? Точка SAN заключается в том, что вы суммируете свою производительность, чтобы каждый пользователь имел более высокий пик и более низкий средний показатель, так как это отражает больше всего рабочих нагрузок. (Когда вы работаете над документом, вам нужен всплеск производительности, чтобы получить его, но потом почти ничего, пока вы его не сохраните).

• Как вы обращаетесь к вашему массиву? Обычно доступ к сети SAN осуществляется через сеть Fibre Channel. Существует целый ряд технических различий с «реальными» сетями, но они вам не важны, но конкуренция и пропускная способность все еще существуют. С ESX, в частности, я нахожу, что существует тенденция недооценивать потребности хранения IO. (Несколько виртуальных машин, использующих одну пару HBA, означают, что вы получаете конкуренцию на сервере ESX).

• с какой рабочей нагрузкой мы имеем дело? Одним из других основных преимуществ массивов хранения является механизм кэширования. Как правило, они имеют очень большие кеши и некоторые умные алгоритмы, чтобы использовать преимущества шаблонов рабочей нагрузки, таких как временная локальность и последовательный или полупоследовательный IO. Нагрузочные нагрузки легче обрабатывать для массива, потому что, несмотря на ужасное ограничение записи на RAID-6, операции записи находятся под мягким временным ограничением (их можно поставить в очередь в кеш), но операции чтения находятся под жестким ограничением времени (чтение не может до тех пор, пока блок не будет извлечен). Это означает, что для истинного случайного чтения вы в принципе не можете кэшировать вообще, а это означает, что вы получаете наихудшую производительность.

• Является ли проблема определенно вашего массива? Похоже, что у вас есть одна виртуальная машина с 15 ТБ, и эта виртуальная машина обрабатывает IO. Это узкое место прямо здесь. Сколько IOPs является генерацией VM на сервер ESX, и что такое конкуренция? Что такое сеть? Сколько других виртуальных машин используют один и тот же сервер ESX и могут быть источниками конкуренции? Это пропуск через LUN или хранилище данных VMFS с помощью VMDK?

Итак, есть множество потенциальных проблем, и поэтому трудно откатить их обратно в один источник. Все, что я могу вам дать, - это некоторые общие рекомендации для получения хорошей производительности ввода-вывода.

• быстрые диски (они дороги, но если вам нужно IO, вам нужно потратить на это деньги).
• Самый короткий путь к хранилищу (не размещайте виртуальную машину в середине, если вы можете ее избежать). Для акций CIFS лучше всего использовать голову NAS.
• Попробуйте сделать вашу рабочую нагрузку кешируемой - я знаю, проще сказать, чем сделать. Но с миллионами файлов, если у вас есть предсказуемый шаблон выборки, ваш массив начнет предварительную выборку, и он будет намного быстрее. Вы можете обнаружить, что если вы начнете архивировать файлы в большие «куски», вы получите производительность (потому что массив/клиент будет извлекать весь фрагмент, и он будет доступен для следующего клиента).

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