SvSAN – Häufig gestellte Fragen
Die StorMagic SvSAN-FAQ soll eine Vielzahl von Fragen zu StorMagic SvSAN, dessen Bereitstellung und Funktionen beantworten.
Zusätzlich zu diesen häufig gestellten Fragen steht Ihnen eine vollständige Dokumentation zur Bereitstellung von SvSAN zur Verfügung, die Sie unter folgendem Link einsehen können: der SvSAN-Handbuchseite.
Haben Sie das SvSAN-Datenblattsowie das Whitepaper „Technischer Überblick über SvSAN“durchgelesen, die beide zahlreiche nützliche Informationen zu SvSAN, seinen Anforderungen und Funktionen enthalten?
Sollten Sie in den SvSAN-FAQ keine passende Antwort finden, können Sie sich an das StorMagic-Team unter [email protected].
Fragenkategorien
Allgemeine Fragen
StorMagic SvSAN vereinfacht die IT-Speicherverwaltung. Im Gegensatz zu den zahlreichen Konkurrenzlösungen auf dem Speichermarkt ist StorMagic SvSAN weder komplex noch teuer oder schwer zu verwalten. Im Mittelpunkt steht das Ziel, Ihrem Unternehmen einen einfachen virtuellen Speicher zur Verfügung zu stellen. Es macht das Komplexe einfach.
SvSAN ist ein hochverfügbares virtuelles SAN mit zwei Knoten, das für hyperkonvergierte Edge-Standorte und kleine Rechenzentren konzipiert ist. Die Technologie basiert auf softwaredefiniertem Speicher, wodurch physische SANs überflüssig werden. Sie wird als virtuelle Speicher-Appliance (VSA) auf einem Hypervisor bereitgestellt.
SvSAN ermöglicht hochverfügbare Cluster durch die Spiegelung von Daten zwischen zwei Knoten. Dank seiner Einfachheit sind pro Standort lediglich zwei Knoten erforderlich, wobei die Bereitstellung, die Verwaltung und die Witness-Dienste von einem zentralen Standort aus ferngesteuert erfolgen können.
SvSAN unterstützt die Hypervisoren VMware vSphere, Microsoft Hyper-V und Proxmox VE. Es wird als virtuelle Speicher-Appliance (VSA) installiert, die nur minimale Serverressourcen benötigt, um den gemeinsamen Speicher bereitzustellen, der für die Nutzung erweiterter Hypervisor-Funktionen wie Hochverfügbarkeits-/Failover-Cluster, vMotion/Live-Migration und VMware Distributed Resource Scheduler (DRS)/Dynamic Optimization erforderlich ist.
Ausführliche Informationen zur Hypervisor-Kompatibilität der neuesten Version von SvSAN finden Sie im SvSAN-Datenblatt.
SvSAN lässt sich als einfacher Cluster mit zwei Knoten bereitstellen und bietet dabei die Flexibilität, sich an wechselnde Kapazitäts- und Leistungsanforderungen anzupassen. Dies wird erreicht, indem entweder zusätzliche Kapazität zu bestehenden Servern hinzugefügt wird oder der SvSAN-Cluster erweitert wird, ohne dass die Verfügbarkeit der Dienste beeinträchtigt wird.
SvSAN spiegelt Daten synchron zwischen VSAs und Clusterknoten und stellt so sicher, dass die Daten an zwei Orten gespeichert sind, bevor der Vorgang als abgeschlossen bestätigt wird.
Jede Seite des Spiegels (Plex) ist aktiv, wodurch der Zugriff auf die Daten von jedem Plex aus möglich ist. Sollte eine Seite des Spiegels ausfallen (Serverausfall, Speicherausfall, Netzwerkausfall), kann weiterhin von dem verbleibenden Plex aus auf die Daten zugegriffen werden.
Solange eine Seite eines Spiegels offline ist, werden Änderungen an der verbleibenden Seite im Metadaten-Journal protokolliert. Nach der Wiederherstellung wird das Journal ausgelesen, um festzustellen, welche Daten sich geändert haben; diese werden dann zusammen mit allen neu geschriebenen Daten auf die wiederhergestellte Seite des Spiegels kopiert. Dieser Vorgang wird als „schnelle Neusynchronisierung“ bezeichnet.
Das Metadaten-Journal sollte eine Größe von mindestens 20 GB aufweisen, um eine sehr große Anzahl von Änderungen verarbeiten zu können. Sollte der Umbruch des Metadaten-Journals fehlschlagen, führt das System einfach eine vollständige Neusynchronisierung des Spiegels durch.
Wenn ein Hardware-RAID nicht möglich ist, beispielsweise bei bestimmten Edge-Servermodellen, die keine Unterstützung für Hardware-RAID-Karten bieten, stellt SvSAN Software-RAID-Funktionen zur Verfügung. Weitere Einzelheiten hierzu finden Sie in unserem Blog zum Thema Software-RAID.
SvSAN bietet keinen expliziten Schutz vor Festplattenausfällen. Der Server, auf dem die VSA ausgeführt wird, schützt mithilfe von Hardware-RAID vor Festplattenausfällen.
In Fällen, in denen kein RAID vorhanden ist, werden die Daten durch SvSAN geschützt, indem eine gespiegelte Kopie der Daten auf einem anderen SvSAN-Knoten gespeichert wird.
Der VSA ist darauf ausgelegt, jeden unerwarteten Stromausfall zu bewältigen. Beim Hochfahren führt der VSA Prüfungen durch, um festzustellen, ob er zuvor ordnungsgemäß heruntergefahren wurde.
Falls das VSA zuvor nicht ordnungsgemäß heruntergefahren wurde, werden Überprüfungen durchgeführt, um sicherzustellen, dass alle Konfigurationsdaten konsistent und korrekt sind.
Ein VSA enthält zwei Boot-Images, um vor Datenbeschädigungen zu schützen. Sollte das primäre Boot-Image beschädigt werden, kann der VSA von dem anderen Image booten.
SvSAN wurde so konzipiert, dass es so weit wie möglich skalierbar ist, da für die meisten Komponenten keine festen Obergrenzen gelten, sondern die Skalierbarkeit vielmehr durch die verfügbaren Hardware-Ressourcen begrenzt wird.
Die maximale Kapazität einer virtuellen Festplatte beträgt 128 Petabyte.
Die kleinste Skalierungseinheit zur Bereitstellung hochverfügbaren gemeinsam genutzten Speichers besteht aus zwei Knoten, wobei virtuelle Festplatten zwischen den Knoten gespiegelt werden.
Ein dritter Server wird verwendet, um ein Quorum zum Schutz vor Split-Brain-Szenarien bereitzustellen; dabei handelt es sich um den SvSAN-Witness. Erfahren Sie mehr darüber in diesem White Paper. Der Witness kann sich vor Ort oder über ein WAN an einem entfernten Standort befinden. Falls kein dritter Knoten verwendet werden kann, kann SvSAN mithilfe der „Stay-up-Isolationsrichtlinie“ in einer Konfiguration mit zwei Knoten betrieben werden.
Ab zwei Knoten kann eine beliebige Anzahl von Knoten unterstützt werden. Es ist möglich, so viele gespiegelte virtuelle Festplatten zu erstellen, wie die Kapazität zulässt, und jede davon kann zwischen einem beliebigen Knotenpaar gespiegelt werden. Darüber hinaus lässt sich SvSAN in Clustern mit drei Knoten konfigurieren. Weitere Informationen zu dieser Art der Konfiguration finden Sie unter das entsprechende Whitepaper.
Weitere Fragen zum SvSAN-Witness werden in einem separaten Abschnitt weiter unten.
Die Systemanforderungen für SvSAN sind im SvSAN-Datenblatt aufgeführt. Ausführliche Informationen entnehmen Sie bitte der Tabelle mit den Systemanforderungen.
SvSAN unterstützt bis zu 32 GB Arbeitsspeicher.
Die folgende Tabelle zeigt die empfohlene Speichermenge, die dem VSA zugewiesen werden sollte, basierend auf der Speichergröße und der Größe des SSD-Caches:
| Größe des SSD-Caches | |||||||
| Bis zu0 GB² | Bis zu 250 GB | Bis zu 500 GB | Bis zu 1000 GB | Bis zu 1.500 GB | Bis zu 2000 GB | ||
| Speicher-Cache erforderlich | 0 GB1 | 1 GB | 3 GB | 3 GB | 4 GB | 5 GB | 6 GB |
| 1 GB | 3 GB | 4 GB | 4 GB | 5 GB | 6 GB | 7 GB | |
| 2 GB | 4 GB | 5 GB | 5 GB | 6 GB | 7 GB | 9 GB | |
| 3 GB | 5 GB | 6 GB | 6 GB | 7 GB | 9 GB | 10 GB | |
| 4 GB | 6 GB | 7 GB | 7 GB | 9 GB | 10 GB | 11 GB | |
| 6 GB | 9 GB | 9 GB | 10 GB | 11 GB | 12 GB | 13 GB | |
| 8 GB | 11 GB | 11 GB | 12 GB | 13 GB | 14 GB | 15 GB | |
| 12 GB | 15 GB | 16 GB | 16 GB | 17 GB | 18 GB | 20 GB | |
| 16 GB | 20 GB | 20 GB | 21 GB | 22 GB | 23 GB | 24 GB | |
| 20 GB | 24 GB | 24 GB | 25 GB | 26 GB | 27 GB | 28 GB | |
| 24 GB | 28 GB | 29 GB | 29 GB | 31 GB | 32 GB | – | |
1 Speicher-Caching deaktiviert
2 SSD-Caching deaktiviert
Weitere Informationen zu den Caching-Funktionen von SvSAN finden Sie im Whitepaper zum Thema Caching.
Die Mindestbandbreite des Netzwerks beträgt 1 Gb Ethernet.
SvSAN unterstützt 10-Gbit/s- und 40-Gbit/s-Ethernet, Jumbo-Frames sowie Netzwerk-Teaming, um die Netzwerkleistung zu verbessern.
Ja, SvSAN nutzt alle Netzwerkverbindungen, die für den virtuellen Server konfiguriert sind. SvSAN kann so konfiguriert werden, dass es die Bandbreite aller verfügbaren Netzwerkschnittstellen ausbalanciert und bündelt. Diese können für Verwaltungszwecke, Spiegelung oder iSCSI-Datenverkehr genutzt werden.
Ja, auf den virtuellen Servern müssen zwei virtuelle Switches konfiguriert werden. SvSAN wird standardmäßig mit zwei virtuellen Netzwerkschnittstellen (vNICs) installiert und konfiguriert. Es können jedoch weitere Netzwerkschnittstellen hinzugefügt werden.
Sollten alle für den Spiegelungsverkehr genutzten Netzwerkschnittstellen nicht verfügbar sein, wird der Spiegelungsverkehr über die verbleibenden Schnittstellen des Verwaltungsnetzwerks umgeleitet.
Ja, ein bestehendes, nicht gespiegeltes Ziel kann in ein gespiegeltes Ziel umgewandelt werden und umgekehrt. Weitere Informationen finden Sie in der SvSAN-Handbuch oder wenden Sie sich an unser Support-Team unter [email protected] , um detaillierte Anweisungen zu erhalten.
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, auf der Registerkarte „System“ der Web-GUI oder in der VSA-Ansicht unter „>“ auf der Registerkarte „System“ im StorMagic-Plugin einsehen. Beispiel: https://VSAname.domainname/system/license/
Ja, die Knoten eines SvSAN-Clusters können sich an unterschiedlichen Standorten befinden. Beispielsweise auf verschiedenen Seiten eines Gebäudes, auf dem gesamten Campus oder in verschiedenen Städten.
Bitte beachten Sie das Whitepaper zum Stretch-Cluster , um weitere Informationen zu den Anforderungen an Bandbreite und Latenz zu erhalten, oder wenden Sie sich an unser Support-Team unter [email protected].
Ja, in einigen Fällen ist es möglich, eine einzelne Firmware-Version zu überspringen, beispielsweise von SvSAN 6.1 direkt auf SvSAN 6.3. Das Zwischen-Upgrade auf SvSAN 6.2 ist nicht erforderlich.
Informationen zu den unterstützten und gültigen Upgrade-Pfaden entnehmen Sie bitte den SvSAN-Versionshinweisen.
Wir empfehlen Ihnen jedoch, stets die aktuellste Version der SvSAN-Firmware zu verwenden, um sicherzustellen, dass Sie Zugriff auf die neuesten Funktionen sowie auf aktuelle Sicherheits-, Leistungs- und Fehlerbehebungen haben.
Lizenzierung und Support
Ja, eine kostenlose, voll funktionsfähige Testversion von SvSAN steht zum Download bereit, sodass Unternehmen die Funktionen und Vorteile von SvSAN vor dem Kauf testen und kennenlernen können. Weitere Informationen sowie den Download der Testversion finden Sie unter die Seite zum Download der Testversion auf der Website.
Während der Testphase können die Tester auf Wunsch Unterstützung und Hilfe bei der ersten Installation sowie eine Produktvorführung erhalten.
Ausführliche Informationen zur Lizenzierung und Preisgestaltung von SvSAN finden Sie auf der Seite „SvSAN-Preise“.
SvSAN ist als Basislizenz erhältlich, die alle für hochverfügbaren gemeinsam genutzten Speicher erforderlichen Funktionen umfasst.
Darüber hinaus stehen für SvSAN zwei Add-ons zur Verfügung, mit denen sich die Leistung und Sicherheit verbessern lassen.
Die leistungssteigernden Funktionen von SvSAN werden zusammenfassend als „Predictive Storage Caching“ bezeichnet. Dabei kommen patentierte Algorithmen zum Einsatz, um das volle Potenzial von Arbeitsspeicher- und Hybridfestplattenkonfigurationen auszuschöpfen.
Die Datenverschlüsselungsfunktion von SvSAN ermöglicht es Unternehmen mit einem bis zu Tausenden von Standorten, an jedem einzelnen Standort kostengünstig und effizient Datenverschlüsselung einzuführen.
Eine ausführliche Erläuterung der SvSAN-Funktionen finden Sie auf der Seite „SvSAN-Funktionen“.
Ja, eine Kapazitätserweiterung ist jederzeit möglich.
Um Software-Updates und Produktunterstützung zu erhalten, ist ein gültiger StorMagic-Wartungs- und Supportvertrag erforderlich.
StorMagic bietet rund um die Uhr erstklassigen Support, um sicherzustellen, dass Kunden und Partner etwaige auftretende Probleme schnell und effektiv beheben können. Der Wartungs- und Support-Service von StorMagic ermöglicht den sofortigen Zugriff auf Artikel der Wissensdatenbank, Software-Updates – einschließlich größerer und kleinerer Updates (darunter Fehlerbehebungen und die Veröffentlichung neuer Funktionen) – sowie die Möglichkeit, Anfragen an den technischen Support zu stellen.
Der StorMagic-Wartungs- und Support-Service ist in zwei Stufen erhältlich: Gold oder Platin.
Ausführliche Informationen zum StorMagic-Support, einschließlich Vergleiche zwischen Support-Paketen, Produktlebenszyklus-Matrixen, Schweregraddefinitionen und Geschäftszeiten des Supports, finden Sie im Übersichtsdokument zum StorMagic-Support.
SvSAN-Witness
YDer SvSAN-Witness ist ein Quorum-Dienst, der als Entscheidungsträger fungiert und im Falle eines Ausfalls, der die Wahl eines Cluster-Leaders erforderlich macht, eine Mehrheitsentscheidung herbeiführt. Dadurch wird verhindert, dass SvSAN-Cluster in einen Zustand geraten, der als „Split-Brain“ bezeichnet wird.
„Split-Brain“ ist ein Cluster-Zustand, der auftritt, wenn Clusterknoten den Kontakt zueinander verlieren und beginnen, unabhängig voneinander zu arbeiten. Die Daten auf den einzelnen Knoten weichen zunehmend voneinander ab und werden inkonsistent, was letztendlich zu Datenbeschädigungen und -verlusten führt.
Die Systemanforderungen für den SvSAN-Witness sind im Datenblatt zum SvSAN-Witness aufgeführt. Ausführliche Informationen entnehmen Sie bitte der Tabelle mit den Systemanforderungen.
Der Witness kann als Software bereitgestellt werden, entweder lokal im SvSAN-Cluster oder remote, beispielsweise in einem externen Rechenzentrum oder in der Cloud. Alternativ steht der Witness-Dienst als Cloud-Abonnementdienst zur Verfügung, der als „Witness-as-a-Service“ (WaaS) bezeichnet wird. Weitere Informationen zu diesen Optionen finden Sie auf der Webseite zur „Witness“-Funktion.
Nein – der Witness ist eine optionale Infrastrukturkomponente, wird jedoch für die Hochverfügbarkeit benötigt.
Informationen zur Betriebssystemkompatibilität für den SvSAN-Witness finden Sie im SvSAN-Witness-Datenblatt. Eine Übersicht über alle unterstützten Betriebssysteme finden Sie in der Tabelle mit den Systemanforderungen.
Eine ausführliche Übersicht über die verschiedenen Ausfallszenarien, vor denen der SvSAN-Witness Schutz bieten kann, finden Sie im White Paper zum Witness.
Der Witness nutzt den SvSAN-Erkennungsdienst, der den Netzwerkport 4174 (TCP/UDP) verwendet. Weitere Informationen finden Sie in der „Von SvSAN verwendete Portnummern“ Abschnitt des SvSAN-Handbuch finden Sie eine Übersicht über alle von SvSAN verwendeten Ports.
Bei der Nutzung des Witness über eine WAN-Verbindung gelten die folgenden Empfehlungen hinsichtlich Netzwerkbandbreite und Latenz, um einen optimalen Betrieb zu gewährleisten:
- Die Latenz sollte weniger als 3.000 ms betragen; dies würde es ermöglichen, den Zeugen nahezu überall auf der Welt zu stationieren.
- Die vom VSA an den Witness übertragene Datenmenge ist gering (weniger als 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 auch bei sehr hohen Latenzzeiten einwandfrei funktionieren und stellt nur sehr geringe Anforderungen an die Netzwerkbandbreite. Auch wenn es sich hierbei um Extremszenarien handelt und Netzwerke mit diesen Eigenschaften in der Praxis nur selten zum Einsatz kommen, zeigt dies doch, wie effizient der Witness ist.
Weitere Informationen zu den Toleranzen des Witness hinsichtlich Bandbreite und Latenz finden Sie im Whitepaper zum SvSAN-Witness.
Der Witness kann von mehreren SvSAN-Clustern gemeinsam genutzt werden. Die empfohlene Obergrenze liegt bei 1.000 Clustern für einen einzelnen Witness.
Der Witness speichert keine Anwendungs- oder Kundendaten, sondern erfasst lediglich den Spiegelungsziel- und den Cluster-Status. Zu den auf dem Witness gespeicherten Daten gehören:
- Spiegelungsstatus (synchronisiert, wird neu synchronisiert usw.)
- iSCSI-qualifizierter Name (IQN)
- Name des Spiegelziels
- Bezeichnungen für Spiegel-Plexe
- Auf welchen Servern befinden sich die Spiegel-Plexe?
Ja – der Witness kann sich in einem separaten Subnetz befinden.
Der Witness nutzt den SvSAN-Erkennungsdienst, der den Netzwerkport 4174 (TCP/UDP) verwendet. Standardmäßig „durchquert“ dieser Dienst keine Subnetze, um sicherzustellen, dass der Broadcast-Verkehr auf ein Minimum beschränkt bleibt. Es ist jedoch möglich, statische Netzwerkeinträge in den Netzwerk-Routing-Tabellen anzulegen, wodurch der Witness in anderen Subnetzen als die VSA-Cluster angesiedelt werden kann.
Statische Netzwerkeinträge können nach der Bereitstellung manuell über die Web-Benutzeroberfläche oder per Skript erstellt werden. Sie werden automatisch angelegt, wenn statische IP-Adressen für die Verwaltungsadresse des VSA verwendet werden.
Für ein Cluster-/Spiegelungsziel kann jeweils nur ein einziger Witness das Quorum gewährleisten. Damit soll sichergestellt werden, dass sich alle VSAs innerhalb eines Clusters darüber einig sind, welche VSA die Führungsrolle innehat. Der Witness verfügt jedoch über eine Reihe von Bereitstellungsoptionen, um seine Verfügbarkeit zu gewährleisten:
- Der Witness kann auf einer virtuellen Maschine installiert werden, die im Falle eines Ausfalls auf einen anderen virtuellen Server umgeschaltet werden kann.
- Der Witness kann auf einem Standby-Server bzw. einer Standby-VM installiert werden. Es wird eine manuelle Umschaltung durchgeführt, damit die Cluster bzw. Spiegelziele im Falle eines Ausfalls diesen „Standby“-Witness nutzen. Dieser Vorgang kann per Skript automatisiert werden.
- In VMware vSphere-Umgebungen kann der Witness auf einer fehlertoleranten (FT) virtuellen Maschine installiert werden, wodurch sichergestellt wird, dass es zu keinen Ausfallzeiten des Witness-Dienstes kommt.
- Es ist zudem möglich, die Umstellung mithilfe eines separaten Überwachungsgeräts und PowerShell-Cmdlets zu automatisieren.
Ja, das ist möglich, solange es sich außerhalb des Clusters befindet, für den es das Quorum bereitstellt.
Ja – es ist möglich, den Witness auf einem Server oder einer virtuellen Maschine (VM) zu betreiben, die von einem Cloud-Anbieter gehostet wird. Darüber hinaus ist der Witness auch als Cloud-Dienst verfügbar, der als „Witness-as-a-Service“ bezeichnet wird und von StorMagic bereitgestellt wird; dieser kann mit den SvSAN-Clustern verbunden werden.
Die StorMagic SvSAN Witness Appliance ist eine eingeschränkte Version der SvSAN VSA, die ausschließlich zur Bereitstellung von Quorum-Funktionen dient. Sie bietet folgende Vorteile:
- Geringe Systemanforderungen (CPU, Arbeitsspeicher und Festplattenspeicher)
- Eigenständig – benötigt kein anderes Betriebssystem, z. B. Microsoft Windows oder Linux
- Schnellere Bereitstellung
- Das Upgrade erfolgte mit derselben Firmware wie beim SvSAN VSA
- Die Witness Appliance ist ausschließlich für VMware vSphere ESXi-Umgebungen vorgesehen.
SvSAN-Datenverschlüsselung
Gartner definiert Verschlüsselung wie folgt:
„Verschlüsselung ist der Vorgang, bei dem ein Bitstrom vor der Übertragung systematisch verschlüsselt wird, sodass Unbefugte ihn nicht entschlüsseln können.“
Die Verschlüsselung sollte als ein Aspekt einer umfassenderen Sicherheitsstrategie betrachtet werden und bezeichnet den Vorgang der Umwandlung von Daten von einer Form (Klartext) in eine andere (Chiffretext). Sie stellt sicher, dass, sollten die Daten in die Hände Unbefugter gelangen, kein Zugriff auf die Daten möglich ist, ohne über die richtigen Encryption-Keys zur Entschlüsselung der Daten zu verfügen.
Die Datenverschlüsselung schützt Daten bei der Speicherung auf Festplatten und kann dazu dienen, Daten vor unbefugtem Zugriff oder Gerätediebstahl zu schützen.
Im Falle eines Festplattenausfalls können die ausgefallenen Festplatten nun entsorgt oder ausgetauscht werden, ohne dass ein Zugriff auf die Daten zu befürchten ist, da diese verschlüsselt sind. Dadurch entfällt die Notwendigkeit von Datenvernichtungsverfahren wie dem „Entmagnetisieren“ von Magnetplatten, der physischen Zerstörung oder dem „Disk Scrubbing“.
Die Datenverschlüsselungsfunktion von SvSAN nutzt die weit verbreitete 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-Verschlüsselungsmethode zur Verschlüsselung der Daten.
Die Länge des kryptografischen Schlüssels beträgt 256 Bit.
Die SvSAN-Datenverschlüsselung nutzt ein integriertes, nach FIPS 140-2 (Stufe 1) validiertes kryptografisches Modul (OpenSSL Object Module v2.0, Zertifikat Nr. 1747), das auf der SvSAN-Plattform gemäß den Richtlinien in Abschnitt G.5 der FIPS 140-2-Implementierungsrichtlinien ausgeführt wird.
SvSAN selbst ist jedoch derzeit nicht nach FIPS 140-2 zertifiziert.
Gartner definiert „Enterprise Key-Management“ (EKM) wie folgt:
„Enterprise Key-Management (EKM) bietet eine einzige, zentralisierte Software oder Netzwerk-Appliance für verschiedene kryptografische Lösungen zur symmetrischen Verschlüsselung oder Tokenisierung. Entscheidend ist, dass es durch das Verschlüsselungs- und Tokenisierungsmanagement einheitliche Richtlinien für den Datenzugriff durchsetzt. Zudem erleichtert es die Schlüsselverteilung und die sichere Speicherung von Schlüsseln und gewährleistet ein einheitliches Schlüssel-Lebenszyklusmanagement.“
Darüber hinaus führen sie außerdem aus, dass:
„EKM-Produkte basieren auf dem KMIP-Standard (Key-Management Interoperability Protocol), der von der Organisation zur Förderung strukturierter Informationsstandards (OASIS) gefördert wird. EKM-Lösungen können alle kryptografischen Lösungen verwalten, die mit KMIP kompatibel sind.“
Das Key-Management-Interoperability-Protokoll (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 verfügte jeder Anbieter über eine eigene Lösung für das Encryption Key Management, was dazu führte, dass mehrere Systeme für das Key-Management (KMS) zum Einsatz kamen, was wiederum den Verwaltungsaufwand erhöhte.
KMIP bietet einen Standardmechanismus, über den Anwendungen, Speicher-Arrays, Bandbibliotheken, Festplattenlaufwerke (selbstverschlüsselnde Laufwerke) und Netzwerkgeräte mit Key-Management-Lösungen (KMS) verschiedener Anbieter kommunizieren können, wodurch sich die Anzahl der erforderlichen Key-Management-Lösungen verringert.
Die SvSAN-Datenverschlüsselung unterstützt die KMIP-Versionen 1.0 bis 1.4.
Standardmäßig verwendet KMIP 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-konformen 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 kryptografischer Schlüssel entwickelt wurde.
StorMagic empfiehlt SvKMS für das Encryption Key Management bei SvSAN-Benutzern, bei denen die Datenverschlüsselungsfunktion aktiviert ist. Das SvSAN-Handbuch enthält jedoch Integrationsanleitungen für viele führende KMS-Lösungen namhafter Anbieter.
Integrationsleitfäden sind im SvSAN-Handbuch unter dem Abschnitt „Weitere Leitfäden > Datenverschlüsselung – SvSAN KMS-Integration“ enthalten.
Die Verfügbarkeit ist die wichtigste Anforderung an das Key-Management. Daher wird dringend empfohlen, mindestens zwei oder möglichst mehrere Server für das Key-Management einzusetzen, um sicherzustellen, dass die Schlüssel stets verfügbar sind.
Sollte es nicht möglich sein, eine Verbindung zum KMS herzustellen, um die kryptografischen Schlüssel abzurufen, ist es nicht möglich, die Daten zu verschlüsseln oder – was noch wichtiger ist – zu entschlüsseln, und die Daten gehen verloren.
Durch den Einsatz mehrerer Server für das Key-Management können die Schlüssel repliziert werden; idealerweise sollten diese an verschiedenen Standorten bzw. in verschiedenen Rechenzentren installiert sein, um sicherzustellen, dass Stromausfälle, Überschwemmungen, Brände usw. die Verfügbarkeit nicht beeinträchtigen.
Neben dem Einsatz mehrerer Server sollten bewährte Verfahren für das Key-Management befolgt werden, wie zum Beispiel:
- Erstellen Sie regelmäßig Sicherungskopien des KMS
- Bewahren Sie die Schlüssel nicht auf dem Speichermedium auf, das sie schützen sollen.
Es ist stets ratsam, sich mit dem KMS-Anbieter abzustimmen, um sicherzustellen, dass alles gemäß dessen Best Practices konfiguriert und eingerichtet ist.
Nein, die SvSAN-Datenverschlüsselung erfolgt ausschließlich softwaremäßig und erfordert keine speziellen Verschlüsselungskarten, RAID-Karten, FPGAs oder ASICs.
Da die Verschlüsselung jedoch sehr rechenintensiv sein kann, bieten viele moderne CPUs mittlerweile Befehle zur Hardwarebeschleunigung an, um die Verschlüsselungsleistung deutlich zu verbessern; diese werden als „Advanced Encryption Standard New Instruction“ (AES-NI)-Operationen bezeichnet. (https://en.wikipedia.org/wiki/AES_instruction_set)
SvSAN nutzt die OpenSSL-Bibliothek und die Verschlüsselungsmethode XTS-AES-265, die wiederum die AES-NI-Hardwarebeschleunigungsbefehle verwendet, sofern diese in der CPU vorhanden und aktiviert sind. Die AES-NI-Hardwarebeschleunigungsbefehle müssen möglicherweise im Server-BIOS aktiviert werden.
Ja, es wird möglich sein, ein bestehendes Volume zu verschlüsseln, auf dem bereits Daten gespeichert sind.
Ja. Eine Änderung der Encryption-Keys ist möglich.
Es gibt zahlreiche Faktoren, 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 weisen im Vergleich zur Vorgängergeneration Leistungsverbesserungen bei diesen Befehlen auf, wodurch Verschlüsselungsberechnungen schneller ausgeführt werden können.)
Wie schnell sind die zugrunde liegenden Festplatten?
Wie viel I/O und welche Datenmenge werden erzeugt?
Daher lautet die Antwort hinsichtlich der Auswirkungen auf die Leistung: „Es kommt darauf an“ – und hängt von der jeweiligen Kundenumgebung ab.
SvSAN-Funktion für Remote-Syslog
Syslog ist ein in RFC 5424 definiertes Standardprotokoll, das vom Dienstprogramm „rsyslog“ verwendet wird, um Systemprotokolle oder Ereignismeldungen an einen zentralen Server zu senden. Auf diese Weise können Protokolle von verschiedenen Geräten, darunter Server, Speichersysteme, Netzwerkgeräte (Router, Switches, Firewalls) sowie Peripheriegeräte (Drucker, Scanner). Auf diese Weise können die Protokolle für die Systemüberwachung, Sicherheitsprüfungen und andere Analysezwecke genutzt werden.
Traditionell nutzt Syslog das UDP-Protokoll auf Port 514, kann jedoch so konfiguriert werden, dass es einen beliebigen Port verwendet.
Derzeit werden alle Ereignisse vom VSA an den entfernten Syslog-Server gesendet.
Die SvSAN-Funktion für Remote-Syslog sollte mit jeder Syslog-Erfassungssoftware funktionieren, die das in RFC 5424 definierte Standardformat für Syslog-Meldungen entschlüsseln kann.
Es wurde mit den folgenden gängigen Syslog-Softwarepaketen getestet und funktioniert sofort, ohne dass eine zusätzliche Nachrichtenübersetzung erforderlich ist:
- Linux-Syslog-Server
- Nagios
- Paessler PRTG
- Graylog
Weitere Softwarepakete werden auf der Grundlage von Kundenrückmeldungen getestet und hinzugefügt.
SvSAN mit VMware vSphere
Informationen zur Hypervisor-Kompatibilität für SvSAN finden Sie im SvSAN-Datenblatt. Eine Übersicht über alle unterstützten Hypervisoren entnehmen Sie bitte der Hypervisor-Kompatibilitätstabelle.
Das Plugin ermöglicht die Verwaltung virtueller SANs durch eine assistentengestützte Bereitstellung sowie laufende Verwaltungsaufgaben direkt in vCenter vor Ort oder an einem zentralen Standort.
Das StorMagic-Dashboard innerhalb von vCenter zeigt den Betriebsstatus aller vom vCenter verwalteten VSAs anhand einer Ampelanzeige an und bietet die Möglichkeit, Firmware-Upgrades für die VSAs durchzuführen.
Die SvSAN-VSA-VM verfügt über eine Konsole, die über die Hypervisor-Tools zugänglich ist, um grundlegende Verwaltungsaufgaben zu ermöglichen und die Netzwerkverbindung sicherzustellen.
VSAs werden über das StorMagic vCenter-Plugin verwaltet. Darüber hinaus verfügt jede VSA über eine Weboberfläche, auf die über jeden beliebigen Webbrowser unter Angabe der IP-Adresse oder des Hostnamens der VSA zugegriffen werden kann.
SvSAN erfordert einen VMware vSphere-Hypervisor und läuft sowohl mit als auch ohne vCenter. SvSAN kann eine integrierte vSphere-Verwaltung bereitstellen, sofern ein vCenter-Server verfügbar ist.
Sollte ein vCenter-Server nicht verfügbar sein, kann SvSAN über eine Weboberfläche und die Hosts verwaltet werden, um softwaregesteuerte SAN-Funktionalität bereitzustellen. Für die Hochverfügbarkeit von virtuellen Maschinen ist vCenter erforderlich.
Ja, eine solche Migration ist möglich. Eine Schritt-für-Schritt-Anleitung finden Sie im VMware vSAN-Migrationsleitfaden.
Ja, SvSAN unterstützt uneingeschränkt alle TCP/IP-Netzwerkkonfigurationen mit Architekturen, die Subnetze oder VLANs zur Trennung von Datenverkehrstypen nutzen. Für den Zugriff auf das Plugin bei Verwendung von VLANs müssen die Verwaltungsschnittstellen zwischen dem vCenter und den Appliances konfiguriert werden. Beispielsweise könnten Sie ein VLAN haben, das ein vCenter, eine Service-Konsole und eine SvSAN-Verwaltungsschnittstelle enthält, sowie ein weiteres VLAN, das einen VMKernel und eine weitere SvSAN-Schnittstelle enthält, 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
Informationen zur Hypervisor-Kompatibilität für SvSAN finden Sie im SvSAN-Datenblatt. Eine Übersicht über alle unterstützten Hypervisoren entnehmen Sie bitte der Hypervisor-Kompatibilitätstabelle.