tips

Proxmox – Ceph su nodo singolo (per test)

Qualche anno fa avevo provato a fare su Virtualbox un cluster Proxmox di 3 nodi per smanettare con Ceph, ovviamente in virtuale le performance erano ridicole ma sono rimasto sorpreso dalla resilienza che Ceph può offrire se ben dimensionato. Più avanti ho testato con due nodi bare metal ma il fatto di avere solamente porte ethernet da 1 Gigabit lo rendeva davvero poco performante. Adesso ho 3 server che si stanno liberando ed uno switch SFP+ a 10 Gigabit e penso proprio che comprerò tre schede ethernet a 10 Gigabit e proverò seriamente ad implementarlo ma visto che dai primi test che ho citato sono passati più di 5 anni e siamo arrivati a Proxmox 7 ho deciso di smanettarci per capire meglio le varie configurazioni partendo da un singolo nodo.

Ceph su un singolo nodo Proxmox è pressoché inutile tant’è che non funziona in una installazione pulita perchè giustamente ci si aspetta almeno un altro host dove effettuare le repliche, nonostante è possibile aggiungere ed inizializzare gli OSD e creare un pool questo non diviene mai operativo e lo storage non è utilizzabile. Ma facendo qualche ricerca ho trovato un folle che spiega come e cosa modificare nella configurazione per far replicare sugli stessi OSD piuttosto che su un altro host. Non è semplicissimo se non si conosce Ceph ed infatti ho imparato un sacco di cose.

E’ necessario decompilare la crush map di Ceph, modificare una riga, ricompilarla e settarla. Vediamo rapidamente come fare:

ceph osd getcrushmap -o comp_crush_map.cm
crushtool -d comp_crush_map.cm -o crush_map.cm

editare crush_map.cm e modificare la riga

step chooseleaf firstn 0 type host

con

step chooseleaf firstn 0 type osd

e poi ricompilare e settare la crush map:

crushtool -c crush_map.cm -o new_crush_map.cm
ceph osd setcrushmap -i new_crush_map.cm

Così lo storage pool diverrà operativo e potrete divertirvi come scimmie ad installare qualcosa in una macchina virtuale e nel frattempo giocare a mettere In/Out/Up/Down i dischi per ore e vedere come reagisce ed opera Ceph: una figata!

Raccogliere i log da remoto con rsyslog, differenziarli in base all’IP e ruotarli con logrotate

Le indicazioni di questo post sono state testate con delle antenne Ubiquity e sono valide per qualsiasi sistema che utilizzi ancora rsyslog e logrotate e qualsiasi hardware che sia in grado di spedire i propri log in remoto. Lo scenario è quello di un logserver Debian che riceve i syslog di access points e stations e li divide in base all’IP di provenienza.

Per prima cosa bisogna dire ad rsyslog di ascoltare su una porta UDP o TCP per poter ricevere i log, su /etc/rsyslog.conf decommentare le righe inerenti al protocollo che si desidera utilizzare:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Successivamente, sempre su /etc/rsyslog.conf o come snippet in /etc/rsyslog.conf.d/ vanno inserite direttive tipo queste:

if $fromhost-ip startswith '192.168.10.' then /var/log/ubnt-stations.log
& ~
if $fromhost-ip startswith '192.168.2.' then /var/log/ubnt-stations.log
& ~

if $fromhost-ip startswith '192.168.1.' then /var/log/ubnt-APs.log
& ~

Molto utile ed importate è la riga ” & ~ ” posta immediatamente dopo la singola direttiva, vuol dire: “fermati li dove hai loggato e non andare avanti”, per evitare di spammare altri logfile tipo syslog o messages. Un restart di rsyslogd ed andiamo avanti.

Ultimo step è quello di configurare logrotate per ruotare anche questi nuovi logfile ed evitare che /var/log/ si riempia troppo presto. Le politiche più adatte spettano a voi, potete anche riciclare delle impostazioni già esistenti tra /etc/logrotate.conf.d/ o crearne una vostra, a seconda di quanto vi serva tenere i log.

Nel mio caso bastava una settimana ed ho aggiunto quei file di log (anche con wildcard) allo stesso snippet che fa ruotare syslog, ovvero ogni giorno e per una settimana, /etc/logrotate.conf.d/rsyslog:

/var/log/syslog
/var/log/ubnt-*.log
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Script per lo spindown automatico dei dischi esterni USB

Prima di tutto -per chi non lo sapesse- lo spindown è lo spegnimento del motore di un hard disk. Alcuni hard disk esterni hanno la possibilità di essere impostati indipendentemente dal sistema operativo per effettuare lo spindown come risparmio energetico dopo un tot tempo di inattività, ma la maggior parte degli hard disk (esterni ed interni) no: girano all’infinito anche se non sono utilizzati.

Oltre ad un fattore energetico (un hard disk è un dispositivo meccanico e tra quelli che consumano più energia in un sistema) c’è un fattore acustico dato dal rumore prodotto dal motore (che può essere più o meno fastidioso, anche più o meno conciliante la notte se ti ci abitui) e c’è un fattore termico: girando il disco si surriscalda ed anche se deve riscaldarsi proprio parecchio per danneggiarsi non mi piace affatto l’idea di avere un hard disk termosifone, soprattutto in estate.

Per i dischi che non vengono gestiti dal sottosistema SCSI di Linux si può impostare il valore di timeout per lo spindown con il buon vecchio hdparm:

hdparm -S valore-in-multipli-di-5-secondi /dev/hdX

Per i dischi che invece vengono gestiti dal sottosistema SCSI la questione è un po’ più complicatuccia perchè hdparm non funziona e sdparm non sempre ci azzecca. E’ comunque possibile forzare lo spindown con un comando e la soluzione più compatibile è fare uno script periodico che metta in spindown il disco se non è stata rilevata un’attività recente.

Uno dei migliori che ho trovato sta qui: http://www.linuxquestions.org/questions/linux-hardware-18/howto-spin-down-external-usb-firewire-hard-drives-on-idle-593192/.

Per i più pigri l’ho messo in questo file: idle-drive.sh.gz. Necessita di sdparm e gawk quindi:

sudo apt-get install sdparm gawk

Prende come argomento l’uuid del disco che si vuole monitorare, io l’ho installato in /usr/local/bin/idle-drive.sh e lo richiamo ogni 5 minuti tramite cron:

echo '*/5 * * * * root /usr/local/bin/idle-drive.sh uuid=1703f12f-e133-356f-aee2-ecb75cca15b2' > /etc/cron.d/idle-drive

Impostare la data con il comando ‘date’

Inutile nascondersi dietro ad un dito! Sembra una cazzata ma a tutti, almeno una volta nella vita, è capitato di trovarsi a dover impostare l’orario di un sistema senza ntp e una connessione ad internet, senza server grafico né utility adeguate: solo il comando date e la sua ostica man page dalla quale non siamo riusciti a capire granchè sul come fare.

In effetti all’inizio della man page, nella sintassi, c’è scritto! Ma con tutte quelle parentesi quadre pensi che sia meglio continuare a leggere cercando un esempio che trovi alla fine della man page ma sei talmente confuso che non lo noti.

Bene: per chi non ci è mai riuscito o per chi se l’era dimenticato il pattern di default che il comando date si aspetta come argomento è

MMDDhhmmAAAA
(mese giorno ore minuti anno)

Per impostare quindi la data alle 18:48 del 25 luglio 2010 basterà un

date 072518482010

;)