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

Edge for Private Cloud v. 4.17.01

Una instalación local de la nube privada perimetral, o una instancia de Edge, consta de varios Componentes perimetrales 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 de hardware y software de Edge completo y puede contener en una o más regiones. En Edge, un planeta es una agrupación lógica de regiones; no crear o configurar explícitamente 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 muestra:

En la siguiente imagen, se muestran las regiones predeterminadas:

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

En una instalación más compleja, puedes crear dos o más regiones. Un motivo para crear múltiples regiones es organizar las máquinas geográficamente, lo que minimiza el tiempo en tránsito de la red. En en este caso, alojas extremos de APIs para que estén geográficamente “cercanos” del los consumidores de esas APIs.

En Edge, cada región se conoce como un centro de datos. Un centro de datos en la Este de EE.UU. podrá entonces gestionar las solicitudes provenientes de Boston, Massachusetts, mientras que un centro de datos en Singapur puede administrar solicitudes que se originen 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 un grupo de uno o más componentes de Edge y almacenes de datos de Cassandra. El perímetro se pueden instalar en un mismo nodo, pero se suelen instalar en otros. Un almacén de datos de Cassandra es un repositorio de datos que usan los componentes de Edge en el Pod.

Cuando instalas Edge, el instalador crea tres Pods y asocia los 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 la “puerta de enlace” Pods son obligatorios para la API el procesamiento de datos. Estos componentes y almacenes de datos deben estar en funcionamiento para procesar las solicitudes a la API. El y almacenes de datos en la zona “central” y "estadísticas" los Pods no son necesarios para procesar APIs, pero agregar más funcionalidades 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 crea 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 a la “puerta de enlace” Pod para manejar un aumento cargas de tráfico.

Ten en cuenta que la "puerta de enlace" contiene los componentes del router perimetral y el procesador de mensajes. Los routers solo envían solicitudes a los procesadores de mensajes del mismo Pod y no a los otros Pods.

Puedes usar la siguiente llamada a la API para ver los detalles de registro del servidor al final del instalación para cada Pod. 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:

• puerta de enlace
• central
• Analytics

Por ejemplo, para la "puerta de enlace" grupo de anuncios:

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

Verás un resultado en 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 enumera el tipo de componente. Observa que enumera el modelo los almacenes de datos registrados en el Pod. Mientras los nodos de Cassandra están instalados en la “puerta de enlace” pod, tú 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, lo que incluye APIs, productos de API, apps y desarrolladores. Una organización está asociada con uno o más Pods, en la que 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, especificas dos datos:

1. Usuario que funciona como administrador de la organización. Ese usuario puede agregar usuarios a la organización y establece el rol de cada usuario.
2. La “puerta de enlace” que contiene los Message Processors.

Una organización puede contener uno o más entornos. Procedimiento de instalación predeterminado de Edge te solicitará crear 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 alcance para algunas capacidades de Apigee. Por ejemplo, mapa clave-valor (KVM) los datos están disponibles a nivel de la organización, es decir, en todos los entornos. Otras capacidades, como el almacenamiento en caché, se limitan a un entorno específico. Los datos de estadísticas de Apigee se particionan mediante un combinación de organización y entorno.

A continuación, se muestran los principales objetos de una organización, incluidos aquellos definidos de manera global en el organización y aquellos 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 de 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 “dev”, “test” y “prod” en una organización.

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

Para crear un entorno, especifica dos datos:

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

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

• Para el comando “dev” asocia el Message Processor A porque no esperas un gran volumen de tráfico.
• Para el término "prueba" asocia el Message Processor B porque no esperas un gran volumen de tráfico.
• Para la producción asocia los procesadores de mensajes A y B para controlar a nivel de producción.

Todos los Message Processor asignados a un entorno pueden pertenecer al mismo Pod o de varios Pods, que abarcan múltiples regiones y centros de datos. Por ejemplo, puedes definir entorno “global” en tu organización, que incluye Procesadores de mensajes de tres regiones tres centros de datos diferentes: EE.UU., Japón y Alemania.

Implementa un proxy de API en la red “global” entorno, hace que el proxy de API se ejecute en mensajes Procesadores en los tres centros de datos. el tráfico de API que llega a un router en cualquiera de esos los centros de datos solo se dirigirán a los procesadores de mensajes de ese centro solo dirige el tráfico a los procesadores de mensajes del mismo Pod.

Acerca de los hosts virtuales

Un host virtual define el puerto del 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 tener al menos un host virtual.

Asegúrate de que el número de puerto que especifica el host virtual esté abierto en el nodo del router. Puedes luego, acceder a un proxy de API mediante una solicitud a la siguiente dirección:

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 admite TLS/SSL, usa HTTPS. Si el host virtual no admite TLS/SSL, usa HTTP.
• <routerIP>:<port> es la IP y el número de puerto del host virtual.
• {proxy-base-path} y Se definieron {resource-name} cuando crees 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 del DNS. entrada. En el ejemplo anterior, deberías especificar un alias de host de myAPI.myCo.com. Si no tienes una entrada DNS, configura el alias del host para la dirección IP del router y el puerto de el host virtual, como <routerIP>:port.

Para obtener más información, consulta http://apigee.com/docs/api-services/content/virtual-hosts.

Creando tu primera organización, de red y el host virtual

Después de completar el proceso de instalación de Edge, por lo general, tu primera acción es crear un organización, entorno y host virtual a través de la el proceso de administración de recursos. Para realizar 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, organización, entorno y un host virtual.

Por ejemplo, puedes crear lo siguiente:

• Un usuario que elijas para funcionar como administrador de la organización
• Una organización llamada example
• Un entorno en la organización llamado prod que está asociado a todos los mensajes Procesadores en la “puerta de enlace” grupo
• Un host virtual en el entorno llamado default que permite el acceso HTTP en el puerto 9,001
• Alias de host para el host virtual

Después de ejecutar esa secuencia de comandos, puedes acceder a tus APIs a través de una URL en el formulario siguiente:

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

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

Para obtener más información sobre la integración, consulta Integra un de Google Cloud.