Størrelsen på Hadoop Cluster-dummies

Forstørre et databehandlingssystem er like mye en vitenskap som den er en kunst. Med Hadoop vurderer du samme informasjon som du ville med en relasjonsdatabase. For det meste må du vite hvor mye data du har, anslå forventede vekstraten og opprett en retensjonspolicy (hvor lenge for å holde dataene).

Svarene på disse spørsmålene er utgangspunktet, som er uavhengig av eventuelle teknologirelaterte krav.

Etter at du har bestemt deg for hvor mye data du må lagre, kan du starte factoring i Hadoop-spesifikke hensyn. Anta at du har et teleselskap, og du har oppdaget at du trenger 750 terabyte (TB) lagringsplass for loggfilene for samtaleoppføringer (CDR). < Du beholder disse postene for å overholde regjeringens forskrifter, men du kan også analysere dem o se churn mønstre og overvåke nettverk helse, for eksempel. For å avgjøre hvor mye lagringsplass du trenger, og som resultat, hvor mange rack og slave noder du trenger, utfører du beregningene dine med disse faktorene i tankene:

Replikering:

• Standard replikasjonsfaktoren for data i HDFS er 3. De 500 terabyte CDR-data for teleselskapet i eksempelet blir så til 1500 terabyte. Bytteplass:

• Enhver analyse eller behandling av dataene fra MapReduce krever ytterligere 25 prosent plass for å lagre eventuelle foreløpige og endelige resultatsett. (Teleselskapet trenger nå 1875 terabyte lagringsplass.)

  Komprimering:

• Teleselskapet lagrer CDRene i komprimert form, der gjennomsnittskompresjonsforholdet forventes å være 3: 1. Du trenger nå 625 terabyte. Antall slave noder:

• Forutsatt at hver slave node har tolv 3TB-stasjoner dedikert til HDFS, har hver slave node 36 terabyte rå HDFS-lagring tilgjengelig, slik at selskapet trenger 18 slave noder. Antall rack:

• Fordi hver slave node bruker 2RU, og selskapet i eksemplet trenger tre master noder (1RU stykke) og to ToR-brytere (1RU stykke), trenger du totalt 41RU. Det er 1RU mindre enn den totale kapasiteten til en standard rack, så en enkelt rack er tilstrekkelig for denne distribusjonen. Uansett, det er ikke rom igjen for vekst i denne klyngen, så det er forsiktig å kjøpe en ekstra rack (og to ekstra ToR-brytere) og dele slavenoderne mellom de to rackene.

  Testing:

• Vedlikehold av en testklynge som er en mindre skala representasjon av produksjonsklyngen er en standard praksis. Det trenger ikke å være stort, men du vil ha minst fem datodenoder, slik at du får en nøyaktig representasjon av Hadops oppførsel.Som med ethvert testmiljø, bør det isoleres på et annet nettverk fra produksjonsklyngen. Sikkerhetskopiering og katastrofeoppretting:

• Som alle produksjonssystemer, vil teleselskapet også måtte vurdere sikkerhetskopierings- og katastrofegjenopprettingskrav. Dette selskapet kunne gå så langt som å lage en speilklynge for å sikre at de har en varm standby for hele systemet. Dette er åpenbart det dyreste alternativet, men passer for miljøer der konstant oppetid er kritisk. I det minst kostbare slutten av spekteret (uten å sikkerhetskopiere dataene i det hele tatt), kunne teleselskapet regelmessig sikkerhetskopiere alle data (inkludert dataene selv, applikasjoner, konfigurasjonsfiler og metadata) lagres i deres produksjonsklynge å tape. Med tape er dataene ikke umiddelbart tilgjengelige, men det vil muliggjøre en katastrofegjenoppretting i tilfelle at hele Hadoop-konseptet i produksjonen mislykkes.

  Som med din egen personlige datamaskin, når hoved harddisken fylles med plass, senker systemet betydelig. Hadoop er ikke noe unntak. Også, en harddisk utfører bedre når den er mindre enn 85 til 90 prosent full. Med denne informasjonen i tankene, hvis ytelse er viktig for deg, bør du boble opp swap-spacefaktoren fra 25 til 33 prosent.