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.
