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

Edge pour Private Cloud v4.18.05

Une installation sur site d'Edge Private Cloud, ou une instance Edge, se compose de plusieurs composants Edge installés sur un ensemble de nœuds serveurs. L'image suivante montre les relations 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:

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"
"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 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 de Planets

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 lors 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, l'installateur crée une seule région nommée "dc-1" contenant trois pods, comme indiqué dans le tableau suivant:

Région Pods dans la région
"dc-1" "gateway", "central", "analytics"

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

Cette image montre l'équilibreur de charge dirigeant le trafic vers le pod "gateway". Le pod "gateway" contient les composants Edge Router et Message Processor qui gèrent les requêtes API. Sauf si vous définissez plusieurs centres de données, vous ne devriez pas avoir à créer de régions supplémentaires.

Pour 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 sur le réseau. Dans ce scénario, vous hébergez des points de terminaison d'API afin qu'ils soient proches géographiquement des consommateurs 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 ainsi gérer les requêtes provenant de Boston (Massachusetts), tandis qu'un centre de données situé à Singapour peut gérer 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 plusieurs composants Edge et de datastores Cassandra. Les composants Edge peuvent être installés sur le même nœud, mais ils sont plus couramment installés sur différents nœuds. Un datastore Cassandra est un dépôt 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 magasins de données Cassandra suivants à chaque pod:

Pod Composants Edge

Datastores Cassandra
"gateway" Routeur, processeur de messages cache-datastore
counter-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
"données analytiques" Postgres analytics-datastore reportcrud-datastore

Les composants Edge et les datastores Cassandra du pod "gateway" sont nécessaires au traitement des API. Ces composants et ces datastores doivent être opérationnels pour traiter les requêtes API. Les composants et les datastores des pods "central" et "données analytiques" ne sont pas nécessaires pour traiter les API, mais ils ajoutent des fonctionnalités supplémentaires à Edge.

L'image suivante montre les composants de chaque pod:

Vous pouvez ajouter des nœuds de processeur de messages et de routeur aux trois 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 "gateway" 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 d'autres pods.

Vous pouvez utiliser l'appel d'API suivant pour afficher les informations d'enregistrement du serveur à la fin de l'installation pour chaque pod. Il s'agit d'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 le pod "gateway" :

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 liste les datastores Cassandra enregistrés dans le pod. Lorsque les nœuds Cassandra sont installés dans le pod "gateway", les datastores Cassandra sont 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 devant contenir un ou plusieurs processeurs de messages.

Dans une installation sur site d'Edge Private Cloud, aucune organisation n'est créée par défaut. Lorsque vous créez une organisation, vous devez spécifier deux informations:

  1. Utilisateur qui joue le rôle d'administrateur de l'organisation. Cet utilisateur peut ensuite ajouter d'autres utilisateurs à l'organisation et définir le rôle de chacun d'eux.
  2. Le pod "gateway", qui contient 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 environnements si nécessaire, tels que "préproduction", "tests", etc.

L'organisation fournit des champ d'application pour certaines fonctionnalités d'Apigee. Par exemple, les données de mappage clé-valeur (KVM) sont disponibles au niveau de l'organisation, c'est-à-dire depuis 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 de manière globale dans l'organisation, ainsi que ceux définis spécifiquement pour un environnement:

À propos des environnements

Un environnement est un contexte 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, 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 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 dans le pod "gateway" à l'environnement. Vous pouvez également spécifier un sous-ensemble des processeurs de messages disponibles afin que différents processeurs de messages gèrent les requêtes vers 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 créez ensuite trois environnements dans votre organisation: "dev", "test" et "prod":

  • Pour l'environnement de développement, vous associez le processeur de messages A, car vous ne vous attendez pas à un grand volume de trafic.
  • Pour l'environnement de test, vous associez le processeur de messages B, car vous ne vous attendez pas à un volume de trafic important.
  • Pour l'environnement "prod", 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 "global" dans votre organisation, qui inclut des processeurs de messages de trois régions, soit trois centres de données différents: États-Unis, Japon et Allemagne.

Le déploiement d'un proxy d'API dans l'environnement "global" entraîne l'exécution du proxy d'API sur les processeurs de messages de chacun des trois centres de données. Le trafic API arrivant à un routeur dans l'un de ces centres de données ne sera dirigé que vers les processeurs de messages de ce centre de données, car les routeurs ne redirigent le trafic que vers les processeurs de messages du 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 du routeur. Vous pouvez ensuite accéder à 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 prendre en charge TLS/SSL, utilisez HTTPS. Si l'hôte virtuel n'est pas compatible avec TLS/SSL, utilisez HTTP.
  • routerIP:port correspond à l'adresse IP et au 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 auprès des clients avec une adresse IP et un numéro de port. Vous devez plutôt définir 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 un alias d'hôte pour l'hôte virtuel qui correspond au nom de domaine de l'entrée DNS. Dans l'exemple ci-dessus, vous devez spécifier un alias d'hôte de myAPI.myCo.com. Si vous ne disposez 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, comme routerIP:port.

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

Créer votre première organisation, votre premier environnement et votre premier hôte virtuel

Une fois le processus d'installation d'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 prend en entrée 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 pour occuper le rôle d'administrateur de l'organisation
  • Une organisation nommée example
  • Un environnement de l'organisation nommé prod associé à tous les processeurs de messages du pod "gateway"
  • 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 de la forme suivante:

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

Vous pourrez ajouter un nombre illimité d'organisations, d'environnements et d'hôtes virtuels ultérieurement.

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