Meinung Disaster Recovery Konzept

[rothkraut]

Hallo zusammen,

ich hocke momentan an einem Konzept für ein Disaster Recovery zwischen zwei Standorten.
Mich würde mal interessieren, ob meine Idee so umgesetzt werden kann, und was eure Meinung dazu ist.

Folgendes Szenario:
Standort A und Standort B. Beide Cluster sind wie folgt aufgebaut:
-2 Nodes + QDevice
-externer Storage (ZFS) für VM-Disks (TrueNAS)

Standort A beherbergt das produktive Cluster. Sollte dieses komplett ausfallen, sollen die VMs im Standort B wieder hochgefahren werden können.


Meine Idee:

Die VM-Disks der TrueNAS werden stündlich von Standort A zu Standort B synchronisiert. Die TrueNAS ist an das Cluster in Standort B als Storage angebunden

Ich übertrage die .conf files der VMs von den beiden Hosts von Standort A zu den beiden Hosts in Standort B direkt in den Path "/etc/pve/nodes/ServerName/qemu-server".
Auch dies findet stündlich statt und überschriebt immer die bereits existierenden .conf-Files.
Dafür würde ich mir ein Skript bauen.


Sobald die .conf-File auf dem Host liegt, sollte ja eine VM mit dieser Config angelegt sein. Und wenn der Storage in beiden Clustern die selbe Bezeichnung hat (z.B. storage-zfs-01), sollten die virtuellen Disk ja auch direkt gefunden werden. Oder!?

Sprich es werden stündlich die VMs neu angelegt und die Festplatten werden auch stündlich aktualisiert.


Wenn es jetzt auf Seite A zum totalen Ausfall kommt, sollte ich doch in der Lage sein, die VMs an Standort B zu starten.

Wenn Standort A wieder laufen würde, müsste man den ganzen Spieß umdrehen, also Storage und .conf Fiels von B nach A synchronisieren etc.


Wie seht ihr das? Macht das Sinn? Wird es so technisch auch funktionieren?

Ich habe das noch nicht testen können, das ist nur meine erste Idee auf Papier.


Ich weiß man könnte das auch mit PVE-zsync realisieren. Aber mich schreckt ab, dass eine große Anzahl von Jobs gebaut werden müsste. Zudem weiß ich nicht, wie es sich verhält, wenn z.B. durch HA oder balancing die VMs zwischen den Hosts migriert werden müssen.

Ich habe auch folgenden Thread gesehen und nun am evaluieren, welche Option mehr Sinn macht:

[TUTORIAL] What Replaces SRM and vSphere Replication on Proxmox?


Schonmal vielen Dank für eure Rückmeldungen!

 

[Supaman]

Dazu folgende Gedanken:

Ein solches Setup würdevorausetzen, das der Datenstand annährend in Echtzeit syncronisiert werden kann - gibt die Datenanbindung das her ? Läuft das über das Intenet, oder ist es das Nebengebäude das mit 10GB+ angebunden ist ?

Insbesondere bei Datenbanken z.B. für das ERP System ist je nach Anzahl der User / Transaktionen ein Datenstand, der 1 Stunde hinterher ist, vielfach keine Option.

Weiterhin: Wenn die VMs an Standort B hochgefahren würden, könnten diese dann auch tatsächlich verwendet werden? Damit meine ich sowohl die benötigte Bandbreite als auch das Netzwerk Setup.

Bevor man ein solche Split Setup in Angriff nimmt, würde ich zu allererst alle Möglichkeiten ausschöpfen, den Betrieb an Standort A so robust wie möglich zu machen, z.B. Cluster mit Ceph, und dann die Server räumlich verteilen, zusammen mit den anderen Maßnahmen.

 

[TErxleben]

Ich finde das Setup ist recht gruselig.
Um eine DB im laufenden Betrieb nahtlos zu übernehmen, taugt es nicht für 5 Pfennig.
Entweder du hast einen entsprechenden Speicher, der das zulässt oder du hast Zeitintervalle, die zu deinen nicht kritischen Maschinen passt.
Eine DB mit PVE, Cluster hin oder her, nahtlos betreiben zu können, ist einfach Irrglaube/Wunschdenken.
Sonst halte ich 1h Synchronisationsfrequenz für komisch. Entweder fehlen 1h wichtige Daten in einer DB oder Tagesfrequenz reicht auch.

 

[ThoSo]

KO Kriterien :

1. Die Standorte ->
- Anbindung (Bandbreite für die Produktive Arbeit und den Sync-Aufwand!) und räumliche Entfernung
- über welches Volumen an VMs und Datenspeicher reden wir hierbei?

Wenn es jetzt auf Seite A zum totalen Ausfall kommt, sollte ich doch in der Lage sein, die VMs an Standort B zu starten.

Was wäre denn der totale Ausfall - die Hütte ist abgebrannt?

2. In der Regel haben die Standorte auch unterschiedliche IP Bereiche. -> Routing?

3. VM-Disks sind auf einem TrueNAS Storage und werden über die Leitung "kopiert" - die sind aktiv in Benutzung? Gesperrt? Und falls es dann doch klappt, sind die nach dem kopieren noch konsistent?

4. Wie oft ändert sich den etwas an den config-Files der VM, das man die stündlich synchronisiert?

5. Wie lange darf den der Ausfall sein?
- Brauche ich jetzt wirklich alles 1:1 am Standort B oder kann man das auf eine Anzahl für den Notfall reduzieren.
- Wenn du am Standort "B" bis alles wieder läuft mehr Zeit bindest als du für den Recovery am Standort "A" brauchst, wäre das auch schlecht.

Teste dein Vorhaben doch einmal mit 2 kleinen Testmaschinen an den jeweiligen Standorten

 

[TErxleben]

@ThoSo hat das schon schön weiter aufgedröselt. Lediglich der "Test" mit kleinen Testmaschinen ist m.E. irreführend, wenn man sich nicht so richtig sicher ist, wohin die Reise gehen soll.

 

[ThoSo]

@TErxleben was nützt dir das schönste Konzept, wenn es ohne Test nicht klappt?
Hier geht es um die Funktionalität und auch das Feeling ob die Rahmenbedingungen mit der Bandbreite passen. Und das während dem Tagesbetrieb.

 

[IsThisThingOn]

Ich verstehe schon das lokale HA Konzept nicht.

Da wird ein PVE cluster verwendet, aber mit dem TrueNAS gibt es einen SPOF? Wahrscheinlich auch noch X andere SPOF (Netzwerk).

Und welchen Fall möchte man genau abdecken mit dem "externen Cluster"? Wenn an Ort A brennt, kann an Ort B weitergearbeitet werden, mit einem 1h alten Stand?

Zudem, wenn nur der Storage übertragen wird, nicht aber der RAM, wie soll das sauber funktionieren? IMHO hast du dann ein crash ähnlichen Zustand der VMs.

Was ich anstelle dessen tun würde:
HA Cluster sind IMHO überbewertet.
Zwei PVE an Standort A mit lokalem Storage für VMs. Das rennt dann auch einiges schneller als per TrueNAS/Netzwerk. Die beiden PVE mittels PVE Storage Replication syncen. Das hat dann auch gleich den schönen Nebeneffekt, dass du bei PVE Updates die einen Neustart verlangen, alle VMs moven kannst. Standord B nutzt du ein PBS, dann hast du ein offsite backup.

 

[Johannes S]

Zwei PVE an Standort A mit lokalem Storage für VMs. Das rennt dann auch einiges schneller als per TrueNAS/Netzwerk. Die beiden PVE mittels PVE Storage Replication syncen. Das hat dann auch gleich den schönen Nebeneffekt, dass du bei PVE Updates die einen Neustart verlangen, alle VMs moven kannst.

Das wäre auch meine Präferenz, damit geht sogar Pseudo-HA Aber: Envtl. hat der OP schlicht nicht genug lokalen Storage und nutzt deshalb TrueNAS?

Standord B nutzt du ein PBS, dann hast du ein offsite backup.

Und zusätzlich zum PBS könnte man mit pve-zsnc die Gäste auf Standort b für ein schnelles Wiederanlaufen replizieren. Standort a) sollte auch einen PBS haben, dafür würde sich eine VM auf dem TrueNAS anbieten. Oder das qdevice.

 

[Bu66as]

Das mit den .conf-Files geht technisch, /etc/pve ist ja pmxcfs und ein Copy da rein legt die VM sofort im Cluster an. Ich würds trotzdem nicht so machen: die Gäste sind dann dauerhaft in Cluster B registriert und irgendwann startet die einer versehentlich oder ein Backup-Job in B greift sie ab, während A noch produktiv läuft. Ich würd die Configs einfach in ein normales Verzeichnis auf B kippen und ein kleines Skript haben, das sie im Ernstfall nach /etc/pve/nodes/<node>/qemu-server/ schiebt. Die Configs ändern sich eh selten, stündlich ist da völlig übertrieben. Und schau, dass du keine VMID-Kollisionen mit dem hast, was in B schon läuft.

Mehr Sorgen macht mir der Storage-Teil: wie replizierst du die TrueNAS genau? Wenn das ZFS send/recv ist, ist das Ziel-Dataset per Default read-only und du hast dort nur Snapshots liegen. Im Failover musst du also erst writable machen beziehungsweise vom letzten Snapshot klonen, sonst startet in B gar nichts. Das würd ich einmal komplett durchspielen, inklusive Rückweg nach A. Der Rückweg ist halt der unangenehmere Teil, weil du dann die Replikationsrichtung drehen musst und ein falsches zfs rollback genau die Daten killt, für die du das ganze DR gebaut hast.

Stündliche zvol-Snapshots sind crash-konsistent, deine DBs kommen in B hoch als hätte man den Stecker gezogen. Meist recovert das sauber, drauf verlassen würd ich mich nicht. Für die DBs würd ich zusätzlich einen nativen Dump oder Log-Shipping nach B fahren, das ist billiger als die ganze Storage-Replikation feiner zu takten.

 

[Johannes S]

Eine DB mit PVE, Cluster hin oder her, nahtlos betreiben zu können, ist einfach Irrglaube/Wunschdenken.

Datenbanken kann man in ProxmoxVE schon gut betreiben, man sollte dafür aber dann halt nicht ProxmoxVEs HA-Feature und Replikation nehmen, sondern die nativen Cluster-/Replikationsfeatures der jeweiligen Datenbank.

 

[rothkraut]

Moin!

Danke erstmal für die vielen Rückmeldungen. Ich möchte kurz auf einige Fragen und Feedback eingehen.

Hier noch ein paar Infos, welche die Situation noch etwas besser beschreiben:

Wir führen momentan eine globale Migration vom VM-Ware zu Proxmox durch. Dies soll nun auch für diese beiden Standorte durchgeführt werden.

Das Konstrukt, wie ich es oben beschieben habe, besteht momentan in unserer VMWare-Umgebung. Diese habe ich nicht geplant und auch nicht aufgesetzt. War alles vor meiner Zeit.

Envtl. hat der OP schlicht nicht genug lokalen Storage und nutzt deshalb TrueNAS?

Exakt. Ich habe leider auch keine Möglichkeit andere Hardware zu besorgen. Budget und so...

Da wird ein PVE cluster verwendet, aber mit dem TrueNAS gibt es einen SPOF? Wahrscheinlich auch noch X andere SPOF (Netzwerk).

Guter Einwand. Netzwerk ist redundant aufgebaut. Und wie gesagt an der Speichersituation kann ich nichts ändern.

Wenn an Ort A brennt, kann an Ort B weitergearbeitet werden, mit einem 1h alten Stand?

Klingt vllt blöd, aber ja. Standort A ist leider durch Umwelteinflüsse gefährdet. Es geht wirklich darum, dass das Gebäude im Extremfall zerstört wird oder für mehrere Wochen nicht genutzt werden kann (länger anhaltender Stromausfall etc.). Geht nicht um kurzzeitige Störungen oder ähnliches. Das Standort B nicht als Hauptstandort genutzt wird hat u.A. logistische Gründe und kann von mir ebenfalls nicht umgesetzt werden. Die Definition von einer Stunde Differenz kam mal aus dem Business. Dass eine schnelle Inbetriebnahme an Standort B umgesetzt werden soll ebenfalls. Bei Standort A handelt sich um ein Data-Center, welches noch viele andere kleine Standorte bedient.

In der Regel haben die Standorte auch unterschiedliche IP Bereiche. -> Routing?

Wie gesagt wurde dieses Konzept bereits mit VMWare umgesetzt. Für die VMs gibt es in den jeweiligen Netzen IP-Adressen.

Wie oft ändert sich den etwas an den config-Files der VM, das man die stündlich synchronisiert?

Das kann man natürlich auch auf einmal am Tag oder sogar einmal die Woche runterschrauben. Änderungen an den VMs finden kaum statt.

Insbesondere bei Datenbanken z.B. für das ERP System ist je nach Anzahl der User / Transaktionen ein Datenstand, der 1 Stunde hinterher ist, vielfach keine Option.

Wie bereits gesagt, kommt aus dem Business. Ist besser als z.B. ein Backup vom Vortag.

Wenn die VMs an Standort B hochgefahren würden, könnten diese dann auch tatsächlich verwendet werden? Damit meine ich sowohl die benötigte Bandbreite als auch das Netzwerk Setup

Ja. Wobei noch zu ergänzen ist, dass nicht alle VMs migriert werden müssen. Von einigen gibt es bereits eine Failover Instanz in Standort-B. Andere haben z.B. überhaupt keinen Mehrwert davon dort zu laufen. Wir sprechen hier von ~20 VMs

Ich würd die Configs einfach in ein normales Verzeichnis auf B kippen und ein kleines Skript haben, das sie im Ernstfall nach /etc/pve/nodes/<node>/qemu-server/ schiebt. Die Configs ändern sich eh selten, stündlich ist da völlig übertrieben. Und schau, dass du keine VMID-Kollisionen mit dem hast, was in B schon läuft.

Das klingt sinnvoll. Mit der einen Stunde ist auch wirklich übertrieben. ID-Kollisionen habe ich auf dem Schirm, aber danke für den Hinweis.




Am sinnvollsten wären einfach zwei PBS an Standort A und B (setze ich da sowieso auf) welche die Daten zwischen den Standorten hin und herschieben können. Dann die VMs aus dem Restore herstellen. Hier würde aber der Restore zu lange dauert. Zudem möchte ich keine stündlichen Backups der VMs anlegen lassen...
Geplant ist, dass ganze innerhalb von einer Stunde wieder zum Laufen zu bekommen. Ausnahme sind reine Datenbank-Server. Die Datenbanken werden separat gebackupt. Hier muss also nur die VM-Stehen.

 

[Johannes S]

Generell ist es bei einer Migration auch nicht verkehrt sich einen Proxmox Partner an Bord zu holen, gerade wenn es um solche kritischen Anforderungen geht.

Zum PBS: Die Wiederherstellung dauert natürlich immer so lange, wie sie halt dauert. Aber mit dem live-restore-Feature startet die VM samt Workloads bereits während des restores. Der Dienst steht also (mit entsprechend eingeschränkter Performance, weil die angeforderten Daten ja aus den Backup erst restored werden müssen) schneller wieder zur Verfügung.

Zum stündlichen Syncen der Configs: Ich würde trotzdem den gleichen Sync-Zyklus nehmen, einfach weil dadurch wahrscheinlicher wird, dass man nichts vergisst. Und bei zfs send/receive dauern die inkrementellen Replikationen ja nun nicht so lange, daher würde ich mal testen, wie weit man den Sync-Zyklus reduzieren kann, ohne dass es zu lange dauert. Auch damit der Datenverlust nicht eine Stunde, sondern ein kleineres Zeitfenster umfasst.

Für die Datenbanken würde ich wirklich dringend empfehlen die native Replikation der Datenbanken zu nutzen, um das Zeitfenster eines Datenverlusts zu begrenzen und die Konsistenz der Datenbank zu gewährleisten.

 

[IsThisThingOn]

Am sinnvollsten wären einfach zwei PBS an Standort A und B (setze ich da sowieso auf) welche die Daten zwischen den Standorten hin und herschieben können. Dann die VMs aus dem Restore herstellen.

Dann musst du aber an Standort B auch ein PVE Hardware haben, auf die du restoren kannst.

Irgendwie seltsame Kombi, du hast keinen lokalen PVE Storage an Standort A, weil du Hardware limitiert bist, möchtest aber PVE A, PBS A, TrueNAS A und PVE B, PBS B?

Ich fände PVE A mit lokalem schnellen Storage, Replication Task auf PVE B, Backup auf PBS B einfacher. Das wären 3 Kisten anstelle von 5.
DB zu clustern wäre natürlich schön, ist aber halt die Frage ob euer Netzwerk den Performance Ansprüchen genügt.

 

[Falk R.]

Hi, das Konzept ist gar nicht schlecht. Du solltest nur absichern, dass die VMs nicht auf ClusterB gestartet werden.
Hast du dir auch schon um das Netzwerk und die Anbindungen der Clients gedanken gemacht? Das Netzwerksetup ist viel kritischer als die vielen gar nicht so relevanten Bedenken zu den VMs.
Die VMs sind ganz normal Crash Konsistent wie bei einem Stromausfall und das sollte kein Problem darstellen.

 

[rothkraut]

Generell ist es bei einer Migration auch nicht verkehrt sich einen Proxmox Partner an Bord zu holen, gerade wenn es um solche kritischen Anforderungen geht.

Stimme ich dir voll zu, aber wenn eben kein Geld ausgegeben werden darf, muss es eben so laufen... :/

Zum stündlichen Syncen der Configs: Ich würde trotzdem den gleichen Sync-Zyklus nehmen, einfach weil dadurch wahrscheinlicher wird, dass man nichts vergisst.

Ja das war auch etwas mein Grundgedanke dazu, weshalb ich es erst mal stündlich gemacht habe. Der entstehende Traffic ist bei der Anzahl der VMs ja auch überschaubar. ^^

Für die Datenbanken würde ich wirklich dringend empfehlen die native Replikation der Datenbanken zu nutzen, um das Zeitfenster eines Datenverlusts zu begrenzen und die Konsistenz der Datenbank zu gewährleisten.

Danke für den Hinweis, wird meines Wissens nach auch gemacht. Die Datenbankserver werden von einem anderen Kollegen betreut. Ich werde mich nochmal schlau machen.

Irgendwie seltsame Kombi, du hast keinen lokalen PVE Storage an Standort A, weil du Hardware limitiert bist, möchtest aber PVE A, PBS A, TrueNAS A und PVE B, PBS B?

PVE-A und B Hardware sowie TrueNAS-A und B sind bereits vorhanden (Bestehendes ESX-Cluster). Ich habe jetzt (alte) Hardware organisieren können, um dann zumindest schonmal an Standort A ein 2-Node-PVE-Cluster bauen zu können um VMs migrieren zu können.

Zwei der vier bestehenden ESX-Hosts (einer A und einer B) müssen auch vorerst weiterhin unter ESX laufen, da wir hier noch CISCO-Appliances virtualisiert betreiben müssen. Hier gibt es leider noch keine Support von Cisco, was die Virtualisierung unter PVE angeht... Ich weiß technisch kein Problem, aber hier soll der bestehende Support erhalten bleiben.

Einer der Hosts vom alten ESX-Custer Standort A muss dann zu B. Hier ist dann auch noch ein Server aus dem bestehenden ESX-Cluster übrig. Mit diesen beiden Servern muss ich dann das neue PVE-Cluster auf Seite B bauen.

Die vorhandene TrueNAS an beiden Standorten haben noch recht viel Kapazität. Daher möchte ich, wie es auch schon jemand hier erwähnt hat, PBS als VM auf der TrueNAS laufen lassen. Somit benötige ich hier keine neue Hardware.

Übelst der Cluster-Fuck mit dem Hardware hin und her Geschiebe...

Du solltest nur absichern, dass die VMs nicht auf ClusterB gestartet werden.

Hier würde es ja Sinn machen es, wie von @Bu66as vorgeschlagen, umzusetzen:

Ich würd die Configs einfach in ein normales Verzeichnis auf B kippen und ein kleines Skript haben, das sie im Ernstfall nach /etc/pve/nodes/<node>/qemu-server/ schiebt.

Hi, das Konzept ist gar nicht schlecht

Danke für das positive Feedback, hatte jetzt zwischenzeitlich Angst, dass das totaler Müll ist, was ich mir überlegt habe.

Es ist halt echt ein Problem, wenn man solche komplexen Umgebungen umziehen muss, ohne dabei auf Dienstleister oder wenigstens neue Hardware zurückgreifen zu können... aber hey auch wenn es dann mal kracht, hat man sich wenigstens die 20 Mark gespart...

 

[IsThisThingOn]

PVE-A und B Hardware sowie TrueNAS-A und B sind bereits vorhanden (Bestehendes ESX-Cluster).

TrueNAS ist noch nicht mal bare metal, sondern ein ESC Cluster? Wird ja immer wilder

Danke für das positive Feedback, hatte jetzt zwischenzeitlich Angst, dass das totaler Müll ist, was ich mir überlegt habe.

Müll vielleicht nicht, aber übelst komplex und viele Layer.

Dazu noch möglichst billig, weil geiziger Auftraggeber. Bisschen fake HA drüber gestreut, was das ganze aber nur noch schlimmer macht. Klingt nach meinem jungen ich damals habe ich es auch so gemacht, heute könnte ich nicht mehr beruhigt schlafen.

Wobei ich die "alles muss HA sein, CO2 Feuerlöscher, Klima im Serverraum und plus +200k€ muss ein KMU halt mal eben locker machen können" Fraktion genausowenig mag.

 

[rothkraut]

Klingt nach meinem jungen ich damals habe ich es auch so gemacht

Ich bin noch jung, da erlaube ich mir das mal

Danke fürs Feedback!

 

[ThoSo]

Das Konstrukt, wie ich es oben beschieben habe, besteht momentan in unserer VMWare-Umgebung. Diese habe ich nicht geplant und auch nicht aufgesetzt. War alles vor meiner Zeit

@IsThisThingOn … ist ja nicht auf seinem jugentlichen Mist entstanden. Eine Erbengeschichte wie sie im Buch steht.

@rothkraut … sparen ist gut, aber nicht um jeden Preis. Aber dem Wassserkopf ist das meistens schwer beizubringen. Da sollte man durchaus hart dran bleiben, sonst kommt so ein Controller auf die Idee das ganze in die Cloud zu schieben, mit dem Argument, das jeder da ran kommt, selbst vom Abbort aus…

Wenn der Standort A so umwelttechnisch gefährdet ist, wäre auch zu überlegen, ob es möglich ist einen Grossteil zum Standort B zu migrieren.

 

[Bu66as]

Was mir im Thread noch fehlt, ist das Netz. Wenn du die Disks 1:1 replizierst, kommt die VM in B mit ihrer Config aus A hoch, also gleiche IP, gleiche MAC. Entweder ziehst du die betroffenen VLANs nach B durch, oder du brauchst pro VM eine zweite Netzkonfiguration plus DNS-Umschwenk. Wie ist das in der bestehenden VMware-Umgebung heute gelöst? Wenn dort schon gestreckte VLANs liegen, hast du das Problem gar nicht und der Rest wird deutlich einfacher.

Live-Restore ist ein guter Hebel, aber nur wenn der PBS-Datastore in B auf flottem Storage sitzt. Die VM läuft während des Restores ja komplett gegen den PBS, auf lahmen HDDs ist das dann eher Demo als Produktivbetrieb.

Und schreib dir das Failover als Runbook auf und spiel es einmal durch, inkl. Reihenfolge und wer die Umschaltung freigibt. Bei ~20 VMs und einer Stunde RTO verbringst du sonst 40 Minuten mit Nachdenken statt mit Starten. Falls ihr für die Konzeptphase Unterstützung braucht, wir (B1 Systems) machen sowas beruflich: https://www.b1-systems.de

 

[rothkraut]

Was mir im Thread noch fehlt, ist das Netz. Wenn du die Disks 1:1 replizierst, kommt die VM in B mit ihrer Config aus A hoch, also gleiche IP, gleiche MAC. Entweder ziehst du die betroffenen VLANs nach B durch, oder du brauchst pro VM eine zweite Netzkonfiguration plus DNS-Umschwenk. Wie ist das in der bestehenden VMware-Umgebung heute gelöst? Wenn dort schon gestreckte VLANs liegen, hast du das Problem gar nicht und der Rest wird deutlich einfacher.

Wir arbeiten bei einem Großteil unserer Server mit DHCP. Am Standort B ist für alle zu migrierenden VMs bereits ein DHCP -Eintrag für das entsprechende Netz vorhanden. Sollte ein neuer Server dazu kommen, muss dies eben gepflegt werden. Aber das wurde bisher auch so gelebt.
Die VLAN-IDs sollten auch übereinstimmen. Das ist aber ein guter Punkt, das müsste ich nochmal gegenprüfen. Danke für dein Hinweis!
Ggf. müsste man hier nochmal manuell die Netze umstellen, oder ein kleines Skript bauen.