Edge per Private Cloud v4.18.05
Un'installazione on-premise di un cloud privato Edge, o di un'istanza Edge, è composta da più componenti Edge installati su un gruppo di nodi server. L'immagine seguente mostra la relazione tra il pianeta, le regioni, i pod, le organizzazioni, gli ambienti e gli host virtuali che compongono un'istanza Edge:
La tabella seguente descrive queste relazioni:
Componente | Contiene | Sensore associato a | Predefinito |
---|---|---|---|
Pianeta | Una o più regioni | n/d | |
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 processori di messaggi e un utente che agisce come amministratore dell'organizzazione | Nessuno |
Ambiente | Uno o più host virtuali | Uno o più processori di messaggi in un pod associato all'organizzazione padre | Nessuno |
Host virtuale | Uno o più alias host | Nessuno |
Informazioni sui pianeti
Un pianeta rappresenta un intero ambiente hardware e software Edge e può contenere una o più regioni. In Edge, un pianeta è un raggruppamento logico di regioni: non devi creare o configurare 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 mostra la seguente tabella:
Regione | Pod nella regione |
---|---|
"dc-1" | "gateway", "central", "analytics" |
La seguente immagine mostra le regioni predefinite:
Questa immagine mostra il bilanciatore del carico che indirizza il traffico al pod "gateway". Il pod "gateway" contiene i componenti router perimetrale e processore di messaggi che gestiscono le richieste API. A meno che non definisci più data center, non è necessario creare altre regioni.
In un'installazione più complessa, puoi creare due o più regioni. Uno dei motivi per creare più regioni è organizzare le macchine a livello geografico, riducendo al minimo il tempo di transito della rete. In questo scenario, ospiti gli endpoint API in modo che siano geograficamente vicino ai consumer di queste API.
In Edge, ogni regione è definita data center. Un data center negli Stati Uniti orientali può quindi gestire le richieste in arrivo da Boston, Massachusetts, mentre un data center a Singapore può gestire le richieste provenienti da dispositivi o computer in Asia.
Ad esempio, la seguente immagine 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 Edge possono essere installati sullo stesso nodo, ma più comunemente vengono installati su nodi diversi. Un datastore 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 i seguenti componenti Edge e datastore Cassandra a ciascun pod:
Pod | Componenti perimetrali | Datastore Cassandra |
|
---|---|---|---|
"gateway" | Router, processore di messaggi | cache-datastore contatore-datastore dc-datastore |
mappa-dati-chiave-datastore km-datastore |
"central" | Server di gestione, Zookeeper, LDAP, UI, Qpid | application-datastore apimodel-datastore audit-datastore auth-datastore |
identità-zona-datastore edgenotification-datastore management-server scheduler-datastore impostazioni-utente-datastore |
"analytics" | Postgres | analytics-datastore | reportcrud-datastore |
I componenti Edge e i datastore Cassandra nel pod "gateway" sono obbligatori per l'elaborazione delle API. Questi componenti e datastore devono essere in esecuzione per elaborare le richieste API. I componenti e i datastore nei pod "centrali" e "analytics" non sono necessari per elaborare le API, ma aggiungono ulteriori funzionalità a Edge.
L'immagine seguente mostra i componenti di ogni pod:
Puoi aggiungere ulteriori pod del processore dei messaggi e del 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 l'aumento dei carichi di traffico.
Nota che il pod "gateway" contiene i componenti Router Edge e Message Processor. I router inviano le 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 di registrazione del server al termine dell'installazione per ogni pod. Questo è un utile strumento di monitoraggio.
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 valori:
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 elenca i datastore Cassandra registrati nel pod. Mentre i nodi Cassandra sono installati nel pod "gateway", vedrai i datastore Cassandra registrati con tutti i pod.
Informazioni sulle organizzazioni
Un'organizzazione è un container per tutti gli oggetti in 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ù processori di messaggi.
In un'installazione on-premise di Edge Private Cloud, non esistono organizzazioni per impostazione predefinita. Quando crei un'organizzazione, specifichi due tipi di informazioni:
- Un utente con il ruolo di amministratore dell'organizzazione. L'utente può quindi aggiungere altri utenti all'organizzazione e impostare il ruolo di ogni utente.
- Il pod "gateway", il pod che contiene i processori di messaggi.
Un'organizzazione può contenere uno o più ambienti. La procedura di installazione Edge predefinita richiede di creare due ambienti: "test" e "prod". Tuttavia, se necessario, puoi creare altri ambienti, ad esempio "gestione temporanea", "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 da tutti gli ambienti. Altre funzionalità, come la memorizzazione nella cache, hanno come ambito un ambiente specifico. I dati di analisi di Apigee sono partizionati da una combinazione di organizzazione e ambiente.
Di seguito sono riportati gli oggetti principali di un'organizzazione, inclusi quelli definiti a livello globale al suo interno e quelli definiti specificamente per un ambiente:
Informazioni sugli ambienti
Un ambiente è un contesto di esecuzione di runtime per i proxy API in 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, potresti definire un ambiente "dev", "test" e "prod" in un'organizzazione.
Quando crei un ambiente, lo associ a uno o più processori di messaggi. Un ambiente può essere considerato 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 diversi.
Per creare un ambiente, specifica due informazioni:
- L'organizzazione contenente l'ambiente.
- I processori di messaggi che gestiscono le richieste proxy delle API all'ambiente. Questi processori di messaggi devono trovarsi in un pod associato all'organizzazione padre 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 dei processori di messaggi disponibili in modo che i vari processori di messaggi gestiscano le richieste ad ambienti diversi.
Un processore di messaggi può essere associato a più ambienti. Ad esempio, l'installazione Edge contiene due processori di messaggi: A e B. Poi creerai tre ambienti nella tua organizzazione: "dev", "test" e "prod":
- Per l'ambiente "dev", devi associare il processore di messaggi A perché non ti aspetti un volume di traffico elevato.
- Per l'ambiente "di test", devi associare il Processore di messaggi B perché non ti aspetti un volume di traffico elevato.
- Per l'ambiente di produzione, devi associare i processori di messaggi A e B per gestire il volume a livello di produzione.
I processori di messaggi assegnati a un ambiente possono provenire tutti dallo stesso pod o da più pod, che si estendono su più regioni e data center. Ad esempio, definisci l'ambiente "globale" nella tua organizzazione, che include processori 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 sarà indirizzato solo ai processori di messaggi nel data center in questione, in quanto i router indirizzano il traffico solo ai processori di messaggi nello stesso pod.
Informazioni sugli host virtuali
Un host virtuale definisce la porta sul router Edge su cui è esposto un proxy API e, per estensione, l'URL che le app utilizzano 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. Potrai quindi accedere a un proxy API effettuando una richiesta ai seguenti URL:
http://routerIP:port/proxy-base-path/resource-name https://routerIP:port/proxy-base-path/resource-name
Dove:
http
ohttps
: 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, le API non vengono pubblicate per i clienti con indirizzo IP e numero di porta. ma devi 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 inoltre creare per l'host virtuale un alias host che corrisponda al nome di dominio della voce DNS. Dall'esempio precedente, devi specificare un alias host di myAPI.myCo.com. Se non disponi di una voce DNS, imposta l'alias host sull'indirizzo IP del router e della porta dell'host virtuale come routerIP:port.
Per saperne di più, consulta Informazioni sugli host virtuali.
Creazione della prima organizzazione, ambiente e host virtuale in corso...
Dopo aver completato il processo di installazione di Edge, la prima azione consiste nel creare un'organizzazione, un ambiente e un host virtuale tramite il processo di "onboarding". Per eseguire l'onboarding, esegui questo 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, crei:
- Un utente a tua scelta che ricopri il ruolo di amministratore dell'organizzazione
- Un'organizzazione denominata
example
- Un ambiente nell'organizzazione denominata
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 API utilizzando un URL nel seguente formato:
http://routerIP:9001/proxy-base-path/resource-name
In seguito potrai aggiungere un numero qualsiasi di organizzazioni, ambienti e host virtuali.
Per ulteriori informazioni, vedi Eseguire l'onboarding di un'organizzazione.