К таким преимуществам Zimbra Collaboration Suite Open-Source Edition, как надежность, высокое быстродействие, а также бесплатность решения, следует отнести еще и достаточно частое появление свежих версий Zimbra и регулярное добавление в них востребованных сообществом функций. Так, например, только за последний год были добавлены такие функции как возможность самостоятельного восстановления пароля пользователем, возможность смены календаря по умолчанию, поддержка иерархических адресных книг и прочие полезные для бизнеса возможности. Впрочем, исторически так сложилось, что ИТ-менеджеры в России не особо любят обновления.
Старое как мир правило о том, что не стоит трогать то, что и так прекрасно работает, прочно засело в головы российских ИТ-шников еще в конце 90-ых годов. И действительно, ломающие стабильность работы решений обновления, а также резкие смены интерфейсов, которые вводили в ступор пользователей, были обычным делом в то время. Однако новые времена бросают ИТ-менеджерам новые вызовы и сейчас подход в стиле «не трогай то, что и так работает», попросту неприменим. Информация об обнаружении уязвимостей сейчас разлетается по миру так быстро, а армии киберзлоумышленников пишут эксплоиты для этих уязвимостей с такой скоростью, что использование устаревших версий программного обеспечения на предприятии сопряжено с гигантскими рисками для информационной безопасности. И особенно эти риски велики в тех случаях, когда речь идет о платформах для совместной работы.
Еще один типичный аргумент против регулярного обновления информационных систем на предприятиях — необходимость приостановки их работы на время установки апдейтов. И такой аргумент действительно является решающим для крупных предприятий и SaaS-провайдеров, для которых важна близкая 100% доступность сервиса. Именно поэтому каждый разработчик при проектировании и разработке своего решения старается минимизировать или вовсе свести к нулю время простоя программного решения при его обновлении. Не являются исключением и разработчики Zimbra.
В настоящее время обновить Zimbra Collaboration Suite на предприятии без простоя самой информационной системы можно, но на деле этот процесс окажется бесшовной миграцией с одного сервера Zimbra на другой, где уже установлена более свежая версия ZCS с помощью Zextras Suite. Этот процесс уже был нами описан в одной из предыдущих статей. Те все же, кто не готов выделять дополнительные серверные мощности для миграции, могут воспользоваться рядом советов для уменьшения времени простоя Zimbra в процессе обновления.
Сам процесс обновления представляет из себя повторение процесса установки Zimbra с использованием более новой версии дистрибутива. Иными словами, достаточно просто скачать с сайта Zimbra.com свежую версию ZCS, и при запуске установки программа самостоятельно обнаружит на сервере установленную Zimbra, после чего предложит обновить ее. В большинстве ситуаций обновление происходит в автоматическом режиме, но в случае, если вы обновляетесь с Zimbra версии 8.6 и старше, то вам может понадобиться доустановить модули memcached и zimbra-proxy, которые стали обязательными для установки, начиная с версии Zimbra 8.7.
Каких-либо советов по оптимизации времени на обновление Zimbra для тех, кто использует решение в односерверном варианте, нет. Обычно такие варианты установки используются на небольших предприятиях, которые могут позволить себе перерыв в работе системы совместной работы, особенно если запланировать обновление Zimbra на вечер или на ночь.
Что касается мультисерверной установки Zimbra, то здесь есть несколько приемов для сокращения времени простоя информационной системы. В первую очередь это касается порядка установки обновлений. Так, в первую очередь следует обновить сервер с LDAP. В том случае, если в вашей компании помимо основного LDAP есть серверы с LDAP Replica, то для избежания длительного простоя во время их обновления вы можете «повысить» один из LDAP Replica до LDAP Master, одновременно с этим с помощью брандмауэра запретив подключения к настоящему LDAP Master. Если же в вашей инфраструктуре всего один сервер LDAP, то избежать длительного простоя во время его обновления можно с помощью создания виртуального сервера LDAP Replica. После того как LDAP Master будет обновлен, можно будет вновь ввести его в работу, а затем обновить остальные LDAP-серверы.
Следующие на очереди серверы с Zimbra MTA и Zimbra Proxy. Если вы обновляетесь со старых версий Zimbra, то после обновления серверов c MTA не лишним будет выполнить следующие команды в интерфейсе командной строки для того, чтобы настройки по умолчанию были верными:
Лишь после того как все узлы с LDAP, MTA и Proxy обновлены, можно приступать к обновлению почтовых хранилищ. Как и все предыдущие, серверы с почтовыми ящикам следует обновлять по одному. Избежать недоступности почтовых ящиков поможет функция doMoveMailbox, которая вшита в зимлет Zextras Powerstore и позволяет переносить ящики пользователей с одного почтового хранилища на другое в рамках одной инфраструктуры. Так, например, команда zxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync перенесет ящик пользователя user@company.ru с первого почтового хранилища на второе, оставив соответствующую запись в LDAP. После этого следует удалить почтовый ящик со старого сервера с помощью команды вида zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru. А уже после завершения обновления почтового хранилища можно совершить перенос в обратном направлении, чтобы все вернулось к исходному состоянию. Отметим, что при желании и наличии полного перечня почтовых ящиков, располагавшихся в почтовом хранилище можно автоматизировать процесс переноса почтовых ящиков на новый сервер и обратно. Также с помощью команды doMoveMailbox можно избежать недоступности наиболее важных для предприятия почтовых ящиков.
После того как будут обновлены все почтовые хранилища, процесс обновления мультисерверной установки Zimbra можно считать завершенным. Заметного для пользователей простоя, если вы использовали команду doMoveMailbox для всех почтовых ящиков, практически удалось избежать.
По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
Старое как мир правило о том, что не стоит трогать то, что и так прекрасно работает, прочно засело в головы российских ИТ-шников еще в конце 90-ых годов. И действительно, ломающие стабильность работы решений обновления, а также резкие смены интерфейсов, которые вводили в ступор пользователей, были обычным делом в то время. Однако новые времена бросают ИТ-менеджерам новые вызовы и сейчас подход в стиле «не трогай то, что и так работает», попросту неприменим. Информация об обнаружении уязвимостей сейчас разлетается по миру так быстро, а армии киберзлоумышленников пишут эксплоиты для этих уязвимостей с такой скоростью, что использование устаревших версий программного обеспечения на предприятии сопряжено с гигантскими рисками для информационной безопасности. И особенно эти риски велики в тех случаях, когда речь идет о платформах для совместной работы.
Еще один типичный аргумент против регулярного обновления информационных систем на предприятиях — необходимость приостановки их работы на время установки апдейтов. И такой аргумент действительно является решающим для крупных предприятий и SaaS-провайдеров, для которых важна близкая 100% доступность сервиса. Именно поэтому каждый разработчик при проектировании и разработке своего решения старается минимизировать или вовсе свести к нулю время простоя программного решения при его обновлении. Не являются исключением и разработчики Zimbra.
В настоящее время обновить Zimbra Collaboration Suite на предприятии без простоя самой информационной системы можно, но на деле этот процесс окажется бесшовной миграцией с одного сервера Zimbra на другой, где уже установлена более свежая версия ZCS с помощью Zextras Suite. Этот процесс уже был нами описан в одной из предыдущих статей. Те все же, кто не готов выделять дополнительные серверные мощности для миграции, могут воспользоваться рядом советов для уменьшения времени простоя Zimbra в процессе обновления.
Сам процесс обновления представляет из себя повторение процесса установки Zimbra с использованием более новой версии дистрибутива. Иными словами, достаточно просто скачать с сайта Zimbra.com свежую версию ZCS, и при запуске установки программа самостоятельно обнаружит на сервере установленную Zimbra, после чего предложит обновить ее. В большинстве ситуаций обновление происходит в автоматическом режиме, но в случае, если вы обновляетесь с Zimbra версии 8.6 и старше, то вам может понадобиться доустановить модули memcached и zimbra-proxy, которые стали обязательными для установки, начиная с версии Zimbra 8.7.
Каких-либо советов по оптимизации времени на обновление Zimbra для тех, кто использует решение в односерверном варианте, нет. Обычно такие варианты установки используются на небольших предприятиях, которые могут позволить себе перерыв в работе системы совместной работы, особенно если запланировать обновление Zimbra на вечер или на ночь.
Что касается мультисерверной установки Zimbra, то здесь есть несколько приемов для сокращения времени простоя информационной системы. В первую очередь это касается порядка установки обновлений. Так, в первую очередь следует обновить сервер с LDAP. В том случае, если в вашей компании помимо основного LDAP есть серверы с LDAP Replica, то для избежания длительного простоя во время их обновления вы можете «повысить» один из LDAP Replica до LDAP Master, одновременно с этим с помощью брандмауэра запретив подключения к настоящему LDAP Master. Если же в вашей инфраструктуре всего один сервер LDAP, то избежать длительного простоя во время его обновления можно с помощью создания виртуального сервера LDAP Replica. После того как LDAP Master будет обновлен, можно будет вновь ввести его в работу, а затем обновить остальные LDAP-серверы.
Следующие на очереди серверы с Zimbra MTA и Zimbra Proxy. Если вы обновляетесь со старых версий Zimbra, то после обновления серверов c MTA не лишним будет выполнить следующие команды в интерфейсе командной строки для того, чтобы настройки по умолчанию были верными:
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Лишь после того как все узлы с LDAP, MTA и Proxy обновлены, можно приступать к обновлению почтовых хранилищ. Как и все предыдущие, серверы с почтовыми ящикам следует обновлять по одному. Избежать недоступности почтовых ящиков поможет функция doMoveMailbox, которая вшита в зимлет Zextras Powerstore и позволяет переносить ящики пользователей с одного почтового хранилища на другое в рамках одной инфраструктуры. Так, например, команда zxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru sync перенесет ящик пользователя user@company.ru с первого почтового хранилища на второе, оставив соответствующую запись в LDAP. После этого следует удалить почтовый ящик со старого сервера с помощью команды вида zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru. А уже после завершения обновления почтового хранилища можно совершить перенос в обратном направлении, чтобы все вернулось к исходному состоянию. Отметим, что при желании и наличии полного перечня почтовых ящиков, располагавшихся в почтовом хранилище можно автоматизировать процесс переноса почтовых ящиков на новый сервер и обратно. Также с помощью команды doMoveMailbox можно избежать недоступности наиболее важных для предприятия почтовых ящиков.
После того как будут обновлены все почтовые хранилища, процесс обновления мультисерверной установки Zimbra можно считать завершенным. Заметного для пользователей простоя, если вы использовали команду doMoveMailbox для всех почтовых ящиков, практически удалось избежать.
По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com
