У чому сенс маршрутизації SAN?

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

Наприклад, у мене є тканина з масивами зберігання від постачальника А. Нове сховище від постачальника В було налаштовано, і замість того, щоб розширювати поточні тканини, було обрано маршрутизацію між старою та новою.

Чи є найкраща практика щодо максимального розміру тканини? Коли найкраще використовувати маршрутизацію SAN замість подовження поточних тканин?

Існує кілька причин для використання розгорнутого підходу до Fiber Channel:

• У вас є окремі, від’єднані острови, з якими ви хочете підключитися, але зусилля для того, щоб не було конфліктів у базах даних про зонування, є надзвичайними.
• У вас є окремі острови підключення, такі як тканина FC на основі Brocade та тканина FCIP на основі Cisco, які потрібно з'єднати і не довіряти тканині, щоб правильно сходитися, якщо вони об'єднані.
• Твоя тканина надзвичайно велика, і ти регулярно стикаєшся з унікальністю-обмеженнями під час внесення змін.
• Тканина настільки велика, що будь-які зміни в конфігурації тканини займатимуть занадто довго, щоб розповсюджуватися скрізь.

У кожному з цих маршрутизаторів допоможе об'єднати дві тканини, які в іншому випадку потребують великих зусиль для злиття або зменшення адміністративної складності через масштаб.

Багато в чому ви використовуєте маршрутизатор FC, коли біль від нерегулярного використання перевищує біль від використання.

Що стосується вашого питання щодо найкращої практики, я не вірю, що тут існує багато загальноприйнятих практик. Найближче до нас іде те, що вам потрібно злити дві тканини на основі різних рішень постачальника (наприклад, Brocade-FC / Cisco-FCIP, який я використовував вище), хоча це "надлишок параної", а не демонстративний факт.

Ви додаєте роутер, коли його немає, було б більш болісно. Якщо у вас є два великих центри обробки даних, проведіть чотири роки, будуючи їх самостійно, а потім, нарешті, отримайте деякий зв’язок між ними. Дві тканини ФК можуть бути дуже складними. Поєднання обох в одну тканину вимагатиме перейменування сотень / тисяч псевдонімів та зон, шанси на друк десь порушити зв'язок не маленькі. У такому випадку використання маршрутизатора для з'єднання тканин було б швидше і спричинило б менше потенційних зривів, ніж спроби злиття тканин.