Av Techopedia Staff, 7. desember 2016
Takeaway: Vert Eric Kavanagh diskuterer tilgjengeligheten med Robin Bloor, Dez Blanchfield og IDERAs Bert Scalzo.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hallo og velkommen tilbake igjen. Det er klokken fire østlig tid på en onsdag, og i disse dager kan det bety omtrent en ting hvis du er i en verden av data: det er på tide igjen for Hot Technologies! Ja absolutt.
Jeg heter Eric Kavanagh, jeg vil være din vert for showet. Den er designet for å finne ut hva som er varmt, hva som skjer der ute, hva er de kule tingene som brukes i bedriften, og selvfølgelig, grunnlaget for alt vi gjør i hele dette feltet er databasen. Så vi skal snakke om å beskytte databasen din. Det nøyaktige emnet er, "Beskytt databasen din: Høy tilgjengelighet for høye etterspørseldata." Så det er et lysbilde om din virkelig. Og nok om meg, slo meg opp på Twitter, @eric_kavanagh.
For det første er dette året varmt, data er varmt, big data er veldig varmt, men det er virkelig fremdeles slags på kanten. Flere av de nyskapende selskapene benytter seg av store data i disse dager, de fleste brød- og smørorganisasjoner der ute i verden, de bruker fremdeles tradisjonelle data, og hvis dataene dine er etterspurt, vil du sikre at de er tilgjengelige fordi når systemer går ned, når data er utilgjengelige, er det når du får ulykkelige kunder, ulykkelige utsikter, du får kundesnak, du blir ulykkelig med alle slags ting, partnere osv. Så du vil ikke ha det.
Vi skal lære av noe av det beste i dag - vi får høre fra vår egen Dr. Robin Bloor, databaseekspert på rundt tre tiår på rad. Dez Blanchfield, som har holdt på med dette like lenge, men han startet da han var veldig ung, og Bert Scalzo fra IDERA, som egentlig er ganske svart i databasens belte. Så ikke hold deg tilbake, folkens, still spørsmål - den store delen av denne begivenheten er verdifull for deg når du stiller gode spørsmål og får gode svar, så send dem via chat-vinduet eller Q og A-delen av konsollen.
Og med det skal jeg overlevere det til Robin Bloor - ta det bort.
Dr. Robin Bloor: OK, la meg klikke på dette og se om det beveger seg - det gjør det. Jeg har ikke tenkt å snakke om database spesielt. Jeg trodde det, for du vet, fordi jeg holder på med introduksjonen, første introduksjonspresentasjon, så jeg skal snakke rundt de forventede servicenivåene og selvfølgelig tilgjengeligheten, som er avtalen, som er temaet for dagens show.
Og spørsmålet er å, du vet, “Virkelig, hva er tilgjengeligheten? Og hvilken rolle spiller det på den måten at folk driver datasentre i dag? ”En ting som jeg la merke til - jeg la merke til dette faktisk en gang på 90-tallet - jeg jobbet på ett nettsted og brukere begynte å klage fordi e-posten deres var nede for 15 minutter.
Og det var interessant fordi CTO eller hvem som hadde ansvaret for IT faktisk hadde et av de få stedene der de i disse dager faktisk hadde bestemt servicenivåene og e-posten som var nede i 15 minutter, ikke var i strid med noens servicenivå . Jeg tror det er lov å være ute i to timer, faktisk. Det var ikke e-posten ikke kunne brukes, det var bare at du ikke kunne sende og motta fordi serveren var ute. Og den slags varslet meg om det faktum at jeg har lagt merke til at jeg har kommet videre siden den gang, at alt bare fremskynder og det samme gjør forventningene til brukerne, og dette fører deg til situasjonen der folk kan ha tre servicenivåer, men ofte vil begynne å klage når servicenivået ikke faktisk blir brutt.
Så definisjon av servicenivåer, bare for å gi en - vel, det kan avhenge nøyaktig av hva du snakker om når det gjelder servicenivå. Vi har snakket om IT-system eller IT-applikasjon. Definer normalt sett med tanke på ytelse, tilgjengelighet og beregning - med andre ord, du kan ikke virkelig definere et servicenivå med mindre du kan måle det, så normalt er det en slags måling involvert, og det handler normalt om responstider, spesielle transaksjoner og tilgjengeligheten av systemene over en bestemt periode, og før ca 1994–1995 var det virkelig sjeldent at det var påkrevd at noen systemer var tilgjengelige i mer enn vanlig arbeidstid. Så la oss si åtte om morgenen til seks på kvelden, for å gi et normalt spenn - og folk bygde systemer og på den måten, og det betydde - i mitt sinn, spesielt med databasen - kan du konfigurere databasen på en spesiell måte og som batchvinduet begynte å krympe, behovet for å tenke nytt begynte å oppstå i noen systemer og deretter andre systemer, og så fikk vi bruk av service eller arkitektur, som begynte å gjøre avhengigheter mellom systemer som ikke tidligere hadde vært avhengige av hverandre, noe som gjør alt enda verre. Vi fikk klemmen når det gjelder tilgjengeligheten til systemene.
Poenget jeg gjorde, var når jeg snakket om tilgjengelighet, det inkluderer sikkerhetskopiering og gjenoppretting og inkluderer - det er som ikke bare tilgjengeligheten på normale vilkår vi snakker om; det er mange forskjellige måter en applikasjon kan mislykkes. Du vet, du kan få maskinvarefeil, eller du kan få databasesvikt, du kan få programvarefeil, og det er mange forskjellige arter av disse tingene, og når det oppstår, må du være i stand til å gjenopprette, og derfor må du også tilbake opp systemene. Så det må være en viss plan for sikkerhetskopiering av systemet, og du, på mange nettsteder i dag, trenger du katastrofegjenoppretting i tilfelle en hel bygning sprenges. Og noe som er verdt å nevne her, og jeg kommer til å snakke om det om et øyeblikk, men forretningsprosessene, de har servicenivåer også, og faktisk de servicenivåene i forretningsprosessen som virkelig betyr noe for bedriften. DET må bare gjøre sin del av det og i henhold til hvilken som helst avtale.
IT-servicenivåer er normalt datterselskap til servicenivåer for forretningsprosesser, men akkurat som det var ganske sjeldent for 15 år siden for enhver organisasjon å ha veldefinerte servicenivåer, er det fortsatt ganske sjelden at organisasjoner har veldefinerte servicenivåer for forretningsprosesser . Det er noe som slags skjer nå; det er ikke noe som har pågått lenge.
Dette er akselerasjons- og tidsbarrierer, det er bare verdt å nevne tidsbarrierer. Vi beveger oss gradvis inn i en begivenhetsbehandlingsverden, og på grunn av det beveger vi oss gradvis inn i en sanntidsverden, og på grunn av det går vi gradvis over til tilgjengelighet til å bli påkrevd 24 for 7, og det er faktisk tøft for mange systemer - det er vanskelig å oppnå. Enten er det veldig dyrt, eller i noen tilfeller kan det hende du faktisk må endre systemene, til og med flytte til en annen database, en annen versjon av databaseprogramvaren vi bruker.
Også disse tidsbarrierene - og jeg liker alltid å nevne disse når jeg får en sjanse - dette er tidsbarrierer som applikasjonene våre støter på; applikasjoner vil kanskje være så raskt som mulig, det er når programvare snakker til programvare. Det er virkelig ikke noen akseptabel lisens i noen situasjoner, du vil være så rask som den kan være, og de situasjonene i forretningsmessige vilkår som markedssituasjoner, der personen som kommer med kjøpsordresekund får en dårligere pris enn noen som kommer først, og derfor betyr programvarehastigheten virkelig.
Men du vet, under at når du faktisk har å gjøre med - samhandle med - mennesker, er den beste responstiden som virkelig kan kreves av deg en tidel av et sekund, fordi det handler om et menneskes responstid. Du trenger ikke gå raskere enn det fordi et menneske ikke vil merke det uansett. Mellom 1, 1 og fire sekunder er det en ventetid som mennesker normalt tåler, men så snart du går forbi omtrent fire sekunder, er de ute og gjør noe annet, og derfor er du virkelig i en batchaktivitet.
Så du kan se at bestemte tidsrammer og dag, uke og måneder for de tingene der en gruppeoppførsel gir mening, og at du derfor ikke er i en verden som behandler hendelser, og derfor kan tilgjengeligheten faktisk være ganske annerledes i forhold til hva du trenger å kunne gi. Men så snart du er i eventverdenen, så er du i 24/7 tilgjengelighet og teknologiendring er en faktor når teknologien går raskere og raskere, da vil tilgjengeligheten kanskje ikke øke; det blir bare slik det er.
Dette er lag med kompleksitet, og jeg vil ikke gå nærmere inn på dette, det er bare, du vet, det er tre ting å vurdere her. Det er servicenivå for infrastruktur, dette er den vertikale aksen, og så er det et servicenivå for en gitt applikasjon, og så er det et forretningstjenestenivå, og de er avhengige av hverandre og de må tas med i betraktningen hvis du faktisk ser på å skape et responsivt miljø der servicenivået blir oppfylt, i utgangspunktet.
Så har du, nede i bunnen her, som nettopp er representert databaser, men du kan gjøre hva som helst i systemet, du vet at du har nonstop-konfigurasjonen, som betyr hva den sier: den vil aldri stoppe. Du har den varme standby-situasjonen, der det på en eller annen måte er forskjellige måter å oppnå den på, men på en eller annen måte, hvis en database mislykkes, byttes den til en varm ventemodus og det er veldig lite etterslep i tidsbetingelser, til det punktet hvor brukerne sannsynligvis vil legge merke til, men ikke ville legge merke til mye.
Varm ventemodus ligner mer på den 20 minutter lange overgangen der alle ringer opp helpdesk og tisper ved hjelpeapparatet mens databasen blir overført til en ventemodus. Så er det en omstartssituasjon der det kan ta veldig lang tid. Det er verdt å merke seg at en gitt applikasjon eller en gitt database kan være i en av situasjonene, avhengig av hva som faktisk skjer og på hvilket servicenivå som kreves av applikasjonen faktisk.
Ut fra det vil jeg bare trekke et poeng om kompleksitetskurven. Kompleksiteten stammer fra noder og forbindelser, avhengighetene. I verden vi lever i, fortsetter antallet noder og forbindelser som er involvert i noe, bare å vokse, slik at du løper til denne typen hensiktsmessige kurve. Hvis du kan se på hvordan kompleksiteten øker og måten tidsdimensjonene krymper, vet du for tilgjengelighetsnivåer, er det tidsmål, vil de sannsynligvis redusere?
Og den naturlige evolusjonen er derfor mot direkte stopp, som selvfølgelig er den dyreste - i det minste etter min erfaring - det er de dyreste konfigurasjonene du kan lage. På en eller annen måte trenger enhver organisasjon som tenker på dette virkelig å tenke ikke bare på hva som skjer nå, men hva som kommer til å skje i fremtiden.
Kanskje det siste poenget jeg ønsker å gjøre er at styringen av servicenivåer er en pågående aktivitet; det er ikke noe som du vet at du har et prosjekt, du gjør det og det er over. Det er det ikke, fordi ting bare fortsetter å endre seg. Når det er sagt, vil jeg føre ballen til Dez.
Dez Blanchfield: Takk Robin. Jeg elsker åpningsbildet ditt. Vi har nettopp kjørt på nytt, jeg tror det er "Finding Nemo 2", filmen. Du fikk Nemo til å søke etter tilgjengelighet i form av ni, som jeg syntes var ganske søt. Alltid en tøff handling å følge. Når jeg tenker på oppetid og tilgjengelighet og høy ytelse, er det første bildet som kommer til tankene, fordi jeg vokste opp på Salomonøyene i nærheten av vulkaner og ekvator, en vulkan som bryter ut i mitt datasenter; det er dette bildet jeg alltid har i tankene om at det er det som potensielt kan skje hvis noe går bra. Dette er et bilde av den vakre fjellet. Etna, som er det nordøstlige hjørnet av Sicilia, som ligger rett ved siden av Catania.
Min tilnærming til dette er å ha en samtale med deg og gi deg et par takeawayer på samme nivå som jeg gjør i et styrerom med jevne mellomrom fra C-suiter og fagsjefer med tanke på at vi har en samtale om hva som kan påvirke organisasjonen din fra kommersiell eller teknisk forstand og hvilke typer engineering.
Vi må tenke på og hvordan - hva vi tar bort fra det, og hvordan vi går for å møte noen av utfordringene vi snakker om når vi snakker om høy tilgjengelighet og oppetid, spesielt rundt automatisering og plattformer.
Så spørsmålet vi stiller innledningsvis er, hva mener vi egentlig når vi snakker om databasesystemer og tilgjengelighet av databaseplattformer? Hva betyr det egentlig å snakke om den faktiske utfordringen med å gjøre noe tilgjengelig for et nivå som Robin snakket om i serviceavtalens installerte kartlegging av hva trenger vi faktisk og ønsker?
Så virkeligheten i dag er at - og her er faktisk et par toppverdigheter i tankene mine - i dag er alt effektivt databasedrevet. Det er veldig få systemer som er bygget i dag og bygget på en slik måte at ting bare blir lagret i filer eller er en slags flat fillogg; alltid er alt databasedrevet. Som et resultat av dette har vi dette behovet for å slutte å tenke på tilgjengeligheten til databasene, til de forskjellige systemene og applikasjonene og verktøyene som er avhengige av dem, og stole på at de leverer tjenestene vi ønsker å levere, selge eller konsumere. . Og all infrastrukturen rundt det.
Faktisk, så mye når du tenker på de store forstyrrelsene i data fra sent, særlig de digitale innfødte eller skyinnfødte, noen av selskapene som har kommet sammen som Uber og Airbnb og så videre, og de litt eldre PayPals og eBays of the world - omfanget og størrelsen på disse organisasjonene er bare mulig på grunn av moderne databaseteknologi og moderne skyinfrastruktur. Uten det, uten den ekstra muligheten, ville de ganske enkelt ikke eksistert. Se for deg et scenario der du bare kunne komme til eBay mellom 9:05 og 9:25 fordi det ikke var tilgjengelig resten av dagen fordi det prøvde å gjøre en iCloud eller en sikkerhetskopi eller noe sånt, det hadde bare ikke virket.
Så, og det er andre viktige områder når du tenker på våre daglige liv, du vet, som detaljhandel og bank og finans og flyselskapene og så videre. De store næringsgruppene som luftfartslogistikk, transportfrakt, det er myndigheter som en helhet, det er nasjonal sikkerhet og politi og så videre. Alle disse næringene, alle disse markedssegmentene, alle disse organene, gruppene er avhengige av at miljøene er i gang.
Så med det i tankene, har vi også det andre forbeholdet som vi må tenke på, den andre takeawayen som jeg vil la deg tenke på, og det er at vår verden er nå det jeg kaller "alltid på." Vi er tilkoblet permanent, og dette er et tema du vil høre regelmessig, og jeg kommer til å gjenta det og gjenta det. Vi har nå smarttelefoner i hendene hele dagen, hver dag. Vi slår dem ikke av, vi legger dem ved siden av sengen, vi bruker dem alltid som vekkerklokker, vi bruker dem som kameraer og vi tar bilder, de skyver bildene opp i skyen.
De er alltid på, permanent tilkoblet mentalitet. Faktisk er det en setningsmynt som jeg liker å bruke, og det er at vi nå slags lever Fitbit-generasjonen, som er der vi måler alt, vi overvåker alt, og det må loggføres og det kommer til å gå et sted.
Og det er også en annen setning jeg skal forlate deg med, og det er, klokka er et sted, hele tiden. Det er en verden 24/7/365 vi lever i. Jorden snurrer hele tiden rundt sola og på et tidspunkt, og tid, hver time på dagen er klokka ni. Og det betyr at folk går opp av sengen og prøver å gjøre ting, kjøpe ting, installere ting osv.
Så, hva mener vi når vi snakker om høy tilgjengelighet? Vel, det høres veldig opplagt til du begynner å dykke ned i detaljene. Så, du vet når vi tenker på “OK, hva betyr høy tilgjengelighet?” Vel, det er ikke sølvkule. Det er et ganske komplekst konsept, som Robin relatert til med noen av temaene han nevnte, for eksempel å måle tilgjengelighet og avtaler på servicenivå. Vi kartlegger det til ting som, jeg har disse spørsmålene, er det oppetid? Bekymrer vi oss om ting som det vi kaller fem ni, som jeg vil gå inn på om et minutt. Ser vi på oss selv hva som står i avtalene våre på servicenivå? I avtaler på tjenestenivå mener jeg for eksempel forsinkelser. Forkortelsen på tre bokstaver for avtaler på servicenivå er blitt mer og mer kritisk i disse dager.
Når du går gjennom hele prosessen med lokalisering og egenhosting til outsourcet til tredjeparts datasentre og outsourcede administrerte tjenester, og nå går vi helt til sky. Og virkeligheten er når du snakker om sky, det er bare andres datamaskiner. Og det betyr at du ikke kjører infrastrukturen, du kjører ikke systemene og alltid kjører du ikke skyen. Du gjør infrastruktur satt opp som plattform, så det er enda viktigere i salgsstyrketjenesten. Tenk deg salg for eksempel, du vet at du ikke berører noen av den infrastrukturen, du logger deg bare på et webgrensesnitt.
Så, den eneste mekanismen du har i den verdenen av sky og outsourcet infrastruktur, uansett form for å kontrollere det er avtaler på servicenivå, det er den eneste mekanismen du har, og hvis folk ikke møter installasjonen din, kan de enten tåle straffer og en reduksjon i mengden penger du betaler dem, eller du bare ikke betaler dem.
Så dette bringer tankene opp igjen hele utfordringen med, vet du, hvordan klarer vi høy tilgjengelighet? Hvordan håndterer vi tilgjengeligheten oppetid hvis det ikke er din infrastruktur - for eksempel handler det om SLA. Hvis det er infrastrukturen din, eller til og med om det er andres infrastruktur som designsynspunkt. Vi snakket om lastbalansering til modellvitenskap, er det et patenttest for feiltoleranse?
Kjører du aktiv aktiv, eller aktiv ventemodus i arkitekturene dine? Har du flere servere, flere lagringsplattformer? Hvordan fungerer de lagringsplattformene? Replikerer de hverandre, speiler de hverandre? Kjører du RAID? Hva slags RAID kjører du for overflødig lagring? Kjører du RAID på diskenivå? Driver du med en objektlagringsplattform som repliseres på tvers av modellstasjoner og modellsystemer og stasjoner? Er det N pluss en for hvert lite infrastruktur du har? Legger du til et annet, og er det i samme datasenter eller et annet datasenter? Har du bygget et designpatent som for eksempel ikke står for et eneste salgssted?
Alle disse grunnleggende tingene, nå høres de ut som enkle konsepter, men når du kommer inn på hver enkelt av disse tingene er de veldig, veldig detaljerte ting. Når vi snakker om tilgjengelighet, ender vi alltid med å snakke om niner. Og hva mener vi med niner? Vi har alle hørt om disse, men la oss bare tenke på hva de betyr i et øyeblikk og hvorfor de er viktige.
Så vi snakker om en ni, som bare er 90 prosent av tilgjengeligheten vår. Jeg vet at det høres veldig høyt ut. Så når vi snakker 24 og 7 av 365, hvis vi bare ser på ett år, for eksempel når vi snakker om en ni, som er 90 prosent av tiden, gir det rom for trettiseks og en halv dag med nedetid i året. La oss bare runde det til litt over en måned.
Tenk nå på enhver virksomhet som vi har hver dag - enten det er nettbank, eBay, PayPal eller sosiale medier-plattformer som LinkedIn, Twitter eller bare en generell forhandler - la oss bare si at jeg ville bestille en flyreise for å komme til USA fra solfylte Australia, ville jeg være lykkelig hvis jeg ville komme til Amerika om en ukes tid, hvis favorittflyselskapet mitt var nede i tretti seks og en halv dag fordi deres leverandør sa: "Se, vi er oppe i 90 prosent av tiden "? Selvfølgelig ville jeg ikke gjøre det.
Når du går opp denne modellen, to niner: 99 prosent. Vel, det blir 3, 65 dager, omtrent tre og en halv dag nedetid i året. Er det en stor sak? Vel, det er hvis du kjører Black Friday, og du kjører en salgsspesial og folk kan bare kjøpe i løpet av disse par dagene.
Tre nier blir så lite som 8, 7 timer i året, men til og med 8, 7 timer i året, det er påfølgende non-stop åtte timer av vår tid. Det er vel i bank og finans, helse - hvis det er et sykehus, kan det koste liv. Når du klatrer opp, er fire nier 52 minutter, fem nier er fem minutter og seks nier er i utgangspunktet 30 sekunder. Seks niner er ekstremt høy, og når du går opp denne stigen, når du klatrer opp dette juletreet på ni, jo mer ni går du opp, desto vanskeligere er designen, miljøet og plattformen. Jo vanskeligere det er å levere den tjenesten, og hvis du tenker på reduksjonen i tiden du har for ting som sikkerhetskopier som skal kjøres, administrasjon, oppdatering, vedlikeholdsvinduer for enhver form for driftsstans - alle ikke-trivielle utfordringer - og alt kommer effektivt ned på prosentandeler av strømbrudd.
Nøkkelen her som jeg ønsker å formidle er at det ikke er noen sølvkule, som jeg nevnte før. Når det gjelder tilgjengeligheten, er det ingen "en størrelse passer alle." Du kan ha en bestemt type designpatent som passer nøkkelindustrier. De samme utfordringene står alle banker overfor. Noen kan være retailbanker, andre kan være premiumbanker. Noen banker fokuserer kanskje på handel og investering, formuesforvaltning. Noen kan være rent forbrukere. Noen vil kanskje bare plassere internett og ikke engang ha fortellere og bare håndtere minibanker når de deler ut kontanter. Så i disse scenariene, selv i bank- og formuestyrings- og finansnæringsbransjen som helhet, for hver av dem har de fremdeles sin egen spesielle smak eller ting de trenger når det gjelder tilgjengeligheten.
Så når vi tenker på tilgjengelighet på vanlig engelsk, er blandingen mellom tilgjengelighet og høy tilgjengelighet - vi tror de er de samme tingene, men de er faktisk kritt og ost. Tilgjengeligheten er, jeg har satt det på vanlig engelsk, et mål på tid som en server eller prosess fungerer normalt eller generelt, knyttet til bruken. Det betyr bare hvordan vi beskriver om det er tilgjengelig eller ikke. Når vi snakker om tilgjengelighet, faller vi ofte i denne felle å tenke: "Jeg leverer den i en tilgjengelig form, " kontra høy tilgjengelighet for å beskytte sikkerheten til infrastrukturen.
Høy tilgjengelighet, i en annen forstand på vanlig engelsk, er designet der du implementerer eller oppnår en slags utfall og tilgjengelighet av data, spesielt der nesten hele tiden - 24/7/365 dager i året - som tilgjengeligheten kommer til noen av disse niere. Unødvendigvis betyr det ikke 100 prosent. Hundre prosent er teknisk sett ikke mulig i en reell verden i et miljø. Det er veldig vanskelig for en server i et operativsystem med en database på den, med en plattform som kjører og på den applikasjonen kan du levere den og forvente at den kjører 100 prosent. Så da begynner vi å tenke på design. Har vi oppsigelser, har vi flere lysbilder å gjenskape? Når du setter det på vanlig engelsk, er det interessant hvor forskjellig emnet tilgjengelighet versus høy tilgjengelighet blir.
Jeg trodde jeg ville sette det på en virkelig enkel grafisk form bare for å gi oss en ide om hvordan dette ser ut når du begynner å klatre opp utfordringen med å øke tilgjengeligheten for å beskytte oppetiden din. I nedre venstre hjørne har vi fått en ni. Jeg har lagt ut de fem niene som vi generelt snakker om. Seks ni er litt skandaløst. Når vi snakker om fem niner i nedre venstre hjørne, 35 dager omtrent det strømbruddet, er det et miljø med lavt og lite kompleksitet du prøver å tilby det fordi du har en rekke ting som kan mislykkes, og du kan oppfyll fremdeles dine servicenivåavtaler.
Men når du går langs bunnen fra venstre mot høyre, og du kommer til punktet der det er flere niner i bildet, får du scenariene der du begynner å tenke på replikering av systemer og plattformer. Du må tenke på gruppering og virtualisering av forskjellige deler av infrastrukturen. Du må tenke på geolokalisering av disse klyngene, flere nettsteder med datasentre, og du må tenke på hvilken type næring og markedssegment du sikter til. Så hvilket type servicenivå trenger du å oppfylle? Hvilken tjenesteyting du leter etter? Områder som er sanntids kortbaserte tjenester som forteller om kommunikasjon. Er det militære tjenester? Så denne grafen går fra nede til venstre til høyre, og når du kommer gjennom den kurven, øker kostnadene og kompleksiteten. Når du får mer komplekse og mer krevende miljøer, trenger du flere niner.
Denne grafen gjør for eksempel veldig lik ting: den beskriver historien mellom kostnadskomponenten kontra ønsket tilgjengelighetskomponent. Så øverst i venstre hjørne kartlegger vi svært tilgjengelige komplekse systemer, og kostnadene som påløper hvis tilgjengeligheten synker mot fordelen ved å ha tilgjengelighet i null nedetid. Så hvis vi for eksempel har et miljø på venstre side der ting er nede, kan vi påføre oss økonomiske tap. Vi har juridiske implikasjoner som kan være kommersielle implikasjoner på forretningsstrategisk nivå.
Det er alle slags potensielle, til og med moralske spørsmål rundt det å ha en tjenesteyting. Hvis det er en helseindustri og de begynner å gå gjennom kostnadene ved et strømbrudd, påvirke kundene, redusere kundetilfredshet, personalets produktivitet, brukerproduktivitet, etc. Disse tingene blir påvirket hvis vi tenker på å utforme svært kompleks, veldig avhengig, svært risikabelt miljø der det er potensiell risiko for strømbrudd og derfor tap.
På høyre side prøver vi å sikte mot et scenario der hvis vi investerer høye kostnader og planlegging i design, investerer vi i intelligent implementering. Vi investerer i å gi mennesker ferdigheter og ressurser, og vi har høyt ansett nettverk og høyt ansett operasjonelt miljø og maskinvare og programvare. Vi får høy tilgjengelighet, men det koster høy pris. Så den svingende magiske pendelflekken med den optimale posisjonen i midten der de krysser, der vi har fått litt reduserte kostnader, og økende tilgjengelighet som bare sjonglerer mellom nivåene på ni og den høye tilgjengeligheten som er kontinuerlig tilgjengelighet og dette er en en stadig utfordring for oss å møte, som i hvor mye penger du er villig til å investere for å få det servicenivået du leter etter?
Vi har også temaet jeg ikke vil gå nærmere inn på, men jeg vil bare at du tar dette bort og tenker på det. Forskjellen mellom middeltid mellom svikt i designen din, sammenlignet med middeltiden for å komme seg. Med andre ord, investerer du i infrastruktur av bedre kvalitet, bedre kvalitet på design, maskinvare og programvare av bedre kvalitet og dyktig personell og ressurser av bedre kvalitet for å konstruere ting og redusere mellomtiden mellom svikt, den gjennomsnittlige tiden det tar å finne pausen i motsetning å redusere investeringer i infrastruktur, i ressurser og design og blinde patenter, den høye evnen til å gjenopprette? Med andre ord, hvis noe går i stykker, har du mye av det å plugge inn. Hvis noen har en bærbar datamaskin og den dør, har du en ekstra en. Du overlater det til dem og på 30 sekunder logger de seg på. Dette er veldig forskjellige ender av stolpen. Den øverste gir deg ingeniører med høye kostnader og høye investeringer for å unngå fiasko, og den nederste sier at “Jeg kommer til å akseptere at fiasko kommer til å komme, så jeg skal konstruere rundt det og være forberedt på å mislykkes og kom deg raskt. "
Som jeg nevnte før, der jeg kunne si: "Min tilgjengelighet er ikke din tilgjengelighet." Så når det kommer til databasemiljøer og støtte infrastrukturen, drive databasen din og beskytte den og sikre høy tilgjengelighet, er det virkelig ingen one-stop shop . Alle har sine egne behov og ønsker. Så du må stille deg selv de grunnleggende spørsmålene som jeg lar deg stå igjen med, og det er: Hva kan organisasjonen ha råd til? Jeg snakker ikke bare om dollar og øre. Jeg snakker om, som organisasjon, hva kan du fra ressurser, tid og krefter og så videre ha råd til så langt tilgjengelighetsnivået kan gi? Hva kan bedriften din også støtte? Så de nåværende evnene, de nåværende ferdighetene, den nåværende infrastrukturen, den nåværende finansieringen du kan skaffe. Så det å sjonglere mellom det du faktisk har råd til mot det du kan støtte er en interessant balanse.
I tillegg må du stille deg selv spørsmålene: Hvilke ferdigheter og teknologi har du internt? Kan du sette ut noe av den utfordringen? Kan du da flytte ting til skyen? Hvis du har infrastrukturtjenesten bortsett fra programvaretjenesten, står du igjen uten den bunken når du går lenger opp i bunken. Så bør du investere mer i plattformer og tjenester og ikke bekymre deg for infrastrukturstykket, eller bør du se på programvare som et tjenestetilbud fordi du ikke trenger å bekymre deg for plattformen?
Hvilken type marked og forbruker eller kunde betjener du? Jeg mener, hvis du er en telekom og noen må hente telefonen og du får en summetone hele tiden, er det en veldig annen utfordring å åpne en liten butikk mellom mandag og fredag, ni til fem og legge ned for en time ved lunsjtid som en hjørnebarberer. Så du må tenke veldig lenge og hardt på hvordan det fungerer og hva det betyr for organisasjonen din, hva du trenger for å kunne tilby.
Og så sjonglere mellom det som er i lokalene, det som er eksternt vertskap og potensielt, det som er i skyen. Som jeg sa før, kommer det også fra tidsutfordringer. Så vi overlater til det endelige spørsmålet at jeg ser frem til vennene våre på IDERA å fortelle oss hvordan de takler akkurat disse tingene, og det er den fine sjongløren mellom å matche ønsket og ønsket tilgjengelighet med ytelse, og hva bedriften trenger og hva ditt marked og dine forbrukere trenger.
Og virkeligheten er at det ikke er noen mening. Det kommer til å ta tid, krefter og penger over hele linjen å tenke på disse tingene. Og alltid er det investering i mennesker og ferdighetsevne og investering i programvare og verktøy for å automatisere noen av disse prosessene og gi disse menneskene de riktige verktøyene og de riktige systemene for å gjøre livene deres ikke bare bedre, men mulig fordi overvåking av veldig store miljøer og beskyttelse og å styre de store miljøene er ofte utenfor individuelle menneskelige evner.
Så med det i tankene, forhåpentligvis har jeg satt scenen for en god samtale for våre venner på IDERA å snakke om plattformen og verktøyene deres, og jeg ser frem til å stille noen gode spørsmål på slutten. Og jeg skal videre.
Dr. Robin Bloor: OK. Bert, jeg ga deg nøklene, ta den bort.
Bert Scalzo: Takk! Takk skal du ha, Dez og Robin. Jeg kommer til å fortsette med emnet med høy tilgjengelighet for dataene dine. Og jeg skal faktisk utnytte mye av det Dez nettopp snakket om. Så, valgene, niene, avveiningene, overkommeligheten. Jeg skal prøve å legge det mer til databaseadministratoren eller noen nærmere skyttergravene, hvordan de ville se på det? Hvordan ville de arkitektere det? Og hva disse valgene slags betyr.
Nå skal jeg prøve å være database-agnostiker. Jeg har ikke tenkt å tegne for eksempel en Oracle-spesifikk eller SQL-Server-spesifikk løsning, men jeg skal tegne, la oss si, en generisk arkitektur som alle databaseleverandørene tilbyr, noe i tråd med det. De kaller det alle med forskjellige navn, men det er en type valg du har til felles, og jeg vil se på det både fra forretnings- og teknologiperspektiv, og hvordan det forholder seg til virksomhetens krav.
Og jeg vil ta utgangspunkt i hva den mest grunnleggende løsningen for pseudo-høy tilgjengelighet er gjennom alternativene du har på løsninger på lagringsnivå, løsninger på virtualiseringsnivå, på databaseløsninger. Og så ønsker jeg også å introdusere deg for at alle valgene er tilgjengelige i skyen også.
Så igjen, jeg kommer til å prøve å være ganske database-agnostisk. Nå, det meste av det jeg skal snakke om, vet jeg at de eksisterer i Oracle, SQL Server, MySQL, PostgreSQL. Det er også noen tredjepartsleverandører, som lager verktøy som også vil gi deg flere arkitekturer som du kan vurdere. Og som Dez nettopp sa, ingen løsning er den beste; det kommer an på. Men det er ett universelt faktum i det vi skal se på, er at det kommer til å være mer bevegelige deler, så det kommer til å bli mer sammensatt og derfor mer kostbart.
Så vi alle vet at data er en viktig ressurs. Og alle vet at rask tilgang til dataene alltid er hyggelig. Men pålitelig tilgang til dataene er kritisk. Og som han snakket om med sine ni eksempler, har du virkelig råd til å ha 36½ dagers driftsstans? Det er viktig at dataene er tilgjengelige hele tiden. Og slik kan nedetid koste en formue, både når det gjelder tapte inntekter, men enda viktigere, hos tapte kunder, eller ved tap av kundevilje. Jeg vil gi deg et godt eksempel; Hvis et bestemt nettsted der jeg kjøper går sakte, kan det hende at jeg prøver å finne en ny webside som selger lignende varer til en lignende kostnad som ikke har trege nettsteder. Og så er det ikke bare tapet av kunden, det er velviljen som kunden har til deg.
Nå er maskinvare mye billigere i disse dager, så det er derfor mer og mer etterspørsel etter høy tilgjengelighet. Og igjen skal jeg føre oss til skyen, når vi ser på det. Og vi har tilbud fra forskjellige nivåer: lagringsleverandørene, databaseleverandørene, virtualiseringsleverandørene og nå til og med skyleverandørene. Og det, som virkelig er interessant med skyen, er etter at jeg tegnet alle disse fantastiske bildene av disse arkitekturene som du kan bygge i skyen, mange ganger er det bare noen avmerkingsbokser du sjekker. Og du sier: "Jeg vil ha replikering på tvers av geografiske regioner." Avkrysningsrute. “Jeg ønsker replikering av viktige maskinvarekomponenter.” Avkrysningsrute Og hvis du forstår bildene, noen ganger i skyen, er det bare å sjekke noen bokser for å lage et bilde du har i tankene dine.
Nå, det viktigste er, hva er forretningskravene for høy tilgjengelighet? Må jeg for eksempel bare bekymre meg for feil på et enkelt sted, eller må jeg ha det på flere nettsteder? Med andre ord, kan jeg ha et datasenter og bryr meg ikke om det ene senteret går offline? Jeg stiller ikke noe krav til at det utvides over flere nettsteder. Det er et forretningsspørsmål. Og det er viktig å vite hvordan virksomheten oppfatter svarene på det spørsmålet, fordi det vanligvis definerer budsjettet.
Nå vil du også se ned på nivået av feilbeskyttelse. Kan det være strømbrudd? Kan det være en komponentfeil? Som at en NIC eller HBA går dårlig, en vertskapadapter. Er det en harddisk som går dårlig? Er det et lagringsskapssvikt? Er det en datamaskinfeil? Eller er det i noen tilfeller stedssvikt? Det er annerledes enn at du i noen tilfeller kan ha en feil på nettstedet, fordi selve nettstedet er frakoblet. I et annet tilfelle kan det være at en betydelig del av nettstedet ikke er frakoblet, men fra ditt perspektiv er det hele nettstedet.
Og så, som Dez snakket om, hva er forventningen til tiden for å gjenoppta driften? Det er et forretningsspørsmål. Hvis virksomheten sier at du må kunne fortsette driften i løpet av to minutter, vil det tydeligvis definere noen av disse bildene som jeg skal vise at du vil fungere, og noen av dem vil ikke være alternativer som du kan velge.
Og et annet spørsmål som dukker opp under høy tilgjengelighet, men ofte glemmer folk å stille er: "Hei, virksomhet, hvis noe skjer mens jeg er i midten av behandlingen av en transaksjon, hva har jeg lov til å tape ved gjenopptakelse av systemet? " Med andre ord, hvis jeg kan bringe systemet opp igjen på to minutter, og jeg ikke mister mer enn 10 sekunder av, la oss si, transaksjoner som var på flukt, er det da akseptabel virksomhet? Og igjen, det vil definere hva virksomheten er villig til å bruke for det, og deretter igjen, som kan definere hvilke bilder jeg skal vise deg enten bruker eller ikke bruker.
Så la oss starte med den mest grunnleggende løsningen for pseudo med høy tilgjengelighet. Dette er egentlig ikke høy tilgjengelighet, men jeg liker å starte med dette, fordi det får folk til å tenke på riktig måte. Hvis jeg har en server og en lagringsgruppe, vil jeg typisk legge flere NIC-er, nettverkskortgrensesnittkort, på den serveren og binde dem slik at hvis en NIC mislykkes, er jeg fremdeles oppe. Og jeg skal gjøre det samme med vertsbussadapterene mine. Jeg vil gå flere veier gjennom forskjellige brytere, slik at jeg har flere måter å komme til lagring på. Og jeg har en universell strømforsyning, og jeg har repeterende kontrollere i lagringsenheten min, og kanskje har jeg gjort noe som RAID 10 med platene mine. Med andre ord, på dette bildet har jeg forhindret enkomponentfeil på flere nivåer. Så jeg er ikke bundet av NIC, eller HBA, eller kontrolleren, eller bryteren.
Men hvis du merker det, er serveren i rødt og lagringsoppstillingen er i rød. Jeg har fremdeles to områder der hvis de mislykkes, hvis serveren min går, jeg er død, hvis lagringsgruppen min går, er jeg død. Så selv om dette ikke er veldig høy tilgjengelighet, begynner det deg å se og se på bildet og si: "Jeg vil ha et bilde der det ikke er rødt." Og det er virkelig målet med disse bildene, å få oss pekt i riktig retning.
Så det første som skjer er, som DBA, kanskje jeg alltid vil legge løsningen med høy tilgjengelighet som en databaseimplementering, men det kan være at det er tilgjengelig at det kan gjøres som en lagringsløsning, eller det kan være at det kan være en replikering på lagringsnivå. I tilfelle til venstre, har jeg lagret virtualisering. Det som skjer er at jeg har RAID 0 i to forskjellige lagringsskap for platene mine, men jeg har RAID 1 på tvers av de to forskjellige lagringsskapene. Med andre ord, jeg kan faktisk nå få et lagringsskap mislykkes, og jeg er ikke død. Så det er bedre enn det forrige bildet, for i det forrige bildet - husk at vi hadde både rødt på serveren og rødt på lagringsenheten - og nå har vi gjort en liten forbedring, vi har ikke lenger rødt på lagringsnivået, vi har brukt - virtualisering av lagring løst problemet.
En annen måte du kan gjøre det på - og ikke alle leverandører gir dette - er at du kanskje kan gjøre replikering på lagringsnivå. Jeg snakker ikke databasereplikasjon, jeg snakker faktisk om å kopiere I / O-blokken din for lagring. Og det kan gjøres på lagringsnivå. Og så igjen, nå har jeg på høyre side, et annet bilde der jeg fjerner det røde fra bunnen, fordi jeg bruker lagringsreplikasjon.
Og så er dette et annet bilde som kanskje eller ikke er tilgjengelig. Og personen som vil administrere dette kan være lagringsadministratoren din, i stedet for databaseadministratoren. Jeg liker å få opp dette, fordi noen ganger tenker folk på, "Å! Høy tilgjengelighet, det må være DBA som løser dette problemet." Det er ikke alltid sant; i dette tilfellet kan det være lagringsadministrator.
Nå neste, kan vi gjøre server virtualisering som en mulig løsning. Nå, hvis du husker, på det første bildet hadde jeg rødt på serveren og rødt på lagringsenheten. I dette tilfellet kunne jeg ved hjelp av virtualisering kanskje være i stand til å flytte, og i noen tilfeller er flytting slags en varm flytting, og i noen tilfeller kan det til og med være en varm flytting. Noen virtualisering eller hypervisorer gir muligheten til å flytte en virtuell maskin under flyging. Og noen databaser vil akseptere den bevegelsen raskt. Nå, igjen, ikke alle hypervisorer gir dette, men dette er ett mulig løsningsnivå. Nå har jeg gjort at de øverste serverne ikke lenger er røde, men jeg har fortsatt den delte lagringsenheten og gjett hva, denne løsningen kan være en felles innsats mellom databaseadministratoren og virtualiseringsadministratoren. Eller det kan til og med være bare virtualiseringsadministratoren, avhengig av hvilket flyttingsnivå som støttes på den hypervisoren og den databasen.
Hvis du lurer på, “Wow, hva mener han med denne flyttingen? Gi meg et spesifikt eksempel. ”For eksempel i VM der du kan bruke VMotion til å flytte den virtuelle maskinen din fra en vert til en annen og gjøre det uten driftsstans. Nå, klart at forrige bilde hadde noe rødt i seg fremdeles. Jeg hadde fremdeles lagringen som et eneste feil punkt. Og så går vi opp til neste løsning som er, vel, la meg kombinere lagring og servervirtualisering.
Nå, i dette tilfellet, igjen, kan det være lagringsadministratoren og virtualiseringsadministratoren som bygger denne løsningen og ser nå ut: Jeg har et bilde uten rødt i det. Jeg har høy tilgjengelighet fordi jeg kan flytte den virtuelle maskinen eller den kjørende applikasjonen eller databasen fra en server til en annen, og jeg har virtualisering i lagringsoppstillingen ved å la den gjøre RAID 1 på tvers av to separate lagringsarrayer. Jeg har multi-pathed bryterne og HBA-ene mine.
Så nå har jeg bygget et HA-system, og jeg har først og fremst gjort det ikke på databasenivå. Med andre ord, jeg har brukt andre teknologier for å oppnå det samme. Så dette er en løsning. Så kommer vi inn på det som kalles skalerbar klynge med delt lagring. Det er egentlig ikke en HA-løsning, men igjen, jeg liker å vise den for bildet.
Og det som skjer her er at vi har to servere som kjører en database, og den anses som en database. Det er ikke to separate databaser; det er ikke som en mester og en slave, eller en het og en kald, eller en aktiv og en beredskap. Dette er at begge disse nodene fungerer sammen for å presentere en logisk database. Og det, som skjer er at hvis en bestemt node mislykkes, er du fremdeles oppe. Så, det beskytter deg mot svikt på servernivå og gjør det i utgangspunktet ved, sortering, skjerming av node-ressursene, hvis du vil, men du har fremdeles det ene feil punktet til bunns for disken. Og så, dette er en skalerbar klynge med delt lagring, og Oracle kaller dette Real Application Cluster eller RAC.
Nå er en annen løsning å bruke en failover-klynge med delt lagring. Så til venstre har jeg en aktiv knute, til høyre har jeg en passiv knutepunkt, jeg har hjerterytme imellom. Jeg har en delt lagringsplass, og dette er avgjørende. det må du ha. Og i utgangspunktet, hva som skjer er hvis den aktive noden støter på problemer, den passive noden kan ta over. Det er lisensproblemer med dette. Noen databaseleverandører lar deg ha den passive noden med redusert lisens i en fast tid. I andre tilfeller må du ha fullstendig duplikatlisensiering. Det hele avhenger av databaseleverandøren. Men de støtter alle denne typen bilder, som er at hvis den ene noden går ned, kan den andre noden ta over.
Og typisk er dette et av de scenariene der det er slags, når du går fra den aktive noden til den passive noden, du sannsynligvis vil, i de fleste databaser - ikke alle - du vil miste noe av in- flytransaksjoner. Så får vi vite hva databaseadministratoren virkelig kan se på, som er databasereplikasjon, og det er to forskjellige måter å gjøre databasereplikasjon på.
Det er fysisk replikering, og det som er viktig er, i midten av dette bildet, kan du se med den grønne stjernen, at replikasjonen, den blir utført av databasen, men omtrent som lagringsnivået, blir det gjort i blokken nivå. Så gjentar vi den faktiske blokken I / Os fra den aktive noden til den skrivebeskyttede eller passive noden. Og dette anses som fysisk replikasjon.
Nå, la meg gå til neste lysbilde fordi det er nesten identisk og det er logisk replikering, og det eneste som endrer seg på bildet er at i midten, i stedet for å sende over I / O-blokken, sender vi egentlig over loggen filer med SQL-kommandoer i seg. Så, med andre ord, det vi replikerer er ikke den fysiske I / O, men kommandoene som forårsaker den fysiske I / O.
Og så kalles dette ofte loggforsendelse eller logbasert replikasjon. Noen databaseleverandører gir deg dette innfødt. Andre databaseleverandører tilbyr kanskje ikke dette, men så tilbyr tredjepartsleverandører det, og derfor er dette en veldig populær HA-løsning, og den anses som en komplett løsning. Men denne løsningen er først og fremst DBAs ansvar.
Så jeg bruker ikke virtualisering for å oppnå dette. Det kunne jeg, men jeg er ikke avhengig av det. Og jeg bruker ikke lagringsvirtualisering. Igjen, det kunne jeg, men jeg er ikke avhengig av det. Men jeg bygger en løsning der databasen er den viktigste kjørefunksjonen. Så dette er logisk replikasjon.
Nå er det også mulig å kombinere database- og lagervirtualisering. På mitt datasenter, la oss si, til venstre i blått, kunne jeg ha virtualisering for lagring, slik at jeg ikke er bundet til at en bestemt lagringsgruppe mislykkes. Men jeg gjør kanskje databasert nivå logbasert eller logisk replikering fra det ene datasenteret til det andre slik at kommandoene blir utført i datasenteret, noe som resulterer i I / O, men ikke nødvendigvis den samme I / O, fordi jeg ' m sender ikke over blokken I / O, verken med lagringsløsningen eller databasen, men jeg sender loggene, og derfor SQL-kommandoene.
Og så, dette er et bilde som er et veldig vanlig bilde for veldig store organisasjoner. Og jeg liker dette bildet her, fordi hvis jeg må sette opp dette på premiss ved hjelp av en database som Oracle, kan jeg gjøre det; det er ganske mye arbeid, det er ganske sammensatt, det er mange bevegelige deler. Hvis jeg gjør dette i skyen, kan jeg bokstavelig talt bare si, avkrysningsrute, jeg vil ha to geografiske regioner, jeg vil ha regionene atskilt med, du vet, på forskjellige kontinenter, jeg vil ha lagringsnivå virtualisering i et bestemt geografisk område. Jeg kan til og med si at jeg vil ha muligheten til å gjøre tildeling av virtualiseringstype eller definisjon med høy tilgjengelighet, og igjen er det en annen avkrysningsrute.
Og den andre tingen jeg liker med i skyen, det er en annen avmerkingsboks for å si: "Jeg vil ikke takle lapp, bare lappe den, " vet du, bare arbeid den inn i arbeidsflyten til alt annet du gjør bak scener, hold meg lappet til enhver tid. Og så, mens noen av disse bildene begynner å bli veldig kompliserte og de kan være veldig vanskelige å gjøre på premisset, blir de faktisk ganske enkle å gjøre i skyen.
Nå, det interessante er at det er enkelt å merke av i alle avmerkingsbokser, men gjett hva, det koster mer penger på månedlig basis. For hvis du kjører to datasentre, vet du at du har to datasentre ute i skyen du bruker, vil du betale mer enn hvis du bare bruker ett. På samme måte, hvis du gjør lagringsnivået eller virtualiseringen har høy tilgjengelighet som et ekstra lag, kan det igjen være ekstra kostnader.
Så det er interessant at selv om det er vanskelig å gjøre på stedet, og du kan tenke over det, i skyen er det så enkelt å gjøre, men du kan tenke det. Så vet alltid hvordan bildet ser ut, og vet alltid hva kostnadsavvikene er for det bildet du bygger. Nå er det mange flere kombinasjoner enn det jeg viste her. Dette er ikke et komplett eller uttømmende eksempel. Det kommer nye teknologier med jevne mellomrom, så hvem vet - jeg har kanskje ikke vist en som nettopp har kommet opp de siste tre månedene. Og høy tilgjengelighet er mye mer vanlig enn for ti år siden.
Jeg vil faktisk ikke betrakte det som en strekning å si at for de fleste store organisasjoner er det et obligatorisk forretningskrav i disse dager. Og jeg liker å gå tilbake til dette lysbildet fordi jeg bare sa at det er et obligatorisk forretningskrav. Og jeg fikk disse to bordene til høyre. Den øverste er utenfor SQL Server-dokumentasjonen, og den nederste er utenfor Oracle-dokumentasjonen. Og hva dette er, dette er tabeller som hjelper deg å velge, vel, hvilken replikasjonsmetode du bør bruke.
Og legg merke til at du starter med noen veldig enkle spørsmål. Hvor mye data har jeg lov til å bruke? Og hvis svaret er null, vet du at du bare kan velge den første eller fjerde raden i det øverste diagrammet. Så stiller du et annet spørsmål. Hvor lang tid har jeg lov til å ta restitusjonen? Og hvis noen sier vel, sekunder eller minutter, så gjør det valg for deg. Og da, må failover være automatisk eller krever det at noen manuelt gjør det? Og det er et annet forretningsspørsmål. De kan si at de vil ha det automatisk fordi de ikke vil stole på, du vet, en opptrappingsprosedyre og deretter noen som får tildelt en billett og deretter løse problemet. De vil bare at det skal fikses.
Dette er alle forretningsspørsmål, og det er de samme spørsmålene hvis jeg går ned og gjør det samme for Oracle. Og jeg spør, OK, hva slags feil tillater jeg, hva slags varighet, hva kan jeg tape, hva er gjenopprettingsprosedyren? Dette er alle forretningsvalg, så hvis virksomheten forteller meg svarene på tre eller fire spørsmål, er jobben min virkelig enkel, kommer jeg bare inn her, velger jeg hvilken av disse som matcher de nærmeste, og så bygger jeg det. Og husk at i skyen kan det bare være noen få avmerkingsbokser for å implementere disse.
Og med det, som fører meg til slutten av materialet mitt og tiden for å åpne dette for spørsmål.
Eric Kavanagh: OK, Dez, kanskje du først og deretter Robin?
Dez Blanchfield: Absolutt. Faktisk, sannsynligvis litt urettferdig for de som ikke er på Twitter, men jeg bare twitret et bilde av en graf som jeg vil visualisere i alles sinn, og så ville jeg kaste spørsmålet til den lærde vennen vår på samtalen her. Når jeg tenker på proprietær versus open source i dette rommet - som ofte er det vi snakker om, slags proprietære databaser fra slike som Oracle og Microsoft og så videre, kontra open source - ender du opp med denne utfordringen der den proprietære verdenen Internett-programvareleverandøren eller programvareutvikleren eller selskapet investerer i organene å bygge den kompleksiteten i. Og så ender du opp med et scenario der du kjøper programvaren og du ikke trenger å investere i mange mennesker fordi du kjøper muligheten innebygd og i åpen kildekode - du betaler ikke for programvaren eller det er lave kostnader, la oss si, men du betaler ikke for programvaren, men du må investere i kroppene.
Og jeg er opptatt av å få tankene dine om sjongelen, spesielt nå som vi går over i skymodeller der du kan få enten / eller. Du kan gå til AWS eller Azure og ditt Rackspace, uansett, og kjøpe som en tjeneste som gir databaseplattformen, eller du kan gjøre det gjennom åpen kildekode. Og hva vi nettopp har snakket om, hva er sjonglering mellom proprietær og åpen kildekode og hvordan designmønstrene du snakker om trer i kraft, og hva er dine generelle tanker rundt dette emnet når vi går fremover, spesielt rundt å tilby tilgjengelighet?
Bert Scalzo: En av de store varene jeg støter på når jeg prøver å ta opp det spørsmålet, jeg går tilbake til kunden og spør dem om ytelseskravene deres. Og grunnen til at jeg gjør det, har jeg funnet - i det minste historisk og etter min egen erfaring - at når det gjelder kunder som trenger høy gjennomstrømming på replikering, så er jeg nesten alltid bedre med replikasjonen som leveres av databasen. leverandør, på grunn av den arten som den er iboende innebygd og på et lavere nivå, og noen ganger bruker den mekanismer som ikke er tilgjengelige for omverdenen, selv i en åpen kildekode-løsning.
Og jeg vil gi deg et godt eksempel på en sak jeg hadde. Jeg hadde et internettbasert selskap som brukte MySQL som sin database, og de var på en gammel versjon av MySQL, som, versjon 4.0, og replikasjonen mellom nodene deres var den begrensende faktoren for hvor store de kunne skalere databasene sine. Og de så på å kjøpe en tredjepartsløsning, så de så på, "Vel, kanskje vi kan bruke en av open source-løsningene." Og hva det egentlig kokte ned til var, alt de måtte gjøre var å oppgradere MySQL til versjon, jeg tror det var 5, 5 vi gikk til, fordi forskjellen mellom de to databaseversjonene var i 4.0-versjonen av MySQL-replikering ikke ble tredd og i versjon 5.0 var det, og det var faktisk den beste veien for dem.
Nå så vi på de andre valgene, men den avgjørende faktoren var ytelse og å bo hos database-leverandørløsningen, og å gjøre databaseoppgraderingen endte faktisk opp med å være den beste løsningen for å få størst sannsynlighet for å få ytelsen de trengte å gå sammen med jo høyere tilgjengelighet.
Dez Blanchfield: Ja, det speiler min egen tankegang, for å være ærlig. Bare for full avsløring, og jeg vil ikke gå inn på merker, men jeg har kommet fra en egenutviklet bakgrunn som jobber for OEMs og programvareleverandører og IOCs generelt, og det har definitivt vært min erfaring og samtidig er jeg veldig proff -open-source og jeg er en bidragsyter for en rekke prosjekter som vi ikke vil navngi, men jeg er enig med deg i at hvis du er en stor organisasjon - la oss si at du er en bank eller hva du måtte måtte gjøre være - alltid vil du ikke være en IT-butikk. Du vet, for eksempel, hvis du er en avisutgiver, eller hvis du er en forhandler, ikke vil være en IT-butikk som gir ut aviser, du vil være en avisbutikk som faktisk bare utnytter IT.
Og så, ved å investere i de proprietære egenskapene der programvareutviklerne bygger all den muligheten, belastningsbalanseringen og så videre, i verktøyet, er det mye mer fornuftig i forhold til om du er som en dotcom-oppstart eller noe som det som kan investere i menneskekropper. Hvor ser du dette gå?
Sannsynligvis mitt siste spørsmål før jeg overlater til Dr. Robin Bloor, fordi jeg vet at vi har kort tid. Hvor ser du dette gå fra et trendsynspunkt? Så du er der ute hele tiden, du er på den blødende kanten av tingene, ser du at folk har satt seg opp og lagt merke til og våknet til behovet for å gjøre dette til en kommersiell del av deres daglige til- dagssamtale tilbake til styrerommet? Eller ser du fremdeles at det er veldig nerdegården, teknikerne og hettegenserne og tenker på tilgjengeligheten fordi det får dem til å våkne klokka fire om morgenen når noe går uten nett?
Tror du trenden svinger nå til organisasjoner i alle størrelser, ikke de åpenbare som flyselskaper og bank og finans, men bare bedrifter generelt? Tror du folk virkelig har kommet seg ut av verdiforslag for å beskytte databasemiljøene deres og gi høy tilgjengelighet og investere i det, eller tror du at vi fortsatt har en vei å gå? Hva er den generelle betydningen i markedet der ute?
Bert Scalzo: Akkurat nå tror jeg det fortsatt er et gap, men det er ikke et gap fordi virksomheten ikke ber om det, det er et gap i kommunikasjonsnivåene mellom de to sidene av gjerdet. Med andre ord sier forretningsfolk veldig tydelig: "Disse applikasjonene krever høy tilgjengelighet og har disse spesifikke kravene når vi sier høy tilgjengelighet."
Og på en eller annen måte får ikke meldingen tydelig ut til teknikerne. Eller de teknologiske menneskene vil komme tilbake og si: "Åh, det er komplisert, og det vil koste deg mer penger, " og dette, det eller det andre. Jeg tror det som kommer til å skje, er at det til slutt vil erodere seg fordi ærlig talt i skyen, bare sjekk noen bokser her eller der for å si: "Bygg meg denne virkelig komplekse teknologistrukturen, " egentlig ingen god grunn for teknologifolket å komme tilbake og si til forretningsfolket, “Å, det er dyrt”, eller “Det er vanskelig å gjøre”, eller dette eller det, og forretningsfolk begynner å vite at det er faktum.
Og jeg har til og med sett i miljøer der, du vet, deres egne IT-folk vil komme og si: “Å, du kan ikke ha det du vil. Det er for dyrt. ”Og de vil hente inn et tredjeparts konsulentfirma som da vil si:“ Nei, det er ikke riktig. Slik kan du gjøre det. Her er hva det vil koste deg. ”Så jeg tror vi har fortsatt litt tid mellom kommunikasjonsnivåene mellom de to sidene før det blir automatisk.
Dez Blanchfield: Ja, det er definitivt speilet det jeg har sett her i Australia og rundt Asia Pacific. Jeg er sikker på at det er en global ting. Og det er at mange av de viktigste beslutningstakerne fra styrerommet nede, alle ledere av bransjen, de er "mye mer teknisk kyndige - de leser bloggene, de ser på webinarer, de er innstilt på forskjellige artikler og podcaster, og de skal til arrangementer og fora og møte, og de vet nå alternativene sine, og de vet at sky er et alternativ.
De vet også at de kan bringe det, som du sa, deres evner internt, og derfor tror jeg det er denne interessante utfordringen nå, at samtalen må finne sted, og det er i grunnen hva vi har gjort i dag der folk, slags, begynn å gjøre ting internt og bare kjøre lunsjpakker med brun veske og ha en intern orientering om hva er vår nåværende tilstand, hva er vår ideelle tilstand, hvor må vi komme oss til? Og så, slags, få det sammen.
Jeg hadde en privat melding som jeg bare kommer til å berøre akkurat nå. Noen stilte et spørsmål: "Er det realistisk at du kan få 100 prosent tilgjengelighet?" Og du kan kanskje rette meg her, men jeg kommer til å si ja. Jeg har bygget en plattform for elektronisk pengeoverføring, EFTPOS-gateway mellom raske bankplattformer og EFTPOS-terminaler. Jeg bygde dette på begynnelsen av 2000-tallet. Det har faktisk vært online 100 prosent av tiden i 17 år. Faktisk, det ble bygget før 2000-tallet, men det gikk produksjonen bare 2000/2001 omtrent.
Så har de 17 årene vært på plass fra utvikling til testing og deretter gått i produksjon. I løpet av de 17 årene har svært billige PC-er som ikke har sokkel, som kjører et open source-operativsystem, men proprietær database, gjort aktiv / passiv bytte hver 90. dag, med forskjellige designpatenter som blir brukt, med replikering av disker i hver server, replikering av data mellom modellservere, replikering av flere datasentre, og bla fra datasenter A som produserer i 90 dager og deretter bla til datasenter B og driver produksjon.
Og når den vipper, oppdateres og oppdateres den automatisk, så bare til spørsmålet jeg nettopp fikk privat, ja, det er mulig, men med mye investering i det prosjektet i et designsynspunkt. Så infrastrukturen var faktisk ikke så dyr, men designen og testingen og implementeringen var veldig dyr å få til. Så vi trengte ikke å bruke mye penger på maskinvare og infrastruktur, men vi brukte veldig smarte verktøy, tilbake på dagen da sky ikke en gang var en mynt.
Så svaret er ja, det kan gjøres, enda mer nå med sky, slik vi nettopp har hørt at du med et klikk på en knapp kan aktivere den muligheten. Jeg kommer til å kaste det til Robin fordi jeg er sikker på at han også har spørsmål. Men tusen takk for at du har svart på spørsmålene mine, og jeg elsket virkelig å høre meldingen din i dag. Helt ombord med alt det fordi det speiler alt jeg har gjort de siste nesten 30 årene selv.
Dr. Robin Bloor: Vel, OK, jeg skal ta det opp. Noe av det som fascinerte meg med presentasjonen din, var antall alternativer som er tilgjengelige nå som ikke var tilgjengelige da jeg pleide å slite med dette. Jeg er litt interessert i hvem som skal designe disse konfigurasjonene, eller hvem, i dag, designer disse konfigurasjonene? Det som tidligere skjedde, eller, verdenen jeg er vant til, er at det ville være et ganske tungt transaksjonssystem og du ville være interessert i høy oppetid og høy tilgjengelighet. Fordi, du vet, transaksjonssystemet, ville det være dyrt hvis det gikk ned på noen måte. Og du ville ikke ha alle alternativene du nettopp har presentert for meg, men på den ene eller den andre måten kan du finne en måte, via replikering for det meste, til å lage en varm ventemodus som ikke ville klikke på unaturlig, men det vil gi deg en degradert tjeneste til du kom tilbake.
Og jeg ser på det du viste meg og tenkte på det, ikke har gjort noe av det slags designarbeid på 15 år, hvem gjør det nå? Er dette, som det var på min tid, noe du gjorde ved starten av et prosjekt, vet du, får infrastrukturen i gang? Eller er dette noe som er en pågående aktivitet i en organisasjon? Fordi det er nye teknologivalg som følger med.
Bert Scalzo: I de store selskapene som er veldig effektive og effektive i all sin virksomhet, inkludert IT-en, vil de vanligvis ha en sentralisert arkitekturgruppe, eller de vil ha noe navn på det, jeg har hørt det heter “the arkitektur gruppe "mange ganger. Og det vil være deres ansvar å vite alle disse forskjellige bildene og hva fordeler og ulemper er og hva kostnadene er. Og hva som vil skje, er når en bestemt applikasjon ser og sier: "Hei, jeg må oppfylle forretningskrav X, Y og Z. Hei, arkitekturteam, hva er mine valg?"
De vil gi dem svaret, her er de to eller tre som er tilgjengelige, og da flytter beslutningen på det punktet tilbake til lavere nivå til applikasjonsteamet eller til forretningssponsoren for applikasjonen. Men typisk er det en sentralisert gruppe som holder seg på toppen av dette og har den informasjonen klar og ferdig bygget.
Nå er det de mellomstore selskapene der det ikke er så formelt. Det som har en tendens til å skje, er at du vil få en eller to av de senior DBA-ene eller systemadministratorene dine, og de vil uformelt sitere "domeneksperten" for den slags kompetanse. Så selv i mellomstore selskaper skjer det, det skjer bare i en ikke-formalisert struktur.
Dr. Robin Bloor: Det er veldig interessant. På min dag ville vi aldri tenke på høy tilgjengelighet, bortsett fra transaksjonssystemene. Vel, i dag har du selvfølgelig streaming-systemer som sannsynligvis er underlagt enda større krav til tilgjengelighet. Men, i spørringsbaserte, back-end, analytics, datavarehus, DI slags miljø, ser du noen gang krav til høy tilgjengelighet der?
Bert Scalzo: Ja, og jeg er glad du spurte det spørsmålet. Jeg jobbet litt for et detaljhandelsfirma, og deres strategiske beslutninger for virksomheten var basert på en stor del av analysen de ville gjøre fra datavarehuset. Og faktisk ble de intervjuet av Forbes Magazine og administrerende direktør i selskapet sa: "Hei, aksjekursen vår vokste 250 prosent de siste fem årene, og en veldig stor grunn som er sant er fordi vi vet hvordan vi effektivt kan utnytte våre data i vårt datavarehus. ”De var så flinke til å ta forretningsavgjørelser at for dem, datavarehuset og å kunne gjøre disse analysene, ved å kunne ta beslutninger på daglig basis mot deres driftsdata, faktisk var for dem, et produksjonssystem.
Og jeg vil gi deg et godt eksempel på hvor viktig det er. Med denne spesielle detaljhandleren, mannen som var ansvarlig for ølsalg, var han, som den tredje viktigste utøvende i selskapet, fordi han hentet inn, du vet, 60, 70 prosent av inntektene. Og så måtte han være i stand til å, for å være konkurransedyktig i det markedet, måtte være i stand til å vite hver dag, du vet, hvilke kampanjer skulle jeg løpe. Og det kan være basert på, vet du, ikke bare tiden på året, men vær, mønstre og andre kritiske data som kan påvirke salg av noe som øl.
Dr. Robin Bloor: Jeg antar at det vil være ting som det. Vi er litt for tidlige, jeg tror jeg bør gi Eric i tilfelle han har noen spørsmål fra publikum. Eric?
Eric Kavanagh: Ja, dette har vært gode ting, Bert. Jeg tror du tok opp alle spørsmålene vi hadde fra publikum i presentasjonen. Men det er gøy å se på. Jeg er glad for at du snakket om lagervirtualisering og hvor stor innvirkning det kan være. Så alt dette er bra.
Vel, folkens, vi arkiverer alle disse webcastene for senere visning. Så hopp online til Techopedia.com for å se etter webcast-delen. Alle disse Hot Techs vil være oppført der. En stor takk til vår venn Bert for hans ekspertise. Og selvfølgelig til Dez og Robin. Og med det kommer vi til å ta farvel, folkens. Ha det fint. Vi snakker med deg neste gang. Ha det.
