mailserver migration sehr unterschiedliche Performance

[Colttt]

Hallo,

wir sind dabei von cyrus zu dovecot zu migrieren, wir testen das vorher mehrere male in unserer Testumgebung, da alles virtualisiert ist (mittels Vmware) ist das auch recht einfach.
Für die Migration nutzen wir cyrus2dovecot und das ganze nach dieser Anleitung. Was auch klappt nur haben wir extrem abweichende Unterschiede was die dauer anbelangt, obwohl wir jedes mal alles gleich machen. Das erste mal hat das ganze 19h gedauert, das zweite mal 30h, 3. 16h und 4. &5 mal ca 28h. Kann mir jmd erklären warum das so ist?
Wie kann ich das genauer analysieren was der Flaschenhals ist? hierzu noch ein paar Daten:
NFS mount options:

Code: Alles auswählen

type nfs4 (ro,noatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys

local mount options:

Code: Alles auswählen

/dev/mapper/data-var on /var type ext4 (rw,noatime,data=ordered)

die platten sind auf den noop-scheduler eingestellt, die readahead-Werte wurden geändert

Code: Alles auswählen

blockdev --setra 8192

in vmware ist schon die Netzwerkkarte auf vmxnet3 umgestellt/eingerichtet und als SCSI-Controller wurde auch Paravirtual genommen. die mtu wurde in Linux auf 9000 gesetzt.
die beiden VMs sind auf dem selben host aber auf unterschiedlichen Storages (Dell Equallogic).

Wie kann ich genau den flaschenhals ausfindig machen (iowait liegt bei dem ganzen vorgang so bei 20-35), wobei ich hier kaum glaube dass das Storage an die grenzen kommt.

EDIT:
lasse es grade nochmal laufen.. wenn man das jetzt so hin und her rechnet komme wir auf ca 18MB/s was mehr als schwach ist meiner Meinung nach

[rendegast]

... 19h gedauert, das zweite mal 30h, 3. 16h und 4. &5 mal ca 28h.

... wenn man das jetzt so hin und her rechnet komme wir auf ca 18MB/s

Und Beobachtung? iftop / iotop
Gibt es vielleicht Einbrüche, zBsp. gar keine Übertragung mehr,
was auf locking-Sperren o.ä. deuten könnte.



Testweise
statt NFS,
ein snapshot der cyrus-Maschine, als weitere Platte in der dovecot-Maschine gemountet?

[Colttt]

Code: Alles auswählen

Und Beobachtung? iftop / iotop
Gibt es vielleicht Einbrüche, zBsp. gar keine Übertragung mehr,
was auf locking-Sperren o.ä. deuten könnte.

hmm ich guck da jetzt nicht die ganze zeit drauf um das irgendwie deuetn zu können, aber jedes mal wenn ich geguckt habe ist etwas passiert..

ein snapshot der cyrus-Maschine, als weitere Platte in der dovecot-Maschine gemountet?

ohh man stimmt, das sollte ja ohne probleme möglich sein nur die ganzen vdisks dort einbinden (sind glaube 5stück via lvm zusammengefrickelt) und dann das lvm mounten und anschliessend nur den ordner mounten oder besser noch nen link zu dem ordner setzen.. das werde ich heute noch testen danke dafür!

EDIT: hmm die platten vom anderen server einen extra controller spendieren oder alles über einen gehen lassen?

[rendegast]

EDIT: hmm die platten vom anderen server einen extra controller spendieren oder alles über einen gehen lassen?

IN der VM?
Halte ich für Jacke wie Hose, resp. es sollte Jacke wie Hose sein.
Vielleicht "ja" der Übersicht halber in einem grafischen Konfigurator.

[Colttt]

soo hängen jetzt an verschiednen controllern.. aber die performance ist irgendwie immer noch unter aller sau..

iostat -x 1 3
Linux 3.16.0-ucs135-amd64 (umail2) 08/31/2016 _x86_64_ (4 CPU)

Code: Alles auswählen

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.52    0.00    0.41   22.35    0.00   75.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.12     0.17    1.37    0.13    27.82     1.35    38.67     0.01    7.42    7.54    6.19   3.38   0.51
sdb               0.01    37.34    1.75   53.62    46.30  3584.21   131.13     1.50   27.06   10.72   27.59   0.63   3.49
sdd               2.95     0.00  208.26    0.00  2968.18     0.00    28.50     3.29   15.82   15.82    0.00   3.93  81.78
sdf               0.02     0.00    0.04    0.00     0.13     0.00     6.56     0.00    1.32    1.32    0.00   1.32   0.01
sde               0.25     0.00    8.33    0.00   427.16     0.00   102.55     0.16   18.98   18.98    0.00   5.94   4.95
sdc               0.49     0.00    4.74    0.00   137.51     0.00    57.98     0.08   16.40   16.40    0.00   6.59   3.12
sdg               0.10     0.00    6.00    0.00    86.42     0.00    28.80     0.09   15.59   15.59    0.00   4.46   2.67
scd0              0.00     0.00    0.00    0.00     0.01     0.00     8.00     0.00    5.09    5.09    0.00   5.09   0.00
dm-0              0.00     0.00  230.50    0.00  3618.60     0.00    31.40     3.66   15.87   15.87    0.00   3.99  91.86
dm-1              0.00     0.00    1.72   90.96    46.15  3584.21    78.35     2.08   22.40   11.00   22.62   0.38   3.48

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.51    0.00    0.25   22.86    0.00   75.38

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdd               3.00     0.00  248.00    0.00  1964.00     0.00    15.84     3.22   14.53   14.53    0.00   3.31  82.00
sdf               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sde               0.00     0.00    1.00    0.00     8.00     0.00    16.00     0.01    8.00    8.00    0.00   8.00   0.80
sdc               1.00     0.00   96.00    0.00  2152.00     0.00    44.83     1.07   11.17   11.17    0.00   1.25  12.00
sdg               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00  334.00    0.00  3904.00     0.00    23.38     4.32   13.96   13.96    0.00   2.84  94.80
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.50    0.00    0.25   24.12    0.00   75.13

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.00    1.00  288.00     4.00  1480.00    10.27     3.16   10.93   24.00   10.89   0.17   4.80
sdd               6.00     0.00  132.00    0.00   872.00     0.00    13.21     1.81   13.88   13.88    0.00   6.45  85.20
sdf               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sde               0.00     0.00    3.00    0.00    60.00     0.00    40.00     0.02    5.33    5.33    0.00   5.33   1.60
sdc               0.00     0.00    5.00    0.00    68.00     0.00    27.20     0.08   16.00   16.00    0.00  14.40   7.20
sdg               0.00     0.00    5.00    0.00    44.00     0.00    17.60     0.05   10.40   10.40    0.00   7.20   3.60
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-0              0.00     0.00  147.00    0.00  1016.00     0.00    13.82     2.01   13.82   13.82    0.00   6.67  98.00
dm-1              0.00     0.00    1.00  288.00     4.00  1480.00    10.27     3.18   10.99   24.00   10.94   0.17   4.80

das ganze scheint irgendwie noch langsamer zu sein als via nfs..
das ganze von den "alten" platten zu lesen scheint hier der ffaschenhals zu sein

[rendegast]

3MB/s ist ja unterirdisch.
(vielleicht überträgt das Skript aber auch jede kleine Mail separat+sync,
sodaß bei zehntausenden von Mail der Lesekopf nur mehr am fliegen ist)

Der generelle Zugriff ist aber oK?

Code: Alles auswählen

hdparm -tT /dev/sda
hdparm -tT /dev/sdb
hdparm -tT /dev/sdd
hdparm -tT /dev/sdf
hdparm -tT /dev/sde
hdparm -tT /dev/sdc
hdparm -tT /dev/sdg

hdparm -tT /dev/dm-0
hdparm -tT /dev/dm-1

resp. was wird beim stumpfen Kopieren irgendwelcher Daten erreicht?

Sind die benutzten Images vielleicht massiv fragmentiert?
Das passiert zBsp. gerne mal bei qcow2-Images.
Tool 'filefrag ...'

[Colttt]

So der generelle speed ist ok, zwar nicht super schnell aber besser als das was man beim kopieren erreicht.

Code: Alles auswählen

hdparm -tT /dev/sda; hdparm -tT /dev/sdc; hdparm -tT /dev/sde; hdparm -tT /dev/sdg; hdparm -tT /dev/dm-0 

/dev/sda:
 Timing cached reads:   13810 MB in  2.00 seconds = 6909.90 MB/sec
 Timing buffered disk reads: 248 MB in  3.00 seconds =  82.55 MB/sec

/dev/sdc:
 Timing cached reads:   13542 MB in  2.00 seconds = 6775.16 MB/sec
 Timing buffered disk reads: 208 MB in  3.03 seconds =  68.63 MB/sec

/dev/sde:
 Timing cached reads:   13120 MB in  2.00 seconds = 6564.39 MB/sec
 Timing buffered disk reads: 164 MB in  3.03 seconds =  54.19 MB/sec

/dev/sdg:
 Timing cached reads:   14108 MB in  2.00 seconds = 7058.91 MB/sec
 Timing buffered disk reads: 246 MB in  3.03 seconds =  81.19 MB/sec

/dev/dm-0:
 Timing cached reads:   14016 MB in  2.00 seconds = 7012.35 MB/sec
 Timing buffered disk reads: 166 MB in  3.01 seconds =  55.19 MB/sec

Das Tool filefrag kenn ich nicht; ich habe es einfach mal auf mein Mailordner ausgeführt, die Ausgabe verstehe ich nur leider nicht

Code: Alles auswählen

filefrag -v /mnt/var/spool/cyrus/mail/domain/m/meine.domain.de/c/user/colttt/
Filesystem type is: ef53
Filesystem cylinder groups is approximately 5622
File size of /mnt/var/spool/cyrus/mail/domain/m/meine.domain.de/c/user/colttt/ is 339968 (83 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0 68320989               1 merged
   1       1 68337721 68320990      2 merged
   2       3 68342099 68337723      1 merged
   3       4 68342101 68342100      1 merged
   4       5 68370482 68342102      1 merged
   5       6 68370485 68370483      3 merged
   6       9 68408761 68370488      3 merged
   7      12 68422026 68408764      1 merged
   8      13 68547406 68422027      3 merged
   9      16 68547410 68547409      1 merged
  10      17 68550032 68547411      4 merged
  11      21 68596554 68550036      1 merged
  12      22 68596556 68596555      1 merged
  13      23 68596564 68596557      1 merged
  14      24 68596575 68596565      1 merged
  15      25 68628019 68596576      1 merged
  16      26 68628040 68628020      1 merged
  17      27 68630592 68628041      1 merged
  18      28 68630594 68630593      3 merged
  19      31 68650640 68630597      1 merged
  20      32 68655696 68650641      1 merged
  21      33 68655701 68655697      1 merged
  22      34 68656448 68655702      1 merged
  23      35 69008348 68656449      1 merged
  24      36 69009279 69008349      1 merged
  25      37 69009290 69009280      1 merged
  26      38 69009296 69009291      1 merged
  27      39 69012123 69009297      1 merged
  28      40 69021978 69012124      3 merged
  29      43 69085599 69021981      4 merged
  30      47 69133405 69085603      1 merged
  31      48 69166369 69133406      2 merged
  32      50 69166372 69166371      2 merged
  33      52 69341844 69166374      1 merged
  34      53 69346404 69341845      3 merged
  35      56 69349874 69346407      1 merged
  36      57 69425593 69349875      4 merged
  37      61 69504055 69425597      2 merged
  38      63 69578867 69504057      1 merged
  39      64 69579221 69578868      1 merged
  40      65 69640803 69579222      1 merged
  41      66 69703349 69640804      3 merged
  42      69 69738251 69703352      2 merged
  43      71 69748366 69738253      2 merged
  44      73 69844283 69748368      2 merged
  45      75 69844299 69844285      1 merged
  46      76 69844416 69844300      1 merged
  47      77 69882060 69844417      1 merged
  48      78 69882085 69882061      1 merged
  49      79 70019863 69882086      1 merged
  50      80 70020728 70019864      1 merged
  51      81 70124163 70020729      1 merged
  52      82 70153770 70124164      1 merged,eof
/mnt/var/spool/cyrus/mail/domain/m/meine.domain.de/c/user/colttt/: 53 extents found, perfection would be 1 extent

soo wie haben das ganze jetzt mit einem 2GB-Mailordner gemacht..
von altem storage auf dem neuen Storage..

Code: Alles auswählen

time rsync --stats -a /mnt/var/spool/cyrus/mail/domain/m/meine.domain.de/c/user/colttt/ /var/www/test/
sent 2031868500 bytes  received 324369 bytes  8932715.91 bytes/sec

anschliessend die caches und buffers geleert und das von einer platte auf die andere (beides ext4 und beide neu, sollte also nicht fragmentiert sein):

Code: Alles auswählen

time rsync --stats -a /var/www/test/ /home/foobar/.
sent 2031868509 bytes  received 324369 bytes  11321408.79 bytes/sec

scheint also entweder an den kleinen Dateien zu liegen oder am Storage.. Ich guck mal ob ich hier irgendwo noch ein hardawre server finde und probier das da mal..

[rendegast]

Anm. zu filefrag und Fragmentierung von VM-Images

Code: Alles auswählen

$ find -size +500M -exec /usr/sbin/filefrag "{}" \;
./.............vdi: 21 extents found
./.............vdi: 31 extents found
./.............vdi: 30 extents found
./.............vdi: 15 extents found
./.............vdi: 31 extents found
./.............vdi: 22 extents found

da alle mit GB-Größen ist die Fragmentierung akzeptabel.
Ganz gut gelungen:

Code: Alles auswählen

./60GB.img.qcow2: 75 extents found

Gegenbeispiel:

Code: Alles auswählen

# qemu-img create test-2GB.raw 2G
Formatting 'test-2GB.raw', fmt=raw size=2147483648
# losetup -f test-2GB.raw 
# losetup -a
/dev/loop0: [0046]:6634492 (/home/test-2GB.raw)

# cat /dev/zero > /dev/loop0 ; sync
cat: write error: No space left on device

# filefrag test-2GB.raw 
test-2GB.raw: 3656 extents found

Aua,
aber zugegeben immer noch 74MB/s (nach Cache-Leeren):

Code: Alles auswählen

# cat /dev/zero | tee /dev/shm/null > /tmp/null
^C
# rm /dev/shm/null /tmp/null

# dd if=/dev/loop0 bs=4k of=/dev/null
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB) copied, 28.9677 s, 74.1 MB/s

(die 2TB-Platte liegt unbelastet bei 150MB/s)

[rendegast]

Da du migrierst mit scheinbar viel Mail-Daten,
aber wohl maildir > maildir.

Ich habe dovecot umgestellt auf mdbox +

Code: Alles auswählen

mail_attachment_dir = ~/mail/attachments

Die Standardgröße für mdbox 2MB auf 19MB:

Code: Alles auswählen

mdbox_rotate_size = 19M

(mdbox und attachment-dir sind unabhängig voneinander)
Wermutstropfen, es muß umgedacht werden:
Für die Behandlung der mail von Adminseite aus (zBsp. backup) sind nur noch die Tools
doveadm
dsync
erlaubt.
Das backup der attachments muß dann auch gesondert behandelt werden.

Auch kann wohl cyrus2dovecot dafür nicht direkt verwendet werden.
Der erzeugte Datenbestand müßte wohl per dsync konvertiert werden.


Bei meiner Konvertierung dovecot-maildir -> dovecot-mdbox sind Altmail-Anhänge nicht im attachment-dir geladet, sondern in den mdbox-Dateien.
Nur neue Mail werden dahingehend aufgetrennt.
Eventuell kann da was mit dsync gemacht werden, habe das aber nicht weiter verfolgt.

Auch sind Admin-/Backup-Frontends zu prüfen, ob sie schon/gut mit doveadm/dsync arbeiten.
Denn händisch ist es doch ein Krampf.




----------------------------------------------------------------------------------------
Davon ab,
wenn da hunderte GB Mail vorliegen,
trifft euch wohl noch eher die gesetzliche Regelung für Signierung/Durchsehbarkeit des Mailbestands,
finanzamtstechnisch.
Im Sinne von, daß da wirklich mal jemand vorbeikommt oder nachfragt.
(beim kleinen Mittelstandsbetrieb hier liegt es wohl eher fern, daß da mal irgendwas passiert)
Somit wäre eine "zertifizierte" Appliance in Betracht zu ziehen, könnte die Nerven schonen.

[pdreker]

Du generierst extrem viele kleine IOPS und die Latenz Deines Storagesystems scheint nicht so die Rakete zu sein. Das würde bedeuten, dass Du nicht am MB/s Limit anschlägst, sondern an der IO Latenz (was bei Storage Sachen ohnehin der eigentlich einzige interessante Wert ist).

Der iowait Wert ist schon grottig (20-35ms für jede einzelne Anfrage, gemessen in der VM... Eine Desktopfestplatte liegt eher so bei 5-7...). Was mich irritiert ist die Tatsache, dass da nur 200-300 IOPS durchgehen (r/s und w/s Spalte in iostat). Was sagt den esxtop zur IO-Last in Richtung Datastores? Das Verhalten kenne ich aus verschiedenen Situationen: Overload (das Storage System ist am Ende (und unter uns: die Equallogics sind keine Raketen)), zu geringe Queue Tiefen (SAN Storage also FC/FCoE oder iSCSI), ...

Wie genau sieht der Setup aus? VM Datastores auf der Equallogic (welches Protokoll? Welche Bandbreite?) und die Mailstores dann per NFSv4 (warum v4?) auf einem anderen Server?

Ich würde meine Zeit erstmal nicht auf die VM verschwenden, das ist den seltensten Fällen ein echtes Problem.

[Colttt]

Hallo,

hier mal die Ausgabe von esxtop

Code: Alles auswählen

12:09:28pm up 276 days  2:12, 509 worlds, 18 VMs, 43 vCPUs; CPU load average: 0.18, 0.19, 0.20
PCPU USED(%):  11 8.4  29  15 6.5 3.9  24 0.8 3.4  30 4.2 8.0 4.8 1.5 9.0 2.4 4.8  12 8.9 3.7 1.0 2.2 8.9 5.0 AVG: 8.8
PCPU UTIL(%):  10 7.8  25  13 6.2 3.7  22 0.9 3.5  27 4.1 7.4 4.5 1.7 8.6 2.4 4.9  12 8.4 3.7 1.1 2.0 8.4 4.9 AVG: 8.2
CORE UTIL(%):  17      39     9.7      23      30      11     5.9      10      16      11     2.9      12     AVG:  15

      ID      GID NAME             NWLD   %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
27155582 27155582 VM_NAME_2608        12   12.21    9.26    2.11 1200.00    2.14    0.10  418.33    0.07    0.00    0.00    0.00

aber mittlerweile hat mir Dell gesagt, dass das Storage am IO LImit liegt. Im guten Fall bis zu 500IOPS (laut dem Headquarters Tool).

Wie genau sieht der Setup aus? VM Datastores auf der Equallogic (welches Protokoll? Welche Bandbreite?) und die Mailstores dann per NFSv4 (warum v4?) auf einem anderen Server?

Auf dem Storage laufen 35VMs, wobei davon max 5-10 wirklich IO machen (Monitoringserver, SYslogserver, mail, die mir spontan einfallen) .. ansonsten ist es mit 4x1GB angeschlossen.. Das mit dem NFSv4 mach ich nicht mehr, ich hänge die Platten direkt rein, was uns aktuell wieder auf eine Zeit von ~16h bringt für die Mirgration und das ist hier erstmal ok..

(das Storage System ist am Ende (und unter uns: die Equallogics sind keine Raketen))

Alternativen?
Ich würde ja gerne mal einen ZFS-System aufsetzen, aber da fehtl dann leider die Redundanz, bei den "Kopfen", bei der EQL kann ich von einem Controller alle Netzwerkkabel ziehen oder den Controller rausnehmen, es läuft instant, ohne das VMware etwas mitbekommt auf dem anderen Controller weiter, wenn ich das mit einem ZFS system auch hinbekomme, sollte ich das als Test bestimmt mal durchbekommen.

[pdreker]

Alternativen?

Naja, lass mich meine Aussage etwas relativieren: 500IOPS entsprechen 3-4 (!!!) 10000rpm SAS Platten unter Wort Case Bedingungen. Wieviele Spindeln drehen sich denn da? Bei SATA Platten würde ich auf so 10-12 tippen... Das wird mit keinem System der Welt schneller sein, außer Du bekommst mehr Spindeln oder schnellere Spindeln. Beides dreht die Preisschraube nach oben.

ZFS Systeme habe ich in der Vergangenheit in solchen Umgebungen als "Tuning Alptraum" kennengelernt... Wenn's performed, dann ist es auch gut, aber wenn es das nicht tut, dann muss man an so vielen Ecken schrauben (oft mit ungewissem Ausgang oder Reformats...), dass es sich unterm Strich nicht lohnt.

Ein schönes SSD Array ist natürlich auch was feines, aber in der "Enterprise-Klasse" "leicht unbezahlbar"...

Je nachdem welche VMware vSphere Lizenz ihr benutzt, dann habt ihr vSAN zur Verfügung (ab Enterprise Plus, IIRC), was ein Software Defined Storage ist. Jeden ESX Host mit 2,3,4 SSDs ausstatten und zusammenfassen. Das hinterlässt "Brandspuren" im Netzwerk. Da ihr aber nur 35 VMs fahrt, habt ihr wahrscheinlich nicht die dicke Lizenz gekauft (wegen $$$) und damit auch kein vSAN.

Was tun? Ein deftig ausgestattetes JBOD mit vielen und/oder schnellen Spindeln und einem SSD Read-Cache "ausreichender Größe" an einem Linux Server. Das Ganze per LVM/md-raid absichern und per NFS Datastore freigeben. Mit Supermicro Hardware (reines Beispiel für kostengünstige Serverhardware - so was hier z.B.) würde ich dann tendenziell ein XFS (nicht so Tuning anfällig wie ZFS und nicht so ein RAM-Fresser) draufsetzen. Wenn Du abenteuerlustig bist und ordentliche Backups machst, vielleicht auch ein BTRFS

Intern lösen wir das bei uns mit NetApp Storage Systemen, Feines Zeug (Snapshots, Replikas, CIFS, NFS, FC, iSCSI alles aus einer Büchse, transparenter Desaster Recovery, Deduplizierung, Flash Caches...) - aber leider in solchen "Kleinumgebungen" entsetzlich teuer (mindestens satt 5-stellig).

lg,
Patrick

[Colttt]

Je nachdem welche VMware vSphere Lizenz ihr benutzt, dann habt ihr vSAN zur Verfügung (ab Enterprise Plus, IIRC), was ein Software Defined Storage ist. Jeden ESX Host mit 2,3,4 SSDs ausstatten und zusammenfassen. Das hinterlässt "Brandspuren" im Netzwerk. Da ihr aber nur 35 VMs fahrt, habt ihr wahrscheinlich nicht die dicke Lizenz gekauft (wegen $$$) und damit auch kein vSAN.

nunja, auf dem einen Storage laufen nur 35VMs, insgesamt laufen aktuell 78 .. aber ok Enterprise Plus haben wir dann doch nicht (ganz)

Bei SATA Platten würde ich auf so 10-12 tippen..

sehr gut, sind aktuell 12platten drin - SATA

Das Ganze per LVM/md-raid absichern und per NFS Datastore freigeben

dann aber mit 10GB NICs.. und lvm+mdraid.. hmm hmmm... ich hätte ja dann da doch lieber zfs, da muss es nicht durch mehrere schichten durch (sdX-mdraid/lvm-FS) ..

und ramfresser ist ja ZFS "nur" weil es alles cached, aber ich hab nach wie vor das problemchen mit der redundanz, wenn man der filer-"kopf" abraucht steh ich im dunklen da und hab definitiv verloren. aber da muss man evtl testen wie weit man pacemaker dazu bekommt das um zu switchen und in welcher zeit vor allem, und ob es ihm stört wenn man die TCPverbindung wieder neu aufbaut

wenn dann wüýde ich auch die intelligenz(kopf) seperat vom storage haben und mir nen reines JBOD holen, ala https://www.supermicro.nl/products/chas ... RJBOD1.cfm .. aber soweit ich mich entsinne haben die SuperMicros probleme mit den HDD-leuchten, wir haben hier in nem Cluster so eins und das leuchtet ROT (was für ne bekloppte farbe) weils ne SWAP-Platte is, nicht weil sie defekt ist, dann blinkt sie rot.. nen blaues lämpchen kostet wohl sehr viel ^^