Informationen zur ONTAP IPspace Konfiguration
Änderungen vorschlagen
PDFs
IPspaces ermöglichen die Konfiguration eines einzelnen ONTAP Clusters, sodass Clients aus mehr als einer administrativ getrennten Netzwerkdomäne darauf zugreifen können, selbst wenn diese Clients denselben IP-Adress-Subnetzbereich verwenden. Dies ermöglicht die Trennung des Client-Datenverkehrs für Datenschutz und Sicherheit.
Ein IPspace definiert einen separaten IP-Adressraum, in dem sich Storage Virtual Machines (SVMs) befinden. Die für einen IPspace definierten Ports und IP-Adressen gelten nur innerhalb dieses IPspace. Für jede SVM innerhalb eines IPspace wird eine eigene Routing-Tabelle geführt, daher findet kein Routing zwischen verschiedenen SVMs oder IPspaces statt.
|
IPspaces unterstützen sowohl IPv4 als auch IPv6 Adressen in ihren Routing-Domänen. |
Wenn Sie den Speicher für eine einzelne Organisation verwalten, ist die Konfiguration von IPspaces nicht erforderlich. Wenn Sie den Speicher für mehrere Unternehmen auf einem einzigen ONTAP Cluster verwalten und sicher sind, dass keiner Ihrer Kunden widersprüchliche Netzwerkkonfigurationen hat, ist die Verwendung von IPspaces ebenfalls nicht erforderlich. In vielen Fällen kann die Nutzung von Storage Virtual Machines (SVMs) mit jeweils eigenen IP-Routingtabellen zur Trennung einzigartiger Netzwerkkonfigurationen anstelle von IPspaces eingesetzt werden.
Beispiel für die Verwendung von IPspaces
Ein typischer Anwendungsfall für die Nutzung von IPspaces ist, wenn ein Storage Service Provider (SSP) Kunden der Unternehmen A und B mit einem ONTAP Cluster in den Räumlichkeiten des SSP verbinden muss und beide Unternehmen die gleichen privaten IP-Adressbereiche verwenden.
Der SSP erstellt für jeden Kunden SVMs auf dem Cluster und stellt einen dedizierten Netzwerkpfad von zwei SVMs zum Netzwerk von Company A und von den anderen beiden SVMs zum Netzwerk von Company B bereit.
Diese Art der Bereitstellung wird in der folgenden Abbildung dargestellt und funktioniert, wenn beide Unternehmen nicht-private IP-Adressbereiche verwenden. Die Abbildung zeigt jedoch, dass beide Unternehmen dieselben privaten IP-Adressbereiche verwenden, was zu Problemen führt.
Beide Unternehmen nutzen das private IP-Adresssubnetz 10.0.0.0, was zu folgenden Problemen führt:
-
Die SVMs im Cluster am SSP-Standort haben widersprüchliche IP-Adressen, wenn beide Unternehmen entscheiden, für ihre jeweiligen SVMs dieselbe IP-Adresse zu verwenden.
-
Selbst wenn sich die beiden Unternehmen darauf einigen, unterschiedliche IP-Adressen für ihre SVMs zu verwenden, können Probleme auftreten.
-
Wenn beispielsweise ein Client im Netzwerk A die gleiche IP-Adresse wie ein Client im Netzwerk B hat, können Pakete, die für einen Client im Adressraum von A bestimmt sind, an einen Client im Adressraum von B weitergeleitet werden und umgekehrt.
-
Wenn die beiden Unternehmen beschließen, sich gegenseitig ausschließende Adressräume zu verwenden (beispielsweise verwendet A 10.0.0.0 mit einer Netzwerkmaske von 255.128.0.0 und B verwendet 10.128.0.0 mit einer Netzwerkmaske von 255.128.0.0), muss der SSP statische Routen auf dem Cluster konfigurieren, um den Datenverkehr entsprechend zu den Netzwerken von A und B zu leiten.
-
Diese Lösung ist weder skalierbar (aufgrund statischer Routen) noch sicher (Broadcast-Datenverkehr wird an alle Schnittstellen des Clusters gesendet). Um diese Probleme zu umgehen, definiert der SSP zwei IPspaces im Cluster, einen für jedes Unternehmen. Da kein Datenverkehr zwischen IPspaces geroutet wird, werden die Daten jedes Unternehmens sicher an das jeweilige Netzwerk weitergeleitet, selbst wenn alle SVMs im Adressraum 10.0.0.0 konfiguriert sind, wie in der folgenden Abbildung gezeigt:
Darüber hinaus beziehen sich die in den verschiedenen Konfigurationsdateien, wie der /etc/ hosts Datei, der /etc/hosts.equiv Datei und der the /etc/rc Datei, referenzierten IP-Adressen auf diesen IPspace. Daher ermöglichen die IPspaces dem SSP, dieselbe IP-Adresse für die Konfigurations- und Authentifizierungsdaten mehrerer SVMs ohne Konflikt zu konfigurieren.
Standardeigenschaften von IPspaces
Spezielle IPspaces werden standardmäßig erstellt, wenn das Cluster erstmals erstellt wird. Zusätzlich werden spezielle Storage Virtual Machines (SVMs) für jeden IPspace erstellt.
Zwei IPspaces werden automatisch erstellt, wenn das Cluster initialisiert wird:
-
"Standard" IPspace
Dieser IPspace ist ein Container für Ports, Subnetze und SVMs, die Daten bereitstellen. Wenn Ihre Konfiguration keine separaten IPspaces für Clients benötigt, können alle SVMs in diesem IPspace erstellt werden. Dieser IPspace enthält außerdem die Cluster-Management- und Node-Management-Ports.
-
"Cluster"-IPspace
Dieser IPspace enthält alle Cluster-Ports von allen Knoten im Cluster. Er wird automatisch erstellt, wenn der Cluster erstellt wird. Er stellt die Konnektivität zum internen privaten Clusternetzwerk bereit. Wenn dem Cluster weitere Knoten beitreten, werden die Cluster-Ports dieser Knoten dem „Cluster“ IPspace hinzugefügt.
Für jeden IPspace existiert eine „System“-SVM. Wenn ein IPspace erstellt wird, wird eine Standard-System-SVM mit demselben Namen erstellt:
-
Die System-SVM für den IPspace "Cluster" transportiert Cluster-Datenverkehr zwischen den Nodes eines Clusters im internen privaten Cluster-Netzwerk.
Es wird vom Cluster-Administrator verwaltet und hat den Namen „Cluster“.
-
Die System-SVM für den IPspace "Default" transportiert Management-Datenverkehr für den Cluster und die Knoten, einschließlich des Intercluster-Datenverkehrs zwischen den Clustern.
Es wird vom Cluster-Administrator verwaltet und verwendet denselben Namen wie das Cluster.
-
Die System-SVM für einen benutzerdefinierten IPspace, den Sie erstellen, transportiert den Management-Traffic für diese SVM.
Es wird vom Cluster-Administrator verwaltet und verwendet denselben Namen wie der IPspace.
In einem IPspace können eine oder mehrere SVMs für Clients existieren. Jede Client-SVM verfügt über eigene Daten-Volumes und Konfigurationen und wird unabhängig von anderen SVMs verwaltet.