Conclusiones

causales de manera m´as concreta.

2. El conocimiento sobre el dominio que se ten´ıa en mente estaba estructurado de manera similar a una jerarqu´ıa de marcos.

3. El sistema pretende ser lo m´as autom´atico posible pero el m´etodo cubrir y diferenciar interact´ua mucho con el usuario. Los valores activos de los marcos, como se-necesita, me permiten elegir entre preguntar al usuario o ejecutar alg´un comando externo que d´e la informaci´on que se est´a bus- cando.

4. Se han rellenado algunas ranuras de marcos clase con conjuntos de acciones. Esto ha permitido simplificar enormemente las acciones y estrategias del m´etodo de planificaci´on.

Concretando, para recuperar todo sistema software hay que seguir unas acciones comunes y en un punto dado del plan ejecutar unas acciones de recuperaci´on concretas de cada sistema software. En la soluci´on propuesta la propiedad ’acciones-recuperaci´on’ del marco que representa dicho software contiene un conjunto de acciones, representadas en estructuras, que son las necesarias para recuperar el sistema. Esto permite hacer el sistema m´as flexible ya que si a˜nadimos m´as sistemas a controlar no hace falta que modifiquemos la l´ogica del modelo de planificaci´on sino s´olo tendremos que definir una propiedad del marco clase que estamos definiendo.

Para no cansar con detalles de bajo nivel se han colocado la descripci´on del modelo y los ejemplos de ejecuci´on en un ap´endice de este documento. Se pueden consular en el Ap´endice A que se encuentra en la p´agina 95.

9.2. Conclusiones

La gran ventaja de este enfoque es que a˜nade una flexibilidad imposible de conseguir con la metodo- log´ıa orientada a objetos. Aunque el dise˜no que se ha realizado en los distintos recuperadores est´a muy estructurado y es f´acil de extender tendr´a que ser un programador el que lo haga. Sin embargo para un administrador es mucho m´as f´acil cambiar un fichero con reglas causa-efecto y as´ı modificar el compor- tamiento o extenderlo.

Una desventaja es que a priori estas soluciones se basan mucho en la interacci´on con el usuario, y esa es una de las cosas que no busc´abamos en un recuperador autom´atico.

Sin embargo, la desventaja m´as grande que encuentro es que para centrarse en la recuperaci´on de nodos, en donde el diagn´ostico y las acciones de recuperaci´on son bastante concretas, no es necesario aumentar tanto la complejidad de la aplicaci´on. S´olo tendr´ıa sentido plantear una soluci´on as´ı si deseamos

tener bajo control toda la m´aquina ya que ah´ı intervienen razonamientos m´as complejos y planes de recuperaci´on m´as elaborados.

Una buena pr´actica ser´ıa integrar la idea de base de conocimiento con reglas claras en el recuperador tradicional y as´ı permitir que los administradores sean capaces de ampliar las acciones de recuperaci´on del recuperador autom´atico.

Parte IV

Cap´ıtulo 10

Conclusiones

El proyecto ha conseguido realizar un sistema de recuperaci´on autom´atica distribuida que cumple con los todos los objetivos que se marcaron en un principio:

Comprobar peri´odicamente el estado de los nodos de c´omputo del supercomputador.

En caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar sub- sanarla de forma autom´atica.

Avisar de la incidencias detectadas.

Generar un registro de actuaciones realizadas.

Ser deshabilitado inmediatamente a voluntad de los administradores para que no interfiera en las labores de estos.

Ser habilitado en cualquier momento para que contin´ue con sus funciones.

Ser suficientemente r´apido para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.

Ejecutar sin interferir en los c´alculos de los usuarios. Ejecutar sobrecargando el sistema lo menos posible.

El recuperador autom´atico distribuido facilita el trabajo de administraci´on sobre Magerit y ahorra tiempo a los administradores de la m´aquina. Adem´as, ahora la m´aquina se recupera de errores incluso

cunado no hay administradores gestion´andola. Otra mejora son los informes de errores que facilitan el seguimiento de incidencias y la elaboraci´on de partes de aver´ıas.

La aplicaci´on es f´acil de usar a trav´es de la l´ınea de comandos y proporciona ayuda sobre las fun- cionalidades que ofrece. Otro aspecto a destacar es la calidad del c´odigo escrito, que sigue la normativa delM3Sy cerca del 40 % de las l´ıneas son comentarios. Adem´as otro factor que demuestra la calidad del producto es la arquitectura del software. Se han utilizado t´ecnicas avanzadas en el dise˜no de software y as´ı se ha expresado durante todo este documento. Pretende ser un valor a˜nadido el inca pi´e que se ha hecho en describir los razonamientos efectuados a la hora de dise˜nar el sistema. Es poco usual que se expliquen detenidamente los pasos que se dan hasta llegar al dise˜no final y pretende ser ´esta una lectura beneficiosa para el que intente entender la mentalidad que se puede emplear para realizar aplicaciones de este tipo.

El resultado de este proyecto es un sistema inform´atico que es capaz de dotar de cierta autonom´ıa al supercomputador Magerit. El supercomputador ahora es capaz de solucionar algunos de los problemas que se pueden dar en sus componentes.