none
DAG e DB distribuiti RRS feed

  • Discussione generale

  • ciao a tutti,

     

    sto testando in questi giorni l'implementazione di un DAG .

    La struttura e' la seguente :

    2 server ciascuno con hub e cas ( creato il cas array)

    3 server mbox per il dag.

     

    In una struttura di questo tipo, vedete meglio la disposizione di tutti i DB attivi su di uno dei due server e tutti i DB passivi nell'altro server o bilanciati ? un po' di attivi nel server1 e un po' di DB nel server 2 ?

    Le cassette postali in produzione sono circa 150 . i due server  ( come pure gli hub / cas ) sono disposti su due SAN distinte e su cestelli distinti.

    quindi per capirci : 2 SAN con due cestelli ciascuno. nella prima SAN in un cestello un HUB/Cas Server e sull'altro un Server Mbox e cosi' nell'altra SAN.

    i DB sono indicativamente 6 .

     

    Nel caso venissero messi 3 DB in un server e 3 DB nell'altro, potrebbe aver senso un terzo server fisico che gestische tutti i 6 DB in modalita' passiva?

     

    cosa ne dite?

    Grazie per le risposte.


    Greetings ! Marco
    giovedì 11 agosto 2011 13:28

Tutte le risposte

  • Io terrei 3 DB su uno e 3 sull'altro. Dato che te lo puoi permettere perchè dovresti lasciare un server a vegetare mentre l'altro fatica :-)

    Il terzo server sarebbe comodo per la manutenzione (nel momento in cui tiri giù uno dei server hai ancora l'alta affidabilità), per un'eventuale Lagged Copy dei DB e per avere a disposizione nuovi scenari di backup e design dei dischi.

    Manutenzione:

    Se tiri giù una macchina per installare una patch hai ancora a disposizione l'alta affidabilità.

    Lagged Copy:

    Le lagged copy ti proteggerebbero da eventuali corruzioni logiche e ti darebbero un ulteriore livello di protezione per il ripristino di oggetti cancellati.

    Ad esempio: Hai una retention di 30 gg. e hai una copia lagged a 14 gg.

    Se devi ripristinare un oggetto cancellato prima dei 30gg. hai il recupera posta eliminata di Outlook
    Se devi rispristinare un oggetto cancellato tra 30 e 44gg. attivi la copia lagged in un recovery DB
    Per gli oggetti superiori ai 44gg. devi fare il restore da backup

    Per maggiori info sulle copie lagged guarda su http://technet.microsoft.com/en-us/library/dd979802.aspx

    Ricorda che però le copie lagged ci mettono più tempo per attivarsi (dato che devono applicare al DB molti più transaction log di una copia normale) per cui non le devi trattare contare per l'alta affidabilità (se le tieni in ritardo di 14gg. ci potrebbero volere ore per montarle).

    Backup:

    Voglio sfatare il mito che si consiglia di andare backup-less con 3 o più copie di un DB perchè il backup è inutile.
    Nessuno ha mai detto questo. Quello che però si deve notare è che gli scenari di restore da backup cambiano.

    Con 3 o più copie l'importanza del backup si sposta da scenari di Database Recovery a scenari di pura retention del dato.
    Quando hai 3 copie separate di un DB è improbabile che tu debba fare un restore per una corruzione. Se anche un DB si corrompe lo cancelli e fai il reseed dei dati dalle altre copie. Il restore diventa necessario per recuperare un oggetto al di fuori della retention e del lag. Se la soluzione non richiede il riprstino di oggetti troppo vecchi allora puoi anche pensare a una soluzione backup-less.

    Storage:

    • Uso di dischi SATA e DAS: La failure rate dei dischi SATA è ancora un po' altina (vedi Empirical Measurements of Disk Failure Rates and Error Rates) ma con più copie ti puoi permettere la perdita del disco con relativa serenità e, cosa non da poco, i dischi SATA costano ancora meno degli altri (almeno a tendere. Non mi sottoponete i listini dei vendor :-))
    • Configurazioni RAID-Less: Anche in questo caso l'affermazione va letta in modo corretto. Le configurazioni in RAID continuano a essere importanti e la loro utilità è indubbia. Quello che cambia è il perchè si decide di usare il RAID. Con 3 copie diventa più facile e veloce sostituire il disco e fare il reseed del DB piuttosto che ricostruire il RAID (i dati ce li ho nelle altre due copie in fondo). Quello che però il RAID mi da è anche un miglioramento delle performance dei dischi e su questo sono d'accordo che continua a essere utile. La domanda da stupido che faccio è: Quando ho 3 copie dei miei dati è davvero necessario metterle su un RAID 10 come si faceva con 2003 ?

    Ammetto che ho approfittato della domanda per parlare di un argomento che mi interessa. Spero di non aver annoiato nessuno.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"
    giovedì 11 agosto 2011 15:13
  • Ti ringrazio infinitamente della risposta decisamente esauriente e chiarissima .

    non potevo davvero chiedere di meglio.

     

    la domanda era proprio per capire che strada seguire anche per ulteirori implicazioni che non ho scritto prima . ( una tra tutte l'implementazione di symantec vault per l'archiviazione che e' decisamente rognosa sotto DAG ).

     

    Penso che usero' il terzo server proprio per avere delle lagged copy.

    i backup verrebbero fatti ogni notte incrementali e full il fine settimana con backup exec ... non ho mai pensato di usare il DAG come strumento per NO backup.

    Per quanto riguarda invece i raid continuo a preferire i raid 10 con dischi sas a 15k rpm....principalmente per un motivo. Se vedo che ho problemi di performance, prima di pensare alla SAN controllo un po' meglio l'infrastruttura :)

    Ti pongo pero' un altra domanda approfittando della tua competenza. Nel caso di volesse implementare per alcuni utenti i personal archive, come gestiresti la cosa? Se non sbaglio dall'Sp1 si possono mettere in DB separati. e' corretto ? sono sempre inseribili dentro ad una infrastruttura DAG ?

     

    Grazie mille.

     


    Greetings ! Marco
    giovedì 11 agosto 2011 16:20
  • Io personalmente metterei le personal archive mailbox sullo stesso DB delle mailbox vere e proprie.
    Se anche le mettessi su un DB a parte richiederebbero prestazioni simili al DB delle mailbox "vere".
    L'unico motivo che mi viene in mente per separarle sarebbe una strategia di backup differente (1 Full settimanale senza gli incrementali ?)
    Tieni anche conto che se la mailbox base non è disponibile l'utente non arriva neppure a quella d'archivio.
    Non so come si comporta Vault con le mailbox di archivio ma ci guarderei con attenzione.
    Se le licenze di Vault le hai già pagate forse è più comodo usare Vault.
    Se le licenze di Vault non le hai ancora e vuoi ridurne il numero che ti serve allora le personal archive possono valere la pena.

    Anche qui ci vuole una spiegazione.

    Le personal archive mailbox sono nate per eliminare la necessità dei PST ma non sono in grado di sostituire in tutto e per tutto un sistema di archiviazione di terze parti come ad esempio Vault.

    Non voglio entrare in discorsi di licenze (ho ancora la fortuna di non dovermene preoccupare troppo :-)) ma gestire le personal archive mailbox è tendenzialmente più facile di SW di terze parti.

    Se voglio il personal archive faccio tasto destro sulla mailbox e lo abilito. Lo vedo già in OWA, lo vedo già in Outlook (Outlook 2007 SP2 o superiori), la conversation view di Outlook 2010 legge anche lì e indicizzo il contenuto in maniera da poter trovare anche la roba nell'archivio con una singola ricerca.

    Per fare quello sopra con un SW di terze parti mi tocca installare le estensioni del prodotto sul CAS, installare il client sulle macchine con Outlook (con un add-in in più da gestire in caso di troubleshooting), le ricerche mi tocca farle un po' con Outlook e un po' con il client del SW di terze parti, devo gestire la cache locale di Outlook e del sistema di archiviazione. Insomma aggiungo un ulteriore elemento di complessità all'infrastruttura.

    Riassumendo: le personal archive mailbox mi rendono la vita più semplice (e forse meno costosa) ma in alcuni casi la semplicità non risponde alle nostre esigenze e dobbiamo complicarci la vita.

    Per quanto riguarda le utility di archiviazione in generale (soprattuto quelle che fanno stubbing come vault) ti consiglio di leggere con attenzione questo articolo:

    Exchange 2010 Database Page Fragmentation Caused By Archive Solutions

    Le considerazioni che fa sullo spazio guadagnato (e non) tramite gli stub cambia le carte in tavola quando si valuta una soluzione di archiviazione. Le soluzioni di terze parti riescono a ridurre lo spazio necessario anche in altri modi (ad es. la deduplication) ma in questa situazione uno dei loro punti forti va a cadere e rischia di far peggiorare le performance del DB invece che migliorarle.

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"
    giovedì 11 agosto 2011 20:15
  • Aggiungo anche un altro link che fa considerazioni interessanti sull'utilità delle archive mailbox:

    Why you should consider using Exchange 2010′s archiving features instead of just large mailboxes

    Ciao ancora
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"
    giovedì 11 agosto 2011 20:21