Jnk (Diskussion | Beiträge) K (Textersetzung - „IMT“ durch „ZIM“) |
|||
| (14 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{service portal | {{service portal | ||
|targetgroup=Angestellte, Gäste, Studierende | |targetgroup=Angestellte, Gäste, Studierende | ||
| − | |description= | + | |description=Das ZIM bietet einen Infrastructure-as-a-Service-Angebot (IaaS) auf der Basis von OpenStack. |
|glossary=Nein | |glossary=Nein | ||
}} | }} | ||
| − | Mit dem Dienst ''' | + | <bootstrap_alert color=info> |
| + | Der Dienst "Cloudcomputing" in der RDI-Cloud wird zum 17.12.2024 eingestellt. | ||
| + | |||
| + | Bei Frage zur Migration wenden Sie sich bitte direkt an das ZIM. | ||
| + | Siehe auch: [[FAQ_Einstellung_RDI-Cloud|FAQ: Einstellung des Dienstes RDI-Cloud]] | ||
| + | </bootstrap_alert> | ||
| + | |||
| + | Mit dem Dienst '''RDI-Cloud''' bietet das ZIM ein Infrastructure-as-a-Service-Angebot (IaaS) auf der Basis von OpenStack. Ausgeführt ist diese am Standort Paderborn als private Cloud, unabhängig von externen Komponenten, betrieben im Rechenzentrum der Universität. | ||
Siehe auch [https://de.wikipedia.org/wiki/Cloud_Computing Wikipedia: Cloud_Computing] | Siehe auch [https://de.wikipedia.org/wiki/Cloud_Computing Wikipedia: Cloud_Computing] | ||
| + | |||
| + | == Organisatorisches / Dienst beantragen == | ||
| + | Der Cloudcomputing Dienst kann von Lehrenden und Mitarbeiter:innen der Universität über ein Ticket an das Ticketsystem des ZIM beantragt werden. Das ZIM erstellt dann eine Serviceportal Gruppe, die in das Openstack übertragen wird. | ||
| + | |||
| + | Benutzer werden einzelnen Projekten zugeordnet die mit Kontingenten (Rechenzeit, Netzwerk, etc.) versehen sind. Alle Benutzer eines Projektes teilen sich die Kontingente des Projektes. | ||
| + | Es können sich nur Benutzer anmelden die auch einem Projekt zugewiesen sind. Neue Projekte können in Abstimmung mit dem ZIM angelegt werden. Schicken Sie hierzu eine [mailto:cloudcomputing@upb.de Mail an das Ticketsystem (cloudcomputing@upb.de)]. | ||
| + | |||
| + | == Anleitungen == | ||
| + | Die Anleitungen umfassen eine ausführliche Quick-Start Anleitung, sowie eine Hand voll Kochbücher für die täglichen Arbeiten in der Cloudumgebung. Unabhängig davon bietet die Umgebung noch eine | ||
| + | Vielzahl von weiteren Funktionen. Eine abschließende Liste von Anleitungen für alle Funktionen kann hier nicht geleistet werden. Haben Sie ein genaues Problem oder eine Idee, lohnt sich eine Suche mit einer Internet-Suchmaschine, gepaart mit den Schlüsselwörtern <code>Openstack</code>, oder <code>Cloudcomputing</code>. In vielen Fällen finden sich gute Denkanstöße oder Erfahrungsberichte die angewendet werden können. | ||
| + | |||
| + | {{service portal listing|type=Anleitung}} | ||
== Angebotene Kernkomponenten == | == Angebotene Kernkomponenten == | ||
| − | |||
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. | 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 === | === Rechenleistung / Compute === | ||
| − | |||
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. | 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 fertige Betriebssysteminstallationen enthalten. Diese werden bei der Instanziierung erweitert durch die maschinenspezifischen Einstellungen (IP-Adresse, Schlüsselpaare, Scripte die nach dem Erzeugen laufen sollen, usw.). Es können auch eigene Abbilder hochgeladen werden, die dann | + | Erstellt werden Instanzen aus Abbildern die fertige Betriebssysteminstallationen enthalten. Diese werden bei der Instanziierung erweitert durch die maschinenspezifischen Einstellungen (IP-Adresse, Schlüsselpaare, Scripte die nach dem Erzeugen laufen sollen, usw.). Es können auch eigene Abbilder hochgeladen werden, die dann zum Erzeugen von Instanzen genutzt werden können. |
| − | Auf der Netzwerkebene werden Instanzen durch Sicherheitsgruppen und deren Zugriffsregeln geschützt. Im | + | Auf der Netzwerkebene werden Instanzen durch Sicherheitsgruppen und deren Zugriffsregeln geschützt. Im Standardfall 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 mehrerer 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. Auch ein bereits vorhandenes SSH-Schlüsselpaar kann 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. | + | Der Standard-Weg um eine Linux-Instanz zu erreichen ist über eine SSH-Verbindung unter Zuhilfenahme eines SSH-Schlüsselpaares. Auch ein bereits vorhandenes SSH-Schlüsselpaar kann 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. |
Die "Größe" der virtuellen Maschine (Festplattenplatz, CPUs, RAM) wird bei der Instanziierung festgelegt und ist im Cloudcomputing-Kontext als Varianten (Flavor) zu finden. | Die "Größe" der virtuellen Maschine (Festplattenplatz, CPUs, RAM) wird bei der Instanziierung festgelegt und ist im Cloudcomputing-Kontext als Varianten (Flavor) zu finden. | ||
| Zeile 27: | Zeile 44: | ||
=== Connectivity / Netzwerk === | === Connectivity / Netzwerk === | ||
| − | + | 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 zugewiesen werden. | |
| − | 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 | ||
==== Floating IPs und IP Pools ==== | ==== Floating IPs und IP Pools ==== | ||
| − | |||
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. | 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. | ||
| − | + | Standardmäßig bekommt jedes Projekt vier Floating IPs zugewiesen. Zwei dieser IPs können aus dem Internet erreicht werden, die anderen zwei aus dem Hochschulnetz. Die Floating IPs bekommen zudem automatisch einen DNS-Eintrag. Die extern erreichbaren Floating IPs sind unter <code>rdi-cloud-xxx-xxx.uni-paderborn.de</code> erreichbar, die internen unter <code>rdi-cloud-private-xxx-xxx.uni-paderborn.de</code>. Den <code>xxx-xxx</code>-Teil der URL ersetzten Sie durch die letzten beiden Blöcken Ihrer Floating IP-Adresse.<br> | |
| + | Diese IPs können 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: | 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: | ||
| Zeile 40: | Zeile 56: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| − | ! Verwendung und Beschreibung || Name | + | ! Verwendung und Beschreibung || Name |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
| IP-Adressen für Instanzen die | | IP-Adressen für Instanzen die | ||
| − | * Dienste innerhalb | + | * Dienste innerhalb der Universität anbieten |
| − | * | + | * Dienste, die über einen Loadbalancer laufen |
| − | * | + | * Konnektivität ins Internet ist nur per IPv6 möglich |
| − | + | * IPv4 Konnektivität ins Internet kann per Floating IP hergestellt werden | |
| − | + | || uni | |
| − | |||
| − | * | ||
| − | || | ||
|} | |} | ||
| − | Alle öffentlichen Netzbereiche werden durch die zentrale Firewall geschützt. Folgende Dienste werden | + | Es empfiehlt sich eine Nutzung eines privaten Netzwerkes in der Cloud. IPv4 Konnektivität wird durch einen Router per NAT sichergestellt. IPv6 Netze können bequem über einen Dropdown zu dem Netzwerk hinzugefügt werden. Bitte beachten Sie die Einstellungen in Ihren Sicherheitsrichtlinien. |
| + | |||
| + | === Firewall === | ||
| + | Alle öffentlichen Netzbereiche werden durch die zentrale Firewall geschützt. Folgende Dienste werden standardmäßig durchgelassen: | ||
{| class="wikitable" | {| class="wikitable" | ||
| Zeile 74: | Zeile 75: | ||
! Dienst !! Protokoll !! Port | ! Dienst !! Protokoll !! Port | ||
|- | |- | ||
| − | | | + | | HTTP || TCP || 80 |
|- | |- | ||
| − | | | + | | HTTPS || TCP || 443 |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
|} | |} | ||
| − | Sonderregeln, welche die oben genannten Einschränkungen aufheben, werden nach Absprache eingetragen. Schicken Sie hierzu eine [mailto: | + | Sonderregeln, welche die oben genannten Einschränkungen aufheben, werden nach Absprache eingetragen. Schicken Sie hierzu eine [mailto:cloudcomputing@upb.de Mail an das Ticketsystem (cloudcomputing@upb.de)]. |
==== Zusatzdienste ==== | ==== Zusatzdienste ==== | ||
| + | Neben den normalen Funktionen rund um virtuelle private Netzwerke, wird noch der Dienst [[Cloudcomputing Kochbuch Load Balancer as a Service (LBaaS)|Load Balancer as a Service (LBaaS)]] angeboten. Weitere Hinweise finden sich auf den verlinkten Seite im Cloudcomputing Kochbuch. | ||
| − | + | === Objektspeicher === | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | === | ||
| − | |||
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. | 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. | 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. | ||
| − | |||
| − | |||
Anmerkung: Ein öffentlicher Container erlaubt jedem Zugriff auf Objekte in dem Container, der die öffentliche URL hat. | Anmerkung: Ein öffentlicher Container erlaubt jedem Zugriff auf Objekte in dem Container, der die öffentliche URL hat. | ||
| − | == | + | === Orchestrierung === |
| − | + | Unter Orchestrierung versteht man im Cloudcomputing Context die Komposition und Konfiguration verschiedener Dienste und Komponenten durch eine Vorlage. Für Openstack werden sogenannte Heat Orchestration Templates (HOT) verwenden. Die Templates werden in der Auszeichnungssprache YAML verfasst und bieten die Möglichkeit der Verwaltung von einzelnen Instanzen bis hin zu ganzen Infrastrukturen ([https://en.wikipedia.org/wiki/Infrastructure_as_code Infrastructure as Code]). Es können auch mehrere Templates kombiniert werden, um komplexe Strukturen abzubilden und diese in Openstack einzurichten. | |
| − | |||
| − | |||
| − | Die | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Informationen == | == Informationen == | ||
{{service portal listing|type=Information, Policy}} | {{service portal listing|type=Information, Policy}} | ||
Aktuelle Version vom 17. Mai 2024, 13:38 Uhr
| Cloudcomputing | |
|---|---|
| Ein Dienst des ZIM | |
 Cloudcomputing | |
| Informationen | |
| Zielgruppe | Endbenutzer |
| Das ZIM bietet einen Infrastructure-as-a-Service-Angebot (IaaS) auf der Basis von OpenStack. | |
Der Dienst "Cloudcomputing" in der RDI-Cloud wird zum 17.12.2024 eingestellt.
Bei Frage zur Migration wenden Sie sich bitte direkt an das ZIM. Siehe auch: FAQ: Einstellung des Dienstes RDI-Cloud
Mit dem Dienst RDI-Cloud bietet das ZIM ein Infrastructure-as-a-Service-Angebot (IaaS) auf der Basis von OpenStack. 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
Organisatorisches / Dienst beantragen[Bearbeiten | Quelltext bearbeiten]
Der Cloudcomputing Dienst kann von Lehrenden und Mitarbeiter:innen der Universität über ein Ticket an das Ticketsystem des ZIM beantragt werden. Das ZIM erstellt dann eine Serviceportal Gruppe, die in das Openstack übertragen wird.
Benutzer werden einzelnen Projekten zugeordnet die mit Kontingenten (Rechenzeit, Netzwerk, etc.) versehen sind. Alle Benutzer eines Projektes teilen sich die Kontingente des Projektes. Es können sich nur Benutzer anmelden die auch einem Projekt zugewiesen sind. Neue Projekte können in Abstimmung mit dem ZIM angelegt werden. Schicken Sie hierzu eine Mail an das Ticketsystem (cloudcomputing@upb.de).
Anleitungen[Bearbeiten | Quelltext bearbeiten]
Die Anleitungen umfassen eine ausführliche Quick-Start Anleitung, sowie eine Hand voll Kochbücher für die täglichen Arbeiten in der Cloudumgebung. Unabhängig davon bietet die Umgebung noch eine
Vielzahl von weiteren Funktionen. Eine abschließende Liste von Anleitungen für alle Funktionen kann hier nicht geleistet werden. Haben Sie ein genaues Problem oder eine Idee, lohnt sich eine Suche mit einer Internet-Suchmaschine, gepaart mit den Schlüsselwörtern Openstack, oder Cloudcomputing. In vielen Fällen finden sich gute Denkanstöße oder Erfahrungsberichte die angewendet werden können.
| 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 | • •
|
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 fertige Betriebssysteminstallationen enthalten. Diese werden bei der Instanziierung erweitert durch die maschinenspezifischen Einstellungen (IP-Adresse, Schlüsselpaare, Scripte die nach dem Erzeugen laufen sollen, usw.). Es können auch eigene Abbilder hochgeladen werden, die dann zum Erzeugen von Instanzen genutzt werden können.
Auf der Netzwerkebene werden Instanzen durch Sicherheitsgruppen und deren Zugriffsregeln geschützt. Im Standardfall 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 mehrerer 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. Auch ein bereits vorhandenes SSH-Schlüsselpaar kann 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.
Die "Größe" der virtuellen Maschine (Festplattenplatz, CPUs, RAM) wird bei der Instanziierung festgelegt und ist im Cloudcomputing-Kontext als Varianten (Flavor) zu finden.
Die üblichen Funktionen von Virtualisierungsumgebungen, bspw. das Pausieren von Instanzen, das Anlegen von Schattenkopien usw. werden unterstützt. Über die Funktion Datenträger können virtuelle Festplatten erzeugt werden, die zwischen den Instanzen und sogar zwischen den Projekten verschoben werden können.
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 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.
Standardmäßig bekommt jedes Projekt vier Floating IPs zugewiesen. Zwei dieser IPs können aus dem Internet erreicht werden, die anderen zwei aus dem Hochschulnetz. Die Floating IPs bekommen zudem automatisch einen DNS-Eintrag. Die extern erreichbaren Floating IPs sind unter rdi-cloud-xxx-xxx.uni-paderborn.de erreichbar, die internen unter rdi-cloud-private-xxx-xxx.uni-paderborn.de. Den xxx-xxx-Teil der URL ersetzten Sie durch die letzten beiden Blöcken Ihrer Floating IP-Adresse.
Diese IPs können 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 |
|---|---|
IP-Adressen für Instanzen die
|
uni |
Es empfiehlt sich eine Nutzung eines privaten Netzwerkes in der Cloud. IPv4 Konnektivität wird durch einen Router per NAT sichergestellt. IPv6 Netze können bequem über einen Dropdown zu dem Netzwerk hinzugefügt werden. Bitte beachten Sie die Einstellungen in Ihren Sicherheitsrichtlinien.
Firewall[Bearbeiten | Quelltext bearbeiten]
Alle öffentlichen Netzbereiche werden durch die zentrale Firewall geschützt. Folgende Dienste werden standardmäßig durchgelassen:
| Dienst | Protokoll | Port |
|---|---|---|
| HTTP | TCP | 80 |
| HTTPS | TCP | 443 |
Sonderregeln, welche die oben genannten Einschränkungen aufheben, werden nach Absprache eingetragen. Schicken Sie hierzu eine Mail an das Ticketsystem (cloudcomputing@upb.de).
Zusatzdienste[Bearbeiten | Quelltext bearbeiten]
Neben den normalen Funktionen rund um virtuelle private Netzwerke, wird noch der Dienst Load Balancer as a Service (LBaaS) angeboten. Weitere Hinweise finden sich auf den verlinkten Seite im Cloudcomputing Kochbuch.
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.
Anmerkung: Ein öffentlicher Container erlaubt jedem Zugriff auf Objekte in dem Container, der die öffentliche URL hat.
Orchestrierung[Bearbeiten | Quelltext bearbeiten]
Unter Orchestrierung versteht man im Cloudcomputing Context die Komposition und Konfiguration verschiedener Dienste und Komponenten durch eine Vorlage. Für Openstack werden sogenannte Heat Orchestration Templates (HOT) verwenden. Die Templates werden in der Auszeichnungssprache YAML verfasst und bieten die Möglichkeit der Verwaltung von einzelnen Instanzen bis hin zu ganzen Infrastrukturen (Infrastructure as Code). Es können auch mehrere Templates kombiniert werden, um komplexe Strukturen abzubilden und diese in Openstack einzurichten.
Informationen[Bearbeiten | Quelltext bearbeiten]
| Artikel | Betriebssysteme | Spezielle Zielgruppe |
|---|---|---|
| Cloudcomputing Aktuelle Informationen | Alle | • •
|
