Planering av infrastruktur för installation av Zimbra Collaboration Suite

Implementeringen av en IT-lösning på ett företag börjar med design. I detta skede måste IT-chefen beräkna antalet servrar och deras specifikationer, så att de å ena sidan har tillräckligt med kapacitet för alla användare, men å andra sidan att pris-prestanda-förhållandet för dessa servrar är optimalt så att kostnaderna för att skapa en datainfrastruktur för det nya informationssystemet inte spräcker företagets IT-budget. Låt oss förstå hur man bör designa infrastrukturen för implementeringen av Zimbra Collaboration Suite på företaget.

Den främsta egenskapen hos Zimbra jämfört med andra lösningar är att när det gäller ZCS sällan en processor hastighet eller RAM-minne blir flaskhalsen. Det huvudsakliga begränsningen är vanligtvis hastigheten på in- och utmatning från hårddisken, och därför bör fokus ligga på datalagring. De officiellt angivna minimikraven för Zimbra i en produktionsmiljö är en 4-kärnig 64-bitars processor med 2 gigahertz klockfrekvens, 10 gigabyte för systemfiler och loggar, samt minst 8 gigabyte RAM. Vanligtvis räcker sådana specifikationer för att servern ska fungera responsivt. Men vad ska man göra om du ska implementera Zimbra för 10 000 användare? Vilka servrar och hur ska man implementera dem i så fall?

Låt oss börja med att infrastrukturen för 10 000 användare bör vara en multiservlösning. En multiservlösning gör å ena sidan Zimbra skalbar, och å andra sidan säkerställer en responsiv drift av informationssystemet även vid hög användartillströmning. Det är ofta ganska svårt att förutsäga hur många användare en Zimbra-server kan serva effektivt, eftersom det beror mycket på hur intensivt de arbetar med kalendrar och e-post, samt vilken protokoll som används. Av denna anledning kommer vi att implementera 4 e-postlagringssystem som exempel. Om kapaciteten är otillräcklig eller alltför överdimensionerad kan man antingen stänga av eller lägga till en till.

Därmed, vid utformningen av infrastrukturen för 10 000 personer kommer det att krävas att skapa LDAP-, MTA- och Proxy-servrar samt 4 e-postlagringsenheter. Observera att LDAP-, MTA- och Proxy-servrar kan göras virtuella. Detta kommer att minska kostnaderna för serverutrustning och underlätta säkerhetskopiering och dataåterställning, men å andra sidan, i händelse av att den fysiska servern går sönder, riskerar ni att bli utan både MTA, LDAP och Proxy. Just därför bör valet mellan fysiska eller virtuella servrar göras med tanke på hur mycket driftstopp ni har råd med vid en nödsituation. E-postlagringsenheterna är bäst placerade på fysiska servrar, eftersom det på dem kommer att ske det största antalet skrivcykler, vilket begränsar Zimbras prestanda, och därför kommer ett större antal dataöverföringskanaler att öka Zimbras prestanda avsevärt.

I princip, efter skapandet av servrar LDAP, MTA, Proxy, nätverkslagringsenheter och sammanfogningen av dessa i en enhetlig infrastruktur, är Zimbra Collaboration Suite för 10 000 användare redo för drift. Arbetsprincipen för en sådan konfiguration kommer att vara ganska enkel:

I schemat visas systemets huvudnoder och de datastreamar som kommer att cirkulera mellan dem. Med en sådan konfiguration kommer infrastrukturen att vara helt oskyddad mot dataförlust, driftstopp på grund av att någon av servrarna går sönder, och så vidare. Låt oss titta på hur man faktiskt kan skydda sin infrastruktur mot dessa problem.

Huvudmetoden är hårdvaruöverskottslösningar. Ytterligare MTA- och Proxy-noder kan i händelse av att huvudservrarna går sönder tillfälligt överta huvudrollerna. Redundans på kritiska infrastruktur noder är nästan alltid en bra idé, men den kan inte alltid genomföras i önskad omfattning. Ett tydligt exempel är redundans av servrar där e-post lagras. För närvarande stöder Zimbra Collaboration Suite Open-Source Edition inte skapande av duplicerande lagringsenheter, vilket innebär att det inte går att undvika driftstopp vid en av dessa servars haveri, och för att minska driftstoppet orsakad av ett fel hos e-postlagringsenheten kan IT-chefen återställa dess säkerhetskopia på en annan. servern.

Eftersom Zimbra OSE inte har något inbyggt backupsystem, behöver vi Zextras Backup, som stöder realtidsbackup, och extern lagring. Eftersom Zextras Backup, vid skapandet av fullständiga och inkrementella backuper, lagrar alla data i mappen /opt/zimbra/backup, skulle det vara klokt att montera extern, nätverksbaserad eller till och med molnlagring där, så att om en av servrarna skulle krascha, har vi en lagringsenhet med en aktuell backup vid tidpunkten för incidenten. Den kan återställas både på en reservfysisk server och på en virtuell maskin eller i molnet. Det kan också vara en bra idé att installera en MTA med spamfilter före servern med Zimbra Proxy för att minska mängden skräptrafik som kommer till servern.

Den skyddade infrastrukturen för Zimbra kommer ungefär att se ut så här:

Med denna konfiguration kommer infrastrukturen för Zimbra inte bara att kunna tillhandahålla högkvalitativa tjänster till 10.000 användare, utan också, vid en nödsituation, möjliggöra en snabb åtgärd för att hantera konsekvenserna.

Källa: habr.com