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