Главная > Open Source, Высокопроизводительная архитектура > AppScale — а построй ка мне Google AppEngine сам? Будет сделано!

AppScale — а построй ка мне Google AppEngine сам? Будет сделано!

10 апреля 2009

logoПриветствуем наших читателей. Весна, даже почти лето на дворе, очень влияет на состояние, ну просто расслабляет так, что сложно сосредоточится и что-либо делать серьезное. Но мы же профессионалы! Потому сегодня продолжаем разговор о современных технологиях, даже более, чем современных - находящихся на острие ИТ-прогресса! А сегодня одна из самых популярных и активных тем какая? Cloud Computing вообще, а один из лучших, оригинальные и ярких его представителей - Google App Engine в частности. Хорошая новость про добавление в платформу возможности работы приложения на Java - может и я попробую, хотя его, в какой то мере конкурент, Stax, о котором я, с прискорбием, никак не напишу, мне намного больше близок и нравиться. Но если вы все же остаетесь приверженцем Python (я вот его так и не смог освоить, просто синтаксис не понравился), и хотите нечто подобное, но полностью свое - для вас есть хорошая новость. Открытый проект AppScale позволяет развернуть собственную систему облачных вычислений предоставить возможность развертывать и запускать там приложения на Python-е, в принципе, без изменения кода, что для GoogleAppEngine, что написанные специально под систему.

И так, AppScale это некоторый интерфейс и инструменты для развертывания и поддержки приложений в Cloud-среде, при этом приложения имеют совместимость на уровне интерфейса с аналогичным сервисом от Google. На более низком уровне, AppScale опирается на ряд собственных подсистем-сервисов, написанных на разных языках, обеспечивающих необходимые системные функции для пользовательских скриптов. Еще ниже лежит стек также открытых технологий, например, Apache Hadoop,об этой части подробнее поговорим ниже. И на самом базовом уровне вся система опирается на инфраструктуру, основанную на системе виртуализации Xen, при этом в качестве базовой платформы может выступать как и банально один сервер, так и кластер или система из кластеров, используя или также открытую систему Eucalyptus (я уже когда-то кратко обозревал ее, в самом начале разработки, на сегодня система уже серьезно обновилась и активно развивается, чего стоит включение ее в следующий дистрибутив Ubuntu) либо коммерческий сервис Amazon EC2.

Если вы поклонник "громких и сексуальных" фраз, то вот описание от самих разработчиков - "AppScale is a multi-language, multi-component framework for executing GAE applications on virtualized
cluster systems.", что в переводе будет означать, что AppScale это многоязычный (имеется ввиду, что возможно использовать для проектов не только на Python, хотя это же касается и самой системы, она также написана на разных языках), мульти-компонентный фреймворк для запуска приложений для Google AppEngine в виртуализированной кластерной среде. А теперь, с расстановкой, по пунктах и подробнее.

Основной системы служат три компонента:

  • AppServer (AS) - сервер приложений, который, собственно, и отвечает за работу приложений;
  • AppLoadBalancer (ALB) - балансировщик нагрузки между нодами,  в этом качестве используется Nginx
  • AppController (AC) - компонент для управления взаимодействием между остальными частями системы.

Кроме этого в состав платформы входит еще два компонента нижнего уровня - DatabaseMaster, основной сервер баз данных (вернее - хранилища данных) и один или несколько компонент DatabaseSlaves, которые обеспечивают отказоустойчивое хранение и обработку данных.

architect

AppServer отвечает за исполнение пользовательских приложений, а также напрямую обращается к системе хранения данных, используя HTTPS протокол, он обращается за данными к DatabaseMaster, а далее уже данные обрабатываются либо на основном сервере, либо запрос передается на один из slave-серверов.

AppController один из основных компонентов. Он отвечает за установку, инициализацию и корректную остановку AppScale инстансов и пользовательских приложений, также он обеспечивает взаимодействие всех компонент системы. В дополнение в этому он обрабатывает авторизацию пользовательских приложений (используется та же система, что и в Amazon EC2 с ключами и сертификатами). Все взаимодействия между компонентами системы происходят по защищенному протоколу SSL.

Балансировщик нагрузки обычно работает на одной из нод, которая доступна снаружи и обеспечивает балансировку запросов к серверам приложений (AppServer), а также мониторинг доступности компонентов и их загрузку.

Вся инфраструктура основана на развертывании одной или несколmких нод (в терминах системы - GuestVM), на которых исполняются экземпляры компонент AppScale. Каждая нода это виртуальная машина, 64-битный Linux, внутри которого вы поднимаете один или все компоненты. Можно совместить как балансировщик и сервер приложения, вынеся базу данных , так и вообще все компоненты на одной машине. Обязательным будет только AppController, который обеспечит включение ноды в общую систему. Работет это все поверх Xen, так что на одной системе вы можете поднять несколько серверов, симитировав весь свой Cloud в рамках одного физического сервера.

guestvm

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

Если детальнее посмотреть на AppController, то это демон, написанный на Ruby, реализующий SOAP клиент/сервер, развернутый на каждой из нод, входящих в систему, и который загружается при старте GuestVM. На основной ноде контроллер после старта запускает балансировщик нагрузки, после чего остальные ноды могут автоматически подключаться к системе. Далее запускается DatabaseMaster (который может запускать другие slave-сервера) и, наконец, запускается AppServer. Контроллер на основной ноде периодически опрашивает все сервера (heartbeat) и собирает статистику загрузки основных ресурсов.

AppLoadBalancer (ALB) представляет собой простой Ruby-скрипт, запускающий Nginx сервер и три реплики Mongrel сервера. Первоначально, ALB обеспечивает авторизацию пользователей (по сути - приложений), а потом обрабатывает запросы приложений к AppServer и направляет их на один из свободных серверов, в дальнейшем приложение работает со своим сервером напрямую, без участия балансировшика.

AppServer совместим с питоновским модулем из Google AppEngine SDK. Но, на более низком уровне есть свои отличия, в частности, в системе хранения данных (Database). На самом низком системном уровне, система основана на Apache Hadoop - распределенная файловая система, реализующая MapReduce. На ее основе могут быть развернуты два хранилища данных - HBase, распределенная база данных, открытая реализация  Google BigTable, а также Hypertable. В одно и то же время один экземпляр AppServer-а может исполнять только одно приложение, поэтому для работы нескольких приложений можно либо разнести их по нодах, либо на одной ноде поднимать несколько экземпляров AppServer.

В качестве протокола для работы с базой данных используется Google Buffers Protocol поверх HTTPS. Запрос от приложения сначала поступает на фрон-енд мастер-сервера, называемый PBServer, который реализует унифицированный интерфейс работы с данными, а также скрывает нюансы между системами хранения. Например,  внутри PBServer использует другие протоколы, Thrift (разработка Facebook, сейчас передана Apache) для работы с HBase.   Используется всего четыре типа команд-запросов:

  • Put для вставки/сохранения данных, в случае если таблицы еще нет, она будет создана
  • Get - получение данных на основе ID (так как это, по сути, Key-value хранилище, о которых мы уже писали)
  • Query - запрос на выборку данных, используя схожий с SQL язык запросов (вероятно, речь идет о HQL)
  • Delete - удаление данных по ID.

Для примера, вот типичная конфигурация системы, которая состоит из одной главной ноды, на которой развернут AppLoadBalancer и DatabaseMaster, используемый для хранения как приложений так и другой системной информации, и трех (или больше) рабочих нод, на которых есть по одному или несколько AppServer-ов для запуска приложений, а также DatabaseSlave компонент для доступа к базе данных. Компонент AppController обязательный для всех нод системы и обеспечивает их связь.

type_architect

Как уже упоминалось, на нижнем системном уровне все работает поверх Xen, а значит, может использовать любые среды на базе этой системы виртуализации. Сейчас на сайте проекта предлагается как вариант на базе Amazon EC2, так и на базе другой открытой разработки, по сути, open-source Amazon EC2 - Eucalyptus. Но, при желании, все можно развернуть и без них, используя собственный сервер и развернув там Xen. Кстати, если вы хотите просто посмотреть на Eucalyptus и построить на нем AppScale инфраструктуру - добро пожаловать, на сайте системы раздают после регистрации возможность потрогать систему в реальности. Для экспериментов надо зарегистрироваться в программе Eucalyptus Public Cloud, получив в свое распоряжение до 4-х виртуальных машин (инстансов) в облаке, правда на 6 часов, после которых они будут выключены.

Чего хочется (и, возможно, скоро будет) - доступ и к обычной SQL базе данных (аналогично Stax), возможность работы с другими платформами (в первую очередь, РНР и Java). Но и сейчас система достаточно интересная, чтобы начать ее изучать и пробовать.

P.S. Возможно это немного странно, но сами разработчики предупреждают - в текущей версии AppScale ваши данные не сохраняются (не понятно, данные или состояние исполнения) при отключении AppServer-а, на котором исполняется ваше приложение. Это будет исправлено в следующей версии.

  1. Пока что нет комментариев.
Комментирование отключено.