Oracle está impulsando mucho el uso de RAC. Obtendrá una alta disponibilidad, una escalabilidad increíble, una vida personal muy mejorada, la posibilidad de particionar las cargas de trabajo, comprar servidores Linux baratos y lo que sea.

Suena muy bien. ¿Cómo puede alguien decir que no a ese tipo de oferta?

RAC no es OPS pero se parece mucho

El marketing de Oracle se esfuerza mucho por distanciar RAC de OPS, y no entiendo por qué.

Es decir: Si el código básico existe desde hace muchos años significa que es estable, depurado y probado.

Si es todo nuevo, ¿quién se atreve a instalarlo en un sistema crítico?

Afortunadamente, no es cierto que RAC no sea OPS.

Las partes básicas del código -GES y GCS- son prácticamente las mismas de siempre.

GES significa Global Enqueue Service y GCS significa Global Cache Service. Más adelante hablaremos de ello.

Un poco de historia: OPS fue creado para la versión 6 de Oracle. Los únicos clusters que existían entonces eran los clusters VAX/VMS, pero desafortunadamente el VAX/VMS Distributed Lock Manager (DLM) fue creado originalmente para manejar la coordinación de relativamente pocos recursos, como archivos y dispositivos, no 1000s de buffers en una caché de buffers (Oracle u otros). Resultó ser demasiado lento para OPS.

Así que Oracle tuvo que crear su propio DLM para VAX/VMS, y lo hizo. Sin embargo, les llevó un tiempo, así que no fue hasta la versión 6.0.35 (que se llamó «6.2» para celebrar la función OPS) que finalmente salió.

Recuerdo haber asistido a una de las primeras clases de OPS (en Chicago) poco después de incorporarme a Oracle y pensar que el departamento de desarrollo de Oracle se había vuelto loco al crear su propio DLM en lugar de dejar que los chicos de Digital lo hicieran (después de todo, ellos habían creado los clusters y todo el concepto).

Estaba equivocado. El propio DLM de Oracle funcionaba muy bien, y Digital adoptó la tecnología y las ideas de Oracle en su propio DLM, así que cuando salió la versión 7 de Oracle, fue de nuevo el DLM nativo de Digital el que se utilizó.

Los vendedores de UNIX empezaron entonces a hacer Clusters (bueno, NCR lo había hecho durante un tiempo). Y en su mayoría obtuvieron la tecnología DLM de Oracle.

Microsoft ciertamente no obtuvo su tecnología DLM de Oracle cuando comenzó a hacer clusters de Windows. Oh no. La obtuvieron de Digital.

PING

Oracle tenía que asegurarse de que un búfer no fuera modificado por dos procesos diferentes al mismo tiempo – ¿cuál debería escribirse en el disco más tarde? Así que en lugar de «sólo» serializar el acceso a una copia del bloque en un búfer (lo que puede lograrse con la combinación de cubos de hash, cadenas y latches que tan bien conocemos), Oracle tuvo que coordinar varias copias en varias cachés de búferes a través de los nodos.

Esto se lograba utilizando un nuevo tipo de bloqueo (llamado Parallel Cache Management o PCM locks) que se coordinaba entre nodos/instancias utilizando el DLM y varios procesos en segundo plano.

Cuando se producía un «conflicto», es decir, cuando más de una instancia solicitaba el mismo bloque o buffer, el bloqueo «exclusivo» del primer «titular» tenía que pasar a ser un bloqueo «compartido» por todos los «titulares». Esta reducción/compartición sólo podía hacerse asegurándose primero de que todos los titulares veían la misma imagen del bloque/buffer.

Así, la copia del bloque que estaba en la caché del búfer del primer titular se escribía en el disco y luego esa copia del bloque se leía en las otras cachés del búfer. El término «ping» se introdujo para describir a otras instancias que solicitaban un búfer mantenido exclusivamente por una instancia.

El ping a través del disco es lento. Si tienes un índice en una columna que sigue creciendo en el lado derecho, el bloque de la hoja más a la derecha podría ser pingado de ida y vuelta sin parar entre las instancias. Hacer ping a través del disco podía acabar con el rendimiento del sistema.

Las soluciones incluían el particionamiento de datos, los tablespaces temporales (introducidos en la 7.3) donde cada instancia tenía su propio latch en lugar de un bloqueo de diccionario compartido (ST- lock – ¿recuerdas el ora-1575?), los índices inversos (7.3) que significaban que era aleatorio el bloque de hoja que se golpeaba incluso si se tenía una indexación monotónicamente creciente) y otros trucos.

Oracle 8i: Introducción de Cache Fusion

Oracle 8i (es decir, 8.1 donde el punto se ha movido encima del 1) introdujo una nueva forma de hacer ping a través del mecanismo HSI (High-Speed Interconnect) o similar, es decir, una especie de transporte de memoria a memoria en lugar de memoria a disco a memoria. No es fácil de hacer, y al principio sólo se hacía para los bloques/buffers de CR.

Funcionó para algunos y no funcionó para otros. En varias instalaciones de OPS aquí en Dinamarca tuvieron que desactivarlo deliberadamente en 8.1.6 y 8.1.7.

Por cierto: Oracle había introducido su propio mecanismo genérico de Lock Manager (LM) en Oracle 8.0, señalando que pronto sería bastante independiente del código DLM de los distintos proveedores.

Se podría decir que el LM era el equivalente a que el código fuente de Oracle fuera independiente del SO y tuviera una pequeña capa en el código conocida como OSD (Operating System Dependent). Con la introducción del LM integrado, Oracle sólo tuvo que gestionar una pequeña capa dependiente del SO para cada puerto – el resto era código genérico. Respeto de nuevo a los ingenieros de Oracle Development.

Oracle9i: Cache Fusion por todas partes – y un nuevo nombre

Con Oracle9i (llamado 9.0 y 9.2 sólo para confundir al enemigo) todo el ping se hace a través del canal de memoria o de la interconexión de alta velocidad. Eso es todo.

Pero, al igual que en su día llegó el momento de llamar a la versión 6.2 en lugar de 6.0.35, también llegó el momento de llamarla RAC en lugar de OPS.

Los vendedores de Oracle empezaron a despreciar el OPS que habían promovido durante una década. Al menos lo hicieron aquí en Dinamarca.

Gran parte del funcionamiento de RAC es, por supuesto, igual que el de OPS (y todavía funciona en muchas instalaciones).

Por supuesto, el RAC es más inteligente. Mucho más inteligente. La tecnología ha mejorado mucho, etc.

Pero no hay que olvidar que los ingenieros de Oracle se basan en un código sólido y probado que luego han mejorado. Por ejemplo, las capas GES y GCS en el código.

Si tienes un sistema que necesita estar en funcionamiento unos segundos después de un fallo, probablemente necesites RAC.

También puede comprar un sistema lo suficientemente grande como para ofrecer la potencia de CPU y/o la memoria que necesita, probablemente necesite RAC.

O tal vez necesita cubrirse las espaldas políticamente en su organización, puede optar por comprar clusters, Oracle, RAC y lo que sea, y entonces podrá decir con seguridad: «Hemos comprado el equipo más caro conocido por el hombre. Es imposible que sea culpa nuestra si algo va mal o el sistema se cae».

Si no es así, probablemente no necesites el RAC. Las alternativas suelen ser más baratas, más fáciles de gestionar y bastante suficientes.

También puedes leer en nuestro blog ¿Dejar Oracle por PostgreSQL?


0 comentarios

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *