sábado, 19 de octubre de 2013

Un DBA en el Barcelona VMworld 2013

La semana pasada se celebró en Barcelona el VMworld 2013, seguramente el segundo evento tecnológico más importante que se celebra en el país después del Mobile World Congress.

Sin duda lo mejor del VMworld fue encontrar a varios compañeros e intercambiar impresiones con ellos, además estoy seguro que podrán explicar el evento en si mejor que yo. En mi caso me limitaré a dar un punto de vista muy particular, el punto de vista de un DBA de Oracle.

VMware empezó virtualizando servidores y ha acabado cambiado la vida del Administrador de Sistemas por completo. Escritorios, aplicaciones virtuales, red virtual, almacenamiento virtual... desde casa y entrando en una web podemos gestionar un CPD en cualquier lugar del mundo. Es fácil imaginar las OPORTUNIDADES que pueden llegarse a plantear ante una situación así.

Creo que ese el objetivo del nuevo hype del "Software Defined": multinacionales con administradores de sistemas remotos, SysAdmins as a Service. Pero en el mundo de las bases de datos ese paso ya se dio hace algunos años, el máximo exponente lo tenemos con Phytian con personal repartido por todo el mundo, pero a nivel local también podemos encontrar ejemplos (esta vez evitaré la publicidad).


Así que ¿cual debería ser el objetivo de un DBA en el VMworld? creo que mejor os dejo la tabla que presentó Charles Kim (Oracle ACE Director) en el mismo VMworld:

CLI DBA
Early 90' DBAs
GUI DBA
Late 90' and Dot Com
Google DBA
Dot Com and 2000's
iDBA
Dot Com, IOUG DBA Master Curriculum
RAC DBAs
2000+ after 9.2 (but major spike with 10.2)
DMA
2010+ Database Machine Administrator
vDBA/vRAC DBA
2010+ Evolving role of a DBA in the virtual world
Cloud DBA
2011+ Database Consolidation with Private Database Cloud Oracle Database 12c Launches June 2013

Su presentación fue "Virtualizing Mission Critical Oracle RAC with vSphere and vCOPs" y presentaba el objetivo de un Cloud DBA:

Aprovisionar servidores Oracle RAC de forma eficiente.

La eficacia se presupone y lo importante es aprovechar las herramientas disponibles para conseguir desplegar una instalación en el menor tiempo posible. A través de instalaciones pre-cocinadas  y aprovechando -como no- el Oracle 12c Multitenant, una opción que completa una de las FORTALEZAS de Oracle: su flexibilidad. Lo único que falta es la consola de vCOPs para que el cliente pueda ver con un simple semáforo si su base de datos (que tantos dolores de cabeza le da siempre) va bien o no.



Este es el mundo de un DBA o un SysAdmin remoto cuando se desplieguen los Software Defined Datacenters, trabajar bien pero sobre todo rápido.

Completando el DAFO
Una de las formas de tener una visión completa de la situación en la que nos encontramos es realizar una análisis DAFO y sólo me faltan dos puntos:

Parece que nadie se cuestiona montar Oracle RAC sobre VMware, y es que aunque podamos hacer un vMotion de una instancia sin demasiado problemas, RAC sigue siendo la única solución que nos asegura una protección real contra la caída de un servidor físico (en este caso el host ESX). Pero hace tres años que se espera una funcionalidad para vSphere: Multiprocessor Fault Tolerance de la que se hicieron algunas demostraciones con una versión beta, y diría que está al caer.

Con el FT que disponemos en la actualidad conseguimos alta disponibilidad de forma independiente a la aplicación que queramos proteger. El coste es alto, ya que estaremos ejecutando una copia de nuestra máquina que además se estará sincronizado "online". Pero en la actualidad se trata de un servicio muy restrictivo, es posible que el más restrictivo que tenga VMware.

Con Multiprocessor FT se pierden esas restricciones:


Uniprocessor FTMultiprocessor FT
# of vCPUs1>= 1
Cluster interoperabilityPractically identical CPUs, ESX versionsEVC compatible (CPUs, ESX versions)
HW assisted memory virtualizationNoYes
Hot enable FTNoYes
VMDK redundancyNoYes
VADP VM backupNoYes
FT network1 Gbps10 Gbps

Básicamente se convierte en un servicio que no dudaremos en activar en nuestros equipos críticos (si tenemos recursos claro). Si tienes RAC por la disponibilidad y tu instalación es virtual... creo que tenemos una gran AMENAZA a la vista. El otro motivo para instalar RAC es la escalabilidad, pero con el hardware virtual y la posibilidad de migrar tu equipo a un Host con más potencia o la capacidad de añadir memoria y vCPUs en caliente... algo se nos ocurrirá.

Sobre las licencias hablaremos otro día.

Me faltan las DEBILIDADES, y en este caso creo que hay una y muy grande: la copia de seguridad.

No estoy hablando que las copias de seguridad de Oracle sean malas, si tuviera que pagar por una de las funcionalidades de Oracle como opción tengo claro que sería RMAN. Todavía me sorprenden sus funcionalidades y sencillez (una vez las conoces), pero falla en su integración con terceros.




Ya he tenido el "placer" de pelearme con varios productos que lo pretenden sin alcanzar ese "algo más" que observo en las integraciones con SQL Server, donde se simplifican las copias de seguridad y la recuperación a niveles extremos. Durante el VMworld pude disfrutar de una pequeña demo de Veeam con SQL Server y la verdad... creo que sentí envidia...

Conclusión
Si el futuro del DBA de Oracle pasa por el Cloud, la flexibilidad que ofrece el producto y las nuevas funcionalidades de la versión 12c ayudar mucho. Pero con poco de perspectiva nos damos cuenta que quizás cosas que hoy en día nadie ponen en duda en breve se convertirán, como mínimo, en una gran duda.