Дякуємо за відгук.
Обмеження ємності користувачів для гібридних служб на основі експрессвей
Надіслати відгук?Гібри дна служба дзвінків на архітектурі Call Connector закінчилася терміном служби (EOL), тому служба більше не підтримується офіційно. З'єднувач виклику не слід розглядати для майбутнього планування пропускної спроможності швидкісної дороги для гібридних послуг.
Ця стаття не охоплює планування ємності для інтеграції служби гібри дного календаря Cisco TMS з Office 365 або інтеграції Cisco TMS з календарем Google. Для отримання інформації про ємність див. посібник із роз гортання служби Cisco Webex гібридного календаря.
Ми надаємо цю статтю, щоб вирішити ваші запитання щодо планування потужності та пояснити, як ми розраховуємо масштаб користувачів. Щоб змоделювати свій сценарій, спробуйте калькулятор ємності Hybrid Services.
Міркування планування
Плануючи пропускну здатність швидкісної дороги для населення користувачів Hybrid Services, враховуйте наступні питання:
-
Які гібридні послуги вам потрібні?
Швидкісна дорога може розміщувати роз'єми для служби гібридних викликів, служби гібридного календаря та служби гібридних повідомлень.
-
Скільки користувачів у вас для кожної послуги?
Чим більше користувачів у вас для кожної послуги, тим більша ймовірність того, що ви захочете присвятити кластери Expressway службам. Для менших груп населення правильним вибором є запуск декількох роз'ємів у спільному кластері (спільна резиденція).
-
Ваші потреби зміняться?
Можливо, ви захочете почати з малого, з одного кластера Expressway, який надає послуги групі ранніх користувачів у вашій організації, і плануйте зростання для майбутнього розгортання. Ви можете перейти зі спільної моделі на виділену модель або масштабувати існуючий кластер відповідно до ваших вимог, що розвиваються.
Фактори, що сприяють
Ми визначаємо ємність кластера з точки зору наступних змінних:
-
Розмір вузла — кожна віртуальна машина Expressway має «розмір віртуальної машини», який визначається під час встановлення ресурсами, призначеними для віртуальної машини. Посіб ники з встановлення швидкісної дороги описують ці вимоги. Якщо у вас вже є швидкісна дорога, ви можете прочитати розмір віртуальної машини на сторінці су швидкісної дороги.
-
Кількість вузлів — Кластер швидкісної дороги може мати від одного до шести вузлів. Вони повинні мати однаковий розмір вузла і запускати одну і ту ж версію програмного забезпечення.
-
Стратегія безперерв ності обслуговування - Служби використовують стратегії для забезпечення безперервного обслуговування користувачів. Служба календаря та служба повідомлень використовують стратегію відмови.
Стратегії детально описані в таблиці С тратегії безперерв ності обслуговування та масштаб виділених кластер ів.
-
Спільне проживання — коли з'єднувачі мають спільний кластер швидкісної дороги, ресурси, доступні для кожної служби, значно нижчі порівняно з виділеним кластером.
На вашому хості роз'єму також можуть бути інші служби на основі ExpressWay, як-от дзвінки від бізнесу до бізнесу (B2B) або Мобільні та Remote Access (MRA). У обмежених сценаріях, де підтримується цей тип спільного проживання, номери масштабів, які ми документуємо тут, обмежені тим, що ми перевірили. Крім того, що описано в цій статті, кластер Expressway хосту роз'єму не повинен бути спільним з іншими службами; це не підтримується.
-
Обмеження для конкретних служб. Наприклад, роз'єм календаря призначений переважно для Microsoft Exchange користувачів і підтримує обмежену кількість користувачів Office 365.
Розрахунки для виділених кластерів швидкісних доріг
Ми встановили жорстке обмеження кількості користувачів послуг, якими може керувати спеціальна швидкісна дорога («кластер однієї»), на основі доказів, які ми збираємо під час тестування та випробувань.
| Розмір вузла швидкісної дороги | Гібридна шкала послуг календаря | Гібридна шкала служби повідомлень |
|---|---|---|
| 1. Маленький | 5000 | 5000 |
| 2. Середній | 10000 | 6500 |
| 3. Великі | 15000 | 15000 |
Ми використовуємо алгоритми безперервності обслуговування для екстраполяції номерів окремих вузлів на кілька кластерів вузлів, як пояснено в наступній таблиці. Якщо ви хочете отримати результати без пояснення, див.:
|
Порівняти |
Гібридна служба календаря |
Гібридна служба повідомлень |
|---|---|---|
|
1. Модель |
Модель відмови |
Модель відмови |
|
2. Опис |
Призначаємо кожному користувачеві один вузол в кластері. Це поширює користувачів по всіх вузлах. Якщо вузол падає, ми відтворюємо призначення користувачів з цього вузла на інших вузлах. Коли вузол повертається назад, ми перебалансуємо призначення користувачів у всіх активних вузлах. |
Призначаємо кожному користувачеві один вузол в кластері. Це поширює користувачів по всіх вузлах. Якщо вузол падає, ми відтворюємо призначення користувачів з цього вузла на інших вузлах. Коли вузол повертається назад, ми перебалансуємо призначення користувачів у всіх активних вузлах. |
|
3. Формула |
У к алН = (Н-1) * У кал1 |
У м Сгн = (Н-1) * У мсг1 |
|
4. Визначення |
Де: U CalN - кластер ємності N для користувачів служби календар я N - кількість вузлів U cal1 — ємність одного вузла для користувачів служби календаря |
Де: U mSgn — кластер ємності N для користувачів служби повідомлень N - кількість вузлів U msg1 - ємність одного вузла для користувачів служби повідомлень |
|
5. Примітки |
Якщо N = 1, не відбувається відмови. Передача відмови є автоматичною та обов'язковою, якщо N>1. Якщо N = 2, ємність така ж, як якщо N = 1, з кращ ою безперервністю служби. Масштаб виграє від N>=3 або за допомогою більшого розміру вузла. |
Якщо N = 1, не відбувається відмови. Передача відмови є автоматичною та обов'язковою, якщо N>1. Якщо N = 2, ємність така ж, як якщо N = 1, з кращ ою безперервністю служби. Масштаб виграє від N>=3 або за допомогою більшого розміру вузла. |
Розрахунки для спільних кластерів швидкісних доріг
Наш алгоритм передбачає, що корезидентні роз'єми пропорційно поділяють ресурси одного вузла. Цей алгоритм консервативно встановлює ліміт для кожного типу користувача на вузлі.
Наприклад, наступна таблиця показує максимальну кількість користувачів для всіх спеціалізованих випадків та випадків спільного проживання на одній середній швидкісній дорозі.
| Призначення швидкісної дороги | Користувачі служби календаря | Користувачі служби повідомлень |
|---|---|---|
|
| ||
| Присвячений службі календаря |
10,000 |
— |
|
Присвячений службі повідомлень |
— |
6,500 |
|
Спільна службою календаря та службою повідомлень |
4,000 |
4,000 |
|
Спільне використання службами календаря, дзвінків та повідомлень |
2,300 |
2,300 |
Ми не вичерпно перераховуємо всі стани спільної резиденції для всіх розмірів кластерів. Натомість ви можете контролювати потужність існуючого розгортання Hybrid Services або використовувати калькулятор для планування нового розгортання.
Калькулятор дозволяє вибрати роз'єми, розмір вузлів та кількість вузлів, щоб ви могли моделювати своє розгортання. Решта цього розділу пояснює, як він обчислює номери користувачів з вашої моделі.
Так само, як і для спеціальної швидкісної дороги, ми екстраполюємо алгоритм спільних швидкісних доріг для визначення номерів користувачів для кількох вузлів. Відмінність від спеціальних випадків полягає в тому, що ми застосовуємо відповідний розрахунок безперервності обслуговування, щоб отримати масштаб користувача для пев ної служби в кластері. Ми не можемо розрахувати масштаб користувача для кластера, оскільки кла стер містить конкуруючі стратегії безперервності обслуговування на основі користувачів.
|
Призначення кластера |
Користувачі гібридної служби повідомлень для 1,2 та 3 вузлів | ||
|---|---|---|---|
|
Присвячений службі повідомлень |
6,500 |
6,500 |
13,000 |
Додаткові фактори, що сприяють
Можуть виникнути конкуруючі вимоги до ресурсів кластера, які зменшать ємність користувачів. Ось відомі приклади:
Служба кален даря — хост роз'єму також може обслуговувати користувачів O365. Цифри та обчислення, показані тут, передбачають, що службу календаря забезпечує лише локальна інфраструктура Exchange. Щоб дізнатися більше про «гібридну» службу календаря, ми маємо деякі цифри та графіки в розділі Служба календаря цієї статті.
Обробка викликів — Хост роз'єму може також обробляти сигналізацію викликів та носій інформації. Це фактично інтеграція «Бізнес до бізнесу» між вашою організацією та хмарою Webex. Це зменшує пропускну здатність, як описано в розділі Спільне проживання з іншими рішеннями швидкісних доріг.
Ви можете використовувати Центр керування, щоб переглянути відсоткове значення поточної місткості користувачів кожного з ваших ресурсів Hybrid Services Expressway. Колірна смуга вказує на те, чи знаходиться ємність в прийнятних межах. Цей перегляд дає змогу оцінити справність розгортання гібридних служб та направляти вас, коли вам потрібно більше швидкісних доріг.
-
Зелений — Ваші швидкісні дороги знаходяться в межах прийнятних обмежень пропускної здатності. (1%–60%)
-
Ян тар - У вас достатньо швидкісних доріг, але ви близькі до досягнення обмежень пропускної здатності. (61%–90%)
-
Червоний - У вас недостатньо швидкісних доріг, і ви повинні додати більше. (91% і вище)
Якщо швидкісні дороги входять до групи ресурсів, індикатор ємності відображається під фільтрованим переглядом кластерів у групі ресурсів.
-
Для розгортання без груп ресурсів (за замовчуванням):
-
У поданні клієнта на сторінці https://admin.webex.com перейдіть до розділу Служби , щоб переглянути відсоток пропускної здатності, використаної на ресурсах швидкісної дороги для кожної служби.
-
-
Для розгортання з групами ресурсів:
-
Якщо значення ємності не застосовується, виберіть групу ресурсів у розділі Філь тр, щоб переглянути групи ресурсів та місткість.
Значення оновлюється, щоб показати відсоток ємності, який використовується для кластерів у цій групі ресурсів, та кольорове кодування для вказівки стану здоров'я.
-
Речі, про які слід пам'ятати
-
Ємність кластера залежить від розміру вузла, кількості вузлів у кластері Expressway, кількості служб, що працюють у кластері, а також високої доступ ності або стратегії відмови. Докладніші відомості див. окремі розділи «Календар» та «Шкала повідомлень».
-
Спільна резиденція зменшує масштаб користувачів для існуючих служб; алгоритм ємності передбачає, що кожен користувач використовує всі послуги.
Ми рекомендуємо спільне проживання, коли ви випробовуєте кілька служб або якщо у вас є невелике розгортання. Для послуг у виробництві або для масштабного розгортання ми рекомендуємо запускати різні гібридні служби на виділених кластерах Expressway.
Що робити далі
Щоб додати більше швидкісних шляхів для гібридних служб, скористайтеся кроками з розгортання для реєстрації хостів роз'ємів у хмарі та додавання їх до існуючих кластерів:
Потужність кластера швидкісної дороги для обслуговування користувачів служби гібридного календаря залежить від розміру складових вузлів Expressway-C, кількості вузлів у кластері швидкісної дороги та стратегії безперервності обслуговування.
У наступній таблиці показано максимальну кількість користувачів на одній швидкісній дорозі, призначеній для різних середовищ гібридного календаря.
|
Середовище календаря |
Мала швидкісна дорога |
Середня швидкісна дорога |
Велика швидкісна дорога |
|---|---|---|---|
|
Лише локальний Exchange |
5 000 користувачів |
10 000 користувачів |
15 000 користувачів |
|
Лише Office 365* |
1000 користувачів |
1000 користувачів |
1000 користувачів |
|
Локальні Exchange і Office 365* (розгортання гібридної біржі) |
Максимально 1 000 користувачів Office 365 із загальної кількості 5 000 користувачів |
Максимально 1000 користувачів Office 365 із 10 000 користувачів |
Максимально 1 000 користувачів Office 365 із загальної кількості 15 000 користувачів |
* Щоб уникнути цього обмеження масштабу, радимо використовувати хмарну службу календаря замість локального роз'єму. Для гібридного календаря на основі Express обмеження місткості користувачів Office 365 до 1000 на кластер не залежить від розміру або кількості вузлів кластера; це обмеження випливає з взаємодії з хмарною службою Microsoft, а не від масштабу локального розгортання Expressway.
Зверніть увагу, що ємність користувача однакова для кластера з одного вузла і для кластера з двох вузлів. Це пов'язано з тим, що служба календаря використовує відмовний перехід для покращення безперервності служби. Усі користувачі призначаються одному вузлу, коли в кластері є два вузли; інший вузол є надлишковою резервною копією. Докладне пояснення див. у розділі Планування потужності кластерів швидкісних доріг для користувачів гібридних послуг.
Потужність кластера Expressway для користувачів служби гібридного календаря в першу чергу залежить від розміру та кількості вузлів у кластері, а також стратегії безперервності обслуговування. У наведеній нижче таблиці показано максимальну загальну ємність користувача, яку кластер може обробляти, коли ви збільшуєте вузли (або розмір вузла OVA) на одному виділеному кластері.
У гібридному середовищі Exchange з користувачами Office 365 існує обмеження в 1000 користувачів Office 365 на кластер незалежно від кількості вузлів або розміру кластера. Хмарна служба є кращим методом обробки користувачів Office 365. Ми настійно рекомендуємо тимчасово розміщувати користувачів Office 365 лише на Expressway.
Це обмеження випливає з взаємодії з хмарною службою Microsoft, а не з масштабу локального розгортання Expressway. Наприклад, якщо у вас є один невеликий вузол Expressway, ваша ємність обмежена 1000 користувачів Office 365 та 4 000 Microsoft Exchange користувачів. Якщо у вас є кластер з 6 невеликих вузлів, ваша ємність обмежена 1000 користувачів Office 365 плюс 24 000 Microsoft Exchange користувачів.
|
Розмір вузла швидкісної дороги |
1 або 2 вузли* |
3 вузли |
4 вузли |
5 вузли |
6 вузли |
|---|---|---|---|---|---|
|
1. Маленький |
5K |
10K |
15K |
20K |
25K |
|
2. Середній |
10K |
20K |
30K |
40K |
50K |
|
3. Великі |
15K |
30K |
45K |
60K |
75K |
* Зверніть увагу, що ємність користувача однакова для кластера з одного вузла і для кластера з двох вузлів. Це пов'язано з тим, що Служба календаря використовує відмову для покращення безперервності служби. Усі користувачі призначаються одному вузлу, коли в кластері є два вузли; інший вузол є надлишковою резервною копією. Докладне пояснення див. у розділі Планування потужності кластерів швидкісних доріг для користувачів гібридних послуг.
Призначення користувачів між хостами та кластерами
За замовчуванням служба гібридного календаря автоматично призначає та розподіляє користувачів рівномірно по всіх роз'ємах календаря в кластері. Призначення є динамічним залежно від доступності, і адміністратор не має контролю над тим, до якого конкретного вузла призначений окремий користувач.
У випадках, коли організація має більше одного кластера, розподіл користувачів базується на кількох факторах, включаючи доступність кластера, поточне призначення (для зменшення відхилення під час відновлення помилок) та порядок сортування на основі найвищих параметрів кластера. Адміністратор також має можливість призначити користувача або групу користувачів до групи ресурсів. Групи ресурсів є специфічними для кластерів, тому вони дозволяють адміністраторам обмежувати призначення певних наборів користувачів певному кластеру.
Завдяки цьому базовому розумінню призначення користувачів та беручи до уваги передумови Expressway Calendar Connector, адміністратор може розгорнути відповідну потужність у масштабі для своєї організації. Давайте розглянемо приклад організації з 126 000 користувачів, які будуть включені для служби гібридного календаря, враховуючи такі параметри:
-
Кластери швидкісних доріг з 6 вузлів за допомогою великого шаблону OVA (ліміт 15 000 користувачів на вузол)
-
Групи ресурсів не потрібні
Формула ємності для одного кластера, U CalN = (N-1) * U cal1 де N = 6 і U cal1 = 15 000 (за допомогою великого шаблону OVA) дає максимум 75 000 користувачів. З загальною кількістю користувачів у розгортанні служби календаря потрібно кілька хост-кластерів Calendar Connector. Користувачі будуть розподілені порівну, як показано на наступному малюнку:
Служба гібридного календаря спочатку додає користувачів до кластера А, поки кластер не досягне обсягу 75 000 користувачів, а потім призначає інших користувачів до кластеру B. Користувачі розподілені випадковим чином і однаково по всіх вузлах у кластері. У цьому прикладі показано рівномірний розподіл вузлів хоста роз'єму календаря (у кожному з двох кластерів) між центрами обробки даних RTP та PDX. Кожен вузол використовує той самий шаблон OVA і відповідає правилам високої доступності швидкісної дороги. Роз'єм календаря використовує логіку кластеризації Expressway в моделі резервування 5+1, щоб забезпечити сценарії високої доступності.
З усіма користувачами, призначеними для роз'єму календаря, давайте тепер розглянемо, що відбувається, коли відбувається збій у кластері. На наступному малюнку показаний вихід з ладу одного вузла. Користувачі, яким було призначено невдалий вузол, 5A у кластері A, тепер не вдалося перейти до решти вузлів у цьому кластері. Ємність одного вузла дозволяє приймати до 15 000 користувачів, і кожен вузол, що залишається в кластері А, додає 2500 користувачів, які спочатку були призначені для вузла 5A. Немає змін або впливу на кластер B або на користувачів, призначених у кластері B.
Кластер А все ще має максимальну ємність, і кожен з операційних вузлів у кластері тепер має максимальну ємність, 15 000 користувачів/вузол. Тому, якщо інший вузол у кластері A стане недоступним, наприклад, вузол 4A на наступному малюнку, кластер B тепер буде відповідати за отримання додаткового навантаження користувача. 15 000 користувачів з вузла 4A тепер перепризначені до кластеру B і рівномірно розподілені по всіх вузлах у кластері B.
Коли вузли 4A і 5A відновляться, користувачі кластера A будуть перерозподілені між вузлами в кластері. Користувачі, яким не вдалося перейти до кластера B, залишаються на кластері B під час цієї фази відновлення, щоб уникнути непотрібних призначень користувачів між кластерами, як показано на наступному малюнку.
Ключовим пунктом, про який слід пам'ятати при плануванні масштабного розгортання служби гібридного календаря, є розуміння впливу збою, якщо вона виникла під час розгортання. Якщо ми використовуємо те саме розгортання 126 000 користувачів, але випадково втрачаємо цілий центр обробки даних, існує ймовірність того, що користувачі не будуть призначені до вузла роз'єму календаря. Щоб запобігти відключенню служби за такого сценарію, клієнту знадобиться третій кластер для перерозподілу та обробки постраждалих користувачів.
Потужність кластера швидкісної дороги для обслуговування користувачів гібридних повідомлень залежить від розміру вузлів швидкісної дороги, кількості вузлів у кластері та стратегії безперервності обслуговування.
У наступній таблиці показано максимальну кількість користувачів на одній швидкісній дорозі, яка використовується для гібридного повідомлення.
|
Мала швидкісна дорога |
Середня швидкісна дорога |
Велика швидкісна дорога |
|---|---|---|
|
5 000 користувачів |
6 500 користувачів |
15 000 користувачів |
Номери користувачів однакові для кластера з одного вузла і для кластера з двох вузлів. Це пов'язано з тим, що служба повідомлень використовує відмовний перехід для покращення безперервності служби. Користувачі розподіляються рівномірно по декількох вузлах у кластері: якщо один вузол виходить з ладу, користувачі цього вузла призначаються іншим вузлам.
Ця тема стосується спільного використання хоста роз'єму Expressway між роз'ємами для кількох гібридних служб, включаючи службу календаря та службу повідомлень. Хост роз'єму не використовується для спільного використання з іншими рішеннями на основі ExpressWay, такими як MRA та B2B.
Ємність хост-кластера роз'єму залежить від розміру вузлів швидкісної дороги, кількості вузлів, роз'ємів, які працюють у кластері, та стратегії безперервності обслуговування. Див. Планування потужності кластерів швидкісних доріг для користувачів гібридних послуг для детального пояснення цих факторів.
Існує також калькулятор для моделювання різних кластерів хостів роз'ємів і перегляду, скільки користувачів кожної служби може підтримувати запропонований вами кластер.
Загалом, ми рекомендуємо спільну резиденцію лише для розгортання меншого розміру до двох вузлів. Якщо ваше розгортання перевищує ємність пари вузлів, вам слід перемістити з'єднувачі до кластерів Expressway, які призначені для кожної конкретної гібридної служби.
Приклад: Шкала хоста роз'єму з трьома корезидентними роз'ємами
У наступній таблиці наведено приклад масштабу та співпроживання. Він дає максимальну кількість користувачів на кластер для кожної служби з різними специфікаціями хост-кластера роз'єму. Кластер має спільний доступ між гібридним календарем (за допомогою локального Exchange), гібридним викликом та службою гібридних повідомлень.
|
Сервіс |
Два маленькі вузли |
Два середні вузли |
Два великих вузли |
|---|---|---|---|
|
Користувачі служби календаря |
1,300 |
2,300 |
3,000 |
|
Користувачі служби повідомлень |
1,300 |
2,300 |
3,000 |
Вступ
Ця тема стосується спільного використання коннектора Expressway з іншими рішеннями на базі Expressway. Якщо ви вирішите розміщувати роз'єми на швидкісній дорозі, яку ви використовуєте для інших цілей, застосовуються такі важливі застереження:
-
Ми не можемо підтримати модель масштабованості, яка застосовується до виділеного вузла роз'єму Expressway. Номери користувачів, отримані під час прочитання інших тем цієї статті або за допомогою калькулятора, не застосовуються, якщо хост роз'єму спільно використовується з іншими службами Expressway.
-
Єдиними підтримуваними сценаріями є комбінації служб на основі ExpressWay та гібридних роз'ємів служб, описані в цій статті, та пов'язані номери користувачів. Ми не тестували інших сценаріїв, і ви не можете очікувати, що вони працюватимуть у вашому середовищі.
Служба календаря на основі Expressway з роз'ємом дзвінків та траверсуванням служби виклику
У цьому сценарії двовузловий кластер Expressway з'єднує з'єднувачі гібридного календаря. Кластер також здійснює перехід дзвінків для інших рішень Cisco для викликів (сигналізації SIP та медіа).
У таблиці наведено різні середовища календаря, які можна використовувати з роз'ємом на основі ExpressWay. Роз'єм календаря на основі ExpressWay не підтримується у кластерах з більш ніж двома вузлами. Використовуйте хмарний роз'єм для більшого масштабування Office 365 (див. Масшта б служби календар я).
|
Сервіс |
Кластер двох малих вузлів |
Кластер двох середніх вузлів |
Кластер двох великих вузлів | |
|---|---|---|---|---|
|
Служба календаря |
Локальна біржа |
500 користувачів |
1000 користувачів |
1000 користувачів |
|
Офіс 365 † |
500 користувачів |
1000 користувачів |
1000 користувачів | |
|
Локальні Exchange і Office 365 (гібридні розгортання Exchange) |
Макс 500 користувачів для обох |
Макс 1000 користувачів для обох |
Макс 1000 користувачів для обох | |
|
Перехід дзвінків |
200 аудіо сесій 100 відеосесій |
200 аудіо сесій 100 відеосесій |
1000 аудіо сесій 500 відеосесій | |
† Щоб уникнути цього обмеження масштабу, радимо використовувати хмарну службу календаря замість локального роз'єму. Для гібридного календаря на основі Express обмеження місткості користувачів Office 365 до 1000 на кластер не залежить від розміру або кількості вузлів кластера; це обмеження випливає з взаємодії з хмарною службою Microsoft, а не від масштабу локального розгортання Expressway.
Календар з мобільним і Remote Access
У цьому сценарії кластер MRA з одного або двох невеликих віртуальних машин Expressway розміщує роз'єм календаря. Цей сценарій передбачає, що кластер використовується лише для MRA та двох роз'ємів. Кластер обмежений одним або двома невеликими вузлами.
|
Призначення швидкісної дороги |
Кластер одного маленького експрессвей-С |
Кластер двох малих експрессвей-С |
|---|---|---|
|
Користувачі служби календаря (локальний роз'єм до Exchange) |
500 користувачів |
500 користувачів |
|
Мобільні пристрої та Remote Access користувачі |
100 |
100 |
