Server, die sich dem Ende ihres Lebenszyklus n\u00e4hern, Storage-Systeme, die mit dem Wachstum nicht mehr Schritt halten, ver\u00e4nderte Lizenzkosten oder eine Umgebung, deren Verwaltung zunehmend komplex wird: All dies sind Situationen, die fr\u00fcher oder sp\u00e4ter dazu f\u00fchren, \u00fcber eine Modernisierung der IT-Infrastruktur nachzudenken.<\/p>\n\n
Die naheliegendste L\u00f6sung besteht darin, jede Komponente durch ein aktuelleres \u00c4quivalent zu ersetzen. Wenn die Einschr\u00e4nkungen jedoch in der Architektur selbst liegen<\/strong> und nicht nur im Alter der Hardware, besteht das Risiko, zu investieren und einige Jahre sp\u00e4ter vor denselben Problemen zu stehen.<\/p>\n\n Daher lohnt es sich, mit einer anderen Frage zu beginnen: Welche Anforderungen muss die Infrastruktur in den kommenden Jahren erf\u00fcllen und welche Einschr\u00e4nkungen der aktuellen Umgebung sollten nicht in die neue Architektur \u00fcbernommen werden?<\/p>\n\n Das Ende des Hardware-Lebenszyklus ist einer der offensichtlichsten Gr\u00fcnde. Support, Garantie, Ersatzteilverf\u00fcgbarkeit und die Kompatibilit\u00e4t mit neuen Softwareversionen k\u00f6nnen eine Erneuerung erforderlich machen.<\/p>\n\n Es gibt jedoch weitere Anzeichen. Eine Modernisierung kann auch dann sinnvoll sein, wenn Workloads und Datenmengen wachsen<\/strong>, h\u00f6here Anforderungen an die Betriebskontinuit\u00e4t bestehen, sich weiteres Wachstum nur schwer bew\u00e4ltigen l\u00e4sst oder Kosten und betriebliche Komplexit\u00e4t nicht mehr zu den Anforderungen des Unternehmens passen.<\/p>\n\n Daher ist es sinnvoll, zwischen zwei Problemen zu unterscheiden: der Alterung einzelner Komponenten und der Eignung der Architektur als Ganzes. Liegt die Einschr\u00e4nkung in der Struktur selbst, kann der blo\u00dfe Austausch der Server das Problem lediglich verschieben, anstatt es zu l\u00f6sen.<\/p>\n\n Bevor eine neue Hardwarekonfiguration festgelegt wird, braucht es belastbare Daten zur bestehenden Umgebung.<\/p>\n\n CPU, RAM und Storage bilden den Ausgangspunkt, m\u00fcssen jedoch im Verh\u00e4ltnis zur tats\u00e4chlichen Nutzung betrachtet werden. Die den VMs zugewiesenen Ressourcen k\u00f6nnen deutlich von den tats\u00e4chlich genutzten Ressourcen abweichen. Beim Storage reicht es nicht aus, lediglich die belegten Terabyte zu kennen: Auch I\/O, Latenz, Datenwachstum und das erforderliche Redundanzniveau spielen eine Rolle.<\/p>\n\n Die Analyse sollte Folgendes ber\u00fccksichtigen:<\/p>\n\n Das Ziel besteht nicht darin, das neue System auf den heutigen Durchschnittsverbrauch auszulegen, sondern ein ausgewogenes Verh\u00e4ltnis zwischen tats\u00e4chlicher Nutzung, Lastspitzen, Resilienz und zuk\u00fcnftigem Wachstum zu finden.<\/p> <\/p><\/p>\n\n Nicht jede Erneuerung erfordert einen Wechsel der Architektur.<\/p>\n\n Wenn die bestehende Umgebung gut funktioniert und das Hauptproblem im Alter der Hardware liegt, kann es sinnvoll sein, die vorhandene Plattform zu erneuern. Haben sich im Laufe der Jahre hingegen verschiedene Systeme, Storage-Ressourcen und fragmentierte Infrastrukturen angesammelt, kann ein Refresh die Gelegenheit bieten, Ressourcen zu konsolidieren oder ein anderes Modell in Betracht zu ziehen<\/strong>.<\/p>\n\n Hier kann beispielsweise eine hyperkonvergente Infrastruktur<\/a> ins Spiel kommen, bei der Rechenleistung und verteilter Storage innerhalb desselben Clusters geplant werden.<\/p>\n\n Dies ist jedoch keine automatische Entscheidung. Anzahl der Nodes, Netzwerk, Storage-Performance, Latenz und betriebliche Kompetenzen m\u00fcssen zu den Workloads passen. Das Ziel besteht nicht darin, eine SAN um jeden Preis zu ersetzen, sondern herauszufinden, welche Architektur f\u00fcr die tats\u00e4chliche Umgebung langfristig am sinnvollsten ist.<\/p>\n\n Hier<\/a> finden Sie den ausf\u00fchrlichen Beitrag der AXOL Server-Systemadministratoren zu hyperkonvergenten Systemen.<\/p>\n\n Die Modernisierung der Infrastruktur bedeutet nicht nur, neue Hardware zu installieren. Ebenso wichtig ist die Frage, wie die bestehenden Dienste in die neue Umgebung \u00fcbertragen werden.<\/p>\n\n Welche VMs lassen sich problemlos migrieren? F\u00fcr welche Anwendungen ist ein geplantes Wartungsfenster erforderlich? Wie viel Downtime ist akzeptabel? Wurden die Backups vor der Migration \u00fcberpr\u00fcft?<\/em><\/p>\n\n Diese Aspekte k\u00f6nnen Auswirkungen auf Architektur, Zeitplanung und Gesamtkosten haben. Daher sollten Zielarchitektur und Migrationsplan gemeinsam entwickelt werden.<\/p>\n\n Auch der wirtschaftliche Vergleich sollte \u00fcber den reinen Hardwarepreis hinausgehen und Konfiguration, Migration, Backup, m\u00f6gliche Subskriptionen oder Lizenzen, Support sowie den zuk\u00fcnftigen Betriebsaufwand ber\u00fccksichtigen.<\/p>\n\n Eine Modernisierung bedeutet nicht zwangsl\u00e4ufig, die gesamte vorhandene Hardware au\u00dfer Betrieb zu nehmen. Noch zuverl\u00e4ssige Server k\u00f6nnen nach Pr\u00fcfung ihres Zustands, ihrer Performance, ihres Energieverbrauchs, ihrer Kompatibilit\u00e4t und Supportf\u00e4higkeit weiterhin eine sekund\u00e4re Rolle \u00fcbernehmen, beispielsweise f\u00fcr Backup oder Disaster Recovery.<\/p>\n\n Im Projekt Union Gas e Luce<\/a> wurden einige der vorhandenen Server f\u00fcr Proxmox Backup Server und Disaster Recovery weiterverwendet<\/strong>. Der Mehrwert liegt dabei nicht in der Wiederverwendung an sich, sondern darin, der bestehenden Hardware innerhalb des neuen Projekts eine sinnvolle Funktion zuzuweisen.<\/p>\n\n Lesen Sie die Fallstudie Union Gas e Luce<\/a>.<\/em><\/p>\n\n Ginvest verf\u00fcgte \u00fcber eine traditionelle Serverinfrastruktur<\/a>, die dem Wachstum der digitalen Dienste, des Dokumentenvolumens und der Anforderungen an die Betriebskontinuit\u00e4t nicht mehr gerecht wurde. Hinzu kamen das Ende des Software-Supports durch den Hersteller sowie Schwierigkeiten bei der Beschaffung von Hardwarekomponenten. Alle Details finden Sie in der Fallstudie zu Ginvest<\/a>.<\/p>\n\n Union Gas e Luce setzte hingegen bereits Proxmox VE ein<\/strong>, allerdings auf einer heterogenen, \u00fcber Jahre gewachsenen Infrastruktur mit gemeinsam genutztem SAN-Storage. In diesem Fall ging es bei der Modernisierung nicht darum, den Hypervisor zu wechseln, sondern die Architektur skalierbarer, flexibler und einfacher zu verwalten zu gestalten.<\/p>\n\n Zwei unterschiedliche Ausgangssituationen, die zum selben Grundsatz f\u00fchren: Die neue Konfiguration sollte das Ergebnis der Analyse sein \u2013 nicht deren Ausgangspunkt.<\/p>\n\n Bevor Sie eine neue Konfiguration anfordern, sollten Sie die wichtigsten Daten Ihrer aktuellen Umgebung zusammentragen: VMs, tats\u00e4chliche CPU- und RAM-Auslastung, Storage-Kapazit\u00e4t und -Wachstum, I\/O, Anforderungen an die Betriebskontinuit\u00e4t, Backups, anwendungsspezifische Einschr\u00e4nkungen sowie die f\u00fcr die kommenden Jahre erwarteten Workloads.<\/p>\n\n Auf dieser Grundlage l\u00e4sst sich beurteilen, ob die bestehende Architektur erneuert, Ressourcen konsolidiert oder ein anderes Modell eingef\u00fchrt werden sollte.<\/p>\n\nWarum die IT-Infrastruktur modernisieren?<\/h2>\n\n
So planen Sie die Modernisierung: von den tats\u00e4chlichen Workloads ausgehen<\/h2>\n\n
\n
IT-Infrastruktur erneuern oder modernisieren?<\/h2>\n\n
Migration und Betriebskontinuit\u00e4t sind Teil des Projekts<\/h2>\n\n
Was tun mit der bestehenden Hardware?<\/h2>\n\n
Zwei AXOL Server-Fallstudien, zwei unterschiedliche Gr\u00fcnde f\u00fcr eine Modernisierung<\/h2>\n\n
Wo Sie bei der Modernisierung Ihrer IT-Infrastruktur ansetzen sollten<\/h2>\n\n