Acerca de Planetas, Regiones, Pods, Organizaciones, Entornos y hosts virtuales

Edge para la nube privada v4.18.01

Una instalación local de la nube privada de Edge, o una instancia de Edge, consta de varios componentes de Edge instalados en un conjunto de nodos de servidor. En la siguiente imagen, se muestra la relación entre el planeta, las regiones, los Pods, las organizaciones, los entornos y los hosts virtuales que conforman una instancia de Edge:

En la siguiente tabla, se describen estas relaciones:

Contiene Asociado con Valor predeterminado
Planeta Una o más regiones N/A
Región Uno o más Pods “dc-1”
Pod Uno o más componentes de Edge "central"
"gateway"
"analytics"
Organization Uno o más entornos Uno o más Pods con procesadores de mensajes y un usuario que actúe como administrador de la organización ninguno
Entorno Uno o más hosts virtuales Uno o más procesadores de mensajes en un Pod asociado con la organización superior ninguno
Host virtual Uno o más alias de host ninguno

Acerca de Planetas

Un planeta representa todo un entorno de hardware y software de Edge y puede contener una o más regiones. En Edge, un planeta es una agrupación lógica de regiones; no se crea ni configura de forma explícita un planeta como parte de la instalación de Edge.

Acerca de las regiones

Una región es un grupo de uno o más Pods. De forma predeterminada, cuando instalas Edge, el instalador crea una sola región llamada “dc-1” que contiene tres pods, como se muestra en la siguiente tabla:

Región Pods en la región
“dc-1” "gateway", "central", "analytics"

En la siguiente imagen, se muestran las regiones predeterminadas:

En esta imagen, se muestra el balanceador de cargas que dirige el tráfico al Pod “puerta de enlace”. El Pod “gateway” contiene los componentes del router perimetral y del procesador de mensajes que controlan las solicitudes a la API. A menos que definas varios centros de datos, no deberías tener que crear regiones adicionales.

En una instalación más compleja, puedes crear dos o más regiones. Un motivo para crear varias regiones es organizar las máquinas geográficamente, lo que minimiza el tiempo en tránsito de la red. En esta situación, debes alojar extremos de API de modo que estén geográficamente cerca de los consumidores de esas API.

En Edge, cada región se conoce como centro de datos. Un centro de datos en el este de EE.UU. puede manejar solicitudes que llegan desde Boston, Massachusetts, mientras que un centro de datos en Singapur puede manejar solicitudes que se originan en dispositivos o computadoras en Asia.

Por ejemplo, en la siguiente imagen se muestran dos regiones que corresponden a dos centros de datos:

Acerca de los Pods

Un pod es una agrupación de uno o más componentes de Edge y almacenes de datos de Cassandra. Los componentes de Edge se pueden instalar en el mismo nodo, pero con mayor frecuencia, en nodos diferentes. Un almacén de datos de Cassandra es un repositorio de datos que usan los componentes de Edge del Pod.

De forma predeterminada, cuando instalas Edge, el instalador crea tres pods y asocia los siguientes componentes de Edge y los almacenes de datos de Cassandra con cada pod:

Pod Componentes de Edge

Almacenes de datos de Cassandra
"gateway" Router y procesador de mensajes cache-datastore
contador-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Servidor de administración, Zookeeper, LDAP, IU, Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 Identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
"analytics" Postgres analytics-datastore reportcrud-datastore

Los componentes de Edge y los almacenes de datos de Cassandra en el Pod “gateway” son necesarios para el procesamiento de la API. Estos componentes y almacenes de datos deben estar en funcionamiento para procesar las solicitudes a la API. Los componentes y los almacenes de datos de los pods “central” y “analytics” no son necesarios para procesar las APIs, pero agregan funcionalidades adicionales a Edge.

En la siguiente imagen, se muestran los componentes de cada Pod:

Puedes agregar Pods de Message Processor y Router adicionales a los tres que se crean de forma predeterminada. Como alternativa, puedes agregar componentes de Edge adicionales a un Pod existente. Por ejemplo, puedes agregar routers y procesadores de mensajes adicionales al pod de “puerta de enlace” para controlar el aumento de las cargas de tráfico.

Observa que el Pod “gateway” contiene los componentes de Edge Router y Message Processor. Los routers solo envían solicitudes a los procesadores de mensajes del mismo pod y no a los procesadores de mensajes de otros pods.

Puedes usar la siguiente llamada a la API para ver los detalles del registro del servidor al final de la instalación de cada Pod. Esta es una herramienta de supervisión útil.

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

En el ejemplo anterior, ms_IP es la dirección IP o el nombre de DNS del servidor de administración y podName es uno de los siguientes:

  • gateway
  • central
  • analytics

Por ejemplo, para el Pod “puerta de enlace”:

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

Verás el resultado con el siguiente formato:

[ {
  "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"
} ]

El atributo type indica el tipo de componente. Observa que se enumeran los almacenes de datos de Cassandra registrados en el Pod. Mientras los nodos de Cassandra se instalan en el Pod “puerta de enlace”, verás almacenes de datos de Cassandra registrados con todos los Pods.

Acerca de las organizaciones

Una organización es un contenedor para todos los objetos en una cuenta de Apigee, incluidas las APIs, los productos de API, las apps y los desarrolladores. Una organización está asociada con uno o más Pods, y cada Pod debe contener uno o más Message Processor.

En una instalación local de la nube privada perimetral, no hay organizaciones de forma predeterminada. Cuando creas una organización, debes especificar dos datos:

  1. Un usuario que funciona como administrador de la organización. Luego, el usuario puede agregar más usuarios a la organización y establecer el rol de cada uno.
  2. El Pod “puerta de enlace”, el Pod que contiene los procesadores de mensajes

Una organización puede contener uno o más entornos. El procedimiento de instalación de Edge predeterminado te solicita que crees dos entornos: “test” y “prod”. Sin embargo, puedes crear más entornos según sea necesario, como “etapa de pruebas”, “experimentos”, etcétera.

La organización proporciona permiso para algunas capacidades de Apigee. Por ejemplo, los datos de mapas clave-valor (KVM) están disponibles a nivel de organización, es decir, de todos los entornos. Otras funciones, como el almacenamiento en caché, tienen alcance en un entorno específico. Los datos de estadísticas de Apigee se particionan por una combinación de organización y entorno.

A continuación, se muestran los objetos principales de una organización, incluidos los definidos a nivel global en la organización y aquellos definidos específicamente en un entorno:

Acerca de los entornos

Un entorno es un contexto de ejecución de entorno de ejecución para los proxies de API en una organización. Debes implementar un proxy de API en un entorno para poder acceder a él. Puedes implementar un proxy de API en un solo entorno o en varios.

Una organización puede contener varios entornos. Por ejemplo, puedes definir un entorno “dev”, “test” y “prod” en una organización.

Cuando creas un entorno, lo asocias con uno o más Message Processor. Puedes considerar un entorno como un conjunto determinado de procesadores de mensajes en el que se ejecutan los proxies de API. Cada entorno puede estar asociado con los mismos procesadores de mensajes o con otros diferentes.

Para crear un entorno, especifica dos datos:

  1. Es la organización que contiene el entorno.
  2. Los Message Processors que controlan las solicitudes de proxy de API al entorno. Estos procesadores de mensajes deben estar en un Pod asociado con la organización superior del entorno.
    De forma predeterminada, cuando creas un entorno, Edge asocia con el entorno todos los procesadores de mensajes disponibles en el Pod “puerta de enlace”. Como alternativa, puedes especificar un subconjunto de los procesadores de mensajes disponibles para que estos procesen las solicitudes a distintos entornos.

Un Message Processor se puede asociar con varios entornos. Por ejemplo, tu instalación de Edge contiene dos procesadores de mensajes: A y B. Luego, crearás tres entornos en tu organización: “dev”, “test” y “prod”:

  • Para el entorno “dev”, debes asociar el procesador de mensajes A porque no esperas un gran volumen de tráfico.
  • Para el entorno de “prueba”, debes asociar el procesador B de mensajes porque no esperas un gran volumen de tráfico.
  • Para el entorno “prod”, debes asociar ambos procesadores de mensajes A y B para manejar el volumen a nivel de producción.

Los procesadores de mensajes asignados a un entorno pueden ser todos del mismo Pod o pueden ser de varios Pods, que abarquen varias regiones y centros de datos. Por ejemplo, defines el entorno “global” en tu organización, que incluye Message Processors de tres regiones, es decir, tres centros de datos diferentes: EE.UU., Japón y Alemania.

La implementación de un proxy de API en el entorno "global" hace que el proxy de API se ejecute en Message Processor en los tres centros de datos. El tráfico de API que llega a un router en cualquiera de esos centros de datos se dirigiría solo a Message Processor en ese centro de datos, ya que los routers solo dirigen el tráfico a Message Processor en el mismo Pod.

Acerca de los hosts virtuales

Un host virtual define el puerto en el router perimetral en el que se expone un proxy de API y, por extensión, la URL que usan las apps para acceder al proxy de API. Cada entorno debe definir al menos un host virtual.

Asegúrate de que el número de puerto especificado por el host virtual esté abierto en el nodo del router. Luego, puedes acceder a un proxy de API si realizas una solicitud a lo siguiente:

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

Donde:

  • http o https: Si el host virtual está configurado para admitir TLS/SSL, usa HTTPS. Si el host virtual no es compatible con TLS/SSL, usa HTTP.
  • routerIP:port es la dirección IP y el número de puerto del host virtual.
  • proxy-base-path y resource-name se definen cuando creas el proxy de API.

Por lo general, no publicas tus APIs para los clientes con una dirección IP y un número de puerto. En su lugar, defines una entrada de DNS para el router y el puerto. Por ejemplo:

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

También debes crear un alias de host para el host virtual que coincida con el nombre de dominio de la entrada de DNS. En el ejemplo anterior, debes especificar un alias de host de myAPI.myCo.com. Si no tienes una entrada de DNS, establece el alias del host para la dirección IP del router y el puerto del host virtual, como routerIP:port.

Para obtener más información, consulta Acerca de los hosts virtuales.

Crea tu primer entorno, organización y host virtual

Después de completar el proceso de instalación de Edge, la primera acción suele ser crear una organización, un entorno y un host virtual a través del proceso de “integración”. Para realizar la integración, ejecuta el siguiente comando en el nodo del servidor de administración perimetral:

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

Este comando toma como entrada un archivo de configuración que define un usuario, una organización, un entorno y un host virtual.

Por ejemplo, puedes crear lo siguiente:

  • Un usuario que elijas para actuar como administrador de la organización
  • Una organización llamada example
  • Un entorno en la organización llamado prod que está asociado con todos los procesadores de mensajes en el Pod “puerta de enlace”
  • Un host virtual en el entorno llamado default que permite el acceso HTTP en el puerto 9001
  • Alias de host para el host virtual

Después de ejecutar esa secuencia de comandos, puedes acceder a tus APIs mediante una URL con el siguiente formato:

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

Luego, puedes agregar cualquier cantidad de organizaciones, entornos y hosts virtuales.

Para obtener más información, consulta Integra una organización.