Posts by michaeleifel

Betreibt jemand zufällig eine Gitea Instanz auf dem Webhosting oder kennt sich sehr gut aus und kann mir paar Kickoff Tipps geben?

Normalerweise nutze ich ja Ansible / Docker / Kubernetes für Setups, aber brauche aktuell was Server unabhängiges wo ich paar private Ansible Playbooks hosten kann und wollte dafür das Webhosting Paket "missbrauchen".

Danke

Ich hoffe es ist OK dass ich hier einen neuen Beitrag verfasse anstatt den alten anzupassen.

Heute morgen war es wieder soweit, ich hatte eine Deadlock Kombination zwischen 2 Servern gehabt, die im selben Moment meinten Master werden zu müssen. Zwar haben sie sich innerhalb von 1 sek geeinigt, der SOAP Call war allerdings trotzdem schon unterwegs. Aufgrund dessen habe ich weitere Anpassung im Keepalived Setup vorgenommen und ein rudimentäres Shellskript geschrieben.

#!/bin/bash
# set -eux
set -eu

# Colors
Black='\033[0;30m'        # Black
Red='\033[0;31m'          # Red
Green='\033[0;32m'        # Green
Purple='\033[0;35m'       # Purple
Blue='\033[0;34m'         # Blue
NC='\033[0m' # No Color

# Netcup URLs
WSDL="https://www.servercontrolpanel.de/WSEndUser?wsdl"
API="https://www.servercontrolpanel.de/WSEndUser"

# parameters from keepalived
# $1 = "GROUP" or "INSTANCE"
# $2 = name of group or instance
# $3 = target state of transition ("MASTER", "BACKUP", "FAULT")
TYPE=$1
NAME=$2
STATE=$3

# Stupid check, i know
check-wsdl() {
  curl -s -o /dev/null -w '%{http_code}' ${WSDL}
}

# Execute SOAP Action getVServers to check reachability
check-api() {
  curl -s -o /dev/null -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup_getVServers.xml -X POST ${API}
}

# Execute SOAP Action getVServerIPs to check current IPs
check-ips() {
  curl -s -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup_getVServerIPs.xml -X POST ${API} | grep -o -i {{ Netcup_routedIP }} | wc -l
}

# Failover Process
# StatusCode 200 indicates operation has been triggered
# StatusCode 500 indicates operation isn't available, cause IP might be already switched

trigger-attach() {
  while true
  do
    STATUS=$(curl -s -o /dev/null -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup_attachIPRouting.xml -X POST ${API})
    if [ $STATUS -eq 200 ]; then
      echo -e "${Green} Attach is triggered! ${NC}"
      break
    elif [ $STATUS -eq 500 ]; then
      echo -e "${Purple} Got $STATUS , seems wrong ${NC}"
      echo -e "${Purple} Break back into main loop ${NC}"
      break
    else
      echo -e "${Red} Got $STATUS :( Not done yet... ${NC}"
    fi
    sleep 10
  done
}

trigger-detach() {
  while true
  do
    STATUS=$(curl -s -o /dev/null -w '%{http_code}' -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/netcup_detachIPRouting.xml -X POST ${API})
    if [ $STATUS -eq 200 ]; then
      echo -e "${Green} Detach is triggered! ${NC}"
      break
    elif [ $STATUS -eq 500 ]; then
      echo -e "${Purple} Got $STATUS , seems wrong ${NC}"
      echo -e "${Purple} Break back into main loop ${NC}"
      break
    else
      echo -e "${Red} Got $STATUS :( Not done yet... ${NC}"
    fi
    sleep 10
  done
}

# Source: https://gist.github.com/krohne/298c6393cf3dd6063b054dd297ba7714
# $1 = # of seconds
# $@ = What to print after "Waiting n seconds"
countdown() {
  secs=$1
  shift
  msg=$@
  while [ $secs -gt 0 ]
  do
    printf "\r\033[KWaiting %.d seconds $msg" $((secs--))
    sleep 1
  done
  echo
}

### Real Stuff is down here

wait-for-wsdl() {
  while true
  do
    STATUS=$(check-wsdl)
    if [ $STATUS -eq 200 ]; then
      echo -e "${Green} Netcup URL is reachable! ${NC}"
      break
    else
      echo -e "${Red} Got $STATUS :( Not done yet... ${NC}"
    fi
    sleep 10
  done
}

wait-for-api() {
  while true
  do
    STATUS=$(check-api)
    if [ $STATUS -eq 200 ]; then
      echo -e "${Green} Netcup API is reachable! ${NC}"
      break
    else
      echo -e "${Red} Got $STATUS :( Not done yet... ${NC}"
    fi
    sleep 10
  done
}

attach() {
  while true
  do
    wait-for-wsdl
    wait-for-api
    RESULT_STRING=$(check-ips)
    if [ $RESULT_STRING -eq 1 ]; then
      echo -e "${Green} FailoverIP is switched! ${NC}"
      break
    else
      echo -e "${Purple} Change FailoverIP Routing! ${NC}"
      trigger-attach
    fi
    countdown 20
  done
}

remove() {
  while true
  do
    wait-for-wsdl
    wait-for-api
    RESULT_STRING=$(check-ips)
    if [ $RESULT_STRING -eq 0 ]; then
      echo -e "${Green} FailoverIP detach done! ${NC}"
      break
    else
      echo -e "${Purple} Detaching FailoverIP! ${NC}"
      trigger-detach
    fi
    countdown 20
  done
}

# Switch Case for keepalived
case $STATE in
        "MASTER") attach
                  exit 0
                  ;;
        "BACKUP") remove
                  exit 0
                  ;;
        "FAULT")  remove
                  exit 0
                  ;;
        *)        echo "unknown state"
                  exit 1
                  ;;
esac

Es deckt rudimentär meine Funktionen ab die ich brauche und hat zumindest ein paar simple Checks (netcup API / URL da) drin statt nur einen einfach Curl Request. Zudem habe ich den Parameter "notify_master_rx_lower_pri" ebenfalls auf das Skript angesetzt. Allerdings kann ich die Aussage:

Quote

Bei einer MAC von 00:00:00:00:00:00 wird die IP aus der Routingtabelle gelöscht und diese muss vor einer weiteren Verwendung erst neu zugeordnet werden. Beim Löschauftrag muss als destinationVserverName der Server angegeben werden, auf den die IP aktuell geroutet ist.

von https://www.netcup-wiki.de/wik…rvice#Web_Service_Methods noch nicht bestätigen. Trigger ich den entsprechenden SOAP Call auf einer Node, welche aktuell nicht die FloatingIP hat, so wird diese vom anderen Server getrennt. Für Anregungen / Ideen bin ich weiterhin offen.

Die entsprechenden referenzierten XML Files werden per Ansible (Vault) mit den Parametern gefüttert. Finde ich "persönlich" lesbarer als InlineCode.

Gruß

Quote from Paul

Die Problematik kenne ich. Darüber bin ich damals auch bei meinen Keepalived Setups gestolpert. Was aber helfen könnte, wäre folgende Option

```
preempt_delay 60

```

Das sollte das zu häufige "Flappen" des Masters etwas abmildern. Bei Bedarf noch etwas höher setzen.

Aus meiner Erfahrung gewinnt immer der erste SOAP Befehl, solange dieser noch "in Arbeit" ist. Bei mir hatte das damals immer so um die 30 Sekunden gedauert, bis die Failover IP Adresse erfolgreich zugewiesen wurde. Wenn dann zwischenzeitlich Keepalived die Floating IP selbst wieder gewechselt hat, hat sie aber trotzdem auf den falschen Server gezeigt und der Service war schlussendlich nicht erreichbar.

Vielen Dank für den Input. Bei mir verhielt es sich wegen der IP ähnliich, weswegen ich mittendrin sogar mit Dummy IPs im VRRP Service gearbeitet hatte. Hab mein Setup gestern mal entsprechend angepasst und werde berichten.

Falls jemand Interesse hat kann ich dass mal auf Github packen. Dass ganze ist momentan ein Helm Chart was ich aus einem anderen Github Projekt für Netcup leicht angepasst habe. Die Informationen welche für die SOAP Kommunikation noch notwendig sind (vServer, MAC Adresse) werden vom Container selbst beim Start vom Hostsystem gelesen.

Hallo zusammen,

ich bastele aktuell an meinem Keepalived Setup wieder. Die Healthchecks etc. laufen bereits alle selber und alle notwendigen Checks sind in Verwendung.

Leider hab ich ein paar Dinge entdeckt welche ich noch gerne verbessern würde und wollte mal fragen ob jemand mir da evtl. Tipps geben kann

oder man sich zum Setup austauschen kann. Auch für Hinweise in der Dokumenation bin ich dankbar.

Aktuell hab ich folgendes Setup:

- Jede Node hat Healthchecks wie bspw Kubernetes API Erreichbarkeit, Ingress Status, Healthchecks vom Monitoringagent

- Jede Node hat bereit die notwendingen FloatingIPs konfiguriert, da ich Probleme hatte wenn ich diese dynamische von Keepalived verwalten lasse

- Alle Nodes sprechen per CloudVLAN miteinander und einigen sich, wer der Master ist

- Beim Übergang zum Masterstate führe ich dann per Curl den SOAP Request aus welche die Zuweisung der IP auf diese Node dann vornimmt (notwendige Informationen sind automatisiert, dynamisch über System Informationen ausgelesen)

Aktuelle "Nichtigkeiten":

- Curl Befehl wird ausgeführt (/usr/bin/curl -H 'Content-Type: text/xml; charset=utf-8' -H 'SOAPAction:' -d @/etc/keepalived/netcup_failover.xml -X POST https://www.servercontrolpanel.de:443/WSEndUser)

- Dieser gibt innerhalb von 1 Sek bereits einen Statuscode zurück, weswegen aus keepalived sicht der prozess abgeschlossen ist

- Innerhalb der nächsten 10 Sekunden kommt es zu einem erneuten Masterstate wechsel, weswegen die nächste Node den Curl Befehl absetzt

Wie kann ich bspw ein skript formulieren, welches erst wenn die FloatingIP der Node "wirklich" zugewiesen ist terminiert?

Und wie handelt die Netcup SOAP diese Befehle?

- gewinnt automatisch der letzte Befehl?

- werden weitere Anweisungen der IP Zuweisung blockiert wenn der Vorgang noch nicht abgeschlossen ist?

Gruß

Als aktuelles Beispiel von mir selber:

- 3 Debian 10 RS 4000 Maschinen melden zum selben Zeitpunkt eine Störung des DNS Resolvers beim Versuch google.de aufzulösen:

- IPs und DNS Resolver sind statisch konfiguriert

- Nur 1 von 3 DNS Resolver ist gestört gewesen

resolver.png

Nächster Check war dann wieder grün.

Ich glaube es würde helfen weitere Details zu kennen, vorher ist es Rätselraten:

- Läuft Windows auf der kIste?

- IP statisch konfiguriert?

- IPv6 konfiguriert?

- Was sagt das Monitoring zu dieser Zeit (falls vorhanden)

- Sind es nur pings oder welche Ressourcen sind nicht ansprechbar?

- Was für ne Maschine ist es (vps 200 g8?)

- Trtt das Problem nur bei Verbindung zu bestimmten Providern auf?

- Was läuft alles auf der Kiste?

- Welcher Netzwerktreiber ist im SCP eingestellt?

- Wurden Updates auf dem System eingespielt welche evtl. dieses Problem verursachen?

- Tritt das Problem nur auf 1 Server auf?

Im Artikel https://www.netcup-wiki.de/wiki/Abusehinweise ist ein Link drin wo du Stellung beziehen kannst und deine Optionen siehst. Falls SLA Zusatzvertrag hast, kannst dort auch anrufen.

Kurze Frage: Hast du die Generationen gewechselt? Ansonsten bietet sich doch ein Sidegrade an. Das dauert eigentlich max ~5 Min ( habs schon mehrmals gemacht). Die Gefahr bei Umzug innerhalb der Generationen ist halt bspw dass Interface Namen sich ändern, die Platte vda statt sda heißt etc. was dann auch Supportaufwand erzeugt.

Mir ist bisher auch kein Provider in der Preisregion bekannt der solche Aktionen unterstützt, wen nur als aufpreispflichtiger Service der pro Stunde dann abgerechnet wird. Die Beträge da sind dann natürlich vielfaches von den monatlichen Kosten. (45€ für ein Debian installer iso mounten bspw!). Hatte da schon im geschäftlichen Umfeld "viel Spaß".

Zum glück kann man bei Netcup ISO mounten, per preseed + ansible hab ich neue Server in ~7 min fertig und kann dann den Datenrestore per restic / rclone anschmeißen.

Hallo Rudi,

nicht verzweifeln. Ich habe hier eine Wordpress Anleitung gefunden bei youtube:

Von den Schritten her könnte dir das auf die Sprünge helfen. Dass du momentan die WCP Seite siehst, könnte dran liegen dass entweder bspw. der DNS noch nicht auf das richtige Ziel zeigt oder im Webhosting Backend dann noch nicht der Pfad auf die Joomla Installation zeigt.

Gruß

Kam gerade eben bei mir als Mail rein. Allerdings an meine "falsche" Adresse. Der Link selber führt dann auf ne Seite die 1:1 wie das CCP aussueht und nach Eingabe von "irgendwelchen" Daten kommt man dann auch tatsächlich zum CCP....

Quote from DerFetzer

Wie hast du den Wechsel durchgeführt? Die RKE-Doku sagt, dass der Network Provider nicht verändert werden kann und in der Flannel-Doku steht auch, dass man das Backend nicht im Betrieb ändern soll.

Hab das beim "rke up" gesetzt. Die Doku schreibt den Satz halt rein weil es halt zu einer Unterbrechung kommt wenn bspw von Calico -> Flannel gehst etc oder auch beim Backendtype. Sofern man sich aber etwas "auskennt", lässt sich das nachts in einer geplanten Aktion einfach durchziehen. In der RKE config sieht das bei mir wie folgt dann aus (eth1 ist das cloud vlan, hab net.ifnames=0 in der grub und deswegen die alten Interface Namen.):

network:
  plugin: canal
  options:
    canal_iface: eth1
    canal_flannel_backend_type: host-gw

Der relevante Eintrag stammt aus der Flannel Doku ( https://github.com/coreos/flan…Documentation/backends.md)

Im laufenden Betrieb (falls keine andere Möglichkeit sich ergibt) würde ich erst alle Deployments auf 0 setzen so dass nur der Kubernetes Core läuft (api, coredns, nodelocaldns), warten bis Ceph / Longhorn alles synced hat und dann die Änderung vornehmen. Weave hat anscheinend aktuell nen kleinen Bug der sich durch das bearbeiten des Daemonsets beheben lässt: https://github.com/weaveworks/weave/issues/3816

Gruß

Quote from DerFetzer

michaeleifel Läuft das dann bei dir trotzdem über das Cloud-VLAN? Ich hatte auch mal überlegt, per Wireguard über die Public Interfaces zu kommunizieren, aber dann hat man auch wieder eine zusätzliche Fehlerquelle.

Hab mir extra dafür das (https://www.netcup.de/bestellen/produkt.php?produkt=2298 ) gegönnt da ich noch auf längere Zeit an G8 Server gebunden bin ( hatte kleine Fehlplanung und kurz vor G9 Launch fertig umgebaut...)

Ich nutze auf allen Systemen ein selbst provisioniertes Debian per preseed bei allen Providern am laufen das danach durch Ansible ergänzt wird. Somit hab ich überall das gleiche System und kann Fehlerquellen schnell eingrenzen. RancherOS hatte ich mal testweise am laufen aber irgendwie komme ich dann doch immer wieder zu Debian zurück, zumal nach der Installation es nur 800 mb an Festplatte nutzt da es minimalistisch gehalten ist. Per Backprots paar aktuelle Pakete wie Kernel.

Seit dem Wechsel auf Host Gw als Backend hab ich keine Probleme mehr. Wireguard hatte ich auch ne Zeit lang im Einsatz, das hatte allerdings bei nem anderen Provider Startup Zeiten von 30 Sekunden (liegt am eingesetzten Hypervisor des Provider Virt..zo) und deswegen habe ich micht einfachheitshalber für das Cloud VLAN entschieden. Kann mich nicht beschweren, keine wegknallenden Volumes, hier nen kleiner fio test:

root@seafile-6578f846fd-j9nqg:/data# fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1
random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=1
fio-3.12
Starting 1 process
random-write: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s]                          
random-write: (groupid=0, jobs=1): err= 0: pid=181846: Wed Oct 28 16:47:14 2020
  write: IOPS=9738, BW=38.0MiB/s (39.9MB/s)(4096MiB/107673msec); 0 zone resets
    slat (nsec): min=369, max=4548.8k, avg=5910.36, stdev=13077.23
    clat (nsec): min=177, max=232807k, avg=34796.15, stdev=254836.05
     lat (usec): min=9, max=232811, avg=40.71, stdev=255.43
    clat percentiles (usec):
     |  1.00th=[   10],  5.00th=[   14], 10.00th=[   15], 20.00th=[   17],
     | 30.00th=[   19], 40.00th=[   20], 50.00th=[   22], 60.00th=[   24],
     | 70.00th=[   27], 80.00th=[   32], 90.00th=[   44], 95.00th=[   70],
     | 99.00th=[  277], 99.50th=[  537], 99.90th=[ 1336], 99.95th=[ 1844],
     | 99.99th=[ 3949]
   bw (  KiB/s): min=58928, max=128464, per=100.00%, avg=95286.47, stdev=14999.21, samples=88
   iops        : min=14732, max=32116, avg=23821.57, stdev=3749.86, samples=88
  lat (nsec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=1.47%, 20=40.52%, 50=49.90%
  lat (usec)   : 100=5.13%, 250=1.84%, 500=0.55%, 750=0.25%, 1000=0.11%
  lat (msec)   : 2=0.14%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
  lat (msec)   : 250=0.01%
  cpu          : usr=3.98%, sys=13.03%, ctx=1095405, majf=0, minf=59
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,1048577,0,1 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=38.0MiB/s (39.9MB/s), 38.0MiB/s-38.0MiB/s (39.9MB/s-39.9MB/s), io=4096MiB (4295MB), run=107673-107673msec

Disk stats (read/write):
  rbd1: ios=0/95706, merge=0/3241, ticks=0/4193217, in_queue=4193217, util=89.28%

Quote from Darian

Ich nutze aktuell ein aktuelles Debian ohne dem Cloud vLAN.

Denkt ihr das Cloud vLAN würde was bringen, aktuell ist es so, dass das Free Cloud vLAN bei 100 Mbit langsamer wäre wie die aktuellen 1GBit die wir sowieso schon haben. Deswegen zögere ich da noch das auszuprobieren.

Meint ihr Cloud vLAN wäre trotzdem sinnvoll? Wenn es wirklich was bringt kann man sich ja noch immer ein schnelleres (bis 2,5 Gbit) besorgen.

Ich würde nicht nur die Geschwindigkeit an der Stelle beachten sondern auch wie die Anbindungen sind bzgl Latenz, Routing etc.

Bspw habe ich bei nem anderen Provider das Problem das wenn ich deren public interface nutze die Kommunikationswege zwischen den Nodes auch nur mit 99% SLA abgedeckt sind. Erst durch deren zusätzliches internes Netzwerk ist sichergestellt dass der kürzeste Weg zwischen den Nodes genommen wird was man auch massiv in der Latenz spürt. Eigentlich würde ich ja erwarten dass wenn das andere Ziel innerhalb vom RZ ist der Traffic nicht 1mal bis Frankfurt und zurück geht, allerdings kenne ich da einen Anbieter wo das tatsächlich der Fall ist, aber da sind auch DNS Resolv Zeiten von 2 Sekunden für die Hotline "normal".

Zuerst habe ich auch mit dem Free ausprobiert, aber eher halt bezogen auf Latenzen, Stabilität etc. Über das VLAN läuft auch sämtliche Kommunikation meiner Nodes und nach außen auf dem Public sind es dann nur eine handvoll Ports die dort überhaupt "lauschen". Ausprobieren mit dem Free kann ja nicht schaden, nur halt nicht Wunder erwarten bei der Geschwindigkeit.

Gruß

Hallo zusammen,

welches OS verwendet ihr denn? Nutzt ihr nen VLAN für die Kommunikation zwischen den Nodes oder das Public Interface?

Ich habe RKE (https://github.com/rancher/rke) im Einssatz (was ja bei Rancher zuerst deplyoed wird) mit Canal als CNI und Backend Host-GW ( https://coreos.com/flannel/docs/latest/backends.html ) Mit VxLAN, was der default ist, hatte ich in der Tat auch leichte Probleme.

Als Storage nutze ich Ceph und das läuft saustabil.

Gruß

Vielen Dank für die Kommentare und den Input.

Ich hatte mir das intern auch schon gedacht. Leider konnte ich den SOA Eintrag nicht modifizeren da dies vom bisherigen Anbieter "aus Sichterheitsgründen" nicht supported wird. Die Einträge selber haben bei mir in der Regel eine TTL von ~30 min ( für Lesestoff: https://blog.apnic.net/2019/11…idiculously-low-dns-ttls/). Als negatives Beispiel führe ich gerne das hier an:

paymenthub.****.com. 300 IN     CNAME   ***.cloudapp.net.
***.cloudapp.net. 10 IN A XXX.XXX.XXX.XXX

Das verursacht einen Großteil unnötigen Traffic aus meiner Sicht und wäre mit einem LB eleganter gelöst da die Applikation ständig nur DNS am resolven und lässt sich nicht vernünftig cachen.

Die Domain löst nach den abgelaufenen 24 Stunden jetzt auch bei Netcup sauber auf. Falls jemand weiß welchen Upstream die nutzen könnte man evtl ja darüber die Sache was "beschleunigen".

Gruß

Bzgl nachträglich: Das schnellste was ich nach 3min google bisher gefunden habe: https://github.com/g2p/blocks#readme

Allerdings würde ich auch eher zu einem managed server in solch einer Situation greifen. Das wird vermutlich dann unter dem Aspekt "und müssen auch den Faktor Zeit bedenken" am meisten Sinn machen von dem was ich bisher hier lese.

Hallo zusammen,

ich habe bereits im Forum recherchiert zu dem Thema DNS. Aktuell hab ich eine Domain von Provider 1 zu Provider 2 Nameserver technisch umgezogen. TTL etc. hatte ich auf niedrigen Werten. Alle Internet Resolver liefern auch schon brave die neuen Einträge, allerdings hängen die im Wiki genannten Server ( https://www.netcup-wiki.de/wiki/Nameserver ) aktuell auf "SERVFAIL" fest. ,was auch kleine Lücken im Monitoring auslöst Da ich prinzipiell natürllich lieber die RZ internen Resolver nutzen wollte, stellte sich mir die Frage ob ich irgendwie "flush" ähnlich wie bei google, opendns etc. machen kann. Im Forum bin ich nur über ( https://forum.netcup.de/netcup…aum-domainumzug/?pageNo=1 ) gestolpert.

Die Domäne selber ist bei Netcup gekauft und nur die NS Einträge zeigen auf die externen Provider zwecks Vermeidung Single Point of Failures bei einzigem DNS Anbieter. Wäre nice wenn es dort was geben würde..

Hat jemand evtl. weiteren Input für mich oder hat schon mal die Situation gehabt?

Gruß,

Michael

Ich gehe mal von aus dass die Konfiguration entsprechend auf die internen Interface gelegt ist und nicht rein zufällig doch die public nutzt?

Hatte zuerst glusters, mittlerweile Ceph und kann mich nicht über Performance beschweren. MTR zeigt avg. 0.4ms zwischen den Nodes bei meinen AdHoc Tests:

HOST: srv1               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.0.11       0.0%   100    0.4   0.4   0.3   0.7   0.1

Hab auch mal in mein altes Ansible Playbook für glusterfs geguckt. Hab dabei immer die Internen IPs und keine Hostnamen etc. verwendet für alle Fälle. Hast du paar Details bereit welches OS, GlusterFS Version etc?

SCD

Hallo Vm Nachbar

pasted-from-clipboard.png

Die Zeiten passen überein mit 1 von meinen Rootserver, beim 1 Ausfall hab ich die 24/7 Hotline angerufen, kurz nach der Bestätigung vom Mitarbeiter kam

dann auch die Netcup Mail.

Gruß

Vielen Dank für das reinschauen in mein Github Issue. Hab leider nicht genug Erfahrugn mit programmierung um das sauber nieder schreiben zu können. Hab auch soeben mal ein Ticket beim Support zu dem Thema aufgemacht.

Quote from whoami0501

Did you made a reboot to the server, after you had configured it?

Have you told this to the support?

[netcup] Felix P. Because it seems that this is an bigger issue - may we can have a statement of netcup? Are there any other known reasons for this problems?

Yes, the Server were all completely shut down, also with the SCP Button "Power off" after being configured.

Funny things is that it seems random if it works currently or not. Like right now 1 of the 6 servers i can reach with IPv6, even though it takes a few seconds before the first ping comes back. And all of them can do ping6 netcup.de, but this does not mean i can also ping them from my home.

I did not reach out to Support yet for this as i happily don't need to rely on IPv6 only.