A Techopedia munkatársai, 2016. december 7
Elvihető: Eric Kavanagh házigazda megbeszélést tesz elérhetővé Robin Bloor, Dez Blanchfield és az IDERA Bert Scalzo részvételével.
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özlet újra. Szerdán négy óra van a keleti idő szerint, és ezek a napok csak egy dolgot jelenthetnek, ha az adatvilágban vagyunk: itt ismét a Hot Technologies! 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, milyen hűvös dolgok vannak, amelyeket a vállalkozásban használnak, és természetesen, az alapja annak, amit az egész területen teszünk, 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, keressen fel a Twitteren, @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 ilyen. 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 tartózkodjon, emberek, kérdéseket tegyen fel - ez az esemény nagy része az Ön számára, ha jó kérdéseket tesz fel és jó válaszokat kap, ezért küldje el őket a csevegőablakon vagy a konzol Q és A komponensén keresztül.
És ezzel átadom Robin Bloornak - vegye el.
Dr. Robin Bloor: Rendben, hadd kattintson rá és nézzem meg, hogy mozog-e. Nem fogok külön az adatbázisról beszélni. Arra gondoltam, hogy tudod, mivel én elkészítem a bevezető, az első bevezető bemutatót, ezért a várt szolgáltatási szintekről és természetesen a rendelkezésre állásról fogok beszélni, ami 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 kilencvenes években észrevettem - egy webhelyen dolgoztam, és a felhasználók panaszkodni kezdtek, mert e-mailük nem volt megfelelő 15 perc.
É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 az e-mail 15 percig nem működött, 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 e-mailt lehetett használni, hanem az volt, hogy nem lehetett küldeni és fogadni, mert a kiszolgáló ki van á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. Beszéltünk az informatikai rendszerekről vagy az informatikai alkalmazásokról. Á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 pontra gondoltam, 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 - ez olyan, mintha nem csupán a rendes elérhetőségrő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 mivel 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, ha a szervezetek jól definiált szolgáltatási szinteket kínálnak 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őkorlát, érdemes megemlíteni az időkorlátokat. 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; Lehet, hogy az alkalmazások a lehető leggyorsabbak, 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 ténylegesen az emberekkel foglalkozol - kölcsönhatásban állsz velük - a legjobb válaszidő, amelyet valójában elvárhatnak tőled, a másodperces tized, mert ez az emberi válaszidőre vonatkozik. 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 kb. Négy másodperccel elmúlnak, elkezdenek valami mást csinálni, és ezért valóban egy sorozatgyakorlatba kerülnek.
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 mélyebben belemenni ebbe, 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 hogy 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, amiről tudod, hogy van egy projekted, csiná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 Robin. Szeretem a nyitó csúszdát. Éppen most 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 tartok, 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 adok neked egy pár elvitelre ugyanazon a szinten, mint én rendszeresen ülésteremben ülök a C-lakosztályok és az üzletvezetők számára azzal a céllal, hogy beszélgetünk arról, hogy mi befolyásolhatja szervezetét kereskedelmi vagy műszaki szempontból, valamint a mérnöki típusokat.
Gondolnunk kell, hogyan és hogyan - mit veszünk ettől, és hogyan kell majd megválaszolnunk néhány olyan 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. Enélkül, a hozzáadott lehetőségek nélkül egyszerűen nem léteznek. 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é tesszük, mindig ébresztőórákként használjuk, kamerákként és fényképeket készítünk, ezeket a képeket a felhőbe tolják.
Mindig bekapcsolódtak, állandó kapcsolatban állnak a 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 kifejezés, mellyel elhagylak téged, vagyis mindig kilenc óra van, egész idő alatt. 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 egy időben, a nap minden órájában, kilenc óra. É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. Figyelembe vesszük magunkat azzal, amit a szolgáltatási szintű megállapodásaink tartalmaznak? 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 átélte a teljes előfeltételezés folyamatát, és önálló házigazdaként működteti külső szolgáltatók adatközpontjainak kihelyezését és kiszervezett menedzselt 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 csak mások számítógépe. É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ésben. 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 a rendelkezésre állási időt, 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 mint tervezési szempont. 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. Kerekítsük ezt alig több mint egy hónapra.
Gondoljon minden olyan üzletre, amelyen minden nap foglalkozunk - legyen az online banki, eBay, PayPal vagy olyan közösségi média platform, mint a LinkedIn, Twitter vagy csak egy általános kiskereskedő - mondjuk, mondjuk, szeretnék egy repülést lefoglalni, hogy napos időben érkezzen az USA-ba Ausztrália, 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 működik, mert szolgáltatójuk azt mondta: "Nézd, az idő 90 százaléka fel van állítva „? Természetesen nem.
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, ez az időnk egymást követő, megállás nélküli nyolc órája. Nos, a bankrendszerben és a pénzügyekben, az egészségügyben - ha ez egy kórház, akkor az életeket okozhat. 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. Sokkal nehezebb ezt a szolgáltatást nyújtani, és ha gondolkodik azon idő csökkentéséről, amire szüksége van a biztonsági mentések futtatásához, az adminisztrációhoz, a javításhoz, a karbantartási ablakokhoz bármilyen leállás esetén - minden nem triviális kihívás - é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 gondolnia kell az iparág típusára és a piaci szegmensre, amelyre törekszik. 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 operatív 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 szint között zsonglőrködik, és a magas rendelkezésre állás, amely folyamatos rendelkezésre állás, és ez egy állandó kihívás, hogy megfeleljünk, például hogy 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 megtö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 hiba é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, amelyekre hagyom Önt, és az a következő: Mit engedhet meg magának a szervezet? 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ást a szoftverszolgáltatástól eltekintve megkapod, akkor a verem nélkül maradsz, ahogy tovább haladsz 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 kell tekintenie, mivel 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 nehéz gondolkodnod kell, hogyan működik, és mit jelent ez a szervezetének, mit kell nyújtania.
És aztán a zsonglőr között, ami a helyszínen van, mi a külső házigazda és potenciálisan, mi van 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 ez nem jelent feat. Idõt, erõfeszítést és pénzt igényel, hogy átgondoljuk ezeket a dolgokat. És mindig az emberekbe és készségekbe való beruházásokba, valamint a szoftverekbe és eszközökbe történő beruházások, 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, mivel 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, 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 feltehessek. És továbbadom.
Dr. Robin Bloor: Jól van. 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 sokat fogok felhasználni arra, 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 megtenni, 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. Nem fogok rajzolni például Oracle-specifikus vagy SQL-Server-specifikus megoldást, de megrajzolom, mondjuk, egy általános architektúrát, amelyet az adatbázis-gyártók kínálnak, valamit e vonal mentén. Mindegyiket különböző néven hívják, de ez a közös választás egy típusa, és azt szeretném megvizsgálni mind az üzleti, mind a technológiai szempontból, és 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 ismét megpróbálom meglehetősen adatbázis-diagnosztikusság 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 lesz, hogy mozgó alkatrészek lesznek, tehát összetettebbek és ezért költségesebbek.
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 szempontjából. Adok egy jó példát; 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 akiknek nincs lassú webhelye. Tehát nemcsak az ügyfél vesztesége, hanem az ügyfél jó akarata is van veled szemben.
A hardver manapság sokkal olcsóbb, tehát egyre nagyobb igény mutatkozik a magas rendelkezésre állásra. És ismét el fog vezetni minket a felhőhöz, 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, amelyet ellenőrizsz. É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. Tehát, ha megérti a képeket, a felhőben néha csak néhány jelölőnégyzetet bejelöl, hogy elkészítse a fejében lévő képet.
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, hogy az a központ offline állapotba kerül-e? Nem követelom meg az üzleti követelményt, hogy az 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 ez az egész webhely.
És akkor, amint Dezről beszélt, mi az elvárás az idő, 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 ez nyilvánvalóan meghatározza ezeket a képeket, amelyeket megmutatom, hogy működni fog, és néhányuk nem lesz olyan lehetőség, amelyet Ön 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 valami történik, miközben egy tranzakció feldolgozásának közepén állok, mit veszíthetek a rendszer újraindításakor? " Más szavakkal: ha el tudom állítani a rendszert két perc alatt, és elveszíthetek legfeljebb 10 másodpercet, mondjuk, a repülés alatt álló tranzakciókat, az elfogadható üzlet? És ez megint meghatározza, hogy a vállalkozás mennyit hajlandó költeni erre, majd megint meghatározhatja, hogy mely képeket mutatom be, amelyek alkalmazandók, vagy nem.
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 van szerver és tárolótömb, á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 is kész vagyok. Ugyanezt fogom csinálni a host busz adapterekkel, és több útvonalat fogok tenni a különféle kapcsolókon keresztül, hogy többféle módon is eljuthassam a tárolómhoz. Van egy univerzális tápegység, és van ismétlődő vezérlőm a tároló tömbömben, és talán megcsináltam valami hasonlót a RAID 10-hez a lemezeimmel. Más szavakkal, ebben a képen több szinten megakadályoztam 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 elmegy, meghalok. 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ám, de előfordulhat, hogy rendelkezésre áll, hogy tárolási megoldásként is megtehető, vagy lehet, hogy hogy tárolási szintű replikáció lehet. Bal oldali esetben virtualizáltam a tárolást. Ami történik, hogy a RAID 0 két különböző tárolószekrényben van a lemezeimhez, de a RAID 1 a két különböző tárolószekrényben található. 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 kis fejlesztést hajtottunk végre, most már nincs vörös a tároló szintjén, A tároló virtualizáció már felhasználta 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 az adatbázis-replikációról beszélek, hanem a blokk I / O replikációjáról a tárolás céljából. É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ási 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 vörös 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 már 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 megvan a megosztott tároló tömb, és hiszem mi. Ez a megoldás az adatbázis-adminisztrátor és a virtualizációs adminisztrátor 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 az elérhetőségem, mert át tudom helyezni a virtuális gépet vagy a futó alkalmazást vagy adatbázist az egyik szerverrő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. Sokáig javítottam a kapcsolókat és a HBA-kat.
Tehát most felé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. Ezutá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, 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 egy mester és egy rabszolga, vagy egy forró és hideg, vagy egy aktív és készenléti. 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ópont, jobb oldalon passzív csomópont, 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 ugyanúgy, mint a tárolási szintű virtualizáció, a blokkban történik. szint. Tehát megismételjük a tényleges blokk I / O-kat az aktív csomóponttól a csak olvasható vagy passzív csomóponttól. É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 a blokk I / O átvitele helyett lényegében a naplót küldjük át. 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álok ennek megvalósítására. Lehet, de nem vagyok tőle függő. És nem használom a tároló 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ó virtualizáció is kombinálható. Lehet, hogy az adatközpontban, mondjuk, a bal oldalon kékkel, 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 küldöm el a blokk I / O-ját 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 az Oracle-hez hasonló adatbázis felhasználásával kell felállítanom, meg tudom csinálni; meglehetősen sok munka, elég bonyolult, rengeteg 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 mondhatom, hogy szeretnék virtualizációs típusú allokációt vagy nagy rendelkezésre állású definíciót elvégezni, és ismét egy újabb 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, noha ezeknek a képeknek egy része nagyon bonyolult, és valószínűleg nagyon nehéz megtenni a feltevést, 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. Mert ha két adatközpontot üzemeltet, akkor tudja, hogy két adatközpont van a felhőben, amelyet használ, többet fog fizetni, mintha csak egyet használna. Hasonlóképpen, ha a tárolási szintet vagy a virtualizáció magas szintű rendelkezésre állását egy további 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 megtenni, és előfordulhat, hogy átgondolja, a felhőben ezt olyan könnyű megtenni, akkor alábecsülheti. Tehát mindig tudja, hogy mit 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 az új technológiák, tehát ki tudja - talán nem mutattam meg egy olyan technológiát, amely csak az utóbbi 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 tartanám túl hosszúnak 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 ez 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 jegyet kapnak, 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, rendben, milyen hibát 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, hogy melyik meccs közül melyik a legközelebbi, és aztán felépí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: Jól van, 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 a Twitteren vannak, de csak egy képet ábrázoltam egy grafikonról, amelyet mindenkinek szem előtt tartani szeretnék, és aztán felhívtam a kérdést tanult barátunknak a hívás ideje alatt. 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.
És nagyon szívesen szeretném felhívni a gondolataidet a zsonglőrre, különösen most, amikor felhőmodellekbe mozogunk, 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, és mi az Ön általános gondolatai ebben a témában, miközben haladunk, különösen a rendelkezésre állás biztosításával kapcsolatban?
Bert Scalzo: Az egyik nagy elem, amellyel szembesülök, amikor megpróbálom megválaszolni ezt a kérdést, visszamegyek az ügyfélhez, és megkérdezem tőle teljesítményük követelményeit. 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 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 például újságkiadó vagy kiskereskedő, nem akarja, hogy informatikai üzlet legyen, amely újságokat publikál, hanem olyan újságbolt, mintha csak kihasználja az informatikai eszközöket.
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égykor 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, hogy megvédjék adatbázis-környezetüket, magas rendelkezésre állást biztosítsanak és befektessenek ebbe, vagy gondolod, hogy van-e még útunk? Mi az általános értelme a piacon?
Bert Scalzo: Úgy gondolom, hogy még mindig van rés, de ez nem rés, mert az üzlet 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 az üzenet valamilyen módon nem jut át egyértelműen a tech emberek számára. Vagy a tech emberek visszatérnek, és azt mondják: „Ó, ez bonyolult és több pénzt fog fizetni”, és ez, vagy a másik. 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 álló tanácsadó céget, aki aztán azt mondja:„ Nem, ez nem helyes. Így tudod megcsinálni. Így fog kerülni Önnek. ”Tehát, azt hiszem, 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 még mindig automatikusvá válik.
Dez Blanchfield: Igen, ez határozottan tükrözi azt, amit láttam itt Ausztráliában és Ázsia-csendes-óceán körül. 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 privát üzenetem, amelyet csak most fogok gyorsan megérinteni. Valaki feltett egy kérdést: „realisztikus-e, ha 100% -kal elérhető?” É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, tehát csak arra a kérdésre, amelyet csak magántulajdonban vettem fel, igen, ez lehetséges, de a tervezés szempontjából sok beruházással járunk ehhez a projekthez. 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, meg lehet tenni, még inkább felhővel, mivel csak 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. Nagyon köszönöm, hogy válaszolt a kérdéseimre, és nagyon szerettem ma hallani az üzenetet. Teljesen a fedélzeten, mivel mindent tükröz, amit magam csináltam 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 világ, amelyhez szoktam, az 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éha azt nézem, amit megmutattál nekem, és gondolkodtam rajta, és 15 éve nem végeztem ilyen típusú tervezési munkát, ki végzi 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ések vannak együtt.
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, rendszerint egy centralizált építészeti csoporttal rendelkeznek, vagy nekik lesz némi neve, hallottam, hogy “a építészeti csoport ”sokszor. É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: itt állnak 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 tartózkodik, é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 ez nem olyan 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ényeknek vannak kitéve 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, ö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é, a 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 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% -á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, nem csak 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 előtt. 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.
