mirror of
https://gitlab.com/ser-cal/m346.git
synced 2024-11-29 18:11:57 +01:00
223 lines
13 KiB
Markdown
223 lines
13 KiB
Markdown
[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
|
|
|
|
[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
|
|
|
|
# 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.
|
|
|
|
- Theorie-script (noch verlinken)
|
|
- Leistungsnachweise (noch verlinken)
|
|
|
|
|
|
|
|
|
|
### 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:
|
|
- Screenshots :
|
|
|
|
1. Load Balancer mit **zwei** Instanzen: :mag_right: [Originalbild][01b] _(oder unten auf erstes Bild klicken)_
|
|
2. Load Balancer mit **vier** Instanzen: :mag_right: [Originalbild][01b2] _(oder unten auf zweites Bild klicken)_
|
|
|
|
1 Load Balancer mit zwei Instanzen | 2 Load Balancer mit vier Instanzen
|
|
:---:|:---:
|
|
[![1. Load Balancer][01a]][01b] | [![2. Load Balancer mit 4 Instanzen][01a2]][01b2]
|
|
|
|
|
|
|
|
|
|
#### 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 :
|
|
|
|
1. LoadBalancer: :mag_right: [Originalbild][001b] _(oder unten auf erstes Bild klicken)_
|
|
2. Target Group: :mag_right: [Originalbild][002b] _(oder unten auf zweites Bild klicken)_
|
|
|
|
1 LoadBalancer | 2 Target Group
|
|
:---:|:---:
|
|
[![1. Loadbalancer][001a]][001b] | [![2. TargetGroup][002a]][002b]
|
|
|
|
1. Webserver **1**: :mag_right: [Originalbild][003b] _(oder unten auf erstes Bild klicken)_
|
|
2. Webserver **2**: :mag_right: [Originalbild][004b] _(oder unten auf zweites Bild klicken)_
|
|
|
|
3 Webswerver 1 | 4 Webserver 2
|
|
:---:|:---:
|
|
[![3. Webserver 1][003a]][003b] | [![4. Webserver 2][004a]][004b]
|
|
|
|
<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.
|
|
|
|
Text:
|
|
1. Text: :mag_right: [Originalbild][19b] _(oder unten auf erstes Bild klicken)_<br>
|
|
1 xxx |
|
|
:---:|
|
|
[![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. 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 diese Ressourcen über zwei oder mehrere **Availability Zones** verteilt werden, spricht man bei einer solchen Konfiguration von einer **High Availability-Architektur**.
|
|
|
|
|
|
#### 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`** den Buttom **`Create Launch template`** aus. Dann 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.
|
|
 |
|
|
- 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 **Choos 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> |  |
|
|
|
|
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: 3.82.198.9) : :mag_right: [Originalbild][15b] _(oder unten auf erstes Bild klicken)_<br>
|
|
2.) Zweite EC2 Instanz (PublicIP: 3.89.71.0): :mag_right: [Originalbild][16b] _(oder unten auf zweites Bild klicken)_
|
|
|
|
Erste EC2 Instanz (PublicIP: 3.82.198.9) | Zweite EC2 Instanz (PublicIP: 3.89.71.0)
|
|
:---:|:---:
|
|
[![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: 3.82.198.9) - **us-east-1a** : :mag_right: [Originalbild][17b] _(oder unten auf erstes Bild klicken)_<br>
|
|
2.) Zugriff auf zweite EC2 Instanz (PublicIP: 3.89.71.0) - **us-east-1b**: :mag_right: [Originalbild][18b] _(oder unten auf zweites Bild klicken)_
|
|
|
|
Erste EC2 Instanz (AZ: us-east-1a) | Zweite EC2 Instanz (AZ: us-east-1b)
|
|
:---:|:---:
|
|
[![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>
|
|
|