Так склалося, що системні адміністратори завжди з недовірою ставляться до всього нового. Буквально все, починаючи від нових серверних платформ до оновлень програмного забезпечення сприймається з настороженістю, доти, поки не з'явиться перший практичний досвід використання та позитивні відгуки від колег з інших підприємств. Воно і зрозуміло, адже коли в буквальному сенсі головою відповідаєш за працездатність підприємства та збереження важливої інформації, згодом перестаєш довіряти навіть самому собі, не кажучи вже про контрагентів, підлеглих чи звичайних користувачів.
Недовіра до оновлень програмного забезпечення обумовлена масою неприємних випадків, коли встановлення свіжих патчів призводило до падіння продуктивності, змін у інтерфейсі користувача, відмови інформаційної системи або, що особливо неприємно, втрати даних. Однак і повністю відмовитися від оновлень не можна, у такому разі інфраструктура вашого підприємства може зазнати атаки кіберзлочинців. Досить згадати випадок з вірусом 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 працює кілька поштових сховищ, а розмір поштового архіву досить великий, то кожне таке резервування може тривати дуже довго, а також створювати серйозне навантаження на локальну мережу та на сервери. Крім того, під час тривалого копіювання різко зростають ризики різних форс-мажорів. Також, якщо виконувати таке резервування без зупинки сервісу, виникає ризик того, що низка файлів може бути скопійована некоректно, що призведе до втрати деяких даних.
Саме тому в тому випадку, якщо вам необхідно резервувати великі обсяги інформації з поштових сховищ, краще використовувати інкрементне резервування, яке дозволяє уникнути повного копіювання всієї інформації, а резервувати лише ті файли, які з'явилися або змінилися після зняття попередньої повної резервної копії. Це значно прискорює процес зняття бекапів, а також дозволяє швидше розпочати встановлення оновлень. Домогтися інкрементного резервування 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 [захищено електронною поштою]
Команда виконується двічі для того, щоб вперше скопіювати всі дані без перенесення самого облікового запису, а вдруге, оскільки перенесення даних здійснюється інкрементно, скопіювати всі дані, що з'явилися після першого перенесення, а потім перенести і самі облікові записи. Звертаємо вашу увагу на те, що перенесення облікового запису супроводжується невеликим періодом недоступності поштової скриньки, і буде розумно попередити користувачів про це. Крім того, після закінчення виконання другої команди, на пошту адміністратору надходить відповідне повідомлення. Завдяки йому адміністратор може максимально швидко розпочати оновлення поштового сховища.
У випадку, якщо оновлення програмного забезпечення на поштовому сховищі здійснюється 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 [захищено електронною поштою]
Після того як перенесення облікових записів та їх даних з поштового сховища здійснено, дані на вихідному сервері перестають представляти хоч якусь значимість і можна починати оновлення поштового сервера без жодних побоювань за їх збереження.
Для тих, хто прагне мінімізувати час простою при перенесенні поштових скриньок, ідеально підійде принципово інший сценарій використання команди zxsuite powerstore doMailboxMove, Суть якого полягає в тому, що перенесення поштових скриньок здійснюється відразу на оновлені сервери, без необхідності використання проміжних серверів. Іншими словами, ми додаємо в інфраструктуру Zimbra нове поштове сховище, яке вже оновлено до останньої версії, а потім просто переносимо на нього за вже знайомим сценарієм облікові записи з неоновленого сервера і повторюємо процедуру доти, доки всі сервери в інфраструктурі не будуть оновлені.
Такий спосіб дозволяє здійснювати перенесення облікових записів один раз і скоротити час, протягом якого поштові скриньки залишатимуться недоступними. Крім того, для його здійснення буде потрібно лише один додатковий поштовий сервер. Однак до його використання з обережністю слід поставитися адміністраторам, які розгортають поштові сховища на різних за конфігурацією серверах. Справа в тому, що перенесення великої кількості облікових записів на більш слабкий сервер може негативно позначитися на доступності та чуйності сервісу, що може бути досить критичним для великих підприємств та SaaS-провайдерів.
Таким чином, завдяки Zextras Backup і Zextras PowerStore, системний адміністратор Zimbra отримує можливість оновлювати всі вузли інфраструктури Zimbra без жодного ризику для інформації, що зберігаються на них.
Джерело: habr.com