Einführung
In diesem Dokument werden einige Aspekte der Support-Richtlinie für die gemeinsame Nutzung von Anwendungen erläutert, die in der Support-Richtlinie für den gleichzeitigen Widerstand von Anwendungen definiert sind und Teil der Support-Richtlinie für virtualisierte Cisco Unified Communications (UC)-/Collaboration-Anwendungen sind, die bei der Cisco Collaboration Virtualization definiert wurden. Dieser technische Hinweis gilt für alle UCs auf dem Unified Computing System (UCS) und andere Hardwareoptionen für die Virtualisierung, darunter die UCS-geprüfte Referenzkonfiguration, die UCS-Spezifikationen-basierte und die Server-Spezifikationen von Drittanbietern.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
-
UC auf UCS-Lösung
-
Hardware für getestete Referenzkonfigurationen für UCS
-
Spezielle Hardware (UCS, HP oder IBM)
-
Virtualisierung von Cisco Collaboration-Anwendungen
-
VMware vSphere-Software
-
Hardware des Cisco Unified Computing System
Hinweis: Links zu den Webseiten finden Sie im Abschnitt "Zugehörige Informationen" dieses Dokuments.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Co-Residenz und "Quality of Service"
Ein zentraler Bestandteil von Netzwerkkonvergenz und Virtualisierung ist die gemeinsame Nutzung von Hardwareressourcen.
-
Ein konvergentes IP-Netzwerk nutzt Netzwerkhardware für mehrere Datenströme (Sprache, Video, Speicherzugriff und andere Daten).
-
Ein virtualisierter Server (oder Virtualisierungshost) nutzt Computing-, Storage- und Netzwerkhardware für mehrere virtuelle Systeme (VMs).
In beiden Fällen ist eine Quality of Service erforderlich, um UC vor Nicht-UC-Anwendungen zu schützen, wenn die Hardwareressourcen begrenzt sind. Dies gilt als solcher:
-
Quality of Service (QoS) bei der Routing- und Switching-Netzwerkhardware, um sicherzustellen, dass der Sprach-/Videonetzwerkverkehr die erforderliche Bandbreite erhält, und um Verzögerungen und Jitter zu vermeiden.
-
Einhaltung von UC-Virtualisierungsregeln (z. B. Dimensionierung physischer/virtueller Hardware, Co-Residence-Richtlinie usw.), um sicherzustellen, dass UC VMs die erforderliche CPU-, Arbeitsspeicher-, Speicherkapazität und Speicher-/Netzwerkleistung erhalten.
Cisco ist nicht in der Lage, jede Kombination von Hardware und Anwendung auf gemeinsame VM-Residenz zu testen, insbesondere bei VMs von Drittanbietern, deren Verhalten möglicherweise nicht vorhersehbar oder nicht klar definiert ist. Aus diesem Grund wird die Echtzeit-Leistung von Cisco UC-Anwendungen nur bei der Installation in einer geprüften Referenzkonfiguration für das UCS und dann nur dann übernommen, wenn alle Bedingungen in der Co-Residence-Richtlinie eingehalten werden (siehe Collaboration Virtualization Sizing, und bei Anwendungen, die CPU-Reservierungen wie UCM und IMP unterstützen, gibt es weitere Überlegungen).
In anderen Umgebungen kann die Unsicherheit durch Tests vor der Bereitstellung, Baselining, die Einhaltung allgemeiner Virtualisierungsprinzipien und die Einhaltung der Cisco UC-Virtualisierungsregeln (bei der Cisco Collaboration Virtualization) verringert werden. Cisco kann jedoch nicht garantieren, dass VMs nie aufgrund von Ressourcenengpässen oder Leistungsproblemen benachteiligt werden.
Wichtige Support-Überlegungen für virtuelle Systeme von Drittanbietern und Drittanbietern
Damit das Cisco TAC bei der Ausführung von Cisco UC VMs, die gleichzeitig mit VMs von Nicht-UC-/Drittanbieter-Anwendungen ausgeführt werden, effektiv Support bereitstellen kann, müssen Kunden eine der folgenden Optionen sicherstellen:
-
Nicht-UC-/Drittanbieter-VMs sind nicht kritisch und können bei Bedarf vorübergehend heruntergefahren werden, um die Fehlerbehebung zu vereinfachen.
-
Wenn keine VMs nicht kritisch sind, müssen auf Virtualisierungshosts oder physischen Servern Kapazitätsreserven bereitgestellt werden, um VMs (temporär oder dauerhaft) als Lösung für Probleme mit der Anwendungsleistung zu verlagern. Ersatzkapazität ist bereits ein empfohlenes Design-Best Practice für Redundanz oder die Bereitstellung einer temporären Bereitstellung von VMs, wenn Hardware oder Software gewartet werden müssen. Beispiele für "ungenutzte Kapazität" sind zusätzliche "leere" physische Server (zur Bereitstellung von "Hot-Standby" oder temporärem Staging) oder vorhandene Blade-/Rackmount-Server, die nicht voll ausgelastet sind.
Damit das Cisco TAC bei der Ausführung von Cisco UC VMs, die gleichzeitig mit VMs von Nicht-UC-/Drittanbietern betrieben werden, effektiv Unterstützung bieten kann, kann Cisco die folgenden Aktivitäten des Kunden zur Problemdiagnose oder -behebung vorschreiben:
-
Änderungen der Software-Workloads oder der physischen Hardware, um Probleme mit der Anwendungsleistung zu beheben oder zu beheben. Beispiele für den Fall, dass diese Änderungen erforderlich sind, sind UC VM, die unzureichende CPU-, Arbeitsspeicher-, Netzwerk-, Festplattenkapazität oder IOPS-Operationen (Storage Input/Output Operations, IOPS) von der Hardware erhält.
-
Beispiele für diese Änderungen in einer tatsächlichen Bereitstellung sind hier aufgeführt.
-
Software: temporäre Deaktivierung nicht kritischer VMs, um die Behebung von Performance-Fehlern zu vereinfachen
-
Software: Verschiebung wichtiger VMs und/oder nicht wichtiger VMs, um als temporäre oder permanente Lösung den Virtualisierungshost/physischen Server zu wechseln.
-
Reduzieren Sie vorübergehend die Anzahl der virtuellen Systeme, die auf einem Host ausgeführt werden, wenn Cisco dies zur Fehlerbehebung für erforderlich hält.
-
Wenn Cisco feststellt, dass der Host überlastet ist, können Sie die Anzahl der virtuellen Systeme, die auf einem Host ausgeführt werden, dauerhaft reduzieren.
-
Aufteilen einer dichten UC-App-VM in mehrere weniger dichte VMs und Verschieben diese weniger dichten VMs auf einen alternativen Host. So wird z. B. eine CUCM 10K-Benutzer-OVA in mehrere CUCM 7.500-Benutzer-OVAs aufgeteilt und dann einige dieser CUCM 7.500-Benutzer-OVAs verschoben.
-
Diese Ansätze ermöglichen eine Reduzierung der Software-Workloads auf einem überlasteten Virtualisierungs-Host/physischen Server, sodass die Workloads nicht mehr durch Hardwareressourcen beeinträchtigt werden.
-
Hardware: Ergänzungen/Upgrades zur "Behebung" eines überlasteten Hosts als Alternative zum Einschalten von VMs oder zum Verschieben von VMs.
-
So können beispielsweise mehr physische Festplatten hinzugefügt werden, um die Speicherkapazität zu erhöhen und/oder IOPS bereitzustellen.
-
So können beispielsweise mehr physische oder mehr physische CPU-Kerne hinzugefügt werden.
-
Beispielsweise können physische NIC-Schnittstellen hinzugefügt werden, um Überlastungen im LAN zu vermeiden.
-
Diese Ansätze ermöglichen ein "Upgrade" der überlasteten Hardware, um den ressourcenintensiven Software-Workloads gerecht zu werden.
Der Support von Cisco ist davon abhängig, dass der Kunde einen aktuellen Support-Vertrag mit Cisco abschließt.
Zugehörige Informationen
Feedback