Hello, pembaca Habr. Dengan artikel ini kami membuka satu siri yang akan membincangkan tentang sistem hyperconverged AERODISK vAIR yang telah kami bangunkan. Pada mulanya, kami ingin memberitahu segala-galanya dalam artikel pertama, tetapi sistemnya agak rumit, jadi kami akan memakan gajah itu di bahagian-bahagian.
Mari kita mulakan cerita dengan sejarah penciptaan sistem, menyelidiki sistem fail ARDFS, yang merupakan asas vAIR, dan juga bercakap sedikit tentang kedudukan penyelesaian ini di pasaran Rusia.
Dalam artikel akan datang kita akan bercakap dengan lebih terperinci tentang komponen seni bina yang berbeza (kelompok, hipervisor, pengimbang beban, sistem pemantauan, dll.), proses konfigurasi, menimbulkan isu pelesenan, secara berasingan menunjukkan ujian ranap dan, sudah tentu, menulis tentang ujian beban dan saiz. Kami juga akan menumpukan artikel berasingan kepada versi komuniti vAIR.
Adakah Aerodisk cerita tentang sistem storan? Atau mengapa kita mula melakukan hiperkonvergensi di tempat pertama?
Pada mulanya, idea untuk mencipta hiperkonvergensi kami sendiri datang kepada kami sekitar tahun 2010. Pada masa itu, tiada Aerodisk mahupun penyelesaian yang serupa (sistem hyperconverged kotak komersial) di pasaran. Tugas kami adalah seperti berikut: daripada satu set pelayan dengan cakera tempatan, disatukan oleh satu sambungan melalui protokol Ethernet, adalah perlu untuk mencipta storan lanjutan dan melancarkan mesin maya dan rangkaian perisian di sana. Semua ini perlu dilaksanakan tanpa sistem storan (kerana tiada wang untuk sistem storan dan perkakasannya, dan kami belum lagi mencipta sistem storan kami sendiri).
Kami mencuba banyak penyelesaian sumber terbuka dan akhirnya menyelesaikan masalah ini, tetapi penyelesaiannya sangat kompleks dan sukar untuk diulang. Selain itu, penyelesaian ini adalah dalam kategori "Adakah ia berfungsi? jangan sentuh! Oleh itu, setelah menyelesaikan masalah itu, kami tidak mengembangkan lagi idea untuk mengubah hasil kerja kami menjadi produk yang lengkap.
Selepas kejadian itu, kami beralih daripada idea ini, tetapi kami masih mempunyai perasaan bahawa masalah ini boleh diselesaikan sepenuhnya, dan faedah penyelesaian sedemikian adalah lebih jelas. Selepas itu, produk HCI syarikat asing yang dikeluarkan hanya mengesahkan perasaan ini.
Oleh itu, pada pertengahan 2016, kami kembali kepada tugas ini sebagai sebahagian daripada mencipta produk yang lengkap. Pada masa itu kami belum mempunyai sebarang hubungan dengan pelabur, jadi kami terpaksa membeli pendirian pembangunan untuk wang kami sendiri yang tidak terlalu besar. Setelah mengumpulkan pelayan terpakai dan menghidupkan Avito, kami memulakan perniagaan.
Tugas awal utama adalah untuk mencipta sistem fail kita sendiri, walaupun mudah, tetapi kita sendiri, yang boleh mengedarkan data secara automatik dan sama rata dalam bentuk blok maya pada nombor ke-n nod kluster, yang disambungkan oleh satu sambungan melalui Ethernet. Pada masa yang sama, FS harus berskala dengan baik dan mudah serta bebas daripada sistem bersebelahan, i.e. diasingkan daripada vAIR dalam bentuk "hanya kemudahan penyimpanan".
Konsep vAIR pertama
Kami sengaja meninggalkan penggunaan penyelesaian sumber terbuka siap sedia untuk mengatur storan terbentang (ceph, gluster, kilau dan seumpamanya) demi pembangunan kami sendiri, kerana kami sudah mempunyai banyak pengalaman projek dengan mereka. Sudah tentu, penyelesaian ini sendiri sangat baik, dan sebelum bekerja pada Aerodisk, kami melaksanakan lebih daripada satu projek penyepaduan dengan mereka. Tetapi adalah satu perkara untuk melaksanakan tugas khusus untuk seorang pelanggan, melatih kakitangan dan, mungkin, membeli sokongan vendor besar, dan perkara lain untuk mencipta produk yang mudah direplikasi yang akan digunakan untuk pelbagai tugas, yang kami, sebagai vendor, mungkin tahu tentang diri kita kita tidak akan. Untuk tujuan kedua, produk sumber terbuka sedia ada tidak sesuai untuk kami, jadi kami memutuskan untuk mencipta sistem fail teragih sendiri.
Dua tahun kemudian, beberapa pembangun (yang menggabungkan kerja pada vAIR dengan kerja pada sistem storan Enjin klasik) mencapai hasil tertentu.
Menjelang 2018, kami telah menulis sistem fail ringkas dan menambahnya dengan perkakasan yang diperlukan. Sistem ini menggabungkan cakera fizikal (tempatan) dari pelayan yang berbeza ke dalam satu kolam rata melalui interkoneksi dalaman dan "memotong"nya menjadi blok maya, kemudian menyekat peranti dengan pelbagai tahap toleransi kesalahan dicipta daripada blok maya, di mana yang maya dicipta dan dilaksanakan menggunakan kereta hipervisor KVM.
Kami tidak terlalu peduli dengan nama sistem fail dan dengan ringkas memanggilnya ARDFS (teka apa maksudnya))
Prototaip ini kelihatan baik (bukan visual, sudah tentu, belum ada reka bentuk visual) dan menunjukkan hasil yang baik dari segi prestasi dan skala. Selepas keputusan sebenar pertama, kami menggerakkan projek ini, mengatur persekitaran pembangunan yang lengkap dan pasukan berasingan yang hanya berurusan dengan vAIR.
Hanya pada masa itu, seni bina umum penyelesaian telah matang, yang masih belum mengalami perubahan besar.
Menyelam ke dalam sistem fail ARDFS
ARDFS ialah asas bagi vAIR, yang menyediakan storan data yang diedarkan dan tahan terhadap kesalahan merentas keseluruhan kluster. Salah satu (tetapi bukan satu-satunya) ciri tersendiri ARDFS ialah ia tidak menggunakan sebarang pelayan khusus tambahan untuk metadata dan pengurusan. Ini pada asalnya difikirkan untuk memudahkan konfigurasi penyelesaian dan untuk kebolehpercayaannya.
Struktur penyimpanan
Dalam semua nod kluster, ARDFS mengatur kumpulan logik daripada semua ruang cakera yang tersedia. Adalah penting untuk memahami bahawa kumpulan belum lagi menjadi data atau ruang yang diformatkan, tetapi hanya penanda, i.e. Mana-mana nod dengan vAIR dipasang, apabila ditambahkan pada kluster, ditambahkan secara automatik pada kumpulan ARDFS yang dikongsi dan sumber cakera secara automatik dikongsi merentas keseluruhan kluster (dan tersedia untuk storan data masa hadapan). Pendekatan ini membolehkan anda menambah dan mengalih keluar nod dengan cepat tanpa sebarang kesan serius pada sistem yang sudah berjalan. Itu. sistem ini sangat mudah untuk skala "dalam batu bata", menambah atau mengalih keluar nod dalam kelompok jika perlu.
Cakera maya (objek storan untuk mesin maya) ditambahkan di atas kumpulan ARDFS, yang dibina daripada blok maya bersaiz 4 megabait. Cakera maya menyimpan data secara langsung. Skim toleransi kesalahan juga ditetapkan pada tahap cakera maya.
Seperti yang anda mungkin telah meneka, untuk toleransi kesalahan subsistem cakera, kami tidak menggunakan konsep RAID (tatasusunan berlebihan Cakera bebas), tetapi menggunakan RAIN (tatasusunan berlebihan Nod bebas). Itu. Toleransi kesalahan diukur, diautomatikkan dan diuruskan berdasarkan nod, bukan cakera. Cakera, tentu saja, juga merupakan objek penyimpanan, mereka, seperti segala-galanya, dipantau, anda boleh melakukan semua operasi standard dengan mereka, termasuk memasang RAID perkakasan tempatan, tetapi kluster beroperasi secara khusus pada nod.
Dalam situasi di mana anda benar-benar mahukan RAID (contohnya, senario yang menyokong berbilang kegagalan pada kelompok kecil), tiada apa yang menghalang anda daripada menggunakan pengawal RAID tempatan dan membina storan terbentang dan seni bina RAIN di atas. Senario ini agak langsung dan disokong oleh kami, jadi kami akan membincangkannya dalam artikel tentang senario biasa untuk menggunakan vAIR.
Skim Toleransi Kesalahan Penyimpanan
Terdapat dua skim toleransi kesalahan untuk cakera maya dalam vAIR:
1) Faktor replikasi atau ringkasnya replikasi - kaedah toleransi kesalahan ini semudah kayu dan tali. Replikasi segerak dilakukan antara nod dengan faktor 2 (2 salinan setiap kluster) atau 3 (3 salinan, masing-masing). RF-2 membenarkan cakera maya untuk menahan kegagalan satu nod dalam kelompok, tetapi "memakan" separuh daripada volum berguna, dan RF-3 akan menahan kegagalan 2 nod dalam kelompok, tetapi menyimpan 2/3 daripada jumlah yang berguna untuk keperluannya. Skim ini sangat serupa dengan RAID-1, iaitu cakera maya yang dikonfigurasikan dalam RF-2 tahan terhadap kegagalan mana-mana satu nod dalam kelompok. Dalam kes ini, semuanya akan baik dengan data malah I/O tidak akan berhenti. Apabila nod yang jatuh kembali ke perkhidmatan, pemulihan/penyegerakan data automatik akan bermula.
Di bawah adalah contoh taburan data RF-2 dan RF-3 dalam mod biasa dan dalam situasi kegagalan.
Kami mempunyai mesin maya dengan kapasiti 8MB data unik (berguna), yang berjalan pada 4 nod vAIR. Adalah jelas bahawa pada hakikatnya tidak mungkin terdapat jumlah yang begitu kecil, tetapi untuk skema yang mencerminkan logik operasi ARDFS, contoh ini adalah yang paling mudah difahami. AB ialah blok maya 4MB yang mengandungi data mesin maya yang unik. RF-2 mencipta dua salinan blok A1+A2 dan B1+B2 ini, masing-masing. Blok ini "dibentangkan" merentasi nod, mengelakkan persilangan data yang sama pada nod yang sama, iaitu, salinan A1 tidak akan terletak pada nod yang sama dengan salinan A2. Begitu juga dengan B1 dan B2.
Jika salah satu nod gagal (contohnya, nod No. 3, yang mengandungi salinan B1), salinan ini diaktifkan secara automatik pada nod di mana tiada salinan salinannya (iaitu, salinan B2).
Oleh itu, cakera maya (dan VM, sewajarnya) boleh bertahan dengan mudah kegagalan satu nod dalam skema RF-2.
Skim replikasi, walaupun mudah dan boleh dipercayai, mengalami masalah yang sama seperti RAID1 - tidak cukup ruang yang boleh digunakan.
2) Pengekodan pemadaman atau pengekodan pemadaman (juga dikenali sebagai "pengekodan berlebihan", "pengekodan pemadaman" atau "kod redundansi") wujud untuk menyelesaikan masalah di atas. EC ialah skim redundansi yang menyediakan ketersediaan data yang tinggi dengan overhed ruang cakera yang lebih rendah berbanding replikasi. Prinsip operasi mekanisme ini serupa dengan RAID 5, 6, 6P.
Apabila pengekodan, proses EC membahagikan blok maya (4MB secara lalai) kepada beberapa "ketulan data" yang lebih kecil bergantung pada skema EC (contohnya, skema 2+1 membahagikan setiap blok 4MB kepada 2 ketulan 2MB). Seterusnya, proses ini menjana "ketul pariti" untuk "ketulan data" yang tidak lebih besar daripada salah satu bahagian yang dibahagikan sebelum ini. Apabila penyahkodan, EC menjana ketulan yang hilang dengan membaca data "bertahan" merentas keseluruhan kluster.
Sebagai contoh, cakera maya dengan skema 2 + 1 EC, dilaksanakan pada 4 nod kluster, akan mudah menahan kegagalan satu nod dalam kluster dengan cara yang sama seperti RF-2. Dalam kes ini, kos overhed akan lebih rendah, khususnya, pekali kapasiti berguna untuk RF-2 ialah 2, dan untuk EC 2+1 ia akan menjadi 1,5.
Untuk menerangkannya dengan lebih mudah, intipatinya ialah blok maya dibahagikan kepada 2-8 (mengapa dari 2 hingga 8, lihat di bawah) "kepingan", dan untuk kepingan ini "kepingan" pariti volum yang sama dikira.
Akibatnya, data dan pariti diagihkan sama rata merentas semua nod kluster. Pada masa yang sama, seperti replikasi, ARDFS secara automatik mengedarkan data di antara nod sedemikian rupa untuk mengelakkan data yang sama (salinan data dan paritinya) daripada disimpan pada nod yang sama, untuk menghapuskan peluang kehilangan data disebabkan kepada fakta bahawa data dan paritinya tiba-tiba akan berakhir pada satu nod storan yang gagal.
Di bawah ialah contoh, dengan mesin maya 8 MB dan 4 nod yang sama, tetapi dengan skema EC 2+1.
Blok A dan B dibahagikan kepada dua keping 2 MB setiap satu (dua kerana 2+1), iaitu A1+A2 dan B1+B2. Tidak seperti replika, A1 bukan salinan A2, ia adalah blok maya A, dibahagikan kepada dua bahagian, sama dengan blok B. Secara keseluruhan, kami mendapat dua set 4MB, setiap satunya mengandungi dua keping dua MB. Seterusnya, bagi setiap set ini, pariti dikira dengan volum tidak lebih daripada satu keping (iaitu 2 MB), kami memperoleh + 2 keping pariti tambahan (AP dan BP). Secara keseluruhan kami mempunyai data 4Γ2 + pariti 2Γ2.
Seterusnya, kepingan itu "dibentangkan" di antara nod supaya data tidak bersilang dengan pariti mereka. Itu. A1 dan A2 tidak akan berada pada nod yang sama dengan AP.
Sekiranya berlaku kegagalan satu nod (contohnya, juga yang ketiga), blok B1 yang jatuh akan dipulihkan secara automatik daripada pariti BP, yang disimpan pada nod No. 2, dan akan diaktifkan pada nod yang terdapat tiada B-pariti, i.e. sekeping BP. Dalam contoh ini, ini ialah nod No. 1
Saya pasti pembaca mempunyai soalan:
"Semua yang anda terangkan telah lama dilaksanakan oleh pesaing dan dalam penyelesaian sumber terbuka, apakah perbezaan antara pelaksanaan EC anda dalam ARDFS?"
Dan kemudian akan ada ciri menarik ARDFS.
Padamkan pengekodan dengan fokus pada fleksibiliti
Pada mulanya, kami menyediakan skema EC X+Y yang agak fleksibel, di mana X adalah sama dengan nombor dari 2 hingga 8, dan Y adalah sama dengan nombor dari 1 hingga 8, tetapi sentiasa kurang daripada atau sama dengan X. Skim ini disediakan untuk fleksibiliti. Meningkatkan bilangan kepingan data (X) di mana blok maya dibahagikan membolehkan mengurangkan kos overhed, iaitu, meningkatkan ruang yang boleh digunakan.
Menambah bilangan ketulan pariti (Y) meningkatkan kebolehpercayaan cakera maya. Lebih besar nilai Y, lebih banyak nod dalam kelompok boleh gagal. Sudah tentu, meningkatkan volum pariti mengurangkan jumlah kapasiti yang boleh digunakan, tetapi ini adalah harga yang perlu dibayar untuk kebolehpercayaan.
Kebergantungan prestasi pada litar EC hampir langsung: lebih banyak "kepingan", semakin rendah prestasi; di sini, sudah tentu, pandangan yang seimbang diperlukan.
Pendekatan ini membolehkan pentadbir mengkonfigurasi storan terbentang dengan fleksibiliti maksimum. Dalam kumpulan ARDFS, anda boleh menggunakan sebarang skim toleransi kesalahan dan gabungannya, yang, pada pendapat kami, juga sangat berguna.
Di bawah ialah jadual yang membandingkan beberapa (tidak semua mungkin) skim RF dan EC.
Jadual menunjukkan bahawa walaupun gabungan yang paling "terry" EC 8+7, yang membenarkan kehilangan sehingga 7 nod dalam kelompok serentak, "memakan" ruang yang kurang boleh digunakan (1,875 berbanding 2) daripada replikasi standard, dan melindungi 7 kali lebih baik , yang menjadikan mekanisme perlindungan ini, walaupun lebih kompleks, jauh lebih menarik dalam situasi yang diperlukan untuk memastikan kebolehpercayaan maksimum dalam keadaan ruang cakera yang terhad. Pada masa yang sama, anda perlu memahami bahawa setiap "tambah" kepada X atau Y akan menjadi overhed prestasi tambahan, jadi dalam segi tiga antara kebolehpercayaan, penjimatan dan prestasi anda perlu memilih dengan berhati-hati. Atas sebab ini, kami akan menumpukan artikel berasingan untuk memadamkan saiz pengekodan.
Kebolehpercayaan dan autonomi sistem fail
ARDFS berjalan secara setempat pada semua nod kluster dan menyegerakkannya menggunakan caranya sendiri melalui antara muka Ethernet khusus. Perkara penting ialah ARDFS secara bebas menyegerakkan bukan sahaja data, tetapi juga metadata yang berkaitan dengan storan. Semasa mengusahakan ARDFS, kami secara serentak mengkaji beberapa penyelesaian sedia ada dan kami mendapati bahawa banyak menyegerakkan meta sistem fail menggunakan DBMS teragih luaran, yang juga kami gunakan untuk penyegerakan, tetapi hanya konfigurasi, bukan metadata FS (mengenai ini dan subsistem lain yang berkaitan dalam artikel seterusnya).
Menyegerakkan metadata FS menggunakan DBMS luaran, sudah tentu, penyelesaian yang berkesan, tetapi kemudiannya ketekalan data yang disimpan pada ARDFS akan bergantung pada DBMS luaran dan kelakuannya (dan, terus terang, ia adalah seorang wanita yang berubah-ubah), yang dalam buruk pendapat kami. kenapa? Jika metadata FS rosak, data FS itu sendiri juga boleh dikatakan "selamat tinggal", jadi kami memutuskan untuk mengambil jalan yang lebih kompleks tetapi boleh dipercayai.
Kami membuat subsistem penyegerakan metadata untuk ARDFS sendiri, dan ia hidup sepenuhnya bebas daripada subsistem bersebelahan. Itu. tiada subsistem lain boleh merosakkan data ARDFS. Pada pendapat kami, ini adalah cara yang paling boleh dipercayai dan betul, tetapi masa akan menentukan sama ada ini sebenarnya begitu. Di samping itu, terdapat kelebihan tambahan dengan pendekatan ini. ARDFS boleh digunakan secara bebas daripada vAIR, sama seperti storan terbentang, yang pastinya kami akan gunakan dalam produk akan datang.
Hasilnya, dengan membangunkan ARDFS, kami menerima sistem fail yang fleksibel dan boleh dipercayai yang memberikan pilihan di mana anda boleh menjimatkan kapasiti atau menyerahkan segala-galanya pada prestasi, atau membuat storan sangat boleh dipercayai pada kos yang berpatutan, tetapi mengurangkan keperluan prestasi.
Bersama-sama dengan dasar pelesenan yang mudah dan model penghantaran yang fleksibel (melihat ke hadapan, vAIR dilesenkan oleh nod dan dihantar sama ada sebagai perisian atau sebagai pakej perisian), ini membolehkan anda menyesuaikan penyelesaian dengan sangat tepat kepada pelbagai keperluan pelanggan dan maka dengan mudah mengekalkan keseimbangan ini.
Siapa yang memerlukan keajaiban ini?
Di satu pihak, kita boleh mengatakan bahawa sudah ada pemain di pasaran yang mempunyai penyelesaian serius dalam bidang hiperkonvergensi, dan ini adalah ke mana kita sebenarnya menuju. Nampaknya kenyataan ini benar, TAPI...
Sebaliknya, apabila kami keluar ke padang dan berkomunikasi dengan pelanggan, kami dan rakan kongsi kami melihat bahawa ini tidak berlaku sama sekali. Terdapat banyak tugas untuk hiperkonvergensi, di sesetengah tempat orang hanya tidak tahu bahawa penyelesaian sedemikian wujud, di tempat lain ia kelihatan mahal, di tempat lain terdapat ujian penyelesaian alternatif yang tidak berjaya, dan di tempat lain mereka melarang membeli sama sekali kerana sekatan. Secara umum, ladang itu ternyata tidak dibajak, jadi kami pergi untuk menaikkan tanah dara))).
Bilakah sistem storan lebih baik daripada GKS?
Semasa kami bekerja dengan pasaran, kami sering ditanya bila lebih baik menggunakan skema klasik dengan sistem storan, dan bila menggunakan hiperkonvergen? Banyak syarikat yang mengeluarkan GCS (terutamanya yang tidak mempunyai sistem storan dalam portfolio mereka) berkata: "Sistem storan menjadi usang, hiperkonvergen sahaja!" Ini adalah kenyataan yang berani, tetapi ia tidak sepenuhnya mencerminkan realiti.
Sebenarnya, pasaran storan sememangnya bergerak ke arah hiperkonvergensi dan penyelesaian yang serupa, tetapi sentiasa ada "tetapi".
Pertama, pusat data dan infrastruktur IT yang dibina mengikut skema klasik dengan sistem storan tidak boleh dibina semula dengan mudah, jadi pemodenan dan penyiapan infrastruktur tersebut masih menjadi warisan selama 5-7 tahun.
Kedua, infrastruktur yang sedang dibina untuk sebahagian besar (bermaksud Persekutuan Rusia) dibina mengikut skema klasik menggunakan sistem storan, dan bukan kerana orang tidak tahu tentang hiperkonvergensi, tetapi kerana pasaran hiperkonvergensi adalah baru, penyelesaian dan standard belum diwujudkan , orang IT belum terlatih, mereka mempunyai sedikit pengalaman, tetapi mereka perlu membina pusat data di sini dan sekarang. Dan trend ini akan bertahan selama 3-5 tahun lagi (dan kemudian warisan lain, lihat titik 1).
Ketiga, terdapat had teknikal semata-mata dalam kelewatan kecil tambahan sebanyak 2 milisaat setiap tulis (tidak termasuk cache setempat, sudah tentu), yang merupakan kos storan teragih.
Nah, jangan lupa tentang penggunaan pelayan fizikal besar yang menyukai penskalaan menegak subsistem cakera.
Terdapat banyak tugas yang perlu dan popular di mana sistem storan berkelakuan lebih baik daripada GCS. Di sini, sudah tentu, pengeluar yang tidak mempunyai sistem storan dalam portfolio produk mereka tidak akan bersetuju dengan kami, tetapi kami bersedia untuk berhujah dengan munasabah. Sudah tentu, kami, sebagai pembangun kedua-dua produk, pasti akan membandingkan sistem storan dan GCS dalam salah satu penerbitan masa hadapan kami, di mana kami akan menunjukkan dengan jelas mana yang lebih baik dalam keadaan apa.
Dan di manakah penyelesaian hiperkonvergen berfungsi lebih baik daripada sistem storan?
Berdasarkan perkara di atas, tiga kesimpulan yang jelas boleh dibuat:
- Di mana tambahan 2 milisaat kependaman untuk rakaman, yang secara konsisten berlaku dalam mana-mana produk (kini kita tidak bercakap tentang sintetik, nanosaat boleh ditunjukkan pada sintetik), adalah tidak kritikal, hiperkonvergen adalah sesuai.
- Di mana beban daripada pelayan fizikal yang besar boleh diubah menjadi banyak maya kecil dan diedarkan di antara nod, hiperkonvergensi juga akan berfungsi dengan baik di sana.
- Apabila penskalaan mendatar adalah keutamaan yang lebih tinggi daripada penskalaan menegak, GCS akan berfungsi dengan baik di sana juga.
Apakah penyelesaian ini?
- Semua perkhidmatan infrastruktur standard (perkhidmatan direktori, mel, EDMS, pelayan fail, sistem ERP dan BI kecil atau sederhana, dsb.). Kami memanggil ini "pengkomputeran am."
- Infrastruktur penyedia awan, di mana ia perlu dengan cepat dan diseragamkan secara mendatar mengembangkan dan dengan mudah "memotong" sejumlah besar mesin maya untuk pelanggan.
- Infrastruktur desktop maya (VDI), di mana banyak mesin maya pengguna kecil berjalan dan "terapung" secara senyap dalam kelompok seragam.
- Rangkaian cawangan, di mana setiap cawangan memerlukan infrastruktur standard, toleran kesalahan, tetapi murah sebanyak 15-20 mesin maya.
- Sebarang pengkomputeran teragih (contohnya perkhidmatan data besar). Di mana beban pergi bukan "dalam", tetapi "dalam keluasan".
- Persekitaran ujian di mana kelewatan kecil tambahan boleh diterima, tetapi terdapat sekatan belanjawan, kerana ini adalah ujian.
Pada masa ini, untuk tugasan inilah kami telah membuat AERODISK vAIR dan pada tugasan itulah kami memberi tumpuan (berjaya setakat ini). Mungkin ini akan berubah tidak lama lagi, kerana... dunia tidak berdiam diri.
Oleh itu ...
Ini melengkapkan bahagian pertama siri artikel yang besar; dalam artikel seterusnya kita akan bercakap tentang seni bina penyelesaian dan komponen yang digunakan.
Kami mengalu-alukan soalan, cadangan dan pertikaian yang membina.
Sumber: www.habr.com