March 25, 2019 at 13:40Reduce downtime when upgrading Zimbra
Among the advantages of Zimbra Collaboration Suite Open-Source Edition, such as reliability, high performance, as well as a free solution, one should also mention the fairly frequent appearance of fresh versions of Zimbra and the regular addition of features demanded by the community in them. So, for example, only over the past year, features such as the ability to independently recover the password by the user, the ability to change the default calendar, support for hierarchical address books, and other useful business opportunities have been added. However, historically, IT managers in Russia do not particularly like updates.
The old as the world rule that you should not touch what works so well has firmly settled in the heads of Russian IT experts back in the late 90s. Indeed, breaking the stability of update solutions, as well as abrupt changes of interfaces, which introduced into a stupor of users, were commonplace at that time. However, new times pose new challenges for IT managers, and now the “do not touch what works” approach is simply not applicable. Information about vulnerability detection is spreading around the world so quickly, and armies of cyber-attackers are writing exploits for these vulnerabilities at such a rate that using outdated versions of software in the enterprise carries enormous risks for information security. And especially these risks are great when it comes to collaboration platforms.
Another typical argument against the regular updating of information systems in enterprises is the need to suspend their work during the installation of updates. And such an argument is indeed decisive for large enterprises and SaaS providers for whom the close 100% service availability is important. That is why every developer, when designing and developing his own solution, tries to minimize or completely reduce to zero the downtime of a software solution when updating it. The developers of Zimbra are no exception.
Currently, it is possible to upgrade the Zimbra Collaboration Suite in the enterprise without downtime of the information system itself, but in reality this process will turn out to be a seamless migration from one Zimbra server to another, where a more recent version of ZCS is already installed using Zextras Suite. We have already described this process in a previous article. Those who are not ready to allocate additional server capacities for migration can use a number of tips to reduce Zimbra downtime during the upgrade process.
The update process itself is a repetition of the Zimbra installation process using a newer version of the distribution. In other words, just download from Zimbra.comthe latest version of ZCS, and when the installation starts, the program will automatically detect the installed Zimbra on the server, and then offer to update it. In most situations, the update takes place automatically, but if you are upgrading from Zimbra version 8.6 or later, you may need to reinstall the memcached and zimbra-proxy modules, which have become mandatory for installation starting from version Zimbra 8.7.
There are no tips for optimizing the time to upgrade Zimbra for those using the single-server solution. Typically, these installation options are used in small enterprises that can afford to interrupt the collaboration system, especially if you plan to upgrade Zimbra in the evening or at night.
As for the Zimbra multiserver installation, there are several tricks to reduce the downtime of the information system. First of all, this concerns the installation of updates. So, first of all, you should upgrade the server with LDAP. In the event that in your company, in addition to the main LDAP, there are servers with LDAP Replica, then in order to avoid long downtime during their upgrade you can “upgrade” one of the LDAP Replica to LDAP Master, at the same time using a firewall to ban connections to real LDAP Master If your infrastructure has only one LDAP server, you can avoid long downtime during its upgrade by creating a virtual LDAP Replica server. After the LDAP Master is updated, it will be possible to put it back into operation, and then update the remaining LDAP servers.
Next servers with Zimbra MTA and Zimbra Proxy. If you are upgrading from older versions of Zimbra, then after upgrading the servers with MTA, it is not superfluous to execute the following commands in the command line interface so that the default settings are correct:
Only after all nodes with LDAP, MTA and Proxy have been updated can you start upgrading your mail stores. Like all previous ones, servers with mailboxes should be updated one at a time. The doMoveMailbox function, which is sewn into the Zextras Powerstore winterlet and allows you to transfer user mailboxes from one mailbox to another within the same infrastructure, will help to avoid inaccessibility of mailboxes. So, for example, the command zxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync will transfer the user box user@company.ru from the first mail store to the second, leaving the corresponding entry in LDAP . After that, delete the mailbox from the old server using the command of the formzmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru . And after the upgrade of the mail storage is completed, you can make the transfer in the opposite direction, so that everything returns to its original state. Note that if you wish and have a complete list of mailboxes located in the mail store, you can automate the process of transferring mailboxes to a new server and vice versa. You can also use the doMoveMailbox command to prevent unavailability of the most important mailboxes for your enterprise.
After all mail storages have been updated, the upgrade process of the Zimbra multiserver installation can be considered completed. Notable downtime for users if you used the doMoveMailbox commandfor all mailboxes, it was practically possible to avoid.
For all questions related to the Zextras Suite, you can contact the representative of the company "Zextras" Katerina Triandafilidi by e-mail katerina@zextras.com
The old as the world rule that you should not touch what works so well has firmly settled in the heads of Russian IT experts back in the late 90s. Indeed, breaking the stability of update solutions, as well as abrupt changes of interfaces, which introduced into a stupor of users, were commonplace at that time. However, new times pose new challenges for IT managers, and now the “do not touch what works” approach is simply not applicable. Information about vulnerability detection is spreading around the world so quickly, and armies of cyber-attackers are writing exploits for these vulnerabilities at such a rate that using outdated versions of software in the enterprise carries enormous risks for information security. And especially these risks are great when it comes to collaboration platforms.
Another typical argument against the regular updating of information systems in enterprises is the need to suspend their work during the installation of updates. And such an argument is indeed decisive for large enterprises and SaaS providers for whom the close 100% service availability is important. That is why every developer, when designing and developing his own solution, tries to minimize or completely reduce to zero the downtime of a software solution when updating it. The developers of Zimbra are no exception.
Currently, it is possible to upgrade the Zimbra Collaboration Suite in the enterprise without downtime of the information system itself, but in reality this process will turn out to be a seamless migration from one Zimbra server to another, where a more recent version of ZCS is already installed using Zextras Suite. We have already described this process in a previous article. Those who are not ready to allocate additional server capacities for migration can use a number of tips to reduce Zimbra downtime during the upgrade process.
The update process itself is a repetition of the Zimbra installation process using a newer version of the distribution. In other words, just download from Zimbra.comthe latest version of ZCS, and when the installation starts, the program will automatically detect the installed Zimbra on the server, and then offer to update it. In most situations, the update takes place automatically, but if you are upgrading from Zimbra version 8.6 or later, you may need to reinstall the memcached and zimbra-proxy modules, which have become mandatory for installation starting from version Zimbra 8.7.
There are no tips for optimizing the time to upgrade Zimbra for those using the single-server solution. Typically, these installation options are used in small enterprises that can afford to interrupt the collaboration system, especially if you plan to upgrade Zimbra in the evening or at night.
As for the Zimbra multiserver installation, there are several tricks to reduce the downtime of the information system. First of all, this concerns the installation of updates. So, first of all, you should upgrade the server with LDAP. In the event that in your company, in addition to the main LDAP, there are servers with LDAP Replica, then in order to avoid long downtime during their upgrade you can “upgrade” one of the LDAP Replica to LDAP Master, at the same time using a firewall to ban connections to real LDAP Master If your infrastructure has only one LDAP server, you can avoid long downtime during its upgrade by creating a virtual LDAP Replica server. After the LDAP Master is updated, it will be possible to put it back into operation, and then update the remaining LDAP servers.
Next servers with Zimbra MTA and Zimbra Proxy. If you are upgrading from older versions of Zimbra, then after upgrading the servers with MTA, it is not superfluous to execute the following commands in the command line interface so that the default settings are correct:
zmprov mcf zimbraMtaCommandDirectory /opt/zimbra/common/sbin
zmprov mcf zimbraMtaDaemonDirectory /opt/zimbra/common/libexec
zmprov mcf zimbraMtaMailqPath /opt/zimbra/common/sbin/mailq
zmprov mcf zimbraMtaManpageDirectory /opt/zimbra/common/share/man
zmprov mcf zimbraMtaNewaliasesPath /opt/zimbra/common/sbin/newaliases
zmprov mcf zimbraMtaSendmailPath /opt/zimbra/common/sbin/sendmailOnly after all nodes with LDAP, MTA and Proxy have been updated can you start upgrading your mail stores. Like all previous ones, servers with mailboxes should be updated one at a time. The doMoveMailbox function, which is sewn into the Zextras Powerstore winterlet and allows you to transfer user mailboxes from one mailbox to another within the same infrastructure, will help to avoid inaccessibility of mailboxes. So, for example, the command zxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync will transfer the user box user@company.ru from the first mail store to the second, leaving the corresponding entry in LDAP . After that, delete the mailbox from the old server using the command of the formzmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru . And after the upgrade of the mail storage is completed, you can make the transfer in the opposite direction, so that everything returns to its original state. Note that if you wish and have a complete list of mailboxes located in the mail store, you can automate the process of transferring mailboxes to a new server and vice versa. You can also use the doMoveMailbox command to prevent unavailability of the most important mailboxes for your enterprise.
After all mail storages have been updated, the upgrade process of the Zimbra multiserver installation can be considered completed. Notable downtime for users if you used the doMoveMailbox commandfor all mailboxes, it was practically possible to avoid.
For all questions related to the Zextras Suite, you can contact the representative of the company "Zextras" Katerina Triandafilidi by e-mail katerina@zextras.com