Les réseaux EC2

Démarrer avec les réseaux EC2

Le lecteur l’aura compris à ce stade du livre, la différence essentielle entre les datacenters classiques et les cloud publics de type AWS c’est que, contrairement aux premiers qui sont constitués d’un certain nombre de commutateurs et routeurs physiques connectés à des interfaces réseau, les derniers font à peu près la même chose en utilisant des serveurs, interfaces réseau, commutateurs et routeurs virtuels. Mais il y a une différence tout aussi importante et moins visible : les réseaux virtuels sont beaucoup plus filtrés que leur équivalent physique.

Qu’est-ce que cela veut dire exactement ? Eh bien, la plupart des clouds publics, AWS compris, ne supportent que les datagrammes de type unicast et rejettent le trafic réseau de type broadcast. Ce détail est essentiel car, comme on le sait, si un trafic de type unicast est simple et sécurisé car il permet le transfert des paquets réseau d’une adresse source vers une adresse destination unique, le trafic de type broadcast permet à cette même adresse source de diffuser des paquets vers tout un sous-réseau. On comprend donc aisément les risques de sécurité auxquels le broadcast peut exposer une organisation, notamment les risques d’attaques DDoS (Distributed Denial of Service).

Pourtant, il existe de nombreux cas de figure où les services que nous déployons ont besoin d’effectuer des opérations de recherches, ou de découvrir d’autres services homologues et, pour ce faire, d’utiliser le broadcasting. Il est donc très important de comprendre dès le départ que la place de ce genre d’applications et services n’est pas dans le cloud public et nous allons ainsi examiner des solutions dédiées à ce cas de figure. Mais pour l’instant, intéressons-nous aux bases des réseaux EC2.

Pour commencer, on a vu qu’une instance EC2 est munie de deux adresses IP : une adresse privée et une adresse publique. Ce principe de fonctionnement est implicite et automatique, et il n’y a rien que nous puissions faire pour changer ce comportement. Les deux adresses IP sont de type DHCP (Dynamic Host Configuration Protocol). Cela...

Le répartiteur de charges

Le répartiteur de charges (ELB - Elastic Load Balancing) est un service AWS qui vous permet de distribuer le trafic réseau entrant à travers votre flotte d’instances EC2. Ce service agit comme un point de contact unique entre ces instances EC2 et leurs consommateurs. Un consommateur, ou un client, envoie des requêtes aux services et applications déployées sur vos instances EC2 à travers des ELB. C’est l’ELB qui décide quelle sera l’instance EC2 qui servira ces requêtes, en fonction de différents critères comme, par exemple, la charge de travail de chacune, etc. Ainsi, on peut faire face à des montées en charge simplement en ajoutant des instances EC2 sans avoir à se préoccuper ni du routage, ni de la répartition des charges, car c’est l’ELB qui s’en occupe.

Associé à la fonction d’Auto Scaling qui sera présentée un peu plus loin dans ce chapitre, l’ELB fournit un environnement de production résilient et tolérant aux pannes, de haute disponibilité et fiable. Voyons concrètement comment les choses se passent en pratique.

L’Auto Scaling

Après avoir examiné en détail tout ce qu’il y a à savoir au sujet des adresses IP et des réseaux EC2, nous allons aborder un des concepts les plus remarquables du cloud AWS, concept connu sous le nom de Auto Scaling. On pourrait traduire ce terme par "mise à l’échelle automatique", mais nous avons décidé de l’utiliser tel quel.

AWS a été le premier cloud public à proposer cette fonctionnalité d’une incroyable puissance qui est devenue actuellement un élément incontournable de toute infrastructure.

Le concept de base de l’Auto Scaling est assez simple : il permet d’augmenter ou de diminuer la capacité de calcul d’une infrastructure en fonction de certaines conditions ou de certaines règles. Ces règles peuvent être très simples, comme par exemple un nombre fixe d’instances EC2 à tout moment, ou alors plus complexes, comme le pourcentage d’utilisation du CPU, de la mémoire, etc.

Mais tout d’abord, pourquoi l’Auto Scaling est-il nécessaire pour une infrastructure réseau ? Pourquoi une démarche classique, basée sur une capacité fixe, n’est-elle pas suffisante ? Eh bien, parce que les exigences de montées en charge auxquelles nos applications et services peuvent être soumis sont imprédictibles. En outre, il n’existe pas de méthode pour garantir une planification juste des ressources pour des exigences de performances inattendues, on finit fatalement par provisionner plus de ressources que nécessaire, tout en prenant le risque qu’à certains moments, les ressources allouées ne soient pas suffisantes. Ainsi, il y aura parfois du gaspillage de ressources, car allouées sans que cela soit nécessaire, et des moments où elles ne pourront pas faire face aux exigences de performance par manque d’anticipation.

Tous ces facteurs ont une influence négative sur le business des organisations et sur les coûts de production, d’où l’intérêt de l’Auto Scaling qui offre les avantages suivants :