Requisiti di installazione

Edge per Private Cloud v4.18.01

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.

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

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

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 nella Software supportati e versioni supportate.

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.

Directory di installazione

Per impostazione predefinita, il programma di installazione scrive tutti i file nella directory /opt/apigee. Tu impossibile modificare questo percorso della directory. Anche se non puoi modificare questa directory, puoi creare un 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 link simbolico da /opt/apigee

Prima di creare il link simbolico, devi prima creare un utente e un gruppo denominati "apigee". Questo è lo stesso gruppo e lo stesso utente creati dal programma di installazione di Edge.

Per creare il collegamento simbolico, eseguire questi passaggi prima di scaricare il file bootstrap_4.18.01.sh. Devi eseguire tutti questi passaggi come root:

1. Crea "apigee" utente e gruppo:

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

   ln -Ts /srv/myInstallDir /opt/apigee

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

3. Cambia la proprietà della radice di installazione e del link simbolico con "apigee" utente:

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

Java

È necessaria una versione supportata di Java 1.8 installata su ogni macchina prima dell'installazione. I JDK supportati sono elencati in Software supportati e versioni supportate.

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

SELinux

A seconda delle impostazioni di SELinux, Edge può riscontrare problemi con l'installazione e l'avvio Componenti periferici. Se necessario, puoi disabilitare SELinux o impostarlo in modalità permissiva per poi riattivarlo dopo l'installazione. Per saperne di più, vedi Installare l'utilità apigee-setup Edge.

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:

• hostname restituisce il nome della macchina
• hostname -i restituisce l'indirizzo IP per il nome host a cui può essere indirizzato. ad 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.

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

ENABLE_DYNAMIC_HOSTIP=y

Con questa proprietà impostata su "y", il programma di installazione ti chiede di selezionare l'indirizzo IP da utilizzare come parte dell'installazione. Il valore predefinito è "n". Consulta Riferimento al file di configurazione Edge per ulteriori informazioni.

Wrapper TCP

I wrapper TCP possono bloccare la comunicazione tra alcune porte e influenzare OpenLDAP, Postgres e Installazione di Cassandra. Su questi nodi, controlla /etc/hosts.allow /etc/hosts.deny per garantire che non ci siano limitazioni per le porte sull'istanza richiesta Porte OpenLDAP, Postgres e Cassandra.

iptables

Verifica che non esistano criteri iptables che impediscano la connettività tra i nodi sul porte perimetrali richieste. Se necessario, puoi interrompere iptables durante l'installazione utilizzando :

sudo/etc/init.d/iptables stop

Su CentOS 7.x:

systemctl stop firewalld

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

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

Se il processo di sicurezza richiede l'impostazione delle autorizzazioni su /etc/rc.d/init.d/functions, non impostarle su 700, altrimenti il router non riuscirà per iniziare. Puoi impostare le autorizzazioni 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 nodi multipli per garantire affidabilità e tolleranza di errore. La strategia di replica per ogni Lo spazio delle chiavi perimetrale determina i nodi Cassandra in cui vengono inserite le repliche. Per ulteriori informazioni,vedi Informazioni su Cassandra fattore di replica e livello di coerenza.

Cassandra regola automaticamente la dimensione dell'heap Java in base alla memoria disponibile. Per ulteriori informazioni, vedi Ottimizzazione Risorse Java. 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 /opt/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
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

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 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 su Cassandra e sul processore di messaggi nodi:

• Nei nodi Cassandra, imposta limiti per memlock soft e hard, nofile e spazio di indirizzi (as) per utente dell'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 del processore 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 come mostrato di seguito:

  apigee soft nofile 32768
  apigee hard nofile 65536

  Se necessario, puoi aumentare questo limite. Ad esempio, se hai un gran numero di aprire i file contemporaneamente.

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

Consulta questo articolo. di RedHat per ulteriori informazioni.

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

Se hai installato e abilitato NSCD (Name Service Cache Daemon), i processori di messaggi effettua due ricerche DNS: una per IPv4 e una per IPv6. Devi disattivare la ricerca DNS IPv6 quando si utilizza NSCD.

Per disattivare la ricerca DNS su IPv6:

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

   enable-cache hosts no

Disabilita IPv6 su Google Cloud Piattaforma per RedHat/CentOS 7

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

Consulta la documentazione di RedHat o CentOS per la versione specifica del tuo sistema operativo per istruzioni su disabilitazione dell'IPv6. Ad esempio, puoi:

1. Apri /etc/hosts in un editor.
2. Inserisci un "#" nella colonna una delle seguenti righe per commentarlo:

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

3. Salva il file.

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

ntpdate

Ti consigliamo di chiedere ai server orari sincronizzati. Se non è già configurato, ntpdate utilità 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 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 virtual di solito viene sovraccaricato in ambito IT, quindi si riferisce a un Apigee Edge per il deployment di host virtuali e il cloud privato. Per chiarire, ci sono due principali usi del termine virtual:

• 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.
• 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, denominato "VM1" e "VM2". Supponiamo che "VM1" espone un'interfaccia Ethernet virtuale, che prende il nome "eth0" all'interno della VM e a cui è assegnato l'indirizzo IP 111.111.111.111 il macchinario di virtualizzazione o un server DHCP di rete; e quindi supponiamo che VM2 espone un'istanza Interfaccia Ethernet chiamata anche "eth0" e gli viene assegnato un 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 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 consente al traffico sulle porte 80 e 443 di connettersi.

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 definito 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'host virtuale che possiede 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 accedano all'API utilizzando http://api.mycompany.com:80/salesdemo. Se distribuisci l'API mycompany con URL di base /, quindi i tuoi 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 del 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 e deve essere aperto 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 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. Consulta Come monitorare per saperne di più.
• 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:

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

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

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. Configura net.ipv4.tcp_keepalive_time = 1800 nelle impostazioni sysctl sul sistema operativo Linux, dove 1800 deve essere inferiore al timeout della connessione tcp di inattività del firewall. Questa impostazione deve mantenere connessione in uno stato stabilito in modo che il firewall non scolleghi la connessione.
2. In tutti i processori di messaggi, 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 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:

• Il portale BaaS dell'API non invia 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 del portale in esecuzione quindi il browser invia richieste ai nodi dello stack BaaS.
• 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.
• Tutti i nodi dello stack devono aprire la porta 2551 per l'accesso da tutti gli altri nodi dello stack (come indicato dal la freccia loop nel diagramma in alto per la porta 2551 sui nodi dello stack). Se disponi di più dati Center, la porta deve essere accessibile da tutti i nodi stack in tutti i data center.
• 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.
• I nodi Cassandra possono essere dedicati al BaaS dell'API o condivisi con Edge.

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

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 della licenza /opt/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 località: /opt/apigee/var/log/edge-management-server/logs. In questo caso, puoi contattare l'assistenza Apigee Edge per i dettagli sulla migrazione.

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