Implementeringen af enhver IT-løsning i en virksomhed begynder med designet. I denne fase skal IT-chefen beregne antallet af servere og deres egenskaber, så det både er tilstrækkeligt til at dække behovene for alle brugere og samtidig sikre, at forholdet mellem pris og kvalitet er optimalt, så omkostningerne til oprettelse af den computermæssige infrastruktur til det nye informationssystem ikke skader virksomhedens IT-budget alvorligt. Lad os se nærmere på, hvordan man skal designe infrastrukturer til implementering af Zimbra Collaboration Suite i virksomheden.
Den primære funktion ved Zimbra i forhold til andre løsninger er, at det sjældent er CPU-kraft eller RAM, der bliver flaskehalsen ved ZCS. Det primære begrænsende faktor er som regel hastigheden på ind- og udlæsning af harddisken, og derfor bør hovedfokus rettes mod datalagring. De officielt angivne minimale krav til Zimbra i et produktionsmiljø er en 4-kernet 64-bit processor med 2 gigahertz clockfrekvens, 10 gigabyte til systemfiler og logfiler samt minimum 8 gigabyte RAM. Disse specifikationer er som regel tilstrækkelige til en responsiv serverdrift. Men hvad skal man gøre, hvis man skal implementere Zimbra for 10.000 brugere? Hvilke servere og hvordan bør man implementere dem i sådan et tilfælde?
Vi starter med, at infrastrukturen for 10.000 brugere skal være multiserver-baseret. En multiserver-infrastruktur tillader på den ene side at gøre Zimbra skalerbar og på den anden side at opnå responsiv drift af informationssystemet, selv ved et stort antal brugere. Det er ofte meget svært at forudsige, hvor mange brugere en Zimbra-server effektivt kan betjene, da dette i høj grad afhænger af intensiteten af deres arbejde med kalendere og e-mail, samt af den anvendte protokol. Derfor vil vi for eksempel implementere 4 mail-lagringssystemer. I tilfælde af utilstrækkelig eller alvorlig overkapacitet kan man enten slukke for eller tilføje endnu en.
Derfor, når man designer en infrastruktur til 10.000 personer, vil det være nødvendigt at oprette LDAP-, MTA- og Proxy-servere samt 4 postlagre. Det skal bemærkes, at LDAP-, MTA- og Proxy-servere kan gøres virtuelle. Dette vil reducere omkostningerne til serverhardware og lette backup og datagendannelse, men på den anden side, i tilfælde af svigt af en fysisk server, risikerer man at miste både MTA-, LDAP- og Proxy-funktioner på én gang. Derfor bør valget mellem fysiske eller virtuelle servere foretages ud fra, hvor meget nedetid man har råd til i tilfælde af en nødsituation. Postlagre bør ideelt set placeres på fysiske servere, da det er her, hovedparten af skrivecyklussen finder sted, hvilket begrænser Zimbras ydeevne, og derfor vil et større antal datakanaler betydeligt forbedre Zimbras ydeevne.
I princippet, efter oprettelsen servere af LDAP, MTA, Proxy, netværkslagre og ved at samle dem i en samlet infrastruktur, er Zimbra Collaboration Suite til 10.000 brugere klar til drift. Funktionsdiagrammet for denne konfiguration vil være ret enkelt:
Diagrammet viser de vigtigste noder i systemet og datastrømmene, der vil cirkulere mellem dem. Under en sådan konfiguration vil infrastrukturen være helt ubeskyttet mod datatab, nedetid forårsaget af svigt af en hvilken som helst server, osv. Lad os se nærmere på, hvordan man kan beskytte sin infrastruktur mod disse problemer.
Den primære metode er hardware redundans. Yderligere MTA- og Proxy-noder kan midlertidigt tage over som hovedsystemer i tilfælde af svigt af de primære servere. Duplikerede noder af kritisk infrastruktur er næsten altid en god idé, men det er ikke altid muligt at opnå i ønsket omfang. Et klart eksempel er backup af servere, hvor posten opbevares. I øjeblikket understøtter Zimbra Collaboration Suite Open-Source Edition ikke oprettelse af duplikerende lagre, så i tilfælde af svigt af en sådan server vil man ikke kunne undgå nedetid, og for at reducere nedetiden forårsaget af svigtet af postlageret kan IT-chefen rulle en backup ud på en anden serveren.
Da der indbyggede backup-system i Zimbra OSE ikke eksisterer, vil vi have brug for Zextras Backup, som understøtter backup i realtid, og ekstern lagring. Da Zextras Backup, ved at tage fulde og inkrementelle sikkerhedskopier, gemmer alle data i mappen /opt/zimbra/backup, ville det være fornuftigt at montere ekstern, netværksbaseret eller endda cloud-lagring til den, så vi i tilfælde af, at en af serverne går ned, har en enhed med en opdateret backup på tidspunktet for hændelsen. Den kan gendannes både på en fysisk backup-server og på en virtuel maskine eller i skyen. Det ville også være en god idé at installere MTA med spamfilter foran serveren med Zimbra Proxy for at reducere den mængde af affaldstrafik, der kommer ind på serveren.
Den beskyttede infrastruktur for Zimbra vil således se cirka sådan her ud:
Med denne konfiguration vil Zimbra-infrastrukturen ikke kun være i stand til at levere kvalitetsydelser til 10.000 brugere, men også ved opståede nødsituationer tillade hurtigst muligt at afhjælpe konsekvenserne.
Kilde: habr.com
