Фон

У нас трапився інцидент, коли кластер Windows відмовлення зазнав перерви. Після смерть показали, що вузол "видалено", як описано в цій статті .

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

У цьому асоційованій статті VMware KB йдеться про збільшення Small Rx Buffersта Rx Ring #1налаштування, але застерігає, що збільшення цих надмірних величин може різко збільшити накладні витрати на пам'ять хоста.

Після перевірки Network Interface\Packets Received Discardedлічильників продуктивності для наших ~ 150 віртуальних машин Windows, у 22 vNIC серед 16 гостей було викинуто кілька пакетів.

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

Запитання

1. Яка залежність між кількістю буферів та розміром кільця?
2. Як можна обчислити об'єм пам'яті, використаний для заданих значень цих параметрів?
3. Оскільки ці налаштування знаходяться в самому NIC в гостьовій ОС, я припускаю, що це налаштування драйвера. Це змушує мене думати, що використана оперативна пам’ять може бути підказками або не підказками.
   1. Це правильно?
   2. Якщо так, то я повинен турбуватися про це?
4. Чи є проблеми, які я тут не беру до уваги?

Ми намагаємося визначити, чи є недолік у встановленні їх максимуму для постраждалих віртуальних машин, окрім використання VMware хост-пам'яті. Якщо, наприклад, ми збільшуємо ризик виснаження пам’яті у басейні у гостя, ми схильні починати з малого.

Деякі з цих питань (можливо, всі) можуть не стосуватися VMware або віртуалізації.

Яка залежність між кількістю буферів та розміром кільця?

Вони пов'язані, але незалежні. Rx "кільце" відноситься до набору буферів в пам'яті, які використовуються в якості черги для передачі вхідних мережевих пакетів від хоста (гіпервізора) до гостя (Windows VM). Пам'ять зарезервується у гостя мережевим драйвером, і вона відображається у пам'яті хоста.

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

Збільшення розміру кільця може допомогти пом'якшити цю проблему. Якщо ви збільшите її, на рингу одночасно з’явиться більше слотів. Це відображається у другому налаштуванні, "Малі буфери Rx", що є загальною кількістю наявних буферів, які можна використовувати для заповнення прорізів у кільці. У кільці має бути принаймні стільки буферів, скільки слотів. Зазвичай ви хочете більше. Коли гість знімає буфер з кільця для передачі стеку гостьової мережі, він не завжди може бути негайно повернутий назад драйверу. Якщо це трапиться, наявність запасних буферів для заповнення кільця означає, що ви можете піти довше, не скидаючи пакетів.

Кільця Rx №1 / Малі буфери Rx використовуються для кадрів, які не є перемичками. Якщо у вас конфігурація NIC за замовчуванням, це єдине кільце, яке буде використовуватися.

Як можна обчислити об'єм пам'яті, використаний для заданих значень цих параметрів?

Якщо припустити, що ви говорите про кадри, що не є джамбо, кожен буфер повинен бути достатньо великим, щоб зберігати весь мережевий пакет, приблизно 1,5 кбіт. Тож якщо у вас є 8192 буферів, це використовує 12 МБ. Більше кільце також використовуватиме більше пам’яті, але дескриптори невеликі (байти), тому це справді буфери, про які ви повинні турбуватися.

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

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

Чи є проблеми, які я тут не беру до уваги?

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

Джерело: Я працював у VMware.

У мене немає відповіді на пункт 1-2-3, але ви можете дізнатися у свого віртуального інженера про конфігурацію хоста Vmware. Якщо він VCP, він зрозуміє речі :)

Ви дійсно повинні перевірити свого хоста, оскільки проблеми з Windows можуть бути в хості, а не в гостях.

Існує багато апаратних функцій, які можуть пояснити ваші проблеми, пряму дорогу io, rss, vcpu, схему управління потужністю ...

Я можу надати вам посилання, яке допоможе вашій віртуальній команді, або ви :)

Це посилання стосується налаштування хоста http://buildvirtual.net/tuning-esxi-host-networking-configuration/

І цей жирний pdf:

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

І це про rss:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008925

Я не в змозі повністю шукати та вказувати на потрібні сторінки, тому я прошу самі шукати деталі ... (вибачте)

У програмі Fail over Cluster є 4 налаштування, які можна змінити; і вони не впливатимуть на буфери, підкачки або несторінкові повідомлення ... Це змінює спосіб Fail over Cluster приймає рішення вважати вузол "видаленим". Ці налаштування:

SameSubnetDelay SameSubnetThreshold CrossSubnetDelay CrossSubnetThreshold

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

Повернувшись у понеділок, я перевірте це повідомлення, якщо у вас виникнуть додаткові запитання

HTH, Едвін.