Facebook công bố dịch vụ thời gian mới
(engineering.fb.com)Facebook đã công bố một dịch vụ thời gian NTP mới tại địa chỉ time.facebook.com. Dịch vụ này được cho là có độ chính xác cao hơn các dịch vụ thời gian công khai khác, đồng thời không nhận diện người dùng bằng địa chỉ IP. Facebook cũng đã đăng một bài viết liên quan đến dịch vụ này trên blog kỹ thuật của công ty. (tiếng Anh)
Lý do các công ty IT lớn như Facebook quan tâm đến dịch vụ thời gian là vì việc vận hành các hệ thống phân tán. Để xử lý giao dịch trong cơ sở dữ liệu phân tán hoặc bảo đảm ghi log chính xác, nhiều máy chủ phải đồng bộ đồng hồ với nhau ở độ chính xác cao.
Facebook đã mua thiết bị đo kiểm chuyên dụng Stratum 1 (thiết bị nhận trực tiếp thông tin thời gian từ đồng hồ nguyên tử trên vệ tinh) để thực hiện benchmark so sánh giữa ntpd, vốn lâu nay thường được dùng làm máy chủ thời gian, và chrony, một NTP daemon tương đối mới ( https://chrony.tuxfamily.org/ ). ntpd sau khi khởi động ban đầu tạm thời có sai số -10 ms rồi dần hội tụ về sai số ±1 ms, trong khi chrony cho thấy phần lớn sai số luôn nằm trong phạm vi ±0.2 ms, thể hiện độ chính xác vượt trội hơn hẳn ntpd.
chrony còn có những ưu điểm khác. Đó là hỗ trợ hardware timestamp. NTP, giao thức đồng bộ thời gian, cố gắng suy ra thời điểm hiện tại chính xác nhất có thể bằng cách đóng dấu thời gian mỗi khi gói tin qua lại giữa máy chủ và máy khách để tính độ trễ truyền đi và nhận về. Tuy nhiên, nếu không phải hệ điều hành thời gian thực thì không thể bảo đảm độ trễ của một số xử lý luôn thấp hơn một mức nhất định. Điều này cũng đúng với NTP, và trở thành một trong những nguyên nhân làm tăng sai số khi đồng bộ thời gian qua mạng.
Tuy nhiên, một số NIC (card mạng) hỗ trợ tính năng hardware timestamp. Tính năng này cho phép NIC duy trì đồng hồ riêng bằng phần cứng riêng biệt và xử lý timestamp ngay trên đó, nên độ trễ xử lý chỉ ở mức vài nano giây. Nếu ở trong môi trường mạng cục bộ và cả máy chủ NTP lẫn máy khách đều hỗ trợ hardware timestamp, tức là trong điều kiện lý tưởng, thì việc đồng bộ thời gian với sai số dưới 1 micro giây cũng có thể thực hiện được. Trên thực tế, dịch vụ thời gian không hoạt động trong môi trường mạng cục bộ và NIC phía máy khách cũng có thể không hỗ trợ hardware timestamp, nên khó có thể kỳ vọng đến mức đó; dù vậy, kết quả benchmark khi kết hợp chrony với tính năng hardware timestamp cho thấy phần lớn sai số đồng bộ thời gian nằm trong khoảng ±0.1 ms.
Vì vậy, Facebook cho biết họ cung cấp dịch vụ thời gian công khai với cấu hình bật hardware timestamp trong chrony. Các máy chủ thời gian công khai khác như của Google hay Apple đôi khi có sai số vượt quá ±2 ms, trong khi dịch vụ của Facebook phần lớn nằm trong phạm vi dưới ±1 ms. Tham khảo thêm, dịch vụ này được vận hành với các endpoint đặt tại 5 khu vực khác nhau. Hãy xem bài viết gốc để biết thêm chi tiết.
7 bình luận
Wow. Đây là một bài viết rất thú vị. Những nỗ lực để đạt độ chính xác đã được chia sẻ vừa ngắn gọn(?) vừa chi tiết. Đọc xong bài này, tôi đã đổi máy chủ NTP trên Mac của mình thành
time3.facebook.com.Tôi đang dùng
time1.facebook.com. Khi thử ping thì từ endpoint thứ 2 đến thứ 5 либо không ping được, hoặc rất chậm. Khi cấu hìnhtime1.facebook.comlàm máy chủ thời gian trong chrony, sai số ước tính hiển thị là hơn một chút so với ±1 ms. Còn nếu chỉ đặttime.facebook.comthì lại không nhận được thời gian.Xin nói thêm, các máy chủ thời gian khác như
time.google.comhaytime.windows.comđều cho sai số trên 30 ms mà không có ngoại lệ. Điều này cũng tương tự với các NTP pool nhưkr.pool.ntp.org. Trong số các máy chủ thời gian tôi từng thấy cho đến nay, máy có sai số thời gian nhỏ nhất làntp.postech.ac.kr, một máy chủ Stratum 1, nhưngchronycũng ước tính nó ở mức khoảng ±5 ms.Gần đây tôi phát hiện ra rằng nếu đặt
time.apple.comlàm Pool trong chrony thì nó sẽ bắt được các máy chủ NTP độ chính xác cao ở Hàn Quốc và Nhật Bản. Thậm chí còn hiện là Stratum 1. Có vẻ như Apple gắn bộ thu GPS vào các máy chủ CDN của họ rồi dùng chúng làm máy chủ thời gian.Ồ, thú vị thật. Cụm từ at Facebook scale giờ cũng đã trở nên quen thuộc rồi.
Nói chuyện ngoài lề một chút, tôi thấy bài này không được đăng lên Twitter của GeekNews; không biết có điều kiện riêng nào cho các tin mà bot Twitter đăng không?
À, kiểm tra lại thì hóa ra ở phần cắt bớt theo số ký tự trước khi đăng, do URL nằm ngay đầu nội dung bị tự động chuyển thành liên kết nên vượt quá số ký tự và Twitter API đã báo lỗi, hu hu.
Trên Twitter thì URL dù thế nào cũng bị quy đổi thành khoảng 22 byte.
Có lẽ phải sửa phần này thôi, hức.