Bacula Vol I

Hoy toca iniciar otra serie de entradas de “divulgación informática” (sin olvidar otras pendientes o en curso, q todo llegará a su debido momento), algo asi como una “Introducción a la gestión de copias de seguridad con fundamento”. La idea es no solo montar un Bacula sino refrescar un poco los típicos conceptos del mundillo de las copias de seguridad para tenerlos bien amarrados y asi poder saltar a otras soluciones con facilidad.

Qué es Bacula y cuándo utilizarlo

Bacula es un software libre que realiza copias de seguridad a nivel de fichero. Punto. Ni es un sistema para hacer imágenes completas ni está´orientado específicamente a restaurar sistemas totalmente descojonados, aunque puede ayudar claro está.

La diferencia fundamental entre el típico scripiti que todos nos hemos currado en bash en algún momento, tirando de herramientas como cp o dd o tar para hacer copias de ficheros, rotarlos y moverlos a otras máquinas, y Bacula son 2 fundamentalmente:

• Bacula mantiene un Catálogo en base de datos donde se registran todas las operaciones realizadas.
• A grandes rasgos Bacula implementa 2 módulos independientes: el Director o programa que gestiona las copias de seguridad, y los agentes, instalados en cada máquina a hacer backup.

Como se verá a lo largo de estos articulillos este esquema está muy simplificado ya que en realidad el sistema permite desgranar sus diversas funciones en otros tantos procesos independientes, de forma que retengamos el máximo control a la hora de hacer el deploy de las diferentes piezas para poder así disponer de un sistema bien balanceado. Si embargo a los efectos puede que sea complicar innecesariamente la solución ya que la mayor parte de la gente solo va a tener 1 servidor de copias y luego n agentes desperdigados por la red, tal y como se muestra en la figura. En este caso concreto la máquina que alberga al Director tendrá también el Catalogo y los sistemas de almacenamiento (típicamente cintas o disco duro) directamente conectados; por la otra parte habrá agentes, uno en cada servidor que vayamos a copiar.

Sobre las plataformas soportadas solo decir que el agente funciona tanto en el mundo Windows como Linux o Mac pero el Director solo rula Linux que yo sepa. No voy a tratar temas concretos de Sistemas Operativos en esta serie de artículos asi que mas o menos y con las salvedades típicas en este mundillo (Unidades, ACLs etc) , todo lo que se diga es “SO independendent”.

Tampoco se verán temas específicos de cintas: se trata de visualizar un poco el tema de forma general concretando para un caso particular y dando las herramientas necesarias para poder retorcer la configuración a nuestro gusto, ampliando la lectura de lo aqui expuesto, y no de resolver “porque mi distro no me detecta la cinta de marca tal”.

Procesos

Vamos a poner nombre y función a los procesos que intervienen en este tinglado aunque por la figura de arriba bien se pueden intuir cuales van a ser:

• Director: es la madre del cordero. Podemos pensar en el Director como en un director de orquesta y en un router de datos: dice cuando hacer las cosas, obtiene los resultados y los manda a los procesos necesarios.
• File Daemon (FD): Es el Agente de la figura: un proceso que corre en el servidor del que vamos a hacer la copia. Recibe ordenes del Director, inicia las copias y se las pasa a éste.
• Console: no esta representado en la figura, es un proceso que se conecta al Director para administrar el servicio. Hay varios tipos de consola soportados pero aqui se usara el principal, la consola de línea de comandos, que es la mas completa de todas las opciones.
• Storage Daemon (sd): Es el proceso que maneja los medios de almacenamiento. Normalmente van a estar conectados al Director pero podría ser que tuviéramos un servidor externo conectado a una cabina de discos, o de cintas. Este proceso recibe los datos y los vuelca en los medios definidos.
• Catalog: es un proceso que interactúa con la base de datos que contiene el catalogo. Típicamente también va en la maquina que alberga el proceso Director pero puede ir en una independiente. El Catalogo será explicado mas adelante, pero para ir afinando diré que es una base de datos donde quedan grabados todos los procesos de copia y la información de todos los ficheros que lo componen, con su fecha y hora, tamaño de cada fichero y de la copia completa, lugar donde se restauran, lugar donde se almacenan físicamente etc. Es una especie de índice de todo lo que va ocurriendo. Ojo que no contiene los datos, los ficheros en si mismos. La consola entonces es, en esencia, un traductor o front-end de la base de datos formado en base a comandos más o menos amigables, generando las sentencias Select necesarias sobre esa base de datos y recabando y formateando los resultados. El catalogo en si mismo puede estar almacenado en MySQL, SQLite o PostGreSQL. Aqui se usara MySQL aunque para volúmenes muy bajos de datos quizá valga con SQLite.
• Monitor: tampoco queda reflejado en la figura anterior y de hecho este modulo no lo vamos a tocar. Solo funciona en GTK+ asi que lo suyo seria instalar unas X en el Director (cosa que no haremos) para poder ejecutar ese programa, que nos reporta de forma grafica el estado de las copias y el de cada uno de los procesos aqui descritos.

En resumen: tenemos un Director que pide datos a los FD y los manda al SD que los graba en el medio de almacenamiento definido. A su vez el Director envía datos de carácter informativo (algo asi como MetaDatos) al Catalog que los escribe en el motor de base de datos de nuestra elección. Y de regalo tenemos una consola que se conecta al Director para ver el estado de las copias, listar su contenido etc.

Conceptos y términos

A continuación indico los conceptos fundamentales sobre los que descansa todo el entramado. Esto no solo hay que tenerlo claro sino que hay que manejarlo con soltura. Primero lo suelto a zorrombollón y luego desgrano un poco.

“Una copia de seguridad esta formada por una serie de Jobs de varias Clases y Tipos, que involucran diferentes FileSets obtenidos de uno o mas FDs, grabados en uno o mas Pools de Volúmenes ejecutados según se defina en un Schedule.”

El Job o Trabajo define practicamente todo lo necesario para empezar a funcionar en Bacula:

1. El “Qué” se copia: Se copia el resultado de aplicar un FileSet (definiciones de grupos de ficheros, con inclusiones y exclusiones de directorios, tipos de archivos por extensión etc)
2. El “De Donde” se copia: Los datos se obtienen de aplicar un FileSet a uno o varios FDs (File Daemon, los agentes instalados en los servidores a copiar)
3. El “Cuando”: el Scheduler indica que días, a que horas y con que periodicidad se lanzan los Jobs.
4. La Clase del trabajo: restauración, backup o verificación.
5. El Tipo: Completa, incremental, diferencial.
6. El “Hacia Donde se copia”: donde se dejan las copias. En primera instancia se envían al SD (Storage Daemon) pero además se indica la agrupación de medios de almacenamiento (Pool formado por Volúmenes) donde se dejaran los datos: típicamente un grupo de 7 cintas para hacer el rotado diario, un grupo de 4 cintas para el semanal etc…

En resumen: tenemos una copia de seguridad formada por el  Job “copia webs” de clase “backup” y de tipo “Full” (copia completa), que se conecta al FD “servidor Web” con un FileSet que incluye  el directorio local al servidor web “/var/html/” del que sacara todos los ficheros a copiar, dejando los datos en el Pool “Webs” formado por 7 Volúmenes (cintas) llamadas “Copia-x“, donde x será la fecha de la copia, que el Scheduler lanzará a la 1 de la mañana todos los días.

Un diagrama complementario podría ser el siguiente:

Vemos al Director recibiendo los ficheros a hacer backup desde los File Daemon (lo que se copia de cada File Daemon se define en un FileSet o set de ficheros), enviando la información del Job al Catalogo (que puede ser un servidor externo con MySQL o el mismo Director), recibiendo instrucciones del cuando hacer la copia por parte del Scheduler y enviando los ficheros al Storage Daemon que en este caso tiene una única unidad de cinta conectada y el Pool “1” definido, que consta de 2 Volúmenes, de tipo cinta, que el administrador del sistema cambiara cuando el Bacula se lo pida.

Prácticamente esto es todo lo necesario para empezar a trabajar con Bacula; no obstante en la próxima entrega ampliaremos un poco mas algunos de los conceptos vistos, ya que hay cosas como los Pools, los Volúmenes y su reciclado o el mismo Catalogo que merecen ser bien tratados.

Txoria Txori

Nacionalismos al margen, aqui va una de las canciones que mas me ha conmovido desde que vi la película / documental: La pelota vasca, la piel contra la piedra. Se trata de una versión del clásico “Txoria Txori” de Mikel Laboa que ya conocía pero mucho mas orquestada y orientada al concierto que el minimalismo del que hacia gala el autor en el original. Esta versión la busque durante mucho tiempo pero no ha sido hasta hoy que, oyendo un anuncio en la radio retome la búsqueda; la diferencia es que hoy tengo Spotify: todo ha sido poner el nombre del autor y comprobar todas las versiones de la canción. No me ha llevado mas de 2 minutos.

La letra original reza asi:

Hegoak ebaki banizkio
nerea izango zen,
ez zuen aldegingo.
Bainan, honela
ez zen gehiago txoria izango
eta nik…
txoria nuen maite.

y la obligada traducción:

Si le hubiera cortado las alas
habría sido mío,
no habría escapado.
Pero así,
habría dejado de ser pájaro.
Y yo…
yo lo que amaba era un pájaro.

La podeis descargar de aqui.

Memories of Murder

 

De tanto en cuanto aparece una película que me impresiona de alguna manera , y aqui estamos con una de esas.

La película sorprende por la capacidad que tiene de hacerlo, y es que una de polis con serial killer de por medio pues como decir… es que ya esta todo tan masticado y contado que francamente no me esperaba nada de nada cuando empecé a verla.

No se muy bien que es lo que me ha llamado la atención: la película es coreana y arranca casi como una comedia, en parte porque ver actuar a los koreanos estos, tan bajitos y con esos movimientos tan nerviosos siempre me da la sensación de estar viendo un sketch de Benny Hill o algo similar. Sin embargo, en un punto no muy bien definido en la película, las cosas se ponen duras hasta desembocar en la escena que encabeza esta entrada y que me pareció una de las mas bellas de la película: como la integridad de una policía muy denostada en su conjunto y porque no decirlo, incompetente, se sobrepone a la desesperación de no encontrar al asesino y al consecuente impulso de culpar al primer pringado que se ponga a tiro. La escena final también me pareció muy destacable, la expresión del rostro del protagonista, varios años después y con otro trabajo y familia, refleja con fidelidad lo que realmente es: un Investigador con la I mayúscula (y a pesar de sus limitaciones). Es por tanto un detalle muy interesante y bastante bonito de ver como lo que en principio se nos presenta como un zoquete necesitado de la ayuda de un experto extranjero para sacar adelante una investigacion en principio sencilla, va evolucionando hasta darse un baile de papeles.

Ciertamente una película con buenas interpretaciones, fotografía, puesta en escena y una muy destacable la contribución de Taro Iwashiro, con una banda sonora muy clásica y musical, con gran protagonismo para el piano. La podeis descargar de aqui.

Implementación de replicas instantáneas, de combinación y transaccionales en SQL Server 2005 Volumen II

Mis queridos amiguitos amarillos, ha llegado el momento de la verdad, el momento en el que vais a tener que trabajar como chinos, en virtud de ese cliente pelmazo que no para de dar el cacorrio con que sus datos son lo mas importante del mundo mundial. Algo habrá que hacer para que deje de dar la murga y por fin ha llegado el momento de la verdad, lo que los gungans llamaban “la hora del dolor”.

Pero no todo tiene que ser necesariamente malo en las oscuras tierras de Microsoft, donde se extienden las sombras -"Atrás!! llama de Udûn!!!"-, de modo que para traer un poco de claridad al proceloso mundo de las réplicas en SQL Server vamos a elegir un disco de Chill Out que sonará a un volumen moderadamente moderado en vuestros altavoces, al tiempo que le dais a la tecla con alegría y desparpajo. Nunca antes existió cirujano escuchando chill mientras extirpaba un tumor, pero vosotros si que podéis escuchar algo bueno mientras tecleáis; es por ello que vosotros no os coméis los mocos con vuestro suelducho de mileurista mientras que ellos se ponen morados a bogavante, que coge por detrás, te coge por delante.

Bien, el disco va a ser "Café del Mar – Dreams Vol 2", se indica como requisito para poder llevar a buen puerto esta instalación. Si algo falla es q no estáis escuchando el disco correcto.

Para empezar con buen pinrrelillo vamos a partir de una instalación límpida, que consistirá en:

• 2 máquinas Windows 2003 R2 SP2 32 bits que llamaremos diligentemente “Nodo1” y “Nodo2”.
• Nodo1 será el DC principal del dominio y Nodo2 el DC secundario. No trataré aquí cómo montar un dominio porque no es el objetivo, y además hoy en día es insultantemente facil montar lo que otrora era un PDC y un BDC (ahhh que tiempos los del NT 3.5 mas… horrorosos!!) .
• Comprobar que está instalado IIS en ambas máquinas al completo.
• Iniciar ambas máquinas con la cuenta de administrador de dominio e instalar SQL Server 2005 al completo. Las opciones por defecto serán mas que válidas por el momento.

No es necesario que las máquinas sean iguales en lo tocante a hardware ya que en este tipo de entorno todo se resuelve por soft (a diferencia del modo Cluster) si bien yo os recomendaría que para hacer esta prueba os montarais un par de VMwares antes que usar dos máquinas físicas, por comodidad mas que nada (a los efectos da exactamente igual). Apunto aquí una nota mental para un posterior articulo sobre hypervisors, que la cosa esta que hecha chispas en este sector.

Una vez llegados a en este punto no faltarán los que se empiecen a revolver en su silla: “porque un dominio?”, “porque instalaciones completas?” etc. Bueno, yo diría que porque sí y te jodes, pero la verdad es que la cosa no funciona si todas las máquinas que van a participar en la réplica no están metidas en el mismo dominio. Domino eh? no grupo de trabajo, dominio. Las instalaciones completas se hacen para minimizar errores, luego vosotros ya lo iréis puliendo una vez q lo tengáis en marcha. Al hilo de todo esto, solo se va a usar la cuenta de administrador para configurar las credenciales de los procesos necesarios, cosa que es un poco fea como todos sabemos. Un nivel mayor de control se deja al feliz informático que quiera hacer las cosas bien, que de esos hay pocos y se esconden; aqui solo se muestra la base del asunto de forma muy elemental.

Finalmente para quitarnos problemas con las políticas de seguridad del 2003 os recomiendo que configures una contraseña de 8 caracteres con números y mayúsculas para la cuenta de administrador, por si acaso.

 

Presentaciones

Llegados a este punto vamos a establecer como montaremos este primera escenario:

Nodo1

Sera el Publicador y el que tenga la base de datos a replicar, que llamaremos “origen”. La Publicación va a ser de tipo transaccional en un solo sentido (del Publicador al Suscriptor) aunque en el arranque le vamos a enchufar al Suscriptor una instantánea o snapshot fresca y completita.

Nodo2

Será el Suscriptor, va a aplicar la Publicación en la base de datos llamada “destino”. El porqué llamamos a las bases de datos de forma distinta es un poco por claridad pero en el fondo es tontería: imaginar que tenéis una aplicación que dispara contra la base de datos “origen”. Lo suyo seria que si el sistema se cae podre seguir atacando a “origen” pero en el esclavo, de modo que lo suyo seria llamar a las dos bases de datos igual aunque aqui como digo no se hará asi por claridad.

Además, el tercer rol, el del Distribuidor lo podremos colocar donde nos plazca pero nosotros lo haremos en el Suscriptor, para dejar mas libre al Publicador ya que se supone que es la máquina contra la que tiran los clientes normalmente. En este caso, si el Distribuidor está en el Suscriptor vamos a operar por el método “pull” o “polling” que como bien sabemos consiste en preguntar cada 2×3 al Publicador si hay cambios pendientes de aplicar. Poner el Distribuidor en el Publicador implica un esquema de tipo “push” en el que el Publicador “empuja” los datos al Suscriptor, algo en principio más óptimo a nivel general pero particularmente para el publicador mas costoso ya que tiene que ejecutar un proceso adicional, que es el del Distribuidor. Sobre pull vs push se podría hablar un poco más y en próximas entregas quizá se haga si os portáis bien y no dejáis nada en el plato.

Finalmente comentar que toda la configuración del percal se realiza a través del Microsoft SQL Server Management Studio, la herramientilla grafica basada en MMC que trae el SQL Server, y mas concretamente en la rama de “replicación”.

Hechas las presentaciones comienza el baile:

 

Prolegómenos

• Creamos una base de datos de prueba llamada Origen en Nodo1.
• Creamos una tabla de nombre “miTabla” con 2 campos de tipo nchar(10) que llamaremos Clave y Datos.
• El campo Clave será la clave primaria.

 

OJO: TODAS LAS TABLAS TIENEN QUE TENER CLAVE PRIMARIA!. Si la base de datos que queréis replicar no tuviera una clave primaria en TODAS las tablas se la añadís a manubrio. Si no lo hacéis el proceso de réplica casca y os iréis a casa taciturnos y cejijuntos, os lo digo ahora, luego no me vengáis con lloros y malas caras.

• Creamos la base de datos Destino vacía en Nodo2.

Ahora tenemos todo lo necesario para poder configurar la réplica. Hay que adelantar que el proceso puede resultar un poco confuso porque a pesar de que se nota que el interface gráfico tiene unas cuantas vueltas no es lo suficientemente claro. Por ejemplo no queda representado de forma gráfica el rol del Distribuidor y además la secuencia de pasos que hay q seguir no es del todo lógica (lo lógico seria configurar primero el Publicador y luego el resto pero hay que empezar por el Distribuidor, el rol mas “gris” de los 3).

 

Nodo2

Como nuestro Distribuidor va a estar en Nodo2 lo configuramos allí:

 

• Ahora tendremos que seguir el Wizard (que de Wizard no tiene mucho la verdad) rellenando los datos necesarios:

 

• Se nos pregunta donde va a ir el Distribuidor, por defecto se ilumina Nodo2 y asi que lo dejamos. Como hemos dicho antes el Distribuidor podría ponerse en otra máquina, que no será el caso.

 

• Aqui se nos pregunta el path donde reside el snapshot inicial. Ojo al dato que nos lo rellena con un path local tal y como viene en la figura, cosa que en este caso no aplica. Y porque no aplica? porque hemos quedado que en Nodo1 está el Publicador y en Nodo2 el Distribuidor asi que tenemos que decirle al Distribuidor que el snapshot no está en un path local sino remoto. Como se hace esto? facil: ponemos “\\nodo1\recurso_compartido”. No dejarse llevar por el pánico por el hecho de que todavía no hayamos creado el recurso compartido (ni sepamos a donde hay que apuntarlo) en Nodo1. Todo llegará a su debido tiempo mis pezqueñines.

 

• Ahora damos nombre a la base de datos de Distribución. Esta base de datos es de tipo System y nosotros no la tocaremos para nada. Yo la llamo “miDistribucion”.

 

• En esta pantalla se nos esta preguntando por los Publicadores (que todavía no tenemos) que usarán este Distribuidor. Por defecto viene Nodo2 pero eso no es correcto porque el Publicador hemos dicho que lo tenemos en Nodo1 asi que con el botón add lo añadimos y desactivamos nodo2, que de hecho no va a llevar Publicador.
• En la pantalla siguiente se nos pide una password que usara el Publicador cuando quiera realizar labores de administración sobre el Distribuidor. No se por qué no se usa una cuenta del dominio simplemente, cosas de Windows supongo. La cosa: poner la password y recordarla porque la tendréis que introducir en el Publicador cuando lo configuremos más adelante.
• Finalmente se nos ofrece la posibilidad de crear el Distribuidor o en su defecto solo generar la secuencia de comandos para poder nosotros lanzarlos a mano con posterioridad. Elegimos crear el Distribuidor ahora y finalizamos con lo que se nos presentará una pantalla resumen de las sabias elecciones tomadas en el proceso y luego una pantalla de progreso que deberá culminar en iconos verdes con un OK bien grande.

Llegados a este punto nada parece haber cambiado a simple vista en la MMC ya que no hay icono asociado al Distribuidor como decía, si bien se ha creado una base de datos de sistema llamada “miDistribucion” con lo que la cosa se supone va por su camino.

 

Nodo1

Pasamos al Nodo1.

 

• Creamos una nueva Publicación

 

• Se nos pregunta donde esta el Distribuidor, asi que le decimos que lo tenemos en Nodo2
• Rellenamos la password que introdujimos en Nodo2
• Elegimos la base de datos a replicar (“Origen”)

 

• Aqui elegimos el tipo de réplica que queremos: snapshots, transaccional, combinación etc. Elegimos una publicación transaccional, que nos permitirá además enviar un snapshot inicial como veremos a continuación.

• Elegimos los artículos a incluir en la Publicación: no nos liaremos en absoluto, añadimos la tabla completa de la base de datos Origen.
• Podemos filtrar los datos a Publicar: en el apartado anterior podíamos elegir columnas y tablas, aqui se nos deja construir una SELECT para cribar datos. Sin mas pasamos del tema.

• Ahora se nos interpela por el agente de snapshots: si queremos que genere un snaphost ahora mismo, y si queremos que los genere vía scheduler a horas determinadas (lo cual esta muy fresco porque como ya decíamos “ayer” al hacer un snapshot se bloquea para escritura y selectivamente la tabla que se está copiando, ergo es una opción guapa hacer snapshots a las 3 de la mañana, cuando solo curran los pelotas o los desesperados (o los jartos de coca, que también los hay). Nosotros como no somos ni lo juno ni lo jotro vamos a poner que genere un snapshot ahora mismo y listo.

• Ya para ir terminando se nos pregunta por las credenciales del Publicador para el agente de logs y de snapshots. Para ambos dos le vamos a dar la cuenta de admin del dominio, para que no falte de nada y estén contentos. Esto vuelve a ser una cagada y como tal hay que decirlo pero aqui lo vamos a dejar asi.
• Y como ya es costumbre se nos pregunta si queremos generar el Publicador ahora o mas tarde con unas secuencias de comandos (lo generamos ahora), presentándonos un bonito resumen de las elecciones tomadas, pidiéndonos nombre para la Publicación(yo he puesto “miPublicacion”) y unas alegres barritas de progreso iguales que las del Distribuidor, que también tiene que terminar el verde, color de la esperanza.

En este caso si que hay un cambio evidente en la MMC:

Chulo eh? bueno, que ya queda menos. Mejor dicho, ya no queda nada porque ahora terminamos con el Suscriptor, asi que volvemos a Nodo2

chsst! un momento ahí ! pensabas que se me iba a olvidar eh?? noooo!!: hay que hacer el recurso compartido! –ein? cual recurso?- Despierta hombre! si, el recurso compartido donde reside el snapshot claaaaaro que genera el Publicador y que recoge el Publicador. Bueno pues sencillamente se trata de compartir la carpeta donde reside el susodicho, que es:

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData\

Le dais un nombre coincidente con el que le disteis mas arriba en el Distribuidor y tira millas. Dar permisos de lectura y escritura a granel por cierto.

Nodo2 revisited

 

• Creamos la Suscripción

 

• Elegimos la Publicación ya creada en Nodo1

 

• Elegimos donde queremos ejecutar el Suscriptor, en el equipo que ejecuta el Distribuidor (Nodo2) o en el equipo que ejecuta el Publicador (Nodo1). Esta es la diferencia que mencionábamos antes: push vs pull. Lo dejamos en Nodo2.

 

• Elegimos base de datos de Suscripción. Esto es, el Publicador nos manda los datos y el Suscriptor los deja en una base de datos que nosotros hemos llamado Destino y es el efectivamente la base de datos replicada.

 

• El Suscriptor se tiene q conectar con el Distribuidor así que le enchufamos credenciales frescas de administrador.

 

• Igual que antes se nos pregunta por la periodicidad con la que el Suscriptor busca cambios. Nosotros le vamos a poner que constantemente. Esto se podría rebajar si no fuera necesario estar sincronizados al segundo y asi aligerar la carga de CPU y red primando el tamaño de las transferencias por encima del numero de ellas.
• Se nos pregunta si inicializamos ya mismo la Suscripción con un snapshot o lo vamos a hacer en la primera sincronización. Como hemos dejado el snapshot al crear el Publicador ya preparado le damos candela y le ponemos que ya mismo.
• Y lo de siempre: barras, verdes y parabienes, congratulations you are the best, gracias por confiar en Microsoft y toda la fanfarria y boato necesarios por haber seguido un wizard diligentemente. Estos se deben de creer que somos gilipollas o algo.

Y aqui termina la configuración porque ya es muy tarde y no da tiempo ni para recoger. La replica ahora tendria que funcionar a plena satisfacción, cosa que podeis comprobar si en Nodo1 metéis filas y veis en Nodo2 como se van añadiendo como por arte de birli birloque.

En la(s) próxima(s) entrega(s) vamos a configurar el Distribuidor en el Publicador, a montar una replica en las dos direcciones para el caso de que hagamos inserciones en el nodo2 (y evitar los errores que se dan si ahora mismo hacemos ahora inserciones en Nodo2), a hacernos un poco con la configuración modificándola y retorciéndola y a monitorizar el estado de la replica, reiniciándola y tal. Finalmente nos pondremos la pegata de “replicante” en el pecho al tiempo que disfrutamos con un par de tomas falsas o descartes.

De que mueren tus compañeros?

O mas que compañeros, la gente de tu grupo de edad? Pues pinchas aqui y lo miras.

Abajo tienes los grupos por edades. Sorprende ver en primer lugar el suicidio y las muertes en carretera.

Y desglosado por sexos.

Nuevo Media player de referencia

 

Hace unos días saltaron los de Xataka con una review ciertamente inútil sobre el nuevo modelo de WD, el Wester Digital TV HD Live Media Player, que no pienso linkar de lo vacía que era pero que podéis ver aqui para comprar por 109  espléndidos eurus. 

Una review en condiciones la tenéis aqui. Pcdemano.com es una web que no conocía hasta hace un par de semanas y me ha gustado por lo exhaustivo de sus análisis hardware. Otra web del pelo es http://www.mpcclub.com, mas centrada en MPC y en inglis.

Estos aparatos me encandilan, no lo puedo remediar.

Bonito debate sobre el precio de los pisos

http://www.burbuja.info/inmobiliaria/burbuja-inmobiliaria/133015-porque-la-vivienda-va-bajar-los-proximos-meses-de-forma-desorbitada.html

Implementación de réplicas instantáneas, de combinación y transaccionales para SQL Server 2005 Volumen I

Un cliente coñón, con una empresa de 3 y el del tambor, que no puede vivir sin su preciada base de datos SQL Server pero que no quiere gastarse un puto duro ni en licencias ni en una solución decente (lo normal, lo de siempre, todo es importantisisisimo hasta que llega la factura), me ha obligado a empaparme un poco de la historia q voy a intentar relatar en una serie de articulillos, no mas de 3 espero, y mas de 1 (también lo espero).

El caso: tenemos una base de datos en SQL Server 2005 y queremos sincronizarla / replicarla para tener una copia de respaldo actualizada al momento por si un día peta por los aires poder trabajar sobre el backup hasta que sea remendada. Para ello necesitamos, a saber:

• Windows 2003 Server.
• SQL Server 2005.
• 2 equipos de corte servidor.
• Un buen par de huevos para entender todo este mondongo.

Aclaro que esto esta basado en un pseudo-libro llamado “SQL Server 2005 Manual del administrador” de Mc Graw Hill, obra y gracia del señor William R. Stanek al que no quito ningún merito ni crédito por no tener yo acceso a su obra original (como en la guerra, el valor se le supone). En su defecto tengo la edición española a cargo de un “traductor profesional” llamado Eloy Pineda Rojas que me gustaría tener presente para usar sus testículos como balón de futbol en toda regla y dejárselos como el apellido. Es un caso generalizado comprar libros en castellano pensando que los entenderás mejor que en su idioma origen, y es caso generalizado que el traductor, que no tiene ni puta idea de informática ni quiere tenerla, estropee totalmente lo que otrora fue un hermoso y bonito libro.

Hechas las presentaciones vamos a explicar la teoría, que no es mucha pero que el funesto libro dedica casi 20 hojas de paja, y que para que no os resulte lo mismo de indigesta que me resultó a mi leyendo la castaña ésta, la voy a intentar simplificar con un ejemplo/paralelismo usando a la industria editorial por fascículos, al mas puro estilo Planeta Agostini y a la sazón.

Roles

En el esquema general de un SQL Server replicado tenemos 3 roles principales, para que no falte de nada:

• Publicador.
• Distribuidor.
• Suscriptor.

De esta guisa tenemos que:

• Publicador: el que genera las copias del contenido. Es una empresa que se encarga de “fotocopiar” un original que ha escrito un señor anónimo, y lo hace miles miles miles de veces, para que el Distribuidor lo distribuya allende los mares. En este caso el Publicador es lo que se conoce como una Editorial: la empresa que determina qué es interesante fotocopiar y qué no lo es, es el que determina qué bases de datos van a ser replicadas, que objetos dentro de ellas etc y nos lo va a dejar preparadito para poder desperdigarlo a los 4 vientos. El Publicador puede ejecutarse en la misma máquina que lleva la base de datos de la que el cliente tira normalmente o en otra máquina aparte. Hay que decir que el proceso de publicación no es moco de pavo y carga la máquina notablemente. Por simplificar y dado que tenemos solo 2 equipos en el ejemplo practico que luego desarrollaré, irá en el que lleva la base de datos principal. Pero ojo amiguitos! no confundir el Publicador con el motor de base de datos ni con la base de datos en si misma!! no no y no! una cosa es la base de datos que usa nuestro querido cliente para sus cositas, con su motor de base de datos y tal, otra es el Publicador, que coge partes de esa base de datos para generar otra, igual o menor, que será la Publicación, y que se replicará en el Suscriptor. Nunca confundir, una Publicación es una base de datos subconjunto de la base de datos original, y la genera el Publicador. Coño.
• Distribuidor: el camionero que lleva la publicación al kiosco o a casa directamente. Un proceso que recoge las Publicaciones y las lleva a los Suscriptores.
• Suscriptor: el lector, que rellenó un panfleto en su día pensando que la colección iba a ser 20 fascículos y resulta que son 2 mil. En nuestro caso el Suscriptor es la base de datos donde vamos a replicar los datos que vienen del Publicador y nos son entregados por el Distribuidor.

Resumiendo un poco, el origen de los datos será el Publicador, el destino el Suscriptor y el agente que pasa datos de uno a otro es el Distribuidor. Haciendo una correspondencia con la terminología mas estándar de MySQL el Publicador vendría a ser mas o menos el Maestro y el Suscriptor el Esclavo. Es evidente que SQL Server parte de un modelo mas complejo que MySQL y por tanto mas flexible y potente, como iremos viendo poco a poco. Y es que ésta es la magia de las medias verdades: ambos motores soportan réplica pero es como comparar un 600 con un Ferrari.

Está claro que en este esquema puede haber muchos Publicadores, muchos Distribuidores y muchos Suscriptores pero por simplificar solo tendremos 1 de cada.

Mas cosas: La unidad mínima para la replica es el “articulo“. Es el fascículo en nuestra analogía editorial. Puede ser una tabla completa o partes de ella (filas, columnas, vistas, procedimientos almacenados). Un grupo de Artículos es una Publicación; por si no lo habías adivinado una base de datos completa a replicar podría ser  una Publicación (muchos artículos empaquetados).

Un esquema básico dividido en roles puede ser el siguiente:

 

 

Aquí tenemos una base de datos que actúa como maestro y 3 réplicas. Los roles son desperdigables en máquinas distintas para mejorar el rendimiento; de hecho el publicador por ejemplo es el mas indicado para separarlo del motor de base de datos ya que al poder generar publicaciones bastante configurables (no solo se limita a preparar bases de datos completas sino que puede operar solo con parte de ellas) puede demandar muchos recursos de CPU.

 

Réplicas

Pero que tipos de réplica hay? solo 3  a fe mía, 3 tipos que detallo a continuación:

• Replica de instantáneas: todo el churro completo. Todos los fascículos a cañón. Sale un fascículo nuevo y te los envían todos incluyendo el nuevo. Que no falte de nada. El Amazonas moribundo, y tu nadando en papel como nadaba el tío Gilito en su piscina de monedas amarillas. Es un volcado de la publicación completa: el Suscriptor cuando la recibe hace un Drop de lo que tiene e incorpora lo que le envían.
• Replica transaccional: un fascículo cada vez, un cambio en la base de datos genera una transacción de replica. Puede que queramos apelotonar varias transacciones en una, algo asi como que no nos envíen todos los días el fascículo de la colección que estoy ya muy mayor para bajar todos los días al buzón, mándame todas de golpe una vez por semana.
• Replica de combinación. Este tipo no vamos a tratarlo mucho, por no decir nada. Los datos que se reciben se modifican, se transforman. No es tan común.

Lo normal es un proceso de réplica es comenzar por una instantánea para poner al día al Suscriptor y luego se le van enchufando replicas de transacción, una por cada cambio. Esto en MySQL se suele hacer parando el Maestro o lockeando a mano todas las tablas, copiando la base de datos con “scp” o haciendo un dump y luego montándola en el esclavo. En SQL Server también podemos hacer esto mismo haciendo un backup del Maestro y un restore en el Esclavo aunque la réplica de instantáneas es menos “cutre” y no necesita tanta “mano de obra” ni parar la base de datos aunque cuando se está´generando la réplica el motor de base de datos hará un lock de escritura de la tabla que este replicando en ese momento de modo que los clientes no podrán escribir en esa tabla. Además las réplicas instantáneas permiten ser empaquetadas en un fichero .CAB para minimizar los tiempos de transferencia por red y espacio en disco necesario.

Por otro lado el asunto de las replicas transaccionales da bastante juego ya que en SQL Server la dirección de réplica puede ser en ambos sentidos sin necesidad de bailar roles como sucede en MySQL, así que toca hablar un poco de esto.

Lo normal es que la dirección de la replica sea única: la base de datos genera una Publicación que el Publicador entrega al Distribuidor que aplica en el Suscriptor (el maestro desperdiga los datos en los esclavos) pero esto tiene matices, como se vera a continuación:

En la replica de instantáneas no hay mucha ostia: se envia todo del Publicador al Suscriptor y el Suscriptor se lo come íntegro. Es como si tiraras todo lo que tienes y te quedaras con todo lo que te envían cada vez. El consumo de red puede ser galopante, un chorreo constante de gigas y gigas. Sin embargo en la réplica transaccional el Suscriptor puede modificar y enviar datos al Publicador de 2 maneras (tanto del Publicador al Suscriptor como a la inversa):

• Actualización inmediata: “chist, me has puesto ‘havia’ con ‘v’!!” el Suscriptor envía de inmediato el cambio al Publicador, que lo acepta de buen grado como un acto de fe. Si hubiera otros Suscriptores recibirían ese cambio desde el Publicador al momento.
• Actualización en cola: “oye pues voy cambiando cosillas y ya te las envío si eso”. Puede ser que haya huelga en correos asi que cuando el link este arriba enviamos todos los cambios de golpe. Si resulta que correos funciona bien (ejem) pues los vas enviando según los vas encontrando.

Pero que sucede si un Suscriptor envía un cambio y el Publicador ha cambiado datos justo en ese articulo? como era de esperar el Publicador gana (estaría gordo) de modo que la transacción emitida por el Suscriptor se rechaza y no solo eso, el Suscriptor se come una transacción con el cambio del Publicador. Luego si quiere podrá generar una nueva transacción con el cambio pero sobre los datos ya cambiados por el Publicador.

 

Procesos

Te lo estás pasando en grande, yo lo sé. Solo puedes haber llegado hasta aqui porque estas de mierda hasta arriba, pero yo te comprendo amigo: las fechas aprietan y necesitas esa base de datos en réplica cuanto antes. Todavía te queda un rato pero no desesperes, que vamos andando el camino. Bájate a la máquina expendedora y sácate unas patatas fritas, date una vuelta a la manzana, fúmate un cigarrillo si eres fumador, ves pasar a las chatis durante un rato, y vuelves con las pilas cargadas.

Hasta aqui todo claro espero. Si no esta claro releer, preguntar y repreguntar porque si no se entiende bien la cosa y no se manejan los 4 conceptos con soltura se cae el chiringuito.

Ahora vamos a describir los procesos que se involucran en todo este meollo repartidos por roles:

En el distribuidor

• Agente de instantáneas (snapshot.exe). Se conecta al Publicador y recaba los datos publicados para hacer la instantánea.
• Agente de registro de log (logread.exe). Es el que pasa los fascículos (los cambios de la base de datos) al Distribuidor para que los distribuya.

De esto se viene a deducir que ambos procesos son lo mismo y hacen lo mismo pero uno relativo a réplicas transaccionales y otro a las de instantáneas: se conectan al Publicador y se traen los datos al Distribuidor.

En el distribuidor y en el suscriptor

• Agente de distribución (distrib.exe) es el que aplica las instantáneas o las transacciones producto de la réplica en el Suscriptor. Es el cartero que te inunda de fascículos o te los trae de uno en uno. En el Distribuidor incluye las Suscripciones, en el Suscriptor las extrae para su posterior aplicación.

En el publicador o en el suscriptor

• Agente de combinación (replmerg.exe). Imagina que la Publicación es la segunda vez que se publica y el Suscriptor no pudo acabarla la primera vez con lo que se da de alta otra vez pero ya tiene algunos fascículos de antes. Recibe fascículos pero como ya tiene algunos de antes el pobre hombre se hace un lio porque empieza a tener algunos repetidos (conflictos). No pasa nada, el agente de combinación resuelve estos conflictos. Se puede ejecutar en el Publicador o en el Suscriptor, lo que seria algo asi como suscribirse a una publicación indicando en el panfleto que me manden todo menos los números 3 y 7 que ya los tengo o que me manden todo que ya tiro yo (el Suscriptor) lo que me sobre a fin de tener a la parienta contenta con el numero mínimo de papeles rondando por allí.

Este agente no trataremos porque solo se usa en replicas de combinación. En MySQL no existe esta figura que yo sepa: sin hay conflictos el proceso de replica sale con error.

En el suscriptor

• Agente de lectura de cola (qrdrsvc.exe). Com hemos dicho antes las modificaciones fluyen en ambas direcciones y el Agente de lectura de cola se encarga de eso: cuando el Publicador y Suscriptor están desconectados por lo que sea y se producen cambios en el Suscriptor estos cambios se van acumulando y los envía el Agente de lectura de cola cuando el link se restablece.

Modelos de réplica

Parece que ya vamos quedándonos con la terminología y por ende con la copla. Pero no cantemos victoria tan pronto mis pezqueñines, que esto tiene cuerda para rato, a fin de cuentas es Microsoft el que ha pergeñado todo este invento de locos.

Ahora que tenemos mas o menos todas las piezas vamos a ver que topología de réplica podemos aplicar. Esto en MySQL es talmente igual:

• Modelo de igual a igual: peer to peer: todos pueden hacer de todo. Una bacanal. Un libertinaje. Un “que viva la fiesta”. En un momento dado hay un Publicador y un Suscriptor pero podemos bailar los roles si por ejemplo el Publicador peta o tiene un gatillazo . El Suscriptor pasaría a ser Publicador y cuando el antiguo Publicador se despierte le enchufamos una replica de instantánea para que se vaya calentando y se ponga al día, al tiempo que le volvemos a nombrar Publicador en funciones, por listo.
• Modelo Publicador central: como el Napster: tenemos un Publicador central y n Suscriptores. El caso típico de la editorial que reparte a muchos Suscriptores.
• Modelo de Publicador central con distribuidor remoto: ya habíamos dicho que el distribuidor podía estar en un servidor separado o en el publicador. No se porque lo repite la mierda de libro esta. Sera por fardar?
• Modelo de suscriptor central. Imagina un jubileta que se aburre mazo porque la parienta monopoliza todo el Home Cinema que en sus momento le permitió comprar con programas del corte de Ana Rosa Quintana y similares. El hombre comprensiblemente tiene fobia a este tipo de ponzoña de modo que se suscribe a 200 publicaciones para estar bien entretenido. Después los de Greenpeace lo requerirán para darle unas de yoyas por encargo.Se trata de una base de datos que recibe datos a cascoporro de varios Publicadores.
• Modelo de publicación del suscriptor: aqui las neuronas no me llegan para entender lo que pone este hombre en el libro. Yo creo q ha pasado el parrafo por el traductor de Google y ha quedado de aquella manera. Entiendo que se refiere a un modelo mixto. Es como esas personas (jubiladas también, esto parece el Inserso) que ves por las mañanas cuando vas a currar con muchas muchas barras de pan y piensas “A donde cojones ira este con tanta barra? y lo que es mas raro… a donde va TAN PRONTO?”.  Pues a repartir chavalines, a repartir. Y tu lo dejas marchar porque acabas de desayunar, que sino le pillabas un currusco eh?. El Publicador envía al Suscriptor los datos y este a su vez publica a otros Suscriptores. Según leo es para el caso en q el Publicador y los Suscriptores están muy lejos (enlace Wan) pero los Suscriptores están todos cerca de si (enlace LAN): el Publicador actualiza 1 solo Suscriptor y este reparte el bacalao  entre el resto de Suscriptores. Como te decía: el jubileta que va a la panadería, se carga de barras y reparte para toda la escalera (y fijo que se queda con el cambio, sino no se entiendo tamaño empeño y altruismo).

Y hasta aqui hemos llegado amiguitos, en esta “amena” introducción. En la próxima le daremos candela al asunto pero ya al teclado, como los hombrrrrres.

Pero candela de buena.

Tantos tontos y tan pocas balas…

Hace tiempo que quería poner esta pataleta por escrito y hoy es un día mejor que cualquier otro porque he sido testigo de una forma de incompetencia estado casi solido, por parte de algunos compañeros de profesión.

“Incompetencia” es una palabra sobrevalorada y sobredimensionada ante todo: en realidad lo único que quiere decir es “falta de competencia” y asi la utilizo yo aqui a pesar del titulo de esta entrada (que lo uso unicamente porque siempre me hizo gracia esa frase y no porque este llamando gilipollas a media empresa). A fin de cuentas la falta de competencia es algo que se puede suplir con estudio si hay capacidad de autocritica y voluntad.

Tejidos los prolegómenos vamos a lo que vamos, aunque sobre faltas de competencia volveremos graciosamente casi al final, si las cosas en esta entrada siguen su cauce y todo sale como esta previsto.

Que ha pasado? o mejor, que esta pasando? pues facil amiguitos, en la mía empresa donde trabajo para no llegar a final de mes como informatico mileurista de pacotilla (esto es un pleonasmo en realidad) estamos como locos implantando una metodología para el desarrollo de software. Hay que decir que mi empresa es grande de cojones, tiene presencia en varios países y lleva a cabo multitud de desarrollos mas o menos afortunados (mas menos que mas, a fe mía); lo que quiero decir con esto es que no somos 4 y el del tambor dedicados a reparar impresoras. Que sucedía hasta ahora? en esencia: no había una metodología clara de desarrollo ni de gestión. Ese cumulo de procesos que suele caer en el saco que llaman “Ingeniería de Software” no existía como tal, de ahí que conceptos como “análisis de requisitos”, “diseño técnico”, “pruebas de regresión” y todas esas cosas no existían en el estricto modo en que existen las cosas en el mundo real: esto es, hay analistas pero no se sabe muy bien que hacen, los diseños técnicos los hace el mismo que va a programarlos y el arquitecto es un tío que no sabe ni de donde viene ni a donde va, y lo que es peor: no sabe el tiempo que le queda. Con esto quiero decir que aunque los gerifaltes usaban los términos con enorme grandilocuencia y gran refocile cuando se conectan a Matrix para hacerse sus simulaciones particulares (aka pajas mentales), en el mundo real no pasaban de ser palabras huecas y conceptos extraños y sin sentido. Al final todo era bastante desastroso y en tiempo de codificación podía cambiarse la funcionalidad de arriba a abajo varias veces porque no se pensó lo mas mínimo si aquello encajaba con el resto o en que manera lo hacia… o si realmente era útil… o si realmente era lo que pedía el cliente… o si o si o si…

Y ahora viene cuando la matan porque se ha pedido ayuda a una empresa externa que se dedica a estos menesteres y claro, han flipado (como no, también tienen que comer los pobrecillos) y han definido una serie de procesos bastante exhaustivos para pilotar todo el proceso de desarrollo, desde el documento de Visión hasta el despliegue del producto ya terminado y todo el mondongo. Entonces es cuando los incompetentes que han vivido de cojones apoltronados en sus asientos rascándose el inglete y pagados de si mismos pensando que su palabra era misa y su inmaculada sabiduría iluminaba el tormentoso camino de los pobres desgraciados que nos arrastramos por el suelo escupiendo líneas de código como escarabajos pelotilleros… como digo, esta suerte de pseudo trabajadores  salen a la luz empezando a matizar, a ponderar, a valorar, a cuestionar en definitiva el procedimiento sugerido, en aras de una mayor “practicidad”; porque claro, eso que te han dicho que porque cojones se hace tan mal y desde hace tanto tiempo ya lo sabían ellos, como no, date cuen.

Concretamente el bacalao ha venido sobre la “interpretación” que este grupo de personas da al documento que recoge lo que tiene que hacer la aplicación y que recibe el bonito nombre de “especificación de requisitos”. Hay una serie de reglas que hay q cumplir para que una especificación de requisitos sea tal, como hay una serie de reglas a cumplir para que una carrera en apariencia desordenada por parte de 22 personas en pijama y en pos de una esfera, se pueda llamar futbol. Pues no oyes, que la especificación de requisitos es una cosa abierta al debate, a la interpretación. A los efectos puede ser una letrina donde todo tiene cabida en favor del pobre programador pelotero que no se albarda de nada: novelas escritas por el comercial justificando la inclusión o exclusión de tal necesidad, dibujos del departamento de diseño para aclarar las cosas (dibujos que rápidamente se quedan desfasados y no se molestan en remendar porque cuesta pasta), recortes de la wikipedia para las partes técnicas, mails entre los arquitectos para aclarar las cosas… un vergel en toda regla, un caos, una puta bacanal orgiástica de tecnicismos indigestos que el programador observa con cara de pueblo. Entonces intentas explicar como tiene que ser una especificación de requisitos ante la plana y te das cuenta de que estas solo. Mas solo que lo que estuviste cuando llegaste a este mundo y mas solo de lo que estarás cuando toque abandonarlo, por viejo y por pellejo.

Y estas solo porque el 95% de los puestos de dirección o de gestión están copados por físicos, matemáticos, industriales o telecos. Cuando mas arriba es el puesto de gestión mas físicos, industriales o economistas. Cuanto mas abajo mas telecos. Informáticos pocos o ninguno aunque sean mayoría picando código. Si habéis intentado explicarle a un teleco o a un físico qué es una especificación de requisitos y no han tratado el tema antes, entenderéis lo que digo. No estoy hablado de falta de capacidad, por supuesto que no, no hay que ser ningún superdotado o haberse chupado una carrera de 5 años mas prorrogas para saber hacer una especificación de requisitos mínimamente decente. Es sencillamente ignorar la existencia y desdeñar por sistema la importancia de las cosas que se ignoran. Es no saber lo que no se sabe y además, importarles un huevo porque si algo relativo a la informática no lo conocen es que no es importante. Si lo fuera ya lo dominarían. Es la incompetencia en estado puro y duro; relativa, porque pueden ser unos hachas en sus cosas (o incluso programando!) pero en lo que aqui concierte la palabra que me viene a la mente es  “vergonzoso”. Y como son mayoría es como para plegar la oreja y subirse las mantas hasta la cabeza.

Pero lo mejor de todo es que los únicos que tienen competencias a día de hoy en informática son… los telecos! tócate el fofete! claro, nuestro menistro/a alega que la informática es una ciencia “transversal” y claro, no ha lugar asignar competencias para esa panda de muertos de hambre que están todo el día con sus chuminaditas de análisis – diseño y demás zarandajas que no van a ningún lado.

En total, que esto no hay quien lo arregle. La verdad es q no se porque el tema me molesta tanto; a fin de cuentas la informática es una puta mierda bien gorda donde nada funciona como debe: te instalas la ultima Ubuntu y lo primero que hace es descargarse 200 megas de parches y la gente se cooooorrre de gustoooo. “Tengo el sistema al día!” Lo mismo pasa con Windows pero peor: reiniciar 37 veces, actualiza el sistema de actualizaciones, parchear el parcheador de parches… ahora te coloco el historial del navegador aqui pero tranquilo que en la próxima versión te lo coloco allá y asi te entretienes buscándolo; y si hoy la config de ethernet esta en /etc/network/interfaces tu tranquilo, no te pongas nervioso que mañana te la ponemos en ifcfg-ethx como antaño o te cambio el inittab o te toco los cojones, que de eso sabemos un ratillo.

Y asi vamos tirando.

Grooveshark

No se cuanto durara pero uan alternativa a spotify es http://listen.grooveshark.com/

Da la sensacion de que tiene un catalogo mayor.