Questa pagina è stata tradotta dall'API Cloud Translation.

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

Edge per Private Cloud v. 4.16.05

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

Nella tabella seguente vengono descritte queste relazioni:

	Contiene	Associato a	Predefinita
Pianeta	Una o più regioni		n/d
Regione	Uno o più pod		"dc-1"
Pod	Uno o più componenti Edge		"centrale" "gateway" "analisi"
Organizzazione	Uno o più ambienti	Uno o più pod contenenti processori di messaggi e un utente che funge da amministratore dell'organizzazione	nessuno
Ambiente	Uno o più host virtuali	Uno o più processori di messaggi in un pod associato all'organizzazione principale	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 in 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, crea una singola regione denominata "dc-1" contenente tre pod, come illustrato nella tabella seguente mostra:

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 "gateway" pod. Il "gateway" pod contiene i componenti Router Edge e Processore di messaggi che gestiscono le richieste API. A meno che tu non più data center, non è necessario creare altre regioni.

In un'installazione più complessa, puoi creare due o più regioni. Un motivo per creare più regioni consiste nell'organizzare le macchine geograficamente, riducendo al minimo il tempo di transito della rete. Nella in questo scenario, ospiti endpoint API in modo che siano geograficamente "vicino" al per i consumatori di queste API.

In Edge, ogni regione è definita data center. Un data center del Gli Stati Uniti orientali possono quindi gestire le richieste in arrivo da Boston, Massachusetts, mentre un data center si trova 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. The Edge i componenti possono essere installati sullo stesso nodo, ma sono più comunemente 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 seguenti componenti Edge e datastore Cassandra con ciascun pod:

Pod	Componenti Edge	Datastore Cassandra
"gateway"	Router, processore di messaggi	datastore-cache contatore-datastore dc-datastore	keyvaluemap-datastore kms-datastore
"centrale"	Server di gestione, Zookeeper, LDAP, UI, Qpid	application-datastore apimodel-datastore audit-datastore	auth-datastore management-server datastore-impostazioni-utente
"analisi"	Postgres	analytics-datastore	reportcrud-datastore

I componenti Edge e i datastore Cassandra nel "gateway" sono obbligatori per l'API e l'elaborazione dei dati. Questi componenti e datastore devono essere attivi per elaborare le richieste API. La e datastore nel settore "centrale" e "analisi" i pod non sono tenuti a elaborare le API, ma aggiungere ulteriori funzionalità a Edge.

L'immagine seguente mostra i componenti di ogni pod:

Puoi aggiungere altri pod del router e del processore di messaggi ai tre creati predefinito. In alternativa, puoi aggiungere ulteriori componenti Edge a un pod esistente. Ad esempio: puoi aggiungere altri router e processori di messaggi al "gateway" di pod da gestire per la gestione del carico di traffico.

Nota che il "gateway" contiene i componenti Router Edge e Processore di messaggi. I router inviano solo richieste ai processori di messaggi nello stesso pod e non ai processori di messaggi nelle e gli altri pod.

Puoi utilizzare la seguente chiamata API per visualizzare i dettagli di registrazione del server al termine della 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 è:

gateway
centrale
Analytics

Ad esempio, per il "gateway" pod:

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

L'output sarà visualizzato nel seguente formato:

[ {
  "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. Nota che riporta i dati di Cassandra e i datastore registrati nel pod. Mentre i nodi Cassandra sono installati nel "gateway" pod, vedrà 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 basati su API, app e sviluppatori. Un'organizzazione è associata a uno o più pod in cui 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, devi specificare due informazioni:

Un utente con il ruolo di amministratore dell'organizzazione. L'utente può quindi aggiungere altri utenti all'organizzazione e imposta il ruolo di ciascun utente.
Il "gateway" , il pod contenente i processori di messaggi.

Un'organizzazione può contenere uno o più ambienti. La procedura di installazione perimetrale predefinita richiede la creazione di due ambienti: "test" e "prod". Tuttavia, puoi creare altri ambienti in base alle necessità, ad esempio "temporaneo", "esperimenti" e così via

L'organizzazione fornisce l'ambito per alcune funzionalità Apigee. Ad esempio, mappa chiave-valore (KVM) i dati sono disponibili a livello di organizzazione, ovvero in tutti gli ambienti. Altre funzionalità come la memorizzazione nella cache, hanno come ambito un ambiente specifico. I dati di analisi di Apigee sono partizionati combinazione di organizzazione e ambiente.

Di seguito sono riportati gli oggetti principali di un'organizzazione, compresi quelli definiti a livello globale organizzazione 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'API a un singolo ambiente o a più ambienti.

Un'organizzazione può contenere più ambienti. Ad esempio, puoi definire "sviluppo", "test" e "prod" all'interno di un'organizzazione.

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

Per creare un ambiente, specifica due informazioni:

L'organizzazione che contiene l'ambiente.
I processori di messaggi che gestiscono le richieste proxy API all'ambiente. Questi messaggi I processori devono essere in un pod associato all'organizzazione padre dell'ambiente.
Per impostazione predefinita, quando crei un ambiente, Edge associa tutti i processori di messaggi disponibili il "gateway" un pod con l'ambiente. In alternativa, puoi specificare un sottoinsieme processori di messaggi disponibili in modo che diversi processori di messaggi gestiscano le richieste a diverse ambienti cloud-native.

Un processore di messaggi può essere associato a più ambienti. Ad esempio, il cluster contiene due processori di messaggi: A e B. Poi creerai tre ambienti organizzazione: "dev", "test" e "prod":

Per "dev" , devi associare il processore di messaggi A perché non prevedi di un grande volume di traffico.
Per il "test" , assocerai il processore di messaggi B perché non ti aspetti di un grande volume di traffico.
Per il comando "prod" , devi associare i processori di messaggi A e B per gestire a livello di produzione.

I processori di messaggi assegnati a un ambiente possono provenire tutti dallo stesso pod più pod in più regioni e data center. Ad esempio, definisci ambiente "globale" che include processori di messaggi provenienti da tre regioni, ovvero tre diversi data center: Stati Uniti, Giappone e Germania.

Deployment di un proxy API nel dominio "globale" causa l'esecuzione del proxy API su Message Processori in tutti e tre i data center. Traffico API in arrivo verso un router in uno qualsiasi di questi saranno indirizzati esclusivamente ai processori di messaggi di quel data center, in quanto indirizzare 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, di conseguenza, 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 accedi a un proxy API effettuando una richiesta a:

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 supporta TLS/SSL, utilizza HTTPS. Se l'host virtuale non supporta TLS/SSL, utilizza HTTP.
<routerIP>:<port> è l'indirizzo IP l'indirizzo e il numero di porta dell'host virtuale.
{proxy-base-path} e {resource-name} definita quando crei il proxy API.

In genere, le API non vengono pubblicate per i clienti con un indirizzo IP e un numero di porta. Dovrai 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 inoltre creare un alias host per l'host virtuale che corrisponda al nome di dominio del DNS . Nell'esempio precedente, specificheresti un alias host di myAPI.myCo.com. Se non disponi di una voce DNS, imposta l'alias host sull'indirizzo IP del router e sulla porta di l'host virtuale, nel formato <routerIP>:port.

Per ulteriori informazioni, vedi http://apigee.com/docs/api-services/content/virtual-hosts.

È in corso la creazione della tua prima organizzazione e l'host virtuale

Dopo aver completato il processo di installazione di Edge, la prima azione è in genere la creazione di un dell'organizzazione, dell'ambiente e dell'host virtuale e il processo di sviluppo. Per eseguire per l'onboarding, esegui questo comando sul nodo Edge Management Server:

/<inst_root>/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

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

Ad esempio, crei:

Un utente di tua scelta che ricopri il ruolo di amministratore dell'organizzazione.
Un'organizzazione denominata example
Un ambiente nell'organizzazione denominato prod associato a tutti gli account Processori nel "gateway" pod
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 formato:

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

In seguito potrai aggiungere il numero desiderato di organizzazioni, ambienti e host virtuali.

Per ulteriori informazioni sull'onboarding, vedi Eseguire l'onboarding di una dell'organizzazione.