1 netwerk - 1 mail systeem - 2 vestigingen.

[Verwijderd]

Mensen,

Ik ben de zoveelste volgens mij die gevraagd is om twee vestigingen aan elkaar te knopen. Nu heb ik hier op het forum rond gekeken maar ik kan niet helemaal een antwoord vinden op de vragen die ik heb.

Ik zal eerst kort de situatie uitleggen.
We hebben hier een netwerk met ongeveer tien users. Nu komt er een andere vestiging bij waar ongeveer 5 users zitten. Ze hebben op de andere vestiging nu een eigen domein met mail, data en gebruikers.

Nu dacht ik om 1 AD te maken (omdat we ook doorgaan als 1 bedrijf) met twee DC's, op beide vestiging 1. Tussen de vestigingen ligt een cisco site-to-site. Op zich is dit allemaal peanuts maar ik loop op 1 zaak vast. En dat is de exchange. Ik dacht even snel twee exchange servers neer te zetten zodat ik de mailboxen kan neerzetten op de vestiging waar hij komt te werken, maar zo mooi is het allemaal helaas niet. Ik heb dit getest met VMWare maar ik krijg de mail routing niet goed voor elkaar.

Wat ik wil hebben:
- De mail voor 3 domeinnamen moet binnenkomen op 1 vestiging.
- Er zijn distibutie groepen met mensen op beide locaties (waardoor het wel 1 systeem moet blijven)
- We willen gebruik gaan maken van gedeelde agenda's van mensen op beide locaties.
- Het kan voorkomen dat mensen een week op de andere vestiging komt te werken. (vandaar dat ik twee exchange server had gedacht zodat je makkelijk een mailbox kon 'moven' naar een andere server).
- Er moet 1 ingang zijn tot het mailsysteem (zodat iedereen hetzelfde adres voor de webmail gebruikt).
- Er moet een data structuur komen waar iedereen bij kan. Wel wil ik de data per vestiging opslaan om de snelheid optimaal te maken, maar het moet wel mogelijk zijn dat iemand over de tunnel bij de bestanden kan.

Wat staat er op beide locaties?
locatie 1.
1x SBS server 2003
1x 2003 terminal server
1x wsus server
1x VOIP centrale (SWYX)
1x database systeem

locatie 2.
nog in te richten.


Heeft iemand een idee wat ik hier moet gaan gebruiken? Exchange clustering?

alvast bedankt voor alle reacties.

[Redwood]

ik snap je verhaal niet helemaal goed.
maar eh.... als je nu eens de al bestaande exchange server gebruikt, en je gebruikt dan alleen de online/webmail functie.
In dat geval kan iedereen vanuit de hele wereld in zijn email, dan hoef je niets te clusteren of wat dan ook.

Ik werk ook bij een bedrijf met meerdere vestigingen, alleen op het hoofdkantoor staan een mailserver incl agenda/gedeelde agenda, bedrijfscontacten e.d.
Iedereen logt in via webmail.

Zo hoef ik niet mail te beheren per vestiging, maar zit alles op 1 server, waar ik de hele dag lekker naast zit ;-)

Dit is toch een optie?

[Verwijderd]

Bedankt voor de snelle reactie.

Helaas is webmail voor ons geen optie. Omdat we bijvoorbeeld veel gedeelde agenda's gebruiken.

[garak]

Waarom laat je die 5 gebruikertjes niet gewoon op de terminal server werken op je hoofdlokatie? Beetje dure grap om hier allerlij ingewikkelde oplossingen voor te gaan verzinnen.

[Verwijderd]

Omdat de kans heel groot is dat mensen die nu op de locatie van 10 man zitten naar de andere kant gaan. Om flexibel te blijven wil ik het zo hebben dat mensen makkelijk op beide locaties kunnen werken.

Ook is het zo dat een aantal mensen techneuten zijn die veel eigen applicaties (VPN's en dergelijke) waardoor een terminal server voor hun niet echt makkelijk is.

[alt-92]

Mwoch....
Hoe dik is de lijn tussen die twee vestigingen, 1Mbit?
Dan kan je daar prima Outlook tegen Exchange mee laten praten, desnoods doe je RPC over HTTPS (buiten de VPN om, belast je die ook niet).

2e DC op lokatie kan wel.
Aangezien je SBS2003 gebruikt kan je een 2e Exchange server @ remote vestiging wel vergeten (weinig nut als je SBS Server als GC moet blijven staan), maar das geen bezwaar om een extra DC neer te zetten, zolang de SBS doos maar alle FSMO rollen houdt...

[Redwood]

Verwijderd schreef op dinsdag 12 september 2006 @ 20:12:
Bedankt voor de snelle reactie.

Helaas is webmail voor ons geen optie. Omdat we bijvoorbeeld veel gedeelde agenda's gebruiken.

eh ja... en wat is dan het probleem?
Dit zit toch gewoon in exchange?

Nu weet ik dit niet zeker, ikzelf werk meestal met Kerio, en deze bied WEL gedeelde agendas/contacten en wat dan ook via de web interface, werkt ook prima met pda, of telefoon via gprs/umts!


Kortom ik zeg Kerio, niet duur, gebruiksvriendelijk, makkelijk te onderhouden, snel, stabiel!
En veel leuke plugins. zoals mappen via de online browser delen, een belangrijke algehele bestanden map staat dan altijd in de webmail!!!!!

[ Voor 18% gewijzigd door Redwood op 12-09-2006 20:59 ]

[Verwijderd]

BackSlash32 schreef op dinsdag 12 september 2006 @ 20:24:
Mwoch....
Hoe dik is de lijn tussen die twee vestigingen, 1Mbit?
Dan kan je daar prima Outlook tegen Exchange mee laten praten, desnoods doe je RPC over HTTPS (buiten de VPN om, belast je die ook niet).

2e DC op lokatie kan wel.
Aangezien je SBS2003 gebruikt kan je een 2e Exchange server @ remote vestiging wel vergeten (weinig nut als je SBS Server als GC moet blijven staan), maar das geen bezwaar om een extra DC neer te zetten, zolang de SBS doos maar alle FSMO rollen houdt...

Op de 1ste locatie is ie inderdaad 1 MB. Misschien is dat RPC verhaal ook wel wat ja. Bedankt voor je hulp.

[alt-92]

redwood schreef op dinsdag 12 september 2006 @ 20:56:
[...]


eh ja... en wat is dan het probleem?
Dit zit toch gewoon in exchange?

Nu weet ik dit niet zeker, ikzelf werk meestal met Kerio, en deze bied WEL gedeelde agendas/contacten en wat dan ook via de web interface, werkt ook prima met pda, of telefoon via gprs/umts!

OWA is nice, maar niet hetzelfde als full-blown Outlook functionaliteit.

Kortom ik ga proberen poster nog meer geld te verspillen door een compleet ander pakket aan te laten schaffen en te laten implementeren...

Leuk bedacht, maar er zijn genoeg andere manieren met Outlook XP/2003 om tegen Exchange 2003 aan te praten.

[Redwood]

Leuk bedacht, maar er zijn genoeg andere manieren met Outlook XP/2003 om tegen Exchange 2003 aan te praten.

En wat kost al die nieuwe outlook xp/2003 versies aanschaffen dan wel niet, voor de overige vestigingen?

En wat zijn voordeel functies van exchange/outlook tegenover kerio?
Maar goed... voor ts... legio mogelijkheden.

[ Voor 20% gewijzigd door Redwood op 12-09-2006 22:14 ]

[Asteroid9]

Off-topic: Kerio is nauwelijks goedkoper voor kleine organisaties, de CAL's zijn goedkoper maar de serverlicentie verschilt weinig van Exchange 2003 standard.
Mijn ervaringen met Exchange alternatieven zijn tamelijk slecht, en meestal wordt ervoor gekozen vanwegen een anti-MS houding of op basis van een foutieve kostenberekening.
Zodra je een grotere mailorganisatie hebt kun je Exchange 2003 pas echt goed gaan gebruiken, alle backup / restore / routing / interfacing die er standaard in zit kun je in geen enkel alternatief product terugvinden.

Back on-topic:
De wensen van de TS lijken me niet echt ingewikkeld, meerdere domeinen afhandelen en webmail opzetten kan gewoon op de hoofdvestiging.
Een tweede mailserver op de sublocatie kan gewoon, zolang deze in hetzelfde forest zit kun je alle zaken gewoon delen / over de vestigingen gebruiken.
In jouw geval simpelweg zou ik domweg 1 domein met 2 DC's maken, heb je gelijk wat meer redundancy.

Verplaatsen van de mailbox over een WAN link moet je niet willen, tenzij je echt kleine mailboxen hebt (<50Mb)
Als het tijdelijk is moeten ze met Exchange 2003 webmail prima uit de voeten kunnen.
Wensen voor je datastructuur zijn niet echt duidelijk, maar public folders die je over beide vestigingen repliceert zijn een prima optie.

Licentietechnisch: ik werk nauwelijks met SBS, maar vermoedelijk heb je een tweede Windows 2003 en Exchange 2003 licentie nodig.
Zal je ongeveer 1300 Euro kosten, plus een aantal CAL's voor de users (5 * 70)

Je kan een Terminal Server oplossing overwegen voor die 5 users, maar een tweede server moet ook geen probleem zijn.

[ Voor 3% gewijzigd door Asteroid9 op 13-09-2006 00:32 ]

[topmusic]

Je kan ook even contact opnemen met een collega van mij, wij hebben ook 2 vestigingen gehad waarbij we een eigen local.domain hadden met een email-adres wat overal werkte.
Jij spammert

[ Voor 29% gewijzigd door Equator op 13-09-2006 08:11 ]

[nextware]

Ik zie dat je een terminal server hebt staan op de hoofdlocatie.

Wellicht is het toch verstandig om bijvoorbeeld Terminal Clients uit te rollen binnen je gehele netwerk. En dat iedereen dan op de Terminal Server werkt ?!

Scheelt je een heleboel werk om allemaal werkstations uit te rollen, profielen overal beschikbaar te maken, etc.

De kosten vallen op zich ook wel mee. CAL's zijn niet enorm duur en terminal clients zijn de laatste tijd ook in prijs gedaald.

[Rolfie]

Waarom neem je niet 1 SBS server op het hoofdkantoor. Deze heb je al staan. Maak voor de 2de vesting een 2de DC (Misschien niet eens nodig). En gebruik gewoon outlook in cached mode. Werkt goed, en snel. Je hoeft maar op 1 locatie Exchange te beheren voor SPAM en antivirus. Backup gaat ook centraal. En dit is veeeeeel gemakkelijk te beheren.

We hebben hier een vestiging in Amsterdam staan, en een locatie in New York.
Hier in Amsterdam hebben we het Exchange cluster staan, en er zit tussen de vestingen een VPN tunnel. Ze hebben daar gewoon een DC staan, en Outlook werkt netjes in Cached mode. We horen weinig klachten er over. En de mailboxen zijn groot, zeer groot (2Gb-7Gb). Het enige is, als een Laptop opnieuw ingespoeld wordt, horen we wel eens klachten, maar ja om even 7Gb over een VPN tunnel pompen

[mabarto]

Verwijderd schreef op dinsdag 12 september 2006 @ 19:54:
Wat ik wil hebben:
- De mail voor 3 domeinnamen moet binnenkomen op 1 vestiging.

+ gelukkig in te stellen

- Er zijn distibutie groepen met mensen op beide locaties (waardoor het wel 1 systeem moet blijven)

+ ook geen probleem

- We willen gebruik gaan maken van gedeelde agenda's van mensen op beide locaties.

+ non issue

- Het kan voorkomen dat mensen een week op de andere vestiging komt te werken. (vandaar dat ik twee exchange server had gedacht zodat je makkelijk een mailbox kon 'moven' naar een andere server).

+ non issue

- Er moet 1 ingang zijn tot het mailsysteem (zodat iedereen hetzelfde adres voor de webmail gebruikt).

+ Exchange front-end dan lijkt mij.

- Er moet een data structuur komen waar iedereen bij kan. Wel wil ik de data per vestiging opslaan om de snelheid optimaal te maken, maar het moet wel mogelijk zijn dat iemand over de tunnel bij de bestanden kan.

+ DFS

1x VOIP centrale (SWYX)

Kijk dat waardeer ik. Eindelijk een bedrijf dat zegt dat ie Swyxware gebruikt!

[hstuivenberg]

Rolfie schreef op woensdag 13 september 2006 @ 09:01:
Waarom neem je niet 1 SBS server op het hoofdkantoor. Deze heb je al staan. Maak voor de 2de vesting een 2de DC (Misschien niet eens nodig). En gebruik gewoon outlook in cached mode. Werkt goed, en snel. Je hoeft maar op 1 locatie Exchange te beheren voor SPAM en antivirus. Backup gaat ook centraal. En dit is veeeeeel gemakkelijk te beheren.

We hebben hier een vestiging in Amsterdam staan, en een locatie in New York.
Hier in Amsterdam hebben we het Exchange cluster staan, en er zit tussen de vestingen een VPN tunnel. Ze hebben daar gewoon een DC staan, en Outlook werkt netjes in Cached mode. We horen weinig klachten er over. En de mailboxen zijn groot, zeer groot (2Gb-7Gb). Het enige is, als een Laptop opnieuw ingespoeld wordt, horen we wel eens klachten, maar ja om even 7Gb over een VPN tunnel pompen

Een extra DC in een domein met reeds een SBS server kan toch helemaal niet?

[ralpje]

hstuivenberg schreef op woensdag 13 september 2006 @ 20:19:
[...]


Een extra DC in een domein met reeds een SBS server kan toch helemaal niet?

Volgens mij wel, zolang je SBS maar je PDC is. Maar dit zeg ik uit het blote bolletje, in het verleden behaalde resultaten yadieyadieya...

[djluc]

hstuivenberg schreef op woensdag 13 september 2006 @ 20:19:
[...]
Een extra DC in een domein met reeds een SBS server kan toch helemaal niet?

Jawel, http://blogs.msdn.com/mss...ve/2006/06/22/642920.aspx

[hstuivenberg]

djluc schreef op woensdag 13 september 2006 @ 20:32:
[...]
Jawel, http://blogs.msdn.com/mss...ve/2006/06/22/642920.aspx

Meerdere servers beschrijft dit. Een server kan je inderdaad toevoegen aan een SBS domein, maar een extra DC absoluut niet dacht ik.

[Zwelgje]

hstuivenberg schreef op woensdag 13 september 2006 @ 20:54:
[...]


Meerdere servers beschrijft dit. Een server kan je inderdaad toevoegen aan een SBS domein, maar een extra DC absoluut niet dacht ik.

dus wel

en ja ik spreek uit ruime ervaring. het is (itt enkele hardnekkige mythes) gewoon mogelijk. hierover was/is zelfs nog een technet webcast te zien waarin dit *keihard* word aangetoond. in een zal met ongelovigen

[alt-92]

Gij ook al Brutus?

Het is geen enkel probleem om een stel extra DC's naast een SBS2003 server neer te poten, zolang de SBS doos de FSMO's en GC maar heeft.
Zelfs die FSMO's kan je mee rommelen, InfraMaster heb ik ook wel eens op een andere doos neergezet zonder problemen.

redwood schreef op dinsdag 12 september 2006 @ 22:12:

En wat kost al die nieuwe outlook xp/2003 versies aanschaffen dan wel niet, voor de overige vestigingen?

Die zijn er toch al, dus waar je het over hebt?

[ Voor 32% gewijzigd door alt-92 op 13-09-2006 21:49 ]

[TrailBlazer]

mag ik zeggen dat ik het aantal servers voor het aantal gebruikers redelijk hoog vind. Volgens mij heb je op 15 gebruikers al 6 servers staan. Al die licenties/beheer kosten ook een fortuin dus kan je beter wat centraliseren lijkt me.

[alt-92]

TrailBlazer schreef op woensdag 13 september 2006 @ 21:54:
mag ik zeggen dat ik het aantal servers voor het aantal gebruikers redelijk hoog vind. Volgens mij heb je op 15 gebruikers al 6 servers staan. Al die licenties/beheer kosten ook een fortuin dus kan je beter wat centraliseren lijkt me.

VOIP doos is dedicated, databeest ook, wsus kan zelfs een desktop doos zijn, en wil je bovendien in een productie omgeving niet echt bovenop je exchange of DC zetten (ondanks dat ze dat met SBS2003R2 wel doen).

Zoveel extra zie ik niet hoor. Wat wil je er dan aan consolideren als ik vragen mag?

[Verwijderd]

Zwelgje schreef op woensdag 13 september 2006 @ 21:03:
[...]


dus wel

en ja ik spreek uit ruime ervaring. het is (itt enkele hardnekkige mythes) gewoon mogelijk. hierover was/is zelfs nog een technet webcast te zien waarin dit *keihard* word aangetoond. in een zal met ongelovigen

Ik kan het niet laten....
Maar ik heb het ook al een paar keer neergezet.

Q. Can I have other domain controllers on my SBS 2003 R2 network?
A. Yes. The most common configuration is to configure a server as a domain controller and then install it in a remote office. You can then manage all the users and computers in your SBS 2003 R2 domain using the server running SBS 2003 R2, while still providing local logon, printing, storage, and management capabilities at each office.

Q. Are there any Active Directory design constraints in SBS 2003 R2?
A. Yes. SBS 2003 R2 has the following design constraints: only one server in a domain can be running SBS 2003 R2; it must be the root of the Active Directory forest; you cannot create trust relationships with any other domains; and an SBS 2003 R2 domain cannot have any child domains. In addition, all the flexible single master operations (FSMO) are restricted to running on the SBS 2003 R2 server.

Read the FAQ @
http://www.microsoft.com/...evaluation/faq/setup.mspx

[TrailBlazer]

BackSlash32 schreef op woensdag 13 september 2006 @ 22:16:
[...]

VOIP doos is dedicated, databeest ook, wsus kan zelfs een desktop doos zijn, en wil je bovendien in een productie omgeving niet echt bovenop je exchange of DC zetten (ondanks dat ze dat met SBS2003R2 wel doen).

Zoveel extra zie ik niet hoor. Wat wil je er dan aan consolideren als ik vragen mag?

Ik bedoelde meer dat een 2e DC/exchange server me onnodig duur ingewikkeld lijkt voor zo'n beperkte hoeveelheid users. Op mijn werk werken er zeker 500 mensen over een 34mb naar de servers toe.

[Verwijderd]

Verwijderd schreef op dinsdag 12 september 2006 @ 21:03:
[...]
Op de 1ste locatie is ie inderdaad 1 MB. Misschien is dat RPC verhaal ook wel wat ja. Bedankt voor je hulp.

Je kunt als je Outllook in Cached mode laat draaien gewoon zonder verder nadenken de LANs tot één netwerk maken voor Exchange. Dat gaat met 1mbit werken, en ik za je vertellen waarom ik dat weet (voor al die mensen die je performance problemen aan gaan praten in de toekomst, een beetje ervaringsdeskundigiteit)

Ik werk op lokatie G, in een bedrijf met 5600 medewerkers waarvan er ongeveer 3500 mail hebben.
We migreren op dit moment naar Exchange. Op het hoofdkantoor in de VS staat een clustertje Exchange te draaien. Hoofdkantoor A heeft een 8 mbit lijn naar het WAN. ALLE andere lokaties hangen met al hun users aan die 8mbit link. Dat gaat prima. Het enige dat af en toe ellende opleveren kan is als een hele lokatie en masse besluit hun caches weg te pleuren en opineuw te vullen vanaf de server, dan gaat er in mijn geval (230 gebruikers x 200 MB mailbox gemiddeld =) 46 GB over die 8 Mb lijn. Dan wordt het wel een beetje langzamer allemaal. Maar afgezien van een ex-ITer die denkt dat ie alle OST files in het login script van de PC moet laten gooien "om ruimte op oudere PCs te sparen" gebeurt zoiets niet.
5 users over 1mbit kan en mag geen enkel probleem zijn. Gewoon helemaal niets aan doen, niet over nadenken.

[alt-92]

TrailBlazer schreef op donderdag 14 september 2006 @ 06:51:
Ik bedoelde meer dat een 2e DC/exchange server me onnodig duur ingewikkeld lijkt voor zo'n beperkte hoeveelheid users.

Ah, ok.
Een 2e Exchange doos lijkt me sowieso een slecht idee, maar een extra fileserver /slash/ DC met UGC aan is wel een mogelijke oplossing.
Al was het maar omdat documenten makkelijker 's nachts te syncen zijn voor backups dan overdag over de lijn te trekken voor het (be)werken.

[djluc]

Een 2e DC is sowieso geen verkeerd plan, alleen is het zo jammer dat je dan alsnog geen exchange hebt. Zijn er nog steeds geen goede oplossingen om een soort backup Exchange te hebben behalve clusters e.d.?

[alt-92]

De vraag is eerder waarom je zo perse een tweede Exch zou willen draaien?

[Asteroid9]

Dan moet je inderdaad eerst je eisen wat meer op een rijtje zetten.
Het kritieke deel zijn de databases, dan kun je wel ergens een reserve Exchange bak hebben maar zonder de databases / mailboxen heb je daar weinig aan.

Een goede recovery procedure is een stuk zinvoller dan een bult reserve installaties zonder dat je eigenlijk weet wat je er mee wilt.

[Rolfie]

Zijn er nog steeds geen goede oplossingen om een soort backup Exchange te hebben behalve clusters e.d.?

Een cluster is geen backup van Exchange. Je werkt nog steeds met 1 database.

Ga inderdaad eerst een kijken wat je precies wilt. Er staan iedeen genoeg ondertussen in dit topic.

[mindwise]

Is een wan accelerator a la juniper wx/c een oplossing ?

Wellicht 'ietwat' over the top maar wel bedoeld voor versnelling/caching van data van hoofdlocatie naar nevenlocaties.

die 'cached' bijvoorbeeld grote bestanden en versneld applicaties over het wan.

http://www.juniper.net/products/appaccel/wan/

gl

m

[djluc]

Rolfie schreef op zondag 17 september 2006 @ 13:39:
[...]
Een cluster is geen backup van Exchange. Je werkt nog steeds met 1 database.

Het woord backup is niet correct, maar als failover wel.

[Asteroid9]

Inderdaad, waarbij de failover enkel en alleen hardware problemen op kan vangen.
Tegen datacorruptie en/of softwarefouten helpt het niet, vandaar dat ik ook nogal sceptisch ben over Exchange clustering.

[JackBol]

mindwise schreef op woensdag 20 september 2006 @ 14:50:
Is een wan accelerator a la juniper wx/c een oplossing ?

Wellicht 'ietwat' over the top maar wel bedoeld voor versnelling/caching van data van hoofdlocatie naar nevenlocaties.

die 'cached' bijvoorbeeld grote bestanden en versneld applicaties over het wan.

http://www.juniper.net/products/appaccel/wan/

gl

m

moah, die dingen helpen vooral bij delay, minder bij beperkte bandbreedte. 1 Mbit trek je tot 150ms rtt nog makkelijk dicht met MAPI verkeer. Pas boven de 150ms rtt begin je impact in performance te merken.

EDIT: Sterker nog, MAPI van Outlook 2003 word helemaal niet geaccelereerd door het WX platform door aanpassingen in het protocol by microsoft. (bron)

[ Voor 15% gewijzigd door JackBol op 21-09-2006 09:38 ]

[Question Mark]

Asteroid9 schreef op woensdag 20 september 2006 @ 16:39:
Inderdaad, waarbij de failover enkel en alleen hardware problemen op kan vangen.
Tegen datacorruptie en/of softwarefouten helpt het niet, vandaar dat ik ook nogal sceptisch ben over Exchange clustering.

Da's een beetje kort door de bocht. Als ik theoretisch een blue screen op één node heb vanwege een rotte driver (= software), dan ben ik toch blij dat er een failover naar een andere node Exchange plaatsvind.

[Asteroid9]

Question Mark schreef op donderdag 21 september 2006 @ 10:23:
[...]
Da's een beetje kort door de bocht. Als ik theoretisch een blue screen op één node heb vanwege een rotte driver (= software), dan ben ik toch blij dat er een failover naar een andere node Exchange plaatsvind.

Dat is waar, maar ik moet mijn eerste blue screen op Windows 2003 nog tegen komen.
Software problemen met clusters komen een heel stuk vaker voor, dus of je availability nou gegarandeerd omhoog gaat met zo'n Exchange cluster?
Fouten in een Exchange datastore zijn waarschijnlijker, en daar helpt een cluster ook helemaal niks tegen.
Als 1 host uit je cluster er spontaan uitknalt is de kans op datacorruptie enkel nog groter, en kan de failover host ook weinig meer doen.

Begrijp me niet verkeerd: clusters hebben wel wat voordelen, maar die vind ik bij een Exchange cluster absoluut niet opwegen tegen de beheersproblematiek.
Ik hou best van exotische oplossingen, maar soms moet je dingen zo simpel mogelijk houden.
Een goed recovery scenario is een stuk nuttiger dan alleen een cluster neergooien.
Te veel beheerders vertrouwen rucksichtlos op hun geliefde cluster en hebben helemaal geen recovery scenario... (nofi)