Jump to content

Hyper-V / Sizing / Verständnisfragen


Blase
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Guten Morgen allerseits,

 

es "heißt" ja immer, dass in aktuellen Konstellationen (v)CPUs "ohne Ende" vorhanden sind und am ehesten der (zugewiesene) Arbeitsspeicher limitiert - sprich: viel hilft viel. Aber was ist mit der I/O Performance - spielt das Festplattensystem hier gar keine (wirkliche) Rolle?

 

Um mit "Zahlen" zu arbeiten - gegeben ist ein physikalischer Server 2008 R2 mit einem RAID1 für das BS und einem SAS RAID10 für die VHDs - alles intern im Server. Der Server verfügt über 2 Cores á 6 Kernen mit HT, also 24 Kerne, und 36 GB RAM.

 

Hierauf laufen 5 virtuelle Maschinen.

 

- Ein Exchange mit der Zuweisung von 4 vCPUs und 8 GB RAM

- Ein SQL Server mit der Zuteilung von 4 vCPUs und 12 GB RAM

- Ein Terminal Server mit der Zuteilung von 4 vCPUs und 6 GB RAM

- Ein CRM Server mit der Zuteilung von 4 vCPUs und 6 GB RAM

- Ein "Archiv Server" mit der Zuteilung von 1 vCPU und 2 GB RAM

 

Dazu muss man noch sagen, dass insgesamt keine 15 Mitarbeiter damit arbeiten. Wenn auf dem TS beispielsweise mal 6 Leute gleichzeitig arbeiten, wäre das viel. Dennoch ist das ganze System gefühlt sehr träge. Der Start der Applikationen auf dem TS dauert z.B. sehr lange.

 

Bei den (v)CPUs kommen wir hier nicht einmal auf ein 1:1 Verhältnis - "verbrauchen" 17 der 24 Kerne

Beim RAM sind 34 GB der vorhandenen 36 GB für die virtuellen Maschinen reserviert.

 

Nun zu meinen Fragen in diesem Kontext:

 

1. "Reichen" die 2 "freien" GByte RAM für das Hostsystem? Ich meine von 2-4 GByte als empfohlene Menge gelesen zu haben.

 

2. Ich meine zu wissen, dass die Zuweisung von ZU VIELEN vCPUs zu einer VM nicht sinnvoll ist, weil diese Ihre Arbeit erst aufnehmen können, wenn das Hostsystem gleichzeitig alle zugewiesenen freischaufeln kann. Ich habe aber hier nicht einmal eine 1:1 Zuweisung. Kann in diesem konkreten Fall doch also gar nicht passieren, oder? Es heißt ja immer, man solle nicht mehr vCPUs zuweisen, als man es "normalerweise" einer physikalischen Maschine tun würde. Nun, wenn ich heute selbst einen kleinen Server kaufe, der meinetwegen "nur" den DC macht, hat dieser trotzdem mindestens 8 Kerne (4 + HT). Wo setzt ihr an? Wie viele Kerne "braucht" denn eine VM wirklich? Ein SQL Server? Ein Terminal Server? Ein Exchange? Bringt mir der Taskmanager der einzelnen VMs hier sinnvolle Informationen? Sprich - wenn die CPU Auslastung insgesamt nicht zu hoch ist, reichen die zugewiesenen vCPUs? Und wenn doch, weise ich weitere zu? Gilt das "nicht zu viele vCPUs zuweisen!" auch für Systeme, die nicht mal auf eine 1:1 Verteilung kommen? Oder nur für diese, wo sonst abzusehen ist, dass wirklich aufgrund von "Überbelegung" oft nicht die gewünschte Anzahl an vCPUs zur Verfügung steht?

 

3. Und eine Sache, die mich in diesem Kontext wirklich interessiert - ab wann wird das Festplattensystem denn zum limitierenden Faktor? Wie im konkreten Beispiel habe ich innerhalb eines lokalen RAID5 @SAS Systems 5 virtuelle Maschinen, die ja einiges an Last erzeugen. Wie sind die Erfahrungswerte? Sollte kein Problem sein?

 

Hintergrund ist wie gesagt, dass das System "gefühlt" recht träge ist. Zugegeben, der Arbeitsspeicher steht jetzt nicht im Überfluss zur Verfügung, aber schaue ich in den jeweiligen Taksmanager ist dort noch "jede Menge" diesbezüglich frei. Tatsächlich sind es ja auch nur eine Handvoll Benutzer, die hier arbeiten.

 

Über die Beantwortung meiner Fragen - aber auch über jede andere Anmerkung in diesem Kontext - würde ich mich freuen.

 

Gruß

Björn

bearbeitet von Blase
Link zu diesem Kommentar

Hintergrund ist wie gesagt, dass das System "gefühlt" recht träge ist. Zugegeben, der Arbeitsspeicher steht jetzt nicht im Überfluss zur Verfügung, aber schaue ich in den jeweiligen Taksmanager ist dort noch "jede Menge" diesbezüglich frei. Tatsächlich sind es ja auch nur eine Handvoll Benutzer, die hier arbeiten.

Sorry, aber das ist eine wirklich fundierte Aussage :D.

Wie wäre es mal mit einer Prüfung der Ressourcen des VM-Hosts!? z.B. per Windows perfmon? Es gibt auch eine Testversion von Veeam ONE mit der man den Hosts mal auf den Zahn fühlen kann.

Auf den blauen Dunst hin würde ich mal darauf tippen, dass das Storageperformance für die VM's der Engpass ist. Wie viele Platten laufen hat denn das RAID-5 für die VM's? was für Platten sind verbaut!? Was für ein Controller ist verbaut? WB-Cache?

bearbeitet von monstermania
Link zu diesem Kommentar

Moin,

 

grundsätzlich stimme ich monstermania zu - die Beschreibung ist nicht sonderlich fundiert.

 

In deinem System sehe ich mehrere mögliche Bremsen:

  • Jede aktuelle Exchange-Version ist mit 8 GB unterdimensioniert, auch für kleine Umgebungen.
  • Von 36 GB physischem RAM 34 an die VMs zu verteilen, ist bei den gegebenen Applikationen und dem Systemaufbau zu eng. Mit nur 2 GB verbleibendem Speicher wird der Host da immer an seine Grenzen kommen.
  • Natürlich ist ein RAID5 für die VMs alles andere als "schnell".
  • Die vCPUs dürften in dem Szenario eher egal sein, wobei ein Verhältnis von 4 vCPU zu 6 GB RAM bei einem Terminalserver mir nicht besonders ideal erscheint - da wird schon das RAM die Limitierung sein.

All das ist jetzt aber ebenso aus dem Bauch wie deine bisherigen Angaben.

 

Gruß, Nils

Link zu diesem Kommentar

Hallo ihr beiden.

 

Schon einmal vielen Dank für die Antworten. Mir ist bewusst, dass "gefühlte" Werte hier überaus schwammig sind und ich noch etwas mit Informationen gegeizt habe.

 

Letzteres möchte ich hier nun nachholen:

 

- Der Server ist ein HP ProLiant DL380G7

- Festplatten sind jeweils "EG0300FBDSP HP 300GB 2.5" SFF 6G Dual Port SAS 10K RPM Hot Plug Hard Drive"

- Smart Array P410i Controller

- und KEIN RAID5 (mein Fehler!) sondern ein RAID10 - bestehend aus 4 dieser Platten zzgl. Hotspare.

- Das Betriebssystem des Hosts selbst läuft wie geschrieben auf einem RAID1 mit zwei dieser Platten: EH0146FARUB HP 146-GB 6G 15K 2.5 DP SAS HDD

 

Und was die "gefühlten" Werte angeht - beispielsweise benötigt der Start einer ERP Software auf dem TS über doppelt so lange (über 1 Minute) als es beispielsweise als Einplatzlösung auf einem (oberem Mittelklasse) Notebook dauert. Überhaupt ist das Arbeiten auf dem TS oftmals recht träge...

 

@Monstermania - Die Storageperformance habe ich auch im Verdacht diesbezüglich. Aber ich kenne diese Tools nicht. Perfmon ist ja Windows Standard. Aber das Tool scheint sehr mächtig zu sein. Muss ich mich noch mal genauer mit beschäftigen.

 

@Nils - Wir schauen grade in zwei Richtungen. Entweder Erweiterung des aktuellen Server (dann natürlich mit deutlich mehr RAM) oder aber einen zweiten daneben Stellen und ein, zwei der vorhandenen Maschinen auf das andere Hostsystem auslagern. Grundsätzlich würde ich aber gerne wissen, was in dieser konkreten Konstellation tatsächlich der primäre Flaschenhals ist. Mir ist bewusst, dass der RAM eher "Unterkannte" statt "Obergrenze" ist, aber würde eine Erweiterung hier wirklich "spürbar" mehr Leistung bringen?

 

Ich habe halt die Empfehlung aufgeschnappt, dass das Hostsystem 2-4 GB RAM für sich haben sollte. Ist diese Aussage allgemeingültig? Oder ist es eher "2 GB reichen für den Umgang mit ein, zwei kleinen VMs und für mehrere "große" VMs dann eher 4+ GByte für das Hostsystem?

 

Was den RAID Level angeht, so habe ich mich vertan. Es war kein RAID5 sondern ein RAID10. Was sind denn die performantesten RAID Level in Kombination mit Virtualisierung? Kann man hier pauschale Aussagen treffen? Oder kommt es auch hier darauf an, welchen Zweck (TS, SQL, Exchange,...) die VMs da drauf erfüllen? EDIT: Was hältst du von SSD@RAID im Serverbereich?

 

Du bringst ein Verhältnis von vCPU zu RAM ins Spiel. So habe ich es bisher nicht betrachtet. Spielt das Verhältnis hier eine Rolle? Das aktuelle Szenario ist wohl eher aus der Not heraus geboren. vCPUs waren genügend da und 4 scheinen für einen TS dieser Größenordnung "gut" bemessen zu sein. Dass es daneben nur 6 GB RAM sind, ist wahrscheinlich einfach dem Umstand geschuldet, dass man damit auf dem Hostsystem bisher sehr haushalten musste. Deswegen hat auch der Exchange nur 8 GB oder generell halt alle Maschinen eher an der Untergrenze diesbezüglich...

 

... aber ist es der RAM, der hier "bremst" - hauptsächlich? So aus Erfahrungswerten - wie viele VMs bringt man denn auf einer Hardware unter? In Bezug auf EINEM Festplatten/RAID System? Kommt wahrscheinlich auch hier wie immer darauf an... ;-)

 

Gruß

Björn

bearbeitet von Blase
Link zu diesem Kommentar

Moin,

 

es gibt keine "one size fits all"-Empfehlungen für die Virtualisierung. Ohne tatsächlich die genauen Anforderungen (technisch und organisatorisch) zu betrachten, wird man nicht weit kommen.

 

In deinem System gehe ich davon aus, dass vor allem zu wenig RAM da ist. Dass alles toll fliegt, wenn du mehr RAM reintust, kann man natürlich nicht versprechen - dafür gibt es zu viele andere Faktoren, an denen es scheitern kann. Die "2-4 GB" für den Host sind in der Tat eine Daumenregel - aber wenn du dir vor Augen hältst, was der Host tun muss, wirst du schnell nachvollziehen können, dass deine VMs unter Umständen schon einiges an I/O erzeugen, was der Host alles koordinieren muss.

 

Zum Platten-I/O kann man ohne Messungen des realen Bedarfs wirklich nichts Sinnvolles sagen. Natürlich sind SSDs schnell, aber ob Kosten und Nutzen in einem sinnvollen Verhältnis stehen, kann man aus der Ferne nicht beurteilen. Bedenke nur Folgendes: Du hast mehrere Applikationen, die zumindest potenziell viel I/O erzeugen. Das muss alles in seiner Summe von dem einen lokalen Plattensystem geliefert werden.

 

2008 R2 ist veraltet, und eine Umgebung der genannten Art steht sicher unter einigen Leistungs- und Verfügbarkeitsanforderungen. Daher wäre es da schon sinnvoll, das etwas professioneller anzugehen.

 

Gruß, Nils

PS. Der Host hat nicht 24 Kerne, sondern 12. Hyperthreading kann in der Virtualisierung zwar nützlich sein, aber es ist nicht gleichwertig mit Cores. (Auch wenn in deiner Situation die CPUs sicher nicht den Engpass darstellen.)

bearbeitet von NilsK
Link zu diesem Kommentar

... aber ist es der RAM, der hier "bremst" - hauptsächlich? So aus Erfahrungswerten - wie viele VMs bringt man denn auf einer Hardware unter? In Bezug auf EINEM Festplatten/RAID System? Kommt wahrscheinlich auch hier wie immer darauf an... ;-)

Hallo Björn,

der Aussage "Kommt wahrscheinlich auch hier wie immer darauf an..." ist nichts hinzuzufügen. :D

Eine verbindliche Aussage kann man so nicht treffen, da es extrem auf die Last ankommt, die auf den Maschinen liegt. Da hilft die Aussage bezüglich der Anzahl de Benutzer auch nur bedingt weiter. Es gibt Firmen da verursachen 5 power User genausoviel Last wie 50 normale User anderswo!

Da hilft nur nachmessen. Schau Dir mal Veeam ONE an. Gibt eine Free und Testversion von Veeam ONE. Damit kannst Du recht zuverlässig erkennen wo es auf den Host hakt. Ich bin immer noch der Meinung, dass das Hauptproblem in der Plattenperformance zu suchen ist. 4 SAS-Platten in einem RAID10-Verbund bringen nicht soviel an IOPS. Gerade wenn Exchange und SQL gleichzeitig belastet werden wird es da schnell eng mit der Performance. 

SSD sind natürlich toll, kosten aber auch richtig Geld wenn es sich denn um Enterprise-Platten handelt. Und vom Einsatz von Consumer-Platten halte ich überhaupt nichts!

 

Wir groß sind die Datenbanken auf dem SQL? 12 GB RAM für den SQL macht ja nur Sinn, wenn da auch ein paar entsprechende Datenbanken drauf sind.

Wenn da nur 1 oder 2 Datenbanken von ~ 1 GB drauf laufen würden auch 8 GB für den SQL locker ausreichen.

 

Gruß

Dirk

bearbeitet von monstermania
Link zu diesem Kommentar

Hat der P410i 256MB oder 512MB Cache und eine BBU ?

Stimmt natürlich. Aber davon bin ich jetzt einfach mal ausgegangen, dass der P410 über Cache und BBU verfügt.

Wichtig ist, dass der Cache auch in der Controllerkonfiguration aktiviert ist. Ich meine mich zu erinnern, dass ich den Cache auf unserem Backupserver mit Windows 2012R2 (HP P400 Controller) zunächst deaktiviert war und erst über den HP Smart Storage Administrator aktiviert werden musste!

Link zu diesem Kommentar

Habt vielen Dank für die rege Beteiligung bisher!

 

@Nils - Ich weiß ja, dass es nie in diesem Kontext allgemeingültige Aussagen gibt... aber "messen" kannst du ja auch eher weniger, wenn ein komplett neues System an steht und du es für die "geplanten" Bedürfnisse ausrichten sollst. Welches RAID System wird denn für welche Anforderungen empfohlen? Gibt es hier seitens MS eine Übersicht. So nach dem Motto "bei SQL Servern ist das am performantesten, bei TS eher das,...". Wir bewegen uns hier eher im KMU Bereich, die Lasten auf den Systemen also i.d.R. eher überschaubar(er).

Du bringst eine für mich neue Information ins Spiel... wenn ich CPU Kerne "zähle", dann rechne ich die HT-Kerne raus? Wenn wir von den Verhältnissen reden (1:4 / 1:8), dann zählen nur die realen Kerne, nicht die HT Kerne?

 

@monstermania - Ich bin wirklich an der Information interessiert, wie man das Festplattensystem des Host am sinnvollsten in bestimmten Konfigurationen ausrichtet. Du sprichst die IOPS an - gibt es hie Empfehlungen, welches RAID Level und welche Festplattenkonfiguration man wann nutzen sollte? Auf dem SQL Server laufen aktuell 15 Datenbanken, wobei hier drei im Bereich von 2.x GByte und der Rest unter 1 GByte an Größe haben.

Und wo du die Controller Konfiguration ansprichst... Ist das der "Schreib-Cache für physische Laufwerke"? Ich schaue grade mit dem HP Array Configuration Utility auf den Controller. Dieser ist bisher deaktiviert. Wäre doch der Brüller, wenn es "ein Klick" wäre und auf einmal läuft das System schnell :jau:  Kann ich das jetzt - im laufenden Betrieb - einfach aktivieren? Muss ich hierbei etwas beachten?

 

@ Dominik Weber - ich habe noch keine Möglichkeit gehabt, die Kiste mal neu zu starten und ins Bios zu schauen. Der Controller hat 256 MByte Cache. Mir sagt allerdings BBU nichts...

 

Gruß

Björn

Link zu diesem Kommentar

Moin,

 

mit der Frage nach dem Storage-Sizing stellst du eine der Kernfragen des Hardware-Designs überhaupt. Und wenn du dich auf den Kopf stellst: Nein, es gibt keine (sinnvollen) Empfehlungen dieser Art. Es gibt für manche Zwecke Kalkulations- bzw- Schätzungshilfen (z.B. für Exchange). Wenn es drauf ankommt, geht aber an Messungen kein Weg vorbei.

 

Ein letztes Mal noch dazu: Halte dir vor Augen, dass dein RAID-10 mit 4 Platten nur zwei Spindeln zur Verfügung hat. Du addierst also plump gesagt die IOPS zweier Platten, und das ist dann die Leistung deines Storage-Subsystems. Besonders viel wird da einfach nicht rumkommen.

 

Und auch das ein letztes Mal: Die CPUs sind nicht dein Problem (sind sie so gut wie nie in der Virtualisierung). Das Verhältnis von vCPU zu LP ist ein rein rechnerisches, das sich nur in der Gesamtschau ergibt. Abgesehen von einzelnen Supportfragen gibt es auch da kein pauschal günstiges oder ungünstiges Verhältnis.

Es gibt auch keine "HT-Kerne". Es gibt Cores. Und es gibt Logische Prozessoren. Letztere sind recht komplex definiert. Dazu gibt es dann noch die Threads.

Das ist in der Tiefe beim Sizing aber, wie gesagt, fast nie von Belang. Für das rechnerische Verhältnis nimmt man aber meist vereinfachend die Cores als Basis, nicht die Threads.

 

Dein Host hat zu wenig RAM und sehr wahrscheinlich zu wenigf Storage-IO-Leistung. Und er läuft mit einem veralteten System. Und das Design ist zumindest fragwürdig.

 

Damit sind wir auf dieser Ebene erst mal durch. Alles Weitere geht in den Bereich von Design und Consulting, was in einem Forum nicht zu leisten ist.

 

Gruß, Nils

Link zu diesem Kommentar

@Blase

BBU = Backupbatterieeinheit

Die Daten werden vom Controller ja zunächst im Cache gespeichert. Das OS hat aber bereits einen Commit erhalten, dass die Daten geschrieben sind. Würde es jetzt ohne BBU einen kompletten Stromausfall am Server geben, so wären die Daten aus dem Cache des RAID-Controllers verloren. Das würde unweigerlich zu Datenverlusten/Korrupten Daten führen.

Ob der Controller eine BBU hat wird auch im HP Smart Storage Administrator angezeigt. Dort kannst Du Dir auch den Status der BBU anzeigen lassen. Im Falle einer schwachen BBU wird normalerweise der Cache deaktiviert (aus Sicherheitsgründen). Das sollte man auch so aktiviert lassen, sofern man nicht über eine 100%ig sichere Absicherung der Stromversorgung des Servers hat!

Ja, den physischen Cache kannst Du aktivieren. Allerdings sollte dann sichergestellt sein, dass der Server über eine USV abgesichert ist (Was jeder Server sowieso sein sollte)!

 

IOPS / RAID

Grundsätzlich hat ein RAID-Level direkt nichts mit den IOPS eines Storages zu tun! RAID dient zur Absicherung durch Datenverlust der durch einen Ausfall einzelner Festplatten verursacht werden kann. Die IOPS werden maßgeblich von der Festplattentechnologie (SATA, NL-SAS, SAS, SSD) und der Anzahl der im Verbund laufenden Platten bestimmt. 

Es mag natürlich sein das ein RAID10 aus 4 Platten eine höhere Performance als ein RAID5 (aus gleichen Festplatten). Aber Du hast eben auch 50% Datenverlust. Kosten/Nutenfaktor nicht gerade optimal.

In mittleren Storagesystemen, wenn ein RAID5/6-Verbund mit z.B. 10 oder mehr Platten genutzt wird spielen dann andere Faktoren bei der Auswahl eines bestimmten RAID-Level eine Rolle. Oftmals setzten Kunden auch auf unterschiedliche Festplattentechnologien und RAID-Verbünde in einem Storagesystem um unterschiedlichste Ansprüche abbilden zu können (z.B. SSD Cache, NL-SAS/SATA für Archivdaten, usw.). Das führt jetzt aber viel zu weit und gehört wie Nils schon richtig bemerkte nicht mehr hier in einen Forenfred.

 

Grundsätzlich scheint Euer Server ein Performanceproblem zu haben. Und daher hilft nur ein Monitoring des Systems um zu analysieren in welchem Bereich genau das Problem/Probleme liegen. Ein Tool (Veeam ONE) dafür habe ich genannt. Nach einer Analyse kann man dann überlegen wie man dem System auf die Sprünge helfen kann. 

Link zu diesem Kommentar

Guten Morgen!

 

@ Nils - du "klingst" etwas angenervt von mir - das war nicht meine Absicht - bitte entschuldige. Vielleicht hatte ich einfach gehofft, du/ihr erzählt einfach ein wenig aus dem Nähkästchen - Erfahrungswerte. Es ist doch klar, dass das nicht 1:1 für bare Münze genommen werden kann und auf alle Szenarien abbildbar ist. Wie geschrieben - hier in meinem KMU Bereich bewege ich mich ganz sicher in komplett anderen Bereichen als ihr es gewohnt seid. Und ich war mit meiner letzten Fragengestellung auch gar nicht mal mehr so wirklich bei meinem aktuellen Problem (was sich übrigens erledigt hat - siehe unten), sondern eher allgemein daran interessiert, mein "gefährliches Halbwissen" zu reduzieren. Mit deiner Aussage...

 

Für das rechnerische Verhältnis nimmt man aber meist vereinfachend die Cores als Basis, nicht die Threads.

... hast du mir meine Frage diesbezüglich beantwortet. Ich danke dir für deine Unterstützung - und bitte nicht die Geduld mit mir verlieren, ich weiß aus anderen Bereichen, wie "schwierig" (um nicht zu sagen "total nervig") Leute mit gefährlichem Halbwissen manchmal sein können ;-)

 

@monstermania - bei dir möchte ich mich quasi gleich doppelt bedanken. Zum Einen, weil du mit deiner Aussage bezüglich Aktivierung des Cache wohl tatsächlich ins Schwarze getroffen hast - und zum Anderen wegen deiner ausführlichen Erklärung - danke!

So wie es aussieht, war die Aktivierung des Schreib Cache wohl tatsächlich die Bremse - mit so einer "einfachen" Lösung hätte ich nun nicht gerechnet. Aber soll mir/uns hier natürlich Recht sein. Und im Standard deaktiviert HP das, eben aufgrund der von dir genannten Nachteile bei nicht vorhandener (oder "leerer") BBU?! Hmmm, na gut. Tatsächlich scheint der Controller keine BBU zu haben - sehr wohl aber ein redundantes Netzteil, welches an einer USV hängt. Diese fährt den Server herunter, bei längerem Stromausfall - sollte dann wohl reichen...

 

Also vielen Dank für alle Anregungen und Meinungen hier - ich bin immer daran interessiert, meinen noch recht eingeschränkten Horizont stetig zu erweitern. Ohne dieses Thema hier wäre ich wohl nie auf die Lösung gekommen. Das ERP Programm startet auf dem Terminal Server nun genau so schnell wie auf einem Einplatzgerät - das hätte ich so nicht gedacht. Von über 1 Minute auf ca. 20 Sekunden - wenn das mal keine Steigerung ist :thumb1:

Auch das Ansprechverhalten innerhalb und außerhalb der Software ist auf dem TS und den anderen Maschinen nun deutlich schneller - "gefühlte" Werte, ich weiß... ;) Der Server hat noch einige Steckplätze bezüglich RAM frei - da es den für kleines Geld zu kaufen gibt, wird jetzt zusätzlich von 36 auf 64 GByte RAM erweitert.

 

Vielen Dank an alle - mein aktuelles Problem ist behoben und ich habe einiges dazu gelernt - so soll es sein!

 

Gruß

Björn

Link zu diesem Kommentar

So wie es aussieht, war die Aktivierung des Schreib Cache wohl tatsächlich die Bremse - mit so einer "einfachen" Lösung hätte ich nun nicht gerechnet. Aber soll mir/uns hier natürlich Recht sein. Und im Standard deaktiviert HP das, eben aufgrund der von dir genannten Nachteile bei nicht vorhandener (oder "leerer") BBU?! Hmmm, na gut. Tatsächlich scheint der Controller keine BBU zu haben - sehr wohl aber ein redundantes Netzteil, welches an einer USV hängt. Diese fährt den Server herunter, bei längerem Stromausfall - sollte dann wohl reichen...

 

Du willst eine BBU für deinen Raidcontroller kaufen.

Diese sollte keine 100€ kosten und dir dafür einiges ersparen.

 

Wir hatten vor einiger Zeit auch ein Problem bei einer EMC Storage. Diese hat bei einem Ausfall einer Komponente den Write Cache deaktiviert und dadurch ist die Shcreibrate von 50MB/s auf 5MB/s eingebrochen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...