Hetzner / Myloc Lokalität


#1

Continuing the discussion from Admintagebuch - Dokumentation der Admintätigkeiten:

Ja und?


#2

Dann bezahlen wir den Traffic doppelt. Wenn wir Backbone und Gateway im selben RZ haben - zumindest bei Hetzner wird das offiziell bestätigt - zahlen wir wenigstens nur einmal. Die ganzen Hetzner-Kisten sind ziemlich am Limit oder darüber. Bei Remü mussten wir im Februar zuzahlen.

Grüße
Matthias


#3

Nicht nur Traffic im selben RZ, sondern im kompletten Hetzner Netz wird nicht berechnet.

Ich vertrete dennoch immer noch die Meinung, dass man die Gateways an mehrere Backbone-Server, wenn nicht sogar an alle, anschließen sollten. Man kann ja die “interne” Verbindung priorisieren.


#4

ACK


#5

Ich sehe da keinen Vorteil drin, da noch nie ein Tunnel gestorben ist, sondern immer eine VM. Und da sind es die VMs mit Batman drauf. Ein Backbone stürzt nicht so schnell ab.

Wir sollten aber noch die Routing Days Erkenntnisse umsetzen und das Backbone vernetzen und dafür die Gatewayverbindungen auf OSPF-Ebene lösen.

Grüße
Matthias


#6

Naja, da hatten wir aber eher darüber gesprochen die Backbone-Server nicht mehr direkt miteinander zu verbinden, dafür aber jeden Gateway-Server an alle Backbone-Server anzuschließen.


#7

Das ist nicht korrekt. Irgendeine Art von Querverbindung brauchst du. Sonst geht das Interdomänrouting nicht. Das was jetzt teilweise als Transit durch Domänen geht, soll im Backbone abgewickelt werden. So hatten wir es mit Takt aufgemalt.

Man kann natürlich jedes Backbone mit jedem Gateway verbinden, ich sehe derzeit einfach keinen Vorteil darin. Habe aber auch nichts dagegen, wenn man die internen Verbindungen priorisieren würde. Am Ende Arbeit, deren Vorteil ich nicht sehe.


#8

Naja, wir haben uns mit takt darüber unterhalten und er hat genau diese Konfiguration (Anbindung aller Gateways an alle Backbone-Server) vorgeschlagen.

Aber ja, wir haben auch darüber gesprochen, das Backbone zu vernetzen und das ospf durchs batman abzudrehen.


#9

Er hat gesagt, dass man das normaler Weise so macht. Das berücksichtigt nicht die ungleichen Latenzen und Kostenstrukturen.

Das Backbone sollte vorallem vernetzt werden und das OSPF aus dem Batman raus. Das ist das wichtigste.


#10

Ja, hatte es gerade meinem vorherigen Posting hinzugefügt. :stuck_out_tongue:

Aber das steht nicht in Widerspruch dazu, die Gateway-Server mehrfach anzubinden.

Es geht eher um ein Fallback. Der Aufwand das so zu konfigurieren ist jetzt nicht soo extrem. Daher sehe ich keinen Grund es nicht umzusetzen.

Pluspunkt: Wenn das einmal so eingerichtet ist und es auf einem Backbone-Server einen Performance-Engpass gibt, kann man super easy, super schnell das ein oder andere Gateway auf einen anderen BB-Server “umschwenken”.


#11

Nach unseren bisherigen Erfahrungen stürzen eigentlich immer nur die Kisten mit Batman ab. Denen eine mehrfache Anbindung zu bringen, bringt halt in meinen Augen nichts.

Stattdessen holt man sich eine zusätzliche Fehlerquelle im Routing rein, die für größere Latenzen und höhere Kosten sorgen könnte. Wir hatten schon bei drei Gateways in einer Domäne OSPF-Routingeffekte, die wir nicht verstanden haben.

Richtig was bringen tut das erst, wenn man z.B. Skripte definiert, die ein Backbone deaktivieren, wenn z.B. die NAT-Tabelle mal wieder vollläuft.