Làm thế nào để thiết lập cụm ElasticSearch với tự động mở rộng trên Amazon EC2?

Question

Có hướng dẫn tuyệt vời elasticsearch on ec2 về định cấu hình ES trên Amazon EC2. Tôi đã nghiên cứu và áp dụng tất cả các khuyến nghị.

Bây giờ tôi có AMI và có thể chạy bất kỳ số lượng nút nào trong cụm từ AMI này. Tự động phát hiện được định cấu hình và các nút tham gia cụm như chúng thực sự cần.

Câu hỏi là Cách định cấu hình cụm theo cách mà tôi có thể tự động khởi chạy/chấm dứt các nút phụ thuộc vào tải cụm sao?

Ví dụ: tôi muốn chỉ có 1 nút đang chạy khi chúng tôi không có bất kỳ tải nào và 12 nút đang chạy trên tải cao điểm. Nhưng chờ đợi, nếu tôi chấm dứt 11 nút trong cluster những gì sẽ xảy ra với mảnh vỡ và bản sao? Làm thế nào để đảm bảo rằng tôi không bị mất bất kỳ dữ liệu nào trong cluster nếu tôi chấm dứt 11 nút trong số 12 nút?

Tôi có thể muốn định cấu hình S3 Gateway cho việc này. Nhưng tất cả các cổng ngoại trừ địa phương đều không được chấp nhận.

Có một bài viết trong sách hướng dẫn về shards allocation. Có thể là tôi đang thiếu một cái gì đó rất cơ bản nhưng tôi phải thừa nhận tôi không thể tìm ra nếu nó có thể cấu hình một nút để luôn luôn giữ tất cả các mảnh bản sao. Mục tiêu của tôi là đảm bảo rằng nếu đây là nút duy nhất chạy trong cụm, chúng tôi vẫn không mất bất kỳ dữ liệu nào.

Giải pháp duy nhất tôi có thể tưởng tượng bây giờ là định cấu hình chỉ mục có 12 phân đoạn và 12 bản sao. Sau đó, khi tối đa 12 nút được khởi chạy, mỗi nút sẽ có bản sao của mọi phân đoạn. Nhưng tôi không thích giải pháp này gây ra tôi sẽ phải cấu hình lại cụm nếu tôi có thể muốn có nhiều hơn thì 12 nút trên tải cao điểm.

Answer 1

Chia tỷ lệ tự động không có ý nghĩa nhiều với ElasticSearch.

Phân đoạn di chuyển và phân bổ lại không phải là quá trình nhẹ, đặc biệt nếu bạn có nhiều dữ liệu. Nó nhấn mạnh IO và mạng, và có thể làm suy giảm hiệu suất của ElasticSearch. (Nếu bạn muốn giới hạn hiệu ứng, bạn nên điều chỉnh khôi phục cụm bằng cách sử dụng các cài đặt như cluster.routing.allocation.cluster_concurrent_rebalance, indices.recovery.concurrent_streams, indices.recovery.max_size_per_sec. Điều này sẽ hạn chế tác động nhưng cũng sẽ làm chậm việc cân bằng lại và phục hồi).

Ngoài ra, nếu bạn quan tâm đến dữ liệu của mình, bạn không muốn chỉ có 1 nút. Bạn cần dữ liệu của bạn để được nhân rộng, vì vậy bạn sẽ cần ít nhất 2 nút (hoặc nhiều hơn nếu bạn cảm thấy an toàn hơn với mức nhân rộng cao hơn).

Một điều cần nhớ là trong khi bạn có thể thay đổi số lượng bản sao, bạn không thể thay đổi số lượng phân đoạn. Điều này được cấu hình khi bạn tạo chỉ mục của bạn và không thể thay đổi (nếu bạn muốn nhiều phân đoạn hơn, bạn cần phải tạo một chỉ mục khác và kết nối lại tất cả dữ liệu của bạn). Vì vậy, số lượng phân mảnh của bạn nên tính đến kích thước dữ liệu và kích thước cụm, cân nhắc số lượng nút bạn muốn cao hơn nhưng thiết lập tối thiểu của bạn (có thể ít nút giữ tất cả phân đoạn và phân phối lưu lượng ước tính?). Vì vậy, về mặt lý thuyết, nếu bạn muốn có 2 nút ở thời gian thấp và 12 nút trên đỉnh, bạn có thể thiết lập chỉ mục của bạn có 6 mảnh với 1 bản sao. Vì vậy, vào thời điểm thấp, bạn có 2 nút giữ 6 mảnh mỗi, và trên đỉnh bạn có 12 nút giữ 1 mảnh mỗi.

Nhưng một lần nữa, tôi đặc biệt khuyên bạn nên xem xét lại điều này và kiểm tra tác động của phân đoạn di chuyển trên hiệu suất cụm của bạn.

Answer 2

Trong trường hợp độ co giãn của ứng dụng được thúc đẩy bởi tải truy vấn biến, bạn có thể thiết lập nút ES được định cấu hình để không lưu trữ bất kỳ dữ liệu nào (node.data = false, http.enabled = true) và sau đó đặt chúng vào ô tô mở rộng. Các nút này có thể giảm tải tất cả xử lý sự kết hợp HTTP và kết quả từ các nút dữ liệu chính của bạn (giải phóng chúng để lập chỉ mục và tìm kiếm thêm).

Vì các nút này sẽ không có phân đoạn được phân bổ cho chúng, nên chúng sẽ tự động không phải là vấn đề và khám phá tự động sẽ cho phép chúng tham gia vào cụm.

Answer 3

Tôi nghĩ rằng đây là một mối lo ngại nói chung khi sử dụng kiến ​​trúc tự động mở rộng để đáp ứng nhu cầu tạm thời, nhưng dữ liệu vẫn cần được lưu. Tôi nghĩ rằng có một giải pháp thúc đẩy EBS

• mảnh bản đồ cho khối lượng EBS cụ thể. Giả sử chúng ta cần 15 mảnh. Chúng ta sẽ cần 15 EBS Volumes

• amazon cho phép bạn gắn kết khối lượng nhiều, vì vậy khi chúng ta bắt đầu chúng ta có thể bắt đầu với vài trường hợp có nhiều khối lượng gắn liền với chúng

• như tăng tải, chúng ta có thể quay lên thêm dụ - tối đa 15.

Giải pháp trên chỉ được đề nghị nếu bạn biết yêu cầu dung lượng tối đa của mình.

Answer 4

Tôi sẽ bị cám dỗ đề nghị giải quyết vấn đề này theo cách khác trong AWS. Tôi không biết dữ liệu ES này là gì hoặc cách cập nhật của nó ... Làm nhiều giả định tôi sẽ đặt cá thể ES đằng sau một hàm cân bằng tải ứng dụng. bạn làm điều đó thường xuyên sau đó nó sẽ được nhanh chóng để làm), sau đó dựa trên tải của máy chủ duy nhất của bạn tôi sẽ kích hoạt nhiều trường hợp được tạo ra từ các trường hợp mới nhất mà bạn có sẵn. Thêm các trường hợp mới vào ALB để chia sẻ một số tải. Khi điều này yên tĩnh xuống tôi sẽ kích hoạt việc chấm dứt các trường hợp tạm thời. Nếu bạn đi tuyến đường này dưới đây là một vài điều nữa để xem xét

• trường hợp sử dụng tại chỗ vì chúng là rẻ hơn và nếu nó phù hợp với trường hợp sử dụng của bạn
• Các chữ "T" trường hợp không phù hợp tốt ở đây vì họ cần thời gian để xây dựng tín dụng
• Sử dụng lambdas cho nhiệm vụ bật và tắt mọi thứ, nếu bạn muốn trở nên ưa thích, bạn có thể kích hoạt nó dựa trên webhook đến cổng aws
• Đưa ra nhiều giả định hơn về trường hợp sử dụng của bạn, cân nhắc đặt Máy chủ Varnish phía trước máy ES của bạn để bạn có thể cung cấp quy mô rẻ hơn dựa trên chiến lược bộ nhớ cache (nhiều giả định ở đây) dựa trên t anh ấy nhấn mạnh bạn có thể quay số trong TTL đúng để xóa bộ nhớ cache. Kiểm tra tính năng tẩy mềm cho công cụ ES của chúng tôi, chúng tôi đã nhận được rất nhiều giá trị tốt từ việc này.
• nếu bạn làm bất cứ những gì tôi đề nghị ở đây làm chắc chắn sẽ làm sinh ra ES trường hợp của bạn báo cáo bất kỳ bản ghi lại đến một nơi địa chỉ trung tâm trên máy ES dai dẳng, do đó bạn không bị mất bản ghi khi máy chết