Af Techopedia Staff, 7. december 2016
Takeaway: Værten Eric Kavanagh diskuterer tilgængeligheden med Robin Bloor, Dez Blanchfield og IDERAs Bert Scalzo.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej og velkommen igen. Det er klokken fire østlig tid på en onsdag, og i disse dage kan det betyde næsten en ting, hvis du er i en verden af data: det er igen tid for Hot Technologies! Ja bestemt.
Jeg hedder Eric Kavanagh, jeg vil være din vært for showet. Det er designet til at finde ud af, hvad der er varmt, hvad der sker derude, hvad de seje ting der bruges i virksomheden, og selvfølgelig, lige ved grundlaget for alt hvad vi gør i hele dette felt, er databasen. Så vi skal tale om at beskytte din database. Det nøjagtige emne er, "Beskyt din database: Høj tilgængelighed for høje efterspørgseldata." Så der er et lysbillede om din virkelig. Og nok om mig, slå mig op på Twitter, @eric_kavanagh.
For det første er dette år varmt, data er varmt, big data er meget varmt, men det er virkelig stadig slags på kanten. Flere af avancerede virksomheder udnytter store data i disse dage, de fleste brød- og smørorganisationer derude i verden, de bruger stadig traditionelle data, og hvis dine data er meget efterspurgte, vil du sikre, at de er tilgængelige, fordi når systemer går ned, når data er utilgængelige, er det, når du får ulykkelige klienter, ulykkelige udsigter, du får kundesår, du bliver ulykkelig med alle slags ting, partnere osv. Så du vil ikke have det.
Vi vil lære af nogle af de bedste i dag i branchen - vi vil høre fra vores egen Dr. Robin Bloor, databaseekspert på omkring tre årtier. Dez Blanchfield, der har gjort dette lige så længe, men han startede, da han var rigtig ung, og Bert Scalzo fra IDERA, som virkelig er ret databasens sorte bælte. Så hold ikke tilbage, folk, still spørgsmål - den store del af denne begivenhed er værdifuld for dig, når du stiller gode spørgsmål og får gode svar, så send dem via chatvinduet eller Q- og A-komponenten i din konsol.
Og med det overlader jeg det til Robin Bloor - tag det væk.
Dr. Robin Bloor: OK, lad mig klikke på dette og se, om det bevæger sig - det gør det. Jeg vil ikke tale særligt om databasen. Jeg troede, at du ved, fordi jeg laver introduktionen, første introduktionspræsentation, så jeg vil tale om det forventede serviceniveau og naturligvis tilgængelighed, hvilket er handlen, som er emnet for dagens show.
Og spørgsmålet er at, du ved, ”Virkelig, hvad er tilgængelighed? Og hvilken rolle spiller det på den måde, at folk driver datacentre i dag? ”En ting, som jeg bemærkede - jeg bemærkede dette faktisk engang i 90'erne - jeg arbejdede på et sted, og brugerne begyndte at klage, fordi deres e-mail var nede for 15 minutter.
Og det var interessant, fordi CTO eller hvem, der var ansvarlig for IT, faktisk havde et af de få steder, hvor de i disse dage faktisk havde bestemt serviceniveauet, og e-mailen, der var nede i 15 minutter, ikke var i strid med nogens serviceniveau . Jeg tror, det er faktisk tilladt at være ude i to timer. Det var ikke e-mailen ikke kunne bruges, det var bare at du ikke kunne sende og modtage, fordi serveren var ude. Og den slags advarede mig om, at jeg har lagt mærke til, at jeg er kommet videre siden da, at alt bare fremskynder, og det gør brugerne også forventningerne, og dette fører dig til den situation, hvor folk måske har tre serviceniveau, men ofte de begynder at klage, når serviceniveauet ikke faktisk overtrædes.
Så definition af serviceniveau, bare for at give en - ja, det kan afhænge nøjagtigt af, hvad du taler om med hensyn til serviceniveau. Vi har talt om it-system eller it-applikation. Definér normalt med hensyn til ydeevne, tilgængelighed og måling - med andre ord, du kan ikke virkelig definere et serviceniveau, medmindre du kan måle det, så normalt er der en slags måling involveret, og det handler normalt om responstider, bestemte transaktioner og tilgængeligheden af systemerne over en bestemt periode, og inden ca. 1994–1995 var det virkelig sjældent, at der kræves nogen systemer til at være tilgængelige i mere end normal arbejdstid. Så lad os sige otte om morgenen til seks om aftenen, for at give et normalt spændvidde - og folk byggede systemer og på den måde, og det betød - efter min mening, især med databasen - du kunne konfigurere databasen på en bestemt måde og som batchvinduet begyndte at krympe, behovet for at tænke igen begyndte at opstå i nogle systemer og derefter andre systemer, og så fik vi fremkomsten af service eller arkitekturen, der begyndte at afhænge mellem systemer, der ikke tidligere var afhængige af hinanden, hvilket gør alt endnu værre. Vi fik presset med hensyn til tilgængeligheden af systemerne.
Det punkt, jeg gjorde, var, når vi taler om tilgængelighed, det inkluderer sikkerhedskopiering og gendannelse og inkluderer - det er som ikke kun er tilgængelighed på de normale vilkår, vi taler om; der er mange forskellige måder, hvorpå en applikation kan mislykkes. Du ved, du kan få hardwarefejl, eller du kan få databasesvigt, du kan få softwarefejl, og der er masser af forskellige arter af disse ting, og når det opstår, skal du være i stand til at gendanne, og derfor skal du også tilbage op systemerne. Så der skal være en række ordninger med sikkerhedskopiering af systemet, og du har også på mange steder i dag brug for evnen til at genoprette katastrofen, hvis en hel bygning sprænger. Og noget, der er værd at nævne her, og jeg vil sige om det om et øjeblik, men forretningsprocesserne, de har også serviceniveauer, og faktisk serviceniveauet i forretningsprocessen, der virkelig betyder noget for virksomheden. IT skal bare gøre sin del af det og i henhold til hvilken aftale der er.
IT-serviceniveauer er normalt underordnede til serviceniveauer for forretningsprocesser, men ligesom det virkelig var ganske sjældent for 15 år siden for enhver organisation at have veldefinerede serviceniveauer, er det stadig ret sjældent for organisationer at have veldefinerede serviceniveauer for forretningsprocesser . Det er noget, der sker slags nu; det er ikke noget, der har foregået i lang tid.
Dette er accelerations- og tidsbarrierer, det er bare værd at nævne tidsbarrierer. Vi bevæger os gradvist ind i en verden, der behandler begivenheder, og på grund af dette bevæger vi os gradvist ind i en realtid verden, og på grund af dette bevæger vi os gradvist over tilgængelighed til at blive krævet 24 for 7, og det er faktisk svært for mange systemer - det svært at opnå. Enten er det meget dyrt, eller i nogle tilfælde må du faktisk nødt til at ændre systemerne, endda flytte til en anden database, en anden version af databasesoftwaren, vi bruger.
Også disse tidsbarrierer - og jeg vil altid gerne nævne disse, når jeg får en chance - dette er tidsbarrierer, som vores applikationer støder på; applikationer ønsker måske at være så hurtigt som muligt, det er når software taler til software. Der er virkelig ikke nogen acceptabel licens i nogle situationer, du vil være så hurtig, som det kan være, og de situationer i forretningsmæssige vilkår som markedssituationer, hvor den person, der kommer med købsordre sekundet, får en dårligere pris end nogen der kommer først, og derfor betyder softwarehastigheden virkelig noget.
Men du ved, nedenfor, at når du faktisk har at gøre med - interagere med - mennesker, er den bedste responstid, der virkelig kan kræves af dig en tiendedel af et sekund, fordi det handler om et menneskes responstid. Du behøver ikke gå hurtigere end det, fordi et menneske ikke vil bemærke det alligevel. Mellem 1, 1 og fire sekunder er en ventetid, som mennesker normalt vil tolerere, men så snart du går forbi cirka fire sekunder, er de ude af at gøre noget andet, og derfor er du virkelig i en batchaktivitet.
Så du kan se, at bestemte tidsrammer og dag, uge og måneder for de ting, hvor en batch-adfærd giver mening, og at du derfor ikke er i en verden, der behandler begivenheder, og derfor er tilgængelighed muligvis faktisk meget anderledes med hensyn til hvad du har brug for at være i stand til at levere. Men så snart du er i begivenhedsverdenen, så er du i nogle døgnets tilgængelighed, og teknologiændring er en faktor, da teknologien går hurtigere og hurtigere, så vil tilgængeligheden muligvis ikke øges; det forbliver bare som det er.
Dette er lag med kompleksitet, og jeg vil ikke gå nærmere ind på dette, det er bare, du ved, der er tre ting, man skal overveje her. Der er serviceniveau på infrastruktur, dette er den lodrette akse, og så er der et serviceniveau for en given applikation, og så er der et forretnings serviceniveau, og disse er afhængige af hinanden, og de skal tages i betragtning hvis du faktisk ser på at skabe et responsivt miljø, hvor serviceniveauet overholdes, dybest set.
Så har du nede i bunden her, som netop er repræsenteret databaser, men du kan gøre hvad som helst inden for systemet, du ved, at du har den nonstop-konfiguration, hvilket betyder, hvad det siger: det vil aldrig stoppe. Du har den varme standby-situation, hvor der på den ene eller den anden måde er forskellige måder at opnå den på, men på en eller anden måde, hvis en database mislykkes, skiftes den til en varm standby, og der er meget lidt forsinkelse i tidsbetingelser, til det punkt, hvor brugerne sandsynligvis ville bemærke, men ikke ville bemærke meget.
Varm standby er mere som den 20-minutters omskiftning, hvor alle ringer op helpdesk og tæver ved helpdesk, mens databasen skiftes til en standby. Så er der en genstart-situation, hvor det kan tage meget lang tid. Det er værd at bemærke en given applikation eller en given database kan være i en af situationerne afhængigt af, hvad der faktisk foregår, og på hvilket serviceniveau, der kræves af applikationen, faktisk.
Ud fra det vil jeg bare gøre et punkt om kompleksitetskurven. Kompleksiteten stammer fra knuder og forbindelser, afhængighederne. I den verden, vi lever i, fortsætter antallet af knudepunkter og forbindelser, der er involveret i noget, bare ved at vokse, så du løber til denne form for hensigtsmæssig kurve. Hvis du kan se på, hvordan kompleksiteten øges, og hvordan tidsdimensionerne skrumper, ved du, hvad angår tilgængelighedsniveauer, er der tidsmål, vil de sandsynligvis reducere?
Og den naturlige udvikling er derfor mod direkte drift, hvilket naturligvis er den dyreste - i det mindste efter min erfaring - det er de dyreste konfigurationer, du kan oprette. På en eller anden måde skal enhver organisation, der tænker over dette, virkelig ikke bare tænke på, hvad der sker nu, men hvad der skal ske i fremtiden.
Det sidste punkt, jeg gerne vil gøre, er måske, at styringen af serviceniveauet er en løbende aktivitet; det er ikke noget, du ved, at du har et projekt, du gør det, og det er forbi. Det er det ikke, fordi tingene bare fortsætter med at ændre sig. Når det er sagt, vil jeg give bolden videre til Dez.
Dez Blanchfield: Tak Robin. Jeg elsker dit åbningsbillede. Vi har netop kørt igen, jeg tror, det er "Finding Nemo 2", filmen. Du havde Nemo søgt efter tilgængelighed i form af nier, som jeg syntes var temmelig sød. Altid en hård handling at følge. Når jeg tænker på oppetid og tilgængelighed og høj ydeevne, er det første billede, der kommer op i tankerne, fordi jeg er vokset op på Salomonøerne nær vulkaner og ækvator, en vulkan, der bryder ud i mit datacenter; der er dette billede, jeg altid har i tankerne om, at det er, hvad der potentielt kunne ske, hvis noget går i stykker. Dette er et billede af den dejlige Mt. Etna, som er det nordøstlige hjørne af Sicilien, som ligger lige ved siden af Catania.
Min tilgang til dette er at have en samtale med dig og give dig et par takeaways på samme niveau, som jeg gør i et bestyrelsesrum regelmæssigt fra C-suiter og lederne af forretningsområdet med det formål at vi har en samtale om, hvad der kan påvirke din organisation ud fra en kommerciel eller teknisk forstand og typer af teknik.
Vi er nødt til at tænke på og hvordan - hvad vi tager væk fra det, og hvordan vi går hen til derefter tackle nogle af de udfordringer, vi taler om, når vi taler om høj tilgængelighed og oppetid, især omkring automatisering og platforme.
Så det spørgsmål, vi stiller oprindeligt, er, hvad mener vi egentlig, når vi taler om databasesystemer og tilgængelighed af databaseplatforme? Hvad betyder det egentlig at tale om den faktiske udfordring ved at stille noget til rådighed for et niveau, som Robin talte om i serviceaftalens installerede kortlægning af hvad har vi faktisk brug for og ønsker?
Så virkeligheden i dag er, at - og i virkeligheden her er et par top-realiteter i mit sind - i dag er alt effektivt databasedrevet. Der er meget få systemer, der er bygget i dag og bygget på en sådan måde, at ting bare bliver gemt i filer eller er en slags flad fillog; altid er alt databaseret. Som et resultat af dette har vi dette behov for at stoppe med at tænke over tilgængeligheden til disse databaser, til de forskellige systemer og applikationer og værktøjer, der er afhængige af dem, og stole på dem for at levere de tjenester, vi ønsker at levere, sælge eller forbruge . Og al infrastrukturen omkring det.
Faktisk så meget, når du tænker på de store forstyrrelser i data fra sent, især de digitale indfødte eller skyindfødte, nogle af de virksomheder, der er kommet sammen som Uber og Airbnb og så videre, og de lidt ældre PayPals og verdens eBays - omfanget og størrelsen af disse organisationer er kun muligt på grund af moderne databaseteknologi og moderne skyinfrastruktur. Uden dette, uden den ekstra leverede mulighed, ville de bare helt sikkert ikke eksistere. Forestil dig et scenarie, hvor du kun kunne komme til eBay mellem 9:05 og 9:25, fordi det ikke var tilgængeligt resten af dagen, fordi det forsøgte at lave en iCloud eller en sikkerhedskopi eller lignende, det ville bare ikke have arbejdede.
Så, og der er andre centrale områder, når du tænker på vores daglige liv, ved du, som detailhandel og bank og finans og flyselskaberne og så videre. De store industrigrupper som luftfartslogistik, transportforsendelse, der er regeringen som en helhed, der er national sikkerhed og politi og så videre. Alle disse brancher, alle disse markedssegmenter, alle disse organer, grupper afhænger af, at deres miljøer er i gang.
Så med det i tankerne har vi også det andet advarsel, som vi er nødt til at tænke på, det andet takeaway, som jeg vil overlade dig til at tænke på, og det er, at vores verden nu er det, jeg kalder "altid på." Vi er permanent tilsluttet, og dette er et tema, du vil høre regelmæssigt, og jeg vil gentage det og gentage det. Vi har nu smartphones i vores hænder hele dagen, hver dag. Vi slukker dem ikke, vi lægger dem ved siden af sengen, vi bruger dem altid som vækkeure, vi bruger dem som kameraer, og vi tager fotos, de skubber disse fotos op i skyen.
De er altid tændt, permanent forbundet mentalitet. Faktisk er der en sætningsmønt, som jeg kan lide at bruge, og det er, at vi nu slags lever Fitbit-generationen, hvor vi måler alt, vi overvåger alt, og det skal logges og det vil gå et eller andet sted.
Og der er også en anden sætning, som jeg overlader dig med, og det er, klokken er ni et eller andet sted, hele tiden. Det er en verden 24/7/365, vi lever i. Jorden roterer konstant rundt om solen og på et tidspunkt og tid, hver time af dagen er det ni. Og det betyder, at folk stiger op af sengen og prøver at lave ting, købe ting, installere ting osv.
Så hvad mener vi, når vi taler om høj tilgængelighed? Det lyder virkelig indlysende, indtil du begynder at dykke ned i detaljerne. Så ved du, når vi tænker på “OK, hvad betyder høj tilgængelighed?” Nå, virkeligheden er, at der ikke er nogen sølvkugle. Det er et ganske komplekst koncept, som Robin relaterede til nogle af de emner, han nævnte, såsom måling af tilgængelighed og aftaler på serviceniveau. Vi kortlægger det til ting som: Jeg har disse spørgsmål, er det oppetid? Bekymrer vi os om ting som det, vi kalder fem nier, som jeg vil gå ind på på et minut. Overvejer vi os selv, hvad der står i vores aftaler på serviceniveau? For eksempel, på serviceniveauaftaler, mener jeg, at der er forsinkelser. Forkortelsen på tre bogstaver til aftaler på serviceniveau er blevet mere og mere kritisk i disse dage.
Når du går igennem hele denne proces med lokalitet og selvhosting til outsourcet til tredjepartsdatacentre og outsourcede administrerede tjenester, og nu går vi hele vejen til sky. Og virkeligheden er, når du taler om sky, det er bare virkelig andres computere. Og det betyder, at du ikke kører infrastrukturen, du kører ikke systemerne, og altid kører du ikke skyen. Du laver infrastruktur konfigureret som platformen, så det er endnu vigtigere i salgsstyrketjenesten. Forestil dig for eksempel salg, du ved, at du ikke rører ved nogen af denne infrastruktur, du logger bare ind på en webgrænseflade.
Så den eneste mekanisme, du har i denne verden af sky og outsourcet infrastruktur, uanset form for at kontrollere, der er aftaler på serviceniveau, det er den eneste mekanisme, du har, og hvis folk ikke møder din installation, så holder de enten ud bøder og en reduktion i det beløb, du betaler dem, eller du bare ikke betaler dem.
Så dette bringer tankerne tilbage til hele denne udfordring, ved du, hvordan styrer vi høj tilgængelighed? Hvordan administrerer vi tilgængelighedstiden, hvis det ikke er din infrastruktur - det handler f.eks. Om SLA. Hvis det er din infrastruktur, eller endda hvis det er en andens infrastruktur som et designmæssigt synspunkt. Vi talte om belastningsbalancering til modelvidenskab, er det et patenttest for fejltolerance?
Kører du aktiv aktiv eller aktiv standby i dine arkitekturer? Har du flere servere, flere lagerplatforme? Hvordan fungerer disse lagerplatforme? Replikerer de hinanden, spejler de hinanden? Kører du RAID? Hvilken type RAID kører du til overflødig lagring? Kører du RAID på diskniveau? Kører du en objektopbevaringsplatform, der replikeres på tværs af drev og modeller og systemdrev? Er det N plus en for hvert lille stykke infrastruktur, du har? Tilføjer du et andet, og er det i det samme datacenter eller et andet datacenter? Har du opbygget et designpatent, der f.eks. Ikke tegner sig for et enkelt salgssted?
Alle disse grundlæggende ting, nu lyder de som enkle begreber, men når du kommer ind på hver enkelt af disse ting, er de meget, meget detaljerede ting. Når vi taler om tilgængelighed, ender vi altid med at tale om nier. Og hvad mener vi med nier? Vi har alle hørt om disse, men lad os bare tænke over, hvad de betyder i et minut, og hvorfor de er vigtige.
Så vi taler om en ni, hvilket kun er 90 procent af vores tilgængelighed. Jeg ved, det lyder meget højt. Så når vi taler 24 og 7 af 365, hvis vi bare ser på et år, for eksempel, når vi snakker om en ni, hvilket er 90 procent af tiden, giver det mulighed for halvtreds seks og en halv dages driftstid om året. Lad os bare runde det til lidt over en måned.
Tænk nu på enhver forretning, vi har hver dag - uanset om det er online bank, eBay, PayPal eller sociale medieplatforme som LinkedIn, Twitter eller bare en almindelig detailhandler - lad os bare sige, at jeg ville booke en flyrejse for at komme til USA fra solrige Australien, ville jeg være glad, hvis jeg ville komme til Amerika om en uges tid, hvis mit foretrukne flyselskab var nede i halvandenesogtres dage, fordi deres tjenesteudbyder sagde: "Se, vi er ope i 90 procent af tiden "? Selvfølgelig ville jeg ikke.
Når du går op på denne model, to nier: 99 procent. Nå, det bliver 3, 65 dage, omtrent tre og en halv dages driftstid om året. Er det en big deal? Det er godt, hvis du kører Black Friday, og du kører en salgsspecial, og folk kan kun købe i løbet af disse par dage.
Tre nier bliver så lidt som 8, 7 timer om året, men endda 8, 7 timer om året, det er sammenhængende non-stop otte timer af vores tid. Det er godt inden for bank og finans, sundhed - hvis det er et hospital, så kunne det koste liv. Når du klatrer op, er fire nier 52 minutter, fem nier er fem minutter og seks nier er dybest set 30 sekunder. Seks nier er ekstremt høj, og når du går op på denne stige, når du klatrer op på dette juletræ af ni, jo flere nier du går op, desto sværere er designet, miljøet og platformen. Jo sværere det er at levere denne service, og hvis du tænker over den reduktion af den tid, du har til, at ting som sikkerhedskopier skal køres, administration, programrettelse, vedligeholdelsesvinduer til enhver form for strømafbrydelse - alle ikke-trivielle udfordringer - og det hele kommer effektivt til procentdel af strømafbrydelser.
Nøglen her, som jeg gerne vil overbringe, er, at der ikke er nogen sølvkugle, som jeg nævnte før. Når det kommer til tilgængelighed, er der ingen "en størrelse passer alle." Du har muligvis en bestemt type designpatent, der passer til nøgleindustrier. De samme udfordringer står alle banker overfor. Nogle kan være detailbanker, andre måske premiumbanker. Nogle banker fokuserer måske på handel og investering, formuestyring. Nogle kan være rent forbrugere. Nogle er måske kun på internetplacering og har ikke engang fortællere og handler kun med pengeautomater, når de udleverer kontanter. Så i disse scenarier, selv i bank- og formuestyrings- og finansservicesektoren som helhed, har de for hver af dem stadig deres egen særlige smag eller ting, de har brug for, når det kommer til tilgængelighed.
Så når vi tænker på tilgængelighed på almindeligt engelsk, er blandingen mellem tilgængelighed og høj tilgængelighed - vi tror, de er de samme ting, men de er faktisk kridt og ost. Tilgængeligheden er, jeg har sagt det på almindeligt engelsk, et tidsmål, som en server eller proces fungerer normalt eller generelt, bundet til deres brug. Det betyder bare, hvordan vi beskriver, om det er tilgængeligt eller ikke. Når vi taler om tilgængelighed, falder vi ofte i denne fælde af at tænke: ”Jeg leverer det i en tilgængelig form” mod høj tilgængelighed til at beskytte sikkerheden i den infrastruktur.
Høj tilgængelighed, i en anden forstand på almindeligt engelsk, er designet, hvor du implementerer eller opnår en slags resultat og tilgængelighed af data, især hvor næsten hele tiden –24/7/365 dage om året - at tilgængeligheden kommer til nogle af disse niere. Under alle omstændigheder betyder det ikke 100 procent. Hundrede procent er teknisk set ikke muligt i en reel verden i et miljø. Det er meget vanskeligt for en server i et operativsystem med en database på, med en platform, der kører, og på det en applikation kan du levere den og forvente, at den kører 100 procent. Så så begynder vi at tænke på design. Har vi afskedigelser, har vi flere lysbilleder at replikere? Når du derefter sætter det på almindeligt engelsk, er det interessant, hvor anderledes emnet tilgængelighed versus høj tilgængelighed bliver.
Jeg troede, at jeg ville sætte det i en rigtig enkel grafisk form bare for at give os en idé om, hvordan det ser ud, når du begynder at klatre op på udfordringen om at øge tilgængeligheden i at beskytte din oppetid af tjenester. I nederste venstre hjørne har vi en ni. Jeg har lagt de fem ni, som vi generelt taler om. Seks ni er lidt skandaløst. Når vi taler om fem nier i nederste venstre hjørne, 35 dage i grov grad af det strømafbrydelse, er det et miljø med lave omkostninger og lavt kompleksitet, du prøver at give det, fordi du har et antal ting, der kan mislykkes, og du kan opfylder stadig dine aftaler på serviceniveau.
Men når du går langs bunden fra venstre mod højre, og du kommer til det punkt, hvor der er flere nier på billedet, får du scenarierne, hvor du begynder at tænke på replikering af systemer og platforme. Du er nødt til at tænke på klynge og virtualisering af forskellige dele af infrastrukturen. Du er nødt til at tænke på geolocation af disse klynger, flere websteder med datacentre, og du er nødt til at tænke på den type industri og markedssegment, du sigter mod. Så hvilket type serviceniveau har du brug for at opfylde? Hvilken tjenesteydelse du leder efter? Områder, der er kortbaserede tjenester i realtid, der fortæller om kommunikation. Er det militære tjenester? Så denne graf går fra nederst til venstre til højre, og når du kommer igennem kurven, øges omkostningerne og kompleksiteten. Når du får mere komplekse og mere krævende miljøer, har du brug for flere niner.
Denne graf gør for eksempel en meget lignende ting: Den beskriver historien mellem omkostningskomponenten kontra den ønskede tilgængelighedskomponent. Så i det øverste venstre hjørne kortlægger vi meget tilgængelige komplekse systemer, og omkostningerne, der opstår, hvis denne tilgængelighed falder i forhold til fordelen ved at have tilgængelighed i nul nedetid. Så hvis vi for eksempel har et miljø på venstre side, hvor tingene er nede, kan vi pådrage os økonomiske tab. Vi har juridiske implikationer, der kan være kommercielle implikationer på forretningsstrategisk niveau.
Der er formodet alle mulige muligheder, selv moralske problemer omkring at have en tjenesteydelse. Hvis det er en sundhedsindustri, og de begynder at gennemgå omkostningerne ved et strømafbrydelse, påvirke kunderne, reduktion i kundetilfredshed, personalets produktivitet, brugerproduktivitet osv. Disse ting påvirkes, hvis vi overvejer at designe meget kompleks, meget afhængig, meget risikabelt miljø, hvor der er potentiel risiko for strømafbrydelse og derfor tab.
På højre side forsøger vi at sigte mod et scenarie, hvor hvis vi investerer høje omkostninger og planlægning i design, vi investerer i intelligent implementering. Vi investerer i at give folk kompetencer og ressourcer, og vi har meget anset netværk og højt anset operationelt miljø og hardware og software. Vi får høj tilgængelighed, men det kommer til en høj pris. Så den svingende magiske pendulplads med den optimale placering i midten, hvor de krydser, hvor vi har fået lidt reducerede omkostninger, og stigende tilgængelighed, der bare jonglerer mellem niveauerne af ni og den høje tilgængelighed, der er kontinuerlig tilgængelighed, og dette er en en stadig udfordring for os at møde, som i hvor mange penge du er villig til at investere for at få det serviceniveau, du leder efter?
Vi har også det emne, som jeg ikke vil gå nærmere ind på, men jeg vil bare have dig til at fjerne dette og tænke over det. Forskellen mellem gennemsnitstid mellem fiasko i dit design og gennemsnitlig tid til at komme sig. Med andre ord investerer du i infrastruktur af bedre kvalitet, bedre kvalitet design, hardware og software af bedre kvalitet og bedre kvalificeret personale og ressourcer til at konstruere ting og reducere den gennemsnitlige tid mellem fiasko, den gennemsnitlige tid det tager at finde pausen i modsætning til at sænke investeringer i infrastruktur, i ressourcer og design og blinde patenter, den høje kapacitet til at komme sig? Med andre ord, hvis noget går i stykker, har du masser af det til at tilslutte. Hvis nogen har en bærbar computer, og det dør, har du et ekstra. Du overleverer det til dem, og på 30 sekunder logger de ind. Dette er meget forskellige ender af stangen. Den øverste giver os ingeniørarbejde med høje omkostninger og høje investeringer for at undgå fiasko, og den nederste siger, at ”Jeg vil acceptere, at fiasko vil komme, så jeg vil konstruere det og være forberedt på fiasko og kom hurtigt tilbage. ”
Som jeg nævnte før, hvor jeg kunne sige, ”Min tilgængelighed er ikke din tilgængelighed.” Så når det kommer til databasemiljøer og understøtte infrastrukturen, køre din database og beskytte det og sikre høj tilgængelighed, er der virkelig ingen one-stop shop . Alle har deres egne behov og ønsker. Så du er nødt til at stille dig selv disse grundlæggende spørgsmål, som jeg overlader dig med, og det er: Hvad har din organisation råd til? Jeg taler ikke kun om dollars og cent. Jeg taler om, som en organisation, hvad kan du fra ressourcer, tid og kræfter osv. Have råd til det niveau, hvor tilgængeligheden kan give? Hvad kan din virksomhed også støtte? Så de nuværende kapaciteter, de nuværende færdigheder, den aktuelle infrastruktur, den aktuelle finansiering, du kan rejse. Så det jonglerer mellem det, du faktisk har råd til, mod det, du kan støtte, er en interessant balance.
Du skal også stille dig selv spørgsmålene: Hvilke færdigheder og teknologi har du internt? Kan du outsource nogle af denne udfordring? Kan du derefter flytte tingene til skyen? Hvis du har infrastrukturtjenesten bortset fra softwaretjeneste, står du uden den stak, når du går længere op i stakken. Så skal du investere mere i platforme og service og ikke bekymre dig om infrastrukturstykket, eller skal du se på software som et servicetilbud, fordi du ikke behøver at bekymre dig om platformen?
Hvilken type marked og forbruger eller kunde betjener du? Jeg mener, hvis du er et telekom, og nogen er nødt til at hente telefonen, og du får en ringetone hele tiden, er det en meget anden udfordring at åbne en lille butik mellem mandag og fredag, ni til fem og lukke ned for en time ved frokosttid som et hjørne butik barber. Så du bliver nødt til at tænke meget længe og hårdt på, hvordan det fungerer, og hvad det betyder for din organisation, hvad du har brug for for at kunne levere.
Og derefter jongleren mellem hvad der er i lokalet, hvad der er eksternt vært og potentielt, hvad der er i skyen. Som jeg sagde før, kommer det også fra tidsudfordringer. Så vi overlades til det sidste spørgsmål, som jeg ser frem til vores venner på IDERA for at fortælle os, hvordan de adresserer netop disse ting, og det er det fine jongleri mellem at matche den ønskede og krævede tilgængelighed med ydeevnen, og hvad din virksomhed har brug for og hvad dit marked og dine forbrugere har brug for.
Og virkeligheden er, at det ikke er noget middelpræstation. Det vil tage tid, kræfter og penge overalt at tænke over disse ting. Og altid er det investering i mennesker og færdighedskapacitet og investering i software og værktøjer til at automatisere nogle af disse processer og give disse mennesker de rigtige værktøjer og de rigtige systemer til at gøre deres liv ikke bare bedre, men muligt fordi overvågning af meget store miljøer og beskyttelse og styring af disse store miljøer er ofte ud over individuelle menneskelige evner.
Så med det i tankerne har jeg forhåbentlig sat scenen for en god samtale for vores venner på IDERA til at tale om deres platform og værktøjer, og jeg ser frem til at stille nogle gode spørgsmål i slutningen. Og jeg går videre.
Dr. Robin Bloor: Okay. Bert, jeg har lige givet dig nøglerne, tag det væk.
Bert Scalzo: Tak! Tak, Dez og Robin. Jeg vil fortsætte med emnet med høj tilgængelighed for dine data. Og jeg kommer faktisk til at udnytte en masse af det, som Dez lige talte om. Så valgene, nierne, afvejningerne, overkommeligheden. Jeg vil prøve at sætte det mere i forhold til databaseadministratoren eller en, der er tættere på skyttegravene, hvordan ville de se på det? Hvordan ville de arkitektere det? Og hvad disse valg slags betyder.
Nu vil jeg prøve at være database-agnostiker. Jeg vil for eksempel ikke tegne en Oracle-specifik eller SQL-server-specifik løsning, men jeg vil tegne, lad os sige, en generisk arkitektur, som alle databaseleverandører tilbyder, noget i disse linjer. De kalder det alle under forskellige navne, men det er en type valg, som du har til fælles, og jeg vil se på det fra både forretnings- og teknologiperspektiv, og hvordan det relaterer til forretningskravene.
Og jeg vil starte med, hvad den mest basale løsning til pseudo-høj tilgængelighed er gennem de muligheder, du har på lagringsniveau-løsninger, virtualiseringsniveau-løsninger, på databaseløsninger. Og så vil jeg gerne også introducere dig for, at alle valgmulighederne også er tilgængelige i skyen.
Så igen, jeg vil prøve at forblive temmelig database-agnostiker. Nu, de fleste af de ting, jeg skal tale om, ved jeg, at de findes i Oracle, SQL Server, MySQL, PostgreSQL. Der er også nogle tredjepartsleverandører, der laver værktøjer, der også vil give dig yderligere arkitekturer, som du kunne overveje. Og som Dez lige sagde, ingen løsning er den bedste; det hele afhænger. Men der er en universel kendsgerning, hvad vi skal se på, er der vil være mere bevægelige dele, så det bliver mere komplekst og derfor dyrere.
Så vi ved alle, at data er et vigtigt aktiv. Og alle ved, at hurtig adgang til dataene altid er rart. Men pålidelig adgang til dataene er kritisk. Og som han talte om med sine ni eksempler, har du virkelig råd til at have 36½ dages nedetid? Det er kritisk, at disse data er tilgængelige hele tiden. Og så kan nedetid koste en formue, både med hensyn til tabt indtægt, men endnu vigtigere, hos mistede kunder eller i tab af kundegenwill. Jeg giver dig et godt eksempel; hvis et bestemt websted, hvor jeg foretager køb, er langsomt, kan jeg prøve at finde et nyt websted, der sælger lignende varer til en lignende pris, som ikke har langsomme websteder. Og så er det ikke kun tabet af kunden, det er den goodwill, som kunden har over for dig.
Nu er hardware meget billigere i disse dage, så der er derfor mere og mere efterspørgsel efter høj tilgængelighed. Og igen vil jeg føre os til skyen, når vi ser på det. Og vi har tilbud fra forskellige niveauer: lagerleverandører, databaseleverandører, virtualiseringsleverandører og nu endda skyleverandører. Og det, der virkelig er interessant med skyen, er, når jeg har tegnet alle disse vidunderlige billeder af disse arkitekturer, som du kunne bygge i skyen, mange gange er det bare nogle afkrydsningsfelter, du tjekker. Og du siger: ”Jeg vil have replikation på tværs af geografiske regioner.” Afkrydsningsfelt. “Jeg vil have replikation af nøglehardwarekomponenter.” Afkrydsningsfelt. Og så, hvis du forstår billederne, undertiden i skyen, er det bare at tjekke et par felter for at bygge det billede, du har i dit sind.
Nu er det vigtigste, hvad er de forretningsmæssige krav til høj tilgængelighed? For eksempel skal jeg kun bekymre mig om fejl på et enkelt sted, eller skal jeg have det på flere websteder? Med andre ord, kan jeg have et computercenter, og jeg er ligeglad med, om det ene center går offline? Jeg stiller ikke et forretningskrav om, at det udvides på flere websteder. Det er et forretningsspørgsmål. Og det er vigtigt at vide, hvordan virksomheden opfatter svarene på det spørgsmål, fordi det typisk definerer dit budget.
Nu vil du også se ned på niveauet for svigtbeskyttelse. Kunne det være en strømafbrydelse? Kan det være en komponentfejl? Ligesom en NIC eller en HBA går dårligt, en hostbusadapter. Er det en harddisk, der går dårligt? Er det et lagerskabssvigt? Er det en computerfejl? Eller er det i nogle tilfælde et webstedsfejl? Det er anderledes end i nogle tilfælde kan du have en webstedsfejl, fordi selve stedet ikke er offline. I et andet tilfælde kan det være, at en betydelig del af webstedet er offline, men fra dit perspektiv er det hele webstedet.
Og så, som Dez talte om, hvad er forventningen til tiden til at genoptage operationen? Det er et forretningsspørgsmål. Hvis virksomheden siger, at du skal være i stand til at genoptage driften inden for to minutter, er det åbenlyst, det vil definere nogle af disse billeder, som jeg vil vise, at du vil arbejde, og nogle af dem vil ikke være indstillinger, som du kan vælge.
Og et andet spørgsmål, der kommer op under høj tilgængelighed, men ofte glemmer folk at stille, er: "Hej forretning, hvis der sker noget, mens jeg er midt i behandlingen af en transaktion, hvad har jeg lov til at miste ved genoptagelse af systemet? " Med andre ord, hvis jeg kan bringe systemet op igen på to minutter, og jeg ikke kan miste mere end 10 sekunder af, lad os sige, transaktioner, der var på flugt, er det da acceptabel forretning? Og igen, det vil definere, hvad virksomheden er villig til at bruge til det, og derefter igen, der kan definere, hvilke billeder, jeg vil vise dig, enten anvender eller ikke anvender.
Så lad os starte med den mest basale løsning til pseudo-høj tilgængelighed. Dette er virkelig ikke stor tilgængelighed, men jeg kan godt lide at starte med dette, fordi det får folk til at tænke den rigtige måde. Hvis jeg har en server og en opbevaringsgruppe, lægger jeg typisk flere NIC'er, netværksgrænsefladekort på denne server og binder dem, så hvis en NIC mislykkes, er jeg stadig oppe. Og jeg skal gøre det samme med mine værtsbussadaptere, jeg multi-sti det gennem forskellige switches, så jeg har flere måder at komme til min lagerplads på. Og jeg har en universal strømforsyning, og jeg har gentagne styreenheder inde i min opbevaringsgruppe, og måske har jeg gjort noget som RAID 10 med mine diske. Med andre ord, på dette billede har jeg forhindret enkomponentfejl på flere niveauer. Så jeg er ikke bundet af NIC, HBA eller controller eller switch.
Men hvis du bemærker, er serveren i rødt, og opbevaringsarrayet er i rødt. Jeg har stadig to områder, hvor hvis de fejler, hvis min server går, er jeg død, hvis mit opbevaringsskab går, er jeg død. Så selvom dette ikke er rigtig høj tilgængelighed, begynder det dig at se og se på billedet og sige, "Jeg vil have et billede, hvor der ikke er rød." Og det er virkelig målet med disse billeder, at få os peget i den rigtige retning.
Så den første ting, der sker, er som en DBA, jeg måske altid ønsker at placere løsningen med høj tilgængelighed som en databaseimplementering, men det kan være, at det er tilgængeligt, at det kunne gøres som en lagerløsning, eller det kan være at det kan være en replikering på lagringsniveau. I tilfælde af venstre har jeg opbevaring virtualisering. Hvad der sker, er, at jeg har RAID 0 i to forskellige opbevaringsskabe til mine diske, men jeg har RAID 1 på tværs af de to forskellige opbevaringsskabe. Med andre ord, jeg kan faktisk nu få et opbevaringsskab, og jeg er ikke død. Så det er bedre end det forrige billede, for i det forrige billede - husk, at vi både havde rød på serveren og rød på opbevaringspanelet - og nu har vi gjort en lille forbedring, vi har nu ikke længere rød på lagringsniveauet, vi har brugt - opbevaring virtualisering løst dette problem.
En anden måde, du kan gøre det på - og ikke alle leverandører leverer dette - er nu, at du muligvis kan udføre replikering på lagringsniveau. Jeg taler ikke databasereplikation, jeg taler faktisk om at replikere din blok I / O til dit lager. Og det kan gøres på lagringsniveauet. Og så igen, nu har jeg på højre side, et andet billede, hvor jeg fjerner det røde fra bunden, fordi jeg bruger lagringsreplikation.
Og så er dette et andet billede, der muligvis er eller måske ikke er tilgængeligt. Og den person, der ville administrere dette, kan være din lageradministrator snarere end din databaseadministrator. Jeg kan godt lide at bringe dette op, fordi nogle gange folk tænker på, "Åh! Høj tilgængelighed, det må være DBA, der løser dette problem." Det er ikke altid sandt; det kan i dette tilfælde være lageradministratoren.
Dernæst kan vi udføre server virtualisering som en mulig løsning. Hvis du nu kan huske, på det første billede havde jeg rød på serveren og rød på opbevaringspanelet. I dette tilfælde kunne jeg ved hjælp af virtualisering muligvis være i stand til at flytte, og i nogle tilfælde er flytningen en slags varm flytning, og i nogle tilfælde kan det endda være en varm flytning. Nogle virtualisering eller hypervisorer giver mulighed for at flytte en virtuel maskine under flyvning. Og nogle databaser vil let acceptere denne bevægelse under flyvning. Nu igen, ikke alle hypervisorer leverer dette, men dette er et muligt niveau af løsning. Nu har jeg gjort, at de øverste servere ikke længere er røde, men jeg har stadig den delte lagringsarray og gæt hvad, denne løsning kan være en fælles indsats mellem databaseadministratoren og virtualiseringsadministratoren. Eller det kan endda være bare virtualiseringsadministratoren, afhængigt af, hvilket omlægningsniveau der understøttes på denne hypervisor og den database.
Hvis du undrer dig over, ”Wow, hvad mener han med denne flytning? Giv mig et specifikt eksempel. ”For eksempel i VM, hvor du muligvis kan bruge VMotion til at flytte din virtuelle maskine fra en vært til en anden og gøre det uden nedetid. Nu, klart, at forrige billede havde noget rødt i det stadig. Jeg havde stadig opbevaringen som et enkelt mislykkelsespunkt. Og så går vi op til den næste løsning, som er, ja, lad mig kombinere lagring og server virtualisering.
Nu, i dette tilfælde, igen, kan det være lageradministratoren og virtualiseringsadministratoren, der bygger denne løsning og ser nu ud: Jeg har et billede uden rød i den. Jeg har stor tilgængelighed, fordi jeg kan flytte den virtuelle maskine eller den kørende applikation eller database fra en server til en anden, og jeg har virtualisering i min opbevaringsgruppe ved at få den til at gøre RAID 1 på tværs af to separate opbevaringsarrays. Jeg har multi-pathed mine switches og mine HBAs.
Så nu har jeg bygget et HA-system, og jeg har primært gjort det ikke på databaseniveau. Med andre ord, jeg har brugt andre teknologier til at udføre den samme ting. Så dette er en løsning. Så får vi ind i det, der kaldes den skalerbare klynge til delt lagerplads. Det er virkelig ikke en HA-løsning, men igen, jeg kan godt lide at vise den til billedet.
Og hvad der sker her er, at vi har to servere, der kører en database, og den betragtes som en database. Det er ikke to separate databaser; det er ikke som en mester og en slave eller en varm og en kolde eller en aktiv og en standby. Dette er, at begge disse noder fungerer sammen for at præsentere en logisk database. Og hvad der sker er, hvis en bestemt knude mislykkes, er du stadig oppe. Så det beskytter dig mod svigt på serverniveau og gør det dybest set ved, sortering af, afskærmning af node-ressourcerne, hvis du vil, men du har stadig det eneste mislykkelsespunkt til bunden for disken. Og så er dette en skalerbar klynge med delt lagerplads, og Oracle kalder dette Real Application Cluster eller RAC.
Nu er en anden løsning at bruge en failover-klynge med delt lagerplads. Så til venstre har jeg en aktiv knude, til højre har jeg en passiv knude, jeg har et hjerteslag imellem. Jeg har en delt opbevaringsgruppe, og dette er kritisk; det skal du have. Og dybest set, hvad der sker, er, hvis den aktive knude støder på problemer, kan den passive knude overtage. Der er licensproblemer til dette. Nogle databaseleverandører giver dig mulighed for at have den passive knude med en reduceret licens i en fast tid. I andre tilfælde skal du have fuldstændig duplikatlicensiering. Det hele afhænger af din databaseleverandør. Men de støtter alle denne form for billede, som er, hvis den ene knude går ned, kan den anden knude overtage.
Og typisk er dette et af de scenarier, hvor det er slags, når du går fra den aktive knude til den passive knude, vil du sandsynligvis i de fleste databaser - ikke alle - du mister noget af in- flytransaktioner. Så får vi fat på, hvad databaseadministratoren virkelig kan se på, hvilket er databasereplikation, og der er to forskellige måder at udføre databasereplikation på.
Der er fysisk replikation, og hvad der er vigtigt er, i midten af dette billede kan du se med den grønne stjerne, at replikationen, den udføres af databasen, men ligesom virtualiseringen på lagringsniveauet foregår den ved blokken niveau. Så vi gentager den faktiske blok I / Os fra den aktive knude til den read-only eller passive node. Og dette betragtes som fysisk replikation.
Lad mig nu gå til det næste lysbillede, fordi det er næsten identisk, og det er logisk replikering, og det eneste, der ændrer sig i billedet, er, at i midten, i stedet for at sende over I / O-blokken, sender vi stort set loggen filer med SQL-kommandoer i sig. Så med andre ord, hvad vi replikerer er ikke den fysiske I / O, men kommandoerne, der forårsager den fysiske I / O.
Og så kaldes dette ofte logforsendelse eller logbaseret replikering. Nogle databaseleverandører giver dig dette indfødt. Andre databaseleverandører tilbyder muligvis ikke dette, men så tilbyder tredjepartsleverandører det, og derfor er dette en meget populær HA-løsning, og det betragtes som en komplet løsning. Men denne løsning er primært DBA's ansvar.
Så jeg bruger ikke virtualisering for at opnå dette. Det kunne jeg, men jeg er ikke afhængig af det. Og jeg bruger ikke lagervirtualisering. Igen kunne jeg, men jeg er ikke afhængig af det. Men jeg bygger en løsning, hvor databasen er den primære drivende funktion. Så dette er logisk replikation.
Nu er det også muligt at kombinere database- og lagervirtualisering. Jeg kunne have, ved mit datacenter, til venstre, til venstre i blåt, at jeg kunne have virtualisering til lageret, så jeg ikke er bundet til, at en bestemt lagringsgruppe mislykkes. Men jeg laver muligvis logbaseret eller logisk replikation på databasniveau fra det ene datacenter til det andet, så kommandoerne udføres også i datacenter, hvilket resulterer i I / O, men ikke nødvendigvis den samme I / O, fordi jeg ' m sender ikke over blok I / O, hverken med lageropløsningen eller af databasen, men jeg sender loggene og derfor SQL-kommandoer.
Og så, dette er et billede, der er et meget almindeligt billede for meget store organisationer. Og jeg kan godt lide dette billede her, for hvis jeg er nødt til at indstille dette på en forudsætning ved hjælp af en database som Oracle, kan jeg gøre det; det er en hel del arbejde, det er temmelig kompliceret, der er masser af bevægelige dele. Hvis jeg gør dette i skyen, kan jeg bogstaveligt talt bare sige, afkrydsningsfelt, jeg vil have to geografiske regioner, jeg vil have regionerne adskilt af, ved du på forskellige kontinenter, jeg vil have virtualiseringslagringsniveau i et bestemt geografisk område. Jeg kan endda sige, at jeg vil have evnen til at gøre tildeling af virtualiseringstype eller definition af høj tilgængelighed, og igen er det et andet afkrydsningsfelt.
Og den anden ting, jeg kan lide ved i skyen, er der en anden afkrydsningsfelt, der ofte siger: ”Jeg vil ikke beskæftige mig med patchning, bare lappe den, ” ved du, bare arbejd den ind i arbejdsgangen til alt andet, du gør bag scener, hold mig opdateret på alle tidspunkter. Og selvom nogle af disse billeder bliver meget komplekse, og de muligvis er meget vanskelige at gøre på en forudsætning, bliver de faktisk ganske nemme at gøre i skyen.
Nu er det interessante, det er let at markere alle afkrydsningsfelterne, men gæt hvad, det koster flere penge på månedlig basis. For hvis du kører to datacentre, ved du, du har to datacentre ude i skyen, som du bruger, betaler du mere end hvis du bare brugte et. Ligeledes, hvis du laver lagringsniveauet eller virtualiseringen med høj tilgængelighed som et ekstra lag, kan der igen være ekstra omkostninger.
Så det er interessant, at selvom det er svært at gøre på stedet, og du muligvis overtænker det, i skyen er det så let at gøre, så kan du muligvis undersøge det. Så ved altid, hvordan billedet ser ud, og ved altid, hvad omkostningsafgrænsningerne er for det billede, det er, du bygger. Nu er der meget flere kombinationer end hvad jeg viste her. Dette er ikke et komplet eller udtømmende eksempel. Der kommer nye teknologier med regelmæssige intervaller, så hvem ved - jeg har måske ikke vist en, der lige er kommet op i de sidste tre måneder. Og høj tilgængelighed er meget mere almindelig, end det var for ti år siden.
Faktisk vil jeg ikke betragte det som en strækning for at sige, at det for de fleste store organisationer er et obligatorisk forretningskrav i disse dage. Og jeg kan godt lide at vende tilbage til dette lysbillede, fordi jeg lige sagde, det er et obligatorisk forretningskrav. Og jeg fik disse to borde til højre. Den øverste er ud af SQL Server-dokumentationen, og den nederste er ude af Oracle-dokumentationen. Og hvad disse er, dette er tabeller, der hjælper dig med at vælge, ja, hvilken replikationsmetode skal du bruge.
Og bemærk, at du starter med nogle meget enkle spørgsmål. Hvor meget data må jeg bruge? Og hvis svaret er nul, ved du, at du kun i det øverste diagram kan vælge den første eller den fjerde række. Så stiller du et andet spørgsmål. Hvor lang tid har jeg lov til at tage mig til bedring? Og hvis nogen siger, ja, sekunder eller minutter, så gør det valg for dig. Og skal så failover være automatisk, eller kræver det, at nogen manuelt gør det? Og det er et andet forretningsspørgsmål. De siger måske, at de ønsker det automatisk, fordi de ikke ønsker at stole på, du ved, en eskaleringsprocedure og derefter nogen der får tildelt en billet og derefter løse problemet. De vil bare have det rettet.
Dette er alle forretningsspørgsmål, og det er de samme spørgsmål, hvis jeg går ned og gør det samme for Oracle. Og jeg spørger, OK, hvilken type fiasko tillader jeg, hvilken type varighed, hvad kan jeg miste, hvad er gendannelsesproceduren? Dette er alt sammen forretningsvalg, så hvis virksomheden fortæller mig svarene på tre eller fire spørgsmål, er mit job rigtig nemt, kommer jeg bare ind her, jeg vælger, hvilken af disse der matcher det nærmeste, og så bygger jeg det. Og husk, i skyen kan det bare være et par afkrydsningsfelter til faktisk at implementere disse.
Og med det bringer det mig til slutningen af mit materiale og tiden til at åbne dette for spørgsmål.
Eric Kavanagh: Okay, Dez, måske først og derefter Robin?
Dez Blanchfield: Absolut. Faktisk sandsynligvis lidt uretfærdigt for dem, der ikke er på Twitter, men jeg tweetede lige et billede af en graf, som jeg ønsker at visualisere i alles sind, og så ville jeg smide spørgsmålet til vores lærde ven på opkaldet her. Når jeg tænker på proprietær versus open source i dette rum - som ofte er det, vi taler om, slags, proprietære databaser fra lignende som Oracle og Microsoft osv. Kontra open source - ender du med denne udfordring, hvor den proprietære verden Internetsoftwareleverandøren eller softwareudvikleren eller virksomheden investerer i organerne, som den kompleksitet skal bygges i. Og så ender du med et scenarie, hvor du køber softwaren, og du ikke behøver at investere i mange mennesker, fordi du køber kapaciteten indbygget og i open source - du betaler ikke for softwaren, eller det er lave omkostninger, lad os sige, men du betaler ikke for softwaren, men du er nødt til at investere i organerne.
Og jeg er ivrig efter at få dine tanker om jongleren, især nu hvor vi flytter til skymodeller, hvor du kan få enten / eller. Du kan gå til AWS eller Azure og dit Rackspace, hvad som helst, og købe som en service, der leverer din databaseplatform, eller du kan gøre det gennem open source-kode. Og hvad vi lige har talt om, hvad er jongleren mellem proprietær og open source, og hvordan de designmønstre, du taler om, træder i kraft, og hvad er dine generelle tanker omkring dette emne, når vi bevæger os fremad, især omkring levering af tilgængelighed?
Bert Scalzo: En af de store ting, som jeg støder på, når jeg prøver at løse det spørgsmål, jeg går tilbage til kunden og spørger dem om deres ydelseskrav. Og grunden til at jeg gør det er, har jeg fundet - i det mindste historisk og efter min egen erfaring - at når det kommer til kunder, der har brug for stor gennemstrømning på deres replikering, er jeg næsten altid bedre stillet med den replikation, der leveres af databasen sælger på grund af den natur, at det er mere iboende indbygget og på et lavere niveau, og nogle gange bruger det mekanismer, der ikke er tilgængelige for omverdenen, selv i en open source-løsning.
Og jeg vil give dig et godt eksempel på en sag, jeg havde. Jeg havde et internetbaseret firma, der brugte MySQL som deres database, og de var på en gammel version af MySQL, ligesom version 4.0, og replikationen mellem deres noder var den begrænsende faktor for, hvor store de kunne skalere deres databaser. Og de så på at købe en tredjepartsløsning, så kiggede de på, "Nå, måske kan vi bruge en af open source-løsningen." Og hvad det virkelig kogte ned til var, alt hvad de skulle gøre var at opgradere deres MySQL til version, jeg tror, det var 5, 5, vi gik til, fordi forskellen mellem disse to databaseversioner var i 4.0-versionen af MySQL-replikation ikke blev trådt og i version 5.0 var det, og det var faktisk den bedste vej for dem.
Nu kiggede vi på de andre valg, men den afgørende faktor var ydelse og ophold hos databaseleverandørens løsning, og at udføre databaseopgraderingen endte med at blive vores bedste løsning for at få den største sandsynlighed for at få den ydelse, de havde brug for at gå sammen med jo større tilgængelighed.
Dez Blanchfield: Ja, det spejler min egen tankegang for at være ærlig. Bare for fuld afsløring, og jeg vil ikke gå ind på mærker, men jeg er kommet fra en proprietær baggrund, der arbejder for OEMs og softwareleverandører og IOC'er generelt, og det har bestemt været min oplevelse, og på samme tid er jeg meget pro -open-source, og jeg er en bidragydere til en masse projekter, som vi ikke vil navngive, men jeg er enig med dig i, at hvis du er en stor organisation - lad os sige, at du er en bank eller hvad du end måtte være - altid vil du ikke være en it-butik. Du ved, for eksempel, hvis du er en avisudgiver, eller hvis du er en detailhandler, du ikke ønsker at være en IT-butik, der udgiver aviser, du vil være en avisbutik, der faktisk bare udnytter IT.
Og så gør det meget mere fornuftigt at investere i de proprietære egenskaber, hvor softwareudviklere bygger al den kapacitet, belastningsbalanceringen osv. I værktøjet, hvis du er en dotcom-opstart eller noget som det der kan investere i menneskelige kroppe. Hvor ser du dette gå?
Sandsynligvis mit sidste spørgsmål, før jeg overleverer til Dr. Robin Bloor, fordi jeg ved, at vi kører kort tid. Hvor ser du dette gå ud fra et trendmæssigt synspunkt? Så du er derude hele tiden, du er på den blødende kant af tingene, ser du folk har sat sig op og opmærksom og vågnet op til behovet for at gøre dette til en kommerciel del af deres dag-til- dag samtale tilbage til bestyrelsesrummet? Eller ser du stadig, at det er meget den nørdegård, teknikerne og hættetrøje og tænker over tilgængelighed, fordi det får dem til at vågne klokken fire om morgenen, når noget går offline?
Tror du, at tendensen svinger nu til organisationer i alle størrelser, ikke de indlysende, som luftfartsselskaber og bank og finans, men bare virksomheder generelt? Tror du, at folk virkelig er kommet ud af værdipropositioner for at beskytte deres databasemiljøer og give høj tilgængelighed og investere i det, eller tror du, at vi stadig har en vej at gå? Hvad er den generelle mening på markedet derude?
Bert Scalzo: Lige nu tror jeg, at der stadig er et hul, men det er ikke et hul, fordi virksomheden ikke beder om det, det er et hul i kommunikationsniveauerne mellem de to sider af hegnet. Med andre ord siger forretningsfolk meget tydeligt, "Disse applikationer kræver stor tilgængelighed og har disse specifikke krav, når vi siger høj tilgængelighed."
Og på den ene eller anden måde får denne meddelelse ikke tydeligt ud til de tekniske mennesker. Eller de tekniske folk kommer tilbage og siger, ”Åh, det er kompliceret, og det vil koste dig flere penge, ” og dette, det eller det andet. Jeg tror, hvad der kommer til at ske, er, at det kommer til at erodere væk til sidst, for ærligt talt med at det for eksempel er i skyen, er det bare at tjekke et par bokse her eller der for at sige, ”Byg mig denne rigtig komplekse teknologistruktur, ” der virkelig ingen god grund for teknologifolkene til at vende tilbage og sige til forretningsfolkene, ”Åh, det er dyrt, ” eller ”Det er svært at gøre”, eller dette eller det, og forretningsfolkene begynder at vide, at det er faktum.
Og jeg har endda set i miljøer, hvor, du ved, deres egne it-folk kommer og siger: ”Åh, du kan ikke have, hvad du vil. Det er for dyrt. ”Og de kommer med et tredjeparts konsulentfirma, der derefter vil sige, ” Nej, det er ikke korrekt. Sådan kan du gøre det. Her er hvad det vil koste dig. ”Så jeg tror, at vi stadig har lidt tid mellem kommunikationsniveauerne mellem de to sider, før det bliver automatisk.
Dez Blanchfield: Ja, det er bestemt spejlet, hvad jeg har set her i Australien og omkring Asien og Stillehavet. Jeg er sikker på, at det er en global ting. Og det er, at mange af de vigtigste beslutningstagere fra bestyrelsesrummet nede, alle forretningsområder, de er 'meget mere teknisk kyndige - de læser bloggene, de ser webinarer, de er tunet til forskellige artikler og podcasts, og de går til begivenheder og fora og meetups, og de kender nu deres muligheder, og de ved, sky er en mulighed.
De ved også, at de kan bringe, som du sagde, deres kapacitet internt, og derfor synes jeg, der er denne interessante udfordring nu, den samtale, der er nødt til at finde sted, hvilket er dybest set, hvad vi har gjort i dag, hvor folk, slags, start med at gøre ting internt og bare køre frokostposer med brun taske og få en intern orientering om, hvad der er vores aktuelle tilstand, hvad er vores ideelle tilstand, hvor skal vi komme til? Og så, slags, få det sammen.
Jeg havde en privat besked, som jeg lige nu vil røre ved lige nu. Nogen stillede et spørgsmål, "Er det realistisk, at du kan få 100 procent tilgængelighed?" Og du kan muligvis rette mig her, men jeg vil sige ja. Jeg har bygget en platform til elektronisk pengeoverførsel, EFTPOS-gateway mellem hurtige bankplatforme og EFTPOS-terminaler. Jeg byggede dette i de tidlige 2000'ere. Det har faktisk været online 100 procent af tiden i 17 år. Faktisk blev det bygget før 2000'erne, men det gik kun i produktion i 2000/2001 i grove træk.
Så de 17 år har været på plads fra udvikling til test og derefter gå i produktion. I de 17 år har meget lave omkostninger uden for hylden pc'er, der kører et open source-operativsystem, men proprietær database, udført aktiv / passiv udveksling hver 90 dag, hvor der anvendes forskellige designpatenter med replikation af diske i hver server, replikation af data mellem modellservere, replikation af flere datacentre og vending fra datacenter A, der producerer i 90 dage og derefter vende til datacenter B og laver produktion.
Og når det vippes, opdateres og opdateres det automatisk, så bare til det spørgsmål, jeg lige har fået privat, ja, det er muligt, men med en masse investeringer i det projekt i et designmæssigt synspunkt. Så infrastrukturen var faktisk ikke så dyr, men designet og testen og implementeringen var meget dyre at få det. Så vi behøvede ikke at bruge en masse penge på hardware og infrastruktur, men vi brugte meget smarte værktøjer, tilbage i den dag, hvor sky ikke engang var en møntning.
Så svaret er ja, det kan gøres, endnu mere nu med sky, som vi lige har hørt, at du med et klik på en knap kan aktivere denne funktion. Jeg vil kaste det til Robin, fordi jeg er sikker på, at han også har spørgsmål. Men tusind tak, fordi du besvarede mine spørgsmål, og jeg elskede virkelig at høre din besked i dag. Helt ombord med alt det, fordi det spejler alt hvad jeg har gjort de sidste næsten 30 år selv.
Dr. Robin Bloor: Nå, okay, jeg henter det. En af de ting, der fascinerede mig ved din præsentation, var antallet af muligheder, der er tilgængelige nu, som ikke var tilgængelige, da jeg plejede at kæmpe med dette. Jeg er slags interesseret i, hvem der designer disse konfigurationer, eller hvem i dag designer disse konfigurationer? Hvad der tidligere skete, eller den verden, som jeg er vant til, er, at der ville være et ret tungt transaktionssystem, og du ville være interesseret i høj oppetid, høj tilgængelighed. Fordi, du ved, det transaktionssystem, det ville være dyrt, hvis det faldt på nogen måde. Og du ville ikke have alle de muligheder, du lige har præsenteret for mig, men på den ene eller den anden måde kunne du finde en måde, via replikering for det meste, til at oprette en varm standby, der ikke ville klikke unødigt ind, men det ville give dig en forringet service, indtil du kom tilbage.
Og jeg ser slags på, hvad du viste mig og tænker over det, ikke har udført noget af den slags designarbejde i 15 år, hvem laver det arbejde nu? Er det, som det var på min dag, noget, du gjorde ved starten af et projekt, ved du, at infrastrukturen kører? Eller er det noget, der er en løbende aktivitet i en organisation? Fordi der er nye teknologivalg, der følger med.
Bert Scalzo: I de store virksomheder, der er meget effektive og effektive til alle deres operationer, inklusive deres IT, har de typisk en centraliseret arkitekturgruppe, eller de har et eller andet navn på det, jeg har hørt det kaldes “the arkitekturgruppe ”mange gange. Og det er deres ansvar at kende alle disse forskellige billeder, hvad fordele og ulemper er, og hvad omkostningerne er. Og hvad der vil ske er, når en bestemt applikation kigger og siger: ”Hej, jeg er nødt til at opfylde forretningskrav X, Y og Z. Hej, arkitekturteam, hvad er mine valg?”
De vil give dem svaret, ligesom her er de to eller tre, der er tilgængelige, og derefter på dette tidspunkt flytter beslutningen tilbage til det lavere niveau til applikationsteamet eller til forretnings sponsor for applikationen. Men typisk er der en centraliseret gruppe, der holder sig på toppen af dette og har disse oplysninger klar og forudbygget.
Nu er det de mellemstore virksomheder, hvor det ikke er så formelt. Hvad der vil ske, er, at du får en eller to af dine senior DBA'er eller systemadministratorer, og de vil uformelt citere "domæneeksperten" for den slags ekspertise. Så selv i mellemstore virksomheder sker det bare i en ikke-formaliseret struktur.
Dr. Robin Bloor: Det er virkelig interessant. På min dag tænker vi aldrig på høj tilgængelighed undtagen for transaktionssystemerne. Nå, i dag har du selvfølgelig streaming-systemer, der sandsynligvis er underlagt endnu større krav med hensyn til tilgængelighed. Men i forespørgselsbaseret, back-end, analyse, datavarehus, DI slags miljø, ser du nogensinde krav til høj tilgængelighed der?
Bert Scalzo: Ja, og jeg er glad for, at du stillede det spørgsmål. Jeg gjorde noget arbejde for et detailfirma, og deres strategiske beslutninger for virksomheden var i en stor del baseret på den analyse, de ville gøre fra datalageret. Og faktisk blev de interviewet af Forbes Magazine, og administrerende direktør for virksomheden sagde: ”Hej, vores aktiekurs steg 250 procent i løbet af de sidste fem år, og en meget stor grund, der er sandt, er fordi vi ved, hvordan vi effektivt kan udnytte vores data i vores datavarehus. ”De var så gode til at tage forretningsbeslutninger, at for dem datalageret og at være i stand til at udføre disse analyser, ved at kunne tage beslutninger på daglig basis mod deres operationelle data, faktisk var for dem, et produktionssystem.
Og jeg vil give dig et godt eksempel på, hvor vigtigt det er. Hos denne bestemte detailhandler, den fyr, der var ansvarlig for ølsalg, var han ligesom den tredje vigtigste direktør i virksomheden, fordi han bragte, du ved, 60, 70 procent af omsætningen. Og så måtte han være i stand til, for at forblive konkurrencedygtig på dette marked, måtte han være i stand til at vide hver dag, ved du, hvilke kampagner skulle jeg køre. Og det kunne være baseret på, ved du ikke kun tid på året, men vejr, mønstre og andre kritiske data, der kan påvirke salg af noget som øl.
Dr. Robin Bloor: Nå, jeg antager, at der bestemt er ting som det. Vi er lidt for tidlige, jeg synes, jeg burde give Eric, hvis han har nogle spørgsmål fra publikum. Eric?
Eric Kavanagh: Ja, dette har alt været gode ting, Bert. Jeg tror, du adresserede alle de spørgsmål, vi havde fra publikum i din præsentation. Men det er sjovt at se på. Jeg er glad for, at du slags talte om opbevaringsvirtuualisering og hvor meget af en indvirkning der kan være. Så alt dette er gode ting.
Nå, folkens, vi arkiverer alle disse webcasts til senere visning. Så hopp online til Techopedia.com for at kigge efter webcast-sektionen. Alle disse Hot Techs vil blive vist her. En stor tak til vores ven Bert for hans ekspertise. Og selvfølgelig til Dez og Robin. Og med det tager vi farvel, folkens. Pas på. Vi taler til dig næste gang. Hej hej.
