Сәлем, Habr оқырмандары. Осы мақалада біз әзірлеген AERODISK vAIR гиперконвергиялық жүйесі туралы айтатын серияны ашамыз. Бастапқыда біз бірінші мақалада бәрін айтқымыз келді, бірақ жүйе өте күрделі, сондықтан біз пілді бөліктерге бөлеміз.
Әңгімені жүйенің құрылу тарихынан бастайық, vAIR негізі болып табылатын ARDFS файлдық жүйесіне үңілейік, сонымен қатар осы шешімнің ресейлік нарықта орналасуы туралы аздап сөйлесейік.
Болашақ мақалаларда біз әртүрлі архитектуралық құрамдас бөліктер (кластер, гипервизор, жүктеме балансы, бақылау жүйесі және т. мөлшерлеу. Біз сондай-ақ vAIR қауымдастық нұсқасына жеке мақала арнаймыз.
Aerodisk сақтау жүйелері туралы әңгіме ме? Немесе біз бірінші кезекте гиперконвергенция жасай бастадық?
Бастапқыда өзіміздің гиперконвергенцияны құру идеясы бізге шамамен 2010 жылы келді. Ол кезде нарықта Aerodisk де, ұқсас шешімдер де (коммерциялық қорапты гиперконвергентті жүйелер) болған жоқ. Біздің міндетіміз келесідей болды: Ethernet протоколы арқылы интерконнект арқылы біріктірілген жергілікті дискілері бар серверлер жиынтығынан кеңейтілген сақтау орнын құру және виртуалды машиналар мен бағдарламалық қамтамасыз ету желісін іске қосу қажет болды. Мұның бәрін сақтау жүйелерінсіз жүзеге асыруға тура келді (өйткені сақтау жүйелері мен оның аппараттық құралдарына ақша жоқ еді, ал біз өзіміздің сақтау жүйелерін әлі ойлап тапқан жоқпыз).
Біз көптеген ашық бастапқы шешімдерді қолданып көрдік және ақырында бұл мәселені шештік, бірақ шешім өте күрделі және қайталануы қиын болды. Сонымен қатар, бұл шешім «Бұл жұмыс істей ме? Ұстамаңыз! Сондықтан, бұл мәселені шешіп, біз өз жұмысымыздың нәтижесін толыққанды өнімге айналдыру идеясын одан әрі дамытпадық.
Сол оқиғадан кейін біз бұл идеядан алыстап кеттік, бірақ бізде бұл мәселе толығымен шешілетін сияқты және мұндай шешімнің пайдасы әлдеқайда айқын болды. Кейіннен шетелдік компаниялардың шығарылған HCI өнімдері бұл сезімді растады.
Сондықтан, 2016 жылдың ортасында біз толыққанды өнім жасау аясында бұл міндетке қайта оралдық. Ол кезде бізде әлі инвесторлармен қарым-қатынас болмады, сондықтан біз өзіміздің үлкен емес ақшаға даму стендін сатып алуға тура келді. Пайдаланылған серверлер мен Avito қосқыштарын жинап, біз іске кірістік.
Негізгі бастапқы міндет - Ethernet арқылы интерконнект арқылы қосылған кластер түйіндерінің n-ші санына виртуалды блоктар түріндегі деректерді автоматты түрде және біркелкі тарата алатын, қарапайым болса да, өзіміздің файлдық жүйемізді құру болды. Сонымен қатар, ТЖ жақсы және оңай масштабтауға және көрші жүйелерге тәуелсіз болуы керек, яғни. vAIR-тен «жай сақтау орны» түрінде иеліктен шығарылуы мүмкін.
Бірінші vAIR тұжырымдамасы
Біз өзіміздің дамуымыздың пайдасына созылған сақтауды (ceph, gluster, luster және т. Әрине, бұл шешімдердің өзі тамаша, және Aerodisk-те жұмыс жасамас бұрын, біз олармен бірнеше интеграциялық жобаны жүзеге асырдық. Бірақ бір тұтынушы үшін нақты тапсырманы орындау, қызметкерлерді оқыту және, мүмкін, ірі жеткізушінің қолдауын сатып алу, ал біз әртүрлі тапсырмалар үшін пайдаланылатын оңай қайталанатын өнімді жасау басқа нәрсе. сатушы, тіпті өзіміз туралы білмеуіміз мүмкін. Екінші мақсат үшін бар ашық бастапқы өнімдер бізге сәйкес келмеді, сондықтан біз үлестірілген файлдық жүйені өзіміз жасауды шештік.
Екі жылдан кейін бірнеше әзірлеушілер (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-де конфигурацияланған виртуалды диск кластердегі кез келген бір түйіннің істен шығуына төзімді. Бұл жағдайда деректермен бәрі жақсы болады және тіпті енгізу-шығару тоқтамайды. Құлаған түйін қызметке оралғанда, деректерді автоматты түрде қалпына келтіру/синхрондау басталады.
Төменде қалыпты режимде және сәтсіздік жағдайында 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 сияқты кластердегі бір түйіннің істен шығуына оңай төтеп береді. Бұл жағдайда үстеме шығындар төмен болады, атап айтқанда, РФ-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) санын ұлғайту үстеме шығындарды азайтуға, яғни пайдалы кеңістікті арттыруға мүмкіндік береді.
Паритет бөліктерінің (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 жасадық және дәл соларға назар аударып отырмыз (әзірге сәтті). Мүмкін бұл жақында өзгеретін шығар, өйткені... дүние бір орында тұрмайды.
Сонымен ...
Бұл мақалалардың үлкен сериясының бірінші бөлігін аяқтайды, келесі мақалада шешімнің архитектурасы мен қолданылатын компоненттер туралы айтатын боламыз.
Біз сұрақтарды, ұсыныстарды және сындарлы дауларды құптаймыз.
Ақпарат көзі: www.habr.com