Installation

Repository klonen und Konfigurationsdateien editieren

root@koala:~# git clone https://gitlab-ce.gwdg.de/koala/koala.git
root@koala:~# cd koala/install/compose-koala
root@koala:/root/koala/install/compose-koala# l
common.env  dias-koala/  docker-compose.yml  dsm.sys  koala.key  koala.pem  mysql_dump.sql

• Konfigurationsdateien die angepasst werden müssen: common.env, dsm.sys
• Sicherstellen, dass alle benötigten Pfade existieren, bspw.: /dias/workarea
• SSL-Zertifikat erstellen

Anmelden an der Docker Registry

root@koala:~# docker login docker.gitlab-ce.gwdg.de/koala/koala
Username: user@gwdg.de
Password:
Login Succeeded

Komponenten starten

Es werden so viele loader gestartet wie CPUs vorhanden sind.

root@koala:/root/koala/install/compose-koala# export NR_OF_CPUS=$(grep -c processor /proc/cpuinfo)
root@koala:/root/koala/install/compose-koala# docker-compose up -d --scale loader=$NR_OF_CPUS

Deployment

Die koala-Komponenten werden in Docker Container gestartet und mit docker-compose orchestriert. Eine Beispiel docker-compose.yml Datei kann im Installationsverzeichnis gefunden werden. Für ein Standard Deployment müssen die folgenden Applikationen gestartet sein: web, scheduler, purger, loader, retriever, stats. Lastabhängig können weitere loader/retriever Applikationen gestartet werden.

Minimale Systemvoraussetzungen:

• x86_64 Linux
• Docker >= 17.03.0-ce
• 2 CPU,
• 4 GB RAM,
• HDD System 20 GB
• HDD DB 50 GB
• HDD Workarea 200 GB,
• HDD Downloadarea 200 GB
• HDD Uploadarea 200 GB

Note

Die Schätzungen sind Erfahrungswerte mit SIPs < 50 GB. Für größere SIPs müssen entsprechend größere Verzeichnisse bereitgestellt werden.

Typisches Beispiel einer produktiven Installation

Hardware

-	koala-test	koala-prod
Beschreibung	Testsystem	Produktives System
Applikationen	Datenbanken, MessageQueue, Cache, Koala Applikationen	Datenbanken, MessageQueue, Cache, Koala Applikationen
CPU	2	4
RAM	8 GB	6 GB
HDD	1 TB	256 GB
SSD	-	50 GB (uploadarea), 100 GB (workarea)
Plattform	VM	VM

Cluster

Variante A

Anwendbar falls die Verarbeitungszeit der loader der Flaschenhals ist.

• Geteilter Speicher zwischen koala-1 und koala-2
• Die Web-Applikation läuft nur auf einer Instanz
• Die Middleware läuft nur auf einer Instanz
• Die Ingests werden über die zwei Instanzen verteilt
• koala-2 braucht von außen nicht erreichbar zu sein und benötigt daher auch keine öffentliche IP

Variante B

Anwendbar falls die Übertragung per SFTP der Flaschenhals ist.

• Retriever und Web-Applikation laufen nur auf einer Instanz
• Die Middleware läuft nur auf einer Instanz
• Ingests werden über zwei Instanzen verteilt
• Retrieves werden nur einer Instanz ausgeführt
• Kein verteilter Speicher benötigt
• koala-2 muss von außerhalb erreichbar sein und benötigt daher eine öffentliche IP
• Der Purger muss auf jedem Host bereitgestellt werden
• Die Client Appliaktion muss per /api/ftpinfo abfragen welcher Host für das Hochladen verwendet werden soll.

Variante C

Anwendbar in den gleichen Fällen wie A, B und bei mehreren gleichzeitigen Retrieve-Vorgängen, sowie hoher Schreib- und Leserate in Bezug auf die Middleware.

• Gleiches wie B
• Die HTTP- und SFTP-Schnittstellen von koala-1 und koala-2 können austauschbar verwendet werden.
• koala-db ist ein separater Host für die Middleware
• koala-db benötigt keine öffentliche IP

Software

Frontend

Backend