Xin chào, tôi là Sergey Elantsev, tôi phát triển trong Yandex.Cloud. Trước đây, tôi đã lãnh đạo việc phát triển bộ cân bằng L7 cho cổng Yandex - các đồng nghiệp nói đùa rằng dù tôi có làm gì thì hóa ra nó cũng là một bộ cân bằng. Tôi sẽ nói với độc giả của Habr cách quản lý tải trong nền tảng đám mây, công cụ mà chúng tôi coi là công cụ lý tưởng để đạt được mục tiêu này và cách chúng tôi hướng tới việc xây dựng công cụ này.
Đầu tiên xin giới thiệu một số thuật ngữ:
- VIP (IP ảo) - địa chỉ IP cân bằng
- Máy chủ, phụ trợ, phiên bản - một máy ảo chạy ứng dụng
- RIP (Real IP) - địa chỉ IP máy chủ
- Healthcheck - kiểm tra sự sẵn sàng của máy chủ
- Vùng sẵn sàng, AZ - cơ sở hạ tầng biệt lập trong trung tâm dữ liệu
- Khu vực - sự kết hợp của các AZ khác nhau
Bộ cân bằng tải giải quyết ba nhiệm vụ chính: chúng tự thực hiện việc cân bằng, cải thiện khả năng chịu lỗi của dịch vụ và đơn giản hóa việc mở rộng quy mô của dịch vụ. Khả năng chịu lỗi được đảm bảo thông qua quản lý lưu lượng tự động: bộ cân bằng giám sát trạng thái của ứng dụng và loại trừ các trường hợp cân bằng không vượt qua kiểm tra độ hoạt động khỏi quá trình cân bằng. Việc mở rộng quy mô được đảm bảo bằng cách phân bổ tải đồng đều giữa các phiên bản, cũng như cập nhật danh sách phiên bản một cách nhanh chóng. Nếu việc cân bằng không đủ đồng đều, một số phiên bản sẽ nhận được tải vượt quá giới hạn công suất và dịch vụ sẽ trở nên kém tin cậy hơn.
Bộ cân bằng tải thường được phân loại theo lớp giao thức từ mô hình OSI mà nó chạy trên đó. Cloud Balancer hoạt động ở cấp độ TCP, tương ứng với lớp thứ tư, L4.
Hãy chuyển sang phần tổng quan về kiến trúc Cân bằng đám mây. Chúng tôi sẽ tăng dần mức độ chi tiết. Chúng tôi chia các thành phần cân bằng thành ba lớp. Lớp mặt phẳng cấu hình chịu trách nhiệm tương tác với người dùng và lưu trữ trạng thái mục tiêu của hệ thống. Mặt phẳng điều khiển lưu trữ trạng thái hiện tại của hệ thống và quản lý các hệ thống từ lớp mặt phẳng dữ liệu, chịu trách nhiệm trực tiếp phân phối lưu lượng truy cập từ máy khách đến phiên bản của bạn.
Mặt phẳng dữ liệu
Lưu lượng truy cập kết thúc trên các thiết bị đắt tiền được gọi là bộ định tuyến biên. Để tăng khả năng chịu lỗi, một số thiết bị như vậy hoạt động đồng thời trong một trung tâm dữ liệu. Tiếp theo, lưu lượng truy cập đi đến bộ cân bằng, bộ này sẽ thông báo địa chỉ IP Anycast cho tất cả các AZ thông qua BGP cho khách hàng.
Lưu lượng truy cập được truyền qua ECMP - đây là chiến lược định tuyến theo đó có thể có một số tuyến tốt như nhau đến mục tiêu (trong trường hợp của chúng tôi, mục tiêu sẽ là địa chỉ IP đích) và các gói có thể được gửi dọc theo bất kỳ tuyến nào trong số đó. Chúng tôi cũng hỗ trợ công việc ở một số vùng sẵn có theo sơ đồ sau: chúng tôi quảng cáo một địa chỉ ở mỗi vùng, lưu lượng truy cập đến vùng gần nhất và không vượt quá giới hạn của nó. Ở phần sau của bài viết, chúng ta sẽ xem xét chi tiết hơn những gì xảy ra với giao thông.
Mặt phẳng cấu hình
Thành phần chính của mặt phẳng cấu hình là API, qua đó các hoạt động cơ bản với bộ cân bằng được thực hiện: tạo, xóa, thay đổi thành phần của các phiên bản, lấy kết quả kiểm tra tình trạng, v.v. Một mặt, đây là API REST và trên mặt khác, chúng tôi trong Cloud rất thường xuyên sử dụng framework gRPC, vì vậy chúng tôi “dịch” REST sang gRPC và sau đó chỉ sử dụng gRPC. Bất kỳ yêu cầu nào đều dẫn đến việc tạo ra một loạt các tác vụ bình thường không đồng bộ được thực thi trên một nhóm công nhân Yandex.Cloud chung. Nhiệm vụ được viết theo cách mà chúng có thể bị tạm dừng bất cứ lúc nào và sau đó được khởi động lại. Điều này đảm bảo khả năng mở rộng, độ lặp lại và ghi lại các hoạt động.
Do đó, tác vụ từ API sẽ đưa ra yêu cầu tới bộ điều khiển dịch vụ cân bằng, được viết bằng Go. Nó có thể thêm và xóa bộ cân bằng, thay đổi thành phần của phần phụ trợ và cài đặt.
Dịch vụ này lưu trữ trạng thái của nó trong Cơ sở dữ liệu Yandex, một cơ sở dữ liệu được quản lý phân tán mà bạn sẽ sớm có thể sử dụng. Trong Yandex.Cloud, như chúng tôi đã , khái niệm thức ăn cho chó được áp dụng: nếu chính chúng tôi sử dụng dịch vụ của mình thì khách hàng của chúng tôi cũng sẽ vui lòng sử dụng chúng. Cơ sở dữ liệu Yandex là một ví dụ về việc triển khai khái niệm như vậy. Chúng tôi lưu trữ tất cả dữ liệu của mình trong YDB và không phải suy nghĩ đến việc duy trì và mở rộng cơ sở dữ liệu: những vấn đề này đã được giải quyết cho chúng tôi, chúng tôi sử dụng cơ sở dữ liệu làm dịch vụ.
Hãy quay trở lại bộ điều khiển cân bằng. Nhiệm vụ của nó là lưu thông tin về bộ cân bằng và gửi tác vụ kiểm tra mức độ sẵn sàng của máy ảo tới bộ điều khiển kiểm tra tình trạng.
Bộ điều khiển kiểm tra sức khỏe
Nó nhận được yêu cầu thay đổi quy tắc kiểm tra, lưu chúng trong YDB, phân phối nhiệm vụ giữa các nút kiểm tra vết thương và tổng hợp kết quả, sau đó được lưu vào cơ sở dữ liệu và gửi đến bộ điều khiển cân bằng tải. Đến lượt nó, nó sẽ gửi yêu cầu thay đổi thành phần của cụm trong mặt phẳng dữ liệu tới nút cân bằng tải mà tôi sẽ thảo luận bên dưới.
Hãy nói nhiều hơn về việc kiểm tra sức khỏe. Chúng có thể được chia thành nhiều lớp. Kiểm toán có các tiêu chí thành công khác nhau. Kiểm tra TCP cần thiết lập thành công kết nối trong một khoảng thời gian cố định. Kiểm tra HTTP yêu cầu cả kết nối thành công và phản hồi với mã trạng thái 200.
Ngoài ra, séc cũng khác nhau về loại hành động - chúng chủ động và thụ động. Kiểm tra thụ động chỉ đơn giản là theo dõi những gì đang xảy ra với lưu lượng truy cập mà không thực hiện bất kỳ hành động đặc biệt nào. Điều này không hoạt động tốt trên L4 vì nó phụ thuộc vào logic của các giao thức cấp cao hơn: trên L4 không có thông tin về thời gian thực hiện thao tác hoặc việc hoàn thành kết nối tốt hay xấu. Kiểm tra hoạt động yêu cầu bộ cân bằng gửi yêu cầu đến từng phiên bản máy chủ.
Hầu hết các bộ cân bằng tải đều tự thực hiện kiểm tra hoạt động. Tại Cloud, chúng tôi quyết định tách các phần này của hệ thống để tăng khả năng mở rộng. Cách tiếp cận này sẽ cho phép chúng tôi tăng số lượng bộ cân bằng trong khi vẫn duy trì số lượng yêu cầu kiểm tra tình trạng dịch vụ. Việc kiểm tra được thực hiện bởi các nút kiểm tra tình trạng riêng biệt, qua đó các mục tiêu kiểm tra được phân chia và sao chép. Bạn không thể thực hiện kiểm tra từ một máy chủ vì nó có thể thất bại. Khi đó chúng ta sẽ không nhận được trạng thái của các instance mà anh ta đã kiểm tra. Chúng tôi thực hiện kiểm tra bất kỳ trường hợp nào từ ít nhất ba nút kiểm tra tình trạng. Chúng tôi phân chia mục đích kiểm tra giữa các nút bằng thuật toán băm nhất quán.
Việc tách biệt sự cân bằng và kiểm tra sức khỏe có thể dẫn đến nhiều vấn đề. Nếu nút kiểm tra tình trạng thực hiện các yêu cầu tới phiên bản, bỏ qua bộ cân bằng (hiện không phục vụ lưu lượng truy cập), thì sẽ xảy ra một tình huống lạ: tài nguyên dường như vẫn còn hoạt động nhưng lưu lượng truy cập sẽ không tiếp cận được nó. Chúng tôi giải quyết vấn đề này theo cách này: chúng tôi đảm bảo sẽ bắt đầu lưu lượng truy cập kiểm tra tình trạng thông qua bộ cân bằng. Nói cách khác, sơ đồ di chuyển các gói có lưu lượng truy cập từ máy khách và từ kiểm tra tình trạng khác nhau tối thiểu: trong cả hai trường hợp, các gói sẽ đến bộ cân bằng, bộ cân bằng sẽ phân phối chúng đến tài nguyên đích.
Sự khác biệt là khách hàng đưa ra yêu cầu tới VIP, trong khi Healthcheck đưa ra yêu cầu cho từng RIP riêng lẻ. Một vấn đề thú vị nảy sinh ở đây: chúng tôi mang đến cho người dùng cơ hội tạo tài nguyên trong mạng IP xám. Hãy tưởng tượng rằng có hai chủ sở hữu đám mây khác nhau đã ẩn dịch vụ của họ đằng sau bộ cân bằng. Mỗi người trong số họ có tài nguyên trong mạng con 10.0.0.1/24, có cùng địa chỉ. Bạn cần có khả năng phân biệt chúng bằng cách nào đó và ở đây bạn cần đi sâu vào cấu trúc của mạng ảo Yandex.Cloud. Tốt hơn là tìm hiểu thêm chi tiết trong , điều quan trọng đối với chúng tôi bây giờ là mạng có nhiều lớp và có các đường hầm có thể được phân biệt bằng id mạng con.
Các nút kiểm tra sức khỏe liên hệ với bộ cân bằng bằng cách sử dụng cái gọi là địa chỉ gần như IPv6. Địa chỉ gần đúng là địa chỉ IPv6 có địa chỉ IPv4 và id mạng con người dùng được nhúng bên trong nó. Lưu lượng truy cập đến bộ cân bằng, trích xuất địa chỉ tài nguyên IPv4 từ nó, thay thế IPv6 bằng IPv4 và gửi gói đến mạng của người dùng.
Lưu lượng truy cập ngược lại diễn ra theo cách tương tự: bộ cân bằng thấy rằng đích đến là mạng màu xám từ các trình kiểm tra tình trạng và chuyển đổi IPv4 sang IPv6.
VPP - trái tim của mặt phẳng dữ liệu
Bộ cân bằng được triển khai bằng công nghệ Xử lý gói Vector (VPP), một khuôn khổ của Cisco để xử lý hàng loạt lưu lượng mạng. Trong trường hợp của chúng tôi, khung này hoạt động dựa trên thư viện quản lý thiết bị mạng trong không gian người dùng - Bộ công cụ phát triển mặt phẳng dữ liệu (DPDK). Điều này đảm bảo hiệu suất xử lý gói cao: xảy ra ít gián đoạn hơn trong kernel và không có chuyển đổi ngữ cảnh giữa không gian kernel và không gian người dùng.
VPP thậm chí còn tiến xa hơn nữa và thu được nhiều hiệu năng hơn nữa từ hệ thống bằng cách kết hợp các gói thành các đợt. Hiệu suất đạt được nhờ việc sử dụng tích cực bộ nhớ đệm trên các bộ xử lý hiện đại. Cả hai bộ đệm dữ liệu đều được sử dụng (các gói được xử lý theo “vectơ”, dữ liệu gần nhau) và bộ đệm lệnh: trong VPP, việc xử lý gói tuân theo một biểu đồ, các nút chứa các chức năng thực hiện cùng một nhiệm vụ.
Ví dụ: quá trình xử lý gói IP trong VPP diễn ra theo thứ tự sau: đầu tiên, tiêu đề gói được phân tích cú pháp trong nút phân tích cú pháp, sau đó chúng được gửi đến nút, nút này sẽ chuyển tiếp các gói tiếp theo theo bảng định tuyến.
Một chút khó tính. Các tác giả của VPP không chấp nhận sự thỏa hiệp trong việc sử dụng bộ đệm của bộ xử lý, do đó, mã điển hình để xử lý một vectơ gói chứa vectơ hóa thủ công: có một vòng xử lý trong đó một tình huống như “chúng tôi có bốn gói trong hàng đợi” được xử lý, sau đó tương tự cho hai, sau đó - cho một. Hướng dẫn tìm nạp trước thường được sử dụng để tải dữ liệu vào bộ đệm nhằm tăng tốc độ truy cập vào chúng trong các lần lặp tiếp theo.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}Vì vậy, Healthchecks trao đổi qua IPv6 với VPP, biến chúng thành IPv4. Điều này được thực hiện bởi một nút trong biểu đồ mà chúng tôi gọi là NAT thuật toán. Đối với lưu lượng truy cập ngược (và chuyển đổi từ IPv6 sang IPv4), có cùng một nút NAT thuật toán.
Lưu lượng truy cập trực tiếp từ các máy khách cân bằng đi qua các nút biểu đồ, các nút này tự thực hiện việc cân bằng.
Nút đầu tiên là phiên cố định. Nó lưu trữ hàm băm của cho các phiên đã được thiết lập. 5-tuple bao gồm địa chỉ và cổng của máy khách nơi thông tin được truyền đi, địa chỉ và cổng của các tài nguyên có sẵn để nhận lưu lượng truy cập, cũng như giao thức mạng.
Hàm băm 5 bộ giúp chúng tôi thực hiện ít tính toán hơn trong nút băm nhất quán tiếp theo, cũng như xử lý tốt hơn các thay đổi danh sách tài nguyên phía sau bộ cân bằng. Khi một gói không có phiên đến bộ cân bằng, nó sẽ được gửi đến nút băm nhất quán. Đây là nơi xảy ra sự cân bằng bằng cách sử dụng hàm băm nhất quán: chúng tôi chọn một tài nguyên từ danh sách các tài nguyên “trực tiếp” có sẵn. Tiếp theo, các gói được gửi đến nút NAT, nút này thực sự thay thế địa chỉ đích và tính toán lại tổng kiểm tra. Như bạn có thể thấy, chúng tôi tuân theo các quy tắc của VPP - thích thích, nhóm các phép tính tương tự để tăng hiệu quả bộ nhớ đệm của bộ xử lý.
Băm nhất quán
Tại sao chúng tôi chọn nó và nó là gì? Đầu tiên, hãy xem xét nhiệm vụ trước đó - chọn tài nguyên từ danh sách.
Với hàm băm không nhất quán, hàm băm của gói đến sẽ được tính toán và tài nguyên được chọn từ danh sách bằng phần còn lại của việc chia hàm băm này cho số lượng tài nguyên. Miễn là danh sách không thay đổi, sơ đồ này hoạt động tốt: chúng tôi luôn gửi các gói có cùng 5 bộ dữ liệu đến cùng một phiên bản. Ví dụ: nếu một số tài nguyên ngừng phản hồi với các cuộc kiểm tra tình trạng, thì đối với một phần đáng kể của hàm băm, lựa chọn sẽ thay đổi. Các kết nối TCP của máy khách sẽ bị hỏng: một gói đã đến phiên bản A trước đó có thể bắt đầu đến phiên bản B, phiên bản này không quen thuộc với phiên của gói này.
Băm nhất quán giải quyết vấn đề được mô tả. Cách dễ nhất để giải thích khái niệm này là: hãy tưởng tượng rằng bạn có một vòng mà bạn phân phối tài nguyên theo hàm băm (ví dụ: theo IP:port). Việc chọn tài nguyên là quay bánh xe theo một góc, được xác định bởi hàm băm của gói.
Điều này giảm thiểu việc phân phối lại lưu lượng khi thành phần tài nguyên thay đổi. Việc xóa tài nguyên sẽ chỉ ảnh hưởng đến phần của vòng băm nhất quán chứa tài nguyên đó. Việc thêm tài nguyên cũng làm thay đổi việc phân phối, nhưng chúng tôi có nút phiên cố định, cho phép chúng tôi không chuyển các phiên đã thiết lập sang tài nguyên mới.
Chúng tôi đã xem xét điều gì sẽ xảy ra với lưu lượng truy cập trực tiếp giữa bộ cân bằng và tài nguyên. Bây giờ chúng ta hãy nhìn vào lưu lượng quay trở lại. Nó tuân theo mô hình tương tự như lưu lượng kiểm tra - thông qua NAT thuật toán, nghĩa là thông qua NAT 44 ngược cho lưu lượng máy khách và thông qua NAT 46 cho lưu lượng kiểm tra tình trạng. Chúng tôi tuân thủ kế hoạch riêng của mình: chúng tôi thống nhất lưu lượng truy cập kiểm tra tình trạng và lưu lượng truy cập của người dùng thực.
Nút cân bằng tải và các thành phần được lắp ráp
Thành phần của bộ cân bằng và tài nguyên trong VPP được báo cáo bởi dịch vụ cục bộ - nút cân bằng tải. Nó đăng ký luồng sự kiện từ bộ điều khiển cân bằng tải và có thể biểu thị sự khác biệt giữa trạng thái VPP hiện tại và trạng thái mục tiêu nhận được từ bộ điều khiển. Chúng tôi nhận được một hệ thống khép kín: các sự kiện từ API đến bộ điều khiển cân bằng, bộ điều khiển này sẽ giao nhiệm vụ cho bộ điều khiển kiểm tra tình trạng để kiểm tra “khả năng hoạt động” của tài nguyên. Đến lượt nó, nó sẽ giao các nhiệm vụ cho nút kiểm tra sức khỏe và tổng hợp các kết quả, sau đó nó sẽ gửi chúng trở lại bộ điều khiển cân bằng. Nút cân bằng tải đăng ký các sự kiện từ bộ điều khiển và thay đổi trạng thái của VPP. Trong hệ thống như vậy, mỗi dịch vụ chỉ biết những gì cần thiết về các dịch vụ lân cận. Số lượng kết nối bị hạn chế và chúng tôi có khả năng vận hành và mở rộng quy mô các phân khúc khác nhau một cách độc lập.
Những vấn đề nào đã được tránh?
Tất cả các dịch vụ của chúng tôi trong mặt phẳng điều khiển đều được viết bằng Go và có các đặc tính về độ tin cậy và khả năng mở rộng tốt. Go có nhiều thư viện mã nguồn mở để xây dựng hệ thống phân tán. Chúng tôi tích cực sử dụng GRPC, tất cả các thành phần đều chứa triển khai khám phá dịch vụ nguồn mở - các dịch vụ của chúng tôi giám sát hiệu suất của nhau, có thể thay đổi thành phần của chúng một cách linh hoạt và chúng tôi đã liên kết điều này với cân bằng GRPC. Về số liệu, chúng tôi cũng sử dụng giải pháp nguồn mở. Trong mặt phẳng dữ liệu, chúng tôi có hiệu suất tốt và nguồn dự trữ tài nguyên lớn: hóa ra rất khó để lắp ráp một giá đỡ mà chúng tôi có thể dựa vào hiệu suất của VPP, thay vì card mạng sắt.
Vấn đề và giải pháp
Điều gì đã không làm việc tốt như vậy? Go có quản lý bộ nhớ tự động nhưng rò rỉ bộ nhớ vẫn xảy ra. Cách dễ nhất để đối phó với chúng là chạy goroutines và nhớ chấm dứt chúng. Bài học rút ra: Theo dõi mức tiêu thụ bộ nhớ của các chương trình Go của bạn. Thông thường, một chỉ báo tốt là số lượng goroutines. Có một điểm cộng trong câu chuyện này: trong Go rất dễ lấy dữ liệu thời gian chạy - mức tiêu thụ bộ nhớ, số lượng goroutine đang chạy và nhiều tham số khác.
Ngoài ra, Go có thể không phải là lựa chọn tốt nhất cho các bài kiểm tra chức năng. Chúng khá dài dòng và cách tiếp cận tiêu chuẩn là “chạy mọi thứ trong CI theo đợt” không phù hợp lắm với chúng. Thực tế là các thử nghiệm chức năng đòi hỏi nhiều tài nguyên hơn và gây ra thời gian chờ thực sự. Do đó, các bài kiểm tra có thể thất bại do CPU đang bận kiểm tra đơn vị. Kết luận: Nếu có thể, hãy thực hiện các bài kiểm tra “nặng” tách biệt với bài kiểm tra đơn vị.
Kiến trúc sự kiện microservice phức tạp hơn một khối: việc thu thập nhật ký trên hàng chục máy khác nhau không thuận tiện lắm. Kết luận: nếu bạn tạo microservice, hãy nghĩ ngay đến việc truy tìm.
Kế hoạch của chúng tôi
Chúng tôi sẽ ra mắt bộ cân bằng nội bộ, bộ cân bằng IPv6, thêm hỗ trợ cho tập lệnh Kubernetes, tiếp tục phân chia các dịch vụ của chúng tôi (hiện tại chỉ có healthcheck-node và healthcheck-ctrl được phân chia), thêm các bài kiểm tra tình trạng mới và cũng triển khai tính năng tổng hợp các bài kiểm tra thông minh. Chúng tôi đang xem xét khả năng làm cho các dịch vụ của mình trở nên độc lập hơn nữa - để chúng không giao tiếp trực tiếp với nhau mà sử dụng hàng đợi tin nhắn. Một dịch vụ tương thích với SQS gần đây đã xuất hiện trên Đám mây .
Gần đây, Yandex Load Balancer đã được phát hành rộng rãi. Khám phá vào dịch vụ, quản lý bộ cân bằng theo cách thuận tiện cho bạn và tăng khả năng chịu lỗi cho dự án của bạn!
Nguồn: www.habr.com