Encuentro que cuando las personas diseñan la arquitectura Oracle RAC, a menudo no piensan en la redundancia N+1 en sus planes de implementación. Hay dos razones para implementar Oracle RAC, disponibilidad y escalabilidad. Para los propósitos de esta discusión, me estoy enfocando solo en el lado de la disponibilidad. Si sus implementaciones de RAC son solo por motivos de escalabilidad, es posible que este tema no se aplique a usted.
Entonces, ¿qué es la Redundancia N+1? En pocas palabras, si necesita N unidades de algo, por motivos de redundancia, debe tener N+1 de ese artículo. Veamos un servidor de base de datos. Debe tener una fuente de alimentación. Ese es un requisito. Sin una fuente de alimentación que funcione, el servidor no funcionará en absoluto. El número mínimo de fuentes de alimentación es 1. Si queremos que este servidor tenga un alto grado de disponibilidad, nos aseguraremos de que tenga fuentes de alimentación N+1, o en este caso, fuentes de alimentación duales. Si sólo hay una fuente de alimentación y falla, se lleva consigo el servidor. Si tenemos una fuente de alimentación adicional, una unidad de repuesto, la pérdida de una fuente de alimentación no hará que el servidor se caiga. La redundancia es algo grandioso y un componente esencial para una infraestructura de alta disponibilidad.
Al diseñar un sistema Oracle RAC, el DBA debe determinar cuántos nodos se necesitan para satisfacer las demandas del usuario final. Si el DBA determina que se necesitan 4 nodos y este clúster de RAC debe exhibir características de alta disponibilidad, entonces es fundamental que el DBA cree un clúster de 5 nodos (4+1). Si las demandas de recursos son suficientes para mantener ocupados 4 nodos y se pierde un nodo, los 3 restantes no podrán mantenerse al día con la carga de trabajo. Si el DBA crea el sistema RAC teniendo en cuenta la capacidad N+1, los usuarios finales no notarán la pérdida de un nodo. Si el DBA crea el clúster RAC sin redundancia N+1, entonces la pérdida de un nodo puede ser tan terrible para el rendimiento del usuario final que todo el clúster podría estar inactivo. Al diseñar sus implementaciones de RAC, busque la redundancia N+1.
Recuerdo que hace dos años, tenía un clúster RAC que perdió un nodo. No hay problema, todavía teníamos dos nodos disponibles. Mientras observaba el rendimiento de los dos nodos restantes, parecían bastante abrumados. Nuestro centro de llamadas comenzó a recibir quejas. Trabajé con otros administradores del equipo de TI para que ese nodo volviera a funcionar lo más rápido posible, pero puede que no siempre sea así si el motivo de la interrupción está relacionado con el hardware y es necesario reemplazar las piezas. Después de que el nodo volvió a estar en servicio, supervisé el rendimiento del clúster durante semanas. Nuestro uso ha crecido desde que este sistema fue diseñado inicialmente. Inicialmente habíamos diseñado este sistema con la redundancia N+1 en mente, pero nuestro uso creció y N pasó de 2 a 3. Nuestro clúster actual de 3 nodos ya no era redundante N+1. Así que trabajé con la gerencia para poner en el presupuesto del próximo año fondos suficientes para adquirir un nuevo nodo y asegurarme de que Oracle tuviera la licencia para él. Duermo mucho mejor por la noche sabiendo que vuelvo a la redundancia N+1.
Al igual que muchas implementaciones, mi sistema RAC no es la única característica de alta disponibilidad integrada en nuestra infraestructura. Esta base de datos RAC es primaria para una base de datos física en espera con Data Guard de Oracle. Me sorprende cuando hablo de la base de datos en espera de RAC con otros DBA de Oracle, cuántos de ellos no están pensando en la capacidad N+1 para su espera. La base de datos física en espera es mi red de seguridad en caso de que el centro de datos principal no esté disponible por algún motivo. He visto a tantos DBA de Oracle implementar una única instancia en espera para un RAC principal de varios nodos. ¡Ay! Espero que nunca tengan que fallar. Toda la carga de trabajo de su clúster RAC de múltiples nodos tendrá grandes dificultades en ese modo de espera de una sola instancia. Entonces, mientras diseña sus implementaciones de RAC tanto para el primario como para el standby, considere las implicaciones de la redundancia N+1 en el diseño de la arquitectura.
Donde probablemente difiero de muchas personas es que mis implementaciones físicas en espera no son compatibles con N + 1, sino N. Omito el nodo adicional redundante para mi espera física. ¿Porqué es eso? Puramente desde una perspectiva de costos. Mi reserva física es solo una red de seguridad. Quiero que me funcione el día que lo necesite. Pero espero que nunca lo necesite. La reserva física es mi póliza de seguro en caso de que el riesgo se haga realidad. Para mí, ese "+1" adicional en el sitio de espera es un seguro excesivo. Puedo ahorrar en hardware físico y licencias de Oracle.
Así que digamos que llega el día y hago una conmutación por error al modo de espera. He perdido mi redundancia N+1. Pero, ¿cuáles son las posibilidades de que pierda el centro de datos principal *y* pierda uno de los nodos en mi clúster de reserva? Posibilidades bastante escasas. La probabilidad de fallas en dos sitios al mismo tiempo es bastante pequeña. En este punto, nuestro equipo de TI está evaluando por qué se perdió nuestro centro de datos principal y cuándo es más probable que podamos regresar nuestras operaciones a esa instalación. Si el centro de datos principal perdió toda su energía y la empresa de servicios públicos dice que el servicio se restablecerá mañana, simplemente ejecutaremos en el centro de datos en espera aunque solo tengamos N nodos para la base de datos de RAC allí. Sin embargo, si el centro de datos principal fue arrasado por un incendio, pasarán muchos meses antes de que vuelva a estar en funcionamiento. Es en este punto que debo planear que el modo de espera físico tenga una redundancia N+1, ya que el tiempo que usaremos ese modo de espera como principal será mucho más largo. Así que nos apresuramos a pedir otro servidor y lo agregamos al clúster lo antes posible. Así que diseño mi base de datos RAC en espera como N, no como N+1, con miras a aumentarla a N+1 en poco tiempo si determinamos que usaremos la base de datos en espera de verdad durante un período de tiempo más largo.
Así que hay otro caso especial que me gustaría discutir. Ahí es donde el DBA determina que N=1. Para los requisitos de carga de trabajo actuales, un nodo es suficiente. Pero queremos tener una alta disponibilidad, por lo que diseñamos un clúster RAC de dos nodos para la base de datos principal. Ahora tenemos redundancia N+1 integrada en el primario. Siguiendo mi último párrafo, mi base de datos en espera solo necesita 1 nodo. El error que veo que cometen algunas personas es crear la base de datos en espera como una sola instancia. Hasta ahora, su lógica tiene sentido. El principal es N+1 y el de reserva es N. Hasta ahora todo bien. Donde difiero es que convierto el standby en un clúster RAC de un nodo, no en una implementación pura de una sola instancia. La razón es para el crecimiento futuro. En algún momento, el DBA puede encontrar que N ya no es igual a 1 en el primario. El uso ha crecido y N debe ser 2 ahora. El DBA quiere hacer crecer el primario a 3 nodos (2+1). Esto se reduce fácilmente sin tiempo de inactividad para agregar un nuevo nodo al clúster y extender la base de datos de RAC a ese nuevo nodo. Pero no es tan fácil hacerlo en espera para convertirlo en un clúster de 2 nodos si ese 1 nodo que existe no está habilitado para RAC. Si todo lo que existe es un modo de espera de instancia única pura, el DBA debe desecharlo y moverlo a un clúster de dos nodos. Si el DBA tuvo previsión e instaló Grid Infrastructure como si el standby físico fuera un clúster de un solo nodo, entonces todo lo que tiene que hacer el DBA es agregar un nuevo nodo, tal como lo hicieron en el lado principal.
Mientras diseña sus implementaciones de RAC, considere asegurarse de tener capacidad N+1 en el primario y al menos N en el standby. Si una empresa determina que el modo de espera es demasiado crítico, es posible que desee implementar N+1 también en el modo de espera. Si el DBA determina que N=1, considere hacer que el standby sea al menos un clúster RAC de un solo nodo.
