Bekijk Volledige Versie : MySQL op aparte server
Je ziet regelmatig bedrijven die één grote MySQL server willen draaien voor hun shared hosting klanten, wat is volgens jullie hier nu het voordeel van ten opzichte van Localhost ?
Ik zal beginnen met wat voorbeelden:
- Wanneer de Load van één klant op de MySQL server zo hoog wordt heeft iedereen er last van. Een limit kan erop, maar daar maak je de klant ook niet blij mee uiteraard.
- Wanneer de MySQL-Server gehacked wordt zijn al je klanten offline, zouden deze lokaal gedraaid hebben dan uiteraard alleen de server die het doelwit was.
- Upgraden naar een nieuwe MySQL server lijkt me een ramp, wanneer je dit lokaal doet trekt je de HD's eruit plaats de ze in een nieuwe server en de boel draait weer. Sowiezo is moven naar een andere box makkelijker, localhost is localhost dus de klant hoeft niets te veranderen.
Ik weet er vast nog wel meer, maar ik geef het stokje even door ;)
superior-is
24/02/06, 15:06
voordeel:
upgraden is makkelijker, want je hoeft niet alle servers af, maar enkel de mysql servers
nadeel:
geen risico spreiding, wanneer alles lokaal draait
voordeel:
upgraden is makkelijker, want je hoeft niet alle servers af, maar enkel de mysql servers
nadeel:
geen risico spreiding, wanneer alles lokaal draait
Volgens mij is je nadeel eerder een voordeel ;)
superior-is
24/02/06, 15:16
Euh elk nadeel hep zijn voordeel. :)
Mja kies dan toch liever voor Lokaal draaien. Maarja zoals al eerder iemand opmerkte, elk voordeel heeft zijn nadeel.
crazycoder
24/02/06, 15:40
- Upgraden naar een nieuwe MySQL server lijkt me een ramp, wanneer je dit lokaal doet trekt je de HD's eruit plaats de ze in een nieuwe server en de boel draait weer. Sowiezo is moven naar een andere box makkelijker, localhost is localhost dus de klant hoeft niets te veranderen.
Ik weet er vast nog wel meer, maar ik geef het stokje even door ;)
mysqldoos.jouwdomeinnaam.tld is dat ook vanaf iedere server.
Zie niet echt een verschil.
mysqldoos.jouwdomeinnaam.tld is dat ook vanaf iedere server.
Zie niet echt een verschil.
Wanneer je wil moven van box naar box zal je toch box1 en box2 moeten gebruiken.
Dezelfde hostname gebruiken gaat niet echt ;)
Heb er geen ervaring mee, je kan niet werken in een cluster met DirectAdmin zover ik weet
Trekt dat niet juist extra load doordat je de mysql op een andere server moet aanspreken ipv lokaal?
Trekt dat niet juist extra load doordat je de mysql op een andere server moet aanspreken ipv lokaal?
Ik heb hier ook een dergelijk gevoel over. Ik zou het eens moeten benchmarken, wellicht heeft iemand dat al gedaan :)
Ryan Kalkhoven
24/02/06, 16:07
Ik denk eigenlijk dat dit zonder een situatie schets moeilijk te bepalen is.
Als je maar 10 domeintjes host met een paar bezoekersmaakt het niets uit.
Gaat het over grotere aantallen websites of om vele bezoekers dan zit je al snel aan clusters etc en servers met dedicated applicaties.
Dus naar mijn idee is er zonder achtergrond informatie niets zinnigs over te zeggen.
Ik denk eigenlijk dat dit zonder een situatie schets moeilijk te bepalen is.
Als je maar 10 domeintjes host met een paar bezoekersmaakt het niets uit.
Gaat het over grotere aantallen websites of om vele bezoekers dan zit je al snel aan clusters etc en servers met dedicated applicaties.
Dus naar mijn idee is er zonder achtergrond informatie niets zinnigs over te zeggen.
Ik denk juist van niet dat je dan aan dedicated applicaties zit wanneer je naar MySQL kijkt, dit wil je naar mijn inziens gewoon niet.
Mail en dergelijk wel uiteraard.
Ryan Kalkhoven
24/02/06, 16:13
Kun je mij uitleggen waarom je dat juist voor mysql specifiek niet zou willen?
Ik heb nooit zoveel getest etc met mysql om te geven wat nu wel of niet beter zou zijn. Bovenstande uitspraak doe ik op basis van andere applicaties zoals mail en andere db applicaties.
Ik zou een centrale mysql server opzetten. Die kan je dan makkelijk failover inrichten voor het geval er problemen optreden.
Wido die weet hier vast meer van dit doen ze volgens mij ook bij pcextreme.nl dacht ik..
Kun je mij uitleggen waarom je dat juist voor mysql specifiek niet zou willen?
Ik heb nooit zoveel getest etc met mysql om te geven wat nu wel of niet beter zou zijn. Bovenstande uitspraak doe ik op basis van andere applicaties zoals mail en andere db applicaties.
Omdat het dusdanig veel queries kan opleveren dat het je performance van je netwerk kan beïnvloeden ben ik bang.
Wanneer je maar één applicatie als "De Telefoongids" zou draaien doe je alles dedicated, je weet toch wat er gebeurt. Wanneer je dit niet weet wil je dingen uitsluiten, dus niet iedereen op één box.
Tevens gaan alle MySQL applicaties plat wanneer je box down is, dit is bij Localhost beperkt tot die ene machine.
Wido die weet hier vast meer van dit doen ze volgens mij ook bij pcextreme.nl dacht ik..
Het is niet specifiek PcExtreme die dit alleen doet. Het gaat erom waarom je het doet.
De meeste personen denken dat je bij dedicated boxen juist veel problemen uitsluit, dat is bij MySQL juist niet het geval heb ik het idee.
Wij maken heel veel gebruik van losse MySQL servers, waarom?
Wij hebben redelijke grote webhosting clusters (5 - 10 webservers) en dan is het niet meer handig om je MySQL lokaal te draaien, je moet dan zorgen voor replicatie e.d. en dan heb je alleen read-only op bepaalde punten.
Upgraden naar een nieuwe versie is een stuk makkelijker en je kan een server samenstellen die helemaal gericht is op een bepaalde taak.
Zo kan je in je webservers simpele S-ATA disks stoppen en in je MySQL server kan je snelle RAID-Controllers plaatsen met ook goede disks.
Als je geen cluster draait, dan is het denk ik niet veel handiger, tenzij je erg veel SQL hebt wat qua performance niet samen kan met een webserver.
Vanaf MySQL 5.1 kan je MySQL ook goed clusteren en dan ben je van het SPOF af.
Je kan dan op alle nodes reads en writes doen, dat is natuurlijk helemaal super.
In /etc/hosts hebben wij gewoon een pointer gemaakt van db.pcextreme.nl naar het IP van de database-server.
Ryan Kalkhoven
24/02/06, 16:25
Maar ik snap niet wat je bedoelt met "tenkoste van je netwerk".
Als ik een aparte server draai voor mysql dan wordt dat op een private netwerk gedaan. Mysql bied je niet aan alle internet gebruikers aan maar alleen aan je klanten dus publiek hoeft die niet te zijn.
Mail is een publieke service dus die moet direct aan het internet mysql kan op een private lan net als bijv. backupservers. Ik mag aannemen dat je ook backups via een private lan draait en niet over je internet kant.
Kortom het internet verkeer zal niet worden vervuilt met verkeer van en naar je mysql server.
En net als wat Wido zegt is dat je voor een dedicated machine heel goed met je hardware in kan spelen op de performance van de service die je draait.
Dus ik denk dat het wel degelijk voordelen heeft.
Maar ik ben van mening dat het allemaal afhangt van de schaal waarop het gebeurd.
@Wido; Zit een kern van waarheid in, echter zie ik geen voordeel in remote in jouw sitatie (waar ik zelf ook zit). Je MySQL repliceren is leuk, maar wanneer de webserver dood gaat en de website daar lokaal op draaide (dus niet ge-loadbalanced) heeft het nog weinig nut.
@Ryan: Je krijgt ontzettend veel intern verkeer dat gewoon niet nodig is. Zolang de box het zelf kan trekken ben je altijd sneller met localhost en meer save qua werking globaal gezien en tevens lokaal.
Wij hebben MySQL ook aan een intern netwerk hangen, daar heeft verder niemand toegang tot, dit is volledig gigabit voor de meest lage latency.
De backups gaan zelfs over een ander netwerk om er voor te zorgen dat als er een gigabit over het backupnetwerk gaat dat dit geen invloed heeft op de performance van het interne netwerk.
Wido, dat is ook een optie uiteraard. Ligt er even aan of je het wel extern aan zou willen bieden.
Ieder voordeel heeft zo zijn nadeel en andersom. Ligt een beetje aan de situatie.
sp-services
24/02/06, 17:12
DA kan wel werken met een apparte MYSQL
Keenondots
24/02/06, 17:16
Vanaf MySQL 5.1 kan je MySQL ook goed clusteren en dan ben je van het SPOF af.
Welke nieuwe features van 5.1 maken dat (beter) mogelijk? In 5.0 zit ook ndb?
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-overview.html
In /etc/hosts hebben wij gewoon een pointer gemaakt van db.pcextreme.nl naar het IP van de database-server.
Dat is erg verstandig, zo heb je geen DNS overhead.
crazycoder
24/02/06, 17:29
Wanneer je wil moven van box naar box zal je toch box1 en box2 moeten gebruiken.
Dezelfde hostname gebruiken gaat niet echt ;)
Als je 1 mysql server voor meerdere servers draai dan heeft ie voor zover mij bekend altijd dezelfde naam.
Ik ga dan uit van een dedicated mysql server....
Ryan Kalkhoven
24/02/06, 17:49
@Ryan: Je krijgt ontzettend veel intern verkeer dat gewoon niet nodig is. Zolang de box het zelf kan trekken ben je altijd sneller met localhost en meer save qua werking globaal gezien en tevens lokaal.
Maar is dit niet wat ik zeg dan? Zolang het om kleine belasting gaat doe je het op 1 en dezelfde machine en zodra de belasting te groot wordt voor dezelfde machine dan ga je het splitsen.
Kortom afhankelijk van de schaal waarover het gaat.
(Eindelijk weer eens een goede discussie ipv die onzin van de laatste tijd.)
Ik ben alleen nog benieuwd naar eventueel wat cijfers... Misschien dat Wido wat inzicht kan geven van op welk moment jullie zijn overgestapt naar losse servers in clustervorm etc.??
Keenondots
24/02/06, 17:51
Ik ben alleen nog benieuwd naar eventueel wat cijfers... Misschien dat Wido wat inzicht kan geven van op welk moment jullie zijn overgestapt naar losse servers in clustervorm etc.??
Het lijkt me voor de hand liggen dat je dat doet zodra de load Apache+MySQL richting de 1.00 gaat. Dan koppel je MySQL los en ga je er losse webservers aanhangen. De volgende stap is MySQL clusteren en je (read) queries verdelen.
Maar daar is natuurlijk geen algemeen iets als #queries/hour voor te geven.
DA kan wel werken met een apparte MYSQL
Hoe dan? Wèl dat de klant gewoon alles kan aanpassen in DirectAdmin aan mySQL
Ryan Kalkhoven
24/02/06, 18:02
Het lijkt me voor de hand liggen dat je dat doet zodra de load Apache+MySQL richting de 1.00 gaat. Dan koppel je MySQL los en ga je er losse webservers aanhangen. De volgende stap is MySQL clusteren en je (read) queries verdelen.
Maar daar is natuurlijk geen algemeen iets als #queries/hour voor te geven.
Het is inderdaad een goede conclusie dat bij een x-load je dat gaat toepassen, maar waar ik dan nieuwsgierig naar ben is:
Stel je hebt 0.4 load aan mysql en 0.6 aan apache. Wat gebeurd er dan zodra je dit extern plaatst. Dan schat ik in dat je niet met 0.4 op je totale load terug zakt op die machine, maar misschien 0.3 omdat er 0.1 extra nodig is voor apache of je eth..... In die hoek zat ik even te denken.
(Volgens mij doelde de TS daar ook op alleen heb ik het idee dat hij verwacht dat je er niet zoveel mee opschiet als in mijn voorbeeld).
Keenondots
24/02/06, 18:11
Stel je hebt 0.4 load aan mysql en 0.6 aan apache. Wat gebeurd er dan zodra je dit extern plaatst. Dan schat ik in dat je niet met 0.4 op je totale load terug zakt op die machine, maar misschien 0.3 omdat er 0.1 extra nodig is voor apache of je eth..... In die hoek zat ik even te denken.
Dat lijkt me geen stof om calculaties tot achter de komma op los te laten zonder de applicatie in kwestie te kennen. Dus in een Shared Hosting omgeving is daar al helemaal weinig over te zeggen. Apache krijgt wel meer geheugen ter beschikking op een node als MySQL er niet meer op draait, daardoor kan hij requests wellicht sneller (meer tegelijk) verwerken, waardoor de load daalt. De latency van een enkele query kan dalen omdat het niet over je lo interface gaat, maar over eth0 (of eth1, of bond0, you get the point).
Daarnaast is load ook maar een getal. Als je load < #CPU's is er weinig winst te behalen. Je koopt natuurlijk geen Dual Xeon om een load van 0.01 te draaien*.
Dit soort zaken stel je m.i. vooral proefondervindelijk vast (live in een Shared Hosting omgeving, vooraf voor een dedicated applicatie).
*) Hmm, onze zwaarst belaste server doet momenteel:
653 processes, load average: 0.12, 0.14, 0.14
(EDIT: oh natuurlijk, het is 18u, Nederland zit aan tafel)
Het is met name interessant als je een failover systeem kan ontwikkelen, volledig geclustert dus (ala pcextreme). Als dan een webserver eruit vliegt, gaat het spul over op een andere server (via de loadbalancer), maar pakt-ie nog wel gewoon de database. Moeten de files natuurlijk ook volledig los staan van de webservers.
Daarnaast betekend een database server die eruit vliegt (en enkel databases draait dus) geen problemen voor je klanten met statische content (of enkel php).
Ook betekend het dat je je server volledig kan optimaliseren voor MySQL. Je neemt wat zwakkere servers voor je webservers (die hoeven enkel php te parsen) en een zwaardere server voor je MySQL werk. Is een stukkie goedkoper op grotere schaal.
Het staat overigens ook vet als je clustert, imo.
@WH-Tim: als de applicaties goed zijn geprogrammeert, doet MySQL het meeste rekenwerk. Je trekt vervolgens die resultaten naar je webserver toe die er eigenlijk niet veel meer mee hoeft te doen (behalve door een php-loopje ofzo heen halen). De load op de webservers zal dan lager zijn (ga maar eens kijken naar 'top', je ziet dan mysqld vast wel voorbij komen. Die processen heb je dan niet meer op je webservers).
Shit, waarom zie ik toch nooit dat er nog meer pagina's zijn.
Jochem
Keenondots
24/02/06, 18:17
Ook betekend het dat je je server volledig kan optimaliseren voor MySQL. Je neemt wat zwakkere servers voor je webservers (die hoeven enkel php te parsen) en een zwaardere server voor je MySQL werk. Is een stukkie goedkoper op grotere schaal.
Let op dat het instantiëren van classes in PHP aardig wat performance kan kosten, met name in PHP4. Dan bedoel ik dus o.o. MVC applicatie met bijv. DataObjects.
Ryan Kalkhoven
24/02/06, 18:34
@keenondots
Helder verhaal! Dank!
Wij draaien alle services lokaal, dit is vooral gedaan om op specifieke wensen van klanten in te kunnen springen. De ene server heeft PHP4 en de andere weer PHP5, de ene heeft MySQL 4.1 en de andere weer MySQL 5, etc. Een ander groot voordeel vind ik toch dat indien een server er mee kapt, alleen de klanten van die server er last van hebben. Als er een MySQL server mee kapt hebben bijna alle klanten hier last van. Om eerlijk te zijn doe ik liever dezelfde handeling 5 keer, dan dat ik zwaar in de stress zit als een centrale MySQL server een keer goed op zijn bek gaat.
Ik kan mij echter wel voorstellen dat je centrale servers voor MySQL opzet zodra het aantal webservers een beetje uit de hand loopt.
@XBL:
Het zal mij om eerlijk niet kunnen schelen of een cluster vet staat, daar heb ik mijn vriendin voor ;)
Ryan Kalkhoven
24/02/06, 20:57
@XBL:
Het zal mij om eerlijk niet kunnen schelen of een cluster vet staat, daar heb ik mijn vriendin voor ;)
Ik ben zelf al vet zat ;)
sp-services
24/02/06, 23:32
DaRkDrEw: gewoon in config de localhost wijzigen in de deicated mysql server.
/usr/local/directadmin/conf/mysql.conf
host=1.2.3.4
/var/www/html/phpMyAdmin/config.inc.php
$cfg['Servers'][$i]['host'] = 'localhost'; // localhost wijzigen
dan moet er een user aangemaakt worden op de mysql
http://help.directadmin.com/item.php?id=45
Alleen opletten bij stap 2 !!!
GRANT ALL PRIVILEGES ON *.* TO da_admin@localhost IDENTIFIED BY 'newdapass' WITH GRANT OPTION;
FLUSH PRIVILEGES;
moet zijn
GRANT ALL PRIVILEGES ON *.* TO da_admin@IP IDENTIFIED BY 'newdapass' WITH GRANT OPTION;
FLUSH PRIVILEGES;
waar IP staat het IP van de Mysql invullen
Vergeet wel niet bij de user in DA
access te geven op mysql remote dan
Onze MySQL servers (Dual Opteron 270's, 4GB DDR) doen zo'n 500 a 600 queries per seconde met een load van op piek ~ 2.00.
De ene zal nu gaan zeggen dat 2.00 veeel te hoog is, maar verdiep je maar eens in wat load nu echt zegt, als je veel traffic over een bak doet, zeg 400mbit, dan zal je een load van minimaal 20 a 30 hebben, hoe snel je CPU ook is. Zo meen ik dat de bakken van kernel.org zo'n load van minimaal 200.00 constant hebben en ze gewoon supersnel zijn.
Deze bakken doen dan per stuk zo'n 30 a 40Mbit aan MySQL verkeer, reken er dus op dat we zo'n 80 Mbit aan MySQL verkeer in totaal doen, we hebben nu namelijk 2 clusters.
Vanaf 5.1 kan je eindelijk goed MyIsam tabellen clusteren (vraag white-paper maar eens aan bij MySQL)
In Q2 komt 5.1 en dan gaan wij ook zeker de mogelijkheden goed bestuderen om meerdere MySQL servers in te zetten.
Ik wil mijn klanten niet gaan vermoeien met het feit dat je op de ene server alleen reads kan doen, dat wordt veel te lastig. Daarom wil ik een MySQL cluster waar je overal read en write kan doen, 5.1 bied dat.
Storage hebben we allemaal centraal, nu nog Linux servers met NFS kernel-server, maar dat wordt een NetApp storage platform.
Performance winst hebben wij zeker gemerkt. Het gaat bij ons op grote schaal, onze webservers hebben allemaal geen RAID of snelle schijven, deze gebruiken ze bijna niet en als er een dood gaat neemt de ander het over.
De grootte van onze clusters wordt nu bepaald door hoeveel 1 MySQL-server aan kan, vanaf 5.1 moeten we dus echt mega clusters kunnen bouwen.
Voordeel zien wij er zeker in, je klanten kunnen via 1 phpMyAdmin overal bij, je hoeft minder software te updaten en backups zijn makkelijker en sneller te maken.
Wat ik al eerder aangaf, je kan je hardware perfect afstemmen en op de taken die het zal vervullen.
Tuurlijk, voor sommige gevallen zal MySQL lokaal draaien beter uitkomen en dan moet je dat ook gewoon doen.
Maar ik denk dat het helemaal van je situatie afhankelijk is.
Onze Reseller-servers draaien de MySQL ook lokaal, maar wie weet gaan we dat ooit veranderen als we besluiten DirectAdmin te gaan clusteren.
Wij gebruiken beide, op normale shared servers draait MySQL lokaal, eenvoudiger te onderhouden met backup's en als er een machine problemen heeft, ligt een deel van je klanten eruit, niet iedereen.
We hebben ook centrale MySQL-server, voor enkele zware sites (zoals mygb.nl) hier merken we zeker de performance-winst en deze server kunnen we op verzoek van klanten ook gebruiken. Voor intensieve SQL-sites biedt het m.i. voordeel om een dedicated SQL-server te gebruiken, voor een gemiddeld CMS-je of forumpje speelt dit veel minder en is de backup incl. database veel eenvoudiger te onderhouden....
Zoals Dillard al zegt, het ligt echt helemaal aan jouw situatie of het wenselijk is of niet.
Zoals Dillard al zegt, het ligt echt helemaal aan jouw situatie of het wenselijk is of niet.
Ik kan echt letterlijk alle kanten op in mijn situatie.
Ik wilde graag eens wat beweeg-redenen horen omdat vaak over dit soort zaken gesproken wordt in de trend van "mooi" in plaats van "doeltreffend".
Ik kan echt letterlijk alle kanten op in mijn situatie.
Ik wilde graag eens wat beweeg-redenen horen omdat vaak over dit soort zaken gesproken wordt in de trend van "mooi" in plaats van "doeltreffend".Stel jij hebt een DirectAdmin server met daarop een paar websites (zeg 50) en die trekken veel MySQL maar weinig httpd.
Dan neem je een losse machine voor de MySQL zodat de webserver snel blijft en de MySQL een eigen server heeft voor zijn verwerkingen.
Stel jij hebt een DirectAdmin server met daarop een paar websites (zeg 50) en die trekken veel MySQL maar weinig httpd.
Dan neem je een losse machine voor de MySQL zodat de webserver snel blijft en de MySQL een eigen server heeft voor zijn verwerkingen.
Uiteraard is dit een goed voorbeeld. Ik denk dat een combinatie zoals Dillard aangaf eigenlijk het beste idee is om flexibel en toch enige manier van failsave voor je overiges klanten te hebben die niet op de centrale server draaien.
Zoals jij ook al zei, het hangt af van de situatie. Deze kun je zo maken als je wil uiteraard ;)
c0ld phr34k
26/02/06, 04:37
Nu heb ik toch een (noob) vraagje :p.
Ik heb een dedicated server bij een host maar ik wil dat een andere dedicated bak aan de mysql server kan op mijn dedicated. Ik kreeg errors dat die gebruiker geen toegang had etc dus heb ik wat gegoogled en idd, ik moet een gebruiker toevoegen die van buiten de server toegang heeft (de andere dedicated bak). Maar hiervoor moet ik in mysql shell een commando uitvoeren maar ik ken het paswoord niet van mijn mysql user (su mysql) en mijn host zegt dat hij niks heeft moeten opgeven..
sp-services
26/02/06, 11:57
c0ld phr34k: is dit met DA ?
ErikKosters
26/02/06, 12:10
als je DA gebruikt is dit heel simpel te verhelpen.. gewoon toestaan van buitenaf.
c0ld phr34k
26/02/06, 18:29
Ja deze dedicated heeft DirectAdmin :). Maar ik vindt het echt niet hoor.. meh.
Ik zou trouwens ook graag de manier weten om het via shell te doen (indien er bv geen DA opstaat).
Ja deze dedicated heeft DirectAdmin :). Maar ik vindt het echt niet hoor.. meh.
Ik zou trouwens ook graag de manier weten om het via shell te doen (indien er bv geen DA opstaat).Met GRANT de juiste rechten geven?
GRANT ALL PRIVILIEGES ON db.* TO "user"@"server01.mijndomein.tld";
Zoiets?
c0ld phr34k
26/02/06, 21:28
Probleem is dat ik niet in mysql shell geraak. Is dat via su mysql of mysqladmin (wtf?) ofzo?
je kan via root gewoon direct mysql intypen en als het goed is zit je erin.
c0ld phr34k
27/02/06, 04:39
ERROR 1045: Access denied for user: 'root@localhost' (Using password: NO)
dat krijg ik dan..
ERROR 1045: Access denied for user: 'root@localhost' (Using password: NO)
dat krijg ik dan..
Om de uitkomst van een heel eenvoudige google aktie te laten zien:
http://dev.mysql.com/doc/refman/5.0/en/connecting-disconnecting.html
De host kan je voor localhost weglaten.
Capt.Pascal
27/02/06, 10:30
Ach ik heb wel gestemt (aparte bak)
maar het hangt toch van zovele factoren af.
Hoe druk is je bak, hoe zwar word de sql server belast
hoe betrouwbaar moetie zijn, dat soort dingen.
Niet dat ik DA heb hoor, maar is het in bv 1 centrale machine niet makkelijker te updaten?
Lijkt me makkelijker om 1 keer te updaten, dan op elke machine de mysql update starten.
sp-services
27/02/06, 12:04
/usr.local/directadmin/conf/mysql
daar staat het root pass van DA in