Clever Tanken: Cloud Hosting für Preisvergleiche rund um die Uhr


Die Deutschen lieben Vergleichsportale für günstiges Tanken. Marktführer ist das Online-Portal und App-Angebot „Clever Tanken“, das jeden Monat 15 Millionen Autofahrer nutzen. Damit Website, App und API trotz des Andrangs niemals offline gehen, setzt Geschäftsführer Steffen Bock auf das Virtual Cloud Hosting der WorNet AG – eine enge Zusammenarbeit, die weit über Hosting hinausgeht. Lesen Sie in diesem Beitrag, warum Hosting und Software-Entwicklung nahtlos miteinander verzahnt sein muss.

Es ist das Jahr 1999 in Heroldsberg bei Nürnberg: Steffen Bock fährt mit seinem Motorrad von Tankstelle zu Tankstelle und notiert sich die Spritpreise. Mit Unterstützung des Sohnes eines Arbeitskollegen veröffentlicht er die günstigsten Angebote online in einer Datenbank. Freunde und Bekannte von Bock freuen sich, weil sie dank seiner Recherchen Geld beim Tanken sparen. Könnte das zu einem Geschäftsmodell werden? Ja, denkt sich der Visionär im Jahr 1999 und legt das Fundament für „clever-tanken.de“, das weltweit erste Vergleichsportal für Spritpreise. „Sogar die Amerikaner hatten diese Idee erst später“, erinnert sich Bock. „Mittlerweile sind wir mit über 15 Millionen Usern pro Monat das führende Vergleichsportal für Kraftstoffpreise.“

Die Herausforderung: Ständige Verfügbarkeit – Kein Platz für Downtimes Weiterlesen

Ransomware verursacht kritische Lastspitzen


 

Durch extreme Malware-Wellen wird Ihren Mailservern bis zu einem zehnfachen der eigentlich notwendigen Last beschert. Eine verseuchte E-Mail kommt nämlich selten allein und wird hauptsächlich von infizierten Rechnern versendet. Je mehr sich infizieren, desto mehr Malware wird versendet, bis die Welle am Tagesende wieder abebbt.

malware-peaks3

Weiterlesen

vSphere 5.5 Flash Read Cache: Performance und Praxis


vSphere 5.5 führt ein neues Feature namens vSphere Flash Read Cache (vFRC) ein. Das beschleunigt Lesezugriffe im SAN durch einen Cache lokaler SSD-Laufwerke.

Ein spannendes neues Feature – Grund genug das im Labor auszuprobieren

Die Testumgebung besteht aus einem HP Microserver N54L mit einer Samsung PRO 840 SSD (128 GB) und einer Benchmark-VM mit fio, die auf einem langsamen Datastore auf einer QNAP TS-210 liegt. Ohne vFRC liegen die Messwerte recht konstant bei knapp 50MB/s Lesedurchsatz (sequential read mit 16MB Blockgröße) und knapp 100 IO/s (random read mit 4K Blockgröße).

Der Test bestand aus zwei Serien mit verschieden großen Caches, die einer virtuellen Festplatte von 50GB zugeordnet waren. Getestet wurde alle 10 Minuten (je 30 Sekunden sequential read und 30 Sekunden random read), die ersten drei Messwerte der abgebildeten Graphen waren Tests ohne vFRC.

vFRC-Benchmark Weiterlesen

Storage Benchmarking mit fio


Graphische Darstellung einer fio Testreihe

Neue Storage Systeme brauchen neue Benchmark-Tools. Unser Testaufbau bestand aus vier schnelldrehenden  Western Digital 1TB Platten, die eine Geschwindigkeit von 10.000 U/m erreichen. Diese sind zusammen mit zwei SSDs, die rein für das Cache benutzt werden, in einem Raid 10 Verbund. Dieser Testaufbau wurde übrigens später weiterentwickelt zu einem sehr schnellen Storage-System für unsere eigenen Hosting-Angebote, aber dazu mehr in einem weiteren Artikel.

Die ersten Versuche, entstanden mit dem Tool bonnie++ diese führten zu widersprüchlichen Ergebnissen. Nach längerem recherchieren, sind wir darauf gestoßen das bonnie++ nicht genügend Last erzeugen kann um Tests in dieser Größenordnung durchzuführen. Die Grenze der zu messenden IOs liegt hier bei 8000.

Nach dieser ernüchternden Erkenntnis, haben wir begonnen mit fio zu testen und bis auf die Ausgabe hat uns dieses Tool voll und ganz überzeugt.

Die Vor- und Nachteile von fio:

  • Erzeugt mehr Last durch das Angeben der Prozesse die  gestartet werden
  • Unterscheidet zwischen dem Modus, der Blöckgröße, der Testdateigröße sowie die Anzahl der Prozesse die gestartet werden
  • Auch für Stresstests und Hardware-Verifikation geeignet
  • Kann gut Automatisiert werden
  • Wenn ein stark unter Last stehendes System getestet wird, wird es mit fio nicht so stark belastet, da die Datenmenge mit der getestet wird geringer wird je stärker das System beansprucht ist, das Problem der Überlastung wird daher umgangen
  • Der Output ist sehr detailliert, um die Testergebnisse auszuwerten jedoch schlecht lesbar
  • Unter Ubuntu-Linux einfach zu installieren (apt-get install fio)

Dieser Programmcode ist unser automatisierter fio Test, mit der dazugehörigen Überschrift. Diese Daten werden anschließend an unser Perl Programm übergeben um die Ausgewerteten Daten lesbar zu machen.

#! /bin/bash

DEVICE=$1
SIZE=$2

ARGS1="--direct=1  --runtime=30 "
ARGS2="--filename=$DEVICE --size=$SIZE "

#  fio --filename=/dev/sdb1 --direct=1 --rw=read --bs=512 --size=4G 
#      --runtime=60 --name=job1 --name=job2 --name=job3 --name=job4 
#      --name=job5 --name=job6

(
echo "     DEVICE;  SIZE;     MODE; BLOCKSIZE; NUMJOBS;  READMB; WRITEMB; READIOS; WRITEIOS"
# for mode in rw read randrw randread; do
for mode in randread; do
   for blocksize in 4k 16M ; do
      ARGS3="--bs=$blocksize --rw=$mode "
      for jobs in 1 2 3 4 6 8 10 12 16 20; do
         ARGS4=""
         i=0
         while [ $i -lt $jobs ]; do
            let i=$i+1
            ARGS4="$ARGS4 --name=job$i"
         done
         #echo -n "$DEVICE;$SIZE;$mode;$blocksize;$jobs;"
         printf "%12s %6s %8s %10s %8s" "$DEVICE;" "$SIZE;" "$mode;" "$blocksize;" "$jobs;"
         fio $ARGS1 $ARGS2 $ARGS3 $ARGS4 | /usr/local/tools/fio_parser.pl
      done
   done
done
) | tee /tmp/fio-result-`/bin/date +%Y-%m-%d--%H-%M-%s`-`/bin/hostname`.csv


#! /usr/bin/perl

while ( $s =  ) {
# egrep "READ:|WRITE:|^  [a-z].*ios="
#   READ: io=4965MB, aggrb=84611KB/s, minb=13880KB/s, maxb=15064KB/s,
#         mint=60055msec, maxt=60088msec
#  WRITE: io=5015MB, aggrb=85463KB/s, minb=13999KB/s, maxb=15155KB/s,
#         mint=60055msec, maxt=60088msec
#  sdb: ios=9946/10014, merge=0/0, ticks=344830/329890,
#       in_queue=674820, util=99.93%

   chomp($s);
   if ( $s =~ / READ: /) {
      $ReadBandwidth = $s;
      $ReadBandwidth =~ s/^.*aggrb=//;
      $ReadBandwidth =~ s/B.*$//;
      $ReadUnit=chop($ReadBandwidth);
      if ($ReadUnit eq "M") {
         $ReadBandwidth=$ReadBandwidth*1024;
      } elsif ($ReadUnit eq "G") {
         $ReadBandwidth=$ReadBandwidth*1024*1024;
      }

      $Time = $s;
      $Time =~ s/^.*maxt=//;
      $Time =~ s/msec.*$//;
   } elsif ( $s =~ / WRITE: /) {
      $WriteBandwidth = $s;
      $WriteBandwidth =~ s/^.*aggrb=//;
      $WriteBandwidth =~ s/B.*$//;
      $WriteUnit=chop($ReadBandwidth);
      if ($WriteUnit eq "M") {
         $WriteBandwidth=$WriteBandwidth*1024;
      } elsif ($WriteUnit eq "G") {
         $WriteBandwidth=$WriteBandwidth*1024*1024;
      }

      if ($Time == undef ) {
         $Time = $s;
         $Time =~ s/^.*maxt=//;
         $Time =~ s/msec.*$//;
      }
   } elsif ( $s =~ /^  [a-z].*ios=/ ) {
      $ReadIOS = $s;
      $ReadIOS =~ s/^.*ios=//;
      $ReadIOS =~ s/\/.*$//;
      $WriteIOS = $s;
      $WriteIOS =~ s/^.*ios=[0-9]+\///;
      $WriteIOS =~ s/\,.*$//;
   }
}

printf( "%8s;", sprintf ("%.3f", $ReadBandwidth/1024) );
#print ";";
printf( "%8s;", sprintf ("%.3f", $WriteBandwidth/1024) );
#print ";";
printf ("%8i", int($ReadIOS*1000/$Time) );
print ";";
printf ("%9i", int($WriteIOS*1000/$Time) );
print "\n";


Und hier einmal eine Ausgabe.

DEVICE SIZE MODE BLOCKSIZE NUMJOBS READMB WRITEMB READIOS WRITEIOS
/dev/sdb1 49G randread 512 1 1624 0 3317 0
/dev/sdb1 49G randread 512 2 2926 0 5974 0
/dev/sdb1 49G randread 512 3 4363 0 8910 0
/dev/sdb1 49G randread 512 4 5572 0 11379 0
/dev/sdb1 49G randread 512 5 5918 0 12085 0
/dev/sdb1 49G randread 512 6 6396 0 13061 0
/dev/sdb1 49G randread 512 7 7076 0 14449 0
/dev/sdb1 49G randread 512 8 7647 0 15615 0
/dev/sdb1 49G randread 4k 1 12473 0 3193 0
/dev/sdb1 49G randread 4k 2 23147 0 5907 0
/dev/sdb1 49G randread 4k 3 33905 0 8656 0
/dev/sdb1 49G randread 4k 4 41183 0 10520 0
/dev/sdb1 49G randread 4k 5 43572 0 11122 0
/dev/sdb1 49G randread 4k 6 46203 0 11794 0
/dev/sdb1 49G randread 4k 7 48973 0 12501 0
/dev/sdb1 49G randread 4k 8 54445 0 13898 0
/dev/sdb1 49G randread 64k 1 106146 0 1693 0
/dev/sdb1 49G randread 64k 2 134256 0 2142 0
/dev/sdb1 49G randread 64k 3 184783 0 2949 0
/dev/sdb1 49G randread 64k 4 223165 0 3562 0
/dev/sdb1 49G randread 64k 5 250008 0 3991 0
/dev/sdb1 49G randread 64k 6 267242 0 4266 0
/dev/sdb1 49G randread 64k 7 282166 0 4504 0
/dev/sdb1 49G randread 64k 8 293171 0 4680 0
/dev/sdb1 49G randread 1M 1 267873 0 534 0
/dev/sdb1 49G randread 1M 2 314568 0 627 0
/dev/sdb1 49G randread 1M 3 290241 0 578 0
/dev/sdb1 49G randread 1M 4 297634 0 593 0
/dev/sdb1 49G randread 1M 5 247376 0 492 0
/dev/sdb1 49G randread 1M 6 263334 0 526 0
/dev/sdb1 49G randread 1M 7 269112 0 536 0
/dev/sdb1 49G randread 1M 8 269197 0 537 0

iSCSI performance tuning: 380 MB/s within a VM with openfiler and ESXi


Hi, folks

There is a large gap between entry level Storage appliances like QNAP, Thecus or Buffalo and „large“ SAN-Storages regarding performance, features and very much the price. We have found a solution to fill this gap for our datacenter. Using open source of course!

unsere TestumgebungFor quite a while we have been using Openfiler, a linux-based storage software. However, we were not content with the performance being just a notch above the entry level storages, despite the decent server hardware used. An ESXi cluster waiting for roll out was just the opportunity we needed to tune up I/O performance. So we hit the lab and found out, that the order of tuning steps was crucial to find the right configuration.

Our test bed:

  • 1 ESXi 4.1 server (Fujitsu RX 200 S6, 8 Cores 2,4 GHz, 48 GB RAM, 6 x GBit-NICs Intel)
  • 1 Openfiler 2.3 (Supermicro 8 Cores 2,0 GHz, 8 GB RAM, 3ware 9650SE 8 Ports, 6 x GBit-NICs Intel, 8 disk drives 2 TB SATA 7200U/min)
  • 1 switch Cisco Catalyst 2960S (24 port GBit)

We used four GBit NICs on either side for four iSCSI-VLANs with different IP address ranges. The NICs have to be assigned to the iSCSI software initiator to address all paths. We created an iSCSI volume in Openfiler, connected and formatted it in ESXi using VMFS 4 file system. Paths selection was configured „round robin“.

virtual machine for benchmarking:

We crated a VM with 1 CPU, 2 GB RAM and a harddisk of 15 GB + twice the size of the storage server’s RAM and installed Windows 7. Then we installed IOMETER and a standardized configuration from the VMware forums. This way your results can be compared with other forum posts.

1st step: Where do we start

First we measure the performance of the unoptimized system. The size of the test file we use is smaller than the storage server’s RAM. So any read and written data comes from the cache and we measure only the iSCSI connection.

Latency (ms) IO/s MB/s
Max Throughput-100%Read 14,6 4096,1 128,0
RealLife-60%Rand-65%Read 412,3 141,4 1,1
Max Throughput-50%Read 13,4 4302,2 134,4
Random-8k-70%Read 546,1 107,6 0,8

Not impressive, is it? Accessing the disks locally yields 420 MB/s! What a performance loss in the way to the VM.

2nd step: iSCSI path optimization

Next thing to do is tuning all parameters associated with the iSCSI paths. It is okay in this step to use unsafe settings (e.b. enabling a write buffer without having a BBU). The test file still is smaller than the storage server’s RAM, because we want to measure the iSCSI connection’s speed.

Things to look at:

  • Parameters of the network interface card (jumbo frames, TCP-offload)
  • iSCSI parameter (round-robin parameter)
  • RAID pontroller (enable write-cache)

The boost in performance was obvious:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,69 12624,71 394,52
RealLife-60%Rand-65%Read 318,66 181,52 1,42
Max Throughput-50%Read 8,08 7030,93 219,72
Random-8k-70%Read 369,51 150,26 1,17

This is close the theoretical limit.Leistungsanzeige der iSCSI-Pfade bei sequentiellem Zugriff

Beware: Don’t continue if you’re not satisfied. From now on it’s getting worse!

Watching the load of iSCSI paths in vSphere client should give a equal share of traffic over all paths.

Things we stumbled upon:

  • bad jumbo frame configuration. Test it with ping using large packets and „dont fragment“-bit set. Our switch needed a „set mtu jumbo 9000“
  • VMwares „round robin“ algorithm switches paths only every 1000 IO ops. You have to use „esxcli“ to change that.

3rd step: optimizing storage parameters

Now we set up everything to safe values for the production environment. The IOMETER testfile is twice as big as the storage server’s RAM. Caution: Size is given in blocks of 512 bytes.

We compared different RAID levels (getting practice in online RAID migration while doing so) and different number of disk drives.

Raid-10 with 4 disks: 2 TB (SATA, 7200 U/min):

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,93 12089,4 377,79
RealLife-60%Rand-65%Read 333,02 171,66 1,34
Max Throughput-50%Read 8,15 6857,19 214,29
Random-8k-70%Read 454,2 129,76 1,01

Raid-10 with 8 disks:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,8 12331,0 385,3
RealLife-60%Rand-65%Read 443,6 138,0 1,1
Max Throughput-50%Read 9,1 6305,3 197,0
Random-8k-70%Read 504,0 121,4 0,9

Increasing the number of spindles didn’t improve performance, although we expected better IOPS. So it would be better to use two independent datastores with 4 drives each.

Using RAID-6 with 8 drives gave worse IOPS.

Summary:

Almost 400 MB/s and >10.000 IOPS makes us very happy. Our x86 server with Openfiler (about $5.500) closes the gap between inexpensive entry level storage appliances ($1.500 Euro for 70 MB/s and2.000 IOPS) and large SAN storages for $15k+.

Further IOPS and latency improvement could be achieved using more and better drives (SSD, SAS). We haven’t tried storage replication yet, but we read reports about users successfully implementing „drbd“ .

 

IT bleibt spannend,

Christian Eich

This article is based on research by Christian Eich, Richard Schunn and Toni Eimansberger.
Author: Christian Eich

iSCSI-Performance-Optimierung: 380 MB/s in der VM mit openfiler und ESXi


Hallo, zusammen

(english version)

Zwischen den günstigen iSCSI-Storage-Appliances (QNAP, Thecus, Buffalo, Cisco SMB und Co.) und den „großen“ Storages aus der Fiberchannel-Welt klafft eine große Lücke, sowohl in der Performance, der Features aber insbesondere im Preis. Im WorNet-Labor haben wir eine überzeugende Lösung gefunden, die diese Lücke überbrückt. Natürlich mit OpenSouce-Mitteln!

unsere TestumgebungSchon lange setzen wir den auf Linux basierenden Openfiler für unsere iSCSI-Storage-Server ein. Allerdings waren wir mit der Performance nicht so recht zufrieden. Selbst mit leistungsfähiger Hardware kommt verglichen mit günstigen Appliances (in unserem Fall von QNAP) in den virtuellen Maschinen nur wenig mehr I/O-Leistung an. Die Testphase unseres neuen ESX-Clusters kam uns da sehr gelegen um systematisch an der Performance-Schraube zu drehen.

Hier hat sich ein optimales Vorgehen bei der Optimierung herauskristallisiert, bei dem die Reihenfolge der Optimierungsschritte  entscheidend ist.

Unsere Testumgebung:

  • 1 ESXi 4.1 Server (Fujitsu RX 200 S6, 8 Cores 2,4 GHz, 48 GB RAM, 6 x GBit-Netzwerk Intel)
  • 1 Openfiler 2.3 (Supermicro 8 Cores 2,0 GHz, 8 GB RAM, 3ware 9650SE 8 Ports, 6 x GBit-Netzwerk Intel, 8 Festplatten 2 TB SATA 7200U/min)
  • 1 Switch Cisco Catalyst 2960S (24 Port GBit)

Je 4 GBit Interfaces werden für iSCSI genutzt. Dabei werden 4 VLANs mit verschiedenen IP-Bereichen definiert. Die Interfaces müssen dem iSCSI-HBA zugeordnet werden bevor die Ziele sichtbar werden.  Dann wird ein Volume mit VMFS formatiert und man erhält einen Datastore mit dem man die Tests durchführen kann. Die Verwendung der Pfade wird auf „Round Robin“ konfiguriert.

virtuelle Testmaschine:

Wir haben eine virtuelle Maschine mit 1 vCPU, 2 GB RAM mit Windows 7 installiert. Die Größe der virtuellen Festplatte sollte mindestens 15 GB + 2 * RAM des Storageservers betragen. Zusätzlich wird IOMETER und ein standardisiertes Konfigurationsfile aus dem VMware-Forum installiert. Mit diesem Test erhält man Werte die mit den Ergebnissen anderer Forumsbeiträge vergleichbar sind.

1. Schritt: Ausgangssituation

Zunächst messen wir die Performance des nicht-optimierten Systems. Dabei wählen wir die Größe des Testfiles bewusst kleiner als der Arbeitsspeicher des Storage-Servers, d.h. wir messen zwar die iSCSI-Anbindung, nicht aber das Festplattensystem.

Latency (ms) IO/s MB/s
Max Throughput-100%Read 14,6 4096,1 128,0
RealLife-60%Rand-65%Read 412,3 141,4 1,1
Max Throughput-50%Read 13,4 4302,2 134,4
Random-8k-70%Read 546,1 107,6 0,8

Für 4 GBit Speicheranbindung ist das nicht gerade beeindruckend. Das RAID-System des Storage-Servers liefert lokal im Openfiler gemessen 420 MB/s!

2. Schritt: Optimierung der iSCSI-Speicheranbindung

Jetzt optimiert aggressiv man alle Parameter, die die Speicheranbindung betreffen. Dabei ist es in Ordnung, wenn unsichere Einstellungen (z.B. Write-Cache im RAID-Controller ohne vorhandene BBU) gewählt werden. Auch wählt man die Größe der Testdatei in IOMETER kleiner als den RAM des Storage-Systems, denn wir wollen möglichst wenig Einflüsse der Platten und statt dessen nur den Weg von der virtuellen Maschine bis zum iSCSI-Daemon im Storage-System testen.

Insbesondere konfiguriert man:

  • Netzwerkkartenparameter (Jumbo Frames, TCP-Offload)
  • iSCSI-Parameter (Round-Robin-Parameter)
  • RAID-Controller (Write-Cache einschalten)

Bei uns machte sich das deutlich bemerkbar:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,69 12624,71 394,52
RealLife-60%Rand-65%Read 318,66 181,52 1,42
Max Throughput-50%Read 8,08 7030,93 219,72
Random-8k-70%Read 369,51 150,26 1,17

Damit sind wir sehr nahe am theoretischen Maximum (4 GBit entspricht ca. 440 MB/s inkl. iSCSI-Overhead).Leistungsanzeige der iSCSI-Pfade bei sequentiellem Zugriff

Wichtig: Machen sie nicht weiter wenn Sie mit diesen Werten nicht 100%ig zufrieden sind. Ab hier wird es wieder schlechter!

Wenn man im vShpere-Client unter Leistung die Nutzung der iSCSI-Pfade bei sequentiellem Zugriff ansieht müssen die Pfade gleichmäßig mit je 1 GBit ausgelastet sein (Bild rechts).

Stolperfallen in unserem Test:

  • fehlerhafte Jumbo-Frame-Konfiguration (Test: Ping mit großen Paketen und Dont-Fragment-Bit), hierbei auch an den Switch (Cisco 2960S: „set mtu jumbo 9000“) denken!
  • Der Round-Robin-Algorithmus bei ESXi wechselt den Pfad im default nur nach 1000 IO-Operationen. Das muss man mit einem esxcli-Befehl umstellen.

3. Schritt: Optimierung der Storageparameter

Jetzt stellt man sinnvolle Werte für den Produktivbetrieb ein und  erhöht die Größe des Testfiles für IOMETER auf das doppelte des RAM des Storageservers. Aufpassen die „Maximum Disk Size“ wird in Blocks angegeben, ein Block hat 512 Bytes.

In unserem Fall haben wir nun verschiedene Raid-Level und Spindelzahlen verglichen.

Raid-10 mit 4 Platten zu je 2 TB (SATA, 7200 U/min):

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,93 12089,4 377,79
RealLife-60%Rand-65%Read 333,02 171,66 1,34
Max Throughput-50%Read 8,15 6857,19 214,29
Random-8k-70%Read 454,2 129,76 1,01

Raid-10 mit 8 Platten:

Latency (ms) IO/s MB/s
Max Throughput-100%Read 4,8 12331,0 385,3
RealLife-60%Rand-65%Read 443,6 138,0 1,1
Max Throughput-50%Read 9,1 6305,3 197,0
Random-8k-70%Read 504,0 121,4 0,9

Die Erhöhung der Anzahl der Festplatten von 4 auf 8 bei RAID-10 hat sich erstaunlicherweise nicht signifikant ausgewirkt. Da ist besser zwei unabhängige Datastores mit je 4 Platten anzulegen.

Ein Test mit einem RAID-6 aus 8 Festplatten ergab noch schlechtere Werte, insbesondere beim Random-Zugriff.

Fazit:

Mit knapp 400 MB/s und >10.000 IOPS sind wir absolut glücklich. Unser x86-Server mit Openfiler (ca. 4.000 Euro) schließt die Lücke zwischen den „kleinen“ (ca. 1.000 Euro und 70 MB/s und 2.000 IOPS) und den „großen“ jenseits der 10 k€.

Eine weitere Verbesserung der IOPS oder Latenzen ist mit schnelleren Festplatten, SSDs oder SAS-Platten sicher realisierbar. Eine Storage-Replikation ist mit „drbd“ machbar, wurde aber in diesem Test nicht untersucht.

Dieser Artikel basiert auf den Testreihen und Erfahrungen von Christian Eich, Richard Schunn und Toni Eimansberger.

IT bleibt spannend,

Christian Eich

SSD im Notebook nachrüsten und guten Rutsch


Hallo, beisammen

zwischen den Feiertagen habe ich etwas Zeit gehabt und meinen MacBook Pro mit einer SSD ExpressCard erweitert. Es handelt sich um eine Verbatim SSD ExpressCard 64GB, die nahtlos im ExpressCard-Slot verschwindet.

Auf die SSD habe ich meine virtuelle Windows 7 Maschine (VMware Fusion) kopiert und ein paar Tests gemacht:

1. Bootzeit mit Einloggen und Outlook starten (ohne Netzanbindung): 2:45 statt 6:11 Minuten

2. typische IOPS während des Bootens: SSD ca. 250 IPOS, HDD ca. 100 IOPS

3. Sequenzielles Lesen unter MacOS: 111 MB/s SSD und 66 MB/s interne Festplatte

Alles in allem eine lohnende Sache, insbesondere wenn der Plattenplatz ohnehin knapp wird und die Festplatte schon betagt ist.

Damit verabschlieden wir uns für dieses Jahr und wünschen allen Lesern einen guten Rutsch ins neue Jahr!

mit vernetzten Grüßen,

Christian