Vraag Waarom is het zo moeilijk om te upgraden tussen de belangrijkste versies van Red Hat en CentOS?


"Kunnen we onze bestaande productie-EL5-servers upgraden naar EL6?"

Een eenvoudig klinkend verzoek van twee klanten met helemaal verschillende omgevingen waren de aanleiding voor mijn gebruikelijke 'best-practices' antwoord: "Ja, maar het vereist een gecoördineerde herbouwen van al uw systemen" ...

Beide klanten zijn van mening dat een volledige herbouw van hun systemen een onaanvaardbare optie is voor downtime en resource-redenen ... Toen mij werd gevraagd waarom het nodig was om de systemen volledig opnieuw te installeren, had ik geen goed antwoord: "Zo is het ..."

Ik probeer geen antwoorden over configuratiebeheer op te roepen ("Puppetize alles" is niet altijd van toepassing) of hoe de klanten beter hadden moeten plannen. Dit is een echt voorbeeld van omgevingen die zijn gegroeid en bloeien in een productiecapaciteit, maar die geen schoon pad hebben om naar de volgende versie van hun besturingssysteem te gaan.

Omgeving A:
Non-profit organisatie met 40 x Red Hat Enterprise Linux 5.4 en 5.5 web, databaseservers en mailservers, een Java-webapplicatiestapel, software load balancers en Postgres-databases. Alle systemen worden gevirtualiseerd op twee VMWare vSphere-clusters op verschillende locaties, elk met HA, DRS, enz.

Omgeving B:
Hoogfrequente financiële handelsfirma met 200 x CentOS 5.x systemen in meerdere co-locatiefaciliteiten met productieverhandelingsactiviteiten, die interne ontwikkeling en backofficefuncties ondersteunen. De handelsservers draaien op bare-metal commodity-serverhardware. Ze hebben tal van sysctl.conf, rtctl, onderbreek binding en driver tweaks op zijn plaats om de latentie van berichten te verminderen. Sommige hebben aangepaste en / of realtime kernels. De ontwikkelaarswerkstations hebben ook een vergelijkbare versie (s) van CentOS.


In beide gevallen werken de omgevingen goed zoals ze zijn. De wens om te upgraden komt voort uit de behoefte aan een nieuwere applicatie of functie die beschikbaar is in EL6.

  • Voor de non-profitorganisatie is het gekoppeld aan Apache, de kernel en enkele dingen die de ontwikkelaars gelukkig zullen maken.
  • In de handelsfirma gaat het om enkele verbeteringen in de kernel, netwerkstack en GLIBC, wat de ontwikkelaars gelukkig zal maken.

Beide zijn dingen die niet zonder meer gemakkelijk kunnen worden verpakt of bijgewerkt het besturingssysteem drastisch wijzigen.

Als systeemingenieur, waardeer ik dat Red Hat volledige herbouwingen aanbeveelt bij het schakelen tussen de belangrijkste versieversies. Een schone start dwingt je om te refactoren en aandacht te besteden aan configs onderweg.

Omdat ik gevoelig ben voor zakelijke behoeften van klanten, vraag ik me af waarom dit zo moet zijn zware taak. Het RPM-verpakkingssysteem is meer dan geschikt voor interne upgrades, maar het zijn de kleine details die u ertoe brengen: /boot meer schijfruimte nodig, nieuwe standaard bestandssystemen, RPM mogelijk doorbrekende mid-upgrade, verouderde en ter ziele gegane pakketten ...

Wat is het antwoord hier? Andere distributies (.deb-gebaseerd, Arch en Gentoo) lijken dit vermogen of een beter pad te hebben. Laten we zeggen dat we de downtime vinden om deze taak te volbrengen rechts manier:

  • Wat moeten deze klanten doen om hetzelfde probleem te voorkomen wanneer EL7 wordt vrijgegeven en gestabiliseerd?
  • Of is dit een geval waarin mensen zich om de paar jaar moeten neerleggen bij volledige herbouwingen?
  • Dit lijkt te zijn verergerd als Enterprise Linux is geëvolueerd ... Of stel ik me dat alleen voor?
  • Heeft dit iemand ervan weerhouden om Red Hat en afgeleide besturingssystemen te gebruiken?

Ik veronderstel dat er een configuratiebeheerhoek is, maar de meeste Puppet-installaties die ik zie, vertalen niet goed naar omgevingen met zeer aangepaste toepassingsservers (Omgeving B kan een enkele server hebben waarvan ifconfig uitgang het lijkt op dit). Ik zou wel graag willen horen hoe configuratiemanagement kan worden gebruikt om organisaties te helpen de grote versiebubbel van RHEL te overstijgen.


70
2017-11-15 15:14


oorsprong


Ik stond op het punt om dit als afsluiting te bestempelen als "niet constructief", toen ik de naam van de auteur en vertegenwoordiger zag, en uit respect zal ik dat niet doen. Ik vind het nog steeds een domme vraag, want het antwoord is: "Red Hat besloot dat het zo zou zijn". 4-> 5-upgrades waren perfect mogelijk via dvd-boot en er waren procedures om dit te doen met een live OS-gebruik yum, wat voor mij het grootste deel van de tijd werkte. Mijn enige hoop is dat RH een a reusachtig De pijn van hun betalende klanten wordt geraakt door hun beslissing om geen ondersteund upgradepad van 5-> 6 te hebben en zal dit opnieuw overwegen voor 6-> 7. - MadHatter
Dat gezegd hebbende, weet u dat er een werkend niet-ondersteund upgradepad is via dvd-booten vanaf C5-> C6 met behulp van de upgradeany boot-time parameter, ja? Ik heb het twee keer getest, eenmaal op een schone C5-installatie waar het goed werkte; eenmaal op een (testkopie van een) crufty oud "was C4 en werd geüpgraded" installeren waar het dramatisch faalde. - MadHatter
Ik ben goed op de hoogte van de upgradeany-opties en heb de installaties absoluut gedwongen de live RPM-benadering te gebruiken (veranderde repo, *-release files en alles). Maar de vragen van klanten van deze week deden me meer nadenken over hoe vastgebakken een omgeving kan worden met een specifieke versie, en geen pad naar buiten hebben. - ewwhite


antwoorden:


(Opmerking van de auteur: dit antwoord verwijst naar RHEL 6 en eerdere versies. RHEL 7 heeft nu een volledig ondersteund upgradepad van RHEL 6, waarvan de details aan het einde zijn.)


Om te beginnen moet ik opmerken dat er zijn twee manieren om de interne upgrade uit te voeren:

  1. Plaats de installatie-dvd (of gebruik de dvd-afbeelding via iLO / iDRAC), start op en kies Upgrade, bijv. linux upgradeany.
  2. Werk het redhat-release RPM handmatig, uitvoeren yum distro-sync (dit is een beetje versimpeld) en start opnieuw op.

Methode 1 wordt alleen niet ondersteund. Methode 2 is voor echte cowboys. Naast de aanbevolen nieuwe installaties, heb ik beide gedaan ...


Heb ik ondersteuning nodig?

Ondersteuning heeft twee complementaire betekenissen in onze wereld. De eerste is dat een product een gegeven kenmerk heeft (bijvoorbeeld "Postfix ondersteunt SMTP"). De tweede is dat de verkoper met u erover zal praten. Welke definitie wordt bedoeld, is niet altijd duidelijk uit de context.

Om een ​​taak te volbrengen, heb je duidelijk behoefte aan ondersteuning in de eerste zin. Waar support van leveranciers binnenkomt, is om u te helpen bij het oplossen van problemen en om de leverancier feedback te geven over welke functies moeten bestaan ​​of worden verbeterd. Veel sites betalen een fortuin voor leveranciersondersteuning wanneer ze de expertise in huis hebben om eventuele problemen op te lossen, sneller en zelfs goedkoper dan de leverancier zou kunnen doen. Of u leverancierondersteuning wilt kopen, is uiteindelijk een zakelijke beslissing die u moet nemen (of advies aan het management geven).


Waarom niet een interne upgrade doen?

Dit is wat Red Hat erover zegt:

Red Hat ondersteunt geen interne upgrades tussen belangrijke versies van Red Hat Enterprise Linux. Een hoofdversie wordt aangegeven door een wijziging van de gehele nummerversie. Red Hat Enterprise Linux 5 en Red Hat Enterprise Linux 6 zijn bijvoorbeeld beide hoofdversies van Red Hat Enterprise Linux.

Interne upgrades voor grote releases behouden niet alle systeeminstellingen, services of aangepaste configuraties. Daarom beveelt Red Hat ten stelligste nieuwe installaties aan bij het upgraden van de ene hoofdversie naar de andere.

Ze waarschuwen verder:

Houd echter rekening met de volgende beperkingen voordat u ervoor kiest om uw systeem te upgraden:

  • Afzonderlijke pakketconfiguratiebestanden kunnen al dan niet werken na het uitvoeren van een upgrade als gevolg van wijzigingen in verschillende configuratiebestandsindelingen of lay-outs.
  • Als u een gelaagde producten van Red Hat (zoals de Cluster Suite) hebt geïnstalleerd, moet deze mogelijk handmatig worden bijgewerkt nadat de Red Hat Enterprise Linux-upgrade is voltooid.
  • Externe of ISV-applicaties werken mogelijk niet correct na de upgrade.

Natuurlijk beschrijven ze vervolgens hoe je een interne upgrade uitvoert via methode 1, voor het geval je het echt wilt doen. De functie bestaat en Red Hat brengt ontwikkelingstijd in, dus het wordt ondersteund doordat de functie bestaat. Maar als er iets misgaat, zal Red Hat u vertellen dat u het vers moet installeren; ze zullen geen ondersteuning bieden aan leveranciers voor dingen die kapot gaan als gevolg van de upgrade.

Voor de goede orde, ik heb nooit echt een probleem gehad met een interne upgrade van een RHEL / CentOS- of Fedora-systeem dat ik zelf niet kon oplossen. De typische problemen komen van hernoemde pakketten, externe opslagplaatsen en de incidentele versie komt niet overeen tussen de i386- en x86_64-architecturen van een pakket. Het installatieprogramma is iets beter in het omgaan met deze dan yum, I denk.


Hoe moet ik upgraden?

Over het algemeen waarschuw ik mensen dat ze zouden moeten plan in een onderhoudsvenster om de 3-4 jaar om RHEL-systemen van de ene hoofdversie naar de volgende bij te werken. Terwijl upgrades over het algemeen soepel verlopen, kan het onverwachte altijd gebeuren.

Voor beide omgevingen verwacht ik dat een interne upgrade zou werken, hoewel ik ten zeerste aanbeveel om eerst grondig te testen. P2V een representatief voorbeeld van de servers en doorloop de interne upgrade op de virtuele systemen om te zien welke problemen u tegen zult komen. U kunt dan de daadwerkelijke productie-upgrade plannen op basis van betere kennis van wat er zal gebeuren.

Voor een grote inzet zoals je hier hebt, kun je overwegen om de "one-some-many" benadering van Limoncelli te gebruiken. Upgrade één machine, kijk welke problemen zich voordoen, los ze op, gebruik dan lessen die je hebt geleerd bij het upgraden van een kleine partij machines, herhaal het geleerde ding en als je denkt dat je alle knikken hebt uitgewerkt, upgrade dan grote batches.

Op een moment als dit, raad ik aan om een ​​lange blik te werpen op het implementatieproces van uw toepassing. Als het niet voldoende geautomatiseerd is, kun je het met één enkele opdracht starten en redelijk zeker zijn dat de app correct zal worden geïmplementeerd, en misschien moeten de ontwikkelaars daar aan de slag. Met een dergelijk implementatieproces zou het veel gemakkelijker zijn om een ​​nieuwe installatie van de nieuwere versie van EL uit te voeren en er vervolgens op te implementeren.


Kunnen overstapverdelingen helpen?

Op Debian gebaseerde distributies hebben een ondersteunde interne upgrademethode en deze werkt meestal, maar is niet immuun voor problemen. Er zijn veel dingen gebroken voor mensen upgraden van Ubuntu 10.04 LTS naar 12.04 LTS via de ondersteunde methode, bijvoorbeeld. Het is niet duidelijk dat Debian of Canonical voldoende ontwikkelingstijd besteedt aan het "ondersteunen" van deze functie, d.w.z. ervoor te zorgen dat het werkt. En je moet nog steeds leveranciersondersteuning voor deze distributie kopen als je wilt dat iemand je hand vasthoudt. Dus ik betwijfel of je veel zult winnen van het overschakelen naar een dergelijke distributie.

U kunt winnen door over te schakelen naar een rollend-release-distributie zoals Gentoo of Arch. Dit maakt je echter ook niet immuun voor problemen; het betekent alleen dat je continu moet omgaan met de upgradeproblemen gedurende de levensduur van de server (bijvoorbeeld wanneer jij of de ontwikkelaars besluiten om iets op het systeem bij te werken), in plaats van alles tegelijk in een goed geplande distributie-upgradetijd. U hebt ook geen leverancier om ondersteuning te bieden.


Wat heeft de toekomst in petto?

Het Fedora Project werkt aan een tool om interne upgrades te verbeteren. Ze hadden een tool genaamd preupgrade die werd verlaten en vervangen door een nieuwe tool genaamd fedup beginnend met Fedora 18. Dit is toegevoegd aan RHEL7 en nu interne upgrades hebben volledige ondersteuning, tenminste van RHEL 6 tot RHEL 7. Uit mijn eigen ervaring kan ik zeggen dat terwijl fedup heeft nog steeds enkele knikken, het wordt vormgegeven als een zeer nuttig hulpmiddel.

CentOS is ook aan het experimenteren een roll-release type repository, maar het is alleen van toepassing tussen minder belangrijke versies (bijvoorbeeld 6.3-6.4).


41
2017-11-15 17:09



De nieuwe Fedora upgrade tool wordt aangeroepen beu. Drie tot vier jaar klinkt voor mij ook agressief voor grote upgrades, moet ik installeren. Ik zie nog veel meer in de richting van de 10+ jarige levenscyclus van RHEL, dus ik zou meer regelmatige kleine upgrades aanmoedigen. - Dominic Cleal
Voor mensen die voortdurend nieuwe functies nodig hebben, is 3-4 jaar bijna te lang. - Michael Hampton♦
Eenvoudige dingen zoals PHP, Apache, kernelrevisies en GLIBC ... Mensen hebben de neiging om die veranderingen vaker te willen. - ewwhite
Het upgradeproces van Debian / Ubuntu is niet perfect, maar het feit dat dit het geprefereerde upgrade-mechanisme is en Red Hat geen officieel ondersteunde upgrade-mechanisme heeft, spreekt boekdelen voor mij. - Paul Gear
Het is niet zozeer of interne upgrades bestaan, zoals duidelijk is, maar of de respectieve leveranciers hen ondersteunen. - Michael Hampton♦


Mijn kijk op je laatste alinea:

Ik veronderstel dat er een configuratiebeheerhoek is, maar de meeste Puppet-installaties die ik zie, vertalen niet goed naar omgevingen met zeer aangepaste applicatieservers (Environment B zou een enkele server kunnen hebben waarvan de ifconfig-uitvoer er zo uitziet). Ik zou wel graag willen horen hoe configuratiemanagement kan worden gebruikt om organisaties te helpen de grote versiebubbel van RHEL te overstijgen.

Ik denk dat de echte waarde van configuratiebeheersystemen, vooral in de context van Environment B, is dat ze de tools bieden om een ​​service te bouwen onafhankelijk van de servers die deze uitvoeren. Als een CMS niet is gebruikt om de bestaande services te maken, zal het waarschijnlijk niet veel helpen bij het opnieuw maken van de services.

Ik weet dat dit je directe probleem niet oplost, maar voor mij komt het voort uit de gedachte van de organisatie in termen van servers in plaats van diensten. Bij servicegericht denken hoeft de persoonlijkheid van individuele servers niet te worden gehandhaafd zolang de service blijft functioneren. Als een CMS op een gedisciplineerde manier wordt gebruikt om de volledige service te bouwen, moet het verhuizen van die service naar een ander systeem relatief eenvoudig zijn, omdat de persoonlijkheid van de machine wordt gebouwd door de CMS.

Postscriptum Ik weet niet precies zeker wat belangrijk is in de uitvoer van ifconfig in deze context - het wordt geproduceerd door een configuratiebestand en een aantal scripts (anders zou het niet aanwezig zijn bij het opstarten) en deze kunnen indien nodig worden beheerd door een CMS.


5
2017-11-20 22:28



U hebt gelijk wat betreft services versus servers in algemene zin. Environment B heeft een aantal gespecialiseerde serverhardware (10 GbE NIC's, offload-bibliotheken) die interfaces heeft met upstream-providers. Het is iets dat niet kan worden uitgebalanceerd of eenvoudig kan worden verplaatst zonder downtime. Een niet-financieel voorbeeld is zoiets als een server die is aangesloten als controller voor sommige betrokken productiemachines. Speciaal geval, misschien met speciale PCIe-interfacekaarten. Zeer een eenmalige setup die uniek is voor de server. Zou je in Puppet gewoon zeggen: "Hier is de configuratie voor deze ene host / rol" en ermee leven? - ewwhite
Overeengekomen, sommige dingen zijn niet eenvoudig in te passen in algemene gevallen, vooral als u een omgeving hebt met specifieke hardwarevereisten. Met marionet is het verstandig om zoveel mogelijk in de rol te duwen. Maar uiteindelijk moet het werken, dus als iets dat niet echt elegant is, het doet werken, dan leef ik gewoon omdat het onelegant is. Veel van de tijd moeten we leven met dingen die onelegant zijn, simpelweg omdat we geen tijd hebben om ze "goed" te maken. - Paul Gear