Migrera lokala Apache Hadoop-kluster till Azure HDInsight

Den här artikeln ger rekommendationer för datalagring i Azure HDInsight-system. Det är en del av en serie som innehåller metodtips som hjälper dig att migrera lokala Apache Hadoop-system till Azure HDInsight.

Välj rätt lagringssystem för HDInsight-kluster

Den lokala katalogstrukturen för Apache Hadoop File System (HDFS) kan återskapas i Azure Blob Storage eller Azure Data Lake Storage. Du kan sedan på ett säkert sätt ta bort HDInsight-kluster som används för beräkning utan att förlora användardata. Båda tjänsterna kan användas både som standardfilsystem och ett ytterligare filsystem för ett HDInsight-kluster. HDInsight-klustret och lagringskontot måste finnas i samma region.

Azure Storage

HDInsight-kluster kan använda blobcontainern i Azure Storage som antingen standardfilsystem eller ett ytterligare filsystem. Lagringskontot på standardnivå stöds för användning med HDInsight-kluster. Premier-nivån stöds inte. Standardcontainern lagrar klusterspecifik information, till exempel jobbhistorik och loggar. Det går inte att dela en blobcontainer som standardfilsystem för flera kluster.

De lagringskonton som definieras i skapandeprocessen och deras respektive nycklar lagras i %HADOOP_HOME%/conf/core-site.xml på klusternoderna. De kan också nås under avsnittet "Anpassad kärnplats" i HDFS-konfigurationen i Ambari-användargränssnittet. Lagringskontonyckeln krypteras som standard och ett anpassat dekrypteringsskript används för att dekryptera nycklarna innan de skickas vidare till Hadoop-daemoner. Jobben, inklusive Hive, MapReduce, Hadoop-strömning och Pig, har en beskrivning av lagringskonton och metadata med sig.

Azure Storage kan geo-replikeras. Även om geo-replikering ger geografisk återställning och dataredundans, påverkar en redundans till den geo-replikerade platsen prestandan allvarligt, och det kan medföra ytterligare kostnader. Rekommendationen är att välja geo-replikering klokt och endast om värdet för data är värt den extra kostnaden.

Ett av följande format kan användas för att komma åt data som lagras i Azure Storage:

Dataåtkomstformat	beskrivning
wasb:///	Få åtkomst till standardlagring med okrypterad kommunikation.
wasbs:///	Få åtkomst till standardlagring med krypterad kommunikation.
wasb://<container-name>@<account-name>.blob.core.windows.net/	Används vid kommunikation med ett lagringskonto som inte är standard.

Skalbarhetsmål för standardlagringskonton visar de aktuella gränserna för Azure Storage-konton. Om programmets behov överskrider skalbarhetsmålen för ett enda lagringskonto kan programmet skapas för att använda flera lagringskonton och sedan partitioneras dataobjekt mellan dessa lagringskonton.

Azure Lagringsanalys tillhandahåller mått för alla lagringstjänster och Azure Portal kan konfigureras samla in mått som ska visualiseras via diagram. Aviseringar kan skapas för att meddela när tröskelvärden har nåtts för lagringsresursmått.

Azure Storage erbjuder mjuk borttagning för blobobjekt som hjälper till att återställa data när de oavsiktligt ändras eller tas bort av ett program eller en annan lagringskontoanvändare.

Du kan skapa blobögonblicksbilder. En ögonblicksbild är en skrivskyddad version av en blob som tas vid en tidpunkt och ger ett sätt att säkerhetskopiera en blob. När en ögonblicksbild har skapats kan den läsas, kopieras eller tas bort, men inte ändras.

Kommentar

För äldre versioner av lokala Hadoop-distributioner som inte har "wasbs"-certifikatet måste de importeras till Java-förtroendearkivet.

Följande metoder kan användas för att importera certifikat till Java Trust Store:

Ladda ned Azure Blob TLS/SSL-certifikatet till en fil

echo -n | openssl s_client -connect <storage-account>.blob.core.windows.net:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > Azure_Storage.cer

Importera filen ovan till Java-förtroendearkivet på alla noder

keytool -import -trustcacerts -keystore /path/to/jre/lib/security/cacerts -storepass changeit -noprompt -alias blobtrust -file Azure_Storage.cer

Kontrollera att det tillagda certifikatet finns i förtroendearkivet

keytool -list -v -keystore /path/to/jre/lib/security/cacerts

Mer information finns i följande artiklar:

• Använda Azure Storage med Azure HDInsight-kluster
• Skalbarhetsmål för standardlagringskonton
• Skalbarhets- och prestandamål för Blob Storage
• Prestanda och skalbarhetschecklista för Microsoft Azure Storage
• Övervaka, diagnostisera och felsöka Microsoft Azure Storage
• Övervaka ett lagringskonto i Azure-portalen

Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 är det senaste lagringserbjudandet. Den förenar kärnfunktionerna från den första generationen av Azure Data Lake Storage Gen1 med en Hadoop-kompatibel filsystemslutpunkt som är direkt integrerad i Azure Blob Storage. Den här förbättringen kombinerar skalnings- och kostnadsfördelarna med objektlagring med den tillförlitlighet och prestanda som vanligtvis endast är associerad med lokala filsystem.

Azure Data Lake Storage Gen 2 bygger på Azure Blob Storage och gör att du kan interagera med data med både filsystem och objektlagringsparadigm. Funktioner från Azure Data Lake Storage Gen1, till exempel filsystemssemantik, säkerhet på filnivå och skalning, kombineras med låg kostnad, nivåindelad lagring, funktioner för hög tillgänglighet/haveriberedskap och ett stort SDK/verktygsekosystem från Azure Blob Storage. I Data Lake Storage Gen2 finns alla egenskaper för objektlagring kvar samtidigt som fördelarna med ett filsystemgränssnitt som är optimerat för analysarbetsbelastningar läggs till.

En grundläggande funktion i Data Lake Storage Gen2 är att lägga till ett hierarkiskt namnområde i Blob Storage-tjänsten, som organiserar objekt/filer i en hierarki med kataloger för att utföra dataåtkomst. Den hierarkiska strukturen gör det möjligt för åtgärder som att byta namn på eller ta bort en katalog att vara enstaka atomiska metadataåtgärder i katalogen i stället för att räkna upp och bearbeta alla objekt som delar katalogens namnprefix.

Tidigare var molnbaserad analys tvungen att kompromissa när det gäller prestanda, hantering och säkerhet. De viktigaste funktionerna i Azure Data Lake Storage (ADLS) Gen2 är följande:

• Hadoop-kompatibel åtkomst: Med Azure Data Lake Storage Gen2 kan du hantera och komma åt data precis som med ett Hadoop Distributed File System (HDFS). Den nya ABFS-drivrutinen är tillgänglig i alla Apache Hadoop-miljöer som ingår i Azure HDInsight. Med den här drivrutinen kan du komma åt data som lagras i Data Lake Storage Gen2.

• En supermängd POSIX-behörigheter: Säkerhetsmodellen för Data Lake Gen2 har fullt stöd för ACL- och POSIX-behörigheter tillsammans med lite extra kornighet som är specifik för Data Lake Storage Gen2. Inställningar kan konfigureras via administratörsverktyg eller via ramverk som Hive och Spark.

• Kostnadseffektivt: Data Lake Storage Gen2 har låg kostnad för lagringskapacitet och transaktioner. När data övergår genom hela livscykeln ändras faktureringspriserna för att minimera kostnaderna via inbyggda funktioner, till exempel livscykeln för Azure Blob Storage.

• Fungerar med Blob Storage-verktyg, ramverk och appar: Data Lake Storage Gen2 fortsätter att fungera med en mängd olika verktyg, ramverk och program som finns idag för Blob Storage.

• Optimerad drivrutin: Drivrutinen för Azure Blob Filesystem (ABFS) är särskilt optimerad för stordataanalys. Motsvarande REST-API:er visas via dfs slutpunkten, dfs.core.windows.net.

Ett av följande format kan användas för att komma åt data som lagras i ADLS Gen2:

• abfs:///: Få åtkomst till Data Lake Storage som standard för klustret.
• abfs://file_system@account_name.dfs.core.windows.net: Används när du kommunicerar med en Data Lake Storage som inte är standard.

Kommentar

Uppgradering av det primära eller sekundära lagringskontot för ett kluster som körs med Azure Data Lake Storage Gen2-funktioner stöds inte. Om du vill ändra lagringstypen för ett befintligt HDInsight-kluster till Data Lake Storage Gen2 måste du återskapa klustret och välja ett hierarkiskt namnområde aktiverat lagringskonto.

Mer information finns i följande artiklar:

• Introduktion till Azure Data Lake Storage Gen2
• Drivrutinen för Azure Blob Filesystem (ABFS.md)
• Använda Azure Data Lake Storage Gen2 med Azure HDInsight-kluster

Skydda Azure Storage-nycklar i lokal Hadoop-klusterkonfiguration

Azure Storage-nycklarna som läggs till i Hadoop-konfigurationsfilerna upprättar anslutning mellan lokal HDFS och Azure Blob Storage. Dessa nycklar kan skyddas genom att kryptera dem med ramverket för Hadoop-autentiseringsuppgifter. När de har krypterats kan de lagras och nås på ett säkert sätt.

Så här etablerar du autentiseringsuppgifterna:

hadoop credential create fs.azure.account.key.account.blob.core.windows.net -value <storage key> -provider jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks/file

Så här lägger du till providersökvägen ovan till core-site.xml eller till Ambari-konfigurationen under anpassad kärnplats:

<property>
    <name>hadoop.security.credential.provider.path</name>
        <value>
        jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks
        </value>
    <description>Path to interrogate for protected credentials.</description>
</property>

Kommentar

Egenskapen providersökväg kan också läggas till på distcp-kommandoraden i stället för att lagra nyckeln på klusternivå på core-site.xml enligt följande:

hadoop distcp -D hadoop.security.credential.provider.path=jceks://hdfs@headnode.xx.internal.cloudapp.net/path/to/jceks /user/user1/ wasb:<//yourcontainer@youraccount.blob.core.windows.net/>user1

Begränsa åtkomsten till Azure Storage-data med SAS

HDInsight har som standard fullständig åtkomst till data i De Azure Storage-konton som är associerade med klustret. Signaturer för delad åtkomst (SAS) i blobcontainern kan användas för att begränsa åtkomsten till data, till exempel ge användarna skrivskyddad åtkomst till data.

Använda SAS-token som skapats med Python

1. Öppna filen SASToken.py och ändra följande värden:

   Tokenegenskap	beskrivning
   policy_name	Namnet som ska användas för den lagrade principen som ska skapas.
   storage_account_name	Namnet på ditt lagringskonto.
   storage_account_key	Nyckeln för lagringskontot.
   storage_container_name	Containern i lagringskontot som du vill begränsa åtkomsten till.
   example_file_path	Sökvägen till en fil som laddas upp till containern.

2. Filen SASToken.py levereras med behörigheterna ContainerPermissions.READ + ContainerPermissions.LIST och kan justeras baserat på användningsfallet.

3. Kör skriptet på följande sätt: python SASToken.py

4. Den visar SAS-token som liknar följande text när skriptet är klart: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

5. Om du vill begränsa åtkomsten till en container med signatur för delad åtkomst lägger du till en anpassad post i kärnplatskonfigurationen för klustret under Ambari HDFS Configs Advanced Custom core-site Add property.

6. Använd följande värden för fälten Nyckel och Värde :

   Nyckel: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netVärde: SAS-nyckeln som returneras av Python-programmet FRÅN steg 4 ovan.

7. Klicka på knappen Lägg till för att spara den här nyckeln och värdet och klicka sedan på knappen Spara för att spara konfigurationsändringarna. När du uppmanas att göra det lägger du till en beskrivning av ändringen (till exempel "lägga till SAS-lagringsåtkomst" och klicka sedan på Spara.

8. I webbgränssnittet för Ambari väljer du HDFS i listan till vänster och väljer sedan Starta om alla som påverkas i listrutan Tjänståtgärder till höger. När du uppmanas till det väljer du Bekräfta starta om alla.

9. Upprepa den här processen för MapReduce2 och YARN.

Det finns tre viktiga saker att komma ihåg om användningen av SAS-token i Azure:

1. När SAS-token skapas med behörigheten "LÄS + LISTA" kommer användare som har åtkomst till Blob-containern med den SAS-token inte att kunna "skriva och ta bort" data. Användare som har åtkomst till blobcontainern med den SAS-token och provar en skriv- eller borttagningsåtgärd får ett meddelande som "This request is not authorized to perform this operation".

2. När SAS-token genereras med READ + LIST + WRITE behörigheter (endast för att begränsa DELETE ), skriver kommandon som hadoop fs -put först till en \_COPYING\_ fil och försöker sedan byta namn på filen. Den här HDFS-åtgärden mappar till en copy+delete för WASB. Eftersom behörigheten DELETE inte angavs skulle "put" misslyckas. Åtgärden \_COPYING\_ är en Hadoop-funktion som är avsedd att ge viss samtidighetskontroll. För närvarande finns det inget sätt att begränsa bara "DELETE"-åtgärden utan att påverka "WRITE"-åtgärder också.

3. Tyvärr fungerar inte providern för hadoop-autentiseringsuppgifter och dekrypteringsnyckelprovidern (ShellDecryptionKeyProvider) för närvarande inte med SAS-token och kan för närvarande inte skyddas från synlighet.

Mer information finns i Använda signaturer för delad åtkomst i Azure Storage för att begränsa åtkomsten till data i HDInsight.

Använda datakryptering och replikering

Alla data som skrivs till Azure Storage krypteras automatiskt med hjälp av SSE (Storage Service Encryption). Data i Azure Storage-kontot replikeras alltid för hög tillgänglighet. När du skapar ett lagringskonto kan du välja något av följande replikeringsalternativ:

• Lokalt redundant lagring (LRS)
• Zonredundant lagring (ZRS)
• Geo-redundant lagring (GRS)
• Geo-redundant lagring med läsbehörighet (RA-GRS)

Azure Storage tillhandahåller lokalt redundant lagring (LRS), men du bör också kopiera kritiska data till ett annat Azure Storage-konto i en annan region med en frekvens som är anpassad efter behoven i haveriberedskapsplanen. Det finns olika metoder för att kopiera data, inklusive ADLCopy, DistCp, Azure PowerShell eller Azure Data Factory.  Vi rekommenderar också att du tillämpar åtkomstprinciper för Azure Storage-kontot för att förhindra oavsiktlig borttagning.

Mer information finns i följande artiklar:

• Azure Storage-replikering
• Katastrofvägledning för Azure Data Lake Storage Gen1 (ADLS)

Koppla ytterligare Azure Storage-konton till klustret

När HDInsight skapas väljs ett Azure Storage-konto, Azure Data Lake Storage Gen1 eller Azure Data Lake Storage Gen2 som standardfilsystem. Utöver det här standardlagringskontot kan ytterligare lagringskonton läggas till från samma Azure-prenumeration eller olika Azure-prenumerationer under klusterskapandeprocessen eller efter att ett kluster har skapats.

Ytterligare lagringskonto kan läggas till på ett på följande sätt:

• Ambari HDFS Config Advanced Custom Core-site Lägg till lagringskontots namn och nyckel Starta om tjänsterna
• Använda skriptåtgärd genom att skicka lagringskontots namn och nyckel

Kommentar

I giltiga användningsfall kan gränserna för Azure Storage ökas via en begäran till Azure Support.

Mer information finns i Add additional storage accounts to HDInsight (Lägga till fler lagringskonton till HDInsight).

Nästa steg

Läs nästa artikel i den här serien: Metodtips för datamigrering för migrering lokalt till Azure HDInsight Hadoop-migrering.