Глюки 1С при работе по сети

Перед тем, как рассказывать о чем либо в этой статье, внесем некоторые оговорки: 

1) не все перечисленные глюки можно на самом деле считать глюками – довольно часто термином Глюк называют ситуации, в которых программа ведет себя не так, как предполагает пользователь,но проблема тут не в программе,а в представлении пользователя. В этой статье такие ситуации мы также будем называть глюками;

2) не все описанные в статье глюки происходят из-за ошибок в программных продуктах 1С – просто они происходят именно тогда, когда используется 1С;

3) не все описанные в статье глюки относятся к сети, но большинство из них наиболее ярко проявляются именно при работе с сетью;

4) некоторые из глюков вообще не относятся к 1С;

5) все изложенная информация основана на личном опыте, а не взята из технических рассылок компании 1С

Введение 

Для начала нужно научиться различать неполадки, которые возникают с опознаванием и считыванием данных с ключа защиты NetHASP, от неполадок, которые связаны непосредственно с работой 1С. Такое распределение неполадок абсолютно оправдано, ведь доступ к NetHASP осуществляется только при запуске программ 1С. Когда ключ успешно распознан и программы декодированы, ключ уже не нужен. Если вы не верите, то запустите 1С, а потом выньте ключ. Как видите, программа продолжает работу безо всяких ошибок до того момента, пока вы не выйдете из нее. Поэтому мы будет различать глюки, возникающие при опознавании ключа, от глюков, которые возникают во время работы с 1С.

1) Инициализация сервера защиты

Наверное, в этот момент совершается большинство всех глюков, связанных с работой программ от 1С. Начнем, пожалуй, с самых странных глюков

Если во время установки ключа защиты на сервера по ОС Windows NT, вы будете совершать все рекомендации, прописанные в документации, и установите сервер NetHasp server как сервис, тогда вас может ждать большое удивление: при перезагрузке NT постоянно будет показывать синий экран смерти, также известный как BSOD. Тут остается только заново переустанавливать NT Server. Мы пытались узнать, как версия релиза NetHasp влияет на появление BSOD, но так этого и не поняли; единственным из релизов, при котором таких проблем не возникало, был 13-й. Но зато мы поняли причину ошибок – SAP Support, к которому, очевидно, NetHaspServer относится не очнь хорошо. Нужно лишь исключить SAP Support из сетевых протоколов, и BSOD больше не появится. Конечно, можно не устанавливать NetHasp Server в качестве сервиса, и запускать его при загрузке NT любым из возможных способов – но в этом случае SAP Support будет продолжать конфликтовать с NetHasp Server; иногда сервер NetHasp не распознает NetBios, даже если он подключен.

Рассмотрим следующий глюк. Его сложно назвать абсолютно сетевым глюком, но, впрочем, появляется он только в сетевых версиях, и именно тогда, когда доступ к ключу проводится посредством NetHasp Server.

Многие специалисты, которые раньше уже имели дело с сетевыми продуктами 1С, обращали внимание на ситуацию, когда сразу после запуска NetHaspServer 1С не хотела запускаться нормально, а рабочая станция выдавала сообщение о том, что ключ не найден. Но после второго же запуска программы 1С все идет нормально. Правда, бывает, что такая же ошибка появляется и при следующих запусках. В чем же причина? Скорее всего, дело тут вот в чем: ключ защиты является активным устройством, которое имеет внутри себя микрочип. В свою очередь, этот микрочип питается микротоком, появляющимся тогда, когда на ключ записываются данные. Перед первой записью, естественно, ключ этот не заряжен, и не распознается системой. Поэтому для инициализации ключа NetHaspServer нужно сначала записать что угодно, а потом уже записывать нужные посылки. Можно также после первой посылки сделать паузу перед тем, как считывать данные. Первый вариант по сути кажется оптимальным в данном случае. Сразу видно, что программное обеспечение NetHaspServer просто не доработано. Чтобы определить характер глюка, можно просто распечатать что-нибудь на принтере, который подключен к тому же порту LPT, но сразу после того, как NetHaspServer будет запущен. Если после печати последующие запуски проходят нормально – тогда с вашей системой случилось именно то, что мы описали выше. Но если начнут появляться ошибки или дальнейшие глюки, нужно подумать о замене порта LPT, или написать программку, которая время от времени посылает сигнал на порт LPT, правда в этом случае можно повредить процесс связи между ключом и NetHaspServer, поэтому замена порта LPT более безопасна.

Если используются некачественные motherboard’ы, с ними могут не работать многие ключи.

2) Принтеры

Если мы уже заговорили о портах LPT, то нужно упомянуть также лазерные принтеры, а особенно такого их представителя, как HP LaserJet 6L. Они отличаются тем, что очень быстро уменьшают напряжение на ключе, делая его этим непригодным для работы. Здесь выход очевиден – установить дополнительный порт LPT. Часто принтер просто садит порт, и работать на таком порту может всего один ключ, на несколько – не хватит мощности. Есть даже такие принтеры, которые моментально снимают все напряжение ключа в том случае, если выключить питание принтера после того, как будет выключено питание компьютера. Особенно это актуально для многофункциональных устройств, которые совмещают в себе принтер, ксерокс, факс, сканер. Правда, не все принтеры так плохо влияют на ключи.

Отдельное место тут занимают принтеры компании LexMark, а точнее не так принтеры, как написанное для них программное обеспечение, то есть не что иное, как драйвера. Создается впечатление, что их писали совсем не программисты, а агрессивно настроенные люди, которые плохо относятся ко всем сетевым принтерам от других производителей. Рассмотрим такую ситуацию: на вашем компьютере есть драйвер принтера Lexmark, при этом компьютер подключен по сети, и однажды вы установили этот принтер как такой, который доступен другим пользователям сети; затем вы отключаете принтер, не удаляя драйвер. После этого, как бы вы не старались сделать сетевую печать для принтера от других производителей, если их подключить туда, где раньше был установлен Lexmark – не выйдет, и ни один из пользователей сети не сможет ничего напечатать. Даже если удалить драйвера от Lexmark, это помогает не всегда – иногда даже приходится переустанавливать Windows. А теперь представьте, как будет работать ключ NetHasp, если включить его в порт, над которым овладел драйвер Lexmark; нормальных драйверов для Lexmark пока не найдено..

И еще о работе с принтерами. Бывают случаи, когда несколько компьютеров, подключенных к одному хабу, начинают медленно работать; связь через витую пару 10Мбит/с. Во время просмотра справочника эти компьютеры зависали на несколько секунд, при этом причины таких зависаний были сначала совсем непонятны. Бывает, что в этом виноваты принтеры, драйвера для которых подобраны неправильно, то есть, например, драйвера для более старой ОС, а установлены они на более молодую версию Windows.

3) TCP/IP 

Конечно, ничего плохого в протоколе TCP/IP нет. Но для систем, где используются программы от 1С, он не очень подходит. Конечно, в каждой системе могут нормально сосуществовать несколько протоколов, и среди них может быть и TCP/IP. Но системы с 1С могут спокойно работать нас IPX/SPX, или же на NetBios. Программы от 1С, которые работают на TCP/IP, функционируют вполне нормально, но не так быстро, как могли бы. Тем более, есть определенные нюансы, связанные с работой NetHaspServer на протоколе TCP/IP. По сути, главная задача TCP/IP – обеспечивать маршрутизацию сложных сетей, но в локальных сетях из нескольких сегментов, NetHaspServer иногда с большим негодованием дает доступ к ключам программы, запущенным на других сегментах этой сети. В этом скорее всего виноват именно NetHaspServer, но ситуацию это не исправляет. Систематизировать глюки этого вида сложно.

TCP/IP имеет и другие не очень хорошие проявления при работе с 1С. Если протокол TCP/IP установлен, но еще не настроен на нескольких компьютеров в сети, программы 1С могут искать ключ минут 3-5, и в дальнейшем тормозить во время работы настолько, что нормально работать практически нельзя, точнее можно, но трудно. Торможение касается  всей сети, а не только компьютеров, где установлены TCP/IP. Устранить     такой глюк просто – снести TCP/IP на одном из компьютеров. Ситуация эта проявляется далеко не всегда, но бывает же.

4) NetBIOS, IPX/SPX и NetHASP

Мы решили наконец понять, что именно, то есть какие протоколы нужно иметь в сети, чтобы поиск ключей был максимально быстрым и надежным, а программы запускались моментально и не давали глюков. После нескольких экспериментов, у нас появились некоторые результаты. Мы уверены в нижесказанном не на 100%, но просто подаем интерпретацию результатов экспериментов:

Для одноранговых сетей под Windows95 наилучшим вариантом является NetBIOS, причем настоящий, а не эмулированный. Сеть работает вполне быстро, а протокол этот установить довольно легко. Недостатком в этом случае является только то, что протокол NetBIOS не маршрутизируется по сетям из многих сегментов,хотя для многих это важной роли не играет. Нерациональным использование NetBIOS на таких сетях будет только в том случае, если есть сетевой принтер наподобие JetDirect – он требует для работы только IPX/SPX.

Если в одноранговую сеть включены больше, чем 6-7 компьютеров, и все эти компьютеры должны иметь доступ к серверу, тут может быть побольше глюков. Ресурсы Windows95 на компьютере, который выступает как сервер, не позволяют ему заниматься больше, чем 5-6 экземплярами программы 1С:Торговаля или же 1С:Бухгалтерия, если они запущены на других компьютерах; заметим, что каждый экземпляр программы 1С открывает больше чем 200 файлов на дисках сервера. Как результат – запуск шестого или седьмого экземпляра  программы от 1С проваливается. Конечно, можно установить выделенный сервер, но обычно в таких ситуациях на сервер устанавливают NT Workstation. Если уж так, что в этом случае наилучшим решением будет IPX/SPX, не включая поддержку SAP. Его работа не медленнее, чем NetBIOS. Бывает, что некоторые пытаются эмулировать NetBIOS на IPX – делать так не нужно, ведь будет торможение.

Вышеописанный вариант действий вполне подходит также для систем с выделенными серверами на ОС Windows NT Server

Если система находится под управлением выделенного сервера Novell NetWare 3,12 или 4,11, протокол IPX/SPX является наиболее оптимальным решением. Его использование дает хорошую скорость, как и надежность при поиске ключа; причем если использовать конфигурацию с двумя процессорами, скорость будет необычайно высокой. Только избегайте установки на рабочие станции клиента Novell, ведь глюков будет больше, чем можно было ожидать. Что бы там не говорили насчет Microsoft, клиент NetWare от этой компании работает довольно хорошо.

Поскольку это все-таки эксперимент, укажем условия, на которых проверялись вышеописанные глюки: 1С:Бухгалтерия 7,5, установленная поверх 1С:Торговля 7,5 в тот же каталог; релизы NetHaspServer были предоставлены с 8-го по 15-й, из них наилучшим оказался 13-й релиз.

Если на вашей сети установлено несколько протоколов, запись в файл Autoexec.bat с текстом set nethaspprotocol=… будет определять только протокол, который используется при поиске ключа для сети. Но какой протокол будет выполнять действия программ 1С с файлами? Исследования показывают, что если на нескольких компьютерах сети установлены разные протоколы, и каждый из них выбирает тот протокол, который ему больше подходит – тут и появляются глюки. Поэтому лучше выбирать единый протокол.

5) Драйвера, совместимые с NE2000 

Довольно часто во время установки сетевой карты на компьютеры под ОС Windows95 система лично определяет эту карту как NE2000-совместимую, и поэтому устанавливает соответствующий драйвер. Многим так называемым специалистам хватает и этого, либо они просто не ищут нормальных драйверов, ведь зачем лишнее время тратить. Но такая экономия времени на самом деле может обернуться множеством пресловутых глюков.

Да, если установить на сетевую карту NE2000-совместный драйвер, сеть может быть довольно работоспособной. Но если установить такой драйвер на современные карты, получается то же самое, что было бы если драйвера VGA установить на хорошую видеокарту – то есть использовать всю функциональность сети не выйдет. Сетевые карты содержат множество аппаратных функций, которые использует сетевое ядро Windows95 посредством драйверов этой карты. Если установлен родной драйвер, все функции используются как и должно быть, но если обходиться только NE2000-совместным драйвером, то он сможет распознать только некоторые из функций карты.

Около 70% всех случаев, когда программы 1С в сети работали неправильно, то есть не находили ключ, связаны с тем, что NE2000-совместимые драйвера используют вместо оригинальных, которые идут на дискетах или дисках. Особенно актуально это при установке драйверов на тот компьютер, где уже установлены ключи NetHasp

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

Если хотите проверить разницу между NE-2000 совместимыми и оригинальными драйверами, сделайте следующее: вставьте карточку в сервер Novell NetWare, и установите сначала оригинальный, и потом NE-2000 драйвер; нужно брать драйвера для серверов с расширением lan. В обеих случаях включите программу Monitor и через нее посмотрите, какие функции есть у вашей сетевой карты.

6) Посторонние драйвера сетевых карт

В предыдущем разделе мы рассмотрели универсальные драйвера сетевых карт, которые ориентированы на работу с картами от разных производителей, и поэтому не позволяют использовать все возможности уникальных сетевых карт. Но бывает и обратное – оригинальные драйвера, созданные специально для этой звуковой карты, пытаются использовать ее возможности в полно объеме, а получаются от этого глюки. Чтобы объяснить этот пункт, расскажем реальную историю.

Была такая себе вполне нормальная сеть : 15-20 ПК, соединенных витой парой с сервером Novell NetWare 3,12. Тут понадобилось расширить эту сети, то есть добавить в нее 3 или 4 дополнительных компьютера. В каждый из них установили только что купленные сетевые карты на AMD и драйвера, взятые из дискет, которые шли вместе с картами. Все работало нормально, пока не присоединили 4-й компьютер. Когда на него начали устанавливать драйвера, то выяснилось, что на дискете кроме стандартного драйвера есть еще и так называемый турбо драйвер. Из файла Readme мы прочитали, что от применения этого драйвера скорость работы сети увеличится на 10-15 процентов. Решили попробовать, установили турбо драйвер, скорость передачи увеличилась. Было поздно, и на остальные компьютеры турбо драйвера устанавливать мы не захотели. Но с самого утра посыпались гневные отзывы – оказывается, работа системы от этого значительно замедлилась. Когда же мы выключили тот компьютер, где установлены турбо-драйвера, все начало работать с нормальной скоростью. После долгих изучений оказалось, что система работает быстрее только тогда, когда эти турбо драйвера поставлены на все компьютеры сети. Наверное, в файле Readme нужно было указать такое.

Так что не нужно гнать за новейшими достижениями, и внимательно следить за драйверами, которые вы устанавливаете.

7) 100-мегабитные сети

100-мегабитные сети также могут проявлять глюки при работе в 1С, кроме того, неясно, как эти глюки исправлять. Отношения именно к программам от 1С этот глюк не имеет, но все равно он значительно уменьшает скорость работы сети, поэтому нужно о нем знать. Проявляется он тогда, когда умный хаб 10/100, который может определять, какой канал какую скорость имеет, каскадирует хотя бы один обычный хаб на 10мегабит. Дополнительно к хабу 10/100 подключены несколько 10мегабитных станций, помимо 100мегабитных. Умный хаб иногда становится ну очень уж умным – путает 10мегабитные каналы со 100мегабитными, точнее считает некоторые 100мб линии 10мегабитными. Как результат – возрастает количество коллизий, от этого производительность страдает. Исправлять ситуацию можно кратковременными выключениями питания этого хаба, хотя бы на несколько секунд, иногда нужно также перегружать сервер. Вообще, такие глюка бывают редко, но если происходят, забирают много рабочего времени. Поэтому нужно либо полностью различать сегменты по 10 и по 100 мегабит, либо не использовать умные хабы, а вместо них настраивать комбинированных хабы с фиксированным количеством линий.

8) SQL-версии

Особых глюков, связанных с SQL не замечено. Разве что, можно посоветовать не забывать устанавливать NamedPipes во время установки MS SQL Server – если не установить, производительность будет не такой, какой может быть.

9) Некоторые рекомендации по глюкам больших сетей

Если вам приходится работать с большой сетью, то есть если в ней больше 20 компьютеров и выделенный сервер, то лучше всего будет использовать отдельный компьютер для установка на него ключей NetHASP. На сервер устанавливать их будет непрактично – ведь у него и так много занятий. Если сделать именно так, легче будет не только серверу, а и его администратору; этот компьютер с ключами может быть обычным ПК, не обязательно использовать для этого современные мощные компьютеры. Также можно организовать на этом ПК работу по приему и отправлению почты и факсов, или обслуживанию по DialUp, и другими функциями, которыми не хочется загружать сервер.

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

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