🤴🏾 👃🏾 💃🏿 À propos du cluster de serveurs 1C ⬅️ 🤷 🐈

Un cluster est un type de système parallèle
ou distribué qui:
1. se compose de plusieurs
ordinateurs interconnectés ;
2. Utilisé comme une
ressource informatique unique et unifiée

Gregory F. Pfister, «A la recherche de clusters».

Étant donné: il existe une application métier (par exemple, un système ERP) avec laquelle des milliers (voire des dizaines de milliers) d'utilisateurs travaillent simultanément.

C'est requis:

Rendre l'application évolutive, de sorte qu'avec une augmentation du nombre d'utilisateurs, il est possible en raison de l'augmentation des ressources matérielles de fournir les performances d'application nécessaires.
Rendre l'application résistante à la défaillance des composants du système (logiciels et matériels), à la perte de connexion entre les composants et à d'autres problèmes possibles.
Utilisez les ressources système aussi efficacement que possible et fournissez les performances d'application souhaitées.
Rendez le système facile à déployer et à administrer.

Pour résoudre ces problèmes, nous utilisons l'architecture de cluster dans la plateforme 1C: Enterprise.

Nous n'avons pas immédiatement atteint le résultat souhaité.

Dans cet article, nous parlerons du type de clusters, de la façon dont nous avons choisi le type de cluster qui nous convient et de l'évolution de notre cluster d'une version à l'autre, et des approches qui nous ont finalement permis de créer un système qui dessert des dizaines de milliers d' utilisateurs simultanés.

Comme Gregory Pfister, l'auteur de l'épigraphe de cet article, l'a écrit dans son livre "A la recherche de clusters", le cluster n'a pas été inventé par un fabricant particulier de matériel ou de logiciels, mais par des clients qui n'avaient pas la puissance d'un ordinateur ou qui avaient besoin de redondance. Cela s'est produit, selon Pfister, dans les années 60 du siècle dernier.
Distinguez traditionnellement les principaux types de grappes suivants:

Clusters de basculement (HA, clusters haute disponibilité)
Clusters d'équilibrage de charge (LBC)
Clusters de calcul (clusters de calcul haute performance, HPC)
(grid) , . grid- , . grid- HPC-, .

Pour résoudre nos problèmes (résistance à la défaillance des composants du système et utilisation efficace des ressources), nous devions combiner les fonctionnalités d'un cluster à sécurité intégrée et d'un cluster avec équilibrage de charge. Nous n'avons pas pris cette décision tout de suite, mais nous l'avons abordée de manière évolutive, étape par étape.

Pour ceux qui ne sont pas à jour, je vais vous expliquer brièvement comment sont organisées les applications métiers 1C. Ce sont des applications écrites dans un langage thématique , "affûté" pour l'automatisation des tâches métiers comptables. Pour exécuter des applications écrites dans cette langue, un runtime de plate-forme 1C: Enterprise doit être installé sur l'ordinateur.

1C: Enterprise 8.0

La première version du serveur d'applications 1C (pas encore un cluster) est apparue dans la version 8.0 de la plateforme. Avant cela, 1C fonctionnait dans la version client-serveur, les données étaient stockées dans un fichier SGBD ou MS SQL, et la logique métier fonctionnait exclusivement sur le client. Dans la version 8.0, une transition a été effectuée vers l'architecture à trois niveaux "client - serveur d'applications - SGBD".

Le serveur 1C dans la plate-forme 8.0 était COM +un serveur capable d'exécuter du code d'application en 1C. L'utilisation de COM + nous a fourni un transport prêt à l'emploi, permettant aux applications clientes de communiquer avec le serveur via le réseau. Beaucoup de choses dans l'architecture de l'interaction client-serveur et des objets d'application disponibles pour le développeur 1C ont été conçues en tenant compte de l'utilisation de COM +. À ce moment-là, la tolérance aux pannes n'était pas intégrée à l'architecture et une panne de serveur a entraîné l'arrêt de tous les clients. Lorsque l'application serveur s'est arrêtée, COM + l'a levée lorsque le premier client y a accédé, et les clients ont commencé leur travail depuis le début - depuis la connexion au serveur. À cette époque, tous les clients étaient servis par un seul processus.

1C: Enterprise 8.1

Dans la prochaine version, nous voulions:

Fournir une tolérance aux pannes à nos clients afin que les accidents et les erreurs de certains utilisateurs ne conduisent pas à des accidents et des erreurs d'autres utilisateurs.
Débarrassez-vous de la technologie COM +. COM + ne fonctionnait que sous Windows, et à cette époque la possibilité de travailler sous Linux devenait déjà pertinente.

Dans le même temps, nous ne voulions pas développer une nouvelle version de la plateforme à partir de zéro - elle serait trop gourmande en ressources. Nous voulions utiliser au maximum nos réalisations, ainsi que maintenir la compatibilité avec les applications développées pour la version 8.0.

Ainsi, dans la version 8.1, le premier cluster est apparu. Nous avons implémenté notre protocole d'appel de procédure à distance (en plus de TCP), qui en apparence ressemblait presque à COM + pour le client final (c'est-à-dire que nous n'avions pratiquement pas à réécrire le code responsable des appels client-serveur). Dans le même temps, nous avons rendu le serveur implémenté indépendant de la plateforme C ++, capable de fonctionner à la fois sur Windows et Linux.

La version 8.0 du serveur monolithique a été remplacée par 3 types de processus - un processus de travail qui sert les clients et 2 processus de service qui prennent en charge le fonctionnement du cluster:

rphost est un workflow au service des clients et exécutant du code d'application. Un cluster peut avoir plusieurs workflows, différents workflows peuvent être exécutés sur différents serveurs physiques - en raison de cette évolutivité.
ragent - un processus d'agent de serveur qui démarre tous les autres types de processus, ainsi qu'une première liste de clusters situés sur ce serveur.
rmngr est un gestionnaire de cluster qui contrôle le fonctionnement de l'ensemble du cluster (mais le code d'application ne fonctionne pas dessus).

Sous la coupe se trouve le diagramme de fonctionnement de ces trois processus dans le cluster.

Pendant la session, le client a travaillé avec un seul flux de travail, la baisse du flux de travail signifiait pour tous les clients que ce processus servait, la session s'est terminée de façon anormale. Les autres clients ont continué de travailler.

1C: Enterprise 8.2

Dans la version 8.2, nous voulions que les applications 1C puissent s'exécuter non seulement dans le client natif (exécutable), mais aussi dans le navigateur (sans modifier le code de l'application). À cet égard, en particulier, la tâche s'est posée de découpler l'état actuel de l'application de la connexion actuelle avec le flux de travail rphost et de le rendre sans état. En conséquence, le concept d'une session et de données de session est apparu qui devait être stocké en dehors du workflow (car il était sans état). Un service de données de session a été développé qui stocke et met en cache les informations de session. D'autres services sont également apparus - un service de verrous transactionnels gérés, un service de recherche en texte intégral, etc.

Cette version a également introduit plusieurs innovations importantes - une meilleure tolérance aux pannes, un équilibrage de charge et un mécanisme de redondance de cluster.

tolérance aux pannes

Étant donné que le processus de travail est devenu sans état et que toutes les données nécessaires au travail ont été stockées en dehors de la connexion client-flux de travail actuelle, en cas de panne de flux de travail, le client est passé à un autre flux de travail "en direct" la prochaine fois qu'il a accédé au serveur. Dans la plupart des cas, un tel commutateur était invisible pour le client.

Le mécanisme fonctionne comme ça. Si, pour une raison quelconque, l'appel du client au flux de travail n'a pas pu aboutir, la partie client est en mesure, après avoir reçu une erreur d'appel, de répéter cet appel en rétablissant la connexion au même flux de travail ou à un autre. Mais vous ne pouvez pas toujours répéter un appel; Répéter l'appel signifie que nous avons envoyé l'appel au serveur, mais que nous n'avons pas reçu le résultat. Nous essayons de répéter l'appel, tout en effectuant le deuxième appel, nous évaluons le résultat de l'appel précédent sur le serveur (les informations à ce sujet sont stockées sur le serveur dans les données de session), car si l'appel a eu le temps de «hériter» là (fermer la transaction, enregistrer les données de session etc.) - il est tout simplement impossible de le répéter, cela entraînera une incohérence des données. Si l'appel ne peut pas être répété, le client recevra un message concernant une erreur irrécupérable,et l'application cliente devra redémarrer. Si vous n'avez pas réussi à «hériter» de l'appel (et c'est la situation la plus courante, car de nombreux appels ne modifient pas les données, par exemple, les rapports, l'affichage des données sur un formulaire, etc., et ceux qui modifient les données n'ont pas de transaction ou jusqu'à ce qu'un changement des données de session ait été envoyé au gestionnaire - il n'y a aucune trace de l'appel) - il peut être répété sans risque d'incohérence des données. Si le flux de travail est tombé en panne ou si une connexion réseau a été interrompue, un tel appel est répété et ce «désastre» pour l'application client se produit complètement inaperçu.qui modifient les données - jusqu'à ce que la transaction soit validée ou jusqu'à ce que la modification des données de session soit envoyée au gestionnaire - il n'y a aucune trace de l'appel) - elle peut être répétée sans risque d'incohérence des données. Si le flux de travail est tombé en panne ou si une connexion réseau a été interrompue, un tel appel est répété et ce «désastre» pour l'application client se produit complètement inaperçu.qui modifient les données - jusqu'à ce que la transaction soit validée ou jusqu'à ce que la modification des données de session soit envoyée au gestionnaire - il n'y a aucune trace de l'appel) - elle peut être répétée sans risque d'incohérence des données. Si le flux de travail est tombé en panne ou si une connexion réseau a été interrompue, un tel appel est répété et ce «désastre» pour l'application client se produit complètement inaperçu.

L'équilibrage de charge

La tâche d'équilibrage de charge dans notre cas est la suivante: un nouveau client entre dans le système (ou un client déjà en fonction fait un autre appel). Nous devons choisir le serveur et le workflow auxquels envoyer l'appel du client afin de fournir au client une vitesse maximale.

Il s'agit d'une tâche standard pour un cluster à charge équilibrée. Il existe plusieurs algorithmes typiques pour le résoudre, par exemple:

Round-Robin () – , , – . . . . , «» . ( ) .
Weighted Round Robin – Round-Robin: , ́ .
Least Connections: , .
Least Response Time: : , .

Pour notre cluster, nous avons choisi un algorithme qui est essentiellement proche du temps de réponse le plus faible. Nous avons un mécanisme qui collecte des statistiques sur les performances des workflows sur tous les serveurs du cluster. Il effectue un appel de référence à chaque processus serveur du cluster; l'appel de référence implique un sous-ensemble des fonctions du sous-système de disque, de la mémoire, du processeur et évalue la rapidité avec laquelle un tel appel est effectué. Le résultat de ces mesures, moyenné au cours des 10 dernières minutes, est un critère - quel serveur du cluster est le plus productif et préféré pour lui envoyer des connexions client dans une période de temps donnée. Les demandes des clients sont réparties de manière à mieux charger le serveur le plus productif - chargez celui qui a de la chance.

La demande du nouveau client est adressée au serveur le plus productif du moment.

Une demande d'un client existant est dans la plupart des cas adressée à ce serveur et au workflow auquel sa demande précédente a été adressée. Un ensemble complet de données sur le serveur est associé à un client qui fonctionne; le transférer entre des processus (et plus encore entre des serveurs) est assez cher (bien que nous puissions le faire aussi).

Une demande d'un client existant est transférée vers un autre workflow dans deux cas:

Il n'y a plus de processus: le workflow avec lequel le client a précédemment interagi n'est plus disponible (le processus est tombé, le serveur est devenu indisponible, etc.).
: , , , , . , , – . – (.. ).

Nous avons décidé d'augmenter la résilience du cluster en recourant au schéma actif / passif . Il y avait une opportunité de configurer deux clusters - fonctionnant et réservant. Si le cluster principal n'est pas disponible (problèmes de réseau ou, par exemple, maintenance planifiée), les appels clients sont redirigés vers le cluster de sauvegarde.

Cependant, cette conception était assez difficile à configurer. L'administrateur a dû assembler manuellement deux groupes de serveurs en clusters et les configurer. Parfois, les administrateurs ont fait des erreurs en définissant des paramètres conflictuels, comme il n'y avait pas de mécanisme centralisé pour vérifier les paramètres. Mais, néanmoins, cette approche a augmenté la tolérance aux pannes du système.

1C: Enterprise 8.3

Dans la version 8.3, nous avons considérablement réécrit le code côté serveur responsable de la tolérance aux pannes. Nous avons décidé d'abandonner le schéma de cluster actif / passif en raison de la complexité de sa configuration. Un seul cluster tolérant aux pannes est resté dans le système, composé d'un nombre quelconque de serveurs - ce qui est plus proche du schéma actif / actif dans lequel les demandes pour un nœud défaillant sont réparties entre les nœuds de travail restants. Pour cette raison, le cluster est devenu plus facile à configurer. Un certain nombre d'opérations qui augmentent la tolérance aux pannes et améliorent l'équilibrage de charge sont devenues automatisées. Des innovations importantes:

« »: , , . , «» .
, , .
, , , , , :

L'idée principale de ces développements est de simplifier le travail de l'administrateur, lui permettant de configurer le cluster dans des termes qui lui sont familiers, au niveau du fonctionnement du serveur, sans descendre plus bas, et aussi de minimiser le niveau de «contrôle manuel» du travail du cluster, en donnant au cluster des mécanismes pour résoudre la plupart des tâches et problèmes possibles » sur le pilote automatique. "

Trois maillons de tolérance aux pannes

Comme vous le savez, même si les composants du système sont fiables séparément, des problèmes peuvent survenir lorsque les composants du système se causent mutuellement. Nous voulions minimiser le nombre de places critiques pour les performances du système. Une considération supplémentaire importante était la minimisation des altérations des mécanismes appliqués dans la plate-forme et l'exclusion des changements dans les solutions appliquées. Dans la version 8.3, il y avait 3 liens pour assurer la tolérance de panne «au niveau des joints»:

, HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
, .
- . 1, - . - . , . , – . - (, , , ) – .
, rmngr. 20 ( ) — , .. . 1: .

Grâce au mécanisme de tolérance aux pannes, les applications créées sur la plate-forme 1C: Enterprise survivent avec succès à divers types de défaillances des serveurs de production du cluster, tandis que la plupart des clients continuent de fonctionner sans redémarrer.

Il y a des situations où nous ne pouvons pas répéter l'appel, ou un crash de serveur attrape la plateforme à un moment très malheureux, par exemple, au milieu d'une transaction et il n'est pas très clair que faire avec eux. Nous essayons d'assurer une survie statistiquement satisfaisante des clients lorsque les serveurs tombent dans le cluster. En règle générale, la perte moyenne de clients en cas de défaillance du serveur est de quelques pour cent. Dans ce cas, tous les clients "perdus" peuvent continuer à fonctionner dans le cluster après le redémarrage de l'application cliente.

La fiabilité du cluster de serveurs 1C dans la version 8.3 a considérablement augmenté. Il n'est pas rare depuis longtemps d'introduire des produits 1C, où le nombre d'utilisateurs travaillant simultanément atteint plusieurs milliers. Il existe des implémentations dans lesquelles 5 000 et 10 000 utilisateurs travaillent simultanément - par exemple, l' introduction à Beeline , où l'application 1C: Trade Management dessert tous les points de vente Beeline en Russie, ou la mise en œuvre de Business Lines chez le transporteur de marchandises. , où l'application, créée de manière indépendante par les développeurs du département informatique des métiers sur la plateforme 1C: Enterprise, dessert le cycle complet du transport de marchandises. Nos tests de charge de cluster interne simulent le fonctionnement simultané de jusqu'à 20 000 utilisateurs.

En conclusion, je voudrais énumérer brièvement ce qui est utile dans notre cluster (la liste est incomplète):

, . , , .
– , , , ( – , ..) . , , (, ) , ERP, , ERP.
– , (, , ..). , , , , , .

À propos du cluster de serveurs 1C