Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Coresidenza e "Qualità del servizio"

Informazioni correlate

Introduzione

Questo documento chiarisce alcuni aspetti della policy di supporto per la co-residenza delle applicazioni definita nella policy di supporto della co-residenza delle applicazioni come parte della policy di supporto per le applicazioni Cisco Unified Communications (UC)/Collaboration virtualizzate definite in Cisco Collaboration Virtualization. Questa nota tecnica è applicabile a tutte le CU su Unified Computing System (UCS) e ad altre opzioni hardware di virtualizzazione che includono la configurazione di riferimento testata UCS, basata su specifiche UCS e su specifiche di server di terze parti.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Soluzione UC su UCS

- Hardware di configurazione di riferimento testato da UCS

- Hardware basato su specifiche (UCS, HP o IBM)

- Virtualizzazione delle applicazioni Cisco Collaboration

- Software VMware vSphere

- Hardware Cisco Unified Computing System

Nota: Per i collegamenti alle pagine Web, vedere la sezione "Informazioni correlate" di questo documento.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

- Applicazioni Cisco Collaboration che supportano la virtualizzazione (vedere In breve Cisco Collaboration Virtualization).

- Regole di supporto per la virtualizzazione delle applicazioni Cisco UCS/Collaboration (vedere Documentazione di supporto per Cisco Collaboration Virtualization).

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Coresidenza e "Qualità del servizio"

Un principio chiave della convergenza di rete e della virtualizzazione è la condivisione delle risorse hardware.

- Una rete IP convergente condivide l'hardware di rete tra più flussi di traffico (voce, video, accesso allo storage e altri dati).

- Un server virtualizzato (o host di virtualizzazione) condivide l'hardware di elaborazione, storage e rete tra più macchine virtuali (VM) applicative.

In entrambi i casi, la qualità del servizio è richiesta per proteggere le comunicazioni unificate dalle applicazioni non UC quando le risorse hardware sono limitate, come indicato di seguito:

- QoS (Quality of Service) nell'hardware di rete di routing e switching per garantire che il traffico di rete voce/video disponga della larghezza di banda necessaria e sia protetto da ritardi e jitter.

- Rispetto delle regole di virtualizzazione UC (ad esempio, dimensionamento dell'hardware fisico/virtuale, criteri di co-on-site e così via) per garantire che le VM UC ottengano la CPU, la memoria, la capacità di storage e le prestazioni di storage/rete necessarie.

Cisco non è in grado di testare ogni combinazione di hardware e applicazioni per la co-residenza delle VM, in particolare per le VM di applicazioni di terze parti il cui comportamento potrebbe essere imprevedibile o non chiaramente definito. Pertanto, il commit delle prestazioni in tempo reale delle applicazioni Cisco UC viene eseguito solo se installate in una configurazione di riferimento testata da UCS e solo quando vengono rispettate tutte le condizioni della policy di co-residenza (vedere Dimensionamento della virtualizzazione di Collaboration e, per le applicazioni che supportano le prenotazioni della CPU come UCM e IMP, potrebbero esserci altre considerazioni).

Per altri ambienti, l'incertezza può essere ridotta eseguendo test pre-installazione, baselining, seguendo i principi generali della virtualizzazione e le regole della virtualizzazione Cisco UCS (in Cisco Collaboration Virtualization). Tuttavia, Cisco non può garantire che le VM non saranno mai affamate di risorse e non avranno mai problemi di prestazioni.

Considerazioni principali sul supporto di macchine virtuali non UC e di terze parti

Per consentire a Cisco TAC di fornire un supporto efficace quando si eseguono VM Cisco UC con applicazioni VM non UC/di terze parti, i clienti devono verificare una delle seguenti condizioni:

- Le VM non UC/di terze parti non sono critiche e possono essere temporaneamente spente se necessario per facilitare la risoluzione dei problemi.

- Se nessuna VM è non critica, è necessario effettuare il provisioning della capacità di riserva sugli host di virtualizzazione o sui server fisici per il trasferimento (temporaneo o permanente) delle VM come soluzione ai problemi di prestazioni delle applicazioni. La capacità di riserva è già una best practice consigliata per la progettazione della ridondanza o per fornire lo staging temporaneo delle VM quando è richiesta la manutenzione su hardware o software. Esempi di "capacità di riserva" sono i server fisici "vuoti" aggiuntivi (per fornire lo "standby a caldo" o lo staging temporaneo) o i server blade/rack esistenti non completamente utilizzati.

Per consentire a Cisco TAC di fornire un supporto efficace quando si eseguono VM Cisco UC con applicazioni VM non UC/di terze parti, Cisco potrebbe richiedere queste attività al cliente per la diagnosi o la risoluzione del problema:

- Modifiche al carico di lavoro del software o all'hardware fisico per risolvere i problemi di prestazioni delle applicazioni. Esempi di quando potrebbero essere necessarie queste modifiche sono le VM UC che ricevono dall'hardware CPU, memoria, rete, capacità del disco o operazioni di input/output di archiviazione (IOPS) al secondo.

- Di seguito sono elencati alcuni esempi di modifiche apportate a una distribuzione effettiva.

- Software: spegnimento temporaneo di VM non critiche per facilitare la risoluzione dei problemi di prestazioni

- Software: spostare le VM critiche e/o non critiche in modo da alternare host di virtualizzazione/server fisico come soluzione temporanea o permanente.

- Ridurre temporaneamente il numero di macchine virtuali in esecuzione su un host se Cisco lo ritiene necessario per la risoluzione dei problemi.

- Ridurre in modo permanente il numero di macchine virtuali in esecuzione su un host se Cisco determina che l'host è sovraccarico.

- Suddivisione di una VM dell'applicazione UC densa in più VM meno dense, quindi spostamento di tali VM meno dense in un host alternativo. Ad esempio, suddividendo un OAV utente CUCM 10K in più OAV utente CUCM 7.5K, quindi spostando alcuni di questi OAV utente CUCM 7.5K.

- Questi approcci consentono di ridurre il carico di lavoro del software su un host di virtualizzazione/server fisico sovraccarico, in modo che il carico di lavoro non sia più affamato di risorse hardware.

- Hardware: aggiunte/aggiornamenti per "correggere" un host sovraccarico come alternativa all'spegnimento delle VM o allo spostamento delle VM.

- Ad esempio, l'aggiunta di più dischi fisici per aumentare la capacità di storage e/o fornire IOPS.

- Ad esempio, aggiunta di più memoria fisica o più core CPU fisici.

- Ad esempio, l'aggiunta di interfacce NIC fisiche per risolvere la congestione della LAN.

- Questi approcci consentono di "aggiornare" l'hardware sovraccarico per far fronte al carico di lavoro del software, caratterizzato da scarse risorse.

Il supporto Cisco viene fornito a condizione che il cliente mantenga un contratto di supporto corrente e completamente pagato con Cisco.

Informazioni correlate

- Cisco Unified Communications su Cisco Unified Computing System

- Unified Communications in un ambiente virtualizzato

- VMware

- Partner DC - VMware

- Requisiti VMware per Unified Communications

- Unified Computing

- Documentazione e supporto tecnico – Cisco Systems