Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Requisiti di installazione

Edge for Private Cloud v4.18.05

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura ad alta affidabilità in un ambiente di livello di produzione.

Il seguente video fornisce indicazioni generali sul dimensionamento per l'installazione:

Per tutti gli scenari di installazione descritti in Topologie di installazione, le seguenti tabelle elencano i requisiti hardware minimi per i componenti di installazione.

In queste tabelle, i requisiti del disco rigido si aggiungono allo spazio su disco rigido richiesto dal sistema operativo. A seconda delle applicazioni e del traffico di rete, l'installazione potrebbe richiedere più o meno risorse di quelle elencate di seguito.

Componente di installazione	RAM	CPU	Hard disk minimo
Cassandra	16 GB	8 core	Spazio di archiviazione locale di 250 GB con SSD o HDD veloce che supporta 2000 IOPS
Processore di messaggi/router sulla stessa macchina	16 GB	8 core	100GB
Analytics - Postgres/Qpid sullo stesso server	16GB^*	8‑core^*	500 GB - 1 TB^ di spazio di archiviazione di rete^, preferibilmente con backend SSD, che supporti 1000 IOPS o più^
Analytics - Postgres standalone	16GB^*	8 core^*	500 GB - 1 TB^ di spazio di archiviazione di rete^, preferibilmente con backend SSD, che supporti 1000 IOPS o più^
Analytics - Qpid standalone	8 GB	4 core	30-50 GB di spazio di archiviazione locale con SSD o HDD veloce Per installazioni superiori a 250 TPS, è consigliato un HDD con spazio di archiviazione locale che supporti 1000 IOPS. La dimensione predefinita della coda Qpid è 20 GB. Se devi aggiungere ulteriore capacità, aggiungi altri nodi Qpid.
Altro (OpenLDAP, UI, server di gestione)	4 GB	2 core	60 GB

^{* Modifica i requisiti di sistema di Postgres in base alla velocità effettiva:

Meno di 250 TPS: 8 GB, 4 core possono essere considerati con spazio di archiviazione di rete gestito^*** che supporta 1000 IOPS o più
Più di 250 TPS: 16 GB, 8 core, archiviazione di rete gestita^*** che supporta 1000 IOPS o più
Più di 1000 TPS: 16 GB, 8 core, spazio di archiviazione di rete gestito^*** che supporta 2000 IOPS o più
Più di 2000 TPS: 32 GB, 16 core, spazio di archiviazione di rete gestito^*** che supporta 2000 IOPS o più
Superiore a 4000 TPS: 64 GB, 32 core, archiviazione di rete gestita^*** che supporta 4000 IOPS o superiore} ^{** Il valore del disco rigido Postgres si basa sull'analisi predefinita acquisita da Edge.
Se aggiungi valori personalizzati ai dati di analisi, questi valori devono essere aumentati di conseguenza. Utilizza la seguente formula per stimare lo spazio di archiviazione richiesto:
bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Ad esempio:
(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB} ^{*** Network Storage is recommended for Postgresql database because:

Offre la possibilità di fare lo scale up dinamico delle dimensioni dello spazio di archiviazione se e quando necessario.
Le IOPS di rete possono essere regolate in tempo reale nella maggior parte dei sottosistemi di ambiente/archiviazione/rete odierni.
Gli snapshot a livello di archiviazione possono essere abilitati nell'ambito delle soluzioni di backup e ripristino.}

Inoltre, di seguito sono elencati i requisiti hardware per l'installazione dei servizi di monetizzazione:

Componente con monetizzazione	RAM	CPU	Hard disk
Server di gestione (con servizi di monetizzazione)	8 GB	4 core	60 GB
Analytics - Postgres/Qpid sullo stesso server	16 GB	8 core	Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti almeno 1000 IOPS, oppure utilizza la regola della tabella precedente.
Analytics - Postgres standalone	16 GB	8 core	Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti almeno 1000 IOPS, oppure utilizza la regola della tabella precedente.
Analytics - Qpid standalone	8 GB	4 core	Spazio di archiviazione locale da 40 GB a 500 GB con SSD o HDD veloce Per installazioni superiori a 250 TPS, è consigliato un HDD con spazio di archiviazione locale che supporti 1000 IOPS.

Requisiti del sistema operativo e del software di terze parti

Queste istruzioni di installazione e i file di installazione forniti sono stati testati sui sistemi operativi e sul software di terze parti elencati in Software e versioni supportati.

Creazione dell'utente "apigee"

La procedura di installazione crea un utente di sistema Unix denominato "apigee". Le directory e i file Edge sono di proprietà di "apigee", così come i processi Edge. Ciò significa che i componenti Edge vengono eseguiti come utente "apigee". Se necessario, puoi eseguire i componenti come utente diverso.

Directory di installazione

Per impostazione predefinita, il programma di installazione scrive tutti i file nella directory /opt/apigee. Non puoi modificare la posizione di questa directory. Anche se non puoi modificare questa directory, puoi creare un collegamento simbolico per mappare /opt/apigee a un'altra posizione, come descritto in Creazione di un collegamento simbolico da /opt/apigee.

Nelle istruzioni di questa guida, la directory di installazione è indicata come /opt/apigee.

Creazione di un collegamento simbolico da /opt/apigee

Prima di creare il collegamento simbolico, devi creare un utente e un gruppo denominati "apigee". Si tratta dello stesso gruppo e dello stesso utente creati dal programma di installazione di Edge.

Per creare il collegamento simbolico, esegui questi passaggi prima di scaricare il file bootstrap_4.18.05.sh. Devi eseguire tutti questi passaggi come root:

Crea l'utente e il gruppo "apigee":

groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee

Crea un collegamento simbolico da /opt/apigee alla radice di installazione che preferisci:
```
ln -Ts /srv/myInstallDir /opt/apigee
```
Dove /srv/myInstallDir è la posizione desiderata dei file Edge.
Cambia la proprietà della directory root di installazione e del collegamento simbolico all'utente "apigee":
```
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
```

Java

Prima dell'installazione, devi installare una versione supportata di Java 1.8 su ogni macchina. I JDK supportati sono elencati in Software e versioni supportati.

Assicurati che la variabile di ambiente JAVA_HOME punti alla directory root del JDK per l'utente che esegue l'installazione.

Nota: il programma di installazione di Edge può installare Java 1.8 e impostare JAVA_HOME per te nell'ambito del processo di installazione di apigee-setup. Per saperne di più, consulta Installa l'utilità apigee-setup di Edge.

SELinux

A seconda delle impostazioni di SELinux, Edge potrebbe riscontrare problemi con l'installazione e l'avvio dei componenti Edge. Se necessario, puoi disattivare SELinux o impostarlo in modalità permissiva durante l'installazione e riattivarlo dopo l'installazione. Per saperne di più, consulta Installa l'utilità apigee-setup di Edge.

Impostazione della rete

Apigee consiglia di controllare le impostazioni della rete prima dell'installazione. Il programma di installazione prevede che tutte le macchine abbiano indirizzi IP fissi. Utilizza i seguenti comandi per convalidare l'impostazione:

hostname restituisce il nome della macchina
hostname -i restituisce l'indirizzo IP del nome host che può essere indirizzato da altre macchine.

A seconda del tipo e della versione del sistema operativo, potrebbe essere necessario modificare /etc/hosts e /etc/sysconfig/network se il nome host non è impostato correttamente. Per saperne di più, consulta la documentazione del tuo sistema operativo specifico.

Se un server ha più schede di interfaccia, il comando "hostname -i" restituisce un elenco di indirizzi IP separati da spazi. Per impostazione predefinita, il programma di installazione di Edge utilizza il primo indirizzo IP restituito, che potrebbe non essere corretto in tutte le situazioni. In alternativa, puoi impostare la seguente proprietà nel file di configurazione dell'installazione:

ENABLE_DYNAMIC_HOSTIP=y

Se questa proprietà è impostata su "y", il programma di installazione ti chiede di selezionare l'indirizzo IP da utilizzare nell'ambito dell'installazione. Il valore predefinito è "n". Per saperne di più, consulta il riferimento al file di configurazione di Edge.

Avviso: se imposti ENABLE_DYNAMIC_HOSTIP=y, assicurati che il file delle proprietà non imposti HOSTIP.

TCP Wrapper

I wrapper TCP possono bloccare la comunicazione di alcune porte e possono influire sull'installazione di OpenLDAP, Postgres e Cassandra. Su questi nodi, controlla /etc/hosts.allow e /etc/hosts.deny per assicurarti che non siano presenti limitazioni sulle porte OpenLDAP, Postgres e Cassandra richieste.

iptables

Verifica che non esistano policy iptables che impediscono la connettività tra i nodi sulle porte Edge richieste. Se necessario, puoi arrestare iptables durante l'installazione utilizzando il comando:

sudo/etc/init.d/iptables stop

In CentOS 7.x:

systemctl stop firewalld

Assicurati che il router perimetrale possa accedere a /etc/rc.d/init.d/functions

Il router perimetrale utilizza il router Nginx e richiede l'accesso in lettura a /etc/rc.d/init.d/functions.

Se la tua procedura di sicurezza richiede l'impostazione delle autorizzazioni su /etc/rc.d/init.d/functions, non impostarle su 700, altrimenti il router non si avvierà. Le autorizzazioni possono essere impostate su 744 per consentire l'accesso in lettura a /etc/rc.d/init.d/functions.

Cassandra

Tutti i nodi Cassandra devono essere connessi a un anello. Cassandra archivia le repliche dei dati su più nodi per garantire affidabilità e tolleranza di errore. La strategia di replica per ogni keyspace Edge determina i nodi Cassandra in cui vengono posizionate le repliche. Per saperne di più, consulta Informazioni sul fattore di replica e sul livello di coerenza di Cassandra.

Cassandra regola automaticamente le dimensioni dell'heap Java in base alla memoria disponibile. Per saperne di più, consulta Ottimizzazione delle risorse Java in caso di peggioramento delle prestazioni o consumo elevato di memoria.

Dopo aver installato Edge for Private Cloud, puoi verificare che Cassandra sia configurato correttamente esaminando il file /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Ad esempio, assicurati che lo script di installazione di Edge for Private Cloud abbia impostato le seguenti proprietà:

cluster_name
initial_token
partitioner
seeds
listen_address
rpc_address
snitch

Database PostgreSQL

Dopo aver installato Edge, puoi regolare le seguenti impostazioni del database PostgreSQL in base alla quantità di RAM disponibile sul tuo sistema:

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

Per impostare questi valori:

Modifica il file postgresql.properties:
```
vi /opt/apigee/customer/application/postgresql.properties
```
Se il file non esiste, crealo.
Imposta le proprietà elencate sopra.
Salva le modifiche.

Riavvia il database PostgreSQL:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Limiti del sistema

Assicurati di aver impostato i seguenti limiti di sistema sui nodi Cassandra e processore di messaggi:

Sui nodi Cassandra, imposta i limiti soft e hard di memlock, nofile e spazio di indirizzi (as) per l'utente di installazione (il valore predefinito è "apigee") in /etc/security/limits.d/90-apigee-edge-limits.conf come mostrato di seguito:
```
apigee soft memlock unlimited
apigee hard memlock unlimited
apigee soft nofile 32768
apigee hard nofile 65536
apigee soft as unlimited
apigee hard as unlimited
```
Sui nodi Processore di messaggi, imposta il numero massimo di descrittori del file aperti su 64K in /etc/security/limits.d/90-apigee-edge-limits.conf come mostrato di seguito:
```
apigee soft nofile 32768
apigee hard nofile 65536
```
Se necessario, puoi aumentare questo limite. Ad esempio, se hai un numero elevato di file temporanei aperti contemporaneamente.

Network Security Services (NSS)

Network Security Services (NSS) è un insieme di librerie che supporta lo sviluppo di applicazioni client e server con funzionalità di sicurezza. Assicurati di aver installato NSS v3.19 o versioni successive.

Per controllare la versione corrente:

yum info nss

Per aggiornare NSS:

yum update nss

Per saperne di più, consulta questo articolo di RedHat.

Disattiva la ricerca DNS su IPv6 quando utilizzi NSCD (Name Service Cache Daemon)

Se hai installato e attivato NSCD (Name Service Cache Daemon), i processori di messaggi eseguono due ricerche DNS: una per IPv4 e una per IPv6. Quando utilizzi NSCD, devi disattivare la ricerca DNS su IPv6.

Per disattivare la ricerca DNS su IPv6:

Su ogni nodo Processore di messaggi, modifica /etc/nscd.conf
Imposta la seguente proprietà:
```
enable-cache hosts no
```

Disattiva IPv6 su Google Cloud Platform per RedHat/CentOS 7

Se installi Edge su RedHat 7 o CentOS 7 su Google Cloud, devi disattivare IPv6 su tutti i nodi Qpid.

Per istruzioni su come disattivare IPv6, consulta la documentazione di RedHat o CentOS relativa alla versione specifica del tuo sistema operativo. Ad esempio, puoi:

Apri /etc/hosts in un editor.
Inserisci un carattere "#" nella prima colonna della riga seguente per commentarla:
```
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
```
Salva il file.

AWS AMI

Se stai installando Edge su un'immagine Amazon Machine Image (AMI) AWS per Red Hat Enterprise Linux 7.x, devi prima eseguire il seguente comando:

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Strumenti

Il programma di installazione utilizza i seguenti strumenti UNIX nella versione standard fornita da EL5 o EL6.

awk	expr	libxslt	rpm	unzip
basename	grep	lua-socket	rpm2cpio	useradd
bash	nome host	ls	sed	wc
bc	id	net-tools	sudo	wget
curl	libaio	perl (da procps)	tar	xerces-c
cyrus-sasl	libdb4	pgrep (da procps)	tr	Slurp
date	libdb-cxx	ps	uuid	chkconfig
dirname	libibverbs	pwd	uname
echo	librdmacm	python

ntpdate

Apigee consiglia di sincronizzare gli orari dei server. Se non è già configurata, l'utilità ntpdate potrebbe servire a questo scopo, ovvero verificare se i server sono sincronizzati nel tempo. Puoi utilizzare yum install ntp per installare l'utilità. Questo è particolarmente utile per replicare le configurazioni OpenLDAP. Tieni presente che il fuso orario del server è impostato su UTC.

openldap 2.4

L'installazione on-premise richiede OpenLDAP 2.4. Se il server dispone di una connessione a internet, lo script di installazione di Edge scarica e installa OpenLDAP. Se il tuo server non dispone di una connessione a internet, devi assicurarti che OpenLDAP sia già installato prima di eseguire lo script di installazione di Edge. Su RHEL/CentOS, puoi eseguire yum install openldap-clients openldap-servers per installare OpenLDAP.

Per le installazioni con 13 host e con 12 host con due data center, la replica di OpenLDAP è obbligatoria perché esistono più nodi che ospitano OpenLDAP.

Firewall e host virtuali

Il termine virtual viene comunemente sovraccaricato nel settore IT, così come avviene con un deployment di Apigee Edge for Private Cloud e gli host virtuali. Per chiarire, esistono due utilizzi principali del termine virtual:

Macchine virtuali (VM): non obbligatorie, ma alcuni deployment utilizzano la tecnologia VM per creare server isolati per i componenti Apigee. Gli host VM, come gli host fisici, possono avere interfacce di rete e firewall.
Host virtuali: endpoint web, analoghi a un host virtuale Apache.

Un router in una VM può esporre più host virtuali (purché siano diversi l'uno dall'altro nell'alias host o nella porta dell'interfaccia).

Ad esempio, un singolo server fisico A potrebbe eseguire due VM, denominate "VM1" e "VM2". Supponiamo che "VM1" esponga un'interfaccia Ethernet virtuale, denominata "eth0" all'interno della VM, a cui viene assegnato l'indirizzo IP 111.111.111.111 dal motore di virtualizzazione o da un server DHCP di rete; supponiamo poi che VM2 esponga un'interfaccia Ethernet virtuale denominata anch'essa "eth0" e che le venga assegnato un indirizzo IP 111.111.111.222.

Potremmo avere un router Apigee in esecuzione in ciascuna delle due VM. I router espongono gli endpoint degli host virtuali come in questo esempio ipotetico:

Il router Apigee in VM1 espone tre host virtuali sulla sua interfaccia eth0 (che ha un indirizzo IP specifico), api.mycompany.com:80, api.mycompany.com:443 e test.mycompany.com:80.

Il router in VM2 espone api.mycompany.com:80 (stesso nome e stessa porta esposti da VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete; in tal caso, il firewall deve essere configurato per trasmettere il traffico TCP destinato alle porte esposte sulle interfacce virtualizzate (111.111.111.111:{80, 443} e 111.111.111.222:80). Inoltre, il sistema operativo di ogni VM può fornire il proprio firewall sulla sua interfaccia eth0 e anche questi devono consentire la connessione del traffico delle porte 80 e 443.

Il percorso di base è il terzo componente coinvolto nel routing delle chiamate API ai diversi proxy API di cui potresti aver eseguito il deployment. I bundle di proxy API possono condividere un endpoint se hanno percorsi di base diversi. Ad esempio, un percorso di base può essere definito come http://api.mycompany.com:80/ e un altro come http://api.mycompany.com:80/salesdemo.

In questo caso, hai bisogno di un bilanciatore del carico o di un Traffic Director di qualche tipo che suddivida il traffico http://api.mycompany.com:80/ tra i due indirizzi IP (111.111.111.111 su VM1 e 111.111.111.222 su VM2). Questa funzione è specifica per la tua installazione particolare ed è configurata dal tuo gruppo di networking locale.

Il percorso di base viene impostato quando esegui il deployment di un'API. Nell'esempio precedente, puoi eseguire il deployment di due API, mycompany e testmycompany, per l'organizzazione mycompany-org con l'host virtuale che ha l'alias host api.mycompany.com e la porta impostata su 80. Se non dichiari un percorso di base nel deployment, il router non sa a quale API inviare le richieste in entrata.

Tuttavia, se esegui il deployment dell'API testmycompany con l'URL di base /salesdemo, gli utenti accedono all'API utilizzando http://api.mycompany.com:80/salesdemo. Se esegui il deployment dell'API mycompany con l'URL di base /, gli utenti accedono all'API tramite l'URL http://api.mycompany.com:80/.

Licenze

Ogni installazione di Edge richiede un file di licenza univoco che ottieni da Apigee. Durante l'installazione del server di gestione, dovrai fornire il percorso del file di licenza, ad esempio /tmp/license.txt.

Il programma di installazione copia il file di licenza in /opt/apigee/customer/conf/license.txt.

Se il file di licenza è valido, il server di gestione convalida la scadenza e il numero di processori di messaggi (MP) consentiti. Se una delle impostazioni della licenza è scaduta, puoi trovare i log nella seguente posizione: /opt/apigee/var/log/edge-management-server/logs. In questo caso, puoi contattare l'assistenza di Apigee Edge per i dettagli sulla migrazione.

Se non hai ancora una licenza, contatta il team di vendita di Apigee.