Halo, pamiarsa Habr. Kalayan tulisan ieu kami muka séri anu bakal nyarioskeun ngeunaan sistem hyperconverged AERODISK vAIR anu parantos dikembangkeun. Mimitina, urang hoyong nyarios sadayana ngeunaan sadayana dina tulisan anu munggaran, tapi sistemna rada rumit, janten urang bakal ngahakan gajah sabagian.
Hayu urang mimitian carita kalawan sajarah kreasi sistem, delve kana sistem file ARDFS, nu jadi dadasar VAIR, sarta ogé ngobrol saeutik ngeunaan posisi solusi ieu dina pasar Rusia.
Dina artikel nu bakal datang urang bakal ngobrol di leuwih jéntré ngeunaan komponén arsitéktur béda (cluster, hypervisor, load balancer, sistem monitoring, jsb), prosés konfigurasi, ngangkat masalah lisénsi, misah némbongkeun tés kacilakaan sarta, tangtosna, nulis ngeunaan nguji beban jeung ukuran. Urang ogé bakal bakti artikel misah ka versi komunitas vAIR.
Naha Aerodisk mangrupikeun carita ngeunaan sistem panyimpen? Atawa naha urang mimiti ngalakukeun hyperconvergence di tempat munggaran?
Mimitina, ideu pikeun nyiptakeun hyperconvergence urang sorangan sumping ka urang dimana waé sakitar 2010. Dina waktos éta, henteu aya Aerodisk atanapi solusi anu sami (sistem hyperconverged boxed komérsial) dina pasaran. Tugas kami nyaéta kieu: ti sakumpulan server sareng disk lokal, dihijikeun ku interkonéksi via protokol Ethernet, perlu nyiptakeun panyimpenan anu diperpanjang sareng ngaluncurkeun mesin virtual sareng jaringan parangkat lunak di dinya. Sadaya ieu kedah dilaksanakeun tanpa sistem panyimpen (sabab teu aya artos pikeun sistem panyimpen sareng perkakasna, sareng urang henteu acan nimukeun sistem panyimpen urang sorangan).
Kami nyobian seueur solusi open source sareng tungtungna ngarengsekeun masalah ieu, tapi solusina rumit pisan sareng sesah diulang. Sajaba ti éta, solusi ieu dina kategori "Naha éta jalan? Tong noél! Ku alatan éta, sanggeus direngsekeun masalah éta, urang teu salajengna ngamekarkeun ideu transformasi hasil karya urang kana produk full-fledged.
Sanggeus kajadian éta, urang dipindahkeun jauh ti gagasan ieu, tapi urang masih boga rarasaan yen masalah ieu sagemblengna solvable, sarta mangpaat solusi sapertos éta leuwih ti atra. Salajengna, produk HCI dileupaskeun pausahaan asing ngan dikonfirmasi rarasaan ieu.
Ku alatan éta, dina pertengahan 2016, urang balik ka tugas ieu salaku bagian tina nyieun hiji produk full-fledged. Dina waktos éta kami henteu acan ngagaduhan hubungan sareng investor, janten kami kedah mésér lapak pangembangan pikeun artos anu henteu ageung pisan. Saanggeus dikumpulkeun server dipaké sarta switch on Avito, urang turun ka bisnis.
Tugas awal utama éta nyieun sorangan, albeit basajan, tapi sistem file urang sorangan, nu bisa otomatis tur merata ngadistribusikaeun data dina bentuk blok maya dina jumlah nth tina titik klaster, nu disambungkeun ku hiji interconnect via Ethernet. Dina waktos anu sami, FS kedah skala anu saé sareng gampang sareng mandiri tina sistem anu padeukeut, nyaéta. diasingkeun tina vAIR dina bentuk "ngan fasilitas panyimpen".
Konsep vAIR munggaran
Kami ngahaja ngantunkeun panggunaan solusi open source anu siap-siap pikeun ngatur panyimpen anu panjang (ceph, gluster, luster sareng anu sanésna) pikeun ngembangkeun urang sorangan, sabab kami parantos ngagaduhan seueur pangalaman proyék sareng aranjeunna. Tangtosna, solusi ieu nyalira saé, sareng sateuacan damel di Aerodisk, kami ngalaksanakeun langkung ti hiji proyék integrasi sareng aranjeunna. Tapi éta hiji hal pikeun ngalaksanakeun tugas husus pikeun hiji customer, ngalatih staf jeung, meureun, meuli rojongan ti vendor badag, sarta rada hal séjén pikeun nyieun hiji produk gampang replicated anu bakal dipaké pikeun sagala rupa tugas, nu urang, salaku a vendor, malah bisa nyaho ngeunaan diri urang moal. Pikeun tujuan kadua, produk open source anu tos aya henteu cocog pikeun kami, janten kami mutuskeun pikeun nyiptakeun sistem file anu disebarkeun sorangan.
Dua warsih saterusna, sababaraha pamekar (anu ngagabungkeun gawé dina vAIR kalawan gawé dina Sistim gudang Engine Palasik) ngahontal hasil nu tangtu.
Taun 2018, kami parantos nyerat sistem file anu saderhana sareng nambihanana ku hardware anu diperyogikeun. Sistem ieu ngagabungkeun disk fisik (lokal) tina server anu béda-béda kana hiji kolam renang datar liwat interkonéksi internal sareng "motong" kana blok virtual, teras meungpeuk alat-alat anu ngagaduhan tingkat kasabaran kasalahan anu béda-béda diciptakeun tina blok maya, dimana blok virtual diciptakeun. sareng dieksekusi nganggo mobil hypervisor KVM.
Kami henteu ganggu teuing ku nami sistem file sareng sacara ringkes nyebat éta ARDFS (tebak naon hartosna))
Prototipe ieu katingali saé (henteu sacara visual, tangtosna, teu acan aya desain visual) sareng nunjukkeun hasil anu saé dina hal kinerja sareng skala. Saatos hasil nyata munggaran, urang nyetél proyék ieu gerak, ngatur lingkungan ngembangkeun full-fledged sarta tim misah nu diurus ngan vAIR.
Ngan ku waktu éta, arsitéktur umum leyuran geus matured, nu teu acan undergone parobahan utama.
Nyilem kana sistem file ARDFS
ARDFS mangrupikeun pondasi vAIR, anu nyayogikeun panyimpen data anu disebarkeun, toleran lepat di sakumna klaster. Salah sahiji (tapi sanés ngan ukur) fitur has ARDFS nyaéta yén éta henteu nganggo server khusus tambahan pikeun metadata sareng manajemén. Ieu asalna katimu pikeun simplify konfigurasi solusi jeung reliabilitas na.
Struktur gudang
Dina sadaya titik kluster, ARDFS ngatur kolam renang logis tina sadaya rohangan disk anu sayogi. Kadé ngartos yen kolam renang a teu acan data atawa spasi formatna, tapi saukur markup, i.e. Sakur titik sareng vAIR dipasang, nalika ditambahkeun kana klaster, otomatis ditambahkeun kana ARDFS pool dibagikeun jeung sumber disk otomatis jadi dibagikeun sakuliah sakabéh klaster (jeung sadia pikeun neundeun data hareup). Pendekatan ieu ngidinan Anjeun pikeun nambahkeun jeung cabut titik on laleur tanpa dampak serius dina sistem geus ngajalankeun. Jelema. Sistim nu pisan gampang skala "dina bata", nambahkeun atawa nyoplokkeun titik dina klaster lamun perlu.
Disk virtual (objék panyimpen pikeun mesin virtual) ditambahkeun dina luhureun kolam renang ARDFS, anu diwangun tina blok virtual anu ukuranana 4 megabyte. Virtual disk langsung nyimpen data. Skéma kasabaran kasalahan ogé diatur dina tingkat disk virtual.
Anjeun bisa geus ditebak, pikeun kasabaran lepat tina subsistem disk, kami henteu nganggo konsép RAID (Asép Sunandar Sunarya kaleuleuwihan of bebas Disk), tapi make HUJAN (Asép Sunandar Sunarya kaleuleuwihan titik bebas). Jelema. Kasabaran kasalahan diukur, otomatis, sareng dikokolakeun dumasar kana titik, sanés disk. Disk, tangtosna, ogé mangrupikeun obyék panyimpen, aranjeunna, sapertos sadayana anu sanés, diawaskeun, anjeun tiasa ngalaksanakeun sagala operasi standar sareng aranjeunna, kalebet assembling RAID hardware lokal, tapi kluster beroperasi sacara khusus dina titik.
Dina kaayaan dimana anjeun rék RAID (Contona, skenario nu ngarojong sababaraha gagal dina klaster leutik), euweuh nyegah anjeun ti ngagunakeun controller razia lokal, sarta ngawangun gudang stretched sarta arsitéktur HUJAN di luhur. Skenario ieu cukup hirup sareng dirojong ku kami, janten kami bakal ngobrol ngeunaan éta dina tulisan ngeunaan skenario umum pikeun ngagunakeun vAIR.
Panyimpenan Skéma Kasabaran Sesar
Bisa aya dua skéma kasabaran kasalahan pikeun disk virtual dina vAIR:
1) Faktor réplikasi atanapi ngan ukur réplikasi - metode kasabaran sesar ieu saderhana sapertos iteuk sareng tali. Réplikasi sinkron dilakukeun antara titik kalayan faktor 2 (2 salinan per klaster) atanapi 3 (3 salinan, masing-masing). RF-2 ngamungkinkeun disk virtual nahan kagagalan hiji titik dina kluster, tapi "dahar" satengah tina volume mangpaat, sarta RF-3 bakal tahan gagalna 2 titik dina kluster, tapi cadangan 2/3 tina volume mangpaat pikeun kaperluan na. Skéma ieu sami sareng RAID-1, nyaéta, disk virtual anu dikonpigurasi dina RF-2 tahan kana gagalna salah sahiji titik dina kluster. Dina hal ieu, sagalana bakal rupa jeung data komo I / O moal eureun. Nalika titik ragrag balik ka layanan, recovery / sinkronisasi data otomatis bakal dimimitian.
Di handap ieu conto distribusi data RF-2 sareng RF-3 dina modeu normal sareng dina kaayaan gagal.
Simkuring boga mesin virtual kalawan kapasitas 8MB data unik (mangpaat), nu dijalankeun dina 4 titik vAIR. Ieu jelas yén dina kanyataanana teu mungkin yen bakal aya volume leutik, tapi pikeun skéma nu ngagambarkeun logika operasi ARDFS, conto ieu paling kaharti. AB nyaéta blok virtual 4MB anu ngandung data mesin virtual unik. RF-2 nyiptakeun dua salinan blok ieu A1 + A2 sareng B1 + B2, masing-masing. Blok ieu "diteundeun" dina titik-titik, ngahindarkeun simpang data anu sami dina titik anu sami, nyaéta, salinan A1 moal aya dina titik anu sami sareng salinan A2. Sarua jeung B1 jeung B2.
Lamun salah sahiji titik gagal (Contona, titik No. 3, nu ngandung salinan B1), salinan ieu otomatis diaktipkeun dina titik dimana euweuh salinan salinan na (nyaéta, salinan B2).
Ku kituna, disk virtual (jeung VM, sasuai) bisa kalayan gampang salamet gagalna hiji titik dina skéma RF-2.
Skéma réplikasi, bari basajan tur dipercaya, ngalaman masalah anu sarua sakumaha RAID1 - teu cukup spasi usable.
2) Erasure coding atawa erasure coding (ogé katelah "redundant coding", "erasure coding" atawa "redundancy code") aya pikeun ngajawab masalah di luhur. EC mangrupikeun skéma redundansi anu nyayogikeun kasadiaan data anu luhur sareng overhead rohangan disk anu langkung handap dibandingkeun réplikasi. Prinsip operasi mékanisme ieu sami sareng RAID 5, 6, 6P.
Nalika encoding, prosés EC ngabagi blok virtual (sacara standar 4MB) kana sababaraha "sakumpulan data" anu langkung alit gumantung kana skéma EC (contona, skéma 2 + 1 ngabagi unggal blok 4MB kana 2 sakumpulan 2MB). Salajengna, prosés ieu ngahasilkeun "sakumpulan parity" pikeun "sakumpulan data" nu teu leuwih badag batan salah sahiji bagian saméméhna dibagi. Nalika decoding, EC ngahasilkeun sakumpulan leungit ku maca data "salamet" sakuliah sakabéh klaster.
Contona, disk virtual kalawan skéma 2 + 1 EC, dilaksanakeun dina 4 titik klaster, bakal gampang tahan gagalna hiji titik dina klaster dina cara nu sarua salaku RF-2. Dina hal ieu, biaya overhead bakal langkung handap, khususna, koefisien kapasitas kapaké pikeun RF-2 nyaéta 2, sareng pikeun EC 2 + 1 éta 1,5.
Pikeun ngajelaskeun eta leuwih basajan, intina nyaéta yén blok maya dibagi kana 2-8 (naha ti 2 nepi ka 8, tingali di handap) "potongan", sarta pikeun potongan ieu diitung "potongan" parity volume sarupa.
Hasilna, data sareng paritas disebarkeun merata ka sadaya titik kluster. Dina waktos anu sami, sapertos réplikasi, ARDFS sacara otomatis nyebarkeun data diantara titik-titik ku cara pikeun nyegah data idéntik (salinan data sareng paritasna) disimpen dina titik anu sami, pikeun ngaleungitkeun kamungkinan kaleungitan data kusabab kanyataan yén data sarta parity maranéhna ujug-ujug bakal mungkas nepi ka hiji titik gudang nu gagal.
Di handap ieu conto, kalawan mesin virtual sarua 8 MB jeung 4 titik, tapi kalawan EC 2 + 1 skéma.
Blok A jeung B dibagi jadi dua lembar 2 MB unggal (dua sabab 2+1), nyaeta, A1+A2 jeung B1+B2. Beda sareng réplika, A1 sanés salinan A2, éta mangrupikeun blok virtual A, dibagi jadi dua bagian, sami sareng blok B. Dina total, urang nampi dua sét 4MB, anu masing-masing ngandung dua potongan dua MB. Salajengna, pikeun tiap set ieu, parity diitung kalawan volume teu leuwih ti hiji sapotong (ie 2 MB), urang ménta tambahan + 2 potongan parity (A-P jeung B-P). Dina total urang gaduh 4 × 2 data + 2 × 2 parity.
Salajengna, potongan-potongan "ditetepkeun" di antara titik-titik supados data henteu bersilangan sareng paritasna. Jelema. A1 sareng A2 moal bohong dina titik anu sami sareng A-P.
Upami gagalna hiji titik (contona, ogé katilu), blok B1 anu murag bakal dibalikeun sacara otomatis tina parity B-P, anu disimpen dina titik No.. 2, sareng bakal diaktipkeun dina titik dimana aya euweuh B-parity, i.e. sapotong B-P. Dina conto ieu, ieu titik No
Kuring yakin nu maca boga patarosan:
"Sagala anu anjeun terangkeun parantos lami dilaksanakeun ku pesaing sareng dina solusi open source, naon bédana antara palaksanaan EC anjeun dina ARDFS?"
Teras bakal aya fitur anu pikaresepeun tina ARDFS.
Hapus coding kalayan fokus kana kalenturan
Mimitina, kami nyayogikeun skéma EC X + Y anu cukup fleksibel, dimana X sami sareng angka ti 2 dugi ka 8, sareng Y sami sareng angka ti 1 dugi ka 8, tapi sok kirang atanapi sami sareng X. Skema ieu disayogikeun. pikeun kalenturan. Ngaronjatkeun jumlah potongan data (X) dimana blok virtual dibagi ngamungkinkeun ngirangan biaya overhead, nyaéta, ningkatkeun rohangan anu tiasa dianggo.
Ngaronjatkeun jumlah sakumpulan parity (Y) ngaronjatkeun reliabiliti disk virtual. Langkung ageung nilai Y, langkung seueur titik dina kluster tiasa gagal. Tangtosna, ningkatkeun volume parity ngirangan jumlah kapasitas anu tiasa dianggo, tapi ieu mangrupikeun harga anu kedah dibayar pikeun réliabilitas.
Katergantungan kinerja dina sirkuit EC ampir langsung: langkung seueur "potongan", langkung handap kinerja; di dieu, tangtosna, pandangan anu saimbang diperyogikeun.
Pendekatan ieu ngamungkinkeun pangurus pikeun ngonpigurasikeun panyimpenan anu panjang kalayan kalenturan maksimal. Dina kolam renang ARDFS, anjeun tiasa nganggo skéma kasabaran kasalahan sareng kombinasina, anu, dina pendapat kami, ogé mangpaat pisan.
Di handap ieu tabel ngabandingkeun sababaraha (teu kabeh mungkin) RF na EC schemes.
tabél nembongkeun yen malah paling "Terry" kombinasi EC 8 + 7, anu ngamungkinkeun leungitna nepi ka 7 titik dina klaster sakaligus, "dahar" spasi kirang usable (1,875 versus 2) ti réplikasi baku, sarta ngajaga 7 kali hadé. , nu ngajadikeun mékanisme panyalindungan ieu, sanajan leuwih kompleks, leuwih pikaresepeun dina situasi dimana diperlukeun pikeun mastikeun reliabiliti maksimum dina kaayaan spasi disk kawates. Dina waktos anu sami, anjeun kedah ngartos yén unggal "tambah" ka X atanapi Y bakal janten overhead kinerja tambahan, janten dina segitiga antara réliabilitas, tabungan sareng kinerja anjeun kedah milih taliti pisan. Ku sabab kitu, urang bakal bakti artikel misah pikeun mupus ukuran coding.
Réliabilitas sareng otonomi sistem file
ARDFS dijalankeun sacara lokal dina sadaya titik kluster sareng nyingkronkeunana nganggo cara sorangan ngalangkungan antarmuka Ethernet khusus. Titik penting nyaéta yén ARDFS bebas nyingkronkeun teu ukur data, tapi ogé metadata patali gudang. Nalika damel di ARDFS, urang sakaligus diajar sababaraha solusi anu tos aya sareng urang mendakan yén seueur anu nyinkronkeun meta sistem file nganggo DBMS anu disebarkeun éksternal, anu ogé kami anggo pikeun sinkronisasi, tapi ngan ukur konfigurasi, sanés metadata FS (ngeunaan ieu sareng subsistem anu aya hubunganana. dina artikel salajengna).
Nyingkronkeun metadata FS nganggo DBMS éksternal, tangtosna, mangrupikeun solusi anu tiasa dianggo, tapi teras konsistensi data anu disimpen dina ARDFS bakal gumantung kana DBMS éksternal sareng paripolahna (sareng, terus terang, éta awéwé capricious). pendapat urang goréng. Naha? Upami metadata FS ruksak, data FS sorangan ogé tiasa disebat "wilujeng," janten urang mutuskeun pikeun nyandak jalur anu langkung rumit tapi dipercaya.
Urang nyieun subsistem sinkronisasi metadata pikeun ARDFS sorangan, sarta hirup sagemblengna bebas tina subsistem padeukeut. Jelema. euweuh subsistem séjén bisa ngaruksak data ARDFS. Dina pamadegan urang, ieu téh cara paling dipercaya jeung bener, tapi waktu bakal ngabejaan naha ieu sabenerna kitu. Sajaba ti éta, aya hiji kaunggulan tambahan kalayan pendekatan ieu. ARDFS tiasa dianggo sacara mandiri tina vAIR, sapertos panyimpenan anu dipanjangkeun, anu pasti bakal kami anggo dina produk anu bakal datang.
Hasilna, ku ngamekarkeun ARDFS, kami nampi sistem file anu fleksibel sareng dipercaya anu masihan pilihan dimana anjeun tiasa ngahemat kapasitas atanapi masihan sadayana kana pagelaran, atanapi ngadamel panyimpen anu tiasa dipercaya dina biaya anu lumayan, tapi ngirangan syarat kinerja.
Kalayan kabijakan lisénsi anu saderhana sareng modél pangiriman anu fleksibel (neuteup ka hareup, vAIR dilisensikeun ku node sareng dikirimkeun boh salaku parangkat lunak atanapi salaku pakét parangkat lunak), ieu ngamungkinkeun pikeun nyaluyukeun sacara akurat solusi pikeun rupa-rupa sarat palanggan sareng lajeng gampang ngajaga kasaimbangan ieu.
Saha anu peryogi mujijat ieu?
Di hiji sisi, urang tiasa nyebatkeun yén parantos aya pamaén di pasar anu ngagaduhan solusi anu serius dina widang hyperconvergence, sareng ieu dimana urang nuju nuju. Sigana pernyataan ieu leres, TAPI ...
Di sisi anu sanésna, nalika urang angkat ka sawah sareng komunikasi sareng para nasabah, urang sareng mitra ningali yén ieu sanés masalahna. Aya seueur tugas pikeun hyperconvergence, di sababaraha tempat jalma ngan saukur teu terang yén solusi sapertos kitu aya, di batur sigana mahal, di batur aya tés anu gagal pikeun solusi alternatif, sareng di batur aranjeunna ngalarang mésér kusabab sanksi. Sacara umum, sawah tétéla unplowed, jadi urang indit pikeun ngumpulkeun taneuh parawan))).
Iraha sistem panyimpen langkung saé tibatan GCS?
Nalika urang damel sareng pasar, urang sering ditaroskeun nalika langkung saé ngagunakeun skéma klasik sareng sistem panyimpen, sareng nalika nganggo hyperconvergent? Seueur perusahaan anu ngahasilkeun GCS (utamana anu henteu ngagaduhan sistem panyimpen dina portofoliona) nyarios: "Sistem panyimpen janten leungit, ngan ukur hyperconverged!" Ieu pernyataan kandel, tapi teu sagemblengna ngagambarkeun kanyataanana.
Sabenerna, pasar gudang memang pindah ka arah hyperconvergence jeung solusi sarupa, tapi sok aya "tapi".
Anu mimiti, pusat data sareng infrastruktur IT anu diwangun dumasar kana skéma klasik sareng sistem panyimpen henteu tiasa gampang diwangun deui, ku kituna modérnisasi sareng parantosan infrastruktur sapertos kitu masih janten warisan salami 5-7 taun.
Bréh, infrastruktur anu ayeuna keur diwangun keur bagian paling (hartina Féderasi Rusia) diwangun nurutkeun skéma klasik ngagunakeun sistem gudang, sarta lain alatan jalma teu nyaho ngeunaan hyperconvergence, tapi alatan pasar hyperconvergence anyar, solusi na. standar teu acan diadegkeun , jalma IT teu acan dilatih, aranjeunna gaduh sakedik pangalaman, tapi maranéhna kudu ngawangun puseur data di dieu jeung ayeuna. Sareng tren ieu bakal salami 3-5 taun deui (teras warisan anu sanés, tingali titik 1).
Thirdly, aya watesan teknis murni dina reureuh leutik tambahan 2 milliseconds per nulis (teu kaasup cache lokal, tangtosna), nu mangrupakeun biaya gudang disebarkeun.
Nya, hayu urang hilap ngeunaan panggunaan server fisik ageung anu resep kana skala vertikal subsistem disk.
Aya seueur tugas anu diperyogikeun sareng populér dimana sistem panyimpen langkung saé tibatan GCS. Di dieu, tangtosna, produsén anu henteu ngagaduhan sistem panyimpen dina portopolio produkna moal satuju sareng kami, tapi kami siap ngabantah sacara wajar. Tangtosna, kami, salaku pamekar duanana produk, pasti bakal ngabandingkeun sistem panyimpen sareng GCS dina salah sahiji publikasi anu bakal datang, dimana urang bakal jelas nunjukkeun mana anu langkung saé dina kaayaan naon.
Sareng dimana solusi hyperconverged tiasa dianggo langkung saé tibatan sistem panyimpen?
Dumasar kana poin-poin di luhur, tilu kacindekan anu jelas tiasa ditarik:
- Dimana tambahan 2 milliseconds of latency pikeun ngarekam, nu konsistén lumangsung dina produk mana wae (ayeuna urang teu ngawangkong ngeunaan synthetics, nanoseconds bisa ditémbongkeun dina synthetics), teu kritis, hyperconvergent cocog.
- Dimana beban tina server fisik ageung tiasa dirobih janten seueur virtual anu alit sareng disebarkeun di antara titik-titik, hyperconvergence ogé tiasa dianggo di dinya.
- Dimana skala horisontal mangrupikeun prioritas anu langkung luhur tibatan skala vertikal, GCS ogé bakal saé pisan.
Naon solusi ieu?
- Sadaya jasa infrastruktur standar (layanan diréktori, mail, EDMS, server file, ERP leutik atawa sedeng jeung sistem BI, jsb). Urang nelepon ieu "komputasi umum".
- Infrastruktur panyadia awan, dimana perlu gancang sarta standarisasi horizontal dilegakeun jeung gampang "motong" angka nu gede ngarupakeun mesin virtual pikeun klien.
- Infrastruktur desktop virtual (VDI), dimana seueur mesin virtual pangguna leutik ngajalankeun sareng tenang "ngambang" dina klaster seragam.
- Jaringan Cabang, dimana unggal cabang peryogi standar, lepat-toleran, tapi infrastruktur murah tina 15-20 mesin virtual.
- Sakur komputasi anu disebarkeun (upamana jasa data gedé). Dimana beban mana teu "jero", tapi "dina breadth".
- Test lingkungan dimana reureuh leutik tambahan bisa ditarima, tapi aya larangan anggaran, sabab ieu téh tés.
Ayeuna, pikeun tugas-tugas ieu kami parantos ngadamel AERODISK vAIR sareng éta anu kami fokuskeun (sajauh ieu parantos suksés). Panginten ieu bakal énggal-énggal robih, sabab ... dunya teu nangtung kénéh.
Jadi…
Ieu ngalengkepan bagian kahiji tina runtuyan badag artikel; dina artikel salajengna urang bakal ngobrol ngeunaan arsitektur solusi jeung komponén dipaké.
Kami ngabagéakeun patarosan, saran sareng sengketa konstruktif.
sumber: www.habr.com