Comment convertir les tâches cron Linux à « la voie de l’Amazonie » ?

Question

Pour le meilleur ou pour le pire, nous avons migré l'ensemble de notre LAMPE de l'application web à partir de machines spécifiques pour le cloud (Amazon EC2 machines). Il va très bien jusqu'à présent, mais la façon dont nous faisons des crons est sous-optimale, j'ai un Amazon spécifique à la question de savoir comment gérer au mieux les tâches cron dans le cloud à l'aide de "l'Amazone".

Le problème: Nous avons plusieurs serveurs web, et besoin pour exécuter crons pour les travaux en lots comme la création de flux RSS, déclenchant des e-mails, beaucoup de choses différentes en fait. MAIS les tâches cron besoin pour s'exécuter uniquement sur une machine parce qu'ils écrivent souvent à la base de données afin de dupliquer les résultats s'exécuter sur plusieurs machines. Jusqu'à présent, nous avons désigné l'un des serveurs web en tant que "maître-toile" et il a un peu "spécial", les tâches que les autres serveurs n'ont pas. Le compromis pour le cloud computing, c'est la fiabilité - nous ne voulons pas d'un "maître-toile" parce que c'est un point de défaillance unique. Nous voulons tous être identiques et être en mesure de haut de gamme et de réduire, sans se souvenir de ne pas prendre le maître-serveur de cluster.

Quelqu'un at-il de bons conseils sur la re-conception d'une application pour convertir Linux tâches cron en transitoire éléments de travail qui n'ont pas de point unique de défaillance?

Mes idées à ce jour:

• Avoir une machine dédiée uniquement à l'exécution de crons. Ce serait un peu plus facile à gérer, mais serait encore un point unique de défaillance, et serait gaspiller de l'argent supplémentaire instance.
• Certains emplois pourraient être déplacés à partir de linux crons pour MySQL Événements cependant, je ne suis pas un grand fan de cette idée que je ne veux pas mettre la logique de l'application dans la base de données de la couche.
• Peut-être que nous pouvons exécuter tous les crons sur toutes les machines, mais de changer notre cron scripts afin qu'ils commencent tous avec un peu de logique qui met en œuvre un mécanisme de verrouillage de sorte qu'un seul serveur prend en fait d'action et les autres, il suffit de sauter. Je ne suis pas fan de cette idée qu'il y paraît potentiellement buggy et je préfère utiliser un Amazon meilleures pratiques plutôt que de rouler notre propre.
• Je suis d'imaginer une situation où les travaux sont planifiés quelque part, ajouté à une file d'attente, puis les serveurs pourraient chacun être un travailleur, qui peut dire "hey, les gars, je vais prendre celui-ci". Amazon Simple Workflow Service des sons exactement ce genre de chose, mais je ne suis actuellement pas en savoir beaucoup sur elle de sorte que des précisions seraient utiles. Il semble sorte de "poids lourds" pour quelque chose d'aussi simple qu'un cron? Est-ce le bon service ou est-il plus adapté Amazon service?

---

Mise à jour: Depuis posant la question, j'ai regardé le Amazon Simple Workflow Service webinaire sur youtube et a remarqué à 34:40 (http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s) j'ai attrapé un aperçu d'une diapositive de mentionner des tâches cron comme un exemple d'application. Dans leur page de documentation, "AWS Flow Framework échantillons pour Amazon SWF", Amazon disent qu'ils ont des exemples de code pour crons:

... > Cron jobs Dans cet exemple, une longue course de flux de travail périodiquement exécute une activité. La capacité de poursuivre les exécutions, en tant que nouveau les exécutions de sorte qu'une exécution peut fonctionner pendant de très longues périodes de le temps est démontrée. ...

J'ai téléchargé le SDK AWS pour Java (http://aws.amazon.com/sdkforjava/) et bien sûr enterré à l'intérieur d'un ridicule couches de dossiers, il est certains de 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, ce n'est pas vraiment utile car il n'est pas quelque chose que je peux facilement digérer avec mon niveau de compétences. Le même échantillon est manquant dans le sdk php et il ne semble pas être un tutoriel qui marche bien le processus. Donc, fondamentalement, je suis toujours à la chasse pour obtenir des conseils ou des conseils...

Answer 1

J'ai signé pour Amazon Gold support pour poser cette question, c'était leur réponse:

---

Tom

J'ai fait un rapide sondage auprès de certains de mes collègues et est venu vide sur le cron, mais après avoir dormi sur elle, j'ai réalisé cette importante étape peut être limitée à la fermeture. J'ai donc cherché "distribué cron job de verrouillage" et trouvé une référence à la Gardienne, un projet Apache.

http://zookeeper.apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-successfully-scaling-with-scalr-on-amazon-by-se.html

J'ai également vu de référence à l'utilisation de memcached ou un semblable mécanisme de mise en cache de manière à créer des serrures avec une durée de vie. De cette façon, vous avez défini un drapeau, avec une durée de vie de 300 secondes et pas d'autres cron travailleur d'exécuter le travail. La serrure sera automatiquement libéré après la durée de vie a expiré. C'est conceptuellement très similaire à la SQS option nous en avons discuté hier.

Voir aussi; Google est joufflu http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

Laissez-moi savoir si cela aide, et n'hésitez pas à poser des questions, nous sommes très conscients que nos services peut être complexe et intimidant pour les débutants et chevronnés développeurs. Nous sommes toujours heureux d'architecture de l'offre et de meilleurs conseils.

Meilleures salutations,

Ronan G. Amazon Web Services

Answer 2

Je pense que cette vidéo répond à votre question exacte - cronjobs aws moyen (évolutive et tolérante aux pannes):

À l'aide de Cron dans le Cloud avec Amazon Simple Flux de travail

La vidéo décrit le SWF service à l'aide des cas d'utilisation spécifiques de mise en œuvre de tâches cron.

La relative complexité de la solution peut être difficile à avaler si vous êtes à venir tout droit d'un crontab. Il y a une étude de cas à la fin qui m'a aidé à comprendre ce que cette complexité supplémentaire qui vous permet d'acheter. Je suggère de regarder l'étude de cas et en tenant compte de vos besoins d'évolutivité et de tolérance de panne à décider si vous devez migrer à partir de votre crontab solution.

Answer 3

Soyez prudent avec l'utilisation SQS pour les tâches cron, comme ils n'ont pas de garantie que seul "un travail est visible que par une machine". Ils garantissent que "au moins une" 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 donner "au moins une fois" remise de tous les messages dans ses files d'attente. Bien que la plupart du temps chaque message sera livré à votre demande exactement une fois, vous devez concevoir votre système de sorte que le traitement d'un message plus d'une fois ne pas créer d'erreurs ou d'incohérences.

Jusqu'à présent, je peux penser à propos de la solution si vous en avez un exemple avec Gearman Travail de l'instance de Serveur installé: http://gearman.org/. Sur la même machine, vous configurer les tâches cron qui produisent de commande pour l'exécution de votre tâche cron tâche en arrière-plan. Puis, l'un de vos serveurs web (travailleurs) va commencer l'exécution de cette tâche, il garantit que seul le prendre. Il n'a pas d'importance combien de travailleurs (en particulier lorsque vous êtes à l'aide de mise à l'échelle automatique).

Les problèmes avec cette solution sont:

• Gearman serveur est point de défaillance unique, sauf si vous configurez avec le stockage distribué, par exemple l'utilisation de memcached ou une base de données
• Ensuite, à l'aide de plusieurs Gearman serveurs, vous devez sélectionner l'un qui crée de la tâche par tâche cron, donc encore une fois, nous sommes de retour pour le même problème. Mais si vous pouvez vivre avec ce genre de point de défaillance unique à l'aide de Gearman ressemble assez bonne solution. Surtout que vous n'avez pas besoin de grande instance (instance micro dans notre cas est assez).

Answer 4

Je suis tombé sur cette question pour la troisième fois maintenant, et j'ai pensé à puce. Nous avons eu ce dilemme pour un certain temps maintenant. J'ai toujours vraiment se sentir AWS manque une fonctionnalité ici.

Dans notre cas, après avoir examiné les solutions possibles, nous avons décidé que nous avions deux options:

• Configurer une tâche cron du serveur qui exécute les travaux qui ne doit être exécuté qu'une fois à un temps, à l'échelle automatique et assurez-vous qu'il est remplacé lors de certaines CloudWatch les statistiques ne sont pas ce qu'ils devraient être. Nous utilisons cloud-init scripts pour obtenir le cron jobs en cours d'exécution. Bien sûr, cela vient avec un temps d'arrêt, conduisant à manqué cronjobs (lors de l'exécution de certaines tâches à chaque minute, comme nous le faisons).
• Utilisez la logique qu' rcron utilise. Bien sûr, la magie n'est pas vraiment en rcron lui-même, il est dans la logique que vous utilisez pour détecter une défaillance du nœud (nous utilisons keepalived ici) et "mise à niveau" un autre nœud maître.

Nous avons décidé d'aller avec la deuxième option, tout simplement parce qu'il est brillamment rapide et nous avons déjà eu l'expérience avec les serveurs web de l'exécution de ces tâches cron (dans notre pré-AWS ère).

Bien sûr, cette solution est conçue spécifiquement pour le remplacement du traditionnel d'un nœud job cron approche, où le calendrier est le facteur déterminant (par exemple, "je veux Un travail à exécuter une fois par jour à 5 heures du matin", ou comme dans notre cas, "je veux du travail B pour exécuter une seule fois chaque minute"). Si vous utilisez les tâches cron pour déclencher le traitement par lots logique, vous devriez vraiment jeter un oeil à SQS. Il n'y a aucun actif-passif dilemme, ce qui signifie que vous pouvez utiliser un serveur unique ou un ensemble de la main-d'œuvre pour le traitement de votre file d'attente. Je voudrais aussi suggérer regardant SWF pour l'accroissement de votre main-d'œuvre (bien qu' auto scaling pourrait être en mesure de faire le tour ainsi dans la plupart des cas).

Selon un autre tiers était quelque chose que nous voulions éviter.

Answer 5

"Amazon" façon est d'être distribué, sens encombrants crons devrait être divisé en de nombreux petits emplois et remis à droite machines. À l'aide de SQS pour la colle il assure le travail est vu par une seule machine. Il tolère aussi à l'échec, puisque les files d'attente de tampon jusqu'à ce qu'une machine tourne le dos.

Considérer également si vous avez vraiment besoin de " lot " de ces opérations. Ce qui se passe si une nuit, les mises à jour sont beaucoup plus importante que prévu? Même avec dynamique de ressourcement, de votre traitement pourrait être retardé d'attente pour assez de machines à tourner. Au lieu de cela, stocker vos données dans SDB, informer les machines de mises à jour via SQS, et de créer votre flux RSS à la volée (avec cache).

Lot emplois sont d'une époque où les ressources étaient limitées et "live", les services ont eu la priorité. Dans le cloud, ce n'est pas le cas.