A Zookeeper a Hadoop egyik alprojektje, és bár a hadoopból származik, azt tapasztaltam, hogy a zookeeper egyre inkább elosztott keretrendszereket használ a hadooopon kívül. Ma a zookeeperről szeretnék beszélni, ez a cikk nem arról fog beszélni, hogyan kell használni az állatkertészet, hanem hogy mik a gyakorlati alkalmazások, milyen alkalmazások játszhatják ki az állatkertész előnyeit, és végül arról, milyen szerepet játszhat a zookeeper a disztízis weboldalarchitektúrában.
A Zookeeper egy rendkívül megbízható koordinációs rendszer nagy, elosztott rendszerek számára. Ebből a definícióból tudjuk, hogy az állatkerti gondnok egy koordinált rendszer, amely elosztott rendszereken működik. Miért van szükség koordinációs rendszerre az elosztott rendszereknek? Az okok a következők:
Egy elosztott rendszer fejlesztése nagyon nehéz dolog, és a nehézség főként az elosztott rendszer "részleges meghibásodásában" tükröződik. A "részleges hiba" azt jelenti, hogy az információ két hálózati csomópont között történő továbbításra kerül: ha a hálózat meghibásodik, a feladó nem tudja, hogy a vevő megkapta-e az üzenetet, és ennek oka összetett, a vevő lehet, hogy megkapta az üzenetet a hálózati hiba előtt, vagy a vevő folyamata halott. Az egyetlen módja annak, hogy a feladó a valódi képet kapja, ha újra csatlakozik a vevőhöz, és megkérdezi, miért történt a hiba, ami az elosztott rendszerfejlesztés "részleges hiba" problémája.
A Zookeeper a rendszer "részleges meghibásodásának" megoldásának keretrendszere. A Zookeeper nem engedi, hogy az elosztott rendszerek elkerüljék a "részleges meghibásodás" problémákat, de lehetővé teszi, hogy az elosztott rendszerek helyesen kezeljék ezeket a problémákat részleges meghibásodás esetén, így az elosztott rendszerek normálisan működhessenek.
Beszéljünk az állatkertész gyakorlati alkalmazásáról:
1. forgatókönyv: Van egy szervercsoport, amely egy adott szolgáltatást nyújt a kliensnek (például a korábban készített elosztott weboldal szerveroldala egy négy szerverből álló klaszter, amely szolgáltatásokat nyújt a front-end klaszternek), és reméljük, hogy az ügyfél minden alkalommal talál szervert a szerver klaszterében, hogy a szerver biztosíthassa a szükséges szolgáltatásokat. Ebben a helyzetben szükségünk van egy szerverlistára a programunkban, amelyből minden alkalommal olvassuk a szerverek listáját, amikor a kliens kéri. Akkor ez az allista nyilvánvalóan nem tárolható egyetlen csomópontos szerveren, különben a csomópont leáll, és az egész klaszter meghibásodik, és reméljük, hogy ez a lista akkor nagyon elérhető lesz. Ha a tárolólistában lévő szerver meghibásodott, más szerverek azonnal lecserélhetik a hibás szervert, és a hibás szervert eltávolíthatják a listáról, így a meghibásodott szerver kivonulhat az egész klaszter működéséből, és ezeket a műveleteket nem a meghibásodott szerver, hanem a klaszterben lévő normál szerver üzemelteti. Ez egy aktív, elosztott adatstruktúra, amely aktívan képes módosítani az adatelemek állapotát, amikor külső feltételek változnak. A Zookeeper keretrendszer biztosítja ezt a szolgáltatást. Ennek a szolgáltatásnak a neve: Unified Naming Service, amely nagyon hasonlít a javaEE JNDI szolgáltatására.
2. forgatókönyv: Elosztott zár szolgáltatás. Amikor egy elosztott rendszer adatokat kezel, például adatokat olvas, elemz, és végül módosít. Az elosztott rendszerben ezek a műveletek szétszóródhatnak a klaszter különböző csomópontjaira, így az adatkezelés folyamatában konzisztens probléma merül fel; ha az következetlen, rossz műveleti eredményt kapunk, egyetlen folyamatban a konzisztencia problémája könnyen megoldható, de nehezebb elérni az elosztott rendszert, mert a különböző szerverek működése független folyamatokban zajlik, és a köztes eredményeket és folyamatokat a hálózaton keresztül kell továbbítani. Így sokkal nehezebb az adatüzemeltetési konzisztens elérni. A Zookeeper olyan zárszolgáltatást nyújt, amely megoldja ezt a problémát, lehetővé téve számunkra, hogy biztosítsuk az adatműveletek következetességét elosztott adatműveletek során.
3. forgatókönyv: Konfigurációkezelés. Egy elosztott rendszerben egy szolgáltatási alkalmazást külön telepítünk n szerverre, és ezeknek a szervereknek a konfigurációs fájljai ugyanazok (például az általam tervezett distributed website keretrendszerben a szerver oldalán 4 szerver van, a 4 szerveren lévő programok ugyanazok, és a konfigurációs fájlok ugyanazok), ha a konfigurációs fájlok beállításai változnak, akkor ezeket a konfigurációs fájlokat egyenként kell megváltoztatni, ha a szerverek viszonylag kicsik, ezek a műveletek nem túl problémásak, Ha sok elosztott szerverünk van, például egy nagy internetes cég Hadoop klasztere több ezer szerverrel, akkor a konfigurációs beállítások megváltoztatása problémás és veszélyes lehet. Ebben az időben a zookeeper hasznos lehet, használhatjuk a zookeepert egy nagyon elérhető konfigurációs memóriaként, átadhatjuk ezt a Zookeepernek a menedzsment céljából, átmásoljuk a klaszter konfigurációs fájlját a zookeeper fájlrendszerének egyik csomópontjára, majd a zookeeperrel figyeljük a konfigurációs fájl állapotát minden elosztott rendszerben, miután megállapítjuk, hogy a konfigurációs fájl megváltozott, Minden szerver értesítést kap a Zookeepertől a konfigurációs fájlok szinkronizálására a Zookeeperben, és a Zookeeper szolgáltatás biztosítja, hogy a szinkronizálási művelet atomikus legyen, hogy minden szerver konfigurációs fájlja helyesen frissüljön.
4. forgatókönyv: Hibajavítási funkciók biztosítása elosztott rendszerekhez. A klaszterkezelés nehéz, és az állatkerti gondnok szolgáltatás hozzáadása az elosztott rendszerhez megkönnyíti a klaszter kezelését. A klaszterkezelésben a legproblémásabb dolog a csomóponthibakezelés, a zookeeper lehetővé teheti, hogy a klaszter egy egészséges csomópontot válasszon mesternek, a master csomópont ismeri a klaszter minden szerverének aktuális állapotát, ha egy csomópont meghibásodik, a mester értesíti a klaszter többi szerverét, hogy újraoszthassák a különböző csomópontok számítási feladatait. A Zookeeper nemcsak hibákat talál, hanem szűri a hibás szervert, megmutatja, milyen hiba van a hibás szerver, ha a hiba javítható, automatikusan megjavíthatja vagy megmondja a rendszergazdának a hiba okát, így az adminisztrátor gyorsan megtalálja a hibát és javíthatja a hibát. Lehet, hogy még mindig kérdésed van: mit tegyek, ha a master hibás? A Zookeeper ezt is figyelembe veszi: a zookeepernek van egy belső "vezetőválasztási algoritmusa", a mestereket dinamikusan lehet kiválasztani, és ha a mester meghibásodik, azonnal kiválaszthat egy új mestert a klaszter kezelésére.
Beszéljünk az állatkertész jellemzőiről:
A ZooKeeper egy egyszerűsített fájlrendszer. Ez kicsit hasonlít a Hadoophoz, de a ZooKeeper fájlrendszer kis fájlokat kezel, míg a Hadoop nagyon nagy fájlokat.
A Zookeeper rengeteg "tárgyat" kínál, amelyek lehetővé teszik számos művelet összehangolását az adatstruktúrák és protokollok között. Például: elosztott sorok, elosztott zárak, és egy azonos szinten lévő csomópontokból álló csoport "vezetőválasztási" algoritmusa.
A ZooKeeper rendkívül elérhető, saját stabilitása is jó, az elosztott klaszterek a Zookeeper klaszterek kezelésére támaszkodhatnak, és a ZooKeeper segítségével elkerülik az elosztott rendszerek egypontos meghibásodásának problémáját.
A Zookeeper lazán kapcsolt interakciós módot alkalmaz. Ez leginkább abban mutatkozik, hogy a zookeeper elosztott zárakat biztosít, amelyek időpontfoglalási mechanizmusként használhatók, lehetővé téve a résztvevő folyamatok felfedezését és interakcióját anélkül, hogy ismernék a többi folyamatot (vagy a hálózatot), és a résztvevő feleknek nem is kell egyszerre létezniük, amíg üzenetet hagynak a zookeeperben, és a folyamat befejezése után egy másik folyamat elolvashatja ezt az üzenetet, így leválasztva a csomópontok közötti kapcsolatot.
A ZooKeeper egy közös tárolót biztosít a klaszternek, ahonnan a klaszter központilag olvashat és írhat megosztott információkat, elkerülve a megosztott műveletek programozását minden csomópont számára, és csökkentve az elosztott rendszerek fejlesztésének nehézségeit.
A Zookeeper elsősorban az adatok tárolásáért és kezeléséért felelős, amelyek mindenkit érdekelnek, majd elfogadja a megfigyelők regisztrációját; ha ezeknek az adatoknak a státusza megváltozik, a Zookeeper felelős azért, hogy értesítse azokat a megfigyelőket, akik regisztráltak az Állatkertben, hogy ennek megfelelően reagáljanak, így egy mester/rabszolga kezelési módot érjenek el a klaszterhez.
Látható, hogy a zookeeper nagyon kedvező az elosztott rendszerek fejlesztésében, ami lehetővé teszi az elosztott rendszereket robusztusabbá és hatékonyabbá.
Nemrég részt vettem a minisztérium hadoop érdeklődési csoportjában, betelepítettem a hadoop-ot, mapreduce-t, Hive-ot és Hbase-et a tesztkörnyezetbe, valamint a zookeeper-t előre telepítettem a hbase telepítésekor is. A Zookeeper szolgáltatásokat nyújt, így a 3 szerver több mint fele 2, és a 4 több mint fele is kettő, így három szerver telepítése elérheti a 4 szerver hatását. A hadoop tanulása során úgy érzem, hogy a zookeeper a legnehezebb alprojekt megérthető, nem az oka, hogy technikailag felelős, hanem hogy az alkalmazási iránya nagyon zavaros számomra, ezért az első cikkem a hadoop technológiáról a zookeeperrel kezdődik, és nem a konkrét technikai megvalósításról beszél, de a zookeeper alkalmazási szcenárióiból értem a zookeeper alkalmazásának területét, úgy gondolom, hogy a zookeeper tanulása hatékonyabb lesz a fele erőfeszítéssel.
Azért szeretnék ma a zookeeperről beszélni, hogy kiegészítsem az előző cikkemben szereplő elosztott weboldal keretrendszert. Bár a weboldal architektúráját elosztott struktúrának terveztem, egy egyszerű hibakezelő mechanizmust is készítettem, például a szívverés mechanizmust, de még mindig nincs mód a klaszter egyetlen hibás pontjának megoldására: ha egy szerver meghibás, az ügyfél megpróbál csatlakozni ehhez a szerverhez, ami néhány kérés blokkolásához vezet, és a szerver erőforrásainak pazarlásához vezet. Azonban jelenleg nem szeretném módosítani a keretrendszeremet, mert mindig úgy érzem, hogy a zookeeper szolgáltatás hozzáadása a meglévő szolgáltatásokhoz befolyásolja a weboldal hatékonyságát. Szerencsére a mi osztályunk is talált ilyen problémát, osztályunk egy hatékony távoli hívási keretrendszert fejleszt ki, elválasztja a klaszterkezelést és kommunikációs menedzsmentet, és hatékony, elérhető szolgáltatásokat nyújt központilag.
Áthelyezve ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Közzétéve 2017. 07. 18. 14:19:01
|
|
|
