Una de las cosas más interesantes de Solaris es Dynamic Reconfiguration, esta característica nos permite "Reconfigurar Dinámicamente" muchos de los recursos de sistema. Además, los conceptos de Hot-Swap nos permiten tener un sistema 99.9 uptime aunque tengamos "problemillas" de Hardware.
En Solaris 10 se introdujeron las Zonas como un contenedor de Instancia de Solaris con sus propios parámetros de configuración con la idea de optimizar al máximo los recursos de los servidores. Hay que decir que yo soy un enamorado de las zonas, sin embargo, también veo que en la actualidad nos han hecho retroceder años, me explicaré mejor.
La configuración de una zona se establece con zonecfg y ésta sólo es leída cuando hacemos un boot de la zona, por lo tanto, aunque cambiemos dicha configuración, sólo será efectiva después de hacer un reboot. Qué supone esto? Pues bien, imaginemos el caso que, por el motivo que sea, necesitamos darle más IO a nuestro Oracle, así que nos conectamos a la SAN y creamos una nueva LUN/Array, la asignamos a nuestro Host y listo. Solaris, ve inmediatamente la nueva LUN y ... sorpresa! Si queremos asignarla a nuestra zona como raw device, podremos añadirla con zonecfg add device, pero no se verá hasta el siguiente reboot.
Es cierto que podemos crearnos una LUN en loopback e ir "añadiendo" puntos de montaje, pero el impacto en el rendimiento es muy grande.
Ahora bien, vamos a suponer que no tenemos impacto en IO y sí en CPU, nuestro pedido de SysB acaba de llegar, y abrimos nuestra máquina, pinchamos la SysB y Solaris la reconoce sin rebootar, pero ... sorpresa! Si tenemos configurado la propiedad capped-cpu en nuestra zona, aunque modifiquemos el valor, nos pasará lo mismo que antes.
Es cierto que podemos dejar la Zona sin el valor de capped-cpu, o a un valor de ncpu en vez de cpu, pero entonces de qué nos sirve la separación de recursos?
En definitiva, el uso de Non-Global Zones tiene algunos problemas en cuanto a Oracle y su configuración dinámica se refiere, pero si lo que deseas es tener un entorno estanco y limitado por recursos es una buena solución.
Conclusión
Antes de subirnos al carro de las Zonas en Solaris, hay que evaluar si los requisitos de reconfiguración en caliente son un valor añadido sobre nuestro sistema, además de analizar si las ventanas de mantenimiento son los suficientemente amplias para rebootar la zona, una y otra vez.
Referencias
- Comando básicos de Solaris, y no tan básicos
- Instalar Oracle 10g2 en Solaris 10 - Parte 1
- Instalar Oracle 10g2 en Solaris 10 - Parte 2
- Instalar Oracle 10g2 en Solaris 10 - Parte 3
- Instalar Oracle 10g2 en Solaris 10 - Parte 4
- Cómo cambiar el planificador por defecto de Solaris
- Activar Oracle Dynamic Intimated Shared Memory
- Instalar Varias DB en Solaris 10
- Configurar PSET en Solaris 10
No hay comentarios:
Publicar un comentario