В этой статье будет описано архитектурное решение низкого уровня облачной платформы Hivext, а именно уровня дата центров и взаимодействия между собой серверов разного типа.
Напомним, что проект Hivext — предназначен для более эффективного использования ресурсов (временных и финансовых) при разработке “богатых” интернет приложений (Rich Internet Application) и предоставляет широкий набор готовых взаимосвязанных сервисов.
Благодаря компании IT-GRAD мы получили возможность бесплатного разворачивания дополнительной копии платформы в Питерском дата центре (ДЦ). Нам выделили виртуальный хостинг на базе VMware vSphere 4. Работать с таким хостингом можно и через веб интерфейс и через десктоп клиент, все довольно удобно.
На данный момент Hivext развернута в 3-х территориально разнесенных ДЦ: Киев (Украина), Житомир (Украина) и Санкт-Петербург (Россия). Конфигурация платформы внутри каждого ДЦ построена по определенной структуре.
Предлагаю, так сказать, заглянуть под капот нашей платформы.
Итак, в связи с победой в конкурсе IT стартапов последняя копия нашей платформы расположена на оборудовании, которое располагается на площадке в ДЦ ИТ-Град с высоким уровнем надёжности TIER3. Это обеспечивает доступность 99,95%, резервный дизель-генератор, водное охлаждение, газовая система пожаротушения, круглосуточная служба поддержки. Всё вкупе создает отказоустойчивую площадку, где располагаются банки, телекоммуникационные компании и наша платформа.
Схема взаимодействия ДЦ
Все запросы от клиентов приходят на общий узел http://api.hivext.com/, который находится в центральном ДЦ. В этом узле имеется информация про размещение каждого конкретного приложения, к которому идет запрос. Если приложение находится в другом ДЦ, текущий ДЦ работает как прокси. В большинстве случаев для работы с API платформы используются клиентские SDK (JavaScript, ActionScript, j2me, j2se, Qt), которые при первом обращении запрашивают в каком конкретно ДЦ находится приложение и все последующие запросы уходят напрямую к нужному ДЦ. Таким образом решается два вопроса — клиентская балансировка и безболезненная миграция приложений между ДЦ.
Взаимодействие компьютеров внутри одного ДЦ
Для обеспечения необходимой функциональности используется четыре различных типа компьютеров.
- Балансировщик
- Сервер приложений (Cloudlets)
- Файловый сервер
- Сервер баз данных
В идеальном случае общая схема будет работать по смешанному принципу HA (High Available) + LB (Load Balancing). В реальном случае (на данный момент развития) HA используется в ограниченном режиме, дублирующий сервер используется только для сервера приложений.
В сфере облачных платформ мы вводим новое понятие Cloudlet — это один инстанс веб-сервера (в данном случае tomcat) с фиксированным размером памяти 1 GB.
Ниже схематически представлена взаимодействие разного типа компьютеров платформы в одном из ДЦ.
В дата центре IT-GRAD нам бесплатно выделили объем ресурсов, из которых получилось собрать нижеуказанную конфигурацию:
Balancer — 1 vCPU, 1Gb Memory, 8 Gb HDD — Apache 2 + AJP (доработанный mod_jk)
Node1 — 3 vCPU, 4Gb Memory, 52 Gb HDD — (Master) tomcat 6 (3шт) + NIS + NFS + FTP
Node2 — 3 vCPU, 4Gb Memory, 36 Gb HDD — tomcat 6 (3шт)
DB — 2 vCPU, 8Gb Memory, 200 Gb HDD — MySQL 5.1
К сожалению, ресурсов выигранных в конкурсе нам не хватило на организацию отдельного сервера File Storage, поэтому временно он был совмещен с одной из нод.
Балансировщик реализован на базе Apache 2 + AJP (доработанный mod_jk) c использованием “липких” сессий (stiky session). Apache 2 сконфигурирован таким образом, что все статические файлы отдаются им напрямую, а остальные запросы перебрасываются на сервер приложений. Добавление нового приложение и выделение доменного имени производится без перезагрузки Apache 2.
Cloudlet (сервер приложений) реализован на базе tomcat 6, который развернут в количестве 6 штук на Node1 и Node2 и сконфигурирован в 3 отдельных cluster-а c использованием DeltaManager + SimpleTcpCluster (репликация в памяти). Балансировка производится между этими тремя кластерами.
Файловый сервер хранит в себе статические файлы. Статические файлы доступны напрямую через web и доступны скриптам приложений внутри сервера приложений. Доступность файлов на других серверах обеспечивается за счет использования NFS 4. К этим же файлам можно добраться используя FTP.
Для синхронизации пользователей между компьютерами используется NIS.
Сервер баз данных реализован на базе MySQL 5.1 с использованием репликации master-slave. Под каждое приложение выделяется отдельная база. Доступ к базам приложений имеется из скриптов приложений, а так же через веб интерфейс PhpMyAdmin.
Схема организации платформы на уровне программного обеспечения указана ниже
В ядре платформы используется два кита Spring Framework и Hibernate.
В данной статье мы вкратце рассмотрели архитектуру низкого уровня облачной платформы Hivext.
—
В следующих статьях: открытие PHP на базе Quercus, описание работы с клиентскими SDK.
Предыдущие статьи про Hivext
- Hivext: Платформа веб сервисов (часть 1 и часть 2)
- Облачная платформа Hivext для web разработки
- Hivext Platform — облачная платформа для разработки Интернет приложений. Бета тестирование
Online Cloud Development Environment
Наш форум
Любые вопросы и замечания по существу приветствуются.
