Browsed by
Category: Cloud

Vademecum 2.0 per picchi di carico imprevisti

Vademecum 2.0 per picchi di carico imprevisti

Comments 0 Comment

[questo articolo è la versione aggiornata e rivista del precedente articolo che era a sua volta la versione rivista e curata di un mio thread inizialmente pubblicato su Twitter]

A volte succede che siti web a basso traffico per la maggior parte della loro esistenza divengano improvvisamente critici per la sopravvivenza dell’umanità.

Questa settimana è stato il turno del sito del Ministero della Salute (salute.gov.it), diventato importante a seguito dell’arrivo del COVID-19 (Coronavirus) in Italia, e collassato sotto il peso dei cittadini che cercavano di informarsi.

Da cittadino non posso che pensare il Ministero non ci abbia fatto una bella figura: in casi come questo l’accesso alle informazioni può veramente prevenire il panico (e/o salvare vite). Da persona (dicono) competente nel settore devo riconoscere che pur essendo la scalabilità delle piattaforme web uno dei problemi più complessi dell’informatica, nel caso di siti informativi (in sola lettura) gestire i picchi di carico diventa estremamente semplice (e veloce).

Ecco quindi un vademecum che spiega come reagire nel caso in cui vi troviate in una situazione simile e doveste riportare online con molta fretta un sito sotto un carico talmente alto da non riuscire nemmeno a collegarvi all’infrastruttura.

Il primissimo passo (contro intuitivo) è quello di chiudere gli utenti fuori dal sito e far si voi siate gli unici a poterlo raggiungere. Il modo migliore è bloccare le porte HTTP/HTTPS sul firewall: se il numero di connessioni è molto elevato, un semplice deny sul frontend potrebbe non bastare.

Fatto questo, procedete con il ripristino del funzionamento del sito per poterci lavorare dall’interno della vostra rete: spesso un riavvio dei componenti (database, application server, frontend) è sufficiente. Controllate che le partizioni in cui vengono scritti file temporanei, sessioni e log non siano piene: in base alla situazione (e al software specifico) potrebbe avere senso rimontarle temporaneamente in /dev/null per escludere una fonte di possibili problemi.

Date anche uno sguardo alla configurazione per controllare non ci siano inutili colli di bottiglia, come limiti troppo stringenti al numero di connessioni verso il database o verso l’application server: in una simile situazione potrebbero creare più problemi che benefici.

Sostituite l’indirizzo IP esterno del frontend: dobbiamo assicurarci che non sia più raggiungibile direttamente dagli utenti una volta riaperto il firewall, motivo per cui aggiungere un nuovo indirizzo in alias non è sufficiente e quello precedente va completamente rimosso.

Create anche un record DNS temporaneo che punti al nuovo IP (ad esempio origin-www.grg.pw). Già che ci siete, assicuratevi che il TTL del vostro hostname principale sia basso, a 300 secondi o meno.

Configurate una CDN: create una distribuzione/vhost usando l’hostname primario del vostro sito web (www.grg.pw) che abbia come origin/backend l’hostname temporaneo creato poco prima. Mi riferirò ad Amazon Cloudfront perchè a differenza di altre è disponibile in self provisioning

In questo scenario ci sono alcuni valori di configurazione estremamente critici: prima di tutto, alzate l’origin timeout ad almeno 60 secondi.

Configurate poi la CDN perchè ignori gli header di caching (non) impostati dal vostro CMS e forzi invece un default e un minimum TTL ragionevolmente alti (nel mio esempio 24 ore).

[NB: questa configurazione non sarebbe ottimale in un normale ambiente di produzione, ma nello scenario sopra descritto la priorità è massimizzare la probabilità che i contenuti finiscano in cache, e che poi ci rimangano]

Disabilitate il forward dei cookie e degli headers HTTP: questo aumenterà la resa delle cache (ma romperà tutte le funzioni di personalizzazione e il login). Il forward delle query string è un tema leggermente più spinoso e richiede conoscenza del CMS: impostatela in modo che venga inoltrato il minimo necessario alla generazione delle pagine (se le vostre URL non includono query strings, disabilitatelo).

Se il sito in questione ha un’area amministrativa (diciamo /wp-admin/), rendete l’intero path inaccessibile al pubblico: potete farlo sia con una eccezione nella configurazione della CDN stessa o direttamente sul vostro frontend. Questo passaggio è importante perchè con la configurazione che stiamo usando la CDN potrebbe inserire in cache (in sola lettura, ovviamente) anche le pagine amministrative e renderle disponibile a tutti gli utenti.

Ci siamo quasi. Il prossimo passo è configurare il vostro firewall perchè accetti solo connessioni provenienti dalla CDN. Se vi risulta troppo complicato se ne può temporaneamente fare a meno (ricordiamo che il nuovo indirizzo IP del frontend è sconosciuto agli utenti, così come il record DNS temporaneo che abbiamo creato).

Potete ora procedere con l’aggiornamento dei record DNS del vostro dominio principale perchè puntino alla CDN e non più direttamente al server.

Il vostro portale tornerà lentamente online, con la propagazione dei nuovi record.

DISCLAIMER: quella qui descritta è una configurazione di emergenza, da usare nei casi in cui riportare online nel minor tempo possibile un portale contenente informazioni critiche è la priorità. Dovrete eseguire invalidation a mano ogni volta che i contenuti vengono aggiornati, e potete stare certi che qualche funzione del portale si romperà. Se avete usato questa guida, è importante pianifichiate l’implementazione di una configurazione adeguata il prima possibile.

Per ogni necessità, mi trovate su Twitter.

Il Cloud spiegato a Nonna Pina: l’alta affidabilità

Il Cloud spiegato a Nonna Pina: l’alta affidabilità

Comments 0 Comment

Noi nerd soffriamo di una patologia che spesso ci porta a dare per scontato che chiunque abbia ben chiaro ciò che, al contrario, è chiaro solo a noi.

Io non sono un nativo delle nuvole: so cosa sono i server, so cosa sono i RAID, e so anche dove si nascondono le birre in datacenter. Nelle mie frequentazioni risalenti a quell’era geologica ho una completa rappresentazione delle idee sbagliate che i sistemisti, gli sviluppatori o gli IT manager hanno in tema di cloud computing.

…e non sono poche: complici sicuramente campagne di marketing di compagnie “wannabe” traboccanti di buzzword (da #cloud a #blockchain passando per #ai), la confusione e quindi l’incomprensione è sempre in agguato. Da qui l’idea di una serie di post, scritti in modo (quasi) semplice, che abbiano lo scopo di spiegare (anche a Nonna Pina, per l’appunto) i fondamenti di questo, per qualcuno, nuovo mondo.

Partiamo da un tema molto caldo: l’alta affidabilità nel cloud. Quello che insomma spinge in media ogni due giorni un sistemista a lamentarsi nel suo gruppo Facebook di fiducia di qualcosa del tipo “…mi avevate detto che il cloud è super affidabile, ci ho spostato la mia macchina virtuale e dopo tre mesi era già down!”.

Questo è senza dubbio il salto concettuale più complesso: nel mondo pre-cloud l’alta affidabilità veniva implementata negli strati più bassi della piramide: si usavano server con componenti ultra ridondati, fatti per non guastarsi mai, collocati in datacenter sotterranei (o con scudi esterni in acciaio), progettati per resistere a qualunque attacco o avversa condizione esterna e, in sostanza, non spegnersi mai.

Un approccio sicuramente molto comodo per chi si occupa dell’applicativo che in questo resta totalmente agnostico perchè pensa a tutto l’infrastruttura sottostante, ma con un numero importante di problemi al seguito. Iniziando dal fatto che un simile modello è sostenibile solo su un singolo datacenter o al massimo un paio, a patto che siano molto vicini geograficamente: i costi crescono in modo sproporzionato, e si arriva comunque ad una situazione sub-ottimale sia di latenza per gli utenti finali (se i DC sono vicini tra loro non possono essere anche vicini agli utenti) che di rischio (sarebbero soggetti alle stesse minacce di tipo metereologico e geologico). Come se questo non bastasse, la scalabilità viene limitata in modo importante, richiedendo di fatto che ogni componente della vostra infrastruttura sia rinchiuso in una ed una sola VM.

Siamo di fronte ad uno dei cambiamenti di paradigma più radicali che il cloud abbia portato: l’alta affidabilità si sposta sugli strati più alti della piattaforma e si basa sul presupposto che ogni componente dell’infrastruttura possa fallire in qualunque momento, sia esso una VM, un datacenter o un intero campus. Notate il salto? Ci siamo evoluti dall’usare componenti indistruttibili pur sapendo non fosse possibile considerare ogni casistica al dare per scontato che tutto ciò che può succedere succederà, e quindi al pianificare reazioni automatiche a qualunque tipo di guasto. Si è passati da un paradigma molto costoso che non poteva considerare ogni eventualità ad un paradigma molto più economico, in cui si progetta tenendo sempre in considerazione il peggiore caso possibile.

Questo vi farà sicuramente riflettere: NukeMap alla mano, con una sola bomba nucleare in un punto strategico un attaccante potrebbe cancellare dalla faccia della terra i vostri conti correnti e infrastrutture critiche nazionali (in Italia ed in Europa, non conosco le leggi/pratiche comuni nel resto del mondo), ma non potrebbe scalfire minimamente le vostre playlist Spotify o i vostri post su Facebook. Quello che alcuni definirebbero “evento catastrofico” è per altri “ordinaria amministrazione”. Se non vogliamo guardare a casi così catastrofici, scommetto che almeno una volta nell’ultimo anno non siete riusciti ad accedere all’home banking della vostra banca a causa di una manutenzione programmata. Vi è mai capitato lo stesso su Snapchat o su Netflix? No? Esattamente.

A riprova del fatto che il focus si sia spostato dall’evitare gli imprevisti al gestirli, ci siamo addirittura inventati il Chaos Engineering: l’idea, anzi, la pratica di causare artificialmente guasti e disastri in produzione per verificare che le nostre piattaforme siano in grado di gestirli senza che gli utenti finali ne risentano.

Ricapitolando, quindi, l’alta affidabilità nei sistemi IT tradizionali si fonda sull’implementare infrastrutture sotto vari aspetti sub-ottimali usando componenti, costosi e complessi, progettati per non fallire mai. Nel paradigma cloud, al contrario, si implementano infrastrutture utilizzando componenti semplici e quindi economici, consci del fatto che questi prima o poi si romperanno e quindi progettando le applicazioni per gestire senza impatto le situazioni avverse.

…chiaro?

[nel prossimo capitolo a Nonna Pina spiegheremo invece i fondamenti di scalabilità]

DAZN, Serie A e streaming: dove stanno i problemi?

DAZN, Serie A e streaming: dove stanno i problemi?

Comments 0 Comment

Immagino sentiate la mancanza dei miei articoli polemici, quindi eccone uno. Parliamo di DAZN, della Serie A, di streaming e dei problemi che qualcuno ha avuto nella visione delle prime partite di questa stagione: mi sono capitati sottomano in questi giorni articoli di “esperti” con idee molto poco chiare che parlano di banda larga, di codec, di reti, di capacità dei server e altro.

Non ci siamo.

Siccome esattamente come nel caso dei vaccini la disinformazione fa danni e porta in direzioni sbagliate, vi regalo le mie competenze (la progettazione di infrastrutture per eventi straordinari come questo costituisce gran parte del mio lavoro) per fare chiarezza: se siete giornalisti e questo articolo non vi basta, sentitevi liberi di contattarmi.

Fatemi iniziare con un pò di sano debunking e quindi dall’esplorare quali non sono le cause della bassa risoluzione / buffering / interruzioni:

  • Non è la banda larga: il concetto di “banda larga” è riferito all’ultimo miglio, in sostanza alla connessione tra voi e la centrale Telecom più vicina. Per tutta una serie di ragioni che non vi sto a spiegare (questioni di fisica dei mezzi trasmissivi), questo è stato storicamente il collo di bottiglia delle reti. In alcune zone d’Italia si naviga a 1 gigabit al secondo, in altre a 250 megabit, in altre ancora a 30mbps e in alcune addirittura a soli 7mbps: quest’ultima è più che sufficiente a ricevere un flusso video con risoluzione decente, anche se la velocità effettiva dovesse essere inferiore. Non fraintendetemi, la lenta diffusione della banda larga può essere una serissima questione di sviluppo economico, ma in questo caso, semplicemente, non è il nostro problema.
  • Non sono i codec: alcuni codec possono essere più pesanti di altri sulla CPU, ma a meno che non stiate usando un PC di 25 anni fa più o meno qualunque processore è in grado di mostrare uno streaming in qualità accettabile senza interruzioni. A meno che sul vostro computer non girino anche un miner Bitcoin e 327 virus con cui condividete la capacità di calcolo, ovviamente.
  • Non è nemmeno la capacità dei server: la tecnologia si è evoluta e le realtà al passo con i tempi (e DAZN lo è) utilizzano infrastrutture elastiche, pronte a scalare per servire più richieste in pochi minuti, nel caso in cui si renda necessario. Di solito lavoriamo perchè le previsioni di carico siano adeguate, ma anche nel caso in cui si dimostrassero errate, correggere il dimensionamento sarebbe cosa da poco. Tutto questo, in una infrastruttura correttamente progettata, ad un costo molto basso.
  • Non è colpa della collocazione geografica delle CDN: questa è una teoria interessante ma totalmente campata in aria, e ci spenderò qualche minuto. Le CDN sono reti ad altissima capacità il cui compito è consegnare contenuti (video, immagini) agli utenti finali (voi). In rete si trova un comunicato stampa di DAZN in cui annunciano di aver scelto LimeLight, che in Italia ha infrastruttura a Milano e Palermo, come partner CDN: secondo gli scienziati, era ovvio che una CDN con presenza solo a Milano e Palermo non fosse all’altezza. Ma questo è sbagliato, per vari motivi:
    • L’analogia “immaginate come sarebbe difficile fare la spesa se gli unici due centri commerciali in Italia fossero a Milano e Palermo: da Roma sono 600km, quasi 12 ore di macchina tra andata e ritorno” potrebbe sembrare sensata, ma è pretestuosa: per la spesa settimanale si impiega un’ora normalmente, il viaggio Roma-Milano aumenta questo tempo di 12 volte ed equivale alla perdita di una giornata intera. Per i dati che viaggiano su fibre ottiche invece è il contrario: le “operazioni intermedie” indipendenti dalla distanza impiegano comunque qualche millisecondo, ed il dover percorrere una tratta di 600km al posto di una lunga solo 6 cambia di pochissimo il ritardo totale.
    • Se invece che usare Google in cerca di comunicati stampa i sopracitati scienziati avessero analizzato lo streaming vero, si sarebbero accorti che DAZN usa almeno tre CDN diverse, alcune con presenza più capillare in Italia. La storia di Palermo e Milano quindi non regge, o comunque non può essere banalizzata su un fattore di semplice distanza.
    • Internet non soffre di barriere nazionali (non ancora perlomeno), e le CDN hanno altre presenze vicino all’Italia come Vienna, Zurigo, Marsiglia, Monaco etc: è realistico pensare che anche queste location contribuiscano all’esperienza del pubblico italiano.

Arrivati a questo punto vi starete chiedendo dove stia il problema, ed eccoci alla risposta: non lo so, ma ho un paio di “maggiori indiziati”, che vi espongo.

Il primo è la particolare conformazione della rete italiana che per questioni geografiche e soprattutto storiche consiste di fatto in una stella con centro a Milano. Le interconnessioni tra diversi provider (tra le quali, ad esempio, la connessione tra chi vi vende la linea internet di casa e la CDN di DAZN) avvengono quasi esclusivamente lì, rendendo di fatto inutile la localizzazione geografica dei punti di distribuzione contenuti (per farla molto semplice, anche se la CDN di riferimento installasse un nodo nella vostra stessa città, con buone possibilità si dovrebbe comunque passare da Milano, o quantomeno da Roma, per raggiungerla).

Questo ci porta al secondo fattore in gioco: il trasporto dati nazionale di lunga distanza (il collegamento Napoli-Roma-Milano, per intenderci) ha costi relativamente alti se comparato a tratte molto più estese (Londra-New York), dettati dalla complessità infrastrutturale e dalla scarsità di competizione e di investimenti. Il traffico in rete è esploso negli ultimi anni, e certe tratte di interesse internazionale si sono sviluppate in modo molto veloce e spinto – altre, di interesse meramente nazionale, sono rimaste indietro e si stanno muovendo più lentamente. In questa condizione è facile che per motivi tecnico-economici si creino situazioni di congestione temporanea durante eventi eccezionali, per il semplice motivo che evitarla sarebbe troppo costoso.

Il terzo fattore è relativo al criterio di dimensionamento dei trasporti digitali, che spesso si deve per forza basare su dei dati di utilizzo medio. Torniamo all’analogia con i trasporti automobilistici: nelle due settimane centrali di Agosto sarebbe indubbiamente comodo se tutte le autostrade a tre corsie ne avessero invece cinque. Perchè allora non ne hanno cinque? Per il semplice motivo che quelle corsie sarebbero da mantenere tutto l’anno pur essendo necessarie per sole due settimane: i costi, in altre parole, avrebbero la prevalenza sui benefici. Lo stesso accade su certe tratte di trasporto difficili da ampliare e mantenere (molte altre sono invece dimensionate in base al picco di traffico atteso, quindi sulla base del caso peggiore).

Non si può infine non citare il nostro buon vecchio PEBKAC – acronimo che in informatica si usa per indicare il problema che sta tra la sedia e la tastiera (in questo caso tra la poltrona e il telecomando), cioè l’utente. In molti si sono avvicinati ai servizi di streaming per la prima volta in questa occasione, e non hanno mai verificato prima che la loro rete di casa (banalmente, il Wi-Fi) fosse pronto a gestire un simile traffico. Sono pronto a scommettere che gran parte dei problemi stia qui.

Tutto chiaro ora? Se ci sono domande chiedete pure.

My second year at AWS: down the rabbit hole

My second year at AWS: down the rabbit hole

Comments 0 Comment

We all know, time flies. I posted about my first year at Amazon Web Services just 12 months ago and now I’m already celebrating my second AWS-birthday.

It’s been a year of both personal and professional growth: it began in December when I became head of a project that has been helping some of our customers running their platforms at massive scale, all the way up to my promotion to Senior TAM a few months back. Needless to say, customers I’m looking after have made giant leaps too, as part of transformation processes that start from the infrastructure and can reach up to their corporate culture.

My post about “Year One” was organised by subsequent evolutional phases but this won’t really make sense from the second year onward: I’ve been involved in a bunch of projects, every one of them with its own life. Why not trying then to recap the last 12 months by picking the project (more details on it here, with a cameo appearance) that took most of my time and checking our slogan “Work Hard, Have Fun, Make History” has been truly met in it? Let’s start here.

Work Hard

This is how it begins. It might seem obvious, as no one ever will pay us to do something other than working hard, but it’s not. Working hard in AWS means taking responsibilities, being effective, facing challenges and turn every opportunity into an huge success.

“Hard” as in pushing our brains to 100%, not necessarily as in working 16 hours a day. True, we carry pagers, and might end up having late evening calls with the teams in Seattle or doing late night debugging sessions from our hotel room, but this only happens in exceptional situations.

I personally find this extremely rewarding: when you focus on a project with all your energy, then the sense of achievement when it’s done is super strong.

…check ✓

Have Fun

“Having Fun” is something we keep reading in job offers: it’s a “new economy” concept, meant as enjoying what you do and finding personal motivation in addition to the obvious business one.

I find this kind of comes by itself: if you work effectively on something and achieve results, then customers will trust you, the relationship will become more friendly and relaxed and you will end up having a lot of fun with them, even in the day to day.

Check ✓

Make History

Last one, and possibly just another consequence. Is there any other way a successful project can finish?

Sometimes we might not realise how big a given change can be. We might focus on some virtual machines becoming EC2 instances and some hard drives becoming S3 partitions, but there’s much more behind the curtains: you will see a quickly changing and moving world there.

Never underestimate the importance of small actions and small steps as they can quickly prove to be giant leaps.

(in the picture below you can see me helping with the final step of a cloud migration: loading a massive storage array on a truck after datacenter decommissioning and shutdown) …check ✓

So What?

Two years in, and for me it still feels like it’s Day One. Learning something new every day, consciously jumping in rabbit holes every other day just to re-emerge stronger and wiser later on. Being surrounded by the smartest people on earth makes you feel extremely small sometimes, but also guarantees you endless opportunities for growth.

This is what I’ll keep doing.

(want to join the band? just ping me!)

This is your sysadmin speaking: please expect some turbulence.

This is your sysadmin speaking: please expect some turbulence.

Comments 0 Comment

A few months back I blogged about my HP DL320 Gen8’s (in)compatibility with the outside world, and someone suggested me to solve the problem by replacing the P420i RAID controller with an LSI-something which would ensure wider flexibility.

Others were suggesting to replace (again) the hard drives instead, and someone was even pushing to swap this “hobby” with something healthier and go cloud instead*.

For the first time in my life I decided to listen to friends, so I replaced the RAID controller with an LSI 9300i HBA (I’m using mdraid anyway)…

…well, not really: I also replaced the chassis, motherboard, CPU, RAM banks, fans, PSUs and drive caddies.

Meet “ZA Rev2″**:

This is how it evolved:

  • HP -> Supermicro (yay!)
  • Xeon E3-1240 v2 -> Xeon E3-1240 v6
  • 4×8 GB DDR3 RAM -> 2×16 GB DDR4 RAM (2 slots free for future upgrades)
  • HP P420i -> LSI-9300i
  • 2x SSD Samsung 850 EVO 250 GB -> no change
  • 2x HGST SATA 7.2k 1 TB -> no change

D-Day for replacement is April 18th (taking a day off from my job to go and do the same things, just for hobby, feels really weird, yes), with a 6 AM wake up call, flight to AMS, 8/10 hours to do everything and a flight back to LON (LTN to be precise, because I didn’t double check before hitting “Buy”).

Now to the sad part: there is no (easy) way to just move the drives to the new server and have everything working, so I have to reinstall it from the ground up. This means my stuff (including this blog, because loose-coupling is a thing but I decided to run its DB and NFS from another country… …for some reason) will be down (or badly broken) during that time window and possibly longer, depending how much I manage to do while I’m onsite.

The timing couldn’t be better for a clean start, as in the last few months I had been considering the option to move away (escape) from Proxmox (which, as an example, is so flexible that its management port number is hardcoded everywhere and can’t be changed) to something else, most likely oVirt or OpenNebula. Haven’t taken a decision yet, but I’ve really fallen in love with the latter: it’s perfect for the cloud-native minds and runs on Debian, whereas oVirt would force me to move to the RPM side of the world.

Deeply apologise in advance for my rants on Twitter while I try to accomplish this mission. Stay tuned.

Giorgio

 

* I.AM.100%.CLOUD. There are two things you can’t (yet) do in the cloud: physical backup of your assets that live in the cloud and testing stuff which requires VT extensions. This is what I’m doing here: ZA is my bare-metal lab.

** this is not ZA Rev2. It was supposed to be, but it came in with a faulty backplane so I pushed for it to be entirely replaced. I don’t have a picture of the new one with me at the time of writing but… yeah, it looks exactly the same (with better cable management).