###### tags: `S8` `SI` `Gestion de données réparties`

<style>
.table-center th, .table-center td {
text-align: center;
}

.row-around {
display: flex;
justify-content: space-around;
width: 100%;
}

ul {
list-style-type: armenian;
}
ul ul {
list-style-type: georgian;
}
ul ul ul {
list-style-type: hebrew;
}

</style>

# Présentation des modèles de Cloud computing

## Maquette

<div class="row-around">
<table class="table-center">
<thead>
<tr>
<th colspan="3">Horaires (h)</th>
</tr>
<tr>
<th>CM</th>
<th>TD</th>
<th>TP</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>4</td>
<td>10</td>
</tr>
</tbody>
</table>

<table class="table-center">
<thead>
<tr>
<th colspan="3">Poids (%)</th>
</tr>
<tr>
<th>UE</th>
<th>CC</th>
<th>ET</th>
</tr>
</thead>
<tbody>
<tr>
<td>30</td>
<td>100</td>
<td>/</td>
</tr>
</tbody>
</table>
</div>

**[Lien vers le cours](https://littl.fr/CC-PolytechTours)**

## Évaluation

Compte-rendu fin TP, a renvoyer avant le TP suivant

## Plan

- Histoire et évolution des infrastructures
- La virtualisation
- IAAS Infrastructure As A Service
- Cloud public / privé / hybride
- PASS Platform As A Service
- SAAS Software As A Service
- Risquesdu cloud
- Docker - microservices
- Autre technologie
- Serverless computing
- DCAAS - DataCenter as a service
- FPGA
- ???
- Evolution et futur du cloud

## Histoire
### Infrastructure mainframe, chaque poste connecté au serveur
- Ressources centralisées
- Système internalisé
- Proximité géographique
- "Vielles technologies"
- Terminaux passifs
- AS400, IBM Mainframe
- Coaxial
- Unix (noyau et pas ses évolutions) / Système proprio (IBM, ...)

### Ethernet / Local
- Séparation des services et composants
- Distance géographique plus élevée que mainframe
- Technologie
- Ethernet / cDSL
- Linux / Windows

### Internet
Les serveurs n'étaient plus tous au même endroit
- App accesssible depuis l'extérieur / ou par VPN
- Nécessite une sécu accrue
- Technos
- xDSL, Fibre, Satellitaire : Nordnet / Starlink
- Firewall
- Linux / Windows

### Besoins mobiles

...

### Les coûts

#### Les coûts d'un datacenter
- m² (location / achat superficie)
- Refroidissement (énergie, maintenance)
- Électricité (achat, maintenance des alimentations)
- Redondance (Générateur (essence, hydraulique), maintenance)
- Sécurité (gardes, caméras, assurances, ...)
- Achats (Composants)
- Support (Maintenance, pannes)
- Licenses (Windows servers, hyperviseurs)
- Baies de stockage

#### Les coûts réseaux
- Connectivité (internet (redondé))
- Switch (license en + de l'achat)
- Addresses IPs
- Nom de domaines

## Virtualisation
**Serveur virtuel :** portion d'un serveur physique dédiée à l'application (les ressources n'ont pas beoin de toutes les ressources de la machine physique) -> VM

### Mutualisation des machines
- Pls roles par machine physique
- ...
- ...
- ...

### Avantages
- Redondance facilitée
- Pas liée à la durée de vie du matériel
- Ressources allouées " au min" (pas de sur allocation)

### Hyperviseurs
#### Type 1 (native (bare metal))
#### Type 2 (hosted)

#### Encore plus loin
- Stockage centralisé (SAN, DAS, NAS, ...)
- Possibilité de basculer les VMs d'un serveur physique à un autre si panne

Virtualisation à stockage centralisé
- VM sotckées sur un appareil partagé entre les différents serveurs
- Déplacement / Migration possible entre machines
- Equilibrage de la charge
- Haute disponibilité
- Maintenance facilitée et évolution du parc facilité

Pilotage centralisé
- Pilotage à distance
- Monitoring / réalloc des ressources en un clique
- Moins de compétences requises

Déploiement de masse
1) Infra physique
2) Hyperviseur / Machines virtuelles
3) Pilotage centralisé

**Cloud :** ensemble de VMs (et de machines physiques qui servent uniquement à les faire tourner, pas important)

## IAAS Infrastructure As A Service

Achat d'une infrastructure complète préfaite (tout préinstallé)

### Location de serveurs / ressources à la demande
- Res dispo très rapidement
- Facture liée à l'utilisation
- Mensuelle
- À la seconde / minute
- À la ms
- Achat / Configuration sur internet
- Configuration personnalisable en un clic
- RAM, etc.

### Serveur "dédié" vs cloud
Serveur dédié :

Cloud :

### Avantages
- Permet de gérer le trafic / charge au plus juste (pics de requêtes (heures, etc.))
- Netflix / TV (coupe du monde)
- Tarification au plus juste
- Optimisation en fonction des services hébergés :
- Serveur web : cpu
- Base de données : ram & iops (lecture/écriture)

## Cloud privé / public / hybride

### Privé
bien pour les données sensibles (données étatiques, coordonnées bancaires, dossiers médicaux...)

### Public
on a le contrôle sur le lieu du data center

### Hybride
infrastructure chez le client et cloud public
allocation publique en cas de besoins
données sensibles restent en privé
permet d'assurer un plan de reprise d'activité (PRA) et de continuité d'activité

## PASS Platform As A Service

L'hébergeur gère tout, même l'applicatif

- Aucun contrôle (versions, programme fournis par l'hébergeur)
- OS/Couches basse (géré par l'hébergeur)
- Ajustable (en fonction des besoins)
- Application (gérer le client)
- Mutualisation (ressources rarement garanties)
- Sauvegardes (pas forcément auto)
Mauvaises performances

Très peu coûteux

## SAAS Software As A Service

Une société héberge un logiciel et le propose aux utilisateurs partout dans le monde

Problèmes
- Nombreuses plateformes matérielles
- Pas/peu de standards (packaging, accès au matériel...)
- UX différente selon l'appareil

Application en mode web
- "Un" standard
- Pas d'installation côté client
- Hébergé en interner/distant
- Mise à jour et maintenance facilitée

## Risque du cloud
- SLA (cloud down pendant un temps)
- Disponibilité d'accès
- Sauvegarde et réplication
- Assurer l'archivage et éviter les pertes de données
- Sécurisation des accès aux machines
- Physiques et distant (email/mdp)
- Données "dans le cloud"
- Serveurs et données hors France
- Lock-in
- Temps de réponses
- Limitations de la bande passante, mutualisé
- Impact des pannes
- Confiance dans le prestataire
- Exploitation de VOS données

...
DMZ - Zone Démilitarisée

## Microservices Container / Pods / Docker / K8s

<hr />

## TDs

**[Lien TDs](https://littl.fr/CC-PolytechTours-TD)**

## TD 1
**Objectif :** accompagner une société à faire évoluer et/ou migrer son infrastructure vieillissante vers de nouvelles solutions

**Scénario :** vous venez d’être embauché afin d’auditer puis modifier l’architecture informatique de la société.

Une fois votre audit terminé, vous êtes arrivé à l’infrastructure détaillée ci-dessous


*Le serveur applicatif 1 contient les différents logiciels de gestion : comptable, fournisseurs, stocks, …
Le serveur applicatif 2 contient votre application métier de vente en ligne (ecommerce)
Le serveur de fichiers contient toutes les archives : factures, contrats, …
Tous les switchs sont des switchs 100 Mb/s et le câble est fait en RJ45 de catégorie 5.*

### I - Régler les problèmes de réseau
#### 1) Le personnel se plaint souvent de latence, déconnexions et coupure internet. Identifier dans l’infrastructure réseaux les incohérences pouvant être responsables de ces problèmes.
- Switchs en série sur les postes de travail
- goulot d'étranglement (ceux à la fin on peu de débit)
- La totalité du trafic passe sur un seul switch
- goulot d'étranglement, d'autant plus qu'il a le même débit
- Les switchs ont un débit très faible (100 Mb/s)
- RJ45 de catégorie 5 -> possède un débit plafonné
- Serveur applicatif 2 pas au bon endroit : à mettre à côté de la DB
- DNS trop éloigné des postes

#### 2) Identifier les points critiques et de défaillance dans l’architecture actuelle
- Pas de firewalls
- Les routeurs et switchs ne sont pas dédoublés / point critique si ils tombent en panne

#### 3) Quels sont les différents problèmes de sécurité dans cette topologie
- Pare-feu
- Quid de l'accès par internet au site et du DNS
- Sous-réseau / isolation des responsabilités

#### 4) Proposer une nouvelle architecture solutionnant ces divers problèmes

<div style="display: flex;">
<img src="https://i.imgur.com/daAsmKX.png" alt="partie 1" />
<img src="https://i.imgur.com/3RCxgWH.png" alt="partie 2" />
</div>

En bas au centre : Wi-Fi (il y en a deux)
En bas à gauche : postes de travail

### II - Migration dans le cloud
Le local technique étant vieillissant tout comme les machines, les normes de sécurité n’étant pas respectées : incendie, onduleur, … la société réfléchie à externaliser ses services dans le cloud le tout en haute disponibilité.

#### 1) Identifier les serveurs / parties devant absolument rester dans la société
- Serveur d'impression
- Serveur app 1
- DNS
- Wi-Fi
- Postes de travail
- (Serveur de fichiers -> + sécurité)
- Attention au feu / redondance

#### 2) Identifier les serveurs pouvant être migré
- Serveur de messagerie
- Serveur de fichiers
- Attention débit internet
- Confiance envers le prestataire
- Serveur app 2
- DB

#### 3) Identifier les services qui peuvent être migré en mode SAAS
- Serveur app 2
- DB
- Serveur de fichiers
- (Postes de travail -> Besoin du dernier matériel || meilleure évolutivité)
- Quid coupure internet
- Fermeture du service
- Evolutivité

#### 4) Réaliser un schéma récapitulatif de l’architecture pouvant être mise en place
On enlève juste les parties correspondant aux services externalisés dans le schéma du I - 4)

#### 5) Quels sont les “nouveaux” risques suite à la mise en place de cette nouvelle infrastructure
- SAAS
- dépendant du service externe : Google Drive
- localisation de vos données
- ordinateurs à distance :
- coupure interne (indisponibilé) : plus de travail possible
- fuite de donnée / piratage
- SLA
- assurances perte de chiffres covid : coût vs théorie

#### 6) Que pouvons nous faire pour mitiger ces risques
- payer plus cher => SLA plus
- double internet
- plusieurs fournisseur pour le cloud / répartir sur plusieurs datacenter

### III - Externalisation
La société envisage d’utiliser un prestataire externe pour la gestion de ses mails.

#### 1) Quels sont les avantages d’une messagerie en mode SAAS
- Gère très bien le spam
- Mettre un serveur mail : extrèmement compliqué spam & respecter les “bonnes pratiques” => taux de réception

#### 2) Et les inconvénients ?
- Dépendant

#### 3) Dans le cas ou la gestion de la messagerie resterai en interne, quelle type d’architecture faudrait-t-il envisager ?