Inhoudsopgave:
Video: Hadoop Rack Awareness 2024
In een Hadoop-cluster voert elk gegevensknooppunt (ook wel een slaafknoop genoemd) een achtergrondproces genaamd DataNode. Dit achtergrondproces (ook bekend als daemon ) houdt de gegevenssegmenten bij die het systeem opslaat op zijn computer. Het spreekt regelmatig met de meesterserver voor HDFS (bekend als de NameNode) om te rapporteren over de status en gezondheid van de lokaal opgeslagen gegevens.
Gegevensblokken worden opgeslagen als onbewerkte bestanden in het lokale bestandssysteem. Vanuit het perspectief van een Hadoop-gebruiker, heb je geen idee welke van de slave-knooppunten de stukken van het bestand heeft die je moet verwerken. Vanuit Hadoop zie je geen gegevensblokken of hoe ze over het cluster worden verspreid - alles wat je ziet is een lijst met bestanden in HDFS.
De complexiteit van hoe de bestandsblokken over het cluster worden verspreid, is voor u verborgen - u weet niet hoe ingewikkeld het allemaal is, en u hoeft niet nodig te hebben weten. Eigenlijk weten de slaafknopen zelf niet eens wat zich in de gegevensblokken bevindt die ze opslaan. Het is de NameNode-server die de toewijzingen kent van welke datablokken de bestanden vormen die zijn opgeslagen in HDFS.
Beter leven door redundantie
Een kernontwerpprincipe van HDFS is het concept van het minimaliseren van de kosten van de afzonderlijke slaafknopen door gebruik te maken van standaardhardwarecomponenten. Voor massaal schaalbare systemen is dit idee een verstandige reden omdat kosten snel escaleren wanneer u honderden of duizenden slaafknooppunten nodig heeft. Het gebruik van goedkopere hardware heeft echter tot gevolg dat individuele componenten niet zo betrouwbaar zijn als duurdere hardware.
Wanneer u opslagopties kiest, overweeg dan de impact van het gebruik van commodity-schijven in plaats van duurdere drives van bedrijfskwaliteit. Stel u voor dat u een cluster met 750 knooppunten hebt, waarbij elk knooppunt 12 vaste schijven heeft die zijn bestemd voor HDFS-opslag.
Gebaseerd op een jaarlijkse uitvalpercentage (AFR) van 4 procent voor standaardschijfstations (een gegeven harde schijf heeft een kans van 4 procent om in een bepaald jaar te mislukken, met andere woorden), zal uw cluster waarschijnlijk een harde schijf ervaren falen elke dag van het jaar.
Omdat er zoveel slaafknooppunten kunnen zijn, is hun falen ook een veel voorkomend verschijnsel in grotere clusters met honderden of meer knooppunten. Met deze informatie in het achterhoofd is HDFS ontworpen in de veronderstelling dat alle hardwarecomponenten, zelfs op het niveau van de slave node, onbetrouwbaar zijn.
HDFS overwint de onbetrouwbaarheid van individuele hardwarecomponenten door middel van redundantie: dat is het idee achter die drie kopieën van elk bestand dat is opgeslagen in HDFS, verspreid over het systeem.Meer specifiek, elk bestandsblok opgeslagen in HDFS heeft in totaal drie replica's. Als één systeem breekt met een specifiek bestand dat u nodig hebt, kunt u zich tot de andere twee wenden.
Het ontwerp van de slave-knooppuntserver schetsen
Om een balans te vinden tussen belangrijke factoren als totale eigendomskosten, opslagcapaciteit en prestaties, moet u het ontwerp van uw slaafknooppunten zorgvuldig plannen.
U ziet nu gewoonlijk slave-knooppunten waarbij elk knooppunt doorgaans 12 tot 16 lokaal aangesloten harde schijven van 3 TB heeft. Slave-knooppunten gebruiken redelijk snelle dual-socket CPU's met elk zes tot acht kernen - geen snelheidsduivels, met andere woorden. Dit gaat gepaard met 48 GB RAM. Kortom, deze server is geoptimaliseerd voor dichte opslag.
Omdat HDFS een bestandssysteem op gebruikersniveau-niveau is, is het belangrijk om het lokale bestandssysteem op de slave-knooppunten te optimaliseren voor gebruik met HDFS. In dit opzicht is een belangrijke beslissing bij het instellen van uw servers het kiezen van een bestandssysteem voor de Linux-installatie op de slaafknooppunten.
Ext3 is het meest gebruikte bestandssysteem, omdat het al een aantal jaren de meest stabiele optie is. Neem echter een kijkje op Ext4. Het is de volgende versie van Ext3 en deze is lang genoeg beschikbaar geweest om algemeen als stabiel en betrouwbaar te worden beschouwd.
Wat nog belangrijker is voor onze doeleinden, het heeft een aantal optimalisaties voor het verwerken van grote bestanden, waardoor het een ideale keuze is voor HDFS-slaveknoopservers.
Gebruik de Linux Logical Volume Manager (LVM) niet - dit is een extra laag tussen het Linux-bestandssysteem en HDFS, waardoor Hadoop zijn prestaties niet kan optimaliseren. Met name aggregeert LVM schijven, hetgeen het bronbeheer dat HDFS en YARN mogelijk maken, belemmert op basis van de manier waarop bestanden op de fysieke schijfeenheden worden gedistribueerd.
