Fokussiere dich nicht so sehr auf die Benchmark Ergebnisse. Diese sind nicht sehr aussagekräftig, da die Tests nur 3-4 Sekunden liefen. Da wird man natürlich kaum große Unterschiede feststellen können. Unter dem Strich sind die RS klar besser als die VPS (kann ich aus eigener Erfahrung bestätigen). Lass die Benchmarks mal länger laufen, dann werden die Unterschiede größer.
H6G hat das eigentlich schon gut zusammengefasst. Die RS Server sind insgesamt den VPS in allen Punkten zwar nicht viel, aber dennoch überlegen (Bessere CPU Leistung, bessere Memory Leistung, mehr IOPS). Hinzu kommt dann noch die etwas höhere Verfügbarkeitsgarantie (99,9%). Kosten daher auch etwas mehr.
Ich persönlich würde zu dem RS greifen, wenn ich die Wahl hätte. Deine Projekte sind ja doch auf eine längere Laufzeit ausgelegt. Da wirst du nicht so oft die Server wechseln wollen. Das merke ich ja auch an meinen eigenen Projekten. Die kurzen Vertragslaufzeiten klingen zwar erst einmal gut, aber die muss man auch nutzen um davon wirklich zu profitieren. Meine Server laufen dann meist doch so lange, dass ich auch mit den Vertragslaufzeiten eines RS gut auskommen würde, auch wenn die längere Laufzeit vielleicht im ersten Moment abschreckt.
Black Friday kommt demnächst zwar. Der Adventskalender aber auch. Dann kommen vielleicht Neujahrsangebote, Frühjahrsangebote, Ostereier, ... Mit dem Warten ist das immer so eine Sache 
Beiträge von Paul
-
-
Naja meine Gedanken waren ja eher nur der Speicherplatz und der ist beim VPS500 und beim RS1000 sowieso gleich (40GB SSD), daher da macht es keinen Unterschied welchen Server ich nehme und ich glaube 4GB reichen für Mailcow....
Du wirst ja nicht ohne Grund nach dem Arbeitsspeicher DDR3 vs. DDR4 gefragt haben ;-).
Einen kleinen bzw. nicht ganz so kleinen Unterschied macht es schon, ob du jetzt einen RS oder einen VPS mietest. Beim RS hast du eine Verfügbarkeitsgarantie von 99,9%, beim VPS "nur" 99,6%. Beim RS hast du dedizierte CPU Kerne, beim VPS nicht. Auch ist die Leistung der SSD beim RS etwas besser als beim VPS.
Klar hast du beim VPS hingegen die stundenbasierte Abrechnung. Aber einen produktiven Mailserver kündigt/migriert man eben nicht so schnell. Das kann schnell mal richtig eklig werden, wenn du die IP deines Mailservers ändern willst. Daher ist ein Mailserver eigentlich eher für längere Zeit geplant und da stört dann auch die Mindestvertragslaufzeit eines RS nicht so sehr. -
Bei den Rootservern ist ja angegeben, das es sich dort um DDr4 Ram handelt, bei den VPS steht allerdings nichts, weiß einer was da verbaut (DDr3 / DDr4) ist?
Netcup legt sich hier bewusst nicht fest. In meinen Benchmark Ergebnissen kann ich aber sehen, dass der Arbeitsspeicher auf einem RS etwa 20% schneller ist als auf einem VPS. Das variiert natürlich auch etwas von VPS zu VPS.
Aber jenseits von Benchmarks wirst du da keinen Unterschied merken. Vor allem nicht bei der Mailkuh. Da sind Disk und CPU Performance deutlich spürbarer.
Mein Tipp: Nimm den RS1000 mit SSD, wenn du dir wirklich Gedanken über die Performance machst. -
Der VPS 200 war ja sowieso nur ein Testserver, auf dem ich ein paar Anwendungen ausprobiert hatte und für den Live-Betrieb wird ein VPS 500 benötigt, daher habe ich keine Datenverluste und Kündige ihn einfach und buche den neuen VPS 500....
Warum kündigen? Einen Testserver kann man immer gebrauchen. Gerade für den produktiven Betrieb lohnt es sich immer, einen möglichst identisch konfigurierten Testserver dauerhaft zu betreiben. Es stehen immer mal Anpassungen der Konfiguration / Updates an, die vorher getestet werden wollen. Gerade bei einem Mailserver, bei dem im schlimmsten Falls Mails verloren gehen, sollte man das in Erwägung ziehen.
Überlege dir das also durchaus mal. -
Server Umzüge sind auch immer eine sehr gute Möglichkeit sein Backup/Restore bzw. DR Konzept zu testen
Anstatt einen expliziten Snapshot anzufertigen, sollte man sein Backup einspielen (bei Bedarf kann man ja kurz vorher nochmal ein Backup anstoßen). -
vmk meine Frage ist ja eher, reichen die Ressourcen vom Server für ein Forum & Shop, Mailcow, eine Datenbank und Jira oder ist das eher zu Wenig für den Live-Betrieb, noch habe ich die Wahl das Projekt startet erst Anfang Oktober....
Es kommt wohl auch stark darauf an wie stark der Shop besucht wird und welche Nachfrage zum Start besteht. Generell ist aber Mailcow wohl recht hungrig, Jira ebenfalls. Das würde ich so definitiv nicht alles auf einem Server hosten. Aus Security Sicht sowieso nicht. Da muss nur in irgendeiner Komponente eine Sicherheitslücke auftauchen (Forum, Jira, Mailserver, beim Shopsystem hat man sowieso direkt einen Supergau) und alle anderen Komponenten sind dann ebenfalls betroffen. Gerade bei einem Online Shop, der sowieso schneller Ziel bestimmer Angriffe wird und bei dem Daten der Kunden gespeichert sind (KK & Co.), hast da ganz schnell ein ziemlich großes Problem.
Du willst auch vielleicht die verschiedenen Services nicht immer zur selben Zeit patchen wollen.
Die Frage nach den Ressourcen ist hier aus meiner Sicht eher irrelevant. Das wirst im Grunde sowieso nur du selbst beantworten können. Theoretisch wird das sicherlich auch alles auf dem RS2000 laufen. Man sollte es aber aus den oben genannten Gründen nicht machen. -
Von mir gibt es ein "+1" für Mediawiki. Nutze ich selbst. Bietet einfach alles, was man sich von einem Wiki wünscht. Lässt sich durch Plugins auch beliebig erweitern. Der administrative Aufwand hält sich auch in Grenzen. MySQL + PHP + Webserver. Bei Bedarf noch einen Redis Cache. Läuft halt einfach
-
Dann bin ich mit den angepeilten 90TB schon drüber.
Wie sieht das ganze bei vServern aus? Meine Server laufen schon seit 3 Jahren und ich weiß nicht mehr was damals an Traffic da angepriesenen würde. Im CCP steht auch nichts dazu.
Wie kommst du denn auf über 90TB/Monat Traffic? Betreibst du einen Streaming oder Download Server?
-
Könnte auch sein, dass es sich bei der Webhosting-Cloud tatsächlich um eine "Cloud" im eigentlichen Sinne handelt und der Storage gar nicht lokal an den Servern anliegt, sondern wie man beim Namen evtl. erwarten würde, zentral über das Netzwerk angesprochen wird. Dadurch kann man natürlich auch günstiger Speicherplatz bereitstellen, weil er nicht wie bei den VPS und Root Servern durch den Host begrenzt wird.
-
Aber bald kommen doch bald die epischen Server der Generation 9.
Die dann andere, schon im Einsatz befindliche Server ersetzen dürfen
-
Serverhorder aller Nationen, vereinigt Euch!
So schnell kommt man ja auch nicht mehr so günstig an 160GB SSD. Und jetzt, da Deutschland in die Rezession rutscht, muss ja jemand die Wirtschaft ankurbeln. Ich agiere hier völlig selbstlos ;-).
-
Mich juckts ja im Finger, aber die 12 Monate Bindung hält mich noch ein wenig davon ab.
Ich habe auch erst überlegt. Aber irgendeinen Einsatzzweck findet sich schon. Bestellung ist raus
-
Auf https://www.servercontrolpanel.de sehe ich aktuell das EV Zertifikat, auf http://www.customercontrolpanel.de hingegen nicht. Hätte ich jetzt nicht mal explizit darauf geachtet, wäre es mir vermutlich auch nie aufgefallen. Das zeigt mir recht deutlich wie sinnlos die EV Zertifikate eigentlich die ganze Zeit über waren und warum es auch richtig ist, dass die Browser diese nun nicht mehr ganz so offensichtlich als solche anzeigen.
Rein technisch gab es sowieso nie einen Unterschied zwischen einem "normalen" DV und einem EV Zertifikat. Die CA hat zumindest theoretisch zusätzliche Überprüfungen des Zertifikats-Antragstellers unternommen, aber dem eigentlichen Besucher der Seite hilft das ja auch nur bedingt. Dieser weiß ja gar nicht, ob die Seite nun ein EV oder ein normales DV verwendet bevor er die Seite überhaupt besucht (was die Frage des TE recht deutlich zeigt). Erst dann sieht er es, wenn er zufällig explizit danach schaut oder auch nicht. Und wenn sich das Zertifikat von heute auf morgen ändert, merken das auch die wenigsten. Der Browser zeigt die Seite ja trotzdem an, ist ja ein gültiges Zertifikat konfiguriert.
Aber Netcup könnte hier vielleicht etwas konsequenter sein und die verschiedenen Seiten (CCP, SCP) einheitlich konfigurieren. Wenn bei der einen Seite ein EV Zertifikat hinterlegt ist und bei der anderen nicht, könnte das vielleicht doch etwas Verwirrungen hervorrufen. Dann lieber konsequent überall ein normales "DV" Zertifikat verwenden. -
Unabhängig jetzt von den schon genannten formalen Hinweisen/Vorschlägen hier mal eine inhaltliche Idee: Wenn du Lust und Zeit hast, baue doch noch anonymisierte, statistische Auswertungen mit ein und stelle eine Liste mit den Top Ländern / Providern / User Agents zur Verfügung, basierend auf den gespeicherten Informationen in der Datenbank.
-
Nach einem Kernel-Update (bzw. dem reboot danach) hängt sich der gesamte Server (Ubuntu 18.04) komplett auf. Netzwerk tot, Anzeige eingefroren, tot einfach. In den Logs gibt es nichts; die brechen einfach ab und offenbaren auch keine mögliche Ursache. Der Server stürzt immer kurz danach ab, nachdem systemd gemeldet hat, dass das hochfahren abschlossen sei.
Beim booten mit dem vorherigen Kernel ist alles in Ordnung und der Server läuft. Hat jemand eine Idee, wie ich das Problem eingrenzen könnte?
Kernel habe ich schon neu "konfiguriert" via dpkg-reconfigure.
Es ist ein reiner Docker-Host (wobei die gleiche Kombination aus OS, Kernel und Docker-Version auf einem anderen Server problemlos funktioniert).
Hast du den Kernel mal komplett gelöscht (apt purge) und neu installiert? Würde ich jetzt zumindest mal als erstes versuchen, also nicht einfach nur ein dpkg-reconfigure ausführen. Auch an die Module/Header denken
-
Eine kleine TTL bürgt das Risiko, dass der Internetauftritt eine Weile offline sein kann. Das passiert zwar selten, aber auch die Registries können einmal ausfallen, so wie z.B. die Denic im Jahr 2010: https://www.heise.de/newsticker/mel…ate-999068.html
Ich erinnere mich an den Ausfall noch sehr gut.
Das ist natürlich auch ein Argument. Aber für den Großteil der Nutzer dürfte der Internetauftritt trotzdem offline sein, auch wenn die TTL etwas länger sein sollte. Denn der Eintrag muss ja auch erst einmal im Cache vorliegen. Gerade bei einem so dezentralen System wie den vielen Mailservern ist es ja dann eher ein Glücksspiel, dass gerade der eine Mailserver den Eintrag noch im Cache hat (bzw. der lokale Resolver in der Firma). Eine lange TTL könnte also höchstens dazu führen, dass ein paar "Stammkunden" etwas länger auf die Seite zugreifen können bzgl. die eine Mail mal eben doch noch zugestellt wird.
Insgesamt überwiegen für mich jedoch ganz klar die Vorteile einer kurzen TTL. Denn Probleme mit dem eigenen Mailserver oder ungeplante Serverumzüge passieren dann in der Regel doch häufiger als dass mal ein Registrar offline ist. Ist dann am Ende des Tages eine Abwegung, welches Risiko man eher eingehen möchte :-). -
Dabei nicht vergessen, dass auch ein eventuell erforderliches "Umbiegen" des MX-DNS-Eintrags Zeit in Anspruch nehmen kann (insbesondere dann, wenn der alte Eintrag bei der Gegenseite eine Weile im DNS-Cache verbleibt). Schlimmstenfalls/als "Workaround" sollte man in diesem Fall überlegen, (ggf. zusätzlich) bei einem IP-/Rechnerwechsel einen temporären Tunnel vom alten zum neuen Host einzurichten.
Guter Hinweis. Aus diesem Grund bevorzuge ich es auch, wenn man die TTLs möglichst niedrig hält (bei mir max. 5 min). Das macht es in vielen Fällen leichter.
Auch würde ich empfehlen, dass keine 1:1 Kopie eingespielt wird, sondern gerade im Fall des SMTP Servers eine weitere Domain mit eigenem A/AAA Record genutzt wird (wenn der ursprüngliche Server mx1.example.tld war, dann den neuen Server als mx2.example.tld konfigurieren). Dann reicht es, wenn man hier den MX Eintrag ändert, es müssen dann nicht sämtliche Einträge geändert werden. Für den IMAP/POP bzw. Submission Server würde ich hingegen schon die Domains behalten, da hier ansonsten sämtliche Clients umkonfiguriert werden müssten. Aber in erster Linie ist es ja wichtig, dass der Mailempfang wieder funktioniert.
-
Ab wieviel Downtime des Mailservers sollte ich in Erwägung ziehen, mailcow (dockerized) auf einem anderen Docker-Host aufzusetzen und das Backup einzuspielen?
Mails gehen ja zum Glück nicht verloren, sondern werden dann einfach später zugestellt. Allzulange sollte man aber auch nicht warten. Ich sage jetzt einfach mal, alles, was innerhalb von 48h behoben werden kann, ist zwar ärgerlich, aber noch im Rahmen. Ab diesem Zeitpunkt aber wäre ein Einspielen des Backups sicherlich eine gute Idee.
-
Hallo Hoptional,
du nutzt DHCP für IPv4. Konfiguriere hier bitte mal deine neue IP Adresse statisch. Da du einen Snapshot eingespielt hast, sind vermutlich noch veraltete DHCP Client Einstellungen vorhanden, die hier evtl. das Problem verursachen. Es wäre generell ratsam, die Netzwerk Konfiguration statisch vorzunehmen. Natürlich könnte man jetzt auch erstmal den DHCP "Cache" leeren, würde aber trotzdem die statische Konfiguration empfehlen, bei IPv6 machst du das ja auch.
Gruß
Paul -
Das hier betrifft wohl einige von uns: https://www.golem.de/news/sicherhei…908-143508.html
Da ist wohl zeitnahes patchen angesagt, sobald die Pakete zur Verfügung stehen, dennZitatOperators should update to the latest Patch Release. There is no
workaround for the issue
