Autors: Techopedia Staff, 2016. gada 7. decembris
Takeaway: Uzņēmējs Ēriks Kavanagh apspriež pieejamību ar Robin Bloor, Dez Blanchfield un IDERA Bert Scalzo.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Ēriks Kavanagh: dāmas un kungi, sveiki un sveicināti vēlreiz. Trešdien ir pulksten četrs Austrumu laiks, un šīs dienas var nozīmēt tikai vienu lietu, ja atrodaties datu pasaulē: atkal ir laiks Hot Technologies! Jā, patiesi.
Mans vārds ir Ēriks Kavanaghs, es būšu jūsu šova vadītājs. Tas ir paredzēts, lai noskaidrotu, kas ir karsts, kas tur notiek, kas ir foršs sīkumi, kas tiek izmantoti uzņēmumā, un, protams, tieši visa pamatā, ko mēs darām šajā jomā, ir datu bāze. Tāpēc mēs runāsim par jūsu datu bāzes aizsardzību. Precīza tēma ir “Aizsargājiet savu datu bāzi: augsta pieejamība datiem ar lielu pieprasījumu”. Tātad, šeit ir slaids par jūsu patieso. Un, pietiekami par mani, piesaki mani Twitter, @eric_kavanagh.
Pirmkārt, šis gads ir karsts, dati ir karsts, lieli dati ir ļoti karsts, bet tas joprojām ir sava veida mala. Mūsdienās lielākajai daļai moderno uzņēmumu tiek piesaistīti lieli dati, vairums maizes un sviesta organizāciju pasaulē darbojas joprojām, un tie joprojām izmanto tradicionālos datus, un, ja jūsu dati ir ļoti pieprasīti, tad vēlaties nodrošināt, ka tie ir pieejami, jo kad sistēmas pasliktinās, kad dati nav pieejami, tas ir, kad jūs saņemat neapmierinātus klientus, neapmierinātus klientus, jūs saņemat klientu traumu, jūs saņemat nelaimīgu visa veida lietas, partnerus utt. Tātad jūs to nevēlaties.
Mēs mācīsimies no labākajiem šodien biznesā - dzirdēsim no mūsu pašu Dr. Robina Bloora, datu bāzes eksperta, kurš darbojas apmēram trīs desmit gadu laikā. Dezs Blanšfīlds, kurš to darīja apmēram tikpat ilgi, bet viņš sāka, kad viņš bija patiešām jauns, un Berts Scalzo no IDERA, kurš patiešām ir diezgan melna datu bāzes datu bāze. Tāpēc nekautrējieties, ļaudis, uzdodiet jautājumus - liela daļa no šī notikuma jums ir vērtīga, kad uzdodat labus jautājumus un saņemat labas atbildes, tāpēc sūtiet tos caur tērzēšanas logu vai konsoles Q un A sastāvdaļu.
Un līdz ar to es to nodošu Robinam Blooram - atņemiet to.
Dr Robin Bloor: Labi, ļaujiet man noklikšķināt uz šī un redzēt, ja tas pārvietojas - tas notiek. Par datu bāzēm īpaši nerunāšu. Es domāju, ka, jūs zināt, tāpēc, ka es rīkoju iepazīstināšanu ar pirmo ievadu, tāpēc runāšu par gaidāmajiem pakalpojumu līmeņiem un, protams, pieejamību, kas ir darījums, kas ir šodienas šova tēma.
Un jautājums ir, jūs zināt, “kas tiešām ir pieejamība? Un kāda loma tajā ir tam, ka mūsdienās cilvēki pārvalda datu centrus? ”Viena lieta, ko es pamanīju - es to pamanīju kādreiz 90. gados - es strādāju vienā vietnē un lietotāji sāka sūdzēties, jo viņu e-pasts nedarbojās 15 minūtes.
Un tas bija interesanti, jo CTO vai tam, kurš bija atbildīgs par IT, faktiski bija viena no nedaudzajām vietām, kur tajos laikos viņi faktiski bija noteikusi pakalpojumu līmeni un e-pasts nedarbojās 15 minūtes, un tas nevienam nepārkāpa pakalpojumu līmeni . Es domāju, ka faktiski ir atļauts būt ārpus divām stundām. Tas nebija tas, ka e-pastu nevar izmantot, bet tikai tas, ka jūs nevarējāt sūtīt un saņemt, jo serveris nebija pieejams. Un tas mani brīdināja par faktu, ka kopš tā laika esmu pamanījis virzību uz priekšu, ka viss tikai paātrinās un tāpat arī tiek sagaidītas lietotāju cerības, un tas noved jūs pie situācijas, kad cilvēkiem varētu būt trīs pakalpojumu līmeņi, bet bieži vien viņi sāks sūdzēties, kad pakalpojumu līmenis netiks faktiski pārkāpts.
Tātad pakalpojumu līmeņa definēšana, tikai lai sniegtu - labi, tas var būt tieši atkarīgs no tā, par ko jūs runājat pakalpojumu līmeņa ziņā. Mēs esam runājuši par IT sistēmu vai IT lietojumu. Parasti definējiet veiktspējas, pieejamības un metrikas izteiksmē - citiem vārdiem sakot, jūs nevarat īsti noteikt pakalpojuma līmeni, ja vien jūs to nevarat izmērīt, tāpēc parasti tiek veikts kaut kāds mērījums, un parasti tas attiecas uz reakcijas laikiem, konkrētiem darījumiem un sistēmu pieejamība noteiktā laika posmā, un pirms aptuveni 1994. – 1995. gada tiešām bija reti, kad jebkurai sistēmai bija jābūt pieejamai ilgāk par parasto darba laiku. Tātad, pieņemsim, ka astoņi no rīta līdz sešiem vakarā, lai sniegtu normālu atstarpi - un cilvēki būvēja sistēmas tieši tādā veidā, un tas, manuprāt, it īpaši ar datu bāzi, nozīmēja, ka jūs varat konfigurēt datu bāzi noteiktā veidā un kā pakešu logs sāka sarukt, dažās sistēmās un pēc tam citās sistēmās atkal radās vajadzība domāt no jauna, un tad mēs saņēmām pakalpojuma vai arhitektūras parādīšanos, kas sāka veidot atkarības starp sistēmām, kuras iepriekš nebija atkarīgas no viens otru, padarot visu vēl sliktāku. Mēs saņēmām izspiest sistēmu pieejamību.
Es uzsvēru, ka, runājot par pieejamību, tas ietver dublēšanu un atkopšanu, kā arī - tas ir tāpat kā tas, ka nav tikai pieejamība parastos apstākļos, par kuriem mēs runājam; ir daudz dažādu veidu, kā lietojumprogramma var neizdoties. Jūs zināt, jūs varat iegūt aparatūras kļūmi vai arī datubāzes kļūmi, varat iegūt programmatūras kļūmi un ir daudz dažādu lietu, un, kad tā notiek, jums jāspēj atgūties, tāpēc jums arī ir jāatgriežas uz augšu sistēmas. Tāpēc ir jābūt kādai sistēmas dublēšanas shēmai, un arī mūsdienās daudzās vietnēs jums ir nepieciešama avārijas seku novēršanas iespēja, ja visa ēka uzsprāgst. Un kaut kas šeit pieminēšanas vērts, un es par to runāšu minūtes laikā, taču biznesa procesiem ir arī pakalpojumu līmeņi, un faktiski - biznesa procesa pakalpojumu līmeņi, kas uzņēmumam tiešām ir svarīgi. IT vienkārši ir jādara sava daļa no tā un neatkarīgi no vienošanās.
IT pakalpojumu līmeņi parasti ir pakārtoti biznesa procesu pakalpojumu līmeņiem, bet tāpat kā pirms 15 gadiem tiešām diezgan reti bija, ka jebkurai organizācijai ir precīzi definēti pakalpojumu līmeņi, joprojām ir diezgan reti, ja organizācijām ir labi definēti biznesa procesu pakalpojumu līmeņi. . Tas ir kaut kas tāds, kas notiek tagad; tas nav kaut kas, kas notiek jau ilgu laiku.
Tas ir paātrinājums un laika šķēršļi, ir tikai vērts pieminēt laika šķēršļus. Pamazām mēs pārejam notikumu apstrādes pasaulē, un tāpēc mēs pakāpeniski pārietam reālā laika pasaulē, un tāpēc mēs pakāpeniski pārejam uz pieejamību, lai mums būtu nepieciešami 24 līdz 7, un tas faktiski ir grūts daudzām sistēmām - tas ir grūti sasniegt. Vai nu tas ir ļoti dārgi, vai dažos gadījumos jums faktiski ir jāmaina sistēmas, pat jāpārvietojas uz citu datu bāzi, atšķirīgu datu bāzes programmatūras versiju, kuru mēs izmantojam.
Arī šie laika šķēršļi - un es vienmēr tos gribu pieminēt, kad vien man rodas izdevība - tie ir laika šķēršļi, ar kuriem saskaras mūsu pieteikumi; lietojumprogrammas varētu vēlēties pēc iespējas ātrāk, tas ir, kad programmatūra runā ar programmatūru. Dažās situācijās patiešām nav nevienas pieņemamas licences, jūs vēlaties būt pēc iespējas ātrāks, un biznesa situācijās tādas situācijas kā tirgus situācijas, kad personai, kas nāk kopā ar pirkšanas pasūtījumu, ir zemāka cena nekā kādai citai kurš ir pirmais, un tāpēc programmatūras ātrumam ir patiešām liela nozīme.
Bet zemāk jūs zināt, ka tad, kad jūs faktiski nodarbojaties ar mijiedarbību ar cilvēkiem, vislabākais reakcijas laiks, ko no jums patiešām var prasīt, ir sekundes desmitdaļa, jo tas ir par cilvēka reakcijas laiku. Jums nav jāiet ātrāk par to, jo cilvēks tik un tā nepamanīs. Laiks no 1, 1 līdz četrām sekundēm ir nogaidīšanas laiks, ko cilvēki parasti panes, taču, tiklīdz jūs paiet garām apmēram četrām sekundēm, viņi sāk darīt kaut ko citu, un tāpēc jūs patiešām iesaistāties partijas darbībā.
Tātad jūs varat redzēt, ka konkrēti laika posmi un diena, nedēļa un mēneši tām lietām, kurās partijas rīcībai ir jēga un tāpēc jūs neatrodaties notikumu apstrādes pasaulē, un tāpēc pieejamība faktiski var būt ļoti atšķirīga vajadzīgā ziņā. lai spētu nodrošināt. Bet, tiklīdz jūs atrodaties notikumu pasaulē, jūs atrodaties pieejamībā visu diennakti, un tehnoloģijas maiņa ir faktors, jo tehnoloģija iet arvien ātrāk un ātrāk, tad pieejamība, iespējams, nepalielināsies; tas vienkārši paliek tāds, kāds ir.
Tas ir sarežģītības slānis, un es nevēlos to iedziļināties, jūs zināt, šeit ir trīs lietas, kas jāņem vērā. Pastāv infrastruktūras pakalpojumu līmenis, šī ir vertikālā ass, un tad ir jebkuras lietojumprogrammas pakalpojumu līmenis, un tad ir biznesa pakalpojumu līmenis, un tie ir atkarīgi viens no otra, un tie būs jāņem vērā ja patiesībā jūs meklējat reaģējošas vides izveidi, kur pamatā tiek sasniegti pakalpojumu līmeņi.
Tad jums ir apakšā šeit, kas ir tikai pārstāvētas datu bāzes, bet jūs varat darīt jebko sistēmā, jūs zināt, ka esat ieguvis tiešo konfigurāciju, kas nozīmē, ko saka: tas nekad neapstāsies. Jums ir karstā gaidīšanas režīma situācija, kurā vienā vai otrā veidā ir dažādi veidi, kā to sasniegt, taču tādā vai citādā veidā, ja datu bāze neizdodas, tā tiek pārslēgta uz karstu gaidīšanas režīmu un ir ļoti maza nobīde laika ziņā līdz vietai, kurā lietotāji, iespējams, pamanīs, bet neko daudz nepamanīs.
Siltais gaidīšanas režīms drīzāk atgādina pārslēgšanos 20 minūšu laikā, kad visi zvana palīdzības dienestam un sašūpojas pie palīdzības dienesta, kamēr datu bāze tiek pārslēgta uz gaidīšanas režīmu. Pēc tam rodas atkārtota sāknēšanas situācija, kurā tas var aizņemt ļoti ilgu laika periodu. Ir vērts atzīmēt, ka konkrētā lietojumprogramma vai jebkura datu bāze var būt jebkurā no situācijām atkarībā no tā, kas faktiski notiek, un no tā, kāds patiesībā ir lietojumprogrammai nepieciešamais pakalpojumu līmenis.
No tā es tikai gribu norādīt uz sarežģītības līkni. Sarežģītība izriet no mezgliem un savienojumiem, atkarībām. Pasaulē, kurā mēs dzīvojam, mezglu un savienojumu skaits, kas saistīts ar jebko, turpina pieaugt, tāpēc jūs ejat uz šāda veida lietderības līkni. Ja varat aplūkot, kā palielinās sarežģītība un kā laika dimensijas sarūk, tad zināt, vai ir pieejami pieejamības līmeņi, vai ir laika mērķi, vai tie, iespējams, samazinās?
Tāpēc dabiskā evolūcija ir vērsta uz nepārtrauktu darbību, kas, protams, ir visdārgākā - vismaz manā pieredzē - tā ir visdārgākā konfigurācija, kādu jūs varat izveidot. Vienā vai otrā veidā jebkurai organizācijai, kas par to domā, patiešām ir jādomā ne tikai par to, kas notiek tagad, bet arī par to, kas notiks nākotnē.
Varbūt pēdējais, ko es gribu izteikt, ir tas, ka pakalpojumu līmeņa pārvaldība ir pastāvīga darbība; tas nav kaut kas tāds, ka jūs zināt, ka jums ir projekts, jūs to darāt un tas ir beidzies. Tā nav, jo lietas tikai mainās. To sakot, es nodošu bumbu Dezam.
Dez Blanchfield: Paldies Robin. Es mīlu tavu atklāšanas slaidu. Mums tikko tika atkārtota filma, es domāju, ka tā ir filmas “Meklējot Nemo 2”. Jums bija Nemo meklējis pieejamību deviņu formu veidā, kas, manuprāt, bija diezgan jauki. Vienmēr smaga rīcība, kas jāievēro. Kad es domāju par darbības laiku un pieejamību un augstu veiktspēju, pirmais attēls, kas man ienāk prātā, jo es uzaugu Zālamana salās pie vulkāniem un ekvatora, manā datu centrā izvirzās vulkāns; tur ir šis tēls, kas man vienmēr prātā, ka tas varētu būt iespējams, ja kaut kas notriec. Šis ir jaukā Mt. attēls Etna, kas ir Sicīlijas ziemeļaustrumu stūris, kas atrodas tieši blakus Katanijai.
Mana pieeja tam ir sarunāties ar jums un dot jums pāris paņemšanas reizes tajā pašā līmenī, ko es regulāri rīkoju sēžu zālē no C-suite un biznesa vadītājiem ar mērķi, ka mums ir saruna par to, kas var ietekmēt jūsu organizāciju no komerciālā vai tehniskā viedokļa, un inženierzinātņu veidus.
Mums ir jādomā par to, kā un kā - ko mēs no tā atņemam un kā mēs ejam, lai risinātu dažus izaicinājumus, par kuriem mēs runājam, runājot par augsto pieejamību un darbības laiku, it īpaši saistībā ar automatizāciju un platformām.
Tātad sākotnēji uzdotais jautājums ir tas, ko mēs patiesībā domājam, runājot par datu bāzu sistēmām un datu bāzu platformu pieejamību? Ko patiesībā nozīmē runāt par reālo izaicinājumu kaut ko padarīt pieejamu līmenim, kā Robins runāja pakalpojuma līmeņa vienošanās instalētajā kartēšanā par to, kas mums patiesībā ir vajadzīgs un vēlams?
Tātad, šodienas realitāte ir tāda - un patiesībā, manuprāt, šeit ir pāris virsotņu realitātes - šodien viss tiek faktiski vadīts datu bāzē. Mūsdienās ir izveidots ļoti maz sistēmu, kas ir veidota tādā veidā, ka sīkumi vienkārši tiek glabāti failos vai ir kaut kāds līdzīgs failu žurnāls; vienmēr viss ir atkarīgs no datu bāzes. Tā rezultātā mums ir jāpārtrauc domāt par pieejamību šīm datu bāzēm, dažādām sistēmām un lietojumprogrammām un rīkiem, kas no tiem ir atkarīgi, un paļauties uz tiem, lai sniegtu pakalpojumus, kurus mēs vēlamies piegādāt, pārdot vai patērēt . Un visa infrastruktūra ap to.
Patiesībā tik ļoti, domājot par novēloto, it īpaši digitālo un mākoņu vietējo iedzīvotāju, lielajiem datu traucējumiem, dažiem uzņēmumiem, kas ir nākuši klāt, piemēram, Uber un Airbnb un tā tālāk, un nedaudz vecākam PayPals un pasaules eBays - šo organizāciju mērogs un lielums ir iespējams tikai modernās datu bāzu tehnoloģijas un mūsdienīgās mākoņu infrastruktūras dēļ. Bez tā, bez pievienotās iespējas, viņi vienkārši neeksistētu. Iedomājieties scenāriju, kurā jūs varētu nokļūt eBay tikai laikā no 9:05 līdz 9:25, jo tas nebija pieejams visu atlikušo dienu, jo tas mēģināja veikt iCloud vai dublējumu vai kaut ko tamlīdzīgu, tā vienkārši nebūtu strādāja.
Tātad, un ir arī citas galvenās jomas, domājot par mūsu ikdienas dzīvi, piemēram, mazumtirdzniecība un banku darbība, finanses, aviokompānijas un tā tālāk. Tādas lielās nozares grupas kā aviācijas loģistika, transporta kuģniecība, tur ir valdība kopumā, ir nacionālā drošība un policija utt. Visas šīs nozares, visi šie tirgus segmenti, visas šīs struktūras, grupas ir atkarīgas no tā, vai viņu vide ir izveidota un darbojas.
Tāpēc, paturot to prātā, mums ir arī otrs brīdinājums, par kuru mums ir jādomā, otrs līdzņemšana, par kuru es gribu atstāt jūs pārdomāt, un tas ir, ka mūsu pasaule tagad ir tā, ko es saucu “vienmēr ieslēgts”. Mēs esam pastāvīgi savienoti, un šo tēmu jūs dzirdēsit regulāri, un es to atkārtošu un atkārtošu. Mums tagad viedtālruņi ir rokās visu dienu, katru dienu. Mēs tos neizslēdzam, noliekam blakus gultai, tos vienmēr izmantojam kā modinātājpulksteņus, kā kameras un fotografējam, viņi šos fotoattēlus stumj mākonī.
Viņi vienmēr ir ieslēgti, pastāvīgi saistīti mentalitāte. Faktiski ir frāze monēta, kuru man patīk izmantot, un tas ir, mēs tagad dzīvojam Fitbit paaudzē, kur mēs visu mēra, visu pārrauga, un tā ir jāreģistrē un tas kaut kur iet.
Un tur ir arī vēl viena frāze, kuru es tev atstāšu, un tas ir, tas ir, ka pulksten deviņi ir kaut kur visu laiku. Tā ir 24/7/365 pasaule, kurā mēs dzīvojam. Zeme pastāvīgi griežas ap Sauli un kādā brīdī, un katru dienu dienā tā ir pulksten deviņi. Un tas nozīmē, ka cilvēki izkāpj no gultas un mēģina darīt lietas, pirkt lietas, instalēt lietas utt.
Tātad, ko mēs domājam, runājot par augstu pieejamību? Nu tas izklausās patiešām acīmredzami, līdz sākat ienirt detaļās. Tātad, jūs zināt, kad domājam par “labi, ko nozīmē augsta pieejamība?” Patiesībā realitāte ir tāda, ka sudraba lodes nav. Tas ir diezgan sarežģīts jēdziens, jo Robins bija saistīts ar dažām viņa pieminētajām tēmām, piemēram, pieejamības mērīšana un pakalpojumu līmeņa vienošanās. Mēs to kartējam, piemēram, man ir šie jautājumi, vai tas ir uptime? Vai mēs uztraucamies par tādām lietām kā tas, ko mēs saucam par pieciem deviņiem, ko es iedziļināšos minūtes laikā. Vai mēs uzskatām sevi par mūsu pakalpojumu līmeņa līgumiem? Piemēram, pakalpojumu līmeņa nolīgumos es domāju kavēšanos, trīs līmeņu burtu saīsinājums pakalpojumu līmeņa nolīgumos mūsdienās ir kļuvis arvien kritiskāks.
Tā kā jūs apmeklējat visu iepriekš izveidoto procesu un pats uzņematies resursus trešo personu datu centriem un pārvaldītiem pakalpojumiem, kas tiek piegādāti ārpakalpojumu sniedzējiem, mēs tagad visu ceļu mākoņosim. Un realitāte ir tāda, ka, kad jūs runājat par mākoni, tas ir vienkārši citu cilvēku datori. Un tas nozīmē, ka jūs nedarbojaties ar infrastruktūru, nedarbojaties ar sistēmām un vienmēr neizmantojat mākoni. Jūs darāt infrastruktūru, kas izveidota kā platforma, tāpēc pārdošanas spēka apkalpošanā tā ir vēl svarīgāka. Tagad iedomājieties, piemēram, pārdošanu, ja zināt, ka nepieskataties nevienai no šīm infrastruktūrām, vienkārši piesakāties tīmekļa saskarnē.
Tātad vienīgais jūsu rīcībā esošais mākoņu un jebkāda veida ārpakalpojumu infrastruktūras pārvaldīšanas mehānisms, kas ir pakalpojumu līmeņa vienošanās, tas ir vienīgais jūsu iegūtais mehānisms. Ja cilvēki nesatur jūsu instalāciju, viņi vai nu iztur soda naudas un samazināta naudas summa, ko jūs viņiem maksājat, vai arī jūs tos vienkārši nemaksājat.
Tātad, atceroties šo visu izaicinājumu, jūs zināt, kā mēs pārvaldām augsto pieejamību? Kā mēs pārvaldām pieejamību uptime, ja tā nav jūsu infrastruktūra - tas viss, piemēram, attiecas uz SLA. Ja tā ir jūsu infrastruktūra vai pat ja tā ir kāda cita infrastruktūra kā dizaina viedoklis. Mēs runājām par slodzes līdzsvarošanu līdz modeļa zinātnei, vai tas ir kļūdas tolerances dizaina patents?
Vai jūsu arhitektūrā darbojas aktīvs aktīvs vai aktīvs gaidīšanas režīms? Vai jums ir vairāki serveri, vairākas uzglabāšanas platformas? Kā darbojas šīs glabāšanas platformas? Vai viņi atkārto viens otru, vai viņi atspoguļo viens otru? Vai jūs izmantojat RAID? Kāda veida RAID jūs izmantojat lielai krātuvei? Vai RAID darbojas diska līmenī? Vai jūs izmantojat objektu glabāšanas platformu, kas atkārtojas visu modeļu diskdziņos un modeļu sistēmās un diskdziņos? Vai tas ir N plus viens par katru mazo jūsu iegūtās infrastruktūras gabalu? Vai jūs pievienojat vēl vienu un vai tas atrodas tajā pašā datu centrā vai citā datu centrā? Vai esat izveidojis dizaina patentu, kurā, piemēram, nav norādīta viena tirdzniecības vieta?
Visas šīs pamatlietas, tagad tās izklausās pēc vienkāršiem jēdzieniem, bet, iedziļinoties katrā no šīm lietām, tās ir ļoti, ļoti sīkas lietas. Kad mēs runājam par pieejamību, mēs vienmēr beidzam runāt par deviņiem. Un ko mēs domājam ar deviņiem? Mēs visi par tiem esam dzirdējuši, bet padomāsim tikai par to, ko tie nozīmē minūti un kāpēc viņi ir svarīgi.
Tātad, mēs runājam par vienu deviņu, kas ir tikai 90 procenti no mūsu pieejamības. Es zinu, ka tas izklausās ļoti augstu. Tātad, kad mēs runājam 24 līdz 7 līdz 365, ja mēs skatāmies, piemēram, uz vienu gadu, kad mēs runājam vienā deviņā, kas ir 90 procenti laika, tas pieļauj trīsdesmit sešas ar pusi dienas dīkstāves. Apkārt to nedaudz vairāk kā mēnesim.
Tagad padomājiet par jebkuru biznesu, ar kuru mēs nodarbojamies katru dienu - neatkarīgi no tā, vai tā ir tiešsaistes banku darbība, eBay, PayPal vai tādu sociālo mediju platformas kā LinkedIn, Twitter vai vienkārši vispārējs mazumtirgotājs - teiksim vienkārši, ka es gribēju rezervēt lidojumu, lai ierastos ASV no saulainas Austrālija, vai es būtu priecīgs, ja es gribētu atgriezties Amerikā pēc pāris nedēļām, ja mana iecienītākā aviokompānija nedarbojās trīsdesmit sešas ar pusi dienas, jo viņu pakalpojumu sniedzējs teica: "Skatieties, mēs esam 90 procentus laika "? Protams, ka es to nedarītu.
Kāpjot pa šo modeli, divi deviņi: 99 procenti. Nu tas kļūst par 3, 65 dienām, aptuveni trīsarpus dienām dīkstāves gadā. Vai tas ir liels darījums? Tā tas ir, ja jūs vadāt Melno piektdienu, un jūs vadāt īpašu izpārdošanu, un cilvēki var iegādāties tikai šo pāris dienu laikā.
Trīs deviņi kļūst tikai 8, 7 stundas gadā, bet pat 8, 7 stundas gadā, tas ir, nepārtraukti, nepārtraukti, astoņas stundas no mūsu laika. Labi, ka banku un finansēs, veselībā - ja tā ir slimnīca, labi, ka tā varētu maksāt dzīvības. Kāpjot augšup, četras deviņas ir 52 minūtes, piecas deviņas ir piecas minūtes un sešas deviņas būtībā ir 30 sekundes. Seši deviņi ir ārkārtīgi augsti, un, kāpjot pa šīm trepēm, kāpjot pa šo deviņu Ziemassvētku eglīti, jo vairāk deviņu pakāpjaties, jo grūtāk ir dizains, vide un platforma. Grūtāk ir sniegt šo pakalpojumu, un, ja jūs domājat par laika samazināšanu, kas jums vajadzīgs, lai veiktu tādas lietas kā dublējumi, administrēšana, labošana, apkopes logi jebkura veida nobīdei - visas nebūtiskas problēmas - un tas viss faktiski samazinās līdz pārtraukumu procentiem.
Galvenais, ko es gribētu pateikt, ir tas, ka nav sudraba lodes, kā es minēju iepriekš. Runājot par pieejamību, nav “viens izmērs der visiem”. Jums var būt īpašs dizaina patenta veids, kas piemērots galvenajām nozarēm. Ar vienādām problēmām saskaras visas bankas. Dažas varētu būt mazumtirdzniecības bankas, citas - prēmiju bankas. Iespējams, ka dažas bankas koncentrējas uz tirdzniecību un ieguldījumiem, bagātības pārvaldību. Daži varētu būt tikai patērētāji. Daži, iespējams, izvieto tikai internetu, un viņiem pat nav stāstītāju, un, izdalot skaidru naudu, darījumi notiek tikai ar bankomātiem. Tātad šajos scenārijos, pat banku un kapitāla pārvaldības un finanšu pakalpojumu nozarē kopumā, katram no viņiem joprojām ir savs īpašs aromāts vai lieta, kas viņiem nepieciešama, kad runa ir par pieejamību.
Tātad, domājot par pieejamību vienkāršā angļu valodā, par pieejamības un augstas pieejamības sajaukumu - mēs domājam, ka tie ir viens un tas pats, bet patiesībā tie ir krīts un siers. Pieejamība, runājot vienkāršā angļu valodā, nozīmē laiku, ko serveris vai process normāli vai vispār darbojas, un tas ir saistīts ar to izmantošanu. Tas nozīmē tikai to, kā mēs aprakstam, vai tas ir pieejams vai nav. Kad mēs runājam par pieejamību, mēs bieži nonākam šajā domāšanas slazdā: “Es to nodrošinu pieejamā formā”, salīdzinot ar augsto pieejamību, aizsargājot šīs infrastruktūras drošību.
Augsta pieejamība, citā nozīmē vienkāršā angļu valodā, ir dizains, kurā jūs ieviešat vai sasniedzat sava veida iznākumu un datu pieejamību, jo īpaši gandrīz visu laiku - 24/7/365 dienas gadā -, ka šī pieejamība izpaužas dažiem no tiem. deviņi. Vienmēr tas nenozīmē 100 procentus. Simt procentiem reālā pasaulē tehniski nav iespējams nevienā vidē. Vienam operētājsistēmas serverim, kurā ir datu bāze, ir ļoti grūti, ja darbojas platforma, un lietojumprogramma jūs to varat piegādāt un gaidīt, ka tā darbosies 100 procentus. Tad mēs sākam domāt par dizainu. Vai mums ir atlaišana, vai mums ir vairāki slaidi, ko atkārtot? Kad jūs to ievietojat vienkāršā angļu valodā, ir interesanti, cik atšķirīga kļūst pieejamības tēma salīdzinājumā ar augstu pieejamību.
Es domāju, ka es to ielikšu vienkāršā grafiskā formā tikai tāpēc, lai sniegtu mums priekšstatu par to, kā tas izskatās, kad jūs sākat kāpt uz izaicinājumu palielināt pieejamību, aizsargājot pakalpojumu uptime. Kreisajā apakšējā stūrī mums ir viens deviņš. Es esmu izlicis piecus deviņus, par kuriem mēs parasti runājam. Seši deviņi ir mazliet briesmīgi. Kad mēs runājam par pieciem deviņiem kreisajā apakšējā stūrī, aptuveni 35 dienu laikā pēc šī pārtraukuma, jūs cenšaties nodrošināt lētu un sarežģītu vidi, jo jums ir vairākas lietas, kas var neizdoties, un jūs varat joprojām izpildiet savus pakalpojumu līmeņa līgumus.
Bet, ejot pa apakšu no kreisās uz labo pusi un nokļūstot vietā, kur attēlā ir vairāk deviņu punktu, jūs saņemat scenārijus, kur jūs sākat domāt par sistēmu un platformu atkārtošanu. Jums ir jādomā par dažādu infrastruktūras daļu apvienošanu un virtualizēšanu. Jums ir jādomā par šo klasteru ģeogrāfisko izvietojumu, vairākām datu centru vietnēm, un jums ir jādomā par nozares veidu un tirgus segmentu, uz kuru jūs tiecaties. Tātad, kāda veida pakalpojumu līmenis jums ir jāsasniedz? Kādu pakalpojumu jūs meklējat? Jomas, kas ir reālā laika karšu pakalpojumi, kas stāsta par sakariem. Vai tas ir militārie dienesti? Tātad šī diagramma iet no apakšas pa kreisi uz augšējo labo pusi, un, izkļūstot caur šo līkni, palielinās izmaksas un sarežģītība. Tā kā jums kļūst sarežģītāka un prasīgāka vide, jums būs nepieciešami vairāk deviņu cilvēku.
Piemēram, šajā grafikā ir izdarīta ļoti līdzīga lieta: tas raksturo stāstu starp izmaksu sastāvdaļu un vēlamo pieejamības komponentu. Tātad augšējā kreisajā stūrī mēs kartē ļoti pieejamās sarežģītās sistēmas un izmaksas, kas rodas, ja šī pieejamība samazinās, salīdzinot ar ieguvumu, ja pieejamība ir bez dīkstāves. Piemēram, ja kreisajā pusē mums ir vide, kurā viss ir slikti, mēs varam ciest finansiālus zaudējumus. Mums ir juridiskas sekas, kas var būt komerciāla biznesa stratēģija līmeņa līmenī.
Es domāju, ka, iespējams, pat morāles problēmas ir saistītas ar pakalpojuma priekšrocībām. Ja tā ir veselības nozare un viņi sāk izjust izmaksas par apstāšanos, ietekmi uz klientiem, klientu apmierinātības samazināšanos, personāla produktivitāti, lietotāju produktivitāti utt. Šīs lietas ietekmē, ja domājam par ļoti sarežģītu, ļoti atkarīgu projektēšanu, ļoti riskanta vide, kur pastāv potenciāls pārtraukuma risks un tātad zaudējumi.
Labajā pusē mēs cenšamies sasniegt scenāriju, kurā ieguldot augstas izmaksas un plānošanu dizainā, mēs ieguldam viedā ieviešanā. Mēs investējam cilvēku prasmju un resursu nodrošināšanā, un mēs esam augstu novērtējuši tīklu un augsti novērtētu darbības vidi, kā arī aparatūru un programmatūru. Mēs saņemam augstu pieejamību, bet tas maksā par augstām izmaksām. Tātad šūpojošās maģiskās svārsta vietas, kas atrodas optimālā pozīcijā vidū, kur tās šķērso, kur mums ir nedaudz samazinātas izmaksas un palielināta pieejamība, kas vienkārši žonglē starp deviņu līmeņu līmeni, un augstā pieejamība, kas ir nepārtraukta pieejamība, un tas ir pastāvīgs izaicinājums, ar kuru mums jāsatiekas, piemēram, cik daudz naudas jūs esat gatavs ieguldīt, lai iegūtu vajadzīgo pakalpojumu līmeni?
Mums ir arī tēma, kurā es neiedziļināšos sīkumos, bet es tikai vēlos, lai jūs to atņemat un padomājat. Atšķirība starp vidējo laiku starp kļūmēm jūsu projektā un vidējo laiku, lai atgūtu. Citiem vārdiem sakot, vai jūs investējat labākas kvalitātes infrastruktūrā, labākas kvalitātes projektēšanā, labākas kvalitātes aparatūrā un programmatūrā un labākas kvalitātes kvalificētā personālā un resursos, lai izstrādātu lietas un samazinātu vidējo laiku starp kļūmēm - vidējo laiku, kas nepieciešams pārtraukuma atrašanai, nevis samazināt ieguldījumus infrastruktūrā, resursos un dizainā, kā arī neredzīgajos patentos, augstas iespējas atgūties? Citiem vārdiem sakot, ja kaut kas sabojājas, jums to ir jāpievieno daudz. Ja kādam ir klēpjdators un tas nomirst, jums ir rezerves. Jūs to nododat viņiem un pēc 30 sekundēm viņi piesakās. Tie ir ļoti dažādi staba gali. Augšējais secina, ka jūs esat inženierzinātnes ar augstām izmaksām un lielām investīcijām, lai izvairītos no kļūmēm, bet apakšā teikts, ka “es pieņemšu, ka kļūme notiks, tāpēc es gatavojos to inženierim un esmu gatavs neveiksmei un ātri atgūties. ”
Kā es minēju iepriekš, kur es varētu pateikt: “Mana pieejamība nav jūsu pieejamība.” Tātad, runājot par datu bāzu vidēm un infrastruktūras atbalstīšanu, datu bāzes pārvaldīšanu un aizsargāšanu un augstas pieejamības nodrošināšanu, tiešām nav vienas pieturas aģentūras. . Katram ir savas vajadzības un vēlmes. Tātad jums ir jāuzdod sev šie pamatjautājumi, kurus es jums atstāšu, un tas ir: ko jūsu organizācija var atļauties? Es nerunāju tikai par dolāriem un centiem. Es kā organizācija runāju par to, ko jūs varat atļauties no resursiem, laika, pūles un tā tālāk, ciktāl to var sasniegt pieejamības līmenis? Kādu atbalstu var sniegt jūsu bizness? Tātad, pašreizējās iespējas, pašreizējās prasmes, pašreizējā infrastruktūra, pašreizējais finansējums, kuru varat piesaistīt. Tā, ka žonglē starp to, ko jūs faktiski varat atļauties, pret to, ko varat atbalstīt, ir interesants līdzsvars.
Turklāt jums ir jāuzdod sev jautājumi: kādas prasmes un tehnoloģijas jums ir iekšējās? Vai jūs varat nodot dažus no šiem izaicinājumiem? Vai jūs pēc tam varat pārvietot lietas uz mākoni? Ja jums ir infrastruktūras pakalpojums, kas nav programmatūras pakalpojums, jūs paliksit bez šī kaudze, dodoties tālāk augšup pa kaudzīti. Tātad jums vajadzētu vairāk ieguldīt platformās un pakalpojumos, nevis jāuztraucas par infrastruktūras gabalu, vai arī programmatūra jāuzlūko kā pakalpojumu piedāvājums, jo jums nebūtu jāuztraucas par platformu?
Kāda veida tirgu un patērētāju vai klientu jūs apkalpojat? Es domāju, ja jūs esat telekomunikāciju operators un kādam ir jāuzņem tālrunis un jums visu laiku jāsaņem iezvanes signāls, tas ir pavisam cits izaicinājums, atverot nelielu mazumtirdzniecības veikalu no pirmdienas līdz piektdienai no deviņiem līdz pieciem un slēdzot Stunda pusdienlaikā kā stūra veikala frizieris. Tātad jums ļoti ilgi un smagi jādomā, kā tas darbojas un ko tas nozīmē jūsu organizācijai, kas jums jāspēj sniegt.
Tad notiek žonglēšana starp to, kas atrodas telpās, to, kas atrodas ārēji un, iespējams, ar to, kas atrodas mākonī. Kā jau teicu iepriekš, tas nāk no laika izaicinājumiem. Tāpēc mēs esam palikuši pie pēdējā jautājuma, ko es ar nepacietību gaidu no draugiem IDERA, lai pastāstītu mums, kā viņi risina šīs lietas, un tas ir lielisks žonglēts starp jūsu vēlamās un nepieciešamās pieejamības saskaņošanu ar sniegumu, kā arī to, kas jūsu uzņēmumam ir vajadzīgs un kas jūsu tirgum un patērētājiem.
Un realitāte ir tā, ka tas nav nekāds varoņdarbs. Būs vajadzīgs laiks, pūles un nauda, lai pārdomātu šīs lietas. Un tas vienmēr ir ieguldījums cilvēkos un prasmju attīstībā, kā arī ieguldījums programmatūrā un rīkos, lai automatizētu dažus no šiem procesiem un nodrošinātu šiem cilvēkiem pareizos rīkus un pareizās sistēmas, kas viņu dzīvi padarītu ne tikai labāku, bet arī iespējamu, jo ļoti liela mēroga vides uzraudzība un aizsardzība un šo liela mēroga vides pārvaldīšana bieži pārsniedz cilvēka individuālās iespējas.
Tāpēc, cerot uz to, es, cerams, esmu izveidojis vietu lieliskai sarunai mūsu draugiem IDERA telpā, lai runātu par viņu platformu un rīkiem, un es ceru uzdot dažus lieliskus jautājumus beigās. Un es nodošu tālāk.
Dr Robin Bloor: Labi. Bert, es jums vienkārši iedevu atslēgas, atņemiet to.
Berts Scalzo: Paldies! Paldies, Dez un Robin. Es turpināšu tēmu par jūsu datu augstu pieejamību. Un es patiesībā gatavojos izmantot daudz tā, par ko Dezs tikko runāja. Tātad, izvēles, deviņi, kompromisi, pieejamība. Es mēģināšu to izteikt vairāk datu bāzes administratoram vai kādam, kurš atradīsies tuvāk tranšejām, kā viņi to izskatīs? Kā viņi to arhitektētu? Un ko nozīmē šīs izvēles?
Tagad es mēģināšu būt datubāzes agnostika. Es necerēšu, piemēram, Oracle specifisku vai SQL Server specifisku risinājumu, bet es izstrādāšu, teiksim, vispārīgu arhitektūru, ko piedāvā visi datu bāzu pārdevēji, kaut ko tādu. Viņi visi to sauc ar atšķirīgiem nosaukumiem, bet tas ir viena veida izvēle, kas jums ir kopīga, un es vēlos to aplūkot gan no biznesa, gan tehnoloģiju viedokļa, kā arī no tā, kā tas ir saistīts ar biznesa prasībām.
Un es gribu sākt ar to, kas ir visvienkāršākais pseido-augstas pieejamības risinājums, izmantojot opcijas, kas jums ir krātuves līmeņa risinājumos, virtualizācijas līmeņa risinājumos, datu bāzes līmeņa risinājumos. Un tad es gribētu jūs arī iepazīstināt ar faktu, ka visas izvēles ir pieejamas arī mākonī.
Tātad es atkal mēģināšu palikt diezgan datubāzes agnostika. Tagad par lielāko daļu lietu, par kurām runāšu, es zinu, ka tās pastāv Oracle, SQL Server, MySQL, PostgreSQL. Ir arī daži trešo pušu pārdevēji, kas ražo rīkus, kas arī sniegtu jums papildu arhitektūru, kuru jūs varētu apsvērt. Un, kā nupat teica Dezs, neviens risinājums nav labākais; viss atkarīgs. Bet ir viens universāls fakts, ko mēs aplūkosim, vai būs vairāk kustīgu detaļu, tāpēc tas būs sarežģītāks un tāpēc dārgāks.
Tātad, mēs visi zinām, ka dati ir svarīga priekšrocība. Un visi zina, ka ātra piekļuve datiem vienmēr ir patīkama. Tomēr uzticami piekļuvi datiem ir kritiski svarīgi. Un kā viņš runāja ar saviem deviņiem piemēriem, vai jūs tiešām varat atļauties 36½ dienu dīkstāvi? Ir svarīgi, lai šie dati būtu pieejami visu laiku. Tātad dīkstāve var maksāt laimi gan zaudēto ieņēmumu izteiksmē, bet vēl svarīgāk - zaudēto klientu vai klientu nemateriālās vērtības zaudēšanas ziņā. Es minēšu labu piemēru; ja konkrēta vietne, kurā es veicu pirkumus, notiek lēni, es varētu mēģināt atrast jaunu vietni, kas par līdzīgām izmaksām pārdod līdzīgas preces, kurām nav lēnas vietnes. Un tā, tas nav tikai klienta zaudējums, bet gan laba griba, kāda klientam ir pret jums.
Mūsdienās datortehnika ir daudz lētāka, tāpēc arvien lielāks pieprasījums ir pēc augstas pieejamības. Un atkal es gribētu mūs novest pie mākoņa, kad mēs to apskatīsim. Un mums ir dažādu līmeņu piedāvājumi: krātuves pārdevēji, datu bāzu pārdevēji, virtualizācijas pārdevēji un tagad pat mākoņa pakalpojumu sniedzēji. Un tas, kas patiešām ir interesants ar mākoni, ir pēc tam, kad esmu uzzīmējis visus šos brīnišķīgos šo arhitektūru attēlus, kurus jūs varētu izveidot mākonī, daudz reižu ir tikai dažas rūtiņas, kuras jūs pārbaudāt. Un jūs sakāt: “Es gribu replikāciju visos ģeogrāfiskajos reģionos.” Atzīmējiet izvēles rūtiņu. “Es vēlos galveno aparatūras komponentu replikāciju.” Rūtiņa. Tātad, ja jūs saprotat attēlus, dažreiz mākonī tas ir tikai dažas izvēles rūtiņas, lai izveidotu attēlu, kas jums prātā.
Tagad galvenais ir tas, kādas ir biznesa prasības attiecībā uz augstu pieejamību? Piemēram, vai man jāuztraucas tikai par kļūmēm vienā vietnē vai arī man tas ir jāatrodas vairākās vietnēs? Citiem vārdiem sakot, vai man var būt viens skaitļošanas centrs, un man nav vienalga, vai šis viens centrs darbojas bezsaistē? Es neizvirzu uzņēmējdarbības prasību, lai tā paplašinātos vairākās vietnēs. Tas ir biznesa jautājums. Ir svarīgi zināt, kā bizness uztver atbildes uz šo jautājumu, jo tas parasti nosaka jūsu budžetu.
Tagad jūs arī vēlaties paskatīties uz aizsardzību pret kļūmēm. Vai tā varētu būt strāvas padeve? Vai tā varētu būt komponenta kļūme? Tāpat kā NIC vai HBA iet slikti, resursdatora kopnes adapteris. Vai cietais disks ir slikts? Vai tā ir glabāšanas skapja kļūme? Vai tā ir datora kļūme? Vai dažos gadījumos tā ir vietnes kļūme? Tas ir savādāk nekā dažos gadījumos vietnes kļūme, jo pati vietne ir bezsaistē. Citā gadījumā var būt, ka ievērojama vietnes daļa ir bezsaistē, taču, no jūsu viedokļa raugoties, tā ir visa vietne.
Un tad, kad runāja par Dezu, kādas ir laika cerības atsākt operācijas? Tas ir biznesa jautājums. Ja bizness saka, ka jums jāspēj atsākt darbību divu minūšu laikā, tad, protams, tas definēs dažus no šiem attēliem, kurus es parādīšu, ka jūs darbosities, un daži no tiem nebūs varianti, kurus jūs var izvēlēties.
Un vēl viens jautājums, kas rodas augstas pieejamības laikā, bet bieži vien cilvēki aizmirst uzdot, ir šāds: "Ei, bizness, ja kaut kas notiek, kamēr es esmu darījuma apstrādes vidū, ko es varu pazaudēt, atsākot sistēmu? " Citiem vārdiem sakot, ja es varu atjaunot sistēmas izveidi divu minūšu laikā un es varu zaudēt ne vairāk kā 10 sekundes no, teiksim, darījumiem, kas bija lidojumā, vai tas ir pieņemams bizness? Un tas atkal definēs, ko bizness ir gatavs tērēt tam, un tad atkal tas var definēt, kuras bildes, kuras jums parādīšu, vai nu tiek piemērotas, vai nav piemērotas.
Tātad, sāksim ar visvienkāršāko pseido-augstas pieejamības risinājumu. Tā patiešām nav augsta pieejamība, bet man patīk sākt ar to, jo tas liek cilvēkiem domāt pareizi. Ja man ir serveris un atmiņas masīvs, parasti šajā serverī ievietošu vairākus NIC, tīkla interfeisa kartes un sasaistīšu tos tā, ka, ja viens NIC neizdodas, es joprojām esmu gatavs. Es darīšu to pašu ar saviem resursdatoru kopņu adapteriem, izmantojot dažādus maršrutus, izmantojot dažādus slēdžus, lai man būtu vairāki veidi, kā nokļūt manā krātuvē. Un es saņēmu universālu barošanas avotu, un manā krātuves blokā ir atkārtoti kontrolieri, un varbūt es ar saviem diskiem esmu izdarījis kaut ko līdzīgu RAID 10. Citiem vārdiem sakot, šajā attēlā esmu novērsis vienkomponentu kļūmes vairākos līmeņos. Tātad, man nav saistošs ne NIC, ne HBA, ne kontrolieris, ne slēdzis.
Bet, ja pamanāt, serveris ir sarkanā krāsā, un krātuves masīvs ir sarkanā krāsā. Man joprojām ir divas jomas, kurās, ja tās neizdodas, ja mans serveris aiziet, es esmu miris, ja mans atmiņas bloka kabinets aiziet, es esmu miris. Tātad, kaut arī tā nav īsti augsta pieejamība, tas sāk jūs redzēt un aplūkot attēlu un teikt: "Es gribu attēlu, kurā nav sarkanas krāsas." Un tas tiešām ir šo attēlu mērķis, lai mūs norādītu pareizajā virzienā.
Tātad, pirmais, kas jānotiek, ir tas, ka es kā DBA vienmēr gribētu likt augstas pieejamības risinājumu kā datu bāzes ieviešanu, taču varētu būt, ka tas ir pieejams, ka to var izdarīt kā krātuves risinājumu, vai arī tas varētu būt ka tā varētu būt krātuves līmeņa replikācija. Kreisajā gadījumā esmu ieguvis virtualizācijas krātuvi. Kas notiek, es esmu ieguvis RAID 0 divos dažādos disku glabāšanas skapjos, bet es esmu ieguvis RAID 1 divos dažādos uzglabāšanas skapjos. Citiem vārdiem sakot, es faktiski tagad varu piedzīvot krātuves skapja kļūmi, un es neesmu miris. Tātad, tas ir labāk nekā iepriekšējais attēls, jo iepriekšējā attēlā - atcerieties, ka serverī mums bija gan sarkans, gan glabāšanas masīvā bija sarkans - un tagad mēs veicām nelielu uzlabojumu, mums vairs nav sarkana krātuves līmenī, Es esmu izmantojis - krātuves virtualizācija atrisināja šo problēmu.
Vēl viens veids, kā jūs to varētu izdarīt - un ne visi pārdevēji to nodrošina - ir tas, ka jūs, iespējams, varēsit veikt krātuves līmeņa replikāciju. Es nerunāju par datu bāzes replikāciju, es faktiski runāju par jūsu bloka I / O replikēšanu jūsu krātuvei. Un to var izdarīt glabāšanas līmenī. Un tā, atkal, man tagad labajā pusē ir vēl viens attēls, kurā es no apakšas noņemu sarkano krāsu, jo es izmantoju atmiņas replikāciju.
Tātad, šī ir vēl viena aina, kas var būt pieejama vai nebūt pieejama. Un persona, kas to pārvaldītu, iespējams, ir jūsu krātuves administrators, nevis datu bāzes administrators. Man patīk to izcelt, jo dažreiz cilvēki domā: "Ak! Augsta pieejamība, šai problēmai jābūt DBA." Tas ne vienmēr ir taisnība; šajā gadījumā tas varētu būt krātuves administrators.
Tagad mēs varam veikt servera virtualizāciju kā iespējamo risinājumu. Ja jūs atceraties, pirmajā attēlā man bija sarkans serverī un sarkans krātuves masīvā. Es šajā gadījumā, izmantojot virtualizāciju, es varētu pārcelties, un dažos gadījumos pārvietošana ir sava veida silta pārvietošana, un dažos gadījumos tā var būt pat karsta pārvietošana. Daži virtualizācijas vai hipervizori nodrošina iespēju pārvietot virtuālo mašīnu lidojuma laikā. Un dažas datu bāzes šo kustību lidojuma laikā viegli pieņems. Tagad ne visi hipervizori to nodrošina, bet tas ir viens no iespējamiem risinājumu līmeņiem. Tagad esmu pārliecinājies, ka labākie serveri vairs nav sarkani, bet man joprojām ir koplietotās krātuves masīvs. Uzmini, šis risinājums var būt kopīgs darbs starp datu bāzes administratoru un virtualizācijas administratoru. Vai arī tas varētu būt tikai virtualizācijas administrators atkarībā no tā, kāds pārvietošanas līmenis tiek atbalstīts šajā hipervizorā un datu bāzē.
Ja jums rodas jautājums: “Oho, ko viņš domā ar šo pārvietošanu? Sniedziet man konkrētu piemēru. ”Piemēram, virtuālajā mašīnā, kur jūs varat izmantot VMotion, lai pārvietotu savu virtuālo mašīnu no vienas resursdatora uz otru un izdarītu to bez dīkstāves. Tagad skaidri redzams, ka iepriekšējā attēlā joprojām bija sarkana krāsa. Man joprojām krātuve bija viens neveiksmes punkts. Tāpēc mēs pārejam pie nākamā risinājuma, kas ir, labi, ļaujiet man apvienot krātuvi un servera virtualizāciju.
Tagad šajā gadījumā atkal varētu būt atmiņas administrators un virtualizācijas administrators, kas veido šo risinājumu un tagad izskatās: man ir attēls, kurā tajā nav sarkanas krāsas. Esmu ieguvis augstu pieejamību, jo varu pārvietot virtuālo mašīnu vai darbojošos lietojumprogrammu vai datu bāzi no viena servera uz otru, un manā virtualizācijas krātuvē ir virtualizācija, veicot RAID 1 divos atsevišķos atmiņas blokos. Esmu daudzkārt uzlicis savus slēdžus un savus HBA.
Tāpēc tagad esmu izveidojis HA sistēmu un to galvenokārt esmu darījis nevis datu bāzes līmenī. Citiem vārdiem sakot, es esmu izmantojis citas tehnoloģijas, lai paveiktu to pašu. Tātad, tas ir risinājums. Tad mēs nokļūstam tā sauktajā koplietojamas krātuves mērogojamā klasterī. Tas tiešām nav HA risinājums, bet man atkal patīk to parādīt attēlam.
Un kas notiek šeit, mums ir divi serveri, kas vada datu bāzi, un to uzskata par vienu datu bāzi. Tās nav divas atsevišķas datu bāzes; tas nav kā saimnieks un vergs, ne karsts un auksts, ne aktīvs un gaidīšanas režīms. Tas ir, abi šie mezgli strādā kopā, lai izveidotu vienu loģisku datu bāzi. Un tā, kas notiek, ja kāds mezgls neizdodas, jūs joprojām esat gatavs. Tātad, tas pasargā jūs no servera līmeņa kļūmēm un, ja vēlaties, galvenokārt rīkojas, sadalot mezgla resursus, taču jums joprojām ir viens diska neizdošanās punkts. Tātad, tas ir koplietojamas atmiņas mērogojams klasteris, un Oracle šo Real Application Cluster vai RAC izsauc.
Tagad vēl viens risinājums ir izmantot koplietotas krātuves kļūmju kopu. Tātad kreisajā pusē esmu ieguvis aktīvu mezglu, labajā pusē pasīvo mezglu, pa vidu esmu sirdsdarbība. Man ir koplietots krātuves masīvs, un tas ir kritiski; jums tas ir jābūt. Un būtībā tas, kas notiek, ja aktīvajam mezglam rodas problēmas, pasīvo mezglu var pārņemt. Tam ir licencēšanas problēmas. Daži datu bāzu pārdevēji ļauj jums pasīvo mezglu ar samazinātu licenci uz noteiktu laiku. Citos gadījumos jums ir jābūt pilnīgai licencēšanas kopijai. Viss ir atkarīgs no jūsu datu bāzes pārdevēja. Bet viņi visi atbalsta šāda veida attēlu, kas ir, ja viens mezgls samazinās, otru mezglu var pārņemt.
Parasti tas ir viens no scenārijiem, kad, pārejot no aktīvā mezgla uz pasīvo mezglu, jūs domājat, ka lielākajā daļā datu bāzu - ne visās - jūs zaudēsit daļu no lidojumu darījumi. Tad mēs nokļūstam tajā, ko patiešām var apskatīt datu bāzes administrators, tas ir, datu bāzes replikācija, un ir divi dažādi veidi, kā veikt datu bāzes replikāciju.
Pastāv fiziska replikācija, un, kas ir svarīgi, šī attēla vidū ar zaļo zvaigzni var redzēt, ka replikāciju veic datu bāze, bet, līdzīgi kā glabāšanas līmeņa virtualizācija, tā tiek veikta blokā līmenis. Tātad, mēs atkārtojam faktisko I / O bloku no aktīvā mezgla uz tikai lasāmo vai pasīvo mezglu. Un tas tiek uzskatīts par fizisku atkārtošanos.
Tagad ļaujiet man pāriet uz nākamo slaidu, jo tas ir gandrīz identisks un tā ir loģiska replikācija, un vienīgais, kas mainās attēlā, ir tas, ka pa vidu, tā vietā, lai nosūtītu pa bloka I / O, mēs galvenokārt sūtām pa žurnālu failus ar tajā esošajām SQL komandām. Citiem vārdiem sakot, tas, ko mēs atkārtojam, nav fiziskā I / O, bet gan komandas, kas izraisa fizisko I / O.
Tātad, to bieži sauc par žurnāla nosūtīšanu vai uz žurnālu balstītu replikāciju. Daži datu bāzu pārdevēji to sniedz jums sākotnēji. Iespējams, ka citi datu bāzu pārdevēji to nepiedāvā, bet tad trešo pušu piegādātāji to piedāvā, tāpēc šis ir ļoti populārs HA risinājums, un tas tiek uzskatīts par pilnīgu risinājumu. Bet par šo risinājumu galvenokārt atbild DBA.
Tātad, es to neizmantoju virtualizēšanai. Es varētu, bet es neesmu no tā atkarīgs. Un es neizmantoju krātuves virtualizāciju. Atkal es varētu, bet es neesmu no tā atkarīgs. Bet es gatavoju risinājumu, kurā galvenā braukšanas funkcija ir datu bāze. Tātad, šī ir loģiska atkārtošana.
Tagad ir arī iespējams apvienot datu bāzes un krātuves virtualizāciju. Varētu manā datu centrā, teiksim, kreisajā pusē, zilā krāsā, man varētu būt virtualizācijas krātuve, lai es netiktu saistīts ar konkrēta krātuves masīva kļūmi. Bet es, iespējams, veicu datu bāzes līmeņa žurnālistiskas vai loģiskas replikācijas no viena datu centra uz otru, lai komandas tiktu izpildītas arī datu centrā, kā rezultātā tiek iegūts I / O, bet ne vienmēr tas pats I / O, jo es ' Es nesūtīšu bloķēšanas I / O caur krātuves risinājumu vai ar datu bāzes palīdzību, bet es nosūtu žurnālus un tāpēc SQL komandas.
Tātad, šis ir attēls, kas ir ļoti izplatīts ļoti lielām organizācijām. Un man šeit patīk šis attēls, jo, ja man tas jāiestata, izmantojot tādu datu bāzi kā Oracle, es to varu izdarīt; tas ir diezgan liels darba apjoms, diezgan sarežģīts, tajā ir daudz kustīgu daļu. Ja es to daru mākonī, es burtiski varu vienkārši pateikt izvēles rūtiņu, es gribu divus ģeogrāfiskos reģionus, es gribu, lai reģionus atdalītu, jūs zināt, dažādos kontinentos, es vēlos krātuves līmeņa virtualizāciju noteiktā ģeogrāfiskajā reģionā. Es pat varu teikt, ka es vēlos iespēju veikt virtualizācijas veida piešķiršanu vai augstas pieejamības definīciju, un atkal tā ir vēl viena izvēles rūtiņa.
Un otra lieta, kas man patīk mākonī, tur ir vēl viena izvēles rūtiņa, kurā bieži tiek teikts: “Es nevēlos nodarboties ar lāpīšanu, vienkārši to ielāpot”, ziniet, vienkārši iekļaujiet to darbplūsmā visam citam, ko darāt aiz ainas, vienmēr mani patur. Un tā, kaut arī daži no šiem attēliem kļūst ļoti sarežģīti un, ņemot vērā pieņēmumu, tos varētu būt ļoti grūti izdarīt, tos faktiski kļūst diezgan viegli izdarīt mākonī.
Tagad ir interesanti, ka ir viegli pārbaudīt visas izvēles rūtiņas, bet uzminiet, kas katru mēnesi maksā vairāk naudas. Tā kā, ja jūs vadāt divus datu centrus, jūs zināt, ka jums ir divi datu centri, kas atrodas mākonī, kuru jūs izmantojat, jūs maksāsit vairāk nekā tad, ja tikai izmantotu vienu. Tāpat, ja jūs kā papildu slāni veicat krātuves līmeni vai virtualizācijas augsto pieejamību, atkal, iespējams, būs papildu izmaksas.
Tātad, ir interesanti, ka, lai gan to ir grūti izdarīt uz vietas un jūs to varat pārvērtēt, mākonī to ir tik viegli izdarīt, jūs to varat apzināties. Tātad, vienmēr ziniet, kā attēls izskatās, un vienmēr zināt, kāda ir izmaksu attiecība uz visu attēlu, kuru jūs veidojat. Tagad ir daudz vairāk kombināciju, nekā tas, ko es šeit parādīju. Šis nav pilnīgs vai izsmeļošs piemērs. Ar regulāriem intervāliem nāk jaunas tehnoloģijas, tāpēc, kas zina - iespējams, ka neesmu parādījis tādu, kas ir parādījies tikai pēdējos trīs mēnešos. Un augsta pieejamība ir daudz biežāka nekā tā bija pirms desmit gadiem.
Patiesībā es to neuzskatu par posmu, sakot, ka lielākajai daļai lielo organizāciju mūsdienās tā ir obligāta uzņēmējdarbības prasība. Un man patīk atgriezties pie šī slaida, jo es tikko teicu, ka tā ir obligāta biznesa prasība. Un es saņēmu šos divus galdus labajā pusē. Augšējā daļa nav pieejama SQL Server dokumentācijā, bet apakšējā - Oracle dokumentācijā. Kas tie ir, šīs ir tabulas, kas palīdzēs jums izvēlēties, kuru replikācijas metodi jums vajadzētu izmantot.
Un ievērojiet, ka jūs sākat ar dažiem ļoti vienkāršiem jautājumiem. Cik daudz datu man ir atļauts izmantot? Un, ja atbilde ir nulle, jūs zināt, ka augšējā diagrammā varat izvēlēties tikai pirmo vai ceturto rindu. Tad jūs uzdodat citu jautājumu. Nu, cik ilgi man atļauts veikt atveseļošanos? Un, ja kāds saka, labi, sekundes vai minūtes, tad tas jums ļauj izdarīt izvēli. Un vai tad kļūmjpārlēcienam jābūt automātiskam, vai arī tas ir jāveic kādam manuāli? Un tas ir vēl viens biznesa jautājums. Viņi var teikt, ka viņi to vēlas automātiski, jo viņi nevēlas paļauties uz eskalācijas procedūru un pēc tam kādam tiek piešķirta biļete un pēc tam atrisināt problēmu. Viņi vienkārši vēlas, lai tas tiktu labots.
Tie visi ir jautājumi uzņēmējdarbībai, un tie ir tie paši jautājumi, ja es dodos uz leju un daru to pašu Oracle. Un es jautāju, labi, kāda veida kļūmi es pieļauju, kāda ilguma, ko es varu zaudēt, kāda ir atkopšanas procedūra? Tā ir visa biznesa izvēle, tāpēc, ja bizness man atbild uz trim vai četriem jautājumiem, un mans darbs ir patiešām viegls, es vienkārši ienācu šeit, es izvēlos to, kurš no šiem mačiem ir vistuvākais, un tad es to veidoju. Un atcerieties, ka mākonī tās var būt tikai dažas izvēles rūtiņas, lai tās faktiski ieviestu.
Un līdz ar to tas beidzas ar mana materiāla beigām un laiku, lai atvērtu to jautājumiem.
Ēriks Kavanaghs: Labi, Dez, varbūt jūs vispirms un tad Robins?
Dez Blanchfield: Absolūti. Patiesībā, iespējams, nedaudz negodīgi attiecībā uz tiem, kas nav čivināt, bet es tikai iekodēju grafika attēlu, kuru es vēlos vizualizēt ikviena prātā, un tad es gribēju iemest jautājumu mūsu iemācītajam draugam, zvanot šeit. Kad es šajā telpā domāju par patentētu versiju pret atvērto avotu - par ko bieži mēs runājam, par sava veida patentētām datu bāzēm, piemēram, Oracle un Microsoft, un tā tālāk, salīdzinot ar atvērto avotu, jūs nonākat šajā izaicinājumā, kurā patentētā pasaule interneta programmatūras pārdevējs vai programmatūras izstrādātājs, vai arī uzņēmums iegulda līdzekļus struktūras izveidē, lai izveidotu šo sarežģītību. Un tā, jūs gaida scenārijs, kurā jūs pērkat programmatūru un jums nav jāiegulda daudzos cilvēkos, jo jūs pērkat iespējas, kas iebūvētas atvērtā pirmkoda iekšpusē - jūs nemaksājat par programmatūru vai, teiksim, jūs maksājat par zemām izmaksām, bet jums nav jāmaksā par programmatūru, bet jums ir jāiegulda ķermenī.
Un es vēlos saņemt jūsu domas par žonglēšanu, it īpaši tagad, kad mēs pārietam pie mākoņu modeļiem, kur varat nokļūt vai nu. Varat doties uz AWS vai Azure un Rackspace, neatkarīgi no tā, un iegādāties kā pakalpojumu, kas nodrošina jūsu datu bāzes platformu, vai arī varat to izdarīt, izmantojot atvērtā pirmkoda kodu. Un tas, par ko mēs tikko runājām, kāda ir žonglēšana starp patentēto un atvērto avotu un kā tiek īstenoti jūsu runājamie dizaina paraugi un kādas ir jūsu vispārējās domas par šo tēmu, kad mēs virzāmies uz priekšu, it īpaši attiecībā uz pieejamības nodrošināšanu?
Berts Scalzo: Viens no lielajiem priekšmetiem, kas man rodas, mēģinot risināt šo jautājumu, es dodos atpakaļ pie klienta un jautāju viņam par viņu veiktspējas prasībām. Es to daru tāpēc, ka vismaz vēsturiski un pēc savas pieredzes esmu secinājis, ka, runājot par klientiem, kuru replikācijai nepieciešama liela caurlaidspēja, man gandrīz vienmēr labāk veicas ar replikāciju, ko nodrošina datu bāze pārdevējs, ņemot vērā būtību, ka tas ir raksturīgāks iebūvēts un atrodas zemākā līmenī, un dažreiz tas izmanto mehānismus, kas ārējai pasaulei nav pieejami pat atvērtā koda risinājumā.
Un minēšu labu piemēru no viena gadījuma, kas man bija. Man bija interneta uzņēmums, kas izmantoja MySQL kā savu datu bāzi, un viņi izmantoja veco MySQL versiju, piemēram, versiju 4.0, un replikācija starp to mezgliem bija ierobežojošais faktors, cik lieli viņi varēja mērogot savas datu bāzes. Viņi skatījās uz trešās puses risinājuma iegādi, pēc tam skatījās: "Nu, varbūt mēs varam izmantot kādu no atvērtā koda risinājumiem." Un tas, ko tas patiesībā saruka uz leju, bija viss, kas viņiem bija jādara, bija uzlabot savu MySQL uz versiju, es domāju, ka tas bija 5, 5, pie kura mēs devāmies, jo atšķirība starp šīm divām datu bāzes versijām bija MySQL versijas 4.0 versijā, kas nebija vītņota Versijā 5.0 tas bija, un tas viņiem faktiski bija labākais ceļš.
Tagad mēs apskatījām citas izvēles, bet noteicošais faktors bija veiktspēja un palikšana pie datu bāzes piedāvātāja risinājuma, un datu bāzes jaunināšanas veikšana faktiski kļuva par mūsu labāko risinājumu, lai iegūtu visaugstāko varbūtību iegūt veiktspēju, kas viņiem nepieciešama, lai kopā ar jo augstāka pieejamība.
Dezs Blanšfīlds: Jā, godīgi sakot, tas atspoguļo manu domāšanu. Tikai pilnīgas informācijas atklāšanas nolūkā es neiedziļināšos zīmolos, bet esmu cēlies no patentēta fona, kas strādā oriģinālo iekārtu ražotāju un programmatūras pārdevēju, kā arī SOK kopumā, un tā noteikti ir bijusi mana pieredze, un tajā pašā laikā es esmu ļoti profesionāls -atvērts avots, un es esmu kodu līdzautors daudziem projektiem, kurus mēs nenosauksim, bet es jums piekrītu, ka, ja jūs esat liela organizācija - teiksim, ka jūs esat banka, vai kas cits, jūs varētu esiet vienmēr, ka nevēlaties būt IT veikals. Jūs zināt, piemēram, ja esat laikrakstu izdevējs vai mazumtirgotājs, jūs nevēlaties būt IT veikals, kas izdod laikrakstus, jūs vēlaties būt avīžu veikals, kas faktiski tikai piesaista IT.
Tātad ieguldīšana patentētajās iespējās, kurās programmatūras izstrādātāji visu šo iespēju, slodzes līdzsvarošanu un tamlīdzīgi veido rīkā, padara daudz vairāk jēgas salīdzinājumā ar to, ja jūs, piemēram, esat dotcom startētājs vai kaut kas tamlīdzīgs piemēram, kas var ieguldīt cilvēku ķermeņos. Kur jūs redzat šo notiekošo?
Droši vien mans pēdējais jautājums, pirms es nododu Dr. Robinam Blooram, jo es zinu, ka mums pietrūkst laika. Kur, jūsuprāt, tas notiek no tendenču viedokļa? Tātad, jūs visu laiku atrodaties tur, uz lietas asiņošanas malas, vai redzat, ka cilvēki ir sēdējuši un pievērsuši uzmanību un pamodinājuši, ka tas ir jāpadara par viņu ikdienas komerciālo daļu. dienas saruna atpakaļ uz sēžu zāli? Vai arī jūs joprojām redzat, ka tas ļoti domā par geek fermu, tehniķiem un kapučiem, domājot par pieejamību, jo tas liek viņiem mosties pulksten četros no rīta, kad kaut kas notiek bezsaistē?
Vai jūs domājat, ka šī tendence ir vērojama jebkura lieluma organizācijās, nevis acīmredzamās organizācijās, piemēram, aviosabiedrībās un banku un finanšu jomā, bet tikai uzņēmumos kopumā? Vai jūs domājat, ka cilvēki patiešām ir izgājuši no vērtības piedāvājuma, lai aizsargātu savu datu bāzu vidi un nodrošinātu augstu pieejamību un tajā ieguldītu, vai jūs domājat, ka mums joprojām ir tālākais ceļš? Kāda vispārējā izpratne pastāv tirgū?
Berts Scalzo: Šobrīd es domāju, ka joprojām pastāv plaisa, taču tā nav plaisa, jo bizness to neprasa, tā ir plaisa komunikācijas līmeņos starp abām sētas pusēm. Citiem vārdiem sakot, biznesa cilvēki ļoti skaidri saka: “Šīm lietojumprogrammām ir nepieciešama augsta pieejamība, un tām ir šīs īpašās prasības, kad mēs sakām, ka ir augsta pieejamība.”
Un kaut kā vai citādi šis vēstījums tehnikas cilvēkiem nav skaidri redzams. Vai arī tehniķi atgriezīsies un sacīs: “Ak, tas ir sarežģīti, un tas tev izmaksās vairāk naudas”, un tas, vai tas, vai otrs. Es domāju, ka tas, kas notiks, beidzot to iznīcinās, jo, ja godīgi, atrodoties, piemēram, mākonī, vienkārši atzīmējot dažas rūtiņas šeit vai tur, lai pateiktu: “Izveidojiet man šo patiešām sarežģīto tehnoloģiju struktūru” tiešām nav pietiekama iemesla, lai tehnoloģiju cilvēki atgrieztos un pateiktu biznesa cilvēkiem: “Ak, tas ir dārgi” vai “to ir grūti izdarīt”, šo vai citu, un biznesa cilvēki sāk zināt, ka tas ir tas fakts.
Un es esmu pat redzējis vidēs, kur, jūs zināt, nāks viņu pašu IT cilvēki un sacīs: “Ak, jums nevar būt tā, ko vēlaties. Tas ir pārāk dārgi. ”Un viņi piesaistīs trešo personu konsultāciju firmu, kura tad atbildēs:“ Nē, tas nav pareizi. Lūk, kā jūs to varētu izdarīt. Lūk, tas jums maksās. ”Tātad, es domāju, ka mums vēl ir mazliet laika starp sakaru līmeņiem starp abām pusēm, pirms tas joprojām kļūst automātisks.
Dezs Blanšfīlds: Jā, tas noteikti atspoguļo to, ko esmu redzējis šeit Austrālijā un ap Āzijas Kluso okeānu. Esmu pārliecināts, ka tā ir globāla lieta. Un tas ir tas, ka liela daļa galveno lēmumu pieņēmēju no sēžu zāles, visi biznesa virziena vadītāji ir tehniski daudz gudrāki - viņi lasa blogus, skatās tīmekļa seminārus, viņi Noskaņoti dažādos rakstos un aplādes veidos, viņi dodas uz pasākumiem, forumiem un sanāksmēm, un tagad viņi zina savas iespējas un zina, ka mākonis ir opcija.
Viņi arī zina, ka viņi, kā jūs teicāt, var ienest savas spējas iekšēji, un tāpēc es domāju, ka tagad ir šis interesants izaicinājums, ka ir jānotiek sarunai, kas principā ir tas, ko mēs šodien esam paveikuši tur, kur ir cilvēki, , sāciet darīt lietas iekšēji un vienkārši vadiet brūnas maisiņu pusdienas un rīkojiet iekšēju instruktāžu par to, kāds ir mūsu pašreizējais stāvoklis, kāds ir mūsu ideālais stāvoklis, kur mums vajadzētu nokļūt? Un tad, kaut kā, sanāciet to kopā.
Man bija privāta ziņa, kuru es tikai tagad ātri pieskaršos. Kāds uzdeva jautājumu: “Vai ir reāli, ka jūs varat saņemt 100 procentu pieejamību?” Un jūs, iespējams, varēsit mani labot šeit, bet es teikšu “jā”. Esmu izveidojis platformu elektroniskai naudas pārskaitīšanai, EFTPOS vārteju starp ātrām banku platformām un EFTPOS termināļiem. Es to uzcēlu 2000. gadu sākumā. Tas faktiski ir bijis tiešsaistē 100 procentus laika 17 gadus. Faktiski tas tika uzcelts pirms 2000. gadiem, taču aptuveni 2000./2001. Gadā tas ražoja.
Tātad ir pagājuši 17 gadi, sākot no izstrādes līdz testēšanai un pēc tam pārejai uz ražošanu. Šajā 17 gadu laikā ļoti zemu cenu plaša patēriņa personālie datori, kas darbojas ar atvērtā pirmkoda operētājsistēmu, bet patentētu datu bāzi, ik pēc 90 dienām veic aktīvu / pasīvu apmaiņu, izmantojot dažādus dizaina patentus, replicējot diski katrā serverī, datu replikācija starp modeļa serveriem, vairāku datu centru replikācija un pāriešana no datu centra A, kas veic ražošanu 90 dienas, un pēc tam pāriešana uz datu centru B un producēšana.
Tā kā tā pārvēršas, tā automātiski tiek ielāpēta un atjaunināta, lai atbildētu tikai uz jautājumu, ko es tikko privāti uzdevu, jā, tas ir iespējams, taču ar lielu ieguldījumu šajā projektā dizaina viedokļa. Tātad infrastruktūra patiesībā nebija tik dārga, bet, lai to iegūtu, projektēšana, testēšana un ieviešana bija ļoti dārga. Tātad, mums nevajadzēja tērēt daudz naudas aparatūrai un infrastruktūrai, bet mēs izmantojām ļoti gudrus rīkus jau dienā, kad mākonis nebija pat monētu kalšana.
Tātad, atbilde ir jā, un to var izdarīt vēl jo vairāk tagad ar mākoni, kā mēs tikko dzirdējām, ka ar peles klikšķi jūs varat iespējot šo iespēju. Es to iemetīšu Robinam, jo esmu pārliecināts, ka arī viņam ir jautājumi. Bet liels paldies par atbildēm uz maniem jautājumiem, un es šodien ļoti mīlēju dzirdēt jūsu vēstījumu. Pilnīgi uz tā visa, jo tas atspoguļo visu, ko pats esmu darījis pēdējos gandrīz 30 gadus.
Dr Robin Bloor: Nu, labi, es to paņemšu. Viena no lietām, kas mani fascinēja par jūsu prezentāciju, bija tagad pieejamo variantu skaits, kas vēl nebija pieejami, kad man kādreiz bija jācīnās ar šo lietu. Mani interesē, kurš projektēs šīs konfigurācijas vai kurš mūsdienās projektē šīs konfigurācijas? Tas, kas agrāk, vai arī pasaule, pie kuras esmu pieradis, ir tāds, ka pastāvētu diezgan smaga darījumu sistēma, un jūs interesētu augsts darbspējas laiks un augsta pieejamība. Tā kā jūs zināt, darījumu sistēma, tas būtu dārgi, ja tas jebkādā veidā pazeminātos. Un jums nebūtu visu iespēju, ko jūs tikko man parādījāt, bet tādā vai citādā veidā, izmantojot replikāciju, jūs varētu atrast veidu, kā izveidot karstu gaidstāves režīmu, kurš neuzklikšķina nemanāmi, bet gan tas sniegtu jums pazeminātu pakalpojumu, līdz jūs atgūsit.
Un es esmu tāda veida, ka skatos, ko jūs man parādījāt, un domāju par to, ka 15 gadus neesmu veicis nevienu šāda veida projektēšanas darbu, kurš to dara tagad? Vai tas, kā tas bija manā laikā, ir kaut kas tāds, ko jūs darījāt projekta sākumā, jūs zināt, ka infrastruktūra darbojas? Vai arī tas ir kaut kas pastāvīgs darbs organizācijā? Tāpēc, ka nāk līdzi jaunu tehnoloģiju izvēles iespējas.
Berts Scalzo: Lielajos uzņēmumos, kas ir ļoti efektīvi un rezultatīvi visās operācijās, ieskaitot IT, parasti viņiem būs centralizēta arhitektūras grupa vai arī viņiem būs kāds nosaukums, esmu dzirdējis, ka to sauc par “the arhitektūras grupa ”daudz reižu. Un viņu pienākums būs zināt visas šīs dažādās bildes un to, kādi ir plusi un mīnusi, un kādas ir izmaksas. Un kas notiks, kad meklēs konkrētu lietojumprogrammu un saka: “Ei, man ir jāatbilst biznesa prasībām X, Y un Z. Ei, arhitektūras komanda, kādas ir manas izvēles?”
Viņi viņiem sniegs atbildi, piemēram, šeit ir pieejami divi vai trīs, un tad tajā brīdī lēmums tiek pārvietots zemākā līmenī uz pieteikuma komandu vai pie pieteikuma biznesa sponsoru. Bet parasti tur ir centralizēta grupa, kas uzturas papildus un kurai šī informācija ir gatava un jau iepriekš izveidota.
Tagad tas ir vidējs uzņēmums, kur tas nav tik formāli. Kas parasti notiks, jūs iegūsit vienu vai divus no jūsu vecākajiem DBA vai sistēmu administratoriem, un viņi neoficiāli tiks citēti “domēna eksperti” šāda veida zināšanām. Tātad, pat vidēja lieluma uzņēmumos tas notiek, tas notiek tikai neformalizētā struktūrā.
Dr Robin Bloor: Tas tiešām ir ļoti interesanti. Manā laikā mēs nekad nedomātu par augstu pieejamību, izņemot darījumu sistēmas. Nu, mūsdienās, protams, jums ir straumēšanas sistēmas, uz kurām, iespējams, attiecas vēl lielākas prasības attiecībā uz pieejamību. Bet vai vaicājumos balstītā, back-end, analītikā, datu noliktavā, DI veida vidē jūs kādreiz redzat prasības par augstu pieejamību?
Berts Scalzo: Jā, un es priecājos, ka uzdevāt šo jautājumu. Es strādāju mazumtirdzniecības firmas labā, un viņu stratēģiskie lēmumi biznesam lielā mērā bija balstīti uz analīzi, ko viņi veiks no datu noliktavas. Patiesībā viņus intervēja žurnāls Forbes, un kompānijas izpilddirektors sacīja: “Ei, mūsu akciju cena pēdējos piecos gados pieauga par 250 procentiem, un tas ir ļoti liels iemesls, jo mēs zinām, kā efektīvi izmantot datus mūsu datu noliktavā. ”Viņi bija tik labi pieņēmuši biznesa lēmumus, ka viņiem faktiski bija datu noliktava un spēja veikt šo analītiku, spējot katru dienu pieņemt lēmumus, ņemot vērā viņu operatīvos datus, ražošanas sistēma.
Un minēšu labu piemēru, cik tas ir svarīgi. Ar šo konkrēto mazumtirdzniecības pārdevēju, puisi, kurš bija atbildīgs par alus tirdzniecību, viņš, tāpat kā, bija trešais nozīmīgākais izpilddirektors uzņēmumā, jo viņš, jūs zināt, ienesa 60, 70 procentus no ieņēmumiem. Un tāpēc viņam bija jāspēj, lai saglabātu konkurētspēju šajā tirgū, viņam bija jāprot katru dienu zināt, kādas akcijas man vajadzētu vadīt. Un, pamatojoties uz to, jūs varat zināt, ne tikai gada laikā, bet arī laikapstākļos, modeļos un citos kritiskos datos, kas var ietekmēt kaut kā alus tirdzniecību.
Dr Robin Bloor: Es domāju, ka tur noteikti būs kaut kas līdzīgs. Mēs esam novēloti, es domāju, ka man vajadzētu nodoties Ērikam, ja viņam rodas kādi jautājumi no auditorijas. Ēriks?
Ēriks Kavanagh: Jā, tas viss ir bijis lieliski, Bert. Es domāju, ka jūs izskatījāt visus jautājumus, kas mums bija uzstājušies no auditorijas jūsu prezentācijā. Bet tas ir jautri skatīties. Es priecājos, ka jūs, piemēram, runājāt par krātuves virtualizāciju un to, cik liela ietekme var būt. Tātad, tas viss ir labs.
Cilvēki, mēs visas šīs tīmekļa apraides arhivējam vēlākai apskatei. Tātad, dodieties tiešsaistē uz Techopedia.com, lai meklētu tīmekļa apraides sadaļu. Tur tiks uzskaitīti visi šie jaunākie tehniskie paņēmieni. Liels paldies mūsu draugam Bertam par viņa kompetenci. Un, protams, Dezam un Robinam. Un ar to mēs jūs atvadīsimies, ļaudis. Rūpēties. Mēs ar jums sarunāsimies nākamreiz. Labdien!
