Requisiti di installazione

Edge per Private Cloud v4.19.01

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura ad alta disponibilità in un ambiente di produzione.

Il seguente video offre indicazioni generali sulle dimensioni da applicare all'installazione:

Per tutti gli scenari di installazione descritti in Topologie di installazione, le seguenti tabelle 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 rispetto a quelle elencate di seguito.

Componente di installazione RAM CPU Disco rigido minimo
Cassandra 16 GB 8 core 250 GB di spazio di archiviazione locale con SSD che supporta 2000 IOPS
Processore/router dei messaggi sulla stessa macchina 16 GB 8 core 100GB
Processore di messaggi (autonomo) 16 GB 8 core 100GB
Router (autonomo) 16 GB 8 core 100GB
Analytics - Postgres/Qpid sullo stesso server 16GB* 8 core* Spazio di archiviazione di rete da 500 GB a 1 TB**, *** preferibilmente con backend SSD, con supporto di almeno 1000 IOPS*
Analytics - Postgres principale o standby (autonomo) 16GB* 8 core* Spazio di archiviazione di rete da 500 GB a 1 TB**, *** preferibilmente con backend SSD, con supporto di almeno 1000 IOPS*
Analytics - Qpid autonomo 16 GB 8 core Spazio di archiviazione locale da 30 GB a 50 GB con SSD

La dimensione predefinita della coda Qpid è 1 GB, che può essere aumentata a 2 GB. Se hai bisogno di maggiore capacità, aggiungi altri nodi Qpid.
OpenLDAP/UI/server di gestione 4 GB 2 core 60 GB
UI/server di gestione 4 GB 2 core 60 GB
OpenLDAP (autonomo) 4 GB 2 core 60 GB

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

  • Meno di 250 TPS: con l'archiviazione di rete gestita da 8 GB a 4 core*** supporta almeno 1000 IOPS
  • Oltre 250 TPS: spazio di archiviazione di rete gestito da 16 GB, a 8 core***, con supporto di almeno 1000 IOPS
  • Oltre 1000 TPS: spazio di archiviazione di rete gestito da 16 GB, a 8 core***, con supporto di almeno 2000 IOPS
  • Oltre 2000 TPS: spazio di archiviazione di rete gestito da 32 GB, a 16 core***, con supporto di almeno 2000 IOPS
  • Oltre 4000 TPS: spazio di archiviazione di rete gestito da 64 GB, a 32 core***, con supporto di 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 devono essere aumentati di conseguenza. Utilizza la seguente formula per stimare lo spazio di archiviazione richiesto:

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Ad esempio:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

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

  • Offre la possibilità di fare dinamicamente lo scale up delle dimensioni di archiviazione se e quando necessario.
  • Le IOPS di rete possono essere regolate in tempo reale nella maggior parte dei sottosistemi di ambiente, archiviazione e rete di oggi.
  • Gli snapshot a livello di archiviazione possono essere abilitati come parte di soluzioni di backup e ripristino.

Inoltre, di seguito sono elencati i requisiti hardware per installare i Servizi di monetizzazione (non supportati nell'installazione All-in-One):

Componente con 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 Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, con supporto di almeno 1000 IOPS oppure utilizza la regola della tabella precedente.
Analytics - Postgres master o standby autonomo 16 GB 8 core Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, con supporto di almeno 1000 IOPS oppure utilizza la regola della tabella precedente.
Analytics - Qpid autonomo 8 GB 4 core Spazio di archiviazione locale da 40 GB a 500 GB con SSD o HDD veloce

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

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

Creazione dell 'utente apigee'

La procedura di installazione crea un utente di sistema Unix denominato 'apigee'. Le directory e i file perimetrali 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 utente diverso.

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 link simbolico per mappare /opt/apigee a un'altra posizione, come descritto in Creare un link simbolico da /opt/apigee.

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

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

Per creare il link simbolico, esegui questi passaggi prima di scaricare il file bootstrap_4.19.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 link simbolico da /opt/apigee alla directory principale di installazione desiderata: 
    ln -Ts /srv/myInstallDir /opt/apigee

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

  3. Cambia la proprietà della root di installazione e aggiungi un link simbolico all'utente "apigee": 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

È necessario che su ogni macchina sia installata una versione supportata di Java 1.8 prima dell'installazione. I JDK supportati sono elencati nella sezione Software e versioni supportate.

Assicurati che la variabile di ambiente 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 di installazione e avvio dei componenti Edge. Se necessario, puoi disabilitare SELinux o impostarlo in modalità permissiva durante l'installazione e riattivarlo dopo l'installazione. Per saperne di più, consulta Installare l'utilità Edge apigee-setup.

Impostazione di rete

Apigee consiglia 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 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 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

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". Per ulteriori informazioni, consulta la pagina di riferimento sul file di configurazione perimetrale.

Wrapper TCP

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

iptables

Verifica che non esistano criteri iptables che impediscono la connettività tra i nodi sulle porte perimetrali 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

Accesso alla directory

La seguente tabella elenca le directory sui nodi perimetrali che hanno requisiti speciali per i processi Edge:

Servizio Directory Descrizione
Router /etc/rc.d/init.d/functions

Il router perimetrale utilizza il router Nginx e richiede l'accesso in lettura a /etc/rc.d/init.d/functions.

Se il processo di sicurezza richiede di impostare le autorizzazioni su /etc/rc.d/init.d/functions, non impostarle su 700 altrimenti il router non si avvierà.

Puoi impostare le autorizzazioni su 744 per consentire l'accesso in lettura a /etc/rc.d/init.d/functions.
Zookeeper /dev/random La libreria client di Zookeeper richiede l'accesso in lettura al generatore di numeri casuali /dev/random. Se /dev/random è bloccato alla lettura, il servizio Zookeeper potrebbe non essere avviato.

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 perimetrale determina i nodi Cassandra in cui sono 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 dello heap Java in base alla memoria disponibile. Per saperne di più, consulta Ottimizzazione delle risorse Java in caso di peggioramento delle prestazioni o consumo elevato 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 per cloud privato imposti 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 nel 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 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 Message Processor:

  • Sui nodi Cassandra, imposta i limiti di memlock soft e hard, nofile e spazio degli indirizzi (as) 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 unlimited
apigee hard memlock unlimited
apigee soft nofile 32768
apigee hard nofile 65536
apigee soft as unlimited
apigee hard as unlimited
  • Sui 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 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 in qualsiasi momento.

Servizi di sicurezza di rete (NSS)

I servizi di sicurezza di rete (NSS) sono un insieme di librerie che supporta lo sviluppo di applicazioni client e server abilitate per la sicurezza. Devi assicurarti di aver installato NSS 3.19 o versioni successive.

Per controllare la tua versione corrente:

yum info nss

Per aggiornare NSS:

yum update nss

Per ulteriori informazioni, consulta 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 disabilitare la ricerca DNS su IPv6 quando utilizzi 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 Platform per RedHat/CentOS 7

Se stai installando Edge su RedHat 7 o CentOS 7 su Google Cloud Platform, devi disabilitare IPv6 su tutti i nodi Qpid.

Per istruzioni sulla disattivazione di IPv6, consulta la documentazione di RedHat o CentOS della tua versione specifica del sistema operativo. Ad esempio, puoi:

  1. Apri /etc/hosts in un editor.
  2. Inserisci un carattere "#" nella colonna una delle seguenti righe per inserire un commento: 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Salva il file.

AWS AMI

Se stai installando Edge su AWS Amazon Machine Image (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 fornita da EL5 o EL6.

awk

expr

libxlst

rpm

unzip

basename

grep

Lua-socket

rpm2cpio

aggiunta utente

bash

 nome host

ls

sed

wc

bc

id

net-tools

sudo

CANNOT TRANSLATE

curl

Libaio

perl (da procps)

catrame

Xerces-c
Cyrus-Sasl libdb4 pgrep (da procps) tr slurp

date

 libdb-cxx

ps

uuid

chkconfig
dirname libibverbi pwd Uname  
echo Librdmacm python    

ntpdate

Apigee consiglia di sincronizzare gli orari dei server. Se non è già configurata, l'utilità ntpdate potrebbe servire a questo scopo, verificando che i server siano sincronizzati con l'ora. Puoi utilizzare yum install ntp per installare l'utilità. Questo è particolarmente utile per replicare le configurazioni OpenLDAP. Tieni presente che il fuso orario del server è impostato in UTC.

openldap 2.4

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

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

Firewall e host virtuali

Il termine virtual viene comunemente sovraccaricato nell'ambito IT, ed è così che è associato ad Apigee Edge per il deployment di cloud privato e a host virtuali. Per chiarire, il termine virtual viene utilizzato principalmente in due modi:

  • Macchine virtuali (VM): non sono richieste, ma alcuni deployment utilizzano la tecnologia VM per creare server isolati per i componenti Apigee. Gli host delle VM, come quelli 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 siano diversi l'uno dall'altro nell'alias host o nella porta dell'interfaccia).

Proprio come esempio di denominazione, un singolo server fisico A potrebbe eseguire due VM, denominate "VM1" e "VM2". Supponiamo che "VM1" mostri un'interfaccia Ethernet virtuale, che viene denominata "eth0" all'interno della VM e a cui è assegnato l'indirizzo IP 111.111.111.111 dal macchinario di virtualizzazione o da un server DHCP di rete, quindi supponiamo che VM2 mostri un'interfaccia Ethernet virtuale anch'essa denominata "eth0" a cui viene assegnato un indirizzo IP 111.111.111.222.

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 in 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 (stesso nome e stessa porta esposte da VM1).

Il sistema operativo dell'host fisico potrebbe avere un firewall di rete; in questo caso, tale firewall deve essere configurato in modo da passare il traffico TCP associato 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 il traffico delle porte 80 e 443 per la connessione.

Il percorso base è il terzo componente coinvolto nell'instradamento delle chiamate API a diversi proxy API di cui potresti aver eseguito il deployment. I bundle proxy API possono condividere un endpoint se hanno percorsi di base diversi. Ad esempio, un percorso base può essere definito come http://api.mycompany.com:80/ e un altro definito come http://api.mycompany.com:80/salesdemo.

In questo caso, è necessario un bilanciatore del carico o un direttore del traffico di qualche tipo che suddivida 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 l'installazione specifica ed è configurata dal gruppo di networking locale.

Il percorso 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 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 /, gli utenti accederanno all'API tramite l'URL http://api.mycompany.com:80/.

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 /opt/apigee/customer/conf/license.txt.

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

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