Saluton, Habr-legantoj! La temo de ĉi tiu artikolo estos la efektivigo de katastrofaj reakiro en AERODISK Engine stoksistemoj. Komence, ni volis skribi en unu artikolo pri ambaŭ iloj: reproduktado kaj metrogrupo, sed, bedaŭrinde, la artikolo montriĝis tro longa, do ni dividis la artikolon en du partojn. Ni iru de simpla al kompleksa. En ĉi tiu artikolo, ni starigos kaj testos sinkronan reproduktadon - ni faligos unu datumcentron, kaj ankaŭ rompos la komunikadkanalon inter la datumcentroj kaj vidos kio okazas.
Niaj klientoj ofte demandas al ni diversajn demandojn pri reproduktado, do antaŭ ol komenci starigi kaj testi la efektivigon de kopioj, ni diros al vi iomete pri kio estas reproduktado en stokado.
Iom teorio
Reproduktado en stokadsistemoj estas kontinua procezo de certigado de datenidenteco sur pluraj stokadsistemoj samtempe. Teknike, reproduktado estas plenumita laŭ du manieroj.
Sinkrona reproduktado – ĉi tio estas kopii datumojn de la ĉefa konserva sistemo al la rezerva, sekvata de deviga konfirmo de ambaŭ stokadsistemoj, ke la datumoj estas registritaj kaj konfirmitaj. Estas post konfirmo ambaŭflanke (ambaŭ konservadsistemoj) ke la datumoj estas konsiderataj registritaj kaj povas esti kunlaboritaj. Ĉi tio certigas garantiitan datumidentecon sur ĉiuj stoksistemoj partoprenantaj en la kopio.
La avantaĝoj de ĉi tiu metodo:
- Datumoj ĉiam estas identaj en ĉiuj stokaj sistemoj
Kons:
- Alta kosto de la solvo (rapidaj komunikaj kanaloj, multekosta optika fibro, long-ondaj transceptoroj, ktp.)
- Distancimigoj (ene de pluraj dekoj de kilometroj)
- Ne ekzistas protekto kontraŭ logika datuma korupto (se datumoj estas koruptitaj (intence aŭ hazarde) sur la ĉefa stokada sistemo, ĝi aŭtomate kaj tuj koruptiĝos ĉe la rezerva, ĉar la datumoj ĉiam estas identaj (tio estas la paradokso)
Nesinkrona reproduktado – ĉi tio ankaŭ estas kopii datumojn de la ĉefa konserva sistemo al la rezerva, sed kun certa malfruo kaj sen neceso konfirmi la skribon aliflanke. Vi povas labori kun datumoj tuj post registri ĝin al la ĉefa stokadosistemo, kaj sur la rezerva stokadosistemo la datumoj estos disponeblaj post iom da tempo. La identeco de la datumoj en ĉi tiu kazo, kompreneble, tute ne estas certigita. La datumoj pri la rezerva stokado estas ĉiam iom "en la pasinteco".
Avantaĝoj de nesinkrona reproduktado:
- Malaltkosta solvo (iuj komunikadkanaloj, optiko laŭvola)
- Neniuj distanclimigoj
- Sur la rezerva stokadsistemo, datumoj ne difektas se ĝi estas difektita sur la ĉefa (almenaŭ dum iom da tempo); se la datumoj koruptiĝas, vi ĉiam povas ĉesigi la kopion por malhelpi datuman korupton sur la rezerva stokadosistemo.
Kons:
- Datumoj en malsamaj datumcentroj ĉiam ne estas identaj
Tiel, la elekto de reprodukta reĝimo dependas de komercaj celoj. Se estas kritike por vi, ke la rezerva datumcentro enhavas precize la samajn datumojn kiel la ĉefa datumcentro (t.e. komerca postulo por RPO = 0), tiam vi devos forĵeti la monon kaj elteni la limojn de sinkrona. kopio. Kaj se la prokrasto en la datuma stato estas akceptebla aŭ simple mankas mono, tiam vi certe devas uzi la nesinkronan metodon.
Ni aparte reliefigu ankaŭ tian reĝimon (pli precize, topologion) kiel metrogrupon. En metrocluster-reĝimo, sinkrona reproduktado estas uzita, sed, male al regula kopio, metrocluster permesas al ambaŭ stokadsistemoj funkciigi en aktiva reĝimo. Tiuj. vi ne havas apartigon inter aktivaj kaj standby datumcentroj. Aplikoj funkcias samtempe kun du stokaj sistemoj, kiuj fizike troviĝas en malsamaj datumcentroj. Malfunkcioj dum akcidentoj en tia topologio estas tre malgrandaj (RTO, kutime minutoj). En ĉi tiu artikolo ni ne konsideros nian efektivigon de la metrogrupo, ĉar ĉi tio estas tre granda kaj ampleksa temo, do ni dediĉos al ĝi apartan, sekvan artikolon, en daŭrigo de ĉi tiu.
Ankaŭ, tre ofte, kiam ni parolas pri reproduktado per stokadsistemoj, multaj homoj havas akcepteblan demandon: > “Multaj aplikaĵoj havas siajn proprajn reproduktajn ilojn, kial uzi reproduktadon sur stokadsistemoj? Ĉu ĝi estas pli bona aŭ pli malbona?
Ne estas klara respondo ĉi tie, do jen la argumentoj POR kaj KONSULOJ:
Argumentoj POR stokado-reproduktado:
- Simpleco de la solvo. Per unu ilo, vi povas reprodukti vian tutan datuman aron, sendepende de ŝarĝa tipo kaj aplikaĵo. Se vi uzas kopion de aplikaĵoj, vi devos agordi ĉiun aplikaĵon aparte. Se estas pli ol 2 el ili, tiam ĉi tio estas ege labor-intensa kaj multekosta (reproduktado de aplikaĵoj kutime postulas apartan kaj ne liberan permesilon por ĉiu aplikaĵo. Sed pli pri tio ĉi sube).
- Vi povas reprodukti ion ajn - ajnan aplikaĵon, ajnajn datumojn - kaj ĝi ĉiam estos konsekvenca. Multaj (plej) aplikoj ne havas reproduktajn kapablojn, kaj kopioj de la stokadsistemo estas la nura maniero provizi protekton kontraŭ katastrofoj.
- Ne necesas tropagi por aplikaĵo-reproduktadfunkcio. Ĝenerale, ĝi ne estas malmultekosta, same kiel licencoj por kopio de konserva sistemo. Sed vi devas pagi por permesilo por konservada reproduktado unufoje, kaj permesilo por aplikaĵa kopio devas esti aĉetita por ĉiu aplikaĵo aparte. Se ekzistas multaj tiaj aplikoj, tiam ĝi kostas belan pencon kaj la kosto de licencoj por stokado-reproduktado fariĝas guto en la oceano.
Argumentoj KONTRAŭ stokadreproduktado:
- Repliko per aplikoj havas pli da funkcieco el la vidpunkto de la aplikoj mem, la aplikaĵo konas siajn datumojn pli bone (evidente), do ekzistas pli da ebloj por labori kun ili.
- Fabrikistoj de iuj aplikaĵoj ne garantias la konsekvencon de siaj datumoj se reproduktado estas farita per triaj iloj. *
* - polemika tezo. Ekzemple, konata DBMS-fabrikisto oficiale deklaras dum tre longa tempo, ke ilia DBMS nur povas esti reproduktita normale uzante siajn rimedojn, kaj la resto de la reproduktado (inkluzive de stokadsistemoj) estas "ne vera". Sed la vivo montris, ke tio ne estas tiel. Plej verŝajne (sed ĉi tio ne estas certa) ĉi tio simple ne estas la plej honesta provo vendi pli da licencoj al klientoj.
Kiel rezulto, en la plej multaj kazoj, reproduktado de la stokadsistemo estas pli bona, ĉar Ĉi tio estas pli simpla kaj malpli multekosta opcio, sed estas kompleksaj kazoj kiam necesas specifa aplikaĵofunkcio, kaj necesas labori kun aplikaĵ-nivela reproduktado.
Finite kun teorio, nun praktiko
Ni agordos la kopion en nia laboratorio. En laboratoriokondiĉoj, ni kopiis du datumcentrojn (fakte, du apudaj rakoj, kiuj ŝajnis esti en malsamaj konstruaĵoj). La stando konsistas el du stokaj sistemoj de Engine N2, kiuj estas konektitaj unu al la alia per optikaj kabloj. Fizika servilo funkcianta Windows Server 2016 estas konektita al ambaŭ stokadsistemoj uzante 10Gb Ethernet. La stando estas sufiĉe simpla, sed ĉi tio ne ŝanĝas la esencon.
Skeme ĝi aspektas jene:
Logike, reproduktado estas organizita jene:
Nun ni rigardu la reproduktan funkcion, kiun ni nun havas.
Du reĝimoj estas subtenataj: nesinkrona kaj sinkrona. Estas logike, ke la sinkrona reĝimo estas limigita per distanco kaj komunika kanalo. Aparte, sinkrona reĝimo postulas la uzon de fibro kiel la fiziko kaj 10 Gigabit Ethernet (aŭ pli alta).
La subtenata distanco por sinkrona reproduktado estas 40 kilometroj, la prokrasta valoro de la optika kanalo inter datumcentroj estas ĝis 2 milisekundoj. Ĝenerale, ĝi funkcios kun grandaj prokrastoj, sed tiam estos fortaj malrapidiĝoj dum registrado (kio ankaŭ estas logika), do se vi planas sinkronan reproduktadon inter datumcentroj, vi devus kontroli la kvaliton de la optiko kaj la prokrastoj.
La postuloj por nesinkrona reproduktado ne estas tiel seriozaj. Pli precize, ili tute ne estas tie. Ajna funkcianta Ethernet-konekto funkcios.
Nuntempe, la stokadsistemo AERODISK ENGINE subtenas reproduktadon por blokaparatoj (LUNoj) per la Eterreto-protokolo (super kupro aŭ optika). Por projektoj, kie reproduktado per SAN-ŝtofo super Fibra Kanalo estas postulata, ni nuntempe aldonas taŭgan solvon, sed ĝi ankoraŭ ne estas preta, do en nia kazo, nur Ethernet.
Reproduktado povas funkcii inter ajnaj ENGINE-seriaj stoksistemoj (N1, N2, N4) de junioraj sistemoj ĝis pli malnovaj kaj inverse.
La funkcieco de ambaŭ reproduktaj reĝimoj estas tute identa. Malsupre estas pliaj detaloj pri kio disponeblas:
- Repliko "unu al unu" aŭ "unu al unu", tio estas, la klasika versio kun du datumcentroj, la ĉefa kaj la rezerva
- Reproduktado estas "unu al multaj" aŭ "unu al multaj", t.e. unu LUN povas esti reproduktita al pluraj stokadsistemoj samtempe
- Aktivigi, malaktivigi kaj "inversigi" reproduktadon, respektive, por ebligi, malŝalti aŭ ŝanĝi la direkton de reproduktado
- Reproduktado estas havebla por kaj RDG (Raid Distributed Group) kaj DDP (Dynamic Disk Pool) naĝejoj. Tamen, LUNoj de RDG-naĝejo povas nur esti reproduktitaj al alia RDG. Same kun DDP.
Estas multaj pli malgrandaj funkcioj, sed ne estas aparta celo listigi ilin; ni mencios ilin dum ni starigas.
Agordi reproduktadon
La agorda procezo estas sufiĉe simpla kaj konsistas el tri etapoj.
- Reta agordo
- Agordo de stokado
- Agordo de reguloj (konektoj) kaj mapado
Grava punkto en agordo de reproduktado estas, ke la unuaj du etapoj devas esti ripetitaj sur la fora stokadosistemo, la tria etapo - nur sur la ĉefa.
Agordi retajn rimedojn
La unua paŝo estas agordi la retajn havenojn per kiuj reprodukta trafiko estos elsendita. Por fari tion, vi devas ebligi la havenojn kaj agordi iliajn IP-adresojn en la sekcio de Front-end adaptiloj.
Post ĉi tio, ni devas krei naĝejon (en nia kazo RDG) kaj virtualan IP por reproduktado (VIP). VIP estas flosanta IP-adreso, kiu estas ligita al du "fizikaj" adresoj de stokadregiloj (la havenoj, kiujn ni ĵus agordis). Ĉi tio estos la ĉefa reprodukta interfaco. Vi ankaŭ povas funkcii ne kun VIP, sed kun VLAN, se vi bezonas labori kun etikedita trafiko.
La procezo de kreado de VIP por kopio ne multe diferencas de kreado de VIP por I/O (NFS, SMB, iSCSI). En ĉi tiu kazo, ni kreas regulan VIP (sen VLAN), sed nepre indiku, ke ĝi estas por reproduktado (sen ĉi tiu montrilo ni ne povos aldoni VIP al la regulo en la sekva paŝo).
La VIP devas esti en la sama subreto kiel la IP-havenoj inter kiuj ĝi flosas.
Ni ripetas ĉi tiujn agordojn sur fora stokado sistemo, kun malsama IP, kompreneble.
Vipuloj de malsamaj stoksistemoj povas esti en malsamaj subretoj, la ĉefa afero estas, ke estas vojigo inter ili. En nia kazo, ĉi tiu ekzemplo estas ĝuste montrita (192.168.3.XX kaj 192.168.2.XX)
Ĉi tio kompletigas la preparadon de la retoparto.
Agordi stokadon
Agordo de stokado por kopio diferencas de kutime nur pro tio, ke ni faras la mapadon per speciala menuo "Reprodukta Mapo". Alie ĉio estas la sama kiel kun la normala aranĝo. Nun, en ordo.
En la antaŭe kreita naĝejo R02, vi devas krei LUN. Ni kreu ĝin kaj nomu ĝin LUN1.
Ni ankaŭ devas krei la saman LUN sur fora stokado sistemo de identa grandeco. Ni kreas. Por eviti konfuzon, ni voku la fora LUN LUN1R
Se ni bezonus preni LUN kiu jam ekzistas, tiam instalante la kopion, ni bezonus malmunti ĉi tiun produktivan LUN de la gastiganto, kaj simple krei malplenan LUN de identa grandeco sur la fora stokado sistemo.
La stokagordo estas kompleta, ni pluiru al kreado de reprodukta regulo.
Starigante reproduktajn regulojn aŭ reproduktajn ligilojn
Post kreado de LUN-oj en la stokadsistemo, kiu estos la ĉefa nuntempe, ni agordas la reproduktan regulon LUN1 sur stokadosistemo 1 al LUN1R sur stokadosistemo 2.
La agordo estas farita en la menuo "Fora reproduktado".
Ni kreu regulon. Por fari tion, vi devas specifi la ricevonton de la kopio. Tie ni ankaŭ fiksas la nomon de la konekto kaj la tipon de reproduktado (sinkrona aŭ nesinkrona).
En la kampo "foraj sistemoj" ni aldonas nian stoksistemon2. Por aldoni, vi devas uzi la administrajn IP-stokadosistemojn (MGR) kaj la nomon de la fora LUN en kiu ni faros reproduktadon (en nia kazo, LUN1R). Kontrolaj IP-oj estas bezonataj nur en la stadio de aldono de konekto; replika trafiko ne estos transdonita per ili; la antaŭe agordita VIP estos uzata por tio.
Jam en ĉi tiu etapo ni povas aldoni pli ol unu foran sistemon por la topologio "unu al multaj": alklaku la butonon "aldoni nodon", kiel en la suba figuro.
En nia kazo, ekzistas nur unu fora sistemo, do ni limigas nin al ĉi tio.
La regulo estas preta. Bonvolu noti, ke ĝi estas aldonita aŭtomate ĉe ĉiuj reproduktaj partoprenantoj (en nia kazo estas du el ili). Vi povas krei tiom da tiaj reguloj kiom vi volas, por ajna nombro da LUN-oj kaj en ajna direkto. Ekzemple, por ekvilibrigi la ŝarĝon, ni povas reprodukti parton de la LUN-oj de stokadosistemo 1 al stokadosistemo 2, kaj la alian parton, male, de stokadosistemo 2 al stokadosistemo 1.
Stoksistemo 1. Tuj post kreado komenciĝis sinkronigo.
Stokadosistemo 2. Ni vidas la saman regulon, sed sinkronigado jam finiĝis.
LUN1 sur stoka sistemo 1 estas en la Ĉefa rolo, tio estas, ĝi estas aktiva. LUN1R sur stokadosistemo 2 estas en la rolo de Sekundara, tio estas, ĝi estas en standby en kazo stokadosistemo 1 malsukcesas.
Nun ni povas konekti nian LUN al la gastiganto.
Ni konektos per iSCSI, kvankam ĝi ankaŭ povas esti farita per FC. Agordo de mapado per iSCSI LUN en kopio preskaŭ ne diferencas de la kutima scenaro, do ni ne konsideros ĉi tion detale ĉi tie. Se io ajn, ĉi tiu procezo estas priskribita en la artikolo "".
La nura diferenco estas, ke ni kreas mapadon en la menuo "Reprodukta Mapo".
Ni starigis mapadon kaj donis la LUN al la gastiganto. La gastiganto vidis la LUN.
Ni formatas ĝin en lokan dosiersistemon.
Jen ĝi, la aranĝo estas kompleta. Provoj venos poste.
Testado
Ni testos tri ĉefajn scenarojn.
- Regula rolŝanĝo Malĉefa > Ĉefa. Regula ŝanĝado de rolo necesas, se ni ekzemple devas fari iujn preventajn operaciojn en la ĉefa datumcentro kaj dum ĉi tiu tempo, por ke la datumoj estu disponeblaj, ni transdonas la ŝarĝon al la rezerva datumcentro.
- Urĝa rolŝanĝo Malĉefa > Ĉefa (fiasko de datumcentro). Ĉi tiu estas la ĉefa scenaro por kiu reproduktado ekzistas, kiu povas helpi postvivi kompletan fiaskon de datumcentro sen haltigi la kompanion por plilongigita periodo.
- Rompiĝo de komunikadkanaloj inter datencentroj. Kontroli la ĝustan konduton de du stokaj sistemoj en kondiĉoj, kie ial la komunika kanalo inter la datumcentroj estas neatingebla (ekzemple, elkavatoro fosis en malĝusta loko kaj rompis la malhelan optikon).
Unue, ni komencos skribi datumojn al nia LUN (skribi dosierojn kun hazardaj datumoj). Ni tuj vidas, ke la komunika kanalo inter la stokaj sistemoj estas uzata. Ĉi tio estas facile komprenebla se vi malfermas la ŝarĝan monitoradon de la havenoj, kiuj respondecas pri reproduktado.
Ambaŭ stokaj sistemoj nun havas "utilajn" datumojn, ni povas komenci la teston.
Ĉiaokaze, ni rigardu la hash-sumojn de unu el la dosieroj kaj skribu ilin.
Regula rolŝanĝo
La operacio de ŝanĝado de roloj (ŝanĝante la direkton de reproduktado) povas esti farita per iu ajn stoksistemo, sed vi ankoraŭ devos iri al ambaŭ, ĉar vi devos malŝalti mapadon sur Primara, kaj ebligi ĝin sur Sekundara (kiu fariĝos Ĉefa). ).
Eble nun ekestas racia demando: kial ne aŭtomatigi ĉi tion? La respondo estas: ĝi estas simpla, reproduktado estas simpla rimedo de katastrofa rezisteco, bazita nur sur manaj operacioj. Por aŭtomatigi ĉi tiujn operaciojn, ekzistas metrocluster-reĝimo; ĝi estas plene aŭtomatigita, sed ĝia agordo estas multe pli komplika. Ni skribos pri starigo de metrogrupo en la sekva artikolo.
Sur la ĉefa stokadsistemo, ni malŝaltas mapadon por certigi, ke registrado ĉesas.
Tiam sur unu el la stokaj sistemoj (ne gravas, sur la ĉefa aŭ rezerva) en la menuo "Fora reproduktado", elektu nian konekton REPL1 kaj alklaku "Ŝanĝi rolon".
Post kelkaj sekundoj, LUN1R (rezerva stokadosistemo) fariĝas Ĉefa.
Ni mapas LUN1R kun konserva sistemo2.
Post tio, nia E: stirado estas aŭtomate alkroĉita al la gastiganto, nur ĉi-foje ĝi "alvenis" de LUN1R.
Ĉiaokaze, ni komparas la hash-sumojn.
Idente. Testo pasis.
Malsukceso. Fiasko de datumcentro
Nuntempe, la ĉefa stokada sistemo post regula ŝanĝado estas konserva sistemo 2 kaj LUN1R, respektive. Por imiti akcidenton, ni malŝaltos la potencon de ambaŭ stokadregiloj2.
Ne plu estas aliro al ĝi.
Ni vidu, kio okazas en la konserva sistemo 1 (la rezerva nuntempe).
Ni vidas, ke la Primara LUN (LUN1R) estas neatingebla. Erarmesaĝo aperis en la protokoloj, en la informpanelo, kaj ankaŭ en la reprodukta regulo mem. Sekve, datumoj de la gastiganto estas nuntempe neatingeblaj.
Ŝanĝu la rolon de LUN1 al Ĉefa.
Mi faras mapadon al la gastiganto.
Certiĝu, ke stirado E aperas sur la gastiganto.
Ni kontrolas la haŝiŝon.
Ĉio estas en ordo. La stokadsistemo sukcese postvivis la falon de la datumcentro, kiu estis aktiva. La proksimuma tempo, kiun ni pasigis por konekti la reproduktan "inversigon" kaj konekti la LUN de la rezerva datumcentro estis proksimume 3 minutoj. Estas klare, ke en reala produktado ĉio estas multe pli komplika, kaj krom agoj kun stokaj sistemoj, vi devas plenumi multajn pliajn operaciojn en la reto, en gastigantoj, en aplikoj. Kaj en la vivo ĉi tiu tempodaŭro estos multe pli longa.
Ĉi tie mi ŝatus skribi, ke ĉio, la provo estis sukcese finita, sed ni ne rapidu. La ĉefa konserva sistemo estas "kuŝanta", ni scias, ke kiam ĝi "falis", ĝi estis en la Ĉefa rolo. Kio okazas se ĝi subite ekŝaltas? Estos du Ĉefaj roloj, kio egalas datuman korupton? Ni kontrolu ĝin nun.
Ni subite ŝaltu la suban stoksistemon.
Ĝi ŝarĝas dum kelkaj minutoj kaj poste revenas al servo post mallonga sinkronigo, sed en la rolo de Sekundara.
Ĉio en ordo. Split-cerbo ne okazis. Ni pensis pri tio, kaj ĉiam post falo la stokadsistemo altiĝas al la rolo de Sekundara, sendepende de kia rolo ĝi estis en "dum vivo". Nun ni povas diri certe, ke la provo de fiasko de datumcentro sukcesis.
Fiasko de komunikadkanaloj inter datumcentroj
La ĉefa tasko de ĉi tiu testo estas certigi, ke la stokado-sistemo ne ekagas strange, se ĝi provizore perdas komunikajn kanalojn inter du stokaj sistemoj kaj poste aperas denove.
Do. Ni malkonektas la dratojn inter la stokaj sistemoj (ni imagu, ke ili estis fositaj de fosmaŝino).
Sur Primara ni vidas, ke ne ekzistas rilato kun Sekundara.
Sur Sekundara ni vidas, ke ne ekzistas rilato kun Primara.
Ĉio funkcias bone, kaj ni daŭre skribas datumojn al la ĉefa stokadosistemo, tio estas, ili estas garantiitaj esti malsamaj de la rezerva, tio estas, ili "apartigis".
Post kelkaj minutoj ni "riparas" la komunikadkanalon. Tuj kiam la stoksistemoj vidas unu la alian, datumsinkronigado estas aŭtomate aktivigita. Nenio necesas de la administranto ĉi tie.
Post iom da tempo, sinkronigo estas finita.
La konekto estis restarigita, la perdo de komunikadkanaloj ne kaŭzis krizajn situaciojn, kaj post ŝaltado, sinkronigo okazis aŭtomate.
trovoj
Ni analizis la teorion - kio estas bezonata kaj kial, kie estas la avantaĝoj kaj kie estas la malavantaĝoj. Tiam ni starigas sinkronan reproduktadon inter du stokaj sistemoj.
Poste, bazaj testoj estis faritaj por normala ŝaltado, fiasko de datumcentro kaj fiasko de komunika kanalo. En ĉiuj kazoj, la konserva sistemo funkciis bone. Ne estas perdo de datumoj kaj administraj operacioj estas minimumaj por mana scenaro.
La venontan fojon ni komplikos la situacion kaj montros kiel ĉio ĉi tiu logiko funkcias en aŭtomatigita metrocluster en aktiva-aktiva reĝimo, tio estas, kiam ambaŭ stokaj sistemoj estas primaraj, kaj la konduto en kazo de stokado-sistemo estas plene aŭtomatigita.
Bonvolu skribi komentojn, ni ĝojos ricevi solidajn kritikojn kaj praktikajn konsilojn.
Ĝis la venonta tempo.
fonto: www.habr.com