Hai bisogno di aiuto per valutare la width di banda richiesta per l'arrays SAN alla replica di arrays SAN su WAN

Ho un objective a lungo termine di creare un sito DR in un colo da qualche parte e parte di quel piano include la replica di alcuni volumi della mia EqualLogic SAN. Sto facendo un po 'di tempo difficile perché non so se il mio metodo è sano.

Questo post può essere un po 'lungo per motivi di completezza.

Informazioni generalmente rilevanti:

  1. Ho un EqualLogic PS4000X (~ 4TB).
  2. I SAN agisce come archiviazione condivisa per 2 host ESXi in ambiente vSphere 5.
  3. Ho 4 volumi di 500 GB ciascuno. I volumi 1 e 2 contengono le mie "tier 1" VM. Questi saranno gli unici volumi che intendo replicare.
  4. Attualmente hanno una connessione di 3Mb / s con la width di banda effettiva di dati a ~ 2.8Mb / s a ​​causa del nostro PRI (voce).

Il mio metodo di misurazione del cambiamento in un volume:

Mi è stato detto da un rappresentante di Dell che un modo (forse non il migliore?) Per stimare i delti in un volume è quello di misurare lo spazio di riserva dello snapshot usato per un periodo di tempo di un regolare snapshot.

Il mio primo esperimento con questo era quello di creare un calendario di 15 minuti tra istantanee con una riserva di istantanea di 500 GB. Ho lasciato che questo funziona durante la notte e fino a COB il giorno successivo. Non ricordo il numero di istantanee che potrebbero essere contenute in 500 GB, ma ho finito con una media di ~ 15 GB per istantanea.

$average_snapshot_delta = $snapshot_reserve_used / $number_of_snapshots 

Ho poi cambiato l'intervallo di istantanea a 60 minuti che dopo un passaggio completo di 24 ore significa un totale di 13 istantanee in 500 GB. Questo mi lascia con ~ 37GB per ora (o ~ 9GB per 15 minuti).

Il problema:

Questi numbers sono astronomici per me. Con la mia width di banda posso fare un po 'più di 1GB / ora con 100% di utilizzo. La replica a livello di block è costosa o sto facendo qualcosa di completamente sbagliato?

  • Verifica se i frame jumbo stanno funzionando
  • Configurazione SAN di Windows 2000 R2 Hyper-V
  • Creazione di un cluster di failover Hyper-V a due nodes con una SAN
  • Quali sono gli aspetti più importnti da considerare quando si sceglie una SAN per un progetto di virtualizzazione di piccoli uffici?
  • Posso interrompere la VM durante l'allineamento di archiviazione iscsi di potenza
  • Come funziona la SAN di LeftHand in un ambiente di produzione?
  • Imansible estendere il disco di dati esistente su 2TB su Windows 2008 con parti dinamiche e gpt
  • È ansible aggiornare i server di archiviazione Dell alle installazioni complete del sistema operativo?
  • 6 Solutions collect form web for “Hai bisogno di aiuto per valutare la width di banda richiesta per l'arrays SAN alla replica di arrays SAN su WAN”

    I tuoi numbers si scaldano fino a 10.24 MB / s, che sembra un po 'in alto per scrivere pura. Ma poi, non conosco i tuoi carichi di lavoro.

    Tuttavia, hai un problema più grande. La replica iniziale replica 1 TB di dati su una paglia di 3 MB / s.

     1TB = 1024GB = 1,048,576 MB 2.8 MB/s replication speed ~4.33 days 

    Durante questo periodo sarà in attesa della modifica della networking per quando finisce la sincronizzazione iniziale. E se dovrai sempre estrarre i dati dall'arrays remoto, saranno 4,33 giorni finché non sarai pienamente in esecuzione (a less che non disponga di un metodo di trasferimento dati fuori banda, ad esempio una spedizione FedEx overnight o un camion).

    Per quanto riguarda la differenza nel cambio netto tra le istantanee di 15 minuti e le istantanee di 60 minuti, credo che l'istantanea di 60 minuti sta ottenendo il beneficio di un sacco di scrittura-combinazione. O mette in altro modo, tutti quelli che scrivono alle riviste del filesystem sono coalescenti nell'istantanea più lunga nel modo in cui non sono tanto negli scatti di 15 minuti.

    Questo è where la modalità di sincronizzazione veramente entra in proprio. Un pipe da 3 MB / s è fortemente sottoprovizionato per la replica sincrona. Una replica asynchronous battezzata guadagnerà alcuni dei vantaggi della combinazione di scrittura e quindi di un trasferimento totale inferiore, a costo di perdere alcuni dati in un disastro. Purtroppo non sono abbastanza esperto in Equilogic per sapere cosa sia capace

    Questo è il più grande contro contro l'equallogico a mio parere. La replica è basata su istantanee e la loro tecnologia istantanea è incredibilmente inefficace.

    Corriamo circa 25 arrays nel nostro ambiente e il mio objective di 2-3 anni è quello di sostituirli tutti con netapp. Sulla base di ciò che vediamo nei nostri cif filati netapp e nel test di nfs, la width di banda di replica e lo spazio istantaneo saranno ridotti dell'80%. aggiungere le funzioni di dedupe del netapp ed è molto più efficiente.

    Assicurati di mettere i file delle pagine di Windows ei file di scambio vmware su un volume non replicato.

    Inoltre – se potete permetterselo guardare aggiungendo alcuni ottimizzatori del wan del fiume. Ridurre la quantità di dati sul tuo guadagno per la replica del 60% o giù di lì. Ci ha salvato e abbiamo collegamenti minumum ds3 wan fino a oc-3.

    Non hai anche menzionato la latenza. È una componente critica nei calcoli di replica.

    Se i VM non dispongono dei file di pagina in un data server separato, dovresti provare a spostarli a uno e quindi riesaminare il tasso di modifica dei dati (data churn). Questo sicuramente aiuterà. Non replicare più di quello che serve.

    EQL support la replica continua asynchronous o è guidata da un programma di snapshot? Puoi usare l'intera 3Mb 24/7?

    Sempre secondo il suggerimento di sincronizzare gli arrays prima di metterlo sul sito remoto.

    Per concentrarmi sulle informazioni più rilevanti, suggerisco di definire un objective per il punto di ripristino e il tempo di recupero. Questi sono inimmaginativamente definiti come "RPO" e "RTO". La replica del disco dovrebbe ridurli sia mantenendo una copia costante dei dati che non è mai più vecchia di pochi minuti su un altro sito. Una volta che questi numbers sono disponibili, puoi definire le cose come la frequenza di copia della replica costante .

    3Mb / s probabilmente non sta per tagliare la senape a less che non si utilizzi l'accelerazione WAN (come il Riverbed, menzionato da uno degli altri rispondenti). L'accelerazione WAN funziona mantenendo una cache sul disco da entrambi i lati del collegamento in cui memorizzano tutti i dati più recenti che hai inviato e se invii un block duplicato, invia un riferimento invece dei dati.

    Detto questo, supponendo che la tua archiviazione utilizzi lo stesso motore per scattare istantanee come utilizza per replicare istantanee, allora la misura più accurata della modifica è in realtà una riserva di istantanea. Sarà necessario mantenere una istantanea e la sua riserva isolata per tutta la durata del periodo di misurazione. Supponendo che EqualLogic utilizza copia in istantanee di scrittura, confrontare i dati dalla riserva di più snapshot assunte durante la giornata potrebbe in realtà far sembrare che i tuoi dati cambino più di quanto non sia effettivamente.

    Quanto ai dati stessi, sono d'accordo con le risposte che suggeriscono di non replicare i file di swap. I file di scambio possono richiedere un sacco di disco e stanno sempre cambiando, il che potrebbe innescare un sacco di traffico di replica. Non so se VMWare support la replica di un ambiente senza di esse, anche se … suppongo che i VM in un datastore AM VM replicati senza file di swap sarebbero coerenti con i crash, tuttavia non posso confermarmi.

    Attualmente sono in procinto di qualcosa di simile tuttavia con Solaris 11 e zfs come il nostro backend san. A causa della width di banda ho deciso di separare la maggior parte dei componenti. Abbiamo migrato per lo scambio 2010 affinché possiamo impostare il nostro sito dr con una copia identica. Quello che ho scoperto stava facendo delle istantanee a livello di san sarebbe stato ridicolo per questi dati a causa di problemi di width di banda come si vede. Abbiamo deciso che sarebbe più economico e più efficiente impostare un dag e replicare all'interno dello scambio. Abbiamo fatto la stessa cosa anche con i nostri server mysql. Ciò che ora cloniamo è sisthemes con less deltas tra istantanee. Sono stato in grado di effettuare la sincronizzazione iniziale presso l'ufficio e trasportrla fino alla destinazione finale.

    La dimensione del block è 16 Mo per istantanea e replica su SAN Equalogic. Ecco perché hai questi numbers astronomici. Non c'è modo di cambiarlo. La soluzione per noi per soddisfare la nostra SLA RTO / RPO whereva installare un Riverbed WAN Optimization Appliance tra i 2 siti.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.