2015-02-19 26 views
6

Xin chào tất cả các bạn những người sáng giá,Cụm treo trên nút lỗi

Chúng tôi hiện đang chạy một cụm sản xuất nhỏ 300 GB trên 5 nút với khoảng 30 triệu tài liệu. Tất cả mọi thứ hoạt động hoàn hảo trừ khi một nút thực sự đi xuống (tôi có nghĩa là như mạng hoặc HW thất bại).

Nói chung khi chúng tôi mất một nút, cụm trở nên nhiều hơn hoặc ít hoàn toàn không phản hồi trong vài phút. Cả hai liên quan đến lập chỉ mục và truy vấn. Đây là khóa học, ít hơn lý tưởng vì chúng tôi đã tải 24/7.

Tôi thực sự đánh giá cao một số trợ giúp để hiểu các cài đặt thực hành tốt nhất để có cụm mạnh mẽ.

Mục tiêu đầu tiên cho chúng tôi là cho cụm không trở nên không hồi đáp trong trường hợp xảy ra sự cố nút. Sau khi đọc tất cả mọi thứ tôi có thể tìm thấy trên web tôi thực sự không thể hiểu được nếu ES được thiết kế để không phản hồi cho ping_retries * ping_timeout giây hoặc nếu cụm sẽ tiếp tục yêu cầu truy vấn máy chủ ngay cả trong thời gian này. Bất cứ ai có thể giúp tôi làm sáng tỏ điều này?

Thứ hai trong trường hợp xảy ra sự cố thậm chí tệ hơn khi cụm chuyển sang trạng thái màu đỏ, có thể cho phép cụm đó vẫn phân phát các yêu cầu đọc/truy vấn không?

Tôi sẽ rất biết ơn đối với bất kỳ ai sẵn sàng giúp tôi hiểu cách thức hoạt động này hoặc những gì chúng tôi cần thay đổi để cài đặt ES mạnh mẽ hơn.

Tôi đã bao gồm cấu hình của chúng tôi ở đây:

cluster.name: clustername 
node.name: nodename 
path.data: /data 
node.master: true 
node.data: true 
discovery.zen.minimum_master_nodes: 2 
discovery.zen.ping.multicast.enabled: false 
discovery.zen.ping.multicast.ping.enabled: false 
discovery.zen.ping.unicast.enabled: true 
discovery.zen.ping.unicast.hosts: ["host1","host2","host3"] 
bootstrap.mlockall: true 
http.cors.enabled: true 
index.number_of_shards: 10 
action.disable_delete_all_indices: true 
marvel.agent.exporter.es.hosts: ["marvel:9200"] 
+1

Bạn có bao nhiêu bản sao? Bất kỳ độ bão hòa mạng nào khi cân bằng lại xảy ra? Bất kỳ thời gian chờ nào được báo cáo trong nhật ký? – Pentium10

+0

1 bản sao. Không có thời gian chờ trong nhật ký. –

+0

Bao nhiêu heap, bao nhiêu RAM trên máy, triển khai cục bộ, đám mây, loại lưu trữ nào (ssd, spinning, other), phiên bản ES, số lượng phân đoạn cho mỗi nút, bất kỳ GC cũ nào trong nhật ký, là cụm truy vấn và lập chỉ mục liên tục, tần suất lập chỉ mục và truy vấn, tại thời điểm xảy ra lỗi mạng là có bất kỳ việc lập chỉ mục hoặc truy vấn nào đang diễn ra? Ngoài ra, hãy xem đồ thị Marvel để xem liệu có bất kỳ đột biến nào trong chúng tại thời điểm xảy ra lỗi mạng hay không. Nếu có, bạn thấy chúng ở đâu và loại gai nào? –

Trả lời

1

Cụm treo trên thất bại vì giá trị fault detection timeout:

discovery.zen.fd.ping_interval: 1s -> default 1s 
discovery.zen.fd.ping_timeout: 2s -> default 30 secs 
discovery.zen.fd.ping_retries: 3 -> default 3 secs 

Có hai quá trình phát hiện lỗi chạy.

Đầu tiên là bởi chủ, ping tất cả các nút khác trong cụm và xác minh rằng chúng còn sống.

Thứ hai, mỗi nút ping để làm chủ để xác minh xem nó vẫn còn sống hay quá trình bầu cử cần phải được bắt đầu.

Với cấu hình ở trên: Nếu nút bị lỗi, Master sẽ thử lại 3 lần với thời gian chờ là 2 giây (sum = 6secs hang) thay vì 90 giây chờ (treo).

Xin lưu ý rằng tôi đang chạy cụm trên mạng cục bộ với kết nối1ms và 1Gbps, Tùy thuộc vào môi trường của bạn, bạn nên điều chỉnh cho phù hợp. Tôi đang sử dụng elasticsearch 5.1.1, bạn nên tham khảo tài liệu phiên bản của mình để biết cú pháp chính xác.

Các vấn đề liên quan