Transkript des Webcasts
Sander Puerto: Hallo, guten Morgen und guten Nachmittag allerseits, und vielen Dank, dass Sie heute bei uns sind. Mein Name ist Sander Puerto. Ich bin Senior Product Marketing Manager hier bei DataCore und werde heute als Moderator fungieren. Wir heißen Sie herzlich willkommen zu diesem Webcast, in dem Sie erfahren werden, wie RSD seine Backup-Leistung um das Dreifache steigern und sein ERP-System blitzschnell machen konnte.
Bevor wir mit unserer Präsentation beginnen, möchten wir kurz einige organisatorische Punkte ansprechen. Schauen wir uns noch einmal die Tagesordnung an. Nun, wir werden uns zunächst vorstellen. Dann werden wir über das Problem sprechen. Anschließend werden wir über die Lösung, den Ausgang und die Ergebnisse sprechen, die RSD erzielen konnte. Gegen Ende werden wir dann noch kurz darauf eingehen, was software-defined storage ist und warum Sie diese Technologie zumindest in Betracht ziehen oder prüfen sollten – und wir werden Ihnen unsere nächsten Veranstaltungen vorstellen. Außerdem wird es am Ende eine offene Fragerunde geben, falls Sie weitere Fragen haben. Beachten Sie außerdem, dass wir eine Amazon-Geschenkkarte im Wert von 200 Dollar verlosen. Wir werden am Ende dieses Webcasts einen Gewinner auswählen, daher empfehle ich Ihnen dringend, bis zum Ende dabei zu bleiben, damit Sie erfahren, ob Sie der Gewinner sind.
An der heutigen Podiumsdiskussion nehmen Alan Kerr, Senior Solutions Architect bei StablePath, Jim Barnes, IT-Leiter bei RSD, und natürlich ich selbst teil. Eine weitere Sache, die ich hier noch erwähnen möchte: Während wir all dies durchgehen, beachten Sie bitte, dass es hier einen Download-Bereich bzw. einen Anhang-Bereich gibt, in dem Sie die Fallstudie zu RSD sowie die Folien des Webinars, die wir durchgehen werden, herunterladen können.
Während wir die Folien durchgehen, können Sie gerne schon Fragen stellen. Sowohl Jim als auch Alan beantworten gerne Ihre Fragen, sofern diese sich auf ihre jeweilige Erfolgsgeschichte beziehen. Außerdem erhalten Sie nach Ende des Webcasts eine E-Mail von BrightTALK mit einem On-Demand-Link, über den Sie die Aufzeichnung ansehen können, falls Sie dies wünschen. Kommen wir nun kurz dazu, wer RSD ist. Dazu würde ich gerne Jim das Wort übergeben – Jim, bist du da?
Jim Barnes: Ich bin hier.
Sander: Jim, könntest du uns ein wenig über RSD erzählen?
Jim: Ja, mein Name ist Jim. Ich bin seit etwa 17 Jahren bei RSD tätig. Wir sind ein Großhändler für Kältetechnik und HLK-Anlagen, der in über 10 Bundesstaaten vertreten ist und 79 Standorte in den 10 westlichen Bundesstaaten, einschließlich Alaska, unterhält. Das Unternehmen besteht seit 112 Jahren; es begann als Klavierhersteller und stieg in den 30er Jahren in die Kältetechnik ein. Ja, wir expandieren und wachsen. Vor ein paar Jahren sind wir gerade erst nach Colorado expandiert. Dank unserer Technologien konnten wir in verschiedene Märkte vordringen und so weiter. Wir sind ein Familienunternehmen. Ich glaube, der derzeitige Eigentümer gehört bereits zur vierten Generation. Ich freue mich, dass ihr hier seid, um unsere Geschichte zu hören.
Sander: Auf jeden Fall, danke. Ausgezeichnet. Das ist ja eine ziemliche Umstellung, erst im Klavierbereich tätig zu sein und jetzt im Bereich Heizung, Lüftung und Klimatechnik. Das ist wirklich beeindruckend. Ausgezeichnet. Nun geben wir das Wort an Alan Kerr weiter, der uns mehr über StablePath erzählen wird. Alan?
Alan Kerr: Ja, wir sind also ein auf Technik ausgerichtetes Unternehmen. Wir sind auf leistungsstarke, ausfallsichere Infrastruktur spezialisiert. Der Gründer des Unternehmens – er ist ein ehemaliger IT-Leiter – hat es um das Jahr 2000 herum gegründet. Wir realisieren leistungsstarke und ausfallsichere Infrastruktur für Unternehmen jeder Größe, verbringen jedoch in der Regel den Großteil unserer Zeit mit mittelständischen Unternehmen. Unser Hauptsitz befindet sich in Kalifornien, aber wir sind landesweit für jeden tätig, der unsere Dienste benötigt. Dazu gehören Unternehmen, Behörden, gemeinnützige Organisationen und so weiter.
Sander: Ausgezeichnet. Ihr Hauptsitz befindet sich also in Kalifornien. Haben Sie noch weitere Zweigstellen?
Alan: Nein, im Grunde genommen deshalb, weil Ingenieure immer mobil sind. Auch wenn sich der Firmensitz in Kalifornien befindet, arbeiten wir immer vor Ort beim Kunden. Das kann überall im Land sein. Wir haben also nirgendwo bestimmte Standorte.
Sander: Ausgezeichnet. Vielen Dank dafür, Alan. Da wir nun genau wissen, wer unsere Diskussionsteilnehmer heute sind, wollen wir gleich damit beginnen, zu erfahren, wie es dazu kam, wie sie die Lösung gefunden haben, die für ihre spezifische Situation am besten geeignet war, und genau zu sehen, welche Vorteile sie unmittelbar nach der Implementierung dieser Lösung in ihrer Umgebung erzielen konnten.
Zunächst einmal bestand das Problem, so wie ich es verstanden habe, aus drei Aspekten, richtig? Zum einen gab es ein Problem mit der unzureichenden Leistung für das anstehende Projekt. Zum anderen benötigten Sie ein gewisses Maß an Flexibilität, um dies umsetzen zu können. Gleichzeitig gab es Ihr ERP-System, das Redundanz erforderte. Jim, könnten Sie uns bitte etwas mehr dazu erzählen, da Sie an der Suche nach Lösungen für diese Probleme beteiligt waren? Erzählen Sie uns doch bitte etwas mehr darüber, was zu dieser Zeit geschah.
Jim: Ja, vor etwa 8 oder 9 Jahren wollten wir unbedingt in die virtuelle Welt einsteigen. Was die Konfiguration unserer Speichersysteme betraf, hatten wir ein Compellent-System. Wir hatten ein EMC-System und nutzten damals EqualLogic-Speicher. Das Compellent-System diente uns als Unternehmensspeicherlösung für unser ERP-System und Exchange. Dieser Speicher war zwar begrenzt, ermöglichte uns aber den Betrieb unseres ERP-Systems und von Exchange. Um jedoch zu expandieren und eine virtuelle Umgebung einzurichten, mussten wir unsere Speicherkapazität unbedingt erweitern.
Wir stellten fest, dass wir einen Großteil unseres Basisspeichers auf dem EqualLogic betrieben, was wirklich langsam ist. Ein weiteres Problem bei den Compellents war, dass es zwar zwei Controller gab, im Backend jedoch nur einen einzigen Speicher. Wenn dieser Speicher also ausfiel oder – wir hatten sogar Fälle, in denen einer der Controller ausfiel und dadurch den anderen blockierte –, dann war unser Tier-1-Speicher zeitweise praktisch offline.
Also begannen wir, nach einer Lösung zu suchen, die uns die benötigte Geschwindigkeit, die für unsere ESX-Umgebung erforderliche Speicherkapazität und auch die gewünschte Redundanz bieten würde, sodass ein Ausfall einer einzelnen Speicher-Appliance den Betrieb überhaupt nicht beeinträchtigen würde. Also kam Alan vorbei und stellte uns das Angebot von DataCore vor. Es dauerte eine Weile, bis wir den Überblick gewonnen und verstanden hatten, worum es dabei ging, aber sobald wir mit der Umstellung begannen, verlief diese sehr reibungslos. Das System bot uns enorme Flexibilität. So konnten wir zwei separate Speicher-Appliances in einer gespiegelten Konfiguration betreiben. Selbst wenn eine DataCore-Appliance ausfallen sollte, würde das System weiterhin einwandfrei laufen.
Außerdem konnten wir dadurch in die ESX-Welt einsteigen und die virtuellen VMs auf dem Speicher ablegen. Der ESX-Server war zwar über Glasfaser mit beiden Appliances und beiden Speicher-Arrays verbunden, für die ESX-Umgebung war es jedoch immer noch nur eine einzige Appliance. Es spielte also keine Rolle, wenn wir eine Appliance abschalteten. Die andere würde automatisch und ohne Probleme weiterlaufen und dafür sorgen, dass unsere Umgebung weiterhin betriebsbereit bleibt. Das gab uns viel Flexibilität, zum Beispiel bei der Durchführung von Updates an den DataCore-Servern.
Außerdem konnten wir dadurch beliebigen Speicher im Backend einsetzen und bereitstellen – da es sich lediglich um eine anwendungsbasierte Appliance handelt. Man kann ihr tatsächlich einfach jeden beliebigen Speicher zuweisen, und sie würde damit genauso umgehen. Da das Caching und all das über den DataCore-Server lief, wurden auch langsamere Speichermedien beschleunigt. Wir nutzten damals noch rotierende Festplatten, und durch den Cache wirkten diese viel schneller, als sie tatsächlich waren.
Alan: Dazu wollte ich noch etwas hinzufügen. Ich habe bei der ersten DataCore-Implementierung mit Jims Vorgänger zusammengearbeitet, und sie kamen von EMC – sie hatten EMC schon eine ganze Weile genutzt. Sagen wir einfach, es war im Großen und Ganzen keine erfreuliche Erfahrung. Jedes Mal, wenn ein Problem auftrat, gab es support . Es gab Probleme mit der Verfügbarkeit. Damit waren zahlreiche Probleme verbunden.
Als damals die ersten DataCore-Knoten eingeführt wurden, war deren Speicher stark isoliert. Ein Teil der Daten befand sich auf EMC, ein Teil auf Compellent, ein Teil auf EqualLogic. Man musste nicht nur drei verschiedene Datensätze verwalten, sondern es gab auch keine Möglichkeit, Daten zwischen diesen verschiedenen Speicherplattformen zu verschieben. Im Grunde genommen schalteten sie das System ab und kopierten alles rüber. Das führte an sich schon zu Ausfallzeiten, wenn beispielsweise beschlossen wurde, Daten von EMC auf Compellent zu verlagern. Das war also der andere Grund für – oder vielmehr das andere Problem, das es zu lösen galt. Wie kommen wir aus einem Silo-Modell heraus, bei dem Speicher und Schnittstellen überall verstreut sind?
Sander: Ja, hervorragend. Wir werden unseren Zuhörern noch ein paar weitere Details zu dieser Geschichte liefern. Auch was das Projekt zu jenem Zeitpunkt angeht – ihr habt versucht, euch von zyklischen Servern zu lösen und im Grunde etwas Kompakteres zu entwickeln, das auf Hypervisoren läuft, richtig? All diese drei verschiedenen Speichersilos waren also nicht die optimalen Lösungen für das, was ihr erreichen wolltet. Ist das richtig?
Jim: Ja. Der Speicherbedarf für den Betrieb einer virtuellen Umgebung ist viel größer, als wir uns mit einer Lösung wie Compellent leisten könnten, da man dort – man konnte viel weniger nutzen. Mit DataCore kann man kostengünstigeren Speicher nutzen, dabei aber weiterhin redundant bleiben und sich die Speichermenge sichern, die man für den Betrieb einer virtuellen Umgebung benötigt. Wenn man 100 Server betreibt, wird dafür viel Speicherplatz benötigt. Bei Compellent hätten die damit verbundenen Kosten die Obergrenze überschritten, die das Unternehmen eigentlich zu zahlen bereit gewesen wäre.
Sander: Hattet ihr damals schon Veeam-Backups im Einsatz?
Jim: Nein, das war erst viel später. Das war, nachdem wir auf – nachdem wir unsere Umgebung virtualisiert hatten.
Sander: Kommen wir nun zum Teil der Lösungsfindung, an dessen Diskussionen Alan, wie ich weiß, beteiligt war. Erzähl uns doch bitte mehr darüber, wie du das gesehen hast, Alan, als man auf dich zukam und sagte: „Das ist es, was wir versuchen, und das wollen wir mit einem Budget von X erreichen.“ Wie sind deine Gedanken damals verlaufen?
Alan: Es war wahrscheinlich genau umgekehrt. Ich sah, wie sie sich abmühten, und wies darauf hin, dass es auch anders gehen kann. Mit der Zeit – ich meine, anfangs gab es, um ehrlich zu sein, Skepsis, weil EMC ein großer Name ist. Compellent ist eine bekannte Größe. Es ist ein Name. DataCore war damals nicht wie diese anderen. Es war wirklich ein Ansatz nach dem Motto „Probieren geht über Studieren“, bei dem wir klein angefangen haben. Es waren, glaube ich, etwa 8 Terabyte, die gespiegelt wurden.
Es war eine kleine erste Implementierung, die wir durchgeführt haben. Sie war im Grunde so erfolgreich, dass wir das produktive ERP-System darauf migriert haben, aber wir hatten dem Chef nichts davon gesagt. Es lief bereits darauf, und er kam schließlich herein und sagte: „Okay, alles sieht gut aus.“ „Wir können auf das ERP-System umsteigen.“ Und wir wiesen darauf hin – eigentlich waren es Jim und ich, die den Umstieg durchgeführt hatten –, „Oh, es läuft dort schon seit ein oder zwei Tagen.“ Er sagte nur „Gut“ und ging wieder.
Es ging also im Grunde darum, dass sie sich anschauten, was sie tagtäglich durchmachten, mit einigen ihrer Administratoren sprachen und sich ein Bild davon machten, welche Probleme sie in Bezug auf Verfügbarkeit, support und Leistung hatten, um dann – sagen wir mal – ein überschaubares Paket für den Anfang zusammenzustellen. Daraus hat sich dann einfach weiterentwickelt – so wird RSD von nun an den Speicher verwalten.
Sander: Was die Hardware angeht, wofür hast du dich damals entschieden?
Alan: Bei der Erstinstallation handelte es sich um Hewlett-Packard-Server mit MSA-Arrays im Backend. Alles war – die MSA-Arrays hatten keine Controller. Im Grunde handelte es sich um Speicher vom Typ JBOD. Das war in der Anfangsphase. Wie lange lief das, sieben Jahre? Die erste Konfiguration lief also wahrscheinlich sieben Jahre lang. In dieser Zeit hatten wir keine Ausfälle. Dann, in den letzten vielleicht anderthalb Jahren –
Jim: Ja, vor etwa einem Jahr.
Alan: Ja, vor etwa einem Jahr sind wir dann bei den Servern auf Lenovo umgestiegen und nutzen im Backend Violin-Speicher, also eine ältere flash .
Sander: Du meinst also, der HP hat so lange durchgehalten?
Alan: Es befindet sich tatsächlich noch in der Produktion.
Sander: Wow, das nenne ich mal Zuverlässigkeit.
Jim: Ja, wir haben unsere Produktionsumgebung, die wir bei der Umstellung auf die neue Hardware genutzt haben, auf … also, lassen Sie uns kurz zurückgehen, denn wir haben ja bereits darüber gesprochen, was wir hier in unserer Produktionsumgebung haben, aber wir haben auch in Peoria, Arizona, zwei DataCore-Server, und wir replizieren alle unsere Daten von hier nach Peoria. Und das geschieht tatsächlich in Echtzeit.
Während eine E-Mail oder eine Rechnung erstellt wird, werden diese Daten sofort an unseren Notfallstandort übertragen. Wir haben dort tatsächlich zwei Systeme, die sich gegenseitig spiegeln. Wir haben also hier in der Produktion zwei Systeme, die sich gegenseitig spiegeln, und wir haben zwei in Peoria, die sich ebenfalls gegenseitig spiegeln. Wir haben einfach die Hardware, die wir in der Produktion verwendet haben, dorthin verlegt, und es funktioniert hervorragend.
Alan: Bei der Erstinstallation gab es also zwei Knoten auf der Produktionsseite, nämlich die HP-Knoten, die wir gerade erwähnt haben. Auf der Remote-Seite befanden sich alte Dell-Geräte, die auf der Produktionsseite außer Betrieb genommen und dorthin verlegt worden waren. Wir stellten fest, dass bei Upgrades oder ähnlichen Maßnahmen auf der Remote-Seite die Notfallwiederherstellung in solchen Szenarien natürlich unterbrochen würde. Deshalb wurde bei der Aufstellung der Knoten auf der Produktionsseite beschlossen, diese Hardware, die bis zum Zeitpunkt des Austauschs offensichtlich noch den gesamten Betrieb aufrechterhielt, auf die Disaster-Recovery-Seite zu verlegen. Wenn wir nun auf einer der beiden Seiten Updates durchführen, legen wir die Umgebung nicht mehr tatsächlich still. Die Umgebung bleibt rund um die Uhr in Betrieb, unabhängig davon, ob wir Wartungsarbeiten oder Ähnliches durchführen – so gut wie immer.
Jim: Ein weiterer Punkt, der mir das Leben als Administrator dieser Lösung erleichtert hat, ist, dass wir – wie bei jeder Software und jeder Art von Server – die Server aktualisieren müssen. Diese laufen unter Windows, genauer gesagt unter Windows Server 2016, auf dem DataCore läuft. Wie wir alle wissen, müssen wir Windows-Updates durchführen. Wir müssen DataCore-Updates durchführen. Wir können diese Updates durchführen, und wir führen sie tatsächlich tagsüber durch. Wir nehmen einen der Server offline, stoppen den DataCore-Dienst, und die Serverumgebung merkt davon nichts. Die ESX-Umgebung merkt davon nichts. Unser ERP-System – nichts bemerkt überhaupt, dass wir einen dieser Knoten offline nehmen, wenn wir das tun. Wir führen die Arbeiten tagsüber durch, installieren unser Windows-Update, führen unsere DataCore-Updates durch und schalten die Server wieder hoch. Die Synchronisierung läuft wieder, und schon läuft alles weiter, als wäre nichts geschehen. Das reduziert auch deutlich die Zeit, die Ihre Mitarbeiter nach Feierabend vor Ort verbringen müssen, und verhindert, dass sie länger arbeiten müssen. Das ist also ein weiterer echter Vorteil für meine Mitarbeiter, dass wir nicht mehr so oft bis spät in die Nacht arbeiten müssen.
Sander: Das ist doch gut, oder? Ein riesiger Pluspunkt.
Alan: Ich meine, wir nähern uns nun schon auf die 9-jährige Betriebszeit unseres Produktionsspeichers zu.
Jim: Ja, die Speicher-Arrays haben in der Zeit, seit wir sie haben – ich habe noch nie einen Ausfall erlebt – oder besser gesagt: Es ist noch nie vorgekommen, dass beide Knoten gleichzeitig ausgefallen sind. Es ist also immer sichergestellt, dass der Speicher irgendwann wieder verfügbar ist.
Sander: Super. Sie haben also derzeit zwei Kopien in der Produktionsumgebung und zwei weitere Kopien im DR. Ist das richtig? Sie verfügen also über vier Kopien Ihrer Daten?
Jim: Richtig.
Sander: Abgesehen von den Backups?
Jim: Ja, und außerdem nutzen wir Veeam, um Backups auf Festplatte zu erstellen und diese dann von der Festplatte auf Band zu übertragen.
Alan: Dann haben wir also kontinuierliche Daten.
Jim: Und dann haben wir noch die kontinuierliche Datensicherung, die auf DataCore läuft. Die kontinuierliche Datensicherung ermöglicht es Ihnen – mangels eines besseren Begriffs – sozusagen „Rollbacks“ durchzuführen. Sie bietet Ihnen einen bestimmten Zeitraum – es kommt also darauf an, wie viel Speicherplatz Sie dafür bereitstellen. Sie können einen Zeitraum von einem Tag bis zu fünf Tagen festlegen – oder was auch immer Sie dafür vorsehen –, in dem Sie tatsächlich einen Zeitpunkt auswählen, diesen zurücksetzen und einen snapshot und eine Kopie dieses Volumes ab diesem Zeitpunkt erstellen und daraus wiederherstellen. Wenn zum Beispiel Ransomware zuschlägt – also Daten verschlüsselt werden –, können Sie den Zustand vor dem Angriff wiederherstellen, und Ihre Daten stehen Ihnen dann wieder zur Verfügung.
Alan: Dann endet man nicht so wie Baltimore.
Sander: Das ist hervorragend. Ich habe hier eine Frage aus dem Publikum. Die Frage lautet: „Wie weit ist Ihr DR-Standort von Ihrer Produktionsumgebung entfernt?“
Jim: Das sind etwa 350 bis 400 Meilen. Die Strecke verläuft von Peoria, Arizona, bis nach Lake Forest.
Sander: Welche Art von Verbindung besteht zwischen den beiden Standorten?
Jim: Derzeit nutzen wir eine 50-Meg-MPLS-Verbindung und setzen Riverbed Steelheads zur Datendeduplizierung ein.
Alan: Und daran wollen wir auch etwas ändern.
Jim: Ja, ich bereite mich gerade darauf vor, mir eine andere Vorgehensweise anzusehen. Wir erwägen, eine Layer-2-Verbindung zwischen den Standorten herzustellen, die Bandbreite auf 200 MB zu erhöhen und dann einen leistungsstärkeren Riverbed Steelhead einzusetzen, um mehr Durchsatz zu erzielen.
Alan: Das wird es uns ermöglichen, in Zukunft nach Belieben jederzeit auf beiden Seiten virtuelle Maschinen laufen zu lassen.
Jim: Ja, wir könnten tatsächlich immer noch Produktionsumgebungen an unserem DR-Standort laufen lassen. Das gibt uns also diese echte—
Sander: Es handelt sich also nun um eine Umgebung mit mehreren Standorten und hoher Verfügbarkeit.
Alan: Ja, darauf läuft es hinaus – die Idee dahinter ist, dass es keine Rolle spielt, auf welcher Seite eine VM gerade läuft.
Sander: Ausgezeichnet. Noch eine Frage: Was die Art der Bandbreite angeht, über die Sie verfügen, und die Daten, die sich täglich ändern, damit diese Replikation stattfinden kann – wie funktioniert das?
Jim: Ja, wie ich schon sagte, das läuft tatsächlich in Echtzeit ab. In DataCore gibt es sogar eine kleine Anzeige, die anzeigt: Okay, es werden gerade so und so viele Daten an dich gesendet, und so viel Verzögerung hast du. Die Verzögerung beträgt normalerweise nie mehr als 2 oder 3 Sekunden. Das kommt nur dann vor, wenn man eine neue Replikation startet oder wenn man beispielsweise einen Knoten herunterfährt, um Updates daran durchzuführen. Dann kann man beobachten, wie schnell die Replikation wieder läuft und wie viel Datenvolumen dabei anfällt. In solchen Fällen fällt es einem auf, aber im Normalfall kann man dort nachsehen, und es gibt nie eine Verzögerung.
Alan: Wir haben heute Morgen genau darüber gesprochen, als wir uns mit der Einrichtung der Layer-2-Verbindung befasst und versucht haben, den Bandbreitenbedarf zu ermitteln. Die Menge – ich meine, in den letzten vier Wochen betrug die Menge, die der Speicher über die 50-Megabit-Leitung gesendet hat oder zu senden versuchte, knapp über 20 Terabyte. Dank der Deduplizierungsgeräte und einiger Anpassungen auf der DataCore-Seite, um die Deduplizierung zu optimieren, haben wir etwa 18,5 Terabyte auf der Leitung eingespart. Wir haben also in den letzten vier Wochen nur 1,4 Terabyte übertragen. Dank der Deduplizierungsrate, die wir erzielen, und der Effizienz, mit der DataCore die Deduplizierung ermöglicht, entsteht dieses Echtzeit-Gefühl – wissen Sie, deshalb gibt es bei keinem der Volumes jemals Verzögerungen.
Sander: Ich habe hier noch eine weitere Frage an euch, die sich ebenfalls auf dieses Thema bezieht. Wir sehen hier eine Menge Redundanz durch die Hochverfügbarkeit vor Ort, die DR-Lösungen, das CDP und die schlanken Backups. Vielleicht kannst du uns, Jim, erklären, warum es für euer Unternehmen, für eure Organisation so entscheidend ist, über mehrere Kopien eurer Daten zu verfügen. Inwiefern kommt das eurem Geschäftsmodell zugute?
Jim: Was wir wissen, ist, dass es viele verschiedene Möglichkeiten gibt, wie Ihre Daten ausfallen können. Es gibt nicht nur eine einzige Lösung für Backup und Wiederherstellung. Man hat viele verschiedene Möglichkeiten. Wie ich bereits sagte: Wenn man Opfer einer Ransomware-Attacke wird, sollte man CDP nutzen, um den Zustand vor dem Angriff wiederherzustellen. Wenn Daten beschädigt wurden, empfiehlt sich möglicherweise die Wiederherstellung über das Veeam-Backup – sofern die Daten nicht zeitkritisch sind.
Ein weiterer Punkt ist: Im Falle einer tatsächlichen Katastrophe sind die Daten, die Sie hier in Ihrer Unternehmenszentrale haben, – wir müssen davon ausgehen, dass sie verloren gehen. Und bei manchen Dingen müssen Sie möglicherweise ganz auf Band zurückgreifen. Wenn es um die Archivierung geht, haben Sie es vielleicht mit Finanzdaten oder Ähnlichem zu tun, bei denen Sie etwas von vor sieben Jahren benötigen, das Sie auf keine andere Weise speichern. Dann müssen Sie auf Band zurückgreifen. Daher ist es wichtig, das – ich nenne es das „3-Tier“-Modell – zu haben. Ich glaube, das wird dafür verwendet: Man möchte die Originalkopie haben. Man möchte sie auf Festplatte haben, und man möchte sie auf Band haben. Mit DataCore erhalten Sie diese vierte Option, nämlich CDP, das Rollback. Das ist nun etwas, das bei einer kurzfristigen Wiederherstellung zum Einsatz kommt, denn man erhält damit nicht die Daten einer ganzen Woche. Man erhält auch nicht die Daten eines ganzen Monats. Man erhält Daten für einige Tage oder vielleicht eine Woche.
Jede Wiederherstellungssituation ist definitiv anders, und man muss bereit sein. Man muss auf jede dieser Situationen vorbereitet sein und wissen, wie man die Daten am effizientesten wiederherstellt. Bei der Sicherung auf Band dauert die Wiederherstellung ewig, während man mit dem Veeam-Backup, CDP oder einem snapshot– snapshots lassen sich snapshots ebenfalls erstellen – viel schneller vorankommt. Bevor Sie also ein Projekt starten oder ein Upgrade durchführen, können Sie einen snapshot erstellen. Wenn etwas schiefgeht, führen Sie einfach ein Rollback von diesem snapshot durch, und schon sind Sie wieder im Ausgangszustand. Jedes Szenario hat seine eigenen Herausforderungen, und diese verschiedenen Möglichkeiten zur Sicherung und Wiederherstellung sind definitiv ein Muss.
Alan: Ich musste mich eigentlich schon mit dieser Frage auseinandersetzen, als wir zum ersten Mal über DataCore, Spiegelung, die Einführung von CDP und einige dieser anderen Funktionen gesprochen haben. Tatsache ist: Wenn ich die Daten spiegele, beanspruche ich wieder denselben Speicherplatz. Wenn ich CDP einsetze, beanspruche ich nun einen zusätzlichen Prozentsatz an Speicherplatz. Die Frage, die sich daher zunächst stellte – und das war noch einmal, bevor Jim das Ruder übernahm –, lautete: Warum brauche ich all diese Kopien meiner Daten? Meine Antwort damals lautete: Es ist das Einzige, was die Versicherungsgesellschaft Ihnen nicht zurückgeben kann. Sie kann Ihnen mehr Software und mehr Hardware geben. Sie kann Ihnen ein weiteres Gebäude zur Verfügung stellen. Sie kann Ihnen Server geben. Sie kann Ihnen das Geld geben, um den Vertrag für eine neue Kommunikationsleitung abzuschließen. Aber das Einzige, was sie Ihnen nicht geben kann, sind Ihre Daten. Entweder Sie haben sie, oder Sie haben sie nicht.
Die Richtlinie lautet fortan, dass in dieser Umgebung alles gespiegelt wird. Wir verfügen in der Umgebung über mindestens eine weitere physische Kopie davon. Darüber hinaus muss entschieden werden: Wird dies per CDP gesichert? Wird es auf Band gesichert? Wird davon ein Backup erstellt? Wie wichtig sind diese Daten? Das Minimum ist jedoch, dass sie gespiegelt werden.
Jim: Ja, da fällt mir tatsächlich eine Geschichte ein. Das ist wahrscheinlich vor fünf oder sechs Jahren passiert. Wir hatten eines unserer Exchange-Volumes. Wir betreiben nämlich etwa fünf verschiedene Datenbanken für unser Exchange, und eine dieser Datenbanken – nur eine davon – war beschädigt. Nachdem wir festgestellt hatten, was passiert war, konnten wir ein Rollback nur für dieses einzelne Datenbank-Volume durchführen, da wir sie in DataCore getrennt hatten – jede Datenbank hat ihr eigenes Volume. Wir konnten ein Rollback durchführen und einen snapshot erstellen, die Datenbank wieder mit Exchange verbinden, noch bevor wir sie tatsächlich als vollständige Kopie zurückhatten, und konnten diese Datenbank wieder online schalten, während sie gerade in die vollständige Kopie zurückgeschrieben wurde.
Sobald man einen snapshot erstellt hat, muss dieser natürlich einen bestimmten Prozess durchlaufen, damit er zu einer echten Live-Datenbank wird und nicht nur ein snapshot bleibt. Wir konnten den snapshot bereits snapshot den Exchange-Server anhängen, noch bevor dieser Prozess abgeschlossen war, und den Vorgang dann im Hintergrund ablaufen lassen. So konnten wir die Datenbank wiederherstellen, sobald wir festgestellt hatten, dass sie beschädigt war – und dass wir innerhalb von fünf Minuten ein Rollback durchführen mussten.
Alan: Außerdem haben wir festgestellt, dass dabei keine Daten verloren gegangen sind. Von dem Zeitpunkt an, als wir die Entscheidung getroffen hatten, das Ganze rückgängig zu machen – also ein Rollback durchzuführen und die beschädigte Version zu löschen –, hat das Ganze, glaube ich, von Anfang bis Ende vielleicht fünf Minuten gedauert.
Sander: Du meinst also, du musstest dein Veeam-Backup gar nicht nutzen, sondern hast stattdessen das CDP von DataCore verwendet?
Jim: Ja, dafür haben wir DataCore CDP verwendet, denn wir wussten – noch einmal: Hätten wir auf ein anderes Produkt zurückgreifen müssen, hätten wir zu diesem Zeitpunkt Daten verloren, da wir auf den Stand vom Vorabend zurückgesetzt hätten. Alle E-Mails, die an jenem Morgen vor dem Datenverlust eingegangen waren, wären verloren gegangen.
Alan: Ja, Veeam war nicht detailliert genug.
Jim: Ja, das führt uns wieder zu derselben Frage zurück: Warum gibt es all diese verschiedenen Backup-Lösungen? Nun, jede hat ihre eigenen, einzigartigen Vorteile, und dank CDP konnten wir – wir konnten den Zeitpunkt ermitteln, zu dem die Beschädigung begann, auf den Zeitpunkt unmittelbar davor zurücksetzen, und das, ohne auch nur eine einzige der E-Mails zu verlieren, die heute Morgen eingegangen waren, bevor die Beschädigung auftrat.
Sander: Ausgezeichnet. Das finde ich großartig. Das ist wirklich beeindruckend, denn die meisten Rechenzentren – oder besser gesagt, die meisten IT-Administratoren – hätten sofort auf das Backup von diesem Morgen zurückgreifen müssen, und wie Sie sagten, hätten sie dabei mehrere Stunden an Daten verloren. Das ist also toll zu hören. Noch kurz zu einer anderen Sache – Sie hatten eine Geschichte über einen Elektriker erwähnt, der bei der Neuverkabelung einen Fehler gemacht hat. Können Sie uns ein wenig mehr darüber erzählen, wie das passiert ist und ob DataCore den Betrieb aufrechterhalten hat oder nicht?
Jim: Ja, in dieser Situation war ein Elektriker vor Ort, der einige Verkabelungsarbeiten durchführte. Wir nennen ihn jetzt „Sparky“. Er war gerade dabei, ein paar Steckdosen einzubauen, und dabei hat er etwa die Hälfte der Sicherungen in unserem Rechenzentrum ausgelöst. Das hat einen ziemlich großen Teil davon lahmgelegt. Da wir die DataCores im Rechenzentrum so voneinander getrennt haben – natürlich an verschiedenen Sicherungen und in verschiedenen Bereichen des Rechenzentrums –, konnten wir – ich glaube, einer von ihnen ist tatsächlich ausgefallen, aber der andere blieb in Betrieb. Was diese Daten angeht – wir hatten nie eine Situation – um noch einmal darauf zurückzukommen – wir hatten nie eine Situation, in der beide DataCore-Server gleichzeitig ausgefallen wären. Wir konnten also die Stromversorgung wiederherstellen und den Server hochfahren. Sobald wir ihn wieder eingeschaltet hatten, synchronisierte er alles mit dem DataCore-Server, der in Betrieb geblieben war, und es gingen keine Daten verloren, noch gab es irgendwelche bleibenden Auswirkungen.
Sander: Das ist toll. Wenn Ihr System nun 5 oder 6 Stunden lang ausgefallen wäre, was hätte das für Ihr Unternehmen bedeutet? Wie hätte sich das auf Ihr Unternehmen ausgewirkt?
Jim: Ja, ich denke, wenn die Filialen keine Bestellungen aufgeben und den Kunden nicht helfen können, entstehen immer finanzielle Kosten – und nicht nur finanzielle. Es geht auch um das Vertrauen der Kunden. Wenn sie in die Filiale kommen, wollen sie sicher sein, dass sie das bekommen, was sie brauchen. Es geht also um Vertrauen: dass der Betrieb läuft und man seinen Kunden helfen kann.
Sander: Ausgezeichnet. Vielen Dank für all diese Beiträge. Ich habe noch eine Frage aus dem Publikum zum Migrationsprozess. Es wurde gefragt, wie schwierig die Migration vom alten Speichersystem zu DataCore war.
Jim: Der Prozess, den Sie durchlaufen, wenn Sie Daten von einem beliebigen Speichermedium in DataCore migrieren – im Wesentlichen stellen Sie den Speicher DataCore zur Verfügung, und dann folgt ein Vorgang, bei dem der sogenannte Passthrough-Modus aktiviert wird. Dieser ermöglicht es Ihnen, die Daten währenddessen in DataCore zu verschieben, wobei die Daten zwar durch DataCore geleitet werden, sich aber weiterhin auf dem bestehenden Speichermedium befinden. Anschließend spiegeln Sie die Daten auf einen anderen Server, und dann führen Sie eine Ausfallumschaltung vom bestehenden – dem alten Speicher – auf den gespiegelten Speicher durch, ähnlich wie bei der Abschaltung eines Servers und dem Hochfahren eines Spiegelservers. Danach spiegeln Sie die Daten zurück auf die zweite Kopie. Wir haben die Migration tatsächlich durchgeführt, ohne dass die Systeme währenddessen ausfielen. Wir mussten für diese Migration nie etwas abschalten. Es geschah also tatsächlich alles, während der Betrieb weiterlief.
Alan: Das war alles tagsüber.
Jim: Das findet alles tagsüber statt.
Sander: Wow, das ist wirklich beeindruckend. Es ist erstaunlich, welche Geschichten wir immer wieder von unseren Kunden hören. Sie sind einfach beeindruckend. Und wenn ich höre, wie Sie all das erwähnen, wird mir wieder bewusst, worin die tatsächlichen Vorteile bestehen – es geht um mehr als nur Technologie, sondern um die Vorteile, die wir unseren Endnutzern bieten können, um nicht nur ihre Geschäftsabläufe zu optimieren, sondern auch Ihnen die Arbeit zu erleichtern. Vielen Dank also für all dieses Feedback.
Wir gehen nun zur nächsten Folie über. Könnten Sie, Alan – oder Sie beide –, uns kurz etwas mehr zu jedem dieser Punkte sagen? Sie verfügen nun über eine einzige Plattform, die alle Ihre Datendienste bereitstellt, während Sie zuvor mehrere Silos hatten. Und wir sprechen hier von einer Entfernung von 400 Meilen, über die hinweg Sie diese Leistung erzielen. Erzählen Sie uns doch bitte etwas mehr über diese Leistung in Bezug auf Ihr ERP-System. Inwiefern hat sich diese verbessert?
Alan: Eine der Veränderungen im Laufe der Zeit war, dass das ERP-System früher auf einem eigenen dedizierten Server lief und die Speicherung auf DataCore erfolgte. Davor befand es sich auf den EMC- und Compellent-Systemen, über die wir gesprochen haben. Uns war es besonders wichtig, sicherzustellen, dass die Datenbank, die dem ERP-System zugrunde liegt, eine Progress-Datenbank ist. Wir wollten sicherstellen, dass das System auch nach der Migration auf eine virtuelle Maschine einwandfrei funktioniert.
Irgendwann fiel die Entscheidung, dass RSD Progress direkt beauftragen sollte, einen Test durchzuführen. Die Ergebnisse – und das habe ich tatsächlich auch bei einem anderen Kunden erlebt, der Progress in derselben Umgebung einsetzte – führten in beiden Fällen zu der Reaktion: „Wie sind Sie auf diese Zahlen gekommen? Denn solche Zahlen sehen wir sonst nicht.“ Was machen Sie, damit es so schnell läuft?“ Das war also quasi das Startsignal, das System von einer dedizierten physischen Bare-Metal-Hardware zu virtualisieren und auf den heutigen Stand zu bringen.
Sander: Alan, von wem stammte dieses Feedback? Vom Softwareanbieter?
Alan: Ja, der Anbieter der Software-Datenbank, nämlich Progress. Die waren neugierig, wie wir diese Zahlen überhaupt erreichen konnten, denn wenn sie sich solche Dinge anderswo ansehen, haben sie solche Zahlen noch nie zuvor gesehen. Diese Rückmeldung habe ich tatsächlich auch von einem anderen Kunden erhalten, der denselben Test direkt mit Progress durchgeführt hat. Wir waren daran nicht beteiligt. Die haben einfach den Test durchgeführt, den sie normalerweise durchführen, also die üblichen Lasttests.
Sander: Erinnerst du dich vielleicht noch an die Zahlen?
Alan: Nein, wir reden hier von vor Jahren.
Sander: Das ist schon eine ganze Weile her. Ausgezeichnet. Jim, wir haben bereits kurz über Veeam gesprochen. Können wir das Thema noch etwas näher ausführen? Soweit ich weiß, hatten Sie Veeam zunächst nicht, haben das Unternehmen aber irgendwann übernommen – auf welche Art von Datenträgern haben Sie damals Ihre Backups gespeichert?
Jim: Ja, als wir mit Veeam angefangen haben, haben wir kostengünstigen Speicher genutzt und die Backups einfach darauf ausgeführt. Während dieses Upgrade-Prozesses haben wir beschlossen, – wir hatten bei unserem Upgrade noch etwas zusätzliche Hardware aus unserem Produktionsbereich übrig – einen zusätzlichen Server und etwas Speicher zu nutzen. Wir beschlossen, DataCore auszuprobieren, um die Backups – also die Veeam-Backups – auf einer DataCore-Plattform auszuführen, anstatt, ich glaube, den JBOD-Speicher, also das Synology-Gerät, zu nutzen. Als ich den Kollegen hatte, der die Veeam-Backups für mich durchführt – er kannte die Zahlen ziemlich gut und hat sich angesehen, wie lange die Backups auf den Synology-Speicher dauerten –, haben wir angefangen, sie auf DataCore auszuführen, mit all seinen…
Alan: Der entscheidende Vorteil war die Caching-Funktion, durch die die Daten viel schneller eingelesen werden konnten. Ich glaube, die Geschwindigkeit war dreimal so hoch, als wir das überprüft haben.
Jim: Ja, das haben wir dann auch gemacht. Er meinte, die Backups auf diesem Server liefen etwa dreimal schneller als auf dem Synology-Gerät.
Alan: Und er hatte alle Zahlen parat. Er hat uns das in einer Art Diagramm präsentiert, denn er hatte daran gearbeitet und verschiedene Arten von Veeam-Backups durchgeführt, und zwar auf unterschiedlichen Rechnern. Er hat sozusagen einen umfassenden Querschnitt durch die verschiedenen Methoden erstellt, mit denen sie Produktions-Backups durchführen würden, und es war deutlich schneller. Daher lautete die Entscheidung letztendlich einfach, es auf diesem separaten DataCore-Knoten zu belassen.
Die Hardware stammte aus der Zeit, als wir – sagen wir mal – die alten Produktionsgeräte an den DR-Standort transportiert haben. Wir haben nicht alle Arrays transportiert, aber wir brauchten am Disaster-Recovery-Standort auch nicht so viel Platz. Also haben wir diese Geräte gewissermaßen wieder in Betrieb genommen und sie hinter diesem Knoten im Wesentlichen als Backup-Ziel eingerichtet. Was die Lizenzierung angeht – wir haben die Lizenzen einfach ein wenig erweitert und diesen Knoten mit einbezogen.
Die Lizenzierung ist mittlerweile ziemlich einfach, denn es kommt ausschließlich darauf an, wie viel Speicherplatz man hat. Das ist alles. Das ist der einzige Punkt, über den man sprechen muss. Wenn wir also einen bestimmten Wert erreichen – also eine intern festgelegte Obergrenze, ab der wir mehr Speicherplatz benötigen –, dann bestellen wir einfach weitere Lizenzen.
Sander: Muss man aus Hardware-Sicht ein neues Gehäuse kaufen? Wie funktioniert das?
Alan: Auf der Produktionsseite wird alles auf der Violin-Seite dedupliziert. Wir müssen also weiterhin DataCore-Lizenzen erwerben, wenn wir weitere Kapazitäten hinzufügen, aber im Backend verläuft das Wachstum aufgrund der Deduplizierung extrem langsam. Wir rechnen daher auf dieser Seite jedenfalls für lange Zeit mit keinem Bedarf. Wenn wir also etwas hinzufügen, betrifft das lediglich DataCore, also den Bereich der Softwarelizenzen. Was die Backup-Seite angeht, glaube ich nicht, dass wir dort noch etwas benötigen werden, aber falls doch, würden wir einfach ein weiteres einfaches JBOD-Array anschaffen und es hinten anschließen – so würden wir wahrscheinlich vorgehen.
Jim: Ja, wenn der Speicherplatz knapp wird und es sich um herkömmlichen Festplattenspeicher handelt, muss man natürlich Hardware hinzufügen. Das Besondere an DataCore ist, dass man – wir betreiben beispielsweise D2700-Systeme – ein anderes Speicherarray hinzufügen kann, und DataCore ist es völlig egal, um welches es sich handelt. Man stellt es ihm einfach zur Verfügung, und es verwaltet es. Es spielt also keine Rolle, ob man HP-Speicher oder EqualLogic-Speicher einsetzt. Man kann ein Compellent-System dahinter schalten. Man kann ein EMC-System dahinter schalten. Man kann alles dahinter schalten, was man will. Es wird alles auf die gleiche Weise verwalten. Dank des integrierten Caching-Mechanismus beschleunigt es selbst langsamen Speicher.
Alan: Es gibt allerdings einen Punkt, wenn man die aktuelle Produktionsumgebung mit der vorherigen vergleicht. Das Wichtigste ist, dass wir nicht wirklich mit irgendetwas durchkommen, oder? Die neue Produktionsumgebung mit all den SSDs deutlich schneller als die alte, denn einer unserer Administratoren hat angemerkt, dass alles ruckfrei läuft. Und das ist jemand, der solche Komplimente nicht leichtfertig macht.
Der DataCore macht einen guten Eindruck, wenn man ihn auf guter Hardware einsetzt, und wenn man ihn auf erstklassiger Hardware einsetzt, sieht er großartig aus. Die derzeitige Infrastruktur, über die sie verfügen – wie ich bereits sagte, gehen wir davon aus, dass wir diese vorerst nicht erweitern werden, einfach weil wir über reichlich Leistung und genügend Speicherplatz verfügen. Wenn wir erweitern würden, wäre das lediglich eine Frage des Speicherplatzes. Es ist sicherlich keine Frage der Leistung. Wir könnten das System viel, viel stärker auslasten, als es derzeit der Fall ist.
Sander: Du meinst also, je nach Anwendungsfall sollte man entsprechend in die richtige Hardware investieren, um diesen Anforderungen gerecht zu werden, richtig?
Alan: Genau. Wenn man sich zum Beispiel den Backup-Teil unseres Themas ansieht: Das ist natürlich deutlich einfachere Hardware als die anderen Komponenten, aber dank der DataCore-Software macht sie einen ziemlich guten Eindruck – vor allem, weil sie im Grunde speziell für diesen Zweck entwickelt wurde und das RAID sowie alles andere so ausgelegt ist, dass es ausschließlich für Backups gedacht ist. Das funktioniert in dieser Umgebung also hervorragend und ist zudem kostengünstig.
Was die Produktion angeht – wir haben dort einige Dinge eingebaut, die wohl besser sind. Das bedeutet, dass wir im Grunde nie eine Diskussion über die Leistung führen müssen, warum etwas langsam ist. Das war im Grunde genau das, was wir damit erreichen wollten – dass die einzige Frage, die wir uns stellen, lautet: Haben wir genug Platz? Und genau so wurde es auch konzipiert.
Sander: Ausgezeichnet. Was Ihre Internetverbindung in diesen neun Jahren angeht: Welche Verbindung nutzen Sie?
Jim: Bei DataCore war es schon immer Fibre Channel. Ja, wir arbeiten mit 8 Gigabit.
Sander: Welche Art von Verbindung besteht zwischen DataCore und Ihrem ESX-Host?
Jim: Das ist auch Ballaststoffe.
Sander: Ausgezeichnet. Ja, ihr habt da definitiv eine solide Basis, die euch den gesamten Durchsatz bietet, den ihr braucht.
Alan: Nun, ein Grund, warum wir uns für Fibre Channel entschieden haben, ist die Vorstellung, dass wir nie darüber diskutieren müssen, warum etwas funktioniert oder nicht funktioniert, denn Fibre Channel läuft Fibre Channel .
Sander: Zumindest für mich persönlich wäre das immer meine erste Wahl, aber wir sehen ja, dass iSCSI genauso gut iSCSI , oder? Auch hier kommt es wieder ganz darauf an, um welche Art von—
Alan: In der DataCore-Umgebung haben wir unsere iSCSI aus bestimmten Volumes bereitgestellt, wie zum Beispiel für die Desktops der Administratoren. Wir sichern Dateien und Ähnliches. Das machen wir also hin und wieder, aber aus produktionstechnischer Sicht – wenn man nur von der Produktionskonnektivität spricht – läuft in dieser Umgebung alles über Fibre Channel. Wir nutzen iSCSI wir vorübergehend etwas zusätzlichen Speicherplatz benötigen. Außerdem diente es in der Vergangenheit für bestimmte administrative Aufgaben, bei denen wir den Administratoren Speicherplatz zur Verfügung stellen mussten.
Sander: Ich habe hier eine Frage, und vielleicht kannst du sie beantworten, Alan. Auf welcher Betriebssystemplattform läuft DataCore? Ist es Linux, Windows oder ein proprietäres Betriebssystem?
Alan: Es läuft unter Windows, und der Grund dafür ist, dass es der einzige verfügbare Echtzeit-Kernel ist – zumindest der einzige, der kommerziell erhältlich ist. Linux verfügt über keinen Echtzeit-Kernel, daher verwenden wir es derzeit nicht. Das könnte sich in Zukunft ändern, sobald ein solcher verfügbar wird. Hinzu kommt: Wenn man einen Windows-Server hat, gibt es kein Speichermedium auf der Welt, mit dem es nicht kompatibel wäre. Man hat also ultimative Flexibilität, was auch immer man dahinter anschließen möchte. Wir haben das nun zumindest als Option, die wir in Betracht ziehen können, wenn wir eine Erweiterung oder Änderung an der Hardware in Betracht ziehen.
Sander: Vielen Dank für diese Antwort. Wir gehen nun kurz zur nächsten Folie über und sprechen über die Ergebnisse – hier nur eine kurze Zusammenfassung. Ihr habt es geschafft, diese Flexibilität zu gewinnen, um weiterhin einige der neuesten Speichersysteme am DR-Standort zu nutzen, alles zu erreichen, was ihr an eurem Produktionsstandort erreichen wolltet, über die gesamte erforderliche Redundanz zu verfügen und eure Investitionen in Speicher-Arrays kosteneffizienter zu gestalten. Insgesamt scheint es, als hätten wir alle Anforderungen erfüllt. Möchtest du dem noch etwas hinzufügen, Alan?
Alan: Nein. Ich glaube, irgendwann haben wir Anforderungen erfüllt, von denen man anfangs gar nicht davon ausgegangen war, dass sie realisierbar wären. Zum Beispiel die Wiederherstellung von Daten ohne jeglichen Datenverlust. Bevor wir CDP überhaupt aktiviert hatten, ging man davon aus, dass es bei einer Beschädigung zu Datenverlusten kommen würde, da man auf einen anderen Zeitpunkt zurückgreifen muss – sei es ein snapshot die Wiederherstellung von Band snapshot ein anderer Mechanismus aus der Sicherung des Vortags. Viele dieser Dinge sind mittlerweile zu Anforderungen geworden, die es anfangs noch gar nicht gab.
Sander: Super. Hier gab es eine Frage zu Veeam. Jim, vielleicht kannst du darauf eingehen. Ich kenne die Antwort zwar, aber ich überlasse dir die Beantwortung. Wir haben noch acht Minuten Zeit, wenn du dir also ein paar Sekunden Zeit nehmen könntest, um diese Frage zu beantworten – sie lautet: „Worauf hast du deine Entscheidung gestützt, dich für Veeam statt für andere Lösungen zu entscheiden?“
Jim: Ich glaube, früher haben wir – wir nutzen eigentlich zwei verschiedene Lösungen – früher haben wir auch Backup Exec verwendet. Wir hatten tatsächlich eine gemischte Umgebung, aber als wir auf Virtualisierung umgestiegen sind – als wir zu einer zu 99 % virtuellen Umgebung übergegangen sind –, haben uns die Flexibilität von Veeam und einige seiner Funktionen überzeugt – zum Beispiel nutzen wir Veeam auch, um virtuelle Maschinen nach Peoria zu replizieren. Während wir also mit DataCore Daten nach Peoria übertragen, nutzen wir Veeam zusätzlich, um die gesamte VM nach Peoria zu replizieren. Dadurch können wir sie in einer virtuellen Umgebung auf einem ESX-Server bereitstellen, wo sie startbereit ist, sich aber im ausgeschalteten Zustand befindet. Veeam bietet uns also diese Möglichkeit, diese Server bereitzuhalten. Das funktioniert zwar nicht in Echtzeit wie bei DataCore, aber für die Server, bei denen sich die Daten nicht oft ändern – wie zum Beispiel Druckserver und Ähnliches –, nutzen wir diese Lösung. Das setzen wir ein.
Der Server steht einfach da und wartet darauf, eingeschaltet zu werden. Das ist also eine der Funktionen, die uns daran besonders gut gefällt. Und auch die Datendeduplizierung funktioniert wirklich gut. So benötigt man auch für die Backups deutlich weniger Speicherplatz. Aber ja, für uns ist es ein großartiges Produkt. Wir finden, dass es viel besser ist als Backup Exec, das wir früher verwendet haben.
Sander: Super. Vielen Dank für diese Antwort, Jim. Das scheint eine großartige Kombination zu sein: Jim kümmert sich um die VM und DataCore um die riesigen Datenmengen im Terabyte-Bereich. Die beiden ergänzen sich also hervorragend.
Jim: Auf jeden Fall, auf jeden Fall. Ja.
Sander: Alles klar, hervorragend. Ich möchte kurz noch einmal darauf eingehen – wissen Sie, um ein wenig näher darauf einzugehen, was software-defined storage . Praktisch gesehen schaffen wir eine intelligente Ebene, die es Ihnen ermöglicht, all diese Datendienste zu nutzen, die Ihre herkömmliche Hardware wahrscheinlich nicht von Haus aus bietet. Sie verfügen nun also nicht nur über all diese Datendienste, sondern können diese auch auf jeden physischen Speicher anwenden, der unter DataCore läuft. Jetzt können Sie Ihren gesamten Speicher über eine einzige Benutzeroberfläche verwalten. Das betrifft nicht nur die Verwaltung und die Dienste, sondern auch die Möglichkeit, alle Ihre Arrays zu konsolidieren.
Wie Sie in Jims Bericht gehört haben, erstellen wir mehrere redundante Kopien – egal, ob es zwei oder drei Kopien sind, ob Sie eine Notfallwiederherstellung an einem physischen Standort oder in der cloud– und wir ermöglichen all diese Optionen. Wir bieten Ihnen die nötige Flexibilität, und es handelt sich um bewährte Funktionen. Jim hat über CDP und einige andere Lösungen gesprochen. Ich würde also definitiv jedem hier empfehlen, sich damit auseinanderzusetzen.
Wir sind nun schon seit 20 Jahren im Geschäft und haben weltweit über 10.000 Kunden, die uns stets treu bleiben – unsere Vertragsverlängerungsquote liegt bei 95 %. Wenn Sie einmal ins sonnige Florida kommen möchten: Unser Firmensitz befindet sich in Fort Lauderdale. Wir würden uns auf jeden Fall sehr freuen, mit allen zu sprechen, die von unseren Leistungen profitieren können. Wir helfen gerne weiter. Das ist unsere Aufgabe, und deshalb wurden wir bereits fünfmal als „Speicherprodukt des Jahres“ ausgezeichnet. Wenn Sie weitere Informationen benötigen, können Sie uns eine E-Mail an info@datacore.com senden.
Lassen Sie mich das kurz zusammenfassen. Wir sind davon überzeugt, dass sich Speicherlösungen weiterentwickeln können, nicht wahr? software-defined storage diese Weiterentwicklung und bietet Ihnen die Flexibilität, Ihre Umgebung von verschiedenen Standorten aus, mit unterschiedlichen deployment und verschiedenen Architekturen zu erweitern – und dabei nutzen Sie weiterhin dieselbe Software, nämlich die von DataCore.
Auch hier haben Sie die Möglichkeit, diese Präsentationen herunterzuladen, damit Sie sich die Folien noch einmal ansehen und prüfen können, ob Ihnen das in Ihrer aktuellen Situation weiterhilft. Hier sind einige Zitate von Jim. Ich möchte mich bei Ihnen beiden – bei Jim und bei Alan – dafür bedanken, dass Sie heute hier sind. Ich weiß Ihre Beiträge sehr zu schätzen.
Also gut, dann lassen Sie uns nun den Gewinner ermitteln. Wir haben noch drei Minuten Zeit, und wir werden einen Gewinner auswählen. Geben Sie mir bitte noch ein paar Sekunden. Mal sehen, wer der glückliche Gewinner einer Amazon-Geschenkkarte im Wert von 200 Dollar ist. Die geht an Railene Schubert. Sie erhalten eine E-Mail mit allen Informationen zum Herunterladen der Geschenkkarte. Herzlichen Glückwunsch!
Noch einmal: Wenn euch diese Geschichten gefallen, möchte ich euch ermutigen, weiterhin an all diesen Webinaren teilzunehmen. Unser nächstes Webinar findet am 26. Mai um 14:00 Uhr statt. Zu Gast wird unsere Partnerin von Tri Delta sein. Wir werden über das YMCA von Long Island sprechen und mehr über dessen Geschichte erfahren. Diese wird sich höchstwahrscheinlich deutlich von Jims Geschichte unterscheiden, aber ihr solltet unbedingt dabei sein, wenn ihr genau sehen wollt, was DataCore für diese Organisationen leistet.
Hier ist noch einmal Sander von DataCore. Denken Sie daran: Sie können sowohl die Präsentation als auch die Fallstudie herunterladen. Gehen Sie dazu einfach zum Abschnitt „Anhänge“, dort finden Sie die entsprechenden Links. Vielen Dank für Ihre Zeit. Bis zum nächsten Mal – ich wünsche Ihnen einen schönen Tag.