Kombinera hypervisors till stor VM

Förutsatt att man har bandbredden för det, går det att med vanliga hypervisors kombinera alla trådar och minnen till en jättestor virtuell maskin som samlar alla deras resurser?

Vet att big-iron fungerar på det sättet men de har speciell hårdvara utöver snabba interconnects och de är inte virtualiserade.

Kanske detta? "VMware DRS" https://www.vmware.com/se/products/vsphere/drs-dpm.html
Inget jag själv labbat med dock

Säger inget på pappret om consolidation.

Hittade detta dock. Även om Epyc 7601 stödjer SMP setups så ser det ju ut som ett riktigt redigt kluster, betydligt fler än 4 CPU:er.

https://youtu.be/obQ3cCJ8rEY

De följer dock inte upp statsen med någon benchmark.

Definitivt inte någon vanlig hypervisor.

Vmware DRS är dessvärre något helt annat.

Det är till för att automatiskt flytta VMs mellan hostar i en miljö baserat på regler, tex belastningen på hosten/VMs, tex om en host står och gäspar, samtidigt som en annan är överbelastad så flyttas VM automatiskt för att skapa balans, till skillnad från HA som bara flyttar dem om en host av någon anledning slutar fungera helt.

Alla lösningar som löser önskat med mjukvara verkar vara nerlagda, inklusive ScaleMP som verkar uppköpt av SAP.

Vad är det för arbetsbörda du har i åtanke? Det är väldigt få scenarier där det finns en poäng med att ha en massiv maskin med enormt mycket systemresurser framför att sprida lasten på många mindre maskiner, "scale out, not up".

Ey grabbar ,vad gafflar ni om?

Vadå Kombinera hypervisors?

Du vill köra en jävla massa hårdvara till en enda VM?

1. Installera ESXI.
2. Installera VM.
3. Allokera alla resurser till vm.
4. Runka.



Vad är problemet?

1. Installera ESXi på typ 5 maskiner med specsen x
2. Gör dem till ett kluster
3. Allokera resurserna x ggr 5 till en VM
4. VMware säger nej. Bestämt nej. Det mesta du får allokera i ett kluster är specsen x ggr 1.
5. Runka och fäll en liten tår.

Virtualization for aggregation är ett koncept som inte stöds av de flesta hypervisors (än).

https://en.wikipedia.org/wiki/Virtualization_for_aggregation


Traditionell virtualisering delar upp maskiner i tårtbitar, distribuerad virtualisering som i ett ESXi kluster gör att tårtbitarna kan flyta mellan hypervisors, så att man får redundans och lastbalansering, men VM:arna får inte bli större än en individuell tårta.

Icke MPI kompatibla men SMP stödjande program. Tänker på bl.a OpenFOAM, RUST kompilering av stora program (bara 4k kod tar upp 64 GB minne) och FP64 intensiv machine learning. En Tesla A100 fixar 9.7 Tflops FP64 och kostar som en bil. En halvdan konsument CPU fixar 1-1.5. Har man tio så är man i kapp för kaffepengar i jämförelse.

Virtualization for aggregation verkar vara ren humbug. En enda referens i din länk från 2010. Ingen av de stora verkar ens titta på detta.

Det är inte så man jobbar med virtualisering.
Dessutom finns det som jag ser det ingen egentlig användning för sådan setup.

Fundera istället på:
Scenario 1: 1 st x86 server med dubbla cpu och en TB ram och kanske 200TB NVME disk. Detta är en standardmaskin i branchen. Behöver du mer än så till en enda VM för någonsomhelst operation?

Scenario 2: (redundans) 4st x86 servrar med DRS.

Scenario 3(recommended): Samma som 2 men istället för att använda en jätteVM så görs skalningen i applikationen. Antingen som flera VM's och LB eller som en container setup.


Jag förstår att tanken är lockande men den är värken smart, det används inte på riktigt och framförallt är det inte best practice att göra sådär.



En liten fråga där .. hur tänker du att exempelvis ram från maskin 1 skall kunna användas av maskin 2(där vi förutsätter att VM bor för tillfället) ?
Även om vi låtsas att vi kan göra detta över RDMA/INF med 40gibit länkar så kommer latency på komponenterna skjuta i höjden jämfört med att köra det lokalt och då faller hela din idé.

Virtualization for aggregation är inte mer humbug än vad Beowulf är.

https://en.wikipedia.org/wiki/Beowulf_cluster


Beowulf har dock en svaghet och det är att minnesbandbredden i kombination med nätverksbandbredden dikterar hur snabbt varje nod får jobba.

De som ligger på Top500 använder Infiniband eller snabbare tekniker med en throughput på 300 Gb/s. Betyder att minnesbandbredden begränsas till 37 GB/s per nod.

För vanlig konsumenthårdvara blir bandbredden ett ännu större problem och gör Beowulf för dyrt att implementera. På den tiden minnesbandbredden understeg gigabit ethernet var det gångbart.

Känner inte till Beowolf men du berättar själv i ditt inlägg om varför denna teknik suger.
Thoughput är dock helt irrelevant då latency är för hög med både konsument och enterprise prylar. Enda alternativet skulle vara just infinityband men det är på tok för dyrt för någon applikation att driftsätta.

Men framförallt så skalar man ut istället för upp.

You keep using that phrase, I don't think you know what it means.

Superdatorer skalar ut, det är fler servrar som delar på arbetsbördan. De skalar inte upp genom att ha extremt snabba komponenter.

I vilket fall är minnesbandbredden den springande punkten för både virtualization for aggregation såväl som MPI och Beowulf.

100 Gbe fiberkort kan man få för runt 5000 spänn i dagsläget. 40GBASE-T över CAT8 håller på att standardiseras. Omöjligt skall det inte vara att skala ut ett homelab kluster till att göra något meningsfullt. I huvudsak att dela på minnet.