Проблемы с облаком: планирование
Эффективность распределенной программы зависит от способа планирования выполнения составляющих ее задач на распределенных компьютерах. Планирование обычно подразделяется на два основных класса — один для задач и один для заданий. Задачи представляют собой минимальные единицы детализации выполнения, а задание может поддерживать одну или несколько задач. Несколько пользователей могут одновременно отправить множество заданий для выполнения в кластере, а планировщики заданий определяют, что следует делать дальше. Hadoop MapReduce, например, использует планировщик заданий по принципу "первым поступил, первым обслужен" (FIFO), когда задания выполняются в порядке поступления, а запланированное задание будет занимать весь кластер до тех пор, пока у него больше не будет запланированных задач. Hadoop MapReduce также использует другие планировщики заданий, такие как Capacity Scheduler (планировщик емкости) и Fair Scheduler (справедливый планировщик). После того как задание поступит в кластер, решение по планированию займется планированием задач, составляющих задание. Задачи можно запланировать близко к данным, которые они будут обрабатывать, или в любом месте. Когда задачи планируются вблизи их данных, считается, что действует концепция расположения. Например, Hadoop MapReduce поддерживает два типа задач: map и reduce. Задачи map планируются в непосредственной близости от их входных одноразмерных блоков HDFS, а задачи reduce планируются на любых узлах кластера (в любом месте), независимо от расположения их входных данных. Pregel и GraphLab, с другой стороны, не используют концепцию расположения при планировании задач.
Чтобы избежать значительного снижения производительности, планировщики задач также должны учитывать разнородность в базовой облачной системе. Аналогичные задачи, относящиеся к одному заданию, например, можно запланировать в разнородном облаке на узлах с разной скоростью. Однако эта процедура может привести к неравномерному распределению нагрузки, а выполнение заданий будет осуществляться в темпе их самых медленных задач. Справиться с этими проблемами могут такие стратегии, как спекулятивное выполнение в Hadoop MapReduce.
Кроме того, планировщики задач должны стремиться к повышению эффективности использования системы и улучшению параллелизма задач. Цель заключается в том, чтобы равномерно распределить задачи между компьютерами кластера таким образом, чтобы справедливо использовать имеющиеся ресурсы и эффективно увеличивать степень параллелизма. Но при этом существуют некоторые противоречивые приоритеты. Во-первых, равномерное распределение задач между машинами кластера может оказать негативное влияние на расположение. Компьютеры в кластере Hadoop, например, могут содержать разное количество блоков HDFS. Если количество блоков на одном компьютере значительно превышает количество блоков на других, расположение будет планировать все задачи сопоставления на этом компьютере. Это может привести к снижению уровня загрузки и использования других компьютеров. Кроме того, эта стратегия может уменьшить параллелизм задач, сосредоточивая множество задач на одном компьютере.
Если немного снизить приоритет концепции расположения, можно повысить эффективность использования, сбалансировать нагрузку между компьютерами и увеличить степень параллелизма задач. Однако при смягчении принципа расположения потребуется переместить данные ближе к задачам. Необоснованное выполнение этой операции может привести к увеличению издержек взаимодействия, тем самым препятствуя масштабируемости и потенциально ухудшая производительность. Фактически при наличии центров обработки данных, в которых размещены тысячи компьютеров, частое перемещение данных в сторону удаленных задач может стать основным узким местом. Для повышения производительности и снижения затрат оптимальный планировщик задач должен обеспечить баланс между использованием системы, распределением нагрузки, параллелизмом задач, взаимодействием и масштабируемостью К сожалению, реализовать это идеальное решение на практике очень сложно, и большинство планировщиков задач, пытаясь оптимизировать одну цель, упускают из виду другие.
При планировании заданий и задач возникает еще одна серьезная проблема, которая заключается в обеспечении соответствия так называемым целям уровня обслуживания (SLO), которые отражают ожидания конечных пользователей в отношении производительности. Поставщики облачных служб назвали нарушения SLO основной причиной недовольства пользователей1. Цель уровня обслуживания может быть выражена, например, как максимально допустимая задержка при выделении необходимых ресурсов заданию, гибкий или жесткий крайний срок для завершения задания или предпочтения GPU для выполнения определенных задач. В многоклиентских разнородных кластерах достичь SLO довольно трудно, особенно когда поступают новые задания, а другие все еще выполняются. В этой ситуации может потребоваться приостановить выполняющиеся задачи и запустить только что появившиеся, чтобы они смогли соответствовать собственным SLO. Возможность приостановки и возобновления задач называется эластичностью задач. К сожалению, большинство механизмов распределенной аналитики, включая Hadoop MapReduce, Pregel и GraphLab, пока не поддерживают эластичность задач. Обеспечение эластичности является довольно сложной задачей и требует определения безопасных точек, в которых задача может быть приостановлена без влияния на правильность ее выполнения, и чтобы при ее возобновлении не требовалось повторно выполнять уже зафиксированную работу. Очевидно, что эта возможность напоминает переключение контекста в современных операционных системах.
Ссылки
- J. Hamilton (2009). The Cost of Latency