Я слышал, что слишком много путей может повлиять на производительность инфраструктуры хранения. Может кто-нибудь ответить, почему?
Речь идет не о количестве путей для одного сервера, а о рассмотрении всей инфраструктуры — как это влияет на коммутаторы FC/массивы хранения данных и т. д.
Помню, в предыдущей компании, где я работал, у нас был проект по уменьшению количества путей, поскольку это несколько снижало производительность SAN/коммутаторов/внутреннего массива хранения данных (не помню подробностей, но у нас были коммутаторы Brocade, и мы переходили с массива хранения данных EMC на NetApp).
Быстрое гугление не дало особых результатов. Наша команда DBA запросила 20 голосовательных дисков для бэкэнда Oracle, по 5 ГБ каждый, и, оставив в стороне накладные расходы на управление, я подумал, что это также может повлиять на производительность.
решение1
Боюсь, я не могу рекомендовать вам статью, но надеюсь, вы уже нашли хороший источник информации. Если нет, вот что я помню по этой теме.
Насколько я помню, в Brocade SAN могла возникнуть очень редкая проблема с избыточным количеством ISL, когда коммутаторов действительно много и они соединены по топологии full-mesh. Могу ошибаться, но это было связано с FSPF, когда он не мог перечислить все пути. Не уверен, актуально ли это сейчас.
Я думаю, что ограничение числа путей может быть полезным, если на коммутаторах включена ограничительная политика In-Order Delivery (IOD). Но если включен IOD, это означает, что вы уже столкнулись с проблемами с неупорядоченными кадрами (вызванными ISL-flapping и т. д.) и устройствами, которые не могут этого выдержать, но вам придется жить как есть (например, потому что у вас длинные пути к удаленному сайту).
Последовательные операции обычно обслуживаются быстрее системами хранения. Поэтому массивы пытаются обнаружить последовательные операции чтения-записи, чтобы включить соответствующие алгоритмы и обеспечить лучшую производительность. Наличие чрезмерного количества путей к одному и тому же LUN иногда может сбивать с толку системы хранения, и они могут начать обрабатывать их как случайный ввод-вывод без применения последовательных оптимизаций.