Цены и порядок поставки. Решения Блок питания и ИБП

• Tutorial

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

Пролог.

Основной вид деятельности нашей небольшой компании является IT аутсорсинг. Скорее в маркетингово-энтузиастских целях, мы создаем шаблоны решений, которые нам позволяют немного стандартизировать IT инфраструктуру подопечных, а клиенту получить и главное осознать экономию (если сам себя не похвалишь отчетом, то никто не заметит). Клиенты - небольшие компании от 20 до 200 человек. Одним из таких решений является реализация 1С сервера предприятий на свободной платформе Linux + Postgres SQL. В статье не будет очередной технической реализации, так как все давно разжевано и пережевано . Будет лишь сравнение стандартного предложения от 1С франчайзи и наш экономный вариант на май 2014.

Задача №1.

Осуществить переход базы с файлового режима работы на SQL-ный вариант с возможностью использования до 20 клиентов.

Расчет двух вариантов.

Мы не занимаемся сопровождением 1С, потому все рекомендации: о необходимости перехода с файловой базы на SQL, покупки лицензий, аппаратного комплекса клиент получает от сопровождающего его 1С франчайзи. Далее проходит консультация с нами, мы предлагаем альтернативное решение на связке 1С+Linux+Postgres SQL, сами же и внедряем.

Предложение на 20 пользователей.

Пояснения и нюансы:

1. Внедренцы 1С (во вселенной конечно же есть и другие, которые пытаются сэкономить клиенту, но нам такие не попадались) по умолчанию предлагают ключи варианта USB, они ощутимо дороже файловых лицензий. Естественно, выбор типа ключа никак не зависит от платформы реализации. Выходит в таблице сделано ухищрение в пользу Linux платформы. Все же напомню, что речь идет не о скрупулезной оценке предложений, а о свежем примере из практики. Объективности ради, должен уточнить, что на мой взгляд внедренцы склоняются в пользу USB ключей не в целях увеличить траты, а ради надежности применения и простоты дальнейшего обслуживания, «тем более» если речь идет о реализации на Linux + Postgres SQL.
2. Часто, мы также для небольших компаний приобретаем ключ 1С: Предприятия x86, а не 64. При этом Postgres SQL используем 64 битный вариант, а 1С сервер предприятия 32 битный. Применение в масштабах организаций до 60 человек, считаем приемлемым, тезис субъективный.
3. Не учтена стоимость работ. В нашем случае она включена в контракт обслуживания, потому для клиента равна нулю. Будем считать что внедрение и дальнейшее сопровождение, примерно одинаковы.

Задача №2 + бонус от 1С

Осуществить переход базы с файлового режима работы на SQL-ный вариант с возможностью использования до 10 клиентов.

Предложение на 10 пользователей

Дополнение к нюансам из примера №1

• Добрая 1С позволяет использовать 1С сервер предприятия на Linux для 12 клиентов без ключа сервера предприятия, для Windows подобного нет. Бонус сомнительный, ведь 10 пользователей смогут и на файловой пережить, но все же приятный.

Итог.

Часто, экономия в рамках нашей страны губит любые добрые системные начинания. Мне кажется, что данный случай все же из другого разряда. Три года назад когда мы вводили 1С сервер предприятия на Linux за стандарт для наших компаний, мы действительно без ложной озабоченности выслушивали от внедренцев 1С, что они снимают с себя ответственность за работоспособность поддерживаемой конфигурации на подобной не «кошерной» связке Linux + Postgres SQL, при этом вводя и клиента в состояние паники.
Возможно, в приведенные мною расчеты можно пульнуть еще с десяток критических стрел, на объективность претендовать сложно, но хотелось донести общее представление финансовой составляющей вопроса.

UPD. from Thug21
клиентские программные и аппаратные лицензии расходуются по разному в клиент-серверном режиме.
-Программные расходуются на каждое подключение
-Аппаратные на компьютер.
UPD от [email protected]
техническая возможность работать без ключа не ознячает юридического разрешения это делать. Закон о правовой защите информации для ЭВМ запрещает использовать любые программные продуктыв, правообладатель которых не декларирует их бесплатность (а мы нигде не объявляли этот сервер бесплатным).
С уважением, менеджер отдела продаж Виктор Быков
Убедительная просьба сохранять историю переписки при дальнейших обращениях.

Платформа «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С, любой владелец хотел бы избежать «родовых травм» - заложенных в него потенциально узких мест. С другой стороны, сегодня мало кто покупает серверы избыточной мощности, «на вырост». Хорошо если профиль нагрузки удается снять заранее - тогда и проектировать сервер под конкретную конфигурацию приложений компании проще.

Для определенности, рассмотрим платформу «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) в одиночку справляются с такими нагрузками:

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

• узким местом и для 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» для малого офиса

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

Кому следует задуматься, нужно ли ему покупать сервер?

Вначале давайте опишем условия, когда сервер под «1С:Предприятие 8» не является необходимостью.
Это, как правило, организации, максимально близко подходящие под два критерия:
а) небольшая организация на 1-5 пользователей,
б) Для поддержки бизнес-процессов компании вполне достаточно возможностей типового решения от 1С (т.е. нет необходимости делать доработки типовой конфигурации, максимум изменения некоторых печатных форм, отчетов и обработок).
По статистике, в зависимости от региона, организаций, использующих типовые конфигурации от 1С, может быть до 60-80%.
Если компания удовлетворяет перечисленным выше критериям, то, возможно, вместо покупки набора, состоящего из:
- «1С:Предприятие 8»,
- Windows Server и клиентских лицензий,
- аппаратного сервера,
- услуг по настройке оборудования и ПО,
- поддержки и обслуживания данного комплекса,
имеет смысл рассмотреть возможность аренды «1С:Предприятие 8» у сервис-провайдера в формате «Программное обеспечение как Сервис» (SaaS).
Сервис-провайдеры подобных услуг предлагают полнофункциональные типовые конфигурации «1С:Предприятие 8», представленные в виде удаленного Web-сайта. Печать документов выполняется на свой локальный принтер, сохранять документы в электронном виде также можно на свой локальный компьютер. Конечно, предусмотрена возможность в любой момент выполнить сохранение локальной резервной копии своей базы данных 1С. Причем располагать резервную копию можно и на диске компьютера, и на съемном накопителе USB, и где-то на удаленном «облачном» диске (таком, как DropBox или Яндекс.Диск).
Арендовать одну из типовых конфигураций «1С:Предприятие 8» можно у самой компании 1С на ресурсе 1cFresh.com , а также у ее партнеров, например 1С:Бухобслуживание .
Из технологических удобств - это работа везде, где есть Интернет и практически с любого устройства, в том числе с планшета и даже смартфона, отсутствие необходимости в привлечении IT-специалиста. Из финансовых преимуществ - организация вместо аккумуляции средств, инвестирования в покупку физического сервера, операционной системы Windows Server и самого ПО «1С:Предприятие 8», организация просто оплачивает доступ к «1С:Предприятие 8» как к услуге, сразу списывая затраты на текущие расходы. По сути - как за коммунальную услугу. Если понадобилось увеличить или уменьшить количество сотрудников - это можно сделать практически моментально, тем самым гибко управляя своими затратами в зависимости от текущих потребностей. А работать в таком сервисе смогут и сотни пользователей одновременно.

«Сдаем анализы», или что желательно зафиксировать на текущем оборудовании?

Если у вас уже имеется в эксплуатации сервер с «1С:Предприятие 8», идеальным вариантом было бы запустить стандартную утилиту Windows - Performance Monitor (Perfmon), и записать данные о нагрузке за одни рабочие сутки. Это будет отправной точкой, которая позволит затем сравнить, насколько эффективнее новый сервер, и стоит ли он потраченных денег.
С помощью Perfmon достаточно снять нагрузку на процессор (CPU) в виде % загрузки по ядрам, оперативную память (RAM) в % использования, и физические (а не логические) диски: на которых расположены 1С и OS Windows (это может быть один, но обычно это различные диски). По нагрузке на диск самые важные параметры:
- “Avg. Disk sec/Transfer” (среднее время обращения к диску) - идеально до 10 мс (миллисекунд), хорошо до 25 мс, предельное значение для комфортной работы 40 мс;
- “Current Disk Queue Length” (текущая длина очереди диска) - идеально наличие узких пиков (на графике) и как можно меньшее значение очереди, длины очереди в 70-100 запросов и более, график в виде «горки» говорит о недостаточной производительности дисковой подсистемы;
- “Disk Transfers/sec” (обращение к диску/сек) - здесь важно зафиксировать предельные цифры и их длительность, как правило, это от 80 IOPS и до нескольких сотен, а то и тысяч.
Имея эту информацию, будет проще сформулировать требования к аппаратным подсистемам сервера для поставщика оборудования, и затем сверить их с расчётными значениями.

Методология расчета оборудования

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

Далее рассмотрим методологию расчета требуемых ресурсов для «1С:Предприятие 8» в зависимости от:
- используемой версии - файловая или SQL,
- типа доступа - по локальной сети, через удаленный рабочий стол “Remote Desktop”, или Web-/тонкий клиент,
- количества пользователей,
- количества и объема баз данных,
- иных задач, возложенных на сервер.
Представленный подход относительно универсальный, и одинаково подходит и для запуска «1С:Предприятие 8» на физическом сервере (с включённым Intel Hyper-Threading), и для запуска на виртуализированном сервере с Microsoft Hyper-V или VMware vSphere, и для расчета арендованных ресурсов у облачных сервис-провайдеров.

Для наглядности расчетов мы возьмем три достаточно типичных примера :
а) 5 пользователей «1С:Предприятие 8», файловая версия , пользователи подключенные по локальной сети (ЛВС) через «толстый» клиент 1С. В таком режиме сервер выполняет только роль файл-сервера, а вся вычислительная нагрузка ложится на рабочие места пользователей.
б) 10 пользователей , база данных SQL , запущен «1С:Предприятие 8. Сервер приложений », пользователи работают через «толстый» клиент по ЛВС, база данных объемом в 4 ГБ, за 2 года. Сервер выполняет роль хранилища данных, SQL-сервера, «Сервера приложений 1С».
в) 20 пользователей , база данных SQL , запущен «1С:Предприятие 8. Сервер приложений », пользователи работают в режиме «Удалённого рабочего стола » (RDP), одна конфигурация, база данных размером 9 ГБ за 3 года. Сервер выполняет роль хранилища данных, SQL-сервера, «Сервера приложений 1С», сервера терминалов.

Расчет потребностей в процессорной мощности (CPU ) : Для начала необходимо подсчитать, какое количество «ядер» процессора нам необходимо. Расчет будем вести в «логических ядрах CPU», где одно логическое ядро соответствует на физическом сервере одному ядру в «Диспетчере задач» при включенном Hyper-Threading (т.е. каждое физическое ядро процессора представлено как два логических).
- Под нужды операционной системы (OS) резервируем 1-2 ядра, для SQL-версии обычно достаточно одного, для файловой - лучше два.
- Если используется SQL-версия, то одно ядро на 20-25 пользователей «1С:Предприятие 8» под нужды MS SQL (больше пользователей - больше ядер);
- Также для SQL-версии резервируем одно ядро под нужды «1С:Предприятие 8. Сервер приложений х64» (процесс rphost) на 15-20 пользователей (больше пользователей - больше процессов rphost, больше ядер);
- В варианте работы пользователей в режиме «Удалённого рабочего стола» (Remote Desktop) - резервируем одно логическое ядро на 8 терминальных пользователей (больше пользователей - больше ядер).
- Для работы в режиме Web-сервиса через браузер или «Тонкий клиент» - также резервируем одно логическое ядро на 8 удаленных пользователей. На самом деле для конфигураций на «Управляемых формах» нагрузка смещается на «1С:Предприятие 8. Сервер приложений х64», а в случае Web-сервиса она еще добавляется и по Web-серверу Internet Information Server (IIS), но для расчетов нам это не важно.

Примеры расчета :
а) для 5 пользователей в файловой версии, подключенных по локальной сети через «толстый» клиент необходимо 2 логических ядра под OS (выполняющую в том числе роль файлового сервера) - итого одно физическое ядро процессора;
б) для 10 пользователей в SQL и через «толстый» клиент необходимо одно ядро под OS, одно ядро под MS SQL Server, одно ядро под «1С:Предприятие 8. Сервер приложений х64» (rphost) - итого 3 логических ядра, или 2 физических;
в) для 20 пользователей в SQL и в режиме «Удалённого рабочего стола» необходимо одно ядро под OS, одно ядро под MS SQL Server, одно ядро под «1С:Предприятие 8. Сервер приложений х64» (rphost), 2,5 ядра на обслуживание терминальных сессий пользователей (20:8) - итого 5,5 логических ядра, или 3 физических.
Сервер с самым младшим процессором Intel Xeon E3 12хx содержит 4 физических ядра, или 8 логических. Таким образом, даже минимальный вариант серверного процессора по ядрам вполне покрывает потребности небольшой организации в 25 пользователей «1С:Предприятие 8». А, к примеру, однопроцессорный сервер на основании более мощного Intel Xeon E5 16хx , содержащего 8 физических, или 16 логических ядер, вполне может справиться с нагрузкой в 50-75 пользователей «1С:Предприятие 8» в режиме «Удалённого рабочего стола» или Web-сервиса/«Тонкого клиента».

При этом одной из важнейших характеристик для процессора является его штатная частота (не путать с Turbo Boost), о чем подробнее поговорим чуть ниже. Если говорить упрощенно - комфорт работы пользователей с «1С:Предприятие 8» в режиме SQL, и особенно при работе через «Удаленный рабочий стол» (RDP) почти линейно растет с частотой процессора.

Расчет потребностей в оперативной памяти (RAM ) : Как и при расчете потребности в процессорных ядрах, наша задача - аккуратно учесть потребности всех сервисов.
- Под нужны операционной системы (OS) резервируем 4 ГБ;
- Если используется SQL-версия, то, как минимум, необходимо разместить в SQL RAM Cache 20-30% объема таблиц базы данных (DB). Если баз данных несколько - то 20-30% от объема таблиц данных каждой из баз данных. Либо же, как критерий расчета потребностей SQL RAM Cache, можно использовать объем данных за 1 год. Так как у небольших организаций обычно и базы данных 1С не слишком большие, то очень часто в SQL RAM Cache можно поместить всю базу данных, т.е. 100% объема таблиц базы данных (это идеальный вариант). Минимальный объем - от 2 ГБ.
- Под нужды «1С:Предприятие 8. Сервер приложений х64» объем RAM рассчитывается исходя из количества запущенных процессов rphost, где-то по 1 ГБ на каждый rphost. Обычно это 1-2 ГБ для 10-25 пользователей.
- При работе пользователей в режиме «Удалённого рабочего стола» (Remote Desktop) всё несколько сложнее. В первую очередь необходимо уточнить используемые конфигурации, а еще лучше физически посмотреть, сколько каждая из конфигураций потребляет RAM на одного пользователя в режиме работы по локальной сети или в терминальном режиме. Причем смотреть нужно не сразу после старта, а где-то через 20-30 мин интенсивной работы. Для примера, «Бухгалтерский учет» в среднем потребляет 250-300 МБ RAM на каждую запущенную сессию, «Управление торговлей» в среднем потребляет 300-350 МБ RAM на каждую запущенную сессию. Далее подсчитываем, сколько пользователей будет одновременно использовать каждую конфигурацию, умножаем их количество на необходимый объем RAM для конфигурации «1С:Предприятие 8», и суммируем по конфигурациям для получения общего объема. Как правило, для одной конфигурации и 10 пользователей это 3-4 ГБ RAM.
- В режиме «Удалённого рабочего стола» (Remote Desktop) также необходимо учитывать и другую вероятную нагрузку. К примеру, из 1С очень часто делается выгрузка в формат MS Excel для дальнейшей обработки печатных форм или отчетов. Или пользователям открывают доступ к использованию Интернет, других приложений MS Office и прочих программ. Соответственно, необходимо посчитать потребляемые ими ресурсы RAM. Для MS Word и MS Excel это приблизительно по 100 МБ, для MS Outlook порядка 150 МБ, Internet Explorer порядка 200 МБ на каждый запущенный экземпляр у каждого пользователя. По иным программам оптимально посмотреть их реальное потребление RAM на ПК и точно так же учесть.
- Для работы в режиме Web-сервиса через браузер или «Тонкий клиент» рассчитать потребление RAM можно по тем же принципам, как и для различных конфигураций «1С:Предприятие 8» в режиме «Удалённого рабочего стола», подсчитав пользователей каждой из конфирмаций, умножив на соответствующее потребление RAM в режиме «толстого клиента», и просуммировав. Эти дополнительные ресурсы на самом деле пойдут «1С:Предприятие 8. Сервер приложений х64» и IIS, но для предварительных расчетов вполне подходит.
Примеры расчета :
а) для 5 пользователей в файловой версии, подключенных по локальной сети через «толстый» клиент минимально необходимо 4 ГБ RAM под OS, а лучше 8 ГБ RAM;
б) для 10 пользователей в SQL и через «толстый» клиент с базой данных в 4 ГБ за 2 года необходимо 4 ГБ под OS, 1 ГБ (это 25% объема) или 2 ГБ (данные за год) под MS SQL Server, а лучше 4 ГБ, чтобы все 100% БД помещалось в RAM, 1 ГБ под «1С:Предприятие 8. Сервер приложений х64» (один поток rphost), итого от 6 ГБ до 9 ГБ RAM;
в) для 20 пользователей «Управления торговлей» в SQL с базой данных в 9 ГБ за 3 года и в режиме «Удалённого рабочего стола» необходимо 4 ГБ под OS, 3 ГБ под MS SQL Server (а лучше 9 ГБ, чтобы все 100% БД помещалось в RAM), 1-2 ГБ под «1С:Предприятие 8. Сервер приложений х64» (1-2 потока rphost), 6-7 ГБ на обслуживание терминальных сессий пользователей, итого от 14 ГБ до 22 ГБ RAM.
После подсчета необходимого объема RAM правильно добавить 20-30% запаса на рост нагрузки (увеличения числа пользователей, к примеру, или рост БД). Благо, RAM нынче стоит недорого, а современные процессоры ее поддерживают много - Intel Xeon E3 16xx до 64 ГБ RAM, а Intel Xeon E5 16xx до 1540 ГБ RAM. В сервере много оперативной памяти не бывает;-).

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

Дисковая подсистема состоит из двух компонентов:
- подсистема ввода/вывода в виде контроллеров вода/вывода (HBA) и RAID-контроллеров;
- устройства хранения данных, или в нашем случае - дисков SSD и HDD.

Подсистема ввода/вывода ( RAID ).
Так как мы обсуждаем сервер, задача которого надежно хранить информацию, абсолютно необходимым является резервирование аппаратных ресурсов для хранения данных, т.е. дисков.
Для небольших предприятий, как правило, используется RAID1, или «зеркало», когда данные записываются на два диска одновременно. В таком режиме, даже если один из дисков физически выходит из строя, данные сохраняются.
Есть сразу несколько вариантов построения RAID 1 в небольшом сервере.

1. К примеру, может быть создан полностью программный RAID (Soft RAID) средствами Windows Server. Этот вариант для системного диска, на котором находится операционная система (OS), не применим. Для диска с базой данных - можно попробовать, используя технологию Windows Storage Spaces. В реальной жизни применяется крайне редко, рекомендовать не будем.

2. Можно использовать аппаратно-программный, построенный на основе чипсета от Intel и технологии Intel® Rapid Storage Technology (Intel RST ). Суть его в том, что все операции по вводу-выводу на аппаратном уровне выполняет чипсет материнской платы, практически не загружая ресурсы CPU. А вот управление этим массивом осуществляется на программном уровне, за счет драйверов под Windows.
Это самый распространенный , и на данный момент самый высокопроизводительный вариант построения RAID1 для не очень нагруженного сервера на 2 или 4 диска.
Правда, как любое компромиссное решение, у него есть некоторое недостатки.
а) Его работа зависит от драйверов, загружаемых в операционную систему. А это несет некоторый потенциальный риск, что при обновлении драйверов или OS может возникнуть ситуация, что диск RAID будет недоступен. Она чрезвычайно маловероятна, т.к. компании Intel и Microsoft весьма дружны и очень качественно тестируют свое ПО, но не исключена. Справедливости ради нужно отметить, что за последние лет 8 автор со случаями подобных сбоев не сталкивался.
б) Исходя из результатов экспериментов в тестовой лаборатории компании Entry, по косвенным признакам можно предположить, что драйверная модель Intel RST для кэширования на запись использует ресурсы RAM. Это дает прирост производительности, но при этом несет некоторые риски потери данных при незапланированном отключении электропитания сервера. В предыдущей «реинкарнации» этой технологии, Intel Matrix RAID, на уровне команд кэширование на запись можно было явно отключить. В современной версии Intel RST как-либо повлиять на этот параметр, или даже узнать его состояние, у пользователя возможности нет. Купируется этот вопрос просто - установкой относительно «умного» источника бесперебойного питания (Smart UPS), который умеет отслеживать состояние своих батарей и при их разряде дает команду на выключение сервера. По сути, ИБП к серверу в любом случае необходимо ставить, так что это не является проблемой, главное не полениться выполнить настройки. Есть некоторый вопрос с переносимостью в случае выхода из строя материнской платы. В гарантийный период этот вопрос наверняка сможет закрыть поставщик оборудования, а вот в пост-гарантийный может потребоваться поиск аналогичной материнской платы.
Стоимость такого решения в большинстве случаев уже включена в стоимость материнской платы и, по сути, пользователю достается «бесплатно».

3. Среди IT специалистов достаточно распространено желание иметь в сервере полностью аппаратный RAID. Удачным примером такого решения является использование SAS-контролера (SAS HBA) в режиме RAID1. К примеру, LSI HBA 9211 и его последователей. Для этого в SAS HBA устанавливается специальная прошивка BIOS, у LSI 9211 это “IR”-прошивка. Преимущества по производительности такая схема не несет. Теоретически, в случае выхода из строя материнской платы можно диски и контроллер оперативно подключить к другому серверу… но ведь с такой же вероятностью как материнская плата может сгореть и SAS-контроллер, так что с точки зрения автора преимущество это несколько призрачное, решающее больше проблемы психологические, чем технологические.
Стоимость LSI HBA 9211 находится на уровне $250-300, что заметно дороже предыдущего варианта на Intel RST. Такой прирост цены для бюджетного решения довольно существенный. С точки зрения автора, если уж есть желание сделать «аппаратный» RAID, то лучше выбрать чуть более дорогое решение на Intel® RAID Controller RS3WC080 . Данный SAS HBA также построен на чипе LSI, но уже следующего поколения, LSI SAS 3008, поддерживает стандарт SAS 3.0 (12-Gb/s), при цене около $300.

4. Иногда, в случае недобросовестности или недостаточной квалификации продавца, в серверы под 1С пытаются продавать недорогие RAID-контроллеры устаревших моделей. Например, Adaptec 6405E . Недостаток таких контроллеров в том, что встроенный в них чип по своей производительности рассчитан на поддержку некоторого количества HDD, и плохо справляется даже с нагрузкой в виде двух серверных SSD младших моделей. К примеру, современные SSD легко могут выдать на чтение 80 000 IOPS (обращений в секунду) каждый, а процессор RAID-контроллера, допустим, способен обработать всего 60 000 IOPS… Также при использовании RAID1 и SSD нет необходимости в кэше на запись на контроллере - запись что в RAM-кэш на контроллере, что напрямую в SSD происходит практически с одинаковой скоростью, как и чтение. Более того, современные RAID-контроллеры, даже имея по 1 ГБ RAM Cache на борту, при работе с SSD его не используют. Это не значит, что Adaptec 6405E плохой контроллер, просто данный инструмент предназначен для другого использования.
Стоимость Adaptec 6405E - порядка $250.

В качестве краткого завершения предлагаю посмотреть на график тестирования четырех SSD в RAID10 в трех вариантах построения RAID: Adaptec 6405E, LSI 9211, Intel RST (тестовая лаборатория Entry). Хорошо видно, что наиболее производительным получается вариант с Intel RST, наименее производительный - с Adaptec 6405E.

Устройства хранения данных ( SSD и HDD )

«1С:Предприятие 8» в своей работе кроме собственно места расположения таблиц Базы данных (папка для файловой версии, таблицы DB для версии SQL), может использовать системный диск “С:\”. Например, системную папку Tmp операционной системы Windows для хранения временных файлов. С ней может работать SQL версия - в частности хранить там tempDB. В режиме «Удалённого рабочего стола» может использоваться локальные tmp директории терминальных пользователей на сервере, которые также обычно находятся на диске “C:\”, в локальных профилях пользователей.
- Под нужны операционной системы (OS) резервируем не менее 120 ГБ;
- Для хранения базы данных в файловой версии желательно просто посмотреть объем папок, в которых хранятся базы данных. Обычно это до 1-2 ГБ, а то и 10-20 ГБ.
- Если используется SQL-версия, то у нас есть три типа данных - сами таблицы базы данных (DB), временные таблицы (tempDB) и SQL log. По умолчанию tempDB будут расположены на системном диске “C:\”. Он для небольших баз данных, как правило, маленький, порядка 100-300 МБ. Таблицы базы данных (DB) - как и писалось выше, редко превышают объем 10-20 ГБ для компаний в 5-25 пользователей, но здесь в первую очередь надо смотреть текущий объем плюс прирост за год. SQL log может быть очень большим, до десятков ГБ, особенно когда включен режим “Full SQL log”, но он же может быть безболезненно «обрезан» в конце каждого месяца и архивирован (или удален, если не нужен).
Итого, под нужды баз данных «1С:Предприятие 8» выходим на емкости 20-60 ГБ, что на самом деле меньше самых маленьких серверных дисков что HDD, что SSD.
- В варианте работы пользователей в режиме «Удалённого рабочего стола» (Remote Desktop) имеет смысл учесть по 3-4 ГБ RAM в личных папках пользователей под хранение различных файлов загрузки или выгрузки/данных в/из 1С. Если же сервер используется еще и как файловое хранилище - это нужно рассчитывать совершенно отдельно от потребностей для 1С, и желательно на других физических дисках.

Что нужно еще учесть для проектирования относительно подбора дисков.
1. Очень желательно разнести Операционную систему (OS) и данные 1С (таблицы данных) на различные физические устройства с точки зрения отказоустойчивости. Но если бюджет маленький - ну что ж, пусть все будет на одном хранилище, с подстраховкой за счет RAID и ежедневных Backup на внешний носитель (или сервис).
2. Не забываем, что для сервера обязательным является резервирование дисков и построение из них отказоустойчивого RAID1 (RAID5 и его аналоги для баз данных не применяются), т.е. нам нужно, как минимум, два одинаковых диска (если OS и база данных совмещены), либо дважды по два одинаковых диска для двух массивов RAID1 (если OS и База данных разнесены).

Примеры расчета :
а) для 5 пользователей в файловой версии, подключенных по локальной сети через «толстый» клиент минимально необходимо 120 ГБ под OS, а лучше 240 ГБ, и 10-20 ГБ под данные. По сути, с такой нагрузкой справится дисковая подсистема из двух дисков Intel SSD s3510 series на 240 ГБ в режиме RAID1.
б) для 10 пользователей в SQL и через «толстый» клиент с базой данных в 4 ГБ также технически будет достаточно дисковой подсистемы из двух дисков вроде Intel SSD s3510 series на 240 ГБ в режиме RAID1. Но, с учетом количества пользователей, уже имеет смысл рассмотреть разнесение на два раздельных тома - два диска в RAID1 по 120-240 ГБ под OS и два диска в RAID1 по 80 ГБ под Базу данных.
в) для 20 пользователей «Управления торговлей» в SQL с базой данных в 9 ГБ также технически будет достаточно дисковой подсистемы из двух дисков вроде Intel SSD s3500 series на 240 ГБ в режиме RAID1. Тем не менее, с учетом количества пользователей, настоятельно рекомендуется разнесение на два раздельных тома ОС и Базу данных - два диска в RAID1 по 120-240 ГБ под OS и два диска в RAID1 по 80-120 ГБ под базу данных.

Хотелось бы напомнить о «принципе разумной достаточности».
Как правило, объем баз данных у небольших компаний на 5-25 пользователей «1С:Предприятие 8» также небольшой. И тут очень важно не гнаться за объемом диска, он вам банально не нужен. Зато имеет смысл выбрать максимально надежный и производительный диск, пусть и меньшей емкости. Типичной ошибкой покупателей является желание «купить диск побольше, дёшево же», что приводит к использованию более дешевых и емких не серверных дисков, что с технической точки зрения недопустимо.

Обход узких мест

Сетевой интерфейс . С наименьшей вероятностью при работе с «1С:Предприятие 8» узким местом может оказаться сетевой интерфейс, т.к. большого объема данных не передается, то и особых требований для 5-25 пользователей нет. Тем более на большинстве серверов установлено сразу две сетевые карты Ethernet 1 Гбит/с, но тут имеются нюансы.
Сетевые карты бывают разные. Одни - предназначены для работы в ПК и ноутбуках, и в них существенная часть нагрузки ложится на CPU. К таким относятся, например, сетевые интерфейсы на чипе Realtek RTL8201N. Такие чипы используются и в серверах, но на специальных портах, предназначенных для управления сервером.
В то же время существуют серверные сетевые чипсеты, например Intel® i350-AM2 Dual Port Gigabit Ethernet. У них большая часть обработки происходит на самом чипе, без привлечения ресурсов CPU, что и быстрее, и эффективнее.
Собственно, рекомендации просты:
- не покупать ПК «а-ля сервер», т.к. скорее всего у него стоит сетевая карта Ethernet для ПК;
- если у сервера несколько портов Ethernet, не использовать для рабочей нагрузки порт, предназначенный для управления.

RAM . Здесь всё просто. Как посчитать - описано выше. Оперативная память нынче стоит недорого. Потому посчитать, взять запас 20-50%, а можно и больше - и закрыть вопрос. Если ожидается существенный рост нагрузки в ближайшие год-два - проконтролировать, чтобы в сервере оставались свободные слоты для установки дополнительных модулей памяти.

CPU . После расчета количества необходимых физических ядер, остается вопрос с частотой.
И это очень важный вопрос.
1. Если ядер хватает, то производительность клиентской части, Сервера приложений «1С:Предприятие 8», а во многих ситуациях и SQL-сервера, напрямую зависит от частоты процессора. Причем - практически линейно. Очень многие отчеты, к примеру, при увеличении частоты процессора в 1,5 раза ровно во столько же раз выполняются быстрее.
Поэтому при прочих равных условиях имеет смысл отдавать предпочтение более высокочастотным процессорам.
2. Следующий момент - это не попасться на маркетинговую уловку некоторых продавцов, выдающих частоту процессора в режиме Turbo Boost за частоту процессора. Да, технология Intel® Turbo Boost Technology 2.0 довольно интересная штука, и в реалиях 1С, когда работает всего один поток (проведение документов или формирование сложного отчета) он позволяет поднять производительность одного ядра на 15-30%, а то и больше. Но нужно помнить, что в реальности в серверном чипе частота поднимется на краткий промежуток времени, на 30 сек, иногда на одну мин, а затем снижается до штатной. В итоге выигрыш - очень краткосрочный. А высокочастотный процессор всегда работает на высокой частоте, а значит быстрее. Поэтому он и стоит дороже.
Пример - ниже в таблице:

Табл. 1

3. Для малых предприятий на 3-10 пользователей иногда предлагают купить не сервер на Intel Xeon E3, а «мощный ПК» на Core-i7, ссылаясь на его большую производительность и надежность.
Но нужно учитывать следующие моменты.
а) Процессор Intel Xeon E3 и Core-i7 на самом деле в аппаратном плане близнецы-братья, и даже стоят одинаково. А вот внутренняя прошивка, отвечающая за расстановку приоритетов - разная. Очень упрощенно - у Xeon E3 приоритетом обладают операции ввода/вывода и другие серверные операции, а у Core-i7, заточенного под игровой сегмент и обработку видеопотоков - в приоритете обслуживание видеокарты. Цена же, еще раз подчеркну - одинаковая (при одинаковых параметрах).
б) Есть большая разница между десктопной и серверной материнской платой. Десктопная рассчитана работать 8 часов в день, 5 дней в неделю, два или три года. Соответственно, компоненты для нее выбираются, чтобы выдержать именно заложенные сроки эксплуатации. Серверные материнские платы рассчитаны работать 24 часа в сутки, 365 дней в году три или пять лет. И компоненты там несколько иные. А вот разница в цене - опять-таки минимальна, зачастую на уровне $10-20.
в) В «продвинутом» ПК с высокой долей вероятности сетевая карта будет стоять отнюдь не серверная.
Имеет ли смысл вместо сервера как специализированного устройства с заданными параметрами эксплуатации пытаться покупать некий «навороченный ПК» на роль сервера, да еще и не факт что дешевле - каждый теперь может сделать осознанный выбор.

Диски . Это, наверное, самая больная тема на момент написания статьи.
К сожалению, все еще есть и пользователи, и продавцы, слегка застрявшие в прошлом веке. И абсолютно уверенные, что HDD SAS 15 000 rpm - это пример надежности и производительности.
На самом деле это давно уже не так.

а) Для начала давайте разберемся с надежностью SSD и HDD.
Чаще всего теоретическую надежность дисков оценивают по параметру «Non-recoverable Read Errors per Bits Read», что можно перевести «Вероятность появления невосстановимой ошибки чтения на количество считанных бит». Он показывает, какой объем данных нужно считать с диска, чтобы появилась высокая вероятность появления невосстановимой ошибки.
Еще одни важный параметр, показывающий вероятность отказа диска - AFR (annual failure rate), или «Годовая интенсивность отказов».
Далее в таблице приведены данные для типовых дисков SATA Desktop HDD 7200 prm , SATA Enterprise HDD 7200 prm (SATA Raid Edition) , SAS HDD Enterprise 15 000 prm , SATA SSD Enterprise (данные взяты из официальных документов производителей, можно проверить цифры по ссылкам).

Как хорошо видно из таблицы, по параметру «Годовая интенсивность отказа» диск для применения в обычном ПК в среднем в два раза менее надежен, чем серверный.
По поводу вероятности появления невосстановимых ошибок теория нам явно говорит, что у Enterprise SATA SSD, в качестве примера которого был взят Intel® SSD DC S3510 Series , в 10 раз ниже вероятность ошибки, чем у SAS HDD Enterprise 15 000 rpm, в 100 раз ниже, чем у SATA Enterprise HDD 7200 rpm, и в 1000 раз ниже, чем у SATA Desktop HDD 7200 rpm.
При этом цена SATA Desktop HDD 7200 rpm и Enterprise SATA SSD за объем, достаточный и для размещения и операционной системы, и баз данных 1С, отличается отнюдь не в 1000 раз, и даже не в 10.
Отдельно обращу внимание на «Объем, при чтении которого статистически ожидается невосстановимая ошибка». Для SATA Desktop HDD этот показатель 12,5 ТБ. А уже есть диски и на 8 ТБ, и на 10 ТБ… таким образом, поставив, к примеру, 8 ТБ десктопный диск, записав его и прочитав два раза, мы по теории столкнемся как минимум с одной невосстановимой ошибкой!

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

б) Далее оценим производительность SSD и HDD.
С точки зрения баз данных, которой, по сути, является 1С, наиболее важными являются всего три параметра диска
- латентность (Latency), или время отклика диска, измеряется в микросекундах (меньше - лучше);
- количество операций чтения в секунду (Disk Reads/sec) , измеряемой в IOPS (больше - лучше);
- количество операций записи в секунду (Disk Writes/sec), измеряемой в IOPS (больше - лучше).
Давайте сведем эти три параметра в одну таблицу для тех же самых дисков, что и в примере про надежность.

Как хорошо заметно из таблицы, SSD по параметру время отклика превосходит HDD в 40-80 раз , а по количеству операций ввода-вывода в секунду в 100-400 раз (!!!).
При этом, если подходить к выбору разумно, и покупать только ту емкость хранения, которая реально востребована - то разница в стоимости Enterprise SATA SSD и Enterprise SATA \ SAS NL HDD окажется очень незначительной.
Разумно ли при этом использовать для размещения баз данных HDD? С точки зрения автора - только если Вы купили на склад неликвид, вам очень надо его продать, и дальнейшие взаимоотношения с покупателем вас мало волнуют. Потому как и соотношение цена/производительность, и цена/надежность явно в пользу Enterprise SSD.

А теперь самое время вернуться к тому моменту, когда были измерены реальные показатели нагрузки на дисковую подсистему (если их удалость сделать).
Если говорить о «средней температуре по больнице», то приблизительные пиковые нагрузки по IOPS могут быть такими (количество пользователей, объем БД 1С; в нижней строке Disk Transfers/sec)

Зная количество пользователей и объем баз данных 1С, вполне можно приблизительно оценить потребность дисковой подсистемы в IOPS по Disk Transfers/sec (=Disk Reads/sec + Disk Writes/sec), либо же взять свои реальные измерения, и сформулировать требования к вашей дисковой подсистеме в операциях ввода/вывода в секунду (IOPS). И вооружившись цифрами выбрать те диски, которые им будут удовлетворять.

в) И чтобы закрыть вопрос, какие именно SSD необходимо ставить, давайте разберемся, чем отличаются Enterprise SATA SSD и обычные десктопные SATA SSD .
1. Производительность скорости чтения данных в IOPS что десктопные, что серверные диски будут показывать очень похожую. А вот производительность скорости записи данных будет существенно отличаться, и с ростом заполнения пространства на диске у десктопных SSD она будет быстро деградировать. Да, в спецификациях на десктопные диски можно увидеть очень высокие показатели в IOPS на запись… при 5-8% заполнении диска данными. А при 100% - их даже не приводят, и неспроста - эти показатели часто не отличаются от таковых у HDD. Для серверных SSD тестирование производительности на запись выполняется как раз при 100% заполнении данными, и её величина - это, как правило, или усреднённый, или один из худших результатов. Вывод - не обращайте внимания на красивые и большие числа в спецификациях производителей для десктопных SSD, это маркетинг. Для сервера необходимо выбирать пусть самую младшую, но Enterprise модель SSD. Например, такие как Intel® SSD DC S3510 Series.
2. Следующий важный параметр, который хорошо демонстрирует кардинальные различия между серверными и десктопными SSD - гарантированный ресурс перезаписи . Большинство десктопных SSD нормально переносят перезапись до 0,1% своей емкости в день (без существенной деградации производительности и выхода из строя) все те же 7 дней в неделю 2-3 года, при не полном заполнении. Серверный диск рассчитан на перезапись 0,3% своего объема каждый день в течении 3-5 лет даже при полном заполнении.
Пункты 1 и 2 объясняются очень просто. В SSD записываются данные в ячейки по 4 КБ, а вот стираются… минимум блоками по 256 ячеек и более. А до стирания всего блока они просто помечаются как готовые к стиранию. Чтобы записать на место старых данных новые - старые необходимо стереть. Чтобы стереть даже одну ячейку в 4 КБ надо вначале все данные из столбца в 256 ячеек перенести в другое место, стереть весь столбец, и вернуть данные на место. Это - небыстрая операция.
Борются с этой ситуацией путем размещения на диске SSD скрытой области, которая не доступна для пользователя, и используется как раз для подмены ячеек, когда есть необходимость «собрать мусор», т.е. очистить неиспользуемые блоки. Такая область называется Over Provisioning, или «Резервная область». Так вот, у десктопных SSD она составляет обычно 4-8% от общей емкости микросхем flash-памяти на диске, а у серверных… достигает 42% от физической ёмкости микросхем . Если же проводить пример, то при условии, что в устройстве будет распаяно микросхем на 320 ГБ, то ёмкость «десктопный» SSD будет 300 ГБ, а в случае серверного пользователю будет доступно всего 180 ГБ. На самом деле все намного сложнее, в серверных дисках применяется еще масса технологий для повышения его «живучести» и обеспечения стабильной производительности, но для общего понимания разницы пример с «Резервной областью» вполне показателен.
3. Еще одно важное отличие серверных и десктопных SSD относится к сфере обеспечения сохранности данных. В любом SSD есть своя энергозависимая RAM, которая используется в т.ч. для операций чтения и записи. В десктопных SSD могут сложиться обстоятельства, когда данные записаны в RAM на SSD, файловая система и SQL-сервер получили подтверждение записи, а на самом деле данные еще не находятся в энергонезависимой памяти. Если в этот момент произойдет сбой по питанию - то очень высока вероятность потери данных, и восстановить, что потеряно, а что нет - очень сложно.
В то же время в серверных SSD имеется суперконденсатор , емкости которого достаточно для записи в энергонезависимую память SSD всех данных, находящихся в RAM внутри SSD. Таким образом, вероятность потери данных при сбое по питанию очень существенно снижается.
И опять-таки, разница в цене серверных и десктопных SATA SSD отличается вовсе не в разы.
Краткое резюме - для хранения важных данных, таких как базы данных 1С, в сервере должны использоваться исключительно серверные Enterprise SSD.

Корпус, блок питания и ИБП

Наиболее распространенным являются три типоразмера для небольших, однопроцессорных серверов:
- монтируемые в 19” стойку (Rack-mount),
- в обычном пьедестальном корпусе (Desktop),
- современные «кубики».
Если вы собираетесь размещать сервер на площадке хостинг-провайдера или специализированной серверной - оптимальным будет Rack-mount формат высотой 1U или 2U. И такой сервер категорически не рекомендуется размещать в том же помещении, где присутствуют люди ввиду его высокой шумности.
Исполнение в Desktop типоразмере корпуса применяется в случае, когда сервер будет стоять в одном помещении с людьми. Такие серверы относительно тихие, мало чем отличаются от ПК, и даже часто выполняют роль рабочей станции для одного из сотрудников.
Хорошим примером «Дружественного к пользователям» подходя являются специализированные корпуса-«кубики».

Кром того, что они приятно выглядят, они еще и тихие.

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

Также следует коснуться вечной темы - нужно или не нужно избыточное электропитание.
С точки зрения автора, при стоимости сервера от $1000 тратить сверху только на обеспечение избыточного электропитания (два блока питания в сервере) еще дополнительно порядка $400 действительно может быть необходимо, только если у вас нет возможности оперативно, за 2-4 часа отвезти сервер в ремонт.

Если сервер rack-mount, то он находится на площадке провайдера или в серверной, где, как правило, обеспечивается качественное электропитание. А если он в офисе - то в подавляющем большинстве случаев за 2-4 часа вполне можно съездить в сервис и заменить блок питания. Если же вы находитесь далеко от сервиса, то, как вариант, можно купить запасной блок питания и положить в шкаф как «ЗиП», а при поломке самостоятельно за 15-20 минут заменить вышедший из строя бок питания на запасной.

Говоря о блоке питания и вероятности выхода его из строя, необходимо вспомнить про источник бесперебойного питания (ИБП) для сервера. Он, как минимум, должен включать в себя возможности корректировки напряжения (AVR), а еще лучше быть класса Interactive. Для снижения рисков потери данных желательно, что бы ИБП имел возможность выключения сервера при низком уровне заряда батарей (и чтобы это все подключили и настроили). И он по своей мощности должен обеспечивать, как минимум, работу от батарей в течение 10-15 минут, чего в большинстве случаев достаточно для корректного выключения сервера.

Собираем сервер «под задачу»

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

а) Для пяти пользователей в файловой версии, подключенных по локальной сети через «толстый» клиент будет достаточно сервер в форм-факторе «кубика», с четырехъядерным процессором Intel Xeon E3 12хx, 8GB RAM, два SSD Intel s3510 240 ГБ в RAID1 на бортовом Intel Rapid Raid.

б) Для десяти пользователей в SQL и через «толстый» клиент будет достаточно сервера в форм-факторе «кубика», с четырехъядерным процессором Intel Xeon E3 12хx, 16 ГБ RAM, двумя SSD Intel s3510 240 ГБ в RAID1 на бортовом Intel Rapid Raid.

в) Для двадцати пользователей в SQL и в режиме «Удалённого рабочего стола» лучше взять сервер в типоразмере Desktop или Rack-mount, с шестиядерным процессором Intel Xeon E5 166x, 32 ГБ RAM, двумя SSD Intel s3510 120 ГБ в RAID1 для размещения баз данных 1С и двумя SATA HDD (RAID Edition) 2-4 ТБ в RAID1 для размещения OS, Backup и пользовательских данных, а также в роли файлового хранилища, и опять-таки на бортовом Intel Rapid Raid либо на Intel® RAID Controller RS3WC080.

И несколько абсолютно практических советов.
1. Не нужно «экономить на мелочи» и использовать неподходящие инструменты - в сервере лучше работает серверный процессор, серверная материнская плата и серверный SSD. Разница в цене с настольными компонентам и очень незначительна, а по функциональным возможностям может оказаться непропорционально большой.
2. Нет особого смысла планировать ресурсы более, чем на три года. Технологии меняются настолько быстро, что через год-два может оказаться эффективнее заменить диск или сервер, чем изначально закладывать ресурс на пять лет.
3. Принцип разумной достаточности применим и к выбору сервера. При объеме базы данных в 10 ГБ специализированный серверный объемом в 80 ГБ куда предпочтительнее «десктопного» в 200 ГБ.

Безусловно, все описанное выше не является догмой. Это эмпирически выведенные расчеты исходя из многолетнего опыта автора по оптимизации аппаратных средств под различные платформы компании 1С.

Основной программный продукт:

Выберите основной продукт 1С:Бухгалтерия 8 ПРОФ 1С:Бухгалтерия 8 ПРОФ (USB) 1С:Бухгалтерия 8 ПРОФ на 5 пользователей. Поставка для розничного распространения (USB) 1С:Бухгалтерия 8 ПРОФ на 5 пользователей. Поставка для розничного распространения. 1С:Бухгалтерия 8 ПРОФ. Поставка для розничного распространения (USB) 1С:Бухгалтерия 8 ПРОФ. Поставка для розничного распространения. 1С:Бухгалтерия 8 ПРОФ. Электронная поставка 1С:Бухгалтерия 8. Комплект на 5 пользователей 1С:Бухгалтерия 8. Комплект на 5 пользователей (USB) 1С:Договорчики 8 на 5 пользователей 1С:Договорчики 8 ПРОФ 1С:Документооборот 8 ПРОФ 1С:Зарплата и Управление Персоналом 8 1С:Зарплата и Управление Персоналом 8 (USB) 1С:Комплексная автоматизация 8 1С:Комплексная автоматизация 8 (USB) 1С:Комплексная автоматизация 8 для 10 пользователей + клиент-сервер 1С:Комплексная автоматизация 8 для 10 пользователей + клиент-сервер (USB) 1С:Комплексная автоматизация 8 для 10 пользователей + клиент-сервер. Редакция 2 1С:Комплексная автоматизация 8. Редакция 2 1С:Предприятие 8. Комплект прикладных решений на 5 пользователей 1С:Предприятие 8. Комплект прикладных решений на 5 пользователей (USB) 1С:Предприятие 8. Управление торговлей 1С:Предприятие 8. Управление торговлей (USB) 1С:Розница 8 ПРОФ 1С:Розница 8 ПРОФ (USB) 1С:Управление нашей фирмой 8 на 5 пользователей 1С:Управление нашей фирмой 8 на 5 пользователей. Электронная поставка 1С:Управление нашей фирмой 8 ПРОФ 1С:Управление нашей фирмой 8 ПРОФ. Электронная поставка 1С:Бухгалтерия 8. Базовая версия 1С:Бухгалтерия 8. Базовая версия. Электронная поставка 1С:Бухгалтерия автономного учреждения 8. Базовая версия (хозрасчетный план счетов) 1С:Бухгалтерия государственного учреждения 8. Базовая версия 1С:Договорчики 8. Базовая версия 1С:Зарплата и кадры государственного учреждения 8. Базовая версия 1С:Зарплата и Управление Персоналом 8. Базовая версия. 1С:Отчетность предпринимателя 8 1С:Предприниматель 2015 1С:Розница 8. Базовая версия 1С:Управление нашей фирмой 8. Базовая версия 1С:Управление нашей фирмой 8. Базовая версия. Электронная поставка 1С:Управление торговлей 8. Базовая версия 1С:Управление торговлей 8. Базовая версия. Редакция 11 1С:Упрощенка 8 Лицензия на 1С:Предприниматель 2015 на 12 месяцев Лицензия на 1С:Предприниматель 2015 на 6 месяцев 1С:Бухгалтерия автономного учреждения 8 КОРП (хозрасчетный план счетов) 1С:Бухгалтерия автономного учреждения 8 КОРП (хозрасчетный план счетов) (USB) 1С:Бухгалтерия автономного учреждения 8 ПРОФ (хозрасчетный план счетов) 1С:Бухгалтерия автономного учреждения 8 ПРОФ (хозрасчетный план счетов) (USB) 1С:Бухгалтерия бюджетного учреждения 8 1С:Бухгалтерия государственного учреждения 8 ПРОФ 1С:Бухгалтерия государственного учреждения 8 ПРОФ (USB) 1С:Бюджет муниципального образования 8 1С:Бюджетная отчетность 8 1С:Бюджетная отчетность 8 (USB) 1С:Вещевое довольствие 8 1С:Документооборот государственного учреждения 8 1С:Зарплата и кадры бюджетного учреждения 8 1С:Зарплата и кадры бюджетного учреждения 8 (USB) 1С:Зарплата и кадры государственного учреждения 8 1С:Свод отчетов 8 ПРОФ 1С:Свод отчетов 8 ПРОФ (USB) 1С:ERP Управление предприятием 2. Корпоративная поставка 1С:Бухгалтерия 8 КОРП 1С:Бухгалтерия 8 КОРП (USB) 1С:Документооборот 8 КОРП 1С:Зарплата и управление персоналом 8 КОРП 1С:Консолидация 8 ПРОФ 1С:Консолидация 8 ПРОФ (USB) 1С:Предприятие 8 ПРОФ. ERP Управление предприятием 2 + Документооборот КОРП. Сервер (x86-64). 50 клиентских лицензий 1С:Предприятие 8. ERP Управление предприятием 2 1С:Предприятие 8. Управление производственным предприятием 1С:Предприятие 8. Управление производственным предприятием (USB) 1С:Предприятие 8. Управление производственным предприятием для 10 пользователей + клиент-сервер 1С:Предприятие 8. Управление производственным предприятием для 10 пользователей + клиент-сервер (USB) 1С:Управление холдингом 8 1С:Управление холдингом 8. Корпоративная поставка