7
ESXi 7.0.2 Raidkonfiguration
Guten Morgen,
eine Frage in die Runde. Wir haben einen DL385Gen10plus Server erworben. hier befinden sich 6 x 960 GB SSD Read Intensive Platten.
Es werden diverse VMs betrieben: Fileserver, DCs, Exchange, SQL.
Habe mal gehört, das die Daten vom Controller sequentiell geschrieben / gelesen werden und somit Warteschlangen das System bremsen wenn alles auf einem RAID5 Verbund wäre. Ist das so oder kann man dem entgegenwirken wenn separate Raid konfiguriert?
z.b. 4 Platten im Raid5 und 2 im Raid1?
Was macht Sinn?
Liebe sonnige Grüße
Martin
eine Frage in die Runde. Wir haben einen DL385Gen10plus Server erworben. hier befinden sich 6 x 960 GB SSD Read Intensive Platten.
Es werden diverse VMs betrieben: Fileserver, DCs, Exchange, SQL.
Habe mal gehört, das die Daten vom Controller sequentiell geschrieben / gelesen werden und somit Warteschlangen das System bremsen wenn alles auf einem RAID5 Verbund wäre. Ist das so oder kann man dem entgegenwirken wenn separate Raid konfiguriert?
z.b. 4 Platten im Raid5 und 2 im Raid1?
Was macht Sinn?
Liebe sonnige Grüße
Martin
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2138478581
Url: https://administrator.de/contentid/2138478581
Ausgedruckt am: 22.11.2024 um 18:11 Uhr
7 Kommentare
Neuester Kommentar
Hi,
Eigentlich sollte man das RAID vor dem Kauf des Servers planen und dann die entsprechenden HDDs ordern.
Meine Empfehlung: noch eine 960 GB SSD ordern (HOTspare, wenn kein Platz mehr vorhanden : COLDspare) und aus den existierenden 6 HDDS ein RAID 10 erstellen.
CH
Was macht Sinn?
Meiner Meinung nach: nichts so richtig.Eigentlich sollte man das RAID vor dem Kauf des Servers planen und dann die entsprechenden HDDs ordern.
Meine Empfehlung: noch eine 960 GB SSD ordern (HOTspare, wenn kein Platz mehr vorhanden : COLDspare) und aus den existierenden 6 HDDS ein RAID 10 erstellen.
CH
Moin,
schließe mich an, darüber macht man Gedanken, bevor man den Server kauft.
RAID10 ist wohl am besten, aber reicht euch dann der Speicherplatz noch?
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
VG
schließe mich an, darüber macht man Gedanken, bevor man den Server kauft.
RAID10 ist wohl am besten, aber reicht euch dann der Speicherplatz noch?
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
VG
Zitat von @chgorges:
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Hallo chgorgesDazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Moin,
mach aus den Platten ein Raid6. Vielleicht der beste Kompromiss aus Leistung und Ausfallsicherheit.
Gruß
Looser
mach aus den Platten ein Raid6. Vielleicht der beste Kompromiss aus Leistung und Ausfallsicherheit.
Gruß
Looser
Zitat von @Toby-ch:
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Zitat von @chgorges:
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Hallo chgorgesDazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Nein, aber es gibt Read-Intensive und Write-Intensive Enterprise-SSDs.
Das macht den Unterschied
1
Zitat von @Nils02:
Nein, aber es gibt Read-Intensive und Write-Intensive Enterprise-SSDs.
Das macht den Unterschied
Moin,Zitat von @Toby-ch:
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Zitat von @chgorges:
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Hallo chgorgesDazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Nein, aber es gibt Read-Intensive und Write-Intensive Enterprise-SSDs.
Das macht den Unterschied
Oder dem entsprechend Mixed-Use Platten.
Ich würde wenn kein Budget mehr da ist auf ein RAID 6 gehen oder ein RAID 5 + Global Hotspare.
Grüße
Niklas
Zitat von @Nils02:
Nein, aber es gibt Read-Intensive und Write-Intensive Enterprise-SSDs.
Das macht den Unterschied
Zitat von @Toby-ch:
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Zitat von @chgorges:
Dazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Hallo chgorgesDazu Read-Intensive SSDs bei nem SQL? Schmeißt bitte den raus, der Server geplant hat.
Ihr wisst, dass wenn die SSDs innerhalb der Garantie sterben und HPE sieht, dass da zu viele Schreibzugriffe drauf waren, ihr keinen Garantieanspruch mehr habt?
Somit sind SSD nicht für Datenbanken geeignet, auf Grund der schreib und Lese Zyklen ?
Aber auf Grund der Geschwindigkeit gerade perfekt!?
Nein, aber es gibt Read-Intensive und Write-Intensive Enterprise-SSDs.
Das macht den Unterschied
Aye....und gerade Exchange und DB Server hauen da schon einiges.
Die SSDs wären perfekt für Sachen wo sich nichts ändert, also alte DBs aus denen nur noch gelesen wird.
DC ist meist nicht so tragisch, aber Exchange ändert sich ständig etwas.
Von der Konfiguration her würde ich sagen das sich jemand im ersten Moment dachte " boah geil, SSD, schnell"...
IMHO sind Read Intensive SSDs ein Schmuh...ist nicht so das die SSD gross leidet wenn sie abgefragt wird (im Gegensatz zu einer HDD).
Nachdem es sich hier eher um ein kleineres Netz zu handeln scheint und der Gedanke an Bottlenecks kommt, würde ich den eher wo anders suchen....
Haben die VMs genügend RAM um überhaupt alles aufs RAID zu bekommen ?
Welcher Hypervisor ?
