Onderwerp: Centos

Dankjewel voor jouw uitgebreide reactie. Misschien moeten wij ook maar een opnieuw de afweging maken om Cloudlinux te blijven gebruiken of niet.

Interessant ja, hoe zit dat voor eindgebruikers? Hebben die ook een GUI om te zien hoe het gaat/ging ?

@The-BosS Doe je het via systemctl set-property user-<ID>.slice MemoryMax & CPUQuota?

Oorspronkelijk geplaatst door Ramon Fincken

Interessant ja, hoe zit dat voor eindgebruikers? Hebben die ook een GUI om te zien hoe het gaat/ging ?

Nee dat hebben ze niet, maar dat hangt ook weer af van het type klanten die je hebt. Laat ons zeggen dat de bakker op de hoek het zelfs niet eens zou snappen wat die grafieken etc allemaal in houden, dus is hij er ook weinig mee. Waar het bij klanten om draait is "werkt het/werkt het niet" en dan komen ze vanzelf wel aankloppen om te vragen waarom ze constant een error 503 (of andere fourmelding) krijgen. En dan kun je uitleggen waardoor dit komt en is de keuze aan jou of je klant om te upgraden. De meer technische klanten gaan toch meer en meer de kant op van serverless deployment (docker) of vps.

Oorspronkelijk geplaatst door mgielissen

@The-BosS Doe je het via systemctl set-property user-<ID>.slice MemoryMax & CPUQuota?

Klopt met onder andere: CPUShares, CPUQuota, MemoryMax, MemoryLimit, BlockIO... eigenlijk hoe je het zelf wilt, je maakt gebruikt van units of van xMB of combinatie als je bvb een user path hebt wat je echt maar 25MB/s read/write wil geven, maar wel cpu tot 100% mag gebruiken als er niemand anders iets doet en dit dan gelijk verdeeld door unit toe te passen. Maar dan moet je er wel vanuit gaan dat je services onder je user runnen zoals php, nodejs, etc, maar dat zal bij de meeste wel het geval zijn neem ik aan.

Instellingen worden gewoon gezet bij het maken van user door middel van callback functie van controlpanel. Dus dat is wel even manueel een script maken met je instellingen maar dat is ook maar eenmalig net zoals je bvb je instellingen via een control paneel zou moeten doen.

Enige wat je echt mist door geen cloudlinux meer te gebruiken is mysql governor, maar alles hangt natuurlijk van het type klanten af wat je host, heb je veel static websites of websites die ernorm goed cachen of host je veel webshops. Dat is uiteraard een keuze die je zelf moet maken en afwegen, een oplossing zou ook kunnen zijn om verschillend mysql servers te draaien en heavy usage klanten een dedicated mysql toe te wijzen. Maar dat was voor mij persoonlijk dus niet echt een probleem waar ik tegenaan liep.

Oorspronkelijk geplaatst door The-BosS

Hier is uiteindelijke de keuze gemaakt om alles van RHEL/CentOS/Cloudlinux uit te faseren en alles is inmiddels overgezet naar Debian, waar we zelfs al verschillende upgrades van major versions achter de rug hebben (van 10 naar 11 naar 12) zonder enige problemen.

Je geeft aan dat jullie over zijn naar Debian, wat heeft jullie doen besluiten om Debian te kiezen en bijv. geen Ubuntu?

Oorspronkelijk geplaatst door snippydevelopmentcom

Je geeft aan dat jullie over zijn naar Debian, wat heeft jullie doen besluiten om Debian te kiezen en bijv. geen Ubuntu?

Door eerdere slechte ervaringen met ubuntu, in een ver verleden nog gebruik gemaakt van ubuntu met xen en toen kwam er plots een nieuwe versie van ubuntu uit en hadden ze bedacht we switchen gewoon onze hele stack van xen naar kvm, dus je compiled alles gewoon zelf of je switched naar kvm. En een ander geval was dat ze plots beslist hadden om raid drivers ook niet meer te supporten en dan sta je daar ook, kun je ook zelf de kernel gaan compilen of nieuwe hardware kopen. Vandaar de beslissing voor een veel stabielere omgeving die je met debian wel hebt en die je toen der tijd met CentOS ook had.

Naast het feit dat er vroeger ook gebruik gemaakt werd van XCP (XenServer) wat ook op basis van RHEL/CentOS was en ik gewoon alles bij 1 basis OS wilde houden. En sinds er nu gebruik gemaakt wordt van proxmox, wat debian based is, is de keuze dus gemaakt om zoveel mogelijk debian te gebruiken en integrated solutions die gebruik maken van debian, dit maakt het net allemaal wat simpeler in het algemene beheer.

En ook deels door de gebruikte toolset die voornamelijk gesupport is op debian based (of rhel based), want anders had ik zelf voor BSD oplossingen gekozen, maar soms heb je niet veel te kiezen als je afhankelijk bent van derden. En ja in princiepe zou je alles ook draaiend kunnen krijgen onder gentoo of suse of ... maar dan verlies je de support waar je mede voor betaald bij je controlpanel, tools, software, ... en dat wil je dan ook niet.

Hier volgen we de eerder gemaakte keuze voor Debian nog grotendeels. Daarnaast hebben we voor shared hosting ook CloudLinux in de mix. Gelijk met deze wijzigingen hebben we ook wat andere zaken aangepast om toekomstige migraties makkelijker te maken.

Wij hadden destijds de keuze gemaakt om naar Ubuntu te switchen voor de eventuele extra LTS die je vanuit Canonical kan afnemen. Zo was bepaalde software onder Ubuntu beter ondersteunt zoals Acronis en andere controle panelen. Wij hadden ook een aantal CL servers alleen was dit een hell om vanaf te gaan en te switchen naar zonder CL.
CL had veel voordelen maar tegenwoordig worden oudere PHP versies ook ondersteunt en wil je bijv als beheerder ook geen PHP 5.6 of andere EOL versies meer ondersteunen wat een goede ontwikkeling is voor shared omgevingen en als je dat wel nodig heb ga je naar een eigen VPS waarbij de risicos voor 1 specifieke klant is en je hulp krijg op basis van best effort.