PDA

Bekijk Volledige Versie : 1M+ websites op DirectAdmin?



eXtreme Service
19/11/15, 22:13
1 Miljoen websites achter een DirectAdmin server, zou dit lukken? Wij spelen al enige tijd met de vraag of het mogelijk is een platform te bouwen dat webhosting doet op basis van DirectAdmin, maar wel volledig werkt op het Cloud principe. Niet “Cloud” als sales term, maar volgens het "pets vs cattle" principe. Eenvoudig en moeiteloos instances kunnen bijplaatsen waar nodig zodat het oneindig schaalbaar kan zijn en daardoor HA verkrijgen op de software laag.

Met dit in het achterhoofd zijn wij gestart met het bedenken van een proefopstelling. Hoewel DirectAdmin niet ontworpen is voor deze toepassingen, bleek het al snel dat de meeste zaken wel realiseerbaar waren. DirectAdmin heeft namelijk de mogelijkheid om voor alle acties in het panel bepaalde pre en post scripts aan te roepen.

DNS is op zich een van de eenvoudigste onderdelen om schaalbaar te maken. Via een post script ontvangen wij alle updates die er gebeuren aan de DNS instellingen en is het enkel nog een punt van replicatie. Hier werd enkele malen rsync aangeraden wat op zich een mogelijkheid is. Nu leek ons de overhead hiervan iets te groot en lijkt het ons beter om gebruik te maken van een queue (RabbitMQ) om alle slaves een update te bezorgen van de zones.

Web engine zelf is al iets complexer. Echter zit in de huidige versie van CustomBuild van DirectAdmin de optie om Apache in combinatie van Nginx te gebruiken. Dit maakt alles ineens al een stuk schaalbaarder, echter moeten de configs overal gelijk zijn en de configs de Ips van alle web instances bevatten. Daarnaast moet de webdata overal beschikbaar zijn en liefst ook consistent. De configs kunnen eventueel via rsync opgezet worden of via distributed storage als GlusterFS. De voordelen van rsync is dat wanneer 1 host offline gaat, de configs gewoon beschikbaar zijn op de andere. Met als nadeel dat er gemakkelijk race conditions kunnen ontstaan waarbij configs niet op alle plaatsen dezelfde zijn. GlusterFS daarentegen werkt met locking waardoor dit niet het geval is. GlusterFS lijkt hier daardoor de beste optie. Andere opties zijn GFS2 (zelfde voor en nadelen als GlusterFS) en een NFS storage wat weer een SPOF kan zijn voor de cluster.

Voor de clustering van een website zien wij 3 belangrijke punten.
1) De diskruimte van de website zelf. Bij GlusterFS en GFS2 is er de bedenking of de performantie voldoende is. Daarnaast is het niet mogelijk om met quotas te werken bij GlusterFS en dit lijkt ook het geval te zijn bij NFS storage.
2) Session storage: Sessies zijn kleine bestanden die meestal in de tijdelijke storage (/tmp) van een server staan. Dit is wellicht iets dat iedereen weet, echter iets wat vaak niet voldoende bij stil word gestaan. Een reactie als: “we gooien die op de shared storage en dan zijn die sessies overal beschikbaar” lukt voor een klein platform met weinig bezoekers. Echter is zoiets dodelijk voor de performance van bijvoorbeeld een GlusterFS. Deze zijn namelijk nogal gevoelig aan veel kleine files. Alternatieven hier zijn memcached of mijn favoriet, een redis cluster. Probleem hier is dat ik hier enkele bedenkingen heb naar security toe. Deze sessies mogen natuurlijk niet toegankelijk zijn voor andere klanten.
3) MySQL is via Galera eenvoudig HA op te zetten. Echter heeft deze opstelling veel impact op de performantie en kan dit wel de onverwachte showstopper zijn voor zeer groot platform als men spreekt over miljoenen websites.


Mail, HA Directadmin en FTP is momenteel nog out of scope omdat dit geen rechtstreekse impact heeft naar de klanten toe op vlak van bereikbaarheid van hun website. Mail lijkt op zich eenvoudig schaalbaar, al is hier de storage weer de moeilijkste factor.

Vragen en bedenkingen zijn zeer welkom!

bibawa
19/11/15, 22:21
Leuk om mee te spelen, maar waarom zou je dat doen? Het lijkt me juist veel voordelen te hebben om horizontaal te schalen met meerdere DA servers.. Het risico dat er dan iets foutloopt en de impact is dan toch 10-tallen keren kleiner dan met 1 grote machine..

Dat lijkt mij 1 groot nadeel om dit soort setups niet te maken..

Mark17
19/11/15, 22:28
Een tijdje terug heb ik over clustering van DirectAdmin al een topic geopend en later dit jaar kom ik nog met een vervolg in de vorm van een blogpost. Bedenk wel vooraf wat je er mee op wilt lossen, een miljoen websites met DirectAdmin hebben ook wat andere gevolgen.

eXtreme Service
19/11/15, 22:37
bibawa: De legacy manier van denken is inderdaad voor x000 websites x aantal servers. Dit heeft als voordeel om het risico te spreiden, echter heeft dit als gevolg dat er x aantal SPOFs bijkomen. Is dus de balans zoeken tussen x aantal SPOF's en 1 systeem dat welliswaar meer impact kan veroorzaken, maar daardoor ook anders is opgezet om net die impact te vermijden.
Mark17: Interessant. Zijn net naar die gevolgen dat we op zoek zijn. Wat bedoel je precies met wat je ermee wilt oplossen?

BReady
19/11/15, 22:47
Interessant onderwerp. Zelf ook al veel geëxperimenteerd met dit soort oplossingen.

Ik denk dat de security een probleem kan worden. Zoveel websites ondergebracht op één omgeving...


Verzonden vanaf mijn iPhone met behulp van webhostingtalk

eXtreme Service
19/11/15, 23:20
Waarom zou security een probleem vormen? Dit lijkt gelijkaardig aan de reactie bibawa. Security complexiteit is even groot voor 10 als voor 10000 klanten of 1M+ klanten. Aan wat voor security problemen denkt u dan? Defacement / Data leakage / ...

NibeP
19/11/15, 23:38
Ik zit hier met dezelfde wensen en ben mij hier ook erg aan in het verdiepen. Het punt van BReady zit ik ook mee. Ik heb een keer een DirectAdmin server gehad, waarin het een virus bij een klant was gelukt om uit te breken en andere bestanden te infecteren. Ik moet er niet aan denken dat dit gebeurd op één omgeving met zo'n aantal websites.

Om die reden ga ik waarschijnlijk het volgende doen: ik zet voor elke service een cluster op aan servers. Voorbeeld: storage. Ik zet ook een aantal DirectAdmin servers op. De storage op die DirectAdmin servers wordt gekoppeld met het storage cluster. Elke DirectAdmin server krijgt zijn eigen volume. Zo geniet ik van de voordelen van de clusters/redundantie en heb ik alsnog de gebruikers verspreidt over verschillende servers, waarbij de servers van elkaar "geïsoleerd" zijn.

eXtreme Service
20/11/15, 02:09
Peter Bin: Deze uitbraak, dit was wellicht via de webserver zelf (customer scripts)? Is natuurlijk wel mogelijk om meerdere webserver instances te draaien en meerdere verschillende storages te draaien die wel los van elkaar staan. De enige node die toegang moet hebben tot alle storages is dan DirectAdmin en FTP. Zal dan op vlak van Directadmin iets complexer worden (symbolische linken voor elke klant naar hun storage bijvoorbeeld) maar dit heeft dan wel als voordeel dat er iets meer isolatie zit tussen groepen van klanten.

Mark17
20/11/15, 03:16
Welk probleem wil je oplossen met dit clusteren? Bij ons ging het om het verwijderen/verminderen van SPOFs. Dat hebben we gedaan en werkt goed. Daarnaast is updaten naar nieuwere PHP versies een stuk makkelijker geworden voor ons.

Ramon Fincken
20/11/15, 12:37
Ik zit hier met dezelfde wensen en ben mij hier ook erg aan in het verdiepen. Het punt van BReady zit ik ook mee. Ik heb een keer een DirectAdmin server gehad, waarin het een virus bij een klant was gelukt om uit te breken en andere bestanden te infecteren. Ik moet er niet aan denken dat dit gebeurd op één omgeving met zo'n aantal websites.

Om die reden ga ik waarschijnlijk het volgende doen: ik zet voor elke service een cluster op aan servers. Voorbeeld: storage. Ik zet ook een aantal DirectAdmin servers op. De storage op die DirectAdmin servers wordt gekoppeld met het storage cluster. Elke DirectAdmin server krijgt zijn eigen volume. Zo geniet ik van de voordelen van de clusters/redundantie en heb ik alsnog de gebruikers verspreidt over verschillende servers, waarbij de servers van elkaar "geïsoleerd" zijn.

Ging dit toevallig om eenzelfde hostingaccount waar meerdere hoofd-domeinen als pakket in hingen of ging t naar een compleet ander hosting account (andere user dus)

NibeP
20/11/15, 14:36
Peter Bin: Deze uitbraak, dit was wellicht via de webserver zelf (customer scripts)? Is natuurlijk wel mogelijk om meerdere webserver instances te draaien en meerdere verschillende storages te draaien die wel los van elkaar staan. De enige node die toegang moet hebben tot alle storages is dan DirectAdmin en FTP. Zal dan op vlak van Directadmin iets complexer worden (symbolische linken voor elke klant naar hun storage bijvoorbeeld) maar dit heeft dan wel als voordeel dat er iets meer isolatie zit tussen groepen van klanten.

Dit was een bestand wat inderdaad via de webserver werd benaderd. Naast DirectAdmin en FTP heeft ook de webserver toegang nodig tot die storage (anders is er natuurlijk niet zoveel om te serveren).


Ging dit toevallig om eenzelfde hostingaccount waar meerdere hoofd-domeinen als pakket in hingen of ging t naar een compleet ander hosting account (andere user dus)
Dit verspreidde zich naar de gehele server. Het virus wijzigde permissies in de server en verwijderde bestanden die nodig waren om het systeem draaiende te houden.

Het lijkt zo op een bug/lek of een permissieprobleem, maar aan de hand van een full backup voor het virus, hebben wij geen problemen gevonden.

Ookal staan permissies etc goed ingesteld, het lijkt mij toch fijn om nog aparte volumes aan te maken, om het verspreiden van problemen te voorkomen. Menselijke fouten zijn er altijd nog.

Ramon Fincken
20/11/15, 15:22
draaide je users wel als eigen user ipv iets als www-data / apache ?
maargoed offtopic ;)

NibeP
20/11/15, 15:54
draaide je users wel als eigen user ipv iets als www-data / apache ?
maargoed offtopic ;)

Ja, als eigen user. Was erg vreemd.

Zal inderdaad weer on topic gaan :)

eXtreme Service
20/11/15, 16:59
Dus als ik het goed begrijp is er een noodzaak aan wat data segregatie tussen de hosts zelf. Dit kan door middel van verschillende webhostingclusters slechts toegang te geven tot bepaalde storages. Op de DirectAdmin host moeten deze inderdaad wel allemaal beschikbaar zijn, ware het niet dat het security risico daar lager is dan op de webservers.
Een ander alternatief kan zijn om voor de webserver instances CloudLinux te gebruiken in combinatie met CageFS? Iemand daar ervaring mee?

systemdeveloper
20/11/15, 22:14
Dus je wilt straks 1 DA instance de virtual hosts, mailboxen, databases e.d. van 1 miljoen websites laten beheren?

Heb je al eens getest hoe lang je webservers over een reload gaan doen of dat DA zijn tally wel overleefd (ervan uitgaande dat ie binnen en dag klaar is natuurlijk)? Vergeet niet dat je met 1M sites al 4GB diskspace nodig hebt per webserver om alleen al de virtual host configs te laden.
Dat levert je resource vretende apache/nginx instances op natuurlijk.

Plus Da heeft vaak al redelijk moeite met enkele duizenden 'whatever' in een lijstje tonen dus met een miljoen... sterkte.

Los daarvan wil je waarschijnlijk sowieso een fysiek onderscheid maken tussen bussiness klanten, budget klanten, sla klanten, de 'ddos magneet sites' etc.

Zelfs als dat technisch allemaal zou gaan werken, dan lijkt me dat een extreeeeeeem slecht plan om ook te doen.

eXtreme Service
21/11/15, 00:39
Niemand zegt dat je webserver alle vhost configs moet inladen. Je kan bijvoorbeeld per website maximaal 3 webinstances/servers toewijzen en wanneer je dan spreekt over in totaal bijvoorbeeld 12 webserver instances, dan hoef je maar 1/4 van alle configs in te laden. Dit kan je natuurlijk verder schalen zoveel je wil. Indien nodig kan je zelfs de vhost configs laten cachen in memory.
Weet niet in hoeverre die tally schaalbaar is want heb nog niet gekeken naar dat component maar is wel mogelijk om tally te draaien voor een lijst van gebruikers of gebruikers van een bepaalde reseller. Dus misschien is dat ook gewoon op een manier schaalbaar te krijgen. Op zich mag de DA server grotendeels van de dag bezig zijn met de tally. Het principe is dat alle andere taken (DNS, web, mail, FTP enz) op een andere plaats draait.

Onderscheid maken tussen verschillende klanten kan nog steeds door deze meer resources/instances toe te wijzen ten opzichte van de andere. Ik heb gezien dat het ook mogelijk is om meerdere home folders te gebruiken. Dit lost ook weer een eventueel probleem met schaalbaarheid op van de storage.

Het is voornamelijk een denk oefening. Wil niet zeggen dat het heel verstandig is om blindelings voor zo een opstelling te kiezen. Maar zo een opstelling kan weldegelijk zijn voordelen hebben. Al is het maar om niet een hoop afzonderlijke servers te hebben waarbij de helft idle draait en de andere helft heel de tijd last heeft van te hoge loads en downtimes te verlagen tot het minimum.

systemdeveloper
21/11/15, 02:21
Ja, ik snap wel wat je wilt. Ik denk dat iedereen dat wel wilt, maar in de praktijk wil je dat echt niet :)

Ik wil je die vhost in memory wel eens zien cachen in ram. Apache doet dat sowieso al, dus extra lijkt me gewoon een verspilling van resources.

Wat je wilt is als eerste een clustered filesystem en daar boven x websites met een hiërarchie van loadbalancers.
Dat is primair voldoende om zoveel websites als je wilt te schalen.

Indien je databases wilt kunnen schalen komt er iets meer bij kijken, maar ook dat is relatief eenvoudig op te lossen.

Een hiërarchie van loadbalancers geeft je de mogelijkheid om eventueel automatisch websites rond te moven over je pools van webservers om zodoende de load onder controle te houden. Door je webservers virtueel te houden kun je bij wijze van spreken 10 web-vpssen per server kwijt en zodra iets uit zijn resources loopt kun je als eerste stap die vpssen naar extra hardware moven. Zodra een website meerdere webservers vereist hoef je maar bij 1 loadbalancer een config aan te passen en te reloaden en je bent klaar.

Dingen zoals mail, ftp etc is dan het minste van je problemen. Dat kun je via zoveel servers regelen als je nodig hebt.

Maar ik blijf mijn twijfels hebben over 1M+ sites in directadmin. Ik ben wel nieuwsgierig hoe da om gaat met 25000 pagina's met users/domeinen dus zodra je dat voor elkaar hebt, ben ik de eerste die je een krat bier stuurt :)
Och wat... zodra ik een miljoen websites heb draaien geef ik iedereen op dit forum een krat bier :)

eXtreme Service
21/11/15, 20:23
Apache doet de caching naar memory bij de reload zelf, niet ervoor. Vandaar dat de reload wat tijd kan kosten omdat dit vanop de hardeschijf moet komen. Verder hoeft dit enkel read caching te zijn om zeker te zijn dat je de wijzigingen naar de files niet verliest. Snelheid van het reloaden zal dan een factor 10 sneller zijn.

Heb wat liggen spelen met DNS en de webinstances vandaag. DNS updates verpreiden doet hij nu via een RabbitMQ server op de DirectAdmin node. Elke DNS server heeft zo zijn queue, daardoor is het ook makkelijk te volgen welke DNS servers de updates aanvaarden en welke niet. Dit gaat stukken sneller dan via files en is lekker eenvoudig. De webinstances zijn iets moeilijker omdat het post script voor httpd rewrites ook ineens een herstart en dit had leuker geweest na het uitvoeren van het post script. Nu is dit enkel een probleem als de Directadmin node ook als webinstances zijn werk doet dus laat ik dit nog even links liggen. Vhost config files lopen nu via een rsync maar de kans is groot dat ik dit ook vervang door een RabbitMQ connectie.

Nu vroeg ik mij af of er interesse was bij jullie om deze proefopstelling eens grondig te testen wanneer hij klaar is? Ik wil gerust proberen om er 1M accounts in te steken om te zien wat dat geeft :-)

DutchTSE
22/11/15, 09:41
De DNS los trekken van DA kan met powerdns vrij eenvoudig. Je hebt dan 1 DNS cluster waar al je DA servers (in jouw geval 1?) naar toe syncen.

eXtreme Service
22/11/15, 14:04
Inderdaad, echter ben ik nooit fan geweest van de standaard replicatie. Zo waren er cleanup scripts nodig voor het verwijderen van domeinen en zo zijn er nog een aantal beperkingen. Op deze manier is het makkelijker op te volgen en te onderhouden. In het kader van "Keep it simple :)"