Смекни!
smekni.com

Сетевые "глюки" 1С (стр. 3 из 3)

Метод лечения очевиден: установить "родной" драйвер. А вывод прост: всегда, когда на сети с программами 1С имеют место "глюки", и на одном или нескольких компьютерах обнаруживается NE2000-совместимый драйвер - это первое, что следует поправить.

Примечание: желающим удостовериться в разнице между родными и NE2000-совместимыми драйверами могу посоветовать следующий метод: установите свою карточку в сервер Novell NetWare и установите сначала родной, а потом NE2000-совместимый драйвера (имеются в виду конечно драйвера для сервера с расширением "lan"). И в том, и в другом случае посмотрите в программе MONITOR набор возможностей и функций, выполняемых картой.

6. "Левые" драйвера сетевых карт.

В предыдущем пункте речь шла об универсальном драйвере сетевой карты, который рассчитан на работу с картами разных производителей и поэтому не в состоянии использовать в полной мере функции, предоставляемые этими картами. Вы вполне можете натолкнуться на противоположную крайность: на драйвер специально рассчитанный на работу с конкретной картой и пытающийся использовать ее функциональность настолько полно, что это приводит к плачевным последствиям. Для иллюстрации изложу реальную жизненную ситуацию, с которой мне пришлось столкнуться пару лет назад.

Имелась работоспособная сеть: 15-20 компьютеров на витой паре и сервер Novell NetWare 3.12. Происходило расширение сети - добавляли 3 или 4 компьютера (точно не помню сколько). В компьютеры установили свежезакупленные сетевые карты на чипе AMD и драйвера с дискеток, поставленных вместе с картами. Все шло нормально, пока дело не дошло до последнего компьютера из новой партии. Когда стали устанавливать драйвера, обнаружили, что на дискетке помимо обычного драйвера живет еще один драйвер - т.н. "турбо"-драйвер. В прилагаемом файлике "Readme" утверждалось, что при применении этого драйвера производительность сети увеличится на 10-15%. Ну что ж, увеличение производительности - это хорошо. Поставили этот "турбо" драйвер. Проверили. Да, действительно, скорость передачи данных несколько возросла. По несчастной случайности "одевание" последнего компьютера происходило поздно вечером, когда на сети никто уже не работал, поэтому проверяемый компьютер был на сети один одинешенек. Опять же, поскольку было уже поздно, другие компьютеры из новой партии "переодевать" в турбо-драйвера мы не стали и разошлись по домам весьма довольные. И естественно, про турбо-драйвера моментально забыли. Но, начиная с утра следующего дня нас начал доставать персонал предприятия: система работала очень медленно. При ближайшем рассмотрении обнаружилось огромное количество коллизий на довольно слабо загруженной сети - светодиод коллизий на хабе светился практически постоянно. Начали разбираться. И опять нам не повезло: тот самый компьютер, где был установлен турбо-драйвер, был загружен практически постоянно и до него мы добрались в последнюю очередь. В итоге, когда наконец до этого компьютера добрались и он был выключен - тут же восстановилась нормальная работоспособность сети. Поскольку было абсолютно непонятно, почему совершенно исправный компьютер с совершенно исправной картой (а это было проверено в первую очередь) ведет себя таким образом, мы занялись исследованиями, использовав все имевшееся в наличии программное и аппаратное обеспечение, позволявшее анализировать функционирование сети. Не буду пересказывать здесь подробности наших изысканий, которые заняли у нас 2-3 дня. Вот что нам удалось выяснить. Турбо-драйвер прекрасно работает и действительно увеличивает производительность сети на 10-15%, но… только в том случае, если ВСЕ компьютеры в сети (в т.ч. и сервер) укомплектованы одинаковыми картами и НА ВСЕХ них установлены эти самые турбо-драйвера. Как только в сети появляется "чужая" карта или "чужой" драйвер, так сразу же все карты, снабженные турбо-драйверами, начинают бомбардировать сеть широковещательными посылками, ожидая, что вновь появившаяся "чужая" карта получит эти посылки и ответит на них. Соответственно, если она ответит так как нужно, т.е. в случае установленного турбо-драйвера, в сети устанавливается симбиоз: турбо-драйвера образуют сообщество, которое использует дополнительную функциональность карт для ускорения работы сети. Если же ответ неправильный или ответа вообще не получено (т.е. драйвер действительно "чужой"), то турбо-драйвер не желая смириться с этим продолжает бомбардировать сеть широковещательными посылками, вероятно в надежде на то, что в один прекрасный момент "чужая" карта с "чужим" драйвером вдруг заработают так как надо. В нашем случае, поскольку на сети существовала всего одна карта с турбо-драйвером, она непрерывно бомбардировала сеть этими широковещательными посылками, причем делала это тем интенсивнее, чем больше машин было активно на сети. Налицо явный просчет разработчика программного обеспечения для сетевой карты. Если эти турбо-драйвера поставлялись в качестве рекламы, то конечно в файле "Readme" следовало написать об особенностях их применения. Вот такая история, стоившая нам нескольких дней сильной головной боли и ругани с заказчиком.

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

7. 100 мегабитная сеть.

100 мегабитная сеть дарит нам удивительный глюк, метода борьбы с которым (кроме переконфигурирования сети) я пока не нашел. Непосредственного отношения к программам 1С этот глюк не имеет, но поскольку он сильно снижает быстродействие сети, его следует здесь упомянуть. Глюк возникает, если имеется "умный" хаб 10/100 (который сам разбирается, какой из каналов с какой скоростью может работать) и с этого хаба каскадируется хотя бы один обычный 10 мегабитный хаб. Кроме этого, к хабу 10/100 подключены не только 100 мегабитные станции, но и парочка 10 мегабитных. Так вот этот "умный" хаб в некоторые моменты становится слишком умным: он начинает путать 10 мегабитные линии со 100 мегабитными. Вернее он начинает считать некоторые 100 мегабитные линии 10 мегабитными. А компьютеры со 100 мегабитными карточками продолжают работать в режиме 100 мегабит. В результате резко подскакивает уровень коллизий и катастрофически падает производительность сети. Лечение "на лету" проводится кратковременным (на 2-4 сек.) выключением питания "умного" хаба. Иногда кроме этого приходится перегружать сервер. Такие глюки происходят не часто, но если происходят, то весь персонал, работающий на сети встает на уши. Что здесь можно придумать? Или полностью разделить 10 и 100 мегабитные сегменты, или не использовать "умный" хаб, а использовать комбинированный хаб с фиксированным числом 10 и 100 мегабитных линий. Решение не самое лучшее, но иного я пока не придумал.

8. SQL-версии.

Все сказанное выше относительно неполадок, связанных с поисками ключа относится и к SQL-версиям программ 1С. Что же до всего остального, то в связи с отсутствием опыта (SQL-версии выпущены недавно), нами пока замечены только разные мелочи. Могу только напомнить, что не следует забывать устанавливать протокол Named Pipes при установке MS SQL Server. Отсутствие этого протокола существенно снижает производительность системы.

9. Некоторые общие рекомендации для больших сетей

Если Вы имеете дело с большой сетью (а большой сетью я считаю сеть с числом компьютеров более 20 и конечно, с выделенным сервером), то экономически и технически вполне оправдано завести отдельный компьютер для установки на нем ключей NetHASP. Избавьте сервер от этой нагрузки: ведь у него и так хватает дел, которыми следует заняться. Поверьте, такой подход облегчит жизнь и серверу и Вам, если Вы занимаетесь администрированием этой сети. "Ключевой" компьютер не обязательно одевать "по полной программе" - это может быть вполне посредственная по характеристикам машина, например какой-нибудь 486DX2-66. Кроме задачи по обслуживанию ключей этот компьютер можно загрузить работой по приему и отправке почты и факсов, обслуживанию линии удаленного доступа (в режиме Dial Up), а также другими вспомогательными задачами, например программированием офисной ATC и протоколированием ее работы с помощью программы типа WinTarif. Ну и конечно, как и сервер, этот компьютер должен быть запитан через UPS.

Далее: не вешайте на один сетевой сегмент более 20 компьютеров, даже если на них только вбивают накладные. Трафик по сегменту будет слишком интенсивным и сеть будет тормозить.

При возможности используйте "европейский" метод разводки сети, т.е. все кабели от всех рабочих мест сводятся в одну комнату. Конечно, кабеля может потребоваться значительно больше и за прокладку придется платить больше, но поверьте, при последующей эксплуатации это окупится сторицей.