Edge для частного облака v. 4.17.09
Локальная установка Edge Private Cloud или экземпляр Edge состоит из нескольких компонентов Edge, установленных на наборе серверных узлов. На следующем изображении показаны взаимосвязи между планетой, регионами, модулями, организациями, средами и виртуальными хостами, составляющими экземпляр Edge:
В следующей таблице описаны эти отношения:
Содержит | Связано с | По умолчанию | |
|---|---|---|---|
Планета | Один или несколько регионов | н/д | |
Область | Один или несколько модулей | "ДЦ-1" | |
капсула | Один или несколько компонентов Edge | "центральный" | |
Организация | Одна или несколько сред | Один или несколько модулей, содержащих обработчики сообщений и пользователя, выступающего в роли администратора организации. | никто |
Среда | Один или несколько виртуальных хостов | Один или несколько обработчиков сообщений в модуле, связанном с родительской организацией. | никто |
Виртуальный хост | Один или несколько псевдонимов хоста | никто |
О планетах
Планета представляет собой всю аппаратную и программную среду Edge и может содержать один или несколько регионов. В Edge планета представляет собой логическую группу регионов — вы не создаете и не настраиваете планету явным образом в рамках установки Edge.
О регионах
Регион — это группа из одного или нескольких модулей. По умолчанию при установке Edge установщик создает один регион с именем «dc-1», содержащий три модуля, как показано в следующей таблице:
Область | Капсулы в этом же регионе |
|---|---|
"ДЦ-1" | «шлюз», «центральный», «аналитика» |
На следующем изображении показаны регионы по умолчанию:
На этом изображении показан балансировщик нагрузки, направляющий трафик на модуль «шлюз». Модуль «шлюз» содержит компоненты Edge Router и Message Processor, которые обрабатывают запросы API. Если вы не определите несколько центров обработки данных, вам не придется создавать дополнительные регионы.
При более сложной установке можно создать два или более региона. Одной из причин создания нескольких регионов является географическая организация компьютеров, что сводит к минимуму время передачи данных по сети. В этом сценарии вы размещаете конечные точки API так, чтобы они были географически «близки» к потребителям этих API.
В Edge каждый регион называется центром обработки данных . Центр обработки данных на востоке США может затем обрабатывать запросы, поступающие из Бостона, штат Массачусетс, а центр обработки данных в Сингапуре может обрабатывать запросы, исходящие от устройств или компьютеров в Азии.
Например, на следующем изображении показаны два региона, соответствующие двум центрам обработки данных:
О модулях
Модуль — это группа из одного или нескольких компонентов Edge и хранилищ данных Cassandra. Компоненты Edge можно установить на одном узле, но чаще всего они устанавливаются на разных узлах. Хранилище данных Cassandra — это хранилище данных, используемое компонентами Edge в модуле.
По умолчанию при установке Edge установщик создает три модуля и связывает с каждым модулем следующие компоненты Edge и хранилища данных Cassandra:
капсула | Краевые компоненты | Хранилища данных Кассандры | |
|---|---|---|---|
"шлюз" | Маршрутизатор, процессор сообщений | хранилище данных кэша | хранилище данных карты-значения |
"центральный" | Сервер управления, Zookeeper, LDAP, пользовательский интерфейс, Qpid | хранилище данных приложений APIмодель-хранилище данных хранилище данных аудита хранилище данных аутентификации | хранилище данных идентификациизоны EdgeNotification-хранилище данных сервер управления планировщик-хранилище данных хранилище данных пользовательских настроек |
"аналитика" | Постгрес | хранилище данных аналитики | Reportcrud-хранилище данных |
Компоненты 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 — это:
- шлюз
- центральный
- аналитика
Например, для модуля «шлюз»:
> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway
Вы видите вывод в форме:
[ {
"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 по умолчанию организации отсутствуют. Когда вы создаете организацию, вы указываете две части информации:
- Пользователь, выполняющий функции администратора организации. Затем этот пользователь может добавить в организацию дополнительных пользователей и установить роль каждого пользователя.
- Модуль «шлюз», модуль, содержащий процессоры сообщений.
Организация может содержать одну или несколько сред. Процедура установки Edge по умолчанию предлагает вам создать две среды: «test» и «prod». Однако при необходимости вы можете создать больше сред, таких как «постановка», «эксперименты» и т. д.
Организация предоставляет возможности для некоторых возможностей Apigee. Например, данные карты ключ-значение (KVM) доступны на уровне организации, то есть из всех сред. Другие возможности, такие как кэширование, ограничены конкретной средой. Аналитические данные Apigee разделены по комбинации организации и среды.
Ниже показаны основные объекты организации, в том числе те, которые определены глобально в организации, а также те, которые определены специально для среды:
О средах
Среда — это контекст выполнения во время выполнения прокси-серверов API в организации. Прежде чем к нему можно будет получить доступ, необходимо развернуть прокси-сервер API в среде. Вы можете развернуть прокси-сервер API в одной или нескольких средах.
Организация может содержать несколько сред. Например, вы можете определить в организации среду «разработки», «тестирования» и «продукта».
Когда вы создаете среду, вы связываете ее с одним или несколькими процессорами сообщений. Вы можете представить себе среду как именованный набор процессоров сообщений, на которых работают прокси API. Каждая среда может быть связана с одними и теми же процессорами сообщений или с разными.
Чтобы создать среду, укажите две части информации:
- Организация, содержащая окружающую среду.
- Процессоры сообщений, которые обрабатывают запросы прокси-сервера API к среде. Эти обработчики сообщений должны находиться в модуле, связанном с родительской организацией среды.
По умолчанию, когда вы создаете среду, Edge связывает все доступные процессоры сообщений в модуле «шлюз» со средой. Альтернативно вы можете указать подмножество доступных процессоров сообщений, чтобы разные процессоры сообщений обрабатывали запросы к разным средам.
Процессор сообщений может быть связан с несколькими средами. Например, ваша установка Edge содержит два процессора сообщений: A и B. Затем вы создаете в своей организации три среды: «dev», «test» и «prod»:
- Для среды «dev» вы связываете процессор сообщений A, поскольку не ожидаете большого объема трафика.
- Для «тестовой» среды вы связываете процессор сообщений B, поскольку не ожидаете большого объема трафика.
- В «производственной» среде вы связываете оба процессора сообщений A и B для обработки объема производственного уровня.
Все процессоры сообщений, назначенные среде, могут быть из одного модуля или из нескольких модулей, охватывающих несколько регионов и центров обработки данных. Например, вы определяете «глобальную» среду в своей организации, включающую процессоры сообщений из трех регионов, то есть трех разных центров обработки данных: США, Японии и Германии.
Развертывание прокси-сервера API в «глобальной» среде приводит к тому, что прокси-сервер API запускается на процессорах сообщений во всех трех центрах обработки данных. Трафик API, поступающий на маршрутизатор в любом из этих центров обработки данных, будет направляться только на процессоры сообщений в этом центре обработки данных, поскольку маршрутизаторы направляют трафик только на процессоры сообщений в том же модуле.
О виртуальных хостах
Виртуальный хост определяет порт на пограничном маршрутизаторе, на котором доступен прокси-сервер API, и, соответственно, URL-адрес, который приложения используют для доступа к прокси-серверу API. В каждой среде должен быть определен хотя бы один виртуальный хост.
Убедитесь, что номер порта, указанный виртуальным хостом, открыт на узле маршрутизатора. Затем вы можете получить доступ к прокси-серверу API, отправив запрос:
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://<router-ip>:9001/{proxy-base-path}/{resource-name}
Позже вы сможете добавить любое количество организаций, сред и виртуальных хостов.
Дополнительную информацию о адаптации см. в разделе Адаптация организации .