Низька продуктивність як iSCSI, так і AoE

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

Для тестування ми використовуємо:

• Fujitsu Siemens RX200 S4 в якості мішені
• Fujitsu Siemens RX200 S4 як ініціатор
• NetGear керував комутатором 1GBit
• бортові NIC (Broadcom w / TOE), EdiMax NIC, Broadcom NIC з TOE - все 1 Гбіт
• цільовий сервер використовує контролер QLogic з 6 дисками WD Blue SATA 6 TB.
• як цільові, так і ініціаторські операційні системи - Ubuntu 16.04 LTS з усіма оновленнями. Вимикач призначений для зберігання. Ми тестуємо зв’язки та багатошляхетність.

Наша проблема - низька швидкість читання. Для тестування ми використовуємо ddі файл розміром 40-100 ГБ.

• локальне читання та запис на цільовому сервері перевищує 300 Мб / с.
• запис на сервер iSCSI або AoE перевищує 200 Мб / с, що задовольняє нас.
• читання з сервера завжди 95-99 Мб / с.

Ми спробували ietd, aoetools, LIO. Ми використовували облігації 2 NIC: balance-rr та LACP, багатосторонніх з rr. Використовуються звичайні та джембові рамки. Нарешті ми навіть зробили пряме Ethernet-з'єднання між ціллю та хостом (без комутатора).

Всі тести дають більше однакових результатів (звичайно, використовуючи загальні NIC без TOE і iSCSI дав на 20-30% гірші результати).

Тестова мережа з iperf показала передачу близько 200 МБ / с (2 Гбіт). Перегляд використання NIC в цілі з bmon показав однакове використання обох пристроїв (кожен близько 50 Мб / с для читання, близько 100 МБ / с для запису).

Оскільки нам не пощастило, ми вирішили використати третій НІК (звичайно, обидві сторони). Результати були дивними:

• 2 NIC - 50MB / s кожен
• 3 NIC - 33 Мб / с кожен

Чи є обмеження на цільове програмне забезпечення, яке вимикає вихід вище 1 Гбіт / с?

Що ми робимо не так?

Щоб вичавити максимальну продуктивність із підключеного до iSCSI пам’яті, слід використовувати Jumbo Frames та MPIO (не LACP). RDMA / iSER рекомендується, якщо ви можете це зробити.

AOE (ATA над Ethernet) старий і лайно. Ми вже позбулися Coraid років тому. Ми використовуємо StarWind https://www.starwindsoftware.com/ в якості цілі iSCSI вже досить давно, і StarWind попросив нас перейти з Coraid у будь-який обсяг пам’яті, що ми могли б зробити.

Тож зараз ми дуже хороші з iSCSI, що надається StarWind та використовуючи Windows, ESX та SCST http://scst.sourceforge.net/ в Linux як ініціатори. З RDMA / iSER він робить до 10 Гбіт, дуже задоволений поки що.

Ваші сподівання на те, як працює агрегація посилань Ethernet, є невірними.

Усі способи агрегації, крім балансу-rr (тобто всі методи, режим яких> 0), не дають вам більшої пропускної здатності для одного з'єднання; скоріше, вони збільшують загальну доступну пропускну здатність, коли встановлено декілька з'єднань від / до постраждалих хостів. Іншими словами, LAG / LACP не дасть вам жодних переваг для цього сценарію одного підключення.

Єдиний метод агрегації, який може дати вам пропускну здатність за один сеанс більше, ніж ви можете мати в одному інтерфейсі, - баланс-rr , який розподіляє пакети в круговій формі. Ви повинні були встановити баланс-RR на обох ініціатора і цілі. Однак велика увага полягає в тому, що це багато в чому залежить від комутаторів.

У будь-якому випадку, якщо ви встановите і цільовий, і ініціатор для балансування rr, безпосередньо з'єднання двох машин повинно підвищити продуктивність. Якщо ні, чи можете ви розмістити повідомлення iperfз балансом rr і обома машинами, безпосередньо підключеними (без комутатора)? Також, будь ласка, опублікуйте точну ddкоманду, яку ви використовували для тестування.

Примітка. Тут я говорю лише про iSCSI. У мене немає досвіду роботи з AoE, окрім читання про це, і я б не втілював його в будь-яку нову інфраструктуру (це майже не існує).

Не використовуйте баланс-rr ні для чого іншого, крім деяких дуже конкретних протоколів точка-точка. Він має жахливу ефективність, коли знаходиться під практично будь-яким навантаженням у реальному світі, і викликає низку проблем з мережею (наприклад, багато тремтіння). Однозначно не використовуйте його з комутатором.

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

Не соромтеся зв’язувати цільову сторону з LACP за шлях (як у двох зв'язках по двох контурах загалом чотири NIC, як приклад конфігурації порту цілі). Це чудово працює і може врівноважувати кілька підключень ініціаторів, які використовують однакові шляхи. Також використовуйте рамки jumbo та iSER, якщо можливо. Використання LACP в цільовому шасі буде врівноважувати з'єднання кожного шляху між декількома NIC.

Використання LACP на ініціаторі буде ефективним лише в тому випадку, якщо він одночасно здійснює безліч з'єднань цільового порталу (не часто для будь-якого навантаження). Навіть якби ви ефективно впроваджували LACP за шлях на ініціатора, це швидко перетвориться на кошмарний кабель для використання (наприклад) чотирьох додаткових тканин у кожній коробці. Якщо вам потрібно більше ~ 2 Гбіт / с пропускної здатності для одного ініціатора, врахуйте ефірну мережу 10 Гбіт / с.

Більшість відповідей на AoE абсолютно невірні, контрфактичні та свідчать про відсутність знань та досвіду AOE. По-перше, це не неіснуюче. CORAID є постачальником за AoE, і вони перезапустили як "SouthSuite", зберігаючи торгову марку CORAID. Вони теж ті самі розробники. Вони виробляють нові продукти та підтримують більшість старих. Вони також підштовхують розвиток AoE вперед, як це чітко видно з їх відкритих списків технічної розсилки. Перевірте веб-сайт, він є актуальним і розповідає всю історію на сторінці їх історії.

Хтось сказав, що AoE не отримає користі від джамбо-кадрів, і він також був неправильним. Він був підтриманий після виходу версії 13 "vbladed". Вам потрібно налаштувати MTU, щоб підтримувати новий розмір кадру, але в іншому випадку він чудово працює.

iSCSI працює в шарі 5 моделі OSI. Це звичайний транспорт - TCP. Це дає деяке виправлення помилок (за рахунок контрольних сум у TCP) і дозволяє маршрутизувати трафік через IP на рівні 3. Саме тут зупиняються переваги iSCSI. Дійсність у реальному світі є дуже жахливою, коли ви насправді справедливо порівнюєте її з чимось на зразок FCP, AoE або FCoE. Я б запросив вас на Google «порівняння ефективності iscsi» для шоу жахів.

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

Агрегація 802.3ad не дуже збільшить пропускну здатність вашого одного потоку навіть у сценарії з круговим циклом. Це також ускладнить вашу мережеву конфігурацію і дасть вам кілька нових можливостей застрелити себе в ногу, невідповідаючи інтервали PDU або неправильно налаштувавши посилання Cisco VPC для підтримки активно-активного стану. Не використовуйте LACP з AoE, нехай він обробляє власну мультипутінг та мультиплексування. Пізніші версії AoE справляються з цим красиво, а в більшості випадків витонченіше, ніж навіть FCP, оскільки все це автоматично. Додаткові порти Ethernet надають вам більшу пропускну здатність та більшу стійкість. Якщо ви поширите порти Ethernet хоста та ініціатора через декілька комутаторів, це може забезпечити ще більше надмірності. Не потрібно налаштовувати режим зв’язування. Крім того, не запускайте IP на тих самих інтерфейсах, які ви використовуєте для AoE.

Коротше кажучи, не слухайте найойерів AoE, вони здаються, що вони не мають великого досвіду і просто катаються на модних мозкових хвилях. Шнур стада. Перейдіть до конфігурації магазину резервного копіювання з налаштованим вручну попереднім завантаженням, і ви, ймовірно, побачите, що пропускна здатність збільшиться вгору. Відмовтеся від використання протоколів агрегації та запустіть крики від iSCSI. І останнє, що перестати використовувати "dd", це не чудовий тест, і він може зазнати поганих ефектів кешування. Використовуйте справжній інструмент для порівняння, як-от "fio", "iozone" або "dbench". Вони дають набагато більш надійні результати.

Я знаю, що LACP призначений для декількох з'єднань. Тестування це було актом відчаю :)

Усі тести проводилися з балансом rr та двома NIC.

Запис у ціль iSCSI:
dd, якщо скопійовано = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 записanych recordów
2097152000 байт (2,1 ГБ, 2,0 ГБ) , 10,1093 с, 207 Мб / с

Читання з цілі iSCSI:
dd, якщо = / mnt / zero.bin of = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 записanych recordów
2097152000 байт (2,1 ГБ , 2,0 ГБ) скопійовано, 16,1684 с, 130 Мб / с

Мережа швидкості:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Клієнт, який підключається до 172.16.10.80, порт
TCP 5001 Розмір вікна TCP: 325 Кбайт (за замовчуванням)
--------------------------------------------- ---------------
[3] локальний порт 172.16.10.70 37024, з'єднаний з портом 172.16.10.80, 5001
[ID] Інтервальна
смуга передачі [3] 0,0-10,0 сек 2,30 Гбіт 1,98 Гбіт / сек.

Тестування за допомогою iperf та jumbo кадрів дало однакові результати.

Я набрав деякої швидкості читання, працюючи на ініціаторі:
hdparm -a 2048 / dev / dm-1
Раніше це було 256, а швидкість читання - 96 Мб / с.
Моя мета - досягти швидкості читання близько 200 Мб / с.

EDIT:
1. Ми не використовуємо LACP - це був тест одного разу.
2. Тестування на баланс-rr та MPIO дає абсолютно однакові результати. Багатосторонність тестувалася за допомогою NIC в різних підмережах.
3. Додавання більшої кількості NIC не збільшує швидкість читання, а лише зменшує використання кожного NIC.
4. Ми вважаємо, що проблема полягає в деякому обмеженні (драйвер, модуль?), Який не дозволяє швидше читати. Але я не впевнений, якщо це цільова чи ініціаторська сторона.


EDIT 2: Просто зробив додатковий тест: налаштував той самий хост як ціль та ініціатор, щоб позбутися мережних апаратних проблем. Я був вражений: точно така ж швидкість читання! 130 Мб / с! Запис становить 227 Мб / с.

як у вас налаштована ніша, чи всі буфери налаштовані належним чином, чи виділили вам достатньо оперативної пам’яті для мережевих буферів. також не використовуйте зв'язок тут, ви можете використовувати 2 канали iscsi та багатостороннім їх на ініціаторі, так само, як ATAoE ініціаторські багатодоріжки через ідентифікатор полиці та ланцюга на будь-якому шляху.