Comment convertir les tâches cron Linux en mode "Amazonien"?
Pour le meilleur ou pour le pire, nous avons migré la totalité de notre LAMPE application Web à partir de machines dédiées vers le cloud (machines Amazon EC2). Cela va très bien jusqu'à présent, mais la façon dont nous procédons (crons } _ est sous-optimale. J'ai une question spécifique à Amazon sur la meilleure façon de gérer les tâches cron dans le nuage en utilisant "la méthode Amazon".
Le problème: Nous avons plusieurs serveurs Web et nous devons exécuter des tâches périodiques telles que la création de flux RSS, le déclenchement d'e-mails, etc. MAIS les tâches cron ne doivent être exécutées que sur une machine car elles écrivent souvent dans la base de données et dupliquent les résultats si elles sont exécutées sur plusieurs machines.
Jusqu'à présent, nous avons désigné l'un des serveurs Web comme "serveur Web principal" et il a quelques tâches "spéciales" que les autres serveurs Web n'ont pas. Le compromis pour l'informatique en nuage est la fiabilité - nous ne voulons pas d'un "serveur web maître", car c'est un point de défaillance unique. Nous voulons qu’ils soient tous identiques et qu’ils puissent passer à l’échelle supérieure et supérieure sans oublier de ne pas supprimer le serveur Web maître du cluster.
Comment pouvons-nous repenser notre application pour convertir les travaux cron Linux en éléments de travail transitoires ne présentant pas un point de défaillance unique?
Mes idées jusqu'ici:
- Avoir une machine dédiée uniquement à l'exécution de crons. Ce serait un peu plus facile à gérer mais resterait un point de défaillance unique et gaspillerait de l'argent en ayant une instance supplémentaire.
- Certains travaux pourraient éventuellement être déplacés de Linux crons vers événements MySQL mais je ne suis pas un grand fan de cette idée car je ne souhaite pas intégrer la logique d'application dans la couche base de données.
- Nous pouvons peut-être exécuter tous les crons sur toutes les machines, mais modifier nos scripts cron afin qu'ils commencent tous avec un peu de logique qui implémente un mécanisme de verrouillage afin qu'un seul serveur passe réellement à l'action et que les autres sautent simplement. Je ne suis pas un partisan de cette idée car cela peut sembler un buggy et je préférerais utiliser les meilleures pratiques d'Amazon plutôt que de lancer la nôtre.
- J'imagine une situation où des tâches sont planifiées quelque part, ajoutées à une file d'attente, puis les serveurs Web pourraient être chacun un travailleur, ce qui peut dire "hé, je vais prendre celui-ci". (Amazon Simple Workflow Service) sonne exactement ce genre de chose, mais je ne connais pas grand chose à ce sujet à ce jour, il serait utile de vous fournir des précisions. Cela semble assez lourd pour quelque chose d'aussi simple qu'un cron? Est-ce le bon service ou existe-t-il un service Amazon plus adapté?
Mise à jour: Depuis que j'ai posé la question, j'ai regardé le webinaire Amazon Simple Workflow Service sur YouTube et l'ai remarqué à 34h40 ( http://www.youtube.com/watch?v = lBUQiek8Jqk # t = 34m40s ) J'ai aperçu une diapositive mentionnant les travaux cron comme exemple d'application. Dans leur page de documentation, " exemples AWS Flow Framework pour Amazon SWF }", Amazon dit qu'ils ont un exemple de code pour les crons:
... > Cron jobs Dans cet exemple, un flux de travail de longue durée est périodiquement exécute une activité. La possibilité de continuer les exécutions en tant que nouveau exécutions afin qu’une exécution puisse s’exécuter pendant de très longues périodes de le temps est démontré . ...
J'ai téléchargé AWS SDK for Java ( http://aws.Amazon.com/sdkforjava/ ) et, bien sûr, enfoui dans une couche de dossiers ridicules, il y a du code Java (aws-Java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow).
Le problème est que, si je suis honnête, cela n’aide pas vraiment car ce n’est pas quelque chose que je peux facilement digérer avec mes compétences. Le même échantillon est absent du kit de développement logiciel PHP et il ne semble pas exister de didacticiel décrivant le processus. Donc, fondamentalement, je cherche toujours des conseils ou des astuces.
Le 12/Feb/16, Amazon a publié un blog sur Planification de travaux SSH à l'aide de AWS Lambda . Je pense que cela répond à la question.
Je me suis inscrit au support Amazon Gold pour leur poser cette question, voici leur réponse:
À M
J'ai fait un rapide sondage auprès de certains de mes collègues et suis arrivé vide sur le cron, mais après avoir dormi dessus, j’ai réalisé que l’étape importante était peut-être limité au verrouillage. J'ai donc cherché "le verrouillage du travail cron distribué" et trouvé une référence à Zookeeper, un projet Apache.
http://zookeeper.Apache.org/doc/r3.2.2/recipes.html
J'ai également vu des références à l'utilisation de memcached ou d'une mise en cache similaire mécanisme comme un moyen de créer des verrous avec un TTL. De cette façon, vous définissez un flag, avec un TTL de 300 secondes et aucun autre opérateur cron ne s’exécutera le travail. Le verrou sera automatiquement relâché après que TTL ait expiré. Ceci est très similaire sur le plan conceptuel à l’option SQS que nous avons discuté hier.
Regarde aussi; Google est grassouillet http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf
Faites-moi savoir si cela aide, et n'hésitez pas à poser des questions, nous sommes très conscients que nos services peuvent être complexes et décourageants pour les deux débutants et les développeurs chevronnés. Nous sommes toujours heureux d'offrir conseils en architecture et bonnes pratiques.
Meilleures salutations,
Ronan G. Services Web Amazon
Je pense que cette vidéo répond à votre question exacte - cronjobs à la façon des aws (évolutive et tolérante aux fautes):
Utilisation de Cron dans le cloud avec Amazon Simple Workflow
La vidéo décrit le service SWF à l'aide du cas d'utilisation spécifique consistant à implémenter des tâches cron.
La complexité relative de la solution peut être difficile à avaler si vous venez directement d'une crontab. À la fin, une étude de cas m'a aidé à comprendre ce que cette complexité supplémentaire vous apporte. Je vous suggère de regarder l’étude de cas et de prendre en compte vos besoins en matière d’évolutivité et de tolérance aux pannes pour décider si vous devez migrer depuis votre solution crontab existante.
Soyez prudent avec SQS pour les tâches cron, car elles ne garantissent pas qu’un seul travail est vu par une seule machine. Ils garantissent que "au moins un" aura reçu le message.
De: http://aws.Amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message
Q: Combien de fois vais-je recevoir chaque message?
Amazon SQS est conçu pour fournir «au moins une fois» la livraison de tous les messages dans ses files d'attente. Bien que la plupart du temps chaque message soit remis à votre application exactement une fois, vous devez concevoir votre système de manière à ce que le traitement d'un message plusieurs fois ne crée aucune erreur ni incohérence.
Jusqu'à présent, je peux penser à la solution pour laquelle vous avez une instance avec l'instance Gearman Job Server installée: http://gearman.org/ . Sur le même ordinateur, vous configurez des tâches cron en production qui exécutent votre tâche cronjob en arrière-plan. Ensuite, l’un de vos serveurs Web (ouvriers) commencera à exécuter cette tâche, il en garantit qu’un seul l’y prendra. Peu importe le nombre de travailleurs que vous avez (surtout lorsque vous utilisez la mise à l'échelle automatique).
Les problèmes avec cette solution sont:
- Le serveur Gearman est un point d’échec unique, sauf si vous le configurez avec un stockage distribué, par exemple en utilisant memcached ou une base de données.
- Ensuite, en utilisant plusieurs serveurs Gearman, vous devez en sélectionner un qui crée une tâche via cronjob. Nous retrouvons donc le même problème. Mais si vous pouvez vivre avec ce type de point de défaillance unique, utiliser Gearman semble être une très bonne solution. Surtout que vous n'avez pas besoin d'une grande instance pour cela (une micro-instance suffit dans notre cas).
Amazon vient de publier nouvelles fonctionnalités pour Elastic Beanstalk. De la docs :
AWS Elastic Beanstalk prend en charge des tâches périodiques pour l'environnement de travail.
niveaux dans des environnements exécutant une configuration prédéfinie avec une pile de solution contenant "v1.2.0" dans le nom du conteneur. "
Vous pouvez maintenant créer un environnement contenant un fichier cron.yaml qui configure les tâches de planification:
version: 1
cron:
- name: "backup-job" # required - unique across all entries in this file
url: "/backup" # required - does not need to be unique
schedule: "0 */12 * * *" # required - does not need to be unique
- name: "audit"
url: "/audit"
schedule: "0 23 * * *"
J'imagine que l'assurance de l'exécuter une seule fois dans un environnement échelonné automatiquement est utilisée via la file d'attente de messages (SQS). Lorsque le démon cron déclenche un événement, il place cet appel dans la file d'attente SQS et le message dans la file d'attente n'est évalué qu'une fois. La documentation indique que l'exécution peut être retardée si SQS doit traiter beaucoup de messages.
Je suis tombé sur cette question pour la troisième fois maintenant et je pensais participer. Nous avons ce dilemme depuis un moment maintenant. Je pense toujours vraiment que AWS manque une fonctionnalité ici.
Dans notre cas, après avoir examiné les solutions possibles, nous avons décidé de choisir deux options:
- Configurez un serveur cronjob qui exécute les travaux qui ne doivent être exécutés qu'une fois à la fois, redimensionnez-le automatiquement et assurez-vous qu'il est remplacé lorsque certaines statistiques CloudWatch ne sont pas ce qu'elles devraient être. Nous utilisons des scripts
cloud-initpour faire fonctionner les tâches cron. Bien sûr, cela vient avec un temps d'arrêt, ce qui entraîne des tâches manquées (lors de l'exécution de certaines tâches à la minute, comme nous le faisons). - Utilisez la logique que
rcronutilise. Bien sûr, la magie n’est pas vraiment dansrcron, mais dans la logique que vous utilisez pour détecter un nœud défaillant (nous utilisonskeepalivedici) et "mettre à niveau" un autre nœud à maîtriser.
Nous avons décidé d’utiliser la deuxième option, tout simplement parce que c’est extrêmement rapide et que nous avions déjà de l’expérience avec les serveurs Web exécutant ces tâches cron (à l’époque antérieure à AWS).
Bien entendu, cette solution est spécifiquement destinée à remplacer l’approche traditionnelle à un nœud avec cronjob, où le facteur décisif est le choix du temps (par exemple, "Je veux que le travail A soit exécuté une fois par jour à 5 heures du matin"case "Je veux que le travail B soit exécuté une fois par minute"). Si vous utilisez cronjobs pour déclencher une logique de traitement par lots, vous devez vraiment jeter un oeil à SQS. Il n'y a pas de dilemme actif-passif, ce qui signifie que vous pouvez utiliser un seul serveur ou des effectifs entiers pour traiter votre file d'attente. Je suggèrerais également de regarder SWF pour augmenter votre effectif (bien que auto scaling puisse également faire l'affaire dans la plupart des cas).
Nous voulions éviter de dépendre d’un tiers.
La méthode "Amazon" doit être distribuée, ce qui signifie que les tâches volumineuses doivent être scindées en de nombreux travaux plus petits et confiées aux bonnes machines. L'utilisation de SQS pour le coller ensemble garantit que chaque tâche est vue par une seule machine. Il tolère également les échecs, car les files d'attente sont mises en mémoire tampon jusqu'à ce qu'une machine effectue une sauvegarde en rotation.
Déterminez également si vous avez vraiment besoin de «grouper» ces opérations. Que se passe-t-il si les mises à jour d'une nuit sont considérablement plus volumineuses que prévu? Même avec des ressources dynamiques, votre traitement peut être retardé en attendant que suffisamment de machines tournent. Stockez plutôt vos données dans SDB, informez les machines des mises à jour via SQS et créez votre flux RSS à la volée (avec mise en cache).
Les travaux par lots datent d'une époque où les ressources de traitement étaient limitées et où les services «en direct» priment. Dans le cloud, ce n'est pas le cas.
Si vous avez déjà un service Redis en place, cela semble être une bonne solution:
https://github.com/kvz/cronlock
En savoir plus: http://kvz.io/blog/2012/12/31/lock-your-cronjobs/
Pourquoi voudriez-vous construire le vôtre? Pourquoi ne pas utiliser quelque chose comme Quartz (avec la planification en cluster). Voir la documentation.
http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering
Ce que nous faisons, c’est que nous avons un serveur particulier faisant partie de notre cluster d’applications Web derrière un ELB, auquel un nom DNS spécifique a également été attribué afin que nous puissions exécuter les travaux sur ce serveur spécifique. Cela présente également l'avantage que si ce travail ralentit le serveur, le ELB le supprimera du cluster, puis le renverra une fois le travail terminé et qu'il sera à nouveau en bonne santé.
Fonctionne comme un champion.
Si vous souhaitez utiliser un service non-AWS, vous pouvez extraire Microsoft Azure . Azure offre un excellent planificateur de travaux .
Puisque personne n'a mentionné CloudWatch Event , je dirais que c'est la manière AWS de faire les tâches cron. Il peut exécuter de nombreuses actions, telles que fonction Lambda, tâche ECS.