Kinsta ne propose pas d’hébergement haute disponibilité (HA), mais nous offrons une garantie de temps de fonctionnement soutenue par un SLA. Chez Kinsta, chaque site sur notre plateforme fonctionne dans un seul conteneur Linux et la base de données du site fonctionne comme un service dans le conteneur du site. Nous n’exécutons pas plusieurs instances d’équilibrage de charge pour chaque site. En savoir plus sur l’architecture de Kinsta.

Grâce à la flexibilité offerte par l’utilisation d’une infrastructure basée sur des conteneurs, la gestion proactive de la charge par notre équipe d’ingénierie et l’utilisation d’un fournisseur de cloud computing de premier ordre dans Google Cloud Platform, nous sommes en mesure d’offrir une solution de cloud computing de premier plan. Disponibilité de 99,9% garantie par SLA.

Circonstances qui bloquent la surveillance du temps de disponibilité

Afin d’assurer le respect de notre garantie de temps de disponibilité, nous surveillons chaque site sur notre plateforme pour vérifier le temps de disponibilité. Lorsqu’un de nos moniteurs de temps de disponibilité ne fonctionne pas, nos ingénieurs réagissent immédiatement et s’efforcent de rétablir le service sur le site. Cependant, il y a quelques scénarios où notre capacité à surveiller le temps de disponibilité peut être limitée :

  • Si l’authentification de base est activée, cela servira une erreur 401 à toutes les requêtes non autorisées.
  • Le mode « I’m Under Attack » de Cloudflare a un temps d’attente de 5 secondes pour prévenir les attaques DDoS. Ceci ne s’applique pas aux requêtes HEAD car celles-ci répondront par une Erreur 503.
  • Les sites de proxy inversé dont le domaine principal ne redirige pas vers l’URL cible.
  • Certains cas de mise en cache personnalisée peuvent causer des problèmes. Par exemple, si vous mettez en cache la requête HEAD de la chaîne de requête de Kinsta. Les services proxy tels que Sucuri et Cloudflare peuvent aussi parfois causer des problèmes de mise en cache en fonction de la configuration.
  • Service de blocage des robot : Notre moniteur de temps de fonctionnement utilise le kinsta-bot comme un user-agent, donc si vous le bloquez avec une extension ou un service (user-agent deny), cela peut provoquer l’échec de notre surveillance de temps de fonctionnement (ceci se traduit généralement par un code d’erreur 406).
  • Le blocage de l’adresse IP ou du pays d’origine (Geo-block) de notre moniteur de temps de disponibilité aura un impact sur notre surveillance. Si vous configurez ces fonctionnalités sur les serveurs de Kinsta, ce n’est pas un problème puisque nous ajoutons des exceptions.
  • Si le domaine primaire ne résout pas l’installation où il a été ajouté ou s’il a une redirection vers un autre domaine (listé dans la liste des domaines du même site).
  • Lorsqu’un site est en mode maintenance, il peut renvoyer une erreur 503.