Beiträge von Paul

Zitat von p3nnyman

Ja, das mag wohl der Hauptgrund gewesen sein. Aber der Raspberry wäre ja auch ein mögliches Endgerät.
Welche wäre denn dann für einen ARMen-Server die zu präferierende Distri? Debian ARM oder ein BSD?

Aus Bequemlichkeit würde ich Debian nehmen Einfach weil es das als fertiges Image schon gibt und man so automatisiert auch seinen SSH Key direkt konfiguriert bekommt. Auch passt dann direkt die Netzwerkkonfiguration (ink. IPv6). Wenn der Aufwand keine Rolle spielt, kann ich auch Fedora wärmstens empfehlen. Sehr stabil und zuverlässig (sowohl amd64 als auch aarch64). Darauf setze ich z.B. bei meinen Systemen, die wirklich wichtig sind (z.B. Mailserver).

Wobei EndeavourOS eher ein reines Desktop OS ist. Und der Desktop Markt ist dann doch noch sehr stark von x86 dominiert. ARM findet man hier wirklich sehr selten. Daher hat es sich vermutlich einfach nicht gelohnt. Kann ja durchaus sein, dass sich das in Zukunft nochmal ändert. Der ARM Support in Archlinux ist generell noch so ein wenig dürftig. Da sind andere Distributionen deutlich weiter.

Zitat von tab

Schneller ist natürlich immer besser. Ab wann die IO zum Flaschenhals wird, kann man wohl nicht pauschal sagen. Werden die Seiten aus einem effektiven Cache ausgeliefert oder werden sie bei jedem Aufruf neu per PHP erzeugt? Ist open_basedir aktiviert (und damit der realpath-Cache deaktiviert)? Wie schnell ist der Core? Wie schnell ist die Netzwerkverbindung? Und und und ... Je nachdem wird die IO eben ab einem anderen Wert zum Flaschenhals.

Habe gestern Abend einige Erfahrungen sammeln dürfen, die auch hier reinspielen und über die ich erst mal nachdenken muss. Eine (aus Gründen) nicht gecachete Website habe ich auf unterschiedlichen Hostings und Servern mal durch Lighthouse gejagt und mir die Zeit für das Stammdokument angeschaut, das also bei jedem Aufruf neu berechnet wurde. Mit Abstand am schnellsten war der VC1-1 (120ms) , deutlich schneller als der ARM 2000 (320ms). Hmmm. Naja, der Core ist halt einfach schneller, YABS Singlecore ca 1400 vs 1100. Das allein reicht dafür aber wohl noch nicht. Ok... Netzwerkanbindung? Die IO ist es jedenfalls nicht, das verfügbare RAM auch nicht. open_basedir bei beiden inaktiv. Ich fürchte, damit hat der VC6-16 ein paar Pluspunkte dazugewonnen im Vergleich zum ARM 2000, der ihn eigentlich ersetzen soll. Das muss ich mir jetzt erst mal irgendwie schönreden

Steht dein ARM 2000 in Wien oder Nürnberg? Interessanterweise habe ich mit meinem neuen ARM 2000 ähnliche Beobachtungen gemacht. Gefühlt laden die Seite nicht merklich schneller und irgendwie wirkt alles etwas träge ohne es genau greifen zu können. Ok, der Steal ist recht konstant bei ~2%. Aber darauf alleine will ich es nicht schieben.

So pauschal lässt sich das natürlich schwer sagen. Die Brandbreite (MB/s) ist da auch weitestgehend egal (solange sie nicht völlig schlecht ist). Entscheidend sind da eher die Latenz der Lese und Schreibzugriffe und auch die IOPS Limits. Man sieht es wohl am ehestens daran, wenn die iowait Werte eines Servers hoch sind. Das zeigt, dass die CPU auf die Disk warten muss. Solange also der iowait Wert niedrig ist, sollte die Disk also nicht der Flaschenhals sein.

In den meisten Fällen dürften wir hier ja von einem Szenario ausgehen, bei dem man sowieso Vollzugriff auf das System hat, weil es man selbst dafür verantwortlich ist bzw. den Auftrag dazu hat. Ich melde mich hier einfach mal aus dem Lager der Befürworter der Root-Shell zu Wort. Persönlich nutze ich sudo nur um eine echte Root Shell (z.B. sudo -i) zu erhalten. Andere Befehle werden so gut wie nie mittels sudo ausgeführt. Das hat einen recht simplen Grund: Die Root Shell unterscheidet sich optisch (prompt) von der Shell eines normalen Users. Entweder weil das die Distribution schon so standardmäßig ausliefert (eher die Regel) oder weil man das selbst so konfiguriert hat. Daher wird hier ja gerne eine Warnfarbe (rot) genutzt. Ich sehe also direkt, dass ich hier in einer "gefährlichen" Umgebung arbeite. Gerade wenn man (wie ich z.B.) sehr viele Systeme administriert und es im Alltag daher schnell mal dazu kommt, dass man auch sehr viele Terminals offen hat, ist ein optischer Hinweis mehr als nützlich. Ein Befehl ist sonst sehr schnell in dem falschen Terminal eingegeben. Daher kann ich aus Erfahrung sagen, dass man sich manchmal auch am besten vor sich selbst schützt, wenn man optische Hinweise hat, die man nicht so einfach ignorieren kann. Das hat man halt nicht, wenn ich einfach nur vor jeden Befehl ein "sudo" setze. Das wird auch gerne mal zur Gewohnheit und man macht es, obwohl man es gar nicht bräuchte und hat dann auf einmal ganz andere Probleme.

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