Zimbra Collaboration Suiteの安全なアップデート

たまたまですが、システム管理者は常に新しいものすべてに対して不信感を抱いています。 文字通り、新しいサーバー プラットフォームからソフトウェア アップデートに至るまで、すべてが慎重に認識されます。それは、最初の実際の使用経験や他の企業の同僚からの肯定的なフィードバックが現れるまでです。 これは当然のことです。企業のパフォーマンスと重要な情報の安全性に対して文字通り責任を負っていると、時間が経つにつれて、取引先、部下、一般ユーザーは言うまでもなく、自分自身さえも信頼できなくなるからです。

ソフトウェア更新に対する不信感は、新しいパッチをインストールするとパフォーマンスの低下、ユーザー インターフェイスの変更、情報システムの障害、さらには特に不快なデータの損失が発生するなど、多くの不快なケースが原因です。 ただし、アップデートを完全に拒否することはできません。この場合、企業のインフラストラクチャがサイバー犯罪者による攻撃を受ける可能性があります。 最新バージョンの Windows に更新されていない数百万台のコンピュータに保存されていたデータが暗号化されていたことが判明した、WannaCry ウイルスのセンセーショナルな事件を思い出すだけで十分です。 このインシデントは、8.8.15 人を超えるシステム管理者の仕事を奪っただけでなく、セキュリティとインストールの速度を組み合わせた、企業内のソフトウェア製品の更新のための新しいポリシーを開発する必要性を明確に示しました。 Zimbra XNUMX の LTS リリースを見越して、すべての重要なデータの安全性を確保するために Zimbra Collabration Suite オープンソース エディションを更新する方法を見てみましょう。

Zimbra Collaboration Suite の主な特徴の XNUMX つは、そのリンクのほぼすべてを複製できることです。 特に、メイン LDAP マスター サーバーに加えて、重複する LDAP レプリカを追加でき、必要に応じてメイン LDAP サーバーの機能をそこに転送できます。 プロキシ サーバーと MTA を使用してサーバーを複製することもできます。 この複製により、必要に応じて、アップデート中にインフラストラクチャから個々のインフラストラクチャ リンクを削除できます。これにより、長時間にわたるダウンタイムだけでなく、アップデートが失敗した場合のデータ損失からも確実に保護されます。

インフラストラクチャの他の部分とは異なり、Zimbra Collaboration Suite ではメールストレージの複製はサポートされていません。 インフラストラクチャ内に複数のメール ストアがある場合でも、各メールボックスのデータは XNUMX つのメール サーバー上に存在する可能性があります。 そのため、更新中のデータの安全性に関する主なルールの XNUMX つは、メール ストレージ内の情報をタイムリーにバックアップすることです。 バックアップが新しいほど、緊急時により多くのデータが保存されます。 ただし、ここにはニュアンスがあり、Zimbra Collaboration Suite の無料版にはバックアップ メカニズムが組み込まれておらず、バックアップを作成するには組み込みの GNU/Linux ツールを使用する必要があるということです。 ただし、Zimbra インフラストラクチャが複数のメール ストレージを実行しており、メール アーカイブのサイズが非常に大きい場合、そのような各バックアップは非常に長時間続く可能性があり、ローカル ネットワークやサーバー自体に重大な負荷がかかることもあります。 さらに、長期にわたるコピー中は、さまざまな不可抗力事象のリスクが急激に増加します。 また、サービスを停止せずにバックアップを実行すると、多数のファイルが誤ってコピーされ、一部のデータが失われる危険性があります。

そのため、メール ストレージから大量の情報をバックアップする必要がある場合は、増分バックアップを使用することをお勧めします。これにより、すべての情報を完全にコピーすることを避け、前回のバックアップ以降に出現または変更されたファイルのみをバックアップできます。完全なバックアップが取られました。 これにより、バックアップの削除プロセスが大幅に高速化され、更新のインストールをすぐに開始できるようになります。 Zextras Suite の一部である Zextras Backup モジュラー拡張機能を使用して、Zimbra オープンソース エディションで増分バックアップを実行できます。

もう XNUMX つの強力なツールである Zextras PowerStore を使用すると、システム管理者はメール ストレージ上のデータを重複排除できます。 これは、メール サーバー上のすべての同一の添付ファイルと重複した電子メールが XNUMX つの元のファイルに置き換えられ、すべての重複が透過的なシンボリック リンクに変換されることを意味します。 このおかげで、ハード ディスク領域を大幅に節約できるだけでなく、バ​​ックアップ コピーのサイズも大幅に削減できます。これにより、完全バックアップの時間が短縮され、それに応じてより頻繁にバックアップを実行できるようになります。

しかし、Zextras PowerStore が安全な更新のために提供できる主な機能は、マルチサーバー Zimbra インフラストラクチャ内のメール サーバー間でのメールボックスの転送です。 この機能のおかげで、システム管理者は、MTA サーバーや LDAP サーバーで行ったのとまったく同じことをメール ストレージで安全に更新することができます。 たとえば、Zimbra インフラストラクチャに XNUMX つのメール ストアがある場合、そのうちの XNUMX つのメール ストアから他の XNUMX つのメール ストアにメールボックスを分散することができ、最初のメール ストアが空の場合は、データの安全性を心配することなく更新できます。 。 システム管理者は、インフラストラクチャ内に予備のメール ストレージがある場合、それを、更新されたメール ストレージから転送されたメールボックスの一時ストレージとして使用できます。

コンソール コマンドを使用すると、このような転送を実行できます。 DoMoveメールボックス。 これを使用してメール ストレージからすべてのアカウントを転送するには、まずアカウントの完全なリストを取得する必要があります。 これを実現するには、メールサーバー上で次のコマンドを実行します。 zmprov sa zimbraMailHost=mailbox.example.com > accounts.txt。 実行するとファイルが届きます アカウント.txt 当社のメールストレージ上のすべてのメールボックスのリストを含みます。 この後、すぐにこれを使用してアカウントを別のメール ストレージに転送できます。 たとえば、次のようになります。

zxsuite powerstore doMailboxMove replace_mailbox.example.com input_file accounts.txt ステージ データ
zxsuite powerstore doMailboxMove replace_mailbox.example.com input_file accounts.txt ステージ データ、アカウント通知 [メール保護]

このコマンドは XNUMX 回実行され、XNUMX 回目はアカウント自体を移行せずにすべてのデータをコピーし、XNUMX 回目はデータ移行が段階的に実行されるため、XNUMX 回目の移行後に表示されたすべてのデータをコピーしてから移行します。アカウント自体。 アカウントの移管には短期間メールボックスが利用できなくなることがあり、これについてユーザーに警告することが賢明であることに注意してください。 さらに、XNUMX 番目のコマンドが完了すると、管理者は電子メールで対応する通知を受け取ります。 そのおかげで、管理者はできるだけ早くメール ストレージの更新を開始できます。

メール ストレージのソフトウェア更新が SaaS プロバイダーによって実行される場合、アカウントごとではなく、そこにあるドメインごとにデータを転送する方がはるかに合理的です。 これらの目的のためには、入力したコマンドを少し変更するだけで十分です。

zxsuite powerstore doMailboxMove replace_mailbox.saas.com ドメイン client1.ru、client2.ru、client3.ru ステージ データ
zxsuite powerstore doMailboxMove secureserver.saas.com ドメイン client1.ru、client2.ru、client3.ru ステージ データ、アカウント通知 [メール保護]

メール ストレージからのアカウントとそのデータの転送が完了すると、ソース サーバー上のデータは重要でなくなり、安全性を心配することなくメール サーバーの更新を開始できます。

メールボックスの移行時のダウンタイムを最小限に抑えたい場合は、コマンドを使用する根本的に異なるシナリオが理想的です。 zxsuite powerstore doMailboxMoveその本質は、中間サーバーを使用せずに、メールボックスが更新されたサーバーに直接転送されることです。 言い換えれば、すでに最新バージョンに更新されている Zimbra インフラストラクチャに新しいメール ストレージを追加し、すでによく知られているシナリオに従って、更新されていないサーバーからそのサーバーにアカウントを転送するだけで、すべてのサーバーが保存されるまでこの手順を繰り返します。インフラストラクチャが更新されます。

この方法を使用すると、アカウントを一度転送できるため、メールボックスにアクセスできなくなる時間を短縮できます。 さらに、その実装には追加のメール サーバーが XNUMX 台だけ必要になります。 ただし、異なる構成のサーバーにメール ストレージを展開する管理者は、その使用に注意する必要があります。 実際、多数のアカウントを弱いサーバーに転送すると、サービスの可用性と応答性に悪影響を及ぼす可能性があり、これは大企業や SaaS プロバイダーにとって非常に重要な問題となる可能性があります。

したがって、Zextras Backup と Zextras PowerStore のおかげで、Zimbra システム管理者は、Zimbra インフラストラクチャ ノードに保存されている情報を危険にさらすことなく、すべての Zimbra インフラストラクチャ ノードを更新できます。

出所： habr.com