Requisiti hardware
Devi soddisfare i seguenti requisiti minimi per l'hardware per un'infrastruttura altamente disponibile in un ambiente di produzione.
Il seguente video fornisce indicazioni generali sulle dimensioni dell'installazione:
Per tutti gli scenari di installazione descritti in Topologie di installazione, le tabelle seguenti elencano i requisiti hardware minimi per i componenti di installazione.
In queste tabelle, i requisiti del disco rigido si aggiungono allo spazio richiesto dal sistema operativo. A seconda delle applicazioni e del traffico di rete, l'installazione potrebbe richiedere più o meno risorse rispetto a quelle elencate di seguito.
Componente di installazione | RAM | CPU | Hard disk minimo |
---|---|---|---|
Cassandra | 16 GB | 8 core | 250 GB di spazio di archiviazione locale con SSD che supporta 2000 IOPS |
Processore di messaggi/router sulla stessa macchina | 16 GB | 8 core | 100GB |
Message Processor (autonomo) | 16 GB | 8 core | 100GB |
Router (autonomo) | 16 GB | 8 core | 100GB |
Analytics - Postgres/Qpid sullo stesso server | 16GB* | 8 core* | Spazio di archiviazione di rete*** da 500 GB a 1 TB**, preferibilmente con backend SSD, supportante almeno 1000 IOPS* |
Analytics - Master o standby Postgres (autonomo) | 16GB* | 8 core* | Spazio di archiviazione di rete*** da 500 GB a 1 TB**, preferibilmente con backend SSD, supportante almeno 1000 IOPS* |
Analytics - Qpid standalone | 8 GB | 4 core | Spazio di archiviazione locale da 30 GB a 50 GB con SSD
La dimensione predefinita della coda Qpid è 1 GB, ma può essere aumentata a 2 GB. Se hai bisogno di una maggiore capacità, aggiungi altri nodi Qpid. |
OpenLDAP/UI/Management Server | 8 GB | 4 core | 60 GB |
Server di gestione/UI | 4 GB | 2 core | 60 GB |
OpenLDAP (autonomo) | 4 GB | 2 core | 60 GB |
* Modifica i requisiti di sistema di Postgres in base al throughput:
** Il valore del disco rigido Postgres si basa sugli analytics out of the box acquisiti 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 necessario:
Ad esempio:
*** Lo spazio di archiviazione di rete è consigliato per il database PostgreSQL perché:
|
Di seguito sono elencati i requisiti hardware per l'installazione dei servizi di monetizzazione (non supportati per l'installazione All-in-One):
Componente con monetizzazione | RAM | CPU | Disco rigido |
---|---|---|---|
Management Server (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 1000 IOPS o più oppure utilizza la regola riportata nella tabella precedente. |
Analytics - Postgres master o standby standalone | 16 GB | 8 core | Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti 1000 IOPS o più oppure utilizza la regola riportata nella 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 archiviazione locale che supporti 1000 IOPS. |
Requisiti di larghezza di banda della rete Cassandra
Cassandra utilizza il protocollo Gossip per scambiare informazioni con altri nodi sulla topologia di rete. L'utilizzo di Gossip, combinato con la natura distribuita di Cassandra, che prevede la comunicazione con più nodi per le operazioni di lettura e scrittura, comporta un trasferimento significativo di dati sulla rete.
Cassandra richiede una larghezza di banda di rete minima di 1 Gbps per nodo. Per le installazioni di produzione, è consigliata una larghezza di banda maggiore.
La latenza massima o del 99° percentile per Cassandra deve essere inferiore a 100 millisecondi.
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.
Prerequisito: attiva il repository EPEL
Prima di procedere con l'installazione, assicurati che il repository EPEL (Extra Packages for Enterprise Linux) sia abilitato. Utilizza i seguenti comandi in base alla versione del sistema operativo:
- Per Red Hat/CentOS/Oracle 8.X:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo rpm -ivh epel-release-latest-8.noarch.rpm
- Per Red Hat/CentOS/Oracle 9.X:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo rpm -ivh epel-release-latest-9.noarch.rpm
Java
Prima dell'installazione è necessario installare una versione supportata di Java 1.8 su ogni computer. I JDK supportati sono elencati in Software e versioni supportati.
Assicurati che la variabile d'ambiente JAVA_HOME
indichi la radice del JDK per l'utente che esegue l'installazione.
SELinux
A seconda delle impostazioni di SELinux, Edge può riscontrare problemi di installazione e avvio dei componenti di Edge. Se necessario, puoi disattivare SELinux o impostarlo in modalità permissiva durante l'installazione, quindi riattivarlo al termine dell'installazione. Per saperne di più, consulta Installare l'utilità apigee-setup di Edge.
Creazione dell'utente "apigee"
La procedura di installazione crea un utente di sistema Unix denominato "apigee". Le directory e i file di Edge sono di proprietà di "apigee", così come i processi di 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. Sebbene non sia possibile modificare questa directory, puoi creare un link simbolico per mappare /opt/apigee
a un'altra posizione, come descritto in Creare un link simbolico da /opt/apigee.
Nelle istruzioni di questa guida, la directory di installazione è indicata come
/opt/apigee
.
Creazione di un link simbolico da /opt/apigee
Prima di creare il link simbolico, devi creare un utente e un gruppo denominato "apigee". Si tratta dello stesso gruppo e dello stesso utente creati dall'installatore di Edge.
Per creare il link simbolico, esegui questi passaggi prima di scaricare il file bootstrap_4.53.00.sh. Devi eseguire tutti questi passaggi come utente 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 link simbolico da
/opt/apigee
alla home directory di installazione che preferisci:ln -Ts /srv/myInstallDir /opt/apigee
dove /srv/myInstallDir è la posizione desiderata dei file Edge.
- Modifica la proprietà della home directory dell'installazione e del link simbolico all'utente "apigee":
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Impostazione di rete
Apigee consiglia di controllare l'impostazione di rete prima dell'installazione. L'installatore si aspetta che tutte le macchine abbiano indirizzi IP fissi. Utilizza i seguenti comandi per convalidare l'impostazione:
hostname
restituisce il nome della macchinahostname -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, potresti dover modificare /etc/hosts
e /etc/sysconfig/network
se il nome host non è impostato correttamente. Per ulteriori informazioni, 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
Con questa proprietà impostata su "y", il programma di installazione ti chiede di selezionare l'indirizzo IP da utilizzare come parte dell'installazione. Il valore predefinito è "n". Per saperne di più, consulta il riferimento del file di configurazione di Edge.
Wrapper TCP
I wrapper TCP possono bloccare la comunicazione di alcune porte e influire sull'installazione di OpenLDAP, Postgres e Cassandra. Su questi nodi, controlla /etc/hosts.allow
e
/etc/hosts.deny
per assicurarti che non ci siano restrizioni per le porte obbligatorie
OpenLDAP, Postgres e Cassandra.
iptables
Verifica che non siano presenti criteri iptables che impediscano la connettività tra i nodi sulle porte Edge richieste. Se necessario, puoi interrompere iptables durante l'installazione utilizzando il comando:
sudo/etc/init.d/iptables stop
Accesso alla directory
La seguente tabella elenca le directory sui nodi Edge che hanno requisiti speciali per i processi Edge:
Servizio | Directory | Descrizione |
---|---|---|
Router | /etc/rc.d/init.d/functions |
Il router Edge utilizza il router Nginx e richiede l'accesso in lettura a
Se la procedura di sicurezza richiede di impostare le autorizzazioni su
Puoi impostare le autorizzazioni su 744 per consentire l'accesso in lettura a
|
Zookeeper | /dev/random |
La libreria client Zookeeper richiede l'accesso in lettura al generatore di numeri casuali
/dev/random . Se /dev/random è bloccato in lettura, il servizio Zookeeper potrebbe non riuscire ad avviarsi. |
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 errori. La strategia di replica per ogni spazio chiavi 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 calo delle prestazioni o consumo elevato di memoria.
Dopo aver installato Edge per il private cloud, puoi verificare che Cassandra sia configurata correttamente esaminando il file /opt/apigee/apigee-cassandra/conf/cassandra.yaml
. Ad esempio, assicurati che lo script di installazione di Edge per il cloud privato abbia impostato le seguenti proprietà:
cluster_name
initial_token
partitioner
seeds
listen_address
rpc_address
snitch
Database PostgreSQL
Dopo aver installato Edge, puoi modificare le seguenti impostazioni del database PostgreSQL in base alla quantità di RAM disponibile sul 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, creane uno.
- Imposta le proprietà elencate sopra.
- Salva le modifiche.
- Riavvia il database PostgreSQL:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
Configurazione delle impostazioni internazionali per Rocky 9.X
Se utilizzi Rocky 9.X, assicurati che il sistema sia configurato con LANG=en_US.utf8
nelle impostazioni internazionali a livello di sistema. Per configurare questa opzione, esegui i comandi seguenti:
dnf -y -q install langpacks-en localectl set-locale LANG=en_US.utf8 reboot
Limiti del sistema
Assicurati di aver impostato i seguenti limiti di sistema sui nodi Cassandra e Message Processor:
- Sui nodi Cassandra, imposta i limiti soft e hard di memlock, nofile e spazio 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 apigee soft nproc 32768 apigee hard nproc 65536
- Nei nodi di elaborazione dei messaggi, imposta il numero massimo di descrittori file aperti su 64 KB
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.
Se visualizzi il seguente errore in un router o in un elaboratore di messaggi
system.log
, è possibile che i limiti dei descrittori dei file siano impostati su valori troppo bassi:"java.io.IOException: Too many open files"
Per controllare i limiti di utenti:
# su - apigee $ ulimit -n 100000
Se continui a raggiungere i limiti di file aperti dopo aver impostato i limiti di descrittori file su
100000
, apri un ticket con l'assistenza Apigee Edge per ulteriori operazioni di risoluzione dei problemi.
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 ulteriori informazioni, 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), gli elaboratori di messaggi eseguono due ricerche DNS: una per IPv4 e una per IPv6. Devi disattivare la ricerca DNS su IPv6 quando utilizzi NSCD.
Per disattivare la ricerca DNS su IPv6:
- In ogni nodo del processore di messaggi, modifica
/etc/nscd.conf
- Imposta la seguente proprietà:
enable-cache hosts no
Disattivare IPv6 su RHEL 8 e versioni successive
Se stai installando Edge su RHEL 8 o versioni successive sulla piattaforma Google Cloud, devi disattivare IPv6 su tutti i nodi Qpid.
Per istruzioni su come disattivare IPv6, consulta la documentazione fornita dal fornitore del sistema operativo. Ad esempio, puoi trovare informazioni pertinenti nella documentazione di Red Hat Enterprise Linux.
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) |
catrame |
xerces-c |
cyrus-sasl | libdb4 | pgrep (da procps) | tr | Slurp |
data |
libdb-cxx |
ps |
UUID |
chkconfig |
dirname | libibverbs | pwd | uname | |
echo | librdmacm | python |
Sincronizzazione dell'ora
Apigee consiglia di sincronizzare l'ora dei server. Se non è già configurata, l'utilità ntpdate
o uno strumento equivalente può essere utilizzata per verificare se i server sono sincronizzati con l'ora. Ad esempio, puoi utilizzare yum install ntp
o un comando equivalente per installare l'utilità. Questo è particolarmente utile per replicare le configurazioni di OpenLDAP. Tieni presente che devi impostare il fuso orario del server su UTC.
openldap 2.4
L'installazione on-premise richiede OpenLDAP 2.4, incluso nel repository apigee-thirdparty-opdk
. Per facilitare l'installazione, rimuovi la raccolta openldap-compat
.
Per le installazioni con 13 host e per quelle con 12 host con due data center, è necessaria la replica di OpenLDAP perché sono presenti più nodi che ospitano OpenLDAP.
Firewall e host virtuali
Il termine virtual
viene spesso sovraccaricato nel settore IT, così come accade per 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 implementazioni 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é differiscano tra loro per l'alias host o per la porta dell'interfaccia).
Come esempio di denominazione, 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
dalla macchina di virtualizzazione o da un server DHCP di rete. Supponiamo inoltre che la VM2 esponga un'interfaccia Ethernet virtuale denominata anche "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 endpoint di host virtuali come in questo esempio ipotetico:
Il router Apigee nella 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 nella VM2 espone api.mycompany.com:80
(stessa porta e stesso nome di quella esposta dalla VM1).
Il sistema operativo dell'host fisico potrebbe avere un firewall di rete. In questo caso, il firewall deve essere configurato per far passare 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 potrebbe fornire il proprio firewall sulla propria interfaccia eth0 e anche questi devono consentire la connessione del traffico delle porte 80 e 443.
Il percorso base è il terzo componente coinvolto nell'indirizzamento delle chiamate API a diversi proxy API
che potresti aver disegnato. I bundle di proxy API possono condividere un endpoint se hanno percorsi di base diversi. Ad esempio, un percorso 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 qualche tipo di direttore del traffico che divida il traffico http://api.mycompany.com:80/ tra i due indirizzi IP (111.111.111.111
sulla VM1 e 111.111.111.222
sulla VM2). Questa funzione è specifica per la tua installazione e viene configurata dal tuo gruppo di networking locale.
Il percorso base viene impostato quando esegui il deployment di un'API. Dall'esempio precedente, puoi implementare 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 arrivo.
Tuttavia, se esegui il deployment dell'API testmycompany
con l'URL di base di
/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 puoi ottenere da Apigee. Dovrai fornire il percorso del file della licenza durante l'installazione del server di gestione, ad esempio /tmp/license.txt.
Il programma di installazione copia il file di licenza in
/opt/apigee/customer/conf/license.txt
.
Se il file della licenza è valido, il server di gestione convalida la scadenza e il numero di elaboratori 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.