Beiträge von Paul

  • Das längste Thema

    Gefühlt sind die ARM Server deutlich näher an den RS als an den VPS Servern. Das sieht man auch an den 2,5 GBit/s, die die ARM Server ebenfalls haben. Die reine CPU Leistung ist ebenfalls top, wenn nicht sogar besser. Zumindest in meinem Fall schlägt der ARM Server meinen RS 9.5 doch deutlich (sogar in der Single Core Leistung, +100%). Bleiben die 99,6% vs 99,9% Verfügbarkeit. Aber das ist halt erst einmal nur eine Zahl auf dem Papier. Die Praxis sieht das dann oft nochmal etwas anders aus und da habe ich in den vielen Jahren eigentlich keinen Unterschied zwischen VPS und RS feststellen können. Die waren beide eher 99,9%. Das würde ich aktuell daher auch bei den ARM Servern erwarten. Schauen wir mal wie es dann in ein paar Monaten ausschaut, wenn die Hosts etwas ausgelasteter sind. Aber Stand heute bin ich äußert zufrieden mit den ARM Servern bei Netcup. Stört mich persönlich gar nicht, dass da kein RS im Namen steht. Denn die Leistung spricht aktuell für sich.

  • Das längste Thema

    Zitat von aRaphael

    Seufz. Ich muss demnächst Server neu aufsetzen (kein Problem :)) und mich entscheiden wo. (Esel - Heuhaufen ^^)

    Ein Dedi bei H. wird ausgemustert und soll auf 2-3 Virtualisierte verteilt werden.

    Und ich kann mich nicht zwischen den netcup ARM und den ARM-Cloudservern bei H. entscheiden... ;(


    (Ich weiß, das ist ein netcup-Forum und ich will hier auch garnicht das Für- und Wider diskutieren. Ich wollte einfach nur mal laut seufzen. ^^ Also ignoriert diesen Beitrag einfach... ;) )

    Das schöne an den neuen ARM Servern ist ja, dass sie (im Gegensatz zu den BETA Servern - irgendwie auch komisch) nur eine Mindestvertragslaufzeit von 1 Monat haben. Daher spricht doch alles dafür, dass einfach mal zu testen. P/L spricht definitiv für Netcup. Einfach mal temporär in beiden Umgebung Server aufsetzen. Sonst wirst du dich ständig fragen müssen, ob das nicht woanders doch besser laufen würde. Manchmal ist es daher besser, direkt von Anfang an Nägel mit Köpfen machen und beides testen.

  • Das längste Thema

    Zitat von aRaphael

    docker kommt mir nicht in die Tüte ;)

    Wobei ich mir das in diesem Fall wirklich nochmal überlegen würde ;). Sich das System mit NodeJS Abhängigkeiten und NPM zu verbasteln, ist jetzt auch nicht unbedingt die schönste Lösung. Zumal man ja gerade bei NodeJS oft darauf achten, muss, dass die benötigte Version auch der entspricht, die man für das Projekt gerade benötigt. Unter Umständen ist hier auch wieder eine zusätzliche Quelle nötig. Genau aus diesem Grund läuft bei mir alles NodeJS-basierte grundsätzlich in isolierten Containern. Bei Golang kann ich es noch verstehen, wenn die Installation im Grunde nur daraus besteht, dass man ein Binary herunterlädt und als unprivilegierter User laufen lässt. Da hat man dann im Grunde dieselbe Isolation wie in einem Container. Aber gerade, wenn dann noch zusätzliche Abhängigkeiten mit ins Spiel kommen oder bestimmte Versionen einer Sprache benötigt wird, spielen Container ihre Stärken aus, weil man dann auch das eigentliche OS aktualisieren kann ohne sich Gedanken machen zu müssen welche Applikation man damit evtl. kaputt macht.


    Man darf auch die Updates nicht vergessen. Mit Docker startet man einfach den Container mit einem neuen Tag. Die manuelle Installation von uptime-kuma muss dann wieder mit npm gemacht werden. npm hat eigentlich auf einem produktiven System auch nichts verloren. Das sollte eher der Entwicklung dienen, wo man ein fertiges Paket baut, das dann wiederum auf Prod ausgerollt werden kann. Wobei das natürlich auch etwas an mir liegen könnte, weil ich da noch etwas aus der alten Schule komme. Hier werden neue Applikationen grundsätzlich nur in Dev gebaut, dann getestet und anschließend erst über einen sicheren Weg in Prod ausgerollt.

  • Das längste Thema

    Zitat von aRaphael

    Hmmm... Wollte gerade Uptime Kuma installieren, aber die Standardseite für den Download des Installskripts funktioniert nicht mehr:

    https://git.kuma.pet/install.sh


    Muss ich mal nach Alternativen suchen....

    (Oder node/npm/pm2 doch manuell installieren)

    Ich empfehle das offizielle Docker Image: https://hub.docker.com/r/louislam/uptime-kuma

    Bei solchen Installationsskripten wäre ich generell vorsichtig. Ich weiß, dass das momentan ziemlich in Mode ist und viele Projekte das so anbieten. Aber ein unbekanntes Skript aus dem Internet herunterladen und mit Root Rechten ausführen ist so mit das letzte was man eigentlich machen sollte. Ich würde von dieser Art der Installation generell abraten. Ja, est ist komfortabel und meist funktioniert das auch zuverlässig, aber es ist halt so eine Grundsatzregel, dass man das eigentlich nicht machen sollte. Genauso wenig wie man unbekannte Code Schnipsel nicht einfach so C&P sollte.

  • Das längste Thema

    Zitat von andreas.

    Das ist ein Tarif noch aus der Steinzeit und war nur für die vServer mit der Typenbezeichnung RS gedacht

    Oh, da werden Erinnerungen wach. Die Root Server L haben mir damals treue Dienste geleistet. Sogar mit einem speziell für diese kompilierten Kernel und Gentoo als OS. Deswegen auch bewusst die dedizierten Cores. Das war damals gar nicht so üblich und eher was besonderes. Die angegebene Verfügbarkeit war zwar "nur" 99,6%, tatsächlich kam das aber auch schon damals eher an 99,9%+ heran. Die Stabilität/Verfügbarkeit war eigentlich schon immer eine der Stärken von Netcup. Damals gab es halt auch noch keinen Unfug wie DNSSEC ^^.

  • der netcup Adventskalender startet wieder

    Immerhin ist das auch eine Premiere. Das erste Türchen, das länger als 24h bestellt werden kann! ;) Das hatten wir so auch noch nicht und ist daher wirklich mal eine Überraschung. Finde ich persönlich sogar besser als zum x-Mal den gleichen VPS oder RS, die es dieses Jahr sowieso jeden Monat im Angebot gab.

  • Für was sammeln manche kleine Server?

    Hier kommen solche kleinen Server (ich gehe mal davon aus, wir sprechen hier von den 1 vCore Produkten a la VPS 200 G8, VPS Piko) vor allem hierzu zum Einsatz:
    * Jumphost / MGT-host (pro Umgebung einer)

    * Git (Gitea, konnte nun nach vielen Jahren meinen fetten Gitlab Server ablösen)

    * Testserver (für Mail, Web, DB & Co. Im Grunde eine 1:1 Kopie von Prod, aber ohne Last - Test von Updates von Konfigurationsänderungen)
    * Dev (Vorab Tests von neuen Major OS Versionen, Weiter/-entwicklung von Ansible & Co.)


    Für meine Monitoring Server braucht es dann aber schon 2+ vCores, wobei das fast auch noch unter klein fällt. Da kommt in Summe also schon was zusammen. Da ist es immer praktisch, wenn man mal für einen spontanen Test so 1 bis 2 auf Halde hat, die sonst nichts zu tun haben ;) .

  • Das längste Thema

    Zitat von Paul

    ...

    Auch wenn ich die Seite als Tab öfter mal im HIntergrund offen gelassen habe, hat mich die Anzahl an Queries doch etwas verwundert. Aber nach kurzer Analyse war die Sache dann doch recht simpel. Meinen systemd-resolved hatte ich so konfiguriert, dass nur positive Antworten im Cache landen. http://www.servercontrolpanel.de ist aber nur über IPv4 erreichbar und hat keinen AAAA record.

    Code
    → Q: www.servercontrolpanel.de IN A
→ Q: www.servercontrolpanel.de IN AAAA
← S: success
← A: servercontrolpanel.de IN SOA root-dns.netcup.net dnsadmin.netcup.net 2023103101 28800 7200 1209600 7200
← A: www.servercontrolpanel.de IN A 46.38.225.84

    Der resolvectl monitor Befehl war hier recht nützlich (falls ihn wer noch nicht kennen sollte). Ich habe das jetzt mal umgestellt, so dass auch "negative" Antworten im Cache landen. Der Traffic bzw. die Queries waren zwar nur im lokalen Netzwerk, aber trotzdem. Ist schon heftig wie viele Anfragen da so zusammen kommen.

  • Domainerreichbarkeit über www und ohne www

    Zitat von Bond007

    Der einfachste Weg für wäre quasi nun für meine www-Seite eine Subdomain ohne www zu erstellen und dann eine Weiterleitung von der www-Seite auf die Subdomain einzurichten?

    Genau. Vermutlich hast du das nur etwas durcheinander gewürfelt in dem letzten Abschnitt. Aber am besten fängst du mal an, den Blog genau unter der Adresse einzurichten, die gewünscht ist. Sobald das steht und fertig ist, kannst du auch die andere(n) Domain(s) einrichten und konfigurieren. Wichtig wäre eben nur, dass dafür ein anderes Stammverzeichnis gewählt wird, damit das nicht auf den gleichen Inhalt zeigt.

  • Domainerreichbarkeit über www und ohne www

    Generell gilt eigentlich die Regel, dass eine Webseite immer nur über eine Domain erreichbar sein sollte. Andere Domains können zwar gerne konfiguriert werden, diese sollten aber immer nur Weiterleitung auf die Hauptdomain sein. Hintergrund ist einfach, dass es in Suchmaschinen sehr oft abgestraft wird, wenn der gleiche Inhalt unter mehreren Domains erreichbar ist. Technisch wäre das an sich kein Problem. Aber gerade ein Blog ist ja meist etwas, das Reichweite generieren möchte. Und gerade da sollte man auf solche Dinge Rücksicht nehmen.


    Meine Empfehlung wäre daher eine Weiterleitung. Am besten konfigurierst du beide Domains (www und ohne www) als eigenständige Hostings mit eigenen Document Roots. In das Document Root der Domain ohne www legst du dann eine htaccess mit der Weiterleitung auf die www Subdomain. Das hat den Vorteil, dass du auch eine Weiterleitung für SSL konfigurieren kannst (Häkchen bei Letsencrypt setzen).