Knowledgebase

OnAPP - Un giorno di ordinaria follia

Tutto procedeva secondo i piani, dopo che in Dicembre, OnAPP (società che si occupa dello sviluppo del nostro software Cloud) ci aveva contattato proponendoci la nuova soluzione che avrebbe risolto i problemi che ci avevano spinto ad abbandonarli a favore dei MyCore. Proviamo in lab la nuova piattaforma e cavoli, funziona, va che è una bomba! Da li la decisione, "aggiornamentone" totale della piattaforma, i clienti saranno soddisfatti e porteremo CloudFlow ai fasti che merita, poi ci guardiamo in faccia e uno dello staff esclama: "Dobbiamo aggiornare live quasi 60 nodi con un salto da CentOS 6 a CentOS 7, cambiare il backend dello storage e infine portare la connettività dedicata ai vDisk da 10 a 40GB..... siete sicuri, è follia!" Ma in SeFlow amiamo la follia e sappiamo i nostri clienti cosa meritano. Quindi, parafrasando una citazione dalla cellulosa il nostro IT Manager si alza ed esclama: follia? follia!?! Questa è SeFlow!

Iniziamo quindi i preparativi, la strada è lunga, ma la voglia è tanta e iniziamo i lavori. Spostiamo il Pannello di Controllo in un ambiente in alta affidabilità, e tutto procede senza intoppi, nel mentre eseguiamo l' upgrade all' ultima release stable, template completamente nuovo ed un backend perfezionato. Il pannello viaggia che è una bomba e ci sono moltissime nuove features che attiveremo dopo gli upgrade!.

Iniziamo con Strasburgo, i clienti già migrati han visto i primi effetti sulle loro VM:

#Vecchia infrastruttura
# dd if=/dev/zero of=/performance bs=1M count=1024 conv=fdatasync | grep MB/s
1073741824 bytes (1.1 GB) copied, 13.24321 s, 47 MB/s

Nuova Infrastruttura
# dd if=/dev/zero of=/performance bs=1M count=1024 conv=fdatasync | grep MB/s
1073741824 bytes (1.1 GB) copied, 1.27325 s, 843 MB/s

 

Non male eh? :-)

La migrazione è automatica, solitamente fatta di notte, il cliente riceve la mail di inizio migrazione e, in base allo spazio occupato dalla vm si ha dai 10 minuti alle due ore di fermo. Quando il sistema riporte Voilà, più veloci del vento ( san NVMe ).  Allo stato attuale quasi tutte le vm sono state migrate, controllo, ne mancano 22, 24 ore e strasburgo è tutto sulla nuova piattaforma, hip hip!

Nel mentre parte dello staff inizia Milano, qui il challenge è più impegnativo. A Milano le vm hanno ridondanza geografica e si lavora su filesystem distribuito.  Dobbiamo andare per gradi. Chiediamo informazioni al supporto OnAPP che ci assicura che si può fare nodo per nodo, ottimo! 

Premessa: il sistema mantiene sincronizzate le immagini tra i datacenter, in condizioni normali (come siamo ora) quando tutte le copie sono in sync abbiamo questo risultato:

[root@10.0.0.110 ~]# getdegradedvdisks

No Degraded vDisks

[root@10.0.0.110 ~]#

 

Bene, programmiamo l' inizio dei lavori. Era un giorno di Febbraio come tanti, il 7 per la precisione, e iniziamo con migrare le vm via dal primo nodo, qui la situazione è delicata, bisogna spegnere il nodo, cambiare la scheda di rete da 10 a 40Gb accendere il nodo rifare la mappatura per la rete storage e per la rete uplink e rimigrare indietro le vm. Tutto trasparete e facile direte voi no? No, murphy è sempre li che attende. Riavviamo il primo nodo, rifacciamo la mappatura e lanciamo il repair disk:

[root@10.0.0.110 ~]#  parallelrepairvdisks

mismatch version detected. Blocking  operation

[root@10.0.0.110 ~]#

Cosa??? Subito di corsa a sentire OnAPP e ci fanno l' escalation al L2 dal quale la tragedia "la versione attualmente installata è troppo vecchia per il salto diretto è probabile che ora tutti i dischi vadano in degrado".... controlliamo

[root@10.0.0.110 ~]# getdegradedvdisks

Degraded vDisks: 4192

[root@10.0.0.110 ~]#

Ok Ok calma, i clienti han le macchine ancora operative, dobbiamo trovare una soluzione, sentiamo OnAPP... prontamente rispondono "spegnete tutte le macchine e riavviare tutti i nodi per portare alla versione 6.2". Ma come??? Non posso riavviare brutalmente i nodi i clienti hanno i database e file aperti, significa corruzione!! 

Da qui l' amara decisione, spegnere tutte le vm poi fare un riavvio dei nodi. Ore 21.40 del venerdì sera iniziamo a spegnere le vm. Riavviamo i nodi con CentOS 7 CloudBoot e rifacciamo la mappatura 1 ad 1  di ogni singolo nodo. Eh si perchè i problemi non finiscono qui, il passaggio da CentOS 6 a CentOS 7 causa il cambio di nomi delle interfacce, vanno rimappate!  Visto che c'è da riavviare tutto riavviamo anche il primo nodo portandolo a CentOS 7 e avviamo le vm.... cavoli le vm sono accese, ma non vanno in rete perchè?? Perchè sviluppare soluzioni banali ad OnAPP non piace, quindi cosa han fatto? ad ogni avvio del Nodo impostano un mac virtuale che sovrascrive i vecchi! 

A quel punto che fare? Rimappare a nostra volta le schede di rete con nomi appropriati sfruttando l' alias 

#Fix Onapp that try to load appbond interface

ifconfig eth2 down

nic0=`ifconfig -a | grep -i 00:25:90:af:e7:e7 -B2 | cut -c1-4 | grep eth`

ip link set $nic0 name appbond

 

Bene ci siamo quasi Ora i nodi stanno tornato operativi e le vm rispondono in rete, ma dannazione, le operazioni sono lunghe, sono le 8.30 dell' 8 Febbraio, qui nessuno ha dormito e siamo a metà dei nodi... la palpebra cala, ma "quei clienti andavano portati in salvo". 

Ora 11.00 tutti i nodi sono operativi e le vm sono ragigungibili. I clienti sono salvi, mandiamo alcuni eroi in branda, rimangono quelli i nosti leaders a riparare i dischi e, dannazione altra sorpresa:

 

[root@10.0.0.67 ~]# onappstore diskinfo uuid=ge2qpcv1j5au0y readable=true
snapshots = []
datastore = horu6n52m7f0kv
hostids = 13,6
size = 17179869184
sector_size = 65536
insyncstatus = 0
uuid = ge2qpcv1j5au0y
utilization = 144176
st_size = 256
transaction_id = 0
status = 1
memberinfo = {
2213972629: {u'status': 1, u'numkeys': 72186, u'frontend': [u'10.200.21.254'], u'nodestatus': 1, u'seqno': 386242848, u'snap_limit': 10, u'membership_gen_count': 1, u'st_mem': 0, u'cache_state': {u'writethrough': [], u'passthrough': [], u'none': [], u'writeback': []}, u'port': 33577}
30960430: {u'status': 0, u'frontend': [u'0.0.0.0'], u'nodestatus': 2, u'seqno': 0, u'snap_limit': 10, u'membership_gen_count': 1, u'st_mem': 0, u'numkeys': 72145, u'port': 48581}

4027819128: {u'status': 1, u'numkeys': 71990, u'frontend': [u'10.200.21.254'], u'nodestatus': 1, u'seqno': 357830744, u'snap_limit': 10, u'membership_gen_count': 1, u'st_mem': 1, u'cache_state': {u'writethrough': [], u'passthrough': [], u'none': [], u'writeback': []}, u'port': 31858}
3017055529: {u'status': 4, u'numkeys': 71954, u'frontend': [u'0.0.0.0'], u'nodestatus': 1, u'seqno': 0, u'snap_limit': 10, u'membership_gen_count': 1, u'st_mem': 1, u'cache_state': {u'writethrough': [], u'passthrough': [], u'none': [], u'writeback': []}, u'port': 62099}
}
description = bujtvqwwgcwkst
replicas = 2
membership = [u'4027819128', u'3017055529', u'2213972629', u'30960430']
members = 4027819128,3017055529,2213972629,30960430
utilization_percent = 54
name = bujtvqwwgcwkst
sectors = 262144
st_mems = 2
redundant = True
size_MB = 16384
snapshot = 0
Datastore = horu6n52m7f0kv

Durante il trambusto alcune immagini non riescono a sincronizzarsi, quindi che fare?  si escludono le immagini non sincronizzabili e si ricrea manualmente il sync. una immagine per volta, a mano per altre 347 volte... 

 

[root@10.0.0.67 ~]# onappstore forget forgetlist=30960430 vdisk_uuid=ge2qpcv1j5au0y
result=SUCCESS completion_time=2
[root@10.0.0.67 ~]# onappstore repairmembership uuid=ge2qpcv1j5au0y
result=SUCCESS completion_time=15
[root@10.0.0.67 ~]# onappstore repair uuid=ge2qpcv1j5au0y
info="Repair process has been initiated, please use resynchstatus CLI to get status of the resynchronization." state=PENDING result=SUCCESS completion_time=9
[root@10.0.0.67 ~]#

Ore 00.43 del 9 Febbraio, tutte le immagini sono in sync e wow, i nodi sono già in CentOS 7 con le nuove funzionalità, ma wow siamo svegli da 42 ore filate... 

 

Situazione Attuale....

Veniamo ad oggi, le occhiaie se ne sono andate, la calma regna sovrana e

[root@10.0.0.50 ~]# getdegradedvdisks

No Degraded vDisks

[root@10.0.0.50 ~]#

 

tutto va a meraviglia. La region Milano funziona molto bene, alcuni nodi sono già a 40Gb, altri passeranno nelle prossime settimane, ma non ci saranno altri problemi perchè il software è già tutto impostato, van solo inserite le schede e il nodo partirà. Ovviamente non ci saranno ulteriori downtime per i clienti in quanto il lavoro si fa a nodo svuotato.

 

Ma dopo tutto questo quali sono i vantaggi?

  • Le risorse ora sono completamente dedicate come con i MyCore, non c'è più il rischio di poweroff improvvisi delle vm
  • I vdisk ora rimangono veramente sincronizzati senza causare i vecchi fastidiosi i/o error nelle vm
  • Al completamente del passaggio a 40Gb a Milano ci sarà un notevole miglioramente prestazionale in I/O. Le vm a Strasburgo stanno già godendo :-)

 

Perchè tutto questo?

Perchè CloudFlow sarà il nostro nuovo servizio di punta con tantissime nuove novità, alcune anticipazioni?

  • i/o prestazionali come SSD anche in ambiente di ridondanza geografica (apena tutti i nodi saranno aggiornati a 40Gb sarà automatico su tutte le vm a Milano)
  • Nuovi template disponibili
  • Possibilità di ordinare risorse Cloud (come il cloudflow) oppure VM a pacchetti sia su base oraria che mensile
  • I Clienti CloudFlow potranno velocizzare la creazione delle VM sfruttando anche pacchetti con risorse prestabilite (o potrete creare vm con risorse a piacimento come sempre)
  • VM Virtual Routers. Potrete, come un vostro datacenter, creare VM con ip privati e gestire il routing dai Virtual Routers. Potrete quindi creare ambienti protetti, per esempio creando VR con soluzioni di firewalling come pfsense
  • Aggiunta di nuove Region basate su tecnologia NVMe
  • Protezione DDoS Inclusa in tutte le regions
  • Supporto per i Containers

..... e molto altro.

  • 4 Users Found This Useful

Was this answer helpful?