Skip to main content
How to enable StorageGRID in your environment
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Informazioni sui bilanciatori del carico dei gestori del traffico locali

Collaboratori

Esplora le linee guida per i bilanciatori del carico del gestore del traffico locale e determina la configurazione ottimale.

Quanto segue viene presentato come guida generale per la configurazione dei sistemi di bilanciamento del carico di terze parti. Collabora con l'amministratore del sistema di bilanciamento del carico per determinare la configurazione ottimale per il tuo ambiente.

Creare un gruppo di risorse di nodi di archiviazione

Raggruppare i nodi di storage StorageGRID in un pool di risorse o in un gruppo di servizi (la terminologia potrebbe differire con specifici bilanciatori del carico). I nodi storage StorageGRID presentano l'API S3 sulle seguenti porte:

  • S3 HTTPS: 18082

  • S3 HTTP: 18084

La maggior parte dei clienti sceglie di presentare le API sul server virtuale tramite le porte HTTPS e HTTP standard (443 e 80).

Nota Ogni sito StorageGRID richiede un'impostazione predefinita di tre nodi storage, due dei quali devono essere integri.

Controllo dello stato di salute

I sistemi di bilanciamento del carico di terze parti richiedono un metodo per determinare lo stato di salute di ogni nodo e la sua idoneità a ricevere il traffico. NetApp consiglia di utilizzare il metodo HTTP OPTIONS per eseguire il controllo dello stato di salute. Il bilanciamento del carico invia richieste HTTP OPTIONS a ogni singolo nodo di storage e prevede una 200 risposta di stato.

Se un nodo di archiviazione non fornisce una 200 risposta, tale nodo non è in grado di eseguire il servizio delle richieste di archiviazione. I requisiti dell'applicazione e dell'azienda devono determinare il timeout per questi controlli e l'azione intrapresa dal bilanciamento del carico.

Ad esempio, se tre dei quattro nodi storage del data center 1 non sono attivi, è possibile indirizzare tutto il traffico al data center 2.

L'intervallo di polling consigliato è una volta al secondo, contrassegnando il nodo offline dopo tre controlli non riusciti.

Esempio di controllo dello stato di salute di S3

Nell'esempio seguente, inviamo OPTIONS e controlliamo 200 OK. Lo utilizziamo OPTIONS perché Amazon S3) non supporta richieste non autorizzate.

curl -X OPTIONS https://10.63.174.75:18082 --verbose --insecure
* Rebuilt URL to: https://10.63.174.75:18082/
*   Trying 10.63.174.75...
* TCP_NODELAY set
* Connected to 10.63.174.75 (10.63.174.75) port 18082 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: webscale.stl.netapp.com
* Server certificate: NetApp Corp Issuing CA 1
* Server certificate: NetApp Corp Root CA
> OPTIONS / HTTP/1.1
> Host: 10.63.174.75:18082
> User-Agent: curl/7.51.0
> Accept: /
>
< HTTP/1.1 200 OK
< Date: Mon, 22 May 2017 15:17:30 GMT
< Connection: KEEP-ALIVE
< Server: StorageGRID/10.4.0
< x-amz-request-id: 3023514741

Controlli dello stato di salute basati su file o contenuti

In generale, NetApp non consiglia controlli dello stato di salute basati su file. In genere, un file di piccole dimensioni —healthcheck.htm, ad esempio, viene creato in un bucket con un criterio di sola lettura. Questo file viene quindi recuperato e valutato dal bilanciamento del carico. Questo approccio presenta diversi svantaggi:

  • Dipendente da un unico conto. Se l'account proprietario del file è disattivato, il controllo di integrità non riesce e non vengono elaborate richieste di archiviazione.

  • Regole per la protezione dei dati. Lo schema di protezione dei dati predefinito è un approccio a due copie. In questo scenario, se i due nodi storage che ospitano il file di controllo dello stato di salute non sono disponibili, il controllo dello stato di salute non riesce e le richieste di storage non vengono inviate ai nodi storage sani, rendendo la griglia offline.

  • Registro di controllo bloat. Il bilanciamento del carico recupera il file da ogni nodo storage ogni X minuti, creando molte voci di registro di controllo.

  • Uso intensivo delle risorse. Il recupero del file di controllo dello stato da ogni nodo ogni pochi secondi consuma le risorse della rete e della griglia.

Se è necessario un controllo dello stato di salute basato sul contenuto, utilizzare un tenant dedicato con un bucket S3 dedicato.

Persistenza della sessione

La persistenza della sessione, o stickiness, si riferisce al tempo in cui una data sessione HTTP può persistere. Per impostazione predefinita, le sessioni vengono interrotte dai nodi storage dopo 10 minuti. Una persistenza più lunga può portare a performance migliori, perché le applicazioni non devono ristabilire le sessioni per ogni azione; tuttavia, mantenendo queste sessioni aperte si consumano le risorse. Se ritieni che il tuo carico di lavoro trarrà beneficio, puoi ridurre la persistenza della sessione su un bilanciamento del carico di terze parti.

Indirizzamento virtuale in stile host

Lo stile in hosting virtuale è ora il metodo predefinito per AWS S3 e, sebbene StorageGRID e molte applicazioni supportino ancora lo stile del percorso, è consigliabile implementare il supporto in stile in hosting virtuale. Le richieste in stile host virtuale hanno il bucket come parte del nome host.

Per supportare lo stile host virtuale, procedere come segue:

  • Supporta ricerche DNS con caratteri jolly: *.s3.company.com

  • Utilizzare un certificato SSL con nomi alt del soggetto per supportare i caratteri jolly: *.s3.company.com alcuni clienti hanno espresso preoccupazioni per la sicurezza riguardo all'uso dei certificati jolly. StorageGRID continua a supportare l'accesso in stile percorso, così come le applicazioni chiave come FabricPool. Detto questo, alcune chiamate API S3 non riescono o si comportano in modo errato senza supporto di hosting virtuale.

Terminazione SSL

La terminazione SSL dei sistemi di bilanciamento del carico di terze parti offre vantaggi in termini di sicurezza. Se il bilanciamento del carico è compromesso, la griglia viene suddivisa in comparti.

Sono disponibili tre configurazioni supportate:

  • Pass-through SSL. Il certificato SSL viene installato su StorageGRID come certificato server personalizzato.

  • Terminazione SSL e nuova crittografia (consigliata). Ciò potrebbe essere utile se si sta già eseguendo la gestione dei certificati SSL sul sistema di bilanciamento del carico piuttosto che installare il certificato SSL su StorageGRID. Questa configurazione offre un ulteriore vantaggio in termini di sicurezza nel limitare la superficie di attacco al bilanciatore del carico.

  • Terminazione SSL con HTTP. In questa configurazione, SSL viene terminato sul bilanciamento del carico di terze parti e la comunicazione dal bilanciamento del carico a StorageGRID non è crittografata per sfruttare il off-load SSL (con librerie SSL incorporate nei processori moderni questo è di limitato beneficio).

Configurazione pass-through

Se si preferisce configurare il bilanciamento del carico per il pass-through, è necessario installare il certificato su StorageGRID. Andare al Configurazione › certificati server › certificato server endpoint del servizio API di archiviazione oggetti.

Visibilità IP del client di origine

StorageGRID 11,4 ha introdotto il concetto di un sistema di bilanciamento del carico di terze parti affidabile. Per inoltrare l'IP dell'applicazione client a StorageGRID, è necessario configurare questa funzione. Per ulteriori informazioni, vedere "Come configurare StorageGRID per il funzionamento con sistemi di bilanciamento del carico Layer 7 di terze parti."

Per abilitare l'intestazione XFF per la visualizzazione dell'IP dell'applicazione client, attenersi alla seguente procedura:

Fasi

  1. Registrare l'IP del client nel registro di controllo.

  2. Utilizzare aws:SourceIp criteri di gruppo o bucket S3.

Strategie di bilanciamento del carico

La maggior parte delle soluzioni di bilanciamento del carico offre molteplici strategie per il bilanciamento del carico. Le seguenti sono strategie comuni:

  • Rotondi. Un adattamento universale ma soffre di pochi nodi e grandi trasferimenti che ostruiscono i singoli nodi.

  • Connessione minima. Ideale per workload di oggetti piccoli e misti, con una distribuzione equa delle connessioni a tutti i nodi.

La scelta dell'algoritmo diventa meno importante con un numero crescente di nodi storage tra cui scegliere.

Percorso dei dati

Tutti i flussi di dati attraverso i bilanciatori del carico del gestore del traffico locale. StorageGRID non supporta il routing diretto del server (DSR).

Verifica della distribuzione dei collegamenti

Per verificare che il metodo in uso distribuisca il carico in modo uniforme tra i nodi storage, controllare le sessioni stabilite su ciascun nodo in un determinato sito:

  • Metodo UI. Andare al supporto › metriche › Panoramica S3 › sessioni HTTP LDR

  • API metriche. Uso storagegrid_http_sessions_incoming_currently_established