- PVSM.RU - https://www.pvsm.ru -
В прошлой статье [1] мы рассказали о попытках использовать Watcher и представили отчет испытаний. Такие испытания мы периодически проводим для балансировки и других критических функций большого корпоративного или операторского облака.
Высокая сложность решаемой задачи, возможно, потребует нескольких статей для описания нашего проекта. Сегодня мы публикуем вторую статью цикла, посвященную балансировке виртуальных машин в облаке.
Компания VmWare ввела утилиту DRS (Distributed Resource Scheduler) для балансировки нагрузки разработанной и предлагаемой ими среды виртуализации.
Как пишет searchvmware.techtarget.com/definition/VMware-DRS [2]
«VMware DRS (Планировщик распределенных ресурсов) — это утилита, которая балансирует вычислительные нагрузки с доступными ресурсами в виртуальной среде. Утилита является частью пакета виртуализации под названием VMware Infrastructure.
С помощью VMware DRS пользователи определяют правила распределения физических ресурсов между виртуальными машинами (ВМ). Утилита может быть настроена на ручное или автоматическое управление. Пулы ресурсов VMware могут быть легко добавлены, удалены или реорганизованы. При желании пулы ресурсов могут быть изолированы между различными бизнес-единицами. Если рабочая нагрузка на одну или несколько виртуальных машин резко меняется, VMware DRS перераспределяет виртуальные машины между физическими серверами. Если общая рабочая нагрузка уменьшается, некоторые физические серверы могут быть временно отключены, а рабочая нагрузка консолидирована.»
По нашему мнению, DRS является обязательной функцией облака, хотя это не значит, что DRS нужно использовать всегда и везде. В зависимости от назначения и потребностей облака могут существовать разные требования к DRS и к методам балансировки. Возможно, существуют ситуации, когда балансировка не нужна совсем. Или даже вредна.
Чтобы было лучше понятно, где и для каких клиентов DRS нужна, рассмотрим их цели и задачи. Облака можно разделить на публичные и частные. Вот основные отличия этих облаков и целей клиентов.
Частные облака / Крупные корпоративные клиенты | Публичные облака / Средний и малый бизнес, люди | |
Основной критерий и цели оператора | Предоставление надежного сервиса или продукта | Снижение себестоимости сервисов в борьбе на конкурентном рынке |
Требования к услуге | Надежность на всех уровнях и во всех элементах системы
Гарантированная производительность Приоритезация виртуальных машин на несколько категорий Информационная и физическая безопасность данных SLA и круглосуточная поддержка |
Максимальная простота получения услуги
Относительно простые услуги Ответственность за данные лежат на клиенте Приоритезация ВМ не требуется Информационная безопасность на уровне типовых сервисов, ответственность на клиенте Могут быть сбои Нет SLA, качество не гарантируется Поддержка по почте Резервное копирование не обязательно |
Особенности клиента | Очень широкий спектр приложений.
Legacy приложения, унаследованные в компании. Сложные кастомизированные архитектуры для каждого клиента. Аффинити правила. Работа ПО без остановка в режиме 7х24. Средства резервного копирования «на лету». Предсказуемая циклическая нагрузка клиента. |
Типовые приложения – балансировка сети, Apache, WEB, VPN, SQL
Возможна остановка приложения на некоторое время Допускается произвольное распределение ВМ в облаке Резервное копирование силами клиента Предсказуемая при большом количестве клиентов статистически усредненная нагрузка. |
Следствия для архитектуры | Геокластеризация
Централизованная или распределенная СХД Резервируемая СРК |
Локальное хранение данных на вычислительных узлах |
Цели балансировки | Равномерное распределение нагрузки
Максимальная отзывчивость приложений Минимальное время задержки на балансировку Балансировка только в случае явной необходимости Вывод части оборудования на профилактическое обслуживание |
Снижение себестоимости услуги и издержек оператора
Отключение части ресурсов в случае низкой нагрузки Экономия электроэнергии Уменьшение издержек на персонал |
Для частных облаков, предоставляемых крупным корпоративным заказчикам, DRS может применяться с учетом ограничений:
Для публичных облаков, предоставляющих сервисы небольшим заказчикам, DRS может применяться гораздо чаще, с расширенными возможностями:
Сложность балансировки заключается в том, что DRS должна работать с большим количеством неопределенных факторов:
Нагрузка большого количества виртуальных серверов приложений и баз данных на ресурсы облака проистекает во времени, последствия могут проявляться и накладываться друг на друга с непредсказуемым эффектом через непредсказуемое время. Даже для управления относительно простыми процессами (например, для управления двигателем, системой водяного отопления дома) системам автоматического регулирования необходимо использовать сложные пропорционально-интегрально-дифференцирующие [3]алгоритмы с обратной связью.
Наша задача на много порядков сложнее, и существует риск, что система за разумное время не сможет провести балансировку нагрузки к устоявшимся значениям, даже если не будет возникать внешних воздействий со стороны пользователей.
Для решения этой проблемы мы приняли решение не начинать с нуля, а отталкиваться от существующего опыта, и стали взаимодействовать с имеющими в этой области опыт специалистами. К счастью, понимание проблематики у нас полностью совпадало.
Мы использовали систему, базирующуюся на технологии нейронных сетей, и попробовали на ее основе оптимизировать наши ресурсы.
Интерес данного этапа состоял в апробировании новой технологии, а его важность – в применении нестандартного подхода к решению задачи, где в прочих равных условиях стандартные подходы практически исчерпали себя.
Мы запустили систему, и у нас действительно пошла балансировка. Масштаб нашего облака не позволил нам получить оптимистичные результаты, заявленные разработчиками, но было видно, что балансировка работает.
При этом мы имели достаточно серьезные ограничения:
Поскольку нас не устраивало положение дел, мы решили модифицировать систему, и для этого ответить на главный вопрос – для кого мы её делаем?
Сначала – для корпоративных клиентов. Значит, нам нужна система, работающая оперативно, с теми корпоративными ограничениями, которые только упрощают реализацию.
Второй вопрос – что понимать под словом «оперативно»? В результате недолгих дебатов мы решили, что можно отталкиваться от времени реагирования 5 – 10 минут, чтобы кратковременные скачки не вводили систему в резонанс.
Третий вопрос – какой размер балансируемого количества серверов выбирать?
Этот вопрос решился сам собой. Как правило, клиенты не делают агрегаты серверов очень большими, и это соответствует рекомендациям из статьи ограничить агрегаты 30-40 серверами.
Кроме того, сегментируя пул серверов, мы упрощаем задачу алгоритму балансировки.
Четвертый вопрос – насколько нам подходит нейронная сеть с ее долгим процессом обучения и редкими балансировками? Мы приняли решение отказаться от нее в пользу более простых оперативных алгоритмов, чтобы получать результат за секунды.
С описанием системы, использующей такие алгоритмы и ее недостатками, можно ознакомиться тут [4]
Мы реализовали и запустили данную систему и получили обнадеживающие результаты – сейчас она регулярно анализирует нагрузку облака и дает рекомендации по перемещению виртуальных машин, которые в значительной степени являются правильными. Даже сейчас видно, что мы можем добиться 10-15% освобождения ресурсов под новые виртуальные машины с улучшением качества работы имеющихся.
При обнаружении дисбаланса по RAM или CPU система дает команды в планировщик Тионикс на выполнение живой миграции требуемых виртуальных машин. Как видно из системы мониторинга, виртуальная машина переехала с одного (верхнего) на другой (нижний) хост и освободила память на верхнем хосте (выделено в желтые круги), заняв ее соответственно на нижнем (выделено в белые круги).
Сейчас мы стараемся более точно оценить эффективность действующего алгоритма и пытаемся найти в нем возможные ошибки.
Казалось бы, на этом можно успокоиться, дождаться доказанной эффективности и закрыть тему.
Но нас подталкивают к проведению нового этапа следующие явные возможности оптимизации
Результатом нашей работы по совершенствованию алгоритмов балансировки стал однозначный вывод о том, что за счет современных алгоритмов можно добиться существенной оптимизации ресурсов (25-30%) датацентров и повысить при этом качество обслуживания клиентов.
Алгоритм, базирующийся на основе нейронных сетей, является, безусловно, интересным, но нуждающимся в дальнейшем развитии решением, и ввиду существующих ограничений не подходящим для решения такого рода задач на объемах, характерных для частных облаков. При этом в публичных облаках значительного размера алгоритм показал хорошие результаты.
Подробнее о возможностях процессоров, планировщиков и высокоуровневой балансировки мы расскажем в следующих статьях.
Автор: ArsenBlagov
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/328784
Ссылки в тексте:
[1] прошлой статье: https://habr.com/ru/company/rostelecom/blog/461483/
[2] searchvmware.techtarget.com/definition/VMware-DRS: https://searchvmware.techtarget.com/definition/VMware-DRS
[3] пропорционально-интегрально-дифференцирующие : https://ru.wikipedia.org/wiki/%D0%9F%D0%98%D0%94-%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80
[4] тут : https://habr.com/ru/post/416391/
[5] Image: https://habrastorage.org/webt/ie/ky/wa/iekywainupnidp_73j55hc1dbnw.png
[6] тут : https://www.cpubenchmark.net/multi_cpu.html
[7] тут : https://www.cpubenchmark.net/high_end_cpus.html
[8] вот одна из статей: https://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf
[9] Источник: https://habr.com/ru/post/465715/?utm_source=habrahabr&utm_medium=rss&utm_campaign=465715
Нажмите здесь для печати.