0 0
Read Time:4 Minute, 31 Second

 

hosted exchange

 

Au cours des dernières semaines, j’ai écrit sur le thème des « questions clés aux fournisseurs d’hébergement Exchange », car cela aide les clients à prendre une décision avant de choisir les bons fournisseurs pour leurs services d’hébergement Exchange.

Principales questions à poser avant de choisir votre fournisseur d’hébergement Microsoft Exchange
Pourquoi une vérification de l’infrastructure est importante avant de choisir un fournisseur d’hébergement

Après avoir soigneusement examiné les caractéristiques d’Hosted Exchange et les avantages de votre hébergeur préféré, l’étape suivante pourrait être d’examiner le SLA (Service Level Agreement) qui peut éventuellement garantir un mode de fonctionnement et une structure de support fiables.

Dans le secteur des services informatiques, les deux éléments les plus importants du SLA sont le temps de fonctionnement et la haute disponibilité. Bien que la plupart des fournisseurs de services offrent un temps de disponibilité à partir de 99 %, vous pouvez constater d’énormes différences en termes d’heures/minutes. Par exemple, les valeurs de comparaison suivantes donnent une métrique de temps de fonctionnement avec l’utilisation de systèmes/infrastructures à haute disponibilité :

99,9% ≡ Moins de 43,8 minutes par mois de temps d’arrêt.
99,99% ≡ Moins de 4,38 minutes par mois de temps d’arrêt.
99,999 % ≡ Moins de 0,44 minute par mois d’indisponibilité.

Dans l’exemple ci-dessus, vous pouvez voir que la disponibilité est mesurée en termes de percentile et que cette valeur correspond essentiellement au temps de disponibilité d’une année donnée. En d’autres termes, les serveurs MS Exchange dans l’environnement d’hébergement offrent un véritable mécanisme de disponibilité continue, qui s’accompagne d’un prix plus élevé car ils garantissent le déploiement d’une infrastructure « de pointe » afin d’éliminer les points de défaillance uniques. Cela peut éventuellement compléter le mode de fonctionnement et la structure de support en offrant le luxe de mettre à niveau les applications, d’appliquer des correctifs, de rafraîchir le matériel et d’effectuer d’autres opérations de maintenance sans arrêter les services et les systèmes critiques.

Quoi qu’il en soit, l’accord de niveau de service devient inutile et sans espoir lorsque les hébergeurs ne peuvent pas prévoir de pénalités dans le cas où ils ne respecteraient pas le niveau de service garanti. En outre, si vous traitez avec des revendeurs d’hébergement Exchange de marque privée, il est encore plus important d’examiner de près l’accord de niveau de service.

Quelles mesures devez-vous prendre maintenant ?

Obtenez une copie de l’accord de service de vos hébergeurs sélectionnés et, enfin et surtout, définissez le niveau de conformité et le processus de sanction. Voici quelques domaines clés dans lesquels les clients peuvent s’entendre avec les hébergeurs dans le SLA :

Exigez un rapport mensuel sur les différents niveaux de conformité dont vous avez convenu avec votre hébergeur désigné.
Assurez-vous d’examiner les résultats des temps de fonctionnement et d’arrêt chaque mois à l’aide de rapports.
Examinez le rapport sur les seuils de performance que vous avez fixés dans l’accord (par exemple, connexions lentes, latence du réseau, etc.)
Les politiques et procédures sont appliquées (par exemple, la gestion des incidents, des changements et des problèmes et l’analyse des causes en cas de panne majeure).

En bref, il devrait s’agir d’un rapport d’état complet en temps réel disponible en ligne. Ensuite, établissez un mécanisme où les comptes de crédit sont actifs dans le cas où les fournisseurs de services ne respectent pas les termes de l’accord de niveau de service.

Est-ce suffisant ? Je suppose que non. Comment faire pour que votre SLA soit en bonne santé ? Quels sont les facteurs clés de succès pour obtenir un SLA efficace ? Examinons quelques domaines :

L’exploitation : Quelles peuvent être les meilleures stratégies ?

Bien qu’il existe de nombreuses stratégies, je pense qu’un plan de reprise après sinistre solide et fiable n’a pas son pareil. Alors décidez d’un meilleur plan de sauvegarde ! Je suggère d’opter pour deux types de sauvegarde : Sauvegarde complète et différentielle. Limitez vos sauvegardes complètes à 1 ou 2 fois par semaine car elles prennent plus de temps. La différentielle commence par une sauvegarde complète et s’étend à chaque jour. La sauvegarde différentielle sauvegarde les données depuis la dernière sauvegarde complète.

Désormais, avec l’hébergement Exchange 2007, vous pouvez bénéficier d’une double protection de sauvegarde grâce à la réplication continue en cluster (CCR). CCR est une fonction de haute disponibilité introduite dans le serveur Exchange 2007, qui possède une capacité intégrée de technologie d’expédition et de relecture asynchrone des journaux. La beauté de CCR est qu’elle ne nécessite ni matériel spécial ni stockage partagé. Il élimine le point de défaillance unique et permet de minimiser la fréquence des sauvegardes complètes avec une taille de volume réduite pour les besoins de la sauvegarde. N’est-ce pas formidable ? Oui, car cela permet également de raccourcir l’accord de niveau de service pour le temps de récupération après la première défaillance. Si vous souhaitez en savoir plus, lisez les tutoriels d’Henrik sur le CCR ici. Ci-dessous le diagramme CCR (source : Microsoft)

Mettre en œuvre et être cohérent sur les « meilleures pratiques » de restauration

Il s’agit ici d’un effort supplémentaire, car le fait de pouvoir difficilement restaurer pour la première fois dans une situation d’urgence n’est pas seulement risqué, mais n’est pas non plus considéré comme la meilleure méthode de restauration. Alors, comment pouvons-nous revoir cela ?

Disposez d’une configuration isolée où le fournisseur de services devrait être en mesure de restaurer les données sur une base hebdomadaire.

Un article proposé gratuitement par https://evok.com/fr/hosted-exchange-switzerland/ spécialiste de Hosted Exchange.

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

code