CloudLinux OS 9: Funktioner og begrænsninger ved delt hosting

At placere CloudLinux OS 9 i den rette sammenhæng

CloudLinux OS 9 er en fortsat dokumenteret generation af operativsystemer til delt hosting baseret på AlmaLinux 9. Den skal dog ikke forveksles med CloudLinux OS 10, som producenten betragter som en separat hovedgren. Versionsnummeret i sig selv beskriver hverken licensomfanget eller de tilgængelige komponenter til delt hosting på en bestemt server.

For klassificeringen er AlmaLinux-kernen Vigtigt: CloudLinux OS 9 bruger ikke længere sin egen CloudLinux-kerne, men AlmaLinux-kernen. Derfor er en del af navnet som f.eks. „LVE“ i kerneversionen ikke et egnet kriterium til at vurdere aktiv ressourceisolering. LVE skal kontrolleres via de installerede CloudLinux-komponenter og deres driftsstatus, ikke via tegnstrengen i kernens navn.

Denne adskillelse forhindrer en udbredt misforståelse i forbindelse med en CloudLinux-opdatering: En opgradering til OS 9 erstatter ikke kontrollen af begrænsninger, CageFS, PHP-handlere eller databasestyring. Operativsystemversionen skaber det tekniske grundlag; hvilke funktioner der er synlige for kunderne, afhænger først og fremmest af kombinationen af licens, pakker og panelintegration. Især på voksende servere kan disse niveauer afvige fra hinanden.

Som tilvalg findes der til CloudLinux OS 9 et LTS-kernen tilgængelig. Ifølge producenten indeholder den sikkerhedsrettelser og færre ændringer fra upstream end den almindelige AlmaLinux-kerne. Det kan være velegnet til miljøer med en konservativ ændringsplanlægning, men er ikke nødvendigvis det bedste valg i alle tilfælde. Udbydere skal afveje kravene til hardwaredrivere, anvendt software, vedligeholdelsesprocesser og kernelstrategien for hele serverparken.

Sørg for en klar adskillelse mellem udgaver og licenser

Versionsnummeret CloudLinux OS 9 angiver hverken en udgave eller en licens. Ved shared hosting skal der især skelnes mellem CloudLinux OS Legacy, tidligere CloudLinux OS Shared, og CloudLinux OS Shared Pro. Legacy understøtter et ubegrænset antal hostingkonti og omfatter etablerede komponenter som LVE, CageFS, MySQL Governor, PHP Selector og sprogvælgere.

Shared Pro skal betragtes separat: I oversigten over udgaver er funktioner som PHP X-Ray, Centralized Monitoring og AccelerateWP tilknyttet denne udgave. En cloudlinux-opdatering fra OS 8 til OS 9 aktiverer derfor ikke disse funktioner, hvis den relevante Pro-licens og de respektive installations- og panelkrav ikke er opfyldt.

CloudLinux OS Admin er heller ikke en forkortet betegnelse for Shared Pro. Denne udgave er rettet mod et andet anvendelsesområde; blandt andet er MySQL Governor ikke inkluderet her. Hvis man ønsker at begrænse databaseoverbelastning pr. hostingkonto, må man derfor ikke ud fra en eksisterende CloudLinux-installation alene konkludere, at dette værktøj er tilgængeligt.

Inden der gives en tilsagn om funktionalitet, skal der besvares tre spørgsmål hver for sig: Hvilken udgave er der licens til, hvilke pakker er installeret, og understøtter det eksisterende panel den ønskede komponent? Derudover kan versionsstatus for de enkelte pakker ændre forudsætningerne. En vellykket konvertering af operativsystemet bekræfter kun selve konverteringsprocessen; den bekræfter ikke automatisk, at alle valgfrie moduler er klar til brug.

Isolering og begrænsninger ved shared hosting

I forbindelse med delt hosting opfyldes LVE opgaven med at begrænse ressourceforbruget pr. konto. Dette omfatter blandt andet CPU, RAM, ind- og udlæsningsoperationer, processer og samtidige webadgange. Hvis et projekt når sine grænser, skal dets ressourceforbrug ikke belaste andre konti uforholdsmæssigt meget. Dette er en beskyttelse mod overforbrug, men ikke en automatisk løsning på langsomme applikationer eller fejlbehæftede databaseforespørgsler.

I forbindelse med forhandlertilbud supplerer forhandlergrænserne kontogrænserne. De begrænser det samlede forbrug på en forhandlers underkonti. De enkelte abonnementer kan matematisk set have højere værdier, men underkontiene må samlet set ikke overskride den overordnede grænse. Dette gør kapaciteter og abonnementsløfter mere gennemsigtige, men kræver en passende planlægning af den samlede grænse.

CageFS har et andet formål end LVE: Det Filsystemisolering begrænser en brugers synlige systemmiljø og har til formål at forhindre adgang til filer på andre hostingkonti. Den erstatter dog ikke en fuldstændig sikkerhedsarkitektur. På cPanel-servere nævner producentens dokumentation blandt andet WebDAV, File Manager, Webmail og FTP-servere uden korrekt chrooting som scenarier, hvor CageFS ikke virker. Beskyttelse mod symlinks og en sikker tjenestekonfiguration forbliver separate opgaver.

PHP Selector gør det muligt at vælge centralt godkendte PHP-versioner og udvidelser og kræver, at CageFS er installeret. MySQL Governor overvåger databasebrugen pr. bruger og kan begrænse konti, der belaster systemet for meget; mod_lsapi er derimod en PHP-handler til Apache. Modulerne supplerer hinanden, men er ikke indbyrdes udskiftelige. Deres tilgængelighed og hensigtsmæssige kombination afhænger af udgave, webserver og konfiguration.

Panelintegrationen kræver særlig opmærksomhed. På cPanel-systemer bør kunderne ikke kunne finde både PHP Selector og et konkurrerende MultiPHP-valg som ligeværdige muligheder, da dette kan føre til modstridende indstillinger. Desuden integrerer ikke alle paneler alle funktioner i samme omfang. For en mere detaljeret afgrænsning af konto- og webstedsisolering henvises til artiklen om SecureLVE og procesisolering i delt hosting; det afgørende er dog licensen, den dokumenterede panelunderstøttelse og den konkrete serverkonfiguration.

Vælg komponenter efter anvendelsesformål

Ved valget er det den konkrete anvendelse, der tæller, ikke blot betegnelsen »CloudLinux OS 9«. Operativsystem, udgave, licens, installerede pakker og kontrolpanel udgør hver især separate kontrolpunkter. Shared-Pro-udvidelser bliver ikke automatisk tilgængelige ved en OS-opgradering; oversigten over udgaver og kravene til den pågældende komponent skal vurderes samlet.

Tabellen er en beslutningshjælp, ikke en godkendelse til installation. Inden du giver dit samtykke, skal du kontrollere den understøttede panelversion, PHP-handleren, den konkrete licens og pakkestatus. CloudLinux dokumenterer egne integrationsbetingelser for de enkelte komponenter; derfor kan en funktion, der i princippet findes, mangle i et bestemt panelmiljø eller administreres på en anden måde.

Denne opdeling er særlig vigtig for takstplanlægningen: LVE-grænser beskytter den fælles serverkapacitet på konto-niveau, mens forhandlergrænser fastsætter en yderligere fælles øvre grænse for underkonti. CageFS, PHP Selector og MySQL Governor løser derimod andre opgaver. En komponent bør derfor vælges ud fra den konstaterede flaskehals eller det konstaterede behov for beskyttelse, ikke ud fra en generel liste over funktioner.

Praktisk planlægning af begrænsninger og PHP-administration

Hvis en WordPress-shop skaber belastningsspidser, begrænser kontobegrænsninger CPU, RAM, ind- og udlæsningsoperationer, processer samt samtidige webadgange. Dette holder forbruget på den pågældende konto inden for en fastsat ramme og kan beskytte andre konti mod overforbrug. For at kunne analysere årsagen er det afgørende at fastslå, hvilken grænse der rent faktisk nås, i stedet for blot at formode, at der er tale om en generel afmatning af serveren.

At en grænse er nået, er dog ikke en diagnose af problemet i webshoppen. En fejlbehæftet udvidelse, ressourcekrævende databaseforespørgsler, en import eller manglende caching kan udløse belastningen. Højere værdier flytter grænsen, men fjerner ikke årsagen. Kontroller derfor først ressourcedataene og applikationen; først derefter skal du beslutte, om optimering, en anden takst eller ekstra kapacitet er det rette valg.

Hos en forhandler med mange små abonnementer supplerer en Forhandlergrænse de enkelte slutkunders grænser. Underkontiene kan hver især have deres egne værdier, men deres samlede forbrug må ikke overskride den overordnede grænse. Dette forhindrer, at en forhandler på grund af summen af mange aktive kunder bruger flere ressourcer, end der er afsat til hans tilbud.

For PHP bør der for hver kundekonto kun være én overskuelig valggrænseflade, der er gældende. PHP Selector forudsætter CageFS. På cPanel-systemer kan parallel brug med MultiPHP føre til modstridende forventninger, hvis kunder ændrer versioner på forskellige steder. Fastlæg derfor, hvilken grænseflade der skal være synlig, hvilke versioner der skal godkendes, og hvem der administrerer undtagelser.

Det interne indlæg forklarer, hvordan CPU, PMEM, I/O, IOPS, EP og NPROC kan omsættes til konkrete prisprofiler Sådan konfigureres CloudLinux LVE Manager korrekt på shared hosting. De angivne værdier kan ikke automatisk overføres til enhver hardware eller kundestruktur. Lagringsydelse, applikationssammensætning og analysen af faktiske fejl er afgørende for hver enkelt konfiguration.

Isolere flere websteder pr. konto

En enkelt hostingkonto indeholder ofte en hovedside, en webshop, et testmiljø og kundeprojekter. Kontobegrænsningen i sig selv adskiller ikke disse applikationer fra hinanden. CloudLinux-isolater er af producenten generelt betegnet som en betaversion. Funktionen kan oprette en filsystemisolering pr. domæne, så et websteds adgang til filer fra andre websteder på samme konto afgrænses. Den er derfor en mulighed, der bør overvejes for konti med projekter med forskellige risikoniveauer eller ansvarsområder.

Hertil kommer LVE-begrænsninger pr. domæne. De har til formål at begrænse ressourcerne for hvert enkelt websted i stedet for kun for hele kundekontoen. CloudLinux betegner også dette lag udtrykkeligt som en betaversion og nævner det i forbindelse med OS 8 og OS 9. Adskillelse af filsystemer og ressourcebegrænsninger pr. domæne er således to separate niveauer med forskellige forudsætninger.

• CloudLinux angiver som minimum lve-stats3 5.1.0-1 og lve-utils 6.6.40-1 for domæne-LVE-grænser.
• PHP-handleren og kontrolpanelet skal understøtte den pågældende Isolates-konfiguration.
• Det kan være muligt at opdele filsystemet pr. domæne, selvom betingelserne for domænebegrænsninger endnu ikke er opfyldt.

Du skal derfor kontrollere forudsætningerne hver for sig: først om beta-funktionen »Isolates« er dokumenteret med det anvendte panel og den anvendte handler for det ønskede filsystemlag, og derefter pakkeversionerne og beta-status for ressourcegrænserne. For standalone LiteSpeed dokumenterer CloudLinux i øjeblikket kun understøttelse af cPanel. Andre tænkelige kombinationer må ikke udledes heraf som værende ligestillet med hensyn til understøttelse.

Isolates kan indsnævre anvendelsesområdet inden for en konto, men erstatter ikke vedligeholdelsen af applikationerne. Opdaterede plugins, separate adgangsoplysninger, sikkerhedskopier og en passende rettighedsstyring er stadig nødvendige. For en konto med flere uafhængige kundeprojekter kan Domæneisolering efter en dokumenteret kompatibilitetstest vil det alligevel være en mere passende supplerende grænse end udelukkende fælles kontogrænser.

Forberedelse til overgang til OS 9

Overgangen til CloudLinux OS 9 er en planlagt konvertering og ikke en almindelig pakkeopdatering. Den kan påvirke installerede pakker, repository-konfigurationer og integrationen med hostingpanelet. Inden du går i gang, skal du derfor kontrollere det oprindelige operativsystem, CPU-arkitekturen, virtualiseringsmiljøet og den CloudLinux-integration, der understøttes af det pågældende panel.

Fastlæg et vedligeholdelsesvindue, og arbejd med komplette, testede sikkerhedskopier eller konsistente VM-snapshots, som kan gendannes i henhold til den gældende gendannelsesprocedure. Som en del af god administrativ praksis anbefales det desuden at dokumentere pakkekilder, aktive tjenester og afvigende konfigurationer på forhånd. På den måde kan man målrettet spore forskelle efter konverteringen, uden at dokumentationen behandles som en erstatning for en sikkerhedskopi.

Efter systemskiftet bør kontrollen ikke afsluttes, når konverteringsprocessen er gennemført med succes. Kontroller de integrerede repositorier samt panelintegrationen, og behandl yderligere komponenter separat. PHP Selector, X-Ray eller AccelerateWP har deres egne krav til installation, licens og panel; en velfungerende OS-9-basis garanterer ikke automatisk, at disse er tilgængelige.

En væsentlig begrænsning vedrører versionsstien: Konverteringen bevarer hovedversionen fra udgangspunktet. Den forvandler derfor ikke et CentOS 7-system direkte til et CloudLinux OS 9-system. For et sådant generationsskifte skal du bruge en passende migrationsmetode, f.eks. en genopbygning med overførsel af data og konti, i stedet for at betragte konverteringen som en opgradering på tværs af flere hovedversioner.

Kontrol af pakker, kerner og fejl

Efter installation eller opgradering starter systemtjekket med en statusopgørelse. Kontroller først den kørende kerne. CloudLinux OS 9 bruger AlmaLinux-kernen; hvis navnedelen „LVE“ mangler i udskriftsværdien, er det derfor ikke et tegn på, at LVE-funktioner mangler. Kommandoen læser blot den aktuelt kørende kerneversion.

uname -r

Derefter tjekker du de installerede kernepakker. Udskriften viser pakkenavne og versionsnumre eller angiver, hvis en pakke ikke er installeret. Den erstatter hverken en licenskontrol eller en kontrol af, om det anvendte kontrolpanel integrerer den pågældende brugergrænseflade og funktion korrekt.

rpm -q lve lvemanager cagefs lve-utils

Hvis du ønsker at vurdere grænser pr. domæne med CloudLinux Isolates, skal du desuden kontrollere de dokumenterede pakkeversioner herfor. Forespørgslen ændrer ikke nogen konfiguration. Domæne-LVE'er er markeret som beta; en passende pakkeversion bekræfter derfor hverken PHP-handlerens praktiske kompatibilitet eller understøttelsen via panelet.

rpm -q lve-stats3 lve-utils

Til årsagsanalysen er Fejl og ressourcedata giver et mere præcist billede end en generel forhøjelse af alle grænseværdier. Når en konto når en grænse, skal du først fastslå, om det er CPU, RAM, I/O, processer eller samtidige adgangsforespørgsler, der er berørt. Derefter tjekker du applikationen og databaseforespørgslerne, vurderer caching og planlægger ny kapacitet eller en ny prisplan, hvis behovet er vedvarende.

Undgå typiske misforståelser

Det vigtigste at huske på er: CloudLinux OS 9 betegner en generation af operativsystemer, ikke det fulde funktionsomfang af en hostinglicens. CloudLinux OS 10 er en separat hovedgren; oplysninger om OS 9 kan derfor ikke automatisk overføres til OS 10. Shared Pro forbliver desuden en selvstændig udgave med yderligere funktioner såsom PHP X-Ray, Centralized Monitoring og AccelerateWP.

Ligeledes bør en vellykket konvertering ikke betragtes som en samlet godkendelse af alle moduler. Efter migreringen skal panelintegration, pakkestatus, licensomfang og forudsætningerne for hver enkelt tillægsfunktion kontrolleres separat. Dette forhindrer, at kunderne får lovet funktioner, der ganske vist kan indgå i den valgte udgave, men som endnu ikke er konfigureret eller understøttet på den konkrete server.

Når det gælder CloudLinux Isolates, er der behov for særlig omhyggelighed. Producentens dokumentation betegner Isolates generelt som en betaversion. Filsystemadskillelsen mellem hjemmesider inden for en konto og de valgfri LVE-grænser pr. domæne skal desuden ikke sidestilles; også domænegrænserne er udtrykkeligt betegnet som en betaversion. Inden implementering skal PHP-handlere, kontrolpanelet og de dokumenterede pakkekrav kontrolleres.

Også Grænser for ressourcer løser ikke årsagerne i en applikation. I forbindelse med driftsanalysen er det fornuftigt først at analysere fejl og den berørte ressourcetype: CloudLinux kan identificere overskridelser af grænserne for CPU, hukommelse, I/O, IOPS, samtidige forbindelser og processer. Først derefter vurderer du applikationen, databaseforespørgsler, cron-jobs og caching samt spørgsmålet om, hvorvidt der rent faktisk er behov for mere kapacitet.

Kontobegrænsninger er tilstrækkelige til driftsbeslutninger, hvis formålet primært er at adskille kundeprojekter fra hinanden og begrænse belastningsspidser. Forhandlergrænser er desuden velegnede, hvis en forhandler skal begrænse den samlede kapacitet på sine underkonti. Webstedsisolering skal betragtes som en beta-mulighed for flere projekter med forskellig risikoniveau inden for én konto, dog først efter en dokumenteret kompatibilitetstest og med en tydelig angivelse af deres status.