Привет, Хабр! Меня зовут Николай Араловец, я эксперт по облачным технологиям в #CloudMTS.
Периодически я общаюсь с заказчиками, которые либо уже перенесли 1С в облако самостоятельно, либо только собираются это сделать. У каждого такого заказчика возникают свои сложности:
В этой статье я хочу рассказать, на что стоит обратить внимание при переносе 1С на площадку провайдера, поделиться рекомендациями по сайзингу и дать советы, которые позволят сделать работу приложения максимально эффективной.
Поясню сразу: материал будет полезен для компаний, которые планируют размещать базы данных и приложения 1С в облаке.
Пул задач зависит от того, на каком этапе переноса 1С в облако находится заказчик. Мы по отдельности рассмотрим проблемы тех, кто только собирается переезжать, и тех, кто уже разместил 1С на площадке провайдера.
Сперва поговорим о нюансах, которые важно учесть при миграции в облако. В первую очередь, необходимо определиться с IaaS-провайдером и решить вопрос сайзинга.
Для начала стоит узнать, какое физическое оборудование (compute node) использует сервис-провайдер и какие варианты его использования доступны. Для крупной инсталляции 1С (несколько сотен пользователей) оптимальным будет вариант размещения в выделенном вычислительном кластере, где используются серверы с высокочастотными процессорами (от 3 ГГц на ядро) и есть возможность выдать требуемый объем оперативной памяти на одну ВМ. На режим Intel Turbo Boost советую внимания не обращать: в виртуальной среде поведение гипервизора и ВМ на оборудовании с этой активированной опцией сильно отличается от поведения на bare-metal серверах.
Обязательно уточните, какие именно процессоры используются в серверах. Зачем это нужно? Например, в ряде конфигураций приложение и базу данных рекомендуется размещать на одной ВМ. Поэтому для нагруженной базы данных (MS SQL, PostgreSQL) может потребоваться определенное количество vCPU (более 4 vCPU) и оперативной памяти (от 64 Гб). Конечно, провайдер может предложить процессоры с тактовой частотой 3.8 ГГц на ядро — например, Intel® Xeon® Gold 5222. Однако у них всего по 4 ядра на сокет, поэтому есть риск, что у вас просто не получится выдать достаточное количество ядер и оперативной памяти машине, на которой будет работать связка «приложение 1С + СУБД». Очевидно, что это негативно отразится на общей производительности решения.
Как правило, наиболее популярный способ организации облачного хранилища у любого провайдера — общие хранилища (shared storage). Они могут быть реализованы на базе различных технологий — как проприетарных, так и с открытым кодом. Однако заказчик в любом случае должен понимать, что:
Если вариант с использованием shared storage не подходит, уточните, какие варианты может предложить сервис-провайдер — например, проброс дисковых объемов напрямую в гостевую ОС для уменьшения накладных расходов на виртуализацию дисковой подсистемы и снижения времени отклика. Либо рассмотрите возможность использования выделенного хранилища, но по понятным причинам стоимость такого решения может быть существенно выше базовой облачной конфигурации.
Для правильного сайзинга перед выбором вариантов где будут размещаться виртуальные машины соберите статистику по счетчикам дисковой подсистемы на серверах СУБД и базы данных на on-prem сайте. Это можно сделать самостоятельно — есть общедоступные инструменты для этого. Например, встроенный в Windows Server Performance Monitor со множеством счетчиков (disk, CPU, memory). Кроме этого я могу порекомендовать портал Live Optics — он предоставляет отчеты по нужным показателям производительности, в том числе и по дисковой подсистемы. Если возникнут сложности, не стесняйтесь обращаться к провайдеру: например, мы в #CloudMTS всегда готовы помочь со сбором нужных данных.
Безусловно, можно запросить выделенную конфигурацию аппаратного сервера с локальными NVMe дисками. Но будет ли она иметь отношение к облаку — вопрос.
При развертывании терминального сервера для доступа к 1С, производительность всей системы будет напрямую зависеть от доступности и пропускной способности канала между офисом/складом/магазином и облаком.
Тест Гилева может выдавать отличные результаты на виртуальной машине внутри облака. Но какой в них смысл, если время выполнения операций деградирует из-за проблем на стороне сети?
Чтобы избежать проблем, выбирайте провайдера с независимыми аплинками от двух поставщиков. Это можно сделать, например, проверив анонсы подсети провайдера через RIPE.
Далее подберите и как следует протестируйте ширину каналов между облаком и внутренней инфраструктурой (при больших расстояниях могут потребоваться корректировки TCP-параметров на уровне точек терминации трафика) и проверьте, что потери на канале не влияют на скорость.
Запрашивать сразу широкий канал смысла не имеет: по моему опыту, 9 из 10 заказчиков, которые запросили канал в 1 Гбит/c, не использовали его пропускную способность даже на 25%.
Доступность приложения и БД может быть реализована различными способами. На мой взгляд, наиболее правильный вариант — реализовать доступность на уровне приложения и/или БД с помощью кластеризации, always-on и прочих репликаций. Тем не менее, стоит уточнить у сервис-провайдера, какие механизмы отказоустойчивости присутствуют в облаке «by design» и как их можно использовать для повышения доступности.
В частности, это касается дисковой подсистемы. Ее простой может привести к длительной недоступности сервиса или потере данных. Например, если заказчик хранит данные на локальных дисках сервера без резервирования оборудования, при выходе сервера из строя, простой может измеряться часами или даже днями.
Другая ситуация — когда среда виртуализации не предоставляет механизмов автоматического перезапуска виртуальной машины на соседнем хосте в кластере, что также может увеличить время простоя. Сервис-провайдер, строящий свою инфраструктуру по определенным принципам, не будет скрывать ее параметры и особенности от заказчика. Наоборот, взаимодействие с технической службой провайдера позволит оптимальным образом использовать те возможности, которые он заложил в свою инфраструктуру. И сделать это еще на этапе внедрения.
Подводя итог, обозначу ключевые параметры облака, на которые необходимо обратить внимание при базовом сайзинге:
Мой опыт работы (8 лет на различных позициях) в облачном сервис-провайдере показывает: если заказчик переносит данные без проработанного сайзинга и учета специфики облачной инфраструктуры, то у него рано или поздно возникнут сложности. Давайте посмотрим, в чем прячется «корень зла» и как устранить уже появившиеся проблемы.
Увы, многие заказчики не консультируются с сервис-провайдером по вопросам правильного сайзинга виртуальных машин и допускают ошибки. К примеру, выбирают конфигурации без учета особенностей аппаратной платформы.
Каждый современный гипервизор, развернутый на x86_64 архитектуре, представляет ресурсы (CPU, memory) в виде NUMA-нод, базирующихся на сокетах. Для однопоточных приложений — а 1С именно к таким и относится — накладные расходы на переключение контекста между сокетами могут значительно влиять на производительность.
На скриншоте ниже — результаты теста Гилева для двух виртуальных машин, размещенных на одном физическом сервере с 4 сокетами по 18 ядер. Одной виртуальной машине выделено 16 vCPU (1 vCPU = 1 сокет), второй — 42 vCPU (2 сокета по 21 vCPU). Результаты говорят сами за себя:
1. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 42 vCPU, 3 GHz (2 сокета, нарушение распределения по pNUMA), 64 Gb mem.
2. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 16 vCPU, 3 GHz (16 сокетов), 64 Gb mem.
Как я уже писал выше, не стесняйтесь консультироваться со специалистами сервис-провайдера по вопросам сайзинга и настроек виртуальных машин. Как показывает практика, они могут оказывать значительное влияние на работу приложения
Тут сразу начну с примера из личной практики. Однажды к нам обратился заказчик, у которого резко упала производительность 1С: значительно увеличилось время выполнения определенных операций.
Разбирая тикет, наша служба поддержки проверила канал от офиса заказчика до его терминального сервера в облаке и выявила около 30% потерь. При этом они приходились на «последнюю милю», через которую подключен офис. После решения проблемы с каналом время выполнения операций вернулось к прежним значениям.
Думаю, приведенных выше кейсов достаточно для демонстрации того, как важно выполнить грамотный сайзинг при подготовке к миграции. Теперь я постараюсь дать советы, которые помогут не допустить ошибок на этом ответственном этапе.
Сайзинг 1С, в первую очередь, зависит от конфигурации приложения. Можно выделить три типовых конфигурации:
В первом случае для оценки скорости выполнения однопоточных задач подойдет тест Гилева. При условии проведения тестов на серверах с процессорами с частотой от 3 ГГц и выше результаты будут устраивать всех. Также в минимальной конфигурации с файловой БД приложение не требовательно к дисковым ресурсам.
Два других варианта требуют детального подхода к тестам.
Приведу пример:
Не имеет смысла проводить замеры производительности облачного хранилища (за исключением случаев, когда сервис-провайдер предоставляет в качестве хранения отдельные локальные диски) с помощью тестов, измеряющих линейные характеристики дисков — например, скорость чтения или записи при последовательной нагрузке в один поток. Полученные с их помощью результаты никак не коррелируют с реальной нагрузкой, которую генерирует база данных.
Любителям использовать для тестирования утилиту Crystal Disk Mark рекомендую брать одну из последних версий, 7.x, для тестов. В них есть возможность замерять значения в MB/s, IOPS и время отклика (latency) дисковой подсистемы для конкретного теста, а также менять параметры.
Перейдем к практическим рекомендациям, которые помогут при сайзинге.
От сервис-провайдера нужно получить следующие параметры:
Под оптимизацией настроек понимаются как параметры BIOS-серверов и гипервизора. Не могу не упомянуть «волшебный» режим TurboBoost, который так любят требовать к включению некоторые аудиторы.
В среде виртуализации есть ряд существенных отличий, которые значительно влияют на поведение этого режима. Например, его активация на уровне BIOS аппаратного сервера не означает, что тактовая частота виртуальных процессоров на уровне гостевой ОС будет отображаться как максимальная тактовая частота, заявленная для физического процессора. Более того, современные многоядерные процессоры не в состоянии выставить максимальную тактовую частоту для всех ядер одновременно, так как они ограничены параметром TDP (Thermal design power, «расчетная тепловая мощность»).
Приведу пример. На процессоре Xeon 6254 с базовой тактовой частотой 3.1 ГГц, заявленная максимальная тактовая частота — 4 ГГц. При активации режима TurboBoost на сервере с 4 процессорами 6254 и включенным режимом Power Management = High Performance, утилита esxtop без нагрузки показывает прирост не более 20% на каждое ядро. В действительности вы увидите реальный рост частоты на уровне виртуальной машины, только запустив ее на конфигурации с 1 vCPU, без какой либо сторонней нагрузки на аппаратном сервере, где размещена эта виртуальная машина. Даже если запустить эту же ВМ, например, в конфигурации с 8 vCPU, прирост частоты на каждый виртуальный процессор будет минимальным.
Ключевые показатели для СУБД — количество операций ввода/вывода в секунду и время отклика (IOPs и Latency). Оптимальным вариантом для сайзинга будет снятие замеров с текущей рабочей системы заказчика (например с помощью портала Live Optic). Расчет в этом случае будет базироваться на реальных показаниях.
Выделение локального сервера с NVMe дисками не имеет смысла. Такой подход не учитывает требования к отказоустойчивости и резервированию инфраструктуры и является избыточным в 99,9% случаев сайзинга, с которыми мы сталкивались. При необходимости мы как сервис-провайдер можем предоставить выделенный iSCSI LUN, выдаваемый напрямую в гостевую операционную систему, что позволяет снизить накладные расходы на виртуализацию.
Прежде чем запрашивать 1 Гбит/с, убедитесь, что вы реально будете использовать хотя бы 20% от этой цифры. Или включите мониторинг — это позволит оптимизировать расходы в ходе эксплуатации.
Банальные, но важные советы:
В завершение позволю себе привести ряд советов (не технических), которые помогут ускорить решение рассмотренных выше проблем.
1. Принимать активное участие в работе по тикетам, связанным с производительностью.
Конечно, можно просто написать запрос в службу поддержки и ожидать, что все проблемы будут устранены в соответствии с SLA. Однако тикеты, связанные с производительностью, почти невозможно решить без знания инфраструктуры заказчика.
На тикет заказчика, связанный с сетевыми проблемами, (пример был приведен выше в статье) у наших специалистов ушло около месяца. Этот срок можно сократить до нескольких дней — достаточно лишь контактировать с командой провайдера и следовать рекомендациям: например, использовать предлагаемые варианты диагностики.
2. Запрашивать у сервис-провайдера любую информацию, которая поможет ускорить работу сервиса.
Например, конфигурацию BIOS аппаратных серверов, на которых размещаются виртуальные машины. Настройки по умолчанию в облаке #CloudMTS таковы, что на процессорах с базовой тактовой частотой ядра в 3 ГГц при правильной конфигурации ВМ, заказчик, размещая 1С и MS SQL, получит в тесте Гилева не менее 33-35 «попугаев». Если вынести виртуальную машину в выделенный кластер, на такой же виртуальной машине при такой же частоте процессора их количество может вырасти уже до 42.
3. Постоянно анализировать быстродействие сервисов 1С в облаке
А не только когда появляется очевидная деградация. Делать это можно с помощью интегрального инструмента оценки APDEX, который даст существенно более объективную оценку быстродействия в сравнении с тестом Гилева (про APDEX можно почитать тут и тут).
Я вообще не рассматриваю тест Гилева в качестве полноценного инструмента для замера производительности в многопользовательской среде. Это инструмент оценки определенных характеристик серверного оборудования. Его показатели напрямую зависят от конфигурации железа и частоты процессора. В общем случае сравнение результатов этого теста далеко не во всех случаях поможет выявить проблемы с производительностью, которые возникают в облачной среде.
В завершение статьи я хочу отметить, что после выбора сервис-провайдера и сайзинга заказчик оказывается перед более трудной задачей — миграцией своих сервисов в облако. Например, с командой #CloudMTS можно обсудить:
Я не буду подробно расписывать процесс миграции — это тема для отдельной статьи. Хочу лишь отметить, что правильный сайзинг сделает процесс переезда в облако еще более простым и снизит количество сложностей, с которыми вы можете столкнуться. Поэтому желаю всем приятной и бесшовной миграции с минимальными даунтаймами.
А если вы планируете переносить 1С в облако, советую обратить внимание на наш специализированный хостинг. Вы можете выбрать подходящий по стоимости сегмент ресурсов, а специалисты #CloudMTS подберут оптимальную конфигурацию, настроят инфраструктуру и при необходимости помогут перенести данные. А для тех, кто работает с персональными данными, есть защищенный сегмент 152-ФЗ.
Периодически я общаюсь с заказчиками, которые либо уже перенесли 1С в облако самостоятельно, либо только собираются это сделать. У каждого такого заказчика возникают свои сложности:
- недостаток опыта при выборе аппаратной конфигурации и нужного объема ресурсов в облаке;
- как следствие, проблемы с производительностью после переноса баз данных и приложения в облако.
В этой статье я хочу рассказать, на что стоит обратить внимание при переносе 1С на площадку провайдера, поделиться рекомендациями по сайзингу и дать советы, которые позволят сделать работу приложения максимально эффективной.
Поясню сразу: материал будет полезен для компаний, которые планируют размещать базы данных и приложения 1С в облаке.
Пул задач зависит от того, на каком этапе переноса 1С в облако находится заказчик. Мы по отдельности рассмотрим проблемы тех, кто только собирается переезжать, и тех, кто уже разместил 1С на площадке провайдера.
Сложности при размещении 1С в виртуальной инфраструктуре
Сперва поговорим о нюансах, которые важно учесть при миграции в облако. В первую очередь, необходимо определиться с IaaS-провайдером и решить вопрос сайзинга.
Аппаратная конфигурация сервера в облаке
Для начала стоит узнать, какое физическое оборудование (compute node) использует сервис-провайдер и какие варианты его использования доступны. Для крупной инсталляции 1С (несколько сотен пользователей) оптимальным будет вариант размещения в выделенном вычислительном кластере, где используются серверы с высокочастотными процессорами (от 3 ГГц на ядро) и есть возможность выдать требуемый объем оперативной памяти на одну ВМ. На режим Intel Turbo Boost советую внимания не обращать: в виртуальной среде поведение гипервизора и ВМ на оборудовании с этой активированной опцией сильно отличается от поведения на bare-metal серверах.
Обязательно уточните, какие именно процессоры используются в серверах. Зачем это нужно? Например, в ряде конфигураций приложение и базу данных рекомендуется размещать на одной ВМ. Поэтому для нагруженной базы данных (MS SQL, PostgreSQL) может потребоваться определенное количество vCPU (более 4 vCPU) и оперативной памяти (от 64 Гб). Конечно, провайдер может предложить процессоры с тактовой частотой 3.8 ГГц на ядро — например, Intel® Xeon® Gold 5222. Однако у них всего по 4 ядра на сокет, поэтому есть риск, что у вас просто не получится выдать достаточное количество ядер и оперативной памяти машине, на которой будет работать связка «приложение 1С + СУБД». Очевидно, что это негативно отразится на общей производительности решения.
Хранилище в облаке
Как правило, наиболее популярный способ организации облачного хранилища у любого провайдера — общие хранилища (shared storage). Они могут быть реализованы на базе различных технологий — как проприетарных, так и с открытым кодом. Однако заказчик в любом случае должен понимать, что:
- в shared storage дисковые объемы разделяются между большим количеством потребителей;
- имеет место быть влияние нагрузки со стороны «соседей» на время отклика дисковой подсистемы и, как следствие, на производительности базы данных.
Если вариант с использованием shared storage не подходит, уточните, какие варианты может предложить сервис-провайдер — например, проброс дисковых объемов напрямую в гостевую ОС для уменьшения накладных расходов на виртуализацию дисковой подсистемы и снижения времени отклика. Либо рассмотрите возможность использования выделенного хранилища, но по понятным причинам стоимость такого решения может быть существенно выше базовой облачной конфигурации.
Для правильного сайзинга перед выбором вариантов где будут размещаться виртуальные машины соберите статистику по счетчикам дисковой подсистемы на серверах СУБД и базы данных на on-prem сайте. Это можно сделать самостоятельно — есть общедоступные инструменты для этого. Например, встроенный в Windows Server Performance Monitor со множеством счетчиков (disk, CPU, memory). Кроме этого я могу порекомендовать портал Live Optics — он предоставляет отчеты по нужным показателям производительности, в том числе и по дисковой подсистемы. Если возникнут сложности, не стесняйтесь обращаться к провайдеру: например, мы в #CloudMTS всегда готовы помочь со сбором нужных данных.
Безусловно, можно запросить выделенную конфигурацию аппаратного сервера с локальными NVMe дисками. Но будет ли она иметь отношение к облаку — вопрос.
Сеть
При развертывании терминального сервера для доступа к 1С, производительность всей системы будет напрямую зависеть от доступности и пропускной способности канала между офисом/складом/магазином и облаком.
Тест Гилева может выдавать отличные результаты на виртуальной машине внутри облака. Но какой в них смысл, если время выполнения операций деградирует из-за проблем на стороне сети?
Чтобы избежать проблем, выбирайте провайдера с независимыми аплинками от двух поставщиков. Это можно сделать, например, проверив анонсы подсети провайдера через RIPE.
Далее подберите и как следует протестируйте ширину каналов между облаком и внутренней инфраструктурой (при больших расстояниях могут потребоваться корректировки TCP-параметров на уровне точек терминации трафика) и проверьте, что потери на канале не влияют на скорость.
Запрашивать сразу широкий канал смысла не имеет: по моему опыту, 9 из 10 заказчиков, которые запросили канал в 1 Гбит/c, не использовали его пропускную способность даже на 25%.
Механизмы отказоустойчивости
Доступность приложения и БД может быть реализована различными способами. На мой взгляд, наиболее правильный вариант — реализовать доступность на уровне приложения и/или БД с помощью кластеризации, always-on и прочих репликаций. Тем не менее, стоит уточнить у сервис-провайдера, какие механизмы отказоустойчивости присутствуют в облаке «by design» и как их можно использовать для повышения доступности.
В частности, это касается дисковой подсистемы. Ее простой может привести к длительной недоступности сервиса или потере данных. Например, если заказчик хранит данные на локальных дисках сервера без резервирования оборудования, при выходе сервера из строя, простой может измеряться часами или даже днями.
Другая ситуация — когда среда виртуализации не предоставляет механизмов автоматического перезапуска виртуальной машины на соседнем хосте в кластере, что также может увеличить время простоя. Сервис-провайдер, строящий свою инфраструктуру по определенным принципам, не будет скрывать ее параметры и особенности от заказчика. Наоборот, взаимодействие с технической службой провайдера позволит оптимальным образом использовать те возможности, которые он заложил в свою инфраструктуру. И сделать это еще на этапе внедрения.
Подводя итог, обозначу ключевые параметры облака, на которые необходимо обратить внимание при базовом сайзинге:
- платформа, которую использует облачный провайдер (compute, storage, network);
- возможность разместить сервисы, критичные к производительности на выделенных ресурсах, а также стоимость этих ресурсов;
- механизмы отказоустойчивости, предоставляемые облачным провайдером «по умолчанию».
Проблемы с производительностью 1С в облаке
Мой опыт работы (8 лет на различных позициях) в облачном сервис-провайдере показывает: если заказчик переносит данные без проработанного сайзинга и учета специфики облачной инфраструктуры, то у него рано или поздно возникнут сложности. Давайте посмотрим, в чем прячется «корень зла» и как устранить уже появившиеся проблемы.
Ошибки сайзинга
Увы, многие заказчики не консультируются с сервис-провайдером по вопросам правильного сайзинга виртуальных машин и допускают ошибки. К примеру, выбирают конфигурации без учета особенностей аппаратной платформы.
Каждый современный гипервизор, развернутый на x86_64 архитектуре, представляет ресурсы (CPU, memory) в виде NUMA-нод, базирующихся на сокетах. Для однопоточных приложений — а 1С именно к таким и относится — накладные расходы на переключение контекста между сокетами могут значительно влиять на производительность.
На скриншоте ниже — результаты теста Гилева для двух виртуальных машин, размещенных на одном физическом сервере с 4 сокетами по 18 ядер. Одной виртуальной машине выделено 16 vCPU (1 vCPU = 1 сокет), второй — 42 vCPU (2 сокета по 21 vCPU). Результаты говорят сами за себя:
1. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 42 vCPU, 3 GHz (2 сокета, нарушение распределения по pNUMA), 64 Gb mem.
2. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 16 vCPU, 3 GHz (16 сокетов), 64 Gb mem.
Как я уже писал выше, не стесняйтесь консультироваться со специалистами сервис-провайдера по вопросам сайзинга и настроек виртуальных машин. Как показывает практика, они могут оказывать значительное влияние на работу приложения
Проблемы на канале связи
Тут сразу начну с примера из личной практики. Однажды к нам обратился заказчик, у которого резко упала производительность 1С: значительно увеличилось время выполнения определенных операций.
Разбирая тикет, наша служба поддержки проверила канал от офиса заказчика до его терминального сервера в облаке и выявила около 30% потерь. При этом они приходились на «последнюю милю», через которую подключен офис. После решения проблемы с каналом время выполнения операций вернулось к прежним значениям.
Особенности сайзинга 1С
Думаю, приведенных выше кейсов достаточно для демонстрации того, как важно выполнить грамотный сайзинг при подготовке к миграции. Теперь я постараюсь дать советы, которые помогут не допустить ошибок на этом ответственном этапе.
Сайзинг 1С, в первую очередь, зависит от конфигурации приложения. Можно выделить три типовых конфигурации:
- минимальная конфигурация на несколько рабочих мест (1-10), файловая база данных;
- средняя конфигурация на 10-50 пользователей (бухгалтерия, склад, продажи), SQL база данных;
- крупная конфигурация на 100+ рабочих мест, SQL база данных, терминальный доступ к приложению, etc.
В первом случае для оценки скорости выполнения однопоточных задач подойдет тест Гилева. При условии проведения тестов на серверах с процессорами с частотой от 3 ГГц и выше результаты будут устраивать всех. Также в минимальной конфигурации с файловой БД приложение не требовательно к дисковым ресурсам.
Два других варианта требуют детального подхода к тестам.
- Прогон тестов Гилева покажет, оптимизированы ли настройки аппаратных серверов под приложение 1С.
- Счетчики производительности на серверах 1С и MS SQL заказчика (CPU, Memory, physical disks, MS SQL) позволят оценить текущую нагрузку на различные подсистемы и спроецировать ее в облако.
- Замеры производительности дисковой подсистемы в облаке можно выполнить с помощью diskspd, iometer, fio. Все эти утилиты доступны под Windows Server. Основная задача — определить время отклика (параметр Latency) и количество операций в секунду (IOPS), которые напрямую влияют на время выполнения операций в SQL СУБД. Потоковая скорость (bandwidth, Мб/с) в случае с нагрузкой, генерируемой базой данных, является произведением количества IOPS на размер блока каждой отдельной операции ввода/вывода. Поэтому этот параметр не является критичным для определения соответствия дисковой подсистемы требованиям со стороны приложения и СУБД.
Приведу пример:
- Размер блока операции чтения/записи, которым оперирует MS SQL сервер, может варьироваться от 512 байт до 8 Мбайт (в зависимости от выполняемых операций).
- При размере блока в 4 Кбайт и 1000 операций ввода/вывода в секунду мы получаем скорость потока данных — 4 Мб/с.
- При размере блока в 1 Мбайт и 1000 операций ввода/вывода в секунду мы получаем скорость потока данных — 1 Гб/с.
Не имеет смысла проводить замеры производительности облачного хранилища (за исключением случаев, когда сервис-провайдер предоставляет в качестве хранения отдельные локальные диски) с помощью тестов, измеряющих линейные характеристики дисков — например, скорость чтения или записи при последовательной нагрузке в один поток. Полученные с их помощью результаты никак не коррелируют с реальной нагрузкой, которую генерирует база данных.
Любителям использовать для тестирования утилиту Crystal Disk Mark рекомендую брать одну из последних версий, 7.x, для тестов. В них есть возможность замерять значения в MB/s, IOPS и время отклика (latency) дисковой подсистемы для конкретного теста, а также менять параметры.
Рекомендации по сайзингу 1С в облаке
Перейдем к практическим рекомендациям, которые помогут при сайзинге.
Выбор аппаратных конфигураций под размещение сервисов 1С
От сервис-провайдера нужно получить следующие параметры:
- откуда выдаются ресурсы (CPU, memory);
- базовая тактовая частота процессора;
- объем оперативной памяти на аппаратный сервер в пуле;
- предоставляет ли сервис-провайдер выделенный пул серверов, настройки которых оптимизированы под 1с.
Под оптимизацией настроек понимаются как параметры BIOS-серверов и гипервизора. Не могу не упомянуть «волшебный» режим TurboBoost, который так любят требовать к включению некоторые аудиторы.
В среде виртуализации есть ряд существенных отличий, которые значительно влияют на поведение этого режима. Например, его активация на уровне BIOS аппаратного сервера не означает, что тактовая частота виртуальных процессоров на уровне гостевой ОС будет отображаться как максимальная тактовая частота, заявленная для физического процессора. Более того, современные многоядерные процессоры не в состоянии выставить максимальную тактовую частоту для всех ядер одновременно, так как они ограничены параметром TDP (Thermal design power, «расчетная тепловая мощность»).
Приведу пример. На процессоре Xeon 6254 с базовой тактовой частотой 3.1 ГГц, заявленная максимальная тактовая частота — 4 ГГц. При активации режима TurboBoost на сервере с 4 процессорами 6254 и включенным режимом Power Management = High Performance, утилита esxtop без нагрузки показывает прирост не более 20% на каждое ядро. В действительности вы увидите реальный рост частоты на уровне виртуальной машины, только запустив ее на конфигурации с 1 vCPU, без какой либо сторонней нагрузки на аппаратном сервере, где размещена эта виртуальная машина. Даже если запустить эту же ВМ, например, в конфигурации с 8 vCPU, прирост частоты на каждый виртуальный процессор будет минимальным.
Сайзинг дисковой подсистемы
Ключевые показатели для СУБД — количество операций ввода/вывода в секунду и время отклика (IOPs и Latency). Оптимальным вариантом для сайзинга будет снятие замеров с текущей рабочей системы заказчика (например с помощью портала Live Optic). Расчет в этом случае будет базироваться на реальных показаниях.
Выделение локального сервера с NVMe дисками не имеет смысла. Такой подход не учитывает требования к отказоустойчивости и резервированию инфраструктуры и является избыточным в 99,9% случаев сайзинга, с которыми мы сталкивались. При необходимости мы как сервис-провайдер можем предоставить выделенный iSCSI LUN, выдаваемый напрямую в гостевую операционную систему, что позволяет снизить накладные расходы на виртуализацию.
Ширина канала
Прежде чем запрашивать 1 Гбит/с, убедитесь, что вы реально будете использовать хотя бы 20% от этой цифры. Или включите мониторинг — это позволит оптимизировать расходы в ходе эксплуатации.
Конфигурация виртуальных машин
Банальные, но важные советы:
- Выбор количества vCPU в соответствии с аппаратной конфигурацией сервера (выравнивание по pNUMA, нужно уточнять у сервис-провайдера) оптимален, когда ВМ может разместится в одном pNUMA домене (все vCPU размещаются на одном физическом сокете). Если требуется большее количество vCPU, то нужно следовать рекомендациям сервис-провайдера.
- Отключайте все feature вида «cpu hot-add» и «memory hot-add».
- По возможности используйте тип SCSI контроллера VMWare Paravirtual и тип сетевого адаптера VMXNET3.
- От выбора операционной системы, версии 1С и MS SQL также может зависеть производительность. Например, все тож же тест Гилева выдает отличающиеся на 5-6 «попугаев» результаты на разных платформах — Windows Server 2016 + MS SQL 2016 и Windows Server 2019 + MS SQL 2019.
- Размещайте базы данных и приложения на одной виртуальной машине.
Советы по работе с 1С в облаке
В завершение позволю себе привести ряд советов (не технических), которые помогут ускорить решение рассмотренных выше проблем.
1. Принимать активное участие в работе по тикетам, связанным с производительностью.
Конечно, можно просто написать запрос в службу поддержки и ожидать, что все проблемы будут устранены в соответствии с SLA. Однако тикеты, связанные с производительностью, почти невозможно решить без знания инфраструктуры заказчика.
На тикет заказчика, связанный с сетевыми проблемами, (пример был приведен выше в статье) у наших специалистов ушло около месяца. Этот срок можно сократить до нескольких дней — достаточно лишь контактировать с командой провайдера и следовать рекомендациям: например, использовать предлагаемые варианты диагностики.
2. Запрашивать у сервис-провайдера любую информацию, которая поможет ускорить работу сервиса.
Например, конфигурацию BIOS аппаратных серверов, на которых размещаются виртуальные машины. Настройки по умолчанию в облаке #CloudMTS таковы, что на процессорах с базовой тактовой частотой ядра в 3 ГГц при правильной конфигурации ВМ, заказчик, размещая 1С и MS SQL, получит в тесте Гилева не менее 33-35 «попугаев». Если вынести виртуальную машину в выделенный кластер, на такой же виртуальной машине при такой же частоте процессора их количество может вырасти уже до 42.
3. Постоянно анализировать быстродействие сервисов 1С в облаке
А не только когда появляется очевидная деградация. Делать это можно с помощью интегрального инструмента оценки APDEX, который даст существенно более объективную оценку быстродействия в сравнении с тестом Гилева (про APDEX можно почитать тут и тут).
Я вообще не рассматриваю тест Гилева в качестве полноценного инструмента для замера производительности в многопользовательской среде. Это инструмент оценки определенных характеристик серверного оборудования. Его показатели напрямую зависят от конфигурации железа и частоты процессора. В общем случае сравнение результатов этого теста далеко не во всех случаях поможет выявить проблемы с производительностью, которые возникают в облачной среде.
В завершение статьи я хочу отметить, что после выбора сервис-провайдера и сайзинга заказчик оказывается перед более трудной задачей — миграцией своих сервисов в облако. Например, с командой #CloudMTS можно обсудить:
- планирование миграции из инфраструктуры заказчика в облако с учетом всех вышеперечисленных особенностей;
- проработку изменений в архитектуре с учетом особенностей облака;
- помощь в мониторинге ключевых параметров после миграции.
Я не буду подробно расписывать процесс миграции — это тема для отдельной статьи. Хочу лишь отметить, что правильный сайзинг сделает процесс переезда в облако еще более простым и снизит количество сложностей, с которыми вы можете столкнуться. Поэтому желаю всем приятной и бесшовной миграции с минимальными даунтаймами.
А если вы планируете переносить 1С в облако, советую обратить внимание на наш специализированный хостинг. Вы можете выбрать подходящий по стоимости сегмент ресурсов, а специалисты #CloudMTS подберут оптимальную конфигурацию, настроят инфраструктуру и при необходимости помогут перенести данные. А для тех, кто работает с персональными данными, есть защищенный сегмент 152-ФЗ.
