De personalul Techopedia, 7 decembrie 2016
Take away : Gazda Eric Kavanagh discută despre disponibilitate cu Robin Bloor, Dez Blanchfield și Bert Scalzo de la IDERA.
În prezent nu sunteți autentificat. Vă rugăm să vă conectați sau să vă înregistrați pentru a vedea videoclipul.
Eric Kavanagh: Doamnelor și domnilor, salut și bineveniți din nou. Este ora patru ora estică într-o zi de miercuri, iar aceste zile pot însemna aproape un lucru dacă sunteți în lumea datelor: este încă o dată pentru Hot Technologies! Da, întradevăr.
Numele meu este Eric Kavanagh, voi fi gazda ta pentru spectacol. Este conceput pentru a descoperi ce este fierbinte, ce se întâmplă acolo, care sunt lucrurile minunate care sunt utilizate în întreprindere și, desigur, chiar la baza a tot ceea ce facem în acest întreg domeniu este baza de date. Vom vorbi deci despre protejarea bazei de date. Subiectul exact este: „Protejează-ți baza de date: Disponibilitate ridicată pentru date cu cerere ridicată”. Deci, există o prezentare cu adevărat despre a ta. Și, destul de mult, lovește-mă pe Twitter, @eric_kavanagh.
În primul rând, anul acesta este fierbinte, datele sunt fierbinți, datele mari sunt foarte fierbinți, dar sunt cu adevărat încă în continuare. Mai multe companii de vârf folosesc date mari în aceste zile, majoritatea organizațiilor de pâine și unt din lume, folosesc în continuare date tradiționale, iar dacă datele dvs. sunt la cerere ridicată, atunci doriți să vă asigurați că acestea sunt disponibile deoarece atunci când sistemele scad, când datele sunt inaccesibile, atunci când obțineți clienți nefericiți, perspective nefericite, obțineți clienții, obțineți tot felul de lucruri nefericite, parteneri, etc. Deci nu doriți asta.
Vom învăța de la unele dintre cele mai bune astăzi în afaceri - vom auzi de la propriul nostru Dr. Robin Bloor, expert în baze de date de aproximativ trei decenii. Dez Blanchfield, care face acest lucru de aproximativ timp, dar a început când era foarte tânăr, și Bert Scalzo de la IDERA, care este cu adevărat centura neagră a bazei de date. Așadar, nu vă rețineți, oameni buni, puneți întrebări - marea parte a acestui eveniment vă este valoroasă atunci când puneți întrebări bune și primiți răspunsuri bune, așa că trimiteți-le prin fereastra de chat sau componenta Q și A a consolei.
Și cu asta o voi înmâna lui Robin Bloor - ia-o.
Dr. Robin Bloor: OK, permiteți-mi să fac clic pe asta și să văd dacă se mișcă - da. Nu voi vorbi în special despre baza de date. M-am gândit că, știi, pentru că fac prezentarea de introducere, prima introducere, așa că voi vorbi despre nivelurile de servicii preconizate și desigur despre disponibilitatea, care este afacerea, care este subiectul emisiunii de astăzi.
Și întrebarea este să știți, „într-adevăr, ce este disponibilitatea? Și ce rol joacă în modul în care oamenii rulează centre de date în zilele noastre? ”Un lucru pe care l-am observat - am observat asta de fapt cândva în anii ’90 - lucram pe un singur site, iar utilizatorii au început să se plângă pentru că e-mailul lor era scăzut pentru 15 minute.
Și a fost interesant, deoarece CTO sau oricine era responsabil de IT, unul dintre puținele locuri în care în acele zile au determinat efectiv nivelul serviciilor și e-mailul redus timp de 15 minute nu a încălcat nivelul serviciilor nimănui. . Cred că este lăsat să stea două ore, de fapt. Nu e-mailul nu a putut fi folosit, ci doar că nu puteți trimite și primi, deoarece serverul era în afara. Și acest fel m-a avertizat asupra faptului că am observat că înaintez de atunci, că totul se grăbește și la fel și așteptările utilizatorilor, iar acest lucru te conduce la situația în care oamenii ar putea avea trei niveluri de servicii, dar deseori va începe să se plângă atunci când nivelurile serviciilor nu sunt încălcate efectiv.
Deci, definirea nivelurilor de servicii, doar pentru a da un bine, poate depinde exact de ceea ce vorbești în ceea ce privește nivelurile serviciilor. Am vorbit despre sistem IT sau aplicație IT. Definiți în mod normal în termeni de performanță, disponibilitate și metricare - cu alte cuvinte, nu puteți defini cu adevărat un nivel de serviciu decât dacă îl puteți măsura, deci în mod normal există un fel de măsurare implicată și, în mod normal, este vorba de timpii de răspuns, tranzacțiile particulare și disponibilitatea sistemelor într-o anumită perioadă de timp, și înainte de aproximativ 1994-1999, era foarte rar ca sistemele să fie necesare pentru mai mult decât orele normale de lucru. Așadar, să spunem opt dimineața până la șase seara, pentru a da un interval normal - iar oamenii au construit sisteme și în acest fel și asta a însemnat - în mintea mea, în special cu baza de date - puteți configura baza de date într-un mod anume și ca fereastra lotului a început să se micșoreze, nevoia de a gândi a început să apară din nou în unele sisteme și apoi în alte sisteme, și atunci am obținut apariția serviciului sau a arhitecturii, care a început să facă dependențe între sistemele care nu au fost anterior dependente de reciproc, ceea ce face și mai rău. Am obținut tensiunea în ceea ce privește disponibilitatea sistemelor.
Punctul pe care l-am făcut, a fost când vorbim despre disponibilitate, include backup și recuperare și include - parcă nu este doar disponibilitatea în termenii normali despre care vorbim; există o mulțime de moduri diferite în care o aplicație poate eșua. Știți, puteți întâmpina o eroare hardware sau puteți obține o defecțiune a bazei de date, puteți obține o eroare de software și există o mulțime de specii diferite din aceste lucruri, iar atunci când apare, trebuie să vă puteți recupera și, prin urmare, trebuie să vă întoarceți în sus sistemele. Așadar, trebuie să existe o schemă de rezervă a sistemului și, de asemenea, pe o mulțime de site-uri în prezent, aveți nevoie de capacitatea de recuperare a dezastrelor în cazul în care o clădire întreagă arde. Și ceva demn de menționat aici și am să mă ocup de asta într-un minut, dar procesele de afaceri, au și niveluri de servicii și, de fapt, nivelurile de servicii ale procesului de afaceri care contează cu adevărat pentru afacere. IT trebuie doar să-și îndeplinească partea din ea și în conformitate cu orice acord.
Nivelurile de servicii IT sunt, în mod normal, subsidiare nivelurilor de servicii ale proceselor de afaceri, dar așa cum era cu adevărat destul de rar acum 15 ani ca orice organizație să aibă niveluri de servicii bine definite, este încă destul de rar ca organizațiile să aibă niveluri de servicii bine definite pentru procesele de afaceri. . Este ceva care se întâmplă acum; nu este ceva care se întâmplă de multă vreme.
Aceasta este barierele de accelerare și de timp, merită menționate doar barierele de timp. Trecem treptat într-o lume de procesare a evenimentelor și, din această cauză, trecem treptat într-o lume în timp real și, din această cauză, trecem treptat la disponibilitate la a fi solicitate 24 până la 7 și asta este de fapt greu pentru o mulțime de sisteme - este dificil de realizat. Fie este foarte scump, fie în anumite cazuri, este posibil să fiți nevoit să schimbați sistemele, chiar să treceți la o bază de date diferită, o versiune diferită a software-ului de bază pe care îl folosim.
De asemenea, aceste bariere de timp - și întotdeauna îmi place să le menționez de fiecare dată când am o șansă - acestea sunt bariere de timp în care aplicațiile noastre se ocupă; aplicațiile pot dori să fie cât mai rapide posibil, atunci când software-ul vorbește cu software-ul. Într-adevăr nu există nicio licență acceptabilă în anumite situații, doriți să fiți cât mai repede, iar acele situații în termeni de afaceri precum situațiile de piață, în care persoana care vine cu comanda de cumpărare a doua primește un preț mai mic decât cineva cine vine primul și, prin urmare, viteza software contează cu adevărat.
Dar știi, mai jos de asta, atunci când ai de-a face cu interacțiunea - interacțiunea cu - ființele umane, cel mai bun timp de răspuns care poate fi solicitat cu adevărat este de o zecime de secundă, deoarece este vorba despre timpul de răspuns al unei ființe umane. Nu trebuie să mergeți mai repede decât atât, deoarece o ființă umană nu va observa oricum. Între 1, 1 și patru secunde este o perioadă de așteptare pe care ființele umane o vor tolera în mod normal, dar imediat ce treci peste patru secunde, acestea vor face altceva și, prin urmare, ești într-adevăr într-o activitate de lot.
Așadar, puteți vedea că anumite perioade de timp și zi, săptămână și luni pentru acele lucruri în care un comportament de lot are sens și, prin urmare, nu sunteți într-o lume de procesare a evenimentelor și, prin urmare, disponibilitatea ar putea fi de fapt diferită în ceea ce vă trebuie. pentru a putea asigura. Dar de îndată ce vă aflați în lumea evenimentelor, atunci sunteți într-o oarecare disponibilitate 24/7, iar schimbarea tehnologiei este un factor pe măsură ce tehnologia merge mai repede și mai repede, atunci disponibilitatea ar putea să nu crească; rămâne doar așa cum este.
Acestea sunt straturi de complexitate și nu vreau să intru în acest lucru în profunzime, este doar, știi, sunt trei lucruri de luat în considerare aici. Există un nivel de serviciu al infrastructurii, aceasta este axa verticală, apoi există un nivel de serviciu al oricărei aplicații date, apoi există un nivel de servicii pentru afaceri, iar acestea sunt dependente unele de altele și va trebui să fie luate în considerare dacă de fapt te uiți la crearea unui mediu receptiv în care nivelurile serviciilor sunt îndeplinite, practic.
Apoi aveți, în partea de jos aici, care sunt doar baze de date reprezentate, dar puteți face orice în cadrul sistemului, știți că aveți configurația non-stop, ceea ce înseamnă ce spune: nu se va opri niciodată. Aveți situația de așteptare caldă, în care într-un fel sau altul, există diferite modalități de realizare a acesteia, dar într-un fel sau altul, dacă o bază de date eșuează, este trecut la o stare de așteptare fierbinte și există foarte puțin decalaj în termeni de timp, până la punctul în care utilizatorii ar observa probabil, dar nu ar observa prea multe.
Așteptarea caldă seamănă mai mult cu comutatorul de 20 de minute în care toată lumea sună la biroul de asistență și mușcă la biroul de asistență în timp ce baza de date este trecută într-un mod de așteptare. Apoi, există o situație de repornire în care poate dura o perioadă foarte lungă de timp. Este demn de remarcat faptul că orice aplicație dată sau orice bază de date dată poate fi în oricare dintre situații, în funcție de ceea ce se întâmplă efectiv și de nivelul de servicii cerut de aplicație.
Din asta, vreau doar să fac un punct despre curba de complexitate. Complexitatea derivă din noduri și conexiuni, dependențe. În lumea în care trăim, numărul de noduri și conexiuni implicate în orice lucru continuă să crească, așa că alergi la acest tip de curbă expedientială. Dacă puteți analiza modul în care complexitatea crește și modul în care dimensiunile timpului scad, atunci știți pentru nivelurile de disponibilitate, există ținte de timp, este probabil să se reducă?
Și, prin urmare, evoluția naturală este spre o funcționare non-stop, care este desigur cea mai scumpă - cel puțin din experiența mea - este cea mai scumpă configurație pe care o puteți crea. Într-un fel sau altul, orice organizație care se gândește la acest lucru, trebuie să se gândească nu doar la ceea ce se întâmplă acum, ci la ce se va întâmpla în viitor.
Poate că ultimul punct pe care vreau să-l fac este acela, gestionarea nivelurilor serviciilor este o activitate în desfășurare; nu este ceva ce știi că ai un proiect, îl faci și s-a terminat. Nu este, pentru că lucrurile continuă să se schimbe. Acestea fiind spuse, voi trece mingea lui Dez.
Dez Blanchfield: Mulțumesc Robin. Îmi place diapozitivul de deschidere. Tocmai am reînceput, cred că este „Finding Nemo 2”, filmul. L-ai avut pe Nemo căutând disponibilitatea sub formă de noi, ceea ce am considerat că este destul de drăguț. Întotdeauna un act greu de urmat. Când mă gândesc la uptime, disponibilitate și performanțe ridicate, prima imagine care îmi vine în minte, pentru că am crescut în Insulele Solomon, lângă vulcani și ecuator, este un vulcan care erupe în centrul meu de date; există această imagine pe care o am întotdeauna în minte că asta se poate întâmpla dacă se întâmplă ceva. Aceasta este o imagine a Muntelui minunat. Etna, care este colțul de nord-est al Siciliei, care este chiar lângă Catania.
Abordarea mea în acest sens este de a avea o conversație cu tine și de a-ți oferi câteva oferte la același nivel pe care o fac într-o sală de consiliu în mod regulat din apartamentele C și șefii de afaceri, în vederea că avem o conversație despre ce poate afecta organizația dvs. dintr-un sens comercial sau tehnic și tipurile de inginerie.
Trebuie să ne gândim și cum - la ce ne îndepărtăm și cum să abordăm apoi unele dintre provocările despre care vorbim atunci când vorbim despre disponibilitate ridicată și timp liber, în special în jurul automatizării și platformelor.
Deci, întrebarea pe care ne-o punem inițial este, ce înseamnă de fapt atunci când vorbim despre sisteme de baze de date și disponibilitatea platformelor de baze de date? Ce înseamnă de fapt să vorbim despre provocarea reală de a pune ceva la dispoziția unui nivel așa cum a vorbit Robin în cartografierea instalată a acordului la nivel de serviciu despre ce ne trebuie și dorim de fapt?
Deci, realitatea de astăzi este că - și, de fapt, aici sunt câteva realități de vârf în mintea mea - astăzi totul este condus în mod eficient de baze de date. Există foarte puține sisteme care sunt construite astăzi și sunt construite în așa fel încât lucrurile să fie doar stocate în fișiere sau este un fel de jurnal de fișiere plate; invariabil, totul este condus de baze de date. În consecință, avem această necesitate să nu ne mai gândim la disponibilitatea acestor baze de date, la diferitele sisteme și aplicații și instrumente care depind de ele și se bazează pe ele pentru a furniza serviciile pe care căutăm să le livrăm, să le vindem sau să le consumăm . Și toată infrastructura din jurul ei.
De fapt, atât de mult, când vă gândiți la marile perturbări ale datelor din târziu, în special, nativii digitali sau nativii cloud, unele dintre companiile care au apărut precum Uber și Airbnb și altele, și PayPals puțin mai vechi. și eBay-urile lumii - amploarea și dimensiunea acelor organizații este posibilă doar datorită tehnologiei moderne de baze de date și a infrastructurii cloud moderne. Fără asta, fără capacitatea suplimentară oferită, cu siguranță nu ar exista. Imaginați-vă un scenariu în care puteți ajunge doar la eBay între orele 9:05 și 9:25, deoarece acesta nu era disponibil pentru restul zilei, deoarece încerca să facă un iCloud sau o copie de rezervă sau ceva de genul, pur și simplu nu ar fi avut a lucrat.
Așadar, există și alte domenii cheie când vă gândiți la viața noastră de zi cu zi, știți, cum ar fi retailul și serviciile bancare, finanțele și companiile aeriene etc. Marile grupuri industriale precum logistica aviației, transportul maritim, există guvernul în ansamblu, există securitate națională și poliție și așa mai departe. Toate aceste industrii, toate aceste segmente de piață, toate aceste organisme, grupuri depind de mediul în care funcționează.
Deci, având în vedere acest lucru, avem și cealaltă atenție la care trebuie să ne gândim, cealaltă livrare la care vreau să vă las să vă gândiți și că lumea noastră este acum ceea ce numesc „mereu mai departe”. Suntem conectați permanent și aceasta este o temă pe care o veți auzi în mod regulat și o să o repet și o voi reitera. Acum avem smartphone-uri în mâinile noastre toată ziua, în fiecare zi. Nu le oprim, le așezăm lângă pat, le folosim invariabil ca ceasuri de alarmă, le folosim ca camere de luat vederi și facem fotografii, ele împing fotografiile în sus.
Ei sunt mereu în continuă, permanent conectați mentalitatea. De fapt, există o monedă de frază pe care îmi place să o folosesc și este că acum trăim generația Fitbit, care este unde măsurăm totul, monitorizăm totul și trebuie conectat și asta va merge undeva.
Și există și o altă frază cu care o să vă părăsesc și adică este ora nouă undeva, tot timpul. Este o lume în 24/7/365 în care trăim. Pământul se învârte constant în jurul Soarelui și, la un moment dat, și ora, în fiecare oră din zi, este ora nouă. Și asta înseamnă că oamenii se dau jos din pat și încearcă să facă lucruri, să cumpere lucruri, să instaleze lucruri etc.
Deci, ce ne referim atunci când vorbim de disponibilitate ridicată? Ei bine sună foarte evident până când începi să te arunce în detalii. Deci, știi când ne gândim la „OK, ce înseamnă disponibilitate ridicată?” Ei bine, realitatea este că nu există un glonț de argint. Este un concept destul de complex, așa cum a relatat Robin cu unele dintre subiectele pe care le-a menționat, cum ar fi măsurarea disponibilității și a acordurilor la nivel de serviciu. O punem la punct cu lucruri de genul acesta, am aceste întrebări, este timpul de funcționare? Ne facem griji pentru lucruri precum ceea ce numim noi cinci, pe care le voi parcurge într-un minut. Ne considerăm cu ce se află în acordurile noastre la nivel de serviciu? De exemplu, în acordurile la nivel de serviciu, vreau să spun că există întârzieri, acronimul de trei litere pentru acordurile la nivel de serviciu au devenit din ce în ce mai critice în aceste zile.
Pe măsură ce parcurgeți acest întreg proces de găzduire pe site-ul și self-hosting pentru a fi externalizate către centrele de date terțe și a serviciilor gestionate externalizate, acum vom merge până la cloud. Și realitatea este când vorbești despre cloud, sunt doar computere ale altor oameni. Și asta înseamnă că nu executați infrastructura, nu executați sistemele și invariabil nu executați cloud. Faceți infrastructură înființată ca platformă, deci este și mai important în serviciul forței de vânzare. Acum imaginați-vă vânzările, de exemplu, știți că nu atingeți nicio infrastructură, ci doar vă conectați la o interfață web.
Deci, singurul mecanism pe care îl aveți în acea lume a infrastructurii cloud și externalizate de orice formă de control care este acordurile la nivel de serviciu, acesta este singurul mecanism pe care îl aveți și, dacă oamenii nu vă îndeplinesc instalarea, atunci vor suporta. penalități și o reducere a sumei de bani pe care le plătiți sau pur și simplu nu le plătiți.
Deci, asta ne readuce în minte această întreagă provocare a, cum știți, cum gestionăm disponibilitatea ridicată? Cum gestionăm timpul de funcționare a disponibilității dacă nu este infrastructura dvs. - este vorba de SLA, de exemplu. Dacă este infrastructura dvs. sau chiar dacă este infrastructura altcuiva ca punct de vedere al proiectării. Am vorbit despre echilibrarea sarcinii la știința modelului, este un brevet de proiectare a toleranței la erori?
Rulează activ activ sau standby activ în arhitecturile tale? Aveți mai multe servere, mai multe platforme de stocare? Cum funcționează acele platforme de stocare? Se reproduc reciproc, se oglindesc? Executați RAID? Ce tip de RAID executați pentru stocarea redundantă? Rulează RAID la nivel de disc? Rulează o platformă de stocare a obiectelor care se reproduce pe unități de model și sisteme model și unități? Este N plus una pentru fiecare bucată de infrastructură pe care o ai? Adăugați altul și se află în același centru de date sau în alt centru de date? Ați construit un brevet de design care nu reprezintă un singur punct de vânzare, de exemplu?
Toate aceste lucruri fundamentale, acum sună ca niște concepte simple, dar când intrați în fiecare dintre aceste lucruri sunt lucruri foarte, foarte detaliate. Când vorbim despre disponibilitate, ajungem invariabil să vorbim despre noi. Și ce ne referim la noi? Cu toții am auzit despre acestea, dar hai să ne gândim doar la ce înseamnă pentru un minut și de ce sunt importante.
Deci, vorbim despre o nouă, care este doar 90 la sută din disponibilitatea noastră. Știu că sună foarte sus. Deci, când vorbim 24 de 7 câte 365, dacă ne uităm doar la un an, de exemplu, când vorbim la nouă, care este 90% din timp, asta permite treizeci și șase zile și jumătate de oprire pe an. Hai să rotunjim asta la puțin peste o lună.
Acum gândiți-vă la orice afacere cu care ne ocupăm zilnic - fie că este vorba de servicii bancare online, eBay, PayPal sau platforme de social media precum LinkedIn, Twitter sau doar un retailer general - să zicem doar că am vrut să rezerv un zbor pentru a veni în SUA de la soare. Australia, aș fi fericit dacă aș vrea să vin în America într-un timp de câteva săptămâni, dacă compania aeriană preferată a scăzut timp de treizeci și șase de zile și jumătate, deoarece furnizorul lor de servicii a spus: „Uite, suntem în creștere de 90 la sută din timp „? Bineînțeles că nu aș face.
Pe măsură ce urcați acest model, două noi: 99 la sută. Ei bine, acesta devine 3, 65 zile, aproximativ trei zile și jumătate de oprire pe an. Este o afacere mare? Ei bine, dacă executați Black Friday și faceți o vânzare specială, iar oamenii pot cumpăra doar în acele două zile.
Trei noua devin la fel de 8, 7 ore pe an, dar chiar și 8, 7 ore pe an, asta înseamnă non-stop opt ore din timpul nostru. Ei bine, asta în domeniul bancar și al finanțelor, în sănătate - dacă este un spital, asta ar putea să coste viața. În timp ce urcați, patru noi sunt de 52 de minute, cinci de nouă sunt de cinci minute și șase de nouă sunt de fapt 30 de secunde. Șase noi sunt extrem de înalți și, pe măsură ce urcați această scară, pe măsură ce urcați în acest brad de Crăciun cu noi, cu cât urcați mai mulți, cu atât este mai greu designul, mediul și platforma. Cu cât este mai greu să furnizați acest serviciu și dacă vă gândiți la reducerea duratei de timp pe care o aveți pentru ca lucrurile precum backup-urile să fie rulate, administrarea, patch-urile, Windows-ul de întreținere pentru orice formă de întrerupere - toate provocările non-banale - și totul se reduce la procente de întreruperi, în mod eficient.
Cheia aici pe care aș dori să o transmit este că nu există niciun glonț de argint, așa cum am menționat anterior. În ceea ce privește disponibilitatea, nu există o „dimensiune unică pentru toate”. Este posibil să aveți un anumit tip de brevet de design care să se potrivească industriilor cheie. Aceleași provocări se confruntă cu toate băncile. Unele pot fi bănci cu amănuntul, altele pot fi bănci premium. Unele bănci s-ar putea concentra pe tranzacționare și investiții, gestionarea averii. Unii ar putea fi doar consumatori. Unele ar putea doar să plaseze internet și nici măcar să nu aibă telefoane și să se ocupe doar de bancomate atunci când se distribuie numerar. Așadar, în acele scenarii, chiar și în industria bancară și în managementul averii și în industria serviciilor financiare, în ansamblu, pentru fiecare dintre ele au încă propria sa aromă sau ceva de care au nevoie atunci când vine vorba de disponibilitate.
Deci, când ne gândim la disponibilitate în limba engleză simplă, amestecul dintre disponibilitate și disponibilitate ridicată - credem că sunt același lucru, dar sunt de fapt cretă și brânză. Disponibilitatea este, am pus-o în engleză simplă, o măsură de timp pe care un server sau un proces funcționează normal sau în general, legată de utilizarea lor. Asta înseamnă doar cum descriem dacă este disponibil sau nu. Când vorbim despre disponibilitate, adesea intrăm în această capcană a gândirii, „O ofer într-o formă disponibilă”, versus o disponibilitate ridicată în protejarea securității respectivei infrastructuri.
Disponibilitatea ridicată, într-un alt sens, în limba engleză simplă, este designul în care implementați sau obțineți un fel de rezultat și disponibilitate de date, în special acolo unde aproape tot timpul - 24/7/365 zile pe an - această disponibilitate ajunge la unele dintre acestea nouari. Invariabil nu înseamnă 100 la sută. Sută la sută nu este posibil din punct de vedere tehnic într-o lume reală într-un singur mediu. Este foarte dificil pentru un server dintr-un sistem de operare, cu o bază de date pe ea, cu o platformă care funcționează și că o aplicație o puteți livra și vă așteptați să ruleze 100 la sută. Atunci începem să ne gândim la modele. Avem disponibilizări, avem mai multe diapozitive de reprodus? Apoi, când o puneți în engleză simplă, este interesant cât de diferit devine subiectul disponibilității față de disponibilitate ridicată.
M-am gândit că o voi pune într-o formă grafică simplă, tocmai pentru a ne face o idee despre cum arată acest lucru atunci când începeți să urcați provocarea creșterii disponibilității în protejarea serviciului dvs. de funcționare. În colțul din stânga jos avem un singur nou. Am pus la punct cele cinci noi despre care vorbim în general. Șase nouă este un pic scandalos. Când vorbim despre cinci noi în colțul din stânga jos, 35 de zile aproximativ în acest caz, este un mediu cu costuri reduse și complexitate scăzută pe care încercați să îl oferiți deoarece aveți o serie de lucruri care pot eșua și puteți îndepliniți în continuare acordurile dvs. la nivel de serviciu.
Dar, pe măsură ce mergeți de jos de la stânga la dreapta și ajungeți la punctul în care există mai mulți noi în imagine, obțineți scenariile în care începeți să vă gândiți la replicarea sistemelor și a platformelor. Trebuie să vă gândiți la clustering și virtualizare a diferitelor părți ale infrastructurii. Trebuie să vă gândiți la geolocalizarea acelor clustere, la mai multe site-uri de centre de date și trebuie să vă gândiți la tipul de industrie și segmentul de piață pe care îl vizați. Deci, ce tip de serviciu trebuie să îndepliniți? Ce prestare de servicii căutați? Zonele care sunt servicii bazate pe carduri în timp real care comunică comunicațiile. Este vorba de servicii militare? Deci, acest grafic merge de jos în stânga la dreapta sus și pe măsură ce treceți prin acea curbă, costurile și complexitatea cresc. Pe măsură ce veți obține medii mai complexe și mai pretențioase, veți avea nevoie de mai mulți noi.
Acest grafic, de exemplu, face un lucru foarte similar: descrie povestea dintre componenta de cost versus componenta de disponibilitate dorită. Așadar, în colțul din stânga sus, cartografiem sisteme complexe extrem de disponibile, iar costurile suportate în cazul în care disponibilitatea scade față de avantajul de a avea disponibilitate în timp de oprire zero. Așadar, de exemplu, dacă avem un mediu pe partea stângă în care lucrurile stau jos, putem suporta pierderi care sunt financiare. Avem implicații legale care pot fi implicații comerciale la nivel de strategie comercială.
Bănuiesc că există tot felul de probleme potențiale, chiar și de a avea beneficii pentru un serviciu. Dacă este o industrie a sănătății și încep să coste o întrerupere, un impact asupra clienților, reducerea satisfacției clienților, productivitatea personalului, productivitatea utilizatorului, etc. Aceste lucruri sunt afectate dacă ne gândim la proiectarea extrem de complexă, foarte dependentă mediu cu risc ridicat în care există riscul potențial de întrerupere și, prin urmare, pierdere.
În partea dreaptă încercăm să vizăm un scenariu în care, dacă investim costuri ridicate și planificăm în proiectare, investim în implementare inteligentă. Investim în furnizarea de abilități și resurse oamenilor și am luat în considerare mediul operațional de rețea și foarte apreciat, hardware și software. Avem o disponibilitate ridicată, dar are un cost ridicat. Deci, locul pendulului magic care se leagănă în poziția optimă în mijlocul unde se traversează, unde avem un cost redus ușor și crește disponibilitatea care jonglează doar între nivelurile de nouă și disponibilitatea ridicată care este disponibilitatea continuă și aceasta este o o provocare continuă pe care o vom întâmpina, cât de mulți bani sunteți dispuși să investiți pentru a obține nivelul de servicii pe care îl căutați?
Avem, de asemenea, subiectul în care nu voi pune în detaliu, dar vreau doar să le îndepărtați și să vă gândiți la asta. Diferența dintre timpul mediu dintre eșecul proiectării dvs., iar timpul mediu de recuperare. Cu alte cuvinte, investești în infrastructură de mai bună calitate, proiectare de calitate mai bună, hardware și software de mai bună calitate și personal calificat și resurse mai bune pentru a proiecta lucrurile și pentru a reduce timpul mediu dintre eșec, timpul mediu necesar pentru a găsi pauză, reducerea investițiilor în infrastructură, în resurse și proiectare și brevete nevăzute, capacitatea ridicată de recuperare? Cu alte cuvinte, dacă se rupe ceva, ai multe de conectat. Dacă cineva are un laptop și moare, ai unul de rezervă. Îi înmânați și în 30 de secunde se conectează. Acestea sunt extrem de diferite ale polului. Cel de sus este important pentru o inginerie cu costuri ridicate și investiții mari, pentru a evita eșecul, iar cel de jos spune că „Eu voi accepta că eșecul va veni, așa că o să mă inginer în acest sens și voi fi pregătit pentru eșec. și recuperați-vă repede. ”
Așa cum am menționat anterior, unde aș putea spune, „Disponibilitatea mea nu este disponibilitatea ta.” Așadar, când vine vorba de medii de baze de date și de susținere a infrastructurii, de administrare a bazei de date și de protejare a acesteia și de asigurare a unei disponibilități ridicate, nu există într-adevăr un singur punct . Fiecare are propriile nevoi și dorințe. Deci trebuie să vă puneți aceste întrebări fundamentale cu care vă voi lăsa și care este: Ce își poate permite organizația dvs.? Nu vorbesc doar de dolari și cenți. Vorbesc despre ce, ca organizație, ce vă puteți permite din resurse, timp și efort și așa mai departe, cât puteți oferi nivelul de disponibilitate? De asemenea, ce poate susține afacerea dvs.? Deci, capacitățile actuale, abilitățile actuale, infrastructura actuală, finanțarea curentă pe care o puteți acumula. Deci, că jonglează între ceea ce îți poți permite efectiv față de ceea ce poți susține este un echilibru interesant.
De asemenea, trebuie să vă puneți întrebările: Ce abilități și tehnologie aveți în interior? Puteți externaliza o parte din această provocare? Puteți apoi să mutați lucrurile în cloud? Dacă aveți serviciul de infrastructură în afară de serviciul software, rămâneți fără acea stivă în timp ce mergeți mai departe în stivă. Așadar, ar trebui să investești mai mult în platforme și servicii și să nu îți faci griji pentru piesa de infrastructură sau ar trebui să privești software-ul ca pe o ofertă de servicii, deoarece nu ar trebui să îți faci griji pentru platformă?
Ce tip de piață și consumator sau client prestați? Adică, dacă ești telecom și cineva trebuie să ridice telefonul și primești un ton de apelare tot timpul, asta este o provocare foarte diferită de a deschide un mic magazin cu amănuntul între luni și vineri, de la nouă la cinci și de a închide pentru un ora la masa de prânz ca un frizer din magazinul de colț. Așadar, trebuie să te gândești foarte mult și la greu cum funcționează asta și ce înseamnă asta pentru organizația ta, ce trebuie să poți oferi.
Și apoi jonglerul dintre ce este la sediu, ce este găzduit extern și potențial, ce se află în cloud. Așa cum am mai spus, asta vine și din provocările timpului. Așa că ne rămâne la acea întrebare finală pe care aștept cu nerăbdare prietenii noștri de la IDERA să ne spună cum abordează aceste lucruri, și aceasta este jonglarea perfectă între potrivirea disponibilității dorite și cerute cu performanța, și ceea ce are nevoie afacerea dvs. și ce piața dvs. și consumatorii dvs. au nevoie.
Și realitatea este că nu are nicio legătură. Va fi nevoie de timp, efort și bani pentru a ne gândi la aceste lucruri. Și invariabil este investiția în oameni și abilități în abilități și investiții în software și instrumente pentru a automatiza unele dintre aceste procese și pentru a le oferi oamenilor aceste instrumente și sisteme potrivite pentru a-și face viața nu doar mai bună, dar posibilă pentru că monitorizează medii la scară largă și protejează și gestionarea acelor medii la scară largă este adesea dincolo de capacitățile umane individuale.
Așa că, cu asta în minte, sper să am creat scena pentru o conversație minunată pentru prietenii noștri de pe IDERA pentru a vorbi despre platforma și instrumentele lor și aștept cu nerăbdare să pun câteva întrebări grozave la final. Și voi trece mai departe.
Dr. Robin Bloor: Bine. Bert, tocmai ți-am dat cheile, ia-o.
Bert Scalzo: Mulțumesc! Mulțumesc, Dez și Robin. Voi continua cu tema disponibilității ridicate pentru datele dvs. Și, de fapt, voi profita foarte mult de ceea ce tocmai a vorbit Dez. Deci, alegerile, noul, compromisurile, accesibilitatea. Voi încerca să pun asta mai mult în termeni de administratorul bazei de date sau de cineva care să fie mai aproape de tranșee, cum ar privi-o? Cum ar arhitect-o? Și ce înseamnă acele alegeri.
Acum, voi încerca să fiu agnostic în baza de date. Nu am de gând să desenez, de exemplu, o soluție specifică Oracle sau SQL-Server specifică, dar voi desena, să zicem, o arhitectură generică pe care o oferă toți furnizorii de baze de date, ceva de-a lungul acestor linii. Toți îl numesc cu nume diferite, dar acesta este un singur tip de alegere pe care îl aveți în comun și vreau să îl privesc atât din perspectiva afacerii, cât și a tehnologiei și a modului în care se raportează la cerințele afacerii.
Și vreau să pornesc de la ceea ce este cea mai de bază soluție de înaltă disponibilitate pseudo-înaltă prin opțiunile pe care le ai la soluții la nivel de stocare, la soluții la nivel de virtualizare, la soluții la nivel de bază de date. Și atunci vreau să vă prezint și faptul că toate alegerile sunt disponibile și în cloud.
Așa că, din nou, voi încerca să rămân destul de agnostic în baza de date. Acum, cele mai multe lucruri despre care voi vorbi, știu că există în Oracle, SQL Server, MySQL, PostgreSQL. Există, de asemenea, unii furnizori terți, care realizează instrumente care să vă ofere arhitecturi suplimentare pe care le puteți lua în considerare. Și, cum a spus doar Dez, nicio soluție nu este cea mai bună; totul depinde. Dar există un fapt universal în ceea ce urmează să analizăm, este că vor fi piese mai mobile, deci va fi mai complexă și, prin urmare, mai costisitoare.
Deci, știm cu toții că datele sunt un atu important. Și toată lumea știe că accesul rapid la date este întotdeauna plăcut. Dar, accesul fiabil la date este esențial. Și cum vorbea despre exemplele sale de nouă, vă puteți permite cu adevărat să aveți 36 de zile de oprire? Este esențial ca aceste date să fie disponibile tot timpul. Astfel, timpul de inactivitate poate costa o avere, atât din punct de vedere al veniturilor pierdute, dar și mai important, al clienților pierduți, fie al pierderii bunăvoinței clienților. Vă voi oferi un exemplu bun; dacă un anumit site web unde fac achiziții este lent, aș putea încerca să găsesc un site nou care vinde articole similare la un cost similar, care nu au site-uri web lente. Și deci, nu este doar pierderea clientului, ci bunăvoința pe care clientul o are față de tine.
Acum, hardware-ul este mult mai ieftin în aceste zile, prin urmare, există din ce în ce mai multe cereri de disponibilitate ridicată. Și din nou, o să ne conducă spre nor, când ne uităm la asta. Și avem oferte de la diferite niveluri: furnizorii de stocare, furnizorii de baze de date, furnizorii de virtualizare și acum chiar și furnizorii de cloud. Și deci, ceea ce este cu adevărat interesant cu cloud este după ce am desenat toate aceste imagini minunate ale acestor arhitecturi pe care le-ați putea construi în cloud, de multe ori sunt doar câteva căsuțe pe care le bifați. Și spuneți: „Vreau replicare în regiuni geografice.” Caseta de selectare. „Vreau replicarea componentelor hardware cheie.” Caseta de selectare. Și deci, dacă înțelegeți pozele, uneori în cloud este doar să verificați câteva căsuțe pentru a construi imaginea pe care v-ați luat-o în minte.
Acum, lucrul cheie este, care sunt cerințele de business pentru o mare disponibilitate? De exemplu, trebuie să-mi fac griji doar pentru eșecul unui singur site sau trebuie să îl am pe mai multe site-uri? Cu alte cuvinte, pot avea un centru de calcul și nu-mi pasă dacă acel centru este offline? Nu fac o cerință de afaceri care să se extindă pe mai multe site-uri. Este o întrebare de afaceri. Și este important să știi cum percepe afacerea răspunsurile la această întrebare, deoarece acest lucru definește de obicei bugetul tău.
Acum, de asemenea, doriți să priviți în jos nivelul de protecție împotriva defecțiunilor. Ar putea fi o pană de energie? Ar putea fi o defecțiune a componentelor? Ca un NIC sau un HBA merge prost, un adaptor de autobuz gazdă. Este un hard disk care merge prost? Este o defecțiune a dulapului de depozitare? Este o defecțiune a calculatorului? Sau, în unele cazuri, este un eșec al site-ului? Acest lucru este diferit decât, în unele cazuri, puteți avea un eșec al site-ului, deoarece site-ul în sine este offline. În alt caz, se poate ca o parte importantă a site-ului să fie offline, dar din perspectiva dvs. acesta este întregul site.
Și atunci, în timp ce vorbea Dez, care este așteptarea timpului de a relua operațiunile? Aceasta este o întrebare de afaceri. Dacă afacerea spune că trebuie să poți relua operațiunile în două minute, atunci, evident, asta va defini unele dintre aceste imagini pe care le voi arăta că vor funcționa, iar unele dintre ele nu vor fi opțiuni pentru care Poți alege.
Și o altă întrebare care apare în timpul unei disponibilități ridicate, dar de multe ori oamenii uită să pună este: „Hei, afaceri, dacă se întâmplă ceva în timp ce sunt în mijlocul procesării unei tranzacții, ce am voie să pierd la reluarea sistemului? " Cu alte cuvinte, dacă pot readuce sistemul în două minute și nu pot pierde mai mult de 10 secunde din, să zicem, tranzacții care au fost în zbor, este o afacere acceptabilă? Și din nou, asta va defini ceea ce afacerea este dispusă să cheltuiască pentru asta, iar apoi din nou, care poate defini care sunt imaginile pe care le voi arăta fie că aplic sau nu aplic.
Așadar, să începem cu cea mai de bază soluție de pseudo-înaltă disponibilitate. Aceasta nu este o disponibilitate ridicată, dar îmi place să încep cu asta, deoarece îi face pe oameni să gândească așa cum trebuie. Dacă am un server și un tablou de stocare, de obicei voi pune mai multe NIC-uri, carduri de interfață de rețea în serverul respectiv și le voi lega astfel încât dacă un NIC nu reușește, rămân în continuare. Și voi face același lucru cu adaptoarele autobuzului meu gazdă, le voi face pe mai multe căi prin diferite comutatoare, astfel încât să am mai multe modalități de a ajunge la stocarea mea. Și am o sursă de alimentare universală și am controlere repetitive în tabloul meu de stocare și poate am făcut ceva de genul RAID 10 cu discurile mele. Cu alte cuvinte, în această imagine am prevenit eșecul cu o singură componentă la mai multe niveluri. Deci, nu sunt legat de NIC, nici de HBA, nici de controler, nici de comutator.
Dar dacă observați, serverul este în roșu și tabloul de stocare este în roșu. Încă mai am două zone în care dacă nu reușesc, dacă serverul meu merge, sunt mort, dacă dulapul meu de stocare merge, sunt mort. Așadar, deși aceasta nu este o disponibilitate ridicată, vă începe să vedeți și să priviți imaginea și să spuneți: „Vreau o imagine în care să nu existe roșu”. Și acesta este într-adevăr obiectivul acestor imagini, acela de a ne orienta în direcția corectă.
Așadar, primul lucru care se întâmplă este ca DBA, aș dori întotdeauna să pun soluția cu disponibilitate ridicată ca o implementare a bazei de date, dar s-ar putea ca să fie disponibil ca să poată fi făcută ca soluție de stocare sau poate fi că ar putea fi o replicare la nivel de stocare. În stânga, am virtualizare de stocare. Ceea ce se întâmplă este că am RAID 0 în două dulapuri de stocare diferite pentru discurile mele, dar am RAID 1 pe cele două dulapuri de stocare diferite. Cu alte cuvinte, acum pot avea o eroare a dulapului de depozitare și nu sunt mort. Deci, este mai bine decât imaginea anterioară, deoarece în imaginea anterioară - amintiți-vă că am avut atât roșu pe server, cât și roșu pe tabloul de stocare - și acum am făcut o mică îmbunătățire, acum nu mai avem roșu la nivel de stocare, am folosit: virtualizarea stocării a rezolvat această problemă.
Acum, un alt mod în care ai putea să o faci - și nu toți furnizorii oferă acest lucru - este că s-ar putea să poți face replicarea la nivel de stocare. Nu vorbesc de replicarea bazei de date, vorbesc de fapt despre replicarea I / O de bloc pentru stocarea dvs. Și asta se poate face la nivel de stocare. Și încă o dată, acum am în partea dreaptă, o altă imagine în care scot roșul din partea de jos, pentru că folosesc replica de stocare.
Și deci, aceasta este o altă imagine care poate fi sau nu disponibilă. Iar persoana care ar gestiona acest lucru poate fi administratorul de stocare, mai degrabă decât administratorul bazei de date. Îmi place să aduc acest lucru, pentru că uneori oamenii se gândesc la „Oh! Disponibilitate ridicată, trebuie să fie DBA care să abordeze această problemă”. Nu este întotdeauna adevărat; în acest caz ar putea fi administratorul de stocare.
În continuare, putem face virtualizarea serverului ca o posibilă soluție. Acum, dacă vă amintiți, în prima imagine am avut roșu la server și roșu la matricea de stocare. Aș putea, în acest caz, folosind virtualizarea, s-ar putea să mă pot muta și, în unele cazuri, relocarea este un fel de relocare caldă, iar în unele cazuri poate fi chiar o relocare fierbinte. Unele virtualizări sau hipervizori oferă capacitatea de a muta o mașină virtuală în zbor. Și unele baze de date vor accepta această mișcare în zbor. Acum, din nou, nu toți hipervizorii furnizează acest lucru, dar acesta este un nivel posibil de soluție. Acum, am făcut ca serverele de top să nu mai fie roșii, dar am totuși tabloul de stocare partajat și ghicesc ce, această soluție poate fi un efort comun între administratorul bazei de date și administratorul de virtualizare. Sau ar putea fi chiar administratorul de virtualizare, în funcție de ce nivel de relocare este acceptat de hipervizorul respectiv și baza de date.
Dacă vă întrebați: „Uau, ce înseamnă el prin această relocare? Dă-mi un exemplu specific. ”De exemplu, în VM unde puteți utiliza VMotion pentru a muta mașina virtuală de la o gazdă la alta și face acest lucru fără timp de oprire. Acum, în mod clar, imaginea anterioară avea încă ceva roșu. Încă am avut stocarea ca fiind un singur punct de eșec. Și, astfel, trecem la următoarea soluție care este, bine, permiteți-mi să combin stocarea și virtualizarea serverului.
Acum, în acest caz, din nou, ar putea fi administratorul de stocare și administratorul de virtualizare care construiesc această soluție și uite acum: am o imagine fără roșu în ea. Am disponibilitate ridicată, deoarece pot reloca mașina virtuală sau aplicația sau baza de date rulând de la un server la altul și am virtualizare în tabloul meu de stocare, făcându-l să facă RAID 1 pe două tablouri de stocare separate. Am multiplicat întrerupătoarele și HBA-urile mele.
Așadar, acum am construit un sistem HA și l-am realizat în primul rând nu la nivelul bazei de date. Cu alte cuvinte, am folosit alte tehnologii pentru a realiza același lucru. Deci, aceasta este o soluție. Apoi vom intra în ceea ce se numește clusterul scalabil de stocare partajată. Chiar nu este o soluție HA, dar, din nou, îmi place să o arăt pentru imagine.
Și ceea ce se întâmplă aici este că avem două servere care rulează o bază de date și este considerată a fi o singură bază de date. Nu este vorba de două baze de date separate; nu este ca un stăpân și un sclav, sau o căldură și o rece, sau un activ și un standby. Aceasta este, ambele noduri colaborează pentru a prezenta o bază de date logică. Și deci, ceea ce se întâmplă este că, dacă un anumit nod eșuează, sunteți încă în pas. Așadar, vă protejează de eșecul la nivel de server și face asta, practic, împărțind resursele nodului, dacă doriți, dar mai aveți un singur punct de eșec în partea de jos a discului. Și deci, acesta este un cluster scalabil cu stocare partajată și Oracle numește acest Real Application Cluster sau RAC.
Acum, o altă soluție este să folosiți un cluster de failover de stocare partajată. Deci, în stânga am un nod activ, în dreapta am un nod pasiv, am băgat o inimă între ele. Am un tablou de stocare partajat și acest lucru este esențial; trebuie să ai asta. Și practic, ceea ce se întâmplă este dacă nodul activ întâmpină probleme, nodul pasiv poate prelua controlul. Există probleme de autorizare în acest sens. Unii furnizori de baze de date vă permit să aveți nodul pasiv cu o licență redusă pentru o perioadă determinată. În alte cazuri, trebuie să aveți licențe duplicate complete. Totul depinde de furnizorul dumneavoastră de baze de date. Dar toate susțin acest tip de imagine care este, dacă un nod coboară, celălalt nod poate prelua.
Și, de obicei, acesta este unul dintre acele scenarii în care este un fel, atunci când treceți de la nodul activ la nodul pasiv, veți merge probabil, în majoritatea bazelor de date - nu toate - veți pierde o parte din tranzacții de zbor. Apoi vom intra în ceea ce poate privi cu adevărat administratorul bazei de date, care este replicarea bazei de date și există două moduri diferite de a face replicarea bazei de date.
Există replicare fizică, iar ceea ce este important este, în mijlocul acestei imagini, puteți vedea cu steaua verde, că replicarea, este realizată de baza de date, dar, la fel ca virtualizarea la nivel de stocare, se face la bloc. nivel. Deci, repetăm I / O-urile efective ale blocului de la nodul activ la nodul numai de citire sau pasiv. Și aceasta este considerată replicare fizică.
Acum, hai să trec la diapozitivul următor, deoarece este aproape identic și este replicare logică și singurul lucru care se schimbă în poză este că la mijloc, în loc să trimitem blocul I / O, în mod esențial trimitem peste jurnal fișiere cu comenzile SQL din el. Deci, cu alte cuvinte, ceea ce reproducem nu este I / O fizic, ci comenzile care provoacă I / O fizice.
Și deci, acest lucru este adesea numit transport de jurnal sau replicare bazată pe jurnal. Unii furnizori de baze de date vă oferă acest lucru în mod nativ. Este posibil ca alți furnizori de baze de date să nu ofere acest lucru, dar atunci furnizorii terți îl oferă, deci este o soluție HA foarte populară și este considerată o soluție completă. Dar această soluție este în primul rând responsabilitatea DBA.
Deci, nu folosesc virtualizarea pentru a realiza acest lucru. Aș putea, dar nu sunt dependentă de asta. Și nu folosesc virtualizarea de stocare. Din nou, aș putea, dar nu sunt dependentă de ea. Dar construiesc o soluție, baza de date fiind caracteristica principală de conducere. Deci, aceasta este replicarea logică.
Acum, este de asemenea posibil să combinați virtualizarea bazei de date și stocarea. Aș putea avea, în centrul meu de date, să zicem, pe stânga, în albastru, aș putea virtualiza stocarea, astfel încât să nu fiu legat de un anumit tablou de stocare. Dar s-ar putea să fac o replicare logică sau bazată pe baza de date logică de la un centru de date la altul, astfel încât comenzile să fie executate și în centrul de date, rezultând I / O, dar nu neapărat același I / O, pentru că I ' Nu trimit I / O bloc, nici prin soluția de stocare, nici prin baza de date, dar trimit jurnalele și, prin urmare, comenzile SQL.
Și deci, aceasta este o imagine care este o imagine foarte obișnuită pentru organizațiile foarte mari. Și îmi place această imagine aici, pentru că dacă trebuie să o stabilesc pe premisa folosind o bază de date precum Oracle, o pot face; este o cantitate corectă de muncă, este destul de complex, există o mulțime de piese în mișcare. Dacă fac acest lucru în cloud, pot spune literalmente, caseta de selectare, vreau două regiuni geografice, vreau regiunile separate prin, știți, pe diferite continente, vreau virtualizarea la nivel de stocare într-o anumită regiune geografică. Pot spune chiar că vreau abilitatea de a face alocare de tip virtualizare sau definiție cu disponibilitate ridicată și, din nou, este o altă casetă de selectare.
Și celălalt lucru care îmi place în cloud, există o altă casetă de selectare care spune adesea: „Nu vreau să mă ocup de patch-uri, ci doar de patch-uri”, știi, pur și simplu lucrează-l în fluxul de lucru al tuturor celorlalte lucruri pe care le faci în spatele scenele, ține-mă tot timpul patat. Și așa, în timp ce unele dintre aceste imagini devin foarte complexe și s-ar putea să fie foarte greu de făcut în premisă, de fapt devin destul de ușor de făcut în cloud.
Acum, lucru interesant este că este ușor să bifați toate casetele de selectare, dar ghiciți ce, asta costă mai mulți bani lunar. Deoarece dacă executați două centre de date, știți, aveți două centre de date în cloud pe care le utilizați, veți plăti mai mult decât dacă folosiți unul singur. De asemenea, dacă faceți din nou nivelul de stocare sau disponibilitatea ridicată a virtualizării ca strat suplimentar, pot exista costuri suplimentare.
Așadar, este interesant că, deși este greu de făcut pe site și este posibil să îl răstoarne, în cloud este atât de ușor de făcut, să-l crezi. Așadar, știi întotdeauna cum arată imaginea și știi întotdeauna care sunt ramificările de costuri pentru orice imagine pe care o creezi. Acum, există mult mai multe combinații decât ceea ce am arătat aici. Acesta nu este un exemplu complet sau exhaustiv. Există tehnologii noi la intervale regulate, așa că cine știe - poate nu am arătat una care tocmai a apărut în ultimele trei luni. Iar disponibilitatea ridicată este mult mai comună decât era acum zece ani.
De fapt, nu aș considera o întindere să spun că pentru majoritatea organizațiilor mari este o cerință de afaceri obligatorie în aceste zile. Și îmi place să mă întorc la acest tobogan pentru că am spus doar că este o cerință obligatorie pentru afaceri. Și am aceste două tabele în dreapta. Cea superioară este din documentația SQL Server, iar cea inferioară este din documentația Oracle. Și care sunt acestea, acestea sunt tabele care vă vor ajuta să alegeți, ce metodă de replicare ar trebui să utilizați.
Și observați că începeți cu câteva întrebări foarte simple. Câte date am voie să folosesc? Și dacă răspunsul este zero, știi că nu poți, în acel grafic de sus, să alegi primul sau al patrulea rând. Apoi puneți o altă întrebare. Ei bine, cât timp am voie să iau recuperarea? Și dacă cineva spune, bine, secunde sau minute, atunci asta face alegeri pentru tine. Și atunci, este necesar ca failover-ul să fie automat sau este necesar ca cineva să-l facă manual? Și asta este o altă întrebare de afaceri. Aceștia pot spune că o doresc automat, deoarece nu vor să se bazeze pe, o procedură de escaladare și apoi cineva care primește un bilet și apoi rezolvă problema. Vor doar să fie rezolvate.
Toate acestea sunt întrebări de afaceri și sunt aceleași întrebări dacă mă duc jos și fac același lucru pentru Oracle. Și întreb, OK, ce fel de eșec îmi permit, ce fel de durată, ce pot pierde, care este procedura de recuperare? Acestea sunt toate opțiunile de afaceri, așa că, dacă afacerea îmi spune răspunsurile la trei sau patru întrebări, jobul meu este foarte ușor, vin doar aici, aleg care dintre aceste meciuri este cea mai apropiată și apoi o construiesc. Și amintiți-vă, în cloud, este posibil să fie doar câteva casete de selectare pentru a le implementa.
Și cu asta, asta mă duce la sfârșitul materialului meu și a timpului de a deschide acest lucru pentru întrebări.
Eric Kavanagh: Bine, Dez, poate tu mai întâi și apoi Robin?
Dez Blanchfield: Absolut. De fapt, probabil un pic nedrept pentru cei care nu sunt pe Twitter, dar am redat doar o poză cu un grafic pe care vreau să îl vizualizez în mintea tuturor și apoi am vrut să arunc întrebarea către învățatul nostru prieten la apel. Când mă gândesc la surse proprii sau open source în acest spațiu - despre care vorbim adesea, despre un fel de baze de date proprii, de genul lui Oracle și Microsoft și altele, versus open source - ajungeți la această provocare în care lumea proprietară vânzătorul de software de internet sau dezvoltatorul de software sau compania investește în organisme pentru a construi acea complexitate. Și deci, ajungeți la un scenariu în care cumpărați software și nu trebuie să investiți în multe persoane, deoarece cumpărați capacitatea încorporată și în sursă deschisă - nu plătiți software-ul sau este cost redus, să zicem, dar nu plătiți pentru software, dar trebuie să investiți în corpuri.
Și sunt dornic să vă gândesc la jongler, mai ales acum, când ne îndreptăm către modele de cloud unde puteți obține. Puteți accesa AWS sau Azure și Rackspace-ul dvs., oricare ar fi, și cumpărați ca un serviciu care vă oferă platforma bazei de date sau o puteți face prin codul sursă deschisă. Și despre ce tocmai am vorbit, despre ce este jonglerul dintre sursa proprie și open source și modul în care modelele de design despre care vorbești intră în vigoare și care sunt gândurile tale generale în acest subiect pe măsură ce înaintăm, în special în ceea ce privește furnizarea de disponibilitate?
Bert Scalzo: Unul dintre elementele mari în care mă ocup atunci când încerc să adresez această întrebare, mă întorc la client și îi întreb despre cerințele de performanță ale acestora. Și motivul pentru care fac asta este, am constatat - cel puțin din punct de vedere istoric și din propria experiență - că atunci când vine vorba de clienții care au un randament ridicat în replicarea lor, sunt aproape întotdeauna mai bine cu replicarea furnizată de baza de date. furnizor, datorită naturii că este mai inerent construit și se află la un nivel mai scăzut și, uneori, folosește mecanisme care nu sunt disponibile pentru lumea exterioară, chiar și într-o soluție open-source.
Și vă voi oferi un bun exemplu de caz pe care l-am avut. Am avut o companie bazată pe internet care folosea MySQL ca bază de date și se aflau pe o versiune veche a MySQL, cum ar fi Versiunea 4.0, iar replicarea dintre nodurile lor a fost factorul limitativ pentru cât de mari își puteau scala bazele de date. Și se uitau să cumpere o soluție terță parte, apoi se uitau: „Ei bine, poate putem folosi una dintre soluțiile open-source”. Și la ceea ce a scăzut cu adevărat a fost, tot ceea ce trebuiau să facă era să-și actualizeze MySQL la versiune, cred că a fost 5.5 la care am mers, deoarece diferența dintre cele două versiuni ale bazei de date era în versiunea 4.0 a replicării MySQL nu era filetată și în versiunea 5.0 a fost și aceasta a fost de fapt cea mai bună cale pentru ei.
Acum, ne-am uitat la celelalte alegeri, dar factorul decisiv a fost performanța și rămânerea cu soluția furnizorului de baze de date, iar actualizarea bazei de date a ajuns în realitate să fie cea mai bună soluție pentru a obține cea mai mare probabilitate de a obține performanța de care aveau nevoie pentru a merge împreună. disponibilitatea mai mare.
Dez Blanchfield: Da, asta oglindește propria mea gândire, ca să fiu sincer. Doar pentru dezvăluirea completă și nu voi intra în mărci, dar am venit dintr-un cadru de proprietate care lucrează pentru OEM și furnizori de software și IOC-uri în general, și asta a fost cu siguranță experiența mea și în același timp sunt foarte pro -open-source și sunt un contribuabil de cod pentru o grămadă de proiecte pe care nu le vom numi, dar sunt de acord cu tine în acest sens, dacă ești o organizație mare - să zicem că ești o bancă, sau orice ai putea fi - invariabil nu vrei să fii magazin IT. Știți, cum ar fi, de exemplu, dacă sunteți editor de ziare sau dacă sunteți un retailer, nu doriți să fiți un magazin IT care publică ziare, ci doriți să fiți un magazin de ziare care să folosească de fapt IT.
Și uite, investiția în capabilitățile proprii în care dezvoltatorii de software construiesc toată acea capabilitate, echilibrarea încărcării și așa mai departe, în instrument, face mult mai mult sens decât dacă ești, cum ar fi, o pornire dotcom sau ceva similar ca asta poate investi în corpurile umane. Unde vezi că merge asta?
Probabil ultima mea întrebare înainte de a-i preda dr. Robin Bloor, pentru că știu că ne ocupăm de scurt timp. Unde vedeți că acest lucru merge din punct de vedere al tendințelor? Deci, sunteți afară tot timpul, sunteți pe marginea sângerării a lucrurilor, vedeți că oamenii s-au așezat și au acordat atenție și s-au trezit la nevoia de a face din aceasta o parte comercială din zilele lor conversație de zi înapoi în sala de consiliu? Sau încă mai vedeți că este foarte mult ferma geek, techies-urile și glugarii care se gândesc la disponibilitate, deoarece le face să se trezească la ora patru dimineața, când ceva se deconectează?
Credeți că tendința se transformă acum în organizații de toate dimensiunile, nu la cele evidente, precum companiile aeriene și serviciile bancare și financiare, ci doar afacerile în general? Credeți că oamenii au ieșit cu adevărat din propunerea de valoare pentru a-și proteja mediile de baze de date și pentru a oferi o disponibilitate ridicată și pentru a investi în asta, sau credeți că mai avem o cale de urmat? Care este sensul general pe piață acolo?
Bert Scalzo: În momentul de față, cred că există încă un decalaj, dar nu este un gol, deoarece afacerea nu o cere, ci este un decalaj în nivelurile de comunicare dintre cele două părți ale gardului. Cu alte cuvinte, oamenii de afaceri spun foarte clar: „Aceste aplicații necesită o disponibilitate ridicată și au aceste cerințe specifice atunci când spunem disponibilitate ridicată.”
Și, într-un fel sau altul, mesajul acesta nu este clar în legătură cu oamenii tehnologici. Sau oamenii de tehnică se vor întoarce și vor spune: „Oh, bine, este complicat și te va costa mai mulți bani”, și asta, asta sau altul. Cred că ceea ce se va întâmpla este că va eroda în cele din urmă, deoarece, sincer, cu faptul că este, de exemplu, în cloud, doar verificând câteva căsuțe aici sau acolo pentru a spune: „Construiește-mi această structură tehnologică cu adevărat complexă”, există într-adevăr niciun motiv bun pentru oamenii de tehnologie să se întoarcă și să le spună oamenilor de afaceri: „Oh, este scump” sau, „Este greu de făcut”, sau asta sau asta, iar oamenii de afaceri încep să știe că acesta este fapt.
Și chiar am văzut în medii în care, știți, oamenii lor de IT vor veni și vor spune: „O, nu puteți avea ce doriți. Este prea scump. Și vor aduce o firmă de consultanță terță parte care va spune atunci: „Nu, nu este corect. Iată cum ai putea să o faci. Iată ce te va costa. ”Deci, cred că mai avem un pic de timp între nivelurile de comunicare între cele două părți înainte ca acest lucru să devină automat.
Dez Blanchfield: Da, asta a reflectat cu siguranță ceea ce am văzut aici în Australia și în Asia-Pacific. Sunt sigur că este un lucru global. Și asta este că mulți dintre factorii cheie de decizie din sala de consiliu în jos, toți șefii de activitate, sunt „mult mai pricepuți din punct de vedere tehnic - citesc blogurile, urmăresc webinarii, sunt web sunt conectate la diverse articole și podcast-uri și vor merge la evenimente, forumuri și întâlniri și acum știu opțiunile lor și știu că cloud este o opțiune.
Știu, de asemenea, că pot aduce această capacitate, așa cum ați spus, în interior, și așa cred că există această provocare interesantă acum, conversația care trebuie să aibă loc, care este practic ceea ce am făcut astăzi acolo unde oamenii, un fel de, începe să faci lucrurile pe plan intern și pur și simplu să rulezi prânzuri cu pungi maro și să ai o informație internă despre care este starea noastră actuală, care este starea noastră ideală, unde trebuie să ajungem? Și apoi, într-un fel, adună asta.
Am avut un mesaj privat pe care abia acum îl voi atinge rapid. Cineva a pus o întrebare: „Este realist că puteți obține disponibilitate de 100 la sută?” Și s-ar putea să mă puteți corecta aici, dar voi spune că da. Am construit o platformă pentru un transfer electronic de fonduri, gateway EFTPOS între platformele bancare rapide și terminalele EFTPOS. Am construit acest lucru la începutul anilor 2000. De fapt a fost online 100 la sută din timp timp de 17 ani. De fapt, a fost construit înainte de anii 2000, dar a mers în producție doar 2000/2001.
Așadar, cei 17 ani s-au desfășurat de la dezvoltare la testare și apoi a intrat în producție. În acei 17 ani, PC-urile cu costuri foarte scăzute în afara platformei, care utilizează un sistem de operare open-source, dar o bază de date proprie, au făcut schimb activ / pasiv la fiecare 90 de zile, fiind aplicate diferite brevete de design, cu replicarea discuri în fiecare server, replicarea datelor între serverele modelului, replicarea mai multor centre de date și întoarcerea din centrul de date A efectuând producția timp de 90 de zile și apoi întorcându-vă în centrul de date B și realizând producție.
Și pe măsură ce se răstoarnă, automat se plasează și se actualizează, la întrebarea pe care tocmai am primit-o în privat, da, este posibil, dar cu o investiție foarte mare în proiectul respectiv din punct de vedere al proiectării. Deci, infrastructura nu a fost chiar atât de costisitoare, dar proiectarea și testarea și implementarea au fost foarte scumpe pentru a obține asta. Așadar, nu a trebuit să cheltuim foarte mulți bani în hardware și infrastructură, dar am folosit instrumente foarte inteligente, în vremea în care cloud nu era nici măcar o monedă.
Deci, răspunsul este da, se poate face, cu atât mai mult acum cu cloud, întrucât tocmai am auzit asta, printr-un clic pe un buton puteți activa această capacitate. O să-i arunc asta lui Robin pentru că sunt sigură că are și întrebări. Dar îți mulțumesc foarte mult că ai răspuns la întrebările mele și mi-a plăcut foarte mult să aud mesajul tău astăzi. Complet la bord cu toate acestea, deoarece reflectă tot ceea ce am făcut în ultimii aproape 30 de ani.
Dr. Robin Bloor: Bine, bine, o voi ridica. Unul dintre aspectele care m-au fascinat în legătură cu prezentarea dvs. a fost numărul de opțiuni disponibile acum, care nu erau disponibile atunci când trebuia să mă lupt cu aceste lucruri. Mă interesează cine va proiecta aceste configurații sau cine, în zilele noastre, proiectează aceste configurații? Ceea ce se întâmpla, sau, lumea cu care sunt obișnuit, este că ar exista un sistem tranzacțional destul de greu și că te-ar interesa un nivel de disponibilitate ridicat, disponibilitate ridicată. Pentru că, știți, sistemul tranzacțional, ar fi scump dacă s-ar reduce în vreun fel. Și nu ați avea toate opțiunile pe care tocmai mi le-ați prezentat, dar într-un fel sau altul, puteți găsi o modalitate, prin replicare, în mare parte, de a crea un standby fierbinte care nu va face clic pe neobservat, dar te-ar oferi un serviciu degradat până te vei întoarce.
Și eu sunt, cam generos, uitându-mă la ceea ce îmi arătați și mă gândesc la asta, nu am făcut nicio lucrare de proiectare de 15 ani, cine lucrează acum? Este, așa cum a fost în zilele mele, ceva ce ai făcut la începutul unui proiect, știi, să funcționezi infrastructura? Sau este ceva care este o activitate continuă în cadrul unei organizații? Deoarece există noi alegeri tehnologice care vin în paralel.
Bert Scalzo: În marile companii care sunt foarte eficiente și eficiente la toate operațiunile lor, inclusiv IT-ul lor, vor avea de obicei un grup de arhitectură centralizat sau vor avea un nume pentru asta, am auzit-o numit „ grup de arhitectură ”de multe ori. Și va fi responsabilitatea lor să știe toate aceste imagini diferite și care sunt pro și contra și care sunt costurile. Și ce se va întâmpla este atunci când o anumită aplicație se uită și spune: „Hei, trebuie să îndeplinesc cerințele de business X, Y și Z. Hei, echipa de arhitectură, care sunt alegerile mele?”
Acestea le vor da răspunsul, cum ar fi, aici sunt cele două sau trei care sunt disponibile, și apoi, la acel moment, decizia se mută din nou la nivelul inferior către echipa de aplicație sau către sponsorul de afaceri al aplicației. Însă, de obicei, există un grup centralizat care rămâne pe deasupra acestui lucru și are aceste informații gata și pre-construite.
Acum, este companiile mijlocii unde nu este atât de formală. Ceea ce va avea tendința de a se întâmpla este că veți primi unul sau doi dintre DBA-urile dvs. senior sau administratorii de sistem și vor fi informali în mod informal „expertul domeniului” pentru acest tip de expertiză. Deci, chiar și în companiile mijlocii se întâmplă, se întâmplă doar într-o structură neformalizată.
Dr. Robin Bloor: Este foarte interesant. Pe vremea mea, nu ne-am gândi niciodată la o disponibilitate ridicată, cu excepția sistemelor tranzacționale. Ei bine, în zilele noastre, desigur aveți sisteme de streaming care sunt supuse probabil unor cerințe și mai mari în ceea ce privește disponibilitatea. Dar, în interogare, back-end, analitică, depozit de date, tip de mediu DI, vezi vreodată cerințe pentru disponibilitate ridicată acolo?
Bert Scalzo: Da, și mă bucur că ai pus această întrebare. Am făcut unele lucrări pentru o firmă de vânzare cu amănuntul și deciziile lor strategice pentru afacere s-au bazat într-o mare parte din analiza pe care ar face-o din depozitul de date. Și, de fapt, au fost intervievați de Forbes Magazine, iar CEO-ul companiei a declarat: „Hei, prețul acțiunilor noastre a crescut cu 250 la sută în ultimii cinci ani, iar un motiv foarte mare, este adevărat, deoarece știm cum să ne folosim eficient datele în depozitul nostru de date. ”Au fost atât de buni în luarea deciziilor de afaceri încât, pentru ei, depozitul de date și a fi capabil să facă acele analize, să poată lua zilnic decizii în raport cu datele lor operaționale, a fost, de fapt, pentru ei, un sistem de producție.
Și vă voi oferi un bun exemplu despre cât de important este. Cu acest vânzător special de vânzare cu amănuntul, tipul care a fost responsabil pentru vânzările de bere, el a fost, ca și al treilea cel mai important executiv al companiei, pentru că a adus, știți, 60, 70% din venituri. Și așa, el trebuia să poată, pentru a rămâne competitiv pe piața respectivă, trebuia să știe în fiecare zi, știi, ce promoții ar trebui să organizez. Și asta s-ar putea baza pe, știți, nu doar perioada anului, ci, vremea, tiparele și alte date critice care pot afecta vânzarea a ceva precum berea.
Dr. Robin Bloor: Bănuiesc că trebuie să fie așa lucruri. Suntem puțin expirati, cred că ar trebui să îi transmit lui Eric în cazul în care va primi câteva întrebări din partea publicului. Eric?
Eric Kavanagh: Da, toate acestea au fost lucruri minunate, Bert. Cred că v-ați adresat toate întrebările pe care le-am avut de la public în prezentarea dvs. Dar este distractiv să urmărești. Mă bucur că ai discutat despre virtualizarea stocării și despre impactul care poate fi. Deci, toate sunt lucruri bune.
Ei bine, oameni buni, arhivăm toate aceste transmisii web pentru vizualizare ulterioară. Așadar, așteaptă online către Techopedia.com pentru a căuta secțiunea webcast. Toate acele tehnici Hot vor fi listate acolo. Mulțumim mult prietenului nostru Bert pentru expertiză. Și, desigur, lui Dez și Robin. Și cu asta o să vă luăm rămas bun, oameni buni. Ai grijă. Vom vorbi data viitoare. Pa! Pa.
