Celery: Fitur: Beat harus menghindari pemanggilan bersamaan

Ini bisa diselesaikan dengan menggunakan kombu.pidbox , ini juga cara celeryd mendeteksi bahwa sudah ada node dengan nama yang sama berjalan. Karena celerybeat terpusat, ia dapat menggunakan nama simpul tetap.

Sebagai efek sampingnya, kita akan dapat mengontrol celerybeat dengan perintah remote control (misalnya, mungkin ada perintah untuk memuat ulang jadwal, atau melihat tugas apa yang harus diselesaikan dalam waktu dekat). Itu adalah efek samping yang cukup mengagumkan jika Anda bertanya kepada saya.

Perlu lebih banyak perencanaan, karena ada kasus penggunaan untuk menjalankan beberapa instance dalam cluster yang sama. Misalnya untuk "sharding" jadwal dalam beberapa bagian. Setidaknya harus ada kemungkinan untuk memilih nama node untuk setiap instance. Menunda ke 2.3.0.

Kami memiliki masalah ketika kotak yang menjalankan celerybeat menjadi offline tanpa fallback yang baik untuk memulai instance celerybeat untuk menggantikannya. Apa cara HA yang disarankan untuk menjalankan celerybeat ?

Akankah pendekatan kombu.pidbox memungkinkan kita untuk menjalankan beberapa instance celerybeat yang hanya akan tidur jika terdeteksi bahwa sebuah instance sudah berjalan dengan nama node tetap dan polling untuk mempromosikan dirinya ke aktif jika itu contoh turun?

Menjalankan beberapa instans aktif terdengar menarik - manfaat lain apa yang mungkin ada selain berbagi jadwal?

+1

+1

Ini adalah sesuatu yang menjadi perhatian nyata untuk penyebaran besar karena ketahanan penjadwalan itu penting.

+9999 ;)
Apakah ada yang salah dengan menggunakan solusi kombu.pidbox ? Bahkan tanpa fitur sharding dan mewah, ini akan sangat bagus dan sangat berguna. Saat ini saya perlu memulai celerybeat secara manual di host lain.

Pidbox bisa digunakan, tapi masalahnya beat itu bukan konsumen. Untuk menanggapi pesan siaran seperti 'ada contoh beat di sini?' itu harus terus-menerus mendengarkan pesan di antrian siarannya, dan saat ini tidak bisa karena sibuk menjadwalkan pesan.

Secara teknis itu bisa menggunakan utas kedua, tetapi itu dapat menyeret kinerja ke bawah dan banyak overhead hanya untuk fitur ini.

Solusi kedua adalah dengan menggunakan kunci, tetapi dengan kerugian karena harus melepaskannya. Yaitu jika proses ketukan dimatikan, kunci basi akan memerlukan intervensi manual untuk memulai instance baru.

Itu juga bisa memiliki batas waktu 2 detik pada kunci, dan memperbarui kunci setiap detik. Maka itu berarti instance baru harus menunggu selama 2 detik jika kunci ditahan.

Kunci di amqp dapat dibuat dengan mendeklarasikan antrian, misalnya `queue_declare('celerybeat.lock', argument={'x-expires': 2000}``

+1

Saya ingin melihat ini

+1

+1

+1 juga

+1

Adakah yang benar-benar mengimplementasikan solusi kombu.pidbox atau mekanisme lain yang memecahkan masalah ini? Jika demikian, silakan bagikan. Ada banyak orang yang masih bertanya-tanya apa praktik terbaik itu.

Adakah yang pindah dari seledri sama sekali karena ini? Saya juga tertarik untuk mengetahuinya.

EDIT:

Saya menemukan intisari ini (https://Gist.github.com/winhamwr/2719812) melalui diskusi google (https://www.google.co.in/search?q=celerybeat+lock&aq=f&oq=celerybeat+lock&aqs= chrome.0.57j62l3.2125j0&sourceid=chrome&ie=UTF-8).

Saya juga bertanya-tanya apakah ada yang baru saja menggunakan pidfile bersama untuk celerybeat secara langsung, mungkin dengan EBS di AWS atau mungkin di ember S3… celerybeat --pidfile=/path/to/shared/volume .

Saya perhatikan bahwa master saat ini (3.1 dev) memiliki langkah gosip untuk konsumen. Apakah mungkin untuk memanfaatkan antrian gosip dan pemilihan pemimpin untuk mengoordinasikan proses ketukan yang tertanam? Artinya setiap pekerja akan menjalankan proses ketukan tertanam tetapi hanya pemimpin yang akan mengantri tugas berkala. Ini kemungkinan akan mengasumsikan penyimpanan jadwal bersama.

@mlavin Ini bisa bekerja, tetapi hanya untuk transportasi broker yang mendukung siaran

Masalah dengan solusi pidbox adalah bahwa program celerybeat kemudian harus ditulis ulang untuk menggunakan Async I/O.
Saat ini tidak dapat menggunakan tugas dan memproduksinya, karena penjadwal memblokir.

Dalam kebanyakan kasus, ini sama sekali bukan fitur yang diperlukan karena sebagian besar penerapan produksi memiliki host khusus untuk proses beat, dan kemudian menggunakan --pidfile sudah cukup untuk memastikan Anda tidak memulai banyak instance.

Saya telah menemukan bahwa seringkali orang yang terkena masalah ini adalah mereka yang menggunakan opsi -B dalam daemonisasi
skrip dan kemudian menduplikasi pengaturan itu ke Host lain.

Jadi saya mengerti bahwa itu menjengkelkan, tetapi saya tidak berpikir itu kritis. Jika ada yang benar-benar menginginkan solusi maka mereka dapat berkontribusi, atau mempekerjakan saya/donasi untuk mengimplementasikannya.

Seseorang dapat menggunakan uWSGI untuk memiliki proses ketukan tunggal dengan mundur ke node lain

+1, kami meluncurkan instans Amazon EC2 yang identik dan akan menyenangkan memiliki tugas berkala yang hanya dijalankan dalam satu node. Sementara itu saya akan mencoba menggunakan uWSGI terima kasih atas sarannya.

+1

+1

Saya telah membuat kasus di tempat kerja untuk menggunakan Celerybeat untuk penjadwalan tetapi tidak memiliki HA di luar kotak membuatnya sangat sulit. Bahkan, sepertinya kita akan menjatuhkannya sama sekali karena ini. Sederhananya, menjalankan hanya 1 instance Celerybeat membuat ini menjadi satu titik kegagalan dan karenanya tidak siap produksi untuk kami.

@junaidch Saya tidak berpikir Anda harus menjatuhkan seledri karena ini. Anda selalu dapat menjalankan penjadwal di setiap server dan untuk tugas berkala gunakan semacam mekanisme penguncian untuk memastikan mereka tidak tumpang tindih dengan cara apa pun dan juga tidak berjalan terlalu sering. Selain itu, Anda dapat mensubklasifikasikan penjadwal dan melakukan penguncian di sana juga atau melewati penguncian tingkat tugas dan hanya melakukan semuanya di penjadwal.

Akan lebih baik untuk memiliki beberapa fungsi bawaan di seledri karena ini adalah semacam solusi, tetapi tetap dapat digunakan dalam produksi dengan baik.

Terima kasih @23doors.

Tugas saya sudah mempertahankan kunci Redis untuk mencegah contoh lain dari tugas berjalan. Jika saya menjalankan 2 ketukan pada 2 mesin yang berbeda dan tugas saya dijadwalkan untuk interval 5 menit, saya pikir itu akan berhasil meskipun kedua ketukan akan mendorong tugas ke antrian. Membuat kasus untuk adopsi semakin sulit ketika Anda harus menerapkan solusi untuk fungsionalitas inti Anda.

Saya akan menyelidiki rekomendasi sub-klasifikasi. Itu mungkin pendekatan yang lebih bersih.

Terima kasih atas sarannya!

Di Lulu kami memecahkan ini dengan menulis manajer tunggal cluster sederhana (bernama BeatCop). Ini menggunakan kunci Redis yang kedaluwarsa untuk memastikan hanya ada satu Celerybeat yang berjalan di kumpulan penskalaan otomatis pekerja Celery. Jika sesuatu terjadi pada Celerybeat itu (seperti instance akan diskalakan atau mati atau Celerybeat mogok), node lain secara otomatis memunculkan Celerybeat baru. Kami telah membuka BeatCop .

@ingmar kami menulis ini https://github.com/ybrs/single-beat untuk alasan yang sama, terakhir kali saya memeriksa saya tidak melihat komentar Anda. kami juga merilis sebagai opensource mungkin berguna untuk beberapa lainnya. kurang lebih melakukan hal yang sama.

sejauh yang saya bisa lihat, perbedaan utama dengan beatcop -, kami menggunakan pyuv - jadi beatcop lebih portabel saya pikir lebih sedikit ketergantungan -, arahkan stderr dan stdout anak sebagai orang tua, dan keluar jika anak mati dengan kode yang sama, konfigurasikan dengan variabel lingkungan. jadi sedikit lebih mudah untuk menambah supervisor.

semoga bisa bermanfaat untuk orang lain.

+1

+1

Saya sedang mempertimbangkan untuk menggunakan nilai kunci Konsul, sebagai pengontrol kunci, adakah yang mencoba pendekatan ini? Jadi sementara ada satu yang bekerja, yang lain akan "tidur" sampai kunci tidak diperbarui, maka mekanisme pemilihan Konsul akan memutuskan siapa yang akan memperbarui nilai kunci yang diberi cap waktu. Siapa pun yang memperbarui kunci adalah orang yang bekerja.

@ingmar Terima kasih untuk ini! Saya akan mencoba ini di cluster pekerja saya.

+10 karena implementasi saat ini berarti satu titik kegagalan yang menghilangkan alasan kami menggunakan antrian terdistribusi sejak awal

+1

+1

Sepertinya ini akan berada di v5.0.0 https://github.com/celery/celery/milestones/v5.0.0

+1

Menutup ini, seperti halnya sumber daya saat ini, dibutuhkan 10 tahun untuk menyelesaikannya.

Maaf, tetapi ini adalah masalah serius untuk apa yang disebut antrean "terdistribusi". Berapa lama pun ini akan diterapkan, pada akhirnya harus diperbaiki. Menutup masalah yang benar-benar valid karena Anda tidak memiliki sumber daya _sekarang_ sepertinya tidak benar. Bisakah Anda membukanya kembali dan menerapkan label yang menunjukkan bahwa itu adalah prioritas rendah saat ini?

Saya tahu alasan penutupan saya sangat mendadak, jadi sebagai pengguna perangkat lunak saya dapat memahami sentimen Anda, tetapi secara teknis Beat lebih seperti fitur tambahan. Ini benar-benar dipisahkan dari seledri lainnya, dan sengaja dirancang untuk tidak didistribusikan agar implementasinya tetap sederhana. Ini dimulai sebagai cara yang rapi untuk mendefinisikan cronjobs dari Python sebagai bonus untuk pengguna yang sudah menggunakan Celery, kemudian semakin banyak orang menggunakan Celery sebagai pengganti cron.

Masalah ini telah terbuka selama ENAM tahun sekarang, dan meskipun sering diminta, dan banyak perusahaan bergantung padanya, tidak ada yang pernah menawarkan untuk membayar implementasinya.

Itu sebenarnya salah satu masalah yang saya pikir akan menarik bagi perusahaan untuk mensponsori. Memang tidak seperti biasanya perusahaan menawarkan untuk membayar fitur apa pun, perbaikan bug, atau bahkan untuk membantu memecahkan masalah produksi. Saya mungkin bisa menghitungnya di satu sisi (Anda luar biasa), jadi sekarang saya tahu betapa naifnya ide itu :)

Saya juga menutup duplikat masalah ini hari ini, lihat #1495. Ada permintaan tarik yang mencoba menyelesaikan masalah, dan beberapa menjanjikan, tetapi mengingat dedikasi yang diperlukan untuk membuktikan bahwa implementasi yang diberikan berhasil, saya masih belum punya waktu untuk meninjaunya dengan benar. Mungkin ini membuat seseorang bertindak, bahkan jika tidak, saya pikir itu lebih baik daripada membiarkan permintaan fitur tetap terbuka selama enam tahun, ketika tidak ada yang mengerjakannya. Itu juga semacam merugikan pengguna yang ingin melihat ini diperbaiki.

@bertanya Cukup adil. Memang benar bahwa cron terdistribusi adalah masalah besar yang rumit, seperti yang Anda katakan di utas lainnya. Dan itu terdengar seperti sesuatu yang seharusnya hidup di luar Seledri.

Terima kasih telah meluangkan waktu untuk menjelaskan alasan Anda secara rinci.

@ask Saya bertanya-tanya apakah masalah ini dapat diatasi dengan menempatkan file celerybeat-schedule (digunakan oleh celery.beat.PersistentScheduler ) di dalam volume NFS yang dibagikan di semua node di cluster?

Kelas PersistentScheduler menggunakan shelve sebagai modul database, jadi penulisan bersamaan ke file celerybeat-schedule harus dicegah dengan desain. Ini adalah kutipan dari dokumentasi shelve :

Modul rak tidak mendukung akses baca/tulis bersamaan ke objek yang disimpan. (Beberapa akses baca simultan aman.) Ketika sebuah program memiliki rak terbuka untuk menulis, tidak ada program lain yang harus membukanya untuk membaca atau menulis.

Dengan asumsi kita memulai ketukan seledri seperti ini:

celery -A project-name beat -l info -s /nfs_shared_volume/celerybeat-schedule

di mana /nfs_shared_volume adalah volume bersama (misalnya, dikelola oleh AWS Elastic File System), dapatkah kita berharap bahwa jadwal tidak akan kacau bahkan jika ada satu proses ketukan seledri yang berjalan di setiap node dalam klaster?

@mikeschaekermann Jika saya membaca dokumen dengan benar shelve tidak berusaha untuk mencegah akses tulis bersamaan. Itu hanya memberitahu Anda untuk tidak membiarkan hal itu terjadi. Bagian yang Anda kutip selanjutnya mengatakan "Penguncian file Unix dapat digunakan untuk menyelesaikan ini, tetapi ini berbeda di seluruh versi Unix dan memerlukan pengetahuan tentang implementasi basis data yang digunakan."

@ze-phyr-us Saya pikir Anda benar, dan saya salah menafsirkan dokumen shelve . Namun, saya bertanya-tanya apakah masalahnya akan terpecahkan dengan asumsi backend Scheduler memastikan operasi atom sesuai jadwal? @ask melakukan django-celery-beat paket dukungan atomicity untuk memecahkan masalah? Saya melihat bahwa itu menggunakan transaksi untuk melakukan beberapa pembaruan.

Untuk siapa pun yang berakhir di sini saat mencari ketukan seledri ramah yang didistribusikan / penskalaan otomatis, dan senang menggunakan Redis sebagai backend; Saya mencoba BeatCop dan single-beat yang disebutkan di atas, tetapi akhirnya memilih RedBeat .

Hai @ddevlin
Saya mengalami masalah serupa, masalah apa yang Anda hadapi saat menggunakan single-beat? Juga jika tidak terlalu banyak, dapatkah Anda membagikan contoh implementasi tentang bagaimana Anda mengonfigurasi redbeat untuk beberapa server.

@ankur11 single-beat memastikan bahwa hanya satu instance dari celery beat yang berjalan, tetapi tidak menyinkronkan status jadwal antar instance.

Jika saya menggunakan penjadwal default dengan tugas berkala yang dimaksudkan untuk berjalan setiap 15 menit, dan memiliki failover dengan ketukan tunggal 14 menit setelah terakhir kali tugas dijalankan, tugas tidak akan berjalan hingga 15 menit setelah seledri baru berdetak contoh dimulai, menghasilkan jeda 29 menit.

Untuk berbagi status jadwal antar instance, saya perlu menggunakan penjadwal alternatif . Django-celery-beat adalah alternatif yang disebutkan dalam dokumen Seledri, tetapi preferensi saya adalah menggunakan Redis sebagai backend untuk sinkronisasi jadwal, karena saya sudah menggunakan Redis sebagai backend Seledri saya.

Redbeat menyertakan status jadwal bersama yang didukung Redis dan penguncian untuk memastikan hanya satu instance yang menjadwalkan tugas, jadi saya tidak memerlukan single-beat atau BeatCop setelah saya mulai menggunakannya.

Dalam implementasi kami, celery beat dimulai dengan supervisor di semua instance, dengan Redbeat sebagai scheduler (misalnya exec celery beat --scheduler=redbeat.RedBeatScheduler --app=myproject.celery:app ). Sayangnya saya tidak dapat membagikan kode yang berhubungan dengan pekerjaan, tetapi saya dengan senang hati menjawab pertanyaan tambahan tentang implementasi secara umum.

@mikeschaekermann Anda bisa mencoba membungkus seledri Anda dengan /use/bin/flock untuk mengunci akses ...

flock /nfs/lock.file celery beat ...

Dengan asumsi Anda mempercayai implementasi kunci NFS Anda :)

Ini akan memastikan hanya satu yang benar-benar berjalan dan yang lain memblokir sampai loker mati.

@mikeschaekermann Anda bisa mencoba membungkus seledri Anda dengan /use/bin/flock untuk mengunci akses ...

kawanan /nfs/lock.file seledri mengalahkan ...

Dengan asumsi Anda mempercayai implementasi kunci NFS Anda :)

Ini akan memastikan hanya satu yang benar-benar berjalan dan yang lain memblokir sampai loker mati.

Saya mencoba metode ini. Sayangnya, jika klien yang memegang kunci NFS kehilangan konektivitas ke server NFS, kunci tersebut dapat dicabut oleh server NFS dan diberikan kepada klien lain. Ketika pemegang kunci asli mendapatkan kembali konektivitas, kawanan tidak menyadari bahwa kunci telah dicabut jadi sekarang ada dua node percaya bahwa mereka adalah 'pemimpin.'

Saya akhirnya menggunakan kunci penasehat di Postgres. Saya membuat perintah manajemen Django yang menggunakan modul Django_pglocks dan menjalankan ketukan seledri dalam subproses.

Saya akhirnya menggunakan kunci penasehat di Postgres. Saya membuat perintah manajemen Django yang menggunakan modul Django_pglocks dan menjalankan ketukan seledri dalam subproses.

Ini sepertinya rentan terhadap masalah yang sama yang saya lihat dengan menggunakan NFS. Apa yang terjadi jika klien yang memegang kunci kehilangan koneksi dengan server Postgres, atau jika server Postgres dimulai ulang?

@swt2c Argh, tentu saja Anda benar! Perlu ada semacam tetap hidup.

Saat ini saya sedang melakukan:

def _pre_exec():
    prctl.set_pdeathsig(signal.SIGTERM)

with advisory_lock(LOCK_ID) as acquired:
            assert acquired
            logging.info("Lock acquired: %s", acquired)
            p = subprocess.Popen(
                celery,
                shell=False,
                close_fds=True,
                preexec_fn=_pre_exec,
            )
            sys.exit(p.wait())

advisor_lock memang mendukung rekursi, tetapi saya tidak tahu apakah itu benar-benar memeriksa db:

In [8]:  with advisory_lock('foo') as acquired:
   ...:     print acquired
   ...:     while True:
   ...:        with advisory_lock('foo') as acquired:
   ...:           print acquired
   ...:        time.sleep(1)
   ...:       

# Yes, it does:

True
True
True
<shutdown the instsance>
InterfaceError: cursor already closed

Jadi ... saya bisa memodifikasinya untuk tetap mendapatkan kembali kunci/polling dan membunuh ketukan jika gagal. Tidak menjamin pengecualian timbal balik, tetapi mungkin cukup baik untuk tujuan saya.

Untuk kasus saya, ketukan bersamaan adalah gangguan yang sia-sia, tetapi bukan masalah integritas. Jika ya, saya juga bisa membungkus tugas dengan kunci penasehat yang jika db turun, tugas tetap gagal.

Saya juga memiliki beat store jadwal di DB, tetapi belum menguji apa yang dilakukan beat ketika db turun.

@ddevlin Saya senang melihat komentar Anda karena itu adalah solusi yang saya pikirkan untuk diterapkan juga.

Namun, jika Anda dapat berbagi logika tentang bagaimana supervisor memulai ulang otomatis redbeat-1 ketika redbeat-2 turun, itu akan sangat membantu.

Ini mungkin karena kurangnya pemahaman saya tentang supervisor , tetapi tampaknya autorestart=True hanya efektif untuk program yang setidaknya masuk ke status RUNNING sekali.

Masalah saya adalah:

1. Saya memiliki dua program di supervisor.conf saya celery beat dengan redbeat.RedBeatScheduler .
2. Mulai supervisor, satu beat ( beat-1 ) mendapatkan kunci dan berjalan, sementara yang lain ( beat-2 ) mencoba untuk memulai beberapa kali dan masuk ke FATAL state (dengan kesalahan Seems we're already running? ).
3. Idealnya, jika beat-1 berhenti, maka saya ingin supervisor memulai beat-2 .
4. Namun, itu tidak terjadi karena tidak pernah dalam keadaan RUNNING untuk memulai. Yang berarti jika saya berhenti beat-1 , maka berhenti dan kemudian tidak ada yang terjadi.

Di luar kepala saya, solusinya adalah memiliki cron yang terus melakukan supervisorctl restart all setiap 5 detik atau lebih, tetapi hanya ingin mendapatkan pemikiran Anda tentang bagaimana Anda dapat mencapai redundansi itu dengan supervisor.

Hai @harisibrahimkv , masalah Anda adalah Anda memulai dua contoh ketukan seledri yang identik pada host yang sama; Saya berharap Anda melihat ERROR: Pidfile (celerybeat.pid) already exists. di log Anda untuk beat-2 ? Saya dapat melihat bahwa menjalankan dua instance celery beat pada host yang sama akan berguna untuk menguji failover di antara keduanya, tetapi untuk redundansi nyata, Anda mungkin ingin celery beat berjalan di beberapa host.

Untuk menjalankan beberapa instance pada host yang sama, minta supervisor memulainya dengan argumen --pidfile dan berikan file pid terpisah: mis.

# beat-1 
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-1.pid" ...
# beat-2
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-2.pid" ...

Kedua instance harus berhasil dimulai di bawah supervisor, tetapi jika Anda memeriksa file log, hanya satu dari mereka yang harus menjadwalkan tugas. Jika Anda menghentikan instance itu, Anda akan melihat instance lain mengambil alih penjadwalan tugas.

Tujuan kami adalah memiliki kumpulan penskalaan otomatis dari host identik yang menjalankan pekerja seledri dan pemukulan seledri di bawah pengawas. Setiap host memiliki satu contoh ketukan seledri. Dalam konfigurasi ini, celery beat harus berhasil dimulai di semua host, tetapi setiap instance celery beat yang tidak memperoleh kunci akan secara efektif menjadi siaga panas dan tidak menjadwalkan tugas (walaupun semua host di kumpulan akan memproses tugas). Jika instans dengan kunci dihentikan (misalnya saat kumpulan diperkecil, atau ketika kami melakukan peningkatan versi host di kumpulan), maka salah satu instans siaga akan memperoleh kunci dan mengambil alih tugas penjadwalan.

@ddevlin Terima kasih banyak telah

1. Bit pidfile berhasil dan saya sangat senang melihat beat-2 mengambil tugas ketika yang lain berhenti. Dapat mengkonfigurasi waktu ketukan dengan CELERYBEAT_MAX_LOOP_INTERVAL = 25 (pada seledri 3.x).

2. Ya, untuk redundansi nyata, kami berencana untuk memiliki pengaturan ini pada contoh yang berbeda sama sekali. Terima kasih telah menjelaskan penyiapan yang Anda gunakan. Akan bekerja pada itu sekarang. Pengaturan "beberapa host pada contoh yang sama", seperti yang Anda pahami dengan benar, adalah untuk memvalidasi pada awalnya apakah konsep failover berfungsi dengan pengaturan supervisor ini.

Terima kasih hangat,
Dari sebuah desa kecil di ujung paling selatan anak benua India. :)