Подтвердить что ты не робот

Как преобразовать задания cron Linux в "Amazon way"?

К лучшему или к худшему, мы перенесли наше все LAMP веб-приложение с выделенных машин на облако (машины Amazon EC2). До сих пор это здорово, но способ, которым мы делаем crons, является неоптимальным. У меня есть вопрос, касающийся Amazon о том, как лучше всего управлять задачами cron в облаке, используя "путь Amazon".

Проблема. У нас есть несколько веб-серверов, и нам нужно запускать клоны для пакетных заданий, таких как создание RSS-каналов, запуск электронных писем и многое другое. НО задания cron должны выполняться только на одной машине, потому что они часто пишут в базу данных, поэтому дублируют результаты, если они запускаются на нескольких машинах.

До сих пор мы обозначили один из веб-серверов как "master-webserver" и у него есть несколько "специальных" задач, которые другие веб-серверы не имеют. Компромисс для облачных вычислений - надежность - мы не хотим "master-webserver", потому что это единственная точка отказа. Мы хотим, чтобы все они были одинаковыми и имели возможность масштабировать и масштабировать, не забывая не вынимать сервер-сервер из кластера.

Как мы можем перепроектировать наше приложение для преобразования заданий Linux cron в переходные рабочие элементы, которые не имеют единой точки отказа?

Мои идеи до сих пор:

  • У вас есть машина, предназначенная только для работы с коронками. Это было бы немного более управляемым, но все равно было бы одноточечным отказом, и он потратил бы деньги на дополнительный экземпляр.
  • Возможно, некоторые рабочие места могут быть перенесены из хруста Linux из событий MySQL, однако я не являюсь большим поклонником этой идеи, так как не хочу ставить логику приложения в слой базы данных.
  • Возможно, мы можем запускать все коронки на всех машинах, но изменять наши скрипты cron, чтобы все они начинались с немного логики, которая реализует механизм блокировки, поэтому только один сервер фактически принимает меры, а остальные просто пропускают. Я не поклонник этой идеи, поскольку она кажется потенциально опасной, и я предпочел бы использовать лучшую практику Amazon, а не сворачивать свои собственные.
  • Я представляю ситуацию, когда задания назначаются где-то, добавляются в очередь, а затем веб-серверы могут быть рабочими, которые могут сказать "эй, я возьму это". Amazon Simple Workflow Service звучит именно так, но я в настоящее время не знаю много об этом, поэтому любые особенности будут полезны. Кажется, это тяжело для чего-то простого, как крона? Это правильный сервис или есть более подходящая услуга Amazon?

Обновление. Спрашивая вопрос, я просмотрел веб-семинар Amazon Simple Workflow Service на YouTube и заметил в 34:40 (http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s) Я заметил проблеск слайда, в котором упоминались задания cron в качестве примера приложения. На странице документации "образцы структуры AWS Flow для Amazon SWF", Amazon говорят, что у них есть пример кода для кронов:

... > Задачи Cron. В этом примере периодически работает длительный рабочий процесс выполняет действие. Возможность продолжать казни как новые казни, так что выполнение может выполняться в течение очень длительных периодов время....

Я загрузил AWS SDK для Java (http://aws.amazon.com/sdkforjava/) и, конечно же, зарылся в смешные слои папок, есть какой-то Java-код (aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow).

Проблема в том, что если честно, это не помогает, так как это не то, что я могу легко переварить с помощью своего набора навыков. Такой же образец отсутствует в SDK PHP, и, похоже, не существует учебника, который проходит через этот процесс. Так что, в основном, я все еще охочусь за советом или советами.

4b9b3361

ОТВЕТЫ

Ответ 2

Я подписался на поддержку Amazon Gold, чтобы задать им этот вопрос, это был их ответ:

Tom

Я сделал быстрый опрос некоторых моих коллег и подошёл на cron, но после сна я понял, что важным шагом может быть ограничивается блокировкой. Поэтому я искал "распределенное блокирование работы cron", и нашел ссылку на Zookeeper, проект 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

Также я видел ссылку на использование memcached или аналогичное кэширование механизм как способ создания блокировок с TTL. Таким образом, вы устанавливаете флаг, с TTL 300 секунд, и никакой другой cron рабочий не выполнит работа. Блокировка будет автоматически освобождена после того, как TTL будет истекший. Это концептуально очень похоже на вариант SQS. обсуждался вчера.

Также см. Google chubby http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

Сообщите мне, если это поможет, и вы можете задавать вопросы, мы очень осознавая, что наши услуги могут быть сложными и сложными для начинающих и опытных разработчиков. Мы всегда рады предложить архитектуры и рекомендаций передовой практики.

С уважением,

Веб-службы Романа Дж. Амазонки

Ответ 3

Я думаю, что это видео отвечает на ваш точный вопрос - cronjobs aws (масштабируемый и отказоустойчивый):

Использование Cron в облаке с простым рабочим процессом Amazon

Видео описывает службу SWF, используя конкретный прецедент реализации cronjob.

Относительная сложность решения может быть трудно усвоить, если вы придете прямо из crontab. В конце есть тематическое исследование, которое помогло мне понять, что эта дополнительная сложность покупает вас. Я бы предложил просмотреть тематическое исследование и рассмотреть ваши требования к масштабируемости и отказоустойчивости, чтобы решить, следует ли вам перейти от существующего решения crontab.

Ответ 4

Будьте осторожны с использованием SQS для cronjobs, поскольку они не гарантируют, что только "одно задание рассматривается только одной машиной". Они гарантируют, что сообщение "по крайней мере одно" получит сообщение.

От: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

В: Сколько раз я получаю каждое сообщение?

Amazon SQS спроектирован таким образом, чтобы обеспечить "по крайней мере один раз" доставку всех сообщений в своих очередях. Хотя в большинстве случаев каждое сообщение будет доставлено в ваше приложение ровно один раз, вы должны разработать свою систему, чтобы обработка сообщения несколько раз не создавала никаких ошибок или несоответствий.

До сих пор я могу думать о решении, в котором у вас есть один экземпляр с установленным экземпляром Gearman Job Server: http://gearman.org/. На том же компьютере вы настраиваете задания cron, которые производят команду для выполнения вашей задачи cronjob в фоновом режиме. Тогда один из ваших веб-серверов (рабочих) начнет выполнение этой задачи, это гарантирует, что только один из них примет его. Неважно, сколько у вас рабочих (особенно при использовании автоматического масштабирования).

Проблемы с этим решением:

  • Сервер Gearman является единственной точкой отказа, если вы не настроили его с распределенным хранилищем, например, с помощью memcached или некоторой базы данных
  • Затем, используя несколько серверов Gearman, вы должны выбрать тот, который создает задачу через cronjob, поэтому снова мы возвращаемся к той же проблеме. Но если вы можете жить с такой единственной точкой отказа, используя Gearman, это выглядит неплохо. Тем более, что вам не нужен большой экземпляр для этого (микро-экземпляр в нашем случае достаточно).

Ответ 5

Amazon только что выпустила новые функции для Elastic Beanstalk. Из docs:

AWS Elastic Beanstalk поддерживает периодические задачи для рабочей среды

уровней в средах с предопределенной конфигурацией с стеком решений, который содержит "v1.2.0" в имени контейнера. "

Теперь вы можете создать среду, содержащую файл cron.yaml, который настраивает задачи планирования:

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

Я бы предположил, что страхование его запуска только один раз в автомасштабируемой среде используется через очередь сообщений (SQS). Когда демона cron запускает событие, он помещает этот вызов в очередь SQS, и сообщение в очереди оценивается только один раз. Документы говорят, что выполнение может быть отложено, если SQS обрабатывает много сообщений.

Ответ 6

В третий раз я столкнулся с этим вопросом и подумал, что я заберусь. У нас была эта дилемма какое-то время. Я по-прежнему чувствую, что AWS отсутствует здесь.

В нашем случае, рассмотрев возможные решения, мы решили, что у нас есть два варианта:

  • Настройте сервер cronjob, который запускает задания, которые должны запускаться только один раз за раз, автоматически масштабируйте его и убедитесь, что он заменен, когда определенная статистика CloudWatch не является тем, чем они должны быть. Мы используем скрипты cloud-init, чтобы запустить cronjobs. Конечно, это происходит с простоями, что приводит к пропущенным cronjobs (при выполнении определенных задач каждую минуту, как и мы).
  • Используйте логику, используемую rcron. Конечно, магия на самом деле не в самом rcron, она в логике, которую вы используете для обнаружения неисправного node (здесь мы используем keepalived) и "обновляем" еще один node для управления.

Мы решили пойти со вторым вариантом, просто потому, что он блестяще быстр, и у нас уже был опыт работы с веб-серверами, выполняющими эти cronjob (в нашу эпоху до AWS).

Конечно, это решение предназначено специально для замены традиционного подхода cronjob, где решающим фактором является выбор времени (например, "Я хочу, чтобы работа A выполнялась один раз в день в 5 часов утра", или как в нашем случае "Я хочу, чтобы работа B запускалась раз в минуту" ). Если вы используете cronjobs для запуска логики пакетной обработки, вы действительно должны взглянуть на SQS. Там нет активной пассивной дилеммы, то есть вы можете использовать один сервер или целую рабочую силу для обработки очереди. Я также предложил бы взглянуть на SWF для масштабирования вашей рабочей силы (хотя auto scaling мог бы также сделать трюк в большинстве случаев).

В зависимости от другой третьей стороны мы хотели избежать.

Ответ 7

Путь "Амазонки" должен быть распределен, а это означает, что громоздкие кроны должны быть разделены на множество небольших заданий и переданы на правильные машины. Использование SQS для склеивания вместе гарантирует, что каждое задание рассматривается только одной машиной. Он также терпит неудачу, так как очереди будут буферизоваться до тех пор, пока машина не вернется обратно.

Также подумайте, действительно ли вам нужно "выполнять" эти операции. Что произойдет, если однодневное обновление значительно больше, чем ожидалось? Даже при динамическом ресурсе ваша обработка может быть отложена, ожидая, пока машины начнут вращаться. Вместо этого сохраните свои данные в SDB, уведомите машины об обновлениях через SQS и создайте RSS-канал "на лету" (с кешированием).

Пакетные задания выполняются с момента, когда ресурсы обработки были ограничены, а "живые" службы имели приоритет. В облаке это не так.

Ответ 10

Что мы делаем, так это то, что у нас есть один конкретный сервер, который является частью нашего кластера веб-приложений за ELB, также назначил определенное имя DNS, чтобы мы могли запускать задания на этом конкретном сервере. Это также имеет то преимущество, что если это задание заставляет сервер замедляться, ELB удалит его из кластера, а затем вернет его после завершения задания и снова станет здоровым.

Работает как чемпион.

Ответ 12

Поскольку никто не упомянул CloudWatch Event, я бы сказал, что это способ AWS делать задания cron. Он может запускать много действий, таких как функция лямбда, задача ECS.