- Warum betreibt man überhaupt den Server am heimischen DSL Anschluss und nicht im Rechenzentrum?
Dies kann Datenschutzgründe und/oder Storagegründe im TB Bereich haben, sprich P/L.
Beiträge von MeisterYoda
-
-
Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte. Die Telekom kann ich halt wenigstens bei einem Tarifwechsel solange ins Kreuz treten, dass ich das Prefix mitnehmen kann. Aber beim Providerwechsel geht das nicht.
Deswegen würde ich für heimische Serverdienste ein VPN (zB. Wireguard) zu einem Hoster/VPS/Rootserver aufsetzen, wo man ein vernünftiges /56 bekommt und sich dieses durchrouten kann. Dieses ist dann unabhängig vom heimischen Provider. zB. bei den Freunden einer der bekanntesten Skriptsprachen (dem diesjährigen Gewinner des Hosttests in der Kategorie VServer).
-
Ich verstehe halt ehrlich gesagt auch nicht, warum Netcup nicht einfach auf den aktuellsten stable Kernel upgraden kann? Ich mein die haben sowas ja sicherlich sogar automatisiert und können die VMs ja während der eine Host geupgraded wird auf ein anderes Hostsystem schieben. Allein schon aus Sicherheitsgründen wäre es eigentlich angesagt, nicht eine X Jahre alte Kernelversion zu fahren. Zumal das Problem jetzt nicht erst seit gestern, sondern seit einem Jahr (!) bekannt ist.
-
Wie beschrieben kann man darüber sehr geteilter Meinung sein. Wenn man die Definition der RFCs in Bezug auf "Site" und "Host" akribisch auslegt, dann macht Netcup exakt das, was in den Standards empfohlen wird. Auch wenn ich zugebe, dass zusätzliche /64 Netze auf einem VPS oder RS zuweilen hilfreich wären, aber auch dann hat man kostenlose Möglichkeiten, wie ich im verlinkten Thread ja auch ausgeführt habe.
Hmm, naja vielleicht kann man sich darauf einigen, dass es einfach von Netcup nicht zu ende gedacht bzw. alles andere als kundennah ist. Wobei man dazusagen muss, dass es, was das Thema betrifft, noch weitaus schlimmere Hoster gibt. Aber es gibt auch jene, die es richtig machen, und die Anzahl derer wird zwangsweise steigen. Netcup liegt irgendwo dazwischen.
Wenn ich beispielsweise 20 Container auf einem Root-Server laufen lassen will und diese per Firewall voneinander trennen will, brauch ich 20 Netze, da ich 20 virtuelle Bridges/Switches zu je /64 IPv6 habe. Klar könnte man subnetten, aber wie gesagt, das ist so in IPv6 nicht vorgesehen. Das gleiche gilt eigentlich für NAT/NPd. Ein externes Netz von zB. HE auf einen RS zu binden, halte ich nicht für wirklich sinnvoll - da wirst du niemals die Bandbreite von zB. 2.5Gbit/s bekommen.
Und: Imho ist das bei Netcup inkludierte /64 Subnetz seines Namens nicht wert, weil es ein geswitchtes Netz ist und kein geroutetes. Die korrekte Umsetzung wäre beispielsweise ein /128 (eine Adresse) auf den Server, worauf dann das /64 geroutet wird. Oder halt wie es hier der Fall ist ein geswitchtes /64 + das richtige (ein geroutetes) oben drauf.
Es hat schon seinen Grund, warum selbst Privatkunden bei DSL Anschlüssen ein geroutetes /56 Netz bekommen: Weil man per Philosophie von IPv6 als Kunde niemals an den Punkt stoßen sollte, wo man sich beschränkt fühlt. Und dass ein Kunde zuhause mehr als 256 VLANs aufspannen will, ist tatsächlich extrem unwarhscheinlich, selbst für Enthusiasten. Bei einem professionellem Serveranbieter sollte also mindestens das gleiche möglich sein. Aus diesem Grund ist Netcup auch nicht mehr uneingeschränkt zu empfehlen, denn IPv6 ist die Zukunft.
-
Die komplette IP Vergabe kann automatisch ablaufen. Aber für die Firewall muss sich wieder jeder Router Hersteller was eigenes ausdenken. Absurd.
Der Grund ist, dass IPv6 niemals dafür vorgesehen war, die Cashcow von dynamisch wechselnden Prefixen + Business-Tarif Aufpreis wenn du static willst weiter zu melken.
-
Bei IPv6 sollte man / muss man letztendlich immer unterscheiden zwischen Clients und Server im Netz:
- für Clients sollte man parallel SLAAC (-> Router Advertisments in pfSense/opnsense, type assisted) und DHCPv6 für das gleiche Subnetz einrichten. Grund: Es gibt Clients die können nur SLAAC und andere nur DHCPv6.
- für Server sollte man eine static v6 direkt am Server eintragen; wenn man einen dynamisch wechselnden Prefix hat, ist dies natürlich ein Problem. Dann muss doch wieder prefix translation ran, sprich du kannst intern die ULA (Unique Local Adressen) vergeben, und nach außen hin auf den dynamischen Prefix mappen (sofern opnsense das schon kann, pfsense kann es noch nicht).
Weiterhin: das kleinste bei IPv6 zur Verfügung stehende Netz ist ein /64, don't split it or stuff will break.
Prinzipiell könnte man sich auch über einen VPS/Root-Server ein statisches /64 pro Interface über ein VPN nach hause routen. Da Netcup aber wie ich in diesem Thread schonmal breit erörtert habe, seine Hausaufgaben bzgl. IPv6 nicht richtig gemacht hat, ist dies nur zu äußerst absurden Aufpreisen für viele Interfaces möglich. Oder man routet sich lediglich ein einzelnes /64 Netz nach hause und wendet dort dann wieder NPt an. Aber auch dann müsste man das NAT nur verwenden, weil der Provider es nicht korrekt implementiert hat und mindestens ein /56 pro Kunde zuweist. Aus diesem Grund habe ich nach wievor IPv6 einfach komplett deaktiviert, da ich nicht einsehe für IPv6 im Jahr 2021 extra zu bezahlen.
Ich denke vor allem Hostingprovider können sich das Spiel noch so lange erlauben, so lange es noch genügend IPv4 Adressen gibt. Sobald hier akute Knappheit herrscht, wird der Druck auf größere IPv6 Netze größer werden bzw. sämtliche Services in die Big Cloud verschoben, da die noch viel länger IPv4 Adressen haben werden.
-
Aber du nutzt jedenfalls das VMX flag + nested KVM, richtig?
Ich hab ja hier nen Proxmox 7 seit 36h am laufen (ohne gebuchtes VMX flag), soweit läuft alles. Nur ein Container (in dem nichts läuft) und cpu stresstest dauerhaft aufm Host, damit der Scheduler was zu tun hat. Bisher kein Reboot.
-
Es ist ein KVM Update ausstehend. Ich werde jetzt erstmal die Kiste runterfahren, damit das KVM Update sicher greift und dann nochmal beobachten.
Welches KVM Update meinst du? Eins seitens Netcup? Gibt es da offizielle Neuigkeiten, dass die ein Update machen?
-
das nicht aber andere hatten ja ihre resets dann mit proxmox
genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte und nicht als Problem seitens Support angesehen wird, werde ich wohl beim zuletzt gebuchten Server die Zufriedenheitsgarantie nutzen und den anderen einfach kündigen und zu einem anderen Hoster umziehen müssen, wo entsprechende Patches / Kernel updates eingespielt werden.
-
Weil ich es hier jetzt nicht nochmal explizit gelesen hatte: Aussage vom Support war nochmal dass man vil. nächstes Jahr was macht. Vorerst sei VMX nicht mehr buchbar.
Hmm, also ich bin ja wirklich gespannt, ob auch Proxmox mit reinen Containern, sprich KEIN nested KVM und auch KEIN VMX flag betroffen ist. Denn sollte das der Fall sein wäre das für mich ein außerordentlicher Kündigungsgrund. Ohne Containervirtualisierung kann ich die Kiste leider nicht brauchen; wäre dann auch nicht bugfree seitens Netcup.
Falls nur VMX + eigenes nested KVM betroffen ist, ist es natürlich in Ordnung wenn der Support da nix (rechtzeitig) macht, da es auch offiziell nicht angeboten wird.
-
Habe das auch schon länger. ~ einmal wöchentlich kann ich ein damit gefülltes VNC Fenster leeren.
ja, bei mir war es definitiv auch vor dem Black Friday.
-
oder der hypervisor bug aus einem anderen thread kommt jetzt so richtig zum Vorscheinen ?
Ich habe gestern mal auf einem RS G9 Proxmox 7.1-4 per .iso installliert und einen testcontainer erstellt. Aufm Host auch mal grade einen 5 Stunden langen CPU stresstest gestartet, mal schauen ob er rebooten wird. Ansonsten läuft er aktuell seit 16h ohne reboot.
-
Ich hab exakt das gleiche "Problem" - ist mir auch schon ein paar Mal aufgefallen... und nein, kein Proxmox, sondern normales Debian 11 drauf.
-
Beispielsweise https://www.datacenter-insider…chine-licensing-a-834733/
Wenn du dir keine VM-Lizenz holst (das lohnt sich für eine Nicht!), dann musst du die Maschine darunter lizensieren, nicht die CPU-Kerne der VM.
(Und du zahlst pro Kern)
Das heißt also: Für den EPYC 7702P die ganzen 64 Kerne. Jetzt gibt es nur ein Problem: Je nach Lösung weißt du nicht was darunter als Blech läuft, die Maschine kann ja woanders hin geschubst werden.Achso, das hatte ich komplett falsch verstanden - ich dachte du meinst Proxmox VE, denn das ist ja kostenlos
-
Außerdem hatten wir das Thema lizensierung hier mal, AFAIK musst du immer noch das Blech darunter lizensieren ? Also 64 Kerne ?
wie meinst du das?
-
illegal
ja gut, das muss ja jeder für sich selbst entscheiden was er wie installiert
-
Was bin ich froh, damals(TM) bei dem Angebot "Ostern 2015 Failover-IPv4 kostenlos" zugeschlagen zu haben. Damit klappt ein Mailserver-Umzug , wenn alles auf dem neuen Server eingerichtet ist, reibungs- (und zeitverlust-)los.
Da kannst du dich glücklich schätzen, ja
Es gibt aber durchaus noch ein zwei andere Hacks, die man anwenden kann um es genauso reibungslos hinzubekommen, wenn auch mit etwas Aufwand:
routing durch vpn, vlan etc.
-
Danke dir! Die 2/Monat wären ja nicht schlimm. Lässt sich das Feature im CCP aktivieren/buchen?
Nein, dazu musst du definitiv eine E-Mail an den Support schreiben.
-
Bei Netcup ist Nested Virtualization - im Vergleich zu diversen Anbietern - leider nicht inklusive. Pro CPU Core kostet es 2€ mtl. Aufpreis, wenn das Flag aktiviert werden soll. Was du nutzen kannst sind Container aller Art, wobei darin natürlich Windows nicht läuft.
-
Ist es möglich mit dem API Command "changeIPRouting" ausschließlich Failover-IPs zuzuweisen, oder ist auch die einmalige Erstzuweisung einer normalen Zusatz-IP damit möglich?
