محتوى هذه الصفحة مترجم آليًا. لا تضمن Zoom دقة المحتوى المترجم آليًا.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

اعتبارات نشر الأجهزة

اعثر على تعليمات لنشر وحدة Zoom Node ZPLS على الآلات الافتراضية باستخدام المشرفات الافتراضية المدعومة

توضح هذه الصفحة نشر وحدة Zoom Node ZPLS على جهاز افتراضي باستخدام برامج المراقبة الافتراضية المدعومة. وهي توفر خيارات تكوين مفصلة ومصممة لاستيعاب قدرات الأجهزة المختلفة، بما يضمن الأداء الأمثل لمختلف الاحتياجات التشغيلية.

برامج المراقبة الافتراضية المدعومة

يجب على العملاء تثبيت برنامج Zoom Node على جهاز افتراضي يعمل على برنامج مراقبة افتراضية مدعوم

باعتبارها حمل عمل Zoom Node، يجب تثبيت وحدة ZPLS على جهاز افتراضي يعمل على منصة Zoom Node، على برنامج مراقبة افتراضية مدعوم‌. يمكن العثور على مزيد من المعلومات حول Zoom Node كمنتج في الملحق.

يمكن للعملاء اختر أحد خياري التكوين، اعتمادًا على قدرات الأجهزة

تدعم وحدة ZPLS تكوينين، اعتمادًا على قدرات الأجهزة الخاصة بالجهاز الافتراضي. هذه القدرات مدرجة أدناه:

خيار التكوين 1
خيار التكوين 2

مواصفات الأجهزة

8 وحدات CPU

16 جيجابايت RAM

80 جيجابايت HDD

16 وحدة CPU

16 جيجابايت RAM

80 جيجابايت HDD

إجمالي عمليات التسجيل

2000

5000

الحد الأقصى للمكالمات المتزامنة

240

480

المكالمات في الثانية

2

4

عمليات التسجيل في الثانية

60

400

إذا تجاوز عدد نقاط النهاية ضمن موقع مُمكَّن للبقاء التشغيلي قدرات النشر الخاصة بالموقع، فستقوم وحدة ZPLS بمعالجة التسجيلات على أساس أسبقية الوصول. ويُنصح العملاء بـ إضافة وحدات إضافية، أو استخدام إعداد نهج Zoom Phone وضع البقاء المحلي لتحديد أولوية المستخدمين الذين يدعمون التحويل إلى البقاء التشغيلي عند الفشل.

توسيع الوحدة والمرونة

تدعم وحدات ZPLS التجميع لتوفير توسيع إضافي و/أو مرونة

يمكن للعملاء تجميع وحدات ZPLS معًا بما يصل إلى 20 وحدة لكل موقع (أو 100 جهاز Node إجمالًا لكل الحساب) لتوفير تكرار إضافي أو توسيع.

هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.

يؤدي التوسيع إلى زيادة قدرات الجهاز المدعومة في الموقع

إن زيادة عدد وحدات ZPLS تعزز قدرات كل موقع بشكل خطي مع كل وحدة إضافية. على سبيل المثال، إذا كانت وحدة واحدة تدعم إجمالي 5,000 عملية تسجيل، فإن نشر خمس وحدات سيرفع الدعم إلى 25,000 عملية تسجيل.

يضيف التكرار وحدات إضافية لتحقيق المرونة، لكنه لا يوسع قدرات الجهاز في الموقع

عندما تُستخدم وحدة ZPLS لأغراض التكرار، فإن الوحدات الاحتياطية لا تسهم في العدد الإجمالي للامتدادات المدعومة. بدلًا من ذلك، تكون الوحدات في وضع «استعداد ساخن»، ولن تعمل إلا إذا فشلت الوحدات الأساسية. على سبيل المثال، تدعم وحدة أساسية واحدة ووحدة احتياطية واحدة إجمالي 5,000 عملية تسجيل، لذا إذا تعطلت وحدة أساسية، فلن تكون الوحدة الاحتياطية محملة بعدد أجهزة يتجاوز حدها المدعوم.

مثال على نشر ZPLS مع التوسيع والتكرار

للتسهيل، يوضح المثال التالي النشر مع توسيع إضافي وتكرار.

اعتبارات تصميم الموقع

تقوم المواقع بتجميع مستخدمي Zoom Phone معًا حسب الموقع من أجل إعدادات وسياسات الاتصال الهاتفي المشتركة

إن موقع هو مصطلح محدد يُستخدم داخل Zoom Phone ويجمع المستخدمين ذوي الخصائص المشتركة — مثل رمز وصول مشترك، أو عنوان، أو منطقة SIP، أو قسم، أو سياسات — في مجموعة واحدة قابلة للإدارة داخل بوابة Zoom الإلكترونية. بالنسبة لبعض العملاء، قد يمثل موقع واحد جميع المستخدمين داخل أعمالهم، ويمكن أن يمتد عبر عدة مبانٍ داخل حرم أو الموقع؛ وبالنسبة لآخرين، قد تكون عدة مواقع مطلوبة اعتمادًا على احتياجات أعمالك. لمزيد من المعلومات حول المواقع أو إدارة الموقع، ارجع إلى مركز دعم Zoom.

يدعم Zoom Phone تصميمات الموقع الواحد والمواقع المتعددة

هناك تصميمان أساسيان لتكوين مواقع Zoom Phone داخل الحساب:

  1. موقع واحد: يمثل جميع المستخدمين داخل الحساب، وقد يمتد عبر عدة مبانٍ أو مواقع، ضمن موقع Zoom Phone واحد.

  2. متعدد المواقع: يمثل شرائح من المستخدمين حسب الموقع أو المبنى أو القسم أو الوظيفة بشكل منفصل، بحيث يكون لكل منها موقعه الخاص.

يمكن لمسؤولي الحساب لدى عملاء Zoom الحاليين التحقق من تصميم الموقع الحالي لديهم من خلال صفحة معلومات الشركة ، المتاحة في قائمة إدارة نظام الهاتف على البوابة الإلكترونية.

يمكن ربط كل وحدة ZPLS بموقع واحد فقط في كل مرة

كما ذُكر سابقًا، فإن وحدة ZPLS هي المسجل ذو الأولوية الثالثة للأجهزة المدعومة، بعد منطقتي SIP الأساسية والثانوية. ولأن الأجهزة تتلقى قوائم SRV الخاصة بها أثناء عملية الإقلاع، وهذه القوائم مرتبطة بإعداد الموقع الخاص بها، يمكن ربط كل وحدة ZPLS بموقع واحد فقط في كل مرة.

يمكن لكل موقع دعم ما يصل إلى 20 وحدة ZPLS في وقت واحد

على الرغم من أن كل وحدة ZPLS يمكن ربطها بموقع واحد فقط في كل مرة، فإن الموقع يمكنه دعم ما يصل إلى 20 وحدة ZPLS في مجموعة واحدة، مما يوسع قدرات البقاء التشغيلي لكل موقع.

هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.

تدعم وحدات ZPLS المكالمات بين المواقع إذا كانت الوحدات متصلة بشبكة مشتركة

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

هذه الميزة متاحة حاليًا في النسخة التجريبية وتتطلب تذكرة دعم فني ليتم تمكينها.

قبل نشر ZPLS، يجب أن تفهم الحسابات أي تكوين موقع هو الأنسب لاحتياجاتها

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

يكون تصميم الموقع الواحد أسهل في الإدارة ويوفر البقاء التشغيلي باستخدام وحدة ZPLS واحدة، لكنه يوفر مرونة أقل لإعدادات المستخدم والسياسات

يساعد تصميم الموقع الواحد على تبسيط إدارة إعدادات وسياسات Zoom Phone من خلال دمج جميع المستخدمين داخل الحساب تحت مجموعة واحدة موحدة. وتوفر مجموعة المستخدمين الواحدة هذه للأعمال إدارة مباشرة وتقليلًا في التعقيد، مما يبسّط عملية الإدارة. بالإضافة إلى ذلك، يمكن أن يوفر تصميم الموقع الواحد بقاءً هاتفيًا محليًا باستخدام وحدة ZPLS واحدة، طالما أن مستخدمي الموقع لا يتجاوزون قدرات الوحدة الواحدة.

ومع ذلك، فإن بساطة تصميم الموقع الواحد تتضمن بطبيعتها بعض القيود. وعلى وجه التحديد، توفر تصميمات الموقع الواحد مرونة أقل بسبب طبيعتها «مقاس واحد يناسب الجميع»، وهو ما قد لا يناسب جميع سيناريوهات النشر عبر أقسام متعددة ذات احتياجات متفاوتة. وعلاوة على ذلك، قد تكون عمليات النشر أحادية الموقع عرضة للخطر في بعض سيناريوهات البقاء إذا فشلت الشبكة المحلية.

يوفر تصميم المواقع المتعددة مرونة أكبر لإعدادات المستخدم والسياسات، لكنه يتطلب وحدة ZPLS واحدة لكل موقع مُمكَّن للبقاء التشغيلي ويكون أكثر تعقيدًا في الإدارة

يوفر تصميم المواقع المتعددة للأعمال مرونة إضافية في إعدادات المستخدم والسياسات من خلال فصل المستخدمين إلى مجموعات متنوعة مع ضوابط إعدادات دقيقة. ويمكّن هذا التصميم المؤسسات من ضبط تكوينات الاتصال بشكل تفصيلي لتلبية متطلبات محددة عبر مواقع متنوعة، مما يؤدي إلى تجربة مستخدم أكثر دقة وقابلية للتكيف لمختلف الأقسام أو السيناريوهات أو الاحتياجات. بالإضافة إلى ذلك، يمكن لعمليات النشر متعددة المواقع دعم الاتصال بين المواقع إذا كانت المواقع متصلة عبر شبكة مشتركة.

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

في تصميم متعدد المواقع، يتمتع العملاء بالمرونة في اختر المواقع التي سيتم تكوينها للبقاء التشغيلي. المواقع من دون وحدة ZPLS ستظل غير قادرة على إجراء المكالمات أو تلقيها حتى تتم استعادة الاتصال المعياري.

إخفاقات الشبكة

قد يتأثر البقاء التشغيلي إذا فشلت الشبكة المحلية للموقع

على الرغم من أن وحدات ZPLS مصممة لتوفير بقاء هاتفي محلي أثناء الفعاليات التي تؤثر في الخدمة، فإن البقاء التشغيلي قد يتأثر إذا فشلت الشبكة المحلية للموقع. يتم توضيح هذه السيناريوهات في القسمين التاليين.

فشل الشبكة المحلية في الموقع الواحد

في تصميم الموقع الواحد، يتم توصيل مبنى واحد أو أكثر عبر شبكة محلية أو شبكة منطقة حرم، ويتم تمثيلها بواسطة موقع واحد داخل Zoom Phone. يفترض هذا التكوين وجود شبكة مشتركة بين جميع المستخدمين والمباني داخل موقع واحد، من دون أي تبعيات شبكة خارجية (مثل الإنترنت) للاتصال بين المباني.

باستخدام تصميم الموقع هذا، يمكن للأعمال توفير بقاء تشغيلي محلي لجميع المستخدمين داخل موقع أو موقع واحد باستخدام أقل عدد ممكن وهو وحدة ZPLS واحدة؛ ومع ذلك، يكون هذا التصميم عرضة للخطر في حال حدوث انقطاع في الشبكة المحلية أو شبكة الحرم يؤثر في الاتصال بين المباني. يصف المثال التالي كيف يمكن أن يؤثر فشل الشبكة المحلية في نشر موقع واحد.

يوضح الجدول التالي البقاء التشغيلي في Zoom Phone في تصميم موقع واحد متعدد المباني:

المكالمات الصادرة من المبنى
يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي
يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم

المبنى A (مضيف ZPLS)

☑️ المباني A وB وC

☑️ المبنى A فقط

المبنى B

☑️ المباني A وB وC

✖️

المبنى C

☑️ المباني A وB وC

✖️

فشل الشبكة المحلية في تصميم متعدد المواقع من دون SBC

في تصميم متعدد المواقع، يتم تمثيل كل مبنى أو موقع (مثل الطابق أو المكتب الفرعي، إلخ) بشكل مستقل بواسطة موقع فريد داخل Zoom Phone. ويفترض هذا التكوين أن لكل موقع وحدة ZPLS، وأن المواقع متصلة عبر شبكة منطقة حرم مشتركة.

باستخدام تصميم الموقع هذا، يدعم كل موقع وحدة ZPLS الخاصة به، مما يسمح للمستخدمين داخل المبنى نفسه بالاتصال ببعضهم بعضًا عند تفعيل وضع البقاء التشغيلي. علاوة على ذلك، عندما تكون عدة مواقع تحتوي على وحدة ZPLS متصلة عبر شبكة مشتركة، يمكن للمستخدمين الاتصال بمستخدمين في _other_sites، طالما بقيت الشبكة المحلية قيد التشغيل. ومع ذلك، يكون هذا التصميم عرضة للخطر في حال حدوث انقطاع في شبكة منطقة الحرم يؤثر في الاتصال بين المباني. يصف المثال التالي كيف يمكن أن يؤثر فشل شبكة الحرم في نشر متعدد المواقع.

يوضح الجدول التالي البقاء التشغيلي في Zoom Phone استنادًا إلى المثال أعلاه في تصميم متعدد المواقع مع شبكة حرم مترابطة:

المكالمات الصادرة من المبنى
يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي
يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم

المبنى A (مضيف ZPLS)

☑️ المباني A وB وC

☑️ المبنى A

المبنى B (مضيف ZPLS)

☑️ المبنى A وB وC

☑️ المبنى B

المبنى C (مضيف ZPLS)

☑️ المبنى A وB وC

☑️ المبنى C

إذا فشلت شبكة محلية، فسيتم أيضًا دعم المكالمات بين المواقع عبر شبكة الهاتف العامة المترابطة، بشرط أن يكون كل موقع متصلًا بوحدة SBC وأن يكون تحويل المكالمات ممكّنًا

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

يوضح الجدول التالي أيضًا البقاء التشغيلي في Zoom Phone في تصميم متعدد المواقع مع وحدات SBC مستقلة:

المكالمات الصادرة من المبنى
يمكنها الوصول إلى هذه المواقع أثناء فشل الإنترنت الخارجي
يمكنها الوصول إلى هذه المواقع أثناء فشل شبكة الحرم

المبنى A (مضيف ZPLS)

☑️ المباني A وB وC

☑️ المباني A وB وC

المبنى B (مضيف ZPLS)

☑️ المباني A وB وC

☑️ المباني A وB وC

المبنى C (مضيف ZPLS)

☑️ المباني A وB وC

☑️ المباني A وB وC

يسجل المستخدمون المتنقلون دائمًا في وحدة ZPLS المرتبطة بموقعهم الأساسي

عند إضافة مستخدمين أو أجهزة إلى Zoom Phone، يتم ربط موقع «أساسي» بشكل ثابت بالمستخدم أو الجهاز حتى يتم تحديثه بخلاف ذلك بواسطة مسؤول الحساب. وهذا يعني أنه إذا انتقل مستخدم إلى موقع فعلي خارج موقعه الأساسي المرتبط، مثل مبنى مكاتب مرتبط بموقع مختلف، فلن يقوم Zoom بضبط الموقع المرتبط بالمستخدم بشكل ديناميكي. ونتيجة لذلك، إذا فقد المستخدم الاتصال بمراكز بيانات Zoom Phone، فسيحاول المستخدم التسجيل في وحدة ZPLS المرتبطة بموقعه الأساسي، حتى إذا كان في موقع مختلف.

آخر تحديث

هل كان هذا مفيدا؟