Søknadskontroll - Application checkpointing
Checkpointing er en teknikk som gir feiltoleranse for databehandlingssystemer. Den består i utgangspunktet av å lagre et øyeblikksbilde av applikasjonens tilstand, slik at applikasjoner kan starte på nytt fra det punktet i tilfelle feil . Dette er spesielt viktig for de langvarige applikasjonene som kjøres i de feilutsatte datasystemene.
Kontrollpunkt i distribuerte systemer
I det distribuerte databehandlingsmiljøet er kontrollpeking en teknikk som hjelper til med å tolerere feil som ellers ville tvinge et langvarig program til å starte på nytt fra begynnelsen. Den mest grunnleggende måten å implementere sjekkpunkt på er å stoppe programmet, kopiere alle nødvendige data fra minnet til pålitelig lagring (f.eks. Parallelt filsystem ) og deretter fortsette med utførelsen. I tilfelle feil, når programmet starter på nytt, trenger det ikke å starte fra bunnen av. Den vil heller lese den siste tilstanden ("kontrollpunktet") fra den stabile lagringen og utføre den. Selv om det pågår debatt om hvorvidt sjekkpunkt er den dominerende I/O -arbeidsmengden på distribuerte datasystemer, er det generell enighet om at sjekkpunkt er en av de store I/O -arbeidsmengdene.
Det er to hovedtilnærminger for sjekkpunkt i de distribuerte datasystemene: koordinert sjekkpunkt og ukoordinert sjekkpunkt. I den koordinerte kontrollpunkttilnærmingen må prosesser sikre at kontrollpunktene er konsistente. Dette oppnås vanligvis med en slags tofaset commit-protokollalgoritme . I den ukoordinerte sjekkpunktet peker hver prosesskontrollpunkt på sin egen tilstand uavhengig. Det må understrekes at det bare ikke er tilstrekkelig for å sikre global konsistens å tvinge prosesser til å kontrollere deres tilstand ved faste tidsintervaller. Behovet for å etablere en konsistent tilstand (dvs. ingen manglende meldinger eller dupliserte meldinger) kan tvinge andre prosesser til å rulle tilbake til kontrollpunktene sine, noe som igjen kan føre til at andre prosesser ruller tilbake til enda tidligere sjekkpunkter, noe som i det mest ekstreme tilfellet kan betyr at den eneste konsistente tilstanden som er funnet, er starttilstanden (den såkalte dominoeffekten ).
Implementeringer for applikasjoner
Lagre staten
En av de opprinnelige og nå vanligste måtene for applikasjonskontroll var en "lagre tilstand" -funksjon i interaktive applikasjoner, der brukeren av applikasjonen kunne lagre tilstanden til alle variabler og andre data til et lagringsmedium på det tidspunktet de brukte det og enten fortsette å jobbe, eller avslutte programmet og på et senere tidspunkt starte programmet på nytt og gjenopprette den lagrede tilstanden. Dette ble implementert gjennom en "lagre" kommando eller menyalternativ i programmet. I mange tilfeller ble det vanlig praksis å spørre brukeren om de hadde ikke -lagret arbeid når de forlot programmet om de ville lagre arbeidet sitt før de gjorde det.
Denne typen funksjonalitet ble ekstremt viktig for brukervennlighet i applikasjoner der det aktuelle arbeidet ikke kunne fullføres på en gang (for eksempel å spille et videospill som forventes å ta dusinvis av timer, eller skrive en bok eller et langt dokument på hundrevis eller tusenvis av sider ) eller der arbeidet ble utført over en lengre periode, for eksempel datainføring i et dokument, for eksempel rader i et regneark.
Problemet med lagringstilstand er at det krever at operatøren av et program ber om lagringen. For ikke-interaktive programmer, inkludert automatiserte eller batchbehandlede arbeidsmengder, måtte muligheten til å kontrollere slike applikasjoner også bli automatisert.
Sjekkpunkt/start på nytt
Etter hvert som batchprogrammer begynte å håndtere titusener til hundretusenvis av transaksjoner, hvor hver transaksjon kan behandle én post fra en fil mot flere forskjellige filer, er det nødvendig at applikasjonen kan startes på nytt på et tidspunkt uten å måtte kjøre hele jobben fra bunnen av ble tvingende nødvendig. Dermed ble "sjekkpunkt/omstart" -funksjonen født, hvor et "øyeblikksbilde" eller "sjekkpunkt" av applikasjonens tilstand etter en rekke transaksjoner hadde blitt behandlet. Hvis programmet mislyktes før neste kontrollpunkt, kan det startes på nytt ved å gi det sjekkpunktinformasjonen og det siste stedet i transaksjonsfilen der en transaksjon var fullført. Programmet kan deretter starte på nytt på det tidspunktet.
Kontrollposisjon pleier å være dyrt, så det ble vanligvis ikke gjort med hver post, men med et rimelig kompromiss mellom kostnaden for et sjekkpunkt og verdien av datatiden som trengs for å behandle en omgang poster. Dermed kan antallet poster som behandles for hvert sjekkpunkt variere fra 25 til 200, avhengig av kostnadsfaktorer, applikasjonens relative kompleksitet og ressursene som trengs for å starte programmet på nytt.
Fault Tolerance Interface (FTI)
FTI er et bibliotek som har som mål å gi beregningsforskere en enkel måte å utføre sjekkpunkt/omstart på en skalerbar måte. FTI utnytter lokal lagring pluss flere replikasjoner og slettingsteknikker for å gi flere nivåer av pålitelighet og ytelse. FTI tilbyr kontrollpunkt på applikasjonsnivå som lar brukerne velge hvilke data som må beskyttes, for å forbedre effektiviteten og unngå plass, tid og energisvinn. Det tilbyr et direkte datagrensesnitt, slik at brukerne ikke trenger å håndtere filer og/eller katalognavn. Alle metadata administreres av FTI på en gjennomsiktig måte for brukeren. Om ønskelig kan brukerne dedikere en prosess per node til å overlappe arbeidsmengde for feiltoleranse og vitenskapelig beregning, slik at post-checkpoint-oppgaver utføres asynkront.
Berkeley Lab Checkpoint/Restart (BLCR)
Future Technologies Group ved Lawrence National Laboratories utvikler en hybrid kjerne/brukerimplementering av sjekkpunkt/omstart kalt BLCR. Målet deres er å tilby en robust implementering av produksjonskvalitet som kontrollerer et bredt spekter av applikasjoner, uten at det må endres i applikasjonskoden. BLCR fokuserer på sjekkpunkt parallelle applikasjoner som kommuniserer gjennom MPI, og på kompatibilitet med programvarepakken produsert av SciDAC Scalable Systems Software ISIC. Arbeidet er delt inn i 4 hovedområder: Checkpoint/Restart for Linux (CR), Checkpointable MPI Libraries, Resource Management Interface to Checkpoint/Restart og Development of Process Management Interfaces.
DMTCP
DMTCP (Distributed MultiThreaded Checkpointing) er et verktøy for å gjennomsiktig kontrollere status for en vilkårlig gruppe programmer spredt over mange maskiner og forbundet med stikkontakter. Det endrer ikke brukerens program eller operativsystemet. Blant programmene som støttes av DMTCP er Open MPI , Python , Perl , og mange programmeringsspråk og shell -skriptspråk. Med bruk av TightVNC kan den også sjekke og starte X Window -programmer på nytt, så lenge de ikke bruker utvidelser (f.eks. Ingen OpenGL eller video). Blant Linux -funksjonene som støttes av DMTCP er åpne filbeskrivelser , rør, stikkontakter, signalbehandlere, prosess -ID og tråd -id -virtualisering (sørg for at gamle pids og tidsbruk fortsetter å fungere ved omstart), ptys, fifos, prosessgruppe -IDer, sesjons -IDer, terminal attributter og mmap /mprotect (inkludert mmap-basert delt minne). DMTCP støtter OFED API for InfiniBand på eksperimentell basis.
Samarbeidskontroll
Noen nylige protokoller utfører samarbeidskontroll ved å lagre fragmenter av sjekkpunktet i noder i nærheten. Dette er nyttig fordi det unngår kostnadene ved lagring i et parallelt filsystem (som ofte blir en flaskehals for store systemer) og det bruker lagring som er nærmere. Dette har funnet bruk spesielt i storskala superdatamaskiner. Utfordringen er å sikre at når sjekkpunktet er nødvendig når du gjenoppretter fra en feil, er de nærliggende nodene med fragmenter av sjekkpunktene tilgjengelige.
Docker
Docker og den underliggende teknologien inneholder et kontrollpunkt og en gjenopprettingsmekanisme.
CRIU
CRIU er et sjekkpunktbibliotek for brukerrom.
Implementering for innebygde og ASIC -enheter
Minner
Mementos er et programvaresystem som forvandler generelle oppgaver til avbrytbare programmer for plattformer med hyppige avbrudd, for eksempel strømbrudd. Den er designet for batteriløse innebygde enheter som RFID -tagger og smartkort som er avhengige av å hente energi fra omgivende bakgrunnskilder. Mementos registrerer ofte den tilgjengelige energien i systemet og bestemmer om programmet skal sjekkes på grunn av forestående strømtap kontra kontinuerlig beregning. Hvis du sjekker, blir data lagret i et ikke-flyktig minne . Når energien blir tilstrekkelig for omstart , hentes dataene fra ikke-flyktig minne og programmet fortsetter fra den lagrede tilstanden. Mementos er implementert på MSP430 -familien av mikrokontrollere . Minner er oppkalt etter Christopher Nolan 's Memento .
Idetisk
Idetic er et sett med automatiske verktøy som hjelper applikasjonsspesifikke integrerte kretsutviklere (ASIC) med å automatisk legge inn sjekkpunkter i sine design. Den er rettet mot synteseverktøy på høyt nivå og legger til sjekkpunktene på registeroverføringsnivå ( Verilog- kode). Den bruker en dynamisk programmering tilnærming for å finne lave overhead punkter i statsapparatet av design. Siden kontrollpunktet på maskinvarenivå innebærer å sende dataene til avhengige registre til et ikke-flyktig minne, kreves de optimale punktene for å ha et minimum antall registre å lagre. Idetic distribueres og evalueres på energihøsting RFID -tag -enhet.
Se også
Referanser
Videre lesning
- Yibei Ling, Jie Mi, Xiaola Lin: En variasjonsberegningstilnærming til optimal kontrollplassering. IEEE Trans. Datamaskiner 50 (7): 699-708 (2001)
- RE Ahmed, RC Frazier og PN Marinos, "Cache-Aided Rollback Error Recovery (CARER) Algorithms for Shared-Memory Multiprocessor Systems", IEEE 20th International Symposium on Fault-Tolerant Computing (FTCS-20), Newcastle upon Tyne, UK, 26.– 28. juni 1990, s. 82–88.