Copia de un volumen logico entre diferentes volumenes de grupo

El comando cplv ofrece una manera directa de copiar un volumen lógico a otro volumen de grupo. Esta funcionalidad es útil para realizar respaldos de dispositivos crudos o, por motivos de rendimiento, descargar E/S de discos sobreutilizados. El formato es el siguiente:


cplv -v volumen-de-grupo-destino -y volumen-logico-destino volumen-logico-original
Ejemplo:
cplv -v memevg -y copialv lv56


Otras parámetros permiten la copia hacia un volumen lógico ya creado, pero considero que el formato antes expuesto es mejor ya que inclusive copia el tipo de volumen lógico, el cual bien podria ser "raw" o cualquier cosa con la que hubiesemos creado el lv original. Digo esto porque muchos lv's se utilizan como dispositivos crudos (raw devices) y el "lv type" -de existir- es inconsecuente, mientras que las otras formas del cplv necesitan una especificación conocida: jfs, jfs2, sysdump, paging, jfslog, jfs2log o boot.

Ejecucion remota de comandos por conexion segura

Para ejecutar comandos dentro de una conexión segura entre servidores, se necesita instalar el SSL y secure shell (ssh) primero, configurarlo y probarlo. Para los efectos de este ejemplo, el usuario ysanson del servidor alpha ejecutará comandos y copiará archivos en el servidor epsilon con el permiso del usuario apptest.

1. Generar las llaves de identificación. En este caso utilizaremos la encriptación rsa:

ysanson@alpha:/home/ysanson $ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/ysanson/.ssh/id_rsa):

Created directory '/home/ysanson/.ssh'.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/ysanson/.ssh/id_rsa.

Your public key has been saved in /home/ysanson/.ssh/id_rsa.pub.

The key fingerprint is:pp:41:yy:84:4c:ta:c8:b4:90:e4:82:j9:5b:pp:fe:a9 ysanson@alpha

Solo necesitamos la llave pública (id_rsa.pub), no introducimos clave (porque añadiría un paso interactivo) y esta queda guardada en el directorio .ssh bajo el HOME del usuario.

2. Copiar el archivo público al servidor destino por de forma segura (scp), utilizando el usuario que nos permitirá la ejecución y copia remota, en este caso apptest.

ysanson@alpha:/home/ysanson/.ssh $scp id_rsa.pub apptest@epsilon:

The authenticity of host 'epsilon (1.70.1.210)' can't be established.

RSA key fingerprint is uu:ce:0a:xx:2b:83:a4:ii:a7:66:86:ed:ee:46:01:80.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'epsilon,1.70.1.210' (RSA) to the list of known hosts.

mailto:apptest@epsilon password:id_rsa.pub 100% 224 0.2KB/s 00:00

El archivo es copiado al HOME del usuario apptest en epsilon porque al final del hostname destino hay dos puntos.

3. Crear el directorio .ssh en el servidor epsilon bajo el HOME de apptest y anexamos el contenido que archivo id_rsa.pub dentro del otro denominado authorized_keys.

$ mkdir .ssh

$ chmod 755 .ssh

$ cd .ssh$ cat ../id_rsa.pub >> authorized_keys

Los permisos son necesarios para garantizar que la llave pueda ser leída. La anexión (>>) se debe a que el mismo archivo puede contener las llaves públicas de otros usuario y servidores.

4. Ejecutamos un comando remotamente utilizando el comando ssh:

ysanson@alpha:/home/ysanson/.ssh $ssh apptest@epsilon cal

April 2008

Sun Mon Tue Wed Thu Fri Sat

1 2 3 4 5

6 7 8 9 10 11 12

13 14 15 16 17 18 19

20 21 22 23 24 25 26

27 28 29 30
o copiamos un archivo:

ysanson@alpha:/home/ysanson/.ssh $scp prueba apptest@epsilon:

Nuevamente es importante los dos puntos al final sino el archivo prueba es copiado al mismo servidor bajo el nombre apptest@epsilon .

Este aparentemente sencillo proceso requiere de mucho cuidado ya que la colocación de los archivos y sus permisos es crítico para su funcionamiento. Un problema que he observado es que durante el proceso de generación de la llave, el ssh-keygen pregunta dónde queremos almacenar los id_rsa*, sin embargo cuando hacemos la copia remota (scp), el archivo known_hosts generado se crea bajo el $HOME del usuario. Esto no tiene mayor consecuencia si el usuario que ejecuta el proceso es único, pero cuando se realiza por medio de un usuario que tiene el mismo UID que otro -como ocurre con aquellos que reemplazan a root-, entonces los id_rsa* deben copiarse al directorio .ssh donde exista el archivo known_hosts.

Corrupcion de los espejos de un volumen logico

La corrupción de los espejos de un volumen lógico se refleja en errores como:

0516-1509 : VGDA corruption: physical partition info for this LV is invalid.

En estos casos, lo primero es tratar de eliminar el espejo y recrearlo, sea por medio de comandos o el smit. Sin embargo, no siempre es posible realizar la operación ya que la corrupción inhabilita al comando para ejecutar la operación de forma directa. En Internet encontré una forma de corregir el problema y aunque la solución funciona, las instrucciones no son claras. Al final lo que se desea es alimentar el comando lreducelv con el mapa de las particiones físicas mal espejadas. En el siguiente ejemplo obtenemos el mapa físico del volumen lógico:

root@server:/home/root #lslv -m fslv02

fslv02:/finanzas

LP PP1 PV1 PP2 PV2 PP3 PV3

0001 0204 hdisk1 0214 hdisk0

0002 0205 hdisk1 0215 hdisk0

0003 0206 hdisk1 0216 hdisk0

0004 0207 hdisk1 0217 hdisk0

El volumen lógico fslv02 tiene un espejo en el disco cero (hdisk0), el cual no permite ser eliminado. El comando lreducelv tiene el siguiente formato:

lreducelv -l identificador-del-volumen-logico -s numero-de-particiones-parcialmente-espejadas nombre-de-archivo

El identificador del volumen lógico lo obtenemos por medio de: lslv fslv02

root@server:/home/root #lslv fslv02

LOGICAL VOLUME: fslv02 VOLUME GROUP: rootvg

LV IDENTIFIER: 00cfd90f00004c0000000108493c5c5b.18

Para construir el archivo necesitamos el identificador de disco físico que contiene el espejo, por medio del comando lspv:

root@server:/home/root #lspv hdisk0

PHYSICAL VOLUME: hdisk0 VOLUME GROUP: rootvg

PV IDENTIFIER: 00cfd90f493c4574

luego, extraemos la información necesaria del lslv -m volumen-logico y creamos el archivo asi:

lslv -m fslv02 awk {'print "00cfd90f493c4574 "$4" "$1'} > archivo

Observese que luego del identificador del volumen físico hay un espacio y que el awk transpone las columnas 4 y 1 para obtener el siguiente formato:

00cfd90f493c4574 0214 0001

00cfd90f493c4574 0215 0002

00cfd90f493c4574 0216 0003

00cfd90f493c4574 0217 0004

Nota: el archivo debe ser editado a mano para eliminar los headers.

Finalmente el comando se corre así:

lreducelv -l 00cfd90f00004c0000000108493c5c5b.18 -s 4 archivo

donde el "4" es el número de líneas del archivo, obtenible por medio de vi o wc -l archivo.

Luego de corregido el problema, el volumen lógico puede volver a ser espejado de forma regular.

Replicacion diferencial de directorios y archivos

Bajo ciertas circunstancias, aparte de las medidas de respaldo hacia dispositivos externos (cintas) o las estrategias de espejo o arreglo en disco, es necesario constar con un sistema actualizado y funcional, que -en caso de desastre- permita continuar la operación o al menos reducir al mínimo el downtime. Por supuesto, podríamos restaurar desde cinta, ¿pero qué tal si esto no es posible?Al existir un equipo de contingencia, usualmente las bases de datos pueden replicarse en línea, sin embargo, que hay sobre los programas y archivos de configuración?

El siguiente shell script copia los archivos del directorio /home/user en el serverA hacia su homologo en el serverB, denominado /home/replic, excluyendo un par de archivos que no nos interesan o bien, contienen información que "dañaría" el destino.

#!/usr/bin/ksh
x=`date`
echo "Directory replication /nProcess begun at: $x"
HOMEDIR=/home/user

cd $HOMEDIR
find . -newer tstamp > list
cat list grep -v "/conf/config.xml" > list1
cat list1 grep -v "/conf/web.xml" > list2
sed "s/user/replic/g" list2 > list3
x=`wc -l list3 awk {'print $1'}`
y=0
y=$(($x - 1))
tail -$y list3 > lista
cat lista
for file in `cat lista`
do
tar -cvf - $file ssh root@serverb "cd /home; tar -xpvf -"
echo $file
done
touch tstamp
x=`date`
echo "Process finished at: $x"

exit 0

Aunque el script podría ser más reducido y elegante, se buscó ser lo más claro posible, mostrando los diferentes filtros aplicables; El find crea la primera lista con los archivos modificados posteriores a la fecha del último respaldo (tstamp), luego deseamos que los archivos config.xml y web.xml sean excluídos (si se necesitan más, un archivo aparte podría contenerlos), esto se logra por medio de un grep exclusivo.

El tail elimina la primera línea de la última lista filtrada, removiendo la referencia al directorio raíz original (/home/user), de no existir este paso la copia se realizaría íntegra, completa, inutilizando la diferencialidad requerida, ya que el comando tar copia subdirectorios por omisión.

El otro punto importante lo constituye el reemplazo de la ruta original /home/user por la del destino /home/replic, utilizando el comando sed. Es decir que el destino raíz no tiene que ser igual que el origen, pero sí lo que hay debajo de él.

Luego de la copia, el archivo tstamp es actualizado por el comando touch, de tal manera que la proxima iteración solo contemple archivos nuevos y aquellos que han sido modificados.

Finalmente, el script depende de que la ejecución de comandos remotos a través de ssh se haya configurado previamente, procedimiento que veremos en otra entrada del blog.