Artículos Técnicos

Artículos Tecnicos y Procedimientos (creado por Pablo Saitta - pablo.saitta@gmail.com)

viernes, abril 28, 2006

Como recuperar un metadispositivo con DiskSuite

Titulo: Solstice Disksuite, como recuperar un metadispositivo que está en estado inetable o como recrear un md sin perder datos.

Productos: Solstice DiskSuite 4.2.1, Solaris Volume Manager, Solstice DiskSuite 4.0 (japones), Solstice DiskSuite 4.1(japones), Solstice DiskSuite 4.1 Software, Solstice DiskSuite 4.2 Software

Área: LVM Logical Volume Management

Descripción:

Rara vez un dispositivo lógico queda en estado indefinido, por lo que recuperarlo suele ser algo problemático.

Este procedimiento es para recrearlo luego de que hallamos guardado la configuración actual con un metastat -p. Este procedimiento es algo riesgoso por lo que es altamente recomendable tener hecho un backup completo de la información.


Documento:

Ejemplos de cuando debo usar este procedimiento:

  1. El mirror tiene sus dos componentes en “Needs Maintenance” y los comandos comunes no me sirven para limpiar el “Last Erred”.

  2. Uno de los submirror tiene un error de I/O no fatal y está en “needs maintenance”. En este momento es muy dificil poner el mirror nuevamente en linea.

  3. Puede haber habido un reboot o una reconfiguración y uno de los dispositivos cambió de controladora o de target.

  4. Cuando un submirror está en OK de un mirror y se va a un estado stale y la otra parte del mirror está OK pero sin información, y si usaramos el “metareplace -e” nos haría perder toda la información.


Ejemplos de cuando no debo usar este procedimiento:

  1. Un submirror está en “Need Maintenance” y el otro en “Last erred”.

  2. Un submirror con datos validos está en OK y el otro en “Last erred” o “Need Maintenance”

Para estos casos use el procedimiento normal de recuperación.


Este documento puede ser utilizado con todas las versiones de DiskSuite. Tener en cuenta que en las versiones anteriores a DiskSuite 4.2.1 los comandos se encuentran en /usr/opt/SUNWmd/sbin así que recomendamos agregar este directorio a su PATH antes de comenzar a trabajar. Para hacer esto tipee:

PATH=$PATH:/usr/opt/SUNWmd/sbin

en las otras versiones de DiskSuite los comandos están en /usr/sbin que es el path del root.


Procedimiento de recuperado:

Con Solaris Volume Manager se puede limpiar cualquier metadispositivo y luego volver a recrearlo sin perder información. El siguiente ejemplo, con el dispositivo d8 que no puede ser reparado, nos muestra el procedimiento para recuperarlo.


Paso 1: Examine la salida del metastat para determinar el estado del mirro y los submirrors.

# metastat [-s setname] d8

d8: Mirror
Submirror 0: d82
State: Needs Maintenance
Submirror 1: d83
State: Needs Maintenance
Pass:1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 35307016 (16Gb)

En este ejemplo, ambos submirror necesitan mantenimiento. Si uno de los dos se encontrara en "Last Erred" use el procedimiento normal de recuperación. Y si este procedimiento no le funcionó continue con el siguiente paso.

Paso 2: Determine si uno de los dos submirro se encuentra activo.

El proposito de este paso es determinar cual de los dos submirror utilizar como principal para luego recrearlo. Si usted ya tiene esta información, o si el mirror solo posee un componente puede obviar este paso.
Use iostat para determinar cual es el submirror activo:

# iostat -xnz 10 6 (el -z no muestra las líneas en cero)

aquí podremos ver a que metadispositivo estamos accediendo.

Paso 3: Para tener una copia de los dispositivos originales capturemos el metastat -p para el dispositivo que tenga fallas

# metastat [-s setname] -p d8 | tee d8.metastat

d8 -m d82 d83 1
d82 1 1 c1t2d0s0
d83 1 1 c1t3d0s0
(esta información también puede ser extraida de un explorer viejo)

Paso 4: Verifique por la existencia de cualquier softpartition creadas sobre este dispositivo

# metastat [-s setname] -p | grep d8 | tee d8.sp

d8 -m d82 d83 1
d82 1 1 c1t2d0s0
d83 1 1 c1t3d0s0
d106 -p d8 -0 28286982 -b 1433600
d105 -p d8 -o 29720583 -b 2097152
d104 -p d8 -o 27262981 -b 1024000
d103 -p d8 -o 25165828 -b 2097152
d102 -p d8 -o 20971523 -b 4194304
d101 -p d8 -o 8388610 -b 12582912 -o 31817736 -b 3481600
d100 -p d8 -o 1 -b 8388608

En este ejemplo tenemos 7 soft partition sobre el mirror. No continue sin haber antes capturado estos datos. Tenga la precaución que el grep puede haberle capturado información de otros dispositivos aparte del que estamos queriendo reparar.

Como una alternativa para los pasos 3 y 4, asegurese que el md.tab está actualizado.

Para el Solstice DiskSuite 4.2.1 y el Solaris Volume Manager:
# mv /etc/lvm/md.tab /etc/lvm/md.tab.old
# metastat [-s setname] -p > /etc/lvm/md.tab

Para versiones anteriores el md.tab no se encuentra en el mismo lugar sino que debemos proceder como se muestra abajo:

# mv /etc/opt/SUNWmd/md.tab /etc/opt/SUNWmd/md.tab.old
# metastat [-s setname] -p > /etc/opt/SUNWmd/md.tab

Paso 5:
Use los comandos como el "df -k" y el "swap -l" para observar todos los filesystems y aplicaciones que están utilizando este metadispositivo.

a) Mire todos los file systems:

# df -k | grep /dev/md/dsk/d8

En este ejemplo no hay filesystem porque el d8 es solo la base para las softpartitions por lo cual los filesystems deberian estar sobre las mismas.

b) busque los dispositivos swap

# swap -l | grep /dev/md/dsk/d8

En este ejemplo no hay dispositivos swap sobre este dispositivo. Si los hubiera deberiamos usar los procedimientos normales para agregar dispositivos swap mientras este se encuentra momentaneamente fuera de línea.

Paso 6: En el paso 4 hemos encontrados soft partition sobre el mirror, debemos encontrar y resguardar los filesystems relevantes, usando el grep para encontrar los patrones que estamos buscando.

# df -k | grep /dev/md/dsk/d10 | awk '{ print $6 }'


/data
/data/packages
/data/crash
/data/dl
/data/install
/data/patches
/data/samba

Paso 7: Borre los metadispositivos soft partition


# metaclear [-s setname] d100
# metaclear [-s setname] d101
# metaclear [-s setname] d102
# metaclear [-s setname] d103
# metaclear [-s setname] d104
# metaclear [-s setname] d105
# metaclear [-s setname] d106

Haga esto uno a uno o use el siguiente comando para todas las particiones

# metaclear [-s setname] -p

Paso 8: Borre recursivamente el mirror (puede necesitar la opción -f)

# metaclear [-s setname] -r d8

Paso 9: Recree los metadispositivos, primero creando los submirrors

# metainit [-s setname] d82 1 1 c1t2d0s0
# metainit [-s setname] d8 -m d82

El submirror usado para que sea el principal es el d82. En el paso 2 vimos que solo había I/O en uno de los submirror, el cual es el mismo que estamos utilizando en este paso.

Si en el paso 1 nos muestra como que uno de los submirror está en "Last Erred", entonces aquí use ese submirror como principal en este paso.

Si nuestro caso es como el pto 4 descripto en los casos en los que debemos usar este procedimiento, entonces en este paso debemos utilizar el submirror con datos validos como submirror principal.

Repase muy bien este punto antes de hacerlo ya que un error puede acarrear la perdida total de la información.

Paso 10: Recrear las softpartition, esto puede ser realizado mientras el d8 se termina de sincronizar.

# metainit [-s setname] d100 -p d8 -o 1 -b 8388608
# metainit [-s setname] d101 -p d8 -o 8388610 -b 12582912 -o 31817736 -b 3481600
# metainit [-s setname] d102 -p d8 -o 20971523 -b 4194304
# metainit [-s setname] d103 -p d8 -o 25165828 -b 2097152
# metainit [-s setname] d104 -p d8 -o 27262981 -b 1024000
# metainit [-s setname] d105 -p d8 -o 29720583 -b 2097152
# metainit [-s setname] d106 -p d8 -o 28286982 -b 1433600

Paso 11 (opcional) si el tiempo lo permite usted puede realizar un fsck -n a cada uno de los filesystem

Si el fsck falla en seguida, deberíamos recrear los metadispositivos que se encuentren en estado incorrecto. Si el fsck encuentra otro errores , estos errores pueden que ya hallan estado en los filesystem originales pero no pudieron ser generados por este procedimiento.

Paso 12: Monte los filesystem como estaban originalmente.

Si el montaje falla puede que deba recrear los metadispositivos incorrectos. Para recuperarlos use el metaclear y el metainit nuevamente.

Paso 13: Una vez que hallamos confirmado que tenemos nuestros datos intactos podemos atachar los otros componentes del mirror

# metainit [-s setname] d83 1 1 c1t3d0s0
# metattach [-s setname] d8 d83

Usando este procedimiento para otro tipo de metadispositivos:
- Raid 5: este mismo procedimiento puede ser utilizado para el Raid 5. La opción -k. Cuando estamos rearmando los dispositivos en el paso 9 la opción -k es de gran importancia. Esta opción le dice al SVM que no inicialice los metadispositivos para usar los datos que ya se encuentran en el disco. No hacer esto puede causar la perdida total de los datos.

- Concatenado o stripe (o los dos): este procedimiento puede ser utilizado en este caso y el uso del metainit y el metaclear no afecta a los datos del usuario. Es muy importante que al recrear el stripe o el concat cada componente sea recreado en el mismo orden. Si no lo hacemos exactamente de la misma forma no perderemos los datos, mientras que los datos (filesystem) no sean modificado (como con un fsck -y). Si accidentalmente recreamos el stripe en el orden equivocado simplemente debemos borrarlo con el metaclear y recrearlo en el orden correcto. Si no conocemos el orden correcto, simplemente repita los pasos del metainit y luego ejecute el fsck -n antes que fsck se complete correctamente.


Usando este procedimiento con los números de las controladoras cambiados:
Este procedimiento puede ser utilizado cuando un reboot de reconfiguración cambió el número de controladora de los dispositivos c#. Simplemente edite y guarde los archivos para reflejar el nuevo número de controladora. Cuando el número de la controladora cambió, es necesario reiniciar todas las meta database (MDBs) en esa controladora.

Trabajando con MDBs embebidas
Con MDBs es cualquier submirror o slice del dispositivo que hallamos recreado y que tenga "Yes" bajo el Dbase en la salida del metastat.
Las MDBs no afectan a este procedimiento. Los metadispositivos pueden ser limpiados e inicializados sin tocar las MDBs embebidas. Si usamos este procedimiento como parte de un cambio de número de controladora, deberiamos reinicializar todas las MDBs. El uso de MDBs no es lo mejor y debemos considerar eliminarlas en un futuro .

(Extraido y traducido del artículo 76077 de Sun Solve)

Backup del SCO 5.0.5

Para hacer el bakcup de los archivos principales de este viejo sistema operativo debemos hacer lo siguiente:
1) realizar una copia en diskette dentro del scoadmin de los archivos de booteo
2) backupear el /stand. Para ello debemos hacer
# umount /stand
# mount /stand
# cp /stand/unix /stand/unix.backup
3) copiar el /etc/conf
# copy -vrom /etc/conf /etc/conf.pablo
4) si queremos tener los usuarios e impresoras debemos hacer backup de los siguientes archivos:
/etc/shadow
/etc/passwd
/etc/printers.conf
/etc/hosts
de esta forma tenemos los archivos mas importantes de nuestro sistema operativo para poder seguir trabajando en caso de un desastre.
Para algunos casos estos no son suficientes por lo que hay que tener en cuenta las terminales que estamos emulando, teclado, si tenemos o no impresoras serie, etc

Configuración de Samba (Fedora Core4)

Aca les paso mi archivo de configuración de samba. (/etc/samba/smb.com) Es para que lo tomen de ejemplo.
[global]
workgroup = kit.dom
log level = 1
netbios name = workstation
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest ok = yes
Server string = fedora core 4
security = share
log file = /var/log/samba/log.%m
max log size = 100
dns proxy = no
printer admin = root, +ntadmin
encrypt passwords = yes

[homes]
browseable = no
map archive = yes

[printers]
path = /usr/tmp
guest ok = yes
printable = yes
min print space = 2000
[download]
browseable = yes
valid users = root, pablo, invitado
read only = no
guest ok = yes
path = /download

[cdrom]
browseable = yes
read only = no
guest ok = yes
path = /media/cdrom

Mirror de discos con Solaris Disk Suite

Instalación:

La versión recomendada es la 4.2 o superior que corre en sistemas con Solaris 2.6 o superior. Hay dos paquetes y un parche necesarios para la instalación de DiskSuite

-SUNWmd
-SUNWmdg
- 106627-04 (obtenga la última versión de este parche)

Los paquetes deben ser instalados en el mismo orden que figuran arriba. Es necesario el rebooteo después de la instalación par que los nuevos drivers sean agregados al kernel.
Asegurese de hacer un update de su PATH y MANPATH para agregar los directorios del DiskSuite. Los ejecutables residen en /usr/opt/SUNWmd/sbin y las páginas del manual en /usr/opt/SUNWmd/man


El ambiente:

En este ejemplo mirrorearemos dos discos. El primer disco sera el primario y el segundo será el mirror. Los discos de nustro ejemplo son:
Disco1: c0t0d0
Disco2: c0t1d0
Cada disco es particionado exactamente igual. El slice 2 comunmente denominado como buckup, representa el disco entero y no debe ser mirroreado.
Hay tres particiones sin asignar en cada uno de los discos y configurada cada una con 256Mb. Estos slices de 256Mb contienen las database replica del DiskSuite, o metadb. Las metadb ocupan 517Kb pero preferimos crear slice más grandes.
Una vez creada las particiones en el disco uno procedemos de la siguiente manera para hacer una copia exacta de esta forma de particionado en el disco 2:

Disco1:
c0t0d0s0: /
c0t0d0s1: swap
c0t0d0s2: backup
c0t0d0s3: unassigned
c0t0d0s4: /var
c0t0d0s5: unassigned
c0t0d0s6: unassigned
c0t0d0s7: /export

para copiar esta misma configuración hacemos:

# prtvtoc /dev/rdsk/c0t0d0s2 > /tmp/vtoc
# fmthard -s /tmp/vtoc /dev/rdsk/c0t1d0s2

De esta forma se copia las tablas de particiones del disco 1 al disco 2.

Las Database state Replicas:

Son los repositores de la información del estado y la configuración de cada metadevice. Teniendo múltiples replicas es critica par la correcta operación del Solaris DiskSuite
- Debe haber un mínimo de 3 replicas. DiskSuite requiere al menos el 51% de las replicas presentes en orden para su operación.
- Las replicas deben estar distribuidas entrelos discos y controladoras de ser posible.
- En una configuración de tres discos, debe haber al menos una replica en cada disco, por si alguno de los discos falla.
- En una configuración de dos discos, debe haber al menos dos replicas por disco. Si hubiera solo 3 y el disco que contiene dos de las mismas falla, el DiskSuite no tendrá suficiente información para funcionar.
Aquí crearemos nuestras replicas usando el comando metadb:

# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t0d0s3
# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t0d0s5
# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t0d0s6
# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t1d0s3
# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t1d0s5
# /usr/opt/SUNWmd/sbin/metadb -a -c3 -f /dev/dsk/c0t1d0s6

La opción -a atacha el nuevo dispositivo de database y automáticamente edita el archivo /etc/system. La opción -c3 crea 3 copias en este dispositivo y el -f crea las replicas en ese instante.
Cada metadispositivo mirroreado contiene dos o más submirrors. El meta dispositivo es montado por el sistema operativo en lugar del dispositivo físico.
Aquí crearemos los dos submirrors para el filesystem / (root), como hay un solo camino en el mirror
entre el metadispositivo y el primer submirror.

# metainit -f d10 1 1 c0t0d0s0
# metainit -f d20 1 1 c0t1d0s0
# metainit d0 -m d10

Los primeros dos comandos crean los submirror. La opción -f fuerza la creación de los submirror aún cuando el slice específico se encuentra montado. La segunda de las opciones 1 1 significa el número de stripes en el metadispositivo y el número de de slices que levantará el stripe. En una situación de mirror siempre será 1 1. Finalmente,
especificaremos el dispositivo físico que mirrorearemos. Despues de hacer el mirror de la partición root, necesitamos correr el comando metarrot. Este comando actualizará la entrada del root en el archivo /etc/vfstab con el nuevo metadispositivo como así también la configuración apropiada en el /etc/system. Omitir este paso es un o de los errores más comunes. Si usted no corre el comando metaroot antes de rebootear el equipo, no podrá bootear el sistema!!!!


# metarrot d0

Luego continuaremos creando los submirror e indicando los metadispositivos que reemplazarán el swap y la partición /var

# metainit -f d11 1 1 c0t0d0s1
# metainit -f d21 1 1 c0t1d0s1
# metainit -d1 -m d11

# metainit -f d14 1 1 c0t0d0s4
# metainit -f d24 1 1 c0t1d0s4
# metainit d4 -m d14

# metainit -f d17 1 1 c0t0d0s7
# metainit -f d27 1 1 c0t1d0s7
# metainit d7 -m d17

Actualizando el /etc/vfstab

El archivo /etc/vfstab debe estar actualizado al punto que refleje los cambios echos en el sistema. La partición / ya ha sido actualizada con el comando metaroot, pero el sistema necesita saber acerca de los nuevos dispositivos para el swap y el /var. Las entradas en el archivo son parecidas a las siguientes:

/dev/md/dsk/d1 - - swap - no -
/dev/md/dsk/d4 /dev/md/rdsk/d4 /var ufs 1 yes logging
/dev/md/dsk/d7 /dev/md/rdsk/d7 /export ufs 1 yes logging

Note que los path de los dispositivos han cambiado del estilo normal /dev/dsk/cxtxdxsx y /dev/rdsk/cxtxdxsx al nuevo path para los metadispositivos /dev/md/dsk/dx y /dev/md/rdsk/dx.

Atachemos un mirror:

Ahora debemos atachar la otra mitad de los mirrors (obviamente antes de hacer este paso ya hemos rebooteado el sistema para que los filesistem montados sean sobre los dispositivos lógicos y no sobre los físicos). Una vez que los mirror son atachados dará comienzo automaticamente el proceso de resincronizado para asegurarse que las dos partes del mirror contengan lo mismo. Este proceso puede ser monitoreado usando el comando metastat. Para atachar los submirrors debemso usar los siguientes comandos:

# metattach d0 d20
# metattach d1 d21
# metattach d4 d24
# metattach d7 d27

Final:

Con un ojo puesto en el caso de tener que hacer una recuperación. Puede que sea una buena idea saber cual es el dispositivo físico del segundo disco, para de esta forma configurar los parámetros de OBP que me permitan bootear tanto de un disco como de otro en caso que uno de los dos no funcione. Para saber a donde están apuntando nuestros discos debemos correr el siguiente comando:

# ls -l /dev/dsk/c0t0d0s0
esto nos dará una salida parecida a esta:
/sbus@3,0/SUNW,fas@3,8800000/sd@1,0:a

Lo mismo hacemos para el otro disco y luego usando esta información creamos un alias para este dipositivo y para el segundo con el comando nvalias dentro de obp, y cambiamos luego las opciones boot-device y diag-device.

Pablo G. Saitta