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