introduction

Dans cet article, je vais parler de ce que fait le mainframe avec le traitement des erreurs et en quoi il diffère du traitement des erreurs Linux.

La raison directe de la rédaction de cet article était une demande d'une certaine personne. Cependant, j'ai toujours pensé que l'idée d'un traitement anormal de la trame principale était souvent utile même à l'ère actuelle, lorsque les systèmes utilisant des serveurs PC et des nuages sont devenus majeurs.

Je travaille maintenant autour du noyau Linux, mais il y a environ 20 ans, j'ai été affecté à l'équipe de développement du système d'exploitation mainframe et j'ai écrit un pilote pour un certain coprocesseur sur le mainframe. C'était. A cette époque, j'ai eu de nombreuses occasions d'expérimenter la façon de penser le traitement anormal, et j'ai senti que l'expérience à cette époque était encore très utile 20 ans plus tard.

En premier lieu, le cadre principal est un système qui soutient tranquillement la fondation de la société depuis de nombreuses années. Par exemple, dans le système comptable de la banque, c'est-à-dire le système qui tient le grand livre de votre compte, le cadre principal occupe toujours un grand nombre [^ 4]. Le cadre principal a été utilisé comme un système qui continue de fonctionner normalement tous les jours et devient un problème social en cas de problème. Même les derniers systèmes peuvent avoir des indications sur ce que fait le mainframe en cas d'anomalie. Nous espérons que les lecteurs se référeront à cet article avec le mot «Je ne sais pas nouveau».

[^ 4]: Wikipédia "[Système de comptabilité](https://ja.wikipedia.org/wiki/%E5%8B%98%E5%AE%9A%E7%B3%BB%E3%82%B7" % E3% 82% B9% E3% 83% 86% E3% 83% A0) "

Refus (à propos des conditions)

J'ai eu beaucoup de mal et de difficultés à écrire cet article sur les termes. Les termes mainframe sont souvent différents des termes Unix / Linux et n'ont pas toujours exactement la même fonctionnalité.

Par exemple, la documentation mainframe d'IBM [peut être écrite](https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.2.0/com.ibm.zos.v2r2. ikjb600 / ikj2k200_ESTAE_and_ESTAI_Exit_Routines.htm).

La routine de sortie ESTAE est définie en émettant la macro instruction ESTAE.

ESTAE sera décrit plus tard, mais la macro ici fait référence au processus d'appel de l'appel système [^ 3] ou de la fonction de bibliothèque sous Unix / Linux. Le nom de cette macro est que le programme de contrôle système de la trame principale est écrit sur une base assembleur, une série de flux lors de l'appel de la fonction est enregistrée comme macro et cette macro est utilisée lors de l'appel. Vient de De même, le terme «routine de sortie» peut être plus approprié pour le lecteur en tant que «gestionnaire». De cette manière, même le simple appel d'une fonction est souvent appelé différemment dans le système d'exploitation mainframe.

Je suis plus familier avec des termes tels que Unix / Linux, donc j'écris un peu plus pour cela. Cependant, veuillez noter qu'il ne s'agit pas d'une description précise en tant que cadre principal.

De plus, je suis loin du cadre principal depuis près de 20 ans, donc je pense qu'il y a des erreurs. Je vous serais reconnaissant si vous pouviez signaler un tel endroit.

[^ 3]: Ceci est également appelé une routine SVC (Super Visor Call) au lieu d'un appel système dans le cadre principal.

Concept de traitement anormal de la trame principale

Eh bien, tout d'abord, je vais expliquer l'idée de base du traitement anormal de la trame principale. Le texte suivant décrira le mieux cela. Ce texte est un manuel de MVS [^ 1], qui est le système d'exploitation du cadre principal de l'ancien IBM "Fonctions et structure de MVS" % 81% AE% E6% A9% 9F% E8% 83% BD% E3% 81% A8% E6% A7% 8B% E9% 80% A0-% E5% 8D% 83% E7% 94% B0-% E6 Il s'agit d'un extrait de% AD% A3% E5% BD% A6 / dp / 4844372890). (Souligné par l'auteur)

[^ 1]: Actuellement, le système d'exploitation mainframe d'IBM est z / OS, mais l'idée de base devrait s'appliquer à la fois à MVS et à z / OS.

L'objectif principal de MVS est de maximiser la disponibilité du système et de minimiser l'impact sur les utilisateurs en cas de panne matérielle ou logicielle. En cas de panne, nous essayons d'abord de récupérer le travail et les ressources, mais si cela échoue, même si la partie défectueuse est séparée du système, tout le système continuera à fonctionner __ et l'utilisateur l'utilisera. Essayez de rester prêt.

Veuillez noter que l'ensemble du système ici n'est pas __ mais __ que nous parlons de l'ensemble du système tel qu'un système de cluster en cluster. Cette phrase parle en fait de __ "1 matériel + 1 OS" __ configuration. En d'autres termes, MVS vise une opération __ qui minimise ce __failure dans un système qui l'exploite. Sous Linux, même si le noyau est inévitablement paniqué, le cadre principal localise la panne et l'isole pour que le système continue de fonctionner autant que possible.

Bien sûr, il y a une limite à ce qui peut être fait avec un seul système, il est donc naturellement possible d'effectuer la redondance en regroupant même dans le cadre principal, mais on peut dire que la caractéristique du cadre principal est de viser l'opération ci-dessus même dans un système. Probablement.

On peut dire que l'idée de valoriser au maximum le fonctionnement continu d'une unité est née parce que le prix unitaire par ordinateur était encore élevé à l'époque où le châssis principal était développé.

Enregistrer un gestionnaire de gestion des erreurs (ESTATE)

Afin d'atteindre l'objectif ci-dessus, dans le système d'exploitation de la trame principale, enregistrez un gestionnaire pour le traitement lorsqu'une erreur critique se produit et enregistrez un gestionnaire pour un traitement anormal appelé routine de sortie __ESTAE __ avec la macro __ESTAE __ ci-dessus. C'est fait [^ 6]. Dans le traitement normal des erreurs, l'erreur est transmise par le code retour du sous-programme appelé, mais dans le cas d'un certain état anormal, le gestionnaire de traitement anormal enregistré à l'aide de cette fonction appelée ESTAE On l'appelle. La signification de ce gestionnaire peut être plus facile à comprendre si vous considérez un gestionnaire de signaux pour les programmes en langage C sous Unix / Linux et un gestionnaire enregistré avec defer () pour le langage Go. Cependant, dans le cas du système d'exploitation de la trame principale, cette fonction ESTAE peut être utilisée même à l'intérieur de l'appel système.

[^ 6]: D'après les critiques, il y a ESPIE en plus de l'ESTAE. (ESTAE a un plus large éventail de fonctions). Malheureusement, je n'ai jamais utilisé ESPIE.

Le gestionnaire de cette gestion des erreurs est appelé dans les cas suivants.

Erreur de programme. Par exemple, accès au pointeur NULL.
Erreur matérielle. (Si le CPU etc. tombe en panne, ce gestionnaire sera appelé à partir d'un autre processeur normal si la récupération par ECC etc. n'est pas possible comme indiqué dans la figure ci-dessous.)
Erreur d'E / S à l'entrée de la page pendant le processus de pagination du système d'exploitation
Lorsque l'opérateur (force) termine le programme de travail, etc.
etc.

De cette manière, il se caractérise par le fait d'être appelé non seulement en cas de bogues logiciels mais également en cas d'anomalies matérielles. Dans le cas d'une erreur matérielle, la façon dont ce gestionnaire est appelé est effectuée dans l'ordre suivant, comme illustré dans la figure suivante.

La CPU qui détecte l'erreur (contrôle machine) génère une interruption de contrôle machine.
Machine Check Handler (MCH) détermine si la récupération est possible par ECC, etc., et si la récupération est possible, reprend à partir du traitement interrompu.
S'il détermine qu'il ne peut pas être récupéré, il informera l'autre processeur de l'anomalie si elle existe.
Le processeur notifié de l'anomalie exécute le Recovery Termination Manager (RTM).
RTM appelle le gestionnaire ESTAE enregistré (non illustré sur cette figure).

(La figure est extraite de "Fonctions et structure de MVS")

Les caractéristiques d'ESTAE sont les suivantes.

Plusieurs gestionnaires ESTAE peuvent être enregistrés et imbriqués. Par exemple, si le module qui a enregistré le gestionnaire ESTAE A appelle un autre module et que ce module enregistre le gestionnaire ESTAE B et qu'une erreur se produit, le gestionnaire ESTAE B est appelé. Très utile étant donné que les gestionnaires de signaux Unix / Linux ne peuvent pas être imbriqués.
Dans la relation décrite en 1., si le gestionnaire de traitement anormal du sous-programme appelé ne peut pas être récupéré, le gestionnaire de traitement anormal de l'appelant est appelé. (C'est ce qu'on appelle la percoration). Cela prend la forme de la responsabilité du parent de la mauvaise gestion de l'enfant (?).

Un diagramme simple de cette situation est le suivant.

Enregistrement du gestionnaire de manipulation anormale (FRR)

En plus de ESTAE, le cadre principal a également une fonction appelée FRR. FRR peut également enregistrer un gestionnaire de traitement des erreurs comme ESTAE, mais la différence par rapport à ESTAE est que MW et les applications ne peuvent pas être utilisés uniquement pour le système [^ 5] Au lieu de cela, le gestionnaire __ est appelé tout en maintenant le verrou système __. C'est un point. L'avantage est que vous n'avez pas à vous soucier des verrous morts car vous n'avez pas à sécuriser à nouveau le verrou pendant le processus d'erreur, car vous pouvez continuer le processus d'erreur tout en maintenant le verrou.

Ceux qui ont du mal avec la spécification de sécurité du signal asynchrone Unix / Linux peuvent trouver cette valeur. Plutôt que de limiter les «fonctions qui peuvent être appelées dans le gestionnaire de signaux», il sera plus facile pour le processus de récupération d'avoir un gestionnaire dédié lors du maintien du verrou.

Si un gestionnaire FRR est inscrit, ce gestionnaire sera appelé avant le gestionnaire ESTAE. Il s'agit d'une fonction pratique qui peut être utilisée lorsque des ressources doivent être renvoyées, par exemple lorsque le verrou système doit être renvoyé.

[^ 5]: Cependant, dans le manuel z / OS, ["Toute fonction de programme peut utiliser SET FRR ..."](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com. Comme il est écrit sous la forme ibm.zos.v2r1.ieaa400 / setfrr.htm), il peut être possible de l'appeler non seulement dans le programme système mais également dans z / OS.

Que faire avec le gestionnaire d'anomalies?

Dans la routine de sortie de gestion des anomalies, d'après mon expérience lors de l'écriture d'un pilote pour un coprocesseur, je faisais ce qui suit:

Enregistrez les informations de débogage lorsqu'une erreur se produit
Notification d'anomalie au composant utilisant la fonction
Réparez les pointeurs dans les composants si possible
Retour des ressources utilisées (verrou, mémoire réservée, etc.)
Si la réparation n'est pas possible, configurez pour renvoyer une erreur lorsque la fonction est à nouveau appelée.

Regardons chacun à son tour.

1. Enregistrez les informations de débogage lorsqu'une erreur se produit

Afin de pouvoir rechercher la cause de l'état lorsqu'une anomalie se produit ultérieurement, nous collecterons des vidages partiels, des journaux et des traces d'exécution des pièces associées. Même s'il s'agit d'un échec de synchronisation difficile tel que la fréquence qui se produit une fois par an, c'est un problème qui vient de se produire du point de vue de l'utilisateur final. Dans un tel cas, vous devez enregistrer les informations pour le débogage et les utiliser pour trouver la cause. Il est important de collecter des données telles que l'état interne du composant dans lequel l'anomalie s'est produite et la structure associée à ce moment-là.

Je l'ai écrit comme un vidage partiel, mais dans le pilote que j'ai écrit, seules les parties pertinentes telles que la zone de mémoire utilisée par ce pilote ont été collectées dans le vidage. De plus, après avoir collecté cette décharge partielle, elle sera récupérée si possible et le système continuera à fonctionner. Je ne me souviens pas beaucoup des fonctionnalités qui correspondent à de tels vidages partiels dans le noyau Linux.

(Qu'il suffise de dire que le plus proche est Linux kdump, mais le but initial de kdump est de collecter un vidage mémoire de l'ensemble du système, pas un vidage partiel, et il est supposé qu'il sera redémarré. )

2. Notification d'anomalie au composant utilisant la fonction

Les programmes utilisant la fonctionnalité du composant concerné doivent être informés que l'erreur s'est produite. Comme mentionné ci-dessus, le châssis principal est conçu pour que le système continue à fonctionner autant que possible, donc si vous ne le faites pas __ "Le système fonctionne normalement" mais "Nécessaire pour les affaires" Seul le composant était mort "__, qui est la pire mort. Si cela se produit, le traitement de récupération nécessaire ne fonctionnera pas, ce qui entraînera des problèmes majeurs affectant l'ensemble du système d'entreprise. Pour cette raison, il est nécessaire de définir un code de retour indiquant qu'une erreur s'est produite pour toutes les tâches en veille en attente de la fin du traitement du composant, puis de réactiver cette tâche.

Dans le noyau Linux, lorsqu'une erreur de mémoire se produit, la suppression du processus est l'opération la plus proche si le processus utilise la zone. Cependant, en cas d'erreur PCIe, il n'est pas possible de le faire, et il n'est possible de l'enregistrer que dans le journal. (Cependant, je pense que c'est parce que les E / S sont abstraites en plusieurs étapes du cache de page à la couche de pilote dans le noyau sous Linux, et qu'il n'est pas possible de déterminer quelle E / S est associée à quel processus. La couche d'E / S de l'image principale est relativement simple, par exemple ne pas avoir de couche de mise en cache comme le cache de page.)

3. Réparez les pointeurs dans les composants si possible

Je ne peux pas entrer trop dans les détails ici, mais je me souviens que le pilote que j'ai écrit a réparé autant que possible des pointeurs tels que des listes de liens à l'intérieur des composants. Je ne me souviens d'aucun pilote Linux qui fasse la même chose. Fondamentalement, la position de base du noyau Linux est de paniquer lorsque cela se produit.

4. Retour des ressources utilisées

Les ressources utilisées doivent être restituées même en cas d'anomalie. Par exemple, si vous ne renvoyez pas la mémoire utilisée, une fuite de mémoire peut se produire et la mémoire système peut s'épuiser plus tard. De plus, si l'ensemble du système est toujours en possession d'un verrou, le système se bloquera ultérieurement pour tenter de récupérer le verrou. De cette manière, il est important de renvoyer les ressources contenues dans la routine de traitement des erreurs. Les ressources doivent être retournées de manière appropriée afin de maintenir le système en marche le plus longtemps possible.

5. Si la réparation n'est pas possible, configurez pour renvoyer une erreur lorsque la fonction est appelée à nouveau.

Détachez le composant du système pour éviter qu'il ne soit utilisé dans un état anormal. Assurez-vous que le code de retour d'erreur est renvoyé lorsque le composant est appelé.

Culture du cadre principal

En parlant de culture, je voudrais raconter une petite histoire ancienne. Les mots signalés par mes aînés dans la revue de bureau du code source pour une certaine fonction du cadre principal n'ont jamais été oubliés par moi. C'est parce que le mot semble indiquer une partie de la culture mainframe.

Senior: "Quand je regarde la source convertie en assembleur, que se passe-t-il si une vérification de la machine se produit entre cette instruction et l'instruction suivante (en raison d'une panne matérielle)?" JE:"????" Senior: "(Parce que le gestionnaire FRR n'a pas encore été enregistré) Le verrou ne peut pas être retourné et le système se bloque? __ C'est un bug alors corrigeons-le! __"

Je pense que les lignes que mes seniors ont prises pour acquises montrent comment les développeurs de systèmes mainframe travaillaient à une gestion anormale.

Il est imprévisible où une panne matérielle se produira lors de l'exécution du logiciel. Il n'est donc pas logique de considérer ce qui précède à un seul endroit du code que j'ai examiné. Presque tout le code source de haut en bas n'a pas de sens en tant que point à moins que de telles anomalies matérielles ne soient prises en compte. Je pense que la vraie génialité de la fiabilité de la trame principale est que nous l'avons implémentée avec l'attitude que même un traitement aussi anormal au moment d'une panne matérielle n'arrête pas le système, et nous avons continué à le faire.

De plus, je me souviens que le ratio du code de traitement anormal dans le code source total était très important car le traitement anormal était mis en œuvre au maximum de cette manière. Je suis désolé pour le sentiment personnel que n = 1, mais j'estime que le traitement normal et le traitement anormal de l'image principale ont été implémentés intuitivement dans un rapport d'environ 3: 7. Je pense qu'il a été mis en œuvre avec beaucoup d'efforts dans le traitement des anomalies. (Si vous voulez le même ratio, est-ce que le noyau Linux est d'environ 5: 5? Si vous êtes intéressé, veuillez calculer.)

Vue critique

Jusqu'à présent, nous avons expliqué ce qu'il faut faire lorsque la trame principale est anormale, mais enfin, expliquons la vue critique. Certains d'entre vous se sont peut-être sentis mal à l'aise après avoir lu les explications jusqu'à présent, et j'ai entendu de nombreux avis sceptiques ou critiques depuis que j'étais dans la division mainframe. Croire au cadre principal n'est pas une attitude saine. Au contraire, je pense que nier complètement le cadre principal n'est pas la bonne forme pour l'ingénierie.

Il est également important d'être conscient de votre scepticisme sur le mainframe afin de pouvoir analyser sereinement les avantages et les inconvénients des architectures modernes, y compris le mainframe et le cloud, et sélectionner la bonne technologie. Faisons le.

"En premier lieu, est-ce que le traitement anormal au moment de la panne matérielle fonctionne?"

Comme il n'y a pas de données à portée de main, ce sera une histoire qualitative, mais lorsque le processus de récupération fonctionne bien en cas de panne du processeur, même la trame principale ne peut pas être récupérée comme prévu. Il semble y en avoir pas mal. Après tout, les pannes matérielles sont souvent Pulpunte qui ne savent pas ce qui va se passer, et il semble qu'il soit difficile de bien effectuer le traitement de récupération, même avec le cadre principal qui le fait si dur. Pour cette raison, est-il logique de travailler dur sur le processus de récupération jusqu'à présent? Il y a aussi l'idée.

Personnellement, même si cela ne fonctionne pas idéalement, il n’est pas surprenant que je puisse dire fièrement: «Le logiciel a été conçu pour récupérer jusqu’à présent», mais la technologie Les avis seront partagés sur la question de savoir si cela a du sens ou non.

(Ajouté le 2020/5/3 20:00) J'ai reçu un commentaire sur Facebook. J'ai reçu l'autorisation, je vais donc l'ajouter ici également.

La question est: "Le traitement anormal au moment de la panne matérielle fonctionne-t-il en premier lieu?" ・ Plutôt que d '"éviter les pannes matérielles", pensez à "laisser des informations pour rendre" explicable "la situation de problèmes pendant le fonctionnement. " ・ "Parce qu'il est essentiel d'être responsable dans le monde professionnel." ・ "Tout d'abord, reconnaissez que le meilleur effort n'est pas autorisé." ・ "Par conséquent, les liens de tâches sont également triplés, et les transitions d'état passées et les facteurs qui ont provoqué les transitions sont laissés." ・ "Pour cela, il est nécessaire d'éviter les pannes matérielles et de laisser des informations." A été enseigné. Pour ton information.

"Est-il crédible de récupérer sur un système qui prétend être anormal?"

Le rapport d'anomalie est-il digne de confiance en premier lieu? Il y a une opinion. Plutôt que de faire confiance à l'histoire de quelqu'un qui prétend être "je suis fou" du patron du département suivant à l'époque, il est plus correct de faire récupérer une autre personne normale? Par conséquent, il est étrange que le système à l'origine de l'anomalie se rétablisse de lui-même avec ESTAE ou FRR. Le processus de récupération doit être effectué à partir d'un autre nœud. " Ce n'est pas vraiment une fausse opinion, et en fait certains systèmes visent à succéder au mainframe ainsi conçu.

Bien entendu, la récupération par d'autres systèmes soulève un autre problème. Je ne vais pas beaucoup parler de la difficulté de la récupération avec le clustering ou les systèmes distribués, car les lecteurs de cela peuvent être plus familiers avec cela, mais il ne semble pas y avoir de solution absolue. Après tout, "jusqu'où et comment effectuer le traitement de récupération en cas d'anomalie?" Peut être le seul moyen de comparer les coûts et effets techniques et monétaires et d'adopter celui qui convient. ne pas.

Résumé

Décrit le concept et le contenu du traitement anormal de la trame principale. J'ai également ajouté autant que je peux écrire sur ce que Linux fait pour cela. J'espère que cela sera utile au lecteur.

Les références

["Fonction et structure de MVS" Modern Science Co., Ltd. (Impress) ISBN-13: 978-4844372899](https://www.amazon.co.jp/%EF%BC%ADVS%E3%81%AE%E6% A9% 9F% E8% 83% BD% E3% 81% A8% E6% A7% 8B% E9% 80% A0-% E5% 8D% 83% E7% 94% B0-% E6% AD% A3% E5% BD% A6 / dp / 4844372890)

[LINUX] Gestion des erreurs de trame principale