Habari, wasomaji wa Habr. Kwa makala hii tunafungua mfululizo ambao utazungumzia juu ya mfumo wa hyperconverged AERODISK vAIR ambao tumeanzisha. Hapo awali, tulitaka kusema kila kitu juu ya kila kitu katika kifungu cha kwanza, lakini mfumo ni ngumu sana, kwa hivyo tutakula tembo kwa sehemu.
Wacha tuanze hadithi na historia ya uundaji wa mfumo, jishughulishe na mfumo wa faili wa ARDFS, ambayo ni msingi wa vAIR, na pia tuzungumze kidogo juu ya uwekaji wa suluhisho hili kwenye soko la Urusi.
Katika makala zijazo tutazungumza kwa undani zaidi kuhusu vipengele tofauti vya usanifu (nguzo, hypervisor, mizani ya mizigo, mfumo wa ufuatiliaji, nk), mchakato wa usanidi, kuibua masuala ya leseni, kuonyesha majaribio ya kuacha kufanya kazi na, bila shaka, kuandika kuhusu kupima mzigo na. ukubwa. Pia tutatoa nakala tofauti kwa toleo la jamii la vAIR.
Je, Aerodisk ni hadithi kuhusu mifumo ya uhifadhi? Au kwa nini tulianza kufanya hyperconvergence katika nafasi ya kwanza?
Hapo awali, wazo la kuunda hyperconvergence yetu wenyewe lilitujia mahali pengine karibu 2010. Wakati huo, hakukuwa na Aerodisk au suluhu sawa (mifumo ya biashara iliyo na sanduku zilizounganishwa) kwenye soko. Kazi yetu ilikuwa ifuatayo: kutoka kwa seti ya seva zilizo na diski za ndani, zilizounganishwa na unganisho kupitia itifaki ya Ethernet, ilikuwa ni lazima kuunda hifadhi iliyopanuliwa na kuzindua mashine za kawaida na mtandao wa programu huko. Yote haya yalipaswa kutekelezwa bila mifumo ya uhifadhi (kwa sababu hapakuwa na pesa tu kwa mifumo ya uhifadhi na vifaa vyake, na bado hatujaunda mifumo yetu ya uhifadhi).
Tulijaribu suluhisho nyingi za chanzo wazi na hatimaye tukatatua shida hii, lakini suluhisho lilikuwa ngumu sana na ngumu kurudia. Mbali na hilo, suluhisho hili lilikuwa katika kitengo cha "Je! Inafanya kazi? Usiguse! Kwa hivyo, baada ya kusuluhisha shida hiyo, hatukukuza zaidi wazo la kubadilisha matokeo ya kazi yetu kuwa bidhaa kamili.
Baada ya tukio hilo, tuliondoka kwenye wazo hili, lakini bado tulikuwa na hisia kwamba tatizo hili lilikuwa na ufumbuzi kabisa, na faida za ufumbuzi huo zilikuwa zaidi ya dhahiri. Baadaye, bidhaa za HCI zilizotolewa za makampuni ya kigeni zilithibitisha tu hisia hii.
Kwa hivyo, katikati ya 2016, tulirudi kwenye kazi hii kama sehemu ya kuunda bidhaa kamili. Wakati huo bado hatukuwa na uhusiano wowote na wawekezaji, kwa hivyo ilitubidi tununue stendi ya maendeleo kwa pesa zetu sio kubwa sana. Baada ya kukusanya seva zilizotumiwa na swichi kwenye Avito, tuliingia kwenye biashara.
Kazi kuu ya awali ilikuwa kuunda yetu wenyewe, ingawa rahisi, lakini mfumo wetu wa faili, ambao unaweza moja kwa moja na sawasawa kusambaza data katika mfumo wa vitalu vya kawaida kwenye nambari ya nth ya nodi za nguzo, ambazo zimeunganishwa na muunganisho kupitia Ethernet. Wakati huo huo, FS inapaswa kupima vizuri na kwa urahisi na kujitegemea mifumo ya karibu, i.e. kutengwa na VAIR kwa njia ya "kituo cha kuhifadhi tu".
Dhana ya kwanza ya VAIR
Tuliachana kimakusudi utumiaji wa suluhu za chanzo wazi zilizotengenezwa tayari kwa ajili ya kuandaa uhifadhi uliopanuliwa (ceph, gluster, luster na kadhalika) kwa ajili ya maendeleo yetu wenyewe, kwani tayari tulikuwa na uzoefu mwingi wa mradi nao. Bila shaka, ufumbuzi huu wenyewe ni bora, na kabla ya kufanya kazi kwenye Aerodisk, tulitekeleza mradi wa ushirikiano zaidi ya mmoja nao. Lakini ni jambo moja kutekeleza kazi maalum kwa mteja mmoja, wafanyikazi wa mafunzo na, labda, kununua msaada wa muuzaji mkubwa, na jambo lingine kabisa kuunda bidhaa iliyoigwa kwa urahisi ambayo itatumika kwa kazi anuwai, ambayo sisi, kama muuzaji, anaweza hata kujua kuhusu sisi wenyewe hatuwezi. Kwa madhumuni ya pili, bidhaa zilizopo za chanzo wazi hazikufaa kwetu, kwa hiyo tuliamua kuunda mfumo wa faili uliosambazwa sisi wenyewe.
Miaka miwili baadaye, watengenezaji kadhaa (ambao walichanganya kazi kwenye vAIR na kazi kwenye mfumo wa uhifadhi wa Injini wa kawaida) walipata matokeo fulani.
Kufikia 2018, tuliandika mfumo rahisi wa faili na tukaiongezea na vifaa muhimu. Mfumo uliunganisha diski za kimwili (za ndani) kutoka kwa seva tofauti hadi kwenye bwawa moja la gorofa kupitia muunganisho wa ndani na "kuzikata" kwenye vizuizi halisi, kisha vifaa vya kuzuia vilivyo na viwango tofauti vya uvumilivu wa makosa viliundwa kutoka kwa vitalu dhahania, ambapo zile za mtandaoni ziliundwa. na kutekelezwa kwa kutumia magari ya KVM hypervisor.
Hatukujisumbua sana na jina la mfumo wa faili na kwa ufupi tukauita ARDFS (nadhani inawakilisha nini))
Mfano huu ulionekana mzuri (sio kuibua, bila shaka, hapakuwa na muundo wa kuona bado) na ulionyesha matokeo mazuri katika suala la utendaji na kuongeza. Baada ya matokeo halisi ya kwanza, tulianzisha mradi huu, tukiandaa mazingira kamili ya maendeleo na timu tofauti ambayo ilishughulikia vAIR pekee.
Wakati huo tu, usanifu wa jumla wa suluhisho ulikuwa umekomaa, ambao bado haujapata mabadiliko makubwa.
Kuingia kwenye mfumo wa faili wa ARDFS
ARDFS ndio msingi wa vAIR, ambayo hutoa hifadhi ya data iliyosambazwa, inayostahimili hitilafu katika kundi zima. Mojawapo ya (lakini si pekee) vipengele bainifu vya ARDFS ni kwamba haitumii seva zozote za ziada zilizojitolea kwa metadata na usimamizi. Hapo awali, hii iliundwa ili kurahisisha usanidi wa suluhisho na kuegemea kwake.
Muundo wa uhifadhi
Ndani ya nodi zote za nguzo, ARDFS hupanga bwawa la kimantiki kutoka kwa nafasi zote za diski zinazopatikana. Ni muhimu kuelewa kwamba bwawa bado sio data au nafasi iliyopangwa, lakini tu markup, i.e. Vifundo vyovyote vilivyo na vAIR vilivyosakinishwa, vinapoongezwa kwenye nguzo, huongezwa kiotomatiki kwenye hifadhi ya ARDFS iliyoshirikiwa na rasilimali za diski hushirikiwa kiotomatiki kwenye kundi zima (na kupatikana kwa hifadhi ya data siku zijazo). Njia hii hukuruhusu kuongeza na kuondoa nodi kwenye nzi bila athari kubwa kwenye mfumo unaoendesha tayari. Wale. Mfumo ni rahisi sana kwa kiwango "katika matofali", kuongeza au kuondoa nodes katika nguzo ikiwa ni lazima.
Diski za kweli (vitu vya kuhifadhi kwa mashine za kawaida) huongezwa juu ya bwawa la ARDFS, ambalo limejengwa kutoka kwa vitalu vya kawaida vya megabytes 4 kwa ukubwa. Disks halisi huhifadhi data moja kwa moja. Mpango wa uvumilivu wa kosa pia umewekwa kwenye kiwango cha disk virtual.
Kama unavyoweza kuwa tayari umekisia, kwa uvumilivu wa makosa ya mfumo mdogo wa diski, hatutumii dhana ya RAID (safu isiyo ya kawaida ya Diski zinazojitegemea), lakini tumia RAIN (Safu isiyohitajika ya Nodi huru). Wale. Uvumilivu wa hitilafu hupimwa, kiotomatiki, na kudhibitiwa kulingana na nodi, sio diski. Disks, bila shaka, pia ni kitu cha kuhifadhi, wao, kama kila kitu kingine, hufuatiliwa, unaweza kufanya shughuli zote za kawaida pamoja nao, ikiwa ni pamoja na kukusanya RAID ya vifaa vya ndani, lakini nguzo hufanya kazi hasa kwenye nodes.
Katika hali ambayo unataka sana RAID (kwa mfano, hali ambayo inasaidia kushindwa nyingi kwenye vikundi vidogo), hakuna kinachokuzuia kutumia vidhibiti vya RAID vya ndani, na kujenga hifadhi iliyopanuliwa na usanifu wa RAIN juu. Hali hii ni ya moja kwa moja na inaungwa mkono na sisi, kwa hivyo tutazungumza juu yake katika nakala kuhusu hali za kawaida za kutumia vAIR.
Mipango ya Kuvumilia Makosa ya Uhifadhi
Kunaweza kuwa na miradi miwili ya kuvumilia makosa kwa diski za kawaida katika vAIR:
1) Kipengele cha kurudia au kurudia kwa urahisi - njia hii ya uvumilivu wa makosa ni rahisi kama fimbo na kamba. Urudiaji wa usawazishaji unafanywa kati ya nodi na kipengele cha 2 (nakala 2 kwa kila kundi) au 3 (nakala 3, mtawalia). RF-2 inaruhusu diski ya kawaida kuhimili kutofaulu kwa nodi moja kwenye nguzo, lakini "hula" nusu ya kiasi muhimu, na RF-3 itahimili kutofaulu kwa nodi 2 kwenye nguzo, lakini inahifadhi 2/3 ya kiasi muhimu kwa mahitaji yake. Mpango huu ni sawa na RAID-1, yaani, diski ya kawaida iliyosanidiwa katika RF-2 inakabiliwa na kushindwa kwa nodi yoyote kwenye nguzo. Katika kesi hii, kila kitu kitakuwa sawa na data na hata I / O haitaacha. Wakati nodi iliyoanguka inarudi kwenye huduma, urejeshaji wa data otomatiki / maingiliano itaanza.
Chini ni mifano ya usambazaji wa data ya RF-2 na RF-3 katika hali ya kawaida na katika hali ya kushindwa.
Tuna mashine pepe yenye uwezo wa 8MB ya data ya kipekee (muhimu), inayotumia nodi 4 za vAIR. Ni wazi kwamba kwa kweli hakuna uwezekano kwamba kutakuwa na kiasi kidogo, lakini kwa mpango unaoonyesha mantiki ya uendeshaji wa ARDFS, mfano huu unaeleweka zaidi. AB ni vizuizi pepe vya MB 4 vilivyo na data ya kipekee ya mashine. RF-2 huunda nakala mbili za vitalu hivi A1+A2 na B1+B2, kwa mtiririko huo. Vitalu hivi "vimewekwa" kwenye nodi zote, kuzuia makutano ya data sawa kwenye nodi sawa, yaani, nakala ya A1 haitapatikana kwenye nodi sawa na nakala A2. Sawa na B1 na B2.
Ikiwa moja ya nodes inashindwa (kwa mfano, node No. 3, ambayo ina nakala ya B1), nakala hii inawashwa moja kwa moja kwenye node ambapo hakuna nakala ya nakala yake (yaani, nakala ya B2).
Kwa hivyo, diski ya kawaida (na VM, ipasavyo) inaweza kuishi kwa urahisi kutofaulu kwa nodi moja kwenye mpango wa RF-2.
Mpango wa kurudia, wakati ni rahisi na wa kuaminika, unakabiliwa na tatizo sawa na RAID1 - haitoshi nafasi inayoweza kutumika.
2) Uwekaji usimbaji wa kufuta au uwekaji wa kufuta (pia unajulikana kama "usimbaji usiohitajika", "usimbaji wa kufuta" au "msimbo wa kufuta tena") unapatikana ili kutatua tatizo lililo hapo juu. EC ni mpango wa upunguzaji wa data ambao hutoa upatikanaji wa juu wa data na nafasi ya chini ya diski ikilinganishwa na replication. Kanuni ya uendeshaji wa utaratibu huu ni sawa na RAID 5, 6, 6P.
Wakati wa kusimba, mchakato wa EC hugawanya kizuizi pepe (4MB kwa chaguo-msingi) katika "visehemu vya data" kadhaa kulingana na mpango wa EC (kwa mfano, mpango wa 2+1 hugawanya kila kizuizi cha 4MB katika vipande 2 2MB). Ifuatayo, mchakato huu hutoa "vipande vya usawa" kwa "visehemu vya data" ambavyo si kubwa kuliko sehemu moja iliyogawanywa hapo awali. Wakati wa kusimbua, EC hutengeneza vipande vilivyokosekana kwa kusoma data "iliyosalia" kwenye nguzo nzima.
Kwa mfano, disk virtual na mpango 2 + 1 EC, kutekelezwa kwenye nodes 4 nguzo, kwa urahisi kuhimili kushindwa kwa node moja katika nguzo kwa njia sawa na RF-2. Katika kesi hii, gharama za juu zitakuwa za chini, hasa, mgawo wa uwezo muhimu kwa RF-2 ni 2, na kwa EC 2 + 1 itakuwa 1,5.
Ili kuelezea kwa urahisi zaidi, kiini ni kwamba block virtual imegawanywa katika 2-8 (kwa nini kutoka 2 hadi 8, angalia chini) "vipande", na kwa vipande hivi "vipande" vya usawa wa kiasi sawa huhesabiwa.
Kama matokeo, data na usawa husambazwa sawasawa katika nodi zote za nguzo. Wakati huo huo, kama ilivyo kwa kurudia, ARDFS inasambaza data kiotomatiki kati ya nodi kwa njia ya kuzuia data inayofanana (nakala za data na usawa wao) kuhifadhiwa kwenye nodi moja, ili kuondoa nafasi ya kupoteza data inayostahili. kwa ukweli kwamba data na usawa wao zitaishia ghafla kwenye nodi moja ya uhifadhi ambayo itashindwa.
Chini ni mfano, na mashine sawa ya 8 MB na nodi 4, lakini kwa mpango wa EC 2 + 1.
Vitalu A na B vimegawanywa katika vipande viwili vya MB 2 kila moja (mbili kwa sababu 2+1), yaani, A1+A2 na B1+B2. Tofauti na replica, A1 si nakala ya A2, ni block virtual A, imegawanywa katika sehemu mbili, sawa na block B. Kwa jumla, tunapata seti mbili za 4MB, ambayo kila moja ina vipande viwili vya MB mbili. Ifuatayo, kwa kila seti hizi, usawa huhesabiwa kwa kiasi cha si zaidi ya kipande kimoja (yaani 2 MB), tunapata ziada + 2 vipande vya usawa (AP na BP). Kwa jumla tuna data 4 × 2 + 2 × 2 usawa.
Ifuatayo, vipande "vimewekwa" kati ya nodes ili data isiingie na usawa wao. Wale. A1 na A2 hazitakuwa kwenye nodi sawa na AP.
Katika tukio la kushindwa kwa node moja (kwa mfano, pia ya tatu), block iliyoanguka B1 itarejeshwa moja kwa moja kutoka kwa usawa wa BP, ambayo imehifadhiwa kwenye node Nambari 2, na itaanzishwa kwenye node ambapo kuna. hakuna B-usawa, i.e. kipande cha BP. Katika mfano huu, hii ni nodi No
Nina hakika msomaji ana swali:
"Kila kitu ulichoelezea kwa muda mrefu kimetekelezwa na washindani na katika suluhisho la chanzo huria, kuna tofauti gani kati ya utekelezaji wako wa EC katika ARDFS?"
Na kisha kutakuwa na vipengele vya kuvutia vya ARDFS.
Futa usimbaji kwa kuzingatia kunyumbulika
Hapo awali, tulitoa mpango wa EC X+Y unaonyumbulika, ambapo X ni sawa na nambari kutoka 2 hadi 8, na Y ni sawa na nambari kutoka 1 hadi 8, lakini kila mara ni chini ya au sawa na X. Mpango huu umetolewa. kwa kubadilika. Kuongeza idadi ya vipande vya data (X) ambamo block virtual imegawanywa inaruhusu kupunguza gharama za juu, yaani, kuongeza nafasi inayoweza kutumika.
Kuongeza idadi ya vipande vya usawa (Y) huongeza kuegemea kwa diski ya kawaida. Thamani kubwa ya Y, nodi nyingi kwenye nguzo zinaweza kushindwa. Bila shaka, kuongeza kiasi cha usawa hupunguza kiasi cha uwezo unaoweza kutumika, lakini hii ni bei ya kulipa kwa kuaminika.
Utegemezi wa utendaji kwenye mizunguko ya EC ni karibu moja kwa moja: "vipande" zaidi, ndivyo utendaji wa chini; hapa, bila shaka, mtazamo wa usawa unahitajika.
Mbinu hii inaruhusu wasimamizi kusanidi hifadhi iliyopanuliwa na kunyumbulika kwa kiwango cha juu zaidi. Ndani ya bwawa la ARDFS, unaweza kutumia mipango yoyote ya uvumilivu wa makosa na mchanganyiko wao, ambayo, kwa maoni yetu, pia ni muhimu sana.
Chini ni jedwali linalolinganisha mipango kadhaa (siyo yote inayowezekana) RF na EC.
Jedwali linaonyesha kuwa hata mchanganyiko wa "terry" zaidi EC 8+7, ambayo inaruhusu kupoteza hadi nodi 7 kwenye nguzo wakati huo huo, "hula" nafasi isiyoweza kutumika (1,875 dhidi ya 2) kuliko uigaji wa kawaida, na inalinda mara 7 bora. , ambayo hufanya utaratibu huu wa ulinzi, ingawa ni ngumu zaidi, kuvutia zaidi katika hali ambapo ni muhimu kuhakikisha kuegemea kwa kiwango cha juu katika hali ya nafasi ndogo ya diski. Wakati huo huo, unahitaji kuelewa kwamba kila "plus" hadi X au Y itakuwa kazi ya ziada ya ziada, kwa hiyo katika pembetatu kati ya kuegemea, akiba na utendaji unahitaji kuchagua kwa makini sana. Kwa sababu hii, tutatoa nakala tofauti ili kufuta ukubwa wa usimbaji.
Kuegemea na uhuru wa mfumo wa faili
ARDFS huendesha ndani ya nodi zote za nguzo na kuzisawazisha kwa kutumia njia zake kupitia miingiliano maalum ya Ethaneti. Jambo muhimu ni kwamba ARDFS hailinganishi data tu, bali pia metadata inayohusiana na uhifadhi. Tulipokuwa tukifanya kazi kwenye ARDFS, tulisoma kwa wakati mmoja idadi ya masuluhisho yaliyopo na tukagundua kuwa nyingi husawazisha meta ya mfumo wa faili kwa kutumia DBMS iliyosambazwa nje, ambayo sisi pia tunaitumia kusawazisha, lakini usanidi pekee, sio metadata ya FS (kuhusu hii na mifumo mingine midogo inayohusiana. katika makala inayofuata).
Kusawazisha metadata ya FS kwa kutumia DBMS ya nje ni, kwa kweli, suluhisho la kufanya kazi, lakini basi uthabiti wa data iliyohifadhiwa kwenye ARDFS itategemea DBMS ya nje na tabia yake (na, kusema ukweli, ni mwanamke asiye na maana), ambaye maoni yetu ni mabaya. Kwa nini? Ikiwa metadata ya FS itaharibiwa, data ya FS yenyewe inaweza pia kusemwa "kwaheri," kwa hivyo tuliamua kuchukua njia ngumu zaidi lakini ya kuaminika.
Tulitengeneza mfumo mdogo wa ulandanishi wa metadata wa ARDFS wenyewe, na unaishi bila kutegemea mifumo ndogo iliyo karibu. Wale. hakuna mfumo mwingine mdogo unaweza kuharibu data ya ARDFS. Kwa maoni yetu, hii ndiyo njia ya kuaminika na sahihi, lakini wakati utasema ikiwa hii ni kweli. Kwa kuongeza, kuna faida ya ziada na njia hii. ARDFS inaweza kutumika kwa kujitegemea kwa vAIR, kama hifadhi iliyopanuliwa, ambayo hakika tutatumia katika bidhaa za baadaye.
Kwa hivyo, kwa kutengeneza ARDFS, tulipokea mfumo wa faili unaonyumbulika na unaotegemewa ambao hutoa chaguo ambapo unaweza kuhifadhi ukitumia kiasi au kuacha kila kitu kutokana na utendakazi, au kutengeneza hifadhi inayotegemewa kwa gharama nafuu, lakini kupunguza mahitaji ya utendaji.
Pamoja na sera rahisi ya leseni na mtindo wa uwasilishaji unaonyumbulika (kuangalia mbele, vAIR imeidhinishwa na nodi, na kuwasilishwa kama programu au kama kifurushi cha programu), hii inakuruhusu kurekebisha kwa usahihi suluhisho kwa anuwai ya mahitaji ya wateja na. kisha kudumisha usawa huu kwa urahisi.
Nani anahitaji muujiza huu?
Kwa upande mmoja, tunaweza kusema kwamba tayari kuna wachezaji kwenye soko ambao wana suluhisho kubwa katika uwanja wa hyperconvergence, na hapa ndipo tunapoelekea. Inaonekana kwamba kauli hii ni kweli, LAKINI...
Kwa upande mwingine, tunapoenda shambani na kuwasiliana na wateja, sisi na washirika wetu tunaona kwamba hii sivyo kabisa. Kuna kazi nyingi za hyperconvergence, katika sehemu zingine watu hawakujua tu kuwa suluhisho kama hizo zipo, kwa zingine zilionekana kuwa ghali, kwa zingine kulikuwa na majaribio yasiyofanikiwa ya suluhisho mbadala, na kwa zingine hukataza kununua kabisa kwa sababu ya vikwazo. Kwa ujumla, shamba liligeuka kuwa halijapandwa, kwa hiyo tulikwenda kuinua udongo wa bikira))).
Je, ni wakati gani mfumo wa kuhifadhi ni bora kuliko GKS?
Tunapofanya kazi na soko, mara nyingi tunaulizwa wakati ni bora kutumia mpango wa classic na mifumo ya kuhifadhi, na wakati wa kutumia hyperconvergent? Kampuni nyingi zinazozalisha GCS (haswa zile ambazo hazina mifumo ya kuhifadhi kwenye kwingineko zao) zinasema: "Mifumo ya uhifadhi inazidi kuwa ya kizamani, imeunganishwa tu!" Hii ni kauli ya kijasiri, lakini haionyeshi ukweli kabisa.
Kwa kweli, soko la uhifadhi linaelekea kwenye hyperconvergence na ufumbuzi sawa, lakini daima kuna "lakini".
Kwanza, vituo vya data na miundombinu ya IT iliyojengwa kulingana na mpango wa zamani na mifumo ya uhifadhi haiwezi kujengwa upya kwa urahisi, kwa hivyo uboreshaji na ukamilishaji wa miundombinu kama hiyo bado ni urithi kwa miaka 5-7.
Pili, miundombinu ambayo kwa sasa inajengwa kwa sehemu kubwa (ikimaanisha Shirikisho la Urusi) imejengwa kulingana na mpango wa zamani kwa kutumia mifumo ya uhifadhi, na sio kwa sababu watu hawajui juu ya hyperconvergence, lakini kwa sababu soko la hyperconvergence ni mpya, suluhisho na suluhisho. viwango bado hazijaanzishwa , Watu wa IT bado hawajafunzwa, wana uzoefu mdogo, lakini wanahitaji kujenga vituo vya data hapa na sasa. Na hali hii itaendelea kwa miaka 3-5 nyingine (na kisha urithi mwingine, angalia hatua ya 1).
Tatu, kuna kizuizi cha kiufundi katika ucheleweshaji mdogo wa ziada wa milisekunde 2 kwa kila uandishi (bila kujumuisha akiba ya ndani, bila shaka), ambayo ni gharama ya uhifadhi uliosambazwa.
Naam, tusisahau kuhusu matumizi ya seva kubwa za kimwili ambazo zinapenda kuongeza wima ya mfumo mdogo wa disk.
Kuna kazi nyingi muhimu na maarufu ambapo mifumo ya uhifadhi hufanya kazi bora kuliko GCS. Hapa, bila shaka, wale wazalishaji ambao hawana mifumo ya kuhifadhi katika kwingineko ya bidhaa zao hawatakubaliana na sisi, lakini tuko tayari kubishana kwa sababu. Bila shaka, sisi, kama watengenezaji wa bidhaa zote mbili, bila shaka tutalinganisha mifumo ya hifadhi na GCS katika mojawapo ya machapisho yetu yajayo, ambapo tutaonyesha kwa uwazi ambayo ni bora chini ya hali gani.
Na ni wapi suluhisho za hyperconverged zitafanya kazi vizuri zaidi kuliko mifumo ya uhifadhi?
Kulingana na vidokezo hapo juu, hitimisho tatu dhahiri zinaweza kutolewa:
- Ambapo milisekunde 2 ya ziada ya latency ya kurekodi, ambayo hutokea mara kwa mara katika bidhaa yoyote (sasa hatuzungumzi juu ya synthetics, nanoseconds inaweza kuonyeshwa kwenye synthetics), sio muhimu, hyperconvergent inafaa.
- Ambapo mzigo kutoka kwa seva kubwa za kimwili zinaweza kugeuzwa kuwa ndogo nyingi na kusambazwa kati ya nodi, hyperconvergence pia itafanya kazi vizuri huko.
- Ambapo kuongeza mlalo ni kipaumbele cha juu kuliko kuongeza wima, GCS itafanya vizuri huko pia.
Masuluhisho haya ni yapi?
- Huduma zote za miundombinu ya kawaida (huduma ya saraka, barua, EDMS, seva za faili, mifumo ndogo au ya kati ya ERP na BI, nk). Tunaita hii "kompyuta ya jumla."
- Miundombinu ya watoa huduma wa wingu, ambapo inahitajika kupanua haraka na kusawazisha kwa usawa na "kukata" kwa urahisi idadi kubwa ya mashine za kawaida kwa wateja.
- Miundombinu ya kompyuta ya mezani (VDI), ambapo mashine nyingi za watumiaji ndogo huendesha na "kuelea" kimya kimya ndani ya nguzo moja.
- Mitandao ya tawi, ambapo kila tawi linahitaji miundombinu ya kawaida, isiyo na makosa, lakini isiyo na gharama ya mashine 15-20 za kawaida.
- Kompyuta yoyote iliyosambazwa (huduma kubwa za data, kwa mfano). Ambapo mzigo hauendi "kwa kina", lakini "kwa upana".
- Mazingira ya majaribio ambapo ucheleweshaji mdogo wa ziada unakubalika, lakini kuna vikwazo vya bajeti, kwa sababu haya ni majaribio.
Kwa sasa, ni kwa ajili ya kazi hizi ambazo tumefanya AERODISK vAIR na ni juu yao ambayo tunazingatia (imefanikiwa hadi sasa). Labda hii itabadilika hivi karibuni, kwa sababu ... ulimwengu hausimami.
Hivyo…
Hii inakamilisha sehemu ya kwanza ya safu kubwa ya vifungu; katika makala inayofuata tutazungumza juu ya usanifu wa suluhisho na vifaa vinavyotumiwa.
Tunakaribisha maswali, mapendekezo na mizozo yenye kujenga.
Chanzo: mapenzi.com