INSTALACIÓN DE AGILE CONTROLLER-CAMPUS V
Hola a todos en el foro.
Esta es la publicación 5 de 5 del tema, y la última del segmento.
Los siguientes enlaces llevan a las partes anteriores:
Implementación de Agile Controller-Campus en el Esquema de Alta Disponibilidad
Vista Conjunta de las Capacidades de Alta Disponibilidad
MÓDULO | Plataforma Windows + SQL Server | Plataforma Linux + Oracle |
MC | HA no es soportado | Soporta HA. La tecnología Keepalive se usa para proveer intercambio entre estado activo/en espera |
SM | HA no es soportado | Soporta HA. La tecnología Keepalive se usa para proveer intercambio entre estado activo/en espera |
SC | HA se implementa a través de un recurso basado en la solución pool. N+1 SCs necesitan ser implementados para proveer redundancia N+1 | HA se implementa a través de un recurso basado en la solución pool. N+1 SCs necesitan ser implementados para proveer redundancia N+1 |
Base de Datos | HA está implementado usando la base de datos SQL Server con la tecnología mirroring. Se necesita desplegar la base de datos principal, espejo y testigo. | HA es soportado. La tecnología Real Aplication Clúster (RAC) se usa para implementar respaldo en caliente. Los arreglos de los discos necesitan ser configurados para el almacenamiento de datos |
· Restricciones de la alta disponibilidad en la Agile Controller:
§ Si el sistema operativo de Windows Server y la base de datos SQL son usados, son necesarios 3 servidores para base de datos (principal, espejo y testigo).
§ Si se usa el sistema operativo Linux y la base de datos Oracle. MC y SM pueden trabajar en modo activo/espera. La base de datos debe correr en u arreglo de discos (tal como S2600T)
Solución de Alta Disponibilidad Para la Plataforma Windows + SQL Server
· La base de datos de Agile Controller usa la función espedo de SQL Server para asegurar la alta disponibilidad y alta confiabilidad. Una vez que la base de datos principal falla, los servicios se intercambian automáticamente hacia la base de datos espejo.
· El servidor testigo monitorea a los servidores principal y espejo, lo cual asegura que solo uno de los dos servidores funcione como principal dentro de un periodo de tiempo dado cuando ocurre una falla.
· Si existe un servidor testigo, la sincronización de la sesión se ejecuta en el modo de alta disponibilidad. Si el servidor principal falla, los servicios se transfieren de manera automática hacia el servidor espejo.
· Si no existe un servidor testigo, la sincronización de la sesión se ejecuta en el modo de protección del alto nivel. Si ocurre una falla, se necesita una transferencia manual del servicio, lo cual resultará en una posible pérdida de datos.
· Solución de redundancia SC N+1 (Linux o Windows)
§ Un servidor SC activo y un servidor SC en espera son especificados para cada dispositivo de acceso. Si el servidor SC activo falla o si está inalcanzable debido a fallas en la red, el NAD será dirigido como servidor SC en espera.
§ Después de que se realiza la redirección o intercambio, los usuarios autenticados no se ven afectados y permanecen en línea. Los nuevos usuarios son autenticados en el nuevo servidor SC activo.
Solución de Alta Disponibilidad Para la Plataforma Linux + Oracle
· La confiabilidad del servidor SM/SC está asegurada por el esquema activo/en espera, y el grupo de software es usado para implementar el intercambio entre activo/en espera de los servidores SM/SC
· La base de datos de Oracle usa la función RAC para proveer alta confiabilidad. Las instancias de bases de datos se ejecutan en estado activo y en espera de manera independiente. Los archivos de las instancias de las bases de datos son almacenadas en un arreglo de discos compartido.
Finalizamos aqui con el segmentro y con el tema. Recuerda visitar mi perfil donde encontrarás toda la informacion referente a los temas del examen H12 723, que es examen 3 de 3 para la certificacion HCIP SEGURIDAD. Comparte, comenta y deja tu
