Какой sql server выбрать для 1с 8.3. Выбор дисковой подсистемы

В любой организации, где количество пользователей 1С 8.3 (или 8.2) от 10 и более, при больших объемах данных рекомендуется использовать клиент-серверный вариант работы. Такой вариант основан на использовании сторонней СУБД, например, MS SQL server. Естественно, клиент-серверный режим сложно представить без отдельно стоящего сервера. Но каждая компания уникальна, у каждой свои потребности, поэтому и к выбору сервера необходимо подходить с ответственностью. В этой статье мы постараемся дать ответ на вопрос, как выбрать сервер 1С — как программное обеспечение, так и железо. Выбор — очень важный пункт в развитии информационной системы компании.

Без программного обеспечения любой компьютер бесполезен. Особенно качественный софт важен в серверном оборудовании. Он должен отвечать самым современным параметрам безопасности и надежности. Клиентское приложение 1С мультиплатформенно и доступно практически во всех операционных системах, включая мобильные системы. Серверное же приложение поддерживает две платформы — Linux и Windows.

Существует пять вариантов СУБД, с которой работает платформа 1С:

Получите 267 видеоуроков по 1С бесплатно:

  • встроенная СУБД самой 1С 8.3, так называемый файловый режим . Самый простой вариант работы, не может похвастаться высокой безопасностью. Работает на ОС Windows и Linux. Ограничение на размер базы данных около 6-10 гигабайт;
  • MS SQL Server — лучшая СУБД для 1С, имеющаяся на рынке. По мнению многих экспертов SQL Server вообще лучший программный продукт фирмы Microsoft. Для работы требуется ОС семейства Windows;
  • IBM DB2 Universal Database — достаточно надежная и безопасная система управления СУБД. Особенность её в некоторых нюансах обработки информации и работы системных методов (например, чувствительность к регистру строковых данных). На качество работы существенно влияют навыки и знания администратора. Поддерживает Windows, Mac OS X, Linux;
  • Oracle Database — версионная СУБД, что даёт в некоторых случая повышение производительности. Поддерживает Windows, Mac OS X, Linux;
  • PostgreSQL — также версионная. Самое главное преимущество — бесплатный дистрибутив программы. На скорость работы сильно влияет квалификация администратора. Рекомендуется для небольшого количества пользователей. Работает на Windows, Mac OS X, Linux.

Выбор железа для 1С

В отличие от программ выбрать аппаратное обеспечение не так просто. Рассмотрим выбор серверных компонентов для разных количеств пользователей. Количество пользователей — понятие абстрактное, берутся средние для документооборота цифры. При подборе оборудования обязательно учитывайте объем документооборота.

До 10 пользователей

  • Процессор : Intel Core i3 или Intel Xeon E3-12xx.
  • Оперативная память : 4 гигабайта, в них включается 2 гб на операционную систему и 2 гигабайта под кеш СУБД.
  • Дисковая подсистема
  • Сетевые интерфейсы

Сервер от 10 до 40

  • Процессор : аналог Intel Xeon E3-12xx или AMD Opteron 4ххх.
  • Оперативная память : обычно достаточно 8-12 гигабайт.
  • Дисковая подсистема : в идеале желательна комбинация SSD + HDD. Но если нет возможности, можно обойтись и HDD.
  • Сетевые интерфейсы : обычно все серверные приложения установлены на одной машине.

от 40 до 70

  • Процессор
  • Оперативная память : 16 гигабайт, а лучше 32.
  • Дисковая подсистема : Достаточно традиционного массива из HDD SAS 15K rpm.
  • Сетевые интерфейсы : Если серверы на разных машинах, использовать сеть с пропускной способностью 10 Gb.

от 70 до 120

При таком количестве пользователей имеет смысл в распределении серверных приложений на отдельные серверные машины.

  • Процессор : Intel Xeon E5-26xx или AMD Opteron 62xx.
  • Оперативная память : от 32 гигабайт.
  • Дисковая подсистема : RAID 10 из надежных серверных SSD с обязательным аппаратным RAID-контроллером.
  • Сетевые интерфейсы : Желательно связать цепочку серверов в сеть с пропускной способностью 10 Gb. Индексные файлы рекомендуется вынести на отдельный SSD, таблица временных таблиц TempDB - на 1-2 (RAID 1).

от 120 пользователей

Сервер для 1С - важный технический элемент при построении IT- инфраструктуры. Мы готовы продать серверное оборудование с отличной конфигурацией по адекватной стоимости, без огромных наценок. Только целесообразные конфигурации для решения ваших задач. Оставьте заявку и вы получите устройство, способное закрыть технические потребности организации.

Мы готовы предоставить серверное оборудование любой сложности с соответствующей требованиям конфигурацией. Есть удобная доставка. В Москве доступен самовывоз. В общем, если желаете приобрести, то достаточно просто позвонить, заполнить форму расчета либо написать на электронную почту. Мы предлагаем разнообразные комплектующие, варианты сборок, сделаем коммерческое предложение. Будем отталкиваться от бюджета и собирать максимально целесообразные серверы 1С.

Если пришли за информацией, то она расположена ниже. Мы постарались разместить полноценный материал, способный дать пусть и не исчерпывающий, но объемный ответ на вопрос. Предупреждаем сразу, сведения скорее о железе, чем о программном обеспечении.

  • Сервер 1С на 5-10 пользователей
  • Сервер 1С на 10-20 пользователей
  • Сервер 1С на 20-30 пользователей
  • Сервер 1С на 30-50 пользователей
  • Сервер 1С на 50-100 пользователей
  • Сервер 1С на 200+ пользователей

В данном случае требуется индивидуальная конфигурация. Составлять конфигурацию наугад практически не имеет смысла, так как нагрузка может серьезно разниться в зависимости от задач пользователей. В некоторых случаях одним устройством ограничиться не получится, потребуется кластер. Оставьте заявку, чтобы специалист смог с вами связаться и уточнить детали.

Любую сборку можно сконфигурировать индивидуально под ваши задачи!

Кстати, предварительные параметры можно выбрать в форме ниже. Это позволит специалистам быстрее сформировать коммерческое предложение.

Получить индивидуальный расчет сервера 1С:

Что такое сервер 1С?

Программный комплекс «1С: Предприятия 8.3» представляет собой набор бизнес-инструментов для ведения бухгалтерии, инвентаризации, создания отчетности в автоматическом режиме. Здесь присутствует много возможностей для заточки под любой сегмент деятельности. ПО довольно гибкое в настройках, но, к сожалению, весьма требовательное.

Собственно, применяют сейчас комплекс повсеместно. Крупные организации, бюджетные учреждения, государственные. Причем не только в России, но и за рубежом.

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

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

Типы реализации

Большинство небольших организаций не покупает сервер для 1С. Не видят смысла в такой трате. Ведь достаточно развернуть комплекс на персональном компьютере, следом дать доступ другим ПК. Такой вариант называется «Файловый режим».

Он не способен обеспечить достойную работоспособность, подходит только для применения в локальной сети (конечно, удаленный доступ тоже доступен, но малоэффективен). При превышении числа одновременных обращений к базе выше 5, начинает серьезно тормозить. Периодически зависает. К тому же, ограничение на размер одной таблицы в базе составляет 4 ГБ, крупные компании, стоит сказать, столь объемные таблицы нередко делают. Конечно же, недостатком файлового режима является следующий фактор, чем выше объем базы данных, тем серьезнее требования к ресурсам «железа». К несчастью, если много сотрудников работает в этом ПО либо приходится создавать объемные таблицы, лучше выбрать другой способ реализации структуры ИТ.

И на помощь приходят системы управления DB , которые работают в клиент-серверном типе исполнения. Сервер 1С поддерживает следующие типы СУБД:

    MS SQL Server - СУБД, разработанная компанией Microsoft. Надежна, функциональна, но требуется ОС семейства Windows. Есть определенные недочеты: любит оперативную память, занимает ее полностью, потому, приходится выставлять ограничения вручную, периодически происходят утечки RAM при взаимодействии с табличными массивами.

    PostgreSQL - бесплатный дистрибутив. Местами медлительна, что доказано опытным путем. Подойдет для небольшого состава сотрудников, крупный штат может не вытянуть. Но, несмотря на недостатки, нет ограничений по поддержк е процессоров, а также отсутствует плато ОЗУ. Основное требование - прямые руки системного администратора. При правильной настройке демонстрирует отличные результаты.

    Oracle Database - версионная СУБД, обладающая хорошим функционалом, при том, весьма шустрая, позволяет одновременно проводить запись, чтение. Слабость – требовательность к RAM .

    IBM DB2 Universal Database. Хорошо подходит для обработки крупных массивов. Имеет обширный функционал. К сожалению, в этой СУБД есть много лишнего для сохранения совместимости с устаревшими ЭВМ, что снижает действенность СУБД. К оперативной памяти нетребовательна, но потому, что временные таблицы ограничены. Максимальное число поддерживаемых ядер - 16, что накладывает некоторые ограничения.

Наиболее эффективные по тестам СУБД - MS SQL Server, Oracle. Если в бюджете есть ограничения, то выбор стоит остановить на PostgreSQL, она является бесплатной СУБД, но учтите, работает только та версия, что сделана именно для целевого программного обеспечения. IBM DB2 Universal Database используется редко, ведь есть более продуктивные аналоги, но в поддержке устаревшего оборудования и сборок от IBM – лучшая.

Приходим к выводу, что реализовать в клиент-серверном исполнении гораздо эффективнее . В противном случае получаем тормоза и серьезные ограничения. Надеюсь, с выбором СУБД определились, но по факту скажу, что наиболее удобная и популярная - MS SQL Server. Она лучше всего поддерживается программным комплексом, о котором идет речь.

И сразу отвечу еще на один вопрос. Другие интерпретаторы SQL не поддерживаются. По крайней мере официально.

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

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

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

Чем крупнее организация, шире состав юзеров, тем производительнее потребуется оборудование. В некоторых ситуациях необходим кластер. С виду затраты большие, на деле, купить сервер для 1С и маломощные ПК дешевле, чем пытаться наладить IT-инфраструктуру без оных.

Аппаратура

Итак, какое же железо нам требуется, чтобы реализовать сервер для 1С ? Хороший вопрос, сначала нужно определиться с параметрами, в соответствии с которыми будем выставлять требования:

    количество пользователей;

    объем DB ;

    требующаяся отказоустойчивость;

    тип реализации.

Подставьте к каждому пункту знак вопроса. Отвечайте на них. Фактически, таким образом формируется задача. Теперь попробуем помочь сориентироваться. Начнем с любимых юзеров.

Численность запросов к SQL – ключевой момент при подготовке технической задачи. Каждый человек или программа способна генерировать определенное количество запросов, занимает часть ресурсов аппаратуры. Так что сборка для 5 пользователей может не подойти для 10, для 50 требования будут выглядеть также иначе. Про 100, 200 тоже самое. Конечно, ПО, которое будет автоматически работать с 1С - отдельная тема, требующая более подробного рассмотрения.

Теперь пункт второй. Есть база данных, соответственно, ее где-то надобно разместить, дать нужное для функционирования количество ресурсов. Задача только с виду легкая. Придется подбирать целесообразные накопители, способные обеспечить скорость и нужный объем. Рекомендуется спрогнозировать потенциальный размер БД, тогда будет проще сформировать требования.

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

Тип реализации - фактически, каким образом будем использовать, для каких целей. Ничего сложного. Если только бухгалтерия, то мощность будет менее принципиальна, а вот если используется весь инструментарий, то требуется техника помощнее.

Пройдемся по комплектующим.

Процессор

ЦП с производительностью минимум 1700 МГц, хоть в требованиях значение ниже, но следует ориентироваться на него, и в итоге купить процессор даже помощнее. Идеально подойдет Intel Cor e i3-8100, Xeon E3-1220 v6 либо AMD Ryzen 3 1200. Конечно, наиболь ш ую производительность даст Xeon, но он дороже всех. Это для 5-10 человек . Если планируется увеличение поголовья «юзеров» , то однозначно стоит выбрать Xeon.

На 10-20 человек уже пригодится Intel Xeon E3-1230 v6, в отличие от более младшего собрата он имеет более высокую тактовую частоту и многопоточность. Хоть она не столь принципиальна, но CPU получается на порядок мощнее. Из менее дорогих подойдут Core i5-8500 и AMD Ryzen 5 1500X. Но последние не смогут показать той же производительности, что и Xeon. Так что остановите выбор на последнем.

Если сервер для 1С планируется на 20-50 человек. То сборка нужна производительная. Про процессоры пользовательского сегмента лучше уже забыть и смотреть на серверный сегмент. Итак. Здесь уже понадобятся минимум Intel Xeon E5-1650 v4 с 6 ядрами 12 потоками и базовой частотой 3,6 ГГц вполне хорош. От AMD подойдет ЦП EPYC 7261 с 8 ядрами, 16 потоками и базовой частотой 2,5 ГГц. Конечно, он покажет меньшую производительность, зато чуть дешевле. Но ненамного.

Для 50-100 юзеров стоит взглянуть уже на Xeon E5-1680 v4 от компании Интел, он заметно мощнее, чем предыдущий CPU . Имеет 8 ядер, 16 потоков и 3,4 ГГц частоты. Можно использовать и AMD EPYC 7351 с 16 ядрами, 32 потоками, базовой частотой 2,4 ГГц. Но он значительно хуже Intel. Но и заметно дешевле.

Для более серьезных решений можно использовать даже двухпроцессорные системы, либо сегментировать устройства. Например, для двухпроцессорной системы идеально подойдет Xeon E5-2643 v4. Но сегментировать устройства гораздо целесообразнее. То бишь, реализовать решение сразу на двух аппаратах.

В целом, надо отметить, что количество ядер в сервере для 1С решающей роли не играют. Больший упор нужно делать на тактовую частоту и производительность в последовательных операциях. Потому, многоядерные ЦП смело отбрасывайте. В обозреваемом программном комплексе поддержка многопоточности и многопроцессорности реализована очень плохо. Многочисленные ядра весомых преимуществ не дают.

Накопители

Бутылочное горлышко в системе традиционно HDD. Начнем с интерфейсов. SATA подходит только для последовательных запросов. Какую-либо параллелизацию можно сделать только в RAID- массиве. Интерфейс SAS получше, до 10 единовременных запросов, но пропускная способность жестких дисков все равно оставляет желать лучшего. Наиболее адекватный выбор - SSD. Подойдут твердотельные накопители с SAS, от SATA рекомендуем отказаться, но тоже вариант и они чуть дешевле. В идеале - SSD NVMe. Они наиболее быстродейственный из предложенных . Но, к сожалению, очень дороги. Отталкивайтесь от бюджета, но выбирать рекомендуем SSD, тогда будет реализована более эффективная система.

Оперативная память

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

Обязательно сделайте RAID 1 либо RAID 10 (1+0), второй вариант заметно производительнее. Они обеспечивают дублирующуюся запись памяти. То есть, одно и то же пишется на несколько дисков одновременно. Но учтите, для создания RAID 10 необходимо 4 накопителя.

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

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

юзер занимает ресурсы. Но, на чтение уходит значительно меньше ресурсов, чем на чтение/запись. Потому, один пользователь может давать большую нагрузку, чем несколько других. При планировании IT-инфраструктуры это также придется учесть, чтобы правильно распределить мощности.

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

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

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

Сервер 1С на 5 пользователей

Для 5 человек не требуется высоких мощностей, подойдут конфигурации для малого бизнеса. Если офис небольшой и нужно компактное размещение, то можно использовать мини-сервер. Такой вариант позволит компактно разместить оборудование, и будет удобен при перевозке.

Стоимость такого устройства составить от 30 000 рублей. Конфигурация, как правило, изысками не отличается. Используется процессор начального уровня из серии Intel Xeon E3, либо AMD Opteron. Есть множество готовых сборок под данную задачу. Но в случае дешевых устройств, нет твердотельных накопителей и запаса под пиковые нагрузки.

Сервер 1С на 10 пользователей

Конфигурация на 10 сотрудников аналогична предыдущему решению, особой мощности не потребуется, достаточно использовать мини-сервер. Но пиковая нагрузка должна быть учтена, если есть автоматизированные действия, такие, как автоматическое формирование отчетности с интернет-магазина, то нагрузка может быть гораздо серьезнее.

Здесь также можно обойтись процессором из линейки Intel Xeon E3, например модель 1240. Оперативной памяти хватит и 8 ГБ, но лучше 16, а также стоит использовать SSD для размещения приложения и DB.

Сервер 1С на 20 пользователей

Здесь нужно оборудование мощнее, чем в предыдущем варианте. Вариант для среднего бизнеса оптимален. SSD в такой системе должен присутствовать по умолчанию, а процессор использовать рекомендуется не ниже Intel Xeon E3-1280 v6. В противном случае не останется запас под пиковую мощность.

Сервер 1С на 50 пользователей

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

Обычно для данной задачи собирается двухпроцессорная система на базе процессоров Intel Xeon E5-2643 v4. 2 таких CPU способны закрыть потребности приложения и даже базы данных. Но, в идеале, создать сервер SQL стоит отдельно.

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

Сервер 1С на 100 пользователей

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

Но примерная конфигурация будет такова:

  1. Терминальный сервер приложения. 2 процессора Intel Xeon Silver 4215, для размещения приложения SSD с высоким TDW, два блока питания, дисковая подсистема для бэкапов состояния системы.

    Сервер SQL. Аналогичные процессоры, SSD с высоким DWPD, также два блока питания и дисковая подсистема с RAID 1 для хранения резервных копий.

Это условно, специфика будет зависеть от конечной технической инфраструктуры.

Сервер для 1С на 200 пользователей и более

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

1С:Предприятие 8 может оказаться ресурсоемким приложением даже при небольшом количестве пользователей. Выбирая сервер под 1С, любой владелец хотел бы избежать «родовых травм» - заложенных в него потенциально узких мест. С другой стороны, сегодня мало кто покупает серверы избыточной мощности, «на вырост». Хорошо если профиль нагрузки удается снять заранее - тогда и проектировать сервер под конкретную конфигурацию приложений компании проще.

Для определенности, рассмотрим платформу «1С:Предприятие 8.2» в ее популярных базовых конфигурациях «Бухгалтерский учет», «Торговля и склад», «Зарплата и Управление Персоналом», «Управление Торговым Предприятием» и, отчасти, «Управление Производственным Предприятием». Исходим из того, что для предприятий с 10 и более сотрудниками, работающими в 1С, используется «1С:Предприятие 8.2. Сервер приложений». Учтем вариант работы в режиме удаленного рабочего стола (Remote Desktop), с количеством одновременных пользователей базы данных до 100-150. Рекомендации будут применимы и для более «тяжелых» БД 1С, но «тяжелые случаи» всегда требуют индивидуального подхода.

Процессоры и оперативная память

Если компания совсем маленькая (2-7 пользователей в системе), база невелика (до 1GB), а «1С:Предприятие 8.2» работает в файловом режиме на пользовательском компьютере, то мы получаем классическую реализацию файл-сервера. С такой задачей по нагрузке на CPU справится даже Intel Core i3, тем более Intel Xeon E3-12xx. Объем необходимой оперативной памяти (RAM) считается совсем просто: 2GB под операционную систему и 2GB под системный файловый кеш.

Если в компании 5-25 пользователей 1С, размер базы данных до 4GB, то приложению «1С:Предприятие 8.2» должно хватить 4-х ядерного Intel Xeon E3-12xx либо AMD Opteron 4ххх. Кроме 2GB оперативной памяти под ОС, необходимо выделить 1-4GB под «1С:Предприятие 8.2. Сервер приложений» и еще столько же под MS SQL Server в качестве кеша - итого 8-12GB RAM. Для небольших БД желательно кешировать в оперативной памяти не менее 30% БД, а лучше все 100%.

Известен (хотя и не особо афишируется) факт: «1С:Предприятие 8.2. Сервер приложений» очень не любит, когда операционная система выгружает его в swap-файл на жесткий диск, и склонно при этом иногда терять отклик. Поэтому на сервере, где запущен «Cервер приложений», всегда должен быть запас свободного пространства в оперативной памяти - тем более она сегодня недорога.

В компаниях побольше пользователи 1С обычно работают через удаленный доступ к приложению (Remote Desktop) - то есть в терминальном режиме. Как правило, при10-100 пользователях 1С с базой данных от 1GB и выше, «1С:Предприятие 8.2. Сервер приложений» и пользовательское приложение «1С:Предприятие 8.2» запускается на одном и том же сервере.

Для определения необходимых процессорных ресурсов исходят из того, что одно физическое ядро может эффективно обрабатывать не более 8 пользовательских потоков - это связано с внутренней архитектурой процессоров. Как показывает практика, под задачи 1С + Remote Desktop не стоит брать серверные процессоры младших линеек с низкими частотами расчетных ядер и урезанной архитектурой. Если пользователей немного (до 15-20), хватит одного процессора из высокочастотных Intel Xeon E3-12xx. При этом минимум одно его физическое ядро (2 потока) уйдет под нужды SQL Server, еще одно (2 потока) - под «1С:Предприятие 8.2. Сервер приложений», а оставшиеся 2 физических ядра (4 потока) - под ОС и терминальных пользователей. При количестве пользователей 1С более 20 или при объемах БД более 4GB пора переходить к 2-х процессорным системам на Intel Xeon E5-26xx или AMD Opteron 62xx.

Расчет нужного объема оперативной памяти относительно прост: 2GB надо отдать ОС, 2GB и больше - MS SQL Server в качестве кеша (не менее 30% БД) , 1-4GB - под «1С:Предприятие 8.2. Сервер приложений», остальной памяти сервера должно хватать под терминальные сессии. Один терминальный пользователь, в зависимости от конфигурации, потребляет в приложениях «Бухгалтерский учет», «Торговля и склад» - 100-120MB, «Зарплата и Управление Персоналом», «Управление Торговым Предприятием» - 120-160MB, «Управление Производственным Предприятием» - 180-240MB. Если пользователь запускает дополнительно на сервере MS Word, MS Excel, MS Outlook, то на каждое приложение надо выделить еще порядка 100MB. Как правило, минимум для сервера терминалов - 12GB RAM.

К примеру, для сервера 1С со всем пакетом ПО, 50 терминальными пользователями в конфигурации «Управление Торговым Предприятием», и базой данных в 8GB оптимальной будет вычислительная мощность двух процессоров Intel Xeon E5-2650 (8 ядер, 16 потоков, 2.0 GHz). Оперативной памяти понадобится минимум 2 (ОС) + 4(SQL) + 4(1C-сервер) + 8 (160 «УТП» * 50 пользователей) = 18GB, а лучше 24-32GB(6-8 каналов DIMM по 4GB).

Дисковая подсистема

Большинство жалоб на медленную работу серверов 1С:Предприятие 8 связано с непониманием, какие на них выполняются типы операций ввода-вывода, над какими данными и с какой интенсивностью. Зачастую, именно дисковая подсистема является ключом к обеспечению достаточной производительности сервера в целом - ведь для нагруженных БД самой большой проблемой является блокировка таблиц при одновременной работе с ними множества пользователей или при массовых загрузках/выгрузках/проводках. Мониторингу и оптимизации дисковой подсистемы сервера .

У 1С есть 5 потоков данных для дисковой подсистемы, с которыми она работает:

  • таблицы баз данных;
  • индексные файлы;
  • временные файлы tempDB;
  • log-файл SQL;
  • log-файл пользовательских приложений 1С.

Структура данных в 1С - объектно-ориентированная, со множеством объектов и связей между ними. Для работы с таблицами данных чрезвычайно важно количество операций чтения и записи, которые способна проделать дисковая подсистема за промежуток времени (Input Output Operation per Second, IOPS). При этом ее способность выдать высокую потоковую скорость передачи данных (в MBp/s) куда менее важна. Очень скромная база объемом 200-300MB с 3-5 пользователями может генерировать в пиках до 400-600 IOPS. База на 10-15 пользователей и объёмом в 400-800MB способна выдать 1500-2500 IOPS, 40-50 пользователей БД 2-4GB порождают5000-7500 IOPS, а базы под 80-100 пользователей легко достигают 12000-18000 IOPS.

Разумеется, средняя нагрузка на дисковую подсистему может составлять и 10-15%от пиковой. Только в реальности важна именно производительность в период пиковых нагрузок: автоматических загрузок данных из других систем, обмена данных распределённой системы или перепроведения периода.

Современные диски в операциях чтения и записи со случайным доступом (Random Read/Write) в одиночку справляются с такими нагрузками:

Intel 910 400 GB

2400 – 8600 IOPS

Хорошо видно, что:

  • узким местом и для HDD, и для SSD является запись;
  • традиционные HDD - не конкуренты SSD по скорости чтения в IOPS даже теоретически, разница превышает два порядка;
  • даже не самый современный десктопный SSD в 3-40 раз (в зависимости от конфигурирования) превосходит по скорости записи в IOPS любой HDD, серверный SSD - в 12-40 раз быстрее HDD;
  • максимальную производительность в IOPS дают PCIe SSD класса Intel 910 или LSI WarpDrive.

Одиночные диски в серверах БД не используются, только RAID-массивы. Для дальнейшего расчета реальной производительности дисковой подсистемы нужно учесть затраты («штраф») на запись в IOPS, которые несет дисковая группа в RAID:

Если собрать 6 дисков в RAID 10, то на каждую запись в 1 IOPS данных будет потрачено 2 IOPS физических дисков, а если в RAID 6 - то 6 IOPS дисков. Таким образом, при расчете нагрузочных возможностей дисковой группы на запись нужно вначале сложить IOPS всех дисков RAID-группы, а затем разделить их на «штраф».

Пример 1: 2 HDD SATA 7200 в RAID 1 обеспечат на запись: (100 IOPS *2) / 2 = 100 IOPS.

Пример 2: 4 SATA 7200 в RAID 5 обеспечат на запись: (100 IOPS *4) / 4 = 100 IOPS.

Пример 3: 4 SATA 7200 в RAID 10 обеспечат на запись: (100 IOPS *4) / 2 = 200 IOPS.

Примеры 2 и 3 наглядно демонстрируют, почему для хранения баз данных, у которых типовое распределение чтение/запись составляет 68/32, предпочтителен RAID 10.

Из данных трех таблиц понятно, по какой причине производительности типового «джентльменского набора» 2 HDD SATA 7200 в RAID 1 серверу недостаточно: при пиковых нагрузках растет очередь обращений к диску, пользователи ожидают ответа системы, иногда по многу часов.

Как увеличить производительность дисковой подсистемы на запись? Наращивают количество дисков в RAID-группе, переходят к дискам с большей скоростью вращения, выбирают уровень RAID c меньшим штрафом на запись. Хорошо помогает кеширование RAID-контроллером с включенным режимом отложенной записи Write back. Данные пишутся не напрямую на диски (как в режиме Write Through), а в кеш контроллера, и только затем, в пакетном режиме и упорядоченном виде - на диски. В зависимости от специфики задачи, производительность записи удается поднять на 30-100%.

Под слабо нагруженные или относительно небольшие БД (до 20GB) подойдет недорогой способ «добычи IOPS» - гибридный RAID из SSD/HDD . Большего и не нужно филиальной БД на 3-15 пользователей в распределённой структуре вроде сети кафе или СТО.

Для объемных (200GB и более) БД с длинным историческим шлейфом данных, либо для обслуживания нескольких объемных БД эффективным может оказаться SSD-кеширование (технологии LSI CacheCade 2.0 или Adaptec MaxCache 3.0). По опыту эксплуатации таких систем, именно в задачах 1С с их помощью можно относительно недорого и без существенных изменений в инфраструктуре хранения ускорить дисковые операции на 20-50%.

Чемпионом по быстродействию в IOPS предсказуемо являются RAID-массивы на серверных SSD - как традиционные, с использованием SAS RAID-контроллера, так и PCIe SSD. Мешают их популярности два ограничителя: технологический (производительность RAID- контроллеров или необходимость радикально ломать структуру хранения) и цена реализации.

Отдельно следует сказать о хранении индексных файлов и TempDB. Индексные файлы обновляются очень редко (обычно 1 раз в сутки), зато читаются очень и очень часто (IOPS). Таким данным просто необходимо храниться на SSD, c их показателями по чтению! TempDB, используемые для хранения временных данных, как правило, невелики по объему (1-4-12GB), зато очень требовательны к скорости записи. Индексные и временные файлы объединяет то, что их потеря не приводит к потере реальных данных. А значит, они могут размещаться на отдельном (еще лучше - на двух отдельных томах) SSD. Хотя бы и на бортовом контроллере SATA материнской платы. С точки зрения надежности и быстродействия, под TempDB желательно отдать зеркало (RAID1) из SSD, можно на бортовом контроллере, но с обязательным выключением всех кешей на запись. С этой ролью справятся и десктопные SSD - вроде Intel 520-серии, где аппаратная компрессия данных при записи в TempDB будет как раз уместной. Вынос этих задач с общей системы хранения на выделенную скоростную подсистему положительно сказывается на производительности системы в целом, особенно в моменты пиковых нагрузок.

В случаях, когда есть возможность обеспечить максимально быструю реакцию администраторов при сбоях, и когда имеются сложные расчетные задачи (складская или транспортная логистика, производство в УПП, объемные обмены в УРБД), TempDB выносят на RAMDrive. Такое решение позволяет выиграть иногда до 4-12% общей производительности системы. Некоторое неудобство возникает только в случае рестарта сервера: если автоматически RAMDrive не запустится, потребуется вмешательство администратора для ручного старта - иначе станет вся система.

Еще один важный компонент - log-файлы. Они имеют неприятную для любой дисковой подсистемы особенность - генерировать почти постоянный поток мелких обращений на запись. Это незаметно при средних нагрузках, но сильно ухудшает быстродействие сервера 1С при пиковых нагрузках. Разумно выносить log-файл (в особенности, log-файл SQL) на отдельный физический том, к которому нет высоких требований по IOPS, и на который будет идти практически линейная запись. Для спокойствия можно создать зеркало из недорогих и объемных SATA/NL SAS (для Full log), либо недорогих десктопных SSD все той же Intel 520-й серии (Simple log, или Full log, с ежедневным его Backup и очисткой).

В целом можно сказать, что приход SSD в серверы открыл новые возможности увеличения производительности массовых серверов - за счет многоуровневого хранения данных и разумного конфигурирования дискового ввода/вывода.

Дисковая подсистема «идеального сервера под 1С» выглядит так:

1. Таблицы базы данных размещены на RAID 10 (или RAID 1 для малых БД) из надежных серверных SSD с обязательным аппаратным RAID-контроллером. При высоких требованиях по IOPS можно рассмотреть вариант PCIe SSD. Для БД большого объема эффективно SSD-кеширование массивов HDD. Если используемая конфигурация 1С и структура данных не слишком требовательны к IOPS, а количество пользователей невелико - хватит традиционного массива из HDD SAS 15K rpm.

2. Индексные файлы вынесены на быстрый и недорогой одиночный SSD, TempDB - на 1-2 (RAID 1) SSD или RAMDrive.

3. Под log-файлы SQL (а желательно и 1С) отведен выделенный том (одиночный физический диск или RAID-1) на SATA/NL SAS HDD или недорогих SSD, либо логический диск на RAID-массиве, на котором расположена операционная система сервера и пользовательские файлы/папки.

4. Операционная система и пользовательские данные хранятся на RAID 1 из HDD или SSD.

Если IT-инфраструктура виртуализирована, крайне желательно, чтобы SQL Server был установлен не как виртуальная машина, а непосредственно на физический сервер, на «голое железо». Цена вопроса - от 15 до 35% производительности дисковой подсистемы (в зависимости от оборудования, драйверов, средств виртуализации и способов подключения тома). В виртуализированной среде SQL-сервера подключение томов с таблицами БД, индексными файлами и TempDB к VM обязательно в монопольном режиме по Direct Access.

Сетевые интерфейсы

При построении систем 1С:Предприятие 8 для малых и средних предприятий (до 100-150 активных пользователей одновременно) следует минимизировать потери на сетевых операциях через интерфейс Ethernet. В идеале - обслуживать и SQL Server, и «1С:Предприятие 8 Сервер приложений х64», и пользовательские сессии 1С в Remote Desktop одним физическим сервером. Спорная с точки зрения обеспечения отказоустойчивости, такая рекомендация позволяет выжать максимум из оборудования и ПО, а за счет применения виртуализации дает определенный уровень безопасности и «повторяемость среды» на другом оборудовании.

Зачем исключать Ethernet из цепочки SQL-сервер -> Сервер приложений 1С:Предприятие 8 -> пользовательская сессия 1С:Предприятие 8? Сетевой интерфейс Ethernet, с его упаковкой данных в относительно небольшие блоки для передачи, всегда будет создавать дополнительные задержки: и при упаковке/распаковке трафика, и при самой передаче (высокая латентность). В 1С:Предприятие 8 довольно большие массивы данных передаются для обработки и отображения по всей цепочке, в некоторых ситуациях - в обе стороны. При прямой же передаче данных от одного процесса другому в рамках оперативной памяти сервера (на одном сервере без виртуализации), или же через виртуальный сетевой интерфейс (в рамках все того же одного физического сервера, при хороших серверных сетевых адаптерах с переносом блоков RAM между VM) задержки намного ниже. Современные двухпроцессорные серверы с большой оперативной памятью и дисковой подсистемой на SSD позволяют комфортно обслужить БД 1С на 100-150 активных пользователей.

Если для нагруженных БД использование нескольких физических хостов неизбежно, желательно связать все серверы по 10Gb Ethernet. Или, как минимум, 2-4агрегированными соединениями 1Gb Ethernet с аппаратным ускорением TCP/IP (TCP/IP Offloader) и аппаратной поддержкой виртуализации.

Больше всего от потерь производительности на портах Ethernet страдают бюджетные решения. Не секрет, что сетевые адаптеры 1Gb, распаиваемые на большинстве серверных материнских плат, не предназначены для обслуживания интенсивного сетевого трафика. Даже если на плате есть 2 или 3 порта GbE, они, как правило, реализованы на десктопных чипах. Достаточные для управления, они порождают дополнительные накладные расходы по обслуживанию сетевых обменов, особенно в виртуализированной среде. Весь процесс передачи данных через такой чип обеспечивается за счет ресурсов процессора, оперативной памяти и нагрузки на внутренние шины. Никакого ускорения передачи IP-трафика такие чипы не дают, каждый принимаемый и передаваемый Ethernet-пакет требует отдельного прерывания на процессор. В виртуализированой среде потери производительности сетевого интерфейса могут достигать 25-30%. Самое неприятное, что перегрузки именно сетевого интерфейса средствами мониторинга можно и не заметить. За него отдувается центральный процессор, а если не работает, то простаивает в ожидании ответа от сетевой карты. Порты на десктопных чипах желательно исключить из потока данных в виртуализированных средах, оставив их под задачи управления сервером. Под интенсивный сетевой трафик стоит добавить дискретную сетевую карту на серверном чипсете.

Отказоустойчивость или допустимое время простоя?

Обсуждение производительности серверов почти всегда сопровождается спорами об их надежности. Обеспечение отказоустойчивости всегда требует дополнительных затрат, в особенности при поддержке непрерывных производственных процессов. Не принижая роли и места 1С, можно сказать, что большая частью ее пользователей дилемму «производительность/надежность» решает в разных плоскостях: за первую борются оптимизацией аппаратных решений, за вторую - организацией процессов и процедурами. Когда приложения умеренно критические, основное внимание в поддержании работоспособности уделяют не средствам индивидуальной защиты серверов, а минимизации простоя инфраструктуры в целом.

Разумеется, для предприятий с относительно большим количеством одновременно подключенных пользователей (25-150) и размещением всех приложений на одном сервере обязательно применение источников бесперебойного энергоснабжения, избыточных блоков питания самих серверов, корзин горячей замены дисков и RAID-массивов с горячим резервированием. Но никакие аппаратные средства не заменят планового резервирования самих данных. Имея ежедневный (точнее, еженощный) backup и оперативный файл с Full SQL log, можно полностью восстановить БД 1С за относительно короткий промежуток.

Допустимое время простоя центральной системы 1С для малых и средних предприятий - 1-2 аварии в месяц, продолжительностью 1-4 часа. На самом деле, это огромный запас времени - если к восстановлению быть готовыми заранее. Необходимым условием быстрого рестарта является наличие образов всех виртуальных и физических серверов в виде VM на отдельном хранилище/томе - для восстановления самой инфраструктурной части на резервном сервере. Обязателен ежедневный backup (а также еженедельный и по закрытию периода) на другое физическое устройство и Full SQL log для случаев, когда потеря данных «с начала рабочего дня» критична и трудно восстановима вручную. При наличии подменного оборудования можно уложиться в 1-2 часа для восстановления работоспособности в целом, пусть и с меньшей производительностью. Ну а там, где требуется непрерывность работы 24×7, первоочередными задачами будут выбор соответствующей архитектуры, оборудования с минимальным количеством точек отказа и полноценных технологий кластеризации. Но это уже совсем другая история.

Оригинал статьи: http://ko.com.ua/proektirovanie_servera_pod_1s_66779

С разрешения редактора журнала "Компьютерное обозрение"

Платформа «1С:Предприятие» версий 8.2 и 8.3 считается стандартным приложением для задач учета и управления компаний. Разработан широкий выбор прикладных решений для государственных и частных предприятий. Внедряя собственную информационную инфраструктуру, у каждого руководителя или IT-менеджера компании возникает вопрос, какой нужен сервер для «1С». Проблема осложняется тем, что покупка оборудования требует значительных финансовых затрат, и далеко не каждое предприятие может позволить себе выбрать топовые конфигурации.

Мы собрали рекомендации ведущих производителей оборудования (HP, Dell, IBM) и разработчиков программного продукта «1С» 8.3, чтобы наши клиенты могли выгодно приобрести нужный сервер. Оптимальная инфраструктура сети может быть получена на базе любой операционной системы, но возможности оборудования играют в этом более важную роль.

Критерии выбора серверов

Платформа «1С» может потребовать значительных аппаратных ресурсов от сервера. Если бюджет компании неограничен, что бывает нечасто, можно не задумываясь брать платформы последних поколений, заполнять все дисковые корзины, слоты для ОЗУ и требовать от IT-специалиста бесперебойной работы системы. Выбор оборудования с ограниченными средствами требует более взвешенного подхода. Чтобы понять какому серверу для «1С» будет под силу справиться с этим, необходимо тщательно проанализировать структуру вычислительных нагрузок. Если они известны заранее, спроектировать готовое решение будет значительно проще.

При выборе сервера для «1С» (8.2; 8.3) ориентируются на следующие моменты:

  • количество операторов, одновременно выполняющих ввод данных и формирование отчетов;
  • возможность выделения отдельных физических серверов для SQL и приложения «1С»;
  • планируемые объемы обработки данных;
  • структуру распределения нагрузки в архитектуре клиент-сервер

Выбор процессора и оперативной памяти

Расчет частоты, нужного количества ядер процессора, а также объема оперативной памяти является первым и самым важным шагом. Чтобы рассмотреть несколько вариантов, выбирать сервер для «1С» будем с учетом штата компании.

Малая организация (до 15 сотрудников). При небольшом количестве пользователей объем базы данных, как правило, не превышает 2 Гб, а программа «1С» в виде файловой версии устанавливается на клиентские машины. Нужды ОС при этом составляют 4–6 Гб и еще 4 Гб выделяют на системный файловый кэш. Распределение нагрузки процессора выглядит следующим образом:

  • 2 ядра – для ОС и терминальных пользователей;
  • 1 ядро – для сервера приложений «1С»;
  • 1 ядро – для БД SQL.

С такой задачей справятся машины начального уровня с одним четырехъядерным процессором. Это могут быть как стоечные, так и башенные серверы. Последний вариант предпочтительнее, поскольку не требует выделения отдельного помещения под серверную.

Средняя организация (до 40 сотрудников). При таком количестве пользователей разработчики «1С» рекомендуют использовать терминальный режим доступа к приложению. Размер баз данных может составлять до 4 Гб. Для такой нагрузки нужно уже как минимум два процессора на 4–6 ядер. Оптимальный объем оперативной памяти составит 16–64 Гб, поскольку для каждого пользователя необходимо выделить минимум 700 Мб. Считается, что прикладное решение «1С», в котором работает клиентская машина, требует от 240 до 480 МБ, а еще 200–220 МБ выделяется под офисные приложения.

При таком количестве процессов рекомендуется использовать одну машину среднего уровня с виртуализацией либо два физических сервера. Один из них будет использоваться для терминального доступа, а второй – для SQL. Сервер приложений «1С» лучше всего реализовать на первой машине или вообще выделить для этого отдельную однопроцессорную систему. Нужная конфигурация подбирается в каждом конкретном случае на основе анализа процессорного времени.

Большая организация (более 40 сотрудников). Базовая конфигурация оборудования в этом случае будет состоять из трех физических серверов:

  • терминального,
  • СУБД,
  • «1С».

Объемы БД при таком количестве сотрудников часто превышают 4 Гб, и под системный кэш рекомендуется выделять не меньший объем оперативной памяти. Еще 4 Гб будет использоваться операционной системой, а для приложений «1С» потребуется около 8 Гб. Таким образом, нужно не менее 16 Гб ОЗУ.

Под такие задачи подбираются двухпроцессорные серверы с поддержкой Intel Xeon E5-2600 или выше. Если количество сотрудников не превышает 50 человек, для терминального доступа и приложений «1С» можно оставить только одну машину. Однако с учетом перспективы роста компании лучше предусмотреть отдельный сервер для каждой задачи. Если количество задействованного персонала приближается в 100 сотрудникам, нужно развернуть кластер из двух машин для «1С», а для остальных задач оставить по одной.

Выбор дисковой подсистемы

Производительность сервера напрямую зависит от дисковой подсистемы. При работе приложений «1С» операции чтения и записи данных выполняются с высокой интенсивностью. Большинство жалоб на работу сервера связаны с блокировкой таблиц при одновременном обращении большого количества пользователей.

В задачу выбора сервера для 1С входит мониторинг дисковой подсистемы, позволяющий найти оптимальное соотношение производительности и надежности. Чрезвычайно важным фактором, влияющим на быстродействие, оказывается ее способность выполнять определенное количество операций чтения/записи в секунду (IOPS). Если база данных составляет до 300 Мб, а количество пользователей «1С» – до 6 человек, этот параметр составляет 400–600. Если количество пользователей сервера доходит до 100 человек, то IOPS будет равняться 18 000. Потоковая скорость передачи играет второстепенную роль.

Для каждого типа жестких дисков установлены значения скорости чтения/записи:

  • SATA – 100/80;
  • SAS – 240/220;
  • SSD – 35 000/8 600.

Отсюда видно, что для серверов баз данных «1С» лучше всего подходят твердотельные накопители. Главным фактором, ограничивающим их использование, является высокая стоимость. Поэтому для снижения бюджета используются и SAS-накопители. Для хранения критичных данных, в том числе «1С», жесткие диски объединяются в RAID-массивы разных уровней, и в расчет производительности сервера следует включать заложенную в них избыточность.

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

Найти нужный сервер и сконфигурировать его под 1С можно на сайте сайт. Наши специалисты окажут помощь в решении этой задачи. Для получения консультаций свяжитесь с ними по телефону или обратитесь к менеджеру в чате.

Клиент-серверный вариант работы - один из вариантов работы системы 1С:Предприятие 8 .

Клиент-серверный вариант работы предназначен для использования в рабочих группах или в масштабе предприятия. Он реализован на основе трехуровневой архитектуры «клиент-сервер».

Клиент-серверная архитектура разделяет всю работающую систему на три различные части, определенным образом взаимодействующие между собой:

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

При этом физически кластер серверов 1С:Предприятия 8 и сервер баз данных могут располагаться как на одном компьютере, так и на разных. Это позволяет администратору при необходимости распределять нагрузку между серверами.

Использование кластера серверов 1С:Предприятия 8 позволяет сосредоточить на нем выполнение наиболее объемных операций по обработке данных. Например, при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере. Обычно увеличить мощность кластера серверов гораздо проще, чем обновить весь парк клиентских машин.

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

1С:Предприятие 8 использует возможности системы управления базами данных для эффективной выборки информации:

  • механизм запросов ориентирован на максимальное использование СУБД для выполнения расчетов и составления отчетов,
  • просмотр больших динамических списков обеспечивается без выполнения большого количества обращений к базе данных; при этом пользователю предоставляются возможности эффективного поиска, а также настройки отбора и сортировки.

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

Клиентские приложения

Работа в клиент-серверном варианте возможна как напрямую с кластером, так и через веб-сервер. При этом в случае непосредственного подключения к кластеру толстый клиент и тонкий клиент используют протокол TCP/IP . При подключении через веб-сервер тонкий клиент и веб-клиент используют протокол HTTP или HTTPS .

Кластер серверов

Кластер серверов 1С:Предприятия 8 - основной компонент платформы, обеспечивающий взаимодействие между пользователями и системой управления базами данных в клиент-серверном варианте работы. Наличие кластера позволяет обеспечить бесперебойную, отказоустойчивую, конкурентную работу большого количества пользователей с крупными информационными базами.

Сервер баз данных

В качестве сервера баз данных могут использоваться:

Администрирование кластера серверов

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

Выполнение основной функциональности на сервере

Вся работа с прикладными объектами, чтение и запись базы данных выполняется только на сервере. Функциональность форм и командного интерфейса также реализована на сервере.

На сервере выполняется подготовка данных форм, расположение элементов, запись данных форм после изменения. На клиенте отображается уже подготовленная на сервере форма, выполняется ввод данных и вызовы сервера для записи введенных данных и других необходимых действий.

Аналогично командный интерфейс формируется на сервере и отображается на клиенте. Также и отчеты формируются полностью на сервере и отображаются на клиенте.

При этом механизмы платформы ориентированы на минимизацию объема данных, передаваемых на клиентский компьютер. Например, данные списков, табличных частей и отчетов передаются с сервера не сразу, а по мере просмотра их пользователем.

На сервере выполняются:

  • Запросы к базе данных,
  • Запись данных,
  • Проведение документов,
  • Различные расчеты,
  • Выполнение обработок,
  • Формирование отчетов,
  • Подготовка форм к отображению.

На клиенте выполняется:

  • Получение и открытие форм,
  • Отображение форм,
  • «Общение» с пользователем (предупреждения, вопросы…),
  • Небольшие расчеты в формах, требующие быстрой реакции (например, умножение цены на количество),
  • Работа с локальными файлами,
  • Работа с торговым оборудованием.

Использование встроенного языка на клиенте

Управлять функциональностью форм можно не только на сервере, но и на клиенте. На клиенте поддерживается работа встроенного языка. Он используется в тех случаях, когда необходимо провести расчеты, связанные с отображенной на экране формой, например, быстро (без обращения к серверу) подсчитать сумму строки документа на основе цены и количества; задать пользователю вопрос и обработать ответ; прочитать файл из файловой системы компьютера и отправить его на сервер.

Однако работа встроенного языка на клиенте поддерживается в строго ограниченном объеме. Клиентские процедуры в модулях в явном виде отделяются от серверных, и в них используется ограниченный состав объектной модели встроенного языка.

На клиенте не допускается непосредственная работа с базой данных. Не допускается работа непосредственно с прикладными объектами, например, недоступны такие типы встроенного языка, как СправочникОбъект.<имя> . Не допускается использование запросов. При необходимости вызова действий с данными в клиентском коде нужно вызывать серверные процедуры, которые уже будут обращаться к данным.