Die Datenmenge in Unternehmen wächst unaufhaltsam und auch deren notwendige Verfügbarkeit steht längst außer Frage. Deshalb befasst sich IT-Administrator im ... (mehr)

Performance-Messung

Zu Demonstrationszwecken begnügen wir uns in diesem Artikel mit der Installation von openATTIC auf zwei virtuellen Maschinen. In einem produktiven Szenario läuft openATTIC aber natürlich direkt auf Hardware-Systemen, die einen großen Speicherbereich bestehend aus Software-RAID 0 über genau zwei oder vier Instanzen Hardware-RAID 5 benutzen. Dieser Aufbau kombiniert ideal die Caching-Möglichkeiten der Hardware, die Flexibilität von LVM und die Performance eines korrekt durchgeführten Disk Alignments.

Listing 3: Pacemaker für Volumes



root@oa01:~$ crm configure
crm(live)configure# primitive drbd_vms01 ocf:linbit:drbd \
    params drbd_resource="vms01" \
    op start interval="0" timeout="240" \
    op stop interval="0" timeout="100"
crm(live)configure# ms ms_drbd_vms01 drbd_vms01 \
    meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true"
crm(live)configure# primitive fs_vms01 ocf:
      heartbeat:Filesystem \
    params device="/dev/drbd/by-res/vms01" \ directory="/media/vms01" fstype="xfs" \
    op monitor interval="10s" timeout="20s" \
    op start interval="0" timeout="60" \
    op stop interval="0" timeout="60"
crm(live)configure# primitive ip_vms01 ocf:
     heartbeat:IPaddr2 \
    op monitor interval="10s" timeout="20s" \
    params ip="172.16.14.252" nic="eth0" cidr_netmask="24"
crm(live)configure# primitive export_vms01
     ocf:heartbeat:exportfs \
    params fsid="2" directory="/media/vms01" \ options="rw,no_subtree_check,no_root_squash" \clientspec="172.16.14.0/24" \unlock_on_stop="true" \
    op monitor interval="10s" \
    op start interval="0" timeout="60" \
    op stop interval="0" timeout="180" \
    meta target-role="Started"
crm(live)configure# group vms01 fs_vms01 export_vms01 ip_vms01
crm(live)configure# colocation vms01-on-drbd_vms01 \inf: vms01 ms_drbd_vms01:Master
crm(live)configure# order drbd_vms01-then-vms01 \ inf: ms_drbd_vms01:promote vms01:start
crm(live)configure# commit
crm(live)configure# exit

Damit die genannten Eigenschaften garantiert sind, ist bei der Beschaffung der Hardware einiges zu beachten:

- Durch die Replikation schränkt das langsamste System die Performance des gesamten Clusters ein, daher werden zwei baugleiche Systeme benötigt.

- Jedes System muss entweder über genau 12 oder 24 Disks verfügen, da das RAID auf diese Zahlen ausgelegt ist.

- Wer ein System mit 12 Disks benutzt und noch weitere Slots zur Verfügung hat, fügt am besten noch zwei Disks hinzu, die als Hot Spares bereitstehen.

- Die Systeme müssen mit einem Hardware-RAID-Controller mit BBU oder Flash-Zwischenspeicher ausgestattet sein.

- Zwischen den openATTIC-Systemen sollte eine GBit-Direktverbindung für die Cluster-Kommunikation und die Datenreplikation zur Verfügung stehen.

- Die Systeme nutzen ihr RAM als Lese-Cache, daher sollten zwischen 12 und 128 GByte RAM pro System verbaut sein.

Um die Performance des Systems zu messen, nutzen wir ein System, das die genannten Kriterien erfüllt und mit dem beschriebenen Setup konfiguriert wurde. Dazu erstellen wir eine virtuelle Maschine mit Windows Server 2008, die über eine leere zweite Disk verfügt. Die Images liegen beide in dem hochverfügbaren Speicherbereich, bereitgestellt durch openATTIC. Auf dem zweiten Speicherbereich lassen wir nun den Performance-Tester HPCreateData [3] laufen.

HPCreateData erstellt in einem Verzeichnis auf einem Windows-Dateisystem Dateien von kleiner bis moderater Dateigröße und beschreibt sie mit Zufallsdaten, wie sie beispielsweise von einer Datenbank oder einem Mailserver stammen könnten. Dadurch wird ein Lastverhältnis simuliert, das der Praxis deutlich näher kommt als ein einfacher Test mit "dd", der nur sequenziell riesige Datenmengen auf die Platte schreiben würde.

Bild 4: Der Aufbau von openATTIC als Storage-Backend.

Die maximale Geschwindigkeit in diesem Szenario wird begrenzt durch die GBit-Verbindung zwischen dem Virtualisierungshost und den openATTIC-Systemen und liegt daher bei 125 MBit/s. Um Caching-Effekten vorzubeugen, haben wir den Test mehrfach laufen lassen. Der erste Durchlauf erreicht einen durchschnittlichen Durchsatz von 147,02 MBit/s und liegt damit über dem theoretischen Maximum. Das kommt daher, dass der ESX-Host zu Beginn nur in seine Caches schreibt. Sind sie gesättigt, kann die VM nur noch mit der maximalen Bandbreite des Netzwerks schreiben. In diesem Fall erreicht der Test 113 MBit/s oder 90 Prozent der maximal möglichen Bandbreite. Für zufällige Schreiboperationen ist das mehr als zufriedenstellend: Es zeigt, dass nicht die Performance des Storage-Systems der limitierende Faktor ist, sondern die Bandbreite des Netzwerkes. Mit einer 10 GBit-Ethernet-Verbindung lassen sich diese Raten daher bei Bedarf sogar noch steigern.

Fazit

Die Architektur von openATTIC berücksichtigt von Grund auf die Möglichkeit, openATTIC als Hochverfügbarkeitscluster betreiben zu können. Dieses Konzept zahlt sich aus: Nicht nur ist es problemlos möglich, eine Konfiguration wie in diesem Artikel beschrieben aufzubauen, die ein Storage-System auf Enterprise-Niveau bereitstellen kann. Das dargestellte System liefert auch eine Performance, die den Anforderungen an den Betrieb einer virtualisierten Infrastruktur gerecht wird. Leider ist die Konfiguration der Hochverfügbarkeit momentan noch nicht über die openATTIC-Oberfläche möglich und muss mühsam über die Kommandozeile erfolgen. Dieser Punkt steht jedoch bereits auf der Roadmap des Projekts und soll in nächster Zeit angegangen werden.

openATTIC wird seinem Versprechen also gerecht, eine unternehmenstaugliche Storage-Plattform für virtualisierte Infrastrukturen bereitzustellen. Das ist jedoch nicht der einzige Einsatzzweck: openATTIC unterstützt auch den Betrieb als zentrale Dateiablage innerhalb einer Windows-Domäne vollständig, und es lassen sich sogar beide Betriebsmodi innerhalb eines Systems realisieren. Das automatische Monitoring erfasst tiefgehende Messdaten und erlaubt dadurch, Performance-Probleme gezielt zu analysieren und zu beheben.

(jp)

Michael Ziegler und Tatjana Dehler sind Consultants bei der it-novum GmbH.

Link-Codes

[1] openATTIC: http://openattic.org/

[2] STONITH Story: http://ourobengr.com/stonith-story/

[3] HPCreateData: http://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?spf_p.tpst=kbDocDisplay&spf_p.prp_kbDocDisplay=wsrp-navigationalState%3DdocId%253Demr_na-lpg50460-13%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken#hpcreatedata/

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

openATTIC 1.2.0 veröffentlicht

Die freie Storage-Lösung openATTIC wurde in einer neuen Version veröffentlicht, die das Management von Snapshots  verbessert.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020