Delen via

On-premises Apache Hadoop-clusters migreren naar Azure HDInsight

  • Artikel

Dit artikel bevat aanbevelingen voor gegevensopslag in Azure HDInsight-systemen. Het maakt deel uit van een reeks met aanbevolen procedures voor het migreren van on-premises Apache Hadoop-systemen naar Azure HDInsight.

Het juiste opslagsysteem kiezen voor HDInsight-clusters

De on-premises HDFS-mapstructuur (Apache Hadoop File System) kan opnieuw worden gemaakt in Azure Blob Storage of Azure Data Lake Storage. Vervolgens kunt u HDInsight-clusters die worden gebruikt voor berekeningen veilig verwijderen zonder dat gebruikersgegevens verloren gaan. Beide services kunnen worden gebruikt als zowel het standaardbestandssysteem als een extra bestandssysteem voor een HDInsight-cluster. Het HDInsight-cluster en het opslagaccount moeten in dezelfde regio worden gehost.

Azure Storage

HDInsight-clusters kunnen de blobcontainer in Azure Storage gebruiken als het standaardbestandssysteem of een extra bestandssysteem. Het opslagaccount voor de Standard-laag wordt ondersteund voor gebruik met HDInsight-clusters. De Premier-laag wordt niet ondersteund. In de standaard blobcontainer worden clusterspecifieke gegevens opgeslagen, zoals taakgeschiedenis en logboeken. Het delen van één blobcontainer als het standaardbestandssysteem voor meerdere clusters wordt niet ondersteund.

De opslagaccounts die zijn gedefinieerd in het aanmaakproces en de bijbehorende sleutels worden opgeslagen op %HADOOP_HOME%/conf/core-site.xml de clusterknooppunten. Ze kunnen ook worden geopend in de sectie Aangepaste kernsite in de HDFS-configuratie in de Ambari-gebruikersinterface. De sleutel van het opslagaccount wordt standaard versleuteld en er wordt een aangepast ontsleutelingsscript gebruikt om de sleutels te ontsleutelen voordat deze worden doorgegeven aan Hadoop-daemons. De taken, waaronder Hive, MapReduce, Hadoop-streaming en Pig, bevatten een beschrijving van opslagaccounts en metagegevens.

Azure Storage kan geografisch worden gerepliceerd. Hoewel geo-replicatie geografische herstel en gegevensredundantie biedt, heeft een failover naar de geo-gerepliceerde locatie ernstige gevolgen voor de prestaties en kunnen er extra kosten in rekening worden gebracht. De aanbeveling is om de geo-replicatie verstandig te kiezen en alleen als de waarde van de gegevens de extra kosten waard is.

Een van de volgende indelingen kan worden gebruikt voor toegang tot gegevens die zijn opgeslagen in Azure Storage:

Data Access-indeling Beschrijving
wasb:/// Toegang tot standaardopslag met behulp van niet-versleutelde communicatie.
wasbs:/// Toegang tot standaardopslag met versleutelde communicatie.
wasb://<container-name>@<account-name>.blob.core.windows.net/ Wordt gebruikt bij het communiceren met een niet-standaardopslagaccount. 

Schaalbaarheidsdoelen voor standaardopslagaccounts bevat de huidige limieten voor Azure Storage-accounts. Als de behoeften van de toepassing de schaalbaarheidsdoelen van één opslagaccount overschrijden, kan de toepassing worden gebouwd om meerdere opslagaccounts te gebruiken en vervolgens gegevensobjecten te partitioneren in deze opslagaccounts.

Azure Opslaganalyse biedt metrische gegevens voor alle opslagservices en Azure Portal kan worden geconfigureerd om metrische gegevens te verzamelen die via grafieken moeten worden gevisualiseerd. Waarschuwingen kunnen worden gemaakt om te melden wanneer drempelwaarden zijn bereikt voor metrische gegevens van opslagresources.

Azure Storage biedt voorlopig verwijderen voor blobobjecten om gegevens te herstellen wanneer deze per ongeluk worden gewijzigd of verwijderd door een toepassing of een andere gebruiker van het opslagaccount.

U kunt blob-momentopnamen maken. Een momentopname is een alleen-lezen versie van een blob die op een bepaald moment wordt gemaakt en biedt een manier om een back-up te maken van een blob. Zodra een momentopname is gemaakt, kan deze worden gelezen, gekopieerd of verwijderd, maar niet worden gewijzigd.

Notitie

Voor oudere versies van on-premises Hadoop-distributies die geen 'wasbs'-certificaat hebben, moeten ze worden geïmporteerd in het Java-vertrouwensarchief.

De volgende methoden kunnen worden gebruikt om certificaten te importeren in het Java-vertrouwensarchief:

Het Azure Blob TLS/SSL-certificaat downloaden naar een bestand

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

Het bovenstaande bestand importeren in het Java-vertrouwensarchief op alle knooppunten

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

Controleer of het toegevoegde certificaat zich in het vertrouwensarchief bevindt

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

Raadpleeg voor meer informatie de volgende artikelen:

Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 is de nieuwste opslagaanbiedingen. Het combineert de kernmogelijkheden van de eerste generatie van Azure Data Lake Storage Gen1 met een hadoop-compatibel bestandssysteemeindpunt dat rechtstreeks is geïntegreerd in Azure Blob Storage. Deze verbetering combineert de schaal- en kostenvoordelen van objectopslag met de betrouwbaarheid en prestaties die doorgaans alleen zijn gekoppeld aan on-premises bestandssystemen.

Azure Data Lake Storage Gen 2 is gebouwd op Azure Blob Storage en stelt u in staat om te interfacen met gegevens met behulp van zowel bestandssysteem- als objectopslagparadigma's. Functies van Azure Data Lake Storage Gen1, zoals semantiek van bestandssysteem, beveiliging op bestandsniveau en schaal, worden gecombineerd met goedkope, gelaagde opslag, mogelijkheden voor hoge beschikbaarheid/herstel na noodgevallen en een groot SDK-/hulpprogramma-ecosysteem van Azure Blob Storage. In Data Lake Storage Gen2 blijven alle eigenschappen van objectopslag behouden terwijl de voordelen van een bestandssysteeminterface die is geoptimaliseerd voor analyseworkloads, worden toegevoegd.

Een fundamentele functie van Data Lake Storage Gen2 is het toevoegen van een hiërarchische naamruimte aan de Blob Storage-service, waarmee objecten/bestanden worden ingedeeld in een hiërarchie van mappen voor performante gegevenstoegang. Met de hiërarchische structuur kunnen bewerkingen zoals het wijzigen of verwijderen van een map één atomische metagegevensbewerkingen in de map zijn in plaats van alle objecten te inventariseren en verwerken die het naamvoorvoegsel van de map delen.

In het verleden moesten analyses in de cloud inbreuk maken op het gebied van prestaties, beheer en beveiliging. De belangrijkste functies van Azure Data Lake Storage (ADLS) Gen2 zijn als volgt:

  • Hadoop-compatibele toegang: Met Azure Data Lake Storage Gen2 kunt u gegevens beheren en openen, net zoals met een Hadoop Distributed File System (HDFS). Het nieuwe ABFS-stuurprogramma is beschikbaar in alle Apache Hadoop-omgevingen die zijn opgenomen in Azure HDInsight. Met dit stuurprogramma hebt u toegang tot gegevens die zijn opgeslagen in Data Lake Storage Gen2.

  • Een superset van POSIX-machtigingen: het beveiligingsmodel voor Data Lake Gen2 biedt volledige ondersteuning voor ACL- en POSIX-machtigingen, samen met extra granulariteit die specifiek is voor Data Lake Storage Gen2. Instellingen kunnen worden geconfigureerd via beheerhulpprogramma's of via frameworks zoals Hive en Spark.

  • Rendabel: Data Lake Storage Gen2 biedt goedkope opslagcapaciteit en transacties. Naarmate gegevens worden overgegaan tot de volledige levenscyclus, veranderen de factureringstarieven om de kosten te minimaliseren via ingebouwde functies zoals de levenscyclus van Azure Blob Storage.

  • Werkt met Blob Storage-hulpprogramma's, frameworks en apps: Data Lake Storage Gen2 blijft werken met een breed scala aan hulpprogramma's, frameworks en toepassingen die momenteel bestaan voor Blob Storage.

  • Geoptimaliseerd stuurprogramma: het Stuurprogramma voor het Azure Blob Filesystem (ABFS) is speciaal geoptimaliseerd voor big data-analyses. De bijbehorende REST API's worden weergegeven via het dfs eindpunt, dfs.core.windows.net.

Een van de volgende indelingen kan worden gebruikt voor toegang tot gegevens die zijn opgeslagen in ADLS Gen2:

  • abfs:///: Open de standaard Data Lake Storage voor het cluster.
  • abfs://file_system@account_name.dfs.core.windows.net: Wordt gebruikt bij het communiceren met een niet-standaard Data Lake Storage.

Notitie

Het upgraden van het primaire of secundaire opslagaccount van een actief cluster met Azure Data Lake Storage Gen2-mogelijkheden wordt niet ondersteund. Als u het opslagtype van een bestaand HDInsight-cluster wilt wijzigen in Data Lake Storage Gen2, moet u het cluster opnieuw maken en een hiërarchisch opslagaccount met een naamruimte selecteren.

Raadpleeg voor meer informatie de volgende artikelen:

Azure Storage-sleutels beveiligen binnen de configuratie van een on-premises Hadoop-cluster

De Azure Storage-sleutels die worden toegevoegd aan de Hadoop-configuratiebestanden, zorgen voor verbinding tussen on-premises HDFS en Azure Blob Storage. Deze sleutels kunnen worden beveiligd door ze te versleutelen met het Hadoop-referentieproviderframework. Zodra ze zijn versleuteld, kunnen ze veilig worden opgeslagen en geopend.

De referenties inrichten:

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

Als u het bovenstaande providerpad wilt toevoegen aan de core-site.xml of aan de Ambari-configuratie onder aangepaste kernsite:

<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>

Notitie

De eigenschap providerpad kan ook als volgt worden toegevoegd aan de distcp-opdrachtregel in plaats van de sleutel op clusterniveau op core-site.xml op te slaan:

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

Toegang tot Azure Storage-gegevens beperken met behulp van SAS

HDInsight heeft standaard volledige toegang tot gegevens in de Azure Storage-accounts die zijn gekoppeld aan het cluster. Shared Access Signatures (SAS) in de blobcontainer kan worden gebruikt om de toegang tot de gegevens te beperken, zoals gebruikers alleen-lezentoegang tot de gegevens bieden.

Het SAS-token gebruiken dat is gemaakt met Python

  1. Open het bestand SASToken.py en wijzig de volgende waarden:

    Tokeneigenschap Beschrijving
    policy_name De naam die moet worden gebruikt voor het opgeslagen beleid dat moet worden gemaakt.
    storage_account_name De naam van uw opslagaccount.
    storage_account_key De sleutel voor het opslagaccount.
    storage_container_name De container in het opslagaccount waartoe u de toegang wilt beperken.
    example_file_path Het pad naar een bestand dat naar de container wordt geüpload.

  2. Het bestand SASToken.py wordt geleverd met de ContainerPermissions.READ + ContainerPermissions.LIST machtigingen en kan worden aangepast op basis van de use-case.

  3. Voer het script als volgt uit: python SASToken.py

  4. Hiermee wordt het SAS-token weergegeven dat vergelijkbaar is met de volgende tekst wanneer het script is voltooid: sr=c&si=policyname&sig=dOAi8CXuz5Fm15EjRUu5dHlOzYNtcK3Afp1xqxniEps%3D&sv=2014-02-14

  5. Als u de toegang tot een container met Shared Access Signature wilt beperken, voegt u een aangepaste vermelding toe aan de basissiteconfiguratie voor het cluster onder de eigenschap Advanced Custom Core-site Add van Ambari HDFS- configuraties.

  6. Gebruik de volgende waarden voor de velden Sleutel en Waarde :

    Sleutel: Waarde: fs.azure.sas.YOURCONTAINER.YOURACCOUNT.blob.core.windows.netde SAS-SLEUTEL die wordt geretourneerd door de Python-toepassing UIT stap 4 hierboven.

  7. Klik op de knop Toevoegen om deze sleutel en waarde op te slaan en klik vervolgens op de knop Opslaan om de configuratiewijzigingen op te slaan. Wanneer u hierom wordt gevraagd, voegt u een beschrijving toe van de wijziging (bijvoorbeeld sas-opslagtoegang toevoegen) en klikt u vervolgens op Opslaan.

  8. Selecteer IN de Ambari-webgebruikersinterface HDFS in de lijst aan de linkerkant en selecteer vervolgens Alles opnieuw opstarten in de vervolgkeuzelijst Serviceacties aan de rechterkant. Wanneer u hierom wordt gevraagd, selecteert u Alles opnieuw opstarten bevestigen.

  9. Herhaal dit proces voor MapReduce2 en YARN.

Er zijn drie belangrijke dingen die u moet onthouden over het gebruik van SAS-tokens in Azure:

  1. Wanneer SAS-tokens worden gemaakt met lees- en lijstmachtigingen, kunnen gebruikers die toegang hebben tot de Blob-container met dat SAS-token geen gegevens schrijven en verwijderen. Gebruikers die toegang hebben tot de Blob-container met dat SAS-token en een schrijf- of verwijderbewerking proberen, ontvangen een bericht zoals "This request is not authorized to perform this operation".

  2. Wanneer de SAS-tokens worden gegenereerd met READ + LIST + WRITE machtigingen (om alleen te beperken DELETE ), schrijven opdrachten zoals hadoop fs -put eerst naar een \_COPYING\_ bestand en proberen vervolgens de naam van het bestand te wijzigen. Deze HDFS-bewerking wordt toegewezen aan een copy+delete for WASB. Omdat de DELETE machtiging niet is opgegeven, mislukt de put. De \_COPYING\_ bewerking is een Hadoop-functie die is bedoeld om enige gelijktijdigheidsbeheer te bieden. Op dit moment is er geen manier om alleen de bewerking DELETE te beperken zonder dat dit ook van invloed is op 'WRITE'-bewerkingen.

  3. Helaas werkt de hadoop-referentieprovider en ontsleutelingssleutelprovider (ShellDecryptionKeyProvider) momenteel niet met de SAS-tokens en kan deze momenteel niet worden beveiligd tegen zichtbaarheid.

Zie Shared Access Signatures van Azure Storage gebruiken om de toegang tot gegevens in HDInsight te beperken voor meer informatie.

Gegevensversleuteling en replicatie gebruiken

Alle gegevens die naar Azure Storage worden geschreven, worden automatisch versleuteld met SSE (Storage Service Encryption). De gegevens in het Azure Storage-account worden altijd gerepliceerd voor hoge beschikbaarheid. Wanneer u een opslagaccount maakt, kunt u een van de volgende replicatieopties kiezen:

Azure Storage biedt lokaal redundante opslag (LRS), maar u moet ook kritieke gegevens kopiëren naar een ander Azure Storage-account in een andere regio met een frequentie die is afgestemd op de behoeften van het noodherstelplan. Er zijn verschillende methoden voor het kopiëren van gegevens, waaronder ADLCopy, DistCp, Azure PowerShell of Azure Data Factory.  Het wordt ook aanbevolen om toegangsbeleid af te dwingen voor een Azure Storage-account om onbedoeld verwijderen te voorkomen.

Raadpleeg voor meer informatie de volgende artikelen:

Extra Azure Storage-accounts koppelen aan cluster

Tijdens het maken van HDInsight wordt een Azure Storage-account, Azure Data Lake Storage Gen1 of Azure Data Lake Storage Gen2 gekozen als het standaardbestandssysteem. Naast dit standaardopslagaccount kunnen extra opslagaccounts worden toegevoegd vanuit hetzelfde Azure-abonnement of verschillende Azure-abonnementen tijdens het maken van het cluster of nadat een cluster is gemaakt.

U kunt op de volgende manieren extra opslagaccounts toevoegen:

  • Ambari HDFS Config Advanced Custom Core-site Voeg de naam van het opslagaccount en de sleutel voor het opnieuw opstarten van de services toe
  • Scriptactie gebruiken door de naam en sleutel van het opslagaccount door te geven

Notitie

In geldige gebruiksscenario's kunnen de limieten voor De Azure-opslag worden verhoogd via een aanvraag die is ingediend bij De ondersteuning van Azure.

Zie Extra opslagaccounts toevoegen aan HDInsight voor meer informatie.

Volgende stappen

Lees het volgende artikel in deze reeks: Best practices voor gegevensmigratie voor on-premises naar Azure HDInsight Hadoop-migratie.