Làm cách nào để thiết lập đồng bộ hóa đồng bộ trong đám mây (AWS, heroku, v.v ...) trên nhiều nút?

Question

Tôi muốn chạy một cụm lớn các nút trong đám mây (AWS, Heroku, hoặc có thể là VMS tự quản), đồng hồ của nó phải được đồng bộ hóa với một dung sai được xác định trước trong tâm trí. Tôi đang tìm kiếm một sự khoan dung có thể là 200 ms. Điều đó có nghĩa là nếu tôi có 250 nút, chênh lệch đồng hồ lớn nhất giữa bất kỳ nút nào trong số 250 nút sẽ không bao giờ vượt quá 200 ms. Tôi không thực sự quan tâm về ngày/giờ thực tế liên quan đến thế giới. Giải pháp phải có khả năng chịu lỗi và không cần phải dựa vào tính chính xác của đồng hồ của bất kỳ hệ thống nào - thực tế, có khả năng là không có đồng hồ nào sẽ chính xác đến mức khủng khiếp.

Yêu cầu đủ mạnh, nếu vì bất kỳ lý do gì, đồng bộ hóa đồng hồ được xác định là không đáng tin cậy cho bất kỳ nút cụ thể nào, tôi muốn thả nút từ cụm do đồng bộ hóa không đồng bộ - , Tôi muốn có thể thực hiện một số loại tắt được kiểm soát của nút đó.

Tôi rất muốn sử dụng cái gì đó như NTP, nhưng theo NTP known issues twiki:

NTP không được thiết kế để chạy bên trong một máy ảo. Nó đòi hỏi một đồng hồ hệ thống có độ phân giải cao, với thời gian đáp ứng để ngắt xung nhịp được bảo trì với độ chính xác cao. Không có máy ảo nào được biết là có khả năng đáp ứng các yêu cầu này.

Và mặc dù cùng một twiki sau đó mô tả các cách khác nhau để giải quyết tình huống (như chạy ntp trên máy chủ), tôi không tin rằng mình có khả năng sửa đổi môi trường đủ bằng AWS hoặc trên horoku để tuân thủ các cách giải quyết.

Thậm chí nếu tôi không chạy trên máy ảo, người quản lý hoạt động đáng tin cậy có nhiều năm kinh nghiệm chạy ntp nói với tôi rằng ntp có thể và sẽ giảm đồng bộ hóa (hoặc đồng bộ nhận sai thời gian). một lúc. Nó không xảy ra thường xuyên, nhưng nó xảy ra, và khi bạn tăng máy móc, bạn tăng cơ hội của bạn xảy ra điều này. AFAIK, phát hiện khoảng cách bạn cần phải dừng ntpd, chạy lệnh chế độ truy vấn và bắt đầu lại sao lưu và có thể mất nhiều thời gian để nhận được câu trả lời.

Tóm lại - Tôi cần một đồng bộ hóa đồng hồ mà mục tiêu chính như sau:

• Chạy tốt trong nơi kiểm soát hoạt động được giới hạn của VM (ví dụ: "cung cấp dịch vụ điện toán đám mây")
• dung sai Time trong cụm vào khoảng 200ms giữa tất cả những người tham gia
• Khả năng phát hiện nút xấu và phản ứng với điều đó một cách chủ động
• lỗi khoan dung (không có điểm duy nhất của thất bại)
• Scalable (thứ e điều không thể đổ khi bạn thêm các nút - chắc chắn tránh n^2)
• thể hỗ trợ hàng trăm nút
• Không ai trong số các nút nên được coi là khái niệm vượt trội về thời gian đối với bất kỳ nút khác
• OK cho toàn bộ cụm trôi dạt (trong vòng lý do) - miễn là toàn bộ cụm đó trôi đi trong unison

Từ mô tả, nó có vẻ là lựa chọn đúng ở đây, nhưng nó đã được triển khai chưa?

Rất vui được giàu:

• cấu hình tối thiểu (nút tự động đăng ký tham gia) - quan trọng cho quay lên nút mới
• bảng điều khiển HTML hoặc (REST?) API mà báo cáo các nút được tham gia đồng bộ hóa đồng hồ và thời gian bù tương đối là gì
• Đồ thị đẹp?

Answer 1

Vì the FAQ for NTP nêu rõ lý do đồng bộ hóa thời gian NTP không hoạt động 'bên phải' trong máy ảo, có thể đó là vấn đề không thể khắc phục.

Hầu hết các máy đều có đồng hồ RTC (đồng hồ thời gian thực), trên máy tính cách bạn lưu trữ thời gian để bạn có thể đoán được thời gian nếu ntp không khả dụng, khi hệ thống nạp có một 'đánh dấu' đồng hồ đó là độ phân giải cao hơn - đó là những gì NTP đặt.

Đồng hồ đánh dấu đó phụ thuộc vào độ trễ của máy ảo vì có thể có hoặc không xảy ra vào khoảng thời gian chính xác - bất kỳ cơ chế thời gian nào bạn cố gắng sử dụng đều sẽ bị trôi dạt. Đây có lẽ là thiết kế tối ưu để cố gắng thực thi đồng bộ hóa ntp trên các máy ảo, nếu máy A và B có đồng bằng 200ms, và máy B và C có đồng bằng 200ms, C có thể cách xa 400 m so với A. Bạn có thể ' t kiểm soát điều đó.

Bạn nên sử dụng hệ thống nhắn tin tập trung như zeromq để giữ cho mọi người đồng bộ với hàng đợi công việc, sẽ tốn nhiều tiền hơn, nhưng dựa vào thời gian đánh dấu hệ thống là một điều tồi tệ nhất. Có nhiều giải pháp phân cụm cho phép tham gia cluster sử dụng tất cả các cơ chế đáng tin cậy để đảm bảo mọi người đồng bộ, xem corosync hoặc spread - họ đã giải quyết vấn đề này cho những thứ như cam kết hai pha.

Ngẫu nhiên, ntp 'từ bỏ' khi trôi quá cao có thể bị phá vỡ bằng cách hướng dẫn nó 'slam' thời gian tới giá trị mới thay vì 'xoay'. Theo mặc định, ntp sẽ cập nhật dần thời gian hệ thống cho tài khoản của nó trôi dạt từ 'thời gian thực'. Tôi quên cách định cấu hình này trong ntpd, nhưng nếu bạn sử dụng ntpdate cờ là -B

-B  Force the time to always be slewed using the adjtime(2) system call, even if the measured 
offset is greater than +-128 ms. The default is to step the time using settimeofday(2) if the offset 
is greater than +-128 ms. Note that, if the offset is much greater than +-128 ms in this case, it 
can take a long time (hours) to slew the clock to the correct value. During this time, the host 
should not be used to synchronize clients.