De implementatie van elke IT-oplossing binnen een onderneming begint met het ontwerp. In dit stadium moet de IT-manager het aantal servers en hun kenmerken berekenen, zodat deze aan de ene kant ruim voldoende zijn voor alle gebruikers, terwijl aan de andere kant de prijs-kwaliteitverhouding van deze servers optimaal is en de kosten voor het creƫren van de rekeneenheid voor het nieuwe informatiesysteem geen ernstige deuk in het IT-budget van het bedrijf veroorzaken. Laten we bekijken hoe we de infrastructuur voor de implementatie van Zimbra Collaboration Suite in een onderneming moeten ontwerpen.
Een van de belangrijkste kenmerken van Zimbra in vergelijking met andere oplossingen is dat in het geval van ZCS de verwerkingskracht of het RAM zelden de beperkende factor is. De belangrijkste beperking is meestal de snelheid van de in- en uitgang van de harde schijf, en daarom moet de focus voornamelijk liggen op de opslagmedia. De officieel aangegeven minimumvereisten voor Zimbra in een productieomgeving zijn een 4-core 64-bits processor met een kloksnelheid van 2 gigahertz, 10 gigabyte voor systeem- en logbestanden, evenals minstens 8 gigabyte RAM. Deze specificaties zijn meestal voldoende voor een responsieve werking van de server. Maar wat te doen als u Zimbra voor 10.000 gebruikers moet implementeren? Welke servers en hoe moet u deze in dat geval implementeren?
Laten we beginnen met het feit dat de infrastructuur voor 10.000 gebruikers multi-server moet zijn. Een multi-server infrastructuur maakt het enerzijds mogelijk om Zimbra schaalbaar te maken, terwijl het anderzijds ervoor zorgt dat het informatiesysteem responsief blijft, zelfs bij een grote toestroom van gebruikers. Het is meestal behoorlijk lastig om precies te voorspellen hoeveel gebruikers een Zimbra-server kwalitatief kan bedienen, aangezien dit sterk afhangt van de intensiteit waarmee ze met agenda's en e-mail werken, evenals van het gebruikte protocol. Daarom zullen we in dit voorbeeld 4 e-mailopslagplaatsen implementeren. In het geval van een tekort of een ernstige overschot aan capaciteit kan er altijd een extra opslagplaats worden uitgeschakeld of toegevoegd.
Bij het ontwerpen van een infrastructuur voor 10.000 mensen moeten LDAP-, MTA- en Proxy-servers en 4 e-mailopslagplaatsen worden gemaakt. Opmerking: de LDAP-, MTA- en Proxy-servers kunnen virtueel worden gemaakt. Dit zal de kosten voor serverhardware verlagen en het herstel en de back-up van gegevens vergemakkelijken, maar aan de andere kant, in het geval van een storing van de fysieke server, loop je het risico om ineens zonder MTA-, LDAP- en Proxy-servers te zitten. Daarom moet de keuze tussen fysieke of virtuele servers worden gebaseerd op de uitvaltijd die je kunt veroorloven in geval van een calamiteit. E-mailopslagplaatsen kunnen het beste op fysieke servers worden geplaatst, aangezien daar het grootste aantal schrijfcycli plaatsvindt, die de snelheid van Zimbra beperken. Een groter aantal datakanalen zal de prestaties van Zimbra aanzienlijk verbeteren.
In principe, na de creatie van servers LDAP, MTA, Proxy, netwerkopslag en de integratie ervan in een enkele infrastructuur, is de Zimbra Collaboration Suite voor 10.000 gebruikers klaar voor gebruik. Het werkingsschema van deze configuratie zal vrij eenvoudig zijn:
In het schema zijn de belangrijkste knooppunten van het systeem en de datastromen tussen hen weergegeven. Met deze configuratie is de infrastructuur volledig onbeschermd tegen gegevensverlies, uitvaltijd veroorzaakt door het falen van een van de servers, enzovoort. Laten we nu eens kijken hoe we onze infrastructuur tegen deze problemen kunnen beschermen.
De belangrijkste methode is hardwarematige redundantie. Extra MTA- en Proxy-knopen kunnen, in het geval van falen van de hoofdservers, tijdelijk de rol van hoofdservers overnemen. Dubbelingen van knooppunten van kritieke infrastructuren zijn bijna altijd een goed idee, maar niet altijd haalbaar in de gewenste omvang. Een duidelijk voorbeeld is de redundantie van servers waar e-mail wordt opgeslagen. Momenteel ondersteunt de Zimbra Collaboration Suite Open-Source Edition geen creatie van dubbele opslagplaatsen, waardoor bij uitval van een dergelijke server uitvaltijd onvermijdelijk is. Ter vermindering van de uitvaltijd door het falen van een e-mailopslagplaats kan de IT-manager een back-up ervan op een andere server implementeren. de server.
Omdat er geen ingebouwd back-upsysteem in Zimbra OSE is, hebben we Zextras Backup nodig, dat real-time back-ups ondersteunt, evenals externe opslag. Aangezien Zextras Backup volledige en incrementele back-ups maakt en alle gegevens plaatst in de map /opt/zimbra/backup, zou het verstandig zijn om externe, netwerk- of zelfs cloudopslag eraan te koppelen, zodat we in geval van een serveruitval een medium hebben met een actuele back-up op het moment van het incident. Deze kan zowel op een reserve fysieke server als op een virtuele machine of in de cloud worden hersteld. Het zou ook een goed idee zijn om een MTA met spamfilter voor de server met Zimbra Proxy te installeren om de hoeveelheid ongewenst verkeer naar de server te verminderen.
Uiteindelijk zal de beveiligde infrastructuur van Zimbra er ongeveer zo uitzien:
Met deze configuratie kan de Zimbra-infrastructuur niet alleen kwaliteitsdiensten aan 10.000 gebruikers leveren, maar kan het ook, in het geval van een noodsituatie, zo snel mogelijk de gevolgen verwijderen.
Bron: habr.com
