Сетевые "глюки" 1С
Алексей Жедь
С самого начала должен сделать следующие оговорки:
Не все описанные ниже "глюки" можно с полным правом назвать "глюками" - очень часто глюком называют ситуацию, когда программа ведет себя не так, как хотелось бы пользователю, в то время как с точки зрения разработчика все нормально и корректно. Для простоты далее все такие ситуации будут причислены к "настоящим глюкам".
Не все описанные ниже "глюки" являются следствием ошибок в программах фирмы "1С" - просто на практике они проявляются именно при использовании программ фирмы "1С".
Не все описанные "глюки" имеют непосредственное отношение к сети, однако, как правило, наиболее ярко они проявляются именно при сетевой работе.
Некоторые из описанных "глюков" вообще не имеют отношения к программам фирмы "1С".
Вся информация, изложенная ниже, основана на моем собственном опыте эксплуатации сетевых программных продуктов или на опыте сотрудников нашей компании и ни в какой степени не заимствована из технических рассылок фирмы 1С.
1. Общие положения.
С самого начала следует разделить неполадки, связанные с опознаванием и чтением информации с ключа защиты NetHASP и неполадки, связанные с функционированием собственно программ 1С. Такое разделение абсолютно целесообразно и оправдано т.к. доступ к ключу защиты из программ 1С осуществляется только в момент их запуска. После успешного опознавания ключа и декодирования частей программы ключ становится не нужен. Кто мне не верит, может попробовать запустить программу 1С (здесь и далее я буду просто писать "программа 1С", если не требуется конкретного уточнения, что это за программа) и затем выдернуть ключ. Программа продолжит свою работу и будет работать до тех пор, пока Вы не выйдете из нее (последний раз я проверял это на релизе 8, может быть сейчас что-то изменилось, но это крайне маловероятно). В связи с вышеизложенным я буду разделять все глюки на глюки, связанные с поиском и опознаванием ключа и глюки рабочего режима.
1. Инициализация сервера защиты.
Это пожалуй один из самых "глюконосных" моментов в программах 1С. Начать вероятно следует с самого страшного и необъяснимого.
Если при установке ключа защиты на сервер Windows NT Вы последуете рекомендациям, приведенным в документации по установке, и установите сервер защиты (NetHasp server) в качестве NT-шного сервиса, то может случиться так, что Вы будете сильно удивлены: при перезагрузке NT сервер стабильно переходит в режим "синей смерти", т.е. загрузка не завершается, а на экране монитора на синем фоне возникает какое-то жуткое невразумительное диагностическое сообщение с указанием каких-то адресов. В этой ситуации можно только выразить Вам соболезнование и посоветовать быстренько переустановить NT Server. Нам так и не удалось определить зависимость возникновения такой ситуации от релиза NetHasp server-а - такая штука кажется может происходить с любыми релизами, кроме 13, но прямой связи версии NetHasp Server с релизом нет - в одном и том же релизе, но в разных коробках может попасться NetHasp Server разных версий. Зато нам удалось найти то, с чем не желает спокойно жить NetHaspServer, вызывая этим нежеланием "синюю смерть" - это установленный SAP support. Достаточно убрать из сетевых протоколов SAP support и никакой "синей смерти" больше не возникает. Можно конечно не устанавливать NetHasp Server как NT-шный сервис и запускать его при старте NT любым доступным способом - хоть вручную. Но даже при ручном запуске наличие SAP support продолжает конфликтовать с NetHasp Server-ом - в некоторых случаях NetHasp Server не видит нормально установленный и "живой" протокол NetBios (имеется в виду конечно его эмуляция на IPX), иногда при выключении и последующем включении (без перезагрузки) NetHasp Server вдруг вообще перестает "видеть" установленные сетевые протоколы. В итоге конечно можно подобрать такую комбинацию версии NetHasp Server, способа его запуска и установленных и задействованных на сервере NT сетевых протоколов, что все будет нормально, но как мне кажется, даже в этой ситуации сбои при опознавании ключа возникают чаще. В качестве хохмы могу привести пример, когда нам пришлось написать небольшой BAT-файл, который перезапускался каждые пять минут и вырубал, а затем снова запускал NetHasp Server. Это из-за того, что после каждых 5-7 запусков программы 1С:Торговля на рабочих станциях ключ вдруг переставал опознаваться, а NetHasp Server начинал показываать, что он не видит ни одного из установленных сетевых протоколов. В итоге после сноса SAP support-а все нормализовалось.
Теперь перейдем к следующему глюку. Его в общем-то нельзя назвать сетевым на сто процентов, однако возникает он только в сетевых версиях, когда доступ к ключу осуществляется через NetHasp Server.
Наверное любой из специалистов, поимевших дело с сетевыми версиями программ 1С обратил внимание на возникающую иногда ситуацию, когда после старта NetHasp Server-а первая попытка запуска программы 1С с рабочей станции заканчивается неудачей с сообщением о том, что "…ключ не найден". Однако следующий запуск проходит нормально и все последующие тоже. Хотя иногда вдруг опять программа берет и не запускается. В чем тут дело? По всей вероятности причина заключается в следующем. Ключ защиты - это активное устройство, имеющее в своем составе микрочип. Этот микрочип питается микротоком, который возникает в тот момент, когда в порт LPT (т.е. на ключ) записывают какие-либо данные. До момента первой записи ключ остается не запитанным и соответственно не инициализированным. Вероятно, для инициализации ключа NetHasp Server должен либо бросить туда пустую посылку, а затем уже начать давать "рабочие" посылки, которые требуют ответа ключа, либо после первой посылки сделать паузу перед вычитыванием данных. Мне представляется более вероятным первый вариант. Налицо факт недоработки программного обеспечения NetHasp Server. При встрече с подобным дефектом Вы можете уточнить его характер просто напечатав что-либо на принтере, подключенном к тому же LPT-порту сразу после запуска NetHasp Server-а. Если после этого первый запуск программы 1С с рабочей станции проходит успешно - можете быть уверены - Вы столкнулись именно с вышеописанным дефектом. Если он начинает досаждать Вам, можно попытаться вылечить его заменой LPT-порта - просто подобрать порт, обеспечивающий большую величину микротока (конечно, если LPT-порт интегрирован на материнской плате, то придется поставить дополнительный порт). Программным путем этот дефект можно излечить написанием программки, периодически обращающейся к LPT-порту, однако здесь есть свои трудности - есть вероятность влезть в процесс обмена между NetHasp Server-ом и ключем, так что аппаратный способ мне кажется более приемлемым.
С "левыми" материнскими платами (типа китайских Lucky Star) часто связана неработоспособность нескольких ключей, подключенных к встроенному (на маме) LPT-порту: порт просто не дает необходимой мощности микротока для питания более, чем одного ключа.
2. Принтеры.
Если уж речь зашла об LPT-портах, то невозможно не упомянуть о лазерных принтерах, особенно о принтере HP LaserJet 6L, которые напрочь "сажают" напряжение на ключе и делают его полностью неработоспособным. Выход один - установка дополнительного LPT-порта - больше здесь ничего не поможет. В некоторых случаях принтер просто "подсаживает" LPT-порт и работать на таком порту может только один ключ. На два и более ключа просто не хватает мощности. Есть также некоторые модели принтеров, которые "убивают" ключ, если питание принтера выключить после того, как выключается питание компьютера. Это в первую очередь относится к комбинированным монстрам, объединяющим в себе факс, ксерокс, принтер и т.д. Конечно, не все модели таких устройств столь злобно настроены по отношению к Алладдиновским ключам, но я бы рисковать не стал.
Отдельный разговор о принтерах Lexmark, а вернее о программном обеспечении для них. Речь идет о драйверах этих принтеров. Эти драйвера написаны не программистами, а какими-то абсолютно враждебными существами, категорически недружелюбно настроенными к сетевым принтерам других производителей. Если на компьютере, подключенном к сети болтается такой драйвер (от принтера Lexmark) и в свое время Вы имели неосторожность установить этот принтер, как доступный другим пользователям сети, а потом принтер отключили, но драйвер не снесли, то сколько бы Вы не пытались организовать сетевую печать на принтер другой фирмы, подключенный туда, где раньше жил Lexmark, ничего у Вас не получится - никто из других пользователей сети не сможет напечатать на этом принтере ни слова. Даже снос драйвера Lexmark не всегда помогает: он оставляет какие-то DLL включенными в систему и их приходится либо удалять хирургически, путем долгих и нудных поисков в Registory, либо просто переставлять с нуля Windows. Сами можете представить себе, что будет выделывать ключ NetHasp, включенный в порт компьютера, изгаженного драйверами Lexmark. Выводы: может быть где-то и существуют нормальные драйвера для лазерных принтеров Lexmark, но я таких не встречал. С того момента, как Lexmarkи появились на нашем рынке (3-4 года назад) нам неоднократно приходилось с ними бороться.
Еще о принтерах. Это уже не относится к поиску ключа, а относится к нормальному режиму работы. Однажды мы наткнулись на следующую загадочную ситуацию. Вдруг, ни с того, ни с сего у одного из наших клиентов стали чрезвычайно медленно работать два компьютера из пяти, подключенных к одному хабу (сеть - витая пара пятой категории, 10 Мбит, сервер Novell NetWare 4.11, протокол IPX/SPX). Больно было смотреть, как компьютеры "засыпали" на несколько секунд при листании справочника. Клиент клялся и божился, что с этими компьютерами ничего не делал. После целого дня бесплодных попыток что-то сделать (переустановка и настройка протоколов, драйверов сетевых карт, замена сетевых карт, замена хаба и т.д.) мы обратили внимание на один из оставшихся трех "нормальных" компьютеров этой группы, а вернее на странный лазерный принтер, подключенный к одному из них. Спросили и выяснили, что клиент где-то (ГДЕ???) добыл по случаю лазерный принтер (кажется фирмы NEC), абсолютно новый, но 4-х или 5-ти летней давности выпуска. А с этим принтером на дискете был драйвер только для Windows 3.11. Вот этот драйвер клиент и влепил в Win95. Мы тут же снесли драйвер и к неописуемой радости (своей и клиента) обнаружили, что те два "больные" компьютера заработали как надо - с нормальной скоростью. Драйвер для Win95 мы потом скачали с Интернет, но почему драйвер принтера под 3.11, установленный на одном из компьютеров тормозил два других компьютера (и только их!) я так до сих пор понять не могу.
Вообще похожие ситуации, выражающиеся в сильном торможении компьютера/компьютеров при установке на сети каких-либо драйверов от 3.11 в Win95 или использования программ от 3.11 на Win95 встречаются достаточно часто, но обычно тормозит та машина, где это все установлено.
3. Протокол TCP/IP
Я не хочу говорить никаких плохих слов о протоколе TCP/IP. Я просто считаю его не нужным для систем, использующих программы 1С. Поскольку в системе спокойно уживаются несколько протоколов, то в случае необходимости для сугубо определенных целей TCP/IP имеет право на существование. Ну и пусть он живет на тех рабочих станциях или серверах, где он нужен (например для удаленного доступа), а 1С чудесно будет работать на IPX/SPX или на NetBIOS. 1C-овские программы, работающие на протоколе TCP/IP вполне работоспособны, однако не являются идеалом быстродействия. Тем более, что существуют какие-то заморочки с работой NetHasp Server на TCP/IP. По идее TCP/IP - это протокол, который в первую очередь обязан обеспечить маршрутизацию в сложных сетях. Однако, на обычной локальной сети, но с несколькими сегментами, NetHasp Server часто бывает невозможно заставить дать доступ к ключу программам, запущенным на другом сегменте сети. Скорее всего это ошибка самого NetHasp Server-а, но нам от этого не легче. Систематизировать неполадки данного вида нам не удалось (да честно говоря мы особо и не старались), как не удались и попытки смоделировать подобные ситуации на своей сети (2 сегмента). Но факт есть факт - иногда не работает и не лечится, а иногда работает. Я лично предпочитаю с головной болью не связываться.
TCP/IP способен преподнести еще некоторые сюрпризы. Наличие установленного, но ненастроенного (по IP-адресам) протокола TCP/IP на паре компьютеров в сети способно заставить программы 1С искать ключ по 3-5 минут, а затем "тормозить" при работе так, что создается впечатление, что перед Вами не 100 мегабитная сеть Ethernet, а просто компьютеры, связанные через COM-порты. При этом тормозит ВСЯ сеть, а не только те машины, где установлен TCP/IP. Лечится просто - сносом протокола TCP/IP на одной из машин (т.е. следует устранить наличие TCP/IP-шной "двухточки"). Естественно ситуация такая наступает не всегда, но при определенных условиях (каких???). Исследования на эту тему нам проводить было лень, достаточно того, что найден метод лечения.
4. NetBIOS, IPX/SPX и NetHASP.
Однажды мы решили наконец разобраться в том, что же нужно (в протокольном смысле) иметь на сети, чтобы ключ искался быстро и надежно (а соответственно и программы запускались быстро и без сбоев). Проведя ряд экспериментов, мы получили некий результат. Не претендуя на истину в последней инстанции, но опираясь на проведенные эксперименты и опыт эксплуатации сетей с программами 1С могу сказать следующее:
· Для одноранговых сетей Win95 оптимальным вариантом является протокол NetBIOS (родной NetBEUI, а не эмуляция его на IPX/SPX). Сама сеть работает очень быстро и протокол устанавливается легко. Единственным недостатком является то, что NetBIOS не маршрутизируется по многосегментной сети, хотя недостатком это назвать сложно: я с трудом могу представить себе одноранговую сеть без выделенного сервера, но с несколькими сегментами. По-моему это будет просто извращение какое-то. Единственным препятствием для использования NetBIOS в такой сети может служить наличие сетевого принтера вроде Jet Direct, который, как правило, требует для своей работы протокола IPX/SPX.
· Если в одноранговой сети используется более 6-7 компьютеров и все они должны иметь доступ к одному из компьютеров, играющему роль сервера, то здесь начинаются неприятности. Ресурсы Win95 в случае, когда компьютер играет роль сервера, не позволяют ему обслужить более 5-6 экземпляров
· Такой же вариант следует предпочесть и для системы с выделенным сервером Windows NT Server.
· Для систем с выделенным сервером Novell NetWare 3.12 или 4.11 протокол IPX/SPX является практически единственным. Его использование дает прекрасные результаты, как по надежности поиска ключа, так и по скорости. А если еще применить двухпроцессорную конфигурацию (с NetWare 4.11) то система просто будет летать. Только ни в коем случае не надо ставить на рабочие станции родного Novell-овского клиента. Глючит по-черному. Несмотря на мое теплое отношение к продуктам Novell и резко отрицательное к продуктам от Била Гейтса, вынужден признать, что Microsoft-овский клиент NetWare для Win95 вполне прилично выполняет свои функции.
Все вышеописанные варианты проверялись на наиболее капризной комбинации: 1C:Бухгалтерии 7.5, поставленной поверх 1С:Торговли 7.5 в один и тот же каталог. При этом тестировались NetHasp Server-ы от релизов с 8-го по 15-й. Наилучшие (по безотказности и надежности) результаты показал NetHasp Server от 13-го релиза, вне зависимости от какого продукта он был взят (проверяли в том числе NetHasp Server от SQL-версий). Не забыли мы и про проблемы с ключами от Бухгалтерии 6.0 о которых часто пишут в конференции 1сsoft. Как ни странно, никаких проблем у нас с ними не было - все прекрасно функционировало "в одном флаконе" в вышеописанных конфигурациях. Во всяком случае, посоветовать кое-что могу: надо внимательно читать не только печатную документацию, но и файлики "Readme" на установочных дискетах. Ну а пользователям пиратской продукции могу только посочувствовать.
Здесь следует добавить еще несколько слов вот о чем: если на Вашей сети установлено несколько протоколов, то запись в AUTOEXEC.BAT "set nethaspprotocol=…" определяет только протокол, который будет использоваться для поиска ключа на сети. А вот с помощью какого протокола будут выполняться файловые операции программой 1С? Нами замечено, что многие сетевые глюки появляются, когда на разных компьютерах сети установлен разный набор протоколов и каждая станция (т.е. каждый экземпляр программы 1С) выбирает тот протокол, который ей больше по душе из того набора, который предлагается на данном компьютере. Поэтому настоятельно рекомендую унифицировать все рабочие станции сети по набору протоколов и их настройкам.
5. NE2000-совместимые драйверы.
Очень часто в процессе установки сетевой карты в компьютер Win95 сама определяет свежеустановленную сетевую карту как NE2000-совместимую и устанавливает соответствующий драйвер. Многие "специалисты" этим и удовлетворяются. А иногда просто для карты нет дискеты с драйвером и искать его лень - ведь установился же NE2000-совместимый и вроде бы даже все работает. Вот это самое "вроде все работает" может жестоко Вас подставить.
Действительно, если на сетевую карту установился NE2000-совместимый драйвер, то сеть внешне может быть вполне (и даже очень хорошо) работоспособна. Однако, установка такого драйвера на современную сетевую карту подобна установке драйвера VGA на хорошую видео карту с ускорителем. Вы не в состоянии использовать всю ее функциональность. Дело в том, что сетевая карта имеет много аппаратных функций, которые используются сетевым ядром системы Windows95 через драйвер карты. Если установлен "родной" драйвер, то все эти функции полноценно используются. Если же установлен NE2000-совместимый драйвер, то во время установки он проводит тесты, чтобы определить, какие функции имеются у карты. Как правило, аппаратное исполнение любой сетевой карты хоть немного, да отличается от стандарта совместимости, по которому действует драйвер NE2000. Поэтому, некоторые из имеющихся в наличии функций, остаются для NE2000-совместимого драйвера невидимыми и при последующем обращении ядра Windows к этой функции, драйвер даже не пытается что-то сделать с картой, а просто возвращает ядру код успешного завершения. Для обычной работы сети большинство таких "продвинутых" функций не нужны, поэтому все выглядит пристойно - сеть работает, файлы качаются и т.д. и т.п. Однако, программа 1С для поиска ключа видимо использует какую-то из этих функций, скорее всего что-то связанное с широковещательными посылками. Если NE2000-совместимый драйвер способен реально заставить карту выполнить эту функцию, то все будет хорошо: ключ будет найден. Если же выполнение функции просто имитируется, то программа 1С ключ не найдет.
По опыту работы могу сказать следующее: в 60-70% случаев неработоспособности программ 1С на сети (не находится ключ) виноваты те, кто залепил NE2000-совместимый драйвер вместо "родного", поставляемого на дискете или CD вместе с картой. Особенно это касается случаев установки такого драйвера на компьютер, на котором установлены ключи NetHASP.
Метод лечения очевиден: установить "родной" драйвер. А вывод прост: всегда, когда на сети с программами 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 компьютеров, даже если на них только вбивают накладные. Трафик по сегменту будет слишком интенсивным и сеть будет тормозить.
При возможности используйте "европейский" метод разводки сети, т.е. все кабели от всех рабочих мест сводятся в одну комнату. Конечно, кабеля может потребоваться значительно больше и за прокладку придется платить больше, но поверьте, при последующей эксплуатации это окупится сторицей.