Ohjelmointi

6 piilotettua pullonkaulaa pilvitietojen siirrossa

Seth Noble on Data Expeditionin perustaja ja presidentti.

Teratavun tai jopa petatavun tiedon siirtäminen pilveen on pelottava tehtävä. Mutta on tärkeää katsoa tavujen lukumäärää pidemmälle. Luultavasti tiedät, että sovelluksesi käyttäytyvät eri tavalla, kun niitä käytetään pilvessä, että kustannusrakenteet ovat erilaiset (toivottavasti paremmat) ja että kaikkien näiden tietojen siirtäminen vie aikaa.

Koska yritykseni, Data Expedition, harjoittaa suuritehoista tiedonsiirtoa, asiakkaat tulevat luoksemme odottaessaan verkon nopeuden olevan ongelma. Mutta auttaessamme yrityksiä voittamaan ongelman, olemme nähneet monia muita tekijöitä, jotka uhkaavat pilata siirtymiä raiteilta, jos ne jätetään huomiotta.

Tietojesi kerääminen, järjestäminen, muotoilu ja validointi voivat aiheuttaa paljon suurempia haasteita kuin niiden siirtäminen. Tässä on joitain yleisiä tekijöitä, jotka on otettava huomioon pilvipalvelun suunnitteluvaiheessa, jotta voit myöhemmin välttää aikaa vieviä ja kalliita ongelmia.

Pilvipalvelujen pullonkaula # 1: tietojen tallennus

Yleisin virhe, jonka näemme pilvipalvelujen siirtämisessä, on tietojen työntäminen pilvitallennustilaan miettimättä, miten kyseisiä tietoja käytetään. Tyypillinen ajatusprosessi on: "Haluan laittaa asiakirjat ja tietokannat pilveen, ja objektien varastointi on halpaa, joten laitan asiakirja- ja tietokantatiedostoni sinne." Mutta tiedostot, objektit ja tietokannat käyttäytyvät hyvin eri tavalla. Tavujen asettaminen väärään voi pilata pilvisuunnitelmasi.

Tiedostot on järjestetty polkujen hierarkian, hakemistopuun mukaan. Jokaiseen tiedostoon pääsee nopeasti, sillä viive on pieni (aika ensimmäiseen tavuun) ja nopea (bittiä sekunnissa, kun data alkaa virrata). Yksittäisiä tiedostoja voidaan helposti siirtää, nimetä uudelleen ja vaihtaa tavutasolle. Sinulla voi olla monia pieniä tiedostoja, pieni määrä suuria tiedostoja tai mitä tahansa kokojen ja tietotyyppien yhdistelmää. Perinteiset sovellukset voivat käyttää pilvipalvelun tiedostoja samalla tavalla kuin tiloissa, ilman erityistä pilvitietoisuutta.

Kaikki nämä edut tekevät tiedostopohjaisesta tallennuksesta kalleimman vaihtoehdon, mutta tiedostojen tallentamiselle pilvessä on muutamia muita haittoja. Korkean suorituskyvyn saavuttamiseksi useimpiin pilvipohjaisiin tiedostojärjestelmiin (kuten Amazon EBS) pääsee vain yhdellä pilvipohjaisella virtuaalikoneella kerrallaan, mikä tarkoittaa, että kaikkien kyseistä tietoa tarvitsevien sovellusten on toimittava yhdellä pilvipalvelimella. Useiden virtuaalikoneiden (kuten Azure Files) palveleminen edellyttää, että tallennustila liitetään NAS-protokollaan (verkkoon liitetty varastointi), kuten SMB, mikä voi rajoittaa suorituskykyä vakavasti. Tiedostojärjestelmät ovat nopeita, joustavia ja vanhoja yhteensopivia, mutta ne ovat kalliita, hyödyllisiä vain pilvessä toimiville sovelluksille, eivätkä ne skaalaa hyvin.

Objektit eivät ole tiedostoja. Muista se, koska se on helppo unohtaa. Objektit elävät tasaisessa nimitilassa, kuten yksi jättiläinen hakemisto. Latenssi on korkea, joskus satoja tai tuhansia millisekunteja, ja läpäisykyky on pieni, ylittäen usein noin 150 megabittiä sekunnissa, ellei käytetä älykkäitä temppuja. Paljon esineiden käyttämisestä tulee fiksuihin temppuihin, kuten moniosainen lataus, tavualueen käyttö ja avaimen nimen optimointi. Objektit voidaan lukea monilla pilvipohjaisilla ja verkkopohjaisilla sovelluksilla kerralla, sekä pilvestä että sen ulkopuolelta, mutta perinteiset sovellukset edellyttävät suorituskyvyn lamauttavia kiertotapoja. Useimmat käyttöliittymät objektien tallennustilan saamiseksi saavat objektit näyttämään tiedostoilta: avainten nimet suodatetaan etuliitteen mukaan näyttämään kansioilta, mukautetut metatiedot liitetään objekteihin, jotka näkyvät tiedostojen metatiedoina, ja jotkut järjestelmät, kuten FUSE-välimuistikohteet VM-tiedostojärjestelmässä, sallivat pääsyn perinteisten sovellusten avulla. Mutta tällaiset kiertotavat ovat hauraita ja tehokkaita. Pilvivarasto on halpaa, skaalautuvaa ja pilvipalvelua, mutta se on myös hidasta ja vaikeasti käytettävissä.

Tietokannoilla on oma monimutkainen rakenne, ja niihin pääsee hakukielillä, kuten SQL. Perinteisiä tietokantoja voidaan tukea tiedostotallennuksella, mutta ne edellyttävät suoraa tietokantaprosessia kyselyjen tarjoamiseksi. Tämä voidaan nostaa pilveen kopioimalla tietokantatiedostot ja sovellukset virtuaalikoneeseen tai siirtämällä tiedot pilvi-isännöityyn tietokantapalveluun. Mutta tietokantatiedoston kopioiminen objektitallennukseen on hyödyllistä vain offline-varmuuskopiona. Tietokannat skaalautuvat hyvin osana pilvipalvelua, mutta on erittäin tärkeää varmistaa, että tietokannasta riippuvat sovellukset ja prosessit ovat täysin yhteensopivia ja pilvikohtaisia. Tietokannan tallennus on pitkälle erikoistunutta ja sovelluskohtaista.

Kohdetallennuksen näennäisten kustannussäästöjen tasapainottaminen tiedostojen ja tietokantojen toimivuuteen edellyttää huolellista tarkkaa harkintaa siitä, mitä toimintoja tarvitaan. Esimerkiksi, jos haluat tallentaa ja jakaa tuhansia pieniä tiedostoja, arkistoi ne ZIP-tiedostoon ja tallenna se yhtenä objektina sen sijaan, että yrität tallentaa jokaista yksittäistä tiedostoa erillisenä objektina. Virheelliset tallennusvaihtoehdot voivat johtaa monimutkaisiin riippuvuuksiin, joita on vaikea ja kallista muuttaa myöhemmin.

Pilvipalvelujen pullonkaula # 2: Tietojen valmistelu

Tietojen siirtäminen pilveen ei ole niin yksinkertaista kuin tavujen kopioiminen määritettyyn tallennustyyppiin. Paljon valmistelua on tapahduttava ennen kuin mitään kopioidaan, ja se aika vaatii huolellista budjetointia. Käsitteitä osoittavat projektit jättävät usein huomiotta tämän vaiheen, mikä voi myöhemmin johtaa kalliisiin ylityksiin.

Tarpeettomien tietojen suodattaminen voi säästää paljon aikaa ja tallennuskustannuksia. Esimerkiksi tietojoukko voi sisältää varmuuskopioita, aiempia versioita tai naarmutiedostoja, joiden ei tarvitse olla osa pilven työnkulkua. Ehkä tärkein osa suodatuksessa on priorisoida, mitkä tiedot on siirrettävä ensin. Aktiivisesti käytetty data ei siedä synkronoinnin puuttumista viikkoihin, kuukausiin tai vuosiin, jotka kuluvat koko siirtoprosessin loppuunsaattamiseen. Tärkeintä tässä on luoda automaattinen keino valita lähetettävät tiedot ja milloin, ja pitää sitten huolellinen kirjaa kaikesta, mitä on ja mitä ei ole tehty.

Erilaiset pilvityönkulut saattavat edellyttää tietojen olevan eri muodossa tai organisaatiossa kuin paikalliset sovellukset. Esimerkiksi laillinen työnkulku saattaa edellyttää tuhansien pienten Word- tai PDF-asiakirjojen kääntämistä ja pakkaamista ZIP-tiedostoihin, median työnkulku voi sisältää koodauksen ja metatietojen pakkaamisen, ja bioinformatiikan työnkulku saattaa edellyttää genomitietojen valitsemista ja lavastamista. Tällainen alustaminen voi olla erittäin manuaalinen ja aikaa vievä prosessi. Se voi vaatia paljon kokeiluja, paljon väliaikaista varastointia ja paljon poikkeusten käsittelyä. Joskus on houkuttelevaa lykätä pilvipalvelun alustamista, mutta muista, että tämä ei ratkaise ongelmaa, vaan vain siirtää sen ympäristöön, jossa jokaisella käyttämälläsi resurssilla on hinta.

Osa tallennus- ja muotoilukysymyksistä voi sisältää pakkaamista ja arkistointia koskevia päätöksiä. Esimerkiksi on järkevää postittaa miljoonia pieniä tekstitiedostoja ennen niiden lähettämistä pilveen, mutta ei kourallista monigigatavuisia mediatiedostoja. Tietojen arkistointi ja pakkaaminen helpottaa tietojen siirtämistä ja tallentamista, mutta ota huomioon aika ja tallennustila, joka kuluu näiden arkistojen pakkaamiseen ja purkamiseen kummassakin päässä.

Pilvipalvelujen pullonkaula # 3: Tietojen vahvistus

Eheyden tarkistus on tärkein yksittäinen askel ja myös helpoin väärin. Usein oletetaan, että tiedonsiirron aikana tapahtuu korruptiota, olipa kyse fyysisestä mediasta tai verkon siirrosta, ja se voidaan saada kiinni suorittamalla tarkistussummat ennen ja jälkeen. Tarkistussummat ovat tärkeä osa prosessia, mutta itse asiassa se on tietojen valmistelu ja tuonti sinne, missä todennäköisimmin menetät tai vahingoitat.

Kun data vaihtaa muotoja ja sovelluksia, merkitys ja toiminnallisuus voivat kadota, vaikka tavut olisivat samat. Yksinkertainen yhteensopimattomuus ohjelmistoversioiden välillä voi tehdä petatavuista "oikeista" tiedoista hyödyttömiä. Skaalautuvan prosessin keksiminen sen varmistamiseksi, että tietosi ovat sekä oikeita että käyttökelpoisia, voi olla pelottava tehtävä. Pahimmassa tapauksessa se voi siirtyä työvoimavaltaiseen ja epätäsmälliseen manuaaliseen prosessiin, joka "näyttää hyvältä minulle". Mutta se onkin parempi kuin ei lainkaan validointia. Tärkeintä on varmistaa, että pystyt tunnistamaan ongelmat ennen vanhojen järjestelmien käytöstä poistamista!

Pilvien migraation pullonkaula # 4: Siirrä marsh

Kun nostat yhden järjestelmän pilveen, on suhteellisen helppoa vain kopioida valmistetut tiedot fyysiseen tietovälineeseen tai siirtää ne Internetin yli. Mutta tätä prosessia voi olla vaikea skaalata etenkin fyysisen median osalta. Se, mikä näyttää "yksinkertaiselta" todistuskäsitteessä, voi olla "painajainen", kun monia ja erilaisia ​​järjestelmiä tulee esiin.

Medialaite, kuten AWS-lumipallo, on kytkettävä jokaiseen koneeseen. Tämä voi tarkoittaa laitteen fyysistä kävelemistä yhden tai useamman palvelinkeskuksen ympäri, liitinten jongleeraamista, ohjainten päivittämistä ja ohjelmistojen asentamista. Yhteyden muodostaminen lähiverkon kautta säästää fyysistä liikettä, mutta ohjelmiston asennus voi silti olla haastavaa ja kopiointinopeus saattaa pudota selvästi alle sen, mikä voitaisiin saavuttaa suoralla Internet-latauksella. Tietojen siirtäminen suoraan jokaisesta koneesta Internetin kautta säästää monia vaiheita, varsinkin jos tiedot ovat valmiita pilvipalveluun.

Jos tietojen valmisteluun liittyy kopiointi, vienti, alustaminen tai arkistointi, paikallisesta tallennustilasta voi tulla pullonkaula. Saattaa olla tarpeen perustaa oma tallennustila valmisteltujen tietojen vaiheistamiseksi. Tämän etuna on, että monet järjestelmät voivat suorittaa valmistelun rinnakkain, ja se vähentää siirrettävän median ja tiedonsiirto-ohjelmiston yhteyspisteet vain yhdeksi järjestelmäksi.

Pilvipalvelujen pullonkaula # 5: Tiedonsiirto

Verrattaessa verkonsiirtoa median lähetykseen on helppo keskittyä vain toimitusaikaan. Esimerkiksi 80 päivän teratavun AWS-lumipallolaite saatetaan lähettää seuraavan päivän kuriirilla, jolloin näennäinen tiedonsiirtonopeus on yli kahdeksan gigabittiä sekunnissa. Mutta tämä jättää huomiotta laitteen hankkimiseen, konfigurointiin ja lataamiseen, palauttamiseen valmistautumiseen kuluvan ajan ja antaa pilvipalvelujen toimittajan kopioida tiedot taustapuolelta. Asiakkaamme, jotka tekevät tämän säännöllisesti, ilmoittavat, että neljän viikon läpimenoaika (laitteen tilaamisesta pilvipalvelussa saatavaan dataan) on yleinen. Tämä nostaa laitteen lähettämisen todellisen tiedonsiirtonopeuden vain 300 megabitiin sekunnissa, paljon vähemmän, jos laitetta ei ole täysin täytetty.

Verkon siirtonopeudet riippuvat samoin useista tekijöistä, ennen kaikkea paikallisesta nousevasta linkistä. Et voi lähettää dataa nopeammin kuin fyysinen bittinopeus, mutta huolellinen tietojen valmistelu voi vähentää lähetettävän datan määrää. Vanhoilla protokollilla, mukaan lukien ne, joita pilvimyyjät käyttävät oletusarvoisesti objektien tallentamiseen, on vaikeuksia nopeuden ja luotettavuuden suhteen pitkän matkan Internet-poluilla, mikä voi tehdä bittinopeuden saavuttamisesta vaikeaa. Voisin kirjoittaa monia artikkeleita haasteista, mutta sinun ei tarvitse ratkaista tätä itse. Data Expedition on yksi harvoista yrityksistä, jotka ovat erikoistuneet varmistamaan polun täyden hyödyntämisen riippumatta siitä, kuinka kaukana tietosi ovat sen pilvikohteesta. Esimerkiksi yksi gigabittinen Internet-yhteys kiihdytysohjelmistoilla, kuten CloudDat, tuottaa 900 megabittiä sekunnissa, mikä on kolme kertaa AWS-lumipallon nettoteho.

Suurin ero fyysisen lähetyksen ja verkonsiirron välillä on myös yksi yleisimmin unohdetuista käsitteiden todistamisen yhteydessä. Fyysisen lähetyksen yhteydessä ensimmäisen laitteeseen lataamasi tavun on odotettava, kunnes viimeinen tavu ladataan, ennen kuin voit lähettää. Tämä tarkoittaa, että jos laitteen lataaminen kestää viikkoja, osa tiedoistasi on viikkoja vanhentunut siihen mennessä, kun se saapuu pilveen. Vaikka tietojoukot saavuttavat petatavun tason, jossa fyysinen toimitus voi olla nopeampaa, kyky pitää tärkeät tiedot ajan tasalla siirtoprosessin aikana voi silti suosia avainominaisuuksien verkonsiirtoa. Huolellinen suunnittelu tietojen valmistelun suodatus- ja priorisointivaiheessa on välttämätöntä, ja se voi sallia hybridimenetelmän.

Tietojen saaminen pilvipalvelujen tarjoajaan ei välttämättä ole tiedonsiirtovaiheen loppu. Jos se on toistettava useille alueille tai palveluntarjoajille, suunnittele huolellisesti, miten se pääsee sinne. Internetin kautta lataaminen on ilmaista, kun taas esimerkiksi AWS veloittaa enintään kaksi senttiä gigatavua kohdealueiden välisestä tiedonsiirrosta ja yhdeksän senttiä gigatavusta siirrosta muille pilvipalvelujen toimittajille. Molemmat menetelmät kohtaavat kaistanleveysrajoituksia, jotka voivat hyötyä liikenteen kiihdytyksestä, kuten CloudDat.

Pilvien migraation pullonkaula # 6: Pilvien skaalaus

Kun tiedot saapuvat määränpäähän pilvessä, siirtoprosessi on vasta puoli valmis. Tarkistussummat tulevat ensin: Varmista, että saapuneet tavut vastaavat lähetettyjä tavuja. Tämä voi olla hankalampaa kuin saatat ymmärtää. Tiedostotallennus käyttää välimuistikerroksia, jotka voivat piilottaa juuri ladattujen tietojen vioittumisen. Tällainen korruptio on harvinaista, mutta kunnes olet selvittänyt kaikki välimuistista ja lukea tiedostot uudelleen, et voi olla varma tarkistussummista. Ilmentymän uudelleenkäynnistys tai tallennuksen irrottaminen tekee siedettävän työn välimuistien tyhjentämisestä.

Objektitallennuksen tarkistussummien tarkistaminen edellyttää, että kukin objekti luetaan ilmentymäksi laskemista varten. Toisin kuin yleisesti uskotaan, objekti “E-tagit” ovat ei hyödyllisiä tarkistussummina. Erityisesti moniosaisia ​​tekniikoita käyttäen ladatut objektit voidaan vahvistaa vain lukemalla ne takaisin.

$config[zx-auto] not found$config[zx-overlay] not found