Салам, Habr окурмандары. Бул макалада биз иштеп чыккан AERODISK vAIR гиперконвергендик системасы жөнүндө сөз кыла турган серияны ачабыз. Башында, биз биринчи макалада бардыгы жөнүндө баарын айткыбыз келген, бирок система абдан татаал, ошондуктан пилди бөлүктөргө бөлүп жейбиз.
Келгиле, окуяны системанын жаралуу тарыхынан баштайлы, vAIRдин негизи болуп саналган ARDFS файлдык тутумуна кайрылалы, ошондой эле бул чечимдин орус рыногунда жайгашуусу жөнүндө бир аз сүйлөшөлү.
Келечектеги макалаларда биз ар кандай архитектуралык компоненттер (кластер, гипервизор, жүк балансы, мониторинг системасы ж.б.) жөнүндө кененирээк сүйлөшөбүз, конфигурациялоо процесси, лицензиялоо маселелерин көтөрөбүз, кросс-тесттерди өзүнчө көрсөтөбүз жана, албетте, жүктөрдү тестирлөө жана өлчөмдөө. Биз ошондой эле vAIRдин жамааттык версиясына өзүнчө макала арнайбыз.
Aerodisk сактоо тутумдары жөнүндө окуябы? Же эмне үчүн биз биринчи кезекте гиперконвергенцияны жасай баштадык?
Башында, өзүбүздүн гиперконвергенцияны түзүү идеясы бизге 2010-жылы келген. Ал убакта рынокто Aerodisk да, ага окшош чечимдер да (коммерциялык кутучалуу гиперконвергделген системалар) болгон эмес. Биздин милдетибиз төмөнкүдөй болду: Ethernet протоколу аркылуу интерконнект менен бириктирилген локалдык дисктери бар серверлердин топтомунан кеңейтилген сактагычты түзүү жана ал жерде виртуалдык машиналарды жана программалык камсыздоо тармагын ишке киргизүү керек болчу. Мунун бардыгын сактоо тутумдары жок ишке ашыруу керек болчу (анткени сактоо тутумдары жана анын жабдыктары үчүн жөн эле акча жок болчу жана биз өзүбүздүн сактагыч системабызды ойлоп таба элек болчубуз).
Биз көптөгөн ачык булактуу чечимдерди сынап көрдүк жана акыры бул көйгөйдү чечтик, бирок чечим абдан татаал жана кайталоо кыйын болду. Мындан тышкары, бул чечим "Ал иштейби?" Тийбе! Ошондуктан, бул маселени чечип, биз ишибиздин натыйжасын толук кандуу продуктка айландыруу идеясын андан ары иштеп чыккан жокпуз.
Ошол окуядан кийин биз бул идеядан алыстап кеттик, бирок бизде дагы эле бул көйгөй толугу менен чечиле тургандай, мындай чечимдин пайдалары ачык эле көрүнүп турду. Кийинчерээк чет элдик компаниялардын HCI продукциялары бул сезимди тастыктады.
Ошондуктан, 2016-жылдын орто ченинде биз толук кандуу продукцияны түзүүнүн алкагында бул милдетке кайтып келдик. Ал кезде инвесторлор менен эч кандай мамилебиз жок болчу, ошондуктан биз өзүбүздүн анча чоң эмес акчага өнүктүрүү стенди сатып алууга аргасыз болдук. Колдонулган серверлерди жана Avito өчүргүчтөрүн чогултуп, биз ишке кириштик.
Негизги баштапкы милдет Ethernet аркылуу интерконнект аркылуу туташтырылган кластердик түйүндөрдүн n-санындагы виртуалдык блоктор түрүндөгү маалыматтарды автоматтык түрдө жана бирдей тарата алган өзүбүздүн, жөнөкөй болсо да, өзүбүздүн файлдык системабызды түзүү болду. Ошол эле учурда, ФС жакшы жана оңой масштабдалышы керек жана чектеш системалардан көз карандысыз болушу керек, б.а. vAIRден "жөн эле сактоочу жай" түрүндө ажыратылышы мүмкүн.
Биринчи vAIR концепциясы
Узулган сактоону (ceph, gluster, luster жана башкалар) уюштуруу үчүн даяр ачык булактуу чечимдерди колдонуудан атайылап баш тарттык, анткени алар менен долбоор боюнча көп тажрыйбабыз бар болчу. Албетте, бул чечимдердин өзүлөрү эң сонун жана Aerodiskте иштөөдөн мурун биз алар менен бир эмес, бир нече интеграциялык долбоорлорду ишке ашырдык. Бирок бир кардар үчүн конкреттүү тапшырманы ишке ашыруу, персоналды окутуу жана, балким, чоң сатуучунун колдоосун сатып алуу башка нерсе, ал эми биз ар кандай тапшырмалар үчүн колдонула турган оңой кайталануучу продуктуну түзүү башка нерсе. сатуучу, биз өзүбүз жөнүндө билбешибиз мүмкүн. Экинчи максат үчүн, иштеп жаткан ачык булактуу өнүмдөр биз үчүн ылайыктуу эмес, ошондуктан биз бөлүштүрүлгөн файл тутумун өзүбүз түзүүнү чечтик.
Эки жылдан кийин, бир нече иштеп чыгуучулар (классикалык Engine сактоо системасында иштөө менен vAIR менен айкалыштырылган) белгилүү бир натыйжага жетишти.
2018-жылга карата биз жөнөкөй файлдык системаны жазып, аны керектүү жабдыктар менен толуктадык. Система ар кандай серверлердин физикалык (локалдык) дисктерин ички интерконнект аркылуу бир жалпак бассейнге бириктирди жана аларды виртуалдык блокторго "кесип", андан кийин виртуалдык блоктордон катага чыдамдуулуктун ар кандай даражадагы блоктук түзүлүштөрү түзүлдү, аларда виртуалдык блоктор түзүлдү. жана KVM гипервизордук машиналарын колдонуу менен аткарылган.
Биз файл тутумунун аталышы менен көп убара болгон жокпуз жана аны кыскача ARDFS деп атадык (ал эмнени билдирет))
Бул прототиби жакшы көрүндү (визуалдык жактан эмес, албетте, азырынча визуалдык дизайн жок болчу) жана аткаруу жана масштабдоо жагынан жакшы натыйжаларды көрсөттү. Биринчи реалдуу натыйжадан кийин, биз толук кандуу өнүктүрүү чөйрөсүн жана vAIR менен гана алектенген өзүнчө команданы уюштуруп, бул долбоорду ишке киргиздик.
Дал ошол убакта, чечимдин жалпы архитектурасы бышып жетилген, ал али чоң өзгөрүүлөргө дуушар боло элек.
ARDFS файл тутумуна кириш
ARDFS бүткүл кластер боюнча бөлүштүрүлгөн, каталарга чыдамдуу маалыматтарды сактоону камсыз кылган vAIRдин негизи болуп саналат. ARDFSтин айырмалоочу өзгөчөлүктөрүнүн бири (бирок жалгыз эмес) бул метаберилиштер жана башкаруу үчүн эч кандай кошумча атайын серверлерди колдонбойт. Бул алгач чечимдин конфигурациясын жөнөкөйлөтүү жана анын ишенимдүүлүгү үчүн иштелип чыккан.
Сактоо структурасы
Кластердин бардык түйүндөрүндө ARDFS бардык жеткиликтүү диск мейкиндигинен логикалык бассейнди уюштурат. Бул бассейн азырынча маалымат же форматталган мейкиндик эмес экенин түшүнүү маанилүү, бирок жөн гана белгилөө, б.а. vAIR орнотулган бардык түйүндөр кластерге кошулганда автоматтык түрдө жалпы ARDFS бассейнине кошулат жана диск ресурстары автоматтык түрдө бүткүл кластер боюнча бөлүшүлөт (жана келечектеги маалыматтарды сактоо үчүн жеткиликтүү). Бул ыкма мурунтан эле иштеп жаткан системага эч кандай олуттуу таасирин тийгизбестен, түйүндөрдү тез арада кошууга жана алып салууга мүмкүндүк берет. Ошол. системаны "кирпичте" масштабдоо өтө оңой, керек болсо кластердеги түйүндөрдү кошуу же алып салуу.
ARDFS бассейнинин үстүнө виртуалдык дисктер (виртуалдык машиналар үчүн сактоо объекттери) кошулат, алар 4 мегабайт өлчөмүндөгү виртуалдык блоктордон курулган. Виртуалдык дисктер маалыматтарды түздөн-түз сактайт. Күнөөлөргө чыдамдуулук схемасы виртуалдык диск деңгээлинде да орнотулган.
Сиз буга чейин болжолдогондой, дисктин подсистемасынын каталарына чыдамдуулук үчүн биз RAID (көз карандысыз дисктердин ашыкча массив) түшүнүгүн колдонбойбуз, бирок RAIN (көз карандысыз түйүндөрдүн ашыкча массиви) колдонобуз. Ошол. Мүчүлүштүккө чыдамдуулук дисктердин эмес, түйүндөрдүн негизинде өлчөнөт, автоматташтырылат жана башкарылат. Дисктер, албетте, ошондой эле сактоо объекти болуп саналат, алар, башка бардык нерселер сыяктуу эле, көзөмөлдөнөт, алар менен бардык стандарттык операцияларды аткара аласыз, анын ичинде локалдык аппараттык RAIDди чогултуу, бирок кластер атайын түйүндөрдө иштейт.
Сиз RAIDди чындап каалап жаткан кырдаалда (мисалы, кичинекей кластерлерде бир нече каталарды колдогон сценарий), локалдык RAID контроллерлорун колдонууга жана сунулган сактагычты жана үстүнө RAIN архитектурасын курууга эч нерсе тоскоол болбойт. Бул сценарий абдан жандуу жана биз тарабынан колдоого алынган, ошондуктан биз бул жөнүндө vAIRди колдонуунун типтүү сценарийлери жөнүндө макалада сүйлөшөбүз.
Сактоо каталарына чыдамдуулук схемалары
vAIRде виртуалдык дисктер үчүн эки катачылыкка чыдамдуу схема болушу мүмкүн:
1) Репликация фактору же жөн эле репликация - катага чыдамдуулуктун бул ыкмасы таяк менен аркан сыяктуу жөнөкөй. Синхрондук репликация 2 (кластерге 2 нуска) же 3 (тиешелүүлүгүнө жараша 3 нуска) фактору менен түйүндөрдүн ортосунда жүргүзүлөт. RF-2 виртуалдык дискке кластердеги бир түйүндүн иштебей калышына туруштук берүүгө мүмкүндүк берет, бирок пайдалуу көлөмдүн жарымын "жейт", ал эми RF-3 кластердеги 2 түйүндүн иштен чыгышына туруштук берет, бирок дисктин 2/3 бөлүгүн сактайт. анын муктаждыктары үчүн пайдалуу көлөмү. Бул схема RAID-1ге абдан окшош, башкача айтканда, RF-2де конфигурацияланган виртуалдык диск кластердеги кайсы бир түйүндүн иштебей калышына туруштук берет. Бул учурда, маалыматтар менен баары жакшы болот, ал тургай I/O токтобойт. Жыгылган түйүн кызматка кайтып келгенде, маалыматтарды автоматтык түрдө калыбына келтирүү/синхрондоштуруу башталат.
Төмөндө RF-2 жана RF-3 маалыматтарын нормалдуу режимде жана бузулган кырдаалда бөлүштүрүүнүн мисалдары келтирилген.
Бизде 8 vAIR түйүндөрүндө иштеген 4 МБ уникалдуу (пайдалуу) маалыматтардын сыйымдуулугу бар виртуалдык машина бар. Чындыгында мынчалык кичинекей көлөмдүн болушу күмөн экени түшүнүктүү, бирок ARDFS ишинин логикасын чагылдырган схема үчүн бул мисал эң түшүнүктүү. AB уникалдуу виртуалдык машина маалыматтарын камтыган 4МБ виртуалдык блоктор. RF-2 бул блоктордун A1+A2 жана B1+B2 эки нускасын түзөт. Бул блоктор бир эле түйүндөгү бир эле маалыматтардын кесилишинен качуу менен түйүндөр боюнча “жайгашкан”, башкача айтканда, A1 көчүрмөсү A2 көчүрмөсү менен бир түйүндө жайгаштырылбайт. B1 жана B2 менен бирдей.
Эгерде түйүндөрдүн бири иштебей калса (мисалы, В3 көчүрмөсүн камтыган №1 түйүн), бул көчүрмө анын көчүрмөсү (б.а. В2 көчүрмөсү) жок түйүндө автоматтык түрдө активдештирет.
Ошентип, виртуалдык диск (жана VM, тиешелүүлүгүнө жараша) RF-2 схемасынын бир түйүнүнүн иштен чыгышына оңой эле туруштук бере алат.
Репликация схемасы жөнөкөй жана ишенимдүү болгону менен, RAID1 сыяктуу эле көйгөйдөн жабыркайт - колдонууга жарактуу орун жетишсиз.
2) Жогорудагы маселени чечүү үчүн өчүрүү коддоо же өчүрүү коддоосу (ошондой эле “артык коддоо”, “тазалоо коддоосу” же “артыкчылык коду” деп аталат) бар. EC репликацияга салыштырмалуу азыраак диск мейкиндиги менен жогорку маалыматтардын жеткиликтүүлүгүн камсыз кылган ашыкча схема. Бул механизмдин иштөө принциби RAID 5, 6, 6P окшош.
Коддоштурууда EC процесси виртуалдык блокту (демейки боюнча 4МБ) EC схемасына жараша бир нече кичине "маалымат бөлүктөрүнө" бөлөт (мисалы, 2+1 схемасы ар бир 4МБ блокту 2 2МБ блокко бөлөт). Андан кийин, бул процесс мурда бөлүнгөн бөлүктөрдүн биринен чоң эмес "маалымат бөлүктөрүнүн" "паритеттик бөлүктөрүн" жаратат. Декоддоштурууда, EC бүткүл кластер боюнча "аман калган" маалыматтарды окуу менен жетишпеген бөлүктөрдү жаратат.
Мисалы, 2 кластердик түйүндөрдө ишке ашырылган 1+4 EC схемасы бар виртуалдык диск, RF-2 сыяктуу эле кластердеги бир түйүндүн иштен чыгышына оңой туруштук берет. Мында кошумча чыгымдар азыраак болот, атап айтканда, RF-2 үчүн пайдалуу кубаттуулук коэффициенти 2, ал эми ЕС 2+1 үчүн 1,5 болот.
Жөнөкөйраак сүрөттөп айтканда, виртуалдык блок 2-8ге бөлүнөт (эмне үчүн 2ден 8ге чейин, төмөндө караңыз) "даана" жана бул даана үчүн окшош көлөмдөгү паритеттин "бөлүктөрү" эсептелет.
Натыйжада, маалыматтар жана паритет кластердин бардык түйүндөрүндө бирдей бөлүштүрүлөт. Ошол эле учурда, репликациядагыдай эле, ARDFS маалыматтарды автоматтык түрдө түйүндөр боюнча бөлүштүрөт, ушундай жол менен бирдей маалыматтардын (маалыматтардын көчүрмөлөрү жана алардын паритети) бир түйүндө сакталышын болтурбоо үчүн, маалыматтарды жоготуу мүмкүнчүлүгүн жокко чыгарат. маалыматтар жана алардын паритетин күтүлбөгөн жерден бир сактоо түйүнүндө аяктайт.
Төмөндө мисал, ошол эле 8 МБ виртуалдык машина жана 4 түйүн менен, бирок EC 2+1 схемасы менен.
А жана В блоктору ар бири 2 МБ болгон эки бөлүккө бөлүнөт (экиден 2+1), башкача айтканда, A1+A2 жана B1+B2. Репликадан айырмаланып, A1 A2 көчүрмөсү эмес, ал виртуалдык блок А, эки бөлүккө бөлүнгөн, В блогу менен бирдей. Бардыгы болуп, биз 4МБдан эки топтом алабыз, алардын ар биринде эки эки МБ даана бар. Андан кийин, бул топтомдордун ар бири үчүн паритет бир даанадан ашпаган көлөм менен эсептелет (б.а. 2 МБ), биз кошумча + 2 паритет (AP жана BP) алабыз. Жалпысынан бизде 4×2 маалымат + 2×2 паритет бар.
Андан кийин, даана маалыматтар алардын паритет менен кесилишкен эмес, ошондуктан түйүндөрдүн арасына "жайгашкан". Ошол. A1 жана A2 AP менен бир түйүндө болбойт.
Бир түйүн иштен чыккан учурда (мисалы, үчүнчүсү да) кулаган В1 блогу №2 түйүндө сакталган БП паритетинен автоматтык түрдө калыбына келтирилет жана бар түйүндө активдештирүү жүргүзүлөт. В-паритет жок, б.а. BP бөлүгү. Бул мисалда бул №1 түйүн
Окурмандын суроосу бар экенине ишенем:
"Сиз сүрөттөгөн нерселердин баары көптөн бери атаандаштар тарабынан да, ачык булактуу чечимдерде да ишке ашырылып келет, ARDFSде ECти ишке ашыруунун ортосунда кандай айырма бар?"
Ошондо ARDFS кызыктуу өзгөчөлүктөрү болот.
Ийкемдүүлүккө басым жасоо менен коддоону өчүрүү
Башында, биз кыйла ийкемдүү EC X+Y схемасын бердик, мында X 2ден 8ге чейинки санга барабар, ал эми Y 1ден 8ге чейинки санга барабар, бирок ар дайым Xден аз же барабар. Бул схема каралган ийкемдүүлүк үчүн. Виртуалдык блок бөлүнгөн маалымат бөлүктөрүнүн (X) санын көбөйтүү кошумча чыгымдарды кыскартууга, башкача айтканда, колдонууга жарамдуу мейкиндикти көбөйтүүгө мүмкүндүк берет.
Паритеттик бөлүктөрүнүн санын көбөйтүү (Y) виртуалдык дисктин ишенимдүүлүгүн жогорулатат. Y мааниси канчалык чоң болсо, кластердеги түйүндөр ошончолук көп иштебей калышы мүмкүн. Албетте, паритеттин көлөмүн көбөйтүү жарактуу кубаттуулуктун көлөмүн азайтат, бирок бул ишенимдүүлүк үчүн төлөй турган баа.
EC схемалар боюнча аткаруунун көз карандылыгы дээрлик түздөн-түз: көп "даана", төмөн аткаруу, албетте, керек;
Бул ыкма администраторлорго максималдуу ийкемдүүлүк менен узартылган сактагычты конфигурациялоого мүмкүндүк берет. ARDFS бассейнинин ичинде, сиз, биздин оюбузча, ошондой эле абдан пайдалуу болгон каталарга чыдамдуулук схемаларын жана алардын комбинацияларын колдоно аласыз.
Төмөндө бир нече (баары мүмкүн эмес) RF жана EC схемаларын салыштырган таблица.
Таблицадан көрүнүп тургандай, кластердеги 8 түйүнгө чейин жоготууга мүмкүндүк берген эң "терри" EC 7+7 комбинациясы стандарттуу репликацияга караганда азыраак мейкиндикти (1,875ке каршы 2) "жейт" жана 7 эсе жакшыраак коргойт. , бул коргоо механизмин татаалыраак болсо да, чектелген диск мейкиндигинде максималдуу ишенимдүүлүктү камсыз кылуу зарыл болгон жагдайларда алда канча жагымдуу кылат. Ошол эле учурда, сиз X же Y үчүн ар бир "плюс" кошумча өндүрүмдүүлүк болот деп түшүнүшүңүз керек, андыктан ишенимдүүлүк, үнөмдөө жана аткаруунун ортосундагы үч бурчтукта сиз өтө кылдаттык менен тандоо керек. Ушул себептен улам, биз коддоо өлчөмүн өчүрүү үчүн өзүнчө макаланы арнайбыз.
Файлдык системанын ишенимдүүлүгү жана автономиясы
ARDFS кластердин бардык түйүндөрүндө локалдуу иштейт жана аларды атайын Ethernet интерфейстери аркылуу өз каражаттарын колдонуу менен синхрондошот. Маанилүү жагдай ARDFS өз алдынча маалыматтарды гана эмес, ошондой эле сактоо менен байланышкан метаберилиштерди синхрондоштуруу болуп саналат. ARDFS үстүндө иштеп жатып, биз бир эле учурда бир катар иштеп жаткан чечимдерди изилдеп көрдүк жана биз көптөр файл тутумунун метасын тышкы бөлүштүрүлгөн МББнын жардамы менен синхрондоштурууну аныктадык, аны биз синхрондоштуруу үчүн да колдонобуз, бирок FS метаберилиштери эмес, конфигурациялар гана (ушул жана башка тиешелүү подсистемалар жөнүндө) кийинки макалада).
Тышкы МББнын жардамы менен FS метаберилиштерин синхрондоштуруу, албетте, жумушчу чечим болуп саналат, бирок анда ARDFSде сакталган маалыматтардын ырааттуулугу тышкы СББЖга жана анын жүрүм-турумуна (жана, ачык айтканда, бул каприз айым) көз каранды болот. биздин пикирибиз жаман. Неге? Эгерде FS метадайындары бузулса, анда FS маалыматтарынын өзү да "кош бол" деп айтууга болот, ошондуктан биз татаал, бирок ишенимдүү жолду тандап алууну чечтик.
Биз ARDFS үчүн метадайындарды синхрондоштуруу подсистемасын өзүбүз жасадык жана ал чектеш подсистемалардан көз карандысыз жашайт. Ошол. башка эч бир подсистема ARDFS маалыматтарын буза албайт. Биздин оюбузча, бул эң ишенимдүү жана туура жол, бирок чындыгында ушундайбы, аны убакыт көрсөтөт. Мындан тышкары, бул ыкманын кошумча артыкчылыгы бар. ARDFS vAIR көз каранды эмес, сунулган сактагыч катары колдонсо болот, биз аны келечектеги өнүмдөрдө сөзсүз колдонобуз.
Натыйжада, ARDFSди иштеп чыгуу менен, биз ийкемдүү жана ишенимдүү файл тутумун алдык, анда кубаттуулукту үнөмдөөгө же бардыгын аткаруудан баш тартууга же акылга сыярлык баада өтө ишенимдүү сактагычты жасоого, бирок аткаруу талаптарын азайтууга мүмкүнчүлүк берет.
Жөнөкөй лицензиялоо саясаты жана ийкемдүү жеткирүү модели менен бирге (алдыга карасак, vAIR түйүн тарабынан лицензияланат жана программалык камсыздоо же программалык пакет катары жеткирилет), бул сизге чечимди кардарлардын ар кандай талаптарына жана анда бул тең салмактуулукту оңой сакта.
Бул керемет кимге керек?
Бир жагынан алганда, биз рынокто гиперконвергенция жаатында олуттуу чечимдери бар оюнчулар бар деп айта алабыз жана бул биз иш жүзүндө бара жаткан жерибиз. Бул сөз чын окшойт, БИРОК...
Экинчи жагынан, талаага чыгып, кардарлар менен баарлашканыбызда, биз жана биздин өнөктөштөр андай эмес экенин көрөбүз. Гиперконвергенция үчүн көптөгөн тапшырмалар бар, кээ бир жерлерде адамдар мындай чечимдер бар экенин билишкен эмес, башкаларында бул кымбат көрүнгөн, башкаларында альтернативалуу чечимдердин сыноолору ийгиликсиз болгон, ал эми башкаларында санкциялардан улам сатып алууга таптакыр тыюу салган. Негизинен талаа айдалбай калыптыр, тың топурак көтөрүүгө бардык))).
Качан сактоо системасы GCSге караганда жакшыраак?
Рынок менен иштешкенибизде, бизден сактагыч системалары менен классикалык схеманы качан колдонуу жакшы жана гиперконвергентти качан колдонуу керек деп сурашат. Көптөгөн GCS өндүрүүчү компаниялар (өзгөчө портфелинде сактоо тутуму жок) мындай дешет: "Сактоо тутумдары эскирип, гиперконвергацияланган гана!" Бул тайманбас сөз, бирок ал реалдуулукту толугу менен чагылдырбайт.
Чынында, сактоо рыногу чындап эле гиперконвергенцияга жана ушул сыяктуу чечимдерге карай жылып жатат, бирок ар дайым "бирок" бар.
Биринчиден, сактагыч системалары менен классикалык схема боюнча курулган дата борборлорун жана IT инфраструктураларын оңой эле кайра куруу мүмкүн эмес, ошондуктан мындай инфраструктураларды модернизациялоо жана бүтүрүү 5-7 жылдан бери мурас бойдон калууда.
Экинчиден, көпчүлүк учурда курулуп жаткан инфраструктура (Россия Федерациясын билдирет) сактоо тутумдарын колдонуу менен классикалык схема боюнча курулган, бул адамдар гиперконвергенция жөнүндө билбегендиктен эмес, гиперконвергенция рыногу жаңы болгондуктан, чечимдер жана стандарттар азырынча түзүлө элек, IT адистери али окута элек, алардын тажрыйбасы аз, бирок бул жерде жана азыр дата борборлорун куруу керек. Жана бул тенденция дагы 3-5 жылга созулат (андан кийин дагы бир мурас, 1-пунктту караңыз).
Үчүнчүдөн, бир жазуу үчүн 2 миллисекунддук кошумча кичинекей кечигүүлөрдүн таза техникалык чектөөсү бар (албетте, жергиликтүү кэштен тышкары), бул бөлүштүрүлгөн сактоонун баасы.
Дисктин подсистемасынын вертикалдуу масштабын жакшы көргөн чоң физикалык серверлерди колдонууну унутпайлы.
Сактоо тутумдары GCSге караганда жакшыраак иштеген көптөгөн керектүү жана популярдуу тапшырмалар бар. Бул жерде, албетте, алардын продукт портфелинде сактоо системасы жок өндүрүүчүлөр биз менен макул эмес, бирок биз негиздүү талашууга даярбыз. Албетте, биз эки продукттун тең иштеп чыгуучулары катары, сактоо тутумдарын жана GCSти келечектеги басылмаларыбыздын биринде сөзсүз салыштырабыз, анда кайсы шарттарда кайсынысы жакшыраак экенин так көрсөтөбүз.
Кайсы жерде гиперконвергделген чечимдер сактоо тутумдарына караганда жакшыраак иштейт?
Жогорудагы пункттардын негизинде үч ачык-айкын жыйынтык чыгарууга болот:
- Кайсы бир продуктта ырааттуу пайда болгон жаздыруу үчүн кошумча 2 миллисекунддук кечигүү (азыр синтетика жөнүндө сөз кылбайбыз, наносекундтарды синтетикада көрсөтсө болот) критикалык эмес, гиперконвергент ылайыктуу.
- Чоң физикалык серверлердин жүгүн көптөгөн кичинекей виртуалдык серверлерге айландырууга жана түйүндөр арасында бөлүштүрүүгө мүмкүн болгон жерде, гиперконвергенция да жакшы иштейт.
- Эгерде горизонталдуу масштабдоо вертикалдык масштабга караганда жогорураак артыкчылыктуу болсо, GCS ал жерде да жакшы болот.
Бул кандай чечимдер?
- Бардык стандарттык инфраструктура кызматтары (каталог кызматы, почта, EDMS, файл серверлери, чакан же орто ERP жана BI системалары ж.б.). Биз муну “жалпы эсептөө” деп атайбыз.
- Булут провайдерлеринин инфраструктурасы, бул жерде тез жана стандартташтырылган горизонталдуу кеңейтүү жана кардарлар үчүн көптөгөн виртуалдык машиналарды оңой "кесүү" керек.
- Виртуалдык иш столунун инфраструктурасы (VDI), мында көптөгөн кичинекей колдонуучу виртуалдык машиналары иштейт жана бирдиктүү кластердин ичинде тынч "сүзөт".
- Ар бир филиалга стандарттуу, каталарга чыдамдуу, бирок 15-20 виртуалдык машинадан турган арзан инфраструктура керек болгон филиалдык тармактар.
- Ар кандай бөлүштүрүлгөн эсептөөлөр (мисалы, чоң маалымат кызматтары). Кайда жүк "тереңдикке" эмес, "кеңдикке" барат.
- Кошумча кичинекей кечигүүлөр алгылыктуу болгон сыноо чөйрөлөрү, бирок бюджеттик чектөөлөр бар, анткени бул сыноолор.
Учурда биз AERODISK vAIRди дал ушул милдеттер үчүн жасадык жана дал ошолорго басым жасап жатабыз (азыр ийгиликтүү). Балким, бул жакында өзгөрөт, анткени... дүйнө бир ордунда турбайт.
Демек, ...
Бул макалалардын чоң сериясынын биринчи бөлүгүн аяктайт, кийинки макалада биз чечимдин архитектурасы жана колдонулган компоненттер жөнүндө сүйлөшөбүз.
Биз суроолорду, сунуштарды жана конструктивдүү талаш-тартыштарды кабыл алабыз.
Source: www.habr.com