Le 26/06/2012 17:19, Tristan Larouanne a écrit :
Bonjour,
Je souhaitais savoir comment vous calculiez l'uptime d'un site hébergé de façon géolocalisé.
Cas concret, le site www.example.com est hébérgé dans 10 zones géographique, chaque utilisateur étant dirigé sur la zone la plus proche de lui.
La Zone 1 a un uptime de 90%, les autres zones sont à 100% Vous calculez l'uptime comme étant:
- de 100% (la majorité des utilisateurs n'aillant pas eu de downtime)
- 90% (le service est up seulement si toutes les zones sont up)
- 990/1000 (soit 99% en faisant un prorata sur le nombre de zone)
- 9X% (en calculant le pourcentage d'utilisateur sans accès au
service, si la zone europe tombe la nuit, elle a moins de poids qu'en heure de pointe)
Deuxième point: Comment mesurer l'uptime de chaque zone ? Avec mon serveur Nagios je suis sujet à des période de downtime que mes utilisateurs n'ont pas (coupure internet entre la sonde Nagios et le service, mais pas entre l'utilisateur et le service)
Avec des mesure externe comme dotcom-monitor, j'ai aussi des périodes de downtime (particulièrement à Hong-Kong) qui ne remonte ni dans nagios, ni dans Analytics pour la zone concerné (donc plutôt un défaut de sonde).
Tristan. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut,
Normalement on détail dans les rapports de SLA et on fait une moyenne des taux de chaque zone, c'est la pratique que j'ai vu et mis en œuvre chez tous les infogéreurs chez qui je suis passé (grand comme tout petit).
Après clairement les chiffres on peut leur faire dire n'importe quoi, exemple simple dans mes cas j'avais souvent 3 zones max à gérer (Amériques, Europe, Asie). Si tu as 10 zones et qu'une seule est mauvaise cela est lissé lors de la moyenne alors que sur trois zones ça se voit beaucoup plus.
Donc à voir avec le client comment il est intelligent de remonter les informations.
Pour ce qui est des fausses alertes, la meilleure solution que j'ai vue et que j'applique à mon entreprise, c'est de mettre une supervision sur ton archi juste à côté des routeurs des transitaires / peering. Tu en mets autant qu'il y a de point logique dans ton architecture (DC, zone de PCA/PRA, pays, ...). Cela vient en plus de la supervision externe à ton réseau. Mais cela te permet de supprimer les fausses alertes des sondes extérieures.
Ce modèle marche bien entendu pour des SLAs normales. Certains gros clients demandent des engagements sur la disponibilité depuis une liste d'FAI mais là on arrive dans les cas exceptionnels de très grosses structures du CAC pour les clients français qui jouait à cela et qui le payait aussi. Donc à voir sur quel engagement tu es parti mais je pense que si tu sondes de partout avec plein de prestataires différents tu dois pas être loin de cas de SLAs étendues. Dans ce cas faut pondérer la part de marché du FAI qui n'a pas su joindre tes plateformes par rapport à sa part de marché pour évaluer le % de personnes qui n'ont pas pu atteindre les services. Ça se fait, mais ça coûte cher car il faut du personnel pour gérer cela (entre 1 et 2 personnes quasi temps plein).