Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Virtualization & Cloud Computing

Final Project

Examined By :

  • Alessio Merlo
  • Enrico Russo

Achieved By :

  • Alessio Gilardi
  • Anna Grosso
  • Soufia Bouamri

Obiettivo

Costruire un'architettura distribuita costituita da 3 Virtual Machines (Ubuntu Server 16.04). Le tre macchine saranno inserite in un Docker Swarm e condivideranno un file system grazie alla tecnologia di GlusterFS. Lo Swarm ospiterà i seguenti container:

Introduzione

Creazione

Creazione VMnet

Edit > Virtual Network Editor

Configurazione Switch di rete

VMnet3

VMnet3

VMnet8

VMnet8

Creazione VM

File > New Virtual Machine > Custom (advanced) > Next > Hardware: Workstation 15.x > Next

Creazione VM

Hard Disk

Settings > Add > Hard Disk (SCSI)

Hard Disk

Formattazione:

Setup

Setup

SSH

VM > SSH > Connect to SSH

Git

Docker

Docker-compose:

Clonazione

VM1>Manage>Clone

Clonazione

VM1

VM3

VM2

Configurazione

VM1

VM2

Settare la rete di VM1:

Sostituire 192.168.75.12

VM3

Setup Network

Sostituire 192.168.75.13

Assegnare un nome all'indirizzo IP

Verifica

Controllare il network:

Testare la connettività:

Test

Verificare la connettività con il nome:

Docker swarm

Settare VM1 manager:

Aggiungere i worker (VM2 e VM3)

Docker Swarm

Mostrare i nodi:

GlusterFS

Settare Gluster network

Assegnare un nome all'indirizzo IP

GlusterFS

Check

Fare questi passaggi per le altre macchine!

Installazione GlusterFS

Per fare partire il servizio:

Ogni server deve sapere degli altri:

Installazione Gluster

Per controllare lo stato:

Settare le cartelle dove risiede il bricks:

Aggiungere la riga al file /etc/fstab sulle VM (i bricks vengono “montati” all’avvio del SO)

Montare filesystems:

I volumi replicati di GlusterFS

Creare un nuovo volume gfs:

Fai partire il volume:

Visualizza informazioni e stato:

Autorizzare le tre VM a connettersi al gfs su ogni nodo:

Volumi replicati

Montare il volume:

Modificare l’owner di /gfs con l’utente corrente:

Creare un file su una macchina virtuale:

Mostrare lo spazio del volume montato:

Verificare che si veda nelle altre due:

Creare le cartelle dei servizi:

File Hosts windows

Soluzione

Risultato

Stack deploy

Servizi

Build

Examined By :

  • Luca Oneto

Achieved By :

  • Asma Rebhi
  • Soufia Bouamri

Docker build

Build delle immagini di Joomla & Phpmyadmin:

Fare questi passaggi per le altre macchine!

Docker Stack

Visualizzare stack e servizi:

Domande

&

Bonus

Cause

Split-brains condition

  • "Crash" di alcuni nodi

  • Problemi di networking

Split brains

Incoerenza nei dati (o nei metadati del file) tra i bricks di una replica.

Non ci sono abbastanza informazioni per scegliere in modo autorevole una copia come originale (curando così le "bad copies"), nonostante tutti i bricks siano attivi e online.

Soluzioni con "quorum"

  • Replica volume 3 (nostro caso)
  • Arbiter volume: replica volume 2 con un terzo usato come "arbitro" che mantiene solo nomi dei file e metadata

Replica volume 3 offre High Availability rispetto a Arbiter volume ma occupa più risorse.

Attenuano il problema MA non lo risolvono.

Fonte:

https://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/

Troubleshooting

Mostra lista dei file in condizione di "split-brains":

Troubleshooting

Individuati i file in Split-brains condition, utilizzo come sorgente:

  • Il file più grande
  • Il file con l'ultima modifica più recente
  • Uno dei "brick" nella replica

Opzione di policy: cluster.favorite-child-policy

Quando è settata ad una delle policy disponibili, risolve in automatico lo Split-brains.

Fonti:

  • https://docs.gluster.org/en/latest/Troubleshooting/resolving-splitbrain/
  • https://www.nutellino.it/2018/09/22/risolvere-glusterfs-split-brain-automagicamente/

Sessioni persistenti

  • Usando stickiness property in Traefik

  • Condividendo su GlusterFS: /var/lib/php/session

  • Usando il DB: Joomla Default

Sessioni persistenti

MySql Group Replication

MySql High Availability

  • Creazione di N container con immagine docker MySql (ad esempio 3)
  • Viene dichiarato un Master (ad esempio il Nodo1)
  • Vengono dichiarati gli altri nodi come Slave
  • I comandi usati sono semplici query SQL
  • Dalla tabella Performance Schema del Nodo1 (Master) è possibile vedere le 3 repliche
  • Simulando il "crash" di un Nodo la fault tolerance è garantita dagli altri due

Load Balancing

Fonte:

https://mysqlhighavailability.com/setting-up-mysql-group-replication-with-mysql-docker-images/

Graphic Map

Graphic Map

Load Balancing

Traefik

"traefik.http.services.monitor.loadbalancer.server.port=<PORT>"

Load Balancing

Traefik è in grado di fornire, nativamene, servizi di load balancing verso le repliche dello Swarm.

Miglioramenti

Single point of failure

Miglioramenti

Taefik è eseguito sullo Swarm Manager, ciò presenta la problematica di "Single point of failure".

Soluzione:

Eseguire traefik su un Worker e, in ogni caso, utilizzare un numero maggiore di Manager, possibilmente in numero dispari come spiegato nella guida:

https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/

Comandi Utili

Stack

Stack

Swarm

Swarm

Aggiungere un manager allo swarm:

Comandi per promuovere o togliere un manager:

Per tirare giù una macchina:

Per riattivarla:

Prometheus

Prometheus

Fonti:

https://awesome-prometheus-alerts.grep.to/rules.html

Learn more about creating dynamic, engaging presentations with Prezi