Root-Server auf unterschiedlichen Nodes/Rechenzentren deployen

Anexia hat ein Rechenzentrum in Amsterdam. Das wird netcup nutzen.

Die Netcup Software verteilt bestellte Server normalerweise über verschiedene Subnetze (*./22).
Das wird vermutlich auch in Amsterdam so sein.

Eine Garantie dafür gibt es aber nicht.

Bei netcup weißt du nicht wie sehr deine Server auf unterschiedlichen Nodes verteilt sind.

Es wird sicherlich versucht die Server auf verschiedene Nodes zu deployen, aber ob dies wirklich am Ende so ist kann nur netcup sagen.

Eine Garantie wie bei den großen Platzhirschen hast du hier nicht. netcup ist einer der kleineres Hoster der versucht ein günstiges Angebot bereitzustellen.

Ich für meinen Teil...:

- habe persönlich bisher noch keinen großen Ausfall mitbekommen

- mir ist bereits mal ein Node unter dem Server gestorben, aber meine Maschine war schnell weg migriert und lief dann auf einem anderen Node weiter

- bin hier aber auch als Privatkunde für meine kleineren Spielerein

Andere Kunden hatten hier aber auch schon größere Probleme. Der letzte war gerade das einem Node ein RAID Controller gestorben ist und das wegmigrieren der Daten wirklich zu Problemen geführt hatte. Da waren Server über mehrere Tage aus.

Zu deiner Anforderung:

Jetzt ist die Frage was für ein Unternehmen du betreibst.

Sollte ich eines Gründen wäre ich vermutlich auch mit netcup ausreichen zufrieden.

Wäre ich allerdings im KRITIS Bereich: Dann würde ich mir vermutlich einen anderen Anbieter suchen der hier Redundanter aufgestellt ist und mir die entsprechenden Garantien auch liefern kann.

Auch da der Support hier gerade wieder am sich erholen ist - Ein Punkt den man auch mit in Betracht ziehen muss. Gibt da ja paar Threads im Forum, falls du es nachlesen möchtest.

Quote from devowlio

Schön wäre eine verlässliche Aussage des Supports, ob die Root-Server auf verschiedenen Nodes deployed werden anstatt ein "wahrscheinlich versuchen sie es".

Ausreichend wäre evtl. bereits die Kennzeichnung des Hosts auf dem der VPS/RS liegt.

Vor einem halben Jahr konnte man das (aufgrund eines Fehlers) im SCP in Logs sehen.

Das 'manuelle Verteilen' könnte man dann durch Tauschgeschäfte unter Suche/Biete selbst erledigen. Das Verschieben auf andere Hosts sollte dann aber durch netcup minimiert werden...

Ich frage mich warum die primären Hosts geheim gehalten werden. Wie viele VPS auf einer Kiste laufen wird eh' nicht garantiert, bei den RS sind Cores hingegen vertraglich (dediziert) zugesichert.

Quote from Win98SE4ever

Das Verschieben auf andere Hosts sollte dann aber durch netcup minimiert werden...

Genau das wird aber das Problem sein.

Selbst wenn man die VMs bei der Bestellung auf verschiedenen Host hat, so wäre nicht garantiert, dass das auch so bleibt.

Es wird nicht zu vermeiden sein, dass VMs hin und wieder auf andere Hosts verschoben werden.

Quote from aRaphael

Selbst wenn man die VMs bei der Bestellung auf verschiedenen Host hat, so wäre nicht garantiert, dass das auch so bleibt.

In einem anderen Diskussionsfaden wurde ja darauf hingewiesen, dass yabs/systemd-detect-virt als verwendete Virtualisierungslösung "microsoft" (Hyper-V) ausweist. Trifft dies zu, stellt sich auch praktisch die Frage, inwieweit man diese Instanzen seitens Anexia/Netcup bei Zubuchung von Kapazitäten bei Dritten überhaupt belastbar "verorten" kann.

Quote from aRaphael

Genau das wird aber das Problem sein.

Selbst wenn man die VMs bei der Bestellung auf verschiedenen Host hat, so wäre nicht garantiert, dass das auch so bleibt.

Es wird nicht zu vermeiden sein, dass VMs hin und wieder auf andere Hosts verschoben werden.

Nennt sich Anti-Affinity und machen andere Cloudprovider, selbst beim Verschieben bleibt gewährleistet, dass die Nodes unterschiedlich sind.

Quote from Win98SE4ever

... bei den RS sind Cores hingegen vertraglich (dediziert) zugesichert.

Scheinbar wird mittlerweile auch das nicht mehr zugesichert, welches man auch ab und zu gut über die entsprechende Konsole sehen kann.

Bei mir betrifft es gerade drei Server vom Typ RS 8000.

Da diese aber nun durch echtes Blech ersetzt wurden und sie schon gekündigt sind, ist es mir mittlerweile auch egal.

Quote from engine

Nennt sich Anti-Affinity und machen andere Cloudprovider, selbst beim Verschieben bleibt gewährleistet, dass die Nodes unterschiedlich sind.

Wenn das bei anderen Cloud-Anbietern – sind das wirklich Massenhoster im vergleichbaren Preissegment? – explizit vertraglich festgehalten ist, wird es sicherlich auch in die Kalkulation einfließen (müssen!).

Quote from m_ueberall

Wenn das bei anderen Cloud-Anbietern – sind das wirklich Massenhoster im vergleichbaren Preissegment? – explizit vertraglich festgehalten ist, wird es sicherlich auch in die Kalkulation einfließen (müssen!).

Natürlich nicht. Ich habe dabei verschiedene Modelle gesehen. Die einen, die es garantieren und die anderen, die die Option anbieten (rotes H) aber es nicht vertraglich festlegen.

Quote from engine

Die einen, die es garantieren und die anderen, die die Option anbieten (rotes H) aber es nicht vertraglich festlegen.

Weißt Du ob die anderen wenigstens eine Erkennung erlauben?

Das wäre ja zumindest ein erster Schritt.

Zum Thema:

Quote from m_ueberall

inwieweit man diese Instanzen seitens Anexia/Netcup bei Zubuchung von Kapazitäten bei Dritten überhaupt belastbar "verorten" kann

Das könnte sich das netcup ja auch von Dritten als Info geben lassen.

Spielt ja diesbezüglich keine Rolle ob echtes Blech in Nürnberg liegt oder woanders Blech angemietet wird.

Unser Einkauf weiß jedenfalls exakt wo Waren herkommen und lässt sich auch bei Dienstleistungen einiges Compliance/Vertraglich zusichern.

Pseudonymisierte Host-Kennzeichnung:

Quote from Win98SE4ever

Ausreichend wäre evtl. bereits die Kennzeichnung des Hosts auf dem der VPS/RS liegt.

Da ich hier aber nicht herummosern will, gibt's gleich mal einen Verbesserungsvorschlag bzw. eine Umsetzungsidee:

Man könnte den Hosts auf denen die Hypervisor laufen einfach kundenindividuelle Namen geben.

Angenommen meine Kundennummer ist 123456789 dann könnte netcup die Hypervisor-Hosts meiner Server einfach so nennen:

hv123456789-2f62a9

hv123456789-1e8256

hv123456789-682c38

hv123456789-45a2b3

Der hintere Teil kann netcup-intern nach internen Befindlichkeiten erzeugt werden.

Das Argument "heute ist bei mir 682c38 ausgefallen und bei m_ueberall zeitgleich der 38691a, also müssen das die gleichen Hostserver sein, wir sind also Nachbarn" greift nicht. Denn einerseits kann man gemeinsam genutztes Wohneigentum auch ohne Identifier bei gleichem Störungsverhalten vermuten und andererseits könnte netcup einfach mit der Vergabe eines neuen Identifiers (nach der Störung) einen Umzug vortäuschen (obwohl alles auf den gleichen Hosts bleibt).

Sollten manche Leute hier verschiedene Kundenaccounts haben, könnte man dies evtl. Verknüpfen. Dann bezieht sich halt der vordere Teil nicht auf einen Kundenaccount sondern auf eine Kundengruppe. Das bietet sich bei kleinen IT-Dienstleistern an.

Nochmal: Mir ist klar dass ein zugesichertes

Quote from engine

Anti-Affinity

Geld kostet, aber eine Identifizierbarkeit sollte doch kostengünstig realisierbar seon, mit sehr hohem Mehrwert für die Kunden.

PS: Das Ding auf dem der Hypervisor läuft nenne ich hier Host bzw. Hostserver. Sollte die korrekte Bezeichnung node, Nodecluster, Hostcluster oder sonstwie heißen ist mir das auch Recht. Ich meine schlicht das zugrundeliegende Ding, des wo ausfallen tuen könnte

Quote from Win98SE4ever

Weißt Du ob die anderen wenigstens eine Erkennung erlauben?

Bei den großen Anbietern kannste das eigentlich immer recht einfach über den metadata-service/api herausfinden, beim roten H steht der Host aber nur indirekt in jeder Routenverfolgung direkt hinter dem Gateway.