Onderwerp: Hoe je eigen cluster te maken op basis van DirectAdmin

De komende periode zal ik in delen de opzet van ons cluster benoemen en bijzonderheden aangeven waar op te letten als je een vergelijkbare omgeving op wilt zetten. Daarnaast zal ik ook vragen beantwoorden die hier over kunnen ontstaan. Mocht je het zelf ook op willen zetten reken dan op meerdere servers, grote capaciteit voor pieken en makkelijk schalen indien nodig/gewenst. Zodra het cluster groter van omvang is wordt het ook mogelijk delen uit te zetten als het rustiger is (kan handig zijn in bepaalde gevallen).

In deze eerste post ga ik een globale beschrijving van de opzet geven. Alle systemen draaien Debian (maar een andere Linux distributie naar eigen voorkeur kan natuurlijk ook).

De volgende functies hebben wij gekozen voor de servers:
- Loadbalancers (met Keepalived/LVS), 1 netwerk interface vereist
- Caching (kan weggelaten worden, op basis van Varnish en Nginx)
- Webservers (Apache httpd, PHP)
- Database servers (MySQL master-master, automatische failover moeten we nog toe gaan voegen. Gebruikt geen NFS)
- Rest (DirectAdmin/mail/ftp/NFS, momenteel nog de enige SPOF. NFS wil ik op termijn overbodig maken als ik hier een goede optie voor heb gevonden)

Waarom deze opsplitsing? Uit ervaring weten we dat als er ergens problemen ontstaan en extra capaciteit gewenst is dit altijd gaat om webservers of database servers bij ons, het wordt veroorzaakt door veel bezoekers/slechte code. Om dit op te kunnen vangen hebben we deze opzet gemaakt en was het met name van belang om makkelijk webservers er bij in te kunnen zetten en om waar nodig extra database servers neer te kunnen zetten (dan kunnen bepaalde klanten andere database servers gebruiken). Een laatste voordeel van deze opzet is dat onderhoud aan de webservers/loadbalancers/caching overdag uitgevoerd kan worden, dit wordt automatisch door een andere server overgenomen.

Bepaalde design keuzes zal ik de komende tijd nader toelichten, net als waar op te letten. De scripts die we hiervoor geschreven hebben zal ik niet delen, hiervoor zal het beheer van de omgeving waar dit wenselijk is aan ons uitbesteed moeten worden.

Ah leuk dit ga ik even volgen. Wij doen alles qua hosting op een HA VPS cluster en doen dit op een ander niveau dan jij van plan bent. Echter is onze manier stabiel, gemakkelijk en behoorlijk betrouwbaar maar is het op jouw manier mogelijk nog veel groter te schalen met 1 omgeving.

Zelf hebben we hier wel eens naar gekeken en zeker omdat we vrij veel met clusters werken ook ivm wat grote websites. Alleen is dit altijd exclusief Directadmin wat sommige best graag hebben.

Alleen wat jij ook aangeeft de SPOF bij directadmin bevalt me nooit zo erg. Is het niet beter om te gaan kijken voor een alternatief voor Directadmin wat wel een beetje te schalen is?

In ieder geval enorm leuk dat je ons een kijkje gaat geven in de ontwikkelingen bij jullie.

Leuk. Hebben we ook al jaren op die manier draaien. Ideaal om te schalen

Oorspronkelijk geplaatst door golden

Alleen wat jij ook aangeeft de SPOF bij directadmin bevalt me nooit zo erg. Is het niet beter om te gaan kijken voor een alternatief voor Directadmin wat wel een beetje te schalen is?

In werkelijkheid wordt de SPOF veroorzaakt doordat ik nog geen goed filesystem heb gevonden dat stabiel draait in tests terwijl het vanaf meerdere locaties tegelijk gemount is. Onze centrale storage (volledig HA) ondersteund helaas geen NFS en daardoor moet ik daarvoor een laag er tussen zetten. DirectAdmin zelf is wel dubbel uit te voeren incl. dat alles aan beide kanten er hetzelfde uit ziet voor de gebruikers maakt het dan niet uit waar ze inloggen. Hiervoor zijn er wel een paar eisen (zelfde DirectAdmin versie/besturingssysteem), de rest kan met de juiste mappen via een gedeeld bestandssysteem beschikbaar maken.

Als iemand een goede en stabiele oplossing weet zonder hardware te vervangen (onze storage servers staan er nog niet zo lang) om met een bestandssysteem te werken dat op meerdere systemen te mounten is (als blockdevice) dan verneem ik het graag en ga ik daar ook zeker mee testen en als het stabiel is zal ik dat ook mee nemen in de volgende posts.

Het geheel is opgezet op VPSen, voor de uitleg (om het simpel te houden) ga ik uit van losse servers in de beschrijving. De extra virtualisatie laag maakt voor de beschrijving relatief weinig verschil.

Voor je servers kunt inrichten die ook beschikbaar zijn voor clients is het handig om het netwerk te regelen (ook makkelijk bij de installatie). Hiervoor is gekozen om elke server met 2 kabels te verbinden met switches, daarnaast gaat het interne verkeer over een ander VLAN dan het verkeer naar de buitenwereld ("het internet"/"externe verkeer"). We hebben voor het interne VLAN IPs gebruikt uit RFC1918 en hier is IPv6 niet beschikbaar. Het verkeer naar het internet kan wel gebruik maken van IPv6. De IPs en VLANs die ik hier noem komen niet overeen met onze werkelijke setup, hieronder een beschrijving van wat gebruikt wordt.

Externe IP adressen:
198.51.100.0/24 (RFC5737)
203.0.113.0/24 (RFC5737)
2001:DB8::/32 (RFC3849)

Interne IP adressen:
192.168.0.0/16 (RFC1918)

Domeinnamen (RFC2606):
example.com
example.net
example.org

Extern VLAN:
VLAN 1

Intern VLAN (een verdere opsplitsing is natuurlijk mogelijk):
VLAN 10

De basis installatie (incl. SSH) van Debian ga ik hier verder niet beschrijven, als je niet weet hoe dat moet dan adviseer ik om niet verder te lezen. Van enige basis kennis mbt Linux ga ik wel uit. eth0 wordt gebruikt voor extern verkeer en eth1 voor intern verkeer. In de voorbeelden/verwijzingen noem ik mogelijk Debian specifieke opties voor de installatie (apt-get) of bestandslocaties, bij een andere Linux distributie zal gekeken moeten worden waar het daar staat.

Hieronder volgt een overzicht van de servers met IP adressen per interface. Ik ga er niet vanuit dat onder de korte naam van de server deze vanaf een andere server bereikbaar is, hier kom ik later nog op terug zodra ik de webservers uitgebreider beschrijf (de overige servers hoeven elkaar enkel op IP te kunnen vinden in bepaalde gevallen).
lb01:
eth0: 198.51.100.10 & 2001:DB8::10
eth1: 192.168.10.10
lb02:
eth0: 198.51.100.11 & 2001:DB8::11
eth1: 192.168.10.11
cache01:
eth0: 198.51.100.20 & 2001:DB8::20
eth1: 192.168.10.20
cache02:
eth0: 198.51.100.21 & 2001:DB8::21
eth1: 192.168.10.21
web01:
eth0: 198.51.100.30 & 2001:DB8::30
eth1: 192.168.10.30
web02:
eth0: 198.51.100.31 & 2001:DB8::31
eth1: 192.168.10.31
mysql01:
eth0: 198.51.100.40 & 2001:DB8::40
eth1: 192.168.10.40
mysql02:
eth0: 198.51.100.41 & 2001:DB8::41
eth1: 192.168.10.41
da01:
eth0: 198.51.100.50 & 2001:DB8::50
eth1: 192.168.10.50

Te gebruiken door websites:
198.51.100.60-198.51.100.69
2011:db8::60-2001:db8::69

De IPs die door websites gebruikt kunnen worden moeten toegevoegd worden aan de loopback interface (lo), in dit voorbeeld ga ik uit van het instellen zoals hieronder (in /etc/network/interfaces, de overige IPs zijn op een vergelijkbare wijze toegevoegd).
auto lo:60
iface lo:60 inet static
address 198.51.100.60
netmask 255.255.255.255
up ip -6 addr add 2011:db8::60/128 dev lo

Dit moet zo gedaan worden op cache01, cache02, web01, web02 en da01. De reden hiervan is dat deze "virtuele IPs" later gebruikt worden voor de sites en met verschillende poorten hiernaar verwijzen, dit gecombineerd met het feit dat ik geen NAT wil doen op de loadbalancers (anders moet alles op de loadbalancers na enkel interne IPs hebben).

Ik ga dit even volgen. Altijd leuk om de setup te zien en hoe collega's bepaalde dingen inregelen.

Leuk mark17. Ik ga dit zeker volgen. Altijd leuk hoe anderen hun omgeving opzetten.

Dit zijn nou interessante topics, ik volg hem ook!

Schatjes .. reply nu gewoon even als je echt iets bij wil dragen. En niet "ik volg ook".
Als je wat fijn vindt .. klik dan op de like knop.

Op de loadbalancers (lb01 en lb02) hebben we Keepalived v1.2.2 geïnstalleerd (met apt-get). Het instellen hiervan is niet echt heel moeilijk, voorbeelden van delen van keepalived.conf staan hieronder. Op basis van deze voorbeelden zal de rest redelijk in te vullen zijn verwacht ik.

Verzin een naam voor de configuratie en definieer deze.

Code:

global_defs {
        lvs_id LVS_CLUSTER_01
}

Maak groepen van IPs die allemaal tegelijk master/slave moeten zijn.

Code:

vrrp_sync_group VG1 {
        group {
                CL01_VI_WAN
                CL01_VI_LAN
        }
}

Voeg een virtueel IP (VIP) toe (later configureer ik de acties voor de poorten). Op de andere server is de state en priority anders (zie voor details de Keepalived documentatie). Voor de andere vrrp instellingen gebruik ik andere namen en een andere virtual_router_id, voor je hiermee begint adviseer ik de documentatie van Keepalived even te lezen.

Code:

vrrp_instance CL01_VI_WAN {
        state MASTER
        interface eth0
        virtual_router_id 101
        priority 100
        advert_int 1
        authentication {
                auth_type PASS
                auth_pass verzinMaarEenWachtwoord
        }
        virtual_ipaddress {
                198.51.100.60
                198.51.100.61
        }
}

Voor poort 80 heb ik per IP een blok dat er uit ziet als volgt, voor andere poorten heb ik een vergelijkbare configuratie.

Code:

virtual_server 198.51.100.60 80 {
        delay_loop 6
        lb_algo rr
        lb_kind DR
        persistence_timeout 3600
        protocol TCP

        real_server 198.51.100.20 80 {
                weight 100
                TCP_CHECK {
                        connect_timeout 3
                        connect_port 80
                }
        }
        real_server 198.51.100.21 80 {
                weight 100
                TCP_CHECK {
                        connect_timeout 3
                        connect_port 80
                }
        }
}

Poorten die via de loadbalancer gaan:
- 25
- 80
- 85 (verwijst naar de webservers, Apache draait op poort 85 en zo kunnen klanten hun site zonder cache benaderen. Dit kan soms enorm handig zijn)
- 110
- 143
- 443
- 587
- 993
- 995
- 2222

SSH en FTP gaan niet via de loadbalancers. FTP werkt niet echt lekker via de loadbalancers (hier heb ik nog geen oplossing voor gevonden helaas, gebruikers verbinden rechtstreeks met da01 als ze naar ftp.domein gaan). SSH toegang krijgen klanten bij ons niet, anders hadden we hier mogelijk wel iets mee gedaan.

Commentaar op onze opstelling is overigens ook welkom. Een goede discussie waarom bepaalde keuzes gemaakt zijn kan juist zeer verhelderend werken lijkt mij.

Op cache01 en cache02 draaien Varnish (luistert op poort 80) en Nginx (luistert op poort 443). Nginx levert voor sites de SSL laag, wij stellen dit verder handmatig in per klant met SSL (we moeten dan toch een IP reserveren voor deze klant). Nginx stuur alle verzoeken (na het afhandelen van het SSL deel) door naar Varnish. Varnish haalt via een roundrobin achtige instelling vervolgens van de webservers het verkeer (op poort 85 luisteren de webservers).

Poort 80 en 443 worden door de loadbalancers verwezen naar cache01 en cache02.

===================================

mysql01 en mysql02 draaien in een master-master opstelling. Er is hier nog geen automatische failover ingesteld (tips? Dit wil ik nog wel in gaan stellen), afhankelijk van de webserver is welke MySQL server gebruikt wordt. Hier is een script toegevoegd om aan elke MySQL gebruiker die rechten heeft om vanaf localhost (de DirectAdmin standaard) te verbinden rechten worden gegeven om vanaf 192.168.10.% te verbinden. Verder is dit een vrij simpele opzet en overweeg ik om nog een keer een plugin voor DirectAdmin te maken om meerdere MySQL servers te gaan ondersteunen. Mocht hier interesse in zijn dan verneem ik dat graag.

De volgende keer ga ik in op een combinatie van web01, web02 en da01. Dit deel is relatief gezien het lastigste.

Waarvoor gebruik je varnish ? Om te cachen of puur om te routeren van het http verkeer ?

Oorspronkelijk geplaatst door Mikey

Waarvoor gebruik je varnish ? Om te cachen of puur om te routeren van het http verkeer ?

Volgens mij ook voor cachen. Hij zei namelijk dat hij port 85 door laat verwijzen naar apache zodat ze eventueel cache kunnen omzeilen wat soms handig kan zijn.

Oorspronkelijk geplaatst door golden

Volgens mij ook voor cachen. Hij zei namelijk dat hij port 85 door laat verwijzen naar apache zodat ze eventueel cache kunnen omzeilen wat soms handig kan zijn.

U heeft gelijk

Wat ik mij dan afvraag, geef je klanten de mogelijkheid om objects uit de varnish cache te flushen ? Of puur op verlopen van cache ?

Oorspronkelijk geplaatst door Mikey

U heeft gelijk

Wat ik mij dan afvraag, geef je klanten de mogelijkheid om objects uit de varnish cache te flushen ? Of puur op verlopen van cache ?

Zeg maar "je" ik ben nog niet zo oud .

Eerlijk gezegd verwacht ik niet (enkel mark17 kan bevestigen) dat dat mogelijk gaat zijn. Daarom is in zekere zin ook die :85 om even changes te checken. Wel denk ik dat ze het met bepaalde headers kunnen forcen. Ook is nog maar de vraag of cache altijd actief is of enkel bij drukke websites.