Aujourd'hui je vous propose un petit billet pour comprendre ce qu'il peut se cacher derrière l'erreur CAS "ERROR: A block of records on a failed node could not be activated among the remaining worker nodes."
Cela peut vous aider dans vos investigations si vous y êtes confronté dans le cadre de l'utilisation de tables dans CAS.
Voici une copie d'écran de cette erreur dans SAS StudioV :
Pour faire simple, ce message d'erreur indique que, lors d'une tentative de lecture d'une table CAS en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., l'accès d'une partie des données en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. n'est pas possible.
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., comme l'indique la log du CAS Controller (en mode debug) : [caption id="attachment_2874" align="aligncenter" width="1119"]
Number of rows (720) oes not match file row total (1440)[/caption]
Le CAS Controller n'a pu lire en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. que 720 lignes sur les 1440 lignes de ma table. Confronté à cette erreur, CAS cherche donc les blocs manquant dans son cache disque (CAS_DISK_CACHE). Mais le message d'erreur "A block of records on a failed node could not be activated among the remaining worker nodes" indique qu'il ne parvient pas à accéder aux blocs pour reconstituer les données de la table absents de la mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya.. Dans mon cas, une analyse de process CAS montre qu'un des CAS workers n'est pas disponible. le CAS Controller est bien actif, mais sur l'une des CAS workers, aucun process cas n'est actif ( process caslaunch et cas absent). Je n'ai donc qu'un seul CAS worker au lieu de 2.
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., j'ai fait le choix de ne pas dupliquer les blocs entre les CAS workers :
Avec REPLICATION à 0, l'espace occupé dans le cas disque de
Avec REPLICATION à 1, CAS peut reconstruire sa mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. à partir des données dans le cache disque.
En affichant les détails de la table en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. via le code ci-dessous, on voit que la table n'est maintenant chargé que dans la mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. d'un seul CAS Worker :
Avant le "crash" d'un de mes deux CAS workers, les blocs actifs était bien répliqués sur les deux CAS worker :
Hors, avec REPLICATION=0, les infomations sur la table montrens l'absence de blocs répliqués :
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. mais avec l'absence de réplication entre les workers. Sans réplication le failover n'est pas possible.
Pour faire simple, ce message d'erreur indique que, lors d'une tentative de lecture d'une table CAS en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., l'accès d'une partie des données en mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. n'est pas possible.
Analyse des logs du CAS Controller
CAS ne parvient pas à lire la totalité de la table CAS en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., comme l'indique la log du CAS Controller (en mode debug) : [caption id="attachment_2874" align="aligncenter" width="1119"]
Number of rows (720) oes not match file row total (1440)[/caption]
Le CAS Controller n'a pu lire en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. que 720 lignes sur les 1440 lignes de ma table. Confronté à cette erreur, CAS cherche donc les blocs manquant dans son cache disque (CAS_DISK_CACHE). Mais le message d'erreur "A block of records on a failed node could not be activated among the remaining worker nodes" indique qu'il ne parvient pas à accéder aux blocs pour reconstituer les données de la table absents de la mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya.. Dans mon cas, une analyse de process CAS montre qu'un des CAS workers n'est pas disponible. le CAS Controller est bien actif, mais sur l'une des CAS workers, aucun process cas n'est actif ( process caslaunch et cas absent). Je n'ai donc qu'un seul CAS worker au lieu de 2.
Mais pourquoi CAS n'a pas réussi à trouver les blocs manquants ?
L'explication est toute simple. Lors du chargement de ma table en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya., j'ai fait le choix de ne pas dupliquer les blocs entre les CAS workers :
Avec REPLICATION à 0, l'espace occupé dans le cas disque de
Avec REPLICATION à 1, CAS peut reconstruire sa mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. à partir des données dans le cache disque.
En affichant les détails de la table en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. via le code ci-dessous, on voit que la table n'est maintenant chargé que dans la mémoireGemini said
Espace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. d'un seul CAS Worker :
Avant le "crash" d'un de mes deux CAS workers, les blocs actifs était bien répliqués sur les deux CAS worker :
Hors, avec REPLICATION=0, les infomations sur la table montrens l'absence de blocs répliqués :
Pour résumer
Le message d'erreur "A block of records on a failed node could not be activated among the remaining worker nodes " se produit après la perte d'un ou plusieurs CAS workers lors de la lecture d'une table en mémoireGemini saidEspace de stockage temporaire (RAM) utilisé par le moteur CAS pour charger et traiter les données à haute vitesse, minimisant les accès disque pour optimiser les performances de SAS Viya. mais avec l'absence de réplication entre les workers. Sans réplication le failover n'est pas possible.






