Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 19 de septiembre de 2011
ATENCIÓN: OVH soporta Solaris 10 Update 8 de forma oficial, que es la última versión publicada por SUN antes de ser adquirida por Oracle. Para la instalación de una máquina Solaris desde cero, lo más simple sería instalar Solaris 10 U8 de forma nativa, y luego actualizarlo a la última versión publicada mediante "Live Upgrade". En mi caso no puedo aplicar este sistema porque lo que estoy migrando es una máquina ya en producción, con la menor pérdida de servicio posible.
Hace dos años instalé un servidor Solaris 10 en una máquina de OVH, con unos resultados muy buenos. Conseguirlo fue muy trabajoso y accidentado, pero una vez puesta a andar, la verdad es que todo ha ido muy bien:
En estos dos años, la tecnología ha cambiado mucho: capacidad de disco duro, CPUs mucho más potentes (gracias a añadir cores, no a mayor velocidad individual), más RAM y, oh maravillas de las maravillas, unidades SSD. El resultado es que pagando menos de lo que pago por la máquina antigua, obtengo: cuatro veces la potencia de CPU, ocho veces la capacidad RAM, más del doble de disco duro y 80 GB en forma de SSD, perfecta para el ZIL ZFS. Y KVM remoto a un precio razonable.
También ha evolucionado mucho el software de máquinas virtuales. Por ejemplo, VirtualBox hace tiempo que soporta multicpu o el control fino del cacheo de disco, que eran algunas de las limitaciones que tuve hace dos años. Por lo tanto, cuando decidí que había llegado la hora de actualizar el equipo, me planteé seriamente instalar un Linux mínimo, instalar sobre él VirtualBox y, dentro, seguir utilizando mi Solaris de toda la vida, sin tener que preocuparme de incompatibilidades hardware.
Pero cuando me puse a evaluar servidores nuevos, vi con agrado que OVH soporta OpenSolaris2009.6 en el servidor que me interesaba. ¿Sería posible instalar Solaris 10 de forma nativa, con pleno soporte de hardware?. Veámoslo.
Contratado el servicio, me conecto y veo que el sistema operativo se ha instalado en los SSD, configurados como un ZPOOL en espejo. Los discos duros en sí no se usan para nada:
root@XXX:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 37G 1.25G 35.7G 3% ONLINE -
root@XXX:~# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0
errors: No known data errors
root@XXX:~# format
Searching for disks...
The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.
The current rpm value 0 is invalid, adjusting it to 3600
The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.
The current rpm value 0 is invalid, adjusting it to 3600
done
c1t2d0: configured with capacity of 1862.95GB
c1t3d0: configured with capacity of 1862.95GB
AVAILABLE DISK SELECTIONS:
0. c1t0d0
/pci@0,0/pci15d9,9@1f,2/disk@0,0
1. c1t1d0
/pci@0,0/pci15d9,9@1f,2/disk@1,0
2. c1t2d0
/pci@0,0/pci15d9,9@1f,2/disk@2,0
3. c1t3d0
/pci@0,0/pci15d9,9@1f,2/disk@3,0
Specify disk (enter its number):
Yo quiero copiar tal cual los datos de mi ZPOOL actual a la máquina nueva, pero hay un problema:
La versión del ZPOOL en mi máquina fuente es la 22, con "datasets" versión 4. OpenSolaris 2009.6 soporta
hasta la versión 14 del ZPOOL y la versión 3 de los "datasets". Esto tiene dos problemas fundamentales:
problemas de compatibilidad en el "zfs send/zfs receive", y problemas para acceder al "pool" en caso
de que el sistema falle en producción.
Para esto hay dos soluciones posibles: una es ejecutar mi entorno Solaris 10 bajo una máquina virtual, la otra es utilizar una versión nueva de OpenSolaris... algo que no existe pero que podemos sustituir con la migración a una versión reciente de OpenIndiana.
No voy a entrar en detalles sobre la historia de Solaris, OpenSolaris, Illumos y OpenIndiana. Esta página no va de eso.
La web de OpenIndiana tiene una página web sobre cómo migrar desde OpenSolaris 2009.6 a OpenIndiana.
root@XXX:~# zpool detach rpool c1t1d0s0
root@XXX:~# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
errors: No known data errors
root@XXX:~# zpool create rpool-backup c1t1d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c1t1d0s0 overlaps with /dev/dsk/c1t1d0s2
root@XXX:~# zpool create -f rpool-backup c1t1d0s0
root@XXX:~# zfs snapshot -r rpool@20110803
root@XXX:~# zfs send -R rpool@20110803 | zfs receive -dFuv rpool-backup
receiving full stream of rpool@20110803 into rpool-backup@20110803
received 257KB stream in 1 seconds (257KB/sec)
receiving full stream of rpool/swap@20110803 into rpool-backup/swap@20110803
received 2.26MB stream in 1 seconds (2.26MB/sec)
receiving full stream of rpool/export@20110803 into rpool-backup/export@20110803
received 250KB stream in 1 seconds (250KB/sec)
receiving full stream of rpool/export/home@20110803 into rpool-backup/export/home@20110803
received 249KB stream in 1 seconds (249KB/sec)
receiving full stream of rpool/ROOT@20110803 into rpool-backup/ROOT@20110803
received 249KB stream in 1 seconds (249KB/sec)
receiving full stream of rpool/ROOT/opensolaris@20110803 into rpool-backup/ROOT/opensolaris@20110803
received 6.83GB stream in 148 seconds (47.3MB/sec)
root@XXX:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
rpool 37G 6.72G 30.3G 18% ONLINE -
rpool-backup 37G 6.72G 30.3G 18% ONLINE -
root@XXX:~# pkg install SUNWipkg SUNWipkg-um SUNWipkg-gui
DOWNLOAD PKGS FILES XFER (MB)
Completed 20/20 5734/5734 38.57/38.57
PHASE ACTIONS
Removal Phase 7/7
Install Phase 6635/6635
Update Phase 180/180
root@XXX:~# pkg set-publisher -O http://pkg.openindiana.org/legacy opensolaris.org
root@XXX:~# pkg image-update -v
Creating Plan / Before evaluation:
UNEVALUATED:
+pkg:/entire@0.5.11,5.11-0.134:20100302T023003Z
After evaluation:
[...]
Update Phase 11683/11683
A clone of opensolaris exists and has been updated and activated.
On the next boot the Boot Environment opensolaris-1 will be mounted on '/'.
Reboot when ready to switch to this updated BE.
---------------------------------------------------------------------------
NOTE: Please review release notes posted at:
http://docs.sun.com/doc/821-1479
---------------------------------------------------------------------------
root@XXX:~# zpool export rpool-backup
root@XXX:~# init 6
updating /platform/i86pc/amd64/boot_archive
updating /platform/i86pc/boot_archive
Mi primer paso consiste en romper el "mirror" ZFS montados sobre los SSD, y copiar la instalación actual, por si acaso queremos echarle mano. Lo siguiente es la primera parte del procedimiento documentado para actualizar de OpenSolaris 2009.6 a OpenIndiana.
Tras el reinicio, procedemos con la segunda parte de la actualización:
root@XXX:~# pkg set-publisher --non-sticky opensolaris.org root@XXX:~# pkg set-publisher -P -O http://pkg.openindiana.org/dev openindiana.org root@XXX:~# pkg image-update -v [...] DOWNLOAD PKGS FILES XFER (MB) Completed 498/498 23318/23318 248.0/248.0 PHASE ACTIONS Removal Phase 8721/8721 Install Phase 17362/17362 Update Phase 22497/22497 A clone of opensolaris-1 exists and has been updated and activated. On the next boot the Boot Environment opensolaris-2 will be mounted on '/'. Reboot when ready to switch to this updated BE. --------------------------------------------------------------------------- NOTE: Please review release notes posted at: http://docs.sun.com/doc/821-1479 --------------------------------------------------------------------------- root@XXX:~# init 6 updating /platform/i86pc/amd64/boot_archive updating /platform/i86pc/boot_archive
El reinicio falla con un error "failed to mount ramdisk from boot", Arrancamos otra vez con el BE de OpenSolaris 2009.6 y regeneramos el ramdisk de arranque del BE de OpenIndiana:
root@XXX:~# mkdir z root@XXX:~# beadm mount opensolaris-2 /z root@XXX:~# cd /z root@XXX:/z# bootadm update-archive -f -R /z/ Creating boot_archive for /z updating /z/platform/i86pc/amd64/boot_archive updating /z/platform/i86pc/boot_archive root@XXX:/z# init 6
Lo que me planteo ahora es crear un ZPOOL en los discos duros, copiar mi Solaris 10 actual en ellos y luego arrancar el sistema con ese nuevo sistema operativo.
Lo primero que hago es crear el zpool nuevo con uno de los discos duros, y transferir un "snapshot" mínimo al servidor nuevo, simplemente para comprobar que el sistema funciona. Utilizo solo uno de los discos duros porque haré las pruebas con el otro y prefiero que las transferencias de datos sean locales, en vez de tener que recurrir constantemente a transferir por red desde mi máquina original:
root@XXX:~# zpool create -oversion=22 -Oversion=4 datos-orig c1t3d0 root@XXX:~# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT datos-orig 1.81T 74.5K 1.81T 0% ONLINE - rpool 37G 1.25G 35.7G 3% ONLINE - (Aquí eliminamos los datasets que no necesitamos mover del snapshot más antiguo de mi máquina, para las pruebas preliminares. Por ejemplo elimino antiguos snapshots de zonas, logs, listas de correo, servidores web, mi cuenta personal, etc. Lo suyo es dejar SOLO el sistema operativo.) root@XXX:~# ssh MAQUINA_FUENTE zfs send -Rp datos@20100518 | zfs receive -dFuv datos-orig
Enviando solo el sistema operativo y lo mínimo, puedo hacer pruebas transfiriendo apenas 26 GB, nada más.
Obsérverse cómo creo un ZPOOL con la versión correcta, que sea compatible con Solaris 10 Update 9.
Una vez copiados todos los datos para la primera prueba, creo un segundo ZPOOL con el otro disco duro, y hago una copia, que será la que utilizaré. También comparto las propiedades del "zpool" original (ojo, el "zpool", no el "dataset" con el mismo nombre):
root@XXX:~# zpool create -oversion=22 -Oversion=4 datos c1t2d0 root@XXX:~# zfs send -Rp datos-orig@20100518 | zfs receive -dFuv datos root@XXX:~# zpool failmode=continue datos root@XXX:~# zpool listsnapshots=on datos root@XXX:~# zpool bootfs=datos/ROOT/Solaris10u9 datos cannot set property for 'datos': property 'bootfs' not supported on EFI labeled devices
Un problema más serio es el error al intentar cambiar la propiedad "bootfs", que me recuerda que el arranque estándar de Solaris / OpenSolaris no permite arrancar desde discos con EFI. Lo que hago es destruir el "zpool" que acabamos de crear, particionar el disco con una partición de 100GB, para pruebas, y volver a hacer la copia. Hay que borrar también las etiquetas EFI del disco, al principio y al final del mismo. Una opción alternativa sería utilizar los SSD como "ZPOOL" del sistema operativo, y los discos duros en sí para datos. Es algo a considerar, pero mi idea actual es utilizar las SSD para el ZIL ZFS y L2ARC.
root@XXX:~# zpool destroy datos
root@XXX:~# format -e
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0
/pci@0,0/pci15d9,9@1f,2/disk@0,0
1. c1t1d0
/pci@0,0/pci15d9,9@1f,2/disk@1,0
2. c1t2d0
/pci@0,0/pci15d9,9@1f,2/disk@2,0
3. c1t3d0
/pci@0,0/pci15d9,9@1f,2/disk@3,0
Specify disk (enter its number): 2
selecting c1t2d0
[disk formatted]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
fdisk - run the fdisk program
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
! - execute , then return
quit
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[1]: 0
Warning: This disk has an EFI label. Changing to SMI label will erase all
current partitions.
Continue? y
You must use fdisk to delete the current EFI partition and create a new
Solaris partition before you can convert the label.
format> quit
root@XXX:~# fdisk c1t2d0
(Aquí borramos la partición EFI y creamos una partición Solaris normal, de 100GB)
root@XXX:~# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0
/pci@0,0/pci15d9,9@1f,2/disk@0,0
1. c1t1d0
/pci@0,0/pci15d9,9@1f,2/disk@1,0
2. c1t2d0
/pci@0,0/pci15d9,9@1f,2/disk@2,0
3. c1t3d0
/pci@0,0/pci15d9,9@1f,2/disk@3,0
Specify disk (enter its number): 2
selecting c1t2d0
[disk formatted]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
fdisk - run the fdisk program
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show vendor, product and revision
volname - set 8-character volume name
! - execute , then return
quit
format> partition
PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
! - execute , then return
quit
partition> print
Current partition table (original):
Total disk cylinders available: 3038 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 0 (0/0/0) 0
1 unassigned wm 0 0 (0/0/0) 0
2 backup wu 0 - 3037 93.09GB (3038/0/0) 195221880
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0
8 boot wu 0 - 0 31.38MB (1/0/0) 64260
9 unassigned wm 0 0 (0/0/0) 0
partition> 0
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 0 (0/0/0) 0
Enter partition id tag[unassigned]:
Enter partition permission flags[wm]:
Enter new starting cyl[0]:
Enter partition size[195157620b, 3037c, 3036e, 95291.80mb, 93.06gb]: 3038c
partition> print
Current partition table (unnamed):
Total disk cylinders available: 3038 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 unassigned wm 0 - 3037 93.09GB (3038/0/0) 195221880
1 unassigned wm 0 0 (0/0/0) 0
2 backup wu 0 - 3037 93.09GB (3038/0/0) 195221880
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0
8 boot wu 0 - 0 31.38MB (1/0/0) 64260
9 unassigned wm 0 0 (0/0/0) 0
partition> label
Ready to label disk, continue? y
partition> quit
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
fdisk - run the fdisk program
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show vendor, product and revision
volname - set 8-character volume name
! - execute , then return
quit
format> quit
root@XXX:~# devfsadm
root@XXX:~# zpool create -oversion=22 -Oversion=4 datos c1t2d0s0
invalid vdev specification
use '-f' to override the following errors:
/dev/dsk/c1t2d0s0 overlaps with /dev/dsk/c1t2d0s2
root@XXX:~# zpool create -f -oversion=22 -Oversion=4 datos c1t2d0s0
root@XXX:~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
datos 99.5G 76K 99.5G 0% ONLINE -
datos-orig 1.81T 14.6G 1.80T 0% ONLINE -
rpool 37G 6.71G 30.3G 18% ONLINE -
root@XXX:~# zfs send -R datos-orig@20100518 | zfs receive -dFuv datos
receiving full stream of datos-orig@20100518 into datos@20100518
received 71.5MB stream in 2 seconds (35.7MB/sec)
receiving full stream of datos-orig/ROOT@20100502 into datos/ROOT@20100502
received 248KB stream in 1 seconds (248KB/sec)
receiving incremental stream of datos-orig/ROOT@20100518 into datos/ROOT@20100518
received 312B stream in 1 seconds (312B/sec)
receiving full stream of datos-orig/ROOT/Solaris10u9@20100518 into datos/ROOT/Solaris10u9@20100518
received 5.41GB stream in 43 seconds (129MB/sec)
receiving full stream of datos-orig/ROOT/Solaris10u9/var@20100502 into datos/ROOT/Solaris10u9/var@20100502
received 3.57GB stream in 34 seconds (107MB/sec)
receiving incremental stream of datos-orig/ROOT/Solaris10u9/var@20100518 into datos/ROOT/Solaris10u9/var@20100518
received 283MB stream in 5 seconds (56.6MB/sec)
receiving full stream of datos-orig/ROOT/Solaris10u9/zones@20100518 into datos/ROOT/Solaris10u9/zones@20100518
received 249KB stream in 1 seconds (249KB/sec)
receiving full stream of datos-orig/ROOT/Solaris10u9/zones/babylon5@20100518 into datos/ROOT/Solaris10u9/zones/babylon5@20100518
received 1.06GB stream in 13 seconds (83.7MB/sec)
receiving full stream of datos-orig/ROOT/Solaris10u9/zones/stargate@20100518 into datos/ROOT/Solaris10u9/zones/stargate@20100518
received 7.69GB stream in 40 seconds (197MB/sec)
receiving full stream of datos-orig/usr_local@20100518 into datos/usr_local@20100518
received 6.37GB stream in 46 seconds (142MB/sec)
receiving full stream of datos-orig/home@20100518 into datos/home@20100518
received 1.56MB stream in 1 seconds (1.56MB/sec)
root@XXX:~# zpool failmode=continue datos
root@XXX:~# zpool listsnapshots=on datos
root@XXX:~# zpool bootfs=datos/ROOT/Solaris10u9 datos
Ahora todo funciona OK. El error en el "zfs create" es debido a que, tradicionalmente, el "Slice 2" de las etiquetas SMI de Solaris cubre todo el disco duro. Estoy de pruebas, no me preocupa.
Ahora hay que preparar el arranque de este sistema.
El enfoque normal sería instalar el GRUB en ese disco duro y ponerlo como disco de arranque en la BIOS. Pero estamos hablando de una máquina hospedada en OVH, sobre la que no tengo acceso físico. El contrato proporciona acceso por KVM IP, pero durante el arranque la estabilidad del enlace es muy mala (se corta con mucha facilidad) y lograr acceder a la BIOS en los breves instantes en que está disponible durante el arranque es bastante difícil. Tras insistir durante horas consigo cambiar el orden de arranque pero, aún así, obtengo errores GRUB, así que al final opto por dejar el arranque como estaba, mantener el GRUB en las SSD y usar "chainload" para arrancar Solaris sin tener que toquetear la BIOS.
Esto supone, no obstante, que no puedo liberar completamente las SSD para utilizarlas como ZFS ZIL. Necesito utilizar una pequeña parte como disco de arranque. Es algo a mejorar en el futuro...
El siguiente paso es instalar un GRUB en el disco duro. Además, debe ser un GRUB capar de arrancar el ZPOOL con el formato de Solaris 10 Update 9, para que no me pase lo de la otra vez. El de OpenIndiana 148 me valdría. Cansado de jugármela y perder el tiempo, instalo la versión actual de mi Solaris 10 Update 9 en producción. Para ello copio en la máquina nueva los archivos "/boot/grub/stage1" y "/boot/grub/stage2" en su "/tmp". Luego hago:
Luego modificamos el "/rpool/boot/grub/menu.lst" de OpenIndiana 148, que está en las SSD, para añadir:installgrub -m /tmp/stage1 /tmp/stage2 /dev/rdsk/c1t2d0s0 installgrub -m /tmp/stage1 /tmp/stage2 /dev/rdsk/c1t3d0s0
title SOLARIS10 rootnoverify (hd2,0) chainloader +1
También subo el "timeout" del GRUB para que sea más fácil acceder a él a través del KVM. Mantengo, de momento, que GRUB arranque por defecto OpenIndiana 148. Por si las moscas.
Reinicio el ordenador, activo el KVM IP para seleccionar el arranque con Solaris 10 y cruzo los dedos.
¡¡Funciona!!.
Nos aseguramos también de poder arrancar con el segundo disco, editando manualmente en el arranque GRUB y poniendo "rootnoverify (hd3,0)".
Naturalmente hay que configurar la tarjeta de red (es un modelo distinto, y una IP diferente), cortafuegos, etc. Pero todo tiene muy buena pinta.
En OpenIndiana hacemos:
root@XXX:~# rtc -z Europe/Madrid root@XXX:~# ntpdate SERVIDOR_NTP 4 Aug 22:32:05 ntpdate[3558]: step time server IP_SERVIDOR_NTP offset 7200.075830 sec
Reiniciamos el servidor y nos aseguramos de que ahora las horas entre ambos sistemas operativos sea consistente.
Para solucionarlo, en OpenIndiana añadimos "termcapinfo xterm* ti@:te@" al fichero ".screenrc".
Envié un mensaje a la lista de correo de OpenIndiana y las respuestas fueron muy interesantes. En resumen, se trata de una "feature" opcional de OpenIndiana, llamada "fastboot", desactivable. Recomiendo leer el hilo en la lista de correo. Es interesante.
El equipo contratado en OVH dispone de dos discos duros tradicionales, y de dos discos SSD. En la configuración de serie, los discos SSD son los discos de arranque, montados en RAID 1 (mirror). Mi idea es utilizar las SSD para aprovechar dos grandes funcionalidades de ZFS: L2ARC (caché de lectura) y ZIL (caché de escritura).
Lo evidente sería mover OpenIndiana a los discos duros, liberando las SSD para estos menesteres, pero eso se ha demostrado problemático a la hora de cambiar el disco de arranque del ordenador. Otra posibilidad sería usar las SSD como disco de arranque, entrando en el sistema operativo real usando el "chainload", como hago ahora mismo con Solaris 10. De esta forma necesitaríamos mantener una pequeña partición de arranque, pero dejando la mayor parte para Solaris 10.
Tras considerarlo unos días decido mantener OpenIndiana en los SSD, porque es mi seguro ante problemas futuros. No obstante, reduciré el espacio en lo posible, para dejar espacio para los usos de Solaris 10.
Los pasos que sigo son los siguientes:
root@XXX# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0
c1t1d0s0 ONLINE 0 0 0
errors: No known data errors
root@XXX# zpool detach rpool c1t0d0s0
root@XXX# format -e
[...]
partition> print
Current partition table (unnamed):
Total disk cylinders available: 4862 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks
0 root wm 1 - 1045 8.01GB (1045/0/0) 16787925
1 unassigned wm 1046 - 1307 2.01GB (262/0/0) 4209030
2 unassigned wu 1308 - 4861 27.23GB (3554/0/0) 57095010
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0
8 boot wu 0 - 0 7.84MB (1/0/0) 16065
9 unassigned wm 0 0 (0/0/0) 0
root@XXX# zpool create -oversion=14 -Oversion=3 rpool2 c1t0d0s0
root@XXX# zpool get all rpool
NAME PROPERTY VALUE SOURCE
rpool size 37G -
rpool capacity 9% -
rpool altroot - default
rpool health ONLINE -
rpool guid 14392417079342218873 local
rpool version 14 local
rpool bootfs rpool/ROOT/OpenIndiana-148 local
rpool delegation on default
rpool autoreplace off default
rpool cachefile - default
rpool failmode wait default
rpool listsnapshots on local
rpool autoexpand off default
rpool dedupditto 0 default
rpool dedupratio 1.00x -
rpool free 33.5G -
rpool allocated 3.48G -
rpool readonly off -
root@XXX# zpool get all rpool2
NAME PROPERTY VALUE SOURCE
rpool2 size 8G -
rpool2 capacity 0% -
rpool2 altroot - default
rpool2 health ONLINE -
rpool2 guid 857709329982925092 local
rpool2 version 14 local
rpool2 bootfs - default
rpool2 delegation on default
rpool2 autoreplace off default
rpool2 cachefile - default
rpool2 failmode wait default
rpool2 listsnapshots off default
rpool2 autoexpand off default
rpool2 dedupditto 0 default
rpool2 dedupratio 1.00x -
rpool2 free 8.00G -
rpool2 allocated 68.5K -
rpool2 readonly off -
root@XXX# zpool set listsnapshots=on rpool2
root@XXX# zfs list|grep -v @
NAME USED AVAIL REFER MOUNTPOINT
rpool 5.47G 31.0G 28K /rpool
rpool/ROOT 3.47G 31.0G 19K /rpool/ROOT
rpool/ROOT/OpenIndiana-148 3.47G 31.0G 2.50G /
rpool/ROOT/OpenIndiana-148INICIAL 47K 31.0G 2.50G /
rpool/export 56K 31.0G 21K /export
rpool/export/home 19K 31.0G 19K /export/home
rpool/swap 2.00G 32.9G 8.84M -
root@XXX# zfs set compression=on rpool
root@XXX# zfs snapshot -r rpool@COPIA
root@XXX# zfs send -Rp rpool@COPIA | zfs receive -dFuv rpool2
receiving full stream of rpool@20110803 into rpool2@20110803
received 18.0KB stream in 1 seconds (18.0KB/sec)
receiving incremental stream of rpool@COPIA into rpool2@COPIA
received 15.6KB stream in 1 seconds (15.6KB/sec)
receiving full stream of rpool/swap@20110803 into rpool2/swap@20110803
received 3.85KB stream in 1 seconds (3.85KB/sec)
receiving incremental stream of rpool/swap@COPIA into rpool2/swap@COPIA
received 9.37MB stream in 1 seconds (9.37MB/sec)
receiving full stream of rpool/export@20110803 into rpool2/export@20110803
received 9.67KB stream in 1 seconds (9.67KB/sec)
receiving incremental stream of rpool/export@COPIA into rpool2/export@COPIA
received 5.65KB stream in 1 seconds (5.65KB/sec)
receiving full stream of rpool/export/home@20110803 into rpool2/export/home@20110803
received 8KB stream in 1 seconds (8KB/sec)
receiving incremental stream of rpool/export/home@COPIA into rpool2/export/home@COPIA
received 312B stream in 1 seconds (312B/sec)
receiving full stream of rpool/ROOT@20110803 into rpool2/ROOT@20110803
received 8KB stream in 1 seconds (8KB/sec)
receiving incremental stream of rpool/ROOT@COPIA into rpool2/ROOT@COPIA
received 312B stream in 1 seconds (312B/sec)
receiving full stream of rpool/ROOT/OpenIndiana-148@20110803 into rpool2/ROOT/OpenIndiana-148@20110803
received 1.31GB stream in 27 seconds (49.7MB/sec)
receiving incremental stream of rpool/ROOT/OpenIndiana-148@2011-08-04-19:11:36 into rpool2/ROOT/OpenIndiana-148@2011-08-04-19:11:36
received 2.11GB stream in 37 seconds (58.3MB/sec)
receiving incremental stream of rpool/ROOT/OpenIndiana-148@COPIA into rpool2/ROOT/OpenIndiana-148@COPIA
received 241MB stream in 2 seconds (120MB/sec)
found clone origin rpool2/ROOT/OpenIndiana-148@2011-08-04-19:11:36
receiving incremental stream of rpool/ROOT/OpenIndiana-148INICIAL@COPIA into rpool2/ROOT/OpenIndiana-148INICIAL@COPIA
received 53.3KB stream in 1 seconds (53.3KB/sec)
root@XXX# zpool set bootfs=rpool2/ROOT/OpenIndiana-148 rpool2
root@XXX# zfs get compressratio rpool
NAME PROPERTY VALUE SOURCE
rpool compressratio 1.00x -
rpool used 5.48G -
root@XXX# zfs get compressratio rpool2
NAME PROPERTY VALUE SOURCE
rpool2 compressratio 1.56x -
rpool2 used 3.97G -
Lo primero que hacemos es romper el "mirror", quitando el primer SSD. Luego lo reformateamos con tres particiones: OpenIndiana, ZIL y L2ARC.
Seguidamente creamos un ZPOOL nuevo, con una versión apropiada para que sea accesible desde Solaris 10 Update 9, que será nuestro sistema nativo. Luego activamos un modo de compresión simple en "rpool", compatible con el arranque del GRUB. Este modo de grabación solo afecta a los nuevos datos que escribamos, claro; no es algo retroactivo. A continuación creamos un snapshot en "rpool" y copiamos todos los datos a "rpool2", de forma recursiva y pasando también los atributos. Entre otros, con esto pasamos el atributo de compresión, así que los datos copiados se grabarán comprimidos, como puede verse a continuación.
Editamos el fichero "/rpool2/boot/grub/menu.lst" y cambiamos las referencias de "rpool" a "rpool2". Lo mismo hacemos en "/etc/vfstab", para el "swap".
Reiniciamos.
Una vez reiniciados, usamos "format" para formatear el segundo SSD de la misma manera que el primero, y hacemos luego un "attach":
root@XXX# zpool attach rpool2 c1t0d0s0 c1t1d0s0 Make sure to wait until resilver is done before rebooting. root@XXX# zfs destroy -r rpool2@COPIA
Una vez que el "resilvering" se completa, reiniciamos y nos aseguramos de que todo funciona.
En esta configuración, "desperdiciamos" 8GB en cada SSD, por seguridad futura (si hay problemas con el Solaris 10, podemos arrancar con OpenIndiana, incluso instalarle una máquina virtual). De esos 8GB tenemos libres 6.4GB, que en realidad son más, debido a la compresión. Todo sea por la tranquilidad de espíritu.
La máquina final tendrá arranque dual, dos sistemas operativos. Usamos dos "pools" ZFS con versiones compatibles entre OpenIndiana 148 y Solaris 10 Update 9, de forma que, en caso de problemas, podamos acceder al "pool" de Solaris 10 para una recuperación desde OpenIndiana.
Pero es previsible que esta máquina esté en producción dos o tres años, al menos, y durante este periodo seguro que actualizaré Solaris 10 varias veces. Y con él, la versión ZFS de su "pool". Además, dado que la evolución de Solaris y OpenIndiana parece diverger sin remisión (hay que ver qué hace Oracle cuando publique Solaris 11), no podemos depender de acceder directamente al "pool" Solaris desde OpenIndiana.
Para casos catastróficos, podemos tener una máquina virtual bajo OpenIndiana, en la que arrancar una imagen ISO del DVD de instalación (actualizada) de Solaris 10. Este sistema operativo virtualizado y actualizado podría acceder a "pool" ZFS de Solaris 10.
root@XXX# zfs create rpool2/opt root@XXX# zfs set compression=gzip-9 rpool2/opt root@XXX# zfs set mountpoint=/opt rpool2/opt root@XXX# zfs create rpool2/SolarisVirtualizado root@XXX# zfs set mountpoint=/SolarisVirtualizado rpool2/SolarisVirtualizado root@XXX# zfs set compression=gzip-9 rpool2/SolarisVirtualizado root@XXX# cd /SolarisVirtualizado/ root@XXX# scp SERVIDOR:/mnt/sol-10-u9-ga-x86-dvd.iso . root@XXX# wget http://download.virtualbox.org/virtualbox/4.1.2/VirtualBox-4.1.2-73507-SunOS.tar.gz root@XXX# mkdir VirtualBox-4.1.2 root@XXX# mv VirtualBox-4.1.2-73507-SunOS.tar.gz VirtualBox-4.1.2 root@XXX# cd VirtualBox-4.1.2/ root@XXX# tar xvfz VirtualBox-4.1.2-73507-SunOS.tar.gz root@XXX# rm VirtualBox-4.1.2-73507-SunOS.tar.gz root@XXX# pkgadd -d VirtualBox-4.1.2-SunOS-r73507.pkg (Instalamos VirtualBox 4.1.2) root@XXX# wget http://download.virtualbox.org/virtualbox/4.1.2/Oracle_VM_VirtualBox_Extension_Pack-4.1.2-73507.vbox-extpack (Reiniciamos el servidor)
Lo primero que hacemos es crear un par de "datasets" para albergar VirtualBox y la máquina virtual en sí. Activamos la compresión al máximo, porque nos sobra CPU y nos falta espacio en este "pool", solo tenemos 8GB.
Luego copiamos la ISO de Solaris 10 Update 9 desde otra máquina, y descargamos e instalamos VirtualBox 4.1.2. También descargamos el "extension pack", para tener acceso a través de VRDP. Reiniciamos para asegurarnos de cargar todos los módulos kernel.
A continuación creamos y configuramos la máquina virtual:
root@XXX# mv /root/.VirtualBox/ /SolarisVirtualizado/
root@XXX# mkdir "/SolarisVirtualizado/VirtualBox VMs"
root@XXX# ln -s /SolarisVirtualizado/.VirtualBox/ /root/.VirtualBox
root@XXX# ln -s "/SolarisVirtualizado/VirtualBox VMs/" "/root/VirtualBox VMs"
root@XXX# VBoxManage internalcommands createrawvmdk -filename /SolarisVirtualizado/SolarisA -rawdisk /dev/rdsk/c1t2d0p0
RAW host disk access VMDK file /SolarisVirtualizado/SolarisA created successfully.
root@XXX# VBoxManage internalcommands createrawvmdk -filename /SolarisVirtualizado/SolarisB -rawdisk /dev/rdsk/c1t3d0p0
RAW host disk access VMDK file /SolarisVirtualizado/SolarisB created successfully.
root@XXX# VBoxManage createvm -name Solaris10 -register
Virtual machine 'Solaris10' is created and registered.
UUID: a799ba86-407a-4b90-abb0-df3597389baf
Settings file: '/root/VirtualBox VMs/Solaris10/Solaris10.vbox'
root@XXX# VBoxManage modifyvm Solaris10 --memory 4000 --acpi on --vrde off --ostype Solaris --vram 32 \
--ioapic on --hwvirtex on --nestedpaging on --vtxvpid on --sata on
root@XXX~# VBoxManage storageattach Solaris10 --type dvddrive --storagectl SATA --port 0 \
--medium /SolarisVirtualizado/sol-10-u9-ga-x86-dvd.iso
root@XXX# VBoxManage storageattach Solaris10 --type hdd --storagectl SATA --port 1 --medium /SolarisVirtualizado/SolarisA
root@XXX# VBoxManage storageattach Solaris10 --type hdd --storagectl SATA --port 2 --medium /SolarisVirtualizado/SolarisB
root@XXX# VBoxManage extpack install /SolarisVirtualizado/VirtualBox-4.1.2/Oracle_VM_VirtualBox_Extension_Pack-4.1.2-73507.vbox-extpack
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".
root@XXX# VBoxHeadless --startvm Solaris10 --vrde on
En mi ordenador personal lanzo una conexión a la máquina virtual en el nuevo servidor mediante "rdesktop". Veo que ha arrancado el DVD virtual. Seleccionamos el modo "single user" e importamos el "pool" "datos". Aparentemente, todo funciona.
Pruebo varias configuraciones de la máquina virtual para arrancar el Solaris 10 instalado de forma virtualizada, sin éxito. El sistema falla y reinicia la máquina virtual a medio arranque. Es algo que tendría que investigar más pero, pensando el problema detenidamente, poder arrancar desde el CD de recuperación es todo lo que necesito, dado que esta máquina tiene KVM remoto. La peor de las situaciones es que necesite arrancar el Solaris 10 instalado con un CD/DVD insertado, cosa que no he conseguido hacer a través del KVM. En todo caso, para (intentar) arrancar el Solaris 10 virtualizado basta con desactivar el DVD virtual:
root@XXX~# VBoxManage storageattach Solaris10 --type dvddrive --storagectl SATA --port 0 --medium none
Aunque la configuración actual me valdría, el no poder arrancar el Solaris 10 instalado bajo VirtualBox es una espinita clavada. El hecho es que tengo muchas máquinas virtuales con Solaris 10, así que sé que funciona correctamente bajo VirtualBox. ¿Qué diferencia hay?.
Al final, tras mucho experimentar y comparando configuraciones, hago los siguientes cambios en la configuración:
root@XXX# VBoxManage modifyvm Solaris10 --ostype OpenSolaris_64
root@XXX# VBoxManage storagectl Solaris10 --name SATA --remove
root@XXX# VBoxManage storagectl Solaris10 --add ide --controller ICH6 --name "IDE Controller"
root@XXX# VBoxManage storageattach Solaris10 --storagectl "IDE Controller" --type hdd --port 0 --device 0 --medium /SolarisVirtualizado/SolarisA
root@XXX# VBoxManage storageattach Solaris10 --storagectl "IDE Controller" --type hdd --port 1 --device 0 --medium /SolarisVirtualizado/SolarisB
root@XXX# VBoxManage storageattach Solaris10 --storagectl "IDE Controller" --type dvddrive --port 0 --device 1 \
--medium /SolarisVirtualizado/sol-10-u9-ga-x86-dvd.iso
Con esta configuración, podemos arrancar el Solaris 10 de forma virtualizada, o bien arrancar su DVD de recuperación, según nos convenga. Con suerte, no hará falta nunca...
Un último detalle: La conexión VRDP va cifrada, pero un ataque activo "man in the middle" tendría éxito, además de que la conexión en sí no está autentificada. Es decir, cualquiera podría conectarse. Si la máquina virtual fuese permanente, habría que implementar autentificación mutua y restringir el acceso por cortafuegos.
Como medida preventiva hago:
root@XXX# VBoxManage setproperty vrdeauthlibrary "VBoxAuthSimple" root@XXX# VBoxManage modifyvm Solaris10 --vrdeauthtype external (Para generar el hash de la clave, usamos el comando 'VBoxManage internalcommands passwordhash "secret"') root@XXX# VBoxManage setextradata Solaris10 "VBoxAuthSimple/users/jcea" HASH
Para entrar en el servidor, usaremos el comando "rdesktop-vrdp -N -u jcea -p CLAVE HOST".
Con esta mejora seguimos siendo susceptibles a un ataque "man in the middle", aunque en mi caso concreto estoy bastante protegido por circunstancias que prefiero no reflejar aquí de forma pública O:-).
Otro vector de ataque es que un atacante remoto aproveche alguna vulnerabilidad en la implementación del protocolo VRDP. Ante ésto, lo más sencillo es filtrar el acceso VRDP mediante cortafuegos.
En todo caso, el uso de la máquina virtual será extremadamente puntual.
Un último detalle: Si arrancamos Solaris 10 de forma virtualizada, hay que prestar MUCHA atención a no tener su "pool" importado dentro de OpenIndiana. En caso contrario, podemos corromper el "pool" de forma irrecuperable, y sin previo aviso.
Ahora que parece que todo va bien, ha llegado la hora de crear una réplica real de la máquina original. La idea es crear un "pool" con los dos discos duros, en "mirror", y copiar en él los datos del "pool" original. Son unos 700GB, lo que estimo que me suponen unas 35 horas de transferencia.
Enviando el "pool" con "zfs send/zfs receive", si se corta el envío, tenemos que empezar desde el principio. Pero es la mejor forma de asegurarnos de transferirlo todo, incluyendo los atributos. Juguémoslo.
Lo primero que debemos hacer es formatear ambos discos duros para que el "slice 0" ocupe todo el disco, y ambos discos duros de forma idéntica. Para ello usamos "fdisk" y "format". Luego creamos un "zpool" con ambos discos en mirror. Cuidado, como antes, de crear un ZPOOL con la versión correcta, para que sea importable en Solaris 10 Update 9.
A continuación hacemos un snapshot TOTAL de la máquina origen, y transferimos el disco duro entero, con los atributos de todos los "datasets", tal y como lo hemos hecho ya más arriba.
Algo del estilo:
root@XXX# ssh MÁQUINA_ORIGEN zfs send -Rp datos@COPIA | zfs receive -dFuv datos
En mi caso la replicación mueve unos 700 GB de datos, en 35 horas.
No necesitamos los datos de "swap" y "dump", así que eliminamos su snapshot tanto en la máquina fuente como en la destino, tras la transferencia. Eso recrea la configuración (atributos) de los "datasets" "swap" y "dump" en la máquina nueva. En mi caso, 4 GB de "dump" es poco cuando la máquina nueva tiene 24GB de RAM, pero también es cierto que en mi caso concreto, tener un "dump" es poco útil si no tengo soporte oficial de Oracle. En cualquier caso, esta configuración se puede cambiar a posteriori, una vez arranquemos Solaris 10, usando el comando "dumpadm". El borrado de los snapshots de estos "datasets" la haremos al final de todo, cuando ponemos el sistema en producción.
El único problema que tiene este sistema (el enviar 700GB con "zfs send") es que si la transferencia se corta, hay que empezar de nuevo. La gran ventaja es que se transfiere toda la estructura de "datasets", con sus atributos. Esto es importante, porque en mi estructura de "datasets" es densa y complicada.
Si hubiese habido algún problema con la conexión, lo que hubiera hecho hubiera sido replicar todo de esta manera menos dos "datasets", que ocupan el 70% del disco. Esos dos "datasets" los crearía a mano, copiaría sus atributos manualmente y, al final, replicaría su contenido usando un par de "rsync" de toda la vida.
Afortunamente me he ahorrado ese trabajo. La conexión ha sido estable y rápida.
El siguiente paso debería ser reiniciar con Solaris 10 y hacer los cambios necesarios para que el sistema funcione. En particular la tarjeta de red ha cambiado (diferente "driver"), la IP nueva es diferente, etc. Lo importante es hacer todos esos cambios y documentarlos con detalle. Una vez que estamos razonablemente seguros de que todo va bien, lo que hacemos es:
(en la máquina fuente) [root@XXX]# zfs snapshot -r datos@COPIA2 (en la máquina destino) root@XXX# ssh MÁQUINA_FUENTE zfs send -Rp -I@COPIA datos@COPIA2 | zfs receive -dFuv datos
Esta nueva resincronización deshará los cambios experimentales que hicimos, así que tenemos que tenerlo todo bien documentado, para rehacerlos de nuevo en el paso final. Otra posibilidad también es copiar los ficheros modificados dentro de OpenIndiana, para ponerlos en su sitio al final, tras completar el paso final. Los ejemplos evidentes son, por ejemplo, el fichero de configuración del cortafuegos o cambios en la configuración de las Zonas Solaris.
Si para probar la configuración lanzamos las zonas Solaris, hay que tener cuidado con cosas como el correo que esté en el "spool" de salida. En general no será un problema porque las zonas Solaris, en mi caso, están configuradas bajo IPs "FailOver" (nomenclatura de OVH) y la infraestructura de red de OVH todavía no ha sido reconfigurada para apuntar al servidor nuevo. Pero son cosas que hay que pensar antes de activar nada.
Durante todo el proceso, tenemos la máquina antigua en reserva, lista para adoptar de nuevo las IPs "FailOver" y levantar las Zonas Solaris, si fuese necesario. Lo peor que puede pasar es tener que enviar de vuelta los buzones de correo. Pero, en todo caso, tenemos un mecanismo de último recurso activable en unos minutos, si ocurre una crisis inesperada.
Una vez que estamos seguros de que todo funciona perfectamente, podemos eliminar la máquina original o, mejor si tenemos la opción, la mantenemos como "backup" del servidor nuevo. Eso ya depende de las necesidades y presupuesto de cada uno.
En mi caso concreto, las cosas que debo cambiar son:
Para esto, vamos al directorio "/etc/ssh/" y generamos una clave RSA y una clave DSA, tal y como las que ya existen. Ojo con los permisos.
Reiniciamos y comprobamos que el cambio funciona. Naturalmente, el cliente SSH de nuestro ordenador personal se quejará de que ha cambiado la clave SSH del servidor, cosa que precisamente acabamos de hacer. Comprobamos que el "fingerprint" que nos sale en el cliente coincide con los que nos imprimió el servidor al crear las nuevas claves.
Sería buena idea que propagar este cambio a todos los BE Solaris ("Boot Environment"), y eliminar los snapshots viejos.
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
