Налаштування пам’яті iSCSI


29

Це канонічне запитання про iSCSI, яке ми можемо використовувати як посилання.

iSCSI - це протокол, який розміщує команди SCSI як корисне навантаження в мережеві пакети TCP. Як такий, він піддається іншому набору проблем, ніж, скажімо, Fiber Channel. Наприклад, якщо посилання стає перевантаженою і буфери комутатора заповнені, Ethernet за замовчуванням скидає кадри замість того, щоб сказати хосту сповільнитись. Це призводить до повторної передачі, що призводить до високої затримки для дуже невеликої частини трафіку.

Існують рішення цієї проблеми в залежності від операційної системи клієнта, включаючи зміни мережевих налаштувань. У наступному списку ОС, як виглядатиме оптимальна конфігурація клієнта iSCSI? Чи передбачає це зміна налаштувань на перемикачах? А як щодо сховища?

  • VMWare 4 і 5
  • Windows Hyper-V 2008 та 2008r2
  • Windows 2003 та 2008 на голий метал
  • Linux на голому металі
  • AIX VIO
  • Будь-яка інша ОС, на яку ви думаєте, буде доречною

iSCSI є набагато складнішим за це - але стосовно IP-стеку все застосовується, що стосується IP-з'єднань з високою пропускною здатністю та низькою затримкою - тут не особливо особливе.
Нільс

Відповіді:


6

Я не знайомий з VMWare, але я використовую Xenserver і використовував Hyper-V (R2).

З моєю поточною конфігурацією Xenserver у мене є:

  • 8 серверів Dell Poweredge 29xx
  • 2 вимикачі Dell Powerconnect 6248
  • 2 Dell MD3000i SAN (iSCSI)

Я налаштував свої перемикачі в багатошарову конфігурацію та оптимізований для iSCSI:

  • Розділення моїх комутаторів на 3 VLANS (2 для iSCSI-трафіку та 1 для управління)
  • Використання JumboFrames
  • Застосування оптимізацій "iSCSI", які має powerconnect

Кожен сервер має декілька мережевих карт для забезпечення з'єднання з кожним комутатором, що, в свою чергу, забезпечує надмірність через багатосторонній шлях між серверами та iSCSI SAN. VLAN-адреси iSCSI не містять іншого трафіку, ніж iSCSI.

Я радий повідомити, що з цією конфігурацією «кластер» Xenserver працює чудово.

Зі сторони, у мене є сервер Windows 2008, підключений iSCSI безпосередньо HP SAN (старий файловий сервер). Він використовувався для запуску Windows 2003 і регулярно припиняв би з'єднання (навіть після перевстановлення 2003 року); однак, як тільки я оновив до Windows 2008, він залишається підключеним.

Я з радістю відповім на будь-яке запитання щодо моєї настройки.


1
Використовуєте ви укладальні кабелі між двома вимикачами Dell?
SpacemanSpiff

Чому iSCSI? Чому б не DRBD на безпосередньо підключеному MD3000?
Нільс

@SpacemanSpiff Мої перемикачі не складені.
Стів

@Nils Я не досліджував DRBD, хоча я чув про нього. Що запропонує DRBD для iSCSI для мого безпосередньо підключеного сховища?
Стів

DRBD не має накладних витрат на SCSI. Інша справа, що ви не можете позбутися iSCSI-клієнтського процесу, коли ваш iSCSI-сервер загине або недоступний (останній не повинен бути проблемою у вашій налаштуванні).
Нілс

3

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

Профіль QoS до портів, а також вимкнення управління штормом, встановлення MTU до 9000, включення контролю потоку та введення портів у portfast

Пропускна здатність та затримка

Оновлено прошивку, драйвери та інші системи

MPIO

Jumbo Frames / MTU

Зі збільшенням швидкості мережевих зв’язків кількість потенційно генеруваних пакетів також збільшується. Це дає все більше і більше часу процесора / переривання, витраченого на генерування пакетів, що призводить до того, що надмірно обтяжує передавальну систему і сприймає надмірну кількість пропускної здатності зв’язку з обрамленням.

Так звані "джамбо" кадри - це Ethernet-кадри, що перевищують канонічну межу 1518 байт. Хоча цифри можуть змінюватися залежно від постачальників комутаторів, операційних систем та NIC, найбільш типовими розмірами пакетів jumbo є 9000 та 9216 байт (останній є найпоширенішим). Зважаючи на те, що приблизно 6X дані можуть бути поміщені в 9K кадр, кількість фактичних пакетів (і переривань) зменшується на аналогічну кількість на хості. Ці посилення особливо виражені на швидкісних (тобто 10GE) посиланнях, які надсилають великі обсяги даних (тобто iSCSI).

Увімкнення джомбових кадрів вимагає конфігурації як хоста, так і комутатора Ethernet, і перед реалізацією слід уважно поставитися до уваги. Слід дотримуватися кількох вказівок:

1.) У межах заданого сегмента Ethernet (VLAN) всі хости та маршрутизатори повинні мати однаковий MTU. Пристрій без належної конфігурації побачить більші кадри як помилки посилань (конкретно "гіганти") та видалить їх.

2.) У межах протоколу IP двом хостам з різними розмірами кадру потрібен певний механізм узгодження відповідного загального розміру кадру. Для TCP це відкриття MTU (PMTU) і покладається на передачу ICMP недоступних пакетів. Переконайтеся, що функція PMTU увімкнена у всіх системах і чи дозволяють будь-які правила ACL або брандмауера ці пакети.

Контроль потоку Ethernet (802,3x)

Незважаючи на те, що його рекомендують деякі постачальники iSCSI, просте керування потоком Ethernet 802.3x не повинно бути ввімкнено в більшості середовищ, якщо всі порти комутаторів, NIC та посилання повністю не присвячені трафіку iSCSI і нічого іншого. Якщо на посиланнях є будь-який інший трафік (наприклад, обмін файлами SMB або NFS, серцебиття для кластеризованого сховища або VMware, керування / моніторинг трафіку NIC та ін.), Простий 802.3x контроль потоку не слід використовувати, оскільки він блокує цілі порти та інший трафік, який не належить до iSCSI, також буде заблокований. Підвищення продуктивності управління потоком Ethernet часто мінімальне або взагалі не існує, реалістичне порівняльне оцінювання слід проводити на всіх комбінаціях OS / NIC / комутатор / накопичувач, що розглядаються, щоб визначити, чи є якась реальна користь.

Актуальне питання з точки зору серверів: Чи зупиняю мережевий трафік, якщо мій NIC або Мережа перевиконаний, або я починаю скидати та повторно передавати пакети? Увімкнення регулювання потоку дозволить спорожняти буфери NIC на стороні приймача, але буде підкреслювати буфери на стороні відправника (як правило, мережевий пристрій буде буферним тут).

Контроль застою TCP (RFC 5681)

TOE (двигуни розвантаження TCP / IP)

iSOE (двигуни для розвантаження iSCSI)

LSO (сегментація TCP / велике відправлення відправки)

Ізольована мережа

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

1.) Фізична ізоляція - усі ініціатори мають один або більше NIC, присвячених виключно трафіку iSCSI. Це може (а може й не означає) спеціальне мережеве обладнання в залежності від можливостей обладнання, про яке йде мова, та конкретних вимог щодо безпеки та експлуатації в даній організації.

2.) Логічна ізоляція - здебільшого у швидких (тобто 10GE) мережах ініціатори мають теги VLAN (див. 802.1q), сконфігуровані для розділення трафіку на зберігання та без зберігання.

У багатьох організаціях застосовуються додаткові механізми, які також гарантують, що ініціатори iSCSI не в змозі дістатися один до одного за допомогою цих виділених мереж і що, крім того, ці виділені мережі недоступні від стандартних мереж даних. Заходи, що застосовуються для цього, включають стандартні списки контролю доступу, приватні VLAN та брандмауери.

Щось тут і про задній план та перемикання тканини.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP тощо)

Придушення руху (управління штормом, керування кількома / широкими передачами)

Безпека

Аутентифікація та безпека

ЧАП

IPSec

Карту LUN (кращі практики)


Чи є якісь налаштування для RFC 5681 на будь-якому пристрої? Якщо ні, то цей розділ слід видалити.
Нілс

Чи варто додати, що джомбові кадри рідко підтримуються для реплікації iSCSI (оскільки всі посередницькі пристрої WAN повинні були б їх підтримувати)?
Джеремі

@ Джеремі впевнений - напишіть це вище. Навіть у локальній мережі - якщо ви забудете один пристрій в дорозі (або якщо ваша аутсорсингова команда щось неправильно налаштовує), шлях MTU не підтримуватиме джамбо кадри.
Нільс

Погодьтеся з Джеремі. Нілс, якщо TCP-CC доступний, що дає можливість отримати переваги та наслідки, їх слід принаймні окреслити.
Кріс S

1

Деякий розгляд та дослідження, які ви повинні взяти суб'єктивно щодо:

1) Мультипутінг - Ваше рішення SAN та ваша ОС, будь то гіпервізор чи ОС із голими металами, для належного функціонування може знадобитися певне програмне забезпечення для постачальника.

2) Ініціатори - Вам потрібно перевірити, чи достатньо продуктивності програмного ініціатора на основі вимог. У багатьох НІК є розвантажувальні можливості iSCSI, які можуть значно покращити пропускну здатність, але, як відомо, деякі старші гіпервізори досить приємно підтримують їх. Більш зрілі пропозиції (ESXi 4.1+) здаються хорошими.

3) Безпека / дозволи - не забудьте повністю перевірити, яким ініціаторам потрібен доступ до яких LUN ... Ви потрапите в невдалий день, якщо адміністратор на одній із ваших машин Windows зробить "диск ініціалізації" на диску, який насправді використовується іншим сервером як сховище даних VMware.


Що стосується багатодоріжжя - насправді ви також можете досягти цього за допомогою різних мереж - що з IP-протоколом трохи складніше, ніж з FC-SAN (де концепція SAN A / B з різними апаратними тканинами є досить поширеною).
Нільс

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

Я спробував (рідний) мультипутінг на SLES11 на різних VLAN. Хитра частина полягала в тому, щоб змінити конфігурацію декількох контурів, тому цілі iSCSI, які перейшли до тієї ж фізичної пам’яті, розглядалися як один і той же пристрій.
Нільс
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.