La « scalabilité » (en français l’extensibilité voire « croissance » pour certains auteurs) d’un serveur est sa propension à pourvoir augmenter les ressources physiques de l’ensemble du système de façon à faire face à une charge accrue ou bien permettre une répartition de charge. Par exemple en matière de serveur web, ajouter des machines en parallèle permet rapidement et à peu de frais d’augmenter la surface d’attaque globale du système. Il n’en va pas de même en matière de serveur de bases de données, du fait des données ! Petites explications…

La « scalabilité » (en anglais scalability) répond en fait à la problématique de montée en charge, mais pas de tolérance à la panne (haute disponibilité), bien qu’il soit dans un certains nombre de cas possible de faire les deux.
Sa définition précise est la suivcante :
Aptitude d’un système à maintenir un même niveau de performance face à l’augmentation de charge ou de volumétrie, par augmentation des ressources matérielle et sans impact global sur le système (par exemple sans nécessité de modifier les applications hébergées par les machines).

1 – les deux voies de la « scalabilité »

Il existe deux manière de réaliser une extension à un système existant : la scalabilité horizontale (dite externe) et la scalabilité verticale (dite interne).

La scalabilité horizontale consiste à rajouter en parallèle des machines supplémentaires. C’est pourquoi on parle de croissance externe. On part d’une machine et on rajoute au fur et à mesure de l’augmentation de la charge de nouvelles machines identiques.
Avantages :

• On ne paye que les machine au fur et à mesure.
• La panne d’une machine ne pénalise pas le système (tolérance à la panne)
• Le système est globalement plus flexible
• La mise à jour sans interruption de service est possible

Inconvénients :

• Il faut trouver un moyen de répartir les demandes (une application particulière doit gérer la répartition de charge en envoyant la demande au serveur le moins occupé à l’instant t).
• Il faut payer des licences pour chaque machine
• L’administration de n serveur consomme n fois plus de temps (sauf à disposer d’un outil spécifique de gestion multi serveur…)
• sur le long terme des machines identiques ne sont plus commercialisées.

Avant mise en place du « scale out » (croissance externe….) :

Après mise en place du « scale out » :

La scalabilité verticale consiste à rajouter des ressources supplémentaire à la machine (CPU, RAM, disque carte réseau…). C’est pourquoi on parle de croissance interne. On part d’une machine conçue pour évoluer et on rajoute au fur et à mesure de l’augmentation de la charge des ressources spécifiques.
Avantages :

• Aucun outil de répartition de charge n’est à ajouter.
• Une seule licence à payer.
• Une administration simplifiée et moins couteuse.
• Même si sur le long terme les ressources matérielle peuvent devenir obsolète, il est plus facile de transférer un seul serveur qu’une multitude.

Inconvénients :

• Il n’y a pas de tolérance à la panne
• On paye cher la machine de départ.
• Le système est moins flexible
• La mise à jour sans interruption de service n’est pas possible

Avant mise en place du « scale up » (croissance interne) :

Après mise en place du « scale up » :

… et encore plus longtemps après :

2 – Scale Up, Scale Out… quelles différences ?

Au fond on pourrait croire que les deux techniques sont interchangeables… Il n’en est rien. En effet la différence essentielle tient à l’existence (ou bien à l’absence) de tout ce qui constitue les éléments à partager. Dans un environnement multiprocessus, un espace mémoire partagé peut être utilisé et adressé par tous. Dans un environnement distribué, il en va tout autrement. Il faut trouver le moyen de synchroniser la présence des éléments à partager sur chacune des machines. Il y a donc nécessité de rajouter un mécanisme de communication entre les différentes machines et plus on tend vers la présence synchrone des éléments partagés, plus ce mécanisme devient couteux.

Prenons pas exemple le cas du site web « passif », c’est à dire sans tenir compte des données dynamiques qui pourrait figurer dans une base. Si l’on met à jour le code et les fichiers dudit site web une fois par jour, un simple FTP permettrais d’envoyer à toutes les machines les nouveaux éléments partagés. Ceci est donc totalement asynchrone et à faible fréquence. Pour l’utilisateur authentifié il en va tout autrement. Il faut trouver un moyen pour informer tous les serveurs de l’état dans lequel se trouve sa connexion. Certes le volume des données à communiquer n’est pas très important mais multiplier par le nombre de serveur, cela peut écrouler à terme le système !

Prenons maintenant le cas de la base de données qui effectuerais par exemple 1000 transactions par minutes, concernant chacune environ 2 Ko de données. Répartissons là sur 10 serveur, c’est déjà 300 Ko par seconde de communications à envoyer entre les différentes machines. De plus il faut gérer l’intégrité des données, la cohérence et la disponibilité (par exemple telle donnée sur tel serveur est actuellement verrouillée par une autre transactions). Le système devient alors vite incapable de prendre en charge un tel trafic et s’écroule très rapidement !

Enfin, et du fait de la charge induite par le a communication entre les nœuds, le gain entre scale-up et scale-out n’est pas linéaire. Ainsi en en passant du scale-up au scale-out, on observe une baisse significative des temps de réponse, car soudainement ce nœud doit gérer le réseau, les transactions, la duplication des données, toutes tâches qui incombaient auparavant à la seule machine et qui était traitée de manière interne.
Mais il existe un moyen de réduire ce coût, en concevant son application de manière distribuée. Pour une application, ce sera par exemple à base de services. Pour une base de données, ce sera à l’aide des mécanismes spécifique du serveur (RAC pour Oracle ou Service Broker pour MS SQL Server) tant est si bien qu’il faudra sans doute réécrire entièrement l’application puisque le modèle de programmation diffère radicalement entre les 2 modes.

3 – Résumons…

De manière général, les SGBDR ne peuvent que difficilement reproduire les mécanismes de répartition de charge des serveurs Web, et cela pour une raison toute simple : il faudrait que les données soient simultanément présente sur tous les serveur. Autrement dit une insertion d’une ligne dans une table doit être envoyé à tous les serveurs. C’est pourquoi il est fortement déconseillé dans la plupart des cas de faire du scale out pour les SDGBR ! Il faut donc veiller dès le départ à acheter un serveur fortement évolutif…

Quelques références :
Scalabilité, le choix des armes
Scalabilité verticale ou scalabilité horizontale ?

PS : j’ai emprunté quelques phrases a ce dernier et excellent article qui présente clairement les choses.
Photos : serveurs HP

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *