Wie die Everpure-Integration technisch in der Nutanix Cloud Platform funktioniert

Disaggregation klingt in der Theorie einfach: Compute und Storage werden getrennt.

In der Praxis entscheidet jedoch die technische Umsetzung, ob daraus ein tragfähiges Betriebsmodell entsteht oder lediglich eine externe Block-Storage-Anbindung.

Genau hier liegt der Unterschied.

Mit der neuen Integration von Everpure FlashArray in die Nutanix Cloud Platform entsteht kein „extern angebundenes Array“, sondern ein gemeinsam validiertes Architekturmodell mit klar definierten Rollen, IO-Pfaden und Lifecycle-Domänen.

Zwei Domänen – bewusst getrennt

Die gemeinsame Lösung basiert auf einer klaren Trennung:

1. Nutanix Cloud Platform
   
   • AHV
     
   • AOS
     
   • Controller-VM
     
   • Cluster-Management via Prism
     
2. Everpure FlashArray
   
   • Datenservices (Snapshots, Replikation, Deduplizierung, Verschlüsselung)
     
   • Performance-Management
     
   • QoS
     
   • Lifecycle über Purity & Evergreen
     

Diese Trennung ist kein Nebeneffekt. Sie ist das Architekturprinzip.

Rolle der Controller-VM: Von Storage-Engine zu Vermittler

In klassischen HCI-Umgebungen übernimmt die Controller-VM (CVM) die Bereitstellung und Orchestrierung von Storage-Services innerhalb des Clusters.

Im disaggregierten Modell mit Everpure verschiebt sich diese Rolle:

• Die CVM agiert als Vermittler zwischen VM und externer Datenplattform.
  
• Storage-Services laufen nicht im Compute-Cluster.
  
• CPU-Ressourcen der Nodes werden nicht für Deduplizierung, Replikation oder Snapshot-Logik verwendet.
  

Der IO-Pfad lautet: Workload → AHV → CVM → NVMe-oF/TCP → FlashArray

Die CVM bleibt integraler Bestandteil der Nutanix-Architektur – sie übernimmt jedoch nicht die Ausführung der Datenservices. Das ist ein fundamentaler Unterschied.

NVMe-oF/TCP: Performance ohne Spezial-Infrastruktur

Die Integration erfolgt über NVMe over Fabrics (TCP).

Warum ist das relevant?

• Nutzung standardisierter Ethernet-Infrastruktur
  
• Keine proprietären Fabrics notwendig
  
• Hohe Parallelität
  
• Geringe Latenz
  

In Enterprise-Umgebungen ist nicht nur die absolute Latenz entscheidend, sondern die Skalierbarkeit und Stabilität unter Last.

NVMe-oF/TCP ermöglicht:

• Hohe Queue-Tiefe
  
• Effiziente Multi-Threaded-IO-Verarbeitung
  
• Skalierung über mehrere Netzwerkpfade
  

Entscheidend ist dabei: Die CPU-Zyklen für Storage-Services verbleiben auf der dedizierten Storage-Plattform – nicht im Compute-Cluster.

vDisk-Level-Integration statt generischer LUN-Anbindung

Ein wesentliches Differenzierungsmerkmal der gemeinsamen Lösung ist die Integration auf vDisk-Ebene. Jede virtuelle Disk wird als eigenes Volume auf der FlashArray-Plattform abgebildet.

Das ermöglicht:

• Granulare Snapshot-Operationen pro VM
  
• VM-spezifische Wiederherstellung
  
• Feingranulare QoS-Kontrolle
  
• Replikation auf Volume-Ebene
  

Das unterscheidet die Lösung deutlich von generischen Block-Storage-Integrationen, bei denen mehrere VMs in einer gemeinsamen LUN zusammengefasst werden.

Hier wird das Disaggregationsmodell bewusst bis auf VM-Ebene durchgezogen.

Lifecycle-Trennung in der Praxis

Die strukturelle Entkopplung zeigt sich besonders im Lifecycle:

• Nutanix-Software wird über LCM aktualisiert
  
• Server-Firmware über Hersteller-Tools (z. B. Cisco Intersight)
  
• Storage-Software über Purity
  
• Storage-Hardware-Refresh über Evergreen – ohne disruptive Datenmigration
  

Das bedeutet: Ein Storage-Controller-Upgrade erfordert keine Workload-Migration. Ein Compute-Refresh erfordert keinen Storage-Umbau.

Für große Enterprise-Umgebungen reduziert diese Trennung operative Risiken erheblich.

Diese Lifecycle-Trennung wirkt sich nicht nur operativ aus, sondern auch ökonomisch.

Wenn Storage-Controller im Evergreen-Modell erneuert werden können, ohne Compute zu beeinflussen, entstehen keine erzwungenen Refresh-Zyklen.

Compute- und Storage-Investitionen lassen sich über mehrere Jahre hinweg getrennt planen. Das reduziert Investitionsspitzen und erhöht langfristige Planbarkeit.

Joint Engineering statt Anschlussoption

Entscheidend ist: Die Integration ist nicht als generische „External Storage“-Option konzipiert.

Sie wurde gemeinsam validiert:

• Unterstützte Topologien
  
• Definierte Performance-Profile
  
• Klar abgegrenzte Support-Domänen
  
• Dokumentierte Best Practices
  

Das unterscheidet ein validiertes Betriebsmodell von einer reinen Kompatibilitätsaussage. Hier entsteht ein bewusst gestaltetes Disaggregationsmodell.

Fazit

Disaggregation ist kein Selbstzweck. Sie entfaltet ihren Wert nur dann, wenn die technische Umsetzung sauber erfolgt.

Mit der Integration von Everpure FlashArray in die Nutanix Cloud Platform entsteht ein klar definiertes Architekturmodell:

• Compute bleibt workload-fokussiert
  
• Datenservices bleiben dediziert
  
• Lifecycle-Domänen bleiben getrennt
  
• Support-Strukturen bleiben klar
  

Entscheidend ist nicht, ob Storage intern oder extern angebunden ist. Entscheidend ist, wo die Datenservices laufen und wie sauber ihre Integration definiert ist.

Ausblick auf Teil 4

Die eigentliche strategische Wirkung zeigt sich nicht im ersten Jahr.

Sondern über einen gesamten Lifecycle hinweg.

Im nächsten Beitrag analysieren wir, warum entkoppelte Architekturen wirtschaftlich relevanter werden – gerade in Zeiten veränderter Lizenzmodelle.