Un réseau privé est un réseau de couche 2 entre vos propres serveurs, transporté en VXLAN à l'intérieur de notre réseau. Le trafic qui y circule reste hors de l'internet public et hors des interfaces publiques des serveurs. Pour les trames jumbo, réglez la MTU de l'interface privée sur 9000. Le réseau transporte aussi vos propres tags VLAN 802.1Q.
Le réseau privé arrive sous forme de VLAN sur le port qui porte déjà le réseau public, et le système d'exploitation sépare les deux grâce au tag.
Le réseau arrive non tagué sur le second port du serveur. Le système d'exploitation y voit une interface ordinaire, sans VLAN à configurer.
Vous choisissez le tag VLAN à la création du réseau. Un serveur reste sur son réseau public et peut rejoindre plusieurs réseaux privés à la fois, chacun avec son propre tag.
Pas à pas dans le guide des réseaux virtuelsLe VLAN d'un réseau privé peut être étendu entre nos centres de données. Des serveurs web à Amsterdam et dans le New Jersey se trouvent alors sur le même réseau de couche 2 et se joignent par le sous-réseau privé que vous leur attribuez.
C'est l'architecture d'un cluster web. Chaque site répond aux visiteurs sur ses propres adresses publiques, tandis que les serveurs gardent sessions, caches et fichiers envoyés synchronisés par le réseau privé plutôt que par l'internet public. La répartition des visiteurs entre les sites, par DNS ou par des répartiteurs de charge que vous exploitez vous-même, relève de votre propre configuration.
Ce sont des estimations pour la planification, pas des mesures.
| Entre | Aller-retour estimé |
|---|---|
| Amsterdam Londres | ≈ 7 ms |
| Amsterdam Francfort | ≈ 8 ms |
| Londres Francfort | ≈ 13 ms |
| New Jersey Chicago | ≈ 18 ms |
| Chicago Dallas | ≈ 22 ms |
| Dallas Los Angeles | ≈ 32 ms |
| New Jersey Dallas | ≈ 38 ms |
| Chicago Los Angeles | ≈ 48 ms |
| Londres New Jersey | ≈ 72 ms |
| Amsterdam New Jersey | ≈ 75 ms |
Chez nous, une DMZ n'est pas un produit à part. Vous la construisez avec les serveurs que vous louez déjà, un réseau privé et un groupe de pare-feu, sur deux niveaux.
Serveurs web et reverse proxies. Chacun a une adresse publique pour les visiteurs et un raccordement au réseau privé pour joindre le niveau situé derrière.
Serveurs de bases de données et d'applications, joints par le réseau privé. Détachez par l'API le réseau public d'un serveur : il n'a alors plus aucune adresse publique, se déploie et se réinstalle toujours, et n'atteint internet qu'à travers l'un de vos serveurs du niveau public, car nous ne proposons pas de passerelle NAT. Si un serveur de ce niveau garde son adresse publique, la base de données n'écoute que sur l'interface privée et un groupe de pare-feu ferme les ports de la base de données et SSH sur cette adresse.
Étendez le réseau à un second centre de données : des serveurs web y rejoignent le niveau public sur le même VLAN et joignent le niveau situé derrière par le réseau privé.
Un groupe de pare-feu est un ensemble nommé de règles que vous appliquez à autant de vos adresses IP publiques que vous le souhaitez. Les règles s'exécutent sur le switch d'accès auquel votre serveur est branché : le trafic qu'une règle bloque y est rejeté et n'atteint jamais le port du serveur. Cela vaut aussi pour le trafic venant d'autres adresses publiques Serverside, pas seulement pour celui d'internet.
Chaque règle autorise, bloque ou limite le trafic en paquets par seconde, selon le protocole (TCP, UDP, ICMP, ICMPv6, GRE ou tous), la plage de ports et le réseau source. Les règles de tous les groupes appliqués à une adresse sont évaluées ensemble par priorité, et le numéro le plus bas l'emporte. Vous gérez les groupes depuis la console cloud ou par l'API, et une règle modifiée s'applique immédiatement.
Bientôt Les groupes de sécurité arrivent bientôt.
Gardez aussi un pare-feu sur chaque serveur. Il suit les connexions, ce que le switch ne fait pas, et c'est le seul filtre sur l'interface privée.
Des serveurs d'applications dans deux centres de données ou plus, chacun derrière un reverse proxy doté de sa propre adresse publique. Ils partagent un magasin de sessions Redis, le cache et des API internes sur des adresses privées, et un déploiement atteint chaque site par le même réseau.
Trois nœuds PostgreSQL sous Patroni avec leurs membres etcd, ou un cluster MySQL ou MariaDB sous Galera ou Group Replication, tous dans un même centre de données. Donnez au trafic du cluster un VLAN à part, distinct de celui sur lequel vos serveurs d'applications interrogent la base.
Dimensionner un serveur de base de donnéesUn cluster par centre de données, avec Corosync et Ceph sur des réseaux privés séparés. La documentation de Proxmox VE demande un réseau dédié à Corosync, car le trafic de stockage peut retarder le heartbeat du cluster.
Cluster Proxmox et haute disponibilitéUn cluster par métropole, avec etcd à l'intérieur. Le trafic entre nœuds et entre pods passe par le réseau privé, et seuls les nœuds d'ingress répondent sur des adresses publiques.
Serveurs dédiés UbuntuL'architecture sentry décrite dans la documentation de CometBFT : les sentinelles du niveau public échangent avec la chaîne, le validateur ne parle qu'à elles par le réseau privé, et un groupe de pare-feu ferme son port pair sur son adresse publique.
Infrastructure Web3Des proxies comme Velocity reçoivent les connexions des joueurs dans le niveau public. Des serveurs de jeu répartis sur plusieurs métropoles joignent une même base de données et un même backend d'authentification par le réseau privé.
Hébergement de serveurs de jeuEnvoyez les sauvegardes vers un serveur d'une autre métropole par le réseau privé. La cible ne fait tourner aucun service public, donc rien n'écoute sur son adresse publique.
Stratégies de sauvegarde ProxmoxLes contrôleurs de domaine répondent à Kerberos et LDAP sur leurs interfaces privées, et un groupe de pare-feu bloque les ports 88, 389 et 445 sur leurs adresses publiques.
Hébergement Windows ServerRien de plus que le serveur que vous louez. Tout ceci est inclus sans surcoût avec chaque serveur dédié, sans frais par réseau, par serveur raccordé ni par centre de données qu'un réseau atteint.
Vous voulez un second avis sur une architecture ? Parlez à notre équipe réseau.
Oui. Un cluster web peut faire tourner des serveurs dans deux métropoles sur un même réseau de couche 2, puisque le VLAN du réseau est étendu entre nos centres de données. Les serveurs y partagent sessions et cache pendant que les deux sites servent les visiteurs. Les clusters de bases de données et Proxmox restent dans un seul centre de données.
La documentation est en anglais.
Ottawa, ON, Canada
Fièrement 
canadien et 
néerlandais
En EUR par Serverside Networks Inc.
