SMB-er må slutte å se til BackBlaze for veiledning

Jeg må innlede denne artikkelen – fordi folk ofte tar slike ting ut av kontekst og reagerer sterkt på ting som aldri ble sagt – med en ansvarsfraskrivelse om at jeg mener BackBlaze gjør en utmerket jobb, har glimrende folk som jobber for dem og har gjort en fantastisk jobb med å designe og utnytte teknologi som er absolutt anvendelig og passende for deres behov. Ingenting, og jeg mener virkelig ingenting, i denne artikkelen skal noensinne tas ut av kontekst og fremstilles som noe negativt om BackBlaze. Hvis noe i denne artikkelen ser ut til eller føles som om det sier noe annet, vennligst les på nytt og bekreft at det faktisk ble sagt, og hvis så er tilfelle, gi meg beskjed slik at jeg kan korrigere det. Det er ingen intensjon i denne artikkelen om å antyde, på noen som helst måte, at BackBlaze ikke gjør det som er smart for dem, deres virksomhet og deres kunder. Nå til artikkelen:

Jeg har funnet ut gjennom mange år at mange IT-fagpersoner i små og mellomstore bedrifter er blitt betatt av det de ser som et mirakel av lavkost, høy kapasitetslagring i det som er kjent som BackBlaze POD-designet. I bunn og grunn er BackBlaze POD en lavkost, høy kapasitet, lav ytelse, nesten hvitboks lagringsserver bygget fra et egendefinert chassis og forbrukerdeler for å lage en engangslagernode brukt i store lagrings-RAIN-matriser som utnytter slettekoding. BackBlaze egenutviklet den originale POD-en og slapp designet til offentligheten, utelukkende for bruk i sine storskala, vertsbaserte sikkerhetskopidatasentre der POD-ene fungerer som individuelle noder i en massiv array av noder med replikering mellom dem. Gjennom årene har BackBlaze oppdatert POD-designet sitt etter hvert som teknologien har endret seg og problemer er blitt adressert. Men det grunnleggende bruksområdet har forblitt det samme.

Jeg må sammenligne dette med SAM-SD-tilnærmingen til lagring, som følger en lignende taktikk, men gjør det ved å bruke enterprise-grade, støttet maskinvare. Disse forskjellene fremstår noen ganger som trivielle, men de er alt annet enn trivielle – de er nøkkelgrunnlag for hva som gjør de ulike løsningene passende i ulike situasjoner. Ideen bak SAM-SD er at lagring må være pålitelig og designet fra maskinvaren opp til å være så pålitelig som mulig og godt støttet for når ting feiler. POD-en tar den motsatte tilnærmingen og gjør den individuelle serveren upålitelig og flyktig av natur, designet for å kastes snarere enn å repareres. SAM-SD-designet forutsetter at den individuelle serveren er viktig, til og med kritisk – alt annet enn engangsvare.

SAM-SD-konseptet, som bokstavelig talt er ingenting mer enn en tilnærming til å bygge åpen lagring, er designet med SMB-lagringsmarkedet i tankene. BackBlaze POD er designet med et ekstremt nisjepregede, storskala, spesialisert forbrukerbackupmarked i tankene. SAM-SD er ment å drives av små bedrifter, selv de uten intern IT. POD-en er designet for å rulles ut og administreres av et heltids, dedikert lagringsteknikerteam.

Fordi BackBlaze POD er designet av eksperter, for eksperter i de aller største lagringssituasjonene, kan den være forvirrende og lett misforstås av ikke-lagringseksperter i småbedriftsmarkedet. Faktisk er den så ofte misforstått at innvendinger mot den ofte møtes med kommentarer som «Jeg tror BackBlaze vet hva de gjør», noe som demonstrerer den ekstreme misforståelsen som eksisterer rundt tilnærmingen. Selvfølgelig vet BackBlaze hva de gjør, men de gjør ikke det som noen SMB gjør.

Offentliggjøringen av POD-designet skaper mye forvirring fordi det bare er én del av en større helhet. Designet av det fullstendige datasenteret og midlene for redundans og mekanismene for dette mellom POD-ene er ikke offentlig, men proprietært. Så selve POD-en representerer bare en enkelt node i en klynge (eller Vault) og gjenspeiler ikke klyngedannelsen i seg selv, som er der det viktigste arbeidet finner sted. Faktisk er selve POD-designet ingenting mer enn arbeidet gjort av Sun Thumper og SAM-SD-prosjektene fra det siste tiåret, uten begrensningene av pålitelighet. POD-en burde ikke være et nytt design, men et åpenbart ett – et design som i tiår har blitt unngått i SMB-lagringsmarkedet fordi det er så dramatisk ikke-anvendelig der.

Fordi klynge- og replikeringsaspektene ignoreres når man snakker om BackBlaze POD, gjøres det noen store antagelser om kapasiteten til en POD som har mye lavere overhead enn BackBlaze selv får for POD-infrastrukturen, selv i stor skala. For eksempel, i RAID-termer, ville dette ligne på å anta at POD-en er RAID 6 (med bare 5 % overhead) fordi det er RAID-nivået til en individuell komponent, mens faktisk RAID 61 (55 % overhead) brukes! Faktisk vurderer mange SMB IT-fagpersoner når de ser på å bruke et POD-design, ganske enkelt å bruke RAID 6 i tillegg til å kun bruke en enkelt POD. Graden av avvik fra BackBlazes modell er svimlende.

BackBlaze: «Backblaze Vaults kombinerer tjue fysiske Storage Pods til ett virtuelt chassis. Vault-programvaren implementerer vår egen Reed-Solomon-koding for å spre dataskår på tvers av alle tjue pods i Vault-en samtidig, noe som dramatisk forbedrer holdbarheten.»

For å gjøre POD-en til et alternativ for SMB-markedet kreves det at hele konseptet med POD-en tas fullstendig ut av kontekst. Både det tiltenkte bruksområdet og implementeringen. Det som gjør BackBlaze spesiell fjernes fullstendig, og bare de mest trivielle, overfladiske aspektene tas og gjøres om til noe som på ingen måte ligner BackBlazes visjon eller formål.

Når vi ser nærmere på hvor BackBlaze POD avviker i design fra standardbehovene til en normal virksomhet, finner vi disse problemene:

• POD-en er designet for å være upålitelig, for å basere seg på et pålitelighets- og replikeringslag på super-POD-nivå som krever at et stort antall POD-er rulles ut og at data er redundant mellom dem ved hjelp av egendefinert replikering eller klyngedannelse. Uten dette laget er POD-en fullstendig ute av kontekst. Super-POD-nivået er internt kjent som BackBlaze Vault.
• POD-en er designet for å rulles ut i et enterprise-datasenter med nøye vibrasjonsdempning, strømkondisjonering og miljøsystemer. Den er mindre motstandsdyktig mot disse problemene enn standard enterprise-maskinvare.
• POD-en er designet for typisk å erstattes som en komplett enhet snarere enn å reparere en node på stedet. Dette er det motsatte av standard enterprise-maskinvare med hot-swap-komponenter designet for å repareres uten avbrudd, langt fra full erstatning. Vi kaller dette et engangsvare- eller flyktighetsbasert brukstilfelle.
• POD-en er designet for å være utrolig lavkost for svært langsomme, kald lagrings-behov. Selv om dette kan eksistere i en SMB, er det typisk ikke tilfellet.
• POD-en er designet for å være en enkelt, høykapasitetslagringsnode i en pool av vanvittig stor kapasitet. Få SMB-er kan utnytte selv lagringspotensialet til en enkelt POD, enn si en pool stor nok til å rettferdiggjøre POD-designet.
• BackBlaze POD er designet for å bruke egendefinert slettekoding, ikke RAID. RAID er ikke effektivt i denne skalaen, selv på enkelt POD-nivå.
• En individuell POD er designet for 180 TB kapasitet og en Vault-skala på 3,6 PB.

Gjeldende referanse for BackBlaze POD 5: https://www.backblaze.com/blog/cloud-storage-hardware/

Kort sagt er BackBlaze POD et glimrende grunnlag for en glimrende tjeneste som møter et svært spesifikt behov som er så langt fjernet fra behovene i SMB-lagringsmarkedet som man rimeligvis kan komme. Respekter BackBlaze for deres gode arbeid, men forsøk ikke å etterligne det.