Docker Swarm-ը, Kubernetes-ը և Mesos-ը կոնտեյներային օրկեստրացիայի ամենատարածված շրջանակներն են։ Իր ելույթում Արուն Գուպտան համեմատում է Docker-ի, Swarm-ի և Kubernetes-ի հետևյալ ասպեկտները.
- Տեղական զարգացում։
- Տեղակայման գործառույթներ։
- Բազմակոնտեյներային կիրառություններ։
- Ծառայության հայտնաբերում։
- Ծառայության մասշտաբավորումը։
- Մեկ անգամ կատարվող առաջադրանքներ։
- Ինտեգրացիա Maven-ի հետ։
- «Շարժվող» թարմացում։
- Couchbase տվյալների բազայի կլաստերի ստեղծում։
Արդյունքում, դուք կստանաք հստակ պատկերացում այն մասին, թե ինչ է առաջարկում յուրաքանչյուր գործիքային գործիք և կսովորեք այդ հարթակները արդյունավետորեն օգտագործելու տեխնիկան։
Արուն Գուպտան Amazon Web Services-ի բաց կոդով արտադրանքի գլխավոր տեխնոլոգն է, ով ավելի քան 10 տարի մշակել է մշակողների համայնքներ Sun, Oracle, Red Hat և Couchbase ընկերություններում: Նա մեծ փորձ ունի մարքեթինգային արշավների և ծրագրային ռազմավարության մշակման և իրականացման մեջ ներգրավված միջֆունկցիոնալ թիմերի ղեկավարման գործում: Նա ղեկավարել է Sun-ի ինժեներական թիմերը, Java EE թիմի հիմնադիրներից մեկն է և Devoxx4Kids-ի ԱՄՆ մասնաճյուղի ստեղծողը: Արուն Գուպտան ավելի քան 2 գրառումների հեղինակ է ՏՏ բլոգներում և ներկայացումներ է ունեցել ավելի քան 40 երկրներում:
55-րդ տողը պարունակում է COUCHBASE_URI-ը, որը մատնանշում է այս տվյալների բազայի ծառայությունը, որը նույնպես ստեղծվել է Kubernetes կարգավորման ֆայլի միջոցով: Եթե նայեք 2-րդ տողին, կարող եք տեսնել kind: Service-ը, որը այն ծառայությունն է, որը ես ստեղծում եմ՝ couchbase-service անունով, և դա նույն անունն է, որը ես նշել եմ 4-րդ տողում: Դրանից ներքև կան մի քանի պորտեր:
Հիմնական տողերը 6-ը և 7-ն են։ Service-ում ես ասում եմ. «Սրանք այն պիտակներն են, որոնք ես փնտրում եմ», և այս պիտակները ոչ այլ ինչ են, քան փոփոխական զույգերի անուններ, իսկ 7-րդ տողը մատնանշում է իմ couchbase-rs-pod հավելվածը։ Հաջորդը թվարկված են այն պորտերը, որոնք մուտք են տալիս այս պիտակներին։
19-րդ տողում ես ստեղծում եմ ReplicaSet նոր տեսակ, 31-րդ տողը պարունակում է պատկերի անունը, իսկ 24-27 տողերը մատնանշում են իմ pod-ին կապված մետատվյալները: Սա այն է, ինչ ծառայությունը փնտրում է և որի հետ պետք է միացված լինի: Ֆայլի վերջում 55-56 և 4 տողերի միջև կա որոշակի կապ, որն ասում է. «օգտագործեք այս ծառայությունը»:
Այսպիսով, ես սկսում եմ իմ ծառայությունը կրկնօրինակների հավաքածուով, և քանի որ յուրաքանչյուր կրկնօրինակների հավաքածու ունի իր սեփական պորտը՝ համապատասխան պիտակով, այն ներառված է ծառայության մեջ: Մշակողի տեսանկյունից, դուք պարզապես կանչում եք ծառայությունը, որն այնուհետև օգտագործում է ձեր ուզած կրկնօրինակների հավաքածուն:
Այսպիսով, ես ունեմ WildFly պոդ, որը կապվում է տվյալների բազայի հետ Couchbase ծառայության միջոցով: Ես կարող եմ ունենալ մի քանի WildFly պոդերով ինտերֆեյս, որոնք նույնպես կապվում են couchbase backend-ի հետ couchbase ծառայության միջոցով:
Հետագայում մենք կանդրադառնանք, թե ինչպես է կլաստերից դուրս գտնվող ծառայությունը իր IP հասցեի միջոցով կապվում կլաստերի ներսում գտնվող և ներքին IP հասցե ունեցող տարրերի հետ։
Այսպիսով, վիճակազուրկ կոնտեյներները հիանալի են, բայց որքանո՞վ է լավ օգտագործել վիճակային կոնտեյներներ: Եկեք նայենք վիճակային կամ մշտական կոնտեյներների համակարգի կարգավորմանը: Docker-ում տվյալների պահպանման դասավորության 4 տարբեր մոտեցում կա, որոնց պետք է ուշադրություն դարձնել: Առաջինը Implicit Per-Container-ն է, ինչը նշանակում է, որ երբ դուք օգտագործում եք վիճակային կոնտեյներներ, ինչպիսիք են couchbase-ը, MySQL-ը կամ MyDB-ն, դրանք բոլորը աշխատում են լռելյայն Sandbox-ով: Այսինքն՝ տվյալների բազայում պահված ամեն ինչ պահվում է հենց կոնտեյների մեջ: Եթե կոնտեյները անհետանում է, տվյալները նույնպես անհետանում են դրա հետ միասին:
Երկրորդը Explicit Per-Container-ն է, երբ դուք ստեղծում եք որոշակի պահեստ docker volume create հրամանով և պահպանում տվյալները դրանում: Երրորդ մոտեցումը՝ Per-Host-ը, կապված է պահեստավորման մապինգի հետ, երբ կոնտեյներում պահված ամեն ինչ միաժամանակ կրկնօրինակվում է հոսթի վրա: Եթե կոնտեյները խափանվի, տվյալները կմնան հոսթի վրա: Վերջինը մի քանի հոսթերի օգտագործումն է՝ Multi-Host, որը խորհուրդ է տրվում տարբեր լուծումների արտադրության փուլում: Ենթադրենք, որ ձեր կոնտեյներները՝ ձեր ծրագրերով, աշխատում են հոսթի վրա, բայց դուք ցանկանում եք ձեր տվյալները պահել ինտերնետում որևէ տեղ, և դրա համար օգտագործվում է բաշխված համակարգերի ավտոմատ մապինգ:
Այս մեթոդներից յուրաքանչյուրը օգտագործում է որոշակի պահեստավորման տեղանք: Անուղղակի և բացահայտ Per-Container-ները տվյալները պահում են հոսթի վրա /var/lib/docker/volumes-ում: Per-Host մեթոդով պահեստավորումը տեղադրվում է կոնտեյների ներսում, իսկ կոնտեյներն ինքնին տեղադրված է հոսթի վրա: Բազմահոսթերի համար կարող են օգտագործվել Ceph, ClusterFS, NFS և այլն լուծումներ:
Եթե մշտական կոնտեյները ձախողվում է, առաջին երկու դեպքերում պահեստի գրացուցակը դառնում է անհասանելի, իսկ վերջին երկու դեպքերում մուտքը պահպանվում է։ Սակայն, առաջին դեպքում, դուք կարող եք մուտք գործել պահեստ վիրտուալ մեքենայի վրա աշխատող Docker հոսթի միջոցով։ Երկրորդ դեպքում տվյալները նույնպես չեն կորչի, քանի որ դուք ստեղծել եք Explicit պահեստ։
Եթե հոսթը խափանվում է, առաջին երեք դեպքերում պահեստի գրացուցակը անհասանելի է, վերջին դեպքում պահեստի հետ կապը չի ընդհատվում: Վերջապես, առաջին դեպքում պահեստի համար համատեղ օգտագործման գործառույթը լիովին բացառվում է, իսկ մյուսներում հնարավոր է: Երկրորդ դեպքում դուք կարող եք համատեղ օգտագործել պահեստը՝ կախված նրանից, թե արդյոք ձեր տվյալների բազան աջակցում է բաշխված պահեստ, թե ոչ: Per-Host-ի դեպքում տվյալների բաշխումը հնարավոր է միայն այս հոսթի վրա, իսկ բազմահոսթի դեպքում այն ապահովվում է կլաստերի ընդլայնմամբ:
Սա պետք է հիշել վիճակային կոնտեյներներ կառուցելիս: Docker-ի մեկ այլ օգտակար գործիք է Volume հավելվածը, որը «մարտկոցներ կան, բայց փոխարինելի» հավելված է: Երբ դուք գործարկում եք Docker կոնտեյներ, այն ասում է. «Եթե գործարկեք կոնտեյներ տվյալների բազայով, կարող եք ձեր տվյալները պահել այս կոնտեյներում»: Սա լռելյայն վարքագիծն է, բայց դուք կարող եք փոխել այն: Այս հավելվածը թույլ է տալիս օգտագործել ցանցային սկավառակ կամ նմանատիպ մի բան կոնտեյներային տվյալների բազայի փոխարեն: Այն ներառում է հոսթի վրա հիմնված պահեստավորման լռելյայն դրայվեր և թույլ է տալիս կոնտեյներների ինտեգրումը արտաքին պահեստավորման համակարգերի հետ, ինչպիսիք են Amazon EBS-ը, Azure Storage-ը և GCE Persistent Disks-ը:
Հաջորդ սլայդը ցույց է տալիս Docker Volume պլագինի ճարտարապետությունը։
Կապույտ գույնը Docker հաճախորդն է, որը միացված է կապույտ Docker հոսթին, որն ունի տեղական պահեստավորման շարժիչ, որը ձեզ տրամադրում է կոնտեյներներ՝ ձեր տվյալները պահելու համար: Կանաչ գույնը Plugin Client-ն է և Plugin Daemon-ը, որոնք նույնպես միացված են հոսթին: Դրանք հնարավորություն են տալիս պահպանել տվյալները ցանցային պահեստում, որը ձեզ անհրաժեշտ է Storage Backend տեսակի:
Docker Volume պլագինը կարող է օգտագործվել Portworx պահեստավորման հետ։ PX-Dev մոդուլը իրականում մի կոնտեյներ է, որը դուք գործարկում եք, որը միանում է Docker հոսթին և թույլ է տալիս հեշտությամբ պահպանել տվյալները Amazon EBS-ում։
Portworx հաճախորդը թույլ է տալիս վերահսկել ձեր հոսթին միացված տարբեր պահեստային համակարգերով կոնտեյներների վիճակը: Եթե այցելեք իմ բլոգը, կարող եք կարդալ, թե ինչպես առավել արդյունավետ օգտագործել Portworx-ը Docker-ի հետ:
Kubernetes-ում պահեստավորման հայեցակարգը նման է Docker-ին և ներկայացված է պոդում ձեր կոնտեյների համար հասանելի դիրեկտորիաներով: Դրանք անկախ են ցանկացած կոնտեյների կյանքի տևողությունից: Հասանելի պահեստավորման ամենատարածված տեսակներն են՝ hostPath, nfs, awsElasticBlockStore և gsePersistentDisk: Եկեք նայենք, թե ինչպես են այս պահեստավորումները աշխատում Kubernetes-ում: Սովորաբար դրանց միացման գործընթացը բաղկացած է 3 քայլից:
Առաջին քայլն այն է, որ ցանցային կողմից ինչ-որ մեկը, սովորաբար ադմինիստրատորը, ձեզ տրամադրի մշտական պահեստ։ Դրա համար կա PersistentVolume անունով կոնֆիգուրացիայի ֆայլ։ Այնուհետև ծրագրի մշակողը գրում է PersistentVolumeClaim անունով կոնֆիգուրացիայի ֆայլ կամ PVC պահեստավորման հարցում, որն ասում է. «Ես ունեմ 50 ԳԲ բաշխված պահեստ, բայց որպեսզի այլ մարդիկ կարողանան օգտագործել այդ տարողությունը, ես այս PVC-ում ասում եմ, որ ինձ այս պահին անհրաժեշտ է ընդամենը 10 ԳԲ»։ Վերջապես, երրորդ քայլն այն է, որ ձեր հարցումը միացվում է որպես պահեստ, և այն ծրագիրը, որն ունի pod-ը կամ replica-ն կամ ինչ-որ այլ բան, սկսում է օգտագործել այն։ Կարևոր է հիշել, որ այս գործընթացը բաղկացած է վերը նշված 3 քայլերից, և այն թույլ է տալիս մասշտաբավորում։
Հաջորդ սլայդը ցույց է տալիս AWS ճարտարապետության Kubernetes Persistence Container-ը։
Շագանակագույն ուղղանկյան ներսում, որը ներկայացնում է Kubernetes կլաստերը, կա մեկ գլխավոր հանգույց և երկու աշխատող հանգույց, որոնք նշված են դեղին գույնով: Աշխատող հանգույցներից մեկը պարունակում է նարնջագույն պոդ, պահեստ, կրկնօրինակի կառավարիչ և կանաչ Docker Couchbase կոնտեյներ: Կլաստերի ներսում, հանգույցների վերևում, մանուշակագույն ուղղանկյունը ներկայացնում է արտաքին հասանելի ծառայություն: Այս ճարտարապետությունը խորհուրդ է տրվում տվյալները սարքի վրա պահելու համար: Անհրաժեշտության դեպքում ես կարող եմ իմ տվյալները պահել EBS-ում կլաստերից դուրս, ինչպես ցույց է տրված հաջորդ սլայդում: Սա մասշտաբավորման տիպիկ մոդել է, բայց այն օգտագործելիս պետք է հաշվի առնել ֆինանսական կողմը. տվյալները ցանցի որևէ տեղ պահելը կարող է ավելի թանկ լինել, քան հոսթի վրա: Սա կոնտեյներացման լուծումներ ընտրելիս ծանրակշիռ փաստարկներից մեկն է:
Ինչպես Docker-ի դեպքում, Portworx-ի հետ կարող եք օգտագործել Kubernetes-ի մշտական կոնտեյներներ։
Սա այն է, ինչն Kubernetes 1.6-ի ներկայիս տերմինաբանությամբ կոչվում է «StatefulSet»՝ Pod-ի անջատման իրադարձությունները և Graceful Shutdown-ները կարգավորող Stateful հավելվածների հետ աշխատելու միջոց: Մեր դեպքում այդ հավելվածները տվյալների բազաներ են: Դուք կարող եք կարդալ Kubernetes-ում Portworx-ի միջոցով StatefulSet ստեղծելու մասին իմ բլոգի գրառման մեջ:
Եկեք խոսենք մշակման կողմի մասին։ Ինչպես ասացի, Docker-ը ունի 2 տարբերակ՝ CE և EE, առաջին դեպքում խոսքը Community Edition կայուն տարբերակի մասին է, որը թարմացվում է յուրաքանչյուր 3 ամիսը մեկ, ի տարբերություն EE ամսական թարմացվող տարբերակի։ Դուք կարող եք ներբեռնել Docker-ը Mac-ի, Linux-ի կամ Windows-ի համար։ Տեղադրվելուց հետո Docker-ը ավտոմատ կերպով կթարմացվի, և դրա հետ աշխատելը շատ հեշտ է։
Kubernetes-ում ես նախընտրում եմ Minikube տարբերակը. դա լավ միջոց է այս հարթակում աշխատանքը սկսելու համար՝ մեկ հանգույցի վրա կլաստեր ստեղծելով: Մի քանի հանգույցներից բաղկացած կլաստերներ ստեղծելու համար կան ավելի շատ տարբերակներ՝ kops, kube-aws (CoreOS+AWS), kube-up (հնացած): Եթե դուք պատրաստվում եք օգտագործել Kubernetes-ը AWS-ի վրա, խորհուրդ եմ տալիս միանալ AWS SIG խմբին, որը ամեն ուրբաթ առցանց հանդիպում է և հրապարակում է տարբեր հետաքրքիր նյութեր Kubernetes AWS-ի հետ աշխատելու վերաբերյալ:
Եկեք դիտարկենք, թե ինչպես է կատարվում շարունակական թարմացումը այս հարթակներում: Եթե կա մի քանի հանգույցներից բաղկացած կլաստեր, ապա այն օգտագործում է պատկերի որոշակի տարբերակ, օրինակ՝ WildFly:1: Շրջանառական թարմացումը նշանակում է, որ պատկերի տարբերակը հաջորդաբար փոխարինվում է նորով՝ յուրաքանչյուր հանգույցի վրա, մեկը մյուսի հետևից:
Դրա համար ես օգտագործում եմ docker service update հրամանը (service name), որտեղ նշում եմ WildFly:2 պատկերի նոր տարբերակը և update-parallelism 2 թարմացման մեթոդը: 2 թիվը նշանակում է, որ համակարգը միաժամանակ կթարմացնի 2 ծրագրի պատկեր, այնուհետև կլինի 10 վայրկյան տևողությամբ թարմացման ուշացում՝ 10 վայրկյան, որից հետո կթարմացվեն ևս 2 հանգույցների վրա հաջորդ 2 պատկերները և այլն: Այս պարզ, գլանաձև թարմացման մեխանիզմը ձեզ տրամադրվում է որպես Docker-ի մաս:
Kubernetes-ում շարունակական թարմացումները գործում են հետևյալ կերպ։ Կրկնօրինակման կառավարիչը rc ստեղծում է մեկ տարբերակի կրկնօրինակների հավաքածու, և այս webapp-rc-ի յուրաքանչյուր պոդին տրամադրվում է etcd-ում գտնվող պիտակով։ Երբ ինձ պոդ է պետք, ես օգտագործում եմ Application Service-ը՝ etcd խանութի հետ կապվելու համար, որը ինձ տրամադրում է այս պոդը՝ օգտագործելով նշված պիտակը։
Այս դեպքում, մենք ունենք 3 պոդ Replication controller-ում, որոնք աշխատում են WildFly հավելվածի 1-ին տարբերակով: Թարմացման ժամանակ ֆոնային ռեժիմում ստեղծվում է մեկ այլ կրկնօրինակման կառավարիչ՝ նույն անունով և ինդեքսով՝ — — xxxxx վերջում, որտեղ x-ը պատահական թվեր են, և նույն պիտակներով: Այժմ Application Service-ը ունի երեք պոդ՝ հին տարբերակի հավելվածով և երեք պոդ՝ նոր տարբերակով նոր Replication controller-ում: Դրանից հետո հին պոդերը ջնջվում են, նոր պոդերով կրկնօրինակման կառավարիչը վերանվանվում և գործարկվում է:
Անցնենք մոնիթորինգին: Docker-ը ունի մոնիթորինգի համար ներկառուցված բազմաթիվ հրամաններ: Օրինակ, docker կոնտեյներների վիճակագրության հրամանի տողի ինտերֆեյսը թույլ է տալիս ամեն վայրկյան կոնսոլում տպել կոնտեյներների վիճակի մասին տվյալներ՝ CPU-ի օգտագործումը, սկավառակի օգտագործումը, ցանցի ծանրաբեռնվածությունը: Docker Remote API գործիքը տրամադրում է տվյալներ այն մասին, թե ինչպես է հաճախորդը շփվում սերվերի հետ: Այն օգտագործում է պարզ հրամաններ, բայց հիմնված է Docker REST API-ի վրա: Այս դեպքում REST, Flash, Remote բառերը նույն բանն են նշանակում: Երբ դուք շփվում եք հոսթի հետ, դա REST API-ն է: Docker Remote API-ն թույլ է տալիս ստանալ ավելի շատ տեղեկություններ աշխատող կոնտեյներների մասին: Իմ բլոգի գրառումը մանրամասներ է տրամադրում այս մոնիթորինգի Windows Server-ի հետ օգտագործման վերաբերյալ:
Բազմահոսթային կլաստեր գործարկելիս Docker համակարգի իրադարձությունների մոնիթորինգը թույլ է տալիս ստանալ տվյալներ որոշակի հոսթի վրա հոսթի կամ կոնտեյների խափանման, մասշտաբային ծառայությունների և այլնի մասին: Սկսած Docker 1.20-ից, այն ներառում է Prometheus, որը վերջնակետեր է ներկառուցում առկա հավելվածների մեջ: Սա թույլ է տալիս ստանալ չափանիշներ HTTP-ի միջոցով և ցուցադրել դրանք վահանակների վրա:
Մեկ այլ մոնիթորինգի գործառույթ է cAdvisor-ը (կոնտեյներների խորհրդատուի կրճատ տարբերակը): Այն վերլուծում և տրամադրում է աշխատող կոնտեյներներից ռեսուրսների օգտագործման և կատարողականության տվյալներ՝ անմիջապես տրամադրելով Prometheus չափանիշները: Այս գործիքի առանձնահատկությունն այն է, որ այն տրամադրում է միայն վերջին 60 վայրկյանների տվյալները: Այսպիսով, դուք պետք է հնարավորություն տաք հավաքելու այս տվյալները և դրանք տվյալների բազայում տեղադրելու՝ երկարատև գործընթացը վերահսկելու համար: Այն կարող է նաև օգտագործվել գրաֆիկական տեսքով չափորոշիչները վահանակի վրա ցուցադրելու համար՝ օգտագործելով Grafana կամ Kibana: Իմ բլոգում մանրամասն նկարագրված է, թե ինչպես օգտագործել cAdvisor-ը՝ Kibana վահանակի միջոցով կոնտեյներները վերահսկելու համար:
Հաջորդ սլայդը ցույց է տալիս, թե ինչ տեսք ունի Prometheus վերջնակետի արդյունքը և ցուցադրման համար հասանելի չափանիշները։
Ներքևի ձախ անկյունում դուք տեսնում եք HTTP հարցումների, պատասխանների և այլնի չափանիշները, իսկ աջ կողմում՝ դրանց գրաֆիկական պատկերը։
Kubernetes-ը նաև ունի ներկառուցված մոնիթորինգի գործիքներ: Այս սլայդը ցույց է տալիս տիպիկ կլաստեր, որը պարունակում է մեկ գլխավոր և երեք աշխատանքային հանգույց:
Յուրաքանչյուր աշխատողի հանգույց ունի ավտոմատ կերպով գործարկվող cAdvisor: Բացի այդ, կա Heapster-ը՝ կատարողականի մոնիթորինգի և չափանիշների հավաքագրման համակարգ, որը համատեղելի է Kubernetes 1.0.6 և ավելի բարձր տարբերակների հետ: Heapster-ը թույլ է տալիս հավաքել ոչ միայն աշխատանքային բեռների, պոդերի և կոնտեյներների կատարողականի չափանիշները, այլև ամբողջ կլաստերի կողմից ստեղծված իրադարձությունները և այլ ազդանշաններ: Տվյալներ հավաքելու համար այն կապվում է յուրաքանչյուր պոդի Kubelet-ի հետ, ավտոմատ կերպով պահպանում է տեղեկատվությունը InfluxDB տվյալների բազայում և ցուցադրում այն որպես չափանիշներ Grafana վահանակում: Այնուամենայնիվ, հիշեք, որ եթե դուք օգտագործում եք miniKube, այս գործառույթը լռելյայնորեն հասանելի չէ, ուստի դուք ստիպված կլինեք օգտագործել հավելումներ մոնիթորինգի համար: Այսպիսով, ամեն ինչ կախված է նրանից, թե որտեղ եք գործարկում կոնտեյներները, և որ մոնիթորինգի գործիքներն են լռելյայնորեն հասանելի, և որոնք պետք է տեղադրվեն որպես առանձին հավելումներ:
Հաջորդ սլայդում ցուցադրված են Grafana վահանակները, որոնք ցույց են տալիս իմ կոնտեյներների առողջությունը: Այստեղ բավականին շատ հետաքրքիր տվյալներ կան: Իհարկե, կան բազմաթիվ առևտրային գործիքներ Docker-ի և Kubernetes-ի գործընթացների մոնիթորինգի համար, ինչպիսիք են SysDig-ը, DataDog-ը, NewRelic-ը: Դրանցից մի քանիսն ունեն 30-օրյա անվճար փորձաշրջան, այնպես որ կարող եք փորձարկել դրանք և տեսնել, թե որն է ձեզ համար ամենաարդյունավետը: Անձամբ ես նախընտրում եմ օգտագործել SysDig-ը և NewRelic-ը, որոնք լավ ինտեգրվում են Kubernetes-ի հետ: Կան գործիքներ, որոնք հավասարապես լավ ինտեգրվում են և՛ Docker-ի, և՛ Kubernetes-ի հետ:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com
