Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Disponibilità e durabilità: file system Single-AZ e Multi-AZ

Amazon FSx for Windows File Server offre due tipi di implementazione di file system: Single-AZ e Multi-AZ. Le seguenti sezioni forniscono informazioni per aiutarti a scegliere il tipo di implementazione giusto per i tuoi carichi di lavoro. Per informazioni sulla disponibilità del servizio SLA (Service Level Agreement), consulta Amazon FSx Service Level Agreement.

I file system Single-AZ sono composti da una singola istanza di file server Windows e da un set di volumi di storage all'interno di un'unica zona di disponibilità (AZ). Con i file system Single-AZ, i dati vengono replicati automaticamente per proteggerli dal guasto di un singolo componente nella maggior parte dei casi. Amazon monitora FSx continuamente i guasti hardware e ripristina automaticamente gli eventi di guasto sostituendo il componente dell'infrastruttura guasto. I file system Single-AZ sono offline, in genere per meno di 20 minuti, durante questi eventi di ripristino in caso di guasto e durante la manutenzione pianificata del file system all'interno della finestra di manutenzione configurata per il file system. Con i file system Single-AZ, l'errore del file system può essere irreversibile in rari casi, ad esempio a causa di guasti di più componenti o a causa di un errore non graduale del singolo file server che lascia il file system in uno stato incoerente, nel qual caso è possibile ripristinare il file system dal backup più recente.

I file system Multi-AZ sono composti da un cluster ad alta disponibilità di file server Windows distribuiti su due AZs (una AZ preferita e una AZ in standby), che sfruttano la tecnologia Windows Server Failover Clustering (WSFC) e un set di volumi di storage su ciascuno dei dueAZs. I dati vengono replicati in modo sincrono all'interno di ogni singola AZ e tra le due. AZs Rispetto all'implementazione Single-AZ, le implementazioni Multi-AZ offrono una maggiore durabilità grazie all'ulteriore replica dei dati e una maggiore disponibilità durante la manutenzione pianificata AZs del sistema e le interruzioni non pianificate del servizio mediante il failover automatico sulla zona di standby. Ciò consente di continuare ad accedere ai dati e a proteggerli da guasti delle istanze e interruzioni dell'AZ.

Scelta del tipo di implementazione del file system Single-AZ o Multi-AZ

Consigliamo di utilizzare i file system Multi-AZ per la maggior parte dei carichi di lavoro di produzione, dato il modello ad alta disponibilità e durabilità che offre. L'implementazione Single-AZ è concepita come una soluzione conveniente per carichi di lavoro di test e sviluppo, determinati carichi di lavoro di produzione che hanno la replica integrata nel livello applicativo e non richiedono ridondanza a livello di storage aggiuntiva e carichi di lavoro di produzione che hanno esigenze di disponibilità e Recovery Point Objective () semplificate. RPO I carichi di lavoro con disponibilità ed RPO esigenze limitate possono tollerare una perdita temporanea di disponibilità fino a 20 minuti in caso di manutenzione pianificata del file system o di interruzione non pianificata del servizio e, in rari casi, la perdita degli aggiornamenti dei dati dopo il backup più recente.

Consigliamo inoltre di esaminare il modello di disponibilità per il file system e di garantire che il carico di lavoro sia resiliente al comportamento di ripristino previsto per il tipo di distribuzione scelto durante eventi come la manutenzione del file system, le modifiche della capacità di throughput e le interruzioni non pianificate del servizio.

Supporto delle funzionalità per tipo di implementazione

La tabella seguente riassume le funzionalità supportate dai tipi FSx di distribuzione del file system Windows File Server:

Processo di failover

Il failover automatico dei file system Multi-AZ dal file server preferito al file server di standby si verifica in presenza di una delle seguenti condizioni:

Quando si esegue il failover da un file server a un altro, il nuovo file server attivo inizia automaticamente a servire tutte le richieste di lettura e scrittura del file system. Quando le risorse nella sottorete preferita sono disponibili, Amazon FSx esegue automaticamente il failback al file server preferito nella sottorete preferita. Un failover in genere viene completato in meno di 30 secondi, dal rilevamento dell'errore sul file server attivo alla promozione del file server di standby allo stato attivo. Inoltre, il failback alla configurazione Multi-AZ originale viene completato in meno di 30 secondi e si verifica solo dopo il ripristino completo del file server nella sottorete preferita.

Durante il breve periodo in cui il file system è in fase di failover e failback, l'I/O potrebbe essere sospeso e i parametri di CloudWatch Amazon potrebbero essere temporaneamente non disponibili. Per i file system Multi-AZ, qualsiasi attività di lettura e scrittura dei file che si verifica durante il failover e il failback dovrà essere sincronizzata tra i file server primari e secondari. Questo processo può richiedere fino a diverse ore per i file system con HDD storage e per i carichi di lavoro con un elevato numero di scritture e carichi di lavoro. IOPS Consigliamo di testare l'impatto dei failover sull'applicazione quando il file system è sottoposto a un carico più leggero.

Esperienza di failover su client Windows

Quando si esegue il failover da un file server a un altro, il nuovo file server attivo inizia automaticamente a soddisfare tutte le richieste di lettura e scrittura del file system. Una volta che le risorse nella sottorete preferita sono disponibili, Amazon FSx esegue automaticamente il failback sul file server preferito nella sottorete preferita. Poiché il DNS nome del file system rimane lo stesso, i failover sono trasparenti per le applicazioni Windows, che riprendono le operazioni del file system senza l'intervento manuale. Un failover viene in genere completato in meno di 30 secondi, dal rilevamento dell'errore sul file server attivo alla promozione del file server di standby allo stato attivo. Inoltre, il failback alla configurazione Multi-AZ originale viene completato in meno di 30 secondi e si verifica solo dopo il ripristino completo del file server nella sottorete preferita.

Esperienza di failover su client Linux

I client Linux non supportano il failover DNS automatico. Pertanto, non si connettono automaticamente al file server di standby durante un failover. Riprenderanno automaticamente le operazioni del file system dopo che il file system Multi-AZ avrà eseguito il failback sul file server nella sottorete preferita.

Test del failover su un file system

È possibile testare il failover del file system Multi-AZ modificandone la capacità di throughput. Quando modifichi la capacità di throughput del file system, Amazon FSx disattiva il file server del file system. I file system Multi-AZ eseguono automaticamente il failover sul server secondario, mentre Amazon FSx sostituisce prima il file server preferito. Quindi il file system torna automaticamente al nuovo server primario e Amazon FSx sostituisce il file server secondario.

Puoi monitorare l'avanzamento della richiesta di aggiornamento della capacità di throughput nella FSx console AmazonCLI, nel e nelAPI. Una volta completato con successo l'aggiornamento, il file system ha eseguito il failover sul server secondario e sul server primario. Per ulteriori informazioni sulla modifica della capacità di trasmissione del file system e sul monitoraggio dello stato di avanzamento della richiesta, consulta. Gestione della capacità di throughput

Risorse del file system Single-AZ e Multi-AZ

I file system Single-AZ e Multi-AZ utilizzano le sottoreti e le interfacce di rete elastiche in modo diverso, come spiegato nelle sezioni seguenti.

Sottoreti

Quando si crea un cloud privato virtuale (VPC), si estende su tutte le zone di disponibilità () di. AZs Regione AWS Le zone di disponibilità sono sedi separate progettate per rimanere isolate dai guasti che si verificano in altre zone di disponibilità. Dopo aver creato unVPC, è possibile aggiungere una o più sottoreti in ciascuna zona di disponibilità. L'impostazione predefinita VPC prevede una sottorete in ogni zona di disponibilità. Una sottorete è un intervallo di indirizzi IP nel VPC. Una sottorete deve risiedere in una singola zona di disponibilità.

FSxper i file system Windows File Server Single-AZ è necessaria una sottorete specificata al momento della creazione. La sottorete scelta definisce la zona di disponibilità in cui viene creato il file system.

I file system Multi-AZ richiedono due sottoreti, una per il file server preferito e una per il file server di standby. Le due sottoreti scelte devono trovarsi in zone di disponibilità diverse all'interno della stessa regione. AWS

Per quanto riguarda AWS le applicazioni interne, si consiglia di avviare i client nella stessa zona di disponibilità del file server preferito per ridurre al minimo la latenza.

Interfacce di rete elastiche del file system

Un'interfaccia di rete elastica è un componente di rete logico in un VPC che rappresenta una scheda di rete virtuale. Quando crei un FSx file system Amazon, Amazon FSx fornisce una o più interfacce di rete elastiche VPC che associ al tuo file system. L'elastic network interface consente ai client di comunicare e montare il file system. L'elastic network interface è considerata rientrante nell'ambito del servizio di AmazonFSx, nonostante faccia parte del tuo accountVPC. I file system Multi-AZ dispongono di due interfacce di rete elastiche, una per ogni file server. I file system Single-AZ dispongono di un'interfaccia di rete elastica.

La tabella seguente riassume l'utilizzo delle risorse FSx per i file system Windows File Server Single-AZ e Multi-AZ:

Una volta creato un file system, i suoi indirizzi IP non cambiano finché il file system non viene eliminato.