Av Techopedia Staff, 7 december 2016
Takeaway: Värd Eric Kavanagh diskuterar tillgängligheten med Robin Bloor, Dez Blanchfield och IDERAs Bert Scalzo.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej och välkommen tillbaka igen. Klockan är östlig klockan fyra på en onsdag, och i dag kan det betyda en sak om du befinner dig i datavärlden: det är dags igen för Hot Technologies! Ja verkligen.
Jag heter Eric Kavanagh, jag kommer att vara din värd för showen. Den är utformad för att ta reda på vad som är varmt, vad som händer där ute, vad som är coola saker som används i företaget, och naturligtvis, grunden till allt vi gör i hela detta fält är databasen. Så vi kommer att prata om att skydda din databas. Det exakta ämnet är "Skydda din databas: Hög tillgänglighet för data med hög efterfrågan." Så det finns en bild om din verkligen. Och nog med mig, slå mig upp på Twitter, @eric_kavanagh.
Först, i år är heta, data är heta, big data är mycket heta, men det är verkligen fortfarande typ på kanten. Fler av de allra senaste företagen utnyttjar stora data i dag, de flesta bröd- och smörorganisationer ute i världen, de använder fortfarande traditionella data, och om dina uppgifter är mycket efterfrågade, vill du se till att de är tillgängliga eftersom när system går ner, när data är otillgängliga, det är när du får olyckliga kunder, olyckliga framtidsutsikter, du får kundkross, du blir olycklig med alla slags saker, partners etc. Så du vill inte ha det.
Vi kommer att lära oss av några av de bästa idag i branschen - vi kommer att höra från vår egen Dr. Robin Bloor, databasekspert på cirka tre decennier i rad. Dez Blanchfield, som har gjort det här lika länge, men han började när han var riktigt ung, och Bert Scalzo från IDERA, som egentligen är ganska databasens svarta bälte. Så håll inte tillbaka, folk, ställ frågor - den stora delen av denna händelse är värdefull för dig när du ställer goda frågor och får bra svar, så skicka dem via chattfönstret eller Q- och A-komponenten i din konsol.
Och med det ska jag överlämna det till Robin Bloor - ta bort det.
Dr. Robin Bloor: OK, låt mig klicka på det här och se om det rör sig - det gör det. Jag kommer inte att prata om databas särskilt. Jag trodde det, för du vet, för jag håller på med introduktionen, första introduktionspresentationen, så jag kommer att prata om de förväntade servicenivåerna och naturligtvis tillgängligheten, vilket är affären, som är ämnet för dagens show.
Och frågan är att, du vet, ”Verkligen, vad är tillgänglighet? Och vilken roll spelar det på det sättet att folk driver datacenter nuförtiden? ”En sak som jag märkte - jag märkte det faktiskt någon gång på 90-talet - jag arbetade på en webbplats och användare började klaga på eftersom deras e-post var nere för 15 minuter.
Och det var intressant eftersom CTO eller vem som var ansvarig för IT faktiskt hade, en av de få platserna där de under dessa dagar faktiskt hade fastställt servicenivåerna och e-postmeddelandet som var nere i 15 minuter inte bröt mot någons servicenivå . Jag tror att det är tillåtet att vara ute i två timmar, faktiskt. Det var inte e-postmeddelandet som inte kunde användas, det var bara att du inte kunde skicka och ta emot eftersom servern var ute. Och den typen varnade mig för det faktum att jag har märkt att jag har kommit framåt sedan dess, att allt bara påskyndas och det gör användarnas förväntningar, och detta leder dig till situationen där människor kanske har tre servicenivåer, men ofta de kommer att börja klaga när servicenivåerna inte faktiskt bryts.
Så definition av servicenivåer, bara för att ge en - ja, det kan bero exakt på vad du pratar om när det gäller servicenivåer. Vi har pratat om IT-system eller IT-applikationer. Definiera normalt i termer av prestanda, tillgänglighet och mätvärde - med andra ord, du kan inte riktigt definiera en servicenivå om du inte kan mäta den, så normalt är det någon form av mätning involverad och det handlar normalt om svarstider, specifika transaktioner och tillgängligheten för systemen under en viss tidsperiod, och före omkring 1994–1995 var det verkligen sällsynt att det krävdes några system för att vara tillgängliga under mer än normal arbetstid. Så låt oss säga åtta på morgonen till sex på kvällen, för att ge ett normalt spann - och folk byggde system och på det sättet och det betydde - i min mening, särskilt med databasen - du kan konfigurera databasen på ett visst sätt och som batchfönstret började krympa, behovet av att tänka igen började uppstå i vissa system och sedan andra system, och sedan fick vi tillkomsten av service eller arkitekturen, som började göra beroenden mellan system som inte tidigare varit beroende av varandra, vilket gör allt ännu värre. Vi fick pressen när det gäller tillgängligheten av systemen.
Poängen jag gjorde, var när jag pratade om tillgänglighet, det inkluderar säkerhetskopiering och återställning och inkluderar - det är som att det inte bara är tillgänglighet i normala termer vi pratar om; det finns många olika sätt på vilka en applikation kan misslyckas. Du vet, du kan få maskinvarufel eller så kan du få databasfel, du kan få programvarufel och det finns massor av olika arter av dessa saker, och när det inträffar måste du kunna återhämta dig och därför måste du också tillbaka upp systemen. Så det måste finnas något system för att säkerhetskopiera systemet och du, på många platser nuförtiden, behöver du katastrofåterhämtningsförmågan om en hel byggnad blåser upp. Och något som är värt att nämna här, och jag kommer att skörda med det om en minut, men affärsprocesserna, de har servicenivåer också, och faktiskt servicenivåerna i affärsprocessen som verkligen betyder för verksamheten. IT måste bara göra sin del av det och enligt vilket avtal som helst.
IT-servicenivåer är normalt dotterbolag till servicenivåer för affärsprocesser, men precis som det egentligen var ganska sällsynt för 15 år sedan för alla organisationer att ha väl definierade servicenivåer, är det fortfarande ganska sällsynt för organisationer att ha väl definierade servicenivåer för affärsprocesser . Det är något som händer typ; det är inte något som har pågått länge.
Detta är accelerations- och tidsbarriärer, det är bara värt att nämna tidsbarriärer. Vi flyttar gradvis in i en händelsehanteringsvärld och på grund av detta flyttar vi oss gradvis in i en realtidsvärld, och på grund av detta övergår vi gradvis till tillgänglighet till att krävas 24 och 7, och det är faktiskt tufft för många system - det är svårt att uppnå. Antingen är det väldigt dyrt, eller i vissa fall kanske du faktiskt måste byta system, till och med flytta till en annan databas, en annan version av databasprogramvaran vi använder.
Även dessa tidsbarriärer - och jag vill alltid nämna dessa när jag får en chans - det är tidsbarriärer som våra applikationer stöter på; applikationer kanske vill vara så snabba som möjligt, det är när programvara talar till programvara. Det finns verkligen inte någon acceptabel licens i vissa situationer, du vill vara så snabb som den kan vara, och de situationer i affärsmässiga termer som marknadssituationer, där den som kommer med en inköpsorder andra får ett sämre pris än någon som kommer först, och därför spelar programvaruhastigheten verkligen roll.
Men du vet, under det att när du faktiskt arbetar med - interagerar med - människor är den bästa responstiden som verkligen kan krävas av dig en tiondel av en sekund, för det handlar om en människas responstid. Du behöver inte gå snabbare än så eftersom en människa inte kommer att märka det i alla fall. Mellan 1, 1 och fyra sekunder är en väntetid som människor normalt tål, men så fort du går förbi cirka fyra sekunder är de av med att göra något annat, och därför är du verkligen i en gruppaktivitet.
Så du kan se att vissa tidsramar och dag, vecka och månader för de saker där ett batchbeteende är meningsfullt och därför inte befinner dig i en händelsebehandlingsvärld, och därför kan tillgängligheten faktiskt vara helt annorlunda vad gäller vad du behöver för att kunna tillhandahålla. Men så fort du befinner dig i händelsevärlden, då är du i någon tillgänglighet dygnet runt och teknikförändring är en faktor eftersom tekniken går snabbare och snabbare, då kan tillgängligheten kanske inte öka. det förblir bara som det är.
Detta är lager av komplexitet och jag vill inte gå in på detta på något djup, det är bara, du vet, det finns tre saker att tänka på här. Det finns servicenivå för infrastruktur, det här är den vertikala axeln, och sedan finns det en servicenivå för en given applikation och sedan finns det en affärsservicenivå, och de är beroende av varandra och de måste beaktas om du faktiskt tittar på att skapa en lyhörd miljö där servicenivåerna uppfylls, i princip.
Sedan har du, nere i botten här, som bara är representerade databaser, men du kan göra vad som helst i systemet, du vet att du har den nonstop-konfigurationen, vilket betyder vad det säger: det kommer aldrig att sluta. Du har den heta standby-situationen, där det på ett eller annat sätt finns olika sätt att uppnå det, men på ett eller annat sätt, om en databas misslyckas, byts den till en varm standby och det finns väldigt lite fördröjning i tidsvillkor, till den punkt där användare förmodligen skulle märka, men inte skulle märka mycket.
Varmt vänteläge liknar den 20 minuters övergången där alla ringer upp helpdesken och tikar vid helpdesken medan databasen övergår till en vänteläge. Sedan finns det en omstartssituation där det kan ta mycket lång tid. Det är värt att notera någon given applikation eller en given databas kan vara i någon av situationerna beroende på vad som faktiskt pågår och på vilken servicenivå som krävs för applikationen faktiskt är.
Från det vill jag bara göra en punkt om komplexitetskurvan. Komplexiteten härrör från noder och anslutningar, beroenden. I världen som vi lever i fortsätter antalet noder och förbindelser som är involverade i allt bara att växa, så du springer till den här typen av lämpliga kurvor. Om du kan titta på hur komplexiteten ökar och hur tidsdimensionerna krymper, vet du för tillgänglighetsnivåer, finns det tidsmål, kommer de sannolikt att minska?
Och den naturliga utvecklingen är därför mot driftstopp, vilket naturligtvis är den dyraste - åtminstone enligt min erfarenhet - det är de dyraste konfigurationerna du kan skapa. På ett eller annat sätt måste alla organisationer som tänker på detta verkligen tänka inte bara på vad som händer nu, men vad som kommer att hända i framtiden.
Kanske den sista punkten jag vill säga är att hanteringen av servicenivåerna är en pågående aktivitet; det är inte något som du vet att du har ett projekt, du gör det och det är över. Det är det inte för att saker bara fortsätter att förändras. Med det sagt kommer jag att skicka bollen till Dez.
Dez Blanchfield: Tack Robin. Jag älskar din öppningsbild. Vi har bara kört om, jag tror att det är "Finding Nemo 2", filmen. Du fick Nemo söka efter tillgänglighet i form av nio, vilket jag tyckte var ganska söt. Alltid en tuff handling att följa. När jag tänker på drifttid och tillgänglighet och hög prestanda är den första bilden som kommer att tänka på mig, eftersom jag växte upp på Salomonöarna nära vulkaner och ekvatorn, en vulkan som bryter ut i mitt datacenter; det finns den här bilden jag alltid har i mitt sinne att det är vad som potentiellt kan hända om någonting slår. Detta är en bild av den vackra Mt. Etna, som är det nordöstra hörnet av Sicilien, som ligger precis intill Catania.
Mitt förhållningssätt till detta är att ha ett samtal med dig och ge dig ett par takeaways på samma nivå som jag gör i ett styrelserum regelbundet från C-sviter och chefer för branschen med tanke på att vi har en konversation om vad som kan påverka din organisation utifrån kommersiell eller teknisk bemärkelse och typer av teknik.
Vi måste tänka på och hur - vad vi tar bort från det och hur vi går för att ta itu med några av de utmaningar som vi pratar om när vi pratar om hög tillgänglighet och drifttid, särskilt kring automatisering och plattformar.
Så frågan vi ställer inledningsvis är, vad menar vi egentligen när vi pratar om databassystem och tillgänglighet för databasplattform? Vad innebär det faktiskt att prata om den faktiska utmaningen att göra något tillgängligt till en nivå som Robin talade om i serviceavtalets installerade kartläggning av vad behöver vi faktiskt och vill?
Så, verkligheten i dag är att - och i själva verket här är ett par toppvärderingar i mitt sinne - i dag är allt effektivt databasdrivet. Det finns väldigt få system som byggs idag och byggs på ett sådant sätt att saker bara lagras i filer eller är någon form av platt fillogg; alltid är allt databasdrivet. Som ett resultat av detta har vi detta behov att sluta tänka på tillgängligheten för dessa databaser, till de olika system och applikationer och verktyg som är beroende av dem och lita på dem för att leverera de tjänster vi ser för att leverera, sälja eller konsumera . Och all infrastruktur kring den.
Faktum är att så mycket, när du tänker på de stora störningarna i data från sent, särskilt de digitala infödingarna eller molninvånarna, några av de företag som har kommit som Uber och Airbnb och så vidare, och de lite äldre PayPals och världens eBays - storleken och storleken på dessa organisationer är bara möjlig på grund av modern databasteknologi och modern molninfrastruktur. Utan det, utan den tillagda förmågan, skulle de helt enkelt inte existera. Föreställ dig ett scenario där du bara kunde komma till eBay mellan 9:05 och 9:25 eftersom det inte var tillgängligt resten av dagen eftersom det försökte göra en iCloud eller en säkerhetskopia eller något liknande, det skulle bara inte ha arbetade.
Så, och det finns andra viktiga områden när du tänker på våra dagliga liv, du vet, som detaljhandel och bank och finans och flygbolagen och så vidare. De stora industrigrupperna som flyglogistik, transportfartyg, det finns regeringen som helhet, det finns nationell säkerhet och polis och så vidare. Alla dessa branscher, alla dessa marknadssegment, alla dessa organ, grupper beror på att deras miljöer är igång.
Så med det i åtanke har vi också den andra varning som vi måste tänka på, den andra takeaway som jag vill lämna dig att tänka på, och det är att vår värld är nu det jag kallar "alltid på." Vi är permanent anslutna och detta är ett tema du kommer att höra regelbundet och jag kommer att upprepa det och upprepa det. Vi har nu smartphones i våra händer hela dagen, varje dag. Vi stänger inte av dem, vi lägger dem bredvid sängen, vi använder dem alltid som väckarklockor, vi använder dem som kameror och vi tar bilder, de skjuter bilderna upp i molnet.
De är alltid på, permanent ansluten mentalitet. I själva verket finns det en frasmynt som jag gillar att använda, och det är att vi nu liknar levande av Fitbit-generationen, där vi mäter allt, vi övervakar allt och det måste loggas och det kommer att gå någonstans.
Och det finns också en annan fras som jag ska lämna dig med, och det är klockan nio någonstans, hela tiden. Det är en 24/7/365 värld vi lever i. Jorden snurrar ständigt runt solen och vid någon tidpunkt, och tid, varje timme på dagen är klockan nio. Och det betyder att människor kommer upp ur sängen och försöker göra saker, köpa saker, installera saker etc.
Så, vad menar vi när vi pratar om hög tillgänglighet? Det låter verkligen uppenbart tills du börjar dyka in i detaljerna. Så, du vet när vi tänker på "OK, vad betyder hög tillgänglighet?" Men verkligheten är att det inte finns någon silverkula. Det är ett ganska komplicerat koncept, som Robin relaterade till med några av de ämnen han nämnde, till exempel att mäta tillgänglighet och servicenivåavtal. Vi kartlägger det till saker som jag har dessa frågor, är det drifttid? Oroar vi oss för saker som vi kallar fem nio, som jag kommer att gå in på om en minut. Anser vi oss själva med vad som finns i våra servicenivåavtal? Till exempel, i servicenivåavtal, menar jag att det finns förseningar. Förkortningen av tre bokstäver för avtal på servicenivå har blivit mer och mer kritisk i dag.
När du går igenom hela processen med lokal och självhost till outsourcad till tredjeparts datacenter och outsourcade hanterade tjänster, och nu går vi hela vägen till molnet. Och verkligheten är när du pratar om moln, det är bara andra människors datorer. Och det betyder att du inte använder infrastrukturen, du kör inte systemen och alltid kör du inte molnet. Du håller på med infrastruktur som plattform, så det är ännu viktigare i försäljningstjänsten. Föreställ dig nu försäljning till exempel, du vet att du inte rör någon av den infrastrukturen, du loggar bara in på ett webbgränssnitt.
Så, den enda mekanismen du har i den världen av moln och outsourcad infrastruktur av vilken form som helst för att kontrollera som är servicenivåavtal, det är den enda mekanismen du har, och om människor inte uppfyller din installation, då håller de antingen ut påföljder och en minskning av mängden pengar du betalar dem eller så betalar du dem inte.
Så detta kommer att tänka på hela denna utmaning, vet du, hur hanterar vi hög tillgänglighet? Hur hanterar vi tillgänglighetstiden om det inte är din infrastruktur - det handlar till exempel om SLA. Om det är din infrastruktur eller till och med om det är någon annans infrastruktur som designsynpunkt. Vi pratade om lastbalansering till modellvetenskap, är det ett patenttest för feltolerans?
Kör du aktiv aktiv eller aktiv standby i dina arkitekturer? Har du flera servrar, flera lagringsplattformar? Hur fungerar dessa lagringsplattformar? Replikerar de varandra, speglar de varandra? Kör du RAID? Vilken typ av RAID kör du för redundant lagring? Kör du RAID på diskenivå? Har du en objektlagringsplattform som replikeras mellan modeller och modeller och enheter? Är det N plus en för varje liten infrastruktur som du har? Läggar du till en annan och finns det i samma datacenter eller ett annat datacenter? Har du byggt ett designpatent som till exempel inte står för en enda försäljningsplats?
Alla dessa grundläggande saker, nu låter de som enkla begrepp, men när du går in på var och en av dessa saker är det väldigt mycket detaljerade saker. När vi pratar om tillgänglighet, slutar vi alltid att tala om niner. Och vad menar vi med nio? Vi har alla hört talas om dessa, men låt oss bara tänka på vad de betyder för en minut och varför de är viktiga.
Så vi pratar om nio, vilket är bara 90 procent av vår tillgänglighet. Jag vet att det låter väldigt högt. Så när vi pratar 24 och 7 av 365, om vi bara tittar på ett år till exempel, när vi pratar på nio, vilket är 90 procent av tiden, så möjliggör vi trettiosex och en halv dag av driftstopp per år. Låt oss bara runda det till drygt en månad.
Tänk nu på alla affärer som vi har med varje dag - oavsett om det är nätbanker, eBay, PayPal eller sociala medieplattformar som LinkedIn, Twitter eller bara en allmän återförsäljare - låt oss bara säga att jag ville boka ett flyg för att komma till USA från soligt Australien, skulle jag vara glad om jag ville komma till Amerika om en veckas tid, om mitt favoritflygbolag var nere i trettiosex och en halv dag eftersom deras tjänsteleverantör sa: "Se, vi är uppe i 90 procent av tiden "? Naturligtvis skulle jag inte göra det.
När du går upp den här modellen, två nio: 99 procent. Det blir 3, 65 dagar, ungefär tre och en halv dag driftstopp per år. Är det en stor sak? Det är väl om du kör Black Friday, och du kör en specialsäljning och människor kan bara köpa under de här par dagarna.
Tre nio blir så lite som 8, 7 timmar per år, men till och med 8, 7 timmar om året, det är i följd non-stop åtta timmar av vår tid. Det är väl inom bank och finans, inom hälsa - om det är ett sjukhus kan det kosta liv. När du klättrar upp är fyra nio 52 minuter, fem nio är fem minuter och sex nio är i princip 30 sekunder. Sex nio är extremt hög, och när du går upp denna stege, när du klättrar upp denna julgran av nio, ju mer nio du går upp, desto svårare är designen, miljön och plattformen. Ju svårare det är att leverera den tjänsten, och om du tänker på den minskade mängden tid du har för saker som säkerhetskopior som ska köras, administration, lappning, underhållsfönster för någon form av avbrott - alla icke-triviala utmaningar - och allt kommer faktiskt ner till procentuella avbrott.
Nyckeln här som jag skulle vilja förmedla är att det inte finns någon silverkula, som jag nämnde tidigare. När det gäller tillgänglighet finns det ingen "en storlek passar alla." Du kan ha en viss typ av designpatent som passar nyckelindustrin. Samma utmaningar står alla banker inför. Vissa kan vara detaljhandelsbanker, andra kan vara premiumbanker. Vissa banker kanske fokuserar på handel och investeringar, kapitalförvaltning. Vissa kan vara rent konsumenter. Vissa kanske bara placerar internet och har inte ens berättare och hanterar bara bankomater när de skickar ut kontanter. Så i dessa scenarier, till och med inom bank- och förmögenhetsförvaltnings- och finanssektorn som helhet, för varje av dem har de fortfarande sin egen speciella smak eller sak de behöver när det gäller tillgänglighet.
Så när vi funderar på tillgänglighet på vanligt engelska, blandningen mellan tillgänglighet och hög tillgänglighet - vi tror att de är samma sak, men de är faktiskt krita och ost. Tillgängligheten är, jag har satt det på vanligt engelska, en tidsmängd som en server eller process fungerar normalt eller generellt, bundet till deras användning. Det betyder bara hur vi beskriver om det är tillgängligt eller inte. När vi talar om tillgänglighet hamnar vi ofta i den här fällan att tänka, "Jag tillhandahåller det i en tillgänglig form", jämfört med hög tillgänglighet för att skydda infrastrukturen.
Hög tillgänglighet, i en annan mening på vanligt engelska, är designen där du implementerar eller uppnår någon sorts resultat och tillgänglighet av data, särskilt där nästan hela tiden - 24/7/365 dagar om året - att tillgängligheten får några av dessa nior. Alltid betyder det inte 100 procent. Hundra procent är tekniskt inte möjligt i en verklig värld i någon miljö. Det är mycket svårt för en server i ett operativsystem med en databas på, med en plattform som körs och med det en applikation kan du leverera den och förvänta sig att den ska köra 100 procent. Så då börjar vi tänka på mönster. Har vi uppsägningar, har vi flera bilder att kopiera? När du sedan sätter det på vanligt engelska är det intressant hur olika ämnet tillgänglighet kontra hög tillgänglighet blir.
Jag trodde att jag skulle sätta det i en verklig enkel grafisk form bara för att ge oss en uppfattning om hur detta ser ut när du börjar klättra upp utmaningen att öka tillgängligheten för att skydda din tjänsttid. I det nedre vänstra hörnet har vi nio. Jag har lagt fram de fem nio som vi generellt talar om. Sex nio är lite upprörande. När vi pratar om fem nio i nedre vänstra hörnet, 35 dagar ungefär det strömavbrottet, är det en miljö med låg kostnad och låg komplexitet som du försöker tillhandahålla det eftersom du har ett antal saker som kan misslyckas och du kan uppfyller fortfarande dina servicenivåavtal.
Men när du går längs botten från vänster till höger och kommer till den punkt där det finns fler nio i bilden får du scenarierna där du börjar tänka på replikering av system och plattformar. Du måste tänka på kluster och virtualisering av olika delar av infrastrukturen. Du måste tänka på geolokalisering av dessa kluster, flera webbplatser med datacenter och du måste tänka på vilken typ av industri och marknadssegment du siktar efter. Så vilken typ av servicenivå måste du uppfylla? Vilken tjänsteförsörjning letar du efter? Områden som är kortbaserade tjänster i realtid som berättar om kommunikation. Är det militära tjänster? Så den här grafen går från vänster till höger uppe och när du kommer igenom den kurvan ökar kostnaden och komplexiteten. När du får mer komplexa och mer krävande miljöer kommer du att behöva fler nio.
Denna graf gör till exempel en mycket liknande sak: den beskriver historien mellan kostnadskomponenten kontra den önskade tillgänglighetskomponenten. Så i det övre vänstra hörnet kartlägger vi mycket tillgängliga komplexa system, och kostnaden som uppstår om den tillgängligheten minskar jämfört med fördelen med att ha tillgänglighet i noll driftstopp. Så om vi till exempel har en miljö på vänster sida där saker är nere, kan vi drabbas av ekonomiska förluster. Vi har juridiska implikationer som kan vara kommersiella konsekvenser på affärsstrateginivå.
Det finns alla slags potentiella, antar jag, till och med moraliska frågor kring att ha en tjänstefördelar. Om det är en hälsoindustri och de börjar gå igenom kostnaderna för ett avbrott, påverkan på kunderna, minskning av kundtillfredsställelse, personalproduktivitet, användarproduktivitet etc. Dessa saker påverkas om vi funderar på att utforma mycket komplexa, mycket beroende, mycket riskfylld miljö där det finns potentiell risk för avbrott och därför förlust.
På höger sida försöker vi sikta till ett scenario där vi investerar i intelligent implementering om vi investerar höga kostnader och planering i design. Vi investerar i att förse människor med färdigheter och resurser och vi har mycket uppskattat nätverk och högt ansett operativ miljö och hårdvara och mjukvara. Vi får hög tillgänglighet men det kommer till en hög kostnad. Så den svängande magiska pendelplatsen med den optimala positionen i mitten där de korsar över, där vi har fått något reducerade kostnader och ökande tillgänglighet som bara jonglerar mellan nivåerna av nio och den höga tillgängligheten som är kontinuerlig tillgänglighet och detta är en en ständig utmaning för oss att möta, som i hur mycket pengar du är villig att investera för att få den servicenivå du letar efter?
Vi har också ämnet som jag inte kommer att gå i detalj på, men jag vill bara att du tar bort detta och tänker på det. Skillnaden mellan medeltiden mellan misslyckande i din design, jämfört med medelhastigheten att återhämta sig. Med andra ord, investerar du i bättre kvalitet infrastruktur, bättre kvalitet design, hårdvara och mjukvara av bättre kvalitet och bättre kvalificerad personal och resurser för att konstruera saker och minska den genomsnittliga tiden mellan misslyckande, den genomsnittliga tiden det tar att hitta pausen i motsats till att sänka investeringar i infrastruktur, i resurser och design och blinda patent, den höga kapaciteten att återhämta sig? Med andra ord, om något går sönder, har du massor av det att ansluta. Om någon har en bärbar dator och den dör, har du en extra. Du lämnar dem till dem och på 30 sekunder loggar de in. Det här är väldigt olika ändar på stången. Den bästa ger dig teknik med höga kostnader och höga investeringar för att undvika misslyckande, och den nedre säger att "Jag kommer att acceptera att misslyckande kommer att komma, så jag kommer att konstruera det och vara beredd på misslyckande och återhämtar sig snabbt. ”
Som jag nämnde tidigare, där jag kunde säga, "Min tillgänglighet är inte din tillgänglighet." Så när det gäller databasmiljöer och stöd för infrastrukturen, köra din databas och skydda det och säkerställa hög tillgänglighet, finns det verkligen ingen one-stop-shop . Alla har sina egna behov och önskemål. Så du måste ställa dig själv dessa grundläggande frågor som jag lämnar dig med, och det är: Vad har din organisation råd? Jag pratar inte bara om dollar och cent. Jag talar om, som en organisation, vad kan du från resurser, tid och ansträngning och så vidare ha råd så långt tillgänglighetsnivån kan ge? Vad kan ditt företag också stödja? Så de nuvarande kapaciteterna, de nuvarande färdigheterna, den nuvarande infrastrukturen, den nuvarande finansieringen du kan samla in. Så att jonglera mellan vad du faktiskt har råd mot vad du kan stödja är en intressant balans.
Dessutom måste du sedan ställa dig själv frågorna: Vilka färdigheter och teknik har du internt? Kan du lägga ut en del av den utmaningen? Kan du sedan flytta saker till molnet? Om du har infrastrukturtjänsten bortsett från mjukvarutjänsten, står du utan den bunten när du går längre upp i bunten. Ska du investera mer i plattformar och tjänster och inte oroa dig för infrastrukturen eller ska du se på programvara som ett tjänsteerbjudande eftersom du inte skulle behöva oroa dig för plattformen?
Vilken typ av marknad och konsument eller kund tjänar du? Jag menar, om du är en telekom och någon måste plocka upp telefonen och du får en ringsignal hela tiden, det är en mycket annorlunda utmaning att öppna en liten butik mellan måndag och fredag, nio till fem och stänga för en timme vid lunchtid som en hörn butik frisör. Så du måste tänka mycket länge och hårt hur det fungerar och vad det betyder för din organisation, vad du behöver för att kunna tillhandahålla.
Och sedan jonglret mellan det som finns i lokalerna, det som är värd externt och potentiellt, vad som finns i molnet. Som jag sa tidigare kommer det också från tidsutmaningar. Så vi är kvar till den sista frågan som jag ser fram emot våra vänner på IDERA att berätta för oss hur de hanterar just dessa saker, och det är den fina jongeln mellan att matcha önskad och önskad tillgänglighet med prestanda, och vad ditt företag behöver och vad din marknad och dina konsumenter behöver.
Och verkligheten är att det är ingen meningsfull prestation. Det kommer att ta tid, ansträngning och pengar över hela linjen att tänka på dessa saker. Och alltid är det investeringar i människor och kompetensförmåga och investeringar i programvara och verktyg för att automatisera några av dessa processer och ge dessa människor rätt verktyg och rätt system för att göra deras liv inte bara bättre, men möjligt eftersom övervakning av mycket stora miljöer och skyddande och att hantera de stora miljöerna är ofta bortom individuella mänskliga förmågor.
Med det i åtanke, så har jag förhoppningsvis skapat scenen för en bra konversation för våra vänner på IDERA att prata om deras plattform och verktyg, och jag ser fram emot att ställa några bra frågor i slutet. Och jag ska vidarebefordra.
Dr. Robin Bloor: Okej. Bert, jag gav bara nycklarna, ta bort den.
Bert Scalzo: Tack! Tack, Dez och Robin. Jag kommer att fortsätta med ämnet hög tillgänglighet för dina data. Och jag kommer faktiskt att utnyttja mycket av det Dez just pratade om. Så valen, nio, avvägningarna, överkomliga priserna. Jag kommer att försöka sätta det mer i databasadministratören eller någon närmare skyttegraven, hur skulle de se på det? Hur skulle de arkitektera det? Och vad dessa val typ betyder.
Nu ska jag försöka vara databasagnostiker. Jag tänker inte teckna till exempel en Oracle-specifik eller SQL-serverspecifik lösning, men jag tecknar, låt oss säga, en generisk arkitektur som alla databasleverantörer erbjuder, något längs dessa linjer. De kallar det alla med olika namn, men det är en typ av val som du har gemensamt, och jag vill titta på det både från affärs- och teknikperspektiv, och hur det hänför sig till företagens krav.
Och jag vill börja med vad den mest grundläggande lösningen för pseudo-hög tillgänglighet är genom de alternativ du har på lösningar på lagringsnivå, lösningar på virtualiseringsnivå och på databaslösningar. Och då vill jag också presentera det faktum att alla val finns tillgängliga i molnet också.
Så igen, jag kommer att försöka hålla mig ganska databasagnostisk. Nu, de flesta saker jag ska prata om, jag vet att de finns i Oracle, SQL Server, MySQL, PostgreSQL. Det finns också några tredjepartsleverantörer som skapar verktyg som också skulle ge dig ytterligare arkitekturer som du kan överväga. Och som Dez just sa, ingen lösning är den bästa; Allt beror på. Men det finns ett universellt faktum i det vi kommer att titta på, kommer det att bli mer rörliga delar, så det kommer att bli mer komplicerat och därför dyrare.
Så vi vet alla att data är en viktig tillgång. Och alla vet att snabb tillgång till data alltid är trevligt. Men tillförlitlig tillgång till uppgifterna är avgörande. Och när han talade om med sina nio exempel, har du verkligen råd att ha 36½ dagars driftstopp? Det är viktigt att data är tillgängliga hela tiden. Därför kan driftstopp kosta en förmögenhet, både när det gäller förlorade intäkter, men ännu viktigare, hos förlorade kunder eller förlust av kundens goodwill. Jag ska ge dig ett bra exempel; Om en viss webbplats där jag gör köp är långsam kan jag försöka hitta en ny webbplats som säljer liknande objekt till en liknande kostnad som inte har långsamma webbplatser. Och så är det inte bara kundens förlust, det är den goodwill som kunden har gentemot dig.
Nu är hårdvara mycket billigare i dag, så därför blir det mer och mer efterfrågan på hög tillgänglighet. Och igen kommer jag att leda oss till molnet, när vi tittar på det. Och vi har erbjudanden från olika nivåer: lagringsleverantörerna, databasleverantörerna, virtualiseringsleverantörerna och nu även molnleverantörerna. Och så, vad som verkligen är intressant med molnet är när jag har ritat alla dessa underbara bilder på dessa arkitekturer som du kan bygga i molnet, många gånger är det bara några kryssrutor du markerar. Och du säger: "Jag vill replikera över geografiska regioner." Kryssruta. ”Jag vill kopiera viktiga hårdvarukomponenter.” Kryssrutan. Och så, om du förstår bilderna, ibland i molnet, är det bara att markera några rutor för att skapa den bild du har i ditt sinne.
Det viktigaste är nu, vad är affärskraven för hög tillgänglighet? Måste jag till exempel bara oroa mig för fel på en enda webbplats, eller måste jag ha det på flera webbplatser? Med andra ord, kan jag ha ett datorcenter och bryr jag mig inte om att det här centret går offline? Jag ställer inte ett affärskrav om att det expanderar på flera webbplatser. Det är en affärsfråga. Och det är viktigt att veta hur företaget uppfattar svaren på den frågan, eftersom det vanligtvis definierar din budget.
Nu vill du också se ner på nivån på felskyddet. Kan det vara ett strömavbrott? Kan det vara ett komponentfel? Som en NIC eller en HBA går dåligt, en värdbussadapter. Är det en hårddisk som går dåligt? Är det ett förvaringsskåp? Är det ett datorfel? Eller är det i vissa fall ett webbplatsfel? Det är annorlunda än i vissa fall kan du ha ett webbplatsfel, eftersom själva webbplatsen är offline. I ett annat fall kan det vara så att en betydande del av webbplatsen är offline, men ur ditt perspektiv är det hela webbplatsen.
Och sedan, när Dez talade om, vad förväntas tiden för att återuppta verksamheten? Det är en affärsfråga. Om företaget säger att du måste kunna återuppta verksamheten inom två minuter är det uppenbart att det kommer att definiera några av dessa bilder som jag ska visa att du kommer att fungera, och några av dem kommer inte att vara alternativ som du kan välja.
Och en annan fråga som dyker upp under hög tillgänglighet, men ofta glömmer folk att ställa är: "Hej, affärer, om något händer medan jag är i mitten av att bearbeta en transaktion, vad får jag tappa när systemet återupptas? " Med andra ord, om jag kan föra upp systemet igen på två minuter och jag kan tappa mer än 10 sekunder av, låt oss säga, transaktioner som var under flygning, är det då acceptabelt företag? Och igen, det kommer att definiera vad verksamheten är villig att spendera för det, och sedan igen, som kan definiera vilka bilder jag ska visa dig antingen tillämpar eller inte använder.
Så låt oss börja med den mest grundläggande lösningen för pseudo-hög tillgänglighet. Det här är verkligen inte hög tillgänglighet, men jag vill börja med det, eftersom det får människor att tänka på rätt sätt. Om jag har en server och en lagringsgrupp, lägger jag vanligtvis flera NIC: er, nätverksgränssnittskort i den servern och binder dem så att om en NIC misslyckas, är jag fortfarande uppe. Och jag kommer att göra samma sak med mina värdbussadaptrar, jag kommer att flera väg som genom olika switchar, så att jag har flera sätt att komma till min lagring. Och jag har en universell strömförsörjning och jag har repetitiva styrenheter i min lagringsgrupp, och kanske har jag gjort något som RAID 10 med mina skivor. Med andra ord, i den här bilden har jag förhindrat fel i enkomponent på flera nivåer. Så jag är inte bunden av NIC, eller HBA, eller regulatorn eller omkopplaren.
Men om du märker att servern är i röd och lagringsgruppen är i röd. Jag har fortfarande två områden där om de misslyckas, om min server går, jag är död, om mitt lagringsfack går, är jag död. Så även om det inte är riktigt hög tillgänglighet börjar du se och titta på bilden och säga, "Jag vill ha en bild där det inte finns rött." Och det är verkligen målet med dessa bilder, att få oss pekade i rätt riktning.
Så det första som händer är att jag som DBA alltid vill lägga lösningen med hög tillgänglighet som en databasimplementering, men det kan vara att det är tillgängligt att det kan göras som en lagringslösning, eller så kan det vara att det kan vara en replikering på lagringsnivå. För vänster har jag lagrad virtualisering. Det som händer är att jag har RAID 0 i två olika förvaringsskåp för mina skivor, men jag har RAID 1 över de två olika förvaringsskåpen. Med andra ord, jag kan faktiskt nu ha ett förvaringsskåp misslyckas, och jag är inte död. Så det är bättre än den tidigare bilden, för i den föregående bilden - kom ihåg att vi hade både rött på servern och rött på lagringsfältet - och nu har vi gjort en liten förbättring, vi har nu inte längre rött på lagringsnivån, vi har använt - lagringsvirtualisering löste problemet.
Nu, ett annat sätt du kan göra det - och inte alla leverantörer tillhandahåller detta - är att du kanske kan göra replikering på lagringsnivå. Jag talar inte databasreplikering, jag pratar faktiskt om att replikera ditt block I / O för din lagring. Och det kan göras på lagringsnivån. Och så igen, nu har jag på höger sida, en annan bild där jag tar bort det röda från botten, för jag använder lagringsreplikering.
Och så, detta är en annan bild som kanske eller inte är tillgänglig. Och personen som skulle hantera detta kan vara din lagringsadministratör, snarare än din databasadministratör. Jag gillar att ta upp detta, för ibland tänker folk på, "Åh! Hög tillgänglighet, det måste vara DBA som hanterar detta problem." Det är inte alltid sant; det kan i detta fall vara lagringsadministratören.
Därefter kan vi göra servert virtualisering som en möjlig lösning. Om du kommer ihåg, på den första bilden hade jag rött på servern och rött på lagringsfältet. I det här fallet kan jag, med hjälp av virtualisering, kanske kunna flytta, och i vissa fall är den omlokaliseringen en varm omlokalisering, och i vissa fall kan den till och med vara en varm omlokalisering. Vissa virtualiseringar eller hypervisorer ger möjlighet att flytta en virtuell maskin under flykt. Och vissa databaser accepterar den rörelsen snabbt. Nu igen, inte alla hypervisorer tillhandahåller detta, men detta är en möjlig nivå av lösning. Nu har jag gjort att toppservern inte längre är röda, men jag har fortfarande den delade lagringsgruppen och gissa vad, den här lösningen kan vara en gemensam ansträngning mellan databasadministratören och virtualiseringsadministratören. Eller det kan till och med vara bara virtualiseringsadministratören, beroende på vilken flyttningsnivå som stöds på den hypervisorn och den databasen.
Om du undrar, "Wow, vad menar han med den här flytten? Ge mig ett specifikt exempel. ”Till exempel i VM där du kan använda VMotion för att flytta din virtuella maskin från en värd till en annan och göra det utan driftstopp. Nu är det klart att den tidigare bilden fortfarande hade något rött. Jag hade fortfarande lagringen som en enda misslyckande. Och så går vi upp till nästa lösning som är, ja, låt mig kombinera lagring och servert virtualisering.
Nu, i det här fallet, återigen, kan det vara lagringsadministratören och virtualiseringsadministratören som bygger denna lösning och ser nu ut: Jag har en bild utan rött i den. Jag har hög tillgänglighet eftersom jag kan flytta den virtuella maskinen eller den applikation eller databas som körs från en server till en annan och jag har virtualisering i min lagringsgrupp genom att låta den göra RAID 1 över två separata lagringsmatriser. Jag har multi-pathed mina switchar och mina HBA.
Så nu har jag byggt ett HA-system och jag har gjort det främst inte på databasnivå. Med andra ord har jag använt andra tekniker för att åstadkomma samma sak. Så detta är en lösning. Sedan kommer vi in på det som kallas skalbar delad lagring. Det är verkligen inte en HA-lösning, men återigen vill jag visa den för bilden.
Och vad som händer här är att vi har två servrar som kör en databas och det anses vara en databas. Det är inte två separata databaser; det är inte som en mästare och en slav, eller en varm och en förkylning, eller en aktiv och en standby. Detta är att båda dessa noder arbetar tillsammans för att presentera en logisk databas. Och så, vad som händer är, om en viss nod misslyckas, är du fortfarande uppe. Så det skyddar dig från fel på servernivå och gör det i grund och botten genom att sortera, skärpa noderesurserna, om du vill, men du har fortfarande den enda punkten för fel till botten för disken. Och så är detta ett skalbart kluster med delad lagring och Oracle kallar det här Real Application Cluster eller RAC.
En annan lösning är nu att använda ett failover-kluster med delad lagring. Så till vänster har jag en aktiv nod, till höger har jag en passiv nod, jag har ett hjärtslag mellan mig. Jag har en delad lagringsgrupp, och det är viktigt. du måste ha det. Och i princip, vad som händer är om den aktiva noden stöter på problem, kan den passiva noden ta över. Det finns licensproblem till detta. Vissa databasleverantörer låter dig ha den passiva noden med en reducerad licens under en fast tid. I andra fall måste du ha fullständig dupliceringstillstånd. Allt beror på din databasleverantör. Men alla stöder denna typ av bild, som är att om en nod går ner kan den andra noden ta över.
Och vanligtvis är detta ett av de scenarierna där det är slags, när du går från den aktiva noden till den passiva noden, kommer du förmodligen, i de flesta databaser - inte alla - du kommer att förlora några av in- flygtransaktioner. Sedan får vi reda på vad databasadministratören verkligen kan titta på, vilket är databasreplikering, och det finns två olika sätt att göra databasreplikering.
Det finns fysisk replikering, och det som är viktigt är att i mitten av den här bilden kan du se med den gröna stjärnan, att replikationen, den görs av databasen men, precis som på lagringsnivå virtualisering, det görs i blocket nivå. Så vi upprepar det faktiska blocket I / Os från den aktiva noden till den skrivskyddade eller passiva noden. Och detta anses vara fysisk replikering.
Nu, låt mig gå till nästa bild eftersom det är nästan identiskt och det är logisk replikering och det enda som ändras på bilden är att i mitten, istället för att skicka över blocket I / O, skickar vi i huvudsak loggen filer med SQL-kommandon i sig. Så, med andra ord, det vi replikerar är inte den fysiska I / O, utan kommandona som orsakar den fysiska I / O.
Och så kallas detta ofta loggfrakt eller logbaserad replikering. Vissa databasleverantörer ger dig detta naturligt. Andra databasleverantörer erbjuder kanske inte detta, men sedan erbjuder tredjepartsleverantörer det, och därför är detta en mycket populär HA-lösning och det anses vara en komplett lösning. Men denna lösning är främst DBA: s ansvar.
Så jag använder inte virtualisering för att uppnå detta. Jag kunde, men jag är inte beroende av det. Och jag använder inte lagringsvirtualisering. Återigen kunde jag det, men jag är inte beroende av det. Men jag bygger en lösning där databasen är den främsta körfunktionen. Så detta är logisk replikering.
Nu är det också möjligt att kombinera databas- och lagringsvirtualisering. Jag skulle kunna, på mitt datacenter, låt oss säga, till vänster i blått, kunna ha virtualisering för lagring så att jag inte är bunden till att en viss lagringsgrupp misslyckas. Men jag kanske gör databasnivå logbaserad eller logisk replikering från ett datacenter till det andra så att kommandona också körs i datacenter, vilket resulterar i I / O, men inte nödvändigtvis samma I / O, eftersom jag " m skickar inte över block I / O, varken med lagringslösningen eller med databasen, men jag skickar loggarna, och därför SQL-kommandona.
Och så, detta är en bild som är en mycket vanlig bild för mycket stora organisationer. Och jag gillar den här bilden här, för om jag måste ställa in det här på grundval av en databas som Oracle, kan jag göra det; det är en hel del arbete, det är ganska komplicerat, det finns massor av rörliga delar. Om jag gör detta i molnet kan jag bokstavligen bara säga, kryssrutan, jag vill ha två geografiska regioner, jag vill att regionerna är separerade av, du vet, på olika kontinenter, jag vill ha lagringsnivå virtualisering i en viss geografisk region. Jag kan till och med säga att jag vill ha möjlighet att göra allokering av virtualiseringstyp eller definition med hög tillgänglighet, och återigen är det en annan kryssruta.
Och det andra jag gillar med i molnet, det finns en annan kryssruta ofta för att säga, "Jag vill inte ta itu med, lappa det bara, " du vet, bara arbeta i arbetsflödet för allt annat du gör bakom scener, håll mig uppdaterad hela tiden. Och så, medan vissa av dessa bilder blir väldigt komplicerade och de kan vara väldigt svåra att göra på premissen, blir de faktiskt ganska enkla att göra i molnet.
Det intressanta är nu att det är lätt att markera alla kryssrutor, men gissa vad, det kostar mer pengar varje månad. För om du driver två datacenter, du vet att du har två datacenter ute i molnet som du använder, kommer du att betala mer än om du bara använder ett. På samma sätt, om du gör lagringsnivån eller virtualiseringen hög tillgänglighet som ett extra lager, kan det också bli ytterligare kostnader.
Så det är intressant att även om det är svårt att göra på webbplatsen och du kan tänka över det, i molnet är det så enkelt att göra, du kan tänka på det. Så vet alltid hur bilden ser ut och vet alltid vad kostnadsförgreningarna är för vilken bild det är som du bygger. Nu finns det många fler kombinationer än vad jag visade här. Detta är inte ett komplett eller uttömmande exempel. Det kommer ny teknik med jämna mellanrum, så vem vet - jag kanske inte har visat en som just har kommit upp under de senaste tre månaderna. Och hög tillgänglighet är mycket vanligare än för tio år sedan.
Faktum är att jag inte anser att det är en sträcka att säga att det för de flesta stora organisationer är ett obligatoriskt affärskrav idag. Och jag gillar att gå tillbaka till den här bilden eftersom jag just sa att det är ett obligatoriskt affärskrav. Och jag fick dessa två bord till höger. Den översta är i SQL Server-dokumentationen och den nedre är från Oracle-dokumentationen. Och vad det här är, det här är tabeller som hjälper dig att välja, ja, vilken replikationsmetod bör du använda.
Och märker att du börjar med några mycket enkla frågor. Hur mycket data får jag använda? Och om svaret är noll, vet du att du bara kan välja den första eller den fjärde raden i det översta diagrammet. Sedan ställer du en annan fråga. Tja, hur lång tid får jag ta för återhämtningen? Och om någon säger, ja, sekunder eller minuter, så gör det val för dig. Och då, måste misslyckandet vara automatiskt eller kräver det någon manuellt för att göra det? Och det är en annan affärsfråga. De kan säga att de vill ha det automatiskt eftersom de inte vill lita på, du vet, ett eskaleringsförfarande och sedan någon som får en biljett och sedan löser problemet. De vill bara att det ska fixas.
Det här är alla affärsfrågor och det är samma frågor om jag går ner och gör samma sak för Oracle. Och jag frågar, OK, vilken typ av misslyckande tillåter jag, vilken typ av varaktighet, vad kan jag förlora, vad är återhämtningsförfarandet? Dessa är alla affärsval, så om företaget berättar svaren på tre eller fyra frågor är mitt jobb riktigt enkelt, jag kommer bara in här, jag väljer vilken av dessa matchar de närmaste och sedan bygger jag det. Och kom ihåg att i molnet kan det bara vara några kryssrutor för att faktiskt implementera dessa.
Och med det kommer det mig till slutet av mitt material och tid att öppna detta för frågor.
Eric Kavanagh: Okej, Dez, kanske du först och sedan Robin?
Dez Blanchfield: Absolut. I själva verket, förmodligen lite orättvist för dem som inte på Twitter, men jag tweetade bara en bild av en graf som jag vill visualisera i allas sinne och sedan ville jag kasta frågan till vår lärda vän på samtalet här. När jag tänker på proprietär kontra öppen källkod i detta utrymme - vilket ofta är det vi pratar om, slags egna databaser från sådana som Oracle och Microsoft och så vidare, mot öppen källkod - hamnar du med den här utmaningen där den ägda världen internetprogramvaruförsäljaren eller mjukvaruutvecklaren eller företaget investerar i organen att bygga den komplexiteten i. Och så slutar du med ett scenario där du köper programvaran och du inte behöver investera i många människor eftersom du köper kapaciteten inbyggd och öppen källkod - du betalar inte för programvaran eller låga kostnader, låt oss säga, men du betalar inte för programvaran, men du måste investera i kropparna.
Och jag är angelägen om att få dina tankar om jonglen, särskilt nu när vi flyttar in i molnmodeller där du kan få antingen / eller. Du kan gå till AWS eller Azure och ditt Rackspace, oavsett vad, och köpa som en tjänst som tillhandahåller din databasplattform, eller så kan du göra det genom öppen källkod. Och vad vi just har pratat om, vad är jongleln mellan proprietär och open source och hur designmönstren du pratar om träder i kraft och vad är dina allmänna tankar kring detta ämne när vi går framåt, särskilt när det gäller att erbjuda tillgänglighet?
Bert Scalzo: En av de stora artiklarna som jag stöter på när jag försöker ta upp den frågan, jag går tillbaka till kunden och frågar dem om deras prestandakrav. Och anledningen till att jag gör det är att jag har funnit - åtminstone historiskt och enligt min egen erfarenhet - att när det gäller kunder som behöver hög genomströmning på sin replikering, är jag nästan alltid bättre med den replikering som tillhandahålls av databasen säljare, på grund av den natur som den är mer inbyggt och den är på en lägre nivå, och ibland använder den mekanismer som inte är tillgängliga för omvärlden, även i en open source-lösning.
Och jag ska ge dig ett bra exempel på ett fall jag hade. Jag hade ett internetbaserat företag som använde MySQL som sin databas och de var på en gammal version av MySQL, som version 4.0, och replikationen mellan deras noder var den begränsande faktorn för hur stora de kunde skala sina databaser. Och de tittade på att köpa en tredjepartslösning, sedan tittade de på: "Tja, kanske kan vi använda en av open source-lösningarna." Och vad det verkligen kokade ner till var, allt de var tvungna att göra var att uppgradera sin MySQL till version, jag tror att det var 5, 5 vi gick till, för skillnaden mellan dessa två databasversioner var i 4.0-versionen av MySQL-replikering inte gängades och i version 5.0 var det, och det var faktiskt den bästa vägen för dem.
Nu tittade vi på de andra valen, men den avgörande faktorn var prestanda och stanna hos databasleverantörslösningen, och genom att göra databasuppgraderingen blev det faktiskt vår bästa lösning för att få högsta sannolikhet för att få den prestanda de behövde för att gå med desto högre tillgänglighet.
Dez Blanchfield: Ja, det speglar mitt eget tänkande för att vara ärlig. Bara för fullständig avslöjande, och jag kommer inte att gå in på varumärken, men jag har kommit från en egen bakgrund som arbetar för OEM-apparater och programvaruförsäljare och IOC i allmänhet, och det har definitivt varit min erfarenhet och samtidigt är jag väldigt professionell -open-source och jag är en kodbidragsgivare för en massa projekt som vi inte kommer att namnge, men jag håller med dig om att om du är en stor organisation - låt oss säga att du är en bank eller vad du än kan vara - alltid vill du inte vara en IT-butik. Du vet, till exempel, om du är en tidningsförlag eller om du är en återförsäljare, du inte vill vara en IT-butik som publicerar tidningar, du vill vara en tidningsbutik som faktiskt bara utnyttjar IT.
Och att investera i de egna kapaciteterna där mjukvaruutvecklarna bygger all den förmågan, belastningsbalanseringen och så vidare, i verktyget, gör ett helvete mycket mer meningsfullt om du är en dotcom-start eller något som det kan investera i mänskliga kroppar. Vart ser du detta gå?
Förmodligen min sista fråga innan jag överlämnar till Dr. Robin Bloor, för jag vet att vi har kort tid. Var ser du detta gå ur en trendsynpunkt? Så du är där ute hela tiden, du är på den blödande kanten av saker, ser du att människor har satt sig upp och uppmärksamt och vaknat upp för att göra detta till en kommersiell del av deras dagliga till- dagssamtal tillbaka till styrelsens rum? Eller ser du fortfarande att det är väldigt den nördiga gården, teknikerna och hoodiesna och tänker på tillgänglighet eftersom det får dem att vakna klockan fyra på morgonen när något går offline?
Tror du att trenden svänger nu till organisationer i alla storlekar, inte de uppenbara som flygbolag och bank och finans, utan bara företag i allmänhet? Tror du att människor verkligen har tagit sig ur värdetillstånd för att skydda sina databasmiljöer och ge hög tillgänglighet och investera i det, eller tror du att vi fortfarande har ett sätt att gå? Vad är den allmänna känslan på marknaden där ute?
Bert Scalzo: Just nu tror jag att det fortfarande finns ett gap, men det är inte ett gap eftersom verksamheten inte begär det, det är ett gap i kommunikationsnivåerna mellan de två sidorna av staketet. Med andra ord säger affärsmän mycket tydligt, "Dessa applikationer kräver hög tillgänglighet och har dessa specifika krav när vi säger hög tillgänglighet."
Och på något eller annat sätt kommer det meddelandet inte tydligt över till teknikerna. Eller teknikerna kommer att komma tillbaka och säga, "Åh, det är komplicerat och det kommer att kosta dig mer pengar, " och det här eller det andra. Jag tror att det som kommer att hända är att det kommer att försvinna slutligen för att ärligt talat, till exempel i molnet, bara kolla några rutor här eller där för att säga, "Bygg mig den riktigt komplexa teknikstrukturen, " där verkligen ingen god anledning för teknologifolk att komma tillbaka och säga till affärsfolk, "Åh, det är dyrt" eller "Det är svårt att göra" eller så eller så, och affärsfolk börjar veta att det är faktum.
Och jag har till och med sett i miljöer där, du vet, deras egna IT-folk kommer och säger: ”Åh, du kan inte ha vad du vill. Det är för dyrt. ”Och de tar in ett tredjeparts konsultföretag som sedan kommer att säga, ” Nej, det är inte korrekt. Så här kan du göra det. Här är vad det kommer att kosta dig. ”Så jag tror att vi fortfarande har lite tid mellan kommunikationsnivåerna mellan de två sidorna innan det blir automatiskt.
Dez Blanchfield: Ja, det speglar definitivt vad jag har sett här i Australien och runt Asien och Stilla havet. Jag är säker på att det är en global sak. Och det är så att många av de viktigaste beslutsfattarna från styrelserummet ner, alla chefer inom branschen, de är "mycket mer tekniskt kunniga - de läser bloggarna, de tittar på webbseminarier, de är inställda på olika artiklar och podcast och de kommer till evenemang och forum och meetups och de vet nu sina alternativ och de vet att moln är ett alternativ.
De vet också att de kan föra det, som du sa, deras förmåga internt, och så jag tror att det finns denna intressanta utmaning nu, det samtalet som måste äga rum, vilket i princip är vad vi har gjort idag där människor, typ av, börja göra saker internt och bara köra lunchväskor med brun väska och ha en intern orientering om vad är vårt nuvarande tillstånd, vad är vårt ideala tillstånd, var måste vi komma till? Och sedan, slags, samla det.
Jag hade ett privat meddelande som jag bara kommer att snabbt beröra just nu. Någon ställde en fråga, "Är det realistiskt att du kan få 100 procent tillgänglighet?" Och du kanske kan korrigera mig här, men jag kommer att säga ja. Jag har byggt en plattform för elektronisk överföring, EFTPOS-gateway mellan snabba bankplattformar och EFTPOS-terminaler. Jag byggde detta i början av 2000-talet. Det har faktiskt varit online 100 procent av tiden i 17 år. I själva verket byggdes den före 2000-talet, men det gick produktion bara 2000/2001 ungefär.
Så de 17 åren har funnits från utveckling till testning och sedan till produktion. Under dessa 17 år har mycket billiga råvaror utanför hyllan, som driver ett öppet källkod, men en egen databas, gjort aktiv / passiv byte var 90: e dag, med olika designpatent som tillämpas, med replikering av diskar i varje server, replikering av data mellan modellservrar, replikering av flera datacenter och vändning från datacenter A som producerar under 90 dagar och sedan bläddrar till datacenter B och gör produktion.
Och när det bläddrar korrigeras och uppdateras det automatiskt så bara till den fråga som jag just fick privat, ja, det är möjligt, men med en hel del investeringar i det projektet i en designsynpunkt. Så infrastrukturen var faktiskt inte så dyr, men designen och testningen och implementeringen var mycket dyr för att få det. Så vi behövde inte spendera mycket pengar i hårdvara och infrastruktur, men vi använde väldigt smarta verktyg redan på dagen då molnet inte ens var ett mynt.
Så, svaret är ja, det kan göras, ännu mer nu med moln, som vi just hört att med ett klick på en knapp kan du aktivera den funktionen. Jag kommer att kasta det till Robin för jag är säker på att han också har frågor. Men tack så mycket för att du har svarat på mina frågor och jag älskade verkligen att höra ditt meddelande idag. Helt ombord med allt detta eftersom det speglar allt jag har gjort de senaste nästan 30 åren själv.
Dr. Robin Bloor: Tja, OK, jag ska hämta det. En av de saker som fascinerade mig för din presentation var antalet tillgängliga alternativ nu som inte var tillgängliga när jag brukade kämpa med det här. Jag är ganska intresserad av vem som ska designa dessa konfigurationer, eller vem utformar nu dessa konfigurationer? Det som brukade hända, eller världen som jag är van vid, är att det skulle finnas ett ganska tungt transaktionssystem och du skulle vara intresserad av hög drifttid, hög tillgänglighet. Eftersom, du vet, transaktionssystemet, skulle det vara dyrt om det skulle gå ner på något sätt. Och du skulle inte ha alla alternativen som du just har presenterat för mig, men på ett eller annat sätt kan du hitta ett sätt, via replikering mestadels, att skapa en varm standby som inte skulle klicka på obemärkt, men det skulle ge dig en försämrad tjänst tills du kom tillbaka.
Och jag tittar på vad du visade mig och tänkte på det, har inte gjort något av den typen av designarbete i 15 år, vem gör det nu? Är det, som det var på min dag, något som du gjorde i början av ett projekt, vet du, får infrastrukturen igång? Eller är det något som är en pågående verksamhet inom en organisation? För det finns nya teknikval som följer.
Bert Scalzo: I de stora företagen som är mycket effektiva och effektiva i alla sina verksamheter, inklusive deras IT, kommer de vanligtvis att ha en centraliserad arkitekturgrupp, eller så kommer de att ha något namn på det, jag har hört det kallas "the arkitekturgrupp ”många gånger. Och det kommer att vara deras ansvar att veta alla dessa olika bilder och vad fördelar och nackdelar är och vad kostnaderna är. Och vad som kommer att hända är att när en viss applikation tittar och säger: "Hej, jag måste uppfylla affärskraven X, Y och Z. Hej, arkitekturteam, vad är mina val?"
De kommer att ge dem svaret, här är de två eller tre som finns tillgängliga, och då flyttar beslutet tillbaka till den lägre nivån till applikationsteamet eller till företagens sponsor för applikationen. Men vanligtvis finns det en centraliserad grupp som håller sig ovanpå detta och har den informationen redo och förbyggd.
Nu är det de medelstora företagen där det inte är så formellt. Det som tenderar att hända är att du får en eller två av dina äldre DBA eller systemadministratörer och de kommer informellt att citera "domänsexperten" för den typen av expertis. Så även i de medelstora företagen händer det bara i en icke-formaliserad struktur.
Dr. Robin Bloor: Det är verkligen intressant. På min dag skulle vi aldrig tänka på hög tillgänglighet utom för transaktionssystemen. Tja, nuförtiden har du naturligtvis strömningssystem som förmodligen är föremål för ännu större krav när det gäller tillgänglighet. Men i frågeformuläret, back-end, analys, datalager, DI typ av miljö, ser du någonsin krav på hög tillgänglighet där?
Bert Scalzo: Ja, och jag är glad att du ställde den frågan. Jag gjorde lite arbete för ett detaljhandelsföretag och deras strategiska beslut för verksamheten baserades till stor del på den analys de skulle göra från datalageret. Och faktiskt intervjuades de av Forbes Magazine och VD för företaget sa: "Hej, vårt aktiekurs ökade 250 procent under de senaste fem åren och en mycket stor anledning som är sant är att vi vet hur vi effektivt kan utnyttja våra uppgifter i vårt datalager. ”De var så bra på att fatta affärsbeslut att för dem, datalageret och att kunna göra dessa analyser, att kunna fatta beslut på daglig basis mot deras operativa data, faktiskt var för dem, ett produktionssystem.
Och jag ska ge dig ett bra exempel på hur viktigt det är. Med just denna detaljhandelsförsäljare, killen som var ansvarig för ölförsäljningen, var han, liksom, den tredje viktigaste verkställande direktören i företaget, för han förde in, du vet, 60, 70 procent av intäkterna. Och så var han tvungen att kunna för att hålla sig konkurrenskraftig på den marknaden måste han kunna veta varje dag, du vet, vilka kampanjer som jag skulle köra. Och det kan baseras på, du vet, inte bara tiden på året, men väder, mönster och andra kritiska data som kan påverka försäljningen av något som öl.
Dr. Robin Bloor: Jag antar att det verkligen kommer att finnas sådana saker. Vi är lite för tidiga, jag tror att jag borde överlämna till Eric om han får några frågor från publiken. Eric?
Eric Kavanagh: Ja, det här har varit fantastiska grejer, Bert. Jag tror att du adresserade alla frågor som vi hade från publiken i din presentation. Men det är kul att titta på. Jag är glad att du, typ av, pratade om lagringsvirtualisering och hur mycket av en inverkan som kan vara. Så det här är allt bra grejer.
Tja, folk, vi arkiverar alla dessa webbsändningar för senare visning. Så hopp online till Techopedia.com för att leta efter avsnittet webcast. Alla dessa hottekniker listas där. Ett stort tack till vår vän Bert för hans expertis. Och naturligtvis till Dez och Robin. Och med det kommer vi att hälsa dig, folkens. Ta hand om dig. Vi pratar med dig nästa gång. Hejdå.
