SETI@home Informes Técnicos - 2001 Tech News - 1999 | Tech News - 2000 Regreso a SETI@home Esta página contiene las últimas noticias técnicas en los aspectos astronómico e informático de Seti@home. Trataremos de mantenerlo actualizado, pero como puede haber un desfase de varias horas (o en el peor de los casos días) con la traducción, si lo desea puede consultar la versión inglesa Traducción a partir del 21 de Mayo de 2001 - Fecha de inicio de esta web Junio 26, 2001 Durante las últimas semanas hemos tenido problemas con la conexión del nuevo servidor web a la base de datos. Por eso las estadísticas de usuarios/equipos se generaban en un servidor secundario. Esta tarde hemos apagado brevemente el servidor de datos y reinicializado los dos servidores web para arreglar el problema. Para el arreglo hemos necesitado volver a una version anterior del sistema operativo Solaris. hasta ahora va bien. Vamos a esperar un dia antes de decir que la operación ha sido un éxito. Junio 20, 2001 Otra mañana complicada: Hemos actualizado la versión Informix de la base de datos de usuarios, sobretodo motivados por la necesidad de conseguir que el nuevo servidor Web maneje correctamente los CGI. Ultimamente teniamos muchos problemas (por si no se ha dado cuenta) porque hay un conflicto de las nuevas versiones de Solaris con las versiones más viejas de Informix. La actualización ha ido bien. De todas maneras, aun no se han solucionado la totalidad de los problemas - no podemos realizar busquedas en las bases de datos del nuevo servidor Web, y por eso los CGI todavia funcionan en el computador auxialiar, iosef. Tambien, despues de reinicializar el servidor de datos, hemos encontrado problemas pronto, y las conexiones se caian cuando se relaizaban búsquedas en la base de datos. Algunos usuarios se habrán encontrado con el error "unknown user" (usuario desconocido). Parece que la anterior configuración de Informix no se entendía con la nueva versión. Después de investigar un poco hemos conseguido contentar a informix y continuar con nuestra actividad normal. Llegados a este punto hemos vuelto a conectar el servidor de datos, y la búsqueda de usuarios por CGI. Desconectamos la función "View recently Completed Results" (Ver resultados completados recientemente) porque necesita conectarse a la base de datos científica, que no está activa para permitirnos construir algunos índices que necesitamos desesperadamente. Al construir los indices las consultas serán muchísimo más rápidas. A proposito, "Ver resultados completados recientemente" es lo que antes era "ver últimos 10 resultados". ¿Porqué ese cambio? para hacer las búsquedas más rápidas, Este nuevo método restringe las búsquedas a sólo las últimas semanas, mientras que el anterior buscaba en los resultados de los últimos 2 años. Los usuarios tenían muchos problemas de pérdida de conexión debido a la cantidad de tiempo que llevaba el proceso. Así que ... ahora trabajamos en 1) Conseguir que el nuevo servidor web contacte con la base de datos de usuario, y 2) Construir los indices de la base de datos científica. Junio 19, 2001 Muchas cosas: 1) Los problemas que causan las fluctuaciones de energía aleatorias (y el gran corte de energía del 14 de Junio) han sido solucionados por nuestro electricista. Tuvimos que hacer una desconexión de 2 horas esta mañana y nuestros servidores web y de datos no estaban accesibles durante ese tiempo. Ya están de nuevo funcionando. 2) Ayer activamos "Last 10 Worunits" (últimas 10 unidades), pero debido a un problema en el firewall algunos usuarios no podian ver estadísticas detalladas. El problema se solucionó esta mañana. 3) El servidor de datos todavía sufre las consecuencias de la caida de la base de datos científica del mes pasado. En ocasiones deja de funcionar durante breves peiodos de tiempo (entre 15 y 20 minutos). Esto pasó regularmente durante la semana pasada, y hemos estado diagnosticando e intentando solucionar el problema. 4) Las páginas de estadísticas y gráficos no se han actualizado durante los últimos 10 dias. El motivo han sido los constantes apagones, trabajos en la actualización de la red y los fallos de imcompatibilidad encontrados durante el proceso de instalación. Junio 16, 2001 Paros planificados durante la próxima semana: Lunes, 18/6/2001, inicio a las 17:00 UT. Un paro de 2 horas para actualizar Informix en la base de datos de usuarios. Martes 19/6/2001, inicio a las 15:00 UT. Un paro de 3 horas por reparaciones del sistema eléctrico en el Laboratorio de Ciencias del Espacio. June 14, 2001 Tuvimos una pérdida inesperada de energía anoche y se convirtió en un paro de varias horas. El electricista del edificio ha encontrado un fallo en el panel de distribución y ha realizado un arreglo temporal, pero se tendrá que reemplazar el panel pronto, seguramente el Lunes. Será un corte de 2 horas que anunciaremos en la página principal. Junio 12, 2001 Las tarjetas RAID continuan dando problemas. Afortunadamente la nueva arquitectura de disco (que duplica a través de las controladoras) a evitado mayores paros. Desgraciadamente, se ha corrompido el indice que controla las unidades que se han enviado. Reconstruimos el indice el viernes. Estamos considerando desactivar la escritura caché en las controladoras de disco para evitar problemas de este tipo. Esperamos que no afecte mucho al rendimiento. Tambien (finalmente) hemos encontrado y eliminado el error que causaba ocasionalmente el desbordamiento de mensajes de "unidad de trabajo duplicada" Junio 5, 2001 Esta mañana hemos reemplazado el antiguo servidor web por uno mucho mejor. Todo iba bien hasta que nos hemos dado cuenta de que la nueva máquina no podía "hablar" con las base de datos de científicas y de usuarios. Todavía trabajamos en el problema, y la solución podría necesitar la instalación de nuevas versiones del software de bases de datos para resolver los conflictos con las últimas versiones de Solaris. Mientras hemos instalado un segundo servidor web para manejar los CGI básicos, y estamos creando enlaces a este servidor auxiliar. Es una medida temporal. Las estadísticas de equipo puede que no se actualicen con regularidad durante este periodo. Junio 4, 2001 Durante el fín de semana el servidor web dejó de funcionar. Aún no estamos seguros de porqué - Probablemente se llenó la tabla de procesos. Las buenas noticias son que recientemente recibimos un nuevo Sun Ultra con doble procesador para reemplazar el actual servidor. El cambio se hará durante esta semana. Dense cuenta que durante el proceso del cambio las estadísticas de usuarios y equipos podrían dejar de funcionar durante un día más o menos ( Sólo en el aspecto ya que no afectara a nuestras bases de datos) Tambien podríamos cerrar las estadísticas de usuario por un breve período de tiempo. Las noticias sobre el proceso se expondrán en la página principal. Junio 1, 2001 Que semana ! La semana pasada completados la restauración de nuestra base científica De todas maneras, al hacerlo tambien hemos restaurado un índice estropeado, que habiamos reparado recientemente. Así que lo hemos tenido que volver a reparar. Tambien necesitabamos hacer algunas actualizaciones en la base de datos, porque ahora era inestable con nuestras unidades en disco y las colas de resultados. Estamos realizando una comprobacián final para ver si ahora todo está correcto. El servidor funciona normalmente, pero los divisores de unidades están temporalmente apagados. Esto significa que la cola de unidades está estática y hay una pequeña posibilidad de que un usuario rápido obtenga una unidad duplicada. Al mismo tiempo, un disco de nuetra base de datos científica maestra se estropeó. Pudimos cambiar el hardware y rápidamente restaurar la base de datos. Ahora usamos esta base de datos para descartar interferencias en la frecuencia de radio (RFI) y y buscamos señales persistentes. Los participantes de SETI@home han proporcionado muchos datos ! Permanezcan atentos. Tambien hemos tenido un problema de seguridad. Una persona o personas malintencionadas obtuvieron direcciones e-mail de usuarios. No hubo ruptura del servidor. Los malehechores hicieron uso de un agujero en nuestro protocolo de comunicaciones cliente/servidor. Obtuvieron alrededor de 50.000 direcciones de correo y las expusieron en una página web. Para nosotros esto es un robo importante de nuestros (tambien suyos) datos y estamos investigando acciones legales contra la persona o personas. Si cree que ha recibido un e-mail del malhechor, por favor vaya aquí. Hemos cerrado el agujero en la seguridad con el efecto de que algunos campos en el fichero user_info.sah ahora están en blanco. Nos damos cuenta de que esto es un problema para algunos programas que trabajan con seti@home y restauraremos algunos de los campo. Informes técnicos no traducidos May 16, 2001 After several days of attempting to fix the damage to the database, we've come to the conclusion that a restore is the only remaining option. We're taking the opportunity to modify the server configuration for what we hope will be enhanced reliability. Malfunction of the RAID controllers has been the cause of most of our major outages. We've decided to stop using hardware RAID and move to a software RAID configuration. Software RAID will allow is to mirror and stripe across controllers, so the failure of a single controller should not shut us down or lead to an unrecoverable situation. We're in the process of reconfiguring now. The restore should start tomorrow. There are 13 tapes that need to be restored. Last time it took about 4 hours per tape, so that's a bit more than two days, assuming we don't sleep. May 14, 2001 On Saturday, one of the RAID cards in the science database machine indicated that all of the drives attached to it had failed. Since then the server has been running as well as it can without the science database. We're working on fixing the problem. Hopefully it won't require a restore from backup. May 11, 2001 Last night the server started generating spurious "duplicate result" messages. The cause appears to be related to a server revision made yesterday afternoon. We've reverted to an earlier server version and are investigating the problem. April 30, 2001 Yesterday, the informix engine running our science database hung, apparently with a resource contention. It did so again today. We are looking into the cause. We did take advantage of the downtime to upgrade the science DB machine (one of the Sun E450's). We added 2 more CPUs and another .5GB of real memory. April 5, 2001 We are now well into the data quality step of analyzing the results from the 80 million workunits thus far distributed. To check data quality, each work unit is analyzed by 2 or 3 (and sometimes more) clients and the redundant results are checked against one another. We choose one result out of this per-workunit result set and insert it into our new master science database. The master science database will thus have one and only one canonical result for each workunit analyzed. References to all participants who contributed results for each workunit are maintained on the online science database. We call the program which chooses the canonical result the "redundancy checker" or "RC" for short. The RC chooses the canonical result based on agreement with other results from the same workunit set. Agreement is seen when signals contained in one result match value for value with signals contained in another result from the set. We don't insist on a exact match, as signals that really do agree may vary slightly because of floating point roundoff and the effects of differential chirping. We are pleased to find that only a tiny fraction of results do not pass the redundancy test. Look for a detailed discussion of the RC algorithm and statistics in a future science newsletter. As this is an ops news page, on to a discussion of our new server set up! SETI@Home originally had 2 databases on independent servers to serve workunits to the end processors (clients), receive the results and keep track of user statistics. We had intended to perform science analysis on the database that received and stored the results of the workunits from the end processors. After a while we found that it was not possible to do any analysis and also receive results effectively. One function would impact the other. So it was decided that we needed to replicate the on-line database to a separate sever so that we could do off-line analysis without impacting on-line response times. The on-line server is a SUN 450 Enterprise multi-processor configuration with 2 GB ECC RAM and around 400 GB of RAIDed disks. We use several SCSI controllers with 64 MB cache with RAID 1+0 configurations. We use Informix Dynamic Server software to implement our high performance databases. This on-line database accepts a number of redundant results for each workunit. Thus, the size of the on-line database could be reduced by 66% to 75% once the canonical results have been chosen. The new master science database is currently being loaded by the RC. The new server is based on a Compaq 570r with 2 CPUs and 1 GB ECC RAM running Solaris and Informix. It has 2 SCSI-2W controllers and 144 GB on 16 drives. We expect the major part of the process to load this server to take around 50 to 90 days. Then we will be able to run a periodic process to update it with new results from the on-line database. We were able to define the database using a 'fragment' function for the tables. This allows Informix to distribute a table by row id across as many disk drives as the administrator thinks is needed. While this will not get the raw IO capacity of RAIDed configurations, it is possible to tune the IO capacity depending on the characteristics of the application and specific tables' needs. Currently Spike table (where we store all reported spikes) is the largest and most frequently accessed structure in the database. So particular care was taken to ensure that Spike table and its indices would be spread over a number of exclusive disk drives and not have IO conflicts with other tables. We had some problems getting the indices allocated exactly where we wanted them, since Informix has a fixed location for the required/implicit indices. In the end, we ensured that the fixed location would have enough disk drives and access paths to minimize the IO queues during high volume activity. In practice, the new database has been performing quite well. March 5, 2001 Around 11:00 GMT (3:00am PST) on Tuesday, February 27, 2001, network fibers were broken, cutting off the entire Space Sciences Laboratory and Lawrence Berkeley Labs from the internet. It turns out this was the work of vandals who cut the fiber in the process of gathering a bunch of expensive copper wire. Due to the difficulty in finding the break, and then repairing in the rain and mud (on a steep slope no less), the outage lasted over five days. The SETI@home website and data server were unaccessible for several days during the entire length of the outage. During this time we took the opportunity to take care of a few offline items, such as split our server equipment into two separate "data closets" - when put in one single closet, the equipment was heating up beyond spec. We came back on line on Saturday, March 3rd, and rather quickly recovered from the back log of clients trying to send results and get new workunits. We are operating normally now, though we are currently dropping a few connections a second, and are trying to determine why (possibly a disk mounting issue). February 7, 2001 We had a planned outage this morning for two hours to rearrange the server closet in order to make room for a new database system. We took this opportunity to replace one of the old RAID cards on the science database server with a new one, as well as clean up the terrible nest of power/ethernet/scsi/serial cables behind the server table. January 30, 2001 Due to a syntax error in an apache .conf file, one disk partition filled up, causing a general slowdown of the web server and the data server last night. This was easily fixed, and plans are being made to reduce server dependencies as much as possible (by moving them on bigger, separate disk partitions). January 15, 2001 An article discussing some of the details of SETI@home has been published in the IEEE Computer Society magazine "Computing in Science and Engineering." It it available in HTML form from their web site http://www.computer.org. January 8, 2001 Over the past several weeks, and especially last weekend, hardware problems on campus have been affecting the router which carries the SETI@home traffic. These problems cause large dips in our maximum bandwidth allowance, and therefore we've been dropping many connections to our server. Central campus is committed to fixing this problem as soon as possible.