Мини ITX клъстер Turing Pi 2 с 32 GB RAM

Здравейте, Хабр общност! Скоро писах за нашата клъстерна дъска от първа версия [V1]. Днес искам да разкажа как работихме по версия Turing V2 с 32 GB оперативната памет.

Ние сме запалени по мини сървъри, които могат да се използват както за локално разработване, така и за локален хостинг. За разлика от десктоп компютри или лаптопи, нашите сървъри са създадени да работят 24/7, бързо се свързват в федерация, например, 4 процесора в клъстера могат да станат 16 за 5 минути (без допълнително мрежово оборудване) и всичко това в компактен форм-фактор, безшумно и енергийно ефективно.

В основата на архитектурата на нашите сървъри е клъстерният принцип на изграждане, т.е. ние правим клъстерни дъски, които свързват няколко изчислителни модула (процессори) чрез ethernet мрежа на платката. За опростяване в момента не правим свои изчислителни модули, а използваме Raspberry Pi Compute Modules и много се надявахме на новия модул CM4. Но всичко тръгна в неправилна посока с новия им форм-фактор и мисля, че много хора са разочаровани.

Под кат ще покажем как минахме от V1 до V2 и как се наложи да се справим с новия форм-фактор на Raspberry Pi CM4.

И така, след създаването на клъстер с 7 нода, въпросът е — какво следва? Как да увеличим стойността на продукта? 8, 10 или 16 нода? Кои са производители на модулите? Размисляйки за продукта в цялост, осъзнахме, че основното нещо не е броят на нодите или кой е производителят, а самата същност на клъстерите като строителен блок. Трябва да намерим минималния строителен блок, който

Първо, ще бъде кластер и в същото време да има възможност за свързване на дискове и разширителни платки. Клъстерният блок трябва да бъде самодостатъчен базов модул с широки възможности за разширение.

Второ, така че минималните клъстерни блокове да могат да се свързват помежду си, изграждайки по-големи клъстери, и това да бъде ефективно по отношение на бюджета и скоростта на мащабиране. Скоростта на мащабиране трябва да бъде по-висока от свързването на обикновени компютри в мрежа и значително по-евтина от сървърното оборудване.

Трето, минималните клъстерни блокове трябва да бъдат достатъчно компактни, мобилни, енергийно ефективни, икономически изгодни и не изискващи специални условия за експлоатация. Това е едно от ключовите различия от сървърните рафтове и всичко, свързано с тях.

Започнахме с определяне на броя на нодовете.

Брой на нодовете

С прости логически заключения осъзнахме, че 4 нода е най-добрият вариант за минимален кластерен блок. 1 нода не е кластер, 2 нода са недостатъчни (1 майстор, 1 работник, няма възможност за мащабиране в рамките на блока, особено за хетерогенни варианти), 3 нода изглеждат добре, но не са кратни на степените на 2 и са ограничени в мащабирането в рамките на блока, 6 нода излизат почти на цената на 7 нода (от нашия опит това вече е висока себестойност), 8 е много, не се вписва в mini ITX форм фактор и е още по-скъпо решение за PoC.

Четирите нода на блок считаме за златна среда:

• по-малко материали за кластерната платка, следователно по-евтино производство
• кратни на 4, общо 4 блока дават 16 физически процесора
• стабилна схема 1 майстор и 3 работника
• повече хетерогенни вариации, модули за общо изчисление + ускорено изчисление
• мини ITX форм-фактор с SSD дискове и платки за разширение

Изчислителни модули

Втората версия е базирана на CM4, мислехме, че ще я пуснат в SODIMM форм-фактор. Но...
Взехме решение да направим дъщерна платка SODIMM и да съберем CM4 директно в модули, за да не се налага на потребителите да мислят за CM4.

Turing Pi Compute Module с поддръжка за Raspberry Pi CM4

Изобщо, при търсенето на модули се откри целия пазар на изчислителни модули от малки модули с 128 MB RAM до 8 GB RAM. Предстоят модули с 16 GB RAM и повече. За крайно хостинг на приложения, базирани на cloud native технологии 1 GB RAM вече е малко, а наскоро появилите се модули с 2, 4 и дори 8 GB RAM предлагат добро пространство за растеж. Дори обмисляхме варианти с FPGA модули за приложения на машинно обучение, но тяхната поддръжка е отложена, тъй като софтуерната екосистема не е развита. По време на проучването на пазара на модули стигнахме до идеята за създаване на универсален интерфейс за модулите и в V2 започваме унификация на интерфейса на изчислителните модули. Това ще позволи на собствениците на версия V2 да свързват модули на други производители и да ги смесват според конкретни задачи.

V2 поддържа цялата линия Raspberry Pi 4 Compute Module (CM4), включително Lite версии и модули с 8 GB RAM

Перферия

След като определихме доставчика на модули и броя на възлите, се насочихме към PCI шина, на която се намират периферни устройства. PCI шина е стандарт за периферни устройства и присъства почти във всички изчислителни модули. Имаме няколко възла и в идеалния случай всеки възел трябва да може да споделя PCI устройства в режим на конкурентни заявки. Например, ако това е диск, свързан към шината, той трябва да бъде достъпен за всички възли. Започнахме да търсим PCI суичове с възможност за поддръжка на мултихост и установихме, че нито един от тях не отговаря на нашите изисквания. Всички тези решения в основната си част бяха ограничени до 1 хост или мулти хостове, но без режим на конкурентни заявки към точки на достъп. Вторият проблем е високата цена от $50 и повече за чип. В V2 решихме да отложим експериментите с PCI суичове (ще се върнем към тях по-късно, когато се развие проектът) и избрахме да назначим роля за всеки възел: първите два възла предлагат мини PCI експрес порт на възел, третият възел предлага 2 порта 6 Gbps SATA контролер. За достъп до дисковете от други възли може да се използва мрежовата файлова система в рамките на кластера. Защо не?

Sneakpeek

Решихме да споделим някои скици, как минималният клъстерен блок е еволюирал с времето в процеса на обсъждане и размисъл

В резултат на това стигнахме до клъстерен блок с 4 възела 260-pin, 2 мини PCIe (Gen 2) порта, 2 SATA (Gen 3) порта. На платката е инсталиран Layer-2 Managed Switch с поддръжка на VLAN. От първия възел е изведен мини PCIe порт, в който може да се инсталира мрежова карта и да се получи още един Ethernet порт или 5G модем и да се направи от първия възел рутер за мрежата в клъстера и Ethernet портовете.

Клъстерната шина има повече функции, включително възможността за флашване на модули директно през всички слотове и, разбира се, FAN конектори на всеки възел с контрол на скоростта.

Приложение

Edge инфраструктура за самостоятелно хоствани приложения и услуги

Проектирахме V2 с цел да я използваме като минимален строителен блок за потребителска/търговска edge инфраструктура. С V2 е лесно да започнете проверка на концепцията и да се мащабирате, постепенно прехвърляйки приложения, които икономически и практически е по-разумно да се хостват в edge. Клъстерните блокове могат да бъдат свързани помежду си, изграждайки по-големи клъстери. Това може да стане постепенно, без значителни рискове за установените.
процесите. Вече днес има огромен брой приложения за бизнес, които могат да се хостват локално.

ARM работна станция

С оперативна памет до 32 GB RAM на клъстера, първият възел може да се използва за настолна версия на ОС (например Ubuntu Desktop 20.04 LTS) и останалите 3 възела за задачи по компилиране, тестване и отстраняване на грешки, разработка на облачно родни решения за ARM клъстери. Като възел за CI/CD на ARM периферна инфраструктура в продукция.

Клъстерът Turing V2 с модули CM4 е архитектурно почти идентичен (разликата е в минорните версии на ARMv8) с клъстера на базата на инстанциите AWS Graviton. В процесора на модулите CM4 се използва архитектура ARMv8, можете да изграждате образи и приложения за AWS инстанции Graviton 1 и 2, които, както е известно, са много по-евтини от инстанциите x86.

Източник: habr.com