S2D Performance Test

Dies ist ein nicht …

Storage Spaces Konfiguration:

Server 1

  • Boot Drive: 32 GB USB SSD
  • 4x WD RED 1 TB
  • 2x Toshiba P300 Desktop

Server 2

  • Boot Drive: 32 GB PCIe 2.0 SSD
  • 1x 500 GB WD
  • 1x 1TB WD Blue

Virtual Disks:

  • S (Nutzung: Steam Cache): Parity, 5 Spalten, 1 Kopie, FaultDomainAwareness: Physical Disk, Host: Anwendungsdaten
  • U (Nutzung: Hyper-V Disks (ISO)): Parity, 5 Spalten, 1 Kopie, FaultDomainAwareness: Physical Disk, Host: Horizontale Skalierung
  • V (Nutzung: Hyper-V Daten): 2 Spalten, 2 Kopien, FaultDomainAwareness: Physical Disk, Host: Horizontale Skalierung

Fault Domain Awareness "Physical Disk" wird hier nur verwendet, da die zwei Server keine Möglichkeit haben die Daten echt zu spiegeln - so kann ich den Speicher ohne Probleme vollständig nutzen, bin allerdings teilweise auf 1 GBit begrenzt.

Alle Tests laufen über 1 GBit Ethernet, sodass hier erheblich Leistung auf der Leitung bleibt.

Test 1, Laufwerk S

Das Laufwerk S wird im Netzwerk über einen regulären Failovercluster Anwendungsdaten-Server bereitgestellt, bedeutet, dass ein Server die Kontrolle über den Server bzw. den Endpunkt hat.

Test 2, Laufwerk U

Das Laufwerk U wird im Netzwerk über einen Failovercluster Horizontaler Dateiserver bereitgestellt, bedeutet, dass jeder Server, der Teil des Failoverclusters ist, als Endpunkt für den Server arbeiten kann. Hier reagiert der DNS Server als Lastenausgleich.

Test 3, Laufwerk V

Das Laufwerk V wird im Netzwerk über einen Failovercluster Horizontaler Dateiserver bereitgestellt, bedeutet, dass jeder Server, der Teil des Failoverclusters ist, als Endpunkt für den Server arbeiten kann. Hier reagiert der DNS Server als Lastenausgleich.

Previous Post Next Post