Niedrigere Kosten und mehr Effizienz dank HPE Synergy
Sehr geehrte Damen und Herren,
Unternehmen wünschen sich eine flexible IT-Landschaft mit maximaler Skalierbarkeit und hervorragender Performance – zu möglichst niedrigen Kosten. Dieser Spagat ist nicht einfach zu meistern, doch unsere Performance-Tests im Computacenter HPE Solution Center beweisen, dass er gelingen kann – mit HPE Synergy und VMware vSAN. Wie das genau funktioniert, erfahren Sie in der aktuellen Ausgabe unseres Datacenter-Newsletters.
Grafikkarten können heute weit mehr, als Bilder, Videos oder Games gut aussehen zu lassen. Nvidia zeigt, wie sich durch ihre immense Kapazität auch besonders rechenintensive Workloads realisieren lassen, etwa im Bereich Deep Learning. Wir stellen Ihnen die Möglichkeiten vor.
Bei der Migration von Applikationen und Datenbanken in die Cloud sind vielfache Herausforderungen zu meistern. Dank der bewährten Services von Computacenter sind Sie dazu bestens gerüstet. Lesen Sie in dieser Ausgabe, wie Sie den Umstieg auf die Cloud schnell, reibungslos und kostengünstig schaffen können.
Mit dem Kubernetes Operator lassen sich auch komplexe Applikationen bis hin zu geschäftskritischen Workloads auf einer Container-Plattform sicher und automatisiert betreiben. Wir zeigen Ihnen, wie eine solche Lösung aussieht.
In unserer Backup-Kolumne informieren wir Sie darüber, welche Auswirkungen die neuesten Anforderungen der deutschen Aufsichtsbehörden auf die Backup- und Archivierungsarchitektur haben. Und in unserer Agile-IT-Kolumne gehen wir auf die Voraussetzungen und Lösungen ein, die nötig sind, damit die Themenbereiche künstliche Intelligenz und Machine Learning auch für den Massenmarkt tauglich und nutzbar werden.
Wie immer freuen wir uns über Ihr Feedback, damit wir die Schwerpunkte aufgreifen können, die für Sie von Interesse sind.
Herzliche Grüße
Markus Kunkel
Group Partner Management
Computacenter stärkt mit einer neuen Geschäftsstelle in Dresden seine Präsenz in Sachsen.
Weitere InfosDie Computacenter plc. hat gestern ihre finalen Geschäftszahlen für 2018 bekanntgegeben.
Weitere Infos
Unternehmen wünschen sich eine flexible IT-Landschaft mit maximaler Skalierbarkeit und hervorragender Performance – zu möglichst niedrigen Kosten. Dieser Spagat ist nicht einfach zu meistern, doch unsere Performance-Tests im Computacenter HPE Solution Center beweisen, dass er gelingen kann. Die Basis dafür liefern HPE Synergy und VMware vSAN.
An der Digitalisierung kommt langfristig niemand vorbei. Um die neuen Anforderungen der Digitalisierung – oder noch besser: der digitalen Transformation – zu erfüllen, sind Public Cloud Services oder eine On-Premises-IT-Infrastruktur, die nach den gleichen Prinzipien arbeitet, gefragt. Die Bereitstellung von IT-Services darf nicht der Engpass sein. Wir helfen Ihnen, hierfür den richtigen Ansatz zu finden, um die Effizienz zu steigern und Kosten zu senken. Wir liefern Ihnen die Expertise, mit der Sie fundierte Entscheidungen für oder gegen eine Technologie als Basis für Digitalisierung und digitale Transformation treffen können, und untermauern sie mit Fakten, die auf eigenen Performance-Tests beruhen. Diese Tests wurden im HPE Solution Center in Ratingen ermittelt und die Ergebnisse teilen wir gern Ihnen.
Unternehmen benötigen eine Architektur mit zukunftsorientierter Skalierbarkeit und eine vorhersehbare, sichere Anwendungs-Performance für virtualisierte Workloads – von geschäftskritischen Anwendungen bis hin zu Anwendungen der nächsten Generation. Dabei steht unter anderem die Frage im Raum, wie künftig IT-Services und Storage bereitgestellt werden: selbst betreiben, aus der Public Cloud beziehen oder ein Mix aus beidem? Die Kosten dafür müssen konstant bleiben – besser noch: sinken – und die Anforderungen der Datenschutz-Grundverordnung sind einzuhalten. On-Premises gibt es verschiedene Lösungsansätze: Converged, Hyperconverged und Software-definiert. IT-Entscheider müssen die unterschiedlichen Optionen verstehen, um herauszufinden, welche davon am besten zu ihrem Unternehmen passt.
Zusammen mit Hewlett-Packard Enterprise (HPE) und VMware bieten wir Software Defined Storage auf Basis der Composable Infrastructure HPE Synergy und VMware VSAN an. Die Lösung wurde mit dem Best-Practice-Design von Computacenter konzipiert. Sie erfüllt die komplexen Anforderungen an eine moderne Unternehmens-IT. Die Lösung ist optimiert für den Storage virtueller Infrastrukturen auf Basis von VMware vSphere und bildet die Basis für eine flexible IT-Landschaft, die zugleich klassische und agile IT unterstützt. Maximale Skalierbarkeit, optimale Performance und die Reduzierung kostenintensiver und aufwändiger Storage Area Networks gehören zu ihren Merkmalen. Kurzum: Sie bietet Kostensenkung und mehr Effizienz für Ihre On-Premises-IT.
In den Performance-Messungen haben wir die Leistungsfähigkeit der Composable Platform HPE Synergy auf die Probe gestellt und zahlreichen Tests unterzogen. Im Fokus standen dabei praxisnahe Performance-Messungen, es ging uns also nicht darum, Höchstwerte durch optimierte Testszenarien erreichen, sondern vielmehr darum, Workloads so realistisch wie möglich abzubilden. Dennoch haben wir auch die Maximalwerte ausgetestet und dabei IO-Raten von 1,5 Mio. IO/s (100 Prozent Lesen, 4 kB Blocksize) in einem 8-Node-Cluster erreicht. Die gleiche Konfiguration zeigte 1 Mio. IO/s bei einem 100-prozentigen Write-Workload.
Wie oben jedoch bereits angeführt, lag der Fokus nicht auf rekordverdächtigen IO-Werten, sondern auf Workloads, wie sie im realen Betrieb vorkommen. 70 Prozent Write bei 8 kB Blocksize mit einer definierten IO-Rate zeigte Latenzen von unter 1 Millisekunde. Mit diesen Werten avanciert VMware vSAN als Software Defined Storage zur ernsthaften Konkurrenz von etablierten Storage-Area-Network-Lösungen.
Wir präsentieren Ihnen die Ergebnisse gern im Detail und loten gemeinsam mit Ihnen aus, ob VMware vSAN auch für Ihre IT eine Lösung sein kann. Ihr Ansprechpartner aus dem Haus Computacenter steht bereit.
Grafikkarten im Rechenzentrum können nicht nur bei grafikintensiven Anwendungen unterstützen, sie ermöglichen durch ihre immense Kapazität auch besonders rechenintensive Workloads, etwa im Bereich Deep Learning. Wir stellen Ihnen die Möglichkeiten vor.
Was fällt Ihnen beim Hersteller Nvidia zuerst ein? Grafikkarten, richtig? Ja, das stimmt zwar noch, allerdings hat Nvidia sein Portfolio enorm erweitert. Die reinen Gaming-Grafikkarten machen nur noch einen kleinen Teil des Umsatzes aus.
Heutzutage ist Nvidia beispielsweise ein großer Player in der Fahrzeugindustrie und liefert unter anderem Kameraunterstützung und Objekterkennung. Vor allem hat Nvidia sich jedoch den Rechenzentrumsthemen zugewandt.
Grafikkarten im Rechenzentrum? Ja, allerdings! Immer mehr unserer Kunden setzen grafikintensive Anwendungen ein, heutzutage meist in virtuellen Maschinen. Dies lässt sich problemlos realisieren und das Feedback der Benutzer ist überragend. Also doch wieder nur Grafiknutzung, werden jetzt einige denken, doch weit gefehlt, denn immer mehr Workloads können statt mit CPUs auf GPUs arbeiten. Auf diese Weise lassen sich Aufgaben deutlich schneller erledigen, denn während eine aktuelle CPU heutzutage bis zu 30 Rechenkerne vorweisen kann, hat die aktuelle GPU-Generation von Nvidia bis zu 5.120 Rechenkerne zu bieten! Diese geballte Rechenpower lässt sich beispielsweise für Machine Learning und Deep Learning einsetzen. Während Big-Data-Analysen auf gängigen CPUs unter Umständen Tage oder Wochen an Rechenzeit belegen können, kann der Einsatz von speziell optimierten Nvidia-Systemen diese massiv verkürzen.
In einem aktuellen für Deep Learning optimierten DGX-System von Nvidia sind zum Beispiel bis zu 16 Nvidia-V100-GPUs mit jeweils 5.120 Rechenkernen verbaut. Die Systeme verfügen zudem über CPUs zur Verwaltung. Auf einem solchen Server läuft ein Linux-Betriebssystem und die Workloads werden als Container Images auf der Plattform betrieben. Das ermöglicht eine extrem flexible Nutzung durch mitunter mehrere Entwickler gleichzeitig. Jeder Entwickler oder User kann sein eigenes Container Image verwenden. Nvidia bietet hierzu eine ganze Reihe vordefinierter Container zum Download an.
Den Einstieg in diese neue Nvidia Welt bietet beispielsweise der Einsatz einer sogenannten vGPU-Lösung. Dazu werden in x86-Servern Grafikkarten von Nvidia verbaut und diese dann dem installierten Hypervisor zur Verfügung gestellt, der daraufhin die benötigten GPU-Ressourcen den einzelnen virtuellen Maschinen zuweist, damit unterschiedliche Anwendungen betrieben werden können. Das kann die Nutzung von Grafikleistung für virtuelle Desktops wie Windows 10 sein oder der Einsatz in Terminalservern. Besonders der Umstieg auf Windows 10 und Server 2019 erfordert häufig den Einsatz von GPUs in den VMs, da die Grafikanforderungen um mehr als 30 Prozent gestiegen sind. Gleichzeitig können mit der vGPU-Lösung die ersten Deep-Learning-Erfahrungen gesammelt werden, ohne gleich in die speziell optimierten DGX-Systeme investieren zu müssen.
Mit dem Einsatz von Nvidia-GPUs ergeben sich diverse neue Aufgabengebiete. Interessiert? Dann sprechen Sie uns an! Unsere Experten unterstützen Sie gern bei PreSales, Sizing, Implementierung und Training.
Der Betrieb von Applikationen in der Cloud bietet zahlreiche Vorteile, die Umstellung darauf ist jedoch häufig mit Herausforderungen gespickt. Damit Sie diese mühelos meistern, unterstützt Computacenter Sie mit einer vorangehenden Analyse und Bewertung sowie einem umfassenden Support während der Migration Ihrer Applikationen und Daten. So können auch Sie schnell und unkompliziert von den Vorteilen profitieren.
Wer sich für eine Cloud-Strategie entschieden hat und Applikationen sowie Datenbanken in der Cloud betreiben möchte, steht vor der Herausforderung, diese Applikationen in die Cloud zu migrieren. In der Regel handelt es sich um komplexe, gewachsene Applikationslandschaften, die nur schwer zu überblicken und zu bewerten sind. Ein wesentlicher Bestandteil des Move2Cloud Offerings von Computacenter ist deshalb eine umfangreiche Applikationsanalyse, um bewerten zu können, ob und welche Applikationen in die Cloud migriert werden können, welche Abhängigkeiten existieren und welche Aufwände dafür entstehen.
Es gibt im Wesentlichen vier Methoden für die Cloud-Migration. Für alle Methoden gilt, im Vorfeld funktionale Bestandteile der Applikationen und des Backends zu analysieren und hinsichtlich verschiedener Merkmale zu bewerten: Sicherheit, Redundanzen, Skalierbarkeit, Datenschutz, Cloud-Fähigkeit (Abhängigkeiten von Schnittstellen, Systemen, anderen Applikationen und Datenbanken), Zugriffe von außen, zeitgemäße Softwarearchitektur, modernes UI und so weiter.
Die vier Methoden für die Cloud-Migration umfassen:
Dies ist die einfachste Möglichkeit einer Cloud-Migration. Voraussetzung ist, dass die Applikation an sich schon „cloud-ready“ ist. Dies ist in der Regel dann gegeben, wenn keinerlei Abhängigkeiten zu anderen Systemen bestehen. Andernfalls ist es auch möglich, durch die Schaffung der entsprechenden Netzwerkinfrastruktur (Hybrid-Szenarien) notwendige Voraussetzungen zu schaffen. Hierbei kann es sich konkret zum Beispiel um Systemschnittstellen oder Authentifizierungsmechanismen handeln.
Bei Abhängigkeiten zu anderen Applikationen muss evaluiert und berücksichtigt werden, ob diese Applikationen ebenfalls in die Cloud verlagert oder weiter on premises betrieben werden.
Ziel dieser Methode ist die Konsolidierung der Applikationslandschaft, das heißt, redundante Applikationen oder Backend-Komponenten abzuschaffen beziehungsweise zusammenfassen und in die Cloud zu verlagern.
Dafür werden die Applikationen auf Prozess- und Benutzerebene analysiert. Grundlage sind beispielsweise folgende Überlegungen:
Die notwendigen Anpassungen sind bei dieser Methode deutlich umfangreicher als bei Shift2Cloud.
Bei der Neuntwicklung wird der komplette Applikationscode neu geschrieben. Ziel ist es, zeitgemäße Softwareentwicklungstechnologien zu nutzen, Applikationen zu entwickeln, die für den Einsatz in der Cloud optimiert sind, neue Funktionen zu implementieren oder mehrere Alt-Applikationen in einer neuen Cloud-Applikation abzubilden.
Hierbei müssen alle Schnittstellen und Abhängigkeiten zu anderen Prozessen betrachtet werden. Datenschutz, Sicherheit, Integration von Azure/ADFS sowie Abhängigkeiten zu On-Premises-Systemen müssen hier besonders berücksichtigt werden. Dies gilt auch hinsichtlich der Infrastrukturvoraussetzungen bei hybriden Cloud-Ansätzen.
Diese Methode eignet sich hervorragend dazu, Cloud-Funktionen und deren Vorteile zu planen, zu implementieren und zu nutzen. Dazu zählen beispielsweise Delivery-Vorteile, die einfache Verwendung von Cloud Services (AI Services, kognitive Services, und so weiter), Skalierbarkeit, Performance und Flexibilität.
Der Fokus bei dieser Strategie liegt darauf, Standard-Softwarefunktionen einzusetzen, eventuell zu Lasten von individuellen Applikationen. Langfristig sollen so die Aufwände für Betrieb und (eigene) Entwicklung deutlich reduziert werden. Hintergrund dieser Strategie ist vor allem die Tatsache, dass eigene Applikationen nur dann einen Vorteil am Markt bringen, wenn sie für Prozesse entwickelt werden, die Unterscheidungsmerkmale zum Wettbewerb bringen.
Mit dem Move2Cloud Offering unterstützt Computacenter Kunden dabei, ihre Geschäftsprozesse zu optimieren und das Digitalisierungstempo zu erhöhen. Wir helfen bei der Entwicklung, der Bereitstellung und beim Betrieb maßgeschneiderter Digitalisierungslösungen. Unsere Erfahrung aus unterschiedlichen Projekten zeigt, dass sich mit unserer Strategie – der Kombination aus existierenden Services und Plattformen mit individuell entwickelten Applikationen – die Entwicklungszeit von Digitalisierungsprojekten erheblich verkürzen lässt. Dabei bleiben kundenspezifische Mehrwerte bestehen oder werden sogar erst geschaffen.
Gern stellen wir Ihnen in einem persönlichen Gespräch detailliert vor, wie wir auch Sie bei der Migration von Applikationen und Datenbanken in die Cloud unterstützen können. Wenden Sie sich dazu einfach an Ihren Ansprechpartner bei Computacenter.
Moderne Applikationen – darunter auch viele geschäftskritische Workloads – werden heutzutage zunehmend auf Container-Technologien umgesetzt. Durch eine Automation ließe sich ein unterbrechungsfreier und sicherer Betrieb gewährleisten, allerdings ist das bei Applikationen, die Abhängigkeiten zu außerhalb des Containers liegenden Daten aufweisen, nicht so einfach zu bewerkstelligen. Die Lösung: ein speziell auf die Applikation angepasster Kubernetes Operator.
2011 präsentierte Adam Wiggins die zwölf Prinzipien, die moderne Applikationen oder sogenannte Cloud-native Applikationen auszeichnen (Twelve-Factor App). Seitdem haben sich Plattformen entwickelt, um Applikationen basierend auf diesen Prinzipien zu entwickeln und zu betreiben. Heutzutage werden diese Applikationen zunehmend auf Container-Technologien umgesetzt. 2019 werden auch viele geschäftskritische Workloads auf Container-Plattformen laufen, darunter immer mehr Applikationen mit einem State – also mit persistenten Daten. Darüber hinaus erwarten wir für dieses Jahr eine zunehmende Betriebsautomation für diese „Stateful-Applikationen“ – programmiert durch die Entwicklerteams. Eine entscheidende Rolle spielt dabei der Kubernetes Operator.
Um das Prinzip und vor allen Dingen die Bedeutung des Kubernetes Operator für den Betrieb von Container-basierten Stateful-Applikationen auf einer Container-Plattform und Kubernetes nachvollziehen zu können, werfen wir einen kurzen Blick auf die Betriebssicht für Stateless- und Stateful-Applikationen.
Bei einer Stateless-Applikation handelt es sich häufig um sogenannte Micro Services oder Applikationskomponenten, die in sich isoliert sind und beispielsweise auf den Twelve-Factor-App-Prinzipien basieren. Dabei ist wichtig: Diese Stateless-Applikationen halten keine persistenten Daten und müssen sich daher nicht um die Redundanz, das Backup und die Verfügbarkeit von Daten kümmern. Weiterhin existieren immer mehrere Instanzen (laufende Container) dieser Stateless-Applikationen, weshalb im Grunde jederzeit ein laufender Container ausfallen kann und die User dennoch die Applikation beziehungsweise den Service ohne Unterbrechung weiternutzen können.
Für das Team (siehe dazu auch unseren Artikel „DevOps – Wie bringe ich Entwicklung, Betrieb und Compliance unter einen Hut?“), welches die Container-Plattform im Unternehmen baut und betreibt, hat dieses Modell positive Auswirkungen. Einzelne Compute-Instanzen können jederzeit im laufenden Betrieb neu gestartet werden und die Applikation ist aufgrund der Architektur der Anwendung davon nicht betroffen. Damit können Wartungsarbeiten im Prinzip jederzeit durchgeführt werden. Das zuständige Team kann zugunsten einer höheren Stabilität der Plattform beispielsweise Modelle wie den Chaos Monkey implementieren, mit denen Komponenten der (Container-)Plattform nach einem Zufallsprinzip abgeschaltet werden.
Im Kern sieht so auch die Architektur von Kubernetes aus. Es wird eine Policy definiert, wie viele Kopien einer Stateless-Applikation verteilt auf dem Kubernetes-Cluster laufen sollen und Kubernetes stellt jederzeit diesen State sicher. Das bedeutet, bei einem Ausfall beispielsweise eines Knotens werden die Container gemäß der Policy oder dem „Desired State“ auf anderen verfügbaren Ressourcen neu gestartet.
Während all das bei Stateless-Applikationen beziehungsweise Container-Images gut funktioniert, ergeben sich bei Stateful-Applikationen Herausforderungen. Bei einer Stateful-Applikation handelt es sich beispielsweise um eine Datenbank, die außerhalb des laufenden Containers persistente Daten speichert. Und jetzt sind die Vorgaben und Spezifikationen des Datenbank-Anbieters in Bezug auf Upgrades, HA/DR-Szenarien, Datensicherung und so weiter einzuhalten. So kann beispielsweise die Vorgabe des Datenbank-Herstellers für eine Hochverfügbarkeit sein, dass mindestens drei Repliken der Datenbank inklusive einer Replikation der Daten auf der Ebene der Datenbank existieren müssen. Wenn in diesem Szenario eine laufende Container-Instanz ausfällt und auf einem anderen Knoten neu gestartet werden muss, so sind neben dem Anbinden des persistenten Speichers Recovery-Verfahren auszuführen, um den Datenbank-Cluster wieder in einen konsistenten Status zu bringen und den neu gestarteten Knoten korrekt zu synchronisieren.
Die Standardverfahren in Kubernetes greifen nicht auf der Ebene der Applikation und adressieren somit nicht die Vorgaben des Herstellers, um einen konsistenten Stand beispielsweise eines Datenbank-Clusters wiederherzustellen. Das dazu notwendige Fachwissen ist in der Dokumentation des Herstellers beschrieben und muss bei einem Recovery durch Administratoren (DB-Admins, andere) umgesetzt oder aufwendig automatisiert werden.
Um diesen Prozess zu automatisieren, hat CoreOS das Konzept der Operator entwickelt, die auf Kubernetes aufsetzen und die Kubernetes-Spezifikationen nutzen, um sich einen Überblick über die Stateful-Applikationen und deren Abhängigkeiten zu verschaffen. Technisch setzt dieses Konzept auf dem Kubernetes Controller auf und erweitert die Kubernetes API um ein spezifisches Verständnis für eine singuläre Applikation. Anders formuliert: Der Hersteller der Stateful-Applikation stellt einen Operator bereit, in dem die Betriebslogik für die Applikation codiert ist. Dies nutzt das Desired-State-Modell in Kubernetes und definiert – basierend auf Programmier- oder Skriptsprachen wie Helm Charts, Ansible oder Go –, wie die Applikation beispielsweise installiert, auf eine neue Version aktualisiert, verfügbar (HA/DR) und sicher gehalten sowie gesichert (Backup) werden muss. Damit muss das Team, welches die Container-Plattform betreut, nur sicherstellen, dass der Operator für die jeweilige Stateful-Software mitinstalliert wird und läuft – und damit ist diese Applikation im Betrieb der Plattform integriert.
Mit einem Operator wird von dem Hersteller oder Entwickler der Softwarebeziehungsweise Applikation die Betriebsanleitung als Code mitgeliefert. Der Betreiber der Container-Plattform installiert den Operator und automatisiert damit den Betrieb der Applikation auf Basis der Vorgaben des Herstellers.
Das bedeutet: Wenn es zum Beispiel bei einem Upgrade auf eine neue Datenbank-Version Schwierigkeiten gibt, liegen alle dazu notwendigen Bausteine in der Kontrolle und damit auch in der Verantwortung des Softwareanbieters. Dieser hat schließlich das Rezept für das Upgrade mit dem Operator mitgeliefert und im Vorfeld getestet.
Weiterhin werden tägliche Routineaufgaben wie beispielsweise die Datensicherung gemäß den Vorgaben des Herstellers über den Operator abgebildet. Damit müssen nicht pro Applikation spezifische Verfahren oder Lösungen implementiert werden.
Somit können die Teams, welche die Container-Plattform verantworten, auch komplexe Stateful-Applikationen sicher und automatisiert betreiben. Das erhöht die Skalierbarkeit und Qualität der Betriebsleistung für Stateful-Applikationen erheblich.
Möchten Sie gern mehr zum Thema Operator erfahren und darüber, wie die Effizienz Ihrer Container-Plattform basierend auf Kubernetes erhöht und deren Betrieb vereinfacht werden kann? Sprechen Sie am besten gleich Ihren Ansprechpartner bei Computacenter an und vereinbaren Sie eine Live Demo oder einen Workshop.
2018 publizierten die deutschen Aufsichtsbehörden gleich mehrere neue Anforderungen, beginnend mit einer neuen Version des IT-Grundschutz-Kompendiums des BSI über die BAIT und VAIT des BAFin bis hin zu den Kriterien des BSI in dem Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“. Die neuen Anforderungen haben potentiell Auswirkungen auf die Backup- und Archivierungsarchitektur unserer Kunden.
In der BAIT und der VAIT (banken- beziehungsweise versicherungsaufsichtliche Anforderungen an die IT) sind im Jahr 2018 die Anforderungen an die Datensicherung spezifiziert worden. Diese finden sich beispielsweise in der VAIT unter Punkt 64 und sind wie folgt formuliert:
„Die Vorgaben für die Verfahren zur Datensicherung (ohne Datenarchivierung) sind schriftlich in einem Datensicherungskonzept zu regeln. Die im Datensicherungskonzept dargestellten Anforderungen an die Verfügbarkeit, Lesbarkeit und Aktualität der Kunden- und Geschäftsdaten sowie an die für deren Verarbeitung notwendigen IT-Systeme sind aus den Anforderungen der Geschäftsprozesse und den Geschäftsfortführungsplänen abzuleiten. Die Verfahren zur Wiederherstellbarkeit im erforderlichen Zeitraum und zur Lesbarkeit von Datensicherungen sind regelmäßig, mindestens jährlich, im Rahmen einer Stichprobe sowie anlassbezogen zu testen.“
An dieser Stelle kann argumentiert werden, dass diese Formulierungen, wenn diese mit dem BSI-IT-Grundschutz-Kompendium verglichen werden, keine wirklich neue Anforderung darstellen. In der Tat wurde nur der Abstand der sporadischen Wiederherstellungsübungen auf mindestens einmal jährlich konkretisiert.
In den zahlreichen Projekten, die Computacenter hierzu durchgeführt hat, hat sich jedoch gezeigt, dass die Revisionsabteilungen intern eine aktualisierte Version des Datensicherungskonzepts anfordern und Unternehmen sicherstellen (sollten), dass diese auf dem aktuellen Stand der Zeit sind. In der konkreten Projektarbeit stellt sich nicht selten heraus, dass der Prozess für die Wiederherstellungsübungen sehr unterschiedlich gestaltet und gelebt wird und dass die Anforderungen an den Dienst Datensicherung auf teilweise älteren Sachständen basiert.
Aus diesem Grund bietet Computacenter einen schlanken Beratungsservice unter dem Namen „Backup Service Katalog“ an, um das Datensicherungs- und Archivierungskonzept auf einen aktuellen Stand zu heben und damit gegenüber den Anforderungen der Revision gewappnet zu sein.
Spannend wird es jedoch, wenn Unternehmen sich auf die neuen Kriterien des BSI für höchstverfügbare und georedundante Rechenzentren konzentrieren.
Die wichtigste Formulierung in dem BSI-Dokument findet sich dazu im Kapitel 3.3. Kunden, die höchstverfügbare Rechenzentren für die regulierten Applikationen betreiben, müssen einen Mindestabstand von circa 200 Kilometern sicherstellen. Unter bestimmten, schriftlich ausführlich dargelegten Bedingungen kann ein Mindestabstand von circa 100 Kilometern ausreichen.
Diese Anforderungen stehen mit dem in Deutschland sehr weit verbreiteten Design der Rechenzentren – verteilt über zwei Brandbereiche in einer synchron gespiegelten Distanz – im Widerspruch. Das bedeutet im Grunde, dass zusätzlich zu den bestehenden Rechenzentren ein Desaster-Recovery-Rechenzentrum (DR-Rechenzentrum) erforderlich wird.
Und tatsächlich ist Computacenter in konkrete Kundenprojekte involviert, um diesbezüglich die vorbereitenden Planungen durchzuführen, damit bei konkreten Anforderungen seitens der Aufsichtsbehörden wie dem BAFin zeitnah reagiert werden kann.
Inwiefern diese Anforderungen durch die jeweiligen Unternehmen in welchen Zeiträumen umgesetzt werden müssen, ist sicherlich Gegenstand für Diskussionen innerhalb der Unternehmen in Abstimmung mit den Beratungs- und Aufsichtsbehörden. Allerdings ergeben sich hieraus gegebenenfalls auch neue Anforderungen in Bezug auf die Datensicherung und die Archivierung, die bei der Planung solcher Projekte beachtet werden müssen.
Die höchste Schwerkraft bei der Planung einer Georedundanz haben die Daten. Heute verfügen Großunternehmen nicht selten über Datenbestände in der Größenordnung von mehreren Hundert TB bis hin zu Petabyte Volumen. Bei dem Aufbau einer Georedundanz und verbunden damit eines dritten DR-Standorts sind die geschäftsrelevanten Daten an diesen dritten Standort zu übertragen.
Technisch gesehen ist dies eine Frage von Datenvolumen, Bandbreite und der täglichen Änderungsrate. Somit ist die Anforderung also fachlich überschaubar. Allerdings entstehen hierbei durchaus sehr hohe Kosten – und dann stellen sich unter anderem folgende Fragen:
Interessanterweise fokussiert sich die Diskussion dann häufig auf die primären Daten – und Themen wie Backup und Archivierung werden entweder gar nicht, nur am Rande oder im Nachgang betrachtet.
Eine ordnungsgemäße Archivierung schreibt die archivierungswürdigen Daten redundant auf mehr als ein Speicherziel, bevor der führenden Applikation die Archivierung bestätigt wird und das Archivierungsobjekt an der Quelle gelöscht wird.
Baut man auf dieser marktüblichen Definition von Archivierung auf, so bedeutet das technisch, dass mit der Einführung eines dritten DR-Standorts drei bestätigte Kopien (zwei lokal auf dem Campus in zwei Brandbereichen plus eine Kopie am DR-Standort) geschrieben sein müssen, bevor eine Bestätigung erfolgen kann. Hintergrund ist, dass eine Archivierung zur Einhaltung gesetzlicher und regulativer Vorgaben dient und daher auch in einem DR-Szenario die Archivdaten vollständig und sicher vorhanden sein müssen.
Die Datensicherung dient dazu, nach einer physischen oder logischen Korruption Teile oder ganze Datenbereiche auf einen definierten und konsistenten Zeitpunkt zurückzusetzen. Dies kann auch ein vorab vereinbarter älterer Zeitpunkt sein (Kriterium ist die Recovery Point Objective, kurz: RPO). Dazu werden in definierten Intervallen Sicherungen erzeugt, die in einen brandtechnisch getrennten Bereich überführt werden müssen.
Im Rahmen eines DR-Szenarios kann eine vollständige Wiederherstellung der geschäftsrelevanten Systeme theoretisch aus einer Kopie der Datensicherung am DR-Standort erfolgen. Das kann bei kleineren Umgebungen und Datenbeständen möglich sein – bei großen Unternehmen ist in der Regel die definierte Wiederanlaufzeit nach einem DR-Szenario dafür nicht ausreichend, weshalb in diesem Fall alternative Übertragungsverfahren notwendig sind.
Bedeutet dies, dass auf eine Übertragung der Datensicherung verzichtet werden kann oder soll?
Gerade bei einem DR-Szenario liegt es nahe, dass eine Reihe von Systemen logische Korruptionen enthält, die durch einen Point-in-Time-Restore beispielsweise durch das Nachziehen der letzten Transaktionen konsistent gesetzt werden müssen. Das ist eines der Einsatzgebiete der Datensicherung und erfordert konsequenterweise, dass die Datensicherung gemäß den Service Levels auch nach einem DR-Fall am dritten Standort verfügbar ist.
Weiterhin ist dann der Regelbetrieb für die Dauer der DR-Situation zu betrachten. Auch hier sind regelmäßige Datensicherungen und Restores erforderlich, die den definierten Service Levels unterliegen. In der Konsequenz bedeutet dies, dass die Datensicherung für die geschäftskritischen Daten sowohl am Primär- wie auch am DR-Standort vollwertig verfügbar sein muss.
Da Daten Schwerkraft haben und das Überwinden der Schwerkraft ein Kostenfaktor ist, stellt sich selbstverständlich die Frage, wie oft die gleichen Daten übertragen werden müssen.
identifiziert. Abhängig von der Nutzung des DR-Standorts beispielsweise für Test- und Development-Zwecke können außerdem noch Datenkopien von der Produktion für Tests und Development hinzukommen.
Selbstverständlich ist es aus Kostensicht nicht sinnvoll, Daten wiederholt und redundant zu übertragen.
Eine pauschale Antwort gibt es jedoch leider nicht, sie muss kundenspezifisch erarbeitet werden. Mit einem großen Erfahrungsschatz aus diversen Projekten in diesem Themenkomplex unterstützt Computacenter Sie gern dabei, diesen Fragen auf den Grund zu gehen und eine Architektur zu erstellen, die zu Ihrem Unternehmen und Ihren speziellen Anforderungen passt. Wenden Sie sich dazu gern an Ihren Ansprechpartner bei Computacenter.
Das Themengebiet künstliche Intelligenz (KI) und Machine Learning (ML) ist das bedeutsamste Fundament für die digitale Transformation. Im Jahr 2019 muss es beweisen, dass es nicht nur in Forschungsbereichen und ersten kleineren Projekten funktioniert, sondern auch für den Massenmarkt skalierbar und nutzbar ist. Wir zeigen die Voraussetzungen und Lösungen dazu auf.
Laut einer Studie von McKinsey & Company sollen im Jahr 2030 bereits 70 Prozent der Unternehmen KI/ML verwenden und der KI/ML-Markt das unglaubliche Volumen von 13 Billionen US-Dollar erreichen. Damit ist KI/ML ein Megatrend und wird zu einer Kernfunktion in digitalen Lösungen sowohl für Nutzer als auch für Business.
Einen entscheidenden Wettbewerbsfaktor stellt die richtige Umsetzung einer KI/ML-Strategie dar. Für die Strategie selbst sind drei technische Säulen relevant:
Wie wird die Kombination von Data Lake, der Algorithm Economy und den Datenanalysten und Entwicklern produktiv? Wie können immer neuen Kombinationen von Algorithmen performant auf Data Lakes trainiert werden und für immense Datenmengen genutzt werden?
Der Unterbau für diese Welt wird 2019 zunehmend auf einer Container-Plattform aufsetzen, in der als Herzstück für die Orchestrierung und Abstraktion der IT-Ressourcen der De-facto-Standard Kubernetes läuft. Aufsetzend auf diesem Motor ist es erforderlich, dass einzelne Data-Analytics- und DevOps-Teams – meist als isolierte Mandanten auf der Plattform – in einem Self Service auf die Algorithm Economy zugreifen können und performant auf die Data Lakes kommen. Dazu muss der Motor um ein breites Spektrum an Werkzeugen und Tools ergänzt werden, mit denen eine produktive Nutzung ermöglicht wird. Dieses Spektrum an Tools und ergänzt den Unterbau, um aus dem Motor ein vollwertiges Fahrzeug zu machen, in das DevOps-Teams und Datenanalysten einsteigen und mit dem sie sofort losfahren können, um neue Lösungen zu erfinden und die digitale Transformation voranzutreiben.
Computacenter hat, gemeinsam mit den Partnern Red Hat und NetApp, ein solches Fahrzeug entwickelt. Das Fahrzeug ist abstrahiert von dem jeweiligen Infrastruktur-Provider (Private Cloud, AWS, Google oder Azure) und unterstützt damit auch den Multi-Cloud-Trend, welchen IDC für die nahe Zukunft mit durchschnittlich vier verschiedenen Clouds in deutschen Unternehmen prognostiziert.
Basierend auf der Red Hat Openshift Container Platform können Entwicklungsteams in einem Self-Service-Modell die KI/ML-Algorithmen zusammenstellen und dazu auch Nvidia-GPU-Compute-Ressourcen buchen. Den performanten Zugriff auf den Data Lake stellt NetApp mit seinen Speicherservices bereit, die in Kubernetes und Openshift integriert sind und die Skalierbarkeit, Performance und Verfügbarkeit erreichen, die für diese neuen Enterprise-Workloads erforderlich sind. Diese Technologien werden veredelt mit der jahrelangen Erfahrung von Computacenter in den Bereichen Data Analytics, KI/ML und DevOps- und Container-Plattformen, damit Ihre Data-Analytics- und DevOps-Teams einsteigen und sofort Geschwindigkeit aufnehmen können in der digitalen Transformation.
Computacenter steht Ihnen gern jederzeit für Fragen und auch für eine Live-Demo zur Verfügung. Wenden Sie sich dazu einfach an Ihren Ansprechpartner bei Computacenter.