Nu när själva konferensen ligger bakom oss, och vi har hittat tillbaka till labbet, är det dags att avsluta det vi påbörjade. Först och främst en ursäkt för vår radiotystnad dag 3: vårt schema visade sig vara ganska mycket mer späckat än vi trodde att det var, så att hitta vägen till tystnaden i pressrummet visade sig vara mer av ett hinder än ursprungligen förväntas.
Eftersom vårt huvudsakliga mål med att delta på konferensen var att lära oss så mycket om virtualisering som möjligt, snarare än att bara täcka nyhetsflash, tillbringade vi mycket tid i breakout-sessionerna, och jag hoppas kunna lägga in dem i en artikel (eller serie). blogginlägg) åt dig så snart som möjligt.
På med showen! Sista bloggen, skrev jag om den första delen av VMwares molnstrategi, som är vCenter och vSphere, fortsättningarna på dagens Virtual Center och Virtual Infrastructure. Då undrade jag exakt hur feltolerans skulle implementeras, och om du missade kommentarerna från läsaren duploxxx och mina egna, ska jag upprepa vad vi lärde oss här.
I huvudsak utnyttjades det mesta av Fault Tolerance-tekniken från Record/Replay-funktionen som finns i VMware Workstation 6, vilket gör det möjligt för användare att korrekt spela in och reproducera en viss uppsättning åtgärder på en VM perfekt. Som Lionel Cavalliere förklarade för oss, vad det handlar om är hypervisorn som loggar varje enskild CPU-instruktion som sker i den primära virtuella datorn, medan en flytande IP (tänk på failover-kluster) hjälper vCenters virtuella switch att skicka trafik till rätt maskin. Mellan de två maskinerna bör ett privat (helst så snabbt som möjligt) nätverk sättas upp för den primära vSphere för att skicka de inspelade instruktionerna till den som bär shadow VM. I breakout-sessionen förklarades det att ingen IO någonsin utförs av den primära virtuella datorn, utan att den virtuella skuggan först har bekräftat instruktionerna. Både primär- och skugg-VM utför sedan båda IO, men skuggans handlingar undertrycks av dess hypervisor.
Eftersom vCenters uppgift är att övervaka tillståndet för alla vSpheres i nätverket, kommer det att märka när den primära virtuella datorn går ner på grund av ett hårdvarufel och kommer att skicka ut en sändning på nätverket för all trafik som ska omdirigeras till den nu fungerande shadow-VM:n .
Tack till Tijl Deneut för denna bild av Feltoleransmodulen i vCenter!
Som förväntat av den här typen av tung loggning kommer det att bli en ganska märkbar prestandaträff, och vid denna tidpunkt har komplexitetsproblem gjort det omöjligt att aktivera den här funktionen på en virtuell maskin som körs på mer än en enda vCPU, vilket lämnar en hel del mycket utrymme för förbättringar.
Vi har blivit tillfrågade tidigare om den här funktionen, när den är fullt fungerande, kommer att ta bort behovet av andra åtgärder för hög tillgänglighet. Svaret på det är ett ganska avgörande “nej”. VMware sa till oss att de inte har något intresse av att göra sin programvara “påträngande” till den grad att de kan tillhandahålla en failover-lösning för applikationer. Feltolerans är avsedd att skydda den virtuella datorn från ett oväntat maskinvarufel. Mjukvarufel kommer helt enkelt att reproduceras på shadow VM, vilket gör den oanvändbar för återställning. Klustring av applikationer kommer vid denna tidpunkt fortfarande att vara nödvändigt, verkar det som.
Kom tillbaka snart för del 2 av andra dagens keynote!
