Настройка vmware esxi для 1с

Обновлено: 04.07.2024

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

Вы используете виртуализацию, и при этом у вас наблюдаются проблемы с производительностью общесистемного характера? Специально для этого варианта мы разработали услугу по анализу виртуальной машины сервера 1С.
Именно при использовании виртуализации есть возможность за небольшую сумму (26 000 рублей) получить помощь специалиста с большим опытом и увеличить производительность виртуальной машины с 1С и СУБД.

В каких случаях вам нужна эта услуга:

Что вы получаете:

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

Стоимость работ: 26 000 рублей

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

Шаблон договоря для ознакомления можно скачать по ссылке.

Богомаз Кирилл Олегович, Диагностические Решения:

Конев Андрей Анатольевич, Инвестгеосервис:

Долгих Валерий, Лебедяньмолоко:

Дрейгер П.Г., Сегежа Групп:

Смагин Павел Александрович, Руфарма:

1. Удаленные рабочие места пользователей (терминальный сервер)
2. Веб-сервера сайтов
3. Учебный сервер для проведения курсов
4. Веб-сервисы 1С НЕ КРИТИЧНЫЕ к нагрузке

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

Причины замедлений

Симуляция железа кодом всегда была медленней работы реального железа.
Изначально виртуализация была только на программном уровне и плюсы виртуализации нивелировались существенным замедлением работы в виртуальной среде. Частично вопрос получилось решить аппаратно — вендоры разработали инструкции процессоры Intel VT-d , AMD-V и т.п. для ускорения работы. Однако память и процессор это не единственные компоненты, есть также видеокарта, жесткие диски и т.п. и от реализации доступа к ним напрямую зависит скорость операций. Т.е. в зависимости от производителя виртуальной машины, драйверов от производителя оборудования, от умения конечного ПО распознавать виртуализацию по-прежнему скорость работы зависит значительно.

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

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

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

Рейтинг облачных провайдеров

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

2. Использовать только физические диски под данные, а не виртуальные.

4. Передача по сети между двумя виртуальными машинами на одной физической машине медленней протокола Shared Memory

5. Функции динамического перераспределения ресурсов между несколькими виртуальными машинами увеличивают возможности по ресурсам, но само перераспределение также вносит замедление. Для 1С рекомендуется выключать такие функции. Если стоит динамическое распределение ресурсов, также может «слететь» программная лицензия 1С.

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

Параметры Microsoft Hyper-V и VMware ESXi & vSphere

VMware ESXi & vSphere

Коллективное использование виртуалок для балансировки нагрузки
Проблема заключается в работе компонента vCenter под названием DRS (Distributed Resource Scheduler), задача которого заключается в балансировке нагрузки виртуальных машин на физические серверы.При появлении больших нагрузок по процессорным мощностям или по загрузке ОЗУ, DRS мигрирует виртуальную машину на другой физический хост, наименее загруженный в данный момент; в кульминации данного процесса возникают кратковременные проблемы с доступом к ресурсам этой VM.

ОПЕРАТИВНАЯ ПАМЯТЬ

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

В старых версиях

Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.

После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):

ПРОЦЕССОР

Иногда при использовании интерфейса типа WMXNET3 могут возникать проблемы по производительности, в этом случае для виртуальных серверов ESXi 6.0 с 1с сервером не используйте сетевые интерфейсы типа WMXNET3, использовать тип e1000e.

ДРАЙВЕРА

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

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

Проверка VMware Tools

Выберите хост в vClient;
Перейдите на вкладку Virtual Machines;
Добавьте столбец «VMware Tools Status»;
Оцените статус. OK->значит все хорошо, ничего делать не надо. Not Running/Out of date — устраняем.

Если VMware Tools не запущены, необходимо разбираться с гостевой операционной системой. Причина может скрываться в обновлении ядра Linux либо отключенной (кем-то) службе VMware Tools в Windows.

Если VMware Tools устарели, необходимо их обновить из контекстного меню vClient. Как правило, это случается после установки обновлений на хосты ESX/ESXi. После этого зачастую требуется обновить и VMware Tools.

ДИСКИ

Independent Persistent Mode vmdk-диска — наиболее производительный, поскольку изменения вносятся сразу на диск, не журналируясь. Но такой диск не подвержен снапшотам, его нельзя откатить.
При использовании iSCSI рекомендуется настроить jumbo frames (MTA=9000) на всех интерфейсах и сетевом оборудовании.
MultiPathing — для большинства случаев RoundRobin — ОК. Fixed может дать большую производительность, но это после вдумчивого планирования и ручной настройки каждого хоста до каждого LUN. MRU можно поставить при active-passive конфигурации, если какие-то пути время от времени пропадают — чтобы не перескакивало туда-обратно.

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

На руках появился лишний сервер и вдруг почему-то очень захотелось создать виртуальную среду=) Большого опыта с виртуализацией у меня нет. С чего начать? Регимся на vmware и скачиваем образ продукта под названием Esxi (vSphere). Download completed! Теперь нужно бы сделать загрузочное устройство. Можно нарезать диск или использовать съемное устройство.

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

Интерфейс достаточно простой, главное не забыть выбрать USB Drive. Полминуты и все готово. Берем флэшку и в сервер ее. В BIOS не забываем выставить загрузку с USB – должно быть имя производителя флэшки (иногда оно начинает видится только после перезагрузки).
Если все правильно, то начнёт грузиться Installer – покомпонентно. После предложит нажать Enter и согласиться с EULA. Теперь нужно выбрать место установки, вот тут «финт ушами» и выбираем наш же USB носитель. Т.к. файлы установки уже в ОЗУ ничего страшного не произойдет. Нюанс такой, носитель берите объемом побольше, чтобы было место куда ESXi будет логи писать. Дальше по плану и НЕ забываем пароль от root. После установки ESXi попросит перезагрузиться.

Дальше надо не забыть настроить сетевой интерфейс для удаленного доступа через vsphere client или web и подключить шнур. Проверили доступность сети и идем обратно к рабочему месту. Запускаем клиента, видим хост и немного настраиваем (data stores, network) и разворачиваем win server 2012 с IP из диапазона сети управления.

Для централизованного управления VM есть такой продукт – vCenter. Попробуем установить его на виртуальный win server 2012, который уже успели развернуть на ESXi хосте. Он у нас не в домене и имеет реальный! сетевой адрес.

Что касается БД – то в инсталляторе центра есть SQL Express, однако лучше использовать полную версию. Устанавливаем SQL Server, создаем БД для vCenter, раздаем права пользователям БД. Далее запускаем вручную SQL Agent! и публикуем коннектор! к БД через эту оснастку в System DSN.

Если коннект к БД есть, то в итоге будет «TESTS COMPLETED SUCCESSFULLY».

Можно перегрузиться и начинать установку vCenter – 4 компонента, simple install:
1. Не забываем пароль админа vsphere.local.
2. Выбираем созданный выше DSN.
3. Опять запоминаем пароль админа и далее.
4. И, если у вас нет DNS, то везде пишем реальный IP, вместо имени, иначе работать ничего не будет, даже при редактировании \etc\hosts.

После установки vCenter доступен через web клиент. При соединении может поругаться на сертификат, игнорим и акксептим. Готово! Теперь с помощью vCenter можно управлять ESXi хостами, создав DataCenter, объединять их в кластер, использовать vDS для коммутации, Vlan и PVlan и т.п.

Опытным путем определено, что любая другая последовательность приводит к неработоспособности vCenter. Удачных экспериментов.

Также обращаю внимание, что проблема разбирается на конкретной модели Samsung 970 pro и VMWare 6.7. Не надо думать, что все виртуалки и все диски NVMe ведут себя одинаково и бездумно тиражировать текущий подход статьи ко всему. В каждом конкретном случае надо проходить полный путь расследования, как в статье.

Проблема с дисковой производительностью

Ситуация: сервер 1С/СУБД, на котором наблюдаются существенные проблемы с производительностью дисковой подсистемы : время обслуживания дисковых операций исчисляется не единицами миллисекунд (как хотелось бы), не десятками (как ещё допустимо), а несколькими сотнями, причём это же видно и средствами операционной системы.

Выглядит это например вот так:

Первая реакция: такие показатели характерны для загруженного механического (дефакто медленного) диска.

Первые тесты

Дожидаемся технологического окна, когда службы 1С и СУБД можно полностью остановить, нагрузку с диска снимаем, и прогоняем тест CrystalDiskMark

Результаты выглядят вполне прилично для недорогого NVMe SSD (отклик должен быть около 10 мс, а не сотнями мс как у нас). Идём выяснять, что же там “под капотом”. Выясняем, что данные расположены на неплохом (для десктопа, не для сервера) NVMe SSD Samsung 970 Pro, который хоть и не “энтерпрайз класса”, но и вот настолько проседать под такой нагрузкой вроде как не должен.

Вот нормальный результат диска на физическом сервере для сравнения.
Идём разбираться дальше: сервер развёрнут на виртуальной машине на базе VMWare ESXi 6.7, SSD используется в “виртуализованном” виде:

Из диспетчера устройств виртуальной Windows устройство видно например так:

В данном виде гостевая операционная система видит SSD как некий сетевой массив, и управлять этим SSD не может (например, не передаётся команда TRIM). И явно для данного SSD это не является “комфортным” режимом работы. Попробуем это изменить.

Вносим изменения в конфигурацию

И вот здесь наступает пора внести изменения!

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

Затем идём в консоль ESXi хост-машины, где развёрнута наша система, и делаем следующее:

Что же изменилось?

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

Теперь этот SSD надо заново отформатировать (мы использовали размер кластера 8 килобайт, так как именно таков размер страницы данных в MS SQL, а именно базы СУБД на этом диске и будут расположен).

И настала пора сравнить результаты тестов CrystalDiskMark:

Итоговый результат

Разница оказалась весьма существенной, хороший десктопный (хоть и не серверный) SSD начал работать заметно лучше.

Результаты снимков монитора ресурсов “до и после” для удобства свели в одну картинку.

Обратите внимание, насколько ускорилось время ответа дисковой подсистемы, и при этом насколько увеличились объёмы чтения и записи. Оборудование сервера по факту не изменилось, но драматически выросла его производительность!

Вывод

Как минимум в данном сценарии, использование десктопного NVMe SSD в VMWare ESXi 6.7 в виртуализованном варианте приводило к существенному ухудшению производительности SSD, при этом “формальный” тест CrystalDiskMark мог выглядеть “вполне прилично” (если не сравнивать “в лоб” с показателями ровно такого же устройства, подключенного напрямую). Подключение же NVMe SSD напрямую в виртуализованную операционную систему привело к тому, что ОС смогла управлять диском напрямую (например, подавать команды TRIM), и производительность диска увеличилась и стала больше соответствовать данной модели NVMe SSD.

Влияние виртуальных сред на производительность 1С

2. Использовать только физические диски под данные, а не виртуальные.

3. Вендоры виртуальных систем честно указывают примерный процент замедления относительно физических серверов от 9 до 24 %. Виртуалки это удобно, но не быстро. «Хочу как на физическом сервере» это пустое.

4. Передача по сети между двумя виртуальными машинами на одной физической машине медленней протокола Shared Memory

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

Microsoft Hyper-V

VMware ESXi & vSphere

Для виртуальных серверов ESXi 6.0 с 1с сервером не используйте сетевые интерфейсы типа WMXNET3, использовать только типа e1000e