Cron outgrowing: lịch trình tiếp theo là gì? [đóng cửa]


30

Chúng tôi đã sử dụng cron trong khoảng thời gian tôi có thể nhớ để xử lý tất cả các nhu cầu lập lịch công việc của chúng tôi. Tất cả mọi thứ từ bản sao lưu trữ / ảnh chụp nhanh đến báo cáo dựa trên cơ sở dữ liệu đến báo cáo hệ thống hàng ngày đến kiểm tra giám sát đều được lên lịch trên một vài trăm máy chủ thông qua cron.

Hạn chế là khá rõ ràng: khó quản lý công việc, không có cách dễ dàng để tạo ra sự phụ thuộc (đặc biệt là trên các máy chủ khác nhau), và tất nhiên, không thể tránh khỏi việc ai đó "tạm thời" bỏ qua công việc nhưng sau đó quên xóa bình luận.

Chúng tôi đã thử cung cấp thương mại, nhưng cuối cùng nó được coi là quá đắt khi là một bước tiến từ cron.

Tôi thấy các tùy chọn khác ngoài đó, chẳng hạn như SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor dường như hướng đến các môi trường cụm lớn hơn, đồng nhất hơn với các công việc chạy trên bất kỳ số nút tương tự nào: điện toán lưới và như thế. Môi trường của chúng tôi khá hỗn tạp (nhiều Linux, AIX và FreeBSD) và chúng tôi cần tạo ra sự phụ thuộc giữa các loại hệ thống khác nhau (ví dụ: một công việc trên hộp Linux có thể cần xác định liệu một công việc trên hộp AIX có nên chạy hay không.)

Có ai có bất kỳ kinh nghiệm nào khi chuyển từ cron sang cung cấp được quản lý tập trung hơn không? Bất kỳ lời khuyên nào cho việc chọn phần mềm hoặc tốt hơn là nên đi nguồn mở hoặc thương mại?

Câu trả lời:


11

Condor, OGE và Torque đều có thể đưa bạn đến đó nhưng chỉ Condor mới có quản lý phụ thuộc tích hợp với công cụ DAGMan . DAGMan cho phép bạn thiết lập một biểu đồ tuần hoàn, có hướng, mô tả luồng công việc của bạn và người quản lý đảm nhiệm việc di chuyển qua các công việc trong quy trình công việc của bạn và đánh giá kết quả đạt / thất bại ở mỗi bước trong luồng. Condor tương đối không biết nền tảng, điều đó có nghĩa là DAGMan cũng vậy, và bạn chắc chắn có thể có một bước con chạy trên AIX khi cha mẹ chạy trên Linux hoặc Windows. DAGMan không quan tâm đến việc các công việc chạy ở đâu, chỉ là các mã thoát bị vượt qua hoặc thất bại.

Bất kỳ lời khuyên nào cho việc chọn phần mềm hoặc tốt hơn là nên đi nguồn mở hoặc thương mại?

Với một số cảnh báo tôi nghĩ rằng các cộng đồng miễn phí trong không gian này rất đáng để xem xét.

OGE đang ở trong một không gian kỳ lạ. Không còn tự do chạy biến thể GE do Oracle sản xuất và Oracle không còn đóng góp mã mà nó viết lại cho GE SCC, nhưng có một số nhánh mã đang tồn tại trong các dự án nguồn mở, miễn phí. Univa đặc biệt đã dẫn đầu về việc thuê các nhà phát triển Sun GE cũ để tiếp tục làm việc trên một biến thể GE nguồn mở, miễn phí. Grid Engine có hai thứ phù hợp với nó: dễ cài đặt, nó có thể xử lý các công việc chạy ngắn (<2 phút) mà không truyền nhiều chi phí lên lịch cho các công việc làm chậm thông lượng. Nhược điểm lớn của nó là không hỗ trợ rất tốt cho Windows. Một số người trong chúng ta đã nỗ lực để chuyển nó sang Cygwin từ nhiều năm trước, nhưng chắc chắn nó không tốt như bản địa.

Bây giờ Condor là yêu thích của tôi trong ba công nghệ bạn đã đề cập. Có một cộng đồng mạnh mẽ xung quanh Condor và phần mềm rất trưởng thành (> 20 tuổi bây giờ). Hỗ trợ hệ điều hành Windows và POSIX gốc có nghĩa là nó chạy rất tốt ở mọi nơi. DAGMan đã nói ở trên chỉ là một trong nhiều tác phẩm tuyệt vời đi kèm với Condor. Nó có thể là một liên lạc phức tạp để thiết lập, nhưng một khi nó hoạt động và nó hoạt động ổn định. Nó có một ngôn ngữ cực kỳ linh hoạt để thực hiện công việc <-> khớp máy và xây dựng quy tắc sử dụng cho tài nguyên của bạn. Nó cũng hỗ trợ cung cấp động trên máy, cho phép các công việc chọn bao nhiêu tài nguyên máy họ cần và sau đó quảng cáo lại sự khác biệt như vẫn có sẵn. Nó hỗ trợ các bộ đếm tài nguyên toàn cầu để bạn có thể hạn chế những thứ như giấy phép phần mềm. Và tất nhiên, nó có DAGMan, một công cụ cực kỳ mạnh mẽ để quản lý quy trình làm việc. Nhược điểm của Condor là chi phí lập kế hoạch cho các công việc ngắn hạn có thể là gánh nặng. Bạn muốn các công việc chạy dài hơn 2 phút một cách lý tưởng, nếu không thì việc lên lịch bắt đầu trở thành một phần lớn thời gian của công việc trong hệ thống.

Mô-men xoắn là một chút thích hợp hơn. Tôi biết ít về nó tôi sợ. Nó so sánh với Grid Engine nhiều hơn Condor. Có những tiện ích trả phí mà @warren đề cập có thể mở rộng những gì Torque cơ bản, miễn phí có thể làm.

Nếu bạn muốn dùng thử ba công nghệ và xem cách chúng hoạt động với khối lượng công việc cụ thể của mình, CycleCloud có thể tạo ra các nhóm bảo mật, ảo hóa, được định cấu hình trước với Condor, GridEngine hoặc Torque - vì vậy không mất thời gian để tìm ra thứ đó về phía bạn Sẽ là một vài đô la để tạo ra các nhóm nhỏ của mỗi công nghệ và thử chúng với khối lượng công việc đại diện. (Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho Chu kỳ tính toán, chúng tôi thực hiện Chu kỳ)


Cảm ơn vì thông tin. Condor dường như thực sự hướng đến các bộ sưu tập máy móc lớn hơn có khả năng chạy một công việc cụ thể. Vấn đề tôi gặp phải là có nhiều công việc chạy ở những địa điểm rất cụ thể, nhưng tôi cần xâu chuỗi các công việc lại với nhau để chạy theo một thứ tự cụ thể. Đây có phải là điều mà Condor có thể làm tốt không, hay sẽ đau đớn khi khiến nó hoạt động theo cách này?
Cakemox

1
Condor có thể xử lý tình huống của bạn. Bạn có thể hạn chế các công việc từ DAG theo mọi cách để chúng nhắm mục tiêu các máy hoặc phần cứng rất cụ thể trong nhóm của bạn.
Ian C.

6

Chronos trông rất hứa hẹn.

Chronos là sự thay thế của Airbnb cho cron. Nó là một bộ lập lịch phân tán và chịu lỗi chạy trên Apache Mesos. Bạn có thể sử dụng nó để sắp xếp công việc. Nó hỗ trợ các trình thực thi Mesos tùy chỉnh cũng như trình thực thi lệnh mặc định. Do đó, theo mặc định, Chronos thực thi các tập lệnh sh (trên hầu hết các hệ thống bash). Chronos có thể được sử dụng để tương tác với các hệ thống như Hadoop (bao gồm EMR), ngay cả khi các nô lệ Mesos mà việc thực thi xảy ra không được cài đặt Hadoop. Các tập lệnh bao bọc cho phép chuyển tập tin và thực thi chúng trên một máy từ xa trong nền và sử dụng các cuộc gọi lại không đồng bộ để thông báo cho Chronos về việc hoàn thành công việc hoặc thất bại.

Tôi cũng đã đạt được thành công lớn khi sử dụng Jenkins làm người thay thế. Nó xử lý các công việc thực thi trên các máy chủ từ xa khá độc đáo. Đây là một bài viết trên đó: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/


4

Trong 4,5 năm qua, tôi đã làm việc với nền tảng Tự động hóa Máy chủ của HP (nee Opsware) và phần còn lại của bộ Tối ưu hóa Công nghệ Kinh doanh (Tự động hóa Mạng, Điều phối Hoạt động, v.v.).

Đối với một môi trường đủ lớn, quản lý công việc thông qua SA là một công cụ rất khả thi (và mong muốn). Kết hợp với OO, các công việc có thể được kiểm soát thông qua quản lý kiểm soát thay đổi, bán vé, v.v.

Đây là phần không thú vị: nó đắt tiền (rất đắt tiền). Bạn có thể kiểm tra một số đề xuất trong một câu hỏi tương tự tôi đã hỏi một lúc trước: Công cụ kiểm toán và quản lý FLOSS Server .

Tôi cũng nói rằng Torque / Maui / Moab (từ tính toán thích ứng ) rất tuyệt vời: không chắc chắn về giá cả, nhưng chúng cũng là những công cụ rất linh hoạt.


Tuyên bố miễn trừ trách nhiệm - Tôi làm việc cho một đối tác của HP BTO và Thích ứng


2

LƯU Ý Một vấn đề hoàn toàn khác nhau về vấn đề!

cron cũ và clunky trong một số điều khoản nhất định.

Nếu bạn thực sự đang tìm kiếm những cách mới để lên lịch, tôi sẽ thử một sự kiện nào đó dựa trên phần mềm trung gian nhắn tin. Hãy suy nghĩ RabbitMQ với khách hàng trên mỗi máy chủ.

Phụ thuộc máy chủ liên có thể được giải quyết bằng "hàng đợi thông báo".

Các sự kiện dựa trên thời gian "thực" phức tạp hơn một chút, đó thực sự là những gì cron dành cho (và khá tốt, ít nhất là về các môi trường nhỏ). Nơi mà nó trở nên khó khăn để nắm bắt ý tưởng là để ngăn chặn những cú hích. Giống như trong: mỗi tối lúc 0100h hãy chụp nhanh. Bạn có thể thấy một số đột biến tải hoặc rất nhiều lần đăng nhập thất bại tại thời điểm đó đã phá hủy toàn bộ cơ sở hạ tầng của bạn. Nếu bạn có một hàng đợi dựa trên một cách tiếp cận, bạn sẽ nhận được ít nhất một số sai lệch miễn phí (mặc dù điều đó không được đảm bảo - trừ khi một số logic thực hiện điều đó).

Điều cần giải quyết là nếu không có các công việc dựa trên thời gian thực, bạn không thể dựa vào những thứ như: vâng, các bản sao lưu của tôi sẽ bắt đầu lúc 0200h và nếu chúng vẫn chạy vào 0400h thì có gì đó không ổn. Điều dễ làm hơn là đảm bảo rằng không có 2 công việc can thiệp nào được chạy cùng một lúc. Chỉ cần tạo một tác nhân chặn sẽ chỉ tiêu thụ một công việc tại một thời điểm.

Phần quản lý sẽ là một giao diện web đẹp, nơi các công việc có thể được gửi theo yêu cầu hoặc - bây giờ nó trở lại "cron" hoặc triển khai yêu thích của bạn về trình lập lịch thạch anh java có độ chi tiết trong vài giây AFAIK - cho phần dựa trên thời gian chỉ sử dụng cron cũ tốt :)

Xin đừng coi thường tôi là OT - đó là một khái niệm khá khó hiểu nhưng vì câu hỏi không loại trừ tiền nên người ta cũng có thể chi tiền để có được giải pháp cho các yêu cầu chính xác trong nhà bằng cách tạo ra thứ gì đó thay vì chi tiêu tiền bằng cách mua một cái gì đó mà một nhà cung cấp nghĩ rằng nó đáp ứng đầy đủ một số yêu cầu :)


Điều này rất thú vị để phân phối các công việc lớn, nhưng công việc của tôi tạm thời hơn nhiều. Tuy nhiên, tôi có một số công việc có thể được xếp hàng như thế này, vì vậy tôi sẽ ghi nhớ điều này cho những công việc đó.
Cakemox

1

Tôi đã sử dụng Espresso (Cybermation) từ CA. Không chắc chắn những gì họ gọi nó bây giờ. Tôi cũng đã sử dụng UC4. Cả hai đều làm việc, tốn rất nhiều tiền (theo sự hiểu biết của tôi) và có thể là một con gấu để duy trì, nhưng họ làm những gì nó nói trên hộp thiếc. / Chỉnh sửa - bỏ lỡ rằng bạn nói rằng các ứng dụng thương mại quá đắt. Tôi hoàn toàn có thể đồng ý, nhưng đối với một số công ty, nó đáng giá, đặc biệt là khi nó dành cho các ứng dụng kinh doanh kiếm tiền.


1

Tôi đã làm việc với Bộ lập lịch công việc nguồn mở như một tùy chọn để thay thế một crontab trung tâm dòng 2000+ trong môi trường sản xuất. Mọi thứ trở nên phức tạp với cron, đến nỗi chúng tôi không thể xác định được cửa sổ ngừng hoạt động là gì hoặc làm thế nào để đối phó với sự phụ thuộc giữa các máy chủ. Sản phẩm này đã giúp, nhưng hơi phức tạp để thiết lập.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.