`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Проектирование сервера под 1С

+2222
голоса

Выбор оптимального серверного оборудования под 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-12 потоков пользовательских терминальных сессий — это связано с внутренней архитектурой процессоров. Как показывает практика, под задачи 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.

3-5 польз., 300 MB

10-15 польз., 800 MB

40-50 польз., 4 GB

80-100 польз., 20 GB

400-600 IOPS

1500-2500 IOPS

5000-7500 IOPS

12000-18000 IOPS

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

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

 

7200 rpm SATA

15000 rpm SAS

Intel 320 160GB

Intel 710 200GB

Intel 910 400 GB

read

100-120 IOPS

200-220 IOPS

35 000 IOPS

35 000 IOPS

90 000 IOPS

write

80-100 IOPS

180-200 IOPS

600-8600 IOPS

2400 – 8600 IOPS

38 000 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:

 

RAID 0

RAID 1 (or 10)

RAID 5

RAID 6

Read

1

1

1

1

Write

1

2

4

6

Если собрать 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, первоочередными задачами будут выбор соответствующей архитектуры, оборудования с минимальным количеством точек отказа и полноценных технологий кластеризации. Но это уже совсем другая история.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+2222
голоса

Напечатать Отправить другу

Читайте также

КО, Юра, Ентри,

большое спасибо за такую статью.
побольше таких материалов, а не статей не о чем с семинаров.

С удовльствием высказу искреннюю благодарность инженерам Intel из Нижнего Новгорода, а также лично представителю украинского офиса Сергею Шевченко за пояснения в области технических нюансов работы SSD и SAS/RAID контроллеров (и бортовых, и дискретных), и обмен результатами реальных тестов оборудования. Это позволило избежать целого ряда неверных шагов в проектировании серверов, в т.ч. под задачи 1С.

На семинарах можно услышать, что у всех вендоров имеются спецсистемы по расчету потребностей для сервера (sizing).
Сколько требуется ОП, ядер под задачу (например, чтение - аналитика) и под какое кол-во пользователей (по их ролям).
Обычно, это простенькие Эксел-файлы.

Странно, что эта статья вызвала такой ажиотаж, неужели у 1С такого нет???

Казалось бы, соседний материал по мониторингу дисковой подсистемы - это азбука. Ан нет, пользоваться бесплатным ПерфМоном, и по его результатам делать выводы о (не)пригодности сервера не умеют многие IT-администраторы. А Вы хотите, чтобы пользователи 1С разбирались, откуда в сервере берутся ИОПСы? Им ведь как раз и внушается мысль на помянутых семинарах, что разбираться не надо. Достаточно купить готовую коробку из списка совместимости на сайте 1С.

Не могу квалифицировано ответить по другим приложениям, отвечу по 1С.
На примере "их жизни".
Допустим, у Вас что-то болит.
Вы приходите в поликлинику.
Дальше Вам дают анкетку из 20-50 вопросов, которую Вы заполняете.
Сразу после заполнения анкетки по ней подсчитываются баллы, вам ставится диагноз и выписывается лечение.
При этом ни осмотр врача, ни даже измерение температуры, ни тем более какие-то анализы совершенно не нужны, т.к. на все вопросы Вы уже ответили в анкете.
Сайзинг сервера для нужд 1С по табличке имеет где-то такую же точность "диагностики".
Причина - в высокой степени вариативности различных реальных баз данных под 1С в связи с разницей учетных политик, наборов хозяйственных операций, объемов вводимых данных, территориальной и организационной структуры предприятий, различного количества пользователей и различных наборов стандартных конфигураций, применяемых на предприятии. Я уже молчу про различный "чудо-код", когда просто грамотно переписанный запрос с тем же конечным результатом начинает выполнятся в 10-15 раз быстрее.
В данном материале постарался изложить общие принципы подбора оборудования, а в предыдущем - специально описал методику, как искать причины проблем, "ставить диагноз путем осмотра и сдачи анализов".

P.S.: По описанному выше - несложно нарисовать для себя табличку самому.

Александр, все дело в целевой аудитории. При внедрении ERP-систем А-класса никому и в голову не придет копаться в устройстве серверов и отклоняться от брендбука. Что конфигуратор показал - то и ставят. А вот пользователям 1С анатомические сеансы очень даже интересны. Сервер - такой же ресурс оптимизации для SMB-компании, как и программный код.

Вот еще одно пояснение "ажиотажу читателей". В отчете о долях рынка ERP-систем написано:

"По оценкам аналитиков, почти 40% прирост обусловлен прежде всего эволюционным переходом небольших и средних предприятий, использующих продукты «1С», на систему «1С: Предприятие 8», которая, в отличие от предыдущих версий, относится к классу ERP. Благодаря этому, «1С» за год удвоила продажи (рост 105,4%) и прибавила к своей рыночной доле более 14%, увеличив ее с 30,2% в 2010 г. до 44,6% в 2011 г. (в 2008 г. доля компании не превышала 14%)."

Как к этому ни относись, даже по официальной статистике 1С стоит поди уже в половине компаний. С одной стороны, бизнес обмельчал, с другой, 1C сделала заметный шаг вперед. Мы реалии рынка ERP не комментируем, мы к ним приспосабливаемся. И помогаем интересующимся понять расклад их собственных возможностей.

To Слепцов Алексей
Алексей, а вы реплику согласовали со своей PR-службой? Я правильно понимаю, что мы уже можем не посещать семинары и мероприятия вашей компании?

Я всегда говорю, что мое личное мнение может расходится с точкой зрения компании ;-)Думаю вы в этом деле опытнее, я просто читатель, но уровень журналистов, в вашем издании разный: после отчета Тимура, жалеешь, что не посетил это мероприятие, а бывают отчеты другого уровня ;-)
Я понимаю, что раньше все было лучше, и солнце светлее, но мне кажется, что лет 5 назад было больше собственных статей КО, с исследованиями, обзорами и собственной точкой зрения Журналиста (именно с большой буквы). Такие статьи всегда интересно читать.
И насколько я вижу, эту статью активно обсуждают на 10-ке ресурсов, сотни людей рекомендуют ее друг другу. А обычный отчет о семинаре 2-3 лайка.

Алексей, раньше, бесспорно, "были и голуби больше и..." (цитируя классика). Но первый ваш коммент, извините, был уж очень однозначный.

> Владислав Слободяник
> Я бы при этом еще виртуализацию платформы для 1С описал. Пару абзцев, но полезно.

У нас есть статистика в основном по виртуализации на базе Microsoft Hyper-V.
Сервер приложений 1С:Предприятие 8.2 и пользовательские сессии 1С:Предприятие 8.2 в режиме Remote Desktop прекрасно себя чувствуют в виртаульных машинах - как в одной общей на всех (SQL, сервер приложений 1С и удаленные пользователи 1С), так и в раздельных VM.
А вот MS SQL Server 2008 с базами данных 1С не любит работать в виртуальной среде. Каждый раз при переносе из виртуально среды на "голое железо" именно сиквел сервера получали отдачу от SSD, на которых хранились БД, на 15-30% выше (в IOPS). Хотя до перехода на "железо" эти же диски были подключены в VM с сиквелом по Direct Access. Как и писал выше, в стандартном режиме это особо не чувтствуется, а вот при перепроведении месяца с восстановлением последовательностей на 50+ тыс. документов уже критично (сиквел в VM - не успевает перепровестись месяц за выходные, сиквел на "железе" - успевает).

>>У нас есть статистика в основном по виртуализации на базе Microsoft Hyper-V.
>>(сиквел в VM - не успевает перепровестись месяц за выходные, сиквел на "железе" - успевает).

точно ссылку не дам т.к. давно натыкался (на opennet), но были утверждения, что SQL в VM показывают больше производительности чем на "железе"
и судя по вышесказанному SQL не в Xen не в vmware не тестировались?

Денис, возможно, в статье это не совсем четко прописано, потому уточню:
- Данные для статьи относительно работы 1С в различных режимах и на разном оборудовании получались не в лабораторных условиях, а как результат обращения заказчиков с просьбой "помочь разобраться".

Т.е. мы "попадали" в совершенно конкретную ситуацию, с уже имеющимся либо запланированным "окружением" в виде системного ПО, принятого в виде стандарта на предприятии. И как результат - использовали ту систему виртуализации, которую использовал заказчик.
Безусловно, часть тестов делалась "синтетически" в лаборатории, особенно касающихся производительности тех или иных устройств, стресс-тесты, моменты оптимизации "железа" и настроек ПО.
Специального же сравнения работы одного и того же пакета прикладного ПО на одном и том же "железе" под различными средами виртуализации мы не производили. И даже никогда не ставили перед собой такой задачи.
Так что вполне допускаю, что при некоторых условиях VMware или Xen окажут лучшую производительность.
Относительно же повышенной производительности MS SQL под VMware - даже не буду споить, такое вполне возможно. Меня только смущает "цена вопроса". Ведь ускорить программно дисковые операции можно в первую очередь за счет работы с кешем. Утверждать, как реализовано это у VMware не буду, но как правило ускорение кеша почти всегда равно кешированию на запись на программном уровне, т.е. в энергозависимой RAM...

> Ulan Kakaev
> Все равно проведение документов выполняется на сервере, зачем исключать Ethernet из цепочки SQL-сервер —> Сервер приложений 1С:Предприятие 8 —> пользовательская сессия 1С:Предприятие 8?

Проводится - да, на сервере.
А где выполняются расчеты?
А где выполняется код динамических форм?
А где выполняется загрузка данных от банк-клиента?
А где смотреть развернутую до договора оборотно-сальдовую ведомость для поиска ошибок первого события по НДС?

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

Сергей, а что Вы понимаете под использованием Ethernet "по полной"?

Обновить до максимальной пропускной способности и загрузить на 100% в режиме клиент-сервер

На большинстве серверных плат распаяны два порта 1Gb Ethernet. Формально - у них у всех одинаковая пропускная способность. Но, за редким исключением, на платах стоят фактически десктопные чипы - вроде i82574L, и только изредка - полноценные серверные - i82576 или i350 (такие же стоят на двухпортовых сетевых картах за $160). Сами понимаете, если цена серверной сетевой карты составляет треть цены материнской платы, то от "бесплатных сетевых карт" на платах многого ждать не приходится. При интенсивных сетевых обменах они становятся потенциально узким местом и пожирателем ресурсов, особенно в виртуализированных средах. Поэтому сетевая подсистема требует к себе внимания и без нужды плодить сущности (множественные физические серверы, общающиеся по Ethernet) не следует.

Это понятно. Я же говорю про то что не стоит всех подключать только через терминальные сессии. И вычислительные ресурсы нужны значительные на каждого пользователя и 100-120MB оперативной памяти как-то маловато я считаю. Это конечно удобно, надежно, безопасно и т.п., но и стоить будет дороже.

Подключение по сети имеет свои недостатки.
Пользователи, подключенные по сети, на ряде операций за счет большей латентности доступа к таблицам могут вызывать блокировки таблиц и замедлять работу остальных. Особенно это чувствуется на работе с большими по объему справочниками (вроде Номенклатура или ОС) в больших БД.
Исходя из стоимости RAM DIMM, по состоянию на сегодня дешевле наращивать объем оперативной памяти у сервера, чем модернизировать ПК пользователей и развивать инфраструктуру Ethernet.

Скажем так, для тех пользователей, которые работают с базой данной не интенсивно и у которых нормальные компьютеры выигрыша от терминального подключения в сравнении с клиент-серверным практически не будет, а доплатить все таки придется ведь не стоит забывать про стоимость терминальной лицензии. А маломощных компьютеров остается все меньше и меньше, хотя у одних моих клиентов до сих пор нормально работает комьютер на windows 95 с 32МБ ОЗУ - в таком случае конечно вариантов нет :)

Очень полезная и интересная статья. Хотел бы просветить по поводу "железа" для 1С Российских 1Сников. Можно ли перепечатать вашу статью (со ссылками на http://ko.com.ua) на сайте infostart.ru

Александр Забалуев, г.Ухта

Александр, спасибо за оценку материала.

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

Замечательная статья, всё по делу! Спасибо, Юрий.

Немножко эрраты — конфигурации «Торговля и склад» для 8.2 нет, её заменила «Управление торговлей».

С моей точки зрения tempdb на потребительских SSD это спорное решение. По моему опыту SQL Server пишет туда больше чем в файлы таблиц. Так что скорость 520-х упадёт достаточно быстро. Но, конечно же, иногда это экономически интересно, заменяешь раз в год дешёвый накопитель вместо вложения больших средств в корпоративные решения.
___________________________________
Twitter: @valbudkin

Валентин, спасибо за комментарий и правку.
С "ТиС" и "УТ" - сказывается прошлая память... В статье уже откорректировал.

Относительно таблиц tempDB.
По ним действительно идет очень высокая нагрузка. И, по идее, для них тоже нужны серверные SSD.
Что слегка меняет ситуацию - как правило объем пространства, требующийся tempDB относительно невелик: 4-16GB.
В итоге если исключительно под tempDB выделить, к примеру, SSD Intel 520 series 120GB, т.е. разметить 8-24GB, а остальное пространство оставить неразмеченным - то под over provisioning будет выделено более 93-80% пространства SSD дополнительно к уже имеющимся скрытым 8%.
Одно из ключевых отличий серверного SSD Intel 710 series от десктопного SSD Intel 320 series как раз и составляет разница в over provisioning: более 40% для Intel 710 и 8% Intel 320.
Что нам мешает взять десктопный SSD Intel 520 по цене десктопного и просто не размечать как можно большую область, тем самым увеличивая over provisioning?
Если можем - то в чем смысл платить больше?
И, как Вы верно заметили, такой диск, в случае сильного износа, значительно дешевле заменить.

Таки печатное слово помогает. SSD-то оказывается, не причуда богатых, а "золотой ключик" в умелых руках. Пользователи 1С начинают понимать, откуда берутся иопсы (а где их нету по определению), и что производительный сервер 1С - не обязательно дорогой сервер. И что в серверах на несколько десятков клиентов нет места рейд-массивам на SAS дисках.

Отличная статья, конкретно и по делу. Очень мало таких материалов. Побольше бы.

Если оставить большой запас по не размеченному месту на ssd - можно использовать 330 и 520 серию на SQL серверах? какая практика?

Какой Raid уровень лучше использовать 5 или 10? На 10 уровне не будет ли контроллер узким местом?

Есть статья на близкую тему - с большей конкретизацией для серверов начального уровня http://ko.com.ua/servery_nachalnogo_urovnya_pod_1s_69697.

Про 330-ю серию ответил в соседней ветке, не надо ее ставить, она для ПК. 520-ю серию интел аккуратно заводила на смену 320-й, но с оговорками: у нее отменные показатели в задачах потоковой записи (в сервере это могут быть бэкапы, сброс логов), но очень посредственные в записи с произвольной выборкой короткими блоками - как в SQL БД. Если говорить об интеловских SSD, то под БД лучше ставить 710-ю серию или дождаться 3700-й.

Если RAID под БД - то только 10. Если RAID 10 из 4 SSD - то любой пристойный контроллер (Adaptec 6405, LSI 9266-4i) справится спокойно.

По поводу рейд контроллера, если брать с запасом может быть имеет смысл выбрать 7 серию контроллера адаптек? и в будущем нарастить массив из ссд дисков?

Можно и на 7-й серии - у него более мощный процессор с хорошим запасом по IOPS. При желании можно создать массив на одних только SSD. Но это не отменяет анализа приложений - возможно вам больше подойдет SSD-кэширование и Adaptec 7805Q. И еще стоит помнить про нестандартные разъемы высокой плотности у седьмой серии - HDmSAS, кабель надо подбирать под тип корзины. Как и писал раньше, имеет смысл обсуждать сервер целиком, определившись с температурным профилем базы данных, ее динамикой роста, структурой операционных приложений итд. Пишите, звоните, найти нас несложно.

2. Индексные файлы вынесены на быстрый и недорогой одиночный SSD

Научите, плз, искать и выносить индексы в SQL-ной базе. Я просто чего-то не знаю? Или речь о файловой версии семерки?

З.Ы. Это не сарказм, я реально испугался за свой уровень подготовки к предстоящему через месяц проекту.

Вы все верно поняли - речь была о файловой версии.

Юрий, может в статье прямо указать что упоминание о индексах, относится к файловой версии 1С 7.7?

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

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

Павел, можно об этом поподробнее?
К какой версии 1с это относится?
К какой базе - файловой или SQL?
Как создать эту файловую группу и как ее перенести на SSD?
Спасибо.

Рекомендую ознакомиться с этим обсуждением:
http://forum.infostart.ru/forum24/topic68077/
Скорость HDD или SSD значительной мере не является решающей для оценки общей производительности сервера 1С. Гораздо большее значение для работы сервера приложений 1С имеет скорость обмена процессора с оперативной памятью.

1С:Предприятие 8.2 Сервер приложений х64 - вообще равнодушен к тому, на какой дисковой подсистеме он стоит - он диски практически не использует.
Что Сервер приложений 1С, что пользовательская часть 1С - очень сильно чувствительны к частоте процессора и латентности RAM.
А с учетом того, что в современных процессорах контроллер памяти интегрирован в CPU - скорость взаимодействия с RAM напрямую зависит от частоты этого процессора и от того, какими планками набрана RAM (идеально - 1 планка на канал высокочастотной памяти).
Мы своим клиентам под 1С рекомендуем брать только среднюю и верхнюю линейку процессоров - начиная с Intel Xeon E5-2650.

Если взять процессор Xeon E3-1270v2 3.50Ghz, на ваш взгляд для однопроцессорной системы достаточен будет? конечно понимаю, что все зависит от остальной системы, но все же, что можете сказать имеет ли смысл на них смотреть?

Павел, все-таки прочтите смежную статью http://ko.com.ua/servery_nachalnogo_urovnya_pod_1s_69697. Там предметно расписано, что 25 клиентам 1С производительности одного Xeon E3-1270V2 (или 1275V2) с 16-32GB памяти хватает за глаза. При условии, что дисковая подсистема строится адекватно нагрузке ввода-вывода.

Кстати по поводу упомянутой конфигурации «Управление Торговым Предприятием» - добиться хорошей производительности от нее невозможно без существенного переписывания программного кода. Скорость проведения документов с отключенным и включенным бухгалтерским учетом отличается на порядок вследствие неправильной архитектуры самой конфигурации. Вы ее хоть на Deep Blue поставьте - "летать" она не будет :-(

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

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

Толку от такого подхода будет мало. В 95% случаев мы имеем 1 сервер (ну или 1 кластер) с БД, связанный с одним сервером приложений, связанным в свою очередь с одним терминальным сервером. Терминальников может быть и больше, но там траффик уже не такой интенсивный, как между СП и БД.
При таком раскладе мы имеем схему ip_addr_DB <-> ip_addr_AppSrv <-> ip_addr_TS - простая агрегация каналов тут бессильна. Чуток улучшить ситуацию мог бы файный свитч, умеющий балансировать нагрузку в транке по номерам портов (L4 balancing), но такая балансировка работает только на нефрагментированных пакетах (т.к. во фрагментах нет номеров портов), а у нас ситуация носит как раз противоположный характер - обмен между AS и DB идёт большими TCP-пакетами. Тут реально помогать будет только Jumbo frames. Но двухкратного прироста производительности (как в сказке про счастливый транк) не случится.
Где-то так, по-моему.
А то мы щас юные поколения осеним надеждой на светлое будущее, и они за год-другой своими бесполезными 8-миканальными транками продажи свичей в стране поднимут в 2 раза. ))

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

Так это ж еще Карамзин на вопрос "Как там, в России?" неизменно отвечал - "Воруют"

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT