Maximizar el rendimiento
EJBCA se utiliza para emitir miles de millones de certificados con una carga de transacciones muy alta (cientos por segundo). Como en cualquier sistema a gran escala, es necesario diseñar la solución para este caso de uso, tanto en lo que respecta al diseño de la solución como a la infraestructura de TI. Para casos de uso más pequeños, tanto el diseño como la infraestructura de TI son bastante sencillos, pero para casos de uso de gran envergadura hay muchos aspectos a considerar y se requiere mucha experiencia (como ocurre con cualquier sistema de TI con grandes cantidades de datos y requisitos exigentes).
Consejos generales de rendimiento
Normalmente, en una PKI, el rendimiento extremo no supone un problema. Una instalación predeterminada de EJBCA puede emitir fácilmente decenas, incluso cientos, de certificados por segundo, lo cual es más que suficiente incluso para instalaciones muy grandes. Para OCSP es más importante, pero OCSP también es más ligero, por lo que el rendimiento predeterminado es de cientos de solicitudes por segundo.
Sin embargo, en instalaciones de PKI más especializadas, puede ser necesario emitir cientos de certificados por segundo. Por lo tanto, proporcionamos una lista de elementos de configuración que pueden maximizar el rendimiento de EJBCA para emitir más de 100 certificados por segundo (dependiendo del hardware, etc.).
Desactive el registro en la base de datos en cesecore.properties y use solo Log4jLogDevice. Esto elimina una inserción en la base de datos y proporciona un gran impulso.
Configura Log4j para que registre solo en archivo, no en consola, y usa solo el registro de información o errores, no el de depuración. Esto puede suponer una pequeña mejora.
Deshabilite el uso de CertReqHistory en la configuración de la CA (Usar historial de solicitudes de certificados). Esto elimina la inserción de una base de datos y proporciona un gran impulso. La configuración predeterminada es tenerlo deshabilitado.
Deshabilite finishUser en la configuración de CA. Verifique primero que esto sea correcto consultando la documentación de esta función. Esto puede ahorrarle tiempo de lectura y actualización a la base de datos.
Habilite todas las cachés en cache.properties. Si almacena en caché indefinidamente, puede usar el comando de la CLI 'bin/ejbca.sh clearcache' si se realizan cambios de configuración. Esto puede mejorar ligeramente; consulte Borrar todas las cachés .
No aplique ninguna unicidad (claves, DN, número de serie del DN del sujeto) en la configuración de CA. Esto garantizará que no se realicen selecciones adicionales y puede suponer una pequeña mejora.
Minimice el número de índices en la base de datos y utilice solo los estrictamente necesarios. Esto agiliza las inserciones en la base de datos y puede generar un 10 % adicional.
Utilice los conectores nativos de JBoss para http y https. Esto puede suponer un 10 % adicional.
Si tiene muchos certificados (más de 100 millones), puede ser recomendable usar una tabla independiente para almacenar los certificados codificados. Consulte la propiedad database.useSeparateCertificateTable en ./conf/database.properties.sample.
Índices de bases de datos
Un requisito previo para obtener un buen rendimiento bajo carga es que la base de datos funcione rápidamente. Asegúrese de que se apliquen (al menos) los índices de base de datos recomendados. Consulte doc/sql-scripts para conocer los índices recomendados. Compruebe el rendimiento de la base de datos durante una prueba para garantizar que funcione en condiciones óptimas.
Consideraciones sobre el diseño de soluciones
En un entorno de alta velocidad y gran volumen, no conviene diseñar la solución para que se sincronice con un solo objeto o fila de la base de datos, ya que esto limitaría el rendimiento. En su lugar, conviene utilizar transacciones sin conflictos siempre que sea posible.
Para mantener la velocidad en casos de uso paralelo, EJBCA (y la mayoría de las demás aplicaciones) utiliza bloqueo optimista en la base de datos. Con este bloqueo, no es recomendable usar el mismo objeto (entidad final) para varios subprocesos paralelos, ya que se generará una condición de carrera en este objeto. Si bien se podría configurar la base de datos/EJBCA para una sincronización más intensa, esto solo provocaría congestión y tiempos de espera.
En la práctica, esto significa que no se deben realizar solicitudes paralelas utilizando la misma entidad final si se desea obtener un buen rendimiento sin tener que serializar alrededor del objeto de entidad final. Un mejor diseño para maximizar el rendimiento es usar:
una entidad final única por hilo (serializada a la misma entidad final), o
una entidad final única por solicitud
Puede utilizar entidades finales aleatorias creadas por solicitud, lo que permite un paralelismo muy grande.
Adaptación de EJBCA para volúmenes extremos
Certificados efímeros
EJBCA puede configurarse para funcionar como una CA de certificados efímeros . En este modo, EJBCA funciona simplemente como una fábrica de certificados de alta velocidad, emitiendo certificados pero sin almacenar rastros de ellos en la base de datos local.
El uso de EJBCA en modo CA efímero limita algunas funcionalidades, principalmente las siguientes:
No se pueden buscar certificados emitidos.
No puede habilitar ciertas limitaciones como Aplicar DN único o Aplicar claves públicas únicas .
Puede revocar certificados. Sin embargo, requiere una configuración específica de la CA y solo se conservarán algunos datos del certificado tras la revocación. Para obtener más información, consulte "Aceptar revocaciones para entradas inexistentes en los campos de la CA" .
Si estas limitaciones son aceptables, puede obtener algunos beneficios al utilizar el modo CA efímero :
Máximo rendimiento al no realizar consultas a la base de datos. Al habilitar el almacenamiento en caché máximo, EJBCA no realizará ninguna llamada a la base de datos.
Requisitos mínimos de almacenamiento. Dado que no se almacenan certificados emitidos en la base de datos, solo la configuración de EJBCA requiere almacenamiento.
Para utilizar certificados efímeros, desactive el almacenamiento de certificados en el perfil de certificado o en la autoridad de certificación .
Fragmentación de bases de datos
Para fragmentar su base de datos y evitar que todo se guarde en el mismo volumen físico, al establecer database.useSeparateCertificateTable como verdadero en el archivo database.properties, el cuerpo del certificado se almacenará en la tabla Base64CertificateData en lugar de en CertificateData.
database.useSeparateCertificateTable = trueLuego, Base64CertificateData se puede fragmentar y colocar en un volumen de base de datos diferente.
Limitar el tamaño de las consultas de base de datos
Ciertos tipos de consultas pueden, intencionalmente o no, generar resultados masivos. Para no saturar el controlador de la base de datos, EJBCA tiene un valor máximo predeterminado de 500 resultados para ciertas tablas, lo que afecta a los siguientes conjuntos de datos:
Certificados
Entidades finales
Nombres de usuario de token duro
Puede cambiar el límite de consultas en Configuración del sistema . Por seguridad, se mantiene un límite máximo de 25 000 entradas.
Limitar el tiempo de espera de las consultas a la base de datos
Ciertos tipos de búsqueda pueden, intencionalmente o no, generar consultas que consumen mucha información de la base de datos (incluso escaneos completos de tablas). Para no sobrecargar la base de datos, EJBCA intentará limitar el tiempo de ejecución de una consulta para ciertas búsquedas antes de cancelarla. Para que estas limitaciones funcionen, tanto la base de datos como el controlador JDBC (Java DataBase Connector) deben ser compatibles. Esta configuración afecta actualmente a las siguientes búsquedas:
Búsqueda de certificados en la GUI de RA
Búsqueda de entidades finales en la GUI de RA
Puede aumentar o reducir el valor predeterminado de 10 000 ms (10 segundos) para el tiempo de espera de consulta en Configuración del sistema. Si se establece en 0, EJBCA no intentará aplicar ningún tiempo de espera de consulta y usará la configuración predeterminada de su servidor de aplicaciones y base de datos.
Particionado de CRL
Si su población de certificados vigentes es grande y depende de CRLs, podría notar que los tiempos de generación de CRLs se vuelven descontrolados y que el tamaño de las CRLs se vuelve inmanejable. EJBCA admite la partición de CRLs según RFC 5280 , lo que permite asignar certificados a un fragmento de CRL específico.
La partición de CRL implica que, en lugar de una sola CRL, esta se divide en varios fragmentos. A medida que los fragmentos aumentan de tamaño, EJBCA permite suspenderlos y crear nuevos automáticamente.
Fijación de servicio
Actualmente, la fijación de servicios solo funciona en instalaciones de la plataforma de soluciones EJBCA.
En una instancia EJBCA en clúster, la ejecución del servicio se realiza de forma semi-aleatoria, y lo ejecuta el primer nodo que se activa dentro del intervalo de servicio permitido. Si algunos servicios, como la generación de CRL, tardan demasiado tiempo, es posible que se experimente latencia en el nodo del clúster que ejecuta el servicio, lo que provoca retrasos intermitentes durante su ejecución. La solución más sencilla es anclar el servicio a un solo nodo y eliminarlo de la lista del balanceador de carga. Esto significa que todas las ejecuciones del servicio se realizarán solo en ese nodo, mientras que las operaciones de inscripción, emisión y revocación se procesarán en el nodo restante.
Para obtener más información sobre cómo anclar a nodos específicos, consulte Servicios .
Respuestas OCSP precompiladas
Cada respuesta OCSP requiere una firma individual del token criptográfico en el VA. Si bien las respuestas generadas se almacenan en caché en el VA EJBCA, los tiempos de validez de las respuestas OCSP suelen ser cortos (menos de un día) y las cachés no se comparten entre los nodos de un clúster, por lo que las respuestas deben generarse con frecuencia. La solución tradicional para esto ha sido el encadenamiento de OCSP , que almacena en caché la primera respuesta encontrada en el proxy HTTP. Si bien esto puede resolver el problema en cierta medida, transfiere la carga de la administración del almacenamiento en caché de las respuestas al usuario.
En cambio, EJBCA ofrece respuestas OCSP precompiladas . También conocidas como OCSP predefinido , esta funcionalidad permite a un agente virtual generar el conjunto completo de respuestas OCSP esperadas con regularidad y dentro de un plazo establecido cuando se esperan interrupciones en el tráfico. Para cualquier PKI, esto reducirá drásticamente la latencia de la infraestructura del agente virtual.
Para obtener más información sobre las respuestas OCSP precompiladas, consulte Preproducción de respuestas OCSP .