Kubernetes është një mjet i shkëlqyer për të drejtuar konteinerët Docker në një mjedis të klasterizuar të prodhimit. Megjithatë, ka detyra që Kubernetes nuk mund t'i zgjidhë. Kur shpërndajmë shpesh në mjedisin e punës, na nevojitet një implementim Blue/Green plotësisht i automatizuar për të shmangur ndalimet në këtë proces, gjatë të cilit gjithashtu duhet të trajtojmë kërkesat ekstern HTTP dhe të kryejmë shkarkimin SSL. Kjo kërkon integrim me një balancues ngarkese si ha-proxy. Një detyrë tjetër është shkallëzimi gjysmë automatizuar i vetë klasterit Kubernetes kur punon në një mjedis cloud, për shembull, zvogëlimi i pjesshëm i klasterit gjatë natës.
Ndërsa Kubernetes nuk i ka këto funksione direkt "nga kutia", ai ofron një API që mund të shfrytëzohet për zgjidhjen e këtyre detyrave. Veglat për implementimin e automatizuar Blue/Green dhe shkallëzimin e klasterit Kubernetes janë zhvilluar në kuadër të projektit Cloud RTI, i cili është ndërtuar mbi bazën e open-source.
Në këtë artikull, në transkriptin e videos, shpjegohet se si të konfiguroni Kubernetes bashkë me komponente të tjera me burim të hapur për krijimin e një mjedisi të gatshëm për prodhim, i cili pranon kod nga angazhimi git commit pa ndërprerje në prodhim.
Pra, pasi të keni aksesuar aplikacionet tuaja nga bota e jashtme, mund të filloni konfigurimin e plotë të automatizimit, duke e çuar atë në një fazë në të cilën mund të realizoni git commit dhe të siguroni që ky git commit përfundon në prodhim. Natyrisht, gjatë realizimit të këtyre hapave, gjatë desplojimit, ne nuk duam të hasim ndonjë ndërprerje. Pra, çdo automatizim në Kubernetes fillon me API.
Kubernetes nuk është një mjet që mund të përdoret produktivisht "në mënyrë të drejtpërdrejtë nga kutia". Sigurisht, mund ta bëni këtë, duke përdorur kubectl etj., por API është gjëja më interesante dhe e dobishme e kësaj platforme. Duke përdorur API-në si një grup funksionesh, mund të keni akses në pothuajse çdo gjë që dëshironi të bëni në Kubernetes. Vetë kubectl gjithashtu përdor REST API.
Kjo është REST, kështu që mund të përdorni çdo gjuhë dhe mjet për të punuar me këtë API, por libraritë përdoruese do t'ju lehtësojnë jetën në mënyrë të konsiderueshme. Ekipi im ka shkruar 2 libra të tillë: një për Java / OSGi dhe një për Go. I dyti nuk përdoret shpesh, por gjithsesi, keni në dispozicion këto mjete të dobishme. Ato janë një projekt pjesërisht i licencuar me burim të hapur. Ekzistojnë shumë libra të tillë për gjuhë të ndryshme, kështu që mund të zgjidhni ato që i përshtaten më mirë.
Pra ndaj, para se të filloni me automatizimin e shpërndarjes, duhet të siguroheni që ky proces të mos pësojë asnjë ndalesë. Për shembull, ekipi ynë kryen shpërndarje në prodhim në mes të ditës, kur njerëzit po e përdorin maksimalisht aplikacionin, prandaj është shumë e rëndësishme të evitoni vonesat në këtë proces. Për të shmangur ndalesat, përdoren dy mënyra: shpërndarje blue/green ose përditësim i vazhdueshëm rolling update. Në rastin e fundit, nëse keni 5 replika të aplikacionit, ato përditësohen një nga një në mënyrë të rregullt. Kjo metodë funksionon shumë mirë, por nuk është e përshtatshme nëse gjatë shpërndarjes keni versione të ndryshme të aplikacionit që funksionojnë njëkohësisht. Në këtë rast, mund të përditësoni ndërfaqen e përdoruesit ndërkohë që backend-i punon me versionin e vjetër, dhe puna e aplikacionit do të ndërpritet. Prandaj, nga pikëpamja e programimit, punimi në kushte të tilla është mjaft i vështirë.
Kjo është një nga arsyet pse ne preferojmë të përdorim blue/green deployment për automatizimin e implementimit të aplikacioneve tona. Me këtë metodë, ju duhet të siguroheni se në çdo moment aktiv është vetëm një version i aplikacionit.
Mekanizmi i blue/green deployment duket si vijon. Ne marrim trafik për aplikacionet tona përmes ha-proxy, i cili e drejton atë te instancat e aktivizuara të aplikacionit të të njëjtit version.
Kur bëhet një implementim i ri, ne përdorim Deployer, i cili merr komponentët e rinj dhe bën implementimin e versionit të ri. Implementimi i versionit të ri të aplikacionit do të thotë se një grup i ri instancash "ngrihet", pas së cilës këto instanca të versionit të ri aktivizohen në një konteiner të ri dhe të ndarë. Megjithatë, ha-proxy nuk di asgjë për ta dhe për momentin nuk drejton asnjë ngarkesë pune te ato.
Prandaj, e para që duhet bërë është të kryhen kontrollet e shëndetshmërisë së versioneve të reja për t'u siguruar se instancat janë të gatshme për të trajtuar ngarkesën.
Të gjithë komponentët e shpërndarjes duhet të mbështesin ndonjë formë të kontrollit të shëndetit. Kjo mund të jetë një kontroll i thjeshtë HTTP, kur merrni një status kod 200, ose një kontroll më i thellë, ku verifikoni lidhjen e kopjeve me databazën dhe shërbimet e tjera, qëndrueshmërinë e lidhjeve në ambientin dinamik, si dhe nëse gjithçka po nis dhe funksionon siç duhet. Ky proces mund të jetë mjaft kompleks.
Pasi sistemi të jetë siguruar për funksionimin e të gjitha kopjeve të azhurnuara, Deployer do të përditësojë konfigurimin dhe do të dërgojë confd-në e sakta, e cila do të rikonfiguronte ha-proxy-n.
Vetëm pas kësaj, trafiku do të drejtohet në nënshtrimin me kopjet e versions së re, ndërsa nënshtrimi i vjetër do të zhduket.
Ky mekanizëm nuk është një veçori e Kubernetes. Koncepti i shpërndarjes Blue/green ekziston për një kohë të gjatë dhe gjithmonë ka përdorur një balancues ngarkese. Fillimisht, ju drejtoni të gjithë trafikun drejt versionit të vjetër të aplikacionit dhe pas përditësimit, plotësisht e shndërroni atë në versionin e ri. Ky princip përdoret jo vetëm në Kubernetes.
Tani unë do t'ju prezantoj një komponent të ri të shpërndarjes – Deployer, i cili kryen verifikimin e funksionimit, rindërton proxy dhe më shumë. Ky është një koncept që nuk lidhet me botën e jashtme dhe ekziston brenda Kubernetes. Do t'ju tregoj se si mund të krijoni konceptin tuaj Deployer duke përdorur mjetet open-source.
Pra, e para që bën Deployer është krijimi i një kontrolluesi të replikimit RC, duke përdorur API-në e Kubernetes. Ky API krijon pod-e dhe shërbime për shpërndarjen e mëtejshme, domethënë krijon një klasë krejt të re për aplikacionet tona. Sapo RC të sigurohet që replikat kanë nisur, ai do të kryejë një kontroll të funksionimit Health check. Për këtë, në Deployer përdoret komanda GET /health. Ajo aktivizon komponentët përkatës të kontrollit dhe verifikon të gjitha elementet që sigurojnë funksionimin e klasës.
Pasi që të gjitha pods raportojnë për "shëndetin" e tyre, Deployer krijon një element të ri konfigurimi – një ruajtje të shpërndarë etcd, e cila përdoret brenda Kubernetes, duke përfshirë për ruajtjen e konfiguracionit të balancuesit të ngarkesës. Ne regjistrojmë të dhënat në etcd, dhe një mjet i vogël confd monitoron etcd për të zbuluar të dhëna të reja.
Nëse ai zb发现 ndonjë ndryshim në konfigurimin e parë, ai gjeneron një skedar të ri konfigurimi dhe ia dërgon ha-proxy. Në këtë rast, ha-proxy rindez pa humbur asnjë lidhje dhe adreson ngarkesën te shërbimet e reja, të cilat sigurojnë funksionimin e versioneve të reja të aplikacioneve tona.
Siç e shihni, pavarësisht nga numri i madh i komponentëve, nuk ka asgjë të komplikuar këtu. Ju thjesht duhet të kushtoni më shumë vëmendje API dhe etcd. Dua t'ju flas për një depozitor open-source, që ne e përdorim vetë – Amdatu Kubernetes Deployer.
Ky është një mjet për orkestrimin e implementimeve Kubernetes, që ka funksione të tilla si:
- implementimi Blue/Green;
- konfigurimi i balancuesit të ngarkesës së jashtme;
- menaxhimi i spesifikimeve të implementimit;
- menaxhimi i implementimit të vërtetë;
- kontrollimi i funksionalitetit të provave të shëndetit gjatë vendosjes;
- implementimi i variablave të mjedisit në pod.
Ky Deployer është ndërtuar mbi API-në Kubernetes dhe ofron një API REST për menaxhimin e descriptorëve dhe vendosjeve, si dhe një API Websocket për log të drejtpërdrejt gjatë procesit të vendosjes.
Ai vendos të dhënat e konfiguarimit të balancuesit të ngarkesës në etcd, kështu që nuk keni nevojë të përdorni ha-proxy me mbështetje 'ndoshta nga kutia', por mund të përdorni lehtësisht skedarin tuaj të konfiguruar për balancuesin. Amdatu Deployer është shkruar në Go, ashtu si Kubernetes vetë, dhe licencohet nga Apache.
Para se të filloja të aplikoj këtë version të deployerit, përdora këtë descriptor vendosjeje ku janë përcaktuar parametrat e nevojshëm.
Një nga parametrat e rëndësishëm të këtij kodi është aktivizimi i flagut "useHealthCheck". Na nevojitet të specifikojmë se gjatë procesit të shpërndarjes duhet të kryhet kontrolli i funksionimit. Ky parametr mund të jetë i çaktivizuar kur në shpërndarje përdoren kontejnerë të palëve të treta që nuk kanë nevojë për verifikim. Në këtë përshkrim gjithashtu është e specifikuar numri i replikave dhe URL-ja e front-end-it që i nevojitet ha-proxy. Në fund, përmendet flagu i specifikimit të pods "podspec", i cili i drejtohet Kubernetes për të marrë informacion në lidhje me konfigurimin e porteve, imazhit etj. Ky është një përshkrim mjaft i thjeshtë në formatin JSON.
Një mjet tjetër, i cili është pjesë e projektit open-source Amdatu, është Deploymentctl. Ai ka një ndërfaqe përdoruesi (UI) për konfigurimin e shpërndarjes, ruan historinë e shpërndarjeve dhe përmban webhooks për thirrjet e rikthimit nga përdoruesit e jashtëm dhe zhvilluesit. Ju mund të mos përdorni UI-në, pasi vetë Amdatu Deployer është një REST API, por kjo ndërfaqe mund ta lehtësojë shumë procesin e shpërndarjes pa nevojën për angazhimin e ndonjë API. Deploymentctl është shkruar në OSGi/Vertx duke përdorur Angular 2.
Tani unë do të demonstroj atë që përmenda më parë në ekran, duke përdorur një regjistrim të bërë më parë, kështu që ju nuk do të duhet të prisni. Ne do të zhvillojmë një aplikacion të thjeshtë në Go. Mos u shqetësoni nëse nuk keni pasur ndonjëherë përvojë me Go, ky është një aplikacion shumë i thjeshtë, kështu që gjithçka do t'ju jetë e qartë.
Këtu ne po krijojmë një server HTTP që përgjigjet vetëm në /health, kështu që ky aplikacion vetëm kontrollon statusin e shëndetit dhe asgjë më shumë. Nëse kontrolli kalon, aktivizohet struktura JSON e paraqitur më poshtë. Ajo përmban versionin e aplikacionit që do të implementohet nga deployer-i, mesazhin që shihni në krye të skedarit dhe tipin boolean - nëse aplikacioni ynë është në gjendje apo jo.
Me rreshtin e fundit kam bërë një truk të vogël, sepse kam vendosur një vlerë konstante boolean në krye të skedarit, e cila më vonë do të ndihmojë në zhvillimin edhe të një aplikacioni "jo të shëndoshë". Më vonë do ta diskutojmë këtë.
Pra, le të fillojmë. Së pari, kontrollojmë për ndonjë pod të hapur duke përdorur komandën ~ kubectl get pods dhe në mungesë të përgjigjes nga URL-ja e frontend-it, sigurohemi se nuk ka asnjë implementim në këtë moment.
Далее на экране вы видите упомянутый мною интерфейс Deploymentctl, в котором задаются параметры развертывания: пространство имен, имя приложения, версию развертывания, количество реплик, фронтенд-URL, название контейнера, образ, лимиты ресурсов, номер порта для проверки health check и т.д. Лимиты ресурсов очень важны, так как позволяют задействовать максимально возможное количество «железа». Здесь же можно просмотреть журнал развертывания Deployment log.
Если сейчас повторить команду ~ kubectl get pods, видно, что система «замирает» на 20 секунд, в процессе которых происходит реконфигурация ha-proxy. После этого под запускается, и нашу реплику можно увидеть в логе развертывания.
Я вырезал из видео 20-ти секундное ожидание, и сейчас вы видите на экране, что первая версия приложения развернута. Все это было проделано только при помощи UI.
Tani tani le të provojmë versionin e dytë. Për këtë, unë po e ndryshoj mesazhin e aplikacionit nga «Hello, Kubernetes!» në «Hello, Deployer!», sistemi krijon këtë imazh dhe e vendos në regjistrin Docker, pas së cilës ne thjesht klikojmë përsëri në butonin «Deploy» në dritaren Deploymentctl. Kjo aktivizon automatikisht logun e implementimit po ashtu siç ndodhi me implementimin e versionit të parë të aplikacionit.
Koma ~ kubectl get pods tregon se aktualisht janë aktivizuar 2 versione të aplikacionit, por frontend-i tregon se ne ende kemi versionin 1 në punë.
Balancuesi i ngarkesës pret deri sa të kryhet kontrollet e shëndetit (health check), pas së cilës do të ridrejtojë trafikun në versionin e ri. Pas 20 sekondash, ne kalojmë në curl dhe shohim se tani kemi implementuar versionin 2 të aplikacionit, ndërsa versioni i parë është fshirë.
Ishte një implementim i aplikacionit "të shëndetshëm" — healthy. Le të shohim se çfarë do të ndodhë nëse për versionin e ri të aplikacionit e ndryshoj vlerën e parametrave Healthy nga true në false, domethënë do të provoj të implementoj një aplikacion të pa shëndetshëm, i cili nuk ia doli kontrollit të funksionalitetit. Kjo mund të ndodhë nëse gjatë fazës së zhvillimit ishin bërë disa gabime konfigurimi dhe ai u dërgua në prodhim në këtë formë.
Siç e shihni, implementimi kalon të gjitha etapat e lartpërmendura, dhe ~ kubectl get pods tregon se të dy pod-et janë aktivizuar. Por ndryshe nga implementimi i mëparshëm, logu tregon një gjendje timeout. Domethënë, për shkak se kontrolli i shëndetit nuk arriti, versioni i ri i aplikacionit nuk mund të implementohet. Si rezultat, ju shihni se sistemi është kthyer në përdorimin e versionit të vjetër të aplikacionit, ndërsa versioni i ri u fshi.
E mira e këtij është se, edhe nëse keni një numër të madh kërkesash të njëkohshme që po vijnë në aplikacion, ato nuk do të ndiejnë asnjë pushim gjatë realizimit të procedurës së shpërndarjes. Nëse e testoni këtë aplikacion me kornizën Gatling, e cila i dërgon atij numrin maksimalt të mundshëm të kërkesave, asnjë nga këto kërkesa nuk do të refuzohet. Kjo do të thotë se përdoruesit tanë nuk do ta ndiejnë asnjëherë përditësimin e versioneve në kohë reale. Nëse përditësimi dështon, puna do të vazhdojë në versionin e vjetër; nëse është e suksesshme, përdoruesit do të kalojnë në versionin e ri.
Ka ekziston vetëm një gjë që mund të çojë në dështim – nëse kontrolli i shëndetit kalon me sukses, por aplikacioni dështon sapo merr ngarkesën e punës, do të thotë se kolapsi do të ndodhi vetëm pasi të përfundojë shpërndarja. Në këtë rast, do t'ju duhet të riktheheni manualisht në versionin e vjetër. Pra, shqyrtuam se si të përdorim Kubernetes me mjetet e tij open-source. Procedura e shpërndarjes do të jetë shumë më e thjeshtë nëse i integroni këto mjete në pipeline-t e ndërtimit/shpërndarjes Build/Deploy. Për këtë, mund të përdorni si ndërfaqen e përdoruesit ashtu edhe ta automatizoni plotësisht këtë proces, duke aplikuar, për shembull, commit to master.
Serveri ynë i ndërtimit Build Server do të krijojë një imazh Docker, do ta ngarkojë atë në Docker Hub ose në çdo regjistër tjetër që përdorni. Docker Hub mbështet webhook, kështu që mund të nisim një shpërndarje të largët përmes Deployer në mënyrën e treguar më sipër. Kështu mund të automatizoni plotësisht shpërndarjen e aplikacionit në prodhimin e mundshëm.
Të kalojmë te tema tjetër – shkallëzimi i klasterit Kubernetes. Vërej se komanda kubectl është komanda për shkallëzim. Me ndihmën e saj, mund të rritet lehtësisht numri i replikave në klasterin tonë të disponueshëm. Megjithatë, në praktikë, zakonisht dëshirojmë të rrisim numrin e nodëve, jo të podëve.
Në këtë mënyrë, gjatë orëve të punës mund t'ju nevojitet rritje, ndërsa gjatë natës, për të reduktuar kostot e shërbimeve të Amazon – zvogëlimi i numrit të instancave të aplikacioneve të lancuara. Kjo nuk do të thotë se mjafton të shkallëzohet vetëm numri i podëve, sepse edhe nëse një nga nodët është i papunë, do të duhet të paguani për të Amazon. Domethënë, përveç shkallëzimit të podëve, do t'ju nevojitet gjithashtu të shkallëzoni numrin e makinave të përdorura.
Kjo mund të shkaktojë vështirësi, sepse pavarësisht nëse përdorim Amazon ose ndonjë shërbim tjetër cloud, Kubernetes nuk di asgjë për numrin e makinave të përdorura. Ajo nuk ka një mjet që lejon shkallëzimin e sistemit në nivelin e nodëve.
Prandaj, do të duhet të kujdesemi për nodet dhe pods. Mund të vetëm të shkallëzojmë nisjen e nodave të rinj duke përdorur AWS API dhe makinat e grupit të shkallëzimit për të përcaktuar numrin e nyjeve punuese në Kubernetes. Gjithashtu, mund të përdorim cloud-init ose një skenar të ngjashëm për të regjistruar nodet në klasterin Kubernetes.
Новая машина стартует в Scaling group, инициирует себя как нод, прописывается в реестре мастера и начинает работу. После этого можно увеличить количество реплик для использования на образовавшихся нодах. Уменьшение масштаба требует больший усилий, так как необходимо убедиться, что подобный шаг не приведет к уничтожению уже работающих приложений после отключения «ненужных» машин. Для предотвращения такого сценария нужно привести ноды к статусу «unschedulable». Это означает, что планировщик по умолчанию при планировании подов DaemonSet будет игнорировать эти ноды. Планировщик не станет ничего удалять с этих серверов, но и будет запускать там никаких новых контейнеров. Следующих шаг заключается в вытеснении узла drain node, то есть в переносе с него работающих подов на другую машину, или другие ноды, обладающие достаточной для этого емкостью. Убедившись, что на этих узлах больше нет никаких контейнеров, их можно удалить из Kubernetes. После этого для Kubernetes они просто перестанут существовать. Далее нужно использовать AWS API для отключения ненужных узлов, или машин.
Mund të përdorni Amdatu Scalerd — një tjetër mjet open-source për skalimin, i ngjashëm me AWS API. Ai ofron CLI për të shtuar ose hequr nodes në klaster. Një veçori interesante është mundësia për të konfiguruar planifikuesin përmes këtij skedari json.
Kodi i paraqitur redukton kapacitetin e klasterit në mënyrë të pjesshme gjatë natës. Ai është i konfiguruar si për numrin e replikave ekzistuese, ashtu edhe për kapacitetin e dëshiruar të klasterit Amazon. Përdorimi i këtij planifikuesi do të reduktojë automatikisht numrin e nodave gjatë natës dhe do t'i rrisë ato në mëngjes, duke lejuar kursim të kostove për përdorimin e nodave të një shërbimi të tillë në re si Amazon. Kjo funksionalitet nuk është e ndërtuar në Kubernetes, por përdorimi i Scalerd do t'ju lejojë të shkalloni këtë platformë sipas dëshirës.
Dua të theksoj se shumë njerëz më thonë: "Kjo është e gjitha mirë, por si bëhet me bazën time të të dhënave, e cila zakonisht është në një gjendje statike?" Si mund të funksionojë diçka e tillë në një mjedis të tillë dinamik si Kubernetes? Në opinionin tim, nuk duhet ta bëni, nuk duhet të përpiqeni të organizoni funksionimin e depozitimit të të dhënave në Kubernetes. Teknikisht është e mundur, dhe ka udhëzime në internet për këtë, megjithatë, do ta komplikohej ndjeshëm jetën tuaj.
Po, në Kubernetes ekziston koncepti i magazinave të qëndrueshme, dhe ju mund të përpiqeni të ekzekutoni magazina të dhënash si Mongo ose MySQL, por kjo është një detyrë mjaft e ndërlikuar. Kjo është për shkak se magazinat e dhënash nuk e mbështesin plotësisht ndërveprimin me një mjedis dinamik. Shumica e bazave të të dhënave kërkojnë konfigurim të konsiderueshëm, duke përfshirë konfigurimin manual të klasterit, nuk i pëlqejnë automatizimet dhe gjëra të ngjashme.
Prandaj, nuk ka kuptim ta komplikoni jetën tuaj duke u përpjekur të lançoni një depozitë të dhënash në Kubernetes. Organizoni punën e tyre në mënyrë tradicionale duke përdorur shërbime të njohura dhe thjesht jepni mundësinë që Kubernetes t'i përdorë ato.
Në përfundim të temës, dëshiroj t'ju prezantoj me platformën Cloud RTI të bazuar në Kubernetes, mbi të cilën punon ekipi im. Ajo ofron menaxhim të centralizuar të regjistrave, monitorim të aplikacioneve dhe klasterëve, dhe ka shumë funksione të tjera të dobishme që do t'ju duhen. Përdoren disa mjete open-source, si Grafana për vizualizimin e monitorimit.
U paraqit një pyetje, pse duhet të përdorim një balancues ngarkese ha-proxy me Kubernetes. Është një pyetje e mirë, sepse aktualisht ekzistojnë 2 nivele balancimi ngarkese. Shërbimet e Kubernetes akoma ndodhen në adresat IP virtuale. Nuk mund t'i përdorni ato për portet e makinave të jashtme, sepse nëse Amazon ngarkon host-in e saj në oborr, adresa do të ndryshojë. Kjo është arsyeja pse ne vendosim ha-proxy përpara shërbimeve, për të krijuar një strukturë më statike për një ndërveprim të papenguar të trafikut me Kubernetes.
Një pyetje tjetër e mirë – si mund të kujdesemi për ndryshimin e skemës së bazës së të dhënave gjatë implementimit të blue/green? Është e vërtetë se, pavarësisht nga përdorimi i Kubernetes, ndryshimi i skemës së bazës së të dhënave është një detyrë e vështirë. Duhet të siguroheni që skema e vjetër dhe ajo e re të jenë të përputhshme, pastaj mund të përditësoni bazën e të dhënave dhe më pas aplikacionet vetë. Mund të kryeni një “zëvendësim të nxehtë” të bazës së të dhënave dhe pastaj të përditësoni aplikacionet. Njoh njerëz që kanë ngarkuar një kluster krejt të ri të bazës së të dhënave me skemë të re, ky është një opsion nëse keni një bazë të dhënash pa skema si Mongo, por në çdo rast, kjo nuk është një detyrë e lehtë. Nëse nuk ka më pyetje, faleminderit për vëmendjen!
Pak reklamë 🙂
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish më i lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
