Linux gibt es schon seit einiger Zeit. Ursprünglich 1991 von Linus Torvalds gegründet, hat es sich neben Windows und den großen Unix-Distributionen zu einem wichtigen Akteur in der Landschaft der Serverbetriebssysteme (OS) entwickelt. An Unix ist zwar an sich nichts auszusetzen, aber es ist ziemlich „in die Jahre gekommen“ und es gibt einen wachsenden Trend zur Migration von Unix zu Linux.
Warum also migrieren?
Wenn Sie ein Administrator eines bestehenden Rechenzentrums sind (ob vor Ort oder in einer Co-Location-Einrichtung), insbesondere eines, das es schon lange gibt, haben Sie wahrscheinlich eine gewisse kommerzielle Erfahrung mit Unix. Diese erfordern normalerweise proprietäre Hardware, und obwohl diese problemlos ausgeführt werden kann, gibt es Herausforderungen bei der Wartung solcher Legacy-Umgebungen. Die größte dieser Herausforderungen, mit denen sich das obere Management möglicherweise beschäftigt, sind die Supportkosten sowohl für die Hardware als auch für das Betriebssystem selbst. Außerdem können Erweiterungen immer schwieriger durchzuführen sein, da die Legacy-Hardware veraltet ist und Teile schwer zu finden und, wenn sie gefunden werden, teuer sein können (oh, Angebot und Nachfrage, du bist so eine harte Geliebte!).
Etwas, das während dieses Übergangs auftreten kann, ist die Möglichkeit, dass Sie eine Anwendung entdecken, die nicht migriert werden kann. Vielleicht hat der Anbieter sein Geschäft eingestellt oder die Anwendung nicht auf Linux portiert. Vielleicht haben sie das, aber es würde eine direkte Beteiligung des Anbieters an einem professionellen Engagement erfordern, das zu hohe Kosten verursacht. In diesem Fall müssen Sie möglicherweise prüfen, ob Sie die Arbeitslast auf eine neue Anwendung migrieren können, die von Linux unterstützt wird, oder diesen bestimmten Legacy-Server beibehalten müssen.
Ein weiteres Problem beim Verbleib auf alten Unix-Systemen ist die Unfähigkeit zur Virtualisierung. Während es in einigen Unix-Umgebungen eine gewisse Virtualisierung gibt, bieten moderne Hypervisoren viel mehr Funktionalität und Flexibilität, wenn Sie zu einem Betriebssystem wechseln können, das von Ihrem gewählten Hypervisor unterstützt wird.
Ok, also werde ich migrieren, wie fange ich an?
Der Erfolg einer Migration von Unix zu Linux beginnt mit einer soliden Untersuchung. Es gibt mehrere Dinge, auf die man sich konzentrieren sollte. Es gibt zwei Möglichkeiten, dies anzugehen, und ich habe festgestellt, dass eine Mischung aus beiden die besten Ergebnisse erzielen kann. Die zwei Ansätze, wie ich sie gesehen habe, sind „von unten nach oben“ und „von oben nach unten“. Diese Sätze sind gebräuchlich und hier ziemlich einfach anzuwenden.
Beim Bottom-up-Ansatz beginnen Sie auf Betriebssystemebene. Beginnen Sie mit der Überprüfung des aktuellen Betriebssystems und der aktuellen Version. Identifizieren Sie installierte Pakete, Module oder zusätzliche Software des Betriebssystemanbieters. Suchen Sie als Nächstes nach Software von Drittanbietern und erfassen Sie den Anbieter und die Version, die Sie ausführen. Das Letzte ist jede selbst entwickelte Software, die Sie haben könnten, einschließlich nicht nur Programme, die in einer formalen Sprache wie C geschrieben sind (oder einer seiner Nachkommen) oder Java , sondern auch Skripte, die in einer der gängigen Shell-Sprachen geschrieben sind (sh , ksh , csh ) oder interpretierte Sprachen wie PERL , Python , und dergleichen.
Ein weiterer Ort, an dem Sie nachsehen sollten, ist cron Planer. Alles, was dort geplant ist, ob vom Anbieter bereitgestellt oder hausgemacht, ist etwas, für das Sie zusätzliche Zeit zum Testen aufwenden möchten.
Der Top-down-Ansatz kann schwieriger sein, da er mit den Endbenutzern beginnt und von ihnen erfährt, was sie auf dem System ausführen. Dieser Ansatz kann eine schwierige Erfahrung sein, da Benutzer nicht immer verstehen, wie etwas funktioniert, sondern nur, wie sie es verwenden. Beispielsweise könnte ein Benutzer wissen, dass er eine Website verwendet, sich aber nicht bewusst ist, dass „unter der Haube“ Apache steckt oder Tomcat , egal ob es CGI hat oder nicht Skripte und wenn ja, in welcher Sprache sie sind. Es können jedoch zusätzliche Leckerbissen nachgelesen werden, wie zum Beispiel herauszufinden, dass ein Server, von dem Sie dachten, er sei mehr oder weniger eigenständig, eng mit einem anderen verbunden ist und dass Sie beide migrieren müssen gleichzeitig.
Am liebsten mache ich beides... Ich versuche herauszufinden, wer die Geschäftsanwender eines bestimmten Systems führt, und treffe mich mit ihnen, um herauszufinden, wofür sie es verwenden. Ich werde auch versuchen, die von ihnen verwendeten Funktionalitäten mit identifizierbaren Systemkomponenten abzugleichen. Ein Beispiel wäre ein Webserver. Ist es ein statischer Server oder dynamisch? Möglicherweise sehen Sie dies nicht, wenn Sie installierte Pakete auf dem Server überprüfen. Dennoch könnte Ihnen ein Benutzerinterview sagen, dass die Seite auf WordPress basiert , was bedeutet, dass Sie die Datenbank finden müssen, die sie steuert, unabhängig davon, ob sie sich auf demselben Server befindet oder vielleicht auf einem anderen, der möglicherweise zur gleichen Zeit migriert werden muss.
Ok, jetzt weiß ich was läuft, was kommt als nächstes?
Sie müssen entscheiden, zu welcher Linux-Distribution Sie wechseln möchten. Viele Dinge spielen bei dieser Entscheidung eine Rolle, die ehrlich gesagt ein eigener Blogbeitrag sein sollte. Im Moment möchte ich hervorheben, dass Sie sich die Funktionen ansehen müssen, die auf dem Server im Spiel sind, und herausfinden, welche Distributionen dieselben Funktionen unterstützen. Handelt es sich bei dem Server beispielsweise um einen einfachen Web- oder FTP-Server, reicht nahezu jedes Linux aus. Wenn Sie Software von Drittanbietern ausführen, unterstützt der Anbieter möglicherweise nur bestimmte Distributionen, daher sollten Sie mit dieser Software beginnen und sich dann von dort aus eingrenzen.
Sobald Sie Ihre Distribution ausgewählt haben, bauen Sie sich eine Entwicklungsumgebung auf, installieren Sie das Basisbetriebssystem und benötigte Pakete, Software von Drittanbietern und dergleichen. Richten Sie Benutzer zum Testen ein und kopieren Sie entweder ihre Programme und Skripte oder stellen Sie sicher, dass sie dies können.
Alles läuft einfach, oder?
In einer perfekten Welt wäre das wahr. Wir alle wissen jedoch, dass die Welt nicht perfekt ist. Vom Betriebssystem bereitgestellte Funktionen funktionieren im Allgemeinen sofort so, wie Sie es erwarten würden. Wenn Sie in Versionen für etwas wie Apache aufspringen, kann es Unterschiede bei der Konfiguration geben, damit Ihre Website auf die gleiche Weise ausgeführt wird. Die Dokumentation hilft Ihnen normalerweise dabei, dorthin zu gelangen. Software von Drittanbietern kann manchmal mehr Probleme haben. Wenn Sie sich damit befassen müssen, stellen Sie sicher, dass Sie über bestätigte Betriebssystemversionen verfügen. Ein Anbieter, mit dem ich zu tun hatte, unterstützt RHEL 6, aber nicht RHEL 7. Manchmal haben sie möglicherweise nur bis zu einem bestimmten Point-Release getestet und unterstützen bis dahin, aber nicht darüber hinaus, z. B. die Unterstützung von RHEL 6.4, aber nicht RHEL 6.10. Es können auch Probleme auftreten, wenn Sie eine 64-Bit-Version des Betriebssystems installiert haben, der Drittanbieter jedoch nur eine 32-Bit-Installation getestet hat.
Eigenentwickelte Software und Skripte sind eine andere Sache. Sie werden dort fast garantiert Probleme haben, abhängig davon, wer den Code geschrieben hat und wie komplex er ist. Formale Sprachen können leichter übertragen werden, solange das Linux-Betriebssystem über die richtigen Bibliotheken verfügt, um das Kompilieren zu unterstützen.
Es könnte Probleme geben, wenn Sie eine ältere Version von Unix verwenden, da sich die Sprache möglicherweise geändert hat. Bestimmte Standardeinstellungen haben sich möglicherweise geändert, und Optionen für Funktionsaufrufe, insbesondere Systemaufrufe, können unterschiedlich sein. Die Empfehlung ist, die ersten Kompilierungen des Codes mit dem höchsten Grad an Debugging durchzuführen, das Sie aktivieren können, und dann, sobald Sie die Probleme durchgearbeitet haben, mit deaktiviertem Debugging neu zu kompilieren, um in Zukunft Serverlast zu sparen.
Für Skripte gilt das Gleiche, aber mit einer größeren Wahrscheinlichkeit von seltsamen Änderungen. Persönliche Erfahrung hat gezeigt, dass die Standard-Shell (auch bekannt als sh )-Skripte werden normalerweise unter der Bourne Again Shell (auch bekannt als bash) ausgeführt ). Dennoch kann es versteckte Fallstricke geben, die keinen Fehler auslösen, aber nicht die erwarteten Ergebnisse liefern. Ein wichtiges Beispiel ist dieses Code-Snippet, das ich in meiner HPUX-Zeit häufig verwendet habe:
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
Unter HPUX hat das problemlos funktioniert. Unter bash in RHEL die Variable $saved_value wäre leer, aufgrund der Art und Weise, wie diese Shell das Scoping im Vergleich zu HPUX durchführte. Ich musste das obige in etwas wie folgt ändern:
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” Daher ist es wichtig, parallele Ausführungen zwischen dem alten und dem neuen System durchzuführen, um sicherzustellen, dass dieselbe Eingabe in ein Skript dieselbe Ausgabe auf beiden Systemen erzeugt.
Ok, wir haben alles getestet, was nun?
Der eigentliche Schritt der Umstellung vom alten auf das neue System kann je nach Umgebung sehr unterschiedlich komplex sein. Damit das Thema wirklich richtig behandelt wird, sollte es einen eigenen Blog haben. Nachdem Sie Ihre Migration durchgeführt haben, ist ein Post-Mortem praktisch, insbesondere wenn Sie weitere Migrationen durchführen müssen. Eine solide Überprüfung dessen, was funktioniert hat und was nicht so gut gelaufen ist, kann nützliche „Lessons Learned“ generieren, die Sie bei Ihrem nächsten Migrationsprojekt anwenden können.
Abschluss
Ich hoffe, dieser Artikel hat dazu beigetragen, die Arten von Dingen hervorzuheben, auf die Sie achten müssen, Gespräche zu führen, Pläne zu gründen und Ihnen einen Vorsprung auf Ihrer Reise in die Migration von Unix zu Linux zu geben. Hoffentlich haben Sie mit den Dingen, die Sie aus diesem Artikel mitnehmen, und etwas Glück einen relativ reibungslosen Übergang.
[ Möchten Sie Red Hat Enterprise Linux ausprobieren? Laden Sie es jetzt kostenlos herunter. ]