Alex Warmerdam
RSS
Overzicht van artikelen >
We zijn van het principe uitgegaan dat als er een disaster is, de communicatie als eerste hersteld moet zijn. Je wilt immers iedereen in kunnen inlichten dat er een ramp gebeurd is. Die communicatie geldt zowel intern als extern. Intern kan je die makkelijk oplossen door een calamiteiten telefoonlijst te hebben en iedereen te bellen.
Maar je wilt als bedrijf je klanten, leveranciers en andere relaties op de hoogte kunnen stellen dat de dienstverlening ernstig verstoord is.
We hadden het voordeel dat de gebruikte email toepassingen Lotus Notes is.
Lotus Notes kent namelijk een eigen clustering en replicatie oplossing.
Vooral de optie: Provides hot standby (load balacing and automatic failover for Notes clients) is een zeer sterkte oplossing. Met een kleine time-out schakelt de de email client over van node 1 naar node 2. Door er nu voor te zorgen dat vanaf elke werkplek de op de disaster site aanwezige Notes cluster node bereikbaar is, heb je eigenlijk gelijk al wat je wilt. Bij uitval van de server schakelen de gebruikers automatisch over op een andere node. Ten tijde van het bedenken van deze opzet (2007) was er geen ander email platform wat deze functionaliteit 100% bied. Mogelijkerwijs zijn er nu andere email platformen die deze functionaliteit ook bieden. Ik hoor dat graag.
Een van de andere voordelen die Lotus Notes cluster software heeft is dat het geen clustering op hardware niveau is. Hierdoor kan je een mix maken van fysieke en gevirtualiseerde servers.
Wat dan nog opgelost moet worden is het ontvangen en versturen van mail. Gelukkig is hiervoor een eenvoudige oplossing. Het MX record van een domain naam bevat naast het aflever adres ook een optie die bepaald welk aflever adres als eerste of als tweede gebruikt moet worden. Als je bijvoorbeeld kijkt naar gmail.
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
Dan zie je dat mail eerst afgeleverd moet worden bij gmail-smtp-in.l.google.com, als dat niet lukt dan bij alt1.gmail-smtp-in.1.google.com.
Door de email omgeving te voorzien van twee of meer smtp connectors, kan je de email op de disaster site laten afleveren. Je email omgeving moet dit wel kunnen ondersteunen.
Voor webmail geldt hetzelfde. Deze is ook redundant opgezet. Door het ‘A’ record van de DNS entry aan te passen, komen gebruikers uit de webmail server waarvan je weet dat ze die kunnen gebruiken.
Eventueel kan je op je website, als deze extern gehost word, ook een linkje plaatsen naar de webmail die je ingeval van een disaster aanpast.
Communicatie is nu geregeld.
Een van de voordelen van deze opzet is, je kan hem dagelijks uittesten.
Op naar deel 3.
Disaster Recovery, deel 2. Email.
Geplaatst op 2-2-2010 09:52 door Alex Warmerdam| NGN Evenement |
| "Disaster Recovery"
op 17 februari
Je kan je hier inschrijven Alex Warmerdam presenteert daar ook en behandelt DR vanuit de praktijk |
| Leden €50,-, Niet-leden €95,-
Lid worden kan hier |
Maar je wilt als bedrijf je klanten, leveranciers en andere relaties op de hoogte kunnen stellen dat de dienstverlening ernstig verstoord is.
We hadden het voordeel dat de gebruikte email toepassingen Lotus Notes is.
Lotus Notes kent namelijk een eigen clustering en replicatie oplossing.
Vooral de optie: Provides hot standby (load balacing and automatic failover for Notes clients) is een zeer sterkte oplossing. Met een kleine time-out schakelt de de email client over van node 1 naar node 2. Door er nu voor te zorgen dat vanaf elke werkplek de op de disaster site aanwezige Notes cluster node bereikbaar is, heb je eigenlijk gelijk al wat je wilt. Bij uitval van de server schakelen de gebruikers automatisch over op een andere node. Ten tijde van het bedenken van deze opzet (2007) was er geen ander email platform wat deze functionaliteit 100% bied. Mogelijkerwijs zijn er nu andere email platformen die deze functionaliteit ook bieden. Ik hoor dat graag.
Lotus Notes cluster kan bestaan uit 2 tot 6 cluster nodes.
Een van de andere voordelen die Lotus Notes cluster software heeft is dat het geen clustering op hardware niveau is. Hierdoor kan je een mix maken van fysieke en gevirtualiseerde servers.
Wat dan nog opgelost moet worden is het ontvangen en versturen van mail. Gelukkig is hiervoor een eenvoudige oplossing. Het MX record van een domain naam bevat naast het aflever adres ook een optie die bepaald welk aflever adres als eerste of als tweede gebruikt moet worden. Als je bijvoorbeeld kijkt naar gmail.
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
Dan zie je dat mail eerst afgeleverd moet worden bij gmail-smtp-in.l.google.com, als dat niet lukt dan bij alt1.gmail-smtp-in.1.google.com.
Door de email omgeving te voorzien van twee of meer smtp connectors, kan je de email op de disaster site laten afleveren. Je email omgeving moet dit wel kunnen ondersteunen.
Voor webmail geldt hetzelfde. Deze is ook redundant opgezet. Door het ‘A’ record van de DNS entry aan te passen, komen gebruikers uit de webmail server waarvan je weet dat ze die kunnen gebruiken.
Eventueel kan je op je website, als deze extern gehost word, ook een linkje plaatsen naar de webmail die je ingeval van een disaster aanpast.
Communicatie is nu geregeld.
Een van de voordelen van deze opzet is, je kan hem dagelijks uittesten.
Op naar deel 3.
