Beiträge von t_b

    Keepalived mit der Floating IP habe ich in Betrieb, bisher kann ich mich nicht beklagen. Prüfung erfoglt über eine IP des Cloud VLANs, von außen gibt's ein externes Monitoring das meldet ,wenn die Floating IP nicht erreichbar ist von mindestens 3 Standorten. 1 Standort reicht nicht aus. Ein weiteres Skript hat nur die Aufgabe die IPs rumzuschieben, falls die Node der neue Primary ist.

    Das ist eben das Problem, da brauche ich weitere externe Systeme. Aber schön, das es prinzipiell klappt.

    Das könnten die LB aber auch selbst machen (z.B. mit keepalived). So ein ähnliches Setup hatte ich auch mal im Einsatz. Damals war das mit den Failover IPs aber noch ziemlich verbuggt, weshalb das in der Praxis nicht wirklich funktioniert hat. Ich hoffe, das klappt mittlerweile besser. Aber mit einem einfachen Curl Script können die LBs auch selbst schauen, ob der andere noch da ist und ggfs. die IP switchen. Ein zusätzliches, externes System ist hier nicht zwingend erforderlich.

    Die gleiche Idee hatte ich zuerst auch, aber es gibt ja noch den Fall, dass sie nicht von außen erreichbar sind, dass muss ja auch noch geprüft werden.

    Den Automatismus hat jedoch der Kunde unter Verwendung der API (Methode changeIPRouting) selbst bereitzustellen; es gibt meines Wissens keine Möglichkeit, über die API eine Liste von Servern zu definieren, welche sich eine IP derart "teilen", dass bei einem definierten Ausfall des Servers, dem die IP zu diesem Zeitpunkt zugeordnet wurde, eine Übertragung seitens eines Netcup-Systems erfolgt. (Das würde ein eigenes Monitoring überflüssig machen.)

    Dann bräuchte ich ein externes System, dass mittels keepalive schaut, ob die LBs noch da sind und das ggf. umlegt... also dann wird das wohl eher nichts...

    Das deutet jedenfalls mal darauf hin, dass ein automatischer Wechsel möglich ist.

    Das habe ich gelesen, aber keine weiteren Informationen dazu gefunden.



    Du hast im Moment nur einen Worker Node aufgelistet. Sind da noch weitere geplant? Sonst könnte man sich den HA LB ja eigentlich auch gleich sparen. Wenn es noch weitere geben sollte, wie willst du das mit dem Storage machen? Normalerweise brauchst du hier ja einen Storage as a Service oder musst das selbst aufsetzen (Ceph, GlusterFS,...). Das funktioniert hier bei Netcup aber leider eher schlecht als recht. Es gibt natürlich auch noch den etwas seltenen Fall, dass gar kein Shared Storage benötigt wird. Dann geht es natürlich auch ohne. Aber in der Praxis habe ich das ehrlich gesagt noch nie gesehen :).


    Aus meiner Erfahrung funktioniert das hier bei Netcup nicht wirklich gut. Hier brauchst du entweder eine richtige Cloud oder aber recht performante Bare Metal Server. Zumindest für alles, was über eine kleine Dev Umgebung hinaus geht.

    Ich weiß nicht, woran es genau liegt, aber bei mir scheint sich immer mal meine Kube-API kurz zu verabschieden, das reicht aber aus um das halbe system runter zu reißen (die stateful sets, was dank readyness probe dann auch die pods mit reißt.

    Daher wollte ich eben diese etwas ausfallsicherer machen. Beim speicher hatte ich an Longhorn gedacht, sobald ich auch mehr als einen Worker habe (der muss ja auch erst mal voll werden ^^) könnte ich so den Speicher erweitern und ebenfalls ausfallsicherer machen. Backups unterstützt Longhorn über S3, ebenso wie Snapshots.


    Dennoch hat mich dein letzter Absatz überlegen lassen, ob ich nicht vielleicht doch mit Kops bei AWS ein Cluster aufsetze. Preislich muss ich da halt schauen, was mich die einzelnen Nodes kosten. Schade eigentlich - ja ich weiß Netcup ist ein Massenhoster - das es hier irgendwie noch nicht so richtig fluppt.

    Hallo,


    Ich hab da mal eine Frage. Durch die Arbeit bin ich beim "roten H" aktuell auf dem Thema Hochverfügbarkeit. Dort ist es dank der Cloud, Terraform und cloud-init recht einfach ein solches Setup aufzusetzen.

    Da ich aber treuer Netcup Kunde bin, überlege ich ein ähnliches Setup auch bei mir aufzusetzen. Allerdings würde ich gerne euer Feedback haben, falls ich etwas übersehen oder nicht richtig verstanden habe:


    Loadbalancer [LB-01] (VPS 500 G8) - Haupt-Loadbalancer

    Loadbalancer [LB-02] (VPS 200 G8) - Failover-Loadbalancer

    Failover IPv4-Adresse => Zeigt auf LB-01, im Falle eines Ausfalls automatischer? Wechsel auf LB-02 - Frage hier, ist das automatisch?
    RKE2 Server [RKE2-S-01, RKE2-S-02, RKE2-S-03] (VPS 500 G8) - Kubernetes Control-Plane, ETCD

    RKE2 Agent [RKE2-A-01] (RS Ostern XXL OST21, vorhanden) - Kubernetes Worker-Node



    LG Tina

    Expert Special 2016 zum Expert Special 2018

    Ich habe ein Expert S. Aber der Expert Special 2018 klingt interessant, ich habe eh schon 3 DE Domains, das würde sich schon lohnen, wenn die Domains mit dem Expert Special verrechnet werden können. Gleich mal Support fragen.

    netcup:


    Das kostenlose Migrationsprogramm ist ja ganz schön, schade nur, dass sich der Expert-S Tarif (2018)/Webhosting 1000 in einem für mich nicht unwesentlichen Teil verschlechtert hat: Statt 512M/128M memory_limit/upload_size nur noch 128M/8M. Das ist gerade nochmal ein 1/4 bzw. 1/16 des originalen. Zwar könnte ich dann ja (kostenlos) auf Expert M/Webhosting 2000 wechseln, kostet mich aber gleich das Doppelte. Zumindest ist das für mich kein Anreiz zu wechseln. Ich hatte überlegt, ein Upgrade zu machen, als der Webhosting 2000 vor kurzen im Angebot war, aber da es dann im Normalfall heißt alles neu einrichten (zumindest war es so bei meinen Root Servern bei Netcup) hatte ich es sein lassen. Wäre also schön, wenn es schon ein Migrationsangebot gibt, dass die Leistung in keinem Aspekt schlechter oder teurer wird (sonst ergibt eine Migration ja keinen Sinn)


    VLG

    Falls es noch jemanden interessiert. Es scheint tatsächlich der opcache gewesen zu sein. Da dieser aber nur für fpm aktiv ist und sich nicht generell löschen lässt habe ich nach dem release noch ein script hinzugefügt, welches über curl eine spezielle seite aufruft, welche im fpm den opcache löscht. Danach hatte ich keine Probleme mehr.

    mmh, das hört sich danach an, als wenn der zum Zeitpunkt des deployens (und auch noch danach) files im Zugriff hat, die im anderen/alten Verzeichnis liegen

    Das habe ich ausprobiert und zumindest meine Zugriffe scheinen das nicht zu bewirken. Da ich privat ebenfalls vServer habe habe ich damit auch kein Problem. Da es hier aber um ein Kundenprojekt geht und wir Netcup entsprechend empfohlen haben ist das etwas schwierig nun zu sagen nein doch nicht...

    Hallo,


    "cache" wird nicht mit geshared, nur "logs" und "session".


    habe Follow Symlinks aktiviert, leider keine Verbesserung. Der Apache bekommt es erst mit, wenn der Ordner auf dem der Symlink vorher lag, gelöscht oder verschoben wird.
    Prinzipiell könnte ich das mit Aufwand bewerkstelligen (deployer prozess anpassen), die Frage ist, ob es nicht auch mit Boardmitteln geht.


    VG t_b

    Hallo,


    für einen Kunden konfiguriere ich gerade dessen Web Expert M Paket. Er hat eine Symfony Anwendung, die wir mittels Deployer auf das System legen.
    Dafür sieht die Dateistruktur folgendermaßen aus:


    /projekt
    /projekt/releases
    /projekt/releases/1234


    /projekt/releases/1235/web

    /projekt/releases/1235

    /projekt/releases/1235/web

    /projekt/shared
    /projekt/shared/var


    /projekt/shared/var/logs

    /projekt/shared/var/cache

    /projekt/shared/var/session

    /projekt/current => /projekt/releases/1235


    Der vHost mit http://www.xyz.de zeigt azuf /projekt/current/web


    Soweit so gut. Nach einem Release wird der Symlink auf die jeweils neueste Version im Releases Ordner geswitched. Jedoch scheint der Apache des Projekts das nicht mitzubekommen oder cached den (alten) realen Pfad, anscheinend auch über Stunden.
    Weiß jemand, wie man das abstellen kann?






    VG t_b

    felix: Das verstehe ich voll und ganz, die Frage ist, gibt es noch andere Kunden als mich, die von euren Leistungen überzeugt sind, aber sich mehr Individualiserung wünschen... vielleicht will ja der nächste wiederrum 10CPUs mehr als ich :) Wäre eine spannendes Thema für eine Umfrage, daraus könnte man dann ggf. auch ableiten, ob es sich lohnt darüber Gedanken zu machen oder eben nicht. Vielleicht auch in einer ganz anderen Form z.B. dass ich einen Teil meiner Kerne anderen Kunden (von vServern) zur Verfügung stelle - sofern eure Lösung soetwas zulässt

    ThomasChr danke für den Link
    felix: Das ist genau das Problem: die Rohleistung der neuen CPUs ist sicher cool, aber dummerweise ist CPU genau das was ich nicht brauche... Ich betreibe einen eigenen Atlassian Stack (Jira, Confluence, Bitbucket, Crowd, Bamboo) unter Proxmox sowie einige weitere vHosts... mal abgesehen von einem Neustart idle ich mit den 8 Kernen des v6 einen Load von unter 1 (avg). RAM hingegen kann ich nie genug haben....

    netcup:
    ich habe nochmal eine Frage zu euer Produktpalette: Irgendwie fehlt mir bei eureren Root Servern ein RS 6000 G7, der den Root-Server XL SSD v6 Preis/Leistungstechnisch ersetzt. Der Sprung von 16GB zu 32GB ist zu groß (im Preis), irgendwie fehlt mir ein System (4-6Kerne) mit 24GB RAM. Alternativ wäre es schön, wenn ihr mehr modular werden könntet und z.B. Upgrades für RAM (vorallem), CPU und Speicher anbietet....

    Ich kann peng und anderen nur zustimmen, ich dachte gerade mich tritt ein Pferd, als ich die v7 gesehen habe... Ich habe einen v6 XL und bin super zu frieden. 17€ mehr für (fast) die gleiche Leistung?

    Hallo,


    Ich habe bei einem Kunden das gleiche Problem. Dieser verwendet Outlook 2016, kann jedoch nicht den Posteingang abrufen. Alle anderen Unterordner funktionieren. Auch habe ich sichergestellt, dass der Posteingang aboniert ist. Gibt es hierbei schon eine Aussage von Netcup dazu?