Skip to main content
È disponibile una versione più recente di questo prodotto.
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Scopri il bilanciamento del carico di StorageGRID

PDF

Puoi usare il bilanciamento del carico per gestire i carichi di lavoro di ingest e recupero dai client S3.

${post_edited_translations.segment}

Quando un'applicazione client salva o recupera dati da un sistema StorageGRID, StorageGRID utilizza un bilanciatore del carico per gestire il carico di lavoro di acquisizione e recupero. Il bilanciamento del carico massimizza la velocità e la capacità di connessione distribuendo il carico di lavoro su più Storage Node.

Il servizio StorageGRID Load Balancer è installato su tutti i nodi di amministrazione e su tutti i nodi gateway e fornisce bilanciamento del carico Layer 7. Esegue la terminazione Transport Layer Security (TLS) delle richieste dei client, ispeziona le richieste e stabilisce nuove connessioni sicure ai nodi Storage.

Il servizio Load Balancer su ciascun nodo opera in modo indipendente durante l'inoltro del traffico client ai Storage Node. Attraverso un processo di ponderazione, il servizio Load Balancer instrada più richieste ai Storage Node con una maggiore disponibilità di CPU.

Nota Sebbene il servizio StorageGRID Load Balancer sia il meccanismo di bilanciamento del carico consigliato, potresti voler integrare un bilanciatore di carico di terze parti. Per informazioni, contatta il tuo NetApp account representative o consulta "Utilizza bilanciatori di carico di terze parti con StorageGRID".

Di quanti nodi di bilanciamento del carico hai bisogno?

Come best practice generale, ogni sito nel tuo sistema StorageGRID dovrebbe includere due o più nodi con il servizio Load Balancer. Ad esempio, un sito potrebbe includere due Gateway Node oppure sia un Admin Node che un Gateway Node. Assicurati che ci sia un'infrastruttura di rete, hardware o virtualizzazione adeguata per ogni nodo di bilanciamento del carico, che tu stia utilizzando servizi appliance, nodi bare metal o nodi basati su macchine virtuali (VM).

${post_edited_translations.segment}

Un endpoint del load balancer definisce la porta e il protocollo di rete (HTTPS o HTTP) che le richieste delle applicazioni client in entrata e in uscita utilizzeranno per accedere ai nodi che contengono il servizio Load Balancer. L'endpoint definisce anche il tipo di client (S3), la modalità di binding e, facoltativamente, un elenco di tenant consentiti o bloccati.

Per creare un endpoint del bilanciatore del carico, utilizza il Grid Manager oppure completa i wizard di setup di S3 e FabricPool:

Considerazioni sulla memorizzazione nella cache del bilanciatore di carico

La memorizzazione nella cache migliora significativamente le prestazioni quando un carico di lavoro opera su un sottoinsieme di dati e accede agli oggetti più volte. Inoltre, la memorizzazione nella cache consente l'accesso remoto allo storage a oggetti senza una completa implementazione della grid. La memorizzazione nella cache del load balancer è disponibile solo per i Gateway Nodes.

Quando crei gli endpoint del bilanciamento del carico:

  • Abilita la memorizzazione nella cache solo per i carichi di lavoro che sono memorizzabili nella cache. I carichi di lavoro che accedono ai dati non memorizzati nella cache più spesso dei dati memorizzati nella cache avranno prestazioni peggiori rispetto a quelli che non sarebbero stati gestiti dalla cache. In alcuni casi, i carichi di lavoro con elevati tassi di sovrascrittura e rimozione potrebbero anche superare la durata di scrittura garantita dell'unità.

  • Valuta di aggiungere ulteriori endpoint o nodi per la memorizzazione nella cache dei singoli carichi di lavoro che sono buoni candidati per la cache.

  • Usa endpoint distinti per i carichi di lavoro memorizzabili nella cache e per quelli non memorizzabili nella cache. Questa separazione garantisce che i meccanismi di caching vengano applicati correttamente e non interferiscano con l'elaborazione dei dati non memorizzabili nella cache.

  • Valuta un potenziale carico di lavoro memorizzabile nella cache indirizzandolo all'endpoint abilitato alla cache. Monitora e verifica il tasso di cache hit per determinare l'idoneità del carico di lavoro per la memorizzazione nella cache. Questa valutazione aiuta a ottimizzare le prestazioni e a garantire un uso efficiente delle risorse di cache.

  • "${post_edited_translations.segment}" per determinare se un carico di lavoro esistente sia un buon candidato per la memorizzazione nella cache. Per un determinato periodo di tempo, determina quale percentuale di GET è per oggetti univoci. Per essere adatto alla memorizzazione nella cache, questo valore deve essere inferiore al 50%.

Esempi di carichi di lavoro che potrebbero essere buoni candidati per la memorizzazione nella cache

  • Data lake

  • ${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • asset management multimediale

  • Produzione video

Nota

  • È possibile memorizzare nella cache più versioni di un oggetto.

  • Sono supportate le operazioni di lettura di intervalli.

Esempi di carichi di lavoro che non sono buoni candidati per la memorizzazione nella cache

  • FabricPool

  • ${post_edited_translations.segment}

  • Tiering dello storage

Avvertenza Se un qualsiasi contenuto che deve essere fornito dalla cache richiede la crittografia a riposo, "abilita la crittografia del nodo o dell'unità" sul nodo di cache.

Tipi di oggetti e richieste che non verranno memorizzati nella cache

  • Il response-content-encoding parametro di query

  • Il partNumber parametro di query

  • ${post_edited_translations.segment}

    • If-Match

    • If-Modified-Since

    • If-None-Match

    • If-Unmodified-Since

  • ${post_edited_translations.segment}

    • ${post_edited_translations.segment}

    • SSE-C (crittografia lato server con chiavi fornite dal cliente)

    • ${post_edited_translations.segment}

Tutte le richieste che non sono memorizzate nella cache vengono inoltrate a un LDR a monte come se la cache non fosse abilitata.

Informazioni correlate

Considerazioni per la porta

La porta per un endpoint del bilanciatore del carico ha come valore predefinito 10433 per il primo endpoint che crei, ma puoi specificare qualsiasi porta esterna inutilizzata tra 1 e 65535. Se usi la porta 80 o 443, l'endpoint utilizzerà il servizio di bilanciamento del carico solo sui nodi Gateway. Queste porte sono riservate sui nodi Admin. Se usi la stessa porta per più di un endpoint, devi specificare una modalità di associazione diversa per ciascun endpoint.

Le porte utilizzate da altri servizi di grid non sono consentite. Vedi "Porte interne di StorageGRID".

Considerazioni sul protocollo di rete

Nella maggior parte dei casi, le connessioni tra le applicazioni client e StorageGRID dovrebbero utilizzare la crittografia Transport Layer Security (TLS). La connessione a StorageGRID senza crittografia TLS è supportata ma non consigliata, in particolare negli ambienti di produzione. Quando selezioni il protocollo di rete per l'endpoint del bilanciatore del carico di StorageGRID, dovresti selezionare HTTPS.

Considerazioni relative ai certificati degli endpoint del bilanciatore di carico

Se selezioni HTTPS come protocollo di rete per l'endpoint del bilanciatore del carico, devi fornire un certificato di sicurezza. Puoi utilizzare una qualsiasi di queste tre opzioni quando crei l'endpoint del bilanciatore del carico:

  • Carica un certificato firmato (consigliato). Questo certificato può essere firmato da un'autorità di certificazione (CA) pubblica attendibile o privata. L'utilizzo di un certificato server CA pubblico attendibile per proteggere la connessione è la best practice. A differenza dei certificati generati, i certificati firmati da una CA possono essere ruotati senza interruzioni, il che può aiutare a evitare problemi di scadenza.

    Devi ottenere i seguenti file prima di creare l'endpoint del bilanciamento del carico:

    • ${post_edited_translations.segment}

    • Il file della chiave privata del certificato server personalizzato.

    • Facoltativamente, un pacchetto CA dei certificati di ciascuna autorità di certificazione emittente intermedia.

  • ${post_edited_translations.segment}

  • Usa il certificato S3 globale di StorageGRID. Devi caricare o generare una versione personalizzata di questo certificato prima di poterlo selezionare per l'endpoint del bilanciamento del carico. Consulta "Configura i certificati API S3".

Di quali valori hai bisogno?

Per creare il certificato, devi conoscere tutti i nomi di dominio e gli indirizzi IP che le applicazioni client S3 utilizzeranno per accedere all'endpoint.

La voce Subject DN (Distinguished Name) del certificato deve includere il fully qualified domain name che l'applicazione client utilizzerà per StorageGRID. Ad esempio:

Subject DN: /C=Country/ST=State/O=Company,Inc./CN=s3.storagegrid.example.com

Come richiesto, il certificato può utilizzare caratteri jolly per rappresentare i fully qualified domain names di tutti i nodi Admin e Gateway che eseguono il servizio Load Balancer. Ad esempio, *.storagegrid.example.com usa il carattere jolly * per rappresentare adm1.storagegrid.example.com e gn1.storagegrid.example.com.

Se vuoi utilizzare richieste in stile S3 virtual hosted, il certificato deve includere anche una voce Nome alternativo per ogni "domain name endpoint S3" che hai configurato, inclusi eventuali nomi wildcard. Per esempio:

Alternative Name: DNS:*.s3.storagegrid.example.com
Nota Se usi i caratteri jolly per i domain name, rivedi il "${post_edited_translations.segment}".

${post_edited_translations.segment}

${post_edited_translations.segment}

Avvertenza Se il certificato utilizzato per proteggere la connessione tra l'applicazione S3 e StorageGRID scade, l'applicazione potrebbe perdere temporaneamente l'accesso a StorageGRID.

${post_edited_translations.segment}

  • Monitora attentamente tutti gli avvisi che segnalano l'imminente scadenza dei certificati, come gli avvisi Expiration of load balancer endpoint certificate e Expiration of global server certificate for S3 API.

  • Mantieni sempre sincronizzate le versioni del certificato di StorageGRID e dell'applicazione S3. Se sostituisci o rinnovi il certificato utilizzato per un endpoint del bilanciatore di carico, devi sostituire o rinnovare anche il certificato equivalente utilizzato dall'applicazione S3.

  • Utilizza un certificato CA firmato pubblicamente. Se utilizzi un certificato firmato da una CA, puoi sostituire i certificati in scadenza senza interruzioni.

  • ${post_edited_translations.segment}

Considerazioni sulla modalità di binding

La modalità di binding ti consente di controllare quali indirizzi IP possono essere utilizzati per accedere a un endpoint del bilanciatore del carico. Se un endpoint utilizza una modalità di binding, le applicazioni client possono accedere all'endpoint solo se utilizzano un indirizzo IP consentito o il corrispondente fully qualified domain name (FQDN). Le applicazioni client che utilizzano qualsiasi altro indirizzo IP o FQDN non possono accedere all'endpoint.

Puoi specificare una delle seguenti modalità di associazione:

  • Global (predefinito): le applicazioni client possono accedere all'endpoint utilizzando l'indirizzo IP di qualsiasi Gateway Node o Admin Node, l'indirizzo virtual IP (VIP) di qualsiasi gruppo HA su qualsiasi rete o un FQDN corrispondente. Utilizza questa impostazione a meno che tu non debba limitare l'accessibilità di un endpoint.

  • Indirizzi IP virtuali dei gruppi HA. Le applicazioni client devono utilizzare un indirizzo IP virtuale (o il corrispondente FQDN) di un gruppo HA.

  • Interfacce dei nodi. I client devono utilizzare gli indirizzi IP (o i corrispondenti FQDN) delle interfacce dei nodi selezionate.

  • Tipo di nodo. In base al tipo di nodo selezionato, i client devono utilizzare l'indirizzo IP (o il corrispondente FQDN) di un qualsiasi Admin Node oppure l'indirizzo IP (o il corrispondente FQDN) di un qualsiasi Gateway Node.

Considerazioni per l'accesso del tenant

L'accesso dei tenant è una funzionalità di sicurezza opzionale che ti permette di controllare quali StorageGRID tenant account possono usare un endpoint del bilanciatore di carico per accedere ai propri bucket. Puoi consentire a tutti i tenant di accedere a un endpoint (impostazione predefinita), oppure puoi specificare un elenco di tenant autorizzati o bloccati per ciascun endpoint.

Puoi usare questa funzionalità per offrire un migliore isolamento di sicurezza tra i tenant e i loro endpoint. Ad esempio, potresti usarla per assicurarti che i materiali top-secret o altamente classificati di proprietà di un tenant restino completamente inaccessibili agli altri tenant.

Nota Ai fini del controllo degli accessi, il tenant viene determinato dalle chiavi di accesso utilizzate nella richiesta del client; se non vengono fornite chiavi di accesso come parte della richiesta (come nel caso di accesso anonimo), viene utilizzato il proprietario del bucket per determinare il tenant.

Esempio di accesso tenant

Per capire come funziona questa funzionalità di sicurezza, considera il seguente esempio:

  1. Hai creato due endpoint di bilanciamento del carico, come segue:

    • Endpoint pubblico: usa la porta 10443 e permette l'accesso a tutti i tenant.

    • Endpoint Top secret: utilizza la porta 10444 e consente l'accesso solo al tenant Top secret. Tutti gli altri tenant non possono accedere a questo endpoint.

  2. Il top-secret.pdf si trova in un bucket di proprietà del tenant Top secret.

Per accedere a top-secret.pdf, un utente nel tenant Top secret può inviare una richiesta GET a https://w.x.y.z:10444/top-secret.pdf. Poiché a questo tenant è consentito utilizzare l'endpoint 10444, l'utente può accedere all'oggetto. Tuttavia, se un utente appartenente a qualsiasi altro tenant invia la stessa richiesta allo stesso URL, riceve un messaggio immediato di Access Denied. L'accesso viene negato anche se le credenziali e la firma sono valide.

disponibilità CPU

Il servizio Load Balancer su ciascun Admin Node e Gateway Node opera in modo indipendente durante l'inoltro del traffico S3 agli Storage Node. Attraverso un processo di ponderazione, il servizio Load Balancer instrada un maggior numero di richieste agli Storage Node con maggiore disponibilità di CPU. Le informazioni sul carico della CPU dei nodi vengono aggiornate ogni pochi minuti, ma la ponderazione potrebbe essere aggiornata con maggiore frequenza. A tutti gli Storage Node viene assegnato un valore di peso base minimo, anche se un nodo segnala un utilizzo del 100% o non segnala affatto il proprio utilizzo.

${post_edited_translations.segment}