tbz-repos/m346
1
0
Fork 0
mirror of https://gitlab.com/ser-cal/m346.git synced 2024-11-25 14:21:57 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
2de0a6babb
m346/KN06/KN06.md
Marcello caee9e5806 Update
2024-03-26 09:29:28 +00:00

839 lines
57 KiB
Markdown
Raw Blame History

[00a]: ./x_res/00_Loadbalancer_titel_1000.png
[01a]: ./x_res/01_Loadbalancer_600.png
[01b]: ./x_res/01_Loadbalancer_ORIG.png
[01a2]: ./x_res/01_Loadbalancer2_600.png
[01b2]: ./x_res/01_Loadbalancer2_ORIG.png
[01a3]: ./x_res/01_Loadbalancer3_600.png
[01b3]: ./x_res/01_Loadbalancer3_ORIG.png
[01a4]: ./x_res/01_Loadbalancer4_600.png
[01b4]: ./x_res/01_Loadbalancer4_ORIG.png
[97a]: ./x_res/97_500_Error_600.png
[98a]: ./x_res/98_500_Error_600.png
[002a]: ./x_res/002_Lab11_Acad_Beweis_600.png
[002b]: ./x_res/002_Lab11_Acad_Beweis_ORIG.png
[001a]: ./x_res/001_Lab11_Acad_Beweis_600.png
[001b]: ./x_res/001_Lab11_Acad_Beweis_ORIG.png
[003a]: ./x_res/003_Lab11_Webzugriff1_600.png
[003b]: ./x_res/003_Lab11_Webzugriff1_ORIG.png
[004a]: ./x_res/004_Lab11_Webzugriff2_600.png
[004b]: ./x_res/004_Lab11_Webzugriff2_ORIG.png
[11a]: ./x_res/11_launch_options_600.png
[11b]: ./x_res/11_launch_options_ORIG.png
[12a]: ./x_res/12_load_balancing_600.png
[12b]: ./x_res/12_load_balancing_ORIG.png
[14a]: ./x_res/14_activity_history_1000.png
[14b]: ./x_res/14_activity_history_ORIG.png
[15a]: ./x_res/15_Instanz1_600.png
[15b]: ./x_res/15_Instanz1_ORIG.png
[16a]: ./x_res/16_Instanz2_600.png
[16b]: ./x_res/16_Instanz2_ORIG.png
[17a]: ./x_res/17_Instanz1_600.png
[17b]: ./x_res/17_Instanz1_ORIG.png
[18a]: ./x_res/18_Instanz2_600.png
[18b]: ./x_res/18_Instanz2_ORIG.png
[19a]: ./x_res/19_AutoScaler_1000.png
[19b]: ./x_res/19_AutoScaler_ORIG.png
[23a]: ./x_res/23_AutoScaler_400.png
[23b]: ./x_res/23_AutoScaler_ORIG.png
[24a]: ./x_res/24_AutoScaler_400.png
[24b]: ./x_res/24_AutoScaler_ORIG.png
[25a]: ./x_res/25_AutoScaler_400.png
[25b]: ./x_res/25_AutoScaler_ORIG.png
[26a]: ./x_res/26_AutoScaler_600.png
[26b]: ./x_res/26_AutoScaler_ORIG.png
[27a]: ./x_res/27_AutoScaler_600.png
[27b]: ./x_res/27_AutoScaler_ORIG.png
[28a]: ./x_res/28_Design_1000.png
[28b]: ./x_res/28_Design_ORIG.png
[29a]: ./x_res/29_Connection_400.png
[29b]: ./x_res/29_Connection_ORIG.png
[30a]: ./x_res/30_Connection_400.png
[30b]: ./x_res/30_Connection_ORIG.png
[31a]: ./x_res/31_Connection_400.png
[31b]: ./x_res/31_Connection_ORIG.png
[32a]: ./x_res/32_Connection_600.png
[32b]: ./x_res/32_Connection_ORIG.png
[33a]: ./x_res/33_Connection_600.png
[33b]: ./x_res/33_Connection_ORIG.png
[34a]: ./x_res/34_Connection_600.png
[34b]: ./x_res/34_Connection_ORIG.png
[35a]: ./x_res/35_Connection_600.png
[35b]: ./x_res/35_Connection_ORIG.png
[37a]: ./x_res/37_Target-Group_600.png
[41a]: ./x_res/41_Target-Group_600.png
[41b]: ./x_res/41_Target-Group_ORIG.png
[42a]: ./x_res/42_Target-Group_600.png
[42b]: ./x_res/42_Target-Group_ORIG.png
[43a]: ./x_res/43_Target-Group_1000.png
[43b]: ./x_res/43_Target-Group_ORIG.png
[57a]: ./x_res/57_Target-Group_600.png
[57b]: ./x_res/57_Target-Group_ORIG.png
[58a]: ./x_res/58_Target-Group_600.png
[58b]: ./x_res/58_Target-Group_ORIG.png
[59a]: ./x_res/59_LB_Kontrolle1_400.png
[59b]: ./x_res/59_LB_Kontrolle1_ORIG.png
[60a]: ./x_res/60_LB_Kontrolle2_400.png
[60b]: ./x_res/60_LB_Kontrolle2_ORIG.png
[61a]: ./x_res/61_LB_Kontrolle3_400.png
[61b]: ./x_res/61_LB_Kontrolle3_ORIG.png
[62a]: ./x_res/62_LB_Kontrolle4_400.png
[62b]: ./x_res/62_LB_Kontrolle4_ORIG.png
[63a]: ./x_res/63_LB_Kontrolle5_400.png
[63b]: ./x_res/63_LB_Kontrolle5_ORIG.png
[64a]: ./x_res/64_LB_Kontrolle6_400.png
[64b]: ./x_res/64_LB_Kontrolle6_ORIG.png
[65b]: ./x_res/65_AutoScalingGroup_deleten_ORIG.png
[66b]: ./x_res/66_Instanzen_deleten_ORIG.png
[67b]: ./x_res/67_LoadBalancer_deleten_ORIG.png
[68b]: ./x_res/68_TargetGroups_deleten_ORIG.png
[69b]: ./x_res/69_Launch-Template_deleten_ORIG.png
[70a]: ./x_res/70_HA_Elastic_Design_400.png
[70b]: ./x_res/70_HA_Elastic_Design_ORIG.png
[71a]: ./x_res/71_HA_Elastic_Design_400.png
[71b]: ./x_res/71_HA_Elastic_Design_ORIG.png
[72a]: ./x_res/72_HA_Elastic_Design_400.png
[72b]: ./x_res/72_HA_Elastic_Design_ORIG.png
[74a]: ./x_res/74_Instanz1_600.png
[75a]: ./x_res/75_Instanz2_600.png
[76a]: ./x_res/76_Dyn_scal_policy_1000.png
[76b]: ./x_res/76_Dyn_scal_policy_ORIG.png
[77a]: ./x_res/77_Dyn_scal_policy_600.png
[77b]: ./x_res/77_Dyn_scal_policy_ORIG.png
[80a]: ./x_res/80_Alarm_400.png
[80b]: ./x_res/80_Alarm_ORIG.png
[81a]: ./x_res/81_Alarm_400.png
[81b]: ./x_res/81_Alarm_ORIG.png
[82a]: ./x_res/82_Alarm_400.png
[82b]: ./x_res/82_Alarm_ORIG.png
[83a]: ./x_res/83_1Instanz_400.png
[83b]: ./x_res/83_1Instanz_ORIG.png
[84a]: ./x_res/84_2Instanz_400.png
[84b]: ./x_res/84_2Instanz_ORIG.png
[85a]: ./x_res/85_3Instanz_400.png
[85b]: ./x_res/85_3Instanz_ORIG.png
[86a]: ./x_res/86_Alarm_log_400.png
[86b]: ./x_res/86_Alarm_log_1000.png
[86c]: ./x_res/86_Alarm_log_ORIG.png
[87a]: ./x_res/87_Alarm_reverse_400.png
[87b]: ./x_res/87_Alarm_reverse_ORIG.png
[88a]: ./x_res/88_Alarm_reverse_400.png
[88b]: ./x_res/88_Alarm_reverse_ORIG.png
[89a]: ./x_res/89_Alarm_reverse_400.png
[89b]: ./x_res/89_Alarm_reverse_ORIG.png
# KN06 Inhaltsverzeichnis
[TOC]
<br>
## Challenges
### A) Theorie: Scaling up vs. out (vertical vs. horizontal) / Auto Scaling, Load Balancer und High Availability
#### Ausgangslage:
:bookmark: Wissen, dass sie für die bevorstehenden Challenges gut nutzen können. In diesem ersten, separaten Auftrag geht es darum, sich das nötige Faktenwissen anzueignen für die Hands-on Übungen später :book:
- [**Auf zum Challenge A**](Recherche.md)
### B) Lab: Zwei Webserver erstellen und Last mittels Load Balancer gleichmässig verteilen.
#### Ausgangslage:
:bookmark: Für dieses Lab verwenden Sie in der **AWS Academy** den Kurs **AWS Academy Introduction to Cloud: Semester 1**.
In dieser Laborumgebung ist der Zugriff nur auf die AWS-Services beschränkt, die zum Ausführen des Labs erforderlich sind. Wenn Sie versuchen, auf andere Dienste zuzugreifen oder Aktionen auszuführen, die über die in diesem Lab beschriebenen hinausgehen, können Fehler auftreten.
#### Anleitung:
Für den ersten Challenge der Kompetenz **KN06** wechseln Sie ins elfte Modul **Module 11 - Load Balancers and Caching**. Hier finden Sie die praktische Übung **Lab 11 - Load Balancing**. Diese ist Schritt für Schritt geleitet.
:warning: **Hinweis:** <br>
>Die folgenden Challenges bauen auf diesem ersten Lab auf. Versuchen Sie deshalb die Schritte so zu dokumentieren, dass Sie darauf zurückgreifen können.
##### Modul 11: Lab 11 - Load Balancers and Caching
Das Lab dauert ca. 30'. Führen Sie alle Schritte konzentriert und der Reihe nach durch. Für den Leistungsnachweis zeigen Sie neben der Doku auch noch gleich live, dass der Loadbalancer funktioniert (Browser mehrmals hintereinander reloaden).
##### Netzwerkschema:
1. Load Balancer mit **zwei** Instanzen: :mag_right: [Originalbild][01b] _(oder unten auf das Bild klicken)_<br>
1 Load Balancer verteilt requests auf zwei Instanzen |
:---:|
[![1. Launch template][00a]][01b]
#### Ziel der Übung
:bell: Sie sind in der Lage, folgende Tasks durchzuführen:
- Application Load Balancer (inkl. Target Group) aufsetzen
- Application Load Balancer testen (mit zwei Webservern in verschiedenen Availability Zones)
##### Leistungsnachweis
- [ ] Ablauf nachvollziehbar im eigenen Repository dokumentiert (für nächste Challenges hilfreich).
- [ ] Live-Demo beim Coach (Mit mehrfachem "Reload" der Webseite beweisen, dass beide Instanzen angesprochen werden)
- [ ] Fachgespräch mit Coach.
Beachten Sie ausserdem die [llgemeinen Informationen zu den Abgaben](../Abgaben.md).
##### Beispiel-Abgabe (Doku):
- Screenshots :
2. LoadBalancer: :mag_right: [Originalbild][001b] _(oder unten auf erstes Bild klicken)_
3. Target Group: :mag_right: [Originalbild][002b] _(oder unten auf zweites Bild klicken)_
2 LoadBalancer | 3 Target Group
:---:|:---:
[![1. Loadbalancer][001a]][001b] | [![2. TargetGroup][002a]][002b]
4. Webserver **1**: :mag_right: [Originalbild][003b] _(oder unten auf erstes Bild klicken)_
5. Webserver **2**: :mag_right: [Originalbild][004b] _(oder unten auf zweites Bild klicken)_
4 Webswerver 1 | 5 Webserver 2
:---:|:---:
[![3. Webserver 1][003a]][003b] | [![4. Webserver 2][004a]][004b]
<br>
#### Wissenswertes vor dem nächsten Challenge:<br>
:bulb: Für eine **perfekte High Availability-Plattform** würde dieser Load Balander **noch nicht alle Bedingungen** erfüllen. Das **Beispiel unten** zeigt, dass die Instanzen in **unterschiedlichen** Availability-Zones sind. Damit ist zwar schon mal **ein wichtiges Kriterium** erfüllt. Was würde jetzt aber passieren, wenn plötzlich gleichzeitig **10'000x mehr** Requests reinkämen und die Applikation unter dieser Last zusammenbricht?
Genau. Um diesen - oder ähnliche - **Use-cases** in den Griff zu bekommen, benötigt der **Load Balancer** Unterstützung von seinem besten Freund, dem **Auto Scaler** :two_men_holding_hands:. Was dieser unternimmt und wie er es macht, erfahren Sie gleich, nachdem wir noch abschliessend zu diesem Challenge einen möglichen Use-Case eines Service-Ausfalls (DoS-Attacke) angeschaut haben. Sie werden dann im nächsten Challenge auch gleich selber einen **Auto Scaler** aufsetzen und diesen dann im übernächsten Challenge mit dem **Load Balancer** zum unschlagbaren Team **High Availabiliy** vereinen. :wrench:
##### Use Case: Denial of Service
Denial of Service (DoS) bezeichnet eine Cyberangriffstechnik, bei der ein Angreifer versucht, ein Computersystem oder eine Website durch Überlastung mit Traffic oder Anfragen unzugänglich zu machen. Das Ziel ist, legitimen Nutzern den Zugriff zu verweigern, indem die Ressourcen des Zielsystems erschöpft werden. DoS-Angriffe oder auch gewöhnliche technische Störungen können erhebliche Schäden verursachen und werden durch verschiedene **proaktive** Sicherheitsmaßnahmen wie Firewalls, Intrusion Detection Systems bekämpft und zusätzlich mit Monitoring-Software überwacht. Der Load Balancer hat aber eine andere Aufgabe und ist nicht darauf ausgelegt, solche Problem zu lösen. Und genau da kommt der **Auto Scaler** ins Spiel. Der **Auto Scaler** gehört zu den **reaktiven** Sicherheitsmassnahmen. Er wird durch einen **Trigger** aktiviert. Das ist entweder ein **Status Check** der einen Alarm auslöst, oder eine **CloudWatch-Metrics**, die eine Grenzwertüberschreitung meldet. Er kommt also erst zum Zug, wenn irgendetwas **nicht** stimmt. Die vier Bilder unten zeigen genau ein solches Szenario auf.
1. **Normale Nutzung** Load Balancer mit **zwei** Instanzen: :mag_right: [Originalbild][01b] _(oder unten auf erstes Bild klicken)_
2. **Denial of Service** (Überlastung des Servers): :mag_right: [Originalbild][01b4] _(oder unten auf zweites Bild klicken)_
1 Normale Nutzung | 2 Denial of Service (wegen Überlastung)
:---:|:---:
[![1. Load Balancer ok][01a]][01b] | [![2. Denial of Service][01a4]][01b4]
3. **Error Code 500**. Der Server ist überlastet.
4. User können nicht mehr auf die Applikation zugreifen.
4 Rückmeldung des Servers (Error Code 500) | 4 Kein Zugiff auf die Applikation mehr möglich
:---:|:---:
[![1. Load Balancer ok][98a]][98a] | [![2. Denial of Service][97a]][97a]
<br>
### C) Lab: Auto Scaling Group erstellen und anwenden
#### Ausgangslage:
: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 sind diese beiden Dienste allerdings unschlagbar und in einer **dynamischen High Availability Umgebung** nicht wegzudenken.
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.
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 diesen 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.
**Aufgaben** des **Auto Scalers**:
- Launchen und terminieren von EC2-Instanzen **dynamisch**.
- Horizontal skalieren (Scale out).
- Unterstützt **Elasticity** und **Scalability**.
- Reagiert auf **EC2 Status Checks** und **CloudWatch-Metrics**.
- Skaliert **On-demand** (Performance) und/oder gemäss Planung (Falls man z.B. weiss, dass am Sonntagabend ein Backup-Job viel Ressourcen braucht). <br>
##### Netzwerkschema:
1. Auto Scaling Group reagiert dynamisch auf Status Checks und CloudWatch Metrics: :mag_right: [Originalbild][19b] _(oder unten auf das Bild klicken)_<br>
1 Auto Scaling Group überwacht Status Checks und CloudWatch Metrics |
:---:|
[![1. Launch template][19a]][19b]
Gleichzeitig erkennt man hier aber sofort auch die **Grenzen** des **Auto Scalers**. Er ist zwar in der Lage, aufgrund von **status checks** und **CloudWatch-Metrics** den Gesundheitszustand der Instanzen zu checken und entsprechend zu reagieren (z.B. beim Ausfall einer EC2-Instanz eine Ersatz-Instanz hochzufahren), aber er ist alleine **nicht** in der Lage, die Last gleichmässig zu verteilen und dabei auch die neuen Instanzen einzubinden. Und genau hier kommt ihm sein bester Freund, der **Load Balancer**, zur Hilfe :two_men_holding_hands:. Der **Auto Scaler** sorgt also quasi **im Hintergrund** dafür, dass **immer** ausreichend (nicht zuviel, aber auch nicht zuwenig) Ressourcen vorhanden sind, während der **Load Balancer** vorne praktisch als **Türsteher** dafür sorgt, dass diese Ressourcen **gleichmässig** genutzt werden. Weil die Ressourcen nun dynamisch angepasst werden und über zwei oder mehrere **Availability Zones** verteilt sind, sind sämtliche Anforderungen an eine **High Availability-Architektur** erfüllt.
#### Anleitung:
Als erstes werden Sie ein Launch Template erstellen.
##### Schritt 1: Launch template erstellen
Setzen Sie als erstes ein Launch-Template auf. Wählen Sie dazu links in der **Navigation Bar** unter **`Instances`** das Feld **`Launch Templates`** und dann den Buttom **`Create Launch template`**. Danach konfigurieren Sie das LaunchTemplate mit folgenden Parametern:
- Launch template Name: **KN06_XXX_LaunchTemplate** (XXX = Gemäss Namenskonvention)
- Application and OS Image: `Amazon Linux 2023 AMI (AWS)`
- Instance type: `t2.micro`
- Key-pair name: `Don't include in launch template`
- Network settings:
- Subnet `Don't include in launch template`
- Security-Groups `M346-XXX-Web-Access` auswählen
- Advanced Details (unter User data):
- [**diesen Code**](https://gitlab.com/ser-cal/m346-scripts/-/blob/main/KN06/user-data-az_c.md?ref_type=heads) eingeben (Copy/Paste). Bitte darauf achten, dass **nur** der Code eingegeben wird. Die Erklärungen helfen Ihnen lediglich, den Code zu verstehen. Später, beim Leistungsnachweis, wird von Ihnen erwartet, dass Sie diesen bis ins Detail erklären können.
![Schema](./x_res/10_User-data_1000.png) |
- Buttom **Create launch template** anklicken: (Template wird erstellt)
- Buttom **View launch template** anklicken: (Kontrolle)
##### Schritt 2: Auto Scaling Group erstellen
Wählen Sie wieder links in der **Navigation Bar** unter **`Auto Scaling`** das Unterverzeichnis **`Auto Scaling Groups`** aus. Dann klicken Sie auf den orangen Buttom **`Create Auto Scaling group`**. Danach erscheint eine neue Seite mit dem Titel **Choose launch template**, welches Sie wie folgt ausfüllen:<br>
- Name:
- Auto Scaling group name: `KN06_XXX_AutoScalingGroup`
- Launch Template: `KN06_XXX_LaunchTemplate`<br>
...sonst nichts ändern und mit **Next** bestätigen.
Es erscheint eine neue Seite mit dem Titel **Choose instance launch options**, welches Sie wie folgt ausfüllen:
1. Launch template (VPC und beide Public Subnets): :mag_right: [Originalbild][11b] _(oder unten auf erstes Bild klicken)_
2. Launch options (No LB und No VPC Lattice Service): :mag_right: [Originalbild][12b] _(oder unten auf zweites Bild klicken)_ <br>
1 Launch template: Korrekte VPC und beide Public Subnets auswählen | 2 Launch options: No load balancer
:---:|:---:
[![1. Launch template][11a]][11b] | [![2. Launch options][12a]][12b]
3. 1 Nun wird noch die Group size definiert. Wieviele Instanzen im gewünschten-, maximalen und minimalen Zustand laufen sollen.<br>
2 Die Scaling policy (Dynamische Anpassung on demand) wird in diesem Challenge **nicht** genutzt. Deshalb auf **None** lassen.
| Group Size und Scaling policies | Entsprechende Werte zuweisen |
|:--------|:------|
| - **Desired capacity:** Gewünschte Anzahl Instanzen - **2** <br> - **Minimum capacity:** (Intervention, wenn **weniger als 2** Instanzen) <br> - **Maximum capacity** (Intervention, wenn **mehr als 2** Instanzen) <br><br> | ![Schema](./x_res/13_Configure_group_size_600.png) |
4. Mit der Bestätigung `Create Auto Scaling Group` die **Auto Scaling Group** erstellen.
##### Schritt 3: Check
1. Activity history anschauen: Hier sieht man, dass die **Auto Scaling Group** bereits aktiv eingegriffen hat. Es wurden **zwei** EC2-Instanzen **gemäss den ganz am Anfang definierten Informationen im Launch template** gelauncht (Increasing the capacity from 0 to 2).
![![1. EC2 Instanz][14a]][14b]
:warning: **Hinweis:** <br>
>Sinnesgemäss sollten die beiden Instanzen in **unterschiedlichen** Availability Zones liegen. Überprüfen wir kurz, ob das so ist:
2. 1.) Erste EC2 Instanz (PublicIP: 18.232.128.55) : :mag_right: [Originalbild][15b] _(oder unten auf erstes Bild klicken)_<br>
2.) Zweite EC2 Instanz (PublicIP: 34.229.82.210): :mag_right: [Originalbild][16b] _(oder unten auf zweites Bild klicken)_
Erste EC2 Instanz (PublicIP: 18.232.128.55) | Zweite EC2 Instanz (PublicIP: 34.229.82.210)
:---:|:---:
[![1. EC2 Instanz][15a]][15b] | [![2. EC2 Instanz][16a]][16b]
:heavy_check_mark: **Beweis:** <br>
Beide Instanzen befinden sich in **unterschiedlichen** Availability Zones:
3. 1.) Zugriff auf erste EC2 Instanz (PublicIP: 18.232.128.55) - **us-east-1b** : :mag_right: [Originalbild][17b] _(oder unten auf erstes Bild klicken)_ <br>
2.) Zugriff auf zweite EC2 Instanz (PublicIP: 34.229.82.210) - **us-east-1a**: :mag_right: [Originalbild][18b] _(oder unten auf zweites Bild klicken)_
Erste EC2 Instanz (AZ: us-east-1b) | Zweite EC2 Instanz (AZ: us-east-1a)
:---:|:---:
[![1. EC2 Instanz][17a]][17b] | [![2. EC2 Instanz][18a]][18b]
#### Ziel der Übung
:bell: Verständnisaufbau für Merkmale, die eine **High availability**-Architektur auszeichnen. Sie wissen, wie eine **Auto Scaling Group** aufgesetzt wird und was sie genau macht. Sie kennen den Unterschied zwischen **Scaling up** (Vertikale Skalierung) und **Scaling out** (Horizontale Skalierung) und verstehen, wie die Services **Auto Scaling Group** und **Load balancer** arbeiten und wie sie sich gegenseitig ergänzen.
##### Leistungsnachweis
- [ ] Das **Launch template** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] Die **Auto Scaling Group** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] **Zwei** Webserver-Instanzen in **unterschiedlichen Availability Zones** wurden gemäss **Launch template** erstellt.
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
- [ ] Fachgespräch mit Coach.
- [ ] Sie kennen die Details des verwendeten User-data scripts
- [ ] Sie kennen den Unterschied zwischen Auto-scaler und Load Balancer.
- [ ] Sie verstehen, was **High availability** bedeutet und können diesen Begriff differenziert anhand eines Beispiels erklären.
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
<br>
### D) Lab: Load Balancer / High Availability
#### Ausgangslage:
:bookmark: Für dieses Lab verwenden Sie in der **AWS Academy** das **Learner Lab**. Es baut auf dem letzten Challenge **C)** auf. Das heisst: Die **Auto Scaling Group** existiert bereits und hat **zwei Instanzen** in **zwei verschiedenen Availability Zones** erstellt. Falls Sie in der Zwischenzeit das Lab aus- und wieder eingeschaltet haben sollten, ist das kein Problem. Die **Auto Scaling Group** ist **persistent** und startet die Instanzen wieder automatisch, wenn Sie das Lab starten. :pushpin: Das heisst aber auch, dass Sie diese und alle dazugehörigen Ressourcen **am Ende dieses Challenges** unbedingt **löschen** sollten.
Nun. Im **ersten Challenge** von **KN06** haben Sie einen **Load Balancer** erstellt. Im **zweiten Challenge** dann haben Sie im **Learner Lab** eine **Auto Scaling Group** erstellt. Sie haben auch erfahren, wie diese beiden Dienste funktionieren, dass sie beste Freunde sind und sich **perfekt** ergänzen. Nun gilt es also, im **Learner Lab** noch den **Load Balancer** aufzusetzen und diesen mit dem bereits funktionierenden **Auto Scaler** zu vereinen. Wenn alles funktioniert, haben Sie am Ende dieses Challenges die reinste Form einer **hochverfügbaren Plattform** geschaffen. Dies, weil auch der vermeintlich einzige **Single Point of Failure**, der **ELB** (Elastic Load Balancer), AWS-Intern mehrfach über verschiedene IP-Adressen abgesichert wird.
#### Anleitung:
Dieser zweitletzte **KN06 Challenge** setzt einen funktionstüchtigen **Auto Scaler** aus dem letzten Challenge voraus (zwei EC2-Instanzen in unterschiedlichen AZs sollten ebenfall schon laufen).
:warning: **Hinweis:** <br>
>Die Umgebung läuft im Moment also wie folgt:
>- Die **Auto Scaling Group** ist **im Hintergrund aktiv** und sorgt dafür, dass **immer mindestens zwei Instanzen** laufen.
>- Es gibt **noch keinen Loadbalancer**.
##### Use Case: Auto Scaler funktioniert, aber ohne Load Balancer
Dieses Beispiel mit einer Reihenfolge von **5 Bildern** verdeutlicht, weshalb es **nicht viel bringt**, wenn man nur den **Auto Scaler** aufsetzt, **ohne** ihn mit dem **Load Balancer** zu ergänzen.
**1. Bild:**
Wenn nun also User auf die Applikation zugreifen, können sie das theoretisch **nur** mit der IP-Adresse oder dem DNS.<br>
**2. Bild:** Das bedeutet, dass die Last **nicht** gleichmässig verteilt wird. Hier fällt genau die EC2-Instanz aus, auf welche alle User zugreifen.<br>
**3. Bild:** Der Auto Scaler erhält diese Info und ist sofort in der Lage, eine neue Instanz zu starten. Aber so, wie die Umgebung aktuell aufgesetzt ist, können die User nicht darauf zugreifen.<br>
**4. Bild:** Der Auto Scaler funktioniert **as designed**. Bei noch mehr Anfragen wird er aufgrund des überschrittenen Grenzwertes weitere Instanzen hochfahren.<br>
**5. Bild:** Der Prozess wird fortgesetzt. On-demand werden Instanzen hoch- oder runtergefahren. Obwohl der Load mit dieser Scale-out-Strategie abgedeckt wäre, können die User immer noch nicht auf den Dienst zugreifen.
1. Zugriff auf App via IP oder DNS: :mag_right: [Originalbild][23b] _(oder unten auf erstes Bild klicken)_
2. Instanz defekt: :mag_right: [Originalbild][24b] _(oder unten auf zweites Bild klicken)_
3. Auto Scaler reagiert und startet neue Instanz: :mag_right: [Originalbild][25b] _(oder unten auf drittes Bild klicken)_
1 Zugriff via IP oder DNS | 2 Instanz failure | 3 Auto Scaler reagiert und startet neue Instanz
:---:|:---:|:---:|
[![VPC][23a]][23b] | [![Your VPC][24a]][24b] | [![Create VPC 1][25a]][25b]
4. Mehr Anfragen. Auto Scaler startet mehr Instanzen :mag_right: [Originalbild][26b] _(oder unten auf erstes Bild klicken)_
5. Noch mehr Anfragen. Auto Scaler erstellt noch mehr Instanzen :mag_right: [Originalbild][27b] _(oder unten auf zweites Bild klicken)_
4 Auto Scaler erstellt mehr Instanzen bei mehr Anfragen | 5 Auto Scaler erstellt noch mehr Instanzen bei noch mehr Anfragen
:---:|:---:
[![xxx][26a]][26b] | [![xxx][27a]][27b]
#### Missing in action
:bulb: Und hier kommt der **Loadbalancer** ins Spiel. Falls dieser nämlich vorhanden wäre, würde er **Hand in Hand** mit dem Auto-Scaler die aktuellen Infos austauschen und dafür sorgen, dass die Anfragen gleichmässig auf die vom **Auto Scaler** zur Verfügung gestellten EC2-Instanzen verteilt werden.
In diesem Challenge wird ein **Loadbalancer** aufgesetzt und so eingebunden, dass genau das funktioniert.<br>
Die Archtitektur sieht dann wie folgt aus:
##### Netzwerkschema:
1. Auto Scaling Group ist konfiguriert und reagiert dynamisch auf Status Checks und CloudWatch Metrics: :mag_right: [Originalbild][28b] _(oder unten auf das Bild klicken)_ <br>
2. Load Balancer existiert noch nicht. Muss nun erstellt werden
1 Auto Scaler ist konfiguriert und läuft / 2 Elastic Load Balancer wird nun erstellt und eingebunden |
:---:|
[![1. Launch template][28a]][28b]
<br>
#### Anleitung:
In diesem Abschnitt wird erklärt, wie man einen **Elastic Load Balancer** einrichtet und mit einer bestehenden **Auto Scaling Group** verbindet.
Es werden nicht alle Screenshots angezeigt. Es gibt allerdings die Möglichkeit, jeweils über den Begriff zu "hovern". Begriffe in Blau bedeuten, dass sie mit Links zu den zugehörigen Bildern ergänzt sind und können mit einem Klick geöffnet werden.
##### Schritt 1: Target Group erstellen
Zuerst definieren Sie eine Target Group. Hier wird bestimmt, **welche** EC2-Instanzen vom **Loadbalancer** bedient werden sollen.
1. [**Navigation Bar:**](./x_res/36_Target-Group_ORIG.png) Wählen Sie links unter **`Load Balancing`** den Buttom **`Target Groups`** aus. Dann konfigurieren Sie die **Target Group** mit folgenden Parametern:
2. [**Target Groups:**](./x_res/37_Target-Group_ORIG.png) Buttom **`Create Target Groups`** anklicken.
3. [**Specify group details (1.Seite):**](./x_res/38_Target-Group_ORIG.png)
- **Choose a target type:** **Instances** auswählen.
- **Target group name:** **`KN06-XXX-TargetGroup1`** eingeben
- **Protocol: `HTTP` Port: `80`**.
4. [**Specify group details (2.Seite):**](./x_res/39_Target-Group_ORIG.png):
- **IP address type:** `IPv4`
- **VPC:** `M346-XXX-VPC` _(Früher eingerichtete VPC auswählen)_.
- **Protocol Version:** `HTTP1` _(Defaultwert belassen)_.
- **Health checks:**
- Health check protocol `HTTP` _(Defaultwert belassen)_.
- Health check path **`/`** _(LB sendet den Targets regelmässig Statusanfragen)_.
- ...nach unten scrollen bis der Buttom **`Next`** erscheint.
5. Auf den Buttom **`Next`** klicken, um auf die nächste Seite zu gelangen.
6. 1. Available Instances: **Beide Instanzen aktivieren** :mag_right: [Originalbild][41b] _(oder unten auf erstes Bild klicken)_.<br>
2. Den Buttom **`Incluide as pending below`** anklicken.
7. **Review Targets:** Buttom **`Create target group`** anklicken :mag_right: [Originalbild][42b] _(oder unten auf zweites Bild klicken)_
6.1 Available instances - Instanzen aktivieren / 6.2. "Include as pending below" anklicken | 7 Review targets: Buttom "Create target group" anklicken
:---:|:---:
[![xxx][41a]][41b] | [![xxx][42a]][42b]
Die Target group wurde nun erstellt. Im nächsten Bild ist allerdings zu erkennen, dass **noch kein** Load Balancer zugewiesen wurde.
8. Load Balancer existiert noch nicht. Muss nun erstellt werden
1 Auto Scaler ist konfiguriert und läuft / 2 Elastic Load Balancer wird nun erstellt und eingebunden |
:---:|
[![1. Launch template][43a]][43b]
##### Schritt 2: Load Balancer erstellen
1. [**Navigation Bar:**](./x_res/45_Target-Group_ORIG.png) Wählen Sie links unter **`Load Balancing`** den Buttom **`Load Balancers`** aus. Dann klicken Sie auf den Buttom **`Create Load balancer`**.
2. [**Compare and select load balancer type:**](./x_res/46_Target-Group_ORIG.png) Wählen Sie den **`Application Load Balancer`** aus.
3. [**Create Application Load Balancer (1.Seite):**](./x_res/47_Target-Group_ORIG.png)
- **Load balancer name:** **`KN06-XXX-ALB1`** eingeben
- **Scheme: `Internet-facing`** auswählen
- **IP address type: `IPv4`** auswählen
4. [**Create Application Load Balancer (2.Seite):**](./x_res/48_Target-Group_ORIG.png)
- **VPC:** **`M346-XXX-VPC`** _(früher erstellte VPC auswählen)_
- **Mappings:**
- **`M346-XXX-Public-1A`** auswählen _(erstes Public Subnet)_
- **`M346-XXX-Public-1B`** auswählen _(zweites Public Subnet)_
5. [**Create Application Load Balancer (3.Seite):**](./x_res/49_Target-Group_ORIG.png)
- **Security Groups:** **`M346-XXX-Web-Access`** _(früher erstellte Security Group auswählen - Inbound rule Port 80 muss offen sein)_
- **Listeners and routing:**
- Protocol **`HTTP`** und Port **`80`** auswählen
- Default action: Forward to: **`KN06-XXX-TargetGroup1`** auswählen _(wenn Anfragen auf Port 80 eintreffen, sollen diese an die vorher erstellte TargetGroup weitergeleitet werden)_.
6. [**Create Application Load Balancer (4.Seite):**](./x_res/50_Target-Group_ORIG.png)
- **Summary:** **`Basic configuration`**, **`Security groups`**, **`Network mappings`** und **`Listeners and routing`** checken _(überprüfen, ob alles korrekt konfiguriert ist)_
- **Buttom `Create load balancer`** anklicken _(Load Balancer wird erstellt)_
7. Resultat: _(Hinweis, dass das Setup ein paar Minuten dauern kann)_
**7.** Mitteilung mit grünem Hintergrund: Successfully created Load balancer |
:---:
![LB](./x_res/51_Target-Group_1000.png) |
> **Animation: Load Balancer erstellen.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/E_lbconfig.gif alt="LoadBalancer" title="LoadBalancer" height="550" style="margin-left: 200px">
<br>
:warning: **Hinweis:** <br>
>Jetzt sind Sie zwar soweit, dass Sie eine Auto Scaling Group **und** einen Load Balancer haben, aber diese sind **noch nicht** aufeinander abgestimmt. Falls jetzt also **neue Instanzen** gelauncht würden, würden diese **noch nicht** der **Target Group** des **Loadbalancers** zugewiesen. Dazu müssen unbedingt noch folgende Steps durchgeführt werden.
##### Schritt 3: Auto Scaling Group der Target Group des Load Balancers zuweisen
1. [**Navigation Bar:**](./x_res/52_Target-Group_ORIG.png) Wählen Sie links unter **`Auto Scaling`** den Buttom **`Auto Scaling Groups`** aus. Dann klicken Sie auf die bereits existierende Auto Scaling Group **`KN06_XXX_AutoScalingGroup`**.
2. Scrollen Sie runter bis [**Load balancing:**](./x_res/53_Target-Group_ORIG.png) und klicken Sie auf **`Edit`**.
3. Unter [**Load balancers:**](./x_res/54_Target-Group_ORIG.png)
- Setzen Sie ein Häkchen in das **Feld** "Application, Network or Gateway Load Balancer target groups"
- Wählen Sie anschliessend die erstellte **Target Group** **`KN06-XXX-TargetGroup1`** aus.
- Klicken Sie unten auf das Feld **`Update`**
##### Schritt 4: Check
Im letzten Schritt nochmals kurz checken, ob in der **Target Group** die Targets (Instanzen) registriert sind und Health status **healthy** haben und dann mit dem DNS-Namen des Load Balancers testen, ob der Dienst funktioniert.
1. Bei der [**Navigation Bar:**](./x_res/55_Target-Group_ORIG.png) wählen Sie links unter **`Load Balancing`** den Buttom **`Target Groups`** aus. Dann klicken Sie auf den Tab **`Targets`**.
2. Bei der [**Navigation Bar:**](./x_res/56_Target-Group_ORIG.png) wählen Sie links unter **`Load Balancing`** den Buttom **`Load Balancers`** aus. Dann erscheint gleich der Name des Load Balancers **`KN06-XXX-ALB1`** und der zugehörige DNS Name **`KN06-XXX-ALB1-xxxxxx.us-east-1.elb.amazonaws.com`**.
3. 1.) Browser öffnen und **DNS-Namen** in neuen Tab kopieren: :mag_right: [Originalbild][57b] _(oder unten auf erstes Bild klicken)_<br>
2.) **`Reload Buttom`** des Browsers **mehrmals betätigen** - **us-east-1a** und **us-east-1b** wechseln sich ab: :mag_right: [Originalbild][58b] _(oder unten auf zweites Bild klicken)_
Random AZ. Entweder us-east-1a oder us-east-1b | Random AZ. Entweder us-east-1a oder us-east-1b
:---:|:---:
[![LoadBalancer in action1][57a]][57b] | [![LoadBalancer in Action2][58a]][58b]
4. Loadbalancer **Details**: :mag_right: [Originalbild][59b] _(oder unten auf Bild **4** klicken)_
5. Loadbalancer **Listener and rules**: :mag_right: [Originalbild][60b] _(oder unten auf Bild **5** klicken)_
6. Loadbalancer **Network mapping**: :mag_right: [Originalbild][61b] _(oder unten auf Bild **6** klicken)_
4 LB Details | 5 LB Listener and rules | 6 LB Network mapping
:---:|:---:|:---:|
[![xxx][59a]][59b] | [![xxx][60a]][60b] | [![xxx][61a]][61b]
7. Target Groups **Targets** (Zugehörige Instanzen): :mag_right: [Originalbild][62b] _(oder unten auf Bild **7** klicken)_
8. Auto Scaling Group **Launch template** (Welches Template wird genutzt): :mag_right: [Originalbild][63b] _(oder unten auf Bild **8** klicken)_
9. Auto Scaling Group **Activitiy** (Journal über gelaunchte Instanzen): :mag_right: [Originalbild][64b] _(oder unten auf Bild **9** klicken)_
7 Target Groups und zugehörige Instanzen | 8 Infos zu Launch Template | 9 Journal, Log
:---:|:---:|:---:|
[![TG-Inst][62a]][62b] | [![Template][63a]][63b] | [![Journal][64a]][64b]
> **Animation: Check.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/F_checkSuccess.gif alt="CheckSuccess" title="CheckSuccess" height="550" style="margin-left: 200px">
<br>
:warning: **Hinweis:** <br>
>Im Gegensatz zum Anfang dieses Challenges, entspricht die Umgebung jetzt dem **High availiabilty**-Standard - wie folgt:
>- Die **Auto Scaling Group** ist **im Hintergrund aktiv** und sorgt dafür, dass **immer mindestens zwei Instanzen** laufen.
>- Es wurde ein **Load Balancer** hinzugefügt, der die Last auf die verfügbaren Instanzen verteilt. Er nutzt dafür eine **Target Group**, auf welche auch der **Auto Scaler** Zugriff hat.
##### Use Case: Auto Scaler und Load Balancer funktionieren:
Dieses Beispiel mit einer Reihenfolge von **5 Bildern** verdeutlicht, wie **Auto Scaler** und **Load Balancer** interagieren und gemeinsam sicherstellen, dass die Plattform **fehlertolerant** und somit **hochverfügbar** ist.
**1. Bild:** Der **erste** Benutzer greift auf die App zu. Der **Load Balancer** leitet ihn weiter zur **Instanz 1**.<br>
**2. Bild:** Der **zweite** Benutzer greift auf die App zu. Der **Load Balancer** leitet ihn weiter zur **Instanz 2**.<br>
**3. Bild:** Der **dritte** und **vierte** Benutzer greifen auf die App zu. Der **Load Balancer** verteilt diese gleichmässig auf **beide Instanzen** _(Lastverteilung funktioniert)_<br>
**4. Bild:** Die **Instanz 1** fällt aus.<br>
**5. Bild:** Der **Load Balancer** erkennt den Fehler und leitet die Anfragen auf **Instanz 2** um<br>
**6. Bild:** Der **Auto-Scaler** erkennt Fehler und erstellt gemäss **Desired State: 2** eine **neue Instanz** (Nr.3).<br>
**7. Bild:** Der **Load Balancer** erhält die Info, dass vom **Auto Scaler** eine **neue** Instanz bereitgestellt wurde, nimmt diesen in seine **Target Group** auf und leitet Teil des Traffics darauf um.<br>
1. Zugriff vom **ersten** Benutzer: :mag_right: [Originalbild][29b] _(oder unten auf erstes Bild klicken)_
2. Zugriff vom **zweiten** Benutzer: :mag_right: [Originalbild][30b] _(oder unten auf zweites Bild klicken)_
3. Zugriff vom **dritten** und **vierten Benutzer**: :mag_right: [Originalbild][31b] _(oder unten auf drittes Bild klicken)_
1 Zugriff vom ersten Benutzer | 2 Zugriff vom zweiten Benutzer| 3 Zugriff vom dritten und vierten Benutzer
:---:|:---:|:---:|
[![User1][29a]][29b] | [![User2][30a]][30b] | [![User3+4][31a]][31b]
4. **Instanz1** fällt aus :mag_right: [Originalbild][32b] _(oder unten auf erstes Bild klicken)_
5. Der **Load Balancer** erkennt den Fehler und leitet Traffic auf gesunde Instanz um :mag_right: [Originalbild][33b] _(oder unten auf zweites Bild klicken)_
4 Instanz (Nr.1) fällt aus | 5 Load Balancer reagiert und leitet auf gesunde Instanz (Nr.2) um
:---:|:---:
[![Instanz1Error][32a]][32b] | [![Umleitung][33a]][33b]
6. Der **Auto-Scaler** erkennt den Fehler und erstellt sofort eine **neue Instanz** (Nr.3) :mag_right: [Originalbild][34b] _(oder unten auf erstes Bild klicken)_
7. Der **Load Balancer** reagiert, bindet die neue Instanz ein und leitet einen Teil des Traffics darauf um :mag_right: [Originalbild][35b] _(oder unten auf zweites Bild klicken)_
6 Auto-Scaler erkennt Fehler und startet neue Instanz (Nr.3) | 7 Load Balancer reagiert und bindet neue Instanz (Nr.3) ein
:---:|:---:
[![Instanz1Error][34a]][34b] | [![Umleitung][35a]][35b]
<br>
#### Ziel der Übung
:bell: Sie wissen, wie man eine **High availability**-Architektur aufsetzt.
Sie sind in der Lage, einen **Load Balancer** aufzusetzen und so zu konfigurieren, dass er mit einer **Auto Scaling Group** zusammenarbeitet und so sicherstellt, dass die Plattform **resilient** und **Fault tolerant** aufgebaut ist.
##### Leistungsnachweis
- [ ] Die **Target Group** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] Der **Load Balancer** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] Die **Auto Scaling Group** wurde korrekt der **Target Group** des **Load Balancers** zugewiesen.
- [ ] Der **Load Balancer** funktioniert fehlerfrei. Bei Reload des Browsers greift der **Load Balancer** auf **beide Availability Zones** zu.
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
- [ ] Fachgespräch mit Coach.
- [ ] Sie wissen, was eine **Target Group** ist und wie diese mit dem **Load Balancer** interagiert.
- [ ] Sie verstehen, weshalb die **Auto Scaling Group** der **Target Group** zugewiesen wird und können anhand eines Beispiels differenziert erklären, wie sich das auf die Funktion der Plattform auswirkt.
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
#### Services löschen
:warning: **Hinweis:**
>Nachdem Sie den **Challenge D** abgeschlossen haben und **bevor** sie mit dem letzten **Challenge E** starten, müssen Sie die **bestehende Umgebung löschen**. Im folgenden Challenge werden Sie das gelernte Wissen für einen neuen, etwas ergänzten, Use-case anwenden.
Führen Sie nun folgende Schritte der Reihe nach durch, damit sie später **keine** Konflikte bekommen:
>1. Auto Scaling Group **löschen**: :mag_right: [Originalbild][65b]
>2. Instanzen **löschen** (falls ASG gelöscht wird, nicht zwingend nötig): :mag_right: [Originalbild][66b]
>3. Load Balancer **löschen**: :mag_right: [Originalbild][67b]
>4. Target Groups **löschen**: :mag_right: [Originalbild][68b]
>5. Launch Template **löschen**: :mag_right: [Originalbild][69b]
<br>
----
### E) High Availability Setup mit elastischer Anpassung der Ressourcen (HA Ninja)
#### Ausgangslage:
Sie wissen nun, wie man eine High Availability Plattform aufbaut und betreibt. Was nun noch fehlt ist, dass die Applikation **on-demand** weitere Instanzen hoch- und runterfahren kann. Im AWS Fachjargon nennt man diesen Prozess **Elasticity**. AWS Elasticity hilft, Geld zu sparen und gleichzeitig sicherzustellen, dass die Anwendungen immer reibungslos laufen.
##### Challenge +
:bulb:
Im letzten KN06-Challenge werden Sie **selbständig** eine **Elastic High Availability Plattform** aufbauen. Erschwerend kommt jetzt also nur noch hinzu, dass Sie die Umgebung so aufsetzen müssen, dass sie **elastisch skalieren** kann. Alles andere haben Sie bereits gemacht. Damit am Ende technisch alles funktioniert, müssen sie für die neue **Auto Scaling Group** eine sogenannte **Dynamic scaling policy** erstellen. In diesem Fall mit dem **Target value = 20**. Das bedeutet, dass sobald Sie ihre Webseite mehr als 20x reloaden, automatisch weitere Instanzen hochgefahren und an den Load Balancer angehängt werden. Damit Sie dies auch beweisen können, erstellen Sie ein **neues Launch Template** mit leicht ergänztem Code. Dieser ist dafür verantwortlich, dass auf Ihrer Webseite unter der Availability Zone noch eine **zweite Zeile** erscheint mit der **Instanz-ID**. So kann man schön überprüfen, ob die neuen Instanzen auch vom Load Balancer angesprochen werden können.
:bookmark_tabs: Die ergänzenden Skills bzgl. **elastischem** Setup werden Ihnen, wenn es soweit ist, step by step erklärt. Bzgl. Namenskonvention gibt es ebenfalls noch ein paar wichtige Informationen unten. Alles andere müssen Sie allerdings **selber elaborieren**.
Nutzen Sie dazu die Anleitung des letzten Challenges. Achten Sie darauf, dass die Namenskonvention **leicht angepasst** wurde und dass Sie z.B. für das Launch Template ein **anderes Script** (ergänzt mit Instance-IDs) verwenden. Dies, weil Sie am Ende beweisen werden, dass Ihre Plattform in der Lage sein wird, **on-demand** neue Instanzen hinzuzufügen und dass der Load Balancer anschliessend auch darauf zugreifen kann.
Die Bildreihenfolge unten zeigt nochmals, was mit **Elastic Load Balancing** gemeint ist.
**1. Bild:** Es greifen weit mehr als gewöhnlich viele User auf die Applikation zu. Desired State ist auf **2 Instanzen** gesetzt.<br>
**2. Bild:** Der **Auto-Scaler** erhält von **Amazon CloudWatch** die Information, dass der Grenzwert **Target value** überschritten wurde (Policy-Metric). Er erstellt eine **neue Instanz** (Nr.3)<br>
**3. Bild:** Der **Auto Scaler** erstellt weitere Instanz (4/5), nimmt diese in seine **Target Group** auf und leitet einen Teil des Traffics darauf um.<br>
1. **Viele Benutzer** greifen auf die App zu: :mag_right: [Originalbild][70b] _(oder unten auf erstes Bild klicken)_
2. **Auto Scaler** reagiert und fährt neue Instanz hoch: :mag_right: [Originalbild][71b] _(oder unten auf zweites Bild klicken)_
3. **Metrics Alarm** besteht weiterhin. Weitere Instanzen werden hochgefahren: :mag_right: [Originalbild][72b] _(oder unten auf drittes Bild klicken)_
1 Hohe Belastung. CloudWatch Alarm | 2 Grenzwert überschritten. Weitere Instanz | 3 Demand bleibt hoch. Noch mehr Instanzen
:---:|:---:|:---:|
[![User1][70a]][70b] | [![User2][71a]][71b] | [![User3+4][72a]][72b]
<br>
#### Anleitung:
:warning: **Hinweis:** <br>
>In diesem Abschnitt wird in **groben Zügen** erklärt, was zu tun ist. Achten Sie auf die Namenskonvention und auf die **Änderungen** in Bezug auf den letzten Challenge. Sie können also **nicht** einfach alles vom letzten Challenge 1:1 kopieren.
Zum Kompetenznachweis gehört nicht nur eine funktionierende Plattform, sondern auch die korrekte Namensgebung, eine nachvollziehbare Dokumentation und solide Argumente im Fachgespräch :muscle:
<br>
##### Schritt 1: Launch template erstellen
> **Referenz:** [**HIER**](#schritt-1-launch-template-erstellen) geht's zur ausführlichen Anleitung **Launch Template erstellen** des letzten Challenges.
Wählen Sie links in der **Navigation Bar** unter **`Instances`** das Unterverzeichnis **`Launch Templates`** aus. Dann klicken Sie auf den orangen Buttom **`Create launch template`**. Danach erscheint eine neue Seite mit dem Titel **Create launch template**, welches Sie wie folgt ausfüllen:<br>
- **Launch template Name and description:**
- Name: **`KN06_XXX_LaunchTemplate_2`**
- Description: **`KN06_XXX_LaunchTemplate_2`**
- **Application and OS Image:**
- **`Amazon Linux 2023 AMI (AWS)`**
- **Instance type:**
- **`t2.micro`**
- **Key-pair name:**
- **`Don't include in launch template`**
- **Network settings:**
- Subnet `Don't include in launch template`
- Security-Groups `M346-XXX-Web-Access` auswählen (wurde bereits früher erstellt)
- **Advanced Details** (unter User data):
- [**diesen Code**](https://gitlab.com/ser-cal/m346-scripts/-/blob/main/KN06/user-data-az_d.md?ref_type=heads) eingeben (Copy/Paste). **Achtung:** Dies ist nicht derselbe Code wie im letzten Challenge!
- Buttom **Create launch template** anklicken: (Template wird erstellt)
- Buttom **View launch template** anklicken: (Kontrolle)
<br>
##### Schritt 2: Auto Scaling Group erstellen
> **Referenz:** [**HIER**](#schritt-2-auto-scaling-group-erstellen) geht's zur Anleitung **Auto Scaling Group erstellen** des letzten Challenges.
Wählen Sie links in der **Navigation Bar** unter **`Auto Scaling`** das Unterverzeichnis **`Auto Scaling Groups`** aus. Dann klicken Sie auf den orangen Buttom **`Create Auto Scaling group`**. Danach erscheint eine neue Seite mit dem Titel **Choose launch template**, welches Sie wie folgt ausfüllen:<br>
- **Name:**
- Auto Scaling group name: **`KN06_XXX_AutoScalingGroup_2`**
- Launch template: **`KN06_XXX_LaunchTemplate_2`**
- VPC: **`M346-XXX-VPC`**
- Availability Zones and subnets: **beide Public-subnets**
- **Load balancing:**
- **`No load balancer`** (da noch kein LB vorhanden ist)
- **VPC Lattice integration options**
- **`No VPC Lattice service`**
- **Group size:**
- `Desired capacity` auf **2**
- `Minimum capacity` auf **2**
- `Maximum capacity` auf **4**
- **Scaling policies**
- `None` anklicken. Später werden wir hier allerdings noch eine sogenannte **Target tracking scaling policy** ergänzen.<br>
- `Next` bestätigen<br>
- Sobald die **Auto Scaling Group** erstellt ist, werden im Hintergrund die beiden Instanzen gemäss **Launch Template** gestartet.
Instanz 1 | Instanz 2
:---:|:---:
[![Instanz1][74a]][74a] | [![Instanz2][75a]][75a]
- Ergänzend wird noch die **Instanz ID** ausgegeben. Diese wird später benötigt, um zu überprüfen, ob die **Scaling Policy** funktioniert und **on-demand** weitere Instanzen startet, wenn der Grenzwert überschritten wurde.
> **Animation: Auto Scaling Group erstellen.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/A_autoscaler.gif alt="AutoScaler" title="AutoScaler" height="550" style="margin-left: 200px">
<br>
##### Schritt 3: Target Group erstellen
> **Referenz:** [**HIER**](#schritt-1-target-group-erstellen) geht's zur Anleitung **Target Group erstellen** des letzten Challenges.
Die **Target Group** bestimmt, **welche** EC2-Instanzen vom **Loadbalancer** bedient werden sollen.<br>
Wählen Sie links in der **Navigation Bar** unter **`Load Balancing`** den Buttom **`Target Groups`** aus. Dann konfigurieren Sie die **Target Group** mit folgenden Parametern:
- **Target Groups:** Buttom **`Create Target Group`** anklicken.
- **Specify group details:**
- **Basic configuration:**
- Choose a target type: **`Instances`** auswählen.
- Target group name: **`KN06-XXX-TargetGroup2`** eingeben
- Protocol: **`HTTP` Port: `80`**.
- IP address type: **`IPv4`**
- VPC: **`M346-XXX-VPC`** _(Früher eingerichtete VPC auswählen)_.
- Protocol Version: **`HTTP1`** _(Defaultwert belassen)_.
- **Health checks:**
- Health check protocol **`HTTP`** _(Defaultwert belassen)_.<br>
- Health check path **`/`** _(LB sendet den Targets regelmässig Statusanfragen)_.
...nach unten scrollen bis der Buttom **`Next`** erscheint.
Auf den Buttom **`Next`** klicken, um auf die nächste Seite zu gelangen.
- **Available Instances:**
- Beide Instanzen **aktivieren** :mag_right: [Originalbild][41b] _(oder unten auf erstes Bild klicken)_.<br>
- Den Buttom **`Incluide as pending below`** anklicken.
- **Review Targets:** Buttom **`Create target group`** anklicken :mag_right: [Originalbild][42b] _(oder unten auf zweites Bild klicken)_.<br>
Available instances - aktivieren / "Include as pending below" | Review targets: "Create target group"
:---:|:---:
[![xxx][41a]][41b] | [![xxx][42a]][42b]
> **Animation: Target Group erstellen.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/B_targetgroup.gif alt="TargetGroup" title="TargetGroup" height="550" style="margin-left: 200px">
<br>
##### Schritt 4: Load Balancer erstellen
> **Referenz:** [**HIER**](#schritt-2-load-balancer-erstellen) geht's zur Anleitung **Load Balancer erstellen** des letzten Challenges.
Wählen Sie links in der **Navigation Bar** unter **`Load Balancing`** den Buttom **`Load Balancers`** aus. Dann konfigurieren Sie den **Load Balancer** mit folgenden Parametern:
- **Compare and select load balancer type:**
- **Load balancer types:** **`Application Load balancer`**
- **Create Application Load Balancer**
- Load balancer name:** **`KN06-XXX-ALB2`**
- Scheme: **`Internet-facing`**
- IP address type: **`IPv4`**
- **Network mapping**
- VPC: **`M346-XXX-VPC`** _(früher erstellte VPC auswählen)_
- Mappings:
- **`M346-XXX-Public-1A`** _(erstes Public Subnet)_
- **`M346-XXX-Public-1B`** _(zweites Public Subnet)_
- **Security Groups:** **`M346-XXX-Web-Access`** _(früher erstellte Security Group auswählen - Inbound rule Port 80 muss offen sein)_
- **Listeners and routing:**
- Protocol **`HTTP`** und Port **`80`** auswählen
- Default action: Forward to: **`KN06-XXX-TargetGroup2`** auswählen _(wenn Anfragen auf Port 80 eintreffen, sollen diese an die vorher erstellte TargetGroup weitergeleitet werden)_.
- **Summary:**
- **`Basic configuration`**, **`Security groups`**, **`Network mappings`** und **`Listeners and routing`** checken _(überprüfen, ob alles korrekt konfiguriert ist)_
- **Buttom `Create load balancer`** anklicken _(Load Balancer wird erstellt)_
- **Resultat:** _(Hinweis, dass das Setup ein paar Minuten dauern kann)_
> **Animation: Load Balancer erstellen.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/C_loadbalancer.gif alt="AutoScaler" title="AutoScaler" height="550" style="margin-left: 200px">
<br>
##### Schritt 5: Auto Scaling Group der Target Group des Load Balancers zuweisen
> **Referenz:** [**HIER**](#schritt-2-load-balancer-erstellen) geht's zur Anleitung **Auto Scaling Group der Target Group des Load Balancers zuweisen** des letzten Challenges.
Wählen Sie links in der **Navigation Bar** unter **`Auto Scaling`** den Buttom **`Auto Scaling Groups`** aus. Dann klicken Sie auf die bereits existierende Auto Scaling Group **`KN06_XXX_AutoScalingGroup_2`**. Scrollen Sie runter bis **Load balancing:** und klicken Sie auf **`Edit`**.
- **Load balancing:**
- Load balancers: **`Application Load balancer`**
- Select target groups: **`KN06-XXX-TargetGroup2`**
- Buttom: **`Update`**
<br>
##### Schritt 6: Dynamic Scaling policy erzeugen und einbinden
Diesen Schritt haben Sie bisher noch nicht durchgeführt. Die **Dynamic Scaling Policy** automatisiert die Anpassung der Instanzen basierend auf einer vordefinierten Metrik.
1. Create dynamic scaling policy: :mag_right: [Originalbild][76b] _(oder unten auf das Bild klicken)_<br>
1.) Auto Scaling Groups 2.) aktiveren 3.) Tab "Automatic scaling" 4.) Create dynamic scaling policy |
:---:|
[![Dynamic scaling policy][76a]][76b]
In diesem Fall erstellen Sie folgende Metric:
- **Create dynamic scaling policy:** :mag_right: [Screenshot][77b]
- Policy type: **`Target tracking scaling`** (Default)
- Scaling policy name: **`Target Tracking Policy`** (Defalut)
- Metric type: **`Application Load Balancer request count per target`**
- Target group: **`KN06-XXX-TargetGroup2`**
- Target valuie: **`20`**
- Instance warmup: **`300`** (Default)
:bookmark_tabs: **Information:**
> Wenn die Metric den Schwellenwerte **20** über- oder unterschreitet, wird die **Anzahl der Serverinstanzen automatisch erhöht oder verringert**. Ohne manuelle Eingriffe. Dies ermöglicht eine flexible und ressourceneffiziente Skalierung der Anwendung in der AWS-Cloud.<br>
**Instance Warmup** ist mit **300 seconds** definiert. Diesen Wert können Sie so lassen. Das ist die Zeitspanne, in der neue Instanzen starten und sich vorbereiten können, **bevor** sie in die Bereitstellung einbezogen werden. So kann man sicherstellen, dass die neu gestarteten Instanzen stabil und betriebsbereit sind, bevor sie den Verkehr von ihrem Application Load Balancer übernehmen. <br>
Es braucht also ein bisschen **Geduld**, bis dieser Nachweis erbracht werden kann - und regelmässiges Reloaden der Webseite (mind. 100x auf URL des Loadbalancers klicken :-) .
##### Schritt 7: Check
Nachdem die Scaling Policy erstellt wurde, erstmal etwas warten (:coffee:). Dann URL des Loadbalancers in einem Browser eingeben und verteilt über ein paar Minuten (mind. 3 Min.) so oft wie möglich **reloaden**. Gleichzeitig mit CloudWatch verfolgen, was läuft. **Reloaden** bis der Alarm ausgelöst wird (oder Krampferscheinungen im Zeigfinger auftreten :dizzy_face: ). Anhand der Kurve weiter unten ist erkennbar, wann der Alarm ausgelöst wird.
> **Animation: URL des Load Balancers reloaden.** Klicken Sie auf unten auf das GIF, um es in Originalgrösse anzuzeigen:
<img src=./x_res/D_check.gif alt="URL-Reload" title="URL-Reload" height="300" style="margin-left: 200px">
<br>
1. CloudWatch-Fenster öffnen und überwachen. Alarm: :mag_right: [Originalbild][86b] _(oder unten auf das Bild klicken)_<br>
1.) TargetTracking: Alarm wird ausgelöst |
:---:|
[![TargetTracking][86b]][86b]
2. **AlarmHigh** wird ausgelöst. Increase the capacity from 2 to 3: :mag_right: [Originalbild][80b] _(oder unten auf erstes Bild klicken)_
3. **Desired capacity** neu **3** (vorher 2): :mag_right: [Originalbild][81b] _(oder unten auf zweites Bild klicken)_
4. **Neue Instanz** nach ein paar Minuten (Instance warmup 5. Min.) eingebunden und funktional: :mag_right: [Originalbild][82b] _(oder unten auf drittes Bild klicken)_
2 Alarm wird ausgelöst | 3 Weitere Instanz wird hochgefahren | 4 Instanz wird eingebunden
:---:|:---:|:---:|
[![Alarm][80a]][80b] | [![WeitereInstanz][81a]][81b] | [![InstanzReady][82a]][82b]
###### 1. Beweis: AlarmHigh
Zusätzliche Instanz ist eingebunden und funktionsfähig.
5. **Erste Instanz** letzte drei Ziffern: **cce** :mag_right: [Originalbild][83b] _(oder unten auf erstes Bild klicken)_
6. **Zweite Instanz** letzte drei Ziffern: **c61** :mag_right: [Originalbild][84b] _(oder unten auf zweites Bild klicken)_
7. **Dritte Instanz** letzte drei Ziffern: **79e** :mag_right: [Originalbild][85b] _(oder unten auf drittes Bild klicken)_
1 Instanz ID ...cce | 2 Instanz ID ...c61 | 3 Instanz ID ...79e
:---:|:---:|:---:|
[![Instanz1][83a]][83b] | [![Instanz2][84a]][84b] | [![Instanz3][85a]][85b]
###### 2. Beweis: AlarmLow
Nicht mehr reloaden. Die Last lässt nach. Der Grenzwert wird irgendwann unterschritten und somit der **AlarmLow** ausgelöst. Daraufhin wird **eine** der drei Instanzen wieder automatisch runtergefahren wird. Der Dienst achtet darauf, dass die beiden verbleibenden Instanzen in unterschiedlichen Availabilty Zones sind.
8. **AlarmLow** wird ausgelöst. Decrease the capacity from 3 to 2: :mag_right: [Originalbild][87b] _(oder unten auf erstes Bild klicken)_
9. **Desired capacity** neu **2** (vorher 3)::mag_right: [Originalbild][88b] _(oder unten auf zweites Bild klicken)_
10. **Eine Instanz** wird terminiert: :mag_right: [Originalbild][89b] _(oder unten auf drittes Bild klicken)_
8 Alarm wird ausgelöst | 9 Desired state wird zurückgesetzt | 4 Instanz wird terminiert
:---:|:---:|:---:|
[![AlarmLow][87a]][87b] | [![DesiredState][88a]][88b] | [![Instanz terminiert][89a]][89b]
<br>
#### Ziel der Übung
:bell: Sie wissen, wie man eine **High availability**-Architektur aufsetzt.
Sie sind in der Lage, einen **Load Balancer** aufzusetzen und so zu konfigurieren, dass er mit einer **Auto Scaling Group** zusammenarbeitet und so sicherstellt, dass die Plattform **resilient**, **Fault tolerant** und **dynamisch skalierbar** ist.
##### Leistungsnachweis
- [ ] Die **Target Group** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] Der **Load Balancer** ist korrekt erstellt worden (gemäss Namenskonvention).
- [ ] Die **Auto Scaling Group** wurde korrekt der **Target Group** des **Load Balancers** zugewiesen.
- [ ] Der **Load Balancer** funktioniert fehlerfrei. Bei Reload des Browsers greift der **Load Balancer** auf **beide Availability Zones** zu.
- [ ] Die **Scaling policy** funktioniert fehlerfrei. Beim Überschreiten des Grenzwertes wird automatisch eine **neue Instanz** hochgefahren und in die Plattform eingebunden.
- [ ] Differenziert und nachvollziehbar im persönlichen Repository dokumentiert.
- [ ] Fachgespräch mit Coach.
- [ ] Sie wissen, was eine **Target Group** ist und wie diese mit dem **Load Balancer** interagiert.
- [ ] Sie verstehen, weshalb die **Auto Scaling Group** der **Target Group** zugewiesen wird und können anhand eines Beispiels differenziert erklären, wie sich das auf die Funktion der Plattform auswirkt.
- [ ] Sie wiessen, wie eine **Scaling Policy** funktioniert und können anhand eines Use-Cases erklären, welche Vorteile sich dadurch ergeben.
Beachten Sie ausserdem die [allgemeinen Informationen zu den Abgaben](../Abgaben.md).
#### Services löschen
:warning: **Hinweis:**
>Nachdem Sie den **Challenge E** abgeschlossen und vorgeführt haben, müssen Sie **sämtliche darin aufgebauten Dienste löschen**.
Führen Sie nun folgende Schritte der Reihe nach durch, damit sie später **keine** Konflikte bekommen:
>1. Auto Scaling Group **löschen**: :mag_right: [Originalbild][65b]
>2. Instanzen **löschen** (falls ASG gelöscht wird, nicht zwingend nötig): :mag_right: [Originalbild][66b]
>3. Load Balancer **löschen**: :mag_right: [Originalbild][67b]
>4. Target Groups **löschen**: :mag_right: [Originalbild][68b]
>5. Launch Template **löschen**: :mag_right: [Originalbild][69b]
<br>
---
> [⇧ **Zurück zu KN06**](./README.md)
---
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
---
Reference in New Issue View Git Blame Copy Permalink