Репликация как услуга (часть первая)

 Это охватывает основы. Одним (из многих) ограничений этой первоначальной попытки является игнорирование проблем безопасности в облаке (т. Е. Групп безопасности). В настоящее время предполагается, что такие проблемы решаются извне (либо вручную, либо путем переопределения базовых рецептов Cloudify). В любом случае, одной из особенностей контейнеров XAP, на которых размещаются шлюзы репликации, является то, что они должны запускаться с портами, используемыми для репликации. Поскольку REST API запускает эти контейнеры, для каждого сайта должны быть определены номера портов, определенные в определении топологии. Они могут иметь какие-то значения по умолчанию, но порты должны быть открыты как в контейнере, так и в Интернете. Для этого в JSON есть еще один раздел, называемый «порты», который определяет порты для каждого сайта. Добавив это, JSON почти завершен:

{
  "name":"some-name",
  "cloudify-instances":[
    {"site1-name":"<some reachable ip>:8100", "site2-name":"<some reachable ip>:8100" ...  }
  ],
  "edges":[["site1","site2"],["site2","site1"]],
  "ports:{
    "site1":{"discovery":"10000","data","10001"},
    "site2":{"discovery":"10000","data","10001"}
  }
}

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

Конечная точка REST

Поскольку цель ограничена только вариантом использования «создание сети репликации», в REST API пока только один глагол. REST API реализован с помощью Spring MVC. API определяет единственный метод, который принимает действие POST с именем сети топологии в качестве переменной пути, например:

http://<host>:<port>/rest/repl/topology/my-topo

Это одно действие, которое делает довольно много, поэтому стоит пройти логику на высоком уровне. Вся информация о топологии включена в тело POST, как описано выше. Для вызова REST, который стремится сделать так много (и потенциально это может занять много времени), проверка запроса является критической. В более общем смысле, провал быстро (или как можно быстрее) является критическим. Это было реализовано в ограниченном объеме, но это определенно область, которая может быть расширена. Как только запрос подтвержден, каждый участвующий сайт связывается одновременно, когда это возможно, чтобы минимизировать задержку вызова. Я свободно использую термин «минимизировать», потому что любой отдельный вызов, который раскручивает несколько виртуальных машин на нескольких облаках (потенциально), не будет быстрым. Выполнение вызова REST вызывает следующие действия:

1. Запросить подтверждение. Синтаксис запроса проверен. Проверяется наличие обязательных полей и правильность скалярных записей.
2. Подтверждение участника. С каждым участвующим сайтом Cloudify связываются для проверки доступности. Каждый сайт проверяется, чтобы убедиться, что топология с тем же именем еще не запущена.
3. XAP развернут на каждом сайте. Это включает в себя менеджер, контейнер (ы) и шлюз. Контейнер шлюза запускается с правильными портами, открытыми в соответствии с определением топологии. Шлюз развертывается с помощью настраиваемого преобразователя NAT, который допускает динамическую настройку (в отличие от стандартной версии). Контейнеры данных и контейнеры шлюзов развернуты в отдельных зонах, чтобы можно было правильно ориентировать будущие развертывания шлюза и пространства. Эта операция выполняется параллельно на всех сайтах.
4. Пространства для хранения данных репликации создаются и развертываются на каждом сайте. Пространство имеет то же имя, что и топология. Особенности пространства, такие как разделы и резервные копии, взяты из определения топологии. Пространство развернуто с именем локального шлюза, взятым из топологии, и пустым блоком целей для последующего динамического введения цели . Эта операция выполняется параллельно на всех сайтах.
5. Шлюзы репликации развернуты. Блок обработки шлюза создается на каждом сайте и разворачивается, а цель пространства обновляется. Делегаторы и приемники являются производными от определения топологии (ребра). Поиски создаются на основе предыдущих шагов в процессе развертывания, где назначаются необходимые IP-адреса. Таблица динамического преобразования NAT обновляется на основе частной / общедоступной информации IP, собранной на предыдущем этапе развертывания шлюза. Эта операция выполняется параллельно на всех сайтах.

Когда все это завершается (частичные сбои вызывают полный откат), система начинает репликацию.