Моя компания сталкивается с проблемой производительности сети, которая, по-видимому, поставила в тупик всех «экспертов», с которыми мы работаем (поддержка VMWare, поддержка RHEL, наш провайдер управляемых услуг).
Проблема в том, что сетевая задержка между нашими виртуальными машинами (даже виртуальными машинами, находящимися на одном физическом хосте) увеличивается - до 100 раз и более! - с увеличением пропускной способности сети. Например, без какой-либо сетевой нагрузки задержка (измеренная с помощью ping) может составлять ~ 0,1 мс. Начните передавать пару файлов размером 100 МБ, и задержка вырастет до 1 мс. Инициируйте группу (около 20 или около того) одновременных передач данных между двумя виртуальными машинами, и задержка между виртуальными машинами может увеличиться до 10 мс.
Это огромная проблема для нас, потому что у нас есть виртуальные машины сервера приложений, на которых размещаются процессы, которые могут выдавать около 1 миллиона запросов к серверу базы данных (другой виртуальной машине) в час. Таким образом, добавление миллисекунды или двух к каждому запросу существенно увеличивает время выполнения - иногда удваивая или утроивая ожидаемую продолжительность.
У нас есть то, что я считаю довольно стандартной средой:
- 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 и обратно
- Отрегулируйте настройки стека Ethernet RHEL
- Использование опции "низкой задержки" ESXi для виртуальных машин
- Обновление наших хостов и vCenter с ESX 5.5 до 6.0u2
- Создание простых виртуальных машин (установка, как указано выше, с LUKS и т. Д., Но без каких-либо наших производственных сервисов на них) для тестирования
- Перемещение хранилища данных с твердотельного накопителя SolidFire SAN на локальное (на блейд-сервере) вращающееся хранилище
Ни один из этих вариантов не улучшил сетевую задержку. Единственный тест, который показал ожидаемую (не ухудшающуюся) задержку, - это когда мы настроили вторую пару простых виртуальных машин без LUKS-шифрования. К сожалению, нам нужны полностью зашифрованные разделы (для которых мы управляем ключами), потому что мы имеем дело с регулируемыми, конфиденциальными данными.
Я не понимаю, как LUKS - сам по себе - может быть здесь виноват. Скорее, я подозреваю, что виноват LUKS, работающий с некоторой комбинацией ESX, нашего хостингового оборудования и / или нашей аппаратной конфигурации виртуальной машины.
Я выполнил тест в гораздо более слабой среде (MacBook Pro, i5, 8 ГБ ОЗУ, VMWare Fusion 6.0, виртуальные машины Centos7, настроенные аналогично LUKS на LVM и те же сценарии тестирования) и не смог воспроизвести проблему задержки. Независимо от того, сколько сетевого трафика я отправил между виртуальными машинами, задержка оставалась стабильной и составляла около 0,4 мс. И это было на ноутбуке с множеством вещей!
Будем очень признательны за любые указатели / подсказки / решения!
