Recuperar un sistema de almacenamiento basado en MD + LVM2

La semana pasada tuve un gran inconveniente en uno de los servidores de apoyo operacional, un rack server HP DL380 G5 (2009) el cual arrancaba desde una unidad HP de almacenamiento multiple de discos duros la cual ya cierto tiempo atras venia con un disco duro presentando fallo fisico el cual hacía parte de un arreglo de discos asociados a una storage pool ZFS. Este pool fue configurado con RAIDZ-2 (un RAIDZ reforzado con dual paridad para sostenerse en linea incluso con dos discos averiados o en fallo) La idea consistía en reemplazar el disco averiado por uno nuevo de repuesto. Pero eso es otra historia, para un próximo post lo dedicaré a compartir la experiencia del caso de uso acerca de reemplazar el disco averiado.

EL pasado viernes 12 de febrero, aseguré dicho host el cual para mi sorpresa desplegaba errores cíclicos en algunos sectores del disco de arranque, a pesar de la advertencia apagué el equipo y bueno retiré el disco pero había olvidado un juego de destornilladores especiales para poderlo soltar del caddy. Fui a colocarlo nuevamente y volver a encenderlo. He ahi que con gran sorpresa encuentro que el sistema no arranca! OMG!, no puede arrancar siquiera el grub boot. Con preocupación me retiré y el lunes siguiente (15 de febrero) empecé a revisar dicha novedad.  Retiré el disco del slot 1 del MSA2000 unit que es donde estaba ubicado el grub bootloader, lo coloco en mi equipo el cual previamente le habia instalado una PCIe HBA Card con  conector de cable multisata (4 puertos) que habia comprado unos 3 años atrás por eBay especifcamente para poder dumpear discos a bajo nivel con dd. Desafortunadamente el disco arrancó con sonido de cabeza atascada y traqueaba fuerte, clara señal de que algo no estaba bien en el. Ni siquiera era reconocido por la controladora asi que la situación se ponía color de hormiga. Para ese momento aun no acaba de recordar de que años atrás cuando preparé el sistema había configurado con RAID1 basado en "Linux MD". Fue entonces cuando procedí a desconectar el siguiente disco en orden del arreglo el cual efectivamente tendría la información del disco. Para verificar que estaba al menos bueno para su uso, procedi a colocarlo en el slot 1 y encenderlo. Intentaba bootearlo pero no tenía grub, fue cuando tomé ese disco y lo coloqué en la controladora instalada en mi estación de trabajo paara verificar que contenía en su interior al menos en los sectores de la cabecera del disco.  Allí terminé encontrando que encima del RAID1 (Linux MD) encontré una estructura basada en LVM2 !!!!!.  La titanica tarea iniciaba, lograr llegar al fondo de los datos y recuperar la información alli presente. Al tener RAID1 con 2 discos, y al tener el 1er disco fuera de linea fisicamente averiado y bloqueado, la unica forma era lograr acceder a las particiones que estaban por debajo de LVM y este por debajo de LinuxMD en ese disco de respaldo.   Estos fueron los pasos que llevé a cabo para lograrlo:  (desde mi equipo el disco ha sido dispuesto por el o/s desde /dev/sdd)

Primero que todo verificar la estructura de particionamiento de disco para saber en que parte se encuentra la información:

root@m0n0-PT1650:/home/m0n0lithic# sfdisk /dev/sdd
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdd: 121601 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Old situation:
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdd1          0+     31-     31-    248832   83  Linux
/dev/sdd2         31+ 121601- 121570- 976510977    5  Extended
/dev/sdd3          0       -       0          0    0  Empty
/dev/sdd4          0       -       0          0    0  Empty
/dev/sdd5         31+ 121601- 121570- 976510976   fd  Linux raid autodetect
Input in the following format; absent fields get a default value.

Usually you only need to specify and (and perhaps ).

Se escanea entonces dicha partición para ubicar mas información al respecto de su estructura:

mdadm --examine --scan  /dev/sdd5 ARRAY /dev/md2 level=raid1 num-devices=2

ARRAY /dev/md/0 level=raid1 num-devices=2
 ↪UUID=9b6e03fe:b73c43f2:1a490486:daa901de

   devices=/dev/sdd5

Como podemos observar la partición asignada a Linux RAID MD es la número 5. Ahora es turno de poder invocar el driver y simular el RAID para que el o/s me permita ingresar a lo que está debajo de el. Con la siguiente instrucción escaneo preliminarmente dicha partición para que el driver md le reconozca y la disponga:

# mdadm --examine --scan level=raid1 /dev/sdd5 num-devices=2 ARRAY /dev/md/0 metadata=1.2 UUID=9b6e03fe:b73c43f2:1a490486:daa901de name=copiapo:0

El UUID tambien es posible sacarlo por el sistema de asignacion al dispositivo md/0 en /dev/disk/by-uuid/

El siguiente paso luego de scanear en el dispositivo es habilitar la unidad al sistema linux RAID:
# mdadm -A -s

Se verifica que este ya atado con:
# cat /proc/mdstat


Luego se procede a recuperar y renombrar el volumen LVM2, pero para ello como no se tiene información certera de la estructura LVM2, se procede a capturar los primeros 255 sectores del disco a recuperar. Dicha salida se almacena en un archivo temporal.  Es allí donde radica la información estructural:

# dd if=/dev/md0 bs=512 count=255 skip=1 of=/tmp/md2-raw-start

Parte de la información extraida es esta (para este ejemplo):

COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 1
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0

physical_volumes {

pv0 {
id = "nKq99y-jngj-Aj0T-vw4O-nhsQ-2U1O-d0KVuC"
device = "/dev/md0"

status = ["ALLOCATABLE"]
flags = []
dev_size = 1952759424
pe_start = 2048
pe_count = 238373
}
}

# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:23 2014

contents = "Text Format Volume Group"
version = 1

description = ""

creation_host = "copiapo"       # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626943      # Tue Jun 24 16:22:23 2014

logical_volumes {

SWAP {
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
id = "qHXmbW-I9hG-IL2V-SKXi-LFPv-PUuO-Kw74eR"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403626970
segment_count = 1

segment1 {
start_extent = 0
extent_count = 2861

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0

]
}
}
}
}
# Generated by LVM2 version 2.02.95(2) (2012-03-06): Tue Jun 24 16:22:50 2014

contents = "Text Format Volume Group"
version = 1

description = ""

creation_host = "copiapo"       # Linux copiapo 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64
creation_time = 1403626970      # Tue Jun 24 16:22:50 2014

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@COP01 {
id = "jg3MRj-5TrS-wdBQ-IXCR-KJ0c-c1hF-hE3tTq"
seqno = 3
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]


ROOT {
id = "3K3u2T-Srwh-Cy0D-AQz0-uVUY-dTyP-JtMYSu"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "copiapo"
creation_time = 1403627035
segment_count = 1

segment1 {
start_extent = 0
extent_count = 235512

type = "striped"


Como ya tenemos el nombre del grupo principal ("COP01") igualmente verificamos a través de vgscan (volume group) y pvscan (physical vol) asi:

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "COP01" using metadata type lvm2

# pvscan
  PV /dev/md0   VG COP01   lvm2 [931,14 GiB / 0    free]
  Total: 1 [931,14 GiB] / in use: 1 [931,14 GiB] / in no VG: 0 [0   ]

Luego de identificado lógica y fisicamente el volumen LVM2, Se procede a activar el volume group "COP01" 

# vgchange COP01 -a y

  2 logical volume(s) in volume group "COP01" now active

Finalmente se habilita dicho VG (Volume Group) para que la capa de archivo del sistema operativo pueda reconocerlo como un dispositivo mas de I/O:



# mount /dev/COP01/ROOT /mnt/linux

root@m0n0-PT1650:/home/m0n0lithic# df
Filesystem              1K-blocks      Used Available Use% Mounted on
udev                      4052292        12   4052280   1% /dev
tmpfs                      812632      1184    811448   1% /run
/dev/sdc6               110560080   9857656  95063256  10% /
none                            4         0         4   0% /sys/fs/cgroup
none                         5120         0      5120   0% /run/lock
none                      4063152     29016   4034136   1% /run/shm
none                       102400        68    102332   1% /run/user
/dev/sdc1                  528112    191668    309616  39% /boot
/dev/sda1              1953521664 960410740 989882988  50% /home
/dev/mapper/COP01-ROOT  949389436 651391012 249749184  73% /mnt/linux

ó df -h

/dev/mapper/COP01-ROOT  906G  622G  239G  73% /mnt/linux

A partir de este punto es cuando el administrador fisico del sistema puede disponer de la información guardada bajo esa estructura para su respectivo aseguramiento.


Espero sea de su agrado, les guste y le sirva de soporte para alguien que tenga una situación similar. Hasta una pronta aparición.

ETHXBT::Kraken:Daily: Beware, there is a negative divergence present and active

ETHXBT::Kraken::Daily: Please, be careful with this negative divergence in RSI and ADX, it is likely that at any time a major dump occurs.

chart by TradingView

For some days now I have been recording such disagreement even though the price was a breakout with some momentum. For this time and even though the price of Ether wants to push higher, it is highly likely that a significant or in the worst cases, a selloff sale comes.

Una nueva "muerte" de Bitcoin vs el auge de Ethereum

El pasado 14 de enero el mundo de Bitcoin y su comunidad de inversionistas y usuarios en todo el mundo se estremecía con un articulo del desarrollador Mike Hearn acerca de su apreciación general sobre el fracaso del proyecto Bitcoin, en lograr un consenso [2] favorable hacia su propuesta de BitcoinXT [1] (junto con el reconocido desarrollador élite: Gavin Andresen) que trataba basicamente de dar una solución (BIP 101: sobre la modificación en el tamaño limite de cada bloque hasta 1MB por uno de mayor capacidad hasta 8MB duplicandose cada dos años) y de su intención de ser recibida y aceptada por el resto de la red. Esta situación finalmente terminaría con su aislamiento y renuncia como parte del anillo de desarrolladores de bitcoin core.
Aunque para muchos causó mucha molestia, Quitandome la camiseta de fan de bitcoin, personalmente y de todas las criticas propuestas por Hearn las que mas me quedan en el tintero son:

1. Limite teórico de 7 transacciones por segundo
Si Bitcoin piensa salir al "mainstream" esta limitante estará afectando considerablemente su rendimiento ya que ademas de la ya conocida latencia de aprox. 10 minutos por cada confirmación, esta limitante estaría presentando un obstáculo sobre todo frente a las capacidades de medios tradicionales de transferencias de valor.  Durante un "test stress" efectuado en julio pasado se demostró una capacidad de 3 transacciones (tx) por segundo.

2. Ha dejado de ser descentralizado para darle paso a la centralización
La sensación de que bitcoin ha dejado de ser generación democrática ya es una realidad. Al principio durante los primeros años se minaba de forma absolutamente independiente ya que la red estaba despoblada y se minaba con procesadores normales (había que encontrar el bloque para recibir recompensa de 50 bitcoin). Luego desarrolladores migraron el algoritmo de minería de alto desempeño hacia GPUs (Aceleradoras de video con poder computacional), el poder computacional aumentaba al ritmo de la dificultad, eso conllevó a generar unas piscinas o pools donde los mineros unían su poder individual hacia un todo que representaba el pool, en el momento que alguno de los mineros atado al pool encontraba el bloque la recompensa se distribuía en el número de shares resueltos. Actualmente con el paso hacia los componentes ASIC, se armó una guerra por el poder computacional a nivel paises y regiones del mundo por optimizar la generación de bitcoin con su algoritmo sha256 pero ya no con pequeñas granjas de servidores, sino con bodegas gigantes que cobijan miles de servidores hospedando dichos mineros. Estas iniciativas fueron acabando con la rentabilidad de aquellos con pequeñas granjas y mineros "de a pie" los cuales muy seguramente muchos fueron saliendo y todo fue centralizandose hacia China y Estados Unidos.

3. Desconfianza en el manejo de los Exchanges
Mas que algo comentado por Hearn, lo agrego como un detalle personal.
Con el auge de bitcoin y luego de su euforia de 2013 (En noviembre de ese año el precio marcó su valor mas alto hasta ahora: aprox. USD $1200 por bitcoin) al año siguiente, el precio estuvo marcado hacia la baja por motivos tan criticos como: Desconfianza del inversionista debido al quiebre de casas exchange como Mt.GOX, y actualmente el reciente sonado caso de la insolvencia de Cryptsy. Curiosamente ambos exchanges manifiestan hackeo y posterior robo electrónico de las monedas de sus clientes desde sus billeteras internas (manejadas por ellos y no por sus propietarios de cuenta).

El salto de Ethereum...

A Ethereum le he llamado la superautopista universal, el gran engranaje que se enfoca no solo a soluciones financieras sino tambien al internet de las cosas. No es sólo una representación de valor que equivale al ether (ETH) una especie de "gasolina" de la red.  Su principal objetivo se enfoca hacia los contratos inteligentes (smart contracts) los cuales se gestionan dentro de su poderoso y eficiente modelo de cadena de bloques. Esa caracteristica le permite definir una criptomoneda como un activo más tratado y llevado a cabo contablemente dentro de el.  Su primer proyecto Frontier fue el lanzamiento del protocolo fue el pasado 30 de Julio de 2015, con la generación del bloque génesis.
Desde el punto de vista del análisis técnico de la "coin fuel" o ether, el precio en presale estuvo altisimo y rapidamente descendió, se recuperó un poco y volvió a caer con mas fuerza. Digamos que con harta acumulación previa, hace mas de dos semanas el precio despertó y se fue en rally. Noticias malas debido a la problematica del tamaño del bloque en Bitcoin y la indecision de la comunidad por escoger la mejor opción técnica que ayude a desembotellar el protocolo, sumado a eso el tan esperado anuncio de Cryptsy y su decadencia sumada al robo  supuestamente por hackeo de sus wallets propició el terreno para que la especulación ayudase al valor de Ether.
Pienso que desde el punto de vista de mercado, Bitcoin ha sido la raiz de todo y deberá preservarse como la referencia en criptomonedas, de ahi hacia adelante pues pueden ocurrir cambios en las capitalizaciones y eso tambien es valido. Ripple hace unos dias había sido desbancado por Ethereum en medio de su rally eufórico que lo ha llevado por encima de los 7 mBTC (0.007 BTC / 700K Satoshis).

[1] http://www.xtnodes.com/
[2] https://bitnodes.21.co/

UNE 4GLTE : Mentiras y Verdades acerca del retiro del servicio.

Hace unos dias recibí una llamada de una asesora de UNE (ahora TIGO-UNE) comentandome de que desafortunadamente el gobierno nacional les había exigido a UNE devolver el ancho de banda asignado en el espectro de los 2600Mhz como consecuencia a la fusión TIGO-UNE. La asesora me comentaba que Tigo se haría cargo del negocio movil, por tal motivo UNE debía cerrar su red LTE (recordemos que fueron la primera implementación en Colombia) . Esto conllevo a UNE a solicitar a cada abonado de su servicio LTE fijo inalambrico con el fin de continuar brindandole el servicio trasladando su suscripción a un plan tigo limitado (como cualquier oferta de telefonía celular en Colombia). Desafortunadamente por costos no me ha sido posible continuar con su servicio 4GLTE de 3Mbps de ancho de banda y de uso ilimitado, por tal motivo solicité la cancelación de dicho plan pospago el cual vencía cancelando hasta el 31 de Enero de 2016.Hoy al llegar a la oficina me percaté de que finalmente había finalizado su servicio conmigo despues de casi 3 años ininterrumpidos. En teoría la fusión TIGO-UNE conllevó a UNE a suspender y prescindir de su red con cobertura LTE dejandole esa parte del negocio a TIGO el cual lo ha tomado como un servicio móvil, donde no hay servicio ilimitado, todos se presentan como cuenta controlada.  A continuación la imagen que ahora me aparece al intentar navegar con el servicio:

Analizando mejor la situación tengo casi la certeza de que el meollo del asunto es que a TIGO no le gusta ofrecer planes 3G/4G móviles ilimitado asi sea fijo (via hotspots MiFi) por capricho de no permitir a un usuario hacer uso de dicha red con trafico alto. Esta situación me obligó a buscar un nuevo operador que me permita continuar utilizando un servicio de calidad a un mejor precio inclusive.
Hasta siempre LTE inalambrico fijo, seguramente mas adelante podrían cambiar las reglas del juego. Espero en Dios y asi sea pq realmente es eficiente y muy práctico.