Disponibilité et fiabilité des services et des systèmes

Transcription

1 Disponibilité et fiabilité des services et des systèmes Anthony Busson Introduction Un site Web commercial perd de l argent lorsque leur site n est plus disponible L activité d une entreprise peut être ralentit ou interrompu à cause de la défaillance d un serveur (mail, serveur d applications, etc.) La disponibilité d un système est un des critères de QoS les plus importants Les systèmes sont de plus en plus complexe. Il est de plus en plus difficile d évaluer et de garantir une disponibilité. Un site Web fait intervenir Les routeurs, les switchs Les firewall, le réseau de l opérateur Le DNS Un équipement effectuant le partage de charge Les serveurs Le réseau électrique 1

2 Disponibilité : Définition Pourcentage de temps durant lequel le système est opérationnel. Il suppose en générale une alternance de phases durant lequel le système fonctionne et de phases durant lequel il ne fonctionne pas. Cela peut être dû à des pannes (temporaire) à des pannes de courant à des interruptions de service (redémarrage du service pour prendre en compte une nouvelle configuration) à un plantage du système d exploitation à des «reboot» périodique à une charge trop élevée sur le système Exemple : La disponibilité du réseau est une des métriques de QoS qui est négocié dans le SLA avec l opérateur. Disponibilité : exemple Les valeurs courantes de disponibilité sont données dans le tableau suivant : Disponibilité 90.0% 99.0% 99.9% 99.99% % % % Indisponibilité (min/an) min (36,5 jours) min (3, 65 jours) 526 min (9 heures) 52,6 min 5,26 min 0,53 min (31 secondes) 0,053min (3 secondes) Commentaires Pas de service Service fournit Bon niveau de service Tolérant aux pannes Hautement disponible Très hautement disponible Ultra disponible 2

3 Calcul de la disponibilité MTTF : Mean Time To Failure MTTR : Mean Time To Recover MTBF : Mean Time Between Failures Availability = MTTF/MTBF up down time MTTF MTBF MTTR Exemple : Soit un serveur web qui est rebooté tous les 20 jours en moyenne. Le redémarrage du serveur prend 10 minutes. Quelle est la disponibilité du serveur? 3

4 Disponibilité : exemple d architecture redondante La disponibilité est grandement améliorer par la mise en place de mécanisme redondant (une alimentation redondante est très courante sur les gros routeur). Les différents modules réseau peuvent également être redondant. Dans ce cas, on préconise un partage de charge. Des changements à chaud sont également possibles. NB: les éléments hardware de Cisco ont une MTTF minimum de heures. Routeur Cisco Disponibilité : exemple réseau Éviter les points sensibles : une topologie en étoile. Éviter que la perte d un élément entraîne celle du réseau. 4

5 Fiabilité : Définition La fiabilité d un système est la probabilité que le système fonctionne normalement durant une certaine période de temps (sans interruptions). Cela peut être vu comme la probabilité que les système fonctionne quand nécessaire. La période n est pas fixée et varie suivant les systèmes considérées Un serveur web n a pas besoin de fonctionner 10 ans sans interruption avec une très grande probabilité Une centrale nucléaire si. Généralement, on obtiens la fiabilité d un composant via des tests (qui peuvent être accéléré). Fiabilité pour une série de composantes (1) Si on cherche la fiabilité d un système composé de plusieurs composants en série, on a : r 1 r 2 r 3 r 4 Fiabilitédu système= Πr n i= 1 L utilisation des composantes en série ne signifie pas que les composantes soient visitées dans un ordre particulier ou une seule fois. Cela signifie que l ensemble des composantes doivent fonctionner pour que le système fonctionne. i 5

6 Fiabilité pour une série de composantes (2) Soit un service faisant intervenir un firewall, un switch, un serveur et une base de données r=0,99 r=0,75 r=0,95 r=0,32 Calculer la fiabilité du système. Fiabilité pour des composantes en parallèle (1) Le système reste fiable tant que toutes les composantes en parallèle ne sont pas indisponibles r 1 r 2 r 3 Quelle est la fiabilité? 6

7 Fiabilité pour des composantes en parallèle (2) On suppose que l on a un système composé d un webswitch qui partage la charge entre 3 serveurs Web. Quelle est la fiabilité des 3 serveurs et quelle est la fiabilité du système? r=0,95 r=0,7 r=0,75 r=0,32 Fiabilité pour des composantes en parallèle (3) r=0,25 r=0,25 r=0,25 Fiabilité 1 0,8 0,6 0,4 0,2 0 Faibilité du système en fonction du nombre de composantes en parallèles Nombre de composantes en parallèles r=0,25 r=0,5 r=0,7 7

8 Exercice On souhaite installer un cluster de serveurs web. On a choisit des serveurs pas chères ayant une fiabilité de 85%. On souhaite avoir pour le système une fiabilité de 99.99%. Quel doit être le nombre de serveurs? r=0,85 r=0,85 r=0,85 Benchmark Etalon de test Anthony Busson 8

9 Benchmark Benchmark : exécuter un ensemble de tests bien définis afin de comparer différents systèmes. Les résultats des tests opérés sur différents systèmes ne sont comparables que si les conditions de tests sont rigoureusement identiques. <? Il est souvent utile à titre de comparaisons mais ne permet pas a priori de déduire le comportement du système dans le cadre de son exploitation futur. La granularité des benchmarks Applications Noyaux «Jeux» Opérations de bases Système Performances du système 9

10 Opérations de bases On cherche à estimer la vitesse du système (ici le CPU) en lui faisant opérer des opérations extrêmement basiques. Dhrystone : regroupe un ensemble d opérations types (essentiellement numérique) utilisée généralement par les applications. Calculs sur les entiers Décisions logiques Opérations sur les chaînes de caractères Whetstone : calcul sur les flottants Jeux Faire exécuter au système des jeux Tour de Hanoi : faire passer tous les palets de la tour de gauche à celle de droite. Un palet à la fois peut être déplacé d une tour à l autre. Mais on ne peut pas poser un palet sur un palet plus petit. Sieve of Eratosthenes (Crible d Eratosthene) : recherche des nombres premiers entre 1 et un entier fixé N. 10

11 Noyaux Exécution de codes extrait de programmes réelles Livermore Loops: extrait de code pour la simulation physique. Linpack: analyses et résolutions d équations linéaires Applications Applications réelles Compilateur Transactions banquière (débit, crédit) Transactions Web Mail Etc. Exemples: SPEC TPC 11

12 SPEC ( SPEC : Standard Performance Evaluation Corporation Regroupe un ensemble d industrielle de l informatique. Ils développent et standardisent des tests (benchmarks) dont ils publient les résultats. SPEC mail 2009 SPEC web 2009 SPEC SIP 2011 SPEC WEB 2009 (1) Il mesure le nombre de connexions simultanées supportées par un serveur Web Les temps de réponses aux requêtes doivent être en dessous d une certaine durée On mesure le nombre de requête qui vérifie ces durées (et d autres paramètres de QoS). La consommation énergétique du serveur est également évaluée. Il n est plus possible de faire un seul type de tests contenus des différences majeures qui existent suivant les types de sites hébergés. Il y a 3 types de test E-commerce Banking Support Les types de fichiers, leur taille, leur popularité sont obtenues après l analyse des logs de site existant. 12

13 SPEC WEB 2009 : e-commerce 3 phases Browse (affichage de base - cookie type de produit) Customisation (pages dynamiques) Achat (gestion du panier, paiement) Pour chaque client, on utilise une chaîne de Markov pour déterminer les passages d une étape à une autre: SPEC WEB 2009 (2) Banking: Émulation d un site bancaire Toutes les transferts sont en SSL Support: Émulation d un site de mise à jour de logiciel/pilote/se. Téléchargement non sécurisé de gros fichiers. 13

14 Exemple: HP ProLiant DL370 G6 SPEC MAIL 2009 et SPEC SIP 2011 SPEC MAIL 2009 Tests de serveur Mail SMTP-IMAP4-TLS Critères de performances Débit (nombre de requêtes accomplies par seconde) sous des contraintes (temps de réponse, taux d erreurs) Charge importante (environ utilisateurs). Mails avec pièces jointe (contenu variant). SPEC SIP 2011 Test d un serveur SIP dans le contexte de la voix sur IP 14

15 TPC : Transaction Processing Performance Council 3 grands types de benchmark TPC-C OLTP - On-Line Transaction Processing (passer des commandes, enregistrer de paiements, consultations des commandes et des stocks). Mesures le nombre de transactions que peut traiter un serveur (l application n est pas fixée). Il définit charge (nombre de transactions par seconde) pour différents types de transactions (intervention d une base de données) Il s agit de pratiquer les test sur le serveur et de prouver (suivant l application) qu ils corresponds aux paramètres du benchmark. TPC-H et TPC-R TPC-H Requêtes nécessitant la consultation de larges volumes de données TPC-R Variation de TPC-H (dans les paramètres du test) 15

16 Benchmark TPC pour le web (1) TPC-W Le test est prévu pour un site qui permet la consultation et la vente de produits en lignes Certaines requêtes sont supposées être sécurisé (SSL) commandes et ventes des produits Il y a un catalogue de produit avec une page html comportant la description et une image (5Ko) Il existe également une base de données avec des informations sur les clients, les transactions bancaires, les produits. Le nombre de produit peut être 1 000, , , ou Benchmark TPC pour le web (2) La charge est définit comme un ensemble d utilisateurs ayant une session sur le serveur. Certaines pages webs sont dynamiques et nécessite la consultation de la base de données ainsi que l enregistrement de nouveaux champs. Visite de la page d accueil Visite de pages statiques Recherches de différents produits Consultations détaillées des fiches produits Commandes Achats Login Catégorie de requête «Browse» Catégorie «order» 16

17 Benchmark TPC pour le web (3) Le système de charge correspond donc à un système fermé avec un nombre d utilisateurs en parallèle et un temps de réflexion entre les requêtes successives. Benchmark TPC pour le web (4) On définit alors 3 types de clients Client 1 : 95% de requêtes de ce type, 5% de requête «order». Ces sessions se caractérisent par un ratio de vente par client de 0,69%. Client 2 : 80% de requête «Browse» et 20% de type «order». Ratio vente/client=1,2%. Client 3 : 50% - 50%. Ratio vente/client=10,18% 17

18 Benchmark TPC pour le web (5) Le première critère de performances est le débit (nombre de requêtes accomplis par seconde) pour les 3 types de clients et en fonction de la taille de la base de données (nombre de produits). Il est nommé WIPS dans les rapports (Web Interactions per Second). Le deuxième critère est le rapport du coût de l infrastructure tester et du débit. Le coût désigne ici le prix du serveur Web, de la base de données pour les aspects à la fois matériels et logiciels. Les équipements réseaux Il n existe pas de consortium définissant des benchmarks utilisée de manière aussi large. Généralement ce sont des études comparatives ponctuels qui sont faites. Les constructeurs procèdent également à leurs propres tests et définissent leurs propres benchmarks pour les équipements réseaux (Cisco par exemple). 18

19 Conclusions sur les benchmarks Idéales pour faire un choix entre différents serveurs/logiciels Il permet de comparer les performances des différents produits et d en choisir un. Ce choix peut être fait en fonction du nombre de connexions simultanées maximum attendu chez l exploitant. Mais Le test est valide uniquement pour une configuration très particulière : serveur, réseau, software, configuration du système d exploitation et du serveur (logiciel) Le test n a pris en compte qu un seul critère de performances (nombre de connexions en parallèle pour le serveur Web par exemple) Les benchmarks ne sont pas effectués sur toutes les combinaisons de serveurs/se/logiciels. Conclusions sur les benchmarks Pertinent pour faire le choix matériel et logiciel d un serveur mais n est pas pertinent pour évaluer son comportement (temps de réponses, utilisation, nombre de clients, etc.) dans son cadre d exploitation. Il n existe pas de benchmarks pour des applications particulières à une entreprise (les applications métiers), à des services peu populaires. 19

20 Test de charges Anthony Busson Introduction Les Benchmarks ne permettent pas de connaître le système dans son environnement d exploitation On émule la charge utilisateur grâce à une plate forme de tests On en déduit les performances du système lors de son exploitation future 20

21 Les différents type de tests Test de charge : voir les performances du système sous les conditions de charge normal Test de montée en charge : augmenter la charge pour en déduire la charge maximale du système en fonction d un taux d erreur d un temps de réponse Test de stress : appliquée la charge maximale sur le système et voir son comportement «Spike Testing» : appliquée une charge anormalement grande durant une courte période de temps afin d analyser les performances du serveur lors de «bursts». Procédure (1) Identification des tâches opérées par les utilisateurs À partir des logs À partir d interview Définition des tâches Identification de la charge Nombre d utilisateurs Nombre de requêtes par seconde Élaboration de plusieurs scénarii Il est impératif que la plate forme de tests soit le plus près possible de son cadre d exploitation. Les injecteurs ne doivent pas se trouver sur les serveurs ni aucune application (hormis les moniteurs) Les injecteurs ne doivent pas être directement connecté aux serveurs : le goulot d étranglement peut être le réseau, l équipement qui fait le partage de charge, etc. 21

22 Procédure (2) Mise en place de la plate-forme de tests Tests Analyse des moniteurs Analyse des résultats Temps de réponse CPU Utilisation mémoire Identification des goulets d étranglements Est-ce que le système répond au critère de QoS fixée (temps de réponse, nombre de connexions en parallèles, nombre de requêtes accomplit par seconde) Si oui, on rentre à la maison (édition d un rapport) Si non, modification matériel ou logiciel du goulet d étranglement et nouvelle série de tests. Matériels Un ou plusieurs injecteurs. Chaque injecteur représente un ensemble de plusieurs utilisateurs virtuels Une console de management qui supervise la campagne de tests et centralise l ensemble des données Émulation d un réseau WAN : utilisation de deux routeurs afin de limiter la bande passante. Les serveurs à tester 22

23 Exemple de plate forme de tests Injecteur Limite de BP pour émuler un WAN RNIS Serveurs à tester Injecteur Console de management Les utilisateurs virtuels On ne peut avoir autant d injecteurs que de futures utilisateurs On regroupe des utilisateurs virtuels sur un même injecteur Un groupe d utilisateurs virtuels définit: Une séquence de requêtes (un comportement) Un think time (qui peut être aléatoire) On peut avoir plusieurs groupes d utilisateurs virtuels sur un même injecteur. 23

24 Les produits Pour les serveurs web Httperf OpenSta JMeter TestMaker LoadSim WebStressTool WAPT LoadRunner Pour les autres types de services: TestMaker LoadRunner Plusieurs type d approches Génération aléatoire des clients Édition de scripts Interface graphique Enregistrement de séquences Hybride Conclusion : Tests de charge Permet de tester l application dans son environnement et sous les conditions de charge futures Elle permet d identifier les goulots d étranglements et de paramétrer le système pour qu il remplisse les critères de performances Ne permet pas de connaître le comportement du système en dehors des conditions de tests Il suppose une bonne connaissance du service testé car il est souvent suivit de proposition d architectures ou de logiciels: Une configuration logiciel Des solutions réseaux Un ou plusieurs serveurs En fonction du coût En fonction de la disponibilité (maintenance) 24

25 Conclusion générale Benchmark : permet de faire un choix à l achat Test de charges : permet de mesurer les performances du système dans son cadre d exploitation Analyse fonctionnelle : complément du test de charge, il permet à partir des mesures de déduire un certain nombre de quantités moyenne (tout n est pas toujours mesurables) Files d attente : permet de mieux comprendre le comportement du système en fonction des paramètres. Il permet un dimensionnement plus fin et donne des quantités qui peuvent ne pas être mesurable lors de tests de charge (la probabilité de perte par exemple). 25