О планетах, регионах, модулях, организациях, средах и виртуальных хостах

Edge для частного облака v4.18.05

Локальная установка Edge Private Cloud или экземпляр Edge состоит из нескольких компонентов Edge, установленных на наборе серверных узлов. На следующем изображении показаны взаимосвязи между планетой, регионами, модулями, организациями, средами и виртуальными хостами, составляющими экземпляр Edge:

В следующей таблице описаны эти отношения:

О планетах

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

О регионах

Регион — это группа из одного или нескольких модулей. По умолчанию при установке Edge установщик создает один регион с именем «dc-1», содержащий три модуля, как показано в следующей таблице:

На следующем изображении показаны регионы по умолчанию:

На этом изображении показан балансировщик нагрузки, направляющий трафик на модуль «шлюз». Модуль «шлюз» содержит компоненты Edge Router и Message Processor, которые обрабатывают запросы API. Если вы не определите несколько центров обработки данных, вам не придется создавать дополнительные регионы.

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

В Edge каждый регион называется центром обработки данных . Центр обработки данных на востоке США может затем обрабатывать запросы, поступающие из Бостона, штат Массачусетс, а центр обработки данных в Сингапуре может обрабатывать запросы, исходящие от устройств или компьютеров в Азии.

Например, на следующем изображении показаны два региона, соответствующие двум центрам обработки данных:

О модулях

Модуль — это группа из одного или нескольких компонентов Edge и хранилищ данных Cassandra. Компоненты Edge можно установить на одном узле, но чаще всего они устанавливаются на разных узлах. Хранилище данных Cassandra — это хранилище данных, используемое компонентами Edge в модуле.

По умолчанию при установке Edge установщик создает три модуля и связывает с каждым модулем следующие компоненты Edge и хранилища данных Cassandra:

Компоненты Edge и хранилища данных Cassandra в модуле «шлюз» необходимы для обработки API. Эти компоненты и хранилища данных должны быть запущены и работать для обработки запросов API. Компоненты и хранилища данных в модулях «центральный» и «аналитика» не требуются для обработки API, но добавляют дополнительные функции в Edge.

На следующем изображении показаны компоненты каждого модуля:

Вы можете добавить дополнительные модули «Обработчик сообщений» и «Маршрутизатор» к трем, созданным по умолчанию. Альтернативно вы можете добавить дополнительные компоненты Edge в существующий модуль. Например, вы можете добавить дополнительные маршрутизаторы и процессоры сообщений в модуль «шлюз», чтобы обрабатывать повышенную нагрузку трафика.

Обратите внимание, что модуль «шлюз» содержит компоненты Edge Router и Message Processor. Маршрутизаторы отправляют запросы только процессорам сообщений в том же модуле, а не процессорам сообщений в других модулях.

Вы можете использовать следующий вызов API для просмотра сведений о регистрации сервера в конце установки для каждого модуля. Это полезный инструмент мониторинга.

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=podName

Где ms_IP — это IP-адрес или DNS-имя Сервера управления, а podName — одно из следующих:

• gateway
• central
• analytics

Например, для модуля «шлюз»:

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=gateway

Apigee возвращает вывод, аналогичный следующему:

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
},
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

Атрибут type перечисляет тип компонента. Обратите внимание, что в нем перечислены хранилища данных Cassandra, зарегистрированные в модуле. Пока узлы Cassandra установлены в модуле «шлюз», вы увидите хранилища данных Cassandra, зарегистрированные во всех модулях.

Об организациях

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

При локальной установке Edge Private Cloud по умолчанию организации отсутствуют. Когда вы создаете организацию, вы указываете две части информации:

1. Пользователь, выполняющий функции администратора организации. Затем этот пользователь может добавить в организацию дополнительных пользователей и установить роль каждого пользователя.
2. Модуль «шлюз», модуль, содержащий процессоры сообщений.

Организация может содержать одну или несколько сред. Процедура установки Edge по умолчанию предлагает создать две среды: «test» и «prod». Однако при необходимости вы можете создать больше сред, таких как «постановка», «эксперименты» и т. д.

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

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

О средах

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

Организация может содержать несколько сред. Например, вы можете определить в организации среду «разработки», «тестирования» и «продукта».

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

Чтобы создать среду, укажите две части информации:

1. Организация, содержащая окружающую среду.
2. Процессоры сообщений, которые обрабатывают запросы прокси-сервера API к среде. Эти обработчики сообщений должны находиться в модуле, связанном с родительской организацией среды.
   По умолчанию, когда вы создаете среду, Edge связывает все доступные процессоры сообщений в модуле «шлюз» со средой. Альтернативно вы можете указать подмножество доступных процессоров сообщений, чтобы разные процессоры сообщений обрабатывали запросы к разным средам.

Процессор сообщений может быть связан с несколькими средами. Например, ваша установка Edge содержит два процессора сообщений: A и B. Затем вы создаете в своей организации три среды: «dev», «test» и «prod»:

• Для среды «dev» вы связываете процессор сообщений A, поскольку не ожидаете большого объема трафика.
• Для «тестовой» среды вы связываете процессор сообщений B, поскольку не ожидаете большого объема трафика.
• В «производственной» среде вы связываете оба процессора сообщений A и B для обработки объема производственного уровня.

Все процессоры сообщений, назначенные среде, могут быть из одного модуля или из нескольких модулей, охватывающих несколько регионов и центров обработки данных. Например, вы определяете «глобальную» среду в своей организации, включающую процессоры сообщений из трех регионов, то есть трех разных центров обработки данных: США, Японии и Германии.

Развертывание прокси-сервера API в «глобальной» среде приводит к запуску прокси-сервера API на процессорах сообщений во всех трех центрах обработки данных. Трафик API, поступающий на маршрутизатор в любом из этих центров обработки данных, будет направляться только на процессоры сообщений в этом центре обработки данных, поскольку маршрутизаторы направляют трафик только на процессоры сообщений в том же модуле.

О виртуальных хостах

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

Убедитесь, что номер порта, указанный виртуальным хостом, открыт на узле маршрутизатора. Затем вы можете получить доступ к прокси-серверу API, отправив запрос на следующие URL-адреса:

http://routerIP:port/proxy-base-path/resource-name
https://routerIP:port/proxy-base-path/resource-name

Где:

• http или https : если виртуальный хост настроен на поддержку TLS/SSL, используйте HTTPS. Если виртуальный хост не поддерживает TLS/SSL, используйте HTTP.
• routerIP:port — это IP-адрес и номер порта виртуального хоста.
• proxy-base-path и resource-name определяются при создании прокси-сервера API.

Обычно вы не публикуете свои API-интерфейсы для клиентов с указанием IP-адреса и номера порта. Вместо этого вы определяете запись DNS для маршрутизатора и порта. Например:

http://myAPI.myCo.com/proxy-base-path/resource-name
https://myAPI.myCo.com/proxy-base-path/resource-name

Вы также должны создать псевдоним хоста для виртуального хоста, который соответствует имени домена записи DNS. В приведенном выше примере вы должны указать псевдоним хоста myAPI.myCo.com . Если у вас нет записи DNS, установите в качестве псевдонима хоста IP-адрес маршрутизатора и порт виртуального хоста, например routerIP:port .

Дополнительную информацию см. в разделе О виртуальных хостах .

Создание вашей первой организации, среды и виртуального хоста

После завершения процесса установки Edge вашим первым действием обычно является создание организации, среды и виртуального хоста посредством процесса «подключения». Чтобы выполнить подключение, выполните следующую команду на узле Edge Management Server:

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

Эта команда принимает в качестве входных данных файл конфигурации, который определяет пользователя, организацию, среду и виртуальный хост.

Например, вы создаете:

• Пользователь по вашему выбору в качестве администратора организации.
• Организация с названием example
• Среда в организации с именем prod , которая связана со всеми процессорами сообщений в модуле «шлюз».
• Виртуальный хост в среде с именем default , который разрешает доступ HTTP к порту 9001.
• Псевдоним хоста для виртуального хоста

После запуска этого сценария вы можете получить доступ к своим API, используя URL-адрес в форме:

http://routerIP:9001/proxy-base-path/resource-name

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

Дополнительную информацию см. в разделе Регистрация в организации .