Une seule architecture pour tous les clients. Les spécificités du cloud (produit de connectivité, service clé, moteur de base de données) relèvent de la configuration, et non d'une refonte complète. C'est ce qui permet de déployer un environnement à partir du code en cinq jours ouvrables.
Lire l'image de haut en bas
- Les utilisateurs et les intégrations accèdent à une seule adresse, erp.<domaine du client>, et atteignent un équilibreur de charge avec un pare-feu applicatif web (WAF) via HTTPS, TLS 1.2 ou supérieur. Il s'agit du seul point d'accès public.
- Au moins trois nœuds de calcul, un par zone de disponibilité, exécutent le service web et l'API, le moteur de publication, l'opérateur ASK, ainsi que les nœuds de calcul et les tâches. La perte d'un nœud ou d'une zone entière entraîne une interruption de service pour les utilisateurs.
- La base de données gérée (moteur et taille au choix du client) dispose d'une sauvegarde synchrone dans une autre zone. En cas de panne de zone, aucune perte n'est constatée : RPO ≈ 0.
- Les documents et les pièces jointes sont stockés dans un système de stockage d'objets versionnés, et non dans la base de données.
- Le trafic sortant transite par NAT vers une liste blanche : banques, fiscalité et facturation électronique, paie, messagerie électronique, moteur d’IA. Rien d’autre.
- Les sauvegardes sont envoyées dans un seul sens vers un coffre-fort isolé du réseau (air-gating) situé sur un compte séparé.
Le point de terminaison privé et l'équilibreur de charge interne sont représentés en pointillés car ils n'existent que lors de l'utilisation d'un accès privé. Ils ne sont pas créés avec un accès HTTPS uniquement.
Cinq boutons, et rien d'autre
Taille des nœuds ; nombre de nœuds (trois minimum) ; moteur et taille de la base de données ; région Live DR ; nombre d’environnements. Le reste correspond à l’architecture de référence.
Configurer, intégrer, et seulement ensuite coder
Une exigence allant au-delà de la configuration standard est satisfaite par une mise à niveau de la plateforme si possible. Dans le cas contraire, une intégration via les API TRANXACT exécutées en dehors du cluster est envisagée. Ce n'est qu'après une analyse de sécurité et d'ingénierie que du code ou un agent interne au cluster est considéré ; s'il est approuvé, il est toléré et pris en charge par le client ; s'il est refusé, il est exécuté en dehors du cluster.
L'accès direct à la base de données n'est pas disponible pour le client (il est indiqué comme non proposé, DB_3.1.09). La génération de rapports et l'intégration s'effectuent via les API et les extractions TRANXACT, ce qui explique pourquoi un outil de BI est connecté par API ou par extraction planifiée, et jamais par une connexion directe à la base de données.
L’équipe BI de Calderwood demande un utilisateur de base de données en lecture seule pour son entrepôt. La solution consiste en une extraction planifiée via une liaison privée : la ligne BI correspondante dans leur liste d’interfaces est « conserver, extraction planifiée, liaison privée ».
Essayez-le Un nœud de calcul de la zone 2 tombe en panne pendant la période de clôture mensuelle de Calderwood. Quelles sont les conséquences pour les utilisateurs ? Cet incident est-il impacté par le SLA ?
Ses pods sont reprogrammés sur les nœuds des zones 1 et 3, dimensionnés pour supporter la charge ; la base de données n’est pas affectée sauf si la zone 2 héberge le nœud principal, auquel cas elle bascule vers le nœud de secours synchrone avec un RPO ≈ 0. Cela n’est comptabilisé dans le SLA que si la disponibilité du mois ne respecte pas l’objectif du niveau.