Информационный портал по безопасности » Админитстрирование » Системное администрирование » Интеграция Apache CloudStack со сторонними системами. Подписка на события с помощью Apache Kafka

 

Интеграция Apache CloudStack со сторонними системами. Подписка на события с помощью Apache Kafka

Автор: admin от 23-07-2017, 22:00, посмотрело: 487

Интеграция Apache CloudStack со сторонними системами. Подписка на события с помощью Apache Kafka

В данной статье рассматривается подход к интеграции Apache CloudStack (ACS) со сторонними системами посредством экспорта событий в брокер очередей сообщений Apache Kafka.



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



Интеграция Apache CloudStack со сторонними системами. Подписка на события с помощью Apache Kafka

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



В разрезе ACS данные функции реализуются следующими возможностями:




  • Стандартный API — позволяет взаимодействовать с ACS типовым способом.

  • Плагины API — позволяют разработчикам описывать свои расширения API, предназначенные для реализации специфических взаимодействий.

  • Экспорт событий — позволяет взаимодействовать с внешними системами при возникновении событий внутри ACS, которые требуют действий от внешних систем.



  • Итак, ACS предоставляет нам все необходимые способы взаимодействия. В рамках статьи освещается третий способ взаимодействия — Экспорт событий. Вариантов, когда такой способ взаимодействия является полезным достаточно много, приведем несколько примеров:




    • уведомление пользователя посредством сторонних средств, например (SMS, IM) о некоторых событиях, например, событии остановки виртуальной машины;

    • уведомление биллинговой системы о выделении или удалении ресурсов (аккаунтинг, учет, списания);

    • уведомление биллинговой системы о новых аккаунтах ACS.



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

    ACS позволяет экспортировать события в брокеры очередей сообщений двумя способами — с применением протокола AMPQ в RabbitMQ и по протоколу Apache Kafka в Apache Kafka, соответственно. Мы широко используем в своей практике Apache Kafka, поэтому в данной статье рассмотрим как подключить к серверу ACS экспорт событий в эту систему.



    Экспорт событий в брокер очередей сообщений VS явный вызов API сторонней системы



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




  • отказоустойчивость;

  • высокая производительность и масштабируемость;

  • возможность отложенной или запаздывающей обработки.



  • Данных свойств весьма сложно добиться в случае с непосредственным вызовом обрабатывающего кода сторонних систем без ущерба стабильности вызывающей подсистемы продукта. К примеру, представим, что при создании аккаунта требуется отправить SMS с уведомлением. В случае непосредственного вызова кода отправки возможны следующие классы ошибок:




  • отказ вызываемого кода и неотправка уведомления;

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



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



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



    Обратная сторона использования брокера сообщений — необходимость настройки данного сервиса и наличие опыта его администрирования и решения проблем. Хотя, Apache Kafka является весьма беcпроблемным сервисом, все же, рекомендуется посвятить время его настройке, моделированию аварийных ситуаций и разработке ответных мер.



    Настройка экспорта событий ACS в Apache Kafka



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



    Для развертывания Kafka будем использовать Docker-контейнер spotify/kafka, который включает в себя все необходимые компоненты (Apache Zookeeper и Kafka) и поэтому отлично подходит для целей разработки.



    Установка Docker (из официального гайда для установки в CentOS 7) выполняется элементарно:



    # yum install -y yum-utils device-mapper-persistent-data lvm2
    # yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    # yum makecache fast
    # yum install docker-ce


    Настройка Apache Kafka



    Развернем контейнер с Apache Kafka:



    # docker run -d -p 2181:2181 -p 9092:9092 --env ADVERTISED_HOST=10.0.0.66 --env ADVERTISED_PORT=9092 spotify/kafka
    c660741b512a


    Таким образом, Kafka будет доступен по адресу 10.0.0.66:9092, а Apache Zookeeper по адресу 10.0.0.66:2181.

    Протестировать Kafka и Zookeeper можно следующим образом:



    Создадим и запишем в топик "cs" строку "test":



    # docker exec -i -t c660741b512a bash -c "echo 'test' | /opt/kafka_2.11-0.10.1.0/bin/kafka-console-producer.sh --broker-list 10.0.0.66:9092 --topic cs"
    [2017-07-23 08:48:11,222] WARN Error while fetching metadata with correlation id 0 : {cs=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)


    Прочитаем ее же:



    # docker exec -i -t c660741b512a /opt/kafka_2.11-0.10.1.0/bin/kafka-console-consumer.sh --bootstrap-server=10.0.0.66:9092 --topic cs --offset=earliest --partition=0
    test
    ^CProcessed a total of 1 messages


    Если все произошло так, как отображено на врезках кода выше, значит Kafka исправно функционирует.



    Настройка Apache CloudStack



    Следующим шагом настроим экспорт событий в ACS (оригинал документации здесь). Создадим файл настроек (/etc/cloudstack/management/kafka.producer.properties) для продюсера Kafka, который использоваться ACS со следующим содержимым:



    bootstrap.servers=10.0.0.66:9092
    acks=all
    topic=cs
    retries=1


    Детальное описание настроек Kafka можно найти на странице официальной документации.



    При использовании реплицируемого кластера Kafka в строке bootstrap.servers необходимо указать все известные серверы.

    Создадим каталог для java bean, активирующего экспорт событий в Kafka:



    # mkdir -p /etc/cloudstack/management/META-INF/cloudstack/core


    И сам файл конфигурации для bean-a (/etc/cloudstack/management/META-INF/cloudstack/core/spring-event-bus-context.xml) со следующим содержимым:



    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xmlns:aop="http://www.springframework.org/schema/aop"
           xsi:schemaLocation="http://www.springframework.org/schema/beans
                               http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                               http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
                               http://www.springframework.org/schema/context
                               http://www.springframework.org/schema/context/spring-context-3.0.xsd">
       <bean id="eventNotificationBus" class="org.apache.cloudstack.mom.kafka.KafkaEventBus">
         <property name="name" value="eventNotificationBus"/>
       </bean>
    </beans>


    Перезагрузим управляющий сервер ACS:



    # systemctl restart cloudstack-management


    Экспортируемые события теперь попадают в топик cs, при этом имеют формат JSON, пример событий отображен далее (отформатирован для удобства):



    {
     "Role":"e767a39b-6b93-11e7-81e3-06565200012c",
     "Account":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
     "eventDateTime":"2017-07-23 14:09:08 +0700",
     "entityuuid":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
     "description":"Successfully completed creating Account. Account Name: null, Domain Id:1",
     "event":"ACCOUNT.CREATE",
     "Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
     "user":"f484a624-6b93-11e7-81e3-06565200012c",
     "account":"f4849ae2-6b93-11e7-81e3-06565200012c",
     "entity":"com.cloud.user.Account","status":"Completed"
    }
    
    {
     "Role":"e767a39b-6b93-11e7-81e3-06565200012c",
     "Account":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
     "eventDateTime":"2017-07-23 14:09:08 +0700",
     "entityuuid":"4de64270-7bd7-4932-811a-c7ca7916cd2d",
     "description":"Successfully completed creating User. Account Name: null, DomainId:1",
     "event":"USER.CREATE",
     "Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
     "user":"f484a624-6b93-11e7-81e3-06565200012c",
     "account":"f4849ae2-6b93-11e7-81e3-06565200012c",
     "entity":"com.cloud.user.User","status":"Completed"
    }
    
    {
     "eventDateTime":"2017-07-23 14:14:13 +0700",
     "entityuuid":"0f8ffffa-ae04-4d03-902a-d80ef0223b7b",
     "description":"Successfully completed creating User. UserName: test2, FirstName :test2, LastName: test2",
     "event":"USER.CREATE",
     "Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
     "user":"f484a624-6b93-11e7-81e3-06565200012c",
     "account":"f4849ae2-6b93-11e7-81e3-06565200012c",
     "entity":"com.cloud.user.User","status":"Completed"
    }


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



    # docker exec -i -t c660741b512a 
        /opt/kafka_2.11-0.10.1.0/bin/kafka-console-consumer.sh --bootstrap-server=10.0.0.66:9092 --topic cs --offset=earliest --partition=0


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



    В случае настройки экспорта событий для "боевой" среды необходимо помнить о следующем:




  • Настройка должна быть выполнена для каждого управляющего сервера ACS;

  • Kafka должен быть настроен в реплицируемом варианте (обычно, 3 сервера и репликация x3);

  • Apache Zookeeper должен быть настроен в реплицируемом варианте (обычно, 3 сервера);

  • Настройки /etc/cloudstack/management/kafka.producer.properties должны быть подобраны с учетом требуемого уровня надежности доставки событий.

  • Не забудьте настроить период удаления старых данных для Kafka (например, 1 месяц).



  • Вместо заключения



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




  • Когда я начал заниматься применением ACS на практике, то не обнаружил подобный материал, в итоге, в одном из облаков используется поллинг для связи с биллинговой системой.

  • Проведена проверка работоспособности для самого нового ACS 4.9.2, которая подтверждает, что функциональность исправна в данной версии продукта.

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

  • В настоящее время основное внимание уделяется Openstack и складывается впечатление, что это это безальтернативный продукт, хотя основное благо он несет, зачастую, только внедряющему. Хотелось обратить внимание на альтернативные продукт, который весьма применяется рядом крупных организаций и предоставляет удобные инструменты для интеграции.



  • Надеюсь, что читатели найдут материал интересным и полезным для себя.



    Источник: Хабрахабр

    Категория: Системное администрирование / Веб-разработка

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

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    • bowtiesmilelaughingblushsmileyrelaxedsmirk
      heart_eyeskissing_heartkissing_closed_eyesflushedrelievedsatisfiedgrin
      winkstuck_out_tongue_winking_eyestuck_out_tongue_closed_eyesgrinningkissingstuck_out_tonguesleeping
      worriedfrowninganguishedopen_mouthgrimacingconfusedhushed
      expressionlessunamusedsweat_smilesweatdisappointed_relievedwearypensive
      disappointedconfoundedfearfulcold_sweatperseverecrysob
      joyastonishedscreamtired_faceangryragetriumph
      sleepyyummasksunglassesdizzy_faceimpsmiling_imp
      neutral_faceno_mouthinnocent