Ein privates Netzwerk ist ein Layer-2-Netz zwischen Ihren eigenen Servern, das innerhalb unseres Netzes als VXLAN transportiert wird. Der Traffic darauf bleibt vom öffentlichen Internet und von den öffentlichen Schnittstellen der Server fern. Für Jumbo Frames setzen Sie auf der privaten Schnittstelle MTU 9000. Eigene 802.1Q-VLAN-Tags transportiert das Netzwerk ebenfalls.
Das private Netzwerk kommt als VLAN auf dem Port an, der bereits das öffentliche Netzwerk führt, und das Betriebssystem trennt beide anhand des Tags.
Das Netzwerk kommt ungetaggt auf dem zweiten Port des Servers an. Das Betriebssystem sieht dort eine gewöhnliche Schnittstelle ohne VLAN-Konfiguration.
Den VLAN-Tag wählen Sie beim Anlegen des Netzwerks selbst. Ein Server bleibt in seinem öffentlichen Netzwerk und kann gleichzeitig mehreren privaten Netzwerken angehören, jedes mit eigenem Tag.
Schritt für Schritt in der Anleitung zu virtuellen NetzwerkenDas VLAN eines privaten Netzwerks lässt sich zwischen unseren Rechenzentren erweitern. Webserver in Amsterdam und New Jersey liegen dann im selben Layer-2-Netz und erreichen sich über das private Subnetz, das Sie vergeben.
So entsteht ein Webcluster. Jeder Standort beantwortet Besucher auf seinen eigenen öffentlichen Adressen, während die Server Sessions, Caches und hochgeladene Dateien über das private Netzwerk abgleichen statt über das öffentliche Internet. Wie Besucher auf die Standorte verteilt werden, per DNS oder über selbst betriebene Load Balancer, legen Sie in Ihrem eigenen Setup fest.
Die Werte sind Schätzungen für die Planung, keine Messungen.
| Zwischen | Geschätzter Round Trip |
|---|---|
| Amsterdam London | ≈ 7 ms |
| Amsterdam Frankfurt | ≈ 8 ms |
| London Frankfurt | ≈ 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 |
| London New Jersey | ≈ 72 ms |
| Amsterdam New Jersey | ≈ 75 ms |
Eine DMZ ist bei uns kein eigenes Produkt. Sie bauen sie aus den Servern, die Sie bereits mieten, einem privaten Netzwerk und einer Firewall-Gruppe, in zwei Ebenen.
Webserver und Reverse Proxys. Jeder hat eine öffentliche Adresse für Besucher und eine Anbindung an das private Netzwerk für die Ebene dahinter.
Datenbank- und Anwendungsserver, erreichbar über das private Netzwerk. Trennen Sie per API das öffentliche Netzwerk eines Servers, hat er gar keine öffentliche Adresse mehr; Deployment und Neuinstallation funktionieren weiter. Ins Internet kommt er dann nur über einen Ihrer eigenen Server in der öffentlichen Ebene, denn ein NAT-Gateway bieten wir nicht an. Behält ein Server dieser Ebene seine öffentliche Adresse, lauscht die Datenbank nur auf der privaten Schnittstelle, und eine Firewall-Gruppe schließt die Datenbank- und SSH-Ports auf dieser Adresse.
Erweitern Sie das Netzwerk in ein zweites Rechenzentrum, dann gehören Webserver dort im selben VLAN zur öffentlichen Ebene und erreichen die Ebene dahinter über das private Netzwerk.
Eine Firewall-Gruppe ist ein benannter Regelsatz, den Sie auf beliebig viele Ihrer öffentlichen IP-Adressen anwenden. Die Regeln laufen auf dem Access-Switch, an dem Ihr Server hängt: Traffic, den eine Regel blockiert, wird dort verworfen und erreicht den Port des Servers nie. Das gilt auch für Traffic von anderen öffentlichen Serverside-Adressen, nicht nur für Traffic aus dem Internet.
Jede Regel erlaubt, blockiert oder begrenzt Traffic in Paketen pro Sekunde, nach Protokoll (TCP, UDP, ICMP, ICMPv6, GRE oder alle), Portbereich und Quellnetz. Die Regeln aller Gruppen auf einer Adresse werden gemeinsam nach Priorität geprüft, und die niedrigste Nummer gewinnt. Sie verwalten die Gruppen in der Cloud-Konsole oder über die API; eine geänderte Regel gilt sofort.
Demnächst Security Groups folgen in Kürze.
Betreiben Sie zusätzlich auf jedem Server eine Firewall. Sie verfolgt Verbindungen, was der Switch nicht tut, und ist der einzige Filter auf der privaten Schnittstelle.
Anwendungsserver in zwei oder mehr Rechenzentren, jeder hinter einem Reverse Proxy mit eigener öffentlicher Adresse. Sie teilen einen Redis-Session-Store, den Cache und interne APIs auf privaten Adressen, und ein Deployment erreicht jeden Standort über dasselbe Netzwerk.
Drei PostgreSQL-Knoten unter Patroni mit ihren etcd-Mitgliedern oder ein MySQL- bzw. MariaDB-Cluster mit Galera oder Group Replication, alle in einem Rechenzentrum. Geben Sie dem Cluster-Traffic ein eigenes VLAN, getrennt von dem, über das Ihre Anwendungsserver die Datenbank abfragen.
Einen Datenbankserver dimensionierenEin Cluster pro Rechenzentrum, mit Corosync und Ceph in getrennten privaten Netzwerken. Die Dokumentation von Proxmox VE verlangt ein eigenes Corosync-Netz, weil Storage-Traffic den Heartbeat des Clusters verzögern kann.
Proxmox-Cluster und HAEin Cluster pro Metropole, mit etcd darin. Traffic zwischen Knoten und Pods läuft über das private Netzwerk, und nur die Ingress-Knoten antworten auf öffentlichen Adressen.
Ubuntu auf dedizierten ServernDer Sentry-Aufbau aus der CometBFT-Dokumentation: Sentries in der öffentlichen Ebene peeren mit der Chain, der Validator spricht nur über das private Netzwerk mit ihnen, und eine Firewall-Gruppe schließt seinen Peer-Port auf seiner öffentlichen Adresse.
Web3-InfrastrukturProxys wie Velocity nehmen die Spielerverbindungen in der öffentlichen Ebene an. Gameserver in mehreren Metropolen erreichen eine gemeinsame Datenbank und ein Login-Backend über das private Netzwerk.
Gameserver-HostingLassen Sie Backup-Jobs über das private Netzwerk auf einen Server in einer anderen Metropole schreiben. Das Backup-Ziel betreibt keinen öffentlichen Dienst, also lauscht auf seiner öffentlichen Adresse nichts.
Backup-Strategien für ProxmoxDomänencontroller beantworten Kerberos und LDAP auf ihren privaten Schnittstellen, und eine Firewall-Gruppe sperrt die Ports 88, 389 und 445 auf ihren öffentlichen Adressen.
Windows-Server-HostingNichts über den gemieteten Server hinaus. All das gehört ohne Aufpreis zu jedem dedizierten Server, ohne Gebühr pro Netzwerk, pro angebundenem Server oder pro Rechenzentrum, das ein Netzwerk erreicht.
Möchten Sie eine zweite Meinung zu einem Aufbau? Sprechen Sie mit unserem Netzwerkteam.
Ja. Ein Webcluster kann Server in zwei Metropolen in einem Layer-2-Netz betreiben, weil das VLAN des Netzwerks zwischen unseren Rechenzentren erweitert wird. Die Server teilen darüber Sessions und Cache, während beide Standorte Besucher bedienen. Datenbank- und Proxmox-Cluster gehören in ein einzelnes Rechenzentrum.
Die Dokumentation ist auf Englisch.
Ottawa, ON, Canada
Mit Stolz 
kanadisch und 
niederländisch
In EUR durch Serverside Networks Inc.
