Проблемы с облаком: разнородность

  • 9 мин

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

  • Поставщики облачных служб обычно поддерживают несколько поколений ИТ-ресурсов, приобретенных в разное время.
  • Поставщики облачных служб все чаще применяют технологию виртуализации в своих облаках для консолидации серверов, улучшения использования системы и упрощения управления. Общедоступные облака — это преимущественно виртуализированные центры обработки данных. Даже в частных облаках виртуализированные среды должны стать нормой1.

Разнородность является прямым результатом распространения виртуализированных сред. Кроме того, к разнородности может привести совместное размещение виртуальных машин на аналогичных физических компьютерах. Рассмотрим, например, два идентичных физических компьютера — А и Б. Даже если предположить, что на идентичных виртуальных машинах выполняются одни и те же программы, при размещении одной виртуальной машины на компьютере А и десяти виртуальных машин на компьютере Б второй компьютер окажется под большей нагрузкой, чем первый. Наличие разнородных виртуальных машин и разнообразных, требовательных к ресурсам программ еще более вероятно в облаке, и ситуация там еще хуже. Особенно привлекательной средой является Azure, предлагающая более 30 типов виртуальных машин5 миллионам пользователей с разными программами. Очевидно, что эта ситуация создает еще большую разнородность. Короче говоря, разнородность уже является и будет оставаться обычным явлением в облаке.

Разнородность создает множество проблем при запуске распределенных программ в облаке. Распределенные программы должны быть спроектированы так, чтобы маскировать разнородность базового оборудования, сетей, операционных систем и языков программирования. Полученная в результате иллюзия однородности обеспечивает взаимодействие распределенных задач. В противном случае передача сообщений и вся концепция распределенных программ провалится. Рассмотрим проблему представления данных: сообщения, которыми обмениваются задачи, обычно содержат примитивные типы данных, такие как целые числа. К сожалению, не все компьютеры хранят целые числа в одном и том же порядке. В частности, некоторые компьютеры используют так называемый обратный порядок следования байтов, в котором старший байт является первым, а другие используют так называемый прямой порядок следования байтов, в котором старший байт является последним. Кроме того, в разных архитектурах компьютеров можно встретить разные числа с плавающей запятой. Другой проблемой является набор кодов, используемых для представления символов. Некоторые системы используют символы ASCII, а другие — стандарт Юникода. Одним словом, распределенные программы должны выработать такую разнородность, которая позволит им существовать. Та часть, которая может быть включена в распределенные программы для обеспечения разнородности, обычно называется ПО промежуточного слоя. К счастью, большинство ПО промежуточного слоя реализуется через интернет-протоколы, которые сами по себе маскируют различия в базовых сетях. Примером ПО промежуточного слоя является протокол SOAP2. SOAP определяет схему для использования языка XML (текстового формата с самоописанием) для представления содержимого сообщений и обеспечения возможности взаимодействия распределенных задач, выполняющихся на различных компьютерах. Еще один пример — передача репрезентативного состояния или REST.

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

Еще одной серьезной проблемой разнородности, требующей внимания программистов, является изменение производительности3, 4 в облаке. Изменение производительности связано с ситуацией, когда выполнение одной и той же распределенной программы дважды в одном и том же кластере может привести к разному времени выполнения. Например, время выполнения одного и того же приложения в одном и том же частном кластере может отличаться в пять раз4. Изменение производительности связано в основном с разнородностью облака, вызванной виртуализированными средами, и временными перепадами в потребностях в ресурсах. Как следствие, облачные виртуальные машины редко выполняют работу с одинаковой скоростью, тем самым препятствуя выполнению задач в (приблизительно) постоянном темпе. Очевидно, что такая ситуация может привести к неравномерному распределению нагрузки и снижению общей производительности, так как неравномерность нагрузки ставит производительность программы в зависимость от ее самой медленной задачи. Распределенные программы могут попытаться упростить ситуацию, выявляя медленно выполняющиеся задачи и планируя работу соответствующих задач на быстрых ВМ так, чтобы они завершались раньше. В частности, две равнозначных задачи могут конкурировать друг с другом следующим образом: они запускаются на двух разных виртуальных машинах, и та, которая завершается раньше, остается, а другая — удаляется. Hadoop MapReduce следует подобной стратегии для решения той же проблемы, которая называется спекулятивным выполнением. К сожалению, различать медленные и быстрые задачи или виртуальные машины в облаке довольно сложно. Может случиться так, что на определенной виртуальной машине, где выполняется задача, временно возникает период пиковой нагрузки. Может быть и так, что виртуальная машина просто вышла из строя. Теоретически не каждый узел, на котором обнаружено снижение производительности, является неисправным, а отличить неисправный узел от медленно работающего очень трудно6. Из-за этой проблемы Hadoop MapReduce плохо работает в гетерогенных средах5, 7. Причины такого поведения и подробности спекулятивного выполнения Hadoop приводятся в разделе по Hadoop MapReduce.


Ссылки

  1. M. Zaharia, A. Konwinski, A. Joseph, R. Katz, and I. Stoica (2008). Improving MapReduce Performance in Heterogeneous Environments OSDI
  2. G. Coulouris, J. Dollimore, T. Kindberg, and G. Blair (май 2011 г.). Distributed Systems: Concepts and Design Addison-Wesley
  3. B. Farley, V. Varadarajan, K. Bowers, A. Juels, T. Ristenpart, and M. Swift (2012 г.). More for Your Money: Exploiting Performance Heterogeneity in Public Clouds SOCC
  4. M. S. Rehman and M. F. Sakr (Nov. 2010). Initial Findings for Provisioning Variation in Cloud Computing CloudCom
  5. Размеры виртуальных машин Linux в Azure
  6. A. S. Tanenbaum and M. V. Steen (October 12, 2006). Distributed Systems: Principles and Paradigms Prentice Hall, Second Edition
  7. T. D. Braun, H. J. Siegel, N. Beck, L. L. Blni, M. Maheswaran, A. I. Reuther, J. P. Robertson, M. D. Theys, B. Yao, D Hensgen, and R. F. Freund (June 2001). A Comparison of Eleven Static Heuristics for Mapping a Class of Independent Tasks onto Heterogeneous Distributed Computing Systems JPDC