Un redéploiement simplifiée des données mainframe vers le cloud

Les mainframes d'IBM existent depuis les années 1950 et demeurent encore essentiels dans de nombreuses organisations. Ces dernières années, certaines d’entre elles ont cependant entrepris un redéploiement de leurs workloads vers le cloud. Cette démarche de modernisation est motivée à la fois par le besoin de rester pertinent, par la pénurie croissante d'experts en mainframes et par les économies promises par les solutions de cloud computing.

L'un des principaux défis du redéploiement des mainframes a toujours été le transfert des données de ces derniers vers le cloud. Heureusement, Google offre en libre accès son connecteur « bigquery-zos-mainframe » pour concrétiser de tels transferts avec un effort minimal.

À la découverte du connecteur Mainframe pour BigQuery et Cloud Storage ?

Le connecteur Mainframe permet aux utilisateurs de Google Cloud de transférer des données mainframes vers Cloud Storage et de soumettre des tâches BigQuery à partir de jobs mainframes  codés en JCL (le langage de contrôle des jobs des mainframes). Grâce à l'interpréteur Shell inclus et aux versions JVM des utilitaires de ligne de commande gsutil et bq, les équipes mainframes peuvent aisément gérer un pipeline ELT complet entièrement depuis z/OS.

Le connecteur déplace les données situées sur un mainframe vers - et depuis - Cloud Storage et BigQuery. Il transcode ces jeux de données directement au format ORC (un format pris en charge par BigQuery). En outre, il permet aux utilisateurs d'exécuter des tâches BigQuery à partir de JCL, de sorte que les jobs mainframes puissent tirer parti de certains des services les plus puissants de Google Cloud. 

Ce connecteur a été testé avec des fichiers plats créés par IBM DB2 EXPORT qui contiennent des champs de caractères binary-integer, packed-decimal et EBCDIC et qui peuvent être facilement représentés par un CopyBook (un fichier de description de données classiquement employé dans l’univers mainframes sous Cobol et DB2).
Les clients disposant de fichiers VSAM peuvent utiliser IDCAMS REPRO pour exporter ces données vers des fichiers plats, ces derniers pouvant ensuite être téléchargés à l'aide du connecteur.
Notez que le transcodage vers ORC nécessite un CopyBook et que tous les enregistrements doivent avoir la même mise en page. Si la mise en page est variable, le transcodage ne fonctionnera pas, mais il est toujours possible de télécharger directement une simple copie binaire du jeu de données.

Comment utiliser le connecteur bigquery-zos-mainframe ?

Un workflow de mise en œuvre du connecteur mainframe comprend en général les étapes suivantes :

- Lecture du jeu de données mainframe

- Transcodage du jeu de données en ORC

- Téléchargement de l'ORC vers Cloud Storage

- Enregistrement de cet ORC en tant que table externe

- Exécution d'une instruction DML MERGE pour charger de nouvelles données incrémentielles dans la table cible (sur le cloud).

Notez que si le jeu de données ne nécessite pas de modifications supplémentaires après le chargement, il est préférable d’opter pour un chargement dans une table native plutôt qu’une table externe.

En ce qui concerne l'étape 2, il est important de mentionner que les exportations DB2 sont écrites sous forme de jeux de données séquentiels sur le mainframe et que le connecteur utilise le CopyBook du jeu de données pour le transcoder en ORC.

L'exemple simplifié ci-dessous montre comment lire un jeu de données sur un mainframe, le transcoder au format ORC, copier le fichier ORC sur Cloud Storage, le charger dans une table native BigQuery et exécuter une commande SQL sur cette table.

1 – Vérifier et compiler

2 - Téléchargez l’assembly jar qui vient d'être créé dans target/scala-2.13 vers un chemin du système de fichiers unix de votre mainframe.

3- Installez la Procédure JCL BQSH sur n’importe quel jeu de données partitionné sur le mainframe que vous souhaitez utiliser comme PROCLIB. Modifiez la procédure pour mettre à jour le classpath Java avec le chemin du système de fichiers unix où vous avez téléchargé l'assembly jar. Vous pouvez modifier la procédure pour définir toute variable d'environnement spécifique à votre infrastructure.

4- Créer le Job

Etape 1

Cette étape lit le jeu de données dans INFILE DD et lit le modèle d'enregistrement dans COPYBOOK DD. Le jeu de données d'entrée peut être un fichier plat exporté depuis IBM DB2 ou un fichier VSAM. Les enregistrements lus à partir du jeu de données d'entrée sont écrits dans le fichier ORC à l'adresse gs://bucket/my_table.orc avec le nombre de partitions déterminé par la quantité de données.

Etape 2

Cette étape soumet un job BigQuery qui chargera les partitions de fichiers ORC de « my_table.orc » dans MY_DATASET.MY_TABLE. Notez que le chemin est bien celui utilisé à l'étape précédente.

Etape 3

Cette étape soumet un job de requêtage BigQuery (Request Job) pour exécuter une lecture SQL à partir du QUERY DD (un fichier FB au format LRECL 80). En général, la requête sera une instruction MERGE ou SELECT INTO qui entraîne la transformation d'une table BigQuery.
Note : le connecteur enregistrera les métriques du job mais n'écrira pas les résultats de la requête dans un fichier.

Fonctionner hors du mainframe pour économiser les MIPS

Sur un système de production, planifier des tâches générant de larges transferts de données n’est pas une chose à prendre à la légère.
Il est important de retenir que le connecteur Mainframe s'exécute dans un processus JVM et devrait donc utiliser les processeurs zIIP par défaut, mais si la capacité est épuisée, l'utilisation peut s'étendre aux processeurs généraux.
Étant donné que le transcodage d'enregistrements z/OS et l'écriture de partitions de fichiers ORC nécessitent une quantité non négligeable de traitements, le Mainframe Connector comprend un serveur gRPC conçu pour gérer les opérations de calcul intensif sur un serveur cloud (une instance VM sur Google Cloud Engine). En activant cette fonctionnalité, les traitements intensifs sont réalisés hors du mainframe sur un serveur cloud, le processus exécuté sur z/OS se contentant de télécharger le jeu de données vers Cloud Storage et d’effectuer un appel RPC.
Le passage du connecteur d’un mode d'exécution locale à un mode d’exécution distante ne nécessite qu'un changement de variable d'environnement. Des informations détaillées sur cette fonctionnalité sont disponibles ici.  

Remerciements

Merci à ceux qui ont testé, débogué, maintenu et amélioré cet outil : Timothy Manuel, Catherine Im, Madhavi Kancharla, Suresh Balakrishnan, Viktor Fedinchuk, Pavlo Kravets.