Apache Hadoop YARN

Le plug-in YARN recherche les files d’attente et les noms des applications qu’elles contiennent, et gère les politiques d’accès sur ce que YARN décide : soumettre des applications aux files d’attente, administrer les files d’attente et administrer le cluster. L’ID du plug-in et le type de service sont tous deux yarn. Le plug-in de service s’exécute dans le serveur GrantForge ; l’agent YARN installé dans les ResourceManagers applique les politiques.

Les tests d’intégration Testcontainers du dépôt couvrent les ResourceManagers de Hadoop 3.2.4, construit à partir de la version Apache vérifiée par SHA-512, 3.3.6, 3.4.3 et 3.5.0, ainsi qu’un ResourceManager Kerberos 3.4.3 ; cela ne certifie pas toutes les autres versions.

Installation

La distribution contient le plug-in dans plugins/yarn. Vérifiez dans Administration de la plateforme → Plug-ins que yarn est activé ; analysez à nouveau le répertoire des plug-ins après une mise à jour. Le plug-in dialogue avec le ResourceManager via le client YARN de Hadoop lui-même, sur le client ombré de Hadoop 3.5.0, dans son propre chargeur de classes.

Ajouter un service de données

1. Ouvrez Permissions sur les données → Services de données, ajoutez un service et choisissez Apache Hadoop YARN (yarn).
2. Saisissez l’adresse client du ResourceManager, ou celle de chaque ResourceManager d’un cluster hautement disponible.
3. Choisissez comment l’utilisateur de recherche se connecte, saisissez-le, testez la connexion et enregistrez le service. Le test se connecte et décrit le cluster : combien de NodeManagers et combien de files d’attente il comporte.

Les paramètres portent les noms de Hadoop et peuvent être repris d’un yarn-site.xml. L’utilisateur de recherche permet à GrantForge de découvrir les ressources ; il est distinct des utilisateurs qui soumettent des applications. Un test de connexion réussi ne signifie pas que les soumissions sont déjà soumises aux politiques.

Le service est exactement ce que disent ses paramètres : aucun core-site.xml ni yarn-site.xml du serveur GrantForge n’est lu. Les paramètres Kerberos sont refusés en authentification simple ; Kerberos exige un mot de passe ou un keytab. Un ResourceManager qui refuse la connexion, par exemple parce qu’il attend Kerberos, est signalé comme une connexion refusée.

Kerberos

Avec kerberos, GrantForge connecte le principal via la connexion de Hadoop, à partir du keytab ou avec le mot de passe, conserve cette connexion et la renouvelle à partir du keytab ; rien d’autre sur le serveur GrantForge n’a besoin de paramètres Kerberos. Les realms dont les KDC figurent dans kerberos.kdc sont déclarés pour tout le serveur GrantForge, comme le font les plug-ins HDFS, Hive, Kafka, HBase et Trino, de sorte que plusieurs services peuvent utiliser des realms différents côte à côte.

Ressources et types d’accès

admin_queue implique submit_app, car les administrateurs d’une file d’attente peuvent y soumettre.

Comme dans YARN, une permission sur une file d’attente couvre les files situées en dessous : submit_app sur root.sales soumet à root.sales.etl. Une vérification est décidée dans chaque file du chemin, depuis la racine, et un refus dans l’une d’elles la rejette ; une politique peut ainsi autoriser root.sales et refuser root.sales.adhoc. Sous une file d’attente, un niveau application indique à quelles applications une permission s’applique : submit_app sur root.hr avec l’application payroll-* n’accepte que les applications dont le nom commence par payroll-, dans root.hr et les files en dessous.

Dans les valeurs de politique, * correspond à un nombre quelconque de caractères et ? à un seul. L’éditeur de politiques propose les files d’attente par leur chemin, ou par leur propre nom quand c’est ce qui est saisi, quel que soit l’ordonnanceur du cluster, ainsi que les noms des applications dont le ResourceManager se souvient encore dans les files nommées par une politique.

Adresses des clients

Un élément de politique peut ne valoir que pour certains clients : sa condition Adresses des clients (ip-range) accepte des adresses, des plages comme 10.1.0.0/16 et des noms d’hôte, comme les listes d’hôtes de Hadoop. Derrière un proxy, par exemple le proxy web de YARN ou un routeur, le client est la première adresse que les proxys ont transmise. Préférez les adresses et les plages aux noms d’hôte, qui coûtent une résolution de nom du client. YARN pose les questions d’administration sans l’adresse du client, la condition ne tient donc jamais sur cluster.

Exemple de politiques

Supposons que le cluster exécute les files d’attente root.sales.etl, root.sales.adhoc et root.hr. Créez ces politiques d’accès activées dans le même service de données :

Une fois que l’agent applique le nouvel instantané, les membres de analysts soumettent à root.sales.etl et root.sales.adhoc, mais alice seulement à root.sales.etl ; bob soumet des applications de paie à root.hr et rien d’autre ; carol soumet aux files des ventes et y arrête les applications ; les membres de etl-robots soumettent partout, mais uniquement depuis le réseau interne ; et les membres de yarn-admins rechargent les files d’attente.

Appliquer les politiques

Le plug-in de service gère les politiques et recherche les ressources. Pour les appliquer, il faut l’agent YARN dans chaque ResourceManager. Le déploiement et les vérifications sont décrits dans l’agent YARN.

Guides associés

• Services de données, politiques et agents
• Agent YARN
• Plug-ins et types de service