Innehåll
- Google File System: En stor fallstudie
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- En titt på kärntekniken
- Hur uppnår andra stora system detta?
- Underhålla en DFS
Hämtmat:
Utvecklare och ingenjörer måste kontinuerligt arbeta för att påskynda och förbättra tjänster över plattformar som har vuxit långt bortom sina klassiska arketyper från 1990-talet.
Med allt surret om enorma NSA-datacenter som håller gazillioner av databitar om våra privata liv, finns det en sak som inte har talats mycket om, åtminstone på CNN. Det handlar om ett tekniskt problem som har uppstått tillsammans med molnteknologi, big data och de imponerande fysiska datalagringscentra som nu byggs över hela världen. Så vad är det? Oavsett vem som administrerar ett av de enorma IT-systemen som driver dessa anläggningar, finns det ett behov av mjukvarusystem som hjälper all den informationen att komma in och ut ur pipeline. Detta behov representerar en av de mest intressanta IT-frågor eller pussel som professionella möter idag.
Som många experter påpekar går dagens extrema efterfrågan på databehandling långt bortom de traditionella metoderna. Enkelt uttryckt, att använda enkla databasstrukturer och verktyg som SQL-frågegränssnitt kommer inte att ge tillräckligt med processorkraft eller funktionalitet för sådana som de egna system som har utvecklats under de senaste åren. Arkiveringarna för dagens stora teknikföretag behöver extremt skalbar teknik. De behöver databehandlingsverktyg som kan mata in och ge resultat i mycket högre volym än vad en enda server kan underlätta. De behöver lösningar som snabbt kan höjas för tillväxt, lösningar som inkluderar komplexa nivåer av konstgjord intelligens, lösningar som är utformade för enkel hantering av en IT-avdelning.
Frågan är, hur erövrar företag och myndigheter begränsningarna i den traditionella datahanteringsvägen? Här kan du ta en titt på ett mycket lovande alternativ: Programvara som hanterar big data och administration av flera datacenter.
Google File System: En stor fallstudie
Den egenutvecklade tekniken som Google använder för att komma åt sina datacenter är ett av de bästa exemplen på vanliga modeller för stordatahantering och administrering av flera datacenter. Google File System (GFS), som utvecklades 2003, är utformat för att stödja den enorma volymen av höghastighetsändringar av datasystem som är en del av att få så mycket ny information in och ut från en enda plattform när miljontals användare klickar bort på samtidigt. Experter hänvisar till detta som ett distribuerat filsystem och använder termen "dataobjektlagring" för att beskriva dessa mycket komplexa tekniker. Men i verkligheten skrapar dessa termer inte ens ytan i termer som beskriver vad som finns på jobbet.
Individuellt är de funktioner och komponenter som utgör ett system som GFS kanske inte banbrytande längre, men de är komplexa. Många av dem har täckts på denna webbplats som relativt nya innovationer som är en del av grunden för ett nytt, alltid på, alltid anslutet globalt IT-system. Sammantaget är ett system som GFS mycket mer än summan av dess delar: det är ett i stort sett osynligt men oerhört komplicerat nätverk som vimlar av enskilda databitar som kastas på detta sätt och som i en process som, om den är helt visuellt modellerad, ser ut som kaos. Att förstå vart alla uppgifter går tar mycket energi och engagemang, eftersom de som bemannar stridstationerna i dessa system medger medger.
"Det finns för många detaljer som har en djup inverkan på användbarhetsområden - inklusive yttre och interna fragmentering, logbaserade kontra uppdateringar på plats och nivåer av transaktionskonsistens - för att sammanfatta hur det fungerar i en enda kortfattad mening , säger Momchil Michailov, VD och medgrundare av Sanbolic.
"Ett distribuerat filsystem är antingen en distribuerad aggregator av lokala namnutrymmen och fria utrymmen för deltagande noder, eller ett lokalt filsystem som körs på flera noder som får åtkomst till delad lagring med hjälp av en distribuerad låshanterarkomponent," sade han.
Kerry Lebel är senior produktchef på Automic, ett företag känt för sina skalbara automationsplattformar. Lebel säger att även om det är korrekt att beskriva en DFS som ett system som helt enkelt tilldelar arbetsbelastningar till servrar som är anslutna till lågkostnadsdelar hårdvara, så berättar det inte riktigt hela historien.
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
"Det du slutar sakna är den coola faktorn på vilket sätt de gör vad de gör, "sa Lebel.
När du går bort från de tekniska detaljerna och bara tänker på den grundläggande idén bakom det distribuerade filsystemet, är den "coola faktorn" som Lebel pratar om. Dessa stora datahanteringssystem ersätter gamla fil / mappsystem med strukturer som inte bara involverar flera leveranssystem, utan ett "objektorienterat" tillvägagångssätt, där ett stort antal enheter slingras hit och där för att förhindra flaskhalsar.
Tänk till exempel på ett modernt motorvägssystem, där hundratusentals bilar inte bara är trattade ner i en multilane direkt, utan hälls upp i snygga små klöverblad eller oxbåssydelar, som snurras runt och skickas mot sina destinationer på olika omvägar. Från himlen ser allt lika koreograferat ut som en schweizisk klocka. Det är den typen av visuell modell som ingenjörer tittar på när de drömmer om nya sätt att dirigera information kring begränsningar genom att "sparka" den till olika nivåer i ett flerskiktat datahållningsschema. Om man lämnar specifikationerna är detta toppmålet för ett hanteringssystem: att hålla de fristående föremål med sina inbäddade metadata rörande i topphastighet dit de behöver vara, att nå konsistensmål, tillfredsställa en slutanvändare eller till och med för att informera en observation eller analys på toppnivå.
En titt på kärntekniken
En artikel av Sean Gallagher som visades på Ars Technica delar upp GFS-designen i något mer hanterbara delar och antyder vad som finns under arket på Google.
GFS börjar med en redundant och feltolerant modell för dataläsningar och skrivningar. Tanken här är att istället för att skriva en specifik uppdatering till en enda enhet, skriver nya system bitar med data till flera destinationer. På så sätt, om en skrivning misslyckas, kommer andra att förbli. För att tillmötesgå detta går en primär nätverkskomponent bort datahantering till andra underordnade enheter, och aggregerar data igen när en klient "kräver" den. Allt detta möjliggörs av ett metadataprotokoll som hjälper till att identifiera var vissa uppdateringar och överföringsresultat ligger i det större systemet.
En annan mycket viktig aspekt av detta är hur dessa duplicerade tunga system upprätthåller datakonsistensen. Som Gallagher noterar, offrar GFS-designen en viss konsistens medan de fortfarande "upprätthåller atomicitet" eller skyddar principen för hur data uppdateras över flera lagringsenheter för att matcha över tid. Googles "avslappnade konsistensmodell" verkar följa den väsentliga teorin för BASE-modellen, som ger mer flexibilitet i gengäld för en längre tidsram för konsistenshantering.
Hur uppnår andra stora system detta?
"När tillräckligt stor skala nås blir inkonsekvenser eller korruption i uppgifterna oundvikliga," säger Michailov. "Därför bör ett primärt mål för distribuerade filsystem vara förmågan att genomföra så många operationer som möjligt i närvaro av korruption, samtidigt som de tillhandahåller effektiva metoder för att hantera korruptionen samtidigt." Michailov nämner också behovet av att bevara prestanda genom noggrant genomförande av redundans.
"Till exempel genom att skapa metadata (data om data) på varje disk gör det möjligt för disken att bygga om sin korrekta datastruktur om dess spegelkopia är skadad," sade Michailov. "Dessutom kan RAID-nivåer användas för att bekämpa lagringsfel antingen i filsystemaggregatorn eller på delade volymhanteringsnivåer."
När han diskuterar en annan konsistensmodell fokuserar Lebel på ett system som kallas ett Hadoop distribuerat filsystem (HDFS), som han kallar en "bransch de-facto standard."
I HDFS, säger Lebel, replikeras varje datablock tre gånger på olika noder och på två olika rack. Data kontrolleras från slutet till slutet. Fel rapporteras till NameNode, en datahanterare som blir av med korrupta block och skapar nya.
Allt detta stöder de typer av "rena data" som är så viktiga för integriteten hos ett av dessa massdatasystem.
Underhålla en DFS
En annan mycket annorlunda titt på GFS kommer från en artikel i oktober 2012 av den trådbundna författaren Steven Levy. Det är mycket kortare att karakterisera mjukvarumetoden för Googles kollektiva topp-down-nätverkshantering.
"Under åren", skriver Levy, "har Google också byggt ett mjukvarusystem som gör det möjligt att hantera sina otaliga servrar som om de var en jätteenhet. Dess interna utvecklare kan fungera som dockmästare och skicka tusentals datorer för att utföra uppgifter lika enkelt som att köra en enda maskin. "
Att göra detta innebär också massor av cyberbaserat och miljöunderhåll, från dedikerade testteam som försöker "bryta" serversystem, till noggrant kontrollerade temperaturer över hallarna i datakrypten.
Levy nämner också kompletterande tekniker för GFS, som MapReduce, ett molnapplikationsverktyg, och Hadoop, en analysmotor som delar vissa designprinciper med GFS. Dessa verktyg har sin egen inverkan på hur stora datacenterhanteringssystem blir utformade och vad som troligen kommer att dyka upp i framtiden. (Läs mer om dessa tekniker i The Evolution of Big Data.)
Michailov anser att MapReduce har potential att stödja allt större datacentersystem och berättar om en "enstaka implementering" av delade och aggregerade filsystem som kan "behålla namnnoderna på ett aggregerat filsystem i ett delat kluster med SSD: er för lagring ".
Lebel ser för sin del en övergång från batchbehandling (den Hadoop-stödda metoden) till strömbearbetning, vilket kommer att föra dessa dataoperationer närmare realtid.
"Ju snabbare vi kan behandla uppgifterna och göra dem tillgängliga för företagens beslutsfattare eller för våra kunder, desto mer av en konkurrensfördel kommer det att finnas," säger Lebel, som också föreslår att ersätta ovanstående behandlingsterminologi med termer som fokuserar på slutanvändare. Genom att tänka på "synkrona" aktiviteter, eller aktiviteter synkroniserade med slutanvändaråtgärder och "asynkrona" aktiviteter som är mer flexibla vad gäller implementering, säger Lebel att företag kan använda SLA: er och andra resurser för att definiera hur ett visst servicesystem kommer att fungera .
Det som allt detta beror på, är att utvecklare och ingenjörer kontinuerligt måste arbeta för att påskynda och förbättra tjänsterna över plattformar som har vuxit långt bortom sina klassiska arketyper från 1990-talet. Det innebär att man kritiskt tittar på maskinens data och bryter igenom flaskhalsar på sätt som inte bara stöder en växande befolkning, utan att den exponentiella förändringen sker med snabba nackdelar som pundits kallar "nästa industriella revolution." Det är troligt att de som bryter mest mark på dessa fronter kommer att dominera på framtidens marknader och ekonomier.