| Zeile 120: | Zeile 120: | ||
== Anleitungen == | == Anleitungen == | ||
| − | + | Die Anleitungen umfassen eine ausfühliche Quick-Start Anleitung, sowie ein Hand voll Kochbücher für die täglichen Arbeiten in der Cloudumgebung. | |
| − | |||
{{service portal listing|type=Anleitung}} | {{service portal listing|type=Anleitung}} | ||
Version vom 27. September 2016, 12:09 Uhr
| Cloudcomputing | |
|---|---|
| Ein Dienst des ZIM | |
 Cloudcomputing | |
| Informationen | |
| Zielgruppe | Endbenutzer |
Mit dem Dienst Cloudcomputing bietet das IMT ein Infrastructure-as-a-Service-Angebot (IaaS) auf der Basis von OpenStack. Gestützt durch eine Studie des Bundeswirtschaftsministeriums zur Standardisierung von Cloud Computing bietet OpenStack eine Referenzarchitektur zum Aufbau von Cloud-Infrastrukturen. Ausgeführt ist diese am Standort Paderborn als private Cloud, unabhängig von externen Komponenten, betrieben im Rechenzentrum der Universität.
Siehe auch Wikipedia: Cloud_Computing
Angebotene Kernkomponenten[Bearbeiten | Quelltext bearbeiten]
Die betriebene Infrastruktur setzt sich aus einer Vielzahl von Komponenten zusammen, welche sich unter anderem um die Virtualisierung sowie die Bereitstellung von Storage kümmern.
Rechenleistung / Compute[Bearbeiten | Quelltext bearbeiten]
Bei Compute, handelt es sich um den Teil des Cloudsystems, der Gruppen von virtuellen Maschinen verwalten kann. Unterstützt wird im Moment ausschließlich Vollvirtualisierung in der Architektur x86(_amd64). Verwaltet werden die virtuellen Maschinen, im Cloudcomputing-Kontext auch Instanzen genannt, über das webbasierte Dashboard oder eine öffentliche REST API.
Erstellt werden Instanzen aus Abbildern die schon fertige Betriebssysteminstallationen enthalten. Diese werden bei der Instanziierung erweitert durch die maschinenspezifischen Einstellungen (IP-Adresse, Schlüsselpaare, Scripte die nach dem Erzeugen laufen sollen, u.s.w.). Es können auch eigene Abbilder hochgeladen werden, die dann zu erzeugen von Instanzen genutzt werden können.
Auf der Netzwerkebene werden Instanzen durch Sicherheitsgruppen und deren Zugriffsregeln geschützt. Im Standartfall sind Instanzen nicht per Netzwerk zu erreichen. Zugriffsregeln bestimmen Verbindungen die aufgebaut werden können. Ein Beispiel wäre der Zugriff per SSH aus einem festgelegten Netzbereich. Erst durch das zuweisen einer oder mehreren Sicherheitsgruppen ist die Instanz zu erreichen.
Der Standard-Weg um eine Linux-Instanz zu erreichen ist über eine SSH-Verbindung unter Zuhilfenahme eines SSH-Schlüsselpaares. Das SSH-Schlüsselpaar kann, falls schon eins Vorhanden ist, importiert werden. Es kann aber auch ein Schlüsselpaar über das Dashboard erzeugt werden. Bei der Anmeldung auf eine Windows-Instanz, die aus einem Abbild erzeugt wurde, geschieht dies per Remote-Desktop. Das Passwort wird mit dem SSH-Schlüsselpaares verschlüsselt und kann mit den Openstack Kommandozeilen-Client abgerufen und wieder entschlüsselt werden.
Die "Größe" der virtuellen Maschine (Festplattenplatz, CPUs, RAM) wird bei der Instanziierung festgelegt und ist im Cloudcomputing-Kontext als Varianten (Flavor) zu finden.
Connectivity / Netzwerk[Bearbeiten | Quelltext bearbeiten]
Neben den virtualisierten Maschinen, ist auch das Netzwerk in Openstack virtualisiert. (Virtuelle) Private Netzwerke bilden den Anschluss für jede Instanz. Soll eine Verbindung von Außen auf Instanzen in der Cloud hergestellt werden, müssen Floating IPs aus einem passenden Pool zugewiesen werden.
Floating IPs und IP Pools[Bearbeiten | Quelltext bearbeiten]
Eine Floating IP ist routbare (im Hochschulnetz und Internet erreichbare) IP-Adresse, die nicht automatisch einer Instanz zugewiesen wird. Stattdessen ordnet ein Projekt-Eigentümer sie bei Bedarf selbst (temporär) einer oder mehreren Instanzen zu. Die jeweilige Instanz verfügt dann sowohl über eine automatisch vergebene und statische IP für die Kommunikation zwischen den Instanzen im privaten Netzwerkbereich, sowie über eine manuell zugewiesene Floating IP. Dies macht die Dienste der Instanz für Nutzer außerhalb einer Cloud bzw. eines Netzwerks erkennbar und damit erreichbar.
Die Projekt-Eigentümer beziehen Floating IPs für ihre Projekte aus verschiedenen Pools. Diese Pools unterscheiden sich durch den Netzbereich aus dem IP-Adressen vergeben werden. Sobald ein Projekt-Eigentümer eine Floating IP bezieht, wird er zu deren „Eigentümer“. Er kann sie jederzeit einer Instanz zuordnen, wieder von ihr lösen und einer anderen zuordnen. Auch wenn eine Instanz beendet wird, „verliert“ der Projekt-Eigentümer die zugeordnete Floating IP nicht. Sie verbleibt als seine Ressource und kann weiterhin jederzeit wieder einer anderen Instanz zugeordnet werden.
In Failover-Szenarien kann eine solche IP auch dynamisch zu einer anderen aktiven Einheit im Netzwerk „floaten“ (floating = gleitend, schwebend). Die folgende Tabelle enthält die Optionen in der Auswahl des passenden Netzes:
| Verwendung und Beschreibung | Name | Netzsegment |
|---|---|---|
IP-Adressen für Instanzen die
|
private-uni (physext_private_uni) |
172.23.56.0/23 |
IP-Adressen für Instanzen die
|
f5 (physext_f5_net) |
172.31.251.0/24 |
IP-Adressen für Instanzen die
|
dmz-uni (physext_dmz_uni) |
131.234.165.0/24 |
IP-Adressen für Instanzen die
|
public-uni-services (physext_uni_services) |
192.26.178.0/23 |
IP-Adressen für Instanzen die
|
public-uni (physext_public_uni) |
192.26.184.0/22 |
Alle öffentlichen Netzbereiche werden durch die zentrale Firewall geschützt. Folgende Dienste werden aufgrund der hohen Missbrauchsgefahr standardmäßig nicht durchgelassen:
| Dienst | Protokoll | Port |
|---|---|---|
| Remote Desktop Protocol (RDP) | TCP & UDP | 3389 |
| Domain Name System (DNS) | TCP & UDP | 53 |
| Network Time Protocol (NTP) | UDP | 123 |
| SOCKS | TCP | 1080, 8080 |
| Network File System (NFS) | TCP & UDP | 111, 694, 2049 |
| SMTP | TCP | 25, 465, 587 |
| (T)FTP | TCP | 20, 21, 69 |
| Telnet | TCP | 23 |
| NetBIOS over TCP/IP, CIFS | TCP & UDP | 137, 138, 139, 445 |
Sonderregeln, welche die oben genannten Einschränkungen aufheben, werden nach Absprache eingetragen. Schicken Sie hierzu eine Mail an das Ticketsystem (imt@upb.de).
Zusatzdienste[Bearbeiten | Quelltext bearbeiten]
Neben den normalen Funktionen rund um virtuelle private Netzwerke, werden noch die beiden Dienste
angeboten. Weitere Hinweise finden sich auf den verlinkten Seiten im Cloudcomputing Kochbuch.
Speicher / Objektspeicher[Bearbeiten | Quelltext bearbeiten]
Zu den Diensten der Cloudcomputing Umgebung gehört ein Objektspeicher. Objektspeicher können zum Speichern von Objekten oder einzelnen Dateien verwendet werden. Auch das Strukturieren der Objekte mit Unterordner ist möglich.
Organisiert wird er in einen oder mehreren Containern. Ein Container ist ein Speicherbehälter für Daten und bietet Ihnen eine Möglichkeit, Ihre Dateien zu organisieren. Sie können sich einen Container wie einen Ordner unter Windows oder in UNIX vorstellen. Der Hauptunterschied zwischen einem Container und anderen Dateisystemkonzepten ist, dass Container nicht verschachtelt werden können. Sie können jedoch in Ihrem Konto eine unbegrenzte Anzahl an Containern erstellen. Da Daten in einem Container gespeichert werden müssen, müssen Sie mindestens einen Container in Ihrem Konto angegeben haben, bevor Sie Daten hochladen können.
Der Zugriff auf Container geschicht ausschließlich über eine REST-API oder über das Dashboard.
Anmerkung: Ein öffentlicher Container erlaubt jedem Zugriff auf Objekte in dem Container, der die öffentliche URL hat.
Organisatorisches[Bearbeiten | Quelltext bearbeiten]
Der Dienst Cloudcomputing wird über das Serviceportal, Weitere Dienste, im Bereich Zentrum für Informations- und Medientechnologien (IMT), Regionale Private Cloud beantragt beantragt.
Die Anträge werden händisch moderiert. Nach der Moderation erhalten Sie eine Mail mit weiteren Informationen. Benutzer werden einzelnen Projekten zugeordnet die mit Kontigenten (Rechenzeit, Netzwerk, etc.) versehen sind. Alle Benutzer eines Projektes teilen sich die Kontigente des Projektes. Es können sich nur Benutzer anmelden die auch einem Projekt zugewiesen sind. Neue Projekte können in Abstimmung mit dem IMT angelegt werden. Schicken Sie hierzu eine Mail an das Ticketsystem (imt@upb.de).
Anleitungen[Bearbeiten | Quelltext bearbeiten]
Die Anleitungen umfassen eine ausfühliche Quick-Start Anleitung, sowie ein Hand voll Kochbücher für die täglichen Arbeiten in der Cloudumgebung.
| Artikel | Betriebssysteme | Spezielle Zielgruppe |
|---|---|---|
| Cloudcomputing Kochbuch Kommandozeilen-Client erzeugen | Alle |  •  • 
|
| Cloudcomputing Kochbuch Load Balancer as a Service (LBaaS) | Alle | • •
|
| Cloudcomputing Kochbuch Netzwerk | Alle | • •
|
| Cloudcomputing Kochbuch Objektspeicher | Alle | • •
|
| Cloudcomputing Kochbuch Orchestrierung | Alle | • •
|
| Cloudcomputing Kurzanleitung - Docker Host | Alle | • •
|
| Cloudcomputing Kurzanleitung - GitLab Runner | Alle | • •
|
| Cloudcomputing Kurzanleitung - Jupyter Notebook | Alle | • •
|
| Cloudcomputing Kurzanleitung - RStudio Server | Alle | • •
|
| Cloudcomputing Kurzanleitung - k3s-Cluster (Kubernetes) | Alle | • •
|
| Cloudcomputing Quick-Start | Alle | • •
|
| FAQ Einstellung RDI-Cloud | Alle | • •
|
Informationen[Bearbeiten | Quelltext bearbeiten]
| Artikel | Betriebssysteme | Spezielle Zielgruppe |
|---|---|---|
| Cloudcomputing Aktuelle Informationen | Alle | • •
|
