Lưu lượng truy cập hợp pháp trên mạng DDoS-Guard gần đây đã vượt quá một trăm gigabit mỗi giây. Hiện tại, 50% lưu lượng truy cập của chúng tôi được tạo ra bởi các dịch vụ web của khách hàng. Đây là hàng chục nghìn miền, rất khác nhau và trong hầu hết các trường hợp đều yêu cầu cách tiếp cận riêng lẻ.
Phần cắt bên dưới là cách chúng tôi quản lý các nút phía trước và cấp chứng chỉ SSL cho hàng trăm nghìn trang web.
Việc thiết lập giao diện cho một trang web, thậm chí là một trang rất lớn, thật dễ dàng. Chúng tôi lấy nginx hoặc haproxy hoặc lighttpd, định cấu hình nó theo hướng dẫn và quên nó đi. Nếu chúng ta cần thay đổi điều gì đó, chúng ta sẽ tải lại và quên lại.
Mọi thứ thay đổi khi bạn xử lý khối lượng lớn lưu lượng truy cập một cách nhanh chóng, đánh giá tính hợp pháp của các yêu cầu, nén và lưu vào bộ nhớ đệm nội dung của người dùng, đồng thời thay đổi các tham số vài lần mỗi giây. Người dùng muốn xem kết quả trên tất cả các nút bên ngoài ngay sau khi anh ta thay đổi cài đặt trong tài khoản cá nhân của mình. Người dùng cũng có thể tải xuống hàng nghìn (và đôi khi hàng chục nghìn) tên miền với các tham số xử lý lưu lượng truy cập riêng lẻ thông qua API. Tất cả điều này cũng sẽ hoạt động ngay lập tức ở Mỹ, ở Châu Âu và Châu Á - nhiệm vụ không phải là tầm thường nhất, vì chỉ riêng ở Moscow đã có một số nút lọc tách biệt về mặt vật lý.
Tại sao có nhiều nút lớn đáng tin cậy trên khắp thế giới?
-
Chất lượng dịch vụ dành cho lưu lượng truy cập của khách hàng - các yêu cầu từ Hoa Kỳ cần phải được xử lý tại Hoa Kỳ (bao gồm cả các cuộc tấn công, phân tích cú pháp và các điểm bất thường khác) và không được kéo đến Moscow hoặc Châu Âu, làm tăng độ trễ xử lý một cách khó lường.
-
Lưu lượng tấn công phải được bản địa hóa - các nhà khai thác vận chuyển có thể suy giảm trong các cuộc tấn công, khối lượng thường vượt quá 1Tbps. Vận chuyển lưu lượng truy cập tấn công qua các liên kết xuyên Đại Tây Dương hoặc xuyên Á không phải là một ý tưởng hay. Chúng tôi đã gặp những trường hợp thực tế khi các nhà khai thác Cấp 1 nói: “Số lượng các cuộc tấn công mà bạn nhận được là nguy hiểm đối với chúng tôi”. Đó là lý do tại sao chúng tôi chấp nhận các luồng đến càng gần nguồn của chúng càng tốt.
-
Yêu cầu nghiêm ngặt về tính liên tục của dịch vụ - các trung tâm vệ sinh không được phụ thuộc vào nhau hoặc vào các sự kiện địa phương trong thế giới đang thay đổi nhanh chóng của chúng ta. Bạn đã cắt điện toàn bộ 11 tầng của MMTS-9 trong một tuần phải không? - Không vấn đề. Không một khách hàng nào không có kết nối vật lý ở vị trí cụ thể này sẽ bị ảnh hưởng và các dịch vụ web sẽ không bị ảnh hưởng trong bất kỳ trường hợp nào.
Làm thế nào để quản lý tất cả điều này?
Cấu hình dịch vụ phải được phân phối tới tất cả các nút phía trước càng nhanh càng tốt (lý tưởng là ngay lập tức). Bạn không thể chỉ lấy và xây dựng lại cấu hình văn bản cũng như khởi động lại daemon mỗi khi thay đổi - nginx tương tự sẽ tắt các tiến trình (tắt nhân viên) thêm vài phút (hoặc có thể vài giờ nếu có phiên websocket dài).
Khi tải lại cấu hình nginx thì hình ảnh sau khá bình thường:
Về việc sử dụng bộ nhớ:
Những người lao động cũ ăn hết bộ nhớ, bao gồm cả bộ nhớ không phụ thuộc tuyến tính vào số lượng kết nối - điều này là bình thường. Khi kết nối máy khách bị đóng, bộ nhớ này sẽ được giải phóng.
Tại sao đây không phải là vấn đề khi nginx mới bắt đầu? Không có HTTP/2, không có WebSocket, không có các kết nối lớn duy trì lâu dài. 70% lưu lượng truy cập web của chúng tôi là HTTP/2, nghĩa là các kết nối rất dài.
Giải pháp rất đơn giản - không sử dụng nginx, không quản lý mặt trận dựa trên tệp văn bản và chắc chắn không gửi cấu hình văn bản nén qua các kênh xuyên Thái Bình Dương. Tất nhiên, các kênh này được đảm bảo và dành riêng, nhưng điều đó không làm cho chúng bớt xuyên lục địa hơn.
Chúng tôi có bộ cân bằng máy chủ phía trước của riêng mình, nội bộ mà tôi sẽ nói đến trong các bài viết sau. Điều chính mà nó có thể làm là áp dụng nhanh chóng hàng nghìn thay đổi cấu hình mỗi giây mà không cần khởi động lại, tải lại, tăng mức tiêu thụ bộ nhớ đột ngột, v.v. Điều này rất giống với Hot Code Reload, ví dụ như trong Erlang. Dữ liệu được lưu trữ trong cơ sở dữ liệu khóa-giá trị được phân phối theo địa lý và được các bộ truyền động phía trước đọc ngay lập tức. Những thứ kia. bạn tải lên chứng chỉ SSL thông qua giao diện web hoặc API ở Moscow và trong vài giây, chứng chỉ sẽ sẵn sàng được chuyển đến trung tâm vệ sinh của chúng tôi ở Los Angeles. Nếu chiến tranh thế giới bất ngờ xảy ra và Internet biến mất trên toàn thế giới, các nút của chúng tôi sẽ tiếp tục hoạt động tự chủ và sửa chữa bộ não phân chia ngay khi một trong các kênh chuyên dụng Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hồng Kông- Los-Los sẽ có sẵn. Angeles hoặc ít nhất một trong các lớp phủ dự phòng GRE.
Cơ chế tương tự này cho phép chúng tôi phát hành và gia hạn chứng chỉ Let's Encrypt ngay lập tức. Rất đơn giản nó hoạt động như thế này:
-
Ngay khi chúng tôi thấy ít nhất một yêu cầu HTTPS cho miền của khách hàng mà không có chứng chỉ (hoặc có chứng chỉ đã hết hạn), nút bên ngoài đã chấp nhận yêu cầu sẽ báo cáo điều này cho cơ quan chứng nhận nội bộ.
-
Nếu người dùng không cấm phát hành Let's Encrypt, cơ quan cấp chứng chỉ sẽ tạo CSR, nhận mã thông báo xác nhận từ LE và gửi nó đến tất cả các mặt trận qua kênh được mã hóa. Bây giờ bất kỳ nút nào cũng có thể xác nhận yêu cầu xác thực từ LE.
-
Trong giây lát, chúng tôi sẽ nhận được chứng chỉ và khóa riêng chính xác và gửi nó ra phía trước theo cách tương tự. Một lần nữa, không cần khởi động lại daemon
-
Trước ngày hết hạn 7 ngày, thủ tục cấp lại Giấy chứng nhận được thực hiện
Hiện tại, chúng tôi đang luân chuyển 350 nghìn chứng chỉ theo thời gian thực, hoàn toàn minh bạch đối với người dùng.
Trong các bài viết tiếp theo của loạt bài này, tôi sẽ nói về các tính năng khác của việc xử lý lưu lượng truy cập web lớn theo thời gian thực - ví dụ: về phân tích RTT bằng cách sử dụng dữ liệu không đầy đủ để cải thiện chất lượng dịch vụ cho khách hàng chuyển tuyến và nói chung về việc bảo vệ lưu lượng truy cập chuyển tuyến khỏi tấn công terabit, về phân phối và tổng hợp thông tin lưu lượng truy cập, về WAF, CDN gần như không giới hạn và nhiều cơ chế tối ưu hóa phân phối nội dung.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Bạn muốn biết điều gì đầu tiên?
-
14,3%Thuật toán phân cụm và phân tích chất lượng lưu lượng truy cập web <3
-
33,3%Nội bộ của bộ cân bằng DDoS-Guard7
-
9,5%Bảo vệ lưu lượng L3/L4 quá cảnh2
-
0,0%Bảo vệ các trang web khi lưu lượng truy cập chuyển tuyến0
-
14,3%Tường lửa ứng dụng web3
-
28,6%Bảo vệ chống phân tích cú pháp và nhấp chuột6
21 người dùng bình chọn. 6 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com