The Doppler Quarterly (DEUTSCHE) Frühjahr 2016 | Page 12

Da die Betriebssysteme bzw. Plattformen der beiden Anwendungen unterschiedlich waren, benötigten wir zwei separate Migrationskonzepte. duktversionen, Unterstützung der Installation einer neuen Ins- tanz mit den Legacy-Versionen der Anwendungen, und vor allem die hoch komplexe Konfiguration der verschiedenen Komponenten zur Nachahmung der vorhande- nen Produktivsysteme. Das Team entschied, dass Klonen der Server ähnlich wie beim Lift-and-Shift-Vorgehensmodell einer Neuinstallation vorzuzie- hen sei. Da die Betriebssysteme bzw. Plattformen der beiden Anwendungen unterschiedlich waren, musste für jede Migration ein eigenes Konzept entwickelt werden. Wir führten eine detaillierte Portfolioanalyse durch, um alle Endpunkte und Abhängigkeiten der beiden Anwendungen zu ermitteln. Im Folgenden werden die jeweiligen Herausforderun- gen und die Wege zu ihrer Über- windung beschrieben. Herausforderungen bei Anwendung 1 • Domänen-Trust-Beziehungen und Computerkennwörter In einer Active Directory-Umge- bung verwenden Windows Server verschiedene Mechanismen zur gegenseitigen Authentifizierung, z. B. eine eindeutige SID pro 10 | THE DOPPLER | FRÜHJAHR 2016 Server sowie ein System zur Kennwortaktualisierung. Die Kennwörter werden regel- mäßig aktualisiert und der Domänen-Controller gestattet oder verweigert den Zugriff. Da wir vorab Zeit für die Vorbe- reitung der Server in AWS gewinnen wollten, wurde das Kennwortaktualisierungssystem mithilfe einer Gruppenrichtlinie vorübergehend deaktiviert, um Probleme bei Domänen-Trust- Beziehungen zu vermeiden. Bei unseren Tests stellte sich außerdem heraus, dass die AWS ELBs aufgrund der URL- Weiterleitung, Inkompatibilität mit CNAMEs und SPN- Anforderungen nicht geeignet für diese Anwendung waren Für das Clustering wurde ein Linux-basierter Lastverteiler mit HAProxy und Keepalived verwendet. Herausforderungen bei Anwendung 2 • Legacy-Anwendungen und Websites • Fehlende Konfigurations- dokumentation • Hartcodierte IP-Adressen • Fehlende Dokumentation und mangelnde Kenntnis der diversen Skripts Alle von der Anwendung bereitgestellten Inhalte wurden auf einer Netapp-Speicher- Appliance unter NFS gehostet. Das Volumen der Inhalte erreichte TB-Größe und es galt sicherzustellen, dass sie alle in AWS gespeichert, synchronisiert und für die Migration verfügbar sind. Eine NAS Virtual Appliance diente als NFS-Server in AWS und die Inhalte wurden per rsync gespeichert und ständig synchronisiert. Da es sich größtenteils um Write-Once- and-Read-Inhalte handelte, dauerte die erstmalige Synchro- nisierung erheblich länger als die inkrementellen Synchronisie- rungen, die regelmäßig bis zum Migrationsfenster durchgeführt wurden. Für die Anwendung waren auch URL-Weiterleitungen auf Lastverteilerebene vorgesehen. Daher konnten keine AWS ELBs eingesetzt werden. Ähnlich wie bei Anwendung 1 wurde ein Linux-basierter Lastverteiler mit HAProxy und Keepalived für das Clustering verwendet. Migrationskonzept Im Wesentlichen bestand die „Lift-and-Shift“-Migration aus der Replikation der Server zu