Hinweis: Dieser Artikel ist eine Anleitung und kein Schritt-für-Schritt-Prozess. Es wird davon ausgegangen, dass Sie mit der Linux®-Systemverwaltung und rsync vertraut sind Führen Sie die Befehle in diesem Artikel nicht aus, wenn Sie damit nicht vollständig vertraut sind. Stellen Sie in jedem Fall sicher, dass Sie Ihre Daten gesichert haben, bevor Sie die Schritte in diesem Handbuch befolgen. Es fallen standardmäßige Bandbreitengebühren an.
Dieser Leitfaden hilft Ihnen, die Servermigrationszeiten zu verkürzen. Wenn die Anwendungen Ihres Servers mit einem der in diesem Artikel hervorgehobenen Merkmale übereinstimmen, lesen Sie weiter – dieser Artikel könnte die rsync-Zeiten für Sie kürzer und vorhersehbarer machen. Es zeigt auch, wie Sie Migrationszeiten verkürzen können, indem Sie vorbeugende Maßnahmen ergreifen, bevor Sie dies tun.
Beschleunigen Sie den rsync-Prozess
Das Volumen des belegten Speicherplatzes auf einem Server bestimmt die rsync-Zeiten. Das heißt, je mehr Daten kopiert werden müssen, desto länger dauert der Job. Normalerweise dauert es 10 bis 15 Minuten, bis ein leerer Betriebssystem-rsync abgeschlossen ist. Die folgenden Server-Anwendungsfälle können die rsync-Zeit erheblich verlängern:
- Server mit vielen kleinen Dateien, z. B. Ruby-Sitzungsdateien, Cache-Dateien, Mailserver-Nachrichtendateien oder Webserver-Miniaturansichten . Das Migrieren solcher Daten mit rsync dauert länger als erwartet. Das bedeutet, dass eine anfängliche Synchronisierung länger dauert, aber ein zweiter Durchlauf im Rettungsmodus – mit der damit verbundenen Ausfallzeit – kürzer ist.
- Server mit mehreren Dateien, die während der Live-Synchronisierung aktualisiert wurden . Typischerweise handelt es sich dabei um MySQL® MyISAM-Tabellendateien oder Webserver, die mehrere Domains hosten, von denen jede so konfiguriert ist, dass sie sich in separaten Dateien protokolliert. Die Notwendigkeit, diese aktiv geschriebenen Dateien nach der rsync-Kopie des ersten Durchgangs zu aktualisieren, verlängert die Ausfallzeit nach einem Neustart, um einen zweiten Durchgang des rsync-Prozesses abzuschließen.
- Server mit einer oder mehreren großen Dateien, die während der Migration aktualisiert wurden . Beispiele hierfür sind MySQL-Datenbanken im InnoDB-Format, Mailserver mit großen Mailprotokollen und Webserver, die einzelne, große Dateien protokollieren. Das Aktualisieren dieser aktiv geschriebenen Dateien mit einem zweiten rsync nach der rsync-Kopie des ersten Durchgangs kann die damit verbundene Ausfallzeit erheblich verlängern.
Das Geheimnis zur Verkürzung der rsync-Zeiten besteht darin, Daten auf Ihrem Server zu verwalten und alle Anwendungen zu identifizieren, die während der Live-Migration auf die Festplatte schreiben.
Problem:Overhead für kleine Dateien
Obwohl sie nicht viel individuellen Speicherplatz beanspruchen, zwingen Server, die viele kleine Dateien hosten, den rsync-Prozess dazu, viele file-open auszuführen , file-copy , undfile-check Prozesse.
Beispielsweise erfordert eine Datendatei von einem Gigabyte einen Satz von Dateiöffnungs-, Kopier- und Prüfprozessen. Vergleichen Sie dies mit einem 1-Gigabyte-Datenblock, der über 10.000 einzelne Dateien verteilt ist und 10.000 einzelne Sätze von Dateiprozessen erfordert. Das ist viel mehr System- und Netzwerk-Overhead.
Die folgende Liste zeigt Anwendungen, die viele kleine Dateien erstellen und längere Vorbereitungszeiten für die Migration haben:
- Webserver, die viele kleine Thumbnails oder Bilddateien bereitstellen
- Caching-Server, die kleine Dateien auf der Festplatte zwischenspeichern
- E-Mail-Server mit großen Archiven nicht gelöschter E-Mails
- Ruby- oder Rails-Server, die dazu neigen, mehrere kleine Sitzungsdateien zu erstellen und sie nicht zu löschen
- Git-Repositories
- Benutzerdefinierte Anwendungsserver, die Sitzungsdateien für jeden Besucher erstellen, aber nicht löschen
Das Problem mit kleinen Dateien macht den rsync weniger vorhersehbar und dauert länger.
Migration
Vergleichen Sie Ihre Serveranwendungen mit der vorstehenden Liste. Wenn Ihre Anwendungen auf der Liste stehen, tun Sie, was Sie können, um unerwünschte kleine Dateien zu löschen, bevor Sie den eigentlichen rsync ausführen Befehl. Wenn Sie Ruby oder Rails verwenden, nehmen Sie das Schlimmste an und suchen Sie in Community-Foren nach typischen Speicherorten von Session- und Cache-Dateien und wie Sie feststellen können, welche Sie sicher löschen können. Erwägen Sie das Speichern von Sitzungsdaten in MySQL mit dem folgenden Befehl:
rake db:sessions:create
Protokolldateien in log/ kürzen auf null Bytes mit dem folgenden Befehl:
rake log:clear
Wenn Sie einen Caching-Server betreiben, der auf der Festplatte statt im RAM zwischenspeichert, identifizieren Sie sein Dateispeicherverzeichnis und bereinigen Sie ihn aggressiv. Überprüfen Sie Ihr Dateisystem auf kleine Sitzungs- und Cache-Dateien, die von benutzerdefinierten Anwendungen erstellt wurden. Auch hier kräftig zurückschneiden. Wenn Sie einen E-Mail-Server mit einem installierten Mail Delivery Agent (MDA) wie Dovecot migrieren, lassen Sie Ihre E-Mail-Benutzer zuerst ihre E-Mail-Archive von alten E-Mails bereinigen.
Problem:Ständig wechselnde Dateien
Sie müssen Dateien, die sich zwischen dem Start und dem Ende eines rsync ändern, mit einem nachfolgenden rsync für eine gründliche Servermigration erneut kopieren. Dieser Vorgang verlängert die Zeit bis zum Abschluss der Migration.
Datenbankserver sind die häufigsten Übeltäter, die große Datendateien zwischen dem Start und dem Ende einer Migration aktualisieren. Diese Änderungen zwingen das System, die gesamte Datenbankdatei erneut in einem zweiten rsync-Prozess zu kopieren, den Sie möglicherweise bei einer Migration durchführen.
Einige Kombinationen von Datenbankstruktur und -typ neigen dazu, diese Art von Problem zu verschlimmern. Angenommen, Sie haben eine MyISAM-Datenbank mit mehreren Tabellen von MySQL, in der viele Tabellendateien innerhalb einzelner SQL-Transaktionen aktualisiert werden. In diesem Fall müssen möglicherweise viele, wenn nicht alle Tabellendateien während der zweiten rsync-Operation im Rettungsmodus erneut kopiert werden.
Da Datenbankdateien groß sein können, werden die Auswirkungen dieser Aktualisierungen auf die Migrationszeit deutlich. Es ist schwierig, genau vorherzusagen, wie lange ein Migrations-rsync dauern könnte. Wie können wir schließlich vorhersagen, welche und wie viele SQL-Aktualisierungen zwischen Start und Ende der Migration stattfinden werden?
Migration
Wenn Ihre Datenbank viele veraltete Daten enthält, sollten Sie in Betracht ziehen, diese Daten zu archivieren und sie dann aus der Live-Datenbank zu entfernen, bevor Sie Ihren Server migrieren. MySQL zum Beispiel erlaubt Ihnen, Daten zu archivieren, indem Sie mysqldump verwenden Skript, nach dem Sie veraltete Daten in der Live-Datenbank löschen können. Das große mysqldump Ausgabedatei, die die veralteten Daten enthält, erweitert kein zweites rsync, da sie sich seit dem ersten Durchlauf nicht geändert hat.
Eine weitere Option, wenn Sie Anwendungen haben, die während der Größenänderung in viele Dateien schreiben, besteht darin, die Anwendung unmittelbar vor dem Ausführen von rsync in den schreibgeschützten Modus zu versetzen Befehl. Sie können Datenbanken normalerweise in den temporären Nur-Lese-Modus versetzen. Bei anderen Anwendungen kann Ihr Kilometerstand variieren. Sie können auch verhindern, dass in mehrere Dateien geschrieben wird, indem Sie Anwendungen deaktivieren, aber das Versetzen von Anwendungen in den schreibgeschützten Modus ist normalerweise die bevorzugte Option.
Problem:Große, ständig aktualisierte Dateien
Sehr große Dateien (10 GB oder mehr), die während eines rsync aktualisiert werden, stellen ähnliche Probleme für die Migrationszeit dar wie kleinere, ständig aktualisierte Dateien, jedoch auf Steroiden. Wenn Ihr Server Dateien hostet, in die häufig geschrieben wird, ist dieser Abschnitt genau das Richtige für Sie.
Ein zweiter rsync muss diese großen, ständig aktualisierten Dateien vollständig neu kopieren, um alle Aktualisierungen zu erfassen, die nach Beginn einer Migration oder eines Größenänderungsprozesses vorgenommen wurden. Dies verlängert die Migrationszeit aufgrund der Größe dieser zweiten rsync-Kopie erheblich.
MySQL-Datenbankserver, die das InnoDB-Datendateiformat verwenden, schreiben Daten in eine einzelne Datei, die tatsächlich sehr groß wird. In ähnlicher Weise protokolliert MySQL im InnoDB-Modus in einer einzigen großen Protokolldatei.
Eine Aktualisierung einer großen InnoDB-MySQL-Daten- oder Protokolldatei, wie z. B. /var/lib/mysql/ibdata1 , zwingt den rsync-Prozess dazu, die gesamte Datei in einem zweiten Durchgang neu zu kopieren. Wenn diese Dateien groß sind, kann das erneute Kopieren einige Zeit dauern, wodurch die Datenbank offline bleibt.
Eine weitere Quelle für große Dateien sind Anwendungsprotokolle, einschließlich Protokollen, die von Mailservern und einigen Webservern erstellt werden. Apache® kann Protokolldateien erstellen, die 16 GB oder größer sind, daher ist es nicht sicher anzunehmen, dass die Standardprotokollierung von Apache Ihnen hilft, dieses Problem mit großen Dateien zu vermeiden.
MySQL-Transaktionsprotokolle können auch sehr groß werden, wenn Sie die Transaktionsprotokollierung aktiviert haben. Menschen tun dies selten, und noch seltener schalten sie die Transaktionsprotokollierung ein, ohne dass ihnen danach der Speicherplatz ausgeht. Dennoch ist es ratsam, nach dieser Möglichkeit Ausschau zu halten.
Migration
Wie zuvor beschrieben, kann das Pruning von cruft-Datenbanken dazu beitragen, die gesamte rsync-Zeit zu reduzieren. Archivieren und löschen Sie alte oder veraltete Datenbanken, bevor Sie eine Migration versuchen.
Auch hier reduziert das Deaktivieren von Datenbankschreibvorgängen, wenn möglich, die Migrationszeit. Das Deaktivieren der Protokollierung kann auch InnoDB-Datenbanken helfen.
Wenn Sie die MySQL-Transaktionsprotokollierung aktiviert haben und die Transaktionsprotokolldatei groß ist, sollten Sie sie deaktivieren, archivieren und dann auf dem Slice löschen, bevor Sie eine rsyncmigration starten.
Überprüfen Sie auf Mailservern die Größe von /var/log/mail.log oder /var/log/maillog vor der Migration. Erwägen Sie, den Mailserver vor der Migration auszuschalten, insbesondere wenn Sie einen Backup-Mailserver haben, um die Last aufzunehmen.
Überprüfen Sie auf ähnliche Weise, wie Apache protokolliert. Wenn alle Anforderungen in einer Datei protokolliert werden, überprüfen Sie die Größe dieser Datei und erwägen Sie, sie zu archivieren und zu löschen oder Apache auszuschalten, bevor Sie den Migrationsprozess starten. Derselbe Rat gilt für jede andere Anwendung, von der Sie wissen, dass sie in eine große Protokolldatei schreibt.
Überprüfen Sie für diese und alle anderen Anwendungen Ihr logrotate Richtlinie (falls Sie eine haben), um zu überprüfen, ob sie Ihre Protokolldateigrößen überprüft. Dies erspart Ihnen Ausfallzeiten während der Migration und macht das Leben mit jedem Linux-Server einfacher.
Packen Sie Ihre Werkzeugtasche
Natürlich ist es schwierig, die erstellten Dateien nachzuverfolgen, nachdem Sie den Server eingerichtet haben. Das gilt für Anwendungen, die Sitzungsdateien erstellen. Es zahlt sich aus, diese großen Sammlungen kleiner Dateien zu finden und zu sortieren.
Sie können die zehn größten Verzeichnisse und Dateien identifizieren, indem Sie den folgenden Befehl als root ausgeben :
du -a / | sort -n -r | head -n 10
Ändern Sie die letzte 10 zu einer beliebigen anderen Zahl, um zu ändern, wie viele Dateien und Verzeichnisse die Suche zurückgibt. Dieser Befehl ist ein gutes Mittelweg-Tool zum Identifizieren großer Verzeichnisse mit kleinen Dateien und großen Dateien. Wenn Sie nur nach großen Dateien suchen möchten, versuchen Sie diesen großen Dateifinder (als root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Wenn Sie nur große Verzeichnisse finden möchten, versuchen Sie diesen großen Verzeichnisfinder (als root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Technische Details
Angenommen, Ihr Server entspricht keinem der oben untersuchten gängigen Typen. In diesem Fall können Sie abschätzen, wie die Migrationszeit aussehen könnte, wenn Sie Ihre Anwendungen mit einem Verständnis dafür betrachten, wie der Migrationsprozess (rsync) funktioniert.
Die typische erste Phase einer Migration ist ein Live-rsync, das im Grunde eine Kopie des gesamten Dateisystems des Servers ist. Alle Anwendungen werden während dieser Phase ausgeführt.
Hier stößt die Vorhersage der Migrationszeit auf ihre erste Unsicherheit. Ohne genaue Kenntnis Ihrer Nutzung des Dateisystems Ihres Servers können Sie nicht genau vorhersagen, wie lange die file-copy dauert Phase eines rsync wird dauern.
Diese Unvorhersehbarkeit gilt für das letzte Verzeichnis auf Linux-Dateisystemen:/var/ Verzeichnis. Es heißt var weil die Größe der darin enthaltenen Daten variabel ist und ändert sich, während die Serveranwendungen ausgeführt werden.
Die zweite Ungewissheit besteht darin, dass die letzte Phase einer Migration eine Komponente des Rettungsmodus (Ausfallzeit) enthält. Während dieser Phase kopiert der Prozess erneut alle Dateien, die nach Beginn der Live-rsyncfirst-Phase aktualisiert wurden. Die Länge der Ausfallzeit hängt von der Größe und Anzahl der aktualisierten Dateien ab. Auch hier kann der rsync-Prozess nicht im Voraus sagen, wie viele Aktualisierungen Anwendungen wie MySQL in Datendateien schreiben, daher ist es schwierig, die Dauer dieser letzten Rettung vorherzusagen. Modus rsync kopieren.
Die vorstehenden Informationen gelten für einen typischen manuellen Migrationsprozess. Unsere Cloud ändert den Größenänderungsprozess, um den Server für eine einzelne rsync herunterzufahren, was die Ausfallzeit verlängert und die Zuverlässigkeit der Synchronisierung erhöht.
Zusammenfassung
Wenn Sie wissen, wie Ihre Anwendungen Speicherplatz verwenden und in Dateien schreiben, können Sie möglicherweise einschätzen, ob eine Migration länger dauern wird, als Sie möchten, und entsprechende Vorbereitungen treffen. Zumindest können Sie Ihr neu erworbenes Migrationswissen nutzen, um Migrationen besser zu planen, damit sie Ihren zeitlichen Anforderungen entsprechen.
Verwenden Sie die Registerkarte „Feedback“, um Kommentare abzugeben oder Fragen zu stellen. Sie können auch mit uns ins Gespräch kommen.