Avtor osebja Techopedia, 7. decembra 2016
Odvzem: Voditelj Eric Kavanagh razpravlja o razpoložljivosti z Robin Bloor, Dez Blanchfield in IDERA Bert Scalzo.
Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.
Eric Kavanagh: Dame in gospodje, pozdravljeni in dobrodošli še enkrat. V sredo je štiri ure vzhodnega časa in v teh dneh lahko to pomeni samo eno stvar, če ste v svetu podatkov: spet je čas za Hot Technologies! Da, resnično.
Moje ime je Eric Kavanagh, jaz bom vaš gostitelj oddaje. Zasnovan je tako, da ugotovi, kaj je vroče, kaj se dogaja tam zunaj, kaj je kul stvari, ki se uporabljajo v podjetju, in seveda prav v temelju vsega, kar počnemo na tem celotnem področju, je baza podatkov. Torej bomo govorili o zaščiti vaše baze podatkov. Natančna tema je: "Zaščitite svojo bazo podatkov: velika razpoložljivost za podatke velikega povpraševanja." In dovolj o meni, zadene me na Twitterju, @eric_kavanagh.
Prvič, letos je vroče, podatki so vroči, veliki podatki so zelo vroči, vendar je res še vedno nekako na robu. V današnjem času več sodobnih podjetij izkorišča velike podatke, večina organizacij za kruh in maslo tam na svetu še vedno uporablja tradicionalne podatke, in če so po vaših podatkih veliko povpraševanja, želite zagotoviti, da so na voljo, ker ko se sistemi sesujejo, ko so podatki nedostopni, takrat pridete nesrečni odjemalci, nezadovoljni potencialni kupci, dobite kompenzacijo strank, postanete nesrečni vse vrste stvari, partnerjev itd. Torej tega ne želite.
Danes se bomo učili od nekaterih najboljših v tem poslu - slišali bomo pri lastnem dr. Robinu Bloorju, strokovnjaku za baze podatkov, ki ga izvajajo približno tri desetletja. Dez Blanchfield, ki se s tem ukvarja že približno tako dolgo, vendar je začel že, ko je bil res mlad, in Bert Scalzo iz IDERA, ki je res čisto črni pas baze podatkov. Zato ne zadržujte, ljudje, postavljajte vprašanja - velik del tega dogodka vam je dragocen, ko postavljate dobra vprašanja in dobite dobre odgovore, zato jih pošljite skozi okno za klepet ali komponento Q in A na vaši konzoli.
In s tem ga bom izročil Robinu Bloorju - vzemite ga.
Dr. Robin Bloor: V redu, dovolite mi, da kliknem to in vidim, če se premakne - da. Ne bom posebej govoril o zbirki podatkov. To sem mislil, saj veste, ker delam uvod, prvo predstavitveno predstavitev, zato bom govoril o pričakovanih nivojih storitev in seveda o razpoložljivosti, kar je dogovor, ki je tema današnje oddaje.
In vprašanje je, veste: "Res, kaj je razpoložljivost? In kakšno vlogo igra to, da danes ljudje upravljajo podatkovne centre? "Ena stvar, ki sem jo opazil - to sem dejansko opazil nekje v 90. letih - sem delal na enem spletnem mestu in uporabniki so se začeli pritoževati, ker je bilo njihovo e-poštno sporočilo prepovedano 15 minut.
Zanimivo je bilo, ker je CTO ali kdo je bil odgovoren za IT dejansko eno od redkih krajev, kjer so v tistem času dejansko določili ravni storitev in e-poštno sporočilo ni bilo 15 minut, kar ni v nasprotju s storitvami nikogar . Mislim, da je v resnici dovoljeno biti dve uri. E-poštnega naslova ni bilo mogoče uporabiti, ampak samo zato, da ne bi mogli pošiljati in prejemati, ker strežnika ni bilo. In tak način me je opozoril na dejstvo, da od takrat opažam, da se premikam naprej, da se vse samo pospeši in tako tudi pričakovanja uporabnikov, in to vas pripelje do situacije, ko imajo ljudje lahko tri ravni storitev, vendar pogosto se bo začel pritoževati, ko ravni storitev dejansko niso kršene.
Torej, opredelitev ravni storitev, samo da - dobro, lahko je natančno odvisno od tega, o čem govorite glede ravni storitev. Govorili smo o IT sistemu ali IT aplikaciji. Običajno določite glede na uspešnost, razpoložljivost in meritve - z drugimi besedami, ravni storitve resnično ne morete določiti, če je ne morete izmeriti, zato je običajno vključena kakšna meritev in običajno gre za odzivne čase, določene transakcije in razpoložljivost sistemov v določenem časovnem obdobju in pred približno 1994–1995 je bilo resnično redko, da bi bili kateri koli sistemi na voljo za več kot običajno delovno uro. Recimo osem zjutraj do šeste ure zvečer, da bi lahko normalno razporedili - in ljudje so gradili sisteme in tako in to je pomenilo - v mojih mislih, zlasti z bazo podatkov, bi lahko bazo konfigurirali na poseben način in kot šaržno okno se je začelo krčiti, spet se je začela pojavljati potreba po razmišljanju v nekaterih sistemih in nato v drugih sistemih, nato pa smo dobili storitev ali arhitekturo, ki je začela ustvarjati odvisnosti med sistemi, ki prej niso bili odvisni od drug drugega, kar vse še poslabša. Stisnili smo glede razpoložljivosti sistemov.
Pri tem sem govoril o razpoložljivosti, vključuje varnostno kopiranje in obnovitev in vključuje - kot da ni samo razpoložljivost v običajnih pogojih, o katerih govorimo; obstaja veliko različnih načinov, s katerimi lahko aplikacija ne uspe. Veste, lahko pride do okvare strojne opreme ali pa do okvare baze podatkov, lahko pride do okvare programske opreme in obstaja veliko različnih vrst teh stvari, in ko se pojavi, morate biti sposobni obnoviti, zato morate tudi nazaj gor sisteme. Torej mora obstajati shema varnostnega kopiranja sistema in tudi na številnih spletnih mestih danes potrebujete sposobnost za reševanje po nesreči, če poruši celotna zgradba. Tu je nekaj omembe vrednega in o tem bom pisal čez minuto, toda poslovni procesi, tudi storitveni nivoji so dejansko ravni storitev, ki so resnično pomembne za podjetje. IT mora samo opraviti svoj del tega in v skladu s kakršnim koli dogovorom.
Ravni IT storitev so običajno odvisne od ravni storitev poslovnih procesov, vendar je bilo tako, kot je bilo pred 15 leti resnično zelo redko, da ima katera koli organizacija natančno določene ravni storitev, še vedno precej redko, da imajo organizacije natančno določene ravni storitev za poslovne procese. . To se zdaj nekako dogaja; to ni nekaj, kar že dolgo traja.
To so pospeški in časovne ovire, treba je omeniti le časovne ovire. Postopoma prehajamo v svet obdelave dogodkov in zaradi tega postopoma prehajamo v svet v realnem času in zaradi tega postopoma prehajamo v razpoložljivost, da bomo potrebovali 24 do 7, kar je dejansko težko za številne sisteme - to je težko dosegljiv. Ali je zelo drago ali pa boste morda morali dejansko spremeniti sisteme, se celo premakniti v drugo bazo podatkov, drugo različico programske opreme baze podatkov, ki jo uporabljamo.
Tudi te časovne ovire - in to vedno rad omenim, kadar imam priložnost - to so časovne ovire, s katerimi se spopadajo naše aplikacije; aplikacije morda želijo biti čim hitrejše, takrat programska oprema govori s programsko opremo. V nekaterih situacijah res ni nobene sprejemljive licence, želite biti čim hitrejši in tiste poslovne situacije, kot so tržne situacije, ko oseba, ki pride z nakupnim naročilom, prejme slabšo ceno kot nekdo kdo je prvi, zato je hitrost programske opreme res pomembna.
Spodaj veste, da je najboljši odzivni čas, ko se dejansko ukvarjate s človeškimi bitji, ena desetina sekunde, ker gre za odzivni čas človeka. Ni treba, da greš hitreje od tega, ker človek tako ali tako ne bo opazil. Med 1.1 in štirimi sekundami je čas čakanja, ki ga bodo ljudje običajno prenašali, a ko greš približno štiri sekunde, se lotijo česa drugega, zato se resnično ukvarjaš s skupnimi aktivnostmi.
Tako lahko vidite, da so določeni časovni okviri in dan, teden in meseci za tiste stvari, pri katerih je vedenje paketov smiselno, in zato niste v svetu obdelave dogodkov, zato je razpoložljivost morda precej drugačna glede na to, kar potrebujete da bi lahko zagotovili. Toda takoj, ko ste v svetu dogodkov, potem ste v razpoložljivosti 24/7 in je sprememba tehnologije dejavnik, ko tehnologija napreduje hitreje in hitreje, zato se razpoložljivost morda ne bo povečala; samo ostane tak, kot je.
To je kompleksnost plasti in ne želim se s tem ukvarjati v nobeni globini, tukaj je treba samo tri stvari razmisliti. Obstaja infrastrukturna raven, to je navpična os, nato je raven storitev katere koli aplikacije in nato raven poslovnih storitev, ki so odvisne druga od druge in jih je treba upoštevati če dejansko želite ustvariti odzivno okolje, kjer so ravni storitev v bistvu dosežene.
Potem ste tukaj spodaj, ki so pravkar predstavljene baze podatkov, vendar lahko znotraj sistema storite karkoli, veste, da ste dobili nonstop konfiguracijo, kar pomeni, kar piše: nikoli se ne ustavi. Dobili ste vročo stanje pripravljenosti, kjer na tak ali drugačen način obstajajo različni načini za dosego tega cilja, vendar tako ali drugače, če baza podatkov ne uspe, se preklopi na vročo stanje pripravljenosti in je zelo malo zaostajanja v časovnem obdobju, do katerega bi uporabniki verjetno opazili, a veliko ne bi opazili.
Topla pripravljenost je bolj podobna 20-minutnemu preklopu, kjer vsi pokličejo službo za pomoč in kukajo na mizo za pomoč, medtem ko se baza podatkov preklopi v stanje pripravljenosti. Potem pride do ponovnega zagona, kjer lahko traja zelo dolgo. Opozoriti velja, da se lahko katera koli aplikacija ali katera koli baza podatkov nahaja v kateri koli situaciji, odvisno od tega, kaj se dejansko dogaja in od tega, kakšen nivo storitve dejansko zahteva aplikacija.
Iz tega želim samo poudariti krivuljo zahtevnosti. Kompleksnost izhaja iz vozlišč in povezav, odvisnosti. V svetu, v katerem živimo, število vozlišč in povezav, vključenih v karkoli, še naprej narašča, zato ste na tej vrsti uporabne krivulje. Če lahko pogledate, kako se kompleksnost povečuje in kako se časovne dimenzije zmanjšujejo, potem veste za raven razpoložljivosti, ali obstajajo časovni cilji, se verjetno zmanjšujejo?
In naravna evolucija je zato usmerjena v neprekinjeno delovanje, kar je seveda najdražje - vsaj po mojih izkušnjah - je najdražja konfiguracija, ki jo lahko ustvarite. Na tak ali drugačen način mora vsaka organizacija, ki razmišlja o tem, v resnici razmišljati ne le o tem, kaj se dogaja zdaj, ampak o tem, kaj se bo zgodilo v prihodnosti.
Mogoče je zadnja točka, ki jo želim poudariti, da je upravljanje ravni storitev nenehna dejavnost; ni nekaj, kar veš, da imaš projekt, narediš ga in je konec. Ne gre, ker se stvari kar naprej spreminjajo. Ko sem to rekel, bom žogo poslal Dez.
Dez Blanchfield: Hvala Robin. Všeč mi je tvoj diapozitiv. Pravkar smo začeli s ponovitvijo, mislim, da gre za film "Iskanje Nemo 2". Nemo si iskal razpoložljivost v obliki devetih, kar se mi je zdelo simpatično. Vedno težko početje. Ko pomislim na produktivnost, razpoložljivost in visoke zmogljivosti, je prva slika, ki mi pride na misel, saj sem odraščala na Salomonovih otokih v bližini vulkanov in na ekvatorju, v mojem podatkovnem centru izbruhne vulkan; vedno imam v mislih to sliko, da bi se to lahko zgodilo, če se kaj zalomi. Ta slika ljubke Mt. Etna, ki je severovzhodni vogal Sicilije, ki je tik ob Kataniji.
Moj pristop k temu je, da se pogovarjam z vami in vam omogočim nekaj sprejemanja na isti ravni, ki jo redno opravljam v sejni sobi iz C-paketov in vodje poslov, da bi se pogovarjali o tem, kaj lahko vpliva na vašo organizacijo iz komercialnega ali tehničnega vidika in vrste inženiringa.
Razmisliti moramo o tem, kako in kaj odvzamemo od tega in kako bomo potem obravnavali nekatere izzive, o katerih govorimo, ko govorimo o visoki razpoložljivosti in vzdržljivosti, zlasti o avtomatizaciji in platformah.
Vprašanje, ki si ga na začetku postavljamo, je, kaj pravzaprav mislimo, ko govorimo o sistemih baz podatkov in razpoložljivosti platforme baze podatkov? Kaj pravzaprav pomeni govoriti o dejanskem izzivu, da nekaj naredimo na voljo tako, kot je Robin spregovoril v sporazumu o ravni storitev, nameščenem preslikavo tega, kaj dejansko potrebujemo in želimo?
Današnja resničnost je takšna - in dejansko je v mojih glavah nekaj največjih resničnosti - danes je vse dejansko na osnovi podatkovnih baz. Danes je zelo malo sistemov, ki so zgrajeni in zgrajeni tako, da se stvari samo shranijo v datoteke ali pa je nekakšen ploščaten dnevnik datotek; nepomembno je, da vse temelji na bazi podatkov. Zaradi tega imamo to potrebo, da nehamo razmišljati o razpoložljivosti teh baz podatkov, o različnih sistemih in aplikacijah ter orodjih, ki so odvisne od njih, in se zanašati na njih za zagotavljanje storitev, ki jih želimo dostaviti, prodati ali porabiti . In vsa infrastruktura okoli njega.
Pravzaprav toliko, ko razmišljate o velikih motnjah podatkov pozno, zlasti digitalnih domorodcev ali domorodcev v oblaku, nekaterih podjetij, ki se pojavljajo kot Uber in Airbnb in tako naprej, in nekoliko starejših PayPals in eBaye sveta - obseg in velikost teh organizacij sta mogoča le zaradi sodobne tehnologije baz podatkov in moderne infrastrukture v oblaku. Brez tega brez dodanih sposobnosti zagotovo ne bi obstajali. Zamislite si scenarij, ko bi na eBay lahko prišli le med 9:05 in 9:25, ker je bil preostali dan na voljo, ker je poskušal narediti iCloud ali varnostno kopijo ali kaj podobnega, preprosto ne bi imel delal.
In tako obstajajo tudi druga ključna področja, ko razmišljate o našem vsakdanjem življenju, kot veste, na drobno, bančništvo, finance in letalske družbe in tako naprej. Velike industrijske skupine, kot so letalska logistika, prevozništvo, vlada kot celota, obstaja nacionalna varnost in policija itd. Vse te panoge, vsi ti tržni segmenti, vsi ti organi, skupine so odvisni od njihovega okolja in delovanja.
Torej, glede na to imamo v mislih tudi drugo pripombo, o kateri moramo razmišljati, drugo odločitev, o kateri bi vas rad pustil, da razmišljate, in to je, da je naš svet zdaj, čemur pravim "vedno naprej". Stalno smo povezani in to bo tema, ki jo boste redno slišali, zato jo bom ponovil in ponovil. Zdaj imamo pametne telefone v rokah ves dan, vsak dan. Ne izklopimo jih, postavimo jih ob posteljo, vedno jih uporabljamo kot budilke, uporabljamo jih kot fotoaparate in fotografiramo, te fotografije potisnejo v oblak.
Vedno so vključeni, stalno povezani mentaliteti. V resnici obstaja fant kovanec, ki ga rad uporabljam, in to je, da zdaj nekako živimo Fitbit generacijo, kjer merimo vse, spremljamo vse, in to je treba zapisati in to bo šlo nekam.
Obstaja pa še ena fraza, s katero vas bom pustil, in to je, da je nekje devet ur, ves čas. To je svet 24/7/365, v katerem živimo. Zemlja se nenehno vrti okoli Sonca in v nekem trenutku in času, vsako uro dneva je devet ur. In to pomeni, da ljudje vstanejo iz postelje in poskušajo narediti stvari, kupiti stvari, namestiti stvari itd.
Kaj torej mislimo, ko govorimo o visoki razpoložljivosti? No, sliši se res očitno, dokler se ne začnete potapljati v podrobnosti. Torej, veste, ko pomislimo na "OK, kaj pomeni velika razpoložljivost?" No, resničnost je, da srebrne krogle ni. Gre za precej kompleksen koncept, saj se je Robin povezal z nekaterimi temami, ki jih je omenil, kot so merjenje razpoložljivosti in sporazumi o ravni storitev. To primerjamo z zadevami, kot so: imam ta vprašanja, ali je čas za naprej? Ali nas skrbijo stvari, kot je tisto, čemur pravimo pet devetih, ki jih bom šel čez minuto. Ali menimo, kaj je s sporazumi o ravni storitev? Na primer, v sporazumih o ravni storitev, mislim, da prihaja do zamud, tričrkovna kratica za sporazume o ravni storitev postaja v teh dneh vse bolj kritična.
Medtem ko grete skozi celoten postopek nastanka in samodejnega gostovanja pri zunanjih izvajalcih podatkovnih centrov tretjih oseb in zunanjim izvajanim upravljanim storitvam, zdaj bomo vse v oblaku. In resničnost je, ko govorite o oblaku, gre samo za resnične računalnike drugih ljudi. In to pomeni, da ne upravljate infrastrukture, ne uporabljate sistemov in vedno ne uporabljate oblaka. Delate infrastrukturo, postavljeno kot platformo, zato je še bolj pomembno pri storitvah prodajnih sil. Zdaj si predstavljajte na primer prodajo, saj veste, da se ne dotikate nobene te infrastrukture, ampak se samo prijavite v spletni vmesnik.
Torej, edini mehanizem, ki ga imate v svetu oblakov in zunanje zunanje infrastrukture katere koli oblike za nadzor nad sporazumi o ravni storitev, to je edini mehanizem, ki ga imate, in če ljudje ne izpolnjujejo vaše namestitve, potem bodisi zdržijo kazni in zmanjšanje zneska denarja, ki ga plačate ali pa jih preprosto ne plačate.
Torej, to spomni na celoten izziv, kako veste, kako upravljamo z visoko razpoložljivostjo? Kako upravljamo s posodobitvijo razpoložljivosti, če ne gre za vašo infrastrukturo - na primer gre za SLA. Če gre za vašo infrastrukturo ali celo, če gre za infrastrukturo nekoga drugega kot z vidika oblikovanja. Govorili smo o uravnoteženju obremenitve z modelno znanostjo, ali gre za patent za odpornost na napake?
Ali v svojih arhitekturah izvajate aktivno ali aktivno pripravljenost? Imate več strežnikov, več platform za shranjevanje? Kako delujejo te platforme za shranjevanje? Ali se med sabo posnemajo, ali se zrcalijo drug drugega? Ali izvajate RAID? Kakšno vrsto RAID uporabljate za odvečno shrambo? Ali izvajate RAID na ravni diska? Ali imate platformo za shranjevanje predmetov, ki se ponavlja v modelih pogonov in modelskih sistemov in pogonov? Ali je to N plus eno za vsak majhen del infrastrukture? Ali dodate še enega in ali je v istem podatkovnem centru ali drugem podatkovnem centru? Ali ste ustvarili patent za oblikovanje, ki na primer ne predstavlja niti enega prodajnega mesta?
Vse te temeljne stvari, zdaj zvenijo kot preprosti koncepti, toda ko prideš v vsako od teh stvari, so to zelo, zelo podrobne stvari. Ko govorimo o razpoložljivosti, vedno govorimo o devetih. In kaj mislimo z devetimi? Vsi smo že slišali o teh, a le pomislimo, kaj pomenijo minuto in zakaj so pomembni.
Torej, govorimo o eni deveti, kar je le 90 odstotkov naše razpoložljivosti. Vem, da zveni zelo veliko. Ko torej govorimo 24 ob 7 do 365, če na primer samo pogledamo eno leto, ko govorimo ob devetih, kar je 90 odstotkov časa, to omogoča šestindvajset dni in pol zastoja na leto. To zaokrožimo na nekaj več kot mesec dni.
Zdaj pomislite na vsako podjetje, s katerim se ukvarjamo vsak dan - naj bo to spletno bančništvo, eBay, PayPal ali platforme za socialne medije, kot so LinkedIn, Twitter ali samo splošni trgovec - recimo, da sem želel rezervirati let, da bi v ZDA prišel iz sončnega Avstralija, ali bi bil vesel, če bi želel priti v Ameriko čez tedne, če bi moja najljubša letalska družba padla šestinštirideset dni in pol, ker je njihov ponudnik storitev rekel: "Poglejte, porabimo se za 90 odstotkov časa "? Seveda ne bi.
Ko nadaljuješ ta model, dve deveti: 99 odstotkov. No, to postane 3, 65 dni, približno tri dni in pol izpadov na leto. Je to velika stvar? No, če vodite Črni petek in prodajate posebno in ljudje lahko kupujejo le v teh dneh.
Tri devetke postanejo le 8, 7 ure na leto, toda celo 8, 7 ure na leto, to je zapored neprekinjeno osem ur našega časa. Pa da v bančništvu in financah, zdravstvu - če gre za bolnišnico, bi to lahko stalo življenja. Ko se povzpnete, so štiri devete 52 minut, pet devetih pet minut, šest devet pa v bistvu 30 sekund. Šest devetih je izjemno veliko, in ko se povzpnete po tej lestvi, ko se vzpenjate na to božično drevo devetk, več kovin se povzpnete, težje je oblikovanje, okolje in ploščad. Težje je ponuditi to storitev in če razmišljate o zmanjšanju števila časa, ki ga imate za zagon varnostnih kopij, upravljanje, popravilo, okna za vzdrževanje za kakršno koli okvaro - vsi ne trivialni izzivi - in vse se dejansko zmanjša na odstotek izpadov.
Ključno pri tem bi rad povedal, da ni srebrne krogle, kot sem že omenil. Kar zadeva razpoložljivost, ni "ene velikosti, ki bi ustrezala vsem." Morda imate določeno vrsto patentnega dizajna, ki ustreza ključnim industrijam. Z enakimi izzivi se soočajo vse banke. Nekatere so lahko maloprodajne banke, nekatere so lahko premijske banke. Nekatere banke se morda osredotočajo na trgovanje in naložbe, upravljanje premoženja. Nekateri so morda izključno potrošniški. Nekateri so morda samo internetni, ki nimajo prodajalcev, in se ukvarjajo samo z bankomati pri izdaji gotovine. Torej v teh scenarijih, tudi v bančništvu in upravljanju premoženja ter celotni industriji finančnih storitev, še vedno obstaja poseben okus ali stvar, ki jo potrebujejo, ko gre za razpoložljivost.
Ko torej pomislimo na razpoložljivost v navadni angleščini, mešanico med razpoložljivostjo in visoko razpoložljivostjo - mislimo, da sta ista stvar, ampak v resnici sta kreda in sir. Razpoložljivost je, povedano sem povedano, v angleščini, merilo časa, ko strežnik ali proces deluje normalno ali na splošno, je vezan na njihovo uporabo. To samo pomeni, kako opisujemo, ali je na voljo ali ne. Ko govorimo o razpoložljivosti, smo pogosto v tej pasti razmišljanja, "zagotavljam jo v razpoložljivi obliki", v primerjavi z visoko razpoložljivostjo za zaščito varnosti te infrastrukture.
Visoka razpoložljivost, v drugem smislu v navadni angleščini, je zasnova, pri kateri implementirate ali dosežete nekakšen rezultat in razpoložljivost podatkov, zlasti kadar skoraj ves čas - 24/7/365 dni na leto - ta razpoložljivost pride do nekaterih od teh devetih. Neizmerno ne pomeni 100 odstotkov. Sto odstotkov tehnično v resničnem svetu v nobenem okolju ni mogoče. Zelo težko je za en strežnik v operacijskem sistemu z bazo podatkov na njem, z nameščeno platformo in na tej aplikaciji mu lahko dostavite in pričakujete, da se bo izvajal stoodstotno. Torej začnemo razmišljati o dizajnih. Ali imamo odpuščanje, ali imamo več diapozitivov za ponovitev? Potem, ko ga napišete v navadno angleščino, je zanimivo, kako različna je tematika razpoložljivosti v primerjavi z visoko razpoložljivostjo.
Mislil sem, da bom to postavil v resnično preprosto grafično obliko, samo da bi nam predstavil, kako je to videti, ko se začnete spoprijeti z izzivom povečanja razpoložljivosti pri zaščiti storitve. Na spodnjem levem kotu imamo eno samo devetko. Izložil sem pet devet, o katerih na splošno govorimo. Šest devetih je malo nezaslišano. Ko govorimo o petih devetih v spodnjem levem kotu, približno 35 dni približno odpovedovanje, to poskušate zagotoviti, ker je nizkocenovno in nizko zapleteno okolje, ker imate številne stvari, ki vam ne morejo uspeti in ki jih lahko še vedno izpolnjujejo sporazume o ravni storitev.
Ko pa greš po dnu od leve proti desni in prideš do točke, ko je na sliki več devet, dobite scenarije, kjer začnete razmišljati o podvajanju sistemov in platform. Morate razmišljati o združevanju in virtualizaciji različnih delov infrastrukture. Razmisliti morate o geolokaciji teh grozdov, več mestih podatkovnih centrov in morate razmišljati o vrsti industrije in tržnem segmentu, ki ga ciljate. Kakšno raven storitve morate izpolniti? Katero ponudbo storitev iščete? Območja, ki so v realnem času na osnovi kartic in sporočajo o komunikacijah. Ali gre za vojaške službe? Torej ta graf gre od spodaj levo navzgor desno, in ko pridete skozi to krivuljo, se stroški in zahtevnost povečajo. Ko boste dobili bolj zapletena in zahtevnejša okolja, boste potrebovali več devet.
Ta graf na primer deluje zelo podobno: opisuje zgodbo med komponento stroškov v primerjavi z želeno komponento razpoložljivosti. Torej, v zgornjem levem kotu preslikamo zelo razpoložljive zapletene sisteme, stroški, ki nastanejo, če ta razpoložljivost upadejo v primerjavi s koristjo razpoložljivosti v nič izpadu. Na primer, če imamo na levi strani okolje, kjer so stvari propadle, lahko povzročimo finančne izgube. Imamo pravne posledice, ki so lahko posledice na ravni poslovne strategije in strategije.
Verjetno obstaja celo vrsta moralnih vprašanj v zvezi s tem, ali imajo storitve koristi. Če gre za zdravstveno industrijo in začnejo s stroški izpada, vplivom na stranke, zmanjšanjem zadovoljstva strank, produktivnostjo osebja, produktivnostjo uporabnikov itd. Te stvari vplivajo, če razmišljamo o oblikovanju zelo zapletenih, močno odvisnih, zelo tvegano okolje, kjer obstaja potencialno tveganje za izpad in s tem izgubo.
Na desni strani skušamo iskati scenarij, v katerem, če vlagamo visoke stroške in načrtujemo v oblikovanje, vlagamo v inteligentno izvedbo. Vlagamo v zagotavljanje znanj in sredstev ljudem, zelo cenjeno omrežje in zelo cenjeno operativno okolje ter strojna in programska oprema. Dobimo visoko razpoložljivost, vendar pride z visokimi stroški. Torej nihajno magično nihalo mesto optimalnega položaja na sredini, kjer se prekrižajo, kjer imamo nekoliko znižane stroške, in vedno večja razpoložljivost, ki žonglira med ravnmi devetih in visoko razpoložljivostjo, ki je neprekinjena razpoložljivost in to je nenehni izziv, s katerim se bomo srečali, koliko denarja ste pripravljeni vložiti, da dosežete raven storitve, ki jo iščete?
Imamo tudi temo, v katero se ne bom spuščala v podrobnosti, ampak samo želim, da to odvzamete in razmislite. Razlika med povprečnim časom med odpovedjo v vašem dizajnu in povprečnim časom za obnovitev. Z drugimi besedami, ali vlagate v kakovostnejšo infrastrukturo, bolj kakovostno oblikovanje, kakovostnejšo strojno in programsko opremo ter bolj kakovostno usposobljeno osebje in vire za inženirske stvari in zmanjšanje povprečnega časa med odpovedjo, povprečni čas, ki je potreben za iskanje odmora v nasprotju znižanje naložb v infrastrukturo, vire in oblikovanje ter slepe patente, visoko sposobnost obnovitve? Z drugimi besedami, če se kaj zlomi, morate vklopiti veliko. Če ima nekdo prenosnik in umre, imaš rezervni. Izročite jim jih in čez 30 sekund se prijavijo. To so zelo različni konci droga. Zgornji del sklepa, da si inženir z visokimi stroški in visokimi naložbami, da se izognete neuspehu, spodnji pa pravi, da "bom sprejel, da pride do okvare, zato bom inženir okoli tega pripravljen na neuspeh. in hitro okrevati. "
Kot sem že omenil, kjer bi lahko rekel: "Moja razpoložljivost ni vaša razpoložljivost." Torej, ko gre za okolja baz podatkov in podporo infrastrukturi, zagon baze podatkov in njeno zaščito ter zagotavljanje visoke razpoložljivosti, v resnici ne obstaja vse na enem mestu . Vsak ima svoje potrebe in želje. Zato si morate zastaviti ta temeljna vprašanja, ki vam jih bom pustil, in to je: kaj si lahko privoščite vaša organizacija? Ne govorim samo o dolarjih in centih. Kot organizacija govorim, kaj si lahko viri, čas in trud in podobno privoščite, kolikor lahko zagotavlja raven razpoložljivosti? Tudi kaj lahko vaše podjetje podpira? Torej, trenutne zmogljivosti, trenutne sposobnosti, trenutna infrastruktura, trenutno financiranje, ki ga lahko zberete. Torej, žongliranje med tistim, kar si dejansko lahko privoščite, in tistim, kar lahko podpirate, je zanimivo ravnovesje.
Nato si morate zastaviti tudi vprašanja: Katere spretnosti in tehnologije imate v svoji družbi? Ali lahko oddate del tega izziva? Lahko potem stvari premaknete v oblak? Če imate infrastrukturno storitev poleg programske storitve, boste ostali brez tega sklada, ko greste naprej navzgor. Torej bi morali več vlagati v platforme in storitve in ne skrbeti za del infrastrukture ali pa bi morali na programsko opremo gledati kot na ponudbo storitev, ker vam ne bi bilo treba skrbeti za platformo?
Kakšen trg in potrošnika ali kupca servisirate? Mislim, če ste telekomunikacija in mora nekdo dvigniti telefon in ves čas dobivate ton klicanja, je to zelo drugačen izziv, da odprete majhno trgovino med ponedeljkom in petkom, devet do pet in zaprete za uro v času kosila kot brivec iz vogala. Torej morate dolgo in trdo razmišljati, kako to deluje in kaj to pomeni za vašo organizacijo, kaj morate zagotoviti.
In potem žonglirajte med tistim, kar je v prostorih, tistim, kar je zunaj, in potencialno, kaj je v oblaku. Kot sem že rekel, to izvira tudi iz časovnih izzivov. Tako ostanemo na zadnjem vprašanju, ki se ga veselim, da bodo naši prijatelji iz IDERA povedali, kako se lotevajo teh stvari, in to je dober žongliranje med ujemanjem želene in zahtevane razpoložljivosti z uspešnostjo ter tem, kaj vaše podjetje potrebuje in kaj vaš trg in potrošniki potrebujejo.
In resničnost je, da ni zloben podvig. Če želite razmisliti o teh stvareh, bo potreben čas, trud in denar. In vedno gre za vlaganje v sposobnost ljudi in veščin ter vlaganje v programsko opremo in orodja za avtomatizacijo nekaterih teh procesov in ljudem zagotovitev pravih orodij in ustreznih sistemov, da njihovo življenje ne postane samo boljše, ampak tudi možno, ker spremljate zelo obsežna okolja in ščitijo in upravljanje teh velikih okolij pogosto presega posamezne človeške zmožnosti.
Torej, s tem v mislih, upam, da sem postavil prizorišče za odličen pogovor za naše prijatelje v IDERI, da bi spregovorili o njihovi platformi in orodjih, in na koncu se veselim, da bom na koncu postavil nekaj odličnih vprašanj. In bom prenesel naprej.
Dr. Robin Bloor: V redu. Bert, pravkar sem ti dal ključe, ga vzemi.
Bert Scalzo: Hvala! Hvala, Dez in Robin. Nadaljeval bom s temo visoke razpoložljivosti vaših podatkov. In dejansko bom uporabil veliko tega, o čemer je Dez ravnokar govoril. Torej, izbire, devetke, kompromisi, cenovna cena. Poskušal bom to povedati več glede na skrbnika baze podatkov ali nekoga bližje rovu, kako bi to gledali? Kako bi to arhitektirali? In kaj pomenijo te odločitve
Zdaj bom poskušal biti agnostik baze podatkov. Ne bom na primer narisal rešitve, ki je značilna za Oracle ali SQL-Server, ampak bom sestavil, recimo, generično arhitekturo, ki jo ponujajo vsi ponudniki baz podatkov, nekaj v tej smeri. Vsi ga imenujejo z različnimi imeni, toda to je skupna izbira, in to želim pogledati tako s poslovnega kot tehnološkega vidika in kako se nanaša na poslovne zahteve.
Izhajati želim iz najbolj osnovne rešitve psevdo z visoko razpoložljivostjo prek možnosti, ki jih imate na rešitvah na nivoju skladišča, na ravni virtualizacije, pri rešitvah na bazi podatkov. Potem bi vas rad seznanil tudi z dejstvom, da so vse izbire na voljo tudi v oblaku.
Torej, spet bom poskušal ostati dokaj agnostik baze podatkov. Zdaj o večini stvari, o katerih bom govoril, vem, da obstajajo v Oracle, SQL Server, MySQL, PostgreSQL. Obstaja tudi nekaj prodajalcev drugih proizvajalcev, ki izdelujejo orodja, ki bi vam dala tudi dodatne arhitekture, ki bi jih lahko upoštevali. In kot je Dez pravkar povedal, nobena rešitev ni najboljša; vse je odvisno. Toda v tem, kar bomo gledali, obstaja eno univerzalno dejstvo, ali bo v njem več gibljivih delov, zato bodo bolj zapleteni in zato dražji.
Torej, vsi vemo, da so podatki pomembna prednost. In vsi vemo, da je hiter dostop do podatkov vedno lep. Vendar je zanesljiv dostop do podatkov ključnega pomena. In kot si je govoril s svojimi devetimi primeri, si res lahko privoščite 36 ½ dni zastoja? Ključno je, da so ti podatki ves čas na voljo. In tako lahko izpadi stanejo celo bogastvo, tako v smislu izgubljenih prihodkov, še pomembneje pa je, da izgubijo stranke ali izgubijo dobro ime kupcev. Dal bom dober primer; če je določeno spletno mesto, kjer nakupujem, počasen, lahko poskusim najti novo spletno mesto, ki prodaja podobne izdelke po podobni ceni, ki nimajo počasnih spletnih mest. In tako ne gre samo za izgubo stranke, temveč za dobro voljo, ki ga ima stranka do vas.
Zdaj je strojna oprema v teh dneh precej cenejša, zato je povpraševanje po veliki razpoložljivosti vedno več. In spet, vodil nas bo v oblak, ko bomo to pogledali. In imamo ponudbe na različnih ravneh: prodajalci pomnilnikov, prodajalci baz podatkov, ponudniki virtualizacije in zdaj celo ponudniki oblakov. In kar je z oblakom res zanimivo, je potem, ko narišem vse te čudovite slike teh arhitektur, ki bi jih lahko gradili v oblaku, velikokrat le nekaj potrditvenih polj, ki jih preverite. In pravite: "Želim kopiranje po geografskih regijah." Potrdite polje. "Želim kopijo ključnih komponent strojne opreme." Potrditveno polje. In če razumete slike, včasih v oblaku le preverite nekaj polj, da sestavite sliko, ki jo imate v mislih.
Ključno je, kakšne so poslovne zahteve za visoko razpoložljivost? Na primer, ali moram skrbeti le zaradi okvare na enem mestu ali ga moram imeti na več mestih? Z drugimi besedami, ali lahko imam en računalniški center in mi je vseeno, če en center deluje brez povezave? Ne postavljam poslovne zahteve, da se razširi na več spletnih mest. To je poslovno vprašanje. Pomembno je vedeti, kako podjetje zaznava odgovore na to vprašanje, saj to običajno določa vaš proračun.
Zdaj želite pogledati tudi na raven zaščite pred okvarami. Mogoče gre za izpad električne energije? Ali bi lahko šlo za okvaro komponent? Tako kot NIC ali HBA gre slabo, tudi adapter gostiteljskega vodila. Ali gre na trdem disku? Ali gre za napako v omari? Ali gre za računalniško napako? Ali pa gre v nekaterih primerih za napako na spletnem mestu? To je drugače kot v nekaterih primerih lahko pride do okvare spletnega mesta, ker je samo spletno mesto brez povezave. V drugem primeru je lahko, da je velik del spletnega mesta brez povezave, toda z vaše perspektive je to celotno spletno mesto.
In potem, ko je Dez govoril, kaj pričakujete čas za nadaljevanje poslovanja? To je poslovno vprašanje. Če podjetje pravi, da boste morali v dveh minutah nadaljevati z delom, potem bo očitno to določilo nekatere od teh slik, za katere bom pokazal, da boste delovali, in nekatere od njih ne bodo možnosti, ki jih lahko izbiram.
In še eno vprašanje, ki se pojavi med veliko razpoložljivostjo, vendar ga ljudje pogosto pozabijo vprašati, je: "Hej, posel, če se med obdelavo transakcije kaj zgodi, kaj lahko izgubim, ko se sistem spet izgubi? " Z drugimi besedami, če lahko sistem dvignem nazaj v dveh minutah in lahko izgubim največ 10 sekund, recimo, transakcij, ki so bile med letom, je to sprejemljiv posel? In spet, to bo opredelilo, kaj je podjetje pripravljeno za to porabiti, nato pa spet, ki bo morda opredelilo, katere slike, ki vam jih bom pokazal, bodisi prijavite bodisi ne.
Začnimo torej z najosnovnejšo psevdo visoko razpoložljivo rešitvijo. To res ni velika razpoložljivost, ampak rad bi začel s tem, ker ljudje spravijo na pravilen način. Če imam strežnik in shranjevalni niz, navadno v ta strežnik postavim več NIC-jev, omrežnih kartic in jih povežem tako, da če en NIC ne uspe, sem še vedno pripravljen. Enako bom storil s svojimi adapterji gostiteljskih vodil, preusmeril se bom skozi različna stikala, tako da imam več načinov, kako priti do svoje shrambe. In dobil sem univerzalni napajalnik in imam ponavljajoče se krmilnike v svojem prostoru za shranjevanje in morda sem s svojimi diski naredil nekaj takega, kot je RAID 10. Z drugimi besedami, na tej sliki sem na več ravneh preprečil odpoved enokomponentnih. Torej me ne veže NIC ali HBA ali krmilnik ali stikalo.
Če opazite, je strežnik v rdeči barvi, shranjevalni niz pa v rdeči barvi. Še vedno imam dve področji, kjer če ne uspeta, če gre moj strežnik, sem mrtev, če gre moja omara za shranjevanje, sem mrtev. Čeprav to ni res velika razpoložljivost, vas začne videti in gledati sliko in reči: "Želim sliko, kjer ni rdeče." In to je res cilj teh slik, da nas usmerijo v pravo smer.
Torej, prva stvar, ki se zgodi, je, da bi kot DBA morda vedno želel rešitev visoke razpoložljivosti postaviti kot implementacijo baze podatkov, lahko pa je, da je na voljo, da bi jo bilo mogoče narediti kot rešitev za shranjevanje ali da bi lahko šlo za podvajanje na ravni pomnilnika. V primeru leve strani imam virtualizacijo pomnilnika. Dogaja se, da imam RAID 0 v dveh različnih omarah za shranjevanje diskov, RAID 1 pa v dveh različnih omarah za shranjevanje. Z drugimi besedami, zdaj lahko odpovem odlagalno omarico in nisem mrtva. Torej je bolje kot na prejšnji sliki, ker na prejšnji sliki - ne pozabite, da smo imeli rdečo na strežniku in rdečo na shranjevalnem nizu - in zdaj smo se malo izboljšali, zdaj nimamo več rdeče na ravni prostora za shranjevanje, sem uporabil - virtualizacija skladiščenja je rešila to težavo.
Zdaj je še en način - in tega ne ponujajo vsi prodajalci - da boste morda lahko izvedli podvajanje na ravni pomnilnika. Ne govorim o podvajanju baze podatkov, pravzaprav govorim o podvajanju blokovnih V / I-jev za shranjevanje. In to je mogoče storiti na ravni skladiščenja. In tako spet, zdaj imam na desni strani še eno sliko, kjer odstranim rdečo od spodaj, ker uporabljam kopiranje za shranjevanje.
In tako, to je še ena slika, ki je morda ali ne bo na voljo. Oseba, ki bi to upravljala, je lahko skrbnik vašega prostora za shranjevanje, ne pa skrbnik baze podatkov. Všeč mi je, da to povem, ker ljudje včasih pomislijo: "O! Visoka razpoložljivost, to težavo mora obravnavati DBA." To ni vedno res; v tem primeru bi lahko bil skrbnik pomnilnika.
Zdaj naslednjič lahko naredimo virtualizacijo strežnika kot možno rešitev. Zdaj, če se spomnite, sem imel na prvi sliki rdečo na strežniku in rdečo na shrambi za shranjevanje. V tem primeru bi se lahko z virtualizacijo preselil, v nekaterih primerih pa je to preselitev nekakšna topla selitev, v nekaterih primerih pa je lahko celo vroča selitev. Nekatere virtualizacije ali hipervizorji omogočajo premikanje virtualnega stroja med letom. In nekatere baze podatkov bodo to gibanje v letu hitro sprejele. Zdaj to ne zagotavljajo vsi hipervizorji, vendar je to ena možna raven rešitve. Zdaj sem naredil, da zgornji strežniki niso več rdeči, vendar še vedno imam na voljo skupno mapo za shranjevanje in ugibajte, kaj, ta rešitev je morda skupno prizadevanje skrbnika baze podatkov in skrbnika virtualizacije. Lahko pa gre celo za skrbnika za virtualizacijo, odvisno od stopnje preselitve, ki jo podpira ta hipervizor in ta baza podatkov.
Če se sprašujete, “Vau, kaj misli s to selitvijo? Navedite mi določen primer. "Na primer, v VM-ju, kjer lahko uporabite VMotion za premikanje navideznega stroja iz enega gostitelja v drugega in to brez izpada. Zdaj je jasno, da je na prejšnji sliki še vedno nekaj rdečega. Še vedno sem imel shrambo kot eno samo napako. Tako preidemo na naslednjo rešitev, ki je, no, naj združim shranjevanje in virtualizacijo strežnika.
Zdaj bi lahko v tej zadevi to skrbnik shranjeval skrbnik pomnilnika in skrbnik za virtualizacijo in zdaj poglejte: imam sliko brez rdeče barve. Imam veliko razpoložljivost, ker lahko preselim virtualni stroj ali delujočo aplikacijo ali bazo podatkov iz enega strežnika na drugega in imam virtualizacijo v svojem shranjevalnem nizu, tako da izvaja RAID 1 v dveh ločenih shranjevalnih nizih. Preklopil sem stikala in svoje HBA.
Zdaj sem sestavil sistem HA in to storil predvsem ne na ravni baze podatkov. Z drugimi besedami, za isto stvar sem uporabil druge tehnologije. Torej, to je rešitev. Nato preidemo na tako imenovano razširljivo gručo v skupni rabi. Res ni rešitev za HA, ampak spet to rad pokažem za sliko.
In tukaj se zgodi, da imamo dva strežnika, ki poganjata bazo podatkov in velja za eno bazo podatkov. Ne gre za dve ločeni zbirki podatkov; to ni kot gospodar in suženj, ali vroč in hladen, ali aktiven in pripravljen. To sta obe obe vozlišči, ki predstavljata eno logično bazo podatkov. In tako se zgodi, če določeno vozlišče odpove, še vedno ste pripravljeni. Torej vas ščiti pred okvaro na ravni strežnika in to v bistvu stori z nekakšnim stiskanjem virov vozlišča, če hočete, vendar imate še vedno eno samo točko neuspeha na disku. In tako, gre za povečano gručo v skupni shrambi in Oracle kliče ta pravi aplikacijski grozd ali RAC.
Zdaj je druga rešitev uporaba grozdne skupine v skupni shrambi. Torej, na levi strani imam aktivno vozlišče, na desni imam pasivno vozlišče, vmes imam srčni utrip. Imam skupino za shranjevanje v skupni rabi in to je ključnega pomena; to moraš imeti. In v bistvu se zgodi, da če se aktivno vozlišče sreča s težavami, lahko pasivno vozlišče prevzame. Te težave imajo glede licenc. Nekateri prodajalci baz podatkov omogočajo, da imate pasivno vozlišče z zmanjšano licenco za določen čas. V drugih primerih morate imeti popolno podvojeno dovoljenje. Vse je odvisno od prodajalca podatkovne baze. Vsi pa podpirajo takšno sliko, ki je, če eno vozlišče pade dol, lahko drugo vozlišče prevzame.
Običajno je to eden tistih scenarijev, kjer gre nekako, ko greš iz aktivnega vozlišča v pasivno vozlišče, boš verjetno v večini baz podatkov - ne vseh - izgubil nekaj letalske transakcije. Nato preidemo na tisto, kar si skrbnik baze podatkov res lahko pogleda, to je podvajanje baze podatkov, in obstajata dva različna načina podvajanja baze podatkov.
Obstaja fizična razmnoževanje, kar je pomembno, da na sredini slike vidite z zeleno zvezdo, da podvajanje, ki ga izvaja baza podatkov, vendar, podobno kot virtualizacija na ravni skladišča, se izvaja v bloku stopnjo. Torej, ponavljamo dejanski blok V / I iz aktivnega vozlišča v samo za branje ali pasivno vozlišče. In to velja za fizično razmnoževanje.
Zdaj pa naj grem na naslednji diapozitiv, ker je skoraj enak in je logična replikacija in edino, kar se spremeni na sliki, je, da na sredini, namesto da pošiljamo preko blokovnih V / I, v bistvu pošiljamo prek dnevnika datoteke z ukazi SQL v njem. Torej, z drugimi besedami, tisto, kar repliciramo, niso fizični V / I, ampak ukazi, ki povzročajo fizični V / I.
In tako se temu pogosto reče pošiljanje dnevnikov ali podvajanje na podlagi dnevnika. Nekateri prodajalci baz vam to sporočijo domače. Drugi prodajalci podatkovnih baz tega morda ne ponujajo, potem pa jih ponudniki drugih ponudnikov ponujajo, zato je to zelo priljubljena rešitev HA in velja za celovito rešitev. Toda ta rešitev je v prvi vrsti odgovornost DBA.
Torej ne uporabljam virtualizacije, da bi to dosegel. Lahko bi, a od tega nisem odvisen. In ne uporabljam virtualizacije za shranjevanje. Spet bi lahko, a nisem odvisen od tega. Gradim pa rešitev, pri čemer je baza podatkov glavna funkcija vožnje. Torej, to je logična replikacija.
Zdaj je mogoče kombinirati tudi virtualizacijo baze podatkov in shranjevanja. V svojem podatkovnem centru, recimo, na levi strani modre barve, bi lahko imel virtualizacijo za shranjevanje, tako da nisem vezan na določen niz shranjevanja. Mogoče pa izvajam logično podvajanje na ravni baze podatkov ali logično podvajanje iz enega podatkovnega centra v drugega, tako da se ukazi izvajajo tudi v podatkovnem centru, kar ima za posledico V / I, ne pa nujno enakega V / I, ker I ' ne pošiljam prek vhodnega / izhodnega bloka niti s shranjevalno raztopino ali z bazo podatkov, ampak pošiljam dnevnike in s tem ukaze SQL.
In to je slika, ki je zelo pogosta slika za zelo velike organizacije. Tu mi je všeč ta slika, ker če moram to nastaviti na premiso z uporabo baze podatkov, kot je Oracle, lahko to storim; to je precej dela, je precej zapleteno, veliko je gibljivih delov. Če to počnem v oblaku, lahko dobesedno samo rečem, potrditveno polje, želim dve geografski regiji, želim, da sta regiji ločeni od, veste, na različnih celinah, želim virtualizacijo na ravni skladišč v določeni geografski regiji. Lahko celo rečem, da želim možnost dodelitve vrste virtualizacije ali opredelitve z visoko razpoložljivostjo, in spet, to je drugo potrditveno polje.
In drugo, kar mi je v oblaku všeč, je še eno potrditveno polje, ki pogosto pravi: "Nočem se ukvarjati s popravki, samo ga prilepite", veste, preprosto ga vključite v potek dela vsega, kar počnete za prizorov, ves čas me zakrpajte. In čeprav so nekatere od teh slik zelo zapletene in jih je morda težko narediti v premisi, v oblaku dejansko postanejo zelo enostavne.
Zanimiva stvar je, da je enostavno potrditi vsa polja, ugibajte pa, kaj to stane več denarja na mesečni osnovi. Ker imate dva podatkovna centra, veste, da imate dva podatkovna centra v oblaku, ki ga uporabljate, boste plačali več, kot če ga uporabljate samo. Prav tako lahko spet pride do dodatnih stroškov, če delate raven skladiščenja ali virtualizacijo visoko razpoložljivost kot dodatno plast.
Zanimivo je, da čeprav je to težko storiti na mestu in ga morda prelisičite, v oblaku je to tako enostavno narediti, pa ga morda podcenite. Vedno torej vedite, kako izgleda slika in vedno veste, kakšne so posledice stroškov za katero koli sliko, ki jo gradite. Zdaj je veliko več kombinacij od tistega, kar sem prikazal tukaj. To ni popoln ali izčrpen primer. Nove tehnologije se pojavljajo v rednih intervalih, zato kdo ve - morda nisem prikazal nobene, ki se je šele pojavila v zadnjih treh mesecih. In visoka razpoložljivost je veliko pogostejša kot pred desetimi leti.
Pravzaprav ne bi štel, da bi bilo treba reči, da je za večino velikih organizacij ta dan obvezna poslovna zahteva. In rad se vračam na ta diapozitiv, ker sem pravkar rekel, da je to obvezna poslovna zahteva. In te dve mizi imam na desni strani. Zgornja je iz dokumentacije SQL Server, spodnja pa iz dokumentacije Oracle. In kar je to, to so tabele, ki vam bodo pomagale izbrati, kateri način podvajanja naj uporabljate.
In opazite, da začnete z nekaj zelo preprostimi vprašanji. Koliko podatkov lahko uporabim? In če je odgovor nič, veste, da lahko samo v tem zgornjem grafikonu izberete prvo ali četrto vrstico. Nato postavite še eno vprašanje. No, kako dolgo si lahko dovolim okrevanje? In če nekdo reče, dobro, nekaj minut ali minut, potem se odloči za vas. In potem mora biti preklapljanje samodejno ali za to potrebuje kdo ročno? In to je drugo poslovno vprašanje. Lahko rečejo, da si ga želijo samodejno, ker se ne želijo zanesti na postopek eskalacije in potem nekdo dobi dovoljenje in nato reši težavo. Samo želijo, da se to popravi.
To so vsa poslovna vprašanja in ista vprašanja, če grem dol in storim isto za Oracle. In vprašam, v redu, kakšno okvaro dovolim, kakšno trajanje, kaj lahko izgubim, kakšen je postopek obnovitve? Vse to so poslovne odločitve, tako da če mi podjetje pokaže odgovore na tri ali štiri vprašanja, je moje delo res enostavno, samo pridem sem, izberem, kateri od teh se ujema z najbližjimi, in potem to sestavim. In ne pozabite, da je v oblaku morda le nekaj potrditvenih polj za njihovo dejansko izvajanje.
In s tem me pripelje konec mojega gradiva in čas, da to odprem za vprašanja.
Eric Kavanagh: V redu, Dez, morda ti najprej Robin?
Dez Blanchfield: Vsekakor. V resnici verjetno malo krivično do tistih, ki niso na Twitterju, ampak sem samo tvitnil sliko grafa, ki ga želim vizualizirati v mislih vsem, nato pa sem želel vprašanje, ki ga je na naš klic posredoval našemu učenemu prijatelju. Ko pomislim na lastniško in odprtokodno datoteko v tem prostoru - o čemer pogosto govorimo, o lastniških bazah podatkov, ki so podobne Oracleu in Microsoftu, in tako naprej, v primerjavi z odprtokodno različico - ste na koncu s tem izzivom, v katerem je lastniški svet internetni prodajalec ali razvijalec programske opreme ali podjetje vlaga v organe za izgradnjo te zapletenosti. In na koncu imate scenarij, kjer kupite programsko opremo in vam ni treba vlagati v veliko ljudi, ker kupujete zmogljivosti, vgrajene in odprtokodne - za programsko opremo ne plačujete ali je poceni, recimo, vendar ne plačujete za programsko opremo, ampak morate vlagati v organe.
Prav tako me zanima vaše misli o žongleru, še posebej zdaj, ko prehajamo v oblačne modele, kjer lahko dobite eno ali drugo. Lahko pojdite na AWS ali Azure in vaš Rackspace karkoli in kupite kot storitev, ki zagotavlja platformo vaše baze podatkov, ali pa to storite prek odprtokodne kode. In o čem smo pravkar govorili, kaj je žongliranje med lastniškim in odprtim kodom in kako oblikovalski vzorci, o katerih govorite, začnejo učinkovati in kakšna so vaša splošna razmišljanja o tej temi, ko gremo naprej, zlasti glede zagotavljanja razpoložljivosti?
Bert Scalzo: Med velikimi predmeti, na katere naletim, ko poskušam odgovoriti na to vprašanje, se vrnem k stranki in jih vprašam o njihovih zahtevah glede uspešnosti. In zato, ker to počnem, sem ugotovil - vsaj zgodovinsko in po lastnih izkušnjah -, da gre pri kupcih, ki potrebujejo velik pretok pri podvajanju, skoraj vedno bolje s podvajanjem, ki ga zagotavlja baza podatkov prodajalec, zaradi narave, da je bolj vgrajena in je na nižji ravni, včasih pa uporablja tudi mehanizme, ki zunanjem svetu niso na voljo, niti v odprtokodni rešitvi.
Navedel bom dober primer enega primera, ki sem ga imel. Imel sem internetno podjetje, ki je uporabljalo MySQL kot svojo bazo podatkov in so bili na stari različici MySQL, na primer različice 4.0, podvajanje med vozlišči pa je bil omejujoč dejavnik pri tem, kako obsežni so lahko obseg njihovih baz podatkov. In gledali so na nakup tretje rešitve, nato pa so gledali: "No, morda lahko uporabimo katero od odprtokodnih rešitev." In kar se je v resnici zmanjšalo, je bilo, da so morali samo nadgraditi svoj MySQL na različico, mislim, da smo šli 5, 5, ker razlika med tema dvema različicama baze podatkov v različici 4.0 različice podvajanja MySQL ni bila navezana in v različici 5.0 je bilo to in to je bila pravzaprav najboljša pot zanje.
Zdaj smo si ogledali druge možnosti, toda odločilni dejavnik je bila uspešnost in ostajanje pri rešitvi ponudnika baz podatkov, nadgradnja baze podatkov pa je bila pravzaprav naša najboljša rešitev, da dobimo največjo verjetnost, da bomo dosegli potrebno uspešnost večja razpoložljivost.
Dez Blanchfield: Ja, to je zrcalo mojega razmišljanja, če sem iskren. Samo za popolno razkritje in ne bom šel v blagovne znamke, vendar prihajam iz lastniškega ozadja, ki deluje za proizvajalce originalne opreme in proizvajalce programske opreme in IOC na splošno, in to je zagotovo moja izkušnja, hkrati pa sem zelo profesionalec -odprti vir in jaz sem sodelavec kode za kup projektov, ki jih ne bomo imenovali, vendar se strinjam z vami, če ste velika organizacija - recimo, da ste banka ali karkoli že biti - vedno ne želite biti IT trgovina. Veste, kot na primer, če ste založnik časopisov ali prodajalec, ne želite biti IT trgovina, ki izdaja časopise, ampak želite biti časopisna trgovina, ki dejansko samo izkorišča IT.
In zato vlaganje v lastniške zmogljivosti, kjer razvijalci programske opreme v orodje vgradijo vse te zmogljivosti, uravnavanje obremenitve in tako naprej, ima veliko bolj smisel v primerjavi s tem, če ste zagon dotcoma ali kaj podobnega kot je ta, ki lahko vlaga v človeška telesa. Kam vidite, da to poteka?
Verjetno je moje zadnje vprašanje pred predajo doktorju Robinu Bloorju, saj vem, da nam primanjkuje časa. Kje vidite, da to poteka s trendnega vidika? Torej, ves čas ste tam zunaj, ste na robu stvari, opazite, da so ljudje sedeli in pozorni in se prebudili, da bi to morali postati komercialni del njihovega dnevnega dne - enodnevni pogovor nazaj v dvorano? Ali še vedno vidite, da zelo radi gojijo farmo, tehniki in puloverji razmišljajo o razpoložljivosti, ker se zbudijo ob štirih zjutraj, ko nekaj ne pride v poštev?
Ali menite, da se trend niha za organizacije vseh velikosti, ne očitne, kot so letalske družbe in bančništvo in finance, ampak le podjetja na splošno? Ali menite, da so se ljudje resnično izognili vrednosti, da bi zaščitili svoje okolje baz podatkov in zagotovili visoko razpoložljivost in vlaganje v to, ali menite, da imamo še kako pot? Kakšen je splošni smisel na trgu tam?
Bert Scalzo: Trenutno mislim, da še vedno obstaja vrzel, vendar to ni vrzel, saj je podjetje ne zahteva, temveč razkorak med nivoji komunikacije med obema stranema ograje. Z drugimi besedami, poslovni ljudje zelo jasno pravijo: "Te aplikacije zahtevajo veliko razpoložljivost in imajo posebne zahteve, ko rečemo velika razpoložljivost."
In tako ali drugače to sporočilo ne prehaja jasno med tehnološke ljudi. Ali pa se bodo vrnili tehnični ljudje in rekli: "Oh, no, to je zapleteno in to bo stalo več denarja", in to, to ali ono. Mislim, da se bo zgodilo to, da bo končno izginilo, saj, če sem iskreno, s tem, da je na primer v oblaku, samo preveri nekaj škatel tukaj ali tam in reče: "Zgradi mi resnično zapleteno tehnološko strukturo", obstaja res ni nobenega dobrega razloga, da se tehnološki ljudje vrnejo in rečejo poslovnim ljudem: "Oh, drago je" ali "To je težko storiti", ali to ali ono, in poslovni ljudje začnejo vedeti, da je to dejstvo.
In že sem videl v okoljih, kjer bodo, kot veste, prišli njihovi lastniki IT in rekli: "Oh, ne moreš imeti, kar bi rad. Predrago je. "In pripeljali bodo tretjo svetovalno podjetje, ki bo nato reklo:" Ne, to ni pravilno. Tukaj je, kako bi to lahko naredili. Tukaj bo to stalo. "Mislim, da imamo še vedno malo časa med komunikacijskimi nivoji med obema stranema, preden ta še postane samodejna.
Dez Blanchfield: Ja, to se vsekakor zrcali, kar sem videl tu v Avstraliji in okoli Azijskega Tihega oceana. Prepričan sem, da gre za globalno stvar. In to je, da je veliko ključnih odločevalcev iz upravnega odbora navzdol, vsi vodje poslov, veliko bolj tehnično pametni - berejo bloge, gledajo webinarja, uglašeni v različne članke in poddaje in se odpravljajo na dogodke, forume in srečanja, zdaj pa poznajo svoje možnosti in vedo, da je oblak možnost.
Prav tako vedo, da lahko to, kot ste že rekli, prinese njihova notranja sposobnost, zato mislim, da je zdaj tu zanimiv izziv, da se mora pogovor, ki je v bistvu to, kar smo danes storili tam, kjer so ljudje, nekako, začnite delati notranje in samo zaženite kosila z rjavimi torbami in si oglejte, kakšno je trenutno stanje, kakšno je naše idealno stanje, kam moramo priti? In potem, nekako, to skupaj.
Imel sem zasebno sporočilo, ki se ga bom šele zdaj hitro dotaknil. Nekdo je postavil vprašanje: "Ali je realno, da lahko dosežete 100-odstotno razpoložljivost?" In morda me boste tukaj lahko popravili, vendar bom rekel da. Zgradil sem platformo za elektronski prenos sredstev, prehod EFTPOS med hitrimi bančnimi platformami in terminali EFTPOS. To sem zgradil v začetku 2000-ih. Dejansko je na spletu 100 odstotkov časa že 17 let. V resnici je bila zgrajena pred 2000-imi leti, proizvodnja pa je šla samo v obdobju 2000/2001.
Torej, 17 let traja od razvoja do testiranja in nato še v proizvodnjo. V teh 17 letih so zelo poceni blagovni računalniki, ki niso na zalogi, z odprtokodnim operacijskim sistemom, vendar lastniško zbirko podatkov, vsakih 90 dni izvajali aktivno / pasivno menjavo, pri čemer so se uporabljali različni patenti za oblikovanje z razmnoževanjem diske v vsakem strežniku, podvajanje podatkov med modelnimi strežniki, podvajanje več podatkovnih centrov in preusmeritev iz podatkovnega centra A, ki dela 90 dni, nato pa preusmeritev v podatkovni center B in proizvodnjo.
In ko se vrti, se samodejno popravi in posodobi, tako da samo na vprašanje, ki sem ga prejel zasebno, ja, mogoče je, vendar z veliko naložbami v ta projekt z vidika oblikovanja. Infrastruktura pravzaprav ni bila tako draga, toda zasnova in testiranje ter izvedba so bili zelo dragi, da bi to dobili. Tako nam ni bilo treba porabiti veliko denarja za strojno opremo in infrastrukturo, ampak smo uporabili zelo pametna orodja, ko se oblak sploh ni pojavil.
Torej, odgovor je pritrdilen, še bolj pa zdaj z oblakom, kot smo pravkar slišali, da lahko s klikom gumba to sposobnost omogočite. To bom vrgel Robinu, ker sem prepričan, da ima tudi on vprašanja. A najlepša hvala za odgovor na moja vprašanja in danes sem zelo rada slišala vaše sporočilo. Popolnoma na krovu z vsem tem, ker zrcali vse, kar sem sam delal zadnjih 30 let.
Dr. Robin Bloor: No, v redu, jaz ga bom pobral. Ena izmed stvari, ki me je o vaši predstavitvi fascinirala, je bilo število možnosti, ki so na voljo zdaj, ko nisem bil na voljo, ko sem se moral spopadati s temi stvarmi. Zanima me kdo bo oblikoval te konfiguracije ali kdo dandanes oblikuje te konfiguracije? Kar se je včasih dogajalo, ali v svetu, ki sem ga vajen, je, da bi obstajal dokaj težak transakcijski sistem in bi vas zanimali velika uptime, velika razpoložljivost. Ker, veste, transakcijski sistem bi bil drag, če bi se kakorkoli spustil. In ne bi imeli vseh možnosti, ki ste mi jih pravkar predstavili, toda na tak ali drugačen način bi lahko s pomočjo replikacije našli način, v katerem bi ustvarili vročo stanje pripravljenosti, ki ne bi neopazno kliknilo, toda nudila bi vam degradirano storitev, dokler se ne vrnete.
In nekako gledam, kaj ste mi pokazali in razmišljali o tem, da že 15 let nisem opravil nobenega takega oblikovalskega dela, kdo to počne zdaj? Ali je to, kot je bilo v mojih dneh, nekaj, kar ste storili ob začetku projekta, zagon infrastrukture? Ali je to nekaj, kar se v organizaciji stalno izvaja? Ker prihajajo nove tehnološke izbire.
Bert Scalzo: V velikih podjetjih, ki so zelo učinkovita in učinkovita pri vseh svojih dejavnostih, vključno s svojimi IT-ji, bodo običajno imeli centralizirano arhitekturno skupino ali pa bodo imeli kakšno ime zanjo, slišal sem, da se imenuje " arhitekturna skupina «velikokrat. Njihova odgovornost bo, da poznajo vse te različne slike in kakšne so prednosti in slabosti ter kakšni so stroški. In kaj se bo zgodilo, ko določena aplikacija pogleda in reče: "Ej, izpolnjevati moram poslovne zahteve X, Y in Z. Hej, arhitekturna ekipa, kakšne so moje odločitve?"
Odgovorili jim bodo, kot so, na primer, tukaj sta na voljo dva ali trije, nato pa se na tej točki odločitev vrne na nižjo raven aplikacijski skupini ali poslovnemu sponzorju vloge. Običajno obstaja centralizirana skupina, ki ostaja nad tem in ima te podatke že pripravljene in vnaprej pripravljene.
Zdaj gre za srednje velika podjetja, kjer to ni tako formalno. Kar se bo navadno zgodilo, boste dobili enega ali dva od svojih starejših pooblaščenih oseb ali skrbnikov sistema in ti bodo neuradno navedli "strokovnjaka za domene" za tovrstno znanje. Torej, tudi v srednje velikih podjetjih se to zgodi, to se zgodi samo v neformalizirani strukturi.
Dr. Robin Bloor: To je res zanimivo. V mojih dneh nikoli ne bi razmišljali o visoki razpoložljivosti, razen o transakcijskih sistemih. No, dandanes imate seveda pretočne sisteme, ki so verjetno še večje zahteve glede razpoložljivosti. Toda, ali v zalednem delu, analitiki, skladišču podatkov, okolju DI, kdaj opazite zahteve po visoki razpoložljivosti tam?
Bert Scalzo: Ja, in vesel sem, da ste postavili to vprašanje. Nekaj dela sem opravil za maloprodajno podjetje in njihove strateške odločitve za poslovanje so v veliki meri temeljile na analizi, ki bi jo opravili iz podatkovnega skladišča. In pravzaprav jih je intervjuval revija Forbes, izvršni direktor podjetja pa je dejal: "Hej, naša cena delnic je v zadnjih petih letih zrasla za 250 odstotkov in zelo velik razlog je to, ker vemo, kako učinkovito izkoristiti naše podatke v našem podatkovnem skladišču. "Bili so tako dobri pri sprejemanju poslovnih odločitev, da je bilo za njih pravzaprav skladišče podatkov in da lahko delajo to analitiko in so bili sposobni vsakodnevno sprejemati odločitve glede na svoje operativne podatke, proizvodni sistem.
In dal vam bom dober primer, kako pomemben je. S tem konkretnim prodajalcem na drobno, fantom, ki je bil odgovoren za prodajo piva, je bil tretji najpomembnejši direktor v podjetju, saj je prinesel, veste, 60, 70 odstotkov prihodka. In tako je moral biti sposoben, da bi lahko ostal konkurenčen na tem trgu, je moral biti sposoben vsak dan, veš, katere promocije naj vodim. In to bi lahko temeljilo na, ne veste, samo času leta, ampak na vremenu, vzorcih in drugih kritičnih podatkih, ki lahko vplivajo na prodajo nečesa, kot je pivo.
Dr. Robin Bloor: No, verjetno bo takšnih stvari. Nekaj nam je časa, mislim, da bi moral predati Eriku, če bo imel kakšna vprašanja iz občinstva. Eric?
Eric Kavanagh: Ja, vse to je bilo super, Bert. Mislim, da ste v svoji predstavitvi naslovili vsa vprašanja, ki smo jih imeli od publike. Je pa zabavno gledati. Vesel sem, da ste se nekako pogovarjali o virtualizaciji skladišč in o vplivu, ki je to lahko. Torej, to so vse dobre stvari.
No, ljudje, arhiviramo vse te spletne oddaje za poznejši ogled. Torej, skočite po spletu na Techopedia.com in poiščite razdelek o spletnem prenosu. Tam bodo navedeni vsi vroči tehniki. Velika zahvala našemu prijatelju Bertu za njegovo strokovno znanje. In seveda k Dezu in Robinu. In s tem se bomo poslovili, ljudje. Pazite. Z vami se bomo pogovarjali naslednjič. Adijo.
