Agrupamiento y equilibrio de carga

Gran parte del escalado consiste en ampliar la arquitectura de su PKI para satisfacer sus necesidades. El primer paso para gestionar más emisiones y tráfico es la agrupación en clústeres: dividir la carga entre varias instancias de EJBCA que trabajan en conjunto. Esto ofrece la ventaja adicional de añadir una capa de fiabilidad a su PKI, ya que cualquier clúster impar siempre puede sobrevivir a un fallo en uno o más de sus nodos. EJBCA se ha diseñado para permitir actualizaciones en caliente, lo que significa que su PKI sigue activa y en funcionamiento mientras los nodos del clúster ejecutan diferentes versiones de EJBCA, sin tiempo de inactividad.

Asimismo, la agrupación se puede realizar en VA o RA para aliviar la carga en su PKI, dependiendo de dónde su PKI tenga problemas de rendimiento:

• Si experimenta tiempos de respuesta largos o tiempos de espera en la infraestructura de su VA, es posible que el HSM del VA o la base de datos estén sobrecargados con consultas. Esto se puede solucionar añadiendo más VA, pero también agrupando las instancias de VA.

• Si emite o revoca certificados en grandes volúmenes, agrupar las CA permitirá que más nodos realicen la revocación y la publicación. Cada revocación enviada a las VA es una sola escritura por clúster.

Si tiene varios VA o clústeres de VA, es fundamental colocarlos detrás de un balanceador de carga para equilibrar la carga en cada VA.

→ Obtenga más información sobre cómo ejecutar EJBCA en un clúster

Fragmentación de bases de datos

Para bases de datos de volúmenes extremos, puede ser conveniente dividir la base de datos en varias instancias de base de datos para ahorrar espacio.

Para fragmentar su base de datos y evitar que todo se guarde en el mismo volumen físico, configure el archivo de configuración database.properties para que los cuerpos de certificado se almacenen en otra tabla de certificados. Active la propiedad database.useSeparateCertificateTable para almacenar el cuerpo de certificado en la tabla Base64CertificateData en lugar de en CertificateData.

Base64CertificateData puede fragmentarse y ubicarse en un volumen de base de datos diferente. Para obtener más información sobre las configuraciones de EJBCA, consulte "Administración de configuraciones de EJBCA" .

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.

→ Obtenga más información sobre las CRL particionadas

Fijación de servicio

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, por ejemplo, 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 fijar el servicio a un solo nodo y eliminar ese nodo de la lista del balanceador de carga, lo que significa que todas las ejecuciones del servicio ocurrirán solo en ese nodo, mientras que las operaciones de inscripción, emisión y revocación se procesan en el nodo restante.

→ Conozca más sobre los servicios en EJBCA

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 precompilado . Esta funcionalidad permite a un agente de autenticación (VA) 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 VA.

→ Obtenga más información sobre las respuestas OCSP precompiladas

Certificados efímeros

EJBCA puede configurarse para funcionar como una CA de certificados efímeros. En este modo, EJBCA funciona como una fábrica de certificados de alta velocidad, emitiendo certificados pero sin almacenar rastros de ellos en la base de datos local.

Si bien este modo aún permite la revocación de certificados, no permite buscarlos en la base de datos ni aplicar restricciones basadas en certificados existentes. Para más información , consulte Certificados efímeros .

Contenido relacionado

Para profundizar en el funcionamiento interno de EJBCA, consulte la Guía conceptual de EJBCA CA. Para obtener más información sobre alta disponibilidad, agrupación en clústeres y la adaptación de EJBCA para volúmenes extremos , consulte Instalación de EJBCA .

Para obtener más información sobre otras áreas de soluciones interesantes y lo que necesita configurar, consulte Áreas de soluciones .