Почему приложение с интенсивным использованием диска должно работать быстрее в сети хранения данных, чем на физическом диске?

21

Почему приложение с интенсивным использованием диска должно работать быстрее в сети хранения данных, чем на физическом диске? Я ожидал бы, что физический диск будет немного быстрее, но на самом деле процесс работал в 100 раз быстрее, когда его рабочий диск был настроен на раздел в SAN.

Мы предполагаем, что SAN оптимизирована из коробки, чтобы быть быстрой, тогда как параметры настройки физического диска связаны с ОС (Solaris) и не были затронуты или исправлены ОС.

Во время наибольшей активности дисковый ввод-вывод работал на 100%, и время для завершения записи составляло более 2 секунд, поскольку несколько процессов записывали на диск одновременно.

(К вашему сведению, это было приложение Informatica PowerCenter)

performance storage-area-network hard-drive tuning Стюарт Вудворд
источник

Ответы:

23

Я совсем не удивлен. В массивах SAN обычно задействовано много дисков. Ограничивающим фактором для дискового ввода-вывода является скорость отдельного диска и их стек. 6 дисков локально в RAID10 будут работать лучше, чем 2, а 80 дисков в сети SAN будут работать лучше, чем 10 дисков локально. Конечно, есть переменные, но так оно и должно работать.

Кроме того, если в SAN задействованы твердотельные накопители, все становится очень быстрым.

sysadmin1138
источник
15

Это почти наверняка связано с кэшированием. Вероятное DAS имеет минимальное кэширование, где большинство корпоративных сетей хранения данных имеют несколько гигабайт кэша. Я предполагаю, что приложение насыщает кэш DAS, но не SAN.

Крис С
источник
1
Очевидная задержка в SAN идет дольше, чем в DAS, но общая пропускная способность выше в SAN со всем его кэшированием. Хороший ответ.
Мэтт
и затем часто имеется кэш с опережением чтения, поэтому его случайное чтение / запись получает наибольшее количество ударов, а затем вы можете кешировать записи, так что на него влияют только случайные операции чтения, хотя это все еще довольно небольшая задержка.
Silverfire
1
Правильно настроенная подсистема хранения в SAN, которая не перегружена, должна давать вам случайное время записи около 1-2 мс.
MikeyB
@MikeyB Я не согласен с тобой. 1-2ms писать в SAN кажется правильным. Но конфигурация SAN Чарльза была в 100 раз быстрее, чем его перегруженные физические диски (записи были> 2 секунды для последних). Так что даже его производительность SAN не так хороша, на 20 мс, а не на 1-2 мс ...?
Элли Кессельман
9

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

  • Требуется ли для вашей рабочей нагрузки время быстрого поиска или высокая пропускная способность, или и то, и другое?
  • Сколько шпинделей на SAN LUN по сравнению с локальным диском?
  • Какова скорость шины между SAN LUN и сервером по сравнению с локальным интерфейсом диска?
  • Сколько кэша чтения / записи доступно на SAN LUN против локального диска?
  • На какой скорости вращаются диски на SAN LUN по сравнению с локальным диском?
  • Какие другие операции ввода-вывода выполняются на SAN LUN по сравнению с локальным диском?
  • На каком уровне RAID находятся массивы в SAN и локальном хранилище?

Все это повлияет на вашу производительность на SAN и локальном диске.

Крис Торп
источник
1

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

С локальной дисковой подсистемой вы также, вероятно, делитесь доступом к головкам чтения / записи с другими операциями, такими как чтение / запись для замены, доступ к файлам локальной ОС и библиотеки, доступ к приложениям и т. Д. для всех действий чтения / записи перемещение головок чтения / записи из одной области диска для охвата одного набора действий в другую для удовлетворения требований вашего приложения, безусловно, может сказаться на производительности.

Джеймс Пулли
источник