Чому MPIO замість 802.3ad Team для iSCSI

Здійснюючи свій перший сервер для iSCSI-цілі, і я думав, що я відключуся до запуску, об'єднавши свій NIC на сервер (звичайна команда 802.3ad).

Однак, з багатьох джерел в Інтернеті, я бачу, що це НЕ рекомендується, і замість цього слід використовувати MPIO (у цій рекомендації не було конкретного розміру, і, здається, він застосовується з кластера 3 вузлів до великих кластерів з десятків вузлів і вище).

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

— морлей
джерело

Чи можете ви трохи розширити архітектуру iSCSI? Скільки адрес ініціатора / цілі ви працюєте, скільки фізичних комутаторів, всі однієї підмережі чи декількох?

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

Конкретні технічні причини цього залежать від архітектури, тому я можу бути набагато конкретнішим, якщо ви надасте додаткову інформацію про налаштування вашої мережі iSCSI. Кілька загальних прикладів:

Без будь-якого MPIO, ваша IP-розмова з ініціатором націлювання - це лише одна розмова. 802.3ad передбачає, що порядок пакетів у розмові не змінюється (і ви все одно не хочете, щоб ваш трафік iSCSI вийшов з ладу), тому ви обмежені пропускною здатністю одного посилання.
MPIO виявляє та обробляє збої шляху, тоді як 802.3ad може компенсувати лише пошкодження посилання - і лише в тому випадку, якщо помилка цього зв’язку виявлена правильно. Якщо ваша карта NIC зависає, але все-таки повідомляється про хороше посилання або конфігурація вашого комутатора перекручена для конкретного порту, ви, швидше за все, втратите підключення пам’яті, незважаючи на те, що друга посилання все ще працює.
Ви прив’язані до одного фізичного перемикача, замість того, щоб мати можливість передавати NIC вашого хоста на різні комутатори.

— Шейн Медден
джерело

Привіт Шейн, дякую за відповідь - для нашої установки це єдина підмережа зберігання даних та 1 фізичний комутатор, однак у документації не вказано розмір, про який він просто сказав використовувати MPIO. З ваших коментарів, мабуть, можна, звичайно, використовувати командування, але MPIO є кращим. Добре пояснення, якщо ви не хочете більше додати, ви відповіли на моє запитання і незабаром відзначите його.

— morleyc

@ g18c Yup - тому головними перевагами, які ви отримаєте від MPIO замість агрегації посилань, буде потенціал для підвищення пропускної здатності (якщо вашої пропускної здатності достатньо для насичення єдиного NIC), а також можливість граціозно працювати з більш широким діапазоном стани невдачі. Я думаю, питання полягає в тому, чи є якісь конкретні причини, що ви віддаєте перевагу використовувати 802.3ad замість MPIO?

— Шейн Мадден

MPIO отримує особливу корисність, коли налаштування ISCSI більш досконала - тому що у MPIO у вас є окремі логічні з'єднання, які можуть робити зайві кінцеві точки. SAN може повторюватись на задньому плані, і 2-3 цілі насправді - це різні боєприпаси. Поки у вас є сценарій "єдиний шлях, єдиний NIC", переваги не такі вже й жорстокі.

— TomTom