High-Performance-Computing (HPC)-Ressourcen sind von essentieller Bedeutung für eine Vielzahl von wissenschaftlichen Forschungsbereichen. Zumeist handelt es sich um Distributed-Memory-Cluster, die sich aus mehreren Rechenknoten zusammensetzen. Die Arbeit mit diesen Systemen ist oft mühsam, besonders für Wissenschafter ohne formale Informatikausbildung. Sie erfordert die Vorbereitung und Übertragung von Eingangsdaten, das manuelle Sammeln von Ergebnissen, und vor allem Erfahrung im Umgang mit Kommandozeilenanwendungen. Derzeitige Ambitionen, den Zugang zu HPC-Clustern zu erleichtern, legen den Fokus vor allem auf die Bereitstellung von Web-basierten grafischen Benutzeroberflächen, die es erlauben Rechenjobs an das Distributed Resource Management System (DRMS) des jeweiligen Clusters zu schicken. Dies bringt bereits wesentliche Bedienungsvorteile gegenüber dem Benützen der Kommandozeile, aber beseitigt nicht die Notwendigkeit des manuellen Umgangs mit Eingangs- und Ausgangsdaten. Wissenschafter müssen auch mit diesen Oberflächen Daten aus ihren Anwendungen mit grafischer Benutzeroberfläche exportieren, sowie Ergebnisse nach erfolgter Ausführung wieder importieren. Unser Ansatz ist es, Zugriff auf Remote-Cluster direkt in grafische Desktopanwendungen, die von Wissenschaftern alltäglich verwendet werden, zu integrieren. Die Handhabung von Datenkonvertierung und Netzwerkkommunikation passiert im Hintergrund und ist transparent für den Benutzer, wodurch jegliche Bedienungsschwierigkeiten vermieden werden können. Andererseits muss der Benutzer weiterhin die Kontrolle über alle in Auftrag gegebenen Rechenjobs haben. Dies bedeutet vor allem, dass es möglich sein muss den Fortschritt der Jobs zu überwachen sowie sie gegebenenfalls vorzeitig abzubrechen. Im Zuge dieser Arbeit wurde eine Serverapplikation entwickelt, die auf HPC-Clustern installiert werden kann und Web-Services zum Starten und Kontrollieren von Rechenjobs zur Verfügung stellt. Die Applikation kann mittels eines automatischen Deployment-Prozesses auch mit Clustern in der Amazon Elastic Compute Cloud (EC2) genutzt werden. Zugang zu HPC-Ressourcen wurde mithilfe der entwickelten Web-Services direkt in die LigandScout-Software für molekulare Modellierung integriert. Diese Integration ermöglicht es, direkt aus der grafischen Benutzeroberfläche von LigandScout, große Moleküldatenbanken mittels Virtual Screening auf ihre biologische Aktivität zu untersuchen. Die eigentlichen, aufwendigen Berechnungen finden auf einem entfernten HPC-Cluster statt. Um dieses Virtual Screening effizient auf Distributed-Memory-Clustern durchführen zu können, entwickelten wir einen Algorithmus zum Aufspalten von Screening-Experimenten in mehrere unabhängige Teilaufgaben. Die dadurch notwendige Aggregation von Fortschrittsdaten sowie der finalen Ergebnisdaten passiert ebenfalls transparent für den Benutzer. Unsere Evaluierung beschäftigt sich hauptsächlich mit der Skalierbarkeit der entwickelten Software und analysiert weiters die Auswirkungen des Algorithmus zur Aufspaltung von Screening-Experimenten auf verschiedenen Clustern. Es wird gezeigt, dass unser Ansatz beinahe linear mit der Anzahl an Cluster-Knoten skaliert. Der Mehraufwand durch Netzwerkkommunikation sowie durch automatisches Aufspalten von Jobs ist insbesondere bei großen Screening Experimenten vernachlässigbar.
de
High Performance Computing (HPC) resources play a major role in facilitating scientific research. Mostly, these resources are present in the form of distributed-memory clusters consisting of multiple compute nodes. Working with these clusters is often cumbersome, especially for researches without formal background in computer science. It requires preparation and transfer of the input data, manual gathering of results, and command-line expertise. Current approaches for improving accessibility to remote HPC clusters focus on providing web-based graphical front-ends, which allow to submit jobs to the distributed resource management system (DRMS) running on the cluster. This comes with significant usability benefits over command-line usage, but does not circumvent the need for manually handling the input and output files. Scientists still have to export data from their graphical user interface (GUI) applications and re-import results later after the remote jobs are completed. We propose a different solution, namely to provide remote access to HPC resources directly within the graphical desktop applications, that scientists use in their day-to-day work. By handling necessary data conversion and network communication transparently to the user, this approach allows to completely evade any HPC usability barriers. At the same time, the user has to stay in control of the executed computational jobs, which requires access to DRMS features such as monitoring and cancelling running or pending jobs. In the course of this work, we have developed a server application that can be deployed on HPC clusters and which provides web-services for submitting and controlling computational jobs. Apart from on-site private clusters, the server software can also be used with clusters in the Amazon Elastic Compute Cloud (EC2) via an automated deployment process. As a practical use case, we have integrated transparent access to HPC resources into the LigandScout molecular design software through background invocations of the developed web-services. This solution allows to virtually screen large compound libraries on remote HPC clusters from within the LigandScout GUI. In order to run the screening algorithm on distributed-memory clusters, screening jobs are automatically split into multiple sub-jobs that can run on individual nodes. Progress and result aggregation is once again transparent to the user. Our evaluation focuses on the scaling capabilities of the developed software and explores the implications of the implemented job-splitting algorithm on different clusters. It is shown that our approach scales almost linearly with the number of cluster nodes. The introduced overhead through network communication and job-splitting is negligible when the screening experiment is sufficiently large.
