Grazie per il feedback.
Limiti di capacità degli utenti per i servizi ibridi basati su Expressway
Feedback?Il servizio di chiamata ibrido sull'architettura Call Connector è andato fuori uso (EOL), quindi il servizio non è più supportato ufficialmente. Call Connector non deve essere preso in considerazione per la futura pianificazione della capacità delle autostrade per i servizi ibridi.
Questo articolo non riguarda la pianificazione della capacità per l'integrazione di Hybrid Calendar Service con Cisco TMS con Office 365 o l'integrazione di Cisco TMS con Google Calendar. Per informazioni sulla capacità, consultare la Guida all'implementazione di Cisco Webex Hybrid Calendar Service.
Forniamo questo articolo per rispondere alle sue domande sulla pianificazione della capacità e spiegare come calcoliamo la scalabilità degli utenti. Per modellare il suo scenario, provi il calcolatore della capacità di Hybrid Services.
Considerazioni sulla pianificazione
Nel pianificare la capacità di Expressway per la sua popolazione di utenti di Hybrid Services, consideri le seguenti domande:
-
Di quali servizi ibridi ha bisogno?
L'Expressway può ospitare connettori per Hybrid Call Service, Hybrid Calendar Service e Hybrid Message Service.
-
Quanti utenti ha, per ogni servizio?
Più utenti ha per ogni servizio, più è probabile che voglia dedicare i cluster Expressway ai servizi. Per popolazioni più piccole, l'esecuzione di più connettori su un cluster condiviso (coresidency) è una scelta valida.
-
Le sue esigenze cambieranno?
Potrebbe voler iniziare in piccolo, con un cluster Expressway che fornisce servizi a un gruppo di early adopter della sua organizzazione e pianificare la crescita per un'implementazione futura. Può migrare da un modello condiviso a un modello dedicato o scalare il cluster esistente per soddisfare le sue esigenze in evoluzione.
Fattori che contribuiscono
Definiamo la capacità di un cluster in termini delle seguenti variabili:
-
Dimensione del nodo: ogni macchina virtuale Expressway ha una «dimensione della macchina virtuale» determinata al momento dell'installazione dalle risorse assegnate alla macchina virtuale. Le guide all'installazione di Expressway descrivono tali requisiti. Se dispone già di un Expressway, può leggere le dimensioni della VM nella pagina dell'interfaccia Expressway.
-
Numero di nodi: un cluster Expressway può avere da uno a sei nodi. Devono avere le stesse dimensioni dei nodi ed eseguire la stessa versione del software.
-
Strategia di continuità del servizio: i servizi utilizzano strategie per garantire un servizio continuo agli utenti. Calendar Service e Message Service utilizzano una strategia di failover.
Le strategie sono dettagliate nella tabella Strategie di continuità del servizio e scala dei cluster dedicati.
-
Coresidenza: quando i connettori condividono un cluster Expressway, le risorse disponibili per ciascun servizio sono significativamente inferiori rispetto al cluster dedicato.
Potrebbero esserci anche altri servizi basati su Expressway sul suo host del connettore, come le chiamate business to business (B2B) o Mobile and Remote Access (MRA). Negli scenari limitati in cui questo tipo di coresidenza è supportato, i numeri di scala che documentiamo qui sono limitati a quelli che abbiamo testato. Oltre a quanto descritto in questo articolo, il cluster Connector Host Expressway non deve essere condiviso con altri servizi; questo non è supportato.
-
Limitazioni specifiche del servizio: ad esempio, Calendar Connector è destinato principalmente Microsoft Exchange agli utenti e supporta un numero limitato di utenti di Office 365.
Calcoli per cluster autostradali dedicati
Abbiamo fissato un limite rigido al numero di utenti del servizio che una singola autostrada dedicata può gestire (un «cluster di uno»), sulla base delle prove raccolte durante test e prove.
| Dimensione del nodo Expressway | Scala di servizio Hybrid Calendar | Scala ibrida del servizio di messaggistica |
|---|---|---|
| 1. Piccolo | 5000 | 5000 |
| 2. Medio | 10000 | 6500 |
| 3. Grande | 15000 | 15000 |
Utilizziamo gli algoritmi di continuità del servizio per estrapolare i numeri dei singoli nodi in più cluster di nodi, come spiegato nella tabella seguente. Se desidera i risultati senza la spiegazione, veda:
|
Comparare |
Servizio di calendario ibrido |
Servizio di messaggistica ibrido |
|---|---|---|
|
1. modello |
Modello di failover |
Modello di failover |
|
2. Descrizione |
Assegniamo ogni utente a un nodo del cluster. Questo distribuisce gli utenti su tutti i nodi. Se un nodo non funziona, ricreiamo le assegnazioni utente da quel nodo sugli altri nodi. Quando il nodo torna attivo, ribilanciamo le assegnazioni degli utenti su tutti i nodi attivi. |
Assegniamo ogni utente a un nodo del cluster. Questo distribuisce gli utenti su tutti i nodi. Se un nodo non funziona, ricreiamo le assegnazioni utente da quel nodo sugli altri nodi. Quando il nodo torna attivo, ribilanciamo le assegnazioni degli utenti su tutti i nodi attivi. |
|
3. Formula |
U CalN = (N-1) * U cal1 |
U msgN = (N-1) * U msg1 |
|
4. Definizioni |
Dove: U CalN è il cluster di capacità N per gli utenti del servizio di calendario N è il numero di nodi U cal1 è la capacità a nodo singolo per gli utenti di Calendar Service |
Dove: U MsGn è il cluster di capacità N per gli utenti di Message Service N è il numero di nodi U msg1 è la capacità a nodo singolo per gli utenti di Message Service |
|
5. Appunti |
Se N=1, non c'è alcun failover. Il failover è automatico e obbligatorio se N>1. Se N=2, la capacità è la stessa di N=1, con una migliore continuità del servizio. La scala trae vantaggio da N>=3 o utilizzando un nodo di dimensioni maggiori. |
Se N=1, non c'è alcun failover. Il failover è automatico e obbligatorio se N>1. Se N=2, la capacità è la stessa di N=1, con una migliore continuità del servizio. La scala trae vantaggio da N>=3 o utilizzando un nodo di dimensioni maggiori. |
Calcoli per cluster autostradali condivisi
Il nostro algoritmo presuppone che i connettori coresident condividano proporzionalmente le risorse di un singolo nodo. Questo algoritmo imposta in modo conservativo il limite per ogni tipo di utente sul nodo.
Ad esempio, la tabella seguente mostra il numero massimo di utenti per tutti i casi dedicati e i casi di coesidenza su una singola superstrada media.
| Scopo della superstrada | Utenti del servizio Calendar | Utenti del servizio di messaggistica |
|---|---|---|
|
| ||
| Dedicato al servizio di calendario |
10,000 |
— |
|
Dedicato al servizio di messaggistica |
— |
6,500 |
|
Condiviso da Calendar Service e Message Service |
4,000 |
4,000 |
|
Condiviso dai servizi di calendario, chiamate e messaggi |
2,300 |
2,300 |
Non elenchiamo in modo esaustivo tutti gli stati di residenza per tutte le dimensioni dei cluster. Può invece monitorare la capacità della sua distribuzione esistente di Hybrid Services o utilizzare la calcolatrice per pianificare una nuova distribuzione.
La calcolatrice Le consente di scegliere i connettori, la dimensione dei nodi e il numero di nodi, in modo da poter modellare la sua distribuzione. Il resto di questa sezione spiega come calcola i numeri utente in base al suo modello.
Proprio come abbiamo fatto per l'autostrada dedicata, estrapoliamo l'algoritmo per le autostrade condivise per determinare i numeri utente per più nodi. La differenza rispetto ai casi dedicati è che applichiamo il calcolo della continuità del servizio appropriato per ottenere la scalabilità utente per un particolare servizio nel cluster. Non possiamo calcolare la scala utente per il cluster perché il cluster ospita strategie di continuità del servizio concorrenti e basate sugli utenti.
|
Scopo del cluster |
Utenti del servizio di messaggistica ibrido per 1,2 e 3 nodi | ||
|---|---|---|---|
|
Dedicato al servizio di messaggistica |
6,500 |
6,500 |
13,000 |
Fattori contributivi aggiuntivi
Potrebbero esserci richieste concorrenti sulle risorse del cluster che ridurranno la capacità degli utenti. Questi sono gli esempi noti:
Servizio calendario: l'host del connettore può servire anche gli utenti di O365. I numeri e i calcoli mostrati qui presuppongono che solo la sua infrastruttura Exchange locale fornisca il servizio di calendario. Per ulteriori informazioni sul servizio di calendario «ibrido», abbiamo alcuni numeri e grafici nella sezione Servizio di calendario di questo articolo.
Elaborazione delle chiamate: l'host del connettore può anche elaborare la segnalazione delle chiamate e i contenuti multimediali. Si tratta effettivamente di un'integrazione «Business to business» tra la sua organizzazione e il cloud Webex. Ciò riduce la capacità, come descritto in Coordinanza con altre soluzioni autostradali.
Può usare Control Hub per visualizzare un valore percentuale della capacità utente corrente di ciascuna delle sue risorse Hybrid Services Expressway. Una barra colorata indica se la capacità rientra nei limiti accettabili. Questa visualizzazione Le consente di valutare lo stato delle sue implementazioni di servizi ibridi e la guida su quando ha bisogno di più autostrade.
-
Verde: le sue autostrade rientrano nei limiti di capacità accettabili. (1%–60%)
-
Amber — Ha abbastanza autostrade ma sta per raggiungere i limiti di capacità. (61%–90%)
-
Rosso: non ha abbastanza autostrade e deve aggiungerne altre. (91% e oltre)
Se le sue autostrade sono in un gruppo di risorse, l'indicatore di capacità viene visualizzato in una vista filtrata dei cluster del gruppo di risorse.
-
Per le distribuzioni senza gruppi di risorse (impostazione predefinita):
-
Dalla visualizzazione clienti in https://admin.webex.com, vada su , quindi scorra fino alle schede dei servizi ibridi per visualizzare la percentuale di capacità utilizzata sulle risorse Expressway per ciascun servizio.
-
-
Per le distribuzioni con gruppi di risorse:
-
Se il valore della capacità è N/A, scelga un gruppo di risorse da Filtro per esaminare i gruppi di risorse e la capacità.
Il valore si aggiorna per mostrare la percentuale di capacità utilizzata per i cluster in quel gruppo di risorse e la codifica a colori per indicare lo stato.
-
Cose da tenere a mente
-
La capacità del cluster varia in base alla dimensione del nodo, al numero di nodi nel cluster Expressway, al numero di servizi in esecuzione nel cluster e alla strategia di alta disponibilità o failover. Per ulteriori informazioni, consulti le singole sezioni Calendario e Scala messaggi.
-
La coresidenza riduce la scalabilità degli utenti per i servizi esistenti; l'algoritmo di capacità presuppone che ogni utente stia utilizzando tutti i servizi.
Le consigliamo la coresidency quando sta provando più servizi o se ha un'implementazione su piccola scala. Per i servizi in produzione o per le implementazioni su larga scala, Le consigliamo di eseguire i diversi servizi ibridi su cluster Expressway dedicati.
Cosa fare dopo
Per aggiungere altre Expressways for Hybrid Services, utilizza i passaggi della guida all'implementazione per registrare gli host dei connettori nel cloud e aggiungerli ai cluster esistenti:
La capacità di un cluster Expressway di fornire assistenza agli utenti di Hybrid Calendar Service dipende dalla dimensione dei nodi Expressway-C costituenti, dal numero di nodi nel cluster Expressway e dalla strategia di continuità del servizio.
La tabella seguente mostra il numero massimo di utenti su una singola autostrada dedicata ai diversi ambienti Hybrid Calendar.
|
Ambiente del calendario |
Piccola superstrada |
Superstrada media |
Grande superstrada |
|---|---|---|---|
|
Solo Exchange locale |
5.000 utenti |
10.000 utenti |
15.000 utenti |
|
Solo Office 365* |
1.000 utenti |
1.000 utenti |
1.000 utenti |
|
Exchange e Office 365* locali (distribuzioni ibride di Exchange) |
Massimo 1.000 utenti di Office 365 su 5.000 utenti totali |
Massimo 1.000 utenti di Office 365 su 10.000 utenti totali |
Massimo 1.000 utenti di Office 365 su 15.000 utenti totali |
* Per evitare questa limitazione di scala, Le consigliamo di utilizzare il servizio di calendario basato sul cloud anziché il connettore locale. Per il calendario ibrido basato su Expressway, la limitazione della capacità di utenti di Office 365 a 1.000 per cluster è indipendente dalla dimensione o dal numero di nodi del cluster; questa limitazione deriva dall'interazione con il servizio cloud Microsoft e non dalla scala della distribuzione locale di Expressway.
Nota che la capacità utente è la stessa per un cluster di un nodo e per un cluster di due nodi. Questo perché Calendar Service utilizza il failover per migliorare la continuità del servizio. Tutti gli utenti vengono assegnati a un nodo quando ci sono due nodi nel cluster; l'altro nodo è un backup ridondante. Vedere Planning Expressway Cluster Capacity for Hybrid Services Users per una spiegazione dettagliata.
La capacità di un cluster Expressway per gli utenti di Hybrid Calendar Service dipende principalmente dalla dimensione e dal numero di nodi nel cluster e dalla strategia di continuità del servizio. La tabella seguente mostra la capacità utente totale massima che il cluster può gestire man mano che Lei aumenta i nodi (o la dimensione OVA del nodo) su un singolo cluster dedicato.
In un ambiente Exchange ibrido con utenti di Office 365, esiste un limite di 1.000 utenti di Office 365 per cluster, indipendentemente dal numero o dalla dimensione dei nodi del cluster. Il servizio basato su cloud è il metodo preferito per gestire gli utenti di Office 365. Consigliamo vivamente di ospitare solo temporaneamente gli utenti di Office 365 su Expressway.
Questa limitazione deriva dall'interazione con il servizio cloud Microsoft e non dalla scala della distribuzione locale di Expressway. Ad esempio, se ha un solo nodo Expressway piccolo, la sua capacità è limitata a 1.000 utenti di Office 365 e 4.000 Microsoft Exchange utenti. Se ha un cluster di 6 nodi piccoli, la sua capacità è limitata a 1.000 utenti di Office 365 più 24.000 Microsoft Exchange utenti.
|
Dimensione del nodo Expressway |
1 o 2 nodi* |
3 nodi |
4 nodi |
5 nodi |
6 nodi |
|---|---|---|---|---|---|
|
1. Piccolo |
5K |
10K |
15K |
20K |
25K |
|
2. Medio |
10K |
20K |
30K |
40K |
50K |
|
3. Grande |
15K |
30K |
45K |
60K |
75K |
* Nota che la capacità utente è la stessa per un cluster di un nodo e per un cluster di due nodi. Questo perché Calendar Service utilizza il failover per migliorare la continuità del servizio. Tutti gli utenti vengono assegnati a un nodo quando ci sono due nodi nel cluster; l'altro nodo è un backup ridondante. Vedere Planning Expressway Cluster Capacity for Hybrid Services Users per una spiegazione dettagliata.
Assegnazione degli utenti tra host e cluster
Per impostazione predefinita, l'Hybrid Calendar Service assegna e distribuisce automaticamente gli utenti in modo uniforme su tutti i connettori di calendario in un cluster. L'assegnazione è dinamica in base alla disponibilità e l'amministratore non ha il controllo su quale particolare nodo è assegnato un singolo utente.
Nei casi in cui un'organizzazione ha più di un cluster, la distribuzione degli utenti si basa su diversi fattori, tra cui la disponibilità del cluster, l'assegnazione corrente (per ridurre le interruzioni durante il ripristino da errore) e un ordinamento basato sulla preferenza più alta del cluster. L'amministratore ha anche la possibilità di assegnare un utente o un gruppo di utenti a un gruppo di risorse. I gruppi di risorse sono specifici del cluster, quindi consentono agli amministratori di limitare l'assegnazione di particolari set di utenti a un cluster specifico.
Con questa conoscenza di base dell'assegnazione degli utenti e tenendo conto dei prerequisiti di Expressway Calendar Connector, un amministratore può implementare la capacità appropriata su larga scala per la propria organizzazione. Diamo un'occhiata a un esempio di organizzazione di 126.000 utenti da abilitare per il servizio Hybrid Calendar, dati i seguenti parametri:
-
Cluster Expressway di 6 nodi che utilizzano il modello OVA di grandi dimensioni (limite di 15.000 utenti per nodo)
-
Nessun gruppo di risorse richiesto
La formula della capacità per un singolo cluster, U CalN = (N-1) * U cal1 dove N=6 e U cal1 =15.000 (utilizzando il modello OVA di grandi dimensioni) produce un massimo di 75.000 utenti. Con 126.000 utenti totali nell'implementazione del servizio di calendario, sono necessari più cluster host di Calendar Connector. Gli utenti sarebbero equamente distribuiti come mostrato nella figura seguente:
L'Hybrid Calendar Service aggiunge utenti al cluster A prima fino a quando il cluster non raggiunge la capacità di 75.000 utenti, quindi assegna gli utenti rimanenti al cluster B. Gli utenti sono distribuiti in modo casuale ed equo su tutti i nodi del cluster. Questo esempio mostra una distribuzione equa dei nodi host di Calendar Connector (all'interno di ciascuno dei due cluster) tra i data center RTP e PDX. Ogni nodo utilizza lo stesso modello OVA e segue le linee guida per l'alta disponibilità di Expressway. Il Calendar Connector utilizza la logica di clustering Expressway in un modello di ridondanza 5+1 per consentire scenari di elevata disponibilità.
Con tutti gli utenti assegnati a un Calendar Connector, esaminiamo ora cosa succede quando si verifica un errore in un cluster. La figura successiva mostra un guasto a un singolo nodo. Gli utenti assegnati al nodo fallito, 5A nel cluster A, sono ora passati ai nodi rimanenti di quel cluster. La capacità di un singolo nodo consente fino a 15.000 utenti e ogni nodo rimasto nel cluster A aggiunge 2500 utenti originariamente assegnati al nodo 5A. Non vi è alcuna modifica o impatto sul cluster B o sugli utenti assegnati al cluster B.
Il cluster A ha ancora la capacità massima e ciascuno dei nodi operativi del cluster ha ora la capacità massima, 15.000 utenti/nodo. Pertanto, se un altro nodo del cluster A non è disponibile, come il nodo 4A nella figura successiva, il cluster B sarà ora responsabile della raccolta del carico utente aggiuntivo. I 15.000 utenti del nodo 4A vengono ora riassegnati al cluster B e distribuiti equamente su tutti i nodi del cluster B.
Quando i nodi 4A e 5A verranno ripristinati, gli utenti del cluster A verranno ridistribuiti tra i nodi del cluster. Gli utenti che hanno effettuato l'accesso al cluster B rimangono nel cluster B durante questa fase di ripristino per evitare assegnazioni non necessarie di utenti tra i cluster, come mostrato nella figura successiva.
Un elemento chiave da tenere presente nella pianificazione di un'implementazione di Hybrid Calendar Service su larga scala è comprendere l'impatto di un eventuale guasto durante l'implementazione. Se utilizziamo la stessa distribuzione di 126.000 utenti ma perdiamo un intero data center, è possibile che gli utenti non vengano assegnati a un nodo Calendar Connector. Per evitare un'interruzione del servizio in questo tipo di scenario, il cliente avrebbe bisogno di un terzo cluster per ridistribuire e gestire gli utenti interessati.
La capacità di un cluster Expressway di fornire assistenza agli utenti di Hybrid Message dipende dalla dimensione dei nodi Expressway costituenti, dal numero di nodi nel cluster e dalla strategia di continuità del servizio.
La tabella seguente mostra il numero massimo di utenti su una singola superstrada utilizzata per il messaggio ibrido.
|
Piccola superstrada |
Superstrada media |
Grande superstrada |
|---|---|---|
|
5.000 utenti |
6.500 utenti |
15.000 utenti |
I numeri utente sono gli stessi per un cluster di un nodo e per un cluster di due nodi. Questo perché Message Service utilizza il failover per migliorare la continuità del servizio. Gli utenti sono distribuiti in modo uniforme tra i diversi nodi del cluster: se un nodo fallisce, gli utenti di quel nodo vengono assegnati agli altri nodi.
Questo argomento riguarda la condivisione di un connettore host Expressway tra i connettori per più servizi ibridi, inclusi Calendar Service e Message Service. L'host del connettore non è condiviso con altre soluzioni basate su Expressway come MRA e B2B.
La capacità del cluster host del connettore dipende dalla dimensione dei nodi Expressway costituenti, dal numero di nodi, dai connettori in esecuzione sul cluster e dalla strategia di continuità del servizio. Vedere Planning Expressway Cluster Capacity for Hybrid Services Users per una spiegazione dettagliata di questi fattori.
C'è anche una calcolatrice per modellare diversi cluster host di connettori e vedere quanti utenti di ogni servizio può supportare il cluster proposto.
In generale, consigliamo la coresidenza solo per implementazioni di dimensioni ridotte con un massimo di due nodi. Se la sua distribuzione supera la capacità di una coppia di nodi, deve spostare i connettori nei cluster Expressway dedicati a ogni specifico servizio ibrido.
Esempio: Connector Host Scale con tre connettori coresident
La tabella seguente mostra un esempio di scala e coresidenza. Fornisce il numero massimo di utenti per cluster, per ogni servizio, con specifiche diverse del cluster host del connettore. Il cluster è condiviso tra Hybrid Calendar (utilizzando il suo Exchange locale), Hybrid Call e Hybrid Message Service.
|
Servizio |
Due piccoli nodi |
Due nodi medi |
Due grandi nodi |
|---|---|---|---|
|
Utenti del servizio Calendar |
1,300 |
2,300 |
3,000 |
|
Utenti del servizio di messaggistica |
1,300 |
2,300 |
3,000 |
Introduzione
Questo argomento riguarda la condivisione di un connettore host Expressway con altre soluzioni basate su Expressway. Quando sceglie di ospitare connettori su un'autostrada che sta utilizzando per altri scopi, si applicano le seguenti importanti avvertenze:
-
Non possiamo supportare il modello di scalabilità che si applica a un connettore host dedicato Expressway. I numeri utente che deriva dalla lettura degli altri argomenti di questo articolo o dall'utilizzo della calcolatrice non si applicano quando l'host del connettore è condiviso con altri servizi Expressway.
-
Le combinazioni di servizi basati su Expressway e connettori di servizi ibridi descritte in questo articolo e i numeri utente associati sono gli unici scenari supportati. Non abbiamo testato altri scenari e non può aspettarsi che funzionino nel suo ambiente.
Servizio di calendario basato su Expressway con Call Connector e Call Service Traversal
In questo scenario, connettori Hybrid Calendar di un cluster Expressway a due nodi. Il cluster esegue anche l'attraversamento delle chiamate per altre soluzioni di chiamata Cisco (segnalazione SIP e contenuti multimediali).
La tabella mostra i diversi ambienti di calendario che può utilizzare con il connettore basato su Expressway. Il connettore Calendar basato su Expressway non è supportato nei cluster con più di due nodi. Usa il connettore basato sul cloud per una maggiore scalabilità con Office 365 (vedere Calendar Service Scale).
|
Servizio |
Cluster a due nodi piccoli |
Cluster a due nodi medi |
Cluster a due nodi di grandi dimensioni | |
|---|---|---|---|---|
|
Servizio calendario |
Exchange locale |
500 utenti |
1.000 utenti |
1.000 utenti |
|
Office 365 † |
500 utenti |
1.000 utenti |
1.000 utenti | |
|
Exchange e Office 365 locali (distribuzioni ibride di Exchange) |
Max 500 utenti per entrambi |
Max 1.000 utenti per entrambi |
Max 1.000 utenti per entrambi | |
|
Call Traversal |
200 sessioni audio 100 sessioni video |
200 sessioni audio 100 sessioni video |
1.000 sessioni audio 500 sessioni video | |
† Per evitare questa limitazione di scala, Le consigliamo di utilizzare il servizio di calendario basato sul cloud anziché il connettore locale. Per il calendario ibrido basato su Expressway, la limitazione della capacità di utenti di Office 365 a 1.000 per cluster è indipendente dalla dimensione o dal numero di nodi del cluster; questa limitazione deriva dall'interazione con il servizio cloud Microsoft e non dalla scala della distribuzione locale di Expressway.
Calendario con cellulare e Remote Access
In questo scenario, un cluster MRA di una o due piccole VM Expressway ospita il Calendar Connector. Questo scenario presuppone che il cluster venga utilizzato solo per MRA e i due connettori. Il cluster è limitato a uno o due piccoli nodi.
|
Scopo della superstrada |
Gruppo di una piccola superstrada C |
Gruppo di due piccole Expressway-C |
|---|---|---|
|
Utenti del servizio di calendario (connettore locale per Exchange) |
500 utenti |
500 utenti |
|
Cellulari e Remote Access utenti |
100 |
100 |
