Так уж сложилось, что системные администраторы всегда с недоверием относятся ко всему новому. Буквально все, начиная от новых серверных платформ до обновлений программного обеспечения воспринимается с настороженностью, ровно до тех пор, пока не появится первый практический опыт использования и позитивные отзывы от коллег из других предприятий. Оно и понятно, ведь когда в буквальном смысле головой отвечаешь за работоспособность предприятия и сохранность важной информации, со временем перестаешь доверять даже самому себе, не говоря уже о контрагентах, подчиненных или обычных пользователях.
Недоверие к обновлениям программного обеспечения обусловлено массой неприятных случаев, когда установка свежих патчей приводила к падению производительности, изменениям в пользовательском интерфейсе, отказу информационной системы или, что особенно неприятно, потере данных. Однако и полностью отказаться от обновлений нельзя, в таком случае инфраструктура вашего предприятия может подвергнуться атаке киберпреступников. Достаточно вспомнить нашумевший случай с вирусом WannaCry, когда данные, хранившиеся на миллионах не обновленных до последней версии Windows компьютерах, оказались зашифрованными. Этот инцидент не только стоил рабочего места не одной сотне системных администраторов, но и наглядно показал необходимость выработки новой политики обновления программных продуктов на предприятии, которая бы позволяла сочетать безопасность и скорость их установки. Давайте же в преддверие выхода LTS-релиза Zimbra 8.8.15 посмотрим на то, как можно обновить Zimbra Collabration Suite Open-Source Edition, чтобы гарантированно обеспечить сохранность всех критически важных данных.
Одной из главных особенностей Zimbra Collaboration Suite является то, что практически все ее звенья можно дублировать. В частности, можно в дополнение к основному серверу LDAP-Master добавить дублирующие LDAP-replica, на которые, в случае необходимости, можно перебросить функции основного LDAP-сервера. Также можно дублировать Proxy-серверы и серверы с MTA. Такое дублирование позволяет при необходимости выводить из инфраструктуры отдельные звенья инфраструктуры на время обновления и, благодаря этому, надежно защитить себя не только от длительного простоя, но и от потери данных в случае неудачного обновления.
В отличие от остальных звеньев инфраструктуры, дублирование почтовых хранилищ в Zimbra Collaboration Suite не поддерживается. Даже в том случае, если в вашей инфраструктуре имеются несколько почтовых хранилищ, данные каждого почтового ящика могут находиться на каком-либо одном почтовом сервере. Именно поэтому одно из главных правил сохранности данных при обновлении — своевременное резервирование информации на почтовых хранилищах. Чем свежее ваш бэкап, тем больше данных сохранится при возникновении нештатной ситуации. Однако здесь есть нюанс, который заключается в том, что в бесплатной редакции Zimbra Collaboration Suite нет встроенного механизма резервного копирования и для создания резервных копий придется воспользоваться встроенными средствами GNU/Linux. Однако если в вашей инфраструктуре Zimbra работает несколько почтовых хранилищ, а размер почтового архива достаточно велик, то каждое такое резервирование может длиться очень долго, а также создавать серьезную нагрузку на локальную сеть и на сами серверы. Кроме того, во время длительного копирования резко возрастают риски возникновения различных форс-мажоров. Также, если выполнять такое резервирование без остановки сервиса, возникает риск того, что ряд файлов может быть скопирован некорректно, что приведет к потере некоторых данных.
Именно поэтому в том случае, если вам необходимо резервировать большие объемы информации c почтовых хранилищ, лучше использовать инкрементное резервирование, которое позволяет избежать полного копирования всей информации, а резервировать лишь те файлы, которые появились или подверглись изменению после снятия предыдущей полной резервной копии. Это значительно ускоряет процесс снятия бэкапов, а также позволяет быстрее приступить к установке обновлений. Добиться инкрементного резервирования в Zimbra Open-Source Edition можно при помощи модульного расширения Zextras Backup, входящего в состав Zextras Suite.
Еще один мощный инструмент Zextras PowerStore позволяет системному администратору дедуплицировать данные на почтовом хранилище. Это означает, что все одинаковые вложения и повторяющиеся электронные письма на почтовом сервере будут заменены на один исходный файл, а все повторы превратятся в прозрачные символьные ссылки. Благодаря этому можно добиться не только значительной экономии места на жестком диске, но и значительного уменьшения размера резервной копии, что позволяет добиться снижения времени полного резервного копирования и, соответственно, проводить его гораздо чаще.
Но главной возможностью, которую способен предоставить Zextras PowerStore для безопасного обновления, является перенос почтовых ящиков между почтовыми серверами в мультисерверных инфраструктурах Zimbra. Благодаря этой возможности системный администратор получает возможность проделать с почтовыми хранилищами ровно то же самое, что мы делали с MTA- и LDAP-серверами для их безопасного обновления. Например, если в инфраструктуре Zimbra имеются четыре почтовых хранилища, можно попробовать распределить почтовые ящики с одного из них по остальным трем, и когда первое почтовое хранилище окажется пустым, можно безо всяких опасений за сохранность данных его обновить. Если же у системного администратора в инфраструктуре имеется запасное почтовое хранилище, он может воспользоваться им, как временным вместилищем для почтовых ящиков, перенесенных с обновляемых почтовых хранилищ.
Выполнять подобный перенос позволяет консольная команда DoMoveMailbox. Для того, чтобы ей воспользоваться с целью переноса всех аккаунтов с почтового хранилища, необходимо сперва получить их полный список. Для того, чтобы этого добиться, на почтовом сервере исполним команду zmprov sa zimbraMailHost=mailbox.example.com > accounts.txt. После ее выполнения мы получим файл accounts.txt со списком всех почтовых ящиков на нашем почтовом хранилище. После этого можно будет сразу же воспользоваться им для переноса аккаунтов на другое почтовое хранилище. Выглядеть это будет, например, вот так:
zxsuite powerstore doMailboxMove reserve_mailbox.example.com input_file accounts.txt stages data
zxsuite powerstore doMailboxMove reserve_mailbox.example.com input_file accounts.txt stages data,account notifications [email protected]
Команда выполняется два раза для того, чтобы в первый раз скопировать все данные без переноса самого аккаунта, а во второй раз, поскольку перенос данных осуществляется инкрементно, скопировать все данные, появившиеся после первого переноса, а затем перенести и сами аккаунты. Обращаем ваше внимание на то, что перенос аккаунта сопровождается небольшим периодом недоступности почтового ящика, и будет разумно предупредить пользователей об этом. Кроме того, после окончания исполнения второй команды, на почту администратору приходит соответствующее уведомление. Благодаря ему администратор может максимально быстро приступить к обновлению почтового хранилища.
В случае, если обновление программного обеспечения на почтовом хранилище осуществляется SaaS-провайдером, гораздо разумнее будет переносить данные не по аккаунтам, а по доменам, которые располагаются на нем. Для этих целей достаточно немного видоизменить вводимую команду:
zxsuite powerstore doMailboxMove reserve_mailbox.saas.com domains client1.ru, client2.ru, client3.ru stages data
zxsuite powerstore doMailboxMove secureserver.saas.com domains client1.ru, client2.ru, client3.ru stages data,account notifications [email protected]
После того как перенос аккаунтов и их данных с почтового хранилища осуществлен, данные на исходном сервере перестают представлять хоть какую-то значимость и можно начинать обновление почтового сервера без каких-либо опасений за их сохранность.
Для тех же, кто стремится минимизировать время простоя при переносе почтовых ящиков, идеально подойдет принципиально иной сценарий использования команды zxsuite powerstore doMailboxMove, суть которого заключается в том, что перенос почтовых ящиков осуществляется сразу на обновленные серверы, без необходимости использования промежуточных серверов. Иными словами, мы добавляем в инфраструктуру Zimbra новое почтовое хранилище, которое уже обновлено до последней версии, а затем просто переносим на него по уже знакомому сценарию аккаунты с необновленного сервера и повторяем процедуру до тех пор, пока все серверы в инфраструктуре не будут обновлены.
Такой способ позволяет осуществлять перенос аккаунтов единожды и за счет этого сократить время, на протяжении которого почтовые ящики будут оставаться недоступными. Кроме того, для его осуществления потребуется всего один дополнительный почтовый сервер. Однако к его использованию с осторожностью следует отнестись тем администраторам, которые разворачивают почтовые хранилища на разных по конфигурации серверах. Дело в том, что перенос большого числа аккаунтов на более слабый сервер может негативно сказаться на доступности и отзывчивости сервиса, что может быть довольно критичным для крупных предприятий и SaaS-провайдеров.
Таким образом, благодаря Zextras Backup и Zextras PowerStore, системный администратор Zimbra получает возможность обновлять все узлы инфраструктуры Zimbra безо всякого риска для хранящихся на них информации.
Источник: habr.com