В последние годы технологии терминального доступа к Windows- приложениям пользуются неимоверной популярностью. В нашей стране основную нишу занимает применение терминального доступа для компен- сации недостатков скорости обработки информации наиболее популярной системы учета – «1С:Предприятие». Именно узкие места реализации обработки данных в этой системе (нера- циональные процедуры чтения-записи записей из БД по сети) привели к не- обходимости решать проблему ускорения системы в целом. Поскольку пе- ределать процедуры обмена самостоятельно невозможно (не имеет смыс- ла, так как система написана производителем и постоянно модифициру- ется по собственным стандартам), необходимо максимально ускорить про- цесс обмена данными в модели клиентсервер, достигнув максимальной ско- рости обмена по сети. Однако никакие типовые локальные сети не позволяют достигнуть той скорости обмена, которая существует на внутренних шинах серверов. Поэтому идея расположить клиентскую и серверную части на од- ном физическом сервере дала максимальное ускорение при работе систе- мы «1С:Предприятия». Подробнее о проблеме Одна из самых неприятных проблем, с которой сталкиваются пользователи системы «1С:Предприятие», – ее медленная работа при увеличении разме- ра информационных баз, а также количества одновременно работающих пользователей. Помимо этого на быстродействие системы в целом может влиять недостаточная производительность серверов и рабочих станций, низкая пропускная способность локальной сети, нерационально состав- ленные процедуры дополнительных отчетов, некорректная настройка IT-инф- раструктуры, отсутствие у техперсонала знаний о возможностях оптимиза- ции информационной системы. Как видите, количество факторов, влияющих на общее быстродействие системы, велико, и не обладая знаниями обо всех возможных причинах за- медления, а главное – о способах устранения таких причин, – невозможно построить быстродействующую систему, на 100% использующую все ее возможности. Успешная работа при реализации многих проектов систем- ной интеграции, связанных с комплексным внедрением систем «1С:Пред- приятие», дает мне возможность максимально точно оценивать причины не- эффективной работы указанного приложения у заказчиков. Общие модели доступа к БД «1С:Предприятие» Наиболее часто использующийся на малых и средних предприятиях ва- риант – файл-серверная модель доступа. В этом случае один из компью- теров исполняет роль файл-сервера, на котором хранятся БД, предостав- ленные в общий доступ по сети, а пользователи играют роль клиентов этого файл-сервера, открывая предоставленные им файлы баз данных на чте- ние и запись. Файл-серверная версия использует файлы в формате DBF. Основное ее преимущество заключается в том, что не требуется дополнительного про- граммного обеспечения для организации работы, так как для подключе- ния к базе данных достаточно предоставить папку с ее файлами в общий доступ, что достигается средствами любой сетевой операционной систе- мы. Этот формат разрабатывался прежде всего для работы с БД небольшо- го размера при малой нагрузке. Поэтому при активной работе нескольких пользователей с базой данных наблюдается значительное замедление ра- боты программы. Особенно если кто-нибудь из пользователей запустит пос- троение масштабных отчётов за большой период времени. О причинах этого замедления я расскажу немного позже, так как именно они мотивируют пе- реход к использованию терминального решения в файл-серверной версии системы «1С:Предприятие». Второй тип организации доступа к базе данных системы «1С:Пред- приятие» – клиент-серверная модель. В клиент-серверной версии таблицы хранятся в базе данных под управлением Microsoft SQL Server, и клиент- ское приложение не открывает файлы базы данных при каждом новом подключе- нии, а посылает запрос серверу баз данных (SQL server). Запрос обрабатывается самим SQL-сервером,который считывает данные из своей базы и выдает клиентскому приложению только необходимую их часть. Таким образом взаимодейс твие «клиент-сервер» сводится к отправке на сервер запроса и получения ответа, содержащего уже отсор- тированные данные вместо самостоятельного считывания клиентом фай- лов БД по сети. Это уменьшает сетевой трафик и увеличивает быстродействие в сравнении с файл-серверной моделью при большом количестве активных пользователей и значительном объеме БД. То есть для клиент-серверной вер- сии время реакции на запросы пользователей при возрастании количес- тва активных пользователей не возрастает так резко, как это происхо- дит с файл-серверной моделью. Однако не стоит забывать, что SQL-вер- сия изначально ориентирована именно на надежность обработки боль- ших объемов данных, хранение которых в файл-серверной модели чрева- то разрушением БД, а не на увеличение скорости работы с приложением (во всяком случае, это относится к сочетанию «1С:Предприятие» – Microsoft SQL Server). Поэтому при малых размерах БД или небольшом количест- ве активных пользователей SQL-версия проигрывает по скоростным пока- зателям файл-серверной. Это можно увидеть на примерном графике со- отношения. Однако при больших объема х БД (например, при общем объеме DBF-файлов, превышающем 2-3 Гб) хранение такой базы в файл-серверном варианте и работа с ней в много- пользовательском режиме может создать проблемы возникновения бло- кировок таблиц при одновременном доступе к ней нескольких пользова- телей, а также разрушение структуры таблиц, что приведет к неработос- пособности БД. SQL-сервер хранит данные в другом формате. Главное принципиаль- ное отличие состоит в том, что при необходимости SQL-сервер обеспечи- вает откат транзакций, аварийно завершившихся по каким-либо причи- нам. То есть в начале любой операции по внесению изменений в БД SQL-сер- вер записывает состояние изменяемого объекта до проведения изменения и отслеживает успех операции. В случае аварийного завершения этой u1086 опе- рации объект не изменяется и возвращается в предыдущее стабильное со- стояние. В случае аварийного завершения операции по изменению фай- ла DBF информация в нем остается «как есть», что может привести к не- работоспособности БД. Поэтому для обеспечения максимальной надежности хранения боль- ших БД и исключения возникновения транзакций рекомендуется использо- вать клиент-серверную модель. В «1С:Предприятии 8.0» использу- ется трёхуровневая архитектура «клиент-сервер», при которой клиентская часть обращается к серверу приложений 1С, а он в свою очередь обращает- ся к серверу баз данных Microsoft SQL Server, который и обрабатывает за- просы к информационной базе. Сервер приложений 1С сосредотачивает на себе выполнение объемных и сложных операций, при этом клиентская часть будет получать необходимую ей выборку. Ресурсы современных сер- веров позволяют расположить и сервер приложений и сервер БД на одном физическом сервере, что, несомненно, ускоряет обработку запросов, од- нако создает двойную нагрузку на ресурсы. К сожалению, именно к этому нас вынуждают схемы взаимодействия клиентов систем «1С:Предприятие» с их серверами. В случае перегрузки такого сервера в моменты пиковых нагрузок жела- тельно разделить Сервер Приложений «1С:Предприятия 8.0» и Microsoft SQL Server, установив их на разных компьютерах, что позволит нормали- зовать работу системы. Рекомендации по выбору необходимого оборудования для различных моделей доступа к БД и максимальных нагрузок будут даны в конце статьи. Разобравшись в моделях доступа к БД в разрезе систем «1С:Предпри- ятие», можно приступать к анализу факторов, влияющих на общее быс- тродействие системы в целом. Еще раз рассмотрим возможные причины замедления: 1. Увеличение размера информа ционных БД: это естественное следствие штатной работы с БД, размер которой зависит от количества введенных документов, однако есть некоторые нюансы. Если компания ведет непрерывный учет всех документов за весь период работы БД, то ее размер при интенсивном документообороте может вырасти до критического за очень небольшой период. Напоминаю, что мы рассматриваем условную величину «критичности» размера БД в файл-серверном варианте, равную 2 Гб. Для клиент-серверной модели это понятие (в разумных пределах), в общем- то, не имеет значения. В случае если компания не собирается переходить к клиент-серверному вари- анту доступа к БД, ей приходится принимать меры по свертке таких баз, путем закрытия отчетных пе- риодов и переноса остатков на начало нового периода. При этом все документы, предшествующие на- чалу нового периода, из базы удаляются. Именно на это я и хотел бы обратить ваше внимание. Да же после удаления неактуальных документов из БД ее размер не изменится! Причина заключается в структуре данных, используемой для хранения БД. При удалении документов из базы на физическом уровне происходит только удаление ссылок на эти документы. Само место, зарезервированное под эти записи, в файлах БД остается занятым. Из-за этого и не меняется размер БД сразу после очист- ки всех помеченных на удаление записей. Для физического сжатия файлов БД необходимо выполнить «Упаковку таблиц БД». Для системы «1С:Предприятие 7.7» это можно сделать из конфигуратора, вы- брав в меню «Администрирование» пункт «Тестирование и исправление ИБ». Будьте осторож- ны с этой процедурой! Ее необходимо проводить только после того, как вы сделали архивную ко- пию БД и провели ее полное тестирование и исправление. Для больших БД данный процесс продолжи- телен и в зависимости от быстродействия компьютера может занимать до 3-5 суток! 2. Увеличение количества активных пользователей БД: тут таких советов, как в предыдущем пункте, дать не получится, так как «Упаковку пользователей» производить запрещено законом… Так что с этим остается только смириться и следовать другим советам по увеличению производительности системы. 3. Недостаточная производительность серверов и рабочих станций: особых хитростей здесь нет, кроме того, что вы должны быть уверены, что замедление работы является следствием недостаточ- ности ресурсов, а не других причин, о которых будет сказано в разделе организации терминального доступа к БД. 4. Низкая пропускная способность локальной сети: для обеспечения достаточного быстродейс- твия необходимо, чтобы пропускная способность сети составляла 100 мегабит от клиента до сер- вера БД (это требование не относится к варианту с сервером терминалов – там достаточно 50-100 килобит(!) в сек. для каждого из клиентов. Для 3-уровневой системы обработки «1С:Предприятие» при разнесении сервера приложений 1С и SQL-сервера по физически разным серверам рекомендуется максимально увеличить скорость их взаимодействия между собой. Нелишним окажется установить в каждый сервер по два и более гигабитных сетевых адаптера и соединить их через гигабитный ком- мутатор, объединив сетевые адаптеры в транк с поддержкой балансировки нагрузки. 5. Зависимость от уровня профессионализма программистов: нередко встречаются случаи, когда отдельные нестандартные процедуры, написанные программистами вручную, работали медлен- но из-за нерационального подхода к анализу данных и затормаживали работу остальных пользова- телей с БД. И наоборот – вручную переписанные талантливым программистом обработки давали не- имоверную производительность даже в простом файл-серверном варианте. При использовании кли- ент-серверной модели максимальной производительности можно достичь, обрабатывая записи БД не- посредственно средствами SQL. Однако не все программисты умеют это делать, а признаться в этом не решаются. 6. Некорректная настройка IT-инфраструктуры техническими специалистами и отсутствие у тех- персонала знаний о возможностях оптимизации информационной системы: здесь все зави- сит от глубокого понимания IT-специалистами происходящих в сети процессов. Помимо общих ка- нонов настройки локальной сети, необходимо учитывать множество факторов. Например, частой ошибкой технических специалистов является отсутствие тонкой настройки антивирусных мониторов. Чаще всего оставляют настройки по умолчанию, что для многих антивирусных продуктов оз- начает постоянную проверку всех подключенных сетевых ресурсов, а также абсолютно всех файлов. Рекомендуется исключать из проверки файлы БД, так как наличие в них вирусов – очень мало- вероятное событие. А вот постоянная проверка файлов метаданных (*.md), структуры метаданных (*.dd) и файлов БД 1С *.dbf и *.cdx замедлят работу всей вашей системы в несколько раз. Замедление работы файл-серверной модели БД на серверах с Windows Итак, мы добрались до рассмотрения технологии терминального доступа,ее преимуществ и причин, по которым ее применение позволяет максималь- но ускорить работу с БД. Наверняка все вы знаете о «странной» особенности работы с БД, расположенных на сетевых дисках серверов, под управлением ОС Windows. С файлсерверами под управлением других ОС дело обстоит получше, но не все умеют их администрировать, да и то ускорение, которое предоставляют технологии терминального доступа, все равно недостижимо другими способами – переносом БД на файл-сервер с ОС, отличимой от Windows. Итак, в чем же заключается эта особенность, из-за которой резко замедляется работа с сетевой БД при одновременной работе с ней более чем одного пользователя? То есть при работе в однопользовательском режиме, даже по сети, скорость работы оказывается приемлемой, однако стоит хотя бы еще одному пользова- телю начать работу с БД, как скорость формирования отчетов и проведения документов падает в несколько раз, а то и на порядок. Это происходит из-за того, что система Windows отключает кэширование дисковых опера- ций при подключении к сетевому ресурсу более чем 1 пользователя. Делается это во избежание потери дан- ных из-за взаимных блокировок, однако сильно страдает производительность системы. Преимущество терминального решения в том, что при его использовании вся обработка информации (не только запросы, но и вся клиентская часть) происходит на сервере терминалов, так что на компьютерах пользователей даже нет необходимости устанавливать программу «1С:Предприятие». По сети компьютерам-клиентам предоставляются только готовые экранные формы, пользовательской тер- минальной сессии. Поскольку передача экранного изображения в сжатом виде требует меньшего потока данных для подключения к серверу терминалов, можно использовать медленные каналы связи, вплоть до обычного мо- дема, а сами компьютеры могут быть низкой производительности. На компьютеры пользователей устанавливается только терминальный клиент, задача которого иници- ировать и поддерживать сеанс связи со сервером терминалов. Именно поэтому не имеет значения, какой ком- пьютер u1091 установлен у клиента – единственная его задача – запустить клиентскую часть, которая будет нормально работать даже на 486-м компьютере с 16 Мб памяти и любой ОС, для которой существует клиент сервера терми- налов Windows. Однако в таком варианте построения сети вся нагрузка перекладывается на сервер, так как в его обязан- ности будет входить не только хранение информационной базы, но и полностью вся обработка, что равносиль- но работе всех пользователей на одном локальном компьютере. Плюс поддержка сеанса связи с каждой подклю- чённой машиной. В терминальном режиме специфична и сама работа пользователей: на экране они видят ра- бочий стол сервера, поэтому все локальные диски и принтеры на самом деле будут являться периферией са- мого сервера. Серьезным расширением возможностей стандартного сервера терминалов Windows является продукт Citrix Metaframe. Он предоставляет возможность сделать работу с терминальны приложением абсолютно прозрачным для пользователя и для удобства позволяет подключить и собственные ресурсы компьютера. Например, подключение к сеансу пользователя его локальных принтеров, на мой взгляд, в Citrix Metaframe организован более удобно. Однако следует учитывать что Citrix Metaframe является только дополнением к стандартному серверу терминалов MS, а не самостоятельным продуктом. Да и стоимость данного «расширения» велика по сравнению с применением стандартного сервера терминалов от Microsoft. К слову, саму технологию Terminal Services компания Microsoft купила именно у компании Citrix. Если вы используете файл-серверную версию программы, то максималь- ные преимущества терминального решения достигаются при расположении базы данных на локальном дисковом массиве этого же сервера. При расположении базы на локальном диске сервера обмен с ней осуществляется по внутренним шинам передачи данных сервера, а не по локальной сети. Именно этим и объясняется «фантас- тическая» скорость работы с БД в режиме сервера терминалов. Не предоставляйте общего сетевого досту- па к папке с базами данных, так как совместное использование u1077 ее по сети значительно замедлит работу. То есть с одной и той же базой все должны работать в терминальном режиме, независимо от ресурсов клиентской рабочей станции. Помимо ускорения работы с БД неоспоримым преимуществом терминал-сервера является сжатие передаваемой по сети информации, что позволяет работать с программой через медленные каналы связи. Именно такая модель доступа позволяет организовать удаленную работу филиальных отделов с единой БД в режи- ме online – ведь для каждого клиента достаточно канала передачи данных шириной 40-60 Кбит/сек. Таким образом, при необходимости предоставить филиальным представительствам доступ к центральной БД (или наоборот) достаточно обладать сервером необходимой мощности для организации на нем сервера терминалов и каналом связи с указанной выше пропускной способностью. Сколько стоит такое терминальное решение? Итак, принимая решение о переходе на терминальную схему работы системы «1С:Предприятие», необходимо учитывать, что для организации работы сервера в режиме сервера приложений необходимо приобрести лицензии клиентского доступа к нему. Каждая лицензия «на устройство» (MS TS CAL) обойдется вам около 80 $. Сам сервер терминалов входит в стоимость лицензии Windows Server. Расширение Citrix Metaframe стоит от 2000 USD за стартовый пакет из 5 лицензий. Каждые последующие 5 лицензий будут стоить около 1500 $. Поэтому (это мое субъективное мнение) покупка MS TS CAL – абсолютно оправдана, так как ускорение работы системы при этом предоставит новые возможности расширения бизнеса. Приобретение же Citrix Metaframe должно быть обусловлено серьезной необходимостью использования возможностей продукта, однако их анализ выходит за рамки данной статьи.