В вычислительной технике эластичность определяется как «степень, в которой система способна адаптироваться к изменениям рабочей нагрузки путем предоставления и отзыва ресурсов автономным образом , так что в каждый момент времени доступные ресурсы максимально соответствуют текущему спросу». [1] [2] Эластичность является определяющей характеристикой, которая отличает облачные вычисления от ранее предложенных парадигм распределенных вычислений , таких как сеточные вычисления . Динамическая адаптация мощности, например, путем изменения использования вычислительных ресурсов , для удовлетворения изменяющейся рабочей нагрузки называется «эластичными вычислениями». [3] [4]
По мнению авторов, в мире распределенных систем существует несколько определений, некоторые из которых рассматривают концепцию масштабируемости как часть эластичности, другие — как отдельные понятия.
Давайте проиллюстрируем эластичность на простом примере поставщика услуг, который хочет запустить веб-сайт в облаке IaaS . В данный момент веб-сайт непопулярен, и одной машины (чаще всего виртуальной ) достаточно для обслуживания всех веб-пользователей. В данный момент веб-сайт внезапно становится популярным, например, в результате внезапного наплыва посетителей , и одной машины больше недостаточно для обслуживания всех пользователей. Исходя из количества веб-пользователей, одновременно получающих доступ к веб-сайту, и требований к ресурсам веб-сервера , может оказаться, что потребуется десять машин. Эластичная система должна немедленно обнаружить это состояние и предоставить девять дополнительных машин из облака, чтобы оперативно обслуживать всех веб-пользователей.
В момент сайт снова становится непопулярным. Десять машин, которые в настоящее время выделены для сайта, в основном простаивают, и одной машины было бы достаточно для обслуживания нескольких пользователей, которые заходят на сайт. Эластичная система должна немедленно обнаружить это состояние и деинициализировать девять машин, а затем выпустить их в облако.
Эластичность направлена на соответствие объема ресурсов, выделенных для сервиса, объему ресурсов, которые ему фактически требуются, избегая избыточного или недостаточного выделения. Избыточного выделения , т. е. выделения большего количества ресурсов, чем требуется, следует избегать, поскольку поставщику услуг часто приходится платить за ресурсы, выделенные для сервиса. Например, экземпляр Amazon EC2 M4 extra-large стоит 0,239 долл. США /час. Если сервис выделил две виртуальные машины, когда требуется только одна, поставщик услуг теряет 2095 долл. США каждый год. Следовательно, расходы поставщика услуг превышают оптимальные, а его прибыль снижается.
Недостаточное обеспечение , т. е. выделение меньшего количества ресурсов, чем требуется, следует избегать, в противном случае сервис не сможет обслуживать своих пользователей с хорошим обслуживанием. В приведенном выше примере недостаточное обеспечение веб-сайта может сделать его медленным или недоступным. Веб-пользователи в конечном итоге отказываются от доступа к нему, таким образом, поставщик услуг теряет клиентов. В долгосрочной перспективе доход поставщика уменьшится, что также уменьшит его прибыль.
Одна из потенциальных проблем заключается в том, что эластичность требует времени. Пользователь может получить облачную виртуальную машину (ВМ) в любое время; однако может потребоваться несколько минут, чтобы приобретенная ВМ была готова к использованию. Время запуска ВМ зависит от таких факторов, как размер образа, тип ВМ, местоположение центра обработки данных, количество ВМ и т. д. [5] Поставщики облачных услуг имеют разную производительность запуска ВМ. Это означает, что любой механизм управления, разработанный для эластичных приложений, должен учитывать в своем процессе принятия решений время, необходимое для вступления в силу действий эластичности, [6] например, предоставление другой ВМ для определенного компонента приложения.
Эластичные приложения могут выделять и освобождать ресурсы (например, виртуальные машины) по требованию для определенных компонентов приложения. Это делает облачные ресурсы нестабильными, и традиционные инструменты мониторинга, которые связывают данные мониторинга с определенным ресурсом (например, виртуальной машиной), такие как Ganglia или Nagios , больше не подходят для мониторинга поведения эластичных приложений. Например, в течение своего жизненного цикла уровень хранения данных эластичного приложения может добавлять и удалять виртуальные машины хранения данных из-за требований к стоимости и производительности, изменяя количество используемых виртуальных машин. Таким образом, для мониторинга эластичных приложений необходима дополнительная информация, такая как связывание логической структуры приложения с базовой виртуальной инфраструктурой. [7] Это, в свою очередь, порождает другие проблемы, такие как то, как агрегировать данные из нескольких виртуальных машин для извлечения поведения компонента приложения, работающего поверх этих виртуальных машин, поскольку различные метрики, возможно, должны быть агрегированы по-разному (например, использование процессора может быть усреднено, передача данных по сети может быть суммирована).
При развертывании приложений в облачных инфраструктурах (IaaS/PaaS) необходимо учитывать требования заинтересованных сторон, чтобы обеспечить надлежащее поведение эластичности. Хотя традиционно можно попытаться найти оптимальный компромисс между стоимостью и качеством или производительностью, для реальных пользователей облака требования относительно поведения более сложны и нацелены на несколько измерений эластичности (например, SYBL [8] ).
Облачные приложения могут быть разных типов и сложности, с несколькими уровнями артефактов, развернутых в слоях. Управление такими структурами должно учитывать множество проблем, подход в этом смысле является rSYBL. [9] Для многоуровневого управления системы управления должны учитывать влияние контроля более низкого уровня на контроль более высокого уровня и наоборот (например, управление виртуальными машинами, веб-контейнерами или веб-сервисами в одно и то же время), а также конфликты, которые могут возникнуть между различными стратегиями управления с разных уровней. [10] Эластичные стратегии в облаках могут использовать преимущества методов теории управления (например, предиктивное управление было опробовано в сценариях облака, показав значительные преимущества по сравнению с реактивными методами). [11]
{{cite book}}
: CS1 maint: дата и год ( ссылка )