Die StorMagic SvSAN FAQ versucht, eine Vielzahl von Fragen zu StorMagic SvSAN, seiner Bereitstellung und seinen Funktionen zu beantworten.
Zusätzlich zu dieser FAQ können Sie die vollständige Dokumentation für den Einsatz von SvSAN auf der Seite SvSAN-Handbuch lesen.
Haben Sie das SvSAN-Datenblatt und das Whitepaper SvSAN Technical Overview gelesen, die beide viele nützliche Informationen über SvSAN, seine Anforderungen und Möglichkeiten enthalten?
If you cannot find an appropriate answer within the SvSAN FAQ, you can contact the StorMagic team at [email protected].
Frage-Kategorien
Verwenden Sie die Links unten, um zu einem bestimmten Abschnitt zu springen:
Allgemeine Fragen
StorMagic SvSAN vereinfacht die IT-Speicherung. Im Gegensatz zu den zahlreichen konkurrierenden Lösungen auf dem Speichermarkt ist StorMagic SvSAN nicht komplex, teuer oder schwierig zu verwalten. Das Herzstück ist das Bestreben, Ihrem Unternehmen einen einfachen virtuellen Speicher zu bieten. Es macht das Komplexe einfach.
SvSAN ist ein hochverfügbares virtuelles SAN mit zwei Knoten, das für hyperkonvergente Edge- und kleine Rechenzentrumsstandorte entwickelt wurde. Die Technologie basiert auf softwaredefiniertem Speicher, der den Bedarf an physischen SANs eliminiert. Es wird als virtuelle Speicheranwendung (VSA) auf einem Hypervisor eingesetzt.
SvSAN ermöglicht hochverfügbare Cluster durch Spiegelung von Daten zwischen zwei Knoten. Seine Einfachheit gewährleistet, dass nur zwei Knoten pro Standort benötigt werden, wobei die Bereitstellung, die Verwaltung und die Witness-as-a-Service-Dienste von einem zentralen Standort aus durchgeführt werden können.
SvSAN unterstützt VMware vSphere, Microsoft Hyper-V und Linux KVM-Hypervisoren. Es wird als virtuelle Speicher-Appliance (VSA) installiert, die nur minimale Server-Ressourcen benötigt, um den gemeinsam genutzten Speicher bereitzustellen, der für erweiterte Hypervisor-Funktionen wie Hochverfügbarkeit/Failover Cluster, vMotion/Live Migration und VMware Distributed Resource Scheduler (DRS)/Dynamische Optimierung erforderlich ist.
Ausführliche Informationen über die neueste Version der Hypervisor-Kompatibilität von SvSAN finden Sie im SvSAN-Datenblatt.
SvSAN kann als einfacher 2-Knoten-Cluster eingesetzt werden, der die Flexibilität bietet, wechselnde Kapazitäts- und Leistungsanforderungen zu erfüllen. Dies wird durch das Hinzufügen zusätzlicher Kapazitäten zu den vorhandenen Servern oder durch die Vergrößerung des SvSAN-Clusters erreicht, ohne die Verfügbarkeit der Dienste zu beeinträchtigen.
SvSAN spiegelt Daten zwischen VSAs/Cluster-Knoten synchron und stellt so sicher, dass die Daten an zwei Orten gespeichert werden, bevor sie als vollständig bestätigt werden.
Jede Seite des Spiegels (Plex) ist aktiv, so dass von jedem Plex aus auf die Daten zugegriffen werden kann. Sollte eine Seite des Spiegels ausfallen (Serverausfall, Speicherausfall, Netzwerkausfall), kann immer noch auf die Daten des überlebenden Plexus zugegriffen werden.
Während eine Seite eines Spiegels offline ist, werden Änderungen an der verbleibenden Seite im Metadaten-Journal aufgezeichnet. Bei der Wiederherstellung wird das Journal gelesen, um festzustellen, welche Daten sich geändert haben. Diese werden dann auf die wiederhergestellte Seite des Spiegels kopiert, zusammen mit allen neu geschriebenen Daten, was als „schnelle Neusynchronisierung“ bezeichnet wird.
Das Metadaten-Journal sollte mindestens 20 GB groß sein, so dass es eine sehr große Anzahl von Änderungen verarbeiten kann. Wenn der Meta-Daten-Journal-Wraps fehlschlägt, führt das System einfach eine vollständige Neusynchronisierung des Spiegels durch.
Wo Hardware-RAID nicht möglich ist, z.B. bei edge-spezifischen Servermodellen, die keine Unterstützung für Hardware-RAID-Karten enthalten, bietet SvSAN Software-RAID-Funktionalität. Weitere Einzelheiten dazu finden Sie in unserem Software-RAID-Blog.
SvSAN bietet keinen expliziten Schutz gegen Laufwerksausfälle. Der Server, auf dem der VSA läuft, schützt sich gegen Laufwerksausfälle mit Hardware-RAID.
In Fällen, in denen kein RAID vorhanden ist, werden die Daten durch SvSAN mit einer gespiegelten Kopie der Daten auf einem anderen SvSAN-Knoten geschützt.
Der VSA ist so konzipiert, dass er jeden unerwarteten Stromausfall bewältigen kann. Beim Start führt der VSA Überprüfungen durch, um festzustellen, ob er zuvor ordnungsgemäß heruntergefahren wurde.
Wenn der VSA zuvor abnormal heruntergefahren wurde, werden Überprüfungen durchgeführt, um sicherzustellen, dass alle Konfigurationsdaten konsistent und korrekt sind.
Ein VSA enthält duale Boot-Images, um sich vor Beschädigungen zu schützen. Wenn das primäre Boot-Image beschädigt wird, kann der VSA von dem anderen Image booten.
SvSAN wurde so konzipiert, dass es so weit wie möglich skalierbar ist, da die meisten Einheiten keine festen Grenzen haben, sondern durch die verfügbaren Hardwareressourcen begrenzt sind.
Die maximale Kapazität einer virtuellen Festplatte beträgt 128 Petabyte.
Die minimale Skalierungseinheit für hochverfügbaren gemeinsamen Speicher sind zwei Knoten, wobei die virtuellen Festplatten zwischen den Knoten gespiegelt werden.
Ein dritter Server dient als Quorum zum Schutz vor Split-Brain-Szenarien, das ist der SvSAN-Witness. Lesen Sie mehr darüber in diesem White Paper. Der Witness kann sich vor Ort oder über ein WAN in der Ferne befinden. Wenn ein dritter Knoten nicht verwendet werden kann, kann SvSAN in einer 2-Knoten-Konfiguration unter Verwendung der „Stay up Isolation Policy“ betrieben werden.
Über zwei Knoten hinaus kann eine beliebige Anzahl von Knoten unterstützt werden. Es ist möglich, so viele gespiegelte virtuelle Festplatten zu erstellen, wie es die Kapazität zulässt, und jede kann zwischen einem beliebigen Knotenpaar gespiegelt werden. Außerdem kann SvSAN in 3-Knoten-Clustern konfiguriert werden. Weitere Informationen zu dieser Art der Konfiguration finden Sie in dem entsprechenden White Paper.
Weitere Fragen zum SvSAN-Witness werden in einem separaten Abschnitt unten beantwortet.
Die Systemanforderungen für SvSAN entnehmen Sie bitte dem SvSAN-Datenblatt. Alle Einzelheiten entnehmen Sie bitte der Tabelle mit den Systemanforderungen.
SvSAN kann bis zu 32 GB Speicher unterstützen.
Die folgende Tabelle zeigt die empfohlene Speichermenge, die dem VSA auf der Grundlage der Speicher- und SSD-Cache-Größen zugewiesen werden muss:
| SSD-Cache-Größe | |||||||
| Bis zu 0GB2 | Bis zu 250 GB | Bis zu 500 GB | Bis zu 1000 GB | Bis zu 1500 GB | Bis zu 2000 GB | ||
| Speicher-Cache erforderlich | 0GB1 | 1GB | 3GB | 3GB | 4GB | 5GB | 6GB |
| 1GB | 3GB | 4GB | 4GB | 5GB | 6GB | 7GB | |
| 2GB | 4GB | 5GB | 5GB | 6GB | 7GB | 9GB | |
| 3GB | 5GB | 6GB | 6GB | 7GB | 9GB | 10GB | |
| 4GB | 6GB | 7GB | 7GB | 9GB | 10GB | 11GB | |
| 6GB | 9GB | 9GB | 10GB | 11GB | 12GB | 13GB | |
| 8GB | 11GB | 11GB | 12GB | 13GB | 14GB | 15GB | |
| 12GB | 15GB | 16GB | 16GB | 17GB | 18GB | 20GB | |
| 16GB | 20GB | 20GB | 21GB | 22GB | 23GB | 24GB | |
| 20GB | 24GB | 24GB | 25GB | 26GB | 27GB | 28GB | |
| 24GB | 28GB | 29GB | 29GB | 31GB | 32GB | – | |
1 Speicher-Caching deaktiviert
2 SSD-Caching deaktiviert
Weitere Informationen über die Caching-Fähigkeiten von SvSAN finden Sie im Caching-Whitepaper.
Die minimale Netzwerkbandbreite beträgt 1Gb Ethernet.
SvSAN unterstützt 10Gbps und 40Gbps Ethernet, Jumbo Frames und Network Teaming, um die Netzwerkleistung zu verbessern.
Ja, SvSAN wird alle Netzwerkverbindungen nutzen, die der virtuelle Server konfiguriert hat. SvSAN kann so konfiguriert werden, dass es einen Lastausgleich vornimmt und die Bandbreite aller verfügbaren Netzwerkschnittstellen aggregiert. Diese können für Verwaltung, Spiegelung oder iSCSI-Verkehr verwendet werden.
Ja, es müssen zwei virtuelle Switches auf den virtuellen Servern konfiguriert werden. SvSAN wird standardmäßig mit zwei virtuellen Netzwerkschnittstellen (vNICs) installiert und konfiguriert. Es können jedoch weitere Netzwerkschnittstellen hinzugefügt werden.
Für den Fall, dass alle für den Spiegelverkehr verwendeten Netzwerkschnittstellen nicht verfügbar sind, wird der Spiegelverkehr über die verbleibenden Verwaltungsnetzwerkschnittstellen umgeleitet.
Ja, ein bestehendes nicht gespiegeltes Ziel kann in ein gespiegeltes Ziel konvertiert werden und umgekehrt. Detaillierte Schritte entnehmen Sie bitte dem SvSAN-Handbuch oder kontaktieren Sie unser Support-Team unter [email protected].
Die Seriennummer und der aktuelle Hostname werden zu Beginn des Konfigurationsassistenten angezeigt.
Nachdem die Einrichtung abgeschlossen ist, können Sie die Seriennummer über die Konsole, die Registerkarte System der WebGUI oder die VSA-Ansicht>Registerkarte System im StorMagic Plugin einsehen. z.B. https://VSAname.domainname/system/license/
Einzelheiten zu den Bandbreiten- und Latenzanforderungen entnehmen Sie bitte dem Whitepaper zum Stretch-Cluster, oder wenden Sie sich an unser Support-Team unter [email protected].
Die unterstützten und gültigen Upgrade-Pfade entnehmen Sie bitte den SvSAN-Versionshinweisen.
Wir empfehlen Ihnen jedoch, sich mit der neuesten Version der SvSAN-Firmware auf dem Laufenden zu halten, um sicherzustellen, dass Sie Zugang zu den neuesten Funktionen und aktuellen Sicherheits-, Leistungs- und Fehlerbehebungen haben.
Lizenzierung und Support
Ja, eine kostenlose, voll funktionsfähige Testversion von SvSAN steht zum Download zur Verfügung, mit der Unternehmen die Funktionen und Vorteile von SvSAN vor dem Kauf testen können. Für weitere Informationen und um eine Testversion herunterzuladen, besuchen Sie die Download-Seite der Testversion auf der Website.
Während des Testzeitraums können Evaluatoren auf Wunsch Unterstützung und Hilfe bei der Erstinstallation sowie eine Produktdemonstration erhalten.
- Erhältlich in 2TB, 6TB, 12TB und Unlimited TB nutzbarer Speicherkapazität
- 1 Lizenz pro Server/Cluster-Knoten erforderlich
- Der Preis basiert auf einer Einzellizenz (2 Lizenzen für einen 2-Knoten-Cluster erforderlich)
- Die SvSAN-Basislizenz enthält alle Funktionen, die für hochverfügbaren gemeinsamen Speicher erforderlich sind
- Leistungs- und sicherheitssteigernde Add-ons verfügbar: Predictive Storage Caching und Datenverschlüsselung
- Die Wartung muss für jede SvSAN-Lizenz erworben werden. Für jedes Add-on muss außerdem eine eigene Wartung erworben werden
- Die Wartung kann in Schritten von 1, 3 oder 5 Jahren erworben werden.
Um die Lizenz- und Wartungsanforderungen zu besprechen und ein Angebot zu erhalten, wenden Sie sich bitte an unser Vertriebsteam unter [email protected].
SvSAN ist als Basislizenz erhältlich, die alle notwendigen Funktionen für hochverfügbaren gemeinsamen Speicher enthält.
Für SvSAN sind außerdem zwei Add-Ons verfügbar, die die Leistung und Sicherheit verbessern.
Die leistungssteigernden Funktionen von SvSAN sind unter dem Namen Predictive Storage Caching bekannt, bei dem patentierte Algorithmen eingesetzt werden, um die volle Leistung von Speicher- und Hybridplattenkonfigurationen zu entfesseln.
Die Datenverschlüsselungsfunktion von SvSAN ermöglicht es Unternehmen mit einem bis zu Tausenden von Standorten, kostengünstig und effizient Datenverschlüsselung an jedem einzelnen Standort einzuführen.
Eine vollständige Erklärung der SvSAN-Funktionen finden Sie auf der Seite SvSAN-Funktionen.
Ja, die Kapazität kann jederzeit aufgestockt werden.
Um Software-Updates und Produktsupport zu erhalten, benötigen Sie einen gültigen StorMagic Wartungs- und Supportvertrag.
StorMagic bietet rund um die Uhr erstklassigen Support, um sicherzustellen, dass Kunden und Partner auftretende Schwierigkeiten schnell und effektiv beheben können. StorMagic Maintenance & Support bietet sofortigen Zugriff auf Knowledge-Base-Artikel, Software-Updates, einschließlich größerer und kleinerer Software-Updates (einschließlich Fehlerbehebungen und neuer Funktionen), sowie die Möglichkeit, technische Support-Anfragen zu protokollieren.
StorMagic Maintenance & Support ist in zwei Stufen erhältlich, Gold oder Platinum.
Ausführliche Informationen zum StorMagic-Support, einschließlich Vergleichen zwischen Support-Plänen, Produktlebenszyklus-Matrixen, Schweregraddefinitionen und Support-Stunden für Unternehmen, finden Sie im Dokument StorMagic-Support-Übersicht.
SvSAN Witness
Split-Brain ist ein Clusterzustand, der auftritt, wenn Clusterknoten den Kontakt zueinander verlieren und beginnen, unabhängig voneinander zu arbeiten. Die Daten auf den einzelnen Knoten beginnen zu divergieren und werden inkonsistent, was letztendlich zu Datenbeschädigung und -verlust führt.
Die Systemanforderungen für den SvSAN Witness finden Sie im SvSAN Witness-Datenblatt. Alle Einzelheiten entnehmen Sie bitte der Tabelle mit den Systemanforderungen.
Shared Remote Witness – Dies ermöglicht es, dass sich ein Minimum an IT-Infrastrukturausrüstung, die hohe Verfügbarkeit gewährleistet (2 Server), am entfernten Standort befindet. Der Witness befindet sich an einem anderen zentralen Standort (Rechenzentrum/HQ) und wird über eine WAN-Verbindung erreicht. Ein einziger Witness kann von Hunderten von SvSAN-Clustern an entfernten Standorten gemeinsam genutzt werden.
Lokaler Witness – Ähnlich wie bei der vorherigen Konfiguration gibt es zwei Server, auf denen jeweils ein SvSAN VSA installiert ist. Diesmal wird der Witness jedoch auf einem dritten physischen Server oder einer virtuellen Maschine (außerhalb des SvSAN HA-Clusters) gehostet, die sich am selben Standort befindet. Diese Konfiguration ist für Umgebungen gedacht, die völlig isoliert sind und nur über eine begrenzte oder gar keine externe Netzwerkverbindung verfügen und vor Split-Brain-Szenarien geschützt werden müssen.
SvSAN-Cluster mit mehreren Knoten – SvSAN kann in Clustern mit mehreren Knoten eingesetzt werden, die drei oder mehr Server enthalten. In diesem Einsatzszenario fungiert eine der SvSAN VSAs als Quorum für andere Clustermitglieder. Zum Beispiel bei einem 3-Knoten-Cluster mit VSAs A, B & C:
- Wenn eine Spiegelung zwischen VSAs A & B erstellt wird, fungiert VSA C als Quorum.
- Wenn eine Spiegelung zwischen VSAs A & C erstellt wird, fungiert VSA B als Quorum.
- Wenn ein Mirror zwischen VSAs B & C erstellt wird, fungiert VSA A als Quorum.
Weitere Informationen zu SvSAN-Clustern mit mehreren Knoten finden Sie in diesem White Paper.
Kein Witness – Die letzte Option ist die Bereitstellung von zwei Servern am entfernten Standort ohne einen Witness. In dieser Konfiguration ist es möglich, bei einem Verlust der Netzwerkverbindung zwischen den Servern oder bei einem gleichzeitigen Neustart der Server ein Split-Brain-Szenario einzurichten. Um das Risiko eines „Split-Brain“ zu verringern, sollten Sie die besten Praktiken anwenden. Dazu gehören stabile Netzwerkverbindungen zwischen Servern, die Verwendung hochwertiger Komponenten und die Nutzung mehrerer redundanter Stromversorgungen.
Nein – der Witness ist eine optionale Infrastrukturkomponente, siehe die Option „kein Witness“ in der Antwort auf die Frage „Was sind die typischen Optionen für den Einsatz von SvSAN Witness?“.
Ja – bei Clustern mit 3 oder mehr Knoten fungieren andere VSAs im Cluster als Quorum für andere Paare von VSAs. Siehe die Bereitstellungsoption „SvSAN-Cluster mit mehreren Knoten“ in der Antwort auf die Frage „Was sind die typischen Bereitstellungsoptionen für SvSAN-Witness“.
Ja – der Witness kann sich an einem zentralen Standort befinden und Quorum für entfernte SvSAN VSA-Cluster bereitstellen. Siehe die Option „Gemeinsamer entfernter Witness“ in der Antwort auf die Frage „Was sind die typischen Optionen für die Bereitstellung von SvSAN-Witness“.
Die Kompatibilität der Betriebssysteme für den SvSAN Witness finden Sie im SvSAN Witness-Datenblatt. In der Tabelle mit den Systemanforderungen finden Sie alle unterstützten Betriebssysteme.
Ja – der Witness kann von mehreren Clustern und Mirrors gemeinsam genutzt werden. StorMagic hat Kunden mit mehr als 2000 Standorten, von denen jeder mehrere Spiegelziele hat, die einen zentralisierten Witness verwenden.
Eine ausführliche Übersicht über die verschiedenen Ausfallszenarien, vor denen SvSAN Witness schützen kann, finden Sie im White Paper zu Witness.
Der Witness verwendet den SvSAN-Erkennungsdienst, der den Netzwerkport 4174 (TCP/UDP) nutzt. Alle von SvSAN verwendeten Ports finden Sie im Abschnitt SvSAN verwendeten Ports des SvSAN-Handbuchs.
Wenn Sie den Witness über eine WAN-Verbindung verwenden, gelten die folgenden Empfehlungen für die Netzwerkbandbreite und Latenzzeit, um einen optimalen Betrieb zu gewährleisten:
- Die Latenzzeit sollte weniger als 3.000 ms betragen, so dass sich der Witness fast überall auf der Welt befinden kann.
- Die Datenmenge, die vom VSA an den Witness übertragen wird, ist gering (unter 100 Byte pro Sekunde). Es wird empfohlen, dass zwischen dem VSA und dem Witness eine Netzwerkbandbreite von mindestens 9 Kb/s zur Verfügung steht.
Im Allgemeinen kann der Witness mit sehr hohen Latenzzeiten arbeiten und hat sehr geringe Anforderungen an die Netzwerkbandbreite. Obwohl es sich hierbei um extreme Szenarien handelt und Netzwerke mit diesen Eigenschaften in der Praxis nur selten zum Einsatz kommen, zeigt dies, wie effizient der Witness ist.
Weitere Informationen zu den Bandbreiten- und Latenztoleranzen des Witness finden Sie im SvSAN-Witness-Whitepaper.
Es ist zwar möglich, einen einzigen Witness für alle Standorte zu verwenden, aber es empfiehlt sich, mehrere Witnesses im Rechenzentrum/HQ einzurichten und die Remote-Cluster/Mirrors auf die verfügbaren Witnesses aufzuteilen, um zu vermeiden, dass bei einem Ausfall eines Witness-Servers alle Remote-Standorte betroffen sind. Mehrere Witness können in verschiedenen Regionen eingesetzt werden, um sicherzustellen, dass die Netzwerkkonnektivität verfügbar ist und den Mindestanforderungen entspricht.
Der Witness speichert keine Anwendungs-/Kundendaten, er zeichnet nur das Spiegelziel und den Cluster-Status auf. Zu den auf dem Witness gespeicherten Daten gehören:
- Spiegelzustand (synchronisiert, neu synchronisiert, etc.)
- iSCSI Qualifizierter Name (IQN)
- Name des Ziels spiegeln
- Plexusnamen spiegeln
- VSAs, auf denen sich die Spiegelplexe befinden
Der Witness verwendet den SvSAN-Erkennungsdienst, der den Netzwerkport 4174 TCP/UDP nutzt. Standardmäßig „durchquert“ dieser Dienst keine Subnetze, um sicherzustellen, dass der Broadcast-Verkehr auf ein Minimum reduziert wird. Es ist jedoch möglich, statische Netzwerkeinträge in den Netzwerk-Routing-Tabellen zu erstellen, so dass sich der Witness in anderen Subnetzen als die VSA-Cluster befinden kann.
Statische Netzwerkeinträge können manuell über die WebGUI oder durch Skripting nach der Bereitstellung erstellt werden. Sie werden automatisch erstellt, wenn statische IP-Adressen für die Verwaltungsadresse des VSA verwendet werden.
- Der Witness kann auf einer VM installiert werden, die im Falle eines Ausfalls auf einen anderen virtuellen Server übertragen werden kann.
- Der Witness kann auf einem Standby-Server/VM installiert werden. Eine manuelle Umschaltung wird durchgeführt, damit die Cluster/Spiegelziele im Falle eines Ausfalls diesen „Standby“-Witness verwenden. Dieser Vorgang kann per Skript gesteuert werden.
- In VMware vSphere-Umgebungen kann der Witness auf einer fehlertoleranten (FT) virtuellen Maschine installiert werden, wodurch sichergestellt wird, dass es keine Ausfallzeiten des Witness-Service gibt.
- Es ist auch möglich, den Übergang mit einem separaten Überwachungsgerät und PowerShell Commandlets zu automatisieren.
Ja, das kann er, solange er sich außerhalb des Clusters befindet, für den er das Quorum bereitstellt.
Ja – es ist möglich, den Witness auf einem Server/VM zu betreiben, der von einem Cloud-Anbieter gehostet wird.
Der Server/die virtuelle Maschine muss die Mindestanforderungen an die Serverressourcen erfüllen und die Anforderungen an die Netzwerklatenz und -bandbreite müssen ausreichend sein. Diese sind in der Antwort auf die Frage „Was sind die Systemanforderungen für den SvSAN-Witness?
Die StorMagic SvSAN Witness Appliance ist eine eingeschränkte Version der SvSAN VSA, die ausschließlich Quorum-Funktionen bietet. Es hat die folgenden Vorteile:
- Leichte Systemanforderungen (CPU, Speicher und Festplatte)
- Eigenständig – benötigt kein weiteres Betriebssystem, z.B. Microsoft Windows oder Linux
- Schnellerer Einsatz
- Wird mit der gleichen Firmware wie SvSAN VSA aktualisiert
Die Witness Appliance ist nur für VMware vSphere ESXi Umgebungen geeignet.
SvSAN Datenverschlüsselung
Gartner definiert Verschlüsselung als:
„Verschlüsselung ist der Prozess der systematischen Verschlüsselung eines Bitstroms vor der Übertragung, so dass ein Unbefugter ihn nicht entschlüsseln kann.“
Verschlüsselung sollte als ein Aspekt einer umfassenderen Sicherheitsstrategie betrachtet werden und ist der Prozess der Umwandlung von Daten von einer Form (Klartext) in eine andere (Chiffretext). Es stellt sicher, dass, wenn die Daten in die Hände eines Unbefugten fallen, nicht auf die Daten zugegriffen werden kann, ohne die richtigen Verschlüsselungsschlüssel zur Entschlüsselung der Daten zu besitzen.
Die Datenverschlüsselung schützt Daten, wenn sie auf der Festplatte gespeichert sind, und kann zum Schutz von Daten vor unbefugtem Zugriff oder Gerätediebstahl verwendet werden.
Im Falle eines Festplattenausfalls können die ausgefallenen Festplatten nun entsorgt oder ersetzt werden, ohne dass ein Zugriff auf die Daten zu befürchten ist, da diese verschlüsselt sind. Damit entfällt die Notwendigkeit von Datenvernichtungstechniken wie „Degaussing“ von Magnetplatten, physische Zerstörung oder „Disk Scrubbing“.
Die Datenverschlüsselungsfunktion von SvSAN verwendet die weithin verfügbare Open-Source-Bibliothek „OpenSSL“, die die Verschlüsselungsalgorithmen bereitstellt.
Die aktuelle Version ist OpenSSL 1.0.2u.
Die SvSAN-Datenverschlüsselung verwendet die XTS-AES-256-Chiffre zur Verschlüsselung von Daten.
Die Länge des Kryptoschlüssels beträgt 256 Bit.
Die SvSAN-Datenverschlüsselung verwendet ein eingebettetes, nach FIPS 140-2 (Level 1) validiertes kryptografisches Modul (OpenSSL Object Module v2.0, Zertifikat #1747), das auf der SvSAN-Plattform gemäß den Richtlinien der FIPS 140-2 Implementation Guidance, Abschnitt G.5, ausgeführt wird.
Es verwendet eine robuste kryptographische Verschlüsselung (XTS-AES-256), die FIPS 140-2-konform ist und die HIPAA-, PCI DSS- und SOX-Standards erfüllt.
SvSAN selbst ist jedoch derzeit nicht FIPS 140-2-validiert.
Gartner definiert Enterprise Key-Management (EKM) als:
„Enterprise Key-Management (EKM) bietet eine einzige, zentralisierte Software- oder Netzwerk-Appliance für mehrere kryptografische Lösungen zur symmetrischen Verschlüsselung oder Tokenisierung. Entscheidend ist, dass es konsistente Datenzugriffsrichtlinien durch Verschlüsselungs- und Tokenisierungsmanagement durchsetzt. Außerdem erleichtert es die Schlüsselverteilung und sichere Schlüsselspeicherung und sorgt für eine konsistente Verwaltung des Lebenszyklus von Schlüsseln.“
Darüber hinaus erklären sie auch, dass:
„EKM-Produkte übernehmen den Standard Key-Management Interoperability Protocol (KMIP), der von der Organization for the Advancement of Structured Information Standards (OASIS) gefördert wird. EKM-Lösungen können alle kryptografischen Lösungen verwalten, die mit KMIP konform sind.“
Das Key-Management Interoperability Protocol (KMIP) wurde 2010 von OASIS eingeführt und ist ein einheitliches Standardprotokoll für die Kommunikation zwischen Key-Management-Systemen und Verschlüsselungslösungen.
Vor der Einführung von KMIP hatte jeder Anbieter seine eigene Lösung für das Key-Management, was dazu führte, dass mehrere Key-Management-Lösungen (KMS) verwendet wurden, was den Verwaltungsaufwand erhöhte.
KMIP bietet einen Standardmechanismus für Anwendungen, Speicher-Arrays, Bandbibliotheken, Festplattenlaufwerke (Self-Encrypting Drives) und Netzwerkgeräte, um mit Key-Management-Lösungen (KMS) verschiedener Anbieter zu kommunizieren und so die Anzahl der erforderlichen Key-Management-Lösungen zu reduzieren.
Die SvSAN-Datenverschlüsselung unterstützt die KMIP-Versionen 1.0 bis 1.4.
KMIP verwendet standardmäßig den Port 5696, der von der IANA (Internet Assigned Numbers Authority) zugewiesen wurde. Dies ist der einzige Port, der in einer Firewall zwischen SvSAN und dem KMS geöffnet werden muss.
Die Datenverschlüsselungsfunktion von SvSAN ist mit allen KMIP-kompatiblen Key-Managern kompatibel, einschließlich StorMagic SvKMS. Dazu gehören softwarebasierte KMS-Lösungen und Hardware-Sicherheitsmodule (HSM). Ein HSM ist ein gehärtetes, manipulationssicheres Gerät, das speziell für den Schutz der kryptografischen Schlüssel entwickelt wurde.
StorMagic empfiehlt SvKMS Encryption Key-Management für SvSAN-Benutzer mit aktivierter Datenverschlüsselungsfunktion. Das SvSAN-Handbuch enthält jedoch Integrationsanleitungen für viele führende KMS-Lösungen großer Anbieter.
Integrationsanleitungen finden Sie im SvSAN-Handbuch unter dem Abschnitt „Weitere Anleitungen > Datenverschlüsselung – SvSAN KMS-Integration“.
Verfügbarkeit ist die wichtigste Voraussetzung für Key-Management. Es wird daher dringend empfohlen, mindestens zwei oder möglicherweise mehr Key-Management-Server zu betreiben, um sicherzustellen, dass die Schlüssel immer verfügbar sind.
Wenn es nicht möglich ist, das KMS zu kontaktieren, um die kryptografischen Schlüssel abzurufen, ist es nicht möglich, die Daten zu verschlüsseln oder, noch wichtiger, zu entschlüsseln, und die Daten sind verloren.
Mit mehreren Key-Management-Servern können die Schlüssel repliziert werden, und idealerweise werden sie an verschiedenen Standorten/Rechenzentren installiert, um sicherzustellen, dass Stromausfälle, Überschwemmungen, Brände usw. die Verfügbarkeit nicht unterbrechen.
Zusätzlich zu mehreren Servern sollten Sie sich an bewährte Verfahren für das Key-Management halten, wie z.B.:
- Machen Sie regelmäßig Backups des KMS
- Bewahren Sie die Schlüssel nicht auf dem Speicher auf, den die Schlüssel schützen.
Es ist immer am besten, den KMS-Anbieter zu konsultieren, um sicherzustellen, dass alles nach seinen bewährten Verfahren konfiguriert und eingerichtet ist.
Nein, die SvSAN Datenverschlüsselung ist rein softwarebasiert und erfordert keine speziellen Verschlüsselungskarten, RAID-Karten, FPGAs oder ASICs.
Da die Verschlüsselung jedoch recht rechenintensiv sein kann, bieten viele moderne CPUs jetzt Anweisungen zur Hardwarebeschleunigung, um die Verschlüsselungsleistung erheblich zu verbessern. Diese Anweisungen sind als „Advanced Encryption Standard New Instruction“ (AES-NI) bekannt.(https://en.wikipedia.org/wiki/AES_instruction_set)
SvSAN verwendet die OpenSSL-Bibliothek und die XTS-AES-265-Chiffre, die wiederum die AES-NI-Hardwarebeschleunigungsanweisungen verwendet, wenn diese in der CPU vorhanden und aktiviert sind. Die Anweisungen zur AES-NI-Hardwarebeschleunigung müssen möglicherweise im BIOS des Servers aktiviert werden.
Ja, es wird möglich sein, ein bestehendes Volume mit darauf gespeicherten Daten zu verschlüsseln.
Ja. Das Ändern der Verschlüsselungsschlüssel ist möglich.
Es gibt viele Variablen, die die Auswirkungen auf die Leistung bei der Verwendung von Verschlüsselung bestimmen, darunter:
- Wie „schnell“ ist die CPU?
- Unterstützt die CPU AES-NI?
(Die meisten modernen Prozessoren unterstützen AES-NI und neuere CPU-Generationen haben die Leistung dieser Anweisungen gegenüber der vorherigen Generation verbessert, so dass sie Verschlüsselungsberechnungen schneller durchführen können). - Wie schnell sind die zugrunde liegenden Festplatten?
- Wie viel E/A und wie viel Daten werden generiert?
Die Antwort auf die Frage nach den Auswirkungen auf die Leistung lautet daher: „Es kommt darauf an“ – und wird von der jeweiligen Kundenumgebung abhängen.
SvSAN Fern-Syslog-Funktion
Syslog ist ein in RFC 5424 definiertes Standardprotokoll, das vom Dienstprogramm rsyslog verwendet wird, um Systemprotokoll- oder Ereignismeldungen an einen zentralen Server zu senden, so dass Protokolle von verschiedenen Geräten wie Servern, Speichergeräten, Netzwerkgeräten (Router, Switches, Firewalls) und Peripheriegeräten (Drucker, Scanner) konsolidiert werden können. Dadurch können die Protokolle für die Systemüberwachung, Sicherheitsüberprüfungen und andere Analysezwecke verwendet werden.
Traditionell verwendet syslog das UDP-Protokoll an Port 514, kann aber so konfiguriert werden, dass es jeden Port verwendet.
Derzeit werden alle Ereignisse von der VSA an den entfernten Syslog-Server gesendet.
Die SvSAN Remote-Syslog-Funktion sollte mit jeder Syslog-Collector-Software funktionieren, die das in RFC 5424 definierte Standard-Syslog-Nachrichtenformat dekodieren kann.
Es wurde mit den folgenden gängigen Syslog-Softwarepaketen getestet und funktioniert sofort, ohne dass eine zusätzliche Übersetzung der Nachrichten erforderlich ist:
- Linux Syslog-Server
- Nagios
- Paessler PRTG
- Graylog
Weitere Softwarepakete werden auf der Grundlage von Kundenfeedback getestet und hinzugefügt.
SvSAN mit VMware vSphere
Die Hypervisor-Versionskompatibilität für SvSAN finden Sie im SvSAN-Datenblatt. In der Hypervisor-Kompatibilitätstabelle finden Sie alle unterstützten Hypervisoren.
Das Plugin ermöglicht die Verwaltung virtueller SANs über eine assistentengestützte Bereitstellung und laufende Verwaltungsaufgaben direkt in vCenter vor Ort oder an einem zentralen Standort.
Das StorMagic Dashboard im vCenter zeigt einen Ampelstatus für alle vom vCenter verwalteten VSAs an und bietet die Möglichkeit, VSA-Firmware-Upgrades durchzuführen.
Die SvSAN VSA VM bietet eine Konsole, die über die Hypervisor-Tools verfügbar ist, um grundlegende Verwaltungsaufgaben zu ermöglichen und die Netzwerkkonnektivität sicherzustellen.
VSAs werden über das StorMagic vCenter Plugin verwaltet. Darüber hinaus verfügt jeder VSA über eine Weboberfläche, die über einen beliebigen Webbrowser unter Verwendung der VSA-IP-Adresse oder des Hostnamens genutzt werden kann.
SvSAN erfordert einen VMware vSphere Hypervisor und kann mit oder ohne vCenter ausgeführt werden. SvSAN kann eine integrierte vSphere-Verwaltung bieten, wenn ein vCenter-Server verfügbar ist.
Wenn kein vCenter-Server zur Verfügung steht, kann SvSAN über eine Weboberfläche und die Hosts verwaltet werden, um Software-definierte SAN-Funktionen bereitzustellen. vCenter ist für VM High Availability erforderlich.
Ja, SvSAN unterstützt alle TCP/IP-Netzwerke mit Architekturen, die Subnetze oder VLANS verwenden, um die Verkehrstypen zu trennen. Für den Zugriff auf das Plugin unter Verwendung von VLANs müssen die Verwaltungsschnittstellen zwischen dem vCenter und den Appliances konfiguriert werden. Sie könnten zum Beispiel ein VLAN mit einem vCenter, einer Service-Konsole und einer SvSAN-Verwaltungsschnittstelle haben und ein anderes VLAN mit einem VMKernel und einer weiteren SvSAN-Schnittstelle, die ein dediziertes iSCSI-VLAN bereitstellt.
Ja, es ist möglich, ein gestaffeltes, unterbrechungsfreies Upgrade sowohl des Hosts als auch der virtuellen Appliance durchzuführen.
SvSAN mit Microsoft Hyper-V
Die Hypervisor-Versionskompatibilität für SvSAN finden Sie im SvSAN-Datenblatt. In der Hypervisor-Kompatibilitätstabelle finden Sie alle unterstützten Hypervisoren.