Anti NLB a gazdaságban terminál szerverek, j3qx
Miért „Anti NLB»? Mert szeretnék eloszlatni egy közös tévhit a lehetőségek NLB terheléselosztás és a hibatűrés, különös tekintettel a terminál szerver farm.
Tévhit valószínűleg abból ered, hogy kudarcot vallott a szolgáltatás nevét, nem fogok beszélni az angol, de az orosz nevét és szolgáltatások jellegét lazán kapcsolódnak egymáshoz.
Használata NLB és Terminal Services előnyeit nyújtja a megnövekedett rendelkezésre állás, a skálázhatóság és a terhelés-kiegyenlítő teljesítmény, valamint a képesség, hogy osztja számos Terminal Services ügyfelei, mint egy csoport terminál szerver.
Azt hiszem, ez egyértelmű, fordítás nélkül, mintha minden jó. Csak nem annyira jó valójában.
Van egy terminál farm, amelyhez csatlakozik, több százezer ügyfelek magas frekvencia? Ha igen, akkor is nem fogja használni NLB - veszel egy hardveres terhelés kiegyenlítő e fontos forrás!
Egy másik pont - rendelkezésre állás. NLB elérhetik? Azt mondják az ellenkezőjét. NLB csak a port számát az ő beállításait, de nem tud semmit a szolgáltatás, amely biztosítja! Ha ez a szolgáltatás nem válaszol, „esett” az egyik szerver a gazdaságban, a NLB lesz, mint korábban, irányítani az új szerver kapcsolatot, és az ügyfelek nem lesz képes dolgozni vele, és hosszú ideig (akár kézi rekonfiguráció NLB)! De ha csökken egy teljes szerver (vagy legalábbis lesz elérhető fizikai hálózati interfészeket), toNLB úgy találja, néhány másodperc után, kizárják a szerver a klaszter, és nem küld neki új ügyfél kapcsolatokat.
Kézi konfigurálni a NLB fent említett, hogy szükségünk van egy mechanizmus (a script), melyben egyrészt diagnosztizálni Denial of Service (nagyon nehéz lehet, például a kapcsolat az RDP-port van, és a munkamenet tényleg nem jön létre (fekete képernyő)), másrészt kizárni a szerver a NLB fürt (ez lehet véghezvinni WMI).
És így kiderül, hogy a NLB nem teljes mértékben hálózati terheléselosztás és off-klaszter - minden, ami meg van írva a fenti idézet, szó sem lehet megbízni - meg kell érteni, mi a NLB valójában.
Menjünk előre, és nézd meg a konfiguráció a terminál farm Remote Desktop Connection Broker. Miért van az NLB?
TS Session Broker lehetővé teszi, hogy töltse be egyensúly ülések között terminál szerverek egy farmon. Ezt a funkciót a TS Session Broker terheléselosztás funkciót. Azonban ez a munkamenet-alapú terhelés kiegyenlítő funkcióhoz egy front-end terhelés kiegyenlítő mechanizmus, hogy osztja a kezdeti csatlakozási kérelmeket a terminál szerver farm. Használhatja a terhelés kiegyenlítő mechanizmus, mint a DNS round robin, NLB vagy hardver terhelés kiegyenlítő terjeszteni a kezdeti kapcsolatot kéréseket.
Továbbra is összehasonlítani megbízhatóságát szoftver, amely megvalósítja az NLB maga Connection Broker. Problémák NLB már tudjuk. Connection Broker működik intelligensebben. Figyeli a bejövő átirányítást a szerver farm, és így rájön, hogy az északi terminál él és jól van. Ha az átirányítás nem több, mint 60 másodperc (paraméter TimeServerSilentBeforePing), a Connection Broker kezd pingelni a terminál szerver, és ha több egymást követő ping (NumberFailedPingsBeforePurge opció) megszünteti sikertelenül, Connection Broker kiszolgáló kizárja a bázis. Mint látható Connection Broker sokkal okosabb, mint NLB.
RD Connection Broker támogatja terheléselosztás és visszakapcsolása meglévő ülések virtuális asztali, Remote Desktop munkamenetek és RemoteApp programok elérése a RemoteApp- és asztali kapcsolat.
Ez az, amit igazán teszi igazán hasznos és szükséges munkát kiegyenlítés - eloszlásának ülések között terminál szerver a gazdaságban, és rendelkezésre állásának biztosítása a szolgáltató - az ügyfelek és dugja a kimenet a gazdaság szerverek nem érhető el!