Requisiti di installazione

Edge per Private Cloud v. 4.16.05

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'alta disponibilità dell'infrastruttura in un ambiente di produzione. Per tutti gli scenari di installazione descritti in Topologie di installazione; le seguenti tabelle elencano Requisiti hardware minimi per i componenti dell'installazione.

In queste tabelle i requisiti del disco rigido si aggiungono allo spazio su disco rigido richiesto tipo e quantità di spazio di archiviazione necessari e sistema operativo. A seconda delle applicazioni e del traffico di rete, l'installazione potrebbe richiedono più o meno risorse rispetto a quelle elencate di seguito.

Componente di installazione

RAM

CPU

Dimensioni minime del 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 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 superiori*.

Analytics - Postgres autonomo

16GB*

8 core*

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

Analytics - Qpid autonomo

8 GB

4 core

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

Per installazioni con una potenza superiore a 250 TPS, è necessario utilizzare un disco rigido con spazio di archiviazione locale che supporta 1000 IOPS consigliato.

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 numero minimo consigliato è di 4 core e 8 core per un sistema a velocità effettiva elevata. Puoi eseguire test delle prestazioni per determinare la dimensione ottimale delle API.

*Regola i requisiti di sistema di Postgres in base alla velocità effettiva:

  • Meno di 250 TPS: 8 GB, quad-core possono essere presi in considerazione con l'archiviazione di rete gestita*** supportando 1000 IOPS o superiori
  • Più di 250 TPS: archiviazione di rete gestita a 8 core da 16 GB*** con supporto di 1000 IOPS o superiori
  • Più di 1000 TPS: archiviazione di rete gestita a 8 core da 16 GB*** con supporto di 2000 IOPS o superiori
  • Più di 2000 TPS: 32 GB, 16 core, spazio di archiviazione di rete gestito*** con supporto di 2000 IOPS o superiori
  • Più di 4000 TPS: archiviazione di rete gestita a 32 core da 64 GB*** che supporta 4000 IOPS o superiori

**Il valore del disco rigido Postgres si basa sull'analisi pronta all'uso acquisita dal perimetrali. Se aggiungi valori personalizzati ai dati di analisi, questi valori devono essere aumentati di conseguenza. Usa la seguente formula per stimare lo spazio di archiviazione richiesto:

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

Ad esempio:

(2.000 byte di dati analitici per richiesta) * 100 richieste/sec * 3600 secondi/ora * Picco di 18 ore utilizzo al giorno * 30 giorni/mese * 3 mesi di conservazione = 1.194.393.600.000 byte o 1194,4 GB.

*** L'archiviazione di rete è consigliata per il database Postgresql perché:

  • Consente di fare dinamicamente lo scale up delle dimensioni dello spazio di archiviazione se e quando obbligatorio.
  • Il numero di IOPS di rete può essere modificato in tempo reale nella maggior parte delle di ambiente/archiviazione/rete.
  • Gli snapshot a livello di archiviazione possono essere abilitati come parte del backup e ripristino soluzioni.

Di seguito sono inoltre elencati i requisiti hardware che consentono di installare Servizi di monetizzazione:

Componente con monetizzazione

RAM

CPU

Disco rigido

Server di gestione (con servizi di monetizzazione)

8 GB

4 core

60 GB

Analisi - Postgres/Qpid sullo stesso server

16 GB

8 core

500 GB - 1 TB di spazio di archiviazione di rete, preferibilmente con backend SSD, con supporto di 1000 IOPS o 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, con supporto di 1000 IOPS o utilizza la regola della tabella precedente.

Analytics - Qpid autonomo

8 GB

4 core

40GB

Di seguito sono elencati i requisiti hardware per installare API BaaS:

Componente API BaaS

RAM

CPU

Disco rigido

ElasticSearch*

8 GB

4 core

60 - 80GB

Stack API BaaS *

8 GB

4 core

60 - 80GB

Portale API BaaS

1 GB

2 core

20GB

Cassandra (facoltativo: in genere utilizzi lo stesso cluster Cassandra per entrambi i servizi Edge) e servizi BaaS delle 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. Se sì, configura ElasticSearch in modo che utilizzi 4 GB di memoria (impostazione predefinita). Se ElasticSearch è installato e configurare il proprio nodo in modo che utilizzi 6 GB di memoria.

Nota:

  • Se le dimensioni del file system radice non sono sufficientemente grandi per l'installazione, ti consigliamo di collocare i dati su un disco più grande.
  • Se sulla macchina è stata installata una versione precedente di Apigee Edge per il cloud privato, assicurati 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” esiste come home directory e fa parte di "apigee:apigee".

Sistema operativo e terze parti requisiti software

Queste istruzioni di installazione e i file di installazione forniti sono stati testati sulla sistemi operativi e 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 periferiche i file sono di proprietà di 'apigee', così come i processi Edge. Ciò significa che i componenti Edge vengono eseguiti 'apigee' utente. se necessario, puoi eseguire i componenti con un altro utente. Consulta la sezione "Associazione del router" a una porta protetta" in Installare i componenti Edge su un Node per un esempio.

Directory di installazione

Per impostazione predefinita, il programma di installazione scrive tutti i file nella directory /opt/apigee. Non puoi modificare questa impostazione percorso della directory.

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

Java

È necessaria una versione supportata di Java1.8 installata su ogni macchina 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.

Impostazione di rete

Ti consigliamo di controllare le impostazioni di rete prima dell'installazione. L'utente che ha eseguito l'installazione prevede che tutte le macchine abbiano indirizzi IP fissi. Utilizza i seguenti comandi per convalidare dell'impostazione:

  • nomehost restituisce il nome della macchina
  • nome host -i restituisce l'IP per il nome host a cui 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 è siano impostati correttamente. Per ulteriori informazioni, consulta la documentazione del sistema operativo in uso.

Cassandra

Tutti i nodi Cassandra devono essere connessi a un anello.

Cassandra regola automaticamente la dimensione dell'heap Java in base alla memoria disponibile. Per ulteriori informazioni, consulta Ottimizzazione di Java Google Cloud. in caso di peggioramento delle prestazioni o elevato consumo della memoria.

Dopo aver installato Edge per il cloud privato, puoi verificare che Cassandra sia configurato correttamente esaminando il file /&lt;inst_root&gt;/apigee/apigee-cassandra/conf/cassandra.yaml . Ad esempio, assicurati che lo script di installazione di Edge per il cloud privato imposti quanto segue proprietà:

  • cluster_name
  • initial_token
  • partizionatore
  • sementi
  • 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 al di RAM disponibile nel 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:
    &gt; vi /&lt;inst_root&gt;/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:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql riavvia

jsvc

"jsvc" è un prerequisito per l'utilizzo di API BaaS. La versione 1.0.15-dev viene installata al momento dell'installazione l'API BaaS.

Network Security Services (NSS)

Network Security Services (NSS) è un insieme di librerie che supporta lo sviluppo di con applicazioni client e server abilitate alla sicurezza. Devi assicurarti di aver installato NSS v3.19 o successive.

Per controllare la versione in uso:

> yum info nss

Per aggiornare NSS:

> yum update nss

Leggi questo articolo di RedHat per ulteriori informazioni.

AMI AWS

Se stai installando Edge su un'immagine AWS Amazon Machine Image (AMI) per Red Hat Enterprise Linux 7.x, devi prima eseguire questo 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

dirname

ls

rpm

decomprimere

nome base

echo

perl

rpm2cpio

aggiunta utente

bash

expr

pgrep (da procps)

sed

wc

bc

Grep

ps

catrame

Slurp

curl

nome host

pwd

tr

chkconfig

data

id

python

Uname

sudo

Nota:

  • L'eseguibile per lo strumento "useradd" si trova in /usr/sbin e per chkconfig in /sbin.
  • Con sudo access puoi ottenere l'accesso all'ambiente dell'utente chiamante, ad esempio di solito chiamerai "sudo <command>" o "sudo PATH=$PATH:/usr/sbin:/sbin <command>”.
  • Assicurati di avere installato lo strumento "patch" prima di un service pack (patch) dell'installazione.

ntpdate: è consigliabile che l'ora dei server sia sincronizzata. Se non ancora configurato, 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 utilità. Ciò è particolarmente utile per replicare le configurazioni OpenLDAP. Tieni presente che hai configurato il server fuso orario in UTC.

openldap 2.4: l'installazione on-premise richiede OpenLDAP 2.4. Se il server abbia una connessione a internet, lo script di installazione Edge scarica e installa OpenLDAP. Se il server non dispone di una connessione Internet, devi assicurarti che OpenLDAP sia è già installata prima di eseguire lo script di installazione perimetrale. Su RHEL/CentOS, puoi eseguire "yum install openldap-clients" openldap-servers&quot; per installare OpenLDAP.

Per le installazioni con 13 host e le installazioni con 12 host con due data center, hai bisogno Replica OpenLDAP perché sono presenti più nodi che ospitano OpenLDAP.

Firewall e host virtuali

Il termine "virtuale" è comunemente sovraccaricato nel campo IT, quindi si tratta di un Apigee Edge per il deployment di host virtuali e il cloud privato. Per chiarire, ci sono due principali usi del termine "virtuale":

  • Macchine virtuali (VM): non richieste, ma alcuni deployment utilizzano la tecnologia VM per creare server isolati per i componenti Apigee. Gli host delle VM, come gli host fisici, possono avere le interfacce di rete e i firewall. Queste istruzioni di installazione non supportano specificamente delle installazioni di VM.
  • 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 nelle l'alias host o la porta dell'interfaccia).

Come esempio di denominazione, un singolo server fisico "A" potrebbe eseguire due VM, denominati "VM1" e "VM2". Supponiamo che VM1 mostri una rete Ethernet virtuale che prende il nome eth0 all'interno della VM e a cui è assegnato l'indirizzo IP 111.111.111.111 dalla virtualizzazione un macchinario o un server DHCP di rete; e quindi supponiamo che VM2 mostri un'interfaccia Ethernet virtuale denominato eth0 e gli viene assegnato l'indirizzo IP 111.111.111.222.

Potremmo avere un router Apigee in esecuzione in ciascuna delle due VM. I router espongono l'host virtuale come in questo esempio ipotetico:

Il router Apigee nella VM1 espone tre host virtuali sulla sua interfaccia eth0 (che ha 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 (stesso nome e porta dello stesso nome esposto da VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete. se sì, il firewall deve essere configurato in modo da passare il traffico TCP per le porte esposte (111.111.111.111:{80, 443} e 111.111.111.222:80). Inoltre, ogni Il sistema operativo della VM può fornire un proprio firewall sull'interfaccia eth0 e anche questi devono per consentire la connessione delle porte 80 e 443 al traffico.

Il percorso di base è il terzo componente coinvolto nell'instradamento delle chiamate API a proxy API diversi di cui potresti aver eseguito il deployment. I bundle di proxy API possono condividere un endpoint se hanno diversi percorsi di base. Ad esempio, un percorso di base può essere definito come http://api.mycompany.com:80/ e un altro definita 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 divida http://api.mycompany.com:80/ traffico tra i due indirizzi IP (111.111.111.111 su VM1 e 111.111.111.222 su VM2). Questa funzione è specifico per la tua particolare installazione ed è configurato dal tuo gruppo di rete locale.

Il percorso di 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'app host con l'alias host di api.mycompany.com e la porta impostata su 80. Se non dichiari un basepath nel deployment, il router non sa quale API inviare le richieste in entrata a.

Tuttavia, se esegui il deployment dell'API testmycompany con l'URL di base di /salesdemo, gli utenti potranno accedere l'API utilizzando http://api.mycompany.com:80/salesdemo. Se distribuire l'API mycompany con l'URL di base di / quindi 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 i soli host virtuali; sia VM che host fisico i firewall devono consentire al traffico di comunicare tra le porte richieste dai componenti e l'altro.

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 da parte del router solo quando a configurare TLS/SSL tra il router e il processore di messaggi. Se non configuri TLS/SSL tra router e processore di messaggi, la configurazione predefinita, la porta 8082, essere aperta sul processore di messaggi per gestire il componente, ma il router non richiede per accedervi.
  • Le porte precedute dal prefisso "M" sono porte utilizzate per gestire il componente e devono essere aperte per l'accesso da parte del 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 poter accedere l'uno all'altro tramite la porta 4528 (indicata dal freccia a ciclo nel diagramma sopra per la porta 4528 sul processore di messaggi). Se disponi di più Nei data center, la porta deve essere accessibile da tutti i processori di messaggi presenti in tutti i data center.
  • Sebbene non sia richiesta, è possibile aprire la porta 4527 sul router per accedere tramite qualsiasi messaggio Processore. In caso contrario, potresti visualizzare messaggi di errore nei file di log del processore di messaggi.
  • Un router deve aprire la porta 4527 come porta di gestione. Se disponi di più router, devono essere tutti in grado di accedere l'uno all'altro sulla porta 4527 (indicata dalla freccia diagramma riportato sopra per la porta 4527 del router).
  • La UI Edge richiede l'accesso al router, tramite le porte esposte dai proxy API, per supportare il pulsante Invia nello strumento di traccia.
  • Il server di gestione richiede l'accesso alla porta JMX su Cassandra nodi.
  • L'accesso alle porte JMX può essere configurato in modo da richiedere un nome utente e una password. Per ulteriori informazioni, consulta la sezione Come monitorare.
  • Facoltativamente, puoi configurare l'accesso TLS/SSL per determinate connessioni, che possono utilizzare porte diverse. Fai riferimento a TLS/SSL per altro ancora.
  • 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 su singoli nodi per consentire tramite SSH.
  • Puoi configurare il server di gestione e la UI perimetrale in modo che inviino le email tramite un server SMTP esterno o server web. In tal caso, è necessario assicurarsi che il server di gestione e l'interfaccia utente possano accedere ai sul server SMTP. Per SMTP non TLS, il numero di porta è in genere 25. Per TLS abilitato SMTP, spesso è 465, ma verifica con il tuo provider SMTP.

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

Componente

Porta

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 Edge. Questi componenti richiedono l'accesso alla porta 8080 il 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 e 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 utilizzato dal router per eseguire controlli di integrità sul processore di messaggi.

1101

Porta JMX

4528

Per cache distribuita e 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 dal server di gestione.

4527

Per chiamate di gestione e cache distribuite

15999

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

Per ottenere lo stato di un router, il bilanciatore del carico invia una richiesta alla porta 15999 sulla Router:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

Se il router è raggiungibile, la richiesta restituisce HTTP 200.

ZooKeeper

2181

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

2888, 3888

Utilizzato internamente da ZooKeeper per il cluster ZooKeeper (noto come insieme ZooKeeper) comunicazione

Cassandra

7000, 9042, 9160

Porte di Apache Cassandra per la comunicazione tra i nodi Cassandra e per l'accesso gli altri componenti Edge.

7199

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

Qpid

5672

Utilizzato per le comunicazioni dal router e dal processore 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 chiamate di gestione e cache distribuite

Postgres

5432

Utilizzato per le comunicazioni da Qpid/Management Server a Postgres

8084

La porta di gestione predefinita sul server Postgres e 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, devi aprire 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 pagina SmartDocs.

Nota: in aggiunta, per il test potrebbe essere necessario aprire le porte nei firewall. Per esempio, 59001 e così via.

La tabella successiva mostra le stesse porte, elencate numericamente, con l'origine e la destinazione componenti:

Numero di 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. Porte 80 e 443 sono i più comuni; 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 client Zookeeper

Server di gestione

Router

processore di messaggi

Server Qpid

Server Postgres

Zookeeper

2888 e 3888

Gestione degli internodi dello zoo

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 chiamate cache distribuite tra processori di messaggi e per le comunicazioni dal router

Router

processore di messaggi

processore di messaggi

5432

Client Postgres

Server Qpid

Postgres

5672

Utilizzato per inviare 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 disponibile per l'accesso sul nodo Cassandra da parte del management Server.

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, l'esatta porta utilizzata dipende dalla configurazione ma deve essere aperto sul componente per l'accesso 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

9042

Trasporto nativo CQL

Router

processore di messaggi

Server di gestione

Cassandra

9160

Cliente di articoli usati Cassandra

Router

processore di messaggi

Server di gestione

Cassandra

10.389

Porta LDAP

Server di gestione

OpenLDAP

15.999 Porta del controllo di integrità. Un bilanciatore del carico utilizza questa porta per determinare se il router è disponibili. Bilanciatore del carico Router

59002

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

SmartDocs

Router

Un processore di messaggi mantiene un pool di connessioni dedicato aperto per Cassandra, che è configurato senza timeout. Quando un firewall si trova tra un processore di messaggi e un server Cassandra, il firewall può causare il timeout della connessione. Tuttavia, il processore di messaggi non è progettato ristabilire le connessioni a Cassandra.

Per evitare questa situazione, Apigee consiglia di utilizzare il server Cassandra, il processore di messaggi I router si trovano nella stessa subnet in modo che non sia coinvolto un firewall nel deployment componenti.

Se un firewall si trova tra il router e i processori di messaggi e ha un timeout tcp di inattività impostato, i nostri consigli sono:

  1. Imposta net.ipv4.tcp_keepalive_time = 1800 nelle impostazioni sysctl sul sistema operativo Linux, dove 1800 dovrebbe essere inferiore al livello di inattività del firewall timeout tcp. Questa impostazione deve mantenere la connessione in uno stato stabilito in modo che il firewall non disconnette la connessione.
  2. In tutti i processori di messaggi, modifica /&lt;inst_root&gt;/apigee/customer/application/message-processor.properties per aggiungere la seguente proprietà. Se il file non esiste, crealo.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. Riavvia il processore di messaggi:
    &gt; /opt/apigee/apigee-service/bin/apigee-service edge-message-processor riavvio
  4. Su tutti i router, modifica /&lt;inst_root&gt;/apigee/customer/application/router.properties per aggiungere la seguente proprietà. Se il file non esiste, crealo.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. Riavvia il router:
    &gt; /opt/apigee/apigee-service/bin/apigee-service edge-router riavvio

Se installi la configurazione in cluster con 12 host con due data center, assicurati che i nodi dei due data center possono comunicare attraverso le porte mostrate di seguito:

Requisiti delle porte BaaS delle API

Se scegli di installare API BaaS, aggiungi i componenti dello stack BaaS dell'API e del portale BaaS dell'API. Questi componenti utilizzano le porte mostrate nella figura seguente:

Note su questo diagramma:

  • I nodi Cassandra possono essere dedicati al BaaS dell'API o condivisi con Edge.
  • Un'installazione in produzione di API BaaS utilizza un bilanciatore del carico tra il nodo del portale API BaaS e i nodi dello stack BaaS API. Durante la configurazione del portale e le chiamate API BaaS, specificare l'indirizzo IP o il nome DNS del bilanciatore del carico, non dei nodi dello stack.
  • Devi configurare tutti i nodi dello stack Baas in modo che inviino le email tramite un server SMTP esterno. Per non TLS, il numero di porta è in genere 25. Per SMTP con TLS abilitato, spesso è 465, ma controlla con il tuo provider SMTP.

La tabella seguente mostra le porte predefinite che è necessario aprire nei firewall, per componente:

Componente

Porta

Descrizione

Portale API BaaS

9000

Porta per l'UI API BaaS

Stack BaaS delle API

8080

Porta in cui vengono ricevute le richieste API

ElasticSearch

Da 9200 a 9400

Per comunicare con API BaaS Stack e per comunicare tra ElasticSearch nodi

Licenze

Ogni installazione di Edge richiede un file di licenza univoco ottenuto da Apigee. Potrai devi fornire il percorso del file di licenza durante l'installazione del server di gestione, ad esempio /tmp/license.txt.

Il programma di installazione copia il file di licenza in /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

Se il file di licenza è valido, il server di gestione convalida la scadenza e il messaggio consentito Numero di processori (MP). Se una delle impostazioni della licenza è scaduta, puoi trovare i log nella seguente percorso: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. In questo caso, puoi contattare l'assistenza Apigee per dettagli della migrazione.