Вопрос о том, стоит ли разносить компоненты системы 1С (сервер приложений и сервер баз данных) по разным виртуальным машинам на одном физическом сервере, является одним из самых дискуссионных в среде системных администраторов и специалистов по внедрению. С одной стороны, мы стремимся к максимальной производительности, с другой — к гибкости управления ИТ-инфраструктурой. В этой статье мы подробно проанализируем ситуацию, разберем технические нюансы и выясним, как добиться оптимального результата.
Рассмотрим классический вариант, когда и Сервер 1С:Предприятие, и MS SQL Server установлены непосредственно на операционную систему физического сервера. Это решение часто выбирают те, для кого критически важна скорость работы системы.
Преимущества использования «железа»:
Однако у этого подхода есть существенный минус: отсутствие гибкости. Если сервер выйдет из строя или потребуется миграция на другое оборудование, процесс восстановления будет долгим и трудоемким.
Разберем стратегию, которую часто предлагают системные администраторы: создание двух отдельных виртуальных машин (одна для 1С, другая для SQL) на одном гипервизоре.
Почему администраторы выбирают этот путь:
Администрирование виртуальных сред значительно проще. Мы получаем возможность делать снимки системы (снапшоты) перед важными обновлениями, легко перемещать машины между хостами в кластере и изолировать ресурсы. Если менеджер кластера 1С (rmngr) «зависнет» и начнет потреблять все доступные ресурсы процессора, это не приведет к полной остановке SQL-сервера, так как лимиты будут жестко заданы на уровне гипервизора.
Но за это приходится платить производительностью:
Проанализируем ситуацию с сетевым взаимодействием. При разносе по разным ВМ протокол Shared Memory становится недоступен. Обмен данными будет происходить через виртуальный сетевой стек по протоколу TCP/IP. Даже при наличии виртуальных 10-гигабитных адаптеров задержки будут выше, чем при обмене через память. В высоконагруженных системах это может привести к падению общей производительности на 10–20%.
Выясним причину, по которой многие пользователи жалуются на «жуткие тормоза» в виртуальной среде. Современные серверы имеют многопроцессорную архитектуру NUMA (Non-Uniform Memory Access). Это означает, что у каждого процессора есть «своя» оперативная память, к которой он обращается быстрее всего.
Если при создании виртуальной машины выделить ей ресурсы, превышающие объем одного узла NUMA (например, назначить 16 ядер, когда на одном физическом процессоре всего 8), гипервизор будет вынужден обращаться к памяти «чужого» процессора. Это вызывает катастрофические задержки.
Рекомендация по настройке:
Спроектируйте виртуальную машину так, чтобы она целиком помещалась в рамках одного физического сокета и его локальной памяти. В настройках гипервизора (VMware ESXi или Hyper-V) необходимо проверить параметры Affinity и убедиться, что топология NUMA пробрасывается внутрь виртуальной машины корректно.
Проанализируем работу дисков, так как 1С крайне чувствительна к скорости записи логов транзакций SQL. Виртуализация добавляет слой абстракции, который может создавать микрозадержки.
Рассмотрим правила настройки дисков для 1С и SQL:
tempdb на разные виртуальные диски, которые, в свою очередь, должны располагаться на разных физических RAID-массивах или LUNах.Часто причиной низкой скорости 1С в виртуалке является работа функций энергосбережения. Процессор динамически снижает частоту, что губительно для однопоточных операций 1С.
Посмотрим, что нужно сделать:
Если вы хотите получить преимущества виртуализации (удобство бэкапа и миграции), но не готовы жертвовать скоростью из-за отказа от Shared Memory, рассмотрим вариант одной мощной виртуальной машины.
В этом случае на гипервизор устанавливается одна ОС, внутри которой разворачиваются и 1С, и SQL. Мы сохраняем возможность использования Shared Memory, минимизируем накладные расходы на содержание второй ОС и при этом сохраняем все плюсы виртуального образа (миграция, снимки). Это наиболее сбалансированное решение для большинства компаний.
Не забудем про вопрос защиты. Если вы используете программные лицензии, помните, что при изменении параметров виртуальной машины (например, добавление оперативной памяти или переезд на другой хост) лицензия может «слететь».
Для аппаратных ключей USB потребуется использование специальных USB-концентраторов (USB-over-IP), так как стандартные средства проброса портов в гипервизорах иногда работают нестабильно при высокой нагрузке на ключ.
Подведем итоги нашего анализа. Выбор между физическим сервером и виртуальной машиной — это всегда компромисс.
Выбирайте физический сервер, если:
Выбирайте виртуализацию, если:
Помните: «из коробки» виртуальная машина всегда будет медленнее физического сервера. Но при грамотной настройке эта разница сокращается до незначительных 3-5%, которые с лихвой компенсируются удобством эксплуатации.