tbz-repos/m346
1
0
Fork 0
mirror of https://gitlab.com/ser-cal/m346.git synced 2024-11-26 03:11:57 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

KN06 Challenge C) ergänzt

Browse Source
This commit is contained in:
Marcello Calisto 2023-10-14 19:58:49 +02:00
parent ef99bf4573
commit 1ca823ebb3
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
KN06/KN06.md
View File

@ -102,11 +102,11 @@ Beachten Sie ausserdem die [llgemeinen Informationen zu den Abgaben](../Abgaben.
:bookmark: Für dieses Lab verwenden Sie in der **AWS Academy** das **Learner Lab**.
In diesem Challenge werden Sie eine **Auto Scaling Group** erstellen und später beim Erstellen von neuen EC2-Instanzen nutzen.
Der **Load Balancer** aus dem letzten Challenge und die **Auto Scaling Group** können unabhängig voneinder eingesetzt werden. Gemeinsam Kombiniert sind diese beiden Dienste allerdings unschlagbar und in einer **High Availability Umgebung** nicht wegzudenken.
Der **Load Balancer** aus dem letzten Challenge und die **Auto Scaling Group** können unabhängig voneinder eingesetzt werden. Gemeinsam sind diese beiden Dienste allerdings unschlagbar und in einer **dynamischen High Availability Umgebung** nicht wegzudenken.
Momentan aber schauen wir diese beiden Dienste losgelöst voneinander an. Im folgenden Auftrag geht es deshalb nur um die Vorzüge des **Auto Scalers**. Er stellt sicher, dass meine Ressourcen **immer** dem gewünschten Zustand (Desired state) entsprechen. Im folgenden Challenge setzen wir diese Dienst so auf, dass **immer mindestens zwei** EC2-Instanzen laufen. Falls eine Instanz wegfällt (z.B. versehntlich terminiert, SW-Issue oder technischer Defekt) wird automatisch eine neue Instanz hochgefahren.
Kombiniert man den **Auto Scaler** mit den **Load Balancer**, erhält der dahinterliegende Service eine um einiges höhere Verfügbarkeit. Beim Ausfall einer Site (z.B. Datacenter Stromausfall) wird der Traffic automatisch auf die andere Site umgeleitet. Die "verlorenen" Instanzen werden automatisch in der verfügbaren Availability Zone hochgefahren. Zusätzlich kann man den **Auto Scaler** auch noch mit Metrics ergänzen. Z.B. Falls die CPU-Auslastung einen Grenzwert überschreitet, sollen dynamisch weitere Instanz hochgefahren werden etc... Das ganze funktioniert natürlich auch umgekehrt. Falls die CPU-Auslastung unter den Grenzwert fällt, wird die zusätzliche Instanz automatisch wieder terminiert. Man spricht in diesem Fall von **Elasticity**. Im Gegensatz zum Begriff **Scalability** (z.B. Einbau einer weiteren SSD) kann die Plattform **on-demand** Ressourcen hinzufügen oder entfernen.
Kombiniert man diesen Dienst mit dem **Loadbalancer** aus dem letzten Challenge, kann man sicherstellen, dass der Service eine um einiges höhere Verfügbarkeit erhält. Beim Ausfall einer Site (z.B. Datacenter Stromausfall) wird der Traffic automatisch auf die andere Site umgeleitet. Zusätzlich kann man diesen Dienst auch noch ergänzten mit Metrics. Z.B. Falls die CPU-Auslastung einen Grenzwert überschreitet, soll dynamisch eine weitere Instanz hochgefahren werden. Das ganze funktioniert auch umgekehrt. Falls die CPU-Auslastung unter den Grenzwert fällt, wird die zusätzliche Instanz automatisch terminiert. Man spricht in diesem Fall von **Elasticity**. Im Gegensatz zum Begriff **Scalability** (z.B. Einbau einer weiteren SSD) kann die Plattform "on-demand" Ressourcen hinzufügen oder entfernen.
Momentan aber schauen wir diese beiden Dienste noch losgelöst voneinander an. Im folgenden Auftrag geht es deshalb nur um die Vorzüge des **Auto Scalers**. Er stellt sicher, dass meine Ressourcen **immer** dem gewünschten Zustand (Desired state) entsprechen. Im folgenden Challenge setzen wir diese Dienst so auf, dass **immer mindestens zwei** EC2-Instanzen laufen. Falls eine Instanz wegfällt (z.B. versehntlich terminiert, SW-Issue oder technischer Defekt) wird automatisch eine neue Instanz hochgefahren.
#### Anleitung: