Edge per Private Cloud v. 4.16.05
Requisiti hardware
Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura ad alta disponibilità in un ambiente di produzione. 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 rispetto a quelle elencate di seguito.
Componente di installazione |
RAM |
CPU |
Numero minimo di disco rigido |
---|---|---|---|
Cassandra |
16 GB |
8 core |
250 GB di spazio di archiviazione locale con SSD o HDD veloce che supporta 2000 IOPS |
Processore/router di messaggi sullo stesso computer |
8/16GB |
4 core† |
100GB |
Analytics - Postgres/Qpid sullo stesso server (non consigliato per la produzione) |
16GB* |
8 core* |
Spazio di archiviazione di rete da 500 GB a 1 TB**, preferibilmente con backend SSD, con supporto di almeno 1000 IOPS*. |
Analytics - Postgres autonomo |
16GB* |
8 core* |
Spazio di archiviazione di rete da 500 GB a 1 TB**, preferibilmente con backend SSD, con supporto di almeno 1000 IOPS*. |
Analytics - Qpid autonomo |
8 GB |
4 core |
Spazio di archiviazione locale da 30 GB a 50 GB con SSD o HDD veloce Per installazioni superiori a 250 TPS, si consiglia un disco rigido con spazio di archiviazione locale che supporta 1000 IOPS. |
Altro (OpenLDAP, UI, server di gestione) |
4 GB |
2 core |
60 GB |
† Regola i requisiti di sistema del processore di messaggi in base alla velocità effettiva: Il valore minimo consigliato è 4 core e 8 core per un sistema a velocità effettiva elevata. Puoi eseguire test delle prestazioni per determinare la dimensione ottimale per le tue API. |
|||
*Regola i requisiti di sistema di Postgres in base alla velocità effettiva:
|
|||
**Il valore del disco rigido Postgres si basa sull'analisi pronta all'uso acquisita da Edge. Se aggiungi valori personalizzati ai dati di analisi, questi devono essere aumentati di conseguenza. Utilizza la seguente formula per stimare lo spazio di archiviazione richiesto: |
|||
*** L'archiviazione di rete è consigliata per il database Postgresql perché:
|
Inoltre, di seguito sono elencati i requisiti hardware se vuoi installare i Servizi di monetizzazione:
Componente con monetizzazione |
RAM |
CPU |
Disco rigido |
---|---|---|---|
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, con supporto di almeno 1000 IOPS oppure utilizza la regola della tabella precedente. |
Analytics - Postgres autonomo |
16 GB |
8 core |
Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, con supporto di almeno 1000 IOPS oppure utilizza la regola della tabella precedente. |
Analytics - Qpid autonomo |
8 GB |
4 core |
40GB |
Di seguito sono elencati i requisiti hardware per installare l'API BaaS:
Componente API BaaS |
RAM |
CPU |
Disco rigido |
---|---|---|---|
ElasticSearch* |
8 GB |
4 core |
60 - 80GB |
Stack BaaS API * |
8 GB |
4 core |
60 - 80GB |
Portale API BaaS |
1 GB |
2 core |
20GB |
Cassandra (facoltativo: in genere si utilizza lo stesso cluster Cassandra sia per i servizi BaaS Edge che API) |
16 GB |
8 core |
250 GB di spazio di archiviazione locale con SSD o HDD veloce che supporta 2000 IOPS |
* Puoi installare ElasticSearch e API BaaS Stack sullo stesso nodo. In tal caso, configura ElasticSearch in modo da utilizzare 4 GB di memoria (impostazione predefinita). Se ElasticSearch è installato sul proprio nodo, configuralo in modo che utilizzi 6 GB di memoria. |
Nota:
- Se il file system radice non è abbastanza grande per l'installazione, ti consigliamo di posizionare i dati su un disco più grande.
- Se sulla macchina è stata installata una versione precedente di Apigee Edge per Cloud privato, assicurati di eliminare la cartella /tmp/java prima di una nuova installazione.
- La cartella temporanea a livello di sistema /tmp richiede le autorizzazioni di esecuzione per poter avviare Cassandra.
- Se l'utente "apigee" è stato creato prima dell'installazione, assicurati che "/home/apigee" esista come home directory e sia di proprietà di "apigee:apigee".
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 sui software di terze parti elencati qui: https://apigee.com/docs/api-services/reference/supported-software.
Creazione dell'utente Apigee
La procedura di installazione crea un utente di sistema Unix denominato 'apigee'. Le directory e i file perimetrali 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. Per un esempio, vedi "Associazione del router a una porta protetta" in Installare i componenti Edge su un nodo.
Directory di installazione
Per impostazione predefinita, il programma di installazione scrive tutti i file nella directory /opt/apigee. Non puoi modificare la posizione della directory.
Nelle istruzioni di questa guida, la directory di installazione è indicata come /<inst_root>/apigee, dove /<inst_root> è /opt per impostazione predefinita.
Java
È necessario che su ogni macchina sia installata una versione supportata di Java 1.8 prima dell'installazione. I JDK supportati sono elencati qui:
https://apigee.com/docs/api-services/reference/supported-software
Assicurati che JAVA_HOME rimandi alla radice del JDK per l'utente che esegue l'installazione.
Impostazione di rete
Ti consigliamo di verificare le impostazioni di rete prima di eseguire l'installazione. Il programma di installazione prevede che tutte le macchine abbiano indirizzi IP fissi. Utilizza i seguenti comandi per convalidare l'impostazione:
- nomehost restituisce il nome della macchina
- nome host -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 ulteriori informazioni, consulta la documentazione del tuo sistema operativo specifico.
Cassandra
Tutti i nodi Cassandra devono essere connessi a un anello.
Cassandra regola automaticamente le dimensioni dello heap Java in base alla memoria disponibile. Per ulteriori informazioni, consulta la sezione Ottimizzazione delle risorse Java. In caso di peggioramento delle prestazioni o di un consumo elevato di memoria.
Dopo aver installato Edge per il cloud privato, puoi verificare che Cassandra sia configurato correttamente esaminando il file /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. Ad esempio, assicurati che lo script di installazione di Edge per cloud privato imposti le seguenti proprietà:
- cluster_name
- initial_token
- partizionatore
- semi
- listen_address
- rpc_address
- spia
Avviso: non modificare questo file.
Database PostgreSQL
Dopo aver installato Edge, puoi modificare le seguenti impostazioni del database PostgreSQL in base alla quantità di RAM disponibile nel 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 postgresql.properties:
> vi /<inst_root>/apigee/customer/application/postgresql.properties
Se il file non esiste, crealo. - Imposta le proprietà elencate sopra.
- Salva le modifiche.
- Riavvia il database PostgreSQL:
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql spiega
jsvc
"jsvc" è un prerequisito per l'utilizzo dell'API BaaS. La versione 1.0.15-dev viene installata quando installi l'API BaaS.
Servizi di sicurezza di rete (NSS)
I servizi di sicurezza di rete (NSS) sono un insieme di librerie che supporta lo sviluppo di applicazioni client e server abilitate per la sicurezza. Devi assicurarti di aver installato NSS 3.19 o versioni successive.
Per controllare la tua versione corrente:
> yum info nss
Per aggiornare NSS:
> yum update nss
Per ulteriori informazioni, consulta questo articolo di RedHat.
AWS AMI
Se stai installando Edge su AWS Amazon Machine Image (AMI) per Red Hat Enterprise Linux 7.x, devi prima eseguire il comando seguente:
> 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 |
dirname |
ls |
rpm |
unzip |
basename |
echo |
perl |
rpm2cpio |
aggiunta utente |
bash |
expr |
pgrep (da procps) |
sed |
wc |
bc |
grep |
ps |
catrame |
slurp |
curl |
nome host |
pwd |
tr |
chkconfig |
date |
id |
python |
Uname |
sudo |
Nota:
- L'eseguibile per lo strumento "useradd" si trova in /usr/sbin e per chkconfig in /sbin.
- Con l'accesso sudo puoi ottenere l'accesso all'ambiente dell'utente chiamante. Ad esempio, di solito chiami "sudo <comando>" o "sudo PATH=$PATH:/usr/sbin:/sbin <comando>".
- Assicurati di aver installato lo strumento "patch" prima dell'installazione del service pack (patch).
ntpdate: è consigliabile sincronizzare l'ora dei server. Se non è già configurata, l'utilità "ntpdate" potrebbe servire a questo scopo, che verifica se i server sono sincronizzati in base all'ora. 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 in 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 Edge scarica e installa OpenLDAP. Se il server non dispone di una connessione a internet, devi assicurarti che OpenLDAP sia già installato prima di eseguire lo script di installazione Edge. Su RHEL/CentOS puoi eseguire "yum install openldap-clients openldap-servers" per installare OpenLDAP.
Per le installazioni da 13 host e da 12 host con due data center, è necessaria la replica OpenLDAP perché sono presenti più nodi che ospitano OpenLDAP.
Firewall e host virtuali
Il termine "virtuale" solitamente è sovraccarico nell'ambiente IT, così è con un Apigee Edge per il deployment di cloud privato e host virtuali. Per chiarire, il termine "virtuale" viene utilizzato principalmente in due modi:
- Macchine virtuali (VM): non sono richieste, ma alcuni deployment utilizzano la tecnologia VM per creare server isolati per i componenti Apigee. Gli host delle VM, come quelli fisici, possono avere interfacce di rete e firewall. Queste istruzioni di installazione non supportano nello specifico le installazioni delle VM.
- Host virtuali: endpoint web, analoghi a un host virtuale Apache.
Un router in una VM può esporre più host virtuali (a condizione che siano diversi l'uno dall'altro nell'alias host o nella porta dell'interfaccia).
Come esempio di denominazione, un singolo server fisico "A" potrebbe eseguire due VM, denominate "VM1" e "VM2". Supponiamo che VM1 mostri un'interfaccia Ethernet virtuale, che viene denominata eth0 all'interno della VM e a cui viene assegnato l'indirizzo IP 111.111.111.111 dalla macchina di virtualizzazione o da un'interfaccia Ethernet1.2 DHCP riceve anche un server IP1.2 denominato eth1.1.2
Potremmo avere un router Apigee in esecuzione in ciascuna delle due VM. I router espongono gli endpoint host virtuali come in questo esempio ipotetico:
Il router Apigee in VM1 espone tre host virtuali sulla sua interfaccia eth0 (che ha un determinato indirizzo IP), api.mycompany.com:80, api.mycompany.com:443 e test.mycompany.com:80.
Il router in VM2 espone api.mycompany.com:80 (lo stesso nome e la stessa porta esposti da VM1).
Il sistema operativo dell'host fisico potrebbe avere un firewall di rete; in questo caso, quel firewall deve essere configurato in modo da passare il traffico TCP associato alle porte esposte sulle interfacce virtualizzate (111.111.111.111:{80, 443} e 111.111.111.222:80). Inoltre, il sistema operativo di ciascuna VM potrebbe fornire il proprio firewall sull'interfaccia eth0 che deve consentire il traffico delle porte 80 e 443.
Il percorso base è il terzo componente coinvolto nell'instradamento delle chiamate API a diversi proxy API di cui potresti aver eseguito il deployment. I bundle 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 definito come http://api.mycompany.com:80/salesdemo.
In questo caso, è necessario un bilanciatore del carico o un gestore del traffico di qualche tipo che divida 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 l'installazione specifica ed è configurata dal gruppo di networking locale.
Il percorso base viene impostato quando esegui il deployment di un'API. Dall'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 di 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/.
Requisiti delle porte perimetrali
La necessità di gestire il firewall va oltre gli host virtuali; sia i firewall host delle VM che quelli fisici devono consentire il traffico delle porte richieste dai componenti per comunicare tra loro.
L'immagine seguente mostra i requisiti delle porte per ogni componente Edge:
Note su questo diagramma:
-
*La porta 8082 sul processore di messaggi deve essere aperta per l'accesso dal router solo quando configuri TLS/SSL tra il router e il processore di messaggi. Se non configuri TLS/SSL tra il router e il processore di messaggi, la configurazione predefinita, la porta 8082 deve comunque essere aperta sul processore di messaggi per poter gestire il componente, ma il router non richiede l'accesso a quest'ultimo.
- Le porte con prefisso "M" sono quelle utilizzate per gestire il componente e devono essere aperte sul componente per consentire l'accesso al server di gestione.
- I seguenti componenti richiedono l'accesso alla porta 8080 sul server di gestione: router, processore di messaggi, UI, Postgres e Qpid.
- Un processore di messaggi deve aprire la porta 4528 come porta di gestione. Se disponi di più processori di messaggi, devono essere tutti in grado di accedere l'uno all'altro sulla porta 4528 (come indicato dalla freccia a loop nel diagramma sopra per la porta 4528 del processore di messaggi). Se disponi di più data center, la porta deve essere accessibile a tutti i responsabili del trattamento dei messaggi in tutti i data center.
- Sebbene non sia necessaria, puoi aprire la porta 4527 sul router per l'accesso da parte di qualsiasi processore di messaggi. In caso contrario, potresti visualizzare messaggi di errore nei file di log del processore di messaggi.
- Un router deve aprire la porta di gestione 4527. Se disponi di più router, tutti devono poter accedere l'uno all'altro sulla porta 4527 (come indicato dalla freccia a loop nel diagramma sopra per la porta 4527 del router).
- La UI Edge richiede l'accesso al router, sulle porte esposte dai proxy API, per supportare il pulsante Invia nello strumento di traccia.
- Il server di gestione richiede l'accesso alla porta JMX sui nodi Cassandra.
- L'accesso alle porte JMX può essere configurato in modo da richiedere un nome utente o una password. Per ulteriori informazioni, consulta la sezione Monitoraggio.
- Facoltativamente, puoi configurare l'accesso TLS/SSL per determinate connessioni, che possono utilizzare porte diverse. Per saperne di più, consulta TLS/SSL.
- Se configuri due nodi Postgres per l'utilizzo della replica in standby master, devi aprire la porta 22 su ciascun nodo per l'accesso SSH. Facoltativamente, puoi aprire le porte sui singoli nodi per consentire l'accesso SSH.
- Puoi configurare il server di gestione e la UI Edge per l'invio di email tramite un server SMTP esterno. In questo caso, devi assicurarti che il server di gestione e la UI possano accedere alla porta necessaria sul server SMTP. Per SMTP non TLS, il numero di porta è generalmente 25. Per SMTP abilitato per TLS, spesso è 465, ma verifica con il tuo provider SMTP.
La tabella seguente mostra le porte che devono essere aperte nei firewall dal componente Edge:
Componente |
Porta |
Descrizione |
---|---|---|
Porte HTTP standard |
80.443 |
HTTP più altre porte utilizzate per gli host virtuali |
Server di gestione |
8080 |
Porta per le chiamate API di gestione perimetrale. Questi componenti richiedono l'accesso alla porta 8080 sul server di gestione: router, processore di messaggi, UI, Postgres e Qpid. |
1099 |
Porta JMX |
|
4526 |
Per chiamate di gestione e cache distribuite |
|
UI di gestione |
9000 |
Porta per l'accesso del browser all'interfaccia utente di gestione |
Processore di messaggi |
8998 |
Porta del processore di messaggi per le comunicazioni dal router |
8082 |
La porta di gestione predefinita per il processore di messaggi; deve essere aperta sul componente per l'accesso da parte del server di gestione.
Se configuri TLS/SSL tra il router e il processore di messaggi, utilizzati dal router per eseguire controlli di integrità sul processore di messaggi.
|
|
1101 |
Porta JMX |
|
4528 |
Per la cache distribuita e le chiamate di gestione tra processori di messaggi e per la comunicazione dal router |
|
Router |
8081 |
Porta di gestione predefinita per il router e deve essere aperta sul componente per l'accesso da parte del server di gestione. |
4527 |
Per chiamate di gestione e cache distribuite |
|
15999 |
Porta per il controllo di integrità. Un bilanciatore del carico utilizza questa porta per determinare se il router è disponibile. Per ottenere lo stato di un router, il bilanciatore del carico invia una richiesta alla porta 15999 sul router: > curl -v http://<routerIP>:15999/v1/servers/self/reachable Se il router è raggiungibile, la richiesta restituisce HTTP 200. |
|
ZooKeeper |
2181 |
Utilizzato da altri componenti come server di gestione, router, processore di messaggi e così via |
2888, 3888 |
Utilizzato internamente da ZooKeeper per la comunicazione del cluster ZooKeeper (noto come ensemble ZooKeeper) |
|
Cassandra |
7000, 9042, 9160 |
Porte di Apache Cassandra per la comunicazione tra nodi Cassandra e per l'accesso da parte di altri componenti Edge. |
7199 |
Porta JMX. Deve essere accessibile al server di gestione. |
|
Qpid |
5672 |
Utilizzato per le comunicazioni dal router e dal processore di messaggi al server Qpid |
8083 |
La porta di gestione predefinita sul server Qpid deve essere aperta sul componente per poter essere accessibile da parte del server di gestione. |
|
1102 |
Porta JMX |
|
4529 |
Per chiamate di gestione e cache distribuite |
|
Postgres |
5432 |
Utilizzato per la comunicazione da Qpid/Management Server a Postgres |
8084 |
La porta di gestione predefinita sul server Postgres. Deve essere aperta sul componente per l'accesso da parte del server di gestione. |
|
1103 |
Porta JMX |
|
4530 |
Per chiamate di gestione e cache distribuite |
|
22 |
Se configuri due nodi Postgres per l'utilizzo della replica in standby master, devi aprire la porta 22 su ciascun nodo per l'accesso SSH. |
|
LDAP |
10389 |
OpenLDAP |
SmartDocs |
59002 |
La porta sul router perimetrale a cui vengono inviate le richieste di pagine SmartDoc. |
Nota: inoltre, a scopo di test, potrebbe essere necessario aprire le porte nei firewall. ad esempio 59001 e così via. |
La tabella successiva mostra le stesse porte, elencate numericamente, con i componenti di origine e di destinazione:
Numero di porta |
Finalità |
Componente di origine |
Componente Destinazione |
---|---|---|---|
<porta host virtuale#> |
HTTP più qualsiasi altra porta utilizzata per il traffico delle chiamate API dell'host virtuale. Le porte 80 e 443 sono quelle più utilizzate; il router dei messaggi può terminare le connessioni TLS/SSL. |
Client esterno (o bilanciatore del carico) |
Listener sul router dei messaggi |
Da 1099 a 1103 |
Gestione JMX |
Client JMX |
Server di gestione (1099) Processore di messaggi (1101) Server Qpid (1102) Server Postgres (1103) |
2181 |
Comunicazione con il cliente di Zookeeper |
Server di gestione Router processore di messaggi Server Qpid Server Postgres |
Zookeeper |
2888 e 3888 |
Gestione degli internodi di Zookeeper |
Zookeeper |
Zookeeper |
Da 4526 a 4530 |
Porte di gestione RPC utilizzate per la cache distribuita e le chiamate dai server di gestione agli altri componenti |
Server di gestione |
Server di gestione (4526) Router (4527) Processore di messaggi (4528) Server Qpid (4529) Server Postgres (4530) |
4528 |
Per le chiamate alla cache distribuita tra i processori di messaggi e per la comunicazione dal router |
Router processore di messaggi |
processore di messaggi |
5432 |
Client Postgres |
Server Qpid |
Postgres |
5672 |
Utilizzato per l'invio di analisi dal router e dal processore di messaggi a Qpid |
Router processore di messaggi |
Server Qpid |
7000 |
Comunicazioni tra nodi Cassandra |
Cassandra |
Altro nodo Cassandra |
7199 |
Gestione JMX. Deve essere aperta per l'accesso al nodo Cassandra da parte del server di gestione. |
Client JMX |
Cassandra |
8080 |
Porta API di gestione |
Client API di gestione |
Server di gestione |
Da 8081 a 8084 |
Porte API dei componenti, utilizzate per inviare richieste API direttamente ai singoli componenti. Ogni componente apre una porta diversa. La porta esatta utilizzata dipende dalla configurazione, ma deve essere aperta sul componente affinché possa essere accessibile da parte del server di gestione |
Client API di gestione |
Router (8081) Processore di messaggi (8082) Server Qpid (8083) Server Postgres (8084) |
8998 |
Comunicazione tra router e processore di messaggi |
Router |
processore di messaggi |
9000 |
Porta UI di gestione perimetrale predefinita |
Browser |
Server UI di gestione |
01:00 |
Trasporto nativo CQL |
Router processore di messaggi Server di gestione |
Cassandra |
1280 |
Cliente di seconda mano Cassandra |
Router processore di messaggi Server di gestione |
Cassandra |
10.389 |
Porta LDAP |
Server di gestione |
OpenLDAP |
15.999 | Porta per il controllo di integrità. Un bilanciatore del carico utilizza questa porta per determinare se il router è disponibile. | Bilanciatore del carico | Router |
59002 |
La porta del router a cui vengono inviate le richieste di pagina SmartDocumenti |
SmartDocs |
Router |
Un processore di messaggi mantiene un pool di connessioni dedicato aperto per Cassandra, che è configurato per non fare mai timeout. Quando un firewall si trova tra un processore di messaggi e il server Cassandra, il firewall può causare il timeout della connessione. Tuttavia, il processore di messaggi non è progettato per ristabilire le connessioni a Cassandra.
Per evitare questa situazione, Apigee consiglia che il server, il processore di messaggi e i router Cassandra si trovino nella stessa subnet, in modo che non sia coinvolto un firewall nel deployment di questi componenti.
Se un firewall si trova tra il router e i processori di messaggi e ha impostato un timeout tcp inattivo, consigliamo di:
- Imposta net.ipv4.tcp_keepalive_time = 1800 nelle impostazioni sysctl sul sistema operativo Linux, dove 1800 deve essere inferiore al timeout tcp per inattività del firewall. Questa impostazione deve mantenere la connessione in uno stato stabilito in modo che il firewall non scolleghi la connessione.
- In tutti i processori di messaggi, modifica /<inst_root>/apigee/customer/application/message-processor.properties per aggiungere la seguente proprietà. Se il file non esiste, crealo.
conf_system_casssandra.maxconnecttimeinmillis=-1 - Riavvia il processore di messaggi:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor affidabile - Su tutti i router, modifica /<inst_root>/apigee/customer/application/router.properties
per aggiungere la seguente proprietà. Se il file non esiste, crealo.
conf_system_casssandra.maxconnecttimeinmillis=-1 - Riavvia il router:
> /opt/apigee/apigee-service/bin/apigee-service edge-router concern
Se installi la configurazione con cluster host a 12 data center, assicurati che i nodi nei due data center possano comunicare tramite le porte mostrate di seguito:
Requisiti per le porte BaaS dell'API
Se scegli di installare l'API BaaS, aggiungi i componenti Stack BaaS API e Portale API BaaS. Questi componenti utilizzano le porte mostrate nella figura seguente:
Note su questo diagramma:
- I nodi Cassandra possono essere dedicati all'API BaaS o condivisi con Edge.
- Un'installazione di produzione dell'API BaaS utilizza un bilanciatore del carico tra il nodo del portale API BaaS e i nodi dello stack BaaS dell'API. Durante la configurazione del portale e le chiamate API BaaS, devi specificare l'indirizzo IP o il nome DNS del bilanciatore del carico, non dei nodi dello stack.
- Devi configurare tutti i nodi Baas Stack per inviare email tramite un server SMTP esterno. Per SMTP non TLS, il numero di porta è in genere 25. Per SMTP abilitato per TLS, spesso è 465, ma verifica con il tuo provider SMTP.
La tabella seguente mostra le porte predefinite che devono essere aperte nei firewall, per componente:
Componente |
Porta |
Descrizione |
---|---|---|
Portale API BaaS |
9000 |
Porta per l'UI BaaS dell'API |
Stack BaaS delle API |
8080 |
Porta dove vengono ricevute le richieste API |
ElasticSearch |
Da 9200 a 9400 |
Per la comunicazione con API BaaS Stack e tra i nodi ElasticSearch |
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 della licenza in /<inst_root>/apigee/customer/conf/license.txt.
Se il file della licenza è valido, il server di gestione convalida la scadenza e il numero consentito del processore di messaggi (MP). Se una delle impostazioni della licenza è scaduta, puoi trovare i log nella seguente posizione: /<inst_root>/apigee/var/log/edge-management-server/logs. In questo caso puoi contattare l'assistenza Apigee per i dettagli sulla migrazione.