Salve, comunità di Habr! Recentemente ho scritto riguardo alla nostra scheda cluster di prima generazione []. Oggi voglio raccontarvi come abbiamo lavorato alla versione memoria volatile.
Siamo appassionati di mini server che possono essere utilizzati sia per lo sviluppo locale che per l'hosting locale. A differenza dei computer desktop o dei laptop, i nostri server sono progettati per operare 24/7 e possono essere rapidamente collegati in federazione; ad esempio, avevamo 4 processori nel cluster e dopo 5 minuti ce ne erano 16 (senza attrezzature di rete aggiuntive), il tutto in un fattore di forma compatto, silenzioso ed energeticamente efficiente.
La nostra architettura server si basa sul principio del clustering, cioè costruiamo schede cluster che collegano diversi moduli di calcolo (processori) tramite una rete ethernet sulla scheda. Per semplificare, al momento non produciamo i nostri moduli di calcolo, ma utilizziamo i Raspberry Pi Compute Modules e speravamo molto nel nuovo modulo CM4. Tuttavia, tutto è andato contrariamente ai piani con il loro nuovo fattore di forma e penso che molti siano delusi.
Di seguito, come siamo passati da V1 a V2 e come abbiamo dovuto arrangiarci con il nuovo fattore di forma del Raspberry Pi CM4.
Quindi, dopo aver creato un cluster di 7 nodi, quali sono le prossime mosse? Come aumentare il valore del prodotto? 8, 10 o 16 nodi? Quali produttori di moduli? Riflettendo sul prodotto nel suo insieme, abbiamo capito che qui la cosa fondamentale 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, sarà un cluster e avrà anche la capacità di collegare dischi e schede di espansione. Il blocco cluster deve essere un nodo autonomo di base con ampie possibilità di espansione.
Il secondo, affinché i blocchi cluster minimi possano essere collegati tra loro creando cluster di dimensioni maggiori e affinché questo sia efficace dal punto di vista del budget e della velocità di scalabilità. La velocità di scalabilità dovrebbe essere superiore a quella di unire normali computer in rete e molto più economica rispetto all'hardware server.
Terzo, i blocchi cluster minimi devono essere abbastanza compatti, mobili, efficienti dal punto di vista energetico, cost-effective e poco esigenti in termini di condizioni operative. Questo è uno dei principali punti di differenza rispetto ai server rack e a tutto ciò che riguarda.
Abbiamo iniziato definendo il numero di nodi.
Numero di nodi
Con semplici ragionamenti logici, abbiamo capito che 4 nodi sono la migliore opzione per un blocco cluster minimo. 1 nodo non è un cluster, 2 nodi sono pochi (1 master 1 worker, non c'è possibilità di scalabilità all'interno del blocco, specialmente per varianti eterogenee), 3 nodi sembrano ok, ma non sono un multiplo delle potenze di 2 e la scalabilità all'interno del blocco è limitata; 6 nodi costano quasi quanto 7 nodi (dalla nostra esperienza, questo è già un costo elevato), 8 nodi sono troppi, non rientrano nel fattore di forma mini ITX e costituiscono una soluzione ancora più costosa per un PoC.
Riteniamo che quattro nodi per blocco siano il punto d'equilibrio:
- meno materiali per la scheda cluster, quindi produzione più economica
- multipli di 4, in totale 4 blocchi danno 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 fattore di forma SODIMM. Ma...
Abbiamo deciso di realizzare una scheda figlia SODIMM e assemblare il CM4 direttamente nei moduli, così gli utenti non devono pensare al CM4.
Modulo di elaborazione Turing Pi con supporto per Raspberry Pi CM4
Esplorando i moduli, è emerso un intero mercato di moduli calcolatori, da piccoli moduli da 128 MB di RAM a 8 GB di RAM. In arrivo moduli da 16 GB di RAM e oltre. Per l'edge hosting di applicazioni basate su tecnologie cloud native, 1 GB di RAM è ormai insufficiente, mentre la recente introduzione di moduli da 2, 4 e persino 8 GB di RAM offre ampie possibilità di crescita. Abbiamo anche considerato versioni con moduli FPGA per applicazioni di machine learning, ma il loro supporto è stato posticipato a causa dell'assenza di un ecosistema software sviluppato. Durante l'analisi del mercato dei moduli, è nata l'idea di creare un'interfaccia universale per i moduli e nella versione V2 iniziamo l'unificazione dell'interfaccia dei moduli di elaborazione. Questo permetterà ai possessori della versione V2 di collegare moduli di altri produttori e combinarli per compiti specifici.
La V2 supporta l'intera gamma del Raspberry Pi 4 Compute Module (CM4), comprese 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 trovano le periferiche. Il bus PCI è uno standard per i dispositivi periferici ed è presente nella maggior parte dei moduli computazionali. Abbiamo diversi nodi e idealmente vorremmo che ciascun nodo potesse condividere i dispositivi PCI in modalità di richieste concorrenti. Ad esempio, se si tratta di un disco connesso al bus, deve essere accessibile da tutti i nodi. Abbiamo iniziato a cercare switch PCI con supporto multi-host e abbiamo scoperto che nessuno di essi soddisfaceva i nostri requisiti. Tutte queste soluzioni erano principalmente limitate a 1 host o a più host, ma senza modalità di richieste concorrenti agli endpoint. Il secondo problema è l'alto costo, a partire da $50 e oltre per chip. Nella V2 abbiamo deciso di rimandare gli esperimenti con gli switch PCI (ci torneremo più avanti man mano che ci svilupperemo) e abbiamo optato per assegnare ruoli 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, si può utilizzare un file system di rete all'interno del cluster. Perché no?
Anteprima
Abbiamo deciso di condividere alcuni schizzi su come è evoluto nel tempo il blocco cluster minimo durante le nostre discussioni e riflessioni.
Di conseguenza, siamo arrivati a un blocco cluster con 4 nodi da 260 pin, 2 porte mini PCIe (Gen 2) e 2 porte SATA (Gen 3). La scheda è dotata di uno switch Layer-2 gestito con supporto VLAN. Dalla prima nodo è stata tirata fuori una porta mini PCIe, nella quale è possibile installare una scheda di rete e ottenere un'ulteriore porta Ethernet o un modem 5G, trasformando quindi la prima nodo in un router per la rete del cluster e le porte Ethernet.
Il bus del cluster ha più funzionalità, comprese la possibilità di aggiornare i moduli direttamente attraverso tutte le porte e, naturalmente, i connettori FAN su ogni nodo con controllo della velocità.
Applicazione
Infrastruttura edge per applicazioni e servizi self-hosted
Abbiamo progettato V2 per utilizzarla come blocco costruttivo fondamentale per infrastrutture edge di livello consumer/commerciale. Con V2, è facile iniziare a testare il concetto e scalare man mano che cresce, trasferendo gradualmente le applicazioni che è più economico e pratico ospitare nell'edge. I blocchi di cluster possono essere uniti, formando cluster di dimensioni maggiori. Questo può essere fatto gradualmente senza rischi significativi per i processi consolidati.
Già oggi ci sono moltissime applicazioni aziendali .
ARM Workstation
Con una memoria fino a 32 GB di RAM per cluster, il primo nodo può essere utilizzato per una versione desktop del sistema operativo (ad esempio Ubuntu Desktop 20.04 LTS) e gli altri 3 nodi per compiti di compilazione,.testing e debugging, sviluppo di soluzioni cloud native per cluster ARM. Come nodo per CI/CD nella periferica infrastruttura in produzione.
Il cluster Turing V2 con moduli CM4 è architettonicamente quasi identico (la differenza è nelle versioni minori di ARMv8) al cluster basato su istanze AWS Graviton. Nel processore dei moduli CM4 viene utilizzata l'architettura ARMv8, puoi costruire immagini e applicazioni per le istanze AWS Graviton 1 e 2, che, come è noto, sono molto più economiche delle istanze x86.
Fonte: habr.com
