Présentation
Je travaille dans une entreprise où nous courons le traitement batch de nombreux millions d'enregistrements de données chaque jour et j'ai pensé récemment à propos de toutes les machines qui sont assis autour de chaque et tous les jours à ne rien faire pendant plusieurs heures. Ce ne serait pas bien si on pouvait utiliser ces machines pour renforcer la puissance de traitement de nos systèmes? Dans cette série d'articles que je vais regarder les avantages potentiels d'employer un bureau de grille en utilisant les environnements virtualisés.
Dans la partie 1 que j'ai donné un aperçu du système et des technologies, je vais utiliser aussi bien comme nous le verrons quelques-unes des raisons potentielles pour lesquelles vous voulez créer une grille de bureau.
Job Control
Si vous allez faire tourner les emplois, alors vous allez avoir besoin d'une certaine façon de les gérer. Votre système de contrôle du travail (sur votre serveur de travail) doit être vraiment bien pensé, avant même de tenter d'exécuter une grille de bureau. Donc premièrement, quelles sont les tâches d'un système de contrôle des tâches:
- Emplois sur la main sur demande auprès de travailleurs
- Dites travailleurs quel type d'emplois à courir
- Emplois piste
- Assurez-vous que les emplois ne sont exécutées une fois
- Fournir des données d'emplois pour les travailleurs, ou tout au moins leur dire où se le procurer
Le système doit également être extensible, une solution qui fonctionne pour l'instant dans un seul cas peut être prolongée d'exécuter plusieurs types d'emplois que l'entreprise voit la valeur dans une solution de la grille. Par exemple, les emplois peuvent gagner des priorités, plus d'un type d'emploi peuvent exister (c'est à dire de plusieurs bases de code), vous finirez peut même exécuter plusieurs machines différentes des travailleurs qui sont optimisés pour chaque type d'emploi (bien que cela s'éloigner de l'ouvrier «génériques 'idée). Toujours essayer de penser à l'avenir lors de l'élaboration des systèmes, une vision à court terme peut conduire à la frustration à long terme et le temps de développement accru.
Job Server
Nous allons avoir besoin de quelque part pour contrôler nos offres d'emploi de ce devrait être le seul système dans votre grille qui a une ressource fixe localisateur, que ce soit une adresse IP, nom d'hôte, URL (en utilisant le DNS interne), etc C'est parce que les travailleurs ont besoin de savoir où chercher un emploi, les travailleurs ont besoin de trouver le système de contrôle du travail (et non le système de contrôle d'emploi à trouver des travailleurs).
Le serveur poste lui-même n'a pas vraiment une tâche compliquée (dans un système de base de toute façon), il a besoin de stocker une liste d'emplois, la main sur l'emploi, de recevoir les résultats, et ensuite les stocker pour une utilisation ultérieure. Comment ces pièces (comme «la main sur des emplois») sont définis peuvent être très basiques. Plus tard, nous pouvons étendre le système pour inclure une interface d'administration pour ajouter, modifier, supprimer, suspendre emplois, mais c'est au-delà de cet exercice.
Il n'y a aucune raison que ce soit alors que votre serveur de travail ne pouvait pas être une machine virtuelle fonctionnant au sein de votre serveur de traitement principal à condition qu'il ne s'écoule pas trop de ressources d'elle. Le serveur d'emploi ne doivent toutefois une haute disponibilité, si elle descend sur un vendredi soir, vous allez perdre tout un week end de traitement, potentiellement vous coûter une couple de semaines de temps de traitement (par rapport à votre serveur de traitement principal seul) . Vous voudrez peut-être envisager de mettre votre serveur d'emplois sur un environnement à charge équilibrée pour une haute disponibilité.
Configuration de base
La configuration de base pour notre serveur d'emplois sera composée de ce que j'appelle un de mes serveurs LIMP (c'est-nux Li, m ySql, P HP). Le code s'exécutant sur les travailleurs thea fonctionnera réellement quels emplois il peut fonctionner en interaction avec des bases de données d'emplois de contrôle du système. Plus tard, nous pourrions créer un service web et fait distribuer des emplois plutôt que d'avoir des ouvriers faire le dur travail eux-mêmes, mais pour l'instant nous allons continuer à utiliser le principe KISS (Keep It Simple, Stupid!).
Alors, laisse créer trois mySQL tables pour faire face à l'emploi. Ces emplois seront ``, `jobRecords` et `jobResults`.
Ici, je suis en utilisant SQL amis une excellente alternative peu de phpMyAdmin juste parce que c'est plus facile à installer sur CentOS (pour les autres voir: 10 alternatives aux phpMyAdmin )
Ce tableau se compose de 5 champs simples,
- Identifiant: Conçus pour identifier l'emploi
- Nom: Pourrait être une référence client, ou n'importe quel nombre d'autres identificateurs
- Statut: Vous avez besoin de savoir où le travail est moins, par exemple
- 0: Pas encore commencé
- 1: Ramassé
- 2: Terminé
- started_by: Qui a commencé à faire le travail? Ce n'est pas entièrement nécessaire, mais est une agréable d'avoir. Je vous suggère de suivi des travailleurs par leur adresse IP sur votre réseau
- started_at: Lorsque le travailleur ne commence le travail? En faisant le suivi des emplois qui n'ont pas terminé dans le montant X de temps, nous savons que nous devons ramasser les emplois une fois de plus et de commencer le traitement par un autre travailleur. Les travailleurs pourraient arrêter le traitement / go offline pour toutes sortes de raisons, une panne de courant, crash, perte de réseau, etc
Il est facile comment ce tableau pourrait être étendue avec quelques champs supplémentaires pour permettre le suivi des statistiques, une colonne de temps d'arrivée pour voir combien de temps le travail a pris, un compteur pour voir combien de travailleurs repris le travail (évidemment cela doit tendance à 1), priorité d'emploi, la liste peut continuer encore et encore. Dans les scénarios d'emplois plus complexes, il serait possible de spécifier la quantité de mémoire que le travailleur aurait besoin d'accéder à (et donc utiliser uniquement des travailleurs qui conviennent), ou même ce type de travailleurs serait nécessaire.
Permet d'ajouter un peu d'emplois par exemple:
Le tableau suivant est encore assez simple à comprendre, ce sont nos dossiers d'emploi. Elles sont liées à la table principale d'emplois par une colonne `jobs_id`. La composition de ce tableau dépend beaucoup des données que vous devez fournir à vos employés, permet de faire un exemple très simple où nous avons quatre colonnes:
- ID: ID de l'enregistrement
- Nom: Nom de la personne
- Adresse: adresse personne
- jobs_id: L'ID d'emplois que ce record est lié à
Le troisième et dernier tableau se compose d'une table de résultats, il a sensiblement la même représenter jusqu'à notre table les dossiers, et avec l'ajout de certaines colonnes pourrait faire partie de la table des dossiers:
- job_record_id: Link le résultat à la table de travail
- Résultat: Les données de résultat
... Et c'est tout ce dont vous avez besoin pour le contrôle de boulot! (Quoique à un niveau très basique) Dans mon cas, je suis a souligné une autre table où mes données à traiter a été localisé, mais cela pourrait tout aussi bien pu un fichier, les paramètres d'exécuter du code de simulation, you name it.
Sélection d'un emploi
Comme indiqué précédemment, les travailleurs ferons de notre gestion du travail pour nous pour l'instant, donc tout ce que nous devons vraiment faire, c'est de trouver un emploi qui nécessite un traitement et obtenir l'information. Comment ferions-nous cela? Eh bien choisir nos critères de sélection d'emploi et chercher un emploi, dans SQL, je ne les suivantes:
- Prenez n'importe quel emploi qui ne sont pas marquées comme terminées, mais de nos travailleurs et les réinitialiser (substitut __ME__ avec un identifiant plus simple, serait d'adresse IP):
UPDATE `emplois` SET `status` = 0 WHERE `status` = 1 et `started_by` = __ME__;
- En utilisant nos critères de sélection des tâches, sélectionnez un emploi et dire au système de contrôle que ce travailleur a affaire avec elle:
UPDATE `emplois` SET `status` = 1, `started_by` = __ME__, `started_at` = MAINTENANT () WHERE `status` = 0 ou
(`Status` = 1 et `started_at`> DATE_SUB (NOW (), heures d'intervalle X)) ORDER BY `id` ASC;
En récupérant des emplois qui ne sont pas retournés en résulte une quantité X de temps nous nous assurons que tous les emplois sont gérés dans le cas d'un travailleur ou d'aller s'écraser AWOL.
- Suivant récupérer les détails d'emplois suivis par les documents eux-mêmes:
SELECT * FROM `emplois` WHERE `started_by` = __ME__ LIMIT 1;
SELECT * FROM `job_records` WHERE `id` = __JOBID__;
À la fin de l'emploi, nous insérons nos dossiers résultat et indiquer que le travail le plus complet. N'oubliez pas que les emplois peuvent suspendre / reprendre à tout moment permettre une certaine robustesse dans votre script. Il se pourrait que la tâche suspend mi-chemin de la modernisation du système de contrôle du travail, donc vérifier le nombre d'enregistrements dans un emploi et le nombre de résultats enregistrées sur le système de contrôle du travail serait une sage décision.
De plus, tout cela démontre comment les emplois peuvent être sélectionnés et gérés à partir d'un cadre de requête SQL, vous devriez vraiment être abstraction de votre volonté d'emplois de sorte que si vous décidez de passer à l'aide d'un service Web, un système de fichiers basé, XML , ou tout autre nombre de systèmes de cela n'affectera pas le code au-dessus.
Configuration d'emploi
Le prochain aspect à considérer est la taille d'emploi et de configuration. En jouant avec la configuration de travail que nous pouvons trouver un excellent équilibre entre la vitesse, la réplication de processus et de fiabilité. Prenez un des scénarios OFA couple:
- Emplois de prendre un jour de chaque lancer: Cela signifie que vos employés ont besoin de 15 jours pour traiter chaque tâche (souvenez-vous de 10% de la puissance pour 2/3rds de l'époque). Ce n'est clairement pas un sage de configuration, la taille de votre travail est beaucoup trop grand! Il faudrait au moins doubler le temps d'obtenir un emploi traitées si le travailleur initiales vont AWOL (le temps de ramasser ce qu'il n'a pas retourné un résultat plus le temps de retraitement). Dans l'idéal, vous auriez au moins un emploi à plein facilement dégagé par la fin de chaque longue période d'inactivité, de cette façon vous conserver les emplois et à retardement sur le pire des cas un travail prendrait deux jours pour le premier processus devrait vont manquer.
- Emplois prendre 1 minute pour lancer: Cela signifie que vos employés prennent environ 15 minutes pour effectuer chaque tâche. Bien que cela puisse paraître initialement idéal, vous gagnez le traitement du travail supplémentaire pendant l'heure du déjeuner, les pauses café, réunions, etc ce scénario met une pression sur d'autres domaines de votre système et introduit ses propres problèmes. Par exemple, tout d'abord votre ratio temps d'installation / de traitement va aller droit vers le bas, donc de perdre l'efficacité du système. Votre réseau va être en permanence en continu des informations d'emplois pour le personnel de divers travailleurs qui sont frustrantes dong de leur travail quotidien. Vous allez aussi de mettre plus de pression sur votre serveur de traitement d'emplois comme il l'a à plat sur des tas de petits morceaux de travailler sur une base régulière. Enfin, dans cette situation si votre serveur tombe en panne d'emplois que vous allez créer un journal de retour énorme de travail inachevé alors plus d'emplois pourraient poursuite de la procédure parfaitement inconscients que le serveur de travail connaît des difficultés.
En réalité, il n'y aura pas de configuration idéale pour une configuration de votre réseau, beaucoup dépend des ressources disponibles, les types d'exigences métier, les délais, la capacité du réseau, et ainsi de suite. Toutefois, certaines lignes directrices seraient:
- Taille d'emplois afin que chaque travailleur peut obtenir à travers au moins 3-4 dans une emplois période de 15 heures (la plus longue période probable temps d'inactivité)
- Jouer avec la taille du travail afin que les temps d'installation devient assez insignifiant par rapport au temps de traitement (en gardant à l'esprit le point ci-dessus).
- Si un travail ne se termine pas au double de la quantité de temps (peut-être moins) que vous attendez qu'elle soit terminée il supposer que son parti AWOL et commencer le traitement avec un autre travailleur. Cela signifie que vous pourriez avoir à attendre jusqu'à trois fois la durée normale d'un emploi qu'elle se termine (peut-être plus si le travail ultérieur échoue). Vous pouvez réduire ce temps, mais attention à ne pas le réduire trop car vous pouvez commencer à dupliquer les tâches de traitement sur une base régulière.
- Jobs devrait être indépendant des exigences de l'extérieur autant que possible. Le serveur d'emplois, par exemple, ne devraient être contactés au début et à la fin de chaque travail.
- Ne pas saturer votre réseau, ce qui a deux effets négatifs, vos collaborateurs pendant la journée se trouve en utilisant le réseau de frustration et de problèmes peuvent être expérimentés avec des connexions moment sur un problème qui ne fera que s'aggraver à mesure que vous réduisez votre grille.
- Assurer des emplois peut fonctionner sur vos travailleurs. Si les emplois deviennent trop de mémoire emplois d'espace disque intensive ou intensive commencera avorter et la seule chose que vous remarquerez est une baisse du nombre de tâches traitées sans véritable raison.
Résultats Soumission d'un job
Lors de la soumission des résultats d'un travail, il est important de vérifier que les résultats n'ont pas été soumis par un autre travailleur, surtout si le travailleur actuelle est inactif depuis un certain temps.
Lorsque les résultats sont soumis s'assurer que le nombre de résultats correspondant au nombre d'enregistrements dans le travail.
Comme indiqué précédemment, et ne peut pas être surestimée, de construire la tolérance de panne dans la récupération d'emplois et la soumission des résultats. Les travailleurs peuvent (et très probablement) passer en mode suspend à la plus dérangeante des temps et cela doit être pris en compte. Aussi une fois de s'abstraire de votre soumission résultats aideront répondre aux futurs changements à votre système de contrôle du travail beaucoup plus facile à traiter.
Résumé
Dans cette Section A, nous avons regardé ce que un serveur de contrôle d'emplois doit faire et comment obtenir un système de base mis en place. Nous avons discuté de la façon de récupérer un travail à partir du système de contrôle et de la meilleure façon de configurer des travaux pour obtenir le maximum de votre système de quadrillage de bureau. Pour finir, un paragraphe ou deux sur la présentation des résultats vers le serveur de contrôle des travaux a été présenté.
- Un serveur de contrôle de tâche gère les emplois et garantit que toutes les unités de travail sont terminées
- En faisant abstraction de sélectionner votre travail / résultats de soumission que nous pouvons changer la technologie du serveur de contrôle, sans beaucoup de problèmes
- Configurez votre emploi afin de s'assurer qu'ils sont gérés rapidement et efficacement sans mettre trop de pression sur votre infrastructure réseau, et sans duplication des tâches de traitement sur une base régulière.
- Assurez-vous que vous construisez une tolérance aux pannes et de checking erreur dans vos routines, les travailleurs peuvent suspendre et reprendre et le plus incommode de fois. N'oubliez pas de vérifier si les résultats ont déjà été soumis par un autre travailleur.
Suivant le temps
Dans la partie 3 , nous allons créer notre machine virtuelle de traitement et de mettre en place nos machines fenêtres de devenir inactif travailleurs à temps.
Commentaires (2) 
En fixant chacun de vos travailleurs comme un esclave pour les mises à jour d'emplois du contrôle serveur à vos sources de données sera retombée bien à vos travailleurs sans une énorme augmentation de l'activité du réseau (qui est moins que vous effectuez une mise à jour des données énormes et tous vos travailleurs coup de pied dans à la fois). Cela a des avantages sur rsync en ce que vous aurait pas une longue pause avant chaque emploi; que les mises à jour de bases de données, le mysql démon sur votre travailleur sera constamment mise à jour de ses données tandis que le traitement continue. 
Articles , Informatique , Grid Computing , Linux , PHP , Programmation Web | 
mise à jour 
