Яндекс.облако

Вторая ежегодная конференция Yandex Scale начнётся сегодня, 23 сентября, в 18.00 по Москве. В этот раз она пройдёт онлайн, а мы проведем текстовую трансляцию на Хабре.



Развитие облачных технологий в этом году позволило компаниям и разработчикам стать мобильнее, быстрее реагировать на изменения и создавать новые качественные продукты. Мы в Yandex.Cloud, в свою очередь, проделали большую работу по развитию платформы, реализовали крупные проекты и сегодня представим новые возможности и сервисы нашего облака.

Вести трансляцию будет редактор Yandex.Cloud Евгений Левашов levashove и руководитель направления архитектуры облачных решений Григорий Атрепьев farlol.

В этой статье я хочу разобрать один из самых популярных опенсорс-инструментов, Node-RED, с точки зрения создания простых прототипов приложений с минимумом программирования. Проверим гипотезу о простоте и удобстве таких средств, а также рассмотрим взаимодействие Node-RED с облачной платформой на примере Yandex.Cloud.

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

Есть ряд ограничений, связанных с хранением данных клиентов в облачных дата-центрах других государств. Поэтому у пользователей зарубежных ресурсов все чаще появляется устойчивое желание использовать гибридные подходы, применять локализованные облачные сервисы, расположенные на территории России. В таких случаях для реализации сценариев интернета вещей вполне оправдано объединение открытых технологий IBM с готовым облачным сервисом Яндекса.

Кратко о Node-RED, его истории, создателях и сообществе

Как гласит первоисточник, Node-RED это инструмент потокового программирования, первоначально разработанный командой IBM Emerging Technology Services и в настоящее время являющийся частью JS Foundation.

В качестве ключевой составляющей Node-RED выступает парадигма потокового программирования, которое было изобретено в 70-х Джеем Полом Моррисоном. Потоковое программирование это способ описания поведения приложения в виде сети черных ящиков или узлов, как они называются в Node-RED. Каждый узел имеет четкую цель к нему поступают некоторые данные, он что-то делает с этими данными, а затем передает их на следующий узел. Сеть отвечает за поток данных между узлами.

Эта модель отлично подходит для того, чтобы представить ее визуально: так она становится более доступной для широкого круга пользователей. Если кто-то пытается разобраться в проблеме, он может разбить задачу на отдельные шаги, взглянуть на поток и понять, что он делает, без необходимости разбираться в отдельных строках кода в каждом узле.

Node-RED работает в среде исполнения Node.js, а для создания или редактирования потока (Flow) используется браузер. В браузере вы можете создавать свое приложение путем перетаскивания необходимых узлов (Node) из палитры в рабочую область и соединять их вместе. Одним кликом по кнопке Deploy приложение разворачивается в среде исполнения и запускается.

Палитра узлов может быть легко расширена путем установки новых узлов, созданных сообществом, а созданные вами потоки могут быть легко переданы в виде файлов JSON.

Node-RED начал свою жизнь в начале 2013 года как совместный проект Ника О'Лири и Дэйва Конвея-Джонса из группы IBM Emerging Technology Services.

Проект стартовал как подтверждение концепции визуализации и манипулирования мэппингами между топиками сообщений в протоколе Message Queuing Telemetry Transport (MQTT). Node-RED быстро стал более универсальным инструментом, который можно было легко расширять в любом направлении.

Исходный код проекта был открыт в сентябре 2013 года. С тех пор он разрабатывался в открытом виде, кульминацией развития стало признание Node-RED одним из фундаментальных проектов JS Foundation в октябре 2016 года.

Почему проект называется Node-RED?

Со слов авторов:

Название было веселой игрой слов, звучащих как Code Red.
Это название приклеилось к проекту и стало существенным шагом вперед по сравнению с тем, как он назывался в первые несколько дней.
Часть Node отражает суть модели потокового программирования (поток/узел) и основную среду выполнения Node.JS.
Окончательного решения о том, что же означает часть RED, принято так и не было.
Одно из предложений Rapid Event Developer (быстрый разработчик событий), но мы никогда не чувствовали себя обязанными что-либо формализовать.
Мы придерживаемся названия Node-RED."

Node-RED предоставляется по лицензии Apache 2.0. Важно понимать и осознавать условия лицензии по этой ссылке есть краткая выдержка с основными свойствами.

Лицензия разрешает коммерческое использование, но при этом накладывает и ряд ограничений. Вот основные из них: при использовании торговой марки Node-RED (принадлежащей OpenJS Foundation) нельзя ее искажать; кроме того, есть ограничение ответственности (Liability/Warranty) участники проекта не могут быть привлечены к ответственности в случае причинения убытков в процессе некорректного использования их продукта.

Постановка задачи интеграция Node-RED c Yandex IoT Core

Сначала хочу отметить: вся эта затея сугубо самообразовательная и подкреплена только непреодолимой тягой энтузиастов к познанинию нового. Например, хотелось изучить возможности облачных сред и сервисов Яндекса, которые могут быть безвозмездно получены для тестирования своих гениальных идей. Ну а чтобы была польза для дела, было решено посмотреть, насколько совместимы реализованные в проекте Node-RED узлы (из коробки на уровне MQTT) с интерфейсами сервиса IoT Core.

Задача выглядит просто:

• Развернуть и настроить виртуальную машину в облаке
• Установить и запустить в нужной конфигурации Node-RED
• Создать и должным образом настроить сервис IoT Core
• Эмулировать IoT-устройство в Node-RED с набором параметров
• Подключить созданное устройство к облачной IoT-платформе
• Отправлять сообщения в облако и получать корректные ответы
• Визуализировать результаты в виде прототипа приложения

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

Создание облачной среды и установка Node-RED

Создание ВМ

Для создания виртуальной машины, на которой мы далее запустим Node-RED, зайдем в Yandex.Cloud и перейдем в Консоль. В сервисе Compute Cloud нажимаем Создать ВМ.

Задаем машине любое разрешенное имя и в качестве операционной системы выбираем CentOS. Для запуска Node-RED подходит любая из приведенных ОС, но в статье мы рассмотрим порядок работы только с CentOS.

Выполнение тестового сценария не требует больших ресурсов, поэтому выставляем все на минимум. Этот ход также позволит сэкономить ресурсы пробного периода, если вы решили развернуть Node-RED только для ознакомления.

Работа с ВМ будет осуществляться через SSH, поэтому пусть у машины будет автоматически выделенный публичный адрес.

Для подключения к машине по SSH необходимо указать публичный ключ. Сгенерируем SSH-ключи командой ssh-keygen -t rsa -b 2048 в терминале, потребуется придумать ключевую фразу.

Теперь требуемый ключ хранится в ~/.ssh/is_rsa.pub, копируем его в поле SSH-ключ и нажимаем Создать ВМ.

Подключение к ВМ

После завершения подготовки ВМ в сервисе Compute Cloud появится наша машина с заполненным полем Публичный IPv4.

Также нам необходим логин, который мы указывали на предыдущем шаге в разделе Доступ. Выполним подключение к машине по SSH командой $ ssh <login>@<IPv4>. При подключении потребуется ввести ключевую фразу, которую мы указали на этапе генерации ключей.

$ ssh <login>@<IPv4>Enter passphrase for key '/Users/<user>/.ssh/id_rsa': Last login: Wed Jul 15 08:42:53 2020 from <your host ip>[<login>@node-red ~]$ 

Установка Node-RED

Теперь мы можем установить Node-RED. Самый удобный способ для новой, пустой системы Linux installers for Node-RED из репозитория проекта. Так как мы используем CentOS 8, нам необходима вторая команда для ОС, основанных на RPM:

$ bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/rpm/update-nodejs-and-nodered)...  Stop Node-RED                         Install Node.js LTS                    Node v10.19.0   Npm 6.13.4  Install Node-RED core                  1.1.2   Add shortcut commands                 Update systemd script                 Update public zone firewall rule    Any errors will be logged to   /var/log/nodered-install.logAll done.  You can now start Node-RED with the command  node-red-start  Then point your browser to localhost:1880 or http://{your_pi_ip-address}:1880...

Скрипт установит LTS-версию Node.js, базовую версию Node-RED, создаст скрипт автозапуска для systemd и по желанию создаст правила для порта 1880 в файрволе. Для проверки успешности установки можно запустить команду:

$ node-red-start

Примечание: для выхода из Node-RED нажмите Ctrl+C.

Как активировать автозапуск и старт службы с помощью systemctl:

$ sudo systemctl enable --now nodered.service

После этого по адресу http://{ip вашей машины}:1880 в браузере будет доступен Node-RED.

Подготовка и настройка сервиса Yandex IoT Core

Возвращаемся в Консоль, выбираем IoT Core и нажимаем Создать реестр. Указываем любое подходящее имя. Далее определимся со способом авторизации.

IoT Core поддерживает два способа: с помощью сертификатов и по логину-паролю. Для нашего тестового сценария намного быстрее использовать последний, поэтому заполним поле Пароль. Длина пароля минимум 14 символов.

После создания переходим в реестр во вкладку Устройства слева и нажимаем Добавить устройство.

Аналогично реестру задаем имя и пароль.

Теперь в пункте Обзор реестра появился его ID и пароль (в скрытом виде), которые мы указали при создании реестра. То же самое с устройством: на странице устройства есть его ID.

Пример создания простого приложения в Node-RED

Перейдем в http://{ip вашей машины}:1880. Импортируем готовый пример, где нам потребуется лишь указать данные реестра и устройства.

В меню в правом верхнем углу Node-RED нажмем Import. Flow в формате .json берем отсюда и либо копируем содержимое в поле, либо скачиваем файл и нажимаем select a file to import.

В новой вкладке появится flow testing connection.

Рассмотрим добавленные узлы. Send data узел типа Inject, предназначен для ручного или автоматического запуска flow.

Device payload узел-функция, позволяет выполнять JavaScript для обработки данных, проходящих через этот узел.

device mqtt-out-узел с настраиваемым MQTT-подключением, предназначен для публикации данных в топик.

Два раза кликаем по узлу device.

Нам необходимо заменить <id_реестра> на ID нашего реестра в IoT Core. Далее редактируем данные в Server. Во вкладке Security указываем username это ID созданного нами устройства, а password пароль, придуманный на этапе создания устройства. Затем нажимаем Update, далее Done.

Протестируем соединение: в правом верхнем углу нажмем Deploy. Под узлом device появится подпись connected.

Импортируем flow с dashboard таким же образом. После импорта будет показано сообщение о недостающих компонентах, загрузим их. В меню в правом верхнем углу перейдем в Manage palette. В появившемся окне во вкладке Install в поисковом поле напишем node-red-dashboard и установим самый первый из найденных пакетов. Таким же образом установим node-red-contrib-web-worldmap.

Flow получился намного интереснее предыдущего, видны новые узлы.

Так, registry mqtt-in-узел, принимает сообщения из указанного в настройках топика и передает их следующим узлам.

Измеряемые данные приходят в строке, поэтому применяется узел разбора сообщений json. Он может конвертировать JSON-объект в его JS-представление и обратно.

Parsing JSON и JSON возвращают полученные измерения уже в виде отдельных объектов, которые далее передаются узлам, отвечающим за элементы Dashboard.

Теперь необходимо настроить узел registry. Аналогично первому flow записываем наш ID реестра и переходим в настройки сервера iot-core-subscription.

Во вкладке Security добавляем данные реестра, сохраняем изменения и нажимаем Deploy.

Если все поля заполнены верно, то после развертывания под узлом registry тоже появится подпись connected.

Последння вкладка в окне справа (с иконкой столбчатой диаграммы) отвечает за Dashboard. Перейти в Dashboard можно по кнопке:

Каждые три секунды устройство из flow testing connection генерирует данные, отправляет их в топик нашего реестра, а flow Smart Utilities, в свою очередь, подписывается на этот топик и обновляет Dashboard в соответствии с данными, приходящими из IoT Core.

В качестве результатов и краткого заключения

Node-RED действительно может скачать любой желающий, безвозмездно. При первом знакомстве он вызывает вопросы в плане логики работы и прививает свою непередаваемую любовь к узлу "debug" и вкладке "debug messages". Но когда осмотришься и разберешься, то все встает на свои места и становится очень просто выполнять любые действия. Совсем без познаний в программировании обойтись не получится требуется хоть какое-то представление о том, что такое переменные, условия, циклы, массивы, JSON сообщения и как осуществлять их разбор. Однако узлы из раздела "Network", такие как "mqtt in/out", заработали с сервисом Yandex IoT Core вообще без проблем при условии правильной конфигурации.

Я умышленно не стал слишком детально описывать, как создается само приложение, поскольку есть исходник потока в JSON. Да и сама идея проекта Node-RED предполагает, что любой желающий может взглянуть на поток и понять, что он делает, без необходимости разбираться в отдельных строках кода на каждом узле. Но в код лучше заглянуть.

Ссылки на полезные материалы

• Node-RED на GitHub
• Документация проекта Node-RED (eng)
• Книга рецептов (eng)
• Как начать работать с Node-RED (eng) в разных облачных средах
• Node-RED гостит у папы (eng)
• Рецепты по Node-RED в IBM (eng)
• Видео от создателей c русскими субтитрами

Отдельное спасибо за помощь при создании статьи:

• Максиму Волкову (ИТ Архитектор, IBM)
• Константину Гальцеву (НТЦ IBM в России)
• Виталию Бондаренко (ИТ Архитектор, IBM)

Привет, Хабр!

В этой статье, я расскажу как легко и просто разместить статический сайт с помощью технологий Яндекса, а именно Object Storage.

В конце у вас будет размещенный в сети сайт, который будет доступен по внешней ссылке.

Эта статья будет полезна, если вы

• Начинающий разработчик, который только обучается программированию;
• Разработчик, который сделал портфолио и хочет разместить его в открытом доступе, чтобы показать друзьям и работодателям.

О себе

Недавно, я разрабатывал SaaS сервис, подобие маркетплейса, где люди находят спортивных тренеров для персональных тренировок. Использовал стек Amazon Web Services (далее AWS). Но чем глубже погружался в проект тем больше нюансов узнавал о разных процессах организации стартапа.

Я столкнулся с следующими проблемами:

• AWS потреблял много денег. Поработав 3 года в Enterprise компаниях, я привык к таким радостям, как Docker, Kubernetes, CI/CD, blue green deployment, и, как начинающий программист-стартапер, захотел реализовать тоже самое. В итоге пришел к тому, что ежемесячно AWS потреблял по 300-400 баксов. Самым дорогим оказался Kubernetes, около 100 баксов, при минималке с одним кластером и одной нодой.
  P.S. На старте не нужно так делать.
• Далее, задумавшись о юридической стороне, я узнал про закон 152-ФЗ, в котором говорилось примерно следующее: "Персональные данные граждан РФ должны храниться на территории РФ", иначе штрафы, чего мне не хотелось. Я решил заняться этими вопросами, пока "сверху" мне не прилетело :).

Вдохновленный статьей о мигрировании инфраструктуры из Amazon Web Services в Яндекс.Облако, я решил изучить стек Яндекса подробнее.

Для меня ключевыми особенностями Яндекс.Облака было следующее:

• Дешевле в 2-3 раза (согласно статье выше и публичным прайсам)
• Хранение персональных данных пользователей на территории РФ, что великий Амазон пока не может осуществить.

Я изучал других конкурентов этого сервиса, но на тот момент Яндекс выигрывал.

О себе рассказал, можно и перейти к делу.

Шаг 0. Подготовим сайт

Для начала нам понадобится сайт, который мы хотим разместить в интернете. Так как я Angular разработчик, я сделаю простой шаблон SPA приложения, который далее размещу в интернете.

P.S. Кто разбирается в Angular или знает про его документацию https://angular.io/guide/setup-local, переходите к Шагу 1.

Установим Angular-CLI чтобы создавать SPA-сайты на Ангуляре:

npm install -g @angular/cli

Создадим Angular приложение с помощью следующей команды:

ng new angular-habr-object-storage

Далее переходим в папку приложения и запускаем его, чтобы проверить работоспособность:

cd angular-habr-object-storageng serve --open

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

ng build --prod

В результате этой команды в корне приложения появилась папочка dist с нашим сайтом.

Работает. Теперь переходим к хостингу.

Шаг 1.

Переходим на сайт https://console.cloud.yandex.ru/ и жмем на кнопку "Подключиться".

Примечание:

• Для пользования сервисом Яндекса может понадобится почта Яндекса (но это не точно)
• Для некоторых функций придется положить деньги на счет в личном кабинете (минимум 500 рублей).

После успешной регистрации и авторизации, мы в личном кабинете.

Далее слева в меню нужно найти сервис "Object Storage", который мы как раз будем использовать для хостинга сайта.

Коротко по терминам:

• Object Storage это хранилище файлов, совместимое с аналогичной технологией Амазона AWS S3, у которого также есть свой API для управления хранилищем из кода и его также как и AWS S3 можно использовать для размещения статического сайта.
• В Object Storage мы создаем "бакеты" (bucket / Корзина), которые являются отдельными хранилищами наших файлов.

Создадим один из них. Для этого в консоли сервиса жмем на кнопку "Создать бакет".

В форме создания бакета есть следующие поля, пробежимся по ним:

• Имя бакета. Для простоты, назовем так же как и ангуляр проект angular-habr-object-storage
• Макс. размер. Ставим столько, сколько у нас весит сайт, так как сайт хранится не бесплатно и за каждый выделенный гигабайт, мы будем платить Яндексу копеечку.
• Доступ для чтения объектов. Ставим "Публичный", так как пользователь должен получать каждый файл нашего статического сайта, чтобы на нем правильно отрисовывалась верстка, отрабатывали скрипты и тд.
• Доступ к списку объектов и Доступ на чтение настроек. Оставляем "Ограниченный". Это нужно для того, чтобы использовать бакет как внутреннее хранилище файлов для приложений.
• Класс хранилища. Оставляем "Стандартный". Это означает, что наш сайт часто будут посещать, а значит и часто скачивать файлы, составляющие сайт. Плюс пункт влияет на производительность и оплату (вставить ссылку).

Жмем "Создать бакет" и бакет создан.

Теперь нужно загрузить наш сайт в бакет. Самый простой способ открыть рядом папочку dist нашего сайта и ручками перетащить прямо на страницу. Это удобнее, чем жать на кнопку "Загрузить объекты", потому что в таком случае папки не переносятся и их придется создавать ручками в правильной последовательности.

Итак, сайт загружен в хранилище, тем можем предоставить пользователям возможность обращаться к хранилищу, как к сайту.
Для этого слева в меню жмем на вкладку "Веб-сайт".

На странице настройки бакета как сайта, выбираем таб "Хостинг". Здесь указываем главную страницу сайта, обычно это index.html. Если у вас SPA приложение, то вероятно все ошибки обрабатываются также на главной странице, поэтому укажем на странице ошибки также index.html.

Мы сразу видим, по какой ссылке будет доступен наш сайт. Жмем сохранить.

Через минут 5, перейдя по ссылке мы видим что теперь наш сайт доступен всем желающим.

Спасибо всем кто дочитал до конца! Это моя первая статья, планирую дальше описать другие сервисы Яндекса и их интеграцию с frontend и backend технологиями.

Напишите в комментариях насколько интересно вам узнать про другие сервисы Яндекса или про использование Angular в современной разработке.

Привет всем, друзья!

* Эта статья написана по мотивам открытого практикума REBRAIN & Yandex.Cloud, если вам больше нравится смотреть видео, можете найти его по этой ссылке https://youtu.be/cZLezUm0ekE

Недавно нам представилась возможность пощупать вживую Яндекс.Облако. Поскольку щупать хотелось долго и плотно, то мы сразу отказались от идеи запуска простого wordpress блога с облачной базой слишком скучно. После непродолжительных раздумий решили развернуть что-то похожее на продакшн архитектуру сервиса для приема и анализа ивентов в near real time режиме.

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

Итак, наша история: как мы писали приложение на golang, тестировали kafka vs rabbitmq vs yqs, писали стриминг данных в Clickhouse кластер и визуализировали данные с помощью yandex datalens. Естественно, все это было приправлено инфраструктурными изысками в виде docker, terraform, gitlab ci и, конечно же, prometheus. Погнали!

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

1 часть (вы ее читаете). Мы определимся с ТЗ и архитектурой решения, а также напишем приложение на golang.
2 часть. Выливаем наше приложение на прод, делаем масштабируемым и тестируем нагрузку.
3 часть. Попробуем разобраться, зачем нам нужно хранить сообщения в буфере, а не в файлах, а также сравним между собой kafka, rabbitmq и yandex queue service.
4 часть. Будем разворачивать Clickhouse кластер, писать стриминг для перекладывания туда данных из буфера, настроим визуализацию в datalens.
5 часть. Приведем всю инфраструктуру в должный вид настроим ci/cd, используя gitlab ci, подключим мониторинг и service discovery с помощью prometheus и consul.

ТЗ

Сперва сформулируем техзадание что именно мы хотим получить на выходе.
1. Мы хотим иметь endpoint вида events.kis.im (kis.im тестовый домен, который будем использовать на протяжении всех статей), который должен принимать event-ы с помощью HTTPS.
2. События это простая jsonка вида: {event: view, os: linux, browser: chrome}. На финальном этапе мы добавим чуть больше полей, но большой роли это не сыграет. Если есть желание можно переключиться на protobuf.
3. Сервис должен уметь обрабатывать 10 000 событий в секунду.
4. Должна быть возможность масштабироваться горизонтально простым добавлением новых инстансов в наше решение. И будет неплохо, если мы сможем выносить фронт-часть в различные геолокации для уменьшения latency при запросах клиентов.
5. Отказоустойчивость. Решение должно быть достаточно стабильным и уметь выживать при падении любых частей (до определенного количества, естественно).

Архитектура

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



Итак, что у нас есть:
1. Слева изображены наши устройства, которые генерируют различные события, будь то прохождения уровня игроков в игрушке на смартфоне или создание заказа в интернет-магазине через обычный браузер. Событие, как указано в ТЗ, простой json, который отправляется на наш endpoint events.kis.im.
2. Первые два сервера простые балансировщики, их основные задачи:

• Быть постоянно доступными. Для этого можно использовать, например, keepalived, который будет переключать виртуальный IP между нодами в случае проблем.
• Терминировать TLS. Да, терминировать TLS мы будем именно на них. Во-первых, чтобы наше решение соответствовало ТЗ, а во-вторых, для того, чтобы снять нагрузку по установлению шифрованного соединения с наших backend серверов.
• Балансировать входящие запросы на доступные backend сервера. Ключевое слово здесь доступные. Исходя из этого, мы приходим к пониманию, что load balancerы должны уметь мониторить наши сервера с приложениями и переставать балансировать трафик на упавшие ноды.

3. За балансировщиками у нас идут application сервера, на которых запущено достаточно простое приложение. Оно должно уметь принимать входящие запросы по HTTP, валидировать присланный json и складывать данные в буфер.
4. В качестве буфера на схеме изображена kafka, хотя, конечно, на этом уровне можно использовать и другие похожие сервисы. Kafka, rabbitmq и yqs мы сравним в третьей статье.
5. Предпоследней точкой нашей архитектуры является Clickhouse колоночная база данных, которая позволяет хранить и обрабатывать огромный объем данных. На данном уровне нам необходимо перенести данные из буфера в, собственно, систему хранения (об этом в 4 статье).

Такая схема позволяет нам независимо горизонтально масштабировать каждый слой. Не справляются backend сервера добавим еще ведь они являются stateless приложениями, а следовательно, это можно сделать хоть в автоматическом режиме. Не тянет буфер в виде кафки докинем еще серверов и перенесем на них часть партиций нашего топика. Не справляется кликхаус это невозможно :) На самом деле также докинем серверов и зашардируем данные.

Кстати, если вы захотите реализовать опциональную часть нашего ТЗ и сделать масштабирование в различных геолокациях, то нет ничего проще:



В каждой геолокации мы разворачиваем load balancer с application и kafka. В целом, достаточно 2 application сервера, 3 kafka ноды и облачного балансировщика, например, cloudflare, который будет проверять доступность нод приложения и балансировать запросы по геолокациям на основе исходного IP-адреса клиента. Таким образом данные, отправленные американским клиентом, приземлятся на американских серверах. А данные из Африки на африканских.

Дальше все совсем просто используем mirror tool из набора кафки и копируем все данные из всех локаций в наш центральный дата-центр, расположенный в России. Внутри мы разбираем данные и записываем их в Clickhouse для последующей визуализации.

Итак, с архитектурой разобрались начинаем шатать Яндекс.Облако!

Пишем приложение

До Облака еще придется немножко потерпеть и написать достаточно простой сервис для обработки входящих событий. Использовать мы будем golang, потому что он очень хорошо себя зарекомендовал как язык для написания сетевых приложений.

Потратив час времени (может, и пару часов), получаем примерно такую штуку: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Какие основные моменты здесь хотелось бы отметить:
1. При старте приложения можно указать два флага. Один отвечает за порт, на котором мы будем слушать входящие http запросы (-addr). Второй за адрес kafka сервера, куда мы будем записывать наши события (-kafka):

addr     = flag.String("addr", ":8080", "TCP address to listen to")kafka    = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints)

2. Приложение использует библиотеку sarama ([] github.com/Shopify/sarama) для отправки сообщений в kafka кластер. Мы сразу выставили настройки, ориентированные на максимальную скорость обработки:

config := sarama.NewConfig()config.Producer.RequiredAcks = sarama.WaitForLocalconfig.Producer.Compression = sarama.CompressionSnappyconfig.Producer.Return.Successes = true

3. Также в наше приложение встроен клиент prometheus, который собирает различные метрики, такие как:

• количество запросов к нашему приложению;
• количество ошибок при выполнении запроса (невозможно прочитать post запрос, битый json, невозможно записать в кафку);
• время обработки одного запроса от клиента, включая время записи сообщения в кафку.

4. Три endpointа, которые обрабатывает наше приложение:

• /status просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
• /metrics по этому url prometheus client будет возвращать собранные им метрики.
• /post основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок записывает данные в кафка-кластер.

Оговорюсь, что код не идеален его можно (и нужно!) допиливать. К примеру, можно отказаться от использования встроенного net/http и переключиться на более быстрый fasthttp. Или же выиграть время обработки и cpu ресурсы, вынеся проверку валидности json на более поздний этап когда данные будут перекладываться из буфера в кликхаус кластер.

Помимо разработческой стороны вопроса, мы сразу подумали о нашей будущей инфраструктуре и приняли решение разворачивать наше приложение через docker. Итоговый Dockerfile для сборки приложения https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. В целом, он достаточно простой, единственный момент, на который хочется обратить внимание, это multistage сборка, которая позволяет уменьшить итоговый образ нашего контейнера.

Первые шаги в облаке

Первым делом регистрируемся на cloud.yandex.ru. После заполнения всех необходимых полей нам создадут аккаунт и выдадут грант на некоторую сумму денег, которую можно использовать для тестирования сервисов облака. Если вы захотите повторить все шаги из нашей статьи, этого гранта вам должно хватить.

После регистрации для вас будет создано отдельное облако и каталог default, в котором можно начать создавать облачные ресурсы. Вообще в Яндекс.Облаке взаимосвязь ресурсов выглядит следующим образом:



На один аккаунт вы можете создать несколько облаков. А внутри облака сделать разные каталоги для разных проектов компании. Подробнее об этом можно почитать в документации https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Кстати, ниже по тексту я буду часто на нее ссылаться. Когда я настраивал всю инфраструктуру с нуля документация выручала меня не раз, так что советую поизучать.

Для управления облаком можно использовать как веб-интерфейс, так и консольную утилиту yc. Установка выполняется одной командой (для Linux и Mac Os):

curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash

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

Если вы хотите установить клиента для windows, то можно воспользоваться инструкцией здесь и затем выполнить yc init, чтобы полностью ее настроить:

vozerov@mba:~ $ yc initWelcome! This command will take you through the configuration process.Please go to https://oauth.yandex.ru/authorize?response_type=token&client_id= in order to obtain OAuth token.Please enter OAuth token:Please select cloud to use: [1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q) [2] fevlake-cloud (id = b1g6bvup3toribomnh30)Please enter your numeric choice: 2Your current cloud has been set to 'fevlake-cloud' (id = b1g6bvup3toribomnh30).Please choose folder to use: [1] default (id = b1g5r6h11knotfr8vjp7) [2] Create a new folderPlease enter your numeric choice: 1Your current folder has been set to 'default' (id = b1g5r6h11knotfr8vjp7).Do you want to configure a default Compute zone? [Y/n]Which zone do you want to use as a profile default? [1] ru-central1-a [2] ru-central1-b [3] ru-central1-c [4] Don't set default zonePlease enter your numeric choice: 1Your profile default Compute zone has been set to 'ru-central1-a'.vozerov@mba:~ $

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

Если у вас несколько аккаунтов или папок внутри одного облака, можете создать дополнительные профили с отдельными настройками через yc config profile create и переключаться между ними.

Помимо вышеперечисленных способов, команда Яндекс.Облака написала очень хороший плагин для terraform для управления облачными ресурсами. Со своей стороны, я подготовил git-репозиторий, где описал все ресурсы, которые будут созданы в рамках статьи https://github.com/rebrainme/yandex-cloud-events/. Нас интересует ветка master, давайте склонируем ее себе локально:

vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ eventsCloning into 'events'...remote: Enumerating objects: 100, done.remote: Counting objects: 100% (100/100), done.remote: Compressing objects: 100% (68/68), done.remote: Total 100 (delta 37), reused 89 (delta 26), pack-reused 0Receiving objects: 100% (100/100), 25.65 KiB | 168.00 KiB/s, done.Resolving deltas: 100% (37/37), done.vozerov@mba:~ $ cd events/terraform/

Все основные переменные, которые используются в terraform, прописаны в файле main.tf. Для начала работы создаем в папке terraform файл private.auto.tfvars следующего содержания:

# Yandex Cloud Oauth tokenyc_token = ""# Yandex Cloud IDyc_cloud_id = ""# Yandex Cloud folder IDyc_folder_id = ""# Default Yandex Cloud Regionyc_region = "ru-central1-a"# Cloudflare emailcf_email = ""# Cloudflare tokencf_token = ""# Cloudflare zone idcf_zone_id = ""

Все переменные можно взять из yc config list, так как консольную утилиту мы уже настроили. Советую сразу добавить private.auto.tfvars в .gitignore, чтобы ненароком не опубликовать приватные данные.

В private.auto.tfvars мы также указали данные от Cloudflare для создания dns-записей и проксирования основного домена events.kis.im на наши сервера. Если вы не хотите использовать cloudflare, то удалите инициализацию провайдера cloudflare в main.tf и файл dns.tf, который отвечает за создание необходимых dns записей.

Мы в своей работе будем комбинировать все три способа и веб-интерфейс, и консольную утилиту, и terraform.

Виртуальные сети

Честно говоря, этот шаг можно было бы и пропустить, поскольку при создании нового облака у вас автоматически создастся отдельная сеть и 3 подсети по одной на каждую зону доступности. Но все же хотелось бы сделать для нашего проекта отдельную сеть со своей адресацией. Общая схема работы сети в Яндекс.Облаке представлена на рисунке ниже (честно взята с https://cloud.yandex.ru/docs/vpc/concepts/)



Итак, вы создаете общую сеть, внутри которой ресурсы смогут общаться между собой. Для каждой зоны доступности делается подсеть со своей адресацией и подключается к общей сети. В итоге, все облачные ресурсы в ней могут общаться, даже находясь в разных зонах доступности. Ресурсы, подключенные к разным облачным сетям, могут увидеть друг друга только через внешние адреса. Кстати, как эта магия работает внутри, было хорошо описано на хабре http://personeltest.ru/aways/habr.com/en/company/yandex/blog/487694/.

Создание сети описано в файле network.tf из репозитория. Там мы создаем одну общую приватную сеть internal и подключаем к ней три подсети в разных зонах доступности internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).

Инициализируем terraform и создаем сети:

vozerov@mba:~/events/terraform (master) $ terraform init... skipped ..vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_vpc_subnet.internal-a -target yandex_vpc_subnet.internal-b -target yandex_vpc_subnet.internal-c... skipped ...Plan: 4 to add, 0 to change, 0 to destroy.Do you want to perform these actions?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.  Enter a value: yesyandex_vpc_network.internal: Creating...yandex_vpc_network.internal: Creation complete after 3s [id=enp2g2rhile7gbqlbrkr]yandex_vpc_subnet.internal-a: Creating...yandex_vpc_subnet.internal-b: Creating...yandex_vpc_subnet.internal-c: Creating...yandex_vpc_subnet.internal-a: Creation complete after 6s [id=e9b1dad6mgoj2v4funog]yandex_vpc_subnet.internal-b: Creation complete after 7s [id=e2liv5i4amu52p64ac9p]yandex_vpc_subnet.internal-c: Still creating... [10s elapsed]yandex_vpc_subnet.internal-c: Creation complete after 10s [id=b0c2qhsj2vranoc9vhcq]Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

Отлично! Мы сделали свою сеть и теперь готовы к созданию наших внутренних сервисов.

Создание виртуальных машин

Для тестирования приложения нам будет достаточно создать две виртуалки первая нам потребуется для сборки и запуска приложения, вторая для запуска kafka, которую мы будем использовать для хранения входящих сообщений. И создадим еще одну машинку, где настроим prometheus для мониторинга приложения.

Настраиваться виртуалки будут с помощью ansible, так что перед запуском terraform убедитесь, что у вас стоит одна из последних версий ансибла. И установите необходимые роли с ansible galaxy:

vozerov@mba:~/events/terraform (master) $ cd ../ansible/vozerov@mba:~/events/ansible (master) $ ansible-galaxy install -r requirements.yml- cloudalchemy-prometheus (master) is already installed, skipping.- cloudalchemy-grafana (master) is already installed, skipping.- sansible.kafka (master) is already installed, skipping.- sansible.zookeeper (master) is already installed, skipping.- geerlingguy.docker (master) is already installed, skipping.vozerov@mba:~/events/ansible (master) $

Внутри папки ansible есть пример конфигурационного файла .ansible.cfg, который использую я. Возможно, пригодится.

Перед тем, как создавать виртуалки, убедитесь, что у вас запущен ssh-agent и добавлен ssh ключик, иначе terraform не сможет подключиться к созданным машинкам. Я, конечно же, наткнулся на багу в os x: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. Чтобы у вас не повторилась такая история, перед запуском Terraform добавьте небольшую переменную в env:

vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

В папке с терраформом создаем необходимые ресурсы:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_compute_instance.build -target yandex_compute_instance.monitoring -target yandex_compute_instance.kafkayandex_vpc_network.internal: Refreshing state... [id=enp2g2rhile7gbqlbrkr]data.yandex_compute_image.ubuntu_image: Refreshing state...yandex_vpc_subnet.internal-a: Refreshing state... [id=e9b1dad6mgoj2v4funog]An execution plan has been generated and is shown below.Resource actions are indicated with the following symbols:  + create... skipped ...Plan: 3 to add, 0 to change, 0 to destroy.... skipped ...

Если все завершилось удачно (а так и должно быть), то у нас появятся три виртуальные машины:

1. build машинка для тестирования и сборки приложения. Docker был установлен автоматически ansibleом.
2. monitoring машинка для мониторинга на нее установлен prometheus & grafana. Логин / пароль стандартный: admin / admin
3. kafka небольшая машинка с установленной kafka, доступная по порту 9092.

Убедимся, что все они на месте:

vozerov@mba:~/events (master) $ yc compute instance list+----------------------+------------+---------------+---------+---------------+-------------+|          ID          |    NAME    |    ZONE ID    | STATUS  |  EXTERNAL IP  | INTERNAL IP |+----------------------+------------+---------------+---------+---------------+-------------+| fhm081u8bkbqf1pa5kgj | monitoring | ru-central1-a | RUNNING | 84.201.159.71 | 172.16.1.35 || fhmf37k03oobgu9jmd7p | kafka      | ru-central1-a | RUNNING | 84.201.173.41 | 172.16.1.31 || fhmt9pl1i8sf7ga6flgp | build      | ru-central1-a | RUNNING | 84.201.132.3  | 172.16.1.26 |+----------------------+------------+---------------+---------+---------------+-------------+

Ресурсы на месте, и отсюда можем вытащить их ip-адреса. Везде далее я буду использовать ip-адреса для подключения по ssh и тестирования приложения. Если у вас есть аккаунт на cloudflare, подключенный к terraform, смело используйте свежесозданные DNS-имена.
Кстати, при создании виртуалке выдается внутренний ip и внутреннее DNS-имя, так что обращаться к серверам внутри сети можно по именам:

ubuntu@build:~$ ping kafka.ru-central1.internalPING kafka.ru-central1.internal (172.16.1.31) 56(84) bytes of data.64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 time=1.23 ms64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 time=0.625 ms^C--- kafka.ru-central1.internal ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1001msrtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 ms

Это нам пригодится для указания приложению endpointа с kafkой.

Собираем приложение

Отлично, сервачки есть, приложение есть осталось только его собрать и опубликовать. Для сборки будем использовать обычный docker build, а вот в качестве хранилища образов возьмем сервис от яндекса container registry. Но обо всем по порядку.

Копируем на build машинку приложение, заходим по ssh и собираем образ:

vozerov@mba:~/events/terraform (master) $ cd ..vozerov@mba:~/events (master) $ rsync -av app/ ubuntu@84.201.132.3:app/... skipped ...sent 3849 bytes  received 70 bytes  7838.00 bytes/sectotal size is 3644  speedup is 0.93vozerov@mba:~/events (master) $ ssh 84.201.132.3 -l ubuntuubuntu@build:~$ cd appubuntu@build:~/app$ sudo docker build -t app .Sending build context to Docker daemon  6.144kBStep 1/9 : FROM golang:latest AS build... skipped ...Successfully built 9760afd8ef65Successfully tagged app:latest

Полдела сделано теперь можно проверить работоспособность нашего приложения, запустив его и направив на kafka:

ubuntu@build:~/app$ sudo docker run --name app -d -p 8080:8080 app /app/app -kafka=kafka.ru-central1.internal:9092</code>С локальной машинки можно отправить тестовый event и посмотреть на ответ:<code>vozerov@mba:~/events (master) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://84.201.132.3:8080/postHTTP/1.1 200 OKContent-Type: application/jsonDate: Mon, 13 Apr 2020 13:53:54 GMTContent-Length: 41{"status":"ok","partition":0,"Offset":0}vozerov@mba:~/events (master) $

Приложение ответило успехом записи и указанием id партиции и оффсета, в который попало сообщение. Дело за малым создать registry в Яндекс.Облаке и закинуть туда наш образ (как это сделать при помощи трех строчек, описано в registry.tf файле). Создаем хранилище:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_container_registry.events... skipped ...Plan: 1 to add, 0 to change, 0 to destroy.... skipped ...Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Для аутентификации в container registry есть несколько способов с помощью oauth токена, iam токена или ключа сервисного аккаунта. Более подробно об этих способах в документации https://cloud.yandex.ru/docs/container-registry/operations/authentication. Мы будем использовать ключ сервисного аккаунта, поэтому создаем аккаунт:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_iam_service_account.docker -target yandex_resourcemanager_folder_iam_binding.puller -target yandex_resourcemanager_folder_iam_binding.pusher... skipped ...Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Теперь осталось сделать для него ключик:

vozerov@mba:~/events/terraform (master) $ yc iam key create --service-account-name docker -o key.jsonid: ajej8a06kdfbehbrh91pservice_account_id: ajep6d38k895srp9osijcreated_at: "2020-04-13T14:00:30Z"key_algorithm: RSA_2048

Получаем информацию об id нашего хранилища, перекидываем ключ и авторизуемся:

vozerov@mba:~/events/terraform (master) $ scp key.json ubuntu@84.201.132.3:key.json                                                                                                                    100% 2392   215.1KB/s   00:00vozerov@mba:~/events/terraform (master) $ ssh 84.201.132.3 -l ubuntuubuntu@build:~$ cat key.json | sudo docker login --username json_key --password-stdin cr.yandexWARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json.Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-storeLogin Succeededubuntu@build:~$

Для загрузки образа в реестр нам понадобится ID container registry, берем его из утилиты yc:

vozerov@mba:~ $ yc container registry get eventsid: crpdgj6c9umdhgaqjfmmfolder_id:name: eventsstatus: ACTIVEcreated_at: "2020-04-13T13:56:41.914Z"

После этого тегируем наш образ новым именем и загружаем:

ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1The push refers to repository [cr.yandex/crpdgj6c9umdhgaqjfmm/events]8c286e154c6e: Pushed477c318b05cb: Pushedbeee9f30bc1f: Pushedv1: digest: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 size: 946

Можем убедиться, что образ успешно загрузился:

vozerov@mba:~/events/terraform (master) $ yc container repository list+----------------------+-----------------------------+|          ID          |            NAME             |+----------------------+-----------------------------+| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |+----------------------+-----------------------------+

Кстати, если вы установите утилиту yc на машинку с linux, то можете использовать команду

yc container registry configure-docker

для настройки докера.

Заключение

Мы проделали большую и трудную работу и в результате:

1. Придумали архитектуру нашего будущего сервиса.
2. Написали приложение на golang, которое реализует нашу бизнес-логику.
3. Собрали его и вылили в приватный container registry.

В следующей части перейдем к интересному выльем наше приложение в production и наконец запустим на него нагрузку. Не переключайтесь!

Этот материал есть в видеозаписи открытого практикума REBRAIN & Yandex.Cloud: Принимаем 10 000 запросов в секунду на Яндекс Облако https://youtu.be/cZLezUm0ekE


Если вам интересно посещать такие мероприятия онлайн и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN https://rebrainme.com/channel

Отдельное спасибо хотим сказать Yandex.Cloud за возможность проведения такого мерпориятия. Ссылочка на них https://cloud.yandex.ru/prices

Если вам нужен переезд в облако или есть вопросы по вашей инфраструктуре, смело оставляйте заявку https://fevlake.com

P.S. У нас есть 2 бесплатных аудита в месяц, возможно, именно ваш проект будет в их числе.

Облачные технологии, инфраструктура как сервис и платформенные сервисы из нишевых решений давно перешли в стандарт де-факто для размещения приложений не только стартапов, но и крупных финансовых компаний, госкомпаний, автомобильных гигантов и популярных игровых сервисов. Компании Netflix и Spotify, Dropbox и Instagram начинали свой путь на облачных ресурсах, не инвестируя в собственную инфраструктуру. Совокупная выручка мировых поставщиков облачных услуг в 2019 году превысила бюджет Российской Федерации. В этой статье мы рассмотрим рынок облачных услуг в России. Мы сравним его с мировыми трендами и определим опережаем мы или отстаём от мировых лидеров в развитии облачных услуг и насколько.

Как все начиналось

Публичные облака в РФ появились как эволюционное развитие собственной инфраструктуры виртуализации. Следуя за трендами в корпоративном сегменте, они были основаны на привычных крупным заказчикам технических решениях, таких как Microsoft Hyper-V и VMware vSphere, c установкой портала самообслуживания (Windows Azure Pack или vCloud Director for SP). Клиенты получали понятный им функционал: знакомые инструменты управления, мониторинга и резервного копирования всё, с чем клиенты работали каждый день.

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

Инфраструктура, обеспечивающая ресурсы платформы виртуализации, должна быть в списке совместимой и поддерживаемой. Для этого чаще всего используются серверы именитых производителей (Dell EMC, HPE, Lenovo, Huawei и др.) и выделенные СХД, подключаемые как блочные устройства по протоколу FС. Приобретение и поддержка такой инфраструктуры это основная статья затрат в эксплуатации облачной платформы. Функционал и развитие облачной платформы целиком определяется выбранным вендором.

Параллельно стали появляться публичные облака, как эластичная инфраструктура, от нетипичных игроков на рынке из таких индустрий, как retail (Amazon), e-commerce (Alibaba) и интернет (Google).

Используя наработки на базе собственных on-premise технологий, в популярного поставщика облачных услуг превратилась компания Microsoft с их платформой Azure.

Большинство игроков частично использовали решения open-source. Например, Amazon использовал гипервизор Xen, а сейчас переключился на KVM. Кто-то использовал платформу с открытым исходным кодом OpenStack, дорабатывая ее под свои нужды.

Запуск решения на базе готовой платформы с открытым исходным кодом позволяет сократить время выхода на рынок, особенно если нет достаточно зрелых технологий, на базе которых можно построить собственную инфраструктуру. Вокруг популярной платформы обычно довольно зрелая экосистема с необходимым набором утилит для организации DevOps конвейера, мониторинга, автоматизации и оркестрации. Такой платформой можно считать Mail.ru Cloud Solutions (MCS) на базе Openstack.

Яндекс для своей платформы Яндекс.Облако принял решение развивать собственную архитектуру системы управления и оркестрации. Для этого они частично переиспользовали собственные наработки. Из-за этого образовался технический долг на старте запуска платформы, который приходится закрывать семимильными шагами.

Немного о сравнении

Мы сравним эти два подхода к построению облачной инфраструктуры от компаний Mail.ru Group и Яндекс. Остановимся только на ключевых отличиях и посвятим сравнению цикл статей. В первой статье мы начнем с IaaS, во второй статье планируем остановиться на сетевых сервисах и PaaS, в третьей на SaaS, мониторинге и сервисной поддержке.


На каждом этапе сравнения будем брать ориентир на облачную платформу Microsoft Azure. Это поможет нам понять, насколько компании Яндекс и Mail.ru Group приблизились в технологическом аспекте к одному из мировых лидеров в области предоставления облачных услуг.

ЦОД

Обеспечить высокую доступность наших сервисов нам помогает хорошо спроектированная архитектура, способная переживать любые отказы компонент. Однако какой бы не была идеальной наша архитектура, отказ дата-центра сведет все наши старания на нет. Ввиду этого избыточность на уровне ЦОД для приложений с такими требованиями является обязательной.


Рис. 2. Архитектура ЦОД ближайшего к России региона Azure

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

Важным преимуществом платформ MCS и Яндекс.Облако по сравнению с Microsoft Azure является наличие дата-центов на территории Российской Федерации. Если ваш сервис должен соответствовать требованиям Федерального закона О персональных данных (ФЗ-152), то развертывание его в облаке от зарубежного поставщика потребует внедрения дополнительных технических решений, так как первичная обработка персональных данных (ПДн) должна происходить на территории Российской Федерации и в дальнейшем данные должны передаваться по защищенным каналам связи. Невыполнение требований о защите ПДн может привести к блокировке доступа к сервису Роскомнадзором.


Рис. 3. Архитектура ЦОД платформы MCS

Облачная платформа от Mail.ru Group размещена на территории города Москвы в двух арендованных дата-центрах: DataLine на Коровинском шоссе и DataPro на Авиамоторной улице. Последний имеет сертификацию Uptime Institute. Между дата-центрами организован канал 40 Гбит/с с длиной трассы около 25 км. Это позволяет нам рассматривать оба дата-центра, как площадки для построения высокодоступных (High-Availability) кластеров с узлами в каждом из дата-центров с синхронной репликацией данных между ними, но без так называемой кворум площадки.

Сетевая архитектура облака имеет растянутые L2 сети между площадками. Это дает нам возможность использовать технические средства отказоустойчивости: Keepalived, Veritas Cluster Server, Microsoft Windows Server Failover Cluster и прочие. Такие средства увеличивают наши шансы на миграцию большинства legacy решений в IaaS данного поставщика. При этом мы сохраняем отказоустойчивость архитектуры, которую мы использовали на собственном оборудовании on-premise.

Арендованные ЦОД позволяют MCS предоставить дополнительный сервис для клиентов, когда поставщик облачных услуг предоставляет в аренду различное оборудование для клиента с подключением его к облачной платформе.


Стоит отметить, что компоновка оборудования самого облака стандартизирована и проходит все стадии тестирования внутри компании.

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


Рис. 4. Архитектура ЦОД платформы Яндекс.Облако

Облако от компании Яндекс в свою очередь размещено в трех собственных дата-центрах, расположенных в Московской, Владимирской и Рязанской областях. Каждый ЦОД проектировался и строился самостоятельно. Яндекс эксплуатируют их с соблюдением международных и собственных стандартов. Надо отметить, что опыт в построении дата-центов у Яндекса действительно имеется.

Компания следит за энергоэффективностью собственных дата-центров, поэтому все оборудование, установленное в них, соответствует стандартам компании. Клиентское оборудование в ЦОД не устанавливается. Дополнительным преимуществом является отсутствие проблем с контролем доступа в дата-центры.

Три полноценные площадки позволяют разворачивать любые отказоустойчивые архитектуры. Однако большая удаленность, порядка 200 км друг от друга, не позволяет развернуть кластера высокой доступности (High-Availability) с узлами в каждом из дата-центров с возможностью синхронной репликации данных между ними. Также отсутствие L2 между дата-центрами ограничивает нас в возможности развернуть здесь legacy решения.

Архитектура IaaS платформы

Модель обслуживания Infrastructure-as-a-Service (IaaS), как описано в стандарте NIST, это возможность предоставить клиенту вычислительные, сетевые ресурсы и ресурсы хранения данных, на базе которых клиент сам размещает и управляет операционными системами и приложениями. Современная IaaS платформа включает в себя гипервизор, предоставляющий вычислительные ресурсы, программно-определяемую систему хранения данных software-defined storage (SDS) для размещения данных и программно-определяемую сеть software-defined networking (SDN) как средство организации сетевого доступа к ресурсам IaaS.

Референтная платформа нашего сравнения, Azure от компании Microsoft, начинает свою историю еще в далеком 2003-м году с приобретения компании Connetix и их продукта Virtual PC с целью догнать конкурента VMware и их продукт GSX Server, вышедший двумя годами ранее. Спустя время продукт Virtual PC интегрировали в состав платформы Windows Server. Он появился в версии 2008, но только к версии 2012 были реализованы SDS на базе Scale-Out File Server и Storage Spaces и SDN на базе Hyper-V Network Virtualization. Это позволило построить целиком программно-определяемую платформу IaaS без привязки к аппаратным возможностям СХД или оборудования ЛВС.

Платформа Azure поддерживается большинством современных DevOps утилит как для построения конвейера непрерывного развертывания, так и для автоматизации рутинных задач. У Azure функциональный веб-интерфейс и подробно документированный API. Все крупные игроки по разработке платформ автоматизации и управления облачными платформами поддерживают Azure. Утилита командной строки Azure CLI доступна как расширение PowerShell и как отдельная утилита для платформ Windows, Linux и MacOS X.

Компания Mail.ru Group для своего облака взяла наработки платформы OpenStack. К 2020 году компания перешла на полностью собственный дистрибутив, который не связан с open-source версией платформы. В качестве гипервизора используется функция ядра ОС Linux Kernel-based Virtual Machine (KVM), основным разработчиком которого является компания Red Hat, ныне часть IBM. Объем доработок KVM, которые выполнили разработчики MCS, компания не раскрывает. В части SDS для блочных устройств и сервиса NFS используется решение CEPH его тоже дорабатывала команда MCS. Для объектного хранилища S3 были переиспользованы технологии облачного диска Mail.ru Group. В качестве сетевого решения применяется решение на базе OpenvSwitch, однако механизмы управления Control plane были серьезно переработаны. Это дало жизнь проекту Sprut.

Для управления платформой MCS был реализован отдельный портал, в котором реализованы самые популярные сервисы, а также доступен нативный интерфейс OpenStack Horizon. Для тонкой настройки сервисов предоставляется доступ к OpenStack CLI или OpenStack API. Есть также возможность использовать решение Infrastructure as Code (IaC) которое будет обращаться напрямую к API платформы. Работу с OpenStack поддерживает большинство систем управления конфигурацией, что упрощает встраивание облака MCS в DevOps конвейер и внешние системы управления облачными ресурсами.

Как было у Яндекса? Первую версию своей платформы компания разрабатывала для себя. Яндекс, так же, как и Mail.ru Group ориентировался на архитектуру и компоненты OpenStack. Однако, потом компания отказалась от нее. Было принято решение начать с чистого листа. Яндекс переиспользовал базовые инфраструктурные компоненты, которые у них уже были. К ним компания дополнительно разработала недостающие модули и платформу управления.

В качестве гипервизора компания Яндекс также использует KVM. В его разработку инвестированы большие ресурсы. Решения SDS и SDN были разработаны компанией самостоятельно. SDS основан на собственной СУБД Yandex Database (YDB) для хранения мета-данных о размещении виртуальных машин и Network Block Storage (NBS) как сервиса предоставления блочных устройств виртуальным машинам, также YDB используется и в S3-совместимом решении в составе платформы. Яндекс, в отличии от MCS и Azure, не предлагает сервис NFS в составе услуг, рекомендуя развернуть его на базе виртуальной машины. В качестве SDN используется переработанная платформа OpenContrail. Её разрабатывали Juniper Networks, которая с недавнего времени входит в Linux Foundation, как платформа TungstenFabric.

Использование собственной платформы управления ограничивает возможности по встраиванию ресурсов Яндекс.Облака в конвейер DevOps или внешние системы управления облачными ресурсами. В настоящий момент заявлена поддержка IaC Terraform с помощью разработанного компанией провайдера. Ещё существует неофициальная поддержка работы с Ansible. Однако, среди популярных систем для управления Гибридными Облаками (Cloud Management Platforms) таких как Red Hat CloudForms, Morpheus, Scalr, поддержка отсутствует. Компания также разработала и поддерживает свою собственную утилиту YC CLI для работы с платформой из командной строки с собственным набором команд.

Хранение данных

У MCS есть репликация блочных устройств между зонами доступности, что позволяет запустить виртуальную машину с теми же данными на любой из площадок, а также получить высокопроизводительный локальный диск NVMe или общее СХД по протоколу ISCSI. Azure предлагает репликацию объектных хранилищ как внутри зоны доступности, так и между зонами в пределах географического региона, а также сервис Azure Site Recovery для репликации блочных устройств. Обе платформы предоставляют сервис NFS.

В платформе Яндекс.Облако нет синхронной репликации блочных устройств между зонами доступности. Реплицируются только резервные копии и S3-хранилище. Репликация данных для Яндекс.Облака может быть реализована средствами приложения или СУБД. Отсутствие репликации блочных устройств связано с тем, что ЦОДы располагаются достаточно далеко и синхронная репликация будет вносить значительные задержки в дисковый ввод-вывод. Сервис NFS платформой Яндекс.Облако не предоставляется.

Образы виртуальных машин

В отличие от Azure, в MCS отсутствует возможность развернуть ВМ с использованием enterprise-level дистрибутива ОС Linux (RHEL, SLES, OEL). Платформа Яндекс.Облако позволяет развернуть ВМ с ОС RHEL версии 7.8, но подписку клиент должен оформлять самостоятельно через стороннюю организацию.

Оба провайдера поддерживают загрузку собственных образов ОС. Яндекс поддерживает форматы qcow (qemu), vhd (Microsoft Hyper-V/Azure) и vmdk (VMware ESXi), но отсутствует возможность импорта ova/ovf формата. MCS поддерживает загрузку формата RAW, для которого требуется конвертация с помощью стандартной утилиты из пакета Qemu. Ещё он поддерживает конвертацию на лету при загрузке через веб-интерфейс портала. Azure позволяет загружать собственные образы в формате VHD (формат Hyper-V).

SLA

Уровни SLA отличаются между платформами. MCS и Azure предоставляют SLA в рамках доступности на каждый из облачных сервисов, а также на отдельные параметры внутри сервиса например, на IOPS для блочных устройств. Яндекс же оперирует только доступностью сервиса, не включая характеристики отдельных компонент. Все провайдеры компенсируют часть счета на услуги в зависимости от времени простоя сервиса. Яндекс отдельно упоминает о возможности полной компенсации платежей в случае потери данных клиента.

IAM

Все платформы предоставляют сервис управления учетными записями и правами Identity and Access Management (IAM).

Яндекс для этого требует наличия учетной записи в сервисе Яндекс.Паспорт или интеграцию с внешним провайдером учетных записей посредством протокола SAML, например, AD FS, и позволяет управлять квотами и правами в контексте облачных услуг.

Компания Mail.ru Group расширила функционал, заложенный в IAM для Openstack в части работы с собственным сервисом S3, и близка по возможностям к сервису платформы Яндекс.Облако.

Обе платформы не предполагают сценариев интеграции IAM для собственных приложений клиента.

Наиболее богатый функционал IAM у Azure. Кроме управления облачной инфраструктурой есть возможность получить Active Directory, как услугу. Есть возможность использовать IAM для интеграции с приложениями в облаке для управления учетными записями клиентов компании. Все платформы поддерживают управление собственными SSH ключами для Linux систем.

Управляемые сервисы VPN и DNS

Для полноценного использования платформы IaaS нам требуются такие сервисы, как Managed VPN и Managed DNS. Azure позволяет управлять внешними и внутренними DNS зонами, обычными или техническими DNS записями, а также автоматически регистрировать новые DNS записи при создании ВМ. В MCS функционал ограничен созданием внутренней DNS зоны и автоматической регистрацией ВМ в ней, с возможностью создания произвольного имени или же привязки DNS-записи к сетевому порту (IP адресу), но без возможности управления техническими записями. В платформе Яндекс.Облако отсутствует возможность управлять записям DNS.

Если говорить об организации защищенного подключения и пиринга, то наиболее полный функционал у Azure. В нём есть поддержка режимов client-to-site, site-to-site и прямого пиринга по протоколу BGP. Пропускная способность VPN-линка к Azure ограничивается оконечным оборудованием клиента. MCS поддерживает только режим site-to-site для протокола IPSec. Яндекс только технологию прямого соединения (название сервиса Yandex.Cloud Interconnect) по протоколу BGP. Для организации защищенного канала VPN к платформе Яндекс.Облако потребуется развернуть Cisco CSR, Mikrotik CHR или другое VPN решение из маркетплейса.

On-Premise решение для частного облака

Все поставщики облачных услуг предоставляют возможность развертывания своей платформы на оборудовании заказчика (on-premise). Частное облако может быть интегрировано с публичной платформой от данного поставщика для организации гибридного решения с единым порталом управления, репликацией машин и Disaster Recovery площадкой в публичном облаке. Есть отличие предоставления сервиса и вот в чём оно состоит. Microsoft и Яндекс поставляют собственные решения в виде готового к установке в ЦОД оборудования. Компания Mail.ru Group может поставить свое решение на оборудование клиента, совместимого с их платформой.

Итоги сравнения

Подведём итоги сравнения платформ MCS и Яндекс.Облако в части IaaS. Производители данных решений не до конца реализовали весь функционал, необходимый для полноценного перехода инфраструктуры клиента на их сервисы. Отсутствие или недостаточная реализация функционала таких сервисов, как VPN и DNS, требует от клиента наличия своей собственной команды для их поддержки. Это создаёт технический долг, который компании обещают закрыть.

Основные отличия между платформами кратко:


Сравнивая функционал у обоих игроков, оценим его как почти равный. Разве что MCS выглядит более зрелым игроком. На это две причины: разница в возрасте, около полутора лет с момента запуска, и использование наработок из эко системы Openstack. С другой стороны в мире не так много крупных облачных сервисов, построенных на базе Openstack. Если развитие данной платформы будет приостановлено, то компания Mail.ru Group будет вынуждена продолжать разработку в одиночку, будучи скованной архитектурными паттернами родительской платформы Openstack.

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

Продолжаем эксперименты по установке различных SAP систем в Яндекс Облаке.

В первой части (статья была опубликована в блоге Яндекс Облака) был рассмотрена установка платформы SAP Netweaver ABAP AS, которая является основой для большинства SAP систем. В этой публикации мы перейдем от сервера приложений к уровню базы данных.

Изначально SAP Netweaver работал на широком спектре баз данных, среди которых были как принадлежащие компании SAP (SAP MaxDB, SAP ASE) так и базы данных от сторонних производителей (DB2, Oracle и MS SQL Server). Ситуация кардинально начала меняться в 2015 году с выходом SAP HANA (High-performance Analytic Appliance). Эта база данных позиционировалась компанией SAP как революционный для рынка продукт:

• обработка всех запросов осуществляется исключительно в оперативной памяти
• совмещение построчного и поколоночного хранение данных
• встроенные библиотеки PAL (Predictive Analytics Library), BFL (Business Function Library), Text Analysis, SAP HANA SQLScript и другие инструменты для подготовки данных на стороне базы данных и таким образом уменьшения обмена данными с сервером приложений.

Чтобы максимально использовать потенциал новой БД в SAP перерабатывают свою флагманскую ERP-система, которая выходит в 2015 году под названием S/4HANA и уже работает исключительно на базе SAP HANA. В последствии глубоко переработанные HANA версии появляются у других популярных продуктов хранилища данных BW (Business Warehouse) решение выходит на рынок под названием SAP BW/4HANA и у CRM-системы решение выходит на рынок под названием SAP C/4HANA.

Остальные SAP ABAP и JAVA системы, например, шина данных SAP Process Orсhestration теперь могут использовать SAP HANA, как одну из доступных для установки баз данных, наряду с Oracle, DB2 и другими.

Поскольку SAP HANA является мультиконтейнерной базой данных, типичный корпоративный SAP ландшафт выглядит следующим образом:



в этом скриношоте каждый тенант это изолированная база данных какой-либо SAP системы (SAP Process Orсhestration, SAP EWM, SAP ATTP, SAP S/4HANA и т.д) внутри одной инсталляции SAP HANA.

Со временем у SAP появились также и коммерческие продукты которые представляют собой связку веб-приложение + база данных SAP HANA.

Например, SAP Medical Research Insights. Данная система должна помочь врачам выработать правильный план лечения, опирающийся на огромный массив данных, в том числе и о генетических исследованиях.



Еще один важный момент это наличие в архитектуре SAP HANA встроенного веб сервера (SAP HANA Extended Application Service). Данный сервер имеет привилегированный доступ к базе данных и позволяет выполнять приложения на Java, Python, Node.js и множестве других языков программирования. В версии сервиса Advanced Model (XSA) в ландшафте SAP HANA появляется такой функционал, как интегрированная среда разработки с веб-интерфейсом (SAP WEB IDE), Codereview (Gerrit) планировщик зданий (SAP XS JOB SCHEDULER) и многое другое.

Архитектура SAP HANA XSA:



Появление и постоянное развитие SAP HANA требует новых знаний у администраторов и разработчиков приложений. Возможность установить и экспериментировать со своей собственной базой и средой разработки в облаке представляется в этом случае далеко не лишней.

Однако SAP HANA будет интересна не только в Enterprise-среде, и не только среди разработчиков SAP. Благодаря гибкой лицензионной политики этот продукт можно бесплатно установить и использовать, в том числе и в коммерческих целях (размер в этом случае ограничен 32 GB) Возможно приведённый ниже пример установки и использования даст идею о том какое место может занять база данных SAP HANA и SAP HANA Extended Application Service в Вашем проекте.

Шаг 1. Скачиваем установочные файлы SAP HANA

Заходим на страницу загрузки SAP HANA, express edition и если у Вас нет учетной записи в SAP необходимо пройти простую регистрацию



Скачиваем и запускаем SAP HANA Express Edition Download Manager



В Download Manager укажем следующие варианты загрузки
Платформа Linux/x86 64
Image Binary Installer
Package Applications*



* Под Applications подразумевается база данных SAP HANA, сервер приложений и среда разработки SAP HANA Extended Application Services, Advanced Model (XSA)

Шаг 2. Создаём виртуальную машину в Яндекс Облаке

На этом шаге нам понадобится следующий бесплатный софт:

• PuTTY SSH-клиент.
• PuTTYgen Генератор Public/Private ключей.
• WinSCP SFTP-клиент.

Как альтернативу для данных приложений можно также рассмотреть приложение MobaXTerm
Создадим связку Public-Private ключ с помощью PuTTYgen.



Регистрируемся / заходим в Яндекс Облако (http://personeltest.ru/aways/cloud.yandex.ru/). Переходим в раздел Compute Cloud и приступаем к созданию виртуальной машины.

Имя виртуальной машины: saphana2

Зададим подходящие характеристики ВМ. В руководстве по установке для SAP HANA Express Edition (Server + Application) видим следующие рекомендуемые параметры:



Зададим их при создании нашей виртуальной машины.

vCPU 2,
RAM 32GB,
15 GB + 150 GB, где
15 GB (загрузочный диск SSD)
150 GB (данные * HDD)

* т.к. SAP HANA все операции проводит в оперативной памяти в качестве носителя для снепшота данных мы можем выбрать более медленный HDD

В качестве операционной системы выберем последнюю стабильную ОС OpenSUSE, на момент написания статьи это версия ОС OpenSUSE 42.3



Укажем Логин и Public SSH-ключ, сгенерированный с помощью PuTTYgen

Шаг 3. Подготавливаем виртуальную машину к установке SAP HANA XSA

Находим в настройках Публичный IPv4 адрес:



Подключаемся к созданной ВМ с помощью Putty-клиента, указав в подключении публичный IPv4, заданный логин и путь к Private ключу



Подготовим файловую структуру к установке.

lsblk
vda boot диск, vdb диск, созданный под данные.



SAP рекомендует следующую файловую структуру:



/usr/sap + /usr/sap/distr 35 GB
/hana/shared/data 60 GB
/hana/shared/log 10 GB
/hana/shared 40 GB

Реализуем такую структуру с помощью утилиты fdisk:

fdisk /dev/vdb`

Проверим ещё раз структуру и создадим файловую систему ext4 на всех созданных разделах:

lsblk

mkfs.ext4 /dev/vdb1mkfs.ext4 /dev/vdb2mkfs.ext4 /dev/vdb3mkfs.ext4 /dev/vdb4

Создадим директории под дистрибутивы и базу данных SAP HANA, а также примонтируем к ним созданные на предыдущем шаге разделы. Также обновим файл /etc/fstab, чтобы монтирование восстанавливалось при перезагрузке:

mkdir /usr/sapmkdir /hanamkdir /hana/sharedmkdir /hana/shared/datamkdir /hana/shared/logmount /dev/vdb1 /usr/sapmount /dev/vdb2 /hana/shared/datamount /dev/vdb3 /hana/shared/logmount /dev/vdb4 /hana/sharedmkdir /usr/sap/distrvi /etc/fstab

Установим разрешение на папку с установочными файлами SAP:

chmod -R 777 /usr/sap/distr

Импортируем в WinSCP настройки из Putty. Подключимся к ВМ и загрузим в /usr/sap/distr архивы SAP HANA Server (hxe.tgz), SAP HANA Extended Application Services XSA (hxeesa.tgz) и shine.tgz (Учебный контент)



Распакуем архивы:

cd /usr/sap/distr tar -xvzf hxe.tgztar -xvzf hxexsa.tgztar -xvzf shine.tgz

Добавим репозиторий:

sudo zypper ar -c https://download.opensuse.org/tumbleweed/repo/oss/ openSUSE-Tumbleweed-Oss-HTTPS

Установим требуемые для работы библиотеки libstdc++, libnuma1, libatomic и libgcc_s1:

zypper install libstdc++6zypper install libatomic1zypper install libgcc_s1zypper install libnuma1

Шаг 4. Устанавливаем SAP HANA XS

Первое с чего стоит начать установку это определением понятия SID
SID (SAP System Identificator) представляет собой комбинацию трех символов и должен быть уникальным в рамках ландшафта. В рамках установки SAP HANA Express Edition значение SID по-умолчанию HXE. Предполагается, что мы не будем выбирать в качестве SID что-то другое.

Запускаем скрипт инсталляции с правами root пользователя:

cd /usr/sap/distr ./setup_hxe.sh

В меню установки требуется несколько раз нажать Enter.

Таким образом мы установим предложенные значения по умолчанию:
Дистрибутивы лежат в /distr/HANA_EXPRESS_20

SID HXE
Номер инстанции 90
Установка всех компонентов all*
* В данном случае это значит, что мы установим набор библиотек Application Function Library (AFL), куда входят Predictive Analysis Library (PAL), Business Function Library (BFL), Optimization Function Library (OFL).

Плагин SAP HANA EPMMDS предназначен для получения данных из различных OLAP источников, а подсистема расширенных сервисов (Extended Services, XS) это встроенный веб-сервер и набор различных компонентов, имеющих привилегированный доступ к базе данных.



Указываем мастер-пароль для пользователей, которые создаются во время инсталляции SAP HANA.

Поскольку мы выбрали SID HXE, adm пользователь на уровне операционной системы будет hxeadm. Указанный мастер-пароль также применится и к пользователю SYSTEM на уровне базы данных.



В процессе установки XSA потребуется также задать мастер-пароль от пользователей XSA_ADMIN, XSA_DEV, TEL_ADMIN

Процесс инсталляции.



База SAP HANA Express Edition установлена.

Шаг 5. Проверка работы SAP HANA XSA

Проверим что база данных SAP HANA установлена и работает:

su  hxeadmHDB info

Пример сервисов, которые будут запущены:



Пройдём авторизацию в SAP HANA Extended Application Services, Advanced Model:

xs-admin-login

Пользователь: XSA_ADMIN
Пароль: Мастер-пароль, который мы задали при установке
Проверим версию SAP HANA Extended Application Services, Advanced Model:

xs -v

Шаг 6. Пост-инсталляционные действия

Для того чтобы использовать веб-инструменты разработки и администрирования SAP HANA XSA необходимо отредактировать файл hosts на локальной Windows-мшине.

1. Открываем блокнот от имени Администратора

2. Открываем в блокноте файл C:\Windows\System32\drivers\etc\hosts



3. Вносим строку вида:
<внешний ip-адрес>

Шаг 7. Начало работы

Существует несколько способов администрирования и разработки для SAP HANA XSA
Администрирование: SAP HANA Cockpit. В настоящее время SAP позиционирует его, как основной инструмент управления базой данных. Также возможно управление базой данных из Eclipse (Перспектива SAP HANA Administration Console)



Разработка: Через веб-интерфейс, через инструмент SAP Web IDE или через Eclipse (Перспектива SAP HANA Development)

Поскольку HANA Cockpit и WebIDE были установлены во время процесса инсталляции именно их как средства управления и администрирования мы и будем рассматривать.

Получим url для интересующих нас приложений xsa-cockpit, webide и cockpit-web-app:

xs app xsa-cockpit --urlsxs app webide --urlsxs app cockpit-web-app --urls

Скопируем https адрес и откроем его в браузере для каждого из этих приложений.

XSA Cockpit

XSA Cockpit это браузерная система управления сервером приложений SAP HANA Extended Application Services, Advanced Model.
XSA Cockpit позволяет управлять пользователями и ролями, организациями и пространствами.
В разделе User Management можно проверить, и при необходимости назначить, для пользователя XSA_DEV роли DEVX_ADMINISTRATOR, DEVX_DEVELOPER.
В разделе Tenant Databases можно расширить возможности XSA на новый тенант, в нашем случае HXE и связать с ним пространство разработки development

HANA Cockpit

HANA Cockpit это система управления базой данных SAP HANA.

Cockpit можно использовать для управления пользователями и ролями на уровне базы данных, для создания бекапов, мониторинга работы, диагностирования проблем с производительностью на уровне базы и множества других административных задач.

Скрипт регистрации ресурсов базы данных в HANA Cockpit выполняется при установке, если скрипт по каким-либо причинам не выполнился его необходимо запустить вручную до первого использования Cockpit-ом.

su  hxeadm/usr/sap/distr/HANA_EXPRESS_20/register_cockpit.sh

WebIDE

WebIDE это интегрированная с GitHub-ом браузерная среда разработки.

В разделе Development можно разрабатывать, тестировать и публиковать модули на NodeJS, Java, HTML5.

В разделе Database Explorer можно создавать и управлять объектами на уровне базы данных (таблицы, представления, хранимые процедуры и т.д).

Подключение к тенанту и обзор объектов в нём:

Шаг 8. Первое Node.js приложение

Откроем WebIDE и создадим простое UI5/Node.js приложение Hello World!

Для этого выберем
Workspace Git Clone Repository
В качестве репозитория укажем Repository github.com/basisteam-io/SAPHANAXS_helloworld.git

Таким образом мы получим копию простого приложения Hello world!, разобраться или модифицировать которое не составит никакого труда.

Установим пространство где будет развернуто данное приложение.

В нашем случае это пространство development.



Последовательно сделаем Вuild приложения и проекта.

Результатом билдинга будет .mtar файл в папке mta_archives, которая расположена в верхней части меню с иерархией проекта.

Необходимо выбрать содержащийся в папке .mtar файл и сделать для него операцию Deploy to XS Advanced.





Вернёмся к командной строке и переключимся на пространство development:

xs target -o HANAExpress -s development

Выведем список всех запущенных приложений в этом пространстве:

xs apps

Отроем наше приложение в браузере:

Заключение

Установить базу данных SAP HANA с сервером приложений HANA Extended Application Services, Advanced Model и написать своё первое приложение оказалось не сложно. В следующей статье рассмотрим более сложный пример, включающий в себя взаимодействие с базой данных SAP HANA.

Роман Горбенко, консультант SAP EWM / SAP BASIS