[pfSense + HyperV] CARP echo

[pica]

Wij zijn hier bezig om een nieuwe Exchange 2013 omgeving op te zetten, we willen dat als de primaire server uitvalt er wordt geswitcht naar de secundaire Exchange server. We hebben dit werkend met DNS round robin, maar de nadelen hiervan zijn dat het traag is, dus hadden we het idee om dit door loadbalancing in pfSense te laten afhandelen.

Dit werkt prima, echter heb je nu nog steeds het probleem dat als de pfSense VM crasht of voor wat voor reden dan ook niet meer functioneert je nog steeds een probleem hebt.
Dus dacht ik van pfSense ook 2 VM's neer te zetten die naar elkaar syncen. Dit heb ik werkend gekregen op een lokale testmachine hier.

Nu heb ik exact dezelfde setup gemaakt alleen in ons cluster in het datacenter. Echter heb ik nu het probleem dat de status van CARP op de primaire pfSense VM continu switcht van backup naar master en weer terug.

Ik heb elke geavanceerde instelling van de VM's netwerkkaarten geprobeerd, zonder resultaat.
Ik vond de volgende pagina welke mijn probleem exact beschrijft:
http://sysadminadventures.com/2010/03/22/fixing-vm-based-pfsense-carp-announcement-echoes-when-using-teamed-network-adapters/
Ook in de documentatie van pfSense zelf staat dit beschreven:
https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting
Echter staat hier geen fix in voor Hyper-V, maar alleen voor ESXI. Op het pfSense forum komt dit ook vaak terug, maar inderdaad alleen icm ESXI.

Ik hoop dat iemand mij de goede richting op kan sturen.

[Question Mark]

Welke Exchange rollen/services probeer je nu te loadbalancen? En hoe heb je dit nu ingesteld? Welke monitor is gekoppeld aan de pool, en wat is de status van die monitor?

[Starck]

Hoeveel downtime(of omschakeltijd) vind je acceptabel?

Je kan het natuurlijk ook op een andere manier oplossen, bijvoorbeeld door Hyper-V clustering of iets minder snel met Hyper-V replication?

[Question Mark]

Dat heeft weer als nadeel dat onderhoud aan een systeem lastiger is.

Met loadbalancing kun je ze rustig één voor één uit de loadbalance pool halen, onderhoud doen en weer inschakelen. Dan kun je zonder downtime voor eindgebruikers onderhoud plegen.

[pica]

@?
Momenteel gaat het helemaal (nog) niet over Exchange, dat was meer achtergrond verhaal, het gaat mij nu even om pfSense.
Ik test de functionaliteit nu door RDP door te laten en dit door TCP te laten monitoren.

De loadbalancer staat als volgt ingesteld:
2 pools met elk het IP adres van de verschillende servers, mode load balance en port 3389.
Bij virtual servers heb ik het WAN adres ingevuld, port 3389, de beide pools als virtual- en fall back pool ingesteld, relay protocol is tcp.
De status is 'Unknown - relayd not running?'. De service staat wel gewoon aan overigens.

/var/etc/relayd.conf:
(123.456.789.001 is het virtuele CARP WAN adres)

code:

log updates
timeout 1000
table <EXCH01> {
        10.0.1.121 retry 2
}
table <EXCH02> {
        10.0.1.122 retry 2
}
dns protocol "dnsproto" {
        tcp { nodelay, sack, socketbuffer 1024, backlog 1000 }
}
redirect "Exchange_3389" {
  listen on 123.456.789.001 port 3389
  forward to <EXCH01> port 3389 check tcp
  forward to <EXCH02> port 3389 check tcp
}

Als ik hier 1 'echt' WAN IP adres ingeef ipv het CARP adres dan werkt dit wel.

De status van de CARP IP's switchen op de primaire pfSense bak van backup naar master en terug, en op de secundaire pfSense bak blijven ze (zoals het hoort) op backup.

@Starck
Momenteel hebben we al Hyper-V clustering. Het gaat erom dat als er iets is met de Exchange VM (iets simpels als een reboot voor Windows updates ofzo), dat de secundaire het overpikt in de tijd dat de primaire uit de lucht is.

[ Voor 185% gewijzigd door pica op 24-04-2015 14:33 ]

[Starck]

In de eerste link die je gaf hebben ze het over de CARP problemen bij een teamed network adapter. Is het mogelijk om dit zonder een teamed adapter te draaien in het datacenter?

En test je de CARP functionaliteit op dezelfde fysieke machine?

Of de andere optie die ze gaven was in de switch de multicast uit te zetten op de poort. Zodat het multicast bericht niet terug komt bij de sender.

[Rolfie]

pica schreef op vrijdag 24 april 2015 @ 13:49:
Momenteel hebben we al Hyper-V clustering. Het gaat erom dat als er iets is met de Exchange VM (iets simpels als een reboot voor Windows updates ofzo), dat de secundaire het overpikt in de tijd dat de primaire uit de lucht is.

Deze snap ik niet echt helemaal....

Als SMTP even uit de lucht is, is dat een ramp? Dit is eventueel met meerdere MX records ook perfect op te losen
En HTTP is vaak juist goed te load balacen met reverse proxy servers met een http health check.
maar soms om een reboot te detecteren, moet je soms zo vaak je health check uitvoeren, dat het soms al niet meer de moeite waard is.

[pica]

Rolfie schreef op vrijdag 24 april 2015 @ 14:11:
[...]


Deze snap ik niet echt helemaal....

Als SMTP even uit de lucht is, is dat een ramp? Dit is eventueel met meerdere MX records ook perfect op te losen
En HTTP is vaak juist goed te load balacen met reverse proxy servers met een http health check.
maar soms om een reboot te detecteren, moet je soms zo vaak je health check uitvoeren, dat het soms al niet meer de moeite waard is.

Als je meerdere klanten op dezelfde server hebt lopen is het niet gewenst dat de mailserver onbereikbaar is nee . Windows updates was een voorbeeld, maar het punt is dat als er een keer wat met de VM is waardoor hij niet meer bereikbaar is dat er een backup server is.
Het afleveren van mail is het probleem niet, omdat dit eerst in een externe spamfilter aankomt voordat het bij de exchange servers wordt afgeleverd, dus die blijven daar in de wachtrij staan tot ze weer afgeleverd kunnen worden, hier hebben klanten niet direct last van.

Het gaat nu vooral om de clients dat ze altijd bij de Exchange servers kunnen komen. Het is ongewenst dat klanten een foutmelding krijgen dat de Exchange servers niet beschikbaar zijn.

Starck schreef op vrijdag 24 april 2015 @ 14:05:
In de eerste link die je gaf hebben ze het over de CARP problemen bij een teamed network adapter. Is het mogelijk om dit zonder een teamed adapter te draaien in het datacenter?

Helaas niet, momenteel draaien er meerdere VMs welke niet zomaar plat kunnen worden gegooid over de geteamde adapters.

En test je de CARP functionaliteit op dezelfde fysieke machine?

Momenteel staan ze inderdaad beide op fysiek dezelfde machine, maar het moet natuurlijk ook blijven werken als ze naar een andere fysieke machine verhuisd worden.

Of de andere optie die ze gaven was in de switch de multicast uit te zetten op de poort. Zodat het multicast bericht niet terug komt bij de sender.

Daar ga ik eerst even research naar doen zodat ik goed de gevolgen ervan in kan schatten, dus daar moet ik even op terugkomen. Ik kan dit heel lastig zomaar doen vanwege de eerder genoemde VMs die al reeds op de host draaien.

[Starck]

Momenteel staan ze inderdaad beide op fysiek dezelfde machine, maar het moet natuurlijk ook blijven werken als ze naar een andere fysieke machine verhuisd worden.

Zou je ook een van de pfSense vm's kunnen verplaatsen naar een andere fysieke machine. Zodat ze dus via andere netwerkaarten de CARP multicast versturen. Misschien omzeil je hierbij de bug dat niemand de master wil zijn.

[pica]

Starck schreef op vrijdag 24 april 2015 @ 14:36:
[...]


Zou je ook een van de pfSense vm's kunnen verplaatsen naar een andere fysieke machine. Zodat ze dus via andere netwerkaarten de CARP multicast versturen. Misschien omzeil je hierbij de bug dat niemand de master wil zijn.

Bedankt voor je suggestie, ik heb de VM naar een andere fysieke host verplaatst, maar helaas, dit had geen effect.

Rolfie schreef op vrijdag 24 april 2015 @ 14:11:
[...]


Deze snap ik niet echt helemaal....

Als SMTP even uit de lucht is, is dat een ramp? Dit is eventueel met meerdere MX records ook perfect op te losen
En HTTP is vaak juist goed te load balacen met reverse proxy servers met een http health check.
maar soms om een reboot te detecteren, moet je soms zo vaak je health check uitvoeren, dat het soms al niet meer de moeite waard is.

Ik denk dat ik nu pas snap wat je zegt, dus ik zou met een reverse proxy server de verbinding tussen de Exchange server en de clients in stand houden, het enige wat dan wat langer zou duren is het switchen van de STMP server, wat dan door DNS round robin zou kunnen gebeuren.

Begrijp ik je dan goed?

[ Voor 68% gewijzigd door pica op 24-04-2015 14:48 ]

[johnkeates]

Je hebt voor CARP een dedicated interface nodig, en je (v)Switch moet het ondersteunen.
Makkelijkere optie is misschien HAProxy in tcp mode.

http://blog.haproxy.com/microsoft-products/exchange-2013/

[3DDude]

Je hebt dus ook meerdere ISP's, en zelf je BGP geconfigureerd?

Anders verleg je alleen je single point of failure?
Je internet lijn is ook geloadbalanced ?
2 * ISP routers, 2 Loadbalancers, 2 * Exchange client access en 2 exchange mailbox store (DAG Group) en een witness server heb je dan nodig lijkt mij.
(buiten dat je dan gelijk ook meerdere fysieke servers wilt hebben )
En nog een fallback naar een 3e server (mx record met lagere prioriteit?)

Heb je een tekening van je opstelling?

[ Voor 23% gewijzigd door 3DDude op 24-04-2015 14:55 ]

[pica]

johnkeates schreef op vrijdag 24 april 2015 @ 14:45:
Je hebt voor CARP een dedicated interface nodig, en je (v)Switch moet het ondersteunen.
Makkelijkere optie is misschien HAProxy in tcp mode.

http://blog.haproxy.com/microsoft-products/exchange-2013/

Bedankt voor je suggestie, dat ga ik even doornemen.

[johnkeates]

pica schreef op vrijdag 24 april 2015 @ 14:49:
[...]

Bedankt voor je suggestie, dat ga ik even doornemen.

Voor gateway en firewall failover is CARP dan wel weer goed om er bij te hebben. Je hebt dan 1 aanspreekpunt qua gateway, waarna de achterliggende exchange via HAProxy gebalanceerd wordt. HAProxy kan prima zonder dat de voorliggende gateway CARP doet, maar als je gateway plat gaat heb je uiteindelijk nog steeds geen exchange

[ Voor 16% gewijzigd door johnkeates op 24-04-2015 20:52 ]

[Rolfie]

pica schreef op vrijdag 24 april 2015 @ 14:42:
Ik denk dat ik nu pas snap wat je zegt, dus ik zou met een reverse proxy server de verbinding tussen de Exchange server en de clients in stand houden, het enige wat dan wat langer zou duren is het switchen van de STMP server, wat dan door DNS round robin zou kunnen gebeuren.

Begrijp ik je dan goed?

SMTP kan je gemakkelijk met meerder MX records oplossen. En een vertraging op de binnen komende of uitgaande Email merkt men niet direct.

Als je gebruikers via http verbinding maken, kan is een uitval inderdaad lastiger. Maar met een http loadbalancer kan je dit perfect oplossen. Pfsense heeft volgens mij hiervoor zelfs iets voor ingebakken.
De http verzoeken dan loadballencen tussen meerdere http servers.
Dit is vrij een vrij standaard oplossen.

[pica]

Bedankt voor de suggesties mensen, vandaag debian + HAProxy + keepalived werkend gekregen :-) .

johnkeates schreef op vrijdag 24 april 2015 @ 20:51:
[...]


Voor gateway en firewall failover is CARP dan wel weer goed om er bij te hebben. Je hebt dan 1 aanspreekpunt qua gateway, waarna de achterliggende exchange via HAProxy gebalanceerd wordt. HAProxy kan prima zonder dat de voorliggende gateway CARP doet, maar als je gateway plat gaat heb je uiteindelijk nog steeds geen exchange

Dit heb ik met keepalived opgelost, hetzelfde principe als CARP alleen werkte het in 1 keer . 1 virtual WAN ip adres voor externe verbindingen en 1 virtueel LAN ip adres als gateway.
Als de 1e debian VM uitvalt pikt de ander het op, en HAProxy regelt dat als de 1e Exchange VM uitvalt er met de andere VM verbinding wordt gemaakt.

[johnkeates]

pica schreef op dinsdag 28 april 2015 @ 16:26:
Bedankt voor de suggesties mensen, vandaag debian + HAProxy + keepalived werkend gekregen :-) .


[...]

Dit heb ik met keepalived opgelost, hetzelfde principe als CARP alleen werkte het in 1 keer . 1 virtual WAN ip adres voor externe verbindingen en 1 virtueel LAN ip adres als gateway.
Als de 1e debian VM uitvalt pikt de ander het op, en HAProxy regelt dat als de 1e Exchange VM uitvalt er met de andere VM verbinding wordt gemaakt.

Top! Dat is inderdaad ook een prima oplossing. Eigenlijk was in deze situatie CARP ook niet perse de beste oplossing geweest. CARP (en VRRP) gebruik je meestal (of, ik tenminste) voor netwerk-gerelateerde zaken. Gateway failover enzo HAProxy + iets als keepalived of heartbeatd werkt voor dingen op applicatie of layer-7 niveau uitstekend!

Heb je de systemen wel op losse bakken draaien of alles op 1 hypervisor ?

[pica]

johnkeates schreef op dinsdag 28 april 2015 @ 16:31:
[...]


Top! Dat is inderdaad ook een prima oplossing. Eigenlijk was in deze situatie CARP ook niet perse de beste oplossing geweest. CARP (en VRRP) gebruik je meestal (of, ik tenminste) voor netwerk-gerelateerde zaken. Gateway failover enzo HAProxy + iets als keepalived of heartbeatd werkt voor dingen op applicatie of layer-7 niveau uitstekend!

Heb je de systemen wel op losse bakken draaien of alles op 1 hypervisor ?

Het zijn high available VM's op een HyperV cluster van 5 fysieke bakken.

[johnkeates]

pica schreef op dinsdag 28 april 2015 @ 16:32:
[...]

Het zijn high available VM's op een HyperV cluster van 5 fysieke bakken.

Dan moet het goed komen

pfSense ook HA draaien? Die zou zichzelf dan wel moeten CARPen zonder probleem.

[pica]

johnkeates schreef op dinsdag 28 april 2015 @ 16:33:
[...]


Dan moet het goed komen

pfSense ook HA draaien? Die zou zichzelf dan wel moeten CARPen zonder probleem.

Dat probeerde ik inderdaad in de eerste instantie, echter werkte dat niet, daarom had ik dit topic aangemaakt.
Uiteindelijk maak ik in deze oplossing helemaal geen gebruik van pfSense (wat ik overigens wel jammer vind want ik vind het geniale software, ook makkelijker beheer- en overdraagbaar).

[Jazzy]

Herkenbaar probleem, loop ik ook wel eens tegenaan bij KEMP load balancers die CARP (of een variant daarop) gebruiken als je ze in HA zet. Eigenlijk zou je het eens aan de makers van pfsense moeten vragen. Er is inmiddels genoeg documentatie om het onder VMware te laten draaien, je zou zeggen dat ze ook wel info hebben voor klanten die Hyper-V gebruiken.

Kwam dit verder nog tegen:
https://forum.pfsense.org/index.php?topic=44529.0
https://forum.pfsense.org/index.php?topic=87329.0
https://forum.pfsense.org/index.php?topic=75549.60

In die laatste discussie wordt gemeld dat het met 2.2 ook in Hyper-V zou moeten werken met CARP.

[pica]

Ik heb het op een losse testbak wel voor elkaar gekregen, het probleem trad echter op toen ik het op het HyperV cluster wou implementeren; Ik vermoed dat het (nog) niet lekker samenwerkt met de geteamde NIC.

Maargoed, ik ga niet veel meer tijd aan pfSense verspillen gezien ik nu een goed werkende oplossing heb .

[Jazzy]

Als je een nog veel betere oplossing zoekt dan zou je eens naar de gratis KEMP kunnen kijken: http://freeloadbalancer.com/ Dan heb je gewoon per-service healthchecks, etc.

[pica]

Jazzy schreef op dinsdag 28 april 2015 @ 16:51:
Als je een nog veel betere oplossing zoekt dan zou je eens naar de gratis KEMP kunnen kijken: http://freeloadbalancer.com/ Dan heb je gewoon per-service healthchecks, etc.

Ga ik een keer naar kijken, bedankt.