Per personal de Techopedia, 7 de desembre de 2016
Take away: l' amfitrió Eric Kavanagh discuteix la disponibilitat amb Robin Bloor, Dez Blanchfield i IDERA, Bert Scalzo.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Eric Kavanagh: Senyores i senyors, hola i benvinguts de nou. Són les quatre de l'horari de l'Est, un dimecres, i en aquests dies això pot significar una cosa si es troba en el món de les dades: torna a ser el moment de Hot Technologies. Sí, efectivament.
Em dic Eric Kavanagh, seré el vostre amfitrió per a la fira. Està dissenyat per descobrir el que fa calor, el que passa, les novetats que s’utilitzen a l’empresa i, per descomptat, el que fonamenta tot el que fem en tot aquest camp és la base de dades. Així que parlarem sobre la protecció de la vostra base de dades. El tema exacte és: “Protegir la vostra base de dades: alta disponibilitat per a dades d’alta demanda”. Així doncs, hi ha una diapositiva sobre la vostra. I, prou amb mi, colpeja-me a Twitter, @eric_kavanagh.
En primer lloc, aquest any és calorós, les dades són calentes, les dades grans són molt calentes, però encara són una mica avantatjoses. Actualment, moltes de les empreses d’avantguarda estan aprofitant les grans dades, la majoria d’organitzacions de pa i mantega existents al món, encara estan utilitzant dades tradicionals, i si les vostres dades tenen una gran demanda, aleshores voleu assegurar-vos que estan disponibles perquè quan els sistemes disminueixen, quan les dades són inaccessibles, és quan aconsegueixen clients infeliços, perspectives infeliços, obté una reducció de clients, obtindreu tot tipus de coses, companys, etc. Així que no ho desitgeu.
Anem a aprendre d’alguns dels millors avui en dia del negoci: sentirem conèixer el nostre propi doctor Robin Bloor, expert en bases de dades d’unes tres dècades en marxa. Dez Blanchfield, que fa tant de temps que ho va fer, però va començar quan era molt jove, i Bert Scalzo de l'IDERA, que és realment el cinturó negre de la base de dades. Així que no us detingueu, amics, feu preguntes: la gran part d’aquest esdeveniment és molt útil per a vostès quan feu preguntes bones i obteniu bones respostes, així que envieu-les a la finestra de xat o al component Q i A de la vostra consola.
I amb això vaig a lliurar-ho a Robin Bloor.
Robin Bloor: D' acord, deixa'm fer clic i mira si es mou. No vaig a parlar especialment sobre la base de dades. Vaig pensar que, ja ho sabeu, perquè faig la presentació de la presentació de la primera introducció, així que parlaré sobre els nivells de servei esperats i, per descomptat, sobre la disponibilitat, que és l’oferta, que és el tema del programa d’avui.
I la pregunta és: “De debò, què és la disponibilitat? I què és el paper de la manera en què la gent gestiona els centres de dades avui en dia? ”Una cosa que vaig notar, això ho vaig notar en algun moment a la dècada dels 90 - estava treballant en un lloc i els usuaris es van començar a queixar perquè el seu correu electrònic baixava per. 15 minuts.
I va ser interessant, ja que el CTO o qualsevol responsable del TI, en realitat, un dels pocs llocs en què en aquells dies havien determinat els nivells de servei i el missatge de correu electrònic baixat de 15 minuts, no violava el nivell de servei de ningú. . Crec que es pot deixar dues hores fora, de fet. No es va poder utilitzar el correu electrònic, sinó que no es podia enviar i rebre perquè el servidor estava fora. I aquest tipus em va alertar del fet que he notat avançar des d’aleshores, que tot simplement s’accelera i també ho fan les expectatives dels usuaris, i això et porta a la situació en què la gent pot tenir tres nivells de servei, però sovint es començarà a queixar quan no es vulneren els nivells de servei.
Així doncs, la definició dels nivells de servei, per donar-los bé, pot dependre exactament del que parleu en termes de nivells de servei. Hem parlat del sistema informàtic o de l’aplicació informàtica. Normalment definiu en termes de rendiment, disponibilitat i mètrica; és a dir, que realment no es pot definir un nivell de servei a menys que es pugui mesurar, de manera que normalment hi ha algun tipus de mesurament i normalment es tracta de temps de resposta, transaccions particulars i la disponibilitat dels sistemes durant un període de temps determinat, i abans de 1994-1995, era realment rar que els sistemes estiguessin disponibles per a més de les hores laborals habituals. Per tant, diguem-ne les vuit del matí fins a les sis del vespre, per donar un interval normal - i la gent construïa sistemes i així, i això significava que, al meu cap, particularment amb la base de dades, podríeu configurar la base de dades d'una manera determinada i la finestra del lot va començar a disminuir, la necessitat de pensar de nou va començar a sorgir en alguns sistemes i després en altres sistemes, i després vam arribar l’adveniment del servei o l’arquitectura, que va començar a dependre entre sistemes que abans no havien estat dependents. mútuament, empitjorar tot. Hem obtingut la compressió quant a la disponibilitat dels sistemes.
El punt que plantejava era quan parlava de disponibilitat, inclou còpia de seguretat i recuperació i inclou: és com si no es tracti només de disponibilitat en termes normals de què parlem; Hi ha moltes maneres diferents en què una aplicació pot fallar. Ja sabeu, podeu produir un fracàs del maquinari o bé que pugueu produir un error en la base de dades, podeu produir un error en el programari i hi ha un munt de diferents espècies, i quan es produeix, cal recuperar-vos i, per tant, també cal recuperar-lo instal·lar els sistemes Per tant, hi ha una especie de còpia de seguretat del sistema i, a més, en molts llocs actualment, necessiteu la capacitat de recuperació de desastres en cas que tot un edifici exploti. Alguna cosa que val la pena esmentar aquí, i vaig a aprofitar-ho en un minut, però els processos empresarials també tenen nivells de servei i, en realitat, els nivells de servei del procés empresarial que realment importen a l'empresa. TI només ha de fer la seva part i segons qualsevol acord.
Els nivells de servei informàtic normalment són subsidiaris als nivells de serveis de processos empresarials, però de la mateixa manera que feia quinze anys que alguna organització tingui nivells de servei ben definits, encara és rar que les organitzacions tinguin nivells de servei ben definits per a processos empresarials. . Això és una cosa que passa ara; no és una cosa que ha estat succeint des de fa temps.
Es tracta de les barreres d’acceleració i de temps, només cal destacar les barreres horàries. Passem a poc a poc a un món de processament d’esdeveniments i per això passem gradualment a un món en temps real i, a causa d’això, passem a la disponibilitat a ser requerit un 24 a 7, i això és difícil per a molts sistemes, és a dir. difícil d’aconseguir. O bé és molt car, o en alguns casos és possible que hagis de canviar els sistemes, fins i tot passar a una base de dades diferent, una versió diferent del programari de base de dades que estem utilitzant.
També aquestes barreres horàries –i sempre m’agradaria esmentar-les sempre que tinc oportunitat–, són barreres horàries a les quals s’apleguen les nostres aplicacions; les aplicacions podrien voler ser el més ràpid possible, és quan el programari parla amb programari. En algunes situacions realment no hi ha cap llicència acceptable, voleu ser el més ràpid possible i aquestes situacions en termes de negoci com situacions de mercat, en què la persona que ve amb la comanda de compra obté el seu preu pitjor que algú. qui arriba primer i, per tant, la velocitat del programari és realment important.
Però ja sabeu, per sota que quan realment esteu tractant -interactuant amb els éssers humans-, el millor temps de resposta que realment us pot demanar és una dècima de segon, perquè es tracta d’un temps de resposta d’un ésser humà. No cal que vagis més ràpidament perquè un ésser humà de totes maneres no ho notarà. Entre 1, 1 i quatre segons és un temps d’espera que els éssers humans toleraran normalment, però tan aviat com passis uns quatre segons, ja estan fent una altra cosa i, per tant, realment estàs en una activitat per lots.
Així, podeu veure que determinats marcs i dies, setmana i mesos per a aquelles coses que té un comportament per lots tenen un sentit i, per tant, no us trobeu en un món de processament d'esdeveniments i, per tant, la disponibilitat pot ser molt diferent pel que necessiteu. per poder proporcionar. Però tan aviat com en el món de l’esdeveniment, estareu en una disponibilitat de 24 hores / 7 i el canvi tecnològic és un factor ja que la tecnologia va més ràpid i més ràpidament, és possible que la disponibilitat no augmenti; només queda com és.
Es tracta de capes de complexitat i no vull aprofundir en això, és senzill, ja ho sabeu, tres coses a considerar aquí. Hi ha un nivell de servei d’infraestructures, aquest és l’eix vertical, i hi ha un nivell de servei de qualsevol aplicació donat, hi ha un nivell de servei empresarial, que depenen els uns dels altres i hauran de tenir en compte. si realment voleu crear un entorn sensible on es compleixin els nivells de servei, bàsicament.
A continuació, teniu a la part inferior aquí, que només són bases de dades representades, però podeu fer qualsevol cosa dins del sistema, ja sabeu que teniu la configuració sense parar, cosa que vol dir el que diu: mai no s’aturarà. Teniu la situació d’estàndard en calent, en què d’una manera o d’una altra hi ha diferents maneres d’aconseguir-ho, però d’una manera o d’una altra, si una base de dades falla, es canvia a un mode d’atenció en calent i hi ha molt poc retard. termes del temps, fins al punt que els usuaris probablement notarien, però no ho notarien gaire.
El mode d’espera càlid s’assembla més a la commutació de 20 minuts on tothom truca a la taula d’assistència i pica a la taula d’assistència mentre es canvia la base de dades a un mode d’espera. Aleshores, es produeix una situació de reinici quan pot trigar un període de temps molt llarg. Val la pena assenyalar que una determinada aplicació o qualsevol base de dades es pot trobar en qualsevol de les situacions depenent del que està passant i del nivell de servei requerit de l'aplicació.
A partir d’això, només vull fer un apunt sobre la corba de complexitat. La complexitat deriva de nodes i connexions, les dependències. Al món on vivim, el nombre de nodes i connexions implicades en qualsevol cosa continua creixent, de manera que esteu executant una corba expediential. Si podeu veure com la complexitat augmenta i la manera en què les dimensions del temps s’estan reduint, ja sabeu els nivells de disponibilitat, hi ha objectius de temps, és probable que es redueixin?
I l'evolució natural és, per tant, cap a una operació sense parar, que és, naturalment, la més cara (almenys segons la meva experiència), és la configuració més cara que podeu crear. D’una manera o altra, qualsevol organització que estigui pensant en això, realment, ha de pensar no només en el que està passant ara, sinó en el que passarà en el futur.
Potser l’últim punt que vull plantejar és que la gestió dels nivells de servei és una activitat continuada; no saps que tens un projecte, que ho fas i ja s'ha acabat. No ho és, perquè les coses continuen canviant. Dit això, passaré la pilota a Dez.
Dez Blanchfield: Gràcies Robin. M'encanta la vostra diapositiva d'obertura. Acabem de repetir, crec que es tracta de "Finding Nemo 2", la pel·lícula. Teníeu Nemo buscant la disponibilitat en forma de nou, que em va semblar bastant valent. Sempre un acte dur a seguir. Quan penso en el temps i la disponibilitat i l’alt rendiment, la primera imatge que em ve al cap, perquè vaig créixer a les Illes Salomó a prop dels volcans i l’equador, és un volcà en erupció al meu centre de dades; Hi ha aquesta imatge que sempre tinc en ment que això és el que podria succeir si alguna cosa es produeix. Aquesta és una imatge de la muntanya preciosa. Etna, que es troba al cantó nord-est de Sicília, que es troba al costat de Catània.
El meu enfocament és fer una conversa amb vosaltres i oferir-vos un parell de coses per emportar al mateix nivell que ho faig a la sala de juntes de forma regular des de les suites C i els caps de negoci per tal de mantenir una conversa. sobre què pot afectar la vostra organització des d’un sentit comercial o un sentit tècnic i els tipus d’enginyeria.
Hem de pensar i com, què ens enduim, i com abordar alguns dels reptes que parlem quan parlem d’alta disponibilitat i temps de funcionament, sobretot en matèria d’automatització i plataformes.
Aleshores, la pregunta que ens plantegem inicialment és, a què es refereix, en realitat, quan parlem de sistemes de bases de dades i de disponibilitat de plataformes de bases de dades? Què significa parlar realment del repte real de posar a l’abast alguna cosa d’algun nivell tal com va parlar Robin a l’acord de nivell de servei instal·lat de mapeig de què necessitem i volem?
Així, la realitat d'avui és que, i de fet, aquí hi ha algunes realitats punta al meu cap, avui en dia tot es basa efectivament en bases de dades. Hi ha molt pocs sistemes que es construeixen avui i es construeixen de tal manera que només s’emmagatzemen els fitxers o hi ha algun tipus de registre de fitxers plans; invariablement tot es basa en bases de dades. Com a resultat d'això, tenim aquesta necessitat de deixar de pensar en la disponibilitat per a les bases de dades, per als diferents sistemes i aplicacions i eines que en depenen i que confien en ells per oferir els serveis que estem buscant per lliurar, vendre o consumir . I tota la infraestructura que hi ha al seu voltant.
De fet, tant és així, quan es pensa en les grans interrupcions de les dades dels últims temps, en particular, els nadius digitals o els nadius, algunes de les empreses que han vingut com Uber i Airbnb, etc., i els PayPals una mica més antics. i l’eBay del món: l’escala i la mida d’aquestes organitzacions només és possible a causa de la moderna tecnologia de bases de dades i la moderna infraestructura del núvol. Sense això, sense la capacitat aportada, sens dubte no existirien. Imagina’t un escenari on només puguis arribar a eBay entre les 9:05 i les 9:25 perquè no estava disponible durant la resta del dia perquè intentava fer un iCloud o una còpia de seguretat o alguna cosa així, simplement no tindria treballat.
Així, i hi ha altres àrees clau per pensar en la nostra vida quotidiana, ja ho sabeu, com ara el comerç al detall i la banca, les finances i les companyies aèries, etc. Els grans grups industrials com la logística de l'aviació, el transport marítim, hi ha govern en general, hi ha seguretat nacional i policia, etc. Totes aquestes indústries, tots aquests segments de mercat, tots aquests grups, depenen del funcionament dels seus entorns.
Així doncs, tenint en compte això, també tenim l’altra advertència que hem de pensar, l’altra cosa per emportar-te en la qual vull deixar-vos pensar, i és que el nostre món és el que anomeno “sempre endavant”. Estem permanentment connectats i aquest tema el podreu escoltar regularment i vaig a repetir-lo i reiterar-lo. Ara tenim telèfons intel·ligents a les nostres mans tot el dia i cada dia. No les apaguem, les posem al costat del llit, les utilitzem sempre com a despertadors, les utilitzem com a càmeres i fem fotos, empenyen aquestes fotos cap al núvol.
Sempre estan en la mentalitat permanentment connectats. De fet, hi ha una moneda de frase que m’agrada fer servir, i és que ara vivim la generació de Fitbit, que és on ho mesurem tot, ho controlem tot, i s’ha de registrar. això anirà a algun lloc.
I també hi ha una altra frase amb la qual us deixaré, i és a dir, són les nou en algun lloc en tot moment. És un món 24/7/365 on vivim. La Terra gira constantment al voltant del Sol i, en algun moment, i el temps, cada hora del dia són les nou. I això vol dir que la gent s’aixeca del llit i intenta fer coses, comprar coses, instal·lar coses, etc.
Aleshores, a què es refereix quan parlem d’alta disponibilitat? Doncs sona realment fins que comenceu a submergir-vos en els detalls. Ja sabeu quan pensem en "d'acord, què significa alta disponibilitat?" Bé, la realitat és que no hi ha bala de plata. És un concepte força complex, com va relacionar Robin amb alguns dels temes que va mencionar, com ara mesurar la disponibilitat i els acords de nivell de servei. El mapem a coses com, jo tinc aquestes preguntes, és a temps? Ens preocupem per coses com el que anomenem cinc nou, que aprofundiré en un minut. Ens considerem què hi ha als nostres acords a nivell de servei? Per exemple, en els acords a nivell de servei, vull dir que hi ha retards, les sigles de tres lletres dels acords a nivell de servei s’han tornat cada cop més crítics.
A mesura que esteu passant per tot aquest procés de sub-premissa i autocomplexat per subcontractar a centres de dades de tercers i a serveis gestionats subcontractats, ara anem fins al núvol. I la realitat és quan parleu de núvol, simplement es tracta d’ordinadors d’altres persones. I això vol dir que no esteu executant la infraestructura, no esteu executant els sistemes i, invariablement, no esteu executant el núvol. Esteu fent infraestructures configurades com a plataforma, per la qual cosa és encara més important en el servei de força de vendes. Ara, per exemple, imagineu-vos vendes, ja sabeu que no toqueu cap infraestructura, només teniu accés a una interfície web.
Així, l’únic mecanisme que teniu en aquest món d’infraestructura del núvol i subcontractats de qualsevol forma per controlar els acords a nivell de servei, aquest és l’únic mecanisme que teniu, i si la gent no compleix la vostra instal·lació, ho suportarà. penalitzacions i una reducció de la quantitat de diners que els pagueu o simplement no els pagueu.
Així doncs, això torna a recordar tot aquest repte de, ja sabeu, com gestionem l’alta disponibilitat? Com gestionem el temps de disponibilitat si no es tracta de la vostra infraestructura, es tracta de SLA, per exemple. Si es tracta de la vostra infraestructura o fins i tot si es tracta d’una infraestructura d’altres persones com a punt de vista del disseny. Hem parlat de l'equilibri de càrregues amb la ciència model, és una patent de disseny de tolerància a errades?
Executeu actiu actiu o actiu en espera a les vostres arquitectures? Tens diversos servidors, múltiples plataformes d’emmagatzematge? Com funcionen aquestes plataformes d’emmagatzematge? Es reprodueixen, es miren? Feu servir RAID? Quin tipus de RAID s’executa per a emmagatzematge redundant? Executeu RAID a nivell de disc? Executeu una plataforma d'emmagatzematge d'objectes que es reprodueixi entre unitats de model i sistemes de model i unitats? És N més un per cada petit equipament d’infraestructura que teniu? N’afegiu un altre i es troba al mateix centre de dades o un altre centre de dades? Heu creat una patent de disseny que no compti per cap punt de venda únic?
Totes aquestes coses fonamentals, ara sonen com a conceptes senzills, però quan entreu en cadascuna d’aquestes coses són coses molt, molt detallades. Quan parlem de disponibilitat, sempre acabem parlant de nou. I què volem dir amb nou? Tots hem sentit a parlar d’aquests, però pensem en què volen dir per un minut i per què són importants.
Així doncs, parlem d’un nou, que és només el 90 per cent de la nostra disponibilitat. Sé que això sona molt alt. Així doncs, quan parlem de 24 a 7 per 365, si només ens fixem en un any, per exemple, quan parlem a les nou, que és el 90 per cent del temps, això permet trenta-sis dies i mig d’aturada a l’any. Comprovem això a poc més d’un mes.
Ara penseu en qualsevol negoci que tractem cada dia, ja sigui amb banca en línia, eBay, PayPal o plataformes de xarxes socials com LinkedIn, Twitter o simplement un minorista general, diguem-ne només que volia reservar un vol per venir als EUA des de sol. Austràlia, estaria contenta si hagués volgut venir a Amèrica d’aquí a unes setmanes, si la meva companyia aèria preferida baixava durant trenta sis dies i mig perquè el seu proveïdor de serveis va dir: “Mira, estem a punt del 90 per cent del temps. "? Per descomptat, no ho faria.
A mesura que pugeu aquest model, dos nou: el 99 per cent. Doncs això es converteix en 3, 65 dies, aproximadament tres dies i mig d’aturada a l’any. És un gran problema? Bé, si teniu un servei de Black Friday i publiqueu una venda especial i la gent només pot comprar durant un parell de dies.
Tres nou són fins a 8, 7 hores a l'any, però fins i tot 8, 7 hores a l'any, això és, sense parar vuit hores del nostre temps. Bé, a la banca i les finances, a la salut, si és un hospital, bé, això podria costar la vida. A mesura que puges, quatre neu són 52 minuts, cinc nou són cinc minuts i sis nou bàsicament 30 segons. Sis nou és extremadament alt i, a mesura que puges per aquesta escala, a mesura que puges per aquest arbre de Nadal de nou, més pujades de nou, més difícil és el disseny, el medi ambient i la plataforma. Com més difícil és lliurar aquest servei i si pensem en la reducció del temps que necessiteu per executar còpies de seguretat, administració, pegats, finestres de manteniment per qualsevol tipus d’interrupció, tots els reptes no trivials I tot això es redueix als percentatges d’interrupcions, de manera eficaç.
La clau aquí que voldria transmetre és que no hi ha cap bala de plata, com he comentat abans. Quan es tracta de disponibilitat, no hi ha cap "mida única". Pot ser que tingueu un tipus particular de patent que s'adapti a les indústries clau. Tots els bancs afronten els mateixos reptes. Alguns poden ser bancs minoristes, altres podrien ser bancs premium. Alguns bancs es podrien centrar en el comerç i la inversió, la gestió de riquesa. Alguns poden ser purament consumidors. Alguns només podrien estar col·locant-se a Internet i ni tan sols tenir distribuïdors i només tracten amb caixers automàtics quan es reparteixen efectiu. Així, en aquests escenaris, fins i tot en la indústria bancària i en la gestió de la riquesa i la indústria dels serveis financers, en general, per a cadascun d'ells encara tenen el seu propi sabor o allò que necessiten quan es tracta de disponibilitat.
Així doncs, quan pensem en la disponibilitat en anglès, la barreja entre disponibilitat i alta disponibilitat, pensem que són el mateix, però en realitat són guixos i formatge. La disponibilitat és, l'he posat en anglès, una mesura del temps que un servidor o procés funciona normalment o generalment relacionat amb el seu ús. Això només vol dir com descrivim si està disponible o no. Quan parlem de disponibilitat solem caure en aquest parany de pensar, "ho proporciono en una forma disponible", versus una alta disponibilitat per protegir la seguretat d'aquesta infraestructura.
L’alta disponibilitat, en un altre sentit en anglès normal, és el disseny en què s’implementa o s’aconsegueix algun tipus de resultat i disponibilitat de dades en particular, on gairebé tot el temps –24/7/365 dies a l’any - que la disponibilitat arriba a alguns d’aquests nou. Invariablement, no vol dir el 100 per cent. Tècnicament no és possible el cent per cent en un món real en cap entorn. És molt difícil que un servidor en un sistema operatiu tingui una base de dades en ell, amb una plataforma en funcionament i que una aplicació la pugueu lliurar i espereu que funcioni al 100%. Aleshores comencem a pensar en dissenys. Tenim redundàncies, hem de reproduir diverses diapositives? Aleshores, quan el poseu en anglès, és interessant el diferent que és el tema de la disponibilitat versus la disponibilitat alta.
Vaig pensar que la posaria en una forma gràfica senzilla i senzilla només per fer-nos una idea del que sembla quan comenceu a plantejar-vos el repte d’augmentar la disponibilitat per protegir el vostre servei de servei. A la part inferior esquerra tenim un nou. He exposat els cinc nou dels que parlem generalment. Sis nou és una mica indignant. Quan parlem de cinc nou a la cantonada inferior esquerra, fa 35 dies aproximadament, és un entorn de baix cost i de complexitat baixa, perquè intenteu proporcionar-ho perquè teniu diverses coses que poden fallar i podeu fer-ho. encara compliu els vostres acords sobre el nivell de servei.
Però a mesura que aneu per la part inferior d’esquerra a dreta i arribeu al punt on hi ha més nou a la imatge, aconsegueixen els escenaris en què comenceu a pensar en la replicació de sistemes i plataformes. Cal pensar en el clúster i la virtualització de diverses parts de la infraestructura. Heu de pensar en la geolocalització d’aquells clústers, en diversos llocs de centres de dades i heu de pensar en el tipus d’indústria i segment de mercat que us dirigiu. Aleshores, quin tipus de servei heu de complir? Quina prestació de serveis estàs buscant? Àrees que són serveis basats en targetes en temps real que informen de les comunicacions. Es tracta de serveis militars? Així doncs, aquest gràfic va de baix a esquerra a la dreta a la dreta i a mesura que es supera aquesta corba augmenta el cost i la complexitat. A mesura que obteniu entorns més complexos i més exigents, necessitareu més nou.
Aquest gràfic, per exemple, fa una cosa molt similar: descriu la història entre el component de cost versus el component de disponibilitat desitjat. Així doncs, a la part superior esquerra cartografiem els sistemes complexos altament disponibles i el cost que es produeixi si aquesta disponibilitat baixa respecte al benefici de tenir disponibilitat en temps morts zero. Així, per exemple, si tenim un entorn a l’esquerra on les coses estan a la baixa, podem incórrer en pèrdues financeres. Tenim implicacions legals que poden tenir implicacions comercials a nivell d'estratègia comercial.
Suposo que hi ha tot tipus de problemes potencials, fins i tot de temes morals sobre tenir un servei. Si es tracta d’una indústria sanitària i comencen a pagar el cost d’una interrupció, l’impacte als clients, la reducció de la satisfacció del client, la productivitat del personal, la productivitat dels usuaris, etc. Aquestes coses tenen un impacte si pensem en dissenyar altament complexos i altament dependents., entorn altament arriscat on hi ha risc potencial d’aturada i per tant de pèrdua.
Al costat dret intentem orientar-nos a un escenari en què si invertim un cost elevat i planifiquem en disseny, invertim en una implementació intel·ligent. Invertim en proporcionar a les persones habilitats i recursos i hem tingut en compte un entorn operatiu i de maquinari i programari molt considerats per a la xarxa. Tenim alta disponibilitat, però suposa un cost elevat. Així, el pendent màgic oscil·lant de la posició òptima al centre on es creuen, on tenim un cost reduït lleugerament i una disponibilitat creixent que simplement fa malabarisme entre els nivells de nou i l’elevada disponibilitat que és de disponibilitat contínua i això és una Desafiament continuat per a què puguem assolir, quant a diners en què esteu disposats a invertir per aconseguir el nivell de servei que esteu buscant?
També tenim el tema sobre el qual no aprofundiré en el tema, però només vull que ho traieu i que hi penseu. La diferència entre el temps mitjà entre el fracàs del vostre disseny i el temps mitjà per recuperar-se. És a dir, invertiu en infraestructures de millor qualitat, disseny de millor qualitat, maquinari i programari de millor qualitat i personal i recursos qualificats de millor qualitat per enginyar coses i reduir el temps mitjà entre el fracàs, el temps mitjà que triga a trobar la pausa en contraposició. disminuir la inversió en infraestructures, en recursos i en disseny i en patents cegues, l’alta capacitat de recuperació? Dit d’una altra manera, si alguna cosa es trenca, n’hi ha moltes per connectar-la. Si algú té un ordinador portàtil i mor, en tens un de recanvi. Se’ls lliura i en 30 segons es inicien la sessió. Aquests extrems són molt diferents. La primera de les quals es dedica a l’enginyeria amb un elevat cost i una inversió elevada per evitar el fracàs, i la de la part inferior diu que “Vaig a acceptar que arribarà el fracàs, així que vaig a enginyar al respecte i estaré preparat per al fracàs. i es recupera ràpidament. ”
Com he comentat abans, on podria dir: "La meva disponibilitat no és la vostra disponibilitat". Així doncs, quan es tracta d’entorns de bases de dades i de suport a la infraestructura, d’executar la base de dades i de protegir-la i assegurar una alta disponibilitat, realment no hi ha cap punt únic . Cadascú té les seves necessitats i desitjos. Així que haureu de plantejar-vos aquestes preguntes fonamentals amb les quals us deixaré, i és a dir: què us pot permetre la vostra organització? No parlo només de dòlars i cèntims. Estic parlant, com a organització, de què es pot permetre els recursos, el temps i l'esforç, etc., fins al punt de disponibilitat? A més, què pot suportar la vostra empresa? Per tant, les capacitats actuals, les competències actuals, la infraestructura actual, el finançament actual que podeu obtenir. Per tant, fer un malestar entre el que realment es pot permetre i el que podeu suportar és un balanç interessant.
A més, haureu de fer-vos les preguntes: quines habilitats i tecnologia teniu a casa? Podeu subcontractar algun d'aquest repte? Podeu traslladar les coses al núvol? Si teniu el servei d’infraestructura a part del servei de programari, quedareu sense aquesta pila mentre aneu més amunt de la pila. Per tant, hauríeu d’invertir més en plataformes i serveis i no preocupar-vos per la peça d’infraestructura, o bé haureu de mirar el programari com una oferta de serveis perquè no us haureu de preocupar de la plataforma?
Quin tipus de mercat i de consumidor o client presta servei? Vull dir, si ets telecomunicatiu i algú ha de recollir el telèfon i tens un to de marca tot el temps, aquest és un repte molt diferent: obrir una petita botiga minorista entre dilluns i divendres, de nou a cinc i tancar un a l'hora de dinar com un barber de la botiga de racons. Així doncs, heu de pensar molt i molt bé com funciona i què significa això per a la vostra organització, què heu de poder proporcionar.
A continuació, feu el malabarisme entre el que hi ha a les instal·lacions, allò que s’allotja externament i potencialment, el que hi ha al núvol. Com he dit abans, això també prové de reptes del temps. Així doncs, ens queda aquesta pregunta final que espero que els nostres amics d’IDERA ens expliquin com s’aborden aquestes coses mateixes, i que és el bon malabarisme entre adaptar la vostra disponibilitat desitjada amb el rendiment i què necessita la vostra empresa i què. el vostre mercat i els vostres consumidors necessiten.
I la realitat és que no és cap proesa. Es necessitarà temps, esforços i diners a tota la taula per pensar en aquestes coses. I, invariablement, és inversió en persones i habilitats i inversió en programari i eines per automatitzar alguns d’aquests processos i proporcionar a aquestes persones les eines i sistemes adequats per fer la seva vida no només millor, sinó que és possible perquè supervisi entorns a gran escala i protegeixi i gestionar aquells entorns a gran escala és sovint més enllà de les capacitats humanes individuals.
Així, doncs, amb l'esperança, espero que hagi creat l'escena per a una gran conversa per als nostres amics de IDERA per parlar de la seva plataforma i eines, i espero esperar fer algunes bones preguntes al final. I passaré.
Robin Bloor: Bé. Bert, només us he donat les claus, traieu-les.
Bert Scalzo: Gràcies! Gràcies, Dez i Robin. Continuaré amb el tema de l’alta disponibilitat per a les vostres dades. I realment vaig a aprofitar molt del que Dez acaba de parlar. Per tant, les opcions, els nous, els compromisos, la rendibilitat. Vaig a intentar posar-ho més en termes de l'administrador de la base de dades o algú més proper a les trinxeres, com ho veurien? Com ho arquitectarien? I què signifiquen aquestes eleccions.
Ara, intentaré ser una base de dades agnòstica. No vaig a dibuixar, per exemple, una solució específica d'Oracle o específica del servidor SQL, però vaig a dibuixar, diguem-ne, una arquitectura genèrica que tots els venedors de bases de dades ofereixen. Tots ho diuen amb diferents noms, però és un tipus d’elecció que teniu en comú, i vull mirar-ho tant des de la perspectiva empresarial com de la tecnologia i com es relaciona amb els requisits del negoci.
I vull començar per la que la solució de base pseudo-alta disponibilitat més bàsica sigui a través de les opcions que teniu a les solucions a nivell d’emmagatzematge, a les solucions a nivell de virtualització, a les solucions a nivell de base de dades. Aleshores, vull presentar també el fet que totes les opcions també estiguin disponibles al núvol.
Així que, de nou, intentaré mantenir una base de dades bastant agnòstica. Ara, la majoria de les coses que parlaré, sé que existeixen a Oracle, SQL Server, MySQL, PostgreSQL. També hi ha venedors de tercers, que fabriquen eines que també us ofereixen arquitectures addicionals que podríeu considerar. I, com acabava de dir Dez, cap solució és la millor; tot depèn. Però hi ha un fet universal en el que anem a veure, hi haurà parts més mòbils, de manera que serà més complex i, per tant, més costós.
Així doncs, tots sabem que les dades són un actiu important. I tothom sap que l’accés ràpid a les dades sempre és bo. Però, un accés fiable a les dades és fonamental. I, mentre parlava amb els seus exemples nou, es pot permetre el luxe de tenir 36 dies i mig d’hora? És fonamental que les dades estiguin disponibles tot el temps. Així doncs, els temps d’aturada poden costar una fortuna, tant en termes d’ingressos perduts, però encara més importants, en clients perduts o en pèrdues de bona voluntat dels clients. Us posaré un bon exemple; si un lloc web particular on faig compres és lent, potser intentaré trobar un lloc web nou que ven articles similars a un cost similar que no tinguin llocs web lents. Per tant, no és només la pèrdua del client, sinó la bona voluntat que el client té envers vostè.
Ara, el maquinari és molt més barat en aquests dies, de manera que cada vegada hi ha més demanda d’alta disponibilitat. I de nou, em portaré al núvol quan ens fixem en això. I tenim ofertes de diversos nivells: els venedors d’emmagatzematge, els venedors de bases de dades, els venedors de virtualització i, fins i tot, els venedors de núvol. I, per tant, el que és realment interessant amb el núvol és després que dibuixi totes aquestes meravelloses imatges d’aquestes arquitectures que podríeu crear al núvol, moltes vegades només són algunes caselles de verificació que comproveu. I dius, "Vull la replicació a les regions geogràfiques". Casella de selecció. "Vull la replicació dels components clau del maquinari." Casella de selecció. I així, si enteneu les imatges, de vegades al núvol només cal que comproveu algunes caselles per crear la imatge que us queda al cap.
Ara, el més important és, quins són els requisits empresarials per tenir alta disponibilitat? Per exemple, només he de preocupar-me del fracàs en un sol lloc o he de tenir-lo a diversos llocs? És a dir, puc tenir un centre informàtic i no m'importa si aquest centre està fora de línia? No faig cap requisit empresarial que s'expandeixi a diversos llocs. És una qüestió empresarial. I és important saber com percep les respostes a aquesta pregunta, perquè normalment defineix el vostre pressupost.
Ara, també voleu veure el nivell de protecció contra fallides. Podria ser una fallada d’energia? Podria ser una falla component? Com si un NIC o un HBA vagin malament, un adaptador de bus host. És un disc dur que va malament? És una fallada del gabinet d’emmagatzematge? És una fallada informàtica? O, en alguns casos, és una fallada del lloc? Això és diferent que, en alguns casos, podeu tenir una fallada del lloc, ja que el lloc mateix està fora de línia. En un altre cas, pot ser que una part important del lloc estigui fora de línia, però des de la vostra perspectiva aquesta és la totalitat del lloc.
Aleshores, mentre estava parlant Dez, quina és l'expectativa del moment per reprendre les operacions? Aquesta és una qüestió empresarial. Si l’empresa diu que hauràs de poder continuar les operacions d’aquí a dos minuts, òbviament, això definirà algunes d’aquestes imatges que vaig a mostrar que funcionaran, i algunes d’elles no seran opcions que pot triar.
I una altra pregunta que es presenta en alta disponibilitat, però sovint la gent s'oblida de plantejar-se és: "Hola, negocis, si passa alguna cosa mentre estic enmig de processar una transacció, què em permet perdre en reprendre el sistema? " In other words, if I can bring the system back up in two minutes, and I can lose no more than 10 seconds of, let's say, transactions that were in flight, is that acceptable business? And again, that will define what the business is willing to spend for that, and then again, that may define which pictures that I'm going to show you either apply or don't apply.
So, let's start with the most basic pseudo-high-availability solution. This is really not high availability, but I like to start with this, because it gets people thinking the right way. If I've got a server and a storage array, typically I will put multiple NICs, network interface cards, in that server, and bond them so that if one NIC fails, I'm still up. And I'll do the same thing with my host bus adapters, I'll multi-path that through different switches, so that I have multiple ways to get to my storage. And I got a universal power supply, and I've got repetitive controllers inside my storage array, and maybe I've done something like RAID 10 with my discs. In other words, in this picture I've prevented single-component failure at multiple levels. So, I am not bound by the NIC, or the HBA, or the controller, or the switch.
But if you notice, the server is in red and the storage array is in red. I still have two areas where if they fail, if my server goes, I'm dead, if my storage array cabinet goes, I'm dead. So, while this is not really high availability, it starts you to seeing and looking at the picture and saying, "I want a picture where there is no red." And that's really the goal of these pictures, to get us pointed in the right direction.
So, the first thing to happen is, as a DBA, I might always want to put the high-availability solution as a database implementation, but it might be that it's available that it could be done as a storage solution, or it might be that it could be a storage-level replication. In case of the left, I've got storage virtualization. What's happening is I've got RAID 0 in two different storage cabinets for my discs, but I've got RAID 1 across the two different storage cabinets. In other words, I can actually now have a storage cabinet fail, and I'm not dead. So, it's better than the prior picture, because in the prior picture – remember we had both red on the server and red on the storage array – and now we made a small improvement, we now no longer have red at the storage level, we've used- storage virtualization solved that problem.
Now, another way you could do it – and not all vendors provide this – is that you may be able to do storage-level replication. I'm not talking database replication, I'm actually talking about replicating your block I/O for your storage. And that can be done at the storage level. And so again, now I have on the right-hand side, another picture where I remove the red from the bottom, because I'm using storage replication.
And so, this is another picture that may or may not be available. And the person who would manage this may be your storage administrator, rather than your database administrator. I like to bring this up, because sometimes people think of, "Oh! High availability, it must be the DBA that addresses this problem." That's not always true; it could in this case be the storage administrator.
Now next, we can do server virtualization as a possible solution. Now if you remember, in the first picture I had red at the server and red at the storage array. I could, in this case, using virtualization, I might be able to relocate, and in some cases that relocation is sort of a warm relocation, and in some cases can actually even be a hot relocation. Some virtualization or hypervisors provide the capability to move a virtual machine in flight. And some databases will accept that movement in flight readily. Now, again, not all hypervisors provide this, but this is one possible level of solution. Now, I've made the top servers are no longer red, but I still have the shared storage array and guess what, this solution may be a joint effort between the database administrator and the virtualization administrator. Or it could even be just the virtualization administrator, depending on what level of relocation is supported on that hypervisor and that database.
Si us pregunteu, "Wow, què vol dir amb aquest trasllat? Doneu-ne un exemple concret. ”Per exemple, a VM on podeu utilitzar VMotion per moure la vostra màquina virtual d’un host a un altre i fer-ho sense temps d’inici. Ara, és clar que la imatge anterior encara tenia una mica de color vermell. Encara tenia l'emmagatzematge com un únic punt de fracàs. I així passem a la següent solució que és, bé, permetre'm combinar l'emmagatzematge i la virtualització del servidor.
Ara, en aquest cas, de nou, podria ser l’administrador d’emmagatzematge i l’administrador de virtualització qui construeixi aquesta solució i ara miren: tinc una imatge sense cap vermell. Tinc una alta disponibilitat perquè puc traslladar la màquina virtual o l’aplicació en funcionament o la base de dades d’un servidor a un altre i tinc virtualització a la matriu d’emmagatzematge fent que faci RAID 1 en dues matrius d’emmagatzematge separades. He multiplicat els meus interruptors i HBA.
Així, ara he creat un sistema HA i ho he fet principalment no a nivell de base de dades. És a dir, he utilitzat altres tecnologies per a dur a terme el mateix. Per tant, aquesta és una solució. A continuació, ens endinsem en el que s’anomena clúster escalable d’emmagatzematge compartit. Realment no és una solució HA, però, de nou, m’agrada mostrar-ho per la imatge.
I el que passa aquí és que tenim dos servidors amb una base de dades i es considera que és una base de dades. No es tracta de dues bases de dades separades; no és com un amo i un esclau, un calor i un fred, o un actiu i un mode d'espera. És a dir, tots dos nodes treballen junts per presentar una base de dades lògica. I el que passa és que, si un node determinat falla, encara esteu a l’altura. Així doncs, et protegeix de la fallada a nivell del servidor i ho fa bàsicament, augmentant els recursos del node, si així ho vols, però encara tens el punt únic de fallada del disc en el fons. Per tant, es tracta d’un clúster escalable d’emmagatzematge compartit i Oracle anomena aquest Real Application Cluster o RAC.
Ara, una altra solució és utilitzar un clúster de failover d’emmagatzematge compartit. Així, a l’esquerra tinc un node actiu, a la dreta tinc un node passiu, tinc un batec del cor pel mig. Tinc un conjunt d’emmagatzematge compartit, i això és crític; cal tenir-ho. I, bàsicament, el que passa és si el node actiu troba problemes, el node passiu es pot fer càrrec. Hi ha problemes de llicència per a això. Alguns proveïdors de bases de dades permeten tenir un node passiu amb una llicència reduïda durant un temps determinat. En altres casos, heu de tenir una llicència duplicada completa. Tot depèn del venedor de bases de dades. Però tots donen suport a aquest tipus d’imatge que és, si un node baixa, l’altre node es pot fer càrrec.
I, normalment, aquest és un dels escenaris en què es tracta, quan passis del node actiu al node passiu, probablement, a la majoria de bases de dades, no totes, perdreu una part del transaccions de vols. A continuació, ens endinsem en el que realment pot mirar l’administrador de bases de dades, que és la replicació de bases de dades, i hi ha dues maneres diferents de fer la replicació de bases de dades.
Hi ha replicació física, i l’important és que, a la meitat d’aquesta imatge, es pot veure amb l’estrella verda, que la replicació, la fa la base de dades, però, com la virtualització a nivell d’emmagatzematge, es fa al bloc. nivell. Per tant, repetim les E / S del bloc real des del node actiu al node de només lectura o passiu. I es considera que és una replicació física.
Ara, deixeu-me anar a la diapositiva següent perquè és gairebé idèntica i és la replicació lògica i l’únic que canvia a la imatge és que al mig, en lloc d’enviar els E / S de bloc, enviem essencialment el registre fitxers amb les ordres SQL que hi ha. Per tant, és a dir, el que estem replicant no són les E / S físiques, sinó les ordres que provoquen les I / O físiques.
Aleshores, això s'anomena sovint enviament de registres o replicació basada en registres. Alguns proveïdors de bases de dades us ho donen de forma nativa. És possible que altres proveïdors de bases de dades no ho ofereixin, però els venedors de tercers ho ofereixen i, per tant, es tracta d’una solució HA molt popular i es considera una solució completa. Però aquesta solució és, principalment, responsabilitat de l’ABD.
Per tant, no estic utilitzant la virtualització per aconseguir-ho. Podria, però no en depeno. I no estic utilitzant virtualització d'emmagatzematge. Un cop més, podria, però no en depeno. Però estic construint una solució, ja que la base de dades és la característica principal de conducció. Per tant, es tracta d’una replicació lògica.
Ara, també és possible combinar base de dades i virtualització d'emmagatzematge. Podria tenir, al centre de dades, diguem-ne, a l’esquerra en blau, que podria virtualitzar l’emmagatzematge de manera que no estic lligat a una matriu d’emmagatzematge en concret. Però potser estic fent una replicació lògica basada en el registre de base de dades o lògica d’un centre de dades a l’altre de manera que les ordres s’executin també al centre de dades, donant lloc a E / S, però no necessàriament la mateixa E / S, perquè jo ” No envio els E / S del bloc, ni per la solució d'emmagatzematge ni per la base de dades, però envio els registres i, per tant, les ordres SQL.
Així doncs, aquesta és una imatge que és una imatge molt comuna per a organitzacions molt grans. I m'agrada aquesta imatge aquí perquè si haig de configurar aquesta premissa amb una base de dades com Oracle, puc fer-ho; és una bona quantitat de treball, és bastant complex, hi ha moltes parts mòbils. Si ho faig al núvol, només puc dir, casella de selecció, vull dues regions geogràfiques, vull les regions separades per, ja ho sabeu, a diferents continents, vull virtualització a nivell d'emmagatzematge en una regió geogràfica determinada. Fins i tot puc dir que vull la possibilitat de fer assignació de tipus de virtualització o definició d’alta disponibilitat i, de nou, és una altra casella de selecció.
I l’altra cosa que m’agrada al núvol, hi ha una altra casella de selecció sovint per dir: “No vull tractar el pegat, només pegar-ho”, ja ho sabeu, només cal treballar-ho al flux de treball de tot el que feu darrere. escenes, mantingueu-me pegat en tot moment. I així, mentre que algunes d’aquestes imatges són molt complexes i poden ser molt difícils de fer amb premissa, en realitat es fan força fàcils de fer al núvol.
Ara bé, l'interessant és que és fàcil comprovar totes les caselles de verificació, però suposo que, això costa més diners mensualment. Com que si teniu dos centres de dades, ja sabeu, teniu dos centres de dades al núvol que utilitzeu, pagareu més que si en utilitzéssiu un. De la mateixa manera, si feu un nivell d'emmagatzematge o una alta disponibilitat de virtualització com a capa addicional, pot ser que torni a haver-hi despeses addicionals.
Per tant, és interessant que, encara que sigui difícil de fer al lloc i pugueu anul·lar-lo, al núvol és tan fàcil de fer, podeu pensar-ho. Per tant, sempre sap què és la imatge i sempre sap quins són els costos per a la imatge que creeu. Ara, hi ha moltes més combinacions que les que vaig mostrar aquí. No és un exemple complet ni exhaustiu. Hi ha noves tecnologies a intervals regulars, així que qui ho sap, potser no he demostrat una que hagi aparegut en els darrers tres mesos. I l’alta disponibilitat és molt més habitual que la que hi havia fa deu anys.
De fet, no consideraria que sigui un estirament dir que per a la majoria de les organitzacions grans és un requisit empresarial obligatori en aquests dies. I m’agrada tornar a aquesta diapositiva perquè només he dit que és un requisit obligatori del negoci. I tinc aquestes dues taules a la dreta. La superior està fora de la documentació de SQL Server i la inferior, de la documentació Oracle. I què són, es tracta de taules que us ajudaran a triar, quin mètode de replicació heu d’utilitzar.
Tingueu en compte que comença amb algunes preguntes molt senzilles. Quantes dades tinc permès utilitzar? I si la resposta és zero, ja sabeu que només podeu, en aquest gràfic superior, escollir la primera o la quarta fila. Aleshores, fa una altra pregunta. Bé, quant de temps tinc permès recuperar-me? I si algú diu, bé, segons o minuts, això és decisiu per a tu. Aleshores, el procés de recuperació ha de ser automàtic o cal que algú ho faci manualment? I aquesta és una altra qüestió empresarial. Poden dir que ho volen automàtic perquè no volen confiar en un procediment d’escalada i que algú aconsegueixi assignar un bitllet i resoldre el problema. Només volen que s’arregli.
Aquestes són totes les preguntes comercials i són les mateixes preguntes si puc fer el mateix per a Oracle. I pregunto, d'acord, quina mena de fallades puc permetre, quin tipus de durada, què puc perdre, quin és el procediment de recuperació? Totes són opcions de negoci, així que si el negoci em diu les respostes a tres o quatre preguntes, la meva feina és realment senzilla, només vinc aquí, tinc la que més correspon a aquestes coincidències i després la creo. I recordeu, al núvol, potser només hi hagi algunes caselles de selecció per implementar-les.
I amb això, això em porta al final del meu material i al moment per obrir-ho per a preguntes.
Eric Kavanagh: D' acord, Dez, potser tu primer i després Robin?
Dez Blanchfield: Absolutament. De fet, probablement una mica injust per a aquells que no es troben a Twitter, però només acabo de tuitejar una imatge d’un gràfic que vull visualitzar en la ment de tothom i després volia fer arribar la pregunta al nostre aprenent amic a la trucada aquí. Quan penso en un codi de propietat o de codi obert en aquest espai, que sovint és el que parlem, tipus de bases de dades propietàries, com ara d’Oracle i Microsoft, etcètera versus el codi obert, acabes amb aquest repte en què el món propietari el venedor de programari d'internet o el desenvolupador de programari o l'empresa inverteix en els organismes per crear aquesta complexitat. Per tant, acabes amb un escenari on comprar el programari i no cal invertir en molta gent perquè està comprant. la capacitat integrada i en codi obert: no pagueu el programari o sigui de baix cost, diguem-ne, però no pagueu pel programari, però heu d’invertir en els organismes.
I tinc ganes de pensar en el malabarisme, sobretot ara que ens movem en models de núvol on es poden obtenir o. Podeu anar a AWS o Azure i al vostre Rackspace, qualsevol cosa, i comprar com a servei que proporciona la vostra plataforma de bases de dades, o ho podeu fer mitjançant codi obert. I de què acabem de parlar, de què es fa el malabarisme entre el codi de propietat i el de codi obert i com es fan efectius els patrons de disseny de què parleu i quins són els vostres pensaments generals al voltant d’aquest tema a mesura que avancem, sobretot pel que fa a la disponibilitat de disponibilitat?
Bert Scalzo: Un dels grans elements en què em trobo quan intento respondre aquesta pregunta, torno al client i els pregunto sobre els seus requisits de rendiment. I la raó per la qual ho faig és que he trobat –almenys històricament i en la meva pròpia experiència- que quan es tracta de clients que necessiten un gran rendiment a la seva replicació, gairebé sempre estic millor amb la replicació que proporciona la base de dades. venedor, per la naturalesa que està integrat més inherentment i està a un nivell inferior, i de vegades utilitza mecanismes que no estan disponibles per al món exterior, fins i tot en una solució de codi obert.
I et donaré un bon exemple d’un cas que vaig tenir. Vaig tenir una empresa basada en internet que utilitzava MySQL com a base de dades i que es trobava en una versió antiga de MySQL, com la versió 4.0, i la replicació entre els seus nodes va ser el factor limitant de la mida que podien escalar les seves bases de dades. I miraven de comprar una solució de tercers, van mirar: "Bé, potser podem utilitzar una de les solucions de codi obert". I el que realment es reduïa era, tot el que havien de fer era actualitzar el MySQL a la versió, crec que era el 5.5 al qual vam anar, perquè la diferència entre aquestes dues versions de la base de dades es trobava en la versió 4.0 de la replicació MySQL no era de fil i a la versió 5.0 era, i aquest era el millor camí per a ells.
Ara, vam analitzar les altres opcions, però el factor decisiu va ser el rendiment i mantenir-se amb la solució del venedor de bases de dades, i fer que l’actualització de la base de dades acabés sent la nostra millor solució per obtenir la màxima probabilitat d’aconseguir el rendiment que necessitaven. major disponibilitat.
Dez Blanchfield: Sí, això és el meu pensament, per ser sincer. Només per a la divulgació completa i no entraré en marques, sinó que he estat procedent d'un bagatge propi que treballa per a fabricants OEM i fabricants de programari i COI en general, i aquesta ha estat sens dubte la meva experiència i alhora sóc molt professional. -Open-source i sóc col·laborador del codi per a un munt de projectes que no anomenarem, però estic d’acord amb tu en què si ets una gran organització - diguem que ets un banc, o qualsevol cosa que puguis sigui, sempre no vol ser botiga d’informàtica. Ja sabeu, com, per exemple, si sou un editor de diaris o si sou un minorista, no voleu ser una botiga d’informàtica que publiqui diaris, sinó que voleu ser una botiga de diaris que, en realitat, només utilitza informàtica.
I així, invertir en les capacitats pròpies on els desenvolupadors de programari construeixen tota aquesta capacitat, l'equilibri de càrregues, etcètera, a l'eina, té un sentit molt més en relació amb si és, com ara, un inici de puntcom o alguna cosa així. així pot invertir en cossos humans. Cap a on veieu això?
Probablement sigui la meva última pregunta abans de lliurar-me al doctor Robin Bloor, perquè sé que passem poc temps. D'on veus això des d'un punt de vista de tendència? De manera que, esteu tot el temps allà fora, esteu al límit sagnant de les coses, veieu que la gent s'ha assegut i presta atenció i s'ha despertat de la necessitat de fer d'aquesta part una part comercial del seu dia a dia. conversa del dia a la sala de juntes? O encara el veieu sent molt més la granja friki, els techies i els sudaders pensant en la disponibilitat perquè els fa despertar a les quatre de la matinada quan alguna cosa està fora de línia?
Creus que actualment la tendència està evolucionant cap a organitzacions de totes les mides, no les evidents com les companyies aèries i la banca i les finances, sinó només les empreses en general? Creus que la gent ha sortit realment de la proposta de valor per protegir els seus entorns de bases de dades i proporcionar una alta disponibilitat i invertir en això, o creu que encara tenim un camí a seguir? Quin és el sentit general del mercat?
Bert Scalzo: Ara mateix, crec que encara hi ha un buit, però no és un desfasament perquè el negoci no ho demana, és un buit en els nivells de comunicació entre les dues cares de la tanca. És a dir, els empresaris diuen molt clarament: “Aquestes aplicacions requereixen alta disponibilitat i tenen aquests requisits específics quan diem alta disponibilitat”.
I, d'alguna i altra manera, aquest missatge no està fent arribar clarament als tècnics. O els tècnics tornaran a dir-te: “Ah, bé, això és complicat i et costarà més diners”, i això, això o un altre. Crec que el que passarà és que finalment es va esborrar perquè, sincerament, amb el fet de ser, per exemple, al núvol, només cal comprovar algunes caselles aquí o allà per dir: “Construeix-me aquesta estructura tecnològica realment complexa”. Realment no hi ha una bona raó perquè la gent tecnològica torni a dir als empresaris: "Ah, és car", o "És difícil de fer", o això o això, i els empresaris comencen a saber que això és el fet
I fins i tot he vist en entorns on, ja sabeu, els seus propis informàtics vindran a dir-me: “Ah, no podeu tenir el que vulgueu. És massa car ". I portaran una empresa de consultoria de tercers que dirà:" No, això no és correcte. A continuació us detallem com podríeu fer-ho. Heus aquí el que us costarà. ”Així que crec que encara tenim un temps de temps entre els nivells de comunicació entre ambdues parts abans que això es faci automàtic.
Dez Blanchfield: Sí, definitivament es va reflectir el que he vist aquí a Austràlia i a Àsia i del Pacífic. Estic segur que és una cosa global. I és que molts dels principals responsables de la decisió de la sala de juntes, tots els caps de negoci, són molt més tècnics: estan llegint els blocs, veuen webinars, són connectats a diversos articles i podcasts, que van a esdeveniments, fòrums i reunions de reunions, ja saben les seves opcions i saben que el núvol és una opció.
També saben que poden aportar aquesta capacitat, com heu dit, a casa, i per això crec que hi ha aquest repte tan interessant, que s'ha de produir la conversa, que és bàsicament el que hem fet avui, on les persones : comenceu a fer coses internament i feu servir dinars de bosses marrons i feu una informació interna sobre quin és el nostre estat actual, quin és el nostre estat ideal, a on hem d’arribar? I, a continuació, ho especifiqueu.
Vaig tenir un missatge privat al qual vaig a tocar ràpidament ara mateix. Algú va fer una pregunta: "És realista que puguis obtenir una disponibilitat del 100 per cent?" I és possible que em puguis corregir aquí, però vaig a dir que sí. He creat una plataforma per a una transferència electrònica de fons, passarel·la EFTPOS entre plataformes bancàries ràpides i els terminals EFTPOS. Vaig construir-ho a principis dels anys 2000. En realitat ha estat en línia el 100 per cent del temps durant 17 anys. De fet, va ser construït abans de la dècada de 2000, però va passar a la producció només aproximadament 2000/2001.
Així, els 17 anys han estat des del desenvolupament fins a la prova i després a la producció. En aquests 17 anys, ordinadors fora de la plataforma de productes molt baixos que utilitzen un sistema operatiu de codi obert, però base de dades propietària, han realitzat intercanvis actius / passius cada 90 dies, aplicant-se diferents patents de disseny, amb la replicació de discs de cada servidor, replicació de dades entre servidors de models, replicació de diversos centres de dades i llençament del centre de dades A fent producció durant 90 dies i després cap al centre de dades B i fent producció.
I, mentre gira, automàticament enganxa i actualitza, de manera que només em corresponen en privat, sí, és possible, però amb molta inversió en aquest projecte des del punt de vista del disseny. Per tant, la infraestructura no era tan costosa, però el disseny i les proves i la implementació eren molt costosos per aconseguir-ho. Per tant, no vam haver de gastar molts diners en maquinari i infraestructura, però vam utilitzar eines molt intel·ligents, aquell dia en què el núvol no era ni tan sols una moneda.
De manera que sí, la resposta sí, es pot fer, encara més ara amb núvol, ja que acabem de sentir això, amb el clic d’un botó podreu habilitar aquesta capacitat. Vaig a llançar això a Robin perquè estic segur que també té preguntes. Però moltes gràcies per respondre les meves preguntes i em va encantar escoltar avui el vostre missatge. Completament a bord amb tot això perquè reflecteix tot el que he estat fent durant els darrers 30 anys.
Robin Bloor: Bé, està bé, ho agafaré. Una de les coses que em va fascinar sobre la vostra presentació va ser el nombre d’opcions disponibles que ara no estaven disponibles quan solia lluitar amb aquestes coses. Estic interessat en qui va a dissenyar aquestes configuracions, o qui, avui dia, dissenya aquestes configuracions? El que solia passar o, el món amb què estic acostumat, és que hi hauria un sistema transaccional força pesat i que estigués interessat en tenir una alta disponibilitat, una alta disponibilitat. Perquè, ja sabeu, el sistema transaccional, seria car si baixés de cap manera. I no tindríeu totes les opcions que m’acabeu de presentar, però, d’una manera o d’una altra, podríeu trobar una manera, mitjançant la replicació majoritàriament, de crear un mode d’espera calent que no faria clic desapercebut, però li donaria un servei degradat fins que tornés.
I estic buscant el que em mostraves i pensant en això, sense haver fet cap treball d'aquest disseny durant 15 anys, qui fa aquesta feina ara? És, com va ser en el meu dia, alguna cosa que vau fer a l’inici d’un projecte, ja sabeu, que la infraestructura estigui en funcionament? O és que això és una activitat continuada dins d’una organització? Perquè hi ha noves opcions tecnològiques.
Bert Scalzo: En les grans empreses que són molt eficients i eficaços en totes les seves operacions, inclosa la seva informàtica, normalment tindran un grup d’arquitectura centralitzada, o bé tindran algun nom per això, l’he sentit anomenar “el grup d’arquitectura ”moltes vegades. I serà responsabilitat seva conèixer totes aquestes imatges diferents, quins són els avantatges i els contres i quins són els costos. I el que passarà és que quan una aplicació en concret estigui buscant i digui: "Hola, he de complir els requisits empresarials X, Y i Z. Ei, equip d'arquitectura, quines opcions són?"
Els donaran la resposta, com ara, aquí hi ha els dos o tres que hi ha disponibles i, en aquest moment, la decisió es trasllada al nivell inferior a l’equip de sol·licitud o al patrocinador empresarial de l’aplicació. Però normalment, hi ha un grup centralitzat que es queda al capdavall i té aquesta informació a punt i pre-construïda.
Ara, és a les empreses mitjanes on no és tan formal. El que tendirà a passar és que obtindràs un o dos dels teus principals administradors de sistemes o administradors del sistema i informaràran "l'expert de domini" per a aquest tipus d'expertesa. De manera que, fins i tot a les empreses mitjanes que succeeix, només passa en una estructura no formalitzada.
Robin Bloor: És realment interessant. En el meu dia, mai estaríem pensant en una alta disponibilitat, tret dels sistemes transaccionals. Bé, avui dia, per descomptat, teniu sistemes de streaming que probablement estiguin subjectes a exigències encara més grans en termes de disponibilitat. Però, en els processos d’anàlisi basats en consultes, back-end, analítics, magatzem de dades, tipus d’entorn de DI, hi veieu alguna vegada requisits d’alta disponibilitat?
Bert Scalzo: Sí, i estic contenta que hagis fet aquesta pregunta. Vaig fer alguna feina per a una empresa de venda al detall i les seves decisions estratègiques per al negoci es van basar en una gran part de l'anàlisi que farien del magatzem de dades. I, de fet, van ser entrevistats per la revista Forbes i el conseller delegat de l’empresa va dir: “Hola, el nostre preu de les accions va créixer un 250 per cent durant els últims cinc anys i una raó molt gran és cert perquè sabem aprofitar de manera efectiva les nostres dades. al nostre magatzem de dades. "Van ser tan bons a la hora de prendre decisions empresarials que, per a ells, el magatzem de dades i poder fer aquestes analítiques, poder prendre decisions diàriament en funció de les seves dades operatives, van ser, per a ells, " un sistema de producció.
I us donaré un bon exemple d’important. Amb aquest venedor minorista en particular, el tipus responsable de les vendes de cervesa, era, com el tercer executiu més important de la companyia, perquè va suposar, el 60, 70% dels ingressos, ja sabeu. I, per tant, havia de ser capaç de, per mantenir-se competitiu en aquell mercat, havia de ser capaç de saber cada dia, ja saps, quines promocions hauria d’estar en marxa. I en això es pot basar, ja no, només en l’època de l’any, sinó en el clima, els patrons i altres dades crítiques que poden afectar la venda d’alguna cosa com la cervesa.
Robin Bloor: Bé, suposo que hi hauria coses així. Estem fora de temps, crec que hauria de transmetre a Eric en cas que tingui preguntes del públic. Eric?
Eric Kavanagh: Sí, tot ha estat fantàstic, Bert. Crec que vau abordar totes les preguntes que vam tenir del públic en la vostra presentació. Però és divertit mirar. M'alegro que, de la mateixa manera, hàgiu parlat de virtualització d'emmagatzematge i l'impacte que pot tenir. Per tant, tot això és bo.
Bé, amics, arxivem tots aquests transmissions web per poder-los veure posteriorment. Per tant, espereu en línia a Techopedia.com per buscar la secció de transmissió web. Hi apareixeran totes aquelles tècniques calentes. Un gran agraïment al nostre amic Bert per la seva experiència. I per descomptat, a Dez i Robin. I amb això us acomiadarem, amics. Cuida't. En parlarem la propera vegada. Adeu.
