Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Sledovací skript na NLB farmu
říjen 02
Sledovací skript na NLB farmu

Obvyklý problém s NLB (Network Load Balancing) je jak sledovat jeho životnost. Máte třeba dva a více web serverů a potřebujete se dívat, jestli žijí a pokud jeden z nich nevrací to, co byste od něho očekávali, chtěli byste danou nodu vyřadit z clusteru.

Já mám k tomu svůj mustr skript v PowerShellu, který si upravuju podle potřeby. Zde je.

Jen poznámečky:

  • funkce Control-NLBNode umi Start, Stop, Suspend, Resume a dělá to na tom počítače, na kterém běží tento skript. Mělo by tedy být zřejmé, že skript bude muset běžet na každém ze sledovaných členů NLB klastru.
  • no a potom už jenom v cyklu zkouším stáhnout nějakou webovou stránku a v jejím obsahu se dívám, jestli to obsahuje například nějaký HTML element tak, jak bych si představoval. Pokud tam není, nebo se ta stránka nestáhne, tak stopnu tanto člen NLB clusteru. Naopak, pokud to vrací v pořádku, tak ho zase nastartuju. Pro více možností stahování stránky se můžete mrknout sem.
  • když dělám ve skriptu Start a Stop, tak to znamená, že jakmile se web zase rozjede, tak se to bude každých pět sekund pokoušet nodu nahodit. Pokud tedy potřebujete nodu z klastru vyřadit ručně, nemusíte skript vypínat, ale stačí přes konzoli NLB použít příkaz Suspend. Ten způsobí, že další příkazy Start a Stop jsou bez efektu, dokud se nerozhodnete z konzole udělat Resume.
  • k tomu, aby skript fungoval, je potřeba, aby se URL a jeho FQDN "intranet" nepřekládalo na tu virtuální společnou NLB klastrovou IP adresu, kterou používají klienti, ale aby se to překládalo přímo na adresu této každé konkrétní nody. Toho dosahuju jednoduše v HOSTS souboru na všech nodách.
function Control-NLBNode ([string] $operation)
{
  $compSys = Get-WmiObject win32_computersystem
  $computerName = '{0}.{1}' -f $compSys.DNSHostName, $compSys.domain

  $clusterManager = $compSys.DNSHostName
  $suspendNode = $computerName

  Write-Host ('Going to change node state: {0} | {1}' -f $clusterManager, $suspendNode)

  $nodes = Get-WmiObject -ComputerName $clusterManager -Namespace root\MicrosoftNLB -Query "SELECT * FROM MicrosoftNLB_Node"

  $node = $nodes | ? { $_.ComputerName -eq $suspendNode }

  if ($operation -eq 'Stop') { $node.Stop() | Out-Null }
  if ($operation -eq 'Start') { $node.Resume() | Out-Null; $node.Start() | Out-Null }
  if ($operation -eq 'Suspend') { $node.Suspend() | Out-Null }
  if ($operation -eq 'Resume') { $node.Resume() | Out-Null }

  Write-Host ('Node state changed to: {0}' -f $operation)
}

while ($true) {

  $zijeTo = $false
  [string] $html = ''

  $webClient = New-Object System.Net.WebClient

  $webClient.Headers.Add("user-agent", "sevecek-nlb-testing")

  $webClient.Credentials = [System.Net.CredentialCache]::DefaultCredentials


  $ErrorActionPreference = 'SilentlyContinue'

  [string] $html = $webClient.DownloadString("http://intranet/default.aspx")

  $ErrorActionPreference = 'Continue'


  $zijeTo = $html -like '*Auta na sklade*'

  Write-Host 'Web zije: ' $zijeTo

  if (-not $zijeTo) {

    Control-NLBNode 'Stop'
  }

  else {

    Control-NLBNode 'Start'
  }

  Start-Sleep 5

}

 

Comments

NOD -  NLB

Hmmm zaujimavy clanok.
Ja mam ale iny problem  z WNLB. Mam tam W2k8 R2 a IIS 7. Identicke  WebSites. Na kazdom Cluster  NLB mam asi 20 IP  adries  pre WebSites. 
Z casu  na cas  dochadza  k tomu  ze mi to na jednu  NOD-u nejde nahodna  WebSite. Ak ju  stopnem  do drianu, na tu druhu  to ide  bez problemov. 
Myslel  som si ze to bude mat spolocne nieco  z Cisco  ARP  cache. Stretol si sa stym niekedy ?
Tom on 3.10.2013 11:27

Re: Sledovací skript na NLB farmu

to je samozřejmě možné ta ARP cache. taky to může odpojovat nějaký port, protože se mu třeba zdá, že je přetížený floodingem. Ideální by bylo zjistit, jestli ty porty nemají nějaký NLB režim, který by byl explicitně určený na tohle.

jinak je prostě potřeba se v okamžiku tohoto stavu podívat co se tam děje, to se nedá takhle říct. dokážu si představit i dalších dvacet jiných důvodů, proč se to nějak zasekne.
ondass on 4.10.2013 9:01

Jaky NLB

Zdravim.
Jakou konfiguraci NLB clusteru preferujete, mate overenou jako funkcni?
Aktualne ve virtualizaci(VMWARE) protozuji NLB v Unicast modu a nefunguje to uplne uspokojive. Testoival jsem IGMP Muticast a ten funguje daleko lepe. Akorat je nutne nastaveni na strane switchu. Bohuzel v mem pripade do komunikace vstupuje HP VirtualConnect. A i kdyz HP tvrdi, ze VirtualConnect komunikaci neovlivnuje, tak v pripade, ze jsou clenove umisteni na nekterem z fyzickem hostu, ktery je zapojen do VirtualConnectu, tak IGMP Muticast nefunguje. Jediny funkcni scenar je ten, ze oba VM jsou umisteni na stejnem fyzickem hostu. Coz je naprd...
Jakub Heinz on 5.10.2013 11:03

Re: Sledovací skript na NLB farmu

My NLB v unicast režimu používáme a je to našem prostředí plně funkční. Co přesně je pro vás problémem?
Borek on 5.10.2013 16:13

Re: Sledovací skript na NLB farmu

já jsem dělal tři sharepointy a všechno spolehlivě (nebo tedy neslyšel jsem stížnosti) funguje v unicast režimu, stejně jako vlastně, když si uvědomím, několik TMG. pokud by to nemělo fungovat, tak bych vinil nějaký zátuh na switchi. taky nejde určitě jenom o ten nejbližší switch, ale jestli je to v jedné LAN s více switchi, tak si málo pravděpodobně, ale přecejenom může být problém i na ostatních switchích. Jenže jak jsem už tu psal, to se nedá takhle moc říct.

buď bych se snažil na tom switchi najít nějaké nastavení, protože ony ty novější mnohdy mají nějaké přepnutí právě na MS NLB. Určitě bych to nepoužíval s teamingem od výrobce síťovek, protože to je podle mě nejčastější případ, kdy nefungují síťovky ve Windows nebo se chovají chaoticky. Taky ty switche floodují svoje výstupy - to má mnohdy různé limity, něco jako "flood protection" apod., které prostě potom ten port zablokují, když je na něho moc velký traffic, nebo třeba jenom vyhází nějaké ty paktety z paměti. A samozřejmě ten flooding dělají na všechny svoje porty, tedy nejenom na ty porty, které vedou do NLB - jestli máte NLB ve stejné VLAN s ještě dalšími systémy, tak to potom flooduje i ty ostatní servery a zase se to možná může nějak víc zatížit.

Dále, ja vždycky nastavuju jméno každého člena klastru do HOSTS souboru - a je jedno, jestli to má více síťovek, nebo jenom jednu tu klientskou. Mám obecně špatné zkušenosti s tím, že když ty nody neznají IP adresu kamaráda natvrdo pomocí HOSTS, tak to buď dlouho konverguje, nebo se to čas od času rozpadává.

Moje doporučení by tedy bylo asi:
a) unicast mode, všechny nody mít v HOSTS
b) vypínám NetBIOS, jako ostatně všude, ale i toto například dost broadcastuje a zase by se to mohlo projevit zvýšenou zátěží všech portů
c) ideálně vyhrazená VLAN, žádné další stroje
d) kontrola switchové dokumentace, jestli nejde u portů zapnout něco jako "NLB support"
e) vypnout na svišti všechny ochrany, IPS, flood protection, NetBIOS protection
f) vypnout na této vyhrazené VLAN všechny port security, STP, RTSP, VTP, DTP, multilinkové detekce apod. - jak ho necháte "domnívat se", tak nikdy nevíte :-)
g) nepoužívat teaming od výrobce síťovek
ondass on 6.10.2013 8:50

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments