server:hetzner

Hetzner

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

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)

Optionen:

  • Failover-IP (manuell → API)
  • Fail-over-Netz (manuell → API)
  • SDN („vswitch“):
    • mit public IPs
    • privates Netz
  • managed Loadbalancer (TCP-Ports oder HTTP/HTTPS)
    • mögliche Ziele:
      • interne Netze
      • alle Hetzner-IPs (auch BGP-Announcements) sein
      • Kategorien sind 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

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 €“

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.) 1)

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 1420 betragen
  • floating IPs und failover-Netze müssen über API umgeschaltet werden und haben bis zu 60s Umschaltzeit
  • 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
  • es gibt keine ipv6-only vserver oder Rootserver (dualstack ist an sich aber schön), Grund ist das Hetzner ihr rescue-System über PXE realisiert was erst neuere Hardware mit v6 kann
  • Firewall-Regeln (Einschränkungen gelten nur bei Rootservern, NICHT bei der cloudplattform!)
    • sind pro Server max. 10 Stück möglich
    • können kein IPv6
  • ipv6
    • Rootserver bekommen nur ein /64
    • zusätzliche Netze kostenpflichtig
  • 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-ZielIP
  • 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 100%ig
  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)
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_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:


1)
bis 1.4.2022: 0,24 €/kWh (exkl. USt.) / 0,2856 €/kWh (inkl. 19.00 % USt.)