تعتمد قدرة مجموعة Expressway على خدمة مستخدمي خدمة التقويم الهجين على حجم عقد Expressway-C المكونة لها، وعدد العقد في مجموعة Expressway، واستراتيجية استمرارية الخدمة.

يوضح الجدول التالي الحد الأقصى لعدد المستخدمين على مسار سريع واحد مخصص لبيئات التقويم الهجين المختلفة.

_{* لتجنب هذا القيد المتعلق بالحجم، نوصي باستخدام خدمة التقويم السحابية بدلاً من الموصل المحلي. بالنسبة للتقويم الهجين القائم على Expressway، فإن تقييد سعة مستخدمي Office 365 إلى 1000 لكل مجموعة مستقل عن حجم أو عدد عقد المجموعة؛ وينشأ هذا التقييد من التفاعل مع خدمة Microsoft السحابية وليس من نطاق نشر Expressway المحلي.}

لاحظ أن سعة المستخدم هي نفسها بالنسبة لمجموعة مكونة من عقدة واحدة ومجموعة مكونة من عقدتين. وذلك لأن خدمة التقويم تستخدم خاصية تجاوز الفشل لتحسين استمرارية الخدمة. يتم تعيين كل المستخدمين إلى عقدة واحدة عندما تكون هناك عقدتان في الكتلة ؛ العقدة الأخرى هي نسخة احتياطية زائدة عن الحاجة. راجع تخطيط سعة مجموعة الطرق السريعة لمستخدمي الخدمات المختلطة للحصول على شرح مفصل.

تعتمد سعة مجموعة Expressway لمستخدمي Hybrid Calendar Service بشكل أساسي على حجم وعدد العقد في المجموعة ، واستراتيجية استمرارية الخدمة. يوضح الجدول التالي الحد الأقصى لسعة المستخدم الإجمالية التي يمكن للمجموعة التعامل معها أثناء قيامك بزيادة العقد (أو حجم العقدة OVA) في مجموعة مخصصة واحدة.

_{* لاحظ أن سعة المستخدم هي نفسها لمجموعة من عقدة واحدة ومجموعة من عقدتين. وذلك لأن خدمة التقويم تستخدم تجاوز الفشل لتحسين استمرارية الخدمة. يتم تعيين كل المستخدمين إلى عقدة واحدة عندما تكون هناك عقدتان في الكتلة ؛ العقدة الأخرى هي نسخة احتياطية زائدة عن الحاجة. انظر تخطيط سعة مجموعة الطرق السريعة لمستخدمي الخدمات الهجينة للحصول على شرح مفصل.}

تعيين المستخدم عبر المضيفين والكتل

بشكل افتراضي ، تقوم خدمة التقويم المختلط تلقائيًا بتعيين المستخدمين وتوزيعهم بالتساوي عبر جميع موصلات التقويم في مجموعة. التعيين ديناميكي بناءً على التوفر ، ولا يتحكم المسؤول في أي عقدة معينة تم تعيين مستخدم فردي لها.

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

من خلال هذا الفهم الأساسي لتعيين المستخدم ومع مراعاة المتطلبات الأساسية لـ Expressway Calendar Connector ، يمكن للمسؤول نشر السعة المناسبة على نطاق واسع لمؤسستهم. لنلقِ نظرة على مثال مؤسسة تضم 126000 مستخدم ليتم تمكينها لخدمة التقويم المختلط ، مع الأخذ في الاعتبار المعلمات التالية:

• مجموعات الطرق السريعة المكونة من 6 عقد باستخدام نموذج OVA الكبير (بحد 15000 مستخدم لكل عقدة)

• لا مجموعات الموارد المطلوبة

صيغة السعة لمجموعة واحدة ، U _calN = (N-1) * U _cal1 حيث N = 6 و U _cal1 = 15000 (باستخدام قالب OVA الكبير) ينتج 75000 مستخدم كحد أقصى. مع وجود 126000 مستخدم في نشر خدمة التقويم ، يلزم وجود مجموعات مضيف متعددة لـ Calendar Connector. سيتم توزيع المستخدمين بالتساوي كما هو موضح في الشكل التالي:

تضيف خدمة التقويم الهجين المستخدمين إلى المجموعة "أ" أولاً حتى تصل الكتلة إلى سعة مستخدم تبلغ 75000 مستخدم ، ثم تقوم بتعيين المستخدمين المتبقين إلى المجموعة "ب". ويتم توزيع المستخدمين عشوائيًا وبشكل متساوٍ عبر جميع العقد داخل المجموعة. يوضح هذا المثال توزيعًا متساويًا لعقد مضيف رابط التقويم (داخل كل من المجموعتين) عبر مراكز البيانات RTP و PDX. تستخدم كل عقدة نموذج OVA نفسه ويتبع إرشادات التوفر السريع للطرق السريعة . يستخدم Calendar Connector منطق المجموعة Expressway في نموذج 5 + 1 التكرار للسماح بسيناريوهات التوفر العالي.

مع تعيين جميع المستخدمين لـ Calendar Connector ، دعنا الآن نفحص ما يحدث عندما يكون هناك فشل في مجموعة. يوضح الشكل التالي فشل عقدة واحدة. المستخدمون الذين تم تعيينهم للعقدة الفاشلة ، 5A في المجموعة A ، فشلوا الآن في الوصول إلى العقد المتبقية في تلك المجموعة. تسمح سعة العقدة الواحدة لما يصل إلى 15000 مستخدم وتضيف كل عقدة متبقية في المجموعة A 2500 مستخدم تم تعيينهم في الأصل على العقدة 5A. لا يوجد تغيير أو تأثير على المجموعة ب أو على المستخدمين المعينين في المجموعة ب.

لا تزال المجموعة (أ) في أقصى سعة ، وكل من العقد التشغيلية في الكتلة الآن بأقصى سعة ، 15000 مستخدم / عقدة. لذلك ، إذا أصبحت عقدة أخرى في المجموعة A غير متوفرة ، مثل العقدة 4A في الشكل التالي ، فإن المجموعة B ستكون الآن مسؤولة عن التقاط حمل المستخدم الإضافي. تم الآن إعادة تعيين 15000 مستخدم من العقدة 4A إلى المجموعة B وتوزيعها بالتساوي عبر جميع العقد داخل المجموعة B.

عند استعادة العقدتين 4A و 5A ، سيتم إعادة توزيع المستخدمين في المجموعة A عبر العقد في المجموعة. المستخدمون الذين فشلوا في المجموعة B يظلون في المجموعة B خلال مرحلة الاسترداد هذه لتجنب تعيينات المستخدم غير الضرورية بين المجموعات ، كما هو موضح في الشكل التالي.

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

تعتمد قدرة مجموعة Expressway على خدمة مستخدمي الرسائل الهجينة على حجم عقد Expressway المكونة لها، وعدد العقد في المجموعة، واستراتيجية استمرارية الخدمة.

يوضح الجدول التالي الحد الأقصى لعدد المستخدمين على طريق سريع واحد يستخدم للرسائل الهجينة.

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

تعتمد سعة مجموعة مضيف الموصل على حجم عقد Expressway المكونة وعدد العقد والموصلات التي تعمل على الكتلة واستراتيجية استمرارية الخدمة. راجع تخطيط سعة مجموعة الطرق السريعة لمستخدمي الخدمات المختلطة للحصول على شرح تفصيلي لهذه العوامل.

هناك أيضًا آلة حاسبة لتصميم مجموعات مضيف موصل مختلفة ومعرفة عدد المستخدمين لكل خدمة يمكن أن تدعمها المجموعة المقترحة.

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

مثال: مقياس مضيف الموصل مع ثلاثة موصلات أساسية

يوضح الجدول التالي مثالاً على المقياس والنوى. فهي توفر الحد الأقصى لعدد المستخدمين لكل مجموعة ، لكل خدمة ، بمواصفات مختلفة لمجموعة مضيف الموصل. يتم مشاركة المجموعة بين التقويم الهجين (باستخدام Exchange المحلي الخاص بك)، والمكالمات الهجينة، وخدمة الرسائل الهجينة.

مقدمة

يدور هذا الموضوع حول مشاركة مضيف موصل Expressway مع الحلول الأخرى المستندة إلى Expressway. عندما تختار استضافة الموصلات على إحدى الطرق السريعة التي تستخدمها لأغراض أخرى ، تسري التحذيرات المهمة التالية:

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

• مجموعات الخدمات المستندة إلى Expressway وروابط الخدمات المختلطة الموضحة في هذه المقالة ، وأرقام المستخدمين المرتبطة ، هي السيناريوهات الوحيدة المدعومة. لم نختبر سيناريوهات أخرى ، ولا يمكنك أن تتوقع منها أن تعمل في بيئتك.

خدمة التقويم المستندة إلى Expressway مع Call Connector و Call Service Traversal

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

يعرض الجدول بيئات التقويم المختلفة التي يمكنك استخدامها مع الموصل المستند إلى Expressway. لا يتم دعم موصل التقويم المستند إلى Expressway في المجموعات التي تحتوي على أكثر من عقدتين. استخدم الموصل المستند إلى مجموعة النظراء للحصول على نطاق أكبر مع Office 365 (راجع مقياس خدمة التقويم ).

_{† لتجنب قيود النطاق هذه ، نوصي باستخدام خدمة التقويم المستندة إلى مجموعة النظراء بدلاً من الموصل الداخلي. بالنسبة للتقويم الهجين القائم على Expressway، فإن تقييد سعة مستخدمي Office 365 إلى 1000 لكل مجموعة مستقل عن حجم أو عدد عقد المجموعة؛ وينشأ هذا التقييد من التفاعل مع خدمة Microsoft السحابية وليس من نطاق نشر Expressway المحلي.}

التقويم مع الوصول عن بعد والجوال

في هذا السيناريو ، تستضيف كتلة MRA من واحد أو اثنين من Expressway VMs الصغيرة رابط التقويم. يفترض هذا السيناريو أن الكتلة تستخدم فقط من أجل MRA والموصلين. الكتلة محدودة لعقد أو عقدتين صغيرتين.