VMWare ESXi, RHEL, LUKS и сетевая задержка

Question

Моя компания столкнулась с проблемой производительности сети, которая, по-видимому, поставила в тупик всех "экспертов", с которыми мы работаем (поддержка VMWare, поддержка RHEL, наш поставщик хостинга управляемых услуг).

Проблема заключается в том, что задержка в сети между нашими виртуальными машинами (даже виртуальными машинами, расположенными на одном физическом хосте) увеличивается - до 100 раз и более!- благодаря пропускной способности сети. Например, без какой-либо сетевой нагрузки задержка (измеренная с помощью ping) может составлять ~0,1 мс. Начните передачу пары файлов размером 100 МБ, и задержка возрастет до 1 мс. Инициируйте группу (~20 или около того) одновременных передач данных между двумя виртуальными машинами, и задержка между виртуальными машинами может увеличиться до более 10 мс.

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

У нас есть то, что я думаю, довольно стандартная среда:

• ESXi 6.0u2
• 4 блейд-сервера Dell M620 с 2 процессорами Xeon E5-2650v2 и оперативной памятью 128 ГБ
• SolidFire SAN

И наша базовая конфигурация виртуальной машины состоит из:

• RHEL7, минимальная установка
• Несколько LUN, настроенных для точек монтирования в /boot, /, /var/log, /var/log/ Audit, /home, /tmp и swap
• Все разделы, кроме / boot, зашифрованы с помощью LUKS (через LVM)

Наши виртуальные машины сервера баз данных работают на Postgres 9.4.

Мы уже попробовали следующее:

• Измените виртуальный сетевой адаптер с VMNETx3 на e1000 и обратно
• Отрегулируйте настройки стека RHEL Ethernet
• Использование опции ESXi "низкая задержка" для виртуальных машин
• Обновление наших хостов и vCenter с ESX 5.5 до 6.0u2
• Создание базовых виртуальных машин (как описано выше с LUKS и т. Д., Но без каких-либо наших производственных служб на них) для тестирования
• Перемещение хранилища данных из SSD SolidFire SAN в локальное (на лопатке) вращающееся хранилище

Ни одна из этих улучшенных задержек в сети. Единственный тест, который показал ожидаемую (не ухудшающуюся) задержку, - это когда мы устанавливаем вторую пару базовых виртуальных машин без шифрования LUKS. К сожалению, нам нужны полностью зашифрованные разделы (для которых мы управляем ключами), потому что мы имеем дело с регулируемыми, конфиденциальными данными.

Я не понимаю, как ЛУКС - сам по себе - может быть виноват здесь. Скорее, я подозреваю, что виноват LUKS, работающий с некоторой комбинацией ESX, нашего хостингового оборудования и / или конфигурации нашего виртуального компьютера.

Я выполнил тестирование в более простой среде (MacBook Pro, i5, 8 ГБ ОЗУ, VMWare Fusion 6.0, виртуальные машины Centos7, настроенные аналогично LUKS на LVM и с теми же сценариями тестирования) и не смог воспроизвести проблему задержки. Независимо от того, какой объем сетевого трафика я отправлял между виртуальными машинами, задержка оставалась постоянной и составляла около 0,4 мс. И это было на ноутбуке с кучей происходящего!

Любые указатели / советы / решения будут с благодарностью!

Answer 1

После тщательного изучения и сравнения неработающих виртуальных машин с работающими виртуальными машинами мы определили проблему как неправильный выбор для расширенного параметра "Чувствительность к задержке".

Для наших плохо работающих ВМ этот параметр был установлен на "Низкий". После изменения значения "Нормальный" и перезапуска виртуальных машин задержка упала в ~100 раз, а пропускная способность (которую мы изначально не замечали также было проблемой) увеличилась в ~250 раз!