Mentális erő

A napokban kihelyezett okítás van nálunk, cluster témakörben. Nyilván az egészet nem fogom beírni, de a tegnapi napból egy levezetés megragadta a fantáziámat.
Előre jelzem, hogy erősen egyszerűsíteni fogok. Most egy konkrét erőforrásról lesz szó. Feltételezem, hogy ez egy fontos erőforrás, melynek ledőlése átmozgatja az erőforrás csoportot a másik node-ra – azaz failover következik be. Az erőforrás tulajdonságlapjának Advanced fülén lehet beállítani az advanced paramétereket. Ilyeneket:

  • Threshold / Period [sec]: a period időtartam alatt az erőforrás hányszor halhat meg, ahhoz, hogy kikényszerítsen egy node váltást.
  • Pending time out [sec]: mennyi ideig várjunk az erőforrásra ahhoz, hogy döglöttnek nyilvánítsuk.

Ránézésre semmi különös. De ha jobban belegondolunk, mégis van itt egy kis rafinéria.
Mondjuk legyen az erőforrás egy service. A küszöbérték legyen 3, a period 900 sec, a timeout 180 sec. (Ezek a default értékek.) A szerencsétlen szolgáltatás beragad – azaz az ‘Is alive’ hibásnak jelzi. Kivárják a 180 másodpercet, küszöbérték számláló 1-re áll. Megpróbálják újraindítani a szolgáltatást, de az ostoba vigyorral a képén továbbra is csak áll, újabb 180 sec múlva lép a küszöbérték kettőre és még 3 perc kell ahhoz, hogy az erőforráscsoport áttegye a seggét a másik node-ra. Átteszi? Igen, mert összesen 3*180 sec telt el, azaz benne vagyunk a 900 sec perióduson belül.
Igenám, de mi van akkor, ha az adminisztrátor azt mondja, hogy ez egy Exchange szolgáltatás, itt a timeout érték igen magas: vegyük fel 350 másodpercre. Tessék végiggondolni.
Pusztán szellemi erővel sikerült hazavágnunk a clustert, legalábbis a szolgáltatásra nézve. A hiba biztos megállapítása 1050 sec lesz, miközben az erőforráscsoport csak akkor fog vándorolni, ha a hibára jellemző mintázat 900 másodpercen belül történik meg. Ez a cluster a büdös életben nem fog clusztogni. (Mellékes folyomány, hogy emiatt nem lehet Exchange szerveren kiemelkedően magas rendelkezésre állást bevállalni – hiszen egy beragadt IS service biztos detektálása 15-20 percet is igénybe vehet.)
És a minta nem egyedi. Van egy másik beállító panel. Ez arra vonatkozik, hogy ha egy bizonyos intervallumon belül (period) volt x darab failover, akkor hagyja abba, mert ez az erőforráscsoport már a boldog vadászmezőkön nyargal és nem illik rugdosni a döglött oroszlánt. Namost, minden failovernek van egy jellemző ideje: ki kell nyírni a döglött erőforrásokat (szolgáltatás, egyebek) és el kell indítani a másik node-on. Exchange esetén ez megint nem kis idő. Ugyanaz a hibalehetőség: ha az x, megszorozva a failover idejével, több, mint a period érték, akkor ez a cluster még a harmadik világháború után is failoverezni fog az embernélküli sártekén.
Szép, mi? Ismerek egy csomó Microsoft terméket, de egyiknél sem emlékszem olyan GUI beállítási lehetőségre, amelyikkel ki lehet nyírni magát a terméket. (Uninstall nem játszik.)
Megint valami, amihez kevés a next-next-finish admin hozzáállás.

6 Comments

  1. Bár ismertem a paraméterek jelentését, először nagyon hitetlenkedve fogadtam a leírásodat. Aztán alaposan átgondolva mégiscsak igazat adtam neked. Végül megtaláltam a hivatalosnak mondható leírást itt (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mscs/mscs/resources_restartperiod.asp)
    amelyből ez a részlet alátámaszt téged:
    The RestartPeriod and RestartThreshold properties work together to limit restart attempts. For example, if the RestartPeriod property is set to 200 milliseconds, and the RestartThreshold property is set to two retry attempts, the Cluster service tolerates two restart failures within any 200 millisecond interval. More than two failures can occur, as long as they occur over an interval that is greater than 200 milliseconds. On the third restart failure within the 200 millisecond interval, the Cluster service considers the resource to have failed and may, depending on the RestartAction property, attempt to fail over the resource’s group to another node.

    After the interval defined by the RestartPeriod property is exceeded, the Cluster service resets the property to zero

    De ezen nem érdemes csodálkozni, ha hozzáveszed ezt a bejegyzést is:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mscs/mscs/resources_restartperiod.asp

    Ahogy írja:

    The PendingTimeout property does not necessarily limit the time that a resource can spend in a ClusterOnlinePending or ClusterOfflinePending state. This property determines only how long a Resource Monitor will wait for resource DLLs to report status updates with the SetResourceStatus function. As long as a resource DLL never exceeds the PendingTimeout interval between calls to SetResourceStatus, the resource DLL can keep a resource in a pending state indefinitely.

    Vagyis egy erőforrás akár örökre indulófélben maradhat, nem kell ahhoz a rendszergazda ügyessége. :-)

    Az egész történetet azonban nem kell felfújni. Amin te szörülködsz, az a következőt mindegyikét feltételezi:

    1. A rendszergazdának rossz beállításokat kell létrehoznia
    2. Az erőforrásnak el kell hasalnia
    3. Indulás után az erőforrás DLL-nek be kell fagynia (értsd bugosnak kell lennie) úgy, hogy sem azt nem tudja jelenteni, hogy az erőforrás nem indítható, sem státuszjelentést nem tud küldeni.

    Az eset nem kizárt, de panaszkodásnak híre hamvát nem láttam a neten. Pedig nagyon kerestem tegnap.

  2. Erőforrás-összeomlasztás javaslat:

    1. Hozz létre egy könyvtárat
    2. Hozz létre egy fileshare erőforrást, amely a könyvtárat megosztja.
    3. Windows Intézővel töröld a könyvtárat, bárhogy sikoltozik.

    Nézd meg mit csinál a fürt :-))

    Szaladgál egyik node-ról a másikra, mint a mérgezett egér addig, amig a csoport failover threshold-ját el nem éri. És ezért kellet négy érték:
    Restartthreshold – Restartperiod – legfeljebb hányszor próbálkozzon szolgáltatásújraindítással egy adott időn belül.
    Failoverthreshold – Failoverperiod – legfeljebb hányszor próbálkozzon csoportmozgatással egy adott időn belül.

    Végülis ezek a módszerek tulajdonképpen a buta rendszergazda eszközei. Nem megy valami? Indítsuk újra! Na ja, de azért meg kell mondani, hogy legfeljebb hányszor.

    Végül is a legkorrektebb az lett volna, ha a három érték egymással való kölcsönhatására felhívja a figyelmet egy párbeszédpanel, ha bármelyiket módosítjuk.

  3. Vagyis egy erőforrás akár örökre indulófélben maradhat, nem kell ahhoz a rendszergazda ügyessége. :-)
    Javíts ki, de ezt én úgy értelmezem, hogy egy beragadt erőforrás a pending timeout lejárása után leállt erőforrásnak számít, addig viszont bizonytalannak.

    Indulás után az erőforrás DLL-nek be kell fagynia (értsd bugosnak kell lennie)
    Nem feltétlenül. Nem tudom, nálatok hogy megy, de én elég sokszor láttam már olyat, hogy az Exchange IS beragadt stopping vagy starting állapotba. Ehhez pusztán a gépre telepített Symantec for Exchange alkalmazásra volt szükség. Azaz nem ez erőforrás volt bugos, hanem alkalmazások akadtak össze.

    Végül is a legkorrektebb az lett volna, ha a három érték egymással való kölcsönhatására felhívja a figyelmet egy párbeszédpanel, ha bármelyiket módosítjuk.
    Pont ez volt az én végkövetkeztetésem is, csak amikor írtam, akkor már elfelejtettem a végére biggyeszteni. Annyi mindenre fel szokták hívni a fiúk a figyelmet – sokszor feleslegesen is – ha máskor nem, akkor az OK gomb megnyomásakor lecsekkolhatták volna az egyenlőtlenségeket.

    A mérgezett egeret a hibatűrő notepad-del is el tudod játszani – csak nem szabad elmenteni az éppen szerkesztett szöveget, amikor kilövöd.:)

  4. A fürt méri, hogy az épp tranziens állapotban (induló vagy leálló) erőforrás “erőforrás DLL”-je mennyi ideje küldött állapotjelzést az erőforrás állapotáról vagyis arról, hogy épp mi van azzal az erőforrással. Ha ez az érték nagyobb, mint a pending time-out, akkor a fürt terminálja az erőforrás processzét, utána pedig failed (nem stopped!) státuszt ad neki. Ha az erőforrás DLL válaszol az erőforrás monitor kérelmére pending timeout időn belül, akkor a monitor azt az értéket állítja be, amit a DLL jelentett neki.
    Szemléletesen:

    Erőforrás monitor: Helyzet?
    Erőforrás DLL: Indul a processz.
    Erőforrás monitor: OK. Státusza: Indul
    Később, de pending timeout időn belül
    Erőforrás DLL: Még mindig indul a kicsike
    Erőforrás Monitor: OK. Státusza: Indul. Pending Timeout számláló nullára állítva

    …és így tovább, amikor egyszer csak épp a végtelenség közelében… Erőforrás DLL elnémul

    Eltelik a Pending TimeOut idő

    Erőforrás monitor: Gyilok elő, “Hát kitépem a szived, teeee!” Státusz: Failed.

    Így OK?

  5. Igen, most már világosabb. De ha így van, akkor az tényleg gáz. Én elég sokszor láttam már olyan IS service-t, amelyik a végtelenségig ragadt be starting/stopping állapotba. (Több óra eltelte után gyilkoltuk ki manuálisan.)

    …és így tovább, amikor egyszer csak épp a végtelenség közelében… Erőforrás DLL elnémul

    Ezt nem látom be, mitől történne meg. A szervíz beragadt, a dll makacsul hajtogatja, hogy éppen indulok. A rendelkezésreállás meg lekonyul.

  6. Ez van. És ebből élünk. Persze nem örülök neki én sem.

Leave a Reply

Your email address will not be published. Required fields are marked *

Discover more from MiVanVelem

Subscribe now to keep reading and get access to the full archive.

Continue reading