Lab 06 : Utilisation de Load Balancers

Objectifs

Dans cet atelier, nous allons manipulez les répartiteurs de charge (Load balancer) fournis par le Cloud 3DS OUTSCALE.

Introduction

3DS OUTSCALE propose des solutions de load balancing pour répartir le trafic entre plusieurs instances de serveurs. Un load balancer OUTSCALE peut être utilisé pour améliorer la disponibilité et la fiabilité de vos applications en répartissant le trafic entrant entre plusieurs instances de serveurs.

Un load balancer OUTSCALE peut être soit relié à internet, soit interne :

Load balancer relié à internet : Il peut être créé dans différentes zones de disponibilité (AZ) ou sous-réseaux et distribuer le trafic vers n’importe quelle AZ de sa région ou sous-réseau. Ce type de load balancer est conçu pour gérer le trafic provenant d’Internet et le répartir entre vos instances de serveurs.
Load balancer interne : Il est utilisé pour répartir le trafic entre les instances de serveurs au sein d’un réseau privé, comme un réseau d’entreprise ou un réseau virtuel privé (VPC).

Chaque load balancer doit être créé avec un listener pour pouvoir recevoir des requêtes. Un listener correspond au processus qui traite les requêtes arrivant au load balancer depuis internet ou depuis votre réseau privé, configuré avec un protocole et un port, avec un port compris entre 1 et 65535 tous deux inclus.

Il est recommandé de créer un load balancer par service pour éviter toute défaillance non détectée.

Pour tester le service, nous utiliserons deux instances et un load balancer relié à internet.

Création des 2 serveurs web et du bastion

Lancez deux instances avec les exigences suivantes :

Créez une paire de clés.
Créez une IP Publique.
Créez un VPC avec un range IP : 10.0.0.0/16
Créez un subnet pub en 10.0.1.0/24 dans l’az eu-west-2a
Créez un subnet priv-a en 10.0.2.0/24 dans l’az eu-west-2a
Créez un subnet priv-b en 10.0.3.0/24 dans l’az eu-west-2b
Créez une Internet Services et liez-la au VPC
Créez une route table
Lié la route table au subnet pub
Ajoutez la route entre l’Internet Service et le CIDR 0.0.0.0/0 à la table de routage créée précédemment
Créez une IP Publique
Créez une Nat Services liée à l’IP publique et au subnet pub
Créez deux routes pour les subnet privées
Ajoutez la route entre la Nat Service et le CIDR 0.0.0.0/0 aux tables de routes créées auparavant

Lancer une instance de serveur Web dans chacune des zones avec les caractéristiques suivantes :

Image Ubuntu 22.04.
Type d’instance : choisissez-en une qui possède 1 processeur virtuel et 1 Gio de mémoire.
Associez les deux instances à deux subnets différents dans des AZ différentes.
Ajouter le script dans la partie cloud-init :

#!/bin/bash
apt-get update
apt-get install -y apache2 php libapache2-mod-php
mv /var/www/html/index.html /var/www/html/index1.html
cat > /var/www/html/index.php << END
<?php
    //header('Content-Type: text/plain');
    session_start();
    setcookie("outscale","lab" );
?>
<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
        <title>Simple PHP App</title>
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <link href="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
        <style>body {margin-top: 40px; background-color: #333;}</style>
        <!--[if lt IE 9]><script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
    </head>
    <body>
        <div class="container">
            <div class="jumbotron">
                <h1>Simple PHP App</h1>
                <h2>Congratulations!</h2>
                <ul>
                    <li>Your PHP application is now running on the host “<?php echo gethostname(); ?></li>
                    <li>This host is running PHP version <?php echo phpversion(); ?>.</li>
                    <li><?php echo "Server IP: ".\$_SERVER['SERVER_ADDR']; ?></li>
                    <li><?php echo "Client IP: ".\$_SERVER['REMOTE_ADDR']; ?></li>
                    <li><?php echo "X-Forwarded-for: ".\$_SERVER['HTTP_X_FORWARDED_FOR']; ?></li>
                    <?php
                        if(!isset(\$_SESSION['visit']))
                        {
                            echo "<li> This is the first time you're visiting this server </li>";
                            \$_SESSION['visit'] = 0;
                        }
                        else
                        {
                            echo " <li>Your number of visits: ".\$_SESSION['visit']."</li>";
                        }
                        \$_SESSION['visit']++;
                        foreach(\$_COOKIE as \$key=>\$value)
                        {
                            echo "<li>".\$key. " => " .\$value. "</li>";
                        }
                    ?>
                </ul>
            </div>
        </div>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.7/js/bootstrap.min.js"></script>
    </body>
</html>
END

Lancer une instance dans le subnet publique avec une ip publique avec 1 proc et 1Go de RAM avec la même image Ubuntu 22.04 (se sera votre bastion)
Créez un Security Group autorisant le flux ssh depuis votre IP et attachez le à la vm publique
Créez un Security Group autorisant le flux ssh depuis le subnet 10.0.0.0/16 et attachez le aux deux vm privées
Connectez-vous en ssh sur les machines en passant par l’ip publique du bastion

Création du load balancer relié à internet dans un VPC

Nous allons créer les security groups et un load balancer relié à internet pour distribuer le trafic réseau entrant venant d’internet et pour le redistribuer vers les deux instances créées précédemment :

Création des security Groups

Créez un security group pour le load balancer avec les règles suivantes :
- Autorisez les flux entrants en protocole TCP sur le port 80.
Modifiez le security group des instances back-ends avec la règle suivante :
- Autorisez les flux entrants en protocole TCP sur le port 80 depuis le cidr 10.0.0.0/16.

Création du load balancer

❗IMPORTANT

Pour ces étapes, utilisez la CLI OSC en vous aidant du lab05 et de la documentation de l’API !

Créez le load balancer avec les caractéristiques suivantes :
- De type internet-facing.
- Utilisant le protocole de routage HTTP et le port 80.
- Utilisant le protocole d’écoute HTTP sur le backend routage et le port 80.

Enregistrement des instances de backend auprès d’un load balancer

Lier les instances de backend au load balancer

Validation du lab

Attendez que le load balancer détecte que vos instances sont en bonne santé. Cela peut prendre quelques minutes.

Une fois que vos instances sont considérées comme saines, vous pouvez tester le load balancer en accédant à son IP publique depuis votre navigateur web. Vous devriez voir la page d’accueil de l’un de vos serveurs web. Si vous actualisez la page, vous devriez voir la page d’accueil de l’autre serveur web, car le load balancer répartit le trafic entre les deux instances.

Challenge Les sessions persistantes

Le mécanisme de sticky session, également appelé session affinity, permet de maintenir la persistance des sessions utilisateur sur une instance spécifique de serveur. Cela signifie que toutes les requêtes d’un utilisateur seront dirigées vers la même instance de serveur pendant la durée de la session. Ce mécanisme est utile pour les applications qui stockent des informations sur l’état de la session côté serveur.

Pour créer une politique de sessions persistantes reposant sur une durée, utilisez OSC CLI.

Attention, il ne faut pas oublier d’activer la sticky session sur le load balancer. Plus d’informations sur la documentation.