Elvitel: Eric Kavanagh házigazda Robin Bloorral, Dez Blanchfield-rel és az IDERA-kkel, Bert Scalzo-val tárgyalja az elérhetőséget.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Hölgyeim és uraim, üdvözlet és üdvözlettel még egyszer. Szerdán négy óra van a keleti idő szerint, és ezek a napok csak egy dolgot jelenthetnek, ha az adatvilágban vagyunk: ismét a Hot Technologies számára! Igen valóban.
A nevem Eric Kavanagh, én leszek a házigazda a showban. Úgy tervezték, hogy kitalálja, mi meleg, mi történik odakint, mi a hűvös dolog, amelyet a vállalkozásban használnak, és természetesen az egész, az egész mezőben tevékenykedő tevékenység alapja, az adatbázis. Tehát az adatbázis védelméről fogunk beszélni. A pontos téma: „Védje az adatbázisát: Magas rendelkezésre állás magas igényű adatokhoz.” Tehát van egy dia a valódi sajátjairól. És elég rólam, rám üt, @eric_kavanagh.
Először is, ez az év forró, az adat forró, a nagy adat nagyon forró, de valójában még mindig szélsőséges. A csúcstechnológiával foglalkozó vállalatok többsége manapság nagy adatgyűjtést hajt végre, a legtöbb kenyér- és vajszervezet a világon ott van, továbbra is használnak tradicionális adatokat, és ha nagy az igény az adataira, akkor azt szeretné biztosítani, hogy elérhetőek legyenek, mert amikor a rendszerek lemerülnek, amikor az adatok elérhetetlenek, akkor boldogtalan ügyfelekkel, boldogtalan kilátásokkal jár, ügyfelek cseréje, mindenféle dolgok, partnerek, stb. boldogtalanok lesznek. Tehát ezt nem akarja.
Tanulni fogunk a mai üzleti élet legjobbjai közül - Dr. Robin Bloor, a mi adatbázisunk szakértője körülbelül három évtizedig működik. Dez Blanchfield, aki ezt már hosszú ideje csinálja, de amikor nagyon fiatal volt, és Bert Scalzo az IDERA-ból, aki valóban eléggé az adatbázis fekete öve. Tehát ne tartsa vissza az embereket, tegyen fel kérdéseket - ez az esemény nagy része az Ön számára, ha jó kérdéseket tesz fel és jó válaszokat kap, tehát a csevegőablakon vagy a konzol Q és A komponensén keresztül.
És ezzel átadom Robin Bloornak - vegye el.
Dr. Robin Bloor: Oké, hadd kattintson rá, és megnézem, mozog-e. Nem fogok külön az adatbázisról beszélni. Arra gondoltam, hogy tudod, mivel az első bevezető bemutatóomat tartom, ezért a várt szolgáltatási szinteken és természetesen a rendelkezésre álláson fogok beszélni, amely az üzlet, amely a mai show témája.
És a kérdés az, hogy tudja: „Valójában mi a rendelkezésre állás? És milyen szerepet játszik abban, hogy manapság az emberek adatközpontokat működtessenek? ”Egy dolog, amit észrevettem - ezt valójában valamikor a 90-es években észrevettem - egy webhelyen dolgoztam, és a felhasználók panaszkodni kezdtek, mert 15 éves korukban nem működtek. percek.
És azért volt érdekes, mert a CTO vagy bárki, aki az informatikáért felelős volt, valójában egyike azon kevés helyeknek, ahol azokban a napokban ténylegesen meghatározták a szolgáltatási szintet, és 15 percig tartó lehallgatás nem sértette senki szolgáltatási színvonalát. Azt hiszem, valójában két órán keresztül szabadon lehet. Nem az volt, hogy nem lehetett használni, csak az volt, hogy nem tudta megkapni és fogadni, mert a kiszolgáló ki volt állva. És ez felhívta a figyelmet arra a tényre, hogy azóta észrevettem az előrehaladást, hogy minden csak felgyorsul, és ugyanúgy teljesíti a felhasználók elvárásait, és ez olyan helyzethez vezet, hogy az embereknek három szolgáltatási szint lehet, de gyakran panaszkodni fog, amikor a szolgáltatási szinteket ténylegesen nem sértik meg.
Tehát a szolgáltatási szintek meghatározása, csak annyit kell adni - nos, ez pontosan attól függ, hogy miről beszélsz a szolgáltatási szintek vonatkozásában. IT-ről vagy IT-alkalmazásáról beszéltünk. Általában a teljesítmény, a rendelkezésre állás és a metrikusság alapján határozza meg - más szavakkal, nem igazán határozhatja meg a szolgáltatási szintet, ha nem tudja megmérni, tehát általában van valamilyen mérés, és általában a válaszidőkre, az egyes tranzakciókra és a a rendszerek elérhetősége egy adott időtartamra, és mintegy 1994–1995 előtt igazán ritka volt, hogy a rendszereknek normál munkaidőnél hosszabb ideig kell rendelkezésre állniuk. Tehát mondjuk reggel nyolc reggel hat óráig este, hogy normál időtartamot biztosítsunk - és az emberek rendszereket építettek, és így, és ez azt jelentette - véleményem szerint, különösen az adatbázis esetében -, az adatbázist konfigurálhatja egy meghatározott módon és a kötegelt ablak zsugorodni kezdett, egyes rendszerekben, majd más rendszerekben újra felmerült a gondolkodás iránti igény, majd megkaptuk a kiszolgálást vagy az architektúrát, amely függőségeket kezdett létrehozni azon rendszerek között, amelyek korábban nem voltak függőek egymással, ami még rosszabbá teszi. Megszorítottuk a rendszerek rendelkezésre állását.
Arra a következtetésre jutottam, hogy amikor a rendelkezésre állásról beszélünk, ez magában foglalja a biztonsági mentést és a helyreállítást, és magában foglalja - olyan, mintha nem csak a rendes elérhetőség lenne, amiről beszélünk; sokféle módon lehet egy alkalmazást megbukni. Tudod, hardverhiba vagy adatbázishiba fordulhat elő, szoftverhiba fordulhat elő, és rengeteg különféle faj van ezekből a dolgokból, és amikor ez bekövetkezik, képesnek kell lennie arra, hogy helyreálljon, és ezért vissza kell térnie fel a rendszereket. Tehát szükség van a rendszer biztonsági mentésének valamilyen sémájára, és manapság sok helyszínen is szükség van a katasztrófa utáni helyreállítási képességre, ha egy egész épület felrobbant. És olyasmit, amit érdemes megemlíteni itt, és egy perc alatt megpróbálom kibővíteni ezt, de az üzleti folyamatoknak szintén van szolgáltatási szintjük, és valójában az üzleti folyamat olyan szolgáltatási szintje, amely az üzleti szempontból igazán fontos. IT-nek csak meg kell tennie a részét és bármilyen megállapodás szerint.
Az IT-szolgáltatási szintek rendszerint kiegészítik az üzleti folyamatok szolgáltatási szintjeit, de ugyanúgy, mint 15 évvel ezelőtt valóban meglehetősen ritka volt, hogy bármely szervezet jól definiált szolgáltatási szintekkel rendelkezzen, továbbra is elég ritka, hogy a szervezetek jól definiált szolgáltatási szinteket biztosítsanak az üzleti folyamatok számára. . Ez valami, ami most történik; ez nem valami, ami hosszú ideje zajlik.
Ez a gyorsulás és az időbeli akadályok, csak érdemes megemlíteni az időbeli akadályokat. Fokozatosan belépünk az eseményfeldolgozó világba, és ezért fokozatosan átkerülünk a valós idejű világba, és ezért fokozatosan áttérünk a rendelkezésre állásra, hogy a 24 és 7 közötti követelményeknek megfeleljenek, és ez sok rendszer számára nehéz. nehéz elérni. Vagy nagyon drága, vagy bizonyos esetekben valószínűleg meg kell változtatnia a rendszereket, akár át is költöztetnie egy másik adatbázisba, az általunk használt adatbázis-szoftver másik verziójába.
Ugyancsak ezek az időbeli akadályok - és ezeket mindig szeretem megemlíteni, amikor csak esélyem van - ezek olyan időkorlátok, amelyekbe bevesszük alkalmazásunkat; az alkalmazások a lehető leggyorsabbak lehetnek, amikor a szoftver beszél a szoftverrel. Bizonyos helyzetekben valójában nincs elfogadható licenc, a lehető leggyorsabban akar lenni, és olyan üzleti helyzetekben, mint például a piaci helyzetek, amikor a vételi megbízással jövevény másodszor rosszabb árat kap, mint valaki ki az első, és ezért a szoftver sebessége valóban számít.
De tudod, az alábbiakban ismered azt, hogy amikor valójában emberekkel vagy - ha kölcsönhatásba lépsz velük - a legjobb válaszidő, amelyet valójában elvárhatnak tőled, a másodperces tized, mert ez az emberi válaszidőről szól. Nem kell ennél gyorsabban mennie, mert az ember egyébként nem veszi észre. 1,1 és négy másodperc között van egy olyan várakozási idő, amelyet az emberek általában elviselnek, de amint körülbelül négy másodperccel elmúlnak, elkezdenek valami mást csinálni, és ezért valóban egy szakaszos tevékenységet folytatnak.
Tehát láthatja, hogy bizonyos időkeretek, valamint a nap, a hét és a hónapok azokban a dolgokban, amelyekben a kötegelt viselkedésnek van értelme, és ezért nem vagy az eseménykezelő világban, ezért a rendelkezésre állás valójában nagyon eltérő lehet attól, amire szüksége van hogy tudjon nyújtani. De amint a rendezvényvilágban tartózkodsz, akkor 24 órás elérhetőség van, és a technológia változása tényező, mivel a technológia gyorsabban halad és előfordulhat, hogy a rendelkezésre állás nem növekszik; csak úgy marad, ahogy van.
Ez a bonyolultság rétege, és nem akarok erre mélyebben belemenni, csak tudod, három dolgot kell fontolóra venni itt. Van szolgáltatási szintű infrastruktúra, ez a vertikális tengely, majd egy adott alkalmazás szolgáltatási szintje, majd egy üzleti szolgáltatási szint, és ezek egymástól függenek, és ezeket figyelembe kell venni ha valójában egy érzékeny környezet megteremtésére törekszik, ahol alapvetően a szolgáltatási szintek teljesülnek.
Akkor az alsó sarokban van, amely csak ábrázolt adatbázisok, de bármit megtehet a rendszerben, tudod, hogy megvan a nem állandó konfiguráció, ami azt jelenti, amit mond: soha nem fog megállni. Megvan a forró készenléti helyzet, amelyben valamilyen módon vagy eltérő módon lehet elérni azt, de egy vagy másik módon, ha egy adatbázis meghiúsul, forró készenléti üzemmódra vált, és nagyon kevés a késleltetés időben arra a pontra, ahol a felhasználók valószínűleg észreveszik, de nem sokat észrevennének.
A meleg készenléti állapot inkább hasonlít a 20 perces átállásra, ahol mindenki felhívja az ügyfélszolgálatot, és harapja az ügyfélszolgálatot, miközben az adatbázist készenléti állapotba kapcsolják. Ezután van egy újraindítási helyzet, ahol nagyon hosszú időt vehet igénybe. Érdemes megjegyezni, hogy az adott alkalmazás vagy bármely adatbázis bármelyik helyzetben lehet, attól függően, hogy mi történik valójában, és hogy mi az alkalmazáshoz szükséges szolgáltatási szint.
Ebből csak szeretnék rámutatni a komplexitási görbére. A bonyolultság a csomópontokból és a kapcsolatokból, a függőségekből fakad. A világban, amelyben élünk, a bármihez kapcsolódó csomópont és kapcsolatok száma folyamatosan növekszik, tehát az ilyen jellegű görbe felé haladunk. Ha megnézheti, hogyan növekszik a bonyolultság, és hogyan csökken az idődimenziók, akkor tudja-e a rendelkezésre állási szinteket, vannak-e időbeli célok, valószínűleg csökkennek-e?
És a természetes evolúció tehát a folyamatos működés felé irányul, ami természetesen a legdrágább - legalábbis tapasztalatom szerint - a legdrágább konfiguráció, amelyet létrehozhat. Ilyen módon úgy, hogy minden erre gondolkodó szervezetnek tényleg nem csak arra kell gondolkodnia, hogy mi történik most, hanem mi fog történni a jövőben.
Talán az utolsó megjegyzésem, hogy a szolgáltatási szintek kezelése folyamatos tevékenység; ez nem valami, ami tudod, hogy van egy projekted, megcsinálod és vége. Nem az, mert a dolgok csak változnak. Ezt követően átadom a labdát Deznek.
Dez Blanchfield: Köszönöm Robinnak. Szeretem a nyitó csúszdát. Nemrégiben végeztük el a filmet, azt hiszem, ez a „Finding Nemo 2” film. Nemo volt a rendelkezésre állás kilenc formában keresve, ami szerintem nagyon aranyos volt. Mindig kemény cselekedet követi. Amikor az üzemidőre, a rendelkezésre állásra és a nagy teljesítményre gondolok, az első kép, amelyre eszembe jut, mivel a Salamon-szigeteken nőttem fel a vulkánok és az Egyenlítő mellett, egy vulkán repül ki az adatközpontban; van ez a kép, amit mindig a fejemben gondolok, hogy ez történhet akkor, ha valami felrobban. Ez a kép a szép hegyről. Etna, Szicília északkeleti sarka, közvetlenül Catania mellett.
Ennek az a megközelítésem, hogy beszélgessek veled, és adj neked egy pár elvitelt ugyanazon a szinten, amit rendszeresen ülök egy tanácsteremben a C-lakosztályokból és az üzletvezetőkből, azzal a céllal, hogy beszélgessünk arról, hogy mi befolyásolhatja szervezetét kereskedelmi vagy műszaki szempontból, valamint a mérnöki típusokat.
Gondolkodnunk kell és hogyan - mit veszünk ettől, és hogyan kell majd megválaszolnunk néhány kihívást, amelyekről beszélünk, amikor a magas rendelkezésre állásról és az üzemidőről beszélünk, különösen az automatizálás és a platformok körül.
Tehát a kezdetben feltett kérdésünk: mit értünk valójában az adatbázis-rendszerekről és az adatbázis-platform elérhetőségéről? Mit jelent valójában azt a tényleges kihívást beszélni, hogy valamely szintet elérhetővé tegyünk, ahogyan Robin beszélt a szolgáltatási szintű megállapodás telepített térképén, mire valójában szükségünk van és akarunk?
Tehát a mai valóság az, hogy - és valójában itt egy pár csúcstalálkozó valóság van a fejemben - ma minden ténylegesen adatbázis-vezérelt. Nagyon kevés olyan rendszer épül fel, amely ma épül és oly módon épül fel, hogy a cucc csak fájlokba kerül, vagy valamilyen lapos fájlnapló; Mindig minden adatbázis alapú. Ennek eredményeként meg kell szüntetnünk azon gondolkodást, hogy ezek az adatbázisok, a különféle rendszerek, alkalmazások és eszközök rendelkezésre állnak-e ezektől, és támaszkodni rájuk azon szolgáltatások nyújtásában, amelyeket nyújtunk, szállítunk, vagy fogyasztunk. . És az egész infrastruktúra.
Valójában annyira, amikor a későn bekövetkező adatok nagy meghibásodására gondolunk, különös tekintettel a digitális bennszülöttekre vagy a felhős bennszülöttekre, néhány olyan társaságra, amelyik együtt jött, mint például az Uber és az Airbnb, és így tovább, valamint a kissé régebbi PayPals-okra. és a világ eBays-i - e szervezetek mérete és mérete csak a modern adatbázis-technológia és a modern felhőinfrastruktúra miatt lehetséges. E nélkül, a hozzáadott lehetőségek nélkül egyszerűen nem léteznének. Képzeljen el egy forgatókönyvet, ahol csak 9:05 és 9:25 között lehet eljutni az eBay-re, mert a nap hátralévő részében nem volt elérhető, mert iCloudot vagy biztonsági másolatot próbált készíteni, vagy valami ilyesmit, csak nem lenne működött.
Tehát, és vannak más kulcsfontosságú területek is, amikor a mindennapi életünkre gondolunk, például: lakossági és banki, pénzügyi és légitársaságok, stb. A nagy ipari csoportok, mint például a repülés logisztika, a szállítás, a kormányzat egésze, a nemzetbiztonság és a rendőrség stb. Mindezek az iparágak, mind a piaci szegmensek, mind ezek a testületek, csoportok attól függ, hogy környezetük felkészül-e és működik-e.
Tehát, szem előtt tartva, van még egy másik figyelmeztetés, amire gondolnunk kell, a másik elvitel, amelyre hagyni akarlak, hogy elgondolkozzon, és hogy a világunk most az, amit „mindig bekapcsolok” -nak hívok. Állandó kapcsolatban állunk, és ezt a témát rendszeresen meg fogod hallani, és meg fogom ismételni, és megismételni. Most egész nap, minden nap okostelefonok vannak a kezünkben. Nem kapcsoljuk ki őket, az ágy mellé helyezzük őket, mindig ébresztőórákként használjuk őket, kamerákként és fényképeket készítünk, ezeket a képeket felhőbe tolják.
Mindig bekapcsolódva vannak, állandóan összekapcsolt mentalitásukba. Valójában van egy érme kifejezés, amelyet szeretek használni, vagyis most egyfajta Fitbit generáción élünk, amelyben mindent mérünk, mindent figyelünk, és be kell jelentkezni, és ez megy valahova.
És van még egy másik mondat, mellyel elhagylak téged, vagyis minden idők kilenc órája van. Ez egy 24/7/365 világ, amelyben élünk. A Föld folyamatosan forog a Nap körül, és egy bizonyos ponton és időben, a nap minden órájában, kilencedik órakor. És ez azt jelenti, hogy az emberek kiszállnak az ágyból, és megpróbálnak dolgokat csinálni, dolgokat vásárolni, felszerelni stb.
Tehát mit értünk, ha a magas rendelkezésre állásról beszélünk? Nos, ez egészen nyilvánvalónak hangzik, amíg el nem merülsz a részletekbe. Tehát, tudod, amikor arra gondolunk, hogy „OK, mit jelent a magas rendelkezésre állás?” Nos, a valóság az, hogy nincs ezüstgolyó. Ez meglehetősen összetett koncepció, mivel Robin az általa említett néhány témával kapcsolatban állt, mint például a rendelkezésre állás mérése és a szolgáltatási szintű megállapodások. Olyan dolgokra térképezzük fel, hogy vannak ezek a kérdések, van-e uptime? Aggódunk-e olyan dolgok miatt, mint például az, hogy öt kilencre hívunk, és ezt egy perc múlva bemegyek. Fontolja meg magunkat azzal, hogy mi van szolgáltatási szintű megállapodásainkban? Például a szolgáltatási szintű megállapodások alatt késésekre gondolok, a szolgáltatási szintű megállapodások hárombetűs rövidítése manapság egyre kritikusabbá vált.
Ahogy megy keresztül ezen a teljes előzetes folyamaton, és önálló házigazdaként működik ki, hogy harmadik fél adatközpontjaiba kiszervezzék és kiszervezzék a kezelt szolgáltatásokat, és most egészen a felhőig megyünk. És ha a felhőről beszélünk, akkor a valóság valójában csak mások számítógépei. És ez azt jelenti, hogy nem működteti az infrastruktúrát, nem a rendszereket, és mindig a felhőt nem futtatja. Ön platformként felállított infrastruktúrát végez, tehát ez még fontosabb az értékesítési szolgálatban. Képzelje el például az értékesítést, ha tudja, hogy nem érinti meg az infrastruktúrát, csak bejelentkezik egy webes felületbe.
Tehát az egyetlen olyan mechanizmus, amely a felhő és bármilyen formában kihelyezett infrastruktúra ellenőrzésének világában van, azaz a szolgáltatási szintű megállapodások, ez az egyetlen mechanizmus, amelyet megvan, és ha az emberek nem találkoznak a telepítéssel, akkor akár büntetések és a pénzösszeg csökkentése, amit fizet nekik, vagy csak nem fizet nekik.
Tehát ez visszahozza az egész kihívást, tudod, hogyan tudjuk kezelni a magas rendelkezésre állást? Hogyan kezeljük az elérhetőséget, ha nem az Ön infrastruktúrája - például az SLA-ról szól. Ha ez az Ön infrastruktúrája, vagy akkor is, ha valaki más infrastruktúrája tervezési szempontból. Beszéltünk a terheléselosztásról a modelltudomány számára, hibatűrési formatervezési szabadalom?
Futtat aktív aktív vagy aktív készenléti módot az architektúráiban? Van több kiszolgálója, több tárolóplatformja? Hogyan működnek ezek a tárolóplatformok? Ismétlik-e egymást, tükrözik-e egymást? RAID-et futtat? Milyen típusú RAID-t futtat redundáns tároláshoz? RAID-et futtat lemezszinten? Objektumtároló platformot futtat, amely replikálja a modellmeghajtókat, a modellrendszereket és a meghajtókat? N plusz egy-egy minden apró infrastruktúra-darabért? Felvesz egy újat, és ugyanabban az adatközpontban vagy másik adatközpontban található? Építettél olyan formatervezési szabadalmat, amely például egyetlen értékesítési pontot nem jelent?
Mindezek az alapvető dolgok, most egyszerű fogalmaknak tűnnek, de ha belemegyek ezekbe a dolgokba, nagyon-nagyon részletesek. Amikor a rendelkezésre állásról beszélünk, akkor mindig a kilencről beszélünk. És mit értünk kilencnel? Mindannyian hallottunk erről, de gondolkodjunk csak azon, hogy mit gondolnak egy percig, és miért fontosak.
Tehát egy kilencről beszélünk, ami elérhetőségünknek csak 90 százaléka. Tudom, hogy ez nagyon magasnak hangzik. Tehát, ha 24 és 7 közötti beszélgetést folytatunk 365-re, ha csak egy évre nézzünk, amikor egy kilencnél beszélünk, ami az idő 90 százaléka, akkor ez harminchat és fél nap leállást tesz lehetővé évente. Csak kerekítsük meg egy hónap alatt.
Gondolj most olyan üzleti vállalkozásra, amelyen minden nap foglalkozunk - akár online banki, eBay, PayPal, akár olyan közösségi média platformokkal, mint a LinkedIn, vagy csak egy általános kiskereskedővel - mondjuk, mondjuk, szeretnék egy repülést lefoglalni, hogy napos Ausztráliából érkezzen az Egyesült Államokba. , boldog lennék, ha hetek múlva szeretnék Amerikába érkezni, ha a kedvenc légitársaságom harminchat és fél napig nem volt működőképes, mert szolgáltatójuk azt mondta: "Nézd, az idő 90 százalékát érjük el"? Természetesen nem akarom.
Ahogy felmegyél erre a modellre, két kilenc: 99 százalék. Nos, ez 3,65 nap lesz, nagyjából három és fél nap leállás az évben. Nagy ügy? Nos, ha a Fekete Péntek fut, és különleges akciókat futtat, és az emberek csak e pár nap alatt vásárolhatnak.
Három kilenc évente csak 8,7 óráig válik, de évente akár 8,7 óráig is korunk nyolc órája egymást követő megállás nélkül. Nos, ez a bankügyben és a pénzügyben, az egészségügyben - ha kórház, Nos, ami életbe kerülhet. Ahogy felmászsz, négy kilenc 52 perc, öt kilenc öt perc és hat kilenc alapvetően 30 másodperc. A hat kilenc rendkívül magas, és ahogy felmegyünk ezen a létrán, miközben felmész a kilencedik karácsonyfára, minél több kilenc felmegy, annál nehezebb a tervezés, a környezet és a platform. Nehezebb ezt a szolgáltatást nyújtani, és ha gondolkodik azon idő csökkentéséről, amelyet a biztonsági mentések futtatásához, az adminisztrációhoz, a javításhoz, a karbantartási ablakokat bármilyen formájú leálláshoz - az összes nem triviális kihíváshoz - csökkentették, és mindez ténylegesen az áramkimaradások százalékára csökken.
A kulcs itt, amit szeretnék mondani, az, hogy nincs ezüst golyó, amint azt már említettem. Ami a rendelkezésre állást illeti, nincs „mindenki számára megfelelő”. Lehet, hogy van egy adott típusú formatervezési szabadalma, amely megfelel a legfontosabb iparágaknak. Ugyanazokkal a kihívásokkal kell szembenéznie minden banknak. Egyesek lehetnek lakossági bankok, mások prémium bankok. Egyes bankok a kereskedelemre és a befektetésekre, a vagyonkezelésre összpontosíthatnak. Vannak, akik tisztán fogyasztók. Néhányan csak internetes forgalmazást végezhetnek, sőt még nem is mondhatják el beszédeket, és csak ATM-ekkel foglalkoznak készpénzkiadáskor. Tehát ezekben a forgatókönyvekben, még a bank- és vagyonkezelési, valamint a pénzügyi szolgáltatási ágazat egészében, mindegyiküknek továbbra is megvan a sajátos ízlése vagy dolga, amire szükségük van a rendelkezésre állás szempontjából.
Tehát, amikor egyszerűen angol nyelven gondolunk a rendelkezésre állásra, a rendelkezésre állás és a magas rendelkezésre állás keverékére - úgy gondoljuk, hogy ugyanazok, de valójában kréta és sajt. A rendelkezésre állás, egyszerűen angol nyelven fogalmazva, egy olyan idő mértéke, amely alatt a szerver vagy a folyamat normálisan vagy általában működik, a felhasználásukhoz kötődve. Ez azt jelenti, hogy hogyan írjuk le, hogy rendelkezésre áll-e vagy sem. Amikor a rendelkezésre állásról beszélünk, gyakran belekerülünk a gondolkodás csapdájába: „rendelkezésre álló formában nyújtom”, szemben az infrastruktúra biztonságának magas szintű rendelkezésre állásával.
A magas rendelkezésre állás, más szóval az egyszerű angol nyelven, az a forma, amellyel valamilyen eredményt megvalósíthat vagy elérhet, és elérhetõ az adatok elérhetõsége, különösen akkor, ha szinte minden alkalommal - évente 24/7/365 napon keresztül - ez a rendelkezésre állás elérhetõ néhány kilences. Mindig nem jelenti a 100 százalékot. Száz százalék gyakorlatilag nem lehetséges valós világban egyetlen környezetben sem. Nagyon nehéz egy operációs rendszer egyik kiszolgálója számára, amelynek adatbázis van, fut egy platformon, és egy alkalmazás képes kiszolgálni azt, és elvárhatja, hogy 100% -ban futjon. Tehát akkor elkezdünk gondolkodni a mintákon. Van-e redundáció, van-e több diák is, amelyeket meg kell replikálni? Akkor, ha egyszerű angol nyelven fogalmazza meg, érdekes, hogy mennyire különbözik a rendelkezésre állás és a magas rendelkezésre állás témája.
Arra gondoltam, hogy valóban egyszerű grafikus formába állítanám, csak hogy elképzelést adjunk nekünk arról, hogyan néz ki ez, amikor elkezdi felvenni a kihívást, hogy növeli a rendelkezésre állást a szolgáltatás uptime védelmében. A bal alsó sarokban van egy kilenc. Lefektettem az öt kilencöt, amelyekről általában beszélünk. A hat kilenc kissé felháborító. Ha öt kilencről beszélünk a bal alsó sarokban, körülbelül 35 nappal a leállás miatt, akkor olcsó és alacsony bonyolultságú környezetet próbálunk biztosítani, mivel számos olyan dolog van, amelyik kudarcot vallhat, és továbbra is teljesítse szolgáltatási szintű megállapodásait.
De amikor az alján balról jobbra haladsz, és eljutsz arra a pontra, ahol a képen több kilenc van, akkor olyan forgatókönyveket kapnak, ahol elkezdesz gondolkodni a rendszerek és platformok replikációjáról. Gondolkodnia kell az infrastruktúra különböző részeinek klaszterezésére és virtualizálására. Gondolkodnia kell a klaszterek földrajzi helyzetére, az adatközpontok több helyére, és át kell gondolni az iparágtípusra és a piaci szegmensre, amelyet megcéloz. Tehát milyen típusú szolgáltatási szintnek kell megfelelnie? Milyen szolgáltatást nyújt? Területek, amelyek valós idejű kártya-alapú szolgáltatások, amelyek a kommunikációról szólnak. Ez katonai szolgálat? Tehát ez a grafikon balról alulról jobbra megy és a görbén átjutva a költségek és a bonyolultság növekednek. Ahogy összetettebb és igényesebb környezetbe kerül, több kilencre lesz szüksége.
Például ez a grafikon nagyon hasonló dolgot végez: leírja a költségkomponens és a kívánt rendelkezésre állási komponens közötti történetet. Tehát a bal felső sarokban nagyon rendelkezésre álló komplex rendszereket ábrázolunk, és ha ezen rendelkezésre állás csökken, akkor annak költségei merülnek fel, ha nulla állásidő alatt állunk rendelkezésre. Tehát például, ha a bal oldali környezetben van olyan helyzet, ahol a dolgok nem működnek, pénzügyi veszteségeket szenvedhetünk. Jogi következményeink vannak, amelyek üzleti vállalkozás-stratégia szintű következményekkel is járhatnak.
Azt hiszem, mindenféle potenciálisan létezik erkölcsi kérdés a szolgáltatás előnyeinek megszerzése körül. Ha ez egy egészségügyi ágazat, és kezdik átjárni a leállás költségeit, az ügyfelekre gyakorolt hatást, az ügyfelek elégedettségének csökkentését, a személyzet termelékenységét, a felhasználói termelékenységet stb., Ezeket a dolgokat befolyásolja, ha gondolunk egy nagyon összetett, nagymértékben függő , rendkívül kockázatos környezet, ahol fennáll a kiesés és ennek következtében veszteség kockázata.
A jobb oldalon megpróbálunk olyan forgatókönyvet keresni, ahol nagy költségeket és tervezést fektetünk a tervezésbe, az intelligens megvalósításba fektetünk be. Befektetünk az emberek képességeinek és erőforrásainak biztosításába, és nagyra becsüljük a hálózat és a magasan megbecsült működési környezetet, valamint a hardvert és szoftvert. Magas rendelkezésre állást kapunk, de ez magas költségekkel jár. Tehát az optimális helyzetű lengő inga folt a közepén, ahol átjutnak, ahol kissé csökkentették a költségeket, és egyre növekszik az elérhetőség, amely csak kilencedik szintek között zsonglőrködik, és a magas rendelkezésre állás, amely folyamatos rendelkezésre állás, és ez örökké folyamatos kihívás, hogy találkozzunk, például mennyi pénzt hajlandó befektetni a kívánt szolgáltatási szint elérésére?
Van egy olyan témánk is, amelybe nem foglalkozom részletesebben, de csak azt akarom, hogy vegye el ezt, és gondolkozzon rajta. A tervezés meghibásodása közötti átlagos idő és a helyreállítási idő közötti különbség. Más szavakkal: a jobb minőségű infrastruktúrába, a jobb minőségű tervezésbe, a jobb minőségű hardverbe és a szoftverbe, valamint a jobb minőségű képzett személyzetbe és az erőforrásokba fekteti be a dolgokat, hogy tervezze és csökkentse a hiba közötti átlagos időt, azaz a szünet megtalálásához szükséges átlagos időt, szemben alacsonyabb beruházások az infrastruktúrába, az erőforrásokba és a tervezésbe, valamint a vak szabadalmakba, a nagy megtérülési képesség? Más szavakkal: ha valami eltört, akkor sok be kell dugnia. Ha valakinek van laptopja, és meghal, akkor van egy tartalék.Ön odaadja nekik, és 30 másodpercen belül belépnek. Ezek a pólus nagyon különböző végei. Az első azt a következtetést vonja le, hogy magas költségekkel és nagy beruházásokkal jár a mérnöki munka, hogy elkerülje a kudarcot, az alsó pedig azt mondja: „El fogom fogadni, hogy a hiba el fog jönni, tehát mérlegelni fogom ezt, és felkészültem a kudarcra. és gyorsan felépül. ”
Mint már említettem, ahol azt mondhattam: „A rendelkezésre állásom nem az Ön elérhetősége.” Tehát, amikor adatbázis-környezetekre és az infrastruktúra támogatására, az adatbázis futtatására, ennek védelmére és a magas rendelkezésre állás biztosítására van, valójában nincs egyablakos ügyintézés. . Mindenkinek megvannak a saját igényei és kívánságai. Tehát fel kell tennie magának ezeket az alapvető kérdéseket, amelyek nélkül hagyhat téged, és ez az: Mi lehet a szervezet számára? Nem csak a dollárról és a centről beszélek. Szerint arról beszélek, hogy mit biztosíthat forrásokból, időből és erőfeszítésekből, stb., Amennyire a rendelkezésre állás szintje képes nyújtani? Továbbá, mit támogathat vállalkozása? Tehát a jelenlegi képességek, a jelenlegi készségek, a jelenlegi infrastruktúra, a jelenlegi finanszírozás, amelyet fel lehet szerezni. Tehát érdekes egyensúlyt teremt az, amit valójában megengedhet magának, és amit támogatni tud.
Ezenkívül fel kell tennie magának a kérdéseket: Milyen készségekkel és technológiával rendelkezik a házban? Tud-e kiszervezni e kihívás egy részét? Tudod mozgatni a dolgokat a felhőbe? Ha az infrastruktúra-szolgáltatáson kívül a szoftverszolgáltatást is megkapta, akkor a verem nélkül marad, ahogy továbbmegy a veremnél. Tehát inkább fektessen be a platformokba és a szolgáltatásokba, és ne aggódjon az infrastruktúra miatt, vagy pedig a szoftvert szolgáltatási ajánlatnak tekintse, mert nem kellene aggódnia a platformon?
Milyen piacot és fogyasztót vagy vevőt szolgál ki? Úgy értem, ha telekommunikáció vagy, és valakinek fel kell vennie a telefont, és folyamatosan tárcsázási hangot kell kapnia, ez nagyon más kihívás, mint egy kiskereskedelmi üzlet kinyitása hétfő és péntek között, kilenc-öt óra között, és bezárás óra ebédidőben, mint egy sarokbolt fodrász. Tehát nagyon hosszú és kemény gondolkodást kell tennie, hogy ez működik, és mit jelent ez a szervezetének, mit kell nyújtania.
És aztán a zsonglőr az, ami a helyszínen található, mi a külső házigazda és potenciálisan a felhőben. Mint már korábban mondtam, ez az időbeli kihívásokból is származik. Tehát arra a végső kérdésre maradunk, hogy várom az IDERA barátait, hogy elmondják, hogyan kezelik ezeket a dolgokat, és ez a finom zsonglőr a kívánt és megkövetelt elérhetőség és a teljesítmény összeegyeztetése között, és mi az üzleti igényeidhez, és mi a piacának és a fogyasztóknak szüksége van.
És a valóság az, hogy nem jelent feat. Idõt, erõfeszítést és pénzt igényel, hogy átgondoljuk ezeket a dolgokat. És mindig az emberekbe való beruházásba és a készségek képességeibe, valamint a szoftverekbe és eszközökbe történő beruházásokba, amelyek automatizálják ezeket a folyamatokat, és ezeknek az embereknek a megfelelő eszközöket és megfelelő rendszereket biztosítják az emberek számára, hogy az életüket ne csak jobbá tegyék, hanem lehetségessé váljanak, mert a nagyon nagy méretű környezet figyelése és a és a nagyszabású környezetek kezelése gyakran meghaladja az egyéni emberi képességeket.
Tehát, ezt szem előtt tartva, remélhetőleg nagyszerű beszélgetést készítettem az IDERA-nál lévő barátaink számára, hogy megbeszéljék platformjukat és eszközeiket, és várom, hogy végül néhány nagyszerű kérdést feltehetek. És továbbadom.
Dr. Robin Bloor: Rendben. Bert, csak adtam neked a kulcsokat, vedd el.
Bert Scalzo: Köszönöm! Köszönöm, Dez és Robin. Folytatom az adatai magas rendelkezésre állásának témáját. És valójában nagyon sokat hasznosítok azon, amit Dez éppen beszélt. Tehát a választások, a kilenc, a kompromisszumok és a megfizethetőség. Megpróbálom ezt inkább az adatbázis adminisztrátorának vagy valamelyik árkokhoz közelebb álló személynek elmondani, hogyan néznék ki? Hogyan építik fel? És mit jelent ezek a választások?
Most megpróbálok adatbázis-diagnosztikussá válni. Például nem fogok rajzolni Oracle-specifikus vagy SQL-Server-specifikus megoldást, hanem rajzolok egy általános architektúrát, amelyet az összes adatbázis-gyártó kínál, és ehhez hasonlóan. Mindegyiket különböző néven hívják, de ez a közös választás egy típusa, és ezt szeretném megvizsgálni mind az üzleti, mind a technológiai szempontból, és hogy ez hogyan kapcsolódik az üzleti követelményekhez.
És azt szeretném kezdeni, hogy mi a legalapvetőbb ál-magas rendelkezésre állású megoldás, a tárolási szintű megoldások, a virtualizációs szintű megoldások és az adatbázis-szintű megoldások lehetőségeivel. Aztán szeretném bemutatni, hogy minden választás elérhető a felhőben is.
Tehát megint megpróbálom meglehetősen adatbázis-agnosztikus maradni. Most, a legtöbb dologról, amiről beszélek, tudom, hogy léteznek Oracle, SQL Server, MySQL, PostgreSQL. Vannak olyan harmadik gyártók is, akik olyan eszközöket készítenek, amelyek szintén további architektúrákat nyújtanak Önnek, amelyeket megfontolhat. És amint Dez csak mondta, senki sem a legjobb; minden attól függ. De van egy univerzális tény abban, amit meg fogunk vizsgálni, az, hogy mozgó alkatrészek lesznek, tehát összetettebbek és ezért költségesek.
Tehát mindannyian tudjuk, hogy az adatok fontos előnye. És mindenki tudja, hogy az adatokhoz való gyors hozzáférés mindig jó. De kritikus fontosságú az adatokhoz való megbízható hozzáférés. És amint a kilenc példájával beszélt, valóban megengedheti magának, hogy 36½ napos leállást kapjon? Fontos, hogy ezek az adatok mindig rendelkezésre álljanak. Így tehát a leállások vagyont fizethetnek, mind a bevételkiesés szempontjából, de még ennél is fontosabb az elveszített ügyfelek vagy az ügyfél goodwilljének elvesztése. Jó példát mutatok neked; ha egy adott webhely, ahol vásárolok, lassú, megpróbálhatok új webhelyet keresni, aki hasonló cikkeket árusít hasonló költséggel, és nem rendelkezik lassú weboldalakkal. Tehát nemcsak az ügyfél vesztesége, hanem az ügyféllel szemben fennálló goodwill is.
A hardver manapság sokkal olcsóbb, ezért egyre nagyobb igény mutatkozik a magas rendelkezésre állásra. És ismét: a felhőhöz vezet minket, amikor erre nézünk. És különféle szinteken kínálunk kínálatot: a tárolási szolgáltatók, az adatbázis-gyártók, a virtualizációs gyártók és most még a felhő-szolgáltatók is. Szóval, ami igazán érdekes a felhőnél, az az, hogy rajzoltam ezeket a csodálatos képeket ezekről az architektúrákról, amelyeket a felhőbe építhetsz, sokszor csak néhány jelölőnégyzet. És azt mondod: „Replikációt akarok a földrajzi régiók között.” Jelölőnégyzet. “A kulcsfontosságú hardverösszetevők replikációját akarom.” Jelölőnégyzet. És tehát, ha megérti a képeket, a felhőben néha csak néhány négyzetet jelöl meg, hogy elkészítse a képét, amely eszedbe jutott.
A legfontosabb dolog az, hogy milyen üzleti követelmények vonatkoznak a magas rendelkezésre állásra? Például csak egyetlen helyszínen kell aggódnom, vagy több oldalon kell lennem? Más szavakkal, lehet egy számítási központ, és nem érdekel, ha ez a központ offline állapotba kerül? Nem követelom meg, hogy üzleti vállalkozás több webhelyre terjedjen ki. Ez üzleti kérdés. Fontos tudni, hogy az üzleti vállalkozás hogyan érzékeli a válaszokat erre a kérdésre, mert ez általában meghatározza a költségvetést.
Most azt is szeretné lenni, hogy nézzen le a hibavédelem szintjére. Lehet, hogy áramkimaradás? Lehet, hogy egy alkatrész meghibásodása? Mint egy hálózati kártya vagy a HBA, rossz a gazda busz adapter. Rosszul megy a merevlemez? Tárolószekrény hiba? Számítógépes hiba? Vagy bizonyos esetekben ez webhelyhiba? Ez más, mint bizonyos esetekben webhelyhiba, mert maga a webhely offline állapotban van. Egy másik esetben előfordulhat, hogy a webhely jelentős része offline állapotban van, de az Ön szempontjából az egész webhely.
És aztán, amint Dezről beszélt, mi az elvárás, hogy újrakezdje a műveleteket? Ez üzleti kérdés. Ha az üzleti vállalkozás azt állítja, hogy képesnek kell lennie arra, hogy két percen belül újra tudja folytatni a műveleteket, akkor nyilvánvaló, hogy meg fogja határozni néhány ilyen képet, amelyet meg fogok mutatni, hogy működni fog, és néhány közülük nem lesz választható.
És egy másik kérdés, amely felmerül a magas rendelkezésre állás során, de gyakran az emberek elfelejtik feltenni a kérdést: "Hé, üzlet, ha történik valami, miközben közben egy tranzakciót dolgoztam fel, mit veszíthetek a rendszer újraindításakor?" Más szavakkal: ha el tudom hozni a rendszert két perc alatt, és elveszíthetek legfeljebb 10 másodpercet, mondjuk a repülés alatt álló tranzakciókat, ez elfogadható üzlet? És ez megint meg fogja határozni, hogy a vállalkozás mennyit hajlandó költeni erre, majd megint meghatározhatja, hogy mely képeket mutatom be vagy alkalmazni vagy nem alkalmazni.
Tehát kezdjük a legalapvetőbb ál-magas rendelkezésre állású megoldással. Ez valóban nem magas a rendelkezésre állás, de szeretnék ezzel kezdeni, mert ez arra készteti az embereket, hogy helyesen gondolkodjanak. Ha Ive szerverrel és tárolótömbvel rendelkezik, általában több hálózati kártyát, hálózati interfészkártyát teszek ebbe a kiszolgálóba, és összekapcsolom őket úgy, hogy ha egy hálózati kártya meghiúsul, akkor még mindig fel vagyok. És ugyanazt csinálok a gazda busz-adapterekkel, többutas útvonalakkal, amelyek különféle kapcsolókon keresztül vannak, így többféle módon juthatom el a tárolómhoz. És kaptam egy univerzális tápegységet, és ismétlődő vezérlőket kaptam a tárolótömbömbe, és talán Ive csinált valamit, mint például a RAID 10 a lemezeimmel. Más szavakkal, ebben a képen az Ive többszintű módon megakadályozta az egykomponensű hibákat. Tehát nem vagyok kötelező a NIC-re, a HBA-re, a vezérlőre vagy a kapcsolóra.
De ha észreveszi, a kiszolgáló piros és a tároló tömb piros. Még két terület van, ahol ha kudarcot vall, ha kiszolgálóm elmegy, halott vagyok, ha tároló tömbszekrényem megy, halott vagyok. Tehát, bár ez nem igazán magas a rendelkezésre állás, elkezdi látni és megnézni a képet, és azt mondja: "Olyan képet akarok, ahol nincs vörös". És valóban ezeknek a képeknek a célja az, hogy a helyes irányba mutatjunk.
Tehát az első dolog, ami történik, mint egy DBA, mindig szeretném, ha a nagy rendelkezésre állású megoldást adatbázis-megvalósításként állítanánk, de előfordulhat, hogy elérhető, hogy tárolási megoldásként is megtehető, vagy esetleg hogy tárolási szintű replikáció lehet. Bal oldali esetben virtualizáltam a tárolást. Ami történik, az Ive RAID 0-at kapott két külön tárolószekrényben a lemezeimhez, de az Ive RAID 1-et kapta a két különféle tárolószekrénybe. Más szavakkal, valójában most egy tárolószekrény meghibásodhat, és nem vagyok halott. Tehát jobb, mint az előző kép, mert az előző képen - ne feledje, mind a vörös volt a kiszolgálón, mind a vörös a tároló tömbön -, és most egy apró fejlesztést hajtottunk végre, most már nincs vörös a tároló szintjén, használt— tároló virtualizáció megoldotta ezt a problémát.
Egy másik módszer, amellyel megteheti - és nem minden gyártó biztosítja ezt - az lehet, hogy tárolási szintű replikációt végezhet. Nem beszélek az adatbázis replikációjáról, vagyok arról, hogy a blokk I / O replikációját tárolom. És ezt meg lehet tenni a tárolási szinten. És így ismét, most a jobb oldalon van egy másik kép, ahol az alsó részből eltávolítom a vörös oldalt, mert tároló replikációt használok.
Tehát ez egy másik kép, amely elérhető, vagy nem. És az a személy, aki ezt kezeli, lehet, hogy a tárhely rendszergazdája, nem pedig az adatbázis adminisztrátora. Szeretem ezt felhozni, mert néha az emberek azt gondolják: "Ó! Magas rendelkezésre állás, ezt a problémát a DBA-nak kell kezelnie." Ez nem mindig igaz; ebben az esetben a tároló adminisztrátora lehet.
Most pedig lehetséges szerver-virtualizációt hajthatunk végre. Most, ha emlékszel, az első képen piros volt a kiszolgálón és a vörös a tároló tömbön. Lehet, hogy ebben az esetben a virtualizációt használva áthelyezhetek, és bizonyos esetekben ez az áthelyezés valamilyen meleg áthelyezés, és egyes esetekben valójában még forró áthelyezés is lehet. Egyes virtualizációs vagy hipervizorok képesek virtuális gépeket repülés közben mozgatni. És néhány adatbázis könnyedén elfogadja ezt a mozgást repülés közben. Most ismét nem minden hipervizor biztosítja ezt, de ez a megoldás egyik lehetséges szintje. Most azt tettem, hogy a felső szerverek nem lesznek vörösek, de még mindig megvan a megosztott tároló tömb, és gondolom mi, ez a megoldás az adatbázis-adminisztrátor és a virtualizációs rendszergazda közös erőfeszítése lehet. Vagy akár csak a virtualizációs rendszergazda is lehet, attól függően, hogy az áthelyezés milyen szintjét támogatja az adott hipervizor és az adatbázis.
Ha azon gondolkodik, hogy „Hű, mit jelent ez az áthelyezés? Adj nekem egy konkrét példát. ”Például virtuális gépben, ahol a VMotion segítségével virtuális gépet áthelyezhet egyik gazdagépről a másikra, és leállások nélkül megteheti. Most egyértelműen az előző képben még mindig volt vörös szín. A tárolást továbbra is egyetlen hibapontnak tekintették. És így továbbmegyünk a következő megoldáshoz, amely az, nos, hadd kombináljam a tárolást és a szerver virtualizációját.
Most ebben az esetben ismét a tárolási adminisztrátorok és a virtualizációs adminisztrátorok építhetik fel ezt a megoldást, és most megnézhetik: van egy kép, amelyben nincs piros szín. Nagyon magas a rendelkezésre állásom, mert át tudom helyezni a virtuális gépet vagy a futó alkalmazást vagy az adatbázist az egyik kiszolgálóról a másikra, és virtualizációm van a tárolótömbömben azáltal, hogy két külön tárolótömbön RAID 1-et hajt végre. Többféle javítást végeztem a kapcsolók és a HBA-k mellett.
Tehát most már építettem egy HA rendszert, és elsősorban nem az adatbázis szintjén csináltam. Más szavakkal, ugyanazt a dolgot más technológiákkal is felhasználtam. Szóval, ez egy megoldás. Aztán bejutunk az úgynevezett megosztott tároló méretezhető klaszterbe. Valójában nem egy HA megoldás, de szeretném megmutatni a képnek.
És ami itt történik, hogy két kiszolgálónk fut egy adatbázist, és ezt egyetlen adatbázisnak tekintjük. Ez nem két különálló adatbázis; nem olyan, mint a mester és a rabszolga, a forró és a hideg, vagy az aktív és a készenléti állapot. Vagyis mindkét csomópont együtt működik, hogy egy logikai adatbázist hozzon létre. És tehát mi történik, ha egy adott csomópont meghibásodik, akkor még mindig fennállsz. Tehát védi a kiszolgálószintű meghibásodásoktól, és ezt alapvetően a csomópont erőforrásainak szétosztásával hajtja végre, ha akarod, de továbbra is fennáll az egyetlen pont, amikor a lemezt fentről elmulasztja. Tehát ez egy megosztott tárhelyű méretezhető fürt, és az Oracle ezt a Real Application Cluster-t vagy RAC-ot hívja.
Most egy másik megoldás a megosztott tároló feladatátvevő fürt használata. Tehát bal oldalon van egy aktív csomópontom, jobb oldalon passzív csomópont van, köztük szívverés. Van egy megosztott tároló tömb, és ez kritikus; neked kell. És alapvetően az történik, ha az aktív csomópont problémákat tapasztal, a passzív csomópont átveheti az irányítást. Vannak ezzel kapcsolatos engedélyezési problémák. Egyes adatbázis-gyártók lehetővé teszik a passzív csomópont korlátozott licencű, meghatározott időtartamra történő megszerzését. Más esetekben teljes másolatú engedélyezéssel kell rendelkeznie. Minden az adatbázis gyártójától függ. De mindannyian támogatják ezt a képet, azaz ha az egyik csomópont leesik, a másik csomópont átveheti az irányítást.
És tipikusan ez egyike azoknak a forgatókönyveknek, amelyekben az aktív csomóponttól a passzív csomópontig haladva valószínűleg a legtöbb adatbázisban - nem mindenben - valószínűleg el fogja veszíteni a repülési tranzakciók. Ezután megismerjük azt, amit az adatbázis-adminisztrátor valóban megnézhet, azaz az adatbázis replikációt, és kétféle módon lehet az adatbázis replikációt végrehajtani.
Van fizikai replikáció, és ami fontos, a kép közepén láthatja a zöld csillaggal, hogy a replikációt az adatbázis hajtja végre, de hasonlóan a tárolási szintű virtualizációhoz a blokkban történik. szint. Tehát megismételjük az aktuális blokk I / O-t az aktív csomóponttól a csak olvasható vagy passzív csomópontig. És ezt fizikai replikációnak tekintik.
Most hadd menjek a következő diához, mert ez majdnem azonos és logikus replikáció, és az egyetlen dolog, ami megváltozik a képen, az a közepén, hogy az I / O blokk fölé helyezése helyett lényegében a napló fölé kerülünk fájlok az abban található SQL parancsokkal. Tehát más szavakkal: nem a fizikai I / O-t replikáljuk, hanem a fizikai I / O-t okozó parancsokat.
Tehát ezt gyakran naplóküldésnek vagy naplóalapú replikációnak nevezik. Néhány adatbázis-szolgáltató ezt natív módon adja meg. Előfordulhat, hogy más adatbázis-gyártók ezt nem kínálják, de ezt harmadik fél gyártók kínálják, tehát ez egy nagyon népszerű HA megoldás, és teljes megoldásnak tekinthető. De ez a megoldás elsősorban a DBA felelőssége.
Tehát nem virtualizációt használom ennek megvalósításához. Lehet, de nem vagyok tőle függő. És nem használom a tárolási virtualizációt. Megint tudtam, de nem vagyok tőle függő. De olyan megoldást építek, hogy az adatbázis az elsődleges vezetési funkció. Tehát ez logikus replikáció.
Mostantól az adatbázis és a tárolási virtualizáció is kombinálható. Adatközpontomban, mondhatnánk, a bal oldalon kék színben, virtualizálhatnék a tárolást, hogy ne vagyok kötve egy adott tárolótömb meghibásodásához. De valószínűleg adatbázis-szintű napló alapú vagy logikai replikációt hajtok végre az egyik adatközpontról a másikra, hogy a parancsok adatközpontban is végrehajtásra kerüljenek, I / O eredményt eredményezve, de nem feltétlenül ugyanazt a I / O-t, mert én ' Nem blokkolja az I / O blokkot, sem a tárolási megoldás, sem az adatbázis segítségével, de a naplókat és ezért az SQL parancsokat továbbítom.
Tehát ez egy kép, amely nagyon általános kép a nagyon nagy szervezetek számára. És tetszik ez a kép itt, mert ha ezt egy olyan adatbázis felhasználásával kell beállítanom, mint az Oracle, akkor meg tudom csinálni; meglehetősen sok munka, elég bonyolult, sok mozgó alkatrész van. Ha ezt a felhőben teszem, szó szerint azt mondom: jelölőnégyzetet, két földrajzi régiót akarok, a régiókat elválasztom egymástól, tudod, különböző kontinenseken, tárolói szintű virtualizációt akarok egy adott földrajzi régióban. Még azt is elmondhatom, hogy szeretnék virtualizációs típusú allokációt vagy magas rendelkezésre állású meghatározást végezni, és ismét egy másik jelölőnégyzet.
És a másik dolog, ami tetszik a felhőben, van egy másik jelölőnégyzet, amely gyakran azt mondja: „Nem akarok foglalkozni, csak javítással foglalkozni”. Tudod, csak illessze be minden más munkafolyamatába, amelyet a jelenetek, mindig foltoztass. És így, bár ezeknek a képeknek egy része nagyon bonyolult, és valószínűleg nehezen készíthető előfeltevésen, valójában meglehetősen könnyűek a felhőben.
Most az érdekes, hogy könnyű ellenőrizni az összes jelölőnégyzetet, de hiszem mi, ez havonta több pénzt jelent. Mivel ha két adatközpontot üzemeltet, akkor tudod, hogy két adatközpont van a felhőben, amelyet használ, akkor többet fog fizetni, mint ha csak egyet használna. Hasonlóképpen, ha a tárolási szintet vagy a virtualizáció magas szintű rendelkezésre állását kiegészítő rétegként végzi, ismét további költségek merülhetnek fel.
Tehát érdekes, hogy bár ezt nehéz a helyszínen elvégezni, és előfordulhat, hogy átgondolja, a felhőben ezt olyan könnyű megtenni, akkor alá is merheti. Tehát mindig tudja, hogy néz ki a kép, és mindig tudja, hogy milyen költségekkel jár a kép, amelyet építesz. Most sokkal több kombináció létezik, mint amit itt mutattam. Ez nem teljes vagy kimerítő példa. Rendszeres időközönként megjelennek új technológiák, tehát ki tudja - talán nem mutattam meg olyan technológiát, amely csak az elmúlt három hónapban jelent meg. És a magas rendelkezésre állás sokkal gyakoribb, mint tíz évvel ezelőtt.
Valójában nem tartom túl hosszúnak azt mondani, hogy a legtöbb nagy szervezet számára manapság kötelező üzleti követelmény. És szeretek visszatérni ehhez a diához, mert csak mondtam, hogy kötelező üzleti követelmény. És jobbra kaptam ezt a két táblát. A legfelső az SQL Server dokumentációjában, az alsó az Oracle dokumentációjában található. És ezek ezek a táblák, amelyek segítenek kiválasztani, milyen replikációs módszert kell használni.
És vegye figyelembe, hogy néhány nagyon egyszerű kérdéssel kezdődik. Mennyi adatot szabad használni? És ha a válasz nulla, akkor tudja, hogy a felső táblázatban csak az első vagy a negyedik sort választhatja. Akkor feltesz egy másik kérdést. Nos, mennyi ideig tarthatom a gyógyulást? És ha valaki azt mondja, másodpercek vagy percek, akkor ez döntést hoz Önnek. És akkor a feladatátvételnek automatikusnak kell lennie, vagy szükség van-e valakit manuálisan? És ez egy másik üzleti kérdés. Azt mondhatják, hogy automatikusan akarják, mert nem akarnak támaszkodni, tudod, egy eszkalációs eljárásra, majd valakire kapnak jegyet, majd megoldják a problémát. Csak azt akarják, hogy rögzítsék.
Ezek mind üzleti kérdések, és ugyanazok a kérdések, ha lemegyek, és ugyanezt tegyem az Oracle-rel. És azt kérdezem, OK, milyen bukást engedhetek meg, milyen időtartamra, mit veszíthetek, mi a helyreállítási eljárás? Ez mind üzleti döntés, tehát ha a vállalkozás három vagy négy kérdésre válaszokat ad nekem, a munkám valóban könnyű, csak idejövök, kiválasztom a legmegfelelőbbet, majd ezt készítem. És ne feledje, hogy a felhőben csak néhány jelölőnégyzet lehet azok végrehajtása.
És ezzel véget vet az anyagom és az ideje annak, hogy fel tudjam nyitni kérdéseire.
Eric Kavanagh: Rendben, Dez, talán először te, majd Robin?
Dez Blanchfield: Teljesen. Valójában valószínűleg egy kicsit tisztességtelen azokkal szemben, akik nem aktívak, de csak egy képet ábrázoltam egy grafikonról, amelyet mindenki számára el akarok látni, és aztán a kérdést akartam feltenni a meghívott barátunknak. Amikor ezen a téren a védett és a nyílt forráskódra gondolok - amelyről gyakran beszélünk, mint például az Oracle és a Microsoft kedvelt védett adatbázisai, és így tovább, szemben a nyílt forráskóddal -, akkor ezzel a kihívással kell szembenéznie, amelyben a védett világ az internetes szoftvergyártó vagy szoftverfejlesztő, vagy a vállalat beruház a testületekbe, hogy felépítse ezt a komplexitást. És így egy olyan forgatókönyvvel jár, ahol megvásárolja a szoftvert, és nem kell sok emberbe fektetnie, mert vásárol a beépített és a nyílt forráskódú képesség - nem fizet a szoftverért, vagy mondjuk, olcsó, de nem fizet a szoftverért, hanem be kell fektetnie a testbe.
Nagyon szívesen felhívom a gondolataidet a zsonglőrre, különösen most, amikor felhőmodellekbe költözünk, ahol bármelyiket meg lehet szerezni. Keresse meg az AWS-t vagy az Azure-ot és a Rackspace-t, bármit is vásárolhasson szolgáltatást, amely biztosítja az adatbázis-platformot, vagy megteheti nyílt forráskódon keresztül. És miről beszéltünk, mi a zsonglőr a szabadalmaztatott és a nyílt forráskód között, és hogyan lépnek életre a tervezett minták, amelyekről beszéltél, és mi az általános gondolataid ebben a témában, ahogyan előrehaladunk, különös tekintettel a rendelkezésre állás biztosítására?
Bert Scalzo: Az egyik nagy elem, amelybe becsapok, amikor megpróbálom megválaszolni ezt a kérdést, visszamegyek az ügyfélhez, és megkérdezem tőle a teljesítménykövetelményeiket. Ennek oka az, hogy - legalábbis történelmileg és a saját tapasztalataim szerint - azt tapasztaltam, hogy amikor olyan ügyfelekről van szó, akiknek replikációjukra nagy áteresztőképességre van szükség, szinte mindig jobban teljesítek az adatbázis által biztosított replikációval. a gyártó, jellegéből adódóan, hogy beépített benne és alacsonyabb szintű, és néha olyan mechanizmusokat használ, amelyek a külvilág számára még nyílt forráskódú megoldásban sem állnak rendelkezésre.
És jó példát fogok adni nekem egy esetemről. Volt egy internetes vállalkozásom, aki MySQL-t használt adatbázisként, és a MySQL régi verziójában, például a 4.0-s verzióban voltak, és a csomópontjaik közötti replikáció volt az a korlátozó tényező, hogy mennyire tudják méretezni az adatbázisukat. És egy harmadik féltől származó megoldás megvásárlására törekedtek, aztán arra gondoltak: "Nos, talán használhatjuk az egyik nyílt forráskódú megoldást." És ami valójában felbukkant, az az volt, hogy csak a MySQL verzióra kellett frissíteniük, azt hiszem, 5,5-re mentünk, mert a különbség e két adatbázis-változat között a MySQL 4.0-s verziójában nem volt menetes, és az 5.0 verzióban ez volt, és valójában ez volt a legjobb út számukra.
Most megvizsgáltuk a többi választást, de a döntő tényező a teljesítmény és az adatbázis-szállítói megoldás melletti maradás volt, és az adatbázis-frissítés valójában a legjobb megoldás volt a legjobb megoldásunk, hogy a lehető legnagyobb valószínűséggel megkapjuk azt a teljesítményt, amelyre szükségük volt, hogy együtt menjenek együtt. minél magasabb a rendelkezésre állás.
Dez Blanchfield: Igen, ez tükrözi a saját gondolkodásomat, hogy őszinte legyek. Csak a teljes nyilvánosságra hozatal érdekében, és nem megyek bele a márkákba, de az eredeti gyártók és a szoftvergyártók és általában a NOB-k szakembereinek hátteréből származik, és ez határozottan a tapasztalatom, és ugyanakkor nagyon profi vagyok -open-source és én egy kódcsatoló vagyok egy csomó projekthez, amelyet nem fogunk megnevezni, de egyetértek veled abban, hogy ha nagy szervezet vagy - mondjuk, hogy bank vagy, vagy bármi más, legyen - mindig sem akarja, hogy informatikus üzlet legyen. Tudod, például, ha Ön újságkiadó vagy kiskereskedő, akkor nem akarja, hogy informatikai üzlet, amely újságokat publikál, hanem egy olyan újságbolt, ahol valójában csak kihasználja az IT-t.
Tehát, ha beruházunk a szabadalmaztatott képességekbe, ahol a szoftverfejlesztők mindezt a képességet, a terheléselosztást és így tovább építik az eszközbe, sokkal több értelmet jelent, mint ha dotcom indító vagy valami más vagy? mint például, amelyek befektethetnek az emberi testekbe. Hol látod ezt megy?
Valószínűleg az utolsó kérdésem, mielőtt átadom Dr. Robin Bloornak, mert tudom, hogy kevés az idő. Hol látja ezt tendencia szempontjából? Tehát egész idő alatt odakint vagy, a dolgok vérző oldalán vagy, látja, hogy az emberek leültek, odafigyeltek és felébredtek annak szükségességére, hogy ezt mindennapi üzleti részévé tegyék. napi beszélgetés vissza az előadóterembe? Vagy továbbra is azt látja, hogy a geek farm, a technikusok és a kapucnis pulóverek a rendelkezésre állásról gondolkodnak, mert reggel négy órakor felébresztik őket, amikor valami offline állapotba kerül?
Gondolod, hogy a tendencia most minden méretű szervezetet öleli fel, nem az olyan nyilvánvaló szervezeteket, mint a légitársaságok, a bankok és a pénzügyek, hanem csak a vállalkozásokat általában? Gondolod, hogy az emberek valóban kihagyták az értékteremtési javaslatokat az adatbázis-környezetük védelme érdekében, magas rendelkezésre állást biztosítva, és beruházva ebbe, vagy gondolod, hogy van-e még útunk? Mi az általános értelme a piacon?
Bert Scalzo: Jelenleg azt hiszem, hogy van még egy rés, de ez nem rés, mert az üzleti vállalkozás nem azt kéri, hanem egy rés a kerítés két oldala közötti kommunikációs szintekben. Más szavakkal: az üzletemberek nagyon egyértelműen azt mondják: "Ezeknek az alkalmazásoknak magas rendelkezésre állásra van szükségük, és ezeknek a speciális követelményeknek meg kell felelniük, amikor azt mondjuk, hogy magas a rendelkezésre állás."
És valamilyen módon, ami nem érthető egyértelműen a tech emberek számára. Vagy a tech emberek visszatérnek, és azt mondják: "Ó, nos, ez bonyolult és több pénzt fog számolni", és ezt, vagy azt. Azt hiszem, hogy mi fog történni, az végül el fog romlani, mert őszintén szólva, amikor például a felhőben van, csak néhány négyzetet bejelölve itt vagy ott, hogy mondjam: „Építsd meg nekem ezt a nagyon összetett technológiai struktúrát” valóban nincs jó ok arra, hogy a technológiai emberek visszatérjenek és mondják az üzletembereknek: „Ó, ez drága” vagy „nehéz megtenni”, vagy ezt, vagy azt, és az üzletemberek kezdik tudni, hogy ez a tény.
És még olyan környezetben is láttam, ahol, tudod, a saját informatikai embereik eljönnek és azt mondják: „Ó, nem lehet, amit akarsz. Túl drága. ”És bevonnak egy harmadik féltől származó tanácsadó céget, aki azt mondja:„ Nem, ez nem helyes. Így teheti meg. Így fog kerülni Önnek. ”Tehát azt hiszem, hogy van még egy kis időnk a két fél közötti kommunikációs szintek között, mielőtt ez automatikusan automatikusan működik.
Dez Blanchfield: Igen, ez határozottan tükrözi azt, amit itt láttam Ausztráliában és az Ázsiai-csendes-óceáni térségben. Biztos vagyok benne, hogy globális dolog. És ez az, hogy a legfontosabb döntéshozók az ülésteremtől lefelé, az összes üzletvezető technikailag sokkal hozzáértőbbek - blogokat olvasnak, webináriumokat néznek, ők különféle cikkekbe és podcastokba hangolva, rendezvényeken, fórumokon és találkozókon mennek, és most már tudják a lehetőségeket, és tudják, hogy a felhő egy lehetőség.
Azt is tudják, hogy a házon belüli képességeikkel hozhatják magukat, amint mondtad, és úgy gondolom, hogy most van ez az érdekes kihívás, hogy meg kell tartania ezt a beszélgetést, ami alapvetően az, amit ma csináltunk, ahol emberek, fajta , kezdje el a belső dolgokat csinálni, csak futtasson barna táska ebédeket, és belső eligazítást tartson arról, hogy mi a jelenlegi állapotunk, mi az ideális állapotunk, hová kell eljutnunk? És aztán, valamiféle, összerakod ezt.
Volt egy magántulajdonom, amelyet csak most fogok gyorsan megérinteni. Valaki feltett egy kérdést: „realisztikus-e, ha 100% -kal elérheted?” És valószínűleg itt javíthat, de én igennel mondom. Felépítettem egy platformot az elektronikus pénzátutaláshoz, az EFTPOS átjárót a gyors bankplatformok és az EFTPOS terminálok között. Ezt a 2000-es évek elején építettem. Valójában az idő 100 százaléka online volt 17 éve. Valójában a 2000-es évek előtt építették, de csak 2000/2001-es termelésre ment nagyjából.
Tehát a 17 év már a fejlesztéstől a teszteléséig, majd a gyártásig tart. Ebben a 17 évben a nagyon olcsó árucikkekhez közeli, nyílt forráskódú operációs rendszert futtató, de saját tulajdonú adatbázisban működő, 90 naponként aktív / passzív cserét végeztek, különböző tervezési szabadalmak alkalmazásával, a lemezek az egyes szerverekben, az adatok replikálása a modellkiszolgálók között, több adatközpont replikálása, és az A adatközpontról való átfordítás. A termelés 90 napig zajlik, majd a B adatközpontba repülés és a termelés végrehajtása.
És miközben elcsúszik, automatikusan javítja és frissíti, így arra a kérdésre, amelyet csak magántulajdonban vettem fel, igen, ez lehetséges, de a tervezés szempontjából jelentős beruházással jár a projektbe. Tehát az infrastruktúra valójában nem volt olyan drága, de a megtervezés, a tesztelés és a megvalósítás nagyon drága volt annak megszerzéséhez. Tehát nem kellett sok pénzt költenünk a hardverre és az infrastruktúrára, de nagyon okos eszközöket használtunk, még abban a napban, amikor a felhő még pénzérme sem volt.
Tehát, a válasz igen, megtehető, még inkább felhővel, mint most hallottuk, hogy egy gombnyomással engedélyezheti ezt a képességet. Meg fogom dobni ezt Robinnak, mert biztos vagyok benne, hogy kérdései is vannak vele. Nagyon köszönöm, hogy válaszolt a kérdéseimre, és nagyon szeretem meghallgatni ma. Teljesen a fedélzeten, mivel mindez tükrözi mindazt, amit magamnak tettem az elmúlt közel 30 évben.
Dr. Robin Bloor: Nos, rendben, felveszem. Az egyik dolog, ami lenyűgözött az előadása során, az a számtalan lehetőség áll rendelkezésre, amelyek jelenleg nem álltak rendelkezésre, amikor nem kellett küzdenem ezekkel a dolgokkal. Nagyon érdekli, ki fogja ezeket a konfigurációkat megtervezni, vagy manapság ki tervezi ezeket a konfigurációkat? Ami korábban történt, vagy a szokásos világban az, hogy meglehetősen nehéz tranzakciós rendszer lenne, és érdekli a magas üzemidő és a magas rendelkezésre állás. Mert, tudod, a tranzakciós rendszer, drága lenne, ha bármilyen módon csökkenne. És nem lenne az összes olyan opció, amelyet éppen nekem mutatott be, de úgy vagy úgy találhatja meg a módját, többnyire replikáció útján, olyan forró készenléti üzemmód létrehozására, amely nem észrevétlenül kattan be, de roppant szolgálatot nyújtana neked, amíg vissza nem kapod.
És én olyan vagyok, hogy arra nézem, amit mutatott nekem, és gondolkodtam rajta, és 15 éve nem végeztem ilyen típusú tervezési munkát. Ki csinálja ezt a munkát? Ez, amint az én napjaim volt, valami, amit a projekt kezdetekor megtettél, tudod, az infrastruktúra működik? Vagy ez valami folyamatos tevékenység egy szervezeten belül? Mert új technológiai döntéseket hoznak.
Bert Scalzo: A nagyvállalatokban, amelyek nagyon hatékonyak és eredményesek minden tevékenységükben, ideértve az informatikai eszközöket is, általában központi építészeti csoporttal rendelkeznek, vagy nekik lesz némi neve, hallottam, hogy „építészeti csoport” sok idő. És a saját felelősségük, hogy megismerjék ezeket a különféle képeket, valamint hogy mi az előnye és hátránya, és milyen költségekkel jár. És mi fog történni, ha egy adott alkalmazás keres és azt mondja: "Hé, meg kell felelnem az X, Y és Z üzleti követelményeknek. Hé, építészmérnöki csapat, mi a választásom?"
Meg fogják adni nekik a választ, például: a rendelkezésre álló kettő vagy három, majd ezen a ponton a döntés visszatér az alsóbb szintre az alkalmazási csapat vagy az alkalmazás üzleti szponzora felé. De általában van egy központosított csoport, aki ezen felül marad, és rendelkezik ezekkel az információkkal, máris készen és előre felépítve.
Most a közepes méretű vállalatok vannak, ahol nem ez a formális. Ami általában fog történni, akkor kap egy vagy két vezető DBA-ját vagy rendszergazdáját, akik informálisan „domain szakértőt” idéznek az ilyen jellegű szakértelemre. Tehát még a közepes méretű vállalatoknál is megtörténik, csak egy nem formalizált struktúrában.
Dr. Robin Bloor: Nagyon érdekes. Napjaimban soha nem gondolnánk a magas rendelkezésre állás lehetőségét, kivéve a tranzakciós rendszereket. Nos, manapság természetesen megvannak a streaming rendszerei, amelyek valószínűleg még nagyobb igényeket támasztanak a rendelkezésre állás szempontjából. De a lekérdezés-alapú, háttér-elemzésben, elemzésben, adattárházban, DI típusú környezetben lát valaha is a magas rendelkezésre állás követelményeit?
Bert Scalzo: Igen, és örülök, hogy feltette ezt a kérdést. Néhány munkát végeztem egy kiskereskedelmi cégnél, és stratégiai döntéseik az üzleti életben nagyrészt azon elemzésen alapultak, amelyet az adattárházból elvégeznének. Valójában a Forbes Magazine interjút készített, és a cég vezérigazgatója elmondta: „Hé, részvényárfolyamunk 250 százalékkal nőtt az elmúlt öt évben, és ez egy nagyon nagy ok, ami igaz, mert tudjuk, hogyan tudjuk hatékonyan kihasználni az adatainkat. Olyan jók voltak az üzleti döntések meghozatalában, hogy számukra az adattárház és az analitika elvégzése, a napi döntések meghozatalának képessége az operatív adataik alapján való volt számukra, termelési rendszer.
És jó példát fogok adni neked annak fontosságáról. Ezzel a kiskereskedővel, az a srácért, aki a sörért felelős, ő volt a vállalat harmadik legfontosabb ügyvezetője, mert, tudod, a bevétel 60, 70 százalékát hozta be. Tehát képesnek kell lennie arra, hogy azért versenyképes maradjon ezen a piacon, minden nap tudnia kell, tudja, milyen promóciókat kell futtatnom. Ez alapulhat, tudod, nemcsak az évszakban, hanem az időjárási viszonyokon, a mintákon és más kritikus adatokon, amelyek befolyásolhatják valami hasonló sör értékesítését.
Dr. Robin Bloor: Nos, azt hiszem, vannak ilyen dolgok. Idővel késünk, azt hiszem, oda kellene adnom Ericnek, ha van néhány kérdése a közönség részéről. Eric?
Eric Kavanagh: Igen, ez mind jó dolog, Bert. Azt hiszem, hogy felválaszolta az összes kérdést, amely a közönség részéről felmerült az előadása során. De szórakoztató nézni. Örülök, hogy egyáltalán beszéltél a tárolási virtualizációról és annak mekkora hatásáról. Szóval, ez mind jó dolog.
Nos, emberek, ezeket az internetes adásokat archiváljuk későbbi megtekintés céljából. Tehát ugorjon online a Techopedia.com webhelyre, és keresse meg a webcast részt. Azokat a forró technikákat ott felsorolják. Nagy köszönetünk Bert barátunknak a szakértelemért. És természetesen Deznek és Robinnak. És ezzel búcsút fogunk adni neked, emberek. Vigyázz magadra. Legközelebb beszélünk veled. Viszlát.