Das längste Thema

Zitat von michaeleifel

Siehe Anhang, das ist mein Lieblingsmeme bei Kubernetes:

Bin gerade dabei Kubernetes Operator zu programmieren.

Gunah haben die 2 Leitungen den Sinn der Bandbreitenbündelung od. den Sinn der Ausfallssicherheit?

vermeide NAT66, NAT64, ... od. ähnliche Krücken;

Zitat von H6G

Bin gerade dabei Kubernetes Operator zu programmieren.

An das Thema hab ich mich noch nicht gesetzt. Aktuell komme ich mit eigenen Helm Charts und Healthchecks ans Ziel

Der Marketing Bullshit hat das nächste Level erreicht;

wurde gerade vom Kollegen darauf hingewiesen, es gibt jetzt (bei einem anderen Anbieter);

Virtual Dedicated Server

im übrigen mit KVM und vCores....

Zitat von Homwer

Der Marketing Bullshit hat das nächste Level erreicht;

wurde gerade vom Kollegen darauf hingewiesen, es gibt jetzt (bei einem anderen Anbieter);

Virtual Dedicated Server

im übrigen mit KVM und vCores....

Du meinst mit "mit dediziertem RAM, CPU und 100 % NVMe-Speicher" wo sie vermutlich einfach nur nicht den Cronjob "/etc/cron.d/sync" mit

echo 3 > /proc/sys/vm/drop_caches installiert haben?

@mainziman soll Ausfallsicher sein, ja habe ich auch gelesen, nur finde ich keine Alternative wie man es macht, wenn mal gewechselt wird ?

Gunah dann ist es doch realtiv einfach; IPv6 connectivity ausschließlich über einen 6in4 Tunnel, welcher bei einem Wechsel einfach mit der anderen WAN-IP Verbunden wird; (ein HE-Tunnel unterstützt das, Du darfst auch einen eigenen 6in4-Tunnel machen)

Warum? der IPv6-Prefix welcher im LAN verwendet wird, darf sich aus diesem Grund nicht ändern;

und IPv4 hast ohnehin nur RFC1918-Adressen, welche korrekt mit dem richtigen WAN-Interface 'verdrahtet' sind;

d.h. es immer nur eine Leitung aktiv; und wenn diese ausfällt wird auf die 2te geschalten;

sind die Bandbreiten bei beiden gleich? od. gibts hier gröbere Unterschiede?

Zitat von Homwer

Virtual Dedicated Server

Also ein VDS statt VPS? Na dann...

bei Netcup auch Root Server genannt

Zitat von Homwer

Der Marketing Bullshit hat das nächste Level erreicht;

wurde gerade vom Kollegen darauf hingewiesen, es gibt jetzt (bei einem anderen Anbieter);

Virtual Dedicated Server

im übrigen mit KVM und vCores....

Wenn du von OpenVZ / Virtuozzo / LXD kommst, ist das gar nicht so unüblich.

interessant wäre hier balt, was folgendes ergibt

cat /proc/cpuinfo |grep 'model name'

ist da dann sowas wie z.B. QEMU Virtual CPU version 2.5+

od. vlt. doch sowas wie z.B. Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz

ersteres als dedizierte CPU zu beeichnen wäre dann nicht ok

TASK ERROR: MAX 8 vcpus allowed per VM on this node

Damn.

Zitat von aRaphael

Wie ist das eigentlich. Woanders werden ja inzwischen auch Server ohne ipv4 (nur mit ipv6) angeboten.

Kann ich auf so einem Teil auch z.B. ein Ubuntu + Webserver aufsetzen, oder hakt das dann irgendwo, aufgrund mangelnder ipv4?

Zitat von H6G

Das geht grundsätzlich, du musst nur auf ein paar "Stolperfallen" achten.

Ja, auf die erste bin ich schon gestoßen:

Could not resolve 'de.archive.ubuntu.com'

Das ist ein CNAME nach ubuntu.mirror.tudos.de und der kann kein ipv6.

Na, suche ich mir mal einen Spiegelserver, der ipv6 kann....

Hätte ja eigentlich erwartet, dass der in .de das kann....

EDIT: done

fi.archive.ubuntu.com

(Der Server steht ja sowieso dort )

@[netcup] Claudia M.

Ich sollte von der Arbeit aus nach einem Manged Privat Server ausschau halten.

Die Seite https://www.netcup.de/professi…managed-privateserver.php ist ja bisle veraltet, da G8.

Neulich gabs ja in den Sonderangeboten einen von G9.

Über Google habe ich noch den Manged PS 2000 G9 gefunden. https://www.netcup.de/bestellen/produkt.php?produkt=2756

Vielleicht da mal die Produktseite anpassen oder ist das da Absicht, dass man da nur die alte Generation bekommt?

Zitat von aRaphael

Ja, auf die erste bin ich schon gestoßen:

Could not resolve 'de.archive.ubuntu.com'

Das ist ein CNAME nach ubuntu.mirror.tudos.de und der kann kein ipv6.

Siehe hier.

Zitat von Homwer

Der Marketing Bullshit hat das nächste Level erreicht;

Virtual Dedicated Server

Connectivity wird hergestellt mit Siemens WLAN Luftkabel.

Zitat von hoedlmoser

solange man scripts zwanghaft in container packt kann ich das alles nicht ernst nehmen! https://github.com/breadlysm/SpeedFlux

Naja, klar. Nur für das Skript alleine wäre es evtl übertrieben. Aber das Beispiel koppelt das ja auch noch an eine InfluxDB und Grafana und das ist dann ggfalls nicht mehr so trivial und kostet auf jeden Fall mehr Aufwand als einen docker-run Befehl abzusetzen.

Außerdem finde ich die (automatische) Updatebarkeit ziemlich praktisch, die Sicherbarkeit ist gut und man kann halt auch sehr sehr komplexe Setups mit einem docker-compose File erschlagen.

Zitat von TBT

Nur für das Skript alleine wäre es evtl übertrieben.

aber mehr ist da nicht drinnen. das ding braucht immernoch eine externe influxdb und ein grafana. und aus einem speedtest-script die daten so aufzubereiten um sie in eine influxdb reinzuschießen ist nicht der aufwand, die bash kann sogar raw-TCP/UDP-sockets. für regelmäßigkeit steuert das ein cronjob.

ich will ja nix sagen, aber irgendwie sollt jemand nach Bulgarien und dort bei einem Datacenter

den FI testen;

wenn die folgenden Ports offen sind:

135/tcp open msrpc

139/tcp open netbios-ssn

445/tcp open microsoft-ds

3389/tcp open ms-term-serv

und das bei einigen des /24-IPv4-Subnets hier Gefahr in Verzug ist;

Zitat von mainziman

ich will ja nix sagen, aber irgendwie sollt jemand nach Bulgarien und dort bei einem Datacenter

den FI testen;

Wenn man in einem Datacenter für die Server ein FI hat läuft sowiso was falsch.