У меня есть серверы приложений EC2 за эластичным балансировщиком нагрузки. Все серверы приложений имеют доступ к общему серверу хранения, особенно для централизованных файлов кэша, журналирования и т. Д. Сервер общего хранения реализует NFS через OpenVPN для выполнения своей работы. Все серверы находятся в одной зоне доступности и общаются друг с другом по внутренней сети. Однако решение с общим хранилищем приводит к аномально высокой загрузке ЦП и задержкам, которые обычно не существуют, если хранилище на 100% локальное. Ожидается небольшое снижение производительности при этой настройке, но в этом случае процессор увеличился, а производительность снизилась в 2-3 раза.
Итак, это вопрос из двух частей:
Что мне сделать, чтобы лучше понять, в чем виноват? Я знаю, что это комбинация OpenVPN и NFS, но могу ли я определить, какие файлы читаются и записываются чаще всего? Или я могу легко определить, где находится узкое место?
Есть ли у кого-нибудь совет, основанный исключительно на приведенной выше информации? Есть ли лучший способ обмена файлами между серверами в облачной среде? (Пожалуйста, не отвечайте «используйте S3», так как это не подходит для требований к мгновенным / временным файлам)
Спасибо!
Убедитесь, что ваш Link-MTU для туннеля openvpn установлен правильно, чтобы вы не получили фрагментацию дважды (один на хосте от 8192 до 1500 байтов и один раз на openvpn от 1500 до 1400 байтов или что-то еще). openvpn очень плохо справляется с настройкой интерфейса mtu (активно препятствует попыткам установить mtu правильно).
Проверьте задержку для пакетов разных размеров, проходящих через туннель и вокруг него. Заговаривайте и ищите проблемы.
Настройте тестовую NFS за пределами туннеля и выполните некоторые измерения производительности, чтобы определить, является ли проблема с openvpn или нет.
Попробуйте разные версии NFS, TCP и UDP.
Попробуйте включить агрессивное кеширование и асинхронный ввод-вывод.
Далее следует разглагольствования об «активном блокировании» openvpn WRT MTU (добавлено «запросом»)
Да. Установка tun-mtu заставляет openvpn генерировать WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1413). Я не использую --mssfix или --fragment.
Кроме того, установка статического MTU в конфигурации - это глупо и чревато ошибками, оно должно быть динамическим. Итак, вы используете «mtu-disc yes», верно? Ну, конечно, за исключением того, что значение, которое он передает в сценарий запуска, не равно 14 (хотя я использую TAP для поддержки IPv6, что может загадочно запутать его). Так что мне нужно /sbin/ifconfig $1 mtu $(($2-14)) up для получения правильного значения (правильное значение означает значение, при котором пакеты туннеля не будут фрагментированы или отброшены из-за их слишком большого размера).
Мне трудно представить себе обстоятельства, при которых установка MTU интерфейса на правильное значение не является хорошей идеей, по крайней мере, если у вас нет набора фрагментов (и вы никогда не должны устанавливать набор фрагментов, по крайней мере, ваши сетевые грехи преследуют вас). Он также должен динамически изменять MTU интерфейса, если позже он получает ошибки, связанные с необходимостью фрагментации, из-за сетевых изменений после инициализации.
MSS - совершенно неподходящий сетевой уровень для выполнения этой работы. Если у вас правильно настроен MTU интерфейса, обнаружение Path-MTU, MSS и все просто работает. Если вы этого не сделаете, некоторые вещи могут вроде как работать, другие - нет, и то, что работает, зависит от того, отправляется ли реальный пакет с хоста openvpn или с какого-либо другого хоста. О, и не заставляйте меня начинать с того, что может выйти из строя, если MTU асимметричный (не совсем редкость).
Я думаю, что OpenVPN был написан людьми без большого опыта работы с сетями и системными администраторами, и их неудачный выбор был жестко запрограммирован в конфигурации и структурах данных / API. Они действительно не очень хорошо справились с гибкой и разумной конфигурацией сети и интеграцией (это лишь один из нескольких примеров). Печально то, что это в сотни раз лучше, чем другие решения, что делает меня сторонником OpenVPN. Например, Cisco VPN - это болезнь.
Вот и мои советы: NFS через OpenVPN: лучшие ускорители производительности
а полная версия здесь: http://thegoodcodeinn.blogspot.it/2015/06/nfs-over-openvpn-over-adslor-slow.html