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

    logoCегодня одна из самых популярных и активных тем какая? 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), а также мониторинг доступности компонентов и их загрузку.

    Вся инфраструктура основана на развертывании одной или нескольких нод (в терминах системы — 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-а, на котором исполняется ваше приложение. Это будет исправлено в следующей версии.
    Поделиться публикацией

    Похожие публикации

    Комментарии 12

      +1
      очень радует что растет выбор облачных плаформ. автору сасибо за обзор, за то что держит «на гребне волны»
        0
        Большое спасибо за статью, но язык очень сложный, много помарок. Видно, что торопились.
          +2
          извиняюсь :) совпадение — весна и расслабления, пытаюсь работать. а главное — в ноуте клавиатура западает, пробел, потому бывают сложности. вроде вычитывал три раза
          0
          Статья ОЧЕНЬ интересная, НО! Попытался прочесть первый абзац и сломал глаза и мозг! Понимаю, что автор, возможно, не учил русский, но все же!
          Cегодня одна из самых популярных и активных тем какая? Cloud Computing вообще, а один из лучших, оригинальных и ярких его представителей — Google App Engine в частности

          дальше — хуже…
            0
            что именно? или просто современные люди разучились воспринимать сложноподчиненные приложения? по моему все достаточно четко и логично, конечно, могут быть нестыковки иногда, все же мысль часто идет впереди, однако я думаю, что смысл важнее. Ну или ждите, пока кто-то с филологическим образованием напишет :) :)
              –1
              я написал исправленное предложение… прочтите оригинал…
                0
                так и сказали бы что очепятка :) подумаешь :)
                  0
                  В таком случае попробуйте найти «опечатку» в следующем предложении и в следующих за ним…
                    0
                    особенно знаки препинания
                      +1
                      и что? я их никогда не ищу, кроме очевидных которые автокоррекция показывает. Ибо смысл важнее этого, а людей, пишущих правильно, больше намного чем тех, кто пишет то, что достойно прочтения другими. :) в общем — шашечки или ехать :)
              0
              вот народ, это можно и автору в приват написать, что ж вы камменты заполняете своими бесполезными указками на ошибки в словах, когда человек о серьезных вещах говорит

              vooD убейся об стену, и сравни свои статьи и автора, в твоем случае даже текст без ошибок не поможет
                0
                Хм. HBase — это интересно. Как-то и не слышал про нее. Интересно, кто-нибудь ей пользуется?

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.