Requisiti di installazione

Edge for Private Cloud versione 4.16.05

Requisiti hardware

Devi soddisfare i seguenti requisiti minimi per l'hardware per un'infrastruttura altamente disponibile in un ambiente 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 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.

Inoltre, di seguito sono elencati i requisiti hardware per installare i servizi di monetizzazione:

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

Nota:

• Se le dimensioni del file system radice non sono sufficientemente grandi 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 Private Cloud, assicurati di eliminare la cartella /tmp/java prima di una nuova installazione.
• La cartella temporanea di sistema /tmp richiede autorizzazioni di esecuzione per 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 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 di Edge sono di proprietà di "apigee", così come i processi di Edge. Ciò significa che i componenti Edge vengono eseguiti come utente 'apigee'. Se necessario, puoi eseguire i componenti come utente diverso. Per un esempio, consulta "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 di questa directory.

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

Java

Prima dell'installazione è necessario installare una versione supportata di Java 1.8 su ogni computer. I JDK supportati sono elencati qui:

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

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

Impostazione di 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
• nome host -i restituisce l'indirizzo IP per il 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 sistema operativo in uso.

Cassandra

Tutti i nodi Cassandra devono essere connessi a un anello.

Cassandra regola automaticamente le dimensioni dell'heap Java in base alla memoria disponibile. Per saperne di più, consulta Ottimizzazione delle risorse Java. In caso di riduzione delle prestazioni o di elevato consumo di memoria.

Dopo aver installato Edge per Private Cloud, 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 abbia impostato le seguenti proprietà:

• cluster_name
• initial_token
• partitioner
• 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 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 postgresql.properties:
   > vi /<inst_root>/apigee/customer/application/postgresql.properties
   
   Se il file non esiste, creane uno.
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 riavvio

jsvc

"jsvc" è un prerequisito per l'utilizzo dell'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 supporta lo sviluppo di applicazioni client e server con funzionalità di sicurezza. Assicurati di aver installato NSS v3.19 o versioni successive.

Per controllare la versione in uso:

> yum info nss

Per aggiornare NSS:

> yum update nss

Per ulteriori informazioni, consulta questo articolo di RedHat.

AMI AWS

Se stai installando Edge su un'immagine Amazon Machine (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.

Nota:

• L'eseguibile dello strumento "useradd" si trova in /usr/sbin e quello di chkconfig in /sbin.
• Con l'accesso sudo puoi accedere all'ambiente dell'utente che chiama, ad esempio, solitamente chiami "sudo <comando>" o "sudo PATH=$PATH:/usr/sbin:/sbin <comando>".
• Assicurati di aver installato lo strumento "patch" prima dell'installazione di un 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 devi impostare il fuso orario del server in UTC.

openldap 2.4: l'installazione on-premise richiede OpenLDAP 2.4. Se il tuo server ha una connessione a internet, lo script di installazione di Edge 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 OpenLDAP.

Per le installazioni con 13 host e per quelle con 12 host e due data center, è necessaria la replica di OpenLDAP perché sono presenti 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, esistono due usi principali del termine "virtuale":

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

Un router in una VM può esporre più host virtuali (purché differiscano tra loro per l'alias host o per la porta dell'interfaccia).

Ad esempio, un singolo server fisico "A" potrebbe eseguire due VM, rinominate "VM1" e "VM2". Supponiamo che la VM1 esponga un'interfaccia Ethernet virtuale, denominata eth0 all'interno della VM, a cui viene assegnato l'indirizzo IP 111.111.111.111 dalla macchina virtuale o da un server DHCP di rete. Supponiamo inoltre che la VM2 esponga un'interfaccia Ethernet virtuale, denominata anche eth0, 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 gli endpoint dell'host virtuale come in questo esempio ipotetico:

Il router Apigee nella VM1 espone tre host virtuali sulla sua interfaccia eth0 (che ha un indirizzo IP specifico), api.mycompany.com:80, api.mycompany.com:443 e test.mycompany.com:80.

Il router nella VM2 espone api.mycompany.com:80 (stessa porta e stesso nome esposti dalla VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete. In questo caso, il firewall deve essere configurato per far passare il traffico TCP diretto 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 sull'interfaccia eth0 e anche questi devono consentire la connessione del traffico sulle porte 80 e 443.

Il percorso base è il terzo componente coinvolto nell'indirizzamento delle chiamate API a diversi proxy API che potresti aver disegnato. I bundle di proxy API possono condividere un endpoint se hanno percorsi di base diversi. Ad esempio, un percorso 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 qualche tipo di direttore del traffico che divida il traffico http://api.mycompany.com:80/ tra i due indirizzi IP (111.111.111.111 sulla VM1 e 111.111.111.222 sulla VM2). Questa funzione è specifica per la tua installazione e viene configurata dal tuo gruppo di networking locale.

Il percorso di base viene impostato quando esegui il deployment di un'API. Dall'esempio precedente, puoi eseguire il deployment di due API, la mia azienda e testa la mia azienda, per l'organizzazione la mia azienda-org con l'host virtuale che ha l'alias host api.la mia azienda.com e la porta impostata su 80. Se non dichiari un percorso di base nel deployment, il router non sa a quale API inviare le richieste in arrivo.

Tuttavia, se esegui il deployment dell'API testmycompany con l'URL di base /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 per le porte Edge

La necessità di gestire il firewall va oltre i semplici host virtuali: sia i firewall delle VM che quelli degli host fisici devono consentire il traffico verso le porte richieste dai componenti di comunicare tra loro.

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

Note su questo diagramma:

• *La porta 8082 sul Message Processor deve essere aperta per l'accesso da parte del router solo quando configurerai TLS/SSL tra il router e il Message Processor. Se non configuri TLS/SSL tra il router e il Message Processor, la configurazione predefinita, la porta 8082 deve essere ancora aperta sul Message Processor per gestire il componente, ma il router non richiede accesso.
• Le porte precedute dal prefisso "M" sono porte utilizzate per gestire il componente e devono essere aperte sul componente per consentire 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 Message Processor 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 del loop nel diagramma sopra per la porta 4528 sul Processore di messaggi). Se hai più data center, la porta deve essere accessibile da tutti gli elaboratori di messaggi in tutti i data center.
• Sebbene non sia richiesta, 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 di Message Processor.
• 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 del loop nel diagramma sopra per la porta 4527 sul router).
• L'interfaccia utente di 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/una password. Per ulteriori informazioni, 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 ciascun nodo per l'accesso SSH. Facoltativamente, puoi aprire le porte su singoli nodi per consentire l'accesso SSH.
• Puoi configurare il server di gestione e l'interfaccia utente di Edge per inviare email tramite un server SMTP esterno. In questo caso, devi assicurarti che il server di gestione e l'interfaccia utente 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, in base al 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 di destinazione:

Un elaboratore di messaggi mantiene aperto un pool di connessioni dedicato a Cassandra, che è configurato per non scadere mai. Quando un firewall si trova tra un elaboratore di messaggi e il server Cassandra, il firewall può causare il timeout della connessione. Tuttavia, l'elaborazione dei messaggi non è progettata per ricollegare le connessioni a Cassandra.

Per evitare questa situazione, Apigee consiglia che il server Cassandra, l'elaboratore 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 gli elaboratori dei 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 dovrebbe mantenere la connessione in uno stato stabilito in modo che il firewall non la disconnetta.
2. In tutti i Message Processor, modifica /<inst_root>/apigee/customer/application/message-processor.properties per aggiungere la seguente proprietà. Se il file non esiste, creane uno.
   conf_system_casssandra.maxconnecttimeinmillis=-1
3. Riavvia il Message Processor:
   > /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, creane uno.
   conf_system_casssandra.maxconnecttimeinmillis=-1
5. Riavvia il router:
   > /opt/apigee/apigee-service/bin/apigee-service edge-router restart

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

Requisiti delle porte BaaS delle API

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:

• I nodi Cassandra possono essere dedicati all'API BaaS o condivisi con Edge.
• 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 ed esegui chiamate all'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 con TLS abilitato, è spesso 465, ma consulta il tuo fornitore SMTP.

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 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 di elaboratori di messaggi (MP) consentiti. 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 ricevere dettagli sulla migrazione.