ARM архитектурасының тарихы: Acorn-нан серверлер мен бұлтқа дейін

Процессор архитектурасы неге маңызды

Процессор архитектурасы — бағдарламалардың аппаратпен "сөйлесу" ережелері. Ол чиптің қандай командаларды түсінетінін, регистрлер мен жадтың қалай орналасқанын, қауіпсіздік механизмдерінің бар-жоғын және жүйеге қандай функциялар берілетінін анықтайды.

Бұл тек инженерлерге ғана емес, күнделікті пайдаланушыларға да әсер етеді: нақты тапсырмалардағы жылдамдыққа, иесі болу құнына және энергия шығынына. Бір ғана бағдарлама әртүрлі архитектураларда өзгеше жұмыс істеуі мүмкін. Бұл салқындатуды, стойкалардағы тығыздықты және соңында электр төлемдерін өзгертеді.

Неліктен ARM туралы көптеген әңгімелер бар? Өйткені ARM ұзақ уақыт бойы үнемділік пен кең таралған құрылғылармен байланысты болды, ал қазір ол бұрын x86 басым болған бағыттарға — серверлер, бұлттық платформалар, ИИ-ға арналған платформалар мен корпоративтік жүйелер — сенімді түрде енуде. Бизнес үшін бұл «процессорлар туралы» сөз емес, практикалық мәселе: қажетті өнімділікті арзанырақ немесе аз энергиямен алуға бола ма.

ARM күнделікті өмірде кеңінен қолданылуы арқасында экожүйесін жылдам өсіре алды: смартфондар мен планшеттер, роутерлер, ТВ-приставкалар, ақылды колонкалар, автомобиль электроникасы, өндірістік автоматика және автономияға бағытталған ноутбуктер.

Ал серверлік әлемде ARM ұзақ уақыт деңгейге жетіп жатты. Онда үйлесімділік, драйверлер, лицензиялар, таныс құралдар мен бағдарламалық қолдау маңызды. Сондықтан архитектура таңдау жиі мегагерцтерден емес, қауіптер мен экожүйенің жетілгендігінен тәуелді болады.

Әрі қарай — ARM қалай пайда болғаны, лицензиялау моделі неліктен оның күшті жағы болғаны, ARMv8 пен ARMv9 не өзгертті, Neoverse сервер тармағы не үшін керек және нақты жағдайда ARM мен x86 арасында қалай таңдау жасау керек, жағымсыз тосынсыйларсыз.

ARM қалай пайда болды: Acorn және RISC идеясы

ARM тарихы деректер орталықтарында да, телефондарда да пайда болған жоқ, ол шағын британдық Acorn компаниясында басталды, олар үй компьютерлерін шығаратын. 1980-жылдардың басында Acorn-ға қымбат компоненттер мен күрделі салқындатуды қажет етпейтін жылдам процессор керек болды.

Ол кезде CISC тәсілі басым еді: көп және күрделі командалар, олардың кейбіреулері сирек қолданылады, ал іске асыру қиын. RISC идеясы керісінше болды: командалар аз, бірақ олар қарапайым және тез орындалады. Қарапайым тілмен айтқанда, "барлығын істейтін комбайн" емес, жиі қолданылатын қарапайым әрекеттер жиынтығын жасап, процессор оларды өте тиімді орындайды.

Acorn үшін бұл практикалық артықшылықтар берді: транзистор саны аз, өзіндік құны төмен, энергия тұтынуы және жылу аз, типтік тапсырмаларда жылдамдық болжамды, компиляторлар оңай, платформа тез дамиды.

Бастапқы ARM чиптері (ARM1 — 1980-ларды ортасында, кейін ARM2) өз класында жылдам, үнемді және өндіруге қарапайым болып шықты. Оларды Acorn компьютерлерінде қолданды, мұнда жүйенің жауаптылығы мен салқындатусыз жұмыс маңызды еді.

ARM атауы да эволюцияны көрсетеді. Алғашында бұл Acorn RISC Machine — «Acorn RISC машинасы» еді. Технология айналасында бөлек компания мен бизнес халықаралық сипат алған соң атаудың түсіндірмесі Advanced RISC Machines-ке өзгерді. Мағына өзгерді, бірақ идея сол қалды: масштабтауға және әртүрлі құрылғыларға бейімделуге оңай қарапайым ядро.

Лицензиялар мен экожүйе: ARM неге тез таралды

ARM тек RISC идеясының арқасында ғана өсіп қойған жоқ, сонымен бірге ерекше бизнес-модельдің нәтижесі. Компания негізінен дайын процессорларды физикалық түрде сатпады. Оның орнына интеллектуалдық меншік — командалар жиыны (архитектура) және дайын «конструкторлық блоктар» (ядролар) қолдану құқығын сатты.

Бұл тәсіл платформаның таралуын жылдамдатты. Өндірушіге процессорды басынан бастап жобалау, қателіктерді табу және оны сериялық өндіріске жеткізу керек болған жоқ. Ол тек тексерілген ARM-ядронды алып, өз SoC-ін қажетті интерфейстермен, графикамен, жад контроллерлерімен жинап, нақты тапсырмаға арналған чип жасай алды.

Әдетте екі лицензия форматы кездеседі:

• Дайын ядро лицензиясы — ядро дерлік "сол күйінде" алынады және нарыққа тез шығуға мүмкіндік береді.
• Архитектуралық лицензия — ARM командалар жиыны пайдаланылады, бірақ өз ядросын жасап, өнімділік пен тиімділікті барынша арттыруға мүмкіндік береді.

Серіктестер экожүйесі осы модельдің жалғасы болды. Біреулер мобильді SoC жасады, басқалар — желілік және кірістірілген шешімдер, тағы біреулер — серверлік процессорлар мен акселераторлар. Нәтижесінде ARM "бар everywhere" болды, өйткені оны әртүрлі бюджеттерге, жылу пакеттеріне және сценарийлерге бейімдеуге болады.

Егер дәстүрлі модельмен салыстырсақ, айырмашылық айқын. x86 әлемінде ұзақ уақыт негізгі процессорларды бірнеше өндіруші бақылады, ал қалғандар сол платформалар маңайына ыңғайланады. ARM-де бәрі керісінше: бір команда стандарты және көптеген жеке жүзеге асырулар. Бұл масштаби эффектісін туғызды — ARM үшін құралдар, операциялық жүйелер және бағдарлама қолдауы тез пайда болды.

Кірістірілген құрылғылардан смартфон дәуіріне дейін

1990-жылдары ARM кірістірілген электроника әлемінде орнықты. ARM7 және ARM9 отбасылары энергияны үнемдеу мен қарапайымдылық маңызды болған барлық жерде жұмыс күштері болды: желі жабдықтары, принтерлер, автомобиль контроллерлері. Бұл кірістірілген құрылғылардың көп болуы көлем, тәжірибе және өндірушілердің сенімін әкелді.

2000-жылдардың басында бірдей "универсал" ядро әртүрлі тапсырмаларға тарлағаны байқалды. Сол кезде Cortex отбасы пайда болды және рөлдер айқындалды:

• Cortex-M — микроконтроллерлер үшін.
• Cortex-R — нақты уақыт жүйелері үшін.
• Cortex-A — күрделі интерфейс пен қосымшалары бар құрылғылар үшін.

Энергоүнемділік сән үшін емес, практика үшін артықшылық болды. Телефондарда батареядан жұмыс уақыты, жылу және салқындату көлемі маңызды. ARM-ядролары әдетте құрылғыларды жіңішке, тыныш және арзан етуге мүмкіндік берді, себебі олар аз энергия тұтынып, жылуды оңай таратады.

Бағдарламалық қамтамасыз ету біртіндеп жетілді: компиляторлар әртүрлі ядролар мен режимдерге жақсырақ оңтайландырды, тұрақты ABI қалыптасты, операциялық жүйелер мен драйверлер көптеген ARM-платформаларды жүйелі түрде қолдады, ал өндірушілер құжаттама мен SDK-ларға көбірек инвестиция салды.

Практикада бұл былай көрінді: смартфон өндірушісі қолданбалар мен мультимедиа үшін Cortex-A таңдап, фондық тапсырмалар үшін әлсіз блоктарды қосып, сол батареядан ұзағырақ өмір сүретін құрылғы алды. Бұл ARM-ға смартфон дәуіріне жол ашты.

64 битке өту: ARMv8-тен ARMv9-ға дейін даму

ARM үшін 64 битке өту жай ғана «көбірек жад» емес еді. Ол үлкен адрес кеңістіктері, процестердің қатаң оқшаулануы және жүктеме астындағы болжамды жұмыс сияқты міндеттер үшін жол ашты. Смартфондарға бұл пайдалы болса да, серверлер мен ірі қосымшалар үшін — маңызды.

ARMv8 64-бит режимін (AArch64) енгізіп, платформға жаңа негіз берді. Операциялық жүйелер мен әзірлеушілер серверлік орта құруды 32 бит дәуіріне тән компромисстерсіз жүргізе алды.

Практикада не өзгерді:

• Жад — үлкен көлемдегі ОЗУ-мен жұмыс істеу оңайлады, бұл дерекқорлар, кэштер, аналитика және виртуализация үшін маңызды.
• Қосымша және ОС — толық 64-бит жинақтар пайда болды, ABI біркелкіленді және кітапханалардың мінезі болжамды болды.
• Өнімділік — регистрлер санының көбеюі және заманауи командалар жиыны компиляторларға серверлік тапсырмаларда жақсы код беруге көмектеседі.
• Платформа — жаңа жүктемелерге ядроларды әрі қарай дамыту оңайлады, үйлесімдікті үзбей.

ARMv9 бұл бағытты жалғастырып, қауіпсіздікке және жаңа есептеулер түрлеріне көбірек көңіл бөлді. Жалпы алғанда бұл бұлттар мен көппайдаланушы орталар үшін процессор деңгейінде қорғанысты күшейту және жоғары параллелизмді талап ететін сценарийлерді қолдау деген сөз.

Серверлер үшін бұл аса маңызды, өйткені сервер бір ғана тапсырманы орындамайды. Бір уақытта дерекқорлар, контейнерлер, сервис пен мониторинг жұмыс істейді. 64-биттіктік жад резервін береді және оқшаулануды сенімді етеді, яғни платформаны масштабтау оңай әрі қауіпсіз болады.

ARM сервер әлемінде: Neoverse және деректер орталықтарының мотивациясы

ARM бұрын смартфондармен байланысты болғанымен, деректер орталықтары үшін ол бөлек бағытқа ие. Мұнда мақсат — үнемділік емес, тұрақты жүктеме астында болжамды өнімділік, көп ядролармен масштабтау және 24/7 тұрақты жұмыс.

Neoverse деген не

Neoverse — серверлік ARM ядроларының отбасы, оны чип өндірушілер мен бұлт провайдерлері қолданады. Мобильді ядролардан айырмашылығы, мұнда жад өткізу қабілеті, көп ағынмен жұмыс, виртуализация, қауіпсіздік және стойкадағы тиімділікке көп көңіл бөлінеді, бір «пиковый» тестке емес.

Неліктен деректер орталықтары ARM-ға қарайды? Көп жағдайда жауап энергия тұтыну мен тығыздыққа келеді. Қызметтер өскен сайын электр және салқындату шығындары жабдық құны сияқты маңызды факторға айналады. Меншікті шығын: қанша сервер қажет, олар қанша орын алады, қаншалықты жиі қызмет көрсету керек және жаңарту қаншалықты оңай — бәрі есепке алынады.

ARM әдетте келесі салаларда жақсы жұмыс істейді: көлденең масштабталатын жүктемелер — веб-сервистер мен API, контейнерлер мен микросервистер, фондық тапсырмалар мен кезектер, оқиғаларды өңдеу, типтік кэш конфигурациялары мен масштабталатын дерекқорлардың кейбір түрлері, CI/CD және тест орталарының бөлігі.

Өтпелі кезең қиын болатын жерлер — ескі ПО-ның ARM үшін жинақтары болмауы, сирек драйверлер мен арнайы аппараттық карталар, сондай-ақ лицензиялау немесе қолдау x86-қа байланған коммерциялық жүйелер.

Практикалық жол — пилот. Бір-екі типтік жүктемені таңдап, сұраныс бойынша және тұтыну бойынша өлшеңіз, содан кейін ARM қай жерде үнем беретінін анықтаңыз. Мұнда тәуелсіз жүйелік интегратор көмектесе алады, бағалау бір брендке немесе платформаға тәуелді болмайтындай.

Қазір кездесетін ARM серверлері және қолдану орны

ARM серверлерін әдетте тұрақты шығын, жоғары тығыздық және көп бірдей конфигурация қажет жерлерде таңдайды. Linux ортасында бұл енді экзотика емес — кейбір тапсырмалар үшін қалыпты шешім.

Бұлт және хостинг

Провайдерлер үшін парк біртекті болғаны тиімді: бірдей түйіндерді сатып алу, қызмет көрсету және масштабтау оңай. ARM типтік инстанстарға, микросервистерге және көлденең масштабтауға жақсы сәйкес келеді.

Бұлтта ARM-ды көбіне веб-сервистер, API, фондық өңдеулер, CI/CD, тест орта және контейнерлік платформалар үшін қолданады.

On-prem: ұйымдардың өзінде ARM сатып алу

Ішкі ортада ARM серверлерін жиі таңдайды, егер жүктеме анық және ортаның бақылауы бар болса: жеке бұлт, корпоративтік Kubernetes платформа, ішкі сервистер пулі. Мұнда шешім экономика мен энергоүнемділікке негізделеді, сәнге емес.

Миграцияны жылдамдататын басты фактор — бағдарламалық қамтамасыз ету. Жалпы сценарий: Linux + контейнерлер және Kubernetes — мәліметтер мен образдарды қайта жазбай-ақ көшіруге мүмкіндік береді, егер образдар архитектураға сәйкес қайта құрастырылса және тәуелділіктер қолжетімді болса.

Сатып алдымас бұрын мына негізгі сұрақтарды тексеріңіз: платформ қанша жадты қолдайды және қалай (каналдар, лимиттер), желіге қандай талап бар және драйверлер бар ма, акселераторлар (GPU/NPU) қажет пе және қандай конфигурациялар тексерілген, микробағдарламалар мен қашықтан басқару қаншалықты жетілген, қолдау және запас бөлшектер қалай ұйымдастырылған.

ARM пен x86 арасындағы таңдау: бағалау жоспары

ARM мен x86 арасындағы таңдау сирек "қарапайымрақ" немесе "жеңіл" деп шешілмейді. Маңыздысы — сіздің жағдайыңызда қайсысы нақты пайда беретіні: жүктеме түрі, ПО, қолдау талаптары және нақты меншікті шығын.

Айқындық беретін бес қадам

1. Жүктемелерді бекітіңіз. Сервис тізімін және олардың профилін жасаңыз (веб, дерекқор, аналитика, виртуализация, контейнерлер, AI, инфрақұрылым). Әрбір үшін не маңызды екенін белгілеңіз: бір ядро ма, көп ядро ма, жад, желі, диск, кідіріс.

2. ПО үйлесімділігін тексеріңіз. ARM-ға арналған ОС жинақтары, гипервизорлар, контейнер образдары, драйверлер, бэкап және мониторинг агенттері керек. Крипто кітапханалар, ML кітапханалары, JNI және коммерциялық өнімдердің лицензияларын бөлек тексеріңіз.

3. Пилот жасаңыз және өлшеңіз. Басыншы бенчмарктерге сенбеңіз. Шынайы деректермен типтік сценарийлерді жүгіртіп, жылдамдықпен қатар тұтынуды, нагрев пен тұрақтылықты да өлшеңіз.

4. TCO есептеңіз. Сатып алу, кепілдіктер, стойка, қуат, лицензиялар, команда шығындары, тоқтап қалу тәуекелі мен миграция шығындарын бір кестеге салыңыз.

5. Миграция мен қолдауды жоспарлаңыз. Ауыстыру мен кері қайтару терезесін, жаңартуларды, мониторингті, запас бөлшектер мен жеткізу мерзімдерін анықтаңыз.

Пилотта не өлшенеді

4–5 негізгі метрика жеткілікті: p95 кідіріс, өткізу қабілеті, CPU және жад пайдалану, IOPS немесе желілік жүктеме, сондай-ақ "бір пайдалы жұмыс бірлігіне" (мысалы, сұранысқа немесе транзакцияға) жұмсалатын ватттар.

ARM серверлерін енгізуде жиі кездесетін қателіктер

Ең жиі қателік — ARM серверін "жиілігі көп және ядросы көп — значит быстрее" логикасымен таңдау. Шын мәнінде көптеген серверлік тапсырмаларда жадтың өткізу қабілеті, кідірістер, RAM каналдарының конфигурациясы және деректердің ядроларға қаншалықты тез берілуі маңызды. Екінші жасырын фактор — желі мен сақтау: егер тар орын диск операциялары немесе кезектер болса, CPU-ның қуатын арттыру нәтижесіз болуы мүмкін.

ПО порттау да жиі бағаланбайды. Қосымша ARM-ды "қолдайды" болса да, драйверлер, мониторинг агенттері, бэкаптар, криптокітапханалар, контейнер образдары мен CI/CD қалпын тексеру қажет. Уақыт көбінесе кодты қайта жазудан гөрі жаңа платформаны тестілеуге және сирек кездесетін қателерді табуға кетеді.

Тағы бір айла — лицензиялау. Кейбір өнімдер құнын ядролар саны, сокеттер немесе инстанстар саны бойынша есептейді. ARM серверінде бір серверде ядролар көбірек болуы мүмкін, сондықтан есеп көздері өзгеріп, шығын өсіп кетуі ықтимал.

Пилот алдында кемінде мына нәрселерді тексеріңіз: нақты жүктеме бойынша метрикалар (latency, throughput, p95/p99), лицензияларды есептеу ережелері, образдар мен құралдардың дайын болу деңгейі, кері қайтару жоспары және техникалық қызмет көрсету (SLA, запас бөлшектер, жөндеу мерзімдері).

Сатып алу немесе миграция алдындағы қысқа чеклист

ARM-ға өту энергоүнемділік пен есептеу тығыздығын арттыруға ынта білдіргенде логикалық көрінеді, бірақ сәттілікті көбінесе детальдар шешеді.

Ең алдымен бүкіл тізбек бойынша үйлесімділікті тексеріңіз: тек қосымша ғана емес, оның айналасындағы бәрі. ОС, контейнер образдары, мониторинг және бэкап агенттері, драйверлер, криптобиблиотекалар, Java/.NET рантаймдері, үшінші тарап модульдер. Ең жиі кездесетін проблема — "бәрі құрастырылады", бірақ бір маңызды компонент тек x86 үшін ғана қолжетімді.

Пилотты шағын өлшеу мүмкін эксперимент ретінде жоспарлаңыз. Ол паспорттық көрсеткіштер емес, сіздің шектеулеріңіз бен жүктемелеріңіз бойынша нақты салыстыру беруі керек: өнімділік, кідірістер, тұтыну, тұрақтылық, сондай-ақ типтік операциялар (жаңарту, авариялық қайта жүктеу, қалпына келтіру).

Сонымен бірге ПО жоспарын дайындаңыз. Қауіп көбінесе ARM серверлерінде емес, образдар мен тәуелділіктерде: нені қайта құрастыру керек (контейнерлер, пакеттер, образдар), CI/CD қалай жұмыс істейді, қандай автотесттер бар, бэкаптар мен кері қайтару қалай ұйымдастырылған.

Төмендегі сұрақтарды нақтылаңыз:

• Негізгі қосымшалардың ARM-нұсқалары және олардың иелері кім; жауапкершілік кімде.
• Қандай метрикалар табысты деп есептеледі (өнімділік, кідіріс, есептеу құны, энергия тұтыну, шыңдар).
• Қауіпсіздік пен реттеу талаптары қандай.
• Қолдау қалай ұйымдастырылады: диагностика, ауыстыру, қалпына келтіру мерзімдері, запас бөлшектер.

Шешімді TCO-ға сүйене отырып жасаған дұрыс: жабдық, лицензиялар, миграция, оқыту, тоқтап қалу және қолдау шығындарын салыстырыңыз.

Практикалық мысал: ұйым жаңа сервистер үшін платформаны қалай таңдайды

Орташа ұйым (мысалы, аймақтық клиникалар желісі) серверлерін виртуализацияға, ішкі сервистер мен аналитикаға жаңартуды жоспарлайды. Ескі жабдық қатты дыбыс шығарады, көп жылу бөледі және электр көп жұмсайды, ал сервер бөлмесіндегі стойкалар қуат пен салқындату бойынша шектелген.

Таңдау алдында әдетте сатып алудан бұрын пилот өткізіледі — 2–4 апта. Нақты өндірістік жүктемелерді алып, бірдей жағдайларда тексереді. Вакуумды тесттер емес, нақты жұмыс жылдамдығын, меншікті шығынды және команданың қолдау мүмкіндіктерін қарастырған жөн.

Пилотта виртуалды машиналар стандартты рөлдермен, бір-екі дерекқор (бэкап пен қалпына келтіруді қоса), контейнерлер мен образдарды құрастыру, мониторинг пен логтар, қауіпсіздік пен үйлесімділік тексеріледі.

Тестілеуден кейін шешім жиі аралас болады: контейнерленген және масштабталатын жүктемелер ARM-ға көшіруі мүмкін, ал лицензиялар немесе арнайы компоненттерге бай жүйелер x86-де қалады. Осылайша тәуекел төмендетіліп, кері қайтару мүмкіндігі сақталады.

Келесі қадамдар: ARM-ға артық тәуекелсіз қалай жақындау керек

Бастамас бұрын "ARM не x86" деген сұрақтан гөрі мақсаттарды анықтаңыз. 3–5 өлшенетін мақсат жазыңыз: энергияда қанша үнемдегіңіз келеді, стойкада қандай тығыздық керек, жеткізілім тәуелсіздігі қаншалықты маңызды, іске қосу мерзімдері қандай. Бұл артық нұсқаларды бірден шетке ығарып тастайды.

Сосын пилот жасаңыз, үлкен сатып алу емес. Ол паспорттық емес, нақты жүктемелерге сәйкес салыстыру үшін қажет: өнімділік, кідіріс, тұтыну, тұрақтылық, сондай-ақ жаңарту мен авариялық қалпына келтіру сияқты типтік операциялар.

Сонымен қатар ПО жоспарын әзірлеңіз. Қауіп көбіне ARM сервистерінде емес, образдар мен тәуелділіктерде: нені қайта құрастыру керек (контейнерлер, пакеттер, образдар), CI/CD қалай ұйымдастырылған, қандай автотесттер бар, бэкап пен x86-ке кері қайтару жолдары.

Егер инфрақұрылым дизайны, сервер таңдау және енгізуге байланысты регламенттер мен қызмет көрсету қажет болса, жобаны жергілікті қолдау мен біртұтас жауапкершілікпен орындау үшін GSE.kz (gse.kz) жүйелік интеграторы және сервер жабдықтарын өндірушісі ретінде қарастыруға болады.