Canonical en Microsoft maken op Azure gerichte kernel voor Ubuntu Cloud Images

Canonical en Microsoft hebben samengewerkt om een op Azure gerichte Ubuntu-kernel te ontwikkelen. Ze maken bekend dat de nieuwe, kleinere kernel vanaf deze week standaard aanwezig is in Cloud Images van Ubuntu 16.04.

De organisaties zeggen dat de kernel dezelfde ondersteuning en beveiligingsupdates zal ontvangen als reguliere Ubuntu-kernels. Momenteel moeten de op Azure gerichte kernel het nog doen zonder de Livepatch-dienst van Canonical, waarmee kritieke patches zonder een herstart toegepast kunnen worden. In de toekomst komt deze dienst mogelijk wel beschikbaar, aldus de aankondiging.

De nieuwe, verkleinde kernel moet onder meer beter presteren onder intensieve workloads op bepaalde Azure-instances. Daarnaast is er ondersteuning voor Accelerated Networking, waarmee een betere netwerkprestatie behaald moet kunnen worden. Verder zijn de meest recente Hyper-V-drivers aanwezig.

Gebruikers kunnen controleren of ze de nieuwe kernel gebruiken door uname -r uit te voeren en de output te controleren op het woord Azure. Het is ook mogelijk naar de oude versie terug te keren door deze te installeren en te herstarten. Samenwerking tussen Canonical en Microsoft komt vaker voor, bijvoorbeeld toen Bash in 2016 werd geïntroduceerd in Windows 10.

Reacties (20)

[wica]

Momenteel moeten de op Azure gerichte kernel het nog doen zonder de Livepatch-dienst van Canonical, waarmee kritieke patches zonder een herstart toegepast kunnen worden.

Jamaar als ik Livepatch wil gebruiken, moet mijn systemen wel met de dienst van Ubuntu communiseren.
Waarom niet gewoon via apt-get?

/edit
Livepatch is tot 3 systemen gratis, daarna kost het geld. Duidelijk waarom apt-get niet gebruikt wordt.

[Reactie gewijzigd door wica op 24 juli 2024 23:42]

[Xieoxer]

Het rebooten van een systeem vindt ik persoonlijk geen ramp. Ik zorg altijd voor dat een server dubbel uitgevoerd is en de zelfde configuratie draait. Met bijv rsync de data in sync houden. Daarnaast keepalived installeren en een crosslink maken dat beiden servers elkaar zien. Gaat de ene down dan neem automatisch de andere het over en zorgt voor dat het publieke IP adres claimt. Af en toe is ook fijn om te testen of system naar behoren blijft werken na een reboot.

[Reactie gewijzigd door Xieoxer op 24 juli 2024 23:42]

[Verwijderd]

Gaat de ene down dan neem automatisch de andere het over en zorgt voor dat het publieke IP adres claimt.

Waarvoor gebruik je niet gewoon een VIP + load balancer?

[burne]

Dat is zo ongeveer precies wat 'ie beschrijft. Het 'publieke IP adres' is wat jij een VIP noemt, en het ding wat er voor zorgt dat het verhuist van ene naar de andere machine is wat jij een 'load balancer' noemt.

(Ik zou failover geen load-balancing noemen, maar goed.. Dat is mijn insteek..)

[smitae]

Een Load-balancer is meestal een stukje voor je machines. En niets wat je op de 2 machines zet die je hoger beschikbaar wilt maken.

En een load-balancer kun je laten load-balancen, het kan ook zijn dat je alles naar 1 poot gaat sturen en als 1 poot dood gaat dan stuur je alles naar de andere poot. De load-balancer ziet dat voor je, moet je je loadbalancer natuurlijk wel in een HA setup draaien anders heeft het niet veel zin 😄
Niet alle toepassingen zijn geschikt om active-active achter een loadbakancer te draaien.

Keepalivd + crosslink met Heartbeat en rsync gaat al richting een "echte" HA cluster, pacemaker ding ofzo. Dan is een load-balancer voor HA in elk geval niet nodig.

[wica]

Klopt, heb de afgelopen 20jaar het nooit een ramp gevonden om een server te herstarten en als ik naar de huidige ontwikkelingen kijk, zal dit de komende 20 jaar nog steeds geen ramp zijn.

En zoals jij zegt, als een systeem kritiek genoeg is, dan N+1 minstens.
Dan zou ik zelfs livepatch niet vertrouwen.

[Soldaatje]

Waar haal je vandaan dat apt-get niet gebruikt wordt?
Livepatch is er om patches live te kunnen toepassen dus zonder herstart, dat wil niet zeggen dat ze apt-get eruit hebben gesloopt.
Sterker nog, er staat een voorbeeld apt-commando in het bronartikel, voor als je terug wil naar de normale kernel, die wel werkt met livepatch.

[wica]

Omdat je een abo moet nemen op een dienst van Ubuntu, waarbij de eerste 3 computers gratis zijn en de volgende computers moet je voor gaan betalen om livepatch te kunnen gebruiken.

En ja, je kan de azure kernel verwijderen via apt-get en er weer "normale" kernel gebruiken, maar dan heb je geen livepatch van ubuntu.

[Soldaatje]

The Azure tailored Ubuntu kernel will not support the Canonical Livepatch Service at the time of this announcement, but investigation is underway to evaluate delivery of this service in the future.

If, for now, you prefer livepatching at scale over the above performance improvements, it is possible to revert to the standard kernel, using the following commands:


$ sudo apt install linux-virtual linux-cloud-tools-virtual

$ sudo apt purge linux*azure

$ sudo reboot


As we continue to collaborate closely with various Microsoft teams on public cloud, private cloud, containers and services, you can expect further boosts in performance, simplification of operations at scale, and enablement of new innovations and technologies.

[CH4OS]

Andersom. De Azure kernel heeft nog geen livepatching support. De gewone kernel heeft dat juist wél, aldus de tekst.

[slaay]

Hij bedoelt waarschijnlijk; waarom is het niet mogelijk om de patches te installeren middels apt-get waarbij je dan ook niet hoeft te herstarten.

[Gijs007]

Zijn deze enkel bedoelt voor servers in Azure of ook voor servers die op een eigen Windows Server 2016 draaien in Hyper-v?

[Verwijderd]

@Gijs007

Algemeen
In principe zijn het twee totaal verschillende omgevingen: Windows Server 2016 + Hyper-V is (totaal) anders dan Azure, omwille van een aantal redenen.

De belangrijkste reden is eigenlijk de mate waarin gebruik wordt gemaakt van de Azure infrastructuur.

In principe bestaat de Azure infrastructuur uit diverse componenten, die in de loop der tijd verschillende namen hebben gekend, wat bijzonder verwarrend kan werken.

De beste manier om het verschil uit te leggen is aan de hand van de Azure Stack.

Het is mogelijk om met meerdere Windows Servers (lees: bepaalde versies daarvan) een on-premise "cloud environment" te maken, die verdacht veel lijkt op de Azure Cloud.

Daartoe is het simpelweg nodig om de Azure Stack te installeren, oftewel de software set die mogelijk maakt dat een combinatie van (bepaalde) Windows Servers net als Azure Cloud gebruikt kan worden.

Simpel gesteld, zonder Azure Stack is een Windows Server + Hyper-V gewoon een Windows Server.

Azure en Ubuntu
De Ubuntu systemen die in de Azure Cloud draaien zijn sterk afhankelijk van cloud-init.

Cloud-init is een onderdeeltje dat standaard in bepaalde Ubuntu versies aanwezig is, maar niet in alle versies van Ubuntu, wat betekent dat bepaalde Ubuntu images in Azure Cloud aangepast zijn.

Het probleem is dat cloud-init onderhouden wordt door Canonical, in samenwerking met Microsoft.

Het is soms een problematisch verhaal, in die zin dat bepaalde config stanza zou moeten werken, maar door de customization (noodzakelijk voor Azure Cloud) niet werkt.

Samengevat, de Windows Server + Hyper-V + Ubuntu image óf een set Windows Servers + Azure Stack kunnen nog steeds afwijken van datgene dat daadwerkelijk in de Azure Cloud draait.

In de praktijk is het veelal zo dat de Ubuntu systemen in de Azure Cloud relatief uniek zijn.

Het is dan ook veelal aan te bevelen om de Ubuntu images op een (lokale) Windows Server + Hyper-V omgeving nagenoeg identiek te houden aan de Ubuntu images in de Azure Cloud.

Potential work-around
Een aantal mogelijkheden bestaan om Ubuntu images te synchroniseren met de images in Azure Cloud.

Eén van de mogelijkheden is het realiseren van een eigen repository in Azure Cloud, maar dat is veelal een erg omslachtige oplossing.

Een simpele én kosteneffectieve work-around is het installeren van een Ubuntu image uit de Azure Cloud op een (lokale) Windows Server + Hyper-V server, zodat de Ubuntu images in Hyper-V eigenlijk gebruik maken van de (update) repo's die ook van toepassing zijn voor de Azure Cloud images.

In dat geval zal een apt-get (of soortgelijk) command leiden tot een relatief pijnloze update, die ervoor zal zorgen dat synchronisatie tussen cloud based images en de Hyper-V based images bestaat.

Het nadeel van een dergelijke (nasty!) work-around is dat er vroeg of laat problemen zullen ontstaan, dit omwille van het simpele feit dat (enerzijds) de Windows Server + Hyper-V infrastructuur niet gelijk is aan de Azure Cloud infrastructuur en (anderzijds) de veranderingen in de Azure Cloud sneller gaan dan welke verandering in de Windows Server omgeving dan ook.

Het is dus een beetje oppassen met een dergelijke (nasty) work-around.

Maar toch, in de praktijk vallen de problemen wel mee, dankzij het fijne Ubuntu OS.

In ieder geval, doe altijd eerst even een "update test" in een separate Hyper-V container.


Hopelijk helpt het bovenstaande een beetje!

[rdtechie]

Alleen Azure lijkt me, omdat Hyper-V in Azure net iets anders werkt dan de variant die jij en ik gebruiken. Dit is althans het verhaal wat Microsoft verteld.

[Tweaker1234]

Goede vraag.
Of eerder: wat zijn bepaalde Azure instances?
En kan je dus met een on premise omgeving ook met deze kernel voordeel mee halen.
Gezien Azure services/functionaliteiten steeds meer naar on premise komen (waar Azure veel van een on premise omgeving heeft (AD, Exchange, SQL enz))

[MoonWatcher]

Ditzelfde hebben ze eerder ook al gedaan voor Ubuntu op AWS.
https://insights.ubuntu.c...st-with-aws-tuned-kernel/

Dezelfde neveneffecten: Geen livepatch support.
Voor servers is dit toch wel degelijk noodzakelijk.
Er zijn er elke maand welk een paar en ik blijf niet bezig met 300 servers herstarten.
( Ik heb een server met 680 dagen uptime en 529 kernel live patches daartegen )

Ik snap dat dit marketingtechnisch voor Ubuntu goed uitkomt: Kijk ons eens, wij hebben de beste performance in de cloud. Gebruik ubuntu! Toch had ik liever gehad dat ze dit gewoon in hun mainline kernel mee hadden geintegreerd. ( of in ieder geval hun eigen distro kernel )

[wica]

Voor servers is dit toch wel degelijk noodzakelijk.

Waarom? Mijn servers mogen best herstarten.

Sterker nog, op AWS met 300+ machine's zou je strategie juist moeten zijn, lekker belangrijk als een server onderuit gaat.
Als je deze strategie op AWS niet toepast, ben je een dief van je portomonee. Aangezien je dan op reserved instances draait ipv spots.

[mg794613]

Als je live moet patches, heb je het niet handig opgezet. Je hebt loadbalancers met keepalived oid en een zwik nodes erachter. Rebooten EN 0 downtime. Maargoed dat zal mijn bekrompen mening zijn.

[Verwijderd]

Ja nee. Je denkt te klein. VM hosts, die tientallen andere servers/containers van verschillende partijen hosten kun je niet zomaar even uitknallen. Al deze hosts redundant opzetten is ook niet haalbaar. Niet de hele wereld is een handje vol webservers achter een paar lb’s.