Por Abián & AcidBorg Versión 1.0

Transcripción

1 Por Abián & AcidBorg Versión 1.0 Proyecto OpenMosix - 1

2 Proyecto OpenMosix - 2

3 LICENCIA Copyright (c) 2004 Abián & AcidBorg Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. GNU Free Documentation License Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royaltyfree license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. Proyecto OpenMosix - 3

4 A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. Proyecto OpenMosix - 4

5 The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computernetwork location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. Proyecto OpenMosix - 5

6 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. Proyecto OpenMosix - 6

7 If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements". Proyecto OpenMosix - 7

8 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. Proyecto OpenMosix - 8

9 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. Proyecto OpenMosix - 9

10 1. INTRODUCCIÓN 1.1 Qué es un cluster? 1.2 Qué es un nodo? 1.3 Qué características tiene un cluster? 1.4 Clusters homogéneos o clusters heterogéneos? 1.5 Qué software necesita un cluster? 1.6 Clusters vs Superordenadores? 1.7 Qué es la escalabilidad? 1.8 Qué tipos de clusters existen? 1.9 Qué es el procesamiento paralelo? 1.10 Qué problemas se pueden resolver mediante paralelización? 1.11 Qué es un sistema distribuido? 1.12 Qué es un sistema operativo distribuido? 1.13 Por qué elegimos GNU/Linux para nuestro clúster? 1.14 Qué es OpenMosix? 1.15 Por qué hemos elegido OpenMosix? 1.16 Cuales son las desventajas de OpenMosix? 1.17 Se puede solucionar el problema de memoria compartida? 1.18 Cuál es el objetivo de este proyecto? 2 CONFIGURACIÓN 2.1 Hardware Nodos Router Topología de red y cableado 2.2Versiones del software Distribución de linux Openmosix Versión del kernel Userspace Tools Openmosixview Librerías MPI 2.3 Opciones de compilación del kernel 2.4 Configuración de la red local Seguridad en el cluster Configuración del router Uso de la red por parte de openmosix 2.5 Openmosix.map 2.6 Openmosix.config 2.7 Scripts 2.8 Sistemas de ficheros 2.9 Detección automática de nodos 2.10El algoritmo de migracion 2.11Consideraciones finales 3. HERRAMIENTAS DE ADMINISTRACIÓN Proyecto OpenMosix - 10

11 3.1Openmosix Tools Mostcl Mosrun Migrate Mosmon Moslimit Mps Setpe 3.2 Openmosixview 3.3 Consideraciones finales 4. TESTS Y BENCHMARKS 4.3 Codificación de ficheros de audio.wav a.mp3 4.4 Cisilia 4.5 Openmosix Stress Test 4.6 NAS Parallel Benchmarks Compilación del kernel 4.8 Pallas MPI Benchmarks (PMB-MPI1) 5. CONCLUSIONES Y OPINIÓN PERSONAL 6. REFERENCIAS 6.1 Webs 6.2 Libros 6.3 Revistas 6.4 Otros 7. AGRADECIMIENTOS Proyecto OpenMosix - 11

12 1. INTRODUCCIÓN Qué es un cluster? Es difícil encontrar una definición formal de cluster y más aún definirlo por nosotros mismos, por lo que añadimos una definición de un especialista en la materia: "Un cluster es una clase de arquitectura de computador paralelo que se basa en unir máquinas independientes integradas por medio de redes de interconexión, para proveer un sistema coordinado, capaz de procesar una carga" ( Dr. Thomas Sterling). Qué es un nodo? Un nodo es cada uno de los ordenadores que forma parte de un cluster. Se excluye de esta definición a los hubs,switchs,routers y cualquier otro dispositivo de interconexión que no participe en la ejecución de los procesos ni puedan migrarse procesos hacia él. Qué características tiene un cluster? 1. Debe estar compuesto de 2 o más nodos. 2. Sus nodos deben estar conectados entre sí formando una red Esto excluye a los SMP, los Mainframes y a un sólo nodo, ya que no disponen de red y no se ajustan a la definición de cluster.una máquina SMP (Symetric MultiProcessing) sigue una modelo de paralelismo al utilizar más de un microprocesador simultáneamente. La memoria y el disco son igualmente accesibles desde cualquiera de los procesadores). Un Mainframe es supercomputador con varios procesadores trabajando en paralelo, cuya memoria puede ser compartida por todos los procesadores o poseer cada cual la suya propia. La interconexión se realiza mediante un bus de datos cuya velocidad supera con creces la de cualquier red. Clusters homogéneos o clusters heterogéneos? No existe nada que obligue a un cluster a ser homogéneo, es decir, que todos sus nodos sean iguales. Es más, encontramos en los clusters SSI la respuesta a esta pregunta. SSI (System Single Image) es la propiedad de un sistema de ocultar la naturaleza heterogénea y distribuida de los recursos disponibles y presentarlos a los usuarios y a las aplicaciones como un sólo recurso unificado de cómputo. Con la SSI los usuarios tienen una imagen globalizada de los recursos que hay disponibles, sin importar el nodo al cual están físicamente asociados. También asegura que el sistema se mantenga balanceado proporcionando un multiprocesamiento común. Proyecto OpenMosix - 12

13 Los objetivos en el diseño de una SSI para sistemas clusters se enfocan principalmente en la total transparencia en el manejo de recursos, el rendimiento escalable y la disponibilidad del sistema para soportar las aplicaciones del usuario. Una SSI puede definirse como la ilusión, creada por hardware o por software, que presenta una colección de recursos como un sólo, y más poderoso, recurso unificado. En definitiva, no importa que los nodos sean diferentes, ya que la abstracción a la que se ven sometidos los habilita para formar parte de un mismo cluster. Eso sí, es mucho más fácil y cómodo de administrar un cluster homogéneo que uno heterogéneo ya que nos podemos beneficiar de la clonación de sistemas y de un proceso de monitorización más claro. Qué software necesita un cluster? A nivel de sistema se necesita un parche o modificación del kernel del sistema operativo que permita la utilización de los ordenadores como nodos del cluster, gestionando la migración de procesos, evaluando la carga del sistema y tomando decisiones para lograr su balanceo. A nivel de aplicación se utiliza software generado apoyándose en bibliotecas especializadas para clusters y procesamiento paralelo, que persiguen la abstracción de los nodos a un sistema conjunto, permitiendo crear entornos distribuidos transparentes. Los programas generados suelen crear subprocesos o subrutinas que son las que se migran a los demás nodos del cluster logrando el balanceo de carga. Clusters vs Superordenadores? Las principales ventajas entre un cluster y un superordenador como puede ser un mainframe son: precio, reutilización, escalabilidad. En primer lugar, el precio de un cluster con una capacidad de cálculo similar a la de un mainframe es un 10% menor, lo que permite el ahorro de ese capital o su inversión en la adquisición de nodos más potentes. La posibilidad de reutilizar máquinas antiguas para la construcción del cluster y su gran escalabilidad son circunstancias que favorecen la decisión del sector empresarial en la adquisición de un cluster, ya que cuando un mainframe se queda "pequeño" respecto a su capacidad de cálculo no cabe otra solución que comprar otro mainframe nuevo. Qué es la escalabilidad? La escalabilidad es una característica de un sistema que consiste en ser capaz de acomodar sus recursos y rendimiento a las necesidades que se le exijan. Aquí hablaremos de escalabilidad hacia arriba, es decir, los sistemas crecen en tamaño, costes, rendimiento y recursos, aunque también se puede dar una escalabilidad hacia abajo, esto es, reducir costes Proyecto OpenMosix - 13

14 mediante la reutilización de componentes. La escalabilidad ideal es de complejidad lineal, es decir, si un sistema aumenta en N su número de elementos se espera de él un rendimiento N veces el inicial y un coste N veces el coste inicial. Esto se aproxima a la realidad en los sistemas distribuidos ya que el precio de obtener el doble de procesamiento en uno de estos sistemas es ligeramente superior al comprar una máquina el doble. En OpenMosix la escalabilidad permite un cluster con un número máximo de nodos trabajando a la vez. Qué tipos de clústers existen? Existen 3 tipos de clusters de acuerdo a su utilidad: de alta disponibilidad, de balanceo de carga y de alto rendimiento. Un cluster de alta disponibilidad (High Availability) consisten en varias máquinas que comparten los discos duros y se monitorizan entre sí constantemente. Su utilidad deriva de la necesidad de tener un sistema capaz de reponerse de un fallo de hardware y de la necesidad de abaratar los costes de los sistemas redundantes y tolerantes a fallos. Cuando uno de los equipos cae, los demás migran sus procesos hacia ellos mismos para que no haya pérdidas de datos y de disponibilidad del conjunto. A su vez, se encargan de rearrancar al ordenador caído y, tras lograrlo, le devuelven su carga correspondiente para volver a la normalidad. La aplicación más común para este tipo de diseño son servidores de páginas web o de bases de datos tolerantes a fallos y que necesiten estar operativos las 24 horas del día todos los días del año. Los clusters de alto rendimiento son los que hemos escogido para nuestro proyecto. Éstos se basan en un conjunto de máquinas diseñadas para lograr una capacidad de cálculo máxima al repartirse la carga de los procesos entre los nodos de acuerdo a las reglas escogidas. Con ésto se consigue mejorar el rendimiento en la obtención de la solución de un problema. Normalmente se utilizan en la resolución de algoritmos científicos, en las granjas de compilación (conjunto de ordenadores destinados a compilar una misma cosa entre todos), granjas de renderizado (grupo de máquinas que se dedican a la visualización, modificación y reproducción de imágenes en 3D) y en la compresión o cifrado de códigos. Por último están los clusters de alta confiabilidad, que son una mezcla de los de alta disponibilidad y los de alto rendimiento. Tienen como objetivo evitar que las aplicaciones se caigan. No existe otra manera de conservar el estado de las aplicaciones que mediante la inclusión de puntos de parada (checkpoints), pero en conexiones de tiempo real no son suficientes, ya que Proyecto OpenMosix - 14

15 no se trata únicamente de utilizar el último checkpoint del sistema y relanzar el servicio. Estos clusters necesitan tener un único reloj de sistema conjunto. No pueden ser implementados de manera eficiente, en tiempo real, únicamente mediante software, debido a problemas de latencia de red. Este tipo de clusters no son fácilmente implementables en la actualidad. Todos los clusters mencionados anteriormente hacen uso de un sistema de balanceo de carga que reparte los procesos entre todos los nodos del cluster de forma que no haya ningún nodo saturado. Si hablamos de la transparencia de los clusters,nos topamos con 2 tipos: Por una parte, los clusters no transparentes requieren una programación paralela explícita y el conocimiento de la topología de la red del cluster por adelantado(beowulf) y/o la utilización de librerías para el paso de mensajes entre tareas,que pueden estar ( PVM MPI) Dentro de los clusters no transparentes destaca el proyecto Beowulf. Se trata de una arquitectura multicomputador utilizada para procesamiento paralelo que opera sobre un cluster, cuya jerarquía se basa en un nodo servidor y uno o más nodos cliente en red. Este sistema se apoya en un sistema distribuido y utiliza mecanismos de paso de mensajes. También cabe destacar aquí las librerías para el paso de mensajes en programación paralela como son las MPI. Por otra parte, en los clusters transparentes el programador no necesita saber la topología de la red, ni necesita utilizar técnicas de programación paralela explícita, ya que ni siquiera necesita saber que su programa va a funcionar en un cluster. Simplemente con adoptar la metodología de programación en multiprocesador es suficiente. Un ejemplo de clusters transparentes son Mosix y OpenMosix. Mosix es un cluster SSI a nivel de sistema transparente. Se utiliza principalmente para el aumento de procesamiento del sistema y permite la utilización de antiguos programas hechos para monoprocesadores en un cluster. El principal inconveniente de Mosix es que hace 2 años que el desarrollo del mismo ha disminuido considerablemente. Además, desde hace 2 años se ha convertido en un proyecto de código cerrado por lo que no se pueden hacer modificaciones del mismo. Proyecto OpenMosix - 15

16 Qué es el procesamiento paralelo? Por procesamiento paralelo se entiende la capacidad de utilizar varios procesadores para ejecutar diferentes partes del mismo programa simultáneamente. El objetivo principal del paralelismo es reducir el número de ciclos de ejecución de un programa en relación al número de procesadores que existen en el sistema, es decir, "divide y vencerás". En esta idea es en la que se apoyan los clusters de alto rendimiento para lograr su cometido. Qué problemas se pueden resolver mediante paralelización? Los programas convencionales no cuentan con ninguna manera de paralelizar su código. La mayoría de los programas son pensados y implementados de manera secuencial. Aun así, existen muchos campos donde el desarrollo de programas que hagan uso de una manera u otra de paralelismo está creciendo cada vez más. Entre estos campos se encuentran: Granjas de compilación Granjas de renderización Procesos matemáticos Multiplicación de matrices Suma de vectores por componentes Multiplicación de matrices o vectores por escalares o funciones escalares. Integrales definidas (creando intervalos más pequeños como elementos de proceso) Compresión Aplicación a nuevos paradigmas inherentemente paralelos Redes neuronales Algoritmos genéticos Qué es un sistema distribuido? Un sistema distribuido es un conjunto de ordenadores o procesadores independientes (nodos) que de cara al usuario funcionan como uno solo. Está formado por varios componentes que cooperan estrechamente para dar un servicio único. Qué es un sistema operativo distribuido? Un sistema operativo distribuido es el encargado de cumplir lo anterior. Hay un particionado y cooperación entre todos los componentes, ninguno sobrevive solo, el propio kernel está distribuido por las máquinas. El hardware no da ninguna facilidad, es el software el que determina que un sistema sea distribuido o no. El usuario no sabe dónde se están ejecutando los procesos ni dónde están los recursos. Proyecto OpenMosix - 16

17 Llevar a la práctica la idea de un kernel global distribuido es muy difícil, pues podría haber inconsistencias de datos en el kernel, además se necesita al menos el kernel mínimo para enviar y recibir información y un mecanismo robusto de comunicación y eficiente para evitar latencias demasiado elevadas. Lo que se han desarrollado hasta ahora son los llamados sistemas operativos en red. En estos sistemas cada máquina tiene su propio kernel. Los sistemas están conectados por una red y se puede hacer login remoto en ellos, en todo momento el usuario sabe donde se encuentran todos los recursos (ficheros, procesos, etc.). No es un sistema distribuido,pero actualmente se está caminando desde los sistemas operativos en red a los sistemas distribuidos. Aunque aún no se han cumplido los objetivos de un sistema distribuido completamente tenemos ya algunos avances. Existen grandes avances en sistemas de ficheros para conseguir que exista un solo directorio raíz al igual que la existencia de una ubicación automática por parte del sistema de los ficheros. Se puede implementar un balanceo de la capacidad y redundancia en los datos para minimizar el impacto de posibles caídas de nodos. Por qué elegimos GNU/Linux para nuestro cluster? La principal razón es su licencia GPL que permite la libre difusión, copia y modificación del código fuente de los programas liberados bajo este tipo de licencia. También porque se evita cualquier tipo de problema con las patentes ya que la distribución elegida para el proyecto (Debian) sólo incorpora programas compatibles con licencias de software libre. También cabe destacar el enorme esfuerzo que está realizando la comunidad Linux mundial en la difusión de documentación, ya sea a nivel de HOWTO's, F.A.Q (Frecuently Asked Questions), manuales, tutoriales paso a paso para principiantes o textos especializados para auténticos gurús de la materia. La comunidad linux también ha visto en el clustering una de las utilidades a sus máquinas y ha desarrollado numerosos proyectos para enfocar al sistema operativo por los caminos de la supercomputación. Los proyectos más relevantes en el campo del clustering de alto rendimiento son: Mosix, OpenMosix y Beowulf. Qué es OpenMosix? OpenMosix es un parche para el Kernel de Linux que le dota de la capacidad de trabajar como nodo, es decir, como máquina que forma parte del cluster. Su misión es convertir una red de ordenadores en un cluster. El algoritmo interno de balanceo de carga se ocupa de migrar automáticamente y de forma transparente al usuario los procesos entre los demás nodos del cluster, lo que proporciona una compartición óptima de la carga entre los nodos. Esta migración se realiza de acuerdo a la velocidad de CPU de cada nodo, a su carga de procesos actual y a la conexión de red Proyecto OpenMosix - 17

18 que lo una a los demás nodos, ya que aunque todos deben utilizar el protocolo TCP/IP para comunicarse entre ellos, no todos tienen que estar conectados en la misma subred, ni utilizar los mismos medios físicos de unión(ethernet, PPP,etc...). Por supuesto, el administrador del cluster puede realizar la migración de procesos de forma manual gracias a las herramientas que de software que acompañas al cluster (Userland tools o Userspace tools). Asimismo, los nodos pueden añadirse o quitarse de la red sin que los procesos en ejecución se vean afectados. Debido a que OpenMosix forma parte del kernel, ya que se añade al código fuente de éste antes de compilarlo, es totalmente compatible con Linux, sus programas y sus ficheros. No es posible distinguir entre una máquina normal y corriente ejecutando linux y una máquina utilizando linux como nodo de un cluster OpenMosix. El sistema de migración de procesos hace trabajar al conjunto de nodos como un enorme sistema de procesadores (o multiprocesadores en el caso de que se trate de procesadores dual o quad en cada máquina). OpenMosix utiliza un sistema de ficheros llamado omfs (OpenMosix File System) que, al contrario que el sistema de ficheros NFS, proporciona cache, "time stamp" y consistencia de enlace. Por qué hemos elegido OpenMosix? Hemos elegido de entre las posibles opciones OpenMosix debido a que corre en GNU/LINUX, es un proyecto con licencia GPL y es uno de los más desarrollados en la actualidad, además de ser el que cuenta con mayor documentación en internet. Originalmente deriva del proyecto MOSIX. Debido a las diferencias de opiniones entre los desarrolladores del proyecto a la hora de liberar el código bajo una licencia no libre, los que optaron por liberarlo bajo licencia GPL se separaron del proyecto original para continuar un desarrollo paralelo, dando lugar a OpenMosix. Numerosas mejoras fueron añadidas al proyecto, como su acomodación a la estructura de Linux, un código y un algoritmo de migración de procesos más limpio, un método de balanceo de carga más eficiente, menores latencias en el kernel, soporte para más arquitecturas (incluidas algunas de 64 bits) y, sobre todo, muchísima documentación. Proyecto OpenMosix - 18

19 Cuáles son las desventajas de OpenMosix? Entre sus desventajas más notables se encuentran: Es dependiente del kernel y, por tanto, de la versión de éste que se esté utilizando. No migra procesos que utilicen memoria compartida No migra procesos que utilicen múltiples threads No migra procesos únicos, como son la mayoría de los programas que utilizamos diariamente Se puede solucionar el problema de la memoria compartida? Sí,para ello existe Migshm. Migshm es un parche para hacer que funciones la memoria compartida de forma distribuida(dsm - Distributed Shared Memory). Con ello se consigue que puedan migrar los procesos que utilicen memoria compartida. Para conseguirlo se utilizan las llamadas al sistema: shmget(), shmat (), shmdt() y shmctl(). Los threads creados a partir de la llamada al sistema clone() también pueden ser migrados aplicando este parche. Hemos decidido no aplicar este parche porque no existe una versión que corresponda con la versión de OpenMosix que hemos utilizado y porque está en una fase muy experimental (alpha), por lo que el rendimiento total del cluster puede verse perjudicado y los resultados de los benchmarks y pruebas pueden verse alterados. Cuál es el objetivo de este proyecto? Nuestro principal objetivo es comprobar si se puede ahorrar tiempo en la ejecución de programas al reutilizar en casa los ordenadores viejos formando un cluster de alto rendimiento. Para ello hemos tenido en cuenta que el ordenador respecto al que se hacen las comparaciones es el más potente, ya que sería el que se utilizaría en solitario si no existiera el cluster. Proyecto OpenMosix - 19

20 2. CONFIGURACIÓN 2.1 Hardware Nodos En esta sección vamos a describir cada uno de los nodos centrándonos en sus características fundamentales: Velocidad de procesador, memoria, tarjeta de red Cada uno de los nodos ha sido bautizado con un nombre dentro del cluster, los integrantes serían Shadowland, Asimov y salon. Para conseguir información útil en cuando al hardware de cada equipo miramos el archivo /proc/cpuinfo obteniendo las siguiente propiedades: NODO1: Llamado Shadowland. processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name: AMD Athlon(tm) XP stepping : 0 cpu MHz : cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception: yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : Como podemos ver se trata de un AMD Athlon XP a 1679 MHz, el tamaño de la memoria cache es de 256 KB, también averiguamos el número de bogomips de este ordenador que es de Además de estos datos, que son los que consideramos más importantes para describir la capacidad de cómputo de nuestra CPU, vamos a describir otros valores para tener una visión más concreta de los equipos que forman nuestro cluster: Proyecto OpenMosix - 20

21 Dispone de 256Mb de memoria RAM, con tecnología DDR a 333MHz, 80 Gb de disco duro distribuido en dos discos duros de 40 Gb, la tarjeta de red que tiene instalada es una Tarjeta de red PCI Fast Ethernet 10/100MB con chipset Realtek. Los tres ordenadores disponen del mismo modelo de tarjeta, para permitir que este modelo concreto funcione bajo nuestro sistema operativo al recompilar el kernel activamos dentro de la sección Network Device Support ->Ethernet 10/100 -> Realteck RTL-8139 PCI Fast Ethernet Adapter Support. NODO 2: Llamado Asimov. processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name: AMD Athlon(tm) Processor stepping : 2 cpu MHz : cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception: yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : En este caso nos encontramos con un AMD Athlon K7 Thunderbird a 1212 MHz, el tamaño de la memoria cache es de 256 KB, también averiguamos el número de bogomips de este ordenador que es de Dispone de 128Mb de memoria RAM, con tecnología SDR a 133MHz, 25 Gb de disco duro distribuido en dos discos duros: uno de ellos de 20 Gb y otro de 5 Gb, la tarjeta de red que tiene instalada es una Tarjeta red PCI Fast Ethernet 10/100MB con chipset Realtek. NODO 3: Llamado salon. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name: Pentium III (Katmai) stepping : 3 Proyecto OpenMosix - 21

22 cpu MHz : cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception: yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : En este caso nos encontramos con un procesador que utiliza la tecnología Intel Pentium a 500 MHz, el tamaño de la memoria cache es de 512 KB. También averiguamos el número de bogomips de este ordenador que es de Dispone de 320Mb de memoria RAM, con tecnología SDR a 133MHz, 10 Gb de disco, la tarjeta de red que tiene instalada es una Tarjeta red PCI Fast Ethernet 10/100MB con chipset Realtek. En la información anterior hay un campo que nos llama la atención, se trata de los bogomips. Lo más usual sería medir la potencia de un computador mediante los MIPS. Este es el momento de explicar ambos conceptos. MIPS: es la abreviatura de Millions of Instructions Per Second o Millones de Instrucciones Por Segundo''. Es una medida de la velocidad de ejecución de un programa. Como la mayoría de tales medidas, frecuentemente se abusa de ella en vez de usarse correctamente (es difícil comparar con justicia MIPS para diferentes tipos de ordenadores). BogoMIPS: son una invención de Linus Torvalds. El núcleo necesita un bucle de temporización (el tiempo es demasiado corto y/o necesita ser demasiado exacto para poder emplear un método de espera no basado en bucles de retardo), que tiene que ser calibrado con la velocidad de procesador de la máquina. Por lo tanto, el núcleo mide durante la secuencia de arranque cómo de rápido se ejecuta en el ordenador un determinado tipo de bucle de retardo denominado BOGO. Por consiguiente, el valor de los BogoMIPS da una cierta indicación acerca de la velocidad del procesador, pero de forma escasamente científica como para ser utilizado seriamente en cuanto a comparación de rendimiento de máquinas distintas. Este bucle de retardo se ejecuta en el arranque para depurar y comprobar las caches y se encuentra definido en /usr/src/linuxopenmosix/init/main.c. La variable correspondiente del núcleo loops_per_sec se usa en varios controladores de dispositivo en las secciones net, scsi y Proyecto OpenMosix - 22

23 char. Las verdaderas funciones de retardo están en ensamblador, y por lo tanto cada plataforma tiene su propia función en include/asm/delay.h Una guía muy aproximada sobre los BogoMIPS podría ser: Sistema BogoMIPS Comparación Intel 8088 frecuencia_reloj * (0.004 ± 0.001) 0.02 Intel/AMD 386SX frecuencia_reloj * (0.14 ± 0.01) 0.8 Intel/AMD 386DX frecuencia_reloj * (0.18 ± 0.01) 1 Motorola frecuencia_reloj * (0.25 ± 0.005) 1.4 Cyrix/IBM 486 frecuencia_reloj * (0.34 ± 0.065) 1.8 Intel Pentium frecuencia_reloj * (0.40 ± 0.035) 2.2 Intel 486/AMD 5x86 frecuencia_reloj * (0.50 ± 0.01) 2.8 Mips R4000/R4400 frecuencia_reloj * (0.50 ± 0.015) 2.3 Nexgen Nx586 frecuencia_reloj * (0.75 ± 0.010) 4.2 PowerPC 601 frecuencia_reloj * (0.84 ± 0.015) 4.7 Alpha (todos) frecuencia_reloj * (0.99 ± 0.005) 5.5 Intel Pentium Pro frecuencia_reloj * (0.99 ± 0.005) 5.5 Cyrix 5x86/6x86 frecuencia_reloj * (1.00 ± 0.005) 5.6 Mips R4600 frecuencia_reloj * (1.00) 5.6 AMD 5k86 frecuencia_reloj * (2.00 ± 0.010) 11.1 Motorola frecuencia_reloj * (2.01) 11.2 El bucle de cálculo de los BogoMIPS no hace uso de paralelismo en procesadores por lo que no podemos utilizarlo para conseguir los BogoMIPS totales de nuestro cluster, tan solo podríamos aproximarlos mediante la suma de los BogoMIPS parciales de los tres nodos, obteniendo Router Se trata de un router 3Com ADSL 11g Wireless Router, las características más importantes de este aparato es que pueden conectar a una red local cuatro ordenadores mediante un cable de red junto con otros clientes wireless dándoles una conexión a internet. El uso que nosotros hemos dado a este router es de hub, es decir, concentrador. Un hub es un dispositivo hardware que integra distintas clases de cables, arquitecturas o tipos de redes de área local. Utilizamos este dispositivo como conexión central de la red que tiene configuración en estrella. Proyecto OpenMosix - 23

24 2.1.3 Topología de red y cableado Existen tres tipologías de red, la primera de ellas sería una red en anillo, la segunda sería la topología de bus o árbol y la tercera sería la topología en estrella. La siguiente imagen es una aclaración para comprender el tipo de esquema utilizado en esta red. El router (o nodo central) tiene la funcionalidad de transmitir por todas las salidas cualquier información que le llegue por la entrada (actuando a modo de repetidor). Le hemos desactivado la conexión Wireless debido a que ninguno de nuestros nodos se conecta mediante dicha tecnología. Otro componente importante de la red es el cableado utilizado para comunicar a los nodos con el hub central. Dependiendo del tipo de cable utilizado podremos transmitir a distintas velocidades. Tendremos que tener en cuenta a la hora de elegirlo: El área que va a ocupar nuestra red, la velocidad de transmisión deseada, el número de nodos que vamos a utilizar... Nuestra elección se ha decantado por cables de red de par trenzado UTP de categoría 5, también denominados cable de calidad de datos, soporta una velocidad de transmisión de hasta 100Mbps en distancias limitadas de hasta 100 metros. Este tipo de cable es el más económico, ofrece mayores limitaciones de velocidad de transmisión y alcance que otras soluciones como podrían ser la fibra óptica o el cable coaxial. Existen dos modelos dentro del cable de par trenzado: UTP: Par trenzado sin apantallar, se trata del modelo más extendido debido a su menor coste. Hay distintas calidades dentro de este modelo que van de la 1 a la 5 siendo la calidad 5 la mejor de todas ellas. STP: Par trenzado apantallado, este modelo es el de mayor calidad debido a que está recubierto por una malla metálica que lo aisla aún más de las interferencias de los pares cercanos. Proyecto OpenMosix - 24

25 2.2 Versiones del software: Es muy importante instalar las mismas versiones del software en cada uno de los ordenadores para evitar problemas de incompatibilidad y para que el trabajo del cluster sea óptimo consiguiendo mejorar su rendimiento Distribución de linux Para trabajar con el cluster hemos instalado la misma distribución de linux en los tres equipos. Nuestra elección ha recaído en una Debian Sid, que se trata de la versión inestable pero la más actualizada. Actualizamos la lista de archivos simultáneamente en los tres nodos a día de 15 de febrero de 2004 a las 21:00. Conseguimos tener las mismas versiones de todos los paquetes instalados para evitar problemas de incompatibilidades y para conseguir unos resultados mas fiables a la hora de realizar las pruebas y mediciones posteriores OpenMosix Una de las fases de la instalación del cluster consiste en el parcheado del kernel de linux, es decir, aplicar una serie de cambios en la configuración original del núcleo del sistema para que nos permita utilizar las características computacionales del cluster de alto rendimiento. Parar poder llevar a cabo el proceso de parcheado del kernel debemos descargar el fichero de texto que contiene los cambios con respecto al kernel estándar, es decir las nuevas funcionalidades que vamos a agregar al sistema. Este archivo se encuentra en la página web del proyecto OpenMosix ( en esta página podemos encontrar todo lo referente al proyecto junto con los programas y archivos necesarios para su uso. La última versión del proyecto se encuentra en el kernel y su parche fue publicado el día 30 de noviembre de Hemos elegido esta versión por ser la más actual y haber corregido posibles errores de versiones anteriores. En base a esta elección tendremos que optar por una versión del kernel Versión del kernel El kernel de linux, es decir el núcleo del sistema, es la parte mas importante del sistema operativo pues se encarga de llevar el control de la memoria, los procesos y el hardware del sistema. Existen distintas versiones del kernel debido a las nuevas mejoras y nuevas prestaciones que se van añadiendo periódicamente. Proyecto OpenMosix - 25