Salve, comunità di Habr! Recentemente ho scritto della nostra scheda madre di prima versione []. E oggi voglio raccontare come abbiamo lavorato sulla versione di memoria RAM.
Siamo appassionati di mini server che possono essere utilizzati sia per sviluppo locale che per hosting locale. A differenza dei computer desktop o dei laptop, i nostri server sono progettati per funzionare 24/7 e possono essere rapidamente uniti in federazione, ad esempio, se inizialmente avevamo 4 processori nel cluster, dopo 5 minuti siamo passati a 16 processori (senza attrezzatura di rete aggiuntiva) e tutto questo in un formato compatto, silenzioso ed energeticamente efficiente.
Alla base dell'architettura dei nostri server c'è il principio di costruzione a cluster, cioè realizziamo schede di cluster che, tramite una rete ethernet sulla scheda, collegano più moduli di calcolo (processori). Per semplificare, per ora non realizziamo i nostri moduli di calcolo, ma utilizziamo i moduli Raspberry Pi Compute e speravamo molto nel nuovo modulo CM4. Tuttavia, tutto è andato contro i piani con il loro nuovo formato e penso che molti siano delusi.
Qui sotto trovi come siamo passati da V1 a V2 e come abbiamo dovuto adattarci al nuovo formato del Raspberry Pi CM4.
Quindi, dopo aver creato un cluster di 7 nodi, ci si chiede: quale sarà il passo successivo? Come aumentare il valore del prodotto? 8, 10 o 16 nodi? Quali produttori di moduli? Riflettendo sul prodotto nel suo insieme, ci siamo resi conto che la questione principale non è il numero di nodi o chi è il produttore, ma l'essenza stessa dei cluster come blocco costruttivo. Dobbiamo cercare il blocco costruttivo minimo che
Primo, rappresenterà un cluster e avrà anche la possibilità di connettere dischi e schede di espansione. Il blocco cluster deve essere un nodo autonomo di base e con ampie possibilità di espansione.
Secondo, affinché i blocchi cluster minimi possano connettersi tra loro, formando cluster di dimensioni maggiori, e affinché ciò sia efficiente in termini di budget e velocità di scalabilità. La velocità di scalabilità deve essere superiore a quella di collegare normali computer in rete ed essere molto più economica rispetto all'hardware server.
Terzo, i blocchi cluster minimi devono essere sufficientemente compatti, mobili, energeticamente efficienti, cost-effective e non esigenti in termini di condizioni operative. Questa è una delle principali differenze rispetto ai rack server e a tutto ciò che li riguarda.
Abbiamo iniziato definendo il numero di nodi.
Numero di nodi
Con semplici ragionamenti logici abbiamo capito che 4 nodi sono la scelta migliore per un blocco di cluster minimo. 1 nodo non è un cluster, 2 nodi sono pochi (1 master 1 worker, manca la possibilità di scalabilità all'interno del blocco, soprattutto per le varianti eterogenee), 3 nodi sembrano ok, ma non sono multipli di potenze di 2 e la scalabilità è limitata all'interno del blocco, 6 nodi costano quasi quanto 7 nodi (dalla nostra esperienza, questo è già un costo elevato), 8 sono troppi, non si adattano nel fattore di forma mini ITX e sono una soluzione ancora più costosa per il PoC.
Quattro nodi per blocco sono considerati il giusto mezzo:
- meno materiali per la scheda del cluster, quindi una produzione più economica
- multiplo di 4, in totale 4 blocchi forniscono 16 processori fisici
- schema stabile 1 master e 3 worker
- maggiore varietà eterogenea, moduli general-compute + accelerated-compute
- fattore di forma mini ITX con dischi SSD e schede di espansione
Moduli computazionali
La seconda versione si basa su CM4, pensavamo che l'avrebbero rilasciata nel formato SODIMM. Ma...
Abbiamo deciso di realizzare una scheda secondaria SODIMM e assemblare il CM4 direttamente nei moduli affinché gli utenti non debbano preoccuparsi del CM4.
Modulo di calcolo Turing Pi con supporto per Raspberry Pi CM4
In effetti, nella ricerca dei moduli è emerso un intero mercato di moduli computazionali, da piccoli moduli con 128 MB di RAM fino a 8 GB di RAM. In arrivo moduli con 16 GB di RAM e oltre. Per l'hosting edge di applicazioni basate su tecnologie cloud native, 1 GB di RAM è già poco, e l'emergere recente di moduli con 2, 4 e persino 8 GB di RAM offre una buona possibilità di crescita. Abbiamo anche considerato opzioni con moduli FPGA per applicazioni di machine learning, ma il loro supporto è stato ritardato a causa della mancata evoluzione dell'ecosistema software. Durante lo studio del mercato dei moduli, siamo giunti all'idea di creare un'interfaccia universale per i moduli e nella V2 iniziamo l'unificazione dell'interfaccia dei moduli computazionali. Questo permetterà ai proprietari della versione V2 di collegare moduli di altri produttori e combinarli per compiti specifici.
La V2 supporta l'intera gamma di Raspberry Pi 4 Compute Module (CM4), incluse le versioni Lite e i moduli con 8 GB di RAM.
Periferica
Dopo aver definito il fornitore dei moduli e il numero di nodi, siamo arrivati al bus PCI, su cui si trova la periferia. Il bus PCI è uno standard per i dispositivi periferici ed è presente quasi in tutti i moduli di calcolo. Abbiamo diversi nodi e idealmente ogni nodo dovrebbe poter condividere i dispositivi PCI in modalità di richieste concorrenti. Ad esempio, se si tratta di un disco collegato al bus, allora è disponibile per tutti i nodi. Abbiamo iniziato a cercare switch PCI con supporto per multi-host e abbiamo scoperto che nessuno di essi soddisfa i nostri requisiti. Tutte queste soluzioni erano in gran parte limitate a 1 host o a più host, ma senza modalità di richieste concorrenti agli endpoints. Il secondo problema è l'alto costo, a partire da $50 e oltre per chip. In V2 abbiamo deciso di rimandare gli esperimenti con gli switch PCI (ci torneremo più avanti man mano che ci sviluppiamo) e abbiamo optato per l'assegnazione di un ruolo a ciascun nodo: i primi due nodi esponevano una porta mini PCI express per nodo, il terzo nodo esponeva un controller SATA a 2 porte da 6 Gbps. Per accedere ai dischi da altri nodi, è possibile utilizzare un file system di rete all'interno del cluster. Perché no?
Anteprima
Abbiamo deciso di condividere alcuni schizzi di come è evoluto il blocco di cluster minimo nel tempo durante il processo di discussione e riflessione
Di conseguenza siamo arrivati a un blocco di cluster con 4 nodi a 260-pin, 2 porte mini PCIe (Gen 2), 2 porte SATA (Gen 3). Sulla scheda è installato uno switch gestito Layer-2 con supporto VLAN. Dalla prima nodo è stata estratta una porta mini PCIe, in cui è possibile installare una scheda di rete e ottenere un'altra porta Ethernet o un modem 5G e trasformare il primo nodo in un router per la rete del cluster e delle porte Ethernet.
Il bus di cluster ha più funzionalità, inclusa la possibilità di programmare i moduli direttamente attraverso tutte le slot e naturalmente con connettori FAN su ogni nodo con controllo della velocità.
Applicazione
Infrastruttura edge per applicazioni e servizi auto-ospitati
Abbiamo progettato V2 con l'obiettivo di utilizzarla come blocco costruttivo minimo per un'infrastruttura edge di livello consumer/commerciale. Con V2 è economico iniziare a testare il concetto e scalare man mano che cresce, trasferendo gradualmente le applicazioni che è più conveniente e pratico ospitare in edge. I blocchi di cluster possono essere collegati insieme, creando cluster di dimensioni maggiori. Questo può essere fatto gradualmente senza particolari rischi per ciò che è già consolidato.
processi. Già oggi ci sono un'enorme quantità di applicazioni per il business, .
ARM Workstation
Con una memoria operativa fino a 32 GB RAM per cluster, la prima node può essere utilizzata per la versione desktop del sistema operativo (ad esempio Ubuntu Desktop 20.04 LTS) e le rimanenti 3 node per attività di compilazione, testing e debugging, sviluppo di soluzioni cloud native per cluster ARM. Come nodo per CI/CD sull'infrastruttura ARM periferica in produzione.
Il cluster Turing V2 con moduli CM4 è architettonicamente quasi identico (la differenza è nelle versioni minori di ARMv8) a un cluster basato su istanze AWS Graviton. Nel processore dei moduli CM4 è utilizzata l'architettura ARMv8, puoi creare immagini e applicazioni per le istanze AWS Graviton 1 e 2, che sono notevolmente più economiche delle istanze x86.
Fonte: habr.com
