Server DROP Marketing - Heavy Peaks - Setup Frage

  • Hallo liebe Netcup User,

    folgende Frage. Wir sind mit unserer Architektur an's Ende gekommen und bereiten uns auf Black Friday vor.
    Wieso ich euch nun fragen möchte ist um mein Setup ein letztes Mal bestätigt zu wissen und zu fragen, ob meine Probleme von vor 10 Jahren noch bestehen.

    Vorweg, wir sind im Influencer Marketing unterwegs, ein Drop von uns und auch Kunden sorgt für 10.000 Besucher im Peak, d.h. bestenfalls zeitgleich.

    Aktuell setzen wir ein:
    RS 8000 G9.5 a1 12M | https://www.netcup.de/bestellen/produkt.php?produkt=2898

    Ubuntu 20
    10.3.34-MariaDB
    Php7.4-fpm (dynamic prozesse) (1 pool, keine anderen Projekte, kein plesk, froxlor, cpanel etc.)
    Ngnix

    Redis Cache
    FileCache (kein Varnish)
    Cloudflare als Proxy davor


    Bis jetzt habe ich die Besucherströme abgefangen, aber leider sind unsere PHP Prozesse zu groß (230M | lt htop im RES).
    Wir kriegen die PHP Prozesse nicht so schnell kleiner, sind aber dabei und gehen auf 8.1 und verbessern den Code.

    Unser Bottleneck ist der Checkout (oh wunder). Caches sind dort aus.

    Nun kam es wie es kommen musste und DB hat abgeschaltet. Ergo ist der Server zu "klein" um sich mit php und redis alles zu teilen.

    zur Frage:


    Mein Plan jetzt (Kollegium will Azure / AWS MariaDB auslagern, was mir aber erstmal zu hohes Budget blockiert)
    zweiter Server (RS 8000 G9.5 a1 12M | https://www.netcup.de/bestellen/produkt.php?produkt=2898)
    MariaDB auslagern, die my.cnf anpassen für ca. 60GB Ram, max connections hochstellen und langsam ans Optimum herantesten.
    Dazwischen würde ich das Netcup VLAN hängen.

    Meine Bauchschmerzen / Erfahrungen:

    bei einem ähnlichen Setup vor 10 Jahren bei Netcup, hatten wir probleme bei kleinerer Aufrufmenge und den Netzwerkströmen,
    ich meine mich zu erinnern, dass das VLAN immer ausgefallen ist sporadisch.

    Ich will aber ganz ehrlich sein und Konfigurationsfehler überhaupt nicht ausschließen.
    Daher kurz die Frage, ob ich bei diesem Setup etwas nicht beachtet habe?

    Muss ich hier insbesondere irgendetwas konfigurieren bei dieser Menge an Besuchern außer am neuen MYSQL Server und der dortigen mariadb config?


    Über Input würde ich mich freuen.

    3 Mal editiert, zuletzt von jackyberlin () aus folgendem Grund: Sorry, das war ein schrecklicher Satzbau

  • Zur hilfreichsten Antwort springen
  • I've read that thread 3 times now and still have no clue what you want, please use English

    VPS Secret • VPS 200 G8 • 4x VPS piko G11s • 2x RS 1000 G9.5 SE NUE • RS Cyber Quack • VPS 1000 ARM G11 VIE

    c@compi.moe

    Gefällt mir 1
  • Ist das jetzt wirklich so schlimm? Ich finde, die Frage ist klar. Es geht darum, die Datenbank vom ursprünglichen Server zu lösen und auf einen eigenen Server auszulagern. Die Verbindung zwischen beiden Servern soll über ein VLAN erfolgen. Die Sorge ist, dass die VLAN Verbindung instabil ist, besonders bei kleinen Aufrufen.


    Grundsätzlich hätte ich gesagt, dass ist der Weg, den man häufig geht, also die Datenbank auf einen eigenen Server auszulagern. Zur Stabilität des VLANs kann ich nur sagen, dass ich zwischen einem Windows Server und einem Linux Server bislang nie Probleme damit hatte. Aber die Verbindung ist auch nicht besonders ausgelastet gewesen. Von daher bin ich dafür der falsche Ansprechpartner.

  • I don’t know if netcup had a VLAN 10 years ago. But the „new“ VLAN was introduced in 2018: https://www.netcup-news.de/201…fuer-virtuelle-netzwerke/


    I‘ve used the free 100 Mbit/s VLAN a few year, but for very low traffic. Never had any problems. Only once there was failure in 2021: https://www.netcup-status.de/2…erung-des-produkts-vxlan/


    Now I connected all my servers (also at different providers) via VPN (WireGuard).


    In this Forum there are very few posts from people who had problems with VLAN. So I think it’s quite reliable.


    Just keep in mind that your servers have to be in the same datacenter/location. Using the VLAN between Nuremberg and Vienna is not possible.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Gefällt mir 1
  • Another Idea: If the VLAN isn't usable for you (too slow, servers not in the same region, although I'd _not_ recommend that for low-latency database access, or it's not reliable enough):
    You can still just restrict the access to your database to that one (or more) specific IP that your application server has. If you're on the cautious side, you'll obviously also do this on the ip layer (nftables,iptables), such that you can't miss-configure this in your DBMS rules. (And your DBMS doesn't have to be reliable enough regarding access control.)

    You could also use that as fallback for the VLAN.

  • What I forgot to mention: Obviously using your normal NIC instead of the VLAN will count towards your traffic limit. But I'd guess that it's not that heavy when you're already offloading everything else to cloudflare.

  • Warum reden wir hier jetzt eigentlich englisch, wo doch offensichtlich alle deutsch sprechen? Der erste Beitrag mag schlecht gewesen sein, wurde aber überarbeitet. Er ist nicht aus einem automatischen Übersetzer, so viel steht fest.

  • Ich bin für VLAN schlicht weglassen. Kann man ja auch ohne VLAN sicherstellen dass nur bestimmte Server an die DB kommen.


    Auch würde mich interessieren was denn nun eigentlich passiert ist? Ist der DB der Speicher ausgegangen und deshalb ist sie abgestürzt? Wir sieht denn die Speicherauslastung aus?

    • Hilfreichste Antwort

    Hmm, also ich bin mir relativ sicher, dass ich, wenn das vLAN 2,5 GBit nicht schnell oder zuverlässig genug sein sollte, ganz sicher nicht über eine externe IP mit einem externen Datenbankserver versuchen würde. Natürlich garantiert das Cloud vLAN 2,5 GBit auch nicht die 2,5 GBit, auch das ist nur ein Maximalwert. Trotzdem gehe ich davon aus, dass hier die Verbindung schneller und zuverlässiger ist als über die "normale" Verbindung. Ansonsten könnte man das Produkt auch gleich einstampfen. Das heißt zwar nicht unbedingt viel in Zeiten, wo eine Großpackung fast schon regelmäßig mehr kostet, als das selbe Produkt in der selben Gesamtmenge in Kleinpackungen, aber so würde ich netcup jedenfalls nicht einschätzen. Zudem gäbe es nötigenfalls die Option, noch höhere vLAN Bandbreiten zu buchen, wenn auch wahrscheinlich dann nur über den Support. Schon diese Option allein würde mich eher die vLAN Variante wählen lassen.


    Wenn allerdings RAM das Problem ist, dann ist (mehr) RAM vielleicht auch die Lösung. Oder die Anwendung muss auf mehreren Anwendungsservern verteilt laufen (können!) mit einem zentralen Datenbankserver. Man darf auch nicht vergessen, mitunter muss eben nicht nur die Architektur der Server-Hardware, sondern auch die der Anwendung an sich optimiert werden. Nicht jede Anwendung skaliert beliebig von 200 Zugriffen pro Monat bis 1.000.000 oder mehr Zugriffen pro Sekunde. Ich will gar nicht wissen wieviele Nullen die Kosten für die Entwicklung des Amazon-Shops haben und auch nicht die Zahl der beteiligten Server, obwohl man auch das sicher irgendwo nachlesen kann. Jedenfalls kann man mit kleinsten Kosten und einfachsten Mitteln eben nicht beliebig hohe Zugriffszahlen bewältigen. Und so zufrieden ich für meine Zwecke mit MySQL/MariaDB bin, auch da gibt es Datenbanksysteme, die halt einfach performanter sind und besser skalieren. Ähnliches gilt m.E. auch für PHP.


    Das mag hier aber alles nicht relevant sein, weil eventuell die Überlastung nicht so groß ist, dass sie nicht durch einen größeren Server (echtes Blech!) mit mehr RAM und/oder einen externen Datenbankserver behoben werden kann.

  • Wenn du in seine Beitragshistorie ab 2015 schaust: Er hat definitiv Deutsch als Muttersprache. Vielleicht mag das in der ursprünglichen Version des ersten Beitrags nicht deutlich geworden sein.

    Also mir ist im Eingangsbeitrag nichts gravierendes aufgefallen. Da habe ich schon wesentlich schlimmere Beiträge von definitiv deutschen Muttersprachlern gelesen. Ich bin auch davon ausgegangen, dass der TE Deutsch als Muttersprache hat, deswegen sah und sehe ich (für mich) auch keinen Sinn darin, hier englischsprachige Beiträge zu schreiben.

  • Wenn du in seine Beitragshistorie ab 2015 schaust: Er hat definitiv Deutsch als Muttersprache. Vielleicht mag das in der ursprünglichen Version des ersten Beitrags nicht deutlich geworden sein.

    Er betreibt nach einem Beitrag auch einen deutschsprachigen Blog.

    Also kann man ziemlich sicher davon ausgehen, dass Deutsch seine Muttersprache ist

  • Ja der erste veröffentlichte Beitrag war murks. Aber in „meiner Welt“ bin ich auch nur noch am englisch „quasseln“, da bringt mir der deutsch Leistungskurs von vor 13 Jahren auch nichts mehr.


    Und über mobile device ist es hier im Forum auch etwas schwieriger (zu meiner Verteidigung).


    Zurück zum Thema:


    Klar ist, dass unser code murks ist, aber das kriege ich nicht bis zum nächsten Drop umgeschrieben. Redis handelt viel und fast alles, aber bei ca. 450 gleichzeitigen Käufern im checkout hat die DB aufgrund zu wenig RAM „dicht“ gemacht.

    Nicht NGNiX, nicht PHP, sondern mysql (mariadb)


    Bei 60GB Ram habe ich in etwa php 35GB ram „gegeben“ und für mariadb in etwa auf 20GB (durch my.cnf „Optimierung“) „freigehalten“.


    Im php-fpm error log sah ich, dass php schon auch mal „gezickt“ hatte (startservers etc).


    Durch das VLAN erhoffe ich mir natürlich mehr „Sicherheit“, einfachere Konfiguration und mehr Stabilität, darauf zielte meine Frage auch ab und bei kleineren Projekten habe ich hier bei (einem anderen Anbieter) auch rel. gute Erfahrungen gesammelt - nun ist netcup aber seit Jahren mein Anlaufpunkt Nr.1 und ich suche nach Erfahrungsberichten.


    Zumindest war hier niemand, der mich und meine Idee für verrückt erklärt hatte. Aus diesem Grund werde ich es versuchen und buche nun einen weiteren Server und schreibe dem Support bzgl. des VLAN‘s mit ggfs. „mehr“.


    Ich werde berichten - thank‘s a lot @all 😂