[Open source, Amazon Web Services, Распределённые системы] Apache Ignite в облаке AWS — базовый пример
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Облачные вычисления так популярны по нескольким причинам: они гибкие, относительно дешевые по сравнению с поддержкой внутренней инфраструктуры и позволяют отлично автоматизировать распределение ресурсов (и тут тоже экономия). Когда объем обрабатываемых данных растет из года в год, нельзя полагаться на вертикальную масштабируемость, покупая все более и более дорогие серверы. Данные должны быть распределены по нескольким более дешевым системам (кластерам), где могут надежно храниться, обрабатываться и возвращаться к пользователю при необходимости. Создание таких систем — непростая задача, но, к счастью, есть решения, которые отлично вписываются в облачную архитектуру. Я говорю об Apache Ignite.
Подготовка среды
Я собираюсь использовать AWS-облако для развертывания кластера Ignite. Для целей обучения нам хватит бесплатных машин базового уровня (AWS free tier). Я выбрал образ Ubuntu 18.04, но в целом это неважно. Перед развертыванием первых машин нам надо настроить группу безопасности (Security Group). В ней должны быть определены сетевые правила для портов, необходимых для узлов Ignite.
Рисунок 1 – Конфигурация Security Group
Два диапазона портов были настроены явным образом: диапазон портов 47500-47600 для discovery (механизм обнаружения, он позволяет узлам находить друг друга и формировать кластер), а диапазон 47100-47200 — для подсистемы связи (communication), которая позволяет узлам посылать друг другу прямые сообщения.
Теперь, после настройки Security Group, пора запустить и настроить наши машины.
Рисунок 2 — Security group выбирается во время подготовки инстанса AWS
Машины запущены, но им не хватает основного ПО: Java. Нет проблем, просто используйте следующую команду для установки Java:
~/sudo apt install openjdk-8-jdkс
Команда для пакетов RedHat/Centos выглядит слегка иначе:
~/sudo yum install java-1.8.0-openjdk.x86_64
Отлично! Мы всего в шаге от первого инстанса Ignite, запущенного и работающего в облаке!
Я скачал с официального сайта бинарный пакет версии 2.7.6 и распаковал его:
~/ignite$ wget http://mirror.linux-ia64.org/apache//ignite/2.7.6/apache-ignite-2.7.6-bin.zip
~/ignite$ unzip apache-ignite-2.7.6-bin.zip
~/ignite/apache-ignite-2.7.6-bin$ ./bin/ignite.sh
Рисунок 3 – Первый узел запущен
Мы уже сильно продвинулись: подготовили среду, выяснили, где взять бинарные файлы и как их запустить. Пора собрать кластер. Запуска группы узлов недостаточно для построения кластера, и это становится очевидным из логов: у каждого узла есть такая строка в логах:
Рисунок 4 – Два узла сформировали два независимых кластера
Это сообщение означает, что два узла сформировали два независимых кластера вместо того, чтобы обнаружить друг друга и объединиться в один.
Чтобы создать настоящую кластерную среду, надо глубже разобраться в том, как узлы объединяются в кластер. Особую роль в этом процессе играет специальный сервис Discovery. Именно он позволяет узлам находить друг друга и формировать кластер.
Когда узел запускается, он первым делом запрашивает свой экземпляр сервиса Discovery для поиска существующего кластера и пытается присоединиться вместо того, чтобы создавать новый.
Настройки DiscoverySPI, позволяющие сервису обнаружить кластер, должен предоставить конечный пользователь, однако они просты и интуитивны. Всё, что нам нужно сделать, — это сконфигурировать IpFinder (компонент для поиска ip-адресов существующих узлов) и передать его в Discovery. Сделаем это и соберем изолированные узлы в единую систему.
Откройте конфигурационный файл в вашем любимом текстовом редакторe…
~/ignite/apache-ignite-2.7.6-bin$ vim config/default-config.xml
… и добавьте следующий блок:
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>172.31.3.57</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
Этот блок нужно разместить прямо под корневым элементом файла конфигурации. Самое важное здесь — значение, переданное в свойстве addresses. Для каждого сервера это должен быть либо частный, внутрисетевой IP-адрес, либо публичный IP-адрес другого сервера.
Вкладка Description каждого узла содержит информацию о публичных и частных IP-адресах наших AWS-узлов:
Рисунок 5 – Частные и публичные IP-адреса в консоли управления AWS
Подключение к кластеру с помощью толстого клиента
Пока что мы создали облачную среду с нуля, развернули, настроили и собрали кластер Ignite, а также расширили наше понимание распределенных систем на этом пути. Настало время сделать что-то полезное с нашим новеньким кластером: подключиться к нему с помощью удаленного клиента, загрузить некоторые данные и убедиться, что они там есть.
Ignite предоставляет несколько способов подключения к кластеру: тонкие клиенты, интерфейсы JDBC/ODBC и так далее. Но я собираюсь использовать подключение толстого клиента, что делается очень просто. Фактически, толстый клиент является почти обычным серверным узлом Ignite, за исключением того, что он не хранит данные кэшей локально (и некоторых других технических деталей, но мы не будем углубляться в них прямо сейчас), поэтому его конфигурация очень похожа.
Я начинаю с моей любимой IDE и создаю простейший Java-проект: проект командной строки. Я добавляю в путь к классам проекта три jar-файла из того самого бинарного пакета, который мы использовали для развертывания наших серверов Ignite в облаке. Вот эти jar-файлы: ignite-core-2.7.6.jar, cache-api-1.0.0.jar и annotations-13.0.jar.
Вот конфигурация в Java для моего клиента:
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setClientMode(true);
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(Arrays.asList("54.154.28.251"));
TcpDiscoverySpi spi = new TcpDiscoverySpi();
spi.setIpFinder(ipFinder);
cfg.setDiscoverySpi(spi);
Здесь мы видим те же свойства, которые уже настроили для серверных узлов: DiscoverySPI, IpFinder и так далее. Здесь много общего, за исключением флажка cfg.setClientMode(true), который превращает обычный узел Ignite в клиентский.
Используя эту конфигурацию, я запускаю клиентский узел, отправляю в кластер запрос на создание кэша, помещаю туда простую строку и снова читаю это значение:
try (Ignite client = Ignition.start(cfg)) {
IgniteCache cache = client.getOrCreateCache(
new CacheConfiguration("clientCache")
.setBackups(1)
.setAffinity(new RendezvousAffinityFunction(false, 4))
);
cache.put(1, "myString");
System.out.println("-->>-->> value of key ‘1’: " + cache.get(1));
}
Хм, я вижу, что что-то не так. Моя простенькая программа запускается, но не выводит никаких результатов. В то же время я вижу в серверных логах, что серверы добавили клиентский узел в топологию:
Рисунок 6 – Сообщение в серверных логах о подключенном клиенте
Так в чём же дело? А вот в чём — в облачных средах на стороне сервера необходимо настроить еще одну вещь: преобразователь адресов AddressResolver.
Поскольку наши серверы работают в AWS, между ними и внешним миром работает сервис NAT (Network Address Translation). Серверы знают свои внутренние (находящиеся за NAT) IP-адреса, но не знают, какие им назначены публичные IP-адреса. Чтобы предоставить серверам информацию об этом сопоставлении и тем самым позволить им взаимодействовать с удаленными клиентами, нам нужно настроить преобразователи адресов на стороне сервера.
Сначала остановите оба серверных узла.
Затем добавьте еще один блок в конфигурацию каждого сервера, снова прямо под корневым элементом config xml. Здесь частный и публичный IP-адреса — это адреса того сервера, чья конфигурация изменяется:
<property name="addressResolver">
<bean class="org.apache.ignite.configuration.BasicAddressResolver">
<constructor-arg>
<map>
<entry key="<private IP>" value="<public IP>"/>
</map>
</constructor-arg>
</bean>
</property>
Перезагрузите узлы Ignite, чтобы изменения вступили в силу. Имейте в виду, что публичный IP-адрес может измениться после перезапуска виртуальной машины, тогда придется редактировать настройку addressResolver.
Снова запустите программу с клиентским узлом. Теперь мы видим ожидаемый результат: программа завершает работу и извлекает из кэша только что помещенное туда значение.
Заключение
Для развертывания кластера Ignite в облаке AWS требуется несколько простых шагов. А после них мы сможем делать более интересные вещи вроде потоковой передачи данных в кластер с помощью стримеров данных, выполнения запросов или использования других интерфейсов, таких как JDBC/ODBC соединение, для подключения к кластеру.
Только помните, что для разработки более полезных приложений требуется больше ресурсов, а бесплатные экземпляры AWS очень быстро израсходуются. Независимо от того, используется ли Ignite в качестве основной базы данных или в качестве in-memory-кэша, больший объем памяти означает лучшую производительность, и для промышленной эксплуатации лучше всего подходят мощные экземпляры уровня x1.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, История IT] Отменим ли мы Web? (перевод)
- [Open source, Законодательство в IT, История IT, IT-компании] Red Hat отказалась финансировать FSF за возврат Столлмана
- [Open source, *nix] FOSS News №62 – дайджест материалов о свободном и открытом ПО за 22-28 марта 2021 года
- [Open source, .NET, C#] Избавляемся от постоянного написания конструкторов для инжекта зависимостей с помощью C# Source Generators
- [Параллельное программирование, Распределённые системы] Часть 3. MPI — Как процессы обшаются? Сообщения типа точка-точка
- [Криптография, Open source, Софт] В OpenSSL нашли две опасные уязвимости
- [Open source, GitHub, Законодательство в IT, Социальные сети и сообщества, Биографии гиков] Multiple violations of policies in RMS open letter
- [Open source, Программирование, Системное программирование, Компиляторы, Rust] Rust 1.51.0: const generics MVP, новый распознаватель функциональности Cargo (перевод)
- [Open source, Программирование, Геоинформационные сервисы, Визуализация данных, Научно-популярное] Google Earth Engine (GEE) как общедоступный каталог больших геоданных
- [Open source] Нетехнические вызовы Open Source разработки
Теги для поиска: #_open_source, #_amazon_web_services, #_raspredelennye_sistemy (Распределённые системы), #_apache_ignite, #_aws, #_cloud_computing, #_blog_kompanii_gridgain (
Блог компании GridGain
), #_open_source, #_amazon_web_services, #_raspredelennye_sistemy (
Распределённые системы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:31
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Облачные вычисления так популярны по нескольким причинам: они гибкие, относительно дешевые по сравнению с поддержкой внутренней инфраструктуры и позволяют отлично автоматизировать распределение ресурсов (и тут тоже экономия). Когда объем обрабатываемых данных растет из года в год, нельзя полагаться на вертикальную масштабируемость, покупая все более и более дорогие серверы. Данные должны быть распределены по нескольким более дешевым системам (кластерам), где могут надежно храниться, обрабатываться и возвращаться к пользователю при необходимости. Создание таких систем — непростая задача, но, к счастью, есть решения, которые отлично вписываются в облачную архитектуру. Я говорю об Apache Ignite. Подготовка среды Я собираюсь использовать AWS-облако для развертывания кластера Ignite. Для целей обучения нам хватит бесплатных машин базового уровня (AWS free tier). Я выбрал образ Ubuntu 18.04, но в целом это неважно. Перед развертыванием первых машин нам надо настроить группу безопасности (Security Group). В ней должны быть определены сетевые правила для портов, необходимых для узлов Ignite.  Рисунок 1 – Конфигурация Security Group Два диапазона портов были настроены явным образом: диапазон портов 47500-47600 для discovery (механизм обнаружения, он позволяет узлам находить друг друга и формировать кластер), а диапазон 47100-47200 — для подсистемы связи (communication), которая позволяет узлам посылать друг другу прямые сообщения. Теперь, после настройки Security Group, пора запустить и настроить наши машины.  Рисунок 2 — Security group выбирается во время подготовки инстанса AWS Машины запущены, но им не хватает основного ПО: Java. Нет проблем, просто используйте следующую команду для установки Java: ~/sudo apt install openjdk-8-jdkс
Команда для пакетов RedHat/Centos выглядит слегка иначе: ~/sudo yum install java-1.8.0-openjdk.x86_64
Отлично! Мы всего в шаге от первого инстанса Ignite, запущенного и работающего в облаке! Я скачал с официального сайта бинарный пакет версии 2.7.6 и распаковал его: ~/ignite$ wget http://mirror.linux-ia64.org/apache//ignite/2.7.6/apache-ignite-2.7.6-bin.zip
~/ignite$ unzip apache-ignite-2.7.6-bin.zip ~/ignite/apache-ignite-2.7.6-bin$ ./bin/ignite.sh  Рисунок 3 – Первый узел запущен Мы уже сильно продвинулись: подготовили среду, выяснили, где взять бинарные файлы и как их запустить. Пора собрать кластер. Запуска группы узлов недостаточно для построения кластера, и это становится очевидным из логов: у каждого узла есть такая строка в логах:  Рисунок 4 – Два узла сформировали два независимых кластера Это сообщение означает, что два узла сформировали два независимых кластера вместо того, чтобы обнаружить друг друга и объединиться в один. Чтобы создать настоящую кластерную среду, надо глубже разобраться в том, как узлы объединяются в кластер. Особую роль в этом процессе играет специальный сервис Discovery. Именно он позволяет узлам находить друг друга и формировать кластер. Когда узел запускается, он первым делом запрашивает свой экземпляр сервиса Discovery для поиска существующего кластера и пытается присоединиться вместо того, чтобы создавать новый. Настройки DiscoverySPI, позволяющие сервису обнаружить кластер, должен предоставить конечный пользователь, однако они просты и интуитивны. Всё, что нам нужно сделать, — это сконфигурировать IpFinder (компонент для поиска ip-адресов существующих узлов) и передать его в Discovery. Сделаем это и соберем изолированные узлы в единую систему. Откройте конфигурационный файл в вашем любимом текстовом редакторe… ~/ignite/apache-ignite-2.7.6-bin$ vim config/default-config.xml … и добавьте следующий блок: <property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi"> <property name="ipFinder"> <bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder"> <property name="addresses"> <list> <value>172.31.3.57</value> </list> </property> </bean> </property> </bean> </property> Этот блок нужно разместить прямо под корневым элементом файла конфигурации. Самое важное здесь — значение, переданное в свойстве addresses. Для каждого сервера это должен быть либо частный, внутрисетевой IP-адрес, либо публичный IP-адрес другого сервера. Вкладка Description каждого узла содержит информацию о публичных и частных IP-адресах наших AWS-узлов:  Рисунок 5 – Частные и публичные IP-адреса в консоли управления AWS Подключение к кластеру с помощью толстого клиента Пока что мы создали облачную среду с нуля, развернули, настроили и собрали кластер Ignite, а также расширили наше понимание распределенных систем на этом пути. Настало время сделать что-то полезное с нашим новеньким кластером: подключиться к нему с помощью удаленного клиента, загрузить некоторые данные и убедиться, что они там есть. Ignite предоставляет несколько способов подключения к кластеру: тонкие клиенты, интерфейсы JDBC/ODBC и так далее. Но я собираюсь использовать подключение толстого клиента, что делается очень просто. Фактически, толстый клиент является почти обычным серверным узлом Ignite, за исключением того, что он не хранит данные кэшей локально (и некоторых других технических деталей, но мы не будем углубляться в них прямо сейчас), поэтому его конфигурация очень похожа. Я начинаю с моей любимой IDE и создаю простейший Java-проект: проект командной строки. Я добавляю в путь к классам проекта три jar-файла из того самого бинарного пакета, который мы использовали для развертывания наших серверов Ignite в облаке. Вот эти jar-файлы: ignite-core-2.7.6.jar, cache-api-1.0.0.jar и annotations-13.0.jar. Вот конфигурация в Java для моего клиента: IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setClientMode(true); TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder(); ipFinder.setAddresses(Arrays.asList("54.154.28.251")); TcpDiscoverySpi spi = new TcpDiscoverySpi(); spi.setIpFinder(ipFinder); cfg.setDiscoverySpi(spi); Здесь мы видим те же свойства, которые уже настроили для серверных узлов: DiscoverySPI, IpFinder и так далее. Здесь много общего, за исключением флажка cfg.setClientMode(true), который превращает обычный узел Ignite в клиентский. Используя эту конфигурацию, я запускаю клиентский узел, отправляю в кластер запрос на создание кэша, помещаю туда простую строку и снова читаю это значение: try (Ignite client = Ignition.start(cfg)) {
IgniteCache cache = client.getOrCreateCache( new CacheConfiguration("clientCache") .setBackups(1) .setAffinity(new RendezvousAffinityFunction(false, 4)) ); cache.put(1, "myString"); System.out.println("-->>-->> value of key ‘1’: " + cache.get(1)); } Хм, я вижу, что что-то не так. Моя простенькая программа запускается, но не выводит никаких результатов. В то же время я вижу в серверных логах, что серверы добавили клиентский узел в топологию:  Рисунок 6 – Сообщение в серверных логах о подключенном клиенте Так в чём же дело? А вот в чём — в облачных средах на стороне сервера необходимо настроить еще одну вещь: преобразователь адресов AddressResolver. Поскольку наши серверы работают в AWS, между ними и внешним миром работает сервис NAT (Network Address Translation). Серверы знают свои внутренние (находящиеся за NAT) IP-адреса, но не знают, какие им назначены публичные IP-адреса. Чтобы предоставить серверам информацию об этом сопоставлении и тем самым позволить им взаимодействовать с удаленными клиентами, нам нужно настроить преобразователи адресов на стороне сервера. Сначала остановите оба серверных узла. Затем добавьте еще один блок в конфигурацию каждого сервера, снова прямо под корневым элементом config xml. Здесь частный и публичный IP-адреса — это адреса того сервера, чья конфигурация изменяется: <property name="addressResolver">
<bean class="org.apache.ignite.configuration.BasicAddressResolver"> <constructor-arg> <map> <entry key="<private IP>" value="<public IP>"/> </map> </constructor-arg> </bean> </property> Перезагрузите узлы Ignite, чтобы изменения вступили в силу. Имейте в виду, что публичный IP-адрес может измениться после перезапуска виртуальной машины, тогда придется редактировать настройку addressResolver. Снова запустите программу с клиентским узлом. Теперь мы видим ожидаемый результат: программа завершает работу и извлекает из кэша только что помещенное туда значение. Заключение Для развертывания кластера Ignite в облаке AWS требуется несколько простых шагов. А после них мы сможем делать более интересные вещи вроде потоковой передачи данных в кластер с помощью стримеров данных, выполнения запросов или использования других интерфейсов, таких как JDBC/ODBC соединение, для подключения к кластеру. Только помните, что для разработки более полезных приложений требуется больше ресурсов, а бесплатные экземпляры AWS очень быстро израсходуются. Независимо от того, используется ли Ignite в качестве основной базы данных или в качестве in-memory-кэша, больший объем памяти означает лучшую производительность, и для промышленной эксплуатации лучше всего подходят мощные экземпляры уровня x1. =========== Источник: habr.com =========== Похожие новости:
Блог компании GridGain ), #_open_source, #_amazon_web_services, #_raspredelennye_sistemy ( Распределённые системы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:31
Часовой пояс: UTC + 5