Kubernetes on loistava työkalu Docker-säiliöiden ajamiseen klusteroidussa tuotantoympäristössä. On kuitenkin ongelmia, joita Kubernetes ei voi ratkaista. Toistuvia tuotantokäyttöjä varten tarvitsemme täysin automatisoidun sinisen/vihreän käyttöönoton välttääksemme seisokkeja prosessissa. Sen on myös käsiteltävä ulkoisia HTTP-pyyntöjä ja suoritettava SSL-latauksia. Tämä edellyttää integrointia kuormantasaajan, kuten ha-välityspalvelimen, kanssa. Toinen haaste on itse Kubernetes-klusterin puoliautomaattinen skaalaus pilviympäristössä ajettaessa, esimerkiksi klusterin skaalaaminen osittain yöllä.
Vaikka Kubernetes ei sisällä näitä ominaisuuksia valmiina, se tarjoaa API:n, jota voit käyttää vastaavien ongelmien ratkaisemiseen. Kubernetes-klusterin automaattiseen Blue/Green käyttöönottoon ja skaalaukseen liittyvät työkalut kehitettiin osana avoimeen lähdekoodiin perustuvaa Cloud RTI -projektia.
Tämä artikkeli, videon transkriptio, näyttää, kuinka voit määrittää Kubernetesin yhdessä muiden avoimen lähdekoodin komponenttien kanssa tuotantokäyttöön sopivan ympäristön luomiseksi, joka hyväksyy koodin git-sitoumuksesta ilman tuotannon seisokkeja.
Joten kun sinulla on pääsy sovelluksiisi ulkomaailmasta, voit aloittaa automaation täydellisen asennuksen, eli viedä sen vaiheeseen, jossa voit suorittaa git-sitoumuksen ja varmistaa, että tämä git-sitoumus päätyy tuotantoon. Näitä vaiheita toteutettaessa, käyttöönottoa toteutettaessa emme luonnollisestikaan halua kohdata seisokkeja. Joten mikä tahansa automaatio Kubernetesissa alkaa API:sta.
Kubernetes ei ole työkalu, jota voidaan käyttää tuottavasti heti alusta alkaen. Tietysti voit tehdä sen, käyttää kubectliä ja niin edelleen, mutta silti API on mielenkiintoisin ja hyödyllisin asia tässä alustassa. Käyttämällä API:ta toimintosarjana voit käyttää melkein kaikkea mitä haluat tehdä Kubernetesissa. kubectl itse käyttää myös REST API:ta.
Tämä on REST, joten voit käyttää mitä tahansa kieltä tai työkalua työskennelläksesi tämän API:n kanssa, mutta mukautetut kirjastot tekevät elämästäsi paljon helpompaa. Tiimini kirjoitti 2 tällaista kirjastoa: yhden Javalle/OSGille ja toisen Golle. Toista ei käytetä usein, mutta joka tapauksessa sinulla on nämä hyödylliset asiat käytettävissäsi. Ne ovat osittain lisensoitu avoimen lähdekoodin projekti. Tällaisia kirjastoja on monia eri kielille, joten voit valita itsellesi sopivimman.
Joten ennen kuin aloitat käyttöönoton automatisoinnin, sinun on varmistettava, että prosessi ei joudu seisokkeihin. Esimerkiksi tiimimme suorittaa tuotannon käyttöönotot keskellä päivää, kun ihmiset käyttävät sovelluksia eniten, joten on tärkeää välttää viiveitä tässä prosessissa. Katkosaikojen välttämiseksi käytetään kahta tapaa: sininen/vihreä käyttöönotto tai jatkuva päivitys. Jälkimmäisessä tapauksessa, jos sinulla on käynnissä 2 kopiota sovelluksesta, ne päivitetään peräkkäin peräkkäin. Tämä menetelmä toimii hyvin, mutta se ei sovellu, jos sinulla on eri versiot sovelluksesta käynnissä samanaikaisesti käyttöönottoprosessin aikana. Tässä tapauksessa voit päivittää käyttöliittymän, kun taustajärjestelmä on käynnissä vanhassa versiossa, jolloin sovellus lakkaa toimimasta. Siksi ohjelmoinnin näkökulmasta työskentely sellaisissa olosuhteissa on melko vaikeaa.
Tämä on yksi syistä, miksi käytämme mieluummin sinistä/vihreää käyttöönottoa sovelluksiemme käyttöönoton automatisoimiseen. Tällä menetelmällä sinun on varmistettava, että vain yksi sovelluksen versio on aktiivinen kerrallaan.
Sininen/vihreä käyttöönottomekanismi näyttää tältä. Saamme sovelluksiemme liikenteen ha-proxyn kautta, joka välittää sen saman version sovelluksen käynnissä oleville replikoille.
Kun uusi käyttöönotto tehdään, käytämme Deployeria, joka saa uudet komponentit ja ottaa käyttöön uuden version. Sovelluksen uuden version käyttöönotto tarkoittaa, että uusi sarja replikoita "nostetaan", minkä jälkeen nämä uuden version kopiot käynnistetään erillisessä uudessa kotelossa. Ha-proxy ei kuitenkaan tiedä niistä mitään eikä reititä heille vielä työtaakkaa.
Siksi ensinnäkin on suoritettava uusien kuntotarkastuksen versioiden suorituskyvyn tarkistus, jotta voidaan varmistaa, että kopiot ovat valmiita palvelemaan kuormaa.
Kaikkien käyttöönottokomponenttien on tuettava jonkinlaista kuntotarkastusta. Tämä voi olla hyvin yksinkertainen HTTP-puhelun tarkistus, kun saat koodin, jonka tila on 200, tai perusteellisempi tarkistus, jossa tarkistat replikoiden yhteyden tietokantaan ja muihin palveluihin, dynaamisen ympäristön yhteyksien vakauden. , ja käynnistyykö ja toimiiko kaikki oikein. Tämä prosessi voi olla melko monimutkainen.
Kun järjestelmä on varmistanut, että kaikki päivitetyt replikat toimivat, Deployer päivittää kokoonpanon ja välittää oikean confd:n, joka määrittää ha-välityspalvelimen uudelleen.
Vasta tämän jälkeen liikenne ohjataan podiin uuden version replikoilla, ja vanha pod katoaa.
Tämä mekanismi ei ole Kubernetesin ominaisuus. Sinisen/vihreän käyttöönoton konsepti on ollut olemassa jo pitkään ja siinä on aina käytetty kuormituksen tasapainotinta. Ensin ohjaat kaiken liikenteen sovelluksen vanhaan versioon, ja päivityksen jälkeen siirrät sen kokonaan uuteen versioon. Tätä periaatetta ei käytetä vain Kubernetesissa.
Nyt esittelen sinulle uuden käyttöönottokomponentin - Deployer, joka suorittaa kuntotarkistuksia, määrittää välityspalvelimet uudelleen ja niin edelleen. Tämä on käsite, joka ei päde ulkomaailmaan ja on olemassa Kubernetesin sisällä. Näytän sinulle, kuinka voit luoda oman Deployer-konseptisi avoimen lähdekoodin työkaluilla.
Joten ensimmäinen asia, jonka Deployer tekee, on luoda RC-replikointiohjain Kubernetes API:n avulla. Tämä API luo podeja ja palveluita jatkokäyttöön, eli se luo täysin uuden klusterin sovelluksillemme. Heti kun RC on vakuuttunut replikoiden alkamisesta, se suorittaa niiden toimivuuden kuntotarkastuksen. Tätä varten Deployer käyttää GET /health -komentoa. Se suorittaa asianmukaiset tarkistuskomponentit ja tarkistaa kaikki elementit, jotka tukevat klusterin toimintaa.
Kun kaikki podit ovat raportoineet kuntostaan, Deployer luo uuden konfigurointielementin - etcd hajautetun tallennustilan, jota Kubernetes käyttää sisäisesti ja tallentaa kuormantasaajan kokoonpanon. Kirjoitamme tiedot etcd:hen ja pieneen työkaluun nimeltä confd monitors etcd uusia tietoja varten.
Jos se havaitsee muutoksia alkuperäiseen kokoonpanoon, se luo uuden asetustiedoston ja siirtää sen ha-välityspalvelimelle. Tässä tapauksessa ha-välityspalvelin käynnistyy uudelleen menettämättä yhteyksiä ja ohjaa kuormituksen uusiin palveluihin, jotka mahdollistavat sovellustemme uuden version toiminnan.
Kuten näet, komponenttien runsaudesta huolimatta tässä ei ole mitään monimutkaista. Sinun tarvitsee vain kiinnittää enemmän huomiota API ja etcd. Haluan kertoa sinulle avoimen lähdekoodin käyttöönottosovelluksesta, jota itse käytämme - Amdatu Kubernetes Deployer.
Se on työkalu Kubernetes-asennusten organisointiin, ja siinä on seuraavat ominaisuudet:
- Sininen/vihreä käyttöönotto;
- ulkoisen kuormantasaajan asettaminen;
- käyttöönoton kuvaajien hallinta;
- varsinaisen käyttöönoton hallinta;
- terveystarkastusten toimivuuden tarkistaminen käyttöönoton aikana;
- ympäristömuuttujien toteuttaminen paloiksi.
Tämä Deployer on rakennettu Kubernetes API:n päälle ja tarjoaa REST API:n kahvojen ja käyttöönottojen hallintaan sekä Websocket API:n lokien suoratoistoon käyttöönottoprosessin aikana.
Se asettaa kuormituksen tasapainottimen määritystiedot etcd:hen, joten sinun ei tarvitse käyttää ha-välityspalvelinta valmiin tuen kanssa, vaan voit helposti käyttää omaa kuormantasaajan asetustiedostoa. Amdatu Deployer on kirjoitettu Go-kielellä, kuten itse Kubernetes, ja sen lisensoi Apache.
Ennen kuin aloitin tämän käyttöönottosovelluksen version käytön, käytin seuraavaa käyttöönottokuvaajaa, joka määrittää tarvitsemani parametrit.
Yksi tämän koodin tärkeistä parametreista on "useHealthCheck"-lipun käyttöönotto. Meidän on täsmennettävä, että terveellisyystarkastus on suoritettava käyttöönottoprosessin aikana. Tämä asetus voidaan poistaa käytöstä, kun käyttöönotto käyttää kolmannen osapuolen säilöjä, joita ei tarvitse vahvistaa. Tämä kuvaaja osoittaa myös replikoiden määrän ja käyttöliittymän URL-osoitteen, jota ha-välityspalvelin tarvitsee. Lopussa on pod-spesifikaatiolippu "podspec", joka kutsuu Kubernetesin saadakseen tietoja portin kokoonpanosta, kuvasta jne. Tämä on melko yksinkertainen JSON-kuvaus.
Toinen avoimen lähdekoodin Amdatu-projektiin kuuluva työkalu on Deploymentctl. Siinä on käyttöliittymä käyttöönottojen määrittämistä varten, se tallentaa käyttöönottohistorian ja sisältää webhookeja kolmannen osapuolen käyttäjien ja kehittäjien takaisinsoittoja varten. Et voi käyttää käyttöliittymää, koska Amdatu Deployer itsessään on REST-sovellusliittymä, mutta tämä käyttöliittymä voi helpottaa käyttöönottoa sinulle paljon ilman APIa. Deploymentctl on kirjoitettu OSGi/Vertx-kielellä Angular 2:lla.
Esitän nyt yllä olevan ruudulla käyttämällä valmiiksi tallennettua tallennetta, jotta sinun ei tarvitse odottaa. Otamme käyttöön yksinkertaisen Go-sovelluksen. Älä huoli, jos et ole kokeillut Goa aiemmin, se on hyvin yksinkertainen sovellus, joten sinun pitäisi pystyä selvittämään se.
Täällä luomme HTTP-palvelimen, joka vastaa vain /healthiin, joten tämä sovellus testaa vain kuntotarkastuksen eikä mitään muuta. Jos tarkistus läpäisee, käytetään alla näkyvää JSON-rakennetta. Se sisältää sovelluksen version, jonka käyttöönottoohjelma ottaa käyttöön, tiedoston yläosassa näkyvän viestin ja loogisen tietotyypin – toimiiko sovelluksemme vai ei.
Huijasin hieman viimeisellä rivillä, koska laitoin kiinteän loogisen arvon tiedoston alkuun, mikä auttaa minua jatkossa asentamaan jopa "epäterveellisen" sovelluksen. Käsittelemme tämän myöhemmin.
Joten aloitetaan. Ensin tarkistamme käynnissä olevien podien olemassaolon komennolla ~ kubectl get pods ja koska käyttöliittymän URL-osoitteesta ei ole saatu vastausta, varmistamme, että käyttöönottoja ei tehdä tällä hetkellä.
Seuraavaksi näet näytöllä mainitsemani Deploymentctl-käyttöliittymän, jossa käyttöönottoparametrit on asetettu: nimiavaruus, sovelluksen nimi, käyttöönottoversio, replikoiden määrä, käyttöliittymän URL-osoite, säilön nimi, kuva, resurssirajoitukset, portin numero kuntotarkastukseen, jne. Resurssirajoitukset ovat erittäin tärkeitä, koska niiden avulla voit käyttää mahdollisimman paljon laitteistoa. Täältä voit myös tarkastella käyttöönottolokia.
Jos toistat nyt komennon ~ kubectl get pods, voit nähdä, että järjestelmä "jäätyy" 20 sekunniksi, jonka aikana ha-proxy konfiguroidaan uudelleen. Tämän jälkeen pod käynnistyy, ja replikamme näkyy käyttöönottolokissa.
Leikasin videosta 20 sekunnin odotuksen, ja nyt näet näytöllä, että sovelluksen ensimmäinen versio on otettu käyttöön. Kaikki tämä tehtiin käyttämällä vain käyttöliittymää.
Kokeillaan nyt toista versiota. Tätä varten muutan sovelluksen viestin "Hei, Kubernetes!" kohdassa "Hei, Deployer!", järjestelmä luo tämän kuvan ja sijoittaa sen Docker-rekisteriin, minkä jälkeen napsautamme "Deploy"-painiketta uudelleen Deploymentctl-ikkunassa. Tässä tapauksessa käyttöönottoloki käynnistetään automaattisesti samalla tavalla kuin sovelluksen ensimmäistä versiota otettaessa.
Komento ~ kubectl get pods osoittaa, että sovelluksesta on tällä hetkellä käynnissä kaksi versiota, mutta käyttöliittymä näyttää, että käytämme edelleen versiota 2.
Kuormantasaaja odottaa kuntotarkastuksen valmistumista ennen kuin ohjaa liikenteen uuteen versioon. 20 sekunnin kuluttua siirrymme curl-tilaan ja näemme, että sovelluksen versio 2 on nyt otettu käyttöön ja ensimmäinen on poistettu.
Tämä oli "terveen" sovelluksen käyttöönotto. Katsotaan mitä tapahtuu, jos muutan sovelluksen uuden version Healthy-parametrin true arvosta false, eli yritän ottaa käyttöön epäterveellisen sovelluksen, joka ei läpäissyt kuntotarkastusta. Näin voi käydä, jos sovellukseen on tehty kehitysvaiheessa konfigurointivirheitä ja se on lähetetty tuotantoon tässä muodossa.
Kuten näet, käyttöönotto käy läpi kaikki yllä olevat vaiheet ja ~kubectl get pods osoittaa, että molemmat podit ovat käynnissä. Mutta toisin kuin edellisessä käyttöönotossa, loki näyttää aikakatkaisun tilan. Toisin sanoen sovelluksen uutta versiota ei voida ottaa käyttöön, koska kuntotarkastus epäonnistui. Tämän seurauksena näet, että järjestelmä on palannut käyttämään sovelluksen vanhaa versiota ja uusi versio on yksinkertaisesti poistettu.
Hyvä puoli tässä on, että vaikka sovellukseen tulee valtava määrä samanaikaisia pyyntöjä, ne eivät edes huomaa käyttökatkoksia käyttöönottoprosessin aikana. Jos testaat tätä sovellusta käyttämällä Gatling-kehystä, joka lähettää sille mahdollisimman monta pyyntöä, mitään näistä pyynnöistä ei hylätä. Tämä tarkoittaa, että käyttäjämme eivät edes huomaa versiopäivityksiä reaaliajassa. Jos se epäonnistuu, työ jatkuu vanhan version parissa; jos se onnistuu, käyttäjät siirtyvät uuteen versioon.
Vain yksi asia voi epäonnistua - jos kuntotarkastus onnistuu, mutta sovellus epäonnistuu heti, kun siihen kohdistetaan työkuormitus, eli romahdus tapahtuu vasta käyttöönoton jälkeen. Tässä tapauksessa sinun on palattava manuaalisesti vanhaan versioon. Joten tarkastelimme, kuinka Kubernetesia käytetään siihen suunniteltujen avoimen lähdekoodin työkalujen kanssa. Käyttöönottoprosessi on paljon helpompi, jos lisäät nämä työkalut Build/Deploy-putkiin. Samanaikaisesti voit aloittaa käyttöönoton käyttämällä joko käyttöliittymää tai automatisoida tämän prosessin kokonaan käyttämällä esimerkiksi commit to master -toimintoa.
Build-palvelimemme luo Docker-kuvan, työntää sen Docker Hubiin tai mihin tahansa käyttämääsi rekisteriin. Docker Hub tukee webhookia, joten voimme käynnistää etäkäytön Deployerin kautta yllä kuvatulla tavalla. Näin voit täysin automatisoida sovelluksesi käyttöönoton mahdolliseen tuotantoon.
Siirrytään seuraavaan aiheeseen - Kubernetes-klusterin skaalaus. Huomaa, että kubectl-komento on skaalauskomento. Lisäämällä apua voimme helposti lisätä replikoiden määrää olemassa olevassa klusterissamme. Käytännössä haluamme kuitenkin yleensä lisätä solmujen määrää koteloiden sijaan.
Samanaikaisesti työaikana saatat joutua lisäämään ja yöllä vähentääksesi Amazon-palveluiden kustannuksia, saatat joutua vähentämään käynnissä olevien sovellusten määrää. Tämä ei tarkoita, että pelkkä podien määrän skaalaaminen riittäisi, sillä vaikka yksi solmuista olisi käyttämättömänä, joudut silti maksamaan siitä Amazonille. Toisin sanoen skaalauspalojen skaalaamisen lisäksi sinun on skaalattava käytettyjen koneiden lukumäärä.
Tämä voi olla haastavaa, koska käytämmepä Amazonia tai muuta pilvipalvelua, Kubernetes ei tiedä käytettyjen koneiden määrästä mitään. Siitä puuttuu työkalu, jonka avulla voit skaalata järjestelmää solmutasolla.
Joten meidän on huolehdittava sekä solmuista että paloista. Voimme helposti skaalata uusien solmujen käynnistämistä käyttämällä AWS-sovellusliittymää ja skaalausryhmäkoneita Kubernetes-työsolmujen määrän määrittämiseksi. Voit myös rekisteröidä Kubernetes-klusterin solmuja käyttämällä cloud-initiä tai vastaavaa komentosarjaa.
Uusi kone käynnistyy Skaalaus-ryhmässä, aloittaa itsensä solmuna, rekisteröityy isäntärekisteriin ja alkaa toimia. Tämän jälkeen voit lisätä replikoiden määrää käytettäviksi tuloksena olevissa solmuissa. Skaalaus vaatii enemmän vaivaa, sillä sinun on varmistettava, että tällainen vaihe ei johda jo käynnissä olevien sovellusten tuhoutumiseen "tarpeettomien" koneiden sammuttamisen jälkeen. Tällaisen skenaarion estämiseksi sinun on asetettava solmut "ei ajoitettava" -tilaan. Tämä tarkoittaa, että oletusajoitin ohittaa nämä solmut ajoitessaan DaemonSet-tyyppejä. Ajastin ei poista mitään näistä palvelimista, mutta ei myöskään käynnistä siellä uusia säilöjä. Seuraava askel on tyhjennyssolmun syrjäyttäminen, eli käynnissä olevien podien siirtäminen siitä toiseen koneeseen tai muihin solmuihin, joilla on riittävä kapasiteetti tähän. Kun olet varmistanut, että näissä solmuissa ei ole enää säilöjä, voit poistaa ne Kubernetesista. Tämän jälkeen ne yksinkertaisesti lakkaavat olemasta Kubernetesille. Seuraavaksi sinun on käytettävä AWS-sovellusliittymää tarpeettomien solmujen tai laitteiden poistamiseen käytöstä.
Voit käyttää Amdatu Scalerdia, toista avoimen lähdekoodin skaalaustyökalua, joka on samanlainen kuin AWS API. Se tarjoaa CLI:n klusterin solmujen lisäämiseen tai poistamiseen. Sen mielenkiintoinen ominaisuus on kyky määrittää ajoitus käyttämällä seuraavaa json-tiedostoa.
Esitetty koodi vähentää klusterin kapasiteettia puoleen yön aikana. Se määrittää sekä käytettävissä olevien kopioiden määrän että Amazon-klusterin halutun kapasiteetin. Tämän ajastimen käyttäminen vähentää automaattisesti solmujen määrää yöllä ja lisää niitä aamulla, mikä säästää Amazonin kaltaisen pilvipalvelun solmujen käyttökustannuksia. Tätä ominaisuutta ei ole sisäänrakennettu Kubernetesiin, mutta Scalerdin avulla voit skaalata tätä alustaa haluamallasi tavalla.
Haluaisin huomauttaa, että monet ihmiset sanovat minulle: "Se on hyvä ja hyvä, mutta entä tietokantani, joka on yleensä staattinen?" Kuinka voit ajaa jotain tällaista dynaamisessa ympäristössä, kuten Kubernetes? Mielestäni sinun ei pitäisi tehdä tätä, sinun ei pitäisi yrittää ajaa tietovarastoa Kubernetesissa. Tämä on teknisesti mahdollista, ja Internetissä on tästä aiheesta opetusohjelmia, mutta se vaikeuttaa elämääsi vakavasti.
Kyllä, Kubernetesissa on pysyvien varastojen käsite, ja voit yrittää ajaa tietovarastoja, kuten Mongo tai MySQL, mutta tämä on melko työvoimavaltainen tehtävä. Tämä johtuu siitä, että tietovarastot eivät täysin tue vuorovaikutusta dynaamisen ympäristön kanssa. Useimmat tietokannat vaativat merkittäviä määrityksiä, mukaan lukien klusterin manuaalinen konfigurointi, eivät pidä automaattisesta skaalauksesta ja muista vastaavista asioista.
Siksi sinun ei pitäisi monimutkaistaa elämääsi yrittämällä ylläpitää tietovarastoa Kubernetesissa. Järjestä heidän työnsä perinteisellä tavalla tuttujen palveluiden avulla ja tarjoa Kubernetes yksinkertaisesti kyky käyttää niitä.
Aiheen päätteeksi haluaisin esitellä sinulle Kubernetesiin perustuvan Cloud RTI -alustan, jonka parissa tiimini työskentelee. Se tarjoaa keskitetyn kirjaamisen, sovellusten ja klusterien valvonnan sekä monia muita hyödyllisiä ominaisuuksia, joista on hyötyä. Se käyttää erilaisia avoimen lähdekoodin työkaluja, kuten Grafanaa, valvonnan näyttämiseen.
Heräsi kysymys, miksi käyttää Kubernetesin kanssa ha-proxy-kuormituksen tasapainotinta. Hyvä kysymys, koska tällä hetkellä on olemassa 2 kuormitustasoa. Kubernetes-palvelut sijaitsevat edelleen virtuaalisissa IP-osoitteissa. Et voi käyttää niitä ulkoisten isäntäkoneiden porteille, koska jos Amazon ylikuormittaa pilviisäntäänsä, osoite muuttuu. Siksi asetamme ha-proxyn palveluiden eteen - luodaksemme staattisemman rakenteen, jotta liikenne voi kommunikoida saumattomasti Kubernetesin kanssa.
Toinen hyvä kysymys on, kuinka voit huolehtia tietokantaskeeman muutoksista, kun teet sinistä/vihreää käyttöönottoa? Tosiasia on, että Kubernetesin käytöstä riippumatta tietokantakaavion muuttaminen on vaikea tehtävä. Sinun on varmistettava, että vanha ja uusi skeema ovat yhteensopivia, minkä jälkeen voit päivittää tietokannan ja päivittää sitten itse sovellukset. Voit vaihtaa tietokannan ja päivittää sitten sovellukset. Tiedän ihmisiä, jotka ovat käynnistäneet täysin uuden tietokantaklusterin uudella skeemalla. Tämä on vaihtoehto, jos sinulla on järjestelmätön tietokanta, kuten Mongo, mutta se ei kuitenkaan ole helppo tehtävä. Jos sinulla ei ole lisäkysymyksiä, kiitos huomiostasi!
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com