Я удаленно устраняю проблемы сети для клиента. Проблема в том, что они иногда получают «тайм-аут соединения» между веб-сервером и внутренним поисковым сервером. Они могут легко воспроизвести это поведение с помощью промежуточного сервера. Я попросил их запустить Wireshark на обоих серверах и обнаружил, что пакеты SYN отправляются снова и снова. И часто их не видно на принимающей стороне. Мне интересно, в чем, по вашему мнению, может быть причина?
Моя первая мысль была о межсетевом экране между серверами. Теперь они говорят, что подключили внутренний поисковый сервер к той же сети, что и веб-сервер, что меня озадачивает.
Более подробно: я предполагаю, что это серверы Windows Server 2008. Я никогда не был на территории клиента. Веб-сервер использует WCF с включенной транспортной безопасностью для доступа к внутренним серверам. Похоже, они могут исключить большую нагрузку, поскольку эти проблемы возникают и при небольшой нагрузке.
Для меня это казалось очевидным, что в сети должно быть что-то, что заставляет SYN не появляться в месте назначения, но теперь они говорят, что отключили правила брандмауэра, отключили брандмауэры Windows и даже поместили серверы в одну сеть. И я ничего не понимаю.
Обновление: последний проведенный ими тест - запустить консольное приложение (имитирующее повторяющиеся веб-запросы) на сервере в той же подсети, что и поисковый сервер. И оба сервера работают как экземпляры VMWare.
Идеи?
Вы хотите сказать, что и веб-сервер, и поисковый сервер находятся в одной подсети? Атакуя это с точки зрения сети, используйте IP-адреса только при устранении неполадок, чтобы исключить любые махинации с неправильными записями DNS и т. Д.
Чтобы помочь себе в здравом уме, я скажу, что у веб-сервера есть IP-адрес w.w.w.w, а у поискового сервера - IP s.s.s.s.
Тот факт, что wirehark не видит прибытия SYN, исключает проблему с брандмауэром, wirehark должен отслеживать пакеты, поступающие на интерфейс. перед брандмауэр получает возможность делать с ними что угодно.
Первое, что мне нужно сделать, это проверить, какая запись в кэше arp на веб-сервере предназначена для s.s.s.s. На большинстве платформ это просто arp -an в командной строке. Затем я бы проверил, совпадает ли MAC-адрес поискового сервера с этим. Если это не так, то вполне вероятно, что в сети есть другое устройство с тем же IP-адресом, что и у поискового сервера, и они борются за него.
Другой вариант - установить непрерывный эхо-запрос между серверами, чтобы увидеть, обнаруживает ли он потерю пакетов. Это может означать проблему с кабелем или несоответствие дуплексного режима, но из вашего описания это маловероятно. Можно ли сесть на коммутатор и проверить интерфейсы на наличие ошибок? Предположительно, если они виртуальные, это повлияет на все серверы на одном VHost ... так что опять же, это маловероятно.
Возможно, у VHosts настроено какое-то соединение интерфейса, которое не совсем работает? Я видел случаи, когда неправильно настроенный порт коммутатора на конце одного из шести интерфейсов ESX вызывал некоторые интересные побочные эффекты.
Более сложный сценарий может заключаться в том, что между двумя серверами существует «удар в проводе» - возможно, балансировщик нагрузки уровня 2, межсетевой экран уровня 2 или IPS некоторого описания. Любое из этих устройств может блокировать фреймы между серверами. Я надеюсь, что ваш клиент упомянул об этом!
Возможные причины:
1) фильтрация на основе скорости на коммутаторах / маршрутизаторах
2) пропадание кадров из-за плохого кабеля / сетевой карты или перегрузки