Er is een probleem met knooppunten die worden verwijderd uit het actieve failoverclusterlidmaatschap
In dit artikel wordt beschreven hoe u de problemen kunt oplossen waarbij knooppunten willekeurig worden verwijderd uit het actieve failoverclusterlidmaatschap.
Symptomen
Wanneer het probleem zich voordoet, ziet u gebeurtenissen zoals deze gebeurtenis die is geregistreerd in uw systeemgebeurtenislogboek:
Deze gebeurtenis wordt geregistreerd op alle knooppunten in het cluster, met uitzondering van het knooppunt dat is verwijderd. De reden voor deze gebeurtenis is dat een van de knooppunten in het cluster dat knooppunt als offline heeft gemarkeerd. Vervolgens worden alle andere knooppunten van de gebeurtenis op de hoogte brengt. Wanneer de knooppunten worden gewaarschuwd, worden de heartbeatverbindingen met het downed-knooppunt stopgezet en opgeheven.
Wat ervoor zorgde dat het knooppunt werd gemarkeerd
Alle knooppunten in een Windows Server-failovercluster communiceren met elkaar via de netwerken die zijn ingesteld om clusternetwerkcommunicatie op dit netwerk toe te staan. De knooppunten verzenden heartbeatpakketten over deze netwerken naar alle andere knooppunten. Deze pakketten moeten worden ontvangen door de andere knooppunten en vervolgens wordt een antwoord teruggestuurd. Elk knooppunt in het cluster heeft zijn eigen heartbeats die worden bewaakt om ervoor te zorgen dat het netwerk is ingeschakeld en de andere knooppunten zijn ingeschakeld. In het volgende voorbeeld moet dit gedrag worden verduidelijkt:
Als een van deze pakketten niet wordt geretourneerd, wordt de specifieke heartbeat als mislukt beschouwd. W2K8-R2-NODE2 verzendt bijvoorbeeld een aanvraag en ontvangt een antwoord van W2K8-R2-NODE1 naar een heartbeatpakket, zodat het netwerk bepaalt en het knooppunt is ingeschakeld. Als W2K8-R2-NODE1 een aanvraag verzendt naar W2K8-R2-NODE2 en W2K8-R2-NODE1 het antwoord niet krijgt, wordt dit beschouwd als een verloren heartbeat en W2K8-R2-NODE1 houdt het bij. Dit gemiste antwoord kan W2K8-R2-NODE1 het netwerk laten zien als offline totdat een andere heartbeat-aanvraag is ontvangen.
Clusterknooppunten hebben standaard een limiet van vijf fouten in vijf seconden voordat de verbinding is gemarkeerd. Dus als W2K8-R2-NODE1 de reactie vijf keer in de periode niet ontvangt, is het van mening dat de specifieke route naar W2K8-R2-NODE2 niet beschikbaar is. Als andere routes nog steeds actief zijn, blijft W2K8-R2-NODE2 actief.
Als alle routes zijn gemarkeerd voor W2K8-R2-NODE2, wordt deze verwijderd uit het actieve failoverclusterlidmaatschap en wordt de gebeurtenis 1135 die u in de eerste sectie ziet, geregistreerd. Op W2K8-R2-NODE2 wordt de clusterservice beëindigd en vervolgens opnieuw opgestart, zodat het kan proberen opnieuw aan het cluster te worden gekoppeld.
Zie het blog Gepartitioneerde clusternetwerken die zijn geschreven door Jeff Hughes voor meer informatie over hoe we specifieke routes verwerken die omlaag gaan met drie of meer knooppunten.
Nu we weten hoe het heartbeatproces werkt, wat zijn enkele van de bekende oorzaken voor het proces mislukken
Werkelijke netwerkhardwarefouten. Als het pakket ergens tussen de knooppunten verloren gaat op de kabel, mislukken de heartbeats. Een netwerktracering van beide betrokken knooppunten zal dit onthullen.
Het profiel voor uw netwerkverbindingen kan mogelijk worden geactiveerd van domein naar openbaar en weer naar domein. Tijdens de overgang van deze wijzigingen kan netwerk-I/O worden geblokkeerd. U kunt controleren of dit het geval is door het operationele logboek van het netwerkprofiel te bekijken. U vindt dit logboek door de Logboeken te openen en te navigeren naar toepassingen en serviceslogboeken\Microsoft\Windows\NetworkProfile\Operational. Bekijk de gebeurtenissen in dit logboek op het knooppunt dat is vermeld in de gebeurtenis-id 1135 en kijk of het profiel op dit moment werd gewijzigd. Zo ja, raadpleegt u Het netwerklocatieprofiel wordt gewijzigd van Domein in Openbaar in Windows 7 of in Windows Server 2008 R2.
U hebt IPv6 ingeschakeld op de servers, maar de volgende twee regels zijn uitgeschakeld voor inkomend en uitgaand verkeer in Windows Firewall:
- Core Networking - Neighbor Discovery Advertisement
- Core Networking - Neighbor Discovery Solicitation
Antivirussoftware kan dit proces ook verstoren. Als u dit vermoedt, test u door de software uit te schakelen of te verwijderen. Doe dit op eigen risico omdat u op dit moment onbeveiligd bent tegen virussen.
Latentie op uw netwerk kan er ook toe leiden dat dit gebeurt. De pakketten gaan mogelijk niet verloren tussen de knooppunten, maar ze komen mogelijk niet snel genoeg bij de knooppunten voordat de time-outperiode verloopt.
IPv6 is het standaardprotocol dat failoverclustering gebruikt voor de heartbeats. De heartbeat zelf is een UDP unicast-netwerkpakket dat communiceert via poort 3343. Als er switches, firewalls of routers niet goed zijn geconfigureerd om dit verkeer toe te staan, kunt u dergelijke problemen ondervinden.
Vernieuwingen van IPsec-beveiligingsbeleid kunnen dit probleem ook veroorzaken. Het specifieke probleem is dat tijdens een IPSec-groepsbeleid alle IPsec-beveiligingskoppelingen (SA's) worden opgesplitst door Windows Firewall met Geavanceerde beveiliging (WFAS). Hoewel dit gebeurt, wordt alle netwerkverbinding geblokkeerd. Wanneer u de beveiligingskoppelingen opnieuw onderhandelt als er vertragingen zijn bij het uitvoeren van verificatie met Active Directory, worden deze vertragingen (waarbij alle netwerkcommunicatie is geblokkeerd) ook voorkomen dat cluster-heartbeats worden doorlopen en ervoor zorgen dat clusterstatuscontrole knooppunten detecteert als ze niet binnen de drempelwaarde van 5 seconden reageren.
Oude of verouderde netwerkkaartstuurprogramma's en/of firmware. Soms kan een eenvoudige onjuiste configuratie van de netwerkkaart of switch ook leiden tot verlies van heartbeats.
Moderne netwerkkaarten en virtuele netwerkkaarten kunnen pakketverlies ondervinden. Dit kan worden bijgehouden door Prestatiemeter te openen en de teller 'Network Interface\Packets Received Discarded' toe te voegen. Dit teller is cumulatief en neemt alleen toe totdat de server opnieuw wordt opgestart. Het zien van een groot aantal pakketten dat hier wordt verwijderd, kan een teken zijn dat de ontvangstbuffers op de netwerkkaart te laag zijn ingesteld of dat de server traag presteert en het binnenkomende verkeer niet kan verwerken. Elke fabrikant van de netwerkkaart kiest of deze instellingen moeten worden weergegeven in de eigenschappen van de netwerkkaart. Daarom moet u naar de website van de fabrikant verwijzen om te leren hoe u deze waarden kunt verhogen en welke aanbevolen waarden moeten worden gebruikt. Als u op VMware werkt, krijgt u in de volgende blog meer informatie over dit onderwerp, waaronder hoe u kunt zien of dit het probleem is en verwijst u naar het VMware-artikel over de instellingen die u wilt wijzigen.
Knooppunten die worden verwijderd uit het lidmaatschap van een failovercluster op VMware ESX
Dit zijn de meest voorkomende redenen waarom deze gebeurtenissen worden geregistreerd, maar er kunnen ook andere redenen zijn. Het punt van deze blog was om u enig inzicht te geven in het proces en ook ideeën te geven over waar u naar moet zoeken. Sommigen verhogen de volgende waarden tot hun maximumwaarden om dit probleem te stoppen.
| Parameter | Standaardinstelling | Bereik |
|---|---|---|
| SameSubnetDelay | 1000 milliseconden | 250-2000 milliseconden |
| CrossSubnetDelay | 1000 milliseconden | 250-4000 milliseconden |
| SameSubnetThreshold | 5 | 3-10 |
| CrossSubnetThreshold | 5 | 3-10 |
Als u deze waarden verhoogt tot het maximum, kan de gebeurtenis en het verwijderen van knooppunten verdwijnen. Het probleem wordt gewoon gemaskeerd. Het lost niets op. Het beste is om de hoofdoorzaak van de heartbeatfouten te achterhalen en deze vast te stellen. De enige echte noodzaak voor het verhogen van deze waarden is in een scenario met meerdere sites waarin knooppunten zich op verschillende locaties bevinden en netwerklatentie niet kan worden opgelost.