Utilizați acest articol pentru a planifica capacitatea conectorului pentru implementările serviciului hibrid Webex și pentru a înțelege recomandările de scalabilitate. Atât pentru implementările de conectori dedicați, cât și pentru cei coresidenți, veți găsi numărul maxim de utilizatori acceptat pentru clusterele de conectori, factorii care determină limitele de utilizator acceptate și modul de utilizare a Control Hub pentru a evalua dacă trebuie să adăugați mai multe drumuri expres.
Serviciul de apeluri hibride din arhitectura Call Connector a dispărut End of Life (EOL),astfel încât serviciul nu mai este acceptat oficial. Call Connector nu ar trebui să fie luate în considerare pentru planificarea viitoare a capacității Expressway pentru Servicii hibride. |
Acest articol nu acoperă planificarea capacității pentru integrarea Cisco TMS Hybrid Calendar Service cu integrarea Office 365 sau Cisco TMS cu Google Calendar. Pentru informații despre capacitate, consultați Ghidul de implementare pentru Serviciul Cisco Webex Hybrid Calendar. |
Vă oferim acest articol pentru a răspunde întrebărilor dvs. de planificare a capacității și pentru a explica modul în care calculăm scala utilizatorilor. Pentru a modela scenariul, încercați calculatorul de capacitate Serviciihibride .
Considerații de planificare
Atunci când planificați capacitatea Expressway pentru populația de utilizatori Ai Serviciilor Hibride, luați în considerare următoarele întrebări:
De ce servicii hibride aveți nevoie?
Autostrada poate găzdui conectori pentru Serviciul de apeluri hibride, Serviciul calendar hibrid și Serviciul de mesaje hibride.
Câți utilizatori aveți, pentru fiecare serviciu?
Cu cât aveți mai mulți utilizatori pentru fiecare serviciu, cu atât este mai probabil să doriți să dedicați clustere Expressway serviciilor. Pentru populațiile mai mici, executarea mai multor conectori pe un cluster partajat (coresidency) este o alegere validă.
Nevoile tale se vor schimba?
Poate doriți să începeți mici, cu un cluster Expressway furnizarea de servicii pentru un grup de adoptatori timpurii în organizația dvs., și planul de creștere pentru o lansare viitoare. Puteți să migrați de la un model partajat la un model dedicat sau să scalați clusterul existent pentru a vă satisface cerințele în evoluție.
Factori care contribuie
Definim capacitatea unui cluster în ceea ce privește următoarele variabile:
Dimensiunea nodului— Fiecare mașină virtuală Expressway are o "dimensiune VM" care este determinată în momentul instalării de resursele atribuite VM. Ghidurile de instalare Expressway descriu aceste cerințe. Dacă aveți deja un drum expres, puteți citi dimensiunea VM pe interfeței Expressway.
Număr de noduri— Un cluster Expressway poate avea între unul și șase noduri. Acestea trebuie să aibă aceeași dimensiune a nodului și să ruleze aceeași versiune de software.
Strategia de continuitatea serviciilor – Serviciile utilizează strategii pentru a asigura servicii continue utilizatorilor. Serviciul calendar și Serviciul de mesaje utilizează o strategie de nereușită.
Strategiile sunt detaliate în tabelul Strategii de continuitate a serviciului și scară a clusterelor dedicate.
Coresidency— Când conectorii partajează un cluster Expressway, resursele disponibile pentru fiecare serviciu sunt semnificativ mai mici în comparație cu clusterul dedicat.
Pot exista, de asemenea, alte servicii bazate pe Expressway pe gazda conectorului, ar fi apelarea business to business (B2B) sau Mobile and Remote Access (MRA). În scenariile limitate în care acest tip de coresidency este acceptat, numerele de scară pe care le documentăm aici sunt constrânse la ceea ce am testat. Dincolo de ceea ce este descris în acest articol, conector gazdă Expressway cluster nu trebuie să fie partajate cu alte servicii; acest lucru nu este acceptat.
Limitări specifice serviciului— De exemplu, Conectorul calendar este destinat în principal utilizatorilor Microsoft Exchange și acceptă un număr limitat de utilizatori Office 365.
Calcule pentru clustere dedicate drumurilor expres
Am stabilit o limită dură a numărului de utilizatori de servicii pe care o autostradă unică dedicată o poate gestiona (un "grup de unul"), pe baza dovezilor pe care le adunăm în teste și încercări.
Dimensiune nod autostradă | Scară serviciu calendar hibrid | Scala serviciului de mesaje hibride |
---|---|---|
1. Mic | 5000 | 5000 |
2. Mediu | 10000 | 6500 |
3. mare | 15000 | 15000 |
Folosim algoritmii de continuitate a serviciului pentru a extrapola numerele cu un singur nod la mai multe clustere de noduri, așa se explică în tabelul următor. Dacă doriți rezultatele fără explicații, consultați:
compara |
Serviciu Hybrid Calendar |
Hybrid Message Service |
---|---|---|
1. ˇ°Modelˇ± |
Model failover |
Model failover |
2. Descriere |
Atribuim fiecare utilizator unui nod din cluster. Acest lucru răspândește utilizatorii pe toate nodurile. Dacă un nod se duce în jos, recreăm atribuirile utilizatorului din acel nod de pe celelalte noduri. Când nodul revine, reechilibrăm atribuirile utilizatorilor în toate nodurile active. |
Atribuim fiecare utilizator unui nod din cluster. Acest lucru răspândește utilizatorii pe toate nodurile. Dacă un nod se duce în jos, recreăm atribuirile utilizatorului din acel nod de pe celelalte noduri. Când nodul revine, reechilibrăm atribuirile utilizatorilor în toate nodurile active. |
3. formulă |
UcalN= (N-1) * Ucal1 |
UmsgN= (N-1) * Umsg1 |
4. Definiții |
Unde: UcalN este clusterul de capacitate N pentru utilizatorii de servicii de calendar N este numărul de noduri Ucal1 este capacitatea de nod unic pentru utilizatorii de servicii calendar |
Unde: UmsgN este clusterul de capacitate N pentru utilizatorii serviciului de mesaje N este numărul de noduri Umsg1 este capacitatea de nod unic pentru utilizatorii serviciului de mesaje |
5. Note |
Dacă N=1, nu există nicio nereușită. Failover este automat și obligatoriu dacă N>1. Dacă N=2, capacitatea este aceeași ca și N=1, cu o mai bună continuitate a serviciului. Scala beneficiază de N> =3 sau utilizând o dimensiune mai mare a nodului. |
Dacă N=1, nu există nicio nereușită. Failover este automat și obligatoriu dacă N>1. Dacă N=2, capacitatea este aceeași ca și N=1, cu o mai bună continuitate a serviciului. Scala beneficiază de N> =3 sau utilizând o dimensiune mai mare a nodului. |
Calcule pentru clusterele de drumuri expres partajate
Algoritmul nostru presupune că conectorii coresident împărtășesc proporțional resursele unui singur nod. Acest algoritm stabilește în mod conservator limita pentru fiecare tip de utilizator de pe nod.
De exemplu, următorul tabel afișează numărul maxim de utilizatori pentru toate cazurile dedicate și cazurile de coresidență pe o singură autostradă medie.
Scopul drumului expres | Utilizatori serviciu calendar | Utilizatori serviciu mesaj |
---|---|---|
Dedicat serviciului Calendar | 10,000 |
— |
Dedicat serviciului de mesaje |
— |
6,500 |
Partajat de Serviciul calendar și Serviciul de mesaje |
4,000 |
4,000 |
Partajat de Calendar, Apel și Servicii de mesaje |
2,300 |
2,300 |
Nu enumerăm exhaustiv toate stările coresidency pentru toate dimensiunile clusterului. În schimb, aveți posibilitatea să monitorizați capacitatea implementării serviciilor hibride existentesau să utilizați calculatorul pentru a planifica o nouă implementare.
Calculatorul vă permite să alegeți conectori, dimensiunea nodului și numărul de noduri, astfel încât să puteți modela implementarea. Restul acestei secțiuni explică modul în care calculează numerele de utilizator din model. |
La fel am făcut pentru Expressway dedicat, extrapolăm algoritmul pentru expressways partajate pentru a determina numerele de utilizator pentru mai multe noduri. Diferența față de cazurile dedicate este că aplicăm calculul adecvat al continuității serviciului pentru a obține scala de utilizator pentru un anumit serviciu din cluster. Nu putem calcula scala de utilizator pentru cluster, deoarece clusterul găzduiește strategii concurente, bazate pe utilizator, continuitatea serviciului.
Scopul clusterului |
Utilizatori de servicii de mesaje hibride pentru 1,2 și 3 noduri |
||
---|---|---|---|
Dedicat serviciului de mesaje |
6,500 |
6,500 |
13,000 |
Factori suplimentari care contribuie
Pot exista cereri concurente privind resursele clusterului care vor scădea capacitatea de utilizator. Acestea sunt exemplele cunoscute:
Serviciu calendar— Gazda conector poate deservi, de asemenea, utilizatorii O365. Numerele și calculele afișate aici presupun că numai infrastructura Exchange locală furnizează Serviciul calendar. Pentru mai multe informații despre Serviciul calendar "hibrid", avem câteva numere și grafice în secțiunea Serviciu calendar din acest articol.
Procesarea apelurilor— Gazda conectorului poate procesa, de asemenea, semnalizarea apelurilor și suportul media. Aceasta este în mod eficient o integrare "Business to business" între organizația dvs. Acest lucru reduce capacitatea descrisă în Coresidency cu Alte soluții expressway.
Aveți posibilitatea să utilizați Control Hub pentru a vizualiza o valoare procentuală a capacității curente de utilizator a fiecăreia dintre resursele drumului expres Servicii hibride. O bară de culoare indică dacă capacitatea este în limite acceptabile. Această vizualizare vă permite să evaluați starea de sănătate a implementărilor de servicii hibride și vă ghidează cu privire la momentul în care aveți nevoie de mai multe drumuri expres.
Verde— Drumurile expres se încadrează în limite acceptabile de capacitate. (1%–60%)
Chihlimbar — Aveți suficiente drumuri expres, dar sunteți aproape de a atinge limitele de capacitate. (61%–90%)
Roșu- Nu aveți suficiente drumuri expres și trebuie să adăugați mai multe. (91% și mai mult)
Dacă drumurile expres sunt într-o grupă de resurse, indicatorul de capacitate apare sub o vizualizare filtrată a clusterelor din grupul de resurse.
Pentru implementări fără grupuri de resurse (implicit):
Pentru implementări cu grupuri de resurse:
Lucruri de reținut
Capacitatea clusterului variază în funcție de dimensiunea nodului, numărul de noduri din clusterul Expressway, câte servicii se execută pe cluster și disponibilitatea ridicată sau strategia de failover. Pentru mai multe informații, consultați secțiunile individuale scala Calendar și Mesaj.
Coresidency reduce scala de utilizare pentru serviciile existente; algoritmul de capacitate presupune că fiecare utilizator utilizează toate serviciile.
Vă recomandăm coresidency atunci când încercați mai multe servicii sau dacă aveți o implementare la scară mică. Pentru servicii în producție sau pentru implementări la scară largă, vă recomandăm să executați diferitele servicii hibride pe clustere Expressway dedicate.
Ce trebuie să faceți în continuare
Pentru a adăuga mai multe drumuri expres pentru servicii hibride, utilizați pașii ghidului de implementare pentru înregistrarea gazdelor conector în cloud și adăugarea acestora la clusterele existente:
Capacitatea unui cluster Expressway pentru utilizatorii serviciului calendar hibrid depinde în primul rând de dimensiunea și numărul de noduri din cluster și de strategia de continuitate a serviciului. Următorul tabel afișează capacitatea totală maximă de utilizator pe care clusterul o poate gestiona pe măsură ce măriți nodurile (sau dimensiunea OVA nodului) pe un singur cluster dedicat.
Într-un mediu Exchange hibrid cu utilizatorii Office 365, există o limită de 1.000 de utilizatori Office 365 per cluster, independent de numărul sau dimensiunea nodurilor clusterului. Serviciul din cadrul norului este metoda preferată de gestionare a utilizatorilor Office 365. Vă recomandăm să găzduiți temporar numai utilizatorii Office 365 pe Expressway. Această limitare derivă din interacțiunea cu serviciul cloud Microsoft și nu din amploarea implementării Expressway local. De exemplu, dacă aveți un singur nod Expressway mic, capacitatea este limitată la 1.000 de utilizatori Office 365 și 4.000 de utilizatori Microsoft Exchange. Dacă aveți un grup de 6 noduri mici, capacitatea este limitată la 1.000 de utilizatori Office 365 plus 24.000 de utilizatori Microsoft Exchange. |
Dimensiune nod autostradă |
1 sau 2 noduri* |
3 Noduri |
4 Noduri |
5 Noduri |
6 Noduri |
---|---|---|---|---|---|
1. Mic |
5K |
10.000 |
15K |
20K |
25K |
2. Mediu |
10.000 |
20K |
30K |
40K |
50K |
3. mare |
15K |
30K |
45K |
60K |
75K |
* Rețineți că capacitatea utilizatorului este aceeași pentru un cluster de un nod și pentru un cluster de două noduri. Acest lucru se datorează faptului că Serviciul Calendar utilizează fail-over pentru a îmbunătăți continuitatea serviciului. Toți utilizatorii sunt atribuite la un nod atunci când există două noduri în cluster; celălalt nod este o copie de rezervă redundantă. Consultați Planificarea capacității clusterului de autostradă pentru utilizatorii de servicii hibride pentru o explicație detaliată.
Atribuirea utilizatorilor între gazde și clustere
În mod implicit, Serviciul calendar hibrid atribuie și distribuie automat utilizatorii în mod egal în toți conectorii de calendar dintr-un cluster. Asocierea este dinamică în funcție de disponibilitate, iar administratorul nu are niciun control asupra nodului căruia îi este atribuit un anumit utilizator.
În cazurile în care o organizație are mai mult de un cluster, distribuția utilizatorului se bazează pe mai mulți factori, inclusiv disponibilitatea clusterului, atribuirea curentă (pentru a reduce flapping în timpul recuperării eșecului) și o ordine de sortare bazată pe cea mai mare preferință de cluster. Administratorul are, de asemenea, capacitatea de a atribui un utilizator sau un grup de utilizatori unui grup de resurse. Grupurile de resurse sunt specifice clusterului, astfel încât acestea permit administratorilor să constrângă atribuirea anumitor seturi de utilizatori la un anumit cluster.
Cu această înțelegere de bază a atribuirii utilizatorului și luând în considerare cerințele preliminare Expressway Calendar Connector, un administrator poate implementa capacitatea corespunzătoare la scară pentru organizația lor. Să ne uităm la o organizație exemplu de 126.000 de utilizatori care urmează să fie activat pentru Serviciul calendar hibrid, având în vedere următorii parametri:
Clustere de drumuri expres de 6 noduri folosind șablonul OVA mare (limita de 15.000 de utilizatori pe nod)
Nu sunt necesare grupuri de resurse
Formula de capacitate pentru un singur cluster, UcalN= (N-1) * Ucal1 unde N=6 și Ucal1=15.000 (folosind șablonul OVA mare) produce maximum 75.000 de utilizatori. Cu 126.000 de utilizatori totali în implementarea serviciului de calendar, sunt necesare mai multe clustere gazdă Calendar Connector. Utilizatorii ar fi distribuiți în mod egal, după se arată în figura următoare:
Serviciul calendar hibrid adaugă mai întâi utilizatorii la clusterul A până când clusterul atinge capacitatea de 75.000 de utilizatori, apoi atribuie utilizatorii rămași clusterului B. Utilizatorii sunt distribuiți aleatoriu și în mod egal în toate nodurile din cluster. Acest exemplu afișează o distribuție egală a nodurilor gazdă Calendar Connector (în fiecare dintre cele două clustere) între centrele de date RTP & PDX. Fiecare nod utilizează același șablon OVA și urmează liniile directoare de disponibilitate ridicată Expressway. Conectorul calendar utilizează logica de grupare Expressway într-un model de redundanță 5+1 pentru a permite scenarii de disponibilitate ridicată.
Cu toți utilizatorii atribuiți unui conector calendar, să examinăm acum ce se întâmplă atunci când există o eroare într-un cluster. Figura următoare arată o singură eroare de nod. Utilizatorii care au fost atribuite nodului nereușit, 5A în clusterul A, nu au reușit acum peste nodurile rămase în acel cluster. O capacitate de nod unic permite până la 15.000 de utilizatori și fiecare nod rămas în clusterul A adaugă 2500 de utilizatori care au fost atribuiți inițial pe nodul 5A. Nu există nicio modificare sau impact asupra clusterului B sau asupra utilizatorilor atribuiți clusterului B.
Clusterul A este încă la capacitate maximă, iar fiecare dintre nodurile operaționale din cluster este acum la capacitate maximă, 15.000 de utilizatori / nod. De aceea, dacă un alt nod în clusterul A devine indisponibil, ar fi nodul 4A în figura următoare, clusterul B va fi acum responsabil pentru ridicarea încărcării utilizator suplimentare. Cei 15.000 de utilizatori din nodul 4A sunt acum reatribuiți clusterului B și distribuiți în mod egal pe toate nodurile din clusterul B.
Când nodurile 4A și 5A recupera, utilizatorii de pe clusterul A vor fi redistribuite peste nodurile din cluster. Utilizatorii care nu au reușit să cluster B rămân pe clusterul B în această fază de recuperare pentru a evita atribuirile inutile de utilizator între clustere, așa se arată în figura următoare.
Un element cheie de care trebuie să fiți conștienți în planificarea unei implementări de serviciu calendar hibrid la scară largă este înțelegerea impactului unei erori dacă ar apărea în implementare. Dacă folosim aceeași implementare de 126.000 de utilizatori, dar se întâmplă să pierdem un întreg centru de date, există un potențial pentru utilizatorii care nu sunt atribuiți unui nod Conector calendar. Pentru a preveni o întrerupere a serviciului în acest tip de scenariu, clientul ar avea nevoie de un al treilea cluster pentru a redistribui și gestiona utilizatorii afectați.
Capacitatea unui cluster Expressway de a deservi utilizatorii Serviciului de mesaje hibride depinde de dimensiunea nodurilor expressway constitutive, de numărul de noduri din cluster și de strategia de continuitate a serviciului.
Următorul tabel afișează numărul maxim de utilizatori pe o singură autostradă utilizată pentru Serviciul de mesajehibride .
Autostradă mică |
Autostradă medie |
Autostradă mare |
---|---|---|
5.000 de utilizatori |
6.500 utilizatori |
15.000 de utilizatori |
Numerele de utilizator sunt aceleași pentru un cluster de un nod și pentru un cluster de două noduri. Acest lucru se datorează faptului că Serviciul de mesaje utilizează failover pentru a îmbunătăți continuitatea serviciului. Utilizatorii sunt distribuite uniform peste mai multe noduri în cluster: dacă un nod nu reușește, utilizatorii nodului respectiv sunt atribuiți celorlalte noduri. |
Acest subiect se referă la partajarea unei gazde de conectori Expressway între conectorii pentru mai multe servicii hibride, inclusiv Serviciul calendar și Serviciul de mesaje. Gazda conectorului nu este partajată cu alte soluții bazate pe Expressway, ar fi MRA și B2B.
Capacitatea clusterului gazdă conector depinde de dimensiunea nodurilor expressway constitutive, numărul de noduri, conectorii care se execută pe cluster și strategia de continuitate a serviciului. Consultați Planificarea capacității clusterului de autostradă pentru utilizatorii de servicii hibride pentru o explicație detaliată a acestor factori.
Există, de asemenea, un calculator pentru a modela diferite clustere gazdă conector și a vedea câți utilizatori ai fiecărui serviciu clusterul propus poate sprijini.
În general, vă recomandăm coresidency numai pentru implementări de dimensiuni mai mici de până la două noduri. Dacă implementarea depășește capacitatea unei perechi de noduri, ar trebui să mutați conectori la clustere Expressway care sunt dedicate fiecărui serviciu hibrid specific.
Exemplu: Scala gazdă conector cu trei conectori Coresident
Următorul tabel arată un exemplu de scară și coresidență. Acesta oferă numărul maxim de utilizatori pe cluster , pentru fiecareserviciu, cu specificații diferite ale clusterului gazdă conector. Clusterul este partajat între Serviciul calendar hibrid (utilizând Exchange local), Serviciul de apelurihibride și Serviciul de mesaje hibride.
Serviciu |
Două noduri mici |
Două noduri medii |
Două noduri mari |
---|---|---|---|
Utilizatorii Serviciului calendar |
1,300 |
2,300 |
3,000 |
Utilizatorii Serviciului de mesaje |
1,300 |
2,300 |
3,000 |
Introducere
Acest subiect se referă la partajarea unui expressway gazdă conector cu alte soluții bazate pe Expressway. Când alegeți să găzduiți conectori pe un drum expres pe care îl utilizați în alte scopuri, se aplică următoarele avertismente importante:
Nu putem accepta modelul de scalabilitate care se aplică unei gazde dedicate a conectorului Expressway. Numerele de utilizator pe care le obțineți din citirea celorlalte subiecte din acest articol sau din utilizarea calculatorului nu se aplică atunci când gazda conector este partajată cu alte servicii Expressway.
Combinațiile de servicii bazate pe Expressway și conectori de servicii hibride descrise în acest articol și numerele de utilizator asociate, sunt singurele scenarii acceptate. Nu am testat alte scenarii și nu vă puteți aștepta ca acestea să funcționeze în mediul dvs.
Serviciu calendar bazat pe autostradă cu conector de apel și traversare serviciu de apel
În acest scenariu, un grup de două noduri Expressway cluster hybrid calendar conectori service. Clusterul este de a face, de asemenea, traversal apel pentru alte soluții de apelare Cisco (sip semnalizare și mass-media).
Tabelul afișează diferitele medii de calendar pe care le puteți utiliza cu conectorul bazat pe Expressway. Conectorul Calendar bazat pe Expressway nu este acceptat pe clustere cu mai mult de două noduri. Utilizați conectorul din cadrul norului pentru o scară mai mare cu Office 365 (consultați Scala de servicii calendar).
Serviciu |
Două cluster nod mic |
Cluster cu două noduri medii |
Două cluster nod mare |
|
---|---|---|---|---|
Serviciu Calendar |
Schimb local |
500 utilizatori |
1.000 de utilizatori |
1.000 de utilizatori |
† Office 365 |
500 utilizatori |
1.000 de utilizatori |
1.000 de utilizatori |
|
Exchange local și Office 365 (implementări Hybrid Exchange) |
Max 500 de utilizatori pentru ambele |
Max 1.000 de utilizatori pentru ambele |
Max 1.000 de utilizatori pentru ambele |
|
Apelare Traversal |
200 de sesiuni audio 100 de sesiuni video |
200 de sesiuni audio 100 de sesiuni video |
1.000 de sesiuni audio 500 de sesiuni video |
† Pentru a evita această limitare a scalei, vă recomandăm să utilizați Serviciul calendar din cadrul norului în locul conectorului local. Pentru Serviciul calendar hibrid bazat pe Expressway , limitarea capacității de utilizator Office 365 la 1.000 per cluster este independentă de dimensiunea sau numărul de noduri al clusterului; această limitare derivă din interacțiunea cu serviciul cloud Microsoft și nu din amploarea implementării Expressway locale.
Calendar cu acces mobil și la distanță
În acest scenariu, un cluster MRA de unul sau două SMS-uri mici Expressway găzduiește Conector calendar. Acest scenariu presupune clusterul este utilizat numai pentru MRA și cei doi conectori. Clusterul este limitat la unul sau două noduri mici.
Scopul drumului expres |
Grup de un mic drum expres-C |
Cluster de două Mici Expressway-Cs |
---|---|---|
Utilizatorii serviciului calendar (conector local la Exchange) |
500 utilizatori |
500 utilizatori |
Utilizatori de acces mobil și la distanță |
100 |
100 |