Is eigentlich schade, dass es bisher immer noch keine Anleitung zum Einrichten des VLANs zwischen 2. Servern gibt
Das hängt doch auch sehr davon ab, welches OS du nutzt, oder nicht?
Beiträge von michaeleifel
-
-
Nach einem halben Kasten Fürstenberg Pils (10 Flaschen a 0,5 l) schreibst Du nicht viel. Denn wenn Du nach 5 Litter Bier nicht schläfst rennst Du zumindest viel zur Toilette.
Das Hacke-Peter-Prinzip: Wer mehr isst, als er trinken kann, kann öfter auf die Toilette, als er muss!
https://www.amazon.de/Prof-Dr-Peter-Hacke-Hacke-Peter-Prinzip/dp/3499629992
-
Natürlich nicht, da es ein Fjord und kein See ist.
Spaß beiseite - ich habe noch nicht herausgefunden, wie ich unter Ubuntu bzw. Gnome ein Panorama-Hintergrundbild über alle drei Bildschirme strecken kann. Wenn jemand weiß, wie das geht, würde ich mich über eine Erleuchtung diesbezüglich freuen.
Nutze Plasma. Der einfachste Ansatz ist selber ein Bild zu "zerschneiden". Mit GIMP geht das in < 2 Minuten und einzeln zuzuweisen.
So sieht's bei mir gerade aus:
-
Da ist aber ein Fehler in der Matrix. Den See gibt`s 3mal identisch?
-
Ich hab hier zum Vergleich mal meinen RS 1000.
Warum sind bei mir die 4k-Werte so schlecht? Falsche Uhrzeit?
Habe zumindest allgemein festgestellt, dass man um 00:00 Uhr kein YABS erstellen lassen sollte.Welcher Festplattentreiber ist denn eingestellt? Virtio ( VirtIO BLK) liefert beim Benchmark bessere Werte, SCSI ( VirtIO Scsi ) ist "langsamer", läuft aber zumindest bei mir stabiler und weniger oft Probleme mit IO.
-
Welche Distribution und Image setzt du denn ein? Kenne das Problem nur mit Systemen < 1GB Ram.
-
Deswegen finde ich es schade, dass Server wie dieser hier kein neues Zuhause finden. Im Vergleich zum heutigen Türchen hat dieser doppelt so viel RAM, doppelt so viel Platte, und ist sogar noch ein paar Cent günstiger. Aber: nur 2 anstatt 4 Kerne.
Die gab es ja mal zum Einstandpreis von < 5€ wenn ich mich richtig erinnere. Für eine Testnode hatte ich solch eine auch im Betrieb gehabt und auch gerne genutzt um vor dem Rollout Sachen zu testen oder als kleinere Worker Nodes. Mittlerweile bin ich aber dazu übergegangen mir stundenweise Server zu mieten für diese Tests, wo ich auch mit Terraform etc. die Ressourcen dynamisch erzeugen kann und die restlichen Sachen sind konsolidiert.
Für Kubernetes ist die Nodegröße halt einen Tick zu klein und für nen Webserver etc. zu groß. Zudem wird die Abrechnungsperiode: alle 12 Monate im voraus einige abschrecken.
Wenn es die ARM Server doch nur mit stündlicher Abrechnungen geben würde...
-
Bei mir ist es seit je her Icinga2 im HA Modus für das aktive Alerting sowie das "pseudo" HA von Prometheus. Beides in Containern.
-
Gilt eigentlich bei den ARM Servern auch:
Kündigungsfrist: mindestens 31 Tage vor Ablauf der Mindestvertragslaufzeit
Oder kann ich die nach dem 1. Monat jederzeit stündlich kündigen?
-
Das ist auch eine schöne Idee.
Wenn es ein langer und großer Test kommt: Nutzt du dann die Namen der Raumstationen?
Da meine Tests "bisher" nicht > 5 Server umfassen tun es erstmal die Namen der Space Shuttles, auch der "Curiosity" war schon im Einsatz für die ARM Forschung. Raumstationen sind dann eher die Namen der Kubernetes Cluster gewesen
-
Bei mir sinds bei den Kubernetes Clustern die klassichen Bezeichnungen:
- k8s-master
- k8s-worker
Die restlichen Servern dienen der Erkundung sowie dem Testing und tragen deshalb die Namen von Raumsonden ( Lunik, Sputnik, Luna, Helios...)
-
Endlich spricht es einmal jemand aus! So ist es!
Externer Inhalt www.youtube.comInhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt. -
Ach Mist ... sollte eigentlich "vga" heißen
Gehört die Verdeckte Gewinnausschüttung nicht eher in den Bereich der Finanzen?
-
Hat er den Ententest schon bestanden?
-
Ist jetzt vielleicht nicht in jeder Situation die beste Lösung, aber ich habe vor meine Kubernetes Cluster (IPv4 only) einfach einen Cloudflare Proxy davor geschaltet. Der Enduser kann sich daher mit IPv4 + IPv6 verbinden, ins "Backend" geht die Verbindung dann aber mittels IPv4. Mit diesem Kompromiss kann ich ganz gut leben.
Danke für den Denkanstoß. Auf der eingehenden Seite habe ich kein Problem da der Loadbalancer die IPv6 terminiert und im Backend an den IPv4 Ingress weitergibt und auch der Rückweg somit ohne Probleme klappt. Allerdings geht halt reiner IPv6 Egress aus dem Pod heraus nicht, bspw. ping6
-
Alles anzeigen
Diesen Aufwand kannst du dir doch aus heutiger Sicht eigentlich sparen. Denn z.B. der Provider aus Falkenstein bietet im Grunde genommen mit seiner Cloud-Infrastruktur sowas schon mit an.
Der zusätzliche Speicher, den sie "SSD-Block Storage" nennen und den man für seine virtuellen Maschine dazubuchen und in der VM mounten kann, basiert laut dieses Providers auf einem sehr großen RAID-Array.
Und das tolle daran ist, dass du mit 10 GB anfangen kannst und wenn du dir später das Limit von zu Anfang 1 TB auf 10 TB hochschrauben läßt, du mit deinen Datenmengen da mitwachsen kannst.
Das Wissen, was du noch heute für deine derzeitige Konfigruation benötigst, weil du alles noch selber so zusammenbauen möchtest oder glaubst zu müssen, kannst du dir bei dem so gesehen zukünftig sparen.
Unterm Strich nimmst du eventuell genauso viel Geld in die Hand, aber hast dann mehr Zeit für eventuell wichtigere Dinge, weil sich um diesen technischen Kram dann der Provider im Hintergrund kümmert.
Mit diesem "technischen" Kram verdiene ich tatsächlich mein Brot. Es gibt bei dem Provider aus Falkenstein 2 Dinge weswegen ich bisher noch nicht dort bin:
- IPv6 im CloudVLAN gibt's nicht und somit auch nicht in Kubernetes
- Die Mindestgröße beim Storage ist 10GB, was bei einer PVC Anzahl von ~40 Stück dann auch wieder als "Kleinvieh macht auch Mist" zählt. Mit Ceph war mir das egal da ich einfach "X" PVCs zum gleichen Preis habe
Falls jemand zu Punkt 1 ne Idee / Lösung hat, bin ich offen für Input. Die Interfaces einfach mit IPv6 versorgen ist keine Option, da diese nicht routed werden zwischen den Nodes.
-
Nehm ich gerne, DM ist raus.
hmm, also kurz gesagt: viel Aufwand für eine nicht so gut funktionierende Lösung, die dann auch nicht gerade günstig ist. Mal schauen, was der ein oder andere noch so berichtet. Dann bleib ich vielleicht hier im privaten Umfeld bei Docker und spiele nur mit einem Single-Node-K8s-Cluster mit https://github.com/rancher/local-path-provisioner als "Storage" rum.
(Auf der Arbeit sind wir fast nur noch mit Kubernetes (Cloud und onPremise) unterwegs.)Seit das rote H ARM-Server hat, hab ich mir das dort auch mal angeschaut... gefällt mir.
So ist die Quintessenz.
Ich benötige aktuell ~250GB Storage für die Sachen die dort laufen. Zu klein für dedizierte Storageserver und teils sind dort Sachen drin die ich für die tägliche Arbeit brauche, da ist Single Node auch nicht so richtig ne Option.
3 RS 2000 reichen vom RAM inkl. der Storagelösung nicht aus, deswegen sind es 3 RS 4000 G9 mit 32 GB RAM und 800GB SSD die dann mit dem VLAN zusammen im 3 stelligen Bereich pro Monat liegen.
Mit "Remote" Storage würden mir die 16er Nodes völlig ausreichen. Auch ne Überlegung war den LocalPath Provisioner zu missbrauchen und gemeinsam mit https://linux.die.net/man/8/cachefilesd zu nutzen. Aber durch die völlige Intranzparenz wieviel Traffic man verbraucht hat, hab ich das nicht verfolgt. Dann hätte ich mir mehrere geholt und zwischen denen "ausbalanciert".
Die Komplexität mit replizierten Datenbanken will ich mir auch nicht freiwillig antun. Ich kann mit Failover leben, wenn das ohne mein Zutun innerhalb von ~10 Minuten wieder online ist.
Insgesamt würde ich aber vermuten dass mein Use-Case nicht üblich hier ist, wenn ich schon sehr oft lese wie "krampfhaft" versucht wird ein Server durch die Kope von einem 1:1 Image aufzusetzen. Dahingehend habe ich ruhige Nächte. Erst gestern wieder in einem Testlauf mit ~10 Minuten die Ressourcen über Terraform erzeugt, Maschinen per Ansible eingerichtet, k8s Cluster hochgezogen und Workload deployed.
-
Verbrauchst du tatsächlich 200 TB im Monat pro RS-Server? Oder habe ich dich da nicht richtig verstanden? Denn der aus Falkenstein gibt nur 20 TB Traffic pro Dedicated Server.
Ich meinte "Traffic / Monat" von https://www.netcup.de/vserver/storagespace.php
Gibt 2 Probleme dabei:
1.) Das Volume ist laut Support offline sobald diese Grenze erreicht ist
2.) Man sieht nicht, wieviel verbraucht wurde, also ohne Vorwarnung
3.) Eine "Freischaltung" gegen weiteres Entgelt ist nicht vorgesehen
Für meine Zwecke würde der normalerweise völlig ausreichen, allerdings ist das halt am Ende das Totschlagkriterium was in Verbindung mit anderen Dingen von oben dann leider mich zu Alternativen umschauen lässt. Hab ganz vergessen noch das Thema Firewall zu ergänzen.
-
Dann noch ne kleine Frage an die, die Kubernetes einsetzen: Nutzt ihr ceph? Was nehmt ihr da als Festplatte(n)/OSD, das Storage im CCP welches man zu einem Server hinzufügen kann?
(Da hier in letzter Zeit Produktideen für netcup diskutiert wurde, irgendwie sowas als Storage zum Buchen wäre nicht schlecht.)
Ich nutze aktuell "noch" Ceph mit Rook ( https://github.com/rook/rook ) bin aber aktuell quasi fast auf dem Absprung zum roten H wegen dem Thema Storage und ARM. Der Storagespace würde mir tendenziell reichen, der hat aber ein "Traffic" Problem wonach das Volume offline ist und auch nicht gegen Gebühr mehr Traffic kriegst. Gefühlt seit 2 Jahren frage ich immer wieder zu dem Thema bei Netcup.
Insgesamt läuft das ganze OK, allerdings mit den Kosten für CloudVLAN, FailoverIP 4/6 ist der Vorteil im Vergleich schnell aufgefressen. Und man merkt dann doch die CPU Last etc. wenn mehr geschrieben wird relativ deutlich.
-
Was ist denn die aktuell beste Möglichkeit für Storage über mehrere Nodes übergreifend? Aktuell nutze ich 3 Hosts mit Ceph sowie dem 2,5 Gbit VLAN.
Allerdings gibt's mehrere Punkte die mich was stören:
- CloudVLAN Kosten
- Failover IPv4/6 Kosten
- Memory Overhead wegen Ceph
wodurch ich im Endeffekt nicht merkbar günstiger im Gesamtkonzept unterwegs bin als beim roten H. Leider ist ja der Storagespace nicht wirklich brauchbar aufgrund der Traffic-Limitierung die sich auch nicht gegen Geld anheben lässt und mir das zu riskant ist "es dort drauf ankommen" zu lassen, da lau Support der Storage nicht mehr zureifbar wird. Aber man hat auch keine Ansicht wieiviel Traffic man schon verbraucht hat. Das Support-Ticket dazu hab ich nie wieder was gehört.
