Kubernetes – гэта выдатная прылада для запуску кантэйнераў Docker у кластарызаваным вытворчым асяроддзі. Аднак існуюць задачы, якія Kubernetes рашыць не ў стане. Пры частым разгортванні ў працоўным асяроддзі мы маем патрэбу ў цалкам аўтаматызаваным Blue/Green deployment, каб пазбегнуць прастояў у дадзеным працэсе, пры якім таксама неабходна апрацоўваць вонкавыя HTTP-запыты і выконваць выгрузку SSL. Гэта патрабуе інтэграцыі з балансавальнікам нагрузкі, такім як ha-proxy. Іншай задачай з'яўляецца паўаўтаматычнае маштабаванне самога кластара Kubernetes пры працы ў хмарным асяроддзі, напрыклад, частковае памяншэнне маштабу кластара ў начны час.
Хоць Kubernetes не валодае гэтымі функцыямі прама са скрынкі , ён падае API, якім можна скарыстацца для рашэння падобных задач. Інструменты для аўтаматызаванага Blue/Green разгортвання і маштабаванні кластара Kubernetes былі распрацаваны ў рамках праекту Cloud RTI, які ствараўся на аснове open-source.
У гэтым артыкуле, расшыфроўцы відэа, распавядаецца, як наладзіць Kubernetes разам з іншымі кампанентамі з адчыненым зыходным кодам для атрымання гатовага да вытворчасці асяроддзя, якое без прастояў у прадакшэне ўспрымае код з коміта змен git commit.
Такім чынам, пасля таго як вы атрымалі доступ да сваіх прыкладанняў з навакольнага свету, можна прыступаць да поўнай наладзе аўтаматызацыі, гэта значыць давесці яе да стадыі, на якой можна выканаць git commit і пераканацца ў тым, што гэты git commit сканчаецца ў прадакшэне. Натуральна, што пры рэалізацыі гэтых крокаў, пры ажыццяўленні разгортвання, мы не жадаем сутыкацца з прастоямі. Такім чынам, любая аўтаматызацыя ў Kubernetes пачынаецца з API.
Kubernetes не той інструмент, які можна прадуктыўна выкарыстоўваць "прама са скрынкі". Вядома, вы можаце так рабіць, выкарыстоўваць kubectl і гэтак далей, але ўсё ж API з'яўляецца самай цікавай і карыснай рэччу гэтай платформы. Выкарыстоўваючы API як набор функцый, вы можаце атрымаць доступ практычна да ўсяго, што хочаце зрабіць у Kubernetes. Сам па сабе kubectl таксама выкарыстоўвае REST API.
Гэта REST, так што вы можаце выкарыстоўваць для працы з гэтым API любыя мовы і інструменты, але ваша жыццё значна аблегчаць карыстацкія бібліятэкі. Мая каманда напісала 2 такія бібліятэкі: адну для Java/OSGi і адну для Go. Другая выкарыстоўваецца не часта, але ў любым выпадку ў вашым распараджэнні ёсць гэтыя карысныя рэчы. Яны ўяўляюць сабой часткова ліцэнзійны open-source праект. Існуе мноства такіх бібліятэк для розных моў, так што вы можаце выбраць найбольш прыдатныя.
Такім чынам, перш чым прыступіць да аўтаматызацыі разгортвання, неабходна пераканацца, што гэты працэс не будзе схільны ніякім прастоям. Напрыклад, наша каманда праводзіць прадакшн-разгортванне ў сярэдзіне дня, калі людзі максімальна выкарыстоўваюць прыкладанні, таму вельмі важна пазбягаць затрымак у гэтым працэсе. Для таго, каб пазбегнуць прастояў, выкарыстоўваюцца 2 спосабу: blue/green разгортванне або слізгальнае абнаўленне rolling update. У апошнім выпадку, калі ў вас працуе 5 рэплік прыкладання, яны паслядоўна абнаўляюцца адна за адной. Гэты спосаб выдатна працуе, але ён не падыходзіць, калі падчас разгортвання ў вас адначасова запушчаны розныя версіі прыкладання. У такім выпадку вы можаце абнавіць інтэрфейс карыстальніка ў той час, як бэкэнд будзе працаваць са старой версіяй, і праца прыкладання будзе спынена. Таму з пункту гледжання праграмавання праца ў такіх умовах даволі цяжкая.
Гэта адна з прычын, па якой мы аддаем перавагу выкарыстоўваць blue/green deployment для аўтаматызацыі разгортвання сваіх прыкладанняў. Пры такім спосабе вы павінны пераканацца, што ў пэўны момант часу актыўная толькі адна версія прыкладання.
Механізм blue/green deployment выглядае наступным чынам. Мы атрымліваем трафік для сваіх прыкладанняў праз ha-proxy, які накіроўвае яго запушчаным рэплікам прыкладання адной і той жа версіі.
Калі ажыццяўляецца новае разгортванне, мы выкарыстоўваем Deployer, якому даюцца новыя кампаненты, і ён ажыццяўляе дэплой новай версіі. Дэплой новай версіі прыкладання азначае, што "паднімаецца" новы набор рэплік, пасля чаго гэтыя рэплікі новай версіі запускаюцца ў асобным, новым подзе. Аднак ha-proxy нічога пра іх не ведае і пакуль што не накіроўвае ім ніякай працоўнай нагрузкі.
Таму ў першую чаргу неабходна выканаць праверку працаздольнасці новых версій health cheking, каб упэўніцца ў гатоўнасці рэплік абслугоўваць нагрузку.
Усе кампаненты разгортвання павінны падтрымліваць якую-небудзь форму health chek. Гэта можа быць зусім простая праверка HTTP выклікам, калі вы атрымліваеце код са статутам 200, або глыбейшая праверка, пры якой вы правяраеце сувязь рэплік з базай дадзеных і іншымі сэрвісамі, устойлівасць сувязяў дынамічнага асяроддзя, ці ўсё запускаецца і працуе правільнай выявай. Гэты працэс можа быць дастаткова складаным.
Пасля таго, як сістэма пераканацца ў працаздольнасці ўсіх абноўленых рэплік, Deployer абновіць канфігурацыю і перадасць правільны confd, які пераналадзіць ha-proxy.
Толькі пасля гэтага трафік будзе накіраваны ў пад з рэплікамі новай версіі, а стары пад знікне.
Гэты механізм не з`яўляецца асаблівасцю Kubernetes. Канцэпцыя Blue/green deployment існуе даволі працяглы час, і яна заўсёды выкарыстоўвала балансавальнік нагрузкі. Спачатку вы накіроўваеце ўвесь трафік да старой версіі прыкладання, а пасля абнаўлення цалкам пераводзіце яго на новую версію. Гэты прынцып выкарыстоўваецца не толькі ў Kubernetes.
Цяпер я прадстаўлю вам новы кампанент разгортвання - Deployer, які выконвае праверку працаздольнасці, рэканфігуруе проксі і гэтак далей. Гэта канцэпт, які не адносіцца да знешняга свету і існуе ўнутры Kubernetes. Я пакажу, як можна стварыць свой уласны канцэпт Deployer з дапамогай open-source інструментаў.
Такім чынам, першае, што робіць Deployer - гэта стварае кантролер рэплікацыі RC, выкарыстоўваючы API Kubernetes. Гэты API стварае поды і сэрвісы для далейшага разгортвання, гэта значыць стварае цалкам новы кластар для нашых прыкладанняў. Як толькі RC пераканаецца ў тым, што рэплікі стартавалі, ён правядзе праверку іх працаздольнасці Health check. Для гэтага ў Deployer выкарыстоўваецца каманда GET/health. Яна запускае адпаведныя кампаненты праверкі і правярае ўсе элементы, якія забяспечваюць працу кластара.
Пасля таго, як усе поды паведамілі аб сваім "здароўі", Deployer стварае новы элемент канфігурацыі - размеркаванае сховішча etcd, якое выкарыстоўваецца ўнутры Kubernetes, у тым ліку для захоўвання канфігурацыі балансавальніка нагрузкі. Мы запісваем дадзеныя ў etcd, і невялікая прылада confd адсочвае etcd на прадмет з'яўлення новых дадзеных.
Калі ён выявіў нейкія змены першапачатковай канфігурацыі, тое генеруе новы файл налад і перадае яго ha-proxy. У гэтым выпадку ha-proxy перазагружаецца без страты якія-небудзь злучэнняў і адрасуе нагрузку новым services, якія забяспечваюць працу новай версіі нашых прыкладанняў.
Як бачыце, не гледзячы на багацце кампанентаў, тут няма нічога складанага. Вам проста трэба надаць больш увагі API і etcd. Я хачу расказаць вам пра open-source дэплоера, якім мы самі карыстаемся - гэта Amdatu Kubernetes Deployer.
Гэта інструмент для аркестроўкі разгортванняў Kubernetes, які валодае такімі функцыямі:
- разгортванне Blue/Green deployment;
- настройка знешняга балансавальніка нагрузкі;
- кіраванне дэскрыптарамі разгортвання;
- кіраванне фактычным разгортваннем;
- праверка працаздольнасці Health checks падчас разгортвання;
- ўкараненне ў поды зменных асяроддзя.
Гэты Deployer створаны на вяршыні Kubernetes API і падае сабой REST API для кіравання дэскрыптарамі і разгортваннямі, а таксама Websocket API для струменевых логаў падчас разгортвання.
Ён змяшчае дадзеныя канфігурацыі балансавальніка нагрузкі ў etcd, таму вы можаце не карыстацца ha-proxy з падтрымкай «прама са скрынкі», а лёгка выкарыстоўваць свой уласны файл канфігурацыі балансавальніка. Amdatu Deployer напісаны на Go, як і сам Kubernetes, і ліцэнзаваны Apache.
Перад пачаткам ужывання гэтай версіі дэплоера я скарыстаўся наступным дэскрыптарам разгортвання, у якім паказаныя патрэбныя мне параметры.
Адзін з важных параметраў гэтага кода - уключэнне сцяга "useHealthCheck". Нам трэба ўказаць, што ў працэсе разгортвання неабходна выконваць праверку працаздольнасці. Гэты параметр можа быць адключаны, калі ў разгортванні выкарыстоўваюцца кантэйнеры іншых распрацоўшчыкаў, якія не трэба правяраць. У гэтым дэскрыптары таксама пазначана колькасць рэплік і URL фронтэнда, які патрэбен ha-proxy. У канцы паказаны сцяг спецыфікацыі пода «podspec», які звяртаецца да Kubernetes для атрымання інфармацыі па наладзе партоў, выяве і г.д. Гэта дастаткова просты дэскрыптар у фармаце JSON.
Яшчэ адна прылада, які з'яўляецца часткай open-source праекту Amdatu, гэта Deploymentctl. Ён мае карыстацкі інтэрфейс UI для канфігуравання разгортвання, захоўвае гісторыю разгортвання і змяшчае webhooks для зваротных выклікаў іншымі карыстальнікамі і распрацоўшчыкамі. Вы можаце не выкарыстоўваць UI, паколькі сам Amdatu Deployer з'яўляецца REST API, але гэты інтэрфейс можа нашмат палегчыць вам разгортванне без прыцягнення які-небудзь API. Deploymentctl напісаны на OSGi/Vertx з выкарыстаннем Angular 2.
Цяпер я прадэманструю вышэйсказанае на экране, выкарыстоўваючы загадзя зроблены запіс, так што вам не давядзецца чакаць. Мы будзем разгортваць простае дадатак на Go. Не хвалюйцеся, калі да гэтага не сутыкаліся з Go, гэта вельмі простае дадатак, так што вам усё павінна быць зразумела.
Тут мы ствараем HTTP-сервер, які адказвае толькі на /health, так што гэта дадатак толькі правярае працаздольнасць health check і нічога больш. Калі праверка праходзіць, задзейнічаецца паказаная ўнізе JSON-структура. Яна змяшчае версію прыкладання, якое будзе разгорнута дэплоерам, message, які вы бачыце ў верхняй частцы файла, і лагічны тып дадзеных boolean - працаздольна наша дадатак ці не.
З апошнім радком я крыху схітраваў, таму што змясціў уверсе файла фіксаванае значэнне boolean, якое ў далейшым дапаможа мне разгарнуць нават «нездаровае» прыкладанне. Пазней мы з гэтым разбярэмся.
Такім чынам, прыступім. Спачатку правяраем наяўнасць якія-небудзь запушчаных подаў з дапамогай каманды ~ kubectl get pods і па адсутнасці адказу URL фронтэнда пераконваемся, што ніякіх разгортванняў у дадзены момант не вырабляецца.
Далей на экране вы бачыце згаданы мною інтэрфейс Deploymentctl, у якім задаюцца параметры разгортвання: прастора імёнаў, імя прыкладання, версію разгортвання, колькасць рэплік, фронтэнд-URL, назоў кантэйнера, выява, ліміты рэсурсаў, нумар порта для праверкі health check і т.д . Ліміты рэсурсаў вельмі важныя, бо дазваляюць задзейнічаць максімальна магчымую колькасць «жалеза». Тутака ж можна прагледзець часопіс разгортвання Deployment log.
Калі зараз паўтарыць каманду ~kubectl get pods, відаць, што сістэма "замірае" на 20 секунд, падчас якіх адбываецца рэканфігурацыя ha-proxy. Пасля гэтага пад запускаецца, і нашу рэпліку можна ўбачыць у логу разгортвання.
Я выразаў з відэа 20-ці секунднае чаканне, і зараз вы бачыце на экране, што першая версія прыкладання разгорнута. Усё гэта было зроблена толькі пры дапамозе UI.
Цяпер давайце паспрабуем другую версію. Для гэтага я змяняю message прыкладання з Hello, Kubernetes! на "Hello, Deployer!", сістэма стварае гэты вобраз і змяшчае яго ў рэестр Docker, пасля чаго мы проста яшчэ раз націскаем на кнопку "Deploy" у акне Deploymentctl. Пры гэтым аўтаматычна запускаецца лог разгортвання сапраўды гэтак жа, як гэта адбывалася пры разгортванні першай версіі прыкладання.
Каманда ~ kubectl get pods паказвае, што ў дадзены момант запушчана 2 версіі прыкладання, аднак фронтэнд паказвае, што ў нас усё яшчэ працуе версія 1.
Балансавальнік нагрузкі чакае, пакуль будзе праведзена праверка health check, пасля чаго перанакіруе трафік на новую версію. Праз 20 з мы перамыкаемся на curl і бачым, што зараз у нас разгорнута 2 версія прыкладання, а першая выдаленая.
Гэта было разгортванне «здаровага» - healthy - прыкладанні. Давайце паглядзім, што адбудзецца, калі для новай версіі прыкладання я змяню значэнне параметру Healthy з true на false, гэта значыць паспрабую разгарнуць unhealthy дадатак, якое не прайшло праверку працаздольнасці. Гэта можа адбыцца, калі на стадыі распрацоўкі ў дадатку былі дапушчаны нейкія памылкі канфігурацыі, і яно ў такім выглядзе адправілася ў прадакшн.
Як бачыце, разгортванне праходзіць усе вышэйпаказаныя этапы, і ~ kubectl get pods паказвае, што запушчаны абодва пода. Але ў адрозненне ад папярэдняга разгортвання, лог паказвае стан timeout. Гэта значыць з-за таго, што праверка health check не прайшла, новая версія дадатку не можа быць разгорнута. У выніку вы бачыце, што сістэма вярнулася да выкарыстання старой версіі прыкладання, а новая версія была проста выдалена.
Добра ў гэтым тое, што нават калі ў вас ёсць вялікая колькасць адначасовых запытаў, якія паступаюць у дадатак, яны нават не заўважаць прастою падчас рэалізацыі працэдуры разгортвання. Калі пратэставаць гэта дадатак з дапамогай фрэймворка Gatling, якое пасылае яму максімальна магчымую колькасць запытаў, то не адзін з гэтых запытаў не будзе адкінуты. Гэта азначае, што нашы карыстачы нават не заўважаць абнаўленні версій у рэжыме рэальнага часу. Калі яно скончыцца няўдачай, праца працягнецца на старой версіі, калі будзе ўдалай - карыстачы пяройдуць на новую версію.
Існуе толькі адна рэч, якая можа прывесці да няўдачы - калі праверка health check прайшла паспяхова, а прыкладанне дало збой, як толькі на яго паступіла працоўная нагрузка, гэта значыць калапс наступіць толькі пасля завяршэння разгортвання. У гэтым выпадку вам давядзецца ўручную адкаціцца на старую версію. Такім чынам мы разгледзелі, як выкарыстоўваць Kubernetes з прызначанымі для яго open-source інструментамі. Працэдура разгортвання будзе праходзіць нашмат прасцей, калі вы ўбудуеце гэтыя прылады ў канвееры стварэння/разгортванні Build/Deploy pipelines. Пры гэтым для запуску разгортвання вы можаце выкарыстоўваць як карыстацкі інтэрфейс, так і цалкам аўтаматызаваць гэты працэс, ужыўшы, да прыкладу, commit to master.
Наш сервер зборкі Build Server створыць Docker-выява, уставіць яго ў Docker Hub або любы іншы выкарыстоўваны вамі рэестр. Хаб Docker падтрымлівае webhook, таму мы можам запусціць выдаленае разгортванне праз Deployer паказаным вышэй шляхам. Такім чынам можна цалкам аўтаматызаваць разгортванне прыкладання ў патэнцыйны прадакшн.
Пяройдзем да разгляду наступнай тэмы - маштабаванні кластара Kubernetes. Заўважу, што kubectl з'яўляецца камандай маштабавання. З яшчэ дапамогай можна лёгка павялічыць колькасць рэплік у наяўным у нас кластары. Аднак на практыцы мы звычайна жадаем павялічваць колькасць не падоў, а нодаў.
Пры гэтым у працоўны час вам можа спатрэбіцца павелічэнне, а ў начны час, для скарачэння кошту паслуг Amazon - памяншэнне колькасці запушчаных асобнікаў прыкладання. Гэта не азначае, што будзе дастаткова маштабаваць толькі колькасць подаў, таму што нават калі адзін з нодаў будзе нічым не заняты, вам усё роўна давядзецца плаціць за яго Amazon. Гэта значыць нараўне з маштабаваннем подаў вам спатрэбіцца маштабаваць і лік выкарыстоўваных машын.
Гэта можа выклікаць складанасці, таму што незалежна ад таго, ці выкарыстоўваем мы Amazon або іншы хмарны сэрвіс, Kubernetes нічога не ведае аб колькасці выкарыстоўваных машын. У ім адсутнічае прылада, які дазваляе маштабаваць сістэму на ўзроўні нодаў.
Так што нам давядзецца паклапаціцца і аб нодах, і аб падах. Мы можам лёгка маштабаваць запуск новых нодаў пры дапамозе AWS API і машын групы маштабавання Scaling group для наладкі колькасці працоўных вузлоў Kubernetes. Таксама можна выкарыстоўваць cloud-init ці падобны яму скрыпт для рэгістрацыі нодаў у кластары Kubernetes.
Новая машына стартуе ў Scaling group, ініцыюе сябе як нод, прапісваецца ў рэестры майстра і пачынае працу. Пасля гэтага можна павялічыць колькасць рэплік для выкарыстання на якія ўтварыліся нодах. Памяншэнне маштабу патрабуе большы намаганняў, бо неабходна пераканацца, што падобны крок не прывядзе да знішчэння ўжо працуючых прыкладанняў пасля адключэння непатрэбных машын. Для прадухілення такога сцэнара трэба прывесці ноды да статуту "unschedulable". Гэта азначае, што планавальнік па змаўчанні пры планаванні падоў DaemonSet будзе ігнараваць гэтыя ноды. Планавальнік не стане нічога выдаляць з гэтых сервераў, але і будзе запускаць там ніякіх новых кантэйнераў. Наступных крок складаецца ў выцясненні вузла drain node, гэта значыць у пераносе з яго якія працуюць падоў на іншую машыну, ці іншыя ноды, якія валодаюць дастатковай для гэтага ёмістасцю. Пераканаўшыся, што на гэтых вузлах больш няма ніякіх кантэйнераў, іх можна выдаліць з Kubernetes. Пасля гэтага для Kubernetes яны проста перастануць існаваць. Далей трэба выкарыстоўваць AWS API для адключэння непатрэбных вузлоў, ці машын.
Вы можаце выкарыстоўваць Amdatu Scalerd - яшчэ адзін open-source інструмент для маштабавання, аналагічны AWS API. Ён дае CLI для дадання або выдаленні нодаў у кластары. Яго цікавай асаблівасцю з'яўляецца магчымасць наладзіць планавальнік пры дапамозе наступнага json-файла.
Намаляваны код напалову памяншае ёмістасць кластара ў начны перыяд часу. У ім наладжана як колькасць наяўных рэплік, так і жаданая ёмістасць кластара Amazon. Выкарыстанне гэтага планавальніка аўтаматычна паменшыць колькасць вузлоў уначы і павялічыць іх раніцай, дазволіўшы зэканоміць кошт выкарыстання нодаў такога хмарнага сэрвісу, як Amazon. Гэтая функцыя не ўбудаваная ў Kubernetes, але выкарыстанне Scalerd дазволіць вам як заўгодна маштабаваць гэтую платформу.
Хачу звярнуць вашу ўвагу на тое, што многія людзі кажуць мне: "Усё гэта добра, але як наконт маёй базы дадзеных, якая звычайна знаходзіцца ў статычным стане?" Якім чынам можна запусціць нешта падобнае ў такім дынамічным асяроддзі, як Kubernetes? На мой погляд, вы не павінны гэтага рабіць, не павінны спрабаваць арганізаваць працу сховішчы дадзеных у Kubernetes. Тэхнічна гэта магчыма, і ў інтэрнэце ёсць кіраўніцтвы па гэтым пытанні, аднак гэта сур'ёзна ўскладніць ваша жыццё.
Так, у Kubernetes існуе паняцце пастаянных сховішчаў, і вы можаце паспрабаваць запускаць такія сховішчы дадзеных, як Mongo або MySQL, але гэта дастаткова працаёмкая задача. Гэта злучана з тым, што сховішчы дадзеных не цалкам падтрымліваюць узаемадзеянне з дынамічным асяроддзем. Большасць баз дадзеных патрабуюць значнай наладкі, у тым ліку ручной налады кластара, не любяць аўтамаштабаванне і іншыя падобныя штукі.
Таму не варта ўскладняць сабе жыццё, спрабуючы запусціць сховішча даных у Kubernetes. Арганізуйце іх працу традыцыйным спосабам з выкарыстаннем звыклых сэрвісаў і проста падайце Kubernetes магчымасць імі карыстацца.
У завяршэнне тэмы хачу вас пазнаёміць з платформай Cloud RTI на базе Kubernetes, над якой працуе мая каманда. Яна забяспечвае цэнтралізаванае вядзенне логаў, маніторынг прыкладанняў і кластараў і валодае мноствам іншых карысных функцый, якія вам спатрэбяцца. У ёй выкарыстоўваюцца розныя open-source прылады, такія як Grafana для адлюстравання маніторынгу.
Прагучала пытанне, навошта выкарыстоўваць з Kubernetes балансавальнік нагрузкі ha-proxy. Добрае пытанне, таму што ў цяперашні час існуе 2 ўзроўню балансавання нагрузкі. Сэрвісы Kubernetes да гэтага часу знаходзяцца на віртуальных IP-адрасах. Вы не можаце выкарыстоўваць іх для партоў вонкавых хост-машын, таму што калі Amazon перагрузіць свой хмарны хост, адрас памяняецца. Вось чаму мы размяшчаем перад сэрвісамі ha-proxy – каб стварыць больш статычную структуру для бесперабойнага ўзаемадзеяння трафіку з Kubernetes.
Яшчэ адно добрае пытанне - як можна паклапаціцца аб змене схемы базы дадзеных пры ажыццяўленні blue/green deployment? Справа ў тым, што незалежна ад выкарыстання Kubernetes, змена схемы базы даных складаная задача. Вам трэба забяспечыць сумяшчальнасць старой і новай схемы, пасля чаго вы зможаце абнавіць базу дадзеных і затым абнавіць самі прыкладанні. Вы можаце выканаць «гарачую замену» hot swapping базы дадзеных, а затым абнавіць прыкладанні. Я ведаю людзей, якія загружалі зусім новы кластар базы дадзеных з новай схемай, гэта варыянт, калі ў вас ёсць schemeless база дадзеных тыпу Mongo, але ў любым выпадку гэта не простая задача. Калі больш пытанняў няма, дзякую за ўвагу!
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com