Hetzner

Die Hetzner Online GmbH ist ein Cloud-Anbieter mit Sitz in Deutschland.

• https://www.golem.de/news/besuch-im-rechenzentrum-so-betreibt-hetzner-tausende-server-effizient-2211-169943.html
• https://www.youtube.com/watch?v=5eo8nz_niiM

• 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.

Serverbörse

• 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€.

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.

IP Preisliste

• 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)

• 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

• 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)
• eigene overlay-Netze (wireguard, GRE-Tunnel, ipsec, …)

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

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?

1. 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 €“
2. oder eigene upstreams suchen, siehe https://docs.hetzner.com/de/robot/colocation/carrier-neutral-colocation-area

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.) ¹⁾

10G Colocation Uplink (nicht redundant):

• LWL-Vorverkabelung Colocation Racks (Single Mode) 593,81 € einmalig
• Setup 10G Colocation Uplink (nicht redundant): 355,81 € einmalig
• 10G Colocation Uplink (nicht redundant) 117,81 € mtl.
• 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.

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.

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/

• vswitche
  • 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

1. Preis stimmt
2. Leistung ist top:
   1. gebraucht (teilweise deutlich unter 30 € einen potenten Quadcore mit ca. 2x 3TB Platten und 1 Gbit/s Bandbreite) in der Serverbörse.
   2. neu ab ~40€, nvme-Systeme bis hin zu dicken Dell-Maschinen
3. Support sehr kompetent
4. Reaktionszeiten bei hands-on sind relativ schnell (ca. 30min bis 1,5h zu jeder Tages- und Nachtzeit)

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_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

ansible:

• hetzner_dns_record hinzufügen oder löschen von einzelnen records
• hetzner_dns_record_info holen von einzelnen records
• hetzner_dns_record_set
• hetzner_dns_record_set_info
• hetzner_dns_record_sets
• hetzner_dns_zone_info