Я создал решение, использующее Microsoft Always-On VPN. Основы настройки следующие:
2 виртуальных машины под управлением Server 2019 с последними обновлениями 2 сетевых адаптера, 1 во «внутренней» сети и 1 во «внешней» сети Маршрут по умолчанию во внешней сети, статические маршруты добавлены в консоль RAS для маршрутизации адресов RFC1918 на «внутренний» шлюз
По большей части решение работает хорошо, но у меня есть данные о производительности с линейкой бизнес-приложений (SAP R3).
Благодаря процессу исключения я в основном свел проблему к низкой производительности между сервером RAS и сервером SAP. Чтобы определить это, я изначально тестировал выполнение той же операции в SAP и использовал секундомер, но мне действительно удалось использовать инструмент тестирования Siege HTTP, чтобы сделать немного более легкое тестирование без необходимости устанавливать приложение в разные места, журнал в и т. д.
Трафик от VPN-сервера к SAP-серверу проходит через VPN от сайта к сайту (Cisco FlexVPN IKEv2), но, похоже, он работает нормально, поскольку медленный трафик идет только с одного сервера, а не со всей сети.
С сервера RAS запускается тестовая команда
осада SAP_SERVER_IP: 8020 -b --time = 60S
Транзакции: 935 обращений Доступность: 100,00% Истекшее время: 6,55 секунды Переданные данные: 18,07 МБ Время отклика: 0,06 секунды Скорость транзакции: 142,81 транзакции / сек Пропускная способность: 2,76 МБ / сек Параллелизм: 9,28 Успешные транзакции: 950 Неудачные транзакции: 0 Самая длительная транзакция: 3.06 Самая короткая транзакция: 0.00
А с другого сервера в той же исходной подсети во много раз быстрее:
Транзакции: 36716 обращений Доступность: 100,00% Истекшее время: 59,80 секунды Переданные данные: 76,00 МБ Время отклика: 0,02 секунды Скорость транзакции: 614,00 транзакций / сек Пропускная способность: 1,27 МБ / сек Параллелизм: 12,23 Успешных транзакций: 0 Неудачные транзакции: 0 Самая длительная транзакция: 3.06 Самая короткая транзакция: 0.00
Однако, когда это становится странно, я запускал тест на другом веб-сервере (в той же подсети, что и целевой сервер SAP) и получил следующие результаты:
Транзакции: 8172 обращения Доступность: 100,00% Истекшее время: 59,23 секунды Переданные данные: 155,40 МБ Время отклика: 0,06 секунды Скорость транзакции: 137,98 транзакций / сек Пропускная способность: 2,62 МБ / сек Параллелизм: 8,56 Успешные транзакции: 8172 / Неудачные транзакции: 0 Самая длинная транзакция : 3.27 Самая короткая транзакция: 0.00
И с «рабочего» сервера, с которого я тестировал в предыдущих результатах (тестирование с SAP Server)
Транзакции: 7708 обращений Доступность: 100,00% Истекшее время: 59,10 секунды Переданные данные: 146,58 МБ Время отклика: 0,10 секунды Скорость транзакции: 130,43 транзакции / сек Пропускная способность: 2,48 МБ / сек Параллелизм: 13,53 Успешные транзакции: 7708 Неудачные транзакции: 0 Самая длительная транзакция: 3.48 Самая короткая транзакция: 0,00
В основном производительность примерно такая же (по крайней мере, в пределах погрешности)
Я открыл wirehark, чтобы попытаться увидеть различия между тестами,
В следующем тесте для быстрого сервера я заметил, что значение MSS было 1460 для «исходящего» пакета, а затем 1300 для «входящего» пакета.
5176 2020-05-07 16: 50: 00.461214 RAS_SERVER_IP FAST_WEB_SERVER_IP TCP 66 64439 → 80 [SYN, ECN, CWR] Seq = 0 Win = 65535 Len = 0 MSS = 1460 WS = 1 SACK_PERM = 1 5238 2020-05-07 16 : 50: 00.462856 FAST_WEB_SERVER_IP RAS_SERVER_IP TCP 66 80 → 64425 [SYN, ACK] Seq = 0 Ack = 1 Win = 65535 Len = 0 MSS = 1300 WS = 256 SACK_PERM = 1
Для медленного сервера SAP это выглядит так:
245 2020-05-07 16:53: 21.554203 RAS_SERVER_IP SAP_SERVER_IP TCP 66 52481 → 8020 [SYN, ECN, CWR] Seq = 0 Win = 65535 Len = 0 MSS = 1460 WS = 1 SACK_PERM = 1 249 2020-05-07 16 : 53: 21.554617 SAP_SERVER_IP RAS_SERVER_IP TCP 62 8020 → 52479 [SYN, ACK] Seq = 0 Ack = 1 Win = 65535 Len = 0 MSS = 1300 WS = 2
но я заметил после того, как получил загрузку повторных передач: 14005 2020-05-07 17:08: 13.576985 SAP_SERVER_IP RAS_SERVER_IP TCP 1354 [TCP Retransmission] 8020 → 64806 [ACK] Seq = 1 Ack = 150 Win = 66300 Len = 1300
Я провел тот же тест на сервере, который показал хорошую производительность, и в основном он выглядел так же, но я не видел ограничений.
tl; dr = Трафик от сервера удаленного доступа к определенному серверу идет медленно, с другого исходного сервера в той же сети быстро, а к другому целевому серверу с медленного исходного сервера он также быстро ..
Кто-нибудь знает, где я могу попытаться решить эту проблему? У меня действительно нет идей :(
заранее спасибо
Я обнаружил, что параметр «Включить спуфинг MAC-адреса» был включен для внутреннего сетевого адаптера виртуальной машины Hyper-V, когда он требовался только для внешнего сетевого адаптера (на котором выполняется балансировка сетевой нагрузки).
Я отключил это, и это устранило проблему с производительностью.