Panorama de la gestion et de l'exploitation forestière

 

 

 

 

 

La solution de Panorama est composée de deux fonctions globales : gestion des périphériques et Log Collection/Reporting. Suivi d’un bref aperçu de ces deux fonctions principales :

 

Gestion des périphériques: cela inclut des activités telles que la gestion de la configuration et le déploiement, le déploiement de Pan-OS et les mises à jour de contenu.

Collection de journaux: cela inclut la collecte de journaux à partir d'un ou plusieurs pare-feu, soit vers un panorama unique, soit vers une infrastructure de collection de journaux distribués. En plus de la collecte des journaux de pare-feu déployées, rapports peuvent être générés basé sur qui enregistrent les données si elle réside localement vers le Panorama (par ex. seule série M ou VM appliance) pour sur une infrastructure d’enregistrement distribué.

 

La solution de Panorama permet une flexibilité dans la conception en assignant ces fonctions à différents éléments physiques de l’infrastructure de gestion. Par exemple : gestion des périphériques peut être effectuée d’un Panorama de la VM, tandis que les pare-feu transmet leurs registres aux collectionneurs colocalisée journal dédié :

 

 

 

 

Dans l’exemple ci-dessus, fonction de gestion de périphérique et les rapports sont exécutées sur un appareil de machine virtuelle Panorama. Il y a trois groupes de collectionneurs de journal. Le groupe A, contient deux collecteurs de journal et reçoit des rondins de trois pare-feu autonome. Le groupe B, se compose d’un collecteur unique et reçoit des bûches d’une paire de pare-feux dans une configuration Active/Passive en haute disponibilité (HA). Groupe C contient deux collectionneurs journal aussi bien et reçoit des journaux de deux paires HA de pare-feux. Le nombre de capteurs de journal dans un lieu donné dépend de plusieurs facteurs. Les considérations de conception sont traitées ci-dessous. Remarque : n’importe quelle plateforme peut être un gestionnaire dédié, mais seulement de M-Series peut être un collectionneur journal dédié.

 

 

Collection de journaux

 

Unités gérées

 

Alors que toutes les plateformes de Panorama actuels ont une limite supérieure de 1 000 périphériques à des fins de gestion, il est important pour le dimensionnement de Panorama à comprendre quel sera le taux de journal entrants de tous les périphériques gérés. Commencer avec, faire l’inventaire des appareils pare-feu total qui sera géré par le Panorama.

 

Utilisez la feuille de calcul suivant pour effectuer un inventaire de vos périphériques qui ont besoin de stocker les journaux :

MODÈLE	PAN-OS (Major Branch #)	Emplacement	Mesuré les taux de valeur moyenne de Log
Ex : 5060	Ex : 6.1.0	Ex : Centre de données principal	Ex. 2500 billes/s

 

  

Exigences de l’exploitation forestière

 

Cette section couvrira l’information nécessaire pour correctement dimensionner et déploiement d’une infrastructure de journalisation de Panorama pour répondre aux besoins de client. Il y a trois principaux facteurs pour déterminer le volume de stockage total requis et comment répartir ce stockage par l’intermédiaire de collecteurs de journaux distribués. Ces facteurs sont :

• Exigences d’Ingestion journal : C’est le nombre total de journaux qui seront envoyés par seconde à l’infrastructure de Panorama.
• Besoins de stockage de journal : C’est la période pour laquelle le client doit conserver les journaux sur la plate-forme de gestion. Il existe différents facteurs pour ce, y compris les deux politique fondée et des motivations de conformité réglementaire.
• Emplacement du périphérique : L’emplacement physique des pare-feu peut conduire à la décision de placer les appareils DLC dans des lieux éloignés, basés sur la bande passante WAN etc..

 

Chacun de ces facteurs sont discutés dans les sections ci-dessous :

 

Exigences d’Ingestion de journal

 

Le taux d'acheminement des journaux globaux pour les périphériques gérés doit être compris afin de avoID une conception où plus de journaux sont régulièrement envoyés à Panorama qu'il ne peut recevoir, traiter et écrire sur le disque. Le tableau ci-dessous décrit le nombre maximal de journaux par seconde que chaque plate-forme matérielle peut transmettre à Panorama et peut être utilisé lors de la conception d'un solutisur pour calculer le nombre maximal de journaux qui peuvent être transférés à Panorama dans l'environnement client.

 

         Dispositif Log transfert

Plate-forme	Prise en charge de billes par seconde (LPS)
PA-200	250
PA-220	1 200
PA-500	625
PA-820/850	10 000
PA-3000 séries	10 000
PA-3220	7 000
PA-3250	15 000
PA-3260	24 000
PA-5050/60	10 000
PA-5220	30 000
PA-5250	55 000
PA-5260	À tester
PA-7050/7080	70 000
VM-50	1 250
VM-100/200	2 500
VM-300/1000-HV	8 000
VM-500	8 000
VM-700	10 000

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Le taux d’ingestion journal Panorama est influencé par la plate-forme et le mode utilisé (mode mixte versets enregistreur mode). Le tableau ci-dessous montre le taux d’ingestion de Panorama sur les différentes plateformes disponibles et les modes de fonctionnement.  Les nombres entre parenthèses à côté de VM dénotent le nombre de CPU et gigaoctets de RAM affectés à la VM.

 

 

 

       Ingestion de journal Panorama

Plate-forme	Mixte	Dédié
VM (8/16)	10 000	18 000
M-200	10 000	28 000
M-500	15 000	30 000
M-600	25 000	50 000

 

Les chiffres ci-dessus sont toutes les valeurs maximales. Dans les déploiements de direct, le taux de journal proprement est généralement une fraction de la valeur maximale prise en charge. Détermination du taux réel journal est fortement tributaire de la composition du trafic du client et n’est pas nécessairement liée au débit. Par exemple, une seule session SMB déchargée sera montrer haut débit mais seulement génèrent un journal de trafic. À l’inverse, vous pouvez avoir un débit plus faible composé de milliers de UDP DNS requêtes que chacun générer un trafic distinct se connecter. Pour le dimensionnement, une corrélation approximative peut être établie entre les connexions par seconde et billes par seconde.

 

 

Méthodes pour la détermination des taux de Log

Nouveau client :

• Exploiter les informations provenant de sources de client existant. De nombreux clients ont une solution de journalisation de tierce partie tels que Splunk, ArcSight, Qradar, etc.. Le nombre de journaux envoyés à partir de leur solution de pare-feu existant peut tiré de ces systèmes. Lorsque vous utilisez cette méthode, obtenez un décompte du journal de la solution tierce pour une journée complète et diviser par 86 400 (nombre de secondes dans une journée). Cela pendant plusieurs jours pour obtenir une moyenne. N’oubliez pas d’inclure les professionnels et les jours non ouvrables, qu’il y a habituellement un écart important taux de journaux entre les deux.
• Utiliser les données de dispositif d’évaluation. Cette information peut fournir un point de départ très utile pour des fins de dimensionnement et, avec l’apport de la clientèle, les données peuvent être extrapolées pour d’autres sites dans la même conception.  Cette méthode a l’avantage de donner lieu à une moyenne sur plusieurs jours. Un script (avec consignes) pour aider à calculer trouvera cette information est jointe au présent document. Pour l'utiliser, téléchargez le fichier nommé "ts_lps. zip". Décompresser le fichier zip et le fichier README.txt pour les instructions de référence.
• Si aucune information n’est disponible, utilisez le tableau dispositif Log Forwarding ci-dessus comme point de référence. Ce sera la méthode la moins précise pour un client particulier.

Déjà client :

    Pour les clients existants, nous pouvons exploiter les données recueillies par leurs pare-feu existants et les collectionneurs de journal :

• Pour vérifier le taux de log d'un seul pare-feu, téléchargez le fichier joint nommé "Dappareil. zip", décompressez le fichier zip et référencez le fichier Readme. txt pour des instructions. Ce paquet interrogera un seul pare-feu pendant une période déterminée de temps (vous pouvez choisir combien d’échantillons) et donnent un nombre moyen de billes par seconde pour la même période. Au minimum, ce script doit être exécuté pendant 24 heures consécutives par jour ouvrable. L'exécution du script pendant une semaine complète aidera à capturer le reflux cyclique et le flux du réseau. Si le client n’a pas un collectionneur de journal, ce processus devront être exécutées sur chaque pare-feu dans l’environnement.
• Si le client dispose d'un collecteur de journaux (ou de collecteurs de journaux), téléchargez le fichier joint nommé "lc_lps. zip", décompressez le fichier zip et référencez le fichier Readme. txt pour les instructions ce paquet va interroger le collecteur de journaux MiB pour prendre un échantillon du journal entrant taux sur une période donnée.

 

Exigences de stockage des journaux

 

Facteurs qui influent sur les besoins de stockage de journal

Il sont a plusieurs facteurs que lecteur journal des conditions de stockage. La plupart de ces exigences est de nature réglementaire. Les clients peuvent ont besoin répondre aux exigences de conformité HIPAA, Sarbanes-Oxely ou PCI.

 

 

• Exigence de PCI DSS 10,7
• Loi Sarbanes-Oxley, section 802
• HIPAA - § 164.316(b)(2)(i)

 

Il existe d’autres normes gouvernementales et de l’industrie qu’il faudra considérer. En outre, certaines entreprises ont des besoins internes. Par exemple : un certain nombre de jours une valeur de journaux une note sur la plate-forme de gestion originale. Veiller à ce que toutes ces conditions sont adressés par le client lors de la conception d’une solution de stockage de journal.

 

Focus est sur le nombre de jours minumum de journaux qui doit être stocké. S'il y a un nombre maximal de jours requis (en raison d'une réglementation ou d'une stratégie), vous pouvez définir le nombre maximal de jours pour conserver les journaux dans la configuration du quota.

 

Calcul de stockage requis

Le calcul de l'espace de stockage requis basé sur les exigences d'un client donné est assez simple processus, mais peut être un travail intensif en obtenant des degrés plus élevés de précision. Avec Pan-OS 8,0, la taille agrégée de tous les types de journaux est de 500 octets. Ce nombre représente aussi bien les journaux eux-mêmes ainsi que les indices associés. La base de données de menace est la source de données pour les journaux de menace comme URL, mémoires d’une traînée de poudre, et filtrage de données se connecte.

    Notez que nous ne soyons pas la solution de journalisation pour d’archivage à long terme.  Dans ces cas suggèrent Syslog expédition à des fins d’archivage. 

 

 

 

L’équation pour déterminer les besoins de stockage pour le type de journal particulier est :

 

Exemple : Le client souhaite pouvoir garder 30 jours de grumes de trafic avec un taux de journal de 1500 billes par seconde :

 

 

 

 

 

 

Le résultat du calcul ci-dessus ne compte que pour les journaux détaillés. Avec les paramètres de quota par défaut, réservez 60% du stockage disponible pour les journaux détaillés. Cela signifie que le nombre calculé représente 60% du stockage total qui devra être acheté. Pour calculer le stockage total requis, dévidez ce numéro par. 60:

 

 

 

Les quotas de journal par défaut pour panorama 8,0 et ultérieurs sont les suivants:

 

Type de journal	% De stockage
Journaux de pare-feu détaillés	60
Journaux de pare-feu Sommaire	30
L’infrastructure et des journaux d’Audit	5
Palo Alto Networks plate-forme journaux	.1
3 rd party journaux externes	.1

 

 

 La feuille ci-jointe va prendre en compte le quota par défaut sur le Panorama et prévoir un montant total de stockage nécessaire.

 

 

 

Calcul de stockage requis pour le Service de journalisation

 

Il existe trois cas différents pour le dimensionnement des collection de journal en utilisant le Service d’enregistrement. Pour les instructions de dimensionnement en profondeur, reportez-vous au stockage de dimensionnement pour le service de journalisation.

 

1. Collection du journal pour la prochaine génération pare-feu de Palo Alto Networks
2. Collection de journal pour l’utilisateur Mobile de services de Cloud GlobalProtect
3. Collection de journaux pour GlobalProtect Cloud Service Bureau à distance

 

 

Collection de journaux pour Palo Alto prochaine génération pare-feux

Le journal de méthodologie pour les pare-feu de connexion pour le Service d’enregistrement de dimensionnement est le même lors du dimensionnement des collecteurs de journal local. La seule différence est la taille du journal sur le disque. Dans le service de journalisation, les journaux de menaces et de trafic peuvent être calculés à l'aide d'une taille de 1500 octets. 

 

Collection de journal pour l’utilisateur Mobile de services de Cloud GlobalProtect

Par connexion utilisateur génération dépend fortement tant le type d’utilisateur que les charges de travail en cours d’exécution dans cet environnement. En moyenne, 1 to de stockage sur le Service d’enregistrement fournira 30 jours de rétention pour 5000 utilisateurs. Un avantage de la fonction de journalisation est que l’ajout de stockage est beaucoup plus simple à faire que dans un traditionnel sur environnement distribué de collection de site. Cela signifie que si votre environnement est beaucoup plus occupé que la moyenne, c’est une simple question d’ajouter le stockage est nécessaire pour répondre à vos exigences de rétention.

 

Collection de journaux pour GlobalProtect Cloud Service Bureau à distance

GlobalProtect Cloud Service (PDC) pour les bureaux distants est vendu basé sur la bande passante. Alors que le taux de journal repose en grande partie par mélange de trafic et des taux de connexion, dans l’entreprise exemple environnements Connectez-vous génération se produit à un rythme d’environ 1,5 billes par seconde par mégabit de débit. La feuille de travail ci-joint dimensionnement utilise ce taux et prend en compte occupé/arrêt heures afin de fournir un taux log moyenne estimée.

 

 

 

 

 

Quotas de stockage LogDB

 

Quotas de stockage ont été simplifiées à partir de PAN-OS version 8.0. Détail et sommaires des journaux ont chacun leur propre quota, quel que soit le type (trafic/menaces) :

 

Type de journal	Quota (%)
Journaux de pare-feu détaillés	60
Journaux de pare-feu Sommaire	30
L’infrastructure et des journaux d’Audit	5
Palo Alto Networks plate-forme journaux	.1
3 rd party journaux externes	.1
Total	95.2

 

 

 

Emplacement du périphérique

La dernière considération de conception pour l’infrastructure de journalisation est emplacement des pare-feu par rapport à la plate-forme Panorama qu’ils sont connectent à. Si l’appareil est séparé du Panorama par un segment de réseau à vitesse réduite (par exemple T1/E1), il est recommandé de placer un collecteur de journal dédié (DLC) sur le site avec le pare-feu. Cela permet de transfert de journal se limiter au segment LAN vitesse supérieur tout en permettant à Panorama interroger le collecteur de journal lorsque nécessaire. Pour référence, les tableaux suivants montre la consommation de bande passante pour l’envoi de journaux à des taux différents journaux. Cela inclut les deux journaux envoyés à Panorama et la reconnaissance du Panorama pour le pare-feu. Notez que pour la 7000 série et 5200 série, journaux sont comprimés pendant la transmission.

 

        Ouvrez une session transfert de bande passante

Journal des taux (LPS)	Bande passante utilisée
1300	8 Mbit/s
8000	56 MB/s
10000	64 Mbit/s
16000	52.8-140,8 Mbit/s (96,8)

 

 

Connectez-vous à bande passante de transfert - série 7000 et 5200

Journal des taux (LPS)	Bande passante utilisée
1300	.6 Mbit/s
8000	4 Mbit/s
10000	4.5 MB/s
16000	5 - 10 Mbit/s

 

 

 

 

 

Gestion des périphériques

Il y a plusieurs facteurs à considérer lors du choix d’une plate-forme pour un déploiement de Panorama. Les facteurs initiaux incluent :

• Nombre d’administrateurs simultanées doit être soutenus ?
• Le client a-t-il des infrastructure de virtualisation de VMWare auxquelles l’équipe de sécurité a accès ?
• Le client nécessite deux alimentations ?
• Quelle est la taille estimée de configuration ?
• La poignée de l’appareil enregistrera une collection aussi bien ?

 

Appliance virtuelle Panorama

Cette plateforme fonctionne comme un M-100 virtuel et partage le même taux d’ingestion de journal. Ajout de ressources supplémentaires permettra à l’appliance virtuelle de Panorama à l’échelle les deux taux d’ingestion c' est ainsi que des capacités de gestion. Les exigences minimales pour une appliance virtuelle Panorama en cours d’exécution 8.0 est 8 vCPUs et 16GB vRAM.

 

 

 

 

 

Quand choisir Appliance virtuelle ?

• Le client a grand VMWare Infrastructure que la sécurité ait accès à
• Client est à l’aide de collecteurs journal dédié et ne sont pas en mode mixte

Quand ne pas choisir l’Appliance virtuelle ?

• Équipe de serveur et sécurité sont séparés et ne veulent pas partager
• Client ne dispose d’aucune infrastructure virtuelle

 

Plate-forme matérielle M-100

Cette plateforme a consacré matériel et capable de gérer jusqu'à simultanées 15 administrateurs. En mode mixte, est capable d’ingérer 10 000-15 000 billes par seconde.

Quand choisir M-100 ?

• Le client a besoin d’une plate-forme dédiée, mais est très sensible aux prix
• Client utilise collectionneurs journal dédié et ne sont pas en mode mixte, mais n’ont pas d’infrastructure VM

Quand ne pas choisir M-100 ?

• Si deux blocs d’alimentation sont nécessaires
• Mode mixte avec plus de 10 k journal/s ou plus de 8 to, nécessaire pour la rétention de journal
• A plus de 15 administrateurs simultanés

 

Plate-forme matérielle M-500

Cette plateforme a le plus haut taux d’ingestion Journal, même en mode mixte. La plus grande disponibilité de ressources gérera les configurations plus grandes et plus simultanées administrateurs (15-30). Propose deux alimentations et dispose d’une feuille de route de forte croissance.

Quand choisir M-500 ?

• Le client a besoin d’une plate-forme dédiée et a un déploiement en grand ou en pleine croissance
• Client utilise le mode double avec plus de 10 k journal/s
• Le client veulent à l’avenir preuve leurs investissements
• Client a besoin d’un appareil dédié, mais a plus de 15 administrateurs simultanés
• Nécessite deux alimentations

Quand ne pas choisir M-500 ?

• Si le client a VM premier environnement et n’a pas plus de 48 to de stockage de journal
• Le client est très sensible aux prix

 

Haute disponibilité

Cette section portera sur des considérations de conception lors de la planification d’un déploiement de haute disponibilité. Panorama haute disponibilité n’est actif/passif et les deux appareils ont besoin d’être pleinement autorisés. Il y a deux aspects à haute disponibilité lors du déploiement de la solution de Panorama. Ces aspects sont la gestion des périphériques et l’exploitation forestière. Les deux aspects sont étroitement liés, mais chacun a des exigences spécifiques de conception et de configuration.

 

Gestion des périphériques ha: capacité de conserver les capacités de gestion des périphériques lors de la perte d'un périphérique panoramique (soit une série M ou un appareil virtuel).

Enregistrement de la redondance ha ou log: la possibilité de conserver les journaux du pare-feu sur la perte d'un périphérique panorama (série M uniquement).

 

Gestion des périphériques HA

Lorsque vous déployez la solution Panorama dans une conception de haute disponibilité, beaucoup de clients choisir de placer les pairs HA dans des lieux physiques distincts. D’un point de vue design, il y a deux facteurs à considérer lors du déploiement d’une paire d’appareils Panorama dans une configuration de haute disponibilité. Ces préoccupations sont le débit et la latence du réseau.

 

Latence du réseau

La latence des segments de réseau intermédiaire affecte le trafic de contrôle entre les membres de l’AP. HA minuteries connexes peuvent être ajustés à la nécessité du déploiement client. Maximale recommandée est de valeur 1000 ms.

• Temps de préemption: si l'option préventive est activée, le temps de préemption est la durée pendant laquelle le périphérique passif attendra avant de prendre le rôle actif. Dans ce cas, les périphériques sont en hausse et la minuterie s’applique à l’appareil avec la priorité « Primaire ».
• Temps de maintien de la promotion: la minuterie de maintien de la promotion spécifie l'intervalle pendant lequel le périphérique secondaire attendra avant d'assumer la Rote active. Dans ce cas, il y a eu une défaillance du dispositif principal, et cette horloge s’applique à l’appareil secondaire.
• Intervalle Hello: Cette minuterie définit le nombre de millisecondes entre les paquets Hello et le périphérique homologue. Bonjour les paquets sont utilisés pour vérifier que l’appareil par les pairs est opérationnel.
• Intervalle de pulsation: Cette minuterie définit le nombre de millisecondes entre les messages ICMP envoyés à l'homologue. Les paquets de pulsation sont utilisés pour vérifier que l’appareil par les pairs est accessible.

Relation entre la latence du réseau et l’intervalle de pulsation

Parce que le rythme cardiaque est utilisé pour déterminer l’accessibilité de l’homologue HA, l’intervalle de pulsation doit être réglée plus élevé que la latence du lien entre les membres de l’AP.

 

HA minuterie Presets

Alors que les clients peuvent régler leurs minuteries HA spécifiquement en fonction de leur environnement, Panorama a également deux ensembles de minuteries préconfigurés utilisables par le client. Ces préréglages couvrent la majorité des déploiements de client

 

Recommandé :

Minuterie	Réglage
Temps de maintien de préemption	1
Bonjour intervalle	8000
Intervalle de pulsation	2000
Moniteur Fail Hold Up Time	0
Temps supplémentaire maître Hold Up	7000

 

Agressif :

Minuterie	Réglage
Temps de maintien de préemption	500
Bonjour intervalle	8000
Intervalle de pulsation	1000
Moniteur Fail Hold Up Time	0
Temps supplémentaire maître Hold Up	5000

 

 

Synchronisation de la configuration

 

 

                                                                        HA synchroniser des processus

 

 

Sur Panorama, le processus de synchronisation HA se produit lorsqu’une modification est apportée à la configuration sur un des membres de la paire HA. Lorsqu'une modification est apportée et validée sur l'active-Primary, elle enverra un message d'envoi à l'actif-secondaire que la configuration doit être synchronisée. Actif-secondaire renverra un accusé de réception qu’elle est prête. Le principal actif envoie ensuite la configuration à l’actif-secondaire. Actif-secondaire vont fusionner la configuration Active primaire et file d’attente une tâche pour valider les modifications envoyée. Ce processus doit terminer dans les trois minutes du message transmis par le Panorama primaire Active HA-Sync. La principale préoccupation est la taille de la configuration d’envoi et le débit du réseau ou des segments qui séparent les membres HA.

 

 

Disponibilité de journal

L’autre morceau de la solution de haute disponibilité de Panorama est offrant une disponibilité de grumes dans le cas d’une défaillance matérielle. Il existe deux méthodes pour y parvenir lors de l’utilisation d’une infrastructure de collecteur de journal (dédiée ou en mode mixte).

 

Redondance de journal

PAN-OS 7.0 inclut une option explicite pour écrire chaque journal à 2 capteurs de journal dans le groupe de collecteur de journal. En activant cette option, un dispositif envoie son journal à c' est journal principal collecteur, qui réplique alors le journal à un autre collecteur du même groupe :

 

 

Duplication de journal veille à ce qu’il y a deux copies de n’importe quel journal donné dans le groupe de collecteur de journal. Il s’agit d’une bonne option pour les clients qui ont besoin de garantir la disponibilité de journal à tout moment. Choses à considérer :

 

1. La réplication ne prend place au sein d’un groupe de collecteurs de journal.

2. L’espace de stockage total disponible est réduit de moitié (car chaque journal est écrit deux fois).

3. Taux d’ingestion de journal sera globalement réduit jusqu'à 50 %.

  

Mise en mémoire tampon de journal

Les pare-feu requièrent un accusé de réception de la plate-forme panoramique vers laquelle ils acheminent les journaux. Cela signifie que dans le cas où le collecteur principal journal du pare-feu devient indisponible, les journaux seront mis en mémoire tampon et envoyées lorsque le collecteur revient en ligne. Il existe deux méthodes aux journaux de la mémoire tampon. La première méthode consiste à configurer des groupes de collectionneurs journal distinct pour chaque collectionneur de journal :

 

 

 

 

Dans cette situation, si Log Collector 1 tombe en panne, B A & pare-feu Firewall chacun stockera leur journal de bord sur leur propre partition journal local jusqu'à ce que le collecteur est ramené vers le haut. La partition de journal local pour les modèles de pare-feu actuels sont:

 

Modèle	Taille de la Partition log (GB)
PA-200	2.4
PA-220	32
Série PA-800	172
PA-3000 séries	90
Série PA-3200	125
Série PA-5000	88
Série PA-5200	1800

 

La deuxième méthode consiste à placer plusieurs collectionneurs de journaux dans un groupe. Dans ce scénario, le pare-feu peut être configuré avec une liste de priorités, donc si le collecteur de journal principal descend, le deuxième collecteur de la liste tamponne les journaux jusqu'à ce que tous les collecteurs du groupe sachent que le collecteur principal est en panne à quel moment , les nouveaux journaux cesseront d'être affectés au collecteur Down.

 

Dans l’architecture ci-dessous, B A & Firewall pare-feu sont configurés pour envoyer leurs journaux de Log Collector 1 principalement, avec Log Collector 2 comme une sauvegarde. Si le collecteur de journaux 1 devient inaccessible, les périphériques envoient leurs journaux dans le collecteur de journaux 2. Le collecteur 2 tamponne les billes qui doivent être stockées sur le collecteur 1 jusqu'à ce qu'il puisse tirer le collecteur 1 hors de la rotation.

 

 

Considérations pour la conception de groupe de collecteur de log

 

Il existe trois raisons principales pour configurer les collecteurs de journaux dans un groupe:

 

1. Une plus grande rétention de journal est nécessaire pour un pare-feu spécifique (ou un ensemble de pare-feu) que peut être fourni par un collecteur de journal unique (pour la rétention d'échelle).
2. Une plus grande capacité d'ingestion est nécessaire pour un pare-feu spécifique que ne peut être fourni par un collecteur de log unique (à l'échelle d'ingestion).
3. Exigence de redondance du journal.

 

Lorsqu'on envisage l'utilisation de groupes de collecteurs de grumes, il y a quelques considérations qui doivent être abordées au stade de la conception:

 

1. Répandre l'ingestion sur les collecteurs disponibles: plusieurs listes de préférences de transfert de périphérique peuvent être créées. Cela permet à l'ingestion d'être manipulé par plusieurs collecteurs dans le groupe de collecteur. Par exemple, la liste de préférences 1 aura la moitié des pare-feu et le collecteur de liste 1 comme principal et le collecteur 2 comme secondaire. La liste de préférences 2 aura le reste des pare-feu et le collecteur de liste 2 comme principal et le collecteur 1 comme secondaire.
2. Problèmes de latence: la latence du réseau entre les collecteurs d'un groupe de collecteurs de journaux est un facteur important dans la performance. Une ligne directrice générale de conception est de garder tous les collectionneurs qui sont membres du même groupe proche ensemble. Le tableau suivant donne une idée de ce à quoi vous pouvez vous attendre à différentes mesures latancy avec redondance activée et désactivée. Dans ce cas, 'log Delay'est le résultat indésirable de la latence élevée-les journaux ne s'affichent pas dans l'interface utilisateur jusqu'à ce que bien après qu'ils soient envoyés à Panorama.

 

 

Latence inter-LC (MS)	Taux de log	Redondance activée	Retard de log
50	40.	No	No
100	5K	No	No
100	40.	No	Oui
50	5K	Oui	No
50	40.	Oui	Oui
100	5K	Oui	No
150	3k	Oui	No
150	5K	Oui	Oui

 

 

 

 À l’aide de la feuille de calcul de dimensionnement

 

 

 Les informations dont vous aurez besoin comprennent la période de rétention souhaitée et le taux de log moyen.

 

 

Période de rétention: nombre de jours pendant lesquels les logs doivent être conservés.

Taux de log moyen: taux de log agrégé mesuré ou estimé.

Redondance requise: Cochez cette case si la redondance du journal est requise.

Stockage pour les journaux détaillés: la quantité de stockage (en gigaoctets) requise pour respecter la période de rétention des journaux détaillés.

Stockage total requis: le stockage (en gigaoctets) à acheter. Ce compte pour tous les types de journaux dans les paramètres de quota defualt.

 

 

Exemples d’utilisation