Kubernetes ialah alat yang hebat untuk menjalankan bekas Docker dalam persekitaran pengeluaran berkelompok. Walau bagaimanapun, terdapat masalah yang tidak dapat diselesaikan oleh Kubernetes. Untuk penggunaan pengeluaran yang kerap, kami memerlukan penggunaan Biru/Hijau automatik sepenuhnya untuk mengelakkan masa henti dalam proses, yang juga perlu mengendalikan permintaan HTTP luaran dan melaksanakan pelepasan SSL. Ini memerlukan penyepaduan dengan pengimbang beban seperti ha-proxy. Cabaran lain ialah penskalaan separa automatik bagi gugusan Kubernetes itu sendiri apabila berjalan dalam persekitaran awan, contohnya mengecilkan separa gugusan pada waktu malam.
Walaupun Kubernetes tidak mempunyai ciri ini di luar kotak, ia menyediakan API yang boleh anda gunakan untuk menyelesaikan masalah yang serupa. Alat untuk penempatan automatik Biru/Hijau dan penskalaan kluster Kubernetes telah dibangunkan sebagai sebahagian daripada projek Cloud RTI, yang dicipta berdasarkan sumber terbuka.
Artikel ini, transkrip video, menunjukkan kepada anda cara menyediakan Kubernetes bersama-sama dengan komponen sumber terbuka lain untuk mencipta persekitaran sedia pengeluaran yang menerima kod daripada komit git tanpa masa henti dalam pengeluaran.
Jadi, sebaik sahaja anda mempunyai akses kepada aplikasi anda dari dunia luar, anda boleh mula menyediakan sepenuhnya automasi, iaitu, membawanya ke peringkat di mana anda boleh melakukan git commit dan pastikan git commit ini berakhir dalam pengeluaran. Sememangnya, apabila melaksanakan langkah-langkah ini, apabila melaksanakan penggunaan, kami tidak mahu menghadapi masa henti. Jadi, sebarang automasi dalam Kubernetes bermula dengan API.
Kubernetes bukanlah alat yang boleh digunakan secara produktif di luar kotak. Sudah tentu, anda boleh melakukannya, menggunakan kubectl dan sebagainya, tetapi tetap API adalah perkara yang paling menarik dan berguna tentang platform ini. Dengan menggunakan API sebagai satu set fungsi, anda boleh mengakses hampir apa sahaja yang anda mahu lakukan dalam Kubernetes. kubectl sendiri juga menggunakan API REST.
Ini ialah REST, jadi anda boleh menggunakan mana-mana bahasa atau alat untuk bekerja dengan API ini, tetapi kehidupan anda akan menjadi lebih mudah oleh perpustakaan tersuai. Pasukan saya menulis 2 perpustakaan sedemikian: satu untuk Java/OSGi dan satu untuk Go. Yang kedua tidak digunakan dengan kerap, tetapi dalam apa jua keadaan anda mempunyai perkara-perkara berguna ini di pelupusan anda. Mereka adalah projek sumber terbuka sebahagiannya berlesen. Terdapat banyak perpustakaan sedemikian untuk bahasa yang berbeza, jadi anda boleh memilih yang paling sesuai dengan anda.
Jadi, sebelum anda mula mengautomasikan penggunaan anda, anda perlu memastikan bahawa proses itu tidak akan tertakluk kepada sebarang masa henti. Sebagai contoh, pasukan kami menjalankan penggunaan pengeluaran pada pertengahan hari apabila orang ramai menggunakan aplikasi paling banyak, jadi adalah penting untuk mengelakkan kelewatan dalam proses ini. Untuk mengelakkan masa henti, 2 kaedah digunakan: penggunaan biru/hijau atau kemas kini bergolek. Dalam kes kedua, jika anda mempunyai 5 replika aplikasi yang sedang berjalan, ia dikemas kini secara berurutan satu demi satu. Kaedah ini berfungsi dengan baik, tetapi ia tidak sesuai jika anda mempunyai versi aplikasi yang berbeza berjalan serentak semasa proses penggunaan. Dalam kes ini, anda boleh mengemas kini antara muka pengguna semasa bahagian belakang menjalankan versi lama dan aplikasi akan berhenti berfungsi. Oleh itu, dari sudut pengaturcaraan, bekerja dalam keadaan sedemikian agak sukar.
Ini adalah salah satu sebab mengapa kami lebih suka menggunakan penggunaan biru/hijau untuk mengautomasikan penggunaan aplikasi kami. Dengan kaedah ini, anda mesti memastikan bahawa hanya satu versi aplikasi yang aktif pada satu masa.
Mekanisme penggunaan biru/hijau kelihatan seperti ini. Kami menerima trafik untuk aplikasi kami melalui ha-proxy, yang memajukannya untuk menjalankan replika aplikasi versi yang sama.
Apabila penempatan baharu dibuat, kami menggunakan Deployer, yang diberikan komponen baharu dan menggunakan versi baharu. Menggunakan versi baharu aplikasi bermakna set replika baharu "dinaikkan", selepas itu replika versi baharu ini dilancarkan dalam pod baharu yang berasingan. Walau bagaimanapun, ha-proxy tidak mengetahui apa-apa tentang mereka dan tidak menghantar sebarang beban kerja kepada mereka lagi.
Oleh itu, pertama sekali, adalah perlu untuk melakukan semakan prestasi versi baharu pemeriksaan kesihatan untuk memastikan replika sedia untuk memberi perkhidmatan kepada beban.
Semua komponen penggunaan mesti menyokong beberapa bentuk pemeriksaan kesihatan. Ini boleh menjadi semakan panggilan HTTP yang sangat mudah, apabila anda menerima kod dengan status 200, atau semakan yang lebih mendalam, di mana anda menyemak sambungan replika dengan pangkalan data dan perkhidmatan lain, kestabilan sambungan persekitaran dinamik , dan sama ada semuanya bermula dan berfungsi dengan betul. Proses ini boleh menjadi agak rumit.
Selepas sistem mengesahkan bahawa semua replika yang dikemas kini berfungsi, Deployer akan mengemas kini konfigurasi dan lulus confd yang betul, yang akan mengkonfigurasi semula ha-proxy.
Hanya selepas ini trafik akan diarahkan ke pod dengan replika versi baharu, dan pod lama akan hilang.
Mekanisme ini bukan ciri Kubernetes. Konsep penggunaan Biru/hijau telah wujud sejak sekian lama dan ia sentiasa menggunakan pengimbang beban. Mula-mula, anda mengarahkan semua trafik ke versi lama aplikasi, dan selepas kemas kini, anda memindahkannya sepenuhnya ke versi baharu. Prinsip ini digunakan bukan sahaja dalam Kubernetes.
Sekarang saya akan memperkenalkan anda kepada komponen penempatan baharu - Deployer, yang menjalankan pemeriksaan kesihatan, mengkonfigurasi semula proksi dan sebagainya. Ini adalah konsep yang tidak terpakai kepada dunia luar dan wujud di dalam Kubernetes. Saya akan menunjukkan kepada anda cara anda boleh mencipta konsep Deployer anda sendiri menggunakan alat sumber terbuka.
Jadi, perkara pertama yang Deployer lakukan ialah mencipta pengawal replikasi RC menggunakan API Kubernetes. API ini mencipta pod dan perkhidmatan untuk penggunaan selanjutnya, iaitu, ia mencipta kluster baharu sepenuhnya untuk aplikasi kami. Sebaik sahaja RC yakin bahawa replika telah dimulakan, ia akan melakukan pemeriksaan Kesihatan ke atas fungsinya. Untuk melakukan ini, Deployer menggunakan arahan GET /health. Ia menjalankan komponen imbasan yang sesuai dan menyemak semua elemen yang menyokong operasi kluster.
Selepas semua pod melaporkan kesihatan mereka, Deployer mencipta elemen konfigurasi baharu - storan teragih dlld, yang digunakan secara dalaman oleh Kubernetes, termasuk menyimpan konfigurasi pengimbang beban. Kami menulis data ke etcd, dan alat kecil yang dipanggil confd monitors etcd untuk data baharu.
Jika ia mengesan sebarang perubahan pada konfigurasi awal, ia menjana fail tetapan baharu dan memindahkannya ke ha-proxy. Dalam kes ini, ha-proxy but semula tanpa kehilangan sebarang sambungan dan mengalamatkan beban kepada perkhidmatan baharu yang membolehkan versi baharu aplikasi kami berfungsi.
Seperti yang anda lihat, walaupun terdapat banyak komponen, tidak ada yang rumit di sini. Anda hanya perlu memberi perhatian lebih kepada API dan etcd. Saya ingin memberitahu anda tentang penyebar sumber terbuka yang kami sendiri gunakan - Amdatu Kubernetes Deployer.
Ia ialah alat untuk mengatur penggunaan Kubernetes dan mempunyai ciri berikut:
- Penggunaan Biru/Hijau;
- menyediakan pengimbang beban luaran;
- pengurusan deskriptor penempatan;
- menguruskan penempatan sebenar;
- menyemak kefungsian pemeriksaan Kesihatan semasa penggunaan;
- pelaksanaan pembolehubah persekitaran ke dalam pod.
Deployer ini dibina di atas API Kubernetes dan menyediakan API REST untuk mengurus pengendalian dan penggunaan, serta API Websocket untuk log penstriman semasa proses penggunaan.
Ia meletakkan data konfigurasi pengimbang beban ke dalam etcd, jadi anda tidak perlu menggunakan ha-proxy dengan sokongan di luar kotak, tetapi gunakan fail konfigurasi pengimbang beban anda sendiri dengan mudah. Amdatu Deployer ditulis dalam Go, seperti Kubernetes sendiri, dan dilesenkan oleh Apache.
Sebelum saya mula menggunakan versi penyebaran ini, saya menggunakan deskriptor penempatan berikut, yang menentukan parameter yang saya perlukan.
Salah satu parameter penting kod ini adalah untuk mendayakan bendera "useHealthCheck". Kami perlu menentukan bahawa pemeriksaan kewarasan mesti dilakukan semasa proses penempatan. Tetapan ini boleh dilumpuhkan apabila penggunaan menggunakan bekas pihak ketiga yang tidak perlu disahkan. Deskriptor ini juga menunjukkan bilangan replika dan URL hujung hadapan yang diperlukan oleh ha-proxy. Pada penghujungnya ialah bendera spesifikasi pod "podspec", yang memanggil Kubernetes untuk mendapatkan maklumat tentang konfigurasi port, imej, dsb. Ini adalah deskriptor JSON yang agak mudah.
Alat lain yang merupakan sebahagian daripada projek Amdatu sumber terbuka ialah Deploymentctl. Ia mempunyai UI untuk mengkonfigurasi penggunaan, menyimpan sejarah penggunaan dan mengandungi cangkuk web untuk panggilan balik daripada pengguna dan pembangun pihak ketiga. Anda mungkin tidak menggunakan UI memandangkan Amdatu Deployer itu sendiri ialah API REST, tetapi antara muka ini boleh menjadikan penggunaan lebih mudah untuk anda tanpa melibatkan sebarang API. Deploymentctl ditulis dalam OSGi/Vertx menggunakan Angular 2.
Saya kini akan menunjukkan perkara di atas pada skrin menggunakan rakaman prarakaman supaya anda tidak perlu menunggu. Kami akan menggunakan aplikasi Go yang mudah. Jangan risau jika anda belum mencuba Go sebelum ini, ia adalah aplikasi yang sangat mudah jadi anda sepatutnya dapat memikirkannya.
Di sini kami mencipta pelayan HTTP yang hanya bertindak balas kepada /kesihatan, jadi aplikasi ini hanya menguji pemeriksaan kesihatan dan tidak ada yang lain. Jika cek lulus, struktur JSON yang ditunjukkan di bawah digunakan. Ia mengandungi versi aplikasi yang akan digunakan oleh pengerahan, mesej yang anda lihat di bahagian atas fail dan jenis data boolean - sama ada aplikasi kami berfungsi atau tidak.
Saya menipu sedikit dengan baris terakhir, kerana saya meletakkan nilai boolean tetap di bahagian atas fail, yang pada masa hadapan akan membantu saya menggunakan walaupun aplikasi "tidak sihat". Kami akan berurusan dengan ini kemudian.
Jadi mari kita mulakan. Mula-mula, kami menyemak kehadiran mana-mana pod yang sedang berjalan menggunakan perintah ~ kubectl get pods dan, berdasarkan ketiadaan respons daripada URL bahagian hadapan, kami memastikan tiada penempatan sedang dibuat pada masa ini.
Seterusnya pada skrin anda melihat antara muka Deploymentctl yang saya nyatakan, di mana parameter penempatan ditetapkan: ruang nama, nama aplikasi, versi penggunaan, bilangan replika, URL bahagian hadapan, nama kontena, imej, had sumber, nombor port untuk pemeriksaan kesihatan, dan lain-lain. Had sumber adalah sangat penting, kerana ia membolehkan anda menggunakan jumlah maksimum perkakasan yang mungkin. Di sini anda juga boleh melihat log Deployment.
Jika anda kini mengulangi arahan ~ kubectl get pods, anda boleh melihat bahawa sistem "membeku" selama 20 saat, semasa ha-proxy dikonfigurasikan semula. Selepas ini, pod bermula, dan replika kami boleh dilihat dalam log penggunaan.
Saya memotong 20 saat menunggu daripada video, dan kini anda boleh melihat pada skrin bahawa versi pertama aplikasi telah digunakan. Semua ini dilakukan hanya menggunakan UI.
Sekarang mari cuba versi kedua. Untuk melakukan ini, saya menukar mesej aplikasi daripada "Hello, Kubernetes!" pada "Hello, Deployer!", sistem mencipta imej ini dan meletakkannya dalam registri Docker, selepas itu kami hanya klik pada butang "Deploy" sekali lagi dalam tetingkap Deploymentctl. Dalam kes ini, log penggunaan dilancarkan secara automatik dengan cara yang sama seperti yang berlaku semasa menggunakan versi pertama aplikasi.
Perintah ~ kubectl get pods menunjukkan bahawa pada masa ini terdapat 2 versi aplikasi yang sedang berjalan, tetapi bahagian hadapan menunjukkan bahawa kami masih menjalankan versi 1.
Pengimbang beban menunggu sehingga pemeriksaan kesihatan selesai sebelum mengubah hala trafik ke versi baharu. Selepas 20 saat, kami beralih kepada curl dan melihat bahawa kami kini mempunyai versi 2 aplikasi yang digunakan, dan yang pertama telah dipadamkan.
Ini ialah penggunaan aplikasi "sihat". Mari lihat apa yang berlaku jika untuk versi baharu aplikasi saya menukar parameter Sihat daripada benar kepada palsu, iaitu, saya cuba menggunakan aplikasi tidak sihat yang gagal dalam pemeriksaan kesihatan. Ini boleh berlaku jika beberapa ralat konfigurasi telah dibuat dalam aplikasi pada peringkat pembangunan, dan ia telah dihantar ke dalam pengeluaran dalam borang ini.
Seperti yang anda lihat, penggunaan melalui semua langkah di atas dan ~kubectl get pods menunjukkan bahawa kedua-dua pod sedang berjalan. Tetapi tidak seperti penggunaan sebelumnya, log menunjukkan status tamat masa. Iaitu, disebabkan oleh fakta bahawa pemeriksaan kesihatan gagal, versi baharu aplikasi tidak boleh digunakan. Akibatnya, anda melihat bahawa sistem telah kembali menggunakan versi lama aplikasi, dan versi baharu hanya dinyahpasang.
Perkara yang baik tentang ini ialah walaupun anda mempunyai sejumlah besar permintaan serentak yang masuk ke dalam aplikasi, mereka tidak akan menyedari masa henti semasa melaksanakan prosedur penggunaan. Jika anda menguji aplikasi ini menggunakan rangka kerja Gatling, yang menghantarnya seberapa banyak permintaan yang mungkin, maka tiada satu pun permintaan ini akan digugurkan. Ini bermakna pengguna kami tidak akan melihat kemas kini versi dalam masa nyata. Jika gagal, kerja akan diteruskan pada versi lama; jika berjaya, pengguna akan bertukar kepada versi baharu.
Hanya ada satu perkara yang boleh gagal - jika pemeriksaan kesihatan berjaya, tetapi aplikasi gagal sebaik sahaja beban kerja digunakan padanya, iaitu, keruntuhan akan berlaku hanya selepas penggunaan selesai. Dalam kes ini, anda perlu melancarkan semula secara manual ke versi lama. Jadi, kami melihat cara menggunakan Kubernetes dengan alatan sumber terbuka yang direka untuknya. Proses penggunaan akan menjadi lebih mudah jika anda membina alatan ini ke dalam saluran paip Bina/Gunakan anda. Pada masa yang sama, untuk memulakan penggunaan, anda boleh menggunakan sama ada antara muka pengguna atau mengautomasikan sepenuhnya proses ini dengan menggunakan, sebagai contoh, komited untuk menguasai.
Pelayan Binaan kami akan mencipta imej Docker, menolaknya ke Hab Docker atau apa sahaja pendaftaran yang anda gunakan. Docker Hub menyokong webhook, jadi kami boleh mencetuskan penggunaan jauh melalui Deployer dengan cara yang ditunjukkan di atas. Dengan cara ini anda boleh mengautomasikan sepenuhnya penggunaan aplikasi anda kepada pengeluaran yang berpotensi.
Mari kita beralih ke topik seterusnya - menskala kelompok Kubernetes. Ambil perhatian bahawa arahan kubectl ialah arahan penskalaan. Dengan lebih banyak bantuan, kami boleh meningkatkan bilangan replika dalam kelompok sedia ada kami dengan mudah. Walau bagaimanapun, dalam amalan, kami biasanya ingin menambah bilangan nod dan bukannya pod.
Pada masa yang sama, semasa waktu bekerja anda mungkin perlu meningkatkan, dan pada waktu malam, untuk mengurangkan kos perkhidmatan Amazon, anda mungkin perlu mengurangkan bilangan contoh aplikasi yang dijalankan. Ini tidak bermakna bahawa penskalaan hanya bilangan pod akan mencukupi, kerana walaupun salah satu nod melahu, anda masih perlu membayar Amazon untuknya. Iaitu, bersama-sama dengan penskalaan pod, anda perlu menskalakan bilangan mesin yang digunakan.
Ini boleh mencabar kerana sama ada kami menggunakan Amazon atau perkhidmatan awan yang lain, Kubernetes tidak mengetahui apa-apa tentang bilangan mesin yang digunakan. Ia tidak mempunyai alat yang membolehkan anda menskalakan sistem pada tahap nod.
Jadi kita perlu menjaga kedua-dua nod dan pod. Kami boleh menskalakan pelancaran nod baharu dengan mudah menggunakan API AWS dan mesin kumpulan Penskalaan untuk mengkonfigurasi bilangan nod pekerja Kubernetes. Anda juga boleh menggunakan cloud-init atau skrip yang serupa untuk mendaftarkan nod dalam kelompok Kubernetes.
Mesin baharu bermula dalam kumpulan Penskalaan, memulakan dirinya sebagai nod, mendaftar dalam pendaftaran induk dan mula berfungsi. Selepas ini, anda boleh menambah bilangan replika untuk digunakan pada nod yang terhasil. Menurunkan skala memerlukan lebih banyak usaha, kerana anda perlu memastikan bahawa langkah sedemikian tidak membawa kepada kemusnahan aplikasi yang sudah berjalan selepas mematikan mesin "tidak perlu". Untuk mengelakkan senario sedemikian, anda perlu menetapkan nod kepada status "tidak boleh dijadualkan". Ini bermakna penjadual lalai akan mengabaikan nod ini apabila menjadualkan pod DaemonSet. Penjadual tidak akan memadamkan apa-apa daripada pelayan ini, tetapi juga tidak akan melancarkan bekas baharu di sana. Langkah seterusnya ialah membuang nod longkang, iaitu, memindahkan pod yang sedang berjalan daripadanya ke mesin lain, atau nod lain yang mempunyai kapasiti yang mencukupi untuk ini. Setelah anda memastikan bahawa tiada lagi bekas pada nod ini, anda boleh mengalih keluarnya daripada Kubernetes. Selepas ini, mereka hanya akan berhenti wujud untuk Kubernetes. Seterusnya, anda perlu menggunakan API AWS untuk melumpuhkan nod atau mesin yang tidak diperlukan.
Anda boleh menggunakan Amdatu Scalerd, alat penskalaan sumber terbuka lain yang serupa dengan API AWS. Ia menyediakan CLI untuk menambah atau mengalih keluar nod dalam kelompok. Ciri menariknya ialah keupayaan untuk mengkonfigurasi penjadual menggunakan fail json berikut.
Kod yang ditunjukkan mengurangkan kapasiti kluster sebanyak separuh semasa tempoh malam. Ia mengkonfigurasi kedua-dua bilangan replika yang tersedia dan kapasiti yang dikehendaki bagi kluster Amazon. Menggunakan penjadual ini secara automatik akan mengurangkan bilangan nod pada waktu malam dan meningkatkannya pada waktu pagi, menjimatkan kos penggunaan nod daripada perkhidmatan awan seperti Amazon. Ciri ini tidak terbina dalam Kubernetes, tetapi menggunakan Scalerd akan membolehkan anda menskalakan platform ini mengikut kehendak anda.
Saya ingin menyatakan bahawa ramai orang memberitahu saya, "Itu semua baik dan bagus, tetapi bagaimana dengan pangkalan data saya, yang biasanya statik?" Bagaimanakah anda boleh menjalankan sesuatu seperti ini dalam persekitaran dinamik seperti Kubernetes? Pada pendapat saya, anda tidak sepatutnya melakukan ini, anda tidak sepatutnya cuba menjalankan gudang data dalam Kubernetes. Ini secara teknikal mungkin, dan terdapat tutorial di Internet mengenai subjek ini, tetapi ia akan merumitkan hidup anda secara serius.
Ya, terdapat konsep kedai yang berterusan dalam Kubernetes, dan anda boleh cuba menjalankan stor data seperti Mongo atau MySQL, tetapi ini adalah tugas yang memerlukan tenaga kerja yang tinggi. Ini disebabkan oleh fakta bahawa gudang data tidak menyokong sepenuhnya interaksi dengan persekitaran yang dinamik. Kebanyakan pangkalan data memerlukan konfigurasi penting, termasuk konfigurasi manual kluster, tidak menyukai penskalaan automatik dan perkara lain yang serupa.
Oleh itu, anda tidak seharusnya merumitkan hidup anda dengan cuba menjalankan gudang data di Kubernetes. Atur kerja mereka dengan cara tradisional menggunakan perkhidmatan biasa dan cukup berikan Kubernetes keupayaan untuk menggunakannya.
Untuk mengakhiri topik ini, saya ingin memperkenalkan anda kepada platform Cloud RTI berdasarkan Kubernetes, yang sedang diusahakan oleh pasukan saya. Ia menyediakan pembalakan berpusat, pemantauan aplikasi dan kelompok, dan banyak ciri berguna lain yang akan berguna. Ia menggunakan pelbagai alat sumber terbuka seperti Grafana untuk memaparkan pemantauan.
Terdapat soalan tentang mengapa menggunakan pengimbang beban ha-proksi dengan Kubernetes. Soalan yang bagus kerana pada masa ini terdapat 2 tahap pengimbangan beban. Perkhidmatan Kubernetes masih berada pada alamat IP maya. Anda tidak boleh menggunakannya untuk port pada mesin hos luaran kerana jika Amazon membebankan hos awannya, alamat akan berubah. Inilah sebabnya kami meletakkan ha-proxy di hadapan perkhidmatan - untuk mencipta struktur yang lebih statik untuk trafik berkomunikasi dengan lancar dengan Kubernetes.
Satu lagi soalan yang bagus ialah bagaimana anda boleh menjaga perubahan skema pangkalan data apabila melakukan penggunaan biru/hijau? Hakikatnya ialah tanpa mengira penggunaan Kubernetes, menukar skema pangkalan data adalah tugas yang sukar. Anda perlu memastikan bahawa skema lama dan baharu adalah serasi, selepas itu anda boleh mengemas kini pangkalan data dan kemudian mengemas kini aplikasi itu sendiri. Anda boleh menukar pangkalan data dan kemudian mengemas kini aplikasi. Saya mengenali orang yang telah memulakan kluster pangkalan data yang benar-benar baharu dengan skema baharu, ini adalah pilihan jika anda mempunyai pangkalan data tanpa skema seperti Mongo, tetapi ia bukanlah satu tugas yang mudah. Jika anda tiada soalan lanjut, terima kasih atas perhatian anda!
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com