Posts Tagged ‘arquitectura’

h1

Guia a la arquitectura empresarial y el caso contra Extreme Programming

02/11/2009

Wizbook [Icon By Buuf]

 Libros: Software Engineering.

Incluso la perfecta verificación de un programa sólo puede establecer que cumple con su especificación. […] Mucha de la esencia de construir un programa es de hecho, la depuración de la especificación.

¿Qué es una arquitectura empresarial y qué elementos la componen? Esa es la pregunta que responde el libro A Practical Guide to Enterprise Architecture (Una Guía Práctica a la Arquitectura Empresarial), de James McGovern, et al. Llevándonos de la mano por todos los conceptos de las arquitecturas empresariales – desde la definición de arquitectura y qué se supone que debe hacer un arquitecto, hasta conceptos más avanzados como el Extreme Programming, un SOA o cómo podemos medir la usabilidad de un sistema – este libro posee información que arquitectos, líderes de proyecto, CIOs y CTOs conocen íntimamente o al menos con la que deberían estar familiarizados.

Tal vez este libro no tenga nada de novedoso para los que ya tenemos un buen rato peleándonos con proyectos de software y sistemas, pero para todo aquél que quiera pasar del desarrollo a la definición de arquitecturas, este documento es una fuente indispensable de conocimiento que difícilmente encontraremos consolidada en un sólo libro.

A grandes rasgos, el texto funciona como un repositorio de información de referencia para aquellos conceptos de TI que están enfocados en proyectos de software, incluyendo los siguientes temas:

• 

Qué es una arquitectura empresarial.

• 

Qué elementos componen dicha entidad (procesos, modelos, metodologías).

• 

Qué tipos de arquitecturas existen (monolítica, cliente-servidor, orientada a servicios).

• 

Qué es una metodología; qué metodologías existen (CMM, RUP, XP). Dejando algunos capítulos completos para definir cada una de éstas, su razón de ser y sus principales artefactos.

• 

Cómo modelar una arquitectura (básicamente UML y sus diagramas).

• 

Cómo se define la usabilidad de un sistema.

• 

Cómo se define una arquitectura de datos.

• 

Aspectos organizacionales de una arquitectura empresarial (básicamente, tips para ser un mejor arquitecto).

Dichos conceptos pueden diagramarse en el siguiente esquema, propuesto por los autores:

El pentágono McGovern/Stevens de agilidad arquitectónica.
(fuente: McGovern, et al. A Practical Guide to Enterprise Architecture, 2003)

Así entonces, recomiendo este libro para aquellos que quieran dar un repaso a todos los conceptos que incluye, así como todo aquél curioso que desee echarse un clavado en el mundo de las arquitecturas de software.

Reflexionando

Sin embargo, leyendo el libro me saltaron un par de ideas: aunque el libro pone mucho énfasis en metodologías ágiles de desarrollo de software y aplicaciones web como la neta del planeta, es bueno tomar en cuenta que ni todos los proyectos son web ni las metodologías ágiles son siempre lo mejor. Por experiencia – y esto no sólo lo he comprobado yo, sino algunos de mis compañeros y colegas también – las metodologías ágiles son excepcionalmente buenas para proyectos con pocas personas en el equipo de trabajo, y las metodologías que requieren muchos artefactos (por ejemplo, RUP) tienen mayor cabida en proyectos con muchas personas involucradas.

¿Cómo es eso? El desarrollo de software es un proceso que depende enormemente de la creatividad (de hecho, es el tema central de trabajos como Peopleware: Productive Projects and Teams); las metodologías ágiles explotan esta creatividad en beneficio del proyecto proporcionando a los desarrolladores el empowerment necesario para participar en todo el ciclo de desarrollo: la misma persona levanta el requerimiento con el cliente, arma el demo y va desarrollando la funcionalidad y casos de prueba de acuerdo a lo que ha platicado con el cliente. Sin embargo, esto depende de tres cosas: 1) que las actividades de un desarrollador no impacten las de otro, 2) que el índice de rotación de un proyecto tienda a cero y 3) que el cliente no quiera chamaquearse al desarrollador. Estos supuestos se logran en proyectos pequeños o donde el staff asignado ya tiene relativa experiencia.

Por el contrario, en proyectos grandes con muchas personas involucradas, el tema principal es la coordinación de un ejército de desarrolladores – de los cuales muchos seguramente son de nivel junior – y la extensa y a veces ineludible dependencia entre el trabajo de unos y otros. Si un desarrollador se va, todo puede verse comprometido como un juego de domino. Por ello, al seguir al pie de la letra una metodología intensiva en documentos como RUP, estamos desaprovechando la creatividad de nuestros desarrolladores, pero estamos asegurando que lo que se está negociando con el cliente es lo que se entregará.

Conclusiones y un par de tips

Siendo así las cosas, una buena estrategia al levantar los requerimientos de un proyecto es definir una serie de artefactos de alto nivel: como mínimo, una arquitectura física, una lógica y las narrativas de los casos de uso; y dependiendo del alcance y complejidad del proyecto, podemos seleccionar una metodología específica. Otra estrategia – la que mejor me ha funcionado – es utilizar una metodología mixta, usando artefactos tales como matrices de requerimientos vs. productos y llevando un estricto control de entregables, pero usando constantemente conceptos ágiles como desarrollo iterativo, pruebas de concepto y prototipos que deben ser verificados por el cliente.

h1

Una arquitectura escalable

12/30/2008

Tips & Tricks [Icon By Buuf]

 Tips & Tricks.

El logro más impresionante de la industria del software es la continua cancelación de los constantes logros alcanzados por la industria del hardware.

Fé de Ratas

Las velocidades de un SATA II y un SATA son de 384 y 192 MB/s respectivamente. Esto porque en la BIOS se leía que la velocidad de transacción de los discos es de 3 Gb/s y 1.5 Gb/s y no me fijé que se refería a gigabits por segundo, no gigabytes.

Esta navidad me compré una Ultra 24 Workstation. Aunque mi señora en un principio me reclamó con un ¿y para qué quieres esa máquina?, la convencí de adquirir el equipo al comentarle que con las partes que sobrarían de la computadora que tengo actualmente, le haría un upgrade a la suya sin gastar de más.

En principio, la susodicha estación de trabajo tiene algunas características que la hacen más que una simple PC, aunque menos poderosa que un servidor de tamaño mediano:

Característica

Propiedades

Procesador

1 x 3.00 GHz Intel Core2 Quad Q9650 (Penryn)

Tarjeta de Video

NVIDIA Quadro FX 5600 graphics accelerator card

Memoria

2 x ECC unbuffered DDR2-667 DIMMs @ 1 GB

Disco Duro

1 SATA II HDD 250GB (7,200 rpm)

Propiedades de una Ultra 24 "Estándar"

Y aunque muchos dirán ¿Y? ¡Eso puedo adquirirlo en la Plaza de la Electrónica o en el SAM’s Club!, la gran ventaja de la placa base y arquitectura es su escalabilidad: Se le pueden añadir DIMMS de 2 GB hasta alcanzar 8 GB de RAM, 4 discos SATA/SATA II de hasta 750 GB (para un total de 3 TB) y en un futuro no muy lejano se podrá intercambiar el procesador Core2 Quad (4 procesadores en uno) por un V8 (8 procesadores en uno). Esto significa que durante los próximos 3 a 5 años sólo bastará con adquirir nuevos componentes para estar al día, cosa que difícilmente se puede encontrar con otras plataformas.

Interior de una Ultra 24. (Fuente: sun.com) (Click en imagen para ver en mayor tamaño)

Bara, bara

Obviamente, no nado en dinero y para ahorrarme una buena lana, sólo adquirí el CPU. De todas formas, ya tenía los periféricos y algunos componentes de hardware adicionales incluyendo un par de DIMMS de memoria, un par de drives SATA y por supuesto, el bendito quemador de DVDs. Precio al público general: unos US$2,000 (antes de la devaluación de octubre). Precio con descuento por sólo adquirir la CPU: unos US$1,150.

Entonces, ¿cuál es la ventaja? Una HP Pavilion M9350 (Core2 Quad a 800 MHz, 4 GB RAM, HDD @ 500 GB, Windows Vista Home Premium) anda en unos MX$22,000 en el SAM’s Club (unos US$1,700), incluyendo su monitor de 20 pulgadas, mouse y teclado. Sin embargo, por un precio más o menos equivalente es posible adquirir al menos la CPU de un equipo cuya arquitectura posee una escalabilidad mucho mayor.

Los "detallitos"

Ahhh… pero aunque esta máquina tiene lo suyo, posee un par de detalles que aunque no son malos, si implican un costo adicional o un par de días de talacha:

• La máquina soporta Windows, Solaris y Linux en sus modalidades de 32 y 64 bits y por defecto trae Solaris 10. Esto significa que 1) Tendremos que adquirir una versión de Windows con su consecuente sobreprecio o 2) Deberemos buscar la manera de utilizar los sistemas operativos abiertos y las aplicaciones que los soportan.

• Aunque tal vez para muchos esto ya es intramuscular, resulta que los puertos PS/2 de ratón y teclado ya dejaron de existir, por lo que la workstation debe usar un mouse y teclado compatibles con el puerto USB 2.0 o conectarse a través del adaptador correspondiente.

• De igual manera, las tarjetas de video que utiliza la estación de trabajo poseen una interfaz DVI que algunos monitores no soportan, pues éstos utilizan la interfaz VGA de 11 pines que todos conocemos.

• Finalmente – y esto me costó un par de noches de desvelo – resulta que Windows XP no tiene soporte nativo para discos duros SATA en modo AHCI (ver recuadro).

Windows XP y el soporte a SATA sobre AHCI

Cualquier versión de Windows previa a Vista carece de soporte a discos duros SATA/SATA II en la modalidad de AHCI.

Esto es malo, pues al cambiar los discos de la máquina anterior a la nueva uno supone que marcará errores por drivers y sólo habrá que entrar en "Modo a prueba de fallos", borrar los drivers viejos e instalar los nuevos. Por desgracia, esto no ocurre así y ya sea durante el boot desde el disco duro o cuando utilizamos el CD de instalación de Windows XP nos saldrá la temida Pantalla Azul, marcando en resumidas cuentas el siguiente error:

***STOP: 0x0000007B (0xF78D2524,0xC0000034,0x00000000,0x00000000)

Y aunque en el sitio de soporte de Microsoft se indica que puede ser problema del disco o corrupción de la FAT por virus y en algunos foros manejan problemas como daño de alguno de los DIMMS de memoria o del CPU, la verdadera causa del problema es que Windows XP en cualquiera de sus modalidades no soporta la interfaz SATA (y mucho menos la SATA II) sobre AHCI, siendo todos sus drivers de tipo IDE.

¿Cómo solucionar el problema? Existen tres alternativas, todas ellas con sus pros y sus contras:

1. Desde la BIOS, habilitar el modo de compatibilidad con discos IDE. Aquellas motherboards con soporte a discos "legados" tienen en algún punto de la configuración de la BIOS el soporte con compatibilidad para este tipo de discos. Es necesario cambiar esta configuración:

   • Durante el boot tecleamos F2.
   • Ingresamos en la sección "Drives" o su equivalente.
   • Finalmente, en el modo de operación se cambia de "RAID Auto/AHCI" a "RAID Auto/ATA" o "RAID Auto/IDE".

El beneficio es la facilidad y rapidez para resolver el problema, pero dicha configuración elimina los beneficios del modo AHCI y pasamos de un máximo de acceso y escritura de 384 MB/s (SATA II) o 192 MB/s (SATA), a tan sólo unos 133 MB/s (velocidad estándar de un IDE).

2. Adición de controladores durante la instalación de Windows. Esto implica descargar los controladores SATA para AHCI e incluirlos durante la instalación:

   • Durante el boot del disco de instalación de Windows presionamos F6 para "instalar otros controladores SATA o SCSI"
   • Proporcionamos los drivers solicitados a través de un disquete en la unidad A:
   • Instalamos Windows de manera normal.

Sin embargo… desde hace más de 3 años muchos nos hemos deshecho de la unidad de disquetes y en las nuevas máquinas, no existe manera de conectar dispositivos de este tipo, a menos que compremos una unidad de disquete externa compatible con USB, pero eso es tirar dinero a la basura. Por ello, existe un método alternativo:

3. Adición de los controladores al disco de instalación de Windows. Aunque significa bastante talacha de por medio, podremos contar con un nuevo bundle de instalación que incluya los drivers de este tipo de discos (ver aquí el procedimiento en detalle):

   • Extraer los contenidos del CD de instalación de Windows en un disco duro.
   • Agregar los drivers así como modificar algunos archivos de configuración de la instalación.
   • Quemado del nuevo bundle en un CD.

Con esta instalación "mejorada" podremos instalar el Windows en discos de tipo SATA AHCI sin necesidad de teclear F6 y mucho menos de adquirir una unidad de disquetes, ahorrándonos una lana en el camino.

Algunas "pruebitas de concepto"

Bueno, ¿y qué tal se comporta el "animalito"? hay una manera sencilla de comprobarlo: siendo un fan de los juegos de first person shooter como Doom 3 o el aclamado Crysis, haciendo la instalación de estas sanas formas de entretenimiento y revisando su desempeño en la máquina, me quedé boquiabierto, pues dejando los máximos de resolución y efectos el juego corre como si estuviéramos en una sala de "maquinitas".

Sin embargo esto hay que tomarlo con un grano de sal, pues por ahí me he topado con reseñas (ver aquí o aquí) donde comentan que algunos de estos juegos no están bien adaptados para trabajar con Quads y no se nota la diferencia contra un Dual Core. También puede deberse a que la tarjeta de video es bastante más avanzada que una tarjeta de uso común; lo mejor es revisar a detalle alguno de los múltiples benchmarks que normalmente se han publicado para comprobar el desempeño total (cpu + tarjeta de video + velocidad de discos) de esta combinación de hardware.

Conclusiones

Tal vez adquirir una workstation pueda sonar caro, pero si tomamos en cuenta que es una inversión que nos permitirá ahorrar al mediano y largo plazo (cada año y medio hay que estar renovando equipos, debido a la mentada Ley de Moore). Esto es especialmente importante para aquellos que buscan lo mejor en hardware para sus aplicaciones "para hombrecitos" o para los videojuegos de moda, porque en vez de gastar casi MX$8,000 (unos US$615) en una nueva tarjeta de video, por un poco más podemos adquirir un equipo que tiene garantía, es escalable y nos fuerza a economizar y no estar generando basura al deshacernos de equipos completos que todavía tienen partes muy buenas. Adicionalmente, las workstations tienen un buen modelo de ventas: el famoso try & buy donde uno adquiere el equipo y si ya no le gusta, lo puede regresar sin compromisos. Lo recomiendo ampliamente.

h1

Head First: Design Patterns

10/07/2008

Wizbook [Icon By Buuf]  Libros: Software Engineering.

Ok, ¿Qué es lo único con lo que siempre podemos contar en el desarrollo de software?

Sin importar dónde trabajes, qué estés construyendo, o en qué lenguaje estés programando, ¿cuál es la única verdadera constante que estará contigo todo el tiempo?

E L   C A M B I O

Sin importar qué tan bien diseñes una aplicación, eventualmente ésta debe crecer y cambiar o morirá.

— Elisabeth Freeman, et al. Head First: Design Patterns, O’Reilly Media, 2004.

Recientemente terminé de leer el libro Head First: Design Patterns, de Eric y Elisabeth Freeman, Kathy Sierra y Bert Bates. Aunque ya he manejado los patrones de diseño del Gang of Four desde hace rato, es la primera vez que veo una manera de presentarlos tan original: ejemplos basados en aplicaciones divertidas y fáciles de recordar (como una de patitos voladores al estilo del memorable El-Fish o esos salvapantallas que parecen un acuario) o ejercicios escritos como crucigramas, verdadero/falso y de adición de código que ayudan al lector a reafirmar los conceptos aprendidos. Sin embargo, lo más novedoso es la presentación tan visual de la información:

El origen de los patrones de diseño: partiendo de la programación orientada a objetos, surgen ciertas buenas prácticas o principios y de éstos nacen los patrones de diseño.

[Click en imagen para ver a mayor escala]

Por cierto, que para aquellos no familiarizados con estos conceptos, el uso de patrones de diseño tiene mucho que ver con la implementación y uso de interfaces y clases abstractas.

A lo largo del libro nos presentan los patrones de diseño más comúnmente utilizados, como el Singleton (cuyo objetivo es tener una sola instancia de una clase por JVM) o la Fábrica Abstracta o Abstract Factory (cuya misión es la creación de familias de objetos sin conocer su clase concreta). Lo interesante de esto es que utilizan conceptos muy familiares para describir la problemática a partir de la cual surge un patrón de diseño, y eso es justamente lo que hace de este título una lectura indispensable para cualquier sistemólogo que se respete. Por ejemplo, con respecto al patrón Decorator es mucho más fácil seguir la analogía de que tenemos tipos de café a los que les vamos agregando características en su constructor…


Beverage beverage = new Espresso();
System.out.println(beverage.getDescription() + ": $" + beverage.getCost());

Beverage beverage2 = new DarkRoast();
beverage2 = new Mocha(beverage2);
beverage2 = new Whip(beverage2);
System.out.println(beverage2.getDescription() + ": $" + beverage2.getCost());


%java StarbuzzCoffe
Espresso: $1.99
Dark Roast Coffee, Mocha, Whip: $2.33
%

… que tener que explicar que Decorator sirve para añadir funcionalidad a un objeto de manera dinámica utilizando algo más abstracto como los streams de datos de Java:


InputStream inputStream = new FileInputStream("/tmp/archivos/archivo.txt");
inputStream = new BufferedInputStream(inputStream, data.length);

Más tarde, una vez descritos los patrones principales, el libro realiza un wrap-up de los temas vistos al integrar lo que ellos llaman patrones de patrones: estrategias de implementación que dan la pauta a conceptos más complejos como el MVC (Model-View-Control). Aunque no van más allá, vale la pena mencionar que esos "patrones de patrones" son conocidos como los Core J2EE Patterns: patrones de diseño de aplicaciones empresariales que salen del dominio de Java puro y tienen que ver más con tecnologías J2EE/JEE, como el Business Delegate o el Service Locator.

Finalmente, sólo tengo una queja con respecto al libro: sólo detallan los 14 patrones más utilizados en la industria, despachándose en algo así como 2 páginas por patrón aquellos menos comunes y que son el pan nuestro de cada día cuando de exámenes de certificación se trata: los términos Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Memento, Prototype y Visit son dejados como "patrones de sobra". Eso por supuesto, significa que es necesario estudiarlos por separado y buscar ejemplos que en la mayoría de los casos son muy abstractos, viejos o difíciles de recordar.

Conclusiones

Si necesitamos aprender los patrones de diseño más importantes del Gang of Four, o darles una repasada para no oxidarnos, es una buena idea adquirir este libro que presenta de forma interesante algunos conceptos que podrían parecer tediosos, aburridos o demasiado complejos para aprender a la primera. Por otro lado, si buscamos algo más serio y no estamos interesados en aprender estos patrones en Java, o simplemente no nos gustan los "monitos" con diálogos, podemos ir directo a la fuente: Design Patterns: Elements of Reusable Object-oriented Software. Sin embargo, aquél libro tiene dos defectos: es extraordinariamente abstracto y casi todos sus ejemplos están escritos en C/C++

h1

Alta Disponibilidad: Qué es y Cómo se logra

08/19/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En el ambiente IT actual, dominado por el paradigma cliente-servidor y las arquitecturas de N-capas, todos los estudios de TCO (Total Cost of Ownership – Costo Total de Propiedad) han mostrado que el TCO de servidores interconectados y estaciones de trabajo es muy alto en comparación con una mainframe centralizada y los thin clients de antaño, siendo la razón principal la baja atención de requerimientos post-liberación, especialmente la disponibilidad.

Durante estas últimas semanas el equipo de trabajo al que pertenezco ha tenido la tarea de diseñar soluciones de alta disponibilidad para nuestros clientes. Esto porque a últimas fechas se han dado cuenta que el tuning & performance de sus servidores y aplicaciones no hace mucho sentido si 1) el diseño de su arquitectura está hecho con los pies y 2) no tienen un plan coherente de administración de sus sistemas una vez que han sido liberados a producción. Sin hacer muy largo el cuento, el detonante de esta nueva asignación es que durante la actualización de firmware de un servidor de base de datos, se volaron la configuración de mirror[1] del mismo, chocolateando la información y perdiendo un 10% de los datos productivos, que vale la pena mencionar, no estaban respaldados. Oooops…

Pues bien, eso aunado al hecho de que terminé de leer el librito High Availability: Design, Techniques, and Processes (Alta Disponibilidad: Diseño, Técnicas y Procesos) de Michael Hawkings y Floyd Piedad, me ha permitido tener una mejor comprensión de este concepto. Dicho libro está algo viejón para los estándares de la industria pues fue publicado en el 2000, pero al menos los conceptos básicos si los tiene y son explicados de forma consistente a lo largo del libro. En resumen, nos cuenta que para alcanzar la alta disponibilidad en nuestros deployments debemos tener lo que el cliente antes mencionado no ha logrado implementar: un buen diseño de arquitectura y un plan de gestión de la solución productiva.

A continuación incluyo un pequeño resumen del libro, que llegué a mostrar a nuestros clientes para crearles conciencia de la necesidad de este tipo de tareas, lo que afortunadamente dio en el clavo.

¿Qué es la disponibilidad?

La disponibilidad es una de las características de las arquitecturas empresariales que mide el grado con el que los recursos del sistema están disponibles para su uso por el usuario final a lo largo de un tiempo dado. Ésta no sólo se relaciona con la prevención de caídas del sistema (también llamadas tiempos fuera de línea, downtime u offline), sino incluso con la percepción de "caída" desde el punto de vista del usuario: cualquier circunstancia que nos impida trabajar productivamente con el sistema – desde tiempos de respuesta prolongados, escasa asistencia técnica o falta de estaciones de trabajo disponibles – es considerada como un factor de baja disponibilidad.

¿Cómo medimos la disponibilidad?

De primera instancia, todo sistema debe tener establecido un Acuerdo de Nivel de Servicio (Service Level Agreement – SLA) que defina cuánto tiempo y en qué horarios debe estar en línea. En el caso de aplicaciones de baja criticidad, dicho SLA puede ser de 8×5 horas a la semana excluyendo días festivos; para sistemas con mayor criticidad como una red de cajeros automáticos se tienen niveles de servicio que alcanzan las 24 horas al día, los 365 días del año. Así entonces, suponiendo un sistema con un SLA de 24×365 podríamos calcular su disponibilidad de la siguiente manera:

Disponibilidad = ((A – B)/A) x 100 por ciento)

Donde:

A = Horas comprometidas de disponibilidad: 24 x 365 = 8,760 Horas/año.

B = Número de horas fuera de línea (Horas de "caída del sistema" durante el tiempo de disponibilidad comprometido). Por ejemplo: 15 horas por falla en un disco; 9 horas por mantenimiento preventivo no planeado.

así entonces:

Disponibilidad = ((8,760 – 24)/8,760) x 100 por ciento) = 99.726%

Cuando se realicen negociaciones para definir objetivos de disponibilidad con los usuarios, es necesario hacerlos concientes de las implicaciones técnicas y económicas, como se muestra en la siguiente tabla:

Disponibilidad (%)

Tiempo offline/año

Tiempo offline/mes

Tiempo offline/día

90%

36.5 días

73 hrs

2.4 hrs

95%

18.3 días

36.5 hrs

1.2 hrs

98%

7.3 días

14.6 hrs

28.8 min

99%

3.7 días

7.3 hrs

14.4 min

99.5%

1.8 días

3.66 hrs

7.22 min

99.9%

8.8 hrs

43.8 min

1.46 min

99.95%

4.4 hrs

21.9 min

43.8 s

99.99%

52.6 min

4.4 min

8.6 s

99.999%

5.26 min

26.3 s

0.86 s

99.9999%

31.5 s

2.62 s

0.08 s

Disponibilidad para un sistema 24×7 y tiempos de caída permitidos.

Estos números (especialmente aquellos que pasan de la marca del 99.5% de disponibilidad) son difíciles de alcanzar, ya que es necesario poder recuperarse ante caídas del sistema de manera transparente. La capacidad e intervalo de tiempo necesarios para recuperarse ante tal eventualidad son directamente dependientes de:

• La complejidad del sistema.
• La severidad del problema.
• La disponibilidad del personal de soporte.
• La madurez en materia de administración del sistema y sus operaciones.
• Otros factores técnicos o de gestión: falta de refacciones, fallas en la cadena de escalamiento, etc.

Alcanzando alta disponibilidad

• Al elaborar un plan eficaz para hacer frente a los retos que disminuyen la disponibilidad de un sistema, primero es necesario comprender el sistema en su conjunto y cómo cada componente afecta la disponibilidad general del mismo.

• Para entonces, es posible identificar los componentes más críticos. Es importante recalcar: no importa cuán insignificante un componente del sistema pueda parecer, es posible que tenga un profundo impacto sobre la disponibilidad general del sistema.

• Una vez que hayan sido identificados los componentes más críticos, se puede buscar la manera de mejorar su confiabilidad, recuperabilidad, capacidad de servicio y administrabilidad.

En la siguiente tabla pueden distinguirse las disciplinas de gestión con el mayor impacto sobre la disponibilidad del sistema: la a menudo descuidada disciplina de la administración de sistemas.

Fase

Disciplina

Descripción

1.Generación de Objetivos

Administración de Niveles de Servicio

Identificar, negociar y acordar los servicios a ser implementados, métricas de calidad y objetivos de desempeño a proporcionar a los usuarios.

2.Planeación

Diseño de Aplicaciones y sistemas

Planear y diseñar infraestructura IT para alcanzar los niveles de servicio comprometidos con el usuario.

 

Planeación de Capacidad

Planeación de requerimientos de crecimiento del sistema.

 

Administración de la Configuración

Crear y mantener información de la configuración del sistema.

 

Administración de activos

Crear y mantener un inventario de activos; rastrear y monitorear dichos activos.

3.Ejecución

Administración de incidencias

Detectar, registrar, resolver incidencias.

 

Respaldo y recuperación

Diseñar sistemas y recursos alternativos para restaurar inmediatamente los servicios IT cuando ocurran problemas.

4.Medición

Administración del Desempeño

Monitorear información de desempeño del sistema; realizar tuning del sistema para alcanzar los niveles de servicio óptimos comprometidos con los usuarios.

5.Control

Administración del Cambio

Controlar todos los cambios en el sistema para asegurar que dichos cambios no degradan el desempeño del sistema.

 

Administración de la seguridad

Controlar y administrar acceso al sistema para minimizar las amenazas a la integridad del mismo.

 

Administración de la disponibilidad

Monitorear y controlar los recursos del sistema y la operación IT para mantener la disponibilidad del sistema.

Las disciplinas pertenecientes a la administración de sistemas.

La administración de sistemas es parte integral de cualquier sistema con alta disponibilidad, y un ingrediente necesario para alcanzar una mayor disponibilidad, pues de acuerdo a ésta:

No hay soluciones técnicas para problemas de gestión, pero puede haber soluciones administradas para problemas técnicos.

Es importante tomar en cuenta que conforme se alcanzan mayores niveles de disponibilidad (arriba del 99.5%) cada vez adquieren mayor importancia los procesos de administración de sistemas e inversamente, influyen en menor grado las técnicas ingenieriles (como tuning & performance, el diseño de la arquitectura o la última generación de hardware de alta disponibilidad).

El aspecto ingenieril de la alta disponibilidad

Aunque la metodología de administración de sistemas se encuentra fuera del alcance de este post, aquí se presentan sencillas técnicas de la ingeniería de sistemas que aseguran que el sistema se desenvolverá de acuerdo a los objetivos marcados. Algunas de ellas son:

Redundancia

La redundancia es una técnica mediante la cual un componente del sistema es duplicado y cualquiera de sus instancias puede ser utilizada en caso de falla. Ya que dos componentes idénticos están en línea, el sistema puede continuar su funcionamiento: no debe existir impacto alguno en la operación si es que esto llegara a ocurrir.

Como ejemplo práctico, en el siguiente diagrama se muestra una aplicación web en configuración de failover: un componente activo o primario siempre atiende las peticiones de los clientes, y en caso de falla, el componente pasivo o secundario entra en acción para procesarlas. Esto aplica tanto para los elementos de software (application server, motor de base de datos) como para los de hardware y almacenamiento (servidores, fuentes de poder, tarjetas de red, arreglo de discos[1]).

Diag. 1: Configuración redundante en failover de una aplicación web estándar.
[Click en imagen para ver en tamaño original]

Adicionalmente se debe considerar que en una configuración redundante debe existir un re-balanceo de la carga de manera automática; asimismo, los componentes deben ser idénticos con el objetivo de lograr que sea transparente para el resto del sistema cuál de los dos elementos está en línea.

Respaldo de recursos críticos

El respaldo (backup) es una técnica donde un componente del sistema – generalmente de software o la información de la base de datos – es duplicado y el respaldo es puesto en reserva o standby, para ser usado en caso de que el componente primario falle. A diferencia de la redundancia, el usuario final puede percibir una caída del sistema; sin embargo, el respaldo se emplea para minimizar el tiempo que toma hacer el cambio hacia el componente de respaldo, reduciendo a su vez el downtime.

Aunque el respaldo de elementos de software – como la información de base de datos, bitácoras o configuración del sistema operativo – es el más común, también existen otros dos tipos de respaldo:

• De componentes de hardware: dependiendo del diseño del sistema, los elementos respaldados son generalmente aquellos con partes mecánicas, manufactura de menor calidad (por ejemplo, equipos ensamblados) o que están sujetos a condiciones ambientales extremas (por ejemplo, en algunos países y regiones el suministro de energía eléctrica no es confiable con apagones y altibajos de voltaje frecuentes; en dichas localidades las fuentes de poder o reguladores de energía tienen un tiempo de vida mucho menor).

• Del personal operativo de IT: Es indispensable contar siempre con más de una persona con los conocimientos críticos necesarios para asegurar que la operación del sistema se lleve a cabo a pesar de la ausencia – o incluso pérdida – de personal clave. Esto se logra mediante manuales de procedimientos claramente definidos y contratos de mantenimiento sobre los componentes del sistema.

En muchas compañías (especialmente aquellas que poseen infraestructura de alto costo o con operaciones que involucren información crítica) es indispensable que los respaldos de hardware, software y personal clave así como los procedimientos de restauración de los mismos estén integrados en un Plan de Recuperación ante Desastres (Disaster Recovery Plan – DRP). Un ejemplo de este tipo de instrumentos – aunque enfocado hacia el hardware – es el Servicio de continuidad de negocio y recuperación ante desastres ofrecido por Sun Microsystems; una idea interesante que forma parte de dicho plan son los centros de datos portátiles que ofrece, llamados Blackbox porque se encuentran en un contenedor de carga (ver aquí o aquí):

Demostración del Blackbox en Monterrey, México.
[Click en la imagen para ver la fuente en sun.com]

Clusterización

En la clusterización, la carga de trabajo es compartida entre múltiples componentes o recursos del sistema redundantes y todos operan al mismo tiempo, actuando conjuntamente como si fueran un único recurso. A diferencia de la redundancia, cada componente procesa una parte de la carga de trabajo; un ejemplo de este tipo de configuraciones a nivel middleware es el Oracle RAC, que permite balancear carga entre los diferentes motores de base de datos, compartiendo un único medio de almacenamiento y redirigiendo las peticiones en caso de caída de alguno de éstos.

Estandarización

La estandarización es el establecimiento de especificaciones para el hardware, software, procedimientos y técnicas que se utilizarán en toda la infraestructura de sistemas. Esta disciplina es a menudo ignorada en favor de dar a los usuarios la libertad de elegir sus propios conjuntos de aplicaciones e interfaces con los demás sistemas de la empresa. Sin embargo, la libertad sin restricciones a menudo conduce al caos y problemas con la administrabilidad del sistema. Por otro lado, cualquier modelo de gestión de calidad (como CMM, Six Sigma o ISO-9000) requiere del establecimiento de un sistema de normas y estándares corporativos.

Conclusiones

En muchos casos, estas técnicas y procesos ya son implementados en la mayoría de los productos y servicios disponibles en el mercado, especialmente aquellos ofrecidos por proveedores de buena reputación[2]. Sólo es cuestión de saber cómo han sido incorporados, y cómo deben ser adaptados al ambiente de sistemas propio, sin embargo es importante recalcar que no importa cuántos recursos se inviertan en soluciones técnicas, éstas serán poco efectivas para prevenir las caídas a menos que también se implementen correctamente las disciplinas de administración de sistemas.

Finalmente, existe una estrategia genérica recomendada para mejorar la disponibilidad de sistemas empresariales:

• Estabilizar el sistema eliminando todos los problemas existentes. Posteriormente, resolver los problemas que ocurren con frecuencia realizando una técnica de análisis de caídas[3]. Estabilizando el sistema permite liberar recursos que pueden ser utilizados para iniciar proyectos de mejora de disponibilidad más avanzados, e incrementar la credibilidad ante los stakeholders para lograr el apoyo necesario para este tipo de soluciones.

• Implementar la administración de sistemas a través de toda la organización IT. Las buenas prácticas de administración de sistemas hacen posible conservar sistemas estables, y previenen nuevos tipos de caídas que pueden ser provocadas al introducir nuevas tecnologías o aplicaciones. Debe comenzarse con la administración de incidencias y luego se debe continuar con la administración del cambio. Después deben enfocarse los esfuerzos en la administración de la seguridad para proteger la integridad de la información ante daños intencionales o accidentales. Las disciplinas de administración de sistemas no necesitan haber sido perfeccionadas para proceder con tareas más avanzadas.

• Deben seleccionarse para mejora de disponibilidad aquellas aplicaciones y subsistemas críticos que impactan la disponibilidad general del sistema en mayor grado.

• Finalmente, deben seleccionase qué técnicas deben implementarse primero, iniciando con la confiabilidad, recuperabilidad, capacidad de servicio y terminando con la administrabilidad. Cuando sea posible, deben implementarse técnicas de disponibilidad enfocadas a mejorar varias características a la vez (por ejemplo el clústering que mejora desempeño y confiabilidad). Las elecciones específicas dependerán de las capacidades de implementación: recursos disponibles, presupuesto y capacidad técnica.

Notas y pies de página

1. La redundancia en los sistemas de almacenamiento se logra a través de configuraciones como la RAID (Redundant Array of Inexpensive Disks – Arreglo Redundante de Discos de Bajo Costo), que combina varios dispositivos de almacenamiento para ser vistos como un solo subsistema. El tipo de implementación RAID del arreglo define cómo la información es almacenada en cada disco, siendo las dos opciones más utilizadas RAID-1 y RAID-5:

• RAID-1 (también denominado mirroring) es la configuración donde efectivamente el almacenamiento se duplica entre los discos del arreglo para mayor disponibilidad, con la desventaja de la disminución en desempeño debido a la duplicidad de la escritura en disco.

• RAID-5 es aquella configuración donde la información y los datos de paridad necesarios para verificar, corregir y recuperar la información en caso de falla son distribuidos entre todas las unidades del arreglo. La principal ventaja de esta última opción es el alto desempeño, aunque se tiene una pequeña disminución de disponibilidad de la información almacenada debido al proceso de recuperación.

2. Sin embargo esta característica aplica principalmente a proveedores de hardware (por ejemplo, Hitachi Data Systems ha ofrecido desde hace casi 10 años soluciones de almacenamiento con 100% de disponibilidad) y proveedores de software que ofrecen productos desarrollados para Unix/Linux, como Oracle o MySQL.

3. El análisis de caídas es esencial para prevenir problemas de disponibilidad. Muchas organizaciones no encuentran las causas de las fallas porque se concentran en atacar los síntomas en vez la verdadera raíz de la caída. El hardware puede fallar, los usuarios pueden equivocarse y el software puede caerse, pero el sistema no necesariamente debe caerse si ha sido diseñado para tolerancia a fallos. Por ejemplo:

Un sistema diseñado para operar 24×7 de pronto se apaga. Ocurrió un apagón hace 30 minutos, y un generador diseñado para operar por dos horas dejó de funcionar por falta de combustible. ¿Cuál es la verdadera causa de la caída del sistema? Muchos pueden opinar que el apagón es el causante. Sin embargo, la raíz del problema es en realidad la falta de combustible para el generador – la persona encargada de verificar los niveles de combustible no lo hizo el día anterior. Una solución podría ser seleccionar un nuevo generador que automáticamente envíe alertas de "nivel bajo de combustible" a los administradores correspondientes.