DAVID Malan: Molt bé, benvingut de nou. Abans d'aprofundir en la computació en núvol, Que vaig pensar en fer una pausa per un moment si hi ha qualsevol pregunta pendent o temes que van sorgir durant el dinar que ara podria ser del seu interès. AUDIÈNCIA: [inaudible] DAVID Malan: OK. Oh d'acord. AUDIÈNCIA: [inaudible] DAVID Malan: No, és clar. OK, bé espero que la totalitat del seu sorgeixen problemes en les pròximes hores i demà tot. No obstant això, anem a fer una ullada, a continuació, a on l'última discussió sobre la configuració de un lloc web condueix, en general quan es tracta de la computació en núvol, la creació d'una arquitectura de servidor, el tipus de decisions que els enginyers i desenvolupadors i administradors de fer quan es tracta de a fer alguna cosa més que la subscripció a un $ 10 per mes d'allotjament web quan en realitat es vol construir a terme seva pròpia infraestructura. I anem a tractar de lligar això de nou, per exemple, per Dropbox i altres Com ells. Així que anem a començar a considerar Quins problemes sorgeixen com a negoci aconsegueix bones i bones sorgeixen problemes. Així, en el cas més simple de tenir alguna empresa que té un servidor web, que pugui tenir, diguem, un servidor que només haurem de extraiem que s'assembla a això. I en aquests dies, la majoria de servers-- i deixar en realitat posar una foto a aquesta tan que és una mica menys nebulós. Així rack Dell server-- de tornada en el dia, hi ha eren els ordinadors centrals que es va dur a quarts sencers. En aquests dies, si vostè fos per aconseguir un servidor, pot tenir un aspecte una mica alguna cosa com això. Els servidors es mesuren en el es diuen unitats de rack, o EF. I una empresa ferroviària és de 1,5 polzades, que és un estàndard de la indústria. Així que això s'assembla a un servidor de dos RU. Pel que és de 3 polzades d'alt. I són generalment 19 polzades d'ample, el que significa tot això tipus de coses està estandarditzat. Així que si ens fixem en un center-- dades no només en un servidor, però anem a fer una ullada a Google de centre de dades i veure si veure una bona foto a Google. Això és molt millor del que va encendre típicament trobar, i molt sexy buscant com a resultat. però això és el que sembla ser una parella centenars de servidors en tot per això la mateixa mida, En realitat, en els bastidors entrin després bastidors entrin en un centre de dades. Una cosa així- Això bé pot ser de Google, ja que a Google de Google. Però podria ser representativa de forma més general un centre de dades en la qual molts les empreses estan normalment ubicats conjuntament. I co-ubicada generalment vol dir que vas a un lloc com Equinix o altres venedors que tenen grans magatzems que tenen un munt d'energia, un munt de refrigeració, és d'esperar molta seguretat, i gàbies individuals que tanca bastidors de servidors, i que o bé llogar els bastidors o aconseguir que els bastidors a. I les empreses individuals, arrencades especialment, tindrà algun tipus de biometria per entrar a la seva gàbia, o un clau, o una targeta d'accés. Vostè obre la porta. I dins d'allà és només una empremta de peus quadrats que vostè està pagant, a l'interior de que es pot posar el que vulguis. I normalment paga per l'energia. I que paga per les empremtes. I després es paga vostè mateix per als servidors que està posada en aquest espai. I el que llavors té el opció de fer és pagar a algú per a la seva connexió a serveis d'Internet. Vostè pot pagar qualsevol quantitat de venedors, tots els quals solen entrar en aquest centre de dades. Però la qüestió és realment interessant, el que realment passa en aquests bastidors? Es podria molt bé semblar-se al que acabem de veure. Però que realitzen diverses funcions i pot ser que necessiti per fer coses diferents. I deixar de realitat motivar aquesta discussió amb la pregunta de, quin problema comença a sorgir si té èxit? Així que tens un lloc web que s'ha construït. I pot ser que ven reproductors o alguna cosa aixi. I que ha estat fent molt bé amb vendes en línia de widgets. I es comença a experimentar alguns dels símptomes, el seu lloc web. Quines podrien ser alguns els símptomes tècniques que els usuaris reporten com a negoci està creixent i en plena expansió i el seu lloc web és es beneficia d'això? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, exactament. El que podria tenir una desacceleració del seu lloc web. I per què podria succeir? Doncs bé, si suposem, per En nom de la discussió en aquest moment, que estàs en un d'aquestes empreses de hosting que hem parlat abans del dinar, que pagui alguna quantitat de dòlars a per mes, i que ja ha pagat el cost anual del seu domini nom, que és probablement d'allotjament web Overselling seus recursos fins a cert punt. El que podria tenir un nom d'usuari i la contrasenya al seu servidor. Però el mateix podria diversos altres, o diversos dotzenes d'altres, o potser fins i tot diversos altres cent, als usuaris. I llocs web viuen físicament en el mateix servidor. Per què és això possible? Bé en aquests dies, servidors com això normalment tenir múltiples unitats de disc dur, potser tants com sis o més unitats de disc dur, cadascun dels quals poden ser tant com 4 terabytes en aquests dies. El que podria tenir 24 terabytes d'espai en tan sols una mica de servidor d'aquesta manera. I fins i tot si vostè roba una mica d'aquest espai per a la redundància, per a fins de còpia de seguretat, és encara un munt d'espai. I, per descomptat, una pàgina web típica no necessita molt espai. Només es registren usuaris i emmagatzemar registres d'ordres no pren tot el que molt espai. Pel que pot particions bastant una mica i donar a cada usuari només una petita porció d'això. Mentrestant, un ordinador com aquesta en aquests dies típicament té múltiples CPUs-- no només 1, potser dos, potser quatre, potser 16, o fins i tot més. I cada un d'aquests CPU té alguna cosa que es diu un nucli, que és una cosa així com un cervell dins d'un cervell. Així que, de fet, gairebé tothom aquí amb ordinadors portàtils moderns tenen probablement un doble nucli o CPU-- de quatre nuclis i probablement només dins d'una CPU d'un ordinador portàtil en aquests dies. Però els ordinadors d'escriptori i equips de rack com això podria tenir un bon nombre més CPU, i en els nuclis de gir. I, francament, fins i tot en els nostres Macs i PCs de Avui en dia, vostè realment no necessita dos nuclis o quatre nuclis per comprovar el seu correu electrònic. Si hi ha algun coll d'ampolla quan es tracta d'usar un ordinador, que l'ésser humà és probablement el El més lenta sobre aquest equip. I no seràs capaç de consultar el seu correu electrònic més ràpid si tenen quatre vegades el nombre de CPU o nuclis. Però la mateixa és una espècie de veritat d'un servidor. Un lloc web no només podria necessàriament es necessita més d'una CPU o un nucli, un cervell petit a l'interior fent tot el pensament i el processament. Així que els fabricants tenen de manera similar començat a tallar a aquests recursos pel que tal vegada el seu lloc web rep una nucli, la Pàgina Web atreu un nucli, o potser estem compartint un tal nucli. També estem compartint espai en disc. I també estem compartint memòria RAM, o memòria d'accés aleatori d'abans, dels quals també hi ha una quantitat finita. I aquesta és la clau. No importa què tan car l'equip era, encara hi ha un nombre finit quantitat de recursos en el mateix. I així, la cada vegada més es tractar de consumir aquests recursos, les coses més lentes podrien arribar a ser. Però perquè? Per què les coses més a poc a poc com una símptoma d'un servidor sobrecarregat? Que està passant? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, exactament. He proposat anteriorment que RAM és un tipus de memòria. És volàtil, pel que és on les aplicacions i les dades són emmagatzemada quan estan sent utilitzats. I per tant no hi ha només un nombre finit de coses que pot fer semblar alhora. I també és més ràpid, que és una bona cosa. Però també és més car, que és una mala cosa. I també és, per tant, present en menor quantitats que l'espai en disc, disc dur espai, que tendeix a ser més barat. En altres paraules, podria tenir 4 terabytes d'espai en disc a l'ordinador. No obstant això, és possible que tingui 4 gigabytes, o 64 gigabytes, en ordre de magnitud, un factor de 1.000 menys de la seva RAM en el seu ordinador. Què fa un ordinador? Bé, suposem que vostè no tenir 64 gigabytes de RAM en un servidor d'aquesta manera, que seria bastant comú, si no baixa aquests dies. Però suposem que té tants els usuaris que fan tantes coses que classe de tipus de necessitarà 65 gigabytes de memòria per a manejar tot això ús simultani? Bé, vostè podria dir: Ho sentim, cert nombre d'usuaris simplement no pot accedir al lloc. I aquesta és la mesura d'última instància, sens dubte. O bé, com l'operatiu sistema, com el Windows o Mac US o Linux o Solaris o qualsevol nombre d'altres sistemes operatius en aquest servidor, podria simplement decidir, saps què? Només tinc 64 gigabytes de memòria RAM. Jo com que necessito 65. Així que ja saben què? Vaig a prendre d'1 gigabyte el valor de les dades a la RAM que era el menys s'ha accedit recentment i només es mouen en el disc temporalment, literalment, copiar del ràpid memòria a la memòria més lenta de manera que llavors puc gestionar això 65a necessitat gigabyte de memòria, fer algun càlcul sobre el mateix. Després, quan he acabat de fer això, Vaig a la moció que en el disc, moure aquesta altra memòria RAM de posar temporalment en el disc nou en el maquinari real de manera que jo sóc una mena de multitasca. Així que estic espècie de posar les coses temporalment a aquest espai més lent pel qual es crea la il·lusió de manejar tots. Però hi ha una desacceleració. Per què? Doncs bé, a l'interior d'aquests durs Discos d'aquests dies és què? Més aviat, el que fa que un disc unitat diferent de la RAM el millor que sap ara? AUDIÈNCIA: [inaudible] DAVID Malan: OK, és cert. AUDIÈNCIA: [inaudible] DAVID Malan: Així que és molt cert. I això és un efecte secundari o característica el fet que la memòria RAM és de fet més ràpid. I per tant desitja utilitzar per al seu ús actual. I un disc és més lenta. Però és permanent o no volàtil. Així que l'utilitzen per a l'emmagatzematge a llarg termini. Però en termes de aplicació, si miro cap amunt el que s'anomena un mòdul DIMM, memòria dual en línia Mòdul, això és el que un tros de memòria RAM normalment podria ser similar. Així que dins la nostra Mac-- que és un insecte. Dins dels nostres Macs i PC d'escriptori, la nostra computadores tindrien cartutxos de memòria, com es pot trucar, o mòduls DIMM o SIMM volta en el dia, de la memòria que s'assemblen a això. Els nostres ordinadors portàtils probablement tenen coses a són un terç de la mida o la meitat de la mida. Són una mica més petit, però el mateix petit idea-- peces de silici verd hòstia o plàstic que té petites fitxes negres en ells amb molta dels cables d'interconnexió tot. És possible que tingui un munt de aquests en l'interior del seu ordinador. Però el menjar per emportar és aquí és totalment electrònica. Només hi ha electrons que flueix en aquest dispositiu. Per contra, si mirem l'interior d'un disc dur i tiri cap amunt una imatge aquí, ho faria en el seu lloc veure alguna cosa com això, que sí que té electricitat en última instància, a través d'ell. Però el que també salta a la vista a vostè sobre aquesta cosa? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, hi ha pel que sembla, les peces en moviment. És una cosa així com un vell disc jugador o jugador fonògraf. I és més o menys. És una mica més elegant que queda mentre que un jugador fonògraf utilitzat ranures en el registre, en realitat això utilitza partícules magnètiques petites diminutes que no podem veure bé. Però si una mica de partícules magnètiques s'assembla a això, es considera gener 1. I si es veu com aquest, nord-sud en lloc de sud a nord, que podria ser un 0. I veurem demà com podem construir d'aquí a les coses més interessants. Però tot el que és ha de moure físicament segurament va a anar més lent que la velocitat de la llum, que en teoria és el un electró podria fluir a, encara que no del tot realista. devices-- de manera mecànica molt més lent. Però són més barats. I vostè pot cabre tant més dades dins d'ells. Així que el fet que hi ha que hi ha al món alguna cosa anomenada memòria virtual, l'ús d'un disc dur com aquest com si fos RAM transparent per a l'usuari, simplement mitjançant el moviment de dades des de la RAM al disc dur, a continuació, movent cap enrere quan es necessita una altra vegada, crea la desacceleració. A causa que té literalment copiar-lo d'un lloc a un altre. I el que estàs còpia a través de és en realitat més lenta que la RAM allà on sigui. La solució alternativa aquí-- si no us agrada que reduir la velocitat, i la memòria virtual és classe d'ésser sobrecarregat, Quin és una altra solució a aquest problema? AUDIÈNCIA: [inaudible] DAVID Malan: Bé, l'augment de la memòria virtual que fem això en una escala encara més gran. Podríem gestionar 66 gigabytes de les necessitats de memòria, o 67 gigabytes. Però suposo que no m'agrada aquesta desacceleració, de fet Vull desactivar virtuals memòria si això és possible, Què més podia llançar a aquest problema per resoldre-ho, on vull gestionar més usuaris i més requisits de memòria que tinc físicament en aquest moment? AUDIÈNCIA: [inaudible] DAVID Malan: Malauradament no. Pel que la CPU i els nuclis de Son en són un recurs finit. I no hi ha anàleg en aquest context. Bona pregunta, però. Així que per ser clar, també, si dins d'aquest equip és, diguem, un pal de memòria RAM que es veu així- i així ho anem a cridar aquesta memòria RAM. I aquí és la unitat de disc dur. I només vaig a trucar aquesta pictòricament com un petit cercle. Hi ha de 0 i 1 d'en ambdós these-- de dades, anem a generalitzar com. I, essencialment, si un usuari és executar una aplicació com, diguem, un lloc web que requereix aquest la quantitat de RAM per usuari, el que estic proposant, per mitjà d'aquesta cosa anomenada memòria virtual, és moure només temporalment que per aquí pel que ara pot moure la memòria d'una altra persona requisits allà. I després, quan es fa això, Puc copiar aquest per sobre del i això va aquí, movent amb això el que volia en aquest país a un altre lloc en conjunt. Així que hi ha només un munt de switcheroo, és el menjar per emportar aquí. Així que si no us agrada això, i no ho fa vol posar res al disc dur, el que és una espècie del que és obvi La solució de la persona de negocis al problema, o l'enginyer de solució, per al cas, també? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, vull dir, literalment, llençar els diners en el problema. I, de fet, aquesta és la perfecta segue a alguns de nivell superior discussions de la computació en núvol. A causa de que molts d'ells està motivat per les decisions financeres, ni tan sols necessàriament tecnològic. Si 64 gigues de RAM és massa poc, bé, per què no obtenir 128 gigabytes de memòria RAM? Per què no aconseguir 256 gigabytes de memòria RAM? Bé, per què no? AUDIÈNCIA: [inaudible] DAVID Malan: Bé, costa més diners, és clar. I si ja té recanvi espai en el disc dur, de manera efectiva, o equivalentment, espai en disc dur és tan molt més barat que també podria utilitzar-lo. Així que de nou, hi ha una compensació que vam veure encara més d'hora al matí, on no hi ha realment necessàriament una resposta correcta, només hi ha una resposta millor o pitjor en base al que realment importa. Així també hi ha realitats tecnològiques. No puc comprar un ordinador, que jo sàpiga, amb un bilió de gigabytes de RAM en aquest moment. És només físicament no existeix. Així que hi ha una certa cota superior. Però si alguna vegada has fins i tot va fer compres per a un consumidor Mac o PC, també, generalment hi ha aquesta corba de característiques en les que podria ser una bona, una millor i un millor equip. I els rendiments marginals en la seva compra de dòlars el millor equip davant el millor equip podria no ser tan alta com passar una mica més de diners i aconseguir el millor equip sobre el bon ordinador. En altres paraules, està pagant una primera per a obtenir la part superior de la línia. I el que veurem en el discussió de la computació en núvol és que el que és molt comú en aquests dies, i el que companyies com Google popularitzat des del principi, no estava prestant per a la construcció i realment de luxe, cars el falsejament dels ordinadors amb una munts i munts de tot, sinó més aviat la compra o construcció de bastant equips modestos, però molts d'ells, i l'ús d'alguna cosa que és generalment anomenada escala horitzontal en comptes de l'escala vertical. Així escalat vertical significaria obtenir més RAM, disc més, més de tot, i una espècie d'invertir verticalment en el seu maquinari pel que acaba d'entrar al millor dels millors dels millors, però que està pagant per això. l'escala horitzontal és una espècie d'obtenir el coses graderia inferior, el bon model, o fins i tot el pitjor model, però aconseguir un munt d'ells. Però tan aviat com s'obté gran quantitat de ells-- per exemple, en aquest cas, servidors web, si un servidor o un lloc d'acollida és insuficient, a continuació, només intuïtivament, la solució a aquest problema de càrrega o sobrecàrrega dels servidors és o bé aconseguir un servidor més gran o, el que estic proposant aquí en comptes d'escalar verticalment per així dir-ho, seria, saps què? Acaba d'obtenir una segona d'aquestes. O potser fins i tot obtenir una tercera. Però ara que hem creat un problema d'enginyeria per la naturalesa d'aquest negoci o decisió financera. Quin és el problema d'enginyeria ara? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, com fer connectar-i- ho sento? AUDIÈNCIA: [inaudible] DAVID Malan: Dreta, perquè encara tener-- si jo em reintroduir en aquesta imatge, si aquest és el meu ordinador portàtil en algun lloc en l'Internet, que ara està entre la companyia i jo estem parlant, ara he de esbrinar, a la qual servidor puc enviar aquest usuari en particular? I si hi ha altres usuaris, com això, i llavors aquest per aquí, i potser aquest és l'usuari A, aquest és l'usuari B, aquest és l'usuari C, i aquest és el servidor 1, 2, i ara 3-- una resposta intuïtiva podria ser just aquí, es lliurarà a l'usuari A 1 i B a 2 i C a 3. I podem gestionar 3 vegades el nombre d'usuaris. Però això és una simplificació excessiva. Com es decideix qui enviar on? Així que anem a tractar de raonar a través d'aquest. Així que suposem que els ordinadors A, B, i C són clients, i servidors d'1, 2, i 3 són horitzontalment reduït servidors. Pel que són una mena de idèntica. Tots estan executant el mateix programari. I que poden fer la mateixa cosa. Però la raó per la qual tenim tres d'ells és pel que podem gestionar 03:00 vegades el nombre de persones alhora. Pel que sabem de la nostra discussió abans del dinar que hi ha maquinari entre els ordinadors portàtils i els servidors. Però només haurem de tipus de generalitzar que ara, com Internet o el núvol. Però sabem que a casa meva, és probable que hi hagi un router a casa. A prop dels servidors, és probable que hi hagi un router, servidor DNS, DHCP. No hi pot haver res que volem en aquesta història. Llavors, com començar a decidir, quan l'usuari A va a something.com, quin servidor per encaminar a l'usuari? Com podem començar a explicar aquesta història? PÚBLIC: L'equilibri de càrrega? DAVID Malan: L'equilibri de càrrega. Que vols dir amb aixó? AUDIÈNCIA: Tornant on l'ús és més i la que es té la la majoria dels recursos disponibles. DAVID Malan: OK, així que permetin-me introduir un nou tipus de maquinari que encara no hem discutit, el qual és exactament això, 01:00 equilibrador de càrrega. Això també podria ser només un servidor. Podria ser exactament igual la que vam veure fa un moment. Un equilibrador de càrrega és molt només una peça de programari que s'executa en una peça de maquinari. O es pot pagar a un venedor, com Citrix o altres, Cisco o altres. Vostè pot pagar pel seu propi maquinari, que és un equilibrador de càrrega de maquinari. Però això només vol dir que pre-instal lat l'equilibri de càrrega programari en el seu maquinari i va vendre a tots vostès junts. Pel que només haurem de dibuixar com una rectangle per als nostres propòsits. Com ara puc implementar un equilibrador de càrrega? En altres paraules, quan l'usuari A vol visiteu el meu lloc, d'alguna manera la seva sol·licitud o un altre, probablement per mitjà de les routers que parlem anteriorment, va a arribar, finalment, aquest equilibrador de càrrega, que després ha de prendre una decisió d'enrutament-similars. Però ha d'encaminament per ordenar d'un propòsit més alt ara. No es tracta només d'aconseguir des del punt A al punt B. Es tracta de decidir què el punt B és el millor entre ells-- 1, 2, o 3 en aquest cas. Llavors, com puc decidir si anar a 1, a 2, a 3? Com seria aquesta caixa de negre, de manera que parlar, estar fent a l'interior? Això també és un altre exemple en el ciències de la computació de l'abstracció. literalment, he dibuixat un equilibrador de càrrega com un quadre negre en tinta negre, a l'interior dels quals és una mica interessant lògica, o la màgia, fins i tot, dels quals ha de venir una a decisió 1, 2, o 3. I l'entrada és només A. AUDIÈNCIA: [inaudible] DAVID Malan: Ho sento? AUDIÈNCIA: [inaudible] DAVID Malan: Molt bé, com podem categoritzar els tipus de transaccions aquí? AUDIÈNCIA: la visualització d'una pàgina web davant de la consulta d'una base de dades. DAVID Malan: OK, això és bo. Així que potser aquest usuari A vol veure una pàgina web. I potser és fins i tot contingut estàtic, cosa que canvia poques vegades, o mai. I que sembla una operació bastant simple. Així que potser només haurem de forma arbitrària, però raonablement, per exemple, el servidor 1, el seu propòsit a la vida és que acaba de servir contingut estàtic, arxius que rares vegades, o mai, el canvi. Potser és les imatges de la pàgina. Potser és el text de la pàgina o altres tal tipus de coses sense interès, transaccional res, res dinàmic. Per contra, si l'usuari A està comprovant fora del seu carret de la compra que requereix una base de dades, un lloc per emmagatzemar i recordar que la transacció, així potser aquesta sol·licitud ha d'anar al servidor 2. I això és bo. Així que podem càrrega basat en l'equilibri del tipus de peticions. Com més podem fer això? el altre-- AUDIÈNCIA: Basat en el servidor de utilització i capacitat. DAVID Malan: Dreta, D'acord. Així que vostè ha esmentat anteriorment que, Kareem. Llavors, què si proporcionem alguna entrada en [inaudible] entre els servidors d'1, 2, i 3 d'aquest equilibrador de càrrega de manera que només estan constantment informant el equilibrador de càrrega el que és el seu estat? Igual que, bé, equilibrador de càrrega, Estic en la utilització del 50%. En altres paraules, no tinc la meitat dels usuaris com realment puc manejar-me en aquest moment. Hey, equilibrador de càrrega, estic al 100% d'utilització. Hey, equilibrador de càrrega, 0% d'utilització. El equilibrador de càrrega, si és dissenyat d'una manera que pot prendre en aquests comentaris com a entrada, es pot llavors decidir, ooh, el número 2 està al 100%. Permetin-me no enviar sol·licituds futures a ell a part dels usuaris ja connectats. Aquest tipus és del 0%. Anem a enviar una gran quantitat de trànsit a el. Aquest home va dir que està en el 50%. Anem a enviar una mica de trànsit a ell. Així que seria un ingredient, que podríem prendre en compte la càrrega. I que canviarà amb el temps. Així que les decisions canviaran. Així que aquesta és una molt bona tècnica, un que s'utilitza habitualment. Quina altra cosa podíem fer? I anem a resumir en realitat només aquí. Per tant les decisions que aquí podrien ser per tipus de trànsit, el trucaré. Pot estar basada en la càrrega. Anem a veure si no podem pujar amb alguns altres. AUDIÈNCIA: [inaudible] DAVID Malan: Ubicació. Així que és una bona idea. Així ubicació: ¿com podria aprofitar aquesta informació? AUDIÈNCIA: [inaudible] DAVID Malan: Oh, això és bo. I sobre el nombre de milisegons seria disminuir per en base al que vam veure aquest matí, li diria? AUDIÈNCIA: [inaudible] DAVID Malan: Bé, basada en les rutes de rastreig hem vist anteriorment, que és just una mesura aproximada d'alguna cosa, almenys el temps que triga per a les dades per arribar de A a B se sent com una cosa local era, el que, com 74 milisegons, més o menys? I després res 100 més, 200 més probablement a l'estranger. I així, basant-se que per si sola, sembla raonable suposar que per a un usuari en els EUA accedir a un servidor Europea podria prendre dues o tres vegades sempre, fins i tot en mil·lisegons, del que podria prendre en cas que servidor es troba aquí geogràficament, o viceversa. Així que quan em vaig proposar anterior que especialment Una vegada que encreuament que 200 mil·lisegons llindar, més o menys, els éssers humans comencen a notar. I el traçat de ruta és simplement suposant, dades sense interès primeres. Quan vostè té un lloc web, vostè ha de aconseguir que l'usuari la descàrrega d'imatges o pel·lícules arxius, gran quantitat de text, les sol·licituds posteriors. Vam veure quan vam visitar, el que era que, Facebook o Amazon anterior, hi ha un munt de coses que necessita ser descarregat. Així que va a sumar. Així multi-segons podria No seria raonable. Així que bo, la geografia és un dels ingredients. Per tant en les empreses com de fet Akamai, si has sentit parlar d'ells, o que altres han considerat durant molt de temps geografia en compte. I resulta que per la naturalesa d'una adreça IP, l'adreça IP del meu ordinador portàtil, es pot inferir, amb certa probabilitat, en quina part del món. I, de fet, no hi ha Serveis de tercers li pot pagar que mantenen bases de dades d'adreces IP i geografies que amb alta confiança serà cert quan se li va preguntar, en quin lloc del món és aquesta adreça IP? I així, de fet, el altres empreses utilitzen això? Si vostè té Hulu o Netflix, si Alguna vegada has estat viatjant a l'estranger, i intenta veure alguna cosa en Hulu, i vostè no està en els EUA, és possible que aparegui un missatge a dir, no als EUA .. Ho sentim, no pots veure aquest contingut. AUDIÈNCIA: [inaudible] DAVID Malan: De debò? Però sí, el que en realitat això és una aplicació perfecta d'una cosa molt tècnic a un problema real. Si es va a VPN des Europa o Àsia o en qualsevol lloc en el món per la seva corporatiu seu central a Nova York o on sigui que siguis, ets crearà l'aparença a llocs web externs que en realitat estàs a Nova York, tot i que ets físicament bastant lluny. Ara que l'usuari va a sap que està òbviament lluny. Però també es va a sentir perquè d'aquests mil·lisegons addicionals. Aquesta distància addicional i la xifrat que està succeint a la VPN es va a retardar les coses. Pel que poden o no poden serà una gran experiència. No obstant això, Hulu i Netflix veuran que com seure en algun lloc de Nova York, com s'hagi claredat obtinguda. El que és una perfecta solució per això. Molt bé, pel que la geografia és una decisió. Què més podríem utilitzar per decidir com per encaminar el trànsit de l'A, B, i C a 1, 2, i 3, de nou, posar el barret de l'enginyeria en? Tot això sona molt complicat. Uh, jo no sé ni per on per començar a implementar aquests. Dóna'm alguna cosa que és més simple. Quina és la forma més senzilla per prendre aquesta decisió? AUDIÈNCIA: Està disponible al servidor? DAVID Malan: Està disponible al servidor? Així que no està malament. Això està bé. En certa manera és una matisació de càrrega. Així que anem a mantenir que en la categoria de càrrega. Si està disponible, només sóc va a enviar les dades allà. Però això podria ser contraproduent ràpidament. Perquè si ús aquesta lògica, i si Sempre pregunti a 1, està vostè, ¿està vostè en, està vostè, si la resposta és sempre sí, Vaig a enviar 100% del tràfic a ell, 0% a tots els altres. I en algun moment, anem a colpejar que la desacceleració o no està disponible el lloc. Llavors, què és una mica millor que que però encara bastant simple i no és tan intel·ligent com tenint tots aquestes dades addicionals en compte? AUDIÈNCIA: Cost per servidor. DAVID Malan: Cost per servidor. OK, així que em moc que en la categoria de càrrega, també. A causa del que trobarà a una empresa, també- que si actualitzar els seus servidors amb el temps o comprar més, pot ser que no sigui capaç d'obtenir exactament les mateixes versions de maquinari. Perquè cau fora de data. No es pot comprar més. Els preus canvien. El que podria tenir servidors dispars al clúster, per dir-ho. Això és totalment bé. Però el maquinari de l'any que podria ser el doble de ràpid, dues vegades tan capaç com la d'aquest any. Així que podem tirar que en la categoria de càrrega. Aquest bucle de retroalimentació entre 1, 2 i 3 en l'equilibrador de càrrega Certament es podria dir que, Hey, estic en capacitat de 50%. Però per cert, també tenir el doble de nuclis. Utilitzar aquesta informació. Fins i tot simpler-- i això va sent un tema de la informàtica. En cas de dubte, o quan es desitja un simple solució que generalment funciona bé amb el temps, no triï la mateixa servidor tot el temps, però choose-- AUDIÈNCIA: a l'atzar? DAVID Malan: --un servidor aleatori. Sí, triar un o altre. Així aleatorietat és en realitat aquest ingredient molt potent en ciències de la computació, i en l'enginyeria més en general, especialment quan es desitja per prendre una decisió senzilla ràpida sense complicar amb tot d'elles molt intel·ligent, però també molt intel·ligents, solucions que requereixen encara més l'enginyeria, tot com més pensament, quan Realment, per què no em només una mica de llançar una moneda, o un tres cares de la moneda, en aquest cas, i decidir si anar 1, 2, 3? Això podria ser contraproduent probabilísticament, però igual que les probabilitats en el llançament del cap de nou i una i altra vegada i una altra i una vegada i una altra que és possible en reality-- súper, súper poc probable. Així que amb el temps, les probabilitats són simplement enviar als usuaris a l'atzar a 1, 2 i 3 es va a treballar perfectament bé. I aquesta és una tècnica generalment conegut com round robin. O en realitat, això no és round robin. Aquest seria l'enfocament aleatori. I si vols ser encara una mica més simple que això, round robin seria, en primer persona va a 1, segona persona per a 2, tercera persona a 3, quarta persona a 1. I aquí està el round robin. Vostè només tipus de gires en un cicle. Ara, vostè ha de ser intel ligent sobre això. Vostè no ha d'enviar a l'usuari a cegues Nombre de servidor d'un si ho és el cas? Si és en la capacitat màxima, o és simplement ja no responen. Així que l'ideal és que vol una mica tipus de bucle de realimentació. Altrament, simplement envia tot dels seus usuaris a un carreró sense sortida. Però això pot ser tingut en compte, també. Així que no es podran aprofitar per sota del valor de acaba d'aleatorietat, que és molt sovint una solució a aquest tipus de problemes. I anem a escriure baix round robin. Llavors, com posar en pràctica algunes empreses round robin o aleatorietat o qualsevol d'aquestes decisions? Bé, per desgràcia, fer coses com aquesta. Déjame treure una altra captura de pantalla ràpid. En realitat, farem dos. No sé per què estem aconseguir tots aquests plats. Això és molt estrany. Està bé, el que realment és una captura de pantalla que desitgi. Això és estrany. Molt bé, així que pot suplantar això. No sé quant més lluny Vull mantenir el desplaçament. Així que amb molta freqüència, es trobarà en una direcció com www.2.acme.com, potser www.3 o 4 o 5. I mantenir un ull per això. No ho veu tan sovint. Però quan ho fa, és com que tendeix a ser més gran, més vell, empreses stodgier que en realitat no tecnològicament semblen saber el que estan fent. I veu això en les empreses de tecnologia De vegades, els de més edat. Llavors, què estan fent? Com estan implementant balanceig de càrrega, ¿us semblaria? Si vostè es troba com el www.something.com usuari escriure, i de sobte estàs en www.2.something.com, el que té la seva càrrega equilibrador probablement fet? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, per la qual cosa la equilibrador de càrrega és de suposar prendre una decisió basada en una de aquests fent processes-- decisió en realitat no importa quin. Però de la mateixa manera que he dibuixat la nombres en el tauler aquí, els servidors no són només trucada 1, 2, i 3. Probablement estan cridats www1, www2, www3. I resulta que a l'interior de una petició HTTP és aquesta característica. I vaig a simular aquest com segueix. Vaig a obrir aquesta mateixa pestanya xarxa de desenvolupadors que abans només perquè puguem veure el que està passant de sota el capó. Vaig a netejar la pantalla. I vaig a anar, anem a a dir, http://harvard.edu. Ara per qualsevol raons de negocis, Harvard ha decidit, com molts, molts altres llocs web, estandarditzar la seva lloc web en www.harvard.edu tant per la tècnica i les raons de màrqueting. És només en el tipus de de moda per tenir la www. Pel que el servidor de la Universitat de Harvard té per redirigir d'alguna manera l'usuari, com segueixo dient, des un URL a l'altra. Com funciona això? Bé, deixa anar per davant i prem enter. I observi l'URL de fet ràpidament canviat a www.harvard.edu. Déjame desplaçar-se cap enrere en aquest història i feu clic en aquest depuració informació de diagnòstic, si es vol. Vull veure a la meva petició. Així que aquí està la sol·licitud que vaig fer. I noti que és consistent amb el tipus de la sol·licitud que vaig fer de Facebook abans. Però noti la resposta. El que és diferent en la resposta aquest cop? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, així que no és un 200 OK. No és un 404 Not Found. És un 301 Mogut permanentment, la qual cosa és una espècie d'una manera divertida de dir, Harvard ha pujat i es va traslladar en altres llocs per www.harvard.edu. Els 301 vol dir que això és una redirecció. I on l'usuari ha de sembla ser redirigit? Hi ha una dada addicional de informació dins d'aquest sobre. I cadascuna d'aquestes línies ara comença a cridar a una capçalera HTTP. Capçalera és només un valor de clau pair-- una mica de còlon alguna cosa. És una peça d'informació. On és el nou ubicació semblar ser? Observi l'última línia entre totes aquelles capçaleres. AUDIÈNCIA: [inaudible] DAVID Malan: Sí, pel que hi ha informació adicional. La primera línia que He destacat 301 Moveu diu de forma permanent. Bé, on els ha mogut? L'última line-- i no ho fan ha de ser en aquest ordre. Pot ser aleatori. Ubicació de còlon vol dir, ei navegador, aneu a aquesta adreça URL al seu lloc. Així navegadors entenen redireccions HTTP. I aquest és un molt, molt forma comuna de rebot l'usuari d'un lloc a un altre. Per exemple, si vostè ha intentat alguna vegada per visitar un lloc web que no està iniciat la sessió al, pot trobar-se de cop i volta vostè mateix en una nova adreça URL complet sent se li demana que ingressi. Com funciona això? El servidor és, probablement, l'enviament d'un 301. També hi ha altres nombres, com 302, alguna cosa diferent en el significat, que enviï a una altra adreça URL. I a continuació, el servidor, una vegada que hagi entrat en el sistema, li enviarà de tornada al lloc on en realitat es pretén. Llavors, què, doncs, són pobrament llocs web d'enginyeria fent? quan visita www.acme.com, i que només passa que té el nom dels seus servidors www1, www2, www3, i així successivament, que són molt simply-- que és just, però molt tipus de foolishly-- de tornar a dirigir a un servidor de realitat diferent nom. I funciona perfectament bé. És agradable i fàcil. Hem vist com seria fet sota de la campana en el sobre virtual. Però ¿per què és això possiblement una mala decisió d'enginyeria? I per què estic espècie de condescendència cap a aquest particular de l'enginyeria acostar-? Argumentar per què això és dolent. Ben? AUDIÈNCIA: [inaudible] DAVID Malan: Cada servidor hauria de tenir un duplicat de la pàgina web. Estic d'acord amb això. I de fet, això és el que sóc suposant per a tota aquesta història, ja que si bé wanted-- de fet, a excepció de Dan abans de suggeriment, en la qual si vostè té diferents servidors de fer les coses diferents, a continuació, potser ells podrien ser en realitat funcionalment fer les coses diferents. Però fins i tot llavors, en algun moment, la seva base de dades va a sobrecarregar-se. La seva estàtica del servidor actius va a sobrecarregar-se. Per tant, en algun moment, estem de tornada en aquesta història, en la qual necessitarà diverses còpies d'una mateixa cosa. Així que estic d'acord amb això. AUDIÈNCIA: [inaudible] DAVID Malan: OK, de manera que algunes pàgines podria ser desproporcionadament popular. I així fixar-se en una direcció no és necessàriament el millor. [Inaudible]? AUDIÈNCIA: [inaudible] DAVID Malan: Què vol dir amb això? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, exactament. Pel que no vol necessàriament que sens dubte tener-- no volen que els seus usuaris escriure manualment en www1 o www2. Des d'una perspectiva de marca, es només es veu una mica ridícul. Si el que desitja és una espècie de net, elegant experiència, que té aquest tipus d'atzar URL numerades realment no és bo. Perquè llavors els usuaris són, sens dubte va a copiar i enganxar en correus electrònics o missatges instantanis. Ara s'estan propagant. Ara que estàs tipus de confondre la seva menys audiència tècnica, que pensa la seva adreça web és www2.something.com. No hi ha cap semàntica de pes per a això. Que només passa a ser un subjacent detalls tècnics que vostè té numerada seus servidors d'aquesta manera. I el que és pitjor, ¿i si, per exemple, potser al voltant de l'època de Nadal, quan negoci està realment en auge, tens www1 través www99, però al gener i febrer i des d'ara, s'apaga la meitat dels de manera que només té www1 través www50? Quina és la implicació que ara decisió de negocis molt raonable? AUDIÈNCIA: [inaudible] DAVID Malan: Cal gestionar tots els que segueixen. AUDIÈNCIA: [inaudible] DAVID Malan: Exactament. Això és una espècie de la captura allà. Si els seus clients estan en l'hàbit de bookmarking coses, enviament per correu electrònic, simplement estalvi de la URL en algun lloc, o si és només en el seu acte completar en el seu navegador perquè estiguin no és realment escrivint intencionalment, és simplement passant, podrien, durant 11 mesos a l'any efectivament, arribar a un carreró sense sortida. I només el més astut de els usuaris es van a donar compte, potser hauria manualment suprimir aquest número. Vull dir, simplement no va a succeir amb molts usuaris, per la qual dolents per als negocis, mala aplicació d'enginyeria intel·ligent. Així que per sort, no és ni tan sols necessari. Resulta que el equilibradors de càrrega poden fer és en lloc de dir, quan A realitza una request-- i i A, aneu a 1. En altres paraules, en comptes de l'enviament d'aquest redireccionament de tal manera que el pas un en aquest és el procés d'anar aquí, A continuació, se li diu que anar a un altre lloc. I així el pas 3 és a dir, que va a una altra banda. En el seu lloc pot seguir la ruta, a seguir fent servir aquest terme, totes les dades d'una mitjançant el equilibrador de càrrega de manera que ell mai els contactes 1, 2, 3 o directament. Tot el trànsit té "enviats" pel equilibrador de la càrrega en si. I pel que ara estem espècie de esborrant deliberadament les línies Entre aquests diversos dispositius. Un equilibrador de càrrega pot d'utilitzar dades. És només una funció que té. Pel que un equilibrador de càrrega, també, és una peça de programari, de veritat. I un router és una peça de programari. I vostè pot tenir absolutament dues peces de programari dins de d'un equip físic de manera que una càrrega equilibrador pot fer aquestes coses múltiples. Així que hi ha una altra manera per fer això, que en realitat es remunta a la classe de primers principis de DNS, el que ens referim abans de les vacances. DNS Sistema de Noms de Domini. Recordi que pot demanar a un servidor DNS, el que és l'adreça IP del google.com, facebook.com? I que realment podem fer això. Una eina que no fem servir anterior és un que és tan accessible, denominada nslookup, per a la recerca de servidor de noms. I jo només vaig a escriure facebook.com. I veig que la propietat intel·lectual de Facebook Direcció aparentment és això. Déjame anar per davant i copiar que, anar a un navegador, i vagi a http: // i que adreça IP i premeu Enter. I, efectivament, sembla que funciona. Ara treballant cap enrere, el que era dins de l'envoltant virtual que va respondre amb Facebook quan Vaig visitar que aborda directament IP? A causa avís, ¿on sóc ara? On sóc ara, la direcció? AUDIÈNCIA: [inaudible] DAVID Malan: En la versió segura, i en el www.facebook.com. Així que no és fins i tot només l'adreça IP segura. Facebook ha pres sobre si mateix dir, això és ridícul. No anem a mantenir-lo en aquest URL lletja aparença que és numèric. Anem a enviar un HTTP redirigir a través de la mateixa capçalera que vam veure abans-- ubicació alguna cosa còlon. I així, això simplement vol dir que per sota el capó segueix sent aquesta adreça IP. Cada ordinador a Internet té una adreça IP, el que sembla. Però no necessàriament ha per exposar que per a l'usuari. I de la mateixa manera que en el seu dia, hi ha Va ser 1-800-COLLECT, 1-800-C-O-L-L-I-C-T, als EUA, era una forma de fer de cobrament a destinació trucades a través d'un telèfon molt fàcil de recordar número, o al 1-800-Mattress per comprar un llit, i mnemotècnics similars que fins i tot es veuen al telèfon tipus d'espècie de encara, que les lletres s'assignen als nombres. Ara, per què? Bé, és molt més fàcil de memoritzar 1-800-matalàs o al 1-800-COLLECT vegada de 1-800 alguna cosa alguna cosa alguna cosa alguna cosa alguna cosa alguna cosa alguna cosa, on cada dels quals és un dígit. De la mateixa manera, el món va aprendre ràpidament que no hem tenen gent memoritza les adreces IP. Això seria una ximpleria. Utilitzarem els noms de lloc. I és per això va néixer DNS. Molt bé, així que amb això va dir, en termes d'equilibri de càrrega, tractarem de yahoo.com. Bé, això és interessant. Yahoo sembla estar tornant tres direccions IP. Així inferir d'això, si pogués, el que és Una altra forma en què podríem aplicar aquesta noció d'equilibri de càrrega potser fins i tot sense utilitzar un examen físic dispositiu, aquest nou dispositiu físic? En altres paraules, puc treure el finançament que té per al equilibrador de càrrega i li dirà a utilitzar algunes existent peça de maquinari per implementar aquesta noció d'equilibri de càrrega? I l'aleró és, Sí, però què, o com? Què és Yahoo potser fent aquí? Kareem? OK, Chris? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, tot tres dels treballs. Així aleatorietat, round robin, ubicació: només es pot aprofitar una peça existent del trencaclosques que hem parlat abans del DNS sistema i simplement dir, quan la primera usuari del dia sol·licita yahoo.com, donar-los la primera adreça IP, com el que s'acaba en 45 fins allà. I la propera vegada que un usuari sol·licita l'adreça IP del yahoo.com des d'algun lloc del món, donar-los el segon IP, llavors la tercera IP, llavors el primera IP, llavors el segon. O ser intel·ligent al respecte i fer-ho de forma gràfica. O fer-ho de forma aleatòria i no només fer es round robin d'aquesta manera. I en aquest cas, a continuació, que ni tan sols ens cal introduir aquest negre la caixa dins la nostra imatge. No necessitem un nou dispositiu. Simplement estem dient als ordinadors anar als servidors de forma directa, efectivament, però no per mitjà del seu nom. Ells mai necessiten saber el nom. Ells simplement estan dient que yahoo.com Els mapes a qualsevol d'aquestes adreces IP. Pel que envia la mateixa petició exacta. Però a l'exterior de el sobre, simplement posa l'IP que se li va informar. I d'aquesta manera, també, podria que equilibren la càrrega de les sol·licituds només enviant el sobre a una un de diferent dels propis servidors de Yahoo? I si mantenim l'excavació, ja veurem probablement altres empreses de més. CNN ha exposat públicament dues. Encara que en realitat, si fem això una altra vegada i una altra vegada-- cnn.com-- es pot veure que estan canviant fi, en realitat. Llavors, quin és el mecanisme CNN usant, pel que es veu? AUDIÈNCIA: Random. DAVID Malan: Bé, podria ser aleatòria, tot i que sembla ser un cicle d'anada i tornada. Així que és probable que l'operació per torns on que només estan canviant l'ordre de manera que vaig a suposar que el primer tom. El meu equip es durà la primera cada vegada. Així que aquest és l'equilibri de càrrega. I això ens permet, en última instància, per mapejar les dades, o les sol·licituds de mapes, a través de múltiples servidors. Llavors, quin tipus de problemes que ara existeixen encara? Se sent com que realment resolt un bon problema. Arribem als usuaris a diferents servidors. Pero-- oh, i Chris, va fer Té una pregunta abans? AUDIÈNCIA: [inaudible] DAVID Malan: depèn totalment. Llavors, què està passant aquí? I en realitat podem veure això. Així que anem a tractar de Yahoo. En realitat, anirem a Facebook. Perquè sabem que un treballa. Així que vaig a copiar que l'adreça IP de nou. Vaig a tancar totes aquestes fitxes. Vaig a anar a veus que pestanya de xarxa especial aquí baix. I vaig a visitar només http: //. I ara vaig a pressionar Enter. I anem a veure el que va passar. Si miro a aquesta petició, la notificació mi-- que Facebook és un mal exemple. A causa de que tenen una tècnica de super luxós que amaga aquest detall de nosaltres. Permetin-me utilitzar Yahoo instead-- http: // que la propietat intel·lectual. Obrirem la nostra xarxa pestanya, preservar registre. I aquí anem, ENTER. És graciós. OK, així que aquí està el missatge famós 404. El curiós aquí és que es probablement mai estarà de tornada. A causa de que és probable que hi hagi No una cosa dolenta per se. Tenen de manera deliberada va decidir no donar suport la forma numèrica de la seva direcció. Així que el que en realitat estem veient en el fitxa Xarxa, si tir això aquí, és, com dic, el famós 404, on si miro les capçaleres de resposta, això és el que em van donar aquí-- 404 no trobat. Així que anem a provar una altra. Ja veurem si la CNN coopera amb nosaltres. Vaig a agafar una de les adreces IP de la CNN, clar aquesta, http, bla bla, bla bla. Així que en resposta a Chris de pregunta, que un va treballar. I anirem a les capçaleres de resposta. En realitat no, està bé, jo sóc lluitant per trobar un exemple de treball. Així CNN ha decidit, només haurem de deixem en qualsevol direcció que en realitat visitar, qüestions de marca a un costat. Però el que no estaria succeint, si el vam poder veure en el cas de Facebook, està ens trobarem amb un 301 Moved De forma permanent, el més probable, dins dels quals és Ubicació: https: //www.facebook.com. I les probabilitats són www.facebook.com és una àlies per al mateix servidor que acabem exacta anar a. Així que és una mica contraproduent. Estem, literalment, visitant el servidor. El servidor està a continuació, ens diu, desapareix. Aneu a aquesta altra direcció. Però acabem de manera toca estar tornar a aquest mateix servidor. Però és de suposar que ara romanen en aquesta servidor sense aquest anar i venir. Perquè ara estem fent servir la nomenem versió del lloc, no el numèric. Bona pregunta. OK, així que si ara ens assume-- s'han resolt l'equilibri de càrrega. Ara tenim un mecanisme, ja sigui a través de DNS, ja sigui a través d'aquest quadre de negre, ja sigui es tracta d'utilitzar qualsevol d'aquestes tècniques. Podem prendre una petició de l'usuari i esbrinar a quin servidor, 1, 2, o 3, a ell o ella enviar. El que comença a trencar la nostra web? En altres paraules, tenim construït un negoci que estava anteriorment en un únic servidor. Ara que el negoci està en marxa a través de múltiples servidors. Quin tipus de supòsits, quin tipus de decisions de disseny, Ara podria estar trencant? Això és menys evident. Però anem a veure si no podem posar la nostra dit en alguns dels problemes que hem creat per nosaltres mateixos. De nou, és una cosa així com la celebració d' per la fuita a la mànega. I ara un nou tema ha aparegut per aquí. AUDIÈNCIA: [inaudible] DAVID Malan: OK, així que hem de mantenir el creixement del nostre espai al disc dur. Estic d'acord amb això en aquest moment. Perquè crec que puc l'escala horitzontal. Igual que si estic corrent baix, només vaig a aconseguir una quarta servidor, potser un cinquè servidor, i després augmentar la nostra capacitat per un altre 30% o 50% o el que sigui. Així que estic d'acord amb això, almenys per ara. AUDIÈNCIA: [inaudible] DAVID Malan: OK, així que és un bon punt. Així que suposem que els servidors no són idèntics. I servei al client o el correu electrònic equivalent és aconseguir una mica de missatge d'un usuari dient, això no està funcionant bé. És molt possible que, de vegades, que potser un o més servidors està actuant una mica malament, però no els altres, el que sens dubte pot fan que sigui més difícil de perseguir la qüestió. És possible que hagi de buscar múltiples llocs. És a dir manifestació d'un altre tipus d'insecte, i és que probablement hauria han dissenyat la seva infraestructura per tot el que és realment idèntica. Però sí revela un nou problema que no teníem abans. Què més? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, hi ha més complexitat. Hi ha físicament més cables. Hi ha un altre dispositiu. De fet, he introduït un element fonamental concepte i un problema fonamental aquí conegut com un únic punt de fallada, el qual, fins i tot si vostè mai ha sentit la frase, probablement pugui Ara treballar cap enrere i esbrinar-ho. Què vol dir que tinc una sola punt de fallada en la meva arquitectura? I en l'arquitectura, només significar la topologia de la mateixa. AUDIÈNCIA: [inaudible] DAVID Malan: Sí, i si el equilibrador de càrrega deixa de funcionar? He inserit aquest home la mitjana propòsit en la vida és per resoldre un problema. Però he introduït un nou problema. Una nova filtració ha sorgit en la mànega. Perquè ara si l'equilibrador de càrrega mor o es trenca o misfunctions, Ara perdo l'accés a els tres de les meves servidors. I abans, no ho vaig fer tenir aquest intermediari. I pel que aquest és un problema nou, sens dubte. tornarem a com podríem arreglar això. AUDIÈNCIA: [inaudible] DAVID Malan: Això seria un enfocament. Sí, i pel que aquest va a ser bastant forat de la rata vam començar a baixar. Però tornem a que en un moment. Quins altres problemes hem creat? Així Dan va esmentar base de dades abans. I fins i tot si no estàs tècnicament molt familiar, una base de dades és només un servidor on canviar les dades normalment s'emmagatzema, potser una ordre que algú ha col·locat, el seu perfil d'usuari, el seu nom, la seva adreça de correu electrònic, les coses que poden ser introduït o canviat amb el temps. Anteriorment, era la meva base de dades en el mateix servidor que el meu servidor web. A causa de que només tenia una compte d'allotjament web. Tot era al mateix lloc. On he de posar la meva base de dades Ara, en el servidor 1, 2, o 3? PÚBLIC: 4. DAVID Malan: 4, OK, tot bé, així que anem a anar-hi. Així que vaig a publicar el meu database-- i deixar de iniciar l'etiquetatge d'aquests www, www, www. I vaig a dir, aquest és el número quatre. I diré DB per a la base de dades. OK, m'agrada això. Quina línia he de presumiblement estar arribant aquí? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, per la qual cosa el codi, com veurem demà, presumiblement és el mateix en els tres servidors. Però ara necessita connectar-se no a una base de dades que s'executen localment però en altres llocs. I això està bé. Només podem donar a la base de dades d'una nomenar, com ho hem fet, o un nombre. I que tot funciona bé. Però què hem fet? Hem escalats horitzontalment per tenir tres servidors en lloc d'un, dels quals està bé. Perquè ara podem gestionar tres vegades més de càrrega. I millor encara, si un o dos d'aquests servidors cau, meu negoci pugui continuar funcionant. Perquè encara tinc un, fins i tot si estic tipus de coixejant pel que fa al rendiment. Però el nou problema que tenen introduït movent la base de dades a aquest servidor independent en lloc de en 1, 2, i 3? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, així que ara tinc un altre punt únic de fallada. Si la meva base de dades mor, o necessita actualitzar-se, o el que sigui, ara segur, la meva pàgina web està en línia. I puc servir estàtica, contingut que no canvia. Però no puc permetre que els usuaris accedeixin o el canvi res ni per a res, pitjor encara. 4 Perquè si és fora de línia, a continuació, 1, 2, i 3 Realment no es pot parlar amb ell per definició. Acceptar així que sí, i pel que aquesta és la raó Estic dubtant dibuixar això. Així que anem a tornar a això. No em refereixo a seguir empenyent fora vostè. No obstant això, el panorama és molt ràpidament va a aconseguir estressant. A causa de que necessita per començar tenir dues de tot. De fet, si alguna vegada has vist la Contacte pel·lícula fa uns anys amb Jodie Foster-- no? OK, així que per als dos nosaltres que hem vist de contacte, hi ha una relació allà on essencialment comprat dos d'alguna cosa en lloc d'un, encara que al doble del preu. Així que va ser una mena de lúdic comentar en la pel·lícula. És una espècie de relació amb això. Podríem fer absolutament això. I vostè acaba de cost som el doble de diners. Però anem a tornar a això. Per a això hem resolt aquest. Així que ja saben què? Això és com un pendent relliscosa. No vull haver de lidiar amb tenir una base de dades duplicada. És massa diners. Tu saps que? Vull tenir la meva base de dades de la mateixa manera que en la versió 1 on cada servidor té seva pròpia base de dades local. Així que només vaig a dibuixar dB en cadascuna d'elles. Així que ara cada un dels servidors web és idèntic en la mesura ja que té el mateix codi, el mateix actius estàtics, les mateixes imatges i text i així successivament. I cada un té la seva pròpia base de dades. He arreglat l'únic punt del problema de la decisió. Ara tinc una base de dades. No importa que dos o un d'aquests les coses moren, sempre hi ha una esquerra. Però el que tinc nou problema vaig crear que la solució de Dan evitar-se? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, han de sincronitzar ells, oi? Perquè, o que necessito per sincronitzar ¿Qui va where-- en altres paraules, si Alícia visita el meu lloc, i ella va passar per obtenir l'atzar o rodona robined o el que sigui, al nombre del servidor d'un, a partir de llavors he de sempre enviar-la al servidor 1. Per què? Perquè si li envio al servidor 2, que va perquè sembli que no hi ha allà. No vaig a tenir al seu historial de comandes. No vaig a tenir el seu profile aquí. I que només se sent com està convidant als problemes. I quan Bob visites, haver d'enviar sempre al mateix servidor, 2, o qualsevol un, i Charlie a un tercer, i consistent. Això no és raonable, però. Això es diu partir el vostre base de dades. I, de fet, això va ser el Facebook va fer des del principi. Si ha seguit la història de Facebook, que va començar aquí al campus com www.thefacebook.com. Després va evolucionar un cop Mark va començar estenent-se a altres campus ser harvard.thefacebook.com i mit.thefacebook.com, i probablement bu.thefacebook.com, i similars. I això va ser perquè des del principi, no crec vostè podria tenir amics a través dels campus. Però això està bé. Perquè qualsevol de Harvard va ser enviat a aquest servidor. Qualsevol persona de BU va ser enviat a aquest servidor. Qualsevol persona de MIT va ser expulsat a aquest server-- en teoria. No sé molt bé tot el detalls de la implementació. Però és de suposar que es va repartir per les persones el seu campus, on estava la seva xarxa. I això és bo fins al moment on necessita dos servidors de Harvard, o tres servidors per a Harvard. I després que la senzillesa tipus de falla. Però això és un enfocament raonable. Anem a enviar sempre Alice al mateix lloc, Sempre enviar a Bob al mateix lloc. Però, què passa si Alicia de servidor es tanca? Bob i Charlie encara es pot comprar coses i iniciar sessió en el lloc. Però Alice no pot. Així que vostè ha perdut un terç de la seva base d'usuaris. Potser això és millor que el 100%? Però potser seria bo si poguéssim Encara donar suport 100% dels nostres usuaris fins i tot quan un terç de la nostra servidors queda sense connexió. Així que podríem sincronitzar què? No els usuaris, per se, però la la base de dades a través de tots aquests servidors. Així que ara necessitem una mica de tipus de tipus d'interconnexió aquí, així que els propis servidors pot sync-- no excessiu. I de fet, aquesta tecnologia existeix. En el món de les bases de dades, no hi ha la noció de bases de dades mestre-esclau, o primària a la secundària, on entre les característiques no només per emmagatzemar dades i respondre amb les dades, sinó només per constantment sincronitzar entre si. Així que cada vegada que escriure o guardar cosa que aquesta base de dades, immediatament es fa "replicat" a les altres bases de dades, així. I cada vegada que en llegir-lo, no importa on es trobi. Perquè si en teoria Tots ells han sincronitzat, ets aconseguirà la mateixa vista de les dades. Així que això sona perfecte. Hi ha d'haver un parany. Quin podria ser el truc? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, per la qual cosa tres vegades com la quantitat de coses pot sortir malament. Això és una realitat. tot el que podria ser el mateix en esperit. Però algú ha de configurar aquests. Hi ha una major probabilitat que alguna cosa sortirà malament. Només té forma combinatòria més coses propens a errors. La resta és dolent potencialment? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, per la qual la sincronització pot ser dolent. Tot i que es pot saber les còpies de seguretat i tal, si el que està fent a cegues còpies de seguretat, el que si alguna cosa anar malament en una base de dades? S'elimina una cosa que no hauria. Vostè ha replicat immediatament aquest problema en qualsevol altre lloc. Així que Victòria estava còpies de seguretat talking-- seria una bona cosa aquí. I així ens posarem en contacte amb això. I perquè quedi clar, que estem parlant No es tracta de còpies de seguretat aquí per se. Estem parlant d'una veritable resposta o la sincronització a través de servidors. Estan tots en viu. No estan destinats a ser utilitzat per a còpies de seguretat. AUDIÈNCIA: [inaudible] DAVID Malan: Què és això? AUDIÈNCIA: Higher-- DAVID Malan: major cost. Hem triplicat el cost de Segur, encara que almenys en termes del maquinari. A causa que una base de dades és només una peça de programari. I un servidor web és una peça de programari. És probable que sigui lliure si estem fent servir qualsevol nombre de coses de codi obert. Però si estem utilitzant alguna cosa així com Oracle, estem pagant Oracle més diners per llicències o Microsoft per a l'accés. Hi ha d'haver algun altre truc aquí. No pot ser tan senzill. Així que per al seu punt, crec que va ser Kareem, per la geografia abans els vaig parlar o no, Romà, que era, per suposar geography-- que estem sent intel·ligents sobre això, i estem posant a un dels nostres servidors, I al seu torn les nostres bases de dades, als EUA, i un altre a Europa, en un altre Amèrica del Sud, un altre a l'Àfrica, una altra a Àsia, a qualsevol lloc que pot ser que vulgui a tot el món. Ja sabem de la nostra traça rutes que el punt A i el punt B, si estan més separats, es va a prendre més temps. I si alguns de vosaltres heu utilitzat eines, com Facebook o Twitter o qualsevol d'aquests llocs en aquests dies que estan canviant constantment a causa de usuari les dades creats, de vegades, si Recarregar colpejar o obrir la mateixa pàgina en un altre navegador, que es veu diferents versions, gairebé. És possible veure l'estat d'una persona actualitzar aquí, però no aquí, i després es torna a carregar, i després es apareix i torna a carregar de nou, i desapareix. En altres paraules, mantenir un ull a això, almenys si està usant socials especialment la creació de xarxes. Una vegada més, només perquè el dades està canviant tan ràpidament, De vegades els servidors no perden la sincronització. I potser és un super petita finestra. Però, potser 200 mil·lisegons fins i tot més del que és que- Va a portar el quantitat no nul·la de temps per aquestes bases de dades se sincronitzin. I no només estem parlant d'una petició. Si una empresa té milers de usuaris utilitzant simultàniament, que podrien esmorteir. En altres paraules, pot ser una cua o una línia d'espera abans que tots els que la base de dades consultes poden sincronitzar-se. Així que potser és en realitat un parell de segons. I de fet això és cert crec que fins i tot a dia d'avui amb Facebook, amb la qual cosa quan es sincronitzen des Costa est a la costa oest, que té un no trivial retard de propagació, per així dir-ho, que acaba de tipus d'haver de tolerar. I el que no és tant un error, ja que és una realitat que els usuaris no vegin les dades correctes per a, almenys, uns pocs segons. Ho veig a Twitter molt en realitat on de vegades vaig a piu en una finestra, obrir un altre per després veure-ho per confirmar que, efectivament, pujar, i que no hi és encara. I he de tipus de recarregar, recarregar, reload-- oh, aquí està. I això no és perquè no s'ha desat. Simplement no s'ha propagat a altres servidors. Així que aquesta disjuntiva, també- és el que realment voler exposar-se al risc que si l'usuari va a la seva fi la història, no és realment allà encara? Ho veig en certs bancs. Sempre em molesta quan, a més, per la seva banda, només es pot anar igual que fa sis mesos en els seus estats de compte bancaris en alguns bancs, tot i que en teoria haurien ser capaç de tenir tot en línia. Que acaba de prendre les coses fora de línia vegades. A vegades, el que demasiado-- pàgina web és? Hi ha un-- oh, és GoDaddy, crec. GoDaddy, quan es fa una ullada la compra d'un nom de domini o alguna cosa així, que sovint li donaran un enllaç al seu rebut. I si fa clic a aquest enllaç dreta de distància, sovint no funciona. Només diu, carreró sense sortida, res aquí. I això és també a causa de aquests retards de propagació. A causa de que per qualsevol raó, estan prenent una mica de temps per generar realment que. Així que això és una cosa així com vostè vol tirar dels pèls en algun moment. Perquè tot el que està tractant de fer és resoldre un problema senzill. I seguim creant nous problemes per nosaltres mateixos. Així que anem a veure si ens pot desfer aquest tipus de. Resulta que la combinació bases de dades en tots els servidors web no és realment la millor pràctica. En general, el que un enginyer faria, o arquitecte de sistemes, seria tenir diferents fileres de servidors. I només pel bé d'espai, vaig a dibuixar la seva base de dades aquí. Podríem tenir la base de dades i Nombre de servidor de quatre aquí que té connexions a cada un d'aquests servidors aquí. Pel que aquest podria ser el nostre front acabar de nivell, com diria la gent. I això seria el nostre nivell de back-end. I això només vol dir que aquests s'enfronten a l'usuari. I les bases de dades no s'enfronten a l'usuari. Cap usuari pot directament accedir a la base de dades. Així que ara pot ser que descendeixen la ruta Victòria va proposar. Es tracta d'un únic punt de fallada. Això em fa incòmode. Llavors, quin és potser el la solució més òbvia? AUDIÈNCIA: [inaudible] DAVID Malan: Malauradament, diuen que de nou. AUDIÈNCIA: [inaudible] DAVID Malan: servidor no de producció. Que vols dir? AUDIÈNCIA: [inaudible] DAVID Malan: Oh, està bé, de manera que les còpies de seguretat. D'acord, pel que podríem fer això, sens dubte. I en realitat això es realitza amb molta freqüència. Aquest podria ser el nombre de bases de dades de cinc. Però això és només comuniquin amb el número quatre. I que es podria anomenar un recanvi d'emergència. Aquestes dues bases de dades podrien estar configurats que acaba de sincronitzar constantment un altre. I pel que si aquesta màquina mor, per qualsevol que sigui estúpida reason-- el disc dur mor, algú es ensopega amb el espinal, alguns programari és defectuós i els bloquejos d'equip o crashes-- vostè podria tenir un humà, literalment, desconnecti aquest de la paret i en lloc d'endollar aquest en. I després dins de, diguem, un pocs minuts, potser mitja hora, que està de tornada en línia. No és gran, però tampoc és horrible. I vostè no ha de preocupar sobre qualsevol problema de sincronització. Perquè tot està ja allà. A causa que tenia una perfecta còpia de seguretat llest per a funcionar. Vostè pot resultar una mica columbòfil sobre això, ja que algunes persones fan sovint, en el qual podria tenir un nombre de bases de dades de quatre aquí, nombre de bases de dades de cinc aquí, que estan parlant l'un a l'altre. Però també té aquest tipus de arrangement-- i deliberadament es veu desordenat, perquè és-- on tota la servidors front-end pot parlar amb tots els servidors de back-end. I pel que si aquesta base de dades no ho fa respondre, aquests servidors front-end tenen tenir programació codi en els que diu, si no rep una connexió amb aquesta base de dades, la primària s'inicia immediatament parlant amb el secundari. Però això ara empeny el complexitat al codi. I ara els seus desenvolupadors, el programari desenvolupadors, han de saber d'això. I estàs tipus de lligar el codi que vostè està escrivint a la seva part final real detalls d'implementació, la qual cosa fa que sigui més difícil, especialment en una més gran empresa o un lloc web més gran, en el qual no necessàriament vol que els programadors tinguin saber com la base de dades Els enginyers estan fent la seva feina. És possible que vulgueu mantenir aquestes funcions tipus de funcionalment diferent manera que hi ha d'aquesta capa abstracció entre els dos. Així que, com podem solucionar aquest problema? Bé, quin tipus de resoldre aquest problema d'una vegada abans. Per què no posem una de aquestes coses aquí on es parla al seu torn a la número quatre i 5, tots els servidors web front-end parlar amb aquest intermediari, i el intermediaris en les rutes de tornada a les seves dades? De fet, el que podria ser una bon nom per a aquesta cosa? AUDIÈNCIA: [inaudible] DAVID Malan: OK, gestor de base de dades. Però el que és un terme que podria ser podríem tornar a fer servir amb aquest dispositiu? Estem equilibri. Sí, així que en realitat, estic no sent just aquí. Pel que un equilibrador de càrrega que implicaria estem d'anar i venir aquí, que no ha de ser en realitat el cas. Així que hi ha algunes maneres que podríem fer això. Si aquest és, de fet, 01:00 equilibrador de càrrega, la història és exactament el mateix que abans. Algunes de les peticions d'anar a la 4. Alguns d'ells van a 5. I això és bo. Perquè ara podem gestionar el doble de rendiment. Però aquesta connexió aquí és súper important. Han de romandre constantment sincronitzada i és d'esperar no són geogràficament molt allunyades pel que la sincronització és essencialment instantani. Altrament podríem tenir un problema. Així que això no és dolent. Però, de nou, hem introduir un nou problema. Quin problema és el que acabo recreat? punt únic de fallada. Quina és la solució per això? Així com de l'aficionat a gastar diners Victòria, podem dur a terme aquest tipus i fer això. I jo només vaig a moure aquí espai suficient. I va ser una mica desordenat. Vaig a mantenir les línies de dibuix. Suposem que tots aquestes línies van en tots dos? Una tècnica molt comú aquí seria utilitzar una tècnica anomenada batec del cor on cada un d'aquests dispositius, equilibradors de càrrega d'esquerra i dreta, o com vulguem anomenar, està constantment dient, estic viu, Estic viu, estic viu, estic viu. Un d'ells per defecte actua com el principal. Així que tot el trànsit es d'utilitzar a través d' l'altre a l'esquerra, per exemple, per defecte, de manera arbitrària. Però tan aviat com el tipus de la dreta no escoltar al noi esquerra més, el de la dreta està programat per automàticament, per exemple, fer-se càrrec de l'adreça IP de l'una a l'esquerra, i per tant convertit en el principal, i potser enviar un correu electrònic o un missatge de text als éssers humans que dir, bé, la primària a l'esquerra no està en línia. Que es convertirà en primària per ara. Així es converteix en vicepresident president, per dir-ho. I algú ha d'anar a salvar el president, si ho desitja. Perquè ara tenim un temporal punt únic de fallada. Així com complicat o estressant com això podria semblar que començar a ser, aquesta és la forma de resoldre aquests problemes. Ho fas llençar els diners en ella. Vostè llança maquinari en ella. Però, lamentablement, afegir la complexitat de la mateixa. Però el resultat, en última instància, és que vostè té una molt més, en teoria, arquitectura robusta. Encara no és perfecte. Perquè fins i tot quan ens podríem tener-- no tenir un únic punt de fallada. Ara tenim dos punts de fallada. Però si dues coses van malament, la qual absolutament podria, estem encara va a estar fora de línia. I així, molt comú en el indústria és descriure el seu temps en termes de punta en blanc. I en certa manera l'objectiu és aspirar a 99,999% de les vegades que el seu lloc està en línia. O millor encara, afegir una uns més que a punta en blanc. Desafortunadament, aquests nous són molt cars. I farem realitat això. Així que si obro la meva calculadora gran de nou, 365 dies en un any, 24 hores en un dia, 60 minuts en una hora, i 60 segons en un minut, que és la quantitat de segons que hi ha en un any si ho fes això correctament. Així que si vegades aquest per 99.999, això és la quantitat de temps que volem aspirar. Per la qual cosa significa que hem de ser fins aquesta quantitat de segons durant l'any. Així que si ara li resta del valor original, o més aviat aquest nou valor de la primer-- 316 segons, que per descomptat és de cinc minuts. Així que si el seu lloc web o la seva empresa està afirmant que "cinc nous", amb el qual vau ser fins 99,99% de les vegades, que significa una millor han estat prou intel·ligent i ràpid suficient i prou ores amb recursos que els seus servidors estan fora de línia única cinc minuts fora de l'any. És un costós i cosa difícil d'aspirar. Així que és una solució de compromís, també. 99,999% de les vegades és bastant rematadament difícil i costós. Cinc minuts-- amb prou feines es pot aconseguir al servidor per reemplaçar físicament cosa que ha anat malament. I és per això que vam començar cablejat coses junts més complicats a priori perquè els equips pot espècie de fixar ells mateixos. Sí. AUDIÈNCIA: [inaudible] DAVID Malan: El problema podria estar en qualsevol nombre de llocs. I en fact-- AUDIÈNCIA: [inaudible] DAVID Malan: Absolutament, absolutament. I a mesura que la imatge és cada vegada més complicada, que podria ser els servidors web. Podria ser l'alimentació de la construcció. Podria ser una cosa física, com van aconseguir els cables esfilagarsats o expulsats. Podria ser la base de dades no està responent. Podria ser que actualitza el seu operatiu sistema i alguna cosa està penjant. Així que hi ha moltes altres parts mòbils. I així un munt de l'enginyeria que ha d'anar darrere d'aquest és realment només compensacions, com la forma Quant de temps, quants diners és en realitat val la pena, i quines són les amenaces vostè és realment preocupa? Per exemple, en el cursos que imparteixo a Harvard, utilitzem una gran quantitat de computació en el núvol, la qual cosa començarem a fer una ullada a ara, de fet, en la que fem servir Amazon Web Services. El fet que aquesta és la Comencem amb un. Però hi ha cada vegada més en aquests dies de Google i Microsoft i altres. I nosaltres vam triar conscientment posar tot de màquines virtuals nostres cursos ', com se'ls anomena, en el pinso és occidental del centre de dades Virgínia. La majoria dels nostres estudiants passarà a ser dels EUA, encara que sens dubte hi ha alguns internacionalment. Però la realitat és que és només més simple i és més barat per a nosaltres posar tots els ous en la cistella de Virgínia, tot i que sé si alguna cosa que va malament a Virgínia, de la mateixa manera que de tant en tant com happened-- si hi ha un huracà o una mica de clima esdeveniment similar que, si hi ha alguna qüestió xarxa elèctrica o la com- tot de les dades dels nostres cursos poden desconnectar ' per algun nombre de minuts o hores o fins i tot més temps. Però la quantitat de complexitat que es necessitaria, i la quantitat de diners que faria es requereix, per funcionar tot en paral·lel a Europa oa Califòrnia simplement no té molt sentit. Així que és una operació racional fora, sinó una dolorosa quan en realitat estàs que té que el temps d'inactivitat. Bé, anem a la transició en aquest moment per algunes de les solucions basades en el núvol a alguns d'aquests problemes. Tot el que hem discutir fins ara és una mena de problemes que tenen estat amb nosaltres des de fa algun temps, si vostè té el seu propi servidors de l'empresa, si vas a un co-ubicació col·locar com un centre de dades i compartir espai amb una altra persona, o avui en dia en el núvol. I el que és bo de el núvol és que tots d'aquestes coses que estic dibuix com a objectes físics ara pot ser considerat com tipus d'objectes virtuals en el núvol que són simulat amb programari. En altres paraules, els ordinadors d'avui en dia, servidors d'avui dia, com la imatge de Dell Em vaig presentar anteriorment, són tan ràpids, tenen tanta memòria RAM, de manera que la quantitat de CPU, tant en disc espai, que la gent ha escrit programari de partició pràcticament un servidor per amunt en la il·lusió que sent dos servidors, o 200 servidors, per la qual que cada un de nosaltres els clients té la il·lusió de tenir no només un compte en alguna web amfitrió, però la nostra pròpia màquina que estem el lloguer d'una altra persona. Però és una màquina virtual en la mesura en què en un servidor Dell, de nou podria ser dividida fins a dues o 200 o més màquines virtuals, tot la qual cosa dóna a algú administrativa l'accés, però d'una manera que cap de nosaltres sap o pot recórrer a altres virtuals màquines en el mateix maquinari. Així que per pintar un quadre en diapositives d'avui en dia, Aquest és el tret d'un lloc web acoblable trucada. Així que això és una mica més detall el que realment necessitem. Però si veu això com seva infrastructure-- de manera que només el maquinari del seu compte, seus servidors, els bastidors, les dades centre, i tots queden ho faria normalment executar un sistema operatiu amfitrió. Així que alguna cosa com- podria ser Windows. No seria Mac OS. A causa de que no és realment l'empresa en aquests dies. Pel que seria Linux o Solaris o Unix o BSD o FreeBSD o qualsevol nombre d'altres sistemes operatius que són gratuïts o comercial. I a continuació, s'executa una programa, programa especial, anomenat 1 hipervisor, o un monitor de màquina virtual, VMM. I aquests són els productes, si estàs familiar, com VMware o VirtualBox o Virtual PC o altres. I el que fan aquests programes és exactament característica que he descrit anteriorment. Es crea la il·lusió que una màquina física pot haver múltiples màquines virtuals. I pel que aquestes caixes de colors a sobre de la tapa és pintar un quadre del següent. Aquest hipervisor, aquesta peça de programari, en diuen VMware, que s'executa en algun altre sistema operatiu, en diuen Linux, està creant la il·lusió que aquest equip físic és realment un, dos, tres ordinadors virtuals. Així que ara que he comprat, com l'amo de aquest maquinari, un equip físic. I ara estic llogant a tres clients. I aquests tres clients tots pensen tenen una màquina virtual dedicada. I no és l'esquer i canviar. És més que la revelació utilitzeu una màquina virtual. Però tecnològicament, tots tenir un control administratiu complet sobre cada un dels convidats sistemes operatius, el que podria ser qualsevol nombre de sistemes operatius. Puc instal·lar el que vulgui. Puc actualitzar-lo com jo vull. I ni tan sols ha de saber o preocupar-se per l'altre operatiu Els sistemes d'aquest equip, les altres màquines virtuals, llevat que l'amo de tot això gris coses és ser una mica cobdiciós i es Overselling seus recursos. Així que si vostè està prenent una màquina física i la seva venda a no 200 400 però clients, en algun moment anem a ensopegar en els mateixos problemes de rendiment com abans. Ja que només té un nombre finit quantitat de disc i la memòria RAM i així successivament. I una màquina virtual és simplement un programa que és pretenent ser un complet equip fet i dret. Així s'obté el que es paga. Pel que trobarà en línia que es podria pagar una empresa de confiança potser $ 100 al mes per a la seva pròpia màquina virtual, o el seu propi servidor privat virtual, que és un altre terme per a això. O és possible trobar alguns volen per nit en què paga 5,99 $ al mes per a la seva pròpia màquina virtual. Però les probabilitats són que no té gairebé tant el rendiment disponible per a vostè, perquè han estat Overselling es així, que ho faria amb la major categoria de servei o en el millor proveïdor. Llavors, què significa això realment per a nosaltres? Així que permetin-me anar a aquest. Vaig a anar a aws.amazon.com. El fet que tenen un bon menú d'opcions. No obstant això, aquestes mateixes lliçons s'apliquen a una Gran quantitat dels altres proveïdors del núvol. Malauradament, és sovint més comercialització parlar de qualsevol cosa. I això no deixa de canviar. Així que anar a un lloc web com aquest. I això realment no ho fa dirà molt de res. I fins i tot, quan miro a això, no faig realment saber el que qualsevol d'aquestes coses necessàriament fer fins submergir-me. Però anem a començar a l'esquerra, a Calcular. I vaig a fer clic en aquest. I ara Amazon té francament una nombre aclaparador dels serveis aquests dies. No obstant això, Amazon EC2 és potser el més simple. Amazon EC2 crearà per a nosaltres exactament la imatge que vam veure fa un moment. És la forma en que fan molt els seus diners en el núvol. Aparentment Netflix i altres estan en el núvol amb ells. Tot això és típicament esponjós comercialització parlar. Així que el que vull fer és anar a Pricing-- o millor dit, anirem a les instàncies primer només per pintar un quadre d'això. Així que això variarà segons el proveïdor. I no és necessari per obtenir massa profund en les males herbes aquí de com funciona tot això. Però la forma en Amazon, per exemple, es lloga una màquina virtual o un servidor en el núvol és el que tenen aquest tipus de noms divertits, com t2.nano, que significa petit, o t2.large, el que significa gran. Cada un d'ells li va bé un o dos CPU virtuals. Per què és una CPU virtual? Així, la màquina física podria tenen 64 o més CPU reals. Però, de nou, a través de programari, que creen la il·lusió que que una màquina pot ser repartit a diversos usuaris. Pel que podem pensar en això com que té una CPU Intel o dos. crèdits de CPU per hour-- ho faria ha de llegir la lletra petita pel que fa al que això significa realment. Això significa la quantitat de la màquina es pot utilitzar per hora vis-a-vis altres clients en aquest maquinari. Aquí està la quantitat de RAM o memòria que get-- ja sigui la meitat d'un gigabyte, o 500 megabytes, o 1 gigabyte, o 2. I a continuació, l'emmagatzematge només es refereix a quin tipus de discos que li donen. Hi ha diferents d'emmagatzematge tecnologies que ofereixen. Però més interessant que això a continuació, podria ser la fixació de preus. Així que si vostè és el CTO o un enginyer que no ho fa que desitgi executar un servidor en la seva oficina, per qualsevol raó, i que és massa complicat o car per comprar servidors i co-localitzar ells i pagar el lloguer d'algun espai en les gàbies física somewhere-- el que desitja és seure a l'ordinador portàtil a altes hores de la nit, escrigui la seva informació de targeta de crèdit, i llogar els servidors de la cloud-- així, podem fer-ho aquí. Vaig a baixar A-- Linux és un popular sistema operatiu. I tindrem una idea de les coses. Whoops-- massa gran. Així que donem una ullada al seu més mínima màquina virtual, que sembla tenir, per als nostres propòsits, una CPU i 500 megabytes de RAM. Això és bastant petita. Però, francament, els servidors web no ho fan cal fer tot el que molt. Segur que té millors característiques en el seu ordinador portàtil. Però vostè no necessita els Fitxa d'aquests dies per les coses. Pagaràs 0,0065 $ per hora. Així que anem a veure. Si hi ha 24 hores en un dia, i estem pagant aquesta quantitat per hora, que li costarà $ 0,15 a llogar aquesta servidor en particular en el núvol. I això és només per un dia. Si fem això 365-- $ 57 a llogar aquest servidor en particular. Pel que sona super barat. Això també és de molt baix rendiment. Així que, per als cursos que ensenyem aquí, tendeixen utilitzar Crec t2.smalls o t2.mediums. I podríem tenir uns pocs centenars usuaris, uns pocs milers d'usuaris, total. És bastant modesta. Així que anem a veure el que això costaria. Així que si faig això temps de costos 24 365 hores de temps, d'aquest 225 $. I per als cursos Ensenyo, generalment, executar dues de tot, per la redundància i també per al rendiment. Així que podríem passar, per tant, $ 500 pels servidors que pot ser que necessiti per any. Ara, si necessita més performance-- anem a fer una ullada a la memòria. Hem parlat de la memòria una mica. I si necessita més memory-- i 64 gigabytes és el nombre Seguí mentioning-- això és gairebé $ 1 per hora. I que pràcticament pot veure ràpidament on aquest goes-- així 24 hores Temps 365. Així que ara és $ 8.000 pel any per a un servidor bastant decent. Per tant, en algun moment, no hi ha aquest punt d'inflexió on ara ens podia passar $ 6000 Probablement i comprar una màquina com aquesta i amortitzar el seu cost sobre potser dos, tres anys, la vida de la màquina. Però el que podria empènyer a afavorir ni perjudicar de lloguer una màquina en el núvol com aquesta? De nou, això és comparable, probablement, a un d'aquests servidors Dell imaginem que vam veure fa una mica. AUDIÈNCIA: [inaudible] DAVID Malan: Sí, això és un enorme revés. A causa de que no estem comprant el màquina, que no hem de desempacar ell. No tenim per aixecar-la. Nosaltres no hem de endollar a la nostra prestatgeria. No hem de endollar. No hem de pagar la factura elèctrica. Nosaltres no hem de donar volta l'aire condicionat encès. Quan mor un disc dur, no tenim conduir en en el medi de la nit per solucionar-ho. Nosaltres no hem de configurar la supervisió. No tenim A-- la llista segueix i en el de totes les coses físiques que no cal fer a causa de "el núvol". I perquè quedi clar, la computació en núvol És aquest terme molt usat en excés. En realitat, només significa pagar a algú més per executar servidors per a vostè, o el lloguer d'espai en servidors d'una altra persona. Pel que el terme "cloud computing" és nova. La idea té dècades d'antiguitat. Així que és bastant convincent. I el que més es pot aconseguir? Bé, també et donen la possibilitat de fer tot en un ordinador portàtil a casa. En altres paraules, totes les Estava imatges drawing-- i no va ser fa tant de temps que ni tan sols Estava pujant per una pista de servidor endollar els cables de per cadascuna de les línies que es veuen, i la millora de l'operació sistemes i unitats que canvien els seus voltants. Hi ha una gran quantitat de físic de tot això. Però el que és bell en virtuals màquines, com el nom suggereix classe de, ara hi ha basat en la web mitjançant el qual les interfícies si voleu que l'equivalent d'una línia des d'aquest servidor a un altre, només ha d'escriure, tipus, tipus, fer clic i arrossegar, feu clic a Enviar, i llest, vostè ha de cablejada de manera virtual. A causa de que es fa amb el programari. I la raó per la qual es fa en programari és de nou perquè tenim tanta memòria RAM i per la quantitat de CPU disponible per a nosaltres en aquests dies, encara que tots això porta temps, és més lent per executar coses en programari de maquinari, de la mateixa manera que és més lent per utilitzar un mecànic dispositiu com un disc dur que la RAM, alguna cosa purament electrònic. Tenim tants recursos disponible per a nosaltres. Els éssers humans som una espècie de invariantly lent. I pel que ara les màquines poden fer molt més per unitat de temps. Tenim aquestes habilitats fer les coses de forma virtual. I vaig a dir per als cursos Ensenyo, per exemple, aquí, Tenim al voltant d'una dotzena o potser de manera total de màquines virtuals de la mateixa manera que l'execució en un moment donat el temps fent coses extrem davanter, fent de nou material final. Tenim tot el nostre emmagatzematge. Pel que qualsevol vídeos, incloent coses com aquest que estem gravant, vam acabar posant en el núvol. Amazon té els serveis de trucades d'Amazon S3, el seu servei d'emmagatzematge senzilla, que és igual que l'espai en disc en el núvol. Ells tenen alguna cosa Anomenat CloudFront, que és un servei de CDN, contingut servei de lliurament de la xarxa, la qual cosa vol dir que ocupen tots els seus arxius i per a vostè automàgicament replicar al voltant del món. Així que no ho fan de forma preventiva. Però la primera vegada que algú a l'Índia sol·licita el seu arxiu, que van potencialment una caché local. La primera vegada a la Xina, l' primera vegada al Brasil que passa, van a començar l'emmagatzematge en memòria cau de forma local. I vostè no ha de fer res d'això. I el que és tan increïblement obligant a aquests dies per moure les coses en el núvol. A causa que té aquesta capacitat, literalment, per no tenir els éssers humans fent gairebé tant treball. I que, literalment, no cal ja que molts els éssers humans fent aquests treballs anymore-- "Operacions", o les funcions operatives, mai més. El que realment necessita desenvolupadors i un menor nombre d'enginyers que acaba pot fer les coses de forma virtual. De fet, només per donar que un sentit d'això, vull anar a la fixació de preus per un altre producte aquí. Anem a veure una mena de CDN S3. Així que això és essencialment una disc dur virtual en el núvol. I si ens desplacem cap avall per pricing-- pel que és $ 0.007 per gigabyte. I és-- com fem això? Crec que és per mes. Així que si això és per mes-- o per dia? Donen, està present per dia? Això és per mes, a D'acord. Així que si això és per mes-- ho sento, és el 0,03 $ per mes. Hi ha 12 mesos a l'any. Així que la quantitat de dades podria s'emmagatzemen en el núvol? Un gigabyte no és enorme, però jo no sé, igual que 1 terabyte, així com 1.000 d'ells. Això no és tot el que molt. Es tracta de $ 368 a emmagatzemar un terabyte de les dades en el núvol d'Amazon. Quines són algunes de les les compensacions, doncs? No tot pot ser bo. Res del que hem parlat avui és espècie de guàrdia o sense un cost. Llavors, què hi ha de dolent en moviment tot en el núvol? AUDIÈNCIA: Seguretat. DAVID Malan: OK, què vol dir? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, és clar. I el que realment vol alguns enginyers atzar a Amazon que vostè mai trobarà a tenir l'accés físic als equips, i si realment estimat, accés virtual? I tot i que en La teoria software-- així, xifrat pot absolutament protegir d'aquesta. Així que si el que busques emmagatzemar en els seus servidors es encrypted-- menys d'una preocupació. Però tan aviat com un ésser humà té física accés a una màquina, a una banda de xifrat, totes les apostes són una espècie de fora. Vostè pot saber d'abans que PCs especialment, fins i tot si tingués aquestes coses anomenades "contrasenyes de BIOS," eren quan el seu escriptori arrencat, que s'hauria demanarà una contrasenya que no té res a veure amb Finestres, normalment pot només cal obrir el xassís de la màquina, trobar petits perns petits, i l'ús d'alguna cosa que es diu un pont i només ha de connectar aquests dos cables per al voltant d'un segon, completant d'aquesta manera un circuit. I això seria eliminar la contrasenya. Així que quan es té accés físic a una dispositiu, pot fer coses per l'estil. Es pot treure el disc dur. Es pot accedir-hi d'aquesta manera. I així, aquesta és la raó, en el cas de Dropbox, per exemple, que és una mica preocupant que no només es tenir les dades, tot i que és encriptat, també tenen la clau. Altres preocupacions? AUDIÈNCIA: [inaudible] DAVID Malan: Sí, és molt cert-- els Googles, les pomes, els Microsofts del món. I de fet, quant de temps tenen que tenia el seu iPhone per? Sí, més o menys. AUDIÈNCIA: [inaudible] DAVID Malan: Ho sento? Vostè està entre aquells que té un iPhone, oi? AUDIÈNCIA: Sí. DAVID Malan: Quant de temps ¿Ha tingut el seu iPhone? AUDIÈNCIA: [inaudible] DAVID Malan: OK, llavors Apple sap, literalment, on ha estat cada hora de el dia durant els últims cinc anys. AUDIÈNCIA: [inaudible] DAVID Malan: Quin és una característica meravellosa. AUDIÈNCIA: [inaudible] DAVID Malan: Sí, però comerç fora segur. AUDIÈNCIA: [inaudible] DAVID Malan: Sí, és molt fàcil. AUDIÈNCIA: [inaudible] DAVID Malan: Altres desavantatges? AUDIÈNCIA: [inaudible] DAVID Malan: Absolutely-- tecnològicament, econòmicament, és bastant convincent per espècie de guanyar aquestes economies d'escala i traslladar tot a l'anomenat núvol. No obstant això, és probable que vulgui anar amb alguns dels majors peixos, les Amazones, els Googles, la Microsofts-- Rackspace és bastant big-- i alguns altres, i no necessàriament volar a la gent de la nit per als que és molt fàcil de fer aquest tipus de tècnica d'avui dia. I això és qui pot pagar 5,99 $ per mes per. Però que sens dubte va obté el que es paga. Quan vostè diu [inaudible], que és quan coses com aquestes cinc nous apareixen, pel que fins i tot si tecnològicament en realitat no podem garantir 99.999, només haurem de construir en una espècie de la pena amb el contracte de manera que si això succeeix, almenys hi ha algun cost per a nosaltres, el venedor. I això és el que ho faria normalment pot aconseguir que es recorden. AUDIÈNCIA: [inaudible] DAVID Malan: I el una mena de benedicció és que fins i tot quan anem cap avall, per instància, o fins i tot certes empreses, la realitat és Amazon, per exemple, té tants clients, clients rematadament ben coneguts, que operen en determinats centres de dades que quan alguna cosa va malament en realitat, com a causes de força i temps i tal, si hi ha qualsevol tipus de revestiment de plata, és que estàs en molt bona companyia. El seu lloc web pot estar fora de línia. Però també ho és que la meitat de internet popular. I el que és sens dubte una mica més acceptable per als seus clients si és més d'una internet El que una cosa acme.com. Però això és una mica trampós. Així que en termes d'altres coses a veure, només perquè no descartem altres, si vas a Microsoft Azure, que tenir les dues coses Linux i de Windows això és comparable a la d'Amazon. Si vostè va a Google Compute de cerca, tenen alguna cosa similar també. I per arrodonir aquestes ofertes de núvol, Vaig a fer esment a una altra cosa. Es tracta d'un popular lloc web això és representativa d'una classe de tecnologies. Els que acabem de parlar aproximadament, Amazon, seria IaaS, Infraestructura com a Servei, on es tipus de maquinari físic com un servei. Hi ha SAAS. En realitat, deixin-me anoto aquestes sota. infraestructura IAAS-- Com un servei, SAAS, i PAAS, que són acrònims molt confusos que descriuen tres diferents tipus de coses. I els propis acrònims realment no importa. Aquesta és tota la matèria núvol que hem estat parlant, les coses de nivell inferior, la virtualització de maquinari i d'emmagatzematge en l'anomenada en el núvol, ja sigui Amazon, Microsoft, Google, o un altre. Programari com clients-- tots nosaltres aquest tipus d'ús. Si utilitzes Google Apps de Gmail o de calendari, qualsevol d'aquests web-basat Fa aplicacions que 10 anys que tindria icones doble clic en la nostre escriptori, el programari com a servei ara és realment d'aplicacions web. I la plataforma com una servei depèn del tipus. I un exemple et donaré aquí en el context del núvol computing-- hi ha una empresa que és bastant populars en aquests dies, Heroku. I són un servei, una plataforma, si es vol, que s'executa en la part superior de la infraestructura d'Amazon. I que només fan que sigui encara més fàcil per als desenvolupadors i enginyers per obtenir aplicacions basades en web en línia. És un dolor, al principi, per utilitzar Amazon Web Services i altres coses. A causa que en realitat tenen per conèixer i comprendre sobre bases de dades i servidors web i balancejadors de càrrega i totes les coses Que acabo de parlar. A causa de que tots Amazon ha fet no és oculta els reptes de disseny. Acaben d'ells virtualitzats i moure'ls en un navegador, en el programari en lloc de maquinari. Però empreses com Heroku i una altra proveïdors de PAAS, plataforma com a servei, que utilitzen aquests fonamentals barebone que acabem de parlar, i construeixen més fàcil utilitzar el programari a la part superior de la mateixa de manera que si vol aconseguir un web basat sol·licitud en línia en aquests dies, que sens dubte ha de saber programar. El que necessita saber Java o Python o PHP o Ruby o un munt d'altres llengües. Però també necessita un lloc per posar-ho. I parlem anteriorment sobre aconseguir una empresa d'allotjament web. En certa manera és com els mitjans dels 2000 enfocament per aconseguir alguna cosa en línia. Avui dia és possible que en lloc de pagar a algú com Heroku uns pocs dòlars al mes. I, essencialment, una vegada que hagi fet alguna configuració inicial, per actualitzar el seu lloc web, només ha d'escriure un comandament en una finestra. I qualsevol que sigui el codi que has escrit aquí a l'ordinador portàtil immediatament es distribueix a qualsevol nombre dels servidors en el núvol. Heroku i s'encarrega de tota la complexitat. Calculen tota la base de dades coses, tot l'equilibri de càrrega, tots els mals de cap que hem acaba d'escriure a la pissarra, i amagar tot això per a vostè. I a canvi, només pagar una mica més. Pel que té com aquestes infraestructures un servei, plataformes com un servei, i després el programari com a servei. És, de nou, aquesta abstracció de múltiples capes. Per a qualsevol dubte sobre el núvol o la construcció de la pròpia infraestructura? Molt bé, això era molt. Per què no anem endavant i prendre el nostre descans de 15 minuts aquí. Tornarem amb alguns nous conceptes i una mica d'oportunitat pràctica abans de la nit ha acabat.