Gebruik dit artikel om uw connectorcapaciteit voor implementaties voor Webex hybride service te plannen en inzicht te krijgen in de aanbevelingen voor schaalbaarheid. Voor beide toegewezen en core-sident connectorimplementaties vindt u het maximale aantal ondersteunde gebruikers voor connectorclusters, de bepalende factoren die de ondersteunde gebruikerslimieten bepalen en hoe u Control Hub kunt gebruiken om te evalueren of u meer Expressways wilt toevoegen.
De hybride gespreksservice op de Call Connector-architectuur is niet langer ondersteund. Daaromwordt de service niet meer officieel ondersteund. Gespreksconnector mag niet worden beschouwd voor toekomstige Expressway van de capaciteitsplanning voor hybride services. |
Dit artikel bevat geen betrekking op de capaciteitsplanning voor de hybride agendaservice Cisco TMS-integratie met Office 365 of integratie van Cisco TMS met Google Agenda. Zie de Implementatiehandleiding voor meer informatie over capaciteit voor Cisco Webex-service voor hybride agenda's. |
We bieden u dit artikel om uw vragen over uw capaciteitsplanning uit te leggen en uit te leggen hoe we de gebruikersschaal berekenen. Als u een scenario wilt modelen, probeert u de Rekenhulp voor de capaciteit van hybrideservices.
Overwegingen bij plannen
Houd bij Expressway plannen van de capaciteit voor gebruikers van uw hybride services rekening met de volgende vragen:
Welke hybride services hebt u nodig?
De Expressway kan connectoren hosten voor de hybride gespreksservice, agendaservice en hybride gespreksservice.
Hoeveel gebruikers hebt u voor elke service?
Hoe meer gebruikers u voor elke service hebt, des te waarschijnlijker is het dat u clusters Expressway services wilt aanstellen. Voor kleinere groepen is het uitvoeren van meerdere connectoren op een gedeeld cluster (coresidency) een geldige keuze.
Gaan uw behoeften veranderen?
Mogelijk wilt u klein beginnen, met één Expressway cluster dat service levert aan een groep van early adopters in uw organisatie, en wilt u groei plannen voor een toekomstige implementatie. U kunt migreren van een gedeeld model naar een speciaal model of uw bestaande cluster opschalen om aan uw veranderende vereisten te voldoen.
Factoren die bijdragen
We definiëren de clustercapaciteit aan de volgende variabelen:
De grootte van het knooppunt —Elke Expressway virtuele machine heeft een 'VM-grootte' die tijdens de installatietijd wordt bepaald door de resources die zijntoegewezen aan de VM. In de Expressway installatiehandleidingen worden deze vereisten beschreven. Als u al een account Expressway, kunt u de VM-grootte vinden via de pagina Status > Systeeminformatie van de delen.
Aantalknooppunten: een Expressway cluster kan tussen één en zes knooppunten hebben. Deze moeten dezelfde knooppuntgrootte hebben en dezelfde softwareversie gebruiken.
Strategie voorservicecontinuïteit: de services gebruiken strategieën om voor continue service te zorgen voor gebruikers. agendaservice- en berichtenservice gebruiken een failover-strategie.
De strategieën worden beschreven in de tabel Strategieën voor servicecontinuïteit en Schaal van speciale clusters.
Core-sidency: wanneer de connectoren een cluster Expressway delen, worden de resources die beschikbaar zijn voor elke service aanzienlijk lager ten opzichte vanhet specifieke cluster.
Er zijn mogelijk ook andere op basis Expressway op basis van services op uw connectorhost, zoals zakelijk bellen (B2B) of Mobile and Remote Access (MRA). In de beperkte scenario's waarin dit type coresidency wordt ondersteund, worden de schaalnummers die we hier documenteren beperkt tot wat we hebben getest. Naast de beschrijving in dit artikel, mag de connectorhost Expressway cluster niet worden gedeeld met andere services; dit wordt niet ondersteund.
Service-specifieke beperkingen : de Calendar Connector is bijvoorbeeld primair bedoeld voor Microsoft Exchange-gebruikers en ondersteunt een beperkt aantalOffice 365-gebruikers.
Berekeningen voor speciale Expressway clusters
We stellen een vaste limiet in voor het aantal servicegebruikers dat door één speciaal Expressway kan worden beheert (een 'cluster van één'), op basis van bewijs dat wij verzamelen met tests en proefperioden.
Expressway grootte van knooppunt | Hybride agendaservice schaal | Schaal hybride berichtenservice |
---|---|---|
1. Klein | 5000 | 5000 |
2. Gemiddeld | 10000 | 6500 |
3. Groot | 15000 | 15000 |
We gebruiken de algoritmen voor servicecontinuïteit om de aantallen van enkele knooppunt te extrapoleren om knooppuntclusters te voudigen, zoals uitgelegd in de volgende tabel. Als u de resultaten zonder uitleg wilt, gaat u naar:
Vergelijken |
Service voor hybride agenda's |
Hybride chatservice |
---|---|---|
1. Model |
Failover-model |
Failover-model |
2. Beschrijving |
We wijzen elke gebruiker toe aan één knooppunt in de cluster. Dit is het de gebruikers van alle knooppunten. Als een knooppunt uitgaat, maken we de gebruikerstoewijzingen van dat knooppunt opnieuw op de andere knooppunten. Wanneer het knooppunt weer wordt weer actief, maken we opnieuw toewijzingen aan gebruikers binnen alle actieve knooppunten. |
We wijzen elke gebruiker toe aan één knooppunt in de cluster. Dit is het de gebruikers van alle knooppunten. Als een knooppunt uitgaat, maken we de gebruikerstoewijzingen van dat knooppunt opnieuw op de andere knooppunten. Wanneer het knooppunt weer wordt weer actief, maken we opnieuw toewijzingen aan gebruikers binnen alle actieve knooppunten. |
3. Formule |
UcalN= (N-1) * Ucal1 |
UmsgN= (N-1) * Umsg1 |
4. Definities |
Waar: UcalN is het cluster van N capaciteit voor agendaservice gebruikers N is het aantal knooppunts Ucal1 is de capaciteit van één knooppunt voor agendaservice gebruikers |
Waar: UmsgN is het cluster van N capaciteit voor gebruikers van de berichtenservice N is het aantal knooppunts Umsg1 is de capaciteit van één knooppunt voor gebruikers van de berichtenservice |
5. Notities |
Als N=1, is er geen failover. Failover is automatisch en verplicht als N>1. Als N=2 is de capaciteit hetzelfde als wanneer N= 1, met een betere continuïteit van de service. Voordelen schalen van N>=3 of door een groter knooppunt te gebruiken. |
Als N=1, is er geen failover. Failover is automatisch en verplicht als N>1. Als N=2 is de capaciteit hetzelfde als wanneer N= 1, met een betere continuïteit van de service. Voordelen schalen van N>=3 of door een groter knooppunt te gebruiken. |
Berekeningen voor gedeelde Expressway clusters
Ons algoritme gaat ervan uit dat de kernen van connectoren naar verhouding de resources van één knooppunt delen. Dit algoritme bepaalt de limiet voor elk type gebruiker van het knooppunt.
De volgende tabel bevat bijvoorbeeld het maximale aantal gebruikers voor alle speciale gevallen en de core-sidency-cases op een enkel, gemiddeld Expressway.
Expressway doel | agendaservice gebruiken | Gebruikers berichtenservice |
---|---|---|
Toegewezen aan agendaservice | 10,000 |
— |
Toegewezen aan berichtenservice |
— |
6,500 |
Gedeeld door agendaservice- en berichtenservice |
4,000 |
4,000 |
Gedeeld door agenda-, gespreks- en berichtenservices |
2,300 |
2,300 |
We zullen niet alle coresidency-staten opsommen voor alle clustergroottes. In plaats daarvan kunt u de capaciteit van uw bestaande implementatie van hybride services controleren, of de rekenhulp gebruiken om een nieuwe implementatie te plannen.
Met de rekenhulp kunt u connectoren, de grootte van het knooppunt en het aantal knooppunt kiezen, zodat u uw implementatie kunt modelen. In het gedeelte rest van dit gedeelte wordt uitgelegd hoe het de gebruikersaantallen van uw model berekent. |
Net als voor de speciale Expressway, extrapoleren we het algoritme voor gedeelde Expressways om gebruikersnummers voor meerdere knooppunten te bepalen. Het verschil tussen de speciale gevallen is dat we de juiste berekening van servicecontinuïteit toepassen om de gebruikersschaal te krijgen voor een specifieke service in het cluster. We kunnen de gebruikersschaal niet berekenen voor het cluster omdat de clusterhosts concurrerende strategieën voor servicecontinuïteit, op basis van gebruikers, gebruiken.
Het doel van het cluster |
Gebruikers van hybride berichtenservice voor 1, 2 en 3 knooppunten |
||
---|---|---|---|
Toegewezen aan berichtenservice |
6,500 |
6,500 |
13,000 |
Aanvullende factoren die bijdragen
Er kunnen concurrerende vragen zijn in de resources van de clusters, wat de gebruikerscapaciteit vermindert. Dit zijn de bekende voorbeelden:
agendaservice:de connectorhost kan ook de O365-gebruikersservice gebruiken. De cijfers en berekeningen die hier worden weergegeven gaan ervan uit dat alleen de lokale Exchange-infrastructuur agendaservice. Voor meer informatie over de hybride agendaservice, hebben we een aantal cijfers en grafieken in het agendaservice van dit artikel.
Verwerken vangesprek: de connectorhost kan ook gesprekssignalering en media verwerken. Dit is in eerste plaats een 'business to business'-integratie tussen uw organisatie en de Webex-cloud. Hierdoor wordt de capaciteit beperkt zoals beschreven in Co-ncy met Andere Expressway-oplossingen.
U kunt Control Hub gebruiken om een percentage weer te geven van de huidige gebruikerscapaciteit van elk van uw hybride services Expressway resources. Een kleurbalk geeft aan of de capaciteit binnen aanvaardbare limieten valt. Met deze weergave kunt u de status van uw implementaties van hybride service evalueren en u wordt op de weg geleid wanneer u meer Expressways nodig hebt.
Groen:uw Expressways zijn binnen acceptabele capaciteitslimieten. (1%–60%)
Oranje:u hebt genoeg Expressways maar bereikt bijna uw capaciteitslimieten. (61%–90%)
Rood:u hebt niet genoeg Expressways en moet er meer toevoegen. (91% en hoger)
Als uw Expressways zich in een resourcegroep zitten, verschijnt de indicator van capaciteit onder een gefilterde weergave van de clusters in de resourcegroep.
Bij implementaties zonder resourcegroepen (standaard):
Bij implementaties met resourcegroepen:
Dingen om rekening mee te houden
De clustercapaciteit varieert, afhankelijk van de grootte van het knooppunt, het aantal knooppunten in het Expressway-cluster, het aantal uitgevoerd op het cluster en de strategie van hoge beschikbaarheid of failover. Zie de afzonderlijke gedeelten agenda- en berichtschaal voor meer informatie.
Co-co-ncy vermindert de gebruikersschaal voor bestaande services; gaat het algoritme van de capaciteit ervan uit dat elke gebruiker alle services gebruikt.
We raden u aan meerdere services te gebruiken of als u een kleine implementatie hebt. Voor services in productie of voor grote implementaties raden we u aan de verschillende hybride services uit te voeren op speciale Expressway clusters.
De volgende stap
Als u meer Expressways voor hybride services wilt toevoegen, gebruikt u de stappen uit de implementatiehandleiding om connectorhosts in de cloud te registreren en toe te voegen aan bestaande clusters:
De Expressway van een cluster voor gebruikers van hybride agendaservice is voornamelijk afhankelijk van de grootte en het aantal knooppunten in het cluster. Daarnaast is de strategie voor servicecontinuïteit. De volgende tabel bevat de maximale totale gebruikerscapaciteit die het cluster kan verwerken wanneer u de knooppunten (of de OVA-grootte van het knooppunt) in één speciaal cluster verhoogt.
In een hybride Exchange-omgeving met Office 365-gebruikers is er een limiet van 1000 Office 365-gebruikers per cluster, onafhankelijk van het aantal knooppunt of de grootte van het cluster. De cloudgebaseerde service is de aanbevolen methode voor het verwerken van Office 365-gebruikers. We raden u met veel meer aan om Office 365-gebruikers tijdelijk te hosten Expressway. Deze beperking is afgeleid van interactie met de Microsoft-cloudservice en niet van de schaal van de Expressway implementatie. Als u bijvoorbeeld één klein Expressway-knooppunt hebt, is uw capaciteit beperkt tot 1.000 Office 365-gebruikers en 4000 Microsoft Exchange-gebruikers. Als u een cluster van 6 kleine knooppunten hebt, is uw capaciteit beperkt tot 1.000 Office 365-gebruikers plus 24.000 Microsoft Exchange-gebruikers. |
Expressway grootte van knooppunt |
1 of 2 knooppunten* |
3 knooppunten |
4 knooppunten |
5 knooppunten |
6 knooppunten |
---|---|---|---|---|---|
1. Klein |
5K |
10K |
15K |
20K |
25K |
2. Gemiddeld |
10K |
20K |
30K |
40K |
50K |
3. Groot |
15K |
30K |
45K |
60K |
75K |
* De gebruikerscapaciteit is gelijk voor een cluster van één knooppunt en voor een cluster van twee knooppunten. Dit komt doordat agendaservice fail-over gebruikt om de continuïteit van de service te verbeteren. Als er twee knooppunten in een cluster zijn, worden alle gebruikers toegewezen aan één knooppunt; het andere knooppunt is een redundante back-up. Zie Planning Expressway clustercapaciteit voor gebruikers van hybride services voor een uitgebreide uitleg.
Gebruikerstoewijzingen onder hosts en clusters
Standaard worden gebruikers door de agendaservice automatisch toegewezen en verdeeld over alle Agendaconnectors in een cluster. De toewijzing is dynamisch op basis van beschikbaarheid en de beheerder heeft geen controle over het specifieke knooppunt waaraan een individuele gebruiker is toegewezen.
In gevallen waarbij een organisatie meerdere clusters heeft, is de distributie van gebruikers gebaseerd op meerdere factoren, waaronder clusterbeschikbaarheid, huidige toewijzing (om het afslappen tijdens het terugvallen van de storing te verminderen) en een sorteerorder op basis van de hoogste clustervoorkeur. De beheerder heeft ook de mogelijkheid om een gebruiker of groep gebruikers toe te wijzen aan een resourcegroep. Resourcegroepen zijn cluster specifiek, dus beheerders kunnen toewijzing van bepaalde sets gebruikers beperken tot een specifiek cluster.
Omdat een beheerder goed inzicht heeft in gebruikerstoewijzing en rekening houdt met de vereisten Expressway Calendar Connector, kan een beheerder de juiste capaciteit op schaal voor de organisatie implementeren. Laten we een voorbeeld organisatie bekijken van 126.000 gebruikers die moeten worden ingeschakeld voor de hybride agendaservice, gezien de volgende parameters:
Expressway van 6 knooppunten de grote OVA-sjabloon gebruiken (limiet van 15.000 gebruikers per knooppunt)
Geen resourcegroepen vereist
De capaciteits formule voor een enkele cluster, UcalN= (N-1) * Ucal1, waarbij N=6 en Ucal1=15.000 (met behulp van de grote OVA-sjabloon) een maximum van 75.000 gebruikers levert. Met in totaal 126.000 gebruikers in de implementatie van de agendaservice zijn meerdere hostclusters van Calendar Connector vereist. Gebruikers worden even groot verdeeld zoals in de volgende afbeelding wordt getoond:
De hybride agendaservice gebruikers eerst toegevoegd aan cluster A totdat het cluster de capaciteit van 75.000 gebruikers bereikt en de resterende gebruikers vervolgens toewijzen aan cluster B. De gebruikers worden willekeurig en even verdeeld over alle knooppunten binnen het cluster. In dit voorbeeld ziet u een even grote distributie van hostknooppunten van de Calendar Connector (binnen elk van de twee clusters) over datacenters RTP & PDX. Elk knooppunt gebruikt dezelfde OVA-sjabloon en volgt de Expressway richtlijnen voor hogebeschikbaarheid. De Calendar Connector gebruikt de logica Expressway clustering in een 5+1 redundantiemodel om scenario's met hoge beschikbaarheid toe te staan.
Terwijl alle gebruikers zijn toegewezen aan een Calendar Connector, laten we nu bekijken wat er gebeurt wanneer er een fout in een cluster is. In de volgende afbeelding ziet u een storing van één knooppunt. Gebruikers die zijn toegewezen aan het knooppunt met fout 5A in cluster A, hebben nu een fout naar de resterende knooppunten in dat cluster. Met een capaciteit voor één knooppunt kunnen maximaal 15.000 gebruikers en elk knooppunt resterend in cluster A 2500 gebruikers toegevoegd die oorspronkelijk aan knooppunt 5A zijn toegewezen. Er zijn geen gevolgen of wijziging voor cluster B of voor de gebruikers die zijn toegewezen aan cluster B.
Cluster A heeft nog steeds de maximale capaciteit en elke operationele knooppunt in het cluster heeft nu de maximale capaciteit, 15.000 gebruikers/knooppunt. Als een ander knooppunt in cluster A onbeschikbaar wordt, zoals knooppunt 4A in de volgende afbeelding, wordt cluster B nu verantwoordelijk voor het ophalen van de extra gebruikersbelasting. De 15.000 gebruikers van knooppunt 4A worden nu toegewezen aan cluster B en worden even verdeeld over alle knooppunten binnen cluster B.
Wanneer knooppunten 4A en 5A worden hersteld, worden de gebruikers in cluster A opnieuw verdeeld over de knooppunten in het cluster. De gebruikers die op cluster B zijn uitgevallen, blijven in cluster B tijdens deze herstelfase om onnodige gebruikerstoewijzingen tussen clusters te voorkomen, zoals getoond in de volgende afbeelding.
Een belangrijk item om zich bewust van te zijn bij het plannen van een grootschalige hybride agendaservice implementatie is het effect van een fout als deze zich voordeed in de implementatie. Als we dezelfde implementatie van 126.000 gebruikers gebruiken maar een volledig datacenter verliezen, is er een mogelijk voor gebruikers die niet zijn toegewezen aan een Calendar Connector-knooppunt. Om een storing van de service in dit type scenario te voorkomen, heeft de klant een derde cluster nodig om de beïnvloede gebruikers opnieuw te distribueren en af te handelen.
De capaciteit van een Expressway voor het bedienen van gebruikers van hybride berichtenservice is afhankelijk van de grootte van de samenstellende Expressway-knooppunten, het aantal knooppunten in het cluster, en de strategie voor servicecontinuïteit.
De volgende tabel bevat het maximale aantal gebruikers in één Expressway dat wordt gebruikt voor de hybride berichtenservice.
Kleine Expressway |
Gemiddelde Expressway |
Grote Expressway |
---|---|---|
5.000 gebruikers |
6.500 gebruikers |
15.000 gebruikers |
De gebruikersnummers zijn hetzelfde voor een cluster van één knooppunt en voor een cluster van twee knooppunten. Dit komt doordat de berichtenservice failover gebruikt om de continuïteit van de service te verbeteren. Gebruikers worden gelijk verdeeld over de meerdere knooppunten in het cluster: als één knooppunt mislukt, worden de gebruikers van dat knooppunt toegewezen aan de andere knooppunten. |
Dit onderwerp gaat over het delen van een connectorhost Expressway de connectoren voor meerdere hybride services, agendaservice en de berichtenservice. De connectorhost wordt niet gedeeld met Expressway oplossingen op basis van software, zoals MRA en B2B.
De capaciteit van het cluster van de connectorhost is afhankelijk van de grootte van de samenstellende Expressway-knooppunten, het aantal knooppunten, de connectoren die worden uitgevoerd op het cluster en de strategie voor servicecontinuïteit. Zie Planning Expressway clustercapaciteit voor gebruikers van hybride services voor een uitgebreide uitleg van deze factoren.
Er is ook een rekenhulp voor u om verschillende connectorhostclusters te modeleren en te zien hoeveel gebruikers van elke service die uw voorgestelde cluster kan ondersteunen.
Over het algemeen raden we alleen coresidency aan voor implementaties met een kleinere omvang van maximaal twee knooppunten. Als uw implementatie de capaciteit van een aantal knooppunten overschrijdt, moet u connectors verplaatsen Expressway clusters die aan elke specifieke hybride service zijn toegewezen.
Voorbeeld: Schaal van connectorhost met drie core-sident connectors
In de volgende tabel ziet u een voorbeeld van schaal- en core-sidency. Dit biedt het maximale aantal gebruikers per cluster , voor elke service, met verschillende specificaties van hetconnectorhostcluster. Het cluster wordt gedeeld tussen agendaservice (met uw lokale Exchange), hybride gespreksservice en hybride gespreksservice.
Service |
Twee kleine knooppunten |
Twee gemiddelde knooppunten |
Twee grote knooppunten |
---|---|---|---|
agendaservice gebruiken |
1,300 |
2,300 |
3,000 |
Gebruikers berichtenservice |
1,300 |
2,300 |
3,000 |
Inleiding
In dit onderwerp gaat het over het delen van een connectorhost Expressway op andere Expressway gebaseerde oplossingen. Wanneer u ervoor kiest connectoren te hosten op een Expressway die u voor andere doeleinden gebruikt, gelden de volgende belangrijke waarschuwingen:
We kunnen het schaalbaarheidsmodel dat van toepassing is op een speciaal connectorhost-Expressway. De gebruikersnummers die u afgeleid bent van het lezen van de andere onderwerpen in dit artikel of met behulp van de rekenhulp, zijn niet van toepassing als de connectorhost wordt gedeeld met andere Expressway services.
De combinaties van op ondersteunde Expressway en connectors voor hybride services zoals beschreven in dit artikel en de gekoppelde gebruikersnummers zijn de enige ondersteunde scenario's. We hebben geen andere scenario's getest en u kunt niet verwachten dat deze in uw omgeving werken.
Expressway-gebaseerde agendaservice met Gespreksconnector en gespreksservice-traversal
In dit scenario is er een tweeknooppunt Expressway van hybride clusterconnectoren agendaservice connectors. Het cluster doet ook gespreks-traversal voor andere Cisco-gespreksoplossingen (SIP-signalering en media).
De tabel bevat de verschillende agendaomgevingen die u kunt gebruiken met Expressway op basis van connector. De Expressway op basis van agendaconnector wordt niet ondersteund op clusters met meer dan twee knooppunten. Gebruik de cloudgebaseerde connector voor meer schaal met Office 365 (zie agendaservice schaal).
Service |
Twee kleine knooppuntcluster |
Twee cluster met gemiddeld knooppunt |
Cluster met twee grote knooppunt |
|
---|---|---|---|---|
Agendaservice |
On-premises Exchange |
500 gebruikers |
1000 gebruikers |
1000 gebruikers |
Office 365-† |
500 gebruikers |
1000 gebruikers |
1000 gebruikers |
|
On-premises Exchange en Office 365 (hybride exchange-implementaties) |
Maximaal 500 gebruikers voor beide |
Maximaal 1000 gebruikers voor beide |
Maximaal 1000 gebruikers voor beide |
|
Gespreks-Traversal |
200 audiosessies 100 videosessies |
200 audiosessies 100 videosessies |
1000 audiosessies 500 videosessies |
† u deze beperking op deze schaal te voorkomen, raden we u aan de cloudgebaseerde agendaservice te gebruiken in plaats van de connector op locatie. Voor de hybride Expressway op basis van hybride agendaservice is de beperking van de gebruikerscapaciteit van Office 365 tot 1.000 per cluster onafhankelijk van de grootte van of het aantal clusterknooppunt. Deze beperking is afgeleid van interactie met de Microsoft-cloudservice en niet van de schaal van de implementatie op locatieExpressway.
Agenda met mobiele en Remote Access
In dit scenario wordt een MRA-cluster van één of twee kleine Expressway host de Calendar Connector. In dit scenario wordt aangenomen dat het cluster alleen wordt gebruikt voor MRA en de twee connectors. Het cluster is beperkt tot één of twee kleine knooppunten.
Expressway doel |
Cluster van één Expressway-C |
Cluster van twee Expressway-cs |
---|---|---|
agendaservice gebruikers (connector op locatie met Exchange) |
500 gebruikers |
500 gebruikers |
Mobiele en Remote Access gebruikers |
100 |
100 |