Bitácora de PSI.: Alta Disponibilidad et al.

No entraré en cuestiones que quedan muy bonitas en la teoría pero que para nuestra operativa profesional no nos van a aportan muchas soluciones, como lo que pueda ser o dejar de ser un sistema tolerante a fallos o un sistema de alta disponibilidad, así como sus sutiles diferencias. En pocas palabras, la Alta Disponibilidad, High Availability (HA), hace referencia a las instalaciones pensadas para "garantizar" un servicio eficiente durante los 525600 minutos del año. Como nota adjunta, señalar la posibilidad de mantener las conexiones y recuperar las sesiones en entornos de alta disponibilidad con persistencia.

Cuando hablamos de clusters siempre pensamos en un grupo o "pandilla" de equipos que, por un motivo u otro, tienen una cierta e "íntima" relación. En cuanto a pandillas, las hay de muchos tipos.

Los clusters para procesamiento de datos constituyen una potente herramienta en tareas que requieren de una gran potencia de cálculo. Aunque en un primer momento se podría pensar en temas de edición de vídeo y rendering, cálculo científico intensivo, etc., en nuestro caso iríamos más bien hacía el cómputo al servicio de los ataques por (pseudo)fuerza bruta. Entre las soluciones disponibles para este tipo de clusters destacar el proyecto Beowulf y Mosix, aunque no tienen un gran interés en nuestro ámbito de actuación.

Otro tipo de clusters estaría orientado a la redundancia de máquinas proporcionando el mismo servicio. Recuerda que la redundancia es un mecanismo de seguridad. De esta forma, nos protegeremos contra posibles fallos del servicio y, o, máquina, además de incrementar la potencia en la prestación del servicio.

En este tipo de instalaciones deberemos plantearnos una serie de tareas, como el control de los computadores del cluster, la monitorización de servicios y su replicación, las comunicaciones y, pensando en sistemas que proporcionan un mismo servicio, la forma de compartir el almacenamiento.

En cuanto al almacenamiento existen varias posibilidades que, en gran medida, estarán en función de los €s disponibles. No debemos olvidar que el factor económico tiene que ser uno de los principales en toda toma de decisión y que bajo ningún concepto "debemos matar usuarios a cañonazos", aunque siempre habrá capullos dispuestos a "matar hippies en la Cíes". El actual despliegue de cañones en nuestra profesión empieza a apestar. Sin duda alguna es el momento de volver al camino de la búsqueda de la sencillez para evitar ???. Recuerdo la semana que pasé impartiendo clase en cierta universidad de un pequeño pero gran país en el que un joven con una creatividad asombrosa proporcionaba servicio de correo electrónico y web a toda la organización con un único PC. De vuelta al contexto de nuestro desarrollo, se podría plantear desde servidores de disco en red sobre NFS (Network File System) o Samba, hasta soluciones de almacenamiento SAN (Storage Area Networks). También otras alternativas como la mera sincronización de dispositivos de almacenamiento, por ejemplo con un rsync (dependiente del entorno de trabajo), el exportado de disco cifrado mediante sshfs (Secure Shell File System), o el uso de sistemas de ficheros distribuidos como GFS (Global File System) o MogiFS.

Por su parte, la detección de servicios deberá encargarse de identificar si están "caídos". De la misma forma habrá que monitorizar si un determinado host está o no operativo. Aunque hay distintas soluciones únicamente incluiremos en este punto mon, para la monitorización de servicios, y heartbeat para la interrogación entre hosts. El proceso de monitorización deberá hacerse en la capa 7 por razones obvias (si, esas con las que nos han torturado a tantos y tantos estudiantes de informática a lo largo de los años). Y, dado que estamos en PSI, sería muy aconsejable que toda comunicación estuviese cifrada adecuadamente. También podremos incluir redundancia parcial en nuestros equipos, por ejemplo de fuente de alimentación, tarjetas de red, controladoras de disco, etc.

En cuanto a soluciones, aunque existen varias, únicamente incluiré el Proyecto Linux Virtual Server (LVS). De forma resumida, instalaremos un conjunto de sistemas en el que un balanceador de carga, que podría redundarse según las necesidades, constituirá el elemento de interacción con cualquier petición de servicios. El balanceador deberá re-direccionar las peticiones a los servidores según unos criterios que "parezcan" medianamente inteligentes (carga de los servidores, anchos de banda, con persistencia, o por cualquier ecuación que pueda integrar de una forma más o menos ponderada diversos parámetros característicos de carga, entre otras). Los servidores podrán atender directamente las peticiones o utilizar el balanceador como un proxy. Recuerda que los "cuellos de botella" son nuestros enemigos. Señalar en este punto la existencia de dispositivos orientados al balanceo de carga. Aunque no soy muy amigo de refernciar soluciones comerciales, en este caso haré una excepción con los balanceadores de carga barracuda para que el alumno tenga referencia de la existencia de este tipo de productos. Obviamente existen otras muchas alternativas.

Sobre la naturaleza del balanceo, podrá plantearse a nivel IP, característico del LVS, o a nivel de aplicación-servicio, mediante el uso por ejemplo de reverse-proxy (cuyo nombre es autoexplicativo). Apache dispone de distintos módulo para implementar reverse proxy.

El servicio de DNS (Domain Name System) nos puede proporcionar una alternativa básica al balanceo de carga y que no requiere "grandes" desplieges. En pequeñas instalaciones esta podría ser una opción aceptable. Los servidores DNS de nuestro dominio responderán a las peticiones hacia el servidor de referencia con una relación de IPs, normalmente mediante un round-robin. Como es obvio, esta solución no contemplará la carga de los servidores, ni el ancho de banda estimado entre el cliente y los servidores que pueden atender su petición (de interés en el caso de clusters distribuidos geográficamente). En el caso de un servicio web, la dirección www.[nuestro-dominio] se resolvería cíclicamente mediante un round-robin sobre varias IPs. Como es obvio, será necesario incluir algún mecanismo que permita retirar una resolución ante una caída de un servidor. ¿Y si está "cacheada" en uno o más clientes?. La implementación en el caso de bind únicamente requerirá de varias entradas CNAME, por ejemplo.:

server1 IN A 193.144.48.10

server2 IN A 193.144.51.16

server3 IN A 193.144.63.83

www IN CNAME server1

IN CNAME server2

IN CNAME server3

Unido a la multitud de referencias en internet sobre configuración de clusters de HA, con o sin NAT, a nivel 2 o 3, etc., para los amantes de la literatura técnica en papel, esa que debería tender a su desaparición completa, señalar por ejemplo el artículo "Replicación y alta disponibilidad con pgpool II de PostgreSQL" del número 108 de la publicación Mundo Linux.

Entre las diversas herramientas con las que podremos "jugar", considerando que jugar es la mejor técnica para aprender, señalar ldirectord (para monitorización de servicios HTTP y HTTPS), heartbeat (para monitorización de equipos), o el entorno gráfico lvs-gui (para configurar un cluster LVS). Existen muchas otras opciones de HA y load balancing aunque esta entrada no tiene como objetivo tal revisión.

Al finalizar la clase se analiza la evolución en nuestros sistemas de información y servidores, desde los monoservidores, pasando por soluciones redundantes con o sin balanceo de carga a las configuraciones de servidores basados en la virtualización y para-virtualización. Finalmente vemos que las posibilidades que nos ha proporcionado el mundo de la virtualización y su aportación en el salto a lo que hoy se conoce como computación en la nube (ver por ejemplo simulador del IBMSmartCl​oud).
Juega aprendiendo y aprende jugando,

Security A(r)t Work

Inicio esta sección de referentes en el ámbito de la PSI, incluyendo los que, por un motivo u otro, me hayan llamado la atención. Security A(r)t Work es una "delicia" en el campo, con una visión y una forma de "plasmar" los contenidos muy de agradecer.

Bitácora de PSI.: Una de cuotas

En el capítulo anterior hemos hablado, entre otras cosas, de los sistemas de ficheros. Hoy trataremos de poner algunas barreras al campo en la forma de cuotas.

Es necesario definir cuotas en nuestros sistemas de ficheros, tanto locales como en red, especialmente en entornos multiusuario. Bueno, si tu máquina únicamente te tiene a ti por usuario, no será tan crítica esta tarea, aunque ...

Nuestro espacio de almacenamiento no suele ser infinito, por lo que será necesario limitar su uso. No es bueno dejar llenar nuestros discos duros. Como mínimo poner cuotas al número de bloques e inodes por usuario y, o, grupo. De forma resumida para vuestras máquinas de laboratorio podéis utilizar este mini-howto "Debian Disk Quota Management". Para asignar cuotas podrás utilizar el quotatool o el edquota. Normalmente se definen varias cuotas tipo a usuarios que se utilizan para asignar a otros usuarios:

$ sudo edquota -p ...

# for i in `cat /etc/passwd [pipe] cut -f1 -d:`; do edquota -p $i; done

Este último comando asignará cuota a todo usuario del /etc/passwd, incluido root, admin, etc. Si quieres asignárselo a un grupo determinado, según el caso, puedes utilizar algún pequeño "script" o comando para seleccionar los usuarios afectados.

En este punto, utilizamos unas viejas conocidas en el mundo de los procesos, las llamadas "fork bombs", que sirve para ilustrar la necesidad de configurar otro tipo de cuotas, como las de procesos. Es bastante habitual encontrarnos en la actualidad máquinas multiusuario con cuotas de disco, pero no de procesos. Tal vez la más conocida, publicada y comentada de las "fork bombs" sea :(){ :[pipe]:& };:

De forma resumida, abre un terminal como usuario y ejecuta dicha cadena. En el caso de que el sistema no tenga cuotas de proceso, se comerá el procesador de la máquina y la dejará tirada. Esta cadena es una función llamada : que se auto-llama de forma recursiva dos veces y que se vuelven a llamar, como diría el inminente Buzz Light Year, "hasta el infinito y más allá". Esta función se puede reescribir de la siguiente forma para una mejor comprensión:

mifuncion(){ mifuncion[pipe]mifuncion& };mifuncion

Para microsoft en un cmd si se ejecutas un fichero por lotes mifuncion.bat cuyo contenido sea %0[pipe]%0 el efecto será el mismo. Existen otras muchas fork bombs, pero que no tienen ningún interés más que el de ilustrar la necesidad de definir cuotas en los distintos subsistemas gestionados por nuestros sistemas operativos. Aunque aquí veremos cuotas para el sistema de ficheros y procesos, recuerda que también tenemos otros recursos que pueden requerir de cuotas, como por ejemplo nuestros interfaces de red (por IP, servicios, etc.), para evitar posibles abusos (traffic shapping y QoS).

En el caso de cuotas de proceso, en los equipos del laboratorio (debian) tienes el fichero de configuración de linux-pam /etc/security/limits.conf. En el que podrás definir cuotas para distintos elementos, por ejemplo.:

@colegas hard nproc 100
@enemigos hard nproc 10

La primera línea definiría un límite "hard" de número de procesos a los usuarios del grupo colegas de 60 y, en la segunda, de 10 para los enemigos.

* hard nproc 60

Esta línea establecerá un límite de procesos de 60 para todo bicho que pulule en el equipo, a excepción del root. No olvides que un proceso puede generar un gran número de procesos. Analizar el perfil de los procesos de tus usuarios y sus necesidades te permitirá definir la política de asignación de cuotas. Bajo ningún concepto debemos considerar la típica coña de "usuario bueno, usuario muerto". Nosotros trabajamos para ellos y, sin ellos, nuestro trabajo no tendría sentido.

Y, es suficiente con las cuotas que hemos visto?. En el caso del fichero /etc/security/limits.conf podrás definir, al igual que se hace con nproc, límites para otros parámetros (fuente fichero de configuración de las debian de laboratorio).:

core limits the core file size (KB)
data max data size (KB)
fsize maximum filesize (KB)
memlock max locked-in-memory address space (KB)
nofile max number of open files
rss max resident set size (KB)
stack max stack size (KB)
cpu max CPU time (MIN)
as address space limit
maxlogins max number of logins for this user
maxsyslogins max number of logins on the system
priority the priority to run user process with
locks max number of file locks the user can hold
sigpending max number of pending signals
msgqueue max memory used by POSIX message queues (bytes)
nice max nice priority allowed to raise to
rtprio max realtime priority

Otros muchos parámetros configurables del sistema los encontrarás en /etc/login.defs y /etc/pam.d/common-password

password required pam_unix.so nullok obscure min=4 max=8 md5

¿Qué opinas de la línea anteriore que puedes localizar en los ficheros common-password de las máquinas de laboratorio?. ¿Qué opinas del uso de password md5 de longitud mínimo 4?. ¿Debemos enviar al md5 a hacerle compañía al crypt?. De momento no, pero requiere unos ciertos cuidados, que recuerdan a los últimos días del crypt.

Para que puedas dedicar un poco de tiempo a probar alguna herramienta, señalar dos dedicadas a la reproducción de ataques por fuerza bruta sobre una gran cantidad de servicios, Medusa y THC Hydra. Sin entrar en IDSs de propósito general, existen herramientas para su detección y filtrado, como fail2ban, denyhosts, blocksshd o sshdfilter. Su funcionamiento se centra en la identificación en los ficheros de "log" de ataques por fuerza bruta desde determinadas IPs para su filtrado normalmente mediante iptables. Será necesario incluir excepciones, para no filtrar lo que no se debe, y tener en cuenta la posibilidad de paquetes IP spoofing que nos puedan producir el filtrado de equipos confiables.

Y la pregunta que está en el aire, ¿no vas a dar más niveles RAID?. Hemos llegado hasta aquí hablando de sistemas de ficheros y RAIDs, y no hemos terminado nuestra aventura. Es hora de cerrarla, y descubrir al asesino.

Se analiza el funcionamiento de los RAID3 y 4, de los que no incluyo en esta entrada nada, al no ser de gran interés para nosotros. El RAID5, uno de nuestros clásicos, ilustra la utilización de información de paridad distribuida entre un grupo de discos para garantizar la recuperación ante el "casque" de un disco duro. El RAID5 incrementa el rendimiento respecto al 3 y 4, evitando el cuello de botella de tener toda la paridad en un único disco duro.

Desde un punto de vista operativo, la mayoría de los RAID que montamos son 0, 1 y 5. Existen otros muchos RAID, pero no son de este mundo -:). Recuerda que los discos duros se pueden llenar (el próximo día de clase hablaremos de LVM), se pueden estropear, te los pueden robar. RAID puede proporcionar un cierto nivel de seguridad, pero no funciona ante un borrado accidental de ficheros, no sustituye al backup, no protege de incendios, inundaciones, etc. También puedes plantear hacer RAID sobre discos remotos, por ejemplo con Fibre Channel.

En algunas ocasiones los RAID se van de fiesta y se montan RAID10 (grupos de "mirrors" "stripeados") o RAID01 (grupos de "stripeados" "mirroreados") [estos últimos términos son el resultado de un proceso de fusión, mis disculpas a la RAE].

Aunque los RAID pueden incrementar el rendimiento también puedes plantear el uso de distintos planificadores de entrada salida a disco o ajustar algunos de sus parámetros. Sin duda alguna, el "tunning" es un deporte maravillo que, por desgracia, se practica poco.

Recuerda que la partición de swap puede darle mucho trabajo a tu disco. No te olvides dimensionar al swap adecuadamente, y meterlo en un disco rápido. También puedes crear varias particiones de swap y distribuirlas entre varios discos, asignándoles prioridades. De esta forma, tu swap podrá irse de vacaciones a varios discos, y utilizar eso que se llama acceso concurrente.

Otra instalación que puede sernos de interés es hacer "mirroring" del sistema operativo. Y finalmente, para que puedas crear, monitorizar y hacer todo tipo de pruebas con los RAID en los equipos del laboratorio, el mdadm.

Avaliación

Información y cartel remitido por el Rectorado.
-----------------
PROFESORADO DA UDC

Achégase o cartel anunciador da Avaliación Docente, para que poida darlle publicidade entre o seu alumnado colocándoo na aula, na porta do seu despacho, ou onde estime conveniente.

Grazas pola súa colaboración
Saúdos cordiais
avaliemos at udc.es

Reporte de errores.: Código Técnico de la Edificación (CTE)

Adjunto reporte literal de errores respecto a la entrada "Sector Inmobiliario TIC". Revisaré las modificaciones y todo el CTE para hacer un upgrade de mi cabeza.
-------------------------
"La norma NBE-CT79 se encuentra actualmente derogada, viniendo a ser sustituida por el documento básico DB-HE: Ahorro de energía y la norma CPI-96 por el documento DB-SI: Seguridad en caso de incendio. Todos ellos forman parte del nuevo Código Técnico de la Edificación, conocido por CTE que vienen a sustituir a las antiguas Normas Básicas de la Edificación. Han ido entrando en vigor de forma escalonada y de algunos de ellos ya han ido saliendo modificaciones.

Este es el enlace desde donde se pueden descargar.: http://www.codigotecnico.org/index.php?id=33

Hacer hincapié que este código es una norma prestacional y no prescriptiva como venían siendo las anteriores."
--------------------------
Gracias Estefanía por el reporte de errores, y especialmente al amigo que te hizo el reporte. Le puedes decir que no se corte en remitirme directamente cualquier error, modificación o sugerencia sobre los temas tratados, u otros que puedan ser de intrerés. Que siempre serán muy bienvenidos. Se han hecho las oportunas modificaciones en la entrada de referencia.

Otro enlace de interés.: http://www.ffii.nova.es/puntoinfomcyt/Formulario-Lseg01.asp

Bitácora de PSI.: Vida salvaje (la redundancia)

Seguridad y redundancia, dos términos íntimamente ligados. Al igual que la "hydra" de la fotografía, la redundancia a distintos niveles nos podrá proporcionar, entre otros, sistemas tolerantes a fallos, alta disponibilidad, computación distribuida y balanceo de carga. En este punto deberemos tener presente la organización "hardware" de nuestros sistemas que, en muchas ocasiones, pasará por la instalación de "clusters" y "blades" (los tipos de enlaces de ambos son autoexplicativos, y recuerda que en algunas ocasiones puede ser aconsejable "casarte" con alguna empresa y cubrirte la espalda con algún tipo de soporte). Tampoco debemos olvidarnos del mundo de la computación GRID. Además, la virtualización y paravirtualización de nuestros sistemas proporciona, entreo otras muchas ventajas, una gran flexibilidad, sin entrar en los posibles problemas de seguridad añadidos a este tipo de aproximaciones y a sus hypervisores.

Todo en la naturaleza utiliza la redundancia como mecanismo de protección-supervivencia. Muchas especies tienen docenas, cientos o incluso miles de crías. Como es lógico, este parámetro está relacionado con su índice de supervivencia. En resumen, se busca perpetuar la especie garantizando la supervivencia de un determinado número de individuos, al igual que nosotros buscamos garantizar la supervivencia de nuestros sistemas y servicios. Si tomamos un único individuo, la redundancia está presente en nuestro sistema de visión y auditivo, más que nada para poder disfrutar del estéreo de los sentidos, dos pulmones, dos riñones, ..., y un corazón (en este último caso más bien por un problema de consumo, de energía). Siempre hay elementos que saldría demasiado caro redundarlos.

La genética y la evolución siempre está presente en nuestros sistemas. La capacidad de adaptarnos a situaciones cambiantes es un cualidad muy deseable. Si estás interesado en estos temas te recomiendo alguno de los proyectos fin de carrera que propuse y dirigí cuando era joven, y que sobre los distintos subsistemas gestionados por nuestros sistemas operativos, se desarrolló todo un conjunto de algoritmos genéticos para proporcionar un sistema automático de ajustre de nuestros sistemas, facilitando su adaptación a distintos entornos, tanto "hard" como de aplicativo. Un ejemplar de cada uno de ellos está disponible en la biblioteca de la FI de la UDC. La monitorización y ajuste de nuestros sistemas es una tarea compleja. Por lo tanto, todo sistema automático que mejore el rendimientos de nuestos operativos, constituira un primer paso para hacer a nuestros sistemas operativos un poco más listos.

Si pensamos en nuestra infraestructura, encontramos redundancia a todos los niveles.

- Tal vez nuestras redes de comunicaciones constituyen el elemento más importante a la hora de pensar en redundancia. Si las redes fallan, todo falla. Debemos tener en cuenta tanto líneas redundantes como activos redundantes. Los caminos que nos unen son múltiples, variados y multitecnología. Hay bits que vuelan, otros navegan y, los que más me gustan a mí, hacen espeleología. Y recuerda, tal y como hemos visto en aventuras anteriores, que existen otros muchos mundos, otras muchas redes.: de suministro eléctrico, de alimentación ininterrumpida, de agua, de gases, de puesta a tierra, etc.

- CPDs redundantes o, como mínimo, la parte más importante, el almacenamiento. Un servidor se puede sustituir (es cuestión de €s), la pérdida total de los datos y de todo soporte disponible puede no serlo. ¿Qué hubiese pasado si nuestra empresa y todos sus sistemas hubiese estado en las torres gemelas o en la torre windsor? (bueno, sin contar con disponer de "backups" de todo en la caja innifuga de la windsor). Además, este nivel de redundancia nos permitirá jugar con distintos esquemas de alta disponibilidad y balanceo de carga, etc., sobre infraestructura en distintos edificios. Recuerda que muchas de estas tareas podrás delegarlas en equipamiento "hardware" especializada, como puedan ser los balanceadores de carga, aceleradores SSL, etc. Aunque en clase referencié algunos de estos dispositivos, no los incluyo aquí por no hacer publicidad. Si algún proveedor de este tipo de sistemas llega a esta entrada y está interesado en presentar alguno de sus "cacharros" a un grupo de unos 60 futuros profesionales, que no dude en contactar. Por favor, abstenerse comerciales.

Observación para los alumnos.: Es habitual encontrar comerciales que siempre tienen una respuesta afirmativa a cualquier cuestión técnica del tipo si se puede hacer tal o cual cosa que, a posteriori, se vuelve prácticamente inviable. Cuando te entrevistes con comerciales, procura documentarte bien sobre el tema a tratar y, de ser posible, ponle algún examen sobre cuestiones que tengas claras y sean poco viables para ver su grado de fiabilidad. Y recuerda que no encontrarás un buen comercial que antes no haya sido buen técnico. Esto mismo se puede aplicar a los directivos y gestores de personal. Vivimos en un mundo en el que con cierta frecuencia se trata de "vender la moto", aunque "menos mal que nos queda Portugal".

- Backups redundantes. Son demasiadas las veces que asistimos a situaciones en las que en el momento de necesitar un "backup", no está en las condiciones que debería, o con la política adecuada a nuestras necesidades. Una buena política de "backups" nos dejará dormir más tranquilos por la noche. Tampoco es aceptable entrar en un CPD y encontrar DLTs de "backup" zapateados por las mesas.

Sobre "backups", haciendo memoria de los tiempos en los que ejercía la segunda profesión más antigua del mundo, al inicio de los noventa utilizaba el tar sobre cintas de 150 Mb. Todo estaba planificado y organizado pero, la primera vez que necesité recuperar algo, mi dispositivo me recibió con un checksum error. Que hijo de puta, con perdón, pensé yo. En esas fechas descubrí que habría ciertas tareas que se debían hacer en single user, o buscar una utilidad un poco más evolucionada e inteligente que un simple tar. Pero bueno, con un poco de imaginación al final se pudo hacer la recuperación. Pasaron unos años y las unidades de cinta de 4mm. llegaron a poblar nuestras mesas (ellas nunca lo harían, no las dejes abandonados encima de la mesa). Ahora pensábamos en Gb, en lugar de Mb., y la compresión de la información entró en nuestras vidas. Era habitual encontrar "backups" sobre cpio, dump-restore, afio, etc. También empezamos a exportar disco en red y a hacer "backups" a disco, mucho más rápido. Finalmente, antes de dejar de ejercer esta gratificante profesión, se instaló un sistema de "backup" en red, un IBM server con el software de "backup" TSM, Tivoli para los amigos, con un primer nivel de "backup" a disco, en el que predominaba como mecanismo de seguridad el RAID5, y un segundo nivel de transferencia a un dispositivo de LTOs. Sin duda alguna las posibilidades de planificación de "backups" en este tipo de sistemas permiten una flexibilidad más que suficiente para atender las peculiaridades de todo tipo de entornos, sistemas y usuarios.

- No quiero dejar fuera de esta sección otro elemento importante a redundar, al menos parcialmente, se trata del personal. Es habitual encontrarnos profesionales que utilizan todo tipo de estrategias para garantizar, muchas veces en un proceso oscurantista, que todo está bajo su único control. No es un delito, pero toda organización deberá tratar de redundar, en la medida de lo posible, total o parcialmente según sea el entorno de trabajo, las atribuciones más críticas del personal técnico. Como decía y dice Rosendo, "esto es la fauna, chaval". Pero también puedes encontrarte el típico centro con buenos profesionales, que planifican todo el trabajo, las migraciones, etc., etc. En estos casos los servicios proporcionados y el trabajo desarrollado pueden llegar a pasar desapercibido para los usuarios y, o, directivos. En algunas situaciones se puede llegar a pensar que sobra personal o que parte del mismo se puede derivar a otras tareas. En el lado opuesto esta el entorno de trabajo que no planifica o hace mal los desarrollos. Se puede llegar a dar la situación que cada cierto tiempo el usuario se percata de problemas en el servicio, así como los directivos, y de la gran labor que desarrolla ese personal técnico y la enorme necesidad de contratar nuevo personal para que todo funcione bien. En estos casos siempre suele aparecer el "técnico" salvador que, después de generar grandes problemas, los soluciona para aplauso de todos los que asisten al circo. Obviamente, contratar nuevo personal no suele solucionar el problema. Pero bueno, siempre queda la opción de coger a los mejores técnicos y aplicar la redundancia por medio de la clonación. Esto último no es posible, pero identificar el trabajo bien hecho debe ser una de las principales tareas de cualquier directivo. Obviamente, será difícil, por no decir imposible, que un directivo pueda llegar a desarrollar bien su trabajo, si antes no ha sido un buen técnico, o al menos aceptable. Como consejo, no tengas prisa por llegar a la cima de la montaña, disfruta de la ascensión. Y recuerda que la cima no es el paraíso.

Finalizamos la clase con un clásico de la redundancia en almacenamiento, los sisetmas RAID (Redundant Array of Inexpensive Disks). En este punto se incluyen conceptos como "hot swap", cabinas de disco, SCSI (Small Computer System Interface), SATA, "Fibre Channel", SAN (Storage Area Networks), "fabric director", etc.

Se analizan los niveles RAID básicos.:

- Lineal (muy bonito en la teoría, pero no sirve para nada)

- 0 "stipping" (utiliza n discos con almacenamiento en paralelo sobre los mismos). Un fichero se almacena en varios discos duros. Este nivel busca un incremento en el rendimiento de la I-O a disco, sin aportar redundancia-seguridad en el almacenamiento. Habitual encontrarlo en sistemas de edición de vídeo (el "rendering" suele comer todo rendimiento a disco que le podamos proporcionar), cálculo científico intensivo (modelos climáticos, biología molecular, etc.) y, en general, en todo entorno que mueva grandes cantidades de datos con nuestros discos. A nivel operativo, señalar que podemos hacer RAIDs de particiones o particiones de RAIDs. Es habitual que, con el tiempo, se tengan que adquirir nuevos discos duros y, por lo tanto, convivan distintos tipos de discos. Una buena organización mejorará los rendimientos o, al menos, no los empeorará. ¿qué pasaría si en un RAID 0 o 1 algunos discos duros fuesen más lentos que otros?

- 1 (mirror). En este nivel existe una redundancia total del almacenamiento, garantizando la disponibilidad del sistema ante casques de dispositivos. Obviamente, todo tiene un coste, y este caso requerirá una doble inversión. Recuerda que si únicamente dispones de una controladora de discos, podrás estar protegido ante la "muerte" de discos, pero no de controladora. Redundar las controladoras y organizar los discos adecuadamente te proporcionará otro nivel de seguridad.

En este punto, antes de continuar con los RAID, se analiza el proceso de "bautizo" de un disco duro. Un disco duro no se puede montar según te llega de fábrica, hay que bautizarlo (particionarlo y generar el sistema de ficheros). Aunque los discos duros virtuales de nuestro laboratorio no se puedan tocar, al ser ficheros, requieren seguir el mismo proceso. No puedo tratar de montar un disco duro que no ha sido particionado, ni generado su sistema de ficheros. El fdisk y el mkfs te podrán solucionar dicha tarea. El fichero /etc/fstab será el encargado de definir la información de montado. En clase se analiza el formato del /etc/fstab y las opciones que podemos encontrarnos. No incluyo en esta entrada nada al respecto, al estar ampliamente publicado en diversas fuentes. También analizamos el conjunto de ficheros y directorios que nos podemos encontrar en el, como dice la literatura, "pseudo" sistema de ficheros /proc.

Concluimos la clase con una cuestión, ¿qué sistemas de ficheros utilizaremos?. La respuesta no es cualquiera, o el reiserfs o ext3 que es el que suelo encontrarme. Si dentro del comando fdisk selecionas la opción l verás varias decenas de sistemas de ficheros distintos. Entonces, para que tantos?. Pues bien, los sistemas de ficheros son como el vino, los hay buenos y malos, unos aconsejables para ciertas comidas y otros para otras. A nadie se le ocurre tratar de meter un fichero de 4 GB en un disco FAT. Por lo tanto, deberemos tener en cuenta factores como los discos duros y buses disponibles, tamaño de los ficheros y directorios, números de lecturas y escrituras, patrón de los accesos a disco y carga de trabajo, algoritmos o planificadores disponibles, gestión de bloqueos, estrategias de reconstrucción ante "casques", etc. Dejamos el tema aquí exponiendo dos posibles configuraciones de un mismo servicio, el de correo electrónico que, según utilicemos "mbox format" o "maildir format" las implicaciones en cuanto al sistema de ficheros serán radicalmente opuestas.

Para terminar, hablando de rendimimiento y seguridad en el almacenamiento, un curioso video de rendimiento con SSDs (fuente Tomás, gracias). Además, no debemos olvidarnos que el cifrado de los sistemas de ficheros tienen su implicación en el rendimiento.

next gen discs

De los muchos emails que me llegan con noticias de nuestro mundillo, algunas de las cuales están relacionadas con los temas tratados en clase, son varias las que merecen nuestra atención, aunque no me queda otra que hacer una selección. Adjunto contenido email remitido por F.A.R.M.
-------------
Encontré un artículo que es relevante de acuerdo al tema que diste en clases pasadas sobre almacenamiento y respaldo de información. Unos investigadores han logrado crear una especie de disco compacto capaz de almacenar el equivalente a 2,000 DVD’s utilizando una tecnología de 5 dimensiones (3 espaciales y dos extras: espectral y polaridad). Esperan que una aplicación comercial llegue en 5-10 años, y podría marcar una nueva manera de guardar respaldos de nuestra información. Enlace de la noticia aquí.
----------------
Sobre el tema, los interesados en otros trabajos relacionados con dispositivos de almacenamiento de alta capacidad, señalar por ejemplo los diferentes desarrollos en sistemas holográficos. Para más información Holography System Development Forum (HSDF).

Pdt.: Sin duda alguna los futuros y cada vez más cercanos procesadores de varias decenas de núcleos requerirán de nuevos planteamientos jerárquicos de almacenamiento, empezando por las caches y terminando por los discos.

What's the Next Web Stack?

Revisando el documento "Sun cloud-computing technology scales your infrastructure to take advantage of new business opportunities" de Sun microsystems, entre las aportaciones identificadas, incluyo en esta entrada la titulada "What's the Next Web Stack?. Sin duda alguna, todo estudiante en tecnologías debe moverse en la dirección que marca el mercado que, a fin de cuestas, es el que define las oportunidades laborales. En resumen, en dicho documento figura la siguiente "evolución", o más bien "mutación".:

Año estelar 1998.: Netscape - BEA/SAP - Oracle
Año estelar 2008.: Apache - PHP/Perl/Python - MySQL
Año estelar ????.: lighttpd - Hadoop - MogileFS

Señalar que la nueva tripleta está pensada para computación y almacenamiento distribuido que, en muchos casos, incluye virtualización a distintos niveles. En los últimos años se está poniendo de moda la comida "light" que, por cierto, tiene muchas ventajas, pero también alguna desventaja. Pensando en el tema que estamos dando en clase esta semana destacar MogileFS, y lo que parece ser aporta una gran cantidad de ventajas. Lo pondré en la cola de las muchas cosas que quiero probar, que por cierto, empieza a ser demasiado grande.

Sobre "cloud computing" recomiendo una pequeña visita a las soluciones y tecnologías aportadas por Enomaly, Elastra (muy interesante el documento Elastic Computing y sus aportaciones sobre "next generation of IT infraestructure?"), Right Scale, 3Tera, Joyent, Mosso, Sun Microsystems & Amazon web services. En esta relación encontrarás diversas soluciones, herramientas y tecnologías de "cloud computing", alguna de ellas disponible en versión "free" para descargar, así como servicios de "cloud hosting".

Ser bueno, y bajaros de la nube, o tal vez subiros,

Observaciones.: Las cuestiones tratadas en esta entrada se salen de la temática-temario de la asignatura de PSI. De todas formas, creo que tiene la suficiente importancia como para dedicarle unos minutos. Sin duda alguna, es importante saber "a dondeeee vaaaamos".

Financial Cryptography and Data Security '10 (January 25-28, 2010 - Tenerife. ES)

Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration, and debate regarding information assurance, with a specific focus on commercial contexts. The conference covers all aspects of securing transactions and systems.

Info.: http://fc10.ifca.ai/

Bitácora de PSI.: Sector inmobiliario TIC

Todo "profesional" tiene un pasado. Las decisiones tomadas son las que definirán las características presentes de un profesional, así como la capacidad para adaptarse a un entorno muy cambiante que requiere en todo momento tomar decisiones, que podrán ser más o menos acertadas. Todo requiere tiempo, y lo que nace mal, muere peor. Como dice el refrán "el que siembra espinas que no espere cosechar flores", aunque yo tengo uno propio "el que plante conocimientos, no sé lo que recogerá, pero al menos tendrá bien amueblada la cabeza".

Entrando en materia, hoy hemos seguido "peleando" con las prácticas de laboratorio. Como es típico de nuestra profesión, nada es lo que parece, y tenemos que adaptarnos a los imprevistos.

En nuestra clase de teoría hemos seguido hablando de UPSs. Se ha planteado un ejemplo de equipamiento, analizado su consumo, planificado el crecimiento a corto-medio plazo y definido las características de una SAI para dicho caso. Los sistemas de UPS deben ser gestionados y monitorizados adecuadamente, tanto en sistemas centralizados como distribuidos. Distinguimos varios sistemas de gestión.:

a) nada, que el usuario llame por teléfono cuando las máquinas se vengan abajo. Sin duda alguna el elegido por un buen profesional -:)
b) UPSs con interface serie y software de gestión. Aceptable en la pequeña empresa.
c) UPS con conexión a red IP, y normalmente con SNMP para integrar en el sistema de gestión. Recomendable para empresas grandes. En este caso no te olvides de conectar los activos de red a la UPS -:) y protegerlas adecuadamente.

Como ejemplo de sistema para monitorizar y gestionar una UPS y los equipos conectados a la misma, se dispone de varias herramientas, como NUT (Network UPS Tools).

También hemos visto las Normas de Estabilidad Eléctrica, en la forma del correspondiente Reglamento Electrotécnico de Baja Tensión (RBT), así como la directiva y la orden CTE de Compatibilidad Electromagnética. En pocas palabras y de forma muy resumida, no se puede mezclar el vino con el agua. No puedo meter el cableado de fibra por los huecos del ascensor. No puedo meter líneas de datos junto a cableado de alta tensión, etc., etc. Todo esto incluye distancias entre los elementos, aislantes, etc.

Una parte importante de la clase la hemos dedicado a una red que suele pasar desapercibida en nuestros edificios de TIC respecto a las de datos, etc. Es la Red de Toma de Tierra. En primer lugar se presentan algunas normas de referencia, como la EN50310:2009 o la J-STD-607-A "the purpose of this standard is to enable the planning, design, and installation of telecommunications grounding and bonding systems within a building with or without prior knowledge of the telecommunications systems that will subsequently be installed. This standard also provides recommendations for grounding and bonding of customer owned towers and antennas. This telecommunications grounding and bonding infrastructure supports a multivendor, multiproduct environment as well as various system installation practices". Se analizan los distintos elementos que constituyen una Red Radial de Tierra y sus características básicas.


El acondicionamiento térmico de las instalaciones estár recogido dentro del artículo 15, del Código Técnico de la Edificación (CTE), sobre exigencias básicas de aHorro de Energía (HE), respecto a la limitación de la demanda energética, rendimiento de las instalaciones térmicas, etc. A nuestros "cacharros" les suele gustar vivir en climas más bien fresquitos -:). Nuestros "cacharros" consumen mucha energía, por lo que el desarrollo de eco-CPDs deberá empezarse a considerar como un parámetro importante en su diseño y desarrollo. Hasta la fecha únicamente tengo constancia de desarrollos de ecoCPDs de Sun Microsystems.

También hemos hablado de pirómanos. En cuanto a la seguridad ante incendios, el CTE dispone el Documento Básico (DB), sobre exigencias básicas de Seguridad en caso de Incendio (SI), respecto a la propagación interior y exterior, evacuación, instalaciones de protección contra incendios, intervención de bomberos y resistencia estructural al incendio (nuestro agradecimiento al amigo de Estefanía por las correcciones, no hay como disfrutar de un domingo con la lectura de un BOE -:))

Enlace de interés.: http://www.ffii.nova.es/puntoinfomcyt/Formulario-Lseg01.asp

Este punto me ha permitido introducir la próxima temática, el uso de redundancia como mecanismo de protección. En la actualidad es necesario el contemplar en nuestros CPDs la posibilidad de desastres, como los incendios, atentados, etc. (obviamente según el tipo y tamaño de la empresa). Estos temas se tratarán más adelante, en el contexto de la llamada Alta Disponibilidad y Sistemas Tolerantes a Fallos. En estos casos, la única solución pasa por la redundancia, que puede ser a distintos niveles. Como ejemplos, la torre Windsor de Madrid, o las Torres Gemelas de Nueva York.

En resumen, nuestros edificios TIC están compuestos de un gran número de redes que, según los casos, pueden compartir infraestructura. Entre ellas destacar, la red de datos, de vigilancia y control de acceso, de alarma, de tensión eléctrica, de tomas a tierra, de almacenamiento (SAN), de "backup", redes de aguas, de aguas sucias, de gases, de ascensores, de acondicionamiento térmico, de detección de incendios, de control de energía y del aire, de espionaje, etc., etc. Como puedes comprobar, son muchas las redes además de la de datos, por lo que siempre tendremos que tener en mente todas ellas. Aquí podríamos hablar de edificios inteligentes, pero creo que se sale de la temática de la asignatura, unido a que esa rara acepción, no creo posible encontrarla en un edificio.