Bekijk Volledige Versie : Advies opzetten webhosting (zeer kleinschalig)
Hallo,
Zou er iemand mij kunnen adviseren betreft het opzetten van een hosting systeem?
We zijn een klein softwarebedrijf die onder andere webapplicaties voor onze klanten ontwikkelen.
Voor het hosten van verschillende webapps hebben we een wmware server met de volgende configuratie:
1x CentOS 5 als webserver
2x CentOS 4 als DNS1 en DNS2
1x CentOS 4 als Database Server (PostgreSQL)
1x Ubuntu 9 als mail server (postfix,dovecot,imap)
1x CentOS 5 voor git en subversion (is voor onze software ontwikkeling alleen)
De DNS servers en de mail server zijn geconfigureerd om gebruik te maken de database server.
Het beheren van deze servers, b.v. os upgrade, aanmaken domeinen, opzetten email, websites en databases
wordt op dit moment handmatig gedaan (het is gênant, ik weet). Er is dus geen control panel of dergelijke.
Op dit moment hosten we 17 applicaties (websites + webapplicaties)
Het beheren van de bovenstaande wordt langzamerhand moeilijker. Wat zou u mij adviseren.
Alvast bedankt.
Draai je DNS1 op je webserver. Scheelt alweer één server om te onderhouden. Eventueel zou je de mail daar ook bij kunnen doen. Met 17 accounts lijkt het me daar niet bepaald druk.
Is het geen idee om het e.e.a. uit te besteden?
DNS op twee servers in hetzelfde netwerk is not done.
Waarom CentOS 4???
DNS op twee servers in hetzelfde netwerk is not done.
Waarom CentOS 4???
1. kon geen twee netwerken krijgen bij de colocatie hoster.
2. oude installaties die niet zijn geupgrade.
Het is juist beter om zo veel mogelijk gescheiden te houden (vanwege veiligheid). DNS en webserver op dezelfde server schiet dus niet op als het niet verder een voordeel oplevert. Maar NS1 en NS2 in aparte servers op het zelfde netwerk levert inderdaad ook niets op, dus die kan je best samenvoegen. En Centos 4 idd... niet doen. Debian is echt een aanrader. Maar dit zijn allemaal details...
Ahmeds idee om uit te besteden is misschien wel handig. Het mensen laten doen die er verstand van hebben, kunnen jullie lekker developen. Aan de andere kant is onze ervaring dat een beetje contact met de serverwereld ook veel oplevert voor het developen van applicaties. Het zijn nou eenmaal van elkaar afhankelijke werelden.
Waarom zoek je niet een high available private cloud met snapshot + restore capabilities en goede support in de vorm van een SLA? Kan je het een en ander zelf doen, en als je hulp/ advies nodig hebt laat je je bijstaan. Afhankelijk van de performance-behoefte kan je tussen de 100 en 200 euro per maand dit prima voor elkaar krijgen.
1. kon geen twee netwerken krijgen bij de colocatie hoster.
Denk dat je dat nergens kunt krijgen voor maar 1 server, want het gaat niet om 2 netwerkkabels maar om 2 verschillende AS netwerken (en als het dan in zelfde datacenter is liefst nog met meer dan 2 verschillende mpls/transit providers.)
2. oude installaties die niet zijn geupgrade.
Sorry als ik brut zou overkomen, maar waar ontwikkel je dan voor en waarop, kan me moeilijk inbeelden dat je nog op php4 met mysql4 en oude PostgreSQL versies zit te ontwikkelen. En als dat echt het geval zou zijn dan zou ik toch wat meer tijd besteden aan het up to date houden van je development/hosting omgeving.
Verder snap ik het punt van rimote wel dat opslitsen goed is, maar zie hier de meerwaarde er niet van in om 2 dns, webserver en mail server te splitsen. Het is veel makkelijker om deze op 1 server te beheren en te onderhouden dan ze op te splitsen, want dit levert hier geen enkel voordeel op. De svn/subversion/git en SQL servers kunnen dan wel weer appart, maar dan zou ik aanraden om hetzelfde OS te gebruiken als de webserver omdat dit dan gelijk kan beheerd en geupgrade worden.
Denk dat je dat nergens kunt krijgen voor maar 1 server, want het gaat niet om 2 netwerkkabels maar om 2 verschillende AS netwerken (en als het dan in zelfde datacenter is liefst nog met meer dan 2 verschillende mpls/transit providers.)
Sorry als ik brut zou overkomen, maar waar ontwikkel je dan voor en waarop, kan me moeilijk inbeelden dat je nog op php4 met mysql4 en oude PostgreSQL versies zit te ontwikkelen. En als dat echt het geval zou zijn dan zou ik toch wat meer tijd besteden aan het up to date houden van je development/hosting omgeving.
Verder snap ik het punt van rimote wel dat opslitsen goed is, maar zie hier de meerwaarde er niet van in om 2 dns, webserver en mail server te splitsen. Het is veel makkelijker om deze op 1 server te beheren en te onderhouden dan ze op te splitsen, want dit levert hier geen enkel voordeel op. De svn/subversion/git en SQL servers kunnen dan wel weer appart, maar dan zou ik aanraden om hetzelfde OS te gebruiken als de webserver omdat dit dan gelijk kan beheerd en geupgrade worden.
We zijn op CentOS 4 blijven hangen omdat de software minimaal op PHP 5.1.6 ook moest werken (vanwege custom PHP extensies!)
Is voor het beheren, DirectAdmin, aan te raden?
We zijn op CentOS 4 blijven hangen omdat de software minimaal op PHP 5.1.6 ook moest werken (vanwege custom PHP extensies!)
Dat houdt je toch niet tegen om CentOS 5 of CentOS 6 te gebruiken, je kan toch gelijk welke php versie uit source compilen en dan is dat probleem opgelost, maar is de rest tenminste up to date.
Is voor het beheren, DirectAdmin, aan te raden?
Nee, DirectAdmin is enkel een klanten portal zodat klanten zelf dingen kunnen aanpassen en aanmaken. DirectAdmin heeft wel een custombuild zodat je makkelijk dingen kunt installeren en upgraden, maar dat moet je dan nog wel zelf manueel uitvoeren. Net zoals je ook nog yum/aptitude/yast/... (afhankelijk van OS) zelf nog moet uitvoeren. Het is dus maar de vraag of je een extra meerwaarde krijgt door het gebruik van DirectAdmin in jouw geval met custom compiled php/apache/exim/... of dat je het OS package (of eigen source compiles) gebruikt en geen klanten beheer wenst.
1x CentOS 5 als webserver
2x CentOS 4 als DNS1 en DNS2
DNS1 compleet upgraden naar laatste versies (laatste debian/centos/etc)
DNS2 op een vps die in een ander datacenter, bij een andere ISP hangt draaien. (powerdns als slave)
1x CentOS 4 als Database Server (PostgreSQL)
Upgraden, geen enkele reden om je kritieke database server risico laten lopen.
1x Ubuntu 9 als mail server (postfix,dovecot,imap)
1x CentOS 5 voor git en subversion (is voor onze software ontwikkeling alleen)
Het beheren van deze servers, b.v. os upgrade, aanmaken domeinen, opzetten email, websites en databases
wordt op dit moment handmatig gedaan (het is gênant, ik weet). Er is dus geen control panel of dergelijke.
Niks mis mee, bij weinig wijzigingen prima te doen.
Het beheren van de bovenstaande wordt langzamerhand moeilijker. Wat zou u mij adviseren.
Als je het echt wil het beheer uitbesteden, denk eraan dat dat niet goedkoop is, je wil 24/7 de partij kunnen bellen (kost flink) partijen met kennis hebben een hoger uurtarief.
Hallo,
Zou er iemand mij kunnen adviseren betreft het opzetten van een hosting systeem?
We zijn een klein softwarebedrijf die onder andere webapplicaties voor onze klanten ontwikkelen.
Voor het hosten van verschillende webapps hebben we een wmware server met de volgende configuratie:
1x CentOS 5 als webserver
2x CentOS 4 als DNS1 en DNS2
1x CentOS 4 als Database Server (PostgreSQL)
1x Ubuntu 9 als mail server (postfix,dovecot,imap)
1x CentOS 5 voor git en subversion (is voor onze software ontwikkeling alleen)
De DNS servers en de mail server zijn geconfigureerd om gebruik te maken de database server.
Het beheren van deze servers, b.v. os upgrade, aanmaken domeinen, opzetten email, websites en databases
wordt op dit moment handmatig gedaan (het is gênant, ik weet). Er is dus geen control panel of dergelijke.
Op dit moment hosten we 17 applicaties (websites + webapplicaties)
Het beheren van de bovenstaande wordt langzamerhand moeilijker. Wat zou u mij adviseren.
Alvast bedankt.
Is er een reden dat je zoveel in eigen beheer wilt doen ?
Als je 'puur' webapplicaties ontwikkelt, is eigenlijk het enige wat je wellicht zelf moet onderhouden de git/subversion server, de rest kun je allemaal als dienst afnemen.
Alleen als je applicaties heel erg diep en nauw met de server infra vervlochten zijn heb je misschien een technische noodzaak om controle te hebben over de server.
Maar anders lijkt het me dat je met een managed webserver met postgres, DNS'en gewoon van de provider, en de mail ook buiten de deur (google apps?) met weinig zorgen klaar kunt zijn.
Misschien dat je puur op zichtbare kosten iets duurder uit bent, maar volgens mij is je vraag ook omdat je merkt dat er best een hoop uren (=geld) gaan zitten in zelf netjes runnen van alle ondersteunende services, en dat voor een nogal beperkt aantal domeinen.
Deze setup kost je een bepaalde hoeveelheid tijd en geld om te draaien (onafhankelijk van het aantal domeinen), en dan een marginale hoeveelheid extra tijd/geld voor elk extra domein.
Nu moet je je tijd en kosten verdelen over heel weinig domeinen, en dan is het m.i. zakelijk gezien niet handig om dat allemaal zelf te doen.
Je hebt geen slechte keuzes qua OS'en (afgezien idd van enige upgrade aanbevelingen), en op deze schaal kun je het niet veel beter doen. Het inrichten van veel meer automatisering om dingen die je nu met de hand doet te automatiseren kost meer tijd en moeite dan het je oplevert,
in elk geval voor dit aantal servers en functies.
Kortom, zoals je je requirements omschreven hebt zou ik zeggen :
mail+dns zijn standaard diensten, gewoon afnemen.
managed webserver + database afnemen.
zelf SW development repository runnen, en misschien 1 webserver met database zelf runnen als test/proof of concept/staging.
Is er een reden dat je zoveel in eigen beheer wilt doen ?
Als je 'puur' webapplicaties ontwikkelt, is eigenlijk het enige wat je wellicht zelf moet onderhouden de git/subversion server, de rest kun je allemaal als dienst afnemen.
Alleen als je applicaties heel erg diep en nauw met de server infra vervlochten zijn heb je misschien een technische noodzaak om controle te hebben over de server.
Maar anders lijkt het me dat je met een managed webserver met postgres, DNS'en gewoon van de provider, en de mail ook buiten de deur (google apps?) met weinig zorgen klaar kunt zijn.
Misschien dat je puur op zichtbare kosten iets duurder uit bent, maar volgens mij is je vraag ook omdat je merkt dat er best een hoop uren (=geld) gaan zitten in zelf netjes runnen van alle ondersteunende services, en dat voor een nogal beperkt aantal domeinen.
Deze setup kost je een bepaalde hoeveelheid tijd en geld om te draaien (onafhankelijk van het aantal domeinen), en dan een marginale hoeveelheid extra tijd/geld voor elk extra domein.
Nu moet je je tijd en kosten verdelen over heel weinig domeinen, en dan is het m.i. zakelijk gezien niet handig om dat allemaal zelf te doen.
Je hebt geen slechte keuzes qua OS'en (afgezien idd van enige upgrade aanbevelingen), en op deze schaal kun je het niet veel beter doen. Het inrichten van veel meer automatisering om dingen die je nu met de hand doet te automatiseren kost meer tijd en moeite dan het je oplevert,
in elk geval voor dit aantal servers en functies.
Kortom, zoals je je requirements omschreven hebt zou ik zeggen :
mail+dns zijn standaard diensten, gewoon afnemen.
managed webserver + database afnemen.
zelf SW development repository runnen, en misschien 1 webserver met database zelf runnen als test/proof of concept/staging.
Zijn er wellicht bedrijven die u mij kunt aanraden betreft het uitbesteden van deze servers?
Vic D'Elfant
11/08/11, 11:22
Dan zul je het even in een offerteaanvraag moeten gieten en hier plaatsen: http://www.webhostingtalk.nl/aanbiedingen-gezocht :)
[mijn suggestie was om veel uit te besteden ]
Kortom, zoals je je requirements omschreven hebt zou ik zeggen :
mail+dns zijn standaard diensten, gewoon afnemen.
managed webserver + database afnemen.
zelf SW development repository runnen, en misschien 1 webserver met database zelf runnen als test/proof of concept/staging.
Zijn er wellicht bedrijven die u mij kunt aanraden betreft het uitbesteden van deze servers?
Daar is dit forum geloof ik niet de plek voor, en om een keus (cq type dienst) te maken moeten de wensen en eisen denk ik nog wel iets preciezer geformuleerd worden.
Mijn advies is overigens om een aantal standaard _diensten_ af te nemen, en niet zozeer "beheer mijn servers zoals ik die nu opgezet heb".
Daarin de impliciete aanname dat er eigenlijk geen 'speciale' dingen gedaan worden, op de ondersteunde services, en alleen de ontwikkelde webapplicaties 'speciaal' zijn.
Voor heel veel soorten mail gebruik is google apps (zakelijk, dus mail adres met eigen domein, niet @gmail ) een geschikte keuze.
Je zoekt dus een (linux) webserver (apache, neem ik aan).
Met de mogelijkheid om PHP (en nog meer? ) scripts te runnen, en een postgres database.
Er kwam in de antwoorden al iets langs over afhankelijkheid van een bepaalde PHP versie.
Ik zou zelf eigenlijk eerst wat webbrowsen langs een paar aanbieders om te kijken wat er typisch in pakketten aangeboden wordt.
Tot nu toe klinkt het als een 'managed server met DNS hosting'; De mailhosting kun je misschien bij dezelfde partij doen, maar kan ook heel goed elders (zoals bv google apps) gebeuren.
Waar je naar moet kijken is wat je echt nodig hebt qua webserver/modules/php versie/andere script taal e.d. .
Als je daar heel veel afwijkt van wat er in een 'standaard' pakket zit wordt het voor een aanbieder maatwerk en krijgt het een hoger prijskaartje.
Je ontwikkel server (git/subversion) zou je op een VPS kunnen hosten, of misschien gewoon 'thuis' houden. Een pure test/ontwikkel webserver volledig in eigen beheer zou je ook in-house kunnen houden, overigens.
Op moment dat je de vraag specifiek genoeg hebt, kun je 'm ook posten in 'aanbieding gezocht'
Ik zie dit soort setups wel vaker langskomen bij ontwikkelaars. Klein begonnen, hardnekkig gebleven. Vaak hangend op "die ene medewerker" die er iets van af wist, maar eigenlijk ergens anders mee bezig moet zijn. Voor een bedrijf aantrekkelijk in het begin, maar een risico later. Je hebt geen gekke dingen nodig, dit kun je tegenwoordig prima inhuren/uitbesteden.
DirectAdmin is handig om accountjes voor je eigen projecten aan te maken. Om de DNS te regelen. Om iets met email te doen. Redmine is handig voor je repositories en issues. Extra VPSje voor oude PHP versies erbij. DNS aan de hoster overlaten. Met een stuk of drie kleine VPSen kun je dit eenvoudig op laten zetten.
Waarom DNS niet volledig uitbesteden aan een partij met naamservers in meerdere datacentra/netwerken? Dit kan tegen een relatief gering bedrag per maand/jaar in veel gevallen. Dan heb je daar geen omkijken meer naar, de rest kun je mogelijk ook beter geheel of gedeeltelijk uitbesteden. De kosten van uitbesteden kunnen varieren van enkele tientjes per omgeving per maand tot enkele honderden euro's per maand voor de genoemde omgeving. Dit is helemaal afhankelijk van de eisen die er zijn mbt (telefonische) bereikbaarheid (enkel bij storingen 24/7 of ook 24/7 om een mailbox toe te voegen als je dit laatste in een controlepaneel kunt doen).
Vanderblom
24/08/11, 17:45
Ik hoor iedereen maar praten over het feit dat je DNS servers niet in 1 netwerk moet zetten.
Ben ik het helemaal mee eens maar in heel veel situaties maakt het niets uit.
Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig :)
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).
Kijk, ga ik de mail afhandelen bij een externe dan zal die niet meer doorkomen omdat de DNS (en vaak tevens ook de webserver) server offline is.
Mijn advies: Ga je alle sites ook zelf hosten, dus hele rataplan met mail enz, dan zou ik het lekker zelf hosten (DNS), verdeeld over 2 servers. Kun je tenminste onderhoud plegen.
Ga je niet alles zelf hosten, zou ik inderdaad een VPS overwegen waarin je het 1 en ander laat syncen met elkaa (en dan vooral om eventuele externe sites waar je enkel de dns voor doet online te houden, of mail records).
Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig :)
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).
Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).
Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).
Het punt dat mail (bij de afzender) gereject gaat worden is een terecht punt.
Het "wachten tot de providers ze terug opnemen" van DNS queries wanneer de NS'en een tijdje onbereikbaar geweest zijn valt nogal mee als probleem.
DNS doet negatieve caching (cachen van een server fail of record not found), maar veel korter dan de TTL gebaseerde caching van positieve antwoorden.
RFC2308 zegt dat het cachen van een server die onbereikbaar is mag, maar maximaal voor vijf minuten.
(Wanneer de server wel bereikbaar is, maar de expliciet zegt dat een record niet bestaat wordt dat antwoord ook gecached; Maar in dat geval met de minimum TTL uit de SOA als negatieve TTL. )
Een resolver die probeert iets aan je DNS te vragen terwijl die down geweest is zal dus (indien rfc compliant) hooguit vijf minuten wachten met het opnieuw proberen voor een volgende query.
Vanderblom
25/08/11, 21:20
Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).
Je begrijpt me verkeerd. Ik ga er vanuit dat veel servers ook de DNS doet, dus dat alles op 1 server staat.
Maar wat jij aangeeft daar draait het inderdaad om.
Ik hoor iedereen maar praten over het feit dat je DNS servers niet in 1 netwerk moet zetten.
Ben ik het helemaal mee eens maar in heel veel situaties maakt het niets uit.
Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig :)
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).
Kijk, ga ik de mail afhandelen bij een externe dan zal die niet meer doorkomen omdat de DNS (en vaak tevens ook de webserver) server offline is.
Mijn advies: Ga je alle sites ook zelf hosten, dus hele rataplan met mail enz, dan zou ik het lekker zelf hosten (DNS), verdeeld over 2 servers. Kun je tenminste onderhoud plegen.
Ga je niet alles zelf hosten, zou ik inderdaad een VPS overwegen waarin je het 1 en ander laat syncen met elkaa (en dan vooral om eventuele externe sites waar je enkel de dns voor doet online te houden, of mail records).
Ik snap je verhaal niet, het is dus ok dat als je server 5 min niet bereikbaar is door een kleine netwerkstoring dat een resolver die je records niet heeft (omdat ie bv net gerestart is) geen antwoord krijgt en de mail bedoeld voor je server gewoon weggooit of bounced?
En mocht je een foutje maken in de zone op je enige nameserver (met 2 ip's in dezelfde range) dan is het ook prima dat resolvers cachen dat je website/email/etc niet bestaat? Dat je dan voor enkele uren onbereikbaar bent is het waard om geen 2 dns servers in 2 netwerken/datacenters te draaien?
[..]
En mocht je een foutje maken in de zone op je enige nameserver (met 2 ip's in dezelfde range) dan is het ook prima dat resolvers cachen dat je website/email/etc niet bestaat? Dat je dan voor enkele uren onbereikbaar bent is het waard om geen 2 dns servers in 2 netwerken/datacenters te draaien?
Je lijkt hier te zeggen dat een outage, door negatieve caching tot enkele uren extra onbereikbaarheid kan leiden ?
Zo werkt negatieve caching niet. Zie mijn posting in deze thread.
Overigens, als je "foutje in de zonefile" als oorzaak neemt, daar helpen meerdere DNSen in meerdere datacenters natuurlijk niet tegen, want die zonefile met fout wordt evenzeer over alle DNSen gerepliceerd als een goede zonefile
Je lijkt hier te zeggen dat een outage, door negatieve caching tot enkele uren extra onbereikbaarheid kan leiden ?
Zo werkt negatieve caching niet. Zie mijn posting in deze thread.
Nee hoor, ik zeg alleen dat in die 5 min downtime alle mail retour gaat ipv even gequeued op de uitgaande smtp.
Overigens, als je "foutje in de zonefile" als oorzaak neemt, daar helpen meerdere DNSen in meerdere datacenters natuurlijk niet tegen, want die zonefile met fout wordt evenzeer over alle DNSen gerepliceerd als een goede zonefile
Een secondairy zal echt weigeren om een zonefile te updaten als de master geen SOA record heeft (en dus geen idee heeft of de slave up to date is)
Behalve als je zonefiles rsynced (niet echt gebruikelijk) kan die situatie niet bestaan.
Als je geen idee hebt waarom een compleet domein niet meer werkt omdat je een foutje in de zone file maakt, zal je waarschijnlijk geen gebruik maken van bind (en dan ben je een van de gelukkigen)
[..]
Een secondairy zal echt weigeren om een zonefile te updaten als de master geen SOA record heeft (en dus geen idee heeft of de slave up to date is)
Behalve als je zonefiles rsynced (niet echt gebruikelijk) kan die situatie niet bestaan.
Als je geen idee hebt waarom een compleet domein niet meer werkt omdat je een foutje in de zone file maakt, zal je waarschijnlijk geen gebruik maken van bind (en dan ben je een van de gelukkigen)
Het worden een beetje byzantijnse scenario's, op welke manier een foutje in de zonefile nog wel of nog geen zichtbaar effect heeft bij een bepaalde server setup.
Als de master ook zichtbaar is, heeft in dit scenario nog steeds 1/n (de helft, bij twee NS'en ,of 1/3 bij drie) van de bezoekers er zichtbaar last van.
Maar ik moet zeggen dat ik een foutscenario op basis van een syntactische fout in de zonefile die niet gecontroleerd/gevonden wordt op de (hidden ?) master en dan wel op de slaves een beetje vergezocht vindt.
Aangezien je aanneemt dat er geen rsync gebruikt wordt, zullen de slaves, als ze een tijdlang geen valide zonetransfer van de master kunnen doen ook stoppen met het geven van antwoorden. Kortom, je hebt alleen een wat langere tijd om je fout te ontdekken en herstellen hier, maar moet dat ontdekken blijkbaar zonder hulp van tools of checks doen, want je hebt 'm wel op de master gezet.
Om het dan te ontdekken moet je of zelf 'gewoon' een brainwave krijgen, of dan ontdekken dat je (bedoelde) wijziging nog niet op de slaves doorkomt, en dat de oorzaak die syntax fout is.
Een fout in de zonefile waar qua syntax/zonetransfer niks mis mee is, maar wel het domein of hosts erin onbereikbaar maakt lijkt me een iets meer aannamelijker model.
Maar hoe dan ook, de aanbeveling van gescheiden netwerken en gescheiden DC's heeft het voorkomen van Single Point of Failure's in de technische infrastructuur als achtergrond, en helpt niet tegen fouten hoger in de keten zoals de inhoud van zonefiles.
(tenminste, wanneer je alle DNS'en voedt vanuit een enkele bron.)
Laatste antwoord, omdat we wel erg afdwalen
Het worden een beetje byzantijnse scenario's, op welke manier een foutje in de zonefile nog wel of nog geen zichtbaar effect heeft bij een bepaalde server setup.
Als de master ook zichtbaar is, heeft in dit scenario nog steeds 1/n (de helft, bij twee NS'en ,of 1/3 bij drie) van de bezoekers er zichtbaar last van.
Onterecht, is niet hoe resolver libraries werken, als ze 1 negatief en 1(of meer keer) een ip adres terug krijgen gebruiken ze die.
<knip>
Aangezien je aanneemt dat er geen rsync gebruikt wordt, zullen de slaves, als ze een tijdlang geen valide zonetransfer van de master kunnen doen ook stoppen met het geven van antwoorden.
Incorrect, de slave blijft gewoon antwoord geven, ook als de master nooit meer terugkeert.
Laatste antwoord, omdat we wel erg afdwalen
't gaat wel richting violent agreement inderdaad...
Maar toch enig disagreement:
Onterecht, is niet hoe resolver libraries werken, als ze 1 negatief en 1(of meer keer) een ip adres terug krijgen gebruiken ze die.
<knip>
Niet wat ik bedoelde : bij een authoritief antwoord (ook fout) gaat een resolver niet verder vragen. Een dode server leidt wel tot door zoeken.
Incorrect, de slave blijft gewoon antwoord geven, ook als de master nooit meer terugkeert.
Je ging blijkbaar uit van een AXFR model (geen rsync, en master/slave terminologie), en in de SOA staat hoe lang een slave mag antwoorden zonder refresh/check met de master.
(refresh - retry - expiry). Na het verlopen van de expiry stopt de slave met antwoorden voor die zone.
De aanbevolen expiry time is typisch wel erg lang (weken), maar ook dat is te kort voor een master die _nooit_ terugkomt.
Werkt elke DNS server met een eigen bron van zoneinformatie (die eventueel via rsync, of gedeelde db, of wat dan ook centraal geupdate wordt) is de term slave niet van toepassing.
Ik zou een VPS nemen met een controlpanel als Plesk, Direct Admin of Cpanel. Je hebt dan shell acces maar geen beheer aan hard-software.
Webhosters zijn webhosters en software ontwikkelaars zijn... juist software ontwikkelaars.