Zusammenfassung: follow the link to find out more

Zusammenfassung: follow the link to find out more

Zusammenfassung: There is support from the OpenDaylight Project for OpenStack and a couple of “plugins” exist to integrate the cloud scheduler and open daylight ** Overview of available extensions and modules to add SDN support in OpenStack and analysis of their pros- and cons. ** Selection of the most appropriate technological options and integration of them within the IOMI OpenStack testbed ** Validation of the environment running a mix of scenarios and recording of the corresponding network setup such as - VM Movement and corresponding update of the Network Settings on the SDN Switches - VM Failure and Restart - Extension of an application by adding additional VMs - Shrinking of an application by stopping VMs ** Analyse and visualize the recorded network updates by extracting the necessary data from the Switch Rules and Table information in the SDN Switches before and after OpenStack triggered actions (der Teil übersteigt vmtl. den Umfang einer Bachelorarbeit je nachdem wie komplex diese Sache ist) * Vorbedingung: - Running Open Stack Testbed mit SDN fähigen Switchen

Zusammenfassung: Software Defined Networking has emerged as standardized mechanism to realize Multi-Tenancy in data centre architectures based on Ethernet connectivity. Due to its better suitability for scalable applications Infinband is still the dominating interconnect technology for cluster systems in the technical and high performance computing domain. ** Comparison on conceptual level of SDN/OpenFlow approaches and Infinband Subnet Manager ** Analysis of suitability for realizing a multi-tenancy technical computing/HPC System ** Overview of literature in this field and existing open source initiatives (e.g. OpenDaylight or OpenSM for Infiniband) ** Design and set-up of a test environment (simple beowulf style cluster with 8 nodes) and realizing a simple framework that allocate dynamically parts of the cluster to different customers - Option 1 is to use a very simple “job database” following a Producer/Consumer pattern that is just operated in FIFO manner - Option 2 is to use a queuing system such as OpenPBS and to make the network stuff in the prolog of the job script (maybe too complex?) - Option 3 is to use a Cloud Orchestrator to distribute the jobs (maybe too complex?) ** Some automated validation by realizing jobs running on the cluster that attempt to access nodes from other customers… Pre-Condition/Open Points: * SDN capable Switch with 1GE ~3000€+ * 8 “Nodes” * Infiniband components that support OpenSM (old bwGrid nodes?), costs for new IB Switch and IB cards with OpenSM support might be too pricy.

Zusammenfassung: Complex Event Processing (CEP) beschäftigt sich mit der Erkennung, Analyse, Gruppierung und Verarbeitung voneinander abhängiger Events. Werden CEP Engines in verteilten Systemen eingesetzt müssen sie mit der Fehleranfälligkeit verteilter Systeme zurechtkommen. In dieser Arbeit soll die Esper OpenSource CEP Engine auf ihre Einsatzfähigkeit in verteilten System hin untersucht werden. Daneben soll eine exemplarische Implementierung von Fehlertoleranzmechanismen stattfinden.