esperimenti di DR

DR sta per disaster recovery. Sono particolarmente paranoico per i miei dati e per i dati della moglie di un mio caro amico, che fa la fotografa.

Ora, io produco veramente poco, tutti i miei dati personali stanno in una 80ina di giga, ma il grosso sono foto. Se faccio un controllo sui miei documenti, contratti, dati clienti di lavoro … siamo a 5.2 giga.

I miei dati stanno su 5 macchine diverse, tutte con il filesystem crittato. Una di queste sta a Berlino, il resto sta nel mio ufficio in Franciacorta: una copia su portatile, una su fisso, una su Mac mini, forse anche qualche qualche vecchia macchina, ma non sincronizzata abitualmente.

Di solito tengo sincronizzati portatile e workstation. Subito a seguire si va su JBOD ZFS, ovvero una macchinetta esterna che mi presenta i dischi all’accensione tramite SAS e SATA (la stessa macchinetta ha un controller SAS per il tape driver). I dischi su tale macchina sono in in raidz1 (cosa non ottimale, che sto anche io imparando in corso d’opera… sostanzialmente perdo i dati, nel momento in cui mi muoiono almeno 2 dischi su 5).

In aggiunta, critto e butto i dati su AWS Glacier tramite duplicity+gpg

E giusto perche’ il cloud e’ sempre il computer di qualcun altro… registro i dati in maniera crittata anche su dei nastri magnetici, che alla fine e’ quello che fa AWS Glacier. (vedasi i costi, non ci vuole molto a dedurlo).

Analisi tecnica ed economica

Visto che un DVD/Blueray potrebbe arrivare a 50 giga. Un normale DVD non super i 4.5 giga… potrebbe essere un’alternativa su cui scrivere i dati. Quello che cerco di evitare e’ di mantenere in giro dei dischi retail di quelli che si comprano in qualsiasi negozio di computer. Oramai un disco esterno da 1TB pero’ si aggira sui 100EUR…

Ovviamente sono un te-nnnico, per cui scoprendo che sul mercato si trovavano nuovi ancora nastri di tipologia LTO5 (1.4 TB o 2.5 TB in caso di compressione LZO -> non applicabile a materiale gia’ compresso di suo come video e immagini) a 25 EUR l’uno… mi sono messo a cercare unita’ nastri per poterle usare. Normalmente nuove costano un rene, sopra i 4k EUR, ma ne ho trovate di usate sui 300-400 EUR.

Rotta la prima (unita’ LTO5, me ne sono comprata una seconda mentre la prima era in riparazione e me la sono portata a Berlino. Per cui ho anche il DR in due posti decisamente distanti tra loro.

Ora… tutto questo e’ molto bello e nerdico, ma fottutamente antieconomico, soprattuto per le moli di dati irrisorie che tratto.

e con la fotografa?

Allora, DB e’ una fotografa giovane, per cui non so ancora dove portera’, diciamo che i suoi dati di lavoro stanno nell’ordine dei 6/7 TB, tutti. Ovviamente mi sento responsabile nel vederla trafficare con dischi esterni USB presi nelle grandi catene di distribuzione, che le morivano come mosche al sole… le ho fatto anche a lei una unita’ JBOD (again: just a bunch of drives, la sigla non e’ niente di esoterico).

Perche’ non un NAS? perche’ il NAS ti impone quello che vuole lui, non puoi truscolare con la tecnologia di replica e consistenza dei dati, prendi quel che passa il convento. Invece con OpenZFS so che da Linux, Win o Mac, i dati li vedo sempre. Ho dovuto disattivare un paio di funzionalita’ per essere sicuro di vedere il dataset su qualsiasi sistema operativo.

Sempre perche’ non un NAS, sul gruppo di barbe bianche appassionati di sistemi *nix/Linux, uno recentemente ha dovuto aggiornare tutti i dischi nell’unita’ e non ha potuto giocare col resilvering. Sostanzialmente se avesse avuto ZFS, avrebbe potuto cambiare un disco alla volta, facendo la re-sincronizzazione nel mentre per ciascuno, e invece ha dovuto recuperare un secondo NAS, trasferire tutti i dati e dismettere il vecchio.

Inoltre…

Il primo tentativo con DB per il suo JBOD con ZFS ci ha lasciati a piedi, forse era il convertitore thundebolt > eSata (mi ero accanito a voler usare eSata al tempo) … fatto si e’ che come le ho cambiato lo scatolo in cui mettere i dischi, con uno USB-3, i dati sono andati corrotti. Ma essendo ZFS uno standard, ho trovato chi si e’ scritto una utility per Windows per recuperare i dati, e ci siamo riusciti, recuperati e anche la history di scrittura (anche i file cancellati nel tempo).

Ma… in tutto questo il mio tempo e’ stato divertimento, perche’ se avessi dovuto conteggiarlo sarebbe stata completamente anti-economica come soluzione.

Per cancellare un nastro LTO5, ci vogliono 4 ore. Per scrivere un dataset da 1.4 TB ci vogliono circa 12h, e per rileggerlo, forse qualcosa meno. Insomma, DB sta su 4 nastri LTO5, indistruttibili, a quanto pare non dovrebbero avere problemi ad attraversare i raggi X agli aereoporti, non e’ roba che emette onde magnetiche, per cui…

Ma il disco esterno preso in un qualsiasi grande magazzino costa infinitamente meno di tutto il cinema qua sopra.

Sicurezza

Ah, per avere i nastri cifrati, nel mio caso, uso dump di snapshot di pool crittati in AES256 da OpenZFS… LTFS per il momento mi ha dato solo problemi di compilazione o consistenza di uso, accesso, tra workstation/OS differenti. Non che LTFS mi aggiunga alcun layer di sicurezza, ma alla fine il modo piu’ pratico che ho trovato e’ registrare dei file singoli, dump AES256, scritti tramite l’utili *nix standard ‘tar’.

p.s. se qualcuno e’ paranoico come me ho l’infrastruttura e gli faccio volentieri dei nastri LTO5, ma non ho la piu’ pallida idea di cosa far pagare un servizio simile

GitLab on Azure

just delegate a domain to the Azure’s cloud, map a wildcard DNS to the Kubernetes loadbalancer entry point… and (crucial, I just mention the painful part) do create your own cert-signing thing for let’s encrypt like this:

(the class: addon-http-application-routing is the REALLY important bit, else you don’t get the fancy loadbalancing/Ingress resource integration from Azure )

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: your@email.address
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: prod-issuer-account-key
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
    - http01:
        ingress:
          class: addon-http-application-routing

and finally bring up the cluster of GitLab specifying 3 separate tls secrets, otherwise GitLab will assume you do have a wildcard certificate and the http01 validation of Let’sEncrypt will fail… (u need otherwise to use dns01 validation)

nginx-ingress:
  enabled: false
certmanager:
  install: false
global:
  hosts:
    domain: your.fancy.domain
  ingress:
    annotations:
      kubernetes.io/ingress.class: addon-http-application-routing
      cert-manager.io/cluster-issuer: letsencrypt-prod
      kubernetes.io/tls-acme: true
    configureCertmanager: false
gitlab:
  unicorn:
    ingress:
      tls:
        secretName: "gitlab-unicorn-tls"
registry:
  ingress:
    tls:
      secretName: "gitlab-registry-tls"
minio:
  ingress:
    tls:
      secretName: "gitlab-minio-tls"

ah… don’t try to use ArgoCD for this,
it is buggy -> gitlab/-/issues/2039

therefore… reiterate with:

$ helm upgrade gitlab gitlab/gitlab -n gitlab -f gitlab_values.yaml –render-subchart-notes –reset-values

UPDATE: u want git+ssh access to pull/push from ur repo, right?

well, then you need to add the following snipped in your values.yaml

gitlab:
  gitlab-shell:
    service:
      type: LoadBalancer
global:
  hosts:
    ssh: ssh.your.fancy.domain

and again, accordingly, create in your dns zone a CNAME (ANAME) towards the newly created LoadBalancer IP that AKS has created you…

yes, of course you could have created a complete set of ingress-controllers, but we are not running a service that yet needs to be scaled to a broad audience

I’m back freelancing

…even more determined than before

If you can keep your head when all about you
    Are losing theirs and blaming it on you,
If you can trust yourself when all men doubt you,
    But make allowance for their doubting too;
If you can wait and not be tired by waiting,
    Or being lied about, don’t deal in lies,
Or being hated, don’t give way to hating,
    And yet don’t look too good, nor talk too wise:

If you can dream—and not make dreams your master;
    If you can think—and not make thoughts your aim;
If you can meet with Triumph and Disaster
    And treat those two impostors just the same;
If you can bear to hear the truth you’ve spoken
    Twisted by knaves to make a trap for fools,
Or watch the things you gave your life to, broken,
    And stoop and build ’em up with worn-out tools:

If you can make one heap of all your winnings
    And risk it on one turn of pitch-and-toss,
And lose, and start again at your beginnings
    And never breathe a word about your loss;
If you can force your heart and nerve and sinew
    To serve your turn long after they are gone,
And so hold on when there is nothing in you
    Except the Will which says to them: ‘Hold on!’

If you can talk with crowds and keep your virtue,
    Or walk with Kings—nor lose the common touch,
If neither foes nor loving friends can hurt you,
    If all men count with you, but none too much;
If you can fill the unforgiving minute
    With sixty seconds’ worth of distance run,
Yours is the Earth and everything that’s in it,
    And—which is more—you’ll be a Man, my son!

src: If— by Rudyard Kipling | Poetry Foundation