I centri di dati muderni sò stallati centinaie di dispusitivi attivi, coperti da diversi tipi di surviglianza. Ma ancu un ingegnere ideale cù un monitoraghju perfettu in manu serà capace di risponde currettamente à un fallimentu di a rete in solu pochi minuti. In un rapportu à a cunferenza Next Hop 2020, aghju prisentatu una metodulugia di cuncepimentu di rete DC, chì hà una caratteristica unica - u centru di dati si guarisce in millisecondi. Più precisamente, l'ingegnere risolve tranquillamente u prublema, mentre chì i servizii simpliciamente ùn l'anu nutatu.
Per parechji ingegneri di rete, una reta di centru di dati principia, sicuru, cù ToR, cù un cambiamentu in u rack. ToR hà generalmente dui tipi di ligami. I chjuchi vanu à i servitori, altri - ci sò N volte più di elli - vanu versu e spine di u primu livellu, vale à dì à i so uplinks. Uplinks sò generalmente cunsiderate uguali, è u trafficu trà uplinks hè equilibratu basatu annantu à un hash da 5-tuple, chì include proto, src_ip, dst_ip, src_port, dst_port. Nisuna sorpresa quì.
In seguitu, chì vede l'architettura di u pianu? I spine di u primu livellu ùn sò micca cunnessi l'un à l'altru, ma sò cunnessi per superspines. A lettera X serà rispunsevuli di superspines; hè quasi cum'è un cross-connect.
È hè chjaru chì, invece, i tori sò cunnessi à tutte e spine di u primu livellu. Cosa hè impurtante in sta stampa? Se avemu interazzione in u rack, allora l'interazzione, sicuru, passa per ToR. Se l'interazzione si trova in u modulu, allora l'interazzione si trova attraversu e spine di u primu livellu. Se l'interazzione hè intermodulare - cum'è quì, ToR 1 è ToR 2 - allora l'interazzione passerà per spine di u primu è u sicondu livellu.
In teoria, una tale architettura hè facilmente scalabile. Sè avemu a capacità portu, spaziu di riserva in u centru di dati è fibra pre-laid, allura u numeru di corsi pò sempre esse aumentatu, cusì cresce a capacità generale di u sistema. Questu hè assai faciule da fà nantu à carta. Saria cusì in a vita. Ma a storia d'oghje ùn hè micca nantu à questu.
Vogliu chì e cunclusioni ghjustificate sò tratte. Avemu parechje strade in u centru di dati. Sò cundiziunali indipendenti. Una strada in u centru di dati hè pussibule solu in ToR. Dentru u modulu, avemu u numeru di camini uguali à u numeru di corsi. U numaru di camini trà i moduli hè uguali à u pruduttu di u numeru di piani è u numeru di superspines in ogni pianu. Per fà più chjaru, per avè un sensu di a scala, daraghju numeri chì sò validi per unu di i centri di dati Yandex.
Ci sò ottu piani, ogni pianu hà 32 superspines. In u risultatu, si trova chì ci sò ottu camini in u modulu, è cù l'interazzione intermodule ci sò digià 256 di elli.
Vale à dì, s'è no sviluppemu Cookbook, circannu d'amparà cumu custruisce centri di dati tolleranti à i difetti chì guariscenu elli stessi, allora l'architettura planar hè a scelta bona. Risolve u prublema di scala, è in teoria hè faciule. Ci sò parechje strade indipendenti. A quistione resta: cumu una tale architettura sopravvive à i fallimenti? Ci sò diversi fallimenti. È discutemu questu avà.
Chì unu di i nostri superspine "si ammalatu". Quì aghju vultatu à l'architettura di dui piani. Restemu cun questi cum'è un esempiu perchè serà simplicemente più faciule per vede ciò chì succede cù menu parti in muvimentu. Lasciate X11 malatu. Cumu affetterà questu i servizii chì campanu in i centri di dati? Moltu dipende da ciò chì u fallimentu veramente pare.
Se u fallimentu hè bonu, hè catturatu à u livellu di l'automatizazione di u stessu BFD, l'automatizazione felice mette l'articuli problematiche è isolate u prublema, allura tuttu hè bè. Avemu parechji percorsi, u trafficu hè istantaneamente re-routed à rotte alternative, è i servizii ùn anu micca nutatu nunda. Questu hè un bonu script.
Un cattivu scenariu hè s'ellu avemu pèrdite custanti, è l'automatizazione ùn hà micca avvistu u prublema. Per capisce cumu questu affetta una applicazione, avemu da passà un pocu di tempu discutendu cumu funziona TCP.
Spergu chì ùn scunvià nimu cù questa infurmazione: TCP hè un protocolu di cunferma di trasmissione. Questu hè, in u casu più simplice, u mittente manda dui pacchetti è riceve un ack cumulativu nantu à elli: "Aghju ricevutu dui pacchetti".
Dopu quì, mandarà dui pacchetti più, è a situazione si ripete. Scusate in anticipu per qualchì simplificazione. Stu scenariu hè currettu se a finestra (u numeru di pacchetti in volu) hè dui. Di sicuru, in u casu generale ùn hè micca necessariamente u casu. Ma a dimensione di a finestra ùn affetta micca u cuntestu di spedizione di pacchetti.
Chì succede se perdemu u pacchettu 3? In questu casu, u destinatariu riceverà i pacchetti 1, 2 è 4. È hà da dì esplicitamente à u mittente utilizendu l'opzione SACK: "Sapete, trè ghjunti, ma u mezu hè persu". Ellu dice: "Ack 2, SACK 4".
A stu mumentu, u mittente senza prublemi ripetiri esattamente u pacchettu chì era persu.
Ma s'è l'ultimu pacchettu in a finestra hè persu, a situazione serà completamente diversa.
U destinatariu riceve i primi trè pacchetti è prima di tuttu principia à aspittà. Grazie à alcune ottimisazioni in a pila TCP di u kernel Linux, aspittà per un pacchettu accoppiatu salvu chì i bandieri indicanu esplicitamente chì hè l'ultimu pacchettu o qualcosa simili. Aspittàrà finu à chì u timeout ACK ritardatu scade è dopu mandà un ricunniscenza à i primi trè pacchetti. Ma avà u mittente aspittà. Ùn sà micca s'ellu u quartu pacchettu hè statu persu o hè per arrivà. È per ùn sopraricà a reta, pruvarà à aspittà una indicazione esplicita chì u pacchettu hè persu, o chì u timeout RTO expire.
Chì ghjè u timeout RTO? Questu hè u massimu di u RTT calculatu da a pila TCP è qualchì constantu. Chì tipu di constantu hè questu, avemu da discutiri avà.
Ma l'impurtante hè chì s'è no simu sfurtunati di novu è u quartu pacchettu hè persu di novu, allora l'RTO raddoppia. Vale à dì, ogni tentativu insuccessu significa radduppià u timeout.
Avà vede ciò chì sta basa hè uguali. Per automaticamente, u RTO minimu hè 200 ms. Questu hè u RTO minimu per i pacchetti di dati. Per i pacchetti SYN hè diversu, 1 secondu. Comu pudete vede, ancu u primu tentativu di rinvià i pacchetti durarà 100 volte più di l'RTT in u centru di dati.
Avà vultemu à u nostru scenariu. Chì succede cù u serviziu ? U serviziu cumencia à perde i pacchetti. Chì u serviziu sia furtunatu in u primu tempu è perde qualcosa à mezu à a finestra, dopu riceve un SACK è rinvia i pacchetti chì sò stati persi.
Ma se a mala furtuna si ripete, allora avemu un RTO. Cosa hè impurtante quì? Iè, avemu assai chjassi in a nostra reta. Ma u trafficu TCP di una cunnessione TCP particulari continuarà à passà per a stessa pila rottu. A perdita di pacchetti, sempre chì questu X11 magicu di u nostru ùn esce micca da sè stessu, ùn porta micca à u trafficu chì scorri in e zone chì ùn sò micca problematiche. Pruvemu di furnisce u pacchettu attraversu a stessa pila rottu. Questu porta à un fallimentu in cascata: un centru di dati hè un inseme di applicazioni chì interagiscenu, è alcune di e cunnessione TCP di tutte queste applicazioni cumincianu à degradà - perchè a superspine afecta tutte l'applicazioni chì esistenu in u centru di dati. Cume si dice: s'è tù ùn fera micca un cavallu, u cavallu andò zoppu ; u cavallu si n'andò zoppu - u rapportu ùn hè statu fattu; u rapportu ùn hè statu fattu - avemu persu a guerra. Solu quì u cuntu hè in seconde da u mumentu chì u prublema nasce à u stadiu di degradazione chì i servizii cumincianu à sente. Questu significa chì l'utilizatori ponu mancassi qualcosa in qualchì locu.
Ci sò dui suluzioni classici chì cumplementarii. U primu hè i servizii chì cercanu di mette paglia è di risolve u prublema cusì: "Fighjemu qualcosa in a pila TCP. Facemu timeout à u livellu di l'applicazione o sessioni TCP di longa durata cù cuntrolli di salute internu ". U prublema hè chì tali suluzioni: a) ùn scala micca in tuttu; b) sò assai pocu verificati. Questu hè, ancu s'ellu u serviziu cunfigura accidintali a pila TCP in una manera chì a rende megliu, prima, hè improbabile chì sia applicabile per tutte l'applicazioni è tutti i centri di dati, è in segundu, assai prubabilmente, ùn capisce micca chì hè stata fatta. currettamente, è chì micca. Questu hè, funziona, ma travaglia pocu è ùn scala micca. È s'ellu ci hè un prublema di rete, quale hè a culpa ? Di sicuru, NOC. Cosa face NOC?
Parechji servizii credi chì in u travagliu NOC succede qualcosa cusì. Ma per esse onesto, micca solu questu.
NOC in u schema classicu hè impegnatu in u sviluppu di parechji sistemi di surviglianza. Quessi sò tramindui surviglianza di scatula nera è scatula bianca. Circa un esempiu di surviglianza spine di scatula negra Alexander Klimenko à l'ultimu Next Hop. Per via, stu surviglianza travaglia. Ma ancu u monitoraghju ideale avarà un ritardu di tempu. Di solitu questu hè uni pochi di minuti. Dopu ch'ellu si spegne, l'ingegneri di turnu necessitanu tempu per verificà u so funziunamentu, localizà u prublema è poi sguassate l'area problematica. Questu hè, in u megliu casu, u trattamentu di u prublema dura 5 minuti, in u peghju, 20 minuti, s'ellu ùn hè micca immediatamente evidenti induve a perdita si trova. Hè chjaru chì tuttu stu tempu - 5 o 20 minuti - i nostri servizii continuanu à soffrenu, chì probabilmente ùn hè micca bonu.
Chì vulete veramente riceve ? Avemu tanti modi. È i prublemi sò precisamente perchè i flussi TCP chì sò sfurtunati cuntinueghjanu à aduprà a stessa strada. Avemu bisognu di qualcosa chì ci permetterà di utilizà parechje rotte in una sola cunnessione TCP. Sembra chì avemu una suluzione. Ci hè TCP, chì hè chjamatu TCP multipath, vale à dì, TCP per parechje strade. True, hè statu sviluppatu per un compitu completamente diversu - per smartphones chì anu parechji dispositi di rete. Per maximizà u trasferimentu o fà u modu primariu / di salvezza, hè statu sviluppatu un mecanismu chì crea parechje fili (sessioni) in modu trasparente à l'applicazione è permette di cambià trà elli in casu di fallimentu. O, cum'è aghju dettu, maximizà a striscia.
Ma quì ci hè una sfumatura. Per capisce ciò chì hè, avemu da vede cumu i fili sò stabiliti.
I fili sò stallati in sequenza. U primu filu hè stallatu prima. I fili successivi sò allora stabiliti utilizendu a cookie chì hè digià statu accunsentutu in quellu filu. È quì hè u prublema.
U prublema hè chì, se u primu filu ùn si stabilisce micca, u sicondu è u terzu filu ùn saranu mai. Questu hè, TCP multipath ùn risolve micca a perdita di un pacchettu SYN in u primu flussu. È se u SYN hè persu, u TCP multipath si trasforma in TCP regular. Questu significa chì in un ambiente di centru di dati ùn ci aiuterà micca à risolve u prublema di perdite in a fabbrica è amparà à aduprà parechje strade in casu di fallimentu.
Chì ci pò aiutà? Qualchidunu di voi avete digià invintatu da u titulu chì un campu impurtante in a nostra storia ulteriore serà u campu di l'intestazione di l'etichetta di flussu IPv6. In verità, questu hè un campu chì appare in v6, ùn hè micca in v4, occupa 20 bits, è ci hè stata cuntruversia annantu à u so usu per un bellu pezzu. Questu hè assai interessante - ci sò stati disputi, qualcosa era riparatu in u RFC, è à u stessu tempu una implementazione apparsu in u kernel Linux, chì ùn era micca documentatu in ogni locu.
Vi invitu à andà cun mè in una piccula investigazione. Fighjemu un ochju à ciò chì hè accadutu in u kernel Linux in l'ultimi anni.
annu 2014. Un ingegnere da una cumpagnia grande è rispettata aghjunghje à a funziunalità di u kernel Linux a dependenza di u valore di l'etichetta di flussu nantu à u socket hash. Chì anu pruvatu à risolve quì ? Questu hè in relazione cù RFC 6438, chì hà discututu u prublema dopu. Dentru u centru di dati, l'IPv4 hè spessu incapsulatu in pacchetti IPv6, perchè a fabbrica stessa hè IPv6, ma IPv4 deve esse datu fora. Per un bellu pezzu ci sò stati prublemi cù i switches chì ùn puderanu micca circà sottu à dui intestazioni IP per ghjunghje à TCP o UDP è truvà src_ports, dst_ports quì. Risultava chì l'hash, se fighjate à i primi dui intestazioni IP, s'era quasi riparatu. Per evitari questu, per chì l'equilibriu di stu trafficu incapsulatu funziona bè, hè stata pruposta di aghjunghje l'hash di u pacchettu incapsulatu 5-tuple à u valore di u campu di l'etichetta di flussu. Apprussimatamente a stessa cosa hè stata fatta per altri schemi di incapsulazione, per UDP, per GRE, l'ultimu hà utilizatu u campu GRE Key. Un modu o un altru, i scopi quì sò chjaru. E almenu à quellu puntu in u tempu eranu utili.
In 2015, un novu patch vene da u listessu ingegnere rispettatu. Hè assai interessante. Dice u seguitu - randomizemu l'hash in casu d'un avvenimentu di routing negativu. Chì ghjè un avvenimentu di routing negativu? Questu hè u RTO chì avemu discututu prima, vale à dì, a perdita di a cuda di a finestra hè un avvenimentu chì hè veramente negativu. True, hè relativamente difficiule di guessà chì questu hè questu.
2016, una altra cumpagnia reputable, ancu grande. Disassemble l'ultimi crutches è face cusì chì l'hash, chì avemu fattu prima aleatoriu, cambia avà per ogni retransmission SYN è dopu ogni timeout RTO. È in questa lettera, per a prima è l'ultima volta, u scopu ultimu hè statu dichjaratu - per assicurà chì u trafficu in casu di perdite o di congestione di canali hà a capacità di esse re-routed suavemente è aduprà parechje strade. Di sicuru, dopu à questu ci era assai publicazioni, pudete truvà facilmente.
Ancu s'è no, ùn pudete micca, perchè ùn hè micca stata una sola publicazione nantu à questu tema. Ma sapemu !
È s'è vo ùn capisce cumplettamente ciò chì hè statu fattu, vi dicu avà.
Chì hè statu fattu, chì funziunalità hè stata aghjunta à u kernel Linux? txhash cambia à un valore aleatoriu dopu ogni avvenimentu RTO. Questu hè u risultatu assai negativu di u routing. L'hash dipende da questu txhash, è l'etichetta di u flussu dipende da l'skb hash. Ci sò qualchi calculi nantu à e funzioni quì; tutti i dettagli ùn ponu micca esse posti nantu à una sola slide. Se qualchissia hè curiosu, pudete passà per u codice di u kernel è verificate.
Cosa hè impurtante quì? U valore di u campu di l'etichetta di flussu cambia in un numeru aleatoriu dopu ogni RTO. Cumu affetta questu u nostru disgraziatu flussu TCP?
Se si verifica un SACK, nunda ùn cambia perchè pruvemu di rinvià un pacchettu persu cunnisciutu. Finu à quì bè.
Ma in u casu di RTO, basta chì avemu aghjustatu una etichetta di flussu à a funzione hash in ToR, u trafficu pò piglià una strada diversa. E più corsi, più grande hè a probabilità di truvà una strada chì ùn hè micca affettata da un fallimentu in un dispositivu particulari.
Un prublema resta - RTO. Di sicuru, ci hè una altra strada, ma assai tempu hè persu in questu. 200 ms hè assai. Un secondu hè assolutamente salvaticu. Prima, aghju parlatu di timeouts chì i servizii sò cunfigurati. Dunque, un secondu hè un timeout, chì hè generalmente cunfiguratu da u serviziu à u livellu di l'applicazione, è in questu u serviziu serà ancu relativamente ghjustu. Inoltre, ripete, u veru RTT in un centru di dati mudernu hè di circa 1 millisecondu.
Chì pudete fà cù i timeout RTO? U timeout, chì hè rispunsevuli di RTO in casu di perdita di pacchetti di dati, pò esse cunfiguratu relativamente facilmente da u spaziu di l'utilizatori: ci hè una utilità IP, è unu di i so paràmetri cuntene u stessu rto_min. In cunsiderà chì RTO, sicuru, deve esse aghjustatu micca in u mondu, ma per prefissi dati, un tali mecanismu pare abbastanza praticabile.
True, cù SYN_RTO tuttu hè un pocu peghju. Hè naturalmente inchiodata. U kernel hà un valore fissu di 1 secondu, è questu hè. Ùn pudete micca ghjunghje quì da u spaziu di l'utilizatori. Ci hè solu un modu.
eBPF vene in salvezza. Per esse simplicemente, questi sò picculi prugrammi C. Puderanu esse inseriti in ganci in diversi lochi in l'esekzione di a pila di kernel è a pila TCP, cù quale pudete cambià un gran numaru di paràmetri. In generale, eBPF hè una tendenza à longu andà. Invece di taglià decine di novi paràmetri sysctl è espansione l'utilità IP, u muvimentu si move versu eBPF è espansione a so funziunalità. Utilizendu eBPF, pudete cambià dinamicamente i cuntrolli di congestione è diverse altre paràmetri TCP.
Ma hè impurtante per noi chì pò esse usatu per cambià i valori SYN_RTO. Inoltre, ci hè un esempiu publicatu publicamente: . Chì hè statu fattu quì ? L'esempiu hè travagliatu, ma in sè stessu hè assai aspra. Quì si assume chì in u centru di dati paragunemu i primi 44 bits; se currispondenu, allora simu in u centru di dati. È in questu casu cambiamu u valore di timeout SYN_RTO à 4ms. U listessu compitu pò esse fattu assai più elegante. Ma stu simplice esempiu mostra chì questu hè a) pussibule; b) relativamente simplice.
Chì sapemu digià ? U fattu chì l'architettura di l'aereo permette di scaling, risulta esse estremamente utile per noi quandu attivemu l'etichetta di flussu in ToR è uttene a capacità di flussu intornu à e zone problematiche. U megliu modu per riduce i valori RTO è SYN-RTO hè di utilizà prugrammi eBPF. A quistione resta: hè sicuru d'utilizà una etichetta di flussu per equilibriu? È quì ci hè una sfumatura.
Supponete chì avete un serviziu in a vostra reta chì vive in anycast. Sfurtunatamente, ùn aghju micca u tempu d'andà in i detaglii di ciò chì anycast hè, ma hè un serviziu distribuitu cù diversi servitori fisichi accessibili via u stessu indirizzu IP. È quì hè un prublema pussibule: l'avvenimentu RTO pò accade micca solu quandu u trafficu passa per u tissu. Puderà ancu accade à u nivellu di u buffer ToR: quandu un avvenimentu incastu accade, pò ancu accade in l'ospitu quandu l'ospite spills qualcosa. Quandu si verifica un avvenimentu RTO è cambia l'etichetta di flussu. In questu casu, u trafficu pò andà in un altru casu anycast. Assumimu chì questu hè un anycast stateful, cuntene un statu di cunnessione - puderia esse un L3 Balancer o un altru serviziu. Allora hè un prublema, perchè dopu à RTO a cunnessione TCP ghjunghje à u servitore, chì ùn sapi nunda di sta cunnessione TCP. È s'ellu ùn avemu micca sparte di u statu trà i servitori anycast, allora tali trafficu serà abbandunatu è a cunnessione TCP serà rotta.
Chì pudete fà quì ? In u vostru ambiente cuntrullatu, induve attivate l'equilibriu di l'etichetta di flussu, avete bisognu di registrà u valore di l'etichetta di flussu quandu accede à i servitori anycast. A manera più faciule hè di fà questu attraversu u listessu prugramma eBPF. Ma quì hè un puntu assai impurtante - chì fà s'ellu ùn operate micca una reta di centru di dati, ma sò un operatore di telecomunicazione? Questu hè ancu u vostru prublema: cuminciendu cù certe versioni di Juniper è Arista, includenu una etichetta di flussu in e so funzioni di hash per difettu - francamente, per un mutivu chì ùn hè micca chjaru per mè. Chistu pò fà caccià e cunnessione TCP da l'utilizatori chì passanu per a vostra reta. Allora vi cunsigliu assai di verificà i paràmetri di i vostri routers quì.
Un modu o un altru, mi pare chì simu pronti à passà à spirimenti.
Quandu avemu attivatu l'etiqueta di flussu nantu à ToR, preparatu l'agentu eBPF, chì avà vive nantu à l'ospiti, avemu decisu di ùn aspittà micca u prossimu grande fallimentu, ma di fà esplusioni cuntrullati. Avemu pigliatu ToR, chì hà quattru uplinks, è hà stallatu gocce nantu à unu di elli. Dissenu una regula è dicenu - avà perdi tutti i pacchetti. Comu pudete vede à a manca, avemu un monitoraghju per pacchettu, chì hè cascatu à 75%, vale à dì, 25% di i pacchetti sò persi. À a diritta sò gràfiche di servizii chì campanu daretu à stu ToR. Essenzialmente, questi sò grafici di trafficu di l'interfaccia cù i servitori in u rack. Comu pudete vede, anu affundatu ancu più bassu. Perchè anu cascatu più bassu - micca da 25%, ma in certi casi da 3-4 volte? Se a cunnessione TCP hè sfurtunata, cuntinueghja à pruvà à ghjunghje à traversu a junction rottu. Questu hè aggravatu da u cumpurtamentu tipicu di u serviziu in u DC - per una dumanda di l'utilizatori, N dumande à i servizii interni sò generati, è a risposta andarà à l'utilizatore sia quandu tutte e fonti di dati rispundenu, sia quandu un timeout si verifica in l'applicazione. livellu, chì deve ancu esse cunfiguratu. Questu hè, tuttu hè assai, assai male.
Avà u stessu esperimentu, ma cù u valore di l'etichetta di flussu attivatu. Comu si pò vede, à a manca u nostru surviglianza batch cascatu da u listessu 25%. Questu hè assolutamente currettu, perchè ùn sapi nunda di retransmits, manda pacchetti è simpricimenti cunta u rapportu di u numeru di pacchetti consegnati è persi.
È à a diritta hè u schedariu di serviziu. Ùn truverete micca l'effettu di una articulazione problematica quì. In quelli stessi millisecondi, u trafficu scorri da l'area problematica à i trè uplinks restanti chì ùn anu micca affettatu da u prublema. Avemu una reta chì guarisce sè stessu.
Questa hè a mo ultima diapositiva, u tempu di riassume. Avà, speru chì sapete cumu custruisce una reta di centru di dati auto-guarigione. Ùn averete micca bisognu di passà per l'archiviu di u kernel Linux è cercate patchs speciale quì; sapete chì l'etichetta Flow in questu casu risolve u prublema, ma avete bisognu di avvicinà stu mecanismu cun cura. È enfatizendu una volta di più chì sè site un operatore di telecomunicazione, ùn deve micca aduprà l'etichetta di flussu cum'è una funzione di hash, altrimenti disturberate e sessioni di l'utilizatori.
L'ingegneri di a rete deve esse sottumessi à un cambiamentu conceptuale: a reta ùn principia micca cù u ToR, micca cù u dispositivu di a rete, ma cù l'ospite. Un esempiu abbastanza sorprendente hè cumu usemu eBPF sia per cambià l'RTO sia per riparà l'etichetta di flussu versu i servizii anycast.
A meccanica di l'etichetta di flussu hè certamente adattata per altre applicazioni in u segmentu amministrativu cuntrullatu. Questu pò esse u trafficu trà i centri di dati, o pudete aduprà tali meccanica in una manera speciale per gestisce u trafficu in uscita. Ma vi dicu di questu, speru, a prossima volta. Grazie assai per a vostra attenzione.
Source: www.habr.com