SafeChildren Banner

Havoc Oracle Solaris Experts

viernes, 29 de enero de 2010

Cómo Obtener WWN HBA Solaris 10

Introducción
En muchas ocasiones es necesario verificar nuestro zonning en el switch de fibra, pero por algún extraño motivo, la HBA que queremos revisar tiene suelta la etiqueta -o perdida- la etiqueta de su WWN.

En post anteriores habíamos visto Cómo ver las LUNs Asignadas a un HBA, sin embargo, a partir de Solaris 10 se ha introducido un comando nuevo llamado <fcinfo> que nos permite obtener la información de nuestra HBA y de sus puertos.
# fcinfo hba-port
HBA Port WWN: 230000144f010690
        OS Device Name: /dev/cfg/c2
        Manufacturer: QLogic Corp.
        Model: 2200
        Firmware Version: 2.1.145
        FCode/BIOS Version: ISP2200 FC-AL Host Adapter Driver: 1.15 04/03/22
        Type: L-port
        State: online
        Supported Speeds: 1Gb
        Current Speed: 1Gb
        Node WWN: 220000144f010690
HBA Port WWN: 210000e08b86661e
        OS Device Name: /dev/cfg/c1
        Manufacturer: QLogic Corp.
        Model: 375-3108-xx
        Firmware Version: 3.3.120
        FCode/BIOS Version:  fcode: 1.13;
        Type: N-port
        State: online
        Supported Speeds: 1Gb 2Gb
        Current Speed: 2Gb
        Node WWN: 200000e08b86661e
HBA Port WWN: 210100e08ba6661e
        OS Device Name: /dev/cfg/c3
        Manufacturer: QLogic Corp.
        Model: 375-3108-xx
        Firmware Version: 3.3.120
        FCode/BIOS Version:  fcode: 1.13;
        Type: N-port
        State: online
        Supported Speeds: 1Gb 2Gb
        Current Speed: 2Gb
        Node WWN: 200100e08ba6661e
Debemos tener en cuenta, que -como sucede con muchos comandos de acceso físico a hardware- sólo está permitido su uso en la Zona Global, ya que si lo intentamos hacer en una zona Non-Global nos mostrará el siguiente error:
# fcinfo hba-port
Cannot open /etc/hba.conf
Failed to load FC-HBA common library
ERROR
fcinfo: Unable to complete operation
# zonename
zion
Referencias

miércoles, 27 de enero de 2010

Instalar Solaris 10 Paso a Paso - VirtualBox Additions

Introducción
Continuando con nuestra serie de Instalar Solaris Paso a Paso, en esta ocasión -como es sobre VirtualBox- vamos a Instalar VirtualBox Additions para obtener mejores prestaciones en nuestro máquina virtual.

En una Instalación de Solaris -sobre SPARC o x86- que no fuese en VirtualBox -o VMWare- no será necesario realizar estos pasos.

Una vez aclarado, podemos comenzar con la instalación de VBoxAdditions, para ello, deberemos montar la ISO en VirtualBox e iniciar la máquina Virtual. Al igual que sucede con otros paquetes, utilizaremos el comando <pkgadd> con las opciones <-G> para que sólo se instale en la zona actual -que será la zona global en nuestro caso-
# cd /cdrom/vboxadditions_3.1.2_56127/
# pkgadd -G -d VBoxSolarisAdditions.pkg

The following packages are available:
  1  SUNWvboxguest     Sun VirtualBox Guest Additions
                       (i386) 3.1.1,REV=r56127.2009.12.17.13.24

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all

Procesando versión del software desde

Sun VirtualBox Guest Additions(i386) 3.1.1,REV=r56127.2009.12.17.13.24
VirtualBox Personal Use and Evaluation License (PUEL)

License version 7, September 10, 2008
...
...
(Contrato de Licencia de Sun)
...
...

Usando como directorio base del paquete.
## Procesando información del paquete.
## Procesando información de sistema.
## Verificando las dependencias del paquete.
## Verificando el espacio de disco requerido.
## Comprobando posibles conflictos con paquetes que ya están instalados.
## Comprobando programas setuid/setgid.

Este paquete contiene archivos de comandos que serán ejecutados con
permiso de superusuario durante el proceso de instalación de este
paquete.

Desea continuar con la instalación de [y,n,?] y

Instalando Sun VirtualBox Guest Additions como

## Instalando parte 1 de 1.
...

... 
  (archivos instalados)
...
...
[ verificando clase ]
## Ejecutando postinstall script.
Uncompressing files...
Configuring VirtualBox guest kernel module...
VirtualBox guest kernel module loaded.
Creating links...
Configuring X.Org...
Configuring client...
Configuring service...
Updating boot archive...
Done.
Please re-login to activate the X11 guest additions.
If you have just un-installed the previous guest additions a REBOOT is required.

La instalación de fue satisfactoria.
# reboot -- -r




Referencias

lunes, 25 de enero de 2010

Cómo Saber los Parches Aplicados a Oracle utilizando OPatch

Introducción
El mantenimiento de nuestra base de datos Oracle es una taréa que debemos tener muy en cuenta, ya que Oracle irá publicando parches -de seguridad y recomendados- de forma contínua. Por ello, es necesario ir parcheando nuestro motor.

En esta ocasión vamos a ver cómo podemos utilizar la herramienta <opatch> para ver el detalle de los parches instalados. Para ello, pondremos como argumento <lsinventory> y nos mostrará el inventario de parches aplicados a nuestro $ORACLE_HOME

$ opatch lsinventory
Invoking OPatch 10.2.0.4.9

Installer de Parche Temporal de Oracle versión 10.2.0.4.9
Copyright (c) 2009, Oracle Corporation. Todos los Derechos Reservados.


Directorio Raíz de Oracle       : /u01/app/oracle/10.2/db
Inventario Central: /export/home/oracle/oraInventory
   de           : /var/opt/oracle/oraInst.loc
Versión de OPatch    : 10.2.0.4.9
Versión de OUI       : 10.2.0.4.0
Ubicación de OUI      : /u01/app/oracle/10.2/db/oui
Ubicación de Archivo Log : /u01/app/oracle/10.2/db/cfgtoollogs/opatch/opatch2010-01-21_09-07-52AM.log

Patch history file: /u01/app/oracle/10.2/db/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u01/app/oracle/10.2/db/cfgtoollogs/opatch/lsinv/lsinventory2010-01-21_09-07-52AM.txt

--------------------------------------------------------------------------------
Productos de nivel superior instalados (3):

Oracle Database 10g                                                  10.2.0.1.0
Oracle Database 10g Products                                         10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 3                            10.2.0.4.0
Hay 3 productos instalados en este directorio raíz de Oracle.


Parches temporales (1) :

Patch  9119284      : applied on Tue Jan 19 11:51:16 CET 2010
Unique Patch ID:  12058282
   Created on 24 Dec 2009, 03:33:53 hrs PST8PDT
   Bugs fixed:
     6418420, 7835247, 7207654, 7592346, 6724797, 7936993, 7331867, 9093300
     7552067, 5879114, 5457450, 8344348, 7272297, 7136866, 7196894, 7013124
     6512622, 7196532, 8568395, 8309587, 7557226, 6509115, 8568397, 8568398
     6052226, 7424804, 6817593, 7553884, 6741425, 7513673, 8437213, 6452766
     6469211, 7527650, 8309592, 5991038, 6945157, 9119226, 6403091, 7552082
     6711853, 8304589, 6052169, 8199266, 6327692, 5756769, 7460818, 6268409
     8232056, 6687381, 6972843, 8230457, 6800507, 7027551, 6778714, 6200820
     6645719, 7393804, 6775231, 3934160, 6683178, 6650256, 7528105, 6378112
     6151380, 6844866, 4723109, 8544896, 5126719, 5890312, 7036453, 8426816
     8433026, 7270434, 7172531, 6451626, 8247855, 6324944, 6874522, 7175513
     6960489, 7341598, 8576156, 6797677, 8342923, 5895190, 7150470, 7593835
     7356443, 7044551, 8227106, 4695511, 7298688, 5747462, 8556340, 7197445
     5348308, 7937113, 8341623, 7569205, 6053134, 8409848, 6163771, 6181488
     6375150, 7295780, 6345573, 7033630, 7523475, 6954722, 7457766, 7309458
     8324577, 6840740, 6804746, 7375611, 8268054, 6512811, 6988017, 7375613
     8344399, 7340448, 8362683, 7375617, 8251247, 5933656, 6599920, 7238230
     6379441, 6452375, 6352003, 6833965, 7136489, 6610218, 7612639, 6392076
     5476236, 7609057, 7609058, 6374297, 6193945, 4693355, 8217795, 7039896
     7432514, 7330909, 6952701, 7190270, 8287155, 7207932, 6802650, 7189447
     4598439, 6615740, 7155655, 6749617, 7159505, 5868257, 5727166, 7173005
     6917874, 7013768, 7691766, 7385253, 7225720, 7257770, 7244238, 7363767
     6941717, 8267348, 7710551, 7247217, 8328954, 8909984, 6681695, 8702276
     9119284, 8217011, 7661251, 6265559, 6823287, 6991626, 6954829, 5259835
     6500033, 5923486, 7432601, 8534387, 5147386, 7697802, 6653934, 7375644
     6490140, 7662491, 8331466, 5623467, 6070225, 6635214, 7396409, 6638558
     7038750, 6714608, 6838714, 6870937, 7219752, 7263842, 7278117, 6882739
     5404871, 8836667, 8373286, 6678845, 6903051, 7936793, 6600051, 7155248
     4966512, 7155249, 7197637, 8836308, 8568402, 8568404, 8568405, 5704108
     6343150, 7280764, 6923450, 7643632, 6145177, 8836671, 8310931, 6640411
     8347704, 8836675, 7155250, 7155251, 8836677, 7155252, 8836678, 7155253
     7155254, 8292378, 6219529, 7411865, 8227091, 8340379, 7276960, 7659217
     5863926, 7022905, 7123643, 6413089, 6596564, 6851438, 8836681, 8836683
     8836684, 7579469, 8836686, 7494333, 7315642, 8340383, 8340387, 6926448
     7462072, 7600026, 6679303, 7197583, 7172752, 7326645, 7008262, 9173244
     9173248, 7573151, 7477934, 6733655, 6799205, 6980597, 6084232, 7499353
     6014513, 7140204, 7254987, 8833280, 6760697, 7693128, 6120004, 6051177
     8247215, 6858062, 6844739, 7189645, 5630796, 7196863, 6768251, 7378661
     7378735, 8290506, 5970301, 6658484, 9173253, 8309623, 7599944, 7125408
     7257461, 6987790, 7568556, 6919819, 5883691, 8886674, 6955744, 6074620
     7149004, 6857917, 8283650, 7552042, 8210889, 8287504, 6506617, 6271590
     5386204, 6976005, 8330783, 7606362, 7043989, 8309632, 7575925, 6870047
     8309637, 8309639, 6827260, 7588384, 6752765, 6024730, 6628122, 8315482
     8239142, 4637902, 8309642, 7345904, 6994160, 6404447, 6919764, 7597354
     7523787, 6029179, 5231155, 6455659



--------------------------------------------------------------------------------

OPatch succeeded.

Conclusión
La herramienta <opatch> deberá ser una de nuestras aliadas a la hora de mantener un DB Oracle, y debemos tener muy en cuenta cómo se utiliza.


Referencias

jueves, 21 de enero de 2010

Cambiar TEMP Tablespace eliminando tempfile

Introducción
A diferencia de los tablespace de datos, los temporales no hacen un uso paralelo de los datafiles asignados <en este caso tempfiles>. Oracle irá llenando el tempfile hasta que no pueda y entonces utilice el siguiente tempfile, es decir, Oracle se comportará de forma secuencial.

Este hecho hace que la estrucutra de los tablespace temporales, difiera un poco de los de datos/indices. Vamos a ver paso a paso, cómo podemos crear una estructura de un único tempfile en nuestro schema y de esta forma, no desperdiciar espacio.

Ver Tablespace Temporales
Vamos a ver cómo podemos obtener los tablespace temporales que tenemos asignados a nuestra base de datos -aquí hay muchas formas de hacerlo, pero vamos a utilizar las vistas dinámicas <v$> para ello, aunque podemos utilizar RMAN si queremos-
$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jan 18 13:33:42 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL>  SELECT TS# FROM V$TEMPFILE GROUP BY TS#;

       TS#
----------
         3
        10

SQL>  SELECT NAME FROM V$TABLESPACE WHERE TS# IN (3,10);

NAME
------------------------------
TEMP
TMPUSR
Vamos a eliminar el tempfile asignado al tablespace <TEMP> y sustituirlo por uno nuevo de 2GB en otra ubicación. Para ello, vamos a utilizar algunos de los pasos de Cómo mover un Tempfile en Caliente


Obtener los Tempfile Asignados al Tablespace
Como queremos obtener los tempfile asignados al tablespace <TEMP>, y éste tiene como TS# el valor <3>, simplemente lanzaremos una consulta a <v$tempfile> para ver que tempfiles tiene asignado.
SQL> SELECT NAME FROM V$TEMPFILE WHERE TS# = 3;

NAME
--------------------------------------------------------------------------------
/u02/oradata/TESTDB/temp01.dbf
Lo primero que debemos hacer es Añadir un Tempfile a un tablespace temporal para, que de esta forma, podamos poner en offline el tempfile que queremos eliminar. Una vez puesto en offline, simplemente haremos un drop y tendremos nuestro tablespace con la estructura nueva. Veamos los pasos con más detalle.
$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jan 18 12:18:00 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL>  ALTER TABLESPACE TEMP ADD TEMPFILE '/u03/oradata/TESTDB/temp03.dbf' SIZE 2048M AUTOEXTEND OFF;

Tablespace altered.

SQL> ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' OFFLINE;

Database altered.

SQL> ALTER DATABASE TEMPFILE '/u02/oradata/TESTDB/temp01.dbf' DROP;

Database altered.

SQL> SELECT NAME FROM V$TEMPFILE WHERE TS# = 3;

NAME
--------------------------------------------------------------------------------
/u03/oradata/TESTDB/temp03.dbf

SQL> QUIT
Disconnected from Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

Referencias

martes, 19 de enero de 2010

Instalar Solaris 10 Paso a Paso

Introducción
Este post lo he creado para la gente de Seguridad Informática - Grupo Solaris para poder tener una Guia Simple de Instalación de Solaris en VirtualBox.

La idea es comenzar con la instalación de Solaris 10 y, poco a poco, iremos poniendo a punto el sistema. Os animo a que -si tenéis tiempo y ganas- le echéis un vistazo.

Recordar que debéis descargar la imagen de Solaris (DVD) desde el sitio de Descargas de Sun y, aunque no lo parezca lo mío no es editar video, xD

Aquí os dejo la Parte 1 de la Instalación


Instalación de Solaris Paso a Paso - Parte 1




Referencias

Añadir un Tempfile Tablespace Temporal Oracle

Introducción
Un tablespace temporal se gestiona igual que uno de datos/indices. Por ello, los pasos para Cómo Añadir un Datafile a un Tablespace nos pueden servir de ayuda, son la única diferencia que donde pone <DATAFILE> en este caso debe ser <TEMPFILE>

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jan 18 12:18:00 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL>  ALTER TABLESPACE TEMP ADD TEMPFILE '/u03/oradata/TESTDB/temp03.dbf' SIZE 2048M AUTOEXTEND OFF;

Tablespace altered.

Referencias

lunes, 18 de enero de 2010

Cómo Añadir Datafile a un TableSpace Oracle

Introducción
Un tablespace puede contener uno o varios datafiles. El hecho de tener varios nos permite que Oracle utilice al máximo las controladoras y, de esta forma mejorar en el rendimiento. Esto -como siempre- depende de nuestra arquitectura, ya que si tenemos una única controladora y/o un único almacenamiento no conseguiremos una mejora en el rendimiento.

Por ejemplo, si tenemos una única LUN donde almacenamos nuestros datafiles el objetivo de añadir uno nuevo, no será para mejorar el rendimiento -ya que las peticiones irán por el mismo canal-, sino que será porque hemos llegado al máximo del tamaño de datafile -en Solaris 64bits 32GB-.

Teniendo esas ideas claras, la mejor opción es tener una estrucutra OFA donde cada disco esté en un punto de montaje, y a su vez, por una controladora distinta. De esta forma, sí que obtendremos una mejora en el rendimiento.

En este caso, he optado por añadir un datafile sin autoextend pero era para simplificar la instrucción, podemos hacer que se autoexpanda hasta un máximo de 32Gb.

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jan 18 12:18:00 2010

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL>  ALTER TABLESPACE TBSD ADD DATAFILE '/u05/oradata/TESTDB/tbs05.dbf' SIZE 2048M AUTOEXTEND OFF;

Tablespace altered.

Referencias

jueves, 14 de enero de 2010

Como recuperar contraseña postgres

Introducción
Puede que se nos <olvide> la contraseña de Super Usuario de PostgreSQL <postgres> y no seamos capaces de realizar ninguna operación sobre ella. Esto que parece un serio problema no será tanto si cumplimos los siguientes requisitos:
  • Tener acceso a la máquina que tiene instalado el servidor <por ssh, físico, etc ..>
  • Tener acceso con el usuario que ejecuta el servidor PostgreSQL <normalmente postgres>
Si tenemos estos requistos, será coser y cantar, sino, será un poco más complicado.

Asumiendo que los tenemos, y ya estamos conectados a la máquina que tiene el servidor con el usuario que la ejecuta, primero debemos editar el archivo de configuración <$PGDATA/pg_hba.conf> y permitir el acceso local sin contraseña, es decir, trust. Para ello, buscaremos la entrada -si la tenemos-
#"local" is for Unix domain socket connections only
local   all         all                               md5
Y la sustituiremos por
# "local" is for Unix domain socket connections only
local   all         all                               trust
Guardaremos y saldremos del editor. A continuación, deberemos llamar a postgres para que vuelva a leer los archivos de configuración, para ello utilizaremos el comando <pg_ctl> con la opción <reload>
$ pg_ctl reload
se ha enviado una señal al servidor
Ahora, nos conectaremos a postgres utilizando el comando <psql> y podremos cambiar la contraseña, utilizando la instrucción SQL <ALTER USER nombre WITH PASSWORD 'password';>
$ psql
psql (8.4.2)
Digite «help» para obtener ayuda.

postgres=# ALTER USER postgres WITH PASSWORD 'nueva_pass';
ALTER ROLE
postgres=# \q
Por último, sólo nos queda revertir el cambio en el archivo <$PGDATA/pg_hba.conf> y llamar a <pg_ctl> para que vuelva a leer la configuración.
$ vi /var/postgres/8.4/data/pg_hba.conf
    # "local" is for Unix domain socket connections only
    local   all         all                               md5

:wq
$ pg_ctl reload
se ha enviado una señal al servidor
$ psql
Contraseña:
psql (8.4.2)
Digite «help» para obtener ayuda.

postgres=# \q
Conclusión
Como podéis ver, si tenemos acceso a la máquina la tarea resulta realmente sencilla. Si no fuese así, el tema se complica y no es en este post cómo explicarlo.

Referencias

martes, 12 de enero de 2010

Diferencias entre Solaris Volume Manager y ZFS - Parte 2

Introducción
En la primera parte comenzamos a ver las diferencias principales entre Solaris Volume Manager -svm- y ZFS. En esta nueva entrega, vamos a ver -de una forma más práctica- cómo llevar a cabo las principales tareas en ambos sistemas: svm y zfs

Aunque hay muchos puntos que tratar, vamos a empezar por lo básico en cuanto a gestión se refiere. Para ello, vamos a ver cómo crear diferentes tipos de RAID tanto en <svm> como en <zfs>.

Antes de empezar, hay que recordar que <zfs> está sólo para Solaris 10, y por lo tanto, si estas obligado a estar en Solaris 9, no hay muchas opciones ... o tal vez sí. Una de las opciones es Solaris 8 and 9 Containers, pero eso será en próximas entregas.

Vamos a asumir que tenemos Solaris 10 y tenemos la siguiente configuración -la utilizaremos en todos los ejemplos-. Para ello utilizaremos Sun VirtualBox -ya que nos ofrece potencia al simular discos-
  • VirtualBox 3.1.2 sobre MacOS X :D
  • Solaris 10 10/09 x86 64bits
  • c0d0 [hdd_os]
  • c2t0d0 [hdd_zfs1]
  • c2t1d0 [hdd_zfs2]
  • c2t2d0 [hdd_zfs3]
No voy a entrar en detalle sobre cuáles son los diferentes tipos de RAID que existen -asumo que ya son conocidos- simplemente vamos a hacer una aclaración sobre las diferencias de <strip> y <concatenation> que, en ambos casos, hacen referencia a un RAID 0.

Si bien ambos son RAID 0, internamente se estructuran de forma diferente -a nivel de blocks-. En el caso de <strip> el contenido a escribir se divide entre el número de discos que forman parte del RAID 0 y se escribe de forma simultánea en cada uno de ellos, sin embargo, esto supone un pequeño trabjo extra ya que debe dividir los datos -mira el gráfico que se muestra a continuación-



Si hablamos de <concatenation> el proceso será diferente. El sistema irá llenando cada uno de los discos que forman parte del array -de uno en uno- y cuando uno esté completo, continuará en el siguiente.



Esto es importante ya que nunca deberemos hacer un strip de discos con datos, ya que los perderemos. Sin embargo, si que podremos hacer una concatenation de un slice con datos sin perderlos.

Preparativos para Solaris Volume Manager
Antes de comenzar debemos recordar que Solaris Volume Manager necesita de una base de metadatos y ésta debe estar accesible para el sistema desde el boot, sino no será posible montar el RAID en el arranque.

Además, Solaris Volume Manager trabaja a nivel de slice -tambien llamado Soft Partition- y por lo tanto, debemos tener correctamente dividido el disco. Para nuestro caso, vamos a hacer dos slice, una de 16Mb para la base de datos de <svm> y otra de 4.88GB -como se muestra en la tabla de particiones-
# prtvtoc /dev/rdsk/c2t0d0p0
* /dev/rdsk/c2t0d0p0 partition map
*
* Dimensions:
*     512 bytes/sector
*      32 sectors/track
*     128 tracks/cylinder
*    4096 sectors/cylinder
*    2558 cylinders
*    2556 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector
*           0      4096      4095
*       36864      4096     40959
*    10285056    184320  10469375
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      0    00       4096     32768     36863
       2      5    01          0  10469376  10469375
       7      0    00      40960  10240000  10280959
       8      1    01          0      4096      4095
Repetiremos estos pasos para cada uno de los discos -c2t0, c2t1 y c2t2- y así poder ubicar tres réplicas de la base de datos en cada uno de ellos, en el slice 0

Creación de la Base de MetaDatos
Para la creación utilizaremos el comando <metadb> con la opción <-a> para añadir una nueva réplica -base de datos- y la opción <-f> para forzar el comando. Si utilizamos el comando sin argumentos, nos mostrará el estados de las réplicas actuales.
# metadb -a -f c2t0d0s0
# metadb -a -f c2t1d0s0
# metadb -a -f c2t2d0s0
# metadb
        flags           first blk       block count
     a        u         16              8192            /dev/dsk/c2t1d0s0
     a        u         16              8192            /dev/dsk/c2t0d0s0
     a        u         16              8192            /dev/dsk/c2t2d0s0
Creación de un RAID 0 -striped-
Para la creación de los grupos, utilizaremos el comando <metainit>  cuyo formato es el siguiente:
metainit {nombre} {número stripes} {componentes del strip} {componentes} [-i tamaño del bloque]
Por ejemplo, vamos a crear un volumen "tripped con tres componentes y un tamaño de 32k
# metainit d0 1 3 c2t0d0s7 c2t1d0s7 c2t2d0s7 -i 32k
d0: Concatenación/reparto está configurado
# metastat d0
d0: Concat/Stripe
    Tamaño: 30720000 bloques (14 GB)
    Banda 0: (entrelazado: 64 bloques)
        Dispositivo   Bloque de in Base         Reubic
        c2t0d0s7             0     No           Si
        c2t1d0s7             0     No           Si
        c2t2d0s7             0     No           Si

Device Relocation Information:
Device   Reloc  Device ID
c2t0d0   Si     id1,sd@f2f2f1fe14b4b97550006a7c60000
c2t1d0   Si     id1,sd@f2f2f1fe14b4b97550006e82c0001
c2t2d0   Si     id1,sd@f2f2f1fe14b4b9755000780380002
Una vez creado nuestro RAID0, deberemos crear el sistema de archivos al igual que si de un disco normal se tratase. Para ello, utilizaremos el comando <newfs> con el tamaño de bloque a 8k, pero ahora nuestro <device> ya no será /dev/rdsk/cXtYdZ, sino /dev/md/rdsk/d0

# newfs -i 8192 /dev/md/rdsk/d0

Por último, editaremos nuestro  /etc/vfstab e incluiremos la entrada correspondiente si queremos que cada vez que nuestro sistema se inicie, monte la unidad.

/dev/md/dsk/d0    /dev/md/rdsk/d0    /raid    ufs    2    yes    -
Creación de un RAID0 -ZFS-
Para crear un RAID0 utilizando ZFS, primero deberemos crear un pool -podemos entender esto como un grupo de discos, en los cuales exportaremos LUNs- y para ello deberemos utilizar el comando <zpool> con la opción <create> y el nombre del pool que queremos asignarle.

La primera diferencia es que con ZFS no es necesario crear una base de metadatos, además, en vez de utilizar las soft partitions <slice> se utilizará el disco completo

# zpool create  raid0 c2t0d0 c2t1d0 c2t2d0

Podemos comprobar cómo ZFS monta nuestro RAID en /raid0 y es totalmente utilizable -no es necesario llamar a <newfs>-
# df -h raid0
Sistema de archivos  tamaño usados aprovechar capacidad Montado en
raid0                   15G    21K    15G     1%    /raid0
 Nota: Si los discos que utilizamos contienen una estructura UFS, el sistema nos informa de ello y nos pide que utilicemos la opción <-f> para crearlo.

# zpool create raid0 c2t0d0 c2t1d0 c2t2d0
especificación de vdev no válida
utilice '-f' para anular los siguientes errores:
/dev/dsk/c2t0d0s7 contiene un sistema de archivos ufs.
# zpool create -f raid0 c2t0d0 c2t1d0 c2t2d0
Creación de un LUN
Una vez creado nuestro pool podemos crear diferentes LUN -o puntos de exportación- con el fin de optimizar la estructura, por ejemplo: u01, u02. Para ello utilizaremos el comando <zfs> con los argumentos <create>

# zfs create raid0/u01
# zfs set quota=9G raid0/u01
También podemos hacerlo todo en un sólo comando, por ejemplo, vamos a crear una  LUN de 1Gb y que se monte en /raid0/u02
# zfs create -o quota=1G raid0/u02
Podemos ver el resultado de nuestras LUN haciendo un simple <df>
# df -h
Sistema de archivos  tamaño usados aprovechar capacidad Montado en
raid0                   15G    24K    15G     1%    /raid0
raid0/u01              9,0G    21K   9,0G     1%    /raid0/u01
raid0/u02              1,0G    21K   1,0G     1%    /raid0/u02

Conclusión
Hemos visto cómo Solaris Volume Manager nos permite utilizar las llamadas Soft Partitions que, en determinadas ocasiones, nos puede interesar. Además en cuanto a complejidad, ZFS ha evolucionado de forma muy significativa, dejando en dos comandos <zpool> y <zfs> la gestión de los volúmenes.

En las siguientes partes iremos viendo cómo crear otro tipo de RAID y, por último su rendimiento.

Referencias

viernes, 8 de enero de 2010

Diferencias entre Solaris Volume Manager y ZFS - Parte 1

Introducción
Desde la introducción de ZFS en Solaris 10 el mundo del almacenamiento anda un poco revuelto. Vamos a ver cómo en este post intentamos ver las diferencias de ZFS y Solaris Volume Manager <Solaris Solstice DiskSuite en Solaris 8> para ello vamos a hacer un poco de historia

Solaris Volume Manager
SVM es un Gestor de Almacenamiento -también llamado Gestor de Volúmenes- incluido en la versión 9 de Solaris que estaba basado en Solstice DiskSuite.

ZettaByte File System
ZFS es un Sistema de Ficheros y Gestor de Volúmenes incluido en la versión 10 de Solaris y con un diseño nuevo basado en Copy-on-Write 

Bien, hay que entender claramente lo que significa Gestor de Alamacenamiento y no confundirlo con Sistema de Archivos. Ahora que tenemos definidos los dos conceptos, vamos a ver si profundizamos en cada uno de ellos.

Un Gestor de Volúmenes se encarga de administrar los discos físicos mediante los formatos de redundancia establecidos, es decir, RAID0, RAID1, RAID5 y de escribir el contenido en el sistema de ficheros que se nos proporciona en dichos discos.

Dicho de otra forma, nuestro Gestor de Volúmenes hará de intermediario entre Solaris y nuestros discos físicos, para ello utiliza una base de datos especial <llamada metadb> donde se almacenan los metadatos necesarios para su gestión.

Es de vital importancia que esa metadb se encuentre en discos locales -no en una SAN- ya que debe estar disponible en arranque antes de pasar a level 3 y por lo tanto, Solaris pueda leerla y saber cómo debe trabajar.

Veamos el siguiente dibujo con la estructura SVM:


Como acabamos de explicar, Solaris Volume Manager hace de capa intermedia entre los discos y nuestro Sistema Operativo, sin embargo, el sistema de ficheros se mantiene intacto. Por lo tanto, svm utiliza las particiones del disco y se encarga de sincronizar, duplicar, ... los datos para adecuarlos al nivel de RAID establecido.

Entonces, si svm hace uso de la particiones <slice>, si tengo un disco HDD0 con dos particiones <c1t0d0s0> y <c1t0d0s4> puedo utilizar Solaris Volume Manager para crear un RAID 1? La respuesta es SI -aunque no tiene sentido-.


Veamos un ejemplo de RAID1 con dos discos c2t2d0 y c2t1d0s0
# metastat
d50: Duplicación
     Subduplicación 0: d51
      Estado: Correcto
    Subduplicación 1: d52
      Estado: Correcto
    Paso: 1
    Opción de lectura: geometric (-g)
    Opción de escritura: parallel (predeterminado)
    Tamaño: 2064384 bloques (1008 MB)

d51: Subduplicación de d50
    Estado: Correcto
    Tamaño: 2064384 bloques (1008 MB)
    Banda 0:
        Dispositivo   Bloque de in Base        Estado Reubi Repuesto en marcha
        c2t1d0s0             0     No        Correcto    Sí


d52: Subduplicación de d50
    Estado: Correcto
    Tamaño: 2064384 bloques (1008 MB)
    Banda 0:
        Dispositivo   Bloque de in Base        Estado Reubi Repuesto en marcha
        c2t2d0s0             0     No        Correcto    Sí


Device Relocation Information:
Device   Reloc  Device ID
c2t2d0   Sí     id1,sd@f084596884b30c5470007ac9c0001
c2t1d0   Sí     id1,sd@f084596884b30c547000664340000
Entonces si SVM hace uso del sistema de ficheros UFS -en nuestro caso-, uno puede pensar que es posible montar uno de los discos de la forma tradicional con el comando <mount>. Lo cierto es que SI pero no debemos hacerlo.

Vamos a ver el contenido de ambos discos con un ejemplo -tener en cuenta que no es mi intención escribir sobre la utilización de SVM o ZFS en este post, para ello publicaré Cómo Utilizar Solaris Volume Manager-

# mount -F ufs -o ro /dev/dsk/c2t2d0s0 /mnt
# ls -l /mnt
total 32
lrwxrwxrwx   1 root     root           9 dic 23 17:22 bin -> ./usr/bin
drwxr-xr-x   3 root     sys          512 dic 21 18:23 export
dr-xr-xr-x   2 root     root         512 dic 23 10:51 home
drwx------   2 root     root        8192 jun  5  2009 lost+found
dr-xr-xr-x   2 root     root         512 dic 23 10:51 net
drwxrwxrwt   2 root     root         512 dic 23 17:08 tmp
drwxr-xr-x  15 root     sys          512 jul 17 10:54 usr
drwxr-xr-x  45 root     sys         1024 jul 11 15:59 var
dr-xr-xr-x   2 root     root         512 dic 23 10:52 vol
# mount -F ufs -o ro /dev/dsk/c2t1d0s0 /mnt2
# ls -l /mnt2
total 32
lrwxrwxrwx   1 root     root           9 dic 23 17:22 bin -> ./usr/bin
drwxr-xr-x   3 root     sys          512 dic 21 18:23 export
dr-xr-xr-x   2 root     root         512 dic 23 10:51 home
drwx------   2 root     root        8192 jun  5  2009 lost+found
dr-xr-xr-x   2 root     root         512 dic 23 10:51 net
drwxrwxrwt   2 root     root         512 dic 23 17:08 tmp
drwxr-xr-x  15 root     sys          512 jul 17 10:54 usr
drwxr-xr-x  45 root     sys         1024 jul 11 15:59 var
dr-xr-xr-x   2 root     root         512 dic 23 10:52 vol

Ahora vamos a ver cómo se monta utilizando Solaris Volume Manager. Para ello, debemos utilizar el device <md>
# mkdir /raid
# mount -F ufs /dev/md/dsk/d50 /raid
# cd /raid/
# ls -ltr
total 32
drwx------   2 root     root        8192 jun  5  2009 lost+found
drwxr-xr-x  45 root     sys         1024 jul 11 15:59 var
drwxr-xr-x  15 root     sys          512 jul 17 10:54 usr
drwxr-xr-x   3 root     sys          512 dic 21 18:23 export
dr-xr-xr-x   2 root     root         512 dic 23 10:51 net
dr-xr-xr-x   2 root     root         512 dic 23 10:51 home
dr-xr-xr-x   2 root     root         512 dic 23 10:52 vol
drwxrwxrwt   2 root     root         512 dic 23 17:08 tmp
lrwxrwxrwx   1 root     root           9 dic 23 17:22 bin -> ./usr/bin
# rm bin

Ahora comprobamos cuál es el resultado de nuestro disco. Debemos desmontarlo puesto que lo tenemos en ReadOnly.
# umount /mnt2
# mount -F ufs -o ro /dev/dsk/c2t1d0s0 /mnt2
# ls -l /mnt2/
total 30
drwxr-xr-x   3 root     sys          512 dic 21 18:23 export
dr-xr-xr-x   2 root     root         512 dic 23 10:51 home
drwx------   2 root     root        8192 jun  5  2009 lost+found
dr-xr-xr-x   2 root     root         512 dic 23 10:51 net
drwxrwxrwt   2 root     root         512 dic 23 17:08 tmp
drwxr-xr-x  15 root     sys          512 jul 17 10:54 usr
drwxr-xr-x  45 root     sys         1024 jul 11 15:59 var
dr-xr-xr-x   2 root     root         512 dic 23 10:52 vol
Todo esto lo hemos hecho para demostrar cómo Solaris Volume Manager se apoya en el sistema de ficheros para realizar las tareas. Además, este ejemplo sólo es válido para RAID 1 ya que se hace una copia de un slice a otro. En RAID0, RAID5 no será posible.

En ZFS las cosas son un poco diferentes. Ya hemos comentado que es un Gestor de Volúmenes y Sistema de Ficheros por lo tanto tenemos todo lo necesario en un único punto. En el siguiente gráfico se muestra conceptualmente su funcionamiento.



Veamos qué sucede con ZFS siguiendo el mismo ejemplo anterior. Lo primero vamos a crear nuestro pool -que se asemeja a nuestra metadb- y las LUN

# zpool create -f testZ mirror c2t1d0 c2t2d0
# zpool status
  conjunto: testZ
 estado: ONLINE
 limpiar: no se ha solicitado ninguna
config:

        NAME        STATE     READ WRITE CKSUM
        testZ       ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c2t1d0  ONLINE       0     0     0
            c2t2d0  ONLINE       0     0     0

errores: ningún error de datosconocido
# zfs create testZ/lun0
# zfs create testZ/lun1
# df -h
Sistema de archivos  tamaño usados aprovechar capacidad Montado en
testZ                  976M    19K   976M     1%    /testZ
testZ/lun0             976M    18K   976M     1%    /testZ/lun0
testZ/lun1             976M    18K   976M     1%    /testZ/lun1
Como toda la gestión se encuentra dentro de ZFS, cambiar sus propiedades resulta realemente sencillo, por ejemplo, asignar una quota a cada LUN
# zfs set quota=256M testZ/lun0
# zfs set quota=256M testZ/lun1
# df -h
Sistema de archivos  tamaño usados aprovechar capacidad Montado en
testZ                  976M    21K   960M     1%    /testZ
testZ/lun0             256M    16M   240M     7%    /testZ/lun0
testZ/lun1             256M    18K   256M     1%    /testZ/lun1
Vamos a ver qué sucede si intentamos montar ahora los discos
# mount -F zfs -o ro /dev/dsk/c2t1d0s0 /mnt
cannot open '/dev/dsk/c2t1d0s0': invalid dataset name
# mount -F ufs -o ro /dev/dsk/c2t1d0s0 /mnt
mount: /dev/dsk/c2t1d0s0 no es de este tipoFS
Hasta aquí la Primera Parte a modo de introducción. En las siguientes iremos viendo cuáles son los escenarios donde cada uno de ellos se comporta como pez en el agua y como no, rendimiento.

Conclusión
Nos hemos introducido en el mundo de los Volume Manager y, aunque a simple vista, ZFS parece la panacéa en las siguientes entregas veremos cómo Solaris Volume Manager puede -y debe- usarse para hacernos la vida más fácil.

Aunque no he querido entrar en el detalle de Cómo trabajar con SVM o ZFS algo se ha escapado, prometo dedicar tiempo para explicar con ejemplos sencillos -y complicados- su uso.

Siguientes Partes

Referencias

lunes, 4 de enero de 2010

Diferencias Procesadores Virtuales, Threads y Cores UltraSPARC

Introducción
Los nuevos diseños de procesadores añaden nuevas formas para resolver los problemas pero, además introducen nuevos retos y configuraciones para poder exprimir al máximo las nuevas arquitecturas.

Uno de los problemas que los nuevos procesadores han introducido son las diferencias entre procesadores virtuales, procesadores reales y threads de ejecución. Vamos a ver si podemos poner un poco de orden y definir las diferencias de cada uno de ellos y cómo nos afectan a la configuración en Solaris.

Antes de comenzar con la explicación de cada uno de ellos, vamos a definir los nombres y así poder saber de qué estamos hablando:
  • Chip: Pastilla de Silicio
  • Hardware Thread: Unidad básica de <planificación> a nivel de procesador
  • Core: Unidad básica de <ejecución> con un procesador
  • SMP: Symmetric Multiprocessing. Arquitectura de computación donde varios procesadores están conectados a través de una memoria compartida
  • CMP: Chip Multriprocessing. Procesador que combina una tecnología de varios <core> en el mismo <chip>
  • CMT: Chip Multithreading. Procesador que permite la ejecución de <hardware thead> en el mismo <chip> que, a su vez, puede contener varios <cores>; O una combinación de ambas tecnologías: Varios <threads> con varios <cores>



Para explicar mejor el funcionamiento de los procesadores, podemos ver las siguientes imágenes donde se explica el funcionamiento de interno de un procesador. Los valores de Compute Cycle son aquellos donde realmente se está realizando un trabajo y Memory Wait son aquellos en los que el procesador está a la espera de IO.


Por lo tanto, el diseño CMT intentará utilizar aquellos Memory Cycle para introducir otros Compute Cycle <hardware thread> y por lo tanto simular varios procesadores dentro del mismo core.

Como podemos ver en la imagen, vamos a llenar aquellos huecos que nuestro procesador está a la espera de IO para poder realizar nuevas tareas y así poder llevar a cabo operaciones en paralelo.

Entonces, realmente tenemos varios procesadores? La verdad es que no. La única solución para tener varios procesadores es tener varios cores o varios chips, aunque en algunos tipos de aplicaciones se puede aproximar.

Tipos de CPU, Cores y Hardware Threads de UltraSPARC
Podemos ver una tabla con las diferentes arquitecturas UltraSPARC con cores, threads y procesadores virtuales. Esta tabla nos servirá posteriormente para poder entender cómo dividir los procesadores virtuales de forma correcta.



Cómo trata Solaris los <Hardware Thread>
Para Solaris los <hardware thread> son tratados como <procesadores virtuales> y por lo tanto si hacemos un <psrinfo> en una máquina UltraSPARC VI con dos CPU veremos el siguiente resultado:
# psrinfo
0       en línea   desde 08/29/2009 05:20:41
1       en línea   desde 08/29/2009 05:20:42
2       en línea   desde 08/29/2009 05:20:42
3       en línea   desde 08/29/2009 05:20:42
8       en línea   desde 08/29/2009 05:20:42
9       en línea   desde 08/29/2009 05:20:42
10      en línea   desde 08/29/2009 05:20:42
11      en línea   desde 08/29/2009 05:20:42
Como podemos ver, para Solaris existen 8 cpu virtuales, que corresponden con: 2CPUx2CORESx2Thread -según la tabla de CPUs-, sin embargo si lanzamos el comando <psrinfo> con la opción <-pv> -physical- veremos la siguiente salida:
# psrinfo -pv
El procesador físico dispone de 4 virtuales virtuales  (0-3)
  SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
El procesador físico dispone de 4 virtuales virtuales  (8-11)
  SPARC64-VI (portid 1032 impl 0x6 ver 0x93 clock 2150 MHz)
Podemos ver con mayor detalle al ejecutar <prtconf -v> la estrucutra que Solaris asigna a los Hardware Threads y los cores
-snip-
    pseudo-mc, instance #0
        System software properties:
            name='ddi-forceattach' type=int items=1
                value=00000001
        Hardware properties:
            name='mirror-mode' type=int items=1
                value=00000000
        Register Specifications:
            Bus Type=0x4082, Address=0x200, Size=0x0
    cmp (driver not attached)
        core (driver not attached)
            cpu (driver not attached)
            cpu (driver not attached)
        core (driver not attached)
            cpu (driver not attached)
            cpu (driver not attached)
    cmp (driver not attached)
        core (driver not attached)
            cpu (driver not attached)
            cpu (driver not attached)
        core (driver not attached)
            cpu (driver not attached)
            cpu (driver not attached)

    pci, instance #0
        Driver properties:
            name='interrupt-priorities' type=int items=6 dev=none
                value=0000000e.0000000e.0000000e.0000000e.0000000e.0000000e
-snip-
Os preguntaréis el por qué de tanto detalle sobre los Hardware Threads, y a continuación os lo explicaré.

Cómo Dimensionar Correctamente un PSet
Como he comentado antes, para Solaris un  Hardware Thread es igual que un core, sin embargo, estas dos soluciones no son equiparables. En el mejor de los casos un Hardware Thread se comportará como un procesador, pero en el peor -interdependencias entre los threads- no podrán ejecutarse en paralelo.

Con esta premisa en mente, debemos saber que para Dimensionar Correctamente un PSET -Processor Set- debemos seguir siempre la siguiente regla:
Asignar un número de CPU Virtuales múltiplo del número de Hardware Threads que tenga cada core.

Vamos a ver si puedo explicar con más detalle este tema. Si continuamos con el ejemplo de nuestra CPU UltraSPARC64 VI, para Solaris existen 8 vCPU y por lo tanto, puedo crear un PSet de 1 a 8 vCPU. Sin embargo, como hemos comentado, debemos crear PSet -siempre- con múltiplo de número de hardware threads y como son 2 debería ser de: 2, 4, 6 u 8 vCPU. Vemos la siguiente tabla:



Por ejemplo las siguientes combinaciones será correctas:
  • vCPU [0,1,2,3] : pset1
  • vCPU [8,9,10,11] : pset2
Pero las siguientes serán incorrectas:
  • vCPU [0,1,2] : pset1 -el vCPU 2 pertenece al core1-
  • vCPU [3,8,9,10] : pset2 -el vCPU 3 y vCPU 10 a cores diferentes-
Entonces, Cómo sé qué tipo de asignación tengo que hacer?
La verdad es que la única solución para esto es conocer el tipo de CPU que tienes instalada y, por lo tanto, cuántos cores y threads tiene. A partir de ahí, dividir en función del número de threads.


Además, tener en cuenta que si utilizamos la opción dedicated-cpu de una Zona no Global, lo que realmente estamos haciendo es crear un pset, y por lo tanto, deberemos seguir las mismas reglas.


Conclusión
El hecho de que Solaris interprete los Hardware Threads como Procesadores Virtuales hace que el control de los cambios de contexto se produzcan dentro del hardware, además, esto hace que escalar Solaris sea mucho más sencillo. Pero también, introduce el problema de crear Processor Sets siempre con el número de Hardware Threads de cada core y por último, no mezclar Hardware Threads de Cores diferentes. Si tenemos estos pequeños consejos, y ahora que sabemos más sobre el funcionamiento de los procesadores SPARC y cómo Solaris trabaja con ellos, podemos dimensionar mejor nuestros recursos.


Nota: Los gráficos sobre CMT han sido obtenidos de http://developers.sun.com/solaris/articles/chip_multi_thread.html

Referencias