amazon-ec2 cron scheduled-tasks lamp amazon-swf

amazon ec2 - ¿Cómo convertir los trabajos cron de Linux a "la manera de Amazon"?



amazon-ec2 scheduled-tasks (12)

Para bien o para mal, hemos migrado toda nuestra aplicación web LAMP de máquinas dedicadas a la nube (máquinas Amazon EC2). Está yendo bien hasta ahora, pero la forma en que hacemos crons no es óptima. Tengo una pregunta específica de Amazon sobre cómo administrar mejor los trabajos de cron en la nube usando "la manera de Amazon".

El problema : tenemos múltiples servidores web, y necesitamos ejecutar crons para trabajos por lotes, como crear feeds RSS, desencadenar correos electrónicos, muchas cosas diferentes en realidad. PERO los trabajos de cron solo deben ejecutarse en una máquina porque a menudo escriben en la base de datos para que se dupliquen los resultados si se ejecutan en varias máquinas.

Hasta ahora, hemos designado a uno de los servidores web como el "servidor web maestro" y tiene algunas tareas "especiales" que los otros servidores web no tienen. La compensación para la computación en la nube es la confiabilidad: no queremos un "servidor web maestro" porque es un punto único de falla. Queremos que todos sean idénticos y que puedan ampliar y reducir de escala sin recordar no sacar el servidor web principal del clúster.

¿Cómo podemos rediseñar nuestra aplicación para convertir trabajos cron de Linux en elementos de trabajo transitorios que no tienen un único punto de falla?

Mis ideas hasta ahora

  • Tener una máquina dedicada solo a ejecutar crones. Esto sería un poco más manejable, pero aún sería un punto único de falla, y desperdiciaría algo de dinero con una instancia adicional.
  • Algunos trabajos podrían posiblemente trasladarse de Linux crons a MySQL Events; sin embargo, no soy un gran admirador de esta idea ya que no quiero poner la lógica de la aplicación en la capa de la base de datos.
  • Quizás podamos ejecutar todos los crons en todas las máquinas pero cambiemos nuestros scripts cron para que todos comiencen con un poco de lógica que implemente un mecanismo de bloqueo para que solo un servidor actúe y los demás salten. No soy fanático de esta idea, ya que suena potencialmente con errores y preferiría usar una de las mejores prácticas de Amazon en lugar de hacer la nuestra.
  • Me estoy imaginando una situación en la que los trabajos están programados en algún lugar, agregados a una cola y luego los servidores web podrían ser trabajadores, que pueden decir "hey, tomaré este". El servicio de flujo de trabajo simple de Amazon suena exactamente este tipo de cosas, pero actualmente no sé mucho al respecto, por lo que cualquier información específica sería útil. Parece algo pesado para algo tan simple como un cron? ¿Es el servicio correcto o hay un servicio de Amazon más adecuado?

Actualización: desde que hice la pregunta, vi el webinar del Servicio de flujo de trabajo simple de Amazon en YouTube y lo noté a las 34:40 ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ). Pude ver un vistazo. diapositiva mencionando trabajos cron como una aplicación de muestra. En su página de documentación, " ejemplos de AWS Flow Framework para Amazon SWF ", Amazon dice que tienen código de muestra para crons:

... > trabajos de cron En esta muestra, un flujo de trabajo de larga ejecución ejecuta periódicamente una actividad. Se demuestra la capacidad de continuar ejecuciones como nuevas ejecuciones para que una ejecución pueda ejecutarse durante periodos de tiempo muy extensos. ...

Descargué el AWS SDK para Java ( http://aws.amazon.com/sdkforjava/ ) y, como es de aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow enterrado dentro de una ridícula capa de carpetas, hay algún código Java ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow ).

El problema es que, si soy sincero, esto realmente no ayuda, ya que no es algo que pueda digerir fácilmente con mi conjunto de habilidades. La misma muestra falta en el PHP SDK y no parece haber un tutorial que recorre el proceso. Básicamente, sigo buscando consejos o consejos.

Amazon acaba de released nuevas características para Elastic Beanstalk. De los docs :

AWS Elastic Beanstalk admite tareas periódicas para el entorno del trabajador
niveles en entornos que ejecutan una configuración predefinida con una pila de soluciones que contiene "v1.2.0" en el nombre del contenedor. "

Ahora puede crear un entorno que contenga un archivo cron.yaml que configure las tareas de programación:

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 * * *"

Me imagino que el seguro de ejecutarlo solo una vez en un entorno de escala automática se utiliza a través de la cola de mensajes (SQS). Cuando el cron daemon desencadena un evento, pone esa llamada en la cola SQS y el mensaje en la cola solo se evalúa una vez. Los documentos dicen que la ejecución puede retrasarse si SQS tiene que procesar muchos mensajes.

Como nadie mencionó el Evento de CloudWatch , diría que es la manera de AWS de hacer trabajos de cron. Puede ejecutar muchas acciones, como la función Lambda, la tarea ECS.

Creo que este video responde tu pregunta exacta: cronjobs the aws way (escalable y tolerante a errores):

Uso de Cron en la nube con Amazon Simple Workflow

El video describe el servicio SWF utilizando el caso de uso específico de implementar cronjobs.

La complejidad relativa de la solución puede ser difícil de tragar si vienes directamente de un crontab. Al final, hay un estudio de caso que me ayudó a comprender qué le compra esa complejidad adicional. Sugeriría ver el estudio de caso y considerar sus requisitos de escalabilidad y tolerancia a fallas para decidir si debe migrar de su solución crontab existente.

La forma de "Amazon" debe distribuirse, lo que significa que los crones voluminosos deberían dividirse en muchos trabajos más pequeños y entregarse a las máquinas adecuadas. El uso de SQS para unirlo asegura que cada trabajo sea visto por una sola máquina. También tolera fallas ya que las colas se almacenarán hasta que una máquina vuelva a funcionar.

También considere si realmente necesita ''lotear'' estas operaciones. ¿Qué sucede si las actualizaciones de una noche son considerablemente más grandes de lo esperado? Incluso con la dotación de recursos dinámica, su procesamiento podría retrasarse a la espera de que suficientes máquinas se activen. En su lugar, almacene sus datos en SDB, notifique a las máquinas sobre las actualizaciones a través de SQS y cree su feed RSS sobre la marcha (con almacenamiento en caché).

Los trabajos por lotes son de una época en que los recursos de procesamiento eran limitados y los servicios ''en vivo'' tenían prioridad. En la nube, este no es el caso.

Lo que hacemos es tener un servidor en particular que es parte de nuestro cluster de aplicaciones web detrás de un ELB que también tiene asignado un nombre DNS específico para que podamos ejecutar los trabajos en ese servidor específico. Esto también tiene el beneficio de que si ese trabajo hace que el servidor se desacelere, el ELB lo eliminará del clúster y luego lo devolverá una vez que el trabajo haya terminado y se recupere.

Funciona como un campeón.

Me encontré con esta pregunta por tercera vez y pensé que podría participar. Hemos tenido este dilema desde hace un tiempo. Siento realmente que a AWS le falta una característica aquí.

En nuestro caso, después de ver las posibles soluciones, decidimos que teníamos dos opciones:

  • Configure un servidor cronjob que ejecute los trabajos que solo deberían ejecutarse una vez a la vez, escale automáticamente y asegúrese de que se reemplacen cuando ciertas estadísticas de CloudWatch no sean lo que deberían ser. Usamos scripts de cloud-init para ejecutar cronjobs. Por supuesto, esto viene con un tiempo de inactividad, lo que lleva a cronjobs perdidos (al ejecutar ciertas tareas cada minuto, como hacemos nosotros).
  • Usa la lógica que usa rcron . Por supuesto, la magia no está realmente en el rcron en sí, está en la lógica que utilizas para detectar un nodo defectuoso (utilizamos keepalived aquí) y "actualiza" otro nodo para dominarlo.

Decidimos ir con la segunda opción, simplemente porque es increíblemente rápido y ya teníamos experiencia con los servidores web que ejecutaban estos cronjobs (en nuestra era anterior a AWS).

Por supuesto, esta solución está diseñada específicamente para reemplazar el enfoque cronjob tradicional de un nodo, donde el tiempo es el factor decisivo (por ejemplo, "Quiero que el trabajo A se ejecute una vez al día a las 5 AM" , o como en nuestro caso "Quiero trabajo B para correr una vez por minuto " ). Si usa cronjobs para desencadenar lógica de procesamiento por lotes, realmente debería echarle un vistazo a SQS . No hay un dilema activo-pasivo, lo que significa que puede usar un solo servidor o una fuerza de trabajo completa para procesar su cola. También te sugiero que busques en SWF para escalar tu fuerza de trabajo (aunque auto scaling podría ser útil en la mayoría de los casos).

Dependiendo de otro tercero, era algo que queríamos evitar.

Me inscribí en Amazon Gold para hacerles esta pregunta, esta fue su respuesta:

Tom

Hice una encuesta rápida a algunos de mis colegas y me quedé sin el cron, pero después de dormirme me di cuenta de que el paso importante puede estar limitado al bloqueo. Así que busqué "bloqueo cron job distribuido" y encontré una referencia a Zookeeper, un proyecto 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

También he visto una referencia al uso de memcached o un mecanismo similar de caché como una forma de crear bloqueos con un TTL. De esta forma, establece un indicador, con un TTL de 300 segundos y ningún otro cron worker ejecutará el trabajo. El bloqueo se liberará automáticamente después de que el TTL haya expirado. Esto es conceptualmente muy similar a la opción SQS que discutimos ayer.

Ver también; Google''s gordito http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

Avíseme si esto ayuda, y siéntase libre de hacer preguntas, somos muy conscientes de que nuestros servicios pueden ser complejos y desalentadores tanto para principiantes como para desarrolladores expertos. Siempre estamos felices de ofrecer la arquitectura y el asesoramiento de mejores prácticas.

Atentamente,

Servicios web de Ronan G. Amazon

Tenga cuidado al usar SQS para cronjobs, ya que no garantizan que solo "un trabajo sea visto por una sola máquina". Garantizan que "al menos uno" recibirá el mensaje.

Desde: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

P: ¿Cuántas veces recibiré cada mensaje?

Amazon SQS está diseñado para proporcionar "al menos una vez" la entrega de todos los mensajes en sus colas. Aunque la mayoría de las veces cada mensaje se entregará a su aplicación exactamente una vez, debe diseñar su sistema para que el procesamiento de un mensaje más de una vez no cree ningún error o incoherencia.

Hasta ahora puedo pensar en la solución donde tienes instalada una instancia con la instancia de Gearman Job Server: http://gearman.org/ . En la misma máquina, configura los trabajos cron que están produciendo el comando para ejecutar su tarea cronjob en segundo plano. Entonces uno de sus servidores web (trabajadores) comenzará a ejecutar esta tarea, lo que garantiza que solo uno lo tomará. No importa cuántos trabajadores tenga (especialmente cuando usa escala automática).

Los problemas con esta solución son:

  • El servidor Gearman es un punto único de falla, a menos que lo configure con almacenamiento distribuido, por ejemplo, utilizando memcached o alguna base de datos.
  • Luego, al utilizar varios servidores de Gearman, debe seleccionar uno que cree tareas a través de cronjob, así que de nuevo volvemos al mismo problema. Pero si puedes vivir con este tipo de punto único de falla, usar Gearman parece una solución bastante buena. Especialmente que no necesita una gran instancia para eso (la micro instancia en nuestro caso es suficiente).