Migratie Zarafa 6.20 -> 6.40

Migratie Zarafa 6.20 -> 6.40 ACHA Automation Geautoriseerd Zarafa Partner Datum 01-11-2010 Door ACHA Automation BV ACHA Automation BV Industrieweg 35 A 3641 RK Mijdrecht The Netherlands Phone +31 297 310 199 www.acha.nl info@acha.nl

Inhoudsopgave 1. Inleiding...3 1.1. Over ACHA Automation...3 1.2. Probleem migratie 6.20 naar 6.30/6.40...3 1.3. Oplossing...3 1.4. Aanpak...3 2. Stappenplan migratie...4 2.1. Controles vooraf...4 2.2. Stappenplan migratie Zarafa 6.20 6.40 (via 6.30)...5 3. Vragen?...7 Migratie Zarafa 6.20 -> 6.40 01-11-2010 2 7

1. Inleiding 1.1. Over ACHA Automation ACHA Automation is geautoriseerd Zarafa partner. In deze rol wil zij zich actief profileren en ook haar bijdrage leveren in de ondersteuning van zowel haar klanten als de Zarafa community. Deze handleiding is in eerste instantie opgesteld en getest voor intern gebruik, maar met het publiekelijk beschikbaar maken hoopt ACHA Automation ook andere Zarafa gebruikers van dienst te zijn. 1.2. Probleem migratie 6.20 naar 6.30/6.40 Veel klanten zitten te springen om de upgrade van Zarafa 6.20 naar Zarafa 6.30 of 6.40. Een aantal randvoorwaarden kunnen roet in het eten gooien bij deze upgrade: 1. Beperkte ruimte op de (virtuele) machines de database mag niet te groot worden 2. Beperkt service window bij veel klanten upgrade moet zo snel mogelijk afgerond worden omdat men zo snel mogelijk weer toegang wil tot mail/agenda/contacten. 3. Backup: veel backups gaan inmiddels online; hoe compacter de database, hoe sneller de backup klaar is. Ook bij eventueel terugplaatsen van een backup levert dit veel tijdswinst op. De reden dat deze randvoorwaarden een probleem vormen is het verdubbelen (!) van de database grootte bij een upgrade van 6.20 naar een nieuwere versie. Volgens Zarafa is de Lob tabel hier de boosdoener en is dit een algemeen InnoDB / MySQL probleem (DB kan alleen groeien en niet krimpen). Wat er precies voor zorgt dat deze Lob tabel ineens verdubbelt blijft vooralsnog onduidelijk. 1.3. Oplossing De oplossing zoals geadviseerd door Zarafa is het dumpen van de database en deze hierna opnieuw inlezen. Dit dumpen kost echter ook tijd en ruimte. Bovendien heeft deze stap pas echt zin als eerst de attachments uit de database zijn verwijderd. De optimale volgorde is dus van belang. 1.4. Aanpak Het stappenplan dat hierna volgt is tot stand gekomen na uivoerige interne tests bij ACHA Automation, met Zarafa versie 6.20 en databases van 4 GB tot 50 GB. Migratie Zarafa 6.20 -> 6.40 01-11-2010 3 7

2. Stappenplan migratie Deze handleiding gaat uit van een standaard Zarafa installatie op Linux CentOS en Sendmail als MTA. Als u een andere Linux distributie en/of andere MTA gebruikt, kan het zijn sommige commando's of bestandslocaties net iets afwijken. Verder gaat deze handleiding er van uit dat de benodigde Zarafa upgrade pakketten van zowel 6.30 als 6.40 al gedownload zijn (maar nog niet geïnstalleerd!) op de machine in kwestie. Aangezien Zarafa 6.40 een database indeling van versie 6.30 of hoger verwacht, gaat een migratie van 6.20 naar 6.40 altijd via 6.30. Als deze stap overgeslagen wordt, is een correcte werking niet te garanderen. Deze handleiding houdt geen rekening met eventueel in gebruik zijnde 'brick-level backup' van Zarafa. Mocht deze feature in gebruik zijn, onderzoek dan goed vantevoren of de in deze handleiding beschreven stappen compatible zijn hiermee. Deze handleiding verwijst op een aantal punten naar de Zarafa 6.40 Administrator Manual. Zorg dat je deze bij de hand hebt. Deze handleiding kan gedownload worden vanaf de Zarafa website. Voor de meeste commando's in deze handleiding wordt het programma 'time' gebruikt, zodat er achteraf nagegaan kan worden hoe lang een bepaalde handeling geduurd heeft. Dit kan weer handig zijn bij het inschatten van het benodige servicewindow als je meerdere installaties moet migreren. Mocht dit niet van belang zijn, dan kan het gedeelte 'time' uit het commando weggelaten worden. 2.1. Controles vooraf Voordat met de daadwerkelijke migratie gestart kan worden, dienen de volgende zaken gecontroleerd / nagekeken te worden. Is er genoeg harddisk ruimte beschikbaar op de machine? De hoeveelheid benodigde ruimte hangt af van: 1) de grootte van de Zarafa database 2) het percentage attachments in de database 3) de mate van compressie die mogelijk is op de rest van de database. De grootte van het totaal aantal attachments in een database is als volgt te achterhalen: mysql> use zarafa; mysql> show table status; Controleer de data_length kolom van de lob tabel. Deze bevat het aantal bytes dat benodigd is voor attachment storage. Op onze testserver bleek dat op de database zonder attachments een compressie mogelijk was van maar liefst 93%. Ga veiligheidshalve uit van 75%. Dit maakte de formule als volgt: Benodigde ruimte Zarafa DB grootte Grootte attachments Compressieratio S D A C Formule: S = (D A) * C + A Bij een database van bijvoorbeeld 10GB met daarin 5GB aan attachments waarbij de resterende database met 75% gecomprimeerd kan worden kom je dan uit op: (10-5) * 0,25 + 5 = 6,25 GB aan benodigde ruimte om de migratie te voltooien. Zorg ervoor dat MySQL is geupgrade naar versie 5, als dit niet al gedaan is. Migratie Zarafa 6.20 -> 6.40 01-11-2010 4 7

Is het vooraf ingeschatte maintenance window ruim genoeg gekozen? Hoe lang de migratie duurt hangt sterk van van de grootte van de Zarafa database, de gebruikte hardware en de load van de machine. Op onze testmachine (virtuele machine op een Intel Xeon 5120 1.86 Ghz, zonder andere activiteiten) duurde het converteren van een 13 GB database met 4GB aan attachments in totaal bijna een uur. Echter, bij onze eerste praktijk-migratie (virtuele machine op een Intel Xeon E5420 2.5 Ghz met een gemiddelde load) duurde het converteren van een 17GB database met 6GB aan attachments ruim drie uur! Kortom, load is een ontzettend belangrijke factor. Verder zul je tijd in moeten ruimen voor een eventuele backup vooraf. Is er een (getest) fallback scenario aanwezig voor als er onverhoopt zaken mis gaan? Zorg ervoor dat de 'license keys' voor Zarafa 6.30/6.40 beschikbaar zijn. De procedure voor het installeren van deze keys valt buiten de scope van deze handleiding. Is Zarafa de enige die gebruik maakt van de InnoDB storage engine op je machine? Zo niet, dan zul je extra stappen moeten ondernemen om deze databases veilig te stellen. Dit valt verder buiten de scope van deze handleiding. Controleer als volgt of alleen Zarafa gebruik maakt van InnoDB: mysql> SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.tables WHERE ENGINE = 'InnoDB'; ACHA Automation raadt aan om in een testomgeving na te gaan of onderstaand stappenplan ook gaat werken op jouw omgeving, voor dit toe te passen op een productie-omgeving. 2.2. Stappenplan migratie Zarafa 6.20 6.40 (via 6.30) Als alle voorafgaande zaken zorgvuldig zijn uitgevoerd / gecontroleerd, dan kunnen we nu (eindelijk) de migratie uitvoeren. Het stappenplan: 1. Safety first zorg er voor dat alle gebruikers Outlook hebben afgesloten en maak een backup van de bestaande configuratie en database(s) voordat je verder gaat. Aangezien er vele manieren zijn om deze backup te maken en veel bedrijven / systeembeheerders hun eigen voorkeur hier in hebben, valt dit verder buiten de scope van deze handleiding. 2. Zorg ervoor dat de MTA niet draait: # service sendmail stop 3. Zorg ervoor dat het Zarafa server proces niet draait: # service zarafa-server stop 4. Pas de configuratie van Zarafa aan zodat voortaan attachments buiten de database worden opgeslagen, zoals beschreven in paragraaf 4.2.3 van de Zarafa 6.40 Administrator Manual: Zoek in het bestand /etc/zarafa/server.cfg naar het gedeelte dat begint met 'attachment_storage ='. Vervang de waarde hierachter door 'files', zonder de quotes. Vul bij 'attachment_path =' in waar de attachments opgeslagen moeten worden. Deze handleiding gaat uit van '/share/zarafa_attachments' maar dit kan elke locatie op het systeem zijn waar het Zarafa proces lees- schijfrechten heeft. 5. Gebruik het script db-convert-attachments-to-files om attachments los te weken uit de database zoals beschreven in paragraaf 4.2.3 in de Zarafa 6.40 Administrator Manual. Indien het script niet wil draaien, installeer dan het pakket perl-dbd-mysql: # yum install perl-dbd-mysql Vergeet niet om de optie delete te gebruiken, anders blijven de attachments ook aanwezig in de database. Migratie Zarafa 6.20 -> 6.40 01-11-2010 5 7

Vul tussen de dubbele quotes ( ) in het onderstaande commando het wachtwoord in voor de root gebruiker in MySQL, als dit wachtwoord ingesteld is. De bestemming zoals aangegeven in onderstaande regel is /share/zarafa_attachments, pas dit naar wens aan. Aanbevolen wordt om deze locatie gelijk te houden aan de locatie die opgegeven is bij stap 4. Zorg er voor dat het script executable is (chmod +x /usr/share/zarafa/db-convert-attachments-tofiles), anders werkt onderstaande regel niet. # time /usr/share/zarafa/db-convert-attachments-to-files root "" zarafa /share/zarafa_attachments delete 6. Nadat het script klaar is, wordt op de achtergrond de lob-tabel nog verkleint. Monitor deze situatie tot de lob-tabel een grootte heeft van 16384: mysql> use zarafa; mysql> show table status; 7. Dump de database: # time mysqldump --single-transaction zarafa gzip > /share/backup_databases/zarafa.mysql.gz 8. Verwijder de bestaande database: # mysqladmin -u root -p drop zarafa 9. Stop MySQL: # service mysqld stop 10. Als je zeker weet dat alleen Zarafa gebruik maakt van InnoDB (zoals beschreven in hoofdstuk 2.1), verwijder / verplaats dan /var/lib/mysql/ib* 11. Start MySQL: # service mysqld start 12. Maak de database opnieuw aan: # mysqladmin -u root -p create zarafa 13. Controleer of de waarde 'Maximum packet size' in MySQL op 32 MB staat, anders zal de volgende stap halverwege de import resulteren in een foutmelding. 14. Lees de database opnieuw in: # time gunzip < /share/backup_databases/zarafa.mysql.gz mysql -u root zarafa 15. Controleer hoeveel kleiner het bestand /var/lib/mysql/ibdata1 nu is. 16. Indien de attachments niet lokaal gedumpt konden worden, zet deze dan nu vanaf de tijdelijke bestemming terug naar de plek die je hebt opgegeven in de zarafa configuratie (stap 4). 17. Navigeer naar de directory waar je de Zarafa 6.30 installatiebestanden hebt neergezet. Installeer Zarafa 6.30 en de benodigde afhankelijkheden: # yum install sysstat # rpm -Uvh *.rpm 18. Start het Zarafa 6.30 server proces met de volgende (eenmalige) toevoeging: # /usr/bin/zarafa-server --ignore-attachment-storage-conflict 19. Controleer of alles nog naar behoren werkt (met name attachments). Is dit niet het geval, ga dan niet verder. Onderzoek de oorzaak van het probleem. Kom je er niet uit, dan treedt nu je fallbackscenario in werking. Migratie Zarafa 6.20 -> 6.40 01-11-2010 6 7

20. Stop het Zarafa server proces: # service zarafa-server stop 21. Navigeer naar de directory waar je de Zarafa 6.40 installatiebestanden hebt neergezet. Upgrade Zarafa naar versie 6.40 en installeer de benodigde afhankelijkheden: # yum install lynx catdoc # rpm -Uvh zarafa*.rpm 22. Start het Zarafa 6.40 server proces: # service zarafa-server start 23. Herstart Apache: # service httpd restart 24. Controleer of alles nog naar behoren werkt. Is dit niet het geval, ga dan niet verder met de volgende stap. Onderzoek de oorzaak van het probleem. Kom je er niet uit, dan treedt nu je fallback-scenario in werking. 25. Start de MTA: # service sendmail start 3. Vragen? Mocht u naar aanleiding van deze handleiding nog vragen, opmerkingen en/of aanvullingen hebben, of heeft u vragen over ondersteuning op Zarafa in het algemeen, aarzelt u dan niet om contact met ons op te nemen: ACHA Automation B.V. Telefoon +31 (0)297 310 199 Industrieweg 35 A E-mail helpdesk@acha.nl / info@acha.nl 3641RK Mijdrecht The Netherlands www.acha.nl ACHA means 'GOOD' in Hindi, and that's exactly what ACHA is! Migratie Zarafa 6.20 -> 6.40 01-11-2010 7 7