Fièrement canadien 
Trafic et couche applicative
Répartissez la charge entre services ou nœuds lorsqu’une seule instance ne suffit pas.
- Répartition de charge
- Nœuds applicatifs redondants
- Mise à l’échelle horizontale
- Vérifications de santé et routage
Hébergement complexe
Grappes, haute disponibilité et infrastructure sur mesure à plusieurs serveurs.
Lorsqu’un serveur ne suffit plus, Gotekky définit la topologie selon le trafic, les dépendances de données, l’impact des pannes et la reprise plutôt que de simplement vendre une machine plus grosse.
Exemple d’architecture
Pourquoi l’hébergement complexe commence par la topologie
Lorsqu’une charge comprend plusieurs composants, ajouter simplement du CPU ou un autre serveur ne constitue pas une architecture. Le trafic, les données et les domaines de panne doivent être conçus ensemble.
Un exemple de topologie à plusieurs serveurs
La vraie conception part de l’application et des exigences de panne. Cet exemple montre pourquoi l’hébergement complexe est un service d’architecture plutôt qu’un forfait serveur fixe.
Utilisateurs et applicationsTrafic entrant
→
Couche de répartitionDistribue le trafic
Nœud applicatif ACharge de production
Nœud applicatif BCapacité redondante
→
Base principaleDonnées applicatives
Réplique ou copie de repriseRôle selon la conception
Sauvegardes indépendantesCouche de reprise
Illustration seulement. La topologie, la redondance et la reprise réelles sont définies dans la proposition et peuvent être plus simples ou plus complexes.
Infrastructure au-delà d’un serveur
L’hébergement complexe est construit selon la charge, l’objectif de disponibilité et les exigences de reprise.
Couche de données
Séparez ou répliquez les services de données selon la cohérence, la performance et la reprise.
- Services de base dédiés
- Modèles principal et réplique
- Réplication
- Architecture de stockage
Reprise et continuité
Concevez pour la panne qui compte pour l’organisation, pas seulement pour le fonctionnement normal.
- Sauvegardes indépendantes
- Planification du basculement
- Environnements de reprise
- Options multi-emplacements lorsque pertinent
Questions de conception
La haute disponibilité est une propriété de conception, pas une case à cocher
Une conception fiable examine les dépendances partagées, le temps d’arrêt acceptable, la perte de données tolérable et la personne responsable lorsqu’un composant tombe.
Qu’est-ce qui peut tomber ensemble?
Deux serveurs applicatifs qui dépendent du même composant peuvent encore partager la même panne. La redondance aide seulement lorsque les domaines de panne sont compris.
Quoi restaurer, et à quelle vitesse?
Les sauvegardes, répliques et basculements règlent des problèmes différents. La conception doit correspondre au chemin de reprise acceptable.
Qui prend les incidents en charge?
La plateforme peut être livrée comme infrastructure seulement ou jumelée à la gestion d’infrastructure pour une responsabilité opérationnelle continue.
Apportez-nous le besoin, pas une liste de serveurs.
Indiquez ce qui doit rester disponible, les dépendances, l’interruption acceptable et le résultat attendu de la reprise. Nous pouvons transformer cela en proposition d’architecture.
Exemples de charges qui peuvent nécessiter un hébergement complexe
Le déclencheur est habituellement la complexité de l’architecture ou l’impact d’une panne plutôt qu’un nombre précis de visiteurs.
Commerce essentiel aux revenus
Boutiques et systèmes transactionnels pour lesquels une panne d’infrastructure unique créerait une interruption inacceptable.
- Couche applicative redondante
- Planification des données
- Conception de reprise et sauvegarde
Plateformes applicatives sur mesure
Applications avec API, travailleurs, bases de données, services internes ou autres composants à séparer.
- Ressources par service
- Réseau privé
- Gestion des changements et capacité
Croissance au-delà d’un serveur
Systèmes qui ont dépassé la mise à l’échelle verticale ou qui nécessitent une progression délibérée vers la redondance.
- Topologie à plusieurs serveurs
- Répartition de la charge
- Modèle documenté de panne et reprise
Responsabilités claires
L’hébergement complexe définit la plateforme. La gestion définit qui l’exploite.
Le projet peut comprendre
- Architecture et composants définis dans la proposition
- Mise en service et interconnexion de la plateforme
- Capacité et redondance choisies selon la charge
- Hypothèses et limites d’infrastructure documentées
La responsabilité continue peut ajouter
- Gestion d’infrastructure pour l’environnement multi-serveurs
- Gestion de site pour la couche applicative approuvée
- Courriel géré lorsque le courriel fait partie de la solution
- Projets de changement distincts hors du mandat récurrent
FAQ
Questions fréquentes
Qu’est-ce qui constitue un hébergement complexe?
Une charge qui nécessite plusieurs serveurs, de la redondance, de la répartition, de la réplication, plusieurs domaines de panne ou une autre topologie sur mesure plutôt qu’un seul compte ou serveur standard.
L’hébergement complexe est-il un forfait fixe?
Non. La topologie correcte dépend de la charge, des exigences de disponibilité, des objectifs de reprise et du budget, donc elle est définie dans une proposition.
La haute disponibilité signifie-t-elle qu’il ne peut jamais y avoir de panne?
Non. La redondance réduit certains risques, mais toute architecture garde des dépendances, des besoins d’entretien et des modes de panne. L’objectif est de concevoir autour des interruptions qui comptent le plus.
Gotekky peut-elle exploiter l’environnement après le déploiement?
Oui. La gestion d’infrastructure peut être ajoutée pour les opérations de plateforme et la gestion de site peut être ajoutée lorsque Gotekky est aussi responsable de l’application.
Services connexes