Fehlerbehebung bei UC in UCS TRC, UC auf UCS Specials-basierten Bereitstellungen und Lösungen von Drittanbietern

Einführung

In diesem Dokument werden einige Support-Aspekte von Cisco Unified Communications (UC)-Anwendungen, VMware vSphere-Virtualisierungssoftware und Serverhardware (Cisco oder Drittanbieter) erläutert, wenn diese entsprechend der Support-Richtlinien unter www.cisco.com/go/virtualized-collaboration bereitgestellt werden. Von besonderem Interesse sind die unterstützten Hardware-Inhalte.

Dieses Dokument gilt für alle Virtualisierungsoptionen, darunter:

• Business Edition 6000- und 7000-Appliances

• Test der Referenzkonfiguration (TRC) für UC auf dem Unified Communications System (UCS)

• UC auf UCS-Spezies-Basis

• Drittanbieter-Spezialisierungen

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in diesen Themen verfügen (siehe die zugehörigen Informationen am Ende dieses Dokuments für Links zu Webseiten):

• UC auf UCS-Lösung (Cisco Unified Communications auf dem Cisco Unified Computing System)

• Hardwarekonfigurationen für getestete UCS-Referenzkonfiguration (TRC)

• Spezielle Hardwarekonfigurationen (UCS oder Drittanbieter von Servern)

• Virtualisierung von Cisco Collaboration-Anwendungen

• VMware vSphere-Software

• Hardware des Cisco Unified Computing System

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco Collaboration-Anwendungen, die Virtualisierung unterstützen (siehe Informationen auf einen Blick auf www.cisco.com/go/virtualized-collaboration).

• Support-Richtlinien für die Virtualisierung von Cisco UC-/Collaboration-Anwendungen (siehe Unterstützende Dokumentation unter www.cisco.com/go/virtualized-collaboration).

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.

Was bedeutet "Unterstützt"?

Im Allgemeinen gibt es immer vier Dimensionen der "Unterstützung" zu berücksichtigen. Sie werden nachfolgend in Form von Fragen aufgeführt und beantworten spezifisch die Virtualisierung von Cisco UC-/Collaboration-Anwendungen:

• "Funktioniert es?" Obwohl dies ein Trend ist, gibt es bei der Virtualisierung viele Elemente, die scheinbar "funktionieren", aber möglicherweise nicht stabil sind oder für Echtzeit-Anwendungen ausreichend ausgeführt werden.  Zwar ist "Arbeit" notwendig, aber es reicht allein nicht aus, um von Cisco "zugelassen" oder unterstützt zu werden, und es ist möglicherweise nicht möglich, von VMware oder Cisco "validiert" worden zu sein.  

• "Wenn es funktioniert, ist es gemäß den Support-Richtlinien des Anbieters zulässig?" Cisco legt fest, was unterstützt wird und was auf www.cisco.com/go/virtualized-collaboration zulässig ist. Für Cisco Collaboration ist ein Artikel, der "nicht erlaubt" ist, auch wenn er "funktioniert", in der Regel aus einem der folgenden Gründe zurückzuführen:

  • Es entsteht ein Anwendungsproblem, das nur durch Software-Erweiterungen oder durch eine Neuarchitektur behoben werden kann. z. B. bestimmte Arten von Snapshots, die Cisco Unified Communications Manager hängen oder abstürzen.

  • Sie kann sich negativ auf die Anwendungsstabilität oder vorhersehbare Kapazität/Leistung auswirken, und es ist noch keine erforderliche Validierung durch Cisco erfolgt. vMotion beispielsweise mit Cisco Unified Communications Manager vor März 2011.

  • Für Cisco Collaboration-Anwendungen existiert kein gültiges Verwendungsszenario. Beispielsweise vSphere Dynamic Resource Scheduler für Anwendungen, die keine CPU-Reservierungen unterstützen.

• "Wenn es zulässig ist, hat der Anbieter es validiert?" So sind beispielsweise formelle Tests und Prüfungen wichtig, die besonders für UC/Collaboration-Bereitstellungen von Echtzeit-Sprach- und Videolösungen, Kundenkontaktcentern und anderen geschäftskritischen Kommunikationsanwendungen wichtig sind. Einige "zulässige" Elemente werden nicht "validiert", entweder weil sie nicht in den Zuständigkeitsbereich von Cisco fallen (z. B. vom Kunden bereitgestellte virtualisierte Server oder Speicher-Arrays von Drittanbietern) oder weil sie nicht in den Zuständigkeitsbereich der explizit von Cisco getesteten Komponenten fallen (z. B. die "Garantie" für die Anwendungsleistung" mit der getesteten Referenzkonfiguration (TRC) der UCS C-Serie Direct Attached Storage (DAS)-Hardware) im Vergleich "nur zur Unterstützung" mit spezieller Hardware). Infrastrukturlösungen wie Vblock oder FlexPod bieten u. a. eine "Validierung" auf Systemebene für eine Bereitstellung mehrerer Produkte und Produkte verschiedener Anbieter.

• "Bietet der Anbieter technische Unterstützung bei der Vorgehensweise oder Behebung von Problemen?" Unterstützung bei der Konfiguration oder Fehlerbehebung, um die Ursache eines Problems zu ermitteln und zu beheben. Das Cisco Technical Assistance Center (TAC) unterstützt Produkte, die bei Cisco erworben wurden, mit einem gültigen, kostenpflichtigen Wartungsvertrag.

Hier einige Beispiele für praxisorientierte "Support"-Konzepte, die diese Konzepte veranschaulichen:

• VMware-Boot vom SAN: 2010 "funktionierte" diese Funktion als experimentelle VMware-Funktion in vSphere 4.0, wurde aber von VMware erst offiziell "unterstützt", wenn vSphere 4.1 eingeführt wurde. Dies wirkte sich aus, als Cisco die Unterstützung für seine Kunden in Erwägung ziehen konnte.

• Fibre Channel-SAN mit virtualisierten UC-Anwendungen: Die Support-Richtlinie von Cisco "erlaubt" UC-Apps, über SAN-Netzwerke von Cisco oder von Drittanbietern mit Storage-Arrays von Drittanbietern zu verbinden, sofern diese die Anforderungen unter www.cisco.com/go/virtualized-collaboration erfüllen. Cisco validiert jedoch keine SAN-Switches oder Storage-Arrays von Drittanbietern, und das Cisco TAC bietet keine Unterstützung für Switches oder Arrays von Drittanbietern.

• Virtualisierung von UC-Anwendungen auf CPUs der Desktop-Klasse (z. B. Core-i3): Dies funktioniert möglicherweise nicht in dem Sinne, dass die Anwendung erfolgreich installiert und gestartet werden kann. Es ist jedoch unwahrscheinlich, dass sie im Sinne von Stabilität, Kapazität oder Leistung der Produktionsklasse "funktioniert". Diese CPUs sind von Cisco Collaboration-Anwendungen nicht zugelassen, validiert oder unterstützt, auch wenn sie scheinbar "funktionieren".

Cisco ist nicht in der Lage, jeden Aspekt und jede Kombination aus Hardware, VMware und Anwendungen auf sichere Weise zu testen, insbesondere bei Hardware und Software von Drittanbietern. Cisco definiert daher verschiedene Richtlinien für den Hardware-Support, die Kompromisse zwischen "Sicherung" und "Flexibilität" darstellen. Diese hängen davon ab, wie viel Lösung der Kunde von Cisco "besitzen" möchte, und stellt sicher, dass die Mindestanforderungen für den Betrieb von Produktionsanwendungen erfüllt werden.

Hinweis: Kunden, die die von Cisco veröffentlichten Support-Richtlinien nicht befolgen, werden gebeten, ein Problem in einer unterstützten Konfiguration zu reproduzieren, bevor das Cisco TAC effektiven Support anbieten kann.

Support-Klarstellungen für virtualisierte Hardware-Optionen

Für alle Optionen muss der Host (physische Hardware + VMware vSphere) von allen gleichzeitig implementierten Anwendungen auf diesem Host unterstützt werden. Informationen zur Anwendungsunterstützung finden Sie unter den folgenden Links:

• Informationen auf einen Blick unter www.cisco.com/go/virtualized-collaboration

• Collaboration Virtualization-Hardware

UC auf UCS TRC

UCS TRC-Hardwarekonfigurationen, die die Anforderungen an die Collaboration Virtualization Hardware erfüllen, sind "zulässig", wurden speziell für UC-Anwendungen von Cisco entwickelt und "validiert" und werden vom Cisco TAC im Rahmen der Support-Abgrenzung vollständig "unterstützt". Beispielsweise besitzt Cisco die gesamte Hardware auf einem TRC der UCS C-Serie mit DAS-Speicher. Bei einem TRC der UCS B-Serie bietet Cisco jedoch keine Validierung oder Unterstützung für Storage-Switches oder Storage-Arrays von Drittanbietern, und das Cisco TAC bietet keine Unterstützung für diese Komponenten von Drittanbietern.

Die Leistung der Cisco UC-App-VMs wird bei der Installation auf einem UCS TRC übernommen, der alle Anforderungen der Collaboration Virtualization Hardware (einschließlich der Speicherleistungsanforderungen für SAN) erfüllt und alle Bedingungen der Co-Residence-Richtlinie für die Collaboration Virtualization Sizing erfüllt.  Für UCM und IMP, die CPU-Reservierungen verwenden, sind hier weitere Überlegungen beschrieben.

In UC auf UCS TRCs wird auch eine Hardware-Materialliste angegeben. Diese ist nützlich für Benutzer, die das Hardwaredesign von Cisco besitzen möchten, wie bei älteren MCS 7800 Appliance-Angeboten.

UC auf UCS-Spezies-Basis

Spezielle UCS-Hardware, die die Anforderungen der Collaboration Virtualization Hardware erfüllt, und alle anwendungsspezifischen Anforderungen werden vom Cisco TAC im Rahmen der Support-Abgrenzung von Cisco "zugelassen" und vollständig "unterstützt", genau wie UCS TRC.

Der Unterschied besteht darin, dass spezielle UCS-Hardwarekonfigurationen nicht explizit für Collaboration-Anwendungen validiert werden. Aus diesem Grund erfolgt bei der Installation auf Hardware auf Basis der UCS-Spezifikationen keine Prognose oder Sicherung der VM-Leistung der UC-Anwendung. Es wird lediglich eine Anleitung gegeben und die Verantwortung dafür übernommen, sicherzustellen, dass das Presales-Hardware-Design die Leistung bereitstellt, die für die Migration von UC-Anwendungen von Cisco zum Kunden erforderlich ist. Andernfalls hilft das Cisco TAC bei der Behebung von Problemen mit der Leistung von UC-Anwendungen, wenn alle Regeln atwww.cisco.com/go/virtualized-collaboration befolgt werden. Beachten Sie die Punkte unter "Wichtige Überlegungen beim Support bei der Bereitstellung auf spezifikationsbasierter Hardware". Diese Punkte helfen zu klären, was das Cisco TAC für effektiven Support benötigen kann und wie weit das TAC ein Problem haben wird.

UCS-TRCs können als "Design-Referenzpunkte" für UCS-Spezifikationen angesehen werden. Das "Risiko", dass ein Hardware-Design auf Basis der UCS-Spezifikationen einer Reihe von UC-Anwendungs-VMs keine ausreichende Leistung bereitstellt, ist proportional zur "Abweichung" von den UCS-TRCs. Im Einzelnen:

• UCS-Servermodell nicht in TRC: In der Regel kein Problem, es sei denn, die Firmware oder die Treiber, die für dieses Modell verwendet werden, unterscheiden sich grundlegend von den Modellen, die als Teil einer TRC validiert wurden.

• CPU-Modell in keinem TRC enthalten: Ein anderes CPU-Modell, das nicht als Teil eines TRC validiert wurde, ist normalerweise kein Problem, solange es sich um eine zulässige CPU-Architektur mit der erforderlichen Kerngeschwindigkeit handelt und die UC-Regeln für die virtuelle bis physische Dimensionierung der erforderlichen Core-Anzahl befolgt werden (siehe unterstützte Prozessoren ). So wiesen beispielsweise VMs für UC-Anwendungen kaum Leistungsunterschiede zwischen dem Intel Xeon E5640 und dem X5650 auf (gleiche Architektur, ähnliche Leistungsmerkmale, dieselbe Kerngeschwindigkeit, nur verschiedene Core-Zähler, die unterschiedliche VM-Zählungen ermöglichen). Aufgrund der Interaktionen von CPU-Modellen mit Server-Modell-Firmware und anderen Systemkomponenten kann die VM-Leistung der UC-Anwendung jedoch nur für CPU-Modelle übernommen werden, die in einem TRC validiert wurden (dies war nur der E5640).

• Speicher: Eine andere Speicherkonfiguration als die der TRCs ist selten problematisch, solange sie den Cisco Richtlinien zur Speicherbestückung für eine optimale Leistung beim Servermodell sowie den Cisco UC-Regeln zur Bedarfsbestimmung für virtuelle und physische Speicherkapazität bei der Collaboration Virtualization Hardware entspricht. Beachten Sie, dass der UCS TRC-Speicher absichtlich für jede mögliche Kombination von UC-App-VMs ausgelegt ist, die auf den Host "passen", was zu einem Gesamt-RAM führt, der höher sein kann, als die Anforderungen Ihrer jeweiligen Bereitstellung.

• Adapter: Die LAN-Auslastung für virtuelle Systeme der UC-Anwendungen ist normalerweise gering für die Signalisierung, kann aber auch bei Bereitstellungen hoch sein, die medienintensiv sind (z. B. viele Voicemail-Audio-Streams oder Videostreams für Konferenzen im Vergleich zum Signalisierungsverkehr) oder NAS/SAN-Speicher (in diesem Fall sind die Adapter Teil der Speicherlösung unten). TRCs der UCS C-Serie sind mit genügend Ethernet-Ports konfiguriert, um die typischen Anforderungen der Typen von VM-Mixen der UC-Anwendungen zu erfüllen, die sie hosten können. Im Rahmen des Designprozesses muss sichergestellt werden, dass diese Ports für Ihre spezifische Bereitstellung ausreichend sind.

• Speicher: Hier liegt der Großteil der Komplexität und des "Risikos", da die meisten Cisco UC-Anwendungen E/A-intensiv sind. Es stehen mehrere Rechner für die theoretische DAS IO-Kapazität zur Verfügung, aber es ist sehr schwierig, die tatsächliche DAS-Kapazität ohne formale Tests genau vorherzusagen. NAS- und SAN-Speicher-Arrays bieten zuverlässigere Tools zur Designsicherung, Cisco validiert jedoch keine Storage-Arrays oder Storage-Switches von Drittanbietern (UC auf Vblock kann zur Gewährleistung dieser Sicherheit verwendet werden). Bei TRCs der UCS C-Serie wurden DAS-Konfigurationen getestet, verglichen mit der Latenztoleranz von und IOPS, die von den Typen von UC-App-VM-Mixen generiert werden, die TRC hosten kann.

Spektrumsbasierte Unsicherheiten lassen sich weiter reduzieren, indem Tests vor der Bereitstellung, Baselining, die allgemeinen Virtualisierungsprinzipien und die Cisco UC-Virtualisierungsregeln (bei der Cisco Collaboration Virtualization) befolgt werden. Cisco kann jedoch nicht garantieren, dass VMs niemals an Ressourcen verliert und keine Leistungsprobleme außerhalb einer UCS TRC aufweisen. "Headroom" ist eine bewährte Designpraxis, die entweder darin besteht, ungenutzte Kapazitäten auf einem Host zu belassen oder zusätzliche Hosts bereitzustellen.

UC auf UCS-Spezifikationen legt keine Hardware Bill of Materials (BOM) fest, da diese per Definition auf Spezifikationsbasis für Bereitstellungen basieren, bei denen der Kunde andere Spezifikationen/Materiallisten benötigt als in einer TRC validiert. Kunden sollten die BOMs der TRC-Module als Orientierungshilfe verwenden und ihre Partner- und Cisco-Teams bei der Erstellung von Materiallisten für Server unterstützen.

Drittanbieter-Spezialisierungen

Spezielle Server-Hardware von Drittanbietern, die die Anforderungen an Collaboration Virtualization Hardware erfüllen, ist von Cisco "zugelassen", Cisco führt jedoch keine Tests oder Validierungen für die Hardware von Drittanbietern durch.

Die VM-Leistung der UC-Anwendung kann bei der Installation auf Hardware, die auf Spezifikationen von Drittanbietern basiert, nicht vorhergesagt oder bestätigt werden. Es wird lediglich eine Anleitung gegeben und die Verantwortung dafür übernommen, sicherzustellen, dass das Presales-Hardware-Design die Leistung bereitstellt, die für die Migration von UC-Anwendungen von Cisco zum Kunden erforderlich ist. Andernfalls hilft das Cisco TAC bei der Fehlerbehebung, wenn alle Regeln der Cisco Collaboration Virtualization befolgt werden, um Anwendungsprobleme als Ursache auszuschließen. Der Kunde ist verantwortlich für die Behebung von Hardware-/Softwareproblemen, die nicht von Cisco sind, oder für die Ursachen von Anwendungsproblemen, die nicht von Cisco stammen (dazu gehört auch die vom Kunden bereitgestellte VMware-Software, wie in den Unterstützungsbestimmungen für Virtualisierungssoftware weiter unten in diesem Dokument beschrieben). Möglicherweise muss der Kunde Drittanbieter einbeziehen, um die Komponenten anderer Anbieter zu untersuchen.

Beachten Sie auch die Punkte, die unter Wichtige Support-Überlegungen bei der Bereitstellung auf spezifikationsbasierter Hardware aufgeführt sind. Diese Punkte helfen zu klären, was das Cisco TAC für effektiven Support benötigt und wie weit das TAC bei einem Problem sein wird.

Beachten Sie, dass Cisco die Virtualisierung auf älteren HP/IBM OEM-Servern (Media Convergence Server der Serie 7800 oder "MCS 7800") nicht unterstützt.

UCS TRCs können als "Design Reference Points" für Drittanbieter-Spezialisierungen verwendet werden, wie bereits zuvor in diesem Dokument beschrieben. Ähnliche Überlegungen gelten für CPU, Arbeitsspeicher, Adapter und Speicher. Beachten Sie, dass es keine TRCs gibt, die auf Servermodellen von Drittanbietern basieren.

Spektrumsbasierte Unsicherheiten lassen sich weiter reduzieren, indem Tests vor der Bereitstellung, Baselining, die allgemeinen Virtualisierungsprinzipien und die Cisco UC-Virtualisierungsregeln (bei der Cisco Collaboration Virtualization ) befolgt werden. Cisco kann jedoch nicht garantieren, dass VMs niemals an Ressourcen verliert und keine Leistungsprobleme außerhalb einer UCS TRC aufweisen.

Cisco legt keine Materialliste (BOM) für Server vor, die auf Spezifikationen von Drittanbietern basieren, da es sich hierbei per Definition um vom Kunden bereitgestellte Server von Drittanbietern handelt, die keine OEM-Server sind. Kunden können die UCS TRC-BOMs als Anleitung verwenden und ihre Server-Anbieter und internen Server-IT-Teams von Drittanbietern bei der Erstellung von Hardware-BOMs unterstützen.

Wichtige Überlegungen beim Support bei der Bereitstellung auf spezifikationsbasierter Hardware

• Damit das Cisco TAC bei der Ausführung von Cisco UC VMs auf spezifikationsbasierten Hardwarekonfigurationen effektiv Unterstützung bieten kann, benötigt Cisco VMware vCenter für UCS-Spezies- und Drittanbieter-Spezialisierungen. Weitere Informationen finden Sie unter Hardware- und Softwareanforderungen für die Collaboration-Virtualisierung. Kunden müssen VMware vCenter-Daten bereitstellen, wenn dies vom Cisco TAC gefordert wird, um die Konformität mit UC-Virtualisierungsanforderungen wie der Speicherleistung nachzuweisen.

• Damit das Cisco TAC bei der Ausführung von Cisco UC VMs auf spezifikationsbasierten Hardwarekonfigurationen effektiv Support anbieten kann, kann Cisco diese Aktivitäten vom Kunden zur Problemdiagnose oder -behebung verlangen: Ä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 sein könnten, sind UC VM, die unzureichende CPU-, Arbeitsspeicher-, Netzwerk-, Festplattenkapazität oder Speicher-IOPS von der Hardware erhält.

• Nachfolgend sind Beispiele für diese Änderungen in einer tatsächlichen Bereitstellung aufgeführt:

  • Software: temporäre Deaktivierung nicht kritischer VMs, um die Behebung von Performance-Fehlern zu vereinfachen

  • Software: Verlagern wichtiger VMs und/oder nicht kritischer VMs auf einen alternativen Virtualisierungshost/physischen Server als temporäre oder permanente Lösung.

    • 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, dann Verlagerung dieser weniger dichten VMs auf einen alternativen Host; Beispiel: Aufteilung einer CUCM 10K-Benutzer-OVA in mehrere CUCM 7.500 Benutzer-OVAs, dann Verlagerung einiger dieser CUCM 7.500 Benutzer-OVAs.

  • 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 Ändern der VM-Platzierung oder -Dichte.

  • Zum Beispiel das Hinzufügen weiterer physischer Festplatten, 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 verhindern.

  • Diese Ansätze ermöglichen ein "Upgrade" der überlasteten Hardware, um dem ressourcenintensiven Software-Workload gerecht zu werden.

  • Cisco kann nur Anleitungen für UCS-Server bereitstellen. Bei Servern von Drittanbietern muss der Kunde Support-Ressourcen von Drittanbietern einbeziehen.

• Wenn diese Anforderungen nicht akzeptabel sind, wird die Bereitstellung auf einem TRC der UCS C-Serie mit DAS-Speicher empfohlen.

Der Support von Cisco ist davon abhängig, dass der Kunde einen aktuellen Support-Vertrag mit Cisco abschließt.

Support-Klarstellungen für Virtualisierungssoftware

Kunden haben die folgenden Optionen für die Beschaffung von Virtualisierungssoftware, die mit Cisco Collaboration-Anwendungen bereitgestellt werden können:

1. Cisco UC Virtualization Hypervisor oder Hypervisor Plus (wird nur von der Cisco Business Edition 6000 unterstützt)

2. Cisco UC Virtualization Foundation (wird nur von UC-Anwendungen unterstützt, die entweder als UC auf der UCS-Lösung oder als Teil der Cisco Business Edition 6000/7000 bereitgestellt werden)

3. VMware vSphere Standard-, Enterprise- oder Enterprise Plus-Editionen, die von Cisco erworben wurden

4. Direkter Erwerb der VMware vSphere Standard-, Enterprise- oder Enterprise Plus-Editionen

Für die Optionen 1, 2 und 3 steht Ihnen das Cisco TAC zur Verfügung. Für Option 4 bietet Cisco TAC keinen Support für die Virtualisierungssoftware, und der Kunde sollte sich an den Händler des Drittanbieters wenden.

Der Support von Cisco ist davon abhängig, dass der Kunde einen aktuellen Support-Vertrag mit Cisco abschließt.

Zugehörige Informationen

• Cisco Unified Communications auf dem Cisco Unified Computing System
• Cisco Collaboration-Virtualisierung
• Collaboration Virtualization-Hardware
• Anforderungen an Virtualisierungssoftware
• Server - Unified Computing
• Rechenzentrumspartner - VMware
• Technischer Support und Dokumentation - Cisco Systems