Guía de diseño y tamaño panorama
Resolution
visión general de la gestión y registro de panorama
La solución de Panorama está compuesto por dos funciones generales: administración de dispositivos y registro de colección/Reporting. Sigue una breve descripción de estas dos funciones principales:
Administración de dispositivos: incluye actividades como administración e implementación de configuración, despliegue de pan-os y actualizaciones de contenido.
Colección log: incluye la recopilación de logs de uno o varios cortafuegos, ya sea a un único panorama o a una infraestructura de recopilación de logs distribuida. Además de recoger los registros del cortafuegos desplegados, informes pueden generarse en base que registrar datos si reside localmente al Panorama (por ejemplo solo serie M o VM dispositivo) para en una infraestructura de registro distribuido.
La solución de Panorama permite flexibilidad en el diseño al asignar estas funciones a distintas piezas físicas de la infraestructura de gestión. Por ejemplo: administración de dispositivos se puede realizar desde un Panorama de la VM, mientras los servidores de seguridad hacia adelante sus registros a los coleccionistas de auxilio coubicada log dedicado:
En el ejemplo anterior, la función de administración de dispositivos y presentación de informes se realizan en un aparato VM Panorama. Hay tres grupos de colector de registro. Grupo A, contiene dos selectores de registro y recibe registros de tres servidores de seguridad independiente. Grupo B, consiste en un colector único y recibe registros de un par de servidores de seguridad en una configuración de alta disponibilidad (HA) de activo/pasivo. Grupo C contiene dos selectores de registro así y recibe registros de dos pares HA de firewalls. El número de colectores de registro en cualquier lugar determinado depende de varios factores. Las consideraciones de diseño están cubiertas por debajo. Nota: cualquier plataforma puede ser un administrador dedicado, pero sólo M Series puede ser un colector de registro dedicado.
Colección de registro
Dispositivos gestionados
Mientras que todas las plataformas de Panorama actuales tienen un límite de 1000 dispositivos para la administración, es importante para el apresto de Panorama entender lo que la tasa de registro entrante será de todos los dispositivos administrados. Para comenzar con, tomar un inventario de los dispositivos de firewall total que será gestionado por Panorama.
Utilice la siguiente hoja de cálculo para llevar un inventario de los dispositivos que necesita almacenar registros:
| MODELO | PAN-OS (rama mayor #) | Ubicación | Mide la tasa de registro promedio |
|---|---|---|---|
| Ex: 5060 | Ex: 6.1.0 | Ej.: Centro de datos principal | Ej.: 2500 registros/s |
Requisitos de registro
Esta sección cubrirá la información necesaria para tamaño y desplegar infraestructura de registro de Panorama para soportar los requerimientos del cliente. Hay tres factores principales para determinar la cantidad de almacenamiento total requerido y cómo asignar ese almacenamiento de información mediante colectores de registro distribuido. Estos factores son:
- Requisitos de registro ingestión: Es el número total de registros que se envía por segundo a la infraestructura de Panorama.
- Requerimientos de almacenamiento de información de registro: Este es el plazo para que el cliente necesita conservar los registros en la plataforma de gestión. Hay diferentes factores para este incluyendo tanto política y motivadores de cumplimiento.
- Ubicación del dispositivo: La ubicación física de los servidores de seguridad puede conducir a la decisión de colocar aparatos de DLC en ubicaciones remotas basados en ancho de banda WAN etcetera.
Cada uno de estos factores se discuten en las secciones siguientes:
Requerimientos de ingesta de registro
La tasa de reenvío de registros agregados para dispositivos administrados debe entenderse para AVOun diseño donde se envían periódicamente más registros a panorama de lo que puede recibir, procesar y escribir en disco. La tabla siguiente describe el número máximo de registros por segundo que cada plataforma de hardware puede reenviar a panorama y puede utilizarse al diseñar un solution para calcular el número máximo de logs que se pueden reenviar a panorama en el entorno del cliente.
Dispositivo de registro expedición
| Plataforma | Registros soportados por segundo (LPS) |
|---|---|
| PA-200 | 250 |
| PA-220 | 1.200 |
| PA-500 | 625 |
| PA-820/850 | 10.000 |
| Serie PA-3000 | 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 | A probar |
| 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 |
La tasa de ingestión de registro en Panorama está influenciada por la plataforma y el modo de uso (modo de logger de versos de modo mixto). La siguiente tabla muestra las tasas de ingestión para Panorama en las diferentes plataformas disponibles y modos de operación. Los números entre paréntesis junto a VM denotan el número de CPUs y gigabytes de RAM asignados a la VM.
Ingestión de registro panorama
| Plataforma | Mixto | Dedicado |
|---|---|---|
| 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 |
Los números de arriba son todos los valores de máxima. En implementaciones de vivo, la tasa de registro real es generalmente una fracción del máximo apoyo. Determinación de tasa de registro actual es fuertemente dependiente de la mezcla de tráfico del cliente y no está necesariamente ligada a rendimiento. Por ejemplo, una sola descarga sesión SMB se muestran alto rendimiento pero sólo generan un registro de tráfico. Por el contrario, puede tener un rendimiento menor compuesta por miles de UDP DNS registro de consultas que cada uno genere un tráfico separado. Para el apresto, puede establecerse una correlación aproximada entre conexiones por segundo y registros por segundo.
Métodos para determinar la tasa de registro
Nuevo cliente:
- Aprovechar la información de las fuentes existentes del cliente. Muchos clientes tienen una solución de registro de terceros como ArcSight, Qradar, Splunk, etcetera. El número de registros enviados de su solución de firewall existente puede tiró de esos sistemas. Cuando se utiliza este método, obtener una cuenta de registro de la solución de terceros para un día completo y divídelo por 86.400 (número de segundos en un día). Hacer esto durante varios días para obtener un promedio. Asegúrese de que incluye negocios y días no laborales ya que generalmente existe una gran variación en la tasa de registro entre los dos.
- Utilizar los datos del dispositivo de evaluación. Esta información puede proporcionar un muy útil punto de partida para el dimensionamiento de fines y, con la entrada del cliente, se pueden extrapolar datos de otros sitios en el mismo diseño. Este método tiene la ventaja de que rinde un promedio sobre varios días. Una secuencia de comandos (con instrucciones) para ayudar a calcular puede encontrarse esta información se anexa a este documento. Para usarlo, descargue el archivo llamado "ts_lps. zip". Descomprimir el archivo zip y el archivo README.txt para obtener instrucciones de referencia.
- Si no hay información disponible, utilice la tabla dispositivo registro expedición arriba como punto de referencia. Este será el método menos exacto para cualquier cliente en particular.
Cliente existente:
Para los clientes existentes, podemos aprovechar datos recopilados de su cortafuegos existentes y colectores de registro:
- Para comprobar la velocidad de registro de un único cortafuegos, descargue el archivo adjunto llamado "Device. zip", Desempaquete el archivo zip y haga referencia al archivo README. txt para obtener instrucciones. Este paquete consulta un solo cortafuegos durante un período especificado de tiempo (puede elegir cuántas muestras) y un número promedio de registros por segundo en ese periodo. Al mínimo, esta secuencia de comandos debe ejecutarse durante 24 horas consecutivas en un día hábil. La ejecución de la secuencia de comandos durante una semana completa ayudará a capturar el flujo cíclico de la red. Si el cliente no tiene un colector de registro, este proceso necesitará ejecutar contra cada firewall en el medio ambiente.
- Si el cliente tiene un recopilador de registros (o recopiladores de registros), descargue el archivo adjunto llamado "lc_lps. zip", Desempaquete el archivo zip y haga referencia al archivo README. txt para obtener instrucciones este paquete consultará la MIB del recopilador de registros para tomar una muestra del registro entrante tasa durante un período especificado.
Requerimientos de almacenamiento de información de registro
Factores que afectan los requerimientos de almacenamiento de información de registro
Hay varios factores requerimientos de almacenamiento de información de registro de unidad. La mayoría de estos requisitos son reglamentario en la naturaleza. Los clientes deben cumplir con requisitos de HIPAA, PCI o Sarbanes-Oxely.
Hay otras normas gubernamentales y la industria que pueden necesitar ser considerado. Además, algunas compañías tienen requerimientos internos. Por ejemplo: mantener un cierto número de días el valor de los registros en la plataforma de administración original. Asegúrese de que todos estos requisitos se tratan con el cliente al diseñar una solución de almacenamiento de registro.
El foco está en el número mínimo de los días que el valor de los registros que necesita ser almacenado. Si hay un número máximo de días requeridos (debido a la regulación o la política), puede establecer el número máximo de días para mantener registros en la configuración de cuota.
Cálculo de almacenamiento requiere
El cálculo del espacio de almacenamiento requerido basado en los requerimientos de un cliente determinado es un proceso bastante sencillo, pero puede ser intensivo en mano de obra cuando se alcanzan mayores grados de precisión. Con pan-OS 8,0, el tamaño agregado de todos los tipos de registro es de 500 bytes. Este número representa los registros ellos mismos, así como los índices asociados. La base de datos de amenaza es la fuente de datos para registros de amenaza así como URL, las presentaciones de incendios forestales, y registra los datos de filtrado.
Tenga en cuenta que no podemos ser la solución de registro para archiving a largo plazo. En estos casos sugerimos Syslog para propósitos de archivo.
La ecuación para determinar los requerimientos de almacenamiento de información para el tipo de registro particular es:
Ejemplo: El cliente desea poder guardar 30 días de los registros de tráfico con una tasa de registro de 1500 registros por segundo:
El resultado del cálculo anterior cuenta sólo para registros detallados. Con la configuración de cuota predeterminada, Reserve el 60% del almacenamiento disponible para registros detallados. Esto significa que el número calculado representa el 60% del total de almacenamiento que deberá adquirirse. Para calcular el total de almacenamiento requerido, divida este número por. 60:
Las cuotas de registro predeterminadas para panorama 8,0 y posteriores son las siguientes:
| Tipo de registro | % De almacenamiento |
| Logs de Firewall detallado | 60 |
| Logs de Firewall Resumen | 30 |
| Infraestructura y Logs de auditoría | 5 |
| Palo Alto Networks plataforma registros | .1 |
| 3er partidos registros externos | .1 |
La hoja de cálculo adjunta se tiene en cuenta la cuota predeterminada en Panorama y aportan una cantidad total de almacenamiento de información necesario.
Cálculo de almacenamiento requerido para el servicio de registro
Hay tres casos diferentes para recopilación de registro utilizando el servicio de registro de tamaño. Para obtener una orientación de tamaño de profundidad, consulte el almacenamiento de tamaño para el servicio de registro.
- Colección de registro para la siguiente generación cortafuegos de Palo Alto Networks
- Colección de registro de usuario de móvil de servicio de nube de GlobalProtect
- Colección de registro para oficinas remotas de servicio de nube de GlobalProtect
Colección de registro para Palo Alto siguiente generación cortafuegos
El registro de tamaño metodología para iniciar sesión en el servicio de registro de cortafuegos es el mismo al dimensionar para en colectores de registro local. La única diferencia es el tamaño del registro en disco. En el servicio de registro, tanto la amenaza como los registros de tráfico se pueden calcular utilizando un tamaño de 1500 bytes.
Colección de registro de usuario móvil de servicio de nube de GlobalProtect
Por registro de usuario generación depende fuertemente del tipo de usuario, así como las cargas de trabajo se ejecute en ese entorno. En promedio, 1TB de almacenamiento de información en el servicio de registro proveerá retención de 30 días para 5000 usuarios. Una ventaja del servicio de registro es que agregar almacenamiento de información es mucho más sencillo de lo que en un tradicional sobre medio ambiente colección distribuida de premisa. Esto significa que si su entorno es significativamente mayor que el promedio, es un asunto sencillo para agregar cualquier almacenamiento de información es necesario cumplir con los requerimientos de retención.
Colección de registro para GlobalProtect nube servicio oficina remota
Servicio de nube de GlobalProtect (GPCS) para oficinas remotas se vende basado en ancho de banda. Mientras que la tasa de registro es en gran parte impulsado por mezcla velocidad y tráfico de conexión, en empresa de muestra sesión de entornos generación se produce a una velocidad de aproximadamente 1,5 registros por segundo por megabit de rendimiento. La hoja de trabajo adjunta tamaño utiliza esta tarifa y toma en cuenta disponibilidad y apagado horas con el fin de proporcionar una tasa de registro promedio estimado.
Cuotas de almacenamiento LogDB
Las cuotas de almacenamiento fueron simplificadas a partir de PAN-OS versión 8.0. Detalle y Resumen de registros, cada uno tienen su propia cuota, independientemente del tipo (tráfico/amenaza):
| Tipo de registro | Cuota (%) |
| Logs de Firewall detallado | 60 |
| Logs de Firewall Resumen | 30 |
| Infraestructura y Logs de auditoría | 5 |
| Palo Alto Networks plataforma registros | .1 |
| 3er partidos registros externos | .1 |
| Total | 95.2 |
Ubicación del dispositivo
La última consideración de diseño para infraestructura de registro es la ubicación de los servidores de seguridad en relación con la plataforma de Panorama están conectando a. Si el dispositivo está separado del Panorama por un segmento de red de baja velocidad (p. ej. T1/E1), se recomienda colocar un colector de registro dedicado (DLC) en el sitio con el servidor de seguridad. Esto permite la expedición de registro para limitarse al mayor segmento de LAN velocidad permitiendo Panorama consultar el selector de registro cuando sea necesario. Para referencia, las siguientes tablas muestra uso de ancho de banda para la expedición del registro en las tasas de registro diferente. Esto incluye ambos registros enviados a Panorama y el reconocimiento del Panorama para el firewall. Tenga en cuenta que para la 7000 serie y 5200 serie, los registros se comprimen durante la transmisión.
Registro de expedición de ancho de banda
| Tasa de registro (LPS) | Ancho de banda utilizado |
|---|---|
| 1300 | 8 Mbps |
8000 | 56 Mbps |
| 10000 | 64 Mbps |
| 16000 | 52,8 140.8 Mbps (96,8) |
Sesión de ancho de banda Forwarding - 5200 y 7000 Series
| Tasa de registro (LPS) | Ancho de banda utilizado |
|---|---|
| 1300 | .6 Mbps |
8000 | 4 Mbps |
| 10000 | 4.5 Mbps |
| 16000 | 5 - 10 Mbps |
Administración de dispositivos
Hay varios factores a considerar al elegir una plataforma para una implementación de Panorama. Los factores iniciales incluyen:
- ¿Número de administradores simultáneos necesita ser apoyado?
- ¿Tiene el cliente de infraestructura de virtualización de VMWare que el equipo de seguridad tiene acceso a?
- ¿El cliente requiere dos fuentes de alimentación?
- ¿Cuál es el tamaño estimado de configuración?
- ¿Registrará la empuñadura del dispositivo colección así?
Panorama Virtual Appliance
Esta plataforma funciona como un virtual M-100 y comparte la misma tasa de ingestión de registro. Añadir recursos adicionales permitirá que el dispositivo virtual del Panorama a escala tanto la tasa de ingestión así como capacidades de administración. Los requisitos mínimos para un dispositivo virtual Panorama correr 8.0 es 8 vCPUs y 16GB de vRAM.
¿Cuándo elegir dispositivo Virtual?
- El cliente tiene gran infraestructura de VMWare que la seguridad tiene acceso a
- Cliente está utilizando colectores de registro dedicado y no son en modo mixto
¿Cuándo no elegir dispositivo Virtual?
- Equipo servidor y equipo de seguridad son separados y no quieren compartir
- Cliente no tiene ninguna infraestructura virtual
Plataforma de Hardware M-100
Esta plataforma ha dedicado hardware y puede manejar hasta los 15 administradores concurrentes. Cuando está en modo mixto, es capaz de ingerir 10.000-15.000 registros por segundo.
¿Cuándo elegir M-100?
- El cliente necesita una plataforma dedicada, pero es muy sensible
- Cliente está utilizando colectores de registro dedicado y no son en modo mixto pero no tiene infraestructura VM
¿Cuándo no elegir M-100?
- Si se requieren dos fuentes de alimentación
- Modo mixto con más de 10 k log/s o más de 8TB para retención de registros
- Tiene más de 15 administradores simultáneos
Plataforma de Hardware M-500
Esta plataforma tiene la mayor tasa de ingestión de registro, incluso cuando está en modo mixto. La mayor disponibilidad de recursos encargará de configuraciones más grandes y los administradores más concurrentes (15-30). Ofrece dos fuentes de alimentación y un plan de crecimiento.
¿Cuándo elegir M-500?
- El cliente necesita una plataforma dedicada y tiene un despliegue grande o creciente
- Cliente está usando modo dual con más de 10 k log/s
- Cliente quiere futuro prueba sus inversiones
- Cliente necesita un dispositivo dedicado pero tiene más de 15 administradores simultáneos
- Requiere dos fuentes de alimentación
¿Cuándo no elegir M-500?
- Si el cliente tiene VM primer ambiente y no necesita más de 48 TB de almacenamiento de registro
- El cliente es muy sensible
Alta disponibilidad
Esta sección abordará consideraciones al planear una implementación de alta disponibilidad. Alta disponibilidad de panorama sólo es activo/pasivo y ambos dispositivos necesitan ser completamente licenciado. Hay dos aspectos para alta disponibilidad al implementar la solución de Panorama. Estos aspectos son administración de dispositivos y el registro. Los dos aspectos están estrechamente relacionados, pero cada una tiene requisitos específicos de diseño y configuración.
Administración de dispositivos ha: la capacidad de conservar las capacidades de administración de dispositivos en la pérdida de un dispositivo panorámico (ya sea una serie M o un equipo virtual).
Registro de ha o redundancia de logs: la capacidad de retener los logs de Firewall sobre la pérdida de un dispositivo panorámico (sólo serie M).
Administración de dispositivos HA
Al implementar la solución de Panorama en un diseño de alta disponibilidad, muchos clientes deciden colocar a pares HA en ubicaciones físicas separadas. Desde una perspectiva de diseño, hay dos factores a considerar al implementar un par de aparatos de Panorama en una configuración de alta disponibilidad. Estas preocupaciones son rendimiento y latencia de red.
Latencia de la red
La latencia de segmentos intermedios de la red afecta el control del tráfico entre los miembros de la HA. HA relacionados con temporizadores se pueden ajustar a la necesidad de la implementación de cliente. La máxima recomendada es de valor 1000 ms.
- Tiempo de espera: si la opción preventiva está activada, el tiempo de espera de la preferencia es la cantidad de tiempo que el dispositivo pasivo esperará antes de tomar el rol activo. En este caso, ambos dispositivos están y el temporizador se aplica al dispositivo con la prioridad «Primaria».
- Tiempo de retención de la promoción: el temporizador de retención de la promoción especifica el intervalo que el dispositivo secundario esperará antes de asumir la memoria activa. En este caso, ha habido una falla en el dispositivo primario y este temporizador se aplica al dispositivo secundario.
- Hola intervalo: este temporizador define el número de milisegundos entre los paquetes Hello al dispositivo peer. Hola paquetes se usan para verificar que el dispositivo de pares está en funcionamiento.
- Intervalo de latido: este temporizador define el número de milisegundos entre los mensajes ICMP enviados al mismo nivel. Paquetes de latido del corazón se usan para verificar que el dispositivo de pares es accesible.
Relación entre la latencia de red y el intervalo de latidos del corazón
Porque los latidos del corazón se utilizan para determinar la accesibilidad de los pares HA, el intervalo del latido del corazón debe establecerse mayor que la latencia de la conexión entre los miembros HA.
HA temporizador preajustes
Mientras que los clientes pueden configurar sus contadores HA específicamente para adaptarse a su ambiente, Panorama tiene también dos sistemas de alarmas preconfiguradas que puede utilizar el cliente. Estos valores cubren la mayoría de las implementaciones de cliente
Recomienda:
| Temporizador | Ajuste |
|---|---|
| Tiempo de espera de preferencia sobre | 1 |
| Hola intervalo | 8000 |
| Intervalo de latidos del corazón | 2000 |
| Monitor error espera tiempo | 0 |
| Adicional maestro espera tiempo | 7000 |
Agresivo:
| Temporizador | Ajuste |
|---|---|
| Tiempo de espera de preferencia sobre | 500 |
| Hola intervalo | 8000 |
| Intervalo de latidos del corazón | 1000 |
| Monitor error espera tiempo | 0 |
| Adicional maestro espera tiempo | 5000 |
Configuración de sincronización
HA Sincronizar proceso
El proceso de sincronización HA se produce en el Panorama cuando se realiza un cambio en la configuración de uno de los miembros de la pareja HA. Cuando se realiza un cambio y se comete en el primario activo, se enviará un mensaje de envío a la secundaria activa que la configuración necesita sincronizarse. El activo secundario devolver un acuse de recibo que está listo. El principal activo enviará la configuración para el activo secundario. El activo secundario fusionará la configuración enviada por el activo principal y poner un trabajo para cometer los cambios. Este proceso debe completar dentro de tres minutos del mensaje Sync HA enviados desde el Panorama del activo principal. La principal preocupación es el tamaño de la configuración de envío y el rendimiento efectivo de los segmentos de red que separan a los miembros de la HA.
Disponibilidad de registro
La otra pieza de la solución de alta disponibilidad de Panorama ofrece la disponibilidad de los registros en caso de un fallo de hardware. Existen dos métodos para lograr esto cuando se utiliza una infraestructura de selector de registro (dedicadoa o en modo mixto).
Redundancia de registro
PAN-OS 7.0 y más adelante incluyen una opción explícita para escribir cada registro a 2 selectores de registro en el grupo de colector de registro. Habilitando esta opción, un dispositivo envía su registro para su registro principal colector, que luego reproduce el registro al otro colector en el mismo grupo:
Duplicación de registro asegura que hay dos copias de cualquier registro dado en el grupo de colector de registro. Esta es una buena opción para clientes que necesitan para garantizar la disponibilidad de registro en todo momento. Cosas a considerar:
1. La replicación sólo tiene lugar dentro de un grupo de colectores de registro.
2. El espacio de almacenamiento disponible total se reduce a la mitad (ya que cada registro está escrito dos veces).
3. Total tasa de ingestión de registro se reducirán en hasta un 50%.
Buffering de registro
Los cortafuegos requieren un reconocimiento de la plataforma panorámica a la que están remitiendo logs. Esto significa que en caso de que el colector de registro principal del firewall está disponible, los registros serán tamponados y enviados cuando el colector entra detrás en línea. Hay dos métodos para registros de búfer. El primer método es configurar grupos de colector de registro separado para cada colector de registro:
En esta situación, si desciende 1 colector de registro, Firewall A Firewall y B cada uno guardará sus registros en su propia partición de registro local hasta que el recolector se trae para arriba. La partición de registro local para los modelos de cortafuegos actuales son:
| Modelo | Tamaño de partición de registro (GB) |
|---|---|
| PA-200 | 2.4 |
| PA-220 | 32 |
| Serie PA-800 | 172 |
| Serie PA-3000 | 90 |
| Serie PA-3200 | 125 |
| Serie PA-5000 | 88 |
| Serie PA-5200 | 1800 |
El segundo método es colocar múltiples colectores de registro en un grupo. En este escenario, el cortafuegos se puede configurar con una lista de prioridades, de modo que si el selector de registro principal se cae, el segundo selector de la lista almacenará en búfer los registros hasta que todos los colectores del grupo sepan que el selector primario está en el momento , los nuevos registros dejarán de ser asignados al colector de Down.
En la arquitectura se muestra a continuación, Firewall A Firewall & B están configurados para enviar sus registros a registro colector 1 principalmente, con 2 de colector de registro como una copia de seguridad. Si el selector de registro 1 se vuelve inalcanzable, los dispositivos enviarán sus logs al colector de registro 2. El colector 2 almacenará en búfer los registros que se almacenarán en el colector 1 hasta que pueda extraer el colector 1 de la rotación.
Consideraciones para el diseño del grupo de coleccionista de logs
Hay tres razones principales para configurar los recopiladores de registros en un grupo:
- Se requiere una mayor retención de logs para un firewall específico (o un conjunto de cortafuegos) que el que puede proporcionar un único colector de logs (para escalar la retención).
- Se requiere una mayor capacidad de ingesta para un cortafuegos específico que el que puede proporcionar un único colector de logs (para escalar la ingesta).
- Requerimiento de redundancia de logs.
Al considerar el uso de grupos de colector de troncos hay un par de consideraciones que deben ser abordadas en la etapa de diseño:
- Propagación de la ingestión a través de los colectores disponibles: se pueden crear listas de preferencias de reenvío de dispositivos múltiples. Esto permite que la ingestión sea manejada por varios colectores en el grupo coleccionista. Por ejemplo, la lista de preferencias 1 tendrá la mitad de los cortafuegos y el selector de lista 1 como el primario y el selector 2 como secundario. La lista de preferencias 2 tendrá el resto de los cortafuegos y el selector de lista 2 como el primario y el selector 1 como secundario.
- Materia de latencia: la latencia de la red entre los colectores en un grupo colector de troncos es un factor importante en el rendimiento. Una pauta general de diseño es mantener a todos los coleccionistas que son miembros del mismo grupo cerca juntos. La siguiente tabla proporciona una idea de lo que puede esperar en diferentes mediciones de latancy con redundancia activada y deshabilitada. En este caso, ' log Delay ' es el resultado no deseado de la alta latencia-los logs no aparecen en la UI hasta bien después de que se envían a panorama.
| Latencia inter LC (MS) | Velocidad de registro | Redundancia activada | Demora de registro |
| 50 | 10k | No | No |
| 100 | 5K | No | No |
| 100 | 10k | No | Sí |
| 50 | 5K | Sí | No |
| 50 | 10k | Sí | Sí |
| 100 | 5K | Sí | No |
| 150 | 3K | Sí | No |
| 150 | 5K | Sí | Sí |
Utilizando la hoja de cálculo de dimensionamiento
La información que necesitará incluye el período de retención deseado y la tasa de registro promedio.
Período de retención: número de días que se deben mantener los troncos.
Tasa promedio de registro: la tasa de registro agregada medida o estimada.
Redundancia requerida: Marque esta casilla si se requiere la redundancia del registro.
Almacenamiento para registros detallados: la cantidad de almacenamiento (en gigabytes) requerida para cumplir con el período de retención para registros detallados.
Total de almacenamiento requerido: el almacenamiento (en gigabytes) que se comprará. Esto representa todos los tipos de registros en la configuración de cuota defualt.
Ejemplo casos de uso