Я унаследовал сеть / среду Microsoft со всеми обычными виновниками: Active Directory, Exchange, сервер терминалов, 50 клиентов, файловый сервер и сервер печати - достаточно стандартные офисные принадлежности.
Все клиенты находятся в диапазоне 172.25.51. *, И их скорость загрузки из Интернета составляет лишь небольшую часть от скорости, которую испытывают серверы. Передача файлов между машинами в этом диапазоне кажется достаточно быстрой. (См. Вывод машины №1 - Клиент ниже.)
Все серверы находятся в диапазоне 172.25.24. *, И их скорость загрузки из Интернета и передачи файлов между собой кажутся нормальными (см. Вывод машины № 2 - Сервер ниже).
Передача файлов между двумя диапазонами тоже кажется довольно медленной. Я думаю, что мой вопрос в конечном итоге приведет к другому, но вот что мне нужно сделать в первую очередь: как я могу приступить к формальной диагностике, почему клиенты в диапазоне 51. * испытывают такие ужасные скорости загрузки из Интернета и диапазона 24. *?
Я полагаю, что тот факт, что Интернет входит в диапазон 24. *, объясняет эту медленность, поэтому моя настоящая проблема, которую мне нужно диагностировать и найти причину, - это то, что вызывает замедление между серверами (24.) и клиентов (51.)?
Я почти уверен, что дело не в кабельной разводке, хотя я был бы признателен за предложения, как я могу доказать, что проблема не в этом? Это было сделано профессиональной компанией, поэтому я склонен полагать, что это проблема конфигурации. Любые предложения будут очень признательны.
# 1 - Клиент
ipconfig
V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:33:30--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9a.tar.bz2
=> `vlc-0.9.9a.tar.bz2'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done. ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)
100%[======================================>] 17,500,620 39.3K/s in 7m 35s
ipconfig / все
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : domain.local
Description . . . . . . . . . . . : Intel(R) 82566DM-2 Gigabit Network Connection
Physical Address. . . . . . . . . : 00-1E-4D-F4-35-57
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 172.25.51.77
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.51.1
DHCP Server . . . . . . . . . . . : 172.25.24.10
DNS Servers . . . . . . . . . . . : 172.25.24.18
172.25.24.12
Primary WINS Server . . . . . . . : 172.25.24.18
# 2 - Сервер
wget
V:\>wget ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vlc-0.9.9a.tar.bz2
--2009-06-30 19:41:15--
ftp://ftp.heanet.ie/mirrors/videolan/vlc/0.9.9a/vl.9a.tar.bz2
=> `vlc-0.9.9a.tar.bz2.1'
Resolving ftp.heanet.ie... 193.1.193.64
Connecting to ftp.heanet.ie|193.1.193.64|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /mirrors/videolan/vlc/0.9.9a ... done.
==> SIZE vlc-0.9.9a.tar.bz2 ... 17500620
==> PASV ... done. ==> RETR vlc-0.9.9a.tar.bz2 ... done.
Length: 17500620 (17M)
100%[======================================>] 17,500,620 510K/s in 28s
ipconfig
Ethernet adapter NIC:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection #2
Physical Address. . . . . . . . . : 00-11-54-31-32-50
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 172.25.24.17
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.25.24.1
DNS Servers . . . . . . . . . . . : 172.25.24.18
172.25.24.12
Управляются ли коммутаторы и доступны ли вам для входа в систему? Мне интересно, не было ли у кого-то решения проблемы злоупотребления полосой пропускания не было QoS определенного процента подсети сервера, и позволить подсети пользователя страдать с тем, что осталось. (Признаюсь, бывают дни, когда идея вызывает апелляцию)
Есть ли несовпадение дуплексов?
Каждый раз, когда возникают проблемы с производительностью, первый вопрос: проблема в DNS или в сети?
Если соединение устанавливается медленно, но после первоначального соединения оно работает нормально, это может быть связано с DNS. Пользователи обычно жалуются, что «Интернет медленный».
Если это несоответствие дуплексного режима, поищите настройки дуплексного режима на обеих сторонах соединения, ищите коллизии и ищите ошибки передачи / приема. Несовпадение дуплексного режима часто вызывается людьми, которые устанавливают переключатель, чтобы не согласовывать соединение автоматически - они жестко задают для переключателя значение 100 / полный, но затем пренебрегают настройкой компьютерной стороны ссылки, чтобы она также была жестко запрограммирована . Часто эта сторона ссылки достигает 100 / половина и будет работать до тех пор, пока вы не попытаетесь протолкнуть через нее более чем тривиальный объем трафика, и в этот момент она будет работать хуже, чем ссылка 10 / половина из-за всех отброшенных пакетов (что другой конец просто думает, что это столкновения).
Что за устройство "172.25.51.1" конкретно (роутер какой-то, очевидно)?
Это маршрутизация между подсетью .51 и подсетью .24, и по какой-то причине кажется, что это узкое место.
Я предполагаю, что это не то же устройство, что и устройство "172.25.24.1", хотя могло быть.
Я чувствую, что либо у устройства «172.25.51.1» возникла проблема - либо с одним из интерфейсов, который соединяет его с различными физическими широковещательными доменами, либо с его конфигурацией. Он также может быть перегружен локальным трафиком, перемещающимся между подсетями.
Я бы проверил счетчики ошибок интерфейса на интерфейсах Ethernet устройства «172.25.51.1» и порты коммутатора, к которым оно подключается. Я бы также попытался измерить, сколько трафика он перемещает между подсетями в среднем и насколько сильно загружен его процессор.
Вы бы действительно хотели иметь что-то вроде MRTG или Кактусы в такой ситуации, чтобы вы могли получить некоторую видимость потоков трафика (и, если ваши устройства поддерживают это, использование ЦП, температуру и т. д.).
Если передачи между всеми клиентами в подсети и между всеми серверами в подсети в порядке, но не между клиентскими подсетями и подсетями сервера, мне кажется, что виновником является маршрутизатор. Если это одно устройство, то есть проблема с конфигурацией. Если в каждой подсети есть собственный маршрутизатор, значит, проблема с маршрутизатором 51.
Между ними есть что-то узкое место, и я предполагаю, что это программная маршрутизация Windows. В качестве шага по устранению неполадок могу я предложить вам взять проблемный клиент и поместить его в подсеть сервера (ничего не меняй на нем) и посмотрим, что получится. Для этого вам, вероятно, придется физически переместить его.