Solaris LDOM - Et andet Solaris Virtualization-lag, jeg skal bruge

I et tidligere indlæg diskuterede jeg Solaris Containers / Zones og hvorfor de var en god idé. Solaris har et andet lag af virtualisering kaldet Logiske domæner eller LDOMS. Oracle har omdøbt det til 'Oracle VM Server for SPARC', men i de fleste årsager er det lettere at kalde dem LDOM'er. Nok om nomenklaturen dog. Hvad er disse præcist, og hvorfor skulle du have brug for endnu et lag af virtualisering?

Solaris LDOM'er ligner mere virtualisering på den måde, som VMware leverer den. Du har unikke og fuldt segmenterede containere. Disse kan køre helt forskellige operativsystemer eller versioner af Solaris. Hvis du husker det fra Solaris Zones-artiklen, deler Non Global Zones (NGZ) den samme kerne af Global Zone (GZ), der er vært for det. Du kan køre en ældre version af en NGZ på en GZ, men dette gøres gennem et kompatibilitetsbibliotek, der efterligner det. LDOM giver dig mulighed for at have en unik forekomst.

LDOM kræver, at processoren understøtter virtualisering. For SPARC er dette primært processorer baseret på sunv4-arkitekturen. Lettere at huske / identificere, Sparc T-processorer, om det er T1-T7, selvom der er andre processorer, der understøtter dette. Til x86 / x64. I nyere versioner begyndte Solaris også at understøtte denne teknologi til x86 / x64, men vi vil fokusere på SPARC-processorer til denne artikel.

På dette tidspunkt spørger du sandsynligvis dig selv, dette er fantastisk, men hvorfor har vi brug for flere lag virtualisering? LDOM'er er gode, hvis du har brug for et virkelig isoleret miljø. Måske har du specifikke versioner af Solaris, du har brug for til bestemte formål? For eksempel, hvis du har en produktionsstak, der kræver Solaris 11.1 til databasen og Solaris 10 til appen, kan du nemt oprette et LDOM-gæstedomæne for hver, så du kan køre de specifikke versioner. Måske er din app 5-6 forskellige applikationer, der har brug for noget segmentering, fordi de ikke kan eksistere i samme OS-forekomst. Du kan oprette hver enkelt i en separat zone for at opnå dette.

Som vist ovenfor er en anden brugssag til migrationer. Når det er tid til at afskaffe ældre hardware, men du stadig har brug for de ældre Solaris-versioner, fordi din app bare ikke vil køre på en nyere version, eller måske er den ikke understøttet / ikke-certificeret i den nyere version, og du vil ikke håndtere dette scenario. Spinding af LDOM'er og zoner er en nem og let måde at opnå dette på, da processorkraft og RAM normalt er overskydende.

For at opnå dette er der 5 hovedroller til en LDOM. Kontroldomæne, servicedomæne, I / O-domæne, roddomæne og gæstedomæne. Kontroldomænet er ansvarlig for styring af LDOM'er hostet på den fysiske server. Det kombineres normalt med Servicedomænet, som er ansvarlig for at præsentere bestemte ressourcer til gæstedomænet, f.eks. Diske. Gæstedomænet er det faktiske Virtual Server Guest-operativsystem, der kører. Det forlader roddomænet og I / O-domænet. Disse to kombineres normalt også på kontroldomænet. De er ansvarlige for at give adgang til PCI / PCIe-busser. Det er vigtigt at bemærke, at Guest Domain typisk er det eneste sted, du vil installere dine forretningsapplikationer for at segmentere miljøet korrekt.

I lighed med andre Hypervisors kan LDOM'er overføres live fra en fysisk server til en anden, så længe de har delt lager, og hver server kan se de samme lagerenheder. Dette kan være yderst nyttigt, hvis du har en LDOM, der tygger gennem ressourcer, og du skal balancere. Når du konfigurerer LDOM'erne, opretter du også de grænser, du ønsker for hver af dem med hensyn til RAM, CPU osv.

Nogle af de vigtigste drivere til brug af begge disse lag af virtualisering kommer til processorkraft og RAM-kapacitet, der overgår de faktiske applikationsbehov. For eksempel var jeg involveret i en omfattende Solaris Datacenter-migration, hvor de var i stand til at udskifte 30 racks SPARC-servere, SAN'er og netværksskiftere ned til 6 racks udstyr og 5 SPARC-servere i alt. Med disse 5 SPARC-servere hostes et par hundrede zoner gennem et dusin LDOM'er. Ledelse er meget mere enkel, fordi der kun er fem fysiske servere at administrere. Hvis en zone eller LDOM skal hoppes, er zoneadm- eller ldm-kommandoer let inden for rækkevidde uden at skulle sende nogen til datacenteret eller huske ILOM-forbindelsesoplysningerne.

Administration af LDOM'er kan associeres med rollebaseret adgangskontrol (RBAC). Måske vil du give bestemte administratorer adgang til at ændre LDOM'er, men administratorer til lavere niveauer til Guest Domains / Zones. Let gjort og vigtigt, så du kan begrænse, hvem der har adgang til at forårsage omfattende konfigurationsændringer.