Reduce downtime when updating Zimbra
These advantages of the Zimbra Collaboration Suite Open-Source Edition, such as reliability, high performance, and free solutions, should also include the fairly frequent appearance of new versions of Zimbra and the regular addition to them of the functions demanded by the community. For example, in the last year alone, such functions were added as the ability for a user to recover a password by himself, the ability to change the default calendar, support for hierarchical address books, and other business-friendly features. However, historically, IT managers in Russia do not particularly like updates.
The old as the world rule that it is not necessary to touch something that works fine anyway, was firmly entrenched in the heads of Russian IT workers at the end of the 1990s. Indeed, breaking the stability of update solutions, as well as abrupt changes in the interfaces that were introduced into the stupor of users, were common at that time. However, new times are throwing new challenges to IT managers and now the “do not touch what works like that” approach is simply not applicable. Information about the detection of vulnerabilities now flies around the world so quickly, and the army of cyber attackers write exploits for these vulnerabilities at such a rate that the use of outdated versions of the software in the enterprise carries enormous risks to information security. And especially these risks are great when it comes to collaboration platforms.
')
Another typical argument against regular updating of information systems in enterprises is the need to suspend their work during the installation of updates. And such an argument is really decisive for large enterprises and SaaS-providers, for whom the close 100% availability of service is important. That is why each developer, when designing and developing his own solution, tries to minimize or completely eliminate the idle time of a software solution when it is updated. The Zimbra developers are no exception.
Currently, it is possible to upgrade the Zimbra Collaboration Suite in an enterprise without the idleness 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. This process has already been described by us in a previous article. Those who are not ready to allocate additional server capacity for migration can use a number of tips to reduce Zimbra downtime during the upgrade process.
The upgrade process itself is a repetition of the Zimbra installation process using a newer version of the distribution. In other words, simply download the latest version of ZCS from Zimbra.com , and when starting the installation, the program will automatically detect the installed Zimbra on the server, and then offer to update it. In most situations, the update is automatic, but if you are upgrading from Zimbra version 8.6 or later, you may need to install the memcached and zimbra-proxy modules, which have become mandatory for installation, starting with Zimbra 8.7.
There are no tips for optimizing the time to update Zimbra for those who use the solution in a single server version, no. Typically, such installation options are used in small enterprises that can afford a break in the work of the collaboration system, especially if you plan to upgrade Zimbra for the evening or for the night.
As for the Zimbra multi-server installation, there are several techniques for reducing the downtime of the information system. First of all it concerns the order of installing updates. So, first of all you should update the server with LDAP. In the event that your company has LDAP Replica servers in addition to the main LDAP, in order to avoid lengthy downtime during their update, you can “upgrade” one of LDAP Replica to LDAP Master, at the same time using a firewall by denying connections to the real LDAP Master. If you have only one LDAP server in your infrastructure, you can avoid lengthy downtime during the upgrade process by creating a virtual LDAP Replica server. After the LDAP Master has been updated, it will be possible to re-enter it and then update the rest of the LDAP servers.
Next up are servers with Zimbra MTA and Zimbra Proxy. If you are upgrading from old versions of Zimbra, then after upgrading servers with the MTA, it is useful to run the following commands in the command line interface to ensure that the default settings are correct:
Only after all the sites with LDAP, MTA and Proxy are updated, you can proceed to update mail storages. Like all previous ones, mailbox servers should be updated one at a time. The doMoveMailbox function, which is sewn into a Zextras Powerstore zimlet, allows you to avoid inaccessibility of mailboxes and allows you to transfer user boxes from one mailbox to another within the same infrastructure. For example, the zxsuite powerstore team doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync will transfer the user@company.ru box from the first mail store to the second, leaving the corresponding entry in LDAP . After that, you should delete the mailbox from the old server using a command like zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru . And after the update of the mail storage is completed, you can make a transfer in the opposite direction, so that everything will return to its original state. Note that if you wish and have a complete list of mailboxes located in the mail storage, you can automate the process of transferring mailboxes to the new server and back. Also, using the doMoveMailbox command, you can avoid the inaccessibility of the most important for the enterprise mailboxes.
After all mail storages have been updated, the process of updating the Zimbra multiserver installation can be considered complete. Notable for users of idle time, if you used the doMoveMailbox command for all mailboxes, it was practically avoided.
The old as the world rule that it is not necessary to touch something that works fine anyway, was firmly entrenched in the heads of Russian IT workers at the end of the 1990s. Indeed, breaking the stability of update solutions, as well as abrupt changes in the interfaces that were introduced into the stupor of users, were common at that time. However, new times are throwing new challenges to IT managers and now the “do not touch what works like that” approach is simply not applicable. Information about the detection of vulnerabilities now flies around the world so quickly, and the army of cyber attackers write exploits for these vulnerabilities at such a rate that the use of outdated versions of the software in the enterprise carries enormous risks to information security. And especially these risks are great when it comes to collaboration platforms.
')
Another typical argument against regular updating of information systems in enterprises is the need to suspend their work during the installation of updates. And such an argument is really decisive for large enterprises and SaaS-providers, for whom the close 100% availability of service is important. That is why each developer, when designing and developing his own solution, tries to minimize or completely eliminate the idle time of a software solution when it is updated. The Zimbra developers are no exception.
Currently, it is possible to upgrade the Zimbra Collaboration Suite in an enterprise without the idleness 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. This process has already been described by us in a previous article. Those who are not ready to allocate additional server capacity for migration can use a number of tips to reduce Zimbra downtime during the upgrade process.
The upgrade process itself is a repetition of the Zimbra installation process using a newer version of the distribution. In other words, simply download the latest version of ZCS from Zimbra.com , and when starting the installation, the program will automatically detect the installed Zimbra on the server, and then offer to update it. In most situations, the update is automatic, but if you are upgrading from Zimbra version 8.6 or later, you may need to install the memcached and zimbra-proxy modules, which have become mandatory for installation, starting with Zimbra 8.7.
There are no tips for optimizing the time to update Zimbra for those who use the solution in a single server version, no. Typically, such installation options are used in small enterprises that can afford a break in the work of the collaboration system, especially if you plan to upgrade Zimbra for the evening or for the night.
As for the Zimbra multi-server installation, there are several techniques for reducing the downtime of the information system. First of all it concerns the order of installing updates. So, first of all you should update the server with LDAP. In the event that your company has LDAP Replica servers in addition to the main LDAP, in order to avoid lengthy downtime during their update, you can “upgrade” one of LDAP Replica to LDAP Master, at the same time using a firewall by denying connections to the real LDAP Master. If you have only one LDAP server in your infrastructure, you can avoid lengthy downtime during the upgrade process by creating a virtual LDAP Replica server. After the LDAP Master has been updated, it will be possible to re-enter it and then update the rest of the LDAP servers.
Next up are servers with Zimbra MTA and Zimbra Proxy. If you are upgrading from old versions of Zimbra, then after upgrading servers with the MTA, it is useful to run the following commands in the command line interface to ensure 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/sendmail Only after all the sites with LDAP, MTA and Proxy are updated, you can proceed to update mail storages. Like all previous ones, mailbox servers should be updated one at a time. The doMoveMailbox function, which is sewn into a Zextras Powerstore zimlet, allows you to avoid inaccessibility of mailboxes and allows you to transfer user boxes from one mailbox to another within the same infrastructure. For example, the zxsuite powerstore team doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync will transfer the user@company.ru box from the first mail store to the second, leaving the corresponding entry in LDAP . After that, you should delete the mailbox from the old server using a command like zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru . And after the update of the mail storage is completed, you can make a transfer in the opposite direction, so that everything will return to its original state. Note that if you wish and have a complete list of mailboxes located in the mail storage, you can automate the process of transferring mailboxes to the new server and back. Also, using the doMoveMailbox command, you can avoid the inaccessibility of the most important for the enterprise mailboxes.
After all mail storages have been updated, the process of updating the Zimbra multiserver installation can be considered complete. Notable for users of idle time, if you used the doMoveMailbox command for all mailboxes, it was practically avoided.
Source: https://habr.com/ru/post/445206/
All Articles