Serverumzug - wie am besten?

Beitrag von **Synonym** » 02.09.2010, 09:28

Hallo zusammen,

da in 6-8 Wochen ein Serverumzug stattfinden soll frage ich nun mal nach wie man da am besten vorgehen soll.

Die Ausgangslage ist ein Root-Server, der als zentraler Server für Datenbank und Bilder dient. Dieser soll gekündigt und durch einen neuen ersetzt werden. Auf ihm ist aktuell eine Domain registriert, die für die Bilderauslieferung benutzt wird.

So wie ich das sehe bleibt mir an sich nur übrig:

Neuen Server bestellen
DB und Bilder abgleichen
Änderungen vorerst auf beiden Servern durchführen
Domain per DNS umleiten
Domain umziehen
alten Server kündigen

Nur ist mir das ehrlich gesagt etwas viel Aufwand. Geht das nicht anders?

Welche Möglichkeiten bestehen denn für die Zukunft, damit man das nicht jedes mal so machen muss?

Ich brauche eigentlich nur einen festen Host, über den die Bilder ausgeliefert werden und einen Zugang zur Datenbank, derzeit über IP. Beim Upgrade von vServern ist das ja kein Problem, aber bei einem Root? Neue IP, neuer Host und die Domain muss manuell umgezogen werden.

Danke und Gruß,
Ingo

von **Anzeige von ABAKUS** »

SEO Consulting bei ABAKUS Internet Marketing
Erfahrung seit 2002

persönliche Betreuung
individuelle Beratung
kompetente Umsetzung

Jetzt anfragen: 0511 / 300325-0.

Beitrag von **Sensei** » 02.09.2010, 16:05

Also was ich machen würde ist folgendes:

1. Neuen Server bestellen
2. Backup vom alten Server ziehen
3. Auf den neuen Ballern vom alten
4. Domain per DNS umleiten
5. alten server kündigen
6. Fertig

mit der Domain musst du ja nicht zwingend umziehen, außer du willst unbedingt wechseln

Beitrag von **Synonym** » 02.09.2010, 16:17

Hallo Sensei,

das ließt sich irgendwie genau wie meine Liste, oder täuscht mich das? Die Domain muss ich umziehen, da die beim Server mit dabei ist (Inkl-Domain), wenn ich die nur per DNS weiterleite und dann den alten Server kündige, dann ist die Domain mit weg.

Daher ja auch meine Frage. vServer-Upgrade ist da ja einfach dagegen, bleibt alles gleich, nur die Hardware / Config wird angepasst. Beim Root ist das aber wesentlich mehr Arbeit. Da das aber ca. alle 12 Monate ansteht nun eben die Frage, wie man das am besten angeht.

Und das andere Problem ist dabei ja auch, dass beide Server in der Übergangsphase abgeglichen werden müssen. Auf die greifen gut 100 Seiten zu und da kommen Daten von allen Ecken. Bis ich da ein Backup drinnen hab und die Webseiten umgestellt sind, sind schon viele Daten verloren, daher eben beide gleichzeitig bedienen und dann nach dem Domainumzug den alten abschalten.

Der andere Punkt wäre nur, dass ich den Hostnamen nehme und nicht die Domain. Da sich der Host aber immer wieder ändert ist das mehr als unschön.

Beitrag von **007** » 02.09.2010, 16:20

Das DNS-Update ist doch schnell durch. Nachts, Apache abschalten, Backup ziehen, auf den neuen Server laden, testen, DNS-Update, Schlafen gehen, Aufwachen, Domain per KK umziehen, Fertig.

Grüsse,

James

Beitrag von **Synonym** » 02.09.2010, 16:28

@James

Das DNS-Update ist doch schnell durch

Bitte? Da haben wir wohl einen Unterschied in der Auffassung von "schnell", oder? Die Umstellung muss direkt erfolgen, ohne Ausfälle. Da ist also nix mit Apache abschalten. Und wenn, dann ist da nichts mit schlafen gehen, denn dann steht das Telefon nicht mehr still. An dem Server hängt alles. Wenn der offline geht, dann gehen alle anderen Seiten und Server auch offline bzw. verweigern den Dienst.

Oder verstehe ich da nun was falsch? Wenn ich mich nur auf das DNS-Update verlasse, dann ist das Risiko doch sehr hoch, dass Daten mal auf dem neuen und mal auf dem alten Server landen, oder? Das letzte mal dauerte das fast 48 Stunden, bis der letzte aus Afrika oder sonst wo her auf dem neuen Server war. Hab das ja nicht zum ersten mal.

Jetzt wird das daher wohl nicht anders gehen, aber zukünftig? Mir fehlen da nur die Erfahrungen. Dachte da schon irgendwie an eine Cloud. Da könnte dann ja einer offline gehen und geupdaten werden, während der andere die Anfragen übernimmt. Oder eben so was wie den Strato MultiServer. Doch da ist die Hardware ja auch fest und kann nicht einfach gewechselt werden wie bei einem vServer. Aber wie gesagt, da habe ich keine Erfahrungen und frage daher hier nach.

Ich stehe da echt auf dem Schlauch und bin ratlos. Ist ja so schon die Frage, was für einen neuen Server. Einen Quad-Core mit 4GB, zwei Dual-Core mit 2 GB (Trennung DB und Bilder), zwei Server als Verbund (jeweils mit DB und Bilder) oder eben einen MultiServer mit 2 vServern im Einsatz. Was wäre da denn das sinnvollste um zukünftig weniger Arbeit zu haben?

Vorteil zwei Server getrennt: Bessere Konfigurationsmöglichkeiten (minimal Apache usw.) Nachteil: Mehr Administration, teurer

Vorteil zwei Server im Verbund: höhere Ausfallsicherheit. Nachteil: Mehr Administration, teurer, effektiv weniger Leistung

Vorteil MultiServer: beliebige Verteilung von Ressourcen, Testsysteme möglich. In Sekunden umschaltbar. Nachteil: Teurer, mehr Administration

Beitrag von **007** » 02.09.2010, 16:59

Synonym hat geschrieben:@James
Das DNS-Update ist doch schnell durch
Bitte? Da haben wir wohl einen Unterschied in der Auffassung von "schnell", oder? Die Umstellung muss direkt erfolgen, ohne Ausfälle. Da ist also nix mit Apache abschalten. Und wenn, dann ist da nichts mit schlafen gehen, denn dann steht das Telefon nicht mehr still. An dem Server hängt alles. Wenn der offline geht, dann gehen alle anderen Seiten und Server auch offline bzw. verweigern den Dienst.

Domain-Update mit neuem Nameserver dauert, aber ein DNS-Update ist normal in 1-2 Stunden komplett durch. Hatte ich gerade anders herum, Nameserver ausgefallen, 90% Besuchereinbruch nach 10 Minuten.

Dass die Umstellung ohne Ausfälle erfolgen muss, hast Du nicht geschrieben. Man erwartet so ein Höchverfügbarkeitsprojekt auch nicht auf einem einzigen Server

Synonym hat geschrieben: Vorteil zwei Server getrennt: Bessere Konfigurationsmöglichkeiten (minimal Apache usw.) Nachteil: Mehr Administration, teurer

Nachteil #2: Ausfallwahrscheinlichkeit, -häufigkeit und -dauer verdoppelt.

Synonym hat geschrieben: Vorteil MultiServer: beliebige Verteilung von Ressourcen, Testsysteme möglich. In Sekunden umschaltbar. Nachteil: Teurer, mehr Administration

In Sekunden umschaltbar? Was ist mit Datenbank und Binär-Files? MySQL ist nicht verteilbar.

Grüsse,

James

Beitrag von **Synonym** » 02.09.2010, 17:20

In Sekunden umschaltbar? Was ist mit Datenbank und Binär-Files? MySQL ist nicht verteilbar.

Jep, in Sekunden, aber das bringt mir bei einem Serverumzug nichts. War nur gedacht für normale Wartung und Tests. VM kopieren, aktivieren, andere deaktivieren. Ausfall ist da nur wenige Sekunden. Und MySQL ist durchaus verteilbar. Eben als Cloud oder als Replication, wobei ich die Replication extra nicht mehr! verwende. Master-Master Update macht oft Probleme. Master-Slave bringt mir keinen Vorteil.

Dass man so ein System nicht auf einem Server hat ist mir eigentlich schon klar, war es anfangs auch nicht, da war das auf 4 vServer verteilt. Dann kam der Root und der kostet eine ganze Latte mehr, daher nur einer. Nur das ist kein Dauerzustand. Daher ja die Frage. Also scheint das ganze wohl in Richtung "zwei Server als Verbund" zu gehen. Nur um da die Ressourcen gleich zu halten heißt das gut vierfache Ausgaben. Eigentlich sollten die ja sinken

Beitrag von **chris21** » 02.09.2010, 17:57

Wie wäre denn folgende Vorgehensweise?

1. Neuen Server bestellen, einrichten (Datenabgleich). Domain noch nicht umziehen.

2. a DNS Update der Domains auf neuen Server

und zugleich

2. b Alten Apache als Proxy so konfigurieren, dass er alle Anfragen, POSTs, GETs etc. an den neuen Server (über IP) sendet. (*)

3. Irgendwann freuen, wenn alter Server überhaupt nicht mehr angefragt wird, kündigen, abschalten.

(*) oder alternativ: Datenbank auf alten Server nicht mehr auf Localhost resp. alten Server verbinden, sondern auf neuen Server.

Beitrag von **Synonym** » 02.09.2010, 18:15

@Chris
Das mit dem Proxy hört sich interessant an. Muss ich mal überlegen ob das geht. Das Problem ist ja so gesehen nicht direkt der Abruf der Bilder, sondern das Hochladen. Und das geht per FTP-Verbindung von verschiedenen Stellen aus. Die muss ich anpassen, nur das dauert durchaus ein paar Stunden, bis ich die alle durch habe. Allerdings stelle mir nun durchaus die Frage, warum ich das per FTP gemacht habe und nicht per Post an den externen Server. Ich glaube aber, das war was mit der Geschwindigkeit, FTP war schneller (Upload mehrere Bilder). Aber das wäre dann nicht so tragisch, die Bildverzeichnisse (PDFs sind es auch noch) sind schnell abgeglichen.

Dein * habe ich nun aber nicht wirklich verstanden. Hört sich irgendwie an wie "Datenbank umleiten"... So was suchte ich eigentlich, hatte aber nie was in der Art gefunden und daher auch schon ganz verworfen.

Beitrag von **chris21** » 02.09.2010, 18:29

Ingo,

ich hatte die Bilder gerade wieder vergessen.

Bzgl. Datenbank: ich meinte einfach, dass die Datenbank(en) auf den neuen Server gespielt werden und dann sogleich der alte Server/Projekte so konfiguriert werden, dass die DBs auf den neuen Server angesprochen werden und nicht mehr die auf den alten.

Also Alter Server IP 111.111.111.111

Neuer Server IP 222.222.222.222

Dann muss nur der 3306 Port (glaube ich) auf dem neuen Server für externe MySQL Anfragen offen - und zugleich gut geschützt

sein, und Du kannst auf dem alten Server in den Projekten als DB Host die 222.222.222.222:3306 statt localhost bzw. alter IP eintragen.

Bzgl FTP: Weiß nicht, wie dass bei Dir konfiguriert ist, aber können die oder Dein Projekt nicht einfach die neue IP als FTP Server Host nehmen?

Beitrag von **Synonym** » 02.09.2010, 18:43

Bzgl. Datenbank: ich meinte einfach, dass die Datenbank(en) auf den neuen Server gespielt werden und dann sogleich der alte Server/Projekte so konfiguriert werden, dass die DBs auf den neuen Server angesprochen werden und nicht mehr die auf den alten.

Ach so. Das ist klar, so würde ich es eh machen. Nur das Anpassen der Projekte ist da wie mit den Bildern / FTP (ist sogar die gleiche Config-Datei), das dauert mehrere Stunden. Also auch bei der DB dann der Punkt, dass dann "Stückchenweise" die neue DB verwendet wird. Das Problem also auch dort der Input. Wenn mal keine Daten per Abfrage kommen ist mir das egal, aber der Input muss halt in die richtige Datenbank.

aber können die oder Dein Projekt nicht einfach die neue IP als FTP Server Host nehmen?

Klar, so soll es ja auch sein. Aber wie gesagt, es sind ca. 80 Stellen die angepasst werden müssen. Da ist keine "zwischendrin", wo ich einfach eine Art Hebel umlege, sondern muss die 80 nacheinander durchmachen. Nur darf dann halt, sobald ich mit dem ersten anfange, nur noch mit dem neuen Server kommuniziert werden. Da ich aber nicht alle zeitgleich ändern kann habe ich da ein Problem.

Du musst Dir das Servertechnisch so vorstellen: Server A1-A10 (auf denen liegen die Webprojekte). Server B ist der Datenbank- und Bilder-Server. Alles was auf den Servern Ax gemacht wird, alle Uploads und alle Abfragen kommen von B. Und B will ich nun wechseln auf einen neuen C.

Beitrag von **chris21** » 02.09.2010, 18:48

Jetzt sehe ich langsam, warum es kompliziert wird

Ok, zweite Idee bzgl. Datenbank & FTP: Port Forwarding. Das gleiche mit dem FTP Port (ist das 53?)

Also anstelle bei den alten Projekten überall die IP umzustellen, richtest Du einfach aufm alten Server nen Port Forwarding z.B. für Port 3306 auf neuen Server Port 3306 ein. Zieht natürlich während der Übergangsphase zusätzliche Ressourcen, sollte aber machbar sein.

Beitrag von **Synonym** » 02.09.2010, 18:58

richtest Du einfach aufm alten Server nen Port Forwarding z.B. für Port 3306

Ha und da bist Du jetzt an einem Punkt, den ich schon vor Jahren hatte. Geht das denn? Habe dazu nichts gefunden bisher. Das wäre nämlich das einfachste, einfach die DB-Anfragen weiterzuleiten. FTP müsste so dann auch gehen, aber das geht zur Not auch manuell, da ich neue Files gut erkennen kann. Neue DB-Einträge aber nur schwer und Änderungen eigentlich gar nicht.

Ressourcen sind mir dabei egal, damit hat der Server sicherlich keine Probleme.

Eine Idee hatte ich nun auch noch, aber ob die sinnvoll ist? Ich passe erst mal alle DB-Connects an und richte ein Fallback ein, für den Fall dass der Server nicht erreichbar ist. Das habe ich schon in der Art, allerdings einfach als SMS-Versand. Sollte aber auch gehen, dass der dann einfach einen anderen konnektiert. Wenn ich das dann bei allen habe, dann müsste ich den alten DB-Sever (nicht Web) eigentlich schon abschalten können. Verbindung schlägt fehlt, Fallback wird ausgelöst. Auch das verursacht zusätzliche Last auf den Ax, aber ist dort auch egal. Wäre das ein möglicher Ansatz?

Wobei, Dein Port-Forwarding gefällt mir ehrlich gesagt besser

Beitrag von **chris21** » 02.09.2010, 19:11

Port-Forwarding sollte über einen SSH Tunnel kein Problem sein. Würde ich aber auch erstmal auf einem Testsystem testen bevor Du das auf 70 Kunden von Dir loslässt

In der Art von: "ssh -L 3306:oldIP:3306 sshuser@newIP"

Ansonsten ist Deine zweite Idee mit dem "missbrauchten" Fallback auch ne gute Idee.

Beitrag von **Synonym** » 02.09.2010, 19:13

Ok, dann versuche ich das mal. Hab zwar kein reines Testsystem, aber dafür muss dann der Piwik-Server herhalten, der ist eh nicht so wichtig.

Danke!