Requisiti di installazione

Requisiti hardware

Devi soddisfare i seguenti requisiti minimi per l'hardware per un'infrastruttura altamente disponibile in un ambiente di produzione.

Il seguente video fornisce indicazioni generali sulle dimensioni dell'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 richiesto dal 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.

Componente di installazione RAM CPU Numero minimo di dischi rigidi
Cassandra 16 GB 8 core 250 GB di spazio di archiviazione locale con SSD che supporta 2000 IOPS
Processore di messaggi/router sulla stessa macchina 16 GB 8 core 100 GB
Message Processor (autonomo) 16 GB 8 core 100GB
Router (autonomo) 16 GB 8 core 100GB
Analytics - Postgres/Qpid sullo stesso server 16 GB* 8 core* 500 GB-1 TB** di spazio di archiviazione di rete***, preferibilmente con backend SSD, supporto di 1000 IOPS o superiore*
Analytics - Master o standby Postgres (autonomo) 16 GB* 8 core* Spazio di archiviazione di rete*** da 500 GB a 1 TB**, preferibilmente con backend SSD, supportante 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, ma può essere aumentata a 2 GB. Se hai bisogno una maggiore capacità, aggiungi altri nodi Qpid.
OpenLDAP/UI/Server di gestione 8 GB 4 core 60 GB
Server di gestione/UI 4 GB 2 core 60 GB
OpenLDAP (autonomo) 4 GB 2 core 60 GB

* Modifica i requisiti di sistema di Postgres in base al throughput:

  • Meno di 250 TPS: 8 GB, 4 core possono essere considerati con la rete gestita spazio di archiviazione*** che supporta 1000 IOPS o più
  • Più di 250 TPS: spazio di archiviazione di rete gestito, 8 core, 16 GB*** supportando 1000 IOPS o superiori
  • Più di 1000 TPS: spazio di archiviazione di rete gestito, 8 core, 16 GB*** supportando 2000 IOPS o superiori
  • Più di 2000 TPS: spazio di archiviazione di rete gestito, 16 core, 32 GB*** supportando 2000 IOPS o superiori
  • Più di 4000 TPS: spazio di archiviazione di rete gestito, 64 GB, 32 core*** supportando 4000 IOPS o superiori

** Il valore del disco rigido Postgres si basa sugli analytics out of the box acquisiti 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 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

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

  • Consente di fare lo scale up dinamico delle dimensioni dello spazio di archiviazione se e quando obbligatorio.
  • Le IOPS di rete possono essere regolate in tempo reale nella maggior parte dei subsistemi di ambiente/archiviazione/rete di oggi.
  • Gli snapshot a livello di archiviazione possono essere abilitati come parte del backup e ripristino soluzioni.

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

Componente con monetizzazione RAM CPU Disco rigido
Management Server (con servizi di monetizzazione) 8 GB 4 core 60 GB
Analytics - Postgres/Qpid sullo stesso server 16 GB 8 core 500 GB - 1 TB di spazio di archiviazione di rete, preferibilmente con backend SSD, con supporto di 1000 IOPS o utilizza la regola della tabella precedente.
Analytics - Postgres master o standby standalone 16 GB 8 core Spazio di archiviazione di rete da 500 GB a 1 TB, preferibilmente con backend SSD, che supporti 1000 IOPS o più oppure utilizza la regola riportata nella tabella precedente.
Analytics - Qpid standalone 8 GB 4 core 40-500 GB di spazio di archiviazione locale con SSD o HDD veloce

Per installazioni superiori a 250 TPS, è consigliato un HDD con archiviazione locale che supporti 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 sulla sistemi operativi e software di terze parti elencati nella Software supportati e versioni supportate.

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 la variabile d'ambiente JAVA_HOME indichi la radice del 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 Componenti periferici. Se necessario, puoi disattivare SELinux o impostarlo in modalità permissiva durante l'installazione, quindi riattivarlo al termine dell'installazione. Per saperne di più, vedi Installare l'utilità apigee-setup Edge.

Creazione dell''apigee' utente

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 come utente diverso.

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. Sebbene non sia possibile 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 prima creare un utente e un gruppo denominati "apigee". Si tratta dello stesso gruppo e dello stesso utente creati dall'installatore di Edge.

Per creare il collegamento simbolico, eseguire questi passaggi prima di scaricare il file bootstrap_4.50.00.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 home directory di installazione che preferisci: 
    ln -Ts /srv/myInstallDir /opt/apigee

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

  3. Modifica la proprietà della directory principale dell'installazione e del link 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. L'installatore si aspetta 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 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 comando "hostname -i" restituisce un elenco di indirizzi IP separati da spazi. 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". Per ulteriori informazioni, consulta la sezione Riferimento file di configurazione Edge.

Wrapper TCP

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 restrizioni per le porte obbligatorie OpenLDAP, Postgres e Cassandra.

iptables

Verifica che non esistano criteri iptables che impediscono la connettività tra i nodi sul porte perimetrali richieste. Se necessario, puoi interrompere 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 Edge che hanno requisiti speciali per i processi Edge:

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

Il router Edge utilizza il router Nginx e richiede 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 l'avvio non riesce.

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 in lettura, il servizio Zookeeper potrebbe non riuscire ad avviarsi.

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 saperne di più, consulta Informazioni sul fattore di replica e sul livello di coerenza di Cassandra.

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

Dopo aver installato Edge for Private Cloud, puoi verificare che Cassandra sia configurata 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 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, creane uno.

  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:

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

    Per ulteriori informazioni, consulta Impostazioni di produzione consigliate nella documentazione di Apache Cassandra.

  • 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 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 un processore di messaggi system.log, è possibile che i limiti per il descrittore del file siano troppo bassi:

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

    Per controllare i limiti di utenti:

    # su - apigee
$ ulimit -n
100000

    Se stai ancora raggiungendo i limiti relativi ai file aperti dopo aver impostato i limiti del descrittore dei 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 supporta lo sviluppo di con applicazioni client e server abilitate alla sicurezza. Assicurati di aver installato NSS v3.19 o versioni successive.

Per controllare la versione corrente:

yum info nss

Per aggiornare NSS:

yum update nss

Consulta questo articolo. di RedHat per ulteriori informazioni.

Disattiva 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 esegui due ricerche DNS: una per IPv4 e una per IPv6. Devi disattivare la ricerca DNS su IPv6 quando utilizzando 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 RedHat o CentOS della 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 carattere "#" nella colonna 1 della riga seguente per commentarla: 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Salva il file.

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

awk

expr

libxslt

rpm

decomprimere

basename

grep

socket-lua

rpm2cpio

useradd

bash

 nome host

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

Libio

perl (da procps)

catrame

xerces-c
Cyrus-Sasl libdb4 pgrep (da procps) tr Slurp

data

 libdb-cxx

ps

Uuid

chkconfig
dirname libibverbs pwd Uname  
echo librdmacm python    

ntpdate

Apigee consiglia di sincronizzare l'ora dei server. Se non è già configurato, l'utilità ntpdate potrebbe essere utile 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 server dispone di una connessione 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 per quelle con 12 host con due data center, è necessaria la replica di 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 obbligatorie, ma alcuni implementazioni 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 (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, denominate "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 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 di quella esposta 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 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 propria interfaccia eth0 e anche questi devono consentire la connessione del traffico delle porte 80 e 443.

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 percorsi di base diversi. Ad esempio, un percorso 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 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 base viene impostato quando esegui il deployment di un'API. Dall'esempio precedente, puoi implementare 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 arrivo.

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 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 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 di Apigee Edge per i dettagli sulla migrazione.

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