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

Edge para nube privada v4.18.05

Una instalación local de Edge para la nube privada 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:

Acerca de los planetas

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

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:

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 de "puerta de enlace". El Pod "puerta de enlace" contiene los componentes de 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. Un motivo 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 endpoints de API para que estén geográficamente cerca de los consumidores de esas APIs.

En Edge, cada región se conoce como un 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 se originan en dispositivos o computadoras de Asia.

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

Información 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 se instalan con más frecuencia en nodos diferentes. 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 almacenes de datos de Cassandra con cada Pod:

Los componentes de Edge y los almacenes de datos de Cassandra en el pod de "puerta de enlace" 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 almacenes de datos en los pods "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 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 Message Processors adicionales al Pod "puerta de enlace" para controlar el aumento de las cargas de tráfico.

Observa que el Pod "gateway" contiene los componentes Edge Router y Message Processor. Los routers solo envían solicitudes a los Message Processors del mismo Pod y no a los Message Processors 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 valores:

• gateway
• central
• analytics

Por ejemplo, para el Pod "gateway":

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

Apigee devuelve 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 se enumeran los almacenes de datos de Cassandra registrados en el Pod. Mientras los nodos de Cassandra se instalan en el Pod de la "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 en una cuenta de Apigee, incluidas las APIs, los productos de API, las apps y los desarrolladores. Una organización se asocia con uno o más Pods, en los que cada Pod debe contener uno o más Message Processors.

En una instalación local de Edge para la nube privada, 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 "gateway", que contiene los Message Processors

Una organización puede contener uno o más entornos. El procedimiento de instalación predeterminado de Edge 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 el alcance para algunas funciones de Apigee. Por ejemplo, los datos del mapa de pares 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 con una combinación de organización y entorno.

A continuación, se muestran los objetos principales de una organización, incluidos los que se definen de forma global en la organización y los que se definen de forma específica 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 de "desarrollo", "prueba" y "producción" en una organización.

Cuando creas un entorno, lo asocias con uno o más Message Processors. Puedes pensar en un entorno como un conjunto con nombre de Message Processors en los 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. Es la organización que contiene el entorno.
2. Los Message Processors que controlan las solicitudes de proxy de API al entorno. Estos Message Processors deben estar en un pod asociado con la organización superior del entorno.
   De forma predeterminada, cuando creas un entorno, Edge asocia todos los Message Processors disponibles en el Pod "puerta de enlace" con el entorno. Como alternativa, puedes especificar un subconjunto de los Message Processors disponibles para que diferentes Message Processors controlen las solicitudes a diferentes entornos.

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

• Para el entorno "dev", asocia el Message Processor A porque no esperas un gran volumen de tráfico.
• Para el entorno "test", asocia el Message Processor B porque no esperas un gran volumen de tráfico.
• Para el entorno "prod", asocia los Message Processors A y B para controlar el volumen a nivel de producción.

Los Message Processors asignados a un entorno pueden ser todos 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 Message Processors de tres regiones, lo que significa tres centros de datos diferentes: EE.UU., Japón y Alemania.

Implementar 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 Message Processors de ese centro de datos, ya que los routers solo dirigen el tráfico a los Message Processors del mismo Pod.

Acerca de los hosts virtuales

Un host virtual define el puerto en el router de Edge 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, como mínimo, 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

Donde:

• 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, define 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 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, la primera acción suele ser crear una organización, un entorno y un host virtual a través del proceso de "incorporación". Para realizar la incorporació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 que elijas para 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 Message Processors en el Pod de "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 con una URL que tenga 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 Incorpora una organización.