Производительность облачных сервисов

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

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

± Если вы не создаете кластеры серверов баз данных, сегментируйте доступ к базе данных таким образом, чтобы операции чтения могли выполняться на подчиненных серверах (slaves), а операции записи — на главном (master).

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

Организация кластеров или независимые узлы

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

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

± Использовать балансировщик нагрузки для маршрутизации трафика на узлы, собранные в кластер серверов приложений. Путем организации кластеров узлы серверов приложений могут взаимодействовать друг с другом и совместно использовать информацию о статусе. Организация кластеров дает то преимущество, что вы можете организовать обмен информацией о статусе на уровне сервера приложений; наряду с этим, недостатком этого подхода является то, что он сложнее и ограничивает долгосрочную масштабируемость. Еще одна проблема с настоящей кластеризацией состоит в том, что многие кластерные архитектуры основываются на многоадресной рассылке (multicasting) — а в Amazon EC2 она недоступна (но доступна в GoGrid и Rackspace).

Я являюсь убежденным сторонником подхода с использованием независимых узлов. Хотя для построения такой архитектуры приложения, которая будет рабо-

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100