|
|
Status: Active
Also involved: none
|
|
9grid.it |
|
The 9grid.it project is an experiment in grid computing using plan9 from Bell Labs, its main objective is building three plan9 clusters in three different domain and connect them in a grid using software already written or writing pieces of code eventually needed.
I want to try to build such structure on top of an already distributed system instead of running tons of middleware software on systems designed (many and many years ago) to be sigle workstations.
I have also some secondary objectives:
- Using virtualization technologies for parts of such environment.
- Integrate that clusters with services already present.
- Evaluate if plan9 or related technologies may be used for some other project.
- Port some my other project to plan9.
|
|
|
|
|
|
Status: Active
Role: creator and project leader
Past collaborators: Igor, Simone
|
|
The Libidentif Project |
The Libidentif Project aims to built a probabilistic command recognition library for *NIX and a similar fileserver for Plan9, we intend to develop an "easy to use" set of API for programmers that will correct inside a CLI (Command Line Interface) the given commands on a probabilistic way and according to known templates.
We also intend to develop some "ready to use" application.
|
|
|
|
|
|
Status: coming soon
Also involved: none
|
|
Marketdb |
|
|
|
Web page not (yet ?) available
|
|
|
|
Status: coming soon
Also involved: none
|
|
MEL |
|
|
|
Web page not (yet ?) available
|
|
|
|
Status: Active Role: Creator and Technical coordinator
Also involved: Claudio, Francesco On the behalf of: Physics Dept. and INFN Perugia
|
|
Scheduling optimization |
|
In our Physics Department we have a Linux cluster with about 200 Cpus running Torque/Maui as Resource Manager/Scheduler. Our farm has many singularites:
- It's a GRID farm connected with the EGEE european infrastructure.
- Beyond GRID jobs it serves also local people jobs.
- It has been built with the economic contribution of different local groups (that work on different physics experiments)
- It uses virtualization technologies.
In this scenario the scheduling is a key point of the whole infrastructure, there are many needs to be satisfied and often requirements are not compatible one with each other. The number of variables that influence the scheduling behaviour are so much that the optimization is an hard task.
This project is about finding a way to optimize our farm in particular and about the scheduling optimization in general. To achieve these results our work is divided in some areas:
- Using virtual machines to create custom farms confiuration to make real launch of jobs.
- Using a simulator (the MAUI simulator) to simulate both these "virtual farms" and our real farm.
- Build a set of metrics to evaluate how much our configurations works well (both real and simulated)
- Validate the simulator (using montecarlo techniques)
- Build an infrastructure for large scale simulation of many changing configurations.
- Build simulations analysis tools.
- Build tools to evolve scheduler configurations via GA (Genetic Algorithm)
|
|
|
|
|
|
Status: Active Role: co-creator and Technical coordinator
Also involved: Riccardo On the behalf of: Physics Dept. and INFN Perugia
|
|
Dynamical Domains |
"Dynamical Domains" is a project in which an application (called manager) is able to interact with a batch system and to run a set of different kind of domUs according to given rules on top of a pool of dom0. This is useful when for example you have very different computational tasks which requires completely different operating systems. Instead of compiling compatibility libraries, solve dependencies etc, you run a dedicated virtual machine for each task.
The manager have to pay attention to and manage various things:
- The dom0s status, capabilities, networking and type (It has a disk ? It is via NFS ? etc)
- The list of domU types and their characteristics (
- Their requirements (How much RAM and processors they need ? What is the way of booting: local disk, file, via iSCSI, via NFS, etc ?)
- The status of one or more batch system and its jobs.
- The migration of domUs if necessary and possible
- The high availability of services running on the domUs
|
|
|
|
|
|
|
Status: Active Role: Creator and technical coordinator
Also involved: Flavio On the behalf of: Physics Dept. and INFN Perugia
|
|
Metrix |
|
Metrix is an integrated monitoring system, it collect metrics and store them in a DBMS. It is made by 7 parts:
- A sendmetrix program that send UDP packets containing the value of a paticular metric to the server.
- A receivemetrix program the collect the data and store it to the DBMS.
- The DBMS itself. Most of the databases operations are made within it using stored procedure and triggers. Even the matrics manteinance configuration are stored in the DBMS.
- The web frontend written in perl is used to administer the system and view the values.
- An agent server and client that can check metrics current status. It is used to raise allarms or make actions.
- An information server and client used for external visualization systems.
- Similar server-client couple to control the system.
The key idea of Metrix is to use some advanced feature of DBMSs such as views, stored procedure and triggers, to arrange data in a different way from an usual central logging system.
An example can be the temperature of a room (it is in production in the Computer Science Laboratory of the physics department) taken in some points of the room and then using a view to give the average temperature.
Other use may be datacenter monitoring, system log archivial etc.
Another key idea is to keep the system much simple as possible so to put it everywhere. The temperature reading system for example is build around a FOX-board (an embedded Linux system) with a 1-wire bus.
|
|
|
|
|
