Семь важных моментов, которые должны быть закреплены в SLA09.11.2023 11:01

Поставщики облачных услуг гарантируют клиенту определенные условия использования сервиса и поддержание стабильной работы, производительности облачных платформ. Такие гарантии принято обозначать как Service Level Agreement (SLA). Обычно они представляют собой специальный документ, где провайдер определяет регламент обслуживания клиента, свои обязательства, время на устранение возможных инцидентов. В документе все выглядит логично и понятно, но на деле появляется масса двусмысленностей и скрытых моментов, что может поставить клиента в невыгодное положение и нанести ему существенный ущерб. О чем не говорится в SLA поставщиком услуг и как избежать просчетов при выборе провайдера, расскажем ниже.

Производительность CPU

Вроде бы, тут все понятно: чем больше ядер, тем больше потоков, тем выше производительность. На деле же получается, что один vCPU другому — рознь, потому что у разных провайдеров разные процессоры и разное понимание vCPU. Плюс тут еще нужно учитывать потоки обработки данных, общую величину нагрузки. Для оценки этих параметров используют CPU Usage.

Если нагрузка приближается к 70–80%, это говорит о том, что vCPU близок к пиковой нагрузке, а дополнительный скачок может создать непредвиденные проблемы на стороне клиента. Оптимально, чтобы текущая нагрузка на vCPU не превышала 40–50% и оставался достаточный запас для пиковых нагрузок.

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

Для разных задач — разные ВМ

На стороне клиента может быть множество разных объектов и приложений, которые должна будет обслуживать виртуальная машина (ВМ). Любое прикладное ПО существенно различается по требованиям к IaaS, а иногда и требует специфических решений. Ввиду этого нужно подбирать ВМ индивидуально под конкретное ПО и задачи, чтобы не получилось, что в один прекрасный момент система попросту встанет.

• Для нормальной работы 1С обязательна высокая частота процессора на уровне не менее 3,5 ГГц.
• Виртуальная АТС сильно привязана к ресурсу vCPU, но менее требовательна к частоте, поэтому фактор дополнительных ядер тут обязателен.
• Полноценная и стабильная работа SAP тесно связана с таким параметром как vRAM, ее должно быть много и на гарантированной основе.
• VDI требователен к Storage, поэтому об этом нужно заранее побеспокоиться и подобрать подходящий объем.
• Стабильность работы СУБД связана с настройками vCPU в составе ВМ и взаимосвязана с типами используемых интерфейсов. Очевидно, что увеличение только количества vCPU и vRAM вряд ли изменит ситуацию в лучшую сторону.

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

Переподписка процессора

Переподписка позволяет провести разделение ядер процессора для того, чтобы использовать меньшее количество pCPU. Чем выше переподписка, тем ниже будет конечная производительность виртуальной машины клиента. Величина переподписки связана с тем, сколько физических ядер процессора задействовано в каждом отдельном кластере провайдера, где находятся пользовательские виртуальные машины. Также на величину переподписки оказывает непосредственное влияние количество vCPU входящих в состав одной ВМ. В прямые обязанности провайдера облачных услуг входит задача следить за переподпиской и не допускать ее чрезмерного увеличения. Приемлемой величиной переподписки считается три vCPU на одно физическое ядро и частота 3 ГГц. Эти параметры позволяют большинству клиентских систем работать в стабильном режиме и не испытывать критических проблем при пиковых нагрузках.

Co-stop

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

Co-stop связан с количеством ядер в ВМ и интервалом измерений. Ядро в состоянии co-stop принимает значения, отличные от нуля в большую сторону, и не производит полезной работы. Co-stop увеличивается, когда на одном гипервизоре задействованы несколько виртуальных машин одновременно с большим числом ядер и наблюдается переподписка.

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

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

NUMA-топология

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

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

Расстояние до ЦОД

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

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

Однако выбор просто ближайшего ЦОД не всегда гарантирует решение проблемы задержки ввиду того, что пакеты данных движутся не про прямой, а по кабельным линиям, чья длина может быть в 1,5–2 раза больше реального расстояния.

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

Качество сети и оборудования в вашей компании

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

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

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

Заключение

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

Также рекомендуется использовать различные тесты для проверки реальной производительности IaaS. Например, для 1С подойдет тест Гилева. Производительность IaaS для сайта оценивают, анализируя время формирования загрузки страницы. В случае с виртуальной АТС возможно оценить производительность с помощью качества голосового соединения.

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

Полный текст статьи читайте на CNews