Von Verfluchtnochmal_5987108 am Do, 2. April 2020 um 02:09 #
Wenn man zu dämlich für dist-upgrades ist freut man sich halt über die Neuigkeiten einesbneuen RHEL Release die Fedora User schon seit Jahren vergessen haben
Unsere Produktivserver wurden 2008 installiert und laufen ohne Neuinstallation, das wäre damals RHEL5 gewesen, also zwischenzeitlich 3 mal alles neu aufsetzen und in 4 Jahren schon wieder
Sorry, zuviel Customizing wenn man kein Dosenfutter frisst und viel zu viel Arbeit im Vergleich zu 2 lächerlichen dist-upgrades pro Jahr die in 4 Stunden für 25 vserver erledigt sind (da wo ich herkomme testet man sowas und lässt es dann unattended laufen samt reboot mit der gleichen downtine eines stinknormalen kernel update)
Konkret keiner, aber warum darf er nicht seine Ansicht dazupacken?
Mich wundert eher der Verweis auf die Neuinstallation. Daß man CentOS nicht über Hauptversionen aktualisieren kann, habe ich irgendwann auch mit Erstaunen zur Kenntnis genommen. Aber bei RHEL soll das doch unterstützt werden, habe ich im Hinterkopf. Täusche ich mich da? Oder ist das ein „jaha, geht offiziell, ist aber so wenig zu gebrauchen, daß man es nicht macht“? Hat das jemand Erfahrung aus der Praxis?
Mit Debian/Ubuntu geht es ja durchaus, auch wenn man zumindest früher (habe keine aktuellen Erfahrungswerte) hinterher massig Scherben zusammenkehren durfte oder Systeme dabei so verkorkst wurden, daß man dann doch neuinstallierte...
Von den Linuxen sind bei uns diesbezüglich die Gentoos am unproblematischsten, wenngleich natürlich auch am zeitaufwändigsten (und wenn man sich erstmal „abgehängt“ hat, weil der Kunde mehrere Updateanfragen mit „jetzt nicht“ zurückgewiesen hatte, ist es ein Riesenspaß, da wieder in die Spur zu kommen - aber anderes Thema).
Von Versionsupgrade am Do, 2. April 2020 um 20:45 #
Wir betreuen in der Firma etwa 200 Server, von Debian, Centos, RHEL und Windows 2012 bis 2019 ist alles dabei.
Jetzt kam das Ende von Windows Server 2008, und wir konnten die Server problemlos auf Windows Server 2012 und dann Windows Server 2016 migrieren.
Debian unterstützt schon seit Ewigkeiten das Upgrade auf neue Versionen.
Die Centos/RHEL müssen wir tatsächlich neu installieren, da ein Upgrade nicht offiziell vorgesehen ist. Es sind zwar nur Oracle DB drauf, also hält sich die Neueinrichtung in Grenzen, per Script etwa 5 Minuten, hat mich aber auch erstaunt. Hoffentlich kommt das bei Centos/RHEL auch mal, dass man auf neue Versionen upgraden kann ohne Reinstallation.
>> Die Centos/RHEL müssen wir tatsächlich neu installieren, da ein Upgrade nicht offiziell vorgesehen ist. Es sind zwar nur Oracle DB drauf, also hält sich die Neueinrichtung in Grenzen, per Script etwa 5 Minuten, hat mich aber auch erstaunt.
Ihr wollt also in 5min eine produktive Oracle-Datenbank migriert haben? Vielleicht ist 5min das Script gelaufen, die Vorbereitungen/Tests etc. werden doch etwas mehr in Zeit genommen haben nehme ich an?! Allein die PreRequirements für Oracle-Datenbank-Systeme füllen je Distribution Seiten.
Hi. Also ich sichere die DB und andere Files per rsync auf einen 2. Rechner. Dann wird Centos neu installiert. Danach per Script wieder alle Files zurückkopiert, die Initscripte angelegt, die Libraries eingespielt per yum, die noch fehlen, und danach die DB wieder gestartet. Lass es auf einer DEV Maschine 10 Minuten sein, ist auch OK, und wirklich wenig Aufwand.
Das ganze zu entwickeln und zu testen hat mich einmalig 4 Stunden gekostet.
Haben das auf mittlerweile etwa 20 Server durchgespielt, je nach DB Größe kann das sichern und zurückspielen dauern. Da ich meine Server aber per 10G angebunden habe, geht das relativ fix. Bei den großen Datenbanken (DB Größe über 500 GB bis in den 8 TB Bereich) liegt die Oracle-DB eh auf einem externen NFS Mount, da muss ich also nur die Mountpoint wieder anlegen.
Ich würde mal sagen, deutlich einfacher wie unter Windows, wenn eine Neuinstallation fällig wäre.
Bei unseren Applikationsserver hat es uns aber auf der Windowsseite definitiv geholfen, dass ein Upgrade möglich war, und nicht alles neu installiert werden musste.
Von Verfluchtnochmal_5987108 am Sa, 4. April 2020 um 10:18 #
Ja weil der ganze Krempel nur bei 08/15 installationen funktionieren kann! Du hast bei einem RHEL major upgrade einen ganzen Rattenschwanz an Fedora dist-upgrades auf einen Schlag
6 auf 7 ist technisch unmöglich! dracut, grub2 passt nicht weil zu wenig Platz vor der ersten Partition, UsrMove, systemd
Apache 2.2 auf 2.4 überlebst du ohne massive Vorbereitung nur auf einem 08/15 setup
Bei Fedora war das jeweils EINE Baustelle plus ein paar Kleinigkeiten bei jedem Upgrade, viel Spaß alles gleichzeitig zu überblicken und vorzubereiten
Dazu kommt die Installation der Datenbank-Umgebung inkl. aller Betriebssystemsettings (s. Oracle Database PreRequirements). Zusätzlich muss die Datenbank in exakt der gleichen Patch-Version installiert und konfiguriert sein (es sei denn man kopiert auch die gesamte Datenbank-Installationsumgebung von Server1 zu Server2). Duplizierte Speicherorte für Controlfiles, Redologs, Archivefiles müssen ebenfalls konfiguriert werden. Des weiteren gilt es die gleiche Hostnamen-Konfigurationen etc. pp zu verwenden. Insbesondere der Enterprise-Manager 11g ist hier schnell ein Pferdefuss, da der Hostname in den Verzeichnisnamen eingebettet ist.
Klar: ein fertiges Script welches individuell zum Klonen einer Datenbankumgebung von Server1 auf Server2 entwickelt wurde ist in 10min durchgelaufen, aber unter Berücksichtigung aller o.g. Punkte ist der Gesamtaufwand bei Oracle ergeblich höher als 10min.
Zu Windows: Soviel höher als unter Linux ist der Aufwand unter Windows auch nicht. Tendenziell eher niedriger, da die benötigten Pre-Requirements nahezu wegfallen. Dafür hat Windows einen ganzen haufen anderer Nachteile - u.a. selbst via Powershell eine äusserst bescheidene Scripting-Umgebung.
Dieser Beitrag wurde 4 mal editiert. Zuletzt am 04. Apr 2020 um 01:26.
Stimme dir völlig zu. Da meine Oracle-dbs (Oracle Sw und die DB Files) unter /oracle installiert werden inkl. Software etc., muss ich nur diesen Rootfolder sichern und recovern. Schon hat man alles wieder.
Da der Rechner neu installiert wird, bleibt IP und Hostname gleich. Dann hat auch der gcagent kein Problem.
Bei einem Wechsel auf einen neuen Server geht das so natürlich nicht, da muss man dann schon einige Teile neu installieren und konfigurieren.
Von Verfluchtnochmal_5987108 am Sa, 4. April 2020 um 10:08 #
Bei RHEL5 wirst du Pech haben und ein dist-upgrade innerhalb eines major release existiert nicht weil die point releases keine wesentlichen Änderungen mitbringen, sowas als dist-upgrade zu bezeichnen ist lächerlich
Spannend wird es beim Support Ende!
Viel Spaß von RHEL 6 auf 7 und bevor ich einen Linux Server neu installiere steche ich mir in den Hals
Wenn man zu dämlich für dist-upgrades ist freut man sich halt über die Neuigkeiten einesbneuen RHEL Release die Fedora User schon seit Jahren vergessen haben
Unsere Produktivserver wurden 2008 installiert und laufen ohne Neuinstallation, das wäre damals RHEL5 gewesen, also zwischenzeitlich 3 mal alles neu aufsetzen und in 4 Jahren schon wieder
Sorry, zuviel Customizing wenn man kein Dosenfutter frisst und viel zu viel Arbeit im Vergleich zu 2 lächerlichen dist-upgrades pro Jahr die in 4 Stunden für 25 vserver erledigt sind (da wo ich herkomme testet man sowas und lässt es dann unattended laufen samt reboot mit der gleichen downtine eines stinknormalen kernel update)
Und? Wer hat dich nach deiner Meinung gefragt?
Konkret keiner, aber warum darf er nicht seine Ansicht dazupacken?
Mich wundert eher der Verweis auf die Neuinstallation. Daß man CentOS nicht über Hauptversionen aktualisieren kann, habe ich irgendwann auch mit Erstaunen zur Kenntnis genommen. Aber bei RHEL soll das doch unterstützt werden, habe ich im Hinterkopf. Täusche ich mich da? Oder ist das ein „jaha, geht offiziell, ist aber so wenig zu gebrauchen, daß man es nicht macht“? Hat das jemand Erfahrung aus der Praxis?
Mit Debian/Ubuntu geht es ja durchaus, auch wenn man zumindest früher (habe keine aktuellen Erfahrungswerte) hinterher massig Scherben zusammenkehren durfte oder Systeme dabei so verkorkst wurden, daß man dann doch neuinstallierte...
Von den Linuxen sind bei uns diesbezüglich die Gentoos am unproblematischsten, wenngleich natürlich auch am zeitaufwändigsten (und wenn man sich erstmal „abgehängt“ hat, weil der Kunde mehrere Updateanfragen mit „jetzt nicht“ zurückgewiesen hatte, ist es ein Riesenspaß, da wieder in die Spur zu kommen - aber anderes Thema).
Wir betreuen in der Firma etwa 200 Server, von Debian, Centos, RHEL und Windows 2012 bis 2019 ist alles dabei.
Jetzt kam das Ende von Windows Server 2008, und wir konnten die Server problemlos auf Windows Server 2012 und dann Windows Server 2016 migrieren.
Debian unterstützt schon seit Ewigkeiten das Upgrade auf neue Versionen.
Die Centos/RHEL müssen wir tatsächlich neu installieren, da ein Upgrade nicht offiziell vorgesehen ist. Es sind zwar nur Oracle DB drauf, also hält sich die Neueinrichtung in Grenzen, per Script etwa 5 Minuten, hat mich aber auch erstaunt.
Hoffentlich kommt das bei Centos/RHEL auch mal, dass man auf neue Versionen upgraden kann ohne Reinstallation.
>> Die Centos/RHEL müssen wir tatsächlich neu installieren, da ein Upgrade nicht offiziell vorgesehen ist. Es sind zwar nur Oracle DB drauf, also hält sich die Neueinrichtung in Grenzen, per Script etwa 5 Minuten, hat mich aber auch erstaunt.
Ihr wollt also in 5min eine produktive Oracle-Datenbank migriert haben? Vielleicht ist 5min das Script gelaufen, die Vorbereitungen/Tests etc. werden doch etwas mehr in Zeit genommen haben nehme ich an?! Allein die PreRequirements für Oracle-Datenbank-Systeme füllen je Distribution Seiten.
Hi. Also ich sichere die DB und andere Files per rsync auf einen 2. Rechner. Dann wird Centos neu installiert. Danach per Script wieder alle Files zurückkopiert, die Initscripte angelegt, die Libraries eingespielt per yum, die noch fehlen, und danach die DB wieder gestartet. Lass es auf einer DEV Maschine 10 Minuten sein, ist auch OK, und wirklich wenig Aufwand.
Das ganze zu entwickeln und zu testen hat mich einmalig 4 Stunden gekostet.
Haben das auf mittlerweile etwa 20 Server durchgespielt, je nach DB Größe kann das sichern und zurückspielen dauern. Da ich meine Server aber per 10G angebunden habe, geht das relativ fix. Bei den großen Datenbanken (DB Größe über 500 GB bis in den 8 TB Bereich) liegt die Oracle-DB eh auf einem externen NFS Mount, da muss ich also nur die Mountpoint wieder anlegen.
Ich würde mal sagen, deutlich einfacher wie unter Windows, wenn eine Neuinstallation fällig wäre.
Bei unseren Applikationsserver hat es uns aber auf der Windowsseite definitiv geholfen, dass ein Upgrade möglich war, und nicht alles neu installiert werden musste.
Ach ja: Es gibt wohl ein ungetestetes Migratonstool von Centos, von deren Nutzung aber in divesen Foren abgeraten wurde.
Ja weil der ganze Krempel nur bei 08/15 installationen funktionieren kann! Du hast bei einem RHEL major upgrade einen ganzen Rattenschwanz an Fedora dist-upgrades auf einen Schlag
6 auf 7 ist technisch unmöglich! dracut, grub2 passt nicht weil zu wenig Platz vor der ersten Partition, UsrMove, systemd
Apache 2.2 auf 2.4 überlebst du ohne massive Vorbereitung nur auf einem 08/15 setup
Bei Fedora war das jeweils EINE Baustelle plus ein paar Kleinigkeiten bei jedem Upgrade, viel Spaß alles gleichzeitig zu überblicken und vorzubereiten
Dazu kommt die Installation der Datenbank-Umgebung inkl. aller Betriebssystemsettings (s. Oracle Database PreRequirements). Zusätzlich muss die Datenbank in exakt der gleichen Patch-Version installiert und konfiguriert sein (es sei denn man kopiert auch die gesamte Datenbank-Installationsumgebung von Server1 zu Server2). Duplizierte Speicherorte für Controlfiles, Redologs, Archivefiles müssen ebenfalls konfiguriert werden.
Des weiteren gilt es die gleiche Hostnamen-Konfigurationen etc. pp zu verwenden. Insbesondere der Enterprise-Manager 11g ist hier schnell ein Pferdefuss, da der Hostname in den Verzeichnisnamen eingebettet ist.
Klar: ein fertiges Script welches individuell zum Klonen einer Datenbankumgebung von Server1 auf Server2 entwickelt wurde ist in 10min durchgelaufen, aber unter Berücksichtigung aller o.g. Punkte ist der Gesamtaufwand bei Oracle ergeblich höher als 10min.
Zu Windows: Soviel höher als unter Linux ist der Aufwand unter Windows auch nicht. Tendenziell eher niedriger, da die benötigten Pre-Requirements nahezu wegfallen. Dafür hat Windows einen ganzen haufen anderer Nachteile - u.a. selbst via Powershell eine äusserst bescheidene Scripting-Umgebung.
Dieser Beitrag wurde 4 mal editiert. Zuletzt am 04. Apr 2020 um 01:26.Stimme dir völlig zu. Da meine Oracle-dbs (Oracle Sw und die DB Files) unter /oracle installiert werden inkl. Software etc., muss ich nur diesen Rootfolder sichern und recovern. Schon hat man alles wieder.
Da der Rechner neu installiert wird, bleibt IP und Hostname gleich. Dann hat auch der gcagent kein Problem.
Bei einem Wechsel auf einen neuen Server geht das so natürlich nicht, da muss man dann schon einige Teile neu installieren und konfigurieren.
Der gleiche der den Typen vor mir nach seiner Unfähigkeit öfters als alle 10 Jahre seinen Arsch zu heben gefragt hat
Schon wieder voll?
* RHEL5/6 werden mit entsprechenden Supportverträgen noch unterstützt.
* RHEL supported Dist-Upgrades innerhalb von Major-Releases.
Bei RHEL5 wirst du Pech haben und ein dist-upgrade innerhalb eines major release existiert nicht weil die point releases keine wesentlichen Änderungen mitbringen, sowas als dist-upgrade zu bezeichnen ist lächerlich
Spannend wird es beim Support Ende!
Viel Spaß von RHEL 6 auf 7 und bevor ich einen Linux Server neu installiere steche ich mir in den Hals