90年代後半、ロシアのIT専門家の頭の中には、これまでのようにうまく機能するものに触れてはならないという古いルールがしっかりと定着しています。 確かに、更新ソリューションの安定性を損なうだけでなく、ユーザーのst迷に巻き込まれたインターフェイスの突然の変更は、当時一般的でした。 ただし、新しい時代はITマネージャーに新たな課題をもたらし、現在では「動作するものに手を触れない」というアプローチはまったく適用できません。 脆弱性検出に関する情報は世界中に急速に広まっており、サイバー攻撃者の軍隊は、企業で古いバージョンのソフトウェアを使用することで情報セキュリティに多大なリスクをもたらすほどの速さでこれらの脆弱性に対するエクスプロイトを作成しています。 特に、コラボレーションプラットフォームに関しては、これらのリスクは非常に大きくなります。
企業の情報システムの定期的な更新に対するもう1つの典型的な議論は、更新のインストール中に作業を中断する必要があるということです。 そして、そのような議論は、100％近いサービス可用性が重要である大企業やSaaSプロバイダーにとって確かに決定的です。 そのため、すべての開発者は、ソリューションを設計および開発するときに、ソフトウェアソリューションの更新時にダウンタイムを最小限に抑えるか、完全にゼロにしようとします。 Zimbraの開発者も例外ではありません。
現在、情報システム自体のダウンタイムなしで企業内のZimbra Collaboration Suiteをアップグレードすることは可能ですが、実際には、このプロセスは、ZimbraサーバーからZextras Suiteを使用してより新しいバージョンのZCSが既にインストールされている別のZimbraサーバーへのシームレスな移行になります。 このプロセスについては、以前の記事ですでに説明しました。 移行のために追加のサーバー容量を割り当てる準備ができていない人は、アップグレードプロセス中のZimbraのダウンタイムを削減するためのいくつかのヒントを使用できます。
更新プロセス自体は、新しいバージョンのディストリビューションを使用したZimbraインストールプロセスの繰り返しです。 言い換えると、 Zimbra.comから最新バージョンのZCSをダウンロードするだけで十分です。インストールが開始されると、プログラムはサーバーにインストールされているZimbraを自動的に検出し、更新を提案します。 ほとんどの場合、更新は自動的に行われますが、Zimbraバージョン8.6以降からアップグレードする場合、memcachedおよびzimbra-proxyモジュールを再インストールする必要があります。これらは、バージョンZimbra 8.7以降のインストールに必須になっています。
シングルサーバーソリューションを使用する人のためにZimbraをアップグレードする時間を最適化するためのヒントはありません。 通常、これらのインストールオプションは、特に夕方または夜間にZimbraをアップグレードする予定の場合、コラボレーションシステムを中断する余裕がある小規模企業で使用されます。
Zimbraマルチサーバーのインストールに関しては、情報システムのダウンタイムを削減するためのいくつかのトリックがあります。 まず第一に、これはアップデートのインストールに関するものです。 そのため、まず、LDAPを使用してサーバーをアップグレードする必要があります。 会社内にメインLDAPに加えて、LDAPレプリカを備えたサーバーがある場合、アップグレード中の長いダウンタイムを回避するために、LDAPレプリカの1つをLDAPマスターに「アップグレード」すると同時に、ファイアウォールを使用して実際のLDAPへの接続を禁止できますマスター インフラストラクチャにLDAPサーバーが1つしかない場合、仮想LDAPレプリカサーバーを作成することにより、アップグレード中の長いダウンタイムを回避できます。 LDAPマスターが更新された後、それを操作に戻し、残りのLDAPサーバーを更新できます。
Zimbra MTAおよびZimbra Proxyを備えた次のサーバー。 Zimbraの古いバージョンからアップグレードする場合、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、およびプロキシを持つすべてのノードが更新された後にのみ、メールストアのアップグレードを開始できます。 以前のすべてのサーバーと同様に、メールボックスを持つサーバーは一度に1つずつ更新する必要があります。 Zextras Powerstoreの冬季に縫い付けられ、同じインフラストラクチャ内のあるメールボックスから別のメールボックスにユーザーメールボックスを転送できるようにするdoMoveMailbox関数は、メールボックスへのアクセス不能を回避するのに役立ちます。 たとえば、コマンドzxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru syncは 、ユーザーボックスuser@company.ruを最初のメールストアから2番目に転送し、LDAPに対応するエントリを残します。 。 その後、 zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ruという形式のコマンドを使用して、古いサーバーからメールボックスを削除する必要があります。 また、メールストアのアップグレードが完了したら、反対方向に転送して、すべてが元の状態に戻るようにすることができます。 メールストアにメールボックスの完全なリストが必要な場合は、メールボックスを新しいサーバーに転送するプロセスを自動化できます。逆も同様です。 doMoveMailboxコマンドを使用して、企業にとって最も重要なメールボックスが使用できなくなるのを防ぐこともできます。
すべてのメールストレージが更新された後、Zimbraマルチサーバーインストールのアップグレードプロセスが完了したと見なすことができます。 すべてのメールボックスにdoMoveMailboxコマンドを使用した場合、ユーザーの顕著なダウンタイムは実質的に回避されました。
Zextrasスイートに関するすべての質問については、電子メールkaterina@zextras.comでZextras Katerina Triandafilidiの代表者に連絡することができます