Занадто багато шляхів - вплив на продуктивність ФК

Я чув, що занадто багато шляхів може спричинити вплив продуктивності інфраструктури зберігання. Може хтось, будь ласка, відповість, чому?

Це не стосується кількості шляхів для одного сервера, а перегляду всієї інфраструктури - який вплив на FC комутатори / масив зберігання тощо.

Я пам’ятаю, що в попередній компанії, в якій я працював, у нас був проект зменшити кількість шляхів, оскільки він мав певну ефективність у SAN / комутаторах / масиві резервного зберігання (не пам'ятаю деталі, але там ми мали перемикачі Brocade і мігрували зі сховища ЕМС масив до NetApp).

Швидкий гуглінг не дав великих результатів. Наша команда DBA попросила 20 дисків для голосування за Oracle, 5 Гб кожен, і відклала управління накладні, я подумав, що це може також досягти ефективності.

Боюся, я не можу рекомендувати вам статтю, але сподіваюся, ви вже знайшли хороше джерело інформації. Якщо ні, ось що я можу згадати з цього приводу.

• Як я пам’ятаю, дуже рідкісна проблема із надмірною кількістю ISL може виникнути в Брокаді SAN, коли існує дійсно велика кількість комутаторів, і вони з'єднуються за допомогою топології з повною сіткою. Я можу помилятися, але це стосувалося FSPF, коли він не в змозі перерахувати всі шляхи. Я не впевнений, чи актуально це сьогодні.

• Я думаю, що обмеження кількості шляхів може бути бажаним, якщо вмикається обмежувальна політика доставки замовлень (IOD). Але якщо функція IOD увімкнена, це означає, що ви вже стикалися з проблемами із позачерговими кадрами (спричиненими ISL-плясканням тощо) та пристроями, які не переносять цього, але вам доведеться жити так, як є (наприклад, тому що у вас довгі шляхи до віддаленого сайту).

• Системи зберігання зазвичай обслуговують послідовні операції швидше. Тож масиви намагаються виявити послідовні операції читання-запису, щоб увімкнути відповідні алгоритми та забезпечити кращу продуктивність. Маючи надмірну кількість шляхів до того ж LUN, іноді можна заплутати системи зберігання, і вони можуть почати трактувати їх як випадковий IO без застосування послідовних оптимізацій.