Slow RDP on Pulseway

Something that doesn’t show up anywhere in combination with a Pulseway monitoring sytem, sometimes the RDP session can be slow as snail OS.

What happened, a new server was set up to monitor client server and with some, trying to log into the server through the Pulseway Remote Desktop Client either was very slow, or it just hung at waiting for a screen update forever.

A colleague was investigating the issue together with support from Pulseway, who suspected the cause was the reverse proxy. The server had been moved directly behind the local router and the issue still persisted.

While having a look at it myself I discovered if I restricted RDP features on server side the session improved a little. Looking further I noticed the Pulseway client connects to the server console, not a standard Windows RDP session.
Something that I haven’t had to do in years fixed this issue, namely turning off graphic hardware acceleration. (right click desktop, click screen resolution, the link to advanced settings, tab troubleshooting and slide the slider all the way to the left.

The sessions were suddenly as fast as a normal RDP session.

This thing hasn’t been documented anywhere, so hopefully it’ll help if anyone who has the same slow RDP client sessions on other remote monitoring or shared desktop software like Teamviewer and ISL.

Write Adobe Lightroom catalogs to a network share

To work around the restriction of Adobe Lightroom refusing to write catalogs on a network share (for Windows PC);

• Connect the share as a normal network share on the Windows PC; for example drive letter Z:
• Create the desired directory on the share; for example Z:\Lightroom
• in a command promtp run subst x: z:\lightroom (or any free drive letter)
• Now you can create a new catalog on X:

The command subst x: z:\lightroom can be made as a shortcut, or even set up as a logon script in the start menu for all or single users.

 

Flexible fileserver on Debian Stretch

Finally getting around to reinstall my fileserver, I wanted to make it flexible with data integrity.
ZFS wasn’t flexible enough for my tastes, and LVM has no integrity check, so I had to create something with btrfs.

Early tests with using btrfs on LVM for root and /boot made the virtual machine unbootable, but using btrfs directly was no problem.
This meant I still had to use separate partitions for /boot, root, and swap (on mdraid10), and then use the rest for LVM.

It seems the installation of Stretch has trouble when adding raid or lvm afterwards, so I partitioned the installation this way:

vda1, 512M, bootable, btrfs, /boot
vda2, 4096M, btrfs, /
vda3, 512M, device for raid (to be made swap after creating raid10 after installation)
vda4, LVM
LVM:
vg0: vda4, vdb4, vdc4
lv’s:
tmp_0, 512M, btrfs, /tmp
home_0, 1024M, btrfs, /home
var_0, 1024M, btrfs, /var

After installation I created the same partitions for vdb and vdc, then created the mdraid10 for swap:
mdadm –create –run /dev/md99 –level=10 –layout=n2 raid-devices=3 /dev/vda3 /dev/vdb3 /dev/vdc3
mkswap /dev/md99

With that done I exchanged all /dev/mapper devices for the UUID’s of the btrfs devices in /etc/fstab and did a reboot as test.

With everything running I created logical volumes tmp_1, tmp_2, home_1, home_2, etc. by specifying the different physical devices to be put on:
lvcreate -L 512M -n tmp_1 vg0 /dev/vdb4
lvcreate -L 512M -n tmp_2 vg0 /dev/vdc4
…

Adding the LV’s to btrfs:
btrfs device add -f /dev/mapper/vg0-tmp_1 /dev/mapper/vg0-tmp_2 /tmp
btrfs device add -f /dev/mapper/vg0-home_1 /dev/mapper/vg0-home_2 /home
…
btrfs balance start -dconvert=raid1 -mconvert=raid1 /tmp
btrfs balance start -dconvert=raid1 -mconvert=raid1 /home
…

For unimportant data I made a logical volume striped across the three disks:
lvcreate -L xxG -n roraid -i 3 vg0
mkfs.ext4 /dev/mapper/vg0-noraid (could also be btrfs but the data integrity isn’t important here.
..and added its UUID to fstab with mountpoint /data/noraid

For the data protected with checksum integrity:
create three LV’s raid1_0, 1, 2 on the three PV’s like /tmp, /home, etc. above and make another btrfs raid of these.

Last, don’t forget to grub-install /dev/vdb and /dev/vdc.

The /data/raid1 mount point caused an error after first reboot, but later no more. Maybe a glitch in the matrix..

With this setup I can expand /tmp, /home, /var, /data/noraid and /data/raid1 as needed since I don’t know if I get more data for raid or not.
With two fileservers I can keep a backup of the raid1 data of one server on the noraid volume of the other. The btrfs volumes only protect from bit rot after all.

And if it really fills up I can start exchanging the disks for bigger ones.

 

Maak IT weer simpel

IT wordt weer te gecompliceerd gemaakt.
Sinds jaren is de focus in de IT steeds meer naar marketing voor nieuwe kleurtjes en ikoontjes gegaan in plaats van hetgene waar het werkelijk om gaat; een betrouwbaar en goed te onderhouden infrastructuur.

De UNIX filosofie van maak een programma wat 1 ding doet, maar goed doet lijkt tegenwoordig ver te zoeken in de commerciele wereld van IT. Daar is de open source wereld een stuk beter in en dat is ook te merken aan de software die meer waarde hecht aan stabiel draaien dan aan knoppen inbouwen die voldoen aan de laatste hype maar niks opleveren.

Eén van de dingen die me laatst opviel; dynamisch geheugen toewijzen aan een Windows 7 machine kan alleen met de dure Enterprise en Ultimate versies onder Hyper-V. Een installatie onder Proxmox VE met virtio drivers loopt als een trein met alle versies van Windows 7, en is nog snel ook, soms zelfs sneller dan onder Hyper-V lijkt het.

Met elke nieuwe versie van Windows sinds 2000 werd steeds meer ruimte op het scherm verspild met loze witte ruimte of onnodige links die met de rechter muisknop al beschikbaar waren (zie vooral de mmc consoles en zeker de IIS console waar het taak gedeelte niet uitgezet kan worden).
Informatie over een update is pas te krijgen na het doorlopen van enkele nietszeggende meldingen (Ik kijk naar jou, Windows Update! Neem een voorbeeld aan package managers van Linux distros!).

Het ergste zijn de interfaces van programmas en websites die de nieuwste waanideeën volgen als brave leden van de kudde.
Zoeken van functies in een “ribbon interface” is een hels karwei, en de oplossing is een zoekveld geworden (yay Office 2016!). Iedereen die met een computer kan werken, kan lezen. Tekst in een logische menustructuur werkt het snelste!
Technische websites die ineens met koeieletters en gigantische knoppen uitgerust worden hebben ook nooit naar de browserversies gekeken van hun bezoekers. Drivers worden niet gedownload op een tablet of mobiele telefoon, dat wordt op een PC gedaan met een browser die niet gelijk eruit hoeft te zien alsof die website gemaakt is voor slechtzienden! Het is al erg genoeg dat de standaard voor een Windows bureaublad eruitziet als een scherm voor peuters die niet kunnen lezen.

Een computer is ook een stuk gereedschap, geen reclame en entertainment centrum.
De normale gebruiker wil de computer starten en met die programmas werken die hij of zij nodig heeft, zonder allerhande afleiding door onnodige meldingen over geslaagde updates van anti-virus of nieuwe versies van programmas. Die dingen moeten pas tevoorschijn komen in de programmas zelf wanneer die draaien. En dan ook alleen als een simpele melding en niet als een enorme audiovisuele presentatie.
Afgezien van de rust die overstappen op FreeBSD en GNU/Linux (voornamelijk Debian) jaren geleden heeft opgeleverd, is het gebruik van een GUI zoals fluxbox waarbij ik na opstarten alleen een blanco scherm heb en met een toetsencombinatie ten alle tijden het menu kan oproepen.
Geen afleiding, alleen die dingen die op dat moment nodig heb, en zeker geen ballonnetjes met onzin van ADHD programmas als ik net een goede film of serie in volledig scherm aan het kijken ben.

Het toenemende gebruik van adblockers geeft ook aan dat de mensen steeds meer vechten tegen de overheersende cultuur van schreeuwende advertenties. Het is ook niet voor niks dat streaming media zoals Netflix en HBO steeds geliefder is dan de ouderwetse commercieele zenders.
Het zoeken en lezen op internet wordt een steeds meer vermoeiende aangelegenheid. Google werd groot omdat zij een simpele pagina met resultaten voorschotelden ten opzichte van de grote zoekmachines van die tijd. Nu zijn door onder andere het privacy vraagstuk en filter/search bubbles zoekmachines zoals Duckduckgo een stuk populairder geworden, en deze zien er weer uit zoals het vroeger was; simpel en overzichtelijk.
Dit alles draagt bij aan de huidige information overload en onoverzichtelijkheid van de infrastructuur achter inter- en intranetwerk. Het is geen wonder dat de huidige generatie die uit de IT opleiding gerold komt problemen heeft om een beeld te krijgen van het netwerk zogauw er ergens een storing is.

IT moet weer simpel opgezet worden, overzichtelijke programmas die 1 taak hebben en als nodig in een batch gecombineerd kunnen worden met logging die als normale tekst gelezen en verwerkt kan worden.
Interfaces die duidelijke en summiere tekst geven met een paar kleuren, waarbij meer informatie met 1 klik of commando opgehaald kan worden.
Zinnige informatie zonder dezelfde marketing bullshit die iedereen spuit. En zeker zonder een hoop grote slideshows of videos die alleen maar bandbreedte, geheugen, en CPU tijd kosten als daar niet om gevraagd wordt.

 

Een verschil van dag en nacht

Het is nu de eerste zondag van het jaar, en de eerste dag voor het begin van een nieuwe en hopelijk permanente manier van leven.
Wat de laatste jaren hebben aangetoond is leven met vertraagde slaapfasesyndroom en diepgaande kennis van IT niet samengaan op termijn. Elke ochtend tegen de interne klok vechten en stress van onverwachte en lastige problemen (nee, de term uitdagingen wordt alleen gebruikt door degenen die het probleem niet op hoeven te lossen) oplossen bracht uiteindelijk mijn energieniveau tot onder nul en leverde concentratie en korte termijngeheugen problemen op.

Ik ben nooit een vroeg mens geweest (zelfs mijn geboorte was pas om elf uur ‘sochtends), en kan me weinig dagen herinneren dat ik vroeg opstond en wakker was. Van mijn schooltijd kan ik me nauwelijks iets herinneren, waarschijnlijk omdat ik niet echt wakker was in die tijd alhoewel ik toch hoge punten scoorde.
In de tijd dat ik in productie werkte moest ik doordeweeks om zeven uur beginnen, maar omdat het geen complex denkwerk maar zwaar physiek werk was (het was echt bodybuilding voor mij) kon ik het volhouden tot het weekend waarbij ik dan tot vroeg in de middag uitsliep.
De periode van werken als systeembeheerder daarna was goed te doen door de verdeling van werk en het feit dat ik pas om half tien begon en andere collegas om acht uur. Het was een normale zaak dat ik als laatste vertrok daar, maar dat was geen probleem voor mij. Het ging fout toen er besloten werd dat wij vanaf zeven uur ‘sochtend beschikbaar moesten zijn en iedereen in een soort van ploegendienst moest draaien. De weken dat ik vroeg begon waren niet plezierig, zeker niet na een paar dagen. Ik wisselde ook graag van dienst met een collega die ook veel liever vroeg begon en op tijd naar huis kon.

In al die tijd bleef één ding hetzelfde, ik ging pas laat slapen.
Al vroeg vond ik het fijn om laat te blijven lezen. Later kwam daar de creativiteit van Lego en tekenen erbij, en voordat ik professioneel in de IT begon, werken en experimenteren met de computer.
Mijn creativiteit kwam los in de avonduren en ik kon hele nachten doorgaan mits ik niet de volgende dag vroeg weg moest (en zelfs dan was ik nog wel eens zo wakker dat ik de nacht gewoon oversloeg).

Elke verschuiving van de klok naar zomertijd was een verschrikking, en elke keer naar wintertijd was even een verademing. De laatste verschuiving maakte echter de boel nog erger.
De laatste jaren merkte ik dat ik steeds minder sliep in de nacht, de laatste twee jaren was het vier tot vijf uur in de nacht, wat het gevolg had dat ik ongeveer het halve weekend sliep en de andere helft zwaar vermoeid was.
De paar weken vakantie die ik me kon veroorloven (het gevolg van instappen in een eigen bedrijf en ondanks recessie een flinke groei doormaken) begonnen met onregelmatige dagen totdat ik in mijn natuurlijk ritme kwam, wat net een beetje energie opleverde totdat ik weer aan het werk moest.Mijn doordeweekse ritme werd inslapen tussen één en twee uur ‘snachts, dan vier uur later wakker worden en pas een aantal uur daarna weer in slaap beginnen te vallen. Met geluk kon ik dan nog een uurtje meepakken voordat de wekker ging. De laatste maanden kreeg ik zelfs deze kans niet meer, de wekker ging precies op het moment dat mijn tweede slaap zou beginnen. Ik kon mezelf pas steeds later uit bed krijgen van vermoeidheid.
En in al deze tijd was het maar af en toe dat ik vroeg insliep, maar dat was dan ook meteen na het avondeten, en dan werd ik alsnog vier tot vijf uur later weer wakker.

Ik ben altijd geïnteresseerd in wetenschap, en begon rond te kijken naar informatie over slaapgewoontes en leerde dat men nog steeds maar heel weinig weet over slaap. Niet alleen het nut van het slapen, maar ook de manier waarop. Het is niet gegeven dat de gemiddelde zeven tot negen uur per dag in één keer gehaald moet worden. Dat is meer iets van de moderne tijd aangezien het in de middeleeuwen normaal was om twee periodes van slaap te hebben tijdens de nacht.
De verwachting in de moderne tijd is dat men vroeg opstaat en vroeg naar bed gaat, wat het merendeel van de mensen redelijk volhoudt, maar wat tegen de interne klok van veel mensen werkt. Het is al bewezen dat in de jeugdjaren de interne klok naar achteren verschuift tot deze later naar het volwassen ritme terugkeert. Ondanks dat wordt tot geëist van scholieren dat deze kennis vergaren op tijden dat het veel lastiger is om dat voor elkaar te krijgen.

De literatuur bevestigd ook de depressiviteit die ik heb gekregen als gevolg, de constante vermoeidheid vreet aan alle kanten totdat ik gewoon niet meer buiten werk iets aankon in het leven. De minste en geringste negativiteit slaat hard aan, rekeningen, defect aan mijn laptop, storing aan de auto, alles bleef liggen. De vrije dagen sinds kerst lieten me weer een klein beetje in mijn ritme komen en ik voelde ineens weer zin om aan krachttraining te doen, iets waar ik al lange tijd niet meer aan werkte.

Omdat doorgaan zoals voorheen gewoon geen optie meer is, en ik zeker niet van plan ben om afhankelijk te gaan worden van onnodige medicatie, heb ik ook besloten om er mee te stoppen. Vnaf dit jaar ga ik mijn leven zoveel mogelijk indelen naar mijn interne klok. Het operationele IT werk gaat naar de anderen die ik zelf op ga leiden zodat ik me zelf veel meer met consultancy en organisatie op projektbasis kan bezig houden in de middag- en avonduren. De rust die dit gaat geven zal me ook in staat brengen om meer te schrijven op het gebied van IT dingen, maar ook als schrijver van (korte) verhalen in science fiction, fantasy, horror, en andere ideeën die me regelmatig in het hoofd schieten (in het afgelopen jaar ongeveer honderd stukken geschreven onder pseudoniem, met een nog een hele lijst te gaan).

Zoals de slaapexpert Till Roenneberg tijdens een conference uitlegde; een wasmachine wordt niet in zijn cyclus onderbroken omdat men een schone was wil krijgen, waarom vind men het dan wel normaal om de slaapcyclus te onderbreken door een wekker?

No more social jetlag

Social jetlag, the difference between the socially expected sleeping pattern and your true natural pattern is plain bad for your health. In my case, it feels destructive to mine with constant tiredness, bad short term memory and depressive tendencies.
Although they call it a disorder, I believe it’s a natural state since not every living creature is identical to others, and there is no proven definition of a human’s sleeping pattern (sleeping in two parts seemed common in medieval times).

So, after 17 years of working in IT I’m going to choose my health and happiness over social norms before it kills me.
I’m quitting and I’m not going to start my day before noon (emergencies excepted of course) anymore.

Back to creative and productive evenings for me.

Hyper-V – Proxmox

Even een halfslachtige vergelijking van de installatie van Windows server 2008 R2 op een Hyper-V server en een Proxmox host.

De Hyper-V 2012 R2 host draait op een HP ML110 G6, CPU X3430, 16GB RAM en RAID 1 van 500GB disks.
De Proxmox 3.4 host draait op een HP 8400 workstation, CPU Q8400, 8GB RAM en softraid 1 met LVM van 500GB disks

De installatie van server 2008 werd in eerste instantie gedaan met standaard instellingen, IDE disk van 64GB (dynamisch), 1GB RAM, standaard netwerkkaart (MS Hyper-V nic en Intel E1000).

De installatie van 2008 verliep op Proxmox een heel stuk sneller dan op Hyper-V. Zelfs het verschil van installatie met een ISO op een netwerkschijf of van lokale schijf mag dat niet maken.
Dit werd ook duidelijk bij de eerste ronde van Windows update. Tegen de tijd dat de Hyper-V guest de eerste van 90 updates  ging installeren was de Proxmox guest al met de zeventigste bezig.
Een snelle benchmarktest die ik van te voren draaide gaf 96MB/s schrijfsnelheid voor Hyper-V en 66MB/s voor Proxmox (na wijziging naar virtio 72MB/s).

Nu kan er pas na installatie van alle updates (service pack 1) pas de integration services van Hyper-V geïnstalleerd worden, dus is de vraag wat dat nog voor verschil kan maken.

Update:
Na gerommel met drivers en deserver over de rooie gekregen te hebben ben ik die op Proxmox opnieuw gaan installeren. Dit keer liep deze net zo traag met updates als de Hyper-V versie.
Ik had nog even een tweede CPU toegevoegd en wat meer RAM maar het ging niet sneller. Later had ik even wat meer tijd om te kijken en ik zag dat ik de extra cdrom met de driver iso nog actief had staan in de configuratie. Deze was niet meer nodig en ik haalde deze weg na de server weer uitgezet te hebben. Het starten liep vervolgens een stuk sneller. Ook de management onderdelen reageerden sneller.
De traagheid was dus veroorzaakt door een dubble cdrom met geladen iso.

Om te zien of dit ook op Hyper-V verschil maakte heb ik bij die server de cdrom compleet verwijderd, echter gaf dat geen verschil. Dit kan goed te maken hebben met de floppy drive die standaard wordt aangemaakt en alsnog vertraging geeft op het I/O gedeelte.

Thoughts about file location and performance

MyDefrag system scripts put the MFT$ and directories at one third of the size of the disk for better access performance.
Creating a zone of frequently accessed files together also serves as a performance enhancer so the disk takes up less time to get from one file to the other.

Looking at recently accessed files on my laptop show mostly browser cache in /home and system logfiles in /var. The OS files would only be used once at startup, binaries only when starting a program. For a single user system it seems there’s no benefit to optimising the location of files on disk beyond keeping /var and /home close together on disk. (done by using separate partitions for these and using a separate partition for data to keep that out of /home)

On a file server it might benefit to create a data partition of about a third the size of the disk, then a partition for /var, then another partition for data (combining both data partitions through LVM). Then the disk arm would be closer to the files on average, reducing wear and tear.

On a multi user server create the /home partition after / and /var and link the user’s data directories in the profile to a separate data partition.
I’ve done this with Windows terminal servers where I used a separate profiles partition (can be done by modifying the system and moving files in save mode, then creating links of the original directories) after the OS, swap and program files partitions and using policies to link document directories to the the file server (had to be done anyway, otherwise it would have been a larger data partition).
One of the biggest benefits was preventing the OS partition of filling up by users (even local system accounts).
Too bad the Windows profiles directory can’t be linked to a network location like on a *nix machine, creating a NFS link to /home on another server.

Revive old home server

After replacing the failing home server with a decent Synology NAS I got my hands on a HP Storageworks Data Vault X510.

Being curious I wanted to see if I could get it to run with Debian so I could do some tests with mdadm.

Turns out it’s not too difficult.

-place the harddisk to install it on in a standard PC and use that to install the i386 version of Debian (in this case it was Jessie)
-add a fixed IP address for eth0 in /etc/networking/interfaces (the Realtek r8168 (seen as r8169) couldn’t get a DHCP address for some reason)
-place the disk in the X510 and boot
-login with SSH (you did install it, didn’t you?)
-have fun with it

 

korte mdadm RAID test

Even een korte test gedaan na de Debian Jessie installatie op een HP Storageworks Data Vault X510 (voormalige Windows home server).

Ik wilde zelf eens testen wat het verschil in snelheid is in (random) read en write op mdadm RAID0, RAID5, en RAID10 met layout n2, o2, f2.

De 4 disks zijn een Seagate 250GB en 3 80GB Hitachi (IBM Deskstar) schijven die ik kon misbruiken voor de test. Geen hoogvliegers maar voldoende voor mijn test aangezien het niet om maximale snelheid gaat.
Debian is geïnstalleerd op de Seagate in een 64GB partitie met daarachter 3 4GB partities. De overige schijven heb ik ook 3 partities van 4GB gegeven.

Array md5 is een RAID5 van sda, b, c en d5, md0 is een RAID0 van sda, b, c en d7. Partities sda, b, c, d6 gebruikte ik om telkens een RAID10 met afwisseled layout n2, o2, f2 te maken.

Een snelle blik met hdparm -t /dev/sd[abcd] laat een snelheid van 95 MB/sec zien voor de Seagate en 73 MB/sec voor de Hitachi’s.
Met /dev/md0, 5 en 10 kwam het volgende (gemiddeld):
md0: 253 MB/sec
md5: 180 MB/sec
md10 (n2): 137 MB/sec
md10 (o2): 135 MB/sec
md10 (f2): 232 MB/sec

Uit de simpele test met iozone kwam het volgende:

RAID0;
Command line used: iozone -R -b raid0 -f 0/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB            reclen   write      rewrite    random read   random write
1048576   4          256342   261384   2105037        17029

RAID5;
Command line used: iozone -R -b raid5 -f 5/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB            reclen   write      rewrite    random read   random write
1048576   4          123690   125667   2080483         6000

RAID10 –layout=n2;
Command line used: iozone -R -b raid10-n2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB            reclen   write      rewrite    random read   random write
1048576   4          130257   131265   2085801        7990

RAID10 –layout=o2;
Command line used: iozone -R -b raid10-o2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB            reclen   write      rewrite    random read   random write
1048576   4          132550    132746  2077713        8075

RAID10 –layout=f2;
Command line used: iozone -R -b raid10-f2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB            reclen   write      rewrite    random read   random write
1048576   4         119730    116639   2110766         6574

De conclusie uit deze test is dat RAID0 het snelste is met sequential en random write, random read is ongeveer gelijk met RAID0, 5 en 10. RAID10 layout near en offset is ongeveer gelijk aan elkaar en iets sneller met write dan layout far.
Het verschil zal misschien groter worden met grotere partities.

Drie disks

Een hdparm -t test met RAID10, n2 op partities sdb,c, en d6 laat een snelheid van 101 MB/sec zien. De regel n/2 geldt dus ook voor een oneven aantal disks in RAID10.

Iozone laat hierbij het volgende zien:
kB            reclen   write      rewrite    random read   random write
1048576   4         97125       98339     2102168       12869

Opvallend is de hogere snelheid bij random write, waarschijnlijk omdat er nu minder keuze is waar een blok geschreven kan worden op een disk.

Wat bij een RAID10 op 2 disks ook opvalt is dat bij de hdparm test de snelheid gelijk is van een enkele disk terwijl via bwm-ng wel te zien is dat er van beide schijven gelezen wordt.

Iozone test:
kB            reclen   write      rewrite    random read   random write
1048576   4          66043      66612    2103323        8655

Random write zakt nu weer in maar is wel iets sneller dan met 4 disks in raid. Zou een oneven aantal disks in RAID10 effectiever zijn voor gebruik met databases of virtuele machines?

Test met de 3 Hitachi’s in RAID10

Dit is interessant genoeg om eens de drie layout opties te testen met partities van 37GB. De snelheid is drastisch minder vanaf de helft van de disk dus gebruik ik niet de volledige schijf. Dit laat nog eens duidelijk zien dat wanneer snelheid het belangrijkste is, het beter is om niet 100% van de disk te gebruiken. En anders gewoon het geld neerleggen voor SSD’s. :-)
(tijdens de sync ging de snelheid bij 92% ineens heel snel van 67 MB/s naar 37 MB/s, misschien omdat de disks al gedeeltelijk gewist waren?)

(wat ook opviel was dat bij de eerste keer mounten van de array na een ext4 formattering er eerst een hoop disk activiteit is, het lijkt alsof dan pas ext4 echt actief wordt)

Eerst layout n2: hdparm -t kwam met 115 MB/s

iozone:
kB            reclen   write      rewrite    random read   random write
1048576   4           95773     96159    2107576         12528

Met een 4GB testfile is het heel anders:
kB            reclen   write      rewrite    random read   random write
4194304   4            87656    87659     660                 3977

Met 2 threads en 1GB files:
Command line used: iozone -R -b raid10-n2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records

Children see throughput for 2 initial writers = 88541.36 kB/sec
Parent sees throughput for 2 initial writers = 80553.47 kB/sec
Min throughput per process = 43050.47 kB/sec
Max throughput per process = 45490.89 kB/sec
Avg throughput per process = 44270.68 kB/sec
Min xfer = 992792.00 kB

Children see throughput for 2 rewriters = 88290.14 kB/sec
Parent sees throughput for 2 rewriters = 82255.72 kB/sec
Min throughput per process = 44094.47 kB/sec
Max throughput per process = 44195.67 kB/sec
Avg throughput per process = 44145.07 kB/sec
Min xfer = 1046688.00 kB

Children see throughput for 2 random readers = 3989.19 kB/sec
Parent sees throughput for 2 random readers = 3988.93 kB/sec
Min throughput per process = 1779.90 kB/sec
Max throughput per process = 2209.29 kB/sec
Avg throughput per process = 1994.60 kB/sec
Min xfer = 844788.00 kB

Children see throughput for 2 random writers = 6503.86 kB/sec
Parent sees throughput for 2 random writers = 6013.46 kB/sec
Min throughput per process = 3240.41 kB/sec
Max throughput per process = 3263.45 kB/sec
Avg throughput per process = 3251.93 kB/sec
Min xfer = 1041236.00 kB

“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”

” Initial write ” 88541.36

” Rewrite ” 88290.14

” Random read ” 3989.19

” Random write ” 6503.86

Deze keer zat de dual core CPU de meeste tijd in wait state, dus daar zit een beperking, Had niet verwacht dat read langzamer was dan write.

 RAID10,o2

hdparm: 118 MB/sec

iozone 1GB:
kB            reclen   write      rewrite    random read   random write
1048576   4           97665      98451     2093890       12945

iozone 4GB:
kB            reclen   write      rewrite    random read   random write
4194304   4           88329      88755      667               3968

Command line used: iozone -R -b raid10-o2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M

Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records

Children see throughput for 2 initial writers = 88701.92 kB/sec
Parent sees throughput for 2 initial writers = 81542.38 kB/sec
Min throughput per process = 44110.47 kB/sec
Max throughput per process = 44591.45 kB/sec
Avg throughput per process = 44350.96 kB/sec
Min xfer = 1037612.00 kB

Children see throughput for 2 rewriters = 87304.59 kB/sec
Parent sees throughput for 2 rewriters = 80649.30 kB/sec
Min throughput per process = 43106.23 kB/sec
Max throughput per process = 44198.36 kB/sec
Avg throughput per process = 43652.30 kB/sec
Min xfer = 1022844.00 kB

Children see throughput for 2 random readers = 3696.82 kB/sec
Parent sees throughput for 2 random readers = 3696.71 kB/sec
Min throughput per process = 1736.35 kB/sec
Max throughput per process = 1960.46 kB/sec
Avg throughput per process = 1848.41 kB/sec
Min xfer = 928756.00 kB

Children see throughput for 2 random writers = 6555.41 kB/sec
Parent sees throughput for 2 random writers = 6059.91 kB/sec
Min throughput per process = 3267.60 kB/sec
Max throughput per process = 3287.81 kB/sec
Avg throughput per process = 3277.71 kB/sec
Min xfer = 1042196.00 kB

“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”

” Initial write ” 88701.92

” Rewrite ” 87304.59

” Random read ” 3696.82

” Random write ” 6555.41

RAID10, f2

De manier zoals far layout is opgezet is duidelijk tijdens de array sync, het duurt veel langer omdat de snelheid ongeveer de helft is van de n2 layout maar wel constant.

hdparm: verwachte 190 MB/sec

iozone:

Command line used: iozone -R -b raid10-f2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records

Children see throughput for 2 initial writers = 82377.73 kB/sec
Parent sees throughput for 2 initial writers = 74056.00 kB/sec
Min throughput per process = 40392.30 kB/sec
Max throughput per process = 41985.43 kB/sec
Avg throughput per process = 41188.86 kB/sec
Min xfer = 1009096.00 kB

Children see throughput for 2 rewriters = 80018.49 kB/sec
Parent sees throughput for 2 rewriters = 74390.03 kB/sec
Min throughput per process = 39565.50 kB/sec
Max throughput per process = 40452.99 kB/sec
Avg throughput per process = 40009.24 kB/sec
Min xfer = 1025572.00 kB

Children see throughput for 2 random readers = 3905.55 kB/sec
Parent sees throughput for 2 random readers = 3905.45 kB/sec
Min throughput per process = 1834.01 kB/sec
Max throughput per process = 2071.54 kB/sec
Avg throughput per process = 1952.78 kB/sec
Min xfer = 928376.00 kB

Children see throughput for 2 random writers = 6103.49 kB/sec
Parent sees throughput for 2 random writers = 5581.33 kB/sec
Min throughput per process = 3007.28 kB/sec
Max throughput per process = 3096.21 kB/sec
Avg throughput per process = 3051.75 kB/sec
Min xfer = 1018532.00 kB

“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”

” Initial write ” 82377.73

” Rewrite ” 80018.49

” Random read ” 3905.55

” Random write ” 6103.49

iozone met een enkele 1GB file:
kB            reclen   write      rewrite    random read   random write
1048576   4           85955     86858      2063179       11344

iozone met een enkele 4GB file:
kB            reclen   write      rewrite    random read   random write
4194304    4          78394     78492      716               4058

Vraag me af waardoor dat weer zo langzaam is.

Stukje conclusie

Write het snelste met n2, langzaamste met f2. Random read het snelste met n2, langzaamste met o2. Random write het snelste met o2, langzaamste met f2.
Het kleine verschil tussen n2 en o2 is omdat met 3 disks n2 al gedeeltelijk een offset krijgt zoals bij o2. 4 disks en meer haalt die gelijkenis dan alweer weg.

Een mooie test is te vinden bij ilsistemista.net over RAID10 met de layouts en meerdere threads. Daar is ook te zien dat in de meeste situaties de verschillende layouts elkaar niet veel ontlopen.

Welke RAID10 layout het beste toegepast kan worden is afhankelijk van de toepassing. Sequentieel lezen zoals een media server thuis, RAID10,f2. Sequentieel schrijven zoals een backup disk, RAID10,n2. Bij een random mix zoals databases en virtuele omgevingen ontlopen RAID10,n2 en o2 elkaar niet veel maar lijkt f2 dan weer beter met enkele grotere files in single thread om te kunnen gaan.

Wat ook een factor is, is de snelheid van resync van de array, zeker na vervanging van een disk. Hoe simpeler de layout, hoe sneller dat verloopt. Het verschil tussen 10,n2 en 10,o2 is al ongeveer 30%. Als prioriteit ligt bij zekerheid dan is het beste om de standaard 10,n2 aan te houden.

Hoe dan ook, er zijn veel opties met mdadm waardoor de ideale configuratie toch getest moet worden in de praktijk. RAID10,o2 lijkt een goed uitgangspunt om te starten.

RAID5

hdparm: 107 MB/sec

1048576   4           88924     88859      2097663        6485

Toch nog even met 4GB file getest:
kB            reclen   write      rewrite    random read   random write
4194304   4           79849     80263      567                2862

Command line used: iozone -R -b raid5-3x37G-t2-1G -w -t 2 -F 5/iodump1 5/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records

Children see throughput for 2 initial writers = 81796.59 kB/sec
Parent sees throughput for 2 initial writers = 75337.88 kB/sec
Min throughput per process = 40671.98 kB/sec
Max throughput per process = 41124.61 kB/sec
Avg throughput per process = 40898.29 kB/sec
Min xfer = 1037352.00 kB

Children see throughput for 2 rewriters = 83058.53 kB/sec
Parent sees throughput for 2 rewriters = 77321.25 kB/sec
Min throughput per process = 41483.91 kB/sec
Max throughput per process = 41574.62 kB/sec
Avg throughput per process = 41529.27 kB/sec
Min xfer = 1046304.00 kB

Children see throughput for 2 random readers = 1301.06 kB/sec
Parent sees throughput for 2 random readers = 1301.06 kB/sec
Min throughput per process = 649.35 kB/sec
Max throughput per process = 651.71 kB/sec
Avg throughput per process = 650.53 kB/sec
Min xfer = 1044784.00 kB

Children see throughput for 2 random writers = 4279.91 kB/sec
Parent sees throughput for 2 random writers = 3856.96 kB/sec
Min throughput per process = 2138.85 kB/sec
Max throughput per process = 2141.06 kB/sec
Avg throughput per process = 2139.96 kB/sec
Min xfer = 1047600.00 kB

“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”

” Initial write ” 81796.59

” Rewrite ” 83058.53

” Random read ” 1301.06

” Random write ” 4279.91

Dit laat het nadeel zien van RAID met parity, langzamere writes omdat er meer I/O voor nodig is. Ik had wel snellere reads verwacht.

Het voordeel is nog steeds meer diskruimte beschikbaar te hebben, maar met het nadeel van een langzamere sync na vervanging van een disk en het hogere risico van het falen van een andere disk wegens de hogere I/O belasting is het tegenwoordig niet echt meer waard.
De optie om RAID6 te gebruiken kan ook vervangen worden door RAID10 op te zetten met 3 kopieën voor extra redundancy als er toch een flinke hoeveelheid disks gebruikt gaan worden.

Disk groottes

Het is jammer dat de beste prijsverhouding bij 3 à 4TB disks ligt. In een ideale situatie krijgt het OS een eigen disk apart van de disks voor data (en virtuele machines).
Met bijvoorbeeld een OS van 1GB grootte is maar 0,025% van zo’n disk in gebruik. De rest is dan weggegooide ruimte. Alleen bij een kans op een goedkope partij kleine (gewoonlijk oudere modellen) disks kan het gevoel van verspilling verminderd worden. Gelukkig zijn de prijzen van kleine SSD’s nog te overzien en een goede optie.
Het andere alternatief is dan om het OS op een RAID te zetten van kleine partities op alle schijven in de machine. Dan is de belasting beter verdeeld en toch geen ruimte verspild.
Men zou nog een groep van disks kunnen verdelen in RAID10 sets van 2 disks, en telkens de eerste kleine partitie van 1 disk van de set gebruiken om een RAID10 set te maken voor het OS. Dan is het effect van het OS verminderd op elke data RAID set (die dus niet de tweede disk nodig heeft).
De overgebleven partities zouden een array voor swap kunnen worden, wat toch weinig gebruikt wordt met voldoende RAM in de machine.

Een betere machine maakt veel verschil, een test op de HP 8100 die ik op het werk gebruik (3x1TB RAID10,o2, 10GB RAM);

Command line used: iozone -R -b raid10-o2 -f iodump -i 0 -i 2 -s 1024M

iozone met een enkele 1GB file:
kB            reclen   write      rewrite    random read   random write
1048576   4          508577    556695    3419980        326604

Met 4GB file:
kB            reclen   write      rewrite    random read   random write
4194304    4          160385   178055    3432041       4320

Test bestanden van een paar gigabyte maken het zelfs snellere schijven net zo lastig in random write.

Ultimate server backbone(?);
cheap servers running RAID10, o3 with lots of RAM and 3 SSD’s/HD’s in 3-node clusters.
Unless reliability is very bad 3 times anything should be enough to cover redundancy.