Schlagwort-Archive: VMWare

vSphere 5.5 Flash Read Cache: Performance und Praxis

Veröffentlicht am von
Antwort

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 →

Energy saving Micro-Servers running VMware vShpere 5

Veröffentlicht am von
1

Hi,

we were looking for inexpensive and energy efficient micro servers working with VMware vSphere 5 for our Lab and testing. These models worked just fine (although they dont have any VMware Certification, so you wont get support from VMware) :

Fujitsu MX130 S2

  • Dual-Core AMD Athlon II X2 220 2,8GHz
  • 16 GB RAM max. (4 x 4GB DDR3 1333 ECC unregistered)
  • onboard Broadcom GBit-LAN (tg3)
  • 2 non-hotswap 3,5″  SATA drive bays
  • 2 x HDD 500 GB
  • 4 low profile expansion slots (PCIe x1, x4, x16, legacy PCI)
  • power consumption 48W (vShpere 5.0 running, no active VM, without harddisks)

 

HP Proliant N40L

  • Dual-Core AMD Processor 1,5 GHz
  • 8 GB RAM max.
  • onboard Intel GBit-LAN
  • 4 non-hotswap 3,5″ SATA drive bays with SFF-8087 connector
  • 1 x HDD 250 GB
  • power consumption 42W (vShpere 5.0 running, no active VM)
  • nice: Set of screws and screwdriver on the back side of the front door, USB connector onboard, boots vSphere from USB

IT is exciting,
Christian Eich

RAID50 vs. RAID10

Veröffentlicht am von
2

Hallo Kollegen,

das Thema RAID ist wohl ein niemals endendes. Gerade jetzt, da in Zeiten vortgeschrittener Virtualisierungstechnik auch die Storage-Strategie angepasst werden muss und  damit größere SAN-Systeme auch in kleines und mittleres Gewerbe Einzug erhalten, stellen viele Admins neue Überlegungen über ihren jeweils optimalen RAID-Verbund an. Im Unterschied zu früher sind die Arrays jetzt viel größer, dazu kommt die Problematik der schnellen Daten-Übertragung über das Netzwerk. Auf das Prinzip von dedizierten Storage-Netzwerken und parallelen Daten-Pfaden werden wir ein anderes mal eingehen.
Die Auswahl des RAID-Setups ist schon der erste magische Punkt, der sorgfältig vorbereitet werden sollte, weil nachträgliche Änderungen nur schwer möglich sind. Viele Storage-Systeme verfügen zwar über eine Funktion bestimmte RAID-Level in andere zu überführen,  ohne dabei Datenbestände oder den Betrieb zu verlieren, in der Praxis ist jedoch oft die benötigte Kombinationnicht möglich oder die Live-Migration würde über Tage das gesamte System deutlich belasten, so, dass der tägliche Betrieb beeinträchtigt werden könnte. Die Auswahl des RAID-Levels sollte daher auf soliden Überlegungen beruhen.

Aber wie lässt sich von einer schwer voraussagbaren Anforderungen der eigenen Systeme auf das richtige RAID-Setup schließen?

Im Groben ist das ganz einfach:
Man untersucht die Anforderungen an Performance- und  Platzbedarf und zirkelt dann mit Hilfe der folgenden und vermutlich jedermann halbwegs geläufigen Tabelle der wichtigsten RAID-Level, eine Entscheidung herbei.

RAID 0 RAID 1 RAID 5 RAID 10 RAID 50
Prinzip Stripes über 2 PLatten Ein Platte gespiegelt Verteilte Parität Stripes über n Platten, gespiegelt Stripes über n RAID5
Mindest Anz. Platten 2 2 3 4 6
Datensicherheit keine 1 Ausfall 1 Ausfall 1 Ausfall pro Subarray 1 Ausfall pro Subarray
Kapazität 100% 50% 67% – 94% 50% 67% – 94%
Performance schnell schreiben schnell lesen mittel schnell schnell bei großen Datenmengen
Rebuild Performance – gut mittel sehr gut mittel
Vorteil 100% Kapazität / Performance Datensicherheit / Schreib-Performance Datensicherheit /hohe Kapazität Skalierbarkeit / Performance Skalierbarkeit / Kapazität

Große RAID-Setups

Das hat bisweilen ganz gut funktioniert in Zeiten der „Baremetal-Rechner“, die nur sich selbst mit Storage versorgen mussten. Gilt es jedoch beispielsweise einen VM-Ware-Cluster mit drei ESX-Servern und  insgesamt 50 virtuellen Rechnern zu bedienen, dann ist diese Informationsbasis zu dürftig.
Wir nehmen hier vorweg, dass wir schnell zu dem Schluss gekommen sind, die RAID-Level 10 und 50 genauer zu untersuchen, da sie als einzige gleichzeitig hohe Performance, Ausfallsicherheit und Skalierbarkeit mitbringen.

Performance ist nicht gleich Performance

Storage-Performance nicht so einfach messen und durch einfache Zahlenangaben charakterisieren. In der Regel wird einfach eine mittelgroße Datenmenge sequenziell auf den zu testenden Store geschrieben bzw. gelesen. Das lässt sich zumeist recht einfach umsetzen und das Ergebnis sind dann Zahlen wie z.B. 73MB/s schreiben etc. . Werden beispielsweise große zusammenhängende Datenmengen bewegt, ist das schon einmal eine hilfreiche Information. Andere Fragen bleiben jedoch zunächst unbeantwortet. Welche Eigenschaften eines Storage-System lassen z.B.einen Windows Domain-Controller in Windeseile booten oder helfen eine relationale Datenbank zu beschleunigen? Ausschlaggebend dafür ist ein schwer zu messendes Kriterium, namens Transaktionen pro Sekunde (tps). Also die Anzahl der Schreib- bzw Lese-Zugriffe pro Zeiteinheit. Die tps eines Systems lassen sich nur durch ausgeklügelte Benchmarks ermitteln, da dazu ein Testumgebung nötig ist, die parallel extrem viele kleine und kleinste I/O-Requests starten kann. Der für das durchschnittliche Serversystem „natürlichen“ I/O-Last kommt das jedoch erheblich näher, als die übliche Lese- und Schreibrate sequenzieller Daten.

Geeignete Benchmarks lassen sich z.B. in der Opensource-Welt finden. Wir verwenden ein freies Tool namens FIO u.a. zur Ermittlung der TPS-Werte. Mit einem  anderen Programm namens Bonni haben wir gute Erfahrungen auf kleineren Storage-Systemen gemacht. Für Tests an besonders schnellen Systeme, z.B. wenn SSD-Platten z.B. für Caches verwendet werden, mussten wir auf FIO umsatteln. Die genaue Funktionsweise von Benchmarkprogrammen, sowie die Interpretation der Resultate werden wir in einem eigenen Blogartikel genauer besprechen.

Welche Kriterien sind entscheidend für hohe TPS-Werte?

  • Die Anzahl der verwendeten Festplatten.
    Je mehr Festplatten (auch Spindeln genannt) gleichzeitig arbeiten, desto mehr Arbeit kann logischerweise auch verrichtet werden. Das trifft insbesondere auf TPS zu, da eine herkömmliche Festplatte bauartbedingt einige Zeit benötigt, um den Lesekopf neu zu positionieren. Bei vielen kleinen Zugriffen an „unterscheidlichen“ Stellen auf der Platte, entstehen so viele kleine Lese-Pausen, während sich der Kopf zum nächsten Ziel bewegt.
  • Das RAID-Setup.
    Am RAID-Level hängt ab, welche Arbeit der Controller verrichten wird und in welcher Weise Festplatten parallel arbeiten können. Logisch betrachtet sind in einem RAID 50 Verbund an einem Schreibzugriff mehr Platten aktiv beteiligt, als z.B. in einem RAID10. Beim Letzteren sollte daraus einen Performace-Gewinn resultieren.
  • Performance und Drehgeschwindigkeit der eingesetzten Festplatten.
    Je schneller sich die Datenscheibe der Festplatte dreht, desto weniger Zeit vergeht bis sich die „gesuchten Daten“ unter dem Lesekopf befinden. Insbesondere nach Repositionierungen des Kopfes muss dabei gewartet werden.

In der Praxis

Soweit die Theorie. Jetzt möchten wir wissen ob wir für unser VMWaren-Cluster besser RAID10 oder RAID50 einsetzten sollen und wie wir die Performance verbessern können.

Setup

  • VM-Ware-Cluster mit drei ESX-Servern (je 96GB RAM) und insgesamt 50 virtuellen Rechnern
  • Dell Equallogic PS4000 mit 12 Festplatten je 15.000 rpm
  • Dell Equallogic PS4000 mit 16 Festplatten je 7.200 rpm
  • Eine Linux-VM mit FIO-Benchmark Software.

Ergebisse (Ausschnitt)

EQL1 (10×15.000rpm) EQL2 (14x7200rpm)
RAID 10 RAID 10 RAID 50
Lesen-TPS 4KB 2161 tps 1406 tps 1390 tps
Lesen / Schreiben – TPS 4KB 1360 tps 800 tps 595 tps

Im direkten Vergleich auf EQL2 stehen sich RAID10 und RAID50 auf der selben Hardware gegenüber.
Außerdem werden zwei RAID10 Setups auf sehr ähnlicher Hardware, jedoch mit unterschiedlichen Ferstplattenbestückungen gegenüber gestellt.

Fazit:

Erwartungsgemäß ist RAID10 als das „teuerste“ RAID auch bei TPS am schnellsten. Allerdings ist der Vorsprung nicht sehr groß (zwischen 5% und 25% schneller als RAID50) und es gibt eine weitere Überraschung.
Die Bauart der Festplatten, insbesondere die Drehgeschwindigkeit, scheint auch in großen Verbünden maßgeblichen für die Leistung am Ende des Tages ausschlaggebend zu sein. Unseren Ergebnissen zufolge, ist die Annahme naheliegend, dass eine Verdoppelung der Drehgeschwindigkeit auch in etwa die Anzahl der Transaktionen verdoppelt. (Wenn man die Anzahl der Festplatten hochrechnet und Unterschiede in der übrigen Hardware vernachlässigt).

RAID 10 RAID 50
Vorteile Beste TPS-Werte, schnelles Rebuild, wenig Performanceverlust bei degradeten Arrays, etwas bessere Redundanz Beste Nutzung der Speicherkapazität (preisgünstiger), Ordentliche TPS-Werte, kleiner Vorteil beim lesen großen Datenmengen
Nachteile Nur 50% der Speicher-Kapazität nutzbar (teurer) Performanceverlust bei degradeten Arrays und während des Rebuilds, etwas weniger Redundanz
Einsatzzweck Schnelle Datenbanken, Storage für (virtuelle und physische) Systeme mit maximalen Leistungsanforderungen Große Datenbanken, Storage für (virtuelle und physische) Rechnersysteme mit normalen Anforderungen, Backup, Fileserver

Aufgrund dieser Messergebnisse haben wir uns entschieden, zwei unterschiedliche Storage-Systeme für unser VMWare-Cluster zu betreiben. Ein Storagesystem mit viel Speicherkapazität auf Basis normal-schneller Platten und RAID50 und dazu ein etwas kleineres System mit RAID10 und schnellen Platten. So können wir jede virtuelle Maschine und alle anderen Systeme mit Speicherplatz-Bedarf, nach Anforderung sortiert auf den jeweils individuell passenden Storage umziehen.

IT bleibt spannend!

Hannes Wilhelm
WorNet AG 2012

 

Quellen:

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

Veröffentlicht am von
11

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

Veröffentlicht am von
5

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

WorNet ist jetzt „VMware Professional Solution Provider“

Veröffentlicht am von
Antwort

Hallo, zusammen

Wir haben ja seit Jahren VMware-Technologie im Einsatz. Da lag es nahe ein paar Kurse zu absolvieren und die Erfahrung auch nach außen sichtbar zu machen. Seit gestern darf sich WorNet als „VMware Professional Solution Provider“ bezeichnen. Und natürlich bieten wir neben Planung Migration und Betrieb auch die komplette Produktpalette von VMware an.

Aktuell bauen wir übrigens einen VMware-Cluster in unserem Rechenzentrum auf. Damit erweitern wir unser Angebot an individuellen Infrastruktur- und Hostinglösungen um Hochverfügbarkeitslösungen.

IT bleibt spannend,

Euer  Christian Eich

Neuer Server in 15 Minuten gefällig?

Veröffentlicht am von
1

Sehr geehrte IT-Nutzer,

der Trend bei großen Firmen geht zu Dynamic Infrastructure, Server-as-a-Service etc. Für den Fall, dass Sie noch nicht wissen, was dahinter steckt, können Sie z.B. bei Wikipedia nachlesen, dass es dabei  darum geht, sich die Infrastruktur (v.a. Server) nur noch nach Bedarf, also dynamisch zu kaufen: D.h. nicht mehr großdimensionert „für alle Fälle“, sondern nach Bedarf genau die Ressourcen einkaufen, die man gerade benötigt – dabei zahlt man immer nur das, was man auch wirklich benutzt. Das heißt dann z.B. dass man für ein paar Wochen 2 zusätzliche Server (oder auch nur CPUs in bestehenden Servern) braucht und bezahlt. Bei großen Firmen lohnt es sich, relativ viel Aufwand zu betreiben, hier sehr umfassend und detailiert (feingranular) zu denken.

Wie kann ich als mittelständische Firma von dieser Entwicklung profitieren?

Wir reduzieren die Anzahl Ihrer Server (und damit die Kosten). Dies ist heute leicht möglich, weil aktuelle Server meistens überdimensioniert sind. Mit Hilfe von Virtualisierung betreiben Sie dann die bisherigen – jetzt logischen – Server auf einer gemeinsamen oder wenigen Hardware-Maschinen. Unser Rechenzentrum wird dann so mit Ihrem Netz verbunden, dass Sie in Zukunft viele Vorteile vereinen – die Verbindung ist so sicher wie VPN und so flexibel wie ein lokales Netz:

  • Sie können flexibel zu entscheiden, wann und wie Sie Ihre lokalen Kapazitäten erweitern möchten. Sie sind frei, welche Dienste im lokalen Netz und welche im WorNet-Rechenzentrum laufen.
  • Dienste im WorNet-Rechenzentrum haben eine bessere Anbindung, höhere Ausfallsicherheit und Stabilität und sind trotzdem zugreifbar wie im lokalen Netz.
  • Bei vom Internet aus erreichbaren Diensten: Hohe Sicherheit durch Verhinderung unerlaubter Zugriffe ins interne Netz.
  • Datensicherheit und Zugriffs-Geschwindigeit durch Verdoppelung der wichigen Daten, sodass sie lokal und im WorNet Rechenzentrum vorhanden sind.
  • Schnelle Reaktion: Ein neuer Server ist innerhalb von 15 Minuten bereit. auch wenn er nur für kurze Zeit benötigt wird.

Wofür kann das genutzt werden? Hier ein paar Beispiele:

  • Der Exchange-Server wird nicht mehr im lokal betrieben, sondern im WorNet-Rechenzentrum (Vorteile: Sicherheit bei gleicher Einfachheit + schnellerer Zugriff auf WebAccess).
  • Für Evaluierungen oder Tests wird für wenige Wochen oder Monate ein zusätzlicher Server gebraucht. Dieser kann lokal oder im Rechenzentrum stehen. In jedem Fall ist er schnell so und kann zugegriffen werden als wäre er lokal.
  • Datei-Ablage-Server, der die Daten an wechselnden Standorten bereitstellt, und im internen Netz trotzdem normal schnell erreichbar sein soll.

Es ist wirklich überraschend einfach, von den Vorteilen dieser Techniken zu profitieren.

  • Hohe Flexibilität.
  • Erhöhte Datensicherheit und Zuverlässigkeit durch Redundanz.
  • Erhöhte Sicherheit vor Angriffen durch Abtrennung von Internet-Diensten.
  • Vertrauen durch persönliche Zusammenarbeit und unser kleines Rechenzentrum mit höchsten Sicherheitsstandards.

Mit vernetzten Grüßen,

Dirk Steinkopf

WorNet AG
Vorstand, CEO

Binden Sie Ihre Kunden in Ihre Abläufe ein
Binden Sie Ihre Kunden in Ihre Abläufe ein