28.08.2024 | Stefan Achter
Lizenz: pickup © AdobeStock
Schwarmverhalten beschreibt abstrakt die kollektive Bewegung vieler Individuen, die sich eigenständig fortbewegen. In mathematischen Modellen wird dies als emergentes Verhalten betrachtet, das aus einfachen Regeln entsteht, denen jedes Individuum folgt, ohne dass eine zentrale Steuerung erforderlich ist.
Biomimikry oder Biomimetik ist die Nachahmung von natürlichen Modellen, Systemen und Elementen zur Lösung komplexer menschlicher Herausforderungen. (Übersetzt aus Wikipedia)
Die patentierte Methode von DataCore zur Synchronisation gemeinsamer Clusterparameter basiert auf einem KI/ML-Algorithmus, der in der Natur seit über 1,2 Milliarden Jahren verwendet wird. Unsere grundlegende Anwendung von Biomimikry liegt jedoch im Design unserer massiv-parallelen Clustertechnologie: einem intelligenten ML-Verhalten eines Schwarms, bestehend aus nahezu unabhängigen Einzelkomponenten – den Servern –, die nur wenige Sensoren, Parameter und Vorgaben gemeinsam nutzen.
Maschinelles Lernen ist ein Bereich der Informatik, der statistische Techniken einsetzt, um Computern das „Lernen“ zu ermöglichen, d. h., ihre Leistung bei bestimmten Aufgaben durch Erfahrung kontinuierlich zu verbessern, ohne explizit dafür programmiert zu sein. (Übersetzt aus Wikipedia)
Während geometrisch inspirierte Clusterkonfigurationen theoretisch Sinn ergeben mögen, stellt sich ein Cluster in der Praxis oft als raues, nicht deterministisches Umfeld heraus. In kritischen Momenten überleben nur einfache Regeln und Konzepte, während komplexere unter ihrer eigenen Last zusammenbrechen. Bei der Swarm-Architektur von DataCore gilt selbst in einem Split-Brain-Szenario: Solange die Daten zugänglich sind, können sie auch gelesen werden. Temporäre Effekte durch Änderungen der Clusterkonfiguration haben keine Auswirkungen auf diese Grundregel. Da die Server unabhängig voneinander arbeiten, können sie weder die Struktur noch einander beeinträchtigen. Ein Schwarm bleibt ein Schwarm, selbst wenn einige seiner Mitglieder ausfallen, während ein Ring seine Integrität verliert, sobald einige seiner Segmente verschwinden. Das bedeutet nicht, dass DataCore Swarm völlig immun gegen Hardwareausfälle ist. Die Software agiert jedoch autonom und vernunftbasiert. Wie in der Natur haben lebenswichtige Funktionen Vorrang, während weniger wichtige vorübergehend in den Hintergrund treten. Ein Split-Brain-Szenario beeinträchtigt die grundlegenden Funktionen des Schwarms – das Lesen und Schreiben von Objekten – nicht, kann jedoch zu einer temporären Überreplikation führen. Sobald die volle Konnektivität wiederhergestellt ist, kehren alle sekundären Funktionen zurück und überschüssige Replikate werden entfernt. So werden die Daten während einer „Krisenzeit“ sogar besser geschützt als gewöhnlich.
Damit eine Swarm-Architektur effizient funktioniert, müssen die Server einfach und agil sein – Anforderungen, die DataCore Swarm perfekt erfüllt.
Bei der Definition unserer Server haben wir uns auf Standardhardware mit Betriebssystem konzentriert. Alles Unnötige, insbesondere bei der Software, haben wir weggelassen und nur das absolut Notwendige hinzugefügt. Der verbleibende Software-Stack einschließlich des Betriebssystems wurde in ein Single-Image gepackt, das beim Starten in den RAM geladen wird. Dieses Bare-Metal-Deployment erfolgt entweder über das PXE-Netzwerk oder von einem einfachen USB-Stick. Sämtliche Software bleibt im RAM, es gibt keine Installation auf der Festplatte, keine Patches und keine Upgrades. Der gesamte Festplattenspeicher steht ausschließlich den zu speichernden Daten zur Verfügung. Nach dem Starten wird das x86-System zu einem abgeschlossenen Spezialsystem, das nur unser RESTful HTTP-Subset und SNMP für das Management versteht. Es gibt keine Accounts auf einem Produktivserver, was bedeutet, dass die Serversicherheit nicht durch SSH oder andere Remote-Logins beeinträchtigt werden kann.
Die Festplatten werden „raw“ genutzt – ohne fehleranfällige Dateisysteme, die die Performance oder Speichereffizienz beeinträchtigen könnten. Weder Inodes noch B-Trees verschwenden Festplattenspeicher. Unserer Ansicht nach hat alles, was nicht Nutzinhalte darstellt, nichts auf der Platte zu suchen. Millionen kleiner Objekte auf einer einzelnen Festplatte? Kein Problem! Alle Informationen im Cluster sind innerhalb von Mikrosekunden über „strictly zero“ IOPS auffindbar, dank eines blitzschnellen, verteilten, RAM-basierten Index, der beim Starten aus einem effizienten linearen Journal geladen wird. Objekte werden mit ihren Metadaten gespeichert und zur Steigerung der Robustheit physisch gekapselt.
Server werden einfach über Gbit oder 10 Gbit/s-Ethernet zu einem Cluster verbunden. Dank automatischer Erkennung, Bereitstellung und intelligenter Lastverteilung ist selbst bei grundverschiedenen Servern unterschiedlicher Hersteller keine Konfiguration erforderlich. Das koordinierte Clustermanagement erfolgt über SNMP oder eine Webkonsole, auf die von jedem Server aus zugegriffen werden kann. Da alle Server denselben Code ausführen und dieselben Aufgaben übernehmen, kann jeder Server Lese-, Schreib-, Lösch- oder Informationsvorgänge an jedem Objekt im Cluster ausführen, identifiziert über die UUID (Universally Unique Identifier). Es werden sowohl von DataCore Swarm generierte 128-Bit-Nummern als auch von Anwendungen generierte S3-kompatible Objektkennungen nativ und gleichzeitig unterstützt. Server A kann einfach nach Objekt X gefragt werden. Er findet automatisch heraus, dass sich die am leichtesten zugängliche Instanz von X derzeit auf Server B befindet und leitet die HTTP-Anfrage an B weiter – ohne Umweg über einen Proxy. Schreibvorgänge funktionieren nach demselben Prinzip. Wenn Sie bei A anfragen, findet A für Sie den optimalen Server B, auf dem Objekt X, basierend auf einem durch maschinelles Lernen entwickelten Datenparadigma, gespeichert werden sollte. Die HTTP-Umleitung erfolgt automatisch. Diese Standardoperationen sind für jeden HTTP-Stack oder Webbrowser unkompliziert.
Objekte werden durch Replikation oder Erasure Coding vor Datenverlust geschützt. Einfach ausgedrückt ist Erasure Coding für Objektspeicher ebenso wertvoll wie RAID für Blockspeicher, da es bei einem Festplattenausfall den Datenverlust verhindert. Bei der Replikation erfolgt der Schutz durch die Speicherung von zwei oder mehr Kopien jedes Objekts auf verschiedenen Servern im Cluster. Sind gemäß Richtlinie drei Replikate festgelegt, können zwei beliebige Festplatten oder Server ausfallen, ohne dass Datenverlust oder eine Einschränkung der Verfügbarkeit auftritt. In DataCore Swarm können die Replikationsrichtlinien (1, 2, 3, 4 …) während des Betriebs frei gewählt, auf Objektbasis voreingestellt oder im Laufe der Zeit automatisch geändert werden – bei Bedarf sogar mehrfach –, wenn eine entsprechende Richtlinie in einem Lifepoint festgelegt wird. Wenn gewünscht, kann die Option „Replicate-on-write“ aktiviert werden, die auf Kosten eines geringen Zeitverlusts beim Schreiben prüft, ob ein Objekt tatsächlich in zwei separaten Servern vorhanden ist, bevor die Schreibbestätigung erfolgt.
Erasure Coding (EC) erweitert die replikationsbasierte Implementierung, indem eine wählbare Anzahl von Datensegmenten und Paritätssegmenten pro Objekt erstellt und auf verschiedene Server verteilt wird. Dies gewährleistet eine höhere Beständigkeit (Schutz vor Datenverlust) und benötigt weniger Speicherplatz als Replikation, erfordert jedoch eine höhere CPU-Leistung bei der Erstellung und Wiederherstellung. Im Gegensatz zu Wettbewerbsprodukten ermöglicht DataCore Swarm die freie Wahl des EC-Schemas für jedes beliebige Objekt im Cluster. Bei einem „5 von 7“-Schema werden beispielsweise fünf Datensegmente und zwei Paritätssegmente über sieben Server verteilt. Fünf beliebige Segmente reichen aus, um das Datenobjekt wiederherzustellen. Das bedeutet, dass zwei gleichzeitige Festplatten- oder Serverausfälle ohne Datenverlust verkraftet werden können.
Der Schutz, den ein Redundanzschema in einer Speicherinfrastruktur bietet, wird als Beständigkeit bezeichnet und in „Neunen“ ausgedrückt. Je mehr Neunen, desto höher die Wahrscheinlichkeit, dass ein bestimmtes Objekt innerhalb eines Jahres erhalten bleibt. Elf Neunen entsprechen einer Wahrscheinlichkeit von 99,999999999%. Dies ist auch die Haltbarkeit, die Amazon für seinen AWS S3-Dienst im Standard-Redundanzformat angibt, bei dem nur drei Replikate in verschiedenen Rechenzentren gespeichert werden. Mit Swarm Erasure Coding (EC) kann die Anzahl der Neunen verdoppelt werden, während nur die Hälfte des Festplattenplatzes, des Rechenzentrumsstandorts, des Stromverbrauchs, des Kühlbedarfs und anderer damit verbundener Kosten benötigt wird. In der Regel basieren EC-Modelle auf der Objektklasse, was die Verwaltung ganz unterschiedlicher Speicher- und Performance-SLAs innerhalb desselben DataCore Swarm-Clusters ermöglicht. So kann ein breites Spektrum an Anwendungsfällen und Anforderungen abgedeckt werden. Mit einem entsprechend dimensionierten Netzwerk und geeigneter CPU-Hardware erreicht DataCore Swarm durch paralleles Striping mehrerer EC-Segmente auf verschiedene Server für seine I/Os einen weitaus höheren Durchsatz, als es mit einer einzelnen Festplatte möglich wäre.
Im Gegensatz zu Wettbewerbsprodukten zeichnet sich DataCore Swarm durch die simultane und synergistische Nutzung beider Schutzmechanismen aus, daher auch die Bezeichnung „Elastic Content Protection (ECP)“ (Patent 9,916,198). Da EC sich besser für größere Objekte eignet, gibt es in DataCore Swarm einen Grenzparameter für die Objektgröße. Bei kleineren Objekten greift automatisch die Replikation anstelle von Erasure Coding. Dies ermöglicht eine ausgewogene Balance zwischen Beständigkeit und Platzbedarf, unabhängig von der Objektgröße.
In einer Infrastruktur mit Tausenden von Festplatten gehören mögliche Ausfälle einzelner Platten zum Alltag. Bei DataCore sind wir der Überzeugung, dass die Infrastruktur diese Aufgabe eigenständig und routinemäßig behandeln sollte, ohne dass ein Mitarbeiter eingreifen muss. Der Cluster übernimmt dies automatisch. Hardware wie Server oder Festplatten können jederzeit in Gruppen ausgetauscht werden.
Alle Server beteiligen sich an der Erkennung von Festplattenausfällen, sodass dies praktisch sofort erfolgt. Solange Speicherplatz verfügbar ist, werden alle Daten, deren Redundanz beeinträchtigt ist (z. B. verlorene Replikate), unverzüglich in einem massiv-parallelen, clusterweiten Wiederherstellungsprozess neu geschützt. Alle Server, auf denen sich ein „verwaistes“ Replikat befindet, veranlassen die Erstellung eines weiteren Replikats auf einem anderen Server. Da die Server im Cluster verteilt sind, tragen alle Server zu dieser Aufgabe bei. So kann eine Festplatte, deren Wiederherstellung in einer herkömmlichen RAID-Konfiguration 24 Stunden dauern könnte, in weniger als 15 Minuten neu gesichert werden. Je größer der Cluster, desto schneller läuft dieser Wiederherstellungsprozess ab und desto geringer ist die Wahrscheinlichkeit, dass mehrere überlappende Festplattenausfälle zu Datenverlusten führen. Bei Daten mit Erasure Coding wird ein ähnlich aktiver Wiederherstellungsprozess ausgelöst (bei Produkten anderer Anbieter erfolgt dies oft langsam im Hintergrund oder erst, wenn das Objekt gelesen wird). Deshalb erreicht Swarm mit einem identischen EC-Schema in einer vergleichbaren Hardware-Umgebung mehr Neunen als andere Systeme.
Wo es erforderlich ist, Inhalte über verschiedene Rechenzentrumsbereiche oder Standorte hinweg zu sichern, stehen mehrere Möglichkeiten zur Verfügung. Das „Local Area“-Replikationsschema nutzt Hochgeschwindigkeitsverbindungen mit niedriger Latenz, um Cluster in mehrere Subcluster zu unterteilen. Replikate oder EC-Segmente werden dann auf die Subcluster verteilt. Selbst bei einem größeren Ausfall in einem Rechenzentrum ist die Datenwiederherstellung und Hochverfügbarkeit so sichergestellt.
Für Verbindungen über größere Entfernungen, mit niedriger Bandbreite oder störanfälligen Verbindungen wird asynchrone Replikation über das WAN eingesetzt. Dabei wird der integrierte, massiv-parallele Feed-Mechanismus genutzt, um die Cluster miteinander zu verbinden.
Da Festplatten in vielen Langzeitarchiven heute Bänder ersetzen, spielen Stromverbrauch und Kühlbedarf eine größere Rolle. Diese Faktoren haben einen erheblichen Einfluss auf die Gesamtkosten (TCO) solcher Archive. Die patentierte Darkive-Technologie von DataCore kombiniert wahlfreien Zugriff mit Festplatten und erreicht gleichzeitig nahezu die Gesamtenergiekosten von Bändern. Nach Aktivierung von Darkive werden nicht benötigte Ressourcen des Clusters, wie einzelne Festplatten oder ganze Server, heruntergefahren. Lediglich das notwendige Minimum bleibt „wach“, um die Betriebsbereitschaft zu gewährleisten. Dadurch wird der Energieverbrauch erheblich gesenkt. Die Überwachung und Wartung erfolgt im Hintergrund, wobei die Ressourcen regelmäßig eingeschaltet werden, um deren Funktionsfähigkeit zu prüfen und sicherzustellen. Auf diese Weise können bis zu 80 Prozent der Energie eingespart werden, ohne auf wesentliche Funktionen oder Leistung zu verzichten. Dies kann Energieeinsparungen von bis zu 25 Prozent der TCO bzw. über 1.000 Dollar pro Petabyte und Monat einbringen.
Je nach Anwendung kann es erforderlich sein, die Authentizität und Integrität der Daten langfristig zu sichern. Die Wurzeln von DataCore Swarm im Content Addressed Storage (CAS) zahlen sich hier aus. Während CAS früher eine separate Speicherkategorie war, bietet DataCore Swarm jetzt zusätzlich zu den generischen Vorteilen von Software-Defined Storage die Compliance-Elemente von CAS. Die Einhaltung vorgeschriebener Aufbewahrungsfristen, terminierbare Objektlöschung und Inhaltsversiegelung mittels im Feld aufrüstbarer Hash-Algorithmen sowie Legal-Hold-Features sind Standard.
Mit der Weiterentwicklung von Anwendungen steigen auch die Anforderungen an die Datenspeicherung. Hier profitieren Sie von den Vorteilen der massiv-parallelen Swarm-Architektur. Keine Konfiguration, keine Bereitstellung, keine Installation – einfach weitere x86-Server hinzufügen, unabhängig von Modell oder Hersteller. Die Server werden automatisch vom Cluster erkannt und integriert. Anschließend werden alle verfügbaren RAM- und Festplattenressourcen intelligent im Rahmen des normalen Clusterbetriebs genutzt. Weitere Hintergrundprozesse im Health Processor überwachen die Objektintegrität und die Kardinalität (d. h. den angemessenen Replikationsgrad) und bearbeiten zeitgesteuerte Lifecycle-Events, die durch die Lifepoint-Metadaten ausgelöst werden. Die Anzahl der Replikate kann sich im Laufe der Zeit entsprechend der sich verändernden Bedeutung der Daten anpassen. Selbst der Redundanzmechanismus kann automatisch von Replikation zu Erasure Coding wechseln, um den Platzbedarf auf der Festplatte zu optimieren, wenn die erwarteten Zugriffsmuster weniger intensiv sind.
Das Entfernen einer Festplatte oder eines kompletten Servers aus dem Cluster erfordert nur einen Klick in der Management-Webkonsole. Der Cluster erstellt dann Ersatzreplikate oder EC-Segmente aller betroffenen Objekte an einem anderen Ort und gibt an, wann die Hardware sicher entfernt werden kann. Interessant ist, dass während des gesamten Prozesses typischerweise gar nicht auf die zu entfernende Hardware zugegriffen wird. Durch ihre erzwungene „Außerdienststellung“ ist sie möglicherweise aufgrund ihres schlechten Zustands keine verlässliche Quelle. Da das Hinzufügen und Entfernen von Servern während des laufenden Betriebs erfolgen kann, verläuft die Migration organisch, ohne größere Unterbrechungen oder hohe Kosten, die mit aufwändigen Upgrades verbunden sind. Stellen Sie sich Ihre Daten als eine sichere Wolke vor, die an ihrem Platz bleibt, während ein langsamer Fluss an Hardware darunter hindurchströmt.
Die grundlegende Einheit für Inhalte in DataCore Swarm ist das Objekt und nicht die Datei, da in Swarm keine traditionellen Dateisysteme verwendet werden. Diese sind weder robust noch schnell genug, um Milliarden von Objekten zu verwalten. Physisch wird ein Objekt in Swarm als einfache, zusammenhängende Sequenz oder Byte-Stream auf der Raw-Disk gespeichert. Die äußerst granulare Adressauflösung reicht bis auf 512- oder 1024-Byte herunter. Selbst bei großen Mengen an kleinen Objekten geht kaum Speicherplatz durch Lücken zwischen den Objekten verloren, sodass die Speichereffizienz hoch bleibt. Der zusammenhängende Datenstrom besteht aus zwei Teilen, den Daten und Metadaten, die nur einmal geschrieben werden und physisch miteinander gekapselt bleiben. Der Metadatenteil enthält zwei Header-Klassen: Header, die das Swarm-Verhalten steuern, wie Lifepoints, und individuelle Header, die von der Anwendung hinzugefügt werden, wie etwa eine Kunden-ID. Objekte werden an einer einzigen „Schreibfront“ mit freiem Platz auf die Festplatte geschrieben. Gelöschte Objekte werden einfach als solche gekennzeichnet, und der Speicherplatz wird anschließend asynchron vom Health Processor wieder freigegeben. Die EC-Segmente werden ähnlich wie reguläre Streams gespeichert. Der vollständige Satz wird in einem Verzeichnis dargestellt, in dem alle Segmente aufgelistet sind. Das Lesen der Inhalte und die Überprüfung der Vollständigkeit des Satzes erfolgen anhand dieses Verzeichnisses. DataCore Swarm nutzt diese Struktur sogar, um simultane, clusterweite, massiv-parallele Uploads eines einzelnen großen Streams durch mehrere parallele Clients zu ermöglichen.
Wenn Objekte geschrieben werden, wird dies auch in einem kleinen Umlaufjournal im vorderen Teil der Festplatte vermerkt. Beim Hochfahren dient dieses Journal dazu, den extrem schnellen RAM-Index zu aktualisieren, der Verweise auf die Festplatte und den Sektor enthält, in dem sich ein bestimmter Stream befindet. Diese Eigenschaft erklärt eine der überraschendsten und attraktivsten Eigenschaften der DataCore Swarm-Architektur: die Fähigkeit, innerhalb von Millisekunden zu wissen, auf welchem Server, welcher Festplatte und in welchem Sektor sich ein bestimmtes Objekt unter 100 Milliarden anderer Objekte im Cluster befindet. DataCore Swarm kann den Laufwerksarm direkt vor das Objekt positionieren und es in einem einzigen I/O-Schritt von der Festplatte lesen. Ein vergleichbarer Vorgang in einem traditionellen Dateisystem erfordert normalerweise deutlich mehr IOPS. Auf diese Weise bleibt die Zugriffszeit auf ein Objekt unabhängig von der Anzahl der Server oder Objekte im Cluster konstant.
Besondere Leistungsfähigkeit erhält der RAM-Index in Swarm durch das zum Patent angemeldete Schema namens Golden Pages. Vor dessen Einführung war es notwendig, beim Lesen eines Objekts im Cluster eine Multicast-Übertragung an alle Server durchzuführen, um das Objekt zu finden. Nach Eingang der Anfrage mussten alle Server schnell ihren RAM-Index auf Vorhandensein des gewünschten Objekts überprüfen, und nur im positiven Fall wurde eine Antwort übermittelt. Dies ist ein einfacher, zuverlässiger und äußerst robuster Mechanismus, der für Ausnahmefälle weiterhin verfügbar bleibt. Der Nachteil des gleichzeitigen Suchens in allen Servern ist die erhebliche CPU-Belastung bei hohen Objektleseraten (über 10.000 Objekte pro Sekunde), unabhängig von der Clustergröße. Golden Pages nutzt stattdessen eine überschaubare Menge an zusätzlichem RAM, um einen weiteren verteilten Index zu führen, der Unicast ermöglicht, sodass nur ein Server statt alle Server abgefragt wird. Dadurch wird CPU-Leistung freigesetzt und die Skalierbarkeit drastisch erhöht.
Oberflächlich betrachtet scheint es einen Widerspruch zwischen der Tatsache zu geben, dass ein DataCore Swarm-Objekt praktisch in einer einzigen Operation geschrieben wird, und der Notwendigkeit, das Objekt aktualisieren zu können. Bei näherer Betrachtung zeigt sich jedoch, dass dies nicht der Fall ist. DataCore Swarm verwendet drei Arten von Objekten oder Streams, die alle auf derselben Mechanik basieren. Der Basistyp ist der unveränderbare Stream, der mittels einer HTTP-POST-Operation an den Cluster übermittelt und auf den Festplatten entweder als Replikate oder in EC-Segmenten gespeichert wird. Eine 128-Bit-UUID wird als Erfolgsmeldung an den Client zurückgesendet. Das Vorhandensein und der Speicherort des Streams werden im Indexjournal sowie in einem Slot des RAM-Index selbst aufgezeichnet: etwa 50 Bytes RAM, einschließlich Golden Pages.
Der zweite Streamtyp, der sogenannte Anchor-Stream oder Alias-Stream, unterscheidet sich vom Basistyp dadurch, dass er mittels HTTP PUT aktualisiert werden kann. Anstatt ihn am Speicherort zu aktualisieren oder zu überschreiben, wird ein neuer Stream geschrieben und die vorhandene UUID wird umgeleitet, um darauf zu verweisen. Für diese zusätzliche Umleitung im RAM-Index wird ein zusätzlicher RAM-Slot pro Stream benötigt.
Drittens gibt es die sogenannten „Named Streams“, die vollständig dem Namensschema von Amazon AWS für den S3-Speicherdienst entsprechen. Anstatt der Client-Anwendung eine zufällige UUID anzubieten, ermöglichen sie es der Anwendung, einen eigenen Namen im HTTP POST-Erstellungsvorgang einzubringen. Dieser Name kann beliebig sein, solange er dem standardmäßigen URI-Format entspricht. Es gibt außerdem eine Ebene von Container-Objekten, die sogenannten „Buckets“, bei denen es sich im Wesentlichen selbst um benannte Objekte handelt. Solche Objekte können anhand ihres Namens, der in den Metadaten hinterlegt ist, in Gruppen zusammengefasst werden.
Ein DataCore Swarm-Cluster kann mehrere Mandanten und Domänen haben, die separat als eine Art virtueller Cluster gesichert und verwaltet werden können. Die Domänen enthalten wiederum Buckets, die benannte Streams beinhalten und DataCore Swarm effektiv zu einer Überordnung von AWS S3 machen. Eine Mehrmandantenfähigkeit ist besonders für Anwendungsfälle wichtig, bei denen verschiedene Benutzer oder Benutzergruppen völlig unabhängig voneinander bedient werden müssen.
Erinnern Sie sich noch daran, wie Datenspeicher vor etwa zehn Jahren aussah? Wie er als unterste Schicht im physischen Technologie-Stack betrachtet wurde, was im Wesentlichen dem mangelnden Interesse am strategischen Wert seiner Inhalte geschuldet war? Doch nach und nach begann der Datenspeicher, sich zu einem der wertvollsten Assets eines Unternehmens zu entwickeln, unter anderem durch die verbesserte Auswertung, Analyse und den Zugriff auf die darin gespeicherten Daten. DataCore war von Anfang an Vorreiter dieser Entwicklung. Wie ein Bienenschwarm, der unermüdlich daran arbeitet, den Bienenstock zu füllen und zu pflegen, entwickelt DataCore Technologien, die sich auf Inhalte konzentrieren, diese pflegen, speichern, heilen, bereinigen, finden und problemlos abrufbar machen. So können Unternehmen jederzeit und überall auf ihre Daten zugreifen, wenn sie diese benötigen.
Stefan Achter
Business Development Manager
stefan.achter@tdsynnex.com
Alle Artikel des Autors