Чи є життя на ARM-і — досвід міграції

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, IT спільното! Мене звати Дмитро Сірант, вже 4 роки я працюю на позиції СТО компанії OpsWorksCo. За цей час ми стали AWS Advanced Consulting Partner, суттєво розширили експертизу та зміцнили команду.

Мій попередній досвід DevOps-інженера дає можливість глибоко оцінити проєкт, тісно співпрацювати з командою, бо я і досі долучаюсь до проєктів компанії, щоб удосконалювати технічну експертизу, бути в курсі сучасних тенденцій. Додавайтесь до мене в LinkedIn, буду радий знайомству.

Дана публікація буде корисна DevOps та Cloud-інженерам, а також всім, хто цікавиться сучасними технологіями та прагне постійного розвитку.

Передісторія

Ми займалися міграцією AWS-проєкту, де замовник від самого початку наполягав на тому, що вартість інфраструктури має бути якомога меншою. Якщо подивитися на архітектуру проєкту, ви не помітите нічого особливого:

  • фронт на React хоститься на S3 та доступний через CloudFront;
  • бекенд на PHP і розгорнутий в EKS;
  • трафік до бекенду потрапляє частково через CloudFront, а частково через NLB (у нас є довготривалі запити, які поки не переробили на стороні застосунку і є WebSocket);
  • використовуємо RDS Aurora для MySQL та ElasticCache Redis;
  • файли зберігаються на S3;
  • є додатковий функціонал, який реалізований на Lambda + Athena;
  • логи складаються та аналізуються в OpenSearch.

З особливостей проєкту — кількість запитів може короткостроково збільшуватись в шість разів від звичайної.

Які процесори ви знаєте?

В AWS ми маємо обмежену кількість процесорних архітектур, а саме: AMD64, ARM64 та i386. Цікаво дізнатися про ваш досвід використання i386, мені на думку спадає лише legacy застосунки, які не мають підтримки сучасніших архітектур.

Можна пограти у гру «Скажи, які процесорні архітектури або процесори ти знаєш, і я вгадаю твій вік». Більшість молодих спеціалістів мають знати AMD64 (x86_64) та ARM64 (AArch64). Ті, хто трохи доросліші, мають знати про 32-бітні процесори і, в залежності від віку, мають досвід роботи з різними версіями процесорів Intel Pentium, AMD. Або, якщо мали справу з мобільною розробкою, — згадають про ARMv7.

Якщо ви працювали з 8086, то ви десь мого віку і, скоріш за все, згадаєте про Zilog Z80 (8-бітний процесор у Спектрумі).

На жаль, я не можу нічого сказати про досвід тих колег, хто працював з RISK-процесорами, такими як: DEC Alpha, Atmel AVR, Blackfin, Intel i860, Intel i960, LoongArch, Motorola 88000, MIPS architecture, PA-RISC, Power ISA, RISC-V, SuperH, SPARC.

Свого часу я намагався придбати на eBay сервер з процесором SPARC, щоб погратися з Solaris, але не склалося і в мене зʼявився досвід використання «illumos», а саме NexentaOS, але то вже зовсім інша історія.

Які проблеми довелося вирішувати

Повертаємось до нашого проєкту. З самого початку ми використовували ARM (Graviton процесори власної розробки AWS) для RDS Aurora for MySQL. Це безпрограшне рішення, яке ми типово використовуємо на кожному проєкті, і не мали жодних проблем.

Наші Lambda функції, написані на Python і досить нескладні, відповідають за додатковий функціонал, тому тут теж не було жодних проблем з використанням ARM. Якщо ваш проєкт на Python має багато залежностей, то можуть виникати складнощі з міграцією.

У нас є деякі проєкти, де ми поки не можемо мігрувати на ARM, тому що частина залежностей на ньому не збираються.

Як не дивно, з ElasticCache Redis на інстансах m6g є проблеми, якщо у вас увімкнутий TLS (а я дуже сподіваюсь, що це так). Навіть підтримка AWS рекомендує використовувати m5 інстанси замість цього. У нашому випадку було достатньо використовувати t4g і наразі проблем з TLS немає.

OpenSearch (по суті форк ElasticSearch, допрацьований та підтримуваний AWS) працює на ARM-інстансах без якихось нарікань і не потребує додаткової уваги при створенні.

Що стосується EKS-кластеру, то все дуже залежить від того, які контейнери ви маєте запускати, а саме, чи є Docker імеджи зібрані під ARM64. У нашому випадку треба було перезібрати деякі імеджи — php-fpm_exporter (наразі вже має підтримку ARM64 по замовченню), missing-container-metrics, довелося оновити prometheus-stack та ще декілька додатків до сучасних версій.

Кластер у нас побудований виключно на SPOT інстансах і ми використовуємо Karpenter для створення воркер нод. Мігрували поступово, створили окремі Provisioners для ARM64 та AMD64 і використовували nodeSelector в залежності від того, чи є в нас необхідний імедж для ARM64.

Інструменти на допомогу

З managed services все майже без проблем, вам достатньо обрати тип інстансу, який відповідає потребам та побудований на ARM-архітектурі (сучасні покоління процесорів мають більшу продуктивність, на даний час це процесор Graviton 3, який представлений у c7g, m7g та r7g інстансах).

З міграцією застосунка складніше, він має компілюватися під потрібну архітектуру. Допомогти з міграцією може проєкт, який аналізує ваш код та показує місця, що треба переписати. Наразі є підтримка:

  • Python 3+
  • Java 8+
  • Go 1.11+
  • C, C++, Fortran

Якщо код ваш збирається під AMD64 і ви використовуєте контейнери, то вам необхідно подбати про те, щоб docker імеджи були зібрані під необхідну архітектуру (краще одразу під декілька, щоб мати можливість запускати на різних процесорах при необхідності).

Docker підтримує збірку кросплатформних імеджей за допомогою плагіну buildx, але я рекомендую використовувати buildah, який не потребує наявності docker socket файлу, і ви можете не використовувати Docker-in-Docker, а запускати збірку навіть на ранерах в Kubernetes.

Все, що вам потрібно, — це виконати команди, які зберуть вам імеджі під дві архітектури та додадуть їх до registry:

buildah login -u "registry_username" -p "registry_password" registry_url
buildah bud --manifest your_image:tag --jobs=2 --platform=linux/arm64/v8,linux/amd64 -f Dockerfile .
buildah manifest push your_image:tag docker://registry_url/your_image:tag --all

Якщо ви використовуєте для збірки машину з AMD64, то можете помітити, що контейнер для ARM64 буде збиратися повільніше (якщо виконується компіляція). Це тому, що в такому випадку відбувається емуляція необхідної архітектури. Якщо це критично, і ви хочете зменшити час роботи вашого пайплайну, має сенс розглянути використання ранерів під кожну архітектуру окремо, щоб уникнути емуляції.

Підібʼємо підсумки

На даний час 99% нашого проєкту працює на ARM, і цей один відсоток залишається лише тому, що master ноди EKS (до яких ми не маємо доступу) чомусь працюють на AMD64. Як на мене, це виглядає дивним (гей, AWS, допомогти з міграцією?). Це невеликий проєкт, за який клієнт платить приблизно $6000 на місяць. Попри міграцію кластера, економічна вигода не була настільки великою, оскільки різниця між вартістю SPOT на AMD64 та ARM64 незначна в абсолютних числах. Використання гравітонів для бази та Redis дає в нашому випадку суттєвішу економію.

На жаль, ми не робили аналізу «до та після» міграції, щоб перевірити, чи насправді інстанси на гравітоні надають перевагу в продуктивності порівняно з Intel та AMD процесорами. У нашому випадку було достатньо того, що вона не гірша, і ми можемо використовувати ті самі інстанси за розміром і платити за них меншу ціну.

Як ви бачите, оптимізацію витрат за допомогою переходу на ARM для managed сервісів можна віднести до першочергових, оскільки це не потребує від вас багато зусиль. У разі міграції самих застосунків — тут все залежить від того, чи є у вас певні залежності, які не підтримують компіляцію під ARM. Якщо ні — має сенс витратити декілька днів і спробувати мігрувати.

Безсумнівно, ваша команда розробників в компанії буде цінувати це, оскільки тепер вони зможуть запускати нативні Docker-імеджі на своїх Macbook M1/M2 без потреби у використанні емуляції.

Гайда в коментарі, хочу почути про ваш досвід використання ARM інстансів в AWS та інших хмарах (у мене немає такого досвіду). Ставте запитання, буду радий долучитися до діалогу.

Якщо вам потрібна допомога з міграцією або з модернізації інфраструктури в AWS, наша команда залюбки допоможе. Підписуйтесь на YouTube-канал @DevOpsTalksAtOpsworks та долучайтеся до онлайн-вебінарів, які ми проводимо.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Чи є життя на ARM-і

Збілдити і як-небудь запустити можна практично все, але принаймні на рівні пет-проектів на локальній залізяці, х64 все ж має ряд переваг:
1) docker, appimage, snap. Не всі автори думають про альтернативні платформи і викладають сурси з актуальними інструкціями для збірки, апдейтити також доведеться самостійно.
2) віртуалізація просто і ефективно працює
3) з апдейтами практично під всі одноплатні комп’ютери все сумно, про можливість просто зробити do-release-upgrade і у випадку проблем зайти через ремоут консоль, а не фізично розбирати і перешивати системний накопичувач можна забути
4) бувають написані аби як апки, які терпить х64, але під arm рандомні падіння з SIGBUS і подібними помилками
5) обвіс дешевого одноплатного комп’ютера довговічним стореджем, який не здохне від логів, джерелом безперебійного живлення для коректного вимикання, виділення йому мережі, виготовлення корпусу — це справжня каша з сокири, яка разом з витратами часу легко переважить у ціні готовий невеликий сервер на х64
6) апетит приходить під час їжі, навішати, наприклад, до vpn і серверу для бекапів ще якесь відеоспостереження чи втулити відеокарту і бавитись з нейронними мережами простіше, коли залізяка відразу має запас потужності і модульності

Цікавий досвід. Мені на думку спадають лише якісь DVR, які можуть не мати підтримки ARM або проблеми, з рештою не стикався. Велика комʼюніті навколо малинки популяризувала ARM і маємо багато проектів на любий смак адаптованих під неї. У Jeff Geering є багато прикладів з різними платами і девайсами, я лише дивився але сам не грався.

Прив’язка до Raspberry Pi дійсно вирішує багато проблем, але п.5 лишається актуальним — ставити повноцінний великий ДБЖ від APC або Powercom до мінімальної і економної системи якось дивно, а у вигляді шилдів — це або самому розробляти, паяти, писати софт для керування системою, або купувати і шукати як доставити за немалі гроші готові. Тобто цим цікаво зайнятись як задачею у собі, але якщо кінцева мета — це захостити вдома пошту або власну хмару, економічно вигідніше купити щось типу HP Microserver.

Єдине що, не пробував Mac Mini M1/M2, можливо у подібного сервера є сенс вже чисто за рахунок однопоточної продуктивності для певних задач.

х64

«x64» це суто віндовий термін (навіть не Intel). Для юніксів — x86-64 чи amd64, а x64 тут означає «будь-яка 64-бітна архітектура». Прошу тримати контекст і використовувати правильні слова.

і у випадку проблем зайти через ремоут консоль, а не фізично розбирати і перешивати системний накопичувач можна забути

Тому їх зазвичай ділять на два (якийсь початковий bootloader і решта після нього).

бувають написані аби як апки, які терпить х64, але під arm рандомні падіння з SIGBUS і подібними помилками

Якась недоробка на зразок атомарного доступу по невирівненій змінній. Десь просто відсутня синхронізація, бо для x86 невимиковна TSO захищає від багатьох помилок (ціною, можливо, швидкости).

яка разом з витратами часу легко переважить у ціні готовий невеликий сервер

На ARM випускаються свої готові сервери... але їх треба пошукати.
Ціна поки сумнівна, але прогрес іде.

Так, звісно, мався на увазі amd64.

Тому їх зазвичай ділять на два (якийсь початковий bootloader і решта після нього).

Все так, але взаємодія з цим стартовим бутлоадером скрізь різна, у типових дистрибутивах рідко тестується сценарій апдейту засобами системного пакетного менеджера.
Навіть займаючись підтримкою відповідних дистрибутивів лінуксу професійно, мейнтейнити ще один заради чисто задач вебу — те ще задоволення, особливо в нинішній час, коли через блекаути часу фіксити збій може не бути.

Якась недоробка на зразок атомарного доступу по невирівненій змінній.

Так, і вони зустрічаються не так вже і рідко. Інколи очікувано, наприклад, у лібах для парсингу маловживаних мережевих протоколів, але бувають наприклад і у драйверах в ядрі лінукса під якусь китайську маловідому периферію, навіть знаючи де проблема, возитись з перезбіркою ядра для себе окремо від дистрибутиву приємного мало.
І це стосується не тільки підключення якогось нетипового заліза — ловив помилки такого типу при заливках важких бекапів чи інших, чисто серверних, але великих навантаженнях.

Якщо ви працювали з 8086

І навіть 8080 у його совковій версії КР580ВМ80 ;-)

Не впевнений що там було в середині, але начебто аналог 8086. Мій перший компʼютер «Электроника МС 1502» )

В OracleCloud можна бескоштовно отримати 4ядерний арм з 20Гб оперативи.

Сам не пробував але чув від колег (десь три тижні тому), що воно начебто і можна, але то картка йому не подобається або сприймає картку але не створює аккаунт. Ну а саппорт OracleCloud не дуже спішить допомагати з таким кейсом.

Так, з Приват карткою в мене теж не виходило. Зареєструватися з карткою польського банку. Спробуйте теж якусь не українську, або хоча б не Приват.

Так, саме польску прийняло але далі застопорилося. Скажу колезі щоб ще раз спробував.

В мене таких проблем не було, я запустив там сервер майнкрафту, по відчуттям воно не дуже швидке, та напевно найшвидший варіант з бескоштовних

Знову перевірили — той самий ефект, картку прийняло але на етапі “Start my free trial” ловимо помилку “The number of requests has been exceeded. Reload the page or retry the operation. If the problem persists, then contact Oracle Support”. Тобто все так як було, релоад не допомогає, сапорт допомогти не може )

Дякую — взяв корисне для себе щодо buildah і зрозумів чого це тупить коли збірка під дві архітектури 😄. Щодо ARM — повноцінно юзаємо t4g та інші більш важкі інстанси = політ норм. Ну і звісно ж єкономія на костах із за того що це нова архітектура/покоління)

> Або, якщо мали справу з мобільною розробкою, — згадають про ARMv7.

Якщо маєш на увазі 32-бітний ARM... прямо зараз бачу проект де він в повний ріст і це не мобільна розробка, а повноцінна окрема залізяка з дохрена ресурсів.
Наголошений, так, застарілим, але до повного звертання ще роки.

> На жаль, я не можу нічого сказати про досвід тих колег, хто працював з RISK-процесорами, такими як: DEC Alpha, Atmel AVR, Blackfin, Intel i860, Intel i960, LoongArch, Motorola 88000, MIPS architecture, PA-RISC, Power ISA, RISC-V, SuperH, SPARC.

«Змішались в купу коні, люди...»
RISC-V тільки пару років як почав виходити у залізо (ну і 5 років для напів-іграшок типу Rasp.Pi). Те ж саме про LoongArch, але для Китаю. POWER в повний зріст, але дуже мала імовірность потрапити на нього, якщо явно не шукаєш. AVR в кожній ардуїні, купуй і тирань на повну (як і RISC-V, купити не проблема), але називати його RISC якось дивно. Занадто багато різного в одній низці імен.

Але все це поки що далеко від великого сексу:) Ось візьміть віртуалку на SystemZ і спробуйте той же самий софт. Половина тупо не запуститься бо не розрахована на bigendian... Деякі відкрито визнають це, як з Cassandra. А більшість інших просто не знає про проблему. ARM порівняно з цим це банальність...

> У нас є деякі проєкти, де ми поки не можемо мігрувати на ARM, тому що частина залежностей на ньому не збираються.

Це дивно. Мабуть, хтось просто перевумничав і завʼязався на детект платформи.

Чи пробує оптимізувати тонкі місця асемблером (хоча це зараз майже ніколи не корисно).

Можете назвати імена?

> Використання гравітонів для бази та Redis дає в нашому випадку суттєвішу економію.

Ось це цікаво. Є уявлення, за рахунок чого таке стається?

PS: По назві статті подумав про якийсь «ARM-i» :)

«Змішались в купу коні, люди...»

Ну так тут очевидно :) Для мене це дійсно лише гарні назви, які зустрічалися у новинах або в розсилках. Інколи навіть читав про проблеми з якими стикаються інженери при роботі з ними, як ті що наведені у вас.

Чи пробує оптимізувати тонкі місця асемблером (хоча це зараз майже ніколи не корисно).
Можете назвати імена?

Один з проектів це скрапінг даних, гляну які там залежності та відпишусь.

> Використання гравітонів для бази та Redis дає в нашому випадку суттєвішу економію.
Ось це цікаво. Є уявлення, за рахунок чого таке стається?

Можливо я не зовсім коректно пояснив. Мова йде про RDS Aurora for MySQL and ElasticCache for Redis. В нашому випадку бази достатньо великі і ми маємо Writer/Reader setup. Якщо порівняти вартість db.r5.2xlarge = $934.4 і db.r6g.2xlarge = $845.34 то це $89.06 на writer і стільки ж на reader. Без докладання жодних зусиль, просто обравши інший тип інстансу.

Якщо порівняти вартість спот інстансів — то t3a.xlarge ~= $100 і t4g.xlarge ~= 95$ (залежить від AZ) ми маємо економію у 5$ при середній кількості інстансів ~10. При цьому нам потрібно докладати зусиль щоб все це налаштувати.

Згоден, що в кожному окремому випадку треба відштовхуватися від витрат по кожній категоріх і результат буде відрізнятися від наведеного мною.

PS: По назві статті подумав про якийсь «ARM-i» :)

В моїй голові воно звучало краще ніж коли опинилося у тексті :)

Нарешті дійшли руки глянути що там фейлиться:

67.84 make -e -C modules/common libaerospike-common.a 67.84 make[1]: Entering directory '/temp_build/aerospike-client-c/modules/common' 67.91 cc -Isrc/include -std=gnu99 -g -Wall -fPIC -O3 -fno-common -fno-strict-aliasing -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -march=nocona -finline-functions -rdynamic -o target/Linux-aarch64/obj/common/aerospike/as_aerospike.o -c src/main/aerospike/as_aerospike.c 67.92 cc1: error: unknown value 'nocona' for -march 67.92 cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a native

Причина — ARM support wasn’t added until Aerospike Client Library version 8.0.0.
Наскільки важко перейти на свіжишу версію я не знаю

cc1: error: unknown value ’nocona’ for -march

Ну це точно значить що в цій версії крім x86 про інше і не думали.

Причина — ARM support wasn’t added until Aerospike Client Library version 8.0.0.

Угу:)

Стосовно AWS Aurora та r6g (Graviton2) інстансів, то вони дещо повільніщі за Інтеловські, особливо для маленьких інстансів, а от r7g (Graviton3) виглядає помітно краще за r6g. А так працюють, проблем/багів теж не помічав.

Цікаво, не вимірював і не помічав якоїсь різниці. Ваш досвід стосується якої саме, Aurora for MySQL чи Aurora for PostgreSQL?

Aurora MySQL. Під «повільніщі» я маю на увазі дві речі: дещо вищій CPUUtilization на ARM при однаковій нагрузці та дещо повільніщі запити на запис (commit, insert, delete, update).

Дякую, цікаво. Треба буде якось заміряти.

привіт! дякую за статтю!
Теж почали використовувати ARM для одного продукту, використовуємо у стекі разом з EKS та karpenter, користоуємось вже десь 4-6 місяців — політ відмінний. Якоїсь суттєвої продуктивності у порівннянні відмітити не можу, бо запускались одразу на гравітонах.
Щодо збірки імеджів — то це дуже влучно, і в нашому випадку під різні архітектури ми збираємо на різних відповідних білд нодах.

Привіт. Просто цікаво, у вас гітхаб? Наче лише вони надають доступ до різних архітектур, у решти на селф хостед ранерах можливо нібито це робити.

Так, gh, але сі в нас побудовано на jenkins

Підписатись на коментарі