von Redaktion IT-A…
Lesezeit
3 Minuten
Seite 2 - Monitoring, Backup und Recovery in virtualisierten Umgebungen (1)
Kommt hingegen eine asynchrone Replikation zum Einsatz, werden die Daten immer auf System A geschrieben und erst zeitlich verzögert auf System B übertragen. Dies hat den Vorteil, dass die VM aus unserem Beispiel nicht auf beide Storage-Systeme warten muss, sondern nur auf System A. Die Latenz zwischen den beiden Storage-Systemen beeinflusst somit die Geschwindigkeit der VM nicht. Der Nachteil eines solchen Aufbaus ist, dass die Daten auf System B immer veraltet sind und nicht den Live-Stand enthalten. Abhängig von der zeitlichen Differenz gegenüber System A sind hier unter Umständen wichtige Daten (noch) nicht übertragen worden, falls System A einmal ausfällt.
Die Möglichkeiten und Funktionen, die Sie mit Stretched Storage erhalten, unterscheiden sich enorm voneinander. Manche Systeme können bei einem Ausfall den Partner automatisch online und in den Betriebsmodus schalten, andere brauchen für diesen Vorgang einen manuellen Eingriff. Manche Storage-Systeme, die über zwei oder mehr Räume verteilt werden, sind aus Hypervisor-Sicht nur ein einziges logisches System. Solche Systeme sind unserer Erfahrung nach einfacher einzubinden, da der Cluster nur ein Storage-System kennt und dieses zur Speicherung der VM-Daten nutzt.
Manchmal arbeiten die Hersteller hier auch kleine Optimierungen ein, sodass zum Beispiel durch einen Treiber die Latenzen zu den physischen Einheiten gemessen werden und der Hypervisor immer mit dem Storage-System spricht, das eine kleinere Latenz hat. Durch diese Technik sollen die Systeme stets mit dem Storage-Kopf am lokalen Standort sprechen und es soll keine Kommunikation eines Servers in Raum A zum Storage-System in Raum B geben, da häufig die Bandbreite in einem Raum höher ist als zwischen den Räumen. Kommt es zum Ausfall des Storage-Systems in Raum A, wird erst dann auf den Speicher in Raum B zugegriffen, sofern dies noch möglich ist. Häufig führen solche Features allerdings auch dazu, dass sich der Preis für solch eine Lösung deutlich erhöht.
Egal für welche Lösung Sie sich entscheiden, Sie sollten gerade bei Ihrem Storage-System genau definieren, welche Anforderungen Sie haben und ob sich diese mit Ihrem Budget vereinbaren lassen. Der Betrieb über zwei Räume führt eigentlich immer dazu, dass sich die Kosten für solch ein Projekt nicht nur verdoppeln, sondern vervielfachen.
Redundanz im Netzwerk
Das Netzwerk in Ihrem Datacenter ist eine der Kernkomponenten, die am besten niemals ausfällt. Um dieses Ziel zu erreichen, lässt sich auch hier mit einer Redundanz arbeiten. Zwei und mehr Enterprise-Geräte lassen sich über unterschiedliche Technologien zu einem logischen Verbund zusammensetzen. Die genaue technische Lösung hängt häufig davon ab, welcher Hersteller zum Einsatz kommt.
Sie sollten bei der Planung und dem Aufbau Ihres Backbone-Netzwerks einige Dinge berücksichtigen. Dies beginnt damit, dass Sie die Bandbreite der Geräte betrachten. 10 GBit/s im Backend ist aktueller Standard. In den letzten 18 Monaten gab es allerdings eine ziemlich große Bewegung in diesem Bereich, Switches mit 25, 50 und 100 GBit/s pro Port sind preislich so attraktiv geworden, dass einige Unternehmen das Core-Netzwerk oder Teile davon auf 100 GBit/s aufrüsten. Diese Bandbreite ist in den meisten Umgebungen für die nächsten Jahre vollkommen ausreichend und bietet nebenbei auch noch den Vorteil, dass sich ein 100 GBit/s-Port mit Breakout-Kabeln auf zwei 50-GBit/s- oder vier 25-GBit/s-Ports splitten lässt. Mit Hilfe dieser Technik wird aus einem Switch mit 16 Ports, die mit 100 GBit/s arbeiten, ein Gerät mit bis zu 64 Ports mit jeweils 25 GBit/s. Falls Sie nun direkt an extrem hohe Preise für solches Equipment denken: Enterprise-Geräte mit diesen Eigenschaften liegen teilweise im vierstelligen Preissegment.
Zwei dieser Geräte sorgen dafür, dass vor Ort eine Redundanz besteht. So können Sie Server mit einem NIC-Team in jeweils einen Switch stecken. Damit sind die Systeme auch dann noch online, wenn im Netzwerk ein Gerät ausfällt oder durch ein Update temporär nicht zur Verfügung steht. Achten Sie vor der Anschaffung darauf, wie und mit welchen Abhängigkeiten Sie solch ein Update machen können. Denn uns sind auch Switch-Modelle bekannt, bei denen im Stack-Modus ein Update nur gleichzeitig für alle Stack-Mitglieder möglich ist.
Dies führt zwangsläufig zu einer Downtime und somit zu einem Wartungsfenster, in dem nicht nur der Switch-Stack ein Update erhält, sondern vermutlich auch alle VMs herunterfahren müssen, da die Verbindung untereinander und (bei der Nutzung von iSCSI oder SMB3) zum Storage unterbrochen wird. Dieser große Aufwand führt daher in vielen Fällen dazu, dass weniger Updates eingespielt und unter Umständen Sicherheitslücken oder Fehler in der Firmware nicht gefixt werden.
Betreiben Sie mehrere Serverräume, sollten Sie die Netzwerkkomponenten über die Räume hinweg ebenfalls redundant anbinden. Zwei Geräte, jeweils eins in jedem Raum, sind keine Redundanz. Pro Standort sollten mindestens zwei Geräte im Einsatz sein, damit auch hier jeweils eins in Wartung genommen werden oder ausfallen kann. Lässt es die Lage der Standorte zu, sollten Sie zwei unterschiedliche Wege für die Verbindung untereinander nutzen (sodass quasi ein Ring betrieben wird). Dies führt bei der Unterbrechung eines Kabels nicht zwangsläufig zu einem Abbruch der gesamten Verbindung zwischen Raum A und Raum B.
Betreiben Sie neben internen Systemen und Applikationen auch Systeme in einem Rechenzentrum oder bei einem Cloudanbieter, ergibt eine Betrachtung der Internetanbindung ebenfalls Sinn. Haben Sie nur eine Leitung und diese fällt aus, sind sofort sämtliche Dienste außerhalb Ihrer Firma nicht mehr nutzbar. Sie sollten auch hier auf Redundanz setzen, je nach Verfügbarkeit am besten über zwei unterschiedliche Anbieter und im besten Fall über zwei unterschiedliche Wege. Zwei Internetanschlüsse, die über den gleichen Anschluss in Ihr Gebäude gelangen, bringen Ihnen beim Ausfall dieser einer Zuleitung auch nichts.
Seite 1: Ausfallsicherheit und Hochverfügbarkeit
Seite 2: Redundanz im Netzwerk
Im zweiten Teil des Workshops gehen wir darauf ein, warum USV-Systeme Pflicht sind, wie Sie beim Storage auf IOPs und Latenz achten und warum Sie beim Monitoring auch Temperatur und Wasser erfassen sollten. Im dritten Teil erklären wir, wie Sie mit einem Backupplan für stufenweisen Schutz der Daten sorgen, warum Replikation nicht gleich Backup ist und wie Sie ein effizientes Desaster-Recovery vorbereiten.
jp/ln/Jan Kappen
Die Möglichkeiten und Funktionen, die Sie mit Stretched Storage erhalten, unterscheiden sich enorm voneinander. Manche Systeme können bei einem Ausfall den Partner automatisch online und in den Betriebsmodus schalten, andere brauchen für diesen Vorgang einen manuellen Eingriff. Manche Storage-Systeme, die über zwei oder mehr Räume verteilt werden, sind aus Hypervisor-Sicht nur ein einziges logisches System. Solche Systeme sind unserer Erfahrung nach einfacher einzubinden, da der Cluster nur ein Storage-System kennt und dieses zur Speicherung der VM-Daten nutzt.
Bild 2: Über das Monitoring lassen sich Probleme wie ungewöhnlich hohe Latenzen identifizieren.
Manchmal arbeiten die Hersteller hier auch kleine Optimierungen ein, sodass zum Beispiel durch einen Treiber die Latenzen zu den physischen Einheiten gemessen werden und der Hypervisor immer mit dem Storage-System spricht, das eine kleinere Latenz hat. Durch diese Technik sollen die Systeme stets mit dem Storage-Kopf am lokalen Standort sprechen und es soll keine Kommunikation eines Servers in Raum A zum Storage-System in Raum B geben, da häufig die Bandbreite in einem Raum höher ist als zwischen den Räumen. Kommt es zum Ausfall des Storage-Systems in Raum A, wird erst dann auf den Speicher in Raum B zugegriffen, sofern dies noch möglich ist. Häufig führen solche Features allerdings auch dazu, dass sich der Preis für solch eine Lösung deutlich erhöht.
Egal für welche Lösung Sie sich entscheiden, Sie sollten gerade bei Ihrem Storage-System genau definieren, welche Anforderungen Sie haben und ob sich diese mit Ihrem Budget vereinbaren lassen. Der Betrieb über zwei Räume führt eigentlich immer dazu, dass sich die Kosten für solch ein Projekt nicht nur verdoppeln, sondern vervielfachen.
Redundanz im Netzwerk
Das Netzwerk in Ihrem Datacenter ist eine der Kernkomponenten, die am besten niemals ausfällt. Um dieses Ziel zu erreichen, lässt sich auch hier mit einer Redundanz arbeiten. Zwei und mehr Enterprise-Geräte lassen sich über unterschiedliche Technologien zu einem logischen Verbund zusammensetzen. Die genaue technische Lösung hängt häufig davon ab, welcher Hersteller zum Einsatz kommt.
Sie sollten bei der Planung und dem Aufbau Ihres Backbone-Netzwerks einige Dinge berücksichtigen. Dies beginnt damit, dass Sie die Bandbreite der Geräte betrachten. 10 GBit/s im Backend ist aktueller Standard. In den letzten 18 Monaten gab es allerdings eine ziemlich große Bewegung in diesem Bereich, Switches mit 25, 50 und 100 GBit/s pro Port sind preislich so attraktiv geworden, dass einige Unternehmen das Core-Netzwerk oder Teile davon auf 100 GBit/s aufrüsten. Diese Bandbreite ist in den meisten Umgebungen für die nächsten Jahre vollkommen ausreichend und bietet nebenbei auch noch den Vorteil, dass sich ein 100 GBit/s-Port mit Breakout-Kabeln auf zwei 50-GBit/s- oder vier 25-GBit/s-Ports splitten lässt. Mit Hilfe dieser Technik wird aus einem Switch mit 16 Ports, die mit 100 GBit/s arbeiten, ein Gerät mit bis zu 64 Ports mit jeweils 25 GBit/s. Falls Sie nun direkt an extrem hohe Preise für solches Equipment denken: Enterprise-Geräte mit diesen Eigenschaften liegen teilweise im vierstelligen Preissegment.
Zwei dieser Geräte sorgen dafür, dass vor Ort eine Redundanz besteht. So können Sie Server mit einem NIC-Team in jeweils einen Switch stecken. Damit sind die Systeme auch dann noch online, wenn im Netzwerk ein Gerät ausfällt oder durch ein Update temporär nicht zur Verfügung steht. Achten Sie vor der Anschaffung darauf, wie und mit welchen Abhängigkeiten Sie solch ein Update machen können. Denn uns sind auch Switch-Modelle bekannt, bei denen im Stack-Modus ein Update nur gleichzeitig für alle Stack-Mitglieder möglich ist.
Dies führt zwangsläufig zu einer Downtime und somit zu einem Wartungsfenster, in dem nicht nur der Switch-Stack ein Update erhält, sondern vermutlich auch alle VMs herunterfahren müssen, da die Verbindung untereinander und (bei der Nutzung von iSCSI oder SMB3) zum Storage unterbrochen wird. Dieser große Aufwand führt daher in vielen Fällen dazu, dass weniger Updates eingespielt und unter Umständen Sicherheitslücken oder Fehler in der Firmware nicht gefixt werden.
Betreiben Sie mehrere Serverräume, sollten Sie die Netzwerkkomponenten über die Räume hinweg ebenfalls redundant anbinden. Zwei Geräte, jeweils eins in jedem Raum, sind keine Redundanz. Pro Standort sollten mindestens zwei Geräte im Einsatz sein, damit auch hier jeweils eins in Wartung genommen werden oder ausfallen kann. Lässt es die Lage der Standorte zu, sollten Sie zwei unterschiedliche Wege für die Verbindung untereinander nutzen (sodass quasi ein Ring betrieben wird). Dies führt bei der Unterbrechung eines Kabels nicht zwangsläufig zu einem Abbruch der gesamten Verbindung zwischen Raum A und Raum B.
Betreiben Sie neben internen Systemen und Applikationen auch Systeme in einem Rechenzentrum oder bei einem Cloudanbieter, ergibt eine Betrachtung der Internetanbindung ebenfalls Sinn. Haben Sie nur eine Leitung und diese fällt aus, sind sofort sämtliche Dienste außerhalb Ihrer Firma nicht mehr nutzbar. Sie sollten auch hier auf Redundanz setzen, je nach Verfügbarkeit am besten über zwei unterschiedliche Anbieter und im besten Fall über zwei unterschiedliche Wege. Zwei Internetanschlüsse, die über den gleichen Anschluss in Ihr Gebäude gelangen, bringen Ihnen beim Ausfall dieser einer Zuleitung auch nichts.
Seite 2: Redundanz im Netzwerk
Im zweiten Teil des Workshops gehen wir darauf ein, warum USV-Systeme Pflicht sind, wie Sie beim Storage auf IOPs und Latenz achten und warum Sie beim Monitoring auch Temperatur und Wasser erfassen sollten. Im dritten Teil erklären wir, wie Sie mit einem Backupplan für stufenweisen Schutz der Daten sorgen, warum Replikation nicht gleich Backup ist und wie Sie ein effizientes Desaster-Recovery vorbereiten.
| << Vorherige Seite | Seite 2 von 2 |
jp/ln/Jan Kappen
