Deployment of Computational Electromagnetics Applications On Large Scale Architectures

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Deployment of Computational Electromagnetics Applications On Large Scale Architectures"




3 Deployment of Computational Electromagnetics Applications On Large Scale Architectures Carlos-Jaime BARRIOS-HERNÁNDEZ (1,2), Fadi KHALIL (3), Yves DENNEULIN (2), Hervé AUBERT (3), Fabio COCCETTI (3) and Robert PLANA (3) 1- LIG Laboratory Mescal Team, Montbonnot-St Martin, France 2- I3S UNSA Laboratory Rainbow Team, Sophia Antipolis, France, 3- LAAS-CNRS; Université de Toulouse, Toulouse, France Abstract Large Scale Architectures, as Grid Computing, provide resources allowing to handle complex problems, vast collections of data storage, specific processing and collaborative interaction between distributed communities. Nowadays, there are several scientific applications that runs on Grid Computing architectures. However, in most of these cases, applications need to be adapted in order to better exploit the capacities and opportunities of scalability, heterogeneity and pervasive characteristics of Grid Computing. Large Scale Computational Electromagnetics problems place computational limitations in terms of hardware capacities. Parallel approaches proposed to face the demand of Computational Electromagnetics (CEM) aim to provide solutions to tackle high degree of complexity of the application and interaction with these large scale architectures. In this work, a description of the adaptation and implementation of Computational Electromagnetics solutions in a grid computing enabled environment is presented in terms of scientific results and performance associated with architectural opportunities. 1 Introduction Actually, fundamental problems in science and technology imply complexity, large set of data, high processing need and interdisciplinary analysis. Grid computing includes all the above characteristics and enables the development of large scientific applications to handle them. Grid-enabled applications benefit of more computational resources that are not generally available at a single local site 1, which make feasible the execution of larger applications that consume large resources and represent a high cost, in architectural terms. Nevertheless, the design and implementation of efficiency grid-aware applications is typically a timeconsuming task. The development of Grid computing applications adds complexity in building parallel and distributed applications too, because it represents new paradigms and new levels of interaction between applications, infrastructures and users. Nowadays, several scientific problems are treated with programs that run in Grid-enabled environments. Fluid dynamics, astrophysics, biology, communications, health, among others, are subject of parallel and distributed applications on Grid-enabled environments. Precisely, a main motivation to propose a Grid to support scientific research can be traced since the origins of Internet technology. This scientific inquiry with Grid computing involves technology evolution, new collaborative modalities of interaction and social challenges. The possibilities to make data-intensive science, simulation-based science, remote access to experimental devices among many others allow to perform science like e-science [8]. Interesting cases in scientific applications in which handling these problems is necessary to deal with are those involving scale changes. The growth of the scale ratio involves the use of more elements, and consequently, more resources. But the use of ad- 1 A local site should be a set of compute infrastructures placed in a specific geographic location, such as a laboratory, supercomputing center or university.

4 ditional resources, in Grid-enabled environments, requires synchronisation, data coherence and planning without losing performance. In another words, multiscale treatment implies scheduling. Several real-world electromagnetic problems like scattering, radiation, waveguiding etc, are not analytically calculable, for the multitude of irregular geometries designed and used. The inability to derive closed form solutions of Maxwell s equations under various constitutive relations of media, and boundary conditions, is overcome by computational numerical techniques. This makes Computational Electromagnetics (CEM), an important field in the design, and modeling of antenna, radar, satellite and other such communication systems, nanophotonic devices and high speed silicon electronics, medical imaging, cellphone antenna design, among other applications. It has continuously evolved in both theoretical formulation and methodology and, more recently, in their numerical implementation. Nevertheless, the multi-scale aspect is very important while modeling such structures. And more where it exists a wide diversity of scales that implies a numerical resolution with a great computational effort associated for reaching the convergence of the numerical results. In a computational context, the motivation of this work is to guarantee the execution of the accurate implemented algorithm to reach an acceptable solution without increasing the time to obtain a result, compared this time to the time cost for the execution of the simplest scale. In this work, Grid Computing capacities are investigated in order to enhance performances of numerical electromagnetic solvers to CEM issues. For this purpose, the major challenge to address is to adapt the middleware in order to guarantee an optimal scheduling, deployment and execution of the solvers in the selected local elements of the Grid Computing platform. 2 Computing Electromagnetic Modeling Techniques Applied electromagnetics is playing a pivotal role in the development of advanced technologies that address society s challenges across a broad spectrum of communications, computing, materials processing, and sensing applications. In electromagnetism, Maxwell s equations, which are a set of four partial differential equations that describe the properties of the electric and magnetic fields and relate them to their sources, charge density and current density, must be solved. Usually, these equations are computed on an enormous number of points representing the discretization of the physical domain of the studied structure. Naturally, such discretization of the computational space consumes computer memory, and solving the equations takes a long time. Large scale CEM problems place computational limitations in terms of memory space, and CPU time on the computer. Generally CEM problems, are run on supercomputers, high performance clusters, vector processors and parallel computer. A number of different numerical techniques for solving electromagnetic problems are available. Each numerical technique is well-suited for the analysis of a particular type of problem. The numerical technique used by a particular EM analysis program plays a significant role in determining what kinds of problems the program will be able to analyze. In this work, two numerical electromagnetic are concerned: the Transmision Line Matrix (TLM) Modeling Method [7] and the Scale Changing Technique (SCT) Method [2]. While applying the TLM, a volumetric time-domain modeling method, the entire region of the analysis is gridded. An advantage of the TLM method resides in the large amount of information in one single computation. But when the computation domain is too large and/or lot of precision is demanded, usually the number of unknowns to compute explodes, which renders these computations impossible on one computer. The second modeling method, named SCT, is an original and efficient numerical technique for electromagnetic modelling of modern planar multiscale structures, like multi-band frequency-selective surfaces, active or passive reflect arrays, or self-similar (pre-fractal) planar objects. This method is known to be fast but due to the actual increase of scale ratio and the complexity of the structures, the parametric studies of convergence needed by this technique for electromagnetic analysis may become prohibitive in terms of computer memory and time. 3 SCT Algorithm The Scale Changing Technique consists of decomposing the electromagnetic studied structure into different domains with respect with the scale ratio between them 2. The strategy consists of artificially introducing intermediate scale levels such that two suc- 2 Examples of multi-scale structures are given by multiband frequency-selective surfaces, active or passive reflectarrays, or self-similar (pre-fractal) planar objects.

5 cessive levels differ from a one (or two) decade(s). The SCT is based on the cascade multimodal Scale Changing Networks (SCN), each network modeling the electromagnetic coupling between two succesive scale levels [2]. The concept of SCT is close to the physical equivalence principle. Instead of describing the whole structure, one can characterize located electromagnetic effects that then will be integrated in the larger scale. In each sub-domain the higher-order modes are used for the accurate representation of the electromagnetic field local variation while lower-order modes are used for coupling the various scale levels. The transition from one scale to another looks like a discontinuity between two waveguides of different section. The integral equation method using entire domain trial functions enables determination of the N-port network associated with this discontinuity. The combination of all scales is then modeled by the cascade of elementary networks that are analogous at each scale [2] [16]. Obviously, the multiplicity of the scales present in a structure is a problem that SCT aims to handle. The multiscale nature of a structure is used to break up this one into sub-structures. Taking into account the entire problem corresponds to the cascading of these different sub-structures, each sub-structure characterize the transition of a scale towards another. This subdivision allows a modularity which largely eases the implementation of parametric studies. The high flexibility of the approach associated with the advantages of the Integral Equations Formulations renders this original approach powerful and rapid [2] [16]. Figure 1 presents the different modules M1, M2, M3, M4 and M5 related with 5 compute process. The modules allow relating two scale levels with different order of magnitude. The cascade of these modules with M6, M7, and M8 modules, allows crossing the scale from the lowest to the highest scale. Figure 1. Compute Flow of SCT Modules and Distribution in Levels Making a sequential description of the SCT technique from the Figure 1, we can propose the next pseudocode: Read General Input Parameters Compute M1 M2 M3 M4 M5 Reduce M1 M2 M3 M4 M5 Output in Level_1 Input Read Level_1 Input Compute M6 Reduce M6 M3 M4 M5 Output in Level_2 Input Read Level_2 Input Compute M7 Reduce M7 M4 M5 Output in Level_3 Input Read Level_3 Input Compute M8 Print General Output The computation codes originally written for such structures are sequential. But since these modules are independent, consequently, they can be computed in parallel. The modules are distributed by levels in the available compute resources. The distribution of the compute process is made using the opportunities of the batch scheduler in the platform, taking advantage of non-local resources, resources on a wide area network, or even the Internet when local compute resources are scarce, as explained in the Section 4. Note that for simplicity of explanation, only a structure with limited scale changes is represented here. Usually, modern studied structures have a big scale ratio between the biggest and the small dimension which may explode the number of levels and modules to treat such problems. 4 Scheduling and Deployment: SCT Case In Grid Computing, scheduling is important because it implies the coordination of users, jobs, task and resources. The scheduling process should support the processing of different algorithms at different times and to different queues (normally both). Scheduling should be able to interact with the resource manager in use [12]. Many tasks of scheduling may be dedicated to a resources manager or they may be treated by the resources manager and the scheduler together. This last possibility allows the generation of the batch scheduler to provide a exploitation of the resources in agreement with jobs processing. Obviously, a hierarchy of tasks and jobs exists. The different levels may be organized in behalf of the profit of the resources or by the order of the task in the job queue, in according with the politics for the use of the common Grid computing resources.

6 Our proposition corresponds to a general hierarchical solution for the scheduling in behalf of the parallelization opportunities present in a specific platform testbed: Grid 5000 (G5K) [3] [11], and the clusters contained in this national wide Grid computing platform. Specifically, the computational electromagnetic method concerned is the Scale Changing Technique (SCT) [2] that allows to analyze the planar complex structures as a combination of many scale [2]. The scale levels interaction is sensitive; when the number of levels grows, the complexity grows too (and also the volume of information). The SCT method is associated with some numerical solvers contained in a SCT application set that consists of a collection of the Matlab c [15] codes. The codes are organized in compute modules for specific compute jobs. The jobs are collected in levels. The different levels are associated with the interaction between the computational modules, which may be distributed on different nodes to take advantage of the opportunities of task distribution in each compute level. Our approach for these numerical solutions can allow the deployment of the applications in the selected nodes of the Grid platform with a specific characteristics of software environment to guarantee scalable and pervasive execution. The use of necessary resources demands management of these distributed resources and good interaction with the middleware and operating system. In the case of G5K, the management is made by OAR 3 [4] [17] and the deployment by KaDeploy [10] [14]. A plug-in between the batch scheduler and the specific SCT codes is proposed to allow the distributed execution in the Grid computing platform. The analysis of these methods determines common opportunities, nevertheless they are different in computing. The plug-in is a set of scripts (written in batch and Taktuk [6] [18]) that allows the allocation, distribution and execution of tasks taking advantage of the OAR characteristics. The possibilities given by TakTuk allows to write simple portable programs. Basically, Taktuk provides an efficient work distribution on heterogeneous platforms thanks to an adaptive work-stealing algorithm. The work-stealing technique allows to divide a procedure execution efficiently among multiple processors. Work-stealing is used in different forms: as adaptive algorithms or reactive algorithms implemented in different systems or programming 3 And an API named OARGRID. languages such as Kaapi [9] [13] or Cilk [1] [5]. The processor maintains a stack on which it places each frame that it has to suspend in order to handle a procedure call. If it is executing the Modules of the level 1, and encounters a recursive call to level 1 Modules, it will save Module s Levels 1 states before to run the next level modules, including its variables and where the code suspended execution, and put that state on the stack. It will not take a suspended state off the stack and resume execution until the procedure call that caused the suspension, and any procedures called in turn by that procedure, have all been fully executed. On the other hand, it is important to say that for the deployment function of the software environment for the execution of SCT programs, Kadeploy is used without any modification. Figure 2. MEG Environment Deployment in Grid 5000 Platform Figure 2 shows the deployment of the MEG Environment (represented by the yellow folder). The MEG Environment is an operating system image with the set of libraries, codes and programs to SCT compute. The MEG Environment is deployed in the reserved nodes of the specific selected clusters. The user interact with the Grid environment with a simple ssh connexion, via a local access site or frontend server. When the user select the nodes in the infrastructure, that contains the necessary hardware (mainly defined by the type of processing cores and number of nodes), and the time to work upon Grid 5000 (or Grid system, represented in the Figure 2 as a cloud), the user should be interact in two modes: active and passive. In the active mode, the interaction with the platform is in real time, contrary, the passive mode is programmed. Actually, the work on one site is managed and scheduled by OAR. When the compute occurs in several sites, the OARGrid API is used. The interconnection among the sites is granted by OARSSH, a SSH API for OAR.

7 In practice, the user should select different nodes and sites (is not necessary to use the local site itself). The possibility of use is determined by the availability of resources at moment of the interaction (in the case of the active mode) or the availability of resources for the start programmed timed of job. Observing the Figures 1 and 3, we can notice the different levels and the relation among them (levels are limited by discontinued blue lines). A data dependence exists between them. For example, after the compute of the first five modules (see the Figure 1) the output is the input of the next level (inputs and outputs are represented like rhomboids with the word input or output respectively), to compute the module 6. Same for the next modules. Figure 3. SCT Scheduling Flow and Distribution in Levels The workflow start with a general input file of parameters. These parameters are placed/distributed into the compute modules (the process of placement and distribution is shown as a circle and the compute modules are represented by boxes into the Figure 3) to reach the first work level. In this level, the five first modules are distributed in the available nodes in equal quantities. For example, if there are 40 nodes reserved and available to compute, the compute work by compute module is made by 8 nodes. The outputs of each one of the modules are concentrated to made the second level of compute 4, also 4 The concentration process is represented with the two inverse triangles symbol. distributed in all nodes available. In the third level shown in the Figure 3, we use the outputs of the level 2 and the outputs of the compute modules 2, 3, 4 and 5. In the next level four, we use the output of the level three and the outputs of the compute modules 4 and 5. In the same way that for the last level, the compute module is distributed in the available nodes. Finally, we can get the final outputs. Note that the relation will be expressed like a hierarchical interaction with the platform resources. Figure 3 shows the computer workflow in terms of inputs, outputs and allocation of resources. Each module of the first level is allocated in function of the reserved resources. After that, in function of the outputs, a new re-allocation is possible, but in this case, in function of the first available resources. The first allocation of resources is really an activity of the resources manager. Obviously, the connections between the outputs, new inputs (manually or not), implying new computing levels. Then, the complexity and size of the levels related with the scale necessary to work, should be growing or decreasing. As these tasks are associated with the management and use of the platform, this approach allows to observe the properties of the tool to build the layer between the batch scheduler such a plug-in. Then, in accordance with the necessity of operation, the goals of the plug-in should be addressed as: Simplicity of use : The scientific user needs an easy interaction, mainly with the compute modules, the access and interaction with the Grid computing platform should be transparent. Integration with OAR and Kadeploy : The SCT modules are addressed with a mainly interaction with Grid 5000 infrastructure. Then the plug-in should be integrated with OAR, OARGRID API and Kaa-tools. Minimal workload added by the plug-in execution: It is recommendable that the plugin do not add significant computational cost compared to the cost of the SCT code itself. Automatic allocation of modules in nodes by level: As shown in Figures 1,?? and??, the deployment and allocation of the MEG Environment, and the compute modules all distributed with efficiency in the available resources. The allocation will be automatic in accordance with the compute needs and availability. There are requirements like fault tolerance and

8 transparent integration with other batch schedulers that are not yet handled. However, in the case of fault tolerance, it is possible to analyze different factors that should be considered as a fault related with the SCT. For example, failures of hardware or connection are treated by the batch scheduler, in this case, OAR. 5 First Results In the SCT application case, we took advantage of the distribution opportunities like data migration possibilities. Every module of the SCT application is treated like a black box. The perspective of processing efficiency, in accordance with the theory is between 15% and 30%. However, in view of the scalability possibilities of the problem, the efficiency is really unknown. Nevertheless, it is necessary to evaluate the performance of the solution proposed, from the practical use. To handle this, two points are necessary: a performance evaluation in terms of HPC efficiency and the observation of the pertinence of the results from the specialists perspective. The objective of the tests shown in this article is to evaluate the performance of the plugin from an infrastructure-tool relation. Then, we can observe the transfer cost of the image environment and also the efficiency of the distribution of the compute modules in the platform in terms of makespan. The makespan allows to observe the time difference between the start and finish of a sequence of job of tasks. Precisely, as is show after in this paper, one our interests is to see the compute time given a number defined of nodes to compute the SCT codes. The observation of this time provides information about the gain or loss of time of the application when the different modules run in the Grid computing platform. The results presented here are obtained with the use of almost two platforms of the Grid 5000 infrastructure. The first one is the Toulouse site, with two clusters: Pastel and Violette. These two clusters allow to use 426 nodes of Sun Fire architecture, with core processors of 2.2 GHz and 2.8 GHz. The other site is the Bordeaux site with 645 nodes of IBM and Dell Technology, which includes the use of AMD Opteron and Intel Xeon architectures. Clearly, the behavior of the implementation depends on the network performance, and consequently implies an analysis of the data transfer. Thus, we propose two different analysis: first, an analysis of data transfer of the image that implies an important set of bytes, and second, an analysis of the normal transfer of data, that implies a smaller quantity of bytes per data. As explained before, in order to run the computation environment, deploying the image that contains the SCT computational codes on several nodes is necessary. Each image contains between 300 MB and 550 MB approximately. This deployment in Grid 5000 platform is made with Kadeploy of Ka- Tools. A data transfer of 300 MB or 550 MB is a critical process, because this type of data transfer implies high bandwidth use, massive and parallel data transfer. In this type of transfer, the network resources implied are exploited in concurrence with others. Also, the capacity of the network should be saturated and when this transfer occurs in heterogeneous nodes, a high cost is associated with the network capacity and the use at same time of the deployment image. Considering the worst case, a deployment process of 550MB on one node occurs during 250 seconds, where an important percentage of the time corresponds to transmission of the server in the node. Obviously, when the number of nodes implied in deployment is increased in the same cluster, the deployment time grows and the maximal use capacity of the network is reached. After this point, the behavior become stable. If we observe the bandwidth in the same transfer, as is presented in the Figure 4, is possible to know the use of the capacity in terms of transfer. Same that the experiences made with the benchmark tool, the bandwidth grows to a point for two (2) links and after remains stable in interval for the two measures between 4.2 MB/s and 4.5 MB/s. Figure 4. Bandwidth in MEG Environment Image Deployment The experience described here shows the deployment using 10 links between 2 remote platforms (in this case between the Pastel cluster at Toulouse site

9 and the Bordemer cluster in the site of Bordeaux, transfer direction from Toulouse to Bordeaux). The latency average between the two clusters at the moment of the transfer is the 75 microseconds. The second point of view, implies only the data transfer of files of smaller quantity of bytes (files from 0 KB to 15 KB). The data transfer in this case for a same latency is very small ( 25 and 100 microseconds). Then, this situation suggest to analyze the processing time. Using the same local platforms, the makespan performance for a typical execution of the SCT implementation that implies 1024 different configurations is investigated. Figure 5 shows the theoretical prediction for this execution compared to the experimental measurements. Figure 5. Makespan Performance of the SCT Implementation In Figure 5, the prediction is represented by the green line and the measures for the red triangles. The confidence interval remains, and the values of the measures start more hight that the theoretical green line. The regularity of the curves shows good agreement with the theory. It is interesting to observe how the slope of the values increase when 4 processors are used. On the other hand, the reduction of the time comparing with the execution on one processor is the almost 45%. A prediction of the time with 50 processors in two remote local platforms has been performed. In Figure 6, it is possible to observe that the reduction of time remains 45%. However the curve (in red and blue) reach the minimal possible value after the use of 46 processors where the estimation for this type of computation is the 10 seconds. Beyond this point, it becomes stable. This situation has been completely predicted, because there is always a limit for the number of processors contributing to the efficiency of the computation with respect to the grain of the problem. Moreover, increasing the num- Figure 6. Makespan Prediction of the SCT Implementation ber of processors should normally increase the total time of computation due to the communication between them. The Scale Changing Technique has proven to be an original and efficient numerical technique for electromagnetic modeling of modern planar multiscale structures. Using this modelling method, accurate numerical results are obtained with a substantial reduction in computer time and memory compared to direct full-wave electromagnetic analysis, due to the intrinsic scalability of this method. The obtained results have confirmed the effectiveness of the parallel distributed approach compared to sequential computing. This approach shows very good computation performance while keeping the same accuracy. Note that most of the time, when small geometry changes occur, only one or few SCT compute modules need to be recalculated, which is not the case of other numerical tools [2]. Besides, this method is very promising for optimizing circuit with multiple design parameters to handle and for the global electromagnetic simulation of multi-scale or/and over-sized structures. 6 Conclusions and Further Work The adaptation and implementation of scientific applications, initially designed to run on simple computers (or monolithic supercomputers), for Grid computing environments is a big challenge. However the same HPC uses and assuming that the parallelization opportunities can be located in one HPC local platform, the distribution of the processing in another local platform implies heterogeneity and scalability, without taking into account the possibilities of

10 a strong data dependency. These aspects should be treated from the infrastructure or computer science perspective without break the scientific efficiency of an application or implemented method. Besides, scientific applications could be developed by scientists which are not necessarily computer specialists. The characteristics of each solution implemented in a computer program correspond to a numerical method with a high sensibility to change. Thus, treatment of a scientific application like a black box could be the efficient strategy to avoid modifying the numerical solution and leaving the problem of the efficient distribution and execution in the grid computing platform to a low level. Our solution is based on the implementation of the SCT method without changes, using a plug-in to deploy the compute environment allows to be useful distribution opportunities and the accuracy of the method proposed by the electromagnetic specialists. Nowadays, there are several scientific applications that solve efficiently a lot of specific problems in their domains. A preoccupation of the scientific community is to run these applications into Grid computing infrastructures that optimize automatically the parallelism and distribution opportunities given for the infrastructure and middleware. However the specific solution proposed for the SCT, the observations in performance evaluation contribute to understand the pertinence and measure the efficiency of the development of plugins to provide parallel and distributed execution into Grid computing platforms. On the other hand, the knowledge of the performance of the scientific application in terms of execution is necessary, and for this reason we have made an evaluation of the efficiency and accuracy in two phases: scientific results and performance evaluation from a computer science perspective. In this paper we are concentrated in the computer science perspective. The first results presented in this paper, confirm an acceptable performance of the strategy implemented in accord with the efficiency of the shared resources. The decrease of the compute time in 45% suggest a good profit of the scalability opportunities. In the current work, new experiences have been executed growing the complexity to have an use necessity of almost two times more of processors ( processors). However, not only the quantity of processors is an important parameter, the specific features of the processors too. For this reason, other work associated is made, that implies the observation of the heterogeneity between the characteristics of the platforms, to use efficiently the available resources. 7 Acknowledgement The authors wish to acknowledge the National Research Agency (ANR) for support of MEG Project (ANR-06-BLAN-0006) 5. References [1] Agrawal, K., He, Y. and Leiserson C. E. An Empirical Evaluation of Work Stealing with Parallelism Feedback. Proceedings of the International Conference on Distributed Computing Systems (ICDCS) Lisboa, Portugal, July, [2] Aubert., H The Concept of Scale-Changing Network in the Global Electromagnetic Simulation of Complex Structures. Progress Electromagnetics Research B, vol. 16, page , [3] Bolze, R., Cappello, F., Caron, E., Dayde, M., Desprez, F., Jeannot, E., Jegou, Y., Lanteri, S. Leduc, J. Melab, N., Mornet, G., Namyst, R., Primet, P., Quetier, B., Richard, O., Talbi, E. and Touche I. Grid 5000: A Large Scale and Highly Reconfigurable Experimental Grid Testbed. International Journal of High Performance Computing Applications, 20(4): , November [4] Capit, N., Da Costa, G., Georgiou, Y., Huard, G., Martin, C., Mounie, G., Neyron, P. and Richard, O. A Batch Scheduler with High Level ComponentsProceedings of IEEE International Symposium on Cluster Computing and the Grid, 2005, CCGrid Volume 2, 9-12 May 2005 Page(s): Vol. 2, Cardiff, United Kingdom [5] MIT- Cilk Project Project Site. [6] Claudel, B., Huard, G. and Richard, O. Tak- Tuk, Adaptive Deployment of Remote Executions. Proceedings of International ACM Symposium on High Performance Distributed Computing, Munich, Germany, [7] Christopoulos, C.: The Transmission-Line Modeling Method. Wiley-IEEE Press, [8] Foster, I. and Kesselman, C. (Editors) The Grid 2: Blueprint for a New Computing Infrastructure. Morgan Kaufmann Publishers, Elsevier Inc. San Francisco, CA, United Statesof America For more information about the MEG Project, please visit:

11 [9] Gautier, T., Besseron, X. and Pigeon, L. KAAPI: A thread scheduling runtime system for data flow computations on cluster of multi-processors. Proceedings of the 2007 international workshop on Parallel symbolic computation, London, Ontario, Canada [10] Georgiou, Y.; Leduc, J.; Videau, B.; Peyrard, J.; Richard, O. A tool for environment deployment in clusters and light grids. Parallel and Distributed Processing Symposium, IPDPS th International Volume, Issue, April [11] Grid 5000 Project Project Site. [12] Iqbal, S., Gupta, R. and Fang, Y. Planning Considerations for Job Scheduling in HPC Clusters. Dell Power Solutions. Internet Document [13] KAAPI Project. Project Site. [14] Kadeploy: Scalable Deployment System for High Performance Computing. Project Site. [15] Matlab. Mathworks Inc. Internet Site. [16] Khalil, F., Rashid, A., Aubert, H., Coccetti, F., Plana, R., Barrios-Hernandez, C.J, and Denneulin. Y. Application of scale changing technique-grid computing to the electromagnetic simulation of reflectarrays IEEE International Symposium on Antennas and Propagation, Charleston, South Carolina, June 1-6, [17] OAR: Resource Managment System for High Performance Computing. Project Site. [18] TakTuk: Adaptive Large Scale Remote Executions Deployment. Project Site.

12 Distributed Architectures As Solution to Demanding Systems of Critical Use Services Considering Security, Performance and Availability Factors. Arquitecturas Distribuidas Como Solución a Sistemas Demandantes de Servicios de Uso Crítico Considerando Factores de Seguridad, Rendimiento y Disponibilidad. Mario Bonilla, Luis Vargas, Erick Meneses Universidad Industrial de Santander, Colombia, Abstract Given the importance and impact that have the availability and performance in information services for network environments with increased demand, distributed architectures are being developed to satisfy these needs. One of them is the high availability cluster, which enables us to orchestrate a set of heterogeneous resources to provide a service for long periods of time without interruption. This paper presents the design process, technology selection and implementation of a high availability cluster system based around three layers: load balancing, network service and distributed storage, taking into consideration security in each of them and the system in general, obtaining therefore a reliable and scalable system with high levels of performance and availability. Resumen Dada la importancia e impacto que toma la disponibilidad y rendimiento en servicios de información para entornos de red con aumento en la demanda de estos, se plantean arquitecturas distribuidas que permitan satisfacer estas necesidades, una de ellas es el cluster de alta disponibilidad, que permite orquestar un conjunto de recursos heterogéneos para prestar un servicio por largos períodos de tiempo sin interrupciones. Este trabajo presenta el proceso de diseño, selección de tecnologías e implementación de un sistema cluster de alta disponibilidad basando en tres capas: balanceo de carga, servicio de red y almacenamiento distribuido, teniendo en cuenta la seguridad en cada una de ellas y el sistema en general, obteniendo así un sistema confiable y escalable con altos niveles de rendimiento y disponibilidad. 1. Introducción Actualmente, debido a la masificación en el uso de servicios informáticos nace la necesidad de funcionar de manera ininterrumpida los 365 días del año[1], buscando mejorar la organización y configuración de los componentes que prestan dichos servicios[2]. Las soluciones tradicionales a la necesidad de servicios disponibles han hecho que las organizaciones opten por el uso de sistemas centralizados con altos costos y con inconvenientes de escalabilidad al no soportar demandas crecientes del servicio. Por estas razones, se ha presentado un auge en el desarrollo de conceptos y tecnologías basadas en sistemas distribuidos por medio de las cuales se logran obtener niveles apropiados de disponibilidad, rendimiento, escalabilidad, seguridad y de relación costo beneficio, que conforman soluciones para las organizaciones actuales dada la masificación de la comunicación y el creciente valor de la información. Algunas de ellas son sencillas como en el caso de clusters de balanceo con DNS[15][16] donde no existe un manejo óptimo de la carga, o haciendo uso de balanceadores más específicos para algunos servicios como el módulo para balanceo de carga de apache[17], lo que se convierte en una desventaja a la hora de querer prestar otros servicios como el de correo electrónico. Para muchas empresas, las interrupciones no planeadas representan tiempo sin el apoyo de sus sistemas informáticos y puede llegar a ser catastrófico, o al menos muy costoso, como lo revelan dos estudios

13 independientes realizados por Giga Group 1 y Eagle Rock Alliance,Ltd 2, encontrando que una empresa pierde en promedio hasta 6.45 millones dólares por hora de interrupción no planeada de sus servicios informáticos. Dado el grado de impacto, surgen tecnologías como el cluster de alta disponibilidad (cluster High Availability) que permite obtener sistemas distribuidos tolerantes a fallos, haciendo uso de la redundancia en los componentes de dicha arquitectura, siendo capaz de soportar fallos en el menor tiempo posible y de forma transparente para el usuario. Linux HA Project y Linux Vitual Server (LVS) son los encargados de aunar los esfuerzos de la comunidad de software libre para hacer de GNU/Linux una plataforma en la cual se puedan desarrollar con éxito este tipo de arquitecturas distribuidas. En las siguiente sección se muestra de manera general la arquitectura de un cluster de alta disponibilidad, sus componentes y la interacción entre ellos dentro del sistema, más adelante se presenta la arquitectura propuesta teniendo en cuenta características de disponibilidad, rendimiento y seguridad, las herramientas tecnológicas que intervienen en el proceso y como se acoplan para alcanzar el objetivo deseado; una vez expuesta la arquitectura se procede a hacer un análisis de disponibilidad y escalabilidad basándose en pruebas y cálculos formales que permitan clarificar la mejora del servicio al utilizar sistemas distribuidos, finalmente se muestran los resultados, conclusiones del trabajo y bibliografía. 2. Arquitectura Cluster de Alta Disponibilidad de alta disponibilidad son de tipo comercial y muy pocas de tipo académico. Soluciones comerciales IBM High Availability Cluster (HACMP) para AIX y GNU/Linux. Red Hat Cluster Suite. Microsoft Cluster Server (MSCS) W.server Sun Cluster para Solaris y OpenSolaris. Oracle Clusterware para Oracle Real Application Clusters (RAC). HP Serviceguard para HP-UX y GNU/Linux. Soluciones investigativas/académicas LVS Linux Virtual Server, soluciones de la comunidad de software libre. Linux-HA, paquetes de uso libre para el sistema operativo GNU/Linux. El proyecto Linux Virtual Server[3] proporciona un servidor escalable y altamente disponible construido sobre un sistema balanceador de carga, un cluster de servidores reales y un sistema de archivos distribuido, todo este conjunto corriendo sobre sistemas operativos GNU/Linux. La arquitectura del cluster es transparente a los usuarios finales, quienes sólo ven un único servidor virtual en una única dirección IP, esto es posible gracias a los métodos de reenvío de conexión que permite que esta serie de recursos puedan atender solicitudes de servicio en conjunto. Los componentes de ésta arquitectura se muestran en la figura 1 donde están agrupados por capas y estas son: capa de monitorización de servicios y balanceo de carga, capa de servidores reales y capa de almacenamiento compartido. A continuación se presenta una descripción de las capas y cada unos de sus componentes. Actualmente existen varias implementaciones de clusters de alta disponibilidad y todas ellas buscan ofrecer excelentes niveles de disponibilidad y eficiencia del servicio resguardando siempre la seguridad de la información y haciendo énfasis en procesos de balanceo de carga, almacenamiento y manteniendo la fiabilidad del sistema a través de la redundancia como técnica principal [18]. La mayoría de soluciones sobre cluster 1 Firma internacional de analistas en tecnología de información. Resultados del estudio se encuentran disponibles en: 2 Eagle Rock Alliance, Ltd. es una empresa consultora especializada en Fiabilidad de consultoría y tecnología. Resultados del estudio: Figura 1: Arquitectura General Cluster Alta Disponibilidad

14 2.1 Capa de Monitoreo y Balanceo de Carga Las peticiones de servicio al servidor virtual son recibidas por un conjunto de máquinas denominado sistema balanceador (a través de una dirección IP virtual VIP), quien estará en continua monitorización de los servicios prestados y redirigirá las peticiones a un conjunto de servidores reales que darán una respuesta a los usuarios del sistema. Esta capa está compuesta por dos nodos y se permiten dos posibles configuraciones para su funcionamiento. En la primera denominada Activo/Activo los dos nodos reciben peticiones de servicio, en la segunda llamada Activo/Pasivo existe un nodo primario o principal que recibe peticiones de servicio y otro secundario o backup el cual permanece en estado de espera hasta que ocurra un fallo en el primario o principal para retomar los servicios prestados por este último. Monitorización de servicios Una de las herramientas software provistas por el proyecto Linux HA3 es heartbeat cuya labor es mantener servicios altamente disponibles. Este basa su funcionamiento en el envío y recepción de latidos ; señales enviadas por los demonios heartbeat que corren en las máquinas del sistema balanceador. Además, heartbeat es el encargado de lanzar la recepción del servicio que ha de prestarse en alta disponibilidad y activar la VIP en el nodo secundario, cuando detecta la ausencia de latidos por parte del nodo balanceo primario. Balanceo de carga El proceso de balanceo de carga hace uso de la lista de servidores reales disponibles que se obtienen mediante una herramienta de administración llamada Ldirectord la cual en tiempo real asigna unos recursos a una solicitud de servicio dependiendo del algoritmo de planificación. Ldirectord (Linux Director) es un demonio lanzado por heartbeat para la monitorización y control de los servidores reales, así como para llevar a cabo la administración de las tablas de forwarding del kernel. Ldirectord verifica el estado de los servidores reales en intervalos de tiempo predeterminados permitiendo 3 Proyecto Linux-HA tiene por objetivo brindar una solución en alta disponibilidad para servicios de red sobre sistemas GNU/Linux actualizar dinámicamente las tablas que definen el comportamiento del balanceador de carga IPVS, así si uno de los servidores reales deja de atender peticiones, ldirectord creará una llamada a ipvsadm que hará que el balanceador deje de reenviarle paquetes al servidor real. Algoritmos de planificación El sistema balanceador es el encargado de distribuir la carga entre los diferentes servidores reales. Para hacerlo se basa en conjunto secuencial de normas, llamadas algoritmos de planificación (scheduling), que permiten decidir en cada momento a que servidor debe reenviar los paquetes pertenecientes a una misma conexión. Dentro de los algoritmos que se pueden usar con el proyecto LVS[3] se encuentran : Round-Robin (rr) Weighted Round-Robin (wrr) Least-Connection (lc). Weighted Least-Connection (wlc). 2.2 Capa de Servicio En esta capa se encuentran los servidores reales los cuales son los encargados de procesar las peticiones de servicio redirigidas desde el sistema balanceador de carga. Entre los servicios que se pueden prestar están: servicio web, correo electrónico, bases de datos, VoIP y aplicaciones más específicas como un CRM o una ERP entre otros. En este proyecto se seleccionaron dos servicios (servicio web y servicio de correo electrónico) a fin de brindar diferentes escenarios para analizar el comportamiento de la arquitectura propuesta. 2.3 Capa de Almacenamiento Compartido Sistemas de almacenamiento compartido El incremento de la demanda de cómputo en ambientes científicos, comerciales ha llevado a una alta demanda no solo de poder computacional, sino de capacidad de almacenamiento para ubicar la información ya procesada o datos a procesar. Se observa a continuación las características más relevantes que tienen los sistemas de archivos, tomadas en cuenta en la arquitectura propuesta para cumplir con las necesidades de compartir y unir todos los discos como uno solo sin dejar de lado los dos objetivos principales de esta propuesta que son: el rendimiento (paralelismo) y la tolerancia a fallos (replicación).

15 Sistemas de archivos distribuidos En un cluster de alta disponibilidad los servidores reales necesitan tener acceso y manipular la misma información, una solución a esta necesidad es mediante los sistemas de archivos distribuidos, en donde varios usuarios comparten archivos y almacenan recursos. Las ventajas de los sistemas de archivos distribuidos respecto a los sistemas centralizados son [4]: Compartir recursos: los usuarios tienen acceso a sus recursos compartidos a través de la red. Reducción de costos: Las redes de equipos de cómputo ofrecen una mejor relación precio/rendimiento que los mainframes. Tolerancia a fallos: Los sistemas distribuidos permiten replicar recursos y procesos, a fin de proporcionar fiabilidad y disponibilidad al sistema, el fallo de un nodo no implica el fallo global. Algunos sistemas de archivos distribuidos son: NFS[5] (Network File System) y GlusterFS[6]. Sistemas de archivos paralelos En los sistemas de archivos distribuidos, los archivos se almacena en un servidor, y el ancho de banda de acceso a un archivo se encuentra limitado por el acceso a un único servidor. Este problema, es originado por el desequilibrio existente entre el tiempo de cómputo y el tiempo de E/S (Entrada/Salida).[7] Lo anterior situación se soluciona con los sistemas de archivos paralelos, puesto que estos utilizan paralelismo en el sistema de E/S con la distribución de los datos de un archivo entre diferentes dispositivos y/o servidores. Esto evita los cuellos de botella en los procesos de E/S ya que se accede de forma paralela a un archivo, aporta en el rendimiento al hacer un mejor uso del ancho de banda del sistema total. Algunos sistemas de archivos paralelos son: Lustre[8], Parallel Virtual File System PVFS2[9]. Los mecanismos para tolerancia a fallos en almacenamiento pueden tener un soporte hardware o software, o bien una combinación de ambos. Un modulo del kernel de GNU/Linux es DRBD (Distributed Replicated Block Device) el cual permite hacer replicación remota en tiempo real en dispositivos de almacenamiento por medio de TCP/IP (RAID1)[11]. 2.4 Capa Transversal de Seguridad La seguridad es una característica deseable en todo sistema y su aplicación un cluster, donde su fuerte es el rendimiento obtenido a través de la distribución de recursos y trabajos, es también su problema, inherente a su naturaleza distribuida que va desde la simple transferencia de archivos hasta operaciones complejas de colaboración y resolución de problemas. Es importante resguardar la seguridad garantizando la integridad, confidencialidad y disponibilidad del sistema [21], en este sentido es posible abordar el problema de forma perimetral descendiendo desde el nivel de red, nivel de host hasta el nivel de servicio, valiéndose de las herramientas proporcionadas en proyectos reconocidos, como: Netfilter 4, Squid 5, Snort 6, SELinux 7 y PKI 8 entre otros. 2.5 Proceso de comunicación entre el usuario y el servicio. La necesidad de atender y responder las solicitudes de servicio de manera transparente para el usuario requiere de métodos de reenvío de conexiones que hacen uso de las propiedades técnicas y geográficas de la topología de red que se use. Los métodos propuestos por LVS [3] se listan a continuación: Método de reenvío de conexiones por NAT (VS- NAT). Método de reenvío de conexiones por encapsulado IP (VS-Tun). Método de reenvío de conexiones por enrutamiento directo (VS-DR). Tolerancia a fallos Tolerancia a fallos es la capacidad de un sistema de mantenerse en funcionamiento ante un fallo. Disminuir la probabilidad de fallo está relacionada con la implementación de técnicas como la replicación de componentes en el sistema. Si algún componente falla otros pueden responder correctamente, haciendo de este proceso transparente para el usuario (failover)[10]. 4 Framework contenido en el sistema operativo linux para el filtrado de paquetes de red 5 Servidor Proxy para filtrado de paquetes y aceleración de servicios web haciendo uso de almacenamiento en cache 6 Sistema de detección de intrusos 7 Conjunto de módulos de seguridad que provee el sistema operativo Linux para la implementación de políticas de acceso y control. 8 Infraestructura de Llave Publica, mecanismo de autenticación usado en sistemas distribuidos

16 3 Disponibilidad en Sistemas Distribuidos Un dilema común en las TIC's es cómo sobrevivir a interrupciones planeadas y no planeadas, por medio de los los sistemas distribuidos se logra distribuir la probabilidad de fallos, en la práctica, esto se requiere del cuidado en el diseño, configuración e integración de los componentes que hacen parte del mismo. En un entorno distribuido, los criterios básicos para calcular la disponibilidad son los siguientes [12]: Determine la disponibilidad de cada componente, como un número de 0 a 1. Multiplicar la disponibilidad de todos los componentes juntos para conseguir la disponibilidad total, que generalmente se expresa como un porcentaje. En un cluster de alta disponibilidad se pueden identificar 3 componentes que conforman una arquitectura de este tipo, los cuales son: balanceadores de carga, nodos del servicio prestado y el almacenamiento compartido. Matemáticamente, esto se describe como [12]: Dtotal = DBalanceoCarga * DNodosServicio * DAlm.Compartido (2) Dtotal = Dtotal * 100% (3) D = Disponibilidad En el contexto de disponibilidad existen dos formas de clasificar los componentes computacionales de un cluster, estos son: Cluster de nodos Activos: Conjunto de componentes computacionales que se encuentran prestando su servicio activamente todo el tiempo. Cluster de nodos Activo/Pasivo: Conjunto de componentes computacionales que tienen un componente igual asociado, el cual es pasivo y monitorea al nodo activo para en caso de falla retoma los servicios del primero. Fallo del cluster Considerando un cluster de nodos Activo/Pasivo, si falla un nodo el otro retomara los servicios, sin embargo si fallan los dos nodos el servicio estará no disponible. Se definen los siguientes parámetros para el cálculo de la disponibilidad del sistema: n = número de nodos del sistema. a = disponibilidad de un nodo (porcentaje del tiempo que está funcionado correctamente). f = probabilidad de fallo de un nodo (porcentaje del tiempo que no funciona). F d = probabilidad de fallo del sistema. F = probabilidad de que el sistema este dañado. A= disponibilidad del sistema. Siendo 1 el 100% se deduce que la probabilidad de no prestar el servicio es f = 1- a, luego la probabilidad de que 2 nodos no estuvieran prestando el servicio al mismo tiempo es la probabilidad de que un nodo no funcione y la probabilidad que el segundo nodo tampoco funcione, matemáticamente esto es f = 1 a² enmarcado en un cluster de n nodos seria f = 1 a n. El número de formas ( c ) en las que pueden fallar los componentes del cluster depende de la manera como fue organizado, más adelante se analiza la variable c para cada caso especifico en la organización de los componentes del cluster de alta disponibilidad. Por último la probabilidad de fallo del cluster es [13]: Fd = c*(1-a) n (4) Eventos de Failover En el caso de que un nodo falle el sistema se mantiene en funcionamiento, sin embargo hay un tiempo usado para la retoma de servicios, este es el tiempo que transcurre desde que un nodo activo es reportado como dañado, hasta que su copia (nodo pasivo) se convierte en activo y retoma los servicios. Se define lo siguiente: F f = Probabilidad que el sistema no funcione por causa de un proceso de failover. MTFO = Tiempo medio de failover (tiempo promedio de retoma de servicios en caso de fallo) MTFB= Tiempo medio entre fallos de un nodo. La proporción de tiempo que el sistema esté dañado durante un failover de un nodo en particular es MTFO/MTFB, teniendo en cuanta que hay n nodos en el sistema, el fallo de cualquier nodo llevara asociado un evento de failover. La probabilidad que el sistema no funcione durante el proceso de failover es [13]: F f = n*(mtfo/mtfb) (5) Disponibilidad en un cluster La probabilidad que el sistema no funcione (F) es la probabilidad de fallo del cluster (F d ) más la probabilidad que el sistema no funcione por causa de un proceso de failover (F f ) [13]: F = F d + F f = c*(1-a) n + n(mtfo/mtbf) (6) La disponibilidad del sistema (D) es: D = 1 F (7)

17 4 Arquitectura Propuesta La arquitectura propuesta fue diseñada con la unión de componentes que aportan características de escalabilidad, rendimiento, seguridad y tolerancia a fallos mediante la replicación de servicios e información. Las tres capas verticales que se muestran en la figura 2 definen el orden en que una petición de servicio será atendida por el servidor virtual y su integración será descrita en esta sección. servidores reales disponibles para prestar servicio. El algoritmo de planificación para el balanceo de carga es el WLC (Servidor con menos conexiones activas ponderado), el cual permite asignar un peso a los servidores reales según sus capacidades o según las características de los servicios prestados. Este método garantiza una distribución de las peticiones de servicio según el estado de las conexiones activas en cada servidor evitando la saturación de los mismos. Capa de Servicio Para evaluar la arquitectura propuesta se generaron dos escenarios. En el primero se implemento el servicio de páginas web mediante el protocolo HTTPS (Hypertext Transfer Protocol Secure) y el servidor Apache, y en el segundo se implemento el servicio de correo web a través los protocolos SMTP (Simple Mail Transfer Protocol) para intercambio de mensajes, IMAP (Internet Message Access Protocol) para el acceso a mensajes electrónicos en el servidor y las herramientas SpamAssassin 9 para filtrado de paquetes, el antivirus Clamav 10 y Rouncube 11 como cliente Mail-Web, todo bajo comunicación cifrada soportada por medio del protocolo SSL (Secure Socket Layer). Capa de Almacenamiento Capa de Balanceo Figura 2: Arquitectura Propuesta Esta encargada de recibir las peticiones de servicio y de repartirlas en el conjunto de servidores reales. Al estar compuesta por dos balanceadores su probabilidad de fallo que se distribuye pues mientras que un nodo está procesando las solicitudes el otro se encuentra monitoreando (configuración Activo/Pasivo) para en caso de falla retomar el servicio de manera rápida sin que el usuario note la ausencia del mismo. El proyecto Linux-HA provee el software encargado de la monitorización: heartbeat, el cual monta automáticamente la interfaz con la IP virtual del servidor para recibir las peticiones de servicio y, cuando el nodo principal falla, el demonio hearbeat será el encargado de levantar una interfaz con la IP virtual en el nodo secundario donde se seguirán prestando los servicios del principal garantizando la continuidad del negocio. En esta misma capa se lleva a cabo el balanceo de carga, tarea realizada por el demonio ldiretord el cual hace uso de reglas IPVSadm para actualizar la tabla de El sistema de archivos basado en cluster que se usó fue Lustre File System, el cual se eligió basándose en los resultados obtenidos de las pruebas de rendimiento donde se comparó con PVFS2 (Parallel Virual File System 2), además de la revisión bibliográfica realizada donde se encuentra que Lustre tiene mejores niveles de rendimiento y escalabilidad al lado de otros sistemas de archivos [8][14]. La distribución de los componentes del sistema de archivos en la arquitectura diseñada es como se muestra en la figura 2, donde un nodo de almacenamiento cumple con las labores de servidor de metadatos MDS y labores de administración del sistema de archivos con el sistema de gestión MGS, además existen 2 nodos de almacenamiento (OSS) que aportan un volumen físico al sistema de archivos paralelo y al igual que el servidor administrador y de metadatos (MDS y MGS) tienen sus respectivas copias de respaldo por medio de DRBD. Esta integración permite obtener un sistema de archivos de alto rendimiento por medio del uso de paralelismo en la E/S, altamente escalable, y tolerante a fallos

18 mediante la replicación en tiempo real permitiendo que si un servidor del cluster de almacenamiento falla, otro tome su lugar de forma transparente sin que el usuario lo note. Capa de Seguridad La seguridad vista de forma perimetral permite asegurar el sistema formando anillos concéntricos de afuera hacia adentro protegiendo la información en varios niveles: red, aplicación y host. A nivel de red se implenta el filtrado de paquetes a través de iptables lo que permite disminuir el trafico restringiendo paquetes no deseados y delimitando la comunicación solo entre capas adyacentes, lo que disminuye la posibilidad de una intrusión. También se incluye un sistema NIDS (Network Intrusion Detection System) usando la herramienta Snort que brinda auditabilidad al tener un registro centralizado de monitoreo de paquetes malformados en la red y detectados como posibles ataques. A nivel de aplicación se aprovecha que los servicios implementados se basan en web y se implementa un servidor proxy replicado sobre los balanceadores, de este modo cada paquete que ingresa al cluster es analizado y almacenado en memoria cache lo que brinda seguridad y rendimiento al tener acceso rápido a páginas que no cambian frecuentemente. También se agrega un elemento externo que es la autoridad de certificación implementada a través del software OpenCA 12 a fin de emitir certificados digitales a cada uno de los usuarios del sistema y de este modo establecer una autenticación multifactor basada en login/password y certificado digital. Por último, se garantiza la integridad de la información haciendo uso de protocolos de transferencia cifrada como ssl y ssh, evitando el sniffing en la red. A nivel de host se realiza el respectivo hardening del sistema operativo así como del servicio que se esté prestando, también se hace uso de SELinux que mediante una correcta configuración permite establecer políticas de división y acceso a los recursos del sistema. cada proyecto. Específicamente, la distribución usada en la implementación fue Debian en su rama estable perteneciente el proyecto GNU/Linux, la cual tiene un índice de disponibilidad de 99,942 (5.08 horas no disponible al año) según un estudio 13 realizado por el Yankee Group Research, Inc. lo que la convierte en una distribución óptima para el desarrollo de sistemas de alta disponibilidad. A nivel de operación la principal característica es la escalabilidad, que está presente en todos los niveles. A nivel de balanceo hertbeat permite tener un cluster de maquinas recibiendo peticiones y redireccionandolas de acuerdo a el algoritmo de balanceo configurado, en el nivel de servicio se encuentra el conjunto de maquinas que atienden las peticiones propiamente y ofrecen el servicio solicitado, y más abajo se encuentra el nivel de almacenamiento administrado por el sistema de archivos lustre que distribuye la información hasta en 100 nodos dependiendo de la capacidad, que está ligada el método de enrutamiento del sistema balanceador. 5 Calculo de la Disponibilidad Para el cálculo de la disponibilidad se necesita conocer dos datos característicos de la arquitectura propuesta, el primero de estos es el MTBF de cada máquina y hace referencia a las propiedades de los equipos de cómputo en términos de disponibilidad, tanto en la parte de hardware como en la parte del software instalado. El segundo dato necesario es el tiempo que se tarda en retomar los servicios las copias existentes en las diversas capas de la arquitectura propuesta. Generalidades Todo el software usado en la construcción de la arquitectura es software libre y de código abierto disponible en los repositorios Linux o en los portales de Figura 3: Failover en las diferentes capas del cluster 12 Software que implementa una autoridad de certificación para una infraestructura de llave publica 13 Resultados disponibles en:

19 Las pruebas de failover se realizaron creando eventos de fallos en algunos nodos por capas sacándolos del cluster y midiendo el tiempo que se tardaba en retomar los servicios al nodo que tenía replicado el servicio adjunto. Este proceso se realizó durante 8 veces y se promediaron los resultados. Primero se realizó la prueba en la capa de balanceo con un tiempo promedio de segundos en la retoma del servicio, en la capa de cluster de servidores el promedio fué de y en la capa de almacenamiento el tiempo de reconfiguraron del sistema de archivos realizado por el MGS de Lustre FS para incluir la copia proporcionada por DRBD, mostró el tiempo más alto de failover en todas las capas, con un promedio de segundos. 5.1 Disponibilidad en la Arquitectura Propuesta A continuación se realiza el cálculo de disponibilidad en cada una de las capas de servicio de la arquitectura implementada, teniendo en cuenta las ecuaciones expuestas en la sesión 3 y los valores de tiempo antes calculados. Disponibilidad en la Capa de Balanceo Con n=2 nodos, a=0, , MTFOBalanceCarga=4,351 Seg, MTBF=8640 h 15 y c=1 se calculan las ecuaciones (4) (5) (6) (7) obteniendo: Fd= e-7, Ft= e-7, F= e-6 DBalCarga = 9, e-1 Disponibilidad en la Capa de Servicio Con n=4 nodos, a= 0,999118, MTFOClusterServicio = 0,762 Seg, MTBF=8640 h y c=1. Teniendo F t = MTFO/MTFB para sistemas con todos los nodos activos y las ecuaciones (4) (6) (7) se obtiene: Fd= e-13, Ft= e-8, F= e-8 DClusterServicio = 9, e-1 muestra que si hay un cluster de n nodos existe n*(n+1)/2 combinaciones únicas de un fallo doble de nodos. Con estos parámetros y las ecuaciones (4) (5) (6) (7) se obtiene: Fd= e-5, Ft= e-5, F= e-5 DAlmCompartido = 9, e-1 Teniendo en cuenta la ecuación (1) enunciada en la sección 3 y reemplazando los valores hallados se tiene: Dtotal = DBalanceoCarga * DNodosServicio * DAlm.Compartido (1) Dtotal= e-1*9, e-1* e-1 Dtotal =9, e-1 Disponibilidad Total = % Con la arquitectura diseñada e implementada se logró una disponibilidad de cuatro nueves, se puede decir que a lo largo de un período de un año el sistema estará fuera de servicio por 20 minutos 36 segundos. Valores de disponibilidad mayores a 99% son considerados sistemas de alta disponibilidad, y al alcanzar un valor de cuatro nueves la arquitectura propuesta es aceptada para prestar servicios de misión crítica [19]. Es de resaltar la redundancia como característica principal en cada una de las capas mejorando la disponibilidad de cada una de ellas distribuyendo la probabilidad de fallos en las copias activas o pasivas existentes en cada capa de la arquitectura implementada. 5.2 Escalabilidad en la Arquitectura Propuesta Las pruebas de escalabilidad fueron realizadas sobre un cluster homogéneo de 12 pc's distribuidos de la siguiente manera: 8 pertenecientes al cluster de almacenamiento con un servidor de metadatos y administrador del sistema de archivos Lustre y 3 servidores de almacenamiento, todos con sus respectivas copias; 4 servidores web corriendo apache, que a la vez son clientes del sistema de archivos y 2 servidores balanceadores en configuración activo/pasivo. Disponibilidad en la Capa de Almacenamiento Con n=6 nodos, a= 0,999118, MTFOAlm.Compartido= Seg, MTBF=8640 h y c=1. En el sistema de archivos Lustre replicado, si dos nodos fallan el sistema de archivos no funcionara, la variable c 14 Valor de la disponibilidad como resultado de cálculo realizado a una máquina Dell Optiplex gx620 con sistema operativo GNU/Linux Debian Valor suministrado por el Centro de Tecnologías de Información y Comunicación CENTIC-UIS para máquinas Dell Optiplex gx620

20 Figura 4: Saturación del Servidor Virtual El benchmark que se utilizo para las pruebas fue autobench[14], este permite realizar un número de conexiones a una IP solicitando una página con una tasa de solicitud constante hasta alcanzar un número de conexiones establecido. Los resultados generados por el benchmark muestran el comportamiento que se obtuvo en el test ejecutado, algunas de estas medidas son: el tiempo promedio en el cual se atendieron las solicitudes realizadas, el ancho de banda usado en la E/S, etc. El conjunto de pruebas se realizaron desde la red local con interfaz fast ethernet 10/100, con los resultados se puede medir el punto de saturación del servidor virtual, el cual es aquel donde el tiempo de respuesta empieza a aumentar (>2 segundos) por el trabajo al que está siendo sometido el servidor. El test se realizó usando escenarios de 1, 2, 3 o 4 servidores reales, en la figura 4 se puede ver la comparación de estos escenarios, en donde se puede observar que el punto de saturación aumenta cuando se aumenta el número de servidores reales garantizando la escalabilidad del servicio cuando la demanda del mismo lo requiera y además asegurando que el servicio http esté disponible por medio de la replicación del servicio que existe en cada servidor, si se daña uno habrá otro(s) que seguirán prestando el servicio. Figura 5: Escalabilidad del Servidor Virtual El comportamiento lineal que se obtiene entre número de servidores reales y el número de conexiones atendidas muestra la escalabilidad que se obtiene en poder de cómputo al aumentar el número de servidores reales y obtener un incremento del número de conexiones atendidas (punto de saturación). 6 Conclusiones El diseño de la arquitectura propuesta divide los servicios por capas y replica los componentes en cada una de ellas, disminuyendo la probabilidad de fallos en el sistema. Se demuestra que demuestra que a través de un correcto diseño e integración de software libre y hardware convencional se puede construir una arquitectura distribuida tipo cluster, logrando alcanzar un índice de disponibilidad aproximado de 99,996% en el servicio prestado. A partir de las pruebas realizadas se observa que la arquitectura propuesta es altamente escalable, lo que permite satisfacer de manera eficiente el creciente número de solicitudes realizadas por los usuarios con un aumento proporcional en el número de servidores reales que componen el cluster. El comportamiento del sistema como un todo se ve afectado por los componentes de comunicación (interfaces y medios), que determinan los tiempos de trasmisión de datos y respuestas, de acuerdo al ancho de canal de banda.

21 7 Referencias [1] E. Marcus y H. Stern. Blueprints for high availability (2nd Ed.). Capítulo 1: Introduction, Pag 1-5. John Wiley and Sons, New York (2003). [2] Charles Bookman Linux clustering: building and maintaining Linux clusters. Tercera edición. Capitulo 5 [3] Zhang W, Linux Virtual Servers for Scalable Network Services, Linux Symposium (July. 2000) DOI= ps.gz. [4] Schroeder, M. D A state-of-the-art distributed system: computing with BOB. In Distributed Systems (2 nd Ed.), S. Mullender, Ed. Acm Press Frontier Series. ACM Press/Addison-Wesley Publishing Co., New York, NY, [5] R. Sandberg, D. Goldberg, S. Kleiman, D Walsh, B. Lyon Design and implementation of the SUN network filesystem. In Proceedings of the 1985 USENIX Conference. (June. 1985). [6] Zresearch. GlusterFS Wiki DOI= [7] Y.N. Patt The I/O subsystem: A candidate for [8] improvement. 27, 3(Match 1994), [9] Cluster File Systems Inc. Lustre file system. DOI= [10] P. Carns Walter, R. B. Ross Rajeev PVFS: A Parallel File System for Linux Clusters Parallel Architecture. Research Laboratory Clemson University, Clemson. Volume 2000, Issue 80 (Nov. 2000). [13] Robinson R. y Polozoff A. Planning for Availability in the Enterprise, IBM WebSphere Developer Technical Journal (Dec 2003) DOI= bsphere/techjournal/0312_polozoff/ ml. [14] Calculating Availability - Cluster Availability, Availability Digest, (May 2007) DOI= /0205/calculating_availability_clusters.pdf [15] Autobench DOI= [16] Bryhni, H. Klovning, E. Kure, O. A comparison of load balancing techniques for scalable Web servers. IEEE (2000). [17] G. Díaz, J. Chaves, Mendoza, H. Hoeger, L. Núñez. Adaptación de Clusters de Linux para Servicios de Redes. VI jornadas Científico Técnicas de la facultada de ingenierías, Universidad de los Andes (2007). [18] K. Coar y R. Bowen. Apache Cookbook. Capítulo 10: Proxies, Load Balancing with mod_proxy_balancer. Páginas 211,212. (2007). [19] E. Marcus y H. Stern Blueprints for high availability (2nd Ed.). Capítulo 9: Data and Web Service, Pag John Wiley and Sons, New York (2003). [20] E. Marcus y H. Stern Blueprints for high availability (2nd Ed.). Capítulo 2: What to Measure, Pag John Wiley and Sons, New York (2003). [21] M. Pourzandi et Al. Clusters and Security: Distributed Security for Distributed Systems. In 2005 IEEE International Symposium on Cluster Computing and the Grid, [11] Cristian, F. Understanding fault-tolerant distributed systems. Commun. ACM 34, 2 (Feb. 1991), DOI= [12] Pla, P Drbd in a heartbeat. Linux J. 2006, 149 (Sep. 2006), 3.

22 Una factorización Cholesky out-of-core Jorge Arturo Castellanos Díaz Centro Multidisciplinario de Visualización y Cómputo Científico (CEMVICC), Facultad de Ciencias y Tecnología (FACYT), Universidad de Carabobo, Valencia, Venezuela. Germán A. Larrazábal S. Centro Multidisciplinario de Visualización y Cómputo Científico (CEMVICC), Facultad de Ciencias y Tecnología (FACYT), Universidad de Carabobo, Valencia, Venezuela. Resumen Con frecuencia, el núcleo computacional en el software general de simulación es el encargado de resolver el sistema lineal. Este núcleo puede ser denso o disperso dependiendo de la discretización numérica. Para la solución de sistemas lineales grandes es deseable el uso de una estructura dispersa. Los solvers directos dispersos como Cholesky, LDL T, o LU son perfectas cajas negras ya que ellos necesitan únicamente como entradas: la matriz (A) y el vector del lado derecho (b) del sistema lineal Ax = b. Pero presentan como principal desventaja que la cantidad de memoria necesaria para resolver el sistema se incrementa rápidamente con el tamaño del problema. En este trabajo, se propone la implementación de un software out-ofcore para la factorización Cholesky que resuelve el problema de la memoria. La capa out-of-core se basa en el desarrollo de una memoria caché especializada que almacena solamente una parte de la matriz del problema (A) y de la matriz factorizada (L) que residen en un archivo de disco. La matriz factorizada (L) se calcula en un proceso de dos pasos, específicamente: un proceso simbólico y uno numérico. El primer paso calcula la posición de los elementos no nulos de cada fila/columna y el segundo proceso calcula los valores numéricos para cada una de las posiciones usando el Método Multifrontal. Se han obtenido ahorros significativos de memoria usando el soporte out-of-core propuesto. Los resultados preliminares muestran un buen desempeño usando el solver LU out-of-core para un conjunto de matrices que provienen de un operador escalar elíptico discretizado usando diferencias finitas. Abstract Frequently, the computational core in general simulation software is the linear system solver. This solver may be dense or sparse depending on the numerical discretization. For solving large systems it is desirable the use of a sparse structure. The direct sparse solvers such as Cholesky, LDL T, or LU are perfect black boxes, i.e., they only need the matrix (A) and the right hand side vector (b) of the linear system Ax = b as inputs. But their main disadvantage is that the memory required by them usually increases rapidly with problem size. In this work, we propose an out-of-core implementation for the Cholesky solver in order to overcome the memory problem. The out-of-core layer is based on a specialized cache memory development that stores only a part of the problem matrix (A) and the factorized matrix (L) whose data is stored in a file disk. The factorized matrix (L) is computed in a two step process, specifically: a symbolical and a numerical process. The first step computes position of the non- zero element of each row/col and the second process computes the numerical value for each position using the Multifrontal Method. We have obtained a significant save of memory with our proposal. The preliminary results show a good performance using our Cholesky out-ofcore solver for a set of large matrices that arise from a scalar elliptic operator which is discretized using finite differences. Keywords-Out-of-core, Sparse cholesky factorization. I. INTRODUCCIÓN El núcleo computacional que consume mayor tiempo de CPU en un paquete de simulación numérica en ingeniería es el solver lineal. Comúnmente, este solver esá basado en un clásico de solución, tal como un método directo o iterativo. Además, la matriz asociada al sistema lineal de ecuaciones, con frecuencia, es disperso y de gran tamaño. Los métodos iterativos tienen la desventaja que no son generales y requerien varios parámetros de usuario y además necesitan precondicionadores a fin de acelerar su convergencia. Sin embargo, estos métodos son populares ya que su principal operación es matriz por vector, y esta opreación es altamente paralelizable. Los métodos directos como Cholesky, LDL T, o LU son perfectas cajas negras ya que ellos necesitan únicamente como entradas la matriz (A) y el vector del lado derecho (b) del sistema lineal Ax = b. Pero presentan como principal desventaja que la cantidad de memoria necesaria para resolver el sistema se incrementa rápidamente con el tamaño del problema. Esta desventaja se ve claramente en un reciente estudio [5]. El problema de la factorización Cholesky out-of-core de matrices dispersas no es nuevo; ya en 1984 se planetea un solver multifrontal [11]. En [13] se revisa la eficiencia en la implementación de tres métodos out-of-core para la factorización Cholesky y se consideran alternativas para mejorar la eficiencia de los métodos revisados. En un trabajo reciente [12] se presenta un solver Cholesky out-of-core escrito en Fortran 95, cuyo funcionamiento se basa en un paquete de memoria virtual que provee las facilidades para la escritura y lectura directa de archivos en disco. A diferencia de [12] en este trabajo se implementa la capa out-of-core de la factorizacón Cholesky como una parte del soporte out-of-core de la biblioteca UCSparseLib [8] que cuenta con un conjunto de funciones para la resolución de sistemas lineales dispersos. En este trabajo, se propone la implementación de un software out-of-core para la factorización Cholesky que resuelve el problema de la memoria. La capa out-of-core se basa en el

23 desarrollo de una memoria caché especializada que almacena solamente una parte de la matriz del problema (A) y de la matriz factorizada (L) que residen en un archivo de disco. La matriz factorizada (L) se calcula en un proceso de dos pasos, específicamente: un proceso simbólico y uno numérico. El primer paso calcula la posición de los elementos no nulos de cada fila/columna y el segundo proceso calcula los valores numéricos para cada una de las posiciones usando el Método Multifrontal. Además, este trabajo representa un avance de [1], [2], mediante el cual se agrega una capa out-of-core a una bilioteca de solución de sistemas lineales. Como parte de este proyecto, el núcleo out-of-core debe estar en capacidad de resolver eficientemente el problema de la factorización de matrices dispersas. En este artículo se tratan la adiciones necesarias al núcleo out-of-core ya existente que hicieron posible resolver este problema. El presente artículo está organizado de la siguiente forma. En la sección II, se presentan los formatos de almacenamiento para matrices dispersas, necesarios para comprender este trabajo. En la sección III, se explica el diseño del núcleo out-of-core, también se muestra la interacción con el núcleo a través de una macro en alto nivel. En la sección IV, se muestra los detalles de implementación de la factorización Cholesky haciendo uso del del núcleo out-ofcore implementado. En la seción V, se presentan resultados que muestran la utilización de memoria y el tiempo de ejecución de la factorización Cholesky cuando el núcleo out-of-core está activado y se comparan con versiones incore equivalentes sin soporte out-of-core. Finalmente en la sección VI se presentan las conclusiones del trabajo. II. ALMACENAMIENTO DE MATRICES DISPERSAS Como lo establece [4], los formatos de almacenamiento comprimido por fila y por columna son los más generales para el almacenamiento de matrices dispersas, pues no toman en cuenta el patrón de esparcidad de la matriz y no almacenan elementos innecesarios. valores de los elementos diferentes de cero de la matriz A en el orden que ellos se obtienen cuando se recorre la matriz por filas. El vector id almacena los índices de las columnas de los elementos en el vector val. Esto es, si val(k) = a i,j, entonces id(k) = j. El vector ia almacena las posiciones en el vector val que inician una fila; asi, si val(k) = a i,j, entonces ia(i) k < ia(i + 1). Por convención, se define ia(n + 1) = nnz, donde nnz es el número de elementos diferentes de cero en la matriz A. Los ahorros en almacenamiento por este formato son significativos. En lugar de almacenar n 2 elementos, solo utilizamos 2nnz + n + 1 localidades. Como un ejemplo, consideremos la matriz nosimétrica A mostrada en la figura 1. Aplicando el formato CRS se tienen los vectores val, ia, id (mostrados en la figura 2). Figura 2. Formato de almacenamiento comprimido por fila (CRS). Análogo al formato CRS, hay un formato comprimido por columna (CCS). El formato CCS es idéntico al formato CRS, excepto que las columnas de A se almacenan (subsecuentemente) en vez de las filas. En otras palabras, el formato CCS es el formato CRS para A T. Con el objeto de facilitar el acceso independiente de un conjunto de filas (columnas) desde un archivo en disco, se definió dentro de la capa out-of-core un formato de almacenamiento temporal en disco (ver figura 3). Figura 1. Matriz dispersa. El almacenamiento comprimido por fila (CRS) guarda los elementos subsecuentes diferentes de cero de las filas de la matriz en localidades contiguas de memoria. Asumiendo que tenemos una matriz dispersa no-simétrica A (ver figura 1), creamos entonces tres vectores para almacenar la matriz (ver figura 2): uno para números en punto flotante (val) y los otros dos para enteros (ia, id). El vector val almacena los Figura 3. Formato de almacenamiento para el archivo temporal. Este formato representa una variación del formato CRS (CCS), mediante el cual se han segmentado los vectores id y val en fraccciones que se corresponden con cada una de las filas (columnas) de la matriz (ver figura 1). Las filas (columnas) representadas por segmentos de los vectores

24 id y val se almacenan entonces concecutivamente en el archivo temporal. El acceso de las filas (columnas) en el archivo se logra a través del vector pos que mantiene las posiciones de inicio de cada una de las filas (columnas) dentro del archivo. Como la matriz se almacena en orden ascendente por fila (columna) dentro del archivo temporal, es posible transferir fácilmente un conjunto de filas (columnas) simultáneamente a la memoria, pues a través del vector pos se puede determinar la posición de inicio y el tamaño del bloque a transferir. En el ejemplo de la figura 3 y en el resto del artículo se supone que los índices y los valores ocupan una unidad de almacenamiento; esto se ha hecho para facilitar las explicaciones. En la implementación real los índices ocupan la mitad de espacio de los valores, pues se considera que los primeros son del tipo entero mientras que los segundos son del tipo double. III. LA CAPA out-of-core Según se indicó en la sección I, la implementación outof-core de la factorización Cholesky obedece al desarrollo de una capa de software que soportará todas las operaciones out-of-core de la biblioteca de solución de sistemas dispersos UCSparseLib [8]. Cuando se inició el soporte out-ofcore para la factorización Cholesky ya se contaba con el núcleo out-of-core para las operaciones básicas con matrices dispersas [1], [2]; este software soportaba eficientemente las operaciones: transpuesta de matrices y los productos matrizvector y matriz-matriz. Para la comprensión de este trabajo se explicará a continuación brevemente la operación de esta capa. Según ya se indicó en la sección II, la matriz que se lee del archivo de disco se almacena en un archivo temporal que obedece a una variación del formato de almacenamiento CRS/CCS que facilita el acceso a cada fila (columna) de la matriz según sea el formato utilizado CRS o CCS. El ńucleo out-of-core usa como unidad mínima e indivisible de almacenamiento una fila (columna), la cual se denominará nodo para futuras referencias en este artículo. De acuerdo con [15] para tener un buen desempeño, un algoritmo out-of-core debe acceder los datos almacenados en disco en forma de grandes bloques contínuos, y una vez que un bloque se carga en memoria, este debe reutilizarse muchas veces. Esto supone que la capa out-of-core debe permitir el acceso de conjuntos de nodos concecutivos para aprovechar los principios de localidad temporal y espacial que soportan la teoría de la memoria caché explicada en detalle en [14]. A diferencia de las matrices en formato denso cuyas filas (columnas) tienen un tamaño fijo, las matrices dispersas presentan un tamaño variable por fila (columna) porque solo almacenan los elementos no-nulos y su posición. Si se quiere aprovechar la teoría de la memoria caché, se debe almacenar en memoria principal un (o mas de un) bloque de nodos. Para el acceso eficiente a los nodos almacenados en disco, el núcleo out-of-core crea en memoria una caché de correspondencia directa [10] que saca provecho de los bits de direccionamiento de bloque en relación a la dirección del nodo. Así, cuando se activa el soporte out-of-core, la matriz dispersa no se carga completamente a la memoria y en lugar de ello solo se transfiere desde el archivo temporal en disco a la memoria un subconjunto de nodos consecutivos de la matriz que en adelante denominaremos bloque. Para dividir apropiadamente la matriz de trabajo en bloques fácilmente direccionables, el número total de nodos de la matriz se completa al próximo número entero 2 n (n: entero 0). En nuestro ejemplo, para la matriz de la figura 4 que tiene 7 nodos, el próximo número 2 n es 8. La figura 4 muestra la conveniencia de completar el total de nodos a 8 = 2 3. De esta forma, la matriz A puede ser fácilmente dividida en 4 bloques de 2 1 = 2 nodos cada uno. Figura 4. División en bloques de una matriz dispersa. Para ocultar los detalles de implementación de la capa out-of-core al programador y acceder en forma transparente a cada uno de los nodos de la matriz, se han definido dos macros: una para operar sobre matrices almacenadas por fila (CRS) y la otra para operar sobre matrices almacenadas por columna (CCS). Cuando el nodo es una fila (formato CRS) se usa la macro For OOCMatrix Row, y cuando el nodo es una columna (formato CCS) se usa la macro For OOCMatrix Col. Para simplificar la explicación, de aqui en adelante solo se hará referencia a nodos del tipo fila y por lo tanto se usará solamente la macro For OOCMatrix Row (ver figura 5). # define For_OOCMatrix_Row( MM, ii, row, mode )\... \... \ Figura 5. Definición de la macro For OOCMatrix Row. Como se ve en la figura 5, la macro For OOCMatrix Row tiene cuatro parámetros: MM es una estructura que contiene información general de la matriz, por ejemplo: formato (CRS/CCS), número de nodos, apuntador al archivo temporal asociado a la matriz, etc. ii es un entero que representa el nodo actual.

25 row es una estructura que contiene la información asociada al nodo; esta estructura tiene tres campos importantes: nz, de tipo entero que contiene el número de elemento diferentes de cero del nodo, id y val son vectores del tipo entero y del tipo double que contienen los índices del nodo y los valores no-nulos del nodo respectivamente. mode es un campo que maneja el acceso al nodo actual; puede tomar tres valores diferentes, es decir, READ: lectura, WRITE: escritura o READ WRITE: lectura/escritura. Esta macro llama internamente todas las funciones necesarias para obtener/liberar un nodo desde la aplicación de alto nivel. Por supuesto, todas la rutinas necesarias para el manejo de la caché y del archivo temporal en disco se llaman dentro del ámbito de la macro. De esta forma el programador elimina su preocupación por los detalles de implementación de bajo nivel que reducen su productividad y la transportabilidad de sus códigos. La figura 6 muestra gráficamente como opera el nucleo out-of-core. Se supone que la matriz A (ver figura 1) reside en un archivo en formato CRS (ver figura 2); para este ejemplo, la caché en memoria se configuró con un tamaño de 1 bloque de 2 1 nodos. Se tiene tambien un archivo temporal asociado a la matriz, como se comentó en la sección II. Cuando la matriz A se carga por primera vez desde un archivo en disco, los índices se leen desde el archivo de acuerdo a la especificación del formato CRS (ver la sección II). Como se ve en la primera parte de la figura 6, los índices cargados desde el archivo de entrada se escriben en la caché. Cuando la caché está totalmente llena con los índices de los dos primeros nodos (filas), es decir, cuando cuando se van a escribir en la caché los índices del tercer nodo, provenientes del archivo en disco, se escribe en el archivo temporal en disco el contenido total del bloque almacenado en caché. Los índices se almacenan en conjunto con ceros (en formato double) con el objeto de reservar espacio para los elementos no-cero asociados a tales índices; los valores del nodo se cargarán en la siguiente fase, despues que se hayan cargado todos los índices. La segunda parte consiste de la carga de los valores nonulos desde el archivo de entrada. En esta fase, los índices que se cargaron en la primera parte son recargados a la caché desde el archivo temporal; de esta forma es posible combinar la información de los índices con los valores en la estructura de la caché y en el archivo temporal en forma de unidades independientes (nodos), para tener un acceso más eficiente a cada uno de los nodos al trabajar con operaciones sobre matrices. La tercera parte de la figura 6 muestra como los nodos se leen secuencialmente desde el archivo temporal hacia la caché. Esto aplica a la mayoría de los casos de operaciones básicas con matrices cuando se accede secuencialmente a los nodos de la matriz. Las operaciones básicas con matrices toman ventaja del principio de localidad espacial [14] de la caché de correspondencia directa del núcleo out-of-core. Por ejemplo, cada vez que el algoritmo producto matriz-vector, trata de acceder a un nodo que no está en caché (ver figura 6), se carga desde el archivo temporal un nuevo bloque de 2 n nodos a la caché. Caso contrario, si el nodo está en la caché, este se lee desde la memoria. Aunque el algoritmo del producto matriz-vector no hace uso del principio de localidad temporal de la caché (enunciado en [14]), el código de la figura 7 muestra buenos tiempos de ejecución. Esto es porque los nodos de la matriz de entrada se acceden secuencialmente y el soporte out-ofcore puede resolver automáticamente los fallos de caché, cargando un bloque de 2 n nodos concecutivos. De esta forma el efecto de los altos tiempos accesos al disco se minimizan cuando la tasa de aciertos es alta (> 99%). for (ii= 0; ii< nn; ii++) { For_OOCMatrix_Row( M, ii, rc, READ ) { raux = 0.0; for (kk= 0; kk<; kk++) raux = raux + rc.val[kk] * xx[[kk]]; yy[ii] = raux; } } Figura 7. Producto matriz-vector. IV. FACTORIZACIÓN DE LA MATRIZ La factorización Cholesky out-of-core de la matriz dispersa se realiza en un proceso de cuatro pasos: 1) Lectura de la matriz desde un archivo de disco y almacenamiento en un archivo temporal usando el esquema descrito en la sección III. 2) Ordenaniento de la matriz usando METIS [6] con el objeto de reducir el número de elementos no-nulos de la matriz factorizada y por tanto reducir el tiempo del proceso de factorización. 3) Factorización simbólica de la matriz, para determinar la posición de los elementos no nulos de la matriz factorizada. 4) Factorización numérica de la matriz, para calcular el valor de cada uno de los elementos no-nulos de la matriz factorizada. El tiempo de procesamiento que toma la factorización viene determinado por el cuarto paso, o sea, la factorización numérica de la matriz, el cual toma aproximadamente el 50% del tiempo total para el proceso in-core, es decir, sin usar la capa out-of-core. Los tres primeros pasos del proceso de factorizar tienen la ventaja que dependen del acceso secuencial de la matriz de entrada, lo cual significa que el nucleo out-of-core probado con las operaciones básicas de matrices presenta un comportamiento aceptable. El cuarto paso del proceso de factorización presenta dos problemas adicionales que forzaron un rediseño del núcleo

26 Figura 6. Operación del núcleo out-of-core. out-of-core existente. El primer problema lo constituyó el anidamiento de macros For OOCMatrix Row necesario por el algoritmo de factorización numérica segun se ve en la figura 8. Para realizar eficientemente este anidamiento se debe mantener en memoria el bloque que contiene al nodo rowi mientras que se carga en memoria el bloque que contiene al nodo rowj. Desde el punto de vista del diseño del nucleo out-of-core esto significó cambiar la organización de la caché para soportar múltiples vías para mantener el nodo rowi en una vía mientras que se cargan los distintos nodos rowj en la otra vía. El segundo problema lo representó el incremento en la tasa de fallos durante el proceso de factorización de la matriz que aumentaba el tiempo de ejecución por el alto costo del acceso a disco. Para resolver este problema se incorporó una Tabla de Predicción de Referencias (RPT), siguiendo el esquema planteado por [3], la cual determina el bloque a ser prebuscado en la caché. Para resolver el acceso concurrente de peticiones a la caché tanto para fallos como para prebúsquedas, se diseñó e implementó una Lista de Solicitudes Salientes (ORL) como una lista enlazada, partiendo del esquema planteado por [7]. Cada entrada de la lista enlazada contiene la siguiente información: un apuntador al slot (bloque dentro de la caché) que se desea actualizar; el tamaño del slot en memoria; un entero que indica el número de bloque en el archivo de disco (ver figura 4), este entero indica el nuevo bloque que se copiará al slot desde el disco; un entero que indica el bloque actual en el slot de la caché; un entero que indica el numero de bloque del slot de la caché, un entero que indica en cual vía de la caché está el slot; también existe para cada entrada un conjunto de banderas que señalan el estado actual de la entrada, ellas son: valid, indica si el slot actual se está actualizando o contiene datos válidos, dirty indica si los datos del slot actual deben copiarse a disco antes de ser actualizados, nouse indica si el slot actual contiene datos recien prebuscados que aun no han sido utilizados, lock indica si el slot actual no puede ser reemplazado porque esta siendo utilizado.

27 Tabla I USO DE MEMORIA Y TIEMPO DE EJECUCIÓN PARA LA FACTORIZACIÓN CHOLESKY. Matriz In-core Out-of-core Resultados % nodos NnzA NnzL memoria tiempo error memoria tiempo error memoria ovhd , 868 6, 39e , 800 6, 39e 13 16, , , 433 2, 52e , 113 2, 52e 12 4, 32 92, , 696 6, 58e , 215 6, 58e 12 3, 17 99, , 306 1, 35e , 383 1, 35e 11 2, , 37 Tabla II COMPORTAMIENTO DE LA PREBÚSQUEDA AL FACTORIZAR LAS MATRICES. Nodos Accesos Aciertos Aciertos(%) Fallos Prebúsquedas lecturas escrituras , , , for (ii= 0; ii< nn; ii++) { For_OOCMatrix_Row( GG, ii, rowi, READ_WRITE ) { for (kk= 0; kk< rowi.diag; kk++) { jj =[kk]; For_OOCMatrix_Row( GG, jj, rowj, READ ) { operaciones_1; } operaciones_2; } } } Figura 8. Anidamiento de macros. V. RESULTADOS Para evaluar el soporte out-of-core, todos los códigos se compilaron usando gcc x86_64 versión 4.3 con las banderas de optimización -O2 -funroll-loops -fprefetch-loop-arrays, ejecutándose sobre un procesador Intel Core TM 2 Duo P 8600, sistema operativo GNU/Linux, kernel SMP, los datos se almacenaron temporalmente en un disco SATA-3 TM W D5000BEV T, el cual tiene una latencia promedio de 5.5ms, una velociad del buffer al host de 3GB/s y una velocidad máxima de buffer a disco de 97MB/s, la memoria de intercambio está habilitada (swapon). El tiempo mostrado en las tablas es la suma del tiempo de usuario mas el de sistema que corresponden con el proceso de factorización simbólica mas el de factorización numérica y esta expresado en segundos. La tabla I muestra los resultados para la factorización Cholesky. La tabla tiene cuatro filas de datos que se corresponden con cuatro tamaños de matriz (8.000; ; ; ). Las matrices de prueba se generaron a partir de la discretización por diferencias finitas de una ecuación 3D escalar de convección-difusión [9] para tamaños de malla: , , y El lado derecho (vector b) del sistema lineal generado fue obtenido artificialmente suponiendo que la solución del sistema lineal es el vector (1, 1,..., 1) t. La tabla está dividida en cuatro secciones: Matriz, Incore, Out-of-core y Resultados. La primera sección se refiere a los detalles de las matrices dispersas, es decir, el número de nodos (N odos: filas en formato CRS) y total de elementos no-nulos de las matrices de entrada (NnzA) y salida (NnzL). La segunda sección contiene los resultados obtenidos sin el soporte out-of-core activado, es decir, memoria usada en bytes, tiempo medido en segundos y error relativo resultante en la resolución del sistema lineal. La tercera sección presenta los resultados cuando el soporte out-of-core está activado, es decir, memoria usada en bytes, tiempo medido en segundos y error relativo cometido en la solucion del sistema lineal. La cuarta sección compara los resultados sin y con el soporte out-of-core activado en términos de porcentaje de uso de memoria (memoria) y porcentaje de overhead en tiempo de ejecución (ovhd). Los ahorros de memoria muestran la fracción de memoria física que usa la implementación con la capa out-of-core en relación con el total de memoria física que necesita la implementación in-core. La penalización en tiempo se calculó como un incremento porcentual en el tiempo de ejecución que muestra la implementación cuando el soporte out-of-core está activado. La tabla II muestra el comportamiento del algoritmo de prebúsqueda durante el proceso de factorización numérica. La primera columna (Nodos) permite conocer a cual matriz se está haciendo referencia, la segunda (Accesos) se refiere al número de accesos a memoria del algoritmo, la tercera y cuarta hacen referencia al comportamiento de aciertos en forma absoluta y porcentual. La cuarta y quinta columna se refieren al numero de fallos y prebúsquedas. Las columnas siete y ocho se refieren a los accesos a disco. El total de accesos de lectura a disco es igual al número de fallos mas

28 el de prebúsquedas. Analizando los resultados en la primera tabla se puede apreciar que hubo ahorros significativos en el uso de memoria que varían entre un 83% (16, 33) para una matriz de entrada de nodos y 97% (2, 39) para una matriz de nodos; el ahorro en el uso de memoria se incrementa en porcentaje cuando se incrementa el orden de la matriz de entrada, lo cual resulta muy ventajoso porque permite factorizar matrices grandes usando máquinas con poca memoria. En relación al overhead ocasionado por la capa out-of-core, se tiene que está en un promedio del 100% con matrices de entrada de 8.000, y , pero desmejora hasta un 147% para la matriz de entrada de nodos. En referencia a los resultados presentados en la segunda tabla tenemos que el algoritmo de prebúsqueda tiene muy buen comportamiento ayudando a mantener la tasa de aciertos en un valor mayor al 99%. VI. CONCLUSIONES Y TRABAJOS FUTUROS El núcleo out-of-core presentado en este trabajo soporta eficientemente la factorización Cholesky de matrices dispersas porque muestra ahorros importantes de memoria con overheads menores del 148%. Para obtener un buen comportamiento de un soporte out-of-core consideramos que es importante tener un algoritmo de prebúsqueda de alta eficiencia, como el desarrollado en este trabajo, que pueda reducir el efecto adverso de la tasa de fallos de la caché. El algoritmo de prebúsqueda debe poder operar en paralelo con el cómputo para aprovechar la tecnología multicore presente en la mayoría de computadores personales actuales. Como trabajo futuros se propone incorporar mejoras en la paralelización del algoritmo de prebúsqueda para reducir la penalización en tiempo de ejecución, estudiar el efecto del tamaño del bloque del cache y tamaño de la caché (en número de bloques) con el objeto de definir heurísticas para la selección automática de estos parámetros, extender la utilización de la capa out-of-core a otras funciones de la biblioteca UCSparseLib, entre ellas, los métodos directos: LDL T, y LU e implementar la capa out-of-core para otros métodos de solución de sistemas lineales dispersos como los métodos iterativos y multinivel algebráico de la biblioteca UCSparseLib. AGRADECIMIENTOS El presente trabajo ha sido posible gracias al financiamiento del CDCH UC para los proyectos CDCH-UC No y CDCH-UC No REFERENCIAS [1] J. Castellanos and G. Larrazábal, Implementación out-of-core para producto matriz-vector y transpuesta de matrices dispersas, Conferencia Latinoamericana de Computación de Alto Rendimiento, Santa Marta, Colombia. Pags ISBN: , [2] J. Castellanos and G. Larrazábal, Soporte out-of-core para operaciones básicas con matrices dispersas, En Desarrollo y avances en metodos numéricos para ingeniería y ciencias aplicadas, Sociedad Venezolana de Métodos Numéricos en Ingeniería, Caracas, Venezuela. ISBN: , [3] T.F. Chen and J.L. Baer, A performance study of software and hardware data prefetching schemes, In International Symposium on Computer architecture, Proceedings of the 21st annual international symposium on Computer Architecture, Chicago Ill, USA, Pages , [4] Z. Bai, J. Demmel, J. Dongarra, A. Ruhe and H. van der Vorst, Templates for the Solution of Algebraic Eigenvalue Problems: A Practical Guide, SIAM, Philadelphia, [5] N. I. M. Gould, J. A. Scott and Y. Hu, A numerical evaluation of sparse direct solvers for the solution of large sparse symmetric linear systems of equations, ACM Trans. Math. Softw. 33,2, Article 10, [6] G. Karypis and V. Kumar, A Fast and Highly Quality Multilevel Scheme for Partitioning Irregular Graphs, SIAM Journal on Scientific Computing, Vol. 20, No. 1, pp , [7] D. Kroft, Lockup-free instruction fetchprefetch cache organization, In International Symposium on Computer architecture, Proceedings of the 8th annual symposium on Computer Architecture, Minneapolis, Minnesota USA, Pages 81-87, [8] G. Larrazábal, UCSparseLib: Una biblioteca numérica para resolver sistemas lineales dispersos, Simulación Numérica y Modelado Computacional, SVMNI, TC19 TC25, ISBN: , [9] G. Larrazábal, Técnicas algebráicas de precondicionamiento para la resolución de sistemas lineales, Departamento de Arquitectura de Computadores (DAC), Universidad Politécnica de Cataluña, Barcelona, Spain. Tesis Doctoral ISBN: , [10] D.A. Patterson and J.L. Hennessy, Computer Organization and Design: The Hardware/Software Interface, Morgan Kaufmann, Third Edition, [11] J. Reid, TREESOLV, a Fortran package for solving large sets of linear finite element equations, Report CSS 155. AERE Harwell, Harwell, U.K., [12] J. Reid and J. Scott, An out-of-core sparse Cholesky solver, ACM Transactions on Mathematical Software (TOMS), Volume 36, Issue 2, Article No. 9, [13] E. Rothberg and R. Schreiber, Efficient Methods for Out-of- Core Sparse Cholesky Factorization, SIAM Journal on Scientific Computing, Vol 21, Issue 1, pages: , [14] A.J. Smith, Cache Memories, ACM Computing Surveys, Vol 14, Issue 3, pages: , [15] S. Toledo, A survey of out-of-core algorithms in numerical linear algebra, In External Memory Algorithms and Visualization, J. Abello and J. S. Vitter, Eds., DIMACS Series in Discrete Mathematics and Theoretical Computer Science, 1999.

29 Universidad Católica de Colombia. Diaz Cesar, EXPERIMENTAL EVALUATION OF STRATEGIES FOR IMPLEMENTATION OF A GRID INFRASTRUCTURE IN A UNIVERSITY CAMPUS EVALUACIÓN EXPERIMENTAL DE ESTRATEGIAS DE IMPLEMENTACIÓN DE UNA INFRAESTRUCTURA GRID EN UN CAMPUS UNIVERSITARIO Diaz, Cesar Universidad Católica de Colombia Colombia Resumen This article focuses on the experimental analysis of implementation strategies, including clusters to a Grid infrastructure in a university campus. The best use in an educational institution due to its structure is the use of cluster technology for the use of homogeneous rooms and then the union of these clusters through Grid middleware. Performance tests were conducted with combinations of both Beowulf and Rocks machines as virtual machines dedicated to cluster, and Globus for the Grid. Índice de Términos Computación Grid, Clúster, sistemas distribuidos aplicados a un campus universitario. A I. INTRODUCCIÓN ctualmente las universidades se encuentran investigando como hacer buen uso de sus recursos computacionales. Universidades en el mundo encuentran problemas complejos de sus proyectos de investigación, generalmente, de sus estudiantes de postgrado y docentes investigadores [29]. Éstas instituciones han convergido a una solución: implementar, sistemas distribuidos como clúster y Grid, para la demanda de recurso computacional y resolver problemas complejos. Sin embargo, esta no es una tarea fácil; debido a su complejidad de implementación, entre otros la capacidad de los recursos y tareas a desarrollar. Se debe, por tanto, crear una estrategia para la implementación de una infraestructura Grid en un campus universitario y suplir la necesidad de cómputo que requieren sus programas de postgrado y proyectos de investigación. Ésta solución debe estar acorde a la tecnología que existe en un campus promedio en Bogotá, Colombia, su utilización y su desempeño. Una institución educativa, cuenta con computadores tanto para la parte administrativa, como con salas de cómputo para los estudiantes, éstas últimas, generalmente, con una configuración tanto de hardware como de software homogénea. Estos equipos, en la mayoría de los casos, se encuentran conectados en red, y en tiempos específicos, se encuentran inactivos. La idea con este artículo es presentar una evaluación de las tecnologías clúster y Grid como solución en una institución universitaria que requiera, para sus proyectos desarrollados por docentes y estudiantes de postgrado, la solución de problemas complejos que demanden un nivel de computación alto y consiga un aprovechamiento de los recursos disponibles en un campus universitario. A. Tecnologías Clúster: La computación basada en clusters surge gracias a la disponibilidad de microprocesadores de alto rendimiento más económicos, de redes de alta velocidad, y también gracias al desarrollo de herramientas de software para cómputo distribuido de alto rendimiento; todo ello frente a la creciente necesidad de potencia de cómputo para aplicaciones en las ciencias y en el ámbito comercial, así como de disponibilidad permanente para algunos servicios. Por otro lado, la evolución y estabilidad que ha alcanzado el sistema operativo GNU/Linux, ha contribuido de forma importante, al desarrollo de clustering [5] y Grid[19]. Tipos de clusters Clusters de alto rendimiento: este tipo surge frente a la necesidad de supercomputación para determinadas aplicaciones; lo que se busca es conseguir que un gran número de máquinas individuales actúen como una sola máquina potente [38]. Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

30 Universidad Católica de Colombia. Diaz Cesar, Clusters de balanceo de carga: este tipo de clúster permite que un conjunto de servidores de red compartan la carga de trabajo de sus clientes, buscando que los clientes lo vean como un único servidor. Al balancear la carga de trabajo en un conjunto de servidores, se mejora el tiempo de acceso y la confiabilidad [38]. Clusters de alta disponibilidad: conocidos también como "clusters de redundancia", permiten el mantenimiento de servidores que actúen entre ellos como respaldos de la información que sirven. La flexibilidad y robustez que proporcionan este tipo de clusters, los hacen necesarios en ambientes de intercambio masivo de información, almacenamiento de datos relevantes y donde sea necesaria una disponibilidad continua del servicio. Cuando el servidor vuelve a estar listo, se reincorpora y vuelve a formar parte del clúster [38]. B. Grid La primera vez que se nombro el término Grid, fue en 1910 aproximadamente, cuando la generación de energía eléctrica fue posible, el reto era trasmitirla y distribuirla a todos aquellos que la requirieran de una forma barata y óptima, de aquí se adopto el nombre de Electric Power Grid o en su traducción popular, malla eléctrica. Estos desarrollos previeron confiabilidad, acceso de bajo costo a un servicio estandarizado y universalmente accesible [6]. Por analogía, se adopta el término malla computacional para la infraestructura que sea capaz de aplicar en computación las características nombradas anteriormente. Una malla computacional es una infraestructura hardware y software que provee acceso fiable, consistente, pervasivo y barato a capacidades de cómputo alta [6]. Se conoce como la infraestructura a la malla computacional o computación en Grid que abarca ciclos de cómputo, datos, sensores o personas, dentro de los recursos que forman el Grid. Se prefiere que sea fiable, se desarrolla de diversos componentes que constituyen el Grid, componentes con diferentes propietarios y formas de acceder a ellos. Por esta razón, esta fiabilidad debe incluir el ancho de banda de la red, latencia, jitter, poder de cómputo, servicios de software, seguridad y confiabilidad. Que sea consistente, se refiere a aplicar estándares como los que se desarrollaron en la malla eléctrica, estándares de servicio que se puedan acceder con interfaces estandarizadas y operar con parámetros estandarizados, sin estos estándares es impráctico pensar en desarrollar aplicaciones que se interconecten y el uso pervasivo, uno de los retos de estandarizar es encapsular la heterogeneidad sin alterar la ejecución de alto desempeño. Por último el que sea pervasivo permite tener un acceso siempre disponible, sin importar en cual sea el ambiente en que se configure, obviamente teniendo en cuenta la capacidad de suscripción y acceso controlado, teniendo la posibilidad de un acceso universal [6]. La Computación en Grid (CG) es un sistema distribuido aplicado, diseñado para compartir en tiempo de ejecución recursos autónomos de cómputo los cuales se encuentran geográficamente distribuidos. Tiene como base los parámetros de diseño de cualquier sistema distribuido, disponibilidad, transparencia, desempeño, confiabilidad y escalabilidad, añadiendo a estos la búsqueda de un bajo costo. El termino Grid abarca conocimientos que van desde redes avanzadas hasta inteligencia artificial. Mucha de la literatura se refiere, antes de abarcar las tecnologías Grid, a si existe o no realmente un problema que justifique estas tecnologías de computación en Grid [3][5][11][12][18][19][20][21][25][32][45]. C. Estructura del artículo La siguiente parte del artículo está estructurada así: en la sección 2 se define el protocolo experimental, en la sección 3 se encuentra la implementación, experimentación y análisis de resultados, por último en la sección 4 están las conclusiones. II. PROTOCOLO EXPERIMENTAL El protocolo experimental se basa en dos acciones especificas: la selección, tanto del problema como de la tecnología clúster o Grid a utilizar y el protocolo de experimentación A. Fase de selección Selección del Problema a Resolver: Para seleccionar el problema a resolver, se debe tener en cuenta varios ítems. El primero es utilización de la máquina, que es, realizar varias operaciones para poder medir el rendimiento del procesador. El segundo es su facilidad para dividir el problema, esto es permitir resolver el problema de una forma entera o por rangos específicos y tercero es definido en un lenguaje compatible, significa que al implementarse no influya ni impacte en herramientas sub-utilizables. El problema que se plantea es verificar si un número es primo. Este tipo de problema permite subdividir el rango de números a evaluar, si el numero es primo solo es divisible por el mismo y por uno, obteniendo así la forma de evaluar dividiendo cada uno de los números del rango al número a evaluar. Selección tipo de clúster y Middleware de Grid: La tabla 1.0 muestra una comparación entre clúster y Grid, se plantearon diferentes aspectos resultando seis criterios importantes. TABLA 1.0. COMPARACIÓN CLÚSTER Y GRID Clúster Equipos homogéneos Sistema operativo único Administración y manejocentralizado (un solo equipo, maestro) Administración única (un solo programa) Los equipos están cercanos (mismo sitio) Objetivo: mejorar el rendimiento del sistema dedicando más recursos Grid Equipos heterogéneos Múltiples sistemas operativos Administración ymanejo descentralizado, (diferentes equipos) Administración múltiple (Varios programas, que se comunican entre sí) Los equipos están dispersos (diferentes sitios) Objetivo: mejorar el rendimiento del sistema compartiendo recursos subutilizados En la tabla 2.0 se muestra una comparación de los diferentes Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

31 Universidad Católica de Colombia. Diaz Cesar, tipos de clúster evaluados por diferentes criterios teniendo en cuenta sus ventajas y desventajas frente a la implementación escogida. De igual forma se realizo el tipo de Grid. TABLA 2.0. TIPOS DE CLÚSTER Y DE GRID. De acuerdo a los criterios de selección desarrollados en el proyecto, se determinó que el clúster 1 será el clúster Beowulf, implementado bajo la plataforma Condor. Por otra parte, se determinó que el clúster 2 será el clúster Rocks, implementado de dos formas: una en máquina dedicada y la otra en máquina virtual [7]. Para el middleware de Grid, Globus Toolkit, se identificó como una de las herramientas más completas, su documentación tanto de implementación, como de configuración, administración y uso, se encuentra en diferentes idiomas y ambientes de desarrollo. B. Protocolo de experimentación El protocolo experimental incluye una serie de pruebas controladas por las diferentes variables que a continuación se especifican, se realizaron las mediciones pertinentes para resolver el problema de si un número es primo. Considerando que el problema que se selecciono cumple fácilmente ser divisible para resolver por herramientas de clúster y por Grid. Variables independientes: Variable Número de máquinas TABLA 3.0 VARIABLES INDEPENDIENTES. Valores Posibles Número de trabajos Alto (10) Tamaño del trabajo Cluster Configuración Software Configuración Hardware. Variables dependientes: Bajo hasta 6 procesadores Medio hasta 12 procesadores Alto más de 20 procesadores Bajo (1) Alto (13 dígitos) Medio (12 dígitos) Bajo (11 dígitos) Cluster 1 (Condor) Cluster 2 (Rocks) Middleware de Grid (Globus) Homogéneo Heterogénea Grid Nombre Ventajas Desventajas Nombre Ventajas Desventajas Lclustering SO. + Poco amis. Legión Inv. Poco D. Beowulf commodit Conf. Hard Globus Grid Col. complejo Alchemi SO. Amis. Windows Unicore Medición Aleman Libra Scheduler GridBus GridBus Economy Poca impl. PlanetLab homogene HP GridBank Data. Economy Rocks Facil Impl. Formatea GridScape testbed No persis. Parallel Knoppix CD boot Sin disponibil. SGE Sun. Poco heterogene. OpenMosix BalanceL. No Grid. glite Clusy Grid complejo ClusterMatic NAMD No update Condor Clusy Grid Impl y conf. Se tomo una sola variable dependiente, ésta es el tiempo. Mide el tiempo de ejecución de un trabajo en milisegundos, conocido como tiempo de respuesta de una maquina o sistema (llámese clúster o Grid) de finalización de la tarea, a partir de esta variable se realiza un análisis, permitiendo calcular las siguientes variables: TABLA 4.0 VARIABLES DE ANÁLISIS Con respecto al sistema Con respecto a la tarea Coeficiente de rendimiento del sistema Utilización del sistema Rendimiento del procesamiento del sistema Tiempo de respuesta promedio del sistema Tiempo de respuesta promedio Utilización del procesador Tiempo de Espera A continuación se presenta la definición de cada una de las variables de análisis. Es importante resaltar que se llama sistema a cada una de las distribuciones clúster evaluadas al igual que el middleware de Grid escogido. Con respecto al sistema: Coeficiente de rendimiento del sistema (competitive ratio). Es la medida de rendimiento del sistema. Mide el rendimiento al ejecutar una tarea en un solo procesador o la misma tarea pero dividida en varios. Utilización del sistema (utilization). Se define como la fracción del tiempo en la cual el sistema fue utilizado. Sirve para medir la capacidad del sistema en resolver las tareas asignadas, es decir, ayuda a revisar cual sistema es más lento y como se comparan con los demás Rendimiento del procesamiento del sistema (throughput). Es el número de tareas finalizadas por unidad de tiempo en el sistema. Mide la capacidad del sistema en resolver tareas por segundo Tiempo de respuesta promedio del sistema (mean turnaround time). Es el promedio de finalización de todas las tareas desde que entran hasta que salen. De acuerdo a la tarea: Tiempo de respuesta. Es el tiempo de finalización de la tarea desde que entra hasta que sale. Es el mismo tiempo que se calculo anterior pero solo para una tarea en el sistema, se tomo la tarea baja. Utilización del procesador. Se define como la fracción del tiempo en la cual el procesador fue utilizado para desarrollar una respectiva tarea. Tiempo de espera. Está definido como el tiempo promedio de espera de las tareas antes de iniciar su ejecución. III. IMPLEMENTACIÓN, EXPERIMENTACIÓN Y ANÁLISIS DE LOS RESULTADOS Configuración Condor: Se tomo la configuración de Clúster Beowulf bajo la plataforma Condor figura 1.0, debido a la capacidad que tiene Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

32 Universidad Católica de Colombia. Diaz Cesar, este de enviar varios trabajos del mismo tipo sin necesidad de realizar mayores cambios; de igual forma, debido a la compatibilidad que generó al conectarlo con Grid. FIGURA 1.0 CONFIGURACIÓN CLÚSTER Los experimentos realizados se pueden observar en la tabla 5.0. Se realizaron los siguientes experimentos, teniendo en cuenta la nomenclatura descrita a continuación en la tabla 3.0 TABLA 5.0 NOMENCLATURA DE LAS PRUEBAS Número de Trabajos Nomenclatura 10 Alto NTA 1 Bajo NTB Tamaño del Trabajo 13 dígitos Alto TA 12 dígitos Medio TM 11 dígitos Bajo TB Configuración de HW Configuración Rocks: La otra configuración de clúster escogida fue Rocks. Esta se implementó de dos formas, una, en las máquinas de ASMA1 [8], de forma dedicada; bajo el sistema operativo propio de Rocks. Se implementó un frontend, con dos tarjetas de red y los nodos, los cuales se autenticaron y configuraron por medio de la red utilizando boot por PXE. La segunda forma de configuración de Rocks fue de forma virtual; se implementó en las máquinas de ASMA2 [4], sobre el sistema operativo Windows XP. Sin embargo la configuración de estas máquinas fue muy baja, la máquina virtual toma por defecto solo la mitad de la memoria RAM y estas máquinas poseían una RAM de 512MB como se menciono las variables intervinientes, tipo de máquina. Configuración Grid: En una sola máquina de ASMA1, cuyo hostname es master, se instaló: el SimpleCA sin autorización y autenticación por web, todo por via comandos, el GridFTP, el GRAM2, el RLS Replica Location Service y el MDS2 servicios de información, se instalo Globus Toolkit 4.2.1, sin servicios web La complejidad de instalación es supremamente alta, las dependencias y demás especificaciones de instalación hacen que se presenten conflictos y no dejan que la implementación sea completa. El tiempo aproximado para instalación de cada servicio depende de la experiencia del que la instala, un tiempo promedio de 1 mes por servicio HH. FIGURA 2.0 CONFIGURACIÓN GRID 12 procesadores Baja Alta BA 4 procesadores Baja Media BM 8 procesadores Baja- Heterogénea BH 24 procesadores Media Alta MA 12 procesadores Media Media MM 12 procesadores Media Heterogénea MH 50 procesadores Alta Media AM En la tabla 5.0 se muestra el tiempo de referencia calculado, es decir, el tiempo que toma terminar un respectivo tamaño de trabajo para cada uno de los tipos de máquina existentes en el proyecto. Esta experimentación se realizo cinco veces, tomando los valores medios y varianzas, llegando a un valor en común después de la tercera ejecución. El valor de la varianza (VAR 2,3ms) y de la media era el mismo después de la tercera ejecución. Los valores en la tabla 7.0 equivalen a estas medias TABLA 6.0 TIEMPOS DE RESPUESTA EN MILISEGUNDOS Experimentación: Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

33 Universidad Católica de Colombia. Diaz Cesar, Condor Rocks(P y VM) Globus CLUSTER 1 CLUSTER 2 GRILLA # de nodos 1 BA_TB_NTB BA_TB_NTA BA_TM_NTB BA_TM_NTA BA_TA_NTB BA_TA_NTA BM_TB_NTB BM_TB_NTA BM_TM_NTB BM_TM_NTA BM_TA_NTB BM_TA_NTA BH_TB_NTB BH_TB_NTA BH_TM_NTB BH_TM_NTA BH_TA_NTB BH_TA_NTA MA_TB_NTB MA_TB_NTA MA_TM_NTB MA_TM_NTA MA_TA_NTB MA_TA_NTA MM_TB_NTB MM_TB_NTA MM_TM_NTB MM_TM_NTA MM_TA_NTB MM_TA_NTA MH_TB_NTB MH_TB_NTA MH_TM_NTB MH_TM_NTA MH_TA_NTB MH_TA_NTA AM_TB_NTB AM_TB_NTA AM_TM_NTB AM_TM_NTA AM_TA_NTB AM_TA_NTA TABLA 7.0 TIEMPO DE REFERENCIA TAMAÑO DEL TRABAJO Asma Asma2 Sala A Rack Bajo Medio alto ,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 FIGURA 3.0 RENDIMIENTO DEL PROCESAMIENTO DEL SISTEMA Rendimiento del procesamiento del sistema 0, , , Clúster 1 Clúster 2 Grilla Rendimiento del procesamiento del sistema UTILIZACION PROMEDIO DEL SISTEMA Clúster 1 Clúster 2 Tomando en cuenta los criterios del sistema, los experimentos mostraron los siguientes resultados. En la figura 3.0, se observa la cantidad de tareas por segundo, en cada uno de los sistemas, es importante la relación que hay de diferencia del clúster 1 con todas las demás, este se debe a que se pudo implementar en todas las máquinas evidenciando así mayor rendimiento según cantidad de tareas. En la figura 4.0,. Se toma el tiempo máximo de utilización para cada sistema, donde exista la participación de las tres implementaciones, sin importar la cantidad de tareas ejecutadas. En la grafica 21.0 se puede observar la utilización poca de la Grid, debido a que no se realizaron todas las pruebas previstas en ella, en comparación con el clúster 1 y con el clúster 2. Con respecto a estos dos últimos se ve diferenciado que el clúster 1 toma menos tiempo en desarrollar las tareas que el clúster 2, es decir Beowulf bajo Condor utiliza menos tiempo la maquina que Rocks IV. CONCLUSIONES La implementación de una Grid en un campus universitario, conlleva a la utilización de equipos que se encuentran en sala y que deben mantener un servicio continuo por eso se plantean dos soluciones, 1) Utilizar la sala en horas de inactividad, esto se puede desarrollar de forma que cada equipo quede en dual boot y trabaje en horas nocturnas o fines de semana; 2) Con maquinas virtuales, en utilización activa, en este tipo de configuración puede trabajar incluso en uso la máquina. Se puede deducir que entre más grande sea el clúster, es decir más procesadores, mayor debe ser el trabajo a realizar, no es óptimo correr un trabajo donde la mayor parte del tiempo se consume es en la administración del mismo. La solución en máquinas virtuales se considera viable mientras la máquina que la hospede tenga una buena capacidad de RAM, en una de ellas se tenga posibilidad de dos tarjetas de red y la capacidad de disco, para esta máquina virtual sea de más de 25GB Para un campus universitario, donde se disponen de salas de computo para los estudiantes Grilla FIGURA 4.0 UTILIZACIÓN PROMEDIO DEL SISTEMA REFERENCIAS [1] Beowulf Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

34 Universidad Católica de Colombia. Diaz Cesar, [2] Rocks, [3] Ian Foster, Carl Kesselman, Globus: A Metacomputing Infrastructure Toolkit, 1996 [4] Globus consultada en el [5] Introducción a las tecnologías de clustering en GNU/Linux, [6] Ian Foster, Carl Kesselman, Computational Grids [7] Xianghua Xu Feng Zhou Jian Wan Yucheng Jiang, Quantifying Performance Properties of Virtual Machine Grid & Service Comput. Lab. Sch. of Comput. Sci. & Technol., Hangzhou Dianzi Univ., Hangzhou, [8] Máquinas dedicadas en la sala del grupo SIDRe, de la Pontifica Universidad Javeriana [9] Avellaneda Fabio, Análisis Comparativo de Arquitecturas Computacionales para la Simulación y Modelado Molecular en Bionanotecnología, PUJ, Grid Colombia: Una Forma de hacer Comunidad [10] I. Barcena, J. A. Becerra, C. Fernández et al. A Grid Supercomputing Environment for High Demand Computational Applications, Boletín de RedIRIS, nº 66-67, diciembre 2003-enero [11] Fran Berman, Anthony J., Geoffrey C., Grid Computing making the global infrastructure a reality, Edición Wiley, [12] Rajkumar Buyya, Luís Moura e Silva, Ira Pramanick. Cluster Computing volume 2. Prentice Hall, 1999 [13] Coulouris George, Dollimore Jean, Kindberg Tim, Sistemas Distribuidos, Conceptos y Diseño 3ra edición, Addison Wesley, [14] Charles Bookman, Linux Clustering: Building and Maintaining Linux Cluster New Riders Publishing, [15] Forrest Hoffman, Clustermatic: A Complete Cluster Solution. April 15th, 2005 [16] Diaz Cesar, Clusters Beowulf, Conferencia Universidad Manuela Beltrán, [17] Grupo de Física y Astrofísica computacional [18] Foster, I. and Kesselman, C. (eds.). The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, [19] Ian Foster, Carl Kesselman, Steven Tuecke, Anatomy of the Grid, The Grid A Blueprint for a new computing infrastructure. [20] Ian Foster Grid Technologies & Applications: Architecture & Achievements 2001 [21] Ian Foster, What is the Grid? A three points checklist Argonne National Laboratory & University of Chicago [22] Rajkumar Buyya, Srikumar Venugopal. The Gridbus Toolkit for Service Oriented Grid and Utility Computing: An Overview and Status Report [23] Srikumar Venugopal, Rajkumar Buyya, Lyle Winton. A Grid Service Broker for Scheduling Distributed Data- Oriented Applications on Global Grids [24] Global Grid Forum, Community Practice Documents, Global Grid Forum Documents and Recommendations: Process and Requirements. April, [25] Ian Foster, Carl Kesselman, Globus: A Metacomputing Infrastructure Toolkit, 1996 [26] pagina oficial consultada en el [27] pagina oficial consultada en el 2009 [28] Holguín Coral Andrés, Grid Uniandes, UNIANDES, Grid Colombia: Una Forma de Hacer Comunidad [29] Joshy Joseph, Craig Fellenstein, Grid Computing, Prentice Hall, [30] Kesselman C, Foster I, Jeffrey M. Nick, Steven Tuecke The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, 2002 [31] Marc Snir, Steve Otto, MPI The complete Reference Volume 1, the MPI Core MIT, [32] Larry Peterson, Tom Anderson, David Culler and Timothy Roscoe, A Blueprint for introducing disruptive technology into the Internet, 2002 [33] Viktors Berstis, Introduction to Grid Computing with Globus, IBM, Red Books. [34] Viktors Berstis, Fundamentals of Grid Computing, IBM, Red Books paper. [35] Red Hat Cluster Suite Configuring and Managing a Cluster Red Hat. [36] Rocks, [37] Sun One Grid Engine Adminsitration and User s Guide Sun Microsystems, [38] Shen, Z., et al., Distributed computing model for processing remotely sensed images based on grid computing. Information Sciences, (2): p [39] Joseph D Sloan, High Performance Linux Cluster with Oscar, Rocks, Openmosix and MPI, O Reilly, [40] Thomas Sterling, Beowulf Cluster Computing with Linux, MIT, 2ed, 2003 [41] Thomas Sterling, Beowulf Cluster Computing with Windows, MIT, 2002 [42] Thomas Sterling How to build a Beowulf, the MIT Press Cambridge, Massachusetts London, England, 1999 [43] Grid Computing in Taiwan Chao Tung Yang, William C. Chu, High Performance Computing Lab, Software Engineering and technology center, Department of Computer Science and Information Engineering, Tunghai University, 2004 [44] Andrew S. Tanenbaum, Maarten van Steen, DISTRIBUTED SYSTEMS Principles and Paradigms, Prentice Hall, [45] Jairo Duque, Universidad del Valle, Iteración multigrid para fenómenos de transporte en reactores MOCVD. [46] Mathilde Romberg, UNICORE: Beyond Web-based Job-Submission Research Center J ulich, Central Institute for Applied Mathematics, Germany, 2000 [47] Dietmar W. Erwin UNICORE A Grid Computing Environment. Forschungszentrum Jülich GmbH, Zentralinstitut für Mathematik (ZAM) Jülich, Germany. [48] Introducción a las tecnologías de clustering en GNU/Linux, [49] Zoltan Juhász, Distributed and parallel systems, cluster and Grid Computing, springer, Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

35 Universidad Católica de Colombia. Diaz Cesar, Cesar Orlando Diaz, es ingeniero eléctrico de la Universidad de los Andes, Magister en ingeniería Electrónica de la Pontificia Universidad Javeriana, se ha desempeñado como profesor universitario en las áreas de redes y sistemas distribuidos en diferentes universidades de Colombia. Actualmente es profesor de planta e investigador de la Universidad Católica de Colombia y docente de cátedra de la Pontificia Universidad Javeriana Conferencia Latinoamericana de Computación de Alto Rendimiento, CLCAR2009, Merida, Venezuela. 2009

36 Interaction of Access Patterns on dnfsp File System Rodrigo V. Kassick, Francieli Z. Boito, Philippe O. A. Navaux Universidade Federal do Rio Grande do Sul: Instituto de Informática Porto Alegre, Brazil {rvkassick, francieli.zanon, Abstract HPC applications executed in cluster environments often produce large quantities of data that need to be stored for later analysis. One important issue with the performance of these applications is the transport and storage of this data. To provide an efficient data storage facility, cluster systems may provide a Parallel File System in which applications can store their data. These systems aggregate disk and network bandwidth of several individual machines in order to improve the performance of data storage and retrieval. These storage systems are often shared by different applications running in the cluster environments in which they are deployed. Concurrent access to the storage service might influence the I/O performance of these applications due to spatial and temporal access patterns. This paper presents a study of interaction between some well-known access patterns over a NFS based parallel file systems. HPC; Parallel File Systems Keywords I. INTRODUCTION In the latest years, Cluster architectures have arise as the de-facto architecture for High Performance Computing (HPC) due to their versatility, scalability and low cost. Applications developed for such environments are usually distributed among the available nodes and employ message-passing mechanisms to perform communication among its instances. This need for communication led to the development and deployment of high performance networks in clusters, allowing faster communication and, as a consequence, better performance. In some situations, the application may need not only to exchange data among it s instances, but also store it on some permanent media. This may be needed for use in future executions, analysis of data using external tools, etc. For such cases, the use of a distributed file system (DFS) might be suitable. DFS s try to provide a large-space, high throughput storage area that can be accessed by a large number of clients like a cluster of computers. The tasks relative to data storage and management are distributed among a set of servers hence distributed file systems in order to increase data throughput and the system s scalability. Many distributed file systems have been studied and developed in latest years, like Lustre [14] and PVFS [5], [22]. While these systems use special protocols to allow the clients to communicate with the distributed servers, dnfsp [1] is a file system that aims to keep compatibility with standard NFS clients, while allowing dynamic server configuration and good I/O performance. When using a DFS, huge amounts of data must be transmitted between the clients and the servers. On the other hand, when different applications are executed concurrently on the same cluster, using the same shared parallel file system, their behavior regarding the usage of the common storage area will affect each other. One common behavior of a parallel application is to have alternate CPU-bound phase in which it generates data and an IO-Bound phase in which it will flush this data to the storage subsystem. In such cases, there will be a relatively constant time between two consecutive I/O phases during which the node will be processing the data read or to be written. During such time, other clients might be doing their own I/O operations This paper studies the behavior of the I/O performance of two concurrent applications executing over the same shared set of storage nodes using dnfsp. We utilize two groups of tests to evaluate this behavior. The first one evaluates the impact of different sized applications running concurrently. The second one simulates the bursty I/O phases separated by idle periods, commonly observed in HPC applications that generate a great amount of output data. The paper is divided as follows: Section II presents related works. Section III gives a brief overview of the temporal access patterns used in the tests. Section IV presents dnfsp, the distributed file system we used for our experiments. In Section V we present the tests and the test-environment used. Section VI presents the results and draws some conclusions on them. Finally, in Section VII we present our conclusions.

37 II. RELATED WORK Parallel file systems are solutions that have been long studied in the area of HPC. Systems like Bigfoot-NFS [11], Vesta [6] and the Zebra File System [10] are early examples of the distributed I/O systems. More recently, systems like GPFS [17], Lustre [14] and PVFS [5] have been developed with improved protocols, management tools and access API s to improve I/O performance and became widely used in large HPC cluster. Several works have studied the I/O performance of parallel applications with different access patterns on this kind of system. Nieuwejaar et al [15] used traces from different I/O workloads to understand the performance of two HPC architectures. Their main goal was to discover the common trends seen in the workloads and understand what performance characteristics were influenced by architecture-specific characteristics. Seelam et al [18] used a similar approach in the BlueGene architecture and used the information obtained to improve performance of the BTIO benchmark [21], [2] over the GPFS file system. Tran and Read [19] studied temporal access patterns present in HPC applications and developed a system able to detect the bursty I/O periods of an application and adjust the system s pre-fetching policies to improve performance. In Oly et al [16], detection of spacial access patterns of distributed applications was used to fine-tune pre-fetching mechanisms in the file system, adapting the file system to specific I/O necessities. More recently, Byna et al [4] studied the guided pre-fetching for a parallel file system based on access characteristics from the application. In this work, on the other hand, information about such characteristics was extracted from high-level I/O API s like MPI-IO. Gu, Wang and Ross [9] studied a mechanism for data grouping and pre-fetching on the PVFS file system. In their prototype, this grouping took place only during idle intervals on the I/O server to avoid competition clients I/O requests. This strategy, while profiting from spacial distribution of data to improve performance, relied on temporal access patterns from the application to allow the system to reorganize data without severely impacting I/O performance of running applications. These works focus on the behavior and performance of a single application over the distributed storage. In this paper, we study the I/O performance of applications running concurrently on a shared DFS and how the performance of one influences the performance of the other. III. TEMPORAL ACCESS PATTERNS Scientific applications usually need access to large data sets used as input and, after processing such input, generate a considerable amount of data that may be written to a high performance storage system. This access to the data may happen in several ways, according to the needs of the applications and the choices made during the development. Applications may read portions of the input a they finish processing previously accessed data, as in the case of mpiblast, a MPI-based parallel implementation of BLAST, for genomic sequence search [12], [7]. Input data may also be accessed only during the process-creation phase, so all the computation is done over an initial dataset. The output, in this case, may be generated along the whole execution. This is the case for ESCAT, a parallel implementation of the Schwinger Multichannel method for study of low-level electron-molecule collisions [20]. Some application may choose to write a partial results from time to time, creating an execution checkpoint that can be later recovered to continue a simulation, as in Flash, a code for astrophysical simulations [8]. In such cases, access to the file system may be bursty during some periods of time, followed by periods of few or no activity at all from the nodes of an application. To the history of the periods of I/O of an application is given the name temporal access pattern of the application. Figure 1 shows an access-trace taken from dnfsp while a synthetic benchmark executed writes to the file system followed by pre-defined idle time. Each cross indicates a request sent from one client to the file system. While the client with id 1 performs few accesses to the storage system, other clients present bursts of I/O requests separated by intervals in which the application executes other activities. This trace presents an example of an application with a well-defined temporal access pattern (I/O, followed by a constant idle time) as seen from the point of view of the file system being used. Although requests are generated in a regular fashion on the clients, their reception and processing on the I/O servers will be less regular. With this in mind, it becomes important to study how much other applications may profit from the idle intervals on the server to perform their own I/O requests with better performance. When more then one application shares the storage system, such temporal patterns may influence the I/O performance of all the applications in execution. Applications with a large I/O inactivity time may have little influence over the overall performance of the system while long-running I/O-bound applications may degrade the performance of applications less data-intensive.

38 4 3 Client ID Time (ms) Figure 1. I/O Requests over time on the dnfsp file system Client Client Client Client read file a.bcd Meta server Meta server IOD IOD IOD read block data Figure 2. dnfsp Architecture IV. DNFSP dnfsp distributed NFS parallel is an extension of the traditional NFS implementation that distributes the functionality of the server over several processes on the cluster. The idea behind dnfsp is to improve the performance and scalability and, at the same time, keep the system simple and fully compatible with standard NFS clients. Similarly to PVFS, dnfsp makes use of I/O daemons IOD s to access data on the disks. The role of the NFS server is played by the meta-data servers meta-servers. These are seen by the clients as regular nfsd servers; when a request for a given piece of data is received, the meta-server forwards the request to the corresponding IOD to perform the operation and answer to the client. dnfsp distributes the meta-server function onto several computing nodes. The I/O daemons are shared by all meta-servers. However, each meta-server is associated to only a subset of the clients. When using dnfsp, if all the clients access the file system at the same time, the load will be distributed among the meta-servers. This is specially important in write operations, since clients send whole data blocks to the meta-servers. Figure 2 illustrates a typical read operation in dnfsp. The client sends a normal NFS read request to its associated meta-server. The meta-server then forwards the request to the IOD storing that piece of the file. After processing the request, the IOD answers directly to the client. Write operations follow the same process, but since the whole block of data needs to be sent from the client to meta-server and then to IOD, the double copy makes this operation significantly slower than read ones. The synchronization of the meta-servers is done via an LRC 1 based algorithm, in which data is updated in one node only when it needs access to it. The employment of LRC allows nodes to have outdated information, leaving the system partially unsynchronized. Meta-data information for each file is assigned to an specific meta-server via a hashing function. The designed meta-server will be responsible for keeping track of the changes done to this specific file and every time other server needs up-to-date information, it will request a copy of the meta-data for this server. V. TWO-FOLD APPLICATION INTERACTION ON DNFSP The temporal access patterns of applications running concurrently on a cluster might influence their I/O performance. It s important to comprehend this interaction on the dnfsp file system due to the inherent lower performance of write 1 Lazy Release Consistency

39 operations. It s also important to understand the point at which this influence becomes visible to other applications. To study the performance of dnfsp under the load from applications with distinct behaviors, we executed two sets of tests using MPI-IO Test 21[13]. This synthetic benchmark uses MPI and MPI-IO to simulate an application writing an specified number of objects of a given size. The tests are constituted of two instances of the benchmark, called foreground and the background respectively, over a shared dnfsp system. The performance of the foreground test was measured as the configuration of the background test changed. This allows us to evaluate the interference of the I/O behavior of the background instance over the foreground. We evaluated two different scenarios with this approach. In the first one, we executed the two instances of the test concurrently over independent sets of clients, changing the number of nodes involved in the I/O. The objective of this test is to evaluate the performance of an IO-bound execution under the influence of concurrency in the shared system and how dnfsp scales over to independent sets of nodes. The second scenario evaluates the I/O performance of the two instances of the test on the presence of different temporal access patterns. The foreground instance executes a modified version of MPI-IO Test 21 that allows configuring a time to wait between reading or writing two objects. This wait time simulates the time that a real application would spend operating over the data stored in the file system. Both instances are executed during a fixed time to make sure that both are making concurrent access to the file system. During this period, both applications write as many objects as the execution time allows them to. The tests were executed on the Pastel cluster, part of the Toulouse site of Grid5000 [3]. All the nodes are equipped with AMD Opteron processors of 2.6GHz, 8Gb of RAM and 250GB SATA hard disks. The nodes are interconnected by a Gigabit Ethernet network. dnfsp was configured with 6 nodes, each acting as both meta-server and IOD. 24 nodes acted as clients, being evenly distributed among the meta-servers. These nodes were divided in two sets, each executing an instance of the benchmark. When all clients make use of the file system, each meta-server is responsible for the requests of at most 4 clients. Each configuration of the tests was executed 6 times. The bandwidth presented in the graphs is the average write bandwidth taken from these executions. VI. RESULTS In this section we present the results obtained with the benchmarks described in the previous section. Each section describes the results obtained in one of the scenarios described previously. A. I/O Bound Applications Interaction In this test, the objective is to evaluate the performance of the foreground instance of the benchmark for different number of nodes both in the foreground and background instances. Figure 3 presents the write bandwidth of the foreground instance of the benchmark. Each line represents the bandwidth for a given number of nodes in foreground. The X-axis represents the number of nodes used in the background instance of the benchmark. Figure 3a shows the results for when the number of objects of the benchmark is constant per node - i.e., the more nodes executing the benchmark, the more data is generated in the file system. In figure 3b, the number of objects written by each node was set as to generate the same final amount of data. For this test, object size was set to 128Kb. For the constant number of objects case, the number of objects was set to 1024, resulting in 128Mb for each node. In the second case, the total amount of data was set to 1Gb for each application. The results indicate that an application with few nodes performing intensive I/O do not suffer significantly with the interference of other applications. For the 2-processors foreground instance, the performance fell from 25.75M b/s to 17.83Mb/s (69%) when the number of processors in the background ranged from 2 to 12 in (a) and from 24.99Mb/s to 24.32Mb/s (97%) in (b). The total bandwidth of the file system (bandwidth from both instances), on the other hand, went from 51.49Mb/s to Mb/s in (a) and 49.82Mb/s to Mb/s in (b). This stability in the performance of the small-sized benchmark is mainly due the NFS client-side caching policies. Even on bursty I/O phases, the write operations are delayed on the client, avoiding that they make full use of the available bandwidth on the file system. This way, the background instance of the benchmark can scale in size, improving it s performance and the overall performance of the system. As the foreground benchmark size grows, sensibility to concurrency begins to stand out more clearly, as we see the bandwidth fall from 109M b/s to 76.87M b/s for 12 processors in case (a). While the absolute difference becomes more noticeable, the fall ratio from 2 to 12 is close to 70% for all cases in (a). The same does not happen when the total data size is constant: the ratio ranges from 97% for foreground with 2 processors to 66% for 6 and 74% for 12. Since more clients perform better on dnfsp and the amount of data per node decreases with

40 MB/s MB/s Number of Processors on background execution Number of Processors on background execution (a) Constant Number of Objects (b) Constant Total Data Generated Figure 3. Interaction between two identical applications with different number of nodes MB/s Baseline Combined Number of Processors on background execution Figure 4. Baseline and Combined Bandwidth for 12-Clients-Foreground and Background Instances the higher number of nodes, the execution time decreases with the growth of the benchmark. This way, the slice of time in which both instances are executed concurrently gets smaller as the number of nodes of each instance diverge. This explains the higher bandwidth obtained with this case. The results also presented sensibility to the alignment of nodes over the meta-servers. Since the distribution of clients over the file system is static, different number of clients on different applications may result in a few overloaded meta-servers. This can be observed in Figure 3a for foreground with 6 and 12 clients: when background has 6 clients, the number of clients in each meta-server is the same. As the number of clients in the background instance grows to 8, the distribution gets unbalanced and the performance has a more significant drop. Figure 4 shows the combined bandwidth of the two instances of the benchmark for case (a) with 12 clients in the foreground instance. This combined bandwidth is combined with a baseline execution, i.e. the bandwidth from an execution of MPI-IO Test 21 with the same number of nodes as the two instances of the concurrent benchmark would have. As we can see, the baseline bandwidth grows more rapidly until it has 18 clients (3 clients per meta-server). After that, it continues growing at a smaller rate. Since the clients in the baseline execution are evenly distributed along the meta-servers, the performance does not suffer from alignment problems. The combined bandwidth, on the other hand, drops after the number of clients gets too unbalanced, reaching the same performance as baseline once a good alignment is reached once again (24 clients, 4 per meta-server). These results show that, while dnfsp is able to scale the overall bandwidth of the system on the presence of concurrent applications, the performance may be negatively influenced by bad client-to-server alignment.

41 B. Temporal Pattern Interaction The objective of this test is to study the bandwidth of both instances of the benchmark in the presence of a well-defined temporal access pattern. While the background instance executes the standard benchmark, the foreground instance was configured to wait a predetermined amount of time between it s I/O operations. Figure 5 shows the performance for the I/O portion of the benchmark under different time intervals. The X-axis represents the amount of time that the foreground instance spends before writing each of it s objects. The tests were executed with object sizes of 128Kb, 2Mb and 4Mb, to allow us to study the relation between the amount of data written to the amount of I/O idle time. The foreground and the background instances of the benchmark were executed with 12 clients. This graph only presents the I/O bandwidth, not including the time spent in between writes. As we see in Figure 5a, with intervals ranging from 10 to 500ms, the write bandwidth for the tree object sizes remained seemingly constant. The 128Kb object size apparently takes better advantage of the client s caching subsystem, since it outperformed the cases with greater write-unit size. As the interval reaches 5 seconds, bigger object-sizes have a significant decrease in performance, while the small object-size case manages to keep close to the original performance. In Figure 5b, we see the performance of the background instance of the benchmark. Since this instance does not wait for the specified interval, it profits from the idle times in the foreground instance. With 128Kb size objects, the background instance has a significant performance improvement with the increase in the interval. This is due to the very short I/O bursts from foreground, leaving the system free to process the requests from the background. For 2Mb and 4Mb sized objects, on the other hand, I/O bursts from the foreground instance are longer, and even with long periods of exclusiveness, the background instance gets a more modest increase in it s write bandwidth Bandwidth (Mb/s) Kb 2Mb 4Mb Wait time (ms) (a) Foreground Figure Wait time (ms) Bandwidth for different wait times (b) Background One question that arises from these tests is how much the bandwidth of the two instances diverge with the different intervals and what s the point in witch this difference starts to get more noticeable. Figure 6 shows the write bandwidth for the foreground and background instances of the benchmark and their combined bandwidth for objects sizes of 128Kb, 2Mb and 4Mb. Immediately below to each case is the time ratio for the foreground instance, i.e. the ratio between the time spent on I/O over the total execution time, including the waits. As seen in Figure 6a, the bandwidth for both instances is very close for intervals of 1 and 10ms, diverging for larger intervals. The time ratio is 0.9, 0.74 and 0.41 for intervals 1, 10 and 50ms respectively. In Figure 6b, the divergence started with intervals of 500ms, when time ratio dropped from 0.87 to Figure 6c shows that with 4Mb sized objects, divergence starts at the same point as with 2Mb, with ratio dropping from 0.93 in 100ms to 0.74 in 500ms. This leads us to infer that the minimum time ratio in which both instances will still have similar performances is proportional to the size of the objects. This is due to the relation of the wait interval to the amount of data written after it. With small sized objects, the idle interval can become significantly longer than the time to write one single object. Since such interval happens between writing two objects, the total execution time becomes dominated by the idle time and the ratio tends to fall more quickly with longer intervals. With bigger sized objects, small idle times are less significant to the total execution time and so the ratio takes longer to fall.

42 Nonetheless, with the increase of the idle time, the background will profit from higher bandwidth availability during such periods of inactivity and, as a result, will increase it s I/O bandwidth. The reason for the decrease in the bandwidth of the foreground instance with the longer intervals, as seen for object sizes of 2 and 4Mb remains to be studied. The results show that dnfsp suffers some contention in the presence of temporal access patterns. Combined bandwidth for 128Kb sized objects was shown in Section VI-A to reach up to 150Mb/s, but was shown to peak only 106Mb/s in these tests. This degradation was seen both in the foreground and background instances of the benchmark. The lower performance in the foreground was expected, since it would do bursty requests to an already overloaded file system and the idle times could influence the production of ready-to-send NFS requests in the client s cache. Since the background instance also had a lower performance (by the tests shown previously, the background was expected to reach around 80Mb/s), we can affirm that the dnfsp servers themselves are influenced by the presence of the temporal access pattern MB/s Foreground Execution 1 Background Execution 2 Combined Combined Bandwidth Bandwidth Ratio 0, (a) 128Kb 0, (b) 2Mb 0, (c) 4Mb Time Ratio Figure 6. Bandwidth Divergence and Time Ratio VII. CONCLUSIONS AND FUTURE WORK In this paper, we have shown the behavior of dnfsp file system when two different applications make heavy use of it. We have tested two distinct scenarios that we considered relevant to the use-cases where dnfsp might be employed. The results for the first scenario indicate that the performance for an individual application is affected by the execution of other applications over the shared system, but that performance for the whole file system was not degraded by the individual executions. The results also highlighted the performance issues when there were uneven distribution of clients over the servers, decreasing the combined bandwidth of the system due to the overloaded servers. For the second scenario, we could observe that long idle I/O periods in one application allowed for increased I/O performance in a concurrent execution. On the other hand, the performance for both applications was below the performance observed in the first scenario, indicating that dnfsp suffer deterioration as a whole with the spaced bursty I/O periods. We also could observe that the time ratio at which the performance of both applications diverge is proportional to the size of the objects written in the system. REFERENCES [1] R. B. Ávila, P. O. A. Navaux, P. Lombard, A. Lebre, and Y. Denneulin. Performance evaluation of a prototype distributed NFS server. pages [2] D. H. Bailey. The NAS parallel benchmarks. International Journal of Supercomputer Applications, 5(3):63 73, [3] R. Bolze, F. Cappello, E. Caron, M. Dayde, F. Desprez, E. Jeannot, Y. Jegou, S. Lanteri, J. Leduc, N. Melab, G. Mornet, R. Namyst, P. Primet, B. Quetier, O. Richard, E.-G. Talbi, and I. Touche. Grid 5000: A large scale and highly reconfigurable experimental grid testbed. International Journal of High Performance Computing Applications, 20(4): , [4] S. Byna, Y. Chen, X.-H. Sun, R. Thakur, and W. Gropp. Parallel i/o prefetching using mpi file caching and i/o signatures. In SC 08: Proceedings of the 2008 ACM/IEEE conference on Supercomputing, pages 1 12, Piscataway, NJ, USA, IEEE Press.

43 [5] P. H. Carns, I. I. I. Walter B. Ligon, R. B. Ross, and R. Thakur. Pvfs: a parallel file system for linux clusters. In Proceedings of the 4th conference on 4th Annual Linux Showcase and Conference (ALS 00), pages 28 28, Berkeley, CA, USA, USENIX Association. [6] P. F. Corbett and D. G. Feitelson. The vesta parallel file system. ACM Trans. Comput. Syst., 14(3): , [7] A. E. Darling, L. Carey, and W.-C. Feng. The design, implementation, and evaluation of mpiblast. In In Proceedings of ClusterWorld 2003, [8] B. Fryxell, K. Olson, P. Ricker, F. X. Timmes, M. Zingale, D. Q. Lamb, P. MacNeice, R. Rosner, J. W. Truran, and H. Tufo. Flash: An adaptive mesh hydrodynamics code for modeling astrophysical thermonuclear flashes. The Astrophysical Journal Supplement Series, 131(1): , [9] P. Gu, J. Wang, and R. Ross. Bridging the gap between parallel file systems and local file systems: A case study with pvfs. In Parallel Processing, ICPP th International Conference on, pages , Sept [10] J. H. Hartman and J. K. Ousterhout. The zebra striped network file system. ACM Trans. Comput. Syst., 13(3): , [11] Kim, G. H. Kim, Minnich, and McVoy. Bigfoot-nfs: A parallel file-striping nfs server (extended abstract), [12] H. Lin, X. Ma, P. Chandramohan, A. Geist, and N. Samatova. Efficient data access for parallel blast. In Parallel and Distributed Processing Symposium, Proceedings. 19th IEEE International, pages 72b 72b, April [13] Los Alamos National Laboratory (LANL). MPI-IO Test 21, Available in [14] S. Microsystems. Lustre file system. White Paper, Available in lustrefilesystem wp.pdf. [15] N. Nieuwejaar, D. Kotz, A. Purakayastha, C. S. Ellis, and M. L. Best. File-access characteristics of parallel scientific workloads. IEEE Trans. Parallel Distrib. Syst., 7(10): , [16] J. Oly and D. A. Reed. Markov model prediction of i/o requests for scientific applications. In Proceedings of the 16th international conference on Supercomputing (New. ACM Press, [17] F. Schmuck and R. Haskin. Gpfs: A shared-disk file system for large computing clusters. In FAST 02: Proceedings of the 1st USENIX Conference on File and Storage Technologies, page 19, Berkeley, CA, USA, USENIX Association. [18] S. Seelam, I.-H. Chung, D.-Y. Hong, H.-F. Wen, and H. Yu. Early experiences in application level i/o tracing on blue gene systems. Parallel and Distributed Processing, IPDPS IEEE International Symposium on, pages 1 8, April [19] N. Tran and D. A. Reed. Arima time series modeling and forecasting for adaptive i/o prefetching. In Proceedings of the 15th international conference on Supercomputing (ICS 01), pages , New York, NY, USA, ACM. [20] C. Winstead, H. Pritchard, and V. McKoy. Parallel computation of electron-molecule collisions. IEEE Comput. Sci. Eng., 2(3):34 42, [21] P. Wong and R. F. Van der Wijngaart. NAS parallel benchmarks I/O version 2.4. Technical Report NAS , NASA Advanced Supercomputing (NAS) Division, Moffett Field, CA, Jan [22] Y. Zhu, H. Jiang, X. Qin, D. Feng, and D. R. Swanson. Design, implementation and performance evaluation of a cost-effective, fault-tolerant parallel virtual file system. International Workshop on Storage Network Architecture and Parallel I/Os, held with 12th International Conference on Parallel Architectures and Compilation Techniques, 2003.

44 Legión - Sistema de Computación en Grid Legion - Grid Computing System Genghis Ríos Kruger Pontificia Universidad Católica del Perú, Dirección de Informática Académica Martín Iberico Hidalgo Pontificia Universidad Católica del Perú, Dirección de Informática Académica Oscar Díaz Barriga Pontificia Universidad Católica del Perú, Dirección de Informática Académica Abstract It is not often possible to acquire a large computing infrastructure dedicated to the execution of computationally intensive applications within university environments in developing countries due to their high cost. Drawing on the resources available in the computer labs of universities themselves, the problem can be solved by implementing a Desktop Grid Computing. This document shows the Legion System, which allows you to manage multiple projects using computer-intensive Desktop Grid Computing implementation raised by the BOINC infrastructure. With the solution implemented in Legion, researches in different areas will have access to broad existent computacional resources inside university campuses, through a web user interface, hidding the complexity of the grid computing system to the end user. 1. Introducción La computación en grid tiene sus orígenes a principios de los años 80 s, donde la investigación intensiva en el campo de la algoritmia, la programación y arquitecturas que soportan paralelismo, provocaron que los primeros éxitos en este campo ayuden a otros procesos de investigación en diversas áreas. A esto último se agrega el exitoso uso de la computación grid en la ingeniería y en el campo empresarial [1], permitiendo la ejecución de procesos en múltiples equipos, pudiendo tener cada uno de ellos características heterogéneas, sin la necesidad de estar ubicados en ambientes dedicados. Durante los últimos años, se han enfocado los esfuerzos en la investigación y desarrollo de protocolos, servicios y herramientas que facilitan la implementación de sistemas en grid escalables [9]. Entre las principales implementaciones tenemos a Condor y BOINC, como sistemas de gestión de trabajos, y a Globus Toolkit, como un conjunto de módulos independientes [10] elaborados para el desarrollo de servicios orientados a las aplicaciones de computación distribuida [11]. La infraestructura BOINC [2], Berkeley Open Infrastructure for Network Computing por sus siglas en inglés, surge con la finalidad de aprovechar la donación voluntaria de recursos de computadores de escritorio distribuidos alrededor del mundo, donde los usuarios brindan un porcentaje de dichos recursos a investigaciones científicas de todo tipo. Además, BOINC plantea su uso como una Desktop Grid, donde se realiza el aprovechamiento de recursos computacionales localizados en ambientes supervisados o controlados, dentro de una organización en particular.

45 Conforme pasa el tiempo, se tiene una mayor cantidad de aplicaciones computacionalmente intensivas, por lo que en muchos casos se hace necesario de una infraestructura de hardware muy costosa. Una posible solución se encuentra en el uso de Desktop Grid Computing, que permite el aprovechamiento de recursos disponibles en ambientes controlados locales o cercanos, siendo para nuestro estudio, computadores ubicados en los laboratorios dentro de un campus universitario. El objetivo principal del trabajo realizado es canalizar esta capacidad de procesamiento hacia proyectos de investigación computacionalmente intensivos, realizando un manejo eficiente de la infraestructura existente dentro de laboratorios informáticos, y motivando a investigadores a realizar estudios más ambiciosos. 2. La infraestructura BOINC BOINC es una plataforma de código abierto que permite a diversos proyectos hacer uso de capacidad computacional ociosa la cual proveniente de computadores ubicados alrededor del mundo de manera voluntaria. Una computadora ejecutando el cliente BOINC puede realizar peticiones al servidor BOINC en busca de tareas disponibles y, si las encuentra, empieza a trabajar para el proyecto al cual se ha unido procesando los datos asociados. El cliente BOINC puede ser limitado en la cantidad de recursos computacionales que puede utilizar, priorizando las necesidades del usuario que utiliza el computador. En el presente caso los usuarios de los laboratorios no deben percibir cambios en el rendimiento del equipo. La flexibilidad y control que permite el cliente BOINC sobre los recursos donados hacen que la infraestructura BOINC sea adecuada para implementar la solución planteada. Con BOINC el proceso general se divide en tareas pequeñas llamada workunits. Tales tareas deben ser independientes unas de las otras en cuanto a secuencia de procesamiento, lo que se conoce como paralelismo perfecto [3]. Entre las características más importantes de BOINC, relacionadas con la implementación de la solución en este proyecto, tenemos: Autonomía de Proyectos: Varios proyectos independientes pueden definirse en el servidor BOINC. Administración de Recursos: Cada uno de los clientes BOINC puede participar en múltiples proyectos, permitiendo configurar la cantidad de recursos asignados a cada uno de éstos: cpu, ram, espacio en disco, velocidad de red. Disponibilidad de Recursos: El cliente BOINC se pueden configurar para disponer permanentemente de la capacidad de procesamiento de la computadora anfitriona, esté o no siendo utilizada por sus usuarios habituales. Multiplataforma: Disponibilidad del cliente BOINC para múltiples plataformas: Windows, Linux y Mac OS X. 3. La Arquitectura Legión A diferencia de la implementación tradicional de BOINC, utilizada como plataforma de encolamiento y distribución de workunits, el Sistema Legión es un desarrollo propio destinado a la administración a alto nivel de usuarios y proyectos, automatizando los procesos de generación y recopilación de tareas, así como el control de computadores cliente. La arquitectura está formada por: La plataforma BOINC, como aplicación base. Base de datos en MySQL para la administración de usuarios, computadoras, proyectos y tareas. Servidor de archivos web en Apache para almacenamiento de los resultados de cada tarea. Aplicaciones en PHP para la interfaz web de usuario.

46 Aplicaciones en C++ para la generación de workunits y resumen de los resultados. Herramientas en java para el mantenimiento y administración de los computadores. Figura 1. La Arquitectura Legión Una característica particular de la computación en grid es que los equipos que la conforman no son necesariamente computadores dedicados. Esta propiedad, denominada pertenencia dinámica, implica que cualquier equipo puede adherirse o abandonar una determinada grid en tiempo de ejecución. Además un equipo que forme parte de una determinada grid no implica que deje de ser operativo para cualquier otro tipo de tarea, pudiendo seguir siendo utilizado por sus usuarios habituales [6] Interfaz Web Es la interfaz que permite el acceso de múltiples usuarios a múltiples proyectos, que forman parte del Sistema Legión, vía web. Esta interfaz fue desarrollada utilizando el lenguaje de programación PHP, requiriendo en algunos casos, el uso de técnicas de programación AJAX vía el framework Prototype [4], para indicar el progreso o avance de ejecución de una tarea. La interfaz permite a los usuarios la generación y observación automática de diversas tareas que les son permitidas, además de la finalización de éstas para la posterior descarga del resultado respectivo. En la mayoría de los casos la interfaz es única para cada proyecto, dado que muchos de los parámetros de creación de las tareas son específicos al proyecto correspondiente Interfaz Generadora de Tareas Es la aplicación en C++ encargada de la generación automatizada de workunits. Utiliza la función create_work, propia del API de BOINC, para invocar al demonio Work Generator propio de BOINC (ver Figura 1) Interfaz Servidor - Cliente Es un conjunto de aplicaciones realizadas en Java, que permiten comunicar al servidor Legión con los computadores clientes a través de BOINC RPC. De este modo los computadores pueden realizar peticiones forzadas de tareas hacia el servidor, minimizando el tiempo muerto de espera de las peticiones de tareas provenientes desde los clientes BOINC Administración de computadores cliente El uso de una Desktop Grid implica la necesidad de administrar, de forma automática

47 y remota, los múltiples computadores que forman o formarán parte del grid. Debido a esto, se han desarrollado una serie de herramientas que permiten interactuar con los computadores a través de BOINC RPC. Dichas herramientas permiten realizar acciones remotas sobre los computadores cliente, como unirse a un proyecto, suspenderse, no solicitar más tareas, separarse de un proyecto, etc. Figura 2. Flujo de trabajo de Legión 4. Funcionamiento de Legión La interfaz web permite al usuario, entre otras cosas, la generación de tareas correspondientes a un proyecto específico. Estas tareas, internamente generan workunits mediante la Interfaz Generadora de Tareas, las cuales son enviadas a los computadores cliente vía el sistema de encolamiento y distribución, para su posterior ejecución dentro del grid. Un sistema de monitoreo supervisa los cambios de estado de todos los workunits. Una vez que todos los workunits pertenecientes a una tarea específica finalizan, se realiza un procesamiento de salida que sumariza los resultados obtenidos. Finalmente, se genera un reporte que se envía al usuario vía correo electrónico. La interfaz web ofrece además la posibilidad de seleccionar y descargar los resultados obtenidos Generación de Tareas Las tareas creadas por los usuarios generan una serie de workunits, mediante una aplicación en C++ y una serie de librerías que provee el API de BOINC. Una vez creadas, las tareas son registradas en la base de datos MySQL. Cabe señalar, que para la mejor administración de las tareas y las workunits que la conforman, además de los usuarios que las generan, se tuvo que realizar una personalización de la base de datos original de BOINC Encolamiento y Distribución Una vez se generan los workunits, éstos son encolados por BOINC, para luego ser distribuidos y procesados en computadores cliente con recursos disponibles. Los computadores cliente seleccionados retornan sus resultados al servidor, donde son almacenados dentro de un servidor de archivos propio de BOINC. Los resultados esperan allí por el procesamiento de salida (punto 4.4) Monitoreo El sistema de monitoreo permite tener un control sobre los estados actuales de cada uno de los workunits que conforman una tarea. Este monitoreo se realiza vía disparadores configurados en la base de datos MySQL, permitiendo conocer el progreso de la ejecución de cada una de las tareas. La ejecución de la última tarea invoca el procesamiento de salida Procesamiento de salida El procesamiento de salida es el último paso en el flujo de ejecución de una tarea, permitiendo realizar un procesamiento sobre

48 cada uno de los archivos de resultados parciales. Este procesamiento es particular para cada proyecto según sus requerimientos. 5. La Infraestructura utilizada El servidor con el que se cuenta para albergar al Sistema Legión es un IBM eserver xseries Intel Xeon 3.2 GHz, con un total de memoria RAM de 4Gb y HDD de 73.4GB RPM, corriendo un sistema operativo CentOS 5.3. El Sistema Legión cuenta, actualmente, con 467 computadores que son utilizados como computadores cliente, encargados del procesamiento de todos los workunits generados. Los laboratorios informáticos de la universidad suman un total de 13, y se encuentran distribuidos según los distintos tipos de computador con los que se cuenta, donde cada uno de ellos alberga aproximadamente 40 equipos. La distribución de los mismos es como sigue: GenuineIntel Intel Core 2 CPU GHz 120 computadores distribuidos en un total de 3 laboratorios. GenuineIntel Intel Core 2 CPU Ghz 212 computadores distribuidos en un total de 6 laboratorios. GenuineIntel Intel Core 2 Duo CPU E Ghz 135 computadores distribuidos en un total de 4 laboratorios. Sumando la capacidad de todos los computadores medida por cada cliente BOINC en FLOPS, se ha llegado a una capacidad máxima estimada de procesamiento de 1 TeraFLOPS. 6. Caso de Aplicación El caso de aplicación esta enmarcado dentro de la Física de Altas Energías, donde el Dr. Alberto Gago, y su equipo de trabajo, han formado el Grupo de Altas Energías, en la Sección Física de la Universidad Católica del Perú. Su trabajo consiste en la comparación de dos modelos de producción de neutrinos de alta energía en Núcleos de Galaxias Activas (NGA), a través de la variación de los valores de los parámetros involucrados en la definición de cada modelo. El programa calcula el número de neutrinos producidos por cada modelo y el número de éstos que serán detectados en el telescopio de neutrinos IceCube[5], ubicado en el Polo Sur. Estos datos simulados serán utilizados posteriormente para cuantificar, primero, la posibilidad de identificar los neutrinos provenientes de NGA, de acuerdo a cada modelo, y, segundo, la capacidad que tendría IceCube para saber cuál de los dos modelos es el que explica la producción de neutrinos. El equipo de Legión recibió por parte del Grupo de Altas Energías el ejecutable de la aplicación antes descrita. Luego del análisis correspondiente, se llegó a la conclusión de que la aplicación podía ser boincificada. La solución en estos casos es utilizar el wrapper que brinda el API de BOINC para la ejecución en los computadores cliente de una aplicación previamente desarrollada. El primer paso de la boincificación, es realizar la creación del proyecto BOINC, para luego realizar la personalización de la base de datos que permita llevar el control adecuado en la creación de las tareas. A medida que se van realizando pruebas controladas de la aplicación a boincificar, la Interfaz Generadora de Tareas es diseñada y desarrollada, para luego proceder con las primeras pruebas de generación de workunits. Luego de validar ejecuciones con pocos workunits, el monitoreo de los mismos y el Procesamiento de Salida son diseñados. Este último requiere un trabajo muy cercano con el equipo que propone el proyecto, tomando los requerimientos de sumarización propios de su estudio. Luego de ello se empiezan a realizar pruebas con el flujo completo desarrollado, desde la generación, hasta la obtención de los resultados finales. Dado que el objetivo es que los usuarios no tengan la necesidad de conocer la arquitectura que soporta el grid, ésta se encuentra oculta a través de un módulo web desarrollado

49 específicamente para el proyecto, donde cada una de las partes del desarrollo mostradas pueda ser ejecutada vía la interfaz Legión. Cada usuario posee a un ambiente propio donde puede acceder a los proyectos a los que pertenece, administrar sus tareas, y acceder a los resultados de las mismas. El acceso a estos ambientes personales es validado vía web mediante un login con usuario y contraseña. En la Figura 3 se muestra la interfaz web del Sistema Legión, específicamente la pantalla de generación de una nueva tarea. Como se muestra, el usuario debe ingresar todos los parámetros necesarios para que la aplicación se ejecute en los computadores cliente. La imagen muestra algunos de los parámetros necesarios para esta generación en particular. Figura 3. Interfaz Legión [7] En la Figura 4 se muestra a una tarea en ejecución, indicando además el progreso de la misma y la cantidad de computadores que se encuentran ejecutando en ese instante la tarea. Luego de que el Procesamiento de Salida finalice, se mostrará la cantidad de Horas CPU que la tarea ha tomado, pudiendo compararse con la cantidad de horas que la tarea hubiera tomado si se ejecutase en una sola computadora. Figura 4. Interfaz Legión [7]

50 La Figura 5 muestra a la tarea antes mencionada luego de finalizar su ejecución, tomando un tiempo total de Horas/CPU, obteniendo un tiempo real de procesamiento dentro del Sistema Legión de aproximadamente 60 horas. Finalmente el link de descarga de resultados se activaría, y este estaría disponible para la descarga por parte del usuario que ha generado la tarea. Figura 5. Interfaz Legión [7] 7. Conclusiones y Trabajos Futuros Diversos campos de investigación no pueden ser abordados de manera satisfactoria sin la ayuda de una capacidad de cómputo realmente importante. Tradicionalmente esto se resuelve con un cluster de computadoras dedicado, el cual puede representar un costo muy elevado, en términos de adquisición, instalación y mantenimiento; considérese además que, por razones de espacio, el cluster puede limitarse a un reducido número de computadores. Por otro lado, notamos que muchas universidades en Latinoamérica cuentan con laboratorios de cómputo equipados con computadores de última generación, cuya potencia de procesamiento realmente excede las necesidades del estudiante promedio, generándose una gran capacidad de cómputo ocioso que puede ser aprovechado en proyectos de investigación computacionalmente intensivos. La tecnología de computación en grid brindada por BOINC, permite aprovechar la infraestructura de aulas informáticas, tomando de forma controlada los recursos computacionales ociosos, de tal forma que no interrumpa el trabajo de los usuarios, con lo que se logra obtener grandes capacidades de cómputo. La infraestructura BOINC puede ser adaptada a diversos proyectos gracias a que posee su propia API de desarrollo, la cual puede ser incluida en aplicaciones ya implementadas, con ciertos cambios de lógica, pero no muy significativos para un desarrollador experimentado permitiendo incorporar funcionalidades de checkpoint para ejecuciones de workunits muy largas. Los proyectos también pueden ser boincificados y ejecutados en paralelo sin necesidad de utilizar el API de manera directa, como es el caso de la aplicación desarrollada en el presente proyecto. El Sistema Legión trabaja como un excelente complemento del sistema BOINC y ofrece a los investigadores una interfaz amigable para que puedan interactuar con la grid, ocultándoles la complejidad de la misma y permitiéndoles mayor fluidez en los trabajos que deseen procesar. Además, se alivia el trabajo del administrador del sistema BOINC, ya que Legión puede configurar los nodos

51 automáticamente mediante las herramientas en java antes descritas. El proyecto desarrollado optimiza el aprovechamiento de la infraestructura con que la universidad cuenta, ya que se puede obtener todo el potencial que tienen los computadores que se poseen. Con el presente estudio se sientan las bases para que otras universidades latinoamericanas puedan replicar el estudio desarrollado, adaptándolo a sus realidades, y así fomentar el ingreso, por parte de éstas, a la eciencia. Nuestro trabajo futuro estará enfocado en la implementación de una interfaz web que permita la administración de los computadores, a fin de realizar en forma eficiente los procesos de mantenimiento requeridos. El uso de un servidor de datos externo es otro de los objetivos futuros de este proyecto. Esto debido a que algunos proyectos podrían generar archivos resultado bastante extensos, por lo que un mismo servidor sería ineficiente. El desarrollo del Sistema Legión tiene como objetivo captar a la mayor cantidad de investigadores para que hagan uso de éste, y puedan terminar sus proyectos de investigación de forma satisfactoria. Dado que los computadores de los laboratorios utilizan el sistema operativo Microsoft Windows XP, se esta trabajando en lograr que éstos puedan a la vez soportar un sistema operativo GNU/Linux, trabajándolos como máquinas virtuales corriendo sobre Microsoft Windows. Con esto logramos tener el soporte para aplicaciones nativas tanto en Microsoft Windows como en GNU/Linux. hardware, Mundo Electrónico N 346, Cetisa, Madrid, Oct. 2003, pp [7] Sistema Legión [8] A. Grama, A. Gupta, G. Karypis and V. Kumar, Introduction to parallel computing, Pearson, Harlow, [9] I.Foster, C.Kesselman and S. Tuecke, The anatomy of the Grid : Enabling Scalable Virtual Organizations, International Journal of Supercomputer Applications, Vol. 15, N 3, [10] P. Plaszczak Jr., R. Wellner, Grid Computing : The Savvy Manager s Guide, Morgan Kaufmann, San Francisco, [11] I. Foster, Globus Toolkit Version 4 : Software for Service-Oriented Systems, Globus Alliance, EFIP-2006.pdf, Referencias [1] R. Smith, Grid Computing: A Brief Technology Analysis, CTO Network Library, nalysis.pdf, 2005 [2] BOINC [3] A. Abbas, Grid Computing: A Practical Guide to Technology and Applications, Charles River Media, Massachusetts, 2004 [4] Prototype Javascript framework [5] IceCube Neutrino Observatory [6] P. Morillo Tena, Grid Computing: Compartición de recursos y optimización del

52 Solving Analytical Structured Formalisms in Parallel Using Slice Algorithm Pedro Velho Computer Science, UJF, LIG, INRIA Grenoble, France Prof. Luiz Gustavo Leão Fernandes Computer Science, PUCRS Porto Alegre, Brazil Abstract Analytical modeling can be used to predict performance, detect unexpected behavior and evaluate strategies in order to improve systems. In the context of modeling computational environments, a multitude of analytical structured modeling formalisms, such as Stochastic Automata Networks (SAN), is becoming popular since they provide high level abstractions and modularity. Indeed, in order to obtain performance estimations of a given SAN model, it is necessary to perform multiple matrix-vector multiplications. In structured formalisms, such as SAN, the matrix-vector multiplication is not presented in the usual format xa, since matrix A is replaced by an algebraic expression Q (called Markovian Descriptor or just descriptor, for short) due to modularity. The original multiplication is then replaced by a vector-descriptor multiplication (VDM), letting some space for algebraic improvements. Mainly, there are two algorithms that implement the VDM: shuffle and slice. In previous works, a parallel version of shuffle was proposed. It presented good results in terms of memory allocation but tasks are hard to split and hence compromises its scalability. The slice algorithm is based on an algebraic property that can, since its name says, split the VDM in many independent operations. The goal of this work is to underline a high performance version of the slice to check the scalability of this algorithm. Keywords-Parallel Applications, Kronecker/Markovian Descriptor, Structured Analytical Formalisms, Stochastic Automata Networks I. INTRODUCTION Performance prediction has proven to be useful in a myriad of situations: to predict the performance of parallel applications [1], [2], establish constrains in algorithms design [1], evaluate the efficiency of fault-tolerant systems [3], among others. Our focus throughout this paper is to propose a parallel version of the resolution of a set of formalisms employed in the stochastic analysis. Those formalisms are called Analytical Structured Formalisms (ASF) because they offer a structured and modular approach to represent Markov Chains. For the final user, the structure imposed by such formalism bring more understanding when modeling complex phenomena. In such formalism an equivalent but more efficient numerical treatment may be used in order to manage the time-memory trade-off. All structured formalisms are based on the multiplication of an algebraic expression by a vector, Qx. This algebraic operation replaces the Markov Chain matrix-vector multiplication, Ax. Since the algebraic expression Q is called Markovian descriptor (throughout this paper we use just descriptor for the sake of brevity) it is called vectordescriptor multiplication (VDM). One of the advantages of using VDM is a more rational use of memory which limits most Markov Chain models. Although, the response time to achieve performance estimations is still unacceptable in many cases [1], [2], [3]. To fill that gap, one can find mainly two algorithms to compute the VDM. Firstly, the Shuffle [4], [5], [6] algorithm proposes an on-the-fly mapping of non-zero elements from the descriptor to the equivalent Markov Chain matrix. This approach significantly reduces the use of memory making the solution bounded by makespan. Secondly, the Slice [5] algorithm provides the opposite trade-off where mapping is performed in grouped data reducing the response time but increasing memory usage. The use of high performance computing environments to improve the VDM has already been explored before in [4] for the Shuffle algorithm. To harness the computational and memory power of many machines is an alternative to CPU and memory bounded applications [7], [8], [9]. Although, the memory management of the algebraic structures in shuffle make it hard to exploit many processors, since the number of tasks depend on problem characteristics. In this context Slice can split the VDM operation in many small tasks. This implies more memory usage but we believe the scalability should be suitable to exploit a high performance computing environment. Although, a parallel Slice version is not yet existent. The objective of this paper is to underline a parallel version of the Slice algorithm hence extending the understanding CPU and memory limitations when solving such formalisms. In Section II we state the VDM problem where the Slice algorithm is presented. Following, in Section III, we underline the parallel strategy. We present performance results in comparison with a sequential version in Section IV. Finally, in Section V, we state conclusions and directives for future work. II. THE MARKOVIAN DESCRIPTOR Analytical structured formalisms (ASF) emerged in the last decade as an alternative to Markov Chain models. The

53 main motivation of using them is due to the lower storage cost. Avoiding the combination of elements which would result in zero (not affecting the calculation) is the key to reduce memory usage. Besides that, ASFs provide higher level abstraction because, in those formalisms, a system can be modeled in subsystems. In those cases the interaction among subsystem may be specified using synchronizing primitives [10], [11], [12]. To illustrate how the structured formalisms make life easier, the Markov Chain seen in Fig. 1 is a possible model to design a mutual exclusion problem of two process sharing a resource. Using an analytical structured formalism one can split the model in subsystems. As can be seen in Fig. 2 which shows a SAN approach modeling the same situation, each entity of the system (processor and resource) is modeled as a separate subsystem. The main lack of abstraction in Markov Chain when compared to structured formalisms is due to the fact that each state must be thought as a combination of two or more states in each entity. When the system being modeled is intrinsic divided in subsystems the use of an ASF is straight forward. T N k=1 i=1 Q (k) i (1) The format of a Markovian Descriptor is generalized as in (1). Although this expression summarize the core of structured analytical formalisms, they are rarely presented in that shape when the focus is to prove their equivalence to Markov Chains. For instance, in [15] a SPN descriptor is proposed as (2). Another example could be the SAN descriptor seen in (3), where E is the total amount of synchronizing events and N the number of automata. Both descriptors given by (2) and (3) are presented in terms of how to combine the matrices in order to prove their equivalence to classic Markov Chains. Once this paper aim is not to prove such equivalence, a more generic shape of the Markovian Descriptor, given by (1), is adopted. R = N R (i) + i=1 τ j T i=1 N R (i,j) (2) l1 1 P rocesso A Recurso P rocesso B 0 e2(π1) e2(π2) e1 2 e1, e3 0 1 Figure 2. A SAN model that models the same problem of Fig. 1. The automata are algebraic represented as a set of matrices. For instance, in Fig. 2, each automaton in that model has a matrix representing their state transitions. The equivalence of an ASF with Markov Chains is proven providing a way to map the specific matrices into a Infinitesimal Generator (IG). This Infinitesimal Generator is the unique algebraic structure in a Markov Chain model, which has the rates associated to all states transitions. The set of structures and the algebraic operation involved in the construction of the IG is called Markovian Descriptor, or descriptor for short. A descriptor is also called Kronecker Descriptor once that the algebraic operations and properties used to map then into a Markov Chain are known as Kronecker algebra [12]. There is a variety of formalisms that are based on the Markovian descriptor, such as: Stochastic Automata Networks [10] (SAN), Stochastic Petri Nets (SPN) [13], Performance Evaluation Process Algebra (PEPA) [14]. Those formalisms have in common the use of Kronecker operations to combine a set of matrices into a Markov Chain. Although, those formalisms are similar they differ in the rates associated and in the manner that transitions are tackled. e2 l2 1 0 e2(π1) e2(π2) e3 2 Q = N i=1 Q (i) l + ( E N e=1 i=1 Q (i) e + + N i=1 Q (i) e The resolution of structured analytical models is made, analogue to a Markov Chain model, solving a linear equation system. Such as in Markov Chain models, this resolution is based on iterative processes which are based on a vectormatrix multiplication at each iteration (4). ) (3) xa (4) However, when using a structured analytical formalism the coefficient matrix A is replaced by the Markovian Descriptor, (5). Hence some complexity is added, once the user deals with the manipulation of a greater amount of matrices whose elements must be combined and mapped into a matrix equation. This process of combining and mapping elements is made using the Kronecker operations defined over matrices: Kronecker product (denoted by ) and Kronecker sum (denoted by ). xq = x ( T N k=1 i=1 Q (k) i Numerical iterative methods are suitable to solve structured analytical models [10]. The iterative method used may vary: Power method, Arnoldi method, and so on. Nevertheless, all iterative methods are based on the same basic operation [16]: the vector-descriptor multiplication. ) (5)

54 τ4 τ2 P A (0) R(0)P B (0) τ3π1 τ1 τ1 τ3π1 P A (0) R(0)P B (1) P A (1) R(0)P B (0) τ3π2 τ1 τ1 τ3π2 τ2 τ3π1 τ3π1 τ4 P A (0) R(1)P B (2) P A (1) R(0)P B (1) P A (2) R(1)P B (0) τ3π2 τ3π2 P A (2) R(1)P B (1) P A (1) R(1)P B (2) τ1 τ1 Figure 1. Markov Chain modeling the mutual exclusion problem with two process and one resource. A. Slice Algorithm The parallel Slice algorithm presented here is focused in one single multiplication. Slice algorithm is based on the additive unitary normal factor decomposition property. This property holds that given a series of Kronecker products, the left side (6), it can be factorized in a sum of scalar multiplications (7). To maintain the position, i and j, where each scalar will be placed in the resulting equation matrix we combine the i and j information of each scalar. The formalization of this property is presented below. This procedure is executed several times until a solution is reached. broadcast x k broadcast x k+1 Process 0 Process 1 Process 2 Process 3 x k+1 0 x k+1 = procs p=0 xk+1 p x k+1 1 x k+1 2 x k+1 3 n 1 i 1=1 n N n 1 i N =1 j 1=1 n N j N =1 Q (1) Q (N) = (6) ( ) ˆq (i 1 1j 1) ˆqN (i N j N ) (7) Applying this properties in the N 1 leftmost Kronecker product is the core idea of slice. We call the scalars resulting form the N 1 first matrices Additive Unitary Normal Factors (AUNF or factor for short), because they are actually not just scalars but a triple of one scalar and its i, j position in the resulting matrix. Since slice generates a significant number of AUNFS this implies in more memory usage when compared to Shuffle. III. PARALLEL MULTIPLICATION The approach used to execute an iteration in parallel is presented in Fig. 3. In this communication scheme the processor with lowest rank is responsible to send the vector of the current iteration, x k, to all processors starting an iteration step. Once a processor gets x k it starts the VDM multiplication concerning the AUNFs (tasks) previously assigned. Afterward, each processor returns a partial vector of the next iteration, x k+1 p (where p denotes the processor id). Finally, the partial vector are summed resulting in the next iteration vector x k+1 finishing one step of the parallel VDM. A high level overview of the parallel vector-product multipli- Figure 3. cation. x k+2 0. x k+2 1. x k+2 2. x k+2 3. Our aim with this parallel approach is to verify its scalability. To do so, we propose two granularities: (i) coarse grain, map each model automaton in one task, this approach is the same as presented in [4] for parallel Shuffle; (ii) fine grain, where each AUNF is one task, this approach should improve scalability. A. Coarse Grain The Markovian Descriptor adopted in (1) is a sum. A coarse granularity approach is then obtained using the distributive property over the sum as given by (8). In this strategy the maximum amount of tasks is the total number of algebraic terms (T ). This approach is similar to the one used in previous works for the parallel shuffle [12]. ( ( T N )) x (8) k=1 i=1 Q (k) i Both algorithms, shuffle and slice, can benefit from this method of distributing computation. Once this approach

55 Table I TEST CASES PARAMETERS IN DETAIL. Test Case # of Coarse # of Fine Density Sequential Time (s) Label Grains Grains MUTEX % MIXED % 5.95 DENSE (A) % DENSE (B) % (a) (b) Coarse grain slice Fine grain slice optimal Coarse grain slice Fine grain slice optimal speedup speedup amount of processors amount of processors Figure 4. Speedup for the mutex (a) and mixed (b) test cases. is based on distributing the multiplication directly in the Markovian Descriptor level, which is the same structure for both algorithms. In order to balance the amount of computation given to each process a static scheduling approach based in the cost of each task is used. This strategy is based on computing each task computational cost before execution. Next, the smallest task will be assigned to the processor with less load. The number of steps taken depends on the total amount of tasks (or terms, T ) and the number of processing units P. One advantage of using coarse granularity is that the computation of AUNFs can be done in parallel, since there is no interdependence between each term. Although, the scalability problem can not be tackled without the use of some algebraic property, which leads us to the fine grain approach. B. Fine Grain Using each AUNF as an independent task is hence explored as an alternative. AUNFs are homogeneous in terms of computational cost. Moreover, AUNFs are dependent of problem complexity and do not rely on problem characteristics as before. For these reasons, the fine grain approach seems to be suitable to increase scalability. One drawback of fine grain is that the AUNF generation step can not be distributed. This step can be distributed when using coarse grain because a term is always entirely assigned to a processor. However, using fine grain, tasks have to be computed in a preconditioning step. The preconditioning step represent a significant computing effort. Even though, the time taken by this step is slightly greater than one iteration. Once it is needed a significant amount of iterations to solve a model, typically 1000 up to 10000, this cost is attenuated in the final execution time (less than 1 % of overall makespan). IV. PERFORMANCE EVALUATION Tests were carried out in Grid5000 using machines from the i-cluster2 located in Montbonnot, France inside the INRIA Rhône-Alpes facility. Each of the 104 nodes of i- cluster2 features two Itanium-2 64 bits processors at 900 MHz, 3 Gigabytes of memory and 72 gigabytes of local disk. The nodes are interconnected through Gigabit ethernet switch. In order to evaluate the algorithm using different test cases we choose four Markovian Descriptors detailed in Tab. I. Aiming to test how this version would behave using classic models, the test cases mutex and mixed are two real algebraic representation of SAN models. The first, named mutex, was extracted from a SAN model that implements the problem of 16 processors sharing 4 resources in a race condition. The second, called mixed, is a hypothetical SAN model that stress different parameters of this formalism such

56 (a) (b) Coarse grain slice Fine grain slice optimal Coarse grain slice Fine grain slice optimal speedup speedup amount of processors amount of processors Figure 5. Speedup for the dense (a) and (b) test cases. as: number of states per automata; number of synchronizing events; among others [10]. The other two tests, dense (a) and (b), were obtained inflating the number of non-null elements from the mixed test case. The overall mean of non-null elements is obtained using the equation (9). In (9), T means the total amount of terms and N means the total number of matrices that compound each term. The variable nz and n are respectively the number of non-null elements and the order of each matrix i from a given term k. T N k=1 i=1 N T n (k) i nz (k) i n (k) i 100 (9) The speedup achieved are presented in Figs. 4 and 5 for both grains, fine and coarse. Test cases mutex, mixed, dense (a) and dense (b) are presented respectively in Figs. 4-a, 4-b, 5-a and 5-b. The results were obtained through a real experiment running the application 10 times and in each one executing 100 iterations. The mean of one iteration execution time was computed discarding the higher and the lowest values obtained. Even though, the standard deviation was observed to avoid intrusiveness such as other applications running at the same time or cache effects. In the two real test cases, mutex (Fig. 4-a) and mixed (Fig. 4-b), the behavior of both proposed grains are similar. One can observe that the speedup is distant from the ideal and that the finer grain approach is always better because it can scale further, for those test cases. The test case mutex has 32 maximum tasks with coarse grain approach due to the problem characteristics which is limited to 32 terms, the other tests are 16 terms each. Observing, Figs. 5-a and 5-b, one can see that the solution can scale better maintaining speedup factor closer to optimal for more computational intensive test cases. Note that the coarse grain is limited to 16 tasks in Dense-A/B because of their amount of terms, as showed in Tab. I. Figs. 5-a and 5-b highlight coarse grain scalability issue. The presence of some constant speedup is due to task heterogeneous characteristics, hence one task becomes the makespan bottleneck. The coarse grain approach, originally inspired by the successful parallel implementation of shuffle [4], is not suitable for slice algorithm. V. CONCLUSIONS The main goal of this work was the parallel implementation of the Slice algorithm to provide a effective scalable parallel vector-descriptor multiplication (VDM). This operation is used by a multitude of structured formalism based on Markovian Chains. Test case Table II BEST RESULTS ACHIEVED. Fine grain Best results Coarse grain Sequential time MUTEX MIXED DENSE (A) DENSE (B) The results presented show a significant gain of performance summarized in Tab. II. In all test cases the fine grain has presented better results than the coarse grain approach. Graphs show that fine grain has also better scalability. However, it is still an open point when to use shuffle or slice. Since both have different characteristics. A scalability vs preconditioning and time-memory trade-off analysis will be done in future work.

57 REFERENCES [1] L. Baldo, L. Brenner, L. G. Fernandes, and A. Sales, Performance Models for Master/Slave Parallel Programs, Electronic Notes in Theoretical Computer Science, vol. 104, no. 1, pp , [2] L. Brenner, L. G. Fernandes, P. Fernandes, and A. Sales, Performance Analysis Issues for Parallel Implementations of Propagation Algorithm, in Proceedings of the 15th Symposium on Computer Architecture and High Performance Computing, Publisher ACM Press, Ed., Sao Paulo, Brazil, 2003, pp [3] C. Bertolini, L. Brenner, A. Sales, P. Fernandes, and A. Zorzo, Structured Stochastic Modeling of Fault-Tolerant Systems, in 12th Annual Meeting of the IEEE/ACM International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, MASCOTS 04, New York: IEEE Press, Ed., Volendam, Netherlands, 2004, pp [13] M. Ajmone Marsan, G. Balbo, G. Conte, S. Donatelli, and G. Franceschinis, Modelling with Generalized Stochastic Petri Nets, Special issue on Stochastic Petri Nets, vol. 26, no. 2, p. 2, [14] S. Gilmore, J. Hillston, L. Kloul, and M. Ribaudo, PEPA Nets: A Structured Performance Modelling Formalism, Performance Evaluation, vol. 17, no. 10, pp , [15] G. Ciardo and M. Tilgner, On the Use of Kronecker Operators for the Solution of Generalized Stochastic Petri Nets, ICASE, Tech. Rep. 96(35), [16] K. Atif and B. Plateau, Stochastic Automata Networks for Modelling Parallel Systems, IEEE Transactions on Software Engineering, vol. 17, no. 10, pp , [4] L. Baldo, L. G. Fernandes, P. Roisenberg, P. Velho, and T. Webber, Parallel PEPS Tool Performance Analysis Using Stochastic Automata Networks, in Euro-Par, Piza, Italy, 2004, pp [5] Pedro Velho, Acelerando a Ferramenta PEPS através da Paralelização do Algoritmo Shuffle para a Multiplicação Vetor-Descritor, Trabalho Individual I, PUCRS-PPGCC, Porto Alegre, Brasil, [6] T. Webber, Alternativas para o Tratamento Numérico Otimizado da Multiplicação Vetor-Descritor, Dissertação de Mestrado, Porto Alegre, Brasil, [7] L. G. Fernandes, E. Bezerra, F. Oliveira, M. Raeder, P. Velho, and L. Amaral, Probe Effect Mitigation in the Software Testing of Parallel Systems, in Latin-American Test Workshop LATW, Buenos Aires, 2006, pp [8] M. Kolberg, L. Baldo, P. Velho, L. G. Fernandes, and D. M. Claudio, Optimizing a Parallel Self-verified Method for Solving Linear Systems, in Workshop on State-of-the-Art in Scientific and Parallel Computing - PARA, Umea, 2006, pp [9] P. Velho, L. G. Fernandes, M. Raeder, M. Castro, and L. Baldo, A Parallel Version for the Propagation Algorithm, in 8th International Conference on Parallel Computing Technologies - PaCT, vol. (LNCS 3606), Kranoyarsk, 2005, pp [10] P. Fernandes, Methodes Numériques pour la Solution de Systèmes Markoviens a Grand Space d états, Ph.D. dissertation, Institut National Polytechnique de Grenoble, Grenoble, [11] P. Fernandes, B. Plateau, and W. J. Stewart, Efficient descriptor-vector Multiplication in Stochastic Automata Networks, Journal of the ACM, vol. 45, no. 3, pp , [12] P. Fernandes, R. Presotto, A. Sales, and T. Webber, An Alternative Algorithm to Multiply a Vector by a Kronecker Represented Descriptor, in 21th Annual UK Performance Engineering Workshop, UKPEW, Newcastle, England, 2005, p. 3.


59 SEQUENCE ALIGNMENT USING PARALLEL PROCESSING TECHNIQUES DEVELOPED ON A CLUSTER OF COMPUTERS Wilson Castaño Galviz 1 Universidad Pontificia Bolivariana Seccional Bucaramanga Lenin Javier Serrano Gil 2 Universidad Pontificia Bolivariana Seccional Bucaramanga Miguel Mateus Marín 3 Universidad Pontificia Bolivariana Seccional Bucaramanga Abstract This paper presents the development of a computer algorithm for sequence alignment, implemented in a computer cluster at the Universidad Pontificia Bolivariana Bucaramanga branch using Linux operating system and OSCAR configuration tool for deploying applications in parallel, also shows the performance clusters with different sizes of files to compare, that using the cluster with different amounts of processing nodes. Palabras clave Cluster de Computadores, OSCAR, MPI, alineamientos. I. INTRODUCCIÓN Un área de aplicación de la Bioinformática[1] que actualmente se encuentra en auge es el alineamiento de secuencias (aplicados a genomas) [2], que permite detectar los niveles de similitud entre las diferentes genomas de distintas especies, permitiendo detectar los cambios entre los organismos vivos de nuestro planeta. En la actualidad existen herramientas[3] para el alineamiento de secuencias que se encuentran disponibles en Internet y permiten a las personas enviar los datos correspondientes a procesar y esperar por un resultado, dichas herramientas realizan los procesos de forma secuencial las cuales tardan en realizarse el cálculo ya que equipos de altas prestaciones no son posible de 1 Wilson Castaño Galviz, Ingeniero de Sistemas, Especialista en Docencia Universitaria y Magíster en Informática, actualmente labora como Docente e Investigador de tiempo completo en la Universidad Pontificia Bolivariana seccional Bucaramanga Colombia. 2 Lenin Javier Serrano Gil, Tecnólogo en Electrónica, Estudiante de 10 semestre de Ingeniería Informática en la Universidad Pontificia Bolivariana seccional Bucaramanga Colombia. 3 Miguel Mateus Marín, Estudiante de 5 semestre dei Ingeniería Informática en la Universidad Pontificia Bolivariana seccional Bucaramanga Colombia. tener en disponibilidad por el alto costo que esto conlleva. Con el avance de la tecnología se ha llevado al uso de sistemas computacionales que mejoren el rendimiento de los procesos, por esto los computadores necesarios para desarrollo computacional de alto consumo de horas máquinas tienen un costo muy elevado lo que hace difícil el acceso a las personas que desean realizar investigación que requiera alta prestación computacional, por este motivo nace el procesamiento en paralelo usando cluster de computadores (aprovechando los computadores que permanecen en tiempo ocioso) para realizar en conjunto el cálculo de alto rendimiento que sea necesario. Una de las áreas de la Ingeniería Informática es el desarrollo de aplicaciones que sean además de ser llevadas a cabo con toda la Ingeniería del Software pertinente, ser aplicables con la funcionalidad que se espera de dicho desarrollo, por este y por los motivos definidos anteriormente se considera necesario llevar a cabo aplicaciones que sean útiles al avance de la ciencia y que pueda ser usada por los miembros de la comunidad tanto académica como científica, que para este caso será la Bioinformática.

60 Por esto se plantea, es posible construir una aplicación de alto rendimiento para el proceso de alineamiento de secuencias que pueda realizar alineamientos en menos tiempo de lo que lo hace un computador?. II. SISTEMAS DE CLUSTER DE COMPUTADORES El término cluster de computadores[4,5] se definió al sistema de integración de varias CPU (Board, Memoria, Disco y procesador) interconectadas a través de una red de datos que permite la comunicación y que utilizando configuración de paso de mensajes a través de los nodos, es posible que todos (los nodos) trabajen como un sistema de multiprocesador con memoria distribuida. máquina (pc ) fuese reconocida como un elemento más del cluster. III. ANÁLISIS DEL CÓDIGO DESARROLLADO El nombre del archivo desarrollado se llamó, al cual se le hace una breve descripción de su funcionalidad. EqualParallel es un algoritmo dedicado a encontrar las similitudes entre dos cadenas de caracteres basado en el paradigma de procesos en paralelo[8] para optimizar la búsqueda de coincidencias. Desarrollado en Python 2.4con uso de bibliotecas MPI[9]. Para analizar las coincidencias definidas por la igualdad de caracteres entre las cadenas, EqualParallel recibe dos cadenas de caracteres denominadas Source y Target bajo la restricción de longitud LEN(Source) >= LEN(Target) para conformar una matriz, Ejemplo: Si Source = atccatattgg y Target = gataca se obtiene: Figura 1. Modelo de un sistema de cluster de computadores. Para el trabajo que se llevó a cabo se utilizó un cluster de 8 Nodos, están instalados con sistema operativo Linux Fedora en el equipo Front-end y para colocarlos a funcionar como cluster se utilizó OSCAR[6] (Open Source Cluster Application resource). El cluster funciona de la siguiente manera: 1. Se instaló Linux Fedora[7] en el equipo principal que se llama Front-end 2. Se configuró OSCAR en el equipo Frontend y se inició el proceso de reconocimiento de cada uno de los nodos, para esto se utilizó la interconexión a través de PXE de cada nodo, con el cual esperaba un servidor DHCP para que cada equipo tomara su configuración desde el Frontend 3. Para cada equipo se asignó la IP con la respectiva MAC, por esta razón cada nodo queda completamente ligado al sistema de cluster para que en las posteriores corridas del código, cada G A T A C A A T C C A T A T T G G Figura 2. Inicio del Análisis de comparación de las secuencias Para procesar las coincidencias sobre la matriz se realiza un barrido diagonal como se referencia en la figura 3. A T C C A T A T T G G G C C C C C C U U U U U A B C C C C C C U U U U T B B C C C C C C U U U A B B B C C C C C C U U C B B B B C C C C C C U A B B B B B C C C C C C Figura 3. Análisis de comparación de las secuencias con barrido diagonal C = Diagonal Central. U = Diagonal Superior. B = Diagonal Inferior.

61 Definido para cada barrido diagonal el término de recorrido. Los recorridos se caracterizan por el tipo de diagonal, es decir, existen para una matriz 3 tipos: recorridos sobre diagonales centrales, recorridos sobre diagonales superiores y recorridos sobre diagonales inferiores. A partir de los recorridos EqualParallel asigna a cada procesador una tarea. Cada tarea esta definida entonces por la función de identificación entre caracteres sobre el recorrido fijado. La función se encarga de identificar las igualdades agregando un peso valorado en 1 que a su vez es sumado al peso de acarreo en el recorrido. Con un valor neutro cero para la NO igualdad al finalizar el recorrido el peso total indica la cantidad de coincidencias. Para el ejemplo antes descrito el resultado se visualiza en la figura 4. A T C C A T A T T G G G A T A C A Figura 4. Análisis de comparación de las secuencias con barrido diagonal y valores encontrados para lograr la mayor coincidencia Los resultados al proceso se reflejan en la última fila para recorridos centrales e inferiores y en la última columna para recorridos superiores. A Figura 5. Análisis de comparación con resultados de recorridos Los datos obtenidos sufren un proceso de ordenamiento que retorna una lista ordenada de mayor a menor de los pesos para cada recorrido, en consecuencia se identifica la mayor coincidencia para una posición de Target vs G Source. Retomando el ejemplo para el peso de mayor valor 4 el alineamiento esta dado en la siguiente secuencia: A T C C A T A T T G G G A T A C A Figura 6. Alineamientos por coincidencias en el programa desarrollado Paralelización. EqualParallel entrega a cada procesador existente los recorridos a ejecutar. La distribución de carga responde al tipo de recorrido, en caso que sea central se distribuye en cada procesador por igual. Para el caso de los recorridos superiores e inferiores a cada procesador se le asigna los recorridos de forma tal que las longitudes sean equivalentes. Para la matriz de ejemplo se describe el proceso en la figura 7, 8 y 9. - Para un total de 3 procesadores recorridos centrales. P A T C C A T A T T G G G A T A C A Figura 7. Análisis de recorridos en paralelo usando tres procesadores para recorrido central Procesador 0 = = 12. Procesador 1 = = 12. Procesador 2 = = 12. Carga total del proceso = 36. Procesador 0 = (12/36) * 100% = 33.33%. Procesador 1 = (12/36) * 100% = 33.33%. Procesador 2 = (12/36) * 100% = 33.33% - Para un total de 3 procesadores recorridos superiores.

62 P A T C C A T A T T G G G A T A 1 0 C 1 A Figura 8. Análisis de recorridos en paralelo usando tres procesadores para recorrido superior Procesador 0 = = 6. Procesador 1 = = 6. Procesador 2 = 3 = 3. Carga total del proceso = 15. Procesador 0 = (6/15) * 100% = 40%. Procesador 1 = (6/15) * 100% = 40%. Procesador 2 = (3/15) * 100% = 20%. - Para un total de 3 procesadores recorridos inferiores. P A T C C A T A T T G G G 0 A 1 1 T A C A Figura 9. Análisis de recorridos en paralelo usando tres procesadores para recorrido inferior Figura 10. Análisis de distribución de carga en los procesadores Al final se usaron 5 procesadores para analizar el comportamiento de la carga, tal como se describirá en los resultados Datos obtenidos A continuación se muestran las diferentes corridas de comparaciones entre genomas con el mismo número de pares de bases, en las corridas se probaron con: 1, 2, 3 y 5 procesadores en el cluster, y en cada corrida se comprobó con 10,100, 1000 y pares de bases en cada genoma. Cada una de las figuras desde la 11 hasta la 14 es la comprobación, en el eje de la abcisa se muestra el número de procesadores que se utiliza y el el eje de la ordenada se muestra el tiempo consumido por todo el cluster mientras realiza el proceso de alineamiento. Utilizando 10 pares de bases Procesador 0 = = 6. Procesador 1 = = 6. Procesador 2 = 3 = 3. Carga total del proceso = 15. Procesador 0 = (6/15) * 100% = 40%. Procesador 1 = (6/15) * 100% = 40%. Procesador 2 = (3/15) * 100% = 20%. Figura 11. Tiempo de proceso concumido por el cluster usando 10 pares de bases Utilizando 100 pares de bases

63 En el caso de los procesos que se corren con cantidad diferente de numéros de pares de bases, se determinó que cuando se tienen pocos pares de bases, el cluster no es funcional sino que por el contrario se tarda mas tiempo ya que se presenta el retardo causado por la comunicación entre los nodos, a diferencia de las corridas en las cuales se tienen mas de 100 pares de bases a comparar ahí si es funcional el cluster, ya que los tiempos se disminuyen hasta en un 20% del tiempo que se tarda en una sola máquina. VI. CONCLUSIONES Figura 12. Tiempo de proceso consumido por el cluster usando 100 pares de bases 1000 pares de bases Figura 13. Tiempo de proceso consumido por el cluster usando 1000 pares de bases Utilizando pares de bases En la selección entre MPI y PVM, se tuvieron en cuenta las ventajas entre las cuales sobresale que PVM se encarga de asignar las tareas de forma automática mientras que MPI no, en contra a esto, MPI controla el envío desde el front-end hacia los nodos, mientras que con PVM no se puede controlar, por esta razón se seleccionó MPI como base de trabajo para el procesamiento en paralelo. El cluster que se implementó fue un Beowulf homogéneo, ya que la Universidad facilitó 8 equipos de cómputo con las mismas características y teniendo en cuenta que se probó ROCKS, OSCAR y MPICH, se decidió por OSCAR, ya que brindó tanto la configuración como la puesta en marcha en una forma muy amigable, y su funcionalidad quedó demostrada. De los sistemas de alineamiento que se analizaron se hizo la selección entre Alineamiento glogal y Alineamiento local, se tuvieron en cuenta las ventajas y desventajas de cada uno y dio un mejor rendimiento el uso de alineamiento global. Utilizar un cluster de computadores para realizar alineamiento de genomas es útil cuando las cadenas tienen un número mayor a 1000 pares de bases, debido a que los tiempos de proceso en cada nodo del cluster se incrementan y el tiempo que se tarda en repartir las tareas es muy pequeño, en estos momentos cada vez que se agregan nodos al cluster, éste va a tener un mejor rendimiento en el procesamiento de las cadenas. Figura 14. Tiempo de proceso consumido por el cluster usando pares de bases De los alineamientos probados en el cluster, se logró una disminución hasta del 80% de tiempo

64 cuando se utilizaron 5 nodos que fue la mayor cantidad de elementos utilizados. VII. TRABAJOS FUTUROS Cabe destacar que la implementación de un Cluster de computadores es el paso inicial para realizar procesos paralelos y se debe continuar con los trabajos de análisis de rendimientos, lo mismo que para ser utilizados en el procesamiento de imágenes, análisis de fluídos, control de alta velocidad, que requieran alta capacidad de cómputo del sistema informático. Para los procesos que se desarrollan al interior del grupo de Investigación GIINFO (Inscrito en Colciencias) y especialmente del Semillero Especializado en Computación de Alto Rendimiento (SIECAR) se trabaja con los lenguajes de programación Python y C++, esto ha permitido implementar las aplicaciones que funcionan en paralelo en nuestro cluster computacional, permitiendo que algunas aplicaciones exigentes de cómputo puedan ser procesadas no en forma secuencial sino en forma paralela [5] [6] [7] [8] GARCÍA LÓPEZ, Areli. DELGADO, Julián J. y CASTAÑEDA, Salvador, Metodologías de paralelizacion en supercomputadoras /paralelo/Part3.html [9] Agradecimientos: El autor expresa sus agradecimientos a la Universidad Pontificia Bolivariana Seccional Bucaramanga por asignar los computadores para la realización de este proyecto, lo mismo que los estudiantes del Semillero Especializado en Computación de Alto Rendimiento. VIII. REFERENCIAS [1] BERGERON, Bryan. Bioinformatics Computing. Prentice Hall, Pearson Education [2] MOUNT, David. Bioinformatics: Secuence and Genome Analysis. CSHL Press [3] PEVZNER, Pavel. TESLER, Glenn. Genome Rearrangement in Mammalian evolution: Lesson from human and mouse genomes. Genome research. [4] LIZÁRRAGA CELAYA, Carlos. clústeres computacionales sobre Linux.

65 GridUIS in the Context of EELA-2 Project GriUIS en el contexto del proyecto EELA-2 Jorge Luis Chacon V, Juan Carlos Escobar, David Fuentes, Julian Nobsa Advanced Supercomputer Center Universidad Industrial de Santander, UIS Abstract The ICT developments and advances dramatically have changed how to do research and technological improvements inside Universities, Centers and Research Institutes. The scientists are commonly interested in studying, modeling and simulating the complex systems. This complexity requires the establishment of multidisciplinary teams in order to work collaboratively interchanging resources and knowledge. The use of the Grid Technology is very important for Science development because the institutions and research groups can share resources that are not often available and expensive. This is the new emerging paradigm of the e-science. With this purpose the Universidad Industrial de Santander (UIS) is participating in the EELA-2 project. The objectives of the project, the implementation methodology, and the future plans of the institution with this infrastructure are presented. 1. Introducción El termino e-science fue introducido por Jhon Taylor[1], director general de investigación del Consejo de Investigación en Gran Bretaña en la oficina de Ciencia y Tecnología (OST). Taylor vislumbro que muchas áreas de la ciencia estaban siendo extremadamente dependientes de nuevas maneras de trabajo colaborativo y multidisciplinario. El termino e-science intenta capturar estos nuevos modos de trabajar: e-science is about global collaboration in key areas of science and the next generation of infrastructure that will enable it [2]. Para que se pueda disponer de un sistema de e-ciencia se debe desarrollar una infraestructura tecnológica que la soporte. Foster[3] ha definido que es un Grid, basado en los siguientes aspectos: 1) Es un sistema que coordina recursos que no están bajo control centralizado. 2) utilización de estándares, protocolos abiertos de uso general e interfaces. 3) proporciona servicios no triviales de gran calidad. Los países emergentes y en especial America Latina no pueden quedar al margen de esta nueva revolución científica y tecnológica. En America Latina y en Colombia existen diversas iniciativas para crear una iniciativa de e-ciencia, basada en la infraestructura de Grid Computing véase por ejemplo H.Hoeger[4], Díaz. C[5]; algunas de estas con mayor o menor grado de desarrollo e implementación. 2. Necesidades y formación del GridUIS La creación de una plataforma de Gridcomputing permitiría que los investigadores, los grupos, centros e institutos de investigación que lo requieran gran capacidad de computo y de almacenamiento, al mismo tiempo, que necesitan trabajar en forma

66 colaborativa para modelar y simular problemas muy complejos, y que se puedan emplear mientras estos recursos estén inactivos o poco utilizados. Además, como es un sistema interconectado se puede compartir el trabajo de investigación con otros colegas que pueden ayudar a hacer mas eficaz el análisis del problema o situación. En este contexto para cualquier universidad y específicamente para la UIS resulta atractivo el desarrollo e implementación de un campus Grid, de características muy parecidas a las que se han implementado o se implementan en otros ambientes académicos y científicos. Un Grid debe incorporar una serie de funciones un poco complejas de implementar en la practica. Entre las mas importantes están: Manejo de usuarios, Seguridad, Manejo de recursos, Transparencia, eficiencia, facilidad de uso y disponibilidad, etc 1. A continuación se describe la conceptualización, el desarrollo y la implementación del campus Grid de la UIS, denominado GridUIS. 3. El proyecto EELA-2 2 El proyecto EELA-2 tiene el propósito de construir un infraestructura Grid escalable, de producción de gran calidad y de alta capacidad que suministre un acceso continuo y que permita un acceso alrededor del mundo a recursos de sistemas de computo distribuido, datos de almacenamiento y redes que son necesarios para una colaboración científica en un amplio rango de aplicaciones entre Europa y LA con un énfasis en: 1) Ofrecer un conjunto completo y versátil de servicios que satisfagan completamente los requerimientos de las aplicaciones. 2) Asegurar a largo plazo la sostenibilidad de la e-infraestructura mas allá de la terminación del proyecto La visión del proyecto EELA-2 tiene dos aspectos: 1) Consolidar y expandir la actual e-infraestructura de EELA construida sobre el proyecto Europeo GÉANT2 y la Red CLARA Latinoamericana y las Redes Nacionales de Investigación y Educación (NREN), para llegar a ser una plataforma de e-infraestructura que suministre un conjunto completo de servicios apropiados para todos los tipos de aplicaciones de múltiples áreas científicas de las comunidades de científicos de Europa y America Latina. 2) Asegurar las condiciones de sostenibilidad de la e- infraestructura mas allá de la duración del proyecto. 4. Implementación de GridUIS Este proyecto busca, por un lado, desarrollar las facilidades y servicios de computación avanzada a través de la creación del GridUIS para satisfacer las demandas de grupos de investigación en ciencias, ingenierías y ciencias humanas, haciendo énfasis en la utilización de aplicaciones en las áreas de: Física de Altas Energías, Química Cuántica, Ingeniería estructural, Geofísica y Sismología, CFD, Bioingeniería y repositorios de archivos históricos de la región. Adicionalmente, se pretende generar líneas de trabajo e investigación, adaptación y optimización de códigos de ciencias e ingeniería a la infraestructura Grid y en la virtualización de ambientes de colaboración electrónica e instrumentación. Los Objetivos Generales de la propuesta son: a) Desarrollar una infraestructura de servicios de computación avanzadas para las comunidades de ciencias, ingenierías y ciencias humanas de la UIS. b) Desarrollar líneas de Investigación en Virtualización de ambientes de colaboración e instrumentación. La metodología contempla las siguientes etapas que son importantes para el cumplimiento de los objetivos planteados: a) Instalación, configuración y afinación del glite

67 ( b) Configuración y afinación del arreglo (Cluster) de los elementos de cómputo y de almacenamiento del servicio Grid. c) La realización de talleres de capacitación técnica para administradores Grid de 32 horas académicas (Básico y Avanzada) y una pasantía en el Centro Nacional de Cálculo Científico de launiversidad de Los Andes (CeCalCULA) y otros centros en el ámbito nacional e internacional. 4.1 Organización de GridUIS. En la UIS se tienen recursos heterogéneos, desde sofisticados sistemas de HPC, salas comunes de informática, computadores de docentes, personal administrativo y docente, cluster especializados de los diferentes grupos, centros e institutos de I+D de la universidad. La arquitectura del Campus GridUIS es bastante flexible y permite agregar o quitar recursos tanto de computo como de almacenamiento de manera dinámica y de acuerdo a las necesidades de los usuarios El Grid se gestiona a través de un comité académico y en la operación del mismo tendrá personal técnico completamente dedicado, pero que tendría apoyo de la Dirección de Servicios de Información(DSI) de la universidad. Es importante señalar que dentro de la arquitectura del campus GridUIS se tiene un Grid experimental adscrito la Escuela de Ingeniería de Sistemas y a los diferentes grupos, Centros e Institutos de I+D en donde se van desarrollando e implementado en diferentes fases nuevas tecnologías de sistemas avanzados de computación y nuevas aplicaciones. 4.2 Arquitectura de GridUIS a nivel de administración. Como parte del proyecto EELA-2 en el que participa por Colombia la UAndes y la UIS se instalo el middleware glite[5]. El Grid EELA es un conjunto de recursos y servicios distribuidos geográficamente. Esta compuesto por varios sistemas de los cuales los principales son: El Sistema Manejador de Carga, (Workload Management Systems o WMS), el Sistema Manejador de Datos(Data Management, System o DMS), el Sistema de Información (Information Systems o IS), y el Sistema de Autenticación y Autorización (Authentication and Authorization Systems). 4.3 Arquitectura de GridUIS a nivel de usuario. En el GridUIS el acceso del usuario es través de una Organización Virtual (VO) de tal manera que su acceso al Grid sea transparente y de fácil manejo. El usuario no sabe donde corren los trabajos o donde están almacenados los datos, el simplemente siente que esta trabajando con una maquina Virtual. Cuando un usuario del Grid Computacional requiere hacer uso de el, comienza un proceso entre los servicios en el cual el trabajo pasa por unos estados en los cuales cada servicio interactúa con los otros para cumplir su función. Uno de los propósitos del GridUIS es desarrollar diferentes VO según el tipo de comunidad. Actualmente, esta en desarrollo una VO para el modelado y simulación de aplicaciones de Computational Fluid Dynamics(CFD) en problemas de contaminación atmosférica y en Bioingeniería. También, se pretende desarrollar VO en Física de Altas Energías 5. Perspectivas de integración de GridUIS con otros Grid El desarrollo e implementación de GridUIS busca integrar el campus universitario con la iniciativa regional del nororiente colombiano Grid Oriente y, este a través de la RedRENATA, con Grid Colombia en la que están participando 12 universidades colombianas. También, existe la posibilidad de crear un Grid binacional entre Colombia y Venezuela

68 para interconectar GridUIS con CECALCULA de la Universidad de los Andes en Venezuela. La otra posibilidad es que con la experiencia del proyecto EELA- 2 en el cual participa la UIS, la universidad se pueda integrar a otras National Grid Initiatives (NGI) en LA mediante la conexión a la red CLARA y mediante esta a otros NGI en Norte America, Europa y Asia. 6. Conclusiones La iniciativa de GridUIS mediante la participación en el proyecto EELA-2 permite crear la e-infraestructura que permitirá que los investigadores, los grupos, centros e institutos de investigación de la UIS tengan acceso a recursos de gran capacidad de computo y de almacenamiento lo que les permitirá participar en proyectos internacionales de gran nivel científico lo que hará visible a la comunidad científica de la UIS. También, a corto y mediano plazo la implementación de GridUIS permitirá la integración con otros Grid nacionales e internacionales. 7. References [1] John Taylor, [2] T. H e y a n d A. T r e f e t h e n, e- Science and its implications, Phil. Trans. R. Soc. Lond. A (2003) 361, [3] I. Foster, What is the grid?, d.pdf [4] H.R. Hoeger, The Venezuelan Academic Grid, CLCAR, UIS-SIC, Bucaramanga, 2007, pp [5] C. Diaz, Task Force National Grid Initiative NGI-Grid Colombia, CLCAR, UIS- SIC, Bucaramanga, 2007, pp [5] I. D. Ramirez y J. M. Nobsa, Implementación de los Servicios y Módulos Fundamentales para la Construcción y Puesta en Marcha de una Infraestructura Computacional Grid Usando el Middleware glite, Trabajo de Grado, Escuela de Ingenieria de Sistemas,UIS, Bucaramanga, 2008, pp

69 Neural Network, Kernighan-Lin and Multilevel Heuristics for the Graph Bisection Problem on Geometrically Connected Graphs Gonzalo Hernandez Center for Mathematical Modeling University of Chile Santiago, Chile Jorge Cornejo, Roberto Leon, Luis Salinas Department of Informatics Federico Santa Maria Technical University Valparaiso, Chile Abstract A neural network heuristic for the Graph Bisection Problem is studied numerically on geometrically connected graphs and its performance is compared with the Kernighan - Lin (KL) and Multilevel (ML) heuristics. For mediumscale sparse graphs with = 2000 to = nodes it was obtained that the NN heuristic applied to the Graph Bisection Problem present a greedy behaviour in comparison to other local improvements heuristics: Kernighan-Lin, Multilevel. The experimental results for large graphs recommend to use as partitioning heuristic for sparse geometrically connected graphs. I. INTRODUCTION The graph partitioning (GPP) is a well known NP-Complete combinatorial optimization problem, see refs. [4], [10], that has been applied in different areas of computer science, for example: processes load balancing (see ref. [6]) and circuit layout. Let =( ) be a finite, undirected and connected graph, where is the set of vertices and is the set of edges. The GPP consists then in finding subsets of vertices 1 2, the partition of set, verifying: [ X = = where = = (1) =1 =1 and such that the cardinality of the cut set: [ {( ) =1 6= } (2) =1 6= is minimal. Several heuristics have been proposed to solve GPP, see for instance refs. [2], [3], [9], [11]. Different computational studies, see refs. [1], [7], [8], [12], have shown that the best heuristic is Multilevel in terms of the distance to the optimal solution. In this work is studied numerically a neural network (NN) heuristic for the Graph Bisection Problem (a special case of the Graph Partitioning Problem). II. NEURAL NETWORK HEURISTIC FOR THE GBP A neural network with parallel dynamics is defined by, see ref. [5]: (a) a connectivity matrix = ( ) =1,where represents the interaction weight between neurons ; (b) a threshold vector =( ) =1,where is the threshold of neuron ; (c) a local transition function : (0) {0 1} Ã ( +1)=(! 1 ( +1) ( +1)) P ( +1)= ( ) =1 =1 (3)

70 where is the Heaviside function. In ref. [5] was proved that if the connectivity matrix is symmetric with non negative diagonal, the parallel dynamics (3) converges to fixed points or cycles of length 2. Therefore, the parallel dynamics (3) defines an optimization heuristic. A combinatorial optimization problem equivalent to the GBP must be obtained in order to solve it with an optimization heuristic of the kind (3) and defined by a quadratic objective function. First, we have to redefine the variables: {0 1} { 1 1} =2 1 Then: = 1 iff 1, =1iff 2 In addition: X X {( ) 1 2 } = (4) 1 2 X X = 4 {( ) 1 2 } + =1 =1 Hence the following combinatorial optimization problem is equivalent to the GBP: X X X min 1 { 1 1} 2 s.t. =0 (5) If the constraint is penalized: where: =1 =1 min { 1 1} ( ) = ( ) = 1 X =1 =1 =1 X ( ) (6) If = If 6= ( ) If 6= ( ) and is the penalization parameter. Therefore, a neural network can be associated to the GBP with connectivity matrix ( ) =( ( )) =1, zero threshold vector =(0) =1, Lyapunov functional ( ) and parallel dynamics defined by: X (0) { 1 1} ( +1)=( 1 ( +1) ( +1)) ( +1)= ( ) ( ) =1 (8) where ( ) is the sign function. The parallel dynamics (8) converges only to fixed points or cycles of length 2, which also are local minima of. Hence, it defines a local search optimization heuristic for. III. PERFORMANCE OF THE NN, KL AND ML HEURISTICS The numerical results were obtained using medium-scale sparse geometrically connected graphs, which are useful to measure the performance of heuristics that produce improvements in the solution by local changes. A geometrically connected graph of size and connectivity radius can be constructed by random points ( ) =1 in the unit square =[0 1] [0 1]. These points will represent the location of the nodes and it computes the graph connectivity matrix =( ). The nodes are connected and then = =1if and only if: q ( ) = ( ) 2 +( ) 2 (9) In figure 1 is shown an example of a geometrically connected graph with = 4000 and =0 028 =1 (7)

71 Figure 1. Example of a geometrically connected graph with =4000and =0 028 The performance of the Neural Network (NN), Kernighan-Lin (KL) and Multilevel (ML) sequential heuristics were computed using the graphs of table 1 and applying the methodology that follows: For each graph of table 1, 50 random initial conditions were generated: 0 { 1 1}. The NN, KL, and ML heuristics were applied starting n from each initial condition 0. The minimum cut was computed =min ( ) 0 6= o, where is the configuration obtained from 0 applying the dinamic (8). For the Multilevel heuristic were chosen a threshold equals to 500 and 1000, the Heavy Edge Matching for the coarsening phase and the Kernighan-Lin heuristic for the partitioning and uncoarsening with refinement phases, according to the results of refs. [1], [7]. Name #Nodes ( ) #Edges Radius Name #Nodes ( ) #Edges Radius Table 1. Geometrically connected graphs used for the numerical study. The numerical results that were obtained for the NN, KL and ML heuristics are summarized in tables 2 and 3. Heuristic NN KL ML (500) ML (1000) Graph [ ] [ ] [ ] [ ] Table 2. Comparison of the performance of the NN, KL and ML sequential heuristics.

72 From table 2 it is clear that the solutions computed by NN have the larger distance to the best known solution for the graphs used. In table 3 are shown the distance of the best solution computed by the NN heuristic and the KL heuristic with respect to the best solution computed by the other heuristics: ML(500) and ML(1000). Graph (500) (1000) (500) (1000) Table 3. Distance of the best solution computed by the NN heuristic with respect to the others heuristics. The NN heuristic presents a behaviour similar to a greedy heuristic; in fact, the quality of the solutions computed by NN tend to increase as increases. The greedy quality of the NN heuristic can be explained due to the sparsity and local connectivity of the geometric connected graphs used in this study. Finally the performance of KL is better that the ML(500) and ML(1000) heuristics in small size graphs but similar in large graphs. Acknowledgement. This work was partially supported by FONDECYT (Research Project and ) and UTFSM DGIP (Research Project ). IV. CONCLUSIONS The numerical experiments developed in this work allow to affirm that the neural network heuristic applied to the Graph Bisection Problem present a greedy behaviour: It obtains good solutions in shorter times in comparison to the other local improvements heuristics that were studied: Kernighan-Lin, Multilevel. The NN heuristic must be applied as a sub-heuristic of a local improvements heuristic. For this reason, in order to improve the convergence times of ML we propose that the partitioning and uncoarsening with refinement phases of this heuristic must be performed by the NN heuristic in the case of sparse locally connected graphs, such geometrically connected graphs. For large graphs, the results for best known solution and convergence times suggest that for sparse geometrically connected graphs is recommendable to use as partitioning heuristic. REFERENCES [1] Baños, R.,C. Gil, J. Ortega and F.G. Montoya, Parallel Heuristic Search in Multilevel Graph Partitioning, Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP 04), [2] Battiti, R., and A. Bertosi, Greedy, Prohibition and Reactive Heuristic for Graph Partitioning, IEEE Transactions on Computers, Vol. 48, No 4, April [3] Bui, T.N., and B. R. Moon, Genetic Algorithm and Graph Partitioning, IEEE Transactions on Computers, Vol. 45, No 7, pp , July [4] Garey, M.R., and D. S. Johnson, Computers and Intractability: A Guide to the Theory of NP-Completeness, New York: W. H. Freeman and Company, [5] Goles, E., and S. Martinez, Neural and Automata Networks, Maths. and Its Applications Series, V. 58, Kluwer [6] Hendrickson, B., Graph partitioning models for parallel computing, P. Computing, V. 26, N. 12, pp , [7] Karypis, G., V. Kumar, A Fast and High Quality Multilevel Scheme for Partitioning Irregular Graphs, SIAM J. Scientific Computing, Vol. 20, No 1, pp , [8] Karypis, G., V. Kumar, Multilevel k-way Partitioning Scheme for Irregular Graphs, Journal of Parallel and Distributed Computing, Vol. 48, Iss. 1, pp , [9] Kernighan, B.W., and S. Lin, An Efficient Heuristic Procedure for Partitioning Graphs, The Bell System Tech. J., Vol. 49, pp , [10] Papadimitriou, Ch.H. and S. Steiglitz, Combinatorial Optimization, Prentice-Hall, Englewood Cliffs, HJ, [11] Rolland, E., H. Pirkul, and F. Glover, A Tabu Search for Graph Partitioning, Annals of Operations Research, Metaheuristics in Combinatorial Optimization, Vol. 63, [12] Walshaw, C., Multilevel Refinement for Combinatorial Optimisation Problems, Annals of Operations Research, Vol. 131, pp , 2004.

73 Planning and Optimization of Drilling for Directional Wells Planificación y Optimización en la Perforación Direccional de Pozos Petrolíferos R. Hernández Postgrado de Modelado y Simulación de Sistemas Universidad de Los Andes Mérida, Venezuela P. Guillén Centro de Simulación y Modelos (CESIMO) Universidad de Los Andes Mérida, Venezuela F. Hidrobo Dpto. de Física Facultad de Ciencias Universidad de Los Andes Mérida, Venezuela G. Montilla Centro de Procesamiento de Imágenes Universidad de Carabobo Valencia, Venezuela Abstract This work presents a mathematical method to design a three dimensional (3D) well trajectory using cubic functions and genetic algorithm to find the optimum drilling depth. The trajectories are obtained for various conditions at the end of the trajectory, minimizing true measured depth. The use of cubic functions and genetic algorithm provides a continuous and smooth trajectory, connecting the current position of the hole (possibly at the surface) to a target on the geometric characteristics of the trajectory. Palabras Claves: Planificación, Optimización, Perforación direccional, Funciones cúbicas, Algoritmos genéticos 1. Introducción Se han publicado varios trabajos para diseñar trayectorias de pozos 3D: Planeix y Fox [1] en 1979 presentaron un trabajo en donde el ángulo de inclinación (desviación con respecto a la vertical) y el azimut (ángulo de desviación con respecto al norte geográfico hacia el este) los controlaban independientemente, pero se llegaba a una formulación implícita. En 1992 Mitchell [2] propuso resolver este problema, pero las expresiones que hacen uso de geometría analítica resultaron limitadas y no pudieron ser usadas bajo restricciones para alcanzar el yacimiento. En 1992 Guo et. al. [3] presentaron el método de la curvatura constante para resolver el problema de fijar restricciones para alcanzar el yacimiento, la determinación del ángulo de máximo crecimiento y otros parámetros necesarios. En 1995 Ebrahim [4] generalizó las expresiones de Mitchell utilizando álgebra vectorial y geometría diferencial. En el 2001 Liu y Shi [5] presentaron un método general donde dos arcos y una línea recta son usados para resolver el caso de establecer las restricciones al final de la trayectoria. En el 2003 Sawaryn y Thorogood [6] presentaron el método de la mínima curvatura. En el 2006 Sampaio [7] publico un trabajo para planificar, diseñar y optimizar trayectorias 3D haciendo uso de geometría diferencial, funciones cúbicas y un esquema de gradiente descendiente para la optimización de la trayectoria. Este trabajo basado en los estudios hechos en [7] presenta el uso de funciones cúbicas para obtener una trayectoria suave, que mejor se adapte a las herramientas de perforación 3D actuales, tomando en cuenta las cuatro restricciones más frecuentes al final de la trayectoria: ángulos de inclinación y azimut libre o fijos, inclinación libre y azimut fijo e inclinación fija y azimut libre. Adicionalmente, se determinan la inclinación, el azimut, la severidad de la curvatura (dog-legseverity, dls), y el ángulo y la dirección de la cara del taladro (tool face). Finalmente, un procedimiento de optimización basado en Algoritmos Genéticos (AGs) es utilizado para

74 minimizar la profundidad verdadera medida (TMD) de la trayectoria, obteniéndose mejores resultados que los presentados en [7]. 2. Materiales y métodos V &( 1 ) = L1 cos ( θ 1 ) & ( 1 ) = L1 sen( θ 1 ) cos E & ( 1 ) = L1 sen( θ1 )sen( ( ϕ 1 ) ϕ 1 ) (6) 2.1. Parametrización de la trayectoria Una curva en 3D puede ser expresada como: [ V( u), ( u), E u] P ( u) = ( (1) donde V,, y E son funciones de coordenadas que representan los puntos de la vertical, el Norte y el Este geográfico, y u tomará cualquier valor en el intervalo cerrado [0,1]. Con u = 0 para el extremo inicial de la trayectoria y u = 1 para el extremo final de la trayectoria. Una longitud infinitesimal ds de la trayectoria puede ser expresada por: ds = V& 2 & 2 E& 2 + N + du = P& P& du (2) Por lo tanto, la longitud s(u ) de la trayectoria entre el extremo inicial y cualquier punto P (u) de la trayectoria está dada por la integral: s(u ) u = [ V( ξ) ] 2 [ & ( ξ) ] 2 [ E& & + + ( ξ) ] 2 ξ 0 d (3) y la longitud total de la trayectoria está dada por S = s(1). De las definiciones de inclinación θ y azimut ϕ de cualquier punto de la trayectoria, las siguientes relaciones se cumplen: cos θ = dv / ds = ( du / ds )V& sen θ cos ϕ = d / ds = ( du / ds ) & sen θsen ϕ = de / ds = ( du / ds )E& (4) con du 1 ds = V& + & + E&. En los extremos inicial y final donde θ 0, ϕ 0, θ 1 y ϕ 1 son conocidas y haciendo uso de (4) se tiene: V( & 0 ) = L0 cos (θ0 ) ( & 0 ) = L0 sen( θ0 ) cos ( ϕ0 ) E( & 0 ) = L0 sen( θ0 )sen( ϕ0 ) (5) L 0 = V& 0 + & 0 + E& 0 y donde ( ) 2 ( ) 2 ( ) 2 = V& ( 1) 2 + & ( 1) 2 + E& ( ) 2. Las magnitudes L 1 1 de L 0 y L 1 están relacionadas a las funciones de coordenadas y sus especificaciones determinarán la forma final de la trayectoria 3D Funciones de coordenadas Las funciones de coordenadas V ( u), ( u) y E (u) son totalmente arbitrarias y pueden proveer el grado de libertad requerido para imponer las condiciones en los extremos de la trayectoria. Para cada función de coordenadas tres o cuatro condiciones pueden ser impuestas: la abscisa y pendiente en el extremo inicial, la abscisa en el extremo final, y generalmente la pendiente en el extremo final. Cualquier función continua conteniendo cuatro coeficientes independientes puede ser usada como función de coordenadas. En este trabajo se hace uso de funciones cúbicas las cuales contienen cuatro coeficientes independientes Funciones cúbicas Las expresiones generales de una función cúbica con su primera y segunda derivada son: 2 3 y( u) = Co + C1u + C2u + C3u 2 y& ( u) = C1 + 2C2u + 3C 2u (7) && y( u) = 2C + 6C u 2 3 donde u es una variable independiente. Para el propósito de este trabajo, se considerarán dos casos: 1) Pendiente libre en el extremo final del intervalo y 2) Pendiente fija en el extremo final del intervalo. En el primer caso las siguientes relaciones se cumplen en los extremos: y ( 0) = Yo; y(1) = Y1 ; y& ( o) = Yo & ; y&& (1) = 0 (8) Usando (7) y (8) se obtiene: Co = Yo C1 = Y& 0 C 2 = 1,5( Yo Y1 + Yo & ) C = 0,5( Yo Y + Yo & ) 3 1 (9)

75 En el segundo caso las siguientes relaciones se cumplen en los extremos: y ( 0) = Yo, y(1) = Y1, y& ( o) = Yo &, y& (1 ) = Y& 1 (10) Usando (7) y (10) se obtiene: Co = Yo; C 1 = Y& 0 C 2 = 3( Y1 Y0 ) 2Yo & Y& (11) 1 C = 2( Yo Y ) + Yo & + Y& 3 1 A manera de ejemplo haciendo uso de (5), (6), (7) y (11) se muestra una expresión para la función de coordenada V con pendiente fija en el extremo final: V ( u) = V0 + L0 cos( θ 0 ) u + 2 (3( V1 V0 ) 2L0 cos( θ 0 ) L1 cos( θ1 )) u 3 + (2( V0 V1 ) + L0 cos( θ 0 ) + L1 cos( θ1 )) u 1 (12) 2.4. Inclinación, azimut, curvatura, ángulo y dirección de la cara del taladro. Para calcular la inclinación y el azimut en cualquier punto de la trayectoria, un vector unitario t (u) tangente a la trayectoria debe ser determinado [8]. Si las componentes de los vectores unitarios tangentes son t V, t, t E, entonces la inclinación y el azimut en cualquier punto de la trayectoria se determinan mediante: t θ = ar cos t V y ϕ = arc tan E t La curvatura dls es normalmente expresado en 30x180 grados/30m y se determina por dls = κ, π donde κ es la magnitud del vector curvatura en un punto P (u). Para hallar el ángulo de la cara del taladro se hace uso de Ψ =arcos( h n) donde h es un vector unitario definido en la intersección de un plano vertical conteniendo la tangente a la trayectoria y el plano vertical a esta tangente, y n es un vector normal unitario K expresado por n = = ( nv, n, ne ). La dirección κ de la cara del taladro se determina por ( h n) t = ( h ne he n ) tv +. ( he nv hv ne ) t + ( hv n h nv ) t E Algoritmos Genéticos Los algoritmos genéticos (AGs) son métodos sistemáticos de optimización para la resolución de problemas que emulan la evolución biológica: selección basada en la población, reproducción y mutación [9]. Trata de hallar el conjunto ( ) i x n x i x n sea máximo o mínimo. Sus componentes básicos son los genes y cromosomas, donde cada cromosoma es una solución, y cada gen x,..., de tal manera que F (,..., ) sería cada uno de los i x i,..., x n buscado. El propósito de aplicar AGs consiste en reducir la profundidad verdadera medida (TMD) que se determina por la ecuación (3). En vista que las cantidades L 0 y L 1 son escogidas de forma arbitraria, éstas pueden ser optimizadas con el objetivo de reducir la TMD. Las cantidades L 0 y L1 van a representar los genes de los cromosomas. A cada cromosoma se le calcula un valor de ajuste (fitness) que en este caso es 2 ( TMD ), el ajuste es penalizado cada vez que el dls esté por arriba de 5 /30 m (curvatura no mayor a 5º por 30m para el mejor desenvolvimiento de los taladros). Se implantó una herramienta computacional en el lenguaje de programación Java, que contiene las formulaciones presentadas en las secciones anteriores, así como también, el modelo de AGs para determinar la trayectoria 3D optimizada. Esta herramienta permite visualizar la profundidad del pozo versus la TMD y la profundidad del pozo versus el dls. 3. Resultados x del conjunto ( ) A continuación se presentan los resultados para cuatro casos bajo restricciones al final de la trayectoria. Los datos para todos los casos en el extremo inicial y final de la trayectoria son: V 0 = 500 m; 0 = 5 m; E0 = 18 m ; o o θ 0 = 30 ; ϕ0 = 10 ; L0 = 3000 ; V 1 = 1600m ; 1 = 800m; E1 = 1000m ; L1 = Y para cada caso se varían los ángulos θ 1 y ϕ 1 en el extremo final de la trayectoria. Para cada caso estos datos son introducidos en el modelo de AGs, de manera de poder obtener las cantidades L 0 y L 1 que permitan reducir la profundidad verdadera medida TMD. Caso 1. Inclinación y Azimut fijos: En la Tabla 1 se muestran los resultados considerando o o θ 1 = 90 y ϕ 1=0, en pasos de El

76 método de AGs logra reducir la TMD de m a m, es decir, 138 m, para unos valores de L 0 = y L 1 = Tabla 1. Resultados de la trayectoria Paso V E TMD dls θ ϕ Ψ En la Figura 1 se muestra una visualización de la TMD no optimizada y optimizada versus la profundidad del pozo. 4. Conclusiones Los resultados presentados nos confirman que las funciones cúbicas pueden ser utilizadas para parametrizar una trayectoria 3D, y a su vez, facilitan la imposición de condiciones en los extremos de la trayectoria. Las trayectorias 3D obtenidas generan curvas suaves y continuas, siendo especialmente útiles para los modernos taladros direccionales. Finalmente, la aplicación de AGs nos permite obtener una trayectoria 3D optimizada, lo que conduce a una reducción de la profundidad verdadera medida (TMD), y una reducción en costos asociados a la perforación. 5. Referencias [1] Planeix M., Fox R Use of an Exact Mathematical Formulation to Plan Three Dimensional Directional Wells. Paper No. 8338, Las Vegas, Nevada, September. [2] Mitchell B Advance Oilwell Drilling Engineering Handbook, 10th ed., SPE-AIME, Dallas, Chap. 3, pp Figura 1. TMD versus profundidad del pozo. Caso 2. Inclinación y azimut libres: En este caso existe un solo grado de libertad L 0, de manera que θ 1 y ϕ 1 pueden tomar cualquier valor. El método de AGs logra reducir la TMD de m a m, es decir, 110 m, para un valor de L 0 = Caso 3. Inclinación libre y azimut fijado: o En este caso se considera ϕ 1=0 y θ 1 libre. El método de AGs logra reducir la TMD de m a m, es decir, 184 m, para un valor de L 0 = y L 1 = Caso 4. Inclinación fija y Azimut libre: o En este caso θ 1 = 90 y ϕ 1 libre. El método de AGs logra reducir la TMD de m a m, es decir, 163 m, para un valor de L 0 = y L 1 = [3] Guo B., Miska S., Lee R Constant Curvature Method for Planning a 3-D Directional Well. Paper No , Casper Wyoming, May. [4] Ebrahim A., General Three-Dimensional Well TrajecTory Planning for Single and Multiple Directional Wells. MS thesis No.T4708, Colorado School of Mines, GoldenCO, December. [5] Liu X., Shi Z Improved Method Makes a Soft Landing Of Well Path. Oil & Gas J., 99(43), pp [6] Sawaryn S, Thorogood J A Compendium of Directional Calculations Based on Minimum Curvature Method. Paper No , Denver, Colorado, October. [7] Sampaio J Planning 3D Well Trajectory Using Cubic Functions. Journal of Energy Resources Technology, Vol. 128, pp December. [8] Stoker J Differential Geometry. Wiley, New York, pp [9] Hidrobo, F. (2001). Computación Evolutiva. En Introducción a las Técnicas de Computación Inteligente. Mérida, Venezuela,

77 Implementation of a Computational Grid Infraestructure Based in the glite Middleware Using the Paravirtualization Technique Implementación de una Infraestructura Computacional Grid Basada en el Middleware glite Utilizando la Técnica de Paravirtualización Julián Mauricio Nobsa Vargas Universidad Industrial de Santander, Colombia Abstract This article explains the fundamental concepts for understanding a grid infrastructure and discuss about the general aspects of implementation and operation with the EGEE middleware, glite. Additionally, explain the methodology of implementation of the virtualization technique known as paravirtualization and the benefits it provides in the construction, configuration, implementation and administration of the platform. 1. Introducción La computación en grid surge como una respuesta a la necesidad de altas capacidades de procesamiento y almacenamiento principalmente por parte de la comunidad investigadora, estas necesidades se han visto cubiertas a través de una infraestructura que permite el uso de recursos compartidos por diferentes organizaciones que se encuentran geográficamente distribuidas y ha originado una oportunidad de mejora en los procesos de investigación debido a que posibilita el trabajo colaborativo y la transferencia y construcción colaborativa de conocimiento. El uso de infraestructuras grid es de gran importancia para el desarrollo e impulso de la investigación en el contexto colombiano, ya que nos permite acceder a recursos con los que no siempre cuentan las instituciones de nuestro país a la vez que posibilita concentrar y compartir los recursos que estas posean. Sin embargo la complejidad que conlleva la implementación de este tipo de infraestructuras es alta, siendo esto un factor que incide negativamente en la masificación y difusión de esta tecnología. Adicionalmente en el caso de este proyecto la limitante de recursos exigió la aplicación de mecanismos que permitieran implementar toda la infraestructura en una cantidad de recursos inferior a la requerida, esto se logró a partir de la técnica de paravirtualización, la cual no solo sirvió para solucionar este problema sino que también aportó diversas ventajas en la logística de implementacion de la infraestructura. 2. Infraestructura Grid Es una infraestructura de hardware y software que permite compartir y utilizar de forma coordinada diferentes tipos de recursos (cómputo, almacenamiento y aplicaciones específicas) que pueden ser heterogéneos (diferentes arquitecturas, supercomputadores, clusters) y que se encuentran conectados mediante redes de área extensa (por ejemplo Internet), sin la preocupación de ubicación física, facilitando la comunicación entre organizaciones geográficamente distribuidas. 3. Arquitectura general de una infraestructura grid La arquitectura general de un grid establece 4 capas, cada una de ellas agrupa un conjunto de recursos o servicios que se encargan de realizar labores enfocadas a cumplir un objetivo en común, las capas son las siguientes: Capa de red Network Layer Capa de recursos Resource Layer Capa de middleware Middleware Layer Capa de aplicaciones y servicios Software Application and Serviceware Layer Capa de red: Las redes son una pieza fundamental en una infraestructura grid, estas se pueden caracterizar según su cobertura y su desempeño, entendido éste como la cantidad de datos que puede transmitir en determinado intervalo de tiempo. El desempeño generalmente se mide en Kilo, Mega o Giga Bits por segundo. Debido a que en un grid se utilizan recursos geográficamente dispersos, son necesarias

78 redes de área extensa y de alto desempeño que cubran grandes distancias y puedan transmitir a altas velocidades. En esta capa se encuentran protocolos de seguridad y comunicación estándarizados para transacciones de red. Los protocolos de comunicación permiten el intercambio de datos en la capa de recursos mientras que los protocolos de seguridad brindan mecanismos de criptografía para mantener la seguridad en la identificación de usuarios y recursos. Capa de recursos: Esta conformada por los recursos computacionales físicos que serán compartidos por las diferentes organizaciones virtuales, estos pueden ser servidores de almacenamiento masivo, supercomputadores, clusters de alto rendimiento y hardware especializado como telescopios, microscopios etc. Capa de middleware: El Middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Funciona como una capa de abstracción de software distribuida, que se sitúa entre la capa de aplicaciones y la capa de recursos abstrayendo de la complejidad y heterogeneidad de estos y proporcionando una API para el fácil manejo de aplicaciones distribuidas. El middleware organiza e integra los recursos en un grid y está conformado por un conjunto de servicios software que implementan el acceso uniforme a los datos y recursos, el manejo de su información de estado, la planificación de la asignación de estos y la autenticación y autorización. En esta capa también se encuentran los servicios que permiten obtener la información de un recurso en particular y gestionarlo controlando el acceso, arranque de procesos, monitorización y auditoria. Capa de aplicaciones y servicios software: Es la capa del mas alto nivel de la estructura siendo visible a los usuarios e interactuando con ellos de varias maneras brindándoles facilidades para trabajar con aplicaciones en diferentes áreas como ciencia, ingeniería, finanzas y simulación entre otras. Las aplicaciones grid interactuan con otras capas como la de Middleware debido a que una aplicación necesita obtener las credenciales necesarias para autenticación con el fin de acceder a recursos y archivos, consultar su estado, determinar su ubicación y características, enviar solicitudes a la capa de recursos para extraer datos, iniciar cálculos y finalmente monitorizar el progreso de estos y las transferencias de datos así como notificar al usuario cuando lo análisis hayan finalizado suministrando los resultados, adicionalmente detectar y responder a fallos. La capa de aplicaciones también incluye algunos servicios que implementan funciones generales de manejo como seguimiento de quien provee los recursos y quien los está usando. 4. Arquitectura del middleware glite El middleware glite esta estructurado en una serie de módulos que se encargan de aspectos específicos del grid como el esquema de seguridad, los servicios de información y monitoreo, gestión de trabajos y servicios de datos. A su vez estos módulos están compuestos por una serie de elementos que estan relacionados fuertemente entre si y que configurados y sincronizados, permiten que los módulos de cada tipo de servicio funcionen correctamente. Los elementos mas importantes que constituyen los módulos de glite son: User Interface (UI): La interfaz de usuario es el punto de acceso al Grid, esta puede ser cualquier máquina donde los usuarios tienen una cuenta personal y en la cual el certificado de usuario está instalado. Desde una interfaz, el usuario puede ser autenticado y autorizado para utilizar los recursos, e inmediatamente acceder a las funcionalidades que ofrecen los sistemas de Información, Workload y Data Manager. La interfaz de usuario proporciona herramientas para realizar algunas operaciones básicas en el Grid sobre los recursos y los trabajos. Computing Element (CE): El Computing Element es el servicio que representa un recurso de cómputo. Su principal funcionalidad es la gestión de trabajos (envío y control de trabajos, etc). Tiene bajo su cargo los nodods que ejecutan realmente los trabajos conocidos como worker nodes, el CE actúa como nodo maestro de un cluster donde los nodos esclavos son los worker nodes. Storage Element (SE): Es el servicio que permite a un usuario o una aplicación guardar datos para la futura recuperación y uso de los mismos. Es consultado por las aplicaciones que requieran estos datos. Un Storage Element proporciona acceso uniforme a los recursos de almacenamiento de datos. El SE puede controlar servidores de disco simple, grandes arrays de disco o cinta, basados en los sistemas de almacenamiento masivo (MSS). Workload Management (WM): Su propósito es el de aceptar y satisfacer las solicitudes de gestión de trabajos procedentes los clientes. Para un cálculo de trabajos, hay dos tipos principales de petición: presentación y cancelación. En particular el significado de la petición de presentación es pasar la responsabilidad del trabajo al WM. El WM luego pasará el trabajo a un "CE" apropiado para su ejecución, teniendo en cuenta las necesidades y preferencias expresadas en la

79 descripción de trabajo. La decisión de cual recurso debe utilizarse es el resultado de un proceso de vinculación entre la presentación solicitudes y los recursos disponibles. BDII (Berkeley Database Information Index): El componente principal del Information Service es el Berkeley Database Information Index (BDII) que tiene la función de proveer la información del estado de los recursos de un grid, es a este elemento que el WM consulta por el estado de los Computing Elements y otros nodos. El BDII consiste en dos o mas bases de datos LDAP que son alimentadas mediante un proceso de actualización. El redireccionamiento de puertos es usado para habilitar una base de datos para ser servidor de datos mientras la otra se actualiza. Los anillos 1 y 2, tienen menos privilegios que el 0 y en estos se ejecutan servicios básicos del sistema, los cuales pueden ser llamados por las aplicaciones, por ejemplo protocolos de red y gestores gráficos, esto permite que los servicios acceso a los datos de las aplicaciones pero a su vez estén protegidos de estas, ya que las aplicaciones se ejecutan en el anillo 3. El anillo 3 es el de menor privilegio, y en este se ejecutan las aplicaciones, manteniendo así un esquema de seguridad para mantener la integridad de los recursos. La siguiente figura explica esta estructura: File Catalog (LFC): Este componente se encarga de manejar la información acerca de los archivos de datos presentes en todo el grid, hace las veces de servidor de páginas amarillas para los archivos que pueden ser usados como entradas para ejecutar trabajos o que los usuarios han almacenado. Es consultado por el WM para saber en que Storage Elements se encuentra determinado archivo. Adicionalmente a estos nodos descritos existen algunos otros para diferentes funciones como el monitoreo de trabajos a partir del Logging and Bookeeping, los cuales se pueden implementar en una misma máquina con otro elemento mas complejo. 5. Virtualización La necesidad de virtualizar parte de la disponibilidad de un número de recursos inferior al necesitado para implementar los nodos necesarios para el envío completo de un trabajo, esto plantea la necesidad de poder ejecutar diferentes sistemas operativos de manera simultánea en una máquina. Para esto se realizó un estudio de las diferentes técnicas de virtualización que permitían esto y se optó por la implementación de la técnica llamada paravirtualización por ventajas como las que se mencionan a continuación. 6. Paravirtualización Esta técnica se basa en la arquitectura de niveles de los actuales procesadores que consiste en que cada procesador tiene 4 niveles de privilegios representados por 4 anillos enumerados del 0 al 3. El anillo 0 es quien permite mayores privilegios de ejecución, permitiendo acceso sin restricciones al hardware, es en este anillo donde se ejecuta el kernel o núcleo del sistema operativo y normalmente los controladores de dispositivos. Figura 1. Estructura de anillos La técnica de paravirtualización consiste en la ubicación de un Hypervisor en el anillo 0, este Hypervisor es un software que tiene la funcionalidad de comunicarse directamente con el hardware, el kernel del sistema anfitrión pasa a ejecutarse en un nivel superior, dejando el anillo 0 asociado al hypervisor. Para poder realizar esto, se deben modificar tanto el kernel del sistema operativo anfitrión, como el de los sistemas operativos a virtualizar, esto podría parecer una limitante para poder paravirtualizar sistemas operativos no modificables como es el caso de los S.O's privativos, sin embargo es posible virtualizar este tipo de sistemas por medio de la paravirtualización haciendo uso de las tecnologías de virtualización VT-X de Intel y Pacifica de AMD presentes en los procesadores modernos, las cuales permiten ejecutar sistemas operativos en el nivel 0 sin tener que modificarlos, esto gracias a un nivel de privilegio especial en el anillo 0 para el hypervisor llamado root-mode también conocido como nivel -1, los demás componentes se ejecutan en otro nivel llamado non-root-mode. De esta manera quedan redistribuidos los componentes del sistema, en el anillo 0 se encuentra el hypervisor y en los anillos superiores se encuentran tanto el S.O anfitrión como de los sistemas operativos invitados y sus kernel que se comunican con el Hypervisor y este a su vez con el

80 hardware. La estructura de la técnica de Paravirtualización se detalla en la siguiente figura: anillo superior diferente del anillo 0 otra forma es obteniendo una imagen modificada del sistema operativo que incluya dicho kernel instalado a partir del arranque del dom0 los S.O paravirtualizados serán dom1, dom2 o mejor conocidos como domu. Scientific Linux Cern 4.4 distribución construida con base en Scientific Linux la cual a su vez está basada en RedHat Enterprise Linux 4, incluye paquetes del CERN el cual desarrolla glite, tiene gran soporte en la comunidad que hace uso de ella y tiene una gama amplia de paquetes precompilados, entre ellos los paquetes necesarios para iniciar el S.O como dom0. Cada nodo de los que conforman glite y que son fundamentales para el envío completo de un trabajo fué implementado en un domu, de forma tal que cada nodo es independiente del otro y la cantidad de máquinas físicas a utilizar disminuye, logrando implementar un grid funcional con varios nodos por cada máquina física. Figura 2. Estructura de la Paravirtualización Entre las ventajas de esta técnica se encuentran: Facilidad para la migración en caliente sin perdida de desempeño en las máquinas que están siendo virtualizadas. Heterogeneidad en los S.O's a virtualizar ya que los sistemas operativos invitados no tienen que compartir un mismo kernel. Gran rapidez de ejecución al no tener que realizar emulación alguna. Portabilidad, ya que las imágenes de los S.O invitados se pueden extraer con facilidad y es posible convertir imágenes de sistemas operativos virtualizados con otras técnicas en imágenes de paravirtualización. Escalabilidad, debido a que inicializar una imagen puede hacerse con mucha facilidad y son totalmente aisladas de tal forma que no se afectan en caso de problemas. 7. Metodología de implementación Para el montaje y configuración de las máquinas paravirtualizadas es necesario primero configurar el arranque del computador permitiendo que el Hypervisor se ubique en el modo privilegiado (anillo 0) y posteriormente el sistema operativo que va acompañado del hypervisor, llamado de otra forma el dom0. Con el fin de iniciar el hypervisor en el anillo 0 es necesario modificar el sistema operativo GNU/Linux Scientific Linux Cern 4.4 instalándole un kernel modificado que permita ejecutarse en un 8. Conclusiones La implementación de los nodos que componen un grid utilizando el middleware glite se puede realizar paravirtualizando cada nodo, de manera que se logra tener para cada elemento de estos las ventajas que con lleva el uso de esta técnica. La técnica de paravirtualización provee de un rendimiento aceptable para la mayoría de nodos, sin embargo para nodos que realicen operaciones complejas como los worker nodes es recomendable estar instalados en una máquina física. La labor de instalación, configuración y sincronización de los nodos se facilita con el uso de la paravirtualización ya que probar una nueva configuración es sencillo utilizando máquinas virtuales que se activan y desactivan con facilidad, ventaja que no se tiene con la instalación de los nodos en máquinas físicas. 10. Referencias [1] Programming the Grid with glite Laure, E.(CERN, Geneva, Switzerland ) et al 22 March 2006 EGEE. [2] Introduction to High Performance and Grid Computing, Architecture and Services of the glite Middleware, Dusan Vudragovic, Faculty of Sciences University of Novi Sad, Scientific Computing Laboratory, Institute of Physics Belgrade, Serbia, Feb 6 of [3] The glite Middleware distribution, OSG Consortium Meeting, Seattle, August [4] J. Nobsa, I. Rodriguez, G. Díaz. Estudio Comparativo de las Técnicas de Paravirtualización y Virtualización a nivel de Sistema Operativo. Bucaramanga, Colombia. Agosto 2008.

81 Parallel Design the Algorithm of Digital Images Segmentation Split & Merge Andrea Reyes Biomedical Engineering Research Group UIS, Colombia Víctor Martínez Biomedical Engineering Research Group UIS, Colombia Ana Ramírez Connectivity and Signal Processing Group UIS, Colombia Abstract This work presents the design of a parallel algorithm based in the Split & Merge regions method (Horowitz and Pavlidis, 1974) for the Segmentation process of Digital Images, in this case Uterine Cervix samples. The proposal utilizes the methodology for the designing parallel algorithm of Ian Foster (Partitioning, Communication, Agglomeration and Mapping). 1. Introduction Image Segmentation is a key step in Image Processing. Subdivide an image into constituent objects, called regions; it is the process of assigning pixels to each region having common properties, using image attributes such as pixel intensity, spectral values and textural properties [3, 5, 15]. Let R represent the entire image having different objects. An Segmentation of R is a partition of R into subsets R 1, R 2,, R n, such that [12]: n (a) U i=1 R i = R, (b) R i is a connected region, i, (c) R i R j = i,j,i j, (d) P R i =TRUE i, (e) P R i R j = FALSE i,j,i j, Where P R i is a logical predicate over the set of pixels in the set of pixels in R i and is the empty set. Proposition (a) indicates that segmentation must be complete, that is, every pixel must be in a region while the second one indicates the pixels belonging to a region must be connected. The proposition (c) represents that the regions must be disjointed, and (d) deals with the properties that must be satisfied by the pixels in every segmented region R i in such a way P(R i ) = TRUE if all pixels in R i are equivalent with respect R i and R j are different in the sense of predicate P. The Segmentation algorithms can be based in two approaches [5]: First, the discontinuities of the pixels, which the main areas of interest are the detection isolated points and the detection of edges and lines. Second, the similarity of the pixels, where is usual to use algorithms such as threshold or oriented regions (Growth or Split & Merge), since grouped the pixels according to similar properties. The algorithms used for the detection of limits and threshold are not very effective, due to they do not make use of spatial information, so the oriented regions are most suitable for the type of Uterine Cervix medical images. The region growing algorithm uses a set of points generators from which it will increases the region, the fundamental problem is to correctly determine the set of initial points. Another alternative is the algorithm Split & Merge, it subdivides the original image into a set of arbitrary disjunct regions and then merge the regions to try to satisfy the criteria of homogeneity, steps that solves the region growing problem. On the other hand, the method based on regions, to determine the location of the final frontier, it has the difficulty of a high consumption of computational resources, which is particularly relevant in applications that require real time response and for this reason, the parallel algorithms constitute a very important approach to solve this problem. The Split & Merge Algorithm proposed by Horowitz and Pavlidis [2, 4] in 1974 is one of the most popular algorithms for image segmentation.

82 The algorithm may be summarized by the following steps [3, 8]: (1) Split any region R i into four almost equal regions where P(R i ) = FALSE. (2) Merge any adjacent regions R i and R j for which P( R i U R j ) = TRUE. (3) Stop when no further merging or splitting is possible. Otherwise repeat steps (1) and (2). The application area is the Medical Images for this research and the input images are Uterine Cervix samples. The Cervical Cancer is the second type of cancer most frequently in the female population; the diagnostic is that near 80% of the cases in not developed countries. The test of Cervical Cancer cytology is used to establish the population of women at risk of this cancer, in Bucaramanga (Colombia) finding cases of slight displace, 736 moderate displaces, 289 several displaces, in the years 2000 and 2001 [13, 18]. In the Biomedical Engineering Research Group (GIIB) the Industrial of Santander University (UIS), has been performed research works in undergraduates and postgraduates in the field of Digital Image Processing in the detection of Cervical Cancer, however there have been problems in the stage of segmentation, where the main inconvenient to implement an image processing system to support analysis, is that the images acquired in the test are large size and quantity, and the time is quite large [10, 11, 13, 14, 16, 17]. Faced with this situation it is proposed to design a parallel algorithm based on the regions method Split & Merge, with the purposed to posterior implement and evaluate the reduction in the execution time, since at present has not been achieved an optimal sequential implementation, due to that in different tests performed has been come to use all the computational resources available without to obtain a result. 2. Split & Merge Regions Method The Algorithm Split & Merge requires two types of operations [3]; a fast split phase which is followed by one or more merge phases. The split stage partitions an image into square regions which conform to a first homogeneity criterion; then merge these square regions into larger regions which conform to a second homogeneity criterion. The Split stage consists of generating a quad tree (see Fig. 1), where nodes at level i are the result of splitting the sub images of size N 1 / 2 i x N 2 / 2 i into four sub images of size N 1 / 2 (i+1) x N 2 / 2 (i+1) [3, 5]. The construction of this quad tree can be carried out following a Bottom up strategy of merging subimages or Top Down strategy of splitting [2, 4]. Figure 1. Quad tree representation In both strategies, only those nodes satisfying the homogeneity criterion will be generated. The Split phase ends when no more square regions can be generated. The set of leaves (regions) on the quadtree produced by the Split phase will be the set of input regions for the Merge phase. The homogeneity criterion of the one region is given by the gray levels of pixels that comprise, establishing a criterion of uniformity. Let X i, i=1,2,3,...n the gray levels of pixels that make up a region R. The average value of gray levels in the region R, is the arithmetic average of gray levels of pixels [9]: i=1 X i n X R = n (1) A region R is uniform gray levels, if for every sub regions r i R, is satisfied that the ratio between the minimum of the average values of gray levels of the R region and a sub region r i and the maximum of these values is less than or equal to That is, Min X R, X ri Max X R, X 0,95 ri,i=1,...4 (2) ri And the region is homogeneity in gray levels if it satisfies with the criterion of uniformity.

83 3. Design Parallel Algorithm of Ian Foster This methodology structures the design process as four following stages (see Fig. 2). In the first and two stages, the focus is on concurrency and scalability. In the third and fourth stages, attention shifts to locality and performance [1]. Figure 2. Methodology for design parallel programs i) Partitioning: The partitioning stage of a design expose opportunities for parallelism. The focus is on defining a large number of small tasks, fine grained decomposition of a problem. ii) Communication: The tasks require data associated with another task. Data must then be transferred between tasks so as to allow computation to proceed. In the communication is defining a channel structure that links and specifies the messages that are to be sent and received on these channels. The communication can be classified in local global, structured unstructured, staticdynamic, and synchronous asynchronous. iii) Agglomeration: The task and communication structures determined in the two previous stages are evaluated against the requirements of performance and costs implementation, to obtaining an algorithm that will execute efficiently on some class of parallel computer. If necessary, the tasks are combined to increase performance and reduce the communication and may still be greater than the number of processors. iv) Mapping: In the final stage, specify where each task is to execute and assigned to each processor. Operating system or hardware mechanisms can be relied upon to schedule executable tasks to available processors. The goal in developing mapping algorithms is minimize total execution time. 4. Proposed Algorithm i) Partitioning: The Split step is inherently parallel task. Initially, an image of size N = N 1 x N 2 is partitioned into P = P 1 x P 2 sub images that containing adjacent pixels N 1 /P 1 x N 2 /P 2 [6]. The structure for represent the regions of the image is the Quad tree [5, 7]. ii) Communication: Each processor work splitting and merging regions, this corresponds to either removing or building nodes of the tree structure [5], communicates transferred data of the adjacency node, this information is stored using an adjacency matrix. Each processor communicates too with others processors for merge regions, satisfying the homogeneity criterion, and the constraints (a) (e) in the steps (1) (3) (see section 1). iii) Agglomeration: In the quad tree representation are defined the method for identifying regions (Id), for this method use a cyclic and random strategy [3, 6], each processor assigns an Id to each region. The Ids should be different for each region and regions in every processor. The Id assigned in the quad tree contains the information the vertices and edge the region. For select the task concurrently use a load balancing describes in the next step. iv) Mapping: The process of the merge between regions are data dependent and the performance of communication, agglomerate and map the algorithm decreasing with the execution time, in this case the algorithms for static and dynamic load balancing are necessaries. For the load balance locally the dynamic balanced algorithm, assigning identifiers cyclic, is suitable and the dynamic balanced algorithm with assignment identifiers random for the load balance global [3]. The parallel algorithm can be describes by the following steps [3, 6, 5, 7, 8]: Step I: Partitioning the image P1 x P2 in four subimages and mapped onto the set of Processors. Step II: Each Processor realized the Split on its own sub image and assigns an identifier (Id) to each of the created regions. Step III: Each Processor builds its own local tree by creating the set of edges between its own local regions which satisfy homogeneity criteria. Step IV: Processors exchange information about the regions at the border of the initial sub image and create the set of edges between regions that belong to different neighboring Processor. Step V: Each region determines the linked regions that best suit the homogeneity criterion as regions to be merged. If more than one region are candidates to

84 merge with it will be selected that region with the minimum Id. Step VI: Processors must exchange information about the best selection for those linked regions located at different Processor. Step VII: The vertices and edges of the tree are updated for the current set of regions. Step VIII: Run the algorithm for load balancing. Step IX: Repeat steps V VIII while linked regions still exist. Otherwise the algorithm ends. 5. Discussions and Future Work The algorithm proposed is for implement in a SPMD programming model and working in architecture MIMD with the message passing MPI. The importance of this research is given to contribute to the development of the line of research on Digital Image Processing in the area of High Performance Computing on the GIIB; in the solution to the problem of the cost of time processing images Uterine Cervix for diagnostic Cervical Cancer. 6. References [1] Foster, I. Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering. Addison Wesley Longman Publishing Co., Inc [2] Horowitz, S.L. and Pavlidis, T. Picture segmentation by a directed split and merge procedure. Proceedings, 2nd International J. C. on Pattern Recognition, Copenhagen, [3] Montoya, M. D. Gil, C. and García, I. The load unbalancing problem for region growing image segmentation algorithms. J. Parallel Distrib. Comput. 63, 4 (Apr. 2003), [4] Horowitz, S. L. and Pavlidis, T. Picture Segmentation by a Tree Traversal Algorithm. J. ACM 23, 2 (Apr. 1976), [5] Kelkar, D. and Gupta, S. Improved Quadtree Method for Split Merge Image Segmentation. In: Proceedings, First international Conference on Emerging Trends in Engineering and Technology Volume 00 (July 16 18, 2008). ICETET. IEEE Computer Society, Washington, DC, [6] Montoya, M.D.G.; Gil, C.; Garcia, I., "Load balancing for a class of irregular and dynamic problems: region growing image segmentation algorithms," Parallel and Distributed Processing. Proceedings of the Seventh Euromicro Workshop on, vol., no., pp , 3 5, Feb [7] Tyagi, A.; Bayoumi, M., "Systolic array implementation of image segmentation by a directed split and merge procedure," Pattern Recognition, Proceedings., 10th International Conference on, vol.ii, no., pp vol.2, 16 21, Jun [8] Faruquzzaman, A.B.M.; Paiker, N.R.; Arafat, J.; Karim, Z.; Ameer Ali, M., "Object segmentation based on split and merge algorithm," TENCON IEEE Region 10 Conference, vol., no., pp.1 4, 19 21, Nov [9] Alvarez M, Rivas M. and Rukoz M. Segmentación de Imágenes Biomédicas Mediante el Crecimiento de Regiones. Acta Científica Venezolana, 52: , 2001 [10] Martinez, V. et al Tecnología Grid para la Detección de Cáncer de Mama y Cuello Uterino por Medio de Procesamiento de Imágenes. CLCAR Colombia, Agosto 2007, [11] Niño, D. et al. Contribución al estudio de las células escamosas de citologías cérvico uterinas que presentan cambio por ASCUS, por medio de tratamiento digital de imágenes. Trabajo de Grado. UIS [12] Gonzalez, R.C. Woods, R.E. Digital Image Processing, 2nd Edition, Prentice Hall, Inc., Upper Saddle River, NJ [13] Martinez, V. et al. Computational model for squamous cells characterization during cervical smear cytology. Rev. Colomb. Biotecnol. Vol. VII No. 2 Diciembre 2005, [14] Amaya, M.L. et al. Contribución al estudio de las Células Escamosas de Citologías Cérvico Uterinas que Presentan Cambios por Virus de Papilona Humano (VPH), utilizando Tratamiento Digital de Imágenes. Trabajo de Grado. UIS [15] Tilton, J.C., "Image segmentation by iterative parallel region growing with applications to data compression and image analysis," Frontiers of Massively Parallel Computation. Proceedings., 2nd Symposium on the Frontiers of, vol., no., pp , Oct 1988 [16] Martinez, V. Modelo Computacional para Caracterización de células endocervicales. Trabajo de Maestria. UIS [17] Martinez, V.E. et al. Software Tool for Squamous Cells Classification in Cervical Smear Cytologies ICCB2005: Proceedings of II International Conference on Computational Bioengineering, IST Press, Lisbon, 2: [18] Universidad Autónoma de Bucaramanga Registro de población de cáncer en el área metropolitana de Bucaramanga

85 Implementation of a Computational Cluster in a Non-dedicated Environment Using a Diskless Methodology Implementación de un Cluster Computacional en un Ambiente no Dedicado Usando una Metodología Diskless Cristian C. Ruiz Sanabria Erick Menéses C. Universidad Industrial de Santander, Colombia Abstract The computational Clusters have reduced to a reasonable cost the demand of computing that current researches require. Although, its cost is lower than the cost of a supercomputer, the processing power is directly proportional to the number of computational resources dedicated to it. Commonly, organizations have a huge number of computational resources dedicated to different activities, many of them are only being used during his labor times and in the remain time they stay inactive. This work pretends to develop a solution that can take advantage of this idle time, based on ramfs technology used on ramdisks, which allow to store a root file system completely in RAM. This propose has the objective of creating a diskless environment that provides a good performance of parallel applications execution, as well as the capacity of doing a deploy without any change in the client`s computer and with few configuration required on behalf of the user. 1. Introducción Los sistemas diskless son una interesante opción para la implementación de clusters computacionales por los siguientes motivos: disminuyen el costo total del sistema, reducen las posibilidades de fallas en disco, son más fáciles de administrar, además del hecho de que muchas aplicaciones de cálculo intenso no requieren ninguna unidad local de almacenamiento. Pero la ventaja más significativa de estos sistemas es la posibilidad de integrarlos a infraestructuras de cómputo existentes para la utilización de los recursos ociosos. En este artículo presentamos nuestro trabajo, el cual consistió en el desarrollo de un sistema diskless que se adaptara a nuestras necesidades, utilizando los recursos ociosos presentes en las salas de cómputo del campus universitario. El presente artículo está organizado de la siguiente forma: En la siguiente sección se hace una revisión del estado del arte, seguidamente y a partir de esto se expone la propuesta planteada, su desarrollo, funcionamiento y finalmente en las dos últimas secciones se muestra los resultados experimentales obtenidos y las conclusiones de nuestro trabajo. 2. Estado del Arte Por un lado la dificultad para encontrar recursos computacionales dedicados a procesamiento, y por otro la abundancia de los mismos dedicados a otros oficios donde solo se usa una fracción de su capacidad, han hecho que aumente el interés y estudio en infraestructuras cluster flexibles que puedan aumentar su poder computacional haciendo uso del tiempo de procesamiento ocioso con maquinas de la organización. Dicha propuesta ha sido abordada desde diferentes puntos de vista y el objetivo es claro llegar a usar la misma máquina para dos actividades distintas: las actividades rutinarias de la organización y como un nodo de procesamiento para un cluster. Con el fin de conservar la integridad de la configuración y ciertos componentes del cluster, no es factible que el usuario en su trabajo diario pueda utilizar el mismo espacio de trabajo y sistema, que utiliza el cluster. Además se ha demostrado en [1] que el sistema más utilizado es Windows con más de un 90 % de uso y el ambiente común en las implementaciones cluster es Linux. Esto conlleva a que se necesite dos sistemas completamente separados, uno para el cluster y otro para el usuario común, para lo cual han surgido las siguientes soluciones:

86 1. Uso de maquinas virtuales. 2. Alojamiento de los sistemas en dos particiones diferentes que se ejecutan a diferentes turnos. 3. Metodología diskless. NDEE [2] utiliza una técnica basada en máquinas virtuales, que permite explotar los recursos incluso cuando estos están utilizándose, se basa en la premisa de que las maquinas desperdician ciclos de procesamiento, mientras están interactuando con el usuario en tareas como: digitar texto o esperar una descarga. Otros sistemas como ICluster [3] utilizan una partición del equipo cliente, esta es creada en un archivo por un programa de instalación y sirve como espacio de almacenamiento para el sistema de archivos raíz. La maquina es monitoreada para poder reiniciarla en el momento debido. Sistemas como Pelican 1 2 y computemode utilizan espacio en RAM y almacenamiento en un servidor, el cual provee un ambiente que permite el despliegue de los sistemas sin la necesidad de modificar la computadora cliente. Se basan en el uso de un servidor que es el encargado de almacenar y proveer los sistemas de archivos que van a utilizar cada uno de los sistemas desplegados. Utilizan la tecnología PXE [4] permitiendo que las computadoras puedan arrancar por medio de la red. Pelican fue desarrollado con un propósito más académico y de pruebas. Computemode es una solución más robusta provista con el manejador de colas OAR 3 el cual hace que esta solución sea factible para trabajos de producción. 3. Propuesta El trabajo que se presenta en este artículo consistió en el desarrollo de un nuevo sistema que se acoplara a nuestras necesidades, a través del uso de algunos componentes pertenecientes a infraestructuras existentes y el desarrollo de otros nuevos. Actualmente las implementaciones cluster basadas en diskless presentan ciertos inconvenientes, principalmente porque el sistema de archivos raíz de los nodos clientes es cargado por medio un sistema de archivos de red, generando cierta latencia en la ejecución del sistema como se muestra en [5] y tráfico en la red [6] que aumenta con el 1 PelicanHPC, 2 Computemode Grid Manager, Deploying lightweight framework on intranets, 3 OAR, Resource Management System for High Performance número de nodos. Dado que una aplicación paralela hace uso intensivo de la red, provoca que infraestructuras de red que no presentan gran ancho de banda como pueden ser fast ethernet, no sean una muy buena alternativa para el montaje de un cluster diskless ya que degradaría seriamente el desempeño de este. Teniendo en cuenta lo anterior se buscó una manera de ten er un sistema Linux completamente almacenado en RAM, para esto el tamaño total del sistema debería ser pequeño con el fin de disponer de suficiente memoria, para la ejecución del sistema y sus respectivos procesos. La solución fue el uso del sistema de archivos ramfs [7], el cual utiliza el mecanismo de caching del kernel Linux como un sistema de archivos dinámico y liviano basado en RAM. Este sistema de archivos es utilizado en casi todas las distribuciones Linux, para implementar el initramfs [8], cuya misión es cargar módulos y realizar algunas configuraciones iníciales, que permitan el montaje del verdadero sistema de archivos raíz que normalmente estará en disco. El uso de esta tecnología permitió tener un sistema completamente almacenado en memoria RAM, sin requerir almacenamientos externos como un servidor o alguna unidad local de almacenamiento. 4. Desarrollo del sistema El Desarrollo del sistema se describirá en tres etapas las cuales se detallaran a continuación Implementación del Sistema Base El sistema debía ser liviano con el fin de que fuera factible almacenarlo en la memoria RAM de la computadora, para esto se eliminaron módulos y servicios innecesarios sin perder funcionalidad en el sistema, incorporando los elementos esenciales para el funcionamiento y administración de un sistema Linux. Obteniéndose finalmente, un sistema completamente funcional, en un tamaño aproximado de 50 MB Optimización del despliegue Dado que el servicio de DHCP el cual es utilizado por Computemode, presenta unos tiempos de petición y adquisición que hacen que el proceso de despliegue demore varios segundos. Se desarrolló una serie de elementos que permiten la asignación de la dirección ip por medio de la línea de comandos del kernel, la cual es suministrada por el cargador de arranque pxelinux. Computing,

87 4.3. Mecanismo de Incorporación de Aplicaciones reservados. Finalmente cuando la reservación termina las maquinas vuelven a su estado inicial. Para incorporar las demás herramientas necesarias en un cluster, se desarrollo un conjunto de scripts que permite a petición del usuario, la integración de las aplicaciones requeridas en las imágenes desplegadas; permitiendo tener ambientes configurables para diferentes necesidades. 5. Funcionamiento del Sistema En la siguiente grafica se describe el proceso de carga del sistema operativo en un nodo de cómputo. Figura 2. Despliegue de una Aplicación Las aplicaciones pueden ser integradas en caliente con el procedimiento que anteriormente se describió, o pueden configurarse para que las aplicaciones se carguen cuando el sistema es desplegado a los nodos. 6. Pruebas y Resultados La implementación fue evaluada en 40 computadores. Cada máquina incluido el servidor implementado, contaba con las siguientes características: CPU Intel Pentium GHz, 2 GB de memoria RAM; todas las maquinas conectadas por una red Fast Ethernet de 100 Mbs Pruebas de despliegue Figura 1. Proceso de carga del sistema operativo en un nodo. El proceso es similar a las implementaciones diskless tradicionales. La gran diferencia presente, es la no necesidad de montar un sistema de archivos raíz por medio de NFS, además de contar con un mecanismo de incorporación de aplicaciones por demanda. La grafica a continuación muestra el funcionamiento del mecanismo de despliegue de aplicaciones. Si el usuario desea un conjunto de recursos con determinada aplicación, lo primero es la reservación de estos recursos por medio de OAR, una vez obtenidos los recursos, el usuario a través de los comandos implementados en este trabajo, despliega la aplicación deseada en los nodos Figura 4. Tiempo de despliegue En la grafica se observa el tiempo de despliegue, el cual comprende la transferencia del kernel, el ramdiks, el software de aplicación que en este caso fue MPICH y la completa carga del sistema. Estos resultados se contrastaron con los tiempos de despliegue de Computemode y como se puede apreciar, se obtienen mejores resultados.

88 6.2. Pruebas de rendimiento 8. Trabajo Futuro Ya que estos sistemas están diseñados para ejecutarse en ambientes no dedicados, una funcionalidad que debe incorporarse es un mecanismo de checkpointing, el cual permita almacenar el estado de un trabajo y su posterior reanudación. 9. Bibliografia [1] Gillen A, Kusnetzky D, Sayana A, Dayal H, Hingley M. Windows Operating Environment Forecast and Analysis. IDC publisher, document 24827, Figura 5. Desempeño del Sistema Se ejecuto el benchmark linpack 4 con el fin de medir la capacidad de procesamiento con determinado número de nodos, se realizaron pruebas con diferentes tamaños de sistemas de ecuaciones a solucionar, los cuales están representados en la grafica por la letra M. El máximo rendimiento obtenido fue de Gflops que corresponden a 24 nodos. Este rendimiento puede ser comparado con el rendimiento teórico de una computadora súper escalar con la siguiente ecuación [9]: Rpeak = ncores nfpu f Lo cual resulta para los procesadores utilizados en estas pruebas en un rendimiento teórico de Gflops. Con esto podemos calcular la eficiencia, dividiendo el rendimiento obtenido entre el teórico dando como resultado una eficiencia de 76.80%. 7. Conclusiones La implementación presentada en este trabajo, permite aumentar la capacidad de cómputo de un cluster sin incurrir en la adquisición de equipos dedicados. El sistema implementado presenta un buen rendimiento en la ejecución de software en paralelo, como lo comprueba la eficiencia obtenida en las pruebas experimentales. Aunque el sistema es almacenado en memoria RAM, se pudo observar que es posible ejecutar procesos demandantes en memoria, como el benchmark linpack. [2]Reynaldo Navaes, Paulo roisenberg, Roquer Scheer, Non dedicated distributed enviroment: an Solution for Safe and Continous Explotation of Idle Cycles. [3]Bruno Richard, Philippe Augerat. I-Cluster: Intense computing with untapped resources. HP Laboratories Grenoble April [4] Pxe specification, The Preboot Execution Environment specification v2.1 published by Intel y Systemsoft. September [5] James H, Laros III, Lee H ward. Implementing Scalable Disk-less Clusters using the Network File System (NFS). Sandia National labs. October [6] Baris guler, Munira Hussain, Tau Leng, Victor Mashayekhi. The advantages of Diskless HPC Clusters Using NAS. Dell power solutions November [7] Kernel org Home page. What is ramfs?. Available on: mfs-rootfs-initramfs.txt. Consulted in 26 july [8] Landley, Rob (15 March 2005), Introducing initramfs, a new model for initial RAM disk, Articles/Introducing-initramfs-a-new-model-for-initial- RAM-disks/ [9] TobiasWittwer, An Introduction to Parallel Programming, VSSD Netlib,HPL A Portable Implementation of the High- Performance Linpack Benchmark for Distributed-Memory Computer,


90 Experiences and Considerations on e Infrastructure Development in Brazil and Latin America Marcio Faerman Rede Nacional de Ensino e Pesquisa RNP In the recent years the world has been experiencing a large growth (and dependence) on digital information. High performance computing and networking are crossing more and more the boundaries from leading edge e science to the typical everyday access to the Internet. In this talk, we will focus on the evolving context of e infrastructure and in Brazil and Latin America. Brazil has gone through several stages of high performance computing and networking development, in support of the country science and technology. Today, the country counts with eight centers focused on massively parallel applications which integrate the SINAPAD the National System of High Performance Computing. There are also a number of HPC efforts including initiatives in the areas of High Energy Physics, Oil and Gas and Climate. Grid computing is a focus of Brazilian high throughput computing projects such as the European & Latin America consortia EELA 2, HEPGrid and SPRACE collaborations with OSG, the opportunistic Grid computing project OurGrid, the infra structured Virtual Community Grid (VCG) project and others. This talk will also go over science and technology initiatives which make use of high performance computing. They include the areas of biology, astronomy, medicine, weather prediction and agriculture. We will also describe the high speed network infrastructure in Brazil the metropolitan optical networks, the national research and education backbone from RNP and the international connectivity to RedClara, GEANT and North America. Finally, we will talk about distributed services which support distributed computing applications in the region. We will describe the upcoming hybrid network technology which provides both end to end circuits and best IP services, which is being developed for the Brazilian NREN. The goal is to provide better quality of service for e science, HPC and massive data applications. Other services include the public key infrastructure (PKI) for academic institutions ICPEDU. And the perfsonar multi domain network monitoring consortia involving Internet2, GEANT, RNP, CLARA, Latin America and European NRENs.

91 Towards Adaptive MPI Programs Nicolas Maillard Standard parallel programs are based on MPI, OpenMP/Posix threads, or a mixture of both in the case of clusters of multicore nodes. Both the current architectural trends and the non-predictable behavior of HPC applications require adaptivity from the parallel programs. Typically, the load has to be balanced at runtime, according to the CPU, Memory or Network necessities. However, the classical way to program an application with MPI/OpenMP is to divide the work among a fixed set of communicating processes (one by CPU), with inner OpenMP or threads parallelization (one thread by core). The load balance is based on the internal data structures of the program. We will explore the different ways that MPI and/or Threads can be used to go beyond this programming model, in order to provide adaptability and dynamic control on the granularity of the parallel tasks. Two approaches will be presented and discussed: first, the use of the dynamic spawning of MPI processes, and then the online control of the mapping of MPI tasks to processes or threads. Experimental results obtained on benchmarks will also be provided. These subjects have been studied in Master and Phd thesis of the Federal University of Rio Grande do Sul (UFRGS), Brazil. About the author: Nicolas Maillard has graduated in 1996 in Applied Mathematics and Computer Science, at the French "Grande École d'ingénieur" ENSIMAG (École Nationale Supérieure d'informatique et de Mathématiques Appliquées de Grenoble) - INPG. He has obtained a Master degree in Applied Mathematics and Parallel Computing, at the University Joseph Fourier (Grenoble I), and a PhD in Information Sciences and Technologies at the same university, in He is currently Assistant Professor at the Federal University of Rio Grande do Sul, Porto Alegre, Brazil. I am teaching Compilers and Parallel Programming. His research is in the area of Parallel, High Performance Computing. He is advising two PhD students and has advised some 10 Master students. He has published 11 papers in international conference with editorial review and 3 in international journals. He has been referee for the journal Parco since 2007, for IEEE Trans. on Parallel and Distributed Systems, and for various conferences of HPC (Europar, CCGRID, HiPC, etc.). Finance chairman and member of the Organizing Committee of SBAC-PAD Nicolas Maillard ---

92 The SimGrid Framework for Research on Large-Scale Distributed Systems Martin Quinson (Nancy University, France) Arnaud Legrand (CNRS, Grenoble University, France) Henri Casanova (Hawaii University at Manoa, USA) Presented By: Pedro Velho (Grenoble University, France) This workshop will provide attendees with clear perspectives on the challenges for experimental research in the area of parallel and large-scale distributed computing, and on current technology for conducting experiments with realworld testbeds, emulated testbeds, or simulated testbeds. The first part of the workshop will present and contrast current experimental methodologies, giving attendees indepth understanding of the scientific and technological issues at hand. The second part of the workshop will focus on simulation, giving a state of the art of current simulation technology and discussing challenges for the development of solid simulation models. The workshop will use the SimGrid [1], [2] simulation framework as an exemplar since it implements sophisticated and validated simulation models [3], [4]. The third part of the workshop will focus on an in-depth presentation of the different simulation approaches enabled by SimGrid, each with its specific range of applications and goals. The last part will give attendees a practical experience with the SimGrid framework. Using a simple scheduling algorithm we intend to give some insight of how useful SimGrid can be in the development life-cycle of distributed applications. SimGrid has been used to obtain results published in over 50 research articles (to cite a few [5], [6]) and has thus emerged as one of the key tools for simulation in the area of parallel and large-scale distributed computing. Workshop attendees will have the opportunity to gain some hands-on experience with SimGrid, by witnessing step-bystep development of small simulation projects. By the end of this workshop attendees should have a clear understanding of current technology and best practice for experimental parallel large-scale distributed computing research, and in particular on the use of simulation. REFERENCES [1] H. Casanova, A. Legrand, and L. Marchal, Scheduling Distributed Applications: the SimGrid Simulation Framework, in Proceedings of the third IEEE International Symposium on Cluster Computing and the Grid (CCGrid 03). IEEE Computer Society Press, May [2] H. Casanova, A. Legrand, and M. Quinson, SimGrid: a Generic Framework for Large-Scale Distributed Experiments, in 10th IEEE International Conference on Computer Modeling and Simulation, April [3] K. Fujiwara and H. Casanova, Speed and accuracy of network simulation in the simgrid framework, in 2nd International Conference on Performance Evaluation Methodologies and Tools (VALUETOOLS), October [4] P. Velho and A. Legrand, Accuracy study and improvement of network simulation in the simgrid framework, in 2nd International Conference on Simulation Tools and Techniques (SIMUTools 09), March [5] M. Gallet, L. Marchal, and F. Vivien, Efficient scheduling of task graph collections on heterogeneous resources, in International Parallel and Distributed Processing Symposium (IPDPS 2009), March [6] S. Hunold, T. Rauber, and F. Suter, Scheduling dynamic workflows onto clusters of clusters using postponing, in 3rd International Workshop on Workflow Systems in e-science (WSES 08), June 2008.

93 Grid5000: An Experimental Grid platform for Computer Science Yiannis Georgiou and Olivier Richard MESCAL, Laboratoire Informatique et Distribution (ID)-IMAG ZIRST 51, avenue Jean Kuntzmann Montbonnot Saint Martin - FRANCE, {Yiannis.Georgiou Abstract Research upon Computer Science, especially in large scale distributed systems like Grids, P2P systems and High Performance Computing (HPC) areas, has to deal with issues related to increasingly complex systems. Theoretical analysis, simulation and even emulation seem not adequate enough for a complete study of these systems. Hence the need for new generation of scientific instruments capable for the observation of complex distributed systems running at real scale and under reproducible experimental conditions has arisen. Grid5000 has been designed to answer to this need. It provides a real-life experimental research tool for computer scientists. In this paper we discuss the importance of an experimental grid platform dedicated to Computer Science research. We present the design choices of Grid5000 architecture and we analyze the key components of the platform which is OAR Resource and Job Management System, Kadeploy reconfiguration toolkit along with all the monitoring and experiments steering tools. 1 Introduction and Motivations Research in Grids, P2P systems and High Performance Computing is based on a variety of methodologies and tools. When Grid5000 [1, 2] was designed, most of the research conducted in Grids and P2P systems was performed using simulators, emulators or production platforms. However, all these tools present limitations making the study of new algorithms and optimizations difficult. Simulators focus on a specific behavior or mechanism of the distributed system and abstract the rest of the system. Hence not all factors and conditions that influence the distributed system can be fully experimented. On the other side, emulators provide a tool capable for executing the actual software of the distributed system, in its whole complexity. Nevertheless, they fail to capture all the dynamic, variety and complexity of real life conditions. Production platforms could provide a good solution for real-life experimentation. However, the fact that specific experiments need specialized software which is often hard to install on production platforms along with the big difficulty of experiment reproduction are some important limitations. Hence, the complexity of Grid and P2P systems raise the need for real-scale experimental platforms where computer scientists can run experiments, observe the distributed systems behavior at large scale under real-life conditions and make precise measurements. As a matter of fact, the experiments upon complex distributed systems span over all the layers of the software stack between the user and the hardware (figure 1). The applications, programming environment, runtime systems, middleware, operating systems and networking layers are subject to extensive studies seeking to improve their performance, security, fairness, robustness and quality of service. Thus, a mechanism that would facilitate the experimentation upon all different layers of the software stack became indispensable. Grid5000 was designed to answer to the above needs. It is a large-scale distributed platform that can be easily controlled, reconfigured and monitored. Especially designed for computer science, it provides a real-life experimental tool, ideal for research upon complex distributed systems. Many institutes and international programs have developed various tools to foster large-scale distributed systems research. Platforms like PlanetLab [3], Emulab [4], GENI [5] and DAS [6] provide some significant examples. The main difference of Grid5000 with all these platforms is the degree of reconfigurability. This functionality, allows researchers to deploy and install the exact software environment they need for their experiments, making the platform an ideal tool for real-

94 Grid 5000 Backbone Network Internet Services Frontend External Access POP Renater 1Gb Link 2Gb Link 10Gb Link Routeur Cluster Server NFS, LDAP, DHCP... Cluster 1 Cluster 2 Cluster3 OAR, Kadeploy Grid5000 Local Site Figure 1. Grid5000 national grid. life experimentation upon all layers of software stack. In the remainder of this paper on section 2 we present the Design Concepts and Architectural choices of Grid5000. The various key components of Grid5000 are presented respectively on section 3,4 and 5. Section 3 analyzes OAR, the Resource and Job Management System, section 4 describes Kadeploy reconfiguration mechanism and section 5 presents the various monitoring and experiment steering tools Finally, section 6 gives some conclusions. 2 Grid5000 Design and Architecture During the preparation of the project in 2003, designers of Grid5000 conducted an analysis on the need of a computer science Grid and the diversity of potential experiments. As described thoroughly on [7], the analysis concluded the need for a large scale (several thousands of CPUs), distributed (10 sites) computer science Grid. Moreover, the experimentation should cover all layers of the software stack, from the application layer to the networking protocols. As the matter of fact, researchers may need a specific experiment setting, different from the other researchers. Researchers involved in networking protocols, Operating Systems and Grid middleware often require a specific OS or kernel for their experiments. Their needs may be quite diverse in Grid Middleware: some require Globus, while others need Unicore, Desktop Grid or P2P middleware. As a consequence, Grid5000 should provide a deep reconfiguration mechanism allowing researchers to deploy, install, boot and run their specific software environments, possibly including all the layers of the software stack. This reconfiguration capability led to the experiment workflow followed by Grid5000 users: 1)reserve specific resources of Grid5000, 2)deploy a soft- Figure 2. Overview of Grid5000 architecture ware environment on the reserved nodes, 3)run the experiment and make precise measurements, and finally 4)collect results and relieve the machines. Since researchers are able to boot and run their specific software on Grid5000 sites and machines, the need of security mechanisms arose. Hence we decided to isolate Grid5000 from the rest of the Internet but to let packets fly inside Grid5000 without limitation. The first choice guarantees that Grid5000 will resist to Internet hacker attacks and the second one makes sure that communication performance will not suffer from the overhead of an imposed security system. Thus, Grid5000 is built as a large scale confined cluster of clusters. Strong authentication and authorization checks are done when users log in Grid5000. Grid5000 is composed of 1/3 heterogeneous and 2/3 homogeneous resources, in order to facilitate all kind of experiments. As analyzed on [8] by Feitelson, the capability to reproduce experimental conditions is fundamental in computer science, especially when performance comparisons are conducted. To fulfill this strong requirement, we decided to use dedicated network links between sites, allow users to allocate dedicated nodes for their experiments and let them install and run their proper experimental condition injectors and measurements software. Thus every user has full control of the allocated Grid5000 partition. Grid5000 initial goal was to provide 5000 CPUcores distributed over 9 sites in France. Figure 1 shows a map of the initial Grid5000 nation wide grid, while figure 2 presents an overview of the platform s architecture. Every site hosts a cluster and all sites are connected between each other by high speed network links (RENATER 4: 10 Gbps links). Every user has a single account on Grid5000. Every Grid5000 site manages its own user accounts and runs 2

95 Users SQL database Perl Scheduler Submission Matching of resource Launching and control of execution Client Log, Accounting Monitoring Server Computing nodes Figure 3. OAR architecture an LDAP server. On a given site, the local administrator can manage its user accounts. Once the account is created, the user can access any of the Grid5000 sites or services (monitoring tools, wiki, deployment, etc.). User data are kept local to every site and distribution to remote sites is done by the user through classical file transfer tools (rsync, scp, sftp, etc.). Data transfers from and to the outside of Grid5000 are restricted to secure tools and done through gateway servers. At cluster level, users submit their resource reservations and experiment jobs using the OAR resource and job management system. To reconfigure the software stack on every reserved node, the users run the Kadeploy toolkit deploying the user defined software environment on a disk partition of selected nodes. Finally to monitor and control the experiments various software tools have been developed by Grid5000 scientists to facilitate different tasks of the experimentation process. In the following sections we present a detailed analysis of these key components used on Grid Cluster resource management and job scheduling: OAR OAR [9, 10] is an open source Resource Management System for large clusters. Initially developed as a tool for research upon the area of Resource Management and Batch Scheduling, this software has evolved towards a certain versatility. It provides a robust solution, used as a production system in various platforms like the regional grid infrastructure Ciment 1 ) used for scientific computations in disciplines like environment, chemistry, astrophysics, etc. OAR is the Resource and Job Management System selected to function on all Grid5000 sites. It is responsible for resources allocation and reservation along with the jobs execution. OAR has been designed considering a modular approach with open architectural choices (figure 3). It is based upon high level components: an SQL Database and the Perl/Ruby Script Programming Languages. It 1 https : //ciment.ujf Figure 4. OAR example of usage can be easily extensible to integrate new features and adapt itself upon different environments. All the most important functionalities, that exist on commercial Resource Management Systems (like PB- SPro or LSF), such as priorities on jobs, advance reservations, resources matching and backfilling are implemented. The priorities are managed through submission queues. All the jobs are submitted to a particular queue which has its own admission rules, scheduling policy and priority. Reservations are a special case in which the user asks for a specific time slot. In this case, as long as the job meet the admission rules and the ressources are available during the requested time slot, the schedule date of the job is definitively set. In OAR, resources required by jobs are matched with available ones. This matching is based on a hierarchical affinity of resources which gives the possibility to allocate from a whole cluster until a specific CPUcore. Moreover a user might need nodes with special properties (like single switch interconnection, or a mandatory quantity of RAM). OAR provides commands to facilitate the allocation of resources. Figure 4 shows an example of OAR jobs submission commands. OAR scheduler also performs backfilling which is the use of idle time slots when large parallel jobs are waiting for execution. Furthermore it can handle Best Effort jobs which are low-priority jobs (usually used for desktop grid experiments) that can be cancelled by normal jobs before the end of their allowed execution time. OAR relies on a specialized parallel launching tool named Taktuk [11, 12] to manage all large-scale operations like parallel tasks launching, nodes probing or monitoring. In order to be able to execute experiments on different clusters of Grid5000, simultaneously, OARGRID [13] software has been developed which is a wrapper that enables the use of several OAR clusters for easier grid experimentation. It provides the possibility 3

96 Applications Batch Scheduler Environment Repository Environment Distro Tools Middleware Specifiable Users Kadeploy2 Database OS(Linux, FreeBSD,...) Submision Hardware Network Configurable Diffusion Mechanism Network booting protocols Hardware reboot mechanism Figure 5. Software environment of resources allocation and reservation on a grid level. The individual job execution is effectuated by the local OAR system. 4 Reconfiguration mechanism: Kadeploy In the context of high performance computing research, scientists seem to need various software environments in order to perform their experiments. A software environment contains all the software layers like the operating system, the libraries, the middlewares and the applications (figure 5 ). According to their experiments nature and the software layer they are investigating (protocols, OS,..), they often require specific OS. Hence, a tool with a deep reconfiguration mechanism allowing researchers to deploy, install, boot and run their specific software images, is needed. Kadeploy [14, 15] is a software environment deployment tool designed to solve the above issues providing automated software installation and reconfiguration mechanisms on all the layers of the software stack. Using kadeploy, in a typical experiment sequence, a researcher reserves a partition of the cluster or grid, deploys its software image (figure 7), reboots all the machines of the partition, runs the experiment, collects results and finally relieves the machines. This reconfiguration capability allows researchers to run their experiments in the software environment that perfectly matches their needs and provides to users, a software homogeneous grid. This tool uses the traditional protocols for network booting: PXE, TFTP, DHCP. As we can see on figure 6, architecture of Kadeploy is designed around a database and a set of specialized operating components. The database is used to store all necessary information for the deployment process, the computing nodes and the environments. At the same time, the code is written in Perl, which is perfectly suited for system tasks. In addition uses a fast mechanism of environment diffusion which depends slightly on the number of nodes. This mechanism is based on a pipeline Client Server Figure 6. Kadeploy architecture Computing Nodes approach (chain of TCP connections between nodes). This enables operations of deployment on large clusters (1000 nodes). The deployment process will write a complete environment, on a partition of the disk of each computing node, which will be followed by a reboot on this partition. The process ensures that the partition of the disk where the reference environment of the node is installed, remains intact during diffusion. To guarantee a greater function reliability, Kadeploy tool directs clusters to be coupled with remote mechanisms of hardware reboot. Thus, if a particular problem occurs on one or more nodes during a deployment, a restarting on the reference partition is ordered automatically, on defected nodes. An environment is created very simply by making an archive of the root partition in compressed tar format. To ensure a high level of portability and to permit that an environment is usable on various clusters of similar processor architectures, the environment should not contain information corresponding to the initial cluster. That is possible because the majority of the services have autoconfiguration mechanism (ex: protocol DHCP for the network) and the majority of the operating systems have hardware autodetection mechanisms making it possible to adapt to the minor differences (network cards, disks...). For the services that lack autoconfiguration procedure during the deployment, a procedure known as post-installation process supplements the parameter setting. Grid5000 uses kadeploy environment deployment tool for effective reconfiguration capabilities. Environment creation 1)Submission of requested nodes at the batch scheduler )Environment deployment 3)Work on the environment New experiment 4)Work finishes, nodes return to the initial reference environment Figure 7. Typical sequence of an environment deployment. 4

97 Figure 8. Monika 5 Monitoring and experiment steering tools In order to control and monitor the experiments various software tools have been developed and used upon Grid5000 platform. Concerning the initiation and experiment steering tools the following tools are some of the most important software used in the platform: Katapult [16] provides a wrapper to kadeploy for automatic redeployment of nodes in case of failures. Grudu [17] software provides a tool for managing Grid5000 resources, reservations and deployments through a user-friendly web interface. Taktuk [11, 12] software is a tool for deploying parallel remote executions of commands to a large set of remote nodes. KAAPI [18] provides a C++ library that allows to execute multithreaded computation with data flow synchronization between threads. The experiments and resources usage monitoring is a valuable component of an experimental grid platform. Numerous tools are used to provide detailed information along and after the experimental process. Monika (figure 8) and Gantt (which are parts of OAR software) provide analytical information about the state of jobs and resources of independent clusters or even the whole grid. Green-net framework [19] is composed by power aware software tools for high performance data transport and computing in large scale distributed systems and it provides ways (web or command line interfaces) to control and measure the energy consumption during the experiments. The electric consumption of some monitored nodes is available live on line, with some graphs, as shown in figure 9. Finally, Ganglia is used for a finer grain monitoring and kaspied tool provides a set of statistical values about the platform usage. Figure 9. Electrical consumption Monitoring 6 Conclusion In this article we presented Grid5000 experimental grid platform dedicated for research in computer science. Building a platform like Grid5000 is a full-fledged research topic. The construction of such large scale instruments is new in computer science and the community just starts to get used to deal with all the administrative, technical and scientific details related to the design, construction, exploitation and maintenance of such platforms. Other branches of science like Physics, Astrophysics and Biology have a long history of instrument construction behind them. This is a precious source of inspiration for computer scientists. Apart being instrument to study distributed computing research problems, Grid5000 offers resources opened and shared by a large community of users. Computer scientists find not only a sophisticated environment involving supporting engineers, specific software and dedicated hardware to ease their experiments but also a social context in which they can share their problems, questions and solutions. Furthermore a lot of international collaborations have been initiated since the beginning of the project, which imply a further opening of the platform in an international scale. As a matter of fact, since July 2009 Grid5000 acquired a new site, in the pool of each resources, situated in the university UFRGS of Porto Alegre in Brazil. This collaboration, gave a new dimension of Grid5000 platform which is now leaning towards an international computer science grid. 5



Más detalles



Más detalles

Herramientas Integradoras para Modelado, Simulación y Control de Redes de Datos

Herramientas Integradoras para Modelado, Simulación y Control de Redes de Datos Universidad Nacional de Rosario Facultad de Ciencias Exactas, Ingeniería y Agrimensura Departamento de Control CIFASIS-CONICET Tesis Doctoral Herramientas Integradoras para Modelado, Simulación y Control

Más detalles

Trabajo Fin de Máster

Trabajo Fin de Máster Trabajo Fin de Máster Integración dinámica de entornos de computación heterogéneos para la ejecución de workflows científicos Autor Sergio Hernández de Mesa Director Pedro Álvarez Pérez-Aradros Escuela

Más detalles


QUALITY METRICS FOR BUSINESS PROCESSES KEYNOTE QUALITY METRICS FOR BUSINESS PROCESSES Jorge Cardoso Departamento de Matemática e Engenharias University of Madeira 9100-390, Portugal Abstract In a competitive e-commerce and e-business

Más detalles


UNIVERSIDAD DE MURCIA UNIVERSIDAD DE MURCIA FACULTAD DE INFORMÁTICA Enhancing User-Centric Identity Management Systems with Reputation Models in Distributed Environments Mejora de Sistemas de Gestión de Identidades Centrados

Más detalles

TRABAJO FIN DE GRADO. Título: Diseño y desarrollo de un sistema de detección de NATS para un monitor de tráfico residencial

TRABAJO FIN DE GRADO. Título: Diseño y desarrollo de un sistema de detección de NATS para un monitor de tráfico residencial TRABAJO FIN DE GRADO Título: Diseño y desarrollo de un sistema de detección de NATS para un monitor de tráfico residencial Autor: Álvaro Fernández Rojas Titulación: Grado en Ingeniería Informática Tutor:

Más detalles

RISCE Revista Internacional de Sistemas Computacionales y Electrónicos. A ñ. NOVIEMBRE 2010 Número 6, Volumen 2, Año 2. A l e j a n d r o [

RISCE Revista Internacional de Sistemas Computacionales y Electrónicos. A ñ. NOVIEMBRE 2010 Número 6, Volumen 2, Año 2. A l e j a n d r o [ [ RISCE Revista Internacional de Sistemas Computacionales y Electrónicos A ñ NOVIEMBRE 2010 Número 6, Volumen 2, Año 2 A l e j a n d r o [ RISCE Revista Internacional de Sistemas Computacionales y Electrónicos;

Más detalles

Integración de Kerberos con servicios Cloud (OpenStack)

Integración de Kerberos con servicios Cloud (OpenStack) Universidad de Murcia Facultad de Informática Integración de Kerberos con servicios Cloud (OpenStack) Trabajo Fin de Grado Autor: Víctor Manuel Ruiz Sánchez Tutores: Gabriel López

Más detalles

La metodología del Data Mining. Una aplicación al consumo de alcohol en adolescentes

La metodología del Data Mining. Una aplicación al consumo de alcohol en adolescentes La metodología del Data Mining. Una aplicación al consumo de alcohol en adolescentes The methodology of Data Mining. An application to alcohol consumption in teenagers Elena Gervilla García*, Rafael Jiménez

Más detalles

Tópicos Selectos de Ingeniería. Pedro Solares. Gobierno de tecnología de Información ECORFAN

Tópicos Selectos de Ingeniería. Pedro Solares. Gobierno de tecnología de Información ECORFAN Tópicos Selectos de Ingeniería Pedro Solares Elena Romero Directores Gobierno de tecnología de Información ECORFAN Tópicos Selectos de Ingeniería Volumen I Para futuros volúmenes:

Más detalles

la sociedad de la información RESUMEN EJECUTIVO / EXECUTIVE SUMMARY

la sociedad de la información RESUMEN EJECUTIVO / EXECUTIVE SUMMARY RESUMEN_SIE_OK.qxd 06/02/2006 19:15 PÆgina 3 la sociedad de la información en España RESUMEN EJECUTIVO / EXECUTIVE SUMMARY El informe "La Sociedad de la Información en España 2005" ha sido elaborado por

Más detalles

Intersemestral de Arquitectura de Computadoras II. AGPS. 2005-2006

Intersemestral de Arquitectura de Computadoras II. AGPS. 2005-2006 TEMARIO 1. FUNDAMENTOS TEÓRICOS DEL CÓMPUTO PARALELO. 1.1. Antecedentes. 1.1.1. Historia del cómputo paralelo 1.1.2. Ventajas 1.1.3. Taxonomía 1.2. Paradigmas del cómputo paralelo 1.2.1. Paradigmas del

Más detalles


UNIVERSIDAD DE EXTREMADURA UNIVERSIDAD DE EXTREMADURA Escuela Politécnica Máster en Ingeniería Informática Trabajo Final de Máster Desarrollo de un Sistema de Información para realizar búsquedas por contenido en imágenes de satélite,

Más detalles

UNIVERSIDAD COMPLUTENSE DE MADRID FACULTAD DE INFORMATICA Departamento de Arquitectura de Computadoras y Automática


Más detalles

Desarrollo de videojuegos 2012


Más detalles



Más detalles



Más detalles



Más detalles

La infraestructura digital de la provincia de San Luis

La infraestructura digital de la provincia de San Luis » La infraestructura digital de la provincia de San Luis Autopista de la Información, Data Center y Wi-fi Gratuito Digital Infrastructure in the Province of San Luis Information Highway, Data Center and

Más detalles

Ingeniería de Telecomunicación

Ingeniería de Telecomunicación Universidad Autónoma de Madrid Escuela politécnica superior Proyecto fin de carrera A NON-INTRUSIVE APPLIANCE LOAD MONITORING SYSTEM FOR IDENTIFYING KITCHEN ACTIVITIES Ingeniería de Telecomunicación María

Más detalles

A Constraint-based Job-Shop Scheduling Model for Software Development Planning

A Constraint-based Job-Shop Scheduling Model for Software Development Planning A Constraint-based Job-Shop Scheduling Model for Software Development Planning Irene Barba, Carmelo Del Valle, and Diana Borrego Dpto. Lenguajes y Sistemas Informáticos, Universidad de Sevilla, Spain {irenebr,carmelo,dianabn}

Más detalles

Multicore and GPU Programming

Multicore and GPU Programming Multicore and GPU Programming EDITORS Miguel A. Vega-Rodríguez Manuel I. Capel-Tuñón Antonio J. Tomeu-Hardasmal Alberto G. Salguero-Hidalgo 2015 Title: Multicore and GPU Programming Editors: Miguel A.

Más detalles

Template courtesy of (

Template courtesy of ( Editor: Beatriz Barros Executive Editor: Inés Méndez Assistant Edition: Ana Rodríguez Place of edition: Málaga Publishing Entity: Departamento de Lenguajes y Ciencias de la Computación de la Universidad

Más detalles

Programación en Entornos Cliente/Servidor Ingeniería Informática Curso 2011/2012 Encuesta de Fin de Curso

Programación en Entornos Cliente/Servidor Ingeniería Informática Curso 2011/2012 Encuesta de Fin de Curso Programación en Entornos Cliente/Servidor Ingeniería Informática Curso 2011/2012 Encuesta de Fin de Curso La asignatura me ha gustado Creo que la asignatura puede servirme en mi profesión. El temario es

Más detalles


ECTS GUIDE COMPUTER SCIENCE ENGINEERING DEGREE CURRICULUM ECTS GUIDE COMPUTER SCIENCE ENGINEERING DEGREE CURRICULUM PROGRAMS OF SUBJECTS 2009/2010 In this document there are summarized the programs of the subjects of the Computer Science Engineering Degree of

Más detalles



Más detalles

Prólogo. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 I

Prólogo. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 3, No. 3, 2009 ISSN 1988-3455 SISTEDES, 2009 I Prólogo Los procesos de negocio están tomando un necesario protagonismo en el campo de la ingeniería del software debido a que los sistemas software son, cada vez más, piezas para dar soporte de automatización

Más detalles

Low-power Wireless ECG Monitoring System for Android Devices

Low-power Wireless ECG Monitoring System for Android Devices Low-power Wireless ECG Monitoring System for Android Devices Sistema inalámbrico de bajo consumo para monitorización de electrocardiogramas desde dispositivos Android Pablo Fernández Vicente Rafael Basilio

Más detalles

Modelo de Interoperabilidad para Plataformas de Cloud Computing basado en Tecnologías del Conocimiento

Modelo de Interoperabilidad para Plataformas de Cloud Computing basado en Tecnologías del Conocimiento Universidad Carlos III de Madrid Doctorado en Ciencia y Tecnología Informática Modelo de Interoperabilidad para Plataformas de Cloud Computing basado en Tecnologías del Conocimiento AUTOR: ENRIQUE JIMÉNEZ

Más detalles