Teil 2.8 - HackMD

AP1: Fabric, Roles AP2: LSDF Speicher angeboten AP3: Beratung/research, mehr nicht AP4: Fabric Kram en detail, Schnittstellen im Frontend/Backend, HPC-> Delayed AP4.1.4: OAI-PMH AP5: .2 und .3 erledigt dank Nicole, .4 ist ungeklärt, .5 delayed//Probleme beschreiben, .6 Webformular das was generiert. AP6: - AP7: Versionierung --> Pierre AP8: - AP9: Chemotion-Edu AP10: - AP11: Felix schreibt ExU, Chemotion-as a Service, Service Team AP12: bwsync share, Nicole. # Teil 2.8 Bedarfe wäre gut # AP2: Modulentwicklung Bereits bei Projektstart war geplant, den Online-Speicher der Large Scale Data Facility (LSDF) am SCC zu benutzen. Im bisherigen Projektverlauf wurden Bedarfe untersucht, die sich für den effizienten Betrieb des Chemotion-ELN mit dieser Infrastruktur ergeben. Folgende Punkte wurden adressiert: - Zugriffsprotokolle: Bisher ist der Zugriff auf Daten, die auf der LSDF gespeichert sind für MoMaF-Services lediglich über SSH-FS und SFTP möglich. Es wurden alternative Protokolle diskutiert, die zu den Zugriffsmustern des Chemotion-ELN besser passen. Es zeigte sich, dass Zugriffe ausschließlich auf Dateiebene erfolgen und Block-level-Zugriffe nicht notwendig sind. Ebenfalls muss nicht vollständige POSIX-kompatibilität gewährleistet werden. Es erscheint somit sinnvoll, auf das für Dateizugriffe optimierte SMB-Protokoll zu wechseln. Dies erfordert die Kooperation mit dem Betreiberteam des Dienstes. Grundsätzliche Machbarkeit wurde signalisiert, allerdings bisher nur im Testbetrieb implementiert. - Erweiterte Remote-Dienste: Es wurde festgestellt, dass bestimmte Daten-Operationen ausschließlich auf dem Speicherbackend passieren. Dies sind beispielsweise Kopier-, Transkodier oder Archivierungsvorgänge. Im Projekt haben wir untersucht, wie wir diese Vorgänge beschleunigen und effizienter umsetzen können. Im Ergebnis soll ein Dienst entstehen, der nahe beim LSDF-Speicher betrieben wird und der aufgrund der Lokalität von einer höheren Bandbreite profitieren kann. Ziel ist es, dass das Front-End (hier das ELN), lediglich einen API-Aufruf für eine solche langlaufende Aufgabe durchführt und der neugeschaffene Dienst diesen dann im Auftrag erledigt. Diese Überlegungen sollen im weiteren Projektverlauf weiter verfolgt und auf der MoMaF-Infrastruktur umgesetzt werden. - Versionierung der ELN-Historie: Um eine bessere Nachverfolgung von Forschungsvorhaben zu gewährleisten, wurde ein Weg gesucht, um bestimmte Vorgänge des ELN zu dokumentieren. Hierbei geht es in erster Linie darum, Forschenden die Möglichkeit zu geben, die eigenen aber auch die Änderungen Dritter an Datensätzen über einen bestimmten Zeitraum einzusehen. Wir erwarten, dass dies besonders bei Berichten, Publikationen und Auswertungen hilfreich sein wird. Technisch soll diese Komponente als Erweiterung des ELN behandelt werden und die Kernfunktionalität in einen Mikro-Service augelagert werden. Somit soll stetige Skalierbarkeit und Modularität zur unabhängigen Entwicklung gewährleistet werden. Im bisherigen Projektverlauf ist ein erster Demonstrator entstanden, dessen Funktionalität bereits einige Use-Cases abbildet. Der Demonstrator basiert auf einer HTTP-basierten Schnittstelle und einer Redis-Datenbank. Die Implementierung ist in Python realisiert. Für die Implementierung mittels HTTP spricht, dass dieses Protokoll einfach an das Chemotion-ELN angebunden werden kann, aber dies auch für andere Anwendungen möglich ist. Redis wurde aufgrund der sehr hohen Geschwindigkeit und Skalierbarkeit gewählt. Beide Eigenschaften sind notwendig, sobald MoMaF von einer Vielzahl an Nutzern gleichzeitig benutzt werden soll.  > TODO: Versionierungsdienst mehr ausbauen? # AP3: > TODO: Über Aktivitäten in verschiedenen Gruppen und Gremien, beispielsweise dem Research Data Management-Service-Team # AP4:  Ausgehend von der Architektur des Antragsdokument (siehe [Antragsdokument], Abb. 3) haben wir die MoMaF-Infrastruktur in mehrere Bereiche gegliedert: - MoMaF-ELN als primärer Einstiegspunkt für Forschende: das Chemotion-ELN bildet das Front-End um u.a. Daten zu importieren und zu verwalten, Experimente zu dokumentieren und Daten auszuwerten. - MoMaF-Repositorien: Das MoMaF-SDC bindet mehrere verschiedene Repositorien ein und erlaubt den direkten Datenaustausch zwischen ELN und Repositorium. Hierdurch soll die Veröffentlichung von Daten und deren Anreicherung mit Metadaten vereinfacht werden. - Externe Ressourcen: Neben den von MoMaF selbst betriebenen Diensten wird es möglich und notwendig sein, Dienste anderer Anbieter zu integrieren. Dies soll über bestehende und neu geschaffene Schnittstellen geschehen. Beispiele hierfür sind diverse Speicherdienste, wie bwDataArchive oder bwHPC. - Unterstützung der Prozesse durch maschinelles Lernen: Daten- und Prozessbeschreibungen sollen durch neue Recommender-Funktionen, beispielsweise bei der Auswahl passender Metadaten, verbessert oder beschleunigt werden. ![Abb. 3](2020-12-20-14-18-55.png) Diese Ansicht zeigt, welche Komponenten und Schnittstellen zu Beginn des Projekts als notwendig identifiziert wurden. Im bisherigen Projektverlauf hat sich ein ausdifferenziertes Konzept mit teilweise abweichenden Komponenten und Schnittstellen ergeben. Dies betrifft vor allem den Teil, der in der Abbildung grob mit "Interfaces" überschrieben ist. So ist beispielsweise eine direkte Anbindung von "ELN" zu "HPC" oder von "Repositorium" zu "Online-Speicher" nicht möglich, sondern es wird jeweils eine Middleware zur Übersetzung von Zugriffen benötigt. Ziel ist es dabei, die Funktionalitäten der spezifischen externen Dienste (in Abb. 3 unter dem Begriff "Ressourcen" subsummiert) zu vereinfachen, vereinheitlichen, abzusichern und gegebenenfalls zu erweitern. Die Gesamtheit dieser Middlewares inklusive der benötigten Managementfunktionalitäten wird nachfolgend als Fabric bezeichnet. Im Rahmen dieses Zwischenberichts sollen die bisher untersuchten Aspekte der ursprünglichen Architektur und des Fabric beschrieben werden. Es ist zu erwarten, dass weitere konzeptuelle Anpassungen im Projektverlauf notwendig werden. ## AP4.1 - Schnittstellen  ### AP4.1.1 - Schnittstellen von ELNs zu Repositorien (IAM, IOC) > Nicole? ### AP4.1.2 - Schnittstellen von ELNs und Repositorien zu Speicher- bzw. Archivierungsdiensten (SCC) > TODO: LSDF/Archivanbindung ### AP4.1.3 - Schnittstellen zwischen ELNs und Big Data-Analyseumgebungen wie HPC, DIC für daten- oder rechenintensive Analyseaufgaben (SCC, IOC, IAM) > TODO: HPC Anbindung ### AP4.1.4 - Schnittstellen der Repositorien untereinander > TODO: hm ... Repo mach die Metadaten, die Daten liegen auf bwArchive. Wir regeln das staging und den export? ## AP4.2 - Ressourcenanbindung ### AP4.2.1 - Datenspeicher- und Auswertungsmanagementsystem (SCC, IOC, IAM) ### AP4.2.2 - Anbindung von Speicher- und Archivierungsdiensten (SCC) Zum Speichern von Daten, auf die regelmäßig zugegriffen werden soll (sog. "hot data"), bietet das SCC Zugriff auf die Large Scale Data Facility (LSDF) an. Der Zugriff erfolgt über gängige Protokolle, aktuell kommen primär SSH-FS und SFTP zum Einsatz. Diese Protokolle sind weit verbreitet, allerdings in einigen Anwendungsfällen weniger leistungsfähig als andere Protokolle. Wie bereits im Obigen erläutert, arbeitet das SCC eng mit dem Team der LSDF zusammen, um in MoMaF das für unsere Anwendungen besser geeignete SMB-Protokoll anbieten zu können. Mit Blick auf die Ziele des Projekts hinsichtlich Interoperabilität ist es notwenig, das Rechtesystem auf SMB-kompatible Access Control Lists (ACL) zu übertragen. Dabei handelt es sich um Beschreibungen für Dateizugriffsberechtigungen basierend auf einem systemspezifischen Benutzer-Namensraum. Es besteht dabei die Möglichkeit einer Kollision von Benutzer-Identifikatoren, da der Namensraum der MoMaF-Plattform grundsätzlich größer sein kann, als der von dem Service unterstützte. Diese Problematik ergibt sich bei jedem Dienst, ist allerdings in den meisten Fällen theoretischer Natur, da selbst einfache Services viele tausend verschiedene Identifikatoren erlauben. Trotzdem wird es unerlässlich sein, einen Übersetzungsdienst zwischen verschiedenen Namensräumen zu betreiben: Eine Nutzerkennung folgt in vielen Fällen unterschiedlichen Regeln, die nicht zwingend mit denen der MoMaF-Plattform eins zu eins übereinstimmen. Hier ist dann eine Konversion nötig. Für die Anbindung an den Online-Speicher LSDF wird somit das SMB-Protokoll für reine Datenoperationen zum Einsatz kommen, zur Authentifizierung allerdings ein vereinheitlichtes Benutzermanagement, welches MoMaF-SDC-Benutzer in den Kontext des Speicherdienstes übersetzen kann. Die Authentifizierungsmethode verhält sich beim Archivdienst ähnlich: Wieder sind die Benutzer dienstspezifisch und müssen vom MoMaF-Namensraum übersetzt werden. Hier sind wir allerdings flexibler, da bwDataArchive ein programmierbares Benutzerinterface anbietet. Aus Gründen der Konsistenz wird dennoch der oben genannte Übersetzungsdienst eingesetzt, allerdings mit einer angepassten Backend-Schnittstelle. Zum Transfer von Daten wird beim Archiv SFTP eingesetzt. Dieses Protokoll ist für diese Anwendung geeignet, da sich die Zugriffsmuster von denen auf Online-Speicher stark unterscheiden: Es werden lediglich große Dateien geschrieben und es wird selten mit Änderungen zu rechnen sein. Das Protokoll ist hierfür aufgrund der Einfachheit geeignet, da es dadurch weit verbreitet ist und weniger potenzielle Sicherheitslücken bietet als komplexere Protokolle. ### AP4.2.3 - Asynchrone Datenbereitstellung und -auswertung (SCC) In einige Anwendungsfällen ist es notwendig, Daten in einer anderen Umgebung, beispielsweise dem HPC-Cluster zu analysieren oder zu verarbeiten. In diesen Fällen müssen die Daten in diese Umgebung übertragen werden. Um diesen Vorgang möglichst reibungsfrei zu gestalten, möchten wir in MoMaF asynchrone Datentransferdienste einsetzen. Die Aufgabe dieser Dienste ist es, Daten zu kopieren, ohne dass hierfür Benutzerinteraktion notwendig ist. Für den Datentransfer an sich gibt es bereits eine Vielzahl an Software-Lösungen, die produktiv einsetzbar sind und Zusatzfunktionen wie Verschlüsselung auf dem Übertragungsweg oder Integritätsprüfung bieten. Es wird allerdings notwendig sein, eine zusätzliche Schnittstelle bereit zu stellen, über die Datentransfers beauftragt werden können. Es ist dabei darauf zu achten, dass bei bestimmten Systemen (beispielsweise asynchronen Speichern wie Bandsysteme oder langsamen Netzwerktransfers über das Internet) möglicherweise ein Zwischenschritt, das sog. Staging, nötig sein wird. ### AP4.2.4 - Integration der Datenbereitstellungsmechanismen in die Arbeitsumgebung (SCC) ??? ### AP4.2.5 - Integration mit Big Data (DIC) und HPC-Analyseumgebungen zur Datenauswertung (SCC, IOC, IAM, AIFB, BIB) ??? # AP5 AP5.1 - Übergreifendes Rechtemanagement AP5.2 - Integration Rechtemanagement Arbeitsumgebungen/ELNs AP5.3 - Integration Rechtemanagement Repositorien AP5.4 - Daten-Authentizität (SCC, AIFB, IOC, IAM) AP5.5 - Integration des Rechte- und Rollenmanagements eingebundener Speicherdienste und HPC- bzw. DIC-Umgebungen (SCC) AP5.6 - Vereinheitlichung und Zusammenführung der Zugangs- und Beantragungssysteme (SCC, BIB) # AP5.5 - Integration des Rechte- und Rollenmanagements eingebundener Speicherdienste und HPC- bzw. DIC-Umgebungen (SCC) Auf Infrastrukturebene ist lediglich die Rolle des Administrators vorgesehen. Benutzern dieser Rolle ist es möglich, weitere Benutzer anzulegen und diesen beliebige Zugriffsberechtigungen zu erteilen. Zur einfachen Handhabung sind Berechtigungsgruppen vorgesehen. Es bleibt somit einem Administrator selbst überlassen, ob er weitere Benutzer anlegt und wenn ja, welche Rollen er für diese vorsieht. Mit diesem Konzept lehnen wir uns an bekannte Konzepte des Cloud-Umfelds an. Durch dieses Konzept ist es möglich, sowohl übliche Service-Benutzer (z.B. für Monitoring-Aufgaben oder zeitgesteuerte, nicht-interaktive Tasks) anzulegen, als auch Berechtigungsmodelle zu erlauben, die noch nicht von Anfang an geplant waren oder sich aus dem Kontext der Benutzer-Domäne ergeben. Ein derartiges Konzept wird jedoch nicht für jeden beteiligten Service implementierbar sein. Aus diesem Grund haben wir in der bisherigen Projektphase mit den Experten der AARC-Community[1] zusammengearbeitet, um derart komplexe Berechtigungssysteme auch auf weniger flexiblen Umgebungen zu ermöglichen. Daraus ist ein Demonstrator entstanden, welcher Token-basierte Authentifizierung auf Linux/Unix-Plattformen über ein PAM-Modul[2] ermöglicht. In ersten Implementierungen wurde dies für SSH-Logins eingesetzt. Diese Technologie ist die Basis für spätere Anwendung auf HPC-Clustern. Der AARC-Authentifizierungs-Blueprint[3] wird auch in einer Vielzahl anderer Großprojekte wie beispielsweise HIFIS oder NFDI diskutiert und verwendet. Wir erhoffen uns durch den Einsatz einer weit verbreiteten Lösung, dass der Quellcode als auch das Konzept durch das Viele-Augen-Prinzip ein größeres Maß an Sicherheit ermöglicht als eine Insel-Lösung, die ausschließlich in MoMaF zum Einsatz kommen würde. Außerdem verspricht diese Lösung eine maximale Kompatibilität mit zukünftigen Diensten und auch eine nachhaltig gesicherte Weiterentwicklung. [1]: https://aarc-project.eu/ [2]: https://de.wikipedia.org/wiki/Pluggable_Authentication_Modules [3]: https://aarc-project.eu/architecture/ # AP 5.6 Bei einigen Diensten der MoMaF-Plattform, die von Drittanbietern angeboten werden, ist es notwendig, vorab einen Zugang zu beantragen. Unsere Recherche ergab, dass es in vielen Fällen ausreicht, ein Online-Formular auszufüllen. Es zeigte sich weiter, dass viele Informationen (Name, Projektbeschreibung, etc.) mehrfach ausgefüllt werden müssen. Wir möchten Forschende hierbei unterstützen, z.B. indem wir ein vereinheitlichtes Online-Formular anbieten, das sämtliche Informationen einmalig abfrägt und anschließend Antragsformulare für Drittanbieterdienste generieren kann. Wir sehen hier noch Potenzial zur Verbesserung: Ein erster Schritt wäre, die generierten Formulare automatisch an eine entsprechende Kontaktadresse des Drittanbieters zu versenden. In einer zweiten Verbesserungsiteration könnte versucht werden, mit Drittanbietern einen automatisierbaren Weg der Datenübermittlung auszuhandeln und gemeinsam ein Gesamtkonzept zur vereinheitlichten Antragstellung zu erarbeiten. # AP7.4 Wie bereits erwähnt wurde im Projekt ein Demonstrator zur Versionierung der ELN-Historie entwickelt. Durch ein geeignetes Interface können diese Informationen Forschenden helfen, die eigenen Experimente nachzuvollziehen und gegebenenfalls Änderungen an Datensätzen, die zusammen mit anderen genutzt und bearbeitet werden, zu identifizieren und nachzuvollziehen. Weiter kann sich ein Wissenschaftler auch überlegen, seine Arbeitshistorie zusammen mit den Ergebnissen zur besseren Nachvollziehbarkeit und größeren Glaubwürdigkeit zu publizieren. Dies könnte einen besonderen Mehrwert für Review-Prozesse mit sich bringen. Der Demonstrator soll im weiteren Projektverlauf optimiert werden und als eine Komponente des Dienstbetriebs ausgebaut werden. # AP9 Zu Lehrzwecken wurde eine Instanz des Chemotion-ELN/-Repo inklusive des Chemspectra-Analyse-Services auf einem virtuellen Server des SCC aufgesetzt. Diese Lehrinstanz dient primär zu Demonstrationszwecken. Es hat sich allerdings als effizient herausgestellt, auf Basis dieser Installation eine einfach zu handhabende Container-Installation zu entwicklen. Es ist hierdurch möglich, die Installation stets mit wenig Aufwand in den Ursprungszustand zu versetzen (beispielsweise nachdem ein Lehrvorgang abgeschlossen wurde) oder komplett unabhängige, neue Kopien des ELN als separierte Arbeitsumgebung zu erzeugen. Wir sehen hierin einen wichtigen Baustein, um das Chemotion-ELN und Repositorium skalierbar zur Verfügung stellen zu können, da die Komplexität der Installation und des Managements während des Betriebs stark verringert wird. # AP11 Ähnlich zur Chemotion-ELN Instanz zu Lehrzwecken (siehe AP9) kann ein "Chemotion as a service" auch zur einfachen Etablierung in der Forschung beitragen. Das Konzept der Containervirtualisierung erlaubt ein einfaches und flexibles Aufsetzen von Dienstinstanzen, die von unterschiedlichen Forschergruppen genutzt werden können. Diese Instanzen können außerdem auch für Schulungen zur Nutzung von ELN durch das Serviceteam RDM@KIT (https://rdm.kit.edu) genutzt werden, um Forschenden die Funktionen zu erklären. Hierzu werden Szenarien in Kooperation mit den Forschenden und dem Serviceteam RDM@KIT erarbeitet. Eine im Rahmen der Exzellenzuniversitätsvorhaben zu Forschungsdatenmanagement am KIT entwickelte ELN-Variante kann von diesen Arbeiten profitieren und eine Nutzbarkeit des ELN auch für weitere wissenschaftliche Communities ermöglichen, wodurch ggfs. Synergien zu erwarten sind. # AP12 Sourcen auf Gitlab?

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.