Hetzner
Die Hetzner Online GmbH ist ein Cloud-Anbieter mit Sitz in Deutschland.
Standorte
Liste der Standorte und peering
geplant: 10,5ha; ~105000 m² Nähe Frankfurt Main 1)
Speedtest / Looking glas
Speedtests
- Nürnberg https://speed.hetzner.de
- Hillsboro https://hil-speed.hetzner.com/
ICMP-Ziele:
- Nürnberg: nbg.icmp.hetzner.com
- Falkenstein: fsn.icmp.hetzner.com
- Helsinki: hel.icmp.hetzner.com
- Ashburn: ash.icmp.hetzner.com
Artikel und Videos
features
- vswitch-Feature: es wird ein Vlan zwischen root-Servern aufgemacht. Das ist z.B. für den Austausch zwischen Cluster-Nodes hilfreich (keepalived, haproxy, …). Es kann sogar ein oder mehrere öffentliche Netze draufgeschaltet werden. Konfiguration siehe https://wiki.hetzner.de/index.php/Vswitch.
- Wenn der Server hart hängen bleibt, kann automatisiert STRG-Alt-Entf bzw. ein soft oder hard-Reset über web ausgelöst werden. Fährt das Teil gar nicht mehr hoch (boot-loader defekt, Netzwerk falsch konfiguriert etc.) kann eine remote-Konsole („Lara“ - entspricht dem lantronics Spider, Bedienung über java) an den Server angeschlossen werden. Kostet nix extra, kann aber nur ein paar Stunden reserviert werden.
- dDoS-Schutz ist inklusive (es gibt da eine Schwelle bei der Anzahl der Datenpakete), ob der nachher bei bei einem spezielleren Angriff greift wird sich zeigen. Für ganz billige „Angriffe“ können eingehende Firewall-Regeln definiert werden die schon vor dem root-Server greifen.
- Anbindung: Allein was Hetzner schon als private Peerings hat, haben andere Anbieter nicht mal in Summe, siehe https://www.hetzner.de/unternehmen/rechenzentrum/ .
- Traffic: Es wird nur der ausgehende Traffic gezählt. Eingehender und interner Traffic wird nicht gezählt.
- niedrigere service-prio: steht auf dem Papier da, ist real irrelevant. Hardware-Defekte (Platten, vielleicht mal in x-Jahren der ganze Server) werden innerhalb kürzester Zeit behoben (Plattentausch i.d.R. unter 2h!). kein telefon-Support unter einem Monatpreis von 46,41€.
administrative Zugänge
Rootserver („Robot“): Aus der FAQ: „Durch das Anlegen eines separaten Adminzugangs, erhalten Sie neue Robot-Zugangsdaten, die nur für den aktuell ausgewählten Server gelten.
Dieser Account verfügt nur über die Menüpunkte „Server“ und „Traffic-Statistik“ und kann nur den einen Server einsehen für den er angelegt wurde. Supportanfragen, Bestellungen und Kündigungen sind über einen Adminzugang nicht möglich.
Sie können die Zugangsdaten für den Adminzugang z.B. Ihrem Administrator zur Verfügung stellen, damit dieser über Zugriff auf Funktionen wie den Reset-Auftrag oder die Rescue-Aktivierung für den Server verfügt.“
vserver („cloud“): für jedes Projekt können per Einladung extra Benutzer hinzugefügt werden.
2FA kann bei Accounts und OTP kann beim tel. Support benutzt werden.
Networking
- vserver (dual-stack mit optional floating-IPs)
- Rootserver (dual-stack mit fixen IPs/Netzen sowie IP-Clustering
- Co-location (Layer2-Domäne mit /56-IPv6-Netz - zum Eigenaufbau von Clustering)
Hochverfügbarkeit / IP-Clustering
öffentliche Netze
- Failover (manuell via API oder automatisiert via hcloud-ip und keepalived, Anleitung: https://www.brunsch.me/keepalived
- Fail-over-IPs (v4 + v6) (Rootserver + Co-location als Ziel) bei cloud heißt das Floating IP * Fail-over-Netz (v4 + v6, /24 bis /29 bzw. ein /64) → Rootserver + Co-location als Ziel
- SDN („vswitch“) → Rootserver
- mit public IPs oder privates Netz
- Co-location: eigenes Loadbalancing (L2 und darüber): extra Netz routen über Außen-IP eines eines Transfernetzes auf Firewall)
- managed Loadbalancer (TCP-Ports oder HTTP/HTTPS) → Rootserver, cloud und Co-location
- mögliche Ziele:
- interne Netze
- alle Hetzner-IPs (auch BGP-Announcements) sein
- Kategorien, mögliche Werte: Cloud, Server, dedicated oder Server via label
- Einstellungen:
- Standort (NBG, FSN, HEL, ASH)
- HTTP:
- Zielport
- Intervall (s), Timeout (s), Retries
- Domäne, Pfad (URI)
- Statuscode für healthcheck (bei HTTP)
- Responsecode
- TLS an oder aus
- Sticky sessions
- Proxy protokoll
- Port: Portopen
- Zielport
- Intervall (s), Timeout (s), Retries
- Proxy protokoll
- Algorithmen:
- Round-Robin
- Least Connections
interne Netze / managed routing
- cloud-Plattform: L3/geroutet (mit „Bruch“ auch zu Rootservern möglich)
- Rootserver:
- SDN („vswitch“) mit kleinerer MTU
- zusätzlicher Gigabit-Link. Vorraussetzung: ins gleiche Rack stellen lassen + extra Switch wird installiert
- Co-location
- private Interconnects (zwischen Racks)
RIPE
Vorteile: /24 Netzwerk nach IPv4 Waiting List https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list) - 2000€ einmalig - 1400€ pro Jahr (~117€ mtl.) - BGP?
- 99€ für ASN ohne eigene IP-Adressen announcen: „Announcement foreign IP address space (PI subnet) für Colo-Racks Nürnberg/Falkenstein 99,00 €“
- oder eigene upstreams suchen, siehe https://docs.hetzner.com/de/robot/colocation/carrier-neutral-colocation-area
Co-Location
Co-Location FAQ mit Rack-Beschreibungen/Abmessungen
Rack Basic (200€, 42HE, 10TB Traffic ausgehend, für ca. 65cm tiefe Server ausreichend)
- Für die Colocation Racks erhält man einen Zahlencode bzw. Schlüssel.
- passende Chassis für Rack basic:
- Supermicro CSE-846
- Supermicro CSE-847 (wenn die vorne nicht festgeschraubt werden!)
- Rails: MCP-290-00058-0N, Achtung: MCP-290-00057-0N sind zu 1-2cm zu lang in der Mindestgröße!
- Stromzufuhr
- redundant (2 x 16 A) über A/B-Schiene (Max. Belastung aus Sicherheitsgründen bis 2 x 10 A, das sind ca. 2300W) → 2x handelsübliche Schuko-Steckdosen
- Stromkosten: 0,29 €/kWh (exkl. USt.) / 0,3451 €/kWh (inkl. 19.00 % USt.) 2)
uplinks
10G Colocation Uplink (nicht redundant):
- LWL-Vorverkabelung Colocation Racks (Single Mode) 499€ netto (einmalig)
- Setup 10G Colocation Uplink (nicht redundant): 299€ netto (einmalig)
- 10G Colocation Uplink (nicht redundant) 99€ netto (mtl.)
- 10G Optik SFP+ 2,50€ /Monat
- eigener Switch mit SFP+ und eigener Optik: SFP+ 10G LR 1310nm und LC/LC Stecker
Optionen mit Redundanz und eigener BGP-Session kosten mehr.
ASN mit eigenen IP-Adressen (PI von RIPE) announcen: Announcement foreign IP address space (PI subnet) für Colo-Racks Nürnberg/Falkenstein 99,00 €
Private Interconnects (29€ netto) : LWL-Vorverkabelung (499 € netto) 1HE Panel in das Rack mit 6x LC-Duplex Verbindungen (Singlemode), Ziel: Patchschrank (meet-me-room). Die einmaligen Kosten für den Private Interconnect sind abhängig von der Trassenführung.
V6 setup (interne Netze)
Standardmäßig kann im Layer2 das ganze Präfix benutzt werden, auch mit Subnets.
Sollte aber eine Art Firmennetz hochgezogen werden (interne Netze und firewalling wie in https://blog.matrixpost.net/set-up-your-internal-lan-and-perimeter-network-with-public-ipv6-addresses-and-pfsense/ beschrieben) dann ist die folgende Herangehensweise am besten:
Hetzner teilt auf Anfrage ein /64 Transfernetz zu, hier kann die statische (Cluster) WAN-IP der Firewall konfiguriert werden und Hetzner routet dann das zugeteilte /56 auf diese IP. Der Rest ist dann intern Sache der Firewall.
V4 setup (interne Netze)
Im Prinzip ähnlich wie bei v6, über ein Transfernetz werden v4-Netze über die Firewalls geroutet.
https://blog.matrixpost.net/set-up-a-perimeter-network-with-public-ipv4-addresses-and-pfsense/
DNS
DNS mit API, ansible module Teil der Community.Dns-Collection.
Einschränkungen:
- SOA-Record kann nicht verändert werden (ggf. über support ticket?)
Einschränkungen
-
- die Verbindung zur Cloud-Plattform läuft über ein nicht transparenter Gateway. D.h. auf dem VMs muss extra konfiguriert werden damit die Verbindung zu Rootserver klappt!
- Traffic: ab 1TB ausgehend kostenpflichtig … oder bei public-IPs
- MTU darf nur 1400 betragen
- floating IPs und failover-Netze müssen manuell über API umgeschaltet werden, Dauer: zwischen 40s und 60s!
- Zusatz-IPs (max. 6 pro Server) und extra Netze sind an einen (root-) server gebunden. Zusammen mit den neuen setup-Gebühren ist das unschön. Übertragung geht höchstens am gleichen RZ-Standort
- Firewall-Regeln (Einschränkungen gelten nur bei Rootservern, NICHT bei der cloudplattform!)
- sind pro Server max. 10 Stück möglich
- ipv6
- Rootserver bekommen nur ein /64 (ggf. zusätzliche Netze möglich?)
- zusätzliche Netze kostenpflichtig (aber nicht teuer)
- Loadbalancer
- kann kein UDP (das ist aber meist auch weniger sinnvoll)
- er kann aber TCP - mit Quell-/Zielportumsetzung - und HTTP/HTTPS-Terminierung und Proxy-Protokoll) mit beliebiger Hetzner-Ziel-IP
- Ziele nur in derselben Netzwerkzone möglich
- Netzwerksetup ist durch die o.g. Einschränkungen oft kompliziert. Z.B. bridged-setup eines Virtualisierungshosts mit festgelegten MAC-Adressen oder routed-IPs
Fazit
- Preis stimmt
- Leistung ist top:
- gebraucht (teilweise deutlich unter 30 € einen potenten Quadcore mit ca. 2x 3TB Platten und 1 Gbit/s Bandbreite) in der Serverbörse.
- neu ab ~40€, nvme-Systeme bis hin zu dicken Dell-Maschinen
- Support sehr kompetent
- Reaktionszeiten bei hands-on sind relativ schnell (ca. 30min bis 1,5h zu jeder Tages- und Nachtzeit)
Hetzner setup
cluster-IP setup
Beispieladresse | steht für … |
---|---|
1.2.3.4 | Cluster-IP |
5.6.7.8 | rootserver |
9.10.11.12 | „alte“ Hauptadresse |
Rootserver-VM
auto ens3 iface ens3 inet static address 1.2.3.4 netmask 255.255.255.255 gateway 5.6.7.8 # rootserver (traceroute $IP)
vserver:
auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.255 # broadcast 1.2.3.4 gateway 172.31.1.1 dns-nameservers 8.8.4.4 9.9.9.9 # "old" main-IP: up ip addr add 9.10.11.12/32 dev eth0 down ip addr del 9.10.11.12/32 dev eth0
bridge setup
bridge_hw eno1 ist ab Debian 11 notwendig, da sonst die bridge eine anderen MAC als die darunterliegende Hardware (hier eno1) bekommt und damit die Portsecurity von hetzner den Traffic nicht erlaubt. Auf ARP-Ebene geht es noch (arping $GW) aber nichts oberhalb Layer2.
iface eno1 inet manual auto br_inet iface br_inet inet static address $IP/$NETMASK gateway $GW bridge_hw eno1 bridge_ports eno1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off iface br_inet inet6 static address $IP netmask 64 gateway fe80::1 bridge_hw eno1 bridge_ports eno1 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off
Hetzner DNS
ansible:
- hetzner_dns_record hinzufügen oder löschen von einzelnen records
- hetzner_dns_record_info holen von einzelnen records