Get best of the week

Cisco UCS mit den Augen eines Cloud-Anbieters

Hallo Habr!

Als Cloud-Anbieter sammeln Sie ständig neues Wissen und Know-how an. Im Laufe der Jahre haben wir eine relativ große Anzahl von Praktiken entwickelt, die wir einhalten möchten, um den bestmöglichen Service zu gewährleisten. Eine davon ist die Verwendung von Cisco Unified Computing System-Lösungen. Unter dem Strich möchte ich Ihnen erklären, warum UCS unserer Meinung nach eine der besten Lösungen für Anbieter ist, und einige Merkmale der Arbeit und Fälle der Verwendung des Systems erörtern.

Fast 8 Jahre sind vergangen, seit Cisco UCS auf den Markt gekommen ist. Dies ist eine ausreichende Zeitspanne, damit sich das Publikum ein vollständiges Bild von der Technologie machen kann. Aus den Handbüchern, Rezensionen und Schulungsartikeln kann ein umfangreiches Buchband zusammengestellt werden. Aus den Marketingartikeln zu diesem Thema erhalten Sie jedoch zwei Bände. Wir werden versuchen, so objektiv wie möglich über Cisco UCS zu sprechen: Wir werden die Hauptmerkmale der Lösung hervorheben und auf dieser Grundlage die Vorteile für Cloud-Dienstanbieter erörtern und Fälle austauschen.

Am Anfang war das Wort


Der Begriff „Konvergenz“ wurde vor etwa 10 Jahren von HP Ingenieuren verwendet. Tatsächlich hat HP als erstes Unternehmen die sogenannten konvergierten Module für die Installation im HP BladeSystem c7000-Gehäuse freigegeben. Sie ermöglichten es beispielsweise, einem bestimmten Blade-Server eine bestimmte Bandbreite zuzuweisen. Dies war der erste Schritt in Richtung Konvergenz, aber diese Lösung verfügte nicht über alle erforderlichen Merkmale konvergierter Systeme.

Lassen Sie uns für alle Fälle erklären: Die konvergente Infrastruktur besteht aus einem einzigen Komplex von Geräten und Software mit einem einzigen Einstiegspunkt für die Verwaltung aller im Komplex enthaltenen Geräte sowie einem Orchester.

Was Cisco UCS betrifft, stimmt diese Lösung bereits vollständig mit der Definition der Konvergenz in Bezug auf Ausrüstung und Teil des Softwarepakets überein.

Lösungsarchitektur


Wir studieren das obige Schema sorgfältig und geben eine kurze Beschreibung der Elemente des komplexen "Top-Down".



Cisco UCS Manager-Software Ein

einziger Einstiegspunkt für die Verwaltung aller im Diagramm gezeigten Hardwarekomponenten und ein Orchestrator, mit dem Sie Komponenten manuell oder über die REST-API verwalten können. Dies ist eine Art "Gehirn" des Komplexes. Es ist in Fabric Interconnect installiert. Alle Geräteeinstellungen werden ausnahmslos über die Verwaltungsschnittstelle (GUI oder CLI) oder die UCS Manager-API vorgenommen.

Stoffverbindung

Ein Hardware-Unified-Switch, der auf Cisco Nexus basiert. Es bietet Netzwerkkonnektivität aller Komponenten des Komplexes sowie Konnektivität von Blade-Servern mit externen Netzwerken. Der Komplex umfasst zwei Fabric Interconnect. In den neuesten Versionen - FI6332 und FI6454 - ist es möglich, bis zu 20 Chassis 5108 anzuschließen, und die Gesamtzahl der Blade-Server erreicht in diesem Fall:

  • b480 M5 - bis zu 80 Server;
  • b200 M5 - bis zu 160 Server.

Heutzutage ist dies fast die einzige Lösung, die Integrationsmöglichkeiten innerhalb eines einzigen Einstiegspunkts bietet und eine nahtlose Netzwerkkonnektivität ohne die Verwendung zusätzlicher ToR-Switches oder anderer im Gehäuse installierter Module zusammen mit Blade-Servern unterstützt.

Chassis c5108

Im Vergleich zu FI sind dies relativ einfache Geräte. Ihr Layout ist Standard für Blade-Systeme: Netzteile, Lüfter sowie eine Schlüsselkomponente des Gehäuses - FEX-Module, die die Konnektivität zwischen Blade-Servern und FI gewährleisten. Zum Zeitpunkt des Schreibens werden sowohl 4-Port-40-GbE-Module 2304 als auch 8- oder 4-Port-10-GbE-Module 2204 unterstützt. Ihre Besonderheit ist die Möglichkeit, Ports zu gruppieren, wodurch die Gesamtbandbreite erhöht werden kann.

VIC (Virtual Interface Card)

Auf dem Blade-Server installierter intelligenter Adapter. Ermöglicht das Zuweisen von virtuellen Netzwerkressourcen sowohl für Hardwareserver als auch für virtuelle Maschinen. Unterstützt Eth- und FC / FCoE-Datenübertragungsprotokolle.

Nachdem das Lösungsgerät mehr oder weniger klar ist, lassen Sie uns darüber sprechen, warum Cisco UCS aus unserer subjektiven Sicht eine der bequemsten Lösungen auf dem Markt ist.

Warum Cisco UCS?


Nachdem wir eine klare Vorstellung davon haben, woraus die Lösung besteht, lassen Sie uns über ihre Vorteile sprechen. Wie ist die Cisco-Lösung besser als ihre „Verwandten“ - zum Beispiel dieselbe HP Synergy? Diese Frage wird oft von unseren Kollegen gestellt, obwohl die Antwort (wie es uns scheint) an der Oberfläche liegt. Der Punkt ist folgender:

  • universelle Lösung, Einhaltung des Begriffs "einheitlich" ⇒ OPEX-Rückgang;
  • Mit der minimalen Anzahl an Geräten können Sie die maximale Anzahl von Fällen (mehr dazu weiter unten) sowie die einfache Skalierung schließen. ⇒ niedrigere Investitionskosten;
  • Hervorragende Leistung und Lastausgleich, Verfügbarkeit auf Unternehmensebene.

De facto konzentrieren sich in diesen drei Punkten alle Hauptanforderungen an die Lösung sowohl auf geschäftlicher als auch auf IT-Seite. Ohne Fälle erscheinen diese Vorteile jedoch etwas unbegründet, weshalb wir sie anhand realer Beispiele weiter „entschlüsseln“ werden.

Praktische Anwendung


Wie zu Beginn dieses Artikels versprochen, werden wir uns in diesem Abschnitt mit Cisco UCS-Fallstudien befassen. Wir beginnen mit einem Rückblick auf unsere Erfahrungen und gehen reibungslos zu bestimmten Situationen über.

Inbetriebnahme von Geräten


Während der Zeit, in der wir Cisco UCS-Lösungen verwenden, mussten wir 8 Online-Systeme in Betrieb nehmen und erweitern (ein Komplex bedeutet ein Paar Fabric Interconnect und mindestens ein Blade-Chassis), insgesamt 16 FI und mehr. Der allererste Komplex, den wir 2014 in Betrieb genommen haben und der zu diesem Zeitpunkt nur über minimale praktische Erfahrung verfügt. Dieser Prozess dauerte drei Tage, von denen zwei für das Studium der Dokumentation und das Verständnis der Logik der Geräte aufgewendet wurden. Beachten Sie, dass die Dokumentation von Cisco auf der Ebene der besten RedBooks von IBM erstellt wurde. Kenner werden den Vergleich verstehen.

Nachdem wir uns mit der Logik und den Grundprinzipien der Konfiguration befasst hatten, konnten wir die Geräte einfach zusammenbauen und auf den Markt bringen. Anschließend haben wir die Firmware aller Komponenten aktualisiert, Serverprofilvorlagen eingerichtet und Profile erstellt. In nur einem Werktag.

Die weitere Implementierung erfolgte im Rahmen der Standardverfahren für das ITIL-Änderungsmanagement und dauerte vom Einschalten bis zur vollständigen Verwendung des Gehäuses, einschließlich der Erstellung und Konfiguration aller erforderlichen Vorlagen und Richtlinien, nicht mehr als vier Stunden, um jedes Paar von FIs und ein oder zwei Gehäusen bereitzustellen.

Die Verwendung der REST-API- und PowerTools-Module kann den Installationsprozess beschleunigen. Das Kopieren eines über 500 VLAN in eine neue Installation erfolgt beispielsweise mit PowerTools in nur zwei einfachen Schritten:

  • Abrufen der VLAN-Liste aus der Produktionsinfrastruktur
  • Hochladen der VLAN-Liste in den neuen Komplex.

Die Skalierung der Infrastruktur erfolgt durch Verbinden eines neuen Gehäuses mit Blade-Servern mit dem installierten FI-Paar (wenn die erforderliche Anzahl freier Ports vorhanden ist). Der Vorgang ist zu 100% online und kann über die Cisco UCS Manager-Oberfläche ausgeführt werden. Mit den richtigen globalen Einstellungen werden diese Ports unmittelbar nach dem Umschalten der FI-Ports, an die das Chassis angeschlossen ist, automatisch im Port-Kanal erfasst. Als nächstes wird ein automatisiertes Bestätigungsverfahren gestartet, in dessen Rahmen:

  • Aktualisieren aller Gehäusekomponenten auf die aktuelle Version von FW;
  • Power Cap Einstellung;
  • Zuordnen von Backplane-Ports auf FEX zu den erforderlichen Fabriken und Port-Channel-Assemblys für genau diese Ports.

Wir erinnern erneut daran, dass dies alles ohne das Eingreifen von Ingenieuren geschieht, basierend auf globalen Richtlinien, die während der Inbetriebnahme des Komplexes festgelegt wurden.

Mit der Zeit dauert ein solcher Vorgang ungefähr anderthalb Stunden. Die physische Verbindung des neuen Chassis mit FI besteht darin, FEX auf Ports am FI umzuschalten und dabei DAC-Kabel optimal zu verwenden. Und es ist überhaupt nicht notwendig, Originalkabel von Cisco zu nehmen.

Ausbeutung


Wie viel von diesem Sound ... Sie können viel darüber reden und nicht nur gut. Wie sie sagen, ohne ein Fass Teer wird ein Löffel Honig nicht so lecker sein. Im Ernst, alle Routinevorgänge, die in einer typischen Infrastruktur viele Minuten oder Stunden dauern, werden automatisch über die GUI ausgeführt. Um beispielsweise ein neues VLAN auf allen Blade-Servern des Komplexes zu verschütten (und ich erinnere mich, dass es 80 bis 160 Teile unterstützt), fügen Sie es einfach der vNIC-Vorlage im Abschnitt LAN-Richtlinien hinzu. Das neue VLAN wird automatisch auf alle Blade-Server übertragen, als Teil davon Diese vNIC-Vorlage ist vorhanden.

Da es sich um Richtlinien handelt, sollten Sie sagen, dass buchstäblich alle Einstellungen über Richtlinien festgelegt werden. Sie können sie natürlich nicht verwenden, aber es wird ... ähm, zu hart. Alle Netzwerkeinstellungen für Blade-Server, einschließlich MAC- und IP-Adressen für KVM, Flow Control, LACP, CDP, VMQ, werden über Richtlinien konfiguriert. Die BIOS-Einstellungen, die FW-Version, die auf den Blade-Server hochgeladen wird, Power Control, IPMI-Zugriffseinstellungen und vieles mehr werden auf dieselbe Weise festgelegt.
In diesem weiteren Beispiel wird die Fähigkeit von UCS vorgestellt, Routinevorgänge zu automatisieren, z. B. FC-Zoning-Einstellungen.

In den Einstellungen der Speicherverbindungsrichtlinie reicht es aus, den gewünschten Zonentyp auszuwählen und ihn beispielsweise als "Einzelinitiator-Einzelziel" festzulegen. In diesem Fall wird beim Binden des Blade-Servers an die Profilvorlage eine separate Zone erstellt. Diese Zone enthält automatisch das angegebene WWN-Ziel und den WWPN des virtuellen HBA vom gewünschten Port der gewünschten Factory.

Richtlinien sind an Vorlagenprofile für Server gebunden. Dann ist alles einfach: Binden der Vorlage an den gewünschten Blade-Server und Initialisierung. Die Ausgabe ist ein Server, der zur Installation des Betriebssystems bereit ist. Die Serverinitialisierung dauert nicht länger als 10 bis 20 Minuten und kann gleichzeitig für die gewünschte Anzahl von Servern durchgeführt werden. Insgesamt erhalten wir in nur 25-35 Minuten 80 bis 160 Server, die vollständig für die Installation des Betriebssystems bereit sind. Natürlich kann der Installationsprozess auch automatisiert werden, und die Cisco UCS-API kann Ihnen bei dieser Aufgabe helfen, aber dies ist ein Thema für einen anderen Artikel.

Gesamt:Um einen Komplex aus zwei FI-, 20-Blade-Chassis- und 160-b200-M5-Blade-Servern von Grund auf bis zur Installation des Betriebssystems bereitzustellen, muss ein Techniker nicht mehr als 8 Stunden und die meiste Zeit, etwa 3 Stunden, für die Erstellung von Richtlinien und Profilvorlagen aufwenden . Die verbleibende Zeit kann viel wichtigeren Angelegenheiten gewidmet werden, die auf die Initialisierung des Gehäuses und der Blade-Server warten, nachdem die Vorlagen an diese gebunden wurden. Die angegebene Bereitstellungszeit passt gut in das oben erwähnte OPEX-Kostensenkungsparadigma.

Einheitliches System


Vielseitigkeit, Vielseitigkeit und noch einmal Universalität - wahrscheinlich können Sie so das Motto des Komplexes ausdrücken. Wir veranschaulichen diese These mit einer Liste von Cisco UCS-Funktionen, die sie auch nach 8 Jahren auf dem Markt einzigartig machen. Nach heutigen Maßstäben ist dies eine sehr lange Zeit.

  • unified 10GbE/16Gbit FC, 40 GbE ( 4x10 GbE breakout);
  • Fibre Channel, Ethernet FCoE FI;
  • FC Fabric FI, FC Brocade NPV;
  • FI rack- Cisco extender', UCS Manager;
  • FI rack- , L2 ;
  • FI Eth FC.

Natürlich sind im UCS-Manager keine Geräteverwaltungsfunktionen von Drittanbietern enthalten - Cisco verfügt über andere Tools dafür -, aber die oben aufgeführten sind bereits beeindruckend. Hier einige Beispiele, bei denen uns einheitliche Funktionen gute Dienste geleistet haben:

Vorübergehender Austausch von Cisco Nexus-Switches Die

Lieferung neuer Cisco Nexus-Switches hat sich erheblich verzögert. Der neue NetApp-Speicher kam vor ihnen an und hätte mehrere Monate inaktiv sein können: Es gab nicht genügend 10-GbE-Ports für eine vollständige ausfallsichere Verbindung. Lösung: Wir verbinden den Speicher über FI-Ports, die im Appliance-Modus konfiguriert sind, konfigurieren den Portkanal mit LACP-Unterstützung und setzen den Speicher einige Monate vor dem Eintreffen der Switches in Betrieb. Die Ausrüstung ist in Betrieb, generiert Einnahmen, die Investitionskosten sinken.

Migration auf ein neues Speichersystem

Unser Kunde musste Daten vom alten EMC-Speichersystem mit minimalen Verlusten auf NetApp-Speicher migrieren. In seiner alten FC-Fabrik gibt es keine freien Ports, und es gibt keine Möglichkeit, FI mit einer gemeinsamen Fabrik zu verbinden. Es gab jedoch freie Ports im Speicher des Kunden. Wir verbinden sie mit FI, wir heben sie auf FC vSAN. Wir starten die Migration von virtuellen Maschinen über Storage vMotion zu NetApp, das über NFS verbunden ist. Alles ist in Ordnung, alle sind glücklich. Migration erfolgreich abgeschlossen.

Cisco UCS und Virtualisierung


Man kann eine Reihe von Vorteilen erwähnen, die die UCS-Architektur bietet, beispielsweise für eine virtuelle Infrastruktur, auf der VMware ausgeführt wird. VIC-Adapter, über die wir bereits bei der Beschreibung von Komponenten gesprochen haben, werden physisch über das Midplane-Chassis mit E / A-Modulen über die Backplane-Ports geschaltet. Es können 2 bis 4 Ports zu einem VIC kommen, die automatisch in EtherChannel-Ports auf UCS Manager-Ebene konfiguriert werden. Auf diese Weise können Sie die folgenden Vorteile von Netzwerkverbindungen nutzen:

  • Auf physikalischer Ebene erhalten wir eine ausfallsichere Verbindung zwischen dem Blade-Server und dem E / A-Modul auf FI-Ebene. Mindestens ein Backplane-Port wird von Fabric A und einer von Fabric B geliefert.
  • FI . EtherChannel Backplane NIC Teaming , , FI. active-active .
  • 256 PCIe virtual devices (vNIC vHBA) VIC. VIC « » Service Profile Template, . vNIC vHBA .
  • VM-FEX-Unterstützung, mit der Sie das Pass-Through-Switching zwischen VM und FI mithilfe der VMWare Direct Path IO-Technologie organisieren können.

Wie Sie sehen, hat sich der Cisco UCS-Komplex in einer Reihe von Aufgaben und Fällen wirklich bewährt. Einerseits ist es eine gut dokumentierte und bewährte Lösung. Andererseits verliert es nicht an Relevanz und schließt im Idealfall alle Aufgaben eines Cloud-Anbieters ab. Wenn Sie Ergänzungen zum Artikel haben oder Ihre eigenen Erfahrungen teilen möchten, warten wir in den Kommentaren auf Sie.

More articles:


All Articles