Surveillance et sécurisation de MongoDB avec les conseillers ClusterControl

La gestion des opérations de base de données consiste à 80 % à lire et à interpréter vos systèmes de surveillance. Des centaines de métriques peuvent être interprétées et combinées de différentes manières pour vous donner des informations approfondies sur vos systèmes de base de données et sur la manière de les optimiser. Lors de l'exécution de plusieurs systèmes de bases de données, la surveillance de ces systèmes peut devenir une véritable corvée. Si l'interprétation et la combinaison des métriques prennent beaucoup de temps, ne serait-il pas formidable si cela pouvait être automatisé d'une manière ou d'une autre ?

C'est pourquoi nous avons créé des conseillers de base de données dans ClusterControl :de petits scripts qui peuvent interpréter et combiner des métriques pour vous, et vous donner des conseils le cas échéant. Pour MySQL, nous avons créé une vaste bibliothèque des vérifications de surveillance MySQL les plus couramment utilisées. Mais aussi pour MongoDB, nous avons une large bibliothèque de conseillers à votre disposition. Pour cet article de blog, nous avons sélectionné les neuf plus importants pour vous. Nous allons décrire chacun d'entre eux en détail.

Les neuf conseillers MongoDB que nous aborderons dans cet article de blog sont :

• Vérification des options de montage de disque
• Vérification numérique
• Pourcentage de blocage de la collecte (MMAP)
• Délai de réplication
• Fenêtre de réplication
• Bases de données et collections non partitionnées (cluster partitionné uniquement)
• Vérification de l'authentification activée
• Contrôle d'intégrité de l'authentification/autorisation
• Détection d'erreurs (nouveau conseiller)

Conseiller en options de montage de disque

Il est très important que vos disques soient montés de la manière la plus optimale. Avec le conseiller en options de montage de disque ClusterControl, nous examinons de plus près votre disque de données au quotidien. Dans ce conseiller, nous étudions le système de fichiers utilisé, les options de montage et les paramètres du planificateur io du système d'exploitation.

Nous vérifions si vos disques ont été montés avec noatime et nodiratime. Leur réglage réduira les performances des disques, car à chaque accès à un fichier ou à un répertoire, le temps d'accès doit être écrit sur le disque. Étant donné que cela se produit en permanence sur les bases de données, il s'agit d'un bon paramètre de performances et augmente également la durabilité de vos SSD.

Pour les systèmes de fichiers, nous vous recommandons d'utiliser des systèmes de fichiers modernes comme xfs, zfs, ext4 ou btrfs. Ces systèmes de fichiers sont créés dans un souci de performance. Il est conseillé au planificateur io d'être soit sur noop ou date limite. Date limite a été la valeur par défaut pour les bases de données pendant des années, mais grâce à un stockage plus rapide comme les SSD, le noop le planificateur a plus de sens de nos jours.

Conseiller Numa Check

Pour MongoDB, nous activons notre NUMA chèque conseiller. Ce conseiller vérifiera si NUMA (Non-Uniform Access Memory) a été activé sur votre système, et si tel est le cas, pour le désactiver.

Lorsque la mémoire à accès non uniforme a été activée, le processeur du serveur ne peut adresser directement que sa propre mémoire et non les autres processeurs de la machine. De cette façon, le processeur ne peut allouer de la mémoire qu'à partir de son propre espace mémoire, et l'allocation de tout excès entraînera une utilisation de l'échange. Cette architecture présente un fort avantage en termes de performances sur les applications multiprocesseurs qui allouent tous les processeurs, mais comme MongoDB n'est pas une application multiprocesseur, cela réduira considérablement les performances et pourrait entraîner une utilisation énorme de l'échange.

Pourcentage de verrouillage de la collecte (MMAP)

En tant que MMAP est un système de stockage basé sur des fichiers, il ne prend pas en charge le verrouillage au niveau du document tel que trouvé dans WiredTiger et RocksDB. Au lieu de cela, le niveau de verrouillage le plus bas pour MMAP est les serrures de collecte. Cela signifie que toute écriture dans une collection (insertion, mise à jour ou suppression) verrouillera toute la collection. Si le pourcentage de verrous devient trop élevé, cela indique que vous avez des problèmes de contention sur la collection. Lorsqu'il n'est pas traité correctement, cela peut entraîner un arrêt brutal de votre débit d'écriture. Par conséquent, il est très utile d'avoir un conseiller qui vous avertit à l'avance.

Conseiller de décalage de réplication MongoDB

Si vous faites évoluer MongoDB pour les lectures via des secondaires, le décalage de réplication est très important à surveiller. Les pilotes du client MongoDB n'utiliseront que des secondaires qui ne sont pas trop en retard, sinon vous risquez de diffuser des données obsolètes.

Dans MongoDB, le primaire gardera une trace de l'état de réplication de ses secondaires. Le conseiller récupère les informations de réplication et protège le délai de réplication. Si le décalage devient trop élevé, il enverra un avertissement ou un message d'état critique.

Conseiller de fenêtre de réplication MongoDB

Outre le décalage de réplication, la fenêtre de réplication est une métrique importante à surveiller. L'oplog MongoDB est une collection unique, qui a été limitée à une taille (prédéfinie). Une fois que l'oplog atteint la fin et qu'une nouvelle transaction doit être stockée, il expulsera la transaction la plus ancienne pour faire de la place pour la nouvelle transaction. La fenêtre de réplication reflète le nombre de secondes entre la transaction la plus ancienne et la plus récente dans l'oplog.

Cette métrique est très importante car vous devez savoir pendant combien de temps vous pouvez retirer un secondaire du replicaSet, avant qu'il ne puisse plus rattraper le maître en raison d'un retard trop important dans la réplication. De plus, si un secondaire commence à prendre du retard, il serait bon de savoir combien de temps nous pouvons tolérer cela avant que le secondaire ne soit plus en mesure de rattraper son retard.

Dans le shell MongoDB, une fonction est disponible pour calculer la fenêtre de réplication. Ce conseiller dans ClusterControl utilise la fonction pour effectuer le même calcul. L'avantage serait que vous puissiez maintenant être alerté sur une fenêtre de réplication trop courte.

Conseiller en bases de données et collections non partitionnées MongoDB

Dans un cluster MongoDB partitionné, toutes les bases de données et collections non partitionnées sont affectées à une partition principale par défaut par le routeur de partition MongoDB. Ce fragment principal peut varier entre les bases de données et les collections, mais en général, ce serait le fragment avec le plus d'espace disque disponible.

Avoir une base de données ou une collection non partitionnée ne présente pas immédiatement un risque pour votre cluster. Cependant, si une application ou un utilisateur commence à écrire de gros volumes de données sur l'un d'entre eux, le fragment principal pourrait se remplir rapidement et créer une panne sur ce fragment. Comme la base de données ou la collection n'est pas fragmentée, elle ne pourra pas utiliser d'autres fragments.

Pour cette raison, nous avons créé un conseiller qui empêchera que cela se produise. Le conseiller analysera toutes les bases de données et collections et vous avertira si elles n'ont pas été partitionnées.

Vérification de l'authentification activée

Sans activer l'authentification dans MongoDB, tout utilisateur se connectant sera traité comme un administrateur. Il s'agit d'un risque sérieux, car les tâches d'administration normales, telles que la création d'utilisateurs ou la création de sauvegardes, sont désormais accessibles à tous. Ceci, combiné aux serveurs MongoDB exposés, a entraîné les récents piratages de rançon de MongoDB, alors qu'une simple activation de l'authentification aurait empêché la plupart de ces cas.

Nous avons mis en place un conseiller qui vérifie si l'authentification est activée sur vos serveurs MongoDB. Cela peut être fait explicitement en définissant ceci dans la configuration, ou implicitement en activant le fichier clé de réplication. Si ce conseiller ne parvient pas à détecter que l'authentification a été activée, vous devez immédiatement agir en conséquence, car votre serveur est susceptible d'être compromis.

Vérification de l'intégrité de l'authentification/autorisation

En plus du conseiller activé pour l'authentification, nous avons également créé un conseiller qui effectue une vérification de cohérence pour l'authentification et l'autorisation dans MongoDB.

Dans MongoDB, l'authentification et l'autorisation ne sont pas placées dans un emplacement central, mais sont effectuées et stockées au niveau de la base de données. Normalement, les utilisateurs se connecteront à la base de données, s'authentifiant auprès de la base de données qu'ils ont l'intention d'utiliser. Cependant, avec les autorisations correctes, il est également possible de s'authentifier auprès d'autres bases de données (non liées) et d'utiliser toujours une autre base de données. Normalement, cela convient parfaitement, à moins qu'un utilisateur ne dispose de droits excessifs (comme le rôle d'administrateur) sur une autre base de données.

Dans ce conseiller, nous vérifions si ces rôles excessifs sont présents et s'ils pourraient constituer une menace. Nous vérifions également en même temps les mots de passe faibles et faciles à deviner.

Détection d'erreurs (nouveau conseiller)

Dans MongoDB, toute erreur rencontrée sera comptée ou enregistrée. Dans MongoDB, il existe une grande variété d'erreurs possibles :les assertions de l'utilisateur, les assertions régulières, les avertissements et même les exceptions internes du serveur. S'il existe des tendances dans ces erreurs, il est probable qu'il s'agisse d'une mauvaise configuration ou d'un problème d'application.

Ce conseiller examinera les statistiques des erreurs MongoDB (assertions) et leur donnera un sens. Nous interprétons les tendances trouvées et des conseils sur la façon de réduire les erreurs dans votre environnement MongoDB !