A cél tiszta és világos: A Datastax-féle Cassanda (DSE) 4.8.9-ről fel kell frissíteni adatvesztés nélkül az összes fontosabb klaszterünket 5.1.11-re, leállás és az üzleti folyamatok bárminemű megakasztása nélkül.
Mivel nekem közvetlenül a Datastax-féle Cassandra (DSE aka Datastax Enterprise) disztribúcióval van tapasztalatom, arra fogok hivatkozni. Ugyanakkor a sztori átültethető Apache Cassandrára is, ha megnézed, melyik DSE melyik Apache Cassandrát használja, mivel nem használok Datastax specifikus dolgokat.
Előzmények
Réges-régen, egy messzi-messzi irodában, amikor valaki elkezdte tervezni azt az architektúrát, amit most használunk, megadott egy használandó DSE verziószámot, minden valószínűség szerint az akkor épp aktuálisat. Az idő telt, a szoftverünk fejlődött. Olykor egy bátor viking megszellőztette, hogy mi lenne, ha frissítenénk a komponenseket. Fúj-fúj, jó, ami most van, ne javítsuk meg, ami nem romlott el, volt rá a válasz évekig.
Majd lecserélődött a menedzsment.
A frissítős sztori tavaly szeptember magasságában kezdődik, mikor a Datastax azt mondta, hogy ők nem szeretnék tovább támogatni a DSE 4.8-as családját, és ha nem frissítünk, akkor elvesztünk mindenféle további támogatást. Mondanom sem kell, hogy mivel amúgy is elég sokáig adták a támogatást erre a verzióra, olyan sok lehetőségünk nem volt.
A feladat tehát megtervezni és lebonyolítani a frissítést, adatvesztés és az üzleti folyamatok bárminemű megakasztása nélkül.
Tervek
Első verzió
Mivel elsődleges prioritás az üzletmenet folytonossága és csak második a költség, így egy viszonylag drága megoldás született: a meglévő két (logikai) DC mellé hozzunk létre ezzel a kettővel teljesen identikus harmadikat és negyediket. A DC-k között legyen folyamatos az adatszinkronizáció. Az új DC-k már az új DSE-t tartalmazzák, így adatszinkronizáció után át lehet rá kapcsolni, a régit felszámolni, és mindenki boldog.
Ez elméletnek nagyon jó volt, de gyakorlatban nem használható, ugyanis a DSE 4.8.9 nem képes megfelelően kommunikálni a DSE 5.1.11-gyel. Az újonnan keletkező adatok látszólag átmennek, de a teljes klaszter szinkronizáció elakad.
Második verzió
Kezdjük 4.8.9-en az új DC-kben is, majd adatszinkronizálás után frissítsük fel 5.1.11-re.
Ez is hibás elképzelés, ugyanis nem lehet az adatok megtartásával direktben frissíteni 5.1.11-re. Egyszerűen más adatformátumot használnak, a régi formátumot nem képes kezelni az új, az újat pedig a régi. Az új olyan szinten nem kompatibilis a régi formátummal, hogy az sstableloader sem boldogul vele. Így természetesen az OpsCenterrel sem lehet a meglévő, régi adatformátumban készült mentéseket helyreállítani.
Harmadik verzió (végleges)
A második verzióban az volt a probléma, hogy nem lehet közvetlenül frissíteni 5.1.11-re. Tehát, szükségünk van egy köztes DSE verzióra, ami nem csak olvasni tudja a régi adatformátumot, hanem át is tudja konvertálni az újra. Ez lett a DSE 5.0.14. Az adatkonverzió után innen már tudunk közvetlenül 5.1.11-re frissíteni. Így terv szerint a két új DC-ben frissítünk folyamatosan, de egy verzióval lemaradva egymástól: 4.8.9 → 4.8.16 → 5.0.14 → 5.1.11 úton.
Fontos: Hogyha rendszeresen, akár időzítve használsz Scala scripteket a Sparkon keresztüli analitikához/adatgyűjtéshez, akkor nagy valószínűséggel kompatibilitási problémába fogsz ütközni a frissítés során. Legegyszerűbb esetben csak újra kell fordítani a scriptedet más (újabb) könyvtárakkal, rosszabb esetben akár magán a kódon is változtatni kell. Erre fontos figyelni.
Fontos: Hacsak nem kifejezetten muszáj, akkor a frissítés során ne csinálj semmilyen DDL műveletet. Ha mégis úgy hozná a sors, akkor semmiképp se a második és a harmadik kör között csináld. Ezzel komoly problémákat tudsz magadnak okozni.
Tervezett menetrend
Itt már kicsit bonyolódnak a dolgok: nevezzük a két régi adatközpontot DC_AD és DC_AS-nek (D mint Data, S mint Spark), míg a két újat DC_BD és DC_BA-nak nevezzük.
Nulladik kör
- Hozzuk létre az új Cassandra DC-t: a DC_BD és DC_BA-t.
- Csatlakoztassuk a DC_AD, DC_AS adatközpontokhoz a DC_BD és DC_BA adatközpontokat. Ehhez frissítsük a seed node-ok IP címeit a DC_A*-ban, hogy tartalmazzák a DC_B* seedek IP címeit is, majd tegyük meg ugyanezt a DC_B*-ban is, hogy ismerjék a DC_A*-hoz tartozóakat.
- Úgynevezett gördülő módon indítsuk újra (rolling restart) a DC_A*-hoz tartozó Cassandra gépeket, majd utána a DC_B*-hoz tartozóakat is.
Nem lenne muszáj mindenhol átírni a seed node-ok IP címeit, sőt igazából elég lett volna az új DC_BD és DC_BA-ban beírni a seed node-ok közé a DC_A* seed IP címeit. Hála ugye a Gossip protokollnak, egész hamar elterjed az új gépek és DC-k információja a klaszterben (próbálva). Ugyanakkor sosem lehet tudni… Szóval inkább biztosra mentünk.
Első kör
- Állítsuk át úgy az összes keyspace replikációs tényezőjét (replication factor), hogy az adatok replikálódjanak a DC_B* adatközpontokba is.
- Legyen az új DC_B* is DSE 4.8.9-en, majd menjen le az adatszinkronizáció. Sima
nodetool rebuild -dc DC_ADparancs, ahol ugye a -dc a forrás adatközpontot adja meg, esetünkben a DC_AD-t. - Frissítsük fel a DC_B*-ot a legújabb 4.8.x-re, ami most épp 4.8.16.
- Végül állítsuk át az alkalmazást, hogy a DC_BD jelű adatközpontot használja.
Második kör
- DC_A*-ot frissítsük fel először 4.8.16-ra.
- Majd 5.0.14-re.
- Majd indítsuk el az adatformátum konverzióját:
nodetool upgradesstables -a. - Amint kész a konverzió (nézz logokat), állítsuk át az alkalmazást, hogy újra a DC_AD-ról vegye az adatokat.
A második kör után jó eséllyel előfordul, hogy a régi és az új Cassandra séma verziói eltérnek. Ha nem csináltál DDL műveletet (lásd fentebb.) akkor nincs gond, a Cassandra belső táblái és keypsace-ei változtak 4.x és 5.x között. A harmadik kör után automatikusan megoldódik a probléma. Előfordulhat továbbá, hogy egyes node-ok látszólag, a nodetool describecluster szerint nem érhetőek el. Amíg a nodetool status szerint elérhetőek azok a gépek (és CQL-lel tudsz csatlakozni) nincs gond.
Példa erre a viselkedésre:
[<valaki>@<valahol> ~]$ nodetool describecluster Cluster Information: Name: test3cluster Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch Partitioner: org.apache.cassandra.dht.Murmur3Partitioner Schema versions: 21d16907-b056-319a-954e-e2bb9b05bdb7: [192.168.10.2, 192.168.10.3, 192.168.10.4, 192.168.10.5, 192.168.10.6] a59a87a9-59a5-3b80-b1c6-d0f01c051115: [192.168.10.7, 192.168.10.8] UNREACHABLE: [192.168.10.9, 192.168.10.10, 192.168.10.11]
Harmadik kör
- DC_B*-ot frissítsük fel 5.0.14-re.
- Konvertáljuk az adatformátumot.
- Frissítsük fel a DC_B*-ot 5.1.11-re.
- Állítsuk át az alkalmazást, hogy a DC_BD-ről vegye az adatokat.
Negyedik kör
- Az összes keyspace replikációs tényezőjéből vegyük ki a DC_AD és DC_AS adatközpontokat.
- A
nodetool decommissionparanccsal minden egyes DC_AD-be és DC_AS-be tartozó gépet külön-külön vegyünk ki a klaszterből. Ez a parancs azért is jó, mert megbizonyosodik arról, hogy nincs az adott gépen olyan adat, ami ne lenne meg máshol. Így pl. a rendszer ki fogja szúrni, ha az egyik keyspace replikációs tényezőjében még mindig benne van a leállítandó adatközpont. - Seed IP címek átállítása: DC_A*-okon legyen 127.0.0.1, elkerülendő, hogy az adott gép véletlenül visszakerüljön a klaszterbe. Elvileg decommission parancs után nem szabadna neki, de, khmm, volt rá példa. A DC_B*-okban pedig legyenek csak a DC_B*-hoz tartozó ip címek felsorolva.
- Cassandra gépek gördülő újraindítása.
Nagyjából készen „is” vagyunk. Ezen terv szerint a frissítés egy éles környezet esetén 5 hetet vesz igénybe. Minden verzió 1 hétig marad, 1 hét az adatszinkronizációnak és 1 hét a régi DC végleges eltávolítása előtt.
Ennek a tervnek több előnye is van:
- Mindig vissza lehet térni az előző verzióra, ha az üzletmenetben gond lenne.
- Anélkül dolgozhatunk az alkalmazás szempontjából inaktív DC-n, hogy bármennyire is hatásunk lenne az éles rendszerre. Így maga a frissítés normális irodai időben történhet.
- A rendszer egész jól tolerálja a kisebb hibákat a frissítésben.
- Ha valahol nem jönne össze a frissítés, nem kell következményektől tartani, van idő a hibajavításra.
… és hátránya:
- 3 + 2 (3 frissítés + 2 klaszter konfigurálás) alkalommal kell karbantartási ablakot kérni, praktikusan akkor, amikor senki nem használja a rendszert, tehát európai környezet esetén hajnalban, amerikai esetén korán reggel (Ausztrália legalább irodaidőben van :)).
- Drága
- Nem egyértelmű egy NoSQL rendszernél, hogy mikor is van két adatközpont szinkronban. Mi egy script segítésével megszámoljuk a fontosabb táblákban lévő sorokat az összes DC-ben és ha az egyezés legalább 99.9%, akkor jónak tekintjük. Fontos, hogy a frissítés folyamán állandó az adatszinkronizáció a DC-k közt.
- Az adatkonverzió miatt relatív lassú frissítés, és mivel mindenhol más az adatmennyiség, így csak erősen becsülhető a szükséges idő.
- Dupla adatkonverzió.
Ehhez az kell, hogy:
- Ha eddig nem lett volna, akkor ún. DCAware, vagyis „adatközpont ismerő” módban kell használni a Cassandra drivert az alkalmazás kódjában. Egyrészt, hogy véletlenül se csatlakozzon rossz IP címre az alkalmazás, másrészt pedig mivel NoSQL-ről beszélünk és az adatközpontok közti adatszinkronizációhoz mindig kell egy kis idő. Kellemetlenül furcsa bugokat okozhatna, ha az alkalmazásunk egy olyan adatot keresne az egyik DC-ben, amit a másikban már beírtunk, csak ebbe még nem lett átszinkronizálva.
- Egyszerre csak egy komponenst akarjunk frissíteni. Így az alkalmazásban lévő Cassandra drivernek tudnia kell kezelni mind a DSE 4.8.x-et, mind az 5.1.11-et. Továbbá a lekérdezéseknek is kompatibiliseknek kell lenniük oda-vissza. Helló teljes regressziós teszt!
Megvalósítás
Bár én valahol a szívem mélyén támogattam volna azt, hogy az egész frissítéssorozatot környezetenként egy hosszú éjszaka alatt lezavarjuk, nem így lett (óvatosság ugye). Mindenesetre az első, második, harmadik körökre lett készítve egy script, ami végigviszi a dolgokat, illetve lekezeli a verziók közti konfiguráció változásokat is.
Éles rendszernél az óvatosság általában jó taktika, márpedig a harmadik verzió másról sem szól. Eddig sikerült végigvinnünk jó pár éles környezetet és még jó pár van hátra, így nem kiabálnám el a végeredményt, de annyit mondhatok, hogy eddig működik a stratégia.
Hozzászólások
Sziasztok!
Sziasztok!
Nagy vonalakban átfutottam az írást. Azért nagy vonalakban, mert bár Linuxozok pár éve, nem vagyok rendszergazda, bonyolultabb Linux alapú rendszerekkel/hálózatokkal sem ismerkedtem soha. Így őszintén szólva a cikkből sem értek szinte egy kukkot sem.
Viszont felmerült bennem pár gondolat. Nem kell rendszergazdának lenni és ilyen szinten érteni az informatikához ahhoz, hogy józan paraszti ésszel végiggondolva is tudja az ember: az élet minden területén jelen van a fejlődés, a változás. Ami mindig újabb dolgokat (újabb verziókat) hoz, és egy idő után az újabbak szükség szerűen nem lesznek kompatibilisek a régiekkel, illetve a régiek nem lesznek támogatottak egy idő után. Ez alapvetés az emberi rendszerek működésében.
Nem tudom teljesen ideillő példa-e, de saját tapasztalataim alapján mondjuk egy fél évről, vagy egy évről korábbról előkotort gördülő, mondjuk Arch alapú (Manjaro, Arco stb.) telepítő képfájl a telepítést, az első frissítést (ami ilyen esetben több GB is lehet), és az első újraindítást követően szinte biztos, hogy el sem indul. Egyszerűen túl sok neki a frissítés, a változás a rendszerben.
(Had jegyezzem meg amióta a Windows a 10-es rendszerrel hasonló gördülő frissítési metódusra váltott azóta ez a probléma ott is hatványozottabban jelen van…)
A gondolatmenetet folytatva, a cikkben taglalt esetben abszolúte nem értem, hogyan lehetséges, vagy milyen tudású, gondolkodású ember lehet a működtető rendszergazda vagy a céget irányító vezetőség ha nem gondolkodnak a folyamatosan frissítésen.
Mi járhatott a fejükben miközben az idő csak telt és telt és már több tucat e-mail és reklámanyag, hivatkozás és cikk érkezett a gépükre a hivatalos cégtől és az informatikai oldalakról a rendszerük újabb és újabb frissítéséről vanatkozóan amiket ezek szerint elegánsan semmibe vettek.
Elnézést, semmi rossz indulat nincs bennem (csak kíváncsiság), de véleményem szerint ez butaság, szakmai hozzá nem értés.
Nem lett volna sokkal-sokkal olcsóbb és nem mellékesen kockázatmentesebb folyamatosan frissítgetni és szépen állni át át az újabb verziókra? Nem lenne mindenkinek jobb? A vezetőségnek amiért tudják, hogy mindig relatíve friss a rendszerük? A rendszergazdának, amiért nem kell felesleges kockázatot vállalnia és 5 hétig remegő térdekkel és gombóccal a torkában jönni-menni, hogy mikor érkezik a telefon egy teljes rendszerleállásról? Vagy egyáltalán a cég imázsának a szoftvert támogató cég felé, hogy nem az utolsó utáni pillanatban kell átállni a legrégebbi rendszerről?
Lehet csak a rosszindulat súgta a fülembe, de nem egy magyar tulajdonú cégről van szó? Ez a „Fúj-fúj, jó, ami most van, ne javítsuk meg, ami nem romlott el...” mentalitás nem magyar gonolatmenet véletlenül?
Sokan nem merik használni az Arch alapú rendszereket, mert úgy gondolják, hogy a frissítés jön ha kell, ha nem, ha jó, ha nem jó, ha működik, ha nem. De gondolom ebben az esetben azért egy elég komoly szofrtverről és támogató rendszerről lehet szó, mely esetben a frissítés nem ördögtől való. Ezért nem értem az irodát működtető emberek gondolatmenetét. Ha sok-sok ember ennek a rendszernek a (jól) működése miatt tudja etetni a családját otthon, nem az lenne a legfontosabb, hogy a kockázatokat (és költségeket) a lehető legkisebbre csökkentsék adott esetben a rendszer folyamatos frissítésének használatával?
Üdv.
Arco Linux
U.I.: és csak hogy olyanhoz is hozzászóljak amihez értek :-) és úgy gondolom részben idekapcsolódik. Frissítettem rendszert Ubuntu 18.04 LTS-ről 19.04-re. Először ugye 18.10-re kell, majd úgy 19.04-re… Egy agyrém. A rendszer lassú lesz, töredezett, és a működés és használhatóság peremén ingadozik.
A Ti hatásotokra kezdtem Linuxozni anno és Xubuntut használni. De rá kellett jönnöm az évek alatt, hogy sokáig csak erőltettem az Ubuntu vonal használatát. Nem kényelmes, nem friss, nem kézreálló rendszer. Elkezdtem ismerkedni az Arch vonallal. Sokat olvasgattam utána mielőtt belevágtam a használatába. Először Manjaro-val kezdtem. Pár hónapja használom az Arco-t és a félelmem az Arch alapú rendszerek miatt teljesen tovaszállt. Arco alatt egyetlen egyszer sem ütköztem frissítés miatti problémába. Ha volt is bizonytalanság egy-egy frissítést követően, egy-két napon belül érkezett is hozzá a javítás.
Többek közt az Arco saját repója és az opcionálisan egy kattintásra használható AUR kárpótol szinte minden gyengeségért, mely a rendszer sajátja. Az a tapasztalatom, hogy a folyamatosan érkező friss csomagok és az azokban esetlegesen felmerülő hibák feszengésre okot adható érzete sokkal-sokkal kevésbé szembetűnő és komfortérzetet csökkentő hatást vált ki bennem, mint az Ubuntu alapú rendszerek használatakor érezhető folyamatos kényelmetlenségek.
Az Ubuntu használata közben azt érzem, hogy a rendszer lassú. Nagyon tudnak hiányozni azok a lehetőségek, melyek az elavult szoftverek miatt nincsenek benne a rendszerben. A folyamatos rossz érzés, miközben olvasom a híreket az újabb megjelenő driverekről és az azokban bevezetésre kerülő hasznos fejlesztésekről, hogy nah, nekem ez sincs a rendszerben, pedig lehet, hogy hasznos lenne és megint telepíteni kellene. De sokszor hiába telepítek kézzel egy-egy csomagból frisset, ha a rendszer többi része elavult és így a gyakorlati előnyök sajnos nem kerülnek felszínre. A PPA-zás és a telepítgetések, a folyamatosan a terninál használatára kéztető működési sajátosságok rettentő frusztrálóak. Illetve az egy adott problémára, a böngésző keresőjében feltárulkozó tucatnyi különböző megoldásnak látszó dolog sem segít, melyek közül sok esetben csak az 5.-6. jelent megoldást.
Illetve meg kell említenem a rossz érzést, mely folyamatosan ott érződik bennem: az Ubuntu mögött egy cég áll. Mint a Windows mögött. És részvényesek. És egy vezetőség, mely akkor is kiadásra készteti az adott időpontban a release-t ha az félig működik rendesen és baromi kényelmetlen használni…
Az Arco-t használva számomra végleg helyre került a fejben, hogy mit is várok el egy operációs rendszertől és hogy mire is van szükségem valójában. A hivatalos oldalon fellelhető igényes és bődületesen részletes leírásoktól és videóktól kezdve, a rendszer félelmetes gyorsaságán át, az új csomagok érkezése és az új opciók használatának hasznosságán keresztül, a rendszer stabilitásáról nem is beszélve sokat, az a tapasztalatom, hogy ilyennek kell lennie egy korszerű operációs rendszernek 2019-ben. Az Arco használata közben nem kell foglalkoznom a driverekkel és a kernellel. Mindig minden friss és olybá tűnik, mintha a rendszer ennek köszönhetően szinte mindig gyorsulna picit és egyre hatékonyabban használná ki a rendszer erőforrásait.
Sokat nyúzom a rendszert, sok mindennel foglalkozom. Egyszerre 8 munkaterületen sokszor több tucat programot használok. Ubuntu alatt kb. 5 nap alatt többször kellett terminált használnom, mint Arcon egy hónap alatt. Továbbá döbbenetes, hogy több hónap használat után nem is emlékszem utoljára mikor kellett egy probléma miatt böngésznem a netet és a fórumokat nyálaznom órákon keresztül… Ubuntu alatt ez a heti rutin része volt sajnos...
És még sorolhatnám a pozitívumok sokaságát, rengeteg van. Ég és föld a különbség egy Ubuntu és egy Arco között, az Arco javára óriási a pozitívum.
Ne haragudjatok a hosszú hangvételért. Csak szerettem volna számotokra és az esetlegesen erre járó olvasók számára felhívni a figyelmet erre a számomra eddig tökéletes disztróra és kicsit népszerűsíteni.
Köszönöm.
Kitartás.
U.I.2.: attól, hogy nem írunk gyakran hozzászólásokat, még itt vagyunk. És habár ritkábban jelennek meg cikkek, hírek, azért még nem adtuk föl a reményt és követünk Benneteket! :-)
:)
Szia Freel!
Engedd meg kérlek, hogy a három hozzászólásodra egyben válaszoljak.
Még annyit elmondhatok, hogy a partnercég, akivel szorosan együtt dolgozunk nem magyar és a frissítés elmulasztásáról sem magyar vezetőség döntött. Sőt épp ellenkezőleg: magyar oldalról támogatást kaptunk.
A frissítések halogatása nagyon rossz döntés volt, ez tény és én is a folyamatosság mellett vagyok. De hogy kontextusba helyezzem a dolgokat: érdemes tudni, hogy nagy cégeknél menedzsment szinten születnek az ilyen döntések, mert végső soron ők tartják a hátukat azért, ha valami félremegy. Nem mondhatják az ügyfélnek, hogy Gipsz Jakab cseszte el, mert rosszul paraméterezte a yum upgrade-et. Ehelyett az van, hogy JohnDoe Ltd. karbantartása miatt állt a rendszer három órát. Én egy elég nagy cégnél dolgozok, így egy nagyobb bakinak nyoma van a Facebookon, Twitteren, rosszabb esetben akár az újságokban is.
Minden frissítés esetén van valamekkora rizikó, még akkor is, ha az csak bugfix verzióra történik. Nyilván, kell csinálni mentést, kell csinálni a rendszer aktuális állapotról egy pillanatképet és még elég sok mindennel lehet védekezni egy hiba ellen. Be lehet vezetni un. kanári módszert, hogy a felhasználók csak n részét engedjük az új rendszerre és figyeljük a hibákat. De a legkörültekintőbb óvintézkedések ellenére sem lehet kizárni minden változót egy frissítés során. Ezért ha a vezetés ezt a rizikót nem vállalja be, akkor nincs frissítés és pont.
--
Nagyon örülök annak, hogy a mi hatásunkra kezdtél egy Linuxszal foglalkozni, annak pedig még jobban, hogy megtaláltad az a disztribúciót amivel igazán elégedett vagy! Gratulálok hozzá! :)
Köszönjük hogy olvasol bennünket! :)