Requisiti di installazione

Requisiti hardware

Devi soddisfare i seguenti requisiti hardware minimi per un'infrastruttura a disponibilità elevata in un ambiente di livello di produzione.

Il seguente video fornisce indicazioni generali sulle dimensioni per l'installazione:

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.

Componente di installazione RAM CPU Hard disk minimo
Cassandra (autonomo) 16 GB 8 core 250 GB di spazio di archiviazione locale con SSD che supporta 2000 IOPS
Cassandra/Zookeeper sulla stessa macchina 16 GB 8 core 250 GB di spazio di archiviazione locale con SSD che supporta 2000 IOPS
Processore/router di messaggi sulla stessa macchina 16 GB 8 core 100GB
Processore di messaggi (autonomo) 16 GB 8 core 100GB
Router (autonomo) 8 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, che supporti 1000 IOPS o più*
Analytics - Postgres master o standby autonomo 16GB* 8 core* Spazio di archiviazione di rete da 500 GB a 1 TB*****, preferibilmente con backend SSD, che supporti 1000 IOPS o più*
Analytics - Qpid (standalone) 8 GB 4 core 30-50 GB di spazio di archiviazione locale 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.
SymasLDAP/UI/Management Server 8 GB 4 core 60 GB
Server di gestione/UI 4 GB 2 core 60 GB
SymasLDAP (autonomo) 4 GB 2 core 60 GB

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

  • Meno di 250 TPS: è possibile prendere in considerazione 8 GB, 4 core con spazio di archiviazione di rete gestito*** che supporta 1000 IOPS o più
  • Superiore a 250 TPS: 16 GB, 8 core, spazio di archiviazione di rete gestito*** che supporta 1000 IOPS o più
  • Maggiore di 1000 TPS: 16 GB, 8 core, spazio di archiviazione di rete gestito*** che supporta 2000 IOPS o più
  • Superiore a 2000 TPS: 32 GB, 16 core, spazio di archiviazione di rete gestito*** che supporta 2000 IOPS o più
  • Superiore a 4000 TPS: 64 GB, 32 core, spazio di archiviazione di rete gestito*** che supporta 4000 IOPS o più

** Il valore del disco rigido Postgres si basa sull'analisi predefinita acquisita da Edge. Se aggiungi valori personalizzati ai dati di analisi, questi valori devono essere aumentati di conseguenza. Utilizza la seguente formula per stimare lo spazio di archiviazione necessario:

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

*** Lo spazio di archiviazione di rete è consigliato per il database PostgreSQL perché:

  • Consente di aumentare dinamicamente la dimensione dello spazio di archiviazione se e quando necessario.
  • Gli IOPS di rete possono essere regolati al volo nella maggior parte dei sottosistemi di ambiente/archiviazione/rete attuali.
  • Gli snapshot a livello di archiviazione possono essere attivati nell'ambito delle soluzioni di backup e ripristino.

Inoltre, di seguito sono elencati i requisiti hardware se vuoi installare i servizi di monetizzazione (non supportati nell'installazione all-in-one):

Componente con monetizzazione RAM CPU Hard disk
Server di gestione (con servizi di monetizzazione) 8 GB 4 core 60 GB
Analytics - Postgres/Qpid sullo stesso server 16 GB 8 core Archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti 1000 IOPS o valori superiori oppure utilizza la regola della tabella precedente.
Analytics - Postgres master o standby autonomo 16 GB 8 core Archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti 1000 IOPS o valori superiori oppure utilizza la regola della tabella precedente.
Analytics - Qpid (standalone) 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, è consigliato un HDD con spazio di archiviazione locale che supporti 1000 IOPS.

Requisiti di larghezza di banda della rete Cassandra

Cassandra utilizza il protocollo Gossip per scambiare informazioni con altri nodi sulla topologia di rete. L'utilizzo di Gossip, combinato con la natura distribuita di Cassandra, che prevede la comunicazione con più nodi per le operazioni di lettura e scrittura, comporta un trasferimento significativo di dati sulla rete.

Cassandra richiede una larghezza di banda di rete minima di 1 Gbps per nodo. Per le installazioni di produzione, è consigliata una larghezza di banda maggiore.

La latenza massima o del 99° percentile per Cassandra deve essere inferiore a 100 millisecondi.

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

Prerequisito: attiva il repository EPEL

Prima di procedere con l'installazione, assicurati che il repository EPEL (Extra Packages for Enterprise Linux) sia abilitato. Utilizza i seguenti comandi in base alla versione del sistema operativo:

  • Per Red Hat/CentOS/Oracle 8.X: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
     
    sudo rpm -ivh epel-release-latest-8.noarch.rpm
  • Per Red Hat/CentOS/Oracle 9.X: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
     
    sudo rpm -ivh epel-release-latest-9.noarch.rpm

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 la variabile di ambiente JAVA_HOME punti alla radice dell'JDK per l'utente che esegue l'installazione.

SELinux

A seconda delle impostazioni di SELinux, Edge può 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.

Creazione dell'utente "apigee"

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

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

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

Prima di creare il collegamento 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 collegamento simbolico, esegui questi passaggi prima di scaricare il file bootstrap_4.53.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 di Edge.

  3. Modifica la proprietà della radice di installazione e del collegamento simbolico all'utente "apigee": 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

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 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 Riferimento al file di configurazione edge.

TCP Wrappers

TCP Wrappers può bloccare la comunicazione di alcune porte e influire sull'installazione di SymasLDAP, Postgres e Cassandra. Su questi nodi, controlla /etc/hosts.allow e /etc/hosts.deny per assicurarti che non ci siano limitazioni delle porte per le porte richieste SymasLDAP, Postgres e Cassandra.

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

Accesso alla directory

La seguente tabella elenca le directory sui nodi Edge che hanno requisiti speciali dai processi Edge:

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

L'Edge Router utilizza il router Nginx e richiede 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à.

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 Zookeeper richiede l'accesso in lettura al generatore di numeri casuali /dev/random. Se /dev/random è bloccato in lettura, il servizio Zookeeper potrebbe non avviarsi.

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ù, consulta Ottimizzazione delle risorse Java in caso di calo delle prestazioni o elevato consumo di memoria.

Dopo aver installato Edge for Private Cloud, 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 il cloud privato 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

Configurazione delle impostazioni internazionali per Rocky 9.X

Se utilizzi Rocky 9.X, assicurati che il sistema sia configurato con LANG=en_US.utf8 nelle impostazioni internazionali a livello di sistema. Per configurare questa impostazione, esegui i seguenti comandi:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

Limiti del sistema

Assicurati di aver impostato i seguenti limiti di sistema sui nodi Cassandra e Message Processor:

  • Sui nodi Cassandra, imposta i limiti soft e hard di memlock, nofile e spazio di 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
apigee soft nproc 32768
apigee hard nproc 65536
  • Nei nodi Message Processor, 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 contemporaneamente.

  • Se visualizzi il seguente errore in un router o in un processore di messaggi system.log, i limiti dei descrittori di file potrebbero essere impostati su un valore troppo basso:

    "java.io.IOException: Too many open files"

    Puoi controllare i limiti utente eseguendo:

    # su - apigee
$ ulimit -n
100000

    Se continui a raggiungere i limiti di file aperti dopo aver impostato i limiti dei descrittori di file su 100000, apri un ticket con l'assistenza Apigee Edge per ulteriore risoluzione dei problemi.

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

Disattivare IPv6 su RHEL 8 e versioni successive

Se installi Edge su RHEL 8 o versioni successive su Google Cloud Platform, devi disattivare IPv6 su tutti i nodi Qpid.

Per istruzioni sulla disattivazione di IPv6, consulta la documentazione fornita dal fornitore del sistema operativo. Ad esempio, puoi trovare informazioni pertinenti nella documentazione di Red Hat Enterprise Linux.

Strumenti

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

awk

expr

libxslt

rpm

decomprimere

basename

grep

lua-socket

rpm2cpio

useradd

bash

 nome host

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

libaio

perl (da procps)

tar

xerces-c
cyrus-sasl libdb4 pgrep (da procps) tr Slurp

data

 libdb-cxx

ps

uuid

chkconfig
dirname libibverbs pwd uname  
echo librdmacm python    

Sincronizzazione dell'ora

Apigee consiglia di sincronizzare l'ora dei server. Se non è già configurato, l'utilità ntpdate o uno strumento equivalente può servire a questo scopo verificando se i server sono sincronizzati con l'ora. Ad esempio, puoi utilizzare yum install ntp o un comando equivalente per installare l'utilità. Ciò è particolarmente utile per replicare le configurazioni LDAP. Tieni presente che devi impostare il fuso orario del server su UTC.

Firewall e host virtuali

Il termine virtual viene comunemente sovraccaricato nell'ambito IT, così come per un'implementazione di Apigee Edge for Private Cloud e per gli host virtuali. Per chiarire, il termine virtual viene utilizzato principalmente in due modi:

  • 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 di 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 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 relativa 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 che 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/.

Licenze

Ogni installazione di Edge richiede un file di licenza univoco che ottieni da Apigee. 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 /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.