Nyilvánvalóan senki terveket leállásra. De a problémák elkerülhetetlenek, és ha nincs olyan terve, hogy azonnal és automatikusan kezelje őket, akkor veszít a bevételéből, amikor a szolgáltatásai csökkennek. A Magas rendelkezésre állás segít a legrosszabb esetek megtervezésében.
Mi a magas rendelkezésre állás?
A magas rendelkezésre állás (HA) a szerver összes leállási idejének minimalizálása, ideális esetben nulláig. Számos technikát tartalmaz, mint például az automatikus méretezés, a valós idejű figyelés és az automatikus kék / zöld frissítések.
Az alapkoncepció nagyon egyszerű – az egyik szerver nem szerver. Két szerver egy szerver. Minél több redundanciát tervez, annál jobban elérhető szolgáltatása lesz. Szolgáltatása nem tapasztalhat megszakadásokat még abban az esetben sem, ha valamelyik alkatrésze lángra lobban.
Ezt olyan egyszerű eszközzel lehet elérni, mint egy automatikus méretezésű csoport, amelyet az AWS-hez hasonló felhőszolgáltatások nagyon jól támogatnak. Ha egy szervernek problémája van, például hirtelen összeomlás, a terheléselosztó észleli, hogy nem válaszol. Ezután elterelheti a forgalmat az összeomlott kiszolgálóról a fürt többi szerverére, akár új példányt is felpörgethet, ha szüksége van a kapacitásra.
Ez a felesleges filozófia a komponens-hierarchia minden szintjére érvényes. Ha például van egy mikroszolgáltatása a felhasználók által feltöltött adathordozók képfeldolgozásának kezelésére, akkor nem lenne jó ötlet ezt a háttérben futtatni az egyik gépén. Ha az adott gépnek problémái vannak, előfordulhat, hogy a felhasználók nem tudnak feltölteni, ami a szolgáltatás részleges leállásának számít, és frusztráló lehet a végfelhasználó számára.
Néha kell garancia elérhetőség az ügyfelek számára. Ha 99,999% -os rendelkezésre állást garantál egy szolgáltatási szintű megállapodásban (SLA), az azt jelenti, hogy a szolgáltatása nem maradhat le több mint öt percig évente. Ez teszi szükségessé a HA-t sok nagy vállalat számára az indulástól.
Például az AWS S3-hoz hasonló szolgáltatások SLA-kkal vannak ellátva, amelyek garantálják az adatok redundanciájának 99,9999999% -át (kilenc 9 másodpercét). Ez alapvetően azt jelenti, hogy az összes adatot a régiók között replikálják, így mindenektől biztonságban vannak, kivéve az óriás-meteor-becsapódás-az-adattárház forgatókönyvet. Akkor is fizikai elválasztással biztonságos lehet a kis meteoroktól, vagy legalábbis a sokkal reálisabb raktári tűz- vagy áramszünetektől.
A jó HA rendszerek elemei
Mi vezet leálláshoz? Az isten cselekedeteinek korlátozása, a leállást általában emberi hiba vagy véletlenszerű kudarc okozza.
A véletlenszerű kudarcokat nem igazán lehet megtervezni, de redundáns rendszerekkel körül lehet tervezni. Ezenkívül elkapják őket, miközben jó megfigyelő rendszerekkel fordulnak elő, amelyek figyelmeztethetnek a hálózat problémáira.
Az emberi tévedés megtervezhető. Első és legfontosabb: a gondos tesztkörnyezetekkel a hibák számának minimalizálása. De mindenki hibázik, még a nagyvállalatok is, ezért tervvel kell rendelkeznie, hogy mikor történnek hibák.
Automatikus méretezés és redundancia
Az automatikus méretezés az a folyamat, amely automatikusan méretezi a szerverek számát, amelyek általában a nap folyamán megfelelnek a csúcsterhelésnek, de nagy stressz esetén is.
A szolgáltatások csökkenésének egyik elsődleges módja a „halál ölelése”, amikor több ezer felhasználó tömegesen tömegesen vonul be az oldalra, vagy más módon megugrik a forgalom. Automatikus méretezés nélkül csavaros vagy, mivel nem tudsz újabb szervereket felpörgetni, és a kereslet kielégítéséhez várni kell, amíg a terhelés alábbhagy, vagy manuálisan felpörgetni egy új példányt.
Az automatikus méretezés azt jelenti, hogy soha nem kell igazán foglalkoznod ezzel a problémával (bár fizetned kell a szerver extra idejéért). Ez annak az oka, hogy az olyan szolgáltatások, mint a szerver nélküli adatbázisok és az AWS Lambda Funkciók, olyan nagyszerűek: Rendkívül jól méretezhetők a dobozból.
Ez azonban túlmutat az elsődleges szerverek automatikus méretezésén – ha más összetevőket vagy szolgáltatásokat tartalmaz a hálózatában, azoknak is képesnek kell lenniük a méretezésre. Például szükség lehet további webszerverek felgyorsítására a forgalmi igények kielégítése érdekében, de ha az adatbázis-kiszolgáló túlterhelt, akkor problémája is lesz.
Ha többet szeretne megtudni, elolvashatja cikkünket az AWS automatikus méretezésének megkezdéséről.
ÖSSZEFÜGGŐ: Az AWS Autoscaling használatának megkezdése
24/7 figyelés
A figyelés magában foglalja a naplók és mutatók valós idejű nyomon követését a szolgáltatásain. Ha ezt automatikusan elvégzi automatikus riasztásokkal, figyelmeztethet a hálózat problémáira, miközben azok történnek, nem pedig azután, hogy a felhasználókat érintenék.
Például beállíthat egy riasztást, amely akkor szól, amikor a szerver eléri a memória 90% -át, ami memóriaszivárgást vagy egy alkalmazás túlterhelésével kapcsolatos problémát jelezhet.
Ezután konfigurálhatja ezt a riasztást úgy, hogy az automatikus skálázási csoportnak azt mondja, hogy vegyen fel egy másik példányt, vagy cserélje le az aktuális példányt egy úttal.
Automatizált kék / zöld frissítések
A hibák leggyakoribb forgatókönyve egy összetört frissítés, amikor a kód megváltoztatja és megtörik az alkalmazás előre nem látható részét. Ezt kék / zöld telepítésekkel lehet megtervezni.
A kék / zöld telepítés lassú, fokozatos folyamat, amely a kódváltozásokat szakaszosan, nem pedig egyszerre telepíti. Képzelje el például, hogy van 10 kiszolgálója, amelyek ugyanazt a szoftvert futtatják egy terheléselosztó mögött.
Egy rendszeres telepítés egyszerűen frissítheti mindet azonnal, amikor új változtatásokat hajtanak végre, vagy legalább egyenként frissíti őket az állásidő elkerülése érdekében.
A kék / zöld színű telepítés az automatikus méretezéscsoport 11. kiszolgálóját indítja el, és telepíti az új kódváltozásokat. Aztán, ha „zöld” lett, vagy kéréseket fogadott el, és készen állt az indulásra, azonnal lecserélte a csoportjában lévő egyik „kék” szervert. Ezután öblítse le és ismételje meg a fürt minden kiszolgálóját. Még ha csak egy kiszolgálója is lenne, a frissítésnek ez a módszere ezt eredményezné nincs leállás.
Még jobb, ha azonnal visszaküldi a változásokat a kék kiszolgálókra, ha problémákat észlel a felügyeleti rendszereivel és a riasztásokkal. Ez azt jelenti, hogy még egy teljesen letörött frissítés sem veszi le a szolgáltatást néhány percnél tovább, ideális esetben egyáltalán nem, ha több szerver van, és lassan telepítheti a frissítést. A kék / zöld telepítések úgy konfigurálhatók, hogy csak öt percenként frissítsék a szervereink 10% -át, például lassan, egy órán keresztül.