Informazioni su pianeti, regioni, pod, organizzazioni, ambienti e host virtuali

Edge for Private Cloud v4.18.05

Un'installazione on-premise di Edge Private Cloud o un'istanza Edge è composta da più componenti Edge installati su un insieme di nodi di server. L'immagine seguente mostra la relazione tra pianeta, regioni, pod, organizzazioni, ambienti e host virtuali che costituiscono un'istanza Edge:

La seguente tabella descrive queste relazioni:

Componente Contiene Associate a Predefinito
Pianeta Una o più regioni n/a
Regione Uno o più pod "dc-1"
Pod Uno o più componenti Edge "central"
"gateway"
"analytics"
Organizzazione Uno o più ambienti Uno o più pod contenenti elaboratori di messaggi e un utente che agisce come amministratore dell'organizzazione nessuno
Ambiente Uno o più host virtuali Uno o più elaboratori di messaggi in un pod associato all'organizzazione principale nessuno
Virtual Host Uno o più alias host nessuno

Informazioni sui pianeti

Un pianeta rappresenta un intero ambiente hardware e software di Edge e può contenere una o più regioni. In Edge, un pianeta è un raggruppamento logico di regioni: non crei o configuri esplicitamente un pianeta durante l'installazione di Edge.

Informazioni sulle regioni

Una regione è un raggruppamento di uno o più pod. Per impostazione predefinita, quando installi Edge, il programma di installazione crea una singola regione denominata "dc-1" contenente tre pod, come illustrato nella tabella seguente:

Regione Pod nella regione
"dc-1" "gateway", "central", "analytics"

L'immagine seguente mostra le regioni predefinite:

Questa immagine mostra il bilanciatore del carico che indirizza il traffico al pod "gateway". Il pod "gateway" contiene i componenti Edge Router e Message Processor che gestiscono le richieste API. A meno che non definisca più data center, non dovresti dover creare regioni aggiuntive.

In un'installazione più complessa, puoi creare due o più regioni. Uno dei motivi per creare più regioni è organizzare le macchine geograficamente, il che riduce al minimo il tempo di transito sulla rete. In questo scenario, ospiti gli endpoint API in modo che siano vicini geograficamente ai consumatori di queste API.

In Edge, ogni regione è indicata come data center. Un data center negli Stati Uniti ed est può gestire le richieste in arrivo da Boston, nel Massachusetts, mentre un data center a Singapore può gestire le richieste provenienti da dispositivi o computer in Asia.

Ad esempio, l'immagine seguente mostra due regioni, corrispondenti a due data center:

Informazioni sui pod

Un pod è un raggruppamento di uno o più componenti Edge e datastore Cassandra. I componenti di Edge possono essere installati sullo stesso nodo, ma in genere vengono installati su nodi diversi. Un archivio dati Cassandra è un repository di dati utilizzato dai componenti Edge nel pod.

Per impostazione predefinita, quando installi Edge, il programma di installazione crea tre pod e associa a ciascun pod i seguenti componenti Edge e datastore Cassandra:

Pod Componenti Edge

Datastore Cassandra
"gateway" Router, processore di messaggi cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"centrale" Management Server, 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

I componenti Edge e i datastore Cassandra nel pod "gateway" sono necessari per l'elaborazione dell'API. Questi componenti e datastore devono essere attivi per elaborare le richieste API. I componenti e i datastore nei pod "centrale" e "analytics" non sono necessari per l'elaborazione delle API, ma aggiungono funzionalità aggiuntive a Edge.

La seguente immagine mostra i componenti di ogni pod:

Puoi aggiungere altri pod di Message Processor e Router ai tre creati per impostazione predefinita. In alternativa, puoi aggiungere altri componenti Edge a un pod esistente. Ad esempio, puoi aggiungere altri router e processori di messaggi al pod "gateway" per gestire i carichi di traffico in aumento.

Tieni presente che il pod "gateway" contiene i componenti Edge Router e Message Processor. I router inviano richieste solo ai processori di messaggi nello stesso pod e non ai processori di messaggi in altri pod.

Puoi utilizzare la seguente chiamata API per visualizzare i dettagli della registrazione del server al termine dell'installazione per ogni pod. Si tratta di uno strumento di monitoraggio utile.

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

dove ms_IP è l'indirizzo IP o il nome DNS del server di gestione e podName è uno dei seguenti:

  • gateway
  • central
  • analytics

Ad esempio, per il pod "gateway":

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

Apigee restituisce un output simile al seguente:

[ {
  "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'attributo type elenca il tipo di componente. Tieni presente che vengono elencati i datastore Cassandra registrati nel pod. Poiché i nodi Cassandra sono installati nel pod "gateway", vedrai i datastore Cassandra registrati con tutti i pod.

Informazioni sulle organizzazioni

Un'organizzazione è un contenitore per tutti gli oggetti di un account Apigee, tra cui API, prodotti API, app e sviluppatori. Un'organizzazione è associata a uno o più pod, dove ogni pod deve contenere uno o più elaboratori di messaggi.

In un'installazione on-premise di Edge Private Cloud, non sono presenti organizzazioni per impostazione predefinita. Quando crei un'organizzazione, specifichi due informazioni:

  1. Un utente che funge da amministratore dell'organizzazione. L'utente potrà quindi aggiungere altri utenti all'organizzazione e impostare il ruolo di ciascuno.
  2. Il pod "gateway", che contiene i Message Processor.

Un'organizzazione può contenere uno o più ambienti. La procedura di installazione predefinita di Edge ti chiede di creare due ambienti: "test" e "prod". Tuttavia, puoi creare altri ambienti se necessario, ad esempio "preparazione", "esperimenti" e così via.

L'organizzazione fornisce l'ambito per alcune funzionalità di Apigee. Ad esempio, i dati delle mappe chiave-valore (KVM) sono disponibili a livello di organizzazione, ovvero in tutti gli ambienti. Altre funzionalità, come la memorizzazione nella cache, sono limitate a un ambiente specifico. I dati di Apigee Analytics vengono suddivisi in base a una combinazione di organizzazione e ambiente.

Di seguito sono riportati gli oggetti principali di un'organizzazione, inclusi quelli definiti a livello globale nell'organizzazione e quelli definiti specificamente per un ambiente:

Informazioni sugli ambienti

Un ambiente è un contesto di esecuzione in fase di runtime per i proxy API di un'organizzazione. Devi eseguire il deployment di un proxy API in un ambiente prima di potervi accedere. Puoi eseguire il deployment di un proxy API in un singolo ambiente o in più ambienti.

Un'organizzazione può contenere più ambienti. Ad esempio, in un'organizzazione potresti definire ambienti "dev", "test" e "prod".

Quando crei un ambiente, lo associ a uno o più processori di messaggi. Puoi considerare un ambiente come un insieme denominato di processori di messaggi su cui vengono eseguiti i proxy API. Ogni ambiente può essere associato agli stessi processori di messaggi o a processori diversi.

Per creare un ambiente, specifica due informazioni:

  1. L'organizzazione contenente l'ambiente.
  2. I processori di messaggi che gestiscono le richieste del proxy API all'ambiente. Questi elaboratori di messaggi devono trovarsi in un pod associato all'organizzazione principale dell'ambiente.
    Per impostazione predefinita, quando crei un ambiente, Edge associa tutti i processori di messaggi disponibili nel pod "gateway" all'ambiente. In alternativa, puoi specificare un sottoinsieme di elaboratori di messaggi disponibili in modo che elaboratori diversi gestiscano le richieste per ambienti diversi.

Un elaboratore di messaggi può essere associato a più ambienti. Ad esempio, la tua installazione di Edge contiene due elaboratori di messaggi: A e B. Poi crei tre ambienti nella tua organizzazione: "dev", "test" e "prod":

  • Per l'ambiente "dev", associ il Message Processor A perché non prevedi un volume elevato di traffico.
  • Per l'ambiente "di test", associ il Message Processor B perché non prevedi un volume elevato di traffico.
  • Per l'ambiente "prod", associa entrambi i processori di messaggi A e B per gestire il volume a livello di produzione.

Gli elaboratori di messaggi assegnati a un ambiente possono provenire tutti dallo stesso pod o da più pod, che coprono più regioni e data center. Ad esempio, nella tua organizzazione definisci l'ambiente "globale" che include gli elaboratori di messaggi di tre regioni, ovvero tre diversi data center: Stati Uniti, Giappone e Germania.

Il deployment di un proxy API nell'ambiente "globale" fa sì che il proxy API venga eseguito sui processori di messaggi in tutti e tre i data center. Il traffico API in arrivo a un router in uno di questi data center verrà indirizzato solo ai processori di messaggi in quel data center perché i router indirizzano il traffico solo ai processori di messaggi nello stesso pod.

Informazioni sugli host virtuali

Un host virtuale definisce la porta sull'Edge Router su cui è esposto un proxy API e, per estensione, l'URL utilizzato dalle app per accedere al proxy API. Ogni ambiente deve definire almeno un host virtuale.

Assicurati che il numero di porta specificato dall'host virtuale sia aperto sul nodo Router. Puoi quindi accedere a un proxy API inviando una richiesta ai seguenti URL:

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

Dove:

  • http o https: se l'host virtuale è configurato per supportare TLS/SSL, utilizza HTTPS. Se l'host virtuale non supporta TLS/SSL, utilizza HTTP.
  • routerIP:port è l'indirizzo IP e il numero di porta dell'host virtuale.
  • proxy-base-path e resource-name vengono definiti quando crei il proxy API.

In genere, non pubblichi le API per i clienti con un indirizzo IP e un numero di porta. Devi invece definire una voce DNS per il router e la porta. Ad esempio:

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

Devi anche creare un alias host per l'host virtuale che corrisponda al nome di dominio della voce DNS. Nell'esempio precedente, dovresti specificare un alias host di myAPI.myCo.com. Se non hai una voce DNS, imposta l'alias host sull'indirizzo IP del router e sulla porta dell'host virtuale, come routerIP:port.

Per saperne di più, vedi Informazioni sugli host virtuali.

Creazione della prima organizzazione, dell'ambiente e dell'host virtuale

Dopo aver completato la procedura di installazione di Edge, la prima azione in genere consiste nel creare un'organizzazione, un ambiente e un host virtuale tramite la procedura di "onboarding". Per eseguire il onboarding, esegui il seguente comando sul nodo Edge Management Server:

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

Questo comando prende come input un file di configurazione che definisce un utente, un'organizzazione, un ambiente e un host virtuale.

Ad esempio, puoi creare:

  • Un utente di tua scelta che fungerà da amministratore dell'organizzazione
  • Un'organizzazione denominata example
  • Un ambiente dell'organizzazione denominato prod associato a tutti i processori di messaggi nel pod "gateway"
  • Un host virtuale nell'ambiente denominato default che consente l'accesso HTTP sulla porta 9001
  • Alias host per l'host virtuale

Dopo aver eseguito lo script, puoi accedere alle tue API utilizzando un URL nel seguente formato:

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

In un secondo momento puoi aggiungere un numero qualsiasi di organizzazioni, ambienti e host virtuali.

Per ulteriori informazioni, consulta Eseguire l'onboarding di un'organizzazione.