Acerca de planetas, regiones, pods, organizaciones, entornos y hosts virtuales

Edge para la nube privada v4.18.05

Una instalación local de Edge Private Cloud, 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 grupos, las organizaciones, los entornos y los hosts virtuales que conforman una instancia de Edge:

En la siguiente tabla, se describen estas relaciones:

Componente Contiene Asociados con Predeterminada
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 que contengan 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

Información acerca de los planetas

Un planeta representa un entorno de hardware y software de Edge completo 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 un planeta de forma explícita como parte de la instalación de Edge.

Información acerca de las regiones

Una región es una agrupación 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 "gateway". El pod "gateway" contiene los componentes Edge Router y Message Processor 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. Una razón para crear varias regiones es organizar las máquinas geográficamente, lo que minimiza el tiempo de tránsito de la red. En esta situación, alojas extremos de API para que estén cerca geográficamente de los consumidores de esas APIs.

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

Por ejemplo, en la siguiente imagen, se muestran dos regiones, correspondientes 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 lo más común es que se instalen en diferentes nodos. Un almacén de datos de Cassandra es un repositorio de datos que usan los componentes de Edge en el 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 uno de ellos:

Pod Componentes de Edge

Almacenes de datos de Cassandra
"gateway" Router y procesador de mensajes cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Servidor de administración, Zookeeper, LDAP, IU y 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 obligatorios 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 grupos "central" y "analytics" no son necesarios para procesar las APIs, pero agregan funcionalidad adicional a Edge.

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

Puedes agregar nodos de procesador de mensajes 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 cargas de tráfico más grandes.

Ten en cuenta que el pod "gateway" contiene los componentes Edge Router y Message Processor. Los routers solo envían solicitudes a los procesadores de mensajes en el mismo pod y no a los procesadores de mensajes en 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 que 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 "gateway":

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

Apigee muestra un resultado similar al siguiente:

[ {
  "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 enumera el tipo de componente. Ten en cuenta que muestra los almacenes de datos de Cassandra registrados en el pod. Mientras los nodos de Cassandra estén instalados en el pod de "puerta de enlace", verás los almacenes de datos de Cassandra registrados con todos los pods.

Acerca de las organizaciones

Una organización es un contenedor para todos los objetos de 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, en los que cada uno debe contener uno o más procesadores de mensajes.

En una instalación local de Edge Private Cloud, 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, ese usuario puede agregar usuarios adicionales a la organización y establecer el rol de cada uno.
  2. El pod de "puerta de enlace", que contiene los procesadores de mensajes.

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

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

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

Acerca de los entornos

Un entorno es un contexto de ejecución del 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 procesadores de mensajes. Puedes considerar un entorno como un conjunto con nombre de procesadores de mensajes en el que se ejecutan los proxies de API. Cada entorno se puede asociar con los mismos Message Processors o con otros diferentes.

Para crear un entorno, especifica dos datos:

  1. La organización que contiene el entorno.
  2. Los procesadores de mensajes que controlan las solicitudes de proxy de API al entorno Estos procesadores de mensajes deben estar en un grupo asociado con la organización superior del entorno.
    De forma predeterminada, cuando creas un entorno, Edge asocia todos los procesadores de mensajes disponibles en el pod de "puerta de enlace" con el entorno. Como alternativa, puedes especificar un subconjunto de los procesadores de mensajes disponibles para que diferentes procesadores de mensajes controlen las solicitudes a diferentes entornos.

Un Message Processor se puede asociar a varios entornos. Por ejemplo, tu instalación de Edge contiene dos procesadores de mensajes: A y B. Luego, creas tres entornos en tu organización: "dev", "test" y "prod":

  • Para el entorno "dev", asocias el procesador de mensajes A porque no esperas un gran volumen de tráfico.
  • Para el entorno de "prueba", asocias el procesador de mensajes B porque no esperas un gran volumen de tráfico.
  • Para el entorno "prod", asocias los procesadores de mensajes A y B para controlar el volumen a nivel de producción.

Los procesadores de mensajes asignados a un entorno pueden ser del mismo pod o de varios pods, que abarcan varias regiones y centros de datos. Por ejemplo, defines el entorno "global" en tu organización que incluye procesadores de mensajes 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 Processors en los tres centros de datos. El tráfico de la API que llega a un router en cualquiera de esos centros de datos se dirigiría solo a los procesadores de mensajes en ese centro de datos, ya que los routers solo dirigen el tráfico a los procesadores de mensajes en el mismo grupo.

Información acerca de los hosts virtuales

Un host virtual define el puerto en el router de borde 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 realizando una solicitud a las siguientes URLs:

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

Aquí:

  • http o https: Si el host virtual está configurado para admitir TLS/SSL, usa HTTPS. Si el host virtual no admite 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, debes definir 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, especificarías un alias de host de myAPI.myCo.com. Si no tienes una entrada de DNS, establece el alias de host en la dirección IP del router y el puerto del host virtual, como routerIP:port.

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

Crea tu primera organización, entorno y host virtual

Después de completar el proceso de instalación de Edge, por lo general, tu primera acción es 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 de Edge:

/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 de tu elección que funcione 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 “gateway”
  • 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 con una URL con el siguiente formato:

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

Más adelante, puedes agregar cualquier cantidad de organizaciones, entornos y hosts virtuales.

Para obtener más información, consulta Cómo integrar una organización.