Buzz Word

Har virtualisering blir en buzz ord i den strategiske planen? Ta råd fra noen som har brukt mange år støtte VMware i tre ulike enterprise miljøer - tenke før du V.

Hvis alt du planlegger er en liten eksperimentell klynge av virtuelle servere, det er ingen big deal. Programvaren er også gratis. VMware ESXi er den beste veien å gå. Men, husk, det er bare et frø for fremtidig vekst. Veksten som vil utvikle seg til et rede av uventede problemer hvis du ikke tror før du begynner å rulle ut ESXi vertskap for DEV, QA og PROD miljøer.

V er ikke for Vendetta

Kyniske som dette kan høres, er det mer sant enn fiksjon! Fem måneder fra den dag første ESXi verten er deployert i datasenteret, vil du ha brukere klager over dårlig ytelse, og din smarteste systemansvarlige begynner mange og lange timer med forskning for å løse gåter for virtualisering sikkerhetskopiering, folkevandringer, lagring og andre rare ukjente glitches som er tillagt den "V" ord.

Fikset SCSI feil Fylle opp Logger

Hvis du er dabbling, som jeg sa tidligere gå for det. Virtuelle servere er gøy å jobbe med - det er - før du får for mange på en vert, og du må starte verten, men du kan ikke fordi det er en DEV server som en eller annen måte har blitt en produksjons server og kjører en bedrift kritisk program som absolutt ikke kan returneres! Nå du er fanget mellom klager brukere, bekymret ledere og ikke vite med sikkerhet om reparasjonen brukt av systemadministratoren vil være løsningen for SCSI-feil som fyller opp logger og drepe ytelse. Alt du trenger å gjøre er å sprette verten for å se om endring køen dybden gjør jobben. Det bør fordi ESX kommandoen ble funnet av systemansvarlig når Googling "Fix for SCSI feil Fylle opp Logger"

  og lesing gjennom 50 000 tråder om SCSI-feil og VMware.

Jeg er ikke prøver å være sarkastisk, jeg prøver å få deg til å tenke! Hendelsen om SCSI-feil er en reell situasjon som har spilt i to av de tre VMware virtuelle miljøer jeg har jobbet i. Google "SCSI-feil" + VMware og se selv.

Uvitenhet og arroganse

De to største problemene jeg har lagt merke til siden jeg begynte å støtte VMware er uvitenhet og arroganse. Her er hva jeg mener.

"Jeg" er for uvitenhet

Først, omtrent alle virtuelt miljø starter med uvitende ledere som ikke forstår hva som kreves for å bygge en vellykket virtuelt miljø. De bare vet at alle andre gjør det og det er ment å spare en masse penger. Dessverre, fremtiden lagring vil alle gå ut av vinduene med støtte og lisens kostnader og tapt arbeidskraft. Støtte-og lisenskostnader er lett nok å forstå, men hva jeg mener med tapt arbeidskraft? Vel, arbeidet er mistet mange timer, dager og uker at toppen systemadministratorer bruker prøver å løse gåter VM. Selv når du kjøper dyre støtte problemene ikke går bort. I de fleste tilfeller noen finner bare en work-around fordi løsningen for roten årsaken er å kjøpe en ny SAN eller kraftigere maskinvare fordi noen ikke gadd å sjekke HCL (hard kompatibilitetslisten).

"A" er for arroganse

Å, så er problemene knyttet til arroganse. Her er hvordan dette spiller ut. Du og interessenter bestemmer seg for å distribuere en virtuell infrastruktur for å spare penger, ikke sant? Du starter med den grunnleggende pakken av tre programledere og et virtuelt senter som raskt vokser til 16 og 32 verter (fløyter og bjeller som inngår er: vMotion, HA, DRS). Så du planlegger en 30 minutters møte med dine systemer team og plukke ditt beste systemansvarlig for å lede «Virtualisering Project" (kanskje til og med sende ham til opplæring). Han / hun har bygget massevis av servere og til og med har en MCSE eller RHCE. VMware er enkelt å sette opp. Bare last vertene, installere virtuelle sentrum, og begynne å bygge og P2Ving servere i miljøet. Det er så enkelt, alle kan gjøre det, ikke sant?

En uke senere, Wow! Alle tror du har VMware gud fungerer for deg. Ganske snart VMware guden blir vMotion kjører og HA å arbeide. Deretter er script kjører å gjenstarte og auto-config VM. En annen 30 minutter langt møte er planlagt å planlegge ut migrerer servere inn i den virtuelle infrastrukturen, denne planen kalles "Server Consolidation" Project. Systemansvarlig har blitt et VMware ekspert i to måneder og dette er hans / hennes virtuelt miljø .... Siterer fra god bok, "Pride kommer før høsten".

Jeg er en fast tro på at historien gjentar seg selv så her er hva jeg forutsi skjer videre. Under overflaten av din virtuelle verden trøbbel er i gjære. Først problemene er små og VMware ekspert kan finne dem ut, så problemene blir større, og som enhver normal person ville gjøre, ekspert virker ikke si det til noen fordi de har blitt vant til å være kalt VMware guden, og de aner t vil at noen skal vite at de er veldig dødelig. Snart emails starter sildret inn i innboksen, og du er CC:. Faget stater "hvorfor er min VM så tregt å logge på?". Snart er det ikke lenger en vedlikeholdslading og du er nå "Til:" fra alle brukerne og VMware guden er på slutten av listen som inkluderer alle i GAL og sjefen din. Katten er ute av sekken, det er et problem med   VMware og alle nå vet at VMware Gud er dødelig, og de kommer etter deg. Nei dette er ikke en Steven Spielberg roman det er virkelige ting ...

Hvordan måler du gjør Suksess - Usynlig

Det verste som kunne skjedd har til din virtuelle infrastruktur som har skjedd. Teknisk ting er fixable men det vil ikke være faste enhver tid er snart det dårlig brukeropplevelse som har rammet hundrevis eller tusenvis av brukere som jobber på servere som ble virtualisert. Alle dine forsøk på å selge virtualisering til forretningsenhetene har nettopp blitt ødelagt og brukere ønsker ikke virtuelle servere lenger. Ledere selv krever at alle deres programmer er flyttet frem dine virtuelle infrastrukturen, fordi de ikke kan håndtere dårlig ytelse og klagende arbeidere lenger.

Tommelfingerregel: Måling av en vellykket VMware distribusjon er ikke hvor mange VMs kan være vert per ESX host, dets hvor mange brukere som kan være tilfredsstillende betjent uten dem vite at de bruker virtuelle teknologi. Virtualisering skal være usynlig. Når brukerne begynner å merke fotavtrykk i snøen, er det over før bildet avfyrt.

Gjør det riktig første gangen

Ved å V eller ikke V er fortsatt spørsmålet så her er mine anbefalinger? Ikke engang setup en enkelt vert, selv med gratisversjonen ESXi hvis du ikke har tenkt å gjøre det riktig. Det vil bare snøball derfra til et monster med uventede resultater og i sluttbrukerne vil tro alle virtuelle miljøer er de samme - crap!

Hvis jeg ikke har avskrekket deg og du likevel ønsker å virtualisere, så her er den riktige måten å gjøre det. (Unnskyld min arroganse).

Først samarbeider tett med leverandører. Lytt til dem og la dem guide deg. Ja, vil de prøve å selge deg bedre utstyr, men ikke fordi de ønsker å utnytte deg. De kan ikke fortelle deg dette, men de vet at du vil få problemer hvis du kjøper den billigste utstyret. Min gjetning er at du fortsatt vil være fristet til å kjøpe billige ting du senere vil skylde på leverandøren når brukerne starter sender deg om sine dårlige erfaringer. Som jeg nevnte tidligere, vil det være for sent og du er skyld.

For de som hører til deres leverandørs råd, neste elementet er viktigere. Ansette en erfaren VMware administrator. Ikke prøv å slå et system eller nettverk administrator i en VMware administrator. VMware administratorer er spesialister akkurat som en DBA. Her er grunnen, er VMware en infrastruktur-teknologi, ikke en server teknologi. Sure en system administrator kan bli en dyktig administrator VMware, gjorde jeg. Her er grunnen til at du trenger noen utenfra, vil de bli objektiv om ting som lagring, nettverk, og kvalitet. Eksisterende interne ansatte vil kutte hjørnene fordi de alltid gjør, du bare ikke vet om det. Og sjansene er sannsynlig at du vil stole på en outsider skjønn mer enn en kompis eller underordnet. Hvis det gjøres riktig brukere vil aldri vite forskjellen, hvis det er gjort galt, alle helt opp til administrerende direktør vil bli å sende deg en e-post.

For det tredje krever virtualisering total samarbeid med lagring, nettverk, utviklere, operasjoner og forretningsenheten ledere. Hvis du ikke kan verve dem til å arbeide sammen som "Virtualization Team" glem det. Det er ingenting mer frustrerende enn å prøve å finne ut et problem når lagringsplass administratorer ikke vil la deg kontrollere de bruker "Best Practices" for reguleringsplan for ESX host server lagring stoff, eller når en nettverksadministrator vil ikke gjøre det du spør når du forteller dem Hvorfor gardinen VLAN må lastebil på alle fire data porter for samme vert. Listen over personer problemene fortsetter ...

Forth, er dette viktigere enn mat og vann. Vær så snill, gi akt på min advarsel. Etter at alle har gjort det beste de kan gjøre å sørge for at din virtuelle infrastruktur vil fungere og bli en suksess. Ikke kommer ut av venstre feltet med dine egne ideer og endre alt etter uker og måneder med planlegging. Ikke endre SAN fra nivå 2 til nivå tre. Ikke kjøp en billigere modell av serveren. Ikke gjenta hvordan serverne skal sikkerhetskopieres. Ikke endre noe ... Tiden for å gjøre endringer er i løpet av planprosessen, eller når et uventet problem overflater. Problemet bør ikke bli deg i siste liten kaster en skiftenøkkel inn i blandingen. Vær så snill!

Til slutt, er virtualisering en stor teknologi som etter hvert vil finne det er veien til datasenteret om du vil det eller ikke. Måten du velger å gå er enkel: la det utvikle seg til et monster som alle vil hate eller, planlegger og arkitekten sin distribusjon til noe ingen vet eksisterer. Husk, virtualisering skal være transparent for brukerne. Når de vet den er der, har noen ikke gjort jobben sin riktig.

Konklusjon!

For å virtualisere eller ikke å virtualisere er spørsmålet? Mitt svar på dette spørsmålet er i form av et spørsmål, "Hvor viktig er folk til deg?" Hvis deres tilfredshet er det viktigste på listen din, og hvis glade folk hakker i vei på tastaturet er din topp prioritet så sørg for når du begynner å sette sammen din virtualisering team og begynner du å planlegge 30-minutters møter, alle vet fra første dag, inntil prosjektet er avsluttet at målet er "virtualisering skal være usynlig for brukeren".

Opprinnelig postet 2008-11-11 13:04:10. Publiseres ved blogginnlegg Arrangøren