من بين مزايا الإصدار المفتوح المصدر من Zimbra Collaboration Suite ، مثل الموثوقية والأداء العالي بالإضافة إلى الحل المجاني ، ينبغي أن نذكر أيضًا المظهر المتكرر إلى حد ما للإصدارات الجديدة من Zimbra والإضافة المنتظمة للميزات التي يطلبها المجتمع فيها. لذلك ، على سبيل المثال ، فقط خلال العام الماضي ، تمت إضافة ميزات مثل القدرة على استرداد كلمة المرور بشكل مستقل من قبل المستخدم ، والقدرة على تغيير التقويم الافتراضي ، ودعم دفاتر العناوين التسلسلية ، وفرص العمل الأخرى المفيدة. ومع ذلك ، تاريخيا ، لا يحب مديرو تكنولوجيا المعلومات في روسيا التحديثات بشكل خاص.

القديم مثل القاعدة العالمية التي يجب أن لا تلمس ما يعمل بشكل جيد قد استقر بحزم في رؤساء خبراء تكنولوجيا المعلومات الروس مرة أخرى في أواخر 90s. في الواقع ، كان كسر ثبات حلول التحديث ، وكذلك التغييرات المفاجئة للواجهات ، والتي تم إدخالها في ذهول المستخدمين ، أمرًا شائعًا في ذلك الوقت. ومع ذلك ، تفرض الأوقات الجديدة تحديات جديدة على مديري تكنولوجيا المعلومات ، والآن أصبح نهج "لا تلمس ما ينجح" ببساطة غير قابل للتطبيق. تنتشر المعلومات حول الكشف عن الثغرات في جميع أنحاء العالم بسرعة كبيرة ، وتقوم جيوش المهاجمين السيبرانيين بكتابة عمليات استغلال لهذه الثغرات الأمنية بمعدلات تجعل استخدام إصدارات قديمة من البرمجيات في المؤسسة مخاطر هائلة على أمن المعلومات. وخاصة هذه المخاطر كبيرة عندما يتعلق الأمر بمنصات التعاون.
هناك حجة نموذجية أخرى ضد التحديث المنتظم لنظم المعلومات في المؤسسات وهي الحاجة إلى تعليق عملهم أثناء تثبيت التحديثات. ومثل هذه الحجة هي في الواقع حاسمة بالنسبة للمؤسسات الكبيرة وموفري SaaS الذين يعد توفر الخدمة القريب بنسبة 100٪ أمرًا مهمًا لهم. هذا هو السبب في أن كل مطور ، عند تصميم وتطوير الحل الخاص به ، يحاول تقليل أو تقليص وقت تعطل أحد الحلول البرمجية إلى الصفر تمامًا عند تحديثه. مطورو Zimbra ليست استثناء.
من الممكن حاليًا ترقية مجموعة Zimbra Collaboration Suite في المؤسسة دون توقف نظام المعلومات نفسه ، ولكن في الواقع ستتحول هذه العملية إلى انتقال سلس من خادم Zimbra إلى خادم آخر ، حيث تم بالفعل تثبيت إصدار أحدث من ZCS باستخدام Zextras Suite. لقد سبق أن وصفنا هذه العملية في مقال سابق. يمكن لأولئك غير المستعدين لتخصيص قدرات خادم إضافية للهجرة استخدام عدد من النصائح لتقليل وقت تعطل زيمبرا أثناء عملية الترقية.
عملية التحديث نفسها هي تكرار لعملية تثبيت Zimbra باستخدام إصدار أحدث من التوزيع. بمعنى آخر ، يكفي تنزيل أحدث إصدار من ZCS من
Zimbra.com ، وعندما يبدأ التثبيت ،
سيكتشف البرنامج تلقائيًا برنامج Zimbra المثبت على الخادم ، ثم
يعرضه لتحديثه. في معظم الحالات ، يتم التحديث تلقائيًا ، ولكن إذا كنت تقوم بالترقية من Zimbra الإصدار 8.6 أو الأحدث ، فقد تحتاج إلى إعادة تثبيت الوحدات النمطية memcached و zimbra-proxy ، والتي أصبحت إلزامية للتثبيت بدءًا من الإصدار Zimbra 8.7.
لا توجد نصائح لتحسين الوقت لترقية Zimbra لأولئك الذين يستخدمون حل خادم واحد. عادةً ما يتم استخدام خيارات التثبيت هذه في المؤسسات الصغيرة التي يمكنها تحمل مقاطعة نظام التعاون ، خاصة إذا كنت تخطط لترقية Zimbra في المساء أو في الليل.
بالنسبة للتركيب المتعدد على Zimbra ، هناك العديد من الحيل لتقليل وقت توقف نظام المعلومات. بادئ ذي بدء ، يتعلق هذا بتثبيت التحديثات. لذا ، أولاً وقبل كل شيء ، يجب ترقية الخادم باستخدام LDAP. في حالة وجود عدد من خوادم LDAP ، بالإضافة إلى LDAP الرئيسي ، توجد خوادم بها نسخة متماثلة من LDAP ، ثم يمكنك "إيقاف" أحد النسخ المتماثلة لـ LDAP إلى LDAP Master ، في نفس الوقت ، باستخدام جدار حماية لحظر الاتصالات بـ LDAP الرئيسية. إذا كانت البنية الأساسية الخاصة بك تحتوي على خادم LDAP واحد فقط ، فيمكنك تجنب وقت التوقف الطويل أثناء الترقية عن طريق إنشاء خادم LDAP Replica افتراضي. بعد تحديث LDAP Master ، سيكون من الممكن إعادة تشغيله ، ثم تحديث خوادم 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 و Proxy ، يمكنك البدء في ترقية متاجر البريد الخاصة بك. مثل جميع الخوادم السابقة ، يجب تحديث الخوادم التي تحتوي على صناديق بريد واحدة في وقت واحد. ستساعد وظيفة doMoveMailbox ، التي يتم تخزينها في فصل الشتاء Zextras Powerstore وتسمح بنقل علب بريد المستخدم من صندوق بريد إلى آخر داخل نفس البنية التحتية ، على تجنب عدم إمكانية الوصول إلى صناديق البريد. لذلك ، على سبيل المثال ، فإن الأمر
zxsuite powerstore doMoveMailbox -a user@company.ru -f mailstore1.company.ru -t mailstore2.company.ru ، ستنقل مزامنة مربع المستخدم
user@company.ru من متجر البريد الأول إلى الثاني ، وترك الإدخال المقابل في LDAP . بعد ذلك ، يجب عليك حذف صندوق البريد من الخادم القديم باستخدام أمر النموذج
zmpurgeoldmbox -a user@company.ru -s mailstore1.company.ru . وبعد الانتهاء من ترقية وحدة تخزين البريد ، يمكنك إجراء النقل في الاتجاه المعاكس ، بحيث يعود كل شيء إلى حالته الأصلية. لاحظ أنه إذا كنت ترغب في الحصول على قائمة كاملة بصناديق البريد الموجودة في مخزن البريد لديك ، فيمكنك أتمتة عملية نقل صناديق البريد إلى خادم جديد والعكس صحيح. يمكنك أيضًا استخدام
الأمر doMoveMailbox لمنع عدم توفر صناديق البريد الأكثر أهمية
لمؤسستك .
بعد تحديث جميع مخازن البريد ، يمكن اعتبار عملية الترقية للتثبيت المتعدد للخادم Zimbra مكتملة. تم
إيقاف عمليا تعطل ملحوظ للمستخدمين ، إذا استخدمت الأمر
doMoveMailbox لجميع صناديق البريد.
بالنسبة لجميع الأسئلة المتعلقة بـ Zextras Suite ، يمكنك الاتصال بممثل شركة "Zextras" Katerina Triandafilidi عبر البريد الإلكتروني katerina@zextras.com