Trang web hiện đại gần như không thể tưởng tượng được nếu không có nội dung truyền thông: hầu hết bà nội đều có điện thoại thông minh, mọi người đều sử dụng mạng xã hội và thời gian ngừng hoạt động trong quá trình bảo trì gây tốn kém cho các công ty. Dưới đây là bản ghi lại câu chuyện của công ty về cách cô ấy tổ chức việc phân phối ảnh bằng giải pháp phần cứng, những vấn đề về hiệu suất mà cô ấy gặp phải trong quá trình này, nguyên nhân gây ra chúng và cách giải quyết những vấn đề này bằng giải pháp phần mềm dựa trên Nginx, đồng thời đảm bảo khả năng chịu lỗi ở mọi cấp độ (). Chúng tôi cảm ơn các tác giả của câu chuyện của Oleg Efimova và Alexandra Dymova chia sẻ kinh nghiệm tại hội thảo .
— Hãy bắt đầu bằng phần giới thiệu nhỏ về cách chúng tôi lưu trữ và lưu vào bộ nhớ đệm ảnh. Chúng tôi có một lớp để lưu trữ chúng và một lớp để lưu trữ ảnh. Đồng thời, nếu chúng tôi muốn đạt được tỷ lệ lừa cao và giảm tải cho bộ nhớ, điều quan trọng đối với chúng tôi là mỗi ảnh của một người dùng riêng lẻ phải nằm trên một máy chủ bộ nhớ đệm. Nếu không, chúng tôi sẽ phải cài đặt số đĩa nhiều gấp nhiều lần khi chúng tôi có nhiều máy chủ hơn. Tỷ lệ lừa của chúng tôi là khoảng 99%, nghĩa là chúng tôi đang giảm tải cho bộ lưu trữ của mình xuống 100 lần và để làm được điều này, 10 năm trước, khi tất cả những thứ này đang được xây dựng, chúng tôi đã có 50 máy chủ. Theo đó, để phân phối những bức ảnh này, về cơ bản chúng tôi cần 50 miền bên ngoài mà các máy chủ này phục vụ.
Đương nhiên, câu hỏi ngay lập tức nảy sinh: nếu một trong các máy chủ của chúng tôi ngừng hoạt động và không khả dụng, chúng tôi sẽ mất phần lưu lượng truy cập nào? Chúng tôi xem xét những gì có trên thị trường và quyết định mua một phần cứng để nó có thể giải quyết mọi vấn đề của chúng tôi. Sự lựa chọn thuộc về giải pháp của công ty mạng F5 (nhân tiện, gần đây đã mua NGINX, Inc): Trình quản lý lưu lượng truy cập cục bộ BIG-IP.
Công dụng của phần cứng (LTM) này: nó là một bộ định tuyến sắt giúp dự phòng sắt cho các cổng bên ngoài của nó và cho phép bạn định tuyến lưu lượng truy cập dựa trên cấu trúc liên kết mạng, trên một số cài đặt và thực hiện kiểm tra tình trạng. Điều quan trọng đối với chúng tôi là phần cứng này có thể được lập trình. Theo đó, chúng tôi có thể mô tả logic về cách phân phát ảnh của một người dùng cụ thể từ bộ nhớ đệm cụ thể. Nó trông như thế nào? Có một phần cứng xem xét Internet trên một tên miền, một IP, thực hiện giảm tải ssl, phân tích các yêu cầu http, chọn số bộ đệm từ IRule, nơi cần truy cập và cho phép lưu lượng truy cập đến đó. Đồng thời, nó thực hiện kiểm tra tình trạng và trong trường hợp một số máy không khả dụng, tại thời điểm đó, chúng tôi đã thực hiện để lưu lượng truy cập đến một máy chủ dự phòng. Tất nhiên, từ quan điểm cấu hình, có một số sắc thái, nhưng nhìn chung mọi thứ khá đơn giản: chúng tôi đăng ký thẻ, tương ứng với một số nhất định với IP của chúng tôi trên mạng, chúng tôi nói rằng chúng tôi sẽ nghe trên cổng 80 và 443, chúng tôi nói rằng nếu máy chủ không khả dụng thì bạn cần gửi lưu lượng truy cập đến máy chủ dự phòng, trong trường hợp này là máy chủ thứ 35 và chúng tôi mô tả một loạt logic về cách phân tách kiến trúc này. Vấn đề duy nhất là ngôn ngữ lập trình phần cứng là Tcl. Nếu có ai còn nhớ điều này... ngôn ngữ này chỉ viết nhiều hơn là ngôn ngữ thuận tiện cho việc lập trình:
Chúng tôi đã nhận được gì? Chúng tôi đã nhận được một phần cứng đảm bảo tính sẵn sàng cao của cơ sở hạ tầng, định tuyến tất cả lưu lượng truy cập của chúng tôi, mang lại lợi ích sức khỏe và hoạt động bình thường. Hơn nữa, nó hoạt động khá lâu: trong 10 năm qua không có lời phàn nàn nào về nó. Vào đầu năm 2018, chúng tôi đã gửi khoảng 80 nghìn ảnh mỗi giây. Đây là khoảng 80 gigabit lưu lượng truy cập từ cả hai trung tâm dữ liệu của chúng tôi.
Nhưng…
Vào đầu năm 2018, chúng ta thấy một bức tranh xấu xí trên bảng xếp hạng: thời gian gửi ảnh tăng lên rõ rệt. Và nó không còn phù hợp với chúng tôi nữa. Vấn đề là hành vi này chỉ hiển thị trong thời gian cao điểm giao thông - đối với công ty chúng tôi, đây là đêm từ Chủ nhật đến thứ Hai. Nhưng thời gian còn lại hệ thống vẫn hoạt động bình thường, không có dấu hiệu hỏng hóc.
Tuy nhiên, vấn đề đã được giải quyết. Chúng tôi đã xác định những điểm nghẽn có thể xảy ra và bắt đầu loại bỏ chúng. Tất nhiên, trước hết, chúng tôi đã mở rộng các liên kết lên bên ngoài, tiến hành kiểm tra toàn diện các liên kết lên nội bộ và tìm ra tất cả các điểm nghẽn có thể xảy ra. Nhưng tất cả điều này không mang lại kết quả rõ ràng, vấn đề không biến mất.
Một nút thắt khác có thể xảy ra là hiệu suất của bộ nhớ đệm ảnh. Và chúng tôi quyết định rằng có lẽ vấn đề nằm ở họ. Chà, chúng tôi đã mở rộng hiệu suất - chủ yếu là các cổng mạng trên bộ đệm ảnh. Nhưng một lần nữa không có sự cải thiện rõ ràng nào được nhìn thấy. Cuối cùng, chúng tôi đã chú ý đến hiệu suất của chính LTM và ở đây chúng tôi thấy một bức tranh đáng buồn trên biểu đồ: tải trên tất cả các CPU bắt đầu diễn ra suôn sẻ, nhưng sau đó đột ngột dừng lại. Đồng thời, LTM ngừng phản hồi đầy đủ với các hoạt động kiểm tra tình trạng và liên kết lên và bắt đầu tắt chúng một cách ngẫu nhiên, dẫn đến suy giảm hiệu suất nghiêm trọng.
Tức là chúng ta đã xác định được nguồn gốc của vấn đề, xác định được điểm nghẽn. Vẫn còn phải quyết định những gì chúng ta sẽ làm.
Điều đầu tiên, rõ ràng nhất mà chúng tôi có thể làm là bằng cách nào đó hiện đại hóa LTM. Nhưng có một số sắc thái ở đây, vì phần cứng này khá độc đáo nên bạn sẽ không đến siêu thị gần nhất và mua nó. Đây là một hợp đồng riêng, một hợp đồng cấp phép riêng và sẽ mất rất nhiều thời gian. Tùy chọn thứ hai là bắt đầu tự suy nghĩ, đưa ra giải pháp của riêng bạn bằng cách sử dụng các thành phần của riêng bạn, tốt nhất là sử dụng chương trình truy cập mở. Tất cả những gì còn lại là quyết định chính xác những gì chúng tôi sẽ chọn cho việc này và chúng tôi sẽ dành bao nhiêu thời gian để giải quyết vấn đề này vì người dùng không nhận được đủ ảnh. Vì vậy, chúng ta cần phải làm tất cả những điều này thật nhanh chóng, người ta có thể nói là ngày hôm qua.
Vì nhiệm vụ nghe có vẻ giống như “làm điều gì đó nhanh nhất có thể và sử dụng phần cứng mà chúng tôi có”, nên điều đầu tiên chúng tôi nghĩ là chỉ cần loại bỏ một số máy không mạnh lắm khỏi phía trước, đặt Nginx ở đó, chúng tôi biết cách làm. làm việc và cố gắng triển khai tất cả logic giống như phần cứng đã từng làm. Trên thực tế, chúng tôi đã rời bỏ phần cứng của mình, cài đặt thêm 4 máy chủ mà chúng tôi phải cấu hình, tạo miền bên ngoài cho chúng, tương tự như cách đây 10 năm... Chúng tôi mất đi một chút tính khả dụng nếu những máy này bị hỏng, nhưng thậm chí còn ít hơn, họ đã giải quyết được vấn đề của người dùng tại địa phương.
Theo đó, logic vẫn giữ nguyên: chúng tôi cài đặt Nginx, nó có thể thực hiện giảm tải SSL, bằng cách nào đó chúng tôi có thể lập trình logic định tuyến, kiểm tra tình trạng trong cấu hình và chỉ cần sao chép logic mà chúng tôi đã có trước đó.
Hãy ngồi xuống để viết config. Lúc đầu, có vẻ như mọi thứ đều rất đơn giản, nhưng thật không may, rất khó tìm được hướng dẫn sử dụng cho từng công việc. Do đó, chúng tôi khuyên bạn không nên chỉ tìm kiếm trên Google “cách định cấu hình Nginx cho ảnh”: tốt hơn nên tham khảo tài liệu chính thức, tài liệu này sẽ hiển thị những cài đặt nào nên được chạm vào. Nhưng tốt hơn hết bạn nên tự mình chọn tham số cụ thể. Chà, mọi thứ đều đơn giản: chúng tôi mô tả các máy chủ mà chúng tôi có, chúng tôi mô tả các chứng chỉ... Nhưng trên thực tế, điều thú vị nhất chính là logic định tuyến.
Lúc đầu, đối với chúng tôi, có vẻ như chúng tôi chỉ đơn giản mô tả vị trí của mình, khớp với số lượng bộ nhớ đệm ảnh trong đó, sử dụng tay hoặc máy tạo để mô tả số lượng luồng lên mà chúng tôi cần, ở mỗi luồng lên, chúng tôi chỉ ra máy chủ mà lưu lượng truy cập sẽ đến đi và một máy chủ dự phòng - nếu máy chủ chính không có sẵn:
Nhưng có lẽ nếu mọi chuyện đơn giản như vậy thì chúng tôi sẽ về nhà và không nói gì cả. Thật không may, với các cài đặt Nginx mặc định, nói chung, đã được thực hiện qua nhiều năm phát triển và không hoàn toàn phù hợp với trường hợp này... cấu hình trông như thế này: nếu một số máy chủ ngược dòng có lỗi yêu cầu hoặc hết thời gian chờ, Nginx luôn chuyển lưu lượng truy cập sang cái tiếp theo. Hơn nữa, sau lần thất bại đầu tiên, trong vòng 10 giây, máy chủ cũng sẽ bị tắt, do nhầm lẫn hoặc do hết thời gian chờ - điều này thậm chí không thể được cấu hình theo bất kỳ cách nào. Nghĩa là, nếu chúng ta xóa hoặc đặt lại tùy chọn hết thời gian chờ trong lệnh ngược dòng, thì mặc dù Nginx sẽ không xử lý yêu cầu này và sẽ phản hồi với một số lỗi không tốt lắm nhưng máy chủ sẽ tắt.
Để tránh điều này, chúng tôi đã làm hai việc:
a) họ cấm Nginx thực hiện việc này một cách thủ công - và thật không may, cách duy nhất để làm điều này là chỉ cần đặt cài đặt lỗi tối đa.
b) chúng tôi nhớ rằng trong các dự án khác, chúng tôi sử dụng một mô-đun cho phép chúng tôi thực hiện kiểm tra tình trạng lý lịch - theo đó, chúng tôi đã thực hiện kiểm tra tình trạng khá thường xuyên để thời gian ngừng hoạt động trong trường hợp xảy ra tai nạn sẽ ở mức tối thiểu.
Thật không may, đây cũng không phải là tất cả, bởi vì theo nghĩa đen, hai tuần đầu tiên hoạt động của chương trình này đã cho thấy rằng việc kiểm tra tình trạng TCP cũng là một điều không đáng tin cậy: trên máy chủ ngược tuyến, nó có thể không phải là Nginx hoặc Nginx ở trạng thái D và ở trường hợp này kernel sẽ chấp nhận kết nối, quá trình kiểm tra sức khỏe sẽ thành công nhưng không hoạt động. Do đó, chúng tôi ngay lập tức thay thế cái này bằng http kiểm tra tình trạng, tạo một cái cụ thể, nếu nó trả về 200 thì mọi thứ đều hoạt động trong tập lệnh này. Bạn có thể thực hiện logic bổ sung - ví dụ: trong trường hợp máy chủ lưu vào bộ nhớ đệm, hãy kiểm tra xem hệ thống tệp có được gắn chính xác hay không:
Và điều này sẽ phù hợp với chúng tôi, ngoại trừ việc hiện tại mạch đã lặp lại hoàn toàn những gì phần cứng đã làm. Nhưng chúng tôi muốn làm tốt hơn. Trước đây, chúng tôi có một máy chủ dự phòng và điều này có lẽ không tốt lắm, bởi vì nếu bạn có một trăm máy chủ, thì khi một số máy chủ bị lỗi cùng một lúc, một máy chủ dự phòng khó có thể đáp ứng được tải. Do đó, chúng tôi quyết định phân phối đặt trước trên tất cả các máy chủ: chúng tôi chỉ cần thực hiện một luồng ngược riêng biệt khác, viết tất cả các máy chủ ở đó với các tham số nhất định phù hợp với tải mà chúng có thể phân phối, thêm các kiểm tra tình trạng tương tự mà chúng tôi đã có trước đây :
Vì không thể đi tới một luồng ngược khác trong một luồng ngược, nên cần phải đảm bảo rằng nếu luồng ngược chính, trong đó chúng tôi chỉ ghi lại bộ đệm ảnh chính xác, cần thiết, không có sẵn, thì chúng tôi chỉ cần đi qua error_page để dự phòng, từ nơi chúng tôi đã đi đến bản sao lưu ngược dòng:
Và bằng cách thêm bốn máy chủ theo đúng nghĩa đen, đây là những gì chúng tôi nhận được: chúng tôi đã thay thế một phần tải - chúng tôi đã xóa nó khỏi LTM sang các máy chủ này, triển khai logic tương tự ở đó, sử dụng phần cứng và phần mềm tiêu chuẩn và ngay lập tức nhận được phần thưởng mà các máy chủ này có thể được mở rộng quy mô, bởi vì chúng có thể được cung cấp một cách đơn giản theo số lượng cần thiết. Chà, điểm tiêu cực duy nhất là chúng tôi đã mất tính sẵn sàng cao cho người dùng bên ngoài. Nhưng lúc đó chúng tôi phải hy sinh điều này, vì cần phải giải quyết vấn đề ngay lập tức. Vì vậy, chúng tôi đã loại bỏ một phần tải, lúc đó là khoảng 40%, LTM cảm thấy tốt và đúng nghĩa là hai tuần sau khi sự cố bắt đầu, chúng tôi bắt đầu gửi không phải 45 nghìn yêu cầu mỗi giây mà là 55 nghìn. Trên thực tế, chúng tôi đã tăng 20% - đây rõ ràng là lưu lượng truy cập mà chúng tôi không cung cấp cho người dùng. Và sau đó, họ bắt đầu nghĩ cách giải quyết vấn đề còn lại - đảm bảo khả năng tiếp cận bên ngoài cao.
Chúng tôi đã tạm dừng một chút để thảo luận về giải pháp mà chúng tôi sẽ sử dụng cho việc này. Đã có những đề xuất nhằm đảm bảo độ tin cậy khi sử dụng DNS, sử dụng một số tập lệnh tự viết tại nhà, giao thức định tuyến động... có nhiều tùy chọn, nhưng rõ ràng là để phân phối ảnh thực sự đáng tin cậy, bạn cần phải giới thiệu một lớp khác sẽ giám sát việc này . Chúng tôi gọi những chiếc máy này là máy đạo diễn ảnh. Phần mềm chúng tôi dựa vào là Keepaliving:
Để bắt đầu, Keepaliving bao gồm những gì? Đầu tiên là giao thức VRRP, được các nhà mạng biết đến rộng rãi, nằm trên thiết bị mạng cung cấp khả năng chịu lỗi đối với địa chỉ IP bên ngoài mà máy khách kết nối. Phần thứ hai là IPVS, máy chủ ảo IP, dùng để cân bằng giữa các bộ định tuyến ảnh và đảm bảo khả năng chịu lỗi ở cấp độ này. Và thứ ba - kiểm tra sức khỏe.
Hãy bắt đầu với phần đầu tiên: VRRP - nó trông như thế nào? Có một IP ảo nhất định có mục nhập trong dns badoocdn.com, nơi khách hàng kết nối. Tại một thời điểm nào đó, chúng tôi có một địa chỉ IP trên một máy chủ. Các gói được lưu giữ chạy giữa các máy chủ bằng giao thức VRRP và nếu gói chính biến mất khỏi radar - máy chủ đã khởi động lại hoặc điều gì khác, thì máy chủ dự phòng sẽ tự động nhận địa chỉ IP này - không cần thực hiện thao tác thủ công nào. Sự khác biệt giữa master và backup chủ yếu nằm ở mức độ ưu tiên: càng cao thì khả năng máy trở thành master càng lớn. Một lợi thế rất lớn là bạn không cần phải định cấu hình địa chỉ IP trên chính máy chủ, chỉ cần mô tả chúng trong cấu hình là đủ và nếu địa chỉ IP cần một số quy tắc định tuyến tùy chỉnh, điều này được mô tả trực tiếp trong cấu hình, sử dụng cú pháp tương tự như được mô tả trong gói VRRP. Bạn sẽ không gặp phải bất kỳ điều gì lạ lẫm.
Điều này trông như thế nào trong thực tế? Điều gì xảy ra nếu một trong các máy chủ bị lỗi? Ngay sau khi bản gốc biến mất, bản sao lưu của chúng tôi sẽ ngừng nhận quảng cáo và tự động trở thành bản chính. Sau một thời gian, chúng tôi đã sửa chữa bản gốc, khởi động lại, nâng cấp Keepaliving - quảng cáo đến với mức độ ưu tiên cao hơn bản sao lưu và bản sao lưu tự động quay trở lại, xóa địa chỉ IP mà không cần thực hiện thao tác thủ công nào.
Vì vậy, chúng tôi đã đảm bảo khả năng chịu lỗi của địa chỉ IP bên ngoài. Phần tiếp theo là bằng cách nào đó cân bằng lưu lượng truy cập từ địa chỉ IP bên ngoài đến các bộ định tuyến ảnh đã chấm dứt nó. Mọi thứ khá rõ ràng với các giao thức cân bằng. Đây có thể là một vòng quay đơn giản hoặc những thứ phức tạp hơn một chút, wrr, kết nối danh sách, v.v. Điều này về cơ bản được mô tả trong tài liệu, không có gì đặc biệt. Nhưng phương thức phân phối... Ở đây chúng ta sẽ xem xét kỹ hơn lý do tại sao chúng tôi chọn một trong số chúng. Đó là NAT, Định tuyến trực tiếp và TUN. Thực tế là chúng tôi đã ngay lập tức lên kế hoạch cung cấp 100 gigabit lưu lượng truy cập từ các trang web. Nếu tính ra thì bạn cần 10 card gigabit phải không? Ít nhất, 10 thẻ gigabit trong một máy chủ đã vượt quá phạm vi của khái niệm “thiết bị tiêu chuẩn” của chúng tôi. Và sau đó chúng tôi nhớ ra rằng chúng tôi không chỉ cho đi lượng truy cập mà còn cho đi những bức ảnh.
Có gì đặc biệt? - Có sự khác biệt lớn giữa lưu lượng truy cập vào và ra. Lưu lượng vào rất nhỏ, lưu lượng đi rất lớn:
Nếu nhìn vào những biểu đồ này, bạn có thể thấy hiện tại giám đốc đang nhận khoảng 200 MB mỗi giây, đây là một ngày rất bình thường. Chúng tôi trả lại 4,500 MB mỗi giây, tỷ lệ của chúng tôi là khoảng 1/22. Rõ ràng là để cung cấp đầy đủ lưu lượng đi đến 22 máy chủ công nhân, chúng tôi chỉ cần một máy chủ chấp nhận kết nối này. Đây là nơi thuật toán định tuyến trực tiếp hỗ trợ chúng tôi.
Nó trông như thế nào? Giám đốc ảnh của chúng tôi, theo bảng của anh ấy, truyền kết nối đến bộ định tuyến ảnh. Nhưng bộ định tuyến ảnh gửi lưu lượng truy cập trực tiếp đến Internet, gửi cho khách hàng, nó không quay trở lại qua giám đốc ảnh, do đó, với số lượng máy tối thiểu, chúng tôi đảm bảo khả năng chịu lỗi hoàn toàn và bơm tất cả lưu lượng truy cập. Trong cấu hình, nó trông như thế này: chúng tôi chỉ định thuật toán, trong trường hợp của chúng tôi là một rr đơn giản, cung cấp phương thức định tuyến trực tiếp và sau đó bắt đầu liệt kê tất cả các máy chủ thực, chúng tôi có bao nhiêu máy chủ trong số đó. Điều này sẽ quyết định lưu lượng truy cập này. Nếu chúng tôi có thêm một hoặc hai máy chủ ở đó hoặc một số máy chủ thì nhu cầu đó sẽ phát sinh - chúng tôi chỉ cần thêm phần này vào cấu hình và đừng lo lắng quá nhiều. Từ phía máy chủ thực, từ phía bộ định tuyến ảnh, phương pháp này yêu cầu cấu hình tối thiểu nhất, nó được mô tả hoàn hảo trong tài liệu và không có cạm bẫy nào ở đó.
Điều đặc biệt thú vị là giải pháp như vậy không đòi hỏi phải thiết kế lại triệt để mạng cục bộ; điều này rất quan trọng đối với chúng tôi; chúng tôi phải giải quyết vấn đề này với chi phí tối thiểu. Nếu bạn nhìn vào , sau đó chúng ta sẽ thấy nó trông như thế nào. Ở đây chúng tôi có một máy chủ ảo nhất định, trên cổng 443, lắng nghe, chấp nhận kết nối, tất cả các máy chủ đang hoạt động đều được liệt kê và bạn có thể thấy rằng kết nối cho hoặc nhận đều giống nhau. Nếu nhìn vào số liệu thống kê trên cùng một máy chủ ảo, chúng ta có các gói tin đến, các kết nối đến nhưng hoàn toàn không có gói tin gửi đi. Các kết nối gửi đi sẽ trực tiếp đến máy khách. Được rồi, chúng tôi đã có thể làm mất cân bằng nó. Bây giờ, điều gì sẽ xảy ra nếu một trong các bộ định tuyến ảnh của chúng tôi bị lỗi? Suy cho cùng, sắt là sắt. Nó có thể rơi vào tình trạng hoảng loạn hạt nhân, có thể bị hỏng, nguồn điện có thể bị cháy. Bất cứ điều gì. Đây là lý do tại sao việc kiểm tra sức khỏe là cần thiết. Chúng có thể đơn giản như kiểm tra xem cổng được mở như thế nào hoặc phức tạp hơn, cho đến một số tập lệnh viết tại nhà, thậm chí sẽ kiểm tra logic nghiệp vụ.
Chúng tôi đã dừng lại ở đâu đó ở giữa: chúng tôi có yêu cầu https đến một vị trí cụ thể, tập lệnh được gọi, nếu nó phản hồi với phản hồi thứ 200, chúng tôi tin rằng mọi thứ đều ổn với máy chủ này, rằng nó vẫn hoạt động và có thể được bật khá tốt một cách dễ dàng.
Một lần nữa, điều này trông như thế nào trong thực tế? Hãy tắt máy chủ để bảo trì - chẳng hạn như flash BIOS. Trong nhật ký, chúng tôi ngay lập tức có thời gian chờ, chúng tôi thấy dòng đầu tiên, sau ba lần thử, nó được đánh dấu là "không thành công" và nó chỉ đơn giản là bị xóa khỏi danh sách.
Tùy chọn hành vi thứ hai cũng có thể thực hiện được, khi VS chỉ được đặt thành XNUMX, nhưng nếu ảnh được trả về thì tùy chọn này không hoạt động tốt. Máy chủ xuất hiện, Nginx khởi động ở đó, kiểm tra tình trạng ngay lập tức hiểu rằng kết nối đang hoạt động, mọi thứ đều ổn và máy chủ xuất hiện trong danh sách của chúng tôi và tải ngay lập tức bắt đầu được áp dụng cho nó. Không có hành động thủ công nào được yêu cầu từ người quản trị nghĩa vụ. Máy chủ khởi động lại vào ban đêm - bộ phận giám sát không gọi cho chúng tôi về việc này vào ban đêm. Họ thông báo với bạn rằng điều này đã xảy ra, mọi thứ đều ổn.
Vì vậy, theo một cách khá đơn giản, với sự trợ giúp của một số ít máy chủ, chúng tôi đã giải quyết được vấn đề về khả năng chịu lỗi bên ngoài.
Tất cả những gì còn lại cần phải nói là tất cả những điều này tất nhiên cần phải được theo dõi. Riêng biệt, cần lưu ý rằng Keepalivede, là phần mềm được viết từ lâu, có rất nhiều cách để giám sát nó, cả hai đều sử dụng kiểm tra qua DBus, SMTP, SNMP và Zabbix tiêu chuẩn. Thêm vào đó, bản thân anh ấy biết cách viết thư cho hầu hết mọi lần hắt hơi, và thành thật mà nói, có lúc chúng tôi thậm chí còn nghĩ đến việc tắt nó đi, bởi vì anh ấy viết rất nhiều thư cho bất kỳ chuyển đổi, bật, chuyển đổi lưu lượng truy cập nào, cho mọi kết nối IP, và vân vân. Tất nhiên, nếu có nhiều máy chủ, thì bạn có thể khiến mình choáng ngợp với những bức thư này. Chúng tôi giám sát nginx trên bộ định tuyến ảnh bằng các phương pháp tiêu chuẩn và việc giám sát phần cứng vẫn chưa biến mất. Tất nhiên, chúng tôi sẽ tư vấn thêm hai điều nữa: thứ nhất là kiểm tra tình trạng bên ngoài và tính khả dụng, bởi vì ngay cả khi mọi thứ đều hoạt động, trên thực tế, có lẽ người dùng không nhận được ảnh do vấn đề với nhà cung cấp bên ngoài hoặc điều gì đó phức tạp hơn. Bạn nên lưu giữ ở đâu đó trên mạng khác, ở Amazon hoặc nơi nào khác, một máy riêng biệt có thể ping máy chủ của bạn từ bên ngoài và cũng nên sử dụng tính năng phát hiện bất thường, đối với những người biết cách thực hiện công nghệ máy học phức tạp hoặc giám sát đơn giản. , ít nhất là để theo dõi xem yêu cầu có giảm mạnh hay ngược lại, tăng lên hay không. Nó cũng có thể hữu ích.
Hãy tóm tắt lại: trên thực tế, chúng tôi đã thay thế giải pháp bọc sắt, giải pháp mà đến một lúc nào đó không còn phù hợp với chúng tôi, bằng một hệ thống khá đơn giản thực hiện mọi thứ giống nhau, nghĩa là nó cung cấp khả năng chấm dứt lưu lượng HTTPS và định tuyến thông minh hơn nữa với kiểm tra sức khỏe cần thiết. Chúng tôi đã tăng tính ổn định của hệ thống này, nghĩa là chúng tôi vẫn có tính sẵn sàng cao cho từng lớp, ngoài ra chúng tôi còn nhận được phần thưởng là khá dễ dàng để mở rộng quy mô tất cả trên mỗi lớp, vì đây là phần cứng tiêu chuẩn với phần mềm tiêu chuẩn, nghĩa là , chúng tôi đã đơn giản hóa việc chẩn đoán các sự cố có thể xảy ra.
Chúng ta đã kết thúc với điều gì? Chúng tôi đã gặp sự cố trong kỳ nghỉ tháng 2018 năm 40. Trong sáu tháng đầu tiên khi đưa kế hoạch này vào hoạt động, chúng tôi đã mở rộng nó sang tất cả lưu lượng truy cập để loại bỏ tất cả lưu lượng truy cập khỏi LTM, chúng tôi chỉ tăng lưu lượng truy cập trong một trung tâm dữ liệu từ 60 gigabit lên 2018 gigabit, đồng thời cho cả năm XNUMX đã có thể gửi số ảnh nhiều hơn gần gấp ba lần mỗi giây.
Nguồn: www.habr.com