Requisiti di installazione

Edge for Private Cloud v4.18.01

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura ad alta disponibilità in un ambiente di livello di produzione. 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 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.

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

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

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 supportato e versioni supportate.

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 Edge. Ciò significa che i componenti Edge vengono eseguiti come utente "apigee". Se necessario, puoi eseguire i componenti come un utente diverso.

Directory di installazione

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

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

Creazione di un collegamento simbolico da /opt/apigee

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

Per creare il collegamento simbolico, esegui questi passaggi prima di scaricare il file bootstrap_4.18.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 collegamento simbolico da /opt/apigee alla radice di installazione che preferisci:

   ln -Ts /srv/myInstallDir /opt/apigee

   dove /srv/myInstallDir è la posizione desiderata dei file Edge.

3. Modifica la proprietà della radice di installazione e del collegamento simbolico all'utente "apigee":

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

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

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

SELinux

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

Impostazione della rete

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

• hostname restituisce il nome della macchina
• hostname -i restituisce l'indirizzo IP per il nome host a cui è possibile accedere 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 saperne di più, consulta la documentazione del tuo sistema operativo specifico.

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

ENABLE_DYNAMIC_HOSTIP=y

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

TCP Wrappers

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 limitazioni delle porte sulle porte OpenLDAP, Postgres e Cassandra richieste.

iptables

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

sudo/etc/init.d/iptables stop

Su CentOS 7.x:

systemctl stop firewalld

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

I nodi Edge Router e BaaS Portal utilizzano il router Nginx e richiedono l'accesso in lettura a /etc/rc.d/init.d/functions.

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

Cassandra

Tutti i nodi Cassandra devono essere connessi a un anello. Cassandra archivia le repliche dei dati su più nodi per garantire affidabilità e tolleranza agli errori. La strategia di replica per ogni spazio delle 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ù, vedi Ottimizzazione delle risorse Java. In caso di peggioramento delle prestazioni o elevato consumo di memoria.

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

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

Database PostgreSQL

Dopo aver installato Edge, puoi 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:

1. Modifica il file postgresql.properties:

   vi /opt/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:

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

Limiti del sistema

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

• Sui nodi Cassandra, imposta i limiti soft e hard di memlock, nofile e spazio degli 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

• Nei nodi processore di messaggi, imposta il numero massimo di descrittori del file aperti su 64.000 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.

jsvc

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

Network Security Services (NSS)

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

Per controllare la versione attuale:

yum info nss

Per aggiornare NSS:

yum update nss

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

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

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

Per disattivare la ricerca DNS su IPv6:

1. Su ogni nodo processore di messaggi, modifica /etc/nscd.conf
2. Imposta la seguente proprietà:

   enable-cache hosts no

Disattiva IPv6 su Google Cloud Platform per RedHat/CentOS 7

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

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

1. Apri /etc/hosts in un editor.
2. Inserisci il carattere "#" nella prima colonna della seguente riga per commentarla:

   #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

3. Salva il file.

AMI AWS

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

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

Strumenti

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

ntpdate

Ti consigliamo di sincronizzare l'ora dei server. Se non è già configurato, l'utilità ntpdate potrebbe servire a questo scopo, verificando se i server sono sincronizzati con l'ora. Puoi utilizzare yum install ntp per installare l'utilità. Ciò è particolarmente utile per replicare le configurazioni OpenLDAP. Tieni presente che hai configurato il fuso orario del server in UTC.

openldap 2.4

L'installazione on-premise richiede OpenLDAP 2.4. Se il server è connesso a internet, lo script di installazione di 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 di Edge. Su RHEL/CentOS, puoi eseguire yum install openldap-clients openldap-servers per installare OpenLDAP.

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

Firewall e host virtuali

Il termine virtual viene spesso sovraccaricato nell'ambito IT, così come per un deployment di Apigee Edge for Private Cloud e per gli host virtuali. Per chiarire, esistono due utilizzi principali del termine virtual:

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

Un router in una VM può esporre più host virtuali (a condizione che differiscano l'uno dall'altro 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 dal meccanismo di virtualizzazione o da un server DHCP di rete. Supponiamo poi che VM2 esponga un'interfaccia Ethernet virtuale denominata anch'essa "eth0" e a cui viene assegnato l'indirizzo IP 111.111.111.222.

Potremmo avere un router Apigee in esecuzione in ciascuna delle due VM. I router espongono endpoint 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 in VM2 espone api.mycompany.com:80 (stesso nome e porta di quelli esposti da VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete; in questo caso, il firewall deve essere configurato per 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 sua interfaccia eth0 e anche questi devono consentire il traffico delle porte 80 e 443 per la connessione.

Il percorso di base è il terzo componente coinvolto nel routing delle chiamate API a diversi proxy API di cui potresti aver eseguito il deployment. I bundle di proxy API possono condividere un endpoint se hanno basepath diversi. Ad esempio, un basepath 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 Traffic Director 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 particolare installazione ed è configurata dal tuo gruppo di networking 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'host virtuale che ha l'alias host api.mycompany.com e la porta impostata su 80. Se non dichiari un basepath 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 a questa 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 i soli host virtuali; i firewall della VM e dell'host fisico devono consentire il traffico per le porte richieste dai componenti per comunicare tra loro.

La seguente immagine mostra i requisiti delle porte per ogni componente Edge:

Note su questo diagramma:

• * La porta 8082 sul processore di messaggi deve essere aperta solo per l'accesso 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 processore di messaggi per gestire il componente, ma il router non richiede l'accesso.
• Le porte con il prefisso "M" vengono 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 di messaggi, UI, Postgres e Qpid.
• Un processore di messaggi deve aprire la porta 4528 come porta di gestione. Se hai più processori di messaggi, tutti devono essere in grado di accedere l'uno all'altro tramite la porta 4528 (indicata dalla freccia a loop nel diagramma precedente per la porta 4528 sul processore di messaggi). Se hai più data center, la porta deve essere accessibile da tutti i Message Processor in tutti i data center.
• Sebbene non sia obbligatorio, puoi aprire la porta 4527 sul router per l'accesso da parte di qualsiasi Message Processor. 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 hai più router, devono essere tutti in grado di accedere l'uno all'altro tramite la porta 4527 (indicata dalla freccia a loop nel diagramma precedente per la porta 4527 sul router).
• L'interfaccia utente 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 e una password. Per saperne di più, consulta Come monitorare.
• Se vuoi, 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 utilizzare la replica master-standby, devi aprire la porta 22 su ogni 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 Edge per inviare 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 è in genere 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, per componente Edge:

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

La tabella seguente mostra le stesse porte, elencate in ordine numerico, con i componenti di origine e destinazione:

Un processore di messaggi mantiene aperto un pool di connessioni dedicato a Cassandra, configurato in modo che non si verifichi mai un timeout. Quando un firewall si trova tra un processore di messaggi e il server Cassandra, il firewall può interrompere la connessione. Tuttavia, il processore di messaggi non è progettato per ristabilire le connessioni a Cassandra.

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

Se tra il router e i processori di messaggi è presente un firewall con un timeout TCP inattivo impostato, 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 inattivo del firewall. Questa impostazione deve mantenere la connessione in uno stato stabilito in modo che il firewall non la interrompa.
2. In tutti i Message Processor, modifica /opt/apigee/customer/application/message-processor.properties per aggiungere la seguente proprietà. Se il file non esiste, crealo.

   conf_system_cassandra.maxconnecttimeinmillis=-1

3. Riavvia il processore di messaggi:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

4. Su tutti i router, modifica /opt/apigee/customer/application/router.properties per aggiungere la seguente proprietà. Se il file non esiste, crealo.

   conf_system_cassandra.maxconnecttimeinmillis=-1

5. Riavvia il router:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

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

Requisiti delle porte API BaaS

Se scegli di installare 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 API BaaS non effettua mai richieste direttamente a un nodo dello stack BaaS. Quando uno sviluppatore accede al portale, l'app del portale viene scaricata nel browser. L'app Portal in esecuzione nel browser effettua richieste ai nodi dello stack BaaS.
• Un'installazione di produzione di API BaaS utilizza un bilanciatore del carico tra il nodo del portale API BaaS e i nodi dello stack API BaaS. 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 di loop nel diagramma precedente per la porta 2551 sui nodi dello stack). Se hai più data center, la porta deve essere accessibile da tutti i nodi Stack in tutti i data center.
• Devi configurare tutti i nodi di 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.
• I nodi Cassandra possono essere dedicati ad API BaaS o possono essere condivisi con Edge.

La tabella seguente mostra le porte predefinite che devono essere aperte nei firewall, per componente:

Licenze

Ogni installazione di Edge richiede un file di licenza univoco che ottieni da Apigee. Dovrai 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 /opt/apigee/customer/conf/license.txt.

Se il file di licenza è valido, il server di gestione convalida la scadenza e il numero di Message Processor (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 Apigee Edge per i dettagli della migrazione.

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