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:
> 1) de 100% (la majorité des utilisateurs n'aillant pas eu de downtime)
> 2) 90% (le service est up seulement si toutes les zones sont up)
> 3) 990/1000 (soit 99% en faisant un prorata sur le nombre de zone)
> 4) 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).

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à