Облачные вычисления так популярны по нескольким причинам: они гибкие, относительно дешевые по сравнению с поддержкой внутренней инфраструктуры и позволяют отлично автоматизировать распределение ресурсов (и тут тоже экономия). Когда объем обрабатываемых данных растет из года в год, нельзя полагаться на вертикальную масштабируемость, покупая все более и более дорогие серверы. Данные должны быть распределены по нескольким более дешевым системам (кластерам), где могут надежно храниться, обрабатываться и возвращаться к пользователю при необходимости. Создание таких систем — непростая задача, но, к счастью, есть решения, которые отлично вписываются в облачную архитектуру. Я говорю об Apache Ignite.
Подготовка среды
Я собираюсь использовать AWS-облако для развертывания кластера Ignite. Для целей обучения нам хватит бесплатных машин базового уровня (AWS free tier). Я выбрал образ Ubuntu 18.04, но в целом это неважно. Перед развертыванием первых машин нам надо настроить группу безопасности (Security Group). В ней должны быть определены сетевые правила для портов, необходимых для узлов Ignite.
На момент появления в Apache Software Foundation проекта Ignite он позиционировался как чистое in-memory-решение: распределенный кэш, поднимающий в память данные из традиционной СУБД, чтобы выиграть во времени доступа. Но уже в релизе 2.1 появился модуль встроенной персистентности (Native Persistence), который позволяет классифицировать Ignite как полноценную распределенную базу данных. С тех пор Ignite перестал зависеть от внешних систем обеспечения персистентного хранения данных, и вязанка граблей конфигурации и администрирования, на которые не раз наступали пользователи, исчезла.
Однако persistent-режим порождает свои сценарии и новые вопросы. Как предотвратить неразрешимые конфликты данных в ситуации split-brain? Можем ли мы отказаться от перебалансировки партиций, если выход узла теперь не означает, что данные на нем потеряны? Как автоматизировать дополнительные действия вроде активации кластера? BaselineTopology нам в помощь.