Записки IT специалиста

Как оценить многопоточную производительность сервера 1С:Предприятие?

Все знают тест Гилева, который стал стандартом де-факто для оценки производительности серверов 1С. Но далеко не все умеют правильно применять и интерпретировать его результаты.

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

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

👉 Как быть? Взять другой инструмент - Многопоточный тест производительности 1с (Fragster). Он не настолько популярен и раскручен как тест Гилева, но позволяет оценить именно многопоточную производительность.

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

Сам автор предлагает интерпретировать результаты следующими образом:

🔹Нижняя граница - 400-500 попугаев на поток (это когда еще «терпимо»)

🔹 Нормально:

▫️ >2000 для РС на 4 потоках
▫️ >1500 для РН на 4 потоках
▫️ >1000 для РБ на 4 потоках

Чтобы не быть голословными рассмотрим реальные тесты, которые предоставили пользователи. Сам пользователь пишет, что на сервере 50 активных сеансов и оценка пользователей комфортности работы – 4 балла.

Что мы видим? На 4 потока результаты немного ниже требуемой отметки для регистров сведения и хорошо для регистров накопления и бухгалтерии. Т.е. работа с небольшой нагрузкой будет преимущественно комфортной.

Если рассматривать многопоточность, то сервер хорошо масштабируется до 32 сеансов и начинает сдавать при большем количестве. После 60 сеансов производительность не растет, но и критического ухудшения еще не происходит.

Критическая отметка – 80 сеансов, сервер серьезно перегружен и уже не вывозит. Если снова вернуться к однопоточному графику, то как раз на этом промежутке 60-80 сеансов производительность достигает нижней планки терпимости.

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

Про «реальную производительность» и APDEX

В комментариях нас уже несколько раз спросили, как мы оцениваем «реальную производительность» наших систем. Вопрос хороший, непростой вопрос.

Мы специально взяли фразу «реальная производительность» в кавычки, потому что за ней кроется нечто непонятное, которое каждый понимает по-своему. Вот прямо сейчас попробуйте отвлечься от прочтения заметки и попытайтесь сформулировать определение этому термину.

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

А теперь сделаем некоторое лирическое отступление. IT-отдел подразделение сугубо затратное, прибыли оно не приносит. Его задача обеспечивать бизнес-процессы. Прибыль при этом генерируют совсем другие подразделения.

Задача бизнеса – зарабатывать деньги. Бизнесу все равно насколько оно там технически правильно или какая «реальная производительность» в попугаях. Ему это не интересно, ему нужно чтобы работали производящие прибыль подразделения и поэтому мнение пользователей этих подразделений всегда будет иметь больший вес, чем мнение обслуживающих их айтишников.

Если пользователи такого подразделения говорят, что система работает плохо, то вы можете до посинения показывать результаты бенчмарков и уверять, что с вашей стороны все хорошо, вон целых 100 попугаев по Гилеву, должно все летать… Ответ будет прост – не летает, пользователи недовольны.

А в соседней конторе может стоять точно такой же сервер, с точной такой же конфигурацией 1С и там все довольны. Это как так? Почему?

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

Основным фактором влияния для APDEX является целевое время выполнения операции, если операция укладывается в период T – все довольны, если выходит за пределы 4T – полностью разочарованы.

Собранные результаты обрабатываются и нормируются по шкале от 0 до 1, где 0 – полностью разочарованы, 1 – полностью довольны.

👉 Результаты интерпретируются по шкале:

▫️0.00 - 0.50 неприемлемо
▫️0.50 - 0.70 очень плохо
▫️0.70 - 0.85 плохо
▫️0.85 - 0.94 хорошо
▫️0.94 - 1.00 отлично

APDEX вычисляется для каждой ключевой операции, что позволяет учесть конкретные потребности бизнеса и особенности его бизнес-процессов.

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

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

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

Согласны, степень довольства – величина субъективная, но APDEX как раз позволяет сопоставить субъективные ощущения с объективными данными.

Если большинство пользователей говорит, что система работает так себе, то принимаем индекс APDEX за 0,65 – плохо, выясняем реальное время выполнения операции и на его основании рассчитываем желаемое T.

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

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

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

858 терабайт государственных данных Южной Кореи сгорели к чёртовой матери. Бэкапа просто не было

26 сентября 2025 года в государственном дата-центре National Information Resources Service (NIRS) в городе Тэджон вспыхнул пожар. За несколько часов огонь уничтожил серверы облачного хранилища G-Drive (от слова government), где чиновникам выделялось по 30 ГБ для хранения различных документов, которые запрещено было хранить на офисных компьютерах. Им пользовалось 17% всех федеральных чиновников в Корее, или около 125 тысяч человек. Но не только — там хранились данные ещё 163 онлайн-сервисов южнокорейского правительства.

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

✅ Подробнее: https://habr.com/ru/articles/954512

В этой новости все прекрасно. И в очередной раз показывает, что госы - такие госы и не только у нас в стране.

Расходы на виртуализацию. Краткие итоги

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

Нравится, не нравится – но это де-факто новый стандарт. Причем мир все дальше уходит от виртуальных машин и отдает предпочтение контейнерам – LXC, Docker и т.д.

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

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

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

Хотим переносимость между хостами с разными поколениями процессора – миримся с тем, что некоторые современные инструкции виртуалка не поддерживает.

Желаем максимальную производительность – выбираем самые современные синтетические устройства.

Но в любом случае расходы на виртуализацию не должны превышать 10-15%, если более, то вы что-то сделали не так, или сознательно пожертвовали производительностью ради иных преимуществ.

А теперь вернемся к нашим процентам. Ребята, если для вас эти 10-15% являются критичными, то у меня плохая новость – ваша система не тянет рабочую нагрузку и справляется из последних сил.

Откройте любую систему мониторинга и посмотрите пороги срабатывания триггеров по основным показателям. Примерно будет так: 80% - начинаем беспокоиться и принимать меры, 90% - бьем во все колокола, включаем сирену и вообще сигнализируем, что ситуация полный швах!

А это как раз ваши 10-15% «потерянные» на виртуализации. Если так, то ваша система и без виртуализации не имела никакого запаса производительности и любой резкий скачок спокойно выбьет ее из седла, а виртуализация только подсветила проблему.

Что касается производительности, то мы будем исходить из того, что высокие значения «попугаев» никому не нужны. Пользователи производственных систем не экстремальные геймеры и выжимать максимум из железа им без нужды.

Есть определенный уровень комфортной эксплуатации и все что выше нее просто останется незамеченным.

Если брать ту же 1С, то это 35-40 «попугаев» по Гилеву. Вы можете станцевать ужом на сковородке и обеспечить 60-70-100!!! Но кто это заметит?

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

Ну было у нас 75 «попугаев» Гилева, стало 65 – кто это заметит? Никто. Но за эти 10 «попугаев» мы приобретаем переносимость, высокую доступность, снижение затрат на сопровождение и многие другие плюшки.

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

​​Скорость виртуальной сети в Proxmox

После вчерашней публикации возник ряд вопросов по скорости виртуальной сети в пределах одного хоста.

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

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

В этом случае скорость лимитируется только вычислительными способностями CPU и пропускной способностью памяти и как правило измеряется в десятках Гбит/с.

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

При использовании эмуляции реальных сетевых адаптеров, скажем E1000 мы можем упереться в ограничения драйвера. Если же используем полностью виртуальный VirtIO, то скорость также ограничивается только возможностями процессора и памяти.

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

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

Для примера мы выполнили тест на процессоре Core i5-4670 3,4 ГГц с 32 ГБ DDR3 2400 и получили значения около 35 Гбит/с, что близко к потолку пропускной способности этого типа памяти в двухканальном режиме (около 38 Гбит/с).

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

​​Сегодня в обсуждении возник вопрос о влиянии виртуализации на производительность. Поэтому решили провести небольшой экспресс-тест.

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

Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
CPU cores: 2
Frequency: 2428.759 MHz
RAM: 15Gi
Swap: 8.0Gi
Kernel: Linux 5.15.108-1-pve x86_64

Disks:
sda 223.6G SSD

CPU: SHA256-hashing 500 MB
5.458 seconds
CPU: bzip2-compressing 500 MB
10.662 seconds
CPU: AES-encrypting 500 MB
2.635 seconds

ioping: seek rate
min/avg/max/mdev = 103.4 us / 146.3 us / 6.43 ms / 67.6 us
ioping: sequential read speed
generated 8.81 k requests in 5.00 s, 2.15 GiB, 1.76 k iops, 440.4 MiB/s

Теперь LXC контейнер:

Processor: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
CPU cores: 2
Frequency: 2500.000 MHz
RAM: 2,0Gi
Swap: 512Mi
Kernel: Linux 5.15.108-1-pve x86_64

Disks:
sda 223,6G SSD

CPU: SHA256-hashing 500 MB
5,858 seconds
CPU: bzip2-compressing 500 MB
11,333 seconds
CPU: AES-encrypting 500 MB
2,666 seconds

ioping: seek rate
min/avg/max/mdev = 110.8 us / 163.9 us / 4.42 ms / 62.5 us
ioping: sequential read speed
generated 8.16 k requests in 5.00 s, 1.99 GiB, 1.63 k iops, 408.1 MiB/s

Как видим - разница на уровне погрешности измерений. Поэтому можно смело говорить, что производительность контейнеров примерно равна производительности хоста.

Теперь KVM виртуальная машина, значения по умолчанию.

Processor: Common KVM processor
CPU cores: 2
Frequency: 1996.800 MHz
RAM: 3,9Gi
Swap: 974Mi
Kernel: Linux 4.19.0-20-amd64 x86_64

Disks:
sda 8G HDD

CPU: SHA256-hashing 500 MB
8,569 seconds
CPU: bzip2-compressing 500 MB
15,707 seconds
CPU: AES-encrypting 500 MB
15,507 seconds

ioping: seek rate
min/avg/max/mdev = 257.1 us / 698.5 us / 29.7 ms / 742.4 us
ioping: sequential read speed
generated 2.75 k requests in 5.00 s, 686.5 MiB, 549 iops, 137.3 MiB/s

В отличии от контейнера виртуалка добавляет отдельный слой виртуального железа и это вносит свои издержки.

Так как у нас эмулируется Common KVM processor, то сразу видим провал по частоте до номинальной и первые два процессорных теста примерно соответствуют разнице в частоте.

А вот третий полностью зависит от поддержки аппаратных инструкций процессора и здесь разница довольно серьезная. Но зато Common KVM processor является универсальным и переносимым.

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

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

Если же нужна производительность, то смело берем LXC.

​​До свиданья наш ласковый миша

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

Сегодня мы поговорим об mdadm, старом-добром mdadm, который мы все любим, знаем и используем.

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

В чем проблема? А проблема в таком явлении, как bitrot, битовое гниение (https://t.me/interface31/2600) – деградация данных, не связанная с физическим выходом из строя накопителя и часто даже не препятствующая чтению данных, так как встроенные во многие форматы методы коррекции позволяют такие ошибки исправлять.

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

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

Но они правы и буквально вчера мы столкнулись с неприятной ситуацией с битовым гниением на mdadm.

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

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

Учитывая важность архива конечно-же делались его копии, в т.ч. и во внешнее хранилище. Извлеченная из бекапа копия проверку подписи прошла.

Следовательно? Следовательно мы имеем дело с классическим bitrot, которое тихо и незаметно портит данные, и никто об этом ни сном, ни духом.

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

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

А причем тут mdadm? А при том, что все это хранилище как раз было организовано средствами mdadm: LVM поверх двух зеркал по 4 ТБ.

Да, mdadm защищает нас от физического выхода диска из строя, но от битового гниения спасти не может.

Кто может? Современные файловые системы с контролем целостности данных: ZFS или btrfs, но для этого избыточность также должна создаваться средствами этих ФС, в этом случае они смогут эффективно выявлять повреждения и восстанавливать их за счет избыточных данных.

Если же вы просто натянете btrfs поверх mdadm – то ничего работать не будет, избыточность брать неоткуда.

Поэтому, как бы прост, понятен и удобен не был mdadm – его время вышло, говорим старичку спасибо и отправляем на заслуженную пенсию.

Встречайте AIOps в INFRAX — виртуального инженера, который работает прямо внутри карточки инцидента:

- анализирует логи,

- предлагает команды,

- помогает устранять неполадки быстрее и надёжнее.

🔐 Все действия прозрачны и безопасны: журналируются в инциденте и выполняются строго в рамках ваших политик доступа.

Что такое INFRAX? Это:

🖥 Мультиметричный мониторинг — CPU, память, диски, трафик, доступность узлов, интерактивные графики и гибкие алерты.

🎫 Helpdesk — управление тикетами, статусы, приоритеты, исполнители и комментарии, портал самообслуживания для пользователей.

🤖 Автоматизация — агенты для Windows/Linux, запуск скриптов по расписанию, планировщик задач, автодетект узлов.

🔐 Удалённые подключения — RDP, SSH, VNC прямо из веба или нативных клиентов, видеозапись сессий для аудита.

📚 База знаний — статьи, категории, контроль публикаций, статистика по популярности.

👥 Управление пользователями — детальная система прав, интеграция с IAM, аудит действий, изоляция данных.

📊 Дашборды — мониторинг, техподдержка, удалённые подключения с realtime-обновлением.

🔥 Infrax — это ситуационный центр вашей ИТ-инфраструктуры. Всё, что нужно для стабильной и безопасной работы сервисов, в одном решении.

#реклама
О рекламодателе

Zabbix – а куда делся мой ресурс SSD?

Жил был Zabbix и его судьба, как это обычно случается, была трудна. Вначале, он как Сирота Казанская жил, где придется, потом, кое-как обрел свой угол, где и обретался худо-бедно…

Потом администраторам приблудился компьютер, не самый плохой, что-то типа Ryzen 5, и они подумали – если он никому не нужен, то сделаем на нем свой сервер и соберем на него всякие админские штуки, тот же Zabbix, чего он там по закоулкам тусуется.

Сказано – сделано. Докупили память, новые NVMe диски, поставили Proxmox и запустили это все в эксплуатацию.

А третьего дня сильно удивились – а куда делся ресурс SSD? За четыре с небольшим месяца (131 день) кто-то скушал 79% ресурса SSD. Диски, так как серьезной нагрузки не предполагалось, брали недорогие, Kingston NV2 500 ГБ с TBW 160 ТБ.

Несложный подсчет показал, что ежесуточный объем записи на диски составил 745 ГБ и основной виновник в этом – процесс MySQL обслуживающий Zabbix. Если продолжать такими темпами, то дисков хватит еще на два месяца.

👆 Мораль? Изучайте потребности собственных приложений в ресурсах перед покупкой комплектующих, а не после. И да, диск – это расходный материал.

​​Монолит против виртуализации

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

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

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

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

Кто-то скажет, а какая разница, сервер все равно один, только добавляется лишняя прослойка в лице виртуализации.

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

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

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

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

Оптимально: один сервис – одна виртуальная машина (контейнер).

Далее – считаем ресурсы, как дисковые, так и по оперативной памяти. И то и другое можно выделять с превышением суммарной наличной емкости, но понимать, что этот момент придется постоянно контролировать.

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

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

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

Да, при необходимости вы можете использовать нужное вам программное окружение. Но контейнер с Debian 8 на Proxmox 8 не означает, что вы там используете Debian 8, а то, что вы используете ядро от Debian 12 в окружении библиотек из Debian 8.

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

Что выбрать? Смотрите сами. Контейнер дает минимальную потерю по производительности, фактически вы работаете на железе хоста. Также контейнеры используют память хоста и то, то вы им выделили – это лимиты.

Но они имеют свои особенности эксплуатации и это надо читать документацию к гипервизору.

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

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

Административная виртуалка

В свете перевода всей инфраструктуры 1С на Linux и в контейнеры встает закономерный вопрос – как обслуживать все это хозяйство.

«Что значит как?» —спросит иной читатель, со своего рабочего места. Но тут не все так просто. Да, повседневные задачи вы можете выполнять откуда угодно, в т.ч. и удаленно. Инструментов для этого хватает.

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

Хорошо, если у вас есть выделенное рабочее место в локальной сети, а если вы нештатный админ или аутсорсер? Также рабочее место может оказаться выключено во внерабочее время, зависнуть, в общем много чего может случиться.

Поэтому мы уже давно практикуем административные виртуалки. Это обычная виртуалка с самой обычной Windows 10/11 на том же самом гипервизоре (или на любом доступном, если их несколько).

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

👉 Накладные расходы – место на диске и потребляемая память. В этом случае уместно использовать Memory ballooning для динамического выделения памяти или просто включать такую виртуалку по необходимости если свободной памяти не очень много.

👆 А плюсов такого решения более чем достаточно. Про высокую доступность такого рабочего места мы уже говорили. Но оно еще и повторяемо – вы можете взять уже настроенную виртуалку и сделать из нее шаблон. После чего быстро разворачивать ее по необходимости.

Зависла – перезагрузим из веб-интерфейса гипервизора, выключена – включим. Сломалась – починим, хотя быстрее развернуть новую из готового шаблона.

Нужно выполнить какие-то ресурсоемкие работы? Добавили вычислительных ресурсов. И все это в быстрой внутренней сети гипервизора.

❓ А вы используете подобные инструменты?

Накладные расходы на контейнер

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

🔹 Итого по памяти ~ 50 МБ, обратите внимание, что сам контейнер показывает большее значение. Но никакого противоречия тут нет, так как контейнер считает внутри и собственное потребление и совместно используемые с хостом ресурсы, в частности ядро.

🔹 Итого по диску ~ 500 МБ, цифра на фоне типовых размер баз 1С достаточно скромная. Даже при использовании SSD небольшого размера.

Примерно такая же картина наблюдается и в контейнере с Apache.

👆 Таким образом накладные расходы на дополнительные контейнеры можно считать несущественными.

Хотели как лучше, а получилось как всегда…

Эта поучительная история случилась с одной очень дружественной нам фирмой. Бухгалтерия на аутсорсе, пять рабочих мест, около 70 баз 1С:Предприятие. Из них реально горячих – 5-10, остальные так – отчетность сдать.

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

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

Но очень скоро, где-то на переносе 25-30 базы сервер стал колом. Причина – 100% загрузка диска. Так как баз много и места им тоже надо много, то их разместили на HDD, мол какая там нагрузка, один человек и то не постоянно…

Но беда… Ладно, пошли купили SSD, отпустило, но в потолок уперся процессор и оперативка.

😡 Что за @#@$@%!!!

Все просто – регламентные задания. У типовой 1С:Бухгалтерия из коробки они очень неоптимальные, и мы рассказывали, как с ними бороться в нашей статье:

✅ Почему тормозит 1С. Регламентные задания

Но на этом дело не закончилось. С диском и процессором разобрались, но вот как быть с ОЗУ?

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

А в клиент-серверной системе каждая база будет запускать регламентные задания, надо оно вам или не надо и все это требует ресурсов. А баз у вас 70, хотя из них 50 – холодные.

Менять серверную платформу? Стоит денег. Как быть?

А просто разобраться. Горячие базы выносим на сервер. Там им самое место. Все быстро, все довольны. А холодные оставляем в файловом варианте и публикуем через веб-сервер, это означает что серверный код будет быстро выполняться на сервере.

А клиентский – на клиенте, но для этого надо использовать тонкий клиент через веб.

В общем мы местного падавана направили и поправили, после чего снова стало все хорошо.

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

​​Разделяй и властвуй

И снова про нашу родную 1С, точнее про сервер 1С:Предприятие, который в наш век виртуализации и контейнеризации с завидным упорством продолжают устанавливать и настраивать монолитом, особенно на платформе Linux.

Вина в этом во многом связана с массой материалов в сети, где эта тема именно так и подается, без разбора на составляющие и пояснений. Мол выполни шпаргалку – получишь результат.

Надо ли говорить, что рано или поздно подобное творчество приходится разбирать и перенастраивать. Почему? Этих почему много и ниже мы их коснемся.

▫️ Начнем с самого сервера 1С:Предприятие, в платформе ПРОФ разработчики фактически забрали у пользователя практически все инструменты управления памятью и сервер будет работать с параметрами по умолчанию.

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

Часто в статьях про виртуализацию советуют выносить в отдельную виртуалку Сервис лицензирования. Но перед тем, как это сделать нужно хорошо подумать.

Локальная серверная лицензия позволяет запустить неограниченное количество экземпляров сервера на узле. При использовании Сервиса лицензирования: один экземпляр – одна лицензия.

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

▫️ СУБД, а наших реалиях это будет все чаще Postgres, но практически все нижесказанное будет справедливо и для MS SQL.

Это второй кандидат на отселение, так как вы не подружите СУБД и сервер 1С:Предприяите по памяти на уровне лицензии ПРОФ.

Для Postgres вообще рекомендуется разносить сервера СУБД по принципу: 1 база – 1 инстанс. Это связано как с возможностью тонкого тюнинга СУБД под нагрузку, так и с особенностями резервного копирования и восстановления Postgres.

Но в любом случае, вне зависимости от СУБД, разделяйте инстансы для рабочих баз, тестовых и архивных. Архивные – это базы прошлых лет, которые бухгалтера любят держать для «зайти посмотреть».

▫️ Веб-сервер, самое интересное, потому что в каждой инструкции он есть и нигде не рассказывается зачем и почему, просто ставим м все тут. А потом удивляемся.

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

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

В клиент-серверном варианте веб-сервер обработкой запросов не занимается и просто проксирует их серверу 1С:Предприятие, поэтому ресурсов много не потребуется.

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

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

Из этих же соображений веб-сервер работающий наружу лучше выделять в отдельную виртуальную машину и не публиковать там ничего лишнего.

Для популярных ныне веб и HTTP-сервисов также используйте отдельный веб-сервер, опять-таки исходя из соображений обслуживания и безопасности.

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

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

​​1С, Linux и виртуализация

Буквально на днях коллега попросил рассказать нас как мы работаем с на платформе виртуализации Proxmox.

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

Центром всей этой системы является сервер 1С:Предприятия, который лицензируется отдельно на каждый запущенный экземпляр, стоимость лицензии составляет 95 000 руб., что не располагает к маневрам по разделению серверов и т.п.

Но не стоит сбрасывать со счетом Сервер-Мини за 15 500 руб. разрешающий пять сеансов к расположенным на нем информационным базам. Его можно использовать для вынесения на него ресурсоемких баз с малым количеством пользователей (например, ЗуП) или служебных баз для выполнения разного рода обменов и прочего регламента.

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

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

Сколько места выделить под контейнер? Много не нужно, там будет храниться серверный кеш, индексы и журналы, не считая временных файлов. Все это можно посмотреть на живой базе. Если не знаете – 1,5 – 2 размера ИБ, в случае чего всегда сможете откорректировать.

Следующий важный компонент – СУБД, мы используем бесплатную версию PostgreSQL от компании PostgresPRO. Также можно использовать сборку от 1С, но версия от PostgresPRO имеет репозиторий и получает обновления, что является более предпочтительным.

Ведущие специалисты по Postgres для 1С, такие как Антон Дорошкевич, рекомендуют выделять под одну базу один контейнер. И в этом есть смысл.

Во-первых, вы можете выделить каждой базе собственный набор ресурсов, за которые ей не придется конкурировать. Во-вторых, вы можете настроить сервер СУБД с учетом реальных потребностей конкретной базы, а не искать компромисс между различными базами с различным характером использования.

Как минимум разнесите на разные сервера СУБД различные конфигурации 1С, Бухгалтерию на один, Зарплату на второй, Торговлю на третий.

В этих целях следует создать готовый шаблон контейнера с уже установленной СУДБ и быстро разворачивать экземпляры по необходимости.

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

Третий компонент – веб-сервер для публикации баз или веб-сервисов. Это дополнительный способ доступа и разворачивается он также по принципу: одна база – один веб-сервер, веб-сервисы публикуются отдельно.

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

Что из этой схемы бекапится? В первую очередь сервер СУБД, частота выбирается исходя из допустимой потери информации. Потеря СУБД – потеря всех расположенных на них информационных баз 1С.

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

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

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

​​KISS (Keep it simple stupid, «не усложняй, придурок»)

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

Когда в сети на 5-7 узлов встречаешь ActiveDirectory, развернутую на единственном сервере, там же еще крутится 1С, СУБД и всякое прочее – берет оторопь.

Причем никакой виртуализацией там не пахнет, потому что виртуализация – это сложно.

А насколько просто будет поддерживать и сопровождать этого монстрика Франкенштейна – никто и не думает.

Если заглянуть в набор правил брандмауэра, то мы увидим там кучу правил с заковыристыми критериями, типа TCP-флагов и прочего, чего сам коллега и толком пояснить не может.

На вопрос: «зачем?»

Поясняют, что: «Защита от сетевых атак»

На следующий вопрос: «А вас кто-то атакует?» тоже остается без ответа.

По имеющимся сообщениям, акроним был придуман Кларенсом Джонсоном, ведущим инженером Lockheed Skunk Works, когда Джонсон вручил команде инженеров-авиаконструкторов набор инструментов, поставив им условие: механик среднего уровня должен суметь отремонтировать реактивный самолёт, который они проектировали, в полевых условиях только с этими инструментами.

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

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

А аппаратные ресурсы для этого способен предоставить любой бытовой ПК среднего уровня.

Еще одно полезное новшество в Proxmox 9

На графике расхода памяти теперь показывается доступная память и ZFS ARC, последнее крайне полезно для тех, кто просто поставил Proxmox, подключил ZFS-хранилище, но ни стал ни читать, ни разбираться.

А потом – ой, а где это вся моя оперативная память? И почему OOM-killer отстреливает мои виртуальные машины?

✅ Прочитать подробнее можно здесь: https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html

Недорогие процессоры Intel Jxxx и Proxmox

Сегодня некоторые читатели, глядя на выложенный нами скриншот с удивлением спрашивали, а серьезно ли это у нас Proxmox крутится на Celeron J3455?

Да, серьезно. Да, в продакшене. Но зачем? Не везде нужна вычислительная мощность, часто бывает просто надо уплотнить размещение сетевых служб, не предполагающих высокой нагрузки. В нашем случае это УТМ ЕГАИС, которые можно установить в количестве 1 единицы на 1 хост. Да, виртуализировать ее официально запрещено, но что прикажете делать, если у вас крупная сеть? Искать 10-20-30 отдельных ПК?

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

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

Пассивное охлаждение на CPU, внешний блок питания, компактный mini-ITX корпус и вот у вас бесшумный, не требующий обслуживания ПК, при этом вы уплотняете не только сервисы, но и физическое размещение за счет предельной компактности.

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

А теперь по моделям. Процессоры линеек J3000/J4000 – это уже устаревшая, но не утратившая актуальности платформа. Скажем так – неплохой выбор для экономных. Производительности вполне хватает, потребление небольшое, цена – приемлемая.

Старшую линейку J5000/J6000 покупать сегодня нет никакого экономического смысла, эти модели не стоят своих денег. Все дело в том, что сейчас на рынке широко представлены модели нового семейства N100, которое превосходит своих предшественников на голову.

Данный процессор по вычислительной мощности примерно равен Core i5 4-го поколения и это не только маркетинговые заявления, мы лично тестировали и те и другие системы и вполне согласны с этим определением.

Поэтому если хотите недорого, но сердито – смотрите на серию N100, там также доступны платы с пассивным охлаждением, цена таких плат формата mini-ITX на сегодня варьируется от 11 000 руб. до 15 000 руб., плюс-минус.

Полностью собрать компактный блок выйдет в 20 - 25 тыс. руб. Если взять J3000/J4000, то там платы доступны по 7 – 8 тыс. рублей, что позволит еще немного сэкономить.

При этом, если брать современные платы, то у вас будет 1 M.2 NVMe, 2 SATA и один или два слота под память, до 16 ГБ, плюс один PCIe x4.

Для обрисованного нами круга задач вполне достаточно. Плюс есть вариативность по памяти и накопителям. Чем не мини-сервер или домашняя лаборатория?

Но можно пойти другим путем и еще немного сэкономить денег купив готовый неттоп. Модели на N100 в рознице стоят в районе 15 000 руб. Это готовый ПК с памятью и накопителем. А если поискать на Озоне или других маркетплейсах, то можно найти китайцев от 7 – 8 тыс. руб.

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

В минусы – низкая возможность расширения и шумный вентилятор под нагрузкой. Зато – предельная компактность и экономия.

Еще более радикально можно сэкономить, купив на Авито старый неттоп с J1900. Это очень старый процессор, но очень удачный и по производительности он даже превосходит младшие J3000, но уступает по энергоэффективности.

Готовый неттоп с ним сейчас можно найти за 5 000 руб. Правда память там будет DDR3 и только SATA. Но как домашний гипервизор начального уровня он будет работать отлично, и полностью бесшумно.

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