zhu difeng - Fotolia
Das ist beim Einsatz von Docker-Containern wichtig
Container benötigen oft dauerhaft Speicher. Wir schauen uns die wichtigsten Möglichkeiten dafür an, darunter Docker-Volumes und Bind-Mounts sowie Docker-Volume-Plugins.
Container sind ein heißes Thema. Die Container-Technologie, für die Docker am gebräuchlichsten ist, ermöglicht die Bereitstellung von Anwendungen als eine Sammlung von Prozessen und nicht als vollständige virtuelle Maschine (VM).
Docker hat ein Ökosystem entwickelt, das die schnelle Entwicklung von Containern ermöglicht und eine Bibliothek von Anwendungsabbildern (den Docker Hub), eine Ausführungsumgebung (die Container-Engine) und eine Reihe von Orchestrierungsfunktionen mit nativer Swarm-Anwendung und Unterstützung für Kubernetes verbindet.
Anfangs wurde erwartet, dass Container kurzlebig sind und vielleicht nur für einige Minuten oder Stunden ausreichen. Typische Einsatzmöglichkeiten waren Anwendungen aus Microservices und für webbasierte Anwendungen.
Es wurde jedoch immer offensichtlicher, dass das Container-Ökosystem für die Bereitstellung von viel langlebigeren Anwendungen, einschließlich traditioneller und NoSQL-Datenbanken, genutzt werden kann. Es ist möglich, eine Reihe von Systemen zu erstellen, die von typischen dreistufigen bis zu komplexeren webbasierten Anwendungen reichen.
Je nachdem, wie die Technologie implementiert ist, kann die Datenausfallsicherheit in der Anwendung vorhanden sein oder von der Infrastruktur bereitgestellt werden. Aus diesem Grund haben wir festgestellt, dass in der Speicherschicht ständige Verfügbarkeit (Persistenz) erforderlich ist, um sicherzustellen, dass Daten über Containerinstanziierungen hinweg verfügbar sind.
Wir sollten nicht vergessen, dass mit der Weiterentwicklung der Containertechnologie auch andere Anforderungen bestehen. Einige davon sind noch nicht vollständig entwickelt, werden aber im Laufe der Zeit wichtiger.
- Persistenz - Bei der Persistenz muss sichergestellt werden, dass Daten über die Lebensdauer des Containers hinausreichen und Resilienz zwischen den Hosts aufweisen. Dies ist wichtig, wenn die Anwendung keine integrierte Ausfallsicherheit aufweist oder ein Container automatisch zwischen Hosts verschoben wird.
- Sicherheit - Wie werden Anwendungsdaten gesichert? Diese Anforderung umfasst die Notwendigkeit, den Zugriff von jedem Container und anderen externen Diensten (zum Beispiel Backup) zu verschlüsseln und zu steuern.
- Leistung - Wie wird die I/O-Leistung für die von den einzelnen Containern verwendeten Daten verwaltet? Es müssen I/O-Durchsatz und -Latenz verwaltet werden.
- Schutz - Der Datenschutz gilt weiterhin in der Containerwelt. Dies umfasst den physischen Schutz von Hardwarefehlern wie Laufwerk oder Medien und die Fähigkeit, größeren Infrastrukturausfällen standzuhalten.
- Mobilität - Eine der vielleicht interessantesten Herausforderungen besteht darin, die Verfügbarkeit von Daten über mehrere Standorte hinweg zu verwalten, da Container in privaten und öffentlichen Rechenzentren genutzt werden.
Docker Volume versus Bind Mount
Die Möglichkeiten für Speicher und Container hängen von der beabsichtigten Verwendung auf der Containerebene ab.
Innerhalb des Docker-Ökosystems kann Speicher von dem Host bereitgestellt werden, der den Container ausführt. Dieser Speicherplatz wird als neu erstelltes Dateiverzeichnis bereitgestellt (das beim Start des Containers erstellt wird) oder als Verzeichnis, das bereits auf dem Host vorhanden ist.
Die frühere Technik wird als Docker-Volume bezeichnet. Dies ist im Wesentlichen ein von Docker verwaltetes Verzeichnis (normalerweise unter dem Ordner /var /lib /docker /volumes).
Docker-Volumes können im Voraus oder zum Zeitpunkt des Startvorgangs eines Containers erstellt und von mehreren Containern gemeinsam genutzt werden. Es ist auch möglich, Volume-Plugins zu verwenden, auf die wir im Folgenden näher eingehen werden.
Die zweite Option besteht darin, ein Verzeichnis auf dem Host zum Zuordnen in einen Container zu verwenden, auch Bind-Mount genannt. Dieser Prozess kann schnell und flexibel sein, wenn die Containerdaten nicht weiter verfügbar sein müssen, wenn der Host nicht mehr existiert.
Ein Bind-Mount kann im Root-Dateisystem oder auf einem anderen Gerät erstellt werden, das mit dem Host verbunden ist, zum Beispiel ein lokaler Speicher im Host/Server oder eine freigegebene Speicher-LUN. Es ist sogar möglich, eine NFS-Freigabe in einen Host einzubinden und damit auch Daten zu speichern.
Container, die Bind-Mounts verwenden, haben jedoch Lese-/Schreibzugriff auf das Dateisystem, mit dem sie verbunden sind. Dies macht es möglich, Systemverzeichnisse direkt in den Container einzuhängen, was wahrscheinlich nicht gut ist. Sie müssen also vorsichtig sein, wenn Sie die Parameter eines Bind Mount angeben.
Die Auswahl, ob Bind-Mounts oder Volumes verwendet werden sollen, hängt von der Verwendung ab. Die Bind-Mount-Technik bietet die Möglichkeit, Daten zwischen Host und Container zu teilen, während Volumes viel mehr Unabhängigkeit von der Host-Konfiguration selbst bieten.
Docker-Volume-Plug-ins
Was passiert, wenn Sie Daten von einem externen Speicherarray verwenden möchten?
Die Verwendung von gemeinsam genutztem Speicher bietet die Möglichkeit, Host-Fehler zu überstehen. In einem Container-Kontext benötigt die Verwendung von gemeinsam genutztem Speicher ein wenig Aufwand. Der Grund dafür erfordert zu verstehen, warum Shared-Storage-Plattformen entwickelt werden.
Herkömmliche SANs (Storage Area Networks) entstanden aus der Notwendigkeit, Speicher zu zentralisieren, der auf viele physische Server verteilt war. Die Zentralisierung bot ein besseres Management, Sicherheit, Wartung und Effizienz. Eine physische LUN (Logical Unit Number) oder ein Volume aus einem freigegebenen Array wird beispielsweise einem physischen Adapter im Host zugeordnet und verborgen.
Als wir zur Virtualisierung übergingen, wurde der Speicher dem Hypervisor zugeordnet, von dem aus die LUN oder das Volume aufgeteilt wurde. Eine physische LUN wird beispielsweise zu einem Datenspeicher auf VMware vSphere. In der Regel ist in diesem Datenspeicher jede VM-Datei (Velocity Template) auch eine VMDK-Datei (Virtual Machine Disk). Eine Dateifreigabe vom NAS würde VM-Verzeichnisse und VMDK-Dateien in diesen Verzeichnissen enthalten.
Aus einer Containerperspektive erscheint ein Speicher, der einem physischen Host zugeordnet ist, als ein Blockgerät, das mit einem Dateisystem formatiert werden muss. Dieses Dateisystem kann dann in den Container eingebunden werden, um dauerhaften Speicher bereitzustellen.
All dies klingt ziemlich umständlich und so hat Docker Volume-Plug-ins eingeführt, um den Prozess effektiver zu verwalten. Anbieter schreiben Plug-in-Software in die Docker-Spezifikation, die den Prozess der Erstellung der LUN/Volume automatisiert und sie dem Host und schließlich dem Container korrekt zuordnet.
Externe Speicher – Vor- und Nachteile
Natürlich bietet die Verwendung von externem Speicher die Vorteile von Resilienz und Persistenz. Wenn der Behälter nicht mehr existiert, kann das Volumen wieder zugeteilt werden. Wenn der Host ausfällt, kann die LUN/Volume verschoben und auf einem anderen Host bereitgestellt werden. Die Leistung kann auf LUN-Ebene angewendet werden, wo Systeme Funktionen wie QoS (Quality of Service) bieten.
Die Implementierung von Sicherheit ist ein wenig komplizierter. Ein externes Volume kann einem bestimmten Container-Host zugeordnet werden. Es gibt jedoch keine systeminterne Sicherheit, um einem Container ein Volume zuzuweisen, das nicht von der Host- und Container-Orchestrierungssoftware bereitgestellt wird. Also müssen Kubernetes oder Swarm die Aufgabe übernehmen.
Supplier Support kommt in Form von Docker Plugins. Die meisten der führenden Speicher-Array-Hersteller bieten Plug-in-Unterstützung, darunter: Pure Storage, NetApp, HPE (3PAR und Nimble) und EMC durch Rex-Ray und das EMC Code-Projekt.
Es gibt aber auch Plugins von Start-ups wie Portworx und StorageOS, die Plattformen speziell für den Containerspeicher entwickelt haben. Plattformanbieter wie Red Hat bieten Unterstützung durch GlusterFS.
Es gibt auch einige Plug-ins von Drittanbietern, die Zugriff auf lokalen Speicher und NFS-Ressourcen bieten. Eine Liste wird auf der Docker-Plug-ins-Seite zur Verfügung gestellt, obwohl diese nicht sehr oft aktualisiert wird.
Kubernetes wird somit immer mehr zum Standard für den Einsatz von Containern. Das Kubernetes-Ökosystem bietet Volumenunterstützung, die nicht an Docker gebunden sein muss. Ein Kubernetes-Volume existiert für die Lebensdauer eines Pods, das mehrere Container für die Beschreibung einer Anwendung umfasst.
Heutzutage enthält der Kubernetes Volume-Support generische NFS-, iSCSI- und Fibre-Channel-Unterstützung sowie Cloud-spezifische Angebote wie Microsoft Azure und Supplier Support, einschließlich Portworx, ScaleIO, GlusterFS und StorageOS.
Zusammenfassung
Die meiste Unterstützung für externen Speicher ist volumenbasiert und erleichtert nicht gerade die Übertragung von lokalen Daten in die Cloud.
Wir erwarten, dass sich die Angebote verbessern und mehr globale Dateisysteme verwendet werden, um die Persistenz von Daten in Docker zu ermöglichen.
Block-Geräte werden eine kurzfristige Lösung bieten, wenn die Anforderungen ausgereift sind und Dateisysteme stärker angenommen werden.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
