Aktueller Channel Fokus:

Output Management

Storage & Data Analytics Technology Conference 2018

Storage ist der Nano-Motor der IT, aber auf keinen Fall langweilig

| Redakteur: Rainer Graefen

Veranstaltungstermine der Storage & Data Analytics: Stuttgart: 22.3 Hamburg: 10.4 Wiesbaden: 24.4 Köln: 26.4
Veranstaltungstermine der Storage & Data Analytics: Stuttgart: 22.3 Hamburg: 10.4 Wiesbaden: 24.4 Köln: 26.4 (Bild: Vogel IT-Akademie)

Am 22.3. findet in Stuttgart die erste von vier Veranstaltungen der Vogel IT-Akademie zum Themenkomplex Storage & Data Analytics statt. Unser Schwester-Portal Storage-Insider hat mit Professor Dr. Brinkmann gesprochen, der in diesem Interview ganz ausführlich zusammenfasst, was sich im Storage-Umfeld in den nächsten Jahren ändern wird.

Storage gilt vielen Beobachtern der IT-Szene als, nett gesagt, Commodity. Sie halten KI, autonome Vehikel, virtuelle Realitäten und anderes mehr für aufregender, bekommen darüber allerdings nicht mit, dass diese modernen Anwendungen in einer erheblichen Performance-Klemme stecken. Nur massive Änderungen in der Speichertechnik wird das Scheitern vieler Projekte verhindern. Das klingt dramatisch. Wenn Sie diesen Artikel gelesen haben, könnte es sein, dass sie ihre Meinung ändern.

Storage ist der Nano-Motor der IT, aber auf keinen Fall langweilig STORAGE Conference 2018

Mehr Infos zur STORAGE & DATA ANALYTICS Technology Conference 2018

Storage-Insider: Herr Professor Brinkmann, Sie halten demnächst eine Keynote vor den Teilnehmern der Storage & Data Analytics Conference 2018. Was wird Ihr Thema sein?

André Brinkmann: Schwerpunkt des Vortrags werden die Möglichkeiten sein, die sich aus dem Einsatz von Storage Class Memory (SCM) in Server-Architekturen ergeben. SCM verspricht als byte-adressierbare Speichertechnologie die Geschwindigkeitsvorteile von DRAM mit dem nichtflüchtigen Verhalten von Flash und magnetischen Festplatten zu verbinden. Dieses beinhaltet, dass SCM deutlich preiswerter und damit größer als DRAM sein kann und gleichzeitig Daten auch über Ausfälle oder Boot-Vorgänge hinweg sicher speichert. Die Speicherhierarchie wird somit um eine weitere Komponenten mit neuen Eigenschaften erweitert, die es ermöglicht, leistungsfähige Prozessoren schneller mit Daten zu versorgen und somit die Geschwindigkeitsvorteile von Mehrkernarchitekturen zu nutzen.

SCM steht für eine gesamte Klasse von Speichertechnologien, bei der heute noch kein klarer Gewinner vorausgesagt werden kann.

Die Bandbreite der Technologien reicht von

Phase Change Memory (PCM), bei dem über Temperaturänderungen die Leitfähigkeit des zugrundeliegenden polykristallinen Chalcogenids verändert wird,

Race Track-Memory, das magnetische Zellen innerhalb eines Drahtes verschiebt oder

Spin-transfer torque memory (STT-RAM) als eine Ausprägung des magnetorestiven Speichers (MRAM).

Die verschiedenen Technologien haben dabei unterschiedliche Einsatzgebiete. Phase Change Memory ermöglicht eine höhere Dichte als DRAM und kann somit zu einem günstigeren Preis gefertigt werden, wohingegen STT-RAM schnellere Zugriffe als DRAM ermöglicht, aber einen höheren Flächenverbrauch aufweist und somit zum Beispiel als Cache zum Einsatz kommen kann.

Mit einem Halbleiterspeicher wie Flash wird eine "riesige" Latenzlücke zwischen DRAM und Festplatte geschlossen. SCM ist allerdings mehr als noch ein Speichermedium, es ist eine prozessornahe Speicherorganisation. Welche Auswirkungen hat das auf die IT?

André Brinkmann: Eine neue Ebene in der Speicherhierarchie erfordert aber auch immer Anpassungen der zugrundeliegenden Server-Technologien. Flash konnte in Form von SSDs über eine Block-Schnittstelle relativ einfach in bestehende Server-Architekturen eingebunden werden und hat insbesondere bei Datenbankanwendungen schnell Vorteile aufzeigen können.

Eine effiziente Nutzung von Flash als Read-/Write-Speicher hat es aber erfordert, dass die Lebenszeit von Flash durch bessere Algorithmen in dem Flash Translation Layer (FTL) und einen höheren Overprovisioning-Faktor verbessert wurde.

Eine optimierte Geschwindigkeit hat weiterhin die Einführung neuer Schnittstellentechnologien wie NVMe sowie schnellere Kontroller erfordert. Der gesamte Prozess hat dabei mehr als 10 Jahre benötigt und wir sind heute bei mehreren 100.000 IOPS pro SSD und Lebenszeiten von fünf Jahren bei 10 Drive Writes pro Tag angekommen. Diese Daten waren noch vor wenigen Jahren nicht denkbar.

Eine ähnliche Entwicklung wird die Einführung von SCM nehmen. Die Vorteile von SCM können sofort genutzt werden, wenn SCM „einfach“ über eine Blockschnittstelle zur Verfügung gestellt wird. Dabei wird SCM höhere IOPS-Zahlen als Flash aufweisen. Eine Adaptierung von Programmen, so dass alle Eigenschaften von SCM genutzt werden können, wird aber nur über mehrere Server- und Programm-Generationen möglich sein.

Ein Aspekt, der hierbei noch einmal an Bedeutung gewinnen wird, ist die Lokalität von Daten. Ein lesender Zugriff auf eine SSD erfordert heute nur noch wenige zehn µ-Sekunden. Dieser lesende Zugriff liegt dabei in der gleichen Größenordnung wie die Latenz, um Daten zwischen zwei Servern über ein Netzwerk zu bewegen, ein schreibender Zugriff auf eine SSD ist sogar deutlich langsamer. SCM-Technologien versprechen Lese- und Schreiblatenzen von unter 100 ns, der Zugriff auf das Speichersystem ist somit erstmalig deutlich schneller als die

Netzwerklatenz und Leselatenzen können nicht mehr versteckt werden. Die Vorteile von SCM können daher nur dann vollständig genutzt werden, wenn der zugreifende Server den Speicher direkt hostet.

André Brinkmann: Storage Class Memory verbindet zur Zeit Flash-Memory als sozusagen permanenter Speicher mit DRAM. Wie funktioniert das Zusammenspiel zwischen beiden Komponenten? Wann werden wir SCM-Produkte sehen?

Die Gemeinsamkeit von DRAM und SCM ist, dass beide direkt in den Speicherbus des Prozessors eingesetzt werden und über die gleichen Protokolle zugegriffen werden können. Hieraus ergeben sich aber auch direkt die Herausforderungen der neuen Technologie. Der Prozessor sieht und verwaltet SCM (falls nicht als Festplatte gekapselt) auf die gleiche Art und Weise wie Hauptspeicher. Zugriffe auf SCM werden somit direkt in die Cache-Lines des Prozessors geladen, bzw. gesichert und durch diese noch einmal beschleunigt. Während der Rechner korrekt funktioniert, stellt der Prozessor über sein Cache-Protokoll sicher, dass immer die aktuellsten Daten im Hauptspeicher und im SCM genutzt werden.

Dieses sieht bei einem Ausfall der Stromversorgung jedoch komplett anders aus. Bisher waren die Daten in dem Cache und in dem Hauptspeicher einfach verloren und das System musste auf Basis des Dateisystems neu starten. Daten im SCM sind aber nach einem Neustart des Servers weiterhin verfügbar und es ist somit notwendig, dass die Daten in dem SCM zu jedem Zeitpunkt einen konsistenten, d.h. sinnvollen Zustand der zugreifenden Programme abbilden.

Programme, die SCM nutzen, müssen daher die Caching-Protokolle des Prozessors mit betrachten, so dass nicht im schlimmsten Fall ein Teil der im Cache gespeicherten Daten im SCM gesichert werden, die nur unter Zuhilfenahme weiterer, noch im Cache befindlicher Daten Sinn ergeben. Die Konsistenz der Daten kann zum Beispiel durch Cache Flushes und Barrieren bei dem Zugriff auf den Hauptspeicher sichergestellt werden. Ein Flush des kompletten Cache sowie Barrieren sind aber kostspielige Operationen, die den Zugriff auf SCM deutlich verlangsamen würden.

Einige Prozessorhersteller passen daher bereits ihre Cache-Architekturen an, so dass der Programmierer einen fein-granularen Zugriff auf den Cache bekommt und zum Beispiel einzelne Cache-Lines in den Hauptspeicher zurückspielen kann. Weiterhin können diese Flushes so genutzt werden, dass nicht gleichzeitig auch die Cache Line invalidiert wird und somit Daten immer wieder aus dem SCM geladen werden müssen, die eigentlich bereits im Cache gespeichert sind.

Eine weitere Herausforderung ist die Sicherheit bei der Nutzung von SCM, insbesondere im Cloud-Umfeld. Daten, die einen Neustart eines Rechners überleben, können prinzipiell in den Adressraum eines unprivilegierten Prozesses eingebunden werden, wenn diese von dem Betriebssystem vor der Vergabe nicht überschrieben werden.

SCM als Hauptspeicherergänzung ist bisher nur in relativ kleinen Kapazitäten erhältlich. Eine interessante Alternative sind DRAM-Bausteine, die im Fall eines Stromausfalls durch Flash-Speicher gepuffert werden. Weiterhin ist die Unterstützung durch Prozessoren und Betriebssysteme noch gering. Produkte, die auf „echtem“ SCM basieren, werden bereits seit längerem angekündigt, werden aber bestenfalls in kleinen Kapazitäten ausgeliefert.

Eine alternative Bereitstellung von SCM ist die Kapselung über eine Block-Schnittstelle. Erste Systeme werden hier bereits von Herstellern angeboten. SCM kann dann wie Flash über NVMe als „Festplatte“ bereitgestellt werden, ohne dass die Programme oder das Betriebssystem hierfür geändert werden müssen. Ein Großteil der Geschwindigkeitsvorteile von SCM gegenüber Flash kann dann natürlich nicht genutzt werden, da der Overhead eines Dateisystems und der Blockschnittstelle diese wieder aufheben.

Vorteile von SCM gegenüber Flash ergeben sich aber auch in diesem Fall. Flash kann eine hohe Anzahl von IOPS nur dann erzielen, wenn jederzeit viele Anfragen auf alle Kanäle und Chips auf der SSDs erfolgen. Dieses liegt daran, dass einzelne Anfragen eine relativ hohe Latenz haben und die Flash-Bausteine die Geschwindigkeit einer SSD limitieren. Bei SCM-basierten Speichersystemen hingegen ist der Kontroller die limitierende Komponente und die Latenz der Zugriffe ist gering. Selbst bei wenigen parallelen Zugriffen kann somit eine geringe Latenz und prinzipiell eine hohe IOPS-Anzahl ermöglicht werden.

Können Anwendungen aus dieser neuen Speichertechnik ohne weitere Modifikationen Vorteile ziehen?

André Brinkmann: Es bieten sich zwei Möglichkeiten, aus dem Einsatz von SCM auch ohne weitere Modifikationen der Anwendungen direkte Vorteile zu erzielen.

Wie bereits im Rahmen der vergangenen Ausführungen angemerkt, kann SCM über eine Blockschnittstelle wie eine Festplatte bereitgestellt werden. Die Protokolle und Konsistenzeigenschaften entsprechen somit denen einer Festplatte oder einer SSD und die Anwendungen können direkt von den geringeren Latenzen und einer höheren Bandbreite des SCM profitieren. Latenzen bewegen sich in diesem Fall aber immer noch im µs-Bereich, da der Software-Stack des Dateisystems und der Blockebene durchlaufen werden muss.

Verbesserungen versprechen hier direct access (DAX)-Erweiterungen von Dateisysteme, die Dateien in den virtuellen Speicher der Anwendungen einblenden, so dass nur noch Metadatenoperationen durch das Betriebssystem verwaltet und somit ein teurer Sprung in den Kernelkontext nur selten vorgenommen werden muss. Der eigentliche Datenzugriff erfolgt dann wie der Zugriff auf den Hauptspeicher. Shadow Paging, das Daten nicht direkt überschreibt, verspricht hier, die Konsistenz der Daten ohne Mitwirkung der Anwendungen sicherzustellen. Daten werden von dem Dateisystem erst dann aktualisiert, wenn die Anwendung die Datei schließt oder eine Synchronisierung vornimmt. Diese Aktualisierungen können dann atomar erfolgen, indem Zeiger in dem Dateisystembaum einfach umgehängt werden.

Eine weiter Möglichkeit zur transparenten Nutzung von SCM besteht darin, dass die Persistenzeigenschaft von SCM nicht genutzt wird und SCM einfach als „billige“ Hauptspeichererweiterung eingesetzt wird. Server können somit mit mehr Hauptspeicher ausgestattet werden, ohne dass hochpreisige DRAM-Chips höchster Kapazität eingebunden werden.

Die Steigerung der Geschwindigkeit hängt dabei aber stark von der Anwendung und auch von dem verwendeten Caching-Algorithmus ab. SCM ist deutlich schneller als Flash und die Zugriffsgeschwindigkeiten bewegen sich in einer vergleichbaren Größenordnung wie die Zugriffszeiten auf Hauptspeicher. Dennoch sind die meisten (und insbesondere die preiswerten) SCM Technologien beim Lesen und Schreiben langsamer als Hauptspeicher und somit würde sich eine Anwendung verlangsamen, wenn sie vorrangig auf dem SCM arbeitet. Der Unterschied kann beim Schreiben dabei noch einmal größer als beim Lesen sein.

Es ist somit notwendig, dass ein Caching-Algorithmus Daten zwischen Hauptspeicher und SCM verschieben kann, so dass hochfrequent zugegriffene Daten im Hauptspeicher liegen und weniger wichtige Daten oder Daten, die vorrangig gelesen werden, im SCM gesichert sind. Die Fähigkeit des Caching-Algorithmus, Daten derart aufzuteilen, hängt aber auch an den Eigenschaften der Anwendungen. Falls diese ein zufälliges Zugriffsmuster aufweist und keine Lokalität sicherstellen kann, kann sich der Algorithmus auch nicht an die Zugriffsmuster anpassen.

Eine weitere Eigenschaft von SCM ist in diesem Zusammenhang zu betrachten. Verschiedene SCM Technologien, wie Phase Change Memory, altern wie Flash bei Schreibzugriffen. Im Gegensatz zu Flash, dass über ein Wear-Leveling und eine gegenüber dem Hauptspeicher langsame Schnittstelle verfügt, kann aber auf SCM deutlich schneller zugegriffen werden und es ist somit möglich, SCM in kürzester Zeit altern zu lassen. Erfahrungen mit dem realen Einsatz von SCM werden zeigen, inwieweit Speicherallokatoren im Betriebssystem und im Virtual Memory Management in der Lage sein werden, diesen Alterungsprozess in Grenzen zu halten und über den gesamten SCM zu verteilen.

Passen SCM und SDS zusammen? (Highspeed im Server versus Massenspeicher über Ethernet)

André Brinkmann: Die Zusammenführung von SCM und Software-defined Storage (SDS) scheint auf den ersten Blick widersprüchlich. SDS ermöglicht es prinzipiell, Speichersysteme unabhängig von einem Hardware-Hersteller preiswert zu skalieren und bildet in der Speicherhierarchie von Unternehmen eher eine untere Ebene ab, an die teilweise auch entsprechend geringere Verfügbarkeits- und Geschwindigkeitsanforderungen geknüpft werden. Bei SCM handelt es sich auf der anderen Seite um den schnellsten (und teuersten) persistenten Speicher in einem Rechenzentrum.

SCM ist aber per Definition durch seine enge Integration in die Rechner Software-defined. Sowohl Virtualisierungs-, als auch Cloud-Umgebungen müssen SCM verstehen, in ihre Management-Infrastruktur einbinden und Daten zwischen den einzelnen Hierarchieebenen migrieren, um SCM auch als persistenten Speicher nutzen zu können.

Neben diesem Mehraufwand bei der Integration von SCM in SDS-Strukturen bieten sich hierdurch aber eine Reihe von Chancen, die aber auch ein neues Denken bei dem Aufbau von SDS und Rechenzentren im Allgemeinen erfordern. Neben der einfachen Nutzung als Cache für Daten bietet SCM die Möglichkeit, eine engere Kopplung zwischen Rechen- und Speicherressourcen voranzutreiben. (Kleinere) Anwendungen und Micro-Services können bei Bedarf direkt zu den auf SCM gespeicherten Daten migriert werden und von der hohen Zugriffsgeschwindigkeit auf das SCM profitieren.

Dabei scheinen auch für den Aufbau von SCM-Pools Objektspeicher eine interessante Alternative, da Objektspeicher das Rechtemanagement direkt in den Objekten speichern können und die zu einem Objekt gehörigen Daten auf wenigen Servern gesichert werden können. Die Verwaltung der Objektspeicher wiederum kann auf die Konzepte der Peer-to-Peer-Systeme und die dynamische Datenverteilung zurückgreifen, die auch die Grundlage vieler SDS-Systeme bilden. Das Speichersystem wird hierdurch, insbesondere bei der Nutzung von Micro-Services, zu einem Server, eine klare Trennung zwischen beiden Eigenschaften wird unmöglich.

SCM kann aber auch direkt einige der Nachteile von SDS-Systemen und hier insbesondere von objekt-basierten Systemen abmildern. Klassische Dateisysteme haben über ihre Verzeichnisse eine "natürliche" Ordnung bei dem Zugriff auf Daten, da zusammengehörige Daten häufig in dem gleichen Verzeichnis abgelegt werden. Die Skalierbarkeit von Objektspeichern wird aber gerade durch das Aufbrechen der Strukturen gewonnen und flache Objektspeicher kennen den semantischen Zusammenhang zwischen verschiedenen Objekten nicht mehr. Sie können daher zusammengehörige Metadaten nur sehr schwer gemeinsam cachen.

Auch wenn Metadaten heutzutage einen schlechten Ruf genießen, ohne diese Abstraktionsebene von Inhalten, wird man die "Stecknadel im Heuhaufen" nicht finden können.

André Brinkmann: Das stimmt, aber SCM ermöglicht es nun, mehr Metadaten im Hauptspeicher oder auf sehr schnellem Sekundärspeicher zu halten und somit die Zugriffszeiten auf diese Metadaten deutlich zu reduzieren. Die Reaktionszeiten von SDS-Systemen sollten sich somit deutlich verbessern lassen.

Im Augenblick sieht es so aus als ob die Verbindung zwischen Prozessor und Speicher wie auch die Entwicklungsgeschwindigkeit bei der Anwendungsprogrammierung weitere Innovationen verhindern, die eigentlich für die Datenanalyse notwendig wären.

Datenanalysen sind naturgegeben durch die Geschwindigkeit limitiert, mit der die beteiligten Prozessoren mit Daten versorgt werden können. Insbesondere bei komplexen Datenzusammenhängen, die nicht-sequentielle Zugriffe auf die Daten erfordern, kommen SSDs und magnetische Festplatten schnell an ihre Grenzen und bilden den Flaschenhals des Gesamtsystems.

Reine In-memory Datenbanken und Datenanalyseumgebungen wie Spark ermöglichen es, diesen Flaschenhals nach dem Einlesen der Daten zu umgehen. Auf Spark aufsetzende Pakete wie Alluxio bilden einen zusätzlichen Cache, der das Rückschreiben von Daten auch zwischen den verschiedenen Phasen einer Datenanalyse verhindert, indem er die Hauptspeicher der beteiligten Knoten in einem Pool zusammenfasst und Daten in diesem Pool speichert. Zugriffe auf persistenten Speicher können hierdurch häufig komplett umgangen werden.

Klassische Datenanalysen profitieren von SCM daher nur insofern, dass sich der Hauptspeicher deutlich vergrößern lässt. Vergleichbares gilt für das Trainieren großer neuronaler Netze. Durch mehr Hauptspeicher können mehr Gewichte trainiert und komplexere Netze gebaut werden. Auch können mehr Trainingsdaten im Hauptspeicher gehalten werden. Negativ für SCM wirkt sich hier aus, dass mittlerweile selbst der Hauptspeicher für das Trainieren neuronaler Netze zu langsam erscheint und Beschleuniger sowie GPUs mit High Bandwidth Memory (HBM) ausgestattet werden, um Daten noch schneller in die Prozessoren zu bringen. Hier kann SCM nur als weitere Caching-Ebene dienen.

Generell hat SCM aber dazu beigetragen, dass im akademischen und industriellen Umfeld wieder verstärkt über die zugrundeliegenden Algorithmen und Protokolle nachgedacht wird. Es wurden verschiedenste Datenstrukturen entwickelt, die konsistent und ohne einen Zwischenschritt über den Hauptspeicher effizient im SCM persistiert werden können. Insbesondere im Datenbankumfeld müssen Transaktionen somit nicht mehr explizit über ein sekundäres Speichersystem persistiert werden, sondern sind sofort in diesem erweiterten „Hauptspeicher“ gemäß der ACID-Anforderungen gesichert. Latenzzeiten von Datenbanken können somit noch einmal deutlich reduziert werden.

Offen ist heute noch, wie sich SCM auf die Entwicklung von Programmiersprachen auswirkt. Selbst Hardware-nahe Programmiersprachen wie C abstrahieren von der Registerebene oder den Caches und bieten diese dem Programmierer transparent an. Dieses hat dazu geführt, dass zum Beispiel in der Vergangenheit Vektor-Erweiterungen in Prozessoren wie SSE und AVX vorrangig über Maschinenbefehle angesprochen werden mussten, wenn sich der Programmierer nicht auf den Compiler verlassen wollte oder konnte. Dieses erhöht die Komplexität der Anwendungen und macht diese gleichzeitig weniger portabel und erhöht den Pflegeaufwand. Es zeichnet sich ab, dass sich für C (und weitere Programmiersprachen) eine Standardisierung bei der Programmierung von Vektor-Erweiterungen herauskristallisiert, die eine HW-unabhängige Code-Entwicklung ermöglicht.

Vergleichbare HW-unabhängige Konzepte für das Ansprechen von SCM fehlen zum jetzigen Zeitpunkt noch. Die hohe Komplexität der Konsistenzprotokolle sowie die nicht einfach detektierbaren, subtilen Fehlerzustände, die eventuell bei einem Ausfall des Rechners auftreten können, erfordern aber eine Unterstützung der Anwendungsentwickler direkt aus den Programmiersprachen heraus.

Ist SCM eine Vorstufe für NVMe over Fabric? Kommt der Speicherpool wieder zurück?

André Brinkmann: NVMe wurde entwickelt, um die Technologievorteile moderner SSDs gegenüber magnetischen Festplatten nutzen zu können und die Geschwindigkeit nicht bereits in der Schnittstelle zum Speicher zu verlieren. Vorteile von NVMe gegenüber SATA und SAS sind insbesondere die Unterstützung einer höheren Parallelität der Zugriffe durch eine Reduzierung notwendiger Locking-Operationen und die direkte Nutzung des PCI-Busses. Blockbasierte SCM-Lösungen können somit ebenfalls von diesem neuen Protokoll profitieren, sie sind sogar auf die zugrundeliegenden Neuerungen angewiesen.

Werden Speicherpools über ein Netzwerk angeboten, ist die Nutzung von RDMA-Konzepten, die auch in NVMe over Fabric vorgesehen sind, die Grundlage, dass die CPUs in den Speichersystemen nicht zum Flaschenhals werden. Der Erfolg hierauf aufbauender Speicherpool-Konzepte wird aber sicherlich von der Preisgestaltung der Hersteller abhängen. Sollte die Preisentwicklung für SCM ähnlich attraktiv wie für Flash verlaufen, ist es möglich und wahrscheinlich, dass All-SCM-Arrays vergleichbar der All-Flash-Arrays besonders hohe Leistungsanforderungen im Storage-Bereich abdecken werden.

SCM als byte-adressierbare Speichertechnologie kann auf der nächst höheren Ebene in der Speicherebene dazu dienen, große, verteilte Hauptspeicherkonzepte umzusetzen, die ebenfalls über Pool-Konzepte an einzelne Anwendungen verteilt werden. An dieser Stelle spielt aber die Lokalität wieder eine sehr große Rolle, da entfernte Zugriffe 10 bis 100-mal langsamer als lokale Zugriffe sein werden.

Kommentare werden geladen....

Sie wollen diesen Beitrag kommentieren? Schreiben Sie uns hier

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45209034 / Summits & Exclusives)