À propos des planètes, régions, pods, organisations, environnements et hôtes virtuels

Edge pour Private Cloud v4.19.01

Une installation sur site de Edge Private Cloud, ou instance Edge, se compose de plusieurs Composants Edge installés sur un ensemble de nœuds de serveur L'image suivante illustre la relation entre la planète, les régions, les pods, les organisations, les environnements et les hôtes virtuels qui constituent Instance périphérique:

Le tableau suivant décrit ces relations:

Composant Contient Associées à Par défaut
Planète Une ou plusieurs régions n/a
Région Un ou plusieurs pods "dc-1"
Pod Un ou plusieurs composants Edge "central"
"passerelle"
"analytics"
Entreprise Un ou plusieurs environnements Un ou plusieurs pods contenant des processeurs de messages et un utilisateur agissant en tant qu'administrateur de l'organisation aucun
Environment Un ou plusieurs hôtes virtuels Un ou plusieurs processeurs de messages dans un pod associé à l'organisation parente aucun
Hôte virtuel Un ou plusieurs alias d'hôte aucun

À propos des planètes

Une planète représente tout un environnement matériel et logiciel Edge, et peut contenir une ou plusieurs régions. Dans Edge, une planète est un groupe logique de régions: on n'utilise pas créer ou configurer explicitement une planète dans le cadre de l'installation de Edge.

À propos des régions

Une région est un regroupement d'un ou de plusieurs pods. Par défaut, lorsque vous installez Edge, le programme d'installation crée une région unique nommée "dc-1" contenant trois pods, comme dans le tableau ci-dessous : affiche:

Région Pods de la région
"dc-1" "passerelle", "central", "analytics"

L'image suivante montre les régions par défaut:

Cette image montre l'équilibreur de charge dirigeant le trafic vers la "passerelle" pod. La "passerelle" série d'annonces contient les composants de routeur Edge et de processeur de messages qui gèrent les requêtes API. À moins que vous définir plusieurs centres de données, vous ne devriez pas avoir à créer de régions supplémentaires.

Dans une installation plus complexe, vous pouvez créer deux régions ou plus. L'une des raisons de créer plusieurs régions est d’organiser les machines géographiquement, ce qui réduit le temps d’acheminement sur le réseau. Dans Dans ce scénario, vous hébergez les points de terminaison de l'API de sorte qu'ils soient géographiquement proches du aux utilisateurs de ces API.

Dans Edge, chaque région est appelée centre de données. Un centre de données L'est des États-Unis peut alors traiter les requêtes en provenance de Boston, dans le Massachusetts, tandis qu'un centre de données situé dans Singapour peut traiter les requêtes provenant d'appareils ou d'ordinateurs situés en Asie.

Par exemple, l'image suivante montre deux régions, correspondant à deux centres de données:

À propos des pods

Un pod est un groupe d'un ou plusieurs composants Edge et de datastores Cassandra. The Edge les composants peuvent être installés sur le même nœud, mais sont le plus souvent installés sur des nœuds différents. Un datastore Cassandra est un référentiel de données utilisé par les composants Edge du pod.

Par défaut, lorsque vous installez Edge, le programme d’installation crée trois pods et associe le les composants Edge suivants et les datastores Cassandra avec chaque pod:

Pod Composants Edge

Datastores Cassandra
"passerelle" Routeur, processeur de messages cache-datastore
compteur-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Serveur de gestion, Zookeeper, LDAP, UI, Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
"analyse" Postgres analytics-datastore reportcrud-datastore

Les composants Edge et les datastores Cassandra de la "passerelle" "pod" sont requis pour l'API en cours de traitement. Ces composants et ces datastores doivent être opérationnels pour permettre le traitement des requêtes API. La et les datastores de la partie "central" et "analyse" les pods ne sont pas nécessaires pour traiter les API, mais ajouter des fonctionnalités supplémentaires à Edge.

L'image suivante montre les composants de chaque pod:

Vous pouvez ajouter des pods de processeur de messages et de routeur aux trois pods créés par par défaut. Vous pouvez également ajouter des composants Edge supplémentaires à un pod existant. Par exemple : vous pouvez ajouter des routeurs et processeurs de messages supplémentaires à la "passerelle" pour gérer l'augmentation du trafic.

Notez que la "passerelle" le pod contient les composants de routeur Edge et de processeur de messages. Les routeurs n'envoient des requêtes qu'aux processeurs de messages du même pod et non aux processeurs de d'autres pods.

Vous pouvez utiliser l'appel d'API suivant pour afficher les détails d'enregistrement du serveur à la fin du pour chaque pod. C'est un outil de surveillance utile.

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

Où ms_IP est l'adresse IP ou le nom DNS du serveur de gestion, et podName est l'un des éléments suivants:

  • gateway
  • central
  • analytics

Par exemple, pour la "passerelle" pod:

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

Apigee renvoie un résultat semblable à celui-ci:

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

L'attribut type indique le type de composant. Notez qu'il répertorie l'instance Cassandra datastores enregistrés dans le pod. Alors que les nœuds Cassandra sont installés dans la "passerelle" pod, vous les datastores Cassandra enregistrés auprès de tous les pods s'affichent.

À propos des organisations

Une organisation est un conteneur pour tous les objets d'un compte Apigee, y compris les API, les produits d'API, les applications et les développeurs. Une organisation est associée à un ou plusieurs pods, où chaque pod doit contenir un ou plusieurs processeurs de messages.

Dans une installation sur site de Edge Private Cloud, il n'y a aucune organisation par défaut. Lorsque vous créez une organisation, vous spécifiez deux informations:

  1. Utilisateur occupant le rôle d'administrateur de l'entreprise. Cet utilisateur peut ensuite ajouter utilisateurs à l'organisation et définir le rôle de chaque utilisateur.
  2. La "passerelle" pod contenant les processeurs de messages.

Une organisation peut contenir un ou plusieurs environnements. La procédure d'installation Edge par défaut vous invite à créer deux environnements : "test" et "prod". Toutefois, vous pouvez créer d'autres tels que "préproduction", "tests", etc.

L'organisation fournit un champ d'application pour certaines fonctionnalités Apigee. Par exemple, un mappage clé-valeur (KVM) les données sont disponibles au niveau de l'organisation, c'est-à-dire dans tous les environnements. D'autres fonctionnalités, comme la mise en cache, sont limités à un environnement spécifique. Les données d'analyse Apigee sont partitionnées combinaison d'organisation et d'environnement.

Ci-dessous figurent les principaux objets d'une organisation, y compris ceux définis à l'échelle mondiale dans le organisation, et celles qui sont définies spécifiquement pour un environnement:

À propos des environnements

Un environnement est un contexte d'exécution d'exécution pour les proxys d'API dans une organisation. Vous devez déployer un proxy d'API dans un environnement avant de pouvoir y accéder. Vous pouvez déployer un proxy d'API dans un seul environnement ou dans plusieurs environnements.

Une organisation peut contenir plusieurs environnements. Par exemple, vous pouvez définir un "dev", "test" et "prod" de l'environnement dans une organisation.

Lorsque vous créez un environnement, vous l'associez à un ou plusieurs processeurs de messages. Vous pouvez Considérez un environnement comme un ensemble nommé de processeurs de messages sur lesquels les proxys d'API s'exécutent. Toutes les peuvent être associés aux mêmes processeurs de messages ou à des processeurs différents.

Pour créer un environnement, spécifiez deux informations:

  1. Organisation contenant l'environnement.
  2. Les processeurs de messages qui gèrent les requêtes de proxy d'API vers l'environnement. Ces messages Les processeurs doivent se trouver dans un pod associé à l'organisation parente de l'environnement.
    Par défaut, lorsque vous créez un environnement, Edge associe tous les processeurs de messages disponibles dans la "passerelle" le pod avec l'environnement. Vous pouvez également spécifier un sous-ensemble les processeurs de messages disponibles de sorte que différents processeurs de messages traitent les requêtes à différents de l'infrastructure.

Un processeur de messages peut être associé à plusieurs environnements. Par exemple, votre Edge contient deux processeurs de messages: A et B. Vous créerez ensuite trois environnements dans votre organisation: "dev", "test" et "prod":

  • Pour les développeurs vous associez le processeur de messages A, car vous ne vous attendez pas à un volume important de trafic.
  • Pour le « test » vous associez le processeur de messages B, car vous ne vous attendez pas à un volume important de trafic.
  • Pour la "production" vous associez les processeurs de messages A et B pour gérer au niveau de la production.

Les processeurs de messages attribués à un environnement peuvent tous provenir du même pod plusieurs pods dans plusieurs régions et centres de données. Par exemple, vous définissez environnement "global" de votre organisation qui comprend des processeurs de messages de trois régions, ce qui signifie trois centres de données différents: États-Unis, Japon et Allemagne.

Déployer un proxy d'API sur le réseau "global" entraîne l'exécution du proxy d'API sur l'instance Processeurs dans les trois centres de données. Le trafic API arrivant à un routeur dans l'un de ces les centres de données ne seraient dirigés que vers les processeurs de messages de ce centre de données, car les routeurs diriger le trafic uniquement vers les processeurs de messages dans le même pod.

À propos des hôtes virtuels

Un hôte virtuel définit le port sur le routeur Edge sur lequel un proxy d'API est exposé, et, par extension, l'URL que les applications utilisent pour accéder au proxy d'API. Chaque environnement doit définir au moins un hôte virtuel.

Assurez-vous que le numéro de port spécifié par l'hôte virtuel est ouvert sur le nœud de routeur. Vous pouvez accédez ensuite à un proxy d'API en envoyant une requête aux URL suivantes:

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

Où :

  • http ou https: si l'hôte virtuel est configuré pour est compatible avec TLS/SSL, utilisez HTTPS. Si l'hôte virtuel n'est pas compatible avec TLS/SSL, utilisez HTTP.
  • routerIP:port est l'adresse IP et le numéro de port de l'hôte virtuel.
  • proxy-base-path et resource-name sont définis lorsque vous créez au proxy d'API.

En règle générale, vous ne publiez pas vos API pour les clients avec une adresse IP et un numéro de port. À la place, vous définissez une entrée DNS pour le routeur et le port. Exemple :

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

Vous devez également créer pour l'hôte virtuel un alias d'hôte correspondant au nom de domaine du DNS entrée. Dans l'exemple ci-dessus, vous spécifieriez l'alias d'hôte myAPI.myCo.com. Si vous ne disposez d'aucune entrée DNS, définissez l'alias d'hôte sur l'adresse IP du routeur et le port de l'hôte virtuel, en tant que routerIP:port.

Pour en savoir plus, consultez la section À propos des hôtes virtuels.

en créant votre première organisation, l'environnement et l'hôte virtuel

Après avoir terminé le processus d'installation Edge, votre première action consiste généralement à créer un de l'organisation, de l'environnement et de l'hôte virtuel processus. Pour effectuer intégration, exécutez la commande suivante sur le nœud du serveur de gestion Edge:

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

Cette commande prend en entrée un fichier de configuration qui définit un utilisateur, une organisation, un environnement et hôte virtuel.

Par exemple, vous pouvez créer les éléments suivants:

  • un utilisateur de votre choix qui occupe le rôle d'administrateur de l'entreprise.
  • Une organisation nommée example
  • Un environnement de l'organisation nommé prod, associé à tous les objets Message Processeurs de la "passerelle" série d'annonces
  • Un hôte virtuel dans l'environnement nommé default qui autorise l'accès HTTP sur le port 9001
  • Alias d'hôte pour l'hôte virtuel

Après avoir exécuté ce script, vous pouvez accéder à vos API à l'aide d'une URL au format suivant:

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

Vous pouvez ensuite ajouter autant d'organisations, d'environnements et d'hôtes virtuels que vous le souhaitez.

Pour en savoir plus, consultez Intégrer une organisation.