Wie mooi wil zijn moet pijn lijden
SSH/SFTP-compatible
Vorige maand kregen we het verzoek om daDup ook geschikt te maken voor het rsyncen van back-ups, via SSH. Een veelgebruikte back-upmethode voor Unix-gebruikers.
Omdat we eerder dit jaar daDup al hadden uitgebreid met CIFS/Samba (zodat je via Windows een hele grote disk aan je machine kunt koppelen) was dit niet een hele grote uitdaging. Binnen een dag of twee zorgden we ervoor dat je met SSH, Key-authentication, in een chroot kon inloggen op daDup. Je krijgt met SSH keurig een console en ook SFTP is mogelijk.
Uh-oh, performance
En daar diende zich een probleem aan. Omdat daDup een bulk-storage dienst is waar de focus niet ligt op IOPS maar op veel opslag voor weinig geld, was de performance van de SSH-access ver beneden peil.
Een bestand bestaat eigenlijk uit twee delen: de data in het bestand en de data over het bestand; metadata. In Ceph (wat daDup is) sla je die twee onderdelen apart op. De data is natuurlijk het grootste gedeelte als het gaat om omvang, maar de metadata wordt het meest benaderd en aangepast. Bij het rsyncen van een back-up wordt metadata heel veel geraadpleegd, maar alleen als een bestand nieuw of anders is wordt de data daadwerkelijk aangepast.
Doordat daDup uit alleen draaiende disken bestond, werden die wel heel erg druk met kleine operaties; voelbaar op het hele daDup cluster.
Enter SSD
Gelukkig kunnen de servers die daDup vormen ook nog wat SSD’s aan en kunnen we Ceph vragen de eerder genoemde metadata anders te behandelen dan de echte data. Gisteren hebben we de SSD’s in het cluster gezet en het migreren van data in gang gezet..
pgs: 55844965/114922938 objects misplaced (48.593%)
recovery: 808MiB/s, 294objects/s
Met ongeveer 300 objecten per seconde gaat deze operatie dus nog wel even duren..
Even pijnlijden dus
Zolang daDup bezig is met het verplaatsen van data zullen de servers en disken extra hard moeten werken. Maar uiteindelijk wordt iedereen er blij van.
Ook daDup via S3/CIFS/SSH/SFTP testen? Vraag een account aan en ga hard!