У нас есть виртуализированный Windows Server 2008R2, работающий на хосте Windows Server 2012R2. Сервер 08R2 также работает под управлением SQL Server 2008R2 SP3 (версия 10.5) и IIS 7.5.
В последнее время у нас периодически возникали проблемы с запуском SSRS на этом сервере, который в нашем программном обеспечении ERP обозначен как "http: // имя сервера / serverhare". В то же время у нас были проблемы с подключением к серверу напрямую через RDP и с доступом к любым общим ресурсам UNC на сервере. Мы можем подключиться к серверу с помощью диспетчера Hyper-V, а доступ к серверу SQL, похоже, не работает. У нас есть какие-либо проблемы.Мы также запускаем отчеты с отдельным программным обеспечением на другом сервере, и, похоже, эти задержки не влияют на него.
Насколько я понимаю, способ доступа к SSRS, RDP и UNC-ресурсы используют TCP / IP. Даже доступ к общим ресурсам UNC на рассматриваемом сервере по-прежнему медленный, по сравнению с обычным просмотром файловой структуры через проводник Windows, и это наводит меня на мысль, что у меня проблема с TCP / IP на этом сервере. Я нашел несколько предложений, таких как отключение разгрузки большой отправки, отключение IPv6, проверка драйверов, хотя я еще не нашел ничего, что решало бы эту проблему. Мне не хочется верить, что это что-то связано с виртуальным коммутатором или физическим интерфейсом, поскольку оба они используются другой виртуальной машиной, которая не испытывает ни одной из этих проблем. Основное различие между этими двумя машинами заключается в том, что другая работает под управлением 2012R2.
Есть ли что-нибудь, что мы должны проверить на этом этапе? Правильно ли мы полагаем, что это связано либо с IIS, либо с TCP / IP, либо с обоими?
Итак, после дополнительных размышлений и ожидания мы наконец решили продолжить перестройку стека TCP / IP. После удаления и переустановки у нас возникли проблемы с разрешением DNS на сервере, где он будет использовать себя только для DNS и не будет запрашивать разрешение DNS где-либо еще. Нашим решением стала переустановка Server 2008 R2. С другой стороны, у нас не было проблем ни с одной из проблем, с которыми мы сталкивались ранее, поэтому, как бы то ни было, проблема казалась основной для самой Windows.