Requisiti di installazione

Edge per il cloud privato v. 4.17.01

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura ad alta disponibilità in un ambiente di livello enterprise. Per tutti gli scenari di installazione descritti in Topologie di installazione, nelle seguenti tabelle sono elencati 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 per l'installazione

RAM

CPU

Minimo disco rigido

Cassandra

16 GB

8 core

250 GB di spazio di archiviazione locale con SSD o HDD veloce con supporto di 2000 IOPS

Processore/router dei messaggi sulla stessa macchina

8/16GB

4 core

100GB

Analytics: Postgres/Qpid sullo stesso server (sconsigliato per la produzione)

16GB*

8 core*

500 GB - 1 TB** di spazio di archiviazione di rete***, preferibilmente con backend SSD, con supporto di 1000 IOPS o superiore*.

Analytics - Postgres autonomo

16GB*

8 core*

500 GB - 1 TB** di spazio di archiviazione di rete***, preferibilmente con backend SSD, con almeno 1000 IOPS.*

Analytics - Qpid autonomo

8 GB

4 core

30 GB - 50 GB di spazio di archiviazione locale con SSD o HDD veloce

Per installazioni superiori a 250 TPS, è consigliato un disco rigido con spazio di archiviazione locale che supporta 1000 IOPS.

La dimensione predefinita della coda Qpid è 20 GB. Se hai bisogno di aumentare la capacità, aggiungi nodi Qpid aggiuntivi.

Altro (OpenLDAP, UI, Management Server)

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 con velocità effettiva elevata. Puoi eseguire test delle prestazioni per determinare la dimensione ottimale delle tue API.

*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ù.
  • Superiore a 250 TPS: 16 GB, 8 core, spazio di archiviazione di rete gestito*** con supporto per 1000 IOPS o più
  • Superiore a 1000 TPS: 16 GB, 8 core, spazio di archiviazione di rete gestito*** con almeno 2000 IOPS
  • Superiore a 2000 TPS: 32 GB, spazio di archiviazione di rete gestito a 16 core*** che supporta almeno 2000 IOPS
  • Superiore a 4000 TPS: 64 GB, spazio di archiviazione di rete gestito a 32 core*** che supporta almeno 4000 IOPS

**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 valori devono essere aumentati di conseguenza. Utilizza la seguente formula per stimare lo spazio di archiviazione richiesto:

(# byte/richiesta) * (richieste al secondo) * (secondi all'ora) * (ore di utilizzo massimo al giorno) * (giorni al mese) * (mesi di conservazione dei dati) = byte di spazio di archiviazione necessario

Ad esempio:

(2000 byte di dati per richiesta) 36 giorni per il periodo di * 30 giorni in 30 giorni

*** Network Storage è consigliato per il database Postgresql perché:

  • Offre la possibilità di fare lo scale up dinamico delle dimensioni di archiviazione, se e quando necessario.
  • Le IOPS di rete possono essere regolate all'istante nella maggior parte dei sottosistemi dell'ambiente/di archiviazione/della rete.
  • Gli snapshot a livello di archiviazione possono essere abilitati nell'ambito di soluzioni di backup e ripristino.

Inoltre, di seguito sono elencati i requisiti hardware se vuoi installare i Servizi di monetizzazione:

Componente con la 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

500 GB - 1 TB di spazio di archiviazione di rete, preferibilmente con backend SSD, supporta 1000 IOPS o superiore oppure utilizza la regola della tabella precedente.

Analytics - Postgres autonomo

16 GB

8 core

500 GB - 1 TB di spazio di archiviazione di rete, preferibilmente con backend SSD, supporta 1000 IOPS o superiore oppure utilizza la regola della tabella precedente.

Analytics - Qpid autonomo

8 GB

4 core

40 GB - 500 GB di spazio di archiviazione locale con SSD o HDD veloce
Per installazioni superiori a 250 TPS, è consigliato un disco rigido con spazio di archiviazione locale che supporta 1000 IOPS.

Di seguito sono elencati i requisiti hardware se vuoi installare l'API BaaS:

Componente API BaaS

RAM

CPU

Disco rigido

Ricerca elastica*

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 utilizzi lo stesso cluster Cassandra per i servizi BaaS perimetrali e API)

16 GB

8 core

250 GB di spazio di archiviazione locale con SSD o HDD veloce con supporto di 2000 IOPS

* Puoi installare ElasticSearch e l'API BaaS Stack sullo stesso nodo. In caso affermativo, configura ElasticSearch in modo che utilizzi 4 GB di memoria (opzione predefinita). Se ElasticSearch è installato su un proprio nodo, configuralo in modo che utilizzi 6 GB di memoria.

Nota:

  • Se il file system radice non è abbastanza grande per l'installazione, è consigliabile posizionare i dati su un disco più grande.
  • Se sul computer è stata installata una versione precedente di Apigee Edge for Private Cloud, assicurati di eliminare la cartella /tmp/java prima di una nuova installazione.
  • La cartella temporanea a livello di sistema /tmp richiede l'esecuzione delle autorizzazioni per poter avviare Cassandra.
  • Se l'utente "Apigee" è stato creato prima dell'installazione, assicurati che "/home/apigee" esista come home directory e appartenga a "Apigee:Apigee".

Requisiti dei sistemi operativi e dei 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 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 appartengono a Apigee, così come i processi perimetrali. Ciò significa che i componenti perimetrali vengono eseguiti come utenti "Apigee". Se necessario, puoi eseguire i componenti come utente diverso. Per un esempio, consulta "Associazione del router a una porta protetta" in Installare i componenti di 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 questa posizione della directory. Anche se non puoi modificare questa directory, puoi creare un collegamento simbolico per mappare /opt/apigee a un'altra località, come descritto di seguito.

Nelle istruzioni di questa guida, la directory di installazione è indicata come /<inst_root>/apigee, dove /<inst_root> è /opt per impostazione predefinita.

Creazione di un symlink da /opt/apigee

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

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

  1. 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
  2. Crea un symlink da /opt/apigee alla radice di installazione desiderata:
    > ln -Ts /srv/myInstallDir /opt/apigee
    dove /srv/myInstallDir è la posizione desiderata dei file perimetrali.
  3. Cambia la proprietà della radice di installazione e del collegamento simbolico all'utente "Apigee":
    > chown -h apigee:Apigee /srv/myInstallDir /opt/apigee

Java

È necessario che su ogni macchina sia installata una versione supportata di Java1.8 prima dell'installazione. I JDK supportati sono elencati qui:

https://apigee.com/docs/api-services/reference/supported-software

Assicurati che JAVA_HOME punti alla radice del JDK per l'utente che esegue l'installazione.

SELinux

A seconda delle impostazioni per SELinux, Edge potrebbe riscontrare problemi con l'installazione e l'avvio dei componenti Edge. Se necessario, puoi disattivare SELinux o impostare la modalità permissiva durante l'installazione, quindi riattivarla dopo l'installazione. Per saperne di più, consulta Installare l'utilità di configurazione perimetrale di Apigee.

Impostazione di rete

Ti consigliamo di controllare l'impostazione della rete prima dell'installazione. Il programma di installazione prevede che tutti gli indirizzi IP siano fissi. Utilizza i comandi seguenti per convalidare l'impostazione:

  • nomehost 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.

Wrapper TCP

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

iptables

Verifica che non esistano criteri iptables che impediscano 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

Su CentOS 7.x:

> systemctl stop firewalld

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

Il router perimetrale e i nodi del portale BaaS utilizzano il router Nginx e richiedono l'accesso in lettura a /etc/rc.d/init.d/functions.

Se il tuo processo di sicurezza richiede l'impostazione delle autorizzazioni su /etc/rc.d/init.d/functions, non impostarle su 700, altrimenti il router non verrà avviato. 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 collegati a un anello. Cassandra archivia le repliche dei dati su più nodi per garantire affidabilità e tolleranza agli errori. La strategia di replica per ogni spazio chiave Key Edge determina i nodi Cassandra in cui vengono posizionate le repliche. Per ulteriori informazioni,consulta la pagina Informazioni sul fattore di replica Cassandra e sul livello di coerenza.

Cassandra regola automaticamente le sue dimensioni heap Java in base alla memoria disponibile. Per ulteriori informazioni, consulta la pagina Ottimizzare le risorse Java. In caso di peggioramento delle prestazioni o consumo elevato di memoria.

Dopo aver installato Edge per il cloud privato, puoi controllare che Cassandra sia configurato correttamente esaminando il file /inin__root>/apigee/apigee-cassandra/conf/cassandra.yaml. Ad esempio, assicurati che lo script di installazione di Edge per il cloud privato imposti le seguenti proprietà:

  • nome_cluster
  • token_iniziale
  • partizionamento
  • sementi
  • listen_address
  • indirizzo_rpc
  • Bocchetta

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 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:

  1. Modifica postgresql.properties:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    Se il file non esiste, crealo.
  2. Imposta le proprietà elencate sopra.
  3. Salva le modifiche.
  4. Riavvia il database PostgreSQL:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service Apigee.postgresql

Limiti del sistema

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

  • Sui nodi Cassandra, imposta limiti soft e hard memlock, nofile e indirizzi (come) limiti per l'utente dell'installazione (il valore predefinito è "Apigee") in /etc/security/limits.d/90-apigee-edge-limits.conf come mostrato di seguito:
    Apigee soft memlock illimitato
    Apigee hard memlock Unlimited
    3Soft 7266
    32768
    3dur

  • Sui nodi dell'elaboratore di messaggi, imposta il numero massimo di descrittori di file aperti su 64.000 in /etc/security/limits.d/90-apigee-edge-limits.conf come mostrato di seguito:
    Apigee soft nofile 32768
    Apigee Apigee nofile 65536


    Se necessario, puoi aumentare questo limite. ad esempio se hai un numero elevato di file temporanei aperti in qualsiasi momento.

jsvc

"jsvc" è un prerequisito per l'utilizzo dell'API BaaS. La versione 1.0.15-dev viene installata quando si installa l'API BaaS.

Servizi di sicurezza di rete (NSS)

NSS (Network Security Services) è un insieme di librerie che supporta lo sviluppo di applicazioni client e server abilitate per la sicurezza. Assicurati di aver installato NSS 3.19 o versioni successive.

Per controllare la versione corrente:

> yum info nss

Per aggiornare NSS:

> yum update nss

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

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

Se hai installato e abilitato NSCD (Name Service Cache Daemon), i processori di messaggi effettuano 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:

  1. Su ogni nodo dell'elaboratore di messaggi, modifica /etc/nscd.conf
  2. Imposta la seguente proprietà:
    enable-cache hosts no

Disabilita IPv6 su Google Cloud Platform per RedHat/CentOS 7

se installi Edge su RedHat 7 o CentOS 7 su Google Cloud Platform, devi disabilitare IPv6 su tutti i nodi Qpid.

Consulta la documentazione di RedHat o CentOS per la tua versione specifica del sistema operativo per istruzioni sulla disabilitazione del IPv6.

AWS AMI

Se installi Edge su un'immagine AWS Amazon Machine (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, come fornito da EL5 o EL6.

awk

expr

lua-presa

rpm

decomprimi

nomedibase

GRP

ls

rpm2cpio

aggiungiutente

bash

nome host

strumenti-net

sed

wc

bc

id

perl (da props)

Sudo

Wget

curl

Libaio

pgrep (da procps)

catrame

xerces-c

Cyrus-Sasl
libdb-cxx
ps tr slurp

date

libibverb

pwd

uid

kkconfig

dirname
librdmacm
python uname
echo
libxxxxt

Nota:

  • L'eseguibile per lo strumento "useradd" si trova in /usr/sbin e per chkconfig in /sbin.
  • Grazie all'accesso sudo puoi accedere all'ambiente dell'utente che chiama, ad esempio, di solito si chiama "sudo <command>" oppure "sudo PATH=$PATH:/usr/sbin:/sbin <comando>".
  • Assicurati di aver installato lo strumento "patch" prima dell'installazione di un service pack (patch).

ntpdate: consigliamo di sincronizzare i server. Se non è già configurata, l'utilità "ntpdate" può servire a questo scopo, il che verifica se i server sono sincronizzati in base all'ora. Puoi utilizzare "yum install ntp" per installare l'utilità. Ciò è particolarmente utile per replicare le configurazioni OpenLDAP. Tieni presente che devi impostare il fuso orario del server nel fuso orario UTC.

openldap 2.4: l'installazione on-premise richiede OpenLDAP 2.4. Se il tuo server dispone di una connessione a Internet, lo script di installazione perimetrale scarica e installa OpenLDAP. Se il server non ha 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 l'OpenLDAP.

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

Firewall e host virtuali

Il termine "virtuale" viene comunemente sovraccaricato nell'arena IT, quindi lo è con un deployment Apigee Edge per il cloud privato e gli host virtuali. Per chiarire, ci sono due usi principali del termine "virtuale":

  • Macchine virtuali (VM): non richiesto, 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, analogamente 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 esponga un'interfaccia Ethernet virtuale, che ha il nome eth0 all'interno della VM, a cui viene assegnato l'indirizzo IP 111.111.111.111 da parte della macchina virtuale1 e un server DH11.

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 nella VM 1 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 (lo stesso nome e la stessa porta indicata da VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete; in tal caso, questo firewall deve essere configurato per passare il traffico TCP legato 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 80 e 443 alle porte.

Il percorso base è il terzo componente coinvolto nel routing delle chiamate API a diversi proxy API di cui potresti aver eseguito il deployment. I pacchetti di proxy API possono condividere un endpoint se hanno percorsi 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 direttore di traffico 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 la tua installazione specifica ed è configurata dal gruppo di rete locale.

Il percorso base è 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 con 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 della tua API mycompany con l'URL di base /, i tuoi utenti accedono all'API dall'URL http://api.mycompany.com:80/.

Requisiti della porta perimetrale

La necessità di gestire il firewall va oltre i soli host virtuali; sia i firewall delle VM che quelli dell'host fisico devono consentire il traffico verso le porte richieste dai componenti per comunicare tra loro.

L'immagine seguente mostra i requisiti per le porte di ogni componente perimetrale:

Note su questo diagramma:

  • *La porta 8082 sul gestore di messaggi deve essere aperta per l'accesso solo da parte del router 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 gestore di messaggi per gestire il componente, ma il router non ne richiede l'accesso.
  • Le porte con il prefisso "M" sono le porte utilizzate per gestire il componente e devono essere aperte sul componente per l'accesso da parte del server di gestione.
  • I seguenti componenti richiedono l'accesso alla porta 8080 sul server di gestione: Router, Processore messaggi, UI, Postgres e Qpid.
  • Un elaboratore dei messaggi deve aprire la porta 4528 come porta di gestione. Se hai più elaboratori di messaggi, devono poter accedere tra loro tramite la porta 4528 (come indicato dalla freccia a loop nel diagramma sopra per la porta 4528 sul processore di messaggi). Se disponi di più data center, la porta deve essere accessibile da tutti i processori di messaggi in tutti i data center.
  • Sebbene non sia obbligatorio, puoi aprire la porta 4527 sul router per accedervi da qualsiasi processore di messaggi. In caso contrario, potresti visualizzare dei messaggi di errore nei file di log dell'Elaboratore messaggi.
  • Un router deve aprire la porta 4527 come porta di gestione. Se hai più router, devono essere tutti in grado di accedere l'uno all'altro tramite la porta 4527 (indicata dalla freccia di loop nel diagramma sopra per la porta 4527 sul router).
  • La UI perimetrale 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/la password. Per saperne di più, consulta Come monitorare.
  • Facoltativamente, puoi configurare l'accesso TLS/SSL per determinate connessioni, che possono utilizzare porte diverse. Per ulteriori informazioni, consulta TLS/SSL.
  • Se configuri due nodi Postgres per l'uso della replica standby principale, 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 l'interfaccia utente perimetrale in modo da inviare email tramite un server SMTP esterno. In questo caso, devi assicurarti che il server di gestione e l'UI possano accedere alla porta necessaria sul server SMTP. Per SMTP non TLS, il numero di porta è solitamente 25. Spesso il protocollo SMTP abilitato per TLS è 465, ma rivolgiti al tuo provider SMTP.

La tabella seguente mostra le porte che devono essere aperte nei firewall in base al componente Edge:

Componente

Porta

Description (Descrizione)

Porte HTTP standard

80.443

HTTP più eventuali 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 la cache distribuita e le chiamate di gestione

UI di gestione

9000

Porta per l'accesso del browser alla UI di gestione

Elaboratore messaggi

8998

Porta dell'elaboratore dei messaggi per le comunicazioni dal router

8082

Porta di gestione predefinita per l'elaboratore di messaggi e deve essere aperta sul componente per l'accesso da parte del server di gestione.

Se configuri TLS/SSL tra il router e l'elaboratore di messaggi, utilizzato dal router per effettuare controlli di integrità sull'elaboratore dei messaggi.

1101

Porta JMX

4528

Per la cache distribuita e le chiamate di gestione tra i 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 la cache distribuita e le chiamate di gestione

15999

Porta 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 effettua 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.

59001

Porta utilizzata per testare l'installazione di Edge dall'utilità apigee-validate. Questa utilità richiede l'accesso alla porta 59001 sul router. Per ulteriori informazioni sulla porta 59001, vedi Verificare l'installazione.

ZooKeeper

2181

Utilizzato da altri componenti come server di gestione, router, processore di messaggi e così via

2888, 3888

Utilizzata internamente dalla comunicazione ZooKeeper per il cluster ZooKeeper (noto come ensemble ZooKeeper)

Cassandra

7000, 9042, 9160

Porte Apache Cassandra per la comunicazione tra nodi nodo Cassandra e per l'accesso da parte di altri componenti Edge.

7199

Porta JMX. Deve essere aperto per l'accesso da parte del server di gestione.

Qpid

5672

Utilizzato per le comunicazioni dal router e dall'elaboratore di messaggi al server Qpid

8083

Porta di gestione predefinita sul server Qpid e deve essere aperta sul componente per l'accesso da parte del server di gestione.

1102

Porta JMX

4529

Per la cache distribuita e le chiamate di gestione

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 la cache distribuita e le chiamate di gestione

22

Se configuri due nodi Postgres per l'utilizzo della replica master-standby, devi aprire la porta 22 su ciascun nodo per l'accesso SSH.

LDAP

10389

OpenLDAP

Documenti intelligenti

59002

La porta sul router periferico a cui vengono inviate le richieste di pagina SmartDocumenti.

La tabella successiva mostra le stesse porte, elencate numericamente, con i componenti di origine e di destinazione:

Numero porta

Scopo

Componente di origine

Componente Destinazione

<porta host virtuale#>

HTTP più eventuali altre porte utilizzate per il traffico delle chiamate API dell'host virtuale. Le porte 80 e 443 sono le più comunemente 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)

Elaboratore messaggi (1101)

Server Qpid (1102)

Server Postgres (1103)

2181

Comunicazione con il cliente Zookeeper

Server di gestione

Router

processore di messaggi

Server Qpid

Server Postgres

Zookeeper

2888 e 3888

Gestione internode del guardiano dello zoo

Zookeeper

Zookeeper

4526

Porta di gestione RPC

Server di gestione

Server di gestione

4527 Porta di gestione RPC per le chiamate distribuite e di gestione della cache e per le comunicazioni tra i router

Server di gestione

Router

Router

4528

Per chiamate alla cache distribuite tra elaboratori dei messaggi e per la comunicazione dal router

Server di gestione

Router

processore di messaggi

processore di messaggi

4529 Porta RPC Management per cache distribuita e chiamate di gestione Server di gestione Server Qpid
4530 Porta RPC Management per cache distribuita e chiamate di gestione Server di gestione Server Postgres

5432

Client Postgres

Server Qpid

Postgres

5672

Utilizzato per l'invio di analisi dal router e dall'elaboratore di messaggi a Qpid

Router

processore di messaggi

Server Qpid

7000

Comunicazioni tra nodi Cassandra

Cassandra

Altro nodo Cassandra

7199

Gestione JMX. Deve essere aperto per l'accesso sul nodo Cassandra da parte del server di gestione.

Client JMX

Cassandra

8080

Porta dell'API di gestione

Client API di gestione

Server di gestione

8081-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 per l'accesso da parte del server di gestione

Client API di gestione

Router (8081)

Elaboratore messaggi (8082)

Server Qpid (8083)

Server Postgres (8084)

8998

Comunicazione tra router e processore di messaggi

Router

processore di messaggi

9000

Porta dell'interfaccia utente di gestione perimetrale predefinita

Browser

Server UI di gestione

0902

Trasporto nativo CQL

Router

processore di messaggi

Server di gestione

Cassandra

118

Client dell'usato Cassandra

Router

processore di messaggi

Server di gestione

Cassandra

10.389

Porta LDAP

Server di gestione

OpenLDAP

15.999

Porta controllo di integrità. Un bilanciatore del carico utilizza questa porta per determinare se il router è disponibile.

Bilanciatore del carico Router
59.001 Porta utilizzata dall'utilità apigee-validate per testare l'installazione di Edge Convalida convalida Router

59.002

La porta del router a cui vengono inviate le richieste di pagina SmartDocumenti

Documenti intelligenti

Router

Un processore di messaggi mantiene un pool di connessioni dedicato aperto a Cassandra, configurato per il timeout. Quando un firewall si trova tra un processore di messaggi e un server Cassandra, può scadere la 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 tra il router e i processori di messaggi è configurato un firewall e il timeout è impostato su TCP inattivo, ti consigliamo di:

  1. Imposta net.ipv4.tcp_keepalive_time = 1800 nelle impostazioni sysctl sul sistema operativo Linux, dove 1800 deve essere inferiore al timeout tcp del firewall in caso di inattività. Questa impostazione dovrebbe mantenere la connessione in uno stato stabilito in modo che il firewall non disconnetta la connessione.
  2. Su 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_cassandra.maxconnecttimeinins=-1
  3. Riavvia il processore di messaggio:
    > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. 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_cassandra.maxconnecttimeinins=-1
  5. Riavvia il router:
    > /opt/apigee/apigee-service/bin/apigee-service edge-router

Se installi la configurazione in cluster di 12 host con due data center, assicurati che i nodi nei due data center possano comunicare sulle porte mostrate di seguito:

Requisiti della porta API BaaS

Se scegli di installare l'API BaaS, aggiungi i componenti API BaaS Stack e API BaaS Portal. Questi componenti utilizzano le porte mostrate nella figura seguente:

Note su questo diagramma:

  • Il portale BaaS dell'API non effettua mai richieste direttamente a un nodo dello stack BaaS. Quando uno sviluppatore accede al Portale, l'app Portal viene scaricata nel browser. L'app Portal in esecuzione nel browser effettua quindi richieste ai nodi BaaS Stack.
  • Un'installazione in produzione di API BaaS utilizza un bilanciatore del carico tra il nodo portale API BaaS e i nodi di stack BaaS API. Quando configuri il portale e quando effettui chiamate API BaaS, devi specificare l'indirizzo IP o il nome DNS del bilanciatore del carico, non dei nodi dello stack.
  • Tutti i nodi dello stack devono aprire la porta 2551 per l'accesso da tutti gli altri nodi dello stack (indicati dalla freccia del loop nel diagramma sopra per la porta 2551 sui nodi dello stack). Se disponi di più data center, la porta deve essere accessibile da tutti i nodi dello stack in tutti i data center.
  • Devi configurare tutti i nodi Baas Stack per inviare email tramite un server SMTP esterno. Per SMTP non TLS, il numero della porta è solitamente 25. Spesso il protocollo SMTP abilitato per TLS è 465, ma contatta il tuo provider SMTP.
  • I nodi Cassandra possono essere dedicati all'API BaaS oppure possono essere condivisi con Edge.

La tabella seguente mostra le porte predefinite che devono essere aperte nei firewall in base al componente:

Componente

Porta

Description (Descrizione)

Portale API BaaS

9000

Porta per l'UI BaaS dell'API

Stack BaaS API

8080

Porta in cui viene ricevuta la richiesta API

2551

Porta per la comunicazione tra tutti i nodi dello stack. Devono essere accessibili da tutti gli altri nodi Stack nel parametro di aggiornamento dei dati.

Se disponi di più data center, la porta deve essere accessibile da tutti i nodi dello stack in tutti i data center.

ElasticSearch

9200-9400

Per la comunicazione con l'API BaaS Stack e per la comunicazione tra nodi ElasticSearch

Concessione delle licenze

Ogni installazione di Edge richiede un file di licenza univoco che ottieni da Apigee. Dovrai fornire il percorso al file della licenza quando installi il server di gestione, ad esempio /tmp/license.txt.

Il programma di installazione copia il file della licenza in /<inst_root>/apigee/customer/conf/licenses.txt.

Se il file della licenza è valido, il server di gestione convalida la data di scadenza e quella consentita per il processore di messaggi (MP). Se una delle impostazioni di licenza è scaduta, puoi trovare i log nel seguente percorso: /<inst_root>/apigee/var/log/edge-management-server/logs. In questo caso puoi contattare l'assistenza Apigee per i dettagli della migrazione.

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