[ English | Indonesia | Deutsch | 日本語 ]
Anwendungsfälle¶
Dieser Anhang enthält eine kleine Auswahl von Anwendungsfällen aus der Community, mit mehr technischen Details als sonst. Weitere Beispiele finden Sie auf der OpenStack-Website.
NeCTAR¶
Wer es nutzt: Forscher aus dem australischen öffentlich finanzierten Forschungssektor. Die Nutzung erfolgt in einer Vielzahl von Disziplinen, mit dem Ziel, Fälle zu vermeiden, die vom Betrieb einfacher Webserver bis hin zur Nutzung Hunderter von Kernen für Hochdurchsatz-Computing reichen.
Bereitstellung¶
Mit OpenStack Compute-Zellen umfasst die NeCTAR Research Cloud acht Standorte mit ca. 4.000 Kernen pro Standort.
Jeder Standort führt eine andere Konfiguration als Ressourcenzellen in einem OpenStack Compute-Zellen-Setup aus. Einige Standorte erstrecken sich über mehrere Rechenzentren, andere verwenden Off-Compute-Node-Speicher mit einem gemeinsamen Dateisystem und wieder andere verwenden Compute-Node-Speicher mit einem nicht gemeinsam genutzten Dateisystem. Jeder Standort stellt den Image-Service mit einem Object Storage Backend bereit. Es werden ein zentraler Identitäts-, Dashboard- und Compute-API-Dienst verwendet. Eine Anmeldung am Dashboard löst eine SAML-Anmeldung mit Shibboleth aus, die ein Konto im Identity-Dienst mit einem SQL-Backend erstellt. Ein Object Storage Global Cluster wird an mehreren Standorten eingesetzt.
Compute-Knoten haben 24 bis 48 Kerne, mit mindestens 4 GB RAM pro Kern und etwa 40 GB ephemeren Speicher pro Kern.
Alle Seiten basieren auf Ubuntu 14.04, mit KVM als Hypervisor. Die verwendete OpenStack-Version ist typischerweise die aktuelle stabile Version mit 5 bis 10 Prozent Back-Ported-Code aus dem Trunk und Modifikationen.
Resourcen¶
MIT CSAIL¶
Wer es benutzt: Forscher vom MIT Computer Science and Artificial Intelligence Lab.
Bereitstellung¶
Die CSAIL-Cloud besteht derzeit aus 64 physikalischen Knoten mit insgesamt 768 physikalischen Kernen und 3.456 GB RAM. Persistente Datenspeicherung liegt auf NFS weitgehend außerhalb der Cloud, wobei sich die Cloud-Ressourcen auf Compute-Ressourcen konzentrieren. Es gibt mehr als 130 Benutzer in mehr als 40 Projekten, die typischerweise 2.000-2.500 vCPUs in 300 bis 400 Instanzen ausführen.
Wir haben ursprünglich auf Ubuntu 12.04 mit der Essex-Version von OpenStack unter Verwendung von FlatDHCP Multi-Host-Netzwerken eingesetzt.
Der Software-Stack ist immer noch Ubuntu 12.04 LTS, aber jetzt mit OpenStack Havana aus dem Ubuntu Cloud Archive. KVM ist der Hypervisor, der über FAI und Puppet für das Konfigurationsmanagement bereitgestellt wird. Die FAI- und Puppen-Kombination wird im gesamten Labor eingesetzt, nicht nur bei OpenStack. Es gibt einen einzigen Cloud-Controller-Knoten, der auch als Netzwerk-Controller fungiert, während der Rest der Server-Hardware für Compute-Knoten vorgesehen ist.
Host-Aggregate und instanzartige Extra-Spezifikationen werden verwendet, um zwei verschiedene Ressourcenzuweisungsverhältnisse bereitzustellen. Die von uns verwendeten Standardverhältnisse für die Ressourcenzuweisung sind 4:1 CPU und 1,5:1 RAM. Rechenintensive Workloads verwenden Instanztypen, die nicht überverkaufte Hosts erfordern, bei denen cpu_ratio und ram_ratio beide auf 1,0 gesetzt sind. Da wir Hyper-Threading auf unseren Compute-Knoten aktiviert haben, erhalten Sie eine vCPU pro CPU-Thread oder zwei vCPUs pro physischem Kern.
Mit unserem Upgrade auf Grizzly im August 2013 wechselten wir zu OpenStack Networking, Neutron (damals noch Quantum). Compute-Knoten verfügen über zwei Gigabit-Netzwerkschnittstellen und eine separate Management-Karte für das IPMI-Management. Eine Netzwerkschnittstelle wird für die Knoten-zu-Knoten-Kommunikation verwendet. Der andere wird als Trunk-Port für OpenStack-verwaltete VLANs verwendet. Der Steuerungsknoten verwendet für seine öffentliche IP-Kommunikation zwei verbundene 10g-Netzwerkschnittstellen. Big Pipes werden hier verwendet, weil Abbilder über diesen Port bereitgestellt werden, und es wird auch verwendet, um eine Verbindung zum iSCSI-Speicher herzustellen und den Abbildspeicher und die Datenbank zu hinterlegen. Der Controller-Knoten verfügt auch über eine Gigabit-Schnittstelle, die im Trunk-Modus für den von OpenStack verwalteten VLAN-Verkehr verwendet wird. Dieser Port verwaltet den Datenverkehr mit dem DHCP-Agenten und dem Metadaten-Proxy.
Wir nähern uns dem älteren nova-network Multi-Host-HA-Setup, indem wir „Provider-VLAN-Netzwerke“ verwenden, die Instanzen direkt mit bestehenden öffentlich adressierbaren Netzwerken verbinden und bestehende physische Router als Standard-Gateway verwenden. Das bedeutet, dass, wenn unser Netzwerkkontroller ausfällt, laufende Instanzen noch ihr Netzwerk zur Verfügung haben und kein einziger Linux-Host zu einem Traffic-Engpass wird. Wir sind in der Lage, dies zu tun, weil wir über ein ausreichendes Angebot an IPv4-Adressen verfügen, um alle unsere Instanzen abzudecken, und somit kein NAT benötigen und keine Floating IP-Adressen verwenden. Wir stellen allen Projekten und zusätzlichen bestehenden VLANs bei Bedarf projektbezogen ein einziges generisches öffentliches Netzwerk zur Verfügung. Einzelne Projekte können auch ihre eigenen privaten GRE-basierten Netzwerke aufbauen.
Resourcen¶
DAIR¶
Wer es benutzt: DAIR ist eine integrierte virtuelle Umgebung, die das CANARIE-Netzwerk nutzt, um neue Informations- und Kommunikationstechnologien (ICT) und andere digitale Technologien zu entwickeln und zu testen. Es kombiniert digitale Infrastrukturen wie fortschrittliche Netzwerke und Cloud Computing und Storage, um eine Umgebung für die Entwicklung und den Test innovativer IKT-Anwendungen, -Protokolle und -Dienste zu schaffen, maßstabsgetreue Experimente zur Bereitstellung durchzuführen und eine schnellere Markteinführung zu ermöglichen.
Bereitstellung¶
DAIR wird in zwei verschiedenen Rechenzentren in ganz Kanada gehostet: einem in Alberta und einem in Quebec. Es besteht aus einem Cloud-Controller an jedem Standort, wobei einer als „Master“-Controller bezeichnet wird, der für die zentrale Authentifizierung und Quoten zuständig ist. Dies geschieht durch benutzerdefinierte Skripte und leichte Änderungen an OpenStack. DAIR betreibt derzeit Havanna.
Für die Objektspeicherung verfügt jede Region über eine schnelle Umgebung.
In jeder Region wird eine NetApp Appliance sowohl für Block Storage als auch für Instanz Storage verwendet. Es ist geplant, die Instanzen von der NetApp Appliance auf ein verteiltes Dateisystem wie Ceph oder GlusterFS zu verschieben.
VlanManager wird häufig für das Netzwerkmanagement eingesetzt. Alle Server verfügen über zwei verbundene 10GbE-Netzwerke, die mit zwei redundanten Switches verbunden sind. DAIR ist für die Verwendung von Single-Node-Netzwerken eingerichtet, wobei der Cloud-Controller das Gateway für alle Instanzen auf allen Compute-Knoten ist. Der interne OpenStack-Verkehr (z.B. Speicher-Verkehr) läuft nicht über den Cloud-Controller.
Resourcen¶
CERN¶
Wer es benutzt: Forscher am CERN (European Organization for Nuclear Research), die Hochenergiephysik forschen.
Bereitstellung¶
Die Umgebung basiert weitgehend auf Scientific Linux 6, das Red Hat-kompatibel ist. Wir verwenden KVM als unseren primären Hypervisor, obwohl die Tests mit Hyper-V auf Windows Server 2008 laufen.
Wir verwenden die Puppet Labs OpenStack-Module, um Compute, Image Service, Identity und Dashboard zu konfigurieren. Puppet wird häufig verwendet, z.B. zur Konfiguration, und Foreman wird als GUI für Reporting und Instanz-Provisionierung verwendet.
Benutzer und Gruppen werden über Active Directory verwaltet und über LDAP in den Identity-Service importiert. Dazu stehen CLIs für nova und Euca2ools zur Verfügung.
Am CERN laufen derzeit drei Clouds mit insgesamt etwa 4.700 Compute-Knoten und etwa 120.000 Kernen. Die CERN IT-Cloud soll bis 2015 auf 300.000 Kerne ausgebaut werden.
