Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

HP Proliant ML310e Gen8 + Intel SSD DC S3500

ESX(i)-taugliche Hardware, HCL .....

Moderatoren: irix, Dayworker

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

HP Proliant ML310e Gen8 + Intel SSD DC S3500

Beitragvon leo » 17.07.2013, 17:36

HP Proliant ML310e Gen8 + Intel SSD DC S3500

Ich habe zum Testen mal ein ESXI 5.1 U1 installiert.

Die SSD direkt angeschlossen (im Bios das Raid deaktiviert).

Ergebnis in einer Windows-VM:
Transferraten SSD Lesen 200 MB/s und Schreiben 138 MB/s. IOPS 1140 (Iometer all in one).

Write-Cache spielt bei der SSD keine Rolle, die Werte bleiben nahezu unverändert. Bei der 7200 Festplatte (WD RE4 500 GB) bricht dagegen ohne Write-Cache die Schreibperformance auf 30 MB/s ein.

Gegenüber früheren Tests mit ESXI 5.0, G7-Server und einer Intel 320 hat sich die Performance deutlich erhöht.

Was spricht gegen das System im Produktiveinsatz, wenn es nur um kleine Server mit geringen Datenmengen im 2-stelligen GB-Bereich geht?

Ein Raid-System müsste man ja schon mit einigen schnellen Festplatten ausstatten, wenn man da leistungsmäßig rankommen will, aber das Speichervolumen wäre dann überdimensioniert, abgesehen von den Kosten.

Ich muss mehrere Standorte mit neuer Hardware ausstatten, bei den geringen Kosten kann ich auch überall zwei Maschinen hinstellen, zur Ausfallsicherheit.

RAID zur Datensicherheit ist nicht so wichtig, da man die Datenmengen schnell mal zwischendurch sichern kann. Bei einer SSD merkt man auch bei Volllast nicht viel von einem laufenden Backup-Prozess.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 17.07.2013, 18:34

Das du noch die von dir geschriebenen Werte für Lesen und Schreiben erreichst, hängt ausschließlich mit der SSD-Geschwindigkeit als solches zusammen. Am Ende erreichst du mit der Server-SSD aber auch nicht mal die Hälfte dessen, zu welcher Leistung diese SSD im Stande wäre, wenn sie an einen Controller mit Schreibcache oder direkt am Chipsatz angeschlossen worden wäre...

Bezüglich "Raid zur Datensicherheit ist nicht so wichtig" habe ich eine andere Meinung und ich setze hier nur auf ein Raid1 zur Verlängerung meiner Reaktionszeit im Fehlerfall. Eine Backup-Regel besagt, daß egal wie häufig du ein Backup machst, im Fehlerfall entweder die aktuellen Daten noch nicht gesichert sind oder der zu sichernde Datenträger während des Backups seinen Geist aufgibt.
Es liegt natürlich an dir zu beurteilen, wie wertvoll im Ernstfall die dabei zu verlierenden Daten sind und wie lange ein Ausfall vom GF geduldet wird.

Experte
Beiträge: 1006
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 17.07.2013, 19:51

Dayworker hat geschrieben: Eine Backup-Regel besagt, daß egal wie häufig du ein Backup machst, im Fehlerfall entweder die aktuellen Daten noch nicht gesichert sind oder der zu sichernde Datenträger während des Backups seinen Geist aufgibt.


Ich möchte das gerne unterschreiben.

Noch besser wird wenn man was zurücksichern will, das Band einlegt, und irgendein hängengebliebener Backupjob freudig das Band löscht um was draufzusemmeln.

Ich möchte in diesem Zusammenhang auf Schreibschutzschalter hinweisen.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 17.07.2013, 20:08

Schreibschutzschalter, sowas gibt es und dann auch noch vollfunktional und ohne Wischiwaschi-Mentalität wie bei SD-Cards :?:

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 17.07.2013, 21:25

Für das Backup denke an 3 Stufen:

1. Stündlich auf ein NFS-Laufwerk sichern
2. mit Rsnapshot täglich, wöchentlich und monatliche Versionstände
3. Nachts Remote in eine sichere Location oder wenn das nicht möglich, über eine Samba-Freigabe auf ein USB-Laufwerk kopieren und dieses sicher verwahren

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 17.07.2013, 22:18

Die stündliche Sicherung bedeutet, daß dir im glimpflichen Ernstfall mal eben 59 Minuten und im Extremfall bei Ausfall während der Sicherung sogar 120 Minuten Arbeit verloren gehen. Sowas kann die gesamte EDV einer Firma lahmlegen oder bei zeitkritischen Geschäften dann schon mal den Ruin bedeuten und ich möchte den GF sehen, der darüber lächelnd hinwegsieht. Mir ist aufgrund vieler hier eingegangener Hilferufe natürlich auch bekannt, daß viele Chefs den monetären Einsatz scheuen und erst reagieren, wenn die Katze in den Brunnen geplumpst ist und es bereits zu einem Datenverlust gekommen war.

Wenn du eh täglich ein Rsnapshot (ich nehme hier mal rsync, robocopy oder vergleichbares Tool an) machst, weshalb dann diesen nicht stündlich oder bei detektierter Änderung durchlaufen lassen?
Ein Sicherung per rsync nimmt dank der Hardlinks wenig Platz weg und verhindert auch, daß korrekt gesicherte Daten im Fehlerfall durch Datenmüll überschrieben werden...

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 18.07.2013, 08:26

Da gebe ich dir recht, Backup's kann man nie genug haben, zumal wenn sie keine Arbeitszeit und Performance kosten. Ich werde die Backup-Strategie noch weiter ausbauen, vielleicht auch noch 1 oder 2 Stufen hinzufügen. Gegenüber früher, wo es üblich war, einmal pro Tag ein Band-Backup zu machen und die Backup-Strategie darin bestand, wie man diese Bänder rotiert, ist das aber schon ein riesiger Unterschied. Ich habe schon seit langen zusätzliche Backup-Methoden eingeführt, aber es gibt heute noch Firmen die so arbeiten.

http://www.rsnapshot.org/ ist ein Tool, welches auf rsync und hardlinks aufbaut, spart einem viel Script-Arbeit.

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 19.07.2013, 09:22

Ich habe jetzt einige Praxistests durchgeführt, mit Backups von den Systemen, welche wir auch produktiv einsetzen.

VMWare hat anscheinend einiges an den SATA-Treibern optimiert. Man bekommt zwar immer noch nicht die gleiche Leistung als wenn man die SSD in eine physikalischen Maschine einbaut, aber das Tempo, insbesondere für Datenbanken, ist mehr als ausreichend. Subjektiv sind die Server so schnell, wie wir sie noch nie hatten. Auch eine etwas gebremste SSD ist bei Datenbanken schneller als ein RAID, natürlich nur in den Bereichen, wo wir uns hier bewegen, für mehr als 4 Laufwerken ist in dem Server kein Platz.

Dazu passen dann auch die neuen Intel SSD DC S3700 und S3500. Sind zwar nicht die schnellsten, aber dafür haben Sie Puffer-Kondensatoren, um bei einem Stromausfall die internen Cache's zu sichern. Man braucht zwar nicht unbedingt den Write-Cache im Bios zu aktivieren, bringt kaum Geschwindigkeitsvorteile, aber eine SSD schreibt auch ohne Write-Cache nicht sofort, sondern sortiert die Daten so, dass möglichst wenige Blöcke belegt werden. Abgesehen von interen Prozessen, wie die Garbage-Collection.

Vielleicht kann man jetzt die generelle Empfehlung, für lokalen Storage nur aktive RAID-Karten einzusetzen, zumindest für kleine Serveranwendung relativieren.

Man erkennt das auch daran, dass ESXI 5.1 jetzt für die SATA-Ports einen Befehl hat, um SMART-Werte auszulesen:

esxcli storage core device smart get

Ideal, wenn man mit einem Script den Wear-Level überwachen will.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 19.07.2013, 13:14

Bezüglich der SSDs DC S3700 und S3500 ist deren größte Stärke weniger der Pufferkondensator sondern die genau spezifierte maximale Schreiblatenz und -konstanz. Im Produktspezifikations-PDF der DC S3700 hat Intel dort festgeschrieben:
  • Quality of Service
    - Read/Write: 500 µs (99.9%)
  • Performance Consistency
    - Read/Write: Up to 90%/90% (99.9%)
Beide Werte sind weit höher zu bewerten als jede maximale, sequentielle Lese/Schreib-Performance anderer SSDs.


Deiner Relativierung unserer Empfehlung, für lokalen Storage nur aktive RAID-Karten einzusetzen, auch wenn es um kleine Serveranwendungen geht, mag ich dagegen nicht zustimmen. Du schaffst dir hier ein völlig unnötigen Reihen-SPOF, denn der Controller stellt bereits einen solchen dar und mit einem einzelnen Datenträger hintendran baust du dir eine Kette. Es hat schon seinen Grund, weshalb für weiterführende ESXi-Funktionen ein Storage vorausgesetzt wird.


Schön das der ESXi inzwischen auch SSD-Smartwerte auslesen kann. Darauf kann man sich je nach Releasedatum der SSD nur nicht vollständig verlassen, da bisher jeder SSD-Hersteller sein eignes Süppchen hinsichtlich der Parameter und ihrer Bedeutung gekocht hat. An diesem Umstand hat sich inzwischen aber etwas getan und dürfte auch sehr bald in ein Spezifikationsupdate münden. Spätestens wenn sich die für nächstes Jahr erwarteten SSDs ganz normal per Sata Express anschließen lassen, sind die Smart-Parameter aller Hersteller wieder einheitlich.

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 19.07.2013, 14:22

Ein RAID hat auch Nachteile. Zum einen ist es ein zusätzliches Bauteil, welches defekt gehen kann. Dann besteht die Gefahr von Fehlalarmen, dass das RAID ohne Grund degradiert wird.Weiterhin muss man RAID-Probleme meist vor Ort lösen, und Fachpersonal hierfür ist bei kleinen Standorten in der Regel nicht vorhanden.

Ich bin also gar nicht so unglücklich, wenn wir kleinere Installationen in Zukunft ohne RAID hinbekommen.

Bei einem Serverausfall kann man dann die noch funktionierenden Laufwerke in einen anderen Server stecken. Dann kann ein Administrator über eine Remoteverbindung die Datastores und die VM's neu einbinden und es geht weiter.

Ich wollte auch nur eine mögliche Alternative vorstellen, welche ich im Moment am Testen bin. Ich bin dankbar für jeden Hinweis, was eventuell gegen einen Produktiv-Einsatz spricht. Alles testen kann man nicht und Probleme treten meist da auf, wo man am wenigsten damit rechnet.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.07.2013, 11:32

Natürlich kann ein Raid-Controller kaputtgehen oder einfach nur Fehlfunktionen zeigen, aber das kann dir mit dem in den Chipsatz integrierten auch passieren. Von daher stellt dann ein Zusatzcontroller die kostengünstigstere Lösung dar, ohne gleich das MB tauschen zu müssen. Zumal ein Raid bekanntermaßen auch kein Allheilmittel ist, es kann aber zumindest deine Reaktionszeit verlängern und stellt auch die von VMware einzig supportete Möglichkeit dar, um lokal angeschlossene Datenträger als VM-Speicherort einzubinden. Für den ESXi selbst gelten da VMware-seitig andere Regeln, da dieser zur Startzeit alle Daten eh komplett in den RAM einliest (den ESXi-Stick kann man nach dem Boot auch problemlos abziehen), er sich ratzfatz wieder installieren läßt und man dann nur noch die Config-Sicherung wieder einspielen muß.
Ich sehe auch keine Probleme beim HW-Tausch, sowas bekommt jeder hin und du weist ja anhand der eingespielten CIM-Provider auch welches Laufwerk ausserhalb seiner normalen Betriebsparameter agiert. Dann kann man über die Controllerverwaltung entweder die betroffene LW-LED leuchten lassen oder gibt dem Techniker das Laufwerk anhand eurer und gleichfalls dem Techniker vorliegender Dokumentation vor.

Funktionstüchtige Laufwerke in einen anderen Server weiter zu verwenden funktioniert. Du solltest nur einige Dinge vorher wissen und beachten. VMware bindet Laufwerke über auf den Datenträger geschriebene IDs ein und diese sind auch in gewissen Rahmen variabel. Doppelungen sind also nicht nur möglich sondern fast sicher und du hast dann kleinere Probleme, den richtigen Speicherort anzusprechen. Dieselbe ID wird also in einem anderen ESXi mit hoher Sicherheit auf einen völlig anderen Ort zeigen.
Welche Wirrungen möglich sind, siehst du am einfachsten, wenn du den ESXi zweimal virtuell installierst und dann die Laufwerke des einen mit im anderen einbindest.

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 20.07.2013, 18:28

Dayworker hat geschrieben:Zumal ein Raid bekanntermaßen auch kein Allheilmittel ist, es kann aber zumindest deine Reaktionszeit verlängern und stellt auch die von VMware einzig supportete Möglichkeit dar, um lokal angeschlossene Datenträger als VM-Speicherort einzubinden.


Ich glaube, dass ist bei den aktuellen ESXI-Versionen nicht mehr so richtig, ich habe mir die "Best practice" von ESXI 5.1 nochmal genau durchgelesen, hier heißt es zu internen SATA-Ports:

11.
For Serial ATA (SATA), a disk connected through supported SAS controllers or supported on-board SATA controllers. SATA disks will be considered remote, not local. These disks will not be used as a scratch partition by default because they are seen as remote.

Note: You cannot connect a SATA CD-ROM device to a virtual machine on an ESXi 5.1 host. To use the SATA CD-ROM device, you must use IDE emulation mode.

SATA disk drives. Supported on-board SATA include:

Intel ICH9
NVIDIA MCP55
ServerWorks HT1000

Note: ESXi does not support using local, internal SATA drives on the host server to create VMFS datastores that are shared across multiple ESXi hosts.

Demnach sind SATA-Ports supported, haben jedoch Einschränkungen, welche aber einen Stand-Alone-Server nicht betreffen.

Früher war dann noch das Problem, dass der SATA-Treiber von ESXi zu langsam war, deswegen wurde davon meist abgeraten, dass ist aber anscheinend jetzt besser geworden.

Ich habe noch nie gehört, dass der SATA-Port an einem Mainboard defekt war, wenn ist das ganze Board hinüber, das sind ja keine dedizierten Schnittstellen-Bausteine, die ganzen Funktionen des Mainboards sind auf ein oder zwei Chips integriert.

Es kann auch sein, dass eine Intel SSD an einem Intel SATA-Port zuverlässiger läuft, als an einem RAID-Kontroller von einem anderen Hersteller, welcher primär für HDD'S und nicht für SSD's entwickelt wurde.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.07.2013, 21:12

Bitte führe unbedingt die Quelle an, wenn du etwas referenzierst. Ich vermute aber mal, daß du vom KB-Eintrag Installing or upgrading to ESXi 5.1 best practices (2032756) sprichst.

In meinen Augen hast du dann bereits die falsche Passage am Wickel, denn schon bei Punkt 9 geht es um unterstützte Controller.
In Punkt 10 geht es um unpartitionierten Speicherplatz zur VM-Ablage (DS), der entweder eine SCSI-Platte oder eine lokal angeschlossene, RAID-Partition/LUN/Volume sein kann. Das "non-network" würde ich hier als "keine Netzwerkfreigabe" verstehen.
Punkt 11 verstehe ich dahingehend, daß SATA-Laufwerke an unterstützten SAS- oder onboard SATA-Controllern (Chipsatz) unterstützt sind. Die Einschränkung erfolgt aber gleich im nächsten Satz, denn dort heißt es, daß SATA-Platten nicht als lokale sondern nur als fern angeschlossene Platten eingebunden werden und das eine solche Platte daher auch nicht automatisch als Scratchpartition eingerichtet wird. Die Erläuterung zu Punkt 11 sagt nur aus, daß SATA-CD/DVDs nicht an VMs als Laufwerke durchgereicht werden können oder dazu der zum SATA-CD/DVD-Laufwerk gehörende Controllerport im pBIOS in den IDE-Legacy-Mode geschaltet werden muß.
Bei Punkt 12 gehts darum, von welchen Speichersystemen sowohl Inst als auch Boot des ESXi5.1 unterstützt werden. Dazu werden zum einen 5 SAS-Controller aufgeführt, die sowohl SAS- als auch SATA-Platten unterstützen und zum anderen 3 Chipsätze (von denen keiner in deinem MB steckt) für SATA-Platten, von denen ebenfalls der ESXi5.1-Boot unterstützt wird. Es geht hier also ausschließlich um Inst und Boot des ESXi5.1 und nicht um den Speicherort für die VMs, denn dieser wurde bereits in Punkt 10 als lokale oder Raid-LUN definiert und SATA fällt damit aufgrund dessen nichtlokaler Einbindung raus. Der Hinweis bei Punkt 12 führt als weitere Einschränkung ein, daß selbst wenn der SAS-Controller auch SATA-Laufwerke einbinden kann, dieses nicht unterstützt ist, wenn auch andere ESXi5.1-Hosts darauf Zugriff haben werden.
Punkt 13 behandelt SAS-Laufwerke, die sowohl als Boot-Medium als auch Speicherort von VMs auf VMFS-Partitionen dienen dürfen.


VMware unterscheidet also immer ganz klar in den Speicherorten für ESXi, der dann auch USB-Stick oder SD-Karte sein kann, und VMs.
Falls ich das wieder mal falsch verstanden habe, möge irix oder jemand anders das korrigieren.

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 21.07.2013, 14:13

In dem Proliant ist ein C200er Chipsatz. Der SATA-Port von diesem Chipsatz ist in der VMware Certified Compatibility Guides:

http://www.vmware.com/resources/compati ... tOrder=Asc

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 21.07.2013, 14:38

VMFS-Datastores auf SATA-Laufwerken waren erstmalig schon bei ESX 4.1 zulässig:

http://kb.vmware.com/kb/1008673

Wenn damals auch nur bis max. 10 VM's. Für ESXI 5 habe ich keine Einschränkungen diese Art mehr gefunden.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 21.07.2013, 15:45

Dein KB-Eintrag SATA Controller Support in ESX (1008673) bespricht leider das falsche Produkt, denn vSphere5 gibt es nur noch als ESXi und die HCL für deinen C200-Chipsatz bedeutet lediglich, daß dieser unterstützt wird und daran angeschlossene Laufwerke überhaupt erkannt werden. Das ändert aber nichts an den restlichen Einschränkungen bezüglich SATA hinsichtlich der VM-Ablage.

Meine Hoffnung ruht jetzt auf irix, daß er als VMware-Partner da Klarheit schaffen kann oder das jemand anders einen entsprechenden KB-Eintrag liefert.

Member
Beiträge: 84
Registriert: 17.07.2013, 15:42

Beitragvon leo » 22.07.2013, 15:17

Dayworker hat geschrieben:Dein KB-Eintrag SATA Controller Support in ESX (1008673) bespricht leider das falsche Produkt, denn vSphere5 gibt es nur noch als ESXi und die HCL für deinen C200-Chipsatz bedeutet lediglich, daß dieser unterstützt wird und daran angeschlossene Laufwerke überhaupt erkannt werden. Das ändert aber nichts an den restlichen Einschränkungen bezüglich SATA hinsichtlich der VM-Ablage.

Meine Hoffnung ruht jetzt auf irix, daß er als VMware-Partner da Klarheit schaffen kann oder das jemand anders einen entsprechenden KB-Eintrag liefert.


Ich wollte damit nur sagen, dass VMWare mit ESX 4.1 die SATA-Schnittstelle für VMFS-Datastores eingeführt hat. Ich glaube die Aussage, dass nur aktive RAID-Kontroller supported sind, stammt aus der Zeit davor und hat sich bis heute gehalten, auch weil zu Beginn die Performance zu schlecht war.

Für ESXI 5 gibt es keine entsprechende KB mehr. Die gibt es meist auch nur, wenn Probleme vorhanden sind.

Die Einschränkungen beziehen sich auf die Scratch-Partition und den Zugriff des Datastores von mehreren Hosts. Es wäre unsinnig, den Zugriff von mehreren Hosts einzuschränken, wenn VMFS generell nicht zulässig wäre.

Ich habe jetzt mit Linux (Debian 7) noch bessere Werte gemessen:

Lesen: 300 MB/s - 2500 IOPS
Schreiben: 180 MB/s - 500 IOPS
(Last mit dd, gemessen mit iostat)

Nachtrag: Debian war natürlich in einer VM


Zurück zu „Hardware“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste