Posts by saremox

Quote from mmaark

Okay also reicht der Server aus , mit z.b hunderte Mitglieder, die registriert wären? Natürlich sind nicht alle gleichzeitig aktiv die Mitglieder,...

Es kommt hier sehr Stark darauf an was für eine Software du für deine Webseiten einsetzt und was das genaue Nutzungsverhalten ist. Wenn es ein Blog/Newsseite ist, wo ein großteil der Last sowieso damit reduziert werden kann durch entsprechendes sinnvolles Caching reicht das Teil wahrscheinlich auch für 1000 Tägliche Benutzer/Besucher.

Wenn da jetzt ein Forum drauf läuft und du 100 User hast ist die Last eine andere, aber auch da würde ich sagen reicht der Server aus.

Wenn das jetzt eine Nextcloud/Owncloud oder andere rechenintensive PHP anwendung ist muss man eben schauen wie das Verhalten von den 100 Users ist. Wenn da jeder einen Desktop Syncclient an hat und da ordentlich durch geht, kommt man da evtl bei einen VPS so langsam an dem Punkt wo in Peak Zeiten die UX (Ladezeiten und Reaktivität) schlechter werden könnte.

Wenn da jetzt ein Custom Written Browser game drauf läuft sieht es sowieso noch einmal ganz anders aus.

Was ich dir aber auf jeden Fall empfehlen kann ist, dir eine Software mal auf den Server zu installieren und laufen zu lassen die deine Systemlast aufzeichnet:

- UptimeKuma https://github.com/louislam/uptime-kuma - Ist eine Software die hier sehr gerne von Menschen im Forum genutzt wird. Natürlich macht das Monitoring im Sinne von "Ist die Webseite/Server gerade ausgefallen" nur dann Sinn wenn du das auf einen 2. Server laufen lässt. Wenn es jetzt aber erst einmal nur darum geht deine Systemlast mal schön aufzuzeichnen und dann dir die Graphen anzusehen ist das ein recht gutes Tool.
- Zabbix - Lernkurve ist hier wahrscheinlich etwas steiler, ist aber das Tool welches ich gerne für Traditionelle VMs nutze, das aber wohl auch eher aus Macht der Gewohnheit und weil ich dort bereits ein Setup habe mit Benachrichtigungen über ein Telegram Bot
- atop - Kleinen Tools was top/htop ähnlich die System auslastung aufzeichnet. Bedienung ist sehr gewöhnungsbedürftig.

Bonus punkte wenn du in die Software noch Metriken einfließen lässt wie "Anfragen / s vom Webserver", "Aktive Nutzer". Dann kannst du direkt deine Systemlast mit dem Nutzerverhalten korrelieren.

Quote from dalu

Ok ich hatte UEFI nicht aktiv.

Das Upgrade war gefühlt instant.

Habe UEFI nun an, und dank deiner coolen animierten Anleitung das 2. device ausgewählt, aber wenn ich enter drücke flackert es kurz und wenn ich raus gehe und continue passiert nichts. Es ist noch immer das standard device eingestellt, wahrscheinlich weil das System nicht per UEFI installiert wurde.

Seit Talos 1.11 installiert er nur noch den Bootloader der benötigt wird und nicht mehr beides. D.h. du müsstest damit es mit UEFI klappt mindestens einmal ein: talosctl -n <ip> upgrade machen über den boot mit der ISO. Hab das aber bisher selber noch nicht gemacht ein BIOS zu UEFI konvertieren mit Talos. BIOS geht ja gar nicht mit den ARM64 kisten.

Quote from dalu

Das Problem ist halt, BIOS meint vda ist boot disk und findet keinen boot sector o.ä. weil, wie bei dir ceph bluestore.

Und vdb hat das Talos system.

Shit ja da bin ich auch schon rein gelaufen. Deswegen hab ich diesen "Hack", dass ich als install drive vda (also immer die größere) nehme und dann das Ephemeral auf das LBS packe.

talosctl -n 192.168.32.10 get discoveredvolumes
NODE            NAMESPACE   TYPE               ID      VERSION   TYPE        SIZE     DISCOVERED   LABEL       PARTITIONLABEL
192.168.32.10   runtime     DiscoveredVolume   loop1   1         disk        672 kB   squashfs
192.168.32.10   runtime     DiscoveredVolume   loop2   1         disk        66 MB    squashfs
192.168.32.10   runtime     DiscoveredVolume   rbd0    1         disk        11 GB    ext4
192.168.32.10   runtime     DiscoveredVolume   sr0     1         disk        1.1 GB
192.168.32.10   runtime     DiscoveredVolume   vda     1         disk        1.1 TB   gpt
192.168.32.10   runtime     DiscoveredVolume   vda1    1         partition   2.2 GB   vfat         EFI         EFI
192.168.32.10   runtime     DiscoveredVolume   vda2    1         partition   1.0 MB   talosmeta                META
192.168.32.10   runtime     DiscoveredVolume   vda3    1         partition   105 MB   xfs          STATE       STATE
192.168.32.10   runtime     DiscoveredVolume   vda4    1         partition   1.1 TB   bluestore                r-storage
192.168.32.10   runtime     DiscoveredVolume   vdb     1         disk        54 GB    gpt
192.168.32.10   runtime     DiscoveredVolume   vdb1    1         partition   54 GB    xfs          EPHEMERAL   EPHEMERAL

Hilft dir jetzt natürlich nicht viel. Ich schaue mal gleich ob ich noch im Kopf habe wie ich damals das gefixt hab (muss dafür aber mal kurz eine node drainen, zum testen), dass zumindest das System wieder bootet. Gab beim UEFI von den ARM kisten zumindest eine Möglichkeit interaktiv explizit von der vdb zu booten.

EDIT:

TalosBootNetcupARM64UEFI-2.gif

EDIT2:

wahrscheinlich wurdest du aufgrund des Updates auf ein anderes Host System umgezogen. Nach meinen Verständnis verschwinden dann die EFI einstellungen die z.B. talos gemacht hat. Danach ist der Default wieder das auf der "Ersten" Block device nach einer EFI partition mit bootx64.efi/bootxaarch.efi gesucht wird.

Moderators würde mir wünschen wenn man die BootOrder der Block devices im SCP wählen könnte. Das würde sowas deutlich reboot safer machen und man bräuchte keine Hacks (die erst kürzlich mit Talos 1.11 möglich sind) brauchen, wenn man vda als Bluetstore für ein CEPH nutzen möchte.

I know mega special anwendungscase den nicht jeder hat. Wäre aber trotzdem mega toll

Ich betreibe auch ein 9 Nodes Talos Cluster bei Netcup mit ARM VPS. Hab da auch schon ein VPS Upgrade gemacht und das ging wunderbar. Das war aber mit einer Älteren Talos version irgendwann letztes Jahr, wenn ich mich richtig erinnere.

Wäre auf jeden fall cool wenn du deine Erkenntnisse hier weiter schreibst.

Ich habe auf der Maindisk vda eine Partition für Ceph Bluestore und ein 50 GB LBS für Ephemeral/System

machine:
  [...]
  install:
    bootloader: true
    image: factory.talos.dev/metal-installer/ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515:v1.11.2
    wipe: true
    diskSelector:
      size: ">= 128GB"
---
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
provisioning:
  diskSelector:
    match: disk.size < 128u * GB
  grow: true
  minSize: 16GB
  maxSize: 128GB
---
apiVersion: v1alpha1
kind: RawVolumeConfig
name: storage
provisioning:
  diskSelector:
    match: disk.size > 128u * GB
  grow: true
  minSize: 128GB

EDIT: ich habe irgendwann angefangen mit diskselector nach Größe zu arbeiten, weil ich einige Nodes hatte wo auf einmal das LBS device vda war (warum auch immer).

Quote from webdesignheld

Die KI hat den Schnipsel bekommen und den kompletten Mail Header von der Support email die an die gleiche Adresse ging an der die automatische Mail gescheitert ist. Ich wollte das auch nur berichten aber ich danke dir natürlich für die ausführliche Darlegung deiner Meinung zu dem Thema. Deine Auffassung wie der Schnipsel zu interpretieren ist teile ich, dazu braucht man ihn ja auch nur lesen.

Wenn nicht Hilfe beim Debugging oder Verstehen von dem E-Mail Zustellproblem, was war deine Intention das hier zu posten?

Dir ist bewusst, dass eine Automatische E-Mail, auch wenn sie über den gleichen SMTP-Relay Provider gesendet wird, anders von z.B. rspamd (Ist jetzt eine Stellvertreter Software, andere Software wird wahrscheinlich nach ähnlichen Metriken die Mail bewerten) gewertet wird als eine Support Antwort oder? Oder das der MTA der es raussendet in dem Fall eine Andere IP sein kann, die vielleicht eine bessere Reputation hat?

Quote from webdesignheld

Please forward this to your mail operations team.
My domain is example.com. Your automated mail system reports
“550 [S10] Blocked” from mx1.mailchannels.net [18.236.29.166] when
sending verification emails. Your support replies arrive normally
(from 213.133.106.242 via MailChannels inbound).
This appears to be a MailChannels-to-MailChannels internal block.
Could you request MailChannels to delist your transactional relay IP?

Display More

Und das ist, mit den Informationen aus dein Posting, der Grund warum man nicht alles so in eine KI pusten sollte. Besonders wenn man, selbst sagend, keine Ahnung davon hat.

In dem Schnipsel den du vom Support bekommst steht, meiner Auffassung nach, eben nicht das mx1.mailchannels.net die Mail ablehnt. Sondern das mx1.mailchannels.net versucht sie zuzustellen und vom dem MX deiner Mailbox ein 550 bekommt.

Da du hier leider auch nicht sagst wo deine Mailbox liegt (Nectup Webhosting, Mailkuh, Mailbox, whatever) kann man hier auch gar nicht großartig weiter helfen zu debuggen oder eine Sinnvollere Antwort mit dir zu formulieren als das von der KI.

KI ist mega toll und ein sehr gutes Tool Aufgaben die man selbst schon verstanden hat in vielen Fällen mit den richtigen Prompt schneller zum Ergebnis zu kommen. Man sollte aber in der Lage sein durch sein Wissen die Antwort von der KI zu bewerten. KI kann sehr viel schneller das gewünschte verhalten in ein Bash script von 100-200 Zeilen runter schreiben, aber ich muss das dann auch lesen können und beurteilen ob das korrekt ist. Wenn ich keine Ahnung habe von Automatisierung mit Bash, ist das einfach nur Roulette spielen und hoffen das es korrekt ist...

Btw ich korrigiere lieber Schreibfehler von anderen in einer Konfiguration, als Ständig AI-SLOP lesen zu müssen. Also falls du interessiert bist dein Problem zu debuggen kannst ja erstmal von Vorne anfangen:

• Wo liegt deine Mailbox?
• Hast du zugriff auf die SMTP Logs?
• Ist ein Spam Filter aktiv?
• Hast du Blocklisten aktiv (Spamhaus, UCEPROTECT etc. pp.)?
• Überprüfst du DKIM / SPF / DMARC?

Falls dir etwas aus der Liste unbekannt vor kommt oder du nicht genau weißt was es bedeutet frag entweder hier nach oder Google es einmal kurz.

Und weil ich aufgrund von Geekbench6 Ergebnissen auf eigener Hardware mal nachgeschaut habe, sollte man die Multi-Core Werte vom Yabs Benchmark mit GB6 etwas mit Vorsicht genießen:

Quote from GB7 Internals, Page 7

Geekbench 6 uses a “shared task” model for multi-threading, rather than the “separate task” model used in earlier versions of Geekbench. The “shared task” approach better models how most applications use multiple cores.

The "separate task" approach used in Geekbench 5 parallelizes workloads by treating each thread as separate. Each thread processes a separate independent task. This approach scales well as there is very little thread-to-thread communication, and the available work scales with the number of threads. For example, a four-core system will have four copies, while a 64-core system will have 64 copies.

The "shared task" approach parallelizes workloads by having each thread processes part of a larger shared task. Given the increased inter-thread communication required to coordinate the work between threads, this approach may not scale as well as the "separate task" approach.

Bei einen 24 Kern Root-Server, lässt man ja meist eher mehrere Anwendungen (php-fpm und andere Server Client Anwendungen, Datenbanken, Caches, etc. pp.) parallel laufen, die dann ein anderes Skalierungsverhalten haben als ein Prozess mit 24 Threads und Synchronisierung zwischen diesen.

Was mich noch wundert ob SMT deaktiviert ist auf den Hosts? Sind es 24 Physische Cores oder 24 Threads die in die VM gegeben werden.

AWS beispielsweise reicht teilweiseThreads durch, es wird aber transparent auch einen gesagt wie viele Physische Cores man bekommt. Beispiel:

Wenn es SMT Threads sind, könnte das evtl. auch erklären was hier einige sehen... Das wäre dann aber, in meinen Augen, falsches Marketing... Dann ist die Performance die man bekommt ja immer Wundertüte.

Quote from sla

Bei nur 50% der Leistung die ich davon nutzen kann, kann man schon über eine Rechnungsminderung nachdenken. Da scheint richtig was im Argen zu sein

Glaube das wird nichts. Du hast keinen Anspruch auf eine bestimmte Leistung hier. Der Vertrag sagt du bekommst Exklusiv 128 GiB Memory und 24 Kerne.

Da ist keine Garantie, dass du zu jeder Zeit immer die Performantesten Cores im Maximalen Turboboost bekommst. Wenn gerade alle auf dem Host ihre V-Server auslasten, gibt es halt für jeden nur maximal den All-Core Boost clock, der ist natürlich nicht so schnell, als wenn du der einzige auf dem Host System bist der gerade Last erzeugt und damit den vollen Turboboost abgekommst.

Ich glaube Netcup würde sich selbst einen Gefallen tun, wenn sie einfach den Turboboost im Bios/Firmware deaktivieren.

Edit: Aus den Specs der CPU:

Max. Boost-Taktung: Bis zu 3.7 GHz

All Core Boost Speed: 3.3 GHz*

Grundtaktung: 2.3 GHz

Wenn du in dem Moment nur den Baseclock abbekommst ist es halt 1,5 Ghz weniger. Das macht halt schon etwas aus bei IO und Geekbench

*EPYC-21: All-core boost for AMD EPYC™ processors is the average frequency of all processor cores running in performance mode while utilizing a low activity workload. Actual achievable all-core boost will vary based on hardware, software, workloads and other conditions.

Quote from m-k

Auf 10Mbit/s kann man ja offensichtlich begrenzen, die 1Gbit/s gehen nicht, auch wenn bei mir nur maximal diese ankommen. Leider kenne ich mich nicht im Detail mit dem Wireguard Protokoll aus, kann mir aber nicht vorstellen, dass der Gegenpart mit angeblich bis zu 20Gbit/s verschickt, wenn mein RS nur 1Gbit/s entgegennehmen kann.

Wireguard läuft i.d.R. über UDP. Die Senderseite muss hier dann den Traffic begrenzen. Ein Limit (Hard & Softwareseitig) auf Empfängerseite führt jetzt nicht automatisch dazu, dass die Senderseite die Senderate reduziert. D.h. wenn deine Sendeseite ein 10Gbit Anschluss hat, machst im Zweifel dein 10Gbit Link voll wenn die Sende-CPU das schafft.

Unter Debian/Unbuntu nfs-common installiert? Was sagt

 # which mount.nfs4
/usr/sbin/mount.nfs4
 # which mount.nfs
/usr/sbin/mount.nfs

Quote from monospacedmagic

Leider scheint auch die Konfiguration via Kernel-Parameter nicht zu funktionieren. Hier ist der Parameter, mit dem ich es versucht habe, als Beispiel:

ip=123.45.67.89/22::123.45.64.1:255.255.252.0:yourhostname:ens3:off::::

Die Kernel Parameter funktionieren bei Factory talos meist nur für die Update OCI images. Grundsätzlich hab ich es noch nie gehabt, dass die Kernel Parameter bei den Raw Disk Images funktionieren.

Du kannst die Machineconfig von Talos als CloudInit ablegen. Du musst dann aber ein nocloud image verwenden anstatt eines metal image. Wichtig ist, dass du dann in der Machineconfig bereits die IP's aus dem SCP hinterlegst:

machine:
  [...]
  network:
    hostname: w1.egg.eggcellent.cloud
    interfaces:
      - addresses:
          - 152.xxx.xxx.xxx/22
        deviceSelector:
          hardwareAddr: xx:xx:xx:72:a7:bb
        dhcp: false
        mtu: 1500
        routes:
          - gateway: 152.xxx.xxx.1
            network: 0.0.0.0/0
# Falls vorhanden VLAN hinzufügen, sinnvoll wenn du mehr als 1 node hast und darüber das Cluster Netz aufbauen willst
      - addresses:
          - 192.168.xxx.xxx/24
        deviceSelector:
          hardwareAddr: xx:xx:xx:72:a7:bc
        dhcp: false
        mtu: 1500
 [...]

Ich habe das aber bisher auf Netcup nicht getestet. Unter Proxmox bei mir auf der Arbeit funktioniert es darüber aber wunderbar.

Edit: Okay gerade getestet mit dem NoCloud image. Ist in die Hose gegangen, man kann bei einen Custom Image leider bei Netcup kein CloudInit mitgeben Ich setzte dann mal meinen einen Worker neu auf

Moin,

du musst sehr wahrscheinlich über das Talos Dashboard die Konfiguration vom Netzwerk Interface vornehmen. DHCP funktioniert hier leider nicht ganz so gut. Grundsätzlich ist hier über das SCP dein Freund zum debuggen. Hab bei Netcup aktuell ein 6 Nodes Talos cluster am werkeln. Kann also bestimmt die ein oder andere weitere Frage beantworten

Viel Erfolg und Spaß!

LMGTFY

pasted-from-clipboard.png

Quote from mainziman

od. auch nicht; ein ARM-Core ist was anderes als ein x86-Core

https://www.elektronikpraxis.d…32cd605f35d17648310a6ca7/

(Hauptunterschied: RISC vs. CISC)

Es gibt durchaus workloads die mit der ARM64 Befehlssatz, bei ähnliche Core/Thread Anzahl durchaus mithalten oder sogar schneller sind als x86 cores. Die Generelle aussage, dass ARM/RISC grundsätzlich langsamer ist als x86/CISC ist meiner Meinung nach nicht mehr genau genug.

Hier einmal kurz ein Geekbench von paar x86/arm kisten die ich hier so herumstehen habe. Natürlich waren alle Kisten nicht nackt und da lief Monitoring und paar andere Dienste drauf. Würde also sagen das die nicht ganz genau sind und bei den VPS ist es ja auch immer die Frage wie laut die Nachbarn sind.

Also zumindest laut Geekbench 6 kann ein arm64 core gar nicht mal so schlecht mit einen RS G9.5 core mithalten. Wichtig ist natürlich das man trotz aller tollen Benchmarks immer vorher schaut ob der spezifische Workload auf der Architektur läuft oder überhaupt eine ARM64 binary gibt.

Zumindest für die Neoverse N1 hat z.B. meines Wissens Amazon auch einige patches für PHP submitted damit es performanter läuft. (Die Graviton nutzen in einer Generation auch die Neoverse N1 cores meines Wissens).

Also fände kleine ARM64 kisten mit 2 vcores durchaus interessant als Gateway server für Haproxy und SSL termination. Sind zumindest deutlich fixer als die VPS nano die ich gerade dafür verwende.

Quote from H6G

Im SCP? => Support

Edit:
Stimmt denn der Serverstandort mit dem VLAN Standort überein?

Jop im SCP und Standort ist bei allem NUE. Hab sogar für Debug zwecke ein free vlan NUE hinterher bestellt. Auch mit den frischen VLAN sind alle 3 nicht startbar. Mal gucken evtl. bemühe ich am Tag den Notfall support falls ich noch keine Antwort auf mein E-Mail Ticket bekomme. Würde schon sehr gerne das Wochenende zum aufsetzen benutzen. Wollte aber niemand jetzt um die Uhrzeit wach klingeln.

Quote from Paul

Das halte ich daher in der Praxis für keine gute Idee.

Effektiv wird das aber z.B. bei AWS ELB gemacht. Wenn dort eine eine von den 3 Endpunkten für maintenance rausgenommen wird, kommt eine neue IP dazu. Deswegen soll man da mit einen CNAME arbeiten statt die A Records vom LB zu setzen. Aber wahrscheinlich sperrt man dann alle mit den faulty DNS resolvern aus.

Nachteil an der Failover IP ist halt auch, dass man kein DNS Load Balancen zwischen seinen Servern dann hat. Außer man bucht sich direkt 2-3 Failover IPs auf denen man dann auflöst und dann im Failover fail ein Server 2 IP zugeordnet hat.

Bei mir gings auch flott

Nur leider gehen bei allen 3 das VLAN nicht. Sobald ich ein VLAN NIC hinzufüge bekomme ich den Generischen Fehler dass etwas nicht geht

Wenn ichs VLAN wieder entferne geht's sofort wieder. Evtl möchte mir Netcup auch nur sagen das ich schlafen soll anstatt server einzurichten

Quote from User_unknow

Wenn man einen Standort bei der Bestellung bucht, sollt der auch korrekt sein. Schliesslich wird manchmal standortbedingt ein Aufpreis verlangt.

GeoIP Dienste Standort != Realer Standort. Je nachdem wann der Dienst auf den du Zugreifen willst zuletzt seine GeoIP Datenbank aktualisiert hat kann es auch wochen Dauern bis die den Korrekten Standort haben. Das kann Netcup hier nur bedingt beeinflussen (insbesondere, wann die Diensteanbieter ihre Kopie Aktualisieren).

Quote from Janko

ungünstig konfigurierte Spam-Prüfung.

Die Erklärung, warum es mit Off-the-shelf MTA und Anti Spam Lösung zu 5-6 Sekunden kommen kann wurde bereits mindestens einmal gegeben: Backscatter. Dadurch das die E-Mail beim MTA erst nach der Spamprüfung in die Queue eingefügt wird, verhindert man bei einer Positiv Meldung (E-Mail ist Spam) das versenden einer Mailer-Daemon E-Mail an den Absender. Es ist auch der bevorzugte Weg, dass bereits beim Enqueue sehr viele Checks passieren, gerade wenn man die Postfächer auch für den Versand per PHP/JS etc. pp. nutzt. Dadurch kann die Anwendung nämlich auf den Misserfolg reagieren.

Ich musste schon einmal mit einen MTA arbeiten, der genau das nicht gemacht hat. Der hat fröhlich alles angenommen, nur um dann schöne Mailer-Daemon Nachrichten zu verschicken, dass wegen irgendwas die E-Mail nicht versendet wird. Schön blöd das für die Laravel Anwendung dann die E-Mail als "Erfolgreich Versand" markiert waren und es deshalb kein Retry dann gab ...

Lösung für dein konkretes Problem mit Thunderbird:

Es ist btw, in Thunderbird durchaus möglich das "Versenden" in den Background zu packen:

pasted-from-clipboard.png

Das ist default auf false, dass es noch known issues geben soll: https://wiki.mozilla.org/Thund…estPlans/SendInBackground.