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

Edge for Private Cloud v4.18.01

Une installation sur site de cloud privé Edge, ou instance de périphérie, se compose de plusieurs composants Edge installés sur un ensemble de nœuds de serveur. L'image suivante montre la relation entre la planète, les régions, les pods, les organisations, les environnements et les hôtes virtuels qui constituent une instance Edge:

Le tableau suivant décrit ces relations:

Contient Associé à 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"
"gateway"
"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 none
Environment Un ou plusieurs hôtes virtuels Un ou plusieurs processeurs de messages dans un pod associé à l'organisation parente none
Hôte virtuel Un ou plusieurs alias d'hôte none

À propos des planètes

Une planète représente un environnement matériel et logiciel Edge complet, et peut contenir une ou plusieurs régions. Dans Edge, une planète est un regroupement logique de régions. Vous ne créez ni ne configurez explicitement une planète dans le cadre de l'installation d'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" et contenant trois pods, comme indiqué dans le tableau suivant:

Région Pods de la région
DC-1 "passerelle", "central", "analytique"

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

Cette image montre l'équilibreur de charge qui dirige le trafic vers le pod de la "passerelle". Le pod de "passerelle" contient les composants Edge Router et Message Processor, qui gèrent les requêtes API. À moins de 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 de transit du réseau. Dans ce scénario, vous hébergez les points de terminaison des API afin qu'ils soient géographiquement proches des utilisateurs de ces API.

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

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

À propos des pods

Un pod est un regroupement d'un ou de plusieurs composants Edge et de datastores Cassandra. Les composants Edge peuvent être installés sur le même nœud, mais le sont plus souvent 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 les composants Edge et les datastores Cassandra suivants à chaque pod:

Pod Composants Edge

Datastores Cassandra
"gateway" Routeur, processeur de messages cache-datastore
Counter-datastore
dc-datastore 		mappage-valeur-clé-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
"analytics" Postgres analytics-datastore reportcrud-datastore

Les composants Edge et les datastores Cassandra du pod de "passerelle" sont requis pour le traitement de l'API. Ces composants et datastores doivent être opérationnels pour traiter les requêtes API. Les composants et les datastores des pods "central" et "analytics" ne sont pas requis pour traiter les API, mais ajoutent 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 supplémentaires aux trois pods créés par défaut. Vous pouvez également ajouter des composants Edge supplémentaires à un pod existant. Par exemple, vous pouvez ajouter des routeurs et des processeurs de messages supplémentaires au pod de "passerelle" pour gérer les charges de trafic accrues.

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

Vous pouvez utiliser l'appel d'API suivant pour afficher les détails de l'enregistrement du serveur à la fin de l'installation 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 correspond à l'adresse IP ou au nom DNS du serveur de gestion, et podName est soit:

  • gateway
  • central
  • analytics

Par exemple, pour le pod de "passerelle" :

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

Le résultat se présente sous la forme suivante:

[ {
  "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'elle liste les datastores Cassandra enregistrés dans le pod. Lorsque les nœuds Cassandra sont installés dans le pod de "passerelle", vous verrez les datastores Cassandra enregistrés auprès de tous les pods.

À 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, chacun d'eux devant contenir un ou plusieurs processeurs de messages.

Dans une installation de cloud privé Edge sur site, il n'existe aucune organisation par défaut. Lorsque vous créez une organisation, vous devez spécifier deux informations:

  1. Utilisateur faisant office d'administrateur de l'organisation. Cet utilisateur peut ensuite ajouter d'autres utilisateurs à l'entreprise et définir le rôle de chaque utilisateur.
  2. Le pod de "passerelle", c'est-à-dire le pod contenant les processeurs de messages.

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

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

Vous trouverez ci-dessous les principaux objets d'une organisation, y compris ceux définis globalement dans l'organisation et ceux définis spécifiquement à un environnement:

À propos des environnements

Un environnement est un contexte d'exécution d'exécution pour les proxys d'API d'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 environnement "dev", "test" et "prod" dans une organisation.

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

Pour créer un environnement, indiquez deux informations:

  1. Organisation contenant l'environnement.
  2. Les processeurs de messages qui traitent les requêtes de proxy d'API à l'environnement. Ces processeurs de messages 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 du pod de "passerelle" à l'environnement. Vous pouvez également spécifier un sous-ensemble des processeurs de messages disponibles afin que différents processeurs de messages traitent les requêtes adressées à différents environnements.

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

  • Pour l'environnement "dev", associez le processeur de messages A, car vous ne prévoyez pas un volume de trafic important.
  • Pour l'environnement de test, vous devez associer le processeur de messages B, car vous ne prévoyez pas un volume de trafic important.
  • Dans l'environnement de production, vous associez les processeurs de messages A et B pour gérer le volume au niveau de la production.

Les processeurs de messages attribués à un environnement peuvent tous provenir du même pod ou de plusieurs pods couvrant plusieurs régions et centres de données. Par exemple, vous définissez l'environnement "mondial" dans votre organisation et qui inclut des processeurs de messages de trois régions, c'est-à-dire trois centres de données différents: Allemagne, États-Unis et Japon.

Le déploiement d'un proxy d'API dans l'environnement "mondial" entraîne l'exécution du proxy d'API sur les processeurs de messages des trois centres de données. Le trafic des API arrivant sur un routeur de l'un de ces centres de données serait dirigé uniquement vers les processeurs de messages de ce centre de données, car les routeurs dirigent le trafic uniquement vers les processeurs de messages du même pod.

À propos des hôtes virtuels

Un hôte virtuel définit le port du routeur périphérique 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 du routeur. Vous pouvez ensuite accéder à un proxy d'API en envoyant une requête à:

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 être 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 le proxy d'API.

En règle générale, vous ne publiez pas vos API pour des 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 de l'entrée DNS. Dans l'exemple ci-dessus, vous devez spécifier l'alias d'hôte myAPI.myCo.com. Si vous n'avez pas d'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 À propos des hôtes virtuels.

Création de votre première organisation, de votre premier environnement et de votre premier hôte virtuel...

Une fois le processus d'installation de Edge terminé, votre première action consiste généralement à créer une organisation, un environnement et un hôte virtuel via le processus d'intégration. Pour effectuer l'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 utilise un fichier de configuration qui définit un utilisateur, une organisation, un environnement et un hôte virtuel.

Par exemple, vous créez:

  • un utilisateur de votre choix agissant en tant qu'administrateur de l'organisation
  • Une organisation nommée example
  • Un environnement de l'organisation nommé prod, qui est associé à tous les processeurs de messages du pod de "passerelle"
  • 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 pourrez 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.