Serveurs syslog externes dans StorageGRID
Suggérer des modifications
PDF
Un serveur syslog externe est un serveur situé en dehors de StorageGRID que vous pouvez utiliser pour centraliser les informations du journal des audits système en un seul endroit. L'utilisation d'un serveur syslog externe vous permet de réduire le trafic réseau sur vos nœuds d'administration et de gérer ces informations plus efficacement. Pour StorageGRID, le format des paquets de messages syslog sortants est conforme à la RFC 3164.
Les types d'informations d'audit que vous pouvez envoyer au serveur syslog externe incluent :
-
Journaux des audits contenant les messages d'audit générés lors du fonctionnement normal du système
-
Événements liés à la sécurité tels que les connexions et les élévations de privilèges à root
-
Journaux d'application susceptibles d'être demandés s'il est nécessaire d'ouvrir un ticket d'assistance pour résoudre un problème que vous avez rencontré
Quand utiliser un serveur syslog externe
Un serveur syslog externe est particulièrement utile si vous avez une grille de grande taille, utilisez plusieurs types d'applications S3 ou souhaitez conserver toutes les données du journal des audits. L'envoi des informations du journal des audits à un serveur syslog externe vous permet de :
-
Collectez et gérez plus efficacement les informations du journal des audits telles que les messages d'audit, les journaux d'application et les événements de sécurité.
-
Réduisez le trafic réseau sur vos nœuds d'administration car les informations du journal des audits sont transférées directement des différents nœuds de stockage vers le serveur syslog externe, sans passer par un nœud d'administration.
Lorsque des journaux sont envoyés à un serveur syslog externe, les journaux uniques supérieurs à 8 192 octets sont tronqués à la fin du message afin de se conformer aux limitations courantes des implémentations de serveurs syslog externes. 
Pour maximiser les options de restauration des données en cas de défaillance du serveur syslog externe, jusqu'à 20 Go de journaux locaux d'audit ( localaudit.logsont conservés sur chaque nœud.
Comment configurer un serveur syslog externe
Pour savoir comment configurer un serveur syslog externe, consultez "Configurer la gestion des journaux et le serveur syslog externe".
Si vous prévoyez de configurer le protocole TLS ou RELP/TLS, vous devez disposer des certificats suivants :
-
Certificats d'autorité de certification du serveur : Un ou plusieurs certificats d'autorité de certification de confiance pour vérifier le serveur syslog externe au format PEM. Si ce paramètre est omis, le certificat d'autorité de certification Grid par défaut sera utilisé.
-
Certificat client : Le certificat client pour l’authentification auprès du serveur syslog externe au format PEM.
-
Clé privée du client : clé privée du certificat client au format PEM.
Si vous utilisez un certificat client, vous devez également utiliser une clé privée client. Si vous fournissez une clé privée chiffrée, vous devez également fournir la phrase secrète. Il n'y a aucun avantage significatif en matière de sécurité à utiliser une clé privée chiffrée, car la clé et la phrase secrète doivent être stockées ; il est recommandé, pour plus de simplicité, d'utiliser une clé privée non chiffrée, si disponible.
Comment estimer la taille du serveur syslog externe
Normalement, la taille de votre grid est calculée pour atteindre un débit requis, exprimé en opérations S3 par seconde ou en octets par seconde. Par exemple, vous pouvez avoir une exigence selon laquelle votre grid doit gérer 1 000 opérations S3 par seconde, ou 2 000 Mo par seconde, d'ingestion et de récupération d'objets. Vous devez dimensionner votre serveur syslog externe en fonction des besoins en données de votre grid.
Cette section fournit quelques formules heuristiques qui vous aident à estimer le débit et la taille moyenne des messages de journalisation de différents types que votre serveur syslog externe doit être capable de gérer, exprimés en fonction des caractéristiques de performance connues ou souhaitées de la grille (opérations S3 par seconde).
Utilisez les opérations S3 par seconde dans les formules d'estimation
Si votre grille a été dimensionnée pour un débit exprimé en octets par seconde, vous devez convertir ce dimensionnement en opérations S3 par seconde pour utiliser les formules d'estimation. Pour convertir le débit de la grille, vous devez d'abord déterminer la taille moyenne de vos objets, ce que vous pouvez faire à l'aide des informations contenues dans les journaux des audits et les métriques existants (le cas échéant), ou en vous basant sur votre connaissance des applications qui utiliseront StorageGRID. Par exemple, si votre grille a été dimensionnée pour atteindre un débit de 2 000 Mo/s et que la taille moyenne de vos objets est de 2 Mo, alors votre grille a été dimensionnée pour pouvoir gérer 1 000 opérations S3 par seconde (2 000 Mo / 2 Mo).
|
|
Les formules de dimensionnement des serveurs syslog externes présentées dans les sections suivantes fournissent des estimations pour des cas courants (plutôt que pour des cas extrêmes). Selon votre configuration et votre charge de travail, vous pouvez observer un taux de messages syslog ou un volume de données syslog supérieur ou inférieur à celui prévu par les formules. Les formules sont destinées à être utilisées uniquement comme lignes directrices. |
Formules d'estimation pour les journaux des audits
Si vous ne disposez d'aucune information sur votre charge de travail S3, hormis le nombre d'opérations S3 par seconde que votre grid est censé prendre en charge, vous pouvez estimer le volume des journaux des audits que votre serveur syslog externe devra gérer à l'aide des formules suivantes, en supposant que vous laissez les niveaux d'audit définis sur les valeurs par défaut (toutes les catégories définies sur Normal, sauf Storage, qui est défini sur Error) :
Audit Log Rate = 2 x S3 Operations Rate Audit Log Average Size = 800 bytes
Par exemple, si votre grille est dimensionnée pour 1 000 opérations S3 par seconde, votre serveur syslog externe doit être dimensionné pour prendre en charge 2 000 messages syslog par seconde et doit être capable de recevoir (et généralement de stocker) des données du journal des audits à un débit de 1,6 Mo par seconde.
Si vous connaissez mieux votre charge de travail, des estimations plus précises sont possibles. Pour les journaux des audits, les variables supplémentaires les plus importantes sont le pourcentage d'opérations S3 de type PUT (par rapport à GETS) et la taille moyenne, en octets, des champs S3 suivants (les abréviations à 4 caractères utilisées dans le tableau sont les noms des champs du journal des audits) :
| Code | Champ | Description |
|---|---|---|
SACC |
Nom du compte locataire S3 (expéditeur de la requête) |
Nom du compte locataire de l'utilisateur ayant envoyé la requête. Vide pour les requêtes avec accès anonyme. |
SBAC |
Nom du compte locataire S3 (propriétaire du compartiment) |
Nom du compte locataire du propriétaire du compartiment. Utilisé pour identifier l'accès inter-comptes ou l'accès anonyme. |
S3BK |
compartiment S3 |
Le nom du compartiment S3. |
S3KY |
Clé S3 |
Le nom de la clé S3, sans le nom du compartiment. Les opérations sur les compartiments n'incluent pas ce champ. |
Utilisons P pour représenter le pourcentage d'opérations S3 qui sont des PUT, où 0 ≤ P ≤ 1 (donc pour une charge de travail PUT à 100 %, P = 1, et pour une charge de travail GET à 100 %, P = 0).
Soit K la taille moyenne de la somme des noms de compte S3, du compartiment S3 et de la clé S3. Supposons que le nom de compte S3 soit toujours my-s3-account (13 octets), que les compartiments aient des noms de longueur fixe comme /my/application/bucket-12345 (28 octets), et que les objets aient des clés de longueur fixe comme 5733a5d7-f069-41ef-8fbd-13247494c69c (36 octets). Alors, la valeur de K est 90 (13+13+28+36).
Si vous pouvez déterminer les valeurs de P et K, vous pouvez estimer le volume des journaux des audits que votre serveur syslog externe devra gérer à l'aide des formules suivantes, en supposant que vous laissez les niveaux d'audit définis sur les valeurs par défaut (toutes les catégories définies sur Normal, sauf Storage, qui est défini sur Error) :
Audit Log Rate = ((2 x P) + (1 - P)) x S3 Operations Rate Audit Log Average Size = (570 + K) bytes
Par exemple, si votre grille est dimensionnée pour 1 000 opérations S3 par seconde, que votre charge de travail est composée à 50 % d’opérations PUT et que les noms de vos comptes S3, de vos compartiments et de vos objets font en moyenne 90 octets, votre serveur syslog externe doit être dimensionné pour prendre en charge 1 500 messages syslog par seconde et doit être capable de recevoir (et généralement de stocker) des données du journal des audits à un débit d’environ 1 Mo par seconde.
Formules d'estimation pour les niveaux de journal des audits non par défaut
Les formules fournies pour les journaux des audits supposent l'utilisation des paramètres de niveau d'audit par défaut (toutes les catégories sont définies sur Normal, sauf Storage, qui est défini sur Error). Il n'existe pas de formules détaillées pour estimer le taux et la taille moyenne des messages d'audit pour des paramètres de niveau d'audit autres que ceux par défaut. Cependant, le tableau suivant peut être utilisé pour effectuer une estimation approximative du taux ; vous pouvez utiliser la formule de taille moyenne fournie pour les journaux des audits, mais sachez qu'elle risque de conduire à une surestimation, car les messages d'audit « supplémentaires » sont, en moyenne, plus petits que les messages d'audit par défaut.
| Condition | Formule |
|---|---|
Réplication : tous les niveaux du journal des audits sont définis sur Débogage ou Normal |
Taux du journal des audits = 8 x Taux d'opérations S3 |
Code d'effacement : tous les niveaux du journal des audits sont définis sur Débogage ou Normal |
Utilisez la même formule que pour les paramètres par défaut |
Formules d'estimation des événements de sécurité
Les incidents de sécurité ne sont pas corrélés aux opérations S3 et génèrent généralement un volume négligeable de journaux et de données. Pour ces raisons, aucune formule d'estimation n'est fournie.
Formules d'estimation pour les journaux d'application
Si vous ne disposez d'aucune information sur votre charge de travail S3 autre que le nombre d'opérations S3 par seconde que votre grille est censée prendre en charge, vous pouvez estimer le volume de journaux d'applications que votre serveur syslog externe devra traiter à l'aide des formules suivantes :
Application Log Rate = 3.3 x S3 Operations Rate Application Log Average Size = 350 bytes
Ainsi, par exemple, si votre grid est dimensionnée pour 1 000 opérations S3 par seconde, votre serveur syslog externe doit être dimensionné pour prendre en charge 3 300 journaux d’application par seconde et être capable de recevoir (et de stocker) des données de journal d’application à un débit d’environ 1,2 Mo par seconde.
Si vous connaissez mieux votre charge de travail, des estimations plus précises sont possibles. Pour les journaux d'application, les variables supplémentaires les plus importantes sont la stratégie de protection des données (réplication ou code d'effacement), le pourcentage d'opérations S3 de type PUT (par rapport aux opérations GET ou autres), et la taille moyenne, en octets, des champs S3 suivants (les abréviations à 4 caractères utilisées dans le tableau sont les noms des champs du journal des audits) :
| Code | Champ | Description |
|---|---|---|
SACC |
Nom du compte locataire S3 (expéditeur de la requête) |
Nom du compte locataire de l'utilisateur ayant envoyé la requête. Vide pour les requêtes avec accès anonyme. |
SBAC |
Nom du compte locataire S3 (propriétaire du compartiment) |
Nom du compte locataire du propriétaire du compartiment. Utilisé pour identifier l'accès inter-comptes ou l'accès anonyme. |
S3BK |
compartiment S3 |
Le nom du compartiment S3. |
S3KY |
Clé S3 |
Le nom de la clé S3, sans le nom du compartiment. Les opérations sur les compartiments n'incluent pas ce champ. |
Exemples d'estimations de dimensionnement
Cette section explique des exemples d'utilisation des formules d'estimation pour les grilles avec les méthodes de protection des données :
-
Réplication
-
Code d'effacement
Si vous utilisez la réplication pour la protection des données
Soit P le pourcentage d'opérations S3 qui sont des PUT, où 0 ≤ P ≤ 1 (donc pour une charge de travail PUT à 100 %, P = 1, et pour une charge de travail GET à 100 %, P = 0).
Soit K la taille moyenne de la somme des noms de compte S3, du compartiment S3 et de la clé S3. Supposons que le nom de compte S3 soit toujours my-s3-account (13 octets), que les compartiments aient des noms de longueur fixe comme /my/application/bucket-12345 (28 octets), et que les objets aient des clés de longueur fixe comme 5733a5d7-f069-41ef-8fbd-13247494c69c (36 octets). Alors K a une valeur de 90 (13+13+28+36).
Si vous pouvez déterminer les valeurs de P et K, vous pouvez estimer le volume de journaux d'application que votre serveur syslog externe devra être capable de gérer à l'aide des formules suivantes.
Application Log Rate = ((1.1 x P) + (2.5 x (1 - P))) x S3 Operations Rate Application Log Average Size = (P x (220 + K)) + ((1 - P) x (240 + (0.2 x K))) Bytes
Ainsi, par exemple, si votre grille est dimensionnée pour 1 000 opérations S3 par seconde, que votre charge de travail est composée à 50 % de PUT, et que les noms de vos comptes S3, de vos compartiments et de vos objets font en moyenne 90 octets, votre serveur syslog externe doit être dimensionné pour prendre en charge 1 800 journaux d’application par seconde et recevra (et stockera généralement) les données d’application à un débit de 0,5 Mo par seconde.
Si vous utilisez le code d'effacement pour la protection des données
Soit P le pourcentage d'opérations S3 qui sont des PUT, où 0 ≤ P ≤ 1 (donc pour une charge de travail PUT à 100 %, P = 1, et pour une charge de travail GET à 100 %, P = 0).
Soit K la taille moyenne de la somme des noms de compte S3, du compartiment S3 et de la clé S3. Supposons que le nom de compte S3 soit toujours my-s3-account (13 octets), que les compartiments aient des noms de longueur fixe comme /my/application/bucket-12345 (28 octets), et que les objets aient des clés de longueur fixe comme 5733a5d7-f069-41ef-8fbd-13247494c69c (36 octets). Alors K a une valeur de 90 (13+13+28+36).
Si vous pouvez déterminer les valeurs de P et K, vous pouvez estimer le volume de journaux d'application que votre serveur syslog externe devra être capable de gérer à l'aide des formules suivantes.
Application Log Rate = ((3.2 x P) + (1.3 x (1 - P))) x S3 Operations Rate Application Log Average Size = (P x (240 + (0.4 x K))) + ((1 - P) x (185 + (0.9 x K))) Bytes
Ainsi, par exemple, si votre grille est dimensionnée pour 1 000 opérations S3 par seconde, que votre charge de travail est composée à 50 % de PUT, et que les noms de vos comptes S3, de vos compartiments et de vos objets font en moyenne 90 octets, votre serveur syslog externe doit être dimensionné pour prendre en charge 2 250 journaux d’application par seconde et doit être capable de recevoir (et généralement de stocker) les données d’application à un débit de 0,6 Mo par seconde.