DR Best Practices In a Virtualized Environment?
Posted: Thu Dec 06, 2012 12:48 pm
WE ARE A ZIMBRA HOSTING PROVIDER PROVIDER RUNNING A VIRTUALISED ZIMBRA FARM ON 7.2.1 PRESENTLY; WE ALSO SUPPORT MULTIPLE CLIENTS' VIRTUALISED ZIMBRA MULTI- AND SINGLE-SERVER ENVIRONMENTS. ALL OF OUR STORAGE IS SAN-BACKED.
WE ARE LOOKING TO IMPROVE OUR DR METHODOLOGIES IN THE EVENT A SANDY/IRENE/KATRINA OR SIMILAR EVENT TAKES, OR IS EXPECTED TO TAKE, DOWN THE PRIMARY DATA CENTER SITE, AND A FAILOVER TO THE SECONDARY DATA CENTER AT LEAST SEVERAL HUNDRED MILES AWAY IS MADE.
SPECIFICALLY, WE ARE LOOKING FOR A ZIMBRA-SUPPORTED PROCESS WHICH:
IS HYPERVISOR AGNOSTIC (BUT WHICH MAY RELY ON HYPERVISOR-SPECIFIC DATA TRANSPORT TOOLS).
IS DATA-SAFE (E.G. DOES NOT RELY ON RSYNCING THE ENTIRE /OPT/ZIMBRA TREE WITHOUT USING LDIF TO COPY LDAP FROM THE PRODUCTION TO THE DR SITE WITH ZIMBRA VERSIONS PRIOR TO 8).
IS, TO THE EXTENT POSSIBLE, ZIMBRA SERVER-VERSION AGNOSTIC.
BY LEVERAGING INTRA-DAY TRANSPORT OF THE REDO LOGS, MINIMIZES LOSS OF DATA WHEN FAILING OVER TO THE DR SITE.
MINIMIZES THE TIME TO "LIGHT UP" A WORKING DR SITE ONCE A DECISION IS MADE TO FAILOVER.
BACKGROUND
HISTORICALLY OUR DR HAS RELIED ON HAVING COLD STANDBY ZIMBRA SERVERS READY IN THE SECONDARY DATA CENTER; RSYNCING THE ZIMBRA NE BACKUPS FROM THE PRIMARY TO THE SECONDARY DATA CENTER; RUNNING ZMRESTORELDAP AND ZMRESTOREOFFLINE FOLLOWED BY MAKING CHANGES TO PUBLIC DNS TO COMPLETE THE FAILOVER. AS THE STORE SIZES GROW, THIS PROCESS CONSUMES A GREAT DEAL OF INTER-DATA CENTER BANDWIDTH (TO RSYNC THE BACKUPS) AND INCREASES THE TIME TO COMPLETE THE FAILOVER AS ZMRESTOREOFFLINE TAKES A FAIR AMOUNT OF TIME TO DO ITS WORK.
THE ADMIN GUIDE POINTS OUT (NE 7.2, APRIL 2012 EDITION, PAGE 239) THAT STORAGE LAYER SNAPSHOTS, IN CONJUNCTION WITH ZMPLAYREDO, MAY BE USED AS AN ALTERNATIVE TO ZIMBRA'S OWN BACKUP AND RESTORE FEATURE BY LEVERAGING ZIMBRA'S REDO LOGS. BUT THE ADMIN GUIDE DOES NOT LAY OUT THE ENTIRE REDOLOG DR PROCESS TO THE EXTENT IT DOES FOR A ZIMBRA SERVER REPLACEMENT.
CONSEQUENTLY, WE ARE STARTING THIS THREAD TO TRY TO DOCUMENT THIS REDO LOG-BASED DR PROCESS. ONCE DONE, I'M HAPPY TO WRITE A WIKI ARTICLE AND SUGGEST ZIMBRA MARK IT AS CERTIFIED DOCUMENTATION ONCE THEY HAVE QA'D IT. WE ARE SEEING HARDLY ANY NEW ZIMBRA INSTALLS GOING ON BARE METAL, SO UPGRADING THE DOCUMENTED DR PROCESSES TO TAKE ADVANTAGE OF HYPERVISOR-RELATED TECHNOLOGIES SEEMS TIMELY. PLEASE HELP!
PROPOSED HIGH-LEVEL DR PROCESS
READING BETWEEN THE LINES OF THE ABOVE-MENTIONED ADMIN GUIDE PROCESS, WE ARE CONTEMPLATING TESTING THE FOLLOWING PROCESS, AND WOULD BE GRATEFUL FOR FEEDBACK FROM THE COMMUNITY BEFORE WE GET TOO FAR AHEAD OF OURSELVES HERE. AT A HIGH LEVEL, THE PROCESS IT SEEMS TO US WOULD COMPRISE:
ONE-TIME OR INFREQUENT INITIALIZATION TASKS
SHORTEN THE TTLS FOR ALL ZIMBRA SERVER PUBLIC DNS RECORDS, AND/OR USE A THIRD-PARTY DNS PROVIDER WHO CAN ORCHESTRATE RAPID DNS FAILOVER-BASED CHANGES.
ON THE PRODUCTION ZIMBRA SERVERS, AS ROOT DO A "CHKCONFIG ZIMBRA OFF", THEN AS THE ZIMBRA USER DO A ZMCONTROL STOP, SHUT DOWN THE VIRTUAL MACHINE, NOTE THE EXACT TIME, TAKE A HYPERVISOR-LEVEL SNAPSHOT OF THE ZIMBRA VIRTUAL MACHINES AND THEN RESTART THE VIRTUAL MACHINES AND ZIMBRA, AND THEN AS ROOT RUN "CHKCONFIG ZIMBRA ON".
DEPENDING ON THE HYPERVISOR, USE APPROPRIATE PROCEDURES TO CREATE CLONES OF THE ZIMBRA SERVERS FROM THE SNAPSHOTS AND TRANSFER THEM TO THE DR DATA CENTER.
(AS AND WHEN PRODUCTION ZIMBRA IS UPGRADED/PATCHED, STEPS 2. AND 3. HERE WILL NEED TO BE REPEATED).
AT THE DR SITE, BOOT THE CLONED ZIMBRA MAILBOX SERVERS ONLY (ZIMBRA ITSELF WILL NOT START AND SHOULD NOT BE STARTED)
ROUTINE SYNCING BETWEEN THE PRODUCTION AND DR SERVERS
SCHEDULE A CRON JOB WHICH, AFTER EACH ZMBACKUP ON THE PRODUCTION SERVERS, RSYNCS FROM /OPT/ZIMBRA/BACKUP ON THE PRODUCTION SERVERS TO THE DR SERVERS JUST /OPT/ZIMBRA/BACKUP/LDAP AND /OPT/ZIMBRA/BACKUP/SYS (FOR FULL BACKUPS) AND /OPT/ZIMBRA/BACKUP/LDAP, /OPT/ZIMBRA/BACKUP/SYS AND /OPT/ZIMBRA/BACKUP/REDOLOGS (FOR INCREMENTAL BACKUPS).
AFTER THE ABOVE RSYNC IS COMPLETE, RUN ZMRESTORELDAP DAILY AND ZMPLAYREDO --LOGFILE=/OPT/ZIMBRA/BACKUP/SESSIONS/INCR-[SESSIONID] AFTER THE INCREMENTAL BACKUP RSYNCS ONLY.
IN ZIMBRA'S CRONTAB AT THE DR SITE, COMMENT OUT THE LINES WHICH RUN FULL AND INCREMENTAL ZMBACKUP, BUT KEEP THE LINE WHICH PRUNES OLDER BACKUPS.
SCHEDULE A CRON JOB WHICH EVERY HOUR OR SO, RSYNCS /OPT/ZIMBRA/REDOLOG WITH THE --DELETE SWITCH FROM THE PRODUCTION ZIMBRA MAILBOX SERVERS TO THE DR SITE ZIMBRA MAILBOX SERVERS.
FAILOVER TO DR SITE PROCESS
ON THE DR ZIMBRA MAILBOX SERVERS, RUN ZMPLAYREDO --LOGFILE=/OPT/ZIMBRA/REDOLOG ONE LAST TIME, THEN START ZIMBRA ON ALL DR SERVERS.
IF THE PRODUCTION SITE IS STILL REACHABLE, SHUTDOWN THE ZIMBRA SERVERS.
UPDATE PUBLIC DNS TO POINT TO THE DR ZIMBRA SERVERS.
QUESTIONS AND MISSING BITS
IS IT TRUE THAT, ONCE A ZIMBRA SERVER IS SNAPSHOTTED AS ABOVE AND TRANSPORTED TO THE DR SITE, KEEPING THIS DR ZIMBRA SERVER PERIODICALLY IN SYNC WITH THE PRODUCTION SITE REQUIRES ONLY RESTORING A RECENT VERSION OF LDAP AND REPLAYING THE REDO LOGS? IS THERE ANY OTHER DATA WHICH NEEDS TO COPIED OVER TO AVOID HAVING TO SHIP THE ENTIRE /OPT/ZIMBRA/BACKUP TREE BETWEEN THE PRODUCTION AND DR SITES?
IS ANYONE USING THIS TECHNIQUE (OR A VARIATION THEREOF) PRESENTLY, AND HAVE YOU EVER TESTED, OR ACTUALLY HAD TO, FAIL OVER TO THE DR SITE?
WHAT ELSE NEEDS TO BE INCLUDED FROM A PROCESS STANDPOINT THAT WE HAVEN'T THOUGHT OF?
THANKS!
MARK
WE ARE LOOKING TO IMPROVE OUR DR METHODOLOGIES IN THE EVENT A SANDY/IRENE/KATRINA OR SIMILAR EVENT TAKES, OR IS EXPECTED TO TAKE, DOWN THE PRIMARY DATA CENTER SITE, AND A FAILOVER TO THE SECONDARY DATA CENTER AT LEAST SEVERAL HUNDRED MILES AWAY IS MADE.
SPECIFICALLY, WE ARE LOOKING FOR A ZIMBRA-SUPPORTED PROCESS WHICH:
IS HYPERVISOR AGNOSTIC (BUT WHICH MAY RELY ON HYPERVISOR-SPECIFIC DATA TRANSPORT TOOLS).
IS DATA-SAFE (E.G. DOES NOT RELY ON RSYNCING THE ENTIRE /OPT/ZIMBRA TREE WITHOUT USING LDIF TO COPY LDAP FROM THE PRODUCTION TO THE DR SITE WITH ZIMBRA VERSIONS PRIOR TO 8).
IS, TO THE EXTENT POSSIBLE, ZIMBRA SERVER-VERSION AGNOSTIC.
BY LEVERAGING INTRA-DAY TRANSPORT OF THE REDO LOGS, MINIMIZES LOSS OF DATA WHEN FAILING OVER TO THE DR SITE.
MINIMIZES THE TIME TO "LIGHT UP" A WORKING DR SITE ONCE A DECISION IS MADE TO FAILOVER.
BACKGROUND
HISTORICALLY OUR DR HAS RELIED ON HAVING COLD STANDBY ZIMBRA SERVERS READY IN THE SECONDARY DATA CENTER; RSYNCING THE ZIMBRA NE BACKUPS FROM THE PRIMARY TO THE SECONDARY DATA CENTER; RUNNING ZMRESTORELDAP AND ZMRESTOREOFFLINE FOLLOWED BY MAKING CHANGES TO PUBLIC DNS TO COMPLETE THE FAILOVER. AS THE STORE SIZES GROW, THIS PROCESS CONSUMES A GREAT DEAL OF INTER-DATA CENTER BANDWIDTH (TO RSYNC THE BACKUPS) AND INCREASES THE TIME TO COMPLETE THE FAILOVER AS ZMRESTOREOFFLINE TAKES A FAIR AMOUNT OF TIME TO DO ITS WORK.
THE ADMIN GUIDE POINTS OUT (NE 7.2, APRIL 2012 EDITION, PAGE 239) THAT STORAGE LAYER SNAPSHOTS, IN CONJUNCTION WITH ZMPLAYREDO, MAY BE USED AS AN ALTERNATIVE TO ZIMBRA'S OWN BACKUP AND RESTORE FEATURE BY LEVERAGING ZIMBRA'S REDO LOGS. BUT THE ADMIN GUIDE DOES NOT LAY OUT THE ENTIRE REDOLOG DR PROCESS TO THE EXTENT IT DOES FOR A ZIMBRA SERVER REPLACEMENT.
CONSEQUENTLY, WE ARE STARTING THIS THREAD TO TRY TO DOCUMENT THIS REDO LOG-BASED DR PROCESS. ONCE DONE, I'M HAPPY TO WRITE A WIKI ARTICLE AND SUGGEST ZIMBRA MARK IT AS CERTIFIED DOCUMENTATION ONCE THEY HAVE QA'D IT. WE ARE SEEING HARDLY ANY NEW ZIMBRA INSTALLS GOING ON BARE METAL, SO UPGRADING THE DOCUMENTED DR PROCESSES TO TAKE ADVANTAGE OF HYPERVISOR-RELATED TECHNOLOGIES SEEMS TIMELY. PLEASE HELP!
PROPOSED HIGH-LEVEL DR PROCESS
READING BETWEEN THE LINES OF THE ABOVE-MENTIONED ADMIN GUIDE PROCESS, WE ARE CONTEMPLATING TESTING THE FOLLOWING PROCESS, AND WOULD BE GRATEFUL FOR FEEDBACK FROM THE COMMUNITY BEFORE WE GET TOO FAR AHEAD OF OURSELVES HERE. AT A HIGH LEVEL, THE PROCESS IT SEEMS TO US WOULD COMPRISE:
ONE-TIME OR INFREQUENT INITIALIZATION TASKS
SHORTEN THE TTLS FOR ALL ZIMBRA SERVER PUBLIC DNS RECORDS, AND/OR USE A THIRD-PARTY DNS PROVIDER WHO CAN ORCHESTRATE RAPID DNS FAILOVER-BASED CHANGES.
ON THE PRODUCTION ZIMBRA SERVERS, AS ROOT DO A "CHKCONFIG ZIMBRA OFF", THEN AS THE ZIMBRA USER DO A ZMCONTROL STOP, SHUT DOWN THE VIRTUAL MACHINE, NOTE THE EXACT TIME, TAKE A HYPERVISOR-LEVEL SNAPSHOT OF THE ZIMBRA VIRTUAL MACHINES AND THEN RESTART THE VIRTUAL MACHINES AND ZIMBRA, AND THEN AS ROOT RUN "CHKCONFIG ZIMBRA ON".
DEPENDING ON THE HYPERVISOR, USE APPROPRIATE PROCEDURES TO CREATE CLONES OF THE ZIMBRA SERVERS FROM THE SNAPSHOTS AND TRANSFER THEM TO THE DR DATA CENTER.
(AS AND WHEN PRODUCTION ZIMBRA IS UPGRADED/PATCHED, STEPS 2. AND 3. HERE WILL NEED TO BE REPEATED).
AT THE DR SITE, BOOT THE CLONED ZIMBRA MAILBOX SERVERS ONLY (ZIMBRA ITSELF WILL NOT START AND SHOULD NOT BE STARTED)
ROUTINE SYNCING BETWEEN THE PRODUCTION AND DR SERVERS
SCHEDULE A CRON JOB WHICH, AFTER EACH ZMBACKUP ON THE PRODUCTION SERVERS, RSYNCS FROM /OPT/ZIMBRA/BACKUP ON THE PRODUCTION SERVERS TO THE DR SERVERS JUST /OPT/ZIMBRA/BACKUP/LDAP AND /OPT/ZIMBRA/BACKUP/SYS (FOR FULL BACKUPS) AND /OPT/ZIMBRA/BACKUP/LDAP, /OPT/ZIMBRA/BACKUP/SYS AND /OPT/ZIMBRA/BACKUP/REDOLOGS (FOR INCREMENTAL BACKUPS).
AFTER THE ABOVE RSYNC IS COMPLETE, RUN ZMRESTORELDAP DAILY AND ZMPLAYREDO --LOGFILE=/OPT/ZIMBRA/BACKUP/SESSIONS/INCR-[SESSIONID] AFTER THE INCREMENTAL BACKUP RSYNCS ONLY.
IN ZIMBRA'S CRONTAB AT THE DR SITE, COMMENT OUT THE LINES WHICH RUN FULL AND INCREMENTAL ZMBACKUP, BUT KEEP THE LINE WHICH PRUNES OLDER BACKUPS.
SCHEDULE A CRON JOB WHICH EVERY HOUR OR SO, RSYNCS /OPT/ZIMBRA/REDOLOG WITH THE --DELETE SWITCH FROM THE PRODUCTION ZIMBRA MAILBOX SERVERS TO THE DR SITE ZIMBRA MAILBOX SERVERS.
FAILOVER TO DR SITE PROCESS
ON THE DR ZIMBRA MAILBOX SERVERS, RUN ZMPLAYREDO --LOGFILE=/OPT/ZIMBRA/REDOLOG ONE LAST TIME, THEN START ZIMBRA ON ALL DR SERVERS.
IF THE PRODUCTION SITE IS STILL REACHABLE, SHUTDOWN THE ZIMBRA SERVERS.
UPDATE PUBLIC DNS TO POINT TO THE DR ZIMBRA SERVERS.
QUESTIONS AND MISSING BITS
IS IT TRUE THAT, ONCE A ZIMBRA SERVER IS SNAPSHOTTED AS ABOVE AND TRANSPORTED TO THE DR SITE, KEEPING THIS DR ZIMBRA SERVER PERIODICALLY IN SYNC WITH THE PRODUCTION SITE REQUIRES ONLY RESTORING A RECENT VERSION OF LDAP AND REPLAYING THE REDO LOGS? IS THERE ANY OTHER DATA WHICH NEEDS TO COPIED OVER TO AVOID HAVING TO SHIP THE ENTIRE /OPT/ZIMBRA/BACKUP TREE BETWEEN THE PRODUCTION AND DR SITES?
IS ANYONE USING THIS TECHNIQUE (OR A VARIATION THEREOF) PRESENTLY, AND HAVE YOU EVER TESTED, OR ACTUALLY HAD TO, FAIL OVER TO THE DR SITE?
WHAT ELSE NEEDS TO BE INCLUDED FROM A PROCESS STANDPOINT THAT WE HAVEN'T THOUGHT OF?
THANKS!
MARK