Производительность сети хранения данных

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

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

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

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

• Какое базовое хранилище вы используете?

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

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

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

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

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

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

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

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

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