Нестабильная работа сети
 

Господа, ПОМОГИТЕ!!!

Есть сервер:
2 x Xeon 2.8 GHz, 2 Gb, RAID 5 Level
Windows 2003 EE SP1 (Контроллер домена), MS SQL Server 2000 EE SP3, MS Office 2003 (плюс по мелочи).
Сеть - свитч D-Link 10/100 16 port полудуплекс.

Проблема - постоянно рвется связь с сервером.
В чем проявляется:
у клиентов подключены по два сетевых диска и работатет 1С SQL (SQL клиент настроен на использование протокола TCP/IP). Периодически у разных клиентов при попытке доступа к любому сетевому диску выдается сообщение, что диск не доступен. Также периодически вылетает 1С без каких либо сообщений об ошибках. "Стабильнее" всего ошибка проявляется если поставить в свойствах клиента SQL протокол Named Pipes и запустить какую-либо длительную операцию. Максимум через 15 минут 1С вылетает с сообщением General Network Error. Причем та же 1С ту же операцию локально выполняет без каких-либо проблем.
До этого 1С работала на другом сервере в терминальном режиме. Проблем с терминальным режимом не было (т.е. коннект не рвался).
Пробовал:
- заменить сетевую карту;
- заменить патчкорд;
- заменить порт на свитче.
Результат один и тот же.

Я в отчаянии. Подскажите хотя бы где рыть нужно.

В логе на сервере ченить сам сервак пишет когда откидывает клиентов?

нет. ничего

Запусти, пинг на сервер и посмотри все ли пакеты проходят. Дело может быть не только в патч-кордах, но и в информационных розетках ( проверь патч-панель). В моей практике был случай: был сервер в Рязани домен третьего уровня и центральный сервер в Москве. Так вот местная сеть в Рязани тоже отваливалась, и работало не стабильно внутри себя. Загвозка оказалось в том что DSL модем был плохо подключен, и как следствие репликация проводилась с ошибками.

А попробуй поменять свич - поставь какой нибудь маленький (5 портовый) подключи тока самых активных пользователей и посмотри как ведёт себя 1С. помоему проблемка всё-таки железная. хотя и не факт.

Возможно 1С открывает слишком много сетевых подключений, что клиентской машиной (только если winXP SP2, эт у него такая "фишка") ограничено, из-за этого и связь рвется. У самого такая фигня была при распечатке большого числа документов из 1С. Для этого есть патч.

Мож и не в этом причина...

Все пинги до сервера идут замечательно.
Замена свитча к положительному результату не привела.
Madness
что за пачт для WinXP?

По-моему, нужно работать с MS SQL через TCP/IP, а named pipes не использовать вообще. Это рекомендации от 1С.
Это для справедливо для базы 1С формата DBF.

В SQL-режиме работы 1С сетевых соединений немного (если работа через TCP/IP).

Candyman
на контроллере домена (AD?) DHCP, DNS-ы и Wins-ы подняты?
на SQL - "client network utility" подымаешь приоритет TCP/IP над named pipes.

поднят DNS
у клиентов стоит TCP/IP с верхним приоритетом

Что бы в таком случае сделал я...
1. Нарыл бы для сервера приличную карточку -- Intel или 3СOM -- сервер едишн, или любую другую, софт к которой позволяет вести логи принятых/потерянных/ошибочных пакетов и помониторил бы сетевую активность.
2. В случае заметного числа ошибок поиграл бы с дуплексами и буферами.
3. Исследовал бы логи сервера на предмет частого перевыбора броузеров. Если таковой имеет место, отключил бы все броузеры кроме мастера (он же DC)
4. Рассадил бы DC и SQL-сервер на разные компы.

Candyman
Адреса в сети - динамические (DHCP) или статика?
Если статические, то имеются ли записи на клиентах о DNS поднятого на котроллере домена. И служба WINS тоже не помешает, особенно если в сети в качестве клиентов есть Win98 и WinNT.

Candyman
>что за пачт для WinXP?
http://www.lantricks.com/lanscope/faq.php#24 пункт с.

Oleg+
>Это для справедливо для базы 1С формата DBF.
Да, dbf было.

Настройка - по 1С и SQL:
1. на каждого клиента установи клиентскую часть MS SQL – MDAC новый.
2. Запусти cliconfg.exe – в нем настрой по умолчанию TCP/IP, причем укажи ip сервера, а не имя, убери настройки по другим протоколам.
3. После изменения настроек перезагрузи SQL сервер.
4. Попробуй обновиться до MS SQL Service Pack 3а или MS SQL Service Pack 4.

Общее.
1. Оставь в сети на клиентах только TCP/IP.
2. Везде в настройках пропиши ip сервера, а не его имя.
3. Проверь загрузку сервера в моменты, когда отваливается сеть – процессоры, сеть, какой процесс жрет ресурсы.

а где в cliconfg.exe настраивается ИМЯ сервера - там есть ТОЛЬКО номер порта.
MDAC стоит везде новый. на SQL сервере стоит SP3.
нагрузку проверить не представляется возможным, так, как "вылеты" носят случайный характер и вылетают не все а кто-то один (или два).

Вкладка Alias (псевдонимы).
В свойствах псевдонима указать IP адрес сервера и протоколы.

Виноват.
Тогда Service Pack 4 - лучше пробовать на виртуальном сервере

В логах MS SQL что-нибудь пишется, когда отваливаются клиенты?

самое интересное, что клиенты отваливаются "полностью", т.е. вместе с сетевыми дисками (правда иногда 1С вылетает сама по себе, но это означает только то, что диски "отвалятся" вскорости)

Значит, проблема не в SQL. Я думаю, что сеть работает некорректно на физическом уровне (неверно обжаты провода и т.д.)

провода обжаты нормально (стоят фабричные патч-корды, причем я пробовал менять - результат нулевой).

Нужно локализовать проблему. Изучить, пропадает ли связь между клиентами во время сбоя. Может быть, нужно провести "прозвонку" (анализ работы) сети на физическом уровне, проверить ее соответствие спецификации 100 Мбит.

Мало ли что может с сетью происходить - высоковольтные помехи, например, или поврежденный (перекрученный, обгрызенный) участок кабеля.

И еще раз попробуй заменить свитч на другую модель с другим блоком питания.

Candyman
а проанализировать логи системные, приложений и SQL, все вместе с привязкой ко времени сбоя не пробовал?
А в настройках подключения к базам 1C подключаться к сетевым шарам 1C не как к дискам, а как сетевым ресурсам не пробовал?

Хм а если перевести сеть не на 100Мбит а на 10 и посмотреть как себя поведёт

пробовал - пусто. отваливаются в полной тишине. единственно растет счетчик соединенй прерваных по ошибке (в счетчиках производительности, причем в объяснении к нему написано, что это может быть и из-за превышения таймаута бездействия, но сообщений о его достижении нет, следовательно все-таки ошибка).
Пробовал - не помогает.
сетевое оборудование не позволит :(

А если посмотреть про отвале всего горит ли светодиод "Link" на сетевухи п далее , ещё можно подвесить на комп (один из подопытных клиентов :) ) сетевую шару от другого коиента и посмотреть отвалится она вместе с серверным диском или нет

Такое же было и у меня, не раз обращался за помощью на форумах, в том числе и на ИМХО. Но ответа так и не получил. Сервак раз в час-два, а иногда и раз в день-два валился - т.е. как и у Candyman'а. Помогало только одно - перезапуск службы сервер.
Ранее пробывал и переобжимать, и карточки менял, память менял. Дошло даже до того, что и сервак переустанавливал - ничего не помогало (ставил другой релиз), пока в один прекрасный день взял да и разгрузил сетку - т.е. перевёл часть сети на другой сервак. И О ЧУДО - с тех пор никаких проблем.
P.S.: конфигурация "глючного" сервака - мать Gigabyte (не помню какая), 2 пня по 800 MHz, RAM 512Mb, 2 винта Samsung'и в аппаратном рэйде (стоят в миррор), третий винт стоит просто как дополнение.

проверил сетку пентасканером - все кабели в норме.
поставил свитч - 3Com SuperStack 24 pot + 2 GBit. Вставил в сервак гигабитную серверную карту.
Результат нулевой. Все равно идут обрывы.
Заметил одну особенность - обрывы идут при повышенной активности в сети. У нас есть ночная смена, в которую работают один-два клиента. Так вот за все ночи был зафиксирован всего один обрыв. А днем их может быть десятка два.
Уже подумываю раздобыть где-нибудь бубуен и попрыгать с ним вокруг сервера.

А сеть точно не имеет пересекающихся IP и прочих мелочей , а то часто бывает что ищут глобальную неиспраность а сами не заметили какую нибудь мелочь
А вобще скорее всего проблема в ОС сервера

IP раздаются через DHCP какие еще могут быть "прочие мелочи"?

Я тоже уже пришел к тому, что проблема программная, возможно даже в самой службе Server (либо она работает нестабильно, либо ее кто-то "кладет"), но меня бесит то, что нет НИКАКИХ сообщений об ошибках.