Giám sát &Bảo mật MongoDB với Cố vấn ClusterControl

Quản lý hoạt động cơ sở dữ liệu bao gồm 80% đọc và giải thích các hệ thống giám sát của bạn. Hàng trăm số liệu có thể được diễn giải và kết hợp theo nhiều cách khác nhau để cung cấp cho bạn những hiểu biết sâu sắc về hệ thống cơ sở dữ liệu của bạn và cách tối ưu hóa chúng. Khi chạy nhiều hệ thống cơ sở dữ liệu, việc giám sát các hệ thống này có thể trở thành một việc vặt. Nếu việc diễn giải và kết hợp các số liệu mất nhiều thời gian, sẽ không tuyệt nếu điều này có thể được tự động hóa theo một cách nào đó?

Đây là lý do tại sao chúng tôi tạo cố vấn cơ sở dữ liệu trong ClusterControl:các tập lệnh nhỏ có thể diễn giải và kết hợp các số liệu cho bạn, đồng thời đưa ra lời khuyên khi có thể. Đối với MySQL, chúng tôi đã tạo một thư viện mở rộng các kiểm tra giám sát MySQL được sử dụng phổ biến nhất. Nhưng đối với MongoDB, chúng tôi có một thư viện rộng lớn các cố vấn để bạn sử dụng. Đối với bài đăng trên blog này, chúng tôi đã chọn ra chín bài quan trọng nhất đối với bạn. Chúng tôi sẽ mô tả chi tiết từng điểm một.

Chín cố vấn MongoDB mà chúng tôi sẽ đề cập trong bài đăng blog này là:

• Kiểm tra các tùy chọn gắn kết đĩa
• Kiểm tra Numa
• Phần trăm khóa bộ sưu tập (MMAP)
• Độ trễ sao chép
• Cửa sổ sao chép
• Bộ sưu tập và cơ sở dữ liệu chưa được phân đoạn (chỉ dành cho cụm được phân đoạn)
• Kiểm tra đã bật xác thực
• Kiểm tra xác thực / ủy quyền
• Phát hiện lỗi (cố vấn mới)

Cố vấn tùy chọn gắn trên đĩa

Điều rất quan trọng là phải gắn các đĩa của bạn theo cách tối ưu nhất. Với cố vấn tùy chọn gắn kết đĩa ClusterControl, chúng tôi xem xét kỹ hơn đĩa dữ liệu của bạn hàng ngày. Trong cố vấn này, chúng tôi điều tra hệ thống tệp được sử dụng, các tùy chọn gắn kết và cài đặt bộ lập lịch io của hệ điều hành.

Chúng tôi kiểm tra xem các đĩa của bạn đã được gắn noatime và nodiratime hay chưa. Việc đặt những điều này sẽ làm giảm hiệu suất của đĩa, vì trên mỗi lần truy cập vào tệp hoặc thư mục, thời gian truy cập phải được ghi vào đĩa. Vì điều này xảy ra liên tục trên cơ sở dữ liệu, đây là một cài đặt hiệu suất tốt và cũng làm tăng độ bền của SSD của bạn.

Đối với hệ thống tệp, chúng tôi khuyên bạn nên sử dụng các hệ thống tệp hiện đại như xfs, zfs, ext4 hoặc btrfs. Các hệ thống tệp này được tạo ra có lưu ý đến hiệu suất. Trình lập lịch io được khuyên là ở trên noop hoặc thời hạn. Thời hạn đã là mặc định cho cơ sở dữ liệu trong nhiều năm, nhưng nhờ bộ nhớ nhanh hơn như SSD, noop ngày nay công cụ lập lịch ngày càng có ý nghĩa hơn.

Cố vấn Kiểm tra Numa

Đối với MongoDB, chúng tôi bật NUMA của chúng tôi kiểm tra cố vấn. Cố vấn này sẽ kiểm tra xem NUMA (Bộ nhớ truy cập không thống nhất) đã được bật trên hệ thống của bạn và nếu đúng như vậy, hãy tắt nó đi.

Khi Bộ nhớ Truy cập Không thống nhất được bật, CPU của máy chủ chỉ có thể xử lý trực tiếp bộ nhớ của chính nó chứ không phải các CPU khác trong máy. Bằng cách này, CPU chỉ có thể cấp phát bộ nhớ từ không gian bộ nhớ của chính nó và cấp phát bất kỳ thứ gì vượt quá sẽ dẫn đến việc sử dụng hoán đổi. Kiến trúc này có lợi ích về hiệu suất mạnh mẽ trên các ứng dụng đa xử lý phân bổ tất cả các CPU, nhưng vì MongoDB không phải là ứng dụng đa xử lý nên sẽ làm giảm hiệu suất rất nhiều và có thể dẫn đến việc sử dụng hoán đổi rất lớn.

Phần trăm khóa bộ sưu tập (MMAP)

Dưới dạng MMAP là một hệ thống lưu trữ dựa trên tệp, nó không hỗ trợ khóa cấp độ tài liệu như được tìm thấy trong WiredTiger và RocksDB. Thay vào đó, mức khóa thấp nhất cho MMAP là ổ khóa bộ sưu tập. Điều này có nghĩa là bất kỳ lần ghi nào vào bộ sưu tập (chèn, cập nhật hoặc xóa) sẽ khóa toàn bộ bộ sưu tập. Nếu phần trăm khóa ngày càng quá cao, điều này cho thấy bạn có vấn đề với bộ sưu tập. Khi không được giải quyết đúng cách, điều này có thể khiến thông lượng ghi của bạn bị đình trệ. Do đó, việc có một cố vấn cảnh báo trước cho bạn là rất hữu ích.

MongoDB Replication Lag Advisor

Nếu bạn đang mở rộng MongoDB để đọc qua thư thứ hai, thì độ trễ của bản sao là rất quan trọng cần theo dõi. Trình điều khiển ứng dụng khách MongoDB sẽ chỉ sử dụng các thứ hai không bị tụt hậu quá xa, nếu không, bạn có thể gặp rủi ro khi cung cấp dữ liệu cũ.

Bên trong MongoDB, tệp chính sẽ theo dõi trạng thái sao chép của các tệp thứ hai. Cố vấn sẽ lấy thông tin sao chép và bảo vệ độ trễ sao chép. Nếu độ trễ trở nên quá cao, nó sẽ gửi cảnh báo hoặc thông báo trạng thái quan trọng.

MongoDB Replication Window Advisor

Bên cạnh độ trễ sao chép, cửa sổ sao chép là một số liệu quan trọng cần theo dõi. Oplog MongoDB là một tập hợp duy nhất, được giới hạn ở kích thước (đặt trước). Khi oplog kết thúc và một giao dịch mới cần được lưu trữ, nó sẽ loại bỏ giao dịch cũ nhất để nhường chỗ cho giao dịch mới. Cửa sổ sao chép phản ánh số giây giữa giao dịch cũ nhất và mới nhất trong oplog.

Số liệu này rất quan trọng vì bạn cần biết bạn có thể lấy một bản sao thứ cấp ra khỏi bản sao trong bao lâu, trước khi nó không thể bắt kịp bản gốc do bị tụt hậu quá xa trong việc sao chép. Ngoài ra, nếu một trường phụ bắt đầu tụt lại phía sau, sẽ rất tốt nếu chúng ta có thể chịu đựng được điều này trong bao lâu trước khi trường phụ không thể bắt kịp được nữa.

Trong MongoDB shell, một hàm có sẵn để tính toán cửa sổ sao chép. Cố vấn này trong ClusterControl sử dụng hàm để thực hiện cùng một phép tính. Lợi ích là bây giờ bạn có thể được cảnh báo về thời lượng sao chép quá ngắn.

Cố vấn thu thập và cơ sở dữ liệu không phân đoạn MongoDB

Trong một cụm MongoDB được phân đoạn, tất cả các bộ sưu tập và cơ sở dữ liệu chưa được phân đoạn được gán cho một phân đoạn chính mặc định bởi bộ định tuyến MongoDB. Phân đoạn chính này có thể khác nhau giữa cơ sở dữ liệu và bộ sưu tập, nhưng nói chung đây sẽ là phân đoạn có nhiều dung lượng đĩa nhất hiện có.

Việc có một bộ sưu tập hoặc cơ sở dữ liệu chưa phân đoạn không gây rủi ro ngay lập tức cho cụm của bạn. Tuy nhiên, nếu một ứng dụng hoặc người dùng bắt đầu ghi khối lượng lớn dữ liệu vào một trong những phân đoạn này, phân đoạn chính có thể đầy nhanh chóng và tạo ra sự cố trên phân đoạn này. Vì cơ sở dữ liệu hoặc bộ sưu tập không được phân đoạn, nó sẽ không thể sử dụng các phân đoạn khác.

Vì lý do này, chúng tôi đã tạo một cố vấn sẽ ngăn điều này xảy ra. Cố vấn sẽ quét tất cả cơ sở dữ liệu và bộ sưu tập, đồng thời cảnh báo bạn nếu nó chưa được chia nhỏ.

Kiểm tra đã bật xác thực

Nếu không bật xác thực trong MongoDB, bất kỳ người dùng nào đăng nhập sẽ được coi là quản trị viên. Đây là một rủi ro nghiêm trọng vì các tác vụ quản trị thông thường, như tạo người dùng hoặc tạo bản sao lưu, giờ đây đã trở nên khả dụng với bất kỳ ai. Điều này kết hợp với các máy chủ MongoDB bị lộ, dẫn đến các vụ hack MongoDB đòi tiền chuộc gần đây, trong khi việc kích hoạt xác thực đơn giản sẽ ngăn chặn được hầu hết các trường hợp này.

Chúng tôi đã triển khai một cố vấn xác minh xem máy chủ MongoDB của bạn có bật xác thực hay không. Điều này có thể được thực hiện một cách rõ ràng bằng cách thiết lập điều này trong cấu hình hoặc ngầm định bằng cách bật tệp khóa nhân bản. Nếu cố vấn này không phát hiện ra xác thực đã được kích hoạt, bạn nên thực hiện ngay lập tức vì máy chủ của bạn rất dễ bị xâm phạm.

Kiểm tra tình trạng xác thực / ủy quyền

Bên cạnh trình cố vấn hỗ trợ xác thực, chúng tôi cũng đã xây dựng một cố vấn thực hiện kiểm tra độ tỉnh táo cho cả xác thực và ủy quyền trong MongoDB.

Trong MongoDB, xác thực và ủy quyền không được đặt ở vị trí trung tâm, nhưng được thực hiện và lưu trữ ở cấp cơ sở dữ liệu. Thông thường người dùng sẽ kết nối với cơ sở dữ liệu, xác thực dựa trên cơ sở dữ liệu mà họ định sử dụng. Tuy nhiên, với các khoản cấp chính xác, nó cũng có thể xác thực với các cơ sở dữ liệu khác (không liên quan) và vẫn sử dụng được cơ sở dữ liệu khác. Thông thường, điều này hoàn toàn ổn, trừ khi người dùng có quá nhiều quyền (như vai trò quản trị viên) đối với cơ sở dữ liệu khác.

Trong cố vấn này, chúng tôi xác minh xem những vai trò quá mức này có hiện diện không và liệu chúng có thể gây ra mối đe dọa hay không. Chúng tôi cũng đồng thời kiểm tra các mật khẩu yếu và dễ đoán.

Phát hiện lỗi (Cố vấn mới)

Trong MongoDB, bất kỳ lỗi nào gặp phải sẽ được tính hoặc ghi lại. Trong MongoDB có rất nhiều lỗi có thể xảy ra:xác nhận của người dùng, xác nhận thông thường, cảnh báo và thậm chí cả ngoại lệ máy chủ nội bộ. Nếu có xu hướng trong những lỗi này, có khả năng là do cấu hình sai hoặc sự cố ứng dụng.

Cố vấn này sẽ xem xét số liệu thống kê về lỗi MongoDB (xác nhận) và hiểu điều này. Chúng tôi giải thích các xu hướng được tìm thấy và lời khuyên về cách giảm lỗi trong môi trường MongoDB của bạn!