Door Techopedia Staff, 7 december 2016
Afhaalmaaltijd: gastheer Eric Kavanagh bespreekt beschikbaarheid met Robin Bloor, Dez Blanchfield en IDERA's Bert Scalzo.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Dames en heren, hallo en welkom weer terug. Het is woensdag om vier uur Eastern Time en tegenwoordig kan dat ongeveer één ding betekenen als je in de wereld van data bent: het is weer tijd voor Hot Technologies! Ja inderdaad.
Mijn naam is Eric Kavanagh, ik zal je gastheer zijn voor de show. Het is ontworpen om erachter te komen wat hot is, wat er daar gebeurt, wat de coole dingen zijn die in de onderneming worden gebruikt, en natuurlijk, precies aan de basis van alles wat we op dit hele gebied doen, is de database. Dus we gaan het hebben over het beschermen van uw database. Het exacte onderwerp is: "Bescherm uw database: hoge beschikbaarheid voor veeleisende gegevens." Er is dus echt een dia over de uwe. En, genoeg over mij, sla me op Twitter, @eric_kavanagh.
Ten eerste is dit jaar hot, data is hot, big data is erg hot, maar het is echt nog steeds een beetje op het randje. Meer van de meest geavanceerde bedrijven maken tegenwoordig gebruik van big data, de meeste brood- en boterorganisaties ter wereld, ze gebruiken nog steeds traditionele data, en als er veel vraag is naar je data, wil je ervoor zorgen dat deze beschikbaar is omdat wanneer systemen uitvallen, wanneer gegevens ontoegankelijk zijn, dan krijg je ongelukkige klanten, ongelukkige prospects, krijg je klantverloop, krijg je ongelukkig allerlei dingen, partners, enz. Dus dat wil je niet.
We gaan vandaag leren van enkele van de beste in de branche - we horen het van onze eigen Dr. Robin Bloor, database-expert van ongeveer drie decennia op rij. Dez Blanchfield, die dit al zo lang doet, maar hij begon toen hij nog heel jong was, en Bert Scalzo van IDERA, die echt behoorlijk de database black belt is. Dus houd je niet in, mensen, stel vragen - het grootste deel van dit evenement is waardevol voor jou als je goede vragen stelt en goede antwoorden krijgt, dus stuur ze via het chatvenster of de Q & A-component van je console.
En daarmee ga ik het overhandigen aan Robin Bloor - haal het weg.
Dr. Robin Bloor: OK, laat me hierop klikken en kijken of het beweegt - het doet het. Ik ga het vooral niet over de database hebben. Ik dacht dat, weet je, omdat ik de intro, eerste introductiepresentatie doe, dus ik zal praten over de verwachte serviceniveaus en natuurlijk beschikbaarheid, wat de deal is, die het onderwerp is van de show van vandaag.
En de vraag is, weet je, "Echt, wat is beschikbaarheid?" En welke rol speelt het in de manier waarop mensen tegenwoordig datacenters runnen? ”Eén ding dat me opviel - ik merkte dit eigenlijk ergens in de jaren '90 - ik werkte op één site en gebruikers begonnen te klagen omdat hun e-mail niet beschikbaar was 15 minuten.
En het was interessant omdat de CTO of degene die verantwoordelijk was voor IT eigenlijk een van de weinige plaatsen was waar ze in die dagen daadwerkelijk de serviceniveaus hadden bepaald en de e-mail die 15 minuten niet beschikbaar was, in strijd was met iemands serviceniveau . Ik denk dat het eigenlijk twee uur buiten mag zijn. Het was niet dat de e-mail niet kon worden gebruikt, het was alleen dat je niet kon verzenden en ontvangen omdat de server uit was. En dat soort waarschuwde me voor het feit dat ik sindsdien heb gemerkt dat alles sneller gaat en ook de verwachtingen van de gebruikers, en dit leidt je tot de situatie waarin mensen misschien drie serviceniveaus hebben, maar vaak begint te klagen wanneer de serviceniveaus niet daadwerkelijk worden geschonden.
Dus definitie van serviceniveaus, gewoon om een - nou ja, het kan precies afhangen van waar je het over hebt in termen van serviceniveaus. We hebben gesproken over IT-systeem of IT-applicatie. Normaal gesproken definiëren in termen van prestaties, beschikbaarheid en metriek - met andere woorden, je kunt een serviceniveau niet echt definiëren tenzij je het kunt meten, dus normaal gesproken is er een soort meting bij betrokken en gaat het normaal gesproken over responstijden, bepaalde transacties en de beschikbaarheid van de systemen gedurende een bepaalde periode, en vóór ongeveer 1994-1995, was het echt zeldzaam dat systemen langer dan normale werkuren beschikbaar moesten zijn. Dus laten we zeggen acht uur 's ochtends tot zes uur' s avonds, om een normale overspanning te geven - en mensen bouwden systemen en op die manier en dat betekende - in mijn gedachten, met name met de database - dat je de database op een bepaalde manier kon configureren en als het batchvenster begon te krimpen, de behoefte om opnieuw te denken ontstond in sommige systemen en vervolgens in andere systemen, en toen kregen we de komst van service of de architectuur, die afhankelijkheden begon te maken tussen systemen die voorheen niet afhankelijk waren elkaar, waardoor alles nog erger wordt. We kregen de druk wat betreft de beschikbaarheid van de systemen.
Het punt dat ik aan het maken was, was wanneer het over beschikbaarheid ging, het omvat back-up en herstel en omvat - het is alsof het niet alleen beschikbaarheid is in de normale termen waar we het over hebben; er zijn veel verschillende manieren waarop een toepassing kan mislukken. Weet je, je kunt hardwarefalen krijgen of je kunt de database falen, je kunt softwarefouten krijgen en er zijn veel verschillende soorten van die dingen, en wanneer het gebeurt moet je kunnen herstellen en daarom moet je ook terug de systemen op. Er moet dus een schema zijn voor het maken van een back-up van het systeem en u hebt tegenwoordig ook op veel sites de mogelijkheid voor noodherstel nodig voor het geval een heel gebouw ontploft. En iets dat het vermelden waard is, en ik ga er zo meteen over beginnen, maar de bedrijfsprocessen hebben ook serviceniveaus en in feite de serviceniveaus van het bedrijfsproces die er echt toe doen voor het bedrijf. IT moet er gewoon zijn deel van doen en volgens welke overeenkomst dan ook.
IT-serviceniveaus zijn normaal gesproken ondergeschikt aan serviceniveaus van bedrijfsprocessen, maar net zoals het 15 jaar geleden echt vrij zeldzaam was voor organisaties met goed gedefinieerde serviceniveaus, is het nog steeds vrij zeldzaam voor organisaties om goed gedefinieerde serviceniveaus voor bedrijfsprocessen te hebben . Dat is iets wat nu gebeurt; het is niet iets dat al lang aan de gang is.
Dit zijn de versnellings- en tijdbelemmeringen, het is gewoon de moeite waard om tijdbelemmeringen te vermelden. We gaan geleidelijk over naar een wereld voor het verwerken van evenementen en daarom gaan we geleidelijk over naar een realtime wereld, en daarom gaan we geleidelijk over tot 24 uur per dag beschikbaarheid en dat is eigenlijk moeilijk voor veel systemen - het is moeilijk te bereiken. Het is ofwel erg duur, of in sommige gevallen moet u misschien de systemen veranderen, zelfs naar een andere database gaan, een andere versie van de databasesoftware die we gebruiken.
Ook deze tijdbarrières - en ik wil deze altijd vermelden wanneer ik de kans krijg - dit zijn tijdbarrières waar onze applicaties tegenaan lopen; applicaties willen misschien zo snel mogelijk zijn, dan spreekt software tegen software. Er is echt geen acceptabele licentie in sommige situaties, je wilt zo snel zijn als het kan zijn, en die situaties in de zakelijke termen zoals marktsituaties, waar de persoon die met de kooporder komt, een slechtere prijs krijgt dan iemand die op de eerste plaats komt, en daarom is de softwaresnelheid echt belangrijk.
Maar weet je, hieronder dat wanneer je te maken hebt met - interactie met - menselijke wezens, de beste responstijd die echt van je kan worden geëist een tiende van een seconde is, want dat is ongeveer de responstijd van een mens. Je hoeft niet sneller te gaan dan dat, want een mens zal het toch niet merken. Tussen 1, 1 en vier seconden is een wachttijd die mensen normaal zullen tolereren, maar zodra je voorbij vier seconden gaat, zijn ze op weg om iets anders te doen, en daarom ben je echt in een batchactiviteit.
U kunt dus zien dat bepaalde tijdframes en dag, week en maanden voor die dingen waar een batchgedrag zinvol is en u zich dus niet in een wereld voor gebeurtenisverwerking bevindt, en daarom kan de beschikbaarheid eigenlijk heel anders zijn wat betreft wat u nodig hebt kunnen bieden. Maar zodra je in de evenementenwereld bent, ben je 24/7 beschikbaar en is technologieverandering een factor, omdat technologie sneller en sneller gaat, dan zal de beschikbaarheid mogelijk niet toenemen; het blijft gewoon zoals het is.
Dit zijn lagen van complexiteit en ik wil hier niet verder op ingaan, het is gewoon, weet je, er zijn hier drie dingen om te overwegen. Er is een serviceniveau van infrastructuur, dit is de verticale as, en dan is er een serviceniveau van een bepaalde applicatie en dan is er een zakelijk serviceniveau, en die zijn van elkaar afhankelijk en ze moeten in overweging worden genomen als u eigenlijk op zoek bent naar een responsieve omgeving waarin in feite serviceniveaus worden bereikt.
Dan hebt u, onderaan hier, die alleen maar databases zijn, maar u kunt alles doen binnen het systeem, u weet dat u de non-stop configuratie hebt, wat betekent wat het zegt: het zal nooit stoppen. Je hebt de hot standby-situatie, waarbij er op de een of andere manier verschillende manieren zijn om dit te bereiken, maar op een of andere manier, als een database faalt, wordt deze overgeschakeld naar een hot standby en is er weinig vertraging in termen van tijd, tot het punt waar gebruikers waarschijnlijk zouden opmerken, maar niet veel zouden opmerken.
Warme standby lijkt meer op de omschakeling van 20 minuten waarbij iedereen de helpdesk belt en teven aan de helpdesk terwijl de database wordt overgeschakeld naar een standby-modus. Dan is er een rebootsituatie waarbij het erg lang kan duren. Het is vermeldenswaard dat een bepaalde toepassing of een gegeven database zich in een van de situaties bevindt, afhankelijk van wat er feitelijk aan de hand is en wat het vereiste serviceniveau van de toepassing is.
Van daaruit wil ik alleen iets zeggen over de complexiteitscurve. De complexiteit komt voort uit knooppunten en verbindingen, de afhankelijkheden. In de wereld waarin we leven, blijft het aantal knooppunten en verbindingen dat bij alles betrokken is, gewoon groeien, dus je rent naar dit soort opportunistische bochten. Als je kunt kijken naar de manier waarop complexiteit toeneemt en de manier waarop tijddimensies krimpen, weet je wat beschikbaarheidsniveaus zijn, zijn er tijddoelen, zullen ze waarschijnlijk verminderen?
En de natuurlijke evolutie is daarom gericht op non-stop werking, wat natuurlijk de duurste is - althans in mijn ervaring - het zijn de duurste configuraties die u kunt maken. Op de een of andere manier moet elke organisatie die hierover nadenkt, niet alleen nadenken over wat er nu gebeurt, maar over wat er in de toekomst gaat gebeuren.
Misschien is het laatste punt dat ik wil maken, het beheer van serviceniveaus een voortdurende activiteit is; het is niet iets waarvan je weet dat je een project hebt, je doet het en het is voorbij. Dat is het niet, omdat dingen gewoon blijven veranderen. Dat gezegd hebbende, zal ik de bal doorgeven aan Dez.
Dez Blanchfield: Bedankt Robin. Ik hou van je openingsdia. We hebben net de herhaling gehad van, ik denk dat het "Finding Nemo 2" is, de film. Je had Nemo op zoek naar beschikbaarheid in de vorm van negens, wat ik best schattig vond. Altijd een moeilijke daad om te volgen. Als ik denk aan uptime en beschikbaarheid en hoge prestaties, is het eerste beeld dat in me opkomt, omdat ik opgroeide op de Salomonseilanden in de buurt van vulkanen en de evenaar, een vulkaan die uitbarst in mijn datacenter; er is een beeld dat ik altijd in gedachten heb dat dat mogelijk zou kunnen gebeuren als er iets knalt. Dit is een foto van de mooie Mt. Etna, dat is de noordoostelijke hoek van Sicilië, dat pal naast Catania ligt.
Mijn benadering hiervan is om een gesprek met je te hebben en je een aantal afhaalrestaurants te geven op hetzelfde niveau als ik regelmatig in een bestuurskamer vanuit C-suites en de bedrijfsleiders met het oog op een gesprek over wat een impact kan hebben op uw organisatie vanuit commercieel of technisch oogpunt en de soorten engineering.
We moeten nadenken over en hoe - wat we daarvan afnemen, en hoe we vervolgens enkele van de uitdagingen aanpakken waar we het over hebben als we het hebben over hoge beschikbaarheid en uptime, met name rond automatisering en platforms.
Dus de vraag die we in eerste instantie stellen is, wat bedoelen we eigenlijk als we het hebben over databasesystemen en beschikbaarheid van databaseplatforms? Wat betekent het eigenlijk om te praten over de werkelijke uitdaging om iets beschikbaar te maken voor een niveau waar Robin het over had in de geïnstalleerde mapping van een serviceniveau-overeenkomst van wat we eigenlijk nodig hebben en willen?
Dus de realiteit van vandaag is dat - en in feite zijn hier een paar piek realiteiten in mijn gedachten - vandaag alles effectief database-gestuurd is. Er zijn zeer weinig systemen die tegenwoordig zijn gebouwd en zo zijn gebouwd dat dingen gewoon in bestanden worden opgeslagen of een soort plat bestandslogboek zijn; steevast is alles database-gestuurd. Als gevolg daarvan hebben we de behoefte om niet langer na te denken over de beschikbaarheid voor die databases, voor de verschillende systemen en applicaties en tools die ervan afhankelijk zijn en erop te vertrouwen dat we de diensten leveren die we willen leveren, verkopen of consumeren. . En alle infrastructuur eromheen.
Sterker nog, als je denkt aan de grote verstoringen van gegevens van de laatste tijd, met name de digitale inboorlingen of cloud inboorlingen, sommige van de bedrijven die zijn meegekomen zoals Uber en Airbnb, enzovoort, en de iets oudere PayPals en de eBays van de wereld - de schaal en grootte van die organisaties is alleen mogelijk vanwege moderne databasetechnologie en moderne cloudinfrastructuur. Zonder dat, zonder de toegevoegde mogelijkheid, zouden ze gewoon zeker niet bestaan. Stel je een scenario voor waarin je alleen tussen 9:05 en 9:25 naar eBay kon komen omdat het de rest van de dag niet beschikbaar was omdat het probeerde een iCloud of een back-up of iets dergelijks te maken, het zou gewoon niet werkte.
Dus, en er zijn andere belangrijke gebieden als u denkt aan ons dagelijks leven, weet u, zoals retail en bankieren en financiën en de luchtvaartmaatschappijen enzovoort. De grote industriegroepen zoals luchtvaartlogistiek, transportvaart, er is de overheid als geheel, er is nationale veiligheid en politie enzovoort. Al deze industrieën, al deze marktsegmenten, al deze instanties, groepen zijn afhankelijk van het feit of hun omgeving actief is.
Dus, met dat in gedachten, hebben we ook het andere voorbehoud waar we aan moeten denken, het andere afhaalrestaurant waar ik je aan wil laten denken, en dat is dat onze wereld nu is wat ik "altijd aan" noem. We zijn permanent verbonden en dit thema zul je regelmatig horen en ik ga het herhalen en herhalen. We hebben nu de hele dag smartphones in onze handen. We zetten ze niet uit, we leggen ze naast het bed, we gebruiken ze steevast als wekkers, we gebruiken ze als camera's en we nemen foto's, ze duwen die foto's tegen de wolk in.
Ze zijn altijd aan, permanent verbonden mentaliteit. In feite is er een zinsnede die ik graag gebruik, en dat is dat we nu een soort van de Fitbit-generatie leven, waar we alles meten, alles monitoren en het moet worden geregistreerd en dat gaat ergens heen.
En er is ook nog een andere zin waarmee ik je zal verlaten, en dat is, het is altijd ergens om negen uur. Het is een 24/7/365 wereld waarin we leven. De aarde draait constant rond de zon en op een bepaald moment en op elk tijdstip van de dag is het negen uur. En dat betekent dat mensen uit bed komen en dingen proberen te doen, dingen kopen, dingen installeren, enz.
Dus wat bedoelen we als we het hebben over hoge beschikbaarheid? Nou, het klinkt echt voor de hand liggend totdat je in het detail duikt. Dus u weet wanneer we denken aan "OK, wat betekent hoge beschikbaarheid?" Nou, de realiteit is dat er geen zilveren kogel is. Het is een vrij complex concept, zoals Robin verband hield met enkele van de onderwerpen die hij noemde, zoals het meten van beschikbaarheid en service level agreements. We brengen het in kaart, zoals: Ik heb deze vragen, is het uptime? Maken we ons zorgen over dingen als wat we vijf negens noemen, waar ik zo meteen op in zal gaan. Overwegen we onszelf met wat er in onze service level agreements staat? In serviceniveau-overeenkomsten bedoel ik bijvoorbeeld dat er vertragingen zijn, het drieletterige acroniem voor serviceniveau-overeenkomsten is tegenwoordig steeds kritischer geworden.
Terwijl u dit hele proces van on-premise en self-hosted door outsourcing naar datacenters van derden en uitbestede beheerde services doorloopt, gaan we nu helemaal naar de cloud. En de realiteit is dat wanneer je het hebt over cloud, het gewoon computers van anderen zijn. En dat betekent dat u de infrastructuur niet beheert, de systemen niet uitvoert en steevast de cloud niet. U doet infrastructuur die is opgezet als het platform, dus het is nog belangrijker in de verkoopafdeling. Stel je bijvoorbeeld eens voor dat je verkoop weet, je weet dat je die infrastructuur niet aanraakt, je logt gewoon in op een webinterface.
Het enige mechanisme dat u in die wereld van cloud en uitbestede infrastructuur in welke vorm dan ook hebt, is het enige mechanisme dat u hebt, en als mensen uw installatie niet ontmoeten, verdragen ze boetes en een vermindering van de hoeveelheid geld die u betaalt of u betaalt ze gewoon niet.
Dit herinnert ons dus aan deze hele uitdaging van, weet u, hoe kunnen we hoge beschikbaarheid beheren? Hoe beheren we beschikbaarheid van uptime als het niet uw infrastructuur is - het draait bijvoorbeeld allemaal om SLA. Als het uw infrastructuur is of zelfs als het de infrastructuur van iemand anders is als een ontwerpstandpunt. We hebben het gehad over load balancing naar de modelwetenschap, is het een patent op fouttolerantieontwerp?
Heeft u actieve actief of actieve stand-by in uw architecturen? Heeft u meerdere servers, meerdere opslagplatforms? Hoe werken die opslagplatforms? Repliceren ze elkaar, spiegelen ze elkaar? Gebruik je RAID? Welk type RAID gebruikt u voor redundante opslag? Gebruikt u RAID op schijfniveau? Gebruikt u een objectopslagplatform dat repliceert over modelstations en modelsystemen en schijven? Is het N plus één voor elk stukje infrastructuur dat je hebt? Voegt u nog een toe en bevindt deze zich in hetzelfde datacenter of een ander datacenter? Hebt u een ontwerppatent gebouwd dat bijvoorbeeld geen enkel verkooppunt vertegenwoordigt?
Al deze fundamentele dingen, nu klinken ze als eenvoudige concepten, maar als je op elk van deze dingen ingaat, zijn het zeer, zeer gedetailleerde dingen. Als we het hebben over beschikbaarheid, praten we steevast over negens. En wat bedoelen we met negens? We hebben er allemaal over gehoord, maar laten we even nadenken over wat ze betekenen en waarom ze belangrijk zijn.
We praten dus over een negen, dat is slechts 90 procent van onze beschikbaarheid. Ik weet dat dat heel hoog klinkt. Dus als we 24 bij 7 bij 365 praten, als we bijvoorbeeld naar één jaar kijken, als we praten over één negen, wat 90 procent van de tijd is, dan is dat zesendertig en een halve dag downtime per jaar. Laten we dat afronden tot iets meer dan een maand.
Denk nu aan elk bedrijf waarmee we elke dag te maken hebben - of het nu gaat om online bankieren, eBay, PayPal of sociale mediaplatforms zoals LinkedIn, Twitter of gewoon een algemene retailer - laten we zeggen dat ik een zonnige vlucht naar de VS wilde boeken Australië, zou ik blij zijn als ik over een week naar Amerika wilde komen, als mijn favoriete luchtvaartmaatschappij zesendertig en een halve dag in de lucht was omdat hun dienstverlener zei: "Kijk, we zijn 90 procent van de tijd op "? Natuurlijk zou ik dat niet doen.
Terwijl je dit model omhoog gaat, twee negens: 99 procent. Welnu, dat wordt 3, 65 dagen, ongeveer drieënhalve dag downtime per jaar. Is dat een probleem? Nou, het is als je Black Friday runt, en je hebt een speciale aanbieding en mensen kunnen alleen kopen gedurende die paar dagen.
Drie negens worden slechts 8, 7 uur per jaar, maar zelfs 8, 7 uur per jaar, dat is achtereenvolgende acht uur achtereen van onze tijd. Welnu, in bankieren en financieren, in gezondheid - als het een ziekenhuis is, zou dat levens kunnen kosten. Terwijl je omhoog klimt, is vier negens 52 minuten, vijf negens vijf minuten en zes negens is in principe 30 seconden. Zes negens is extreem hoog, en als je deze ladder op gaat, terwijl je deze kerstboom van negens beklimt, hoe meer negens je omhoog gaat, hoe moeilijker het ontwerp, de omgeving en het platform. Hoe moeilijker het is om die service te leveren, en als je nadenkt over de vermindering van de hoeveelheid tijd die je hebt voor het uitvoeren van back-ups, administratie, patchen, onderhoudsvensters voor elke vorm van uitval - allemaal niet-triviale uitdagingen - en het komt allemaal neer op percentages uitval.
De sleutel die ik hier wil overbrengen, is dat er geen zilveren kogel is, zoals ik al eerder zei. Als het gaat om beschikbaarheid, is er geen 'one size fits all'. U heeft misschien een bepaald type ontwerpoctrooi dat bij belangrijke industrieën past. Alle banken staan voor dezelfde uitdagingen. Sommige kunnen retailbanken zijn, sommige premium banken. Sommige banken richten zich misschien op handel en investeringen, vermogensbeheer. Sommigen zijn misschien puur consument. Sommigen kunnen alleen internet plaatsen en hebben zelfs geen tellers en behandelen alleen geldautomaten bij het uitgeven van contant geld. Dus in die scenario's, zelfs in het bank- en vermogensbeheer en de financiële dienstverlening als geheel, hebben ze voor elk van hen nog steeds hun eigen specifieke smaak of ding dat ze nodig hebben als het gaat om beschikbaarheid.
Dus als we denken aan beschikbaarheid in gewoon Engels, de mix tussen beschikbaarheid en hoge beschikbaarheid - we denken dat ze hetzelfde zijn, maar ze zijn eigenlijk krijt en kaas. Beschikbaarheid is, ik heb het in gewoon Engels gezegd, een maat voor de tijd dat een server of proces normaal of in het algemeen functioneert, afhankelijk van hun gebruik. Dat betekent gewoon hoe we beschrijven of het beschikbaar is of niet. Als we het hebben over beschikbaarheid, vallen we vaak in de val van het denken: 'Ik bied het in een beschikbare vorm', versus hoge beschikbaarheid bij het beschermen van de beveiliging van die infrastructuur.
Hoge beschikbaarheid, in andere zin in gewoon Engels, is het ontwerp waarbij u een soort uitkomst en beschikbaarheid van gegevens implementeert of bereikt, met name waar bijna altijd - 24/7/365 dagen per jaar - die beschikbaarheid een aantal van die bereikt negens. Het betekent steevast niet 100 procent. Honderd procent is technisch niet mogelijk in een echte wereld in één omgeving. Het is heel moeilijk voor één server in een besturingssysteem met een database erop, waarop een platform draait en waarop een applicatie u deze kan leveren en verwachten dat het 100 procent draait. Dus dan gaan we nadenken over ontwerpen. Hebben we ontslagen, moeten we meerdere dia's repliceren? Als je het dan in gewoon Engels zet, is het interessant hoe anders het onderwerp beschikbaarheid wordt vergeleken met hoge beschikbaarheid.
Ik dacht dat ik het in een heel eenvoudige grafische vorm zou zetten, gewoon om ons een idee te geven van hoe dit eruitziet als u de uitdaging aangaat om de beschikbaarheid te verhogen in het beschermen van de uptime van uw service. In de linkeronderhoek hebben we een enkele negen. Ik heb de vijf negens uiteengezet waar we het over het algemeen over hebben. Zes negens is een beetje schandalig. Als we het hebben over vijf negens in de linkerbenedenhoek, 35 dagen ruwweg die storing, is het een goedkope en weinig complexe omgeving die je probeert te bieden omdat je een aantal dingen hebt die kunnen mislukken en je kunt nog steeds voldoen aan uw service level agreements.
Maar als je van links naar rechts langs de onderkant gaat en je komt op het punt dat er meer negens in beeld zijn, krijg je de scenario's waarin je begint na te denken over replicatie van systemen en platforms. Je moet nadenken over clustering en virtualisatie van verschillende delen van de infrastructuur. U moet nadenken over de geolocatie van die clusters, meerdere datacentersites en u moet nadenken over het type industrie en het marktsegment dat u nastreeft. Aan welk type serviceniveau moet u voldoen? Welke dienstverlening zoekt u? Gebieden die realtime op kaarten gebaseerde services zijn die vertellen over communicatie. Zijn het militaire diensten? Dus deze grafiek gaat van linksonder naar rechtsboven en als je die curve doorloopt, nemen de kosten en complexiteit toe. Naarmate je complexere en veeleisendere omgevingen krijgt, heb je meer negens nodig.
Deze grafiek doet bijvoorbeeld iets soortgelijks: het beschrijft het verhaal tussen de kostencomponent versus de gewenste beschikbaarheidscomponent. Dus in de linkerbovenhoek brengen we zeer beschikbare complexe systemen in kaart, en de gemaakte kosten als die beschikbaarheid daalt ten opzichte van het voordeel van beschikbaarheid zonder downtime. Dus als we bijvoorbeeld een omgeving aan de linkerkant hebben waar het slecht gaat, kunnen we financiële verliezen lijden. We hebben juridische implicaties die commerciële implicaties op bedrijfsstrategieniveau kunnen zijn.
Er zijn allerlei mogelijke, denk ik, zelfs morele kwesties rondom het hebben van een servicevoordeel. Als het een gezondheidsindustrie is en ze gaan door de kosten van een stroomstoring, impact op de klanten, vermindering van klanttevredenheid, personeelsproductiviteit, gebruikersproductiviteit, etc. Deze dingen worden beïnvloed als we denken aan het ontwerpen van zeer complexe, zeer afhankelijke, zeer risicovolle omgeving met een potentieel risico op uitval en dus verlies.
Aan de rechterkant proberen we te streven naar een scenario waarin we, als we hoge kosten en planning investeren in ontwerp, investeren in intelligente implementatie. We investeren in het aanbieden van vaardigheden en middelen aan mensen en we hebben een hoog aangeschreven netwerk en een hoog aangeschreven operationele omgeving en hardware en software. We krijgen een hoge beschikbaarheid, maar het kost hoge kosten. Dus de slingerende magische slingerplek van de optimale positie in het midden waar ze oversteken, waar we iets lagere kosten hebben, en een toenemende beschikbaarheid die net tussen de niveaus van negen schommelt en de hoge beschikbaarheid die continue beschikbaarheid is en dit is een eeuwige uitdaging voor ons om aan te gaan, zoals in hoeveel geld u bereid bent te investeren om het serviceniveau te krijgen waarnaar u op zoek bent?
We hebben ook het onderwerp waarop ik niet in detail zal ingaan, maar ik wil gewoon dat je dit wegneemt en erover nadenkt. Het verschil tussen gemiddelde tijd tussen falen in uw ontwerp, versus gemiddelde tijd om te herstellen. Met andere woorden, investeert u in infrastructuur van betere kwaliteit, ontwerp van betere kwaliteit, hardware en software van betere kwaliteit en geschoolde medewerkers en middelen van betere kwaliteit om dingen te engineeren en de gemiddelde tijd tussen falen te verminderen, de gemiddelde tijd die nodig is om de pauze te vinden in tegenstelling tot lagere investeringen in infrastructuur, in middelen en ontwerp en blinde octrooien, de hoge mogelijkheid om te herstellen? Met andere woorden, als er iets kapot gaat, moet je er veel op aansluiten. Als iemand een laptop heeft en die sterft, heb je een reserve. Je geeft het aan hen en ze loggen in 30 seconden in. Dit zijn heel verschillende uiteinden van de paal. De bovenste afleidt je engineering met hoge kosten en hoge investeringen om falen te voorkomen, en de onderste zegt: "Ik ga accepteren dat falen zal komen, dus ik ga daar rond engineeren en op falen voorbereid zijn en snel herstellen. "
Zoals ik al eerder zei, waar ik zou kunnen zeggen: "Mijn beschikbaarheid is niet uw beschikbaarheid." Dus als het gaat om database-omgevingen en het ondersteunen van de infrastructuur, het runnen van uw database en het beschermen daarvan en het garanderen van hoge beschikbaarheid, is er echt geen one-stop-shop . Iedereen heeft zijn eigen behoeften en wensen. Dus u moet uzelf deze fundamentele vragen stellen die ik u zal nalaten, en dat is: wat kan uw organisatie zich veroorloven? Ik heb het niet alleen over dollars en centen. Ik heb het over, als organisatie, wat kunt u zich vanuit middelen, tijd en moeite enzovoort veroorloven voor zover het niveau van beschikbaarheid kan bieden? Wat kan uw bedrijf ook ondersteunen? Dus de huidige mogelijkheden, de huidige vaardigheden, de huidige infrastructuur, de huidige financiering die u kunt ophalen. Het is dus een interessant evenwicht tussen wat u zich daadwerkelijk kunt veroorloven en wat u kunt ondersteunen.
Je moet jezelf dan ook de volgende vragen stellen: welke vaardigheden en technologie heb je in huis? Kun je een deel van die uitdaging uitbesteden? Kun je dingen dan naar de cloud verplaatsen? Als je de infrastructuurdienst los van de softwareservice hebt, zit je zonder die stapel als je verder op de stapel gaat. Dus zou je meer moeten investeren in platforms en service en je geen zorgen moeten maken over de infrastructuur, of moet je software als een serviceaanbod beschouwen omdat je je geen zorgen hoeft te maken over het platform?
Wat voor soort markt en consument of klant onderhoudt u? Ik bedoel, als je een telecom bent en iemand moet de telefoon opnemen en je krijgt altijd een kiestoon, dat is een heel andere uitdaging om een kleine winkel te openen tussen maandag en vrijdag, negen tot vijf en sluiten voor een uur tijdens de lunch als een kapper op de hoekwinkel. Je moet dus heel lang en diep nadenken hoe dat werkt en wat dat voor je organisatie betekent, wat je moet kunnen bieden.
En dan het jongleren tussen wat er op het terrein is, wat extern wordt gehost en mogelijk, wat zich in de cloud bevindt. Zoals ik al eerder zei, komt dat ook uit tijdsproblemen. Dus we blijven zitten bij die laatste vraag waar ik onze vrienden bij IDERA naar uitkijk om ons te vertellen hoe zij precies deze dingen aanpakken, en dat is de fijne combinatie tussen het matchen van uw gewenste en vereiste beschikbaarheid met prestaties, en wat uw bedrijf nodig heeft en wat uw markt en uw consumenten nodig hebben.
En de realiteit is dat het geen gemene prestatie is. Het kost tijd, moeite en geld om over deze dingen na te denken. En steevast is het investering in mensen en vaardigheden en investeringen in software en tools om sommige van die processen te automatiseren en die mensen de juiste tools en juiste systemen te bieden om hun leven niet alleen beter te maken, maar mogelijk omdat monitoring van zeer grootschalige omgevingen en bescherming en het beheer van die grootschalige omgevingen gaat vaak verder dan individuele menselijke mogelijkheden.
Dus, met dat in gedachten, heb ik hopelijk het toneel geschapen voor een geweldig gesprek voor onze vrienden op IDERA om te praten over hun platform en tools, en ik kijk ernaar uit om aan het einde een aantal geweldige vragen te stellen. En ik zal doorgeven.
Dr. Robin Bloor: Oké. Bert, ik gaf je net de sleutels, haal het weg.
Bert Scalzo: Bedankt! Bedankt, Dez en Robin. Ik ga verder met het onderwerp hoge beschikbaarheid voor uw gegevens. En ik ga eigenlijk veel gebruiken waar Dez het net over had. Dus de keuzes, de negens, de afwegingen, de betaalbaarheid. Ik ga proberen dat meer in termen van de databasebeheerder of iemand die dichter bij de loopgraven staat, hoe ze er naar zouden kijken? Hoe zouden ze het architecten? En wat die keuzes eigenlijk betekenen.
Nu ga ik proberen database-agnostisch te zijn. Ik ga bijvoorbeeld geen Oracle-specifieke of SQL-Server-specifieke oplossing tekenen, maar ik ga, laten we zeggen, een generieke architectuur tekenen die alle databaseleveranciers aanbieden, iets in die richting. Ze noemen het allemaal verschillende namen, maar dat is een type keuze dat jullie gemeen hebben, en ik wil dat bekijken vanuit zowel het zakelijke als technologische perspectief, en hoe het zich verhoudt tot de zakelijke vereisten.
En ik wil beginnen met wat de meest basale oplossing met pseudo-hoge beschikbaarheid is, via de opties die u hebt op oplossingen op opslagniveau, oplossingen op virtualisatieniveau, op oplossingen op databaseniveau. En dan wil ik je ook laten kennismaken met het feit dat alle keuzes ook in de cloud beschikbaar zijn.
Dus nogmaals, ik ga proberen om redelijk database-agnostisch te blijven. Nu, de meeste dingen waar ik het over ga hebben, ik weet dat ze bestaan in Oracle, SQL Server, MySQL, PostgreSQL. Er zijn ook een aantal externe leveranciers, die tools maken die u ook extra architecturen geven die u zou kunnen overwegen. En, zoals Dez zojuist zei, geen enkele oplossing is de beste; het hangt er vanaf. Maar er is een universeel feit in waar we naar gaan kijken, er zullen meer bewegende delen zijn, dus het wordt complexer en daarom duurder.
We weten dus allemaal dat gegevens een belangrijke troef zijn. En iedereen weet dat snelle toegang tot de gegevens altijd leuk is. Maar betrouwbare toegang tot de gegevens is van cruciaal belang. En terwijl hij het over zijn voorbeelden had, kun je je echt veroorloven om 36½ dagen downtime te hebben? Het is van cruciaal belang dat die gegevens altijd beschikbaar zijn. En dus kan downtime een fortuin kosten, zowel in termen van verloren inkomsten, maar nog belangrijker, in verloren klanten, of in het verlies van goodwill van klanten. Ik zal je een goed voorbeeld geven; als een bepaalde website waar ik aankopen doe langzaam is, kan ik proberen een nieuwe website te vinden die vergelijkbare items verkoopt tegen vergelijkbare kosten die geen trage websites hebben. En dus is het niet alleen het verlies van de klant, het is de goodwill die de klant ten opzichte van u heeft.
Nu is hardware tegenwoordig een stuk goedkoper, dus er is steeds meer vraag naar hoge beschikbaarheid. En nogmaals, ik ga ons naar de wolk leiden, als we daarnaar kijken. En we hebben aanbiedingen van verschillende niveaus: de opslagleveranciers, de databaseverkopers, de virtualisatieverkopers en nu zelfs de cloudleveranciers. En dus, wat echt interessant is met de cloud, is dat nadat ik al deze prachtige foto's van deze architecturen heb getekend die je in de cloud zou kunnen bouwen, vaak slechts enkele selectievakjes zijn die je aanvinkt. En u zegt: "Ik wil replicatie over geografische regio's." Selectievakje. "Ik wil replicatie van belangrijke hardwarecomponenten." Selectievakje. En dus, als je de foto's begrijpt, vinkt het soms in de cloud slechts een paar vakjes aan om de foto te bouwen die je in je hoofd hebt.
Het belangrijkste is nu, wat zijn de zakelijke vereisten voor hoge beschikbaarheid? Moet ik me bijvoorbeeld alleen zorgen maken over fouten op een enkele site, of moet ik het op meerdere sites hebben? Met andere woorden, kan ik één rekencentrum hebben en kan het me niet schelen of dat ene centrum offline gaat? Ik stel geen zakelijke eis dat het zich over meerdere sites uitbreidt. Het is een zakelijke vraag. En het is belangrijk om te weten hoe het bedrijf de antwoorden op die vraag waarneemt, omdat dat doorgaans uw budget bepaalt.
Nu wilt u ook naar beneden kijken naar het niveau van faalbescherming. Zou het een stroomstoring kunnen zijn? Zou het een componentfout kunnen zijn? Zoals een NIC of een HBA slecht gaat, een hostbusadapter. Is het een harde schijf die slecht gaat? Is het een storing in de opslagkast? Is het een computerstoring? Of is het in sommige gevallen een sitefout? Dat is anders dan, in sommige gevallen kunt u een sitefout hebben, omdat de site zelf offline is. In een ander geval kan het zijn dat een aanzienlijk deel van de site offline is, maar vanuit uw perspectief is dat de hele site.
En dan, zoals Dez het had, wat is de verwachting van de tijd om de activiteiten te hervatten? Dat is een zakelijke vraag. Als het bedrijf zegt dat je de operaties binnen twee minuten moet kunnen hervatten, dan is het duidelijk dat dit enkele van deze foto's gaat definiëren die ik ga laten zien dat je zult werken, en sommige zullen geen opties zijn die je kan kiezen.
En een andere vraag die opkomt tijdens hoge beschikbaarheid, maar vaak vergeten mensen te vragen is: "Hé, bedrijf, als er iets gebeurt terwijl ik bezig ben met het verwerken van een transactie, wat mag ik verliezen bij hervatting van het systeem? " Met andere woorden, als ik het systeem binnen twee minuten kan herstellen en ik niet meer dan 10 seconden verlies kan verliezen aan transacties die in de lucht waren, is dat acceptabel? En nogmaals, dat zal bepalen wat het bedrijf daarvoor wil uitgeven, en nogmaals, dat kan bepalen welke foto's die ik ga laten zien, wel of niet van toepassing zijn.
Laten we dus beginnen met de meest basale oplossing met pseudo-hoge beschikbaarheid. Dit is echt geen hoge beschikbaarheid, maar ik begin hier graag mee, omdat het mensen aan het denken zet. Als ik een server en een opslagarray heb, plaats ik meestal meerdere NIC's, netwerkinterfacekaarten, in die server en bind ik ze zo dat als een NIC uitvalt, ik nog steeds klaar ben. En ik zal hetzelfde doen met mijn hostbusadapters, ik zal dat via verschillende schakelaars multi-path uitvoeren, zodat ik meerdere manieren heb om naar mijn opslag te gaan. En ik heb een universele voeding, en ik heb repetitieve controllers in mijn opslagarray, en misschien heb ik zoiets gedaan als RAID 10 met mijn schijven. Met andere woorden, op deze foto heb ik uitval van één component op meerdere niveaus voorkomen. Dus ik ben niet gebonden aan de NIC, of de HBA, of de controller, of de schakelaar.
Maar als u opmerkt, staat de server in rood en is de opslagarray in rood. Ik heb nog twee gebieden waar als ze falen, als mijn server weggaat, ik dood ben, als mijn storage array-kast weggaat, ik dood ben. Dus hoewel dit niet echt een hoge beschikbaarheid is, begint het je de foto te zien en te bekijken en te zeggen: "Ik wil een foto zonder rood." En dat is echt het doel van deze foto's, om ons in de goede richting te wijzen.
Dus het eerste wat er gebeurt is, als een DBA, wil ik misschien altijd de high-availability oplossing als een database-implementatie zetten, maar het kan zijn dat het beschikbaar is dat het als een opslagoplossing kan worden gedaan, of het kan zijn dat het een replicatie op opslagniveau zou kunnen zijn. In het geval van links heb ik opslagvirtualisatie. Wat er gebeurt is dat ik RAID 0 heb in twee verschillende opbergkasten voor mijn schijven, maar ik heb RAID 1 in de twee verschillende opbergkasten. Met andere woorden, ik kan nu echt een opslagkast laten falen en ik ben niet dood. Dus het is beter dan de vorige afbeelding, want in de vorige afbeelding - onthoud dat we zowel rood op de server als rood op de opslagarray hadden - en nu hebben we een kleine verbetering aangebracht, we hebben nu geen rood meer op het opslagniveau, we heb gebruikt - opslagvirtualisatie heeft dat probleem opgelost.
Een andere manier om dit te doen - en niet alle leveranciers bieden dit - is dat u mogelijk replicatie op opslagniveau kunt uitvoeren. Ik heb het niet over databasereplicatie, ik heb het eigenlijk over het repliceren van uw blok-I / O voor uw opslag. En dat kan op opslagniveau. En dus nogmaals, nu heb ik aan de rechterkant een andere foto waar ik het rood van de onderkant verwijder, omdat ik opslagreplicatie gebruik.
En dus is dit een andere afbeelding die al dan niet beschikbaar is. En de persoon die dit zou beheren, kan uw opslagbeheerder zijn in plaats van uw databasebeheerder. Ik wil dit graag naar voren brengen, omdat mensen soms denken: "Oh! Hoge beschikbaarheid, het moet de DBA zijn die dit probleem aanpakt." Dat is niet altijd waar; het zou in dit geval de opslagbeheerder kunnen zijn.
Nu kunnen we servervirtualisatie doen als een mogelijke oplossing. Als u het zich herinnert, had ik in de eerste afbeelding rood op de server en rood op de opslagarray. Ik zou in dit geval met virtualisatie kunnen verhuizen, en in sommige gevallen is die verhuizing een soort warme verhuizing, en in sommige gevallen zelfs een verhuizing. Sommige virtualisatie of hypervisors bieden de mogelijkheid om een virtuele machine tijdens de vlucht te verplaatsen. En sommige databases zullen die beweging tijdens de vlucht gemakkelijk accepteren. Nu, nogmaals, niet alle hypervisors bieden dit, maar dit is een mogelijk niveau van oplossing. Nu heb ik de topservers niet langer rood gemaakt, maar ik heb nog steeds de gedeelde opslagarray en raad eens, deze oplossing kan een gezamenlijke inspanning zijn tussen de databasebeheerder en de virtualisatiebeheerder. Of het kan zelfs alleen de virtualisatiebeheerder zijn, afhankelijk van welk niveau van verhuizing wordt ondersteund op die hypervisor en die database.
Als je je afvraagt: “Wauw, wat bedoelt hij met deze verhuizing? Geef me een specifiek voorbeeld. ”Bijvoorbeeld in VM waar u VMotion kunt gebruiken om uw virtuele machine van de ene host naar de andere te verplaatsen en dat te doen zonder downtime. Het is duidelijk dat die vorige foto nog wat rood bevatte. Ik had de opslag nog steeds als een enkel storingspunt. En dus gaan we naar de volgende oplossing die, nou ja, ik wil de opslag en de servervirtualisatie combineren.
Nu, in dit geval, kunnen het weer de opslagbeheerder en de virtualisatiebeheerder zijn die deze oplossing bouwen en nu kijken: ik heb een foto zonder rood erin. Ik heb een hoge beschikbaarheid omdat ik de virtuele machine of de actieve toepassing of database van de ene server naar de andere kan verplaatsen en ik heb virtualisatie in mijn opslagarray door RAID 1 over twee afzonderlijke opslagarrays te laten doen. Ik heb mijn switches en mijn HBA's multi-pathed.
Dus nu heb ik een HA-systeem gebouwd en ik heb het voornamelijk niet op databaseniveau gedaan. Met andere woorden, ik heb andere technologieën gebruikt om hetzelfde te bereiken. Dus dit is een oplossing. Vervolgens gaan we in op wat het schaalbare cluster voor gedeelde opslag wordt genoemd. Het is echt geen HA-oplossing, maar nogmaals, ik laat het graag zien voor de foto.
En wat hier gebeurt, is dat we twee servers hebben die een database draaien en het wordt beschouwd als één database. Het zijn geen twee afzonderlijke databases; het is niet zoals een meester en een slaaf, of een warme en koude, of een actieve en een stand-by. Dit betekent dat beide knooppunten samenwerken om één logische database te presenteren. En dus, wat er gebeurt is, als een bepaald knooppunt faalt, ben je nog steeds op. Dus het beschermt je tegen falen op serverniveau en doet dat in principe door de knooppuntbronnen zo min mogelijk te scherven, maar je hebt nog steeds het enige punt van mislukking voor de schijf. En dus is dit een schaalbaar cluster voor gedeelde opslag en Oracle noemt dit Real Application Cluster of RAC.
Nu is een andere oplossing om een failover-cluster voor gedeelde opslag te gebruiken. Dus links heb ik een actieve node, rechts heb ik een passieve node, ik heb er een hartslag tussen. Ik heb een gedeelde opslagarray en dit is van cruciaal belang; dat moet je hebben. En wat er in feite gebeurt, is dat als het actieve knooppunt problemen tegenkomt, het passieve knooppunt het kan overnemen. Hier zijn licentieproblemen aan verbonden. Bij sommige leveranciers van databases kunt u het passieve knooppunt met een beperkte licentie voor een bepaalde tijd gebruiken. In andere gevallen moet u over volledige dubbele licenties beschikken. Het hangt allemaal af van uw database leverancier. Maar ze ondersteunen allemaal dit soort beeld, dat is, als de ene knoop naar beneden gaat, de andere knoop kan overnemen.
En meestal is dit een van die scenario's waarbij het, als je van het actieve knooppunt naar het passieve knooppunt gaat, waarschijnlijk in de meeste databases - niet alle - een deel van de in- vluchttransacties. Vervolgens gaan we in op wat de databasebeheerder echt kan bekijken, namelijk databasereplicatie, en er zijn twee verschillende manieren om databasereplicatie uit te voeren.
Er is fysieke replicatie, en wat belangrijk is, is in het midden van deze foto, je kunt met de groene ster zien dat de replicatie wordt gedaan door de database, maar, net als de virtualisatie op opslagniveau, het wordt gedaan in het blok niveau. We herhalen dus de werkelijke blok-I / O's van het actieve knooppunt naar het alleen-lezen of passieve knooppunt. En dit wordt beschouwd als fysieke replicatie.
Laat me nu naar de volgende dia gaan omdat het bijna identiek is en het is logische replicatie en het enige dat in de afbeelding verandert, is dat in het midden, in plaats van over het blok I / O te verzenden, we in wezen het logboek verzenden bestanden met de SQL-opdrachten erin. Met andere woorden, wat we repliceren, is niet de fysieke I / O, maar de opdrachten die de fysieke I / O veroorzaken.
En dus wordt dit vaak logverzending of log-gebaseerde replicatie genoemd. Sommige databaseverkopers geven u dit native. Andere databaseverkopers bieden dit mogelijk niet aan, maar externe leveranciers bieden dit ook aan, en dus is dit een zeer populaire HA-oplossing en wordt het als een complete oplossing beschouwd. Maar deze oplossing is primair de verantwoordelijkheid van de DBA.
Dus ik gebruik geen virtualisatie om dit te bereiken. Ik zou het kunnen, maar ik ben er niet afhankelijk van. En ik gebruik geen opslagvirtualisatie. Nogmaals, ik zou het kunnen, maar ik ben er niet afhankelijk van. Maar ik bouw een oplossing met de database als primaire drijffunctie. Dit is dus logische replicatie.
Nu is het ook mogelijk om database- en opslagvirtualisatie te combineren. Ik zou in mijn datacenter, laten we zeggen, links in het blauw, virtualisatie voor de opslag kunnen hebben, zodat ik niet gebonden ben aan een bepaalde opslagarray die faalt. Maar ik doe misschien log-gebaseerde of logische replicatie op databaseniveau van het ene datacenter naar het andere, zodat de opdrachten ook in datacenter worden uitgevoerd, resulterend in I / O, maar niet noodzakelijkerwijs dezelfde I / O, omdat ik ' m verzend niet de blok-I / O, hetzij door de opslagoplossing of door de database, maar ik verzend de logboeken en daarom de SQL-opdrachten.
En dus is dit een afbeelding die veel voorkomt voor zeer grote organisaties. En ik vind deze foto hier leuk, want als ik dit lokaal moet opzetten met behulp van een database zoals Oracle, kan ik het doen; het is behoorlijk wat werk, het is behoorlijk complex, er zijn veel bewegende delen. Als ik dit in de cloud doe, kan ik letterlijk zeggen, selectievakje, ik wil twee geografische regio's, ik wil de regio's gescheiden door, weet je, op verschillende continenten, ik wil virtualisatie op opslagniveau in een bepaalde geografische regio. Ik kan zelfs zeggen dat ik de mogelijkheid wil hebben om toewijzing van het virtualisatietype of definitie van hoge beschikbaarheid te doen, en nogmaals, het is nog een selectievakje.
En het andere waar ik van hou in de cloud, is er nog een selectievakje dat vaak zegt: "Ik wil niet omgaan met patchen, gewoon patchen", weet je, werk het gewoon in de workflow van alles wat je doet achter de scènes, houd me te allen tijde gepatcht. En dus, hoewel sommige van deze foto's erg complex worden en ze op locatie misschien moeilijk zijn om te doen, worden ze eigenlijk vrij eenvoudig om in de cloud te doen.
Het interessante is dat het eenvoudig is om alle selectievakjes aan te vinken, maar raad eens, dat kost maandelijks meer geld. Omdat als u twee datacenters beheert, u weet dat er twee datacenters in de cloud zijn die u gebruikt, u meer gaat betalen dan wanneer u er slechts één zou gebruiken. Evenzo, als u het opslagniveau of de hoge beschikbaarheid van virtualisatie als extra laag gebruikt, kunnen er opnieuw extra kosten zijn.
Het is dus interessant dat hoewel het moeilijk is om ter plaatse te doen en je het misschien te overdenkt, het in de cloud zo gemakkelijk is om te doen, je er misschien over nadenkt. Weet dus altijd hoe de afbeelding eruit ziet en weet altijd wat de kostengevolgen zijn voor welke afbeelding u ook maakt. Nu zijn er veel meer combinaties dan wat ik hier heb laten zien. Dit is geen volledig of volledig voorbeeld. Er komen regelmatig nieuwe technologieën bij, dus wie weet heb ik er misschien niet één laten zien die de afgelopen drie maanden is verschenen. En hoge beschikbaarheid komt veel vaker voor dan tien jaar geleden.
Ik zou het zelfs niet erg vinden om te zeggen dat het voor de meeste grote organisaties tegenwoordig een verplichte zakelijke vereiste is. En ik ga graag terug naar deze dia omdat ik net zei dat het een verplichte zakelijke vereiste is. En ik heb deze twee tafels aan de rechterkant. De bovenste is afkomstig uit de SQL Server-documentatie en de onderste is afkomstig uit de Oracle-documentatie. En wat dit zijn, dit zijn tabellen om u te helpen, nou ja, welke replicatiemethode u moet gebruiken.
En merk op dat u begint met enkele zeer eenvoudige vragen. Hoeveel gegevens mag ik gebruiken? En als het antwoord nul is, weet je dat je alleen in die bovenste grafiek de eerste of de vierde rij kunt kiezen. Dan stel je nog een vraag. Hoe lang mag ik het herstel doen? En als iemand zegt, nou ja, seconden of minuten, dan maakt dat keuzes voor u. En dan, moet de failover automatisch zijn of moet iemand dit handmatig doen? En dat is nog een zakelijke vraag. Ze kunnen zeggen dat ze het automatisch willen omdat ze niet willen vertrouwen op, weet je, een escalatieprocedure en dan krijgt iemand een ticket toegewezen en dan het probleem oplossen. Ze willen gewoon dat het wordt opgelost.
Dit zijn allemaal zakelijke vragen en het zijn dezelfde vragen als ik naar beneden ga en hetzelfde doe voor Oracle. En ik vraag, OK, wat voor soort storing sta ik toe, wat voor soort duur, wat kan ik verliezen, wat is de herstelprocedure? Dit zijn allemaal zakelijke keuzes, dus als het bedrijf me de antwoorden op drie of vier vragen vertelt, is mijn baan heel eenvoudig, ik kom hier gewoon binnen, ik kies een van deze die het meest overeenkomt en bouw dat dan. En vergeet niet dat het in de cloud slechts enkele selectievakjes kunnen zijn om deze daadwerkelijk te implementeren.
En daarmee ben ik aan het einde van mijn materiaal en de tijd om dit open te stellen voor vragen.
Eric Kavanagh: Oké, Dez, misschien jij eerst en dan Robin?
Dez Blanchfield: Absoluut. In feite waarschijnlijk een beetje oneerlijk voor degenen die niet op Twitter zijn, maar ik heb een foto van een grafiek getweet die ik in ieders gedachten wil visualiseren en toen wilde ik de vraag aan onze geleerde vriend over de oproep hier geven. Als ik denk aan proprietary versus open source in deze ruimte - waar we het vaak over hebben, soort van proprietary databases van Oracle en Microsoft enzovoort, versus open source - kom je uit op deze uitdaging waarin de proprietary wereld de internet software verkoper of software ontwikkelaar of het bedrijf investeert in de instanties om die complexiteit in te bouwen. En zo krijg je een scenario waarin je de software koopt en hoef je niet in veel mensen te investeren omdat je koopt de ingebouwde en open source-capaciteit - u betaalt niet voor de software of de lage kosten, laten we zeggen, maar u betaalt niet voor de software, maar u moet investeren in de instanties.
En ik ben benieuwd naar je gedachten over het jongleren, vooral nu we naar cloudmodellen gaan waar je een van beide kunt krijgen. U kunt naar AWS of Azure en uw Rackspace gaan, wat dan ook, en kopen als een service die uw databaseplatform levert, of u kunt het doen via open source code. En waar we het zojuist over hebben gehad, wat is het jongleren tussen proprietary en open source en hoe de ontwerppatronen waar u het over hebt effect hebben en wat zijn uw algemene gedachten over dit onderwerp terwijl we verder gaan, met name over het bieden van beschikbaarheid?
Bert Scalzo: Een van de grote dingen die ik tegenkom als ik die vraag probeer te beantwoorden, ga terug naar de klant en vraag hem naar hun prestatie-eisen. En de reden dat ik dat doe, is dat ik - althans historisch en in mijn eigen ervaring - heb ontdekt dat als het gaat om klanten die een hoge doorvoer nodig hebben voor hun replicatie, ik bijna altijd beter af ben met de replicatie die door de database wordt geboden leverancier, vanwege de aard dat het inherent is ingebouwd en het op een lager niveau is, en soms maakt het gebruik van mechanismen die niet beschikbaar zijn voor de buitenwereld, zelfs in een open-source oplossing.
En ik zal je een goed voorbeeld geven van een geval dat ik had. Ik had een internetbedrijf dat MySQL als hun database gebruikte en ze gebruikten een oude versie van MySQL, zoals versie 4.0, en de replicatie tussen hun knooppunten was de beperkende factor voor hoe groot ze hun databases konden schalen. En ze keken naar het kopen van een oplossing van derden en vervolgens naar: "Wel, misschien kunnen we een van de open-source oplossingen gebruiken." En waar het eigenlijk op neerkwam, was dat ze alleen maar hun MySQL moesten upgraden naar versie, ik denk dat het 5, 5 was waar we naar toe gingen, omdat het verschil tussen die twee databaseversies in de 4.0-versie van MySQL-replicatie niet was opgenomen en in versie 5.0 was het zo, en dat was eigenlijk het beste pad voor hen.
Nu hebben we de andere keuzes bekeken, maar de beslissende factor waren de prestaties en het blijven bij de oplossing van de databaseverkoper, en het uitvoeren van de database-upgrade was uiteindelijk onze beste oplossing om de hoogste kans te krijgen om de prestaties te krijgen die ze nodig hadden om mee te werken de hogere beschikbaarheid.
Dez Blanchfield: Ja, dat weerspiegelt mijn eigen denken, om eerlijk te zijn. Alleen voor volledige openbaarmaking, en ik zal niet ingaan op merken, maar ik heb een eigen achtergrond en werk voor OEM's en softwareleveranciers en IOC's in het algemeen, en dat is absoluut mijn ervaring en tegelijkertijd ben ik zeer pro -open-source en ik ben een code-medewerker voor een aantal projecten die we niet zullen noemen, maar ik ben het met je eens dat als je een grote organisatie bent - laten we zeggen dat je een bank bent, of wat dan ook be - steevast wil je geen IT-winkel zijn. Je weet wel, bijvoorbeeld als je een krantenuitgever bent of als je een retailer bent, je wilt geen IT-winkel zijn die kranten publiceert, je wilt een krantenwinkel zijn die eigenlijk alleen maar gebruik maakt van IT.
En dus, investeren in de gepatenteerde mogelijkheden waar de softwareontwikkelaars al die mogelijkheden bouwen, de taakverdeling, enzovoort, in de tool, is heel wat logischer in vergelijking met of je een dotcom-startup bent of zoiets zoals dat kan investeren in menselijke lichamen. Waar zie je dit heen?
Waarschijnlijk mijn laatste vraag voordat ik het overhandig aan Dr. Robin Bloor, omdat ik weet dat we te weinig tijd hebben. Waar zie je dit vanuit een trendperspectief gaan? Dus je bent er altijd, je zit op de rand van het spul, zie je dat mensen rechtop zijn gaan zitten en opletten en wakker werden van de noodzaak om dit een commercieel onderdeel van hun dagelijkse leven te maken daggesprek terug naar de bestuurskamer? Of zie je het nog steeds heel erg de geekfarm, de techneuten en de hoodies die denken aan beschikbaarheid omdat het hen wakker maakt om vier uur 's ochtends wanneer er iets offline gaat?
Denk je dat de trend nu naar organisaties van elke omvang doorzwaait, niet voor de hand liggende zoals luchtvaartmaatschappijen en banken en financiën, maar alleen bedrijven in het algemeen? Denkt u dat mensen echt uit waardepropositie zijn geraakt om hun database-omgevingen te beschermen en een hoge beschikbaarheid te bieden en daarin te investeren, of denkt u dat we nog een weg te gaan hebben? Wat is de algemene betekenis in de markt daar?
Bert Scalzo: Op dit moment denk ik dat er nog steeds een kloof is, maar het is geen kloof omdat het bedrijf er niet om vraagt, het is een kloof in de communicatieniveaus tussen de twee kanten van het hek. Met andere woorden, de zakenmensen zeggen heel duidelijk: "Deze applicaties vereisen een hoge beschikbaarheid en hebben deze specifieke vereisten als we zeggen hoge beschikbaarheid."
En op de een of andere manier komt die boodschap niet duidelijk over op de techmensen. Of de technische mensen zullen terugkomen en zeggen: "Oh, dat is ingewikkeld en het kost je meer geld", en dit, dat of het ander. Ik denk dat wat er gaat gebeuren is dat het uiteindelijk weg zal eroderen omdat, eerlijk gezegd, omdat het bijvoorbeeld in de cloud is, gewoon een paar vakjes hier of daar aanvinkt om te zeggen: "Bouw me deze echt complexe technologische structuur, " er is echt geen goede reden voor de technologiemensen om terug te komen en tegen de zakenmensen te zeggen: "Oh, het is duur", of "Het is moeilijk om te doen" of dit of dat, en de zakenmensen beginnen te weten dat dat de feit.
En ik heb zelfs gezien in omgevingen waar, weet je, hun eigen IT-mensen zullen komen en zeggen: "Oh, je kunt niet hebben wat je wilt. Het is te duur. 'En ze zullen een extern adviesbureau inschakelen dat dan zal zeggen:' Nee, dat is niet correct. Hier is hoe je het zou kunnen doen. Dit is wat het je gaat kosten. ”Dus ik denk dat we nog een beetje tijd hebben tussen de communicatieniveaus tussen de twee partijen voordat dat nog steeds automatisch wordt.
Dez Blanchfield: Ja, dat is zeker een afspiegeling van wat ik hier in Australië en rond Asia Pacific heb gezien. Ik weet zeker dat het iets wereldwijd is. En dat is dat veel van de belangrijkste besluitvormers uit de directiekamer, alle bedrijfsleiders, ze zijn technisch veel slimmer - ze lezen de blogs, ze bekijken webinars, ze zijn afgestemd op verschillende artikelen en podcasts en ze gaan naar evenementen en forums en meetups en ze kennen nu hun opties en ze weten dat cloud een optie is.
Ze weten ook dat ze dat, zoals je zei, hun capaciteiten in eigen huis kunnen brengen, en dus denk ik dat er nu een interessante uitdaging is, dat er een gesprek moet plaatsvinden dat eigenlijk is wat we vandaag hebben gedaan waar mensen, soort van, begin dingen intern te doen en voer gewoon bruine zaklunches uit en krijg een interne briefing over wat onze huidige staat is, wat onze ideale staat is, waar moeten we naartoe? En dan, min of meer, breng dat samen.
Ik had een privébericht dat ik zojuist ga bespreken. Iemand stelde een vraag: "Is het realistisch dat u 100 procent beschikbaarheid kunt krijgen?" En misschien kunt u mij hier corrigeren, maar ik ga ja zeggen. Ik heb een platform gebouwd voor een elektronische overboeking, een EFTPOS-gateway tussen snelle bankplatforms en de EFTPOS-terminals. Ik heb dit begin 2000 gebouwd. Het is eigenlijk al 17 jaar 100 procent van de tijd online. In feite werd het vóór de 2000s gebouwd, maar het ging slechts ongeveer 2000/2001 in productie.
Dus, de 17 jaar is op zijn plaats geweest van ontwikkeling tot testen en vervolgens in productie gaan. In die 17 jaar hebben zeer voordelige standaard-pc's met een open-source besturingssysteem, maar een eigen database, elke 90 dagen actieve / passieve swaps uitgevoerd, met verschillende ontwerppatenten, met replicatie van schijven in elke server, replicatie van gegevens tussen modelservers, replicatie van meerdere datacenters en flippen vanuit datacenter A gedurende 90 dagen productie en vervolgens flippen naar datacenter B en productie uitvoeren.
En terwijl het omkeert, wordt het automatisch bijgewerkt en bijgewerkt, dus alleen de vraag die ik zojuist privé heb gekregen, ja, het is mogelijk, maar met veel investeringen in dat project vanuit een ontwerpoogpunt. Dus de infrastructuur was eigenlijk niet zo duur, maar het ontwerp en het testen en de implementatie was erg duur om dat te krijgen. We hoefden dus niet veel geld uit te geven aan hardware en infrastructuur, maar we gebruikten zeer slimme tools in de tijd dat cloud niet eens een munt was.
Dus, het antwoord is ja, het kan worden gedaan, nog meer nu met cloud, zoals we zojuist hebben gehoord, met een klik op een knop kun je die mogelijkheid inschakelen. Ik ga dat naar Robin gooien omdat ik zeker weet dat hij ook vragen heeft. Maar heel erg bedankt voor het beantwoorden van mijn vragen en ik vond het erg leuk om vandaag je bericht te horen. Helemaal aan boord, omdat het alles weerspiegelt wat ik de afgelopen bijna 30 jaar zelf heb gedaan.
Dr. Robin Bloor: Nou, OK, ik zal het oppakken. Een van de dingen die me fascineerde aan je presentatie was het aantal opties dat nu beschikbaar is en die niet beschikbaar waren toen ik met dit soort dingen worstelde. Ik ben een beetje geïnteresseerd in wie deze configuraties gaat ontwerpen, of wie tegenwoordig deze configuraties ontwerpt? Wat er vroeger gebeurde, of, de wereld die ik gewend ben, is dat er een redelijk zwaar transactiesysteem zou zijn en dat je geïnteresseerd zou zijn in hoge uptime, hoge beschikbaarheid. Omdat, je weet wel, het transactionele systeem, het zou duur zijn als het op welke manier dan ook zou dalen. En je zou niet alle opties hebben die je me net hebt gepresenteerd, maar op de een of andere manier zou je een manier kunnen vinden, meestal via replicatie, om een hete stand-by te creëren die niet onopgemerkt zou klikken, maar het zou u een slechte service geven tot u terug bent.
En ik ben eigenlijk aan het kijken naar wat je me liet zien en erover nadenken, ik heb 15 jaar lang geen van dat soort ontwerpwerk gedaan, wie doet dat nu? Is dit, zoals het in mijn tijd was, iets dat je deed bij het begin van een project, weet je, de infrastructuur draaiende maken? Of is dit iets dat een doorlopende activiteit is binnen een organisatie? Omdat er nieuwe technologische keuzes zijn.
Bert Scalzo: In de grote bedrijven die zeer efficiënt en effectief zijn in al hun activiteiten, inclusief hun IT, hebben ze meestal een gecentraliseerde architectuurgroep, of ze hebben er een naam voor, ik heb het gehoord dat 'de architectuurgroep 'vaak. En het zal hun verantwoordelijkheid zijn om al deze verschillende foto's te kennen en wat de voor- en nadelen zijn en wat de kosten zijn. En wat er zal gebeuren is, wanneer een bepaalde applicatie kijkt en zegt: "Hé, ik moet voldoen aan zakelijke vereisten X, Y en Z. Hé, architectenteam, wat zijn mijn keuzes?"
Ze zullen hen het antwoord geven, zoals, hier zijn de twee of drie die beschikbaar zijn, en op dat moment gaat de beslissing terug naar het lagere niveau naar het applicatieteam of naar de bedrijfssponsor van de applicatie. Maar meestal is er een gecentraliseerde groep die dit in de gaten houdt en die informatie bij de hand heeft en vooraf gebouwd.
Nu zijn het de middelgrote bedrijven waar het niet zo formeel is. Wat meestal zal gebeuren, is dat u een of twee van uw senior DBA's of systeembeheerders krijgt en zij zullen informeel “de domeinexpert” citeren voor dat soort expertise. Dus zelfs in de middelgrote bedrijven gebeurt het gewoon in een niet-geformaliseerde structuur.
Dr. Robin Bloor: Dat is echt best interessant. In mijn dag zouden we nooit aan hoge beschikbaarheid denken, behalve aan de transactiesystemen. Nou, tegenwoordig heb je natuurlijk streaming-systemen die waarschijnlijk nog hogere eisen stellen aan de beschikbaarheid. Maar zie je in de query-gebaseerde, back-end, analyse, datawarehouse, DI-soort omgeving ooit eisen voor hoge beschikbaarheid daar?
Bert Scalzo: Ja, en ik ben blij dat je die vraag hebt gesteld. Ik deed wat werk voor een retailbedrijf en hun strategische beslissingen voor het bedrijf waren grotendeels gebaseerd op de analyse die ze vanuit het datawarehouse zouden doen. En in feite werden ze geïnterviewd door Forbes Magazine en de CEO van het bedrijf zei: "Hé, onze aandelenkoers is de afgelopen vijf jaar met 250 procent gestegen en een zeer grote reden is dat we weten hoe we onze gegevens effectief kunnen benutten in ons datawarehouse. ”Ze waren zo goed in het nemen van zakelijke beslissingen dat, voor hen, het datawarehouse en in staat zijn om die analyses te doen, dagelijks beslissingen kunnen nemen op basis van hun operationele gegevens, eigenlijk voor hen was, een productiesysteem.
En ik zal je een goed voorbeeld geven van hoe belangrijk het is. Met deze specifieke retailverkoper, de man die verantwoordelijk was voor de bierverkoop, was hij, net als de derde belangrijkste leidinggevende in het bedrijf, omdat hij, weet je, 60, 70 procent van de omzet binnenhaalde. En dus moest hij, om concurrerend te blijven in die markt, elke dag kunnen weten, weet je, welke promoties ik zou moeten lopen. En dat kan gebaseerd zijn op, weet je, niet alleen de tijd van het jaar, maar ook het weer, patronen en andere kritieke gegevens die de verkoop van zoiets als bier kunnen beïnvloeden.
Dr. Robin Bloor: Nou, ik denk dat er zulke dingen zijn. We hebben een beetje tijd, ik denk dat ik Eric moet doorgeven voor het geval hij vragen heeft van het publiek. Eric?
Eric Kavanagh: Ja, dit zijn allemaal geweldige dingen geweest, Bert. Ik denk dat je alle vragen van het publiek in je presentatie hebt beantwoord. Maar het is leuk om te zien. Ik ben blij dat je soort van opslagvirtualisatie hebt gesproken en hoeveel impact dat kan zijn. Dus dit is allemaal goed spul.
Welnu, mensen, we archiveren al deze webcasts om ze later te bekijken. Spring dus online naar Techopedia.com om de webcast-sectie te zoeken. Al die Hot Techs worden daar vermeld. Hartelijk dank aan onze vriend Bert voor zijn expertise. En natuurlijk, aan Dez en Robin. En daarmee gaan we u vaarwel zeggen, mensen. Wees voorzichtig. We spreken je de volgende keer wel. Tot ziens.
