Performance Report

Transcription

Performance Report

Ausgabe 1.1
November 2008
Performance Report
iSCSI und iSCSI Boot
Seiten 18
Abstract
Reduzierung der IT-Betriebskosten ist ein wichtiger Aspekt bei der Gestaltung
von IT-Umgebungen. Eine der zentralen Maßnahmen in diesem
Zusammenhang ist die Konsolidierung von Infrastrukturen zur effektiveren
Nutzung und Administration.
Diese technische Dokumentation richtet sich an Personen, die vor der Frage
stehen, ob der Anschluss von Storage-Systemen an PRIMERGY Server über
iSCSI eine Möglichkeit für einen preisgünstigen Einstieg in die Storage Area
Netzwerk-Technologie ist, ohne eine komplett neue Infrastruktur aufbauen zu müssen.
Weiterhin stellt dieses Dokument eine Alternative zur herkömmlichen Art der Betriebssystem-Datenhaltung
vor. Hierbei befinden sich die Betriebssystemdateien nicht lokal auf den Server-Festplatten (local Boot),
sondern entfernt (remote) in einem zentralen Storage-System. Im Speziellen wird ein Überblick über das
Thema iSCSI Boot gegeben.
Inhalt
Einleitung ............................................................................................................................................................ 2
iSCSI-Architektur ................................................................................................................................................ 3
iSCSI-Durchsatz ................................................................................................................................................. 5
iSCSI Boot .......................................................................................................................................................... 9
Messumgebung ................................................................................................................................................ 15
Fazit .................................................................................................................................................................. 17
Literatur ............................................................................................................................................................ 18
Kontakt ............................................................................................................................................................. 18
White Paper
Performance Report | iSCSI und iSCSI Boot
Version: 1.1, November 2008
Einleitung
Server und Storage-Systeme werden im Rahmen von Konsolidierungen zur Senkung der IT-Betriebskosten
zu effektiveren, besser ausnutzbaren und administrierbaren Einheiten zusammengefasst. In zunehmendem
Maße wird an Stelle der alt bekannten, direkt angeschlossenen Storage-Systeme (»Direct Attached
Storage« (DAS)) das so genannte »Storage Area Network« (SAN) eingesetzt, um sowohl die physikalischen
Restriktionen lokaler Storage-Systeme als auch die durch die Verkabelung fixe Zuordnung von Servern und
Storage-Systemen zu durchbrechen. Neben Fibre-Channel (FC) mit seiner komplett eigenen Infrastruktur
gewinnt »Internet SCSI« (iSCSI), durch die »Internet Engineering Task Force« (IETF) als RFC3270
beschrieben, immer mehr an Bedeutung. Hinter diesem Konzept steckt ebenfalls die Idee, das StorageSystem vom Server loszulösen und als eigenständige Einheit in einem Netz einem oder mehreren Servern
zur Verfügung zu stellen. Umgekehrt kann auch ein Server auf mehrere Storage-Einheiten zugreifen. Im
Gegensatz zu den meisten »Network Attached Storage« (NAS) Systemen, welche über ein LAN die aus der
Microsoft Welt bekannten Protokolle SMB (»Server Message Block«) bzw. CIFS (»Common Internet File
System«) oder das aus dem UNIX / Linux bekannte NFS (»Network File System«) zur Verfügung stellen,
werden sowohl durch iSCSI als auch durch Fibre-Channel im Server blockorientierte Geräte (Block Devices)
zur Verfügung gestellt. Einige Anwendungen setzen für ihre Datenablage Block Device-Schnittstellen
zwingend voraus, bei denen es für Anwendungen dann keinen Unterschied macht, ob sie auf ein direkt
angeschlossenes Storage-System zugreifen oder ob sich die Daten »irgendwo« im Netzwerk befinden.
Im Unterschied zu Fibre-Channel mit seiner speziellen Infrastruktur mit eigenen Controllern, eigener
Verkabelung, eigenen Switches und auch eigenem Management, greift iSCSI auf die von TCP/IP bekannte
Infrastruktur zurück – daher auch die Bezeichnung »IP-SAN«. Durch die Nutzung vorhandener
Infrastrukturen sind die Einstiegskosten bei iSCSI niedriger als im Fibre-Channel-Umfeld. Auch für die
Überbrückung großer Entfernungen ist iSCSI hervorragend geeignet. FC-SAN und IP-SAN sind aber nicht
nur alternativ zu sehen, denn der Anschluss entfernter Betriebseinheiten, Abteilungen oder Zweigstellen an
ein zentral vorhandenes FC-SAN kann kostengünstig über iSCSI erfolgen.
Auffallend ist, dass obgleich viele Kunden über leistungsfähige SAN-Systeme verfügen, diese im
Allgemeinen nur für Daten der Anwendungen, nicht aber für das Server-Betriebssystem selbst und dessen
temporäre Daten, genutzt werden. Unverändert existiert vielerorts das heute übliche Vorgehen, das
Betriebssystem des Servers von den lokalen Server-Festplatten zu booten. Die Daten der Anwendungen
liegen im SAN, und die der Betriebssysteme jeweils lokal auf den Servern. Dabei kann gerade eine
vollständige Entkopplung von Servern und Festplatten einen bedeutenden Beitrag zur Reduzierung der ITKosten beitragen.
Die Vorteile liegen auf der Hand. Die aufgrund ihrer beweglichen Teile fehlerträchtigen Festplatten werden in
einer Infrastruktur vereint. Das reduziert die Komplexität, gegeben durch die Vielfalt an RAID-Controllern,
Anschlusstechnologien, wie PATA, SATA, SCSI, SAS, und Festplattentypen. Zentrale Storage-Systeme
bieten eine einheitliche Infrastruktur und somit eine bessere Ausnutzung der Ressourcen, eine einfachere
Wartung und Vorhaltung von Spare Parts und somit eine höhere Verfügbarkeit.
Der Grundgedanke einer Server- und Storage-System-Konsolidierung, das Zusammenfassen von
Ressourcen, wird erst durch Realisierung von SAN Boot vollständig umgesetzt. Für diese Boot-Methode
eignen sich besonders die Server-Installationen, die aufgrund des Bedarfs nach zentralisiertem Management
und erweiterten Storage-Funktionalitäten, wie Datenreplikation und Snapshooting-Mechanismen, bereits
über die notwendige Infrastruktur verfügen. Hier kann ohne zusätzliche Kosten eine »remote Boot« Lösung
realisiert werden, denn die aktuellen PRIMERGY Server, die für den Einsatz im Enterprise-Umfeld
vorgesehen sind, verfügen alle über die Fähigkeit via Netzwerk zu booten.
© Fujitsu Technology Solutions 2009
Seite 2 (18)
White Paper
iSCSI-Architektur
Das iSCSI-Protokoll ermöglicht die Übertragung von SCSI-Aufträgen und -Daten über Ethernet mit Hilfe des
TCP/IP-Protokolls. Der Server, von dem die Kommunikation ausgeht, wird »Initiator« genannt. Das
angesprochene Storage-System wird als »Target« bezeichnet, da es das »Ziel« der Kommunikation ist.
iSCSI Initiator
Aufgabe eines iSCSI Initiators ist die Kommunikation mit einem oder mehreren iSCSI Targets sowie die
Darstellung der von den Targets repräsentierten iSCSI Devices als Server-lokale SCSI Devices. Zur
Kommunikation gehört auch das Versenden und Empfangen der in Netzwerkpaketen verpackten SCSIPakete. Ein iSCSI Initiator kann entweder als Software-Lösung implementiert sein oder als dedizierte
Hardware-Komponente.
Software-Initiatoren sind für alle aktuellen Betriebssysteme verfügbar. Ein Vorteil beim Einsatz der SoftwareInitiatoren ist die Möglichkeit, die vorhandene Infrastruktur zu verwenden. Dies trifft allerdings nur dann zu,
wenn im vorhandenen Netzwerk noch genügend Ressourcen, insbesondere Bandbreite, zur Verfügung
stehen. Es macht natürlich wenig Sinn, ein vorhandenes Netz zu verwenden, wenn dessen komplette
Bandbreite dann bereits für die iSCSI-Verbindung zum Storage-System benötigt wird. Abhilfe schafft hier ein
separates Netz oder eine Aufrüstung des vorhandenen Netzes. Die Leistungsfähigkeit (also der Durchsatz)
der iSCSI-Anbindung wächst mit der Leistungsfähigkeit der Netzwerkinfrastruktur, vorausgesetzt die
angeschlossenen Storage-Systeme bieten ebenfalls die benötigte Leistungsfähigkeit. Nicht nur aus
Performance-, sondern auch aus Sicherheitsgründen sollte ein separates Netzwerk für iSCSI trotz der dann
entstehenden Mehrkosten in Erwägung gezogen werden.
Hardware-Initiatoren sind spezielle »iSCSI Host Bus Adapter« (HBA). Diese Controller müssen zusätzlich
eingebaut werden und benötigen neben eigenen IP-Adressen auch geeignete Anschlüsse an das Netzwerk.
Daher unterscheiden sich die Investitionskosten für einen solchen iSCSI Controller nicht sehr von den
Kosten eines Fibre-Channel-Controllers. Dadurch wird ein Teil des Kostenvorteils von iSCSI gegenüber
Fibre-Channel zunichte gemacht. Außerdem können sie nicht zusätzlich noch für den Betrieb des
allgemeinen Netzwerkverkehrs genutzt werden.
Unabhängig von der Implementierungsform in Soft- oder Hardware werden iSCSI Initiatoren vom ServerBetriebssystem als SCSI-Adapter wahrgenommen und dargestellt.
Die aktuellen PRIMERGY Server erlauben das Booten über iSCSI, sofern ein iSCSI HBA oder ein SWInitiator mit Boot-Unterstützung für einen aktuellen Ethernet-Controller installiert ist. Bei Verwendung eines
SW-Initiators wird beim Boot-Vorgang die Rolle des Initiators vom Ethernet-Controller wahrgenommen.
iSCSI Target
Storage-Systeme mit iSCSI-Funktionalität übernehmen die Rolle eines iSCSI Targets. Dies ist zuständig für
die Kommunikation mit einem oder mehreren iSCSI Initiatoren und für die Repräsentation von sogenannten
iSCSI Devices, die in einem Storage-System als »Logical Unit Numbers« (LUNs) oder Volumes, eventuell
als virtuelle Harddisks (Images), abgebildet sind.
Ebenso wie für den Initiator im Server gibt es auch für die iSCSI Storage Systeme sowohl Software- als auch
Hardwarelösungen für die Anbindung an das TCP/IP Netz. Die Hardware-Lösung beinhaltet ein StorageSystem mit »nativer« iSCSI-Schnittstelle. Die Software-Lösung vermittelt mit Hilfe eines zweiten Servers, auf
dem dann ein Betriebssystemdienst läuft, zwischen TCP/IP und einem an diesen Server angeschlossenes
Storage-System. Software Targets sind für alle aktuellen Betriebssysteme verfügbar.
Die Art der verwendeten Anbindung ist für den Initiator transparent und ohne Bedeutung. Im Storage-System
selbst sind dann die verwendeten SCSI- oder Fibre-Channel-Platten über gängige RAID-Verfahren
gesichert.
Seite 3 (18)
White Paper
Sicherheit bei iSCSI
Da iSCSI, anders als Fibre-Channel, auch im gleichen Netzwerk betrieben werden kann wie die angeschlossenen Client-Arbeitsplätze, besteht wenigstens theoretisch die Gefahr des unberechtigten Zugriffs auf
Speicherdaten. Um ein Ausspionieren der über das Netzwerk abgewickelten Speicherzugriffe zu unterbinden, können Sicherheitsmechanismen wie Host-Authentifizierung und Verschlüsselung der IP-Pakete
mittels »Internet Protocol Security« (IPSec) eingesetzt werden. Bei Verwendung eines Software-Initiators
bzw. -Targets werden dabei die im Betriebssystem vorhandenen Mechanismen genutzt. Beim Einsatz eines
Hardware-Initiators bzw. -Targets sollten die im HBA vorhandenen Mechanismen genutzt werden.
Als Alternative zur Verschlüsselung des gesamten Netzwerkverkehrs gibt es noch weitere Möglichkeiten, um
den unbefugten Zugriff auf die Daten zu verhindern: die Verwendung eines separaten Netzwerkes für die
Zugriffe auf das Storage-System oder der Einsatz von virtuellen Netzwerken (VLANs).
PRIMERGY Server und iSCSI
Fujitsu Technology Solutions bietet Netzwerk-Controller der Firmen Broadcom und Intel an, mit denen sich in
Verbindung mit PRIMERGY Servern performante und zuverlässige LAN-Verbindungen, also auch iSCSIVerbindungen, realisieren lassen. LAN-Controller der Familien »Broadcom NetXtreme« und »Intel
PRO/1000« unterstützen iSCSI-Verbindungen aufgrund eines integrierten BIOS bereits in der Boot-Phase.
Standardmäßig sind alle mit diesen Netzwerk-Controllern ausgestattete PRIMERGY Systeme in der Lage,
über iSCSI zu booten.
Fujitsu Technology Solutions bietet Storage-Systeme der FibreCAT Serie mit iSCSI-Konnektivität an. Durch
ihre RAID-Funktionen bieten sie ein hohes Maß an Ausfallsicherheit und Performance. Snapshot-, Cloningund Datenreplikationstechniken der FibreCAT Serie erhöhen die Sicherheit, damit eignen sich diese
Systeme sehr gut zur zentralen Ablage der Daten und auch der Betriebssystemdateien für die
»remote Boot« Vorgänge.
Seite 4 (18)
White Paper
iSCSI-Durchsatz
In diesem Kapitel wird zuerst die generelle Leistungsfähigkeit des Storage-System-Anschlusses über iSCSI
betrachtet, um einen allgemeinen Eindruck von der iSCSI-Performance zu erhalten, bevor gezielt der BootVorgang über iSCSI analysiert wird. Dazu wird der Datendurchsatz von verschiedenen PRIMERGY Servern
bei verschiedenen Storage-System-Anschlussarten dargestellt.
Folgende PRIMERGY Server werden betrachtet:
Blade Sever
PRIMERGY BX620 S4
Rack Server
PRIMERGY RX300 S4
Tower Server
PRIMERGY TX200 S4
Auf allen Systemen ist Windows Server 2003 Enterprise Edition installiert. Die lokale (interne) Festplatte wird
mit einem LSI MegaRAID 1068 oder 1078 SAS Controller betrieben. Alle Systeme besitzen »onboard« LANController vom Typ »Broadcom NetXtreme GigE« mit 5708C oder 5715S Chip. Ein separates Netzwerk ist
für den Anschluss des Storage-Systems vorgesehen und die Netzwerkpakete werden nicht verschlüsselt.
Das Storage-System wird direkt über den SAS-Controller, über Fibre-Channel oder über iSCSI
angeschlossen. Für die Anbindung der Server an das iSCSI Storage-System wurde die Boot-Version des
Microsoft Software-Initiator eingesetzt.
Folgende Storage-Systeme werden eingesetzt:
FibreCAT SX40 als Direct Attached Storage-System (DAS, 3 Gb/s)
FibreCAT SX80 als Fibre-Channel Storage-System (FC, 4 Gb/s)
FibreCAT NX40 S4 als iSCSI Storage-System (iSCSI, 1 Gb/s)
Die Storage-Systeme sind mit zwölf Festplatten ausreichend dimensioniert und als zwei für dieses Szenario
übliche RAID 5 Festplattenverbände konfiguriert. Es werden der Datendurchsatz, die Antwortzeit und die
CPU-Belastung des Servers bei unterschiedlichen Zugriffsmustern und Blockgrößen betrachtet.
Datendurchsatz
Das folgende Diagramm zeigt den Datendurchsatz der Storage-System-Anschlussvarianten DAS, FC und
iSCSI beim sequentiellen Lesen (»sequential read«), sequentiellen Schreiben (»sequential write«) und bei
wahlfreien Zugriffen mit 2/3 Leseanteil (»random 67% read«), jeweils bei den von Anwendungen
hauptsächlich genutzten Blockgrößen von 4, 8 und 64 kB.
Es ist erkennbar, dass der Durchsatz bei sequentiellen Zugriffen bei DAS am höchsten und bei iSCSI am
niedrigsten ist. Die Unterschiede beim wahlfreien (random) Zugriff sind zu vernachlässigen. Das iSCSI-
Seite 5 (18)
White Paper
Durchsatzmaximum wird bei exklusiver Verwendung einer 1-GbE-Verbindung auf etwa 117 MB/s
beschränkt, wenn das Medium nur in einer Richtung, d.h. nur lesend oder nur schreibend, genutzt wird. Bei
bidirektionaler Verarbeitung, wenn also sowohl lesend als auch schreibend zugegriffen wird, kann mit einer
1-GbE-Verbindung ein Durchsatzmaximum von etwa 170 MB/s erreicht werden. Werden zwei 1-GbEVerbindungen parallel verwendet, so lässt sich der Durchsatz fast verdoppeln. Dies lässt sich skalieren, bis
andere Ressourcen zum Engpass werden.
Antwortzeit
Neben dem absoluten Datendurchsatz ist die Latenz des Storage-Subsystems eine wichtige Messgröße, die
sich in der Antwortzeit gegenüber der Anwendung ausdrückt.
Positiv zu bemerken ist, dass die Antwortzeiten bei allen Anschlussarten und Zugriffsmustern weniger als
sieben Millisekunden betragen. Hierbei muss aber beachtet werden, dass die Antwortzeit mitbestimmt wird
durch die vom Messprogramm Iometer über »Outstanding I/Os« auf drei eingestellte Warteschlangenlänge.
Eine höhere Queue-Tiefe ermöglicht höhere Parallelität und Optimierungsmöglichkeiten durch den
Controller. Dies führt in der Regel zu einer höheren Auslastung der Hardware und damit zu einem höheren
Durchsatz. Die Antwortzeit erhöht sich dabei um die Verweildauer des I/O-Auftrages in der Warteschlange.
Bei der Betrachtung der mittleren Antwortzeiten (»avg Resp Time«) ist erkennbar, dass beim sequentiellen
Lesen oder Schreiben die kürzesten Antwortzeiten bei DAS und die längsten Antwortzeiten bei iSCSI
auftreten.
Bedingt durch Positionierungsvorgänge dauern wahlfreie Zugriffe länger als sequentielle Zugriffe. Dies zeigt
sich bei allen Anschlussarten deutlich, wobei mit FC die kürzesten und mit DAS bzw. iSCSI die längsten
Antwortzeiten auftreten.
Die längeren Antwortzeiten bei iSCSI sind auf die geringere Geschwindigkeit der genutzten Verbindung
zurückzuführen. Während die SAS-Schnittstelle 3 Gb/s und die FC-Schnittstelle 4 Gb/s transportieren kann,
ist die Ethernet-Verbindung auf 1 Gb/s beschränkt. Der Vergleich zeigt jedoch auch, dass die Anschlussart
iSCSI über eine 1-GbE-Verbindung hinsichtlich der Antwortzeit unproblematisch ist, da die meisten
Anwendungen mit Zeiten kleiner 10 Millisekunden gut bedient sein dürften.
Seite 6 (18)
White Paper
CPU-Belastung
Neben Datendurchsatz und Latenzzeit ist es sinnvoll, die CPU-Belastung aufzuzeigen. Diese kann absolut
betrachtet werden oder im Verhältnis zum erzielten Datendurchsatz, das die Effektivität der Anschlussart
beschreibt. Die im Folgenden dargestellten Werte beziehen sich auf zwei Quad-Core CPUs mit 3.0 GHz
Taktfrequenz.
Wenn man sich die absolute CPU-Belastung bei den verschiedenen Zugriffsmustern ansieht, so benötigen
alle Anschlussarten weniger als 10% der CPU-Ressourcen, und das bei der von Iometer erzeugten
Höchstlast an Disk-I/O. Moderne Prozessoren sollten diese zusätzliche Last gut bewältigen können. Es ist
ersichtlich, dass bei diesen Messungen iSCSI das System weniger belastet als FC. Dies ist auf den
geringeren Durchsatz bei iSCSI zurückzuführen. Beim wahlfreien Zugriff wird durch DAS die geringste und
durch FC die höchste CPU-Belastung erzeugt.
Beim sequentiellen Schreiben wird bei DAS die höchste und bei iSCSI die geringste CPU-Belastung
festgestellt. Beim sequentiellen Lesen wird die niedrigste CPU-Belastung bei 4 kB und 64 kB Blöcken durch
DAS verursacht und bei 8 kB Blöcken durch iSCSI.
Der Vergleich zeigt, dass die Anschlussart iSCSI über eine 1-GbE-Verbindung hinsichtlich der CPUBelastung unproblematisch ist.
Seite 7 (18)
White Paper
Die folgende Grafik zeigt die CPU-Belastung per I/O-Operation. Die Werte bewegen sich im Bereich kleiner
drei Promille. Relativ hoch ist allerdings die Belastung beim wahlfreien Zugriff mit FC.
Beim sequentiellen Lesen wird bei DAS die niedrigste CPU-Belastung und bei iSCSI die höchste CPUBelastung erzeugt. Dies ist beim sequentiellen Schreiben und bei den wahlfreien Zugriffen anders, hier
verursacht FC eine höhere CPU-Last als iSCSI und DAS.
Die nächste Grafik zeigt die CPU-Effektivität bei den verschiedenen Storage-System-Anschlussarten in
anderer Form. Dazu werden die I/O-Operationen per %CPU-Last dargestellt. Auch hier ist die hohe CPUEffektivität beim DAS klar erkennbar.
Eine höhere CPU-Effektivität als beim FC-Anschluss zeigt sich beim iSCSI-Anschluss wenn sequentiell
geschrieben oder wahlfrei zugegriffen wird. Lediglich beim sequentiellen Lesen ist FC gegenüber iSCSI im
Vorteil.
Seite 8 (18)
White Paper
iSCSI Boot
Als Boot-Prozess bezeichnet man das Laden des Betriebssystems in den Arbeitsspeicher eines Computers.
Als erster Schritt wird nach dem Einschalten des Rechners das BIOS (Basic Input Output System)
initialisiert. Das BIOS besitzt nach entsprechender Konfiguration Informationen, welche die boot-fähigen
Geräte definieren und deren Reihenfolge vorgeben. Dies können beispielsweise Festplatten, Disketten,
optische Laufwerke, USB-Geräte oder I/O-Karten mit eigenem BIOS sein. Auch für diese Controllers kann
ein Boot-Gerät definiert werden. Damit ist es möglich, den Boot-Prozess über ein Netzwerk zu starten. Mit
SAN Boot wird der Bootvorgang des Servers über FC- oder iSCSI-Verbindungen bezeichnet.
Local Boot
Der mit »Local Boot« bezeichnete Vorgang wird hier als der traditionelle Boot-Prozess verstanden, welcher
das Betriebssystem von einem lokalen Datenträger lädt und startet. Es ist heute das am häufigsten
angewandte Vorgehen.
Merkmale von Local Boot sind:
Kein zentrales Management der Boot-Devices möglich bei erhöhter Komplexität, gegeben durch die
Vielfalt an RAID-Controllern, Anschlusstechnologien, wie PATA, SATA, SCSI, SAS, und
Festplattentypen.
Backup und Restore können nur über ein an jeden Server lokal angeschlossenes Bandlaufwerk oder
über das Netzwerk abgewickelt werden.
Die lokalen Festplatten in den Servern benötigen Strom, bedingen größere Netzteile und führen
deshalb zu mehr Wärmeentwicklung in den Servern. Dies erfordert mehr oder größere Lüfter, was
wiederum den Formfaktor bzw. die Größe des Servergehäuses negativ beeinflusst.
Relativ einfacher Einrichtungsprozess.
SAN Boot (Fibre-Channel und iSCSI)
Beim SAN Boot liegt das Boot-Device des Servers im SAN. Der Zugriff erfolgt über HBAs (Host Bus Adapter)
welche auf Fibre-Channel- oder Netzwerk-Technik basieren. Die verwendeten Host-Bus-Adapter müssen
über ein eigenes BIOS verfügen, welches während des Boot-Prozesses den Zugriff auf die im SAN
befindlichen Geräte erlaubt.
Merkmale von SAN Boot sind:
Es werden keine lokalen Festplatten benötigt und somit wird der Einsatz von kleineren und
sparsameren Servern ermöglicht. Durch Verringerung von Energieverbrauch und Wärmeentwicklung
kann ein Rechenzentrum kostengünstiger implementiert werden.
Ein zentrales Management der Boot-Devices inklusive einem zentralen Backup bei gleichzeitiger
Vermeidung einer Vielfalt an RAID-Controllern und Anschlusstechnologien.
Von den in einem SAN üblichen Maßnahmen zur Erhöhung der Ausfallsicherheit profitieren auch die
Boot-Devices.
Relativ komplexer Einrichtungsprozess.
PXE Boot
Diese Methode wird hier nicht weiter betrachtet, weil sie in der Regel nur zum Booten eines Thin Client oder
zur Installation eines Betriebssystems auf einer Server-lokalen Festplatte mit Hilfe einer Netzwerkressource
dient.
Seite 9 (18)
White Paper
Boot-Zeiten
In diesem Kapitel werden die Zeiten für »local Boot« und »remote Boot« verglichen. Dabei steht nicht die
Vergleichbarkeit der Systeme im Fokus, sondern die Vergleichsmöglichkeit des lokalen Boots mit dem iSCSI
Boot je System. Weiterhin werden Broadcom und Intel LAN-Adapter verglichen sowie ein 32-bit- mit einem
64-bit-Betriebssystem.
Es werden folgende PRIMERGY Server betrachtet:
Blade Sever
PRIMERGY BX620 S4
Rack Server
PRIMERGY RX300 S4
Tower Server
PRIMERGY TX200 S4
Auf allen Systemen ist Windows Server 2003 Enterprise Edition installiert. Die lokale (interne) Festplatte wird
mit einem LSI MegaRAID 1068 oder 1078 SAS Controller betrieben. Für das durch das Betriebssystem
verursachte Datenaufkommen ist eine SAS Disk mit einer Umdrehungsgeschwindigkeit von 10 krpm oder
eine SATA Disk mit 7200 rpm ausreichend.
Alle Systeme besitzen »onboard« LAN-Controller vom Typ »Broadcom NetXtreme GigE« mit 5708C oder
5715S Chip. Für den Vergleich zwischen Broadcom und Intel wird zusätzlich ein »Intel PRO/1000 PT Quad
Port LP« Server Adapter verwendet.
Bewertet wird die Boot-Dauer beginnend von dem über F12 erreichbaren Boot-Menü bis zum Erscheinen
des Windows Login-Bildschirms. In der Boot-Zeit nicht enthalten ist also die Zeit vom Einschalten des
Systems per Power-Taster bis zum Erscheinen des Boot-Menüs, da diese zwar bei unterschiedlichen
Systemen und bei unterschiedlicher Hardware-Ausstattung variiert, die Abweichung aber bei dem gleichen
System bei allen Anschlussarten identisch ist. Diese »pre boot«-Zeit wird bestimmt durch
Initialsierungsarbeiten des Board Management Controllers (BMC) und des BIOS und der eventuell
vorhandenen Controller. Sie beträgt bei den untersuchten Systemen zwischen 60 und 80 Sekunden.
Die Dauer des lokalen Boots wurde mit der Stoppuhr gemessen. Die Feststellung der iSCSI Boot-Dauer
erfolgte ebenfalls handgestoppt, wird aber ergänzt durch eine Performance-Monitor-Aufzeichnung des DiskDurchsatzes der FibreCAT NX40 S4. Damit werden die zu transportierende Datenmenge und deren zeitliche
Verteilung ermittelt.
Seite 10 (18)
White Paper
Local Boot und iSCSI Boot im Vergleich
Die in der folgenden Grafik dargestellten Boot-Zeiten bestätigen die Erwartung, dass ein Boot über eine
iSCSI-Verbindung mehr Zeit braucht als ein Boot von der lokalen Festplatte.
Der iSCSI Boot benötigt zwischen Faktor 1.3 und 1.9 mehr Zeit als der lokale Boot. Die längste gemessene
Boot-Zeit lag bei 80 Sekunden. Das scheint tolerierbar zu sein, zumal Boot-Vorgänge für einen Server nicht
zur Regelanwendung gehören. Die schon beim lokalen Boot unterschiedlichen Boot-Zeiten der
verschiedenen PRIMERGY Systeme sind in der unterschiedlichen Hardware, deren Erkennung und dem
damit einhergehenden unterschiedlich hohen Datenaufkommen begründet.
Der lokale Boot der PRIMERGY BX620 S4 von einer 10 krpm SAS-Disk benötigt ca. 34 Sekunden,
gemessen vom Verlassen des Boot-Menüs bis zum Erscheinen der Login-Aufforderung. Für die gleiche
Strecke braucht der iSCSI Boot der PRIMERGY BX620 S4 von einer FibreCAT NX40 S4 ca. 51 Sekunden.
Wie die folgende Grafik zeigt, werden dazu ca. 90 MB Daten transportiert, verteilt über 17 Sekunden DiskAktivitäten, wobei 97% der Zugriffe Leseaufträge sind. Die Blockgrößen bewegen sich zwischen 4 und
16 kB. Die Datenmenge und -verteilung ist absolut unkritisch bei Verwendung einer 1-GbE-Verbindung, die
unidirektional ca. 117 MB in der Sekunde bewältigen kann. Theoretisch könnten in den 50 Sekunden ca. 50
Boot-Vorgänge parallel ablaufen.
Seite 11 (18)
White Paper
Der lokale Boot der PRIMERGY RX300 S4 von einer 10 krpm SAS-Disk braucht ca. 47 Sekunden. Der
iSCSI Boot der PRIMERGY RX300 S4 von einer FibreCAT NX40 S4 benötigt ca. 62 Sekunden. Wie obige
Grafik zeigt, muss die FibreCAT NX40 S4 dazu ca. 105 MB Daten liefern, verteilt über 18 Sekunden DiskAktivitäten.
Der lokale Boot der PRIMERGY TX200 S4 von einer 7200 rpm SATA-Festplatte dauert ca. 42 Sekunden,
während der iSCSI Boot von einer FibreCAT NX40 S4 ca. 81 Sekunden braucht. Wie obige Grafik zeigt,
muss die FibreCAT NX40 S4 dazu ca. 80 MB Daten liefern, verteilt über 20 Sekunden Disk-Aktivitäten.
Auffällig bei diesem PRIMERGY System ist die im Vergleich zu den anderen Systemen lange »Denkzeit«
nach der ersten Disk-Aktivität.
Die Datenmengen und deren zeitliche Verteilung sind absolut unkritisch bei Verwendung einer 1-GbEVerbindung. Theoretisch könnten in den 50 Sekunden ca. 50 Boot-Vorgänge parallel ablaufen.
Seite 12 (18)
White Paper
32-bit/64-bit Windows Server 2003 im Vergleich
Der Vergleich der Boot-Dauer einer 32-bit gegenüber einer 64-bit Windows Server 2003 Installation zeigt,
dass sowohl der lokale als auch der iSCSI Boot einer 64-bit Installation etwas länger dauert. Dies ist in der
größeren Datenmenge und in der Hardware-Erkennung des 64-bit Boot Loaders begründet.
Der lokale Boot der 32-bit-Installation braucht ca. 34 Sekunden. Der iSCSI Boot der 32-bit-Installation dauert
ca. 51 Sekunden. Wie die folgende Grafik zeigt, muss die FibreCAT NX40 S4 dazu ca. 90 MB Daten liefern,
verteilt über 17 Sekunden Disk-Aktivitäten.
Der lokale Boot der 64-bit-Installation braucht ca. 49 Sekunden. Der iSCSI Boot der 64-bit-Installation dauert
ca. 66 Sekunden. Wie die obige Grafik zeigt, muss die FibreCAT NX40 S4 dazu ca. 133 MB Daten liefern,
verteilt über 30 Sekunden Disk-Aktivitäten.
Die beobachteten Datenmengen und deren zeitliche Verteilung sind absolut unkritisch bei Verwendung einer
1-GbE-Verbindung.
Seite 13 (18)
White Paper
LAN-Adapter von Broadcom und Intel im Vergleich
Der Vergleich der Boot-Dauer zwischen den LAN-Adaptern von Broadcom und Intel zeigt nur minimale
Differenzen, sie ist praktisch gleich.
Der iSCSI Boot mit dem Broadcom LAN-Adapter dauert ca. 81 Sekunden. Wie die folgende Grafik zeigt,
muss die FibreCAT NX40 S4 dazu ca. 80 MB Daten liefern, verteilt über 20 Sekunden Disk-Aktivitäten.
Der iSCSI Boot mit dem Intel LAN-Adapter dauert ca. 79 Sekunden. Wie obige Grafik zeigt, muss die
FibreCAT NX40 S4 dazu ca. 96 MB Daten liefern, verteilt über 40 Sekunden Disk-Aktivitäten. Auffällig ist hier
der geringe Durchsatz bei den anfänglichen Disk-Aktivitäten. Dafür ist die anschließende »Denkzeit«
geringer. Die Unterschiede zwischen den Adaptern bezüglich der Datenmenge und der verbrauchten Zeit
sind dadurch zu erklären, dass die Controller zu Beginn der Boot-Phase die Rolle des iSCSI Initiators
besitzen. Diese Rolle geben sie im Verlauf des Boot-Vorganges an den Software iSCSI Initiator des
geladenen Betriebssystems ab. Wann dies genau geschieht, ist von außen nicht erkennbar. Außerdem
müssen sie für den »normalen« Betrieb nach dem Boot-Vorgang mit Treiber-Software versorgt und
initialisiert werden. Die Datenmengen und deren zeitliche Verteilung sind absolut unkritisch bei Verwendung
einer 1-GbE-Verbindung.
Seite 14 (18)
White Paper
Messumgebung
Die in diesem Dokument vorgestellten Messergebnisse wurden mit folgenden Hardware- und SoftwareKomponenten ermittelt:
PRIMERGY BX620 S4
2 × Quad-Core
2.83 GHz, 1 × SAS Disk 36 GB 10 krpm
PRIMERGY RX300 S4
2 × Quad-Core
3 GHz,
1 × SAS Disk 36 GB 10 krpm
PRIMERGY TX200 S4
2 × Dual-Core
3 GHz,
1 × SATA Disk 150 GB 7.2 krpm
FibreCAT SX40
als Direct Attached Storage-System (DAS, 3 Gb/s)
FibreCAT SX80
als Fibre-Channel Storage-System (FC, 4 Gb/s)
FibreCAT NX40 S4
als iSCSI Storage-System (iSCSI, 1 Gb/s)
Das Storage-System wurde für die Messungen entweder direkt über den SAS-Controller oder über FibreChannel oder über iSCSI angeschlossen. Für die Anbindung der Server an das iSCSI Storage-System
wurde die Boot-Version des Microsoft Software-Initiator eingesetzt.
Damit das Storage-System nicht zum Leistungsengpass wird, wurde es mit zwölf Festplatten für die
durchgeführten Messungen ausreichend dimensioniert und als zwei für dieses Szenario übliche RAID 5
Festplattenverbände konfiguriert. Es wurden der Datendurchsatz, die Antwortzeit und die CPU-Belastung
des Servers bei unterschiedlichen Zugriffsmustern und Blockgrößen ermittelt.
Als Messinstrument für die Ermittlung der Festplattendurchsätze wurde Iometer eingesetzt. Iometer ist ein
Projekt bei http://SourceForge.net und wird von einer Gruppe internationaler Entwickler weiterentwickelt und
auf verschiedene Plattformen portiert. Das Programmpaket besteht aus einer grafischen Bedieneroberfläche
für Windows Systeme und dem so genannten »dynamo«, der für verschiedene Plattformen verfügbar ist.
Diese beiden Komponenten können unter »Intel Open Source License« von http://www.iometer.org/ oder
http://sourceforge.net/projects/iometer herunter geladen werden.
Mit Iometer hat man die Möglichkeit, das Verhalten realer Anwendungen bezüglich der Zugriffe auf StorageSysteme nachzubilden. Dazu kann man unter anderem die zu verwendende Blockgröße, die Art des Zugriffs
wie sequentielles Lesen oder Schreiben, wahlfreies Lesen oder Schreiben und auch Mischungen davon
konfigurieren. Als Ergebnis liefert Iometer eine Textdatei mit durch Komma separierten Werten (.csv)
wesentlicher Kenngrößen wie z.B. »Durchsatz pro Sekunde«, »Transaktionen pro Sekunde« und
»durchschnittliche Antwortzeit« für das jeweilige Zugriffsmuster. Auf diese Weise kann man die
Leistungsfähigkeit verschiedener Storage-Systeme oder, wie für dieses Dokument beabsichtigt, die
Leistungsfähigkeit der verschiedenen Anschlussarten an die Server ermitteln.
Als weiteres Messinstrument wurde der zum Umfang eines Windows Betriebssystem gehörende
Performance-Monitor eingesetzt. Damit wurden zusätzliche Leistungsdaten hinsichtlich des Verlaufs einer
Messung gewonnen.
Seite 15 (18)
White Paper
Tabelle der verwendeten Komponenten:
Blade Server
PRIMERGY BX620 S4
BIOS
08.00.12 Rev.3A25.2571, 2/1/2008
CPU Type
2 × Quad-Core Intel Xeon E5440, 2.83 GHz
Memory
4 × 2 GB DDR2-667 ECC DDR2 SDRAM FB-DIMM
Disk Controller
LSI Adapter, SAS 3000 series, 8-port with 1068 -StorPort
Disk Driver
lsi_sas.sys, 1.27.3.0
Hard Disk SAS, 2½", 10 krpm
Seagate ST936701SS, 36 GB
LAN Controller
Broadcom NetXtreme BCM 5715S
Betriebssystem
Windows Server 2003 Enterprise Edition mit Service Pack 2
iSCSI Initiator
Microsoft iSCSI Initiator Service Version 5.2.3790.3273
Messwerkzeug
Iometer 2006.07.27
Rack Server
PRIMERGY RX300 S4
BIOS
Phoenix 4.06 Rev. 1.01.2519, 2/5/2008
CPU Type
2 × Quad-Core Intel Xeon X5365, 3 GHz
Memory
4 × 1 GB DDR2-667 ECC DDR2 SDRAM FB-DIMM
Disk Controller
RAID 5/6 SAS based on LSI MegaRAID
Disk Driver
msas2k3.sys, 2.20.0.32
Hard Disk SAS, 2½", 10 krpm
Seagate ST936701SS, 36 GB
LAN Controller
Broadcom NetXtreme BCM 5708C
Betriebssystem
iSCSI Initiator
Messwerkzeug
Iometer 2006.07.27
Tower Server
PRIMERGY TX200 S4
BIOS
Phoenix 4.06 Rev. 1.01.2509, 2/5/2008
CPU Type
2 × Dual-Core Intel Xeon 5160, 3 GHz
Memory
8 × 512 MB DDR2-667 ECC DDR2 SDRAM FB-DIMM
Disk Controller
RAID 5/6 SAS based on LSI MegaRAID
Disk Driver
msas2k3.sys, 2.20.0.32
Hard Disk SATA, 3½", 7.2 krpm
Seagate ST3160812AS, 160 GB
LAN Controller
Broadcom NetXtreme BCM 5708C
Intel PRO/1000 PT Quad Port LP Server Adapter
Betriebssystem
iSCSI Initiator
Messwerkzeug
Iometer 2006.07.27
Storage-System
FibreCAT NX40 S4, 12 × HD SAS, 3½", 15 krpm, 146 GB
FibreCAT SX80, 12 × HD SAS, 3½", 15 krpm, 146 GB
FibreCAT SX40, 12 × HD SAS, 3½", 15 krpm, 146 GB
Seite 16 (18)
White Paper
Fazit
Zusammenfassend kann gesagt werden, dass iSCSI mit dem hier untersuchten Software-Initiator aus
Performance-Sicht durchaus als Alternative zu anderen Anschlussarten eingesetzt werden kann, solange ein
System nicht schon im oberen Belastungsbereich betrieben wird und die Begrenzung der Durchsatzmenge
einer 1-GbE-Verbindungsrichtung von ca. 117 MB pro Sekunde akzeptabel ist.
Beim Einsatz von 10-GbE-Verbindungen werden die jetzigen Durchsatzbegrenzungen sicherlich
aufgehoben. Es muss natürlich, unabhängig von der Anschlussart, sichergestellt sein, dass das StorageSystem für die durch die Anwendung benötigten I/O-Raten ausreichend dimensioniert ist.
Der Vorteil eines SAN Boots, hier eines iSCSI Boots, liegt in der Möglichkeit der zentralen Verwaltung der
Boot-Medien. Die Dauer eines Boot-Vorganges sollte demgegenüber in den Hintergrund treten. Bei Servern,
die annähernd 24 Stunden an 7 Tagen in der Woche verfügbar sind, spielt die Boot-Dauer dann eine
untergeordnete Rolle, wenn sie für wartungsbedingte Boot-Vorgänge in einem akzeptablen Zeitrahmen liegt.
Dabei wird die Boot-Dauer nur in zweiter Linie durch den Transport der zu ladenden Datenmenge bestimmt,
in erster Linie sind die Denkzeiten des Boot Loaders (Erkennung der Hardware und ähnliches) prägend für
den notwendigen Zeitaufwand und diese Denkzeiten treten selbstverständlich auch beim »local Boot« auf.
Die beobachteten Datenmengen und deren zeitliche Verteilung sind absolut unkritisch bei Verwendung einer
1-GbE-Verbindung. Theoretisch könnten in einer beobachteten Boot-Dauer von 50 Sekunden ca. 50 BootVorgänge parallel ablaufen.
Unter Windows Server 2003 mit dem Microsoft iSCSI Software-Initiator wird der Anschluss einer lokalen
Festplatte für die temporären Betriebssystemdaten (Pagefile) empfohlen. Die Zugriffe des Betriebssystems
auf seine »remote« liegenden Systemdateien sind im Verhältnis zu den gemessenen maximalen
Datendurchsätzen unerheblich.
Seite 17 (18)
White Paper
Literatur
Allgemeine Informationen zu Produkten von Fujitsu Technology Solutions
http://de.ts.fujitsu.com
Allgemeine Informationen zur PRIMERGY Produktfamilie
http://www.primergy.de
PRIMERGY Benchmark - Performance Reports und Sizing Guides
http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html
Informationen von Microsoft zu iSCSI
http://www.microsoft.com/windowsserversystem/storage/technologies/iscsi/default.mspx
Internet Engineering Task Force
http://www.ietf.org/
Informationen über Iometer
http://www.iometer.org/
Kontakt
PRIMERGY Performance und Benchmarks
mailto:primergy.benchmark@ts.fujitsu.com
PRIMERGY Produkt Marketing
mailto:Primergy-PM@ts.fujitsu.com
Lieferung vorbehaltlich Verfügbarkeit, technische Änderungen ohne
Vorankündigung möglich, Korrektur von Irrtümern und Auslassungen
vorbehalten.
Alle angegebenen Konditionen (TCs) sind empfohlene Einstandspreise in
Euro ohne MwSt. (sofern im Text nicht anderweitig angegeben). Sämtliche
verwendete Hardware- und Software- Namen sind Handelsnamen und/oder
Warenzeichen ihrer jeweiligen Hersteller.
Copyright © Fujitsu Technology Solutions GmbH 2009
Herausgegeben durch:
Internet:
http://ts.fujitsu.com/primergy
Enterprise Products
PRIMERGY Server
PRIMERGY Performance Lab
mailto:primergy.benchmark@ts.fujitsu.com
Extranet:
http://partners.ts.fujitsu.com/com/products/serv
ers/primergy

Performance Report

Transcription

Similar documents

Videorechner nach Maß

Bereitstellung von Microsoft Private Cloud auf Hitachi Unified Storage

TI- Übung 5 Speicher – Typen Speicher – SRAM Speicher – DRAM

RAID-Controller Performance 2013

RAID-Controller für PRIMERGY

Sachunterricht - Conen-GmbH

Leben in afrika annika - Sachunterricht Petersen

Mai 2013 - Alt-Schmargendorf

Diplomarbeit