Beiträge von Paul

Zitat von andreas.

Ich nehme mal an, dass die Intel-CPU´s nur deswegen weniger Steal haben, weil weniger Kunden auf den älteren Wirtsystemen sind und weil den vServern nur die virtuelle CPU "QEMU Virtual CPU version 2.5+", die sowieso schon langsamer ist, anstelle der Host-CPU durchgereicht wird.

Daran allein sollte es eigentlich nicht liegen. Ich habe ja noch einige x86 Systeme. Auf keinem einzigen habe ich solche Steal Werte (zum größten Teil aber auch einen anderen Workflow). Selbst im "Idle" Zustand ohne Applikation zeigen die ARM Server einen Steal von 0,2-0,5%. Daher wollte ich auch einfach mal andere Erfahrungswerte hier erfragen. Mein Erfahrung muss ja nicht zwangsläufig auch übertragbar sein.

Ich selbst betreibe auch einige Container basierte Umgebungen. Die laufen mittlerweile fast alle auf ARM Servern. 80% der Container baue ich sowieso selbst. Da stelle ich selbst sicher, dass es diese auch für arm64/aarch64 gibt. Die anderen sind auch kein Problem. Probleme mit der ARM Architektur sind mittlerweile wirklich selten.

Ausnahme ist bzw. war z.B. Neuvector, was ich nicht zum Laufen bekommen habe. Das gab es lange nicht als ARM Version. Das hat sich jetzt aber wohl auch geändert. Das zeigt, dass man darauf definitiv auf ARM setzen kann, weil sich in die Richtung einfach sehr viel bewegt.

Zitat von andreas.

Der Unterschied zwischen der ARM und x86 Serie ist schon extrem.

Ist der x86 noch ein sehr alter Intel vServer?

Ja. Von der reinen CPU Leistung her deutlich langsamer als die ARM oder auch vergleichbare AMD Server, aber halt auch weniger Steal.

Sysbench (CPU - 1 Thread):

Mal eine allgemeine Frage in die Runde: Wie sehen denn eigentlich eure Steal Werte bei den ARM Servern aus? Beim Einrichten der neuen Server aus der Osteraktion ist mir aufgefallen, dass diese doch signifikant höhere CPU Steal Werte haben als vergleichbare x86 Systeme. Ich habe hier mal einen Vergleich von 3 Servern, die ähnlich aufgesetzt sind (k3s + einige Pods). Probleme stelle ich keine fest, auffällig ist es aber trotzdem.

Screenshot from 2024-04-02 17-17-20.png

Grün: ARM 1000 BETA (NUE)
Rot: ARM 2000 OST 24 (VIE)
Blau: x64

Zitat von peng

Für was nutzt ihr denn alle die ARMs das da so viele heiß drauf sind

Gibt es use-cases wo die ARMs beispielsweise eher einem RS1000/RS2000 mit x86 vorzuziehen sind?

Das die u.U. stromsparender sind mag ja sein, aber das dürfte beim Hosting für den Enduser sekundär sein.

Mehr Cores bei gleichem bzw. günstigeren Preis. Ich nutze diese mittlerweile sehr gerne für mein Kubernetes (k3s) Nodes. Bin jetzt gerade dabei meine Nextcloud auf den neuen ARM 2000 zu ziehen. Der lief vorher noch bei einem anderen Anbieter. Aber mit den Specs und 1TB Storage, war die Verlockung zu gross.

Falls jemand seinen ARM 500 nicht haben möchte, melde ich hier gerne mal Interesse an. Zum Kündigen ist er sicherlich zu schade. Da nehme ich lieber gerne noch einen ab Bei mir könnte er sich wunderbar als Build Runner machen. Das Rätsel selbst habe ich leider mangels Zeit gar nicht selbst machen können. Ostern ist halt doch Familienzeit.

Oh, hast du einen kleinen Hinweis, wo man die aktuell findet?

Zitat von VeePay

Knapp 50€ für Werbung find ich schon bissle hart.

Qualitativ ist der Hoddie aber wirklich gut. Sehr hochwertig. Aber wirklich nur was für die kalte Jahrezeit, da er sehr dick ist (im Vergleich zu herkömmlichen Hoodies). Den Preis ist er schon wert, wenn man denn einen netcup Hoodie haben möchte.

Zitat von engine

G11? Ich hab bislang nur 9.5 RS gefunden?

Achso. G11 habe ich doch glatt überlesen. Sorry. Die scheinen dieses Jahr noch nicht dabei zu sein.

Zitat von moepoi

Ich versuche, RS 1000 G11 Vienna zu finden, kann es aber immer noch nicht finden

Aktuell bei den Root Server Erweiterungen.

Falls jemand einen ARM Server findet, gerne melden Am liebsten den 2000. 1000 scheint es ja in VIE zu geben. Standort wäre mir egal.

Zitat von andreas.

Von der Theorie her müßte es schon reichen, wenn man die Domain fritz.box und *. fritz.box in seinem eigenen internen DNS-Server (PI Hole, Adugard, ...) die IP-Adressen 127.0.0.1 und ::1 vergibt und entlastet damit seine interne Firewall.

Ja. Im Grunde gibt es 2 sinnvolle Lösungen:
1. Upstream von fritz.box ändern und auf die FRITZ!Box zeigen lassen (sinnvoll, wenn man die Namen auflösen will/muss).
2. Die Domain (inkl. Subdomains) im internen DNS Resolver blockieren. Z.B. in Adguard als Custom Eintrag mit @@||fritz.box^$

Falls die FW nicht zufällig auch gleichzeitig der DNS Resolver ist, kann man sie dort ja sowieso nicht blockieren, da man ja ausgehenden DNS Traffic benötigt.

Zitat von extremmichi

naja aber vertraust du so einer Option?

wenn du nicht selber löschst, kannst du nicht sicher sein , dass es auch wirklich gelöscht ist.

Selbst löschen kann man ja immer vorher. Gäbe es so ein Flag, würde man aber direkt sehen, dass es eben nicht automatisch gelöscht wird und man ggfs. vorher lieber nochmal schauen sollte, ob man das tatsächlich so will.

Wobei das durchaus sinnvoll ist. Der Inhaberwechsel ist ja im Grunde genau dafür da, dass man einen bestehenden Server (inklusive Daten) in einen anderen Account transferiert. Ich hätte das auch genauso erwartet. Bei einem VPS200 ist das noch weitestgehend egal. Aber wenn man einen 1TB+ Server übertragen möchte, will man ja nicht vorher noch die Daten migrieren müssen. Gerade im Hinblick auf die neuen Richtlinien bzgl. der Brandbreite. Dass wir hier die Server untereinander tauschen ist ja nur ein Szenario, welches durch die Funktion abgedeckt wird. Auf der anderen Seite wäre es definitiv ein nettes Feature, wenn es während dem Inhaberwechsel ein Flag geben würde, welches man setzen kann, das dann die Daten automatisch löscht. Quasi als Option.

An dieser Stelle nochmal ein kleiner Hinweis an alle FRITZ!Box User mit eigenem DNS Resolver (PI Hole, Adugard, ...). Unbedingt die fritz.box Domain blockieren. Da die Domain mittlerweile im Public DNS ist und die fritz.box Domain über DHCP als Search Domain verteilt wird, hat man hier ein echtes Sicherheitsproblem, da man diese auch nicht deaktivieren kann. Ich hatte hier gerade ein Problem im Heimnetzwerk und bin da gerade ziemlich erschrocken. Man kann die Domain in der FRITZ!Box auch nicht deaktivieren, was eigentlich ein Unding ist.

Sonst passiert es schnell mal, dass man Daten an fremde Server schickt.

;; ANSWER SECTION:
foorbar.fritz.box.    86400    IN    A    45.76.93.104

Zeige mal den Inhalt von 000-default-le-ssl.conf. Das dürfte der Grund sein.

Zitat

Code

subjectAltName: host "munin.compi.dev" matched cert's "munin.compi.dev"

Also wenn du das Zertifikat nicht zufällig noch in einem anderen vHost verwendet hast, scheint er den vHost ja zu laden und auch zu benutzen, sonst müsste es hier zu einem Zertifikatsfehler kommen. Laufen auf dem Server noch andere vHosts (ls -l /etc/apache2/sites-enabled/)? Der Inhalt in var/cache/munin/www stimmt aber?

Teste den Zugriff bitte mal mit curl -v https://munin.firma.de und poste ggfs. den Output. Wie greifst du auf die Seite zu? IPv4, IPv6? Lass und das zu Beginn mal klären, nicht dass es evtl. schon daran liegt. Denn ein * lässt wohl Apache nur auf IPv4 hören. Es könnte sein, dass dein Default vHost auf IPv6 konfiguriert ist, du mit IPv6 zugreifst und daher nur die Default vHost Seite angezeigt wird.

Zitat von nitram

Ja das ist mir bewusst, dass die ja virtuell sind. Aber da steht halt "dediziert" im Text.

CPU überbucht != dediziert meiner Auffassung nach.
Wenn das jetzt wirklich Überbucht wäre, würde ja die Beschreibung nicht mehr stimmen. Wobei ich das eigentlich nicht glaube, weil dann müsste man ja bei top steal sehen.
Finde ich halt nur immer komisch.

Das liegt mir sehr hoher Wahrscheinlichkeit am Turbo Boost der CPU. Je leerer ein Node ist, desto höher die Wahrscheinlichkeit, dass die eigene VM davon profitiert. Der Turbo Boost hat sehr starken Einfluss auf diese Benchmark Werte. Da reicht schon ein minimal höherer Takt. Daher sind diese Werte auch kaum vergleichbar. Dafür müsste man entweder einen eigenen dedizierten (physischen Node) für sich haben oder aber den Turbo Boost komplett deaktivieren und den VMs nur den Basis Takt zur Verfügung stellen. Erst dann hätte man sinnvolle und auch vergleichbare Werte. Das hat weniger etwas mit Überbuchen zu tun, sondern dass manche VMs einfach einen zusätzlichen Bonus erhalten. Das ist aber eben nur ein Bonus, keine Leistung, die allen immer gleich zur Verfügung steht - dedizierter CPU Core hin oder her.

Zitat von ptervip

Now the performance is gradually declining, and it is unclear which score it will stop at.

The benchmarks are only useful to a very limited level. The CPU clock boost is more frequent on empty nodes, so you never know whether you had a turbo boost during a benchmark or not. Different circumstances, different results. That's why I generally don't like such benchmarks.