Fattigmanns cluster med Exchange 2007

Local Continuous Replication

Vi skal denne gang se litt på LCR (Local Continuouse Replication) som er en av Exchange Server2007 sine nye funksjoner for sikring av databaser. LCR bruker asynkron log sending og log “replay” for å opprette og vedlikeholde en kopi av databasen. I utgangpunktet brukes dette for mailbox databaser, men det kan også brukes på public databasen (public folder) hvis man bare har 1 public database i Exchange organisasjonen.

LCR Cluster

 

LCR er egentlig ikke clusterteknologi siden det ikke er noen form for automatisk overføring av tjenester, men funksjonen vil sørge for at man har høyere sikkerhet når det gjelder disaster recovery-scenarioer. Siden vi har en kopi som er så godt som identisk, kan vi rett og slett mounte opp kopien av databasen hvis det blir nødvendig og Exchange er oppe igjen på rekordtid i forhold restore fra tape.

Det som er ulempen med LCR er at det ikke er noen automatisk ”failover” ved feil. Man må rekonfigurere servere til å bruke kopien manuelt. Fordelene er mange som man vil se i denne artikkelen, en av de ikke tekniske sidene er pris. Et vanlig cluster er dyrt, mens LCR gir bare kostnader med at vi må ha ekstra lagringskapasitet.

Hvor kan kopien ligge

 

Når man leser om LCR er det lett for å misforstå funksjonen

For å tolke dette rett må man kjenne til hva som menes med “Second set of disk that are connected to the same server…”.

For det første trenger det ikke å være disker fysisk plassert i serveren (selv om det selvfølgelig også kan være det også), det kan være en san eller nas løsning, eller til og med en USB disk koblet i eller mot serveren. Dette betyr at man også kan ha et nivå med fysisk sikkerhet da SAN/NAS-løsningen kan stå i et annet rom/lokasjon i bygget. Dette motviser det største ankepunktet til de som ikke liker LCR. For øvrig er ikke USB-disk anbefalt, men det kan være greit for å få ut en kopi av databasen.

Hvordan fungere det

 

LCR bruker Exchange databasen sin logg-tankegang til å sørge for at alle hendelser blir duplisert inn i begge databasene. I Exchange og de fleste andre databaser blir alt som skal utføre i en database loggført før endringene skrives inn i databasen. Dette gir oss 2 veldig gode effekter.

Effekt 1 er relatert til ytelse. Hvis du skulle utført alle endringer direkte mot en database (tenk gigabytes) ville dette medført at serveren sine resurser som minne, disk og CPU ble heftig (over)brukt, spesielt på de tider hvor tjenestene blir mest brukt. På grunn av dette blir alle endringer i stedet skrevet inn i loggfiler, loggfilene som er mindre filer (1 Mb i Exchange 2007) er raske å lese og skrive og belaster derfor ikke resursene like mye.

Selvfølgelig må alt i loggfilen skrives inn i databasen, men dette kan nå gjøres når serveren ikke er belastet og det vil derfor ikke påvirke ytelsen mot brukerne.

 

Den andre effekten vi oppnår med loggfiler er relatert til backup. La oss bruke en enkel filbackup som eksempel. Hvis vi sletter filen eller disken krasjer og vi må foreta en restore, sitter vi igjen med filen sånn som den var da vi foretok backupen , dette medfører at vi mister alle endringer utført på filen siden backup tidspunktet. Når vi ser på en Exchange database i samme senario vil loggfilene inneholde endringene som har skjedd siden siste backup (selvsagt avhengig av backup type) og ved hjelp av Loggfil ”replay” vil databasen bli oppdatert slik den var rett før krasjen. Dette er også da en veldig god grunn til at loggfiler ikke skal ligge på samme fysiske disker som det databasen ligger på.

Da dette er en integrert del av Exchange allerede, bygger LCR seg på dette. Det LCR gjør er å kopiere loggfilene til kopiområde før endringene blir ”committet (utført)” i databasen. På denne måten vil begge databasene alltid være noenlunde identiske og oppdatert

Hvorfor LCR

 

I visse tilfeller vil LCR gi bedre beskyttelse enn den klassiske Exchange clusteringen (Singel Copy Cluster, SCC). SCC beskytter oss mot feil på tjenester eller hardwaren, mens LCS beskytter oss mot databasefeil. En av de vanligste feilene med Exchange er korrupt database. Databasen i seg selv har masse beskyttelsesmekanismer (Atomic/Acid reglene) mot dette så det er i de aller fleste tilfellene feil som oppstår på datalagringsnivå (disk) som medfører databasekorrupsjonen. Når databasen er replisert til enn annen diskløsning vil dette medføre at vi har en kopi som mest sannsynlig ikke er korrupt.

I situasjoner hvor hele Exchange-serveren er defekt kan man også benytte seg av Exchange 2007 sin database mobility. Denne går ut på at man nå kan mounte opp databasen på hvilken som helst Exchange 2007 server. Den trenger ikke lengre å ha samme navn og lignende som vi måtte ha på tidligere versjoner. Dette betyr at man for eksempel kan ha en Virtual Server liggende passivt med Exchange 2007 (noe som ikke krever lisens så lenge det er for disaster recovery og den virtuelle maskinen ikke brukes ellers) og starte denne ved behov og koble opp databasen.

Hvordan sette det opp

 

Jeg skal ikke ta en skrittvis gjennomgang på oppsettet, det er jo derfor vi har hjelpefiler og Technet, men et par tips på hvordan dette kan gjøres.

Replikaen bør sette opp på en av følgende 2 metoder:

Den enkleste og ofte greieste løsningen er å sette opp identisk struktur på 2 forskjellige stasjoner. Den aktive kopien av databasen kan for eksempel ligge i følgende sti:

D:/Exchange/DB/

Mens stien til den passive kopien er da:

E:/Exchange/DB/

Ved eventuelle feil i den aktive databasen kan man nå bare endre stasjonsbokstaven på disse 2 stasjonene.

Denne metoden bruker mounting av stasjoner inn i katalog strukturen. I tidligere eksempel vil da mappen DB være en disk som er mountet inn. Den passive kopien av databasen ligger også på en disk som kan mountes opp ved eventuelle problemmer. Det er her da også viktig å sørge for at strukturen er identisk. Denne metoden er spesielt aktuell når man har flere stasjoner tilgjengelig enn bokstaver.

Hvis man ikke følger disse tipsene så kan man eventuelt bruke en powershell-kommando som flytter peker fra den aktive kopien til den passive.

LCR og backup

 

Et annet stort pluss med LCR er backup. Med å bruke VVS (Volume Shadow Service) kan man ta backup av den passive kopien og på den måte ikke belaste den aktive databasen som brukeren benytter. Dette er funksjon som må støttes av backup-programmet, spesielt med tanke på ”flushing” av loggfilene.

Oppsummering

 

Som oppsummering så ser vi at vi nå har en enkel, grei og billig måte å sikre databasene våre på. Som en ulempe må det nevnes at man bare kan ha 1 store i storage-gruppen, men i Standard Edition kan vi nå ha opptil 5 databaser i motsetning til tidligere versjoner hvor vi bare kunne ha 2 og den ene var reservert Public folders.

Så alt i alt sitter vi nå på et kraftig verktøy som mange nok vil bli glade for den første gangen de oppdager en korrupt database, eller de som alt har vært borte i korrupte databaser ønsker seg hver jul.